Le 14 août 2026, l'arrêté du 12 août a été publié au Journal officiel de la République française. Il approuve la version 3.2 du référentiel d'exigences applicable aux prestataires de services d'informatique en nuage — le nouveau socle de qualification SecNumCloud. Pour les entités soumises à NIS2 qui hébergent tout ou partie de leurs systèmes essentiels chez un prestataire cloud, ce texte n'est pas une mise à jour interne de l'ANSSI : il redéfinit ce qu'est un prestataire qualifié et ce que votre chaîne de sous-traitance doit documenter.
Ce que SecNumCloud qualifie — et pourquoi cela vous concerne
Le référentiel SecNumCloud est le schéma de qualification des prestataires de services cloud piloté par l'ANSSI. Il couvre trois catégories de services : Infrastructure as a Service (IaaS), Platform as a Service (PaaS) et Software as a Service (SaaS). Un prestataire qualifié SecNumCloud a fait auditer ses pratiques de sécurité, d'exploitation, de gestion des incidents et de réversibilité par un organisme d'audit accrédité. La qualification est valable trois ans, renouvelable.
Pour une entité NIS2, le lien avec SecNumCloud n'est pas toujours direct dans le texte de la directive elle-même. Il passe par l'article 21 et ses exigences de gestion des risques liés à la chaîne d'approvisionnement, ainsi que par l'article 6 du décret NIS2 français en cours de transposition. La Commission nationale de l'informatique et des libertés (CNIL) et l'ANSSI ont indiqué dans leurs guides pratiques que l'utilisation d'un prestataire qualifié SecNumCloud est la voie de conformité présumée pour l'hébergement de données sensibles ou de systèmes à risque élevé.
Les principales évolutions de la version 3.2
La version 3.2 introduit plusieurs changements substantiels par rapport à la version 3.1 qui faisait référence depuis 2022. Trois d'entre eux ont des conséquences directes pour les acheteurs de services cloud.
Le premier concerne la souveraineté des données. La version 3.2 renforce les exigences relatives à l'immunité vis-à-vis des législations extra-européennes. Un prestataire qualifié doit désormais démontrer qu'aucune entité soumise à une législation non européenne — notamment la section 702 du FISA américain ou les lois chinoises sur la sécurité nationale — ne dispose d'un accès technique ou juridique aux données hébergées. Cette exigence s'applique non seulement au prestataire lui-même, mais aussi à ses sous-traitants techniques.
Le deuxième changement porte sur la gestion des vulnérabilités. La version 3.2 aligne les délais de correction sur les exigences du Cyber Resilience Act : les vulnérabilités critiques (CVSS ≥ 9.0) doivent être corrigées dans les 24 heures suivant la disponibilité d'un correctif éditeur, ou faire l'objet d'une mesure d'atténuation documentée dans ce délai. Pour les vulnérabilités élevées (CVSS 7.0–8.9), le délai est porté à 72 heures. Ces délais sont contractuellement opposables au prestataire qualifié.
Le troisième changement concerne la réversibilité. La version 3.2 exige que le prestataire documente et teste annuellement la procédure de portabilité des données et de migration vers un prestataire alternatif. Cette documentation doit être mise à disposition du client sur simple demande. L'objectif est de rendre la réversibilité vérifiable, non plus seulement déclarée.
Ce que votre contrat doit vérifier maintenant
Si votre organisation utilise un prestataire cloud qui était qualifié SecNumCloud sous la version 3.1, vous devez vérifier deux points avant la prochaine échéance de votre contrat. Le premier est la date de renouvellement de la qualification : les prestataires disposent d'un délai de transition pour obtenir la qualification sous la version 3.2. Ce délai est fixé à dix-huit mois à compter de la date de publication de l'arrêté, soit jusqu'au 14 février 2028. Pendant cette période de transition, une qualification 3.1 reste valide.
Le second point est la conformité des annexes contractuelles de sécurité. Les SLA relatifs aux délais de correction des vulnérabilités, les clauses de portabilité et les engagements de souveraineté doivent être mis en cohérence avec la version 3.2 lors du prochain renouvellement ou de la prochaine révision contractuelle. Un contrat qui référence explicitement SecNumCloud sans préciser la version peut créer une ambiguïté sur les exigences applicables.
L'articulation avec NIS2 et DORA
L'arrêté du 12 août s'insère dans un contexte réglementaire où la gestion des prestataires cloud fait l'objet d'obligations convergentes. Sous NIS2, l'article 21 exige que les entités gèrent les risques liés à leurs prestataires de services essentiels. Sous DORA, l'article 28 et ses clauses contractuelles ICT obligatoires s'appliquent aux prestataires considérés comme ICT tiers critiques. La qualification SecNumCloud ne se substitue pas à ces obligations : elle les complète en fournissant une base d'audit préalablement vérifiée.
Pour les entités doubles — soumises à la fois à NIS2 et à DORA, typiquement les établissements financiers utilisant des services cloud pour des fonctions critiques — la qualification SecNumCloud 3.2 peut servir de preuve partielle pour satisfaire les exigences de due diligence précontractuelle de l'article 28 de DORA. Elle ne couvre pas l'intégralité des exigences DORA, notamment les droits d'audit contractuels et les plans de continuité spécifiques. L'article sur les clauses contractuelles ICT obligatoires sous DORA détaille les éléments complémentaires à négocier.
Le cas des prestataires non qualifiés
SecNumCloud reste une qualification volontaire. Aucun texte n'interdit à une entité NIS2 d'utiliser un prestataire cloud non qualifié. En revanche, l'utilisation d'un prestataire non qualifié pour héberger des systèmes essentiels ou des données sensibles impose à l'entité de documenter les mesures compensatoires qui justifient ce choix au regard de ses obligations de gestion des risques. Cette documentation fait partie du corpus que les autorités compétentes — l'ANSSI pour les entités françaises — peuvent demander dans le cadre d'un contrôle.
En pratique, pour les entités qui n'utilisent pas de prestataire qualifié SecNumCloud, la version 3.2 sert de référence utile pour construire vos propres questionnaires d'évaluation fournisseurs. Les exigences du référentiel — sur la souveraineté, la gestion des vulnérabilités, la réversibilité — sont des questions légitimes à poser à tout prestataire cloud dans le cadre d'une démarche TPRM. L'article sur les pièges de la cartographie des tiers en 2026 aborde la structuration de ces évaluations.
Trois actions pour les directions conformité
La publication de l'arrêté ouvre une fenêtre de travail utile avant la fin de l'année.
Première action : cartographiez vos prestataires cloud critiques et vérifiez leur statut de qualification. Le site de l'ANSSI maintient la liste des prestataires qualifiés SecNumCloud avec leur version de qualification et leur date d'expiration. Pour chaque prestataire hébergeant des systèmes essentiels ou des données sensibles, vérifiez si sa qualification couvre la version 3.2 ou si elle est encore en période de transition.
Deuxième action : anticipez les révisions contractuelles. Si votre contrat avec un prestataire cloud référence SecNumCloud sans préciser la version, ou si les SLA de correction des vulnérabilités ne correspondent pas aux délais de la version 3.2, incluez une mise à jour de l'annexe de sécurité dans le prochain cycle de révision annuelle. Ne attendez pas le renouvellement complet du contrat.
Troisième action : utilisez la version 3.2 comme grille d'évaluation pour vos prestataires non qualifiés. Extraire les exigences de souveraineté, de gestion des vulnérabilités et de réversibilité du référentiel pour en faire un questionnaire fournisseur est un investissement limité qui renforce votre documentation de due diligence.
L'arrêté du 14 août 2026 est en vigueur. La période de transition de dix-huit mois laisse le temps de mettre en ordre votre documentation contractuelle — mais elle ne reporte pas l'obligation de savoir, dès maintenant, si vos prestataires actuels sont en trajectoire de conformité vers la version 3.2.