← Retour aux articles
Défis

Laisse le LLM parler, pas toucher : l'architecture en boucle fermée qui survit vraiment à la production (3/3)

Par Marc Molas·13 mai 2026·11 min de lecture

Ceci est le post 3 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 2 couvrait la Feasible Sovereign Operating Region.

La troisième pièce du papier de Sergio Cruzes AI Infrastructure Sovereignty qui devrait voyager plus loin qu'elle ne l'a fait est l'endroit où il trace une ligne architecturale dure : dans un système d'infrastructure IA en boucle fermée, les LLM sont conseillers et interprétatifs. Ils n'exécutent pas. L'exécution est le travail d'agents bornés, déterministes, validés par un jumeau numérique, avec deux chemins de feedback strictement séparés.

Je déploie de l'IA agentique dans des environnements régulés pour gagner ma vie. Je suis "investi" dans cette technologie au sens le plus littéralement facturable. Et je pense que l'architecture du papier est la bonne — c'est exactement pourquoi je veux signaler que la plupart des produits vendus comme plateformes agentiques en 2026 la violent silencieusement. Ils placent le LLM plus près de l'actionneur que ce que le design du papier permet, puis ils marketent cette proximité comme la fonctionnalité.

C'est le troisième post sur le papier, après la souveraineté-n'est-pas-la-résidence-des-données et la FSOR. Si ceux-là couvraient ce que tu dois contrôler, celui-ci porte sur comment la boucle de contrôle doit être câblée sans mettre le feu à la salle serveur.

L'architecture de référence à quatre couches, en un paragraphe

Le papier propose quatre couches empilées :

  1. Physique — data centers IA, réseaux optiques, systèmes énergétiques. Le substrat.
  2. Observabilité — normalisation en streaming, alignement de timestamps, certification de fraîcheur, fusion cross-domaine. Produit le vecteur d'état unifié θ(t).
  3. Contrôle coordonné — agents de domaine (compute, power, cooling, optical) + couche de coordination + jumeau numérique + une couche d'assistance LLM.
  4. Exécution sûre — seules les actions validées par le jumeau numérique atteignent l'infrastructure live.

La frontière intéressante est entre 3 et 4. La non-frontière intéressante — celle que la couche hype veut brouiller — est entre l'assistance LLM et tout le reste à l'intérieur de la couche 3.

Ce que Cruzes dit réellement sur les LLM

Le papier est inhabituellement explicite. La couche LLM a un "rôle conseiller et interprétatif uniquement". Elle existe pour :

  • Traduire l'intention humaine en objectifs structurés que les agents déterministes peuvent consommer.
  • Générer des explications de ce que le système agentique a décidé et pourquoi.
  • Être une surface en langage naturel par-dessus le vrai système de contrôle, pas un participant dedans.

Et puis le papier dit la partie tue à haute voix :

Permettre aux sorties LLM de piloter directement des actions infrastructure — sans validation par le constraint-checking déterministe du système agentique et la simulation pré-exécution du jumeau numérique — introduit un mode d'échec dans lequel des instructions plausibles mais incorrectes sont exécutées sur l'infrastructure live.

C'est le mode d'échec LLM-en-production que j'ai personnellement vu dans cinq incident reviews différents sur les dix-huit derniers mois, aucun dans le contrôle de data center mais tous dans des environnements régulés : le LLM produit quelque chose qui ressemble à la bonne commande, le système autour est trop pressé de l'exécuter, et le post-mortem se transforme en un exercice "on a fait confiance à du texte là où on aurait dû faire confiance à la politique". La version data center de cet incident ne serait pas un embarras de slack-bot. Ce serait un événement thermique.

La structure agentique à deux niveaux

À l'intérieur de la couche de contrôle coordonné, le papier sépare :

  • Niveau 1 — agents de domaine. Raisonneurs spécialisés pour placement compute, gestion power, contrôle cooling, routage optique. Chacun a une connaissance codée en dur des contraintes et de la physique de son domaine. Ce sont eux qui font la proposition effective des actions.
  • Niveau 2 — couche de coordination. Vérification de faisabilité jointe sur l'ensemble des propositions du niveau 1. Si compute veut placer une charge sur le site A, mais que l'agent cooling dit que A est hors budget compte tenu du wet-bulb actuel, et que l'agent optical dit que le lien vers A est en mode dégradé, le coordinateur capture la contradiction. Si aucune action conjointement faisable n'existe, il escalade vers les humains plutôt que de choisir silencieusement la moins mauvaise option.

Le LLM n'est pas niveau 1 et n'est pas niveau 2. Le LLM est en dehors de cette boucle. Il explique ce que la boucle a fait. Il accepte l'intention humaine et la reformule en objectif structuré nourri dans la boucle. Il ne place pas de charges. Il ne throttle pas de racks. Il ne reroute pas de chemins optiques.

C'est un design défendable et regulator-friendly. C'est aussi un design que la plupart des plateformes "agentiques" du marché aujourd'hui ne respectent pas, parce que la pression marketing est d'inclure le LLM dans la décision — c'est là que vit la démo coup-de-magie.

Deux chemins de feedback, gardés strictement séparés

Le détail qu'un ingénieur appréciera et qu'un marketeur glissera est la discipline des deux-chemins-de-feedback :

  • Feedback A — les résultats mesurés remontent depuis la couche physique à travers l'observabilité. Ça ferme la boucle de contrôle. Les agents apprennent que l'action qu'ils ont prise a produit (ou pas) le changement d'état attendu.
  • Feedback B — les résidus de prédiction (la différence entre ce que le jumeau numérique attendait et ce qui s'est réellement passé) retournent dans le jumeau numérique uniquement. C'est comme ça que le jumeau détecte sa propre dérive par rapport à la réalité physique.

Le papier insiste pour que ces canaux restent strictement séparés. Confonds-les et tu détruis la détection de dérive. Si le jumeau numérique reçoit le même flux de mesure que la boucle de contrôle agent, sans isolation, alors une dérive lente dans la précision du jumeau ressemblera à une variance opérationnelle normale pour les agents, et tu ne verras pas la dérive jusqu'à ce que le jumeau prenne une décision que le système physique rejette en incident.

C'est le genre de rigueur architecturale qui ne vend pas de licences plateforme mais qui te garde hors d'un post-mortem.

Là où la plupart des plateformes "agentiques" actuelles cassent ça en silence

Je vais généraliser à partir de ce que je vois dans les architectures clients et les démos fournisseurs, sans nommer :

  1. LLM dans le chemin d'action. Le produit vend "un agent qui opère ton infrastructure". Sous le capot, le LLM interprète la requête et émet la commande. Il n'y a pas d'agent niveau 1 déterministe avec des contraintes codées en dur entre le LLM et l'actionneur. C'est le mode d'échec que le papier nomme explicitement.

  2. Jumeau numérique comme actif marketing, pas comme porte de validation. Beaucoup de produits montrent un "jumeau numérique" rendu en 3D dans la démo. Peu d'entre eux exigent que le jumeau valide chaque action proposée avant exécution. Le jumeau est décoratif. Dans l'architecture du papier, le jumeau est une porte ; si la simulation du jumeau diverge de la politique, l'action est bloquée.

  3. Télémétrie en boucle unique. L'agent et le jumeau consomment le même flux sans séparation. Feedback A et B sont confondus, la détection de dérive est peu fiable, et le système perd silencieusement la propriété sur laquelle le papier insiste.

  4. Pas de contrat d'escalade. Quand la couche de coordination ne trouve aucune action conjointement faisable, que se passe-t-il ? Dans le papier, dégradation gracieuse avec escalade structurée vers les humains, qui gardent l'autorité finale. Dans beaucoup de produits, le système choisit juste l'action au moindre coût sous une heuristique de repli et écrit un debug log. Ce n'est pas de la dégradation gracieuse ; c'est de l'échec silencieux avec un système de logs.

  5. Human-on-the-loop comme case à cocher. Un dashboard humain existe ; il est revu chaque semaine. Opérationnellement, les agents ont bougé plus vite que la cadence de revue depuis des mois. C'est la version data center du HITL théâtral que le rapport McKinsey a signalé pour les systèmes agentiques généraux. Même maladie, blast radius plus élevé.

Si ta plateforme rate un seul de ces tests, tu as un système d'infrastructure agentique au sens marketing et une démo aux permissions élevées au sens opérationnel.

Pourquoi je pense que l'architecture du papier est correcte

Trois raisons, tirées de la façon dont ça se joue vraiment chez des clients qui doivent défendre la stack :

1. Le LLM est excellent à la couche où ses erreurs sont récupérables. Traduire "je veux planifier le prochain run d'entraînement quelque part dans notre enveloppe carbone" en objectif structuré est un excellent usage d'un LLM. Si la traduction est fausse, l'objectif structuré rate la validation et la requête revient en erreur. Aucune action physique n'a été prise. Récupérable. Excellent.

2. Le LLM est dangereux à la couche où ses erreurs ne sont pas récupérables. Générer la commande exacte de throttling de rack est le mauvais endroit pour utiliser le LLM, parce que si la commande générée est plausible-mais-fausse et qu'elle s'exécute, le système physique a déjà bougé. Il n'y a pas d'"undo" sur un cycle thermique. La séparation du papier place le LLM exactement là où ses forces atterrissent et le retire de là où ses faiblesses mordent.

3. Vocabulaire en forme de régulateur. Un superviseur dans un secteur régulé va demander, dans toute incident review : qu'est-ce qui a pris la décision, qu'est-ce qui l'a validée, quelle preuve as-tu ? Le design du papier a une réponse propre pour chaque. Le design LLM-dans-le-chemin-d'action a, au mieux, "le modèle a décidé", qui est la réponse qui déclenche les deux prochaines années de remédiation.

Je veux être clair : je suis positif sur les LLM. Je les déploie, j'ai du skin in the game sur l'IA qui fonctionne en production. Je ne fais pas un argument "les LLM ne sont pas fiables, ne les utilisez pas". Je fais un argument de placement : les LLM sont le bon outil à la couche langage naturel et explication, et le mauvais outil à la couche exécution. Le papier formalise le placement vers lequel les bons opérateurs convergeaient déjà informellement.

Ce que ça veut dire pour le reste de l'IA agentique, pas seulement les data centers

Le papier est spécifiquement sur le contrôle d'infrastructure IA, mais l'architecture se généralise proprement à la plupart des déploiements agentiques régulés :

  • Agent bancaire qui traite des paiements. Le LLM traduit l'intention du client. L'agent déterministe avec politique et limites émet le débit réel. Le jumeau numérique (ou des pré-vérifications contre un ledger sandboxé) valide avant commit.
  • Agent de triage en santé. Le LLM médie le dialogue, résume l'historique. L'agent déterministe applique le protocole. Human-in-the-loop sur toute action qui produit un effet clinique.
  • Agent de contrôle industriel. Le LLM explique les setpoints à l'opérateur et accepte les cibles de setpoint en langage naturel. Le contrôleur déterministe bouge effectivement la vanne, après qu'un simulateur a validé que le mouvement ne viole pas les limites de procédé.

Dans les trois, le squelette architectural est le même que celui du data center dans le papier : le LLM ne tient jamais l'actionneur. Il tient l'explication, la surface langage naturel, et la traduction d'intention. La frontière ne bouge pas parce que le régulateur et la physique ne bougent pas.

C'est la même ligne que j'ai tracée dans mes posts proof-carrying deployment et architecture de gouvernance vérifiable, depuis un angle différent. Le papier Cruzes fournit la version infrastructure-physique d'un argument qui converge à travers les secteurs régulés : LLM utile, LLM pas autoritaire, agent déterministe dans le chemin de conséquence.

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

S'il faut traduire ce troisième post en actions pour une équipe plateforme qui fait tourner — ou planifie de faire tourner — de l'IA agentique dans un environnement sérieux :

  1. Cartographier ton graphe d'actions. Pour chaque opération qu'un "agent" peut effectuer, marque quelle couche l'émet : LLM, agent déterministe niveau 1, ou humain. Si le LLM apparaît quelque part dans la colonne exécution, tu as du rework à faire avant que le régulateur ne le fasse pour toi.

  2. Mettre un jumeau numérique devant l'actionneur. Même grossier. Le point n'est pas la fidélité ; le point est la porte. Une action que le jumeau ne peut pas simuler, ou que le jumeau montre violant une contrainte, ne s'exécute pas. Point. Cette seule discipline retire une catégorie d'incidents qui ont l'air catastrophiques dans le post-mortem et triviaux rétrospectivement.

  3. Séparer feedback A et B. Les résultats vont à la boucle de contrôle. Les résidus du jumeau vont au jumeau. Même télémétrie source, deux pipelines, deux politiques de rétention, deux lignes de propriété. C'est du travail infra peu glamour ; c'est aussi le travail qui rend la détection de dérive réelle.

  4. Écrire le contrat d'escalade. Définir ce qui se passe quand aucune action conjointement faisable n'existe. La réponse est humains, avec un handoff clair et un SLA publié sur la réponse. Toute autre chose est un fallback silencieux qui sortira en incident.

  5. Auditer ton fournisseur contre les quatre tests ci-dessus. LLM pas dans le chemin d'action ; jumeau comme vraie porte de validation ; chemins de feedback séparés ; escalade explicite. Toute "plateforme agentique" qui rate deux ou plus de ces tests n'est pas un système regulator-grade ; c'est une démo de productivité aux permissions élevées.

La ligne que je trace — et pourquoi je la tiens

Je suis critique du hype IA agentique actuel non parce que la technologie n'est pas réelle — elle l'est, démontrablement, et je facture pour — mais parce que l'architecture marketée est systématiquement plus proche de l'actionneur que ce que l'architecture d'ingénierie devrait être. Le papier de Cruzes, travaillant dans le domaine opérationnel le plus exigeant disponible (infrastructure IA live sous contraintes physiques jointes), arrive à une discipline qui se traduit proprement dans tout déploiement agentique régulé : les LLM parlent et expliquent. Les agents déterministes proposent. Les coordinateurs vérifient la faisabilité. Les jumeaux numériques valident. Les humains autorisent la politique et possèdent l'escalade. Le système physique ne voit jamais que des actions qui ont franchi les quatre portes précédentes.

La plateforme agentique la plus rapide en 2026 ne sera pas celle dont le LLM se rapproche le plus du métal. Ce sera celle dont le LLM est honnêtement placé là où ses forces vivent, avec le reste de la stack ingéniérié pour absorber ses faiblesses. Cette plateforme ne fera pas la démo coup-de-magie. Elle fera l'audit un mardi d'octobre à 09h30 sans que personne n'ait besoin de prendre sa journée.

C'est le système que je veux continuer à construire. Tout le reste est du théâtre avec permissions.


Sources :

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

Tu mets de l'IA agentique en production et tu n'es pas sûr que ton architecture survivrait à une incident review ? Parle à un CTO — on t'aide à placer le LLM exactement là où ses forces atterrissent et nulle part ailleurs.

Prêt à construire votre équipe d'ingénierie ?

Parlez à un partenaire technique et déployez des développeurs validés par des CTOs en 72 heures.