Ce que SecNumCloud est, et ce qu’il n’est pas
SecNumCloud est un référentiel d’exigences publié par l’ANSSI, l’Agence nationale de la sécurité des systèmes d’information, qui sert de base à une qualification des services de cloud computing. Le terme de qualification a un sens précis dans la doctrine française : il ne s’agit pas d’une simple attestation délivrée par un organisme privé, mais d’un acte par lequel l’État, via l’ANSSI, reconnaît qu’un produit ou un service atteint un niveau de sécurité défini et peut être recommandé pour la protection des informations sensibles [1].
La distinction est fondamentale. Une certification ISO 27001 est délivrée par un organisme accrédité qui vérifie l’existence d’un système de management. La qualification SecNumCloud va plus loin : l’ANSSI elle-même supervise le processus, valide les évaluateurs, et engage la crédibilité de l’État sur le résultat. Un service qualifié SecNumCloud figure sur la liste officielle des produits et services qualifiés publiée par l’agence.
Ce que SecNumCloud n’est pas mérite d’être énoncé aussi clairement. Ce n’est pas un label marketing que tout fournisseur peut afficher sur sa page d’accueil. Ce n’est pas non plus une garantie d’incident zéro. Et ce n’est pas un synonyme de cloud public hyperscale : aucun des trois grands fournisseurs mondiaux ne dispose, en 2026, d’une offre intégralement qualifiée SecNumCloud sous leur propre marque, précisément à cause des critères de juridiction.
La genèse : du besoin de l’État à la doctrine de souveraineté
Le référentiel SecNumCloud est né d’un constat opérationnel. À partir du milieu des années 2010, l’administration et les opérateurs d’importance vitale ont massivement migré vers le cloud. Cette migration a soulevé une question que les certifications de sécurité classiques n’adressaient pas : qui peut légalement accéder aux données hébergées, indépendamment des mesures techniques de protection ?
La réponse tenait moins à la cryptographie qu’au droit. Un fournisseur soumis à une législation extraterritoriale, comme le CLOUD Act américain de 2018 ou la section 702 du Foreign Intelligence Surveillance Act, peut être contraint par une autorité étrangère de communiquer des données, y compris lorsque ces données sont physiquement hébergées en Europe. Le chiffrement protège contre une interception technique, pas contre une réquisition judiciaire adressée à l’entité qui détient les clés ou le contrôle de l’infrastructure.
SecNumCloud a donc évolué pour intégrer cette dimension juridique. Les premières versions se concentraient sur la sécurité technique et organisationnelle. La version 3.2, entrée en application et applicable aux qualifications instruites en 2026, ajoute des exigences explicites destinées à neutraliser le risque d’accès extraterritorial. Cette évolution s’inscrit dans la doctrine plus large de souveraineté numérique portée par les pouvoirs publics français, dont nous décrivons les acteurs dans notre comparatif Cloud souverain France 2026 : OVH vs Scaleway vs Outscale.
Le contenu du référentiel 3.2 : trois grandes familles d’exigences
Le référentiel SecNumCloud couvre plusieurs centaines d’exigences réparties en chapitres. Pour un décideur, elles se regroupent utilement en trois familles.
Sécurité technique et organisationnelle
Cette première famille reprend et durcit le socle commun aux référentiels de sécurité de l’information. Elle couvre la gouvernance de la sécurité, la gestion des risques, la sécurité physique des centres de données, le contrôle d’accès logique, la cryptographie, la gestion des vulnérabilités, la journalisation, la détection et la réponse aux incidents, la continuité d’activité et la sauvegarde.
Sur de nombreux points, SecNumCloud s’aligne sur la logique d’ISO 27001 et de la norme ISO 27017 dédiée au cloud, mais avec des exigences plus prescriptives. Là où ISO 27001 demande à l’organisation de définir et de justifier ses mesures, SecNumCloud impose souvent des seuils ou des mécanismes précis. La détection et la réponse à incident, par exemple, doivent répondre à des exigences proches de celles que nous détaillons pour les outils de détection dans EDR vs MDR vs XDR : comparatif RSSI 2026.
Localisation des données et des opérations
La deuxième famille concerne la géographie. Le référentiel exige que les données du commanditaire, y compris les données de gestion et les métadonnées, soient hébergées au sein de l’Union européenne. Il exige également que les opérations d’administration et de support qui donnent accès à ces données soient réalisées par des personnels situés dans l’Union, et que les outils d’exploitation soient eux-mêmes maîtrisés depuis l’Union.
Cette exigence dépasse la simple localisation physique des serveurs. Un centre de données situé à Paris mais administré à distance par des équipes situées hors d’Europe, ou dont les outils de supervision remontent vers une console pilotée depuis un pays tiers, ne satisfait pas le critère. La localisation porte sur l’ensemble de la chaîne d’accès aux données, pas seulement sur l’emplacement des disques.
Immunité aux lois extraterritoriales
La troisième famille est celle qui distingue le plus nettement SecNumCloud des autres référentiels. Elle vise à garantir que le prestataire ne peut pas être contraint par une autorité d’un pays tiers de communiquer les données ou de compromettre la sécurité du service.
Les critères portent sur la structure même du fournisseur : son siège social et son administration centrale doivent se situer dans l’Union européenne, et son contrôle capitalistique ne doit pas permettre à une entité soumise à un droit extracommunautaire d’exercer une influence déterminante. Des montages de type coentreprise sous licence, où une technologie étrangère est exploitée par une structure européenne mais sous le contrôle effectif d’un actionnaire extra-européen, font l’objet d’une analyse approfondie de l’ANSSI. L’agence examine la réalité du contrôle, pas seulement sa forme juridique apparente.
La portée juridique réelle : obligation ou recommandation
Une confusion fréquente consiste à présenter SecNumCloud comme une obligation légale généralisée. La réalité est plus nuancée et mérite d’être posée précisément, car elle conditionne les arbitrages d’architecture.
Pour l’administration de l’État, la doctrine Cloud au centre rend SecNumCloud obligatoire de fait pour l’hébergement des données qualifiées de sensibles. Cette doctrine, formalisée par circulaire du Premier ministre, impose que les données sensibles des administrations soient hébergées soit sur le cloud interne de l’État, soit sur une offre commerciale qualifiée SecNumCloud. Pour ces données, le recours à une offre non qualifiée n’est pas une option par défaut.
Pour le secteur privé, il n’existe pas d’obligation générale de recourir à SecNumCloud. Une entreprise reste libre d’héberger ses données sur l’offre de son choix, sous réserve du respect du RGPD et des règles sectorielles. SecNumCloud relève alors de la recommandation et du choix de gestion du risque.
Toutefois, certains régimes sectoriels et certaines exigences réglementaires créent une pression indirecte. Les opérateurs assujettis à la directive NIS2, dont nous détaillons les obligations dans le guide NIS2 entreprise 2026, doivent maîtriser le risque lié à leur chaîne d’approvisionnement numérique. Pour les traitements les plus sensibles, le recours à un hébergeur qualifié SecNumCloud devient un moyen lisible de démontrer cette maîtrise à l’autorité de contrôle. De même, les entités financières soumises au règlement DORA, que nous analysons dans DORA : obligations cyber du secteur financier, doivent encadrer le risque lié aux prestataires tiers de services informatiques ; la qualification SecNumCloud constitue un argument de conformité parmi d’autres.
La bonne formulation est donc la suivante : SecNumCloud est obligatoire pour un périmètre défini de données publiques sensibles, et fortement recommandé comme moyen de preuve pour les traitements critiques du secteur privé régulé.
SecNumCloud face aux autres référentiels
Un décideur confronté à une offre cloud rencontre une accumulation de logos de conformité. Distinguer leur portée respective évite les erreurs d’appréciation.
| Référentiel | Délivré par | Couvre la juridiction | Couvre la localisation | Portée |
|---|---|---|---|---|
| ISO 27001 | Organisme accrédité | Non | Non | Système de management de la sécurité |
| ISO 27017 / 27018 | Organisme accrédité | Non | Partielle (27018) | Sécurité et données personnelles cloud |
| SOC 2 | Cabinet d’audit | Non | Non | Contrôles opérationnels (référentiel américain) |
| HDS | Organisme accrédité | Non | Oui (UE) | Hébergement de données de santé |
| SecNumCloud 3.2 | Qualification ANSSI | Oui | Oui | Sécurité, localisation et immunité juridique |
| EUCS (en cours) | Schéma européen ENISA | Variable selon niveau | Variable | Certification cloud européenne harmonisée |
La lecture de cette table fait apparaître la spécificité de SecNumCloud : il est le seul, avec le futur EUCS dans son hypothèse de niveau le plus exigeant, à traiter conjointement la sécurité technique, la localisation et la juridiction. Une offre cumulant ISO 27001, ISO 27017 et SOC 2 peut afficher une excellente sécurité opérationnelle tout en restant exposée à une réquisition extraterritoriale. C’est ce point précis que SecNumCloud adresse et que les autres référentiels ignorent par construction.
L’hébergement de données de santé, encadré par la certification HDS, mérite une mention particulière. HDS impose une localisation européenne et un référencement, mais ne traite pas la question capitalistique avec la rigueur de SecNumCloud 3.2. Plusieurs hébergeurs de santé certifiés HDS ne satisfont pas les critères d’immunité extraterritoriale de SecNumCloud.
Le cas EUCS : pourquoi le schéma européen ne change rien à court terme
Le schéma européen de certification de cybersécurité pour les services cloud, désigné par l’acronyme EUCS, suscite une attente importante. Élaboré sous l’égide de l’ENISA dans le cadre du règlement européen sur la cybersécurité, il vise à harmoniser les certifications cloud au sein du marché unique [2].
Deux raisons expliquent qu’EUCS ne modifie pas l’équation française à court terme. D’abord, le schéma n’est pas adopté en 2026 : les discussions sur son contenu, et notamment sur l’inclusion ou non de critères de souveraineté au niveau d’assurance le plus élevé, n’ont pas abouti à un acte d’exécution applicable. Ensuite, même une fois adopté, un schéma européen volontaire ne supprime pas automatiquement les exigences nationales tant que les critères de souveraineté ne sont pas garantis à un niveau équivalent.
La position française, exprimée publiquement par les autorités, consiste à maintenir SecNumCloud comme référence nationale tant que le dispositif européen n’offre pas de garanties d’immunité juridique comparables. Pour un DSI, la conséquence pratique est claire : planifier sur la base de SecNumCloud, et traiter EUCS comme une évolution future à surveiller, pas comme un substitut imminent.
Le marché qualifié en 2026 : une offre encore restreinte
La liste des services qualifiés SecNumCloud, publiée par l’ANSSI, reste volontairement exigeante, ce qui se traduit par un nombre limité d’offres. Les acteurs historiques de l’infrastructure française y figurent, avec des périmètres de qualification qui portent sur des familles de services précises, pas nécessairement sur l’intégralité de leur catalogue.
Ce point est essentiel et souvent mal compris. Une qualification SecNumCloud porte sur un service défini, dans un périmètre défini. Un fournisseur peut disposer d’une offre d’infrastructure qualifiée sans que ses services managés de plus haut niveau le soient. Le commanditaire doit donc vérifier que le service précis qu’il consomme entre bien dans le périmètre qualifié, et non se contenter du fait que le fournisseur figure sur la liste.
L’écart entre l’offre qualifiée et l’offre des hyperscalers mondiaux explique une tension structurelle du marché. Les fonctionnalités les plus avancées, en particulier dans les domaines de l’intelligence artificielle et des bases de données managées, sont d’abord disponibles sur les grands clouds publics non qualifiés. Les organisations soumises à SecNumCloud arbitrent donc entre richesse fonctionnelle et conformité. Cet arbitrage rejoint la problématique de dépendance que nous traitons dans Multi-cloud : architecture résiliente et exit strategy hyperscaler.
Le processus de qualification, vu du commanditaire
Pour une organisation qui consomme un service qualifié, le processus de qualification du fournisseur est largement invisible : elle bénéficie d’une qualification déjà obtenue. Comprendre les grandes étapes reste néanmoins utile pour évaluer la solidité d’une qualification affichée.
Le prestataire candidat constitue d’abord un dossier décrivant son service et son organisation. Il fait ensuite réaliser une évaluation par un centre d’évaluation reconnu par l’ANSSI, qui vérifie la conformité aux exigences du référentiel par revue documentaire, entretiens et tests techniques. L’ANSSI instruit le rapport d’évaluation, peut demander des compléments, et délivre la qualification pour une durée de trois ans. Pendant cette période, le prestataire est soumis à une surveillance continue et doit signaler tout changement substantiel.
Trois points appellent l’attention du commanditaire. La date de la qualification indique la version du référentiel applicable : une qualification ancienne peut reposer sur une version antérieure à la 3.2, donc sans les critères d’immunité renforcés. Le périmètre exact précise les services et les centres de données couverts. Les éventuelles réserves ou limitations figurant dans la décision de qualification doivent être lues attentivement.
Implications concrètes pour l’architecture d’un SI
Au-delà de la conformité formelle, l’adoption de SecNumCloud emporte des conséquences sur la conception du système d’information.
La première concerne la classification des données. SecNumCloud n’a de sens que rapporté à un classement préalable des données par sensibilité. Une organisation qui héberge l’ensemble de ses données sur une offre SecNumCloud, sans classification, paie le surcoût d’une exigence souveraine pour des données qui ne le justifient pas. La démarche rationnelle consiste à classifier, puis à n’imposer SecNumCloud qu’aux données qui le requièrent, en cohérence avec une approche Zero Trust telle que nous la décrivons dans Zero Trust : déployer en 5 étapes sans casser le SI.
La deuxième concerne l’architecture hybride. Peu d’organisations placent l’intégralité de leur SI sous SecNumCloud. La pratique courante consiste à isoler les traitements sensibles sur une offre qualifiée, tout en maintenant les charges non sensibles sur des clouds publics plus riches fonctionnellement. Cette segmentation exige une cartographie rigoureuse des flux de données entre les deux environnements, pour éviter qu’une donnée sensible ne transite ou ne soit copiée vers un environnement non qualifié.
La troisième concerne la réversibilité. Comme pour tout engagement avec un fournisseur, le commanditaire doit prévoir les conditions de sortie : format des données exportables, durée de conservation post-contrat, accompagnement à la migration. La qualification SecNumCloud impose au prestataire des obligations de réversibilité, mais le commanditaire doit en vérifier la traduction contractuelle concrète.
Les erreurs d’appréciation les plus fréquentes
Plusieurs malentendus reviennent régulièrement dans les décisions d’hébergement.
Confondre localisation et souveraineté. Héberger des données en France ne suffit pas à les protéger d’une réquisition extraterritoriale si le fournisseur est soumis à un droit étranger. La localisation est nécessaire mais pas suffisante. C’est précisément l’apport de SecNumCloud que d’ajouter le critère juridique à la localisation.
Prendre une certification ISO pour une qualification souveraine. Un fournisseur certifié ISO 27001 peut afficher une posture de sécurité solide tout en étant exposé au CLOUD Act. La certification ISO ne dit rien de la juridiction applicable.
Supposer que tout le catalogue d’un fournisseur qualifié est qualifié. La qualification porte sur un périmètre précis. Consommer un service hors périmètre annule le bénéfice de conformité, alors même que le fournisseur figure sur la liste officielle.
Attendre EUCS pour décider. Reporter un choix d’hébergement souverain dans l’attente d’un schéma européen dont le calendrier et le contenu restent incertains revient à laisser des données sensibles sur des infrastructures exposées pendant une durée indéterminée.
Articuler SecNumCloud avec la conformité globale
SecNumCloud ne s’évalue pas isolément. Il s’inscrit dans un paysage réglementaire dense où plusieurs obligations se recoupent. Une entité essentielle au sens de NIS2, qui héberge des données financières soumises à DORA et applique les exigences de détection du référentiel ReCyF, doit articuler ces dispositifs sans redondance ni angle mort. Notre analyse du référentiel ReCyF ANSSI 2026 montre comment les obligations de détection et de réponse s’imbriquent avec les choix d’hébergement.
La logique d’ensemble est celle d’une défense en profondeur réglementaire : NIS2 et DORA fixent des obligations de gouvernance et de gestion du risque, ReCyF précise les capacités de détection-réponse, et SecNumCloud garantit que la couche d’hébergement des données les plus sensibles repose sur un fournisseur de confiance, à la fois techniquement sûr et juridiquement protégé. Aucun de ces dispositifs ne se substitue aux autres ; ils se complètent.
Références
[1] ANSSI, dispositif des visas de sécurité et qualification des prestataires et services. [2] ENISA, travaux relatifs au schéma européen de certification cloud (EUCS) dans le cadre du règlement (UE) 2019/881. [3] Doctrine d’utilisation de l’informatique en nuage par l’État (Cloud au centre), circulaire du Premier ministre. [4] CLOUD Act (États-Unis, 2018) et section 702 du Foreign Intelligence Surveillance Act, sources du risque d’accès extraterritorial. [5] Référentiel SecNumCloud version 3.2 publié par l’ANSSI.
Sources primaires : ANSSI / cyber.gouv.fr, Produits et services qualifiés ANSSI, ENISA, Légifrance, EUR-Lex.