Dans un projet, la liste de contrôle est souvent le dernier jalon avant la mise en service. Quand toutes les cases sont cochées, on se sent autorisé à livrer. Pourtant, une case cochée ne dit qu'une chose : quelqu'un a estimé que c'était bon. Elle ne dit ni comment il l'a vérifié, ni ce qu'il n'a pas regardé.
Deux vérifications qui disaient vrai, et qui se trompaient
Ce site, be-hem.com, a d’abord été construit avec deux outils qui se partageaient le travail : WordPress, où sont rangés les textes, et un programme séparé chargé de les afficher. Pour qu’un texte soit modifiable depuis WordPress, il fallait le déclarer à plusieurs endroits. Il est arrivé, deux fois, qu’un texte ne soit déclaré que dans le programme d’affichage. À l’écran, rien ne trahissait l’oubli : le texte s’affichait correctement, grâce à une valeur de secours prévue pour les pannes. La vérification visuelle était donc positive. Mais ce texte n’était modifiable nulle part, et personne ne s’en serait aperçu avant de vouloir le corriger.
Plus tard, au moment de reconstruire le site autrement, un outil de comparaison automatique a déclaré l’ancienne et la nouvelle version identiques. Il ne mentait pas : il comparait bien les pages. Seulement, il n’en comparait que le premier écran, ce que l’on voit avant de faire défiler. Tout le reste de la page n’avait jamais été examiné.
Dans les deux cas, la vérification avait réellement eu lieu. Elle portait simplement sur autre chose que ce que l’on croyait. C’est le défaut des listes de contrôle : elles enregistrent le verdict, jamais la méthode qui y a conduit.
Écrire comment on a vérifié
Kheris Workspace, un logiciel de gestion (un ERP) conçu en septembre 2026, a tiré la leçon de ces épisodes dès son cahier des charges. Sa liste de contrôle ne se coche pas : chaque ligne dit comment elle a été vérifiée. Au lieu d’écrire « le retour à la version précédente fonctionne », on écrit par exemple que ce retour a été effectué sur le serveur réel, et combien de temps il a pris.
La différence paraît mince, elle est décisive. « Ça fonctionne » est une appréciation, que personne ne peut contrôler après coup. « Essayé sur le serveur le 14 septembre, en une minute » est un fait : un autre peut refaire l’essai, le contester, ou constater que les conditions ont changé depuis. Une vérification décrite se transmet ; une case cochée ne se transmet pas, elle se croit sur parole.
Dire aussi ce qu’on n’a pas vérifié
Cette exigence s’étend aux comptes rendus. Pour ce site, la règle est de toujours distinguer trois choses : ce qui a été contrôlé, ce qui ne l’a pas été, et ce qui ne peut pas être garanti. Jamais un « c’est bon » global, qui mélange les trois et rassure à tort.
La deuxième partie est la plus utile, et la plus rarement écrite. Personne n’aime avouer qu’il n’a pas regardé quelque chose. C’est pourtant elle qui indique à celui qui reprend le travail où se trouvent les risques, et par où commencer si ça casse. Un compte rendu qui ne dit que ce qui marche ressemble à un bulletin de victoire ; un compte rendu qui dit aussi ce qui reste incertain ressemble à un état des lieux.
Une case cochée rassure celui qui la coche. Une case expliquée renseigne celui qui vient après.