Aller au contenu
Mastering Claude

Accueil / Vérifier ce qu'il rend

Vérifier ce qu'il rend4 minFondation

Où vous regardez détermine ce que vous trouvez

Une vérification pointée sur le dernier changement dit où l'on a regardé, jamais où sont réellement les défauts : sans avoir examiné le reste avec le même soin, aucune conclusion sur la dangerosité comparée du code récent et du code ancien ne tient.

Une vérification adverse relit presque toujours le dernier diff en premier, le dernier commit, le bloc qu'on vient de changer. Ce périmètre restreint est un choix raisonnable, mais il produit un effet trompeur si on l'oublie : ce que cette relecture trouve dépend d'abord de l'endroit où elle a cherché, pas seulement de l'endroit où les défauts se trouvent réellement.

Un compte sans dénominateur ne compare rien

Affirmer que le code récent est plus dangereux que le code ancien exigerait deux chiffres : la part du dépôt relue qui était récente, et le taux de défauts trouvé dans chacune des deux parts, ancienne et récente, à effort de relecture égal. Sans ces deux chiffres, un compte de défauts trouvés dans le dernier diff ne mesure que le périmètre choisi, jamais la dangerosité comparée des deux zones. C'est un biais de sélection ordinaire : compter les seuls cas qui ont été remarqués, au lieu de la population entière, puis généraliser depuis ce sous-ensemble choisi.

Le biais se vérifie sans fichier vivant du cours, qui se réécrit à chaque correction. La commande qui suit fabrique elle-même les deux fichiers qu'elle compte, avant de les compter : un lecteur qui la rejoue sur son propre poste obtient exactement la même sortie, aujourd'hui comme dans six mois. Compter combien de fois un mot apparaît dans un seul fichier, puis dans deux fichiers voisins, rend deux comptes corrects et deux comptes différents, sans qu'aucun des deux ne dise combien de fois ce mot apparaîtrait dans un ensemble plus large qui n'a pas été interrogé. Elle compte des occurrences, pas des lignes : grep -o imprime chaque correspondance sur sa propre ligne, que wc -l compte ensuite, alors que grep -c ne compterait que les lignes.

$ printf 'Ce fichier decrit un défaut de comptage.\nUn deuxieme défaut apparait plus bas.\nUn troisieme défaut clot la liste.\n' > fichier-b.txt
$ grep -o "défaut" fichier-b.txt | wc -l
3
$ printf 'Ce fichier voisin decrit un premier défaut.\nPuis un second défaut.\n' > fichier-a.txt
$ grep -o "défaut" fichier-a.txt fichier-b.txt | wc -l
5

Le périmètre interrogé détermine le nombre trouvé. Trois, ou cinq, dépend uniquement du nombre de fichiers ouverts par la commande, pas d'une propriété plus profonde du texte fabriqué pour la démonstration.

Déclarer une donnée absente

Le même biais fausse un constat d'absence. « Non relevé » ou « outil non installé » ne se disent qu'après avoir regardé tous les endroits où la chose peut vivre : l'outil global, le dossier de profil, le cache du projet, les noms des variables d'environnement (jamais leurs valeurs). Une valeur déclarée absente puis remplacée par une hypothèse peut vivre dans un projet voisin, hors du périmètre de la relecture. Tenez le journal de ce qui a été cherché avant d'écrire « absent ». Claude Code applique ce principe à sa propre recherche : depuis octobre 2026, Grep et Glob retentent une fois ou signalent l'échec quand le fichier ou le dossier visé n'est pas lisible, au lieu d'annoncer « aucun résultat ».

Ce qui reste utile malgré le biais

Relire en priorité le dernier changement garde un sens, non parce qu'il concentrerait forcément plus de défauts, mais parce que c'est le seul code que personne d'autre n'a encore examiné. Une ligne ancienne a déjà survécu à plusieurs relectures et plusieurs exécutions. Une ligne écrite dix minutes plus tôt n'a survécu qu'à la relecture de son auteur, et cette relecture immédiate rejoue la même intention qui a produit l'erreur, si erreur il y a : elle ne peut pas la voir, comme le montre la leçon sur un vert qui n'a pas encore été mis en défaut. C'est un motif d'urgence, pas un motif statistique.

Une garde ou un contrôle tout juste ajouté pour corriger un défaut précis hérite de la même urgence : personne ne l'a mis en défaut, et son vert d'aujourd'hui ne prouve rien.

Figure 1

Ce qu'une relecture pointée révèle, et ce qu'elle ne peut pas dire

Relecture pointée sur le dernier diff

Des défauts réels, comptés avec exactitude dans ce périmètre précis.

Ce que ce même compte ne mesure jamais

La densité de défauts dans le reste du dépôt, non relu avec le même effort, donc aucune comparaison entre code récent et code ancien.

Le même périmètre qui révèle des défauts réels à gauche ne dit rien de la densité de défauts dans la zone jamais relue avec le même soin, à droite.
Calibrez vous-même

Un agent adverse reçoit pour instruction de relire le dernier commit d'un dépôt à la recherche de défauts. Il y consacre vingt minutes et remonte trois défauts, chacun situé dans les lignes modifiées par ce commit. Chaque défaut est accompagné d'un numéro de ligne et d'une explication de deux phrases.

Écrivez en une phrase ce que ce résultat établit, et en une phrase ce qu'il n'établit pas.

Ce qu’il faut retenir
  • Un compte de défauts limité à un seul périmètre mesure ce périmètre, jamais la dangerosité comparée du reste, faute d'un dénominateur commun aux deux zones ; de même, une donnée ne se déclare absente qu'après avoir regardé partout où elle peut vivre.
  • Chercher davantage dans une zone y fait trouver davantage : un biais de sélection reconnaissable, qui n'a besoin d'aucune mauvaise foi pour produire un raisonnement fluide et faux.
  • Relire le dernier changement en premier reste défendable, parce que c'est le seul code que personne d'autre n'a encore examiné, pas parce que les défauts s'y concentreraient statistiquement.
  • La relecture qu'un auteur fait de son propre code au moment de l'écrire rejoue la même intention qui a produit l'erreur : elle ne peut donc pas la révéler.
  • Un regard extérieur, une personne ou un agent qui n'a pas écrit le code, teste ce qu'une relecture par l'auteur ne peut jamais tester.
À faire maintenant

Demandez à un agent dans une session neuve, qui n'a pas écrit votre dernier diff et ne connaît pas votre intention, de le relire avec pour seule consigne de chercher une raison pour laquelle il serait faux. Faites relire ensuite par ce même agent, avec la même consigne, un fichier resté stable depuis plusieurs mois. Notez lequel des deux passages rend un défaut : cela vous dit où regarder ensuite, pas où les défauts sont forcément les plus nombreux.

Vérifier à la source

Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.