Souveraineté numérique : de quoi parle-t-on vraiment ?

Dialogue entre un entrepreneur du cloud et un architecte Open Source first

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

Les intervenants

Kevin : Chef d'entreprise française spécialisée dans les technologies cloud et opérateurs télécoms. Vision pragmatique du marché, confronté quotidiennement aux réalités économiques et techniques du secteur. Vingt ans d'expérience dans la transformation numérique des entreprises françaises.

Sylvain : Architecte systèmes et analyste politique. Expert des infrastructures haute disponibilité multi-AZ avec PCA/PRA, spécialiste de l'open source et des chaînes de production logicielles sans dépendance aux GAFAM. Perspective souverainiste centrée sur la maîtrise des couches applicatives face aux législations extraterritoriales (FISA, Cloud Act).

Thèse centrale

La souveraineté numérique n'est pas un concept binaire mais un spectre de dépendances à cartographier et à arbitrer. Le débat actuel souffre d'une confusion entre souveraineté juridique, souveraineté technique et souveraineté opérationnelle. Une approche réaliste distingue les couches où l'autonomie est atteignable à court terme (logiciel, applications, plateformes) de celles où elle suppose des décennies d'investissement (gravure de semi-conducteurs avancés).

Position de convergence

Construire un patrimoine de calcul souverain en CAPEX (investissement capitalisé) plutôt qu'en OPEX (dépense récurrente vers des fournisseurs étrangers), à condition que les couches logicielles soient open source ou détenues à 100% par des capitaux européens, sans dépendance systémique aux législations extraterritoriales américaines (FISA, Cloud Act, ITAR) ou chinoises.

Grille de lecture proposée

Introduction

La souveraineté numérique est devenue un lieu commun du discours politique et économique. Ministres, dirigeants d'entreprise, experts autoproclamés : tous invoquent ce concept sans jamais le définir précisément. Cette imprécision n'est pas innocente. Elle permet de labelliser "souverain" à peu près n'importe quelle offre, du moment qu'un drapeau tricolore figure sur la plaquette commerciale.

Cet échange entre deux praticiens du secteur vise à dissiper le brouillard. Kevin apporte le regard de l'entrepreneur confronté aux contraintes du marché. Sylvain apporte celui de l'architecte qui a construit des infrastructures critiques sans recourir aux hyperscalers américains. Leurs perspectives divergent parfois, mais convergent sur l'essentiel : la souveraineté se construit couche par couche, avec méthode, en distinguant l'atteignable de l'illusoire.

Partie I : De quoi parle-t-on quand on parle de souveraineté ?

1.1 Le flou sémantique comme stratégie commerciale

Kevin : Quand je vois mes concurrents brandir le terme "souverain" à tout bout de champ, je suis partagé entre l'agacement et l'inquiétude. Agacement parce que le mot est vidé de son sens. Inquiétude parce que cette confusion dessert tout le monde, y compris ceux qui font un vrai travail de fond.

Prenons un exemple concret. Un hébergeur français qui revend du Azure avec une facturation en euros et un support en français, est-ce souverain ? Techniquement, les données transitent par des datacenters Microsoft, le code tourne sur leur hyperviseur, et le Cloud Act s'applique. Mais commercialement, ça se vend comme du "cloud de confiance".

Sylvain : Le problème est plus profond. On confond trois choses distinctes : la localisation géographique, la nationalité du prestataire, et la maîtrise technique réelle. Un datacenter à Paris opéré par AWS reste soumis au droit américain. Une ESN française qui déploie du VMware reste dépendante de Broadcom pour les licences. Un éditeur tricolore dont le code source dépend de bibliothèques maintenues par Google reste vulnérable à un changement de politique de licence.

La souveraineté, au sens où je l'entends, c'est la capacité à maintenir le service sans dépendre d'une décision d'une puissance étrangère. C'est quasi binaire sur ce point : soit tu peux continuer à opérer si les États-Unis décident demain de te couper l'accès, soit tu ne peux pas.

Kevin : C'est une définition exigeante. À ce compte-là, presque personne n'est souverain.

Sylvain : Exactement. Et c'est pourquoi il faut raisonner par couches et par niveaux de risque. On ne peut pas exiger le même degré d'autonomie pour une PME qui gère sa comptabilité et pour un OIV qui traite des données de défense.

1.2 Une grille de lecture par couches

Sylvain : Pour sortir du flou, je propose de raisonner par couches. Le modèle OSI, conçu pour les réseaux, peut servir de grille pédagogique, même s'il ne colle pas parfaitement à la distinction hardware/software :

Couches hautes : Application, présentation, session (logiciel, plateformes)
Couches intermédiaires : Transport, réseau (protocoles, routage)
Couches basses : Liaison, physique (matériel, câbles, puces)

La question de la souveraineté se pose différemment selon les niveaux. Sur les couches basses, on parle de matériel : serveurs, switches, câbles, puces. Sur les couches hautes, on parle de logiciel : systèmes d'exploitation, middlewares, applications. La frontière n'est pas nette (un firmware est du logiciel embarqué dans du matériel), mais cette distinction reste opérationnelle.

Kevin : Et ta thèse, c'est qu'on peut être souverain sur les couches hautes sans l'être sur les couches basses ?

Sylvain : C'est plus nuancé. Ma thèse, c'est que la souveraineté sur les couches hautes est atteignable à court terme avec les bons choix architecturaux. La souveraineté sur les couches basses, notamment la gravure de semi-conducteurs avancés, prendra des décennies et des centaines de milliards d'investissement. Donc il faut prioriser.

Pour les secteurs critiques, je défends une approche hybride : accepter une dépendance contrôlée sur le hardware, à condition de le transformer en CAPEX (achat, propriété) plutôt qu'en OPEX (location, abonnement), et exiger une souveraineté totale sur les couches applicatives (logiciel, données, plateformes).

1.3 CAPEX vs OPEX : construire un patrimoine ou louer une dépendance

Kevin : Cette distinction CAPEX/OPEX est intéressante. Dans mon secteur, la tendance lourde depuis quinze ans, c'est justement le passage au modèle OPEX. Le cloud public, c'est ça : tu paies à l'usage, tu n'immobilises pas de capital, tu scales à la demande. Les DAF adorent.

Sylvain : Les DAF adorent parce qu'ils raisonnent en coût comptable immédiat, pas en risque stratégique à long terme. Quand tu passes tout en OPEX chez un hyperscaler américain, tu construis quoi comme patrimoine ? Rien. Tu enrichis AWS ou Azure. Le jour où les prix augmentent significativement (des hausses de 10 à 30% ont été observées sur certains services), tu subis. Le jour où une loi extraterritoriale te contraint, tu subis. Le jour où ton fournisseur décide de concurrencer ton métier avec les données qu'il a collectées sur ton usage, tu subis.

Le CAPEX, c'est l'inverse. Tu achètes des serveurs, tu les amortis sur cinq ans, tu construis une compétence interne pour les opérer. Au bout de cinq ans, le matériel est amorti, il continue à tourner, et ton coût marginal tend vers l'électricité et la maintenance.

Kevin : Mais le CAPEX suppose des compétences internes que beaucoup d'organisations n'ont pas. Et la flexibilité du cloud, la capacité à scaler en quelques minutes, ça a une vraie valeur.

Sylvain : Je ne dis pas que le CAPEX convient à tout le monde. Je dis que pour les acteurs qui ont des enjeux de souveraineté réels, comme les OIV, les administrations, les entreprises stratégiques, le réflexe "tout en OPEX chez les Américains" est une erreur stratégique.

Et sur la flexibilité : avec une bonne architecture, tu peux avoir du scaling automatique sur ton propre matériel. Kubernetes, OpenStack, les outils existent. La différence, c'est que tu dois investir dans la compétence pour les maîtriser.

Hypothèses de ce scénario : 100 serveurs, charge stable, amortissement 5 ans, datacenter colocation, équipe ops de 2 ETP pour CAPEX. Le cloud suppose une croissance des coûts de 8-10%/an (hausse tarifs + usage). Ces chiffres varient fortement selon les profils de charge, les volumes egress, et les niveaux de service requis.

1.4 La vraie question : qui contrôle quoi en cas de crise ?

Kevin : Au fond, la souveraineté, c'est une question de contrôle en situation dégradée. Tant que tout va bien, personne ne se pose la question. C'est quand ça déraille que la dépendance devient visible.

Sylvain : Exactement. Et c'est pourquoi je raisonne toujours en termes de PCA (Plan de Continuité d'Activité) et de PRA (Plan de Reprise d'Activité). Quand je conçois une infrastructure, je me demande : que se passe-t-il si tel fournisseur me coupe l'accès demain ? Puis-je basculer ? En combien de temps ? À quel coût ?

Si la réponse est "je ne peux pas basculer parce que tout mon code dépend de services propriétaires AWS", alors je ne suis pas souverain. Je suis locataire précaire.

Un vrai PCA/PRA souverain suppose :

Kevin : C'est le niveau d'exigence qu'on trouve dans les secteurs régulés : banque, santé, défense.

Sylvain : Oui. Et ma conviction, c'est que cette exigence devrait se généraliser à mesure que le numérique devient critique pour tous les secteurs. On l'a vu avec les ransomwares : des hôpitaux paralysés, des collectivités à genoux. La résilience n'est plus un luxe.

Partie II : La grande confusion actuelle

2.1 Historiquement : le hardware dédié

Kevin : Pour comprendre où on en est, il faut remonter un peu. Dans les années 80-90, l'informatique d'entreprise, c'était du hardware dédié. Tu achetais un mainframe IBM, tu le faisais tourner avec une équipe dédiée, et personne d'autre n'y touchait. La question de la souveraineté ne se posait pas en ces termes : tu possédais physiquement ta machine.

Sylvain : C'était l'époque des architectures propriétaires. Chaque constructeur avait son OS, son format de données, ses protocoles. La dépendance existait, mais elle était visible et assumée : tu étais "client IBM" ou "client Bull" ou "client Digital". Changer de fournisseur coûtait une fortune, mais au moins tu savais à qui tu avais affaire.

Kevin : Et puis la standardisation est arrivée.

2.2 La standardisation du hardware et des packages logiciels

Sylvain : Les années 90-2000 ont vu deux révolutions convergentes. D'un côté, la standardisation du hardware autour de l'architecture x86 d'Intel. De l'autre, l'émergence de systèmes d'exploitation standardisés : Windows NT pour le monde Microsoft, Linux pour le monde ouvert.

Cette standardisation a été une libération : tu pouvais changer de fournisseur de serveurs sans réécrire tes applications. Un serveur Dell ou HP ou IBM, ça faisait tourner le même code. La concurrence sur le hardware a fait baisser les prix.

Kevin : Mais cette standardisation autour de x86 a créé une nouvelle dépendance, cette fois à Intel.

Sylvain : Oui, et c'est un point crucial. On a remplacé une dépendance visible (constructeur intégré) par une dépendance invisible (le couple Intel + Microsoft, le fameux "Wintel"). Pendant vingt ans, ces deux acteurs ont dominé l'informatique d'entreprise. AMD a survécu comme challenger, mais Intel fixait le tempo.

La vraie question qu'on n'a pas posée à l'époque : est-ce qu'une dépendance à un acteur américain pour les CPU pose un problème stratégique ? La réponse était non, parce qu'on était encore dans l'illusion de la mondialisation heureuse.

2.3 La main mise américaine et l'émergence de l'open source

Kevin : Les années 2000-2010 ont vu l'émergence du cloud et des GAFAM. Amazon lance AWS en 2006, Microsoft lance Azure en 2010, Google développe ses propres datacenters. En quelques années, ces acteurs ont construit des infrastructures d'une échelle sans précédent.

Sylvain : Et ils ont réussi un tour de force : transformer la dépendance au hardware en dépendance au service. Avec le cloud public, tu ne possèdes plus rien. Tu consommes de la puissance de calcul, du stockage, des services managés. Ton code devient dépendant d'API propriétaires : Lambda pour AWS, Azure Functions pour Microsoft, BigQuery pour Google.

Ce qui est pervers, c'est que cette dépendance se construit progressivement. Tu commences par un simple hébergement de VM, puis tu adoptes leur base de données managée parce que c'est plus simple, puis leur service de queue de messages, puis leur outil de machine learning. Au bout de trois ans, ton architecture est tellement imbriquée dans l'écosystème du fournisseur que migrer coûterait une fortune.

Kevin : C'est le fameux "lock-in".

Sylvain : Exactement. Et c'est là que l'open source devient stratégique. Face à ce lock-in, la communauté open source a développé des alternatives à chaque brique propriétaire. PostgreSQL au lieu de RDS, Kubernetes au lieu d'ECS, MinIO au lieu de S3, Kafka au lieu de Kinesis. Toutes ces technologies sont matures, éprouvées en production, et surtout : portables.

Avec une stack full open source, tu peux déployer chez n'importe quel hébergeur, sur ton propre datacenter, ou en hybride. Tu n'es pas prisonnier.

2.4 La capacité réelle de pilotage

Kevin : Mais l'open source, ça ne se déploie pas tout seul. Il faut des compétences.

Sylvain : C'est le nerf de la guerre. La souveraineté technique sans souveraineté des compétences, c'est du théâtre. Tu peux avoir la meilleure stack open source du monde, si tu n'as pas les équipes pour la déployer, l'opérer, la sécuriser, la faire évoluer, tu restes dépendant. Simplement, ta dépendance se déplace du fournisseur cloud vers l'intégrateur ou l'ESN qui fait le travail à ta place.

C'est pourquoi je milite pour une approche qui combine :

Le pire scénario, c'est l'organisation qui a tout délégué, qui ne comprend plus son propre SI, et qui est à la merci du premier incident ou du premier changement de contrat.

Kevin : C'est un problème culturel autant que technique. Beaucoup de DSI ont été formatés à l'idée que l'IT est un centre de coût qu'il faut externaliser. Le "core business", c'est ailleurs.

Sylvain : Cette vision est obsolète. Aujourd'hui, pour la plupart des entreprises, l'IT est le business. Ta supply chain tourne sur des ERP. Ta relation client passe par des CRM. Tes ventes se font en ligne. Tes données sont ton actif le plus précieux. Externaliser aveuglément, c'est externaliser ton avantage compétitif.

2.5 Les dépendances aux États-Unis et à la Chine

Sylvain : Maintenant, parlons des dépendances structurelles qu'on ne peut pas éliminer à court terme.

Côté américain, on a :

Côté chinois, on a :

Kevin : Et au milieu, l'Europe ?

Sylvain : L'Europe n'a pas de fondeur de semi-conducteurs avancés. TSMC est taïwanais, Samsung est coréen, Intel et GlobalFoundries sont américains. ASML est néerlandais pour les machines de lithographie, c'est un atout stratégique majeur, mais ça ne suffit pas à graver des puces.

Sur le software, on a quelques champions : SAP en Allemagne, Dassault Systèmes en France, mais ils sont minoritaires dans l'écosystème global.

C'est pourquoi je dis qu'il faut être lucide : la souveraineté sur le hardware avancé (CPU, GPU dernière génération) est un objectif à 15-20 ans, pas à 3 ans. En attendant, il faut sécuriser ce qu'on peut sécuriser : les couches logicielles, les données, les compétences.

2.6 Le cas particulier du FISA et du Cloud Act

Kevin : Tu mentionnes souvent le FISA et le Cloud Act. Peux-tu expliquer concrètement ce que ça implique ?

Sylvain : Le Foreign Intelligence Surveillance Act (FISA) et le Clarifying Lawful Overseas Use of Data Act (Cloud Act) sont deux lois américaines qui permettent aux autorités US d'accéder aux données détenues par des entreprises américaines, y compris si ces données sont stockées hors des États-Unis.

Concrètement : si tu utilises AWS, Azure ou GCP, le gouvernement américain peut légalement exiger l'accès à tes données, y compris celles stockées en Europe. Ces requêtes peuvent inclure des ordres de confidentialité (gag orders) limitant l'information du client. Les marges de contestation juridique existent mais sont limitées dans la pratique, surtout pour les entreprises non-américaines. Le cadre juridique européen (RGPD) entre en conflit avec ces lois, créant une insécurité juridique structurelle.

Kevin : Mais les hyperscalers proposent des options de chiffrement...

Sylvain : Le chiffrement côté serveur avec des clés gérées par le fournisseur ne protège pas du Cloud Act. Le fournisseur a les clés, il peut déchiffrer.

Le seul chiffrement qui protège, c'est le chiffrement côté client avec des clés que tu gères toi-même et que tu ne transmets jamais au fournisseur. Mais dans ce cas, tu perds l'accès à la plupart des services managés qui ont besoin de lire tes données pour fonctionner.

C'est un dilemme structurel : soit tu utilises les services avancés du cloud US et tu acceptes l'exposition au Cloud Act, soit tu chiffres en local et tu te prives de ces services.

Kevin : D'où l'intérêt des offres "cloud de confiance" à la française ?

Sylvain : En théorie oui. En pratique, il faut regarder de près. Bleu (Orange + Capgemini avec techno Microsoft) ou S3ns (Thales avec techno Google) proposent d'opérer des technologies américaines sous licence, dans des datacenters français, avec des équipes françaises. L'idée est de créer une barrière juridique : l'entité opératrice est française, donc non soumise au Cloud Act.

Mais cette barrière est fragile. Microsoft et Google restent propriétaires du code source. Ils peuvent modifier les conditions de licence. En cas de conflit géopolitique majeur, le risque existe que le gouvernement américain exige de Microsoft ou Google de suspendre leurs licences. C'est un scénario hypothétique, pas une certitude, mais l'absence de jurisprudence claire et les précédents sur d'autres secteurs (Huawei, semi-conducteurs) montrent que ce risque n'est pas purement théorique.

Pour moi, le "cloud de confiance" est un compromis acceptable pour du moyen de gamme, pas pour du haut de gamme stratégique.

2.7 S3NS et BLEU : l'erreur stratégique et économique

Kevin : Tu es donc critique sur ces offres "cloud de confiance" ?

Sylvain : Critique est faible. Si l'objectif est l'autonomie à long terme et la réduction du risque extraterritorial, S3NS et BLEU sont des choix stratégiques fortement contestables. En pleine guerre technologique mondiale, ce choix me semble contradictoire avec les objectifs affichés de souveraineté.

Commençons par l'erreur stratégique. On est en 2025. Les États-Unis ont déclenché une guerre des semi-conducteurs contre la Chine. L'extraterritorialité du droit américain s'est renforcée. Les sanctions peuvent tomber du jour au lendemain sur n'importe quel secteur. Et la réponse française, c'est de payer des milliards en licences à Microsoft et Google pour opérer leurs technologies sous franchise ?

Pour prendre une analogie historique : c'est comme si, en pleine guerre froide, on avait décidé de construire notre dissuasion nucléaire en sous-traitant les ogives aux Américains. On aurait eu des "ogives de confiance", opérées par des Français, mais dont le fonctionnement dépendrait in fine d'un partenaire étranger. L'analogie est imparfaite, mais elle illustre la différence entre contrôle apparent et maîtrise réelle.

Kevin : Mais l'argument de ces offres, c'est qu'elles permettent d'avoir le meilleur des deux mondes : la technologie de pointe des hyperscalers et la protection juridique française.

Sylvain : C'est un leurre. D'abord, la protection juridique est plus fragile qu'il n'y paraît. Microsoft et Google restent propriétaires du code. Ils peuvent modifier les conditions de licence. Ils peuvent décider que tel usage n'est plus couvert. En cas de conflit géopolitique majeur, le risque existe que le Département du Commerce américain exige la suspension des licences, comme il l'a fait pour d'autres technologies (semi-conducteurs vers la Chine, logiciels vers la Russie). Ce scénario n'est pas certain, mais si Bleu ou S3NS devaient continuer à opérer sans licence, ils n'ont pas le code source. C'est une vulnérabilité structurelle.

Ensuite, si l'objectif est de construire un écosystème européen, c'est une erreur économique. Chaque euro versé en licence à Microsoft ou Google, c'est un euro qui ne finance pas l'écosystème européen. On parle de contrats à plusieurs centaines de millions d'euros. Cet argent, investi dans des alternatives open source européennes, aurait pu créer des emplois, des compétences, un tissu industriel.

Kevin : Mais les alternatives européennes sont-elles au niveau techniquement ?

Sylvain : C'est là que le débat est biaisé. On compare l'écosystème Microsoft ou Google, construit sur 20 ans avec des centaines de milliards d'investissement, à des alternatives européennes qui n'ont jamais eu ces moyens. Évidemment qu'il y a un écart. Mais cet écart se comble si on investit. Et il ne se comblera jamais si on continue à financer les Américains.

Et surtout, il y a un fait nouveau qui change la donne : l'IA générative.

2.8 L'IA comme accélérateur de souveraineté

Sylvain : On est à un moment charnière. L'IA générative permet aujourd'hui ce qui était impensable il y a trois ans : redévelopper, migrer, transformer des systèmes entiers à une vitesse inédite.

Tu veux migrer une application de Azure vers une stack open source ? L'IA peut analyser le code existant, identifier les dépendances propriétaires, proposer des équivalents open source, générer le code de migration. Ce qui prenait des mois de travail d'architecte peut maintenant se faire en semaines.

Tu veux transformer des données d'un schéma propriétaire vers un format ouvert ? L'IA peut parser les structures, comprendre la sémantique, proposer des mappings, générer les scripts de transformation. Ce qu'on appelait "dette technique insurmontable" devient un chantier gérable.

Kevin : Tu parles de "colorer" les données ?

Sylvain : Oui, c'est une métaphore que j'utilise. Colorer les données, c'est les qualifier, les classifier, comprendre leur nature et leur usage pour les intégrer dans de nouveaux schémas. Avant, c'était un travail manuel titanesque. Aujourd'hui, l'IA peut analyser des millions de lignes de données, identifier les patterns, détecter les anomalies, proposer des typologies.

Concrètement, si tu as dix ans de données métier dans un format propriétaire, l'IA peut :

C'est un game changer pour la souveraineté. L'argument classique "on ne peut pas migrer, c'est trop complexe" ne tient plus. On peut migrer. Il faut juste la volonté et la méthode.

Cela dit, ces gains dépendent fortement de la qualité du code existant, de la documentation disponible, et de la gouvernance du SI. L'IA ne fait pas de miracles sur un legacy non documenté depuis 20 ans. Mais elle réduit drastiquement le coût d'entrée des projets de migration bien préparés.

Kevin : Donc ton argument, c'est que S3NS et BLEU arrivent au pire moment : on investit dans la dépendance alors qu'on a enfin les outils pour s'en libérer ?

Sylvain : Exactement. C'est comme acheter une calèche au moment où la voiture devient accessible. Ces contrats nous enferment pour 5 à 10 ans dans une dépendance à des technologies américaines, au moment précis où l'on pourrait investir dans des alternatives souveraines accélérées par l'IA.

Le calcul économique peut s'illustrer ainsi (scénario indicatif, hypothèses : budget IT public d'un grand ministère sur 10 ans) :

Dans dix ans, avec l'option S3NS/BLEU, on sera au même point de dépendance. Avec l'option souveraine, on aura un écosystème.

Note méthodologique : ces chiffres sont des ordres de grandeur illustratifs. Un calcul précis nécessiterait de spécifier : profil de charge, coûts egress, support, RH, énergie, amortissement, etc.

2.9 La méthode : comprendre, colorer, migrer

Kevin : Concrètement, comment on procède pour cette migration souveraine assistée par l'IA ?

Sylvain : Trois phases : comprendre, colorer, migrer.

Phase 1 : Comprendre

Avant de toucher à quoi que ce soit, il faut cartographier l'existant. Pas juste l'inventaire technique, mais la compréhension fonctionnelle : pourquoi cette donnée existe, qui l'utilise, pour quel processus métier.

L'IA peut analyser :

Le livrable de cette phase, c'est une cartographie sémantique du SI, pas juste technique.

Phase 2 : Colorer

Une fois qu'on comprend les données, on les qualifie. C'est la "coloration" :

Cette coloration permet de prioriser : on ne migre pas tout en même temps, on commence par ce qui est critique et faisable.

Phase 3 : Migrer

Avec la compréhension et la coloration, on peut planifier la migration :

L'IA accélère chaque étape : génération de code, détection d'anomalies, validation de cohérence, documentation automatique.

Kevin : Et les applications propriétaires type Office 365, SAP ?

Sylvain : C'est le sujet le plus sensible. Pour la bureautique, les alternatives existent : LibreOffice, OnlyOffice, Nextcloud. La migration est faisable, c'est surtout un changement d'habitude pour les utilisateurs.

Pour les ERP type SAP, c'est plus complexe. Mais là encore, l'IA change la donne. On peut :

C'est un chantier de plusieurs années, mais c'est faisable. Et c'est la seule option qui construit de la souveraineté réelle.

Le graphique ci-dessous présente des estimations indicatives basées sur des retours d'expérience de projets de migration. Les durées réelles varient significativement selon la complexité du legacy, la qualité de la documentation existante, et les compétences des équipes.

Partie III : Les critères de souveraineté par niveau d'exigence

3.1 L'approche par niveaux

Sylvain : Plutôt qu'un débat binaire "souverain / pas souverain", je propose une grille à trois niveaux qui permet à chaque organisation de se positionner en fonction de ses enjeux réels.

Kevin : Une sorte de certification interne ?

Sylvain : Plutôt un cadre d'analyse pour les décisions d'architecture. Chaque niveau définit des exigences sur quatre axes : hardware, logiciel, données, opérations. L'idée est de permettre une montée en maturité progressive.

3.2 Niveau 1 : Entrée de gamme (souveraineté minimale)

Sylvain : Ce niveau convient aux organisations sans enjeux stratégiques majeurs : PME classiques, associations, collectivités de petite taille, données non sensibles.

Kevin : C'est le niveau où se trouve la majorité du marché aujourd'hui.

Sylvain : Oui, et c'est normal. Pour une PME qui gère sa compta et ses mails, exiger une souveraineté totale serait disproportionné. L'enjeu ici, c'est surtout de ne pas créer de lock-in inutile et de garder la capacité à migrer si besoin.

La recommandation minimale : utiliser des formats ouverts, éviter les services propriétaires sans alternative, documenter son architecture.

3.3 Niveau 2 : Moyen de gamme (souveraineté opérationnelle)

Sylvain : Ce niveau correspond aux ETI, aux grandes collectivités, aux entreprises manipulant des données métier sensibles (mais pas classifiées).

Kevin : SecNumCloud, c'est la qualification ANSSI ?

Sylvain : Oui. SecNumCloud est un référentiel exigeant qui impose des contraintes sur la localisation, la nationalité des équipes, l'architecture technique, la sécurité physique. C'est un bon indicateur, même s'il ne couvre pas tout.

À ce niveau, l'organisation doit avoir une vraie compétence interne de pilotage. Pas forcément pour tout opérer elle-même, mais pour comprendre son architecture, challenger ses prestataires, et pouvoir reprendre la main en cas de crise.

La stack type :

Kevin : Et le coût par rapport à une approche cloud public ?

Sylvain : Sur le TCO à cinq ans, c'est souvent comparable ou moins cher, comme on l'a vu plus haut. Le surcoût initial est dans la montée en compétence des équipes. Mais c'est un investissement, pas une dépense perdue.

3.4 Niveau 3 : Haut de gamme (souveraineté stratégique)

Sylvain : Ce niveau est réservé aux OIV (Opérateurs d'Importance Vitale), aux administrations sensibles, à la défense, à certains acteurs de la santé ou de la recherche.

Kevin : À ce niveau, on sort du marché classique.

Sylvain : Complètement. Ce n'est plus une question de coût mais de capacité stratégique. L'État doit garantir que ses systèmes critiques fonctionneront même en cas de conflit majeur avec les États-Unis ou la Chine. C'est un scénario peu probable mais aux conséquences catastrophiques, donc il faut s'y préparer.

C'est ici que l'architecture ARM européenne prend tout son sens. SiPearl développe des processeurs ARM pour le calcul haute performance dans le cadre du projet européen EPI (European Processor Initiative). Ces puces ne rivaliseront pas avec les derniers GPU Nvidia pour l'entraînement de modèles d'IA massifs, mais elles peuvent couvrir les besoins de calcul des administrations, de la simulation scientifique, du traitement de données sensibles.

Kevin : Et la puissance de calcul pour l'IA ?

Sylvain : C'est le point de tension. Pour l'entraînement de grands modèles, on reste dépendant des GPU américains à court terme. Mais il faut distinguer l'entraînement (qui peut être fait sur des infrastructures moins sensibles) de l'inférence (qui peut tourner sur du matériel plus modeste et plus contrôlé).

Une stratégie réaliste : entraîner sur des infrastructures cloud avec les précautions adaptées, déployer en inférence sur des infrastructures souveraines. C'est un compromis, mais c'est atteignable.

3.5 La question des coûts

Kevin : Soyons concrets sur les coûts. Comment se comparent ces trois niveaux ?

Sylvain : C'est très variable selon les contextes, mais on peut donner des ordres de grandeur pour une infrastructure type de 50 serveurs sur 5 ans :

Hypothèses de ce scénario illustratif : 50 serveurs, charge stable, amortissement 5 ans, coûts RH équivalents entre options, énergie moyenne Europe, support niveau 2 inclus. Les coûts réels varient significativement selon le profil de charge, les volumes de données sortantes (egress), le niveau de support, et les compétences internes disponibles.

Kevin : Le niveau 2 serait donc compétitif économiquement ?

Sylvain : Oui, sur le TCO à cinq ans, une approche hybride souveraine avec du CAPEX hardware et une stack open source peut être moins chère que du cloud public, surtout si les workloads sont stables. Le cloud public est imbattable pour les charges variables, les POC, les projets courts. Mais pour une infrastructure pérenne à charge prévisible, le calcul change.

Ce qui coûte dans le niveau 2, c'est la montée en compétence initiale. Il faut des architectes qui maîtrisent Kubernetes, PostgreSQL, la sécurité Linux. Ces profils existent, mais ils sont recherchés. C'est un investissement humain autant que technique.

Partie IV : Mise en pratique et recommandations

4.1 Par où commencer ?

Kevin : Pour une organisation qui veut progresser sur la souveraineté, par où conseilles-tu de commencer ?

Sylvain : Trois étapes préalables avant tout chantier technique :

1. Cartographier les dépendances actuelles

Faire l'inventaire complet : quels fournisseurs, quelles technologies, quelles données où. Identifier les SPOF (Single Point of Failure) juridiques et techniques. Beaucoup d'organisations découvrent à cette étape qu'elles dépendent de services dont elles ignoraient l'existence.

2. Classifier les données et les applications

Tout n'a pas la même criticité. La messagerie interne et le système de contrôle industriel n'ont pas les mêmes enjeux. Classifier permet de cibler les efforts sur ce qui compte vraiment.

3. Définir sa cible de souveraineté

Niveau 1, 2 ou 3 ? Par application, par périmètre ? Cette décision est stratégique, elle doit impliquer la direction générale, pas seulement la DSI.

Ensuite seulement, on peut lancer les chantiers techniques : migration vers l'open source, rapatriement de données, montée en compétence des équipes, mise en place des PCA/PRA.

4.2 Les erreurs à éviter

Kevin : Quelles sont les erreurs classiques que tu observes ?

Sylvain : J'en vois trois récurrentes :

Erreur 1 : Confondre localisation et souveraineté

"Nos données sont en France" ne veut rien dire si l'opérateur est soumis au Cloud Act. La localisation géographique est une condition nécessaire mais pas suffisante. Ce qui compte, c'est la chaîne de contrôle juridique et technique.

Erreur 2 : Vouloir tout faire d'un coup

La souveraineté se construit par étapes. Vouloir migrer tout son SI vers une stack souveraine en six mois, c'est le meilleur moyen de se planter. Mieux vaut commencer par un périmètre pilote, apprendre, puis étendre.

Erreur 3 : Négliger le facteur humain

La plus belle architecture souveraine ne sert à rien si les équipes ne savent pas l'opérer. J'ai vu des projets échouer parce qu'on avait investi dans la technique mais pas dans la formation. Sur les programmes réussis que j'ai observés, le budget compétences représente souvent entre 20 et 40% du budget total. C'est un ordre de grandeur à garder en tête.

4.3 Une stack de référence pour le niveau 2

Sylvain : Pour concrétiser, voici une stack de référence que j'ai déployée plusieurs fois pour des clients en niveau 2 :

Infrastructure

Orchestration

Données

Applications

Observabilité

Sécurité

Tout est open source, tout est portable, tout est auditable. Et ça couvre 90% des besoins d'une organisation classique.

Kevin : C'est impressionnant de voir que l'écosystème open source couvre autant de besoins.

Sylvain : C'est le résultat de vingt ans d'investissement communautaire et industriel. Des entreprises comme Red Hat, Canonical, Elastic, GitLab ont construit des modèles économiques viables autour de l'open source. Elles emploient des développeurs qui contribuent au code. C'est un écosystème mature.

Le piège, c'est de croire que "open source = gratuit". Il faut du support, de l'expertise, du temps. Mais le modèle économique est plus sain : tu paies pour du service et de la compétence, pas pour une rente de licence.

4.4 Semi-conducteurs : l'atout ASML et l'opportunité TSMC

Kevin : On a beaucoup parlé du retard européen sur les semi-conducteurs. C'est vraiment irrattrapable ?

Sylvain : Non, et c'est là que le discours défaitiste m'agace. L'Europe a un atout stratégique majeur que tout le monde semble oublier : ASML.

ASML, c'est une entreprise néerlandaise qui détient le quasi-monopole mondial sur les machines de lithographie EUV (Extreme Ultraviolet). L'EUV est devenu quasi incontournable pour les noeuds les plus avancés (en dessous de 7nm environ, selon les définitions des fondeurs). Ni TSMC, ni Samsung, ni Intel ne peuvent produire leurs puces de dernière génération sans ASML.

C'est tellement stratégique que les États-Unis ont fait pression sur les Pays-Bas pour bloquer les ventes à la Chine. ASML est devenu un instrument de la guerre technologique américaine contre Pékin. Mais c'est une entreprise européenne.

Kevin : Donc on a l'équipementier, mais pas les fondeurs ?

Sylvain : Exactement. On fabrique les machines qui fabriquent les puces, mais on ne fabrique pas les puces nous-mêmes aux noeuds les plus avancés. L'Europe est surtout forte sur des noeuds matures et spécialisés : STMicroelectronics maîtrise le FD-SOI (jusqu'à 18nm) pour l'automobile et l'IoT, Infineon excelle sur les puces de puissance. Ce n'est pas un "retard" sur tout, c'est une spécialisation. Mais pour les processeurs généralistes de dernière génération (CPU, GPU), on dépend aujourd'hui de TSMC, Samsung ou Intel. GlobalFoundries a un site à Dresde, mais c'est une entreprise américaine. Sur les noeuds de pointe, l'Europe accuse actuellement un retard de 2 à 3 générations technologiques par rapport à TSMC.

Mais voilà ce qui devrait être la stratégie européenne : utiliser ASML comme levier pour négocier un vrai partenariat avec TSMC.

Kevin : TSMC ouvre des usines partout : Arizona, Japon, Allemagne...

Sylvain : Oui, et c'est une opportunité historique. TSMC cherche à diversifier géographiquement pour réduire le risque taïwanais. Ils ont besoin d'ASML pour leurs machines. L'Europe a une carte à jouer.

Mais attention : il ne faut pas se contenter d'accueillir une usine TSMC comme on accueille une usine Toyota. L'objectif doit être le transfert de compétences, pas juste l'implantation.

Concrètement, une vision à moyen terme (10-15 ans) ressemblerait à ça :

Phase 1 (2025-2028) : Partenariat d'implantation

Phase 2 (2028-2032) : Montée en compétences

Phase 3 (2032-2038) : Autonomisation progressive

Kevin : Ça demande une vision politique de long terme...

Sylvain : Exactement. Et c'est là que ça coince. Les Américains ont le CHIPS Act avec près de 280 milliards de dollars mobilisés (52 Mds$ publics + investissements privés engagés) et une vision claire : rapatrier la production et contenir la Chine. Les Chinois ont investi plus de 140 milliards via différents programmes et acceptent de perdre de l'argent pendant 15 ans pour construire leur filière.

L'Europe a l'European Chips Act avec 43 milliards, c'est bien, mais sans vision stratégique unifiée. Chaque pays veut son usine, on saupoudre, on ne concentre pas.

Le paradoxe, c'est qu'on a ASML. On a le levier. TSMC a besoin de nous pour ses machines. On pourrait négocier en position de force. Mais on ne le fait pas parce qu'on n'a pas de stratégie industrielle européenne digne de ce nom.

Kevin : Et le lien avec la souveraineté numérique dont on parlait ?

Sylvain : C'est le socle matériel de tout le reste. Sans puces souveraines, toutes les couches au-dessus restent fragiles. Tu peux avoir le meilleur OS open source, le meilleur cloud souverain, si tes serveurs tournent sur des CPU dont l'approvisionnement peut être coupé demain, tu n'as pas de vraie souveraineté.

Mais attention au piège du "tout ou rien". On n'a pas besoin de fabriquer tous les types de puces en Europe. On a besoin de :

ASML + partenariat TSMC + European Chips Act pourraient permettre ça. Si on a la vision et la volonté.

Note : les montants "investissement privé attendu" sont des projections basées sur les engagements annoncés par les industriels dans le cadre des programmes publics. Les chiffres chinois sont des estimations agrégées de différents programmes (Made in China 2025, Big Fund I et II, plans provinciaux).

4.5 Le rôle de l'État

Kevin : L'État a-t-il un rôle à jouer dans cette dynamique ?

Sylvain : Un rôle central, à trois niveaux :

1. Exemplarité

L'État devrait appliquer à ses propres systèmes les exigences qu'il recommande aux autres. Or, on voit encore des ministères sur Microsoft 365, des administrations sur AWS. Cette incohérence décrédibilise le discours souverainiste. L'État doit montrer que c'est possible en le faisant lui-même.

2. Commande publique

Les marchés publics représentent des milliards d'euros par an en IT. Si cette commande était orientée vers des solutions souveraines, ça créerait un marché suffisant pour faire vivre un écosystème européen. Aujourd'hui, trop de marchés sont rédigés de façon à favoriser les acteurs dominants (américains).

3. Formation

La souveraineté suppose des compétences. L'État doit investir massivement dans la formation aux technologies ouvertes : Linux, Kubernetes, PostgreSQL, cybersécurité. Pas seulement dans les écoles d'ingénieurs, mais aussi dans la formation continue, les reconversions, l'apprentissage.

Kevin : Et sur le hardware, tu as développé la stratégie ASML/TSMC...

Sylvain : Oui, c'est la clé. L'État doit porter cette vision à l'échelle européenne : utiliser notre levier ASML pour négocier un vrai transfert de compétences avec TSMC, pas juste accueillir des usines. En parallèle, soutenir les initiatives type EPI/SiPearl pour les niches stratégiques. L'objectif n'est pas de tout fabriquer en Europe, mais d'avoir une capacité de résilience sur les composants critiques d'ici 2035-2040.

Conclusion : construire plutôt que subir

Kevin : Pour conclure, quel message retiens-tu de cet échange ?

Sylvain : Trois idées forces :

1. La souveraineté est un spectre, pas un absolu

Il faut sortir du débat binaire. Chaque organisation peut et doit progresser sur l'échelle de la souveraineté, à son rythme, selon ses moyens et ses enjeux. L'important est d'avancer consciemment, pas de prétendre avoir atteint un idéal inaccessible.

2. Le logiciel est le levier accessible à court terme

On ne produira pas de CPU souverains demain. Mais on peut, dès aujourd'hui, migrer vers des stacks open source, chiffrer ses données avec des clés qu'on maîtrise, former ses équipes, documenter ses architectures. C'est là qu'il faut concentrer l'effort. Parce que le logiciel conditionne directement la portabilité, la résilience et la capacité de sortie de dépendance.

3. CAPEX + compétences = patrimoine

Le modèle OPEX pur vers les hyperscalers américains est une impasse stratégique. Il faut réapprendre à investir, à construire du patrimoine technique, à développer des compétences internes. C'est plus exigeant, mais c'est le seul chemin vers l'autonomie réelle.

Kevin : Et le mot de la fin ?

Sylvain : La souveraineté numérique n'est pas une nostalgie ni une utopie. C'est un projet industriel et politique concret. Les briques techniques existent. Les compétences peuvent se développer. Ce qui manque, c'est la volonté collective de changer de modèle. Cet échange, je l'espère, contribue à montrer que c'est possible.

La question n'est donc plus technique. Elle est désormais essentiellement politique.

Annexe : Glossaire

Annexe : Ressources

Textes de référence

Projets européens

Ressources techniques open source

Hébergeurs qualifiés SecNumCloud (liste non exhaustive)

Article rédigé selon une approche pragmatique de la souveraineté numérique. L'objectif est de fournir une grille d'analyse opérationnelle aux décideurs techniques et stratégiques. Les positions exprimées reflètent l'expérience de terrain des intervenants.