Souveraineté Cloud : Protéger les Données Sensibles en France et en Europe

1. Introduction : la souveraineté numérique, enjeu stratégique majeur

En 2026, la question de la souveraineté cloud n'est plus un débat théorique réservé aux juristes et aux géopoliticiens : c'est un impératif opérationnel qui conditionne les choix d'infrastructure de milliers d'organisations en France et en Europe. Avec 72 % des données européennes hébergées chez des fournisseurs cloud américains (AWS, Azure, GCP), la dépendance technologique est massive -- et les risques juridiques associés au CLOUD Act et au FISA Section 702 ne cessent de se concrétiser.

L'invalidation du Privacy Shield par la décision Schrems II de la CJUE en juillet 2020 a confirmé ce que les experts sécurité pressentaient : les transferts de données personnelles vers les États-Unis ne peuvent pas être considérés comme sûrs au regard du droit européen, tant que les lois de surveillance américaines permettent un accès sans mandat aux données des non-Américains. Le Data Privacy Framework (DPF) adopté en 2023 pour remplacer le Privacy Shield est déjà contesté devant la CJUE -- un arrêt « Schrems III » est probable avant 2027.

Face à cette réalité, la France et l'Europe ont accéléré la construction d'un cadre réglementaire et industriel pour la souveraineté cloud. Le référentiel SecNumCloud 3.2 de l'ANSSI, le projet européen EUCS (European Union Cybersecurity Certification Scheme for Cloud Services), et l'émergence d'offres « cloud de confiance » (S3NS, Bleu, NumSpot) redessinent le paysage. Ce guide analyse les enjeux, la réglementation, les offres disponibles et les stratégies de migration pour les organisations qui doivent protéger leurs données sensibles.

Point clé : La souveraineté cloud n'est pas une question de nationalisme technologique. C'est une question de maîtrise juridique : qui peut accéder à vos données, sur ordre de quel tribunal, et avez-vous le droit d'en être informé ?

2. Les menaces juridiques extraterritoriales

2.1 CLOUD Act : quand le droit américain s'applique partout

Le Clarifying Lawful Overseas Use of Data Act (CLOUD Act), adopté en mars 2018, est la pierre angulaire du problème de souveraineté. Cette loi permet aux autorités américaines (FBI, DOJ, agences fédérales) d'exiger la production de données détenues par un fournisseur cloud américain, indépendamment de la localisation géographique des données. En clair : si vos données sont hébergées chez AWS dans la région eu-west-3 (Paris), le gouvernement américain peut légalement contraindre Amazon à les transmettre via un mandat ou une assignation.

Les implications sont considérables :

• Extraterritorialité absolue : la localisation des données (France, Allemagne, Japon) est juridiquement sans effet. Seule compte la nationalité du fournisseur cloud.
• Gag orders : les autorités peuvent exiger la confidentialité de la demande d'accès. Le fournisseur cloud ne peut pas informer son client que ses données ont été saisies.
• Périmètre large : couvre les données de contenu (emails, fichiers, bases de données) ET les métadonnées (logs, journaux d'accès, informations de connexion).
• Pas de limite aux données personnelles : couvre également les données commerciales, les secrets industriels, la propriété intellectuelle.

Le CLOUD Act prévoit un mécanisme de contestation (« motion to quash ») que le fournisseur cloud peut invoquer si la demande crée un conflit avec le droit étranger. En pratique, cette protection est largement illusoire : Microsoft a publiquement déclaré n'avoir jamais réussi à bloquer une demande CLOUD Act pour un client non-américain. Le rapport de transparence 2025 de Google indique que 94 % des demandes CLOUD Act sont honorées dans un délai de 30 jours.

2.2 FISA Section 702 : la surveillance de masse des non-Américains

La Section 702 du Foreign Intelligence Surveillance Act est encore plus préoccupante que le CLOUD Act. Renouvelée en avril 2024 jusqu'en 2026, cette loi autorise la NSA à collecter massivement les communications de non-Américains à des fins de renseignement, sans mandat individuel. Les programmes de surveillance PRISM et Upstream opèrent sous cette autorité légale.

Contrairement au CLOUD Act qui nécessite une procédure judiciaire (même expéditive), FISA 702 opère via des directives secrètes émises par la Foreign Intelligence Surveillance Court (FISC), un tribunal secret dont les décisions ne sont pas publiées. Les fournisseurs cloud américains sont légalement contraints de coopérer et n'ont aucun moyen de s'y opposer publiquement.

C'est précisément FISA 702 qui a motivé la décision Schrems II de la CJUE. La Cour a estimé que le niveau de surveillance autorisé par cette loi était incompatible avec les droits fondamentaux garantis par la Charte européenne (articles 7 et 8 : respect de la vie privée et protection des données personnelles). Le chiffrement des données, même avec des clés gérées par le client, ne constitue pas une garantie suffisante : les autorités américaines peuvent exiger les clés de déchiffrement ou contraindre le fournisseur à implémenter des backdoors.

2.3 Schrems II et le Data Privacy Framework

L'arrêt Schrems II (CJUE, 16 juillet 2020, C-311/18) a invalidé le Privacy Shield et imposé aux organisations européennes de vérifier, au cas par cas, que le pays destinataire offre un niveau de protection « essentiellement équivalent » au droit européen avant tout transfert de données personnelles. Pour les États-Unis, la Cour a conclu que cette équivalence n'existait pas, en raison de FISA 702.

Le Data Privacy Framework (DPF), adopté par la Commission européenne en juillet 2023, tente de résoudre ce problème en s'appuyant sur un décret présidentiel américain (Executive Order 14086) qui encadre l'accès aux données européennes par les agences de renseignement. Cependant, un décret présidentiel peut être révoqué par le président suivant -- il n'a pas la force contraignante d'une loi. L'association noyb de Max Schrems a déjà déposé un recours devant la CJUE, et de nombreux juristes considèrent un arrêt « Schrems III » comme inévitable.

3. Cadre réglementaire européen et français

3.1 SecNumCloud 3.2 : le référentiel souverain de l'ANSSI

Le référentiel SecNumCloud, publié par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information), est le standard français pour la qualification des fournisseurs de services cloud. La version 3.2, publiée en mars 2022 et applicable depuis 2023, introduit des exigences qui vont bien au-delà de la sécurité technique pour adresser directement la souveraineté juridique.

Les exigences clés de SecNumCloud 3.2 :

• Immunité au droit extra-européen : le fournisseur cloud et sa chaîne capitalistique doivent être immunisés contre toute loi extra-européenne permettant l'accès aux données (CLOUD Act, FISA). Concrètement, le capital et le contrôle opérationnel doivent être détenus à plus de 39 % par des entités européennes -- un seuil qui bloque toute filiale américaine.
• Localisation des données en UE : toutes les données (contenu, métadonnées, logs, clés de chiffrement) doivent être stockées et traitées exclusivement dans l'Union européenne.
• Opération depuis l'UE : l'administration et la supervision du service doivent être effectuées depuis le territoire européen, par des personnes habilitées de nationalité européenne.
• Sécurité technique : isolation des tenants, chiffrement au repos et en transit, journalisation exhaustive, cloisonnement réseau, gestion des vulnérabilités, PCA/PRA.
• Audit et transparence : audits PASSI réguliers, rapports de transparence sur les demandes gouvernementales, notification des incidents.

En 2026, seuls quatre fournisseurs disposent de la qualification SecNumCloud : OVHcloud (Private Cloud, Bare Metal), Outscale (filiale Dassault Systèmes), Cloud Temple, et Oodrive (stockage). Les offres « cloud de confiance » comme S3NS (Thales + Google) et Bleu (Cap Gemini/Orange + Microsoft) visent cette qualification mais ne l'ont pas encore obtenue à ce jour.

3.2 EUCS : vers un schéma de certification européen

Le projet EUCS (European Union Cybersecurity Certification Scheme for Cloud Services), porté par l'ENISA, vise à créer un schéma de certification cloud harmonisé pour toute l'Union européenne. Le schéma prévoit trois niveaux : Basic, Substantial et High.

Le débat central autour de l'EUCS concerne le niveau High et les exigences de souveraineté. La France, soutenue par l'Italie et l'Espagne, pousse pour inclure des exigences d'immunité au droit extra-européen similaires à SecNumCloud 3.2. L'Allemagne, les Pays-Bas et les pays nordiques s'y opposent, arguant que cela exclurait les hyperscalers américains et créerait un protectionnisme technologique. En 2026, le compromis n'est toujours pas trouvé -- le niveau High de l'EUCS pourrait inclure une exigence de « localisation et contrôle européens » sans aller jusqu'au critère capitalistique de SecNumCloud.

3.3 HDS, NIS 2 et DORA : exigences sectorielles

Au-delà de SecNumCloud, plusieurs réglementations sectorielles imposent des contraintes spécifiques sur l'hébergement cloud :

Réglementation	Secteur	Exigences cloud	Statut 2026
HDS (Hébergeur de Données de Santé)	Santé	Certification HDS obligatoire, hébergement en France, auditabilité	Applicable, révision en cours
NIS 2	Entités essentielles et importantes	Gestion des risques supply chain cloud, notification incidents 24h	Transposition en cours
DORA	Secteur financier	Registre des prestataires ICT, tests de résilience, stratégie multi-cloud	Applicable depuis jan. 2025
RGPD	Toutes organisations	TIA obligatoire pour transferts hors UE, mesures supplémentaires	Applicable, sanctions renforcées
LPM / IGI 1300	Défense, OIV	Cloud qualifié SecNumCloud obligatoire pour données Diffusion Restreinte	Applicable

La doctrine « Cloud au centre » de l'État français (circulaire du Premier ministre, 2021, actualisée en 2023) impose l'utilisation de cloud qualifié SecNumCloud pour les données de sensibilité « diffusion restreinte » et supérieure. Les administrations et les opérateurs d'importance vitale (OIV) sont les premiers concernés, mais la tendance s'étend progressivement au secteur privé via NIS 2 et les attentes des donneurs d'ordre publics.

4. Les offres cloud souveraines en France

4.1 Panorama des fournisseurs qualifiés SecNumCloud

L'écosystème des fournisseurs cloud qualifiés SecNumCloud s'est significativement étoffé entre 2023 et 2026. Le marché se structure autour de deux modèles : les acteurs indépendants français et les partenariats technologiques sous licence (hyperscalers américains opérés par des entités européennes).

Fournisseur	Modèle	SecNumCloud	Services clés	Points forts
OVHcloud	Indépendant français	3.2 (Hosted Private Cloud)	IaaS, PaaS, Bare Metal, S3	Souveraineté capitalistique totale, datacenters FR
Outscale (Dassault)	Indépendant français	3.2	IaaS (API compatible AWS)	Compatibilité API AWS, qualification historique
S3NS (Thales + Google)	Partenariat sous licence	3.2 (en cours)	GCP sous contrôle Thales	Richesse fonctionnelle GCP, contrôle français des clés
Bleu (Orange + Capgemini + Microsoft)	Partenariat sous licence	3.2 (en cours)	Azure + M365 souverains	Écosystème Microsoft, opéré par entité française
NumSpot (Docaposte, Dassault, Bouygues)	Consortium français	3.2 (en cours)	IaaS/PaaS open source	Stack OpenStack, 100% capitaux français
Cloud Temple	Indépendant français	3.2	IaaS, hébergement qualifié	Spécialisé secteur public et santé

4.2 Le modèle « cloud de confiance » : S3NS et Bleu

Le modèle de « cloud de confiance » est un compromis français original : utiliser la technologie des hyperscalers américains (Google Cloud, Microsoft Azure) tout en garantissant l'immunité au droit extra-européen. Le principe repose sur :

• Licence technologique : le code source est licencié à une entité française qui opère le service de manière indépendante.
• Gouvernance française : l'entité opératrice est de droit français, à capitaux majoritairement français, avec un conseil d'administration ne comportant aucun ressortissant soumis à une législation extra-européenne.
• Isolation physique et logique : les datacenters sont en France, les données ne quittent jamais le territoire, les clés de chiffrement sont contrôlées par l'opérateur français (Thales pour S3NS, Orange/Capgemini pour Bleu).
• Pas d'accès à distance : aucun accès technique depuis les États-Unis ou tout pays tiers aux données hébergées.

4.3 Les offres open source : NumSpot et alternatives

L'approche alternative privilégie un stack 100% open source pour éliminer toute dépendance à un éditeur américain. NumSpot, consortium réunissant Docaposte, Dassault Systèmes et Bouygues Telecom, s'appuie sur OpenStack, Kubernetes et des briques open source pour proposer un cloud IaaS/PaaS souverain. Cette approche offre une transparence totale du code et une indépendance technologique réelle, au prix d'un catalogue de services plus limité que les hyperscalers et d'un effort d'intégration plus important pour les clients.

5. Architecture technique d'un hébergement souverain

5.1 Classification des données et stratégie de placement

La première étape d'une démarche de souveraineté cloud est la classification des données. Toutes les données n'ont pas le même niveau de sensibilité et ne nécessitent pas le même niveau de protection. Une matrice de classification à quatre niveaux est recommandée :

Niveau	Exemples	Cloud autorisé	Chiffrement
Public (C0)	Site web, documentation publique	Tout cloud, CDN global	En transit (TLS)
Interne (C1)	Données métier courantes, emails	Cloud UE (RGPD compliant)	Au repos + en transit
Confidentiel (C2)	Données personnelles, financières, RH	Cloud qualifié (SecNumCloud / HDS)	CMK + HSM sous contrôle client
Restreint (C3)	Secret défense, données DR, OIV	SecNumCloud obligatoire, cloud privé	HSM on-prem, Confidential Computing

Cette classification permet une approche hybride pragmatique : les données C0-C1 peuvent être hébergées sur des hyperscalers (avec les régions européennes), les données C2 sur des clouds qualifiés SecNumCloud ou de confiance, et les données C3 sur des infrastructures souveraines dédiées. L'objectif est d'éviter le piège du « tout souverain » qui surenchérit les coûts sans bénéfice proportionné, tout en protégeant adéquatement les données réellement sensibles.

5.2 Chiffrement et gestion des clés souveraine

Le contrôle des clés de chiffrement est le pilier technique de la souveraineté cloud. Sans contrôle des clés, le chiffrement n'offre aucune protection contre un fournisseur contraint de coopérer avec une autorité étrangère. Trois modèles sont possibles :

• Provider-Managed Keys (PMK) : le fournisseur cloud gère les clés. Aucune souveraineté -- le provider peut déchiffrer à tout moment. Acceptable uniquement pour les données C0.
• Customer-Managed Keys (CMK) : le client apporte ses propres clés dans le KMS du cloud (BYOK). Le client contrôle la rotation et la révocation, mais le provider a accès à la clé en mémoire lors du déchiffrement.
• Hold Your Own Key (HYOK) / External KMS : la clé ne quitte jamais le HSM du client. Le cloud effectue les appels de chiffrement/déchiffrement vers le KMS externe. Souveraineté maximale mais impact performance et compatibilité limitée avec certains services managés.

# Architecture HYOK avec Thales CipherTrust Manager
# Le HSM Thales contrôle les clés, le cloud ne les voit jamais

# 1. Configuration CipherTrust Manager (on-prem ou cloud souverain)
ciphertrust_manager:
  hsm_partition: "souverain-prod"
  key_policy:
    exportable: false          # Clé non-exportable
    rotation_period: "90d"
    allowed_operations:
      - encrypt
      - decrypt
      - wrap
      - unwrap

# 2. Intégration avec le cloud via External Key Manager
# Pour GCP (Cloud EKM) :
gcloud kms ekm-connections create sovereign-ekm \
  --location=europe-west9 \
  --service-directory-service="projects/my-proj/locations/europe-west9/namespaces/ekm/services/ciphertrust" \
  --hostname="ciphertrust.sovereign.example.fr" \
  --server-certificates-pem-file=ciphertrust-cert.pem

# 3. Création d'une clé externe
gcloud kms keys create sovereign-key \
  --keyring=sovereign-ring \
  --location=europe-west9 \
  --purpose=encryption \
  --protection-level=external \
  --external-key-uri="ciphertrust://keyid/sovereign-prod-aes256"

5.3 Réseau et localisation des données

La localisation des données est une exigence réglementaire pour certaines catégories (santé HDS, données Diffusion Restreinte) et une bonne pratique de souveraineté pour toutes les données sensibles. Au-delà du stockage, la localisation concerne également le transit réseau : les données ne doivent pas transiter par des infrastructures hors UE, même temporairement.

• Résidence des données : choisir des régions cloud françaises (Paris, Marseille) ou européennes. Configurer les data residency controls (GCP Organization Policy, Azure Policy, AWS SCP) pour interdire le déploiement de ressources hors régions autorisées.
• Backbone réseau : vérifier que le backbone du fournisseur ne fait pas transiter les données par des points de présence hors UE. Les interconnexions privées (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) offrent un contrôle du chemin réseau.
• DNS souverain : utiliser des résolveurs DNS européens pour éviter les fuites de métadonnées vers des serveurs DNS américains.

6. Migration vers un cloud souverain

6.1 Évaluation et cartographie préalable

La migration vers un cloud souverain commence par un inventaire exhaustif des workloads et données existants. Pour chaque application, il faut évaluer :

• Sensibilité des données : classification C0 à C3 selon la matrice définie.
• Dépendances techniques : services managés utilisés (bases de données, IA/ML, serverless), APIs propriétaires, intégrations tierces.
• Contraintes réglementaires : obligation HDS, LPM, RGPD, NIS 2, DORA selon le secteur.
• Criticité métier : impact en cas d'indisponibilité, RTO/RPO requis.
• Coût de migration : effort de refactoring, tests, formation des équipes.

Cette évaluation permet de construire une matrice de décision qui identifie les workloads candidats à la migration souveraine (données C2-C3, contraintes réglementaires fortes) et ceux qui peuvent rester sur des clouds non qualifiés (données C0-C1, applications non critiques).

6.2 Stratégies de migration

Quatre stratégies de migration sont envisageables, en fonction de la complexité et des dépendances de chaque workload :

6.3 Éviter le vendor lock-in

La souveraineté implique la réversibilité : la capacité de changer de fournisseur cloud sans perte de données ni interruption majeure. Pour minimiser le vendor lock-in :

• Conteneurisation : empaqueter les applications dans des conteneurs Docker/OCI, orchestrés par Kubernetes. Kubernetes est disponible sur tous les clouds et fournisseurs souverains.
• APIs ouvertes : privilégier les APIs S3-compatible pour le stockage objet, PostgreSQL/MySQL pour les bases de données, plutôt que les services propriétaires (DynamoDB, Cosmos DB).
• Infrastructure as Code : utiliser Terraform/OpenTofu avec des modules abstraits qui encapsulent les différences entre fournisseurs.
• Formats ouverts : stocker les données dans des formats ouverts (Parquet, Avro, JSON) plutôt que des formats propriétaires.
• Clause de réversibilité contractuelle : exiger du fournisseur un plan de réversibilité documenté avec un SLA d'assistance à la migration sortante.

7. Cas d'usage sectoriels

7.1 Santé : HDS et données de santé

Le secteur de la santé est le plus avancé en matière d'exigences de souveraineté cloud en France. La certification HDS (Hébergeur de Données de Santé) est obligatoire pour tout hébergement de données de santé à caractère personnel. En 2026, la convergence entre HDS et SecNumCloud se précise : l'ANSSI travaille à un référentiel unifié qui intègrerait les exigences HDS dans le périmètre SecNumCloud, simplifiant la conformité pour les établissements de santé.

Les cas d'usage critiques incluent le Health Data Hub (entrepôt national de données de santé), qui a été contraint de migrer depuis Microsoft Azure vers une infrastructure souveraine suite à une décision du Conseil d'État. Les hôpitaux et les GHT (Groupements Hospitaliers de Territoire) migrent progressivement vers des clouds HDS+SecNumCloud pour le dossier patient informatisé (DPI), l'imagerie médicale et les entrepôts de données cliniques.

7.2 Secteur financier : DORA et résilience

Le règlement DORA, applicable depuis janvier 2025, impose aux entités financières une gestion rigoureuse des prestataires ICT cloud. Les banques et assurances françaises sont tenues de maintenir un registre d'information détaillé de leurs prestataires cloud, d'évaluer les risques de concentration (dépendance excessive à un seul provider) et de disposer d'une stratégie de sortie documentée pour chaque prestataire critique. La tendance est à la diversification multi-cloud avec au moins un fournisseur souverain qualifié pour les workloads les plus sensibles (systèmes de paiement, données KYC, reporting réglementaire).

7.3 Secteur public et défense

Le secteur public français est le principal moteur de la demande de cloud souverain. La doctrine « Cloud au centre » impose l'utilisation de cloud qualifié SecNumCloud pour toutes les données de sensibilité « diffusion restreinte » et supérieure. Les ministères, les collectivités territoriales et les établissements publics migrent progressivement vers des offres souveraines, avec une priorité donnée aux applications de gestion RH, financière et aux systèmes d'information critiques.

Pour la défense et les OIV, les exigences sont encore plus strictes : cloud privé dédié, homologation spécifique, personnel habilité, infrastructure physiquement isolée. Le ministère des Armées développe son propre cloud de défense, tandis que les OIV s'appuient sur des offres SecNumCloud renforcées par des mesures de sécurité physique et organisationnelle supplémentaires.

8. Perspectives et recommandations

8.1 Tendances 2026-2028

Plusieurs tendances structurantes se dessinent pour les années à venir :

• IA souveraine : l'entraînement et l'inférence de modèles d'IA sur des données sensibles deviennent un cas d'usage majeur pour le cloud souverain. Les offres GPU souveraines (OVHcloud AI, NumSpot) se développent pour répondre à cette demande.
• Edge souverain : la souveraineté s'étend au edge computing, avec des micro-datacenters qualifiés déployés au plus près des utilisateurs (hôpitaux, usines, bases militaires).
• Certification EUCS : l'adoption du schéma européen, même avec un compromis sur le niveau High, harmonisera les exigences et facilitera le marché unique du cloud sécurisé.
• Consolidation du marché : le nombre de fournisseurs souverains se réduira par consolidation, avec l'émergence de 3 à 5 champions européens capables de rivaliser en fonctionnalités avec les hyperscalers.

8.2 Recommandations pratiques

9. Conclusion

La souveraineté cloud n'est ni un fantasme protectionniste ni un luxe réservé aux administrations. C'est une nécessité stratégique pour toute organisation manipulant des données sensibles dans un contexte géopolitique où l'extraterritorialité juridique américaine constitue un risque documenté et croissant. Le cadre réglementaire français et européen (SecNumCloud, EUCS, NIS 2, DORA) fournit des repères clairs, et l'écosystème des offres souveraines a atteint en 2026 un niveau de maturité suffisant pour répondre à la majorité des cas d'usage.

L'approche pragmatique recommandée est le cloud hybride à géométrie variable : héberger les données selon leur classification, en utilisant le cloud souverain qualifié pour les données sensibles et les hyperscalers (avec des mesures de protection appropriées) pour les workloads non critiques. Cette stratégie optimise le rapport protection/coût tout en préparant l'organisation à l'évolution inéluctable vers un renforcement des exigences de souveraineté. Dans un monde où les données sont le nouvel actif stratégique, leur protection juridique et technique est un investissement, pas une contrainte.