Souveraineté numérique : critères, certifications et arsenal réglementaire européen

RÉSUMÉ EXÉCUTIF (lecture 5 minutes)

Thèse centrale

La souveraineté numérique ne se décrète pas : elle se construit par l'accumulation de critères techniques, juridiques et industriels dont l'articulation détermine le degré réel d'autonomie d'un État ou d'une zone économique. L'Europe a développé deux approches complémentaires mais distinctes : une approche "dure" fondée sur des certifications techniques exigeantes (SecNumCloud en France), et une approche "souple" reposant sur un arsenal réglementaire contraignant pour les acteurs étrangers (RGPD, DMA, DSA, AI Act, NIS2). Ces deux voies présentent des forces et des limites qu'il convient d'analyser sans complaisance.

Les sept piliers de la souveraineté numérique

La souveraineté numérique effective repose sur sept critères cumulatifs :

SecNumCloud : l'approche par la certification

SecNumCloud, référentiel de l'ANSSI, constitue la tentative française la plus aboutie de définir des critères techniques de souveraineté cloud. La version 3.2 (2022) a introduit des exigences d'immunité aux lois extraterritoriales qui excluent de facto les hyperscalers américains dans leur configuration standard.

Chiffres clés SecNumCloud (janvier 2026) :

Le package réglementaire européen : réguler sans produire

L'Union européenne a développé un arsenal réglementaire impressionnant visant à encadrer les acteurs numériques :

Limites structurelles : Ce package réglemente des acteurs étrangers sans créer d'alternatives européennes. Il impose des contraintes aux GAFAM tout en maintenant la dépendance structurelle à leurs services.

Le paradoxe français

La France dispose du référentiel de souveraineté cloud le plus exigeant d'Europe (SecNumCloud 3.2), mais son administration reste massivement dépendante des solutions américaines. Microsoft détient plus de 80% du marché des postes de travail de la fonction publique. Le "cloud de confiance" progresse (qualification S3NS fin 2025), mais reste un chantier plus qu'un acquis.

Diagnostic

La souveraineté numérique européenne oscille entre deux écueils : une certification trop exigeante qui exclut les solutions performantes (SecNumCloud pur), et une régulation qui encadre sans autonomiser (package réglementaire). La voie médiane des offres hybrides (S3NS désormais qualifié, BLEU en cours) tente de concilier performance américaine et immunité juridique européenne, au prix de compromis dont la solidité à long terme reste à observer.

Position éditoriale : le risque que personne ne nomme

Au-delà des risques juridiques (Cloud Act, FISA), le risque stratégique majeur concerne le code dormant. Stuxnet (2010) a prouvé que des États peuvent insérer des cyberarmes dans des systèmes informatiques. Les révélations Snowden ont documenté les programmes NSA (BULLRUN, QUANTUM, TAO) visant à compromettre les produits commerciaux. L'affaire Crypto AG a démontré que cette pratique a duré des décennies.

Implication : les systèmes Windows, Azure et autres produits américains peuvent contenir des vulnérabilités exploitables en cas de crise. Ce n'est pas de la paranoïa : c'est du réalisme géopolitique.

Cas d'usage chiffré : la preuve par l'exemple

Une migration type "Région administrative" (4 200 agents, 3 800 postes) vers des solutions souveraines présente ce bilan :

Conclusion : le souverain n'est pas plus cher, il est différemment réparti dans le temps.

Projection budgétaire 10 ans : l'investissement rentable

Pour l'ensemble de l'État français (5,5 millions d'agents) :

La souveraineté numérique n'est pas un coût mais un investissement rentable à moyen terme.

Projection budgétaire : le prix de la souveraineté

Une modélisation économique sur 10 ans (2026-2035) pour l'administration française permet de chiffrer le coût de la transition :

Le scénario B (hybride) apparaît comme le meilleur compromis : surcoût maîtrisé de 460 M EUR/an (20% du budget SI), trajectoire progressive, réduction significative des risques de dépendance, contribution à l'écosystème européen.

Introduction : qu'est-ce que la souveraineté numérique ?

Une notion aux contours flous

La souveraineté numérique est une expression omniprésente dans le discours politique contemporain, mais dont le contenu précis reste souvent indéterminé. Elle peut désigner, selon les contextes : la capacité d'un État à contrôler les données de ses citoyens, l'indépendance technologique vis-à-vis de fournisseurs étrangers, la protection contre l'espionnage et les lois extraterritoriales, ou encore l'existence d'un écosystème industriel national dans le numérique.

Cette polysémie n'est pas innocente. Elle permet aux acteurs politiques d'invoquer la souveraineté numérique sans s'engager sur des critères précis, et aux acteurs économiques de revendiquer une conformité à géométrie variable. Un hyperscaler américain peut se prétendre "souverain" parce qu'il stocke des données en France, tandis qu'un acteur français peut revendiquer ce label simplement parce que son siège social est à Paris.

Souveraineté formelle et souveraineté effective

L'analyse doit distinguer la souveraineté formelle (l'apparence juridique du contrôle) de la souveraineté effective (la capacité réelle à exercer ce contrôle en situation de crise).

Une entreprise française utilisant AWS avec des serveurs localisés en France dispose d'une souveraineté formelle sur ses données : elles sont physiquement sur le territoire national. Mais cette souveraineté est effective seulement tant que les relations franco-américaines restent stables. En cas de sanctions américaines, de conflit commercial, ou simplement de demande d'accès au titre du Cloud Act, cette souveraineté formelle s'évapore.

La souveraineté effective suppose de pouvoir maintenir le contrôle y compris dans des scénarios adverses : sanctions économiques, conflits géopolitiques, pressions juridiques, cyberattaques. C'est ce critère de résilience en situation dégradée qui différencie les approches cosmétiques des approches substantielles.

Le trilemme de la souveraineté numérique

Les organisations confrontées à la question de la souveraineté numérique font face à un trilemme entre trois objectifs difficilement conciliables :

Performance : les hyperscalers américains (AWS, Azure, GCP) offrent des services techniquement supérieurs, avec une couverture mondiale, une richesse fonctionnelle et une fiabilité que les acteurs européens peinent à égaler.

Souveraineté : l'indépendance vis-à-vis des juridictions étrangères et des technologies propriétaires suppose de renoncer aux solutions les plus performantes.

Coût : les solutions souveraines européennes sont généralement plus coûteuses que leurs équivalentes américaines, du fait d'économies d'échelle moindres et d'un écosystème moins mature.

Maximiser deux de ces critères implique généralement de sacrifier le troisième. Les offres hybrides type S3NS ou BLEU tentent de résoudre ce trilemme, avec des résultats qui commencent à être évaluables depuis la qualification de S3NS fin 2025.

Partie I : Les sept critères de la souveraineté numérique

1.1 Critère 1 : Localisation des données

Le premier critère, le plus visible et le plus souvent invoqué, concerne la localisation physique des données. Il repose sur l'idée que des données stockées sur le territoire national sont soumises au droit national et échappent aux juridictions étrangères.

Ce que garantit la localisation :

Ce que la localisation ne garantit pas :

La localisation est une condition nécessaire mais très insuffisante de la souveraineté. Un data center Amazon en France reste soumis au Cloud Act américain. La localisation sans maîtrise de l'opérateur est un leurre juridique.

1.2 Critère 2 : Immunité aux lois extraterritoriales

Ce critère vise à garantir que les données ne peuvent être réquisitionnées par une autorité étrangère sans passer par les voies de la coopération judiciaire internationale (traités d'entraide, commissions rogatoires).

Les principales menaces extraterritoriales :

Le Cloud Act américain (2018) permet aux autorités américaines d'exiger l'accès aux données détenues par des entreprises américaines, quel que soit le lieu de stockage. Il concerne toute entreprise "soumise à la juridiction des États-Unis", ce qui inclut les filiales européennes des groupes américains.

La section 702 du FISA (Foreign Intelligence Surveillance Act) autorise la surveillance des communications de personnes non-américaines situées hors des États-Unis, via les infrastructures des entreprises américaines.

L'Executive Order 12333 permet la collecte de renseignements sur les communications étrangères transitant par des infrastructures américaines, sans contrôle judiciaire.

Comment atteindre l'immunité :

SecNumCloud 3.2 a introduit des exigences spécifiques sur ce point, rendant la qualification impossible pour les filiales européennes des hyperscalers américains agissant en propre.

1.3 Critère 3 : Contrôle opérationnel

Le contrôle opérationnel désigne la maîtrise effective des opérations d'administration, de maintenance et de sécurité des infrastructures. Il ne suffit pas que les serveurs soient en France : encore faut-il que les personnes qui les administrent soient soumises au droit français et agissent dans l'intérêt du client.

Dimensions du contrôle opérationnel :

Risques d'un contrôle opérationnel défaillant :

Les offres hybrides (S3NS, BLEU) reposent sur une séparation entre la technologie (américaine) et l'opération (française). La qualification de S3NS par l'ANSSI en décembre 2025 valide en principe cette architecture, mais des questions de long terme demeurent : que se passe-t-il si Google décidait de ne pas renouveler la licence technologique de Thales dans un contexte géopolitique dégradé ?

1.4 Critère 4 : Maîtrise technologique

La maîtrise technologique désigne la capacité à comprendre, modifier, auditer et, le cas échéant, remplacer les composants techniques de l'infrastructure. Elle s'oppose à la dépendance à des "boîtes noires" dont le fonctionnement interne est opaque.

Niveaux de maîtrise technologique :

La souveraineté technique complète (niveau 4) est rarement atteignable : elle supposerait de maîtriser l'intégralité de la pile technologique, du silicium au logiciel applicatif. Une approche réaliste vise un niveau 2-3 sur les composants critiques et accepte la dépendance sur les composants non critiques.

Composants critiques nécessitant une maîtrise :

1.5 Critère 5 : Sécurité certifiée

La certification par une autorité nationale compétente atteste du respect d'exigences de sécurité vérifiées par des audits indépendants. En France, l'ANSSI (Agence nationale de la sécurité des systèmes d'information) délivre les qualifications de référence.

Niveaux de certification ANSSI pour le cloud :

La certification n'est pas une garantie absolue de sécurité : elle atteste de la conformité à un référentiel à un instant donné. Elle doit être complétée par une surveillance continue et des audits réguliers.

1.6 Critère 6 : Réversibilité

La réversibilité désigne la capacité à migrer ses données et applications vers un autre fournisseur sans perte, sans dégradation, et dans des délais raisonnables. Elle conditionne l'exercice effectif de la souveraineté : un client prisonnier de son fournisseur n'est pas souverain, même si ce fournisseur est national.

Dimensions de la réversibilité :

Le Data Act européen (applicable depuis le 12 septembre 2025) introduit des obligations de portabilité pour les fournisseurs cloud, mais leur effectivité à grande échelle reste à démontrer face aux stratégies de lock-in des hyperscalers.

1.7 Critère 7 : Transparence et auditabilité

La transparence désigne la capacité du client à vérifier ce que fait réellement le fournisseur : où sont les données, qui y accède, quels traitements sont effectués, quelles mesures de sécurité sont en place.

Niveaux de transparence :

SecNumCloud exige un niveau "auditable" minimum, avec possibilité pour l'ANSSI de conduire des inspections. Les hyperscalers américains proposent généralement un niveau "documenté" avec des rapports SOC 2 et des certifications ISO, mais sans accès au code source ni possibilité d'audit technique approfondi.

Partie II : SecNumCloud - l'approche française par la certification

2.1 Genèse et évolution du référentiel

SecNumCloud est le référentiel de sécurité de l'ANSSI pour les prestataires de services d'informatique en nuage. Créé en 2016, il a connu plusieurs évolutions majeures reflétant la prise de conscience progressive des enjeux de souveraineté.

Chronologie :

La version 3.2, actuellement en vigueur, marque une rupture conceptuelle. Elle ne se contente plus de vérifier la sécurité technique des infrastructures : elle impose des critères de souveraineté juridique et opérationnelle qui rendent la qualification impossible pour les hyperscalers américains opérant en propre.

2.2 Architecture du référentiel SecNumCloud 3.2

Le référentiel SecNumCloud 3.2 s'organise en plusieurs domaines d'exigences :

Exigences techniques (environ 500 points de contrôle) :

Exigences organisationnelles (environ 200 points de contrôle) :

Exigences de souveraineté (environ 100 points de contrôle, version 3.2) :

2.3 Les exigences de souveraineté en détail

La version 3.2 de SecNumCloud introduit des exigences dites "de souveraineté" qui vont au-delà de la sécurité technique.

Exigence de nationalité du prestataire : Le prestataire doit avoir son siège social dans un État membre de l'Union européenne. Son capital et ses droits de vote doivent être détenus directement et indirectement à plus de 50% par des entités européennes. La direction effective doit être assurée depuis l'Europe.

Exigence d'immunité aux lois extraterritoriales : Le prestataire ne doit pas être soumis à des législations non-européennes susceptibles d'imposer la communication de données hébergées. Concrètement, cela exclut :

Exigence de localisation : Les données doivent être stockées et traitées exclusivement sur le territoire de l'Union européenne. Aucune donnée, même technique ou de supervision, ne doit transiter par des infrastructures situées hors de l'UE.

Exigence de contrôle opérationnel : L'administration, la supervision et la maintenance doivent être réalisées depuis l'Europe par du personnel soumis au droit européen. Le support technique de niveau 3 (expertise approfondie) ne peut être externalisé hors UE.

2.4 Prestataires qualifiés SecNumCloud (janvier 2026)

Au 20 janvier 2026, 22 prestataires disposent d'une qualification SecNumCloud, pour un total de 30 services qualifiés.

Évolution majeure fin 2025 : La qualification de S3NS (Thales/Google) le 17 décembre 2025 marque un tournant. C'est la première offre hybride utilisant une technologie hyperscaler à obtenir le visa SecNumCloud, validant le modèle de séparation technologie/opération.

Liste des prestataires qualifiés (extrait) :

Statut des offres hybrides :

Absents structurels :

2.5 Les offres hybrides : S3NS et BLEU

Face à l'impossibilité pour les hyperscalers de se qualifier directement, des montages juridiques hybrides ont été conçus pour tenter de concilier technologies américaines et souveraineté française.

S3NS (Thales + Google Cloud) - Qualifié SecNumCloud :

BLEU (Capgemini + Orange + Microsoft) :

Questions résiduelles sur le modèle hybride :

La qualification de S3NS valide le modèle juridique et opérationnel à un instant T, mais des interrogations de long terme subsistent :

2.6 Les angles morts de SecNumCloud : OS, dépendances et SaaS

SecNumCloud, malgré ses ambitions et sa rigueur sur le périmètre qu'il couvre, présente des angles morts structurels qui limitent sa capacité à garantir une souveraineté et une résilience complètes. Ces lacunes concernent principalement les couches basses (OS, firmware) et les couches hautes (SaaS, applications) de la pile technologique.

#### 2.6.1 Angle mort n°1 : la couche système d'exploitation

SecNumCloud certifie l'infrastructure cloud (IaaS, PaaS) mais ne traite pas la question des systèmes d'exploitation qui tournent sur cette infrastructure. Or, la quasi-totalité des workloads déployés sur des clouds SecNumCloud utilisent des OS d'origine américaine :

Précisions sur la nature des risques :

Il convient de distinguer plusieurs types de risques souvent amalgamés :

Le point clé : une organisation peut héberger ses données sur un cloud OVH qualifié SecNumCloud, mais si ces données sont traitées par un Windows Server, elle reste exposée à des risques de continuité (licences, support) et à une opacité technique (code non auditable).

#### 2.6.2 Angle mort n°2 : les dépendances de l'écosystème

SecNumCloud se concentre sur l'opérateur cloud mais n'audite pas exhaustivement les dépendances de l'écosystème technique.

Dépendances matérielles :

Dépendances logicielles courantes :

Nuance importante sur l'open source :

Il faut distinguer :

Un cloud SecNumCloud utilisant Kubernetes n'est pas "dépendant des USA" de la même manière qu'un cloud utilisant VMware. L'open source change fondamentalement la nature du risque : la continuité est possible, même si elle a un coût.

#### 2.6.3 Angle mort n°3 : la couche SaaS

C'est sur la couche SaaS que l'angle mort est le plus significatif. Le référentiel a été conçu pour l'IaaS et le PaaS, mais la majorité des usages quotidiens repose sur du SaaS :

Le constat : une administration française peut héberger ses bases de données sur un cloud SecNumCloud tout en faisant transiter l'intégralité de ses communications et documents par Microsoft 365, hors de tout périmètre souverain.

#### 2.6.4 Le problème des licences en cas de crise

Scénario de stress : en cas de crise géopolitique majeure impliquant des sanctions américaines contre des entités européennes, plusieurs ruptures sont envisageables :

Calibration du risque : ces scénarios sont théoriquement possibles mais supposent une escalade géopolitique majeure (comparable aux sanctions contre la Russie). Ils ne doivent pas être présentés comme des menaces imminentes, mais comme des risques de queue à intégrer dans une stratégie de résilience.

#### 2.6.5 Synthèse des limites de SecNumCloud

2.7 Proposition de cadre complémentaire : le modèle EJCI

Face aux angles morts de SecNumCloud, des réflexions émergent dans la communauté de la souveraineté numérique sur un cadre complémentaire plus exigeant que nous désignons ici sous l'acronyme EJCI (European Jurisdiction Controlled Infrastructure).

Avertissement méthodologique : le "label EJCI" présenté ci-après n'est pas un référentiel officiel existant. Il s'agit d'une proposition conceptuelle synthétisant les exigences maximales de souveraineté identifiées par différents analystes et rapports parlementaires. Ce modèle est présenté à titre d'outil de réflexion pour illustrer ce que serait une souveraineté numérique "dure", et non comme une certification en voie d'institutionnalisation.

#### 2.7.1 Philosophie du modèle EJCI (proposition)

Là où SecNumCloud se concentre sur l'opérateur cloud et ses pratiques de sécurité, le modèle EJCI théorique adopte une approche par l'immunité juridique complète de l'ensemble de la chaîne technologique.

Principe fondamental proposé : "Une infrastructure EJCI garantit une soumission exclusive au droit de l'Union européenne et un contrôle effectif exercé par des entités européennes, à l'exclusion de toute influence juridique, technique ou opérationnelle extra-européenne."

La différence conceptuelle est fondamentale : SecNumCloud certifie des opérateurs, EJCI qualifierait des chaînes de contrôle complètes.

#### 2.7.2 Critères proposés pour un niveau EJCI

Critère 1 : Juridiction exclusive (calque strict)

Critère 2 : Contrôle opérationnel total

Critère 3 : Indépendance technologique (apport majeur vs SecNumCloud)

Implications si ce modèle existait :

#### 2.7.3 Comparaison avec les cadres existants

#### 2.7.4 Pourquoi EJCI reste une proposition théorique

Un tel référentiel n'existe pas institutionnellement pour plusieurs raisons :

#### 2.7.5 Articulation réaliste SecNumCloud / niveau supérieur

Une approche pragmatique distinguerait deux niveaux :

Niveau 1 : SecNumCloud (opérationnel aujourd'hui)

Niveau 2 : Exigences renforcées (à construire)

L'enjeu n'est pas de créer un label EJCI immédiatement, mais de développer progressivement l'offre permettant d'y satisfaire : distributions Linux européennes certifiées, forks maintenus des projets critiques, alternatives SaaS souveraines.

2.8 Doctrine de l'État français sur l'usage du cloud

La circulaire du Premier ministre du 17 juillet 2021 (dite "doctrine cloud au centre") définit les règles d'utilisation du cloud par les administrations françaises.

Trois niveaux de sensibilité :

Application pratique (état janvier 2026) : La doctrine reste partiellement appliquée. L'arrivée de S3NS qualifié fin 2025 élargit l'offre pour le niveau "sensible" avec une solution combinant fonctionnalités Google Cloud et certification ANSSI. Cependant, de nombreuses administrations continuent d'utiliser Microsoft 365 pour leurs outils collaboratifs, le passage à une alternative souveraine restant un chantier de plusieurs années.

Partie III : Le package réglementaire européen - la souveraineté par la norme

3.1 Vue d'ensemble de l'arsenal réglementaire

L'Union européenne a développé depuis 2016 un arsenal réglementaire sans équivalent visant à encadrer l'économie numérique. Contrairement à l'approche par la certification (qui crée des labels de confiance), l'approche réglementaire impose des contraintes à tous les acteurs opérant sur le marché européen, qu'ils soient européens ou non.

Les textes structurants (état janvier 2026) :

3.2 RGPD : le modèle fondateur

Le Règlement général sur la protection des données (RGPD), applicable depuis mai 2018, constitue le texte fondateur de l'approche réglementaire européenne au numérique. Son influence a largement dépassé les frontières de l'UE, inspirant des législations similaires dans de nombreux pays ("effet Bruxelles").

Principes clés :

Droits des personnes :

Sanctions : Le RGPD prévoit des amendes pouvant atteindre 4% du chiffre d'affaires mondial annuel ou 20 millions d'euros. Ces montants théoriques se sont traduits par des sanctions effectives significatives :

Limites du RGPD comme outil de souveraineté : Le RGPD protège les données personnelles mais ne crée pas de préférence pour les acteurs européens. Il impose des contraintes aux GAFAM tout en leur permettant de continuer à opérer en Europe. L'arrêt Schrems II (2020) a certes invalidé le Privacy Shield et compliqué les transferts vers les USA, mais le nouveau Data Privacy Framework (2023) a rouvert les flux de données transatlantiques.

3.3 DMA : réguler les gatekeepers

Le Digital Markets Act (DMA), applicable depuis 2023, cible spécifiquement les grandes plateformes numériques qualifiées de "contrôleurs d'accès" (gatekeepers). Son objectif est de garantir la contestabilité des marchés numériques et l'équité des relations entre plateformes et utilisateurs professionnels.

Critères de désignation des gatekeepers :

Gatekeepers désignés (septembre 2023) :

Obligations imposées aux gatekeepers :

Interopérabilité : permettre aux tiers de fonctionner avec les services de la plateforme (messagerie interopérable, app stores alternatifs).

Non-favoritisme : ne pas favoriser ses propres services dans les classements (Google Shopping dans Google Search, apps Apple préinstallées).

Portabilité : permettre aux utilisateurs de récupérer leurs données et de les transférer.

Accès aux données : fournir aux utilisateurs professionnels l'accès aux données générées par leur activité sur la plateforme.

Non-coupling : ne pas imposer l'utilisation d'un service comme condition d'accès à un autre.

Sanctions : jusqu'à 10% du CA mondial, 20% en cas de récidive, voire démantèlement structurel.

Portée et limites : Le DMA représente la tentative la plus ambitieuse de réguler les plateformes numériques. Les premiers cas d'application font l'objet de bras de fer avec la Commission (Apple et les app stores, Google et le choix du moteur de recherche). Le DMA contraint les pratiques mais ne crée pas d'alternatives européennes aux services régulés.

3.4 DSA : la responsabilité des plateformes

Le Digital Services Act (DSA) modernise le régime de responsabilité des intermédiaires numériques hérité de la directive e-commerce de 2000. Il introduit des obligations de diligence graduées selon la taille et la nature des plateformes.

Catégories de plateformes et obligations :

Obligations spécifiques aux VLOP/VLOSE :

Plateformes désignées VLOP (2024) : Alibaba AliExpress, Amazon Store, Apple App Store, Booking.com, Facebook, Google Play, Google Maps, Google Shopping, Instagram, LinkedIn, Pinterest, Snapchat, TikTok, X (Twitter), Wikipedia, YouTube, Zalando, Bing, Google Search.

3.5 AI Act : encadrer l'intelligence artificielle

L'AI Act (Règlement UE 2024/1689), adopté en 2024, constitue le premier cadre réglementaire horizontal sur l'intelligence artificielle au niveau mondial. Il adopte une approche par les risques, avec des obligations graduées selon la dangerosité potentielle des systèmes.

Calendrier d'application (progressif) :

Note : Des discussions sont en cours sur d'éventuels ajustements de ce calendrier pour certaines catégories de systèmes.

Pyramide des risques :

Obligations pour les systèmes à haut risque :

Obligations pour les modèles de fondation (GPAI) :

L'AI Act introduit des règles spécifiques pour les "General Purpose AI" (modèles de fondation type GPT, Claude, Gemini) :

Portée et limites : L'AI Act crée des barrières à l'entrée sur le marché européen pour les systèmes d'IA non conformes. Il ne crée cependant pas de préférence pour les systèmes européens et pourrait même avantager les grands acteurs capables d'absorber les coûts de conformité face aux startups européennes.

3.6 NIS2 et DORA : la résilience des infrastructures critiques

La directive NIS2 (Network and Information Security) et le règlement DORA (Digital Operational Resilience Act) visent à renforcer la cybersécurité et la résilience des secteurs critiques.

NIS2 - Périmètre élargi (applicable depuis octobre 2024) :

NIS2 étend considérablement le périmètre de la directive NIS originale de 2016 :

Obligations NIS2 :

DORA - Focus secteur financier (applicable depuis le 17 janvier 2025) :

DORA impose des exigences spécifiques aux entités financières (banques, assurances, gestionnaires d'actifs, plateformes de trading) :

Impact sur la souveraineté : NIS2 et DORA imposent une réflexion sur les dépendances technologiques. La gestion des risques liés aux tiers inclut l'évaluation des risques géopolitiques et juridiques associés aux fournisseurs. Un établissement financier utilisant AWS doit désormais documenter les risques liés au Cloud Act et aux sanctions potentielles.

3.7 Data Act : l'accès aux données industrielles

Le Data Act, applicable depuis le 12 septembre 2025, vise à faciliter le partage des données générées par les objets connectés et les services numériques. Il crée un droit d'accès aux données au profit des utilisateurs et des tiers.

Principales dispositions :

Accès aux données des objets connectés : l'utilisateur d'un appareil connecté (voiture, machine industrielle, appareil ménager) a le droit d'accéder aux données générées par cet appareil et de les transférer à un tiers.

Portabilité des services cloud : les fournisseurs de cloud doivent permettre la migration vers un autre fournisseur, fournir des outils d'export, et ne pas facturer de frais de sortie excessifs. Les frais de switching doivent être progressivement éliminés d'ici 2027.

Accès des autorités publiques : en cas de besoin exceptionnel (urgence publique), les autorités peuvent demander l'accès à des données détenues par des entreprises.

Protection contre les clauses contractuelles abusives : les clauses imposant un partage de données déséquilibré aux PME peuvent être déclarées nulles.

Portée pour la souveraineté : Le Data Act renforce la réversibilité (critère 6 de la souveraineté) en limitant les stratégies de lock-in des fournisseurs cloud. Il ne traite cependant pas les questions d'immunité juridique ou de maîtrise technologique.

3.8 EUCS : vers un SecNumCloud européen ?

Le schéma européen de certification de cybersécurité pour les services cloud (EUCS - EU Cybersecurity Certification Scheme for Cloud Services) est un projet en cours de négociation visant à créer un cadre harmonisé de certification au niveau européen.

Niveaux envisagés :

Le débat sur les critères de souveraineté :

Le projet EUCS fait l'objet d'un débat majeur entre États membres sur l'inclusion de critères de souveraineté similaires à SecNumCloud 3.2. La France pousse pour inclure des exigences d'immunité aux lois extraterritoriales au niveau élevé. D'autres États (Pays-Bas, pays nordiques) s'y opposent, craignant d'exclure les hyperscalers américains.

État actuel (janvier 2026) : Le projet EUCS reste bloqué sur cette question. Les versions successives ont oscillé entre inclusion et exclusion des critères de souveraineté. Un compromis possible serait de créer un niveau "élevé+" optionnel incluant ces critères, laissant aux États membres le choix de l'exiger pour leurs administrations.

Partie IV : Analyse comparative - certification vs régulation

4.1 Deux philosophies de la souveraineté

L'approche française (SecNumCloud) et l'approche européenne (package réglementaire) incarnent deux philosophies distinctes de la souveraineté numérique.

L'approche par la certification (SecNumCloud) :

L'approche par la régulation (package UE) :

4.2 Forces et faiblesses comparées

4.3 Complémentarité ou contradiction ?

Les deux approches peuvent être vues comme complémentaires ou contradictoires selon l'angle adopté.

Lecture complémentaire : La régulation européenne crée un socle minimum applicable à tous. La certification française ajoute une couche d'exigences pour les usages les plus sensibles. Une entreprise peut utiliser des services conformes au RGPD et au DSA pour ses usages courants, et réserver SecNumCloud pour ses données critiques.

Lecture contradictoire : L'approche réglementaire européenne légitime de facto la présence des hyperscalers sur le marché européen, dès lors qu'ils se conforment aux règles. Elle affaiblit l'argument en faveur d'alternatives souveraines : pourquoi payer plus cher et accepter moins de fonctionnalités si les GAFAM sont "régulés" et donc acceptables ?

Le risque du pire des deux mondes : Le danger est d'aboutir à une situation où la régulation européenne impose des coûts de conformité aux acteurs européens sans avantage compétitif, tandis que les hyperscalers absorbent ces coûts et maintiennent leur domination. La souveraineté resterait alors un discours sans traduction opérationnelle.

4.4 La question des offres hybrides : leçons de la qualification S3NS

La qualification de S3NS par l'ANSSI en décembre 2025 constitue un test décisif pour l'évaluation des offres hybrides combinant technologie américaine et opération souveraine.

Ce que valide la qualification S3NS :

Ce que la qualification ne résout pas :

Implications pour BLEU : La qualification de S3NS crée un précédent favorable pour BLEU (architecture similaire avec Microsoft), sous réserve que les critères techniques et opérationnels soient satisfaits.

Partie V : Perspectives et recommandations

5.1 Diagnostic d'ensemble (janvier 2026)

La souveraineté numérique européenne présente un bilan en amélioration mais encore contrasté.

Acquis :

Manques persistants :

5.2 Hiérarchie des priorités

Une stratégie de souveraineté numérique cohérente devrait hiérarchiser les efforts selon l'impact et la faisabilité.

Priorité 1 : Accélérer la migration vers le cloud souverain (court terme)

Priorité 2 : Renforcer l'écosystème souverain (moyen terme)

Priorité 3 : Harmoniser au niveau européen (moyen terme)

Priorité 4 : Réduire les dépendances technologiques profondes (long terme)

5.3 Le cas des offres hybrides : doctrine proposée

La qualification de S3NS appelle à clarifier la doctrine sur les offres hybrides.

Position recommandée : acceptation conditionnelle avec transparence

- "Cloud souverain pur" (stack 100% européen) - "Cloud souverain hybride" (opération européenne, technologie sous licence)

5.4 Indicateurs de suivi

Mesurer les progrès de la souveraineté numérique suppose de définir des indicateurs objectifs.

Indicateurs d'offre :

Indicateurs d'usage :

Indicateurs de résilience :

Partie VI : Projection budgétaire de la transition souveraine sur 10 ans

Cette partie propose une modélisation économique de la transition vers la souveraineté numérique pour l'administration française, avec trois scénarios chiffrés sur la période 2026-2035. L'objectif est de passer du discours aux ordres de grandeur, condition préalable à toute décision éclairée.

6.1 Périmètre et hypothèses de modélisation

Périmètre retenu : l'État central et ses opérateurs

L'analyse porte sur l'ensemble des ministères, agences et opérateurs de l'État, soit environ :

Hypothèses structurantes

Les couches considérées

La modélisation distingue quatre couches technologiques, chacune avec ses propres dynamics de coût et de dépendance :

6.2 Les trois scénarios de transition

#### Scénario A : Statu quo optimisé (référence)

Maintien de la trajectoire actuelle avec optimisations marginales :

Coûts annuels (base 2026) :

#### Scénario B : Transition hybride (recommandé)

Bascule progressive vers les offres hybrides qualifiées et développement parallèle de l'écosystème souverain :

Phase 1 (2026-2028) : Migration cloud sensible

Phase 2 (2029-2031) : Élargissement

Phase 3 (2032-2035) : Consolidation

#### Scénario C : Souveraineté maximale

Remplacement systématique de toutes les solutions américaines :

6.3 Projection des coûts par scénario

#### Coûts cumulés sur 10 ans (2026-2035)

Synthèse des coûts totaux sur 10 ans :

6.4 Trajectoire annuelle et cash-flows

Analyse de la trajectoire :

Le scénario B (hybride) présente un pic de coûts entre 2028 et 2030, correspondant à la phase d'investissement intensive (migrations, formations, développements). Les coûts redescendent ensuite progressivement à mesure que les économies de licences se matérialisent et que les compétences se consolident.

Le scénario C (souverain max) montre un pic plus élevé (2029-2030) et une décrue plus lente, reflétant la complexité accrue des migrations et le besoin de développements spécifiques pour combler les gaps fonctionnels.

Point de croisement économique :

Le scénario B devient plus économique que le scénario A à partir de 2033 en coûts annuels, grâce aux économies de licences. Sur l'ensemble de la période, le surcoût cumulé de 4,6 Md EUR correspond à un "investissement de souveraineté" de 460 M EUR/an, soit environ 20% du budget actuel.

6.5 Décomposition par couche technologique

#### Couche IaaS (Infrastructure cloud)

Justification des écarts : Les offres souveraines (S3NS, OVH, Scaleway) présentent un surcoût de 15-35% par rapport aux hyperscalers US pour des services IaaS comparables. Ce surcoût se réduit progressivement avec la montée en charge et les économies d'échelle.

#### Couche PaaS (Services managés)

Point d'attention : La couche PaaS est celle où l'écart fonctionnel avec les hyperscalers est le plus marqué. Les services managés AWS/Azure (Kubernetes managé, bases de données serverless, services d'IA) n'ont pas d'équivalent souverain à parité fonctionnelle. Le scénario C implique des développements compensatoires significatifs.

#### Couche SaaS (Applications métier)

Économie nette licences : Le scénario C économise 7,2 Md EUR de licences Microsoft mais requiert 2,8 Md EUR d'investissement dans les alternatives (Collabora, OnlyOffice, solutions développées). L'économie nette de 4,4 Md EUR est partiellement absorbée par les coûts de migration et d'accompagnement.

#### Couche OS et postes de travail

Risque majeur : La migration vers Linux des postes de travail génère des coûts induits de requalification des applications métier non compatibles. Le scénario C chiffre ce risque à 1,8 Md EUR, hypothèse qui pourrait être dépassée si de nombreuses applications legacy s'avèrent non portables.

6.6 Analyse coût-bénéfice ajustée du risque

La comparaison brute des coûts ne capture pas la valeur de la souveraineté. Une analyse ajustée du risque doit intégrer le coût potentiel de scénarios adverses.

Scénarios de risque considérés :

Note méthodologique : Les probabilités sont des estimations subjectives calibrées sur l'évolution du contexte géopolitique 2020-2025. Le lecteur est invité à ajuster selon sa propre appréciation du risque.

Coût total ajusté du risque :

Interprétation : Le surcoût "réel" du scénario B par rapport au scénario A, ajusté du risque, est de 3,65 Md EUR sur 10 ans (365 M EUR/an), soit 20% du budget annuel SI de l'État. Ce montant peut être considéré comme une "prime d'assurance souveraineté".

6.7 Analyse de sensibilité

Les projections sont sensibles à plusieurs paramètres dont l'évolution est incertaine.

Paramètres les plus sensibles :

6.8 Recommandation économique

Au terme de cette analyse, le scénario B (transition hybride) apparaît comme le meilleur compromis coût-souveraineté-faisabilité :

Arguments économiques :

Arguments opérationnels :

Arguments stratégiques :

Ce que le scénario B ne résout pas :

6.9 Synthèse : le prix de la souveraineté

Le prix de la souveraineté numérique :

Ces ordres de grandeur permettent de situer le débat sur la souveraineté numérique dans sa réalité économique. Le surcoût n'est ni négligeable ni prohibitif. Il correspond à un choix politique assumé dont les bénéfices (autonomie, résilience, développement industriel) ne sont pas tous monétisables mais n'en sont pas moins réels.

Partie VI : Position éditoriale : Pour une souveraineté numérique assumée

Cette partie expose une position éditoriale engagée. Contrairement aux sections précédentes qui visaient l'analyse factuelle, celle-ci assume un point de vue normatif sur les choix stratégiques que la France et l'Europe devraient opérer.

6.1 Le risque systémique que personne ne veut nommer : le code dormant

L'analyse des risques liés aux technologies américaines se concentre généralement sur les aspects juridiques (Cloud Act, FISA) et commerciaux (dépendance aux licences, lock-in). Ces risques sont réels mais ne constituent pas la menace la plus grave. Le risque systémique majeur, rarement évoqué dans le débat public français, concerne la capacité d'États étrangers à insérer du code dormant dans les systèmes informatiques qu'ils fournissent.

Stuxnet : la preuve de concept

En 2010, le ver informatique Stuxnet a détruit environ 1 000 centrifugeuses du programme nucléaire iranien. Cette cyberarme, attribuée aux États-Unis et à Israël par de nombreuses sources (dont le New York Times en 2012), a démontré plusieurs capacités :

Stuxnet n'était pas un virus classique : c'était une arme de sabotage stratégique dissimulée dans du code informatique. Son existence prouve que les grandes puissances disposent de la capacité technique et de la volonté politique d'utiliser les infrastructures numériques comme vecteurs d'attaque.

Les programmes de la NSA révélés par Snowden

Les documents révélés par Edward Snowden en 2013 ont mis en lumière des programmes de la NSA visant spécifiquement à compromettre les équipements informatiques :

Ces révélations documentées établissent que la NSA a activement travaillé à compromettre les produits informatiques commerciaux, y compris ceux destinés à des alliés. L'Allemagne a découvert que le téléphone d'Angela Merkel était surveillé par la NSA. La France a été ciblée par des opérations de renseignement économique documentées.

Le précédent Crypto AG

En 2020, une enquête du Washington Post et de la ZDF a révélé que Crypto AG, entreprise suisse de chiffrement utilisée par plus de 120 pays pendant des décennies, était secrètement contrôlée par la CIA et le BND allemand. Les machines de chiffrement vendues à des gouvernements étrangers contenaient des backdoors permettant aux services américains et allemands de déchiffrer les communications censées être sécurisées.

Cette affaire démontre que l'insertion de vulnérabilités dans des équipements commerciaux n'est pas une hypothèse théorique mais une pratique documentée sur plusieurs décennies.

Implications pour Windows, Azure et les produits Microsoft

Dans ce contexte, quelle confiance accorder à des systèmes d'exploitation et services cloud fournis par des entreprises américaines soumises à la juridiction des États-Unis ?

La question ne porte pas sur la probité des entreprises elles-mêmes, mais sur les contraintes légales auxquelles elles sont soumises :

Un dirigeant de Microsoft, Google ou Amazon n'a pas le choix légal de refuser une demande de la NSA accompagnée des contraintes légales appropriées. Il ne peut même pas révéler l'existence de cette demande. Le code source de Windows, Azure ou AWS peut contenir des modifications imposées par les services de renseignement américains sans que l'entreprise puisse en informer ses clients.

Le scénario que personne ne veut envisager

Imaginons un scénario de crise majeure entre les États-Unis et un pays européen, ou une divergence stratégique profonde (par exemple sur la politique envers la Chine, la Russie, ou le Moyen-Orient). Les États-Unis disposeraient potentiellement de la capacité de :

Ce scénario n'est pas de la science-fiction : c'est exactement ce que Stuxnet a réalisé contre l'Iran. La seule question est de savoir si les États-Unis utiliseraient de telles capacités contre des alliés. L'histoire de Crypto AG et la surveillance de Merkel suggèrent que l'alliance n'est pas une protection absolue.

6.2 La position de SensPo.fr : assumer le choix de la souveraineté

Face à ces risques, la position de SensPo.fr est claire : la souveraineté numérique n'est pas une option mais une nécessité stratégique.

Ce que nous défendons :

Ce que nous refusons :

6.3 Le code dormant : un risque à prendre au sérieux

Pour conclure cette section, il convient d'être explicite sur la nature du risque :

Nous ne disposons pas de preuves que Windows, Azure ou d'autres produits américains contiennent actuellement du code dormant exploitable contre les intérêts européens.

Mais nous savons avec certitude que :

Dans ce contexte, le principe de précaution stratégique commande de réduire la dépendance aux technologies américaines pour les fonctions critiques de l'État et des infrastructures essentielles. Ce n'est pas de l'anti-américanisme : c'est du réalisme géopolitique.

Les États-Unis eux-mêmes n'accepteraient jamais que leurs infrastructures critiques fonctionnent sur des technologies chinoises ou russes. Ils ont interdit Huawei et TikTok pour des risques bien moins documentés que ceux associés aux technologies américaines du point de vue européen. L'Europe devrait appliquer le même raisonnement, avec la même fermeté.

Partie VII : Cas d'usage chiffré : la migration de la Région Bourgogne-Franche-Comté

Ce cas d'usage est un scénario illustratif construit à partir de données publiques sur les coûts des services cloud et les effectifs des administrations régionales. Il vise à donner des ordres de grandeur réalistes, non des chiffres exacts.

7.1 Contexte de départ (situation 2024)

La Région Bourgogne-Franche-Comté emploie environ 4 200 agents (services centraux + lycées) et gère un système d'information comprenant :

Infrastructure existante :

Coûts annuels avant migration :

Dépendances identifiées :

7.2 Décision de migration (2025)

Suite à la doctrine cloud de l'État et aux recommandations de l'ANSSI, la Région décide d'engager une migration vers des solutions souveraines sur 4 ans.

Objectifs fixés :

Architecture cible retenue :

7.3 Coûts de la migration (période 2025-2028)

Année 1 (2025) : Préparation et pilote

Année 2 (2026) : Migration principale

Année 3 (2027) : Finalisation

Année 4 (2028) : Régime nominal

7.4 Bilan économique sur 5 ans

Analyse économique :

Conclusion économique : La migration vers des solutions souveraines atteint l'équilibre économique sur 5 ans et génère ensuite des économies significatives (plus de 1 M EUR/an). Le surcoût est concentré sur l'année 2 (pic de migration).

7.5 Bilan qualitatif

Gains obtenus :

Difficultés rencontrées :

Éléments non chiffrés mais significatifs :

7.6 Enseignements transposables

Ce cas illustre plusieurs réalités de la migration souveraine :

Partie VIII : Projection budgétaire : coûts de transition sur 10 ans pour l'État français

Cette projection vise à estimer les ordres de grandeur d'une migration complète de l'État français vers des solutions souveraines. Les chiffres sont des estimations basées sur les données disponibles et doivent être considérés comme indicatifs.

8.1 Périmètre et hypothèses

Périmètre considéré :

Hypothèses de calcul :

8.2 Scénario A : Statu quo (maintien dépendance Microsoft)

Coûts projetés sur 10 ans :

Risques non chiffrés :

8.3 Scénario B : Migration souveraine progressive

Hypothèses de migration :

Coûts détaillés :

Tableau de synthèse par grande catégorie :

8.4 Comparaison des scénarios

Analyse comparative :

8.5 Détail des investissements par domaine

8.5.1 Développement d'alternatives SaaS (3,5 Md EUR sur 10 ans)

8.5.2 Contribution aux projets open source (1,7 Md EUR)

8.5.3 Formation (4,8 Md EUR)

8.6 Retour sur investissement

Économies structurelles post-migration (année 11 et suivantes) :

Bénéfices non monétaires :

8.7 Conditions de réussite

Conditions politiques :

Conditions industrielles :

Conditions techniques :

Conditions humaines :

8.8 Synthèse : le vrai coût de la souveraineté

Le message clé :

La souveraineté numérique n'est pas un luxe ruineux mais un investissement rentable à moyen terme. Sur 10 ans, la migration complète coûte moins cher que le maintien de la dépendance Microsoft (28,5 Md vs 31 Md EUR). Elle génère ensuite des économies récurrentes de près de 2 milliards d'euros par an.

Le véritable obstacle n'est pas financier mais politique : accepter un surcoût transitoire, maintenir l'effort sur plusieurs mandatures, résister aux pressions des acteurs installés.

La question n'est pas "peut-on se permettre la souveraineté numérique ?" mais "peut-on se permettre de ne pas l'avoir ?". Au regard des risques stratégiques (code dormant, Cloud Act, dépendance totale), la réponse devrait être évidente.

Partie IX : Comparaison internationale des stratégies de souveraineté numérique

La France n'est pas seule à affronter la question de la dépendance numérique. L'analyse des stratégies adoptées par d'autres pays permet de situer l'approche française, d'identifier les bonnes pratiques et de mesurer les écarts de maturité.

9.1 Allemagne : le Sovereign Workplace et ses contradictions

L'Allemagne a développé une approche ambitieuse mais heurtée de la souveraineté numérique, révélatrice des tensions entre discours politique et réalités industrielles.

Le projet Sovereign Workplace (2021-2025)

Lancé par le ministère fédéral de l'Intérieur, le projet "Souveräner Arbeitsplatz" visait à créer une alternative open source à Microsoft 365 pour l'administration fédérale. Basé sur Nextcloud, LibreOffice et Matrix, il devait équiper 300 000 postes d'ici 2025.

Analyse des blocages :

Le cloud : Delos et la controverse

L'Allemagne a opté pour un modèle similaire à S3NS avec Delos (SAP + Arvato + Microsoft), censé offrir Azure sous opération allemande. Contrairement à S3NS, Delos n'a pas obtenu de certification équivalente à SecNumCloud à ce jour.

Position comparative France-Allemagne :

Enseignement clé : L'Allemagne illustre le risque d'une approche trop ambitieuse sans accompagnement suffisant. La France progresse plus lentement mais avec des acquis plus solides (SecNumCloud qualifié).

9.2 Pays-Bas : le pragmatisme assumé

Les Pays-Bas ont adopté une approche distincte, assumant la dépendance technologique tout en la négociant activement.

La doctrine néerlandaise : "Strategic Autonomy within Interdependence"

Plutôt que de viser l'indépendance technologique jugée irréaliste, les Pays-Bas cherchent à maximiser leur pouvoir de négociation au sein de la dépendance. Cette approche se traduit par :

Le DPIA Microsoft 365 : un précédent européen

En 2022, l'autorité de protection des données néerlandaise (AP) a conduit une évaluation d'impact (DPIA) sur Microsoft 365 dans l'administration, identifiant 8 risques élevés. Cette analyse, partagée avec les autres États membres, a conduit à des renégociations contractuelles avec Microsoft à l'échelle européenne.

Résultats obtenus :

Limites de l'approche :

9.3 Pays nordiques : l'open source institutionnalisé

Les pays nordiques (Suède, Norvège, Finlande, Danemark) partagent une culture de transparence et d'open source qui facilite les stratégies de souveraineté.

Suède : le cas Skatteverket

L'administration fiscale suédoise (Skatteverket) a migré 10 000 postes de travail vers Linux (Ubuntu) entre 2019 et 2024, devenant la plus grande administration européenne sur poste Linux.

Économie nette : 4,7 M EUR/an, soit 44% de réduction.

Facteurs de succès :

Finlande : le cloud souverain mutualisé

La Finlande a créé Valtori, un opérateur public de services numériques fournissant cloud et bureautique à l'ensemble des administrations. Ce modèle mutualisé permet des économies d'échelle tout en maintenant le contrôle national.

Chiffres Valtori (2025) :

Danemark : le "Digital-ready legislation"

Le Danemark impose depuis 2018 que toute nouvelle loi soit "digitally ready", c'est-à-dire conçue pour être implémentée sur des systèmes numériques ouverts et interopérables. Cette approche "by design" limite la création de nouvelles dépendances propriétaires.

9.4 Chine : la souveraineté comme doctrine d'État

La Chine a déployé la stratégie de souveraineté numérique la plus complète et la plus radicale, avec des moyens sans équivalent.

La doctrine "信息安全" (sécurité de l'information)

Depuis le discours de Xi Jinping de 2014 sur la "cyber-souveraineté", la Chine a érigé l'indépendance technologique en priorité nationale absolue. Cette doctrine se traduit par :

Résultats de la stratégie (2020-2025)

Le coût de la souveraineté chinoise

La Chine a accepté des compromis significatifs :

Transposabilité à l'Europe : Faible. La Chine combine taille de marché (1,4 Md habitants), autoritarisme politique, et acceptation sociale du contrôle numérique que les démocraties européennes ne peuvent répliquer.

9.5 Corée du Sud : l'équilibre techno-nationaliste

La Corée du Sud présente un cas intermédiaire : forte base industrielle technologique, alliance stratégique avec les États-Unis, mais volonté d'autonomie croissante.

La stratégie "Digital New Deal" (2020-2025)

Le plan de 58 Md USD intègre une composante souveraineté avec :

Le cloud souverain coréen

L'approche hybride coréenne

La Corée distingue :

Ce modèle de classification inspiré des approches militaires offre un pragmatisme que l'Europe pourrait adapter.

9.6 Tableau comparatif synthétique

Synthèse comparative

9.7 Recommandations issues du benchmark international

L'analyse comparative suggère plusieurs enseignements pour la stratégie française :

1. Adopter la classification coréenne Distinguer explicitement les niveaux de sensibilité et adapter les exigences. Tout ne justifie pas SecNumCloud.

2. Créer un "Valtori français" Mutualiser les services numériques de l'État dans un opérateur dédié permettrait des économies d'échelle et une masse critique pour les solutions souveraines.

3. Répliquer l'approche DPIA néerlandaise Systématiser les évaluations d'impact et les renégociations contractuelles avec les fournisseurs américains.

4. Lancer des pilotes "à la suédoise" Identifier des administrations volontaires pour des migrations complètes vers l'open source, documenter et partager les retours d'expérience.

5. Éviter l'erreur allemande Ne pas annoncer d'objectifs irréalistes. Privilégier une progression mesurable à une ambition inatteignable.

Partie X : Doctrine politique explicite de la souveraineté numérique française

Cette partie propose une doctrine politique explicite pour la souveraineté numérique française. Contrairement aux recommandations techniques des parties précédentes, elle formule des choix politiques assumés sur ce que l'État devrait accepter, refuser et exiger.

10.1 Préambule doctrinal

Constat fondateur

La dépendance numérique de la France vis-à-vis des acteurs américains constitue une vulnérabilité stratégique qui, sans relever de la menace immédiate, expose l'État et l'économie nationale à des risques de disruption majeure en cas de dégradation des relations transatlantiques.

Cette dépendance n'est pas le fruit d'une fatalité technologique mais de choix cumulés sur trois décennies : sous-investissement dans la R&D numérique, préférence pour l'achat sur étagère, absence de politique industrielle coordonnée, naïveté sur les enjeux de souveraineté.

La correction de cette trajectoire est possible mais coûteuse. Elle suppose des arbitrages politiques explicites, un effort financier soutenu, et une constance de la volonté sur plusieurs mandatures.

Principes directeurs

La doctrine proposée repose sur quatre principes :

10.2 Ce que l'État ACCEPTE

Acceptation explicite n°1 : La dépendance technologique de court terme

L'État accepte de maintenir, pour une période transitoire de 10 ans maximum, l'usage de technologies américaines pour les systèmes non sensibles, sous conditions :

Justification : Le remplacement immédiat de Microsoft, AWS ou Google est techniquement irréaliste et économiquement prohibitif. Nier cette réalité conduit à l'immobilisme.

Acceptation explicite n°2 : Le surcoût de la souveraineté

L'État accepte un surcoût de 20 à 30% sur les solutions souveraines par rapport aux hyperscalers américains, considérant ce différentiel comme :

Justification : Exiger la parité de prix immédiate avec les GAFAM revient à interdire de facto les solutions souveraines.

Acceptation explicite n°3 : Les offres hybrides qualifiées

L'État accepte le recours aux offres hybrides (S3NS, BLEU) pour les données sensibles, sous réserve de leur qualification SecNumCloud, considérant que :

Justification : Refuser les offres hybrides au nom de la pureté reviendrait à maintenir la dépendance directe aux hyperscalers.

Acceptation explicite n°4 : La progressivité

L'État accepte une trajectoire de transition sur 10-15 ans plutôt qu'une bascule brutale, avec des jalons intermédiaires mesurables :

Justification : Les migrations forcées échouent. Seule une progression maîtrisée permet l'appropriation par les utilisateurs et l'adaptation des processus.

10.3 Ce que l'État REFUSE

Refus explicite n°1 : Les données régaliennes sur infrastructure non souveraine

L'État refuse catégoriquement l'hébergement sur des infrastructures non qualifiées SecNumCloud (ou équivalent EUCS élevé+) des données suivantes :

Ce refus est non négociable et sans exception, quel que soit l'argument de performance, de coût ou de facilité invoqué.

Refus explicite n°2 : La dépendance à fournisseur unique

L'État refuse toute situation de dépendance critique à un fournisseur unique pour un service essentiel, que ce fournisseur soit américain, européen ou français.

Concrètement :

Refus explicite n°3 : L'extraterritorialité subie sans réaction

L'État refuse d'accepter passivement l'application extraterritoriale du droit américain (Cloud Act, FISA) aux données françaises.

Concrètement :

Refus explicite n°4 : La résignation technologique

L'État refuse le discours selon lequel l'Europe serait condamnée à la dépendance technologique.

Concrètement :

Refus explicite n°5 : Le dumping de souveraineté

L'État refuse les offres commerciales qui sacrifient la souveraineté sur l'autel du prix.

Concrètement :

10.4 Ce que l'État EXIGE

Exigence n°1 : La transparence des fournisseurs

L'État exige de tout fournisseur de services numériques :

Exigence n°2 : La portabilité effective

L'État exige la portabilité réelle (et non théorique) des données et des applications :

Exigence n°3 : La localisation et le contrôle

Pour les données sensibles, l'État exige cumulativement :

Exigence n°4 : La prévisibilité contractuelle

L'État exige des engagements contractuels de long terme :

Exigence n°5 : La contribution à l'écosystème

L'État exige des grands fournisseurs étrangers une contribution au développement de l'écosystème français :

10.5 Matrice décisionnelle de la doctrine

La doctrine se traduit opérationnellement par une matrice de décision croisant niveau de sensibilité et type de solution :

10.6 Gouvernance de la doctrine

Instance de pilotage

Création d'un Comité de la Souveraineté Numérique (CSN) rattaché au SGDSN, réunissant :

Missions :

Mécanisme de dérogation

Toute dérogation à la doctrine doit :

Clause de revoyure

La doctrine fait l'objet d'une révision tous les 3 ans pour intégrer :

10.7 Trajectoire cible

Jalons politiques

10.8 Engagements et redevabilité

Engagement de transparence

Le gouvernement publie annuellement :

Engagement de constance

La présente doctrine engage l'État au-delà des alternances politiques. Elle ne peut être modifiée que par un décret motivé, après avis du CSN et information du Parlement.

Engagement de moyens

L'État s'engage sur un effort budgétaire de 500 M EUR/an dédiés à la transition souveraine, inscrits dans la loi de programmation des finances publiques.

Conclusion : au-delà du discours, les actes

Le paradoxe en voie de résolution ?

La France et l'Europe disposent désormais d'un cadre conceptuel, juridique et technique pour la souveraineté numérique parmi les plus élaborés au monde. Le RGPD a fait école. SecNumCloud constitue un référentiel exigeant. Le package DMA/DSA/AI Act impose des contraintes inédites aux géants du numérique. La qualification de S3NS fin 2025 démontre que le modèle hybride peut satisfaire aux exigences de souveraineté.

Pourtant, la dépendance structurelle aux acteurs américains persiste dans les usages quotidiens. Microsoft équipe l'essentiel des postes de travail des administrations françaises. AWS et Azure dominent le cloud des entreprises. Les smartphones sont américains ou utilisent un OS américain.

Le paradoxe s'explique par l'écart entre la capacité à réguler/certifier et la capacité à substituer. L'Europe sait contraindre les acteurs étrangers et qualifier des alternatives, mais le basculement effectif des usages prend du temps et suppose d'accepter des compromis temporaires.

Les conditions du changement

Trois conditions restent nécessaires pour que la souveraineté numérique devienne pleinement effective :

1. Accepter une période de transition avec des offres hybrides Les offres 100% souveraines sur toute la pile technologique n'existent pas à l'échelle requise. Les offres hybrides qualifiées (S3NS, bientôt BLEU) constituent une étape intermédiaire réaliste, à condition d'en assumer les limites et de continuer à développer des alternatives pures.

2. Investir dans les couches non couvertes La certification SecNumCloud ne suffit pas : il faut développer des alternatives SaaS (bureautique, collaboration), des OS audités, des stacks applicatives européennes. Cet effort suppose des investissements massifs sur 10-15 ans.

3. Maintenir la pression dans la durée Les cycles politiques sont courts, les transformations numériques sont longues. Une stratégie de souveraineté numérique suppose une constance de l'effort sur plusieurs mandatures.

Le test de réalité

La vraie mesure de la souveraineté numérique n'est pas dans les textes mais dans les crises. La qualification de S3NS est un progrès, mais la question ultime reste : que se passerait-il si les États-Unis imposaient des sanctions à des entités européennes comme ils l'ont fait avec la Russie ?

La réponse est aujourd'hui : dégradation significative mais pas paralysie totale. C'est un progrès par rapport à la situation d'il y a cinq ans. C'est encore insuffisant pour une souveraineté pleinement effective.

Annexe : Glossaire

ANSSI : Agence nationale de la sécurité des systèmes d'information, autorité française de cybersécurité.

Backdoor : Porte dérobée, accès caché dans un système informatique permettant de contourner les mécanismes de sécurité normaux.

BULLRUN : Programme de la NSA révélé par Snowden visant à affaiblir les standards de chiffrement et insérer des backdoors dans les produits commerciaux.

Cloud Act : Clarifying Lawful Overseas Use of Data Act (2018), loi américaine permettant aux autorités d'accéder aux données détenues par des entreprises américaines quel que soit leur lieu de stockage.

Code dormant : Code malveillant inséré dans un système et restant inactif jusqu'à une activation conditionnelle (date, signal externe, conditions spécifiques).

Crypto AG : Entreprise suisse de chiffrement secrètement contrôlée par la CIA et le BND pendant des décennies, ayant vendu des équipements compromis à plus de 120 pays.

DMA : Digital Markets Act, règlement européen sur les marchés numériques ciblant les "gatekeepers".

DORA : Digital Operational Resilience Act, règlement sur la résilience numérique du secteur financier, applicable depuis le 17 janvier 2025.

DSA : Digital Services Act, règlement européen sur les services numériques régissant la responsabilité des plateformes.

EUCS : EU Cybersecurity Certification Scheme for Cloud Services, projet de certification cloud européenne en négociation.

FISA : Foreign Intelligence Surveillance Act, loi américaine sur la surveillance des communications étrangères.

Gatekeeper : Contrôleur d'accès, qualification DMA des grandes plateformes occupant une position d'intermédiation incontournable.

GPAI : General Purpose AI, modèles d'IA de fondation à usage général (GPT, Claude, Gemini).

IaaS : Infrastructure as a Service, service cloud fournissant des ressources informatiques de base (calcul, stockage, réseau).

NIS2 : Network and Information Security Directive 2, directive européenne sur la cybersécurité des infrastructures critiques.

NSA : National Security Agency, agence de renseignement américaine spécialisée dans le renseignement d'origine électromagnétique et la cybersécurité.

NSL : National Security Letter, injonction administrative du FBI permettant d'exiger des informations sans mandat judiciaire, avec interdiction de divulgation.

PaaS : Platform as a Service, service cloud fournissant une plateforme de développement et d'exécution d'applications.

QUANTUM : Programme de la NSA permettant l'interception et la modification du trafic Internet en temps réel.

RGPD : Règlement général sur la protection des données, règlement européen sur les données personnelles.

S3NS : Société commune Thales opérant la technologie Google Cloud sous licence, qualifiée SecNumCloud le 17 décembre 2025.

SaaS : Software as a Service, service cloud fournissant des applications prêtes à l'emploi.

SecNumCloud : Référentiel de sécurité de l'ANSSI pour les prestataires de services cloud.

Stuxnet : Ver informatique découvert en 2010, considéré comme la première cyberarme d'État, ayant détruit des centrifugeuses du programme nucléaire iranien.

TAO : Tailored Access Operations, unité de la NSA spécialisée dans les opérations d'intrusion ciblées et l'insertion de backdoors matérielles.

VLOP : Very Large Online Platform, très grande plateforme en ligne au sens du DSA (>45M utilisateurs UE).

Annexe : Sources et références

Sources institutionnelles

Rapports et études

Données chiffrées

Article rédigé selon les critères éditoriaux de SensPo.fr. Les Parties I à V visent l'analyse factuelle. Les Parties VI à VIII assument une position éditoriale engagée en faveur de la souveraineté numérique. Les projections budgétaires sont des estimations indicatives. Mise à jour : janvier 2026.