Aller au contenu
Mastering Claude

Accueil / Vérifier ce qu'il rend

Vérifier ce qu'il rend4 minFondation

Une vérification très rigoureuse peut quand même ne rien voir

Plus une méthode de contrôle est disciplinée, plus elle donne l'illusion d'avoir tout couvert, parce qu'elle ne peut juger que ce qui existe déjà, jamais ce qui manque entièrement.

Une vérification adverse, même très disciplinée, répond toujours à une question fermée : ce fragment de code fait-il ce qu'il prétend faire. Elle relit des fichiers, des fonctions, des écrans qui existent déjà dans le livrable qu'on lui soumet. Un écran jamais construit, une fonction jamais écrite, un parcours jamais branché n'apparaissent nulle part dans ce périmètre, donc aucune relecture, aussi minutieuse soit elle, ne peut les y trouver.

Un contrôle ne peut juger que ce qui existe

Ce n'est pas une faiblesse de méthode, c'est une limite structurelle du geste lui même : on ne relit que ce qui a été écrit. La preuve tient dans une seule commande, qui fabrique elle même le fichier qu'elle interroge avant de l'interroger, plutôt que de dépendre d'une correspondance vivante du projet susceptible d'être modifiée entre l'écriture de cette leçon et sa lecture :

$ printf 'v2m3l1\nv2m3l2\nv2m3l3\nv2m3l4\nv2m3l5\nv2m3l6\nv2m3l7\nv2m3l8\nv2m3l9\n' > planning.txt
$ grep -c "v2m3l10" planning.txt
0
$ echo "code de sortie : $?"
code de sortie : 1

La commande rend zéro occurrence sur sa sortie standard, parce qu'aucune chaîne ne correspond, et elle signale bien quelque chose par ailleurs : son code de sortie vaut 1, la convention par laquelle grep indique l'absence de correspondance. Le code de sortie fait partie de la sortie, au même titre que le texte affiché, et l'ignorer revient à perdre une partie de l'information déjà rendue. Ce signal ne dit pourtant pas qu'une leçon manque : que la dixième leçon du module ait été oubliée en cours de route ou qu'elle n'ait jamais été planifiée, la commande rendrait exactement le même zéro et le même code 1 dans les deux cas. Un contrôle confiné à ce que le fichier contient ne distingue pas ces deux situations.

La rigueur aggrave l'illusion au lieu de la corriger

Le résultat est contre intuitif : plus une méthode de contrôle est disciplinée sur ce qu'elle regarde, plus son verdict positif inspire confiance, et plus cette confiance devient trompeuse sur ce qu'elle n'a pas regardé du tout. Comme pour une relecture pointée sur le dernier diff, un vert obtenu par une méthode sérieuse se lit comme une couverture totale, alors qu'il ne dit rien de ce qui est absent du périmètre examiné.

Ce qui referme l'angle mort

Aucune discipline supplémentaire appliquée au même geste ne comble ce trou, puisque le geste porte par construction sur l'existant. Ce qui le comble est une question différente, posée en dehors du code relu : un parcours utilisateur complet plutôt qu'une liste de cas à vérifier, confié à un usage réel, même très bref, mené tôt par la personne concernée. Un tel usage n'est pas plus rigoureux qu'une relecture disciplinée, il examine un périmètre différent, celui qui inclut l'absence totale, là où une relecture de code ne peut par construction examiner que ce qui a été écrit.

Figure 1

Ce que la rigueur change, et ce qu'elle ne change jamais

Défaut sur l'existant
Élément manquant entièrement
Contrôle peu rigoureux

Souvent raté

Un contrôle relâché laisse passer des défauts pourtant présents dans le code.

Raté aussi, sans surprise

Un contrôle relâché ne voit évidemment pas ce qui n'a jamais été écrit.

Contrôle très rigoureux

Ce que la rigueur change réellement

Un contrôle disciplinée relit ce qui existe avec le soin voulu, sans que cela dise combien de défauts échappent encore à ce même périmètre.

Raté quand même

Le même contrôle, aussi rigoureux soit il, ne peut rien dire d'un écran, d'une fonction ou d'un parcours jamais construits : ce n'est pas dans son périmètre.

La rigueur améliore la colonne des défauts présents dans l'existant, jamais la colonne de l'absence totale, qui reste ratée quelle que soit la discipline appliquée.
Calibrez vous-même

Une correspondance de planification décrit un module de dix leçons, numérotées de un à dix, pour une équipe de rédaction. Plusieurs agents adverses reçoivent chacun les fichiers des neuf leçons déjà rédigées, avec pour instruction d'y chercher des défauts. Chaque agent remet un rapport de défauts limité aux fichiers qui lui ont été transmis.

É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
  • Une vérification adverse, aussi disciplinée soit elle, ne juge que ce qui existe déjà dans le périmètre qu'on lui soumet, jamais ce qui en est totalement absent.
  • Un contrôle confiné à des fichiers existants rend le même silence face à un élément oublié et face à un élément qui n'a jamais été prévu : il ne distingue pas les deux cas.
  • Plus une méthode de contrôle est rigoureuse sur son périmètre, plus son vert inspire une confiance qui déborde largement ce qu'elle a réellement couvert.
  • Un usage réel bref n'est pas plus rigoureux qu'une relecture disciplinée : il examine un périmètre différent, celui qui inclut l'absence totale.
À faire maintenant

Ouvrez un produit ou un livrable que vous venez de faire relire avec soin, et tentez d'atteindre son but final sans suivre aucune instruction ni documentation. Notez chaque point où vous vous arrêtez sans savoir quoi faire. Le nombre de points d'arrêt est votre résultat vérifiable, et chacun est un candidat à un élément que la relecture de code n'a jamais pu voir.