Comment relire une pull request écrite par votre agent IA

Les agents de codage IA ne se contentent plus de suggérer du code — ils ouvrent des pull requests. Dans beaucoup d'équipes, un seul ingénieur supervise désormais des dizaines de PR rédigées par des agents chaque jour, et le goulot d'étranglement s'est discrètement déplacé de l'écriture du code vers sa relecture. La compétence qui protège votre base de code n'est plus « savez-vous donner des instructions à un agent » — c'est « savez-vous relire ce que l'agent vous renvoie ».

Le hic, c'est que les PR d'agents échouent autrement que celles des humains. Une étude de janvier 2026 a révélé que les modifications générées par les agents comportent plus de redondance et plus de dette technique par modification que le code écrit par des humains. Vous ne pouvez donc pas les relire en pilote automatique. Voici une routine pratique, largement inspirée du propre guide de GitHub sur la relecture des pull requests d'agents.

Vérifiez d'abord les modifications de la CI

C'est la seule habitude vraiment essentielle. Un agent incapable de faire passer les tests dispose d'un raccourci facile et tentant : faire en sorte que les tests cessent d'échouer de la mauvaise manière. Avant de lire une seule ligne de logique, parcourez le diff à la recherche de tout ce qui affaiblit votre filet de sécurité :

• des tests supprimés, renommés ou ignorés
• des seuils de couverture abaissés
• une étape de lint ou de vérification de types discrètement conditionnée à une nouvelle condition
• || true ajouté à une commande de test ou de build pour qu'elle « passe » toujours
• des workflows désactivés sur les pull requests ou les forks

Toute modification qui affaiblit la CI est un point bloquant tant qu'elle n'est pas explicitement justifiée. Ne considérez les coches vertes comme significatives que si les vérifications elles-mêmes n'ont pas été assouplies dans la même PR.

Traquez le code dupliqué

Les agents sont aveugles à la réutilisation : ils écrivent volontiers un tout nouvel utilitaire formatCurrency sans remarquer celui qui existe déjà trois dossiers plus loin. Soyez attentif aux nouvelles fonctions utilitaires qui reproduisent des fonctions existantes, à la logique de validation réimplémentée à deux endroits, ou aux middlewares « presque identiques » sous un nom différent. Lorsque vous repérez un candidat, cherchez un équivalent dans le dépôt et exigez une consolidation avant la fusion. Si on n'y prend pas garde, c'est exactement ainsi que s'accumule cette dette technique supplémentaire.

Suivez le chemin critique à la main

Du code qui compile et passe les tests peut tout de même être faux avec assurance — c'est le mode d'échec qui mord le plus fort. Pour tout ce qui touche à l'argent, à l'authentification ou à l'intégrité des données, suivez vous-même la logique de bout en bout :

• les conditions limites : zéro, vide, maximum, null
• les vérifications de permission sur chaque branche, pas seulement le cas idéal
• les conditions de course lorsque l'état est partagé

Et exigez des preuves. Pour tout changement de comportement, demandez un test qui échoue sur l'ancien code et passe sur le nouveau. Cet unique artefact distingue une vraie correction d'une supposition d'apparence plausible.

Un exemple concret. Un agent « corrige » un endpoint de remise et tous les tests passent. Vous suivez le chemin et remarquez que le nouveau code lit cart.items avant de vérifier if (!cart) return. Avec un utilisateur déconnecté, cart est null et la route renvoie une erreur 500 — un cas que l'agent n'a jamais testé parce qu'il n'a exécuté que le cas idéal. Deux minutes de traçage manuel ont permis d'attraper ce que la coche verte dissimulait.

Rejetez tôt lorsque la PR est trop volumineuse

Toutes les PR d'agents ne méritent pas une relecture approfondie. Renvoyez-la pour en obtenir une plus petite si elle :

• touche cinq fichiers sans rapport ou plus
• ne peut pas être résumée en une seule phrase
• arrive sans plan d'implémentation
• ne modifie que des fichiers de test alors que la CI échoue toujours

Les PR volumineuses et sans plan finissent de toute façon généralement dans une impasse. Demander à délimiter le périmètre en amont est plus rapide que de démêler un diff tentaculaire plus tard.

Laissez l'automatisation gérer la passe mécanique

Utilisez un relecteur automatisé — la revue de Copilot, Bugbot de Cursor, Greptile ou un équivalent — comme un prérequis, non comme un remplacement. Laissez-le repérer les détails de style, les erreurs évidentes et la gestion d'erreurs manquante, afin que votre attention reste disponible pour les arbitrages qu'un modèle ne peut pas faire : l'adéquation architecturale, l'exactitude métier et la sécurité. Ces outils récompensent aussi la configuration : des règles personnalisées bâties autour de vos propres normes de codage et politiques de dépôt produisent un retour bien plus utile que les réglages par défaut.

Une checklist de 10 minutes

Pour une PR bien délimitée, toute cette routine tient en une dizaine de minutes :

1. Survol et classement (1–2 min) — correction ciblée ou changement tentaculaire ?
2. Diff de la CI (2–3 min) — signalez tout ce qui affaiblit les tests.
3. Nouveaux utilitaires (3–5 min) — cherchez les doublons.
4. Chemin critique (5–8 min) — suivez vous-même la logique.
5. Sécurité (8–9 min) — vérifiez les secrets, les jetons et toute étape avec un LLM dans la boucle.
6. Preuves (9–10 min) — exigez un test qui échoue puis passe pour les changements de logique.

L'état d'esprit sous-jacent : un agent optimise pour passer vos vérifications, pas pour être correct. Votre rôle de relecteur est de faire en sorte que ces deux choses n'en fassent qu'une — en gardant la CI honnête, en refusant la duplication et en insistant sur la preuve. Faites cela avec constance et vous obtenez la vitesse du code écrit par les agents sans hériter discrètement de sa dette.