Délibération multi-agents : quand le consensus est le bug

Le résultat le plus dangereux que produit mon agent IA n’est pas une erreur. Les erreurs sont faciles. Les linters détectent les fautes de syntaxe, les suites de tests détectent les régressions, et les 95 hooks que j’ai construits détectent les except: pass et les force pushes. Le résultat dangereux est une recommandation assurée, bien argumentée, qui se trouve être fausse.

J’ai demandé à un agent unique de vérifier un endpoint API pour des problèmes de sécurité. L’agent a vérifié l’authentification, validé la sanitisation des entrées et vérifié les en-têtes CORS. Bilan de santé impeccable. Un second agent, sollicité séparément en tant que testeur d’intrusion, a découvert que l’endpoint acceptait des paramètres de requête non limités qui pouvaient déclencher un déni de service par amplification des requêtes de base de données. Le premier agent n’a jamais vérifié parce que rien dans son cadre d’évaluation ne traitait la complexité des requêtes comme une surface d’attaque.

Cette lacune est structurelle. Aucune quantité d’ingénierie de prompts ne la corrige, car la limitation ne réside pas dans le prompt. La limitation réside dans le fait qu’une seule perspective évalue un problème multidimensionnel.

J’ai construit un système de délibération multi-agents pour combler cette lacune. Des agents avec différents personas recherchent indépendamment, débattent de leurs conclusions et parviennent à un consensus par vote structuré. Le système exécute 141 tests, impose l’isolation du contexte entre les agents et utilise une architecture de validation à deux portes qui bloque le consensus prématuré.

TL;DR

Les systèmes d’IA mono-agent ont un angle mort structurel : ils ne peuvent pas remettre en question leurs propres hypothèses. Une boucle Ralph exécutant Sonnet produit du code à 10 $/heure, mais chaque angle mort du modèle est déployé au même rythme. La délibération multi-agents impose une évaluation indépendante depuis plusieurs perspectives avant que toute décision ne soit verrouillée. Mon implémentation utilise 10 personas de recherche, une machine à états à 7 phases et deux portes de validation (consensus + pride check) fonctionnant sur les hooks Claude Code. Le système se déclenche sur les décisions à faible confiance (en dessous de 0,70) et ajoute environ 3x le coût en tokens par délibération. Pour les décisions de sécurité, les choix d’architecture et tout ce qui est irréversible, ce coût est rentabilisé dès la première fois qu’il détecte quelque chose qu’un agent unique aurait manqué. Pour les corrections de documentation et les modifications de routine, ignorez entièrement la délibération.

La nuit où mes agents se sont mis d’accord pour tout casser

Février 2026. Un mardi. J’ai demandé à mon agent « d’étudier l’amélioration du système de dispatch des hooks » et je suis allé faire du café. L’agent a évalué sa propre confiance à 0,58 (en dessous du seuil de 0,70), ce qui a déclenché la délibération. Le système a engendré 3 agents de recherche. Chaque agent de recherche a évalué le problème, trouvé des sous-problèmes et engendré ses propres agents de recherche. Ces agents en ont engendré d’autres.

Sept minutes plus tard : 23 processus d’agents actifs. 4,80 $ de crédits API consommés. Le répertoire ~/.claude/state/ se remplissant de fichiers d’état JSON tandis que chaque agent persistait consciencieusement ses résultats. La consommation de tokens grimpant à environ 0,70 $ par minute sans signe de convergence.

La garde de récursion que j’avais construite pour le système de qualité suivait la profondeur (le parent engendre un enfant, l’enfant engendre un petit-enfant) mais pas la largeur (le parent engendre 12 enfants qui engendrent chacun 12 de plus). La limite de profondeur de 3 n’a jamais été déclenchée parce que les agents se propageaient horizontalement. J’ai tué les processus manuellement et j’ai fixé les fichiers d’état.

Chaque agent était d’accord : le système de dispatch des hooks avait besoin d’amélioration. Chaque agent proposait des changements qui semblaient raisonnables. Aucun agent n’a remis en question si l’investigation elle-même était correctement délimitée. Vingt-trois agents parvenant à un consensus sur la mauvaise question.

La correction a pris 20 minutes : un budget d’engendrement qui suit le nombre total d’enfants actifs par parent, plafonné à 12. La leçon plus profonde a pris plus de temps. La courbe d’accélération d’infrastructure que j’avais documentée rendait le système de délibération constructible en 2 semaines, précisément parce que l’infrastructure des hooks existait déjà. Mais une construction rapide n’empêche pas les défaillances structurelles. La progression des pipelines RAG mono-agent vers les systèmes autonomes suit un arc prévisible. La délibération multi-agents se situe à la fin pour une raison : vous ne la construisez qu’après qu’un agent unique ait déployé avec assurance la mauvaise réponse.

Le consensus, pas le désaccord, était le mode de défaillance dangereux.

Anatomie d’une délibération

Le système a deux composants structurels : une machine à états qui séquence le travail et deux portes de validation qui empêchent un mauvais consensus d’être déployé.

La machine à états

Sept phases, chacune conditionnée par la précédente :

IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
                                                                    |
                                                              (or FAILED)

RESEARCH : des agents indépendants étudient le sujet. Chaque agent reçoit un persona différent (Technical Architect, Security Analyst, Performance Engineer, et 7 autres). L’isolation du contexte garantit que les agents ne peuvent pas voir les résultats des autres pendant la recherche. L0 (règles système) et L1 (contexte projet) sont partagés. L2 (focus spécifique à l’agent) est privé. L3 (patterns du domaine) charge les bibliothèques de patterns pertinentes par persona.¹

DELIBERATION : les agents voient tous les résultats de recherche et génèrent des alternatives. L’agent Debate identifie les conflits entre les perspectives. L’agent Synthesis combine les résultats non contradictoires.

RANKING : chaque agent note chaque approche proposée selon 5 dimensions pondérées :

Les scores pondérés s’agrègent en un score de consensus. Le seuil est adaptatif selon la tâche : 0,85 pour les décisions de sécurité, 0,80 pour l’architecture, 0,70 par défaut, 0,65 pour le refactoring, 0,50 pour la documentation.²

Les deux portes

Porte 1 : validation du consensus (hook PostToolUse:Task). Quatre vérifications s’exécutent après chaque complétion d’agent de délibération :

1. La phase doit avoir atteint au moins RANKING
2. Minimum 2 agents complétés (configurable)
3. Le score de consensus atteint le seuil adaptatif à la tâche
4. Si un agent a émis une dissidence, ses préoccupations doivent être documentées

L’échec à l’une de ces vérifications bloque l’avancement de la délibération.³

Porte 2 : Pride Check (hook Stop). Cinq vérifications de qualité s’exécutent avant que la session puisse se clôturer :

1. Méthodes diverses : plusieurs personas uniques représentés
2. Transparence des contradictions : les dissidences ont des raisons documentées
3. Gestion de la complexité : au moins 2 alternatives générées
4. Confiance du consensus : score classifié comme fort (au-dessus de 0,85) ou modéré (0,70-0,84)
5. Preuve d’amélioration : la confiance finale dépasse la confiance initiale

L’architecture à deux portes détecte les problèmes à différentes étapes. La porte 1 empêche la convergence prématurée pendant le processus. La porte 2 empêche le déploiement de résultats qui semblent complets mais manquent de rigueur.

Les analystes du renseignement ont eu ce problème en premier

J’ai construit le système de délibération en janvier 2026. Deux semaines plus tard, j’ai trouvé Psychology of Intelligence Analysis de Richards Heuer sur une liste de lecture consacrée à la prise de décision structurée. Le chapitre 8 décrit l’analyse des hypothèses concurrentes (ACH) : les analystes évaluent les preuves par rapport à plusieurs hypothèses simultanément, plutôt que de construire un dossier en faveur de leur conclusion préférée.⁴

Le parallèle était dérangeant. Le cadre de Heuer, publié en 1999 pour la CIA, traitait la même défaillance structurelle que je déboguais : des personnes intelligentes convergeant vers une seule explication parce qu’elles ne s’étaient jamais forcées à évaluer les alternatives.

Voici à quoi ressemble l’ACH en pratique. Un analyste du renseignement enquêtant sur un programme d’armement suspecté ne demande pas « est-ce un programme d’armement ? » (biais de confirmation). Au lieu de cela, l’analyste liste toutes les hypothèses plausibles (programme d’armement, recherche civile, installation à double usage), évalue chaque élément de preuve par rapport à chaque hypothèse et identifie quelles preuves distinguent le mieux les hypothèses entre elles.

Mon système fait la même chose avec un vocabulaire différent. Trois agents évaluent une modification proposée de schéma de base de données. L’agent A (Technical Architect) écrit : « Le schéma est propre, normalisé en 3NF. » L’agent B (Performance Engineer) écrit : « Les patterns de requêtes nécessiteront des jointures sur 4 tables à chaque lecture. » L’agent C (Security Analyst) écrit : « Les champs PII ne sont pas chiffrés au repos. » Même schéma, trois évaluations différentes, trois éléments de preuve discriminants. La phase de classement évalue l’approche proposée par rapport à ces évaluations indépendantes de la même manière que l’ACH évalue les hypothèses par rapport aux preuves.

Je n’ai pas conçu le système à partir du cadre de Heuer. J’ai réinventé un sous-ensemble de l’ACH par essais et erreurs, puis j’ai découvert que quelqu’un avait déjà écrit le manuel. La version honnête est plus utile que la version flatteuse : arriver indépendamment à la même architecture confirme que le problème sous-jacent est réel, pas théorique.

Pourquoi le consensus est le mode de défaillance dangereux

Charlan Nemeth a étudié la dissidence minoritaire de 1986 à son livre de 2018 In Defense of Troublemakers. Les groupes avec des dissidents prennent de meilleures décisions que les groupes qui parviennent rapidement à un accord. Le dissident n’a pas besoin d’avoir raison. L’acte de désaccord force la majorité à examiner des hypothèses qu’elle aurait autrement ignorées.⁵

James Surowiecki, dans The Wisdom of Crowds, identifie quatre conditions pour des décisions de groupe avisées : la diversité d’opinions, l’indépendance du jugement, la décentralisation et un mécanisme d’agrégation.⁶ Violez l’indépendance (laissez les agents voir le travail des autres pendant la recherche) et vous obtenez du mimétisme. Violez la diversité (utilisez des prompts identiques pour chaque agent) et vous obtenez des chambres d’écho.

J’ai testé directement la condition d’indépendance. Deux agents évaluant la même stratégie de déploiement avec visibilité sur les résultats de l’autre : l’agent A a noté le risque à 0,45. L’agent B a vu ce score et a produit 0,48. Les mêmes agents sans visibilité : 0,45 et 0,72. L’écart entre 0,48 et 0,72 est le coût du mimétisme. L’évaluation indépendante de l’agent B a signalé un risque d’orchestration de conteneurs qui disparaissait lorsque la pression sociale entrait dans l’évaluation.

Des travaux récents confirment que les deux patterns s’appliquent aux agents LLM. Choi et al. à NeurIPS 2025 ont constaté que le vote majoritaire parmi des agents sollicités indépendamment capture la majeure partie des gains de qualité des systèmes multi-agents.⁷ Kaesberg et al. à ACL 2025 ont quantifié la répartition : le vote améliore les tâches de raisonnement de 13,2 %, tandis que les protocoles de consensus améliorent les tâches de connaissances de 2,8 %.⁸ Cela suggère que le choix devrait dépendre du type de tâche. C’est pourquoi mon système utilise des seuils adaptatifs à la tâche plutôt qu’un chiffre de consensus unique.

Wu et al. ont testé si les agents LLM peuvent véritablement débattre et ont constaté que sans incitations structurelles au désaccord, les agents convergent vers la réponse initiale la plus assurée, indépendamment de sa justesse.⁹ Wynn et al. sont allés plus loin : le débat peut être activement nuisible. Les modèles passent de réponses correctes à incorrectes en réponse au raisonnement de leurs pairs, même lorsque les modèles plus performants sont majoritaires.¹⁰ Liang et al. ont identifié la cause racine comme la « dégénérescence de la pensée » : une fois qu’un LLM établit sa confiance dans une position, l’autoréflexion ne peut pas générer de contre-arguments nouveaux, rendant l’évaluation multi-agents structurellement nécessaire.¹¹

Mon système traite l’indépendance par l’isolation du contexte (les couches L2 sont privées à l’agent pendant la recherche). La diversité provient de 10 personas distincts avec des priorités d’évaluation différentes. L’agrégation utilise un scoring pondéré sur 5 dimensions plutôt qu’un simple vote. L’incitation structurelle au désaccord est plus faible : je suis si la dissidence est documentée mais ne récompense pas les agents pour leur dissidence. Le module de détection de conformité tente de combler cette lacune, avec des résultats mitigés.

Détecter le faux désaccord

Le module de conformité suit des patterns qui suggèrent que les agents sont d’accord sans évaluation véritable. Les préoccupations documentées qui répètent le même langage entre agents, les scores qui se regroupent de manière suspecte près du seuil, ou le soutien unanime de chaque persona (un Security Analyst et un Performance Engineer sont rarement d’accord sur tout) déclenchent des avertissements.

Ce qu’il détecte : la dissidence standardisée (les agents copiant le langage de préoccupation des autres), le regroupement de scores (chaque agent notant à moins de 0,3 points d’écart sur une échelle de 10 points), et les perspectives minoritaires absentes (approbation unanime de personas avec des priorités contradictoires).

Un exemple tiré de mes logs : cinq agents ont évalué un refactoring d’authentification. Les cinq ont noté le risque de sécurité entre 7,1 et 7,4. Le détecteur de conformité a signalé le regroupement. Quand j’ai relancé avec une isolation de contexte fraîche (en vidant les caches L2), les scores se sont étalés de 5,8 à 8,9. Le regroupement initial reflétait une contamination de contexte partagé, pas un accord véritable.

Ce qu’il manque : l’accord sophistiqué où les agents évaluent véritablement depuis la perspective de leur persona mais parviennent à la même conclusion pour des raisons différentes. Le module ne peut pas distinguer un vrai consensus du mimétisme lorsque le raisonnement semble indépendant. J’ai essayé d’entraîner un classificateur sur des exemples d’accord véritable vs. fabriqué, mais les données d’entraînement étaient trop limitées (moins de 50 sessions de délibération) et le signal trop faible. Le détecteur de conformité attrape les cas évidents et manque les subtils.

L’évaluation honnête : la détection de conformité ajoute un contrôle de cohérence utile sur les 10-15 % de délibérations où les agents convergent trop rapidement. Pour les 85-90 % restants, les portes de consensus et de pride check fournissent une validation suffisante. J’ai envisagé de construire un système de conformité plus sophistiqué et j’ai décidé que l’effort d’ingénierie ne correspondrait pas à l’amélioration marginale.

Ce qui n’a pas fonctionné

Impasse 1 : tours de débat en texte libre

La première version faisait écrire aux agents de longues réfutations des conclusions des autres : 3 tours d’échanges textuels. J’ai observé une délibération sur la stratégie d’indexation de base de données se dérouler sur 7 500 tokens de débat. Tour 1 : désaccord véritable sur les index composites vs. mono-colonne. Tour 2 : positions reformulées avec une élaboration mineure. Tour 3 : arguments quasi identiques enveloppés dans des mots différents. Le signal a culminé au tour 1 et s’est dégradé ensuite.

Le coût en tokens par délibération a atteint 2-4 $, et la densité d’information utile diminuait à chaque tour. La correction : un scoring structuré par dimension a remplacé le débat en texte libre. Les agents notent les propositions sur 5 dimensions avec des valeurs numériques au lieu d’écrire des dissertations. Le coût et le temps ont diminué d’environ 60 %, et la qualité du classement final s’est en fait améliorée parce que les scores numériques imposent une précision que la prose masque.

Impasse 2 : récursion basée sur la profondeur pour la délibération

L’incident de prolifération infinie a exposé une erreur de modélisation fondamentale. La garde de récursion suivait la profondeur : le parent à la profondeur 0 engendre un enfant à la profondeur 1, l’enfant engendre un petit-enfant à la profondeur 2, profondeur maximale 3. Mais les agents de délibération devraient se déployer en largeur (10 agents de recherche au même niveau), pas en profondeur (un agent engendrant un enfant engendrant un petit-enfant). La limite de profondeur de 3 n’a jamais été déclenchée parce que 23 agents à la profondeur 1, c’est toujours « profondeur 1 ».

La correction a été un modèle de budget d’engendrement : les agents de délibération héritent de la profondeur du parent au lieu de l’incrémenter et partagent un budget total d’engendrements d’enfants plafonné à 12. Le modèle de budget correspond au mode de défaillance réel (trop d’agents au total) plutôt qu’à une métrique proxy (trop de niveaux d’imbrication). La lignée des agents est suivie dans un fichier JSON pour que le budget persiste entre les complétions asynchrones des agents.¹²

Impasse 3 : porte de validation unique

La première implémentation exécutait un seul hook de validation en fin de session, combinant les vérifications de consensus avec les vérifications de qualité. Le mode de défaillance est apparu dès la première semaine. Un agent a complété la délibération avec un score de consensus de 0,52 — en dessous du seuil de 0,70. Il a ensuite continué sur des tâches non liées pendant 20 minutes avant que le hook de fin de session ne signale l’échec. Vingt minutes de travail construites sur une fondation qui n’avait pas passé la validation.

Diviser en deux portes a corrigé le problème de timing. La porte 1 (validation du consensus) s’exécute en tant que hook PostToolUse:Task, détectant un mauvais consensus immédiatement après la complétion de l’agent de délibération. La porte 2 (pride check) s’exécute en fin de session, détectant les problèmes de qualité qui se sont accumulés au fil des étapes. Deux hooks à différents points du cycle de vie correspondent à la manière dont les défaillances surviennent réellement : certaines sont instantanées (mauvais score) et d’autres sont graduelles (faible diversité, documentation de dissidence manquante).

Les chiffres honnêtes

La délibération coûte des tokens. Chaque agent de recherche traite environ 5 000 tokens de contexte et génère 2 000-3 000 tokens de résultats. Avec 3 agents (minimum pour une délibération utile), cela représente 15 000-24 000 tokens supplémentaires par décision. Avec 10 agents (panel de recherche complet), environ 50 000-80 000 tokens.

Au tarif Opus (15 $/75 $ par million de tokens), une délibération à 3 agents coûte environ 0,68-0,90 $. Une délibération à 10 agents coûte 2,25-3,00 $. Mon système déclenche la délibération sur environ 10 % des décisions (celles notées en dessous de 0,70 de confiance), donc le coût amorti sur toutes les décisions est de 0,23-0,30 $ par session.

La question de la rentabilité dépend de ce que coûte une mauvaise décision. Une vulnérabilité de sécurité manquée dans un déploiement en production coûte des heures de réponse à incident. Un mauvais choix d’architecture coûte des semaines de refactoring. Une faute de frappe dans la documentation ne coûte rien.

Le module de confiance détermine quelles décisions déclenchent la délibération. Quatre dimensions (ambiguïté, complexité, enjeux et dépendance au contexte) produisent chacune un score de 0 à 1. Plusieurs dimensions doivent avoir un score élevé pour que la confiance globale descende en dessous de 0,70 et déclenche la délibération. Les problèmes unidimensionnels (« c’est complexe mais sans ambiguïté ») restent au-dessus du seuil et évitent la délibération.¹³

Deux agents, une règle

Vous n’avez pas besoin de 10 personas de recherche, de 8 modules Python ou de 141 tests pour tirer profit de la délibération multi-agents. Commencez avec 2 agents et 1 règle : les agents doivent évaluer indépendamment avant de voir le travail de l’autre.

Délibération minimum viable

Decision arrives
  |
  v
Confidence check: is this risky, ambiguous, or irreversible?
  |
  ├── NO  -> Single agent decides (normal flow)
  |
  └── YES -> Spawn 2 agents with different system prompts
             Agent A: "Argue FOR this approach"
             Agent B: "Argue AGAINST this approach"
             |
             v
             Compare findings
             |
             ├── Agreement with different reasoning -> Proceed
             ├── Genuine disagreement -> Investigate the conflict
             └── Agreement with same reasoning -> Suspect herding

Le diagramme de décision ci-dessus couvre 80 % de la valeur. Voici l’implémentation minimale :

# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
    agent_for = spawn_agent(
        f"Argue FOR this approach: {decision_description}",
        persona="advocate"
    )
    agent_against = spawn_agent(
        f"Argue AGAINST this approach: {decision_description}",
        persona="critic"
    )

    if same_reasoning(agent_for, agent_against):
        return "WARNING: Suspect herding. Verify independently."
    elif genuine_conflict(agent_for, agent_against):
        return "Investigate the specific disagreement."
    else:
        return "Proceed. Independent agreement with different reasoning."

Tout le reste apporte une amélioration incrémentale : le classement à 5 dimensions, les seuils adaptatifs à la tâche, la détection de conformité. L’insight fondamental reste simple : deux perspectives indépendantes détectent des défaillances qu’une seule perspective manque.

Agent unique vs. multi-agents : ce qui change

Quand délibérer

Tester la délibération

Le système exécute 141 tests répartis sur trois couches :¹⁴

• 48 tests d’intégration bash : validation de la syntaxe des hooks, flux de consensus, portes de pride check, application de la garde de récursion et compatibilité inter-configurations
• 81 tests unitaires Python : les 7 modules de la bibliothèque (machine à états, confiance, isolation du contexte, classement, agents, conformité, génération de PRD)
• 12 tests de bout en bout : simulation complète du pipeline, de l’évaluation de confiance jusqu’à la sortie du PRD

Tester un système conçu pour le désaccord requiert de tester deux catégories. Le chemin nominal : les agents sont en désaccord de manière productive et parviennent à un consensus. Les chemins d’échec : les agents convergent trop rapidement, ne convergent jamais ou dépassent les budgets d’engendrement. Les tests E2E simulent chaque scénario avec des réponses d’agents déterministes, vérifiant que les deux portes détectent chaque mode de défaillance documenté.

Commencez avec le pattern à 2 agents. Ajoutez de la complexité quand la version à 2 agents manque quelque chose de spécifique. Chaque agent, seuil et porte de validation supplémentaire dans mon système existe parce que la version plus simple a échoué sur une tâche spécifique. Vos échecs seront différents, et le système que vous construirez pour les détecter devrait refléter vos échecs, pas les miens.

Points clés à retenir

• Le consensus est le mode de défaillance dangereux. Les agents uniques ne peuvent pas remettre en question leurs propres hypothèses. Deux agents indépendants avec des priorités d’évaluation différentes détectent les angles morts structurels que les portes de qualité et la philosophie ne peuvent pas traiter.
• Deux portes valent mieux qu’une. La validation du consensus pendant le processus détecte les problèmes tôt. Le pride check en fin de session détecte les problèmes qui se sont accumulés au fil des étapes. Diviser la validation en deux hooks à différents points du cycle de vie correspond à la manière dont les défaillances surviennent réellement.
• Délibérez sélectivement. Le module de confiance déclenche la délibération sur environ 10 % des décisions. Tout délibérer gaspille des tokens. Ne rien délibérer manque les décisions où les perspectives indépendantes comptent le plus.

FAQ

Références