Pourquoi les grandes équipes multi-agents patinent
Lorsque les agents LLM ont commencé à être massivement utilisés dans le développement, de nombreuses équipes ont suivi une voie logique, mais pas toujours efficace : recruter autant de « spécialistes » algorithmiques que possible et leur attribuer des rôles. L'un écrit le code, le deuxième cherche les vulnérabilités, le troisième vérifie les scénarios. Le problème, c'est que chaque nouvel agent apporte de moins en moins de valeur : sur des tâches à l'échelle d'un dépôt entier, les coûts de coordination dépassent rapidement le gain apporté par ces « mains supplémentaires ».
La réaction a été de se diriger dans la direction opposée : les agents ont été transformés en sous-agents — des outils obéissants, appelés à la demande et n'entrant pas en dialogue. Cette approche élimine le chaos, mais détruit du même coup la principale ressource du travail collectif : plus personne ne conteste les décisions des autres, et les erreurs passent donc inaperçues.
Le point d'équilibre : un minimum de coopération
Eric S. Qiu et Joyce Gill ont cherché ce juste milieu dans leur travail « Adversarial Review: Structured Disagreement for Grounded Agentic Code Review » (arXiv:2608.18167, catégories cs.AI et cs.SE ; soumis le 16 août 2026, accepté à l'ICML 2026 Workshop on DL4C). Leur hypothèse est simple : on peut conserver la simplicité d'une architecture à sous-agents tout en y ajoutant un minimum de coopération — un seul nœud où les opinions des agents se confrontent délibérément.
Le résultat est le protocole Adversarial Review (AR). Les auteurs ne construisent volontairement pas de hiérarchie complexe et ne multiplient pas les rôles. À la place, trois participants interviennent :
- l'agent codeur prépare les modifications du code ;
- le relecteur évalue la pertinence de ces modifications ;
- le critique audite non pas le code, mais la relecture elle-même, et en identifie les faiblesses.
Le critique ne se contente pas de dire « je ne suis pas d'accord » — il formule un désaccord structuré : il pointe des fragments de code précis qui ne confirment pas les conclusions du relecteur. Et ce n'est qu'une fois ce cycle terminé que l'agent principal est autorisé à apporter des corrections.
Ce que les tests ont montré
L'effet du désaccord est clairement visible dans les résultats des benchmarks.
Sur LiveCodeBench, AR a affiché le plus haut pourcentage de passages réussis parmi toutes les méthodes testées. Un détail important : trois agents ont suffi pour cela, alors que la version de base, qu'AR a surpassée, en utilisait cinq.
Sur SWE-PRBench, les choses se sont révélées plus intéressantes. La version naïve du protocole a soudainement mis en évidence un mode de défaillance que les auteurs ont appelé le faux consensus : les agents convergeaient vers une opinion commune sans disposer de preuves suffisantes. Autrement dit, même un désaccord spécialement construit peut dégénérer en un « d'accord avec tout le monde » formel. On y remédie par une itération du prompt, où l'exigence de contester et de justifier son désaccord est formulée explicitement — après cet ajustement, la méthode a pris la première place en F1.
Enfin, sur SWE-bench Verified, AR a de nouveau amélioré les résultats des approches de base. C'est important, car les tâches à l'échelle du dépôt représentent une tout autre échelle de complexité que les fonctions isolées : des modifications dans un module peuvent casser des dizaines de modules voisins.
Conclusion : la force ne vient pas du nombre de voix, mais du droit de s'opposer
Les auteurs aboutissent à une conclusion contre-intuitive, mais confirmée par l'expérience : une revue de code efficace n'exige ni une grande équipe, ni des schémas de communication complexes. Il suffit que le désaccord soit :
- minimal — un seul point de conflit, pas un chat sans fin ;
- structuré — chaque participant a une fonction claire et distincte ;
- fondé sur des preuves — l'objection s'appuie sur des faits présents dans le code, et non sur des préférences subjectives.
La leçon pratique pour tous ceux qui construisent des pipelines d'agents : n'essayez pas de résoudre le problème en ajoutant des rôles. Intégrez plutôt une étape de doute obligatoire dans le processus — et permettez à un agent de contester officiellement les conclusions d'un autre. La valeur d'une revue ne se mesure pas au nombre de voix, mais à la présence de quelqu'un capable de s'opposer sur le fond.
