Gérer un incident, écrire le post-mortem

Quand la prod casse : l'ordre des priorités

Un incident réel (une vague de 500 sur les commandes, plusieurs tenants touchés) suit un ordre non négociable :

1. restaurer le service AVANT de comprendre : rollback sur le tag précédent (leçon 2 !), redémarrage, coupure de la feature fautive — on répare l'hémorragie, l'autopsie vient après. Le réflexe inverse (« laisse-moi trouver la cause ») rallonge la panne ;
2. ouvrir un canal d'incident dédié (#inc-2026-… chez le projet étudié) : un lieu unique, horodaté, où l'état s'écrit en temps réel — qui fait quoi, ce qu'on sait, ce qu'on tente. La communication EST une tâche de l'incident, pas une distraction ;
3. quantifier l'impact : « 123 requêtes en 500, 8 tenants, endpoints orders » — des chiffres, pas « ça marche pas ». L'impact chiffré priorise et cadre la comm ;
4. identifier les données à rejouer : après restauration, la réconciliation (les commandes non passées, à rejouer) — le nettoyage post-incident est une étape à part entière.

Les rôles pendant l'incident

Même en petite équipe, deux casquettes se distinguent : le commandant (coordonne, décide, protège l'équipe des sollicitations) et les intervenants (creusent, tentent, mesurent). L'erreur classique : tout le monde débogue en parallèle sans coordination, personne ne communique, et trois hypothèses se marchent dessus. Un incident bien géré est calme — le canal structuré remplace la panique.

Le post-mortem sans coupable

Une fois le calme revenu : le post-mortem (l'ADR de l'échec — cours Stack IA à l'envers). Sa règle d'or est blameless : on cherche la cause systémique, jamais la personne. « Pourquoi ce déploiement a-t-il pu casser la prod ? » (garde-fou manquant) et non « qui l'a poussé ? ». La structure :

• timeline : ce qui s'est passé, minute par minute (le canal d'incident la fournit gratuitement) ;
• cause racine : les 5 pourquoi jusqu'au facteur systémique ;
• impact : chiffré, honnête ;
• actions : chacune un ticket assigné — le garde-fou qui aurait empêché (un test, une alerte, une validation). Un post-mortem sans actions concrètes est un exutoire, pas une amélioration.

La boucle vertueuse : chaque incident renforce le système (un nouveau test E2E, une alerte de plus, un invariant en hook). C'est le pendant ops de l'eval-driven : l'échec devient un cas de non-régression. Une équipe mûre ne promet pas « zéro incident » — elle promet « aucun incident deux fois pour la même raison ».