Revue de pull requests par des agents IA : configuration en 6 étapes

En bref : Pour faire relire des pull requests par des agents IA, confiez la revue à un second agent disposant de ses propres instructions, de son propre checkout et, si possible, d'un modèle différent. Déclenchez-le automatiquement dès qu'une tâche passe au statut de revue, faites-lui exécuter les tests et publier un verdict PASS ou CHANGES REQUIRED, puis renvoyez les échecs à l'agent développeur. La décision de merger revient toujours à un humain.

Pourquoi confier la revue des pull requests à des agents IA avant d'intervenir

Toutes les pull requests générées par des agents finissent au même endroit : sur votre bureau. Lorsqu'un seul agent soumet une PR par heure, le rythme reste gérable. Mais dès que cinq agents tournent en parallèle, la file d'attente s'allonge plus vite que vous ne pouvez lire les diffs, et la première relecture devient alors le goulot d'étranglement.

C'est précisément là qu'intervient un agent relecteur pour cette première passe. Il ne remplace pas votre jugement : il élimine les PR qui échouent aux tests, dépassent le périmètre prévu ou divulguent des secrets, afin que celles qui arrivent jusqu'à vous méritent vraiment votre attention. Dans Sharkly, cette configuration ne nécessite qu'un Agent supplémentaire et deux Automations. Le reste de ce guide détaille chaque élément étape par étape.

Si vous souhaitez d'abord découvrir les limites de la revue automatisée, consultez notre article sur ce que les agents IA de revue de code peuvent et ne peuvent pas vérifier. Le présent article se concentre quant à lui sur la mise en place.

Pourquoi un agent ne peut pas relire son propre code

L'agent qui a écrit le code a également conçu le récit qui l'entoure. Lorsque vous lui demandez de vérifier son propre travail, il relit son propre raisonnement et l'approuve d'emblée. Les angles morts à l'origine du bug sont exactement ceux qui effectuent la revue.

Ce phénomène est particulièrement flagrant avec les tests. Un agent développeur qui ne parvient pas à faire passer un test peut être tenté d'affaiblir l'assertion et de considérer la tâche comme terminée. Nous avons analysé ces comportements dans notre guide expliquant comment repérer les agents de code qui trichent sur les tests. Un relecteur, quant à lui, n'a aucun intérêt dans le résultat : il examine le diff à froid et pose une question bien différente : cette modification répond-elle à ce qui était demandé, et rien d'autre ?

L'essai de conception de l'équipe DeepSeek Harness sur les super-agents aboutit à une séparation similaire : plusieurs Workers rattachés à la même PR suivent ses événements et peuvent arbitrer les conflits entre eux. Il s'agit d'une architecture prototype et non d'un produit finalisé, mais le principe reste parfaitement valable. La revue gagne en efficacité lorsque le relecteur est une entité distincte.

Étape 1 : Séparer le développeur et le relecteur

Créez deux Agents distincts, et non un seul Agent doté de deux modes. Chacun dispose de ses propres instructions, de ses dépôts et de sa propre cible d'exécution.

Dans Sharkly, un Agent ne possède pas de sélecteur de modèle. Sa cible d'exécution repose sur un Computer et un Runtime détecté sur ce Computer ; « utiliser un modèle différent » signifie donc associer le relecteur à un Runtime distinct. Ce second Runtime apporte un ensemble d'habitudes différent face au diff. Chaque exécution est facturée selon le forfait déjà rattaché à ce Runtime, car Sharkly ne vend pas de tokens au détail.

Configurez le répertoire de travail du relecteur en mode Temporary. La documentation sur les Computers explique comment chaque exécution obtient un répertoire isolé, et comment les exécutions de dépôt peuvent préparer un worktree Git propre. Le relecteur extrait alors la branche de la PR dans sa propre copie sans risquer d'écraser les fichiers du développeur. Notre article consacré aux agents en parallèle dans des worktrees isolés détaille l'importance de ce mécanisme dès lors que plusieurs agents partagent un même dépôt.

Étape 2 : Rédiger les instructions du relecteur

Les instructions de l'Agent définissent son rôle, les contrôles à effectuer et le format du compte rendu. Les détails spécifiques à chaque tâche restent sur la tâche elle-même. Veillez à ce que les instructions du relecteur restent courtes et vérifiables :

You are the code reviewer for this Space. You never push, merge or edit files.

1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.

La première étape est bien plus cruciale qu'elle n'en a l'air. À ce jour, les déclencheurs de statut et de commentaire s'appliquent à l'échelle de toute l'Organization ; les instructions doivent donc obligatoirement valider la tâche avant d'agir. La documentation sur les Automations l'indique expressément.

Étape 3 : Choisir le déclencheur

Les Automations de Sharkly combinent des instructions, un Agent ou une Crew, ainsi qu'un ou plusieurs déclencheurs. Pour la revue de PR, deux déclencheurs conviennent parfaitement.

Le changement de statut de tâche. Ajoutez un statut comme In Review au workflow de votre Space. L'agent développeur y déplace sa tâche après avoir ouvert la PR, ce qui lance le relecteur. Une exécution déclenchée par un statut génère une conversation sur cette tâche, de sorte que le verdict et la consommation de tokens restent rattachés au travail concerné.

Cette capture d'écran montre le point de contrôle utilisé par ce blog pour ses propres brouillons : lorsqu'une tâche passe à Ready for Release, un Agent relecteur la prend en charge. Le schéma est rigoureusement identique pour le code.

Le webhook. Si vos PR sont ouvertes en dehors de votre tableau de tâches, dirigez un webhook pull_request de GitHub vers l'URL de webhook d'une Automation. Lorsque la vérification de signature est activée, Sharkly prend en charge l'en-tête X-Hub-Signature-256 de GitHub ; collez simplement le secret de signature dans le champ Secret de GitHub. Les exécutions par webhook n'étant pas associées à une tâche, le relecteur publie directement son verdict sur la PR elle-même via la CLI GitHub.

Testez l'une ou l'autre de ces approches avec Run now avant de la déployer en production.

Étape 4 : Fournir une checklist au relecteur

Sans checklist, un relecteur rédige des dissertations. Avec une checklist, il formule des constats. Cinq questions couvrent l'essentiel des PR produites par des agents :

1. Les tests s'exécutent-ils et passent-ils avec succès ? Le relecteur les lance lui-même, sans jamais se fier au résumé fourni par le développeur.
2. Le périmètre a-t-il été respecté ? Tout fichier modifié en dehors du cadre de la tâche constitue une anomalie, même si la modification semble anodine.
3. Des secrets sont-ils exposés ? Tokens, clés ou valeurs de fichiers .env dans le diff ou dans les logs.
4. Y a-t-il des régressions pour les appelants ? Signatures modifiées, endpoints supprimés ou migrations sans procédure de rollback.
5. Les tests ont-ils été affaiblis ? Assertions supprimées, nouveaux skips ajoutés ou valeurs attendues assouplies.

Conservez cette liste au sein d'une Skill si plusieurs Agents relecteurs la partagent, afin qu'une seule modification mette à jour l'ensemble d'entre eux.

Étape 5 : Définir un format de verdict standardisé

Un verdict qu'un humain peut parcourir en dix secondes est bien plus précieux qu'une analyse détaillée qu'il ignorera. Adoptez un format rigide :

VERDICT: CHANGES REQUIRED

Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none

Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.

Le verdict PASS reprend exactement les mêmes champs avec une liste Required vide. Ces champs fixes rendent également les verdicts quantifiables : vous pouvez observer la fréquence d'échec de chaque point de contrôle et adapter les instructions de l'agent développeur en conséquence.

Étape 6 : Boucler la boucle vers le développeur

Un verdict CHANGES REQUIRED doit relancer le développeur sans que vous ayez à intervenir. Créez une seconde Automation, attribuée à l'Agent développeur, avec un déclencheur par commentaire configuré sur une phrase bien spécifique.

La détection de commentaire est insensible à la casse et se déclenche dès que la phrase apparaît n'importe où dans un commentaire. Choisissez une formule que personne ne taperait par accident, et demandez au relecteur de ne l'écrire que sur sa ligne CHANGES REQUIRED. Si le développeur cite cette phrase dans sa propre réponse, il risquerait de s'auto-déclencher : précisez-lui donc de ne jamais la répéter.

Fixez une limite à la boucle : deux cycles de revues et de corrections, après quoi le relecteur transmet la tâche à un humain en joignant son dernier verdict.

Ce qui reste sous le contrôle de l'humain

Le merge reste entièrement de votre ressort. Dans l'intégration GitHub de Sharkly, l'identifiant d'une tâche dans le titre de la PR associe celle-ci à la tâche, et l'opération de merge ne modifie pas le statut de la tâche. Rien ne part en production sur la seule base d'un avis PASS émis par un agent.

Appliquez cette règle également dans GitHub : des branches protégées imposant une approbation humaine empêchent un relecteur trop confiant de constituer le dernier rempart. Vous conservez également les arbitrages qu'une checklist ne peut pas trancher : s'agit-il de la bonne architecture, et ce changement a-t-il simplement lieu d'être ? Pour savoir comment ordonner les éléments qui arrivent jusqu'à vous, découvrez comment classer la file d'attente des PR d'agents et découvrez pourquoi la revue humaine représente le véritable goulot d'étranglement.

Conclusion

Les PR générées par vos agents cesseront de s'accumuler dès lors qu'un second agent assurera la première passe. Séparez le développeur du relecteur, donnez au relecteur son propre worktree et son propre Runtime, déclenchez-le à l'aide d'un statut ou d'un webhook, et exigez qu'il réponde à cinq questions précises dans un format standardisé. Renvoyez les échecs grâce à une phrase clé en commentaire, limitez la boucle à deux itérations et gardez la main sur le merge.

Si vous faites déjà tourner dix agents de code en même temps, cette étape est la brique suivante indispensable. Lancez-vous gratuitement sur Sharkly et commencez par créer votre Agent relecteur.

FAQ

Un agent IA peut-il relire sa propre pull request ?

Il en est capable, mais il détectera moins d'erreurs. L'agent partage les hypothèses qui ont conduit à l'écriture du code. Un relecteur distinct doté de ses propres instructions et, idéalement, d'un Runtime différent examinera le diff sans ces préjugés.

Le relecteur doit-il utiliser un modèle différent de celui du développeur ?

Oui, dès que possible. Dans Sharkly, le modèle découle du Runtime ; reliez donc l'Agent relecteur à un Runtime différent de celui du développeur, par exemple Codex pour relire le code produit par Claude Code.

Que doit vérifier en priorité un relecteur de code IA ?

Les tests. Demandez-lui d'exécuter la suite lui-même et de rapporter le nombre de réussites et d'échecs. Examinez ensuite le périmètre, les secrets, les changements cassants (breaking changes) et les tests affaiblis, dans cet ordre précis.

Un agent relecteur peut-il approuver et merger une PR ?

Ne l'y autorisez pas. Réservez les droits de merge aux humains à l'aide de la protection de branches. Le relecteur publie un avis sous forme de commentaire ; la décision finale revient à une personne.

Comment empêcher la boucle de revue de tourner indéfiniment ?

Plafonnez-la à deux itérations dans les instructions du relecteur, et utilisez une phrase de commentaire que le développeur ne répète jamais. Une fois ce plafond atteint, le relecteur passe la main à un humain.

Cela fonctionne-t-il avec des pull requests GitHub ouvertes en dehors de Sharkly ?

Oui. Reliez un webhook GitHub au déclencheur par webhook d'une Automation. Sharkly gère l'en-tête de signature de GitHub lorsque la vérification est activée.