Le vrai enjeu : le savoir tout de suite
Un serveur qui s’arrête se remarque. Une automatisation qui s’arrête, non. Elle ne prévient personne, personne ne s’en plaint, et le travail qu’elle faisait cesse simplement d’être fait. On s’en aperçoit trois semaines plus tard, quand un client demande pourquoi il n’a jamais reçu sa relance.
J’ai vécu exactement ça sur ce site. Un composant était pourtant bien écrit, bien testé, et poussé en ligne. Sauf que le déploiement avait été refusé par l’hébergeur, sans message d’alerte. Le code était parti, le site tournait, tout paraissait normal. Il a fallu qu’un humain constate l’absence du résultat pour qu’on comprenne ce qui s’était passé.
C’est la leçon qui gouverne tout le reste : la bonne question n’est pas « est-ce que mon système va tenir ? », mais « comment je saurai, tout de suite, qu’il a besoin de moi ? ».
Les cinq points que je surveille
Le fournisseur change quelque chose. Un outil modifie son interface, renomme un champ, change sa politique. Votre système, lui, cherche toujours l’ancien champ. C’est le point qui revient le plus dès qu’une installation prend de l’âge, et il ne dépend pas de vous.
Un caractère invisible. Mon exemple préféré, parce qu’il est vexant. Une clé secrète copiée depuis un terminal s’est retrouvée avec un caractère invisible en tête, ajouté silencieusement par l’outil de copie. Le service distant refusait la clé sans dire pourquoi. Rien ne se voyait à l’écran. Même famille : une phrase contenant un simple deux-points a rendu un fichier de configuration illisible pour la machine, avec pour seul message d’erreur « problème avec le fichier ».
Un droit d’accès insuffisant. Le système a bien une clé, mais elle ne permet pas l’action demandée. Souvent, le service répond par un refus poli et générique, qui fait penser à un défaut technique alors que c’est une simple question d’autorisation. C’est ce qui m’est arrivé sur la publication automatique de ce blog, et j’ai fini par changer de mécanisme plutôt que de forcer.
Le succès apparent. Le plus discret. Le système répond « c’est fait », tout est vert, et rien n’a été fait. Un filtre trop strict quelque part a écarté toutes les lignes, un identifiant ne correspondait à rien, une condition n’a jamais été vraie. Sans vérification de ce qui a été réellement produit, cela peut passer inaperçu pendant des mois.
Le processus change, personne ne le dit. Quelqu’un renomme un dossier, ajoute une étape de validation, change de logiciel. Le système continue d’appliquer l’ancien monde, correctement, sur des données qui n’ont plus le même sens. C’est le seul des cinq points qui ne soit pas technique : il se règle d’abord en parlant ensemble, avant de toucher au système.
Vous vous demandez ce que ça donnerait chez vous ? Le diagnostic gratuit vous dit par quoi commencer, en 2 minutes.
Comment j’interviens
Toujours dans le même ordre, et cet ordre compte plus que l’expertise.
Reproduire avant de toucher. Tant que je n’ai pas vu la situation se produire sous mes yeux, je ne corrige rien. La tentation, dans l’urgence, est de modifier ce qui ressemble à la cause. Une fois sur deux, on modifie quelque chose qui fonctionnait très bien, et on ajoute un second problème au premier.
Isoler la pièce en cause. Un système est une chaîne. On la coupe en deux, on regarde de quel côté ça se passe, on recommence. Trois coupes suffisent presque toujours, même sur une chaîne compliquée.
Corriger la cause, pas le symptôme. Relancer un service qui s’est arrêté fait disparaître le symptôme jusqu’au lendemain. La question à se poser avant toute action est celle-ci : est-ce que ce que je m’apprête à faire est soutenu par ce que j’ai constaté, ou par ce que je suppose ?
Écrire la leçon. Chaque intervention laisse une règle derrière elle. Le caractère invisible a produit la règle « vérifier une clé après l’avoir posée, jamais avant ». Le fichier de configuration a produit « valider le format avant la mise en service ». Ces règles valent plus cher que la correction elle-même : ce sont elles qui font qu’on ne repaie pas deux fois la même heure.
Les quatre garde-fous que j’installe
Sur toute installation que je livre, quatre choses existent avant même la première exécution.
- Une alerte automatique. Toute exécution qui s’interrompt, quelle qu’elle soit, envoie un message avec l’étape concernée et le lien vers le détail. Pas un tableau de bord à consulter : un message qui arrive.
- Une preuve de vie. Le système signale ce qu’il a produit, pas seulement qu’il a tourné. « 14 relances envoyées » se vérifie ; « exécution réussie » ne prouve rien.
- Une trace consultable. Ce qui est arrivé, quand, avec quelles données. C’est ce qui transforme une enquête d’une demi-journée en une vérification de deux minutes.
- Le moins de pièces possible. Chaque outil ajouté est une pièce de plus à surveiller. Quand une pièce résiste, je regarde d’abord si une autre, déjà présente, peut faire le travail. Les installations qui tiennent dans le temps sont les plus simples, pas les plus astucieuses.
Ces garde-fous sont exactement ceux qu’on retrouve dans la mécanique que j’ai décrite en détail dans un précédent article de coulisses. Ils représentent une part non négligeable du travail d’installation, et c’est normal : ce sont eux qui vous permettent de ne plus y penser. Dans mes formules au mois, ils sont compris : tout est surveillé 24 h sur 24, et j’interviens en 24 h maximum.
