Pourquoi chaque relecteur de code IA a besoin d'un test qui échoue
La revue de code par IA produit un bruit convaincant. Une seule règle suffit à y remédier : aucun problème ne compte sans un test qui échoue et le reproduit, plus un témoin qui prouve que le test est valide.
Demandez à un modèle d'IA de relire une pull request et vous obtiendrez des remarques. Vous en obtiendrez toujours. Certaines seront de vrais bugs. Beaucoup seront des inquiétudes bien formulées et sûres d'elles, sur des problèmes qui n'existent pas.
C'est le cœur du problème de la revue de code par IA : soulever une inquiétude ne coûte rien, la vérifier coûte cher. Si chaque remarque demande à un humain d'enquêter, le relecteur ne fait pas gagner de temps, il en crée.
La règle
Sur mes projets, une remarque de revue ne compte que si elle s'accompagne d'un test qui échoue et la reproduit.
Pas « ceci pourrait provoquer une situation de concurrence ». Un test qui déclenche la situation de concurrence et échoue. Pas « ce validateur semble trop permissif ». Un test qui envoie la mauvaise entrée et montre qu'elle passe.
Si le relecteur ne peut pas écrire le test de reproduction, la remarque devient une question, pas un point bloquant.
Pourquoi un témoin est indispensable
Un test qui échoue prouve que quelque chose a échoué. Il ne prouve pas que le code est faux. Parfois, c'est le test qui est faux : le jeu de données est invalide pour une autre raison, le mock est mal configuré, ou le test vérifie la mauvaise chose.
Chaque test de reproduction a donc besoin d'un témoin : le même jeu de données, valide en tout point sauf le champ attaqué, et qui doit passer. Si le témoin échoue aussi, le problème vient du test, pas du code.
Rejeter les faux positifs avec des preuves
La règle s'applique dans les deux sens. Quand un développeur conteste une remarque, « je ne suis pas d'accord » n'est pas une réponse non plus. Il la rejette avec des preuves. La preuve la plus solide est une mutation qui ne fait rien échouer : casser le code exactement de la façon décrite par la remarque, lancer les tests, et montrer que le bug supposé ne peut pas se produire.
Chaque remarque finit dans l'un de ces trois états :
- Réelle : corrigée, avec un test qui l'aurait détectée
- Faux positif : rejetée par écrit, preuves à l'appui
- Partiellement juste : la bonne moitié corrigée, et la moitié rejetée expliquée
Où placer le test de reproduction
Écrivez les tests de reproduction dans un espace à part, jamais dans le worktree qui passe les contrôles. Un test de reproduction actif dans la vraie suite de tests contamine l'exécution. Une fois le bug corrigé, il peut devenir un vrai test de non-régression.
Ce qui change
Avec cette règle, les remarques de revue cessent d'être des opinions. L'agent relecteur consacre ses efforts à des attaques qu'il peut prouver, le développeur ne perd pas de temps sur des bugs fantômes, et l'humain ne regarde que des remarques déjà démontrées.
C'est la différence entre un relecteur IA qui a l'air intelligent et un relecteur qui améliore vraiment le code. Cette règle fait partie du pipeline multi-agents que j'utilise pour livrer du code en production.