La code review à l'ère des agents : ce qui doit changer

Un ingénieur senior que je respecte m'a dit récemment qu'il approuve les PR générées par IA plus vite que celles des humains. Son raisonnement : "le code est généralement plus propre". Il a raison sur la surface et tort sur tout ce qu'il y a en dessous, et l'écart entre ces deux choses devient le problème central de qualité de notre métier.

Le code écrit par un agent est propre. Variables bien nommées, style cohérent, structure plausible, souvent des tests corrects. Chaque signal que nous avons passé une décennie à apprendre à lire, du genre code en désordre veut dire code risqué, a volé en éclats. Les diffs ont l'air d'avoir été écrits par un senior consciencieux. Parfois ils ont été écrits par un processus qui a fondamentalement mal compris la tâche et a exprimé ce malentendu magnifiquement.

Après un an à travailler quotidiennement avec des agents de code en parallèle, voici comment ma pratique de la review a réellement changé.

Le problème de volume est réel, la solution n'est pas la vitesse

Les agents produisent plus de code. Beaucoup plus. La réponse naïve est de reviewer plus vite, ce qui en pratique veut dire reviewer plus superficiellement, ce qui veut dire que le garde-fou qualité cesse silencieusement de jouer son rôle.

Mon correctif contre-intuitif : contraindre la génération, pas la review. J'ai arrêté de laisser les agents tourner sans surveillance pendant une heure pour livrer un diff de 800 lignes. Les briefs sont devenus plus courts, les checkpoints plus fréquents, et tout diff de plus de quelques centaines de lignes repart pour découpage. La même règle que j'appliquerais à un coéquipier humain, appliquée avec moins de culpabilité. La capacité de review est la ressource rare désormais ; tout ce qui se trouve en amont devrait être façonné autour d'elle.

Reviewer l'intention, pas seulement le diff

Avec du code humain, le diff vous dit en général ce que l'auteur avait en tête. Avec du code d'agent, le diff vous dit ce que l'agent a fait. Ce qu'il a compris est une autre question, et c'est là que vivent les bugs.

Du coup, la première chose que je lis dans une PR d'agent n'est plus le code. C'est le spec ou le brief qui l'a produit, en regard du résultat. Les défaillances les plus dangereuses que j'ai attrapées n'étaient pas des bugs dans l'implémentation. C'étaient des implémentations correctes d'une mauvaise lecture : un cas limite silencieusement "géré" en inventant une règle métier que personne n'avait demandée, une migration qui préservait un comportement que le spec voulait explicitement changer. Impeccable localement, faux globalement. Aucune catégorie de linter n'existe pour ça.

Les tests sont reviewés plus durement que le code

Je l'ai écrit dans mon article sur les worktrees et je vais continuer à le répéter : quand l'agent écrit à la fois l'implémentation et les tests, les tests sont votre seul signal indépendant, sauf qu'ils ne sont pas indépendants. Ils ont été générés par le même processus, partageant le même malentendu.

Habitude concrète : pour chaque suite de tests d'agent, je demande ce qui n'est pas testé. Les agents excellent à tester le happy path qu'ils viennent d'implémenter et sont bizarrement réticents à tester les limites de leurs propres hypothèses. Une suite de tests avec 95% de coverage et zéro cas adverse est un tampon d'approbation déguisé en blouse blanche. J'écris régulièrement deux ou trois cas de test hostiles à la main contre le code d'agent. Le taux de réussite donne de l'humilité.

Ce que les humains devraient arrêter de reviewer

Honnêteté dans l'autre sens : une grande partie de l'activité de review classique est désormais du gaspillage.

Le style, le formatage, les conventions de nommage, l'ordre des imports : réglé, entre les formatters, les linters et le fait que les agents suivent les conventions plus systématiquement que les humains ne l'ont jamais fait. Si vos reviewers y consacrent encore de l'attention, vous payez des salaires de senior pour un travail que fait un fichier de config.

Les diffs chargés de boilerplate, comme un nouvel endpoint CRUD suivant un pattern établi, un changement de config, des refactors mécaniques, méritent un niveau de review différent et plus léger que la logique inédite. Nous taguons informellement les PR par risque désormais : qui suit un pattern reçoit une passe de bon sens, logique inédite ou manipulation de données reçoit le traitement complet, tout ce qui touche à l'argent, l'auth ou les migrations reçoit deux humains, peu importe qui ou quoi l'a écrit. Accorder la même attention à tout, c'est accorder une attention insuffisante aux parties dangereuses.

Des agents qui reviewent des agents, ça aide, en pré-filtre

Nous faisons tourner un review agent sur les PR avant qu'un humain ne regarde. Il attrape des choses réelles : gestion d'erreur oubliée, incohérences avec des patterns ailleurs dans la codebase, le bug authentique occasionnel. Ça vaut le coup de l'avoir.

Mais après des mois de ça, je suis convaincu que le reviewer agent et le reviewer humain font des métiers différents, et les confondre est l'erreur. L'agent vérifie le code par rapport à la codebase. L'humain vérifie le code par rapport à la réalité : la règle métier qui vit dans un thread Slack, le client qui va tomber sur ce cas limite, le fait de savoir que ce module est porteur d'une manière qu'aucun commentaire ne documente. Tant que les agents ne détiennent pas ce contexte (et malgré les progrès du context engineering, c'est encore rarement le cas), la review humaine est celle qui attrape les défaillances coûteuses.

Ce que je dirais à moi-même au départ

Le basculement mental qui m'a pris le plus de temps : arrêter de reviewer le code d'agent comme si la compétence impliquait la compréhension. Avec un auteur humain, un code propre est la preuve d'un esprit clair qui a probablement aussi visé juste sur l'intention. Avec un agent, la corrélation est rompue : le poli est gratuit, et il ne vous dit rien.

Donc lisez le brief avant le diff. Méfiez-vous des tests magnifiques. Hiérarchisez votre attention par risque, pas par taille. Et gardez une vieille habitude un peu sale de l'ancien monde : quand quelque chose vous semble louche et que vous ne savez pas dire pourquoi, n'approuvez pas. Cet instinct a été entraîné sur des années d'incidents en production, et c'est la seule partie de la review qui n'a pas été automatisée.