« Aucune interface ne permet d'attacher une heure à une tâche existante. » La phrase était écrite, argumentée, fausse. Elle a coûté deux jours, deux fois de suite. Voici pourquoi une conclusion négative est la plus chère des affirmations.
1. La phrase
Il y a des erreurs qui se voient tout de suite : un chiffre faux, un lien mort, une capture d'écran qui contredit le texte. Et il y a les erreurs qui ne se voient pas, parce qu'elles ont la forme d'un constat : « aucune interface ne permet de faire cela ».
Cette phrase-là, nous l'avons écrite. Avec méthode, même. Nous avions ouvert l'interface, cherché dans les menus, testé un chemin plausible, constaté l'absence. Puis nous avons documenté : la fonctionnalité manque, il faut passer par un contournement (créer une seconde entrée, la découper, la replanifier).
Le lendemain, en cliquant au mauvais endroit pour une autre raison, la fonctionnalité est apparue. Elle était là depuis le début. Elle s'appelait simplement autrement, et elle vivait dans une fiche, pas dans un dialogue de création.
2. Ce que nous avions testé
Le chemin testé était le plus évident : le bouton « Créer », puis le formulaire de création, puis le choix du type. Dans ce parcours, aucune option d'horaire. Conclusion : pas d'horaires.
Le chemin réel était ailleurs : la bande des tâches du jour, un clic sur une fiche existante, puis un lien discret — « préciser l'heure » — qui ouvre deux champs, début et fin, et enregistre sur la fiche cliquée. Aucune seconde entrée créée, un bloc natif posé sur la tâche existante.
Deux chemins, deux interfaces, deux réponses opposées. Nous avions testé un point d'entrée et généralisé à l'ensemble du produit.
3. La deuxième fois en deux jours
Le plus gênant n'est pas l'erreur : c'est sa répétition. La veille, une conclusion négative du même type avait déjà été produite — sur un autre sujet, avec la même mécanique : une sonde trop étroite, une généralisation trop rapide, une documentation publiée.
Deux occurrences en quarante-huit heures, ce n'est plus une étourderie. C'est un défaut de méthode. Et un défaut de méthode qui produit des affirmations négatives est particulièrement coûteux, pour une raison simple : une conclusion négative décourage la recherche. Personne ne va chercher une fonctionnalité qu'on lui a dit inexistante.
4. Pourquoi le négatif est plus dangereux que le positif
Une erreur positive se corrige d'elle-même : on affirme que quelque chose existe, quelqu'un essaie, ça ne marche pas, on est contredit. La réalité reprend la main.
Une erreur négative, non. Elle ne se heurte à rien. Elle ferme une porte, et personne ne sait qu'elle était ouverte. Elle se propage dans la documentation, dans les procédures, dans les contournements qu'elle justifie. Elle coûte en travail détourné, parfois pendant des mois.
C'est pour cela qu'une conclusion négative doit être traitée comme une affirmation extraordinaire, et exiger une preuve extraordinaire.
5. La méthode que nous appliquons désormais
Quatre règles, courtes.
Un : énumérer les points d'entrée avant de tester. Une fonctionnalité peut être accessible depuis un menu, une fiche, un raccourci, un glisser-déposer, une commande clavier, une ligne de commande, une interface de programmation. Tant que cette liste n'est pas écrite, on n'a pas le droit de conclure.
Deux : formuler le négatif comme un constat daté et personnel. « Je n'ai pas trouvé » n'est pas « il n'y a pas ». La première phrase est vraie et laisse la porte ouverte ; la seconde est une affirmation sur le monde, qui exige d'avoir tout épuisé.
Trois : chercher la preuve de l'inverse. Avant d'écrire qu'une chose n'existe pas, on cherche activement un cas où elle existe : documentation, capture, témoignage, trace d'usage. Une recherche qui ne vise qu'à confirmer ce qu'on croit déjà n'est pas une recherche.
Quatre : ne jamais documenter un contournement sans avoir daté l'absence. Un contournement construit sur une conclusion fausse devient une dette invisible : il fonctionne, donc personne ne le remet en cause.
6. Le second enseignement : écrire au bon endroit
La découverte de la vraie porte a révélé un autre risque, plus grave que l'erreur de diagnostic.
Un outil avait été construit pour planifier des tâches. Il écrivait sur la première entrée correspondant à un titre approximatif. Or, dès qu'on peut éditer une fiche existante, l'identité de la cible devient critique : une tâche planifiée n'est pas la même qu'une tâche créée, et confondre les deux déplace des heures d'un endroit à un autre.
Nous avons donc ajouté un contrôle simple, qui a évité au moins une erreur : relire le titre de la fiche avant d'écrire, et refuser si l'identité ne correspond pas. Quatre contrôles encadrent désormais chaque écriture : identité de la cible, relecture des valeurs écrites, comptage avant/après, présence de l'effet attendu.
Un outil sans contrôle d'identité est un outil qui écrit au mauvais endroit. Il ne le fait pas souvent ; il le fait une fois, et cette fois-là suffit.
7. Ce que ça change
Depuis, nos comptes rendus distinguent systématiquement trois registres :
- ce que nous avons observé (une mesure, une capture, un journal) ;
- ce que nous avons fait (l'action, avec sa preuve) ;
- ce que nous croyons (l'hypothèse, explicitement datée et attribuée).
Et la phrase « il n'y a pas » a disparu de notre vocabulaire technique. À la place : « je n'ai pas trouvé, voici les points d'entrée testés, voici ce que je n'ai pas testé. »
C'est moins affirmatif. C'est aussi ce qui évite d'écrire, un mardi soir, qu'une porte n'existe pas — alors qu'elle est ouverte depuis le début.
À retenir. Une erreur négative ne se corrige jamais d'elle-même : elle ferme une porte sans bruit. Énumérez les points d'entrée, écrivez « je n'ai pas trouvé », cherchez la preuve du contraire, et n'écrivez jamais sur une cible dont vous n'avez pas relu l'identité.