Vérifié = commande + sortie

De toutes les disciplines que je m’impose dans le travail avec l’IA, s’il ne devait en rester qu’une, ce serait celle-ci : « vérifié » doit vouloir dire « commande + sortie ». Sans la commande collée et sa sortie réelle, « c’est fait », « ça devrait aller » et « les tests sont passés » comptent pour rien.

Cette règle, je ne l’ai pas inventée. C’est une facture qui me l’a apprise.

Près de vingt bugs, tous derrière un « c’est fait »

Il y avait un projet qui me tenait à cœur, très automatisé, du genre où une erreur de calcul se paie vraiment. Avant la mise en service, j’ai fait une relecture module par module — non pas les rapports, seulement le code.

Cette relecture a exhumé près de vingt bugs. Leur point commun n’était pas la difficulté : bien au contraire, la plupart sautaient aux yeux. Leur point commun, c’était que chacun se trouvait dans une portion de code déclarée terminée.

Ce qui m’a glacé, ce n’est pas le nombre. C’est d’avoir constaté que je n’avais aucun moyen, de l’extérieur, de distinguer les portions dignes de confiance. Tous les rapports étaient rédigés avec la même élégance, sur le même ton assuré.

Pourquoi l’auto-recette ne tient pas structurellement

Ce n’est pas une question de morale du modèle. Il y a trois raisons plus terre à terre :

• Le contexte qui écrit est le contexte qui juge. Il relit son propre code en portant avec lui « c’est bien ce que je voulais dire », et voit donc l’intention, pas le comportement. Chez les humains, c’est pareil : relire une phrase que l’on vient d’écrire est presque impossible.
• Dire « terminé » ne coûte presque rien, alors que « le faire tourner pour de vrai » coûte quelque chose de réel. N’importe quel système empruntera le chemin le moins coûteux dès lors que ce chemin passe aussi la recette. C’est un fait de structure, pas un défaut de caractère.
• Une longue conversation dilue le critère. Plus le contexte se remplit, plus un critère de recette posé au début se voit discrètement rétrogradé en « globalement atteint ».

J’ai donc cessé de miser sur « la rendre plus honnête » pour aller changer la structure.

Trois pratiques applicables

1. Chaque « vérifié » voyage avec sa preuve. Une ligne de commande, un bloc de sortie, collés à côté de la conclusion. La règle vaut tout autant pour moi : j’ai moi-même très souvent envie de dire « ça devrait aller ».
2. L’auteur ne juge pas son propre travail. La recette revient à une fenêtre au contexte vierge, et l’exécutant ne voit pas les questions à l’avance. Plus le contexte est propre, plus il est facile de voir le comportement plutôt que l’intention.
3. Une discipline ne compte que si un script peut l’exécuter. Ce site a une commande de vérification ; en local et en CI, c’est la même. Ce qu’elle surveille est très simple : pas de chinois dans le code ni la documentation, un champ manquant est une erreur, les clés des trois langues doivent coïncider, la compilation doit passer. Elle n’a rien d’intelligent, mais elle ne se fatigue jamais et ne me fait aucun cadeau les jours où je suis pressé.

Ce que cela fait vraiment gagner

Un « terminé » non vérifié ne vaut pas zéro : c’est une dette. Les travaux suivants la prennent pour fondation et bâtissent trois étages dessus, et l’après-midi où l’on découvre enfin que la fondation est creuse, ce n’est plus une ligne de code qu’il faut démolir. Les intérêts tombent toujours trois semaines plus tard.

J’ai d’abord cru que « commande + sortie » servait à se prémunir de l’IA. À l’usage, j’ai découvert que son plus grand mérite est de me donner le cran d’avancer : la chaîne de preuves est là, je n’ai pas besoin de tout relire à chaque fois.

C’est au fond le même sujet qu’un autre article, Signal et bruit : celui-là explique comment juger de la fiabilité d’une conclusion, celui-ci comment inscrire ce jugement dans un processus, pour qu’il ne dépende pas de ma forme du jour.