Architecture & exploitation

La plupart des pannes ne viennent pas d'un bug. Elles viennent d'une dépendance dont personne n'avait mesuré la criticité — un composant introduit pour aller plus vite, devenu au fil du temps un point de défaillance unique sans que la décision ait jamais été prise consciemment.

Le schéma se répète avec une régularité troublante. Un cache est ajouté pour soulager la base de données : personne ne le considère comme critique, puisque le site fonctionnait avant lui. Puis on lui confie les sessions, parce que c'est pratique et déjà disponible. À partir de cet instant, le cache n'est plus une optimisation : sa perte n'interrompt plus une accélération, elle interrompt le service. Rien n'a été décidé ; la criticité s'est déplacée toute seule.

Les guides de cette rubrique analysent des incidents réels selon cette grille. Un cache saturé qui fait tomber une interface d'administration. Un site qui s'effondre parce qu'une API externe est saturée. Un planificateur de tâches à l'arrêt depuis des semaines sans qu'aucun voyant ne passe au rouge. Dans les trois cas, l'infrastructure était « en bonne santé » au sens des outils de supervision.

Deux principes reviennent systématiquement. Le premier : séparer ce qui est jetable de ce qui ne l'est pas. Un cache doit pouvoir disparaître sans conséquence ; s'il porte un état non reconstructible, ce n'est plus un cache. Le second : superviser les effets, pas les processus. Vérifier qu'un conteneur tourne ne dit rien de ce qu'il fait — et une tâche périodique qui ne s'exécute plus ne produit aucun signal, seulement une absence que personne ne surveille.

L'objectif n'est pas de construire des systèmes qui ne tombent jamais : c'est d'obtenir des systèmes qui se dégradent proprement, et dont les pannes se signalent d'elles-mêmes plutôt que d'être découvertes trois semaines plus tard, par hasard.