La souveraineté IA n'est pas la résidence des données. Ce sont des mégawatts, de la fibre et de la température au thermomètre mouillé. (1/3)

Ceci est le post 1 sur 3 d'une série sur le papier AI Infrastructure Sovereignty de Sergio Cruzes. La partie 2 couvre la Feasible Sovereign Operating Region ; la partie 3 couvre l'architecture LLM-comme-conseiller.

Il y a quelques semaines, Sergio Cruzes (Ciena) a déposé sur arXiv un papier intitulé AI Infrastructure Sovereignty (2602.10900v4). C'est le genre de papier qui ne devient pas viral sur LinkedIn parce qu'il ne promet à personne un gain de productivité de 10x, mais qui devrait être lu par toute personne signant une "stratégie de souveraineté IA" cette année. Sa thèse centrale est simple et inconfortable : la souveraineté IA n'est plus un problème logiciel ni juridique. C'est un problème d'infrastructure. Les clauses de localisation des données, les régions cloud régionales et la posture RGPD sont nécessaires mais loin d'être suffisantes. La vraie souveraineté vit dans les mégawatts, les routes fibre et la température au thermomètre mouillé à l'extérieur de votre salle serveur.

D'où je travaille — construire du DevOps et de la platform engineering pour des entreprises qui doivent défendre leur stack IA devant un régulateur — ce recadrage est en retard, et la plupart des feuilles de route souveraineté publiques que j'ai revues sur les douze derniers mois opèrent encore une couche trop haut.

Souveraineté juridique vs souveraineté opérationnelle

Le papier introduit une distinction qui devrait devenir vocabulaire standard :

• Souveraineté juridique : la couche que tout le monde comprend déjà : juridiction, conformité, protections de propriété intellectuelle, cadres de localisation des données. RGPD, AI Act européen, CLOUD Act, labels type SecNumCloud. C'est là que vivent les juristes et les achats.
• Souveraineté opérationnelle : "la capacité pratique à observer l'état du système, prendre des décisions basées sur les conditions locales, valider ces décisions, et agir dans des politiques et limites physiques définies." C'est là que vivent les ingénieurs et les opérateurs. Ou plutôt, devraient vivre. Dans la plupart des conversations sur la souveraineté, cette couche est absente.

Les deux couches ne sont pas la même chose, et l'une sans l'autre c'est de la décoration. Un contrôle juridique sans capacité opérationnelle est nominal. Tu peux détenir le contrat, les rapports d'audit et la clause de résidence des données, et dépendre quand même du hardware de quelqu'un d'autre, du réseau optique de quelqu'un d'autre et du PPA de quelqu'un d'autre pour faire effectivement tourner le système. Quand ce quelqu'un d'autre est contraint par des contrôles d'export, des sanctions ou une décision unilatérale de plateforme, ta souveraineté s'évapore quoi que dise le contrat.

C'est la partie que la plupart des conversations sur le "cloud souverain européen" élude élégamment. On discute d'où vivent les octets et on ignore d'où viennent les joules.

Ce que "infrastructure" veut dire concrètement dans le papier

Cruzes est inhabituellement concret pour un papier sur la souveraineté. Les trois couches qu'il traite comme substrat ne sont pas des abstractions :

1. Data centers IA — des racks qui dépassent 20–30 kW (le plafond du refroidissement par air) en passant au liquide en standard. Des clusters d'entraînement qui exigent des dizaines à des centaines de mégawatts par site. De la puissance qui ne dessine pas une courbe plate mais pique pendant les opérations collectives à l'échelle de la milliseconde à la seconde. Rien de tout ça n'est exotique dans le monde hyperscaler ; presque rien de tout ça n'est sous contrôle local dans les clouds souverains européens que j'ai revus.

2. Réseaux optiques — la partie que la plupart des discussions souveraineté centrées logiciel ignorent entièrement. La vitesse de la lumière donne un plancher dur à environ 5 ms par 1 000 km. Les clusters d'entraînement tolèrent environ 1 ms de latence en communication collective, ce qui se traduit par un rayon géographique d'environ 100 km. L'inférence est plus indulgente mais doit quand même se trouver près de la demande. Les câbles sous-marins — ceux qui portent l'essentiel du trafic IA intercontinental — sont "difficiles à réparer. Les interruptions peuvent durer des semaines." La souveraineté d'un chemin fibre n'est pas une clause contractuelle ; c'est le droit de passage physique et le bateau dont tu as besoin pour le réparer.

3. Systèmes énergétiques — capacité du réseau, intensité carbone, eau pour le refroidissement. Le papier propose une Feasible Sovereign Operating Region (FSOR) : l'intersection où la disponibilité énergétique, l'intensité carbone et le budget eau peuvent être satisfaits conjointement. Je reviendrai sur la FSOR dans le prochain post parce qu'elle mérite son propre traitement. Le point ici est structurel : une région sans marge réseau suffisante, avec un mix énergétique fortement carboné ou un stress hydrique saisonnier n'est pas souveraine pour l'IA de frontière quelles que soient la qualité de ses lois sur la protection des données.

Une fois formulé comme ça, tu ne peux pas sérieusement prétendre à la souveraineté pour une charge IA tournant sur des accélérateurs importés, sur un réseau optique opéré par un tiers, tirant son électricité d'un réseau que tu ne contrôles pas, refroidi par de l'eau dont tu ne paies pas le prix. Tu peux revendiquer quelque chose, mais pas la souveraineté au sens opérationnel.

Pourquoi le narratif des régions cloud se casse ici

Si tu prends au sérieux les définitions de Cruzes, le narratif européen dominant sur la souveraineté — "nous aurons des régions cloud souveraines opérées par des entités UE" — résout au maximum une des trois couches, et probablement moins de la moitié de celle-là. Une région souveraine implémentée sur :

• Des accélérateurs importés sous régimes étrangers de contrôle d'export,
• De la capacité optique louée à des opérateurs de transit basés ailleurs,
• Des PPA sans télémétrie opérationnelle dans le réseau,
• De l'eau de refroidissement venant d'un bassin sans gestion locale,

est une région au sens juridique et un locataire au sens opérationnel. Le superviseur acceptera la couche juridique. La physique non.

Je ne dis pas que l'effort sur les régions cloud est faux. Je dis qu'il résout la partie du problème que les juristes peuvent vérifier et laisse intacte la partie avec laquelle les ingénieurs et les opérateurs doivent vivre. La première fois qu'un point de contrôle transfrontalier — sanctions d'export, changement de licence d'un fournisseur de plateforme, panne d'un câble fibre sous-marin — touchera la région, l'écart entre "juridiquement souverain" et "opérationnellement souverain" deviendra la seule chose qui compte.

La couche télémétrie est la vraie couche de souveraineté

L'affirmation technique la plus sous-estimée du papier est celle-ci : la souveraineté opérationnelle dépend de la fusion télémétrique cross-couches, et l'entité qui exécute cette fusion tient les vraies clés.

Aujourd'hui, il existe quatre écosystèmes de protocoles distincts qu'il faut joindre pour produire une représentation d'état unifiée d'un data center IA :

Domaine	Protocoles	Maturité
Réseaux optiques	OpenConfig / gNMI	La plus élevée
Compute / power	Redfish, IPMI, API BMC fournisseurs	Hétérogène
Cooling / facilities	BACnet, Modbus	Niveau facilities, pas temps réel
Durabilité du réseau	WattTime, Electricity Maps (mises à jour ~5 min)	Commercial, externe

Ces quatre n'ont pas été conçus pour se parler. Ils émettent des schémas différents, des cadences différentes, des garanties de fraîcheur différentes. Les joindre en un seul vecteur d'état — que Cruzes appelle θ(t) — n'est pas un travail commodité. C'est le travail qui détermine si tu peux détecter une défaillance en cascade (spike de puissance → événement thermique → migration de charge → congestion réseau) avant qu'elle ne te surprenne, ou si tu la liras dans le post-mortem.

Et voici le coup de poing souveraineté opérationnelle : celui qui possède la couche de fusion télémétrique possède la vraie surface de contrôle. Si tu délègues ce travail à une plateforme externe — la "suite infrastructure IA" d'un hyperscaler, un produit d'observabilité packagé par un fournisseur — tu as délégué la visibilité opérationnelle avec. Ton dashboard dit "tout est vert". Tu ne sais plus ce qui le ferait passer au rouge, dans les conditions de qui, ni avec quelle latence.

Je le dirais plus directement que le papier : la fusion télémétrique est le nouveau système d'enregistrement pour l'infrastructure IA, et la plupart des opérateurs européens n'en ont pas. Ils ont des dashboards construits sur le pipeline de quelqu'un d'autre. Ce qui va très bien jusqu'à ce que ça n'aille plus.

Ce que ça veut dire pour un client régulé cette année

Pour le genre de client avec qui je travaille — banques, santé, énergie, secteur public — traduire ça en posture pratique veut dire abandonner quelques hypothèses confortables et adopter trois inconfortables :

1. Abandonner l'hypothèse que la résidence des données est la conversation souveraineté. C'est la couche la plus facile, celle que ton DPO sait déjà expliquer, et celle qu'un adversaire compétent ou un accident réglementaire contourne le plus vite. Elle a sa place dans la réponse, pas comme réponse entière.

2. Adopter l'hypothèse que tu as besoin d'un inventaire des dépendances physiques. Pour chaque charge IA en production ou planifiée : quels accélérateurs (et sous quel régime d'export), quels chemins optiques (et le droit de passage de qui), quelle source d'énergie (et le PPA de qui), quelle ressource de refroidissement (et les droits sur l'eau de qui). La plupart des équipes ne peuvent pas répondre à ça pour leur stack existante aujourd'hui. Le premier travail c'est l'inventaire, pas l'architecture.

3. Adopter l'hypothèse que la fusion télémétrique est ta responsabilité. Même si tu opères sur le métal de quelqu'un d'autre, tu peux — et en secteur régulé tu devrais — posséder la couche qui fusionne tes signaux opérationnels en une représentation d'état que tu peux raisonner, auditer et présenter à un superviseur sans traduction. Sans ça, tes rapports d'incident seront toujours écrits dans le vocabulaire de ton fournisseur, sur le calendrier de ton fournisseur.

4. Reclasser le système, pas le modèle. Je continue à le dire, y compris dans ma lecture du rapport McKinsey 2026 sur la confiance IA : le régulateur veut le système socio-technique complet classifié, ce qui inclut maintenant explicitement la couche physique. Le dossier de gestion des risques Article 9 pour un système IA à haut risque qui ne reconnaît pas les dépendances énergie, optique et refroidissement est incomplet selon la logique propre du papier.

5. Accepter que la souveraineté est un spectre, pas un binaire. Cruzes est clair là-dessus : aucune région n'atteint la souveraineté absolue. Toutes existent quelque part sur une courbe définie par quelles couches sont contrôlées localement et quelles dépendances externes sont acceptées. La feuille de route souveraineté honnête est celle qui nomme les dépendances et les chiffre, pas celle qui prétend les supprimer toutes.

La partie où je suis critique du hype IA autour de la souveraineté

Je suis publiquement positif sur les LLM et les systèmes agentiques en production — je les déploie, je facture pour, mes clients paient, mon propre temps est "investi" dedans au sens le plus littéral. Je ne suis pas la personne qu'il faut convaincre que l'IA est réelle.

Cela dit, le discours public sur la souveraineté IA aujourd'hui a un mode d'échec spécifique que le papier rend lisible : il traite la souveraineté comme un problème de contenu et non comme un problème de substrat. Le pitch c'est "tes données restent dans le pays", et le corollaire non dit c'est "tout ce qui est sous tes données est le problème de quelqu'un d'autre". Cruzes montre que le substrat n'est pas le problème de quelqu'un d'autre ; c'est le problème, parce que le substrat est ce qu'un acteur externe peut effectivement retirer.

La version hype de l'IA souveraine est un modèle entraîné sur des données locales, hébergé dans une région cloud locale, marketé sous un drapeau local, tournant sur le même silicium importé et la même capacité optique longue distance que la stack de tout le monde. La version du papier de l'IA souveraine, c'est le même modèle, mais avec la question sous quelles contraintes physiques puis-je continuer à opérer si mes dépendances externes sont révoquées ? honnêtement répondue. La première version est une slide. La seconde est un runbook.

Si ton programme de souveraineté peut répondre à la slide et ne peut pas répondre au runbook, tu es exactement là où le reste de l'industrie est. Le travail de cette année c'est d'inverser ces deux états.

Ce que je mettrais sur la feuille de route plateforme ce trimestre

Pour une équipe plateforme ou infrastructure dans un secteur régulé, trois mouvements concrets avant la prochaine mise à jour du board :

1. Cartographier la stack de dépendances physiques pour chaque charge IA en production. Un tableau, quatre colonnes : famille d'accélérateurs + régime réglementaire, chemin optique + opérateur, source d'énergie + termes du PPA, ressource de refroidissement + gestion locale. Le tableau ne sera pas joli. C'est le point.

2. Démarrer un baseline de fusion télémétrique, même rugueux. Prends une seule charge, tire OpenConfig de ta couche optique, Redfish du compute, ce que tu peux obtenir des facilities, et un feed commercial d'intensité carbone. Construis un θ(t) à résolution 60 secondes pour cette charge. Tu découvriras une quantité gênante d'inconnues inconnues. C'est la valeur de l'exercice.

3. Rédiger un memo souveraineté d'une page qui distingue souveraineté juridique et opérationnelle pour ton CFO et ton superviseur. Même si tout ce que tu peux livrer ce trimestre c'est la colonne juridique, posséder le vocabulaire garde la conversation au board honnête. Je préfère arriver à une réunion superviseur en disant "nous contrôlons les couches 1 et 2, nous dépendons du fournisseur X pour les couches 3 et 4, voici le plan de contingence" plutôt que d'arriver en revendiquant une souveraineté que je n'ai pas.

La ligne que je trace

Le cadrage du papier — juridique vs opérationnel, avec la physique comme contrainte liante — est le bon à tenir en interne même quand la version marketing de la souveraineté est celle qui se cite en externe. L'IA est réelle, le déploiement accélère, la valeur est authentique. Rien de tout ça ne change le fait que la couche où la souveraineté se décide vraiment s'est déplacée sous le vocabulaire actuel de la majorité de l'industrie.

Si ton programme de souveraineté cette année se termine encore à la clause de résidence des données, tu n'as pas tort. Tu es juste une couche trop haut. Le travail intéressant — et celui qui intéressera un régulateur dans les douze prochains mois — se passe sous ton dashboard.

---

Sources :

• Sergio Cruzes (Ciena Corporation), AI Infrastructure Sovereignty, arXiv:2602.10900v4, avril 2026. arxiv.org

Tu construis une infrastructure IA qui doit se défendre devant un régulateur et tu n'es pas sûr où ton programme de souveraineté se termine vraiment ? Parle à un CTO — on t'aide à séparer la couche juridique de l'opérationnelle avant que quelqu'un d'autre ne le fasse pour toi.