Le pire mode de panne : celui qui se déclare en bonne santé

Notre site a deux filets pour ne jamais perdre une demande. Le premier est la base de données. Le second est un courriel : si la base tombe, la demande arrive quand même dans une boîte que quelqu'un lit. Il faut que les deux tombent en même temps pour perdre un client.

En testant ce second filet pour la première fois, nous avons découvert qu'il n'existait pas. Pas qu'il fonctionnait mal : qu'il n'existait pas, tout en rapportant un succès depuis le début.

Le défaut, en une phrase

Le code envoyait le courriel au fournisseur, puis passait à la suite sans jamais regarder la réponse. Or un fournisseur qui refuse un envoi ne provoque pas une erreur : il répond poliment « non ». Clé expirée, domaine d'expédition non vérifié, adresse refusée — dans les trois cas, le programme continuait comme si tout allait bien.

Pourquoi ce genre de défaut survit si longtemps

Parce qu'il est invisible par construction. Un formulaire cassé se voit en une heure : quelqu'un se plaint. Un filet de secours cassé ne se voit jamais, parce qu'on ne s'en sert pas les jours normaux. Il passe les tests, il passe les revues, il passe les mois.

Le second facteur est plus gênant : ce chemin n'était pas testable. L'adresse du fournisseur était écrite en dur dans le code, donc l'exercer demandait une vraie clé et un vrai envoi. Ce qui coûte cher à tester ne se teste pas — et ce qui ne se teste pas finit par ne plus fonctionner.

Ce qu'on a changé

• On lit la réponse du fournisseur, et on journalise POURQUOI il refuse — un code à trois chiffres ne dit pas « votre domaine n'est pas vérifié ».
• L'adresse du fournisseur est devenue remplaçable, ce qui rend le chemin exerçable contre un faux fournisseur local. Ce qui se teste facilement se teste souvent.
• Quand les DEUX filets tombent, le journal le crie : c'est la seule trace qui restera de la demande perdue.
• On a vérifié le correctif en simulant un refus « domaine non vérifié » — la panne la plus banale — et en confirmant qu'il apparaît bien dans le journal.

Ce que ça veut dire pour votre entreprise

Vous n'avez pas à comprendre le code pour repérer ce risque. Il existe dans toute automatisation qu'on vous installe : un texto de rattrapage d'appel manqué, une relance de soumission, une alerte de stock. La question n'est jamais « est-ce que ça marche ? » — le jour de l'installation, tout marche.

Comment tester une alerte sans attendre une vraie panne ?

En provoquant la panne exprès, dans un environnement séparé. Couper la base, révoquer la clé, refuser l'envoi — puis vérifier que l'alerte sort. Si personne ne peut vous montrer ça, l'alerte n'a jamais été éprouvée.

Est-ce qu'un tableau de bord vert suffit ?

Non. Un tableau de bord montre ce qu'on a pensé à mesurer. Une panne silencieuse est précisément celle qu'on n'a pas pensé à mesurer — c'est pour ça qu'elle reste verte.