Pourquoi cette mesure ?
La question du cloud public n’est pas seulement celle de l’emplacement physique des serveurs. Elle concerne la juridiction applicable, les accès administrateurs, la chaîne de sous-traitance, le chiffrement, la traçabilité, la continuité d’activité et la capacité à résister à des demandes extraterritoriales. La mesure 9.02 part d’une intuition forte — les données publiques sensibles ne doivent pas dépendre d’une infrastructure dont l’État ne maîtrise pas les risques — mais elle doit être rendue plus précise qu’une formule « tout SecNumCloud ». Toutes les données publiques n’ont pas le même niveau de sensibilité, et toutes les applications ne justifient pas le même coût de protection.
État des lieux en 2026 : partir de ce qui existe vraiment
L’ANSSI maintient le référentiel SecNumCloud 3.2 et une liste de services qualifiés ou en cours de qualification. La DINUM utilise déjà des infrastructures souveraines pour Albert API et la doctrine cloud de l’État prévoit des exigences renforcées pour certaines données sensibles. La page distingue donc trois situations : données ordinaires pouvant relever d’offres standard correctement sécurisées ; données sensibles ou stratégiques exigeant un niveau de confiance renforcé ; systèmes pouvant rester sur des clouds internes de l’État si le niveau de sécurité est démontré. Cette classification est plus crédible qu’une obligation uniforme qui pourrait créer des goulets de capacité.
Source au point d’usage : ANSSI — référentiel SecNumCloud 3.2 ↗
Concevoir, financer et sécuriser la mise en œuvre
Architecture, fonctionnement et conditions techniques
Le dossier propose une matrice décisionnelle : sensibilité des données ; conséquence d’une indisponibilité ; exposition extraterritoriale ; besoin de chiffrement sous contrôle de l’administration ; localisation des personnels d’exploitation ; dépendance à des services propriétaires. Une application de communication publique et un système contenant des dossiers fiscaux n’appellent pas la même réponse. L’exigence doit être inscrite dans l’architecture cible, avec un registre des exceptions, leur justification, leur durée et une date de réexamen. Les offres qualifiées doivent également être testées sur la portabilité : sécurité élevée ne doit pas signifier enfermement contractuel.
Démonstration financière : séparer coût, capacité et économie
Il n’existe pas d’« économie SecNumCloud » automatique. Une migration peut au contraire augmenter le coût direct d’hébergement. Le calcul doit comparer le coût total de possession : abonnement, migration, exploitation, transfert de données, support, sécurité, redondance, coût de sortie et risque d’interruption. Le bénéfice principal est un risque réduit et une meilleure maîtrise juridique. Lorsqu’un différentiel de prix est constaté, il doit être publié par catégorie d’usage plutôt que masqué dans un agrégat. L’État peut ensuite décider que le surcoût de sécurité est justifié pour certaines données, exactement comme il accepte des coûts supplémentaires pour d’autres infrastructures critiques.
Droit applicable et limites à ne pas franchir
SecNumCloud est une qualification de sécurité, pas une formule magique abolissant le RGPD, la commande publique ou le droit de la concurrence. Les marchés doivent rester proportionnés à l’objet et aux risques. Si une exigence de qualification limite fortement le nombre de candidats, le dossier de consultation doit documenter la nécessité de cette exigence. Les règles relatives aux transferts et aux accès extraterritoriaux doivent être vérifiées indépendamment du simple lieu d’hébergement. La CNIL et l’ANSSI doivent intervenir selon leurs compétences respectives : protection des personnes pour l’une, sécurité des systèmes et qualification pour l’autre.
Plans A, B et C : l’objectif survit au blocage d’une voie
classification nationale des données et migration prioritaire des systèmes sensibles vers des offres qualifiées.
si la capacité du marché qualifié est insuffisante, conserver temporairement certains systèmes sur infrastructures publiques internes homologuées tout en préparant la migration.
pour les usages moins sensibles, appliquer des clauses fortes de localisation, chiffrement, sous-traitance et réversibilité sans prétendre qu’ils sont équivalents à SecNumCloud. Le refus d’un fournisseur ou l’absence d’une offre adaptée ne doit pas rendre le service public indisponible : la continuité prime, mais l’exception doit être temporaire et auditée.
Risques, objections et garde-fous
Les risques symétriques sont la sous-protection et la surprotection. Sous-protéger expose l’État à des accès non maîtrisés et à une perte de souveraineté. Surprotéger chaque donnée au niveau maximal peut renchérir inutilement les services et concentrer le marché sur quelques fournisseurs. Une politique saine publie les critères de classification, mesure les capacités disponibles et conserve une possibilité de pluralité technologique. Elle prévoit aussi la sortie : exporter données et configurations, documenter les interfaces et tester réellement la bascule.
Indicateurs, audit et preuve de réussite
Indicateurs : part des systèmes classifiés ; part des systèmes sensibles sur environnement qualifié ou homologué ; nombre d’exceptions ; coût de migration ; coût récurrent par application ; concentration des fournisseurs ; résultats d’audits de sécurité ; temps de réversibilité ; incidents liés à la chaîne de sous-traitance ; disponibilité. Un indicateur « 100 % SecNumCloud » sans distinction de risque serait trop simpliste et pourrait inciter à de mauvais arbitrages.
Classer les données avant de choisir l’hébergement
Une règle d’hébergement crédible commence par une classification des données et des usages. Les données publiques ouvertes, les documents internes ordinaires, les données personnelles sensibles, les secrets protégés et les informations relevant de fonctions régaliennes n’appellent pas automatiquement le même niveau de protection. Le classement doit intégrer non seulement la donnée brute, mais aussi le résultat produit par le modèle : un résumé peut révéler une information sensible même si l’entrée a été pseudonymisée.
Chaque classe reçoit des exigences de chiffrement, journalisation, localisation, réversibilité et accès administrateur. Ce travail empêche deux excès : sous-protéger une donnée critique ou imposer à un usage banal une solution tellement coûteuse qu’elle freine toute modernisation. La sécurité devient alors un choix de risque explicite, pas un slogan commercial.
Ce que SecNumCloud apporte et ce qu’il ne garantit pas à lui seul
La qualification SecNumCloud constitue un niveau de confiance élevé pour des services de cloud, mais elle ne remplace pas l’architecture de sécurité du client. Une administration peut choisir un prestataire qualifié et malgré tout mal configurer ses droits, conserver trop longtemps des données, exposer des clés ou copier des informations sensibles dans un service non prévu. Inversement, certains traitements peu sensibles peuvent être correctement protégés sans exiger la qualification la plus élevée.
La mesure doit donc combiner qualification du prestataire, politique interne, maîtrise des identités, chiffrement, sauvegardes et tests de restauration. Le contrat doit également préciser les sous-traitants et les changements de périmètre. L’objectif est d’obtenir une chaîne de confiance complète et contrôlable, pas d’acheter une étiquette puis de considérer le risque comme réglé.
Construire une doctrine d’exception plutôt qu’une interdiction absolue
Il existe des situations où une administration peut avoir besoin d’un service spécialisé ne disposant pas immédiatement de l’environnement cible. La bonne réponse n’est ni l’interdiction aveugle ni l’exception permanente. Une procédure d’exception doit identifier la donnée, la finalité, la durée, les mesures compensatoires, le responsable qui accepte le risque et la trajectoire de sortie.
L’exception doit expirer automatiquement et être réexaminée. Les données les plus sensibles peuvent rester exclues sans dérogation. Pour les autres, un environnement de test sur données synthétiques ou anonymisées peut permettre d’évaluer l’outil avant tout transfert réel. Cette mécanique donne aux administrations une capacité d’innovation sans transformer l’expérimentation en dépendance durable ni contourner silencieusement la politique de souveraineté.
Mesurer le coût total plutôt que le prix mensuel du cloud
Comparer deux offres uniquement par le prix de stockage ou de calcul est insuffisant. Le coût total comprend la migration, les compétences d’exploitation, les transferts de données, la supervision, les sauvegardes, les environnements de secours, la certification, les tests de réversibilité et le coût d’une sortie. Une offre apparemment moins chère peut devenir très coûteuse si les données sont difficiles à exporter ou si chaque changement impose une prestation propriétaire.
À l’inverse, un environnement qualifié plus cher peut réduire certains risques et mutualiser des contrôles. Le dossier budgétaire doit donc présenter une durée d’analyse, par exemple cinq ans, et au moins trois scénarios de charge. Il ne faut reconnaître une économie que lorsqu’un coût historique disparaît réellement après migration, et non au moment où une promesse tarifaire est signée.
Contrôle annuel de la souveraineté d’hébergement
Chaque année, un tableau de bord doit publier le nombre de services par classe de sensibilité, le nombre d’exceptions, leur ancienneté, les incidents, les tests de restauration et les tests de sortie. Les administrations doivent aussi indiquer les principaux fournisseurs et la concentration des dépenses. Une dépendance excessive à un seul opérateur constitue un risque même si cet opérateur satisfait les exigences de sécurité.
Les résultats techniques sensibles peuvent rester non publics, mais les tendances, coûts et écarts doivent être accessibles aux organes de contrôle. Le succès de 9.02 se constate lorsque les exceptions diminuent ou sont justifiées, que les restaurations fonctionnent et qu’un changement de prestataire peut être préparé sans interrompre le service. La qualification devient ainsi un composant d’une politique vérifiable plutôt qu’une fin en soi.
Approfondissement opérationnel et conditions de réussite
Résidence des données, contrôle juridique et contrôle opérationnel : trois questions différentes
Héberger des données en France ne répond pas à lui seul à toutes les exigences de sécurité. Il faut distinguer l’emplacement physique, le droit applicable au prestataire et le contrôle opérationnel de l’infrastructure. La qualification SecNumCloud traite précisément un ensemble d’exigences de sécurité et de confiance ; elle ne doit pas être réduite à un drapeau sur une salle informatique. Pour chaque système, l’analyse classe les données, identifie les administrateurs, documente les sous-traitants et vérifie les mécanismes de chiffrement, de journalisation et de support. Les données ordinaires peuvent relever d’un niveau de protection proportionné ; les données sensibles ou les fonctions critiques exigent un niveau renforcé. Cette logique évite à la fois le laxisme et l’obligation coûteuse d’utiliser le même niveau de sécurité pour tout.
Tester la sortie avant de signer : la réversibilité comme critère d’hébergement
Le marché d’hébergement n’est accepté qu’après un scénario de sortie crédible. Le candidat décrit les formats d’export, le volume de données, le débit nécessaire, les coûts de transfert, la restitution des configurations et la suppression vérifiable des copies résiduelles. Un test sur un échantillon représentatif est réalisé avant la généralisation. Pour les services critiques, le plan prévoit une période de coexistence entre l’ancien et le nouvel environnement afin de limiter le risque de rupture. Le coût de la sortie est intégré au coût total de possession dès l’appel d’offres. Un prix d’hébergement faible mais une sortie prohibitive n’est donc pas considéré comme une économie. Cette discipline lie directement sécurité, souveraineté et maîtrise budgétaire.
Établir une matrice de classification des données avant toute décision d’hébergement
La décision d’hébergement commence par la finalité et le contenu : données publiques, données internes, données personnelles ordinaires, données sensibles au sens du droit, secrets protégés, informations de sécurité ou données dont l’indisponibilité paralyserait une mission essentielle. La matrice indique pour chaque catégorie les exigences minimales de chiffrement, localisation, administration, sauvegarde, journalisation et continuité. Les applications composites peuvent séparer leurs données au lieu d’appliquer le niveau le plus élevé à tout le système. Cette approche réduit le coût de surprotection tout en rendant visibles les données qui exigent réellement un environnement de confiance renforcé. La classification est validée par les responsables métier et de sécurité, puis revue lorsque le périmètre change. Une politique d’hébergement crédible est donc d’abord une politique de connaissance des données.
Suivre la qualification et les sous-traitants pendant toute la durée du marché
Une qualification ou une certification observée au jour de l’achat ne dispense pas du suivi. Le marché exige l’information sur les changements substantiels d’infrastructure, de sous-traitant, de localisation ou de contrôle. Les responsables vérifient périodiquement que les conditions ayant justifié le choix restent réunies. Si une qualification expire ou si un changement augmente le risque, un plan de remédiation ou de migration est déclenché selon la criticité. Le registre contractuel conserve les versions des engagements et les principaux changements. Ce suivi empêche une situation où l’administration achète un niveau de confiance puis découvre plusieurs années plus tard que la chaîne technique ou capitalistique a profondément évolué. Il prépare aussi la réversibilité en maintenant à jour les informations indispensables à une sortie.
Définir clairement la responsabilité partagée entre administration et hébergeur
Même un prestataire hautement qualifié ne sécurise pas une application mal configurée. Le dossier répartit donc explicitement les responsabilités : sécurité physique et infrastructurelle, configuration des services, gestion des identités, chiffrement applicatif, correctifs, sauvegardes, supervision, détection d’incidents et réaction. Les tâches incombant à l’administration sont affectées à une équipe et ne sont pas supposées réalisées par le fournisseur. Les contrôles vérifient cette matrice plutôt que de se limiter à la conformité contractuelle du prestataire. Cette distinction est essentielle pour l’analyse des incidents : elle évite qu’un défaut de configuration interne soit présenté comme un échec du cloud ou, inversement, qu’une responsabilité du fournisseur soit diluée. La souveraineté opérationnelle implique de savoir précisément qui peut agir sur quoi.
Organiser la migration par coexistence plutôt que par bascule brutale
Lorsqu’un service existant doit rejoindre un environnement plus protecteur, la transition peut être plus risquée que l’état initial. Le plan inventorie les dépendances, mesure les volumes, teste les performances et prépare la synchronisation. Pour les services importants, une période de coexistence permet de comparer résultats et de revenir temporairement en arrière si une anomalie apparaît. Les données sont transférées avec contrôles d’intégrité ; les sauvegardes et clés sont traitées selon une procédure distincte. Les coûts de double fonctionnement sont identifiés comme coûts de transition, pas dissimulés dans l’exploitation courante. Cette méthode permet de prioriser les migrations selon le risque au lieu de fixer une date uniforme politiquement séduisante mais techniquement dangereuse. La protection progresse ainsi sans sacrifier la continuité du service public.
Sources primaires et institutionnelles
Les affirmations de droit ou d’état de l’art ci-dessus sont rattachées à des sources publiques. Les hypothèses propres au Plan Delta-Sierra sont signalées comme propositions et ne sont pas présentées comme des chiffres officiels.
- ANSSI — référentiel SecNumCloud 3.2 ↗
- ANSSI — offres qualifiées ↗
- DINUM — infrastructure Albert ↗
- CNIL — IA et RGPD ↗
Date de vérification : 12 août 2026. Le cadre de l’IA évolue rapidement ; les dates d’application du règlement européen sont vérifiées contre le règlement (UE) 2026/1744.