Semaine 6. Quatrième patch. Le bug est revenu — adapté.
Mon agent de code review avait identifié un problème de typage dans un module critique. L'agent de refactoring avait corrigé. L'agent de tests avait validé. Et pourtant, le lendemain, une variante du même bug était réapparue, deux fichiers plus loin, comme si le système avait développé des anticorps contre ma correction.
Je gère une infrastructure de plus de 30 agents IA orchestrés via Claude Code, RAG et pgvector. Chaque agent a un domaine d'expertise : rédaction, audit, tests, maintenance. Pendant cinq semaines, j'ai tenté d'arbitrer leurs divergences. Chaque correction en engendrait une nouvelle. Les agents ne « cassaient » rien — ils optimisaient chacun dans leur direction, et ces directions étaient incompatibles.
Dans cet article, je raconte comment j'ai cessé d'arbitrer mes agents pour les laisser se consulter entre eux — et pourquoi ça a tout changé.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le problème : chaque correction a une parade
Dans un système multi-agent classique, chaque agent a un rôle fixe. L'agent de sécurité pense sécurité. L'agent de performance pense performance. L'agent de qualité pense couverture de tests. C'est le principe même de la spécialisation.
Sauf que la spécialisation crée un biais de domaine. Quand l'agent de sécurité recommande d'ajouter une validation, l'agent de performance la considère comme du overhead inutile. Quand l'agent de performance supprime une abstraction, l'agent de qualité considère que la maintenabilité a été sacrifiée.
Ce n'est pas un bug. C'est un conflit structurel — chaque agent fait exactement ce qu'on lui demande, et c'est précisément le problème.
Concrètement, voici ce que j'observais :
| Semaine | Correction appliquée | Parade de l'agent adjacent |
|---|---|---|
| 1 | Ajout de validation stricte (sécurité) | Suppression « dead code » par le refactorer |
| 2 | Restauration validation + tests | Agent perf optimise en inlinant la logique |
| 3 | Extraction en module dédié | Agent qualité flag le module comme « trop couplé » |
| 4 | Découplage via interface | Agent sécurité flag l'interface comme « surface d'attaque » |
Quatre semaines. Quatre corrections. Quatre parades. Le système revenait toujours à un état de conflit, comme un homéostat dysfonctionnel.
J'ai d'abord pensé que le problème venait de mes prompts. J'ai affiné les instructions, ajouté des contraintes, renforcé les critères d'acceptation. Ça n'a fait qu'empirer : plus les instructions étaient précises, plus chaque agent défendait son territoire avec conviction.
L'insight : les LLM reproduisent les pathologies d'équipe humaines
Le déclic est venu d'une analogie que je n'attendais pas. En observant mes agents diverger, j'ai reconnu un pattern que tout manager a déjà vécu : l'équipe de spécialistes où personne ne regarde le problème dans son ensemble.
Les LLM ne « pensent » pas comme des humains, mais ils se comportent comme des humains quand on les place dans des structures organisationnelles similaires. Donnez un rôle fixe à un LLM, et il développera un biais de confirmation identique à celui d'un expert humain défendant son domaine.
C'est documenté dans la recherche sur les systèmes multi-agents : le taux de succès passe de 99,5 % pour un agent seul à 97 % en multi-agents. Ces 2,5 points semblent négligeables. Sur 127 tâches quotidiennes, ça représente trois à quatre échecs silencieux — exactement ce que je constatais.
Mais le vrai problème n'était pas le taux d'échec. C'était la taxe de coordination : chaque agent optimisant localement sans vision globale, les corrections se neutralisaient mutuellement. Mon arbitrage humain — lire les rapports, trancher, patcher — ajoutait une couche supplémentaire de latence sans résoudre la cause racine.
La cause racine, c'est que l'arbitre a aussi un biais. Quand je tranchais, je favorisais inconsciemment la sécurité (mon background). Un autre développeur aurait favorisé la performance. L'arbitrage humain ne résout pas le biais de domaine — il le déplace.
La solution : le pattern /mutant — roleless et phone-call
J'ai construit /mutant, un orchestrateur qui fonctionne à l'inverse des frameworks multi-agents classiques comme CrewAI ou AutoGen. Son principe fondamental : l'orchestrateur n'a pas de rôle.
Pas de persona « chef de projet ». Pas de domaine d'expertise prédéfini. L'orchestrateur est volontairement « roleless » — un généraliste qui décompose le problème en questions atomiques (maximum 5), puis décide pour chacune s'il peut répondre lui-même ou s'il doit consulter un expert.
C'est le phone-call pattern : « Je connais quelqu'un qui sait. »
Voici comment ça fonctionne :
1. Décomposition atomique. Le problème est découpé en 3 à 5 questions indépendantes. Pas de « fais tout d'un coup » — chaque question a un périmètre précis.
2. Évaluation self vs expert. Pour chaque question, l'orchestrateur évalue s'il peut répondre seul (connaissance généraliste suffisante) ou s'il doit appeler un sous-agent spécialisé. Le critère : la réponse doit être directe, sourcée et actionnable.
3. Phone-call. Si un expert est nécessaire, l'orchestrateur lance un Quick Match domain-aware qui identifie le meilleur sous-agent, envoie la question ciblée, récupère la réponse structurée en JSON.
4. Scoring et CALL-2. Chaque réponse est scorée de 0 à 3 sur trois critères : directe, sourcée, actionnable. Si le score est inférieur à 2, un deuxième appel est lancé vers un expert différent.
5. Synthèse débiaisée. L'orchestrateur reprend sa position « sans rôle » pour la synthèse finale. Il n'a pas de domaine à défendre. Il peut trancher une divergence entre l'agent sécurité et l'agent performance sans biais structurel.
La différence cruciale avec un router statique : le rôle est adopté question par question, pas session par session. L'orchestrateur peut consulter l'agent sécurité sur Q1 et l'agent performance sur Q2, sans que l'un n'influence l'autre.
Résultats concrets : de 4 semaines de ping-pong à 0
Le déploiement de /mutant a produit trois changements mesurables.
Les boucles de correction ont disparu. Le scénario « correction → parade → re-correction » qui durait 4 semaines s'est résolu en un seul cycle. L'orchestrateur roleless identifie les contraintes conflictuelles avant de lancer les corrections, pas après.
La qualité des décisions a augmenté. Le scoring 0-3 avec CALL-2 automatique agit comme un filet de sécurité. Une réponse vague ou biaisée est automatiquement complétée par un second avis. En production, environ 15 % des questions déclenchent un CALL-2 — pile le taux où les experts divergent.
Le coût de coordination a baissé. Paradoxalement, consulter des experts ponctuellement coûte moins cher que maintenir une équipe fixe d'agents permanents. Le pattern phone-call ne charge le contexte que pour la question en cours, alors qu'une équipe fixe maintient le contexte de tous les agents en parallèle.
Métrique |
Avant /mutant | Après /mutant |
|---|---|---|
| Cycles correction moyen | 3–4 par semaine | 0–1 par semaine |
| Divergences non résolues | ~15 % des tâches | < 3 % des tâches |
| Temps de résolution conflits | 45 min (arbitrage humain) | 2 min (synthèse auto) |
| Tokens par orchestration | Élevé (contexte partagé) | Réduit (phone-call ciblé) |
Le cas d'usage le plus parlant : l'analyse cross-domain. Quand une question touche à la fois la sécurité, la performance et la maintenabilité, l'orchestrateur classique échoue parce qu'il doit choisir quel agent « gagne ». Le /mutant ne choisit pas — il consulte les trois, score les réponses, et synthétise sans biais.
Arrêtez d'arbitrer vos agents
Si vos agents IA divergent, le réflexe naturel est de renforcer les règles, d'affiner les prompts, d'ajouter des couches de vérification. C'est exactement ce que j'ai fait pendant cinq semaines — et c'est exactement ce qui ne fonctionnait pas.
Le problème n'est pas que vos agents sont mal configurés. Le problème est que la spécialisation crée mécaniquement des conflits, et qu'aucun arbitrage — humain ou IA — ne peut les résoudre sans introduire son propre biais.
La solution contre-intuitive : un orchestrateur qui ne sait rien mais qui sait qui appeler. Pas de rôle fixe. Pas de biais de domaine. Juste la bonne question, posée au bon expert, au bon moment.
Si vous gérez un système multi-agent et que vous passez votre temps à arbitrer des conflits entre agents, essayez de retirer l'arbitre. Le pattern /mutant est disponible dans mon infrastructure Claude Code — je détaillerai l'implémentation technique dans un prochain article.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.
Mes agents IA se battaient entre eux — j'ai arrêté de les arbitrer