La seule panne qui compte vraiment
Un serveur qui tombe 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 découvre le problème.
C’est la leçon qui gouverne tout le reste : la question n’est pas de savoir si votre système va casser, mais de savoir comment vous l’apprendrez.
Cinq façons de casser
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 la cause qui revient le plus dès qu’une installation prend de l’âge, et elle ne dépend pas de vous.
Un caractère invisible. Ma panne préférée, parce qu’elle est vexante. 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 ressemble à une panne alors que c’est une 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 vicieux. 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, ce genre de panne peut durer 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 la seule panne des cinq qui ne soit pas technique, et c’est celle qu’on répare le plus difficilement.
Vous vous demandez ce que ça donnerait chez vous ? Le diagnostic gratuit chiffre votre situation en 6 minutes.
Comment je répare
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 panne se produire, je ne corrige rien. La tentation, dans l’urgence, est de modifier ce qui ressemble à la cause. Une fois sur deux, on répare quelque chose qui n’était pas cassé, et on ajoute un second problème au premier.
Isoler la pièce fautive. Un système est une chaîne. On la coupe en deux, on regarde de quel côté est le problème, 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 plante 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 panne 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.
- Un filet d’erreur global. Toute exécution qui casse, quelle qu’elle soit, envoie un message avec l’étape fautive 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 un point de rupture de plus. 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 n’est pas le jour où l’on construit qu’un système coûte cher, c’est le jour où il tombe sans prévenir.
