La souveraineté est passée du discours politique à la clause contractuelle. Dès que vous traitez des données de l'État, des workloads d'opérateurs critiques, des données de santé sous contrat ou de la propriété intellectuelle liée à la défense, la question tombe : votre plateforme tourne-t-elle chez un hébergeur qualifié SecNumCloud ? Cet article revient sur ce que garantit réellement la qualification, quand elle est obligatoire, et surtout sur ce qui change concrètement dans l'architecture d'une équipe plateforme le jour où elle quitte un hyperscaler.
Ce que qualifie réellement SecNumCloud
SecNumCloud est une qualification délivrée par l'ANSSI sur la base d'un référentiel public (version 3.2 aujourd'hui). Ce n'est ni une auto-déclaration ni une certification privée négociée avec un auditeur : un centre d'évaluation agréé audite le prestataire, et l'ANSSI délivre la qualification pour un périmètre défini et une durée limitée, avec des audits de surveillance intermédiaires.
Deux familles d'exigences coexistent :
- Les exigences de sécurité, largement recoupées avec l'ISO/IEC 27001 et enrichies pour le cloud : durcissement, cloisonnement des tenants, administration depuis des postes dédiés, cryptographie, journalisation, réponse à incident, maîtrise de la chaîne d'approvisionnement, habilitation du personnel, sécurité physique.
- L'immunité aux législations extra-européennes. C'est le volet qu'aucun chiffrement supplémentaire ne permet de contourner. Le référentiel encadre la structure capitalistique et juridique du prestataire, la localisation des données et de l'administration, ainsi que l'exposition du fournisseur et de ses sous-traitants à des juridictions tierces comme le CLOUD Act ou le FISA 702.
Un détail opérationnel décisif : la qualification porte sur un service et un périmètre précis, pas sur une entreprise. Un prestataire peut avoir son IaaS qualifié alors que son stockage objet, sa base managée ou son offre Kubernetes restent hors périmètre. Lisez la fiche officielle publiée par l'ANSSI plutôt que la page marketing, et annexez le périmètre au contrat.
Quand est-ce réellement obligatoire ?
SecNumCloud n'est pas une obligation générale pour toute entreprise française. Les moteurs sont :
- la doctrine « cloud au centre » de l'État, qui impose un hébergement qualifié (ou équivalent) pour les données sensibles de l'administration et les applications traitant des données personnelles de citoyens ou d'agents ;
- la loi SREN, qui étend l'exigence de qualification à certaines données sensibles des administrations et de certains opérateurs ;
- la pression sectorielle : opérateurs d'importance vitale, chaînes de sous-traitance défense, et grands donneurs d'ordre qui répercutent l'exigence sur leurs éditeurs logiciels.
Hors de ce périmètre, la motivation relève de l'appétence au risque et de la gouvernance NIS2/DORA, qui imposent de documenter l'exposition juridique des prestataires critiques. Formulation utile pour un COMEX : SecNumCloud est le seul dispositif français qui traite le risque juridique, pas seulement le risque technique.
Positionnement face aux autres référentiels
| Référentiel | Délivré par | Traite l'exposition extra-UE | Usage typique |
|---|---|---|---|
| ISO/IEC 27001 | Organismes de certification accrédités | Non | Socle SMSI, présent partout |
| HDS (données de santé) | Organismes accrédités, cadre français | Non (les hyperscalers sont certifiés HDS) | Obligatoire pour héberger des données de santé |
| C5 (Allemagne) | Auditeurs, catalogue BSI | Non | Attentes du secteur public allemand |
| SecNumCloud 3.2 | ANSSI | Oui, par construction | Données sensibles de l'État, OIV, sous-traitance critique |
| EUCS (schéma européen) | Niveau UE, toujours en discussion | Sujet de négociation politique | Harmonisation future — ne pas bâtir dessus aujourd'hui |
Attention au piège classique : HDS et SecNumCloud sont orthogonaux. Des données de santé peuvent légalement résider chez un hyperscaler certifié HDS ; SecNumCloud ajoute la dimension juridictionnelle que certains projets santé ou recherche exigent désormais en surcouche.
Classifier avant de migrer
L'erreur la plus coûteuse consiste à traiter la « migration souveraine » comme un lift-and-shift de tout le patrimoine applicatif. Commencez par une classification des données, workload par workload, et décidez la cible par classe plutôt que par application. Un modèle en quatre niveaux suffit :
| Classe | Exemples | Cible |
|---|---|---|
| C0 — public | Site vitrine, documentation, open data | N'importe quel cloud, optimisation coût |
| C1 — interne | Artefacts de build, préprod, télémétrie sans identifiants | Région UE de n'importe quel fournisseur |
| C2 — confidentiel | Données personnelles clients, contrats, bases métier | Fournisseur UE, chiffrement à clés détenues par le client, arbitrage au cas par cas |
| C3 — sensible / régulé | Données de l'État, dossiers santé sous contrat, PI défense | Périmètre qualifié SecNumCloud, sans exception |
Regardez ensuite les flux, pas seulement les données au repos. Une base C3 hébergée dans un cloud qualifié perd l'essentiel de son intérêt si les logs, les traces, les sauvegardes, la chaîne CI/CD ou l'outil de ticketing SaaS qui reçoit les stack traces sortent du périmètre. Dans la pratique, c'est la chaîne d'observabilité et de CI/CD qui fait fuiter les programmes de souveraineté.
Ce qui change concrètement pour l'équipe plateforme
Les clouds qualifiés sont pour l'essentiel de solides plateformes IaaS, avec un catalogue de services managés plus étroit qu'AWS, Azure ou GCP. Prévoyez de reconstruire une partie de la couche PaaS :
- Kubernetes : selon le prestataire, vous consommez une offre managée incluse dans le périmètre qualifié, ou vous opérez votre propre distribution sur du compute qualifié. Le cycle de vie des clusters, le CNI, l'ingress, la gestion des certificats et la cadence d'upgrade redeviennent du vrai travail de plateforme.
- Bases de données : moins de moteurs entièrement managés. Les opérateurs Kubernetes (CloudNativePG, opérateurs MariaDB/MySQL, Redis…) sont la réponse standard, avec la responsabilité opérationnelle qui va avec.
- Stockage objet : compatible S3 dans la plupart des cas, mais vérifiez les sémantiques de cohérence, les règles de cycle de vie et les limites multipart avant de supposer que votre outillage fonctionne sans retouche.
- Observabilité : l'APM en SaaS est exclu pour les workloads C3. Prometheus + Thanos/Mimir, Loki, Tempo et Grafana auto-hébergés constituent la pile réaliste. Dimensionnez tôt : le stockage de télémétrie est une ligne budgétaire à part entière.
- CI/CD : des runners SaaS qui viennent « piquer » dans un réseau qualifié constituent un signal rouge en audit. Forge auto-hébergée, ou a minima runners et registries d'artefacts internes au périmètre, avec une promotion à sens unique.
- Secrets et clés : prévoyez un KMS inclus dans le périmètre qualifié, ou un Vault auto-hébergé avec unseal adossé à un HSM. Les clés gérées par le client restent un contrôle fort, même dans un cloud qualifié.
- GPU et IA : la disponibilité progresse mais reste plus rare que chez les hyperscalers. Si vous prévoyez de l'inférence LLM sur données sensibles, validez les quotas et les modèles de GPU disponibles avant de concevoir le produit.
Garder une plateforme portable
La meilleure assurance contre l'enfermement — et contre une évolution du périmètre de qualification — consiste à rendre portable tout ce qui se situe au-dessus de l'IaaS. Terraform pour l'infrastructure, une couche applicative Kubernetes-native, GitOps pour la réconciliation. La surface spécifique au fournisseur doit tenir dans un module fin, réécrivable en quelques jours.
terraform {
required_version = ">= 1.6"
# L'état distant DOIT rester dans le périmètre qualifié.
backend "s3" {
bucket = "tfstate-prod-c3"
key = "platform/terraform.tfstate"
endpoint = "https://s3.fournisseur-qualifie.example"
region = "eu-west-0"
skip_credentials_validation = true
skip_region_validation = true
encrypt = true
}
}
module "landing_zone" {
source = "./modules/landing-zone-souveraine"
# Toutes les spécificités fournisseur sont isolées ici.
classification = "C3"
region = "eu-west-0"
private_only = true # aucune IP publique sur les workers
egress_allowlist = ["repo.internal", "ocsp.internal"]
kms_key_owner = "customer" # clés gérées par le client
}
Côté cluster, faites respecter le périmètre par de la politique, pas par de la documentation. Une règle Kyverno qui bloque toute image issue d'un registre externe attrape la fuite de souveraineté la plus courante : une image de base récupérée discrètement sur un hub public à 3 h du matin.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-registries-c3
spec:
validationFailureAction: Enforce
rules:
- name: only-internal-registry
match:
any:
- resources:
kinds: ["Pod"]
namespaceSelector:
matchLabels:
data-classification: "c3"
validate:
message: "Les images doivent provenir de registry.internal (périmètre souverain)."
pattern:
spec:
containers:
- image: "registry.internal/*"
Coût et réalité hybride
L'hébergement qualifié coûte plus cher à l'unité de calcul que le cloud de commodité, et l'écart se creuse si l'on intègre le temps d'ingénierie consacré à reconstruire les services managés. C'est une raison d'être précis sur le périmètre, pas une raison de renoncer. Le schéma qui fonctionne : un patrimoine hybride où les workloads C3 vivent dans le périmètre qualifié avec des flux entrants et sortants stricts et audités, tandis que le reste reste là où il est le plus efficace — avec une seule base de code IaC, un seul modèle GitOps et un seul fournisseur d'identité couvrant les deux mondes.
Méfiez-vous des recouplages accidentels. Un front C0 qui appelle une API C3 est acceptable ; un service C3 qui dépend d'un feature flag SaaS, d'un collecteur d'erreurs hébergé outre-Atlantique ou d'un CDN externe qui termine le TLS ne l'est pas. Tracez le diagramme de flux, marquez chaque dépendance externe et traitez cette liste comme un livrable d'audit.
Comment évaluer un prestataire
- Vérifiez la qualification sur la liste officielle de l'ANSSI : quels services, quels sites, et quelle date d'échéance.
- Exigez la matrice de responsabilité partagée alignée sur le référentiel 3.2. Beaucoup d'exigences retombent sur vous, pas sur le prestataire.
- Testez la qualité de l'API et du provider Terraform pendant le PoC : c'est là que se matérialise l'écart d'expérience développeur.
- Validez sauvegarde, PRA et réversibilité : clauses de sortie, formats d'export, coûts de sortie de données, et une restauration réellement répétée sur un second site.
- Confrontez le modèle de support et les délais de notification d'incident à vos obligations NIS2/DORA.
- Confirmez que la roadmap des services dont vous avez besoin (Kubernetes managé, KMS, GPU) se situe dans le périmètre qualifié, et pas à côté.
En résumé
SecNumCloud est le dispositif d'assurance cloud le plus exigeant disponible en France, et le seul qui traite sérieusement l'exposition aux lois extraterritoriales. Il s'accompagne d'un catalogue plus étroit et d'un coût d'exploitation supérieur, ce qui fait de la classification des données l'étape décisive : qualifiez ce qui doit l'être, gardez le reste efficace, et investissez dans une couche plateforme portable pour que le choix du fournisseur reste une décision d'un module Terraform, pas une migration de trois ans.