SecNumCloud 2026 : Migration et Certification EUCS

La migration vers un cloud qualifié SecNumCloud est l'un des projets les plus complexes qu'une organisation soumise aux réglementations françaises peut engager en 2026. Ce n'est pas une simple opération technique de déplacement d'instances — c'est une transformation architecturale, contractuelle et organisationnelle qui touche les systèmes d'information dans leur profondeur. Les organisations qui tentent cette migration sans méthode se heurtent à trois écueils majeurs : la sous-estimation des dépendances CLOUD Act (des composants tiers innocents en apparence peuvent invalider l'immunité extraterritoriale), les ruptures de service lors de la bascule depuis AWS ou Azure, et les surcoûts de conformité liés aux différences de catalogue entre providers qualifiés et hyperscalers américains. Ce guide détaille une roadmap en 6 étapes éprouvée, les cas d'usage secteur public et santé, les divergences majeures entre EUCS et SecNumCloud, les coûts réels et les risques à ne pas sous-estimer. Une migration SecNumCloud bien conduite prend entre 12 et 36 mois selon la complexité du système d'information — anticiper dès maintenant est déjà prendre de l'avance sur vos obligations réglementaires NIS 2 et doctrine Cloud de l'État.

Étape 1 : Inventaire des données et cartographie applicative

La migration SecNumCloud commence invariablement par une cartographie exhaustive des données et des applications. Cette étape, souvent bâclée, conditionne pourtant toutes les décisions suivantes. L'inventaire doit répondre à quatre questions fondamentales : quelles données sont traitées (nature, sensibilité, volumétrie), où résident-elles actuellement (région AWS, datacenter Azure, S3 bucket, base de données RDS), qui y accède (utilisateurs internes, prestataires, partenaires) et sous quelles contraintes réglementaires (RGPD, HDS, secret défense, données OIV).

En pratique, une organisation de taille intermédiaire (500-2000 collaborateurs) avec un SI hétérogène découvre lors de cet inventaire que 20 à 40 % de ses données sensibles sont hébergées sur des services cloud dont elle avait perdu la trace : buckets S3 créés par des équipes DevOps sans validation sécurité, instances de test jamais dépubliées, sauvegardes externalisées chez des prestataires tiers. Ces « shadow cloud » sont les premiers risques à traiter.

L'outil recommandé pour cette cartographie est une CMDB cloud-native (AWS Config, Azure Resource Graph, ou des outils tiers comme Lyftrondata ou Cloudability) complétée par une revue manuelle des contrats fournisseurs. Le livrable attendu est un catalogue structuré précisant pour chaque actif : sensibilité (selon la classification de l'organisation), contrainte réglementaire applicable, dépendances applicatives et priorité de migration.

Étape 2 : Analyse des dépendances CLOUD Act

C'est l'étape la plus contre-intuitive et souvent la plus révélatrice. L'analyse des dépendances CLOUD Act consiste à identifier, dans l'ensemble de la chaîne de services utilisés, tous les composants dont un fournisseur américain pourrait revendiquer juridiction. Un système hébergé sur OVHcloud peut être invalidé pour SecNumCloud Avancé s'il utilise :

Des services d'authentification externalisés vers Microsoft Azure AD (aujourd'hui Entra ID) ou Okta (entreprise américaine). La fédération d'identité avec un IdP américain expose les logs d'authentification à une potentielle injonction CLOUD Act.

Des CDN ou DNS opérés par Cloudflare (USA), Akamai (USA) ou Amazon Route 53. Ces services transitent par des infrastructures américaines et peuvent être contraints de journaliser ou filtrer le trafic.

Des librairies logicielles ou des services de monitoring (Datadog, New Relic, PagerDuty — tous américains) qui collectent des métadonnées sur les systèmes et les envoient vers des serveurs américains.

Des sauvegardes répliquées automatiquement vers des destinations incluant des régions ou prestataires non qualifiés.

Cette analyse produit une matrice de dépendances où chaque composant est évalué sur son exposition CLOUD Act. Les composants exposés doivent être remplacés par des équivalents européens qualifiés ou maintenus en dehors du périmètre SecNumCloud. Cette phase dure généralement 4 à 8 semaines pour un SI de taille moyenne et nécessite l'implication des équipes techniques, juridiques et achats.

Étape 3 : Choix du provider qualifié

En 2026, trois prestataires dominent le marché cloud qualifié SecNumCloud Avancé en France :

OVHcloud Sovereign Cloud est le choix le plus naturel pour les organisations qui partent d'une infrastructure IaaS standard. OVHcloud propose un catalogue IaaS complet (instances compute, stockage objet, réseaux privés, Kubernetes managé) qualifié SecNumCloud, avec une compatibilité API partielle avec AWS (S3 compatible) facilitant la migration des scripts et outils existants. La présence géographique (Roubaix, Strasbourg, Gravelines) offre une résilience géographique tout-français.

3DS Outscale (S3NS) est à privilégier pour les organisations déjà investies dans l'écosystème Google Cloud (GKE, BigQuery, Cloud Run) ou cherchant des services de données analytiques avancés. Le partenariat S3NS avec Google Cloud permet d'accéder à certains services GCP depuis une infrastructure qualifiée, bien que le périmètre de services qualifiés reste plus restreint que l'offre GCP native.

Numspot, porté par Banque des Territoires, La Poste et Docaposte, est spécifiquement positionné pour les collectivités territoriales, établissements publics et acteurs de l'économie sociale. Son catalogue est pour l'heure plus limité, mais son modèle de gouvernance public-privé est perçu comme un gage de pérennité institutionnelle.

Le critère de choix doit intégrer non seulement la liste des services qualifiés disponibles aujourd'hui, mais aussi la roadmap du provider : quels services seront ajoutés au périmètre qualifié dans les 18 prochains mois ? Un service critique à votre architecture qui n'est pas encore qualifié peut être un bloquant majeur.

Étape 4 : Migration pilote sur environnement non-critique

La règle absolue de toute migration cloud souverain est de ne jamais démarrer par les systèmes critiques. La migration pilote cible un environnement représentatif techniquement mais à faible criticité métier : un environnement de recette, un outil interne peu exposé, ou une application secondaire.

Le pilote remplit trois fonctions : valider que l'architecture cible fonctionne sur l'infrastructure qualifiée (compatibilité des APIs, performances des volumes de stockage, latence réseau), identifier les adaptations applicatives nécessaires (changements de configuration, réécriture de scripts de déploiement, migration des secrets vers un Vault qualifié), et former les équipes ops aux outils et procédures du nouveau provider.

Pour une migration depuis AWS vers OVHcloud, les chantiers techniques classiques incluent : la migration des buckets S3 vers le stockage objet OVH (compatible S3 mais avec des nuances sur les ACLs et les politiques de lifecycle), la conversion des images AMI vers les images QCOW2 ou RAW d'OVHcloud, le reconfiguration des groupes de sécurité (security groups AWS) vers les firewalls OVH, et la mise en place d'une nouvelle chaîne CI/CD pointant vers les registres d'images OVH.

Pour une migration depuis Azure vers 3DS Outscale, les défis sont différents : migration des identités depuis Entra ID vers un IdP souverain (Keycloak hébergé on-premise ou sur Outscale), migration des données depuis Azure Blob Storage vers l'Object Storage Outscale, et remplacement d'Azure Monitor par des outils de supervision open source (Prometheus/Grafana) auto-hébergés dans le périmètre qualifié.

Étape 5 : Tests de non-régression et validation de la conformité

La phase de tests de non-régression est chroniquement sous-dotée en budget dans les projets de migration. Elle doit couvrir trois dimensions : fonctionnelle (les applications rendent-elles les mêmes services ?), performance (les temps de réponse, les débits et la disponibilité sont-ils conformes aux SLA ?) et sécurité (la surface d'attaque a-t-elle été réduite ou au contraire élargie par la migration ?).

La validation de conformité SecNumCloud côté client consiste à vérifier que l'organisation n'a pas reintroduit de dépendances CLOUD Act dans son usage des services qualifiés. Par exemple, configurer une règle de sauvegarde automatique vers un bucket S3 AWS "juste pour la période de transition" invalide immédiatement le bénéfice de la qualification. Cette vérification doit être outillée (scans automatiques des configurations Terraform ou Ansible, revue des flux réseau sortants) et répétée périodiquement. La sécurisation du pipeline de développement doit être intégrée dès cette étape.

Un audit de configuration par un prestataire externe spécialisé est recommandé avant la bascule en production. Cet audit, distinct de l'audit de qualification du provider, porte sur la configuration spécifique de l'organisation cliente : politiques IAM, chiffrement des données au repos et en transit, journalisation des accès, séparation des environnements. La pratique opérationnelle NIS 2 fournit un cadre utile pour structurer cet audit de pré-bascule.

Étape 6 : Certification et audit final

Pour les organisations qui ne sont pas elles-mêmes prestataires cloud mais clientes, la « certification » ne prend pas la même forme que pour un provider. Il s'agit plutôt d'une attestation de conformité documentant que l'organisation utilise les services qualifiés de façon conforme aux exigences réglementaires applicables (doctrine Cloud de l'État, NIS 2, HDS…).

Cette attestation, produite par le RSSI de l'organisation avec l'appui éventuel d'un RSSI externalisé, doit couvrir : la liste des services qualifiés utilisés avec leur périmètre de qualification, la description de la configuration mise en œuvre, les résultats des tests de non-régression, et le plan de surveillance continue. Pour les entités OIV soumises à NIS 2, cette attestation peut être demandée par l'ANSSI dans le cadre des contrôles.

Cas d'usage santé : HDS + SecNumCloud, la double contrainte

Le secteur de la santé présente la contrainte de conformité la plus forte en France : les données de santé à caractère personnel doivent être hébergées par un Hébergeur de Données de Santé (HDS) certifié, et les établissements de santé classés OIV (grands CHU, AP-HP, EPS) doivent en plus satisfaire SecNumCloud pour leurs systèmes d'information critiques.

La bonne nouvelle en 2026 : OVHcloud et 3DS Outscale ont obtenu la double certification HDS + SecNumCloud. Un établissement de santé peut donc migrer son DPI (Dossier Patient Informatisé) ou son SIH (Système d'Information Hospitalier) vers un cloud qui satisfait simultanément les deux référentiels, sans avoir à jongler entre des prestataires distincts.

Le cas pratique d'un CHU régional illustre les enjeux : son ancien hébergeur SaaS pour le DPI ne disposait que de la certification HDS mais pas de SecNumCloud. La migration vers OVHcloud a nécessité 18 mois de projet, 400k€ d'investissement (hors coût d'hébergement récurrent) et une refonte complète des procédures de sauvegarde et de reprise d'activité. En contrepartie, le CHU a pu sortir son SI du périmètre d'exposition CLOUD Act et satisfaire les nouvelles exigences de son classement OIV sans avoir à redéposer un dossier de conformité spécifique à l'ANSSI.

EUCS vs SecNumCloud : les divergences majeures en 2026

La divergence la plus significative porte sur l'accès des entreprises non-européennes. EUCS High standard permettrait à une filiale européenne de Microsoft ou d'Amazon d'obtenir la certification, sous réserve de garanties contractuelles renforcées — une position inacceptable pour la France qui exige l'immunité structurelle. Cette divergence a donné lieu à des négociations intenses au sein de l'ENISA entre 2022 et 2024, et se reflète dans la création du niveau EUCS High Renforcé comme option pour les États membres voulant maintenir des critères d'immunité stricts. La réglementation CRA ajoute une couche supplémentaire de complexité pour les fournisseurs de composants logiciels dans ce contexte.

Coûts de migration : estimation réaliste selon le périmètre

Les coûts de migration vers un cloud qualifié SecNumCloud varient considérablement selon le périmètre. Voici une estimation par profil organisationnel :

PME / ETI (50-200 utilisateurs, 5-20 applications) : 150k€-300k€. La migration cible généralement les outils SaaS (messagerie, collaboration, stockage documentaire) vers des équivalents qualifiés. Le poste principal est l'accompagnement au changement et la formation des utilisateurs.

Collectivité territoriale / Établissement public (200-1000 utilisateurs) : 250k€-500k€. Le SI est plus hétérogène, avec des applications métier spécifiques (progiciels RH, finances) dont la migration requiert l'implication de l'éditeur. Le recours à Numspot ou OVHcloud via des marchés publics cadres peut réduire les coûts.

OIV / Grande administration (1000+ utilisateurs, SI critique) : 500k€-1,5M€ et 24-36 mois. À cette échelle, la migration inclut souvent une refonte de l'architecture réseau (SD-WAN, bastions qualifiés), la mise en place d'un SOC hébergé en France pour la supervision des événements de sécurité, et des programmes de formation étendus. Les obligations DORA pour les acteurs financiers ajoutent des exigences spécifiques sur la résilience opérationnelle et les tests de pénétration réguliers.

Note sur les coûts cachés : les organisations oublient régulièrement d'intégrer dans le budget les coûts de double-running (maintien de l'ancien environnement pendant la période de migration, typiquement 6-12 mois), les adaptations applicatives (recompilation pour des architectures CPU différentes, mise à jour des dépendances logicielles) et les surcoûts de bande passante lors des migrations initiales de données volumineuses (plusieurs To).

Risques majeurs de la migration SecNumCloud

La migration vers un cloud qualifié présente des risques spécifiques qui doivent être anticipés dans le plan de gestion des risques projet :

Lock-in prestataire : les 7 prestataires qualifiés en 2026 représentent un marché oligopolistique. Les offres tarifaires, les SLA et les interfaces de gestion sont moins standardisés que chez les hyperscalers américains. Le risque de dépendance est réel. La doctrine Cloud de l'État 2023 impose des clauses de réversibilité sous 30 jours, mais la portabilité technique effective (migrer 10 To d'objets d'OVHcloud vers Numspot) reste complexe en pratique.

Rupture de service : les basculements de production sont le moment le plus risqué. Un incident technique (mauvaise configuration DNS, certificat TLS expiré, problème de routage réseau) peut générer une interruption de service visible par les utilisateurs. La migration par phases et les tests de non-régression rigoureux sont les meilleures atténuations.

Régression fonctionnelle : certaines fonctionnalités SaaS ou services managés disponibles sur AWS/Azure n'ont pas d'équivalent qualifié. Par exemple, les services de machine learning managés (SageMaker, Azure ML) n'ont pas encore de substitut complet dans les offres qualifiées. Les équipes data doivent migrer vers des architectures auto-hébergées (MLflow, Kubeflow) plus complexes à opérer. Le contexte de l'AI Act 2026 renforce cette contrainte pour les systèmes d'IA à haut risque.

Résistance au changement : les équipes techniques habituées aux outils AWS ou Azure peuvent percevoir la migration comme une régression. L'accompagnement au changement, les formations et la valorisation des nouvelles compétences acquises (souveraineté, conformité) sont des facteurs clés de succès souvent négligés dans les budgets projet.

Comment se préparer à l'EUCS dès aujourd'hui ?

Pour les organisations qui opèrent à l'échelle européenne, se préparer à l'EUCS High (attendu entre 2026 et 2028) est complémentaire à la migration SecNumCloud. Les actions concrètes dès 2026 :

Documenter la classification de vos données selon une taxonomie alignée avec les niveaux Basic/Substantial/High de l'EUCS. Les données relevant du niveau High (informations critiques pour la sécurité nationale, données personnelles sensibles à grande échelle) doivent être identifiées et séparées des données Substantial.

Intégrer dans vos contrats cloud des clauses de portabilité EUCS-compatibles qui anticiperont les exigences de réversibilité que le schéma EUCS imposera aux prestataires certifiés. Cela vous positionnera favorablement lors de la mise en conformité.

Suivre les travaux de l'ENISA et du groupe de travail EUCS de la Commission européenne via les canaux officiels. Les dates d'entrée en vigueur et les modalités de transition (délais de grâce pour les certifications existantes) sont encore en discussion et peuvent impacter significativement votre calendrier de migration.

Exploiter la complémentarité entre ISO 27001:2022 et SecNumCloud/EUCS : une certification ISO 27001 existante couvre en moyenne 60 % des exigences documentaires SecNumCloud, réduisant d'autant les efforts d'accompagnement et d'audit. C'est souvent la première étape recommandée avant d'engager un projet de qualification.

Questions fréquentes

Combien de temps dure réellement une migration SecNumCloud pour une ETI ?

Pour une ETI de 200 à 500 salariés avec un SI classique (ERP, messagerie, applications métier, SI financier), comptez 18 à 24 mois de projet réel. Les phases les plus longues sont l'inventaire (sous-estimé systématiquement), la remédiation des dépendances CLOUD Act (découverte d'outils non inventoriés) et les tests de non-régression en production. Les projets qui affichent des délais de 6-9 mois se limitent généralement à la messagerie et aux outils collaboratifs, en laissant de côté le cœur du SI.

Peut-on migrer partiellement, en conservant certaines applications sur AWS ou Azure ?

Oui, c'est l'approche hybride. Elle consiste à qualifier uniquement le périmètre des données sensibles (SecNumCloud) tout en maintenant les données non-sensibles sur des clouds commerciaux. C'est la stratégie la plus pragmatique pour les OIV qui ne peuvent pas tout migrer en même temps. La contrainte est d'assurer une séparation réseau et logique stricte entre les deux périmètres, et de ne faire transiter aucune donnée sensible par les infrastructure non qualifiées — y compris dans les flux de journalisation ou de monitoring.

L'EUCS va-t-il remplacer SecNumCloud à terme ?

Non, du moins pas dans les 5 prochaines années. SecNumCloud restera le référentiel de référence en France pour les données les plus sensibles, notamment parce qu'il impose l'immunité extraterritoriale que l'EUCS High standard n'impose pas. L'EUCS sera complémentaire pour les organisations qui opèrent en dehors de France et ont besoin d'une certification reconnue dans plusieurs États membres. La posture RSSI externalisé la plus robuste consiste à viser SecNumCloud pour les données critiques françaises et EUCS High pour les données à portée européenne.

Quelles sont les sanctions en cas de non-conformité à la doctrine Cloud de l'État ?

Pour les administrations centrales, le non-respect de la doctrine Cloud de l'État n'entraîne pas de sanction pénale directe, mais expose à des risques d'audit de la Cour des Comptes, à des recommandations de l'ANSSI avec délai de mise en conformité et, en cas d'incident de sécurité, à une responsabilité aggravée des dirigeants. Pour les OIV, le non-respect des exigences NIS 2 peut entraîner des amendes atteignant 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial.