Réduire les faux positifs

Vous avez intégré Claude Code à votre pipeline CI pour examiner chaque demande de fusion. Cela fonctionne — mais les développeurs commencent à l’ignorer. Pourquoi ? Trop de bruit. La revue signale sans cesse des éléments qui ne sont pas de véritables problèmes : des remarques tatillonnes sur le style, des commentaires TODO inoffensifs et des vérifications nulles défensives.

C’est le problème des faux positifs. Un réviseur qui crie au loup finit par être réduit au silence. Dans le scénario 5 (Claude Code pour CI/CD), l’une des compétences architecturales essentielles consiste à réduire les faux positifs afin que le signal restant soit digne de confiance.

Dans cette leçon, vous apprendrez une tactique rapide et ciblée : désactiver temporairement les catégories très bruyantes afin que la revue reste utile pendant que vous affinez les véritables règles.

Un réviseur CI n’a qu’une seule mission : faire ressortir les problèmes auxquels un humain doit donner suite. Dès qu’il produit plus de fausses alertes que de véritables problèmes, deux choses se produisent :

• Les développeurs cessent de lire les commentaires.
• Les véritables bogues se cachent dans le bruit (perdus au milieu : l’attention diminue dans la longue partie centrale d’une liste).

Dire globalement « nous avons trouvé 40 problèmes » semble productif, mais si 35 sont du bruit, la revue a une valeur négative : elle coûte de l’attention pour un faible retour. Réduire les faux positifs n’est pas une question esthétique ; cela protège la crédibilité de l’ensemble du pipeline.

Avant de désactiver quoi que ce soit, identifiez quelles catégories génèrent le bruit. Exécutez la revue en mode non interactif avec une sortie lisible par machine afin de pouvoir compter les problèmes par type au lieu d’évaluer le texte à l’œil.

Utilisez -p (également --print) pour les exécutions CI non interactives et --output-format json pour obtenir des résultats analysables.

Une fois que vous avez repéré une catégorie produisant principalement des faux positifs — par exemple style ou doc_formatting — la correction la plus rapide consiste à la désactiver temporairement. Ne la supprimez pas définitivement : réduisez son bruit maintenant, puis réactivez-la lorsque vous aurez rédigé des critères plus précis.

Le meilleur endroit pour cela est l’instruction que lit le réviseur. Indiquez explicitement ce qu’il doit ignorer, car les critères explicites sont plus efficaces que les demandes vagues comme « faites moins de bruit ».

Une option dans une seule commande ne met en sourdine qu’une seule exécution. Pour rendre la règle cohérente dans toutes les revues CI, placez-la dans le CLAUDE.md au niveau du projet (./CLAUDE.md ou .claude/CLAUDE.md) — partagé par le contrôle de version afin que chaque coéquipier et chaque exécution du pipeline en hérite.

Évitez le ~/.claude/CLAUDE.md au niveau utilisateur : il est personnel et n’est NOT partagé via VCS ; les nouveaux coéquipiers et l’exécuteur CI ne verraient donc pas la règle.

Il arrive qu’une catégorie ne soit bruyante que dans une partie du dépôt. Les fichiers générés ou les appareils de test, par exemple, feront constamment réagir un réviseur strict. Au lieu d’alourdir le CLAUDE.md monolithique, utilisez un fichier .claude/rules/ avec un en-tête YAML contenant paths — il se charge uniquement lorsque les fichiers correspondants sont concernés, ce qui économise du contexte et des jetons.

Mettre en sourdine les catégories bruyantes vous donne un peu de répit, mais la correction durable consiste à définir des critères plus précis pour les catégories conservées. Les critères explicites sont toujours plus efficaces que les instructions vagues.

• Vague : « Signalez les mauvais commentaires. » → se déclenche partout.
• Explicite : « Signalez un commentaire ONLY lorsqu’il contredit le code qu’il décrit. » → se déclenche sur les véritables défauts.

Réactiver une catégorie avec une règle précise vaut bien mieux que la laisser désactivée pour toujours.

Lorsqu’une catégorie se trompe régulièrement dans les cas limites, ne vous contentez pas de décrire la limite — montrez-la. De deux à quatre exemples ciblés à partir de quelques cas pour chaque ambiguïté enseignent au modèle la distinction entre signal et bruit. Le modèle généralise à partir d’eux ; il ne se contente pas de les copier.

Cette approche est particulièrement efficace pour la cohérence, les cas limites, le format de sortie et la réduction des problèmes inventés — exactement les leviers qui permettent de faire baisser les faux positifs.

Une source subtile de faux positifs : le biais. Si la même session qui a généré le code le relit aussi, l’auteur conserve son raisonnement et ne remet pas ses choix en question — il rationalise ses propres décisions. Il en va de même pour un évaluateur influencé par un long contexte de génération.

Effectuez la relecture dans une session nouvelle et isolée. Une instance indépendante évalue la différence selon ses propres mérites et produit des remarques plus pertinentes, moins justificatrices.

Un schéma bruyant dans les demandes de fusion itératives : l’évaluateur ressignale les mêmes problèmes à chaque envoi, noyant ceux qui sont réellement nouveaux. Lorsque vous relancez une relecture, transmettez-lui les résultats précédents et demandez-lui de ne signaler que les problèmes nouveaux ou toujours non corrigés.

Ainsi, la sortie de chaque exécution reste concise et les développeurs ne passent pas à côté des répétitions en faisant défiler la liste — un autre facteur discret de lassitude face aux faux positifs.

Désactiver une catégorie bruyante est une décision de réglage du signal de relecture — ce n’est NOT pas ainsi que vous appliquez les règles critiques. Les instructions au niveau de la requête sont fiables à environ 90 % ; elles sont parfaites pour orienter ce qu’une relecture signale, mais ne conviennent pas aux garanties.

Lorsqu’une règle a des conséquences financières, juridiques ou de sécurité (bloquer un remboursement supérieur à 500 $, rejeter un secret ajouté au dépôt), appliquez-la avec un crochet déterministe, pas avec une requête. Mettez le bruit en sourdine avec les requêtes et la configuration ; appliquez les règles strictes avec des crochets. Gardez ces deux fonctions séparées.

Points essentiels pour conserver la fiabilité d’un évaluateur d’intégration continue :

• Le bruit détruit la confiance — un évaluateur qui crie au loup finit par être mis en sourdine, et les vrais bogues se cachent dans la liste.
• Mesurez d’abord — exécutez avec -p et --output-format json, puis comptez les résultats par catégorie pour localiser le bruit.
• Désactivez temporairement les catégories très bruyantes ; mettez-les en sourdine maintenant, puis réactivez-les plus tard avec des règles plus précises.
• Encodez cela dans le fichier CLAUDE.md du projet (partagé via VCS) et utilisez .claude/rules/ avec paths pour limiter les mises en sourdine aux fichiers générés ou de test.
• Affinez les éléments conservés avec des critères explicites et 2 à 4 exemples à quelques exemples par ambiguïté.
• Effectuez la relecture dans une session isolée et ne signalez que les problèmes nouveaux ou non corrigés lors des nouvelles exécutions.
• Mettez en sourdine avec les requêtes et la configuration ; appliquez les règles critiques avec des crochets déterministes. Ne confondez jamais ces deux fonctions.