Peut-on faire confiance aux revues IA ?

En exploitant un outil interne de revue IA, voici le partage du processus suivi pour mesurer quantitativement la qualité et l’améliorer afin de répondre aux questions : « Peut-on faire confiance aux revues IA ? » et « Vérifient-elles vraiment bien les choses ? »

Contexte

• Le code généré par IA présente 1,7 fois plus de problèmes par PR que le code humain, et 75 % plus d’erreurs de logique (CodeRabbit)
• Après un incident causé par du code IA, Amazon a rendu obligatoire l’approbation des PR par un senior, et Shopify interdit le merge automatique des PR IA
• Les revues IA ont été introduites dans ce contexte comme un moyen de validation pour détecter plus tôt les problèmes et erreurs
• Mais comme la revue IA elle-même est non déterministe, il faut d’abord mesurer si « ce moyen de validation valide réellement bien »

Construction d’un benchmark interne

• Remonter des PR de hotfix vers les PR d’origine pour mesurer si « au moment de la PR d’origine, la revue IA aurait pu détecter ce bug »
• N’inclure que les cas pouvant être jugés à partir du seul diff de PR, et exclure ceux nécessitant un contexte externe
• Notation via GPT-4o mini en mode LLM-as-a-Judge. Même si la valeur absolue est imprécise, cela suffit pour des comparaisons relatives
• Premier score : 33. L’impression de « bien faire le travail » n’était qu’une illusion due à une poignée de cas de réussite

Échec 1 (orchestration de sous-agents)

• Tentative d’une architecture où des sous-agents spécialisés par domaine sont pilotés par un agent principal
• Résultat : taux de détection en baisse, coût multiplié par 1,5 à 3
• Trois causes
  • Perte d’information due à la compression du contexte
  • Réduction du champ de vision à cause d’un périmètre d’attention trop limité
  • Angle mort sur les responsabilités transverses entre domaines

Échec 2 (contamination du benchmark)

• En automatisant l’ajustement des prompts en boucle, cela a convergé vers une liste d’instructions du type « vérifier la division par zéro »
• SWE-bench est lui aussi déjà contaminé
• Confirmation qu’un benchmark externe ne permet pas de fonder solidement le choix d’un modèle

Nouveau métrique (Adoption Rate)

• adopted : la revue a effectivement conduit à une modification du code
• engaged : pas de modification, mais interaction via une réponse en commentaire (reconnaissance de la valeur de validation croisée)
• noised : ni modification ni réponse
• Méthode d’évaluation : comparaison entre le commit SHA au moment de la revue et le SHA au moment du merge, avec classification en adopted s’il y a une modification dans les ±3 lignes autour de la ligne commentée

A/B entre Opus 4.6 et GPT-5.2 Codex

• Répartition des modèles selon la parité du numéro de PR, comparaison sur environ 100 PR
• Opus 4.6 : rapide et créatif, mais manque de rigueur, approuve facilement
• GPT-5.2 Codex : plus lent mais plus rigoureux, et formule encore des remarques utiles même au moment d’une nouvelle demande de revue
• Après passage fixe à Codex, le taux hebdomadaire de prise en compte a atteint un pic de 60 %

Trois mesures qui ont amélioré le taux de prise en compte

• Question : formuler en question au lieu d’une remarque quand le modèle n’est pas certain
• Sections Intent/Decisions dans le modèle de PR
  • Intent : insertion, via la compétence create-pr, de réponses à la question « pourquoi est-ce nécessaire ? »
  • Decisions : extraction automatique des décisions prises dans la session de conversation via le hook Claude Stop
  • Baisse d’environ 29 % des faux positifs dus au manque de contexte côté reviewer
• Résolution automatique des threads : l’IA ferme elle-même le thread lorsqu’elle confirme que la revue a été prise en compte

Résultats

• Taux mensuel de prise en compte de 63 % atteint (au 2026-04-17)
• Toutes les actions étant pilotées par les données, il devient aussi possible de décider des prochaines expérimentations sur une base solide
• Il faut toutefois rester vigilant : l’Adoption Rate non plus ne garantit pas que « adopté = correct », et ce métrique peut lui aussi être contaminé

[pkj3186]

• Mais comme l’évaluation par l’IA elle-même est non déterministe, il faut d’abord passer par l’étape consistant à mesurer si « ce moyen de vérification vérifie vraiment correctement ».

Eh bien… ça ressemble à « qui surveille les surveillants ? »

[bangdori1]

Par le « moyen de vérification » mentionné plus haut, je voulais dire un reviewer IA. Comme l’IA est non déterministe, mon intention était de dire qu’il fallait d’abord une base de référence (benchmark) pour mesurer la qualité des reviews IA, mais du point de vue du lecteur, cela peut aussi se lire comme l’idée qu’il faut d’abord examiner la validité du benchmark lui-même.

J’ai sans doute rédigé la phrase de manière ambiguë, ce qui a pu prêter à confusion. Merci de l’avoir signalé..!

[epdlemflaj]

Personnellement, j’utilise des modèles différents pour écrire le code et pour le relire.
D’après mon expérience, Claude a tendance à considérer que le code écrit par Claude est du bon code, et ChatGPT semble juger meilleur le code écrit par ChatGPT.

[jimmy2056]

J’utilisais Codex pour l’étape de planification et l’étape de vérification, donc j’étais déjà sur la bonne voie.