Aller au contenu

SecNumCloud

300 Concevoir ⏱ 1 h 15 cloudsouverainetesecnumcloudscaleway

À la fin, vous saurez

  • Distinguer une qualification de l'ANSSI d'une certification, et un service qualifié d'un fournisseur qualifié
  • Lire les exigences du chapitre 19 du référentiel SecNumCloud 3.2 et expliquer ce que chacune protège
  • Vérifier dans le catalogue officiel de l'ANSSI si une offre est qualifiée, pour quels types de service et jusqu'à quelle date
  • Évaluer une offre hybride (technologie d'un éditeur non européen opérée par une société européenne) au regard des exigences 19.6.c et 19.6.d
  • Déterminer ce qu'il faut qualifier quand on construit un service SaaS sur une infrastructure qualifiée
  • Situer SecNumCloud par rapport au schéma européen EUCS et à son état d'avancement

Prérequis

Pourquoi

La métropole qui veut déployer Signalements dans ses trente communes a joint à son cahier des charges une ligne courte : « hébergement qualifié SecNumCloud ». Le commercial de Lyneko a répondu, de bonne foi, que l'application tourne chez Scaleway, « un cloud français souverain ». Le responsable de la sécurité de la métropole a renvoyé la réponse avec une seule question : « Quel est le numéro de la décision de qualification, et quel est son périmètre ? »

Il n'y en a pas. Au 5 octobre 2026, l'offre SecNumCloud de Scaleway figure dans la liste des offres en cours de qualification de l'ANSSI, pas dans le catalogue des offres qualifiées. Et même si elle y figurait, la question ne serait pas réglée : la métropole n'achète pas des machines virtuelles, elle achète un service, Signalements, que Lyneko exploite. Ce que le cahier des charges demande, c'est peut-être que ce service-là soit qualifié.

Cette scène se répète dans beaucoup d'appels d'offres publics, parce que « SecNumCloud » est devenu un mot de passe : on l'écrit dans les cahiers des charges, on l'imprime sur les plaquettes, on l'applique à des centres de données, à des entreprises, à des logiciels. Or c'est une qualification précise, délivrée à une offre précise, pour des types de service précis, pour une durée précise, au regard d'un référentiel précis, et tout cela se vérifie dans un document public. Cette leçon vous apprend à lire ce référentiel, à vérifier une qualification, et à savoir ce qu'elle vous apporte et ce qu'elle laisse à votre charge.

Les concepts

L'ANSSI et ses visas de sécurité

L'Agence nationale de la sécurité des systèmes d'information (ANSSI), rattachée au Secrétariat général de la défense et de la sécurité nationale, est l'autorité française de cybersécurité. Parmi ses missions, elle évalue des produits et des services et leur délivre des visas de sécurité. Deux mots reviennent, qu'il ne faut pas confondre :

  • une certification atteste qu'un produit (un pare-feu, une carte à puce, un logiciel) résiste à des attaques, après évaluation par un laboratoire agréé (un CESTI) ;
  • une qualification est plus large : elle atteste qu'un produit ou un service est conforme à un référentiel d'exigences, et elle porte aussi sur l'organisation, les personnes et les engagements du prestataire. C'est une recommandation de l'État.

SecNumCloud est une qualification de prestataires de services d'informatique en nuage. Le catalogue de l'ANSSI précise qu'elle est délivrée « au titre de l'article 14 du décret n°2015-350 », le décret relatif à la qualification des produits de sécurité et des prestataires de service de confiance. Concrètement, une offre qualifiée reçoit une décision de qualification numérotée, valable trois ans (FAQ de l'ANSSI), avec un audit de surveillance pendant cette période.

D'où vient le référentiel

Le tableau d'historique du référentiel, en tête du document de l'ANSSI, raconte son évolution :

VersionDate (selon le document)Ce qui change
1.330 juillet 2014Version publiée pour commentaires
2.020 mars 2015Version intermédiaire, utilisée pour une procédure expérimentale
3.08 décembre 2016Première version applicable
3.1indiquée 11 juin 2016Prise en compte du RGPD, retrait du niveau de qualification « avancé »
3.28 mars 2022Intégration principalement de « critères de protection vis-à-vis du droit extra-européen »

La date affichée pour la version 3.1 est antérieure à celle de la 3.0, alors que cette version intègre le RGPD, applicable en 2018 : c'est manifestement une coquille du tableau. Elle illustre un réflexe utile, valable pour tout le cours : un document de référence se lit attentivement, et une incohérence se signale plutôt qu'elle ne se recopie.

La version 3.2 est celle en vigueur au 5 octobre 2026. Elle a pris une valeur nouvelle cet été : l'arrêté du 12 août 2026, pris en application du décret n° 2026-272 du 14 avril 2026 (leçon 4), approuve ce référentiel comme celui que doivent respecter les prestataires de cloud des administrations de l'État pour leurs données d'une sensibilité particulière. Son article 2 précise que le respect du référentiel est attesté « par une qualification délivrée par l'Agence nationale de la sécurité des systèmes d'information » ou par une certification d'un État de l'Union ou de l'Espace économique européen reconnue équivalente. Une qualification qui n'était qu'une recommandation devient, pour ces clients-là, une obligation.

La structure du référentiel

Le référentiel compte 55 pages. Sa structure suit celle de la norme ISO/IEC 27001 et de son annexe de mesures : politique de sécurité et gestion des risques (chapitre 5), organisation (6), ressources humaines (7), actifs (8), contrôle d'accès (9), cryptologie (10), sécurité physique (11), exploitation (12), communications (13), développement (14), tiers (15), incidents (16), continuité (17), conformité (18). Le chapitre 19, « Exigences supplémentaires », est ce qui le distingue d'une simple certification ISO 27001.

Deux mots du vocabulaire du référentiel servent dans toute la leçon. Le prestataire est l'organisme qui fournit le service et vise la qualification. Le commanditaire est son client. Le référentiel distingue aussi les exigences, vérifiées lors de l'évaluation, des recommandations (« il est recommandé »), qui ne le sont pas (chapitre 3.1). Une offre qualifiée respecte toutes les exigences, pas forcément toutes les recommandations.

Ce que couvre la qualification : quatre types de service

Le chapitre 2 définit quatre activités, avec une figure qui répartit les responsabilités entre prestataire et commanditaire, sur le même principe que le modèle de responsabilité partagée de la leçon 2 du cours cloud :

TypeCe que fournit le prestataire qualifiéCe qui reste au commanditaire
IaaSMachines, réseau, stockage, virtualisationSystème d'exploitation, intergiciels, applications, données
CaaSOutils de déploiement et d'orchestration de conteneursBibliothèques, intergiciels, code de l'application
PaaSPlateforme d'hébergement d'applicationsApplications déployées, une partie de la configuration
SaaSL'application complèteParamétrages métier, utilisation

Le chapitre 3.2 en tire la règle qui compte le plus : la qualification porte sur une portée choisie, « tout ou partie des activités décrites au chapitre 2 ». Un prestataire qualifié pour son IaaS peut vendre d'autres services, mais « ne peut, dans ce cas, se prévaloir de la qualification sur ces prestations ». Conséquence directe : on ne qualifie pas un fournisseur, on qualifie une offre, et une console de cloud qui propose cinquante services peut n'en couvrir que quelques-uns.

Les exigences qui font la différence

Une bonne partie du référentiel décrit une hygiène de sécurité exigeante mais classique : authentification multifacteur des administrateurs (9.6.f), interfaces d'administration du prestataire inaccessibles depuis un réseau public (9.6.d), chiffrement des données stockées avec au moins une clé par commanditaire (10.1), vérification renforcée des antécédents des personnes qui ont des privilèges élevés (7.1.b), poste de rebond supervisé pour toute télémaintenance par une personne qui n'a pas passé ces vérifications (12.13), application du guide d'hygiène de l'ANSSI au niveau renforcé (5.1.b). Ce qui distingue SecNumCloud se trouve surtout au chapitre 19.

La convention de service (19.1). Le contrat doit appliquer « le droit d'un État membre de l'Union Européenne » (19.1.c), prévoir une résiliation sans pénalité si le service perd sa qualification (19.1.g), une réversibilité de toutes les données, dans des formats documentés ou par des interfaces documentées (19.1.h et i), et indiquer si les données sont sauvegardées automatiquement (19.1.m). Le prestataire doit aussi inclure l'attestation de qualification dans la convention (19.1.o) : c'est le document que la métropole demandait.

La localisation (19.2). Les données du commanditaire sont stockées et traitées dans l'Union européenne (19.2.b), les opérations d'administration et de supervision sont réalisées depuis l'Union (19.2.c), et les données techniques aussi : identités, journaux, annuaire, certificats, configuration des accès (19.2.d). Une exception est prévue : le support aux commanditaires peut être fourni depuis un État hors de l'Union (19.2.e), à condition de documenter les opérations possibles et leur contrôle depuis l'Union. Ce détail se lit dans la convention de service, où la localisation du support doit être précisée (19.1.b).

La protection vis-à-vis du droit extra-européen (19.6). C'est l'apport de la version 3.2, et la raison pour laquelle SecNumCloud est cité dans les débats sur la souveraineté. Six exigences, à lire dans l'ordre :

  • 19.6.a : le siège statutaire, l'administration centrale et le principal établissement du prestataire sont dans un État membre de l'Union.
  • 19.6.b : le capital et les droits de vote du prestataire ne sont pas, directement ou indirectement, détenus par des entités extra-européennes à plus de 24 % individuellement et à plus de 39 % collectivement. Ces entités ne peuvent pas non plus disposer d'un droit de veto ni désigner la majorité des organes d'administration, de direction ou de surveillance.
  • 19.6.c : si le prestataire recourt à une société tierce extra-européenne (ou contrôlée par une telle société), y compris un sous-traitant, celle-ci ne doit pas avoir « la possibilité technique d'obtenir les données opérées au travers du service », données techniques comprises.
  • 19.6.d : toute société tierce à laquelle le prestataire recourt pour fournir le service doit lui garantir une autonomie d'exploitation continue, ou être elle-même qualifiée. Le référentiel définit cette autonomie comme la capacité de maintenir le service avec ses propres compétences, ou en recourant à des prestations disponibles auprès d'au moins deux sociétés tierces.
  • 19.6.e : le service respecte les droits fondamentaux et les valeurs de l'Union ; les liens du prestataire avec un gouvernement étranger peuvent être pris en considération.
  • 19.6.f : le prestataire informe le commanditaire, dans un délai d'un mois, de tout changement juridique, organisationnel ou technique qui pourrait affecter sa conformité à ce chapitre.

Ces exigences répondent à la question de la leçon 2 : une loi étrangère qui s'applique à une société s'applique d'abord à elle et à ce qu'elle contrôle. SecNumCloud ne cherche pas à rendre une société américaine indifférente au droit américain, ce qui est impossible ; il exige que le prestataire ne soit pas sous ce contrôle, et que ses fournisseurs non européens ne puissent pas techniquement accéder aux données.

Ce que SecNumCloud ne garantit pas

Le référentiel est honnête sur ses limites, au chapitre 3.3.2, qu'il faut lire avant de vendre ou d'acheter une offre qualifiée :

  • la conformité « ne se substitue pas aux exigences légales ou réglementaires » propres à certaines données, comme les données de santé ou de niveau Diffusion Restreinte : un hébergement qualifié n'est pas automatiquement un hébergement de données de santé certifié (leçon 4) ;
  • le référentiel « n'apporte pas de garanties techniques fortes contre un accès du prestataire aux données », seulement des engagements contractuels ; un commanditaire qui veut une protection technique contre son prestataire doit chiffrer lui-même, avec des clés qu'il maîtrise (leçon 5) ;
  • la virtualisation « ne doit pas être considérée comme un mécanisme de cloisonnement équivalent à une séparation physique ».

Le chapitre 4 ajoute que la conformité au référentiel n'atteste pas de la conformité à la politique de sécurité des systèmes d'information de l'État, et qu'un usage pour des données réglementées passe par une homologation du système, avec sa propre analyse de risques. Une qualification réduit le travail d'homologation ; elle ne le remplace pas.

Le processus de qualification

La FAQ de l'ANSSI décrit les grandes étapes. Le prestataire présente son projet à l'ANSSI, puis dépose une demande formelle. L'ANSSI valide l'entrée dans le processus : c'est le jalon J0, à partir duquel le prestataire peut communiquer publiquement sur sa démarche, et apparaître, s'il l'accepte, dans la liste des offres en cours de qualification. L'évaluation est confiée à un organisme d'évaluation de la conformité ; le catalogue de l'ANSSI de septembre 2026 en liste quatre pour SecNumCloud (AFNOR Certification, BYCYB, Certi-Trust France et LSTI), tous habilités pour les quatre types de service. La qualification dure trois ans, avec un audit de surveillance, puis se renouvelle.

Les délais sont longs. Scaleway a annoncé le 9 janvier 2025 la validation de son jalon J0, en visant une qualification fin 2025 ; au 5 octobre 2026, son offre est toujours dans la liste des offres en cours. Ce n'est pas un cas isolé : un projet de qualification mobilise un prestataire pendant un an et demi à deux ans, parce qu'il faut souvent modifier l'organisation, les contrats avec les fournisseurs, parfois l'actionnariat, avant de pouvoir être audité.

Le jalon J0 n'est pas une qualification. Une offre « en cours de qualification » ne donne aucune des garanties du référentiel, et le décret n° 2026-272 ne la reconnaît pas comme conforme. Elle peut en revanche justifier une dérogation temporaire pour un projet existant (leçon 4).

Les offres qualifiées au 5 octobre 2026

Le catalogue de l'ANSSI, mis à jour le 15 septembre 2026 (section 3.3), liste les services qualifiés. En voici le résumé, pour les offres d'infrastructure et de plateforme qui intéresseraient l'hébergement d'une application comme Signalements :

FournisseurServiceTypesQualifié duJusqu'au
CegedimCegNumCloud Secured IaaSIaaS04/12/202404/12/2027
Cloud TemplePaaS OpenshiftPaaS30/05/202530/05/2028
Cloud TempleIaaS Secure Temple (VMware, open source, stockage objet S3, HSM-KMS, bare metal)PaaS, IaaS31/07/202630/05/2028
NumspotPlateforme des services cloud de NumspotIaaS31/07/202631/07/2029
OVHHosted Private Cloud powered by VMwareIaaS28/12/202329/12/2026
OVHBare Metal PodIaaS24/03/202524/03/2028
OVHSNC Cloud PlatformIaaS31/07/202631/07/2029
Orange Business ServicesCloud Avenue SecNumIaaS11/07/202511/07/2028
OutscaleIaaS Cloud on DemandIaaS30/11/202330/11/2026
Thales Cloud SécuriséCloud de confiance S3NSPaaS, CaaS, IaaS17/12/202517/12/2028
WorldlineWorldline Cloud Services, Secured IaaSIaaS24/03/202531/03/2028

Le catalogue liste aussi des services SaaS qualifiés (suites collaboratives, logiciels scolaires, messagerie d'équipe). Trois remarques sur ce tableau, qui valent méthode :

  • Les dates de fin comptent. Deux qualifications d'IaaS arrivent à échéance avant la fin de 2026 (Outscale le 30 novembre, OVH Hosted Private Cloud le 29 décembre). Un renouvellement est probable, mais un cahier des charges sérieux demande une qualification valide pendant toute la durée du contrat, et la clause 19.1.g (résiliation sans pénalité) prévoit le cas contraire.
  • Le nom du service compte. OVH a trois services qualifiés, qui ne recouvrent pas tout son catalogue public. Pour savoir si un service précis (une base de données managée, un Kubernetes) entre dans la portée, il faut lire la décision de qualification, dont le catalogue donne le numéro.
  • Le catalogue est la source. Un communiqué de presse, une page commerciale ou un article annoncent souvent une qualification avant, ou au-delà, de ce que dit la décision. Le catalogue est mis à jour au moins une fois par mois ; il fait foi.

Dans la liste des offres en cours de qualification, consultée le même jour, figurent notamment l'offre « Scaleway SecNumCloud » (IaaS, PaaS) et l'offre « Cloud de Confiance Bleu » (IaaS, PaaS, CaaS), aux côtés d'une quinzaine d'autres.

Les offres hybrides : S3NS et Bleu

Deux projets ont pris une place à part dans le débat : S3NS, coentreprise de Thales et de Google, et Bleu, société détenue majoritairement par Orange et Capgemini. Tous deux proposent la technologie d'un grand fournisseur américain (Google Cloud pour S3NS, Microsoft Azure et Microsoft 365 pour Bleu), opérée par une société européenne, dans des centres de données en France, sans lien d'exploitation avec le fournisseur d'origine.

L'exigence 19.6.c dit pourquoi ce montage peut être qualifié : ce qui compte n'est pas l'origine du logiciel, mais que la société extra-européenne n'ait pas « la possibilité technique d'obtenir les données ». Le code est fourni, les mises à jour sont analysées et déployées par l'opérateur européen, et l'éditeur n'a pas d'accès à la plateforme. S3NS a obtenu en décembre 2025 la qualification de son offre pour l'IaaS, le PaaS et le CaaS ; le catalogue la mentionne sous le nom du fournisseur « Thales Cloud Sécurisé ». Bleu est, au 5 octobre 2026, dans la liste des offres en cours de qualification.

L'exigence 19.6.d pose la vraie question, qui n'est plus juridique mais industrielle : l'autonomie d'exploitation. Si l'éditeur cesse de fournir des mises à jour, par décision commerciale ou parce qu'une loi ou une sanction le lui impose, l'opérateur européen peut-il continuer à faire fonctionner et à sécuriser le service, « en faisant appel aux compétences propres du prestataire » ou à au moins deux autres sociétés ? Pour une plateforme logicielle de cette taille, la réponse dépend de la durée envisagée : quelques mois de fonctionnement sans mise à jour sont imaginables, plusieurs années sans correctif de sécurité ne le sont pas. C'est ce que l'on appelle la dépendance technologique résiduelle. La qualification atteste que l'exigence est satisfaite au sens du référentiel ; elle ne supprime pas ce risque, que la leçon 6 apprend à peser selon la durée de vie du système et sa criticité.

SecNumCloud et le schéma européen EUCS

Le règlement européen sur la cybersécurité de 2019 (Cybersecurity Act) a prévu des schémas de certification européens, préparés par l'agence européenne ENISA. Celui des services cloud, EUCS (European Cybersecurity Certification Scheme for Cloud Services), est en préparation depuis 2020, avec trois niveaux d'assurance : élémentaire, substantiel et élevé. Les premières versions du niveau élevé reprenaient des critères proches du chapitre 19.6 (siège dans l'Union, immunité au droit étranger) ; ces critères de souveraineté ont été retirés du projet en 2024, faute d'accord entre États membres.

Au 5 octobre 2026, EUCS n'est pas adopté. La proposition de révision du Cybersecurity Act présentée par la Commission le 20 janvier 2026 prévoit, selon les analyses publiées, de fonder la certification européenne sur des critères techniques uniquement, en excluant les exigences liées à la souveraineté, traitées par d'autres instruments (sécurité de la chaîne d'approvisionnement des secteurs critiques). Pour une équipe qui choisit un hébergement aujourd'hui, la conséquence est simple : en France, SecNumCloud reste la référence pour la protection vis-à-vis du droit extra-européen, et l'arrêté du 12 août 2026 prévoit déjà l'équivalence d'une future certification européenne de même niveau.

En pratique

Vous allez faire ce qu'aurait dû faire le commercial : vérifier, pour la demande de la métropole, ce qui est qualifié, et identifier ce qu'il faudrait qualifier. Le travail se fait avec deux documents publics : le catalogue de l'ANSSI et la liste des offres en cours de qualification.

Étape 1 : télécharger et dater le catalogue

Le catalogue est un PDF publié par l'ANSSI, mis à jour au moins une fois par mois :

$ curl -sLO https://messervices.cyber.gouv.fr/visas/catalogue-produits-services-profils-de-protection-sites-certifies-qualifies-agrees-anssi.pdf
$ pdftotext -layout catalogue-produits-services-profils-de-protection-sites-certifies-qualifies-agrees-anssi.pdf catalogue.txt
$ grep -m1 "mis à jour" catalogue.txt
$ grep -n "Services d'informatique en nuage" catalogue.txt
  • pdftotext (paquet poppler-utils) convertit le PDF en texte ; -layout conserve la disposition en colonnes des tableaux.
  • La première recherche affiche la date de mise à jour : notez-la dans votre analyse. Une vérification de qualification sans date ne vaut rien six mois plus tard.
  • La seconde donne la ligne de la section 3.3, qui contient le tableau des services qualifiés.

Le catalogue du 15 septembre 2026 contient, dans cette section, le tableau résumé plus haut.

Étape 2 : lire une ligne du tableau

Chaque ligne donne cinq informations : le fournisseur, le nom exact du service, les types couverts (SaaS, PaaS, CaaS, IaaS), les dates de début et de fin de qualification, et un lien vers la décision de qualification. Pour l'hébergement de Signalements, vous cherchez au minimum un IaaS (pour des instances), ou un PaaS ou un CaaS (pour une base de données managée, un Kubernetes).

Constatez que :

  • Scaleway n'apparaît pas dans la section 3.3 ;
  • la liste des offres en cours de qualification, sur le site de l'ANSSI, mentionne « Scaleway SecNumCloud » pour l'IaaS et le PaaS.

Conclusion à écrire telle quelle dans la réponse à la métropole : au 15 septembre 2026, date du catalogue, l'hébergement actuel de Signalements n'est pas qualifié SecNumCloud ; l'offre SecNumCloud de son fournisseur est en cours de qualification, sans date de décision publique.

Étape 3 : lire la décision et poser les bonnes questions

Pour une offre candidate (prenons un IaaS qualifié), la décision de qualification et la convention de service répondent aux questions qui comptent. Voici la liste de celles que Lyneko pose désormais à tout fournisseur qui annonce une qualification :

  1. Numéro de décision, dates de début et de fin, types de service : correspondent-ils au catalogue ?
  2. Portée exacte : quels services de la console sont dans le périmètre qualifié ? La base PostgreSQL managée, le stockage objet, le registre de conteneurs, le répartiteur de charge en font-ils partie ? Comment les distinguer des services non qualifiés dans la console et dans l'API (régions, projets ou comptes dédiés) ?
  3. Localisation du support (19.1.b, 19.2.e) : depuis quels pays, et avec quels accès ?
  4. Sous-traitants extra-européens (19.6.c) : y en a-t-il, et pour quoi faire ?
  5. Réversibilité (19.1.h et i) : formats et interfaces, délai, coût ?
  6. Perte de qualification (19.1.g) : la clause de résiliation sans pénalité figure-t-elle bien dans la convention ?
  7. Chiffrement (10.1) : qui gère les clés, et le client peut-il fournir les siennes (leçon 5) ?
  8. Certification HDS, si des données de santé sont en jeu (leçon 4) : c'est un dossier distinct.

Étape 4 : ce qu'il faut qualifier pour Signalements

Revenez à la demande de la métropole. Elle n'achète pas un IaaS : elle achète Signalements, une application en ligne exploitée par Lyneko. Du point de vue du référentiel, Lyneko est un prestataire SaaS, et l'IaaS sous-jacent est un tiers au sens des chapitres 15 et 19.6.

Deux lectures du cahier des charges sont possibles, et elles n'engagent pas du tout la même chose :

LectureCe qui est exigéCe que Lyneko doit faire
« L'hébergement est qualifié »L'infrastructure sur laquelle tourne Signalements est un service qualifiéMigrer vers un IaaS, PaaS ou CaaS qualifié, et le démontrer
« Le service est qualifié »Signalements lui-même est un SaaS qualifiéEngager une qualification SaaS de Signalements, qui peut s'appuyer sur un IaaS qualifié (la FAQ de l'ANSSI évoque ces qualifications composites)

La seconde est un projet de plus d'un an, qui touche l'organisation de Lyneko (vérification du personnel, administration depuis l'Union, journalisation, gestion des incidents, convention de service). La première est une migration d'infrastructure. Le bon réflexe n'est pas de choisir à la place du client, mais de lui poser la question par écrit, avec ce tableau, avant de répondre à l'appel d'offres. La leçon 4 montre comment déterminer, selon les données traitées, laquelle des deux lectures est imposée par un texte, et laquelle n'est qu'une préférence.

Sous le capot

Pourquoi des seuils de 24 % et de 39 %

Les seuils du 19.6.b ne sont pas arbitraires. Ils restent sous les seuils qui, en droit des sociétés, donnent un pouvoir de blocage ou de contrôle (un tiers des voix permet de bloquer certaines décisions extraordinaires dans de nombreuses sociétés, la majorité donne le contrôle). Le référentiel renvoie d'ailleurs au code de commerce pour définir la notion de contrôle (article L. 233-3) et les déclarations de franchissement de seuils des sociétés cotées (article L. 233-7). L'idée : aucun acteur extra-européen, seul ou avec d'autres, ne doit pouvoir imposer une décision au prestataire, ni s'y opposer. La détention s'apprécie directement ou indirectement : une filiale française d'une société mère américaine échoue au 19.6.b, quelle que soit la localisation de ses serveurs.

Pourquoi les données techniques

La 19.2.d et la 19.6.c étendent la protection aux données techniques : identités des utilisateurs et des administrateurs, journaux, configuration du réseau défini par logiciel, certificats, annuaires. C'est une leçon tirée du fonctionnement réel des clouds : même si les données d'un client sont chiffrées et localisées, un plan de contrôle global, hébergé ou administré ailleurs, connaît la liste des clients, leurs identités, leurs adresses, leurs habitudes d'usage, et détient souvent les moyens d'agir sur leurs ressources. C'est la distinction plan de contrôle et plan de données de la leçon 1 du cours cloud, appliquée à la souveraineté : protéger le plan de données ne suffit pas si le plan de contrôle reste exposé.

Comment on vérifie

Une qualification n'est pas une déclaration sur l'honneur. Le référentiel impose au prestataire d'accepter que l'ANSSI et l'organisme d'évaluation auditent le service (19.1.o), de faire réaliser des audits réguliers par un prestataire d'audit qualifié PASSI (19.1.p, chapitre 18.2) et de prévenir ses clients de tout changement qui touche le chapitre 19.6 (19.6.f). Le commanditaire peut déposer une réclamation auprès de l'ANSSI (19.1.o). C'est ce dispositif de contrôle, autant que le contenu des exigences, qui fait la valeur de la qualification.

Pièges courants

« Notre centre de données est SecNumCloud. » Un bâtiment ne se qualifie pas. Un centre de données peut porter des certifications de sécurité physique, et héberger un service qualifié, mais la qualification porte sur une offre de service. Demandez le numéro de décision.

Confondre « en cours de qualification » et « qualifié ». Le jalon J0 signifie qu'un dossier est ouvert. Il ne donne aucune garantie, et une offre peut rester des années dans la liste, ou en sortir si le projet est suspendu (la page de l'ANSSI le précise).

Utiliser un service hors périmètre. Un fournisseur qualifié pour son IaaS propose aussi, dans la même console, des services qui ne le sont pas. Déployer la base de données sur le service managé non qualifié fait sortir le système du périmètre, souvent sans que personne ne s'en aperçoive. Le périmètre se lit dans la décision et se vérifie dans l'architecture.

Oublier les dépendances de l'application. Signalements tourne sur un IaaS, mais son code est sur GitHub, son pipeline sur GitHub Actions, ses images sur un registre, et l'authentification des administrateurs passe peut-être par un fournisseur d'identité américain. Une infrastructure qualifiée ne qualifie pas ces chaînes-là. La leçon 6 en fait l'inventaire.

Croire que SecNumCloud vaut HDS, ou l'inverse. Le référentiel dit lui-même qu'il ne se substitue pas aux exigences propres aux données de santé. Ce sont deux démarches distinctes, que certains fournisseurs ont menées toutes les deux.

Ignorer la date de fin. Une qualification expire. Un contrat de trois ans signé sur une qualification qui finit dans deux mois repose sur un renouvellement qui n'est pas acquis.

Sécurité

SecNumCloud est d'abord un référentiel de sécurité, et le chapitre 19.6 ne doit pas faire oublier le reste : la plupart des incidents qui touchent les données hébergées viennent d'attaquants, pas d'autorités étrangères. Les exigences sur l'authentification multifacteur des administrateurs, le cloisonnement des interfaces d'administration, la journalisation et sa protection, la surveillance des flux sortants (12.14) et la gestion des incidents protègent contre ces menaces-là, et sont la raison principale pour laquelle l'ANSSI recommande ces offres pour les systèmes sensibles.

Trois points restent à la charge du commanditaire, qualification ou non :

  • La sécurité de ce qu'il déploie. Sur un IaaS qualifié, le système d'exploitation, l'application et leurs configurations sont à vous. Une instance mal configurée sur une offre qualifiée reste une instance mal configurée.
  • Les comptes de son organisation. La compromission d'un compte d'administration du client (hameçonnage, clé d'API dans un dépôt Git, voir la leçon 7 du cours cloud) donne accès aux données, sur une offre qualifiée comme ailleurs.
  • La protection contre le prestataire lui-même. Le référentiel l'écrit : il n'apporte que des engagements contractuels contre l'accès du prestataire aux données. Si votre analyse de risques l'exige, chiffrez avec des clés que vous seul détenez (leçon 5).

En production

  • Tenir un registre des qualifications. Pour chaque service utilisé : nom exact, numéro de décision, dates, types couverts, date de la dernière vérification dans le catalogue. Une vérification trimestrielle suffit, et elle se fait en quelques minutes avec le PDF.
  • Prévoir la perte de qualification. La clause 19.1.g permet de résilier sans pénalité ; encore faut-il savoir où aller. Le plan de sortie de la leçon 8 du cours cloud prend ici tout son sens.
  • Accepter un catalogue plus étroit. Une offre qualifiée propose en général moins de services que le catalogue public du même fournisseur, avec un décalage dans l'arrivée des nouveautés, et des prix plus élevés : la conformité a un coût (organisation, audits, personnel vérifié). Une architecture qui vise une offre qualifiée doit se contenter des briques du périmètre, ce qui plaide pour des choix simples et standard (machines virtuelles, Kubernetes, PostgreSQL, stockage S3).
  • Ne qualifier que ce qui doit l'être. Tout héberger sur une offre qualifiée par principe coûte cher et prive l'équipe d'outils utiles. La leçon 6 apprend à proportionner : les données qui l'exigent sur une offre qualifiée, le reste ailleurs, avec des frontières claires.
  • Chez Lyneko, la réponse à la métropole a été réécrite : état actuel daté, tableau des deux lectures de l'exigence, question posée au client, et engagement de migrer l'hébergement de son instance de Signalements vers une offre qualifiée si la première lecture est retenue.

Exercices

1. Lire une annonce (niveau 300). Un fournisseur écrit sur sa page d'accueil : « Notre cloud est hébergé dans des centres de données SecNumCloud en France, opérés par notre filiale française. » Sa maison mère est cotée aux États-Unis. Listez les questions que vous posez, et dites quelle exigence du référentiel risque d'échouer avant même tout audit technique.

Solution

Questions : quel est le nom exact du service qualifié, le numéro de décision, les dates et les types de service ? Où figure-t-il dans le catalogue de l'ANSSI ? Un centre de données ne se qualifie pas, l'annonce est donc au mieux imprécise. L'exigence 19.6.b échoue presque certainement : une filiale détenue par une société mère américaine voit son capital détenu indirectement à plus de 24 % par une entité extra-européenne, et 19.6.a (siège et principal établissement) pose aussi question selon la structure du groupe. Sans décision de qualification dans le catalogue, l'offre n'est pas qualifiée, quelle que soit la localisation des serveurs.

2. Calculer un actionnariat (niveau 300). Le capital d'un prestataire est détenu par : un fonds européen (45 %), ses fondateurs européens (20 %), un fonds américain (22 %) et un groupe japonais (13 %). Le pacte d'actionnaires donne au fonds américain un droit de veto sur les budgets d'investissement. Le prestataire respecte-t-il le 19.6.b ?

Solution

Individuellement, aucune entité extra-européenne ne dépasse 24 % (22 % et 13 %). Collectivement, elles détiennent 35 %, sous le seuil de 39 %. Mais le 19.6.b interdit aussi à ces entités de disposer, « en vertu d'un contrat ou de clauses statutaires », d'un droit de veto. Le veto du fonds américain sur les investissements fait échouer l'exigence. Pour être qualifiable, le pacte doit être modifié.

3. Évaluer une offre hybride (niveau 300). Une collectivité hésite entre une offre hybride qualifiée (technologie d'un éditeur américain opérée par une société française) et une offre d'un fournisseur européen, qualifiée pour l'IaaS seulement. Son application est un logiciel métier qu'elle doit exploiter pendant dix ans. Quels arguments, liés au référentiel et à la durée, mettez-vous en balance ?

Solution

Les deux offres satisfont le référentiel, y compris 19.6.c et 19.6.d, puisqu'elles sont qualifiées. L'offre hybride apporte un catalogue plus riche (PaaS, CaaS) et des outils familiers. Son risque propre est la dépendance technologique résiduelle : sur dix ans, la capacité de l'opérateur à maintenir et corriger la plateforme sans l'éditeur, si celui-ci cessait de livrer ses mises à jour, est la question centrale, et elle relève d'une analyse de risques plus que du référentiel. L'offre européenne réduit ce risque mais oblige à exploiter davantage soi-même (IaaS seulement) ou à attendre l'extension de la qualification. On compare aussi : dates de fin de qualification, réversibilité (formats et interfaces), coût sur la durée, et facilité de sortie dans les deux cas, ce que les leçons 5 et 6 approfondissent.

4. Le périmètre de Signalements (niveau 300). Lyneko déplace l'instance de Signalements de la métropole sur un IaaS qualifié. Le code reste sur GitHub, le pipeline sur GitHub Actions qui pousse les images dans un registre hébergé hors du périmètre qualifié, et les administrateurs de Lyneko se connectent à l'application avec leur compte Google. Qu'est-ce qui sort du périmètre qualifié, et quels risques cela crée-t-il ?

Solution

Sortent du périmètre : le dépôt de code et le pipeline (GitHub, société américaine), le registre d'images, le fournisseur d'identité des administrateurs. Les données des usagers restent sur l'IaaS qualifié, mais la chaîne qui produit et déploie le logiciel, et l'authentification des administrateurs, dépendent de services soumis à un droit extra-européen. Risques : une compromission ou une contrainte sur la chaîne de livraison peut injecter du code dans l'application (risque d'intégrité, voir le cours Chaîne d'approvisionnement logicielle : SBOM, signature, provenance) ; un fournisseur d'identité externe peut, en théorie, permettre d'usurper un administrateur ; une coupure de ces services bloque les déploiements et l'administration, même si l'application continue de tourner. Ce n'est pas forcément rédhibitoire, mais cela doit être écrit dans l'analyse de risques, et la leçon 6 montre comment arbitrer.

Récapitulatif

  • SecNumCloud est une qualification de l'ANSSI (un visa de sécurité), délivrée à une offre de service, pour des types (IaaS, CaaS, PaaS, SaaS), pour trois ans, au vu du référentiel 3.2 du 8 mars 2022, en vigueur au 5 octobre 2026.
  • L'arrêté du 12 août 2026 approuve ce référentiel pour les données d'une sensibilité particulière de l'État ; la conformité s'atteste par une qualification de l'ANSSI ou une certification européenne équivalente.
  • Le chapitre 19 fait la différence : contrat de droit européen, résiliation sans pénalité en cas de perte de qualification, réversibilité, données et données techniques dans l'Union, administration depuis l'Union, capital extra-européen limité à 24 % individuellement et 39 % collectivement, sans veto ni contrôle, aucune possibilité technique d'accès pour les tiers extra-européens, autonomie d'exploitation.
  • La qualification ne garantit ni la conformité HDS, ni une protection technique contre le prestataire lui-même, ni la sécurité de ce que vous déployez.
  • Le catalogue de l'ANSSI fait foi : nom exact, dates, types, décision. Au 15 septembre 2026, l'offre SecNumCloud de Scaleway est en cours de qualification, pas qualifiée ; S3NS est qualifiée pour l'IaaS, le PaaS et le CaaS ; Bleu est en cours.
  • Construire un SaaS sur un IaaS qualifié ne qualifie pas le SaaS : il faut savoir ce que le client exige.
  • EUCS n'est pas adopté, et ses critères de souveraineté ont été retirés du projet : SecNumCloud reste la référence française.

Pour aller plus loin

  • Le référentiel SecNumCloud 3.2 lui-même, en particulier les chapitres 3, 4 et 19 : une trentaine de minutes de lecture qui évitent beaucoup de malentendus.
  • La FAQ de l'ANSSI sur la qualification SecNumCloud, pour le point de vue d'un prestataire qui se lance.
  • Le catalogue de l'ANSSI, à télécharger chaque trimestre, et la liste des offres en cours de qualification.
  • La leçon suivante, qui dit quels textes imposent un tel niveau de confiance, et à quels clients.
Voir ma constellation →

Sources