Revue de code par IA : papiers et outils comparés à mon skill

Quand tu modifies du code, un collègue relit tes changements avant la mise en ligne. C'est la revue de code. Moi, je la fais faire par des IA, avec un outil que j'ai écrit pour Claude Code, l'assistant de programmation d'Anthropic. Cet outil est un skill : un dossier d'instructions que Claude Code lit avant une tâche précise.

Mon skill, senior-review, lance plusieurs relecteurs. Un relecteur est une instance de Claude lancée pour relire le code (on dit aussi un « agent »). Il ne connaît pas l'auteur du code, celui qui l'a écrit (j'ai expliqué pourquoi le relecteur ne doit jamais être l'auteur). Chaque défaut qu'un relecteur signale s'appelle un « finding ». J'utilise ce skill presque chaque jour de travail : 236 revues depuis le 14 août.

Le skill a trois réglages, appelés paliers. « quick » est léger, « standard » est celui par défaut, « deep » est censé être plus rigoureux, avec plus de relecteurs. Il tient un journal : pour chaque revue, il note combien de findings sont remontés et combien passent la vérification. La vérification exige une preuve pour chaque défaut et tente de réfuter les plus graves, c'est-à-dire de montrer qu'ils sont faux.

Le journal dit autre chose. En « deep », 74 % des findings remontés survivent à la vérification. En « quick », c'est 89 %. En apparence, j'avais donc payé plus cher pour des relecteurs qui tombent plus souvent à côté.

Ces chiffres m'ont donné envie de vérifier si mon skill est solide ou si c'est un bricolage qui me plaît. J'ai lancé deux agents de recherche : l'un dans la littérature scientifique, l'autre du côté des outils existants.

Revue de code par IA : mon skill face aux autres outils

Je compare mon skill à d'autres outils de revue par IA. Il y a celui d'Anthropic, des outils commerciaux (CodeRabbit, Greptile, Qodo, Bugbot) et des skills de la communauté. J'ai retenu neuf critères.

• Contexte : le dépôt entier (le dossier du projet), son historique, le code qui appelle la partie modifiée.
• Indépendance : les relecteurs ignorent l'auteur du code.
• Preuve : le relecteur montre comment il sait que le défaut existe.
• Réfutation : quelqu'un tente de prouver que le défaut est faux.
• Bruit : peu de fausses alertes (des défauts signalés à tort).
• Mémoire : l'outil garde la trace de ses erreurs.
• Boucle : correction puis relecture, avec un nombre de tours maximum.
• Lecture seule : l'outil ne peut rien modifier dans le code.
• Ticket : l'outil lit la description du travail demandé (le « ticket »).

J'ai ajouté trois critères qui manquaient : la mesure validée de l'extérieur, l'intégration et le coût. Mesure validée de l'extérieur : un autre que l'éditeur a-t-il testé l'outil ? Intégration : l'outil marche-t-il sans réglage dans les « pull requests », ces demandes qu'on poste pour faire relire ses changements ?

Chaque colonne du tableau est un outil ou un groupe d'outils, chaque case une note de 0 à 5 (5 est la meilleure). C'est mon jugement, d'après les documentations lues. « Non documenté » dans une source ne veut pas dire « absent », et j'ai noté en conséquence. « 1-2 » couvre les outils du groupe. Regarde la preuve (5 pour mon skill) et la mesure externe (2).

« Claude Code officiel » regroupe le service de revue géré par Anthropic et son extension code-review. Cette extension lance quatre agents en même temps. D'autres agents vérifient ensuite les défauts trouvés, un par défaut : un défaut non confirmé est jeté. Sa documentation cite un seuil de confiance à 80, qui n'est plus dans le code.

Mes forces sont la preuve exigée, le ticket, la boucle à nombre de tours limité et la mémoire. Mes faiblesses : un coût élevé, aucune intégration native aux pull requests, et surtout une mesure externe faible. Les outils commerciaux affichent des benchmarks (des tests chiffrés), mais chaque éditeur gagne sur sa propre mesure, comme les « commentaires résolus avant fusion ». Ces chiffres ne se comparent pas. Je n'en cite aucun.

Ce que dit la recherche, et ce qu'elle ne dit pas

L'agent de recherche a ouvert la page d'une trentaine de papiers. Les chiffres viennent de leurs résumés, sauf un, tiré du corps de l'étude de Cihan. Plusieurs sont des « preprints », des textes pas encore relus par d'autres chercheurs. Six résultats comptent pour un skill de revue.

• Donne l'intention du changement au relecteur. Une étude a testé GPT-4o et Gemini 2.0 Flash. Ils classent juste 68,5 % et 63,9 % des cas de code (bon ou défaillant) quand on leur donne la description du problème. Sans elle, ils font moins bien : jusqu'à 24,8 % des morceaux de code corrects reçoivent des suggestions erronées (Cihan et al., arXiv 2505.20206). Mon skill lit le ticket avant le code.
• Plus de consignes ne veut pas dire moins de fausses alertes. Un « prompt » est le texte de consignes qu'on donne au modèle. Des prompts plus élaborés, qui demandent explications et corrections, font juger défaillant plus souvent du code correct (Jin et Chen, arXiv 2508.12358).
• Un modèle ne se corrige pas seul. Sans retour externe, l'auto-correction n'aide pas et dégrade parfois (Huang et al., ICLR 2024). Elle marche avec un signal fiable, comme un test exécuté (Kamoi et al., 2024). D'où ma règle : pas de finding sans preuve. Un correctif est prouvé quand l'annuler fait rougir un test, c'est-à-dire échouer.
• Plusieurs relecteurs ne valent pas autant de votes indépendants. Une famille de modèles, c'est un fournisseur et sa lignée : Claude, GPT, Gemini. Sur une tâche de langage, on a fait voter neuf modèles de sept familles. Leurs réponses se ressemblent tant qu'ils comptent pour environ deux votes indépendants. L'étude est un preprint d'un seul auteur (Kohli, arXiv 2605.29800). Mes relecteurs sont tous des modèles Claude, donc de la même famille : l'effet doit être pire chez moi.
• Le débat n'est pas supérieur au vote. Faire débattre des modèles ne bat pas de façon fiable le simple vote majoritaire (Smit et al., arXiv 2311.17371). Cela peut même dégrader la justesse des réponses (Wynn et al., atelier ICML 2025). Ma réfutation ressemble à un débat : sa valeur vient de mes preuves, d'aucune étude.
• À coût égal, un seul agent égale ou bat une équipe. Cela vaut pour des tâches de raisonnement, pas de code (Tran et Kiela, arXiv 2604.02460, preprint). Le coût se compte en tokens. Un modèle lit et écrit par petits morceaux de texte, souvent un mot ou un bout de mot. Chaque morceau est un token.

Un dernier chiffre vient d'un outil réel, CodeRabbit. Sur 31 073 retours à ses revues, dans 239 dépôts, 56,3 % des commentaires ont été rejetés. C'était surtout des fausses alertes, des redites ou du hors-sujet (Lin et al., arXiv 2607.03316). C'est un seul outil, mais l'ordre de grandeur prévient : plus d'un commentaire sur deux finit rejeté.

Ce que mon journal contient vraiment

Voici la sortie de la commande learn, qui analyse le journal. Elle ne garde que les revues dont les comptes s'additionnent : 189 sur 236, dont 182 dans les trois paliers du tableau. La dernière colonne donne le coût d'un finding, en tokens.

Le coût dépend du nombre d'agents. Un finding coûte environ 66 000 tokens avec 1 agent, 50 000 avec 4 à 5, puis 87 000 à partir de 6. Rien ne montre qu'ajouter des relecteurs aide au-delà de cinq.

Il faut pourtant se méfier de ces lectures : les revues ne portent pas sur les mêmes changements. Un « diff » est la liste des lignes modifiées par un changement. Sa taille médiane (la valeur du milieu) est de 158 lignes en quick, contre plus de 1 000 en deep.

Les revues à un seul agent relisent surtout un petit changement, tour après tour. La comparaison « un seul gros contre plusieurs », à budget égal, reste à faire.

Mon vrai trou est ailleurs : la façon de lire ce « 74 % ». Voici le chemin d'un finding.

Pour te représenter la chose, pense à une dictée. Un premier correcteur souligne des mots : les relecteurs. Un second raye ceux qu'il juge corrects : la vérification. Les mots restés soulignés ont l'air de fautes. Pourtant l'élève, c'est moi, peut en refuser un : « c'est le nom d'un personnage, c'est voulu ». Les compter mesure le second correcteur, pas ce que l'élève accepte.

Mon journal faisait pareil. Sa « précision », la part des findings qui survivent à la vérification, mesurait ce que laisse passer mon propre filtre, pas ce que j'accepte. Un finding confirmé peut très bien être rejeté par moi (« c'est voulu »). Les 236 lignes du journal ne portaient pas le sort de chaque finding. Un outil qui se note avec son propre filtre ne mesure que ce filtre.

Ce que j'ai changé

Le journal et la recherche m'ont fait changer trois choses, publiées dans le dépôt public du skill (version 1.26).

• Le sort de chaque finding. Le journal note maintenant combien de findings confirmés ont été corrigés, rejetés, ou renvoyés vers un autre ticket. Le sens de « précision » ne change pas. Une « acceptation » s'ajoute : les corrigés divisés par les corrigés plus les rejetés. Un exemple imaginé : 8 corrigés et 2 rejetés donnent 8 sur 10. Aucun relecteur ne décide du sort d'un finding : les comptes viennent de moi ou de la boucle de relecture.
• Le modèle des relecteurs est enregistré, pour pouvoir comparer plus tard la précision selon le modèle.
• Le plafond de 5 agents devient vérifiable. Le skill ne doit pas lancer plus de 5 agents par revue. La commande learn signale maintenant celles qui le dépassent (11 depuis que le plafond existe, 28 sur tout le journal). Elle calcule aussi combien de findings sortent pour 100 lignes de diff.

Un quatrième changement, la version 1.25, vient d'un livre sur les architectures d'agents (la façon d'organiser plusieurs agents), que j'ai relu en parallèle. Un relecteur peut planter ou rendre une réponse vide. Le skill le relance alors une fois. Au second échec, le rapport écrit « non couvert » à côté de l'aspect de la revue qu'il devait vérifier. Le verdict final ne peut plus être « approuvé ». Avant, un relecteur tombé en route laissait un trou que le rapport ne montrait pas.

Un agent distinct a relu le code de ces changements. Il a trouvé six défauts, dont un cas où deux écritures simultanées dans le journal pouvaient faire disparaître une ligne. Chacun a eu un test rouge avant la correction.

Ce que je n'ai pas fait

Je n'ai pas branché le skill sur les pull requests. Il est interactif, pensé pour mon poste : je le lance moi-même. Le brancher demanderait un programme qui se lance seul à chaque envoi de code. Il faudrait de la configuration, des mots de passe et une dépense à chaque envoi. Pour un usage solo, ça ne vaut pas la peine.

Je n'ai pas non plus ajouté de relecteur d'une autre famille de modèles. Il faudrait un second compte, chez le fournisseur de cet autre modèle. L'étude qui le justifie porte sur une tâche de langage, pas sur du code.

Reste l'expérience que la recherche réclame : un seul gros relecteur contre le groupe de relecteurs, sur les mêmes diffs, à budget égal. D'après mon estimation, elle coûterait environ 300 000 tokens de plus par revue d'essai. Je ne la lance pas tout de suite. Le journal doit d'abord accumuler quelques semaines de sorts de findings, pour que la comparaison parle d'acceptation et non de filtre.

Ce que je ne sais pas

Mon rappel, c'est-à-dire la part des défauts qu'un relecteur trouve, n'est mesuré que sur sept cas à bugs injectés. Un bug injecté est un défaut planté exprès pour tester le relecteur. Selon le bug, il va de 3 sur 3 à 1 sur 3. Sept cas ne tranchent qu'un écart grossier.

Aucun papier vérifié ne donne non plus la taille de diff idéale. Aucun ne donne le point à partir duquel plusieurs agents rapportent plus qu'ils ne coûtent. Les ratios de tokens que je lisais sur les équipes d'agents ne se retrouvent dans aucun des papiers que l'agent de recherche a ouverts.

Conclusion

Le plus utile de cette recherche n'était ni un papier ni un outil. C'était de découvrir que ma propre mesure se notait avec le filtre qu'elle devait juger. La seule note qui compte, c'est ce que le lecteur de la revue fait des findings : il les corrige, ou il les écarte. Tout le reste, l'architecture comprise, est une hypothèse tant que ce chiffre manque.

Si tu fais relire ton code par une IA, note ce que tu fais de chaque défaut (corrigé, rejeté, renvoyé vers un autre ticket). Dix lignes de journal suffisent à voir si ta revue sert à quelque chose.

Le livre sur les architectures d'agents dont je parle plus haut a sa fiche dans ma bibliothèque. Le skill est public : github.com/ohugonnot/claude-skills, dossier senior-review, avec l'historique de chaque version.