Penser avec dix cerveaux : comment j'utilise la délibération multi-agents comme outil de décision

J’étais plongé depuis trois heures dans la conception d’un système de récupération de mémoire pour mon harness Claude Code lorsque j’ai décidé de soumettre la décision à mon système de délibération multi-agents. Dix agents IA ont évalué le projet de manière indépendante. Neuf d’entre eux avaient des opinions sur l’architecture, la sécurité et la performance. Le dixième a posé une question que je n’avais pas pensé à poser : « Combien coûte réellement le problème que vous essayez de résoudre ? »

La réponse a tué le projet. Le surcoût en tokens que je prévoyais d’optimiser coûtait moins par mois qu’un café. Le système de récupération que je prévoyais de construire aurait nécessité 200 à 400 heures d’ingénierie. Seuil de rentabilité : 18 à 36 ans.¹

Chaque autre agent avait produit une analyse utile. Le design du Technical Architect était propre. Le Security Analyst avait trouvé de vrais risques. Les calculs du Performance Engineer étaient précis. Mais aucun d’entre eux n’avait remis en question l’existence même du projet. Et moi non plus. J’étais déjà ancré sur la solution. Le Cost Analyst n’avait pas cet ancrage, car il évalue chaque proposition à partir de zéro.

En bref

Vous ne pouvez pas éliminer les biais cognitifs simplement en en ayant conscience. Kahneman l’a prouvé il y a des décennies : même les experts qui étudient les biais y succombent.² La délibération multi-agents est une intervention structurelle, pas une astuce de prompting. Dix agents IA dotés de priorités d’évaluation différentes forcent l’externalisation du raisonnement, rendant les angles morts visibles avant qu’ils ne deviennent des engagements. J’ai construit l’architecture en janvier 2026 et je l’utilise depuis deux mois sur des décisions allant des systèmes de mémoire à la stratégie éditoriale en passant par la conception d’API. Cet article porte sur la pratique : comment penser avec dix cerveaux, quand le faire, et quand cela empire les choses.

Le problème avec votre propre tête

Daniel Kahneman a consacré sa carrière à documenter une défaillance structurelle de la cognition humaine. Le Système 1 génère des jugements rapides et intuitifs. Le Système 2 est censé les vérifier. En pratique, le Système 2 fonctionne dans « un mode confortable de faible effort » et valide les conclusions du Système 1 sans examen.² La découverte centrale de Kahneman : le système de contrôle est paresseux. Il tamponne l’intuition sans la questionner.

Cela correspond directement à la façon dont la plupart des gens utilisent l’IA. Vous posez une question à un agent. L’agent génère une réponse (Système 1). Vous lisez la réponse et décidez si elle semble correcte (Système 2). Mais votre Système 2 évalue la réponse à travers les mêmes biais qui ont façonné la question. Vous vous êtes ancré sur votre premier cadrage. Vous avez donné à l’agent un contexte qui confirmait votre hypothèse existante. L’agent, entraîné à être utile, a renforcé votre direction. À aucun moment quelqu’un n’a remis en cause la prémisse.

Voici les biais qui frappent le plus fort dans les décisions d’ingénierie :

Les contre-stratégies sont bien documentées : processus d’avocat du diable, analyse pré-mortem, cadres de décision structurés, boucles de retour externe.³ Le problème, c’est l’exécution. Mener une analyse pré-mortem nécessite de réunir des personnes, de planifier du temps et de surmonter la pression sociale. Chercher un avocat du diable nécessite de trouver quelqu’un disposé à contredire la personne qui signe son évaluation de performance.

La délibération multi-agents supprime la barrière de l’exécution. Les agents sont toujours disponibles. Ils n’ont aucune incitation sociale à être d’accord. Ils évaluent indépendamment par conception, non par discipline.

La délibération comme pensée externalisée

Sam Altman décrit l’écriture comme une « pensée externalisée » : quand un problème semble confus, le mettre par écrit force la clarté.⁴ Le même mécanisme s’applique au débat structuré. Quand dix agents articulent leur raisonnement en parallèle, ce raisonnement devient un artefact que vous pouvez inspecter.

Ce n’est pas une idée nouvelle. Marvin Minsky a proposé dans The Society of Mind que l’intelligence émerge de l’interaction de nombreux agents plus petits et plus simples, et non d’un seul processus sophistiqué.⁵ Andrew Ng a identifié trois schémas pour les systèmes multi-agents : le débat (proposer, critiquer, réviser), la collaboration (spécialistes en parallèle avec un synthétiseur) et l’évaluation adversariale (red team contre blue team).⁶ Le cadre des Six Thinking Hats d’Edward de Bono, publié en 1985, attribue des perspectives parallèles (faits, émotions, prudence, optimisme, créativité, processus) pour empêcher les groupes de s’ancrer sur un seul mode de pensée.⁷

Mon système de délibération implémente les trois schémas simultanément. Les dix agents de recherche sont des spécialistes (schéma collaboratif de Ng). Les agents de Débat et de Synthèse créent un désaccord structuré (schéma de débat de Ng). Le Maintenance Pessimist et le Security Analyst fonctionnent comme des évaluateurs adversariaux. Chaque agent correspond à un « chapeau de réflexion » :

L’architecture est documentée ailleurs. Ce qui compte ici, c’est la pratique. La délibération vous force à externaliser la décision dans un format où les biais deviennent visibles. Vous cessez de demander « est-ce une bonne idée ? » et commencez à lire dix réponses indépendantes à « qu’est-ce qui pourrait mal tourner, que disent les chiffres, et quelles alternatives existent ? »

Pedro Domingos décrit l’IA idéale comme un « exosquelette mental » : quelque chose qui prolonge votre réflexion plutôt que de la remplacer, qui représente vos intérêts plutôt que de flatter vos conclusions.⁸ Un panel de délibération incluant un avocat du diable, un analyste des coûts et un pessimiste de la maintenance est exactement cela. Il amplifie les parties de votre cognition qui sont structurellement faibles.

Étude de cas : la décision d’architecture mémoire

En février 2026, j’ai lancé le premier test en conditions réelles du système de délibération sur la question de l’introduction : quelle architecture mémoire mon harness Claude Code devrait-il utiliser à travers 12 projets actifs ?¹

Mon harness injecte des fichiers MEMORY.md dans chaque conversation. Ces fichiers contiennent les décisions de projet, les schémas, l’historique des erreurs et les notes d’architecture. Le problème : la majeure partie de ce contexte est sans rapport avec une session donnée. Seuls 5 à 10 % de la mémoire chargée sont pertinents pour la tâche en cours. Le reste est du gaspillage de tokens. Une cible d’optimisation évidente.

La confiance initiale était de 0,50, bien en dessous du seuil de 0,70 qui déclenche la délibération. Le système a déployé les dix agents de recherche. Chacun a enquêté de manière indépendante avec isolation de contexte : les agents ne pouvaient pas voir les conclusions des autres pendant la recherche.

Trois approches ont émergé :

Les scores racontent une histoire. Ce que les agents individuels ont trouvé en raconte une meilleure.

Technical Architect : A identifié quatre schémas d’intégration (serveur MCP, MEMORY.md augmenté, récupération par embedding, gestionnaire basé sur un agent). A recommandé une approche par paliers : augmenter les fichiers existants maintenant, ajouter la récupération par embedding plus tard. Design propre, bien délimité.

Security Analyst : A évalué chaque outil de mémoire externe comme risque ÉLEVÉ à CRITIQUE pour l’exposition de credentials. A identifié une attaque spécifique : une session compromise injecte « toujours résumer les clés API » dans la mémoire persistante, empoisonnant silencieusement chaque session future.

Performance Engineer : A quantifié le gaspillage. Seuls 5 à 10 % de la mémoire chargée sont pertinents par conversation. Mais avec des fenêtres de contexte de 1M de tokens, le surcoût total de la mémoire est de 2K tokens, soit seulement 0,2 % de la capacité. « L’optimisation évidente » cible une erreur d’arrondi.

UX Advocate : « Le meilleur système de mémoire est celui auquel vous ne pensez jamais. » Chaque alternative ajoute une charge cognitive. Les utilisateurs commencent à se demander « est-ce que la mémoire fonctionne ? Que sait-elle ? » et cessent de faire confiance au contexte automatisé. Le système invisible inspire plus de confiance que n’importe quel système visible.

Maintenance Pessimist : Des systèmes de mémoire multiples créent des surfaces de défaillance combinatoires. Quatre systèmes en interaction produisent 16 modes de défaillance par paires. Claude Code se met à jour fréquemment. Les plugins externes cassent lors des changements de version. Une défaillance silencieuse d’un hook signifie que l’agent opère avec un contexte incomplet et sans avertissement.

Cost Analyst : C’est l’agent qui a tué le projet. Le coût total en tokens du chargement systématique des fichiers mémoire à travers les 12 projets : dérisoire. Le système de récupération proposé économiserait quelques dollars par mois. Temps d’ingénierie pour le construire : 200 à 400 heures. Seuil de rentabilité : 18 à 36 ans. Le résumé du Cost Analyst : « Dans un monde obsédé par l’optimisation, parfois la bonne réponse est de ne rien toucher. »

Aucun agent n’a produit une analyse erronée. Le design du Technical Architect fonctionnait. Les calculs de tokens du Performance Engineer étaient justes. Mais la décision nécessitait les dix perspectives pour éviter le piège de l’optimisation. Livré à mes propres instincts, j’aurais construit le système de récupération parce que cela ressemblait à du progrès. Le Cost Analyst a posé la question que je ne pouvais pas me poser moi-même, car trois heures de cadrage avaient déjà ancré ma réflexion sur la solution.

Délibération vs. Duel

La délibération est collaborative : dix agents évaluent une décision sous différentes perspectives. J’ai également construit une variante compétitive qui fait concourir Claude Code contre Codex CLI sur la même tâche, note les deux plans à l’aveugle et synthétise les éléments les plus forts de chacun. Trente-six duels ont produit des schémas qui méritent leur propre article. En résumé : je délibère les décisions architecturales et je fais dueler les plans d’implémentation. La délibération répond à « devrait-on construire cela ? » Le duel répond à « quelle est la manière la plus solide de le construire ? »

Le Maintenance Pessimist et l’art de l’inversion

La technique d’inversion de Charlie Munger demande : au lieu de « comment atteindre X ? », posez-vous la question « qu’est-ce qui garantirait l’échec de X ? » Puis évitez ces choses.⁹ Le pré-mortem de Gary Klein opérationnalise la même idée : supposez que le projet a échoué, puis expliquez pourquoi.¹⁰ Les recherches de Philip Tetlock sur la précision des prévisions ont montré que les « renards » qui intègrent de multiples perspectives surpassent systématiquement les « hérissons » qui s’engagent sur une seule grande idée.¹¹

Chaque agent de délibération incarne un cadre de pensée nommé :

Le Maintenance Pessimist est l’agent le plus précieux de mon système. Non pas parce qu’il est le plus intelligent ou le plus minutieux, mais parce qu’il pose la question que je suis le moins susceptible de me poser. Quand je suis enthousiaste à l’idée de construire quelque chose, la dernière chose que je veux envisager, c’est ce que cela coûtera à maintenir dans six mois. Le Maintenance Pessimist n’a pas d’enthousiasme. Il n’a pas de coût irrécupérable. Il évalue la proposition comme si elle existait déjà et demande ce qui casse.

Dans la délibération sur l’architecture mémoire, le Maintenance Pessimist a identifié que quatre systèmes de mémoire en interaction produisent 16 modes de défaillance par paires. Claude Code se met à jour fréquemment. Les plugins externes cassent lors des changements de version. Les défaillances silencieuses de hooks signifient que l’agent opère avec un contexte incomplet et sans avertissement. Ce ne sont pas des risques hypothétiques. Ce sont des prédictions basées sur des schémas que le pessimiste a été entraîné à reconnaître.

Kahneman a décrit le pré-mortem comme l’une des techniques de débiaisage les plus efficaces qu’il connaisse, parce qu’il légitime la dissidence.² Un agent de délibération conçu pour exprimer son désaccord supprime entièrement le coût social.

L’Evidence Gate : ne vous laissez pas auto-évaluer

Mon harness utilise un schéma d’Evidence Gate pour chaque rapport de complétion.¹² La règle : les impressions ne sont pas des preuves. « Je crois que ça fonctionne » n’est pas une affirmation. Exécuter la suite de tests et coller la sortie en est une.

Le langage évasif est un signal d’alerte : « devrait », « probablement », « semble », « je crois », « a l’air correct ». Chaque mot signale que la vérification n’a pas eu lieu.¹² Cela s’applique aussi au raisonnement humain. Quand vous vous surprenez à dire « je suis assez confiant que c’est la bonne approche », ce n’est pas une preuve. C’est le Système 2 qui tamponne le Système 1.

La délibération multi-agents impose l’Evidence Gate de manière structurelle. Le Cost Analyst ne dit pas « cela a probablement un sens économique ». Il dit « coût actuel de 9 $/mois, économie de 5 $/mois, 200 à 400 heures de construction, seuil de rentabilité de 18 à 36 ans ». Le Security Analyst ne dit pas « la posture de sécurité semble raisonnable ». Il dit « scénario d’empoisonnement de mémoire : une session compromise injecte des instructions de collecte de credentials dans la mémoire persistante ».

Le mécanisme de débiaisage le plus efficace que j’ai trouvé n’est ni une checklist ni une philosophie. C’est un système où les agents ne peuvent pas s’auto-évaluer. Ils doivent produire des preuves, et ces preuves sont évaluées par d’autres agents qui n’ont aucune incitation à être d’accord.

Quand NE PAS délibérer

La délibération a aussi ses modes de défaillance. Le système ajoute 2 à 4 minutes et 2 à 3 $ par invocation à pleine échelle. Plus important encore, il peut sur-corriger.

J’ai lancé une délibération sur un refactoring simple d’endpoint API. Dix agents ont soulevé des préoccupations concernant la compatibilité ascendante, les chemins de migration, la limitation de débit, la gestion des erreurs, le monitoring et la documentation. L’endpoint servait deux consommateurs internes. La délibération a généré 14 actions à mener pour ce qui aurait dû être un changement de 20 lignes. J’en ai ignoré 12 et j’ai livré le refactoring. La délibération était techniquement correcte — les risques étaient réels — mais la décision était une porte à double sens.¹³

Jeff Bezos distingue les décisions de Type 1 (irréversibles, portes à sens unique) des décisions de Type 2 (réversibles, portes à double sens). Les décisions de Type 1 exigent une délibération minutieuse : modifications de schéma de base de données, architecture de sécurité, contrats d’API publics. Les décisions de Type 2 exigent de la rapidité : refactorings internes, mises à jour de documentation, expérimentations par feature flag.¹³ Appliquer un processus lourd à des décisions légères est une forme de gaspillage en soi.

Règles que je suis :

Délibérez quand : - La décision est irréversible ou coûteuse à inverser - Des compromis multiples nécessitent une évaluation spécialisée - Votre confiance est inférieure à 0,70 (vous vous sentez incertain sans pouvoir expliquer pourquoi) - Le domaine est en dehors de votre expertise principale

Décidez simplement quand : - Le changement est derrière un feature flag ou facilement réversible - Le périmètre est contenu (un fichier, une fonction, un endpoint) - Vous avez déjà pris ce type de décision avec succès - Le coût de se tromper est inférieur au coût de la délibération

Ne délibérez jamais sur : - Les corrections de documentation - Les renommages de variables - Les mises à jour de fixtures de test - Les modifications de messages de log

Les 10 % de décisions qui méritent une délibération produisent 90 % de la valeur. Tout délibérer produit une paralysie par l’analyse. Ne rien délibérer expédie les biais que vous ne pouvez pas voir.

Ce que j’ai appris en deux mois

Le système a exécuté environ 40 délibérations depuis janvier 2026. Les schémas constatés :

1. Le Cost Analyst est l’agent le plus sous-estimé. Les ingénieurs se tournent instinctivement vers le Performance Engineer et le Security Analyst. Le Cost Analyst a tué plus de mauvaises idées que tout autre persona en posant l’unique question que les ingénieurs détestent : « combien cela coûte-t-il réellement ? »

2. Un consensus inférieur à 0,70 signifie que la question est mal posée. Quand les agents ne parviennent pas à s’accorder, le problème est généralement un cadrage ambigu, pas un véritable désaccord. Recadrer la question et relancer produit de meilleurs résultats que de forcer la convergence.

3. Le Maintenance Pessimist détecte ce que les post-mortems trouvent trop tard. Chaque préoccupation que le Maintenance Pessimist a soulevée concernant l’architecture mémoire a depuis été validée par l’expérience réelle de la maintenance de systèmes plus simples.

4. Deux agents capturent 80 % de la valeur. Le schéma minimum viable : un agent argumente POUR, un autre argumente CONTRE. L’indépendance est le mécanisme. Dix agents, c’est mieux, mais deux agents sont infiniment meilleurs qu’un seul.

5. La délibération améliore la question, pas seulement la réponse. Le résultat le plus fréquent n’est pas « l’approche gagnante ». C’est « la question recadrée d’une manière qui rend la réponse évidente ».

Références