Cinq agents fiables à 90 % ne font pas un système fiable à 90 %. Ils font 59 %.

Il existe une arithmétique que peu d'équipes techniques posent clairement avant de mettre des agents en production. Un agent fiable à 90 %, pris isolément, semble excellent. Mais enchaînez-en cinq en série, chacun à 90 %, et la probabilité de succès de la chaîne complète tombe à 0,9⁵, soit environ 59 %. La fiabilité des systèmes agentiques est multiplicative, pas additive : elle se compose à la baisse. Ce calcul n'est qu'une illustration : un système réel n'aligne pas mécaniquement des maillons indépendants, et des architectures multi-agents bien orchestrées savent au contraire maintenir la précision. Mais l'ordre de grandeur porte une vérité que le décideur doit intérioriser : la fiabilité d'une chaîne ne se déduit pas de la fiabilité de ses maillons. C'est la raison, souvent mal formulée, pour laquelle « ça marchait dans la démo » se transforme si régulièrement en « c'est ingérable en production ».

Cet article traite de la réponse à ce problème : le plan de contrôle IA. Il prolonge directement deux concepts que SFEIR place au cœur de son cycle, le Loop Engineering (qui conçoit la boucle pilotant un agent) et le Compound Engineering (qui fait apprendre le système à chaque cycle), en les portant à l'échelle d'une flotte gouvernée. Là où le Loop Engineering conçoit une boucle avec sa preuve et sa condition d'arrêt, la gouvernance conçoit le système qui garantit que des centaines de boucles restent fiables, traçables et économiquement soutenables. C'est la face « gouvernance » du socle que nous décrivons dans notre article sur le SDLC IA et le Platform Engineering : une fois la plateforme en place, encore faut-il piloter ce qui tourne dessus.

La gouvernance probabiliste : pourquoi « done » ne suffit pas

Le SDLC augmenté pose déjà le bon principe, au niveau d'une boucle : une boucle qui se déclare « terminée » n'a rien prouvé. On ne croit pas un agent sur parole quand il affirme que les tests passent : on capture la sortie d'exécution réelle. C'est la discipline de preuve, et elle vaut pour un agent. La gouvernance probabiliste ne fait que généraliser ce principe à l'échelle d'une flotte entière : ce qui était une règle par boucle devient une propriété de système.

Le cœur de cette discipline est ce que l'éditeur Arthur AI appelle l'Agent Development Flywheel (le volant d'inertie du développement d'agents) au centre de son cycle de développement d'agents (Industrie · Arthur AI). Son principe : avec l'IA agentique, atteindre un état « fonctionnellement complet » est rapide ; passer de « fonctionnel » à « fiable » est là où réside la totalité du travail. Et ce travail tourne en quatre temps qui s'enchaînent en boucle. On observe le comportement réel (usage en production et simulations) via le tracing, la trace fine de chaque décision. On identifie les anomalies et les modes de défaillance. On enrichit les suites d'évaluations, les evals, en transformant chaque échec de production en cas de test. Puis on expérimente un correctif et on le verrouille par une régression, pour qu'il le reste. Le volant est lancé : chaque tour rend le suivant plus sûr.

On reconnaît là une parenté profonde avec le Compound Engineering de SFEIR et sa formule : un bug vu deux fois n'est pas un bug, c'est un trou dans le système. La boucle d'évals est exactement le mécanisme qui transforme une leçon runtime en règle automatique, le pendant, côté comportement des agents, de ce que le Compound-2 fait côté code. La différence d'échelle est le seul écart : là où le Compound capitalise les leçons d'un projet, la gouvernance probabiliste capitalise celles d'une flotte tout entière, sur chaque interaction qu'elle produit.

Évals supervisées, non supervisées, et quatre contrôles automatisés

Encore faut-il savoir quoi mesurer, car toutes les évaluations ne se valent pas. Arthur AI distingue deux familles, et la distinction est décisive (Industrie · Arthur AI). Les évals supervisées exigent une réponse de référence connue à l'avance : l'équivalence sémantique attendue d'une requête SQL, la séquence d'outils correcte pour une tâche donnée. Elles sont précises mais coûteuses à constituer, et ne couvrent que ce qu'on a pensé à annoter. Les évals non supervisées, elles, évaluent le comportement à partir du seul contexte dont l'agent disposait, sans réponse attendue, ce qui permet de les faire tourner sur chaque interaction en production, et pas seulement sur un jeu de test figé.

Quatre contrôles non supervisés forment le socle recommandé, à exécuter en verdict binaire : passe ou échoue. Le premier traque l'hallucination : l'agent a-t-il énoncé des faits que son contexte n'étayait pas ? Le deuxième vérifie la complétude de la réponse : a-t-il traité tous les aspects de la question, ou seulement le plus facile ? Le troisième mesure l'adhérence thématique : est-il resté dans le périmètre que son prompt système lui assignait, ou a-t-il dérivé ? Le quatrième contrôle l'exactitude de l'objectif : a-t-il appelé les bons outils pour satisfaire l'intention réelle de l'utilisateur, et pas une intention voisine qu'il aurait devinée de travers ?

Pour un responsable de plateforme, ces quatre contrôles sont, côté comportement agentique, l'exact équivalent de ce que sont les tests unitaires côté code : le filet minimal sans lequel toute mise à l'échelle est aveugle. On ne déploierait pas dix mille lignes de code sans tests ; on ne devrait pas déployer une flotte d'agents sans ces quatre évals qui tournent en continu.

Le plan de contrôle centralisé : une passerelle unifiée

Reste une question d'architecture, et c'est peut-être la plus structurante. La gouvernance ne peut pas vivre dans chaque agent. Si chaque agent porte ses propres garde-fous, ils divergeront, vieilliront à des rythmes différents, et le premier agent mal configuré ouvrira la brèche. La gouvernance doit être structurellement hors des agents, dans une couche de supervision indépendante : un plan de contrôle IA, ou passerelle unifiée. C'est l'approche que défend un éditeur comme TrueFoundry : sans passerelle unique, chaque agent devient son propre hub d'intégration, gérant ses identifiants et ses connexions dans son coin, et la Shadow AI se répand mécaniquement (Industrie · TrueFoundry).

Une passerelle unifiée bien conçue centralise ce qu'on ne peut pas se permettre de disperser. Elle assure le routage multi-modèles et le fallback : l'autorité sur de nombreux fournisseurs sans réécrire la logique applicative à chaque changement. Elle porte l'authentification, le RBAC et le scoping des permissions par identité d'agent, pas par comptes de service partagés dans lesquels toute traçabilité se dissout. Elle fournit l'observabilité au niveau de la trace : chaque étape, chaque appel d'outil, chaque décision, avec l'attribution des coûts qui va avec. Et elle applique les garde-fous en entrée comme en sortie : détection d'injection de prompt et masquage des données personnelles avant que la requête n'atteigne le modèle ; détection de toxicité, de fuite de données et d'hallucination après que la réponse en revient.

Dans cette couche de connexion, un standard s'est imposé : le MCP (Model Context Protocol). Créé par Anthropic en novembre 2024, il a été confié en décembre 2025 à l'Agentic AI Foundation, lancée sous l'égide de la Linux Foundation avec Anthropic, Block et OpenAI parmi les cofondateurs (Industrie · Agentic AI Foundation). Il standardise la connexion entre agents et outils d'entreprise : un « USB-C pour l'IA », selon la formule consacrée. Mais il faut être lucide sur ce qu'un protocole garantit et ne garantit pas : MCP est neutre en matière de sécurité. Sa gouvernance dépend entièrement de son implémentation. Les risques identifiés sont réels : serveurs MCP compromis, injections glissées dans les descriptions d'outils, escalade de privilèges, attaques dites « rug pull » où un serveur de confiance change de comportement après coup. Ils imposent une MCP gateway centralisée : inventaire des serveurs autorisés, revue de sécurité avant tout déploiement, moindre privilège systématique, OAuth granulaire et journalisation. Le protocole ouvre la porte ; c'est la passerelle qui décide qui la franchit.

Le FinOps des tokens : la dérive financière silencieuse

Le troisième pilier du plan de contrôle est économique, pas technique, et il surprend souvent les organisations qui l'ont négligé. Contrairement au cloud classique, où le coût s'adosse à des ressources provisionnées (CPU, mémoire, stockage) et évolue de façon quasi linéaire, l'économie de l'IA générative est asymétrique : on paie à l'usage, mesuré en tokens. Cette asymétrie a une conséquence redoutable. Une dépense de tokens qui pèse quelques milliers d'euros par mois en pilote peut se composer, en production, en un ordre de grandeur bien supérieur, sans qu'aucune décision unique ne déclenche jamais cette hausse. Elle s'accumule silencieusement, à travers des dizaines de features et d'équipes qui grossissent en parallèle. C'est le fameux bill shock : la facture qui atterrit un matin sur le bureau du directeur financier sans que personne ne l'ait vue venir.

Une discipline émerge pour maîtriser cela : le LLM FinOps, parfois appelé TokenOps : l'application des principes FinOps (visibilité, allocation, optimisation, gouvernance) à la consommation de tokens. Ses leviers sont désormais bien identifiés. Le model routing consiste à router les tâches simples vers des modèles moins chers plutôt que d'envoyer systématiquement tout au modèle le plus puissant. Le prompt caching met en cache les entrées répétées, avec des économies substantielles sur tout ce qui se redemande à l'identique. Le caching sémantique va plus loin en réutilisant les réponses à des questions proches, réduisant d'autant les appels au modèle. Et le structured output, couplé au contrôle de la longueur, exploite un fait comptable simple : la sortie coûte plus cher que l'entrée, donc raccourcir et cadrer les réponses paie directement.

Un point de vigilance distingue toutefois ce FinOps-ci de son cousin cloud. Réduire du compute ne dégrade pas la qualité d'un calcul ; réduire agressivement les tokens peut dégrader la qualité de sortie. Chaque optimisation doit donc être validée par une mesure de qualité, ce qui reboucle directement sur les évals de la section précédente. On n'optimise pas le coût contre la fiabilité ; on optimise le coût sous contrainte de fiabilité, et c'est la boucle d'évals qui tient la contrainte. La discipline s'institutionnalise du reste rapidement : la Tokenomics Foundation, annoncée le 3 juin 2026 par la Linux Foundation en partenariat avec la FinOps Foundation puis présentée à FinOps X (San Diego, 8-10 juin 2026), a précisément pour objet la gestion du coût des tokens à l'échelle (Industrie · Tokenomics Foundation). Son constat, résumé par J.R. Storment (FinOps Foundation), tient en une phrase : le coût et l'efficience des tokens sont devenus une préoccupation de niveau PDG, pas une note de bas de page d'ingénierie (Industrie · Tokenomics Foundation). C'est exactement la thèse que SFEIR défend sur le coût de l'agentic coding et, plus largement, dans son cadre FinOps : le bon indicateur n'est ni la vitesse ni le volume de code, mais le coût total rapporté à la valeur créée.

Sécurité, PII, et l'architecte de la force de travail numérique

Le dernier pilier est la sécurité, et il faut en mesurer l'ampleur. L'interface conversationnelle d'un agent masque une surface d'attaque très large : derrière une simple consigne en langage naturel, l'agent peut manipuler des fichiers, suivre des liens, appeler des extensions et combiner plusieurs outils dans une même chaîne d'action. Ce qui ressemble à un chat est en réalité un exécutant doté de mains. Les garde-fous doivent donc être architecturaux, pas cosmétiques : moindre privilège par défaut, approbations explicites pour les actions sensibles, exécution en sandbox, contrôle strict des extensions autorisées, traçabilité de bout en bout, et masquage des données personnelles intégré à la passerelle plutôt que laissé à la bonne volonté de chaque agent. Sur les vecteurs propres au contexte (injection, exfiltration, empoisonnement de la mémoire), nous renvoyons à notre article dédié : le contexte des agents est une surface d'attaque à part entière.

Ce déplacement transforme le métier même de l'ingénieur de plateforme. Il ne provisionne plus seulement des environnements : il devient l'architecte de la force de travail numérique : celui qui définit les rôles, les permissions, les golden paths et les critères de fiabilité d'une flotte d'agents. C'est exactement le prolongement, à l'échelle organisationnelle, de la thèse du Loop Engineering : on cesse de prompter les agents un par un pour concevoir et gouverner les boucles qui les pilotent. Le développeur augmenté d'hier devient, à ce niveau, un concepteur de systèmes autonomes sous contrainte. La compétence rare n'est plus d'écrire le meilleur prompt ; c'est de dessiner le système qui rend mille boucles fiables.

Par où commencer : quatre contrôles, une passerelle, un budget

Comment démarrer sans se noyer ? Trois chantiers, dans cet ordre de priorité, suffisent à poser le plan de contrôle.

Le premier est le moins coûteux et le plus rentable : installer les quatre contrôles d'évals non supervisés (hallucination, complétude, adhérence, exactitude de l'objectif) sur chaque interaction en production. C'est le filet minimal, et il tourne dès le premier jour sans jeu de test à annoter. Le deuxième est structurel : faire passer tout le trafic agentique par une passerelle unifiée, pour que l'identité, le scoping, l'observabilité et les garde-fous vivent en un seul lieu gouvernable plutôt que dispersés dans chaque agent, MCP gateway comprise pour la connexion aux outils. Le troisième est financier : rendre le coût en tokens visible et alloué avant de chercher à le réduire, puis n'optimiser qu'en validant chaque gain par une mesure de qualité. On gouverne ce qu'on voit ; le FinOps commence par la visibilité, pas par la coupe.

Le point de vue de SFEIR sur ce terrain est cohérent avec sa doctrine : la fiabilité ne se déclare pas, elle se prouve. À l'échelle d'une flotte, la preuve prend la forme d'évals continues, d'une trace interrogeable et d'un budget maîtrisé. C'est la même exigence que celle du gate de validation dans le SDLC augmenté, portée du cycle unique à la flotte. La stratégie Software Factory 10x ne tient pas malgré cette gouvernance : elle tient grâce à elle.

La gouvernance est la condition du 10x

Le facteur 10x promis par le SDLC augmenté n'est atteignable que si la fiabilité tient à l'échelle. Or la fiabilité des chaînes d'agents est multiplicative : sans plan de contrôle, elle s'effondre, exactement comme le suggérait notre arithmétique du début. Les quatre piliers de ce plan (la gouvernance probabiliste par les évals, la passerelle unifiée pour l'identité et la connexion, le FinOps des tokens, la sécurité et le masquage des données) sont les fondations qui permettent au Loop Engineering et au Compound Engineering de fonctionner au-delà du pilote, là où la démo cède la place à la production.

Ce qui nous ramène aux 59 % du titre. Cinq agents à 90 % ne font pas un système à 90 %, sauf si un plan de contrôle rattrape, à chaque maillon, ce que la chaîne perd. En 2026, la question qui sépare les organisations n'est plus « nos agents marchent-ils ? » (ils marchent). Elle est : « notre système sait-il les gouverner ? » La réponse à cette question-là ne se lit pas dans une démo. Elle se lit dans les évals qui tournent, la trace qu'on peut interroger, et la facture qu'on a vue venir.

Sources

1. Arthur AI, Introducing The Agent Development Lifecycle (ADLC) (l'Agent Development Flywheel : usage réel & simulé → modes de défaillance → enrichissement des évals → expérimentation) — arthur.ai, 3 novembre 2025.
2. Arthur AI, Best Practices for Building Agents, Part 3 — Continuous Evaluations (évals supervisées vs non supervisées ; les quatre contrôles : hallucination, complétude de la réponse, adhérence thématique, exactitude de l'objectif) — arthur.ai, 4 mars 2026.
3. TrueFoundry, Introducing Agent Gateway: A Unified Control Plane for Enterprise AI Agents — truefoundry.com, 28 mai 2026.
4. Linux Foundation, Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF) (MCP, goose et AGENTS.md en contributions fondatrices ; Anthropic, Block et OpenAI parmi les cofondateurs) — linuxfoundation.org, 9 décembre 2025.
5. Linux Foundation, Linux Foundation Announces the Intent to Launch the Tokenomics Foundation (avec la FinOps Foundation, présentée à FinOps X ; citation de J.R. Storment : « Token costs and efficiency have become a CEO-level concern, not an engineering footnote ») — linuxfoundation.org, 3 juin 2026.