Benchmark d'agents de revue de code : comment évaluer un réviseur et exécuter c-CRAB sur votre propre code

Comment savoir si un agent de revue de code est bon ? Pendant la majeure partie de la brève histoire de ce domaine, la réponse était « mesurer à quel point ses commentaires se rapprochent de ceux d’un relecteur humain » — ce qui semble raisonnable jusqu’à ce qu’on l’essaie réellement, car deux relecteurs peuvent soulever le même problème avec des mots complètement différents. Le Code Review Agent Benchmark — l’article est arXiv:2603.23448, son jeu de données est c-CRAB — est la première tentative sérieuse de noter une revue selon ce que le fait d’agir en conséquence produit plutôt que selon son phrasé. Il a converti 234 commentaires de revue humaine en tests exécutables, a fait passer quatre relecteurs largement utilisés — PR-Agent, Devin, Claude Code et Codex — et a constaté que, tous ensemble, ils réussissent 41,5 % de ces tests, « seulement environ 40 % » selon les termes de l’article. Cette page est un guide : comment lire ce résultat sans le déformer, comment exécuter c-CRAB vous-même, et que faire lorsque votre base de code n’est pas du tout dans le benchmark.

Le chiffre principal est l'élément le moins utile de cette page. Ce qui est utile, ce sont la méthode et les modes d’échec : pourquoi chaque système de notation antérieur mesurait la mauvaise chose, ce que coûte le fait de noter une critique avec des tests exécutables à la place, et pourquoi « les agents de révision ne détectent que 40 % des bugs » est une triple erreur de lecture du résultat réel. Tout ici est une lecture communautaire du benchmark publié et de l’expérience des praticiens qui l’exécutent — et non des conseils des fournisseurs d’outils impliqués.

Pourquoi les métriques évidentes ne fonctionnent pas

Avant c-CRAB, les évaluations des agents de revue de code se répartissaient en un petit nombre de familles, et le tableau comparatif de l'article (Tableau 1) en expose la lignée. La plus ancienne est le chevauchement de texte — BLEU, ROUGE, chrF et apparentés, utilisés par des benchmarks comme CodeReviewer et ContextCRBench. L'idée est qu'un commentaire d'agent est bon lorsque ses n-grammes correspondent à ceux d'un humain. Cette idée échoue sur le seul type de cas que l'on rencontre partout en revue de code : le même défaut décrit avec des mots différents.

L'étude de cas de l'article est l'exemple le plus net. Sur une pull request dans python-telegram-bot (PR #3514), le relecteur humain et Codex ont tous deux signalé le même bug de robustesse d'indexation imbriquée. La revue de Codex était comportementalement correcte — un agent de codage qui l'a suivie a produit un correctif qui a réussi le test exécutable. Pourtant, les métriques textuelles lui ont attribué BLEU-4 0,00, ROUGE-L 7,02, chrF 20,74 et une similarité d'embedding de 54,59. Chevauchement de n-grammes nul, et la revue avait raison. Même préoccupation, mots différents : les métriques de chaînes ne pouvaient pas le voir. La similarité d'embedding est une amélioration partielle — 54,59 par rapport à un test confirmé reste loin d'un seuil utilisable — et elle hérite du même problème sous une forme plus douce.

LLM-as-judge, où un modèle compare l'évaluation de l'agent à celle de l'humain et vote, corrige le problème de vocabulaire mais en introduit trois nouveaux, que l'article nomme directement : le biais, l'instabilité et la sensibilité à la conception des prompts. Exécutez deux fois la même comparaison et un juge peut vous rendre des verdicts différents ; reformulez le prompt d'évaluation et les classements bougent. Lorsque vous choisissez entre deux évaluateurs qui se situent à trois points d'écart sur le même benchmark, un juge avec une telle variance ne peut pas appuyer une décision — et un score que vous ne pouvez pas reproduire n'est pas un score.

Ce qu'un oracle exécutable apporte — et ce qu'il coûte

L'idée sur laquelle repose c-CRAB est à la fois simple et radicale : au lieu de se demander « la critique ressemble-t-elle à celle d'un humain ? », demandez-vous « si l'on agit sur la critique, le code est-il corrigé ? ». Chaque commentaire de revue humain retenu est converti en un test exécutable qui capture le problème sous-jacent. Un commentaire de revue est considéré comme correct si le fait d'y donner suite produit un correctif comportementalement correct qui fait passer le test — et chaque instance est fournie avec un environnement Docker exécutable, si bien que « faire passer le test » est un fait et non un jugement.

L'article définit deux types de tests. Les tests comportementaux « importent et exécutent le code testé à l'exécution », en appelant des fonctions « avec des entrées spécifiques » et en vérifiant « les sorties ou en confirmant les exceptions ». Les tests structurels « inspectent le texte du code source, recherchent des motifs et examinent les surfaces d'API pour déterminer si les modifications de code souhaitées ont été apportées ». La répartition finale est de 42 tests comportementaux (17,9 %) et 192 tests structurels (82,1 %) — et ce déséquilibre mérite une phrase honnête : la majeure partie de cet oracle est une correspondance de motifs sur le texte source, et non une exécution du code. L'étalon-or est le test comportemental ; la majorité du jeu de données en est la version pragmatique.

Construire l'oracle est un entonnoir en quatre étapes, et chaque étape jette des choses :

• Jeu de données initial — 671 PRs, 1 313 commentaires de revue.

• Filtrage des revues — 410 PRs, 595 commentaires. Un classifieur LLM, calibré sur un ensemble de référence de 100 commentaires annotés manuellement, ne conserve que les problèmes objectivement vérifiables et écarte les retours conversationnels ou subjectifs.

• Construction de l'environnement exécutable — 410 PRs, 595 commentaires. Une image Docker par PR, la résolution des dépendances se repliant sur un agent de codage lorsque l'automatisation échoue.

• Conversion des commentaires NL en tests — 339 PRs, 481 commentaires. Généré avec GPT-5.2 sous une boucle de raffinement guidée par l'exécution (jusqu'à trois tentatives) ; un test n'est conservé que s'il échoue sur la version avant et réussit sur la version après.

• Validation avec un agent de codage — 184 PRs, 234 commentaires (final). Claude Code sur un backend Sonnet-4.6 essaie de corriger le code en se basant uniquement sur le commentaire de révision humain ; les cas où il ne parvient pas à faire passer le test sont écartés.

Environ 27 % des pull requests initiales survivent. Disons-le clairement, car c’est le prix honnête d’un oracle fondé sur des tests : si un commentaire n’est pas assez actionnable pour devenir un test qui échoue, ou si l’environnement ne peut pas être construit, ou si un agent de codage compétent ne peut pas corriger le code à partir du seul commentaire, l’instance est écartée. C’est aussi pour cela que le benchmark est petit. 184 instances de PR et 234 commentaires validés, c’est un ensemble de données que l’on peut lire, pas un corpus dans lequel on peut se noyer — et pour un oracle qui doit exécuter de vrais environnements Docker, la petite taille est un atout.

Pour donner une échelle : une instance moyenne touche 418,1 lignes modifiées, les tests font en moyenne 31,8 lignes, et il y a 1,27 test par instance. Deux annotateurs étaient d'accord 84 % du temps — sur 50 instances échantillonnées — pour savoir si un test généré reflétait fidèlement la préoccupation du réviseur humain.

Un défaut bibliographique que vous rencontrerez si vous lisez l'article vous-même : le tableau des données (Tableau 4) répertorie 67 dépôts, tandis que la section Menaces à la validité indique « 184 instances de pull requests avec 234 oracles vérifiables répartis sur 56 dépôts ». L'article donne les deux chiffres à des endroits différents et ne les concilie pas. Ne choisissez pas un chiffre préféré et ne faites pas de moyenne — citez chacun à l'endroit où il apparaît. Les écarts comme celui-ci sont précisément le genre de détail que les lecteurs utilisent pour décider si un benchmark vaut leur temps.

Pour la diligence raisonnable en matière d'indépendance : l'article divulgue qu'un auteur est affilié à SonarSource, et précise que les résultats ne doivent pas être interprétés comme « an evaluation of the quality of products at SonarSource ». C'est leur avertissement, cité plutôt que paraphrasé.

Comment lire un score sur c-CRAB sans le citer de travers

La métrique principale est le taux de réussite : pour chaque instance, la proportion des tests de cette PR qui réussissent, moyennée sur les 184 instances. Voici le tableau complet des résultats de l'article, une ligne par évaluateur. La ligne « humain » est un marqueur d'échelle plutôt qu'un concurrent — les humains ont écrit l'oracle, donc ils obtiennent 100 % par construction :

• Claude Code — 1 336 commentaires, 7,3 par PR, 32,1 % au total (38,1 % comportementaux, 30,7 % structuraux).

• Devin — 1 344 commentaires, 7,3 par PR, globalement 24,8 % (comportemental 31,0 %, structurel 23,4 %).

• PR-Agent — 524 commentaires, 2,8 par PR, globalement 23,1 % (comportemental 38,1 %, structurel 19,8 %).

• Codex — 324 commentaires, 1,8 par PR, globalement 20,1 % (comportemental 38,1 %, structurel 16,1 %).

• Humain — 234 commentaires, 1,3 par PR, 100 % par construction.

Trois corrections, car le « only around 40 % » du résumé est le chiffre le plus mal cité de ce coin de la conversation sur les codeurs IA en ce moment. Premièrement, le chiffre de 41,5 % — 97 des 234 tests réussis par au moins un outil — est une union sur les quatre relecteurs : un test compte une fois si un agent quelconque l’a réussi. Aucun agent n’a obtenu 41,5 % à lui seul ; le meilleur score individuel est celui de Claude Code, à 32,1 %. Deuxièmement, la ligne « humain » est l’oracle, pas un concurrent ; la répéter comme « les humains battent les bots » est une erreur de catégorie. Troisièmement, et c’est le plus important : c-CRAB n’accorde aucun crédit pour un problème valide que le relecteur humain n’a jamais soulevé. L’oracle, c’est l’intention de la relecture humaine. Un agent qui trouve un vrai bug dont personne n’a parlé obtient zéro pour celui-ci. Donc « les agents de revue IA ne détectent que 40 % des bugs » est faux à trois égards — c’est une union, ce n’est pas un taux de détection de bugs, et cela mesure l’accord avec les relecteurs humains, pas l’exactitude totale.

Le volume de commentaires est le piège.

Le nombre le plus intéressant dans les résultats n'est pas le gagnant. Claude Code et Devin ont chacun publié plus de 1 300 commentaires — environ 7,3 par PR — pour atteindre 32,1 % et 24,8 %. Codex a publié 324 commentaires, soit environ 1,8 par PR, et a atteint 20,1 %. La référence humaine est de 1,3 commentaire par PR. Le volume n'est pas la couverture : environ cinq fois plus de commentaires n'achètent même pas le double du taux de réussite. Si vous choisissez un relecteur, le vrai coût de tous ces commentaires supplémentaires est la fatigue de relecture humaine — chaque commentaire publié par un agent est un jugement qu'une personne doit trier.

Le constat sur l'utilité va dans l'autre sens, et c'est ce qui empêche que ce soit une simple histoire de « bots bruyants ». Les auteurs ont examiné manuellement 92 commentaires répartis sur 6 PR et en ont jugé 84 % (77/92) utiles — PR-Agent 94 %, Codex 88 %, Devin 85 %, Claude Code 78 %. La plupart des commentaires qui échouent au test ne sont donc pas du bruit ; ils portent sur quelque chose que le réviseur humain n'a pas soulevé. L'échantillon est petit — 92 commentaires, 6 PR — et il vaut la peine de le mentionner dans la même phrase que les pourcentages.

Ce dont les deux camps parlent réellement explique la forme des résultats. Les évaluateurs humains penchaient vers la maintenabilité, la conception et la documentation ; les outils vers la robustesse, les tests et la gestion des erreurs. L'article interprète cela comme un argument en faveur de la collaboration humain-agent plutôt que du remplacement — et c'est aussi la meilleure explication disponible pour comprendre pourquoi les scores semblent bas. Un évaluateur pointu sur les cas limites mais discret sur la conception manquera systématiquement les catégories que les humains signalent, et l'oracle est entièrement construit à partir des signalements humains.

Les praticiens qui ont travaillé sur ce sujet arrivent au même constat. Une analyse détaillée de Daniel Vaughan, qui nomme ce travail CR-bench, aboutit à la même conclusion et le transforme en flux de travail : laisser l'agent effectuer le balayage de robustesse et de correction, réserver aux humains la conception, les conventions et l'architecture — les catégories où les agents obtiennent les moins bons résultats — et guider l'agent avec des instructions de revue qui désignent les catégories faibles. Sa mise en garde la plus utile pour quiconque lit le classement : « l'utilité n'est pas la même chose que le taux de réussite », car la suite de tests exige que le correctif corresponde à celui que l'humain avait prévu, et un correctif alternatif valide échoue au test. Le chemin qui mène de 20 % à un score nettement supérieur, selon sa lecture, n'est pas une mise à niveau du modèle — c'est du travail de configuration.

Exécuter c-CRAB vous-même

Tout ce qui précède consiste à lire les résultats d'autres personnes. Le package de réplication rend le benchmark exécutable — il se trouve à l'adresse c-CRAB-Benchmark/dataset sur GitHub — et le README est honnête sur ce que cela implique.

Prérequis : code>uv sync/code>; Docker; et soit code>OPENAI_API_KEY/code> ou code>ANTHROPIC_API_KEY/code> (Claude Code lit également les identifiants depuis code>~/.claude/.credentials.json/code>, monté dans les conteneurs par défaut). La disposition comprend cinq répertoires : code>pipeline//code> (logique du pipeline et prompts), code>execution//code> (générateurs d'images Docker et utilitaires d'exécution), code>results_preprocessed//code> (sous-ensemble du benchmark publié), code>results_pipeline_funnel//code> (les fichiers JSONL stage0–stage4 et le résumé du funnel), et code>raw_results_compressed//code> (sorties brutes des expériences). Les cinq étapes, dans l'ordre :

1. Construire les environnements Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Des images préconstruites sont également publiées sous l’organisation GitHub Packages c-CRAB-Benchmark si vous préférez ne pas effectuer la construction.

2. Générer les tests — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Collectez les avis de référence — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Configurez les identifiants de l'outil externe correspondant avant cette étape.

4. Exécutez la résolution d'agent — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Évaluer — répéter une fois par outil : code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

Deux choses que le README ne mentionne pas. Ajouter un cinquième réviseur implique de modifier code>run_batch_baselines.py/code> — c'est là que se trouvent les prompts de revue de base par outil, et il n'y a pas d'interface de plugin ; le README ne documente aucun point d'extension plus propre. Et le dépôt ne contient aucun fichier de licence explicite, donc ne supposez pas que le code est sous licence MIT ou Apache — l'article est sous CC BY 4.0, et les conditions du code lui-même ne sont pas précisées.

Le coût est l'autre élément non mentionné. Le document ne publie ni chiffres de tokens ni montants en dollars pour l'exécution du pipeline, traitez donc tout chiffre de coût cité en ligne comme non vérifié. Ce que la structure implique est assez clair : une image Docker par PR sur 184 instances, plus une passe de résolution par agent de codage et une passe d'évaluation par outil. Ce n'est pas un après-midi à l'échelle d'un ordinateur portable — prévoyez une véritable puissance de calcul.

Lorsque vous ne pouvez pas vous permettre des oracles exécutables.

La position honnête de la plupart des équipes est la suivante : le benchmark a raison de dire qu'un juge LLM ne peut pas évaluer les revues, mais construire un oracle basé sur des tests pour ses propres PRs est un gros chantier. La distinction à faire est entre un juge LLM comme évaluateur et un juge LLM comme filtre. Le rejet par c-CRAB du juge comme oracle ne rend pas un juge inutile dans un outil de revue — un juge qui regroupe les constatations en double et élimine les faibles peut encore améliorer la précision. Le mode de défaillance contre lequel il faut se prémunir est l'indépendance.

Un juge qui s'exécute sur le modèle même du relecteur est d'accord avec lui-même : il lit la revue, la trouve plausible et signale un succès sans rien changer. Un juge d'un autre fournisseur réduit cet accord avec soi-même — il ne transforme pas un juge en test, mais il met fin au tampon complaisant. Nous pouvons vous montrer un exemple concret et vérifiable de ce garde-fou précis, car notre propre harnais est ouvert : Orca-Code-Review sur GitHub est sous licence MIT, et sa recette de routage énonce la règle dans les propres termes du dépôt — le juge « NE DOIT PAS NOMMER LE MODÈLE PAR DÉFAUT », car « sur le modèle du relecteur lui-même, il est d'accord avec lui-même, si bien que la passe devient inerte tout en signalant un succès ». L'Action ne nomme jamais de modèle ; c'est la recette qui décide. Dans la configuration fournie, le relecteur par défaut est deepseek/deepseek-v4-flash-0731, et une règle qui correspond à l'en-tête code>x-cr-lens: judge/code> envoie la passe du juge vers z-ai/glm-5.3 — un fournisseur différent. C'est un parallèle de conception avec l'argument de c-CRAB, pas un résultat : nous ne sommes pas dans le benchmark et il n'y a pas de score c-CRAB pour notre relecteur. Mais c'est l'atténuation pratique offerte à quiconque ne peut pas construire d'oracles exécutables, et c'est peu coûteux lorsque le juge et le relecteur peuvent vivre chez des fournisseurs différents derrière une seule clé — ce à quoi sert un routeur. Sur OrcaRouter, le relecteur et son juge sont deux lignes d'un DSL de routage, et vous payez le tarif public du fournisseur, sans aucune marge.

Quand votre code n'est pas dans le benchmark.

184 PRs répartis sur 56 ou 67 dépôts publics, ce n'est pas votre base de code, et ça ne l'a jamais été. La partie transférable, c'est la méthode, et vous pouvez l'appliquer à votre propre historique à une échelle bien plus réduite. Prenez des PR fusionnées qui ont reçu des commentaires de revue humaine. Pour un échantillon de ces commentaires, écrivez un test qui échoue avant que la revue ne soit prise en compte et qui réussit après — la propriété « échec puis succès » est tout le jeu. Lancez votre relecteur candidat sur le diff d'avant revue. Ensuite, vérifiez si le fait de suivre ses commentaires fait passer le test. Ce que vous obtenez est un nombre calculé sur le code que vous livrez réellement, ce qui vaut plus qu'une position au classement. Ce que ça coûte, c'est exactement le mur contre lequel l'article est tombé : il vous faut des environnements par PR reproductibles, parce qu'un test qui ne réussit que sur votre machine n'est pas un oracle.

Vous n'avez pas besoin de 234 tests. Une douzaine de tests bien choisis sur des PR que votre équipe a réellement débattues vous en apprendra plus sur votre relecteur qu'un score de benchmark. Et une analyse parallèle de praticiens sur cette famille de benchmarks est sans détour concernant le goulot d'étranglement : la précision du classificateur LLM quant à savoir si un commentaire est un problème valide et vérifiable se situe entre 66 % et 85 %. Traitez donc le filtrage automatique comme une présélection et conservez une étape de jugement humain avant que quoi que ce soit ne devienne un test. Le même article note que ReviewBench de LangChain, construit indépendamment sur la même idée de commentaire-à-test, ne récupère qu'environ 30 % de ses problèmes de référence au mieux — soit le même ordre de grandeur que les 20–32 % de c-CRAB, et un rappel que les écarts de classement à un chiffre entre outils sont souvent plus petits que le bruit de votre propre configuration.

Si vous vous demandez quel outil de revue de code acheter, c'est une autre question — notre guide d'achat des agents de revue de code couvre le comparatif bot versus agent, la tarification par siège ou par jeton, et les cas où l'auto-hébergement est gagnant — et une fois que vous en avez un, le coût d'exécution d'un harnais de revue à chaque push est traité dans notre guide explicatif sur la revue de code automatisée. Cette page ne traite que de la mesure, et l'article complémentaire détaille l'anatomie du benchmark : l'entonnoir de construction, les statistiques du jeu de données et le tableau complet des résultats.

FAQ

41,5 % est-il le meilleur score d'agent ? Non. 41,5 % est l'union des quatre outils — un test compte une fois si l'un d'eux l'a réussi. Le meilleur score individuel est celui de Claude Code avec 32,1 %.

c-CRAB mesure-t-il le nombre de bogues qu'un relecteur détecte ? Non. Il mesure à quel point une revue correspond à ce qu'un relecteur humain a signalé, converti en tests exécutables. Un défaut réel que l'humain n'a jamais mentionné obtient un score de zéro, aussi valide soit-il.

Les évaluateurs humains ont-ils « battu » les bots ? La ligne 100 % humaine est l'oracle lui-même — les humains ont écrit les tests — c'est donc un marqueur d'échelle, pas un concurrent.

Est-ce que c-CRAB est la même chose que CR-bench ?Oui. Le jeu de données s'appelle c-CRAB ; certaines sources tierces l'appellent CR-bench, mais il n'y a qu'un seul benchmark ici.

Combien cela coûte-t-il de l’exécuter ? L’article ne publie aucun chiffre de coût. Une image Docker par PR sur 184 instances, plus une passe de résolution d’agent, implique de la vraie puissance de calcul — pas un après-midi à l’échelle d’un ordinateur portable.

En résumé

La contribution de c-CRAB n'est pas le classement — c'est la démonstration qu'une revue peut être notée en exécutant ses conseils, et que les méthodes de similarité textuelle et de jugement par LLM qui l'ont précédée évaluaient la mauvaise chose. Si vous ne deviez retenir qu'une chose, que ce soit la correction en trois parties : 41,5 % est une union, la ligne humaine est l'oracle, et le benchmark n'accorde aucun crédit aux défauts que les humains n'ont jamais soulevés. Et si vous voulez un chiffre sur lequel agir, la méthode se transpose : des tests qui échouent puis passent sur vos propres PR fusionnées, une étape d'arbitrage humain, et, si vous ne pouvez pas construire d'oracles exécutables, au moins un juge dont le modèle est indépendant de celui du critique.

Si vous préférez mesurer un réviseur plutôt que de débattre à son sujet, partez d'un harnais que vous pouvez lire. OrcaCode Review exécute une passe de révision plus un juge de vérification indépendant, par jeton plutôt que par siège, et chaque prompt qu'il contient est public — afin que vous puissiez le pointer vers un benchmark comme celui-ci et obtenir votre propre chiffre au lieu du nôtre.