Ce jour-là, je corrigeais un problème mineur sur un composant qui paraissait sans lien avec le reste. Un correctif modeste, propre, que j'avais pris soin de tester avant de le mettre en production. Le genre d'intervention que l'on classe, presque sans y penser, dans la catégorie rassurante des changements sans risque.

Quelques minutes plus tard, un collègue me prévient : un outil interne ne répond plus. Je relis mon changement, incrédule, car rien dans ce que je venais de faire n'aurait dû l'atteindre. Je n'y avais pas touché ; je ne l'avais même pas vu tomber.

C'est cette catégorie rassurante qui m'a piégé. Ce jour-là, j'ai compris pour de bon une évidence que l'on récite sans y croire : dans une infrastructure partagée, l'isolement n'existe pas.

Un changement sans risque

Tout part d'une migration d'hébergement. Un tag marketing avait cessé de fonctionner sur notre domaine principal, et il fallait le rétablir. La solution tenait en un ajustement de routage : une seule entrée, sur un seul domaine, pour une seule raison. Rien, nulle part, ne la reliait à un autre service. À ce stade, l'affaire semblait close avant même d'avoir commencé.

Un test qui rassure

Je n'avais pourtant pas travaillé à l'aveugle. J'avais reproduit la configuration dans un environnement de test, appliqué le correctif, vérifié que tout fonctionnait sans la moindre interruption. L'essai était concluant ; je suis passé en production avec la tranquillité de celui qui a fait ses devoirs.

Mon erreur n'était pas d'avoir négligé le test. Elle était d'avoir cru qu'il disait toute la vérité. Un environnement de test reproduit ce que l'on connaît du système ; il reste muet sur ce que l'on ignore.

Le point d'appui invisible

Ce que j'ignorais, c'est que le domaine que je modifiais servait discrètement de point d'appui à d'autres services, rattachés à lui sans qu'aucun lien apparent ne le signale. En retirant mon composant, j'ai changé ce point d'appui en impasse. Tous ceux qui s'y adossaient sans le savoir se sont retrouvés sans fondations.

L'outil interne qui est tombé, celui dont dépendent les équipes qui suivent nos plus gros clients, n'était que le plus visible ; d'autres services ont sans doute vacillé, que personne n'a remarqués. Aucun client final n'était directement touché, mais les personnes chargées des comptes les plus sensibles se retrouvaient, elles, sans outil.

Mon changement ne portait pas sur une entrée dans un domaine, mais sur le sol qui soutenait un nombre inconnu de services. L'ampleur des dégâts n'avait aucun rapport avec la taille de la modification.

Ce qui a sauvé la situation

Je n'ai rien détecté par moi-même : c'est un collègue qui a donné l'alerte. Voilà le détail qui dérange, et sans doute le plus honnête : je surveillais ce que je venais de modifier, pas ce qui pouvait céder autour.

Restait une chose que j'avais eu la prudence de préparer avant d'intervenir : un retour arrière, prêt et vérifié. Je l'ai déclenché, et en quelques secondes tout était rétabli. Le correctif auquel j'avais consacré mon attention n'a pas sauvé la journée. C'est la précaution prise « au cas où », sans y croire vraiment, qui l'a fait.

Comprendre, après coup

À vrai dire, avant cet incident, j'ignorais jusqu'à l'existence du mécanisme en cause : la façon dont ce composant décide vers quelle origine envoyer chaque requête, et comment d'autres services finissent par en dépendre. On ne se méfie pas d'un piège dont on ne soupçonne pas la présence. Je l'ai donc découvert après coup, en creusant pour comprendre ce que j'avais réellement provoqué. C'est inconfortable à écrire, mais c'est souvent comme ça qu'on apprend vraiment : une notion croisée dans la douleur, on ne l'oublie plus.

Ce que j'en retiens

Depuis, je tiens le mot « isolé » pour une hypothèse à démontrer, jamais pour un acquis, surtout dans ces systèmes anciens où les dépendances ne sont consignées nulle part. Un test réussi ne prouve pas l'absence de liens cachés ; il atteste seulement que ce que l'on a su reproduire fonctionne. Quant au retour arrière, j'ai cessé de le voir comme une roue de secours : c'est la première chose à préparer, avant même le correctif. Et je regarde aujourd'hui autant ce qui peut céder que ce que je change. J'ai aussi appris à écrire ce que je fais et ce dont un système dépend : une dépendance que personne n'a documentée est un piège qui attend le suivant.

Casser la production, ça arrive, et ça arrivera encore. On doit tout faire pour l'éviter, mais le jour où ça tombe, l'important n'est pas de se flageller : c'est de comprendre pourquoi et comment, pour que ça ne recommence pas. Même les infrastructures les mieux tenues finissent par tomber. Ce qui distingue un bon ingénieur, ce n'est pas de ne jamais rien casser, c'est ce qu'il fait de ses incidents.