Que faites-vous pour empêcher le même type d'incident de se reproduire une seconde fois ?

Question

Accepted Answer

Mener un **postmortem sans blâme** qui trouve la cause systémique, puis le convertir en actions **concrètes, attribuées et suivies** — et vérifier qu'elles sont réellement livrées. L'objectif n'est pas de trouver qui blâmer ; c'est de changer le système pour que la même classe de défaillance devienne impossible ou auto-détectable.

## La boucle centrale

1. **Postmortem sans blâme.** Construire une chronologie honnête : ce qui s'est passé, quand on l'a détecté, comment on a réagi, quel a été l'impact. Le blâme tue la vérité dont vous avez besoin.
2. **Creuser jusqu'à la cause systémique**, pas le déclencheur. « Un ingénieur a poussé une mauvaise config » est un déclencheur ; « il n'y avait ni validation ni déploiement progressif pour les configs » est la cause. Utiliser les **Cinq Pourquoi** mais s'arrêter au système, jamais à une personne.
3. **Générer des couches de prévention**, pas un correctif unique :
   - **Prévenir** — rendre la défaillance impossible (validation, types, garde-fous).
   - **Détecter** — l'attraper plus tôt (alertes, SLOs, checks synthétiques).
   - **Mitiger** — limiter le rayon d'impact (rollback, flags, circuit breakers).
4. **Attribuer des responsables et des échéances.** Une action sans responsable est un vœu. Les suivre comme du vrai travail dans le backlog.
5. **Vérifier et boucler la boucle.** Le correctif a-t-il été livré ? Aurait-il attrapé l'original ? Le MTTR et la détection se sont-ils réellement améliorés ?

## Arbitrages et pièges

- **Des postmortems qui produisent des documents, pas des changements** — l'échec le plus courant. Aucun suivi signifie que vous reverrez le même incident.
- **Sur-corriger le symptôme spécifique** tandis que la classe de bug reste ouverte. Corriger la catégorie, pas seulement cette instance.
- **La fatigue d'alerte** d'empiler de la détection sans la régler ; les alertes bruyantes sont ignorées et le prochain incident passe au travers.
- **Une culture du blâme** pousse le reporting dans la clandestinité ; vous perdez les quasi-accidents qui sont vos leçons les moins chères.
- Traiter les **incidents récurrents comme un signal de défaillance du processus**, pas de malchance — suivre la récurrence comme une métrique.

## Pourquoi c'est important

Les incidents sont des frais de scolarité déjà payés ; le seul gaspillage est de ne pas en tirer de leçon. Une équipe qui prévient systématiquement la récurrence devient plus fiable chaque trimestre, tandis qu'une équipe qui ne fait qu'éteindre des feux revit les mêmes pannes pour toujours. Construire cette boucle d'apprentissage — et la sécurité d'y être honnête — est l'une des choses les plus durables qu'un Tech Lead puisse laisser derrière lui.