Résumé rapide
Une rétrospective sans blâme part du principe que les personnes ont pris des décisions raisonnables avec les informations qu'elles avaient. La réunion cherche les conditions qui ont rendu l'erreur probable : alertes manquantes, runbook confus, fenêtre de déploiement, revue qui ne pouvait pas voir le risque. Vous nommez quand même ce qui s'est passé. Vous ne nommez pas un coupable comme correctif.
Cette définition couvre deux réunions que les gens confondent. Une rétro de sprint peut être sans blâme sur la façon dont l'équipe a travaillé. Une rétro d'incident est sans blâme sur un seul échec, et elle a besoin d'une chronologie.
Ce que « sans blâme » veut dire, et ce que cela ne veut pas dire
Cela ne veut pas dire que personne n'est responsable. Quelqu'un possède encore le prochain changement sur l'alerte, le runbook ou le déploiement. Cela veut dire que l'action est un changement de système. « Jordan devrait être plus prudent » est du blâme. « Les déploiements en production exigent une deuxième personne le vendredi après 16:00, sous la responsabilité du responsable d'astreinte, revu dans deux semaines » est une action sans blâme.
Cela ne veut pas dire non plus une réunion molle sans faits. Une rétro sans blâme sans chronologie devient un cercle de ressentis, et la même panne revient.
La Prime Directive de Norm Kerth est la phrase d'ouverture habituelle : avec les informations qu'elles avaient, les personnes ont fait de leur mieux. Dites-la au début si la salle est tendue. Passez ensuite à la chronologie. La phrase n'est pas toute la réunion.
Sans blâme dans une rétro de sprint ordinaire
Vous n'avez pas besoin d'une panne. Utilisez un langage sans blâme quand les cartes commencent à nommer des personnes :
- Remplacez « Alex a cassé le build » par « le build est resté rouge pendant une journée parce que le contrôle en échec n'était pas obligatoire sur la pull request ».
- Remplacez « le produit n'arrête pas de changer le périmètre » par « trois stories ont changé les critères d'acceptation après le début du développement ».
Puis votez et choisissez un changement de système. Le reste de l'ordre du jour est la rétrospective de sprint habituelle : cartes silencieuses, un vote, une à trois actions.
Comment mener une rétrospective d'incident sans blâme
Menez-la dans les quelques jours qui suivent l'incident, pas à la prochaine rétro de sprint. Invitez les personnes qui étaient dans la réponse, plus un animateur capable d'arrêter le blâme. Limitez-la à 45–60 minutes pour un incident.
1. Écrire la chronologie avant la réunion (15 minutes, en asynchrone)
Une liste partagée, la plus ancienne en premier :
- quand le premier signal s'est déclenché, ou quand un client a écrit
- quand une personne l'a vu
- ce qu'elle croyait être en train de se passer
- ce qu'elle a changé
- quand l'impact s'est arrêté
Demandez à chaque personne d'ajouter les étapes qu'elle a suivies. Faites-le par écrit pour que la réunion ne soit pas un concours de mémoire. Les cartes anonymes aident pour la ligne « ce que je croyais » si les gens s'attendent à une sanction.
2. Ouvrir la règle (2 minutes)
Dites : nous ne désignerons pas une personne comme cause. Nous repartirons avec des changements sur la détection, la décision ou le rétablissement. Si un nom apparaît, écrivez plutôt la condition autour de cette personne.
3. Parcourir la chronologie (15 minutes)
Lisez-la dans l'ordre. Demandez seulement : que savions-nous à cette minute, et qu'ont montré les outils ? Corrigez les heures. Ne sautez pas encore à « ce que nous aurions dû faire ».
4. Trouver les conditions contributives (15 minutes)
Groupez les notes en trois colonnes :
- Détection : alerte absente, alerte bruyante, tableau de bord que personne n'ouvre
- Décision : runbook faux, responsable peu clair, deux personnes font des changements opposés
- Rétablissement : rollback lent, flag coincé, message client tardif
Ces colonnes gardent la conversation sur le système. Une carte qui ne dit qu'un nom n'obtient pas de vote.
5. Choisir un à trois correctifs (10 minutes)
Chaque correctif nomme la condition, le changement, un responsable et une date. Privilégiez un correctif de détection. Les incidents qui ne déclenchent aucun page se reproduiront, si prudent soit l'ingénieur.
Envoyez la chronologie et les actions à l'équipe. Ne rangez pas le document là où seul l'animateur peut le trouver. Revoyez les actions à la prochaine rétro de sprint, dans les cinq premières minutes.
Formulations que vous pouvez corriger dans la salle
| Blâme | Sans blâme |
|---|---|
| Qui a livré ceci ? | Quel contrôle ne s'est pas exécuté avant la livraison ? |
| Ils auraient dû savoir | Qu'affichait le tableau de bord à cette minute ? |
| Erreur humaine | Quelle étape n'a pas eu de second regard, et pourquoi était-ce normal ? |
Questions fréquentes
Qu'est-ce qu'une rétrospective sans blâme ?
C'est une rétrospective qui traite l'échec comme une propriété du système. Les personnes décrivent ce qu'elles savaient à ce moment-là. Les actions changent les alertes, les runbooks, les revues ou les règles de déploiement. Le nom d'une personne n'est pas l'action corrective.
Comment mener des rétrospectives d'incident sans blâme ?
Écrivez la chronologie avant la réunion, interdisez « qui a causé cela » comme résultat, triez les notes en détection, décision et rétablissement, et repartez avec un à trois changements de système attribués. Gardez-la séparée de la rétro de sprint.
Un post-mortem sans blâme est-il la même chose ?
Oui, dans ce but. Post-mortem, revue d'incident et rétrospective d'incident sont la même réunion quand elles utilisent une chronologie et refusent le blâme comme correctif. Une rétrospective de sprint est une réunion différente, sur l'ensemble du sprint.
Créer un tableau gratuit et placez Détection, Décision et Rétablissement dans les colonnes. Les participants peuvent rejoindre la session depuis le lien sans compte.
