Souveraineté technologique du cloud : juridique vs technique

Vos données sont hébergées dans le cloud, mais où exactement et qui peut y accéder ? Si vous utilisez un fournisseur américain comme AWS, Microsoft Azure ou Google Cloud, vos données — même hébergées en France — peuvent être légalement accessibles aux autorités américaines via le CLOUD Act. Mais le risque va plus loin : la stack technologique elle-même peut être rendue indisponible par décret américain, comme cela a été fait pour Huawei en 2019, ZTE en 2018, ou les universités russes en 2022. Cette page distingue souveraineté juridique et souveraineté technologique, analyse les qualifications SecNumCloud et EUCS, décortique les cas S3NS et Bleu, et défend une position claire : une vraie souveraineté impose de questionner toute la stack, pas seulement le siège social du fournisseur.

Ce que vous allez apprendre

La distinction juridique vs technologique dans la souveraineté cloud
Les lois extraterritoriales (Cloud Act, FISA) et leur impact concret
Ce que garantit (et ne garantit pas) SecNumCloud 3.2
Les cas d’école de coupure technologique (Huawei, ZTE, Russie 2022)
Le débat S3NS (Thales/Google) et Bleu (Microsoft/Capgemini/Orange)
Comment faire un choix éclairé pour vos données sensibles

Prérequis : aucun. Ce guide est accessible à tous ceux qui utilisent ou envisagent d’utiliser des services cloud.

1. Le problème : vos données ne vous appartiennent pas vraiment

L’illusion de la localisation

Beaucoup d’entreprises pensent que stocker leurs données « en France » ou « en Europe » suffit à les protéger. C’est une illusion dangereuse.

Exemple concret : vous êtes une PME française et vous stockez vos données clients sur Microsoft Azure, dans un datacenter situé à Paris. Vous pensez être en sécurité ? En réalité, si les autorités américaines demandent à Microsoft l’accès à vos données, Microsoft est légalement obligé de les fournir — même si elles sont physiquement en France. La raison : Microsoft est une entreprise américaine, soumise au droit américain, et le droit américain a une portée extraterritoriale.

Ce que signifie « extraterritorial »

Une loi extraterritoriale s’applique au-delà des frontières du pays qui l’a adoptée. Concrètement :

Situation	Ce que vous pensez	Ce qui se passe réellement
Données sur AWS Paris	« Mes données sont en France, protégées par le droit français »	Les États-Unis peuvent exiger leur transmission
Contrat avec filiale européenne	« Je contracte avec AWS Europe, pas AWS USA »	La maison mère américaine reste soumise au CLOUD Act
Chiffrement des données	« Mes données sont chiffrées, personne ne peut les lire »	Le fournisseur peut être contraint de fournir les clés

2. Les lois extraterritoriales américaines

Le CLOUD Act (2018)

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act) est la loi la plus connue. Adoptée en mars 2018, elle permet aux autorités américaines (FBI, NSA, DOJ) d’exiger l’accès aux données stockées par des entreprises américaines, quel que soit le pays où ces données sont hébergées.

Ce que dit la loi :

S’applique à toutes les entreprises américaines (AWS, Microsoft, Google, Oracle, Salesforce…).
Concerne les données stockées partout dans le monde.
Permet des demandes via mandat ou citation à comparaître (subpoena).
Prévoit des mécanismes de contestation, mais l’entreprise doit prouver que la demande viole le droit local.

Implications concrètes :

Type de données	Risque
Données clients	Accessibles aux autorités US sans votre consentement
Secrets commerciaux	Potentiellement exposés (espionnage économique)
Données de santé	Violation potentielle du RGPD et du secret médical
Données stratégiques	Risque géopolitique pour les entreprises sensibles

Le FISA Section 702

La section 702 du FISA (Foreign Intelligence Surveillance Act) autorise la NSA à collecter des données sur des citoyens étrangers (non-américains) qui transitent par des infrastructures américaines. Cette loi cible explicitement la surveillance de masse.

Différence avec le CLOUD Act :

Aspect	CLOUD Act	FISA 702
Objectif	Enquêtes criminelles	Renseignement étranger
Cible	Données spécifiques	Surveillance de masse
Transparence	L’entreprise peut contester	Souvent classifié (secret)
Notification	Possible (sous conditions)	Généralement impossible

Autres lois à connaître

Loi	Pays	Portée
PATRIOT Act (2001)	États-Unis	Lutte antiterroriste, accès aux données
National Intelligence Law (2017)	Chine	Oblige les entreprises chinoises à coopérer avec les services de renseignement
UK Investigatory Powers Act (2016)	Royaume-Uni	Pouvoirs de surveillance étendus post-Brexit

3. La distinction critique : souveraineté juridique vs technologique

Deux risques distincts, deux mécanismes différents

C’est le cœur de cette page : la souveraineté ne se réduit pas à la juridiction du fournisseur. Elle inclut aussi la souveraineté technologique de la stack — c’est-à-dire la maîtrise des composants techniques sous-jacents.

Risque	Mécanisme	Vitesse	Recours
Juridique (CLOUD Act, FISA)	Demande légale formelle au fournisseur, accès aux données	Mois à années	Possible (contestation judiciaire)
Technologique (sanctions, Entity List)	Décret OFAC / BIS qui interdit l’export de la technologie vers une entité	Jours à semaines	Quasi nul (décret unilatéral)

Le premier risque donne accès aux données. Le second coupe l’accès au service. Deux mécanismes disjoints, deux protections différentes. La plupart des analyses publiques se focalisent sur le premier et oublient le second — c’est exactement le piège dans lequel sont tombés Huawei et les universités russes.

Mécanismes de coupure technologique américaine

Entity List du Bureau of Industry and Security (BIS) : interdiction d’export des technologies américaines vers une entité listée, avec effet immédiat dès parution au Federal Register.
Sanctions OFAC : blocage des transactions financières et techniques avec une entité ou un pays.
Executive Orders présidentiels : effet immédiat, opposabilité minime devant les tribunaux US, durée variable.
Restrictions sectorielles (semi-conducteurs avancés, cryptographie, IA) : applicables sur produit, pas seulement sur entité, ce qui élargit drastiquement le périmètre.

4. Cinq cas d’école de coupure technologique unilatérale

Ces cas ne sont pas des hypothèses ni du complotisme — ce sont des décisions publiques documentées, prises légalement par des États souverains, dont les conséquences ont été immédiates et massives.

Cas 1 — Huawei perd Android et les Google Mobile Services (mai 2019)

Suite au placement de Huawei sur l’Entity List du BIS le 15 mai 2019, Google a coupé l’accès aux Google Mobile Services (Play Store, Maps, YouTube, Gmail) sur les nouveaux smartphones Huawei en quelques jours. Les modèles vendus en Europe pré-2019 ont continué à recevoir des mises à jour de sécurité limitées, mais aucun nouvel appareil n’a pu utiliser la stack Android complète. Réponse industrielle : développement de HarmonyOS par Huawei, plusieurs années pour atteindre une parité partielle, perte estimée à 30 milliards de dollars de revenus sur 3 ans selon Huawei.

Cas 2 — ZTE banni des composants américains (avril 2018)

Le Department of Commerce US a interdit en avril 2018 toute exportation de composants américains vers ZTE pour 7 ans, suite à une violation des sanctions iraniennes. Effet immédiat : ZTE a arrêté ses chaînes de production en quelques semaines, ses 75 000 employés se sont retrouvés sans travail, l’action en bourse a chuté de 50 %. ZTE n’a été sauvée que par un accord politique direct entre Trump et Xi Jinping, en juillet 2018, contre une amende de 1 milliard de dollars.

Cas 3 — Universités russes coupées d’AWS, GitHub et Slack (mars 2022)

Suite à l’invasion de l’Ukraine, AWS, Microsoft, GitHub, Slack, Docker Hub, Atlassian et beaucoup d’autres ont coupé les comptes des organisations russes sanctionnées en quelques jours. Les universités sanctionnées ont perdu l’accès à leurs dépôts privés GitHub (souvent contenant des années de recherche), à leurs comptes AWS (avec leurs données clientes), et à leurs outils de collaboration. La récupération des données a été partielle, certaines pertes définitives.

Cas 4 — Kaspersky bannie aux États-Unis (juin 2024)

Le Department of Commerce US a interdit en juin 2024 la vente de tous les produits Kaspersky sur le territoire américain, avec obligation de désinstallation pour les utilisateurs existants au 29 septembre 2024. Aucun procès, aucune preuve publique d’acte malveillant — décision purement politique liée à la nationalité russe de l’entreprise. Précédent inquiétant : la nationalité d’un fournisseur peut suffire à le bannir, indépendamment de tout fait technique.

Cas 5 — Restrictions NVIDIA H100 vers la Chine (octobre 2023)

Le Department of Commerce a élargi en octobre 2023 les restrictions d’export sur les GPU IA avancés (NVIDIA H100, A100), bloquant les ventes vers la Chine. Effet immédiat sur les capacités d’entraînement de modèles LLM par les acteurs chinois, contournements partiels par des versions dégradées (H800), évolutions vers des architectures alternatives (Huawei Ascend). Cas important parce qu’il vise un produit (le GPU), pas seulement une entité.

5. SecNumCloud : le référentiel de confiance français

Qu’est-ce que SecNumCloud ?

SecNumCloud est une qualification de cybersécurité délivrée par l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Ce n’est pas un label politique ou commercial : c’est un référentiel technique exigeant qui couvre plus de 360 critères répartis sur 14 thèmes.

Ce que SecNumCloud garantit :

Sécurité technique : architecture, chiffrement, cloisonnement, détection des incidents.
Immunité juridique : le prestataire doit être européen (siège et capital) et conserver un contrôle exclusif sur les données.
Continuité de service : protection contre les scénarios de « kill switch » (coupure imposée par un tiers).
Localisation : données hébergées dans l’Union européenne.

Ce que SecNumCloud ne garantit pas :

L’indépendance technologique totale (dépendances à des composants non-européens possibles, c’est précisément le sujet de cette page).
Une protection absolue contre toutes les menaces.
Un choix politique ou industriel (c’est une qualification technique neutre).

Les exigences clés de SecNumCloud 3.2

Domaine	Exigences principales
Juridique	Siège en UE, capital européen, pas de soumission à des lois extraterritoriales
Données	Hébergement en UE, chiffrement au repos et en transit
Exploitation	Autonomie opérationnelle, pas d’accès pour les fournisseurs tiers
RH	Habilitations, séparation des responsabilités, contrôle des accès
Incidents	Détection, réponse, notification, SOC qualifié
Continuité	Résilience, plans de reprise, indépendance vis-à-vis des fournisseurs

Les fournisseurs qualifiés SecNumCloud (avril 2026)

Fournisseur	Offre qualifiée	Type
Outscale (Dassault Systèmes)	Cloud public IaaS	Cloud souverain français, stack TINA propriétaire FR
OVHcloud	Hosted Private Cloud powered by VMware, Bare Metal Pod, Public Cloud Project	Cloud souverain français
Cloud Temple	Secure Temple + PaaS OpenShift	Cloud souverain français
Worldline	Cloud Services Secured IaaS	Cloud souverain français
Cegedim	Cegedim Cloud (santé HDS + SecNumCloud)	Cloud souverain français
Orange Business	Cloud Avenue	Cloud souverain français
S3NS (Thales/Google)	PREMI3NS	Cloud hybride : techno US, opération FR

En cours de qualification (2026) : Bleu (Orange/Capgemini/Microsoft), Scaleway, NumSpot, Free Pro, SFR Business.

Source : ANSSI - Prestataires qualifiés SecNumCloud.

6. Le cas S3NS — quand Thales certifie Google

En décembre 2025, l’offre PREMI3NS de S3NS a obtenu la qualification SecNumCloud 3.2. Cette décision a fait couler beaucoup d’encre et relancé le débat sur la définition même de la souveraineté numérique.

Qu’est-ce que S3NS ?

S3NS (prononcé « sense ») est une coentreprise créée par Thales et Google Cloud. Thales détient la majorité du capital et opère le service. Google fournit la technologie cloud (Compute Engine, Cloud Storage, BigQuery, GKE).

C’est le premier cloud hybride — combinant technologie américaine et opération française — à recevoir la qualification SecNumCloud.

Les deux visions de la souveraineté

L’affaire S3NS révèle deux conceptions concurrentes de la souveraineté numérique.

Vision juridique
Vision technologique

Souveraineté juridique et opérationnelle

Définition : contrôle des données, immunité aux lois étrangères, autonomie d’exploitation.
Critère clé : qui contrôle les clés de chiffrement et les opérations ?
Partisans : ANSSI, S3NS, Bleu.
Position : un cloud peut utiliser de la technologie étrangère s’il conserve le contrôle exclusif des données.
Limite : ne traite pas le risque de coupure technologique amont.

La réalité : aucune infrastructure cloud, même opérée par un acteur 100 % européen, ne maîtrise l’intégralité de sa chaîne technologique (processeurs Intel/AMD, firmware, composants open source américains). La question n’est pas de l’éliminer totalement mais de gérer la dépendance et de réduire la surface d’exposition.

7. Bleu — le même débat avec Microsoft

Bleu est un projet similaire à S3NS, porté par Orange, Capgemini et Microsoft. L’objectif : proposer les services Microsoft Azure et Microsoft 365 dans un cadre qualifié SecNumCloud.

État d’avancement (avril 2026) : jalon J1 (engagement) validé en novembre 2025. Qualification complète attendue courant 2026.

Le projet Bleu suscite les mêmes débats que S3NS. Pour ses partisans, c’est une avancée qui permettra aux administrations et entreprises françaises d’accéder à des services cloud avancés avec des garanties de sécurité. Pour ses critiques, c’est une « souveraineté de façade » qui perpétue la dépendance technologique aux géants américains. Le cas Bleu est particulièrement sensible parce qu’il porte sur Microsoft 365 — une dépendance opérationnelle quotidienne pour les administrations françaises.

8. Trois piliers d’une souveraineté technologique réelle

Si on accepte que la souveraineté technologique absolue est inatteignable, il reste possible d’améliorer significativement son niveau de souveraineté en s’appuyant sur trois piliers.

Pilier 1 — Stack logicielle libre auditée. Noyau Linux, KVM/QEMU, Kubernetes upstream, OpenStack, PostgreSQL — tous ces composants sont open source, modifiables et redistribuables hors juridiction US. Si Linus Torvalds est blacklisté demain par les US, le développement du noyau Linux continue ailleurs (la majorité des contributions vient déjà d’Europe et d’Asie). Cette propriété de forkabilité est ce qui rend l’open source structurellement plus souverain que les stacks propriétaires.

Pilier 2 — Hébergeur 100 % européen sur stack libre. Outscale (TINA propriétaire mais français), OVHcloud (KVM + OpenStack), Scaleway (KVM + propriétaire), CleverCloud, Cloud Temple. Ces fournisseurs combinent souveraineté juridique (siège UE) et technologique (stack libre auditée). Ils ne sont pas parfaits — ils dépendent du silicium Intel/AMD et de certaines briques propriétaires — mais leur surface d’exposition au risque de coupure est radicalement plus faible qu’une offre Bleu ou S3NS.

Pilier 3 — Souveraineté hardware. Sujet encore ouvert en 2026. Le silicium Intel/AMD/NVIDIA reste américain. RISC-V et architectures alternatives sont des paris long terme (initiative européenne EPI, Sipearl Rhea, Bull SeQuana). La souveraineté logicielle 100 % parfaite avec hardware US dépendant n’existe pas en 2026 — mais c’est un objectif réaliste sur 10-15 ans.

9. Critères pratiques d’évaluation d’un fournisseur dit souverain

Voici les 8 questions à poser systématiquement à un fournisseur cloud qui se présente comme souverain.

Capital social et siège juridique : où est domicilié le fournisseur ? Capital majoritairement européen ?
Hébergement physique : où sont les datacenters ? Tous en UE ? Sous quelle juridiction concrète ?
Code source des composants critiques : la stack est-elle open source auditable (KVM, OpenStack, Kubernetes upstream) ou propriétaire fermée (VMware, Microsoft Azure Stack) ?
Dépendance aux mises à jour amont : si le fournisseur amont (ex. : Microsoft pour Bleu) cesse le support, le service peut-il continuer ? Pendant combien de temps ?
Réversibilité technique : pouvez-vous extraire vos données et les redéployer ailleurs ? Sous quel format ? Avec quel temps de migration ?
Conformité SecNumCloud : le fournisseur est-il qualifié 3.2 ? Pour quel périmètre exact (toutes les régions, ou seulement certaines) ?
Primitives cryptographiques : quelles bibliothèques de chiffrement sont utilisées ? Origine ? Audits ? FIPS 140-2 ou ANSSI CC ?
Licences logicielles : les composants sont-ils sous licences libres (Apache, MIT, GPL) ou propriétaires soumises à révocation ?

Si plusieurs réponses sont gênantes, le fournisseur est dans le quadrant « souveraineté de façade » plutôt que « souveraineté réelle ». Ce n’est pas forcément éliminatoire — pour des données non sensibles, c’est acceptable. Mais c’est un signal à intégrer dans la décision.

10. Choisir son cloud — matrice de décision par sensibilité

Niveau de sensibilité	Exemples	Recommandation
Critique	Défense, renseignement, infrastructure vitale	Cloud souverain qualifié SecNumCloud à stack libre (Outscale, Cloud Temple, OVHcloud Bare Metal)
Sensible	Données de santé HDS, finance bancaire, R&D stratégique	SecNumCloud (Outscale, OVHcloud, Cloud Temple, Cegedim)
Standard	Applications métier, données internes RGPD	Cloud européen (OVH, Scaleway) ou hyperscaler avec garanties contractuelles
Non sensible	Sites web publics, environnements de test	Hyperscaler (AWS, Azure, GCP) acceptable

Comparatif synthétique des options

Critère	Hyperscaler (AWS, Azure, GCP)	Cloud européen libre (OVH, Scaleway)	Cloud SecNumCloud (Outscale, Cloud Temple)	Cloud hybride (S3NS, Bleu)
Richesse fonctionnelle	★★★★★	★★★☆☆	★★★☆☆	★★★★☆
Immunité CLOUD Act	❌	✅	✅	✅
Qualification SecNumCloud	❌	Partielle	✅	✅
Indépendance technologique	❌	Forte	Forte	❌
Coût	Compétitif	Compétitif	Plus élevé	Plus élevé
Écosystème partenaires	Très large	Moyen	Limité	Large (Google/Microsoft)
Risque coupure technologique	Élevé	Faible	Faible	Élevé

11. Mon avis : la souveraineté absolue n’existe pas, la souveraineté améliorée existe

Trois positions tranchées pour conclure cette page, basées sur des audits de migration souveraine que je conduis depuis 5 ans.

Position 1 — Le pire scénario est de croire à la souveraineté contractuelle d’un fournisseur dont la stack peut être désactivée par décret amont. C’est la pire des illusions parce qu’elle donne un faux sentiment de sécurité. Un client qui choisit Bleu ou S3NS « parce que c’est qualifié SecNumCloud » sans avoir lu cette page ne sait pas qu’il dépend opérationnellement d’une décision politique américaine. Ma recommandation : si vous choisissez S3NS ou Bleu, faites-le les yeux ouverts, en assumant le risque résiduel et en planifiant un scénario de coupure (réversibilité, plan de continuité avec stack alternative).

Position 2 — Pour un projet qui exige une vraie souveraineté technologique, Outscale ou OVHcloud restent les choix défensables en 2026. Outscale a sa propre stack TINA (propriétaire mais 100 % française). OVHcloud utilise massivement KVM, OpenStack et Kubernetes upstream — du libre auditable et forkable. Ces deux fournisseurs combinent juridique européenne, technologie majoritairement libre, et qualification SecNumCloud sur les périmètres adaptés. C’est imparfait (silicium US, certaines briques propriétaires), mais c’est incomparablement plus souverain que Bleu ou S3NS sur le plan technologique.

Position 3 — La souveraineté est un curseur, pas un binaire. Aucun fournisseur ne sera jamais 100 % souverain (silicium, firmware, primitives cryptographiques resteront en partie américains pour les 10 prochaines années). La bonne question n’est pas « suis-je souverain à 100 % ? » mais « quel est mon niveau de souveraineté actuel et comment le maintenir au bon niveau pour la sensibilité de mes données ? ». Pour des données non sensibles, AWS reste défendable. Pour des données critiques, exigez une stack libre auditable et une réversibilité documentée.

À retenir

La localisation ne suffit pas : des données hébergées en France chez un fournisseur américain restent accessibles aux autorités US via le CLOUD Act.
La souveraineté juridique (CLOUD Act, FISA) est distincte de la souveraineté technologique (sanctions, Entity List).
SecNumCloud 3.2 garantit la souveraineté juridique et opérationnelle, pas la souveraineté technologique de la stack amont.
Cinq cas d’école documentés prouvent que la coupure technologique unilatérale est un risque réel : Huawei 2019, ZTE 2018, organisations russes 2022, Kaspersky 2024, NVIDIA H100 vers Chine 2023.
S3NS et Bleu résolvent le risque CLOUD Act mais pas le risque technologique amont.
Trois piliers d’une souveraineté technologique réelle : stack libre auditée, hébergeur européen, souveraineté hardware (objectif long terme).
Le défaut 2026 pour un projet souverain : Outscale ou OVHcloud, pas un cloud hybride à techno américaine.

Prochaines étapes

Modèles de déploiement cloud Public, privé, hybride, sovereign, multi-cloud : où vivent vos données.

Egress et data transfer Le différentiel × 10 entre fournisseurs souverains et hyperscalers américains.

IAM : gérer les identités cloud Le pilier opérationnel de la sécurité cloud, indépendant du fournisseur.

Surveillance et détection des menaces Bonnes pratiques ANSSI 2026 et outils CSPM/CNAPP/SIEM open source.