c-CRAB, le benchmark des agents de revue de code : ce qu'il mesure, ce qu'il a découvert, et ce que 41,5 % signifie vraiment

Un agent de revue de code et un relecteur humain ont examiné la même pull request et ont soulevé la même préoccupation. Donner suite au commentaire de l’agent corrige le bug ; le test passe. Et pourtant, toutes les métriques de similarité textuelle calculées par les auteurs ont jugé la revue de l’agent comme essentiellement sans lien avec celle de l’humain : BLEU-4 0,00, ROUGE-L 7,02, chrF 20,74, similarité d’embedding 54,59. Même préoccupation, mots différents, et la méthode standard d’évaluation d’une revue ne pouvait pas voir qu’ils étaient d’accord. Cet exemple à lui seul est l’argument derrière c-CRAB (prononcé « see-crab »), le benchmark d’agents de revue de code publié sous arXiv:2603.23448.

c-CRAB évalue les agents de revue de code, et non les agents qui écrivent du code. Étant donné une pull request — qui peut provenir d'un humain ou d'un agent de codage — un agent de revue produit une revue, et c-CRAB note cette revue selon que le fait de la suivre aboutit à une correction comportementalement correcte. Ce benchmark a été conçu par les chercheurs en génie logiciel Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen et Abhik Roychoudhury, et il évalue quatre outils : PR-Agent, Devin, Claude Code et Codex. L'un des auteurs est affilié à SonarSource, et l'article précise explicitement ce que cela signifie et ne signifie pas, dans ses propres termes : « Les points de vue et conclusions exprimés dans cet article sont ceux des seuls auteurs et ne représentent pas les politiques officielles ni les soutiens de SonarSource. En outre, les résultats présentés ici sont indépendants et ne doivent pas être interprétés comme une évaluation de la qualité des produits de SonarSource. »

Deux remarques avant d’entrer dans le détail. Certains articles de tiers désignent ce même travail sous le nom “CR-bench” ; il s’agit du même benchmark, et cette page utilise c-CRAB tout au long. Toutes les figures ci-dessous sont les résultats rapportés par l’article, tels que lus aujourd’hui dans l’article et le package de réplication — non ré-exécutés indépendamment — et l’interprétation est la nôtre, ainsi que la discussion des praticiens que l’article a déjà suscitée. Rien de tout cela ne constitue une recommandation des fournisseurs dont les outils ont été évalués. Et si vous êtes encore en train de décider s’il faut lancer un agent de revue de code, notre guide de l’acheteur sur les agents de revue de code est un meilleur point de départ ; cette page traite de la manière dont ces agents sont mesurés.

Pourquoi c-CRAB note les avis avec des tests, et non avec un juge LLM

La manière habituelle de noter un agent de revue de code est de comparer sa revue à celle d’un humain, avec un LLM comme juge ou une métrique de similarité textuelle. Les auteurs de c-CRAB rejettent les deux. Le LLM comme juge, soutiennent-ils, souffre de biais, d’instabilité et de sensibilité aux invites, ce qui rend difficile une notation reproductible et cohérente. Et l’étude de cas ci-dessus montre ce que les métriques de chaînes de caractères mesurent réellement : le libellé, pas l’efficacité. Sur cette pull request de python-telegram-bot, la revue de Codex disait la même chose que l’humain, et BLEU-4 et ROUGE-L n’ont pas pu le reconnaître.

Ainsi, c-CRAB fait l'inverse. Chaque commentaire de revue humaine 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 — un correctif qui fait passer le test. Chaque instance est livrée avec un environnement Docker exécutable, de sorte que la décision de réussite/échec est prise en exécutant du code, et non en demandant à un autre modèle à quel point deux textes sont similaires. C'est pourquoi cela compte : le travail d'une revue est de changer ce qu'un développeur fait, et un test est le seul signal de notation qui mesure directement ce changement.

L'article définit deux types de tests, selon ses propres termes : “Les tests comportementaux importent et exécutent le code testé au moment de l'exécution. Ils invoquent les fonctions testées avec des entrées spécifiques, vérifient les sorties ou valident les exceptions. En revanche, les tests structurels inspectent le texte du code source, identifient des motifs et vérifient 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 %). Il convient d'être honnête : la majeure partie de l'oracle repose sur la correspondance de motifs dans le texte source, et non sur l'exécution du code. Ce déséquilibre est une réelle limitation à garder à l'esprit.

Comment le benchmark a été construit, et ce que coûte l’entonnoir.

c-CRAB est construit à partir du jeu de données existant inclusionAI/SWE-CARE, qui fournit des instances de pull-request avec des métadonnées de commit ; la propre contribution de c-CRAB est l’oracle, et non le corpus de PR. Le pipeline de curation applique quatre filtres, et chacun d’eux a un coût en instances. L’article présente l’entonnoir comme suit :

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

• 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 d'environnements exécutables — 410 PRs, 595 commentaires. Une image Docker par PR, avec un agent de codage comme solution de repli pour la résolution des dépendances lorsque l'automatisation échoue.

• Conversion de commentaires en langage naturel en tests — 339 PRs, 481 commentaires. Les tests sont générés avec GPT-5.2 dans une boucle de raffinement guidée par l’exécution comportant jusqu’à trois tentatives ; un test n’est conservé que s’il échoue sur le code d’origine et réussit après la correction.

• Validation avec un agent de codage — 184 PRs, 234 commentaires. Claude Code sur un backend Sonnet-4.6 tente de corriger le code en se basant uniquement sur le commentaire de revue humaine ; les cas où il ne parvient pas à faire passer les tests sont écartés. Il s'agit de l'ensemble final.

Environ 27 % des pull requests initiales survivent. C'est le prix honnête d'un oracle basé sur des tests, et c'est aussi la raison pour laquelle le benchmark est petit plutôt que tentaculaire. L'ensemble survivant : 184 instances de PR, 234 commentaires de revue validés, 1,27 test par instance, 418,1 lignes modifiées par PR en moyenne, 31,8 lignes par test. Deux annotateurs ont jugé indépendamment si un test généré reflétait fidèlement la préoccupation du relecteur humain, sur 50 instances échantillonnées, et ont été d'accord dans 84 % des cas.

Une divergence que vous remarquerez si vous lisez attentivement : le tableau du jeu de données répertorie 67 dépôts, tandis que la section sur les menaces à la validité indique “184 instances de pull requests avec 234 oracles vérifiables dans 56 dépôts.” L'article donne les deux chiffres, à des endroits différents, et nous n'allons pas les moyenner ni choisir silencieusement celui qui arrange. Les lecteurs utilisent précisément ce genre de détail pour juger si un benchmark mérite leur temps, alors les deux sont reproduits ici tels qu'ils ont été publiés.

Les résultats, et comment les lire

Le taux de réussite est le taux de réussite agrégé des tests : pour chaque instance, il s’agit de la part des tests de cette PR qui réussissent, et le chiffre principal est la moyenne sur l’ensemble des instances. L’article indique, par outil :

• Claude Code — 1 336 commentaires, 7,3 par PR — comportemental 38,1 %, structurel 30,7 %, global 32,1 %

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

• PR-Agent — 524 commentaires, 2,8 par PR — comportemental 38,1 %, structurel 19,8 %, global 23,1 %

• Codex — 324 commentaires, 1,8 par PR — comportemental 38,1 %, structurel 16,1 %, global 20,1 %

• Humain — 234 commentaires, 1,3 par PR — 100 % par construction. Les humains ont écrit l'oracle, donc cette ligne est un marqueur d'échelle, pas un concurrent.

Lisez attentivement ces lignes avant d'en citer une. La “seulement environ 40 %” du résumé est une union : 41,5 % des 234 tests ont été réussis par au moins un des quatre outils. Ce n'est pas le score d'un seul agent — le meilleur score individuel est celui de Claude Code avec 32,1 % — et cela ne signifie pas que les quatre outils ensemble ont détecté 40 % des défauts réels. La section ci-dessous explique pourquoi.

Le chiffre le plus intéressant 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 en a publié 324, soit environ 1,8 par PR, pour atteindre 20,1 %. La base de référence humaine est de 1,3 commentaires par PR. Faites le calcul : environ quatre fois plus de commentaires permettent d'obtenir bien moins que le double du taux de réussite. Le volume n'est pas la couverture. Un relecteur bavard n'est pas la même chose qu'un relecteur utile, et c-CRAB est le premier benchmark conçu pour le démontrer.

L'utilité joue dans l'autre sens.

Les faibles taux de réussite se lisent comme une condamnation jusqu'à ce qu'on regarde ce que les auteurs ont mesuré d'autre. Ils ont inspecté manuellement 92 commentaires sur 6 PR et ont jugé que 84 % d'entre eux étaient utiles (77 sur 92) — PR-Agent 94 %, Codex 88 %, Devin 85 %, Claude Code 78 %. Donc la plupart des commentaires qui échouent à un test c-CRAB ne sont pas du bruit ; ils portent sur quelque chose que le relecteur humain n'a pas soulevé. L'échantillon est petit — 92 commentaires, 6 PR — et l'article le dit, et nous devrions le dire aussi.

La même tendance se retrouve dans les sujets abordés par les évaluateurs. Les évaluateurs humains penchaient pour la maintenabilité, la conception et la documentation ; les outils, pour la robustesse, les tests et la gestion des erreurs. L'article y voit un argument en faveur d'une collaboration humain-agent plutôt que d'un remplacement. C'est aussi la meilleure explication disponible pour des scores aussi bas : les agents et les humains n'examinent souvent pas les mêmes choses, et l'oracle ne récompense que la liste de l'humain.

Ce que c-CRAB ne peut pas voir

Le benchmark est explicite sur son angle mort, et nous aussi. c-CRAB n'accorde aucun crédit pour un problème valide que le relecteur humain n'a jamais soulevé. L'oracle est l'intention de la revue humaine : un agent qui trouve un vrai bug que personne n'a mentionné obtient zéro pour cela. L'article le dit directement — les outils de revue automatisés peuvent générer d'autres commentaires précieux que les relecteurs humains n'ont pas identifiés, mais “comme les autres benchmarks existants, c-CRAB n'évalue pas directement ces commentaires supplémentaires.”

Cette seule phrase est la correction à apporter à la plupart des articles traitant de ce résultat. Quiconque cite « les agents de revue ne résolvent que 40 % » comme si cela mesurait combien de défauts réels les agents détectent se méprend sur ce nombre. Il mesure combien de préoccupations soulevées par des humains les agents, conjointement, ont réussi à résoudre — une affirmation plus étroite et bien plus honnête.

L'exécuter vous-même

Si vous souhaitez reproduire les chiffres ou ajouter votre propre critique, le package de réplication est public sur c-CRAB-Benchmark/dataset. Le README est la véritable documentation, et il est honnête sur la forme de la chose. La configuration se fait avec code>uv sync/code> ; vous avez besoin de Docker et d'une code>OPENAI_API_KEY/code> ou d'une code>ANTHROPIC_API_KEY/code>, et Claude Code lit également les identifiants depuis code>~/.claude/.credentials.json/code>. L'organisation publie également des images Docker préconstruites pour les environnements.

La structure : code>pipeline//code> contient la logique du pipeline et les invites, code>execution//code> les constructeurs d’images Docker et les utilitaires d’exécution, code>results_preprocessed//code> le sous-ensemble de benchmark publié (410 instances prétraitées), code>results_pipeline_funnel//code> les fichiers JSONL stage0–stage4 et le résumé de l’entonnoir, et code>raw_results_compressed//code> les sorties brutes des expériences.

Reproduire l’exécution complète comporte cinq étapes : construire les environnements Docker (code>execution.build_swe_care/code>), générer les tests (code>run_testgen_full.sh/code>), collecter les revues de référence (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), lancer la résolution par les agents (code>run_batch_agent_resolution.py/code>), puis évaluer (code>run_batch_tool_eval.py --tool <name>/code>). Si vous voulez ajouter un cinquième évaluateur, sachez que le point d’extension n’est pas une interface de plugin : les prompts d’évaluation de référence pour chaque outil se trouvent dans code>run_batch_baselines.py/code>, et le README ne documente pas de moyen plus propre — vous modifiez ce script.

Deux autres faits avant que vous le cloniez. L'article est sous licence CC BY 4.0 ; la page du dépôt n'indique pas de licence pour le code, donc n'en supposez pas une. Et l'article ne publie aucun chiffre de coût ni d'utilisation de jetons pour exécuter le benchmark — cela n'est pas publié, donc nous n'allons pas l'inventer. Ce que le pipeline implique en revanche : une image Docker par PR sur 184 instances, plus une passe de résolution par agent, ce n'est pas un après-midi à l'échelle d'un ordinateur portable.

Ce que cela signifie pour quiconque déploie un pipeline de revue

L’argument central de c-CRAB est qu’un juge LLM est un oracle peu fiable. Si vous ne pouvez pas construire des oracles exécutables — et la plupart des équipes ne le peuvent pas — la meilleure atténuation disponible est de ne jamais laisser le juge s’exécuter sur le modèle qui a produit la critique. Un juge qui partage le modèle du réviseur est d’accord avec lui-même, et la passe de vérification se transforme en un simple tampon qui renvoie quand même un nombre.

C’est exactement l’échec contre lequel la recette de routage derrière le relecteur que nous livrons protège — et c’est un parallèle de conception avec la critique de c-CRAB, pas un résultat de benchmark. Le harnais exécute de toute façon un juge LLM, comme seconde passe, qui regroupe les constats, note chaque regroupement de 0 à 1 pour déterminer s’il s’agit d’un défaut concret dans ce changement, et écarte tout ce qui est sous un seuil. La recette qui le régit, code>recipes/orcacode-review.dsl.yaml/code>, est un fichier public. L’Action ne nomme jamais de modèle : elle appelle un alias de routeur, et la recette décide. Telle que provisionnée, la recette tient en quatre lignes — le relecteur par défaut est code>deepseek/deepseek-v4-flash-0731/code>, et une règle correspondant à l’en-tête code>x-cr-lens: judge/code> envoie la passe du juge vers code>z-ai/glm-5.3/code>, un fournisseur différent. Les termes mêmes de la recette exigent que le juge « NE DOIT PAS NOMMER LE MODÈLE PAR DÉFAUT », car sur le propre modèle du relecteur, il « est d’accord avec lui-même, si bien que la passe devient inerte tout en signalant un succès ».

Un juge d'un autre fournisseur réduit l'auto-accord ; cela ne transforme pas un juge LLM en test. c-CRAB n'a pas testé notre relecteur, et nous n'allons pas sous-entendre le contraire. OrcaCode Review effectue une passe de relecture plus un juge de vérification indépendant, par jeton plutôt que par siège, et chaque prompt qu'il contient est public — vous pouvez donc le pointer vers un benchmark comme celui-ci et obtenir votre propre chiffre au lieu du nôtre.

En résumé

c-CRAB est le premier benchmark de revue de code dont la notation est en grande partie fiable : une revue n'est réussie que lorsque le fait de l'appliquer corrige le code. Les chiffres clés sont réellement bas — meilleur outil unique 32,1 %, union 41,5 % — mais ils mesurent le chevauchement avec les préoccupations soulevées par les humains, et non la qualité des revues, et les données d'utilité montrent que la plupart des commentaires sont un signal réel. Les enseignements durables sont ceux que l'article lui-même défend : le volume n'est pas la couverture, les agents et les humains regardent des choses différentes, et le bon déploiement est la collaboration humain-agent. Et le benchmark est ouvert, donc la prochaine étape honnête est d'y exécuter votre propre outil de revue et d'obtenir votre propre chiffre.