Accueil / Quand ça déraille

La demande peut reposer sur une fausse prémisse

Une demande peut décrire le symptôme avec exactitude tout en se trompant sur la cause, et exécuter cette demande à la lettre ne corrige alors rien ou aggrave la situation.

Une demande de correction contient presque toujours deux choses mêlées : un symptôme observé et une cause supposée. Le symptôme peut être parfaitement exact, le serveur répond bien sur le mauvais port, le rapport contient bien un chiffre faux, pendant que la cause avancée pour l'expliquer est fausse. Obéir à la lettre à une demande construite sur une cause fausse ne répare rien, et peut même masquer le vrai problème en donnant l'impression que quelqu'un s'en est occupé.

Le symptôme est vrai, la cause supposée ne l'est pas forcément

La formulation d'une demande vient toujours de quelqu'un qui a déjà un diagnostic en tête au moment de l'écrire. Ce diagnostic n'a rien d'arbitraire, il vient souvent d'un souvenir ou d'une hypothèse raisonnable, mais rien ne garantit qu'il ait été vérifié sur l'état réel du système au moment où la demande est formulée. Une prémisse fausse glissée dans une demande a une propriété gênante : elle se lit comme un fait établi, pas comme une hypothèse, et rien dans sa formulation ne signale qu'elle mérite d'être contrôlée avant d'agir.

# La demande affirme : "le port est reste a 3000 dans config.json, remets le a 8080"
printf '{"port": 8080}\n' > config-exemple.json
cat config-exemple.json
# {"port": 8080}

La lecture directe du fichier fabriqué ci dessus contredit déjà la demande : la valeur enregistrée est 8080, pas 3000. Corriger une valeur qui est déjà correcte ne répare rien et laisse entière la vraie cause du symptôme observé, qu'il s'agisse d'un cache, d'un processus qui n'a pas redémarré, ou d'un second fichier de configuration lu en priorité.

Mesurer avant d'exécuter à la lettre

Le réflexe qui évite ce piège tient en trois gestes, dans cet ordre. Mesurer l'état réel par un moyen indépendant de la demande elle même, un diff, une lecture de journal, une ouverture directe du fichier de configuration en cause. Énoncer l'écart dès le début de la réponse, avant toute correction, pour que la personne qui a formulé la demande voie immédiatement que sa prémisse ne tenait pas. Corriger ensuite la cause réelle telle qu'elle vient d'être mesurée, pas la cause telle qu'elle avait été supposée dans la demande d'origine.

Cet ordre compte davantage que chaque geste pris isolément. Mesurer sans jamais le dire laisse la personne repartir avec la même fausse croyance pour la prochaine fois. Corriger sans avoir mesuré revient à parier que la prémisse était juste, un pari perdu dès que le symptôme et la cause supposée se sont détachés l'un de l'autre. La même discipline, vérifier avant d'incriminer, structure le diagnostic d'une session qui meurt sans raison apparente, voir plusieurs sessions meurent ensemble, soupçonnez la machine.