La Feasible Sovereign Operating Region : pourquoi ta feuille de route IA va se cogner à un mur énergie–carbone–eau (2/3)

Ceci est le post 2 sur 3 d'une série sur le papier AI Infrastructure Sovereignty de Sergio Cruzes. La partie 1 cadrait pourquoi la souveraineté est de l'infrastructure, pas de la résidence des données ; la partie 3 couvre l'architecture LLM-comme-conseiller.

L'idée la plus utile dans le papier de Sergio Cruzes AI Infrastructure Sovereignty est une que je n'ai vue nommée explicitement nulle part ailleurs : la Feasible Sovereign Operating Region (FSOR). L'intersection dans laquelle trois limites physiques dures peuvent être satisfaites conjointement, pas une à la fois :

1. Énergie — capacité du réseau et fluctuations rapides que les charges IA y injectent.
2. Intensité carbone — le mix en direct du réseau qui alimente le site.
3. Eau — disponibilité de refroidissement sous stress saisonnier.

La plupart des feuilles de route IA que j'ai revues sur les douze derniers mois optimisent une des trois et présupposent silencieusement les deux autres. Elles ne composent pas. La FSOR est la partie du plan où elles doivent.

C'est un suivi de l'article la-souveraineté-n'est-pas-la-résidence-des-données. Si l'article précédent soutenait que la vraie souveraineté vit dans l'infrastructure physique, celui-ci porte sur ce qui se passe quand tu essaies vraiment d'opérer dans cette infrastructure physique sous les contraintes que le papier rend explicites.

Les trois limites ne sont pas indépendantes — c'est tout l'enjeu

La durabilité IA a historiquement été reportée comme trois KPI séparés : PUE pour l'efficacité énergétique, gCO₂eq/kWh pour le carbone du réseau, WUE pour l'eau. Trois nombres, trois équipes, trois rapports trimestriels. La contribution du papier est d'insister que ce sont un seul problème de faisabilité joint, pas trois additifs.

Un site de cluster d'entraînement est opérable à un moment donné seulement si les trois suivantes sont simultanément vraies :

• Le réseau a la marge de puissance pour absorber le profil bursty de la charge, y compris les spikes milliseconde-à-seconde pendant les opérations collectives.
• L'intensité carbone en direct de ce réseau est à l'intérieur de l'enveloppe politique à laquelle tu t'es engagé (ou celle qu'un régulateur durabilité acceptera).
• Le budget eau local — wet-bulb ambiant, réserves du bassin, variation saisonnière — supporte la charge de refroidissement à la densité de puissance requise.

Retire une seule d'entre elles, et le cluster n'opère pas dans la FSOR ; il opère hors politique et accumule une dette future — financière, réglementaire ou réputationnelle. Les trois contraintes peuvent être en tension sur le même site :

• Une région avec de l'énergie bas carbone abondante peut avoir une capacité réseau insuffisante pour absorber 100+ MW de charge bursty sans déstabiliser le réseau local.
• Une région avec eau et capacité réseau abondantes peut avoir un mix fortement carboné qui pousse la charge hors de son enveloppe durabilité déclarée.
• Une région avec énergie propre et eau adéquate peut se trouver sur un chemin fibre avec des dépendances de latence ou d'opérateur qui rendent la charge inadmissible de toute façon.

La FSOR est l'intersection. Elle est souvent plus petite que ce que chacun de ses ensembles constitutifs suggère, et la plupart des opérateurs ne l'ont pas effectivement calculée.

Pourquoi l'entraînement est le cas le plus dur

Le papier propose une classification des charges qui devrait être sur le mur de toute équipe plateforme :

Charge	Profil de puissance	Demande de refroidissement	Demande réseau	Portabilité
Entraînement	Bursty, élevé	Extrême	Très élevée	Faible
Inférence	Soutenu	Modérée–élevée	Élevée	Moyenne
Batch analytics	Variable	Modérée	Faible–modérée	Élevée

La colonne tueuse c'est la portabilité. Les clusters d'entraînement ne peuvent pas exploiter des sites distants bas-carbone pour une raison structurelle — la latence de communication collective. La vitesse de la lumière fixe le plancher : ~5 ms par 1 000 km. L'entraînement tolère grossièrement 1 ms de latence en communication collective, ce qui réduit le rayon géographique à environ 100 km. À 100 km, tu prends le mix énergétique, la situation de l'eau et la marge réseau que tu trouves, ou tu n'entraînes pas.

C'est la partie du discours sur la durabilité IA où ça commence à faire mal. L'histoire "on va déplacer notre entraînement là où l'énergie est la plus verte" est une slide, pas une architecture. Le papier le dit clairement : l'entraînement IA de frontière est intrinsèquement lié au site et concentré dans les quelques endroits qui satisfont les trois contraintes FSOR simultanément. C'est pourquoi la capacité d'entraînement réelle dans le monde se concentre sur un petit ensemble de géographies ; ce n'est pas la préférence de l'industrie, c'est la FSOR qui fait son travail.

L'inférence est plus indulgente — réplicable à travers les régions, mais quand même liée à la géographie de la demande. Batch analytics est la seule catégorie où une relocalisation carbon-aware est effectivement réalisable à l'échelle. La plupart des démos "IA carbon-aware" dans la nature rebaptisent batch analytics comme la manchette. C'est bien, mais ça n'adresse pas l'entraînement, là où l'impact carbone, eau et réseau vit vraiment.

Là où les feuilles de route européennes craquent en silence

Si tu prends la FSOR au sérieux, plusieurs lignes sur les feuilles de route actuelles d'infrastructure IA européenne cessent de tenir leur propre poids :

• "Localiser l'entraînement en Europe du Nord pour le réseau vert." Partiellement vrai. Le réseau est plus vert ; la marge réseau dans beaucoup de régions cibles est déjà contrainte par la tenancy data center existante et les expansions hyperscalers. Carbone ✓, énergie ✗.
• "Utiliser la capacité solaire sud-européenne pour l'entraînement IA." Disponibilité énergétique parfois ✓ ; budget eau sous conditions wet-bulb estivales souvent ✗. La pénalité de refroidissement en haute saison effondre la FSOR.
• "L'edge IA élimine le problème du data center." Pour l'inférence très à l'edge, parfois. Pour l'entraînement, non. Le papier est explicite là-dessus : l'entraînement est lié au site et ses contraintes ne sont pas résolues par un éclatement edge.
• "Le refroidissement liquide résout le problème de densité." Il résout le plafond du refroidissement par air (le seuil des ~20–30 kW par rack). Il ne résout pas le budget eau ; dans beaucoup de configurations il rend la situation WUE plus lisible, pas meilleure, parce qu'il amène la demande de refroidissement dans un régime qu'il faut mesurer plutôt qu'approximer.

Je ne dis pas ça pour être méprisant — je soutiens chacun de ces programmes en principe. Je le dis parce que la prochaine vague d'incidents opérationnels dans l'infrastructure IA européenne vivra précisément dans l'écart entre l'hypothèse en manchette ("région à énergie propre") et la FSOR jointe ("région à énergie propre qui, en août à 19h00 heure locale, avec la concurrence réseau actuelle, ne peut pas opérer cette charge en politique").

La télémétrie qu'il te faut juste pour connaître ta FSOR

Tu ne peux pas prouver que tu opères à l'intérieur d'une FSOR si tu ne peux pas la mesurer. L'architecture de référence du papier le formule : la fusion télémétrique cross-couches est une précondition, pas un nice-to-have. Pour chacun des trois axes FSOR, l'ensemble minimal de signaux est non trivial :

Axe énergie

• Consommation par rack et la dérivée (pour que tu voies les spikes d'opération collective, pas seulement les moyennes).
• Signal de marge réseau en amont — généralement un feed commercial ou une intégration directe avec l'opérateur.
• Comptabilité PPA temps réel (quelle fraction de la consommation actuelle est effectivement couverte par tes renouvelables contractées vs. spot réseau).

Axe carbone

• Feed d'intensité carbone du réseau en direct (WattTime, Electricity Maps, TSO national). Cadence de mise à jour ~5 minutes.
• Distinction émissions marginales vs. moyennes — la plupart des enveloppes de politique sont écrites en moyennes, mais pour les décisions de workload-shifting, c'est le marginal qui compte.
• Attribution : à quelle entité, entité de facturation ou périmètre réglementaire appartiennent les émissions de quelle charge.

Axe eau

• Températures coolant inlet/outlet, débits.
• Wet-bulb ambiant et une prévision (pour que la FSOR ait une projection prochaines six heures, pas seulement un instantané).
• Signal de gestion du bassin / utility — généralement une intégration externe, souvent pas temps réel.

Dans le langage de mon post précédent, c'est le vecteur d'état θ(t) pour la durabilité. Sans ça, ta FSOR est une devinette. Avec ça, tu as le substrat pour prendre des décisions de scheduling, throttling et migration de manière défendable.

La raison pour laquelle la plupart des équipes plateforme n'ont pas cette couche c'est qu'elle coûte du vrai travail d'ingénierie et ne produit aucune démo. Elle produit un système qui, après trois mois, dit "nous ne pouvons pas opérer la charge X sur ce site entre 17h00 et 23h00 les semaines d'été". C'est un output politiquement inconfortable, ce qui est en partie pourquoi la télémétrie FSOR reste sous-construite.

Ce que la couche agentique est censée faire — et ce qu'elle n'est pas

Cruzes propose une architecture de contrôle dans laquelle l'IA agentique aide à opérer dans la FSOR. Je couvrirai la frontière LLM-vs-agent-déterministe dans le prochain post. Pour la FSOR spécifiquement, l'architecture dit trois choses utiles :

1. L'optimisation respecte la primauté des contraintes. Les limites dures — enveloppes durabilité, physique — ne sont pas des objectifs mous dans la fonction de perte. Elles outrepassent. Un agent qui propose un placement de charge violant le budget eau doit être rejeté par la couche de coordination, pas pénalisé par un terme de régularisation.

2. L'accord cross-domaine est le vrai job. Un agent de placement compute qui choisit le site le plus bas carbone n'a raison que si l'agent cooling, l'agent réseau et l'agent grid sont d'accord que c'est conjointement faisable. L'optimisation mono-domaine est exactement le mode d'échec que la FSOR existe pour prévenir.

3. Validation par jumeau numérique avant exécution. Aucune proposition d'agent ne touche l'infrastructure live tant qu'un jumeau numérique n'a pas simulé contre la dynamique physique. C'est la discipline qui sépare faire tourner de l'IA pour l'infrastructure IA d'une démo d'IA pour l'infrastructure IA.

Le point que je veux extraire ici pour mes clients régulés : l'histoire IA-agentique-sur-data-center n'est pas une histoire d'autonomie. C'est une histoire d'application de contraintes habillée en vocabulaire d'agents. Le travail intéressant c'est de rendre les contraintes lisibles par machine et la validation déterministe, pas de rendre les agents plus malins.

Ce que je critique dans le hype durabilité-IA

Je déploie des LLM et des systèmes agentiques pour gagner ma vie. Je ne vais pas argumenter que la technologie n'est pas utile. Ce que je vais argumenter, c'est que le hype durabilité-IA optimise actuellement la mauvaise couche.

• "L'IA pour l'optimisation du réseau électrique" pitchée comme la réponse alors que l'IA est aussi un moteur majeur du stress réseau. Les deux sont vrais en même temps. La seconde phrase manque dans la plupart des decks.
• La relocalisation entraînement carbon-aware présentée comme un levier court terme. C'est un levier long terme conditionné à la résolution de la contrainte de latence des 100 km, que personne n'a résolue. Le levier court terme c'est batch analytics carbon-aware, qui est réel et utile mais qui n'est pas l'entraînement.
• Le reporting WUE traité comme une case à cocher. Il est bien en tant que nombre ; il devient significatif seulement à l'intérieur d'une FSOR qui le joint aux axes carbone et énergie. Un site avec un excellent WUE sur un réseau fortement carboné dans un bassin sous stress hydrique ne gagne rien ; il déplace l'externalité.
• "Refroidissement liquide = durable" affirmé sans la comptabilité jointe. Le refroidissement liquide est ce qui rend possible des racks >30 kW ; savoir s'il améliore l'empreinte globale dépend entièrement des maths FSOR sur ce site spécifique.

La version honnête de l'IA carbon-aware c'est : pour le petit ensemble de charges à haute portabilité, dans des régions avec une vraie FSOR, on peut décaler la charge de façon à réduire matériellement l'empreinte. C'est de la vraie valeur. C'est aussi une revendication bien plus étroite que la slide.

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

Pour une équipe plateforme qui a lu la section FSOR du papier et veut agir avant le prochain cycle de disclosure durabilité :

1. Construire une carte de portabilité des charges. Pour chaque charge IA, marque sa catégorie (entraînement / inférence / batch / serving) et son budget de portabilité réel — rayon géographique, downtime autorisé pour migration, contraintes de statefulness. Ce seul artefact te dit quelles charges pourraient même être déplacées sur une base FSOR.

2. Calculer la FSOR pour un site. Choisis ton emplacement le plus chargé. Calcule la région faisable jointe sur les trois axes pour les 72 prochaines heures avec la télémétrie que tu peux assembler. Publie ça comme un dashboard interne. Tu découvriras des angles morts immédiatement. C'est la valeur.

3. Définir l'enveloppe de contraintes. Traduis tes politiques carbone, énergie et eau engagées en contraintes lisibles par machine. Si ta politique est "moyenne <X gCO₂/kWh", écris-la comme une fonction de l'heure du jour et de la saison. Les politiques molles qui vivent seulement dans un PDF ne peuvent pas entrer dans la FSOR.

4. Étiqueter les charges par portabilité, pas seulement par tier. L'étiquette de portabilité est ce que ton futur scheduler de workload — agentique ou autre — utilisera pour décider ce qui peut bouger. C'est la précondition pour que le carbon-aware batch shifting soit plus qu'une démo.

5. Traiter la FSOR comme partie du dossier de gestion des risques. Dans un environnement régulé, on te demandera sur les dépendances énergie, carbone et eau des systèmes IA à haut risque dans ce cycle réglementaire. Mieux vaut avoir une analyse FSOR dans le dossier que de l'écrire la semaine de l'audit.

La ligne que je trace

La FSOR n'est pas un nom malin pour ce qu'on fait déjà ; c'est une discipline qu'on ne fait surtout pas encore. Les trois KPI durabilité qu'on reporte trimestriellement ne sont pas testés conjointement en opérations. Le hype autour de l'IA carbon-aware aplatit la distinction de portabilité des charges qui décide si quoi que ce soit est déplaçable. Le discours européen sur la souveraineté prend un des trois axes et présuppose que les deux autres sont le problème de quelqu'un d'autre.

Si tu fais tourner de l'infrastructure IA en 2026 et que la question "quelle est la FSOR pour la charge X au site Y sur les 72 prochaines heures ?" ne peut pas être répondue par ta plateforme depuis un système live en moins de cinq minutes, tu n'as pas encore de FSOR — tu as trois KPI qui se trouvent être reportés sur la même slide.

Le travail est faisable. C'est surtout du travail de télémétrie, de schéma et de politique, avec une petite couche de logique agentique au-dessus. L'équipe qui le fait avant que le cycle réglementaire ne rattrape sera visiblement en avance sur celle qui ne le fait pas.

---

Sources :

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

Tu fais tourner des charges IA avec des engagements durabilité dont tu n'es pas sûr que ton infrastructure puisse vraiment les honorer ? Parle à un CTO — on t'aide à calculer une vraie FSOR avant que le cycle de disclosure ne le fasse pour toi.