L'agent orchestrateur universel est une impasse : maître-serviteur

Un agent unique, censé tout comprendre et tout piloter, paraît la voie royale vers l'automatisation. C'est en réalité la manière la plus sûre de concentrer la complexité, le coût et le risque en un seul point — et ce point est probabiliste.

Quand un premier agent rend service, la pente est naturelle : on lui ajoute un outil, puis dix, puis un domaine, puis un autre. On vise l'agent qui sait tout faire. À mesure que son champ grandit, pourtant, ses décisions deviennent opaques, son contexte enfle, sa maintenance se fragilise. L'agent orchestrateur universel n'est pas une cible à atteindre : c'est une impasse à éviter.

Pourquoi le tout-en-un se dégrade

Le problème n'est pas que l'agent soit « gros ». C'est qu'il concentre trop de variabilité — métier, technique, opérationnelle — dans un même point de décision probabiliste. Trois symptômes le trahissent :

• Surcharge de contexte. Exposer un catalogue d'outils trop vaste dégrade la précision : au-delà de quelques fonctions, le modèle sélectionne moins bien, hallucine des paramètres, et le coût d'inférence grimpe. Plus on lui en donne, moins il choisit juste.
• Opacité croissante. Plus l'agent embrasse de règles locales, moins ses décisions sont explicables. L'observabilité baisse à mesure que les usages augmentent — l'inverse de ce que l'on veut en exploitation.
• Instabilité systémique. Un agent omnipotent est impossible à tester exhaustivement et difficile à protéger contre les injections de prompt indirectes : toute donnée qu'il lit peut devenir une instruction.

Un signal simple : si un agent doit connaître trop de règles métier locales, son périmètre est déjà trop large. Si une capacité est critique, répétable ou testable, elle doit sortir de l'agent généraliste.

La sortie n'est pas « moins d'orchestration »

L'erreur serait d'en conclure qu'il faut renoncer à coordonner. Ce qu'il faut jeter, ce n'est pas l'orchestration, c'est la concentration. La réponse robuste est une orchestration sobre, qui sépare la coordination de l'exécution : le pattern maître ↔ serviteur.

Le maître ne fait pas le travail

Dans ce modèle, un agent maître ne réalise pas les tâches : il les découpe et route chaque sous-tâche vers un serviteur spécialisé et jetable — un mandat précis, un périmètre d'outils mince, isolé du reste. Le maître se réserve trois rôles que le serviteur n'a pas :

• orchestration — séquencer ou paralléliser les sous-tâches et gérer leurs dépendances ;
• validation — contrôler le livrable de chaque serviteur avant de l'intégrer ; un résultat probabiliste non vérifié n'est pas un résultat ;
• consolidation — agréger, dédupliquer et synthétiser les livrables partiels en un tout cohérent.

Ce qui change face au tout-en-un est net. Le contexte de chaque serviteur reste mince — un mandat, pas tout le SI — donc sa précision reste haute. Le maître reste léger : il coordonne et juge, il n'accumule pas les règles locales. Et chaque serviteur est isolé et remplaçable : une panne ou une dérive locale ne contamine pas l'ensemble.

La validation transforme le probabiliste en gouverné

C'est le point le plus important. Sans contrôle, une chaîne d'agents est une chaîne de paris : chaque serviteur peut se tromper, et les erreurs se composent. La validation par le maître intercale un point de contrôle entre la production et l'intégration : on transforme une suite de décisions probabilistes en un résultat gouverné. C'est aussi là que s'insère naturellement l'escalade humaine — quand un livrable ne passe pas le contrôle, on remonte, on ne propage pas.

Décider qui appelle qui, qui valide quoi, n'est pas un détail : c'est de l'architecture de dépendances, avec les mêmes pièges qu'ailleurs (voir Le sens des dépendances : qui doit connaître qui ?). Le maître connaît ses serviteurs ; l'inverse n'a pas à être vrai.

Cette architecture n'est pas une vue de l'esprit : elle est au cœur d'un débat industriel vif. En juin 2025, Cognition publie un essai au titre sans ambiguïté — ne construisez pas de systèmes multi-agents — et Anthropic répond le lendemain avec le récit d'un système multi-agents qui dépasse de 90 % l'agent seul. Le détail réconcilie les deux camps. Dans le système d'Anthropic, chaque sous-agent reçoit une tâche autonome et un contexte frais, ignore l'existence des autres et ne se coordonne pas en cours de route — exactement le serviteur isolé décrit ici. Et la leçon que Cognition retient finalement rejoint la nôtre : des agents peuvent apporter l'intelligence à condition que les écritures restent mono-thread, c'est-à-dire validées et consolidées en un seul point. Le maître.

Spécialiser, puis figer

Le pattern maître ↔ serviteur garde l'agent là où il est utile — l'ambiguïté, le cadrage, l'imprévu — et en sort tout ce qui est devenu stable. Or une fois qu'un serviteur fait toujours la même chose de la même manière, une autre question se pose : a-t-il encore besoin d'être un agent ? C'est le dernier mouvement de la série.