La première fois que vous lancez trois agents de codage en même temps, l'exécution cesse d'être le facteur lent. Vous confiez un bug à Claude Code, un refactoring à Codex et un manque de couverture de tests à un troisième Runtime, et quarante minutes plus tard, trois branches sont prêtes. C'est là que la véritable attente commence, car toutes les trois attendent désormais après vous. Vous lisez le premier diff, vous le validez, et les deux autres restent à l'arrêt. Vous avez une exécution parallèle et une revue sérielle : le parallélisme ne vous apporte donc presque rien.
C'est le piège dans lequel tombe toute équipe qui devient performante dans l'exécution d'agents en parallèle. Le goulot d'étranglement ne disparaît pas : il se déplace, de « à quelle vitesse un agent peut écrire le code » à « à quelle vitesse une personne peut lire, juger et accepter le résultat ». Ajouter un quatrième agent ne fait qu'empirer la situation : une file plus longue de travail terminé, avec toujours un seul relecteur.
La solution n'est pas de relire plus vite ni de faire davantage confiance. Elle consiste à concevoir la revue comme une partie explicite du workflow, plutôt que comme une réflexion de dernière minute gardée dans un coin de votre tête. C'est le workflow que cet article détaille, et c'est le problème autour duquel Sharkly a été conçu : garder l'objectif, le diff, les preuves et la revue de chaque exécution d'agent dans une seule Tâche, pour que la file de revue devienne quelque chose que vous pouvez voir et gérer, au lieu d'un amas d'onglets ouverts dans votre navigateur.
Pourquoi les agents en parallèle déplacent le goulot d'étranglement vers la revue
La revue est une file d'attente. Les exécutions d'agents terminées arrivent à un certain rythme, une personne les traite à un autre rythme, et si les arrivées dépassent les sorties, la file grandit sans limite. Toute l'histoire est là, et c'est pourquoi le débit brut d'agents est le mauvais chiffre à optimiser. Si dix agents terminent en une heure et que vous pouvez accepter soigneusement trois changements par heure, vous avez construit une usine dont le quai de chargement tient à une seule personne avec un presse-papiers.
La plupart des outils masquent ce phénomène. Une pile de pull requests vous montre le travail, mais pas quels éléments attendent réellement une décision, lesquels tournent encore et lesquels sont déjà fusionnés. La file est bien réelle, mais elle est éparpillée entre les onglets, les notifications et votre mémoire. Le premier objectif de conception est de la rendre visible, car on ne peut pas gérer un goulot d'étranglement que l'on ne voit pas. Un article complémentaire sur le calcul de la capacité de revue détaille ce qui se passe à mesure que la concurrence augmente.
Le modèle opérationnel : qui assigne, qui exécute, qui relit, qui accepte
Avant de toucher aux statuts, nommez les quatre rôles. Ce sont des rôles distincts, et c'est en les confondant que la revue devient chaotique.
Quelqu'un assigne le travail : il transforme une intention en une Tâche délimitée, avec des critères d'acceptation. Quelque chose l'exécute : un Agent, sur un Computer, s'exécutant dans un Runtime, produisant un changement et un compte rendu de ce qu'il a fait. Quelqu'un relit le résultat : il lit le diff et les preuves, et décide s'il répond aux critères. Quelqu'un l'accepte : il prend la décision de fusionner et de livrer, ce qui est un choix différent de « le code a l'air correct ».
Sharkly énonce le contrat en une phrase qui mérite un post-it : les agents recherchent, exécutent, testent et rendent compte ; les humains donnent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis. L'assignation et l'acceptation sont humaines par conception. L'exécution revient à l'Agent. La revue, elle, est le rôle qu'il faut véritablement concevoir, car c'est là que la file se forme.
Une distinction utile : une PR fusionnée n'est pas la même chose qu'un résultat accepté. Fusionner est une opération git. Accepter, c'est une personne qui décide que le changement fait bien ce que la Tâche demandait. Quand ces deux étapes se réduisent à un seul clic, la qualité de la revue tombe au niveau de l'énergie que le relecteur avait à cet instant précis.
Rôles, statuts et points de contrôle de revue
Donnez une forme à cette file en attribuant aux Tâches un petit ensemble de statuts entre lesquels agents et humains font circuler le travail. La Tâche est l'unité de travail principale : elle contient l'objectif, la conversation et l'exécution. L'intérêt des statuts est que les agents peuvent faire avancer une Tâche jusqu'au point de contrôle de revue, et qu'une personne est la seule à pouvoir lui faire franchir ce cap.
| Statut | Qui le déplace ici | Signification |
|---|---|---|
| Backlog | Personne | Délimité, non démarré. Aucune exécution n'a lieu ici. |
| Ready | Personne | Validé pour exécution ; un Agent peut le prendre en charge. |
| In progress | Agent | Une exécution est en cours dans un worktree isolé. |
| Ready for review | Agent | Exécution terminée, changement et preuves joints, en attente d'une personne. |
| Changes requested | Personne | Renvoyé avec un commentaire ; une exécution de suivi se poursuit sur la même Tâche. |
| Done | Personne | Accepté, fusionné, livré. |
Le point de contrôle correspond au passage vers Ready for review et à la sortie vers Done. Les agents peuvent l'atteindre seuls ; ils ne peuvent pas le franchir. C'est cette règle unique qui vous permet de faire tourner dix agents en toute sécurité : ils remplissent en parallèle la colonne Ready for review, et vous la videz au rythme qui préserve la qualité. La longueur de cette colonne, c'est votre goulot d'étranglement rendu visible.
Voici la paire de décisions à prendre honnêtement. Faites passer par un point de contrôle tout changement livré aux utilisateurs ou touchant à l'argent, à l'authentification, aux migrations de données ou aux API publiques. Ne le faites pas pour les spikes jetables, le boilerplate généré que vous regénérerez de toute façon, ou le travail derrière un flag encore inaccessible. Un point de contrôle sur tout déplace simplement le goulot d'étranglement sur le relecteur, pour des changements qui n'avaient jamais eu besoin d'un humain. L'article sur les points d'approbation explique où placer l'arrêt pour les travaux à risque plus élevé.
Concevoir la revue pour qu'elle passe à l'échelle
Relire la production d'agents en parallèle n'a rien à voir avec la relecture de la PR d'un collègue. Il y en a davantage, elle arrive par vagues, et vous savez souvent moins de choses sur la façon dont elle a été produite. Trois principes permettent de réduire le coût de revue par élément.
Rattachez les preuves à la Tâche, pas à votre mémoire. Une exécution doit renvoyer le résumé des changements, la sortie du typecheck et des tests, le résultat du build et les limites connues, le tout consigné. Quand vous ouvrez un élément Ready for review, vous lisez un dossier, vous ne reconstituez pas ce qui s'est passé. C'est toute la différence entre relire avec des preuves au niveau de la Tâche et tout relancer soi-même pour retrouver la confiance.
Jugez la décision, pas les frappes au clavier. Les propriétés vérifiables par une machine — formatage, sûreté du typage, réussite des tests — doivent être contrôlées par des machines avant que la Tâche ne vous parvienne. Les recommandations de Google en matière de revue de code opèrent la même séparation : automatisez ce qu'un outil peut vérifier, pour que l'humain consacre son attention à la conception et à l'adéquation. Votre jugement, ressource rare, doit porter sur « est-ce le bon changement », et non sur « est-ce que ça compile ».
Plafonnez le travail en cours. Une limite stricte du nombre de Tâches simultanément en In progress évite que la colonne Ready for review ne devienne un mur impossible à absorber. C'est l'idée de la limite WIP du kanban appliquée aux agents : lancer une sixième exécution alors que cinq vous attendent déjà n'augmente pas le débit, cela masque la file d'attente. Il est également utile de surveiller les agents en cours d'exécution pour distinguer une exécution bloquée d'une exécution lente avant qu'elle n'atteigne le point de contrôle.
Un exemple concret, du ticket à la PR fusionnée
Prenons une Tâche réaliste, SH-312 : « Limiter le débit de l'endpoint de recherche public ». Une personne la façonne dans le Backlog avec des critères d'acceptation (429 après N requêtes par minute et par clé, en-tête documenté, un test) et la déplace vers Ready.
Trois Agents travaillent dans le Space en parallèle. L'un prend SH-312, clone le dépôt configuré sur un Computer et s'exécute dans un worktree isolé pour que sa branche n'entre jamais en collision avec les deux autres exécutions en cours. Il écrit le limiteur, ajoute un test, lance le typecheck et la suite de tests, ouvre une PR dont le titre porte l'ID de la Tâche, puis déplace SH-312 vers Ready for review avec le résumé des changements, la sortie des tests réussis et une limite connue signalée : le compteur est en mémoire de processus, et non partagé entre les instances.
Vous ouvrez la Tâche, pas quinze onglets. Les preuves sont là, et la note sur la limite connue est le point précieux : les tests passent, mais l'état partagé entre instances relève d'un choix de conception qui vous revient. Vous laissez un commentaire et déplacez la Tâche vers Changes requested. Ce commentaire déclenche une exécution de suivi sur la même Tâche ; l'Agent remplace le compteur par un stockage partagé et renvoie des preuves actualisées. Cette fois, vous acceptez. Le passage de SH-312 à Done est votre décision, enregistrée comme un changement de statut à votre nom, et non comme l'effet de bord silencieux d'un merge git.
Pendant ce temps, les deux autres Agents attendent dans Ready for review. Comme la file est une colonne et non votre boîte de réception, vous les traitez ensuite, dans l'ordre, sans perdre le fil.
La ligne que l'on garde pour les humains
Les agents en parallèle, c'est une histoire de débit… jusqu'à ce que la revue devienne la contrainte, et c'est alors une histoire de file d'attente. Les équipes qui tirent de la valeur d'un grand nombre d'agents traitent la revue comme une infrastructure à part entière : des statuts explicites, un point de contrôle que les agents peuvent atteindre sans le franchir, des preuves rattachées à la Tâche, des vérifications machine avant les vérifications humaines, et une limite au volume de travail en cours.
Vous pouvez mettre tout cela en place à la main, avec des worktrees, une convention de nommage des branches et de la discipline. Ou laisser Sharkly gérer le workflow : des Agents assignables, des Tâches qui portent l'exécution et ses preuves, et un board où Ready for review est une colonne que vous videz, pour que les agents recherchent, exécutent, testent et rendent compte pendant que les humains gardent la décision finale. Si vous faites déjà tourner plusieurs agents, c'est un endroit unique pour gérer leurs tâches et leurs résultats, au lieu de compter sur votre mémoire.
FAQ
Faire tourner des agents en parallèle fait-il gagner du temps si la revue est sérielle ? Uniquement jusqu'au moment où les exécutions terminées arrivent plus vite que vous ne pouvez les accepter. Au-delà, les agents supplémentaires allongent la file de revue sans rien livrer plus tôt. Le gain vient du fait de rendre la revue visible et de ne soumettre à un point de contrôle que ce qui a réellement besoin d'un humain.
Chaque changement produit par un agent doit-il être relu par un humain ? Non. Soumettez à un point de contrôle les changements livrés aux utilisateurs ou touchant à l'authentification, aux données, à l'argent ou aux API publiques. Laissez passer le travail à faible risque ou regénérable avec les seules vérifications machine. Tout soumettre à un point de contrôle ramène le goulot d'étranglement sur le relecteur, pour des changements qui n'en avaient pas besoin.
Fusionner la PR revient-il au même qu'accepter le travail ? Non. La fusion est une opération git ; l'acceptation, c'est une personne qui décide que le changement satisfait aux critères de la Tâche. Les garder distincts préserve la qualité de la revue quand le volume est élevé. Voir les agents de codage avec humain dans la boucle pour savoir où placer la décision humaine.
