Migrer une plateforme vers un cloud souverain européen : ce qui casse vraiment (SecNumCloud, portabilité, Data Act)

Le sujet a longtemps été traité par la presse comme un débat de politique industrielle. En 2026, il est devenu un backlog. La Commission européenne a attribué en avril 2026 son marché de cloud souverain (jusqu’à 180 M€ sur six ans) à quatre fournisseurs et consortiums incluant OVHcloud, Scaleway et S3NS. AWS a ouvert son European Sovereign Cloud en disponibilité générale en janvier 2026. Le paysage SecNumCloud 3.2 continue de bouger, et les obligations de changement de fournisseur du Data Act (règlement UE 2023/2854, applicables depuis le 12 septembre 2025) donnent enfin un levier contractuel aux équipes techniques.

Reste la partie que personne ne publie : ce qui casse quand on déplace réellement une plateforme. Voici une lecture d’ingénieur.

Cartographie 2026 : trois modèles, trois protections différentes

Il faut cesser de parler de « cloud souverain » au singulier. Trois modèles coexistent, et ils ne protègent pas contre les mêmes risques.

1. Les offres « souveraines » des hyperscalers. Régions dédiées, personnel et support en Europe, chaîne d’exploitation cloisonnée, parfois entité juridique européenne distincte. Elles apportent une parité fonctionnelle quasi complète avec le catalogue d’origine — c’est leur force décisive. Elles n’éliminent pas le débat sur l’exposition au droit extraterritorial du groupe propriétaire : celui-ci se déplace du plan technique vers le plan capitalistique et judiciaire.

2. Les acteurs européens qualifiés SecNumCloud 3.2. Le référentiel de l’ANSSI ne se limite pas à la sécurité technique : il traite le contrôle capitalistique, la localisation des données et des opérations, et la protection contre les injonctions extra-européennes. C’est aujourd’hui le seul dispositif français qui adresse explicitement le risque juridique. Contrepartie : un catalogue de services managés plus resserré, et un rythme de release différent.

3. Les offres sous licence de technologie (Bleu, S3NS, et autres montages du même type). Une entité européenne exploite une pile technologique d’origine américaine, avec ses propres administrateurs, ses propres clés et une gouvernance séparée, en visant la qualification SecNumCloud. Le compromis est explicite : on récupère une partie de l’ergonomie hyperscaler, on accepte un décalage de catalogue et de versions par rapport à l’offre mère, et une dépendance technologique résiduelle.

Ce que vous cherchez	Hyperscaler « sovereign »	SecNumCloud 3.2	Sous licence
Résidence des données	Oui	Oui	Oui
Résidence des opérations (support, admin)	Contractuelle	Auditée	Auditée
Immunité aux injonctions extra-UE	Débattue	Objectif du référentiel	Objectif du référentiel
Parité fonctionnelle	Élevée	Faible à moyenne	Moyenne
Autonomie technologique réelle	Non	Variable	Non

Ajoutez à cela les initiatives d’infrastructure : le projet ApeiroRA porté par Fraunhofer et SAP, communiqué le 3 août 2026, illustre la direction cloud-edge souveraine à base de standards ouverts (Gaia-X, IPCEI-CIS). Utile pour la veille, pas encore un socle de production.

Poser le besoin avant l’outil : matrice de sensibilité

La première erreur des projets « souveraineté » est de choisir un fournisseur avant d’avoir qualifié le besoin. Construisez une matrice à deux axes : sensibilité de la donnée × niveau de souveraineté requis.

Quatre niveaux de souveraineté, croissants et cumulatifs :

1. Résidence : les données ne quittent pas l’UE (RGPD, clauses contractuelles).
2. Contrôle opérationnel : aucun administrateur hors UE ne peut accéder au plan de contrôle ni aux données au repos.
3. Immunité juridique : le fournisseur n’est pas soumis à un droit extra-européen susceptible de le contraindre (cible SecNumCloud).
4. Autonomie technologique : la plateforme reste opérable si l’éditeur d’origine cesse de la fournir (réversibilité effective).

Rattachez chaque domaine fonctionnel à un niveau : données de santé (HDS), données couvertes par NIS2 pour les entités essentielles, secret des affaires, données publiques. Dans la majorité des SI que l’on audite, 10 à 20 % des workloads exigent le niveau 3 ou 4. Migrer le reste « par principe » est une décision de coût, pas de conformité — et elle doit être assumée comme telle. Notez aussi que le schéma européen de certification EUCS reste à ce jour non adopté, et que les travaux sur un label de souveraineté européen sont encore en discussion : n’appuyez pas une roadmap 2026 sur ces référentiels.

L’audit qui fait mal : l’inventaire des non-substituables

C’est ici que les projets dérapent. Le compute et le stockage objet se déplacent ; ce sont les services managés propriétaires qui coûtent cher.

Commencez par un inventaire depuis le code, pas depuis la console :

# Décompte des types de ressources réellement gérés par l'IaC
tofu show -json \
  | jq -r '[.. | objects | select(has("type") and has("mode")) | .type] | .[]' \
  | sort | uniq -c | sort -rn

Puis classez chaque type par difficulté de substitution :

• Substituable à faible coût : compute, stockage objet (S3-compatible), load balancers, PostgreSQL/MySQL managés, Redis/Valkey, DNS.
• Substituable au prix d’une réécriture : IAM propriétaire (rôles, politiques, fédération de type IRSA/Workload Identity), bus d’événements (EventBridge, Pub/Sub), FaaS, files (SQS, Kinesis), step functions.
• Non substituable sans redesign : bases serverless non relationnelles (DynamoDB, Firestore, Cosmos DB), data warehouses colonne (BigQuery, Redshift), plateformes ML managées (Bedrock, Vertex AI), CDN/WAF de périphérie couplés aux applicatifs.

Chiffrez en unités observables, pas en pourcentages : nombre de tables NoSQL dont les access patterns sont incompatibles avec un modèle relationnel, nombre de fonctions et de règles d’événements, nombre de politiques IAM à retraduire, volume de requêtes SQL propriétaires. Une table DynamoDB à clé composite avec deux index secondaires globaux, réécrite en PostgreSQL, c’est un changement de modèle de données, une revue de performance et une campagne de tests — comptez cela en semaines, pas en heures.

Patterns d’architecture portable

L’objectif n’est pas le multi-cloud actif : c’est de faire tenir le coût de sortie en dessous d’un seuil décidé à l’avance.

• Kubernetes comme substrat unique, avec des opérateurs open source pour les briques à état : CloudNativePG pour PostgreSQL, Strimzi pour Kafka, opérateurs Valkey, MinIO ou Ceph pour l’objet en interne. Attention : vous reprenez alors le day-2 (bascules, sauvegardes PITR, upgrades majeurs). C’est un transfert de coût, pas une suppression.
• Stockage objet via API S3, avec une couche client unique et le versioning côté application plutôt que côté fournisseur.
• IaC avec interface neutre : le module expose un contrat métier, l’implémentation varie.

# modules/postgres/variables.tf — contrat stable, backend interchangeable
variable "engine_version" { type = string }
variable "storage_gb"     { type = number }
variable "ha"             { type = bool }
variable "backup_retention_days" { type = number }

# Implémentations : ./impl/ovh-managed, ./impl/cnpg-operator, ./impl/rds
# Le code applicatif ne consomme que module.postgres.dsn_secret_ref

• Observabilité en OpenTelemetry, collector auto-hébergé en sortie, backend interchangeable. C’est le point le plus rentable de tout le chantier : les agents propriétaires sont un verrou silencieux.
• Secrets et identités : external-secrets + OpenBao/Vault, OIDC pour les workloads. Ne modélisez jamais vos autorisations applicatives dans l’IAM du fournisseur.

Trois stratégies de migration, et la question des clés

Lift-and-shift maîtrisé. Pertinent pour les workloads déjà conteneurisés et sans dépendance managée forte. Rapide, mais transporte la dette : prévoyez un lot d’optimisation post-bascule, sinon la facture surprend.

Double exécution avec bascule progressive. L’ancien et le nouvel environnement tournent en parallèle, le trafic bascule par pourcentage ou par tenant. C’est la seule option acceptable pour un service critique, et la plus coûteuse (double run + réplication + trafic inter-cloud). Pour les bases relationnelles, la réplication logique reste l’outil de référence :

-- Source (hyperscaler)
CREATE PUBLICATION mig FOR ALL TABLES;

-- Cible (cloud souverain), après restauration du schéma
CREATE SUBSCRIPTION mig
  CONNECTION 'host=src.example.eu port=5432 dbname=app sslmode=verify-full'
  PUBLICATION mig WITH (copy_data = true, streaming = true);

-- Contrôle du retard avant la fenêtre de bascule
SELECT slot_name, pg_size_pretty(pg_current_wal_lsn() - confirmed_flush_lsn) AS lag
FROM pg_replication_slots;

Découpage sensible / non sensible. Les données de niveau 3-4 partent sur l’offre qualifiée, le reste demeure. Architecture plus complexe (latence inter-cloud, deux plans d’identité, deux chaînes CI/CD) mais souvent le meilleur rapport conformité/coût.

Pour le transfert des volumes objet, validez l’intégrité et le débit avant de planifier la fenêtre :

rclone sync src:bucket dst:bucket \
  --transfers 64 --checkers 128 --s3-chunk-size 64M \
  --checksum --immutable --stats 30s

Sur le chiffrement : BYOK (clés importées dans le KMS du fournisseur) améliore la traçabilité mais laisse le déchiffrement chez lui. HYOK (clés conservées dans un HSM que vous contrôlez, hors du fournisseur) est la seule réponse crédible aux scénarios d’accès non autorisé — au prix d’une perte de compatibilité avec plusieurs services managés, qui ne savent pas opérer sur des données qu’ils ne peuvent pas déchiffrer. Décidez-le tôt : c’est structurant pour l’architecture, pas un paramètre.

Le levier Data Act : ce que vous pouvez exiger maintenant

Le chapitre VI du Data Act est un outil d’ingénierie, pas une déclaration d’intention. Points exploitables immédiatement, y compris auprès de votre fournisseur actuel :

• Préavis de résiliation plafonné (deux mois) et période de transition contractuelle de 30 jours, prolongeable si la migration est techniquement infaisable dans ce délai, dans la limite prévue par le règlement.
• Période de récupération des données d’au moins 30 jours après la fin du contrat.
• Obligation d’information : le fournisseur doit documenter les formats d’export, les interfaces et les actifs exportables. Demandez-la par écrit et confrontez-la à votre inventaire : les écarts constatés sont votre vraie liste de dépendances.
• Équivalence fonctionnelle pour les services de type IaaS, et interfaces ouvertes pour les couches supérieures.
• Suppression des frais de changement de fournisseur : le règlement prévoit une réduction transitoire puis leur interdiction à compter du 12 janvier 2027. Distinguez bien ces frais des tarifs de transfert réseau applicables à l’exploitation courante, qui restent facturables.

Traduction opérationnelle : inscrivez ces clauses dans un avenant, exigez un plan de sortie testé (pas décrit), et faites du test de réversibilité une exigence de recette annuelle.

Économie du projet : modéliser au lieu de comparer des grilles

Les comparaisons de prix à l’unité sont trompeuses. Modélisez le TCO sur 36 mois :

TCO_36 = Σ(compute + stockage + réseau + services managés)
       + migration (j·h × TJM)
       + double_run (mois × coût_mensuel_source)
       + réimplémentation des non-substituables (j·h)
       + run additionnel interne (ETP SRE/DBA × 36 mois)
       + formation + risque (provision % du total)

Les effets systématiquement sous-estimés : la perte du scale-to-zero et du serverless transforme des coûts variables en capacité provisionnée ; la reprise des bases de données par vos opérateurs ajoute du temps SRE ; la perte des engagements de volume ou d’instances réservées casse vos remises acquises. À l’inverse, les fournisseurs européens facturent généralement le trafic sortant de façon beaucoup plus favorable, ce qui change radicalement l’équation des plateformes à fort egress (média, distribution logicielle, API publiques). Relevez vos propres tarifs à la date du chiffrage : c’est le seul chiffre défendable en comité.

Angles morts

• GPU pour l’IA : c’est la contrainte n°1. Disponibilité par région, quotas, absence de marché spot profond, réservations longue durée. Si votre roadmap comporte de l’entraînement, sécurisez la capacité avant de signer.
• Catalogue IA managé : côté souverain, l’offre se concentre sur l’inférence de modèles à poids ouverts. Une plateforme construite sur des API propriétaires (agents, RAG managé, garde-fous intégrés) est à réécrire.
• Écosystème : marketplaces plus étroites, moins d’intégrations SaaS tierces natives, images certifiées d’éditeurs parfois absentes.
• Topologie : nombre de zones de disponibilité et distance entre régions conditionnent votre stratégie de DR. Revalidez RTO/RPO, ne les recopiez pas.
• Compétences : reprendre des opérateurs Kubernetes à état exige un vrai niveau day-2. C’est un plan de recrutement et de formation, pas une ligne de budget.

Grille de décision et feuille de route 90 jours

Décision, dans l’ordre : niveau de souveraineté exigé → contraintes sectorielles → dépendances non substituables → capacité GPU → TCO 36 mois → maturité interne. Si les deux premiers critères imposent le niveau 3 ou 4, le débat sur la parité fonctionnelle est clos : il devient un chantier de réécriture à planifier.

• J0–J15 : matrice de sensibilité, classement des workloads par niveau, exigences réglementaires validées avec le juridique et le RSSI.
• J15–J40 : inventaire IaC des non-substituables, chiffrage en jours-homme, demande formelle d’information de portabilité au fournisseur actuel (Data Act).
• J40–J70 : pilote sur un workload à état, non critique mais représentatif (une API + une base PostgreSQL + du stockage objet). Cible : IaC neutre, OpenTelemetry, secrets externalisés, sauvegardes restaurées sur la cible.
• J70–J90 : bascule du pilote, mesure de p95/p99, coût réel constaté, RTO/RPO testés, et rédaction du plan de sortie réutilisable.

Critères de sortie du pilote : aucune régression de latence supérieure au seuil défini, restauration complète prouvée, écart de coût mensuel expliqué à moins de 10 %, et estimation de l’effort de migration du portefeuille complet avec un intervalle, pas un point.

La souveraineté ne s’achète pas : elle se conçoit, et son prix se mesure en couplage. Les équipes qui réussissent ces migrations en 2026 sont celles qui avaient déjà réduit leur dépendance aux services managés propriétaires pour de bonnes raisons d’ingénierie — testabilité, maîtrise des coûts, reproductibilité des environnements. Le Data Act n’annule pas cette dette technique ; il vous donne le droit de la constater et un calendrier pour la solder. Le bon indicateur à instrumenter dès maintenant n’est donc pas « sommes-nous souverains ? », mais « combien de jours-homme et combien de minutes d’indisponibilité pour changer de fournisseur ? » — et surveiller cette valeur comme n’importe quel SLO.