Workflow de revue de code multi-agents : deux réviseurs, un seul rédacteur final
Je me heurte sans cesse à la même limite lorsque j’utilise plusieurs sessions de programmation avec l’IA. D’après mon expérience, les sessions parallèles trouvent des chemins de code différents, mais leurs désaccords restent enfermés dans des fils séparés. Je deviens le bus de messages, en copiant une revue dans une autre session et en décidant quel modèle a compris le fichier.
Une meilleure conception consiste en un workflow de revue de code multi-agents avec trois rôles distincts. Deux sessions d’IA inspectent indépendamment la même révision du fichier. Elles échangent leurs conclusions et remettent en question les éléments probants de l’autre. Une troisième session reçoit le compte rendu de la décision, écrit un seul correctif et exécute les vérifications.
Traitez le fichier comme une entrée partagée et immuable pendant la revue. Accordez l’accès en écriture à une seule session lorsque la revue converge.
Cela diffère de ma boucle hybride de revue de code avec l’IA→ actuelle, dans laquelle un modèle écrit et un second modèle examine chaque correction. Cette boucle donne déjà au réviseur une indépendance utile. L’expérience suivante retarde l’écriture : les deux premières sessions effectuent d’abord la revue, et une troisième session ne commence à coder qu’après que leur désaccord a produit un compte rendu de décision.
Ce modèle est déjà proche de ce que les outils d’agents actuels prennent en charge. La documentation des sous-agents de Codex d’OpenAI recommande des agents parallèles pour l’exploration intensive en lecture, les tests, le triage et la revue, tout en avertissant que les workflows parallèles intensifs en écriture créent des conflits et une surcharge de coordination. La pièce manquante est une couche de discussion et de synthèse de première classe entre les réviseurs et le rédacteur.
Pourquoi un workflow de revue de code multi-agents a-t-il besoin d’un seul rédacteur ?
L’analyse parallèle fournit différentes hypothèses de défaillance sans créer plusieurs correctifs concurrents.
Un réviseur peut retracer le comportement et les invariants. L’autre peut rechercher des problèmes de sécurité, des conditions de concurrence, des tests manquants ou des ruptures de contrat d’API. Ils partent du même commit SHA et de la même tâche, mais reçoivent des consignes de revue différentes. Cette séparation réduit le risque que les deux sessions suivent la même première idée.
Anthropic décrit un modèle de production connexe dans Building effective agents : plusieurs appels au modèle peuvent examiner le code sous différents angles, tandis qu’un workflow orchestrateur-travailleurs délègue le travail et synthétise les résultats. Anthropic conseille également aux équipes d’ajouter de la complexité agentique uniquement lorsqu’elle améliore les résultats mesurés. Trois sessions coûtent plus de tokens et de temps qu’une seule ; le workflow doit donc avoir une raison d’exister.
La mutation concurrente est rarement cette raison. Si deux agents modifient la même copie de travail, le système doit résoudre le contexte obsolète, les hunks qui se chevauchent et les hypothèses partiellement appliquées. Git offre déjà une primitive plus sûre : les worktrees liés permettent à des sessions distinctes d’utiliser un état `HEAD` et d’index isolé tout en partageant le même historique du dépôt.
Les réviseurs peuvent utiliser des worktrees pour leurs expériences, mais seul l’intégrateur devrait être responsable du correctif candidat.
Que possède chaque session d’IA ?
| Session | Accès | Sortie requise | Ne doit pas faire |
|---|---|---|---|
| --- | --- | --- | --- |
| Réviseur A | Instantané en lecture seule | Risques comportementaux, invariants rompus, références aux lignes, tests proposés | Modifier la branche finale |
| Réviseur B | Instantané en lecture seule | Sécurité, concurrence, cas limites, contre-exemples | Copier la conclusion du Réviseur A sans éléments probants |
| Intégrateur | Accès exclusif en écriture | Correctif accepté, conclusions rejetées avec leurs raisons, résultats des tests, diff final | Réécrire au-delà du périmètre convenu |
Le troisième agent n’est pas automatiquement plus intelligent. Son avantage vient de la responsabilité. Il reçoit des éléments probants délimités, rend explicite la résolution des conflits et produit un diff unique et vérifiable.
Je garderais également les réviseurs à l’écart de la première passe de l’autre. Une étude contrôlée du débat multi-agents a montré que la pression de la majorité peut supprimer la correction indépendante. Les échanges précoces peuvent transformer deux réviseurs en une seule opinion répétée. Les conclusions indépendantes doivent venir en premier ; la discussion devrait commencer après que chacun a consigné ses premiers éléments probants.
Comment les réviseurs doivent-ils discuter d’un même fichier ?
Le chat libre est utile aux humains, mais un workflow de programmation a besoin d’un registre compact des conclusions. Chaque affirmation doit contenir suffisamment d’éléments probants pour que l’intégrateur puisse la vérifier sans rejouer une chaîne de pensée privée.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
Le second réviseur peut accepter la conclusion, la réfuter au moyen d’un argument fondé sur le code réellement atteignable, ou en restreindre la portée. Le registre conserve les deux positions. L’accord ne prouve pas à lui seul la justesse, et un paragraphe assuré ne devrait pas l’emporter sur un test reproductible.
Les protocoles d’agents évoluent dans cette direction. Le protocole Agent2Agent de Google modélise la collaboration au moyen de tâches, de messages, d’états et d’artefacts. Un système local de programmation n’a pas besoin du protocole complet pour reprendre ce contrat : utilisez des messages typés, des identifiants stables, un état explicite et des artefacts durables plutôt qu’une transcription non structurée.
Mon pont de revue par les pairs avec l’IA→ regroupe déjà un diff, des questions ciblées et un verdict structuré pour un second modèle. Un workflow à trois sessions a besoin de la couche suivante : deux paquets de revue capables de référencer, contester et résoudre les mêmes identifiants de conclusions avant que le rédacteur ne les reçoive.
Que doit recevoir le rédacteur avant de modifier le code ?
L’intégrateur ne devrait pas recevoir deux longs historiques de chat. Il lui faut un petit paquet de transmission :
Le rédacteur relit ensuite le fichier actuel et compare sa révision avec la transmission. Toute divergence interrompt l’écriture. Cette simple vérification empêche qu’une revue valide du fichier d’hier ne devienne un correctif défectueux appliqué au code d’aujourd’hui.
C’est également à ce stade que les permissions doivent devenir déterministes. J’ai défendu des permissions déterministes pour les agents d’IA→, car une consigne telle que « modifier uniquement ce fichier » est plus faible qu’une politique d’outil qui rend tous les autres chemins accessibles en lecture seule. Dans ce workflow, le modèle de permissions doit imposer la séparation des rôles : les réviseurs ne peuvent pas écrire, et l’intégrateur ne peut pas élargir le périmètre sans une nouvelle décision.
Le débat améliore-t-il les correctifs logiciels ?
Les éléments disponibles vont dans cette direction, mais ils ne prouvent pas que chaque équipe devrait utiliser exactement deux réviseurs et un rédacteur.
Improving Factuality and Reasoning in Language Models through Multiagent Debate montre que plusieurs instances d’un modèle peuvent proposer, critiquer et affiner des réponses au fil de plusieurs tours, améliorant les résultats sur les tâches de raisonnement et de factualité de l’article. Ces expériences n’ont pas testé les conflits Git ni les pull requests en production.
Un exemple de programmation plus proche est apparu dans le préprint de 2025 SWE-Debate. Ses agents débattent de traces concurrentes de localisation des défauts, consolident un plan de correction et transmettent ce plan à un agent distinct de génération de correctif. L’article rapporte 207 tâches résolues sur 500 dans SWE-bench Verified, soit 41,4 %, contre 38,8 % pour ses meilleurs baselines listés. Le benchmark et l’architecture diffèrent du workflow que je propose, mais la séparation est révélatrice : une analyse diverse d’abord, puis une seule étape de modification.
L’étape suivante honnête consiste en une petite évaluation contrôlée sur de vraies pull requests. Comparez un agent de programmation unique au workflow à trois sessions sur 10 à 20 bugs. Mesurez les conclusions valides, les faux positifs, les conflits de fusion, le temps nécessaire pour obtenir un correctif acceptable et les régressions détectées après la première version. Un plus grand nombre de messages d’agents n’est pas une métrique de réussite.
Comment le rédacteur produit-il un correctif vérifiable unique ?
L’intégrateur devrait suivre une boucle étroite :
Cette dernière revue doit examiner le correctif, et non relancer le débat de conception. Chaque réviseur répond à deux questions : le rédacteur a-t-il mis en œuvre la décision acceptée, et le correctif a-t-il introduit un nouveau risque ?
L’application Codex actuelle d’OpenAI utilise déjà des fils et des worktrees distincts afin que les agents puissent s’exécuter en parallèle sans toucher au même état Git local, et elle permet aux développeurs d’inspecter et de commenter chaque diff. L’annonce de l’application Codex montre que la couche d’isolation existe. Un registre partagé des conclusions et un rôle d’intégrateur explicite transformeraient les tâches parallèles en salle de revue coordonnée.
Quels échecs subsistent ?
Un seul rédacteur élimine les courses à l’écriture, pas les erreurs du modèle.
Deux réviseurs peuvent partager le même angle mort, surtout s’ils utilisent le même modèle, le même prompt et le même contexte. L’intégrateur peut choisir l’argument le plus persuasif plutôt que le bon. Les commentaires du dépôt peuvent contenir des instructions non fiables. Une suite de tests réussie peut manquer le comportement dont dépendent les utilisateurs.
Le workflow a besoin de garde-fous :
Ma conclusion précédente après 21,54 milliards de tokens d’activité d’agents de programmation→ reste valable : c’est le système autour du modèle qui détermine si davantage d’intelligence devient un travail utile ou un nettoyage plus rapide.
Quand un workflow à trois sessions en vaut-il la peine ?
Utilisez-le lorsqu’un mauvais correctif coûte cher ou que le code admet plusieurs interprétations plausibles : authentification, permissions, paiements, migrations, concurrence, API publiques et corrections d’incidents. Il peut également être utile lorsqu’un ingénieur senior demanderait normalement à deux spécialistes d’examiner des domaines de risque différents.
Évitez-le pour le formatage, les fichiers générés, les renommages simples et les modifications disposant d’un oracle de test évident. L’équipe multi-agents d’Anthropic a constaté que la complexité de coordination augmente rapidement, et son système de recherche en production dépend d’une délégation claire et d’un agent principal qui synthétise les résultats spécialisés. La programmation exige la même discipline, avec une tolérance moindre pour les écritures ambiguës.
Je veux que les agents de programmation débattent des éléments probants avant que l’un d’eux ne gagne le contrôle du curseur. Deux sessions devraient inspecter le même fichier, exprimer publiquement leur désaccord et laisser un seul compte rendu de décision. Une troisième devrait écrire le correctif candidat et le démontrer par rapport au dépôt.
Ce candidat a toujours besoin de tests, d’une revue du diff et d’une décision humaine de mise en production. Trois sessions d’IA peuvent améliorer le chemin vers le correctif ; elles ne transforment pas le correctif en vérité.
FAQ
Deux agents d’IA peuvent-ils modifier le même fichier en même temps ?
Ils le peuvent, mais les écritures partagées créent un contexte obsolète et des modifications conflictuelles. Laissez les deux agents analyser la même révision en mode lecture seule, ou isolez les expériences dans des worktrees distincts, puis accordez à un seul intégrateur un accès exclusif en écriture à la branche finale.
Les deux réviseurs doivent-ils utiliser le même modèle ?
Ils le peuvent, mais des prompts, des rôles ou des familles de modèles différents peuvent réduire les angles morts corrélés. La diversité ne garantit pas la justesse ; le workflow exige donc toujours des éléments probants et des tests.
Que se passe-t-il lorsque les réviseurs ne sont pas d’accord ?
Consignez les deux positions dans le registre des conclusions. L’intégrateur devrait reproduire l’affirmation, exécuter le test proposé ou marquer le problème comme non résolu pour un humain. Le vote majoritaire est un faible substitut aux éléments probants vérifiables.
La troisième session d’IA remplace-t-elle la revue de code humaine ?
Non. La troisième session est responsable de la synthèse et de l’écriture du correctif candidat. Un humain décide toujours si le correctif s’intègre au système global, à l’intention produit et au risque de mise en production.
Ce workflow peut-il gérer des modifications portant sur plusieurs fichiers ?
Oui. Épinglez chaque fichier examiné à la même révision du dépôt, attribuez des responsabilités claires et conservez une seule branche d’intégration. Les réviseurs peuvent travailler dans des worktrees isolés, tandis que l’intégrateur reste la seule session qui assemble le correctif final.