La revue de code qui prouve chaque bug — testée

Demandez à une IA de relire votre PR et elle vous rend une checklist bien nette : injection vérifiée, secrets vérifiés, authentification vérifiée, tout va bien. Ça a l'air rigoureux. Mais avoir trouvé quelque chose est une tout autre affaire — et c'est justement ce que la checklist dissimule. Nous dirigeons un annuaire qui teste les skills Claude à longueur de journée, et quand nous avons pointé notre propre benchmark sur un skill de revue déjà noté validé, il est passé à côté d'un secret codé en dur que la version sans garde-fous, elle, avait repéré. La liste ne prévoyait aucune ligne pour cet endroit précis, alors le relecteur n'a jamais regardé.

Ce raté explique pourquoi review-discipline existe, et pourquoi il existe dans sa deuxième version. Il est gratuit et sous licence MIT : github.com/Skillproofdev/review-discipline. Chaque signalement doit nommer une entrée concrète qui atteint le code et produit un résultat erroné — sinon il est rétrogradé en [suspicion], jamais affirmé comme un fait. Sur notre benchmark à bugs implantés, il attrape 18.5 sur 21 bugs semés avec zéro faux positif et un chemin d'échec démontré sur ~100 % des signalements.

Le vide : chaque skill de revue est une checklist, et les checklists créent des œillères

Avant d'écrire une ligne, nous avons passé en revue 321 skills de revue indexés, plus le champ hors plateforme — y compris le plugin de revue de code d'Anthropic lui-même. Trois mécanismes n'apparaissaient dans aucun d'entre eux comme règles applicables à un agent unique. Les trois remontent au même échec que nous avons vu se produire sur notre banc de test.

Une checklist dit au relecteur ce qu'il doit chercher. C'est aussi une liste de ce qu'il va laisser passer. Quand les catégories n'incluent pas le bug, le bug survit — et pire, la revue revient quand même au vert, parce que chaque case existante a été cochée. Une revue échoue de deux façons : signaler des suppositions non démontrées comme des faits (le bruit), ou passer discrètement à côté d'un vrai bug parce qu'il est petit ou qu'un plus effrayant a monopolisé l'attention (la couverture manquée). Une checklist produit structurellement les deux.

Le plugin d'Anthropic combat la moitié « bruit » avec des agents évaluateurs en parallèle qui votent un score de confiance. C'est un mécanisme réel, mais il exige plusieurs agents et ne traite en rien la moitié « couverture ». Personne ne propose ce qui inverse la forme même de la checklist : traquer d'abord tout, sans catégorie en tête, prouver ou étiqueter chaque signalement ensuite, et n'écarter que ce qu'on peut réellement réfuter — avec un seul agent, dans un seul fichier installable.

Huit règles, dont trois qu'aucun autre skill n'impose

Le skill est un ensemble de règles applicables (SKILL.md complet). Les éléments familiers sont là : sévérité P0–P3 avec de vraies définitions plutôt qu'un ressenti, discipline de périmètre du diff (relire le changement, pas toute la base de code), signalement des tests manquants rattaché au comportement modifié, et zéro remplissage complaisant. Les éléments qu'aucun autre n'impose :

1. Pas de chemin d'échec démontré, pas de signalement. Chaque signalement doit nommer une entrée ou un état concret qui atteint le code visé et produit un résultat erroné. Impossible d'en construire un ? Il part en [suspicion], classé sous chaque signalement prouvé — jamais comme un fait. Affirmer un bug sans démonstration est le seul résultat interdit par le skill.
2. Deux passes, la chasse ouverte d'abord. Lire le changement en attaquant, sans liste de catégories en main, et noter chaque anomalie — aucun plancher de sévérité, un détail simplement suspect est quand même consigné. Ensuite seulement, balayer la checklist standard (secrets, injection, limites, arithmétique, concurrence…) pour ce que la chasse ouverte aurait manqué. Chez tous les concurrents, la checklist est la méthode ; ici elle passe en second, volontairement.
3. Tuez votre propre signalement avant de le publier. Une tentative honnête de réfutation par signalement — garde-fous en amont, comportement intentionnel, couverture de test existante, atteignabilité — et le rapport précise ce qui a été vérifié. La réfutation est la seule porte autorisée à écarter un signalement ; « je n'ai pas pris la peine de le prouver » devient un [suspicion], jamais un abandon silencieux. Les signalements qui meurent réellement meurent en silence.

La règle qui porte tout, c'est l'ordre : la largeur avant la profondeur. Collecter chaque anomalie sans plancher de sévérité avant d'en vérifier une seule, pour que l'approfondissement sur un bug ne puisse jamais tronquer la chasse aux autres. Ça paraît évident. C'est aussi exactement la règle que notre première version n'avait pas — et la raison pour laquelle elle a perdu.

Le benchmark honnête (résultats négatifs inclus)

Protocole à bugs implantés : de vrais échantillons de code (environ 200 à 400 lignes chacun, TypeScript / Python / JS) contenant des bugs documentés de sévérité connue — logique, sécurité, cas limites, concurrence — avec une vérité terrain figée avant toute exécution. Du code réel et intact reste dans chaque échantillon pour mesurer les faux positifs. Mêmes prompts, même modèle ; la seule variable est de savoir si l'agent lit le SKILL.md en premier. Méthodologie complète : skillproof.dev/methodology.

4 échantillons, 21 bugs implantés, 12 pièges intentionnellement sains pour mesurer les faux positifs. La colonne intéressante n'est pas base contre skill — c'est v1 contre v2, parce que c'est notre propre benchmark qui a forcé la reconstruction.

Métrique	Base (sans skill)	Skill v1	Skill v2
Bugs implantés trouvés (sur 21)	17.0 (81 %)	16.5 (79 %)	18.5 (88 %)
Détection P0 (exploitable / perte de données)	3/3	3/3	3/3
Détection P1 (comportement erroné, chemin réaliste)	7/7	7/7	7/7
Détection P2 (cas limites / arithmétique)	6/7	4/7	7/7
Sonde de secret codé en dur	trouvé	trouvé	trouvé
Taux de faux positifs	5.6 % (1 FP)	0 %	0 %
Signalements avec chemin d'échec démontré	~63 %	~100 %	~100 %
Rétrogradations [suspicion] (nuances honnêtes)	0	3	5
Lignes de complaisance / remplissage	présentes	aucune	aucune

Lisez la colonne du milieu et vous verrez l'échec qui a donné son nom à ce skill. v1 a obtenu 16.5 — en dessous des 17 de la base sans skill. Il avait la discipline du chemin d'échec (il a ramené les faux positifs à zéro et démontré ~100 % de ses signalements), mais il était moins bon pour trouver les bugs, parce qu'il s'était fixé sur les P0 spectaculaires d'un échantillon et n'avait jamais balayé les lignes discrètes d'arrondi monétaire. Il avait des œillères. Notre benchmark public d'un skill déjà noté validé est ce qui l'a démasqué : v1 a manqué deux vrais P2 — une erreur logique de prorate /30 et une troncature int(amount × 100) — que la base a repérées simplement en lisant de façon linéaire.

Le correctif a été la règle largeur-avant-profondeur. v2 collecte chaque anomalie sans plancher de sévérité avant d'en vérifier une seule. Résultat : le P2 est passé de 4/7 à un net 7/7 (il a même récupéré un StopIteration sur un CSV vide que base et v1 avaient tous deux manqué), le rappel total a grimpé à 18.5 — au-delà des 17 de la base — et la discipline a tenu : toujours zéro faux positif, toujours ~100 % de chemins démontrés, et davantage de nuances [suspicion] honnêtes (5 contre 3) plutôt que moins. L'arbitrage complet à trois voies est dans bench/results/verdict.md.

Un mythe que le benchmark a aussi enterré, clairement : l'hypothèse « la checklist crée des œillères sur les secrets », qui avait motivé tout le projet, ne s'est pas reproduite dans l'exécution avec bugs implantés — les trois versions ont attrapé la sonde du secret codé en dur (S4-B1). Le raté d'origine était réel et c'est lui qui nous a appris la forme du problème ; le benchmark implanté montre juste que ce n'est pas là que la largeur paie. Ce sont les cas limites d'arrondi monétaire. Nous rapportons le mécanisme qui a réellement fait bouger les chiffres, pas celui qui faisait la meilleure histoire d'origine.

Là où v2 a perdu — publié quand même

Notre méthodologie exige que les pertes soient publiées à côté des gains. v2 est la meilleure version sur tout ce qui bloque une fusion, mais elle n'est pas strictement supérieure à v1, et nous ne prétendrons pas le contraire.

En poursuivant une largeur exhaustive, v2 a arrêté d'approfondir une fonction (_parse_tags) et est passée à côté d'une suspicion subtile de literal_eval en imbrication profonde (S2-B5) que la passe en profondeur de v1 avait, elle, uniquement captée. Donc sur l'axe P3 / hors-checklist, v2 a en fait régressé — de 2.5/4 pour v1 à 1.5/4. Net, c'est un bon échange (+2 signalements moyens pour −1 P3 subtil), mais c'est une vraie régression sur cet axe précis, pas une domination nette. Le relecteur idéal serait la largeur de v2 plus la volonté de v1 de creuser encore un niveau sur le code d'apparence tranquille — et nous préférons vous le dire plutôt que d'arrondir.

Il y a aussi un bug qu'aucune version n'a trouvé : une égalité stricte < sur une expiration de coupon (S1-B6), manquée par base, v1 et v2 à la fois. Le skill réduit les ratés ; il ne rend pas Claude infaillible.

Installation

git clone https://github.com/Skillproofdev/review-discipline ~/.claude/skills/review-discipline

Redémarrez Claude Code. Une seule commande — le dépôt est le skill. Il se déclenche sur « review this PR/diff », « check this before merge », « find bugs in » et les vérifications avant fusion — et reste en retrait pour l'écriture de fonctionnalités, le lint purement stylistique et la relecture de prose. Il rejoint notre série discipline : token-discipline réduit ce qu'un agent coûte, research-discipline réduit ce qu'il se trompe sur les faits, et celui-ci réduit ce qu'une revue manque.

FAQ

En quoi est-ce différent du plugin de revue de code d'Anthropic ? Le plugin filtre les faux positifs en faisant voter un score de confiance à des agents évaluateurs en parallèle — efficace, mais il exige plusieurs agents et ne traite que le problème du bruit. review-discipline filtre avec un chemin d'échec démontré, dans un seul agent, dans un seul fichier installable, et s'attaque en plus au problème de couverture que le plugin ne touche pas : la règle de chasse ouverte avant checklist, qui a fait passer notre rappel P2 de 4/7 à 7/7.

« Prouver chaque signalement » ne va-t-il pas lui faire manquer des choses qu'il ne peut pas démontrer ? Non — c'est là qu'intervient le mécanisme [suspicion]. Un vrai bug pour lequel on ne peut pas construire de chemin d'échec (il faut un état d'exécution invisible, ou un système externe) est quand même signalé, marqué [suspicion] et classé sous les signalements confirmés, avec une ligne sur ce qui manque. Rétrograder la confiance, c'est l'outil ; l'abandonner, non. Dans le benchmark, v2 a émis 5 nuances honnêtes de ce type plutôt que de les avaler.

Relit-il toute la base de code ou juste mon diff ? Juste le changement. Les signalements doivent être causés ou activés par ce diff ; les problèmes préexistants vont dans une courte note hors-périmètre, pas dans la liste classée. La seule exception est un P0 préexistant — un secret actif ou une vulnérabilité active — toujours signalé de façon bien visible. Cette exception existe précisément à cause du raté fondateur.

18.5/21, est-ce suffisant pour se passer d'une revue humaine ? Non. Il attrape chaque bloqueur P0 et P1 de notre benchmark et bat une base sans garde-fous sur le rappel total, avec zéro faux positif — ce qui en fait un premier relecteur solide, qui ne tamponne jamais à l'aveugle et nomme toujours ce qu'il a attaqué. Mais il a manqué un bug implanté en entier et sacrifié un P3 subtil au profit de la largeur, les deux documentés plus haut. Utilisez-le pour vous assurer que les bugs évidents et les erreurs arithmétiques discrètes n'atteignent jamais un humain ; gardez l'humain pour le dernier niveau de profondeur.