Rédigez le bilan d'incident pour corriger le système, pas la personne

L'affirmation

Après une panne, l'explication la plus tentante est que quelqu'un a fait une erreur, et la réponse la plus inutile est de s'assurer que cette personne soit plus prudente la prochaine fois. Les gens sont prudents ; ils font quand même des erreurs, car la capacité de faire cette erreur précise était intégrée au système et y a été laissée. Un bilan d'incident qui conclut par « on a dit à l'ingénieur d'être plus prudent » n'a rien appris et rien corrigé, et il garantit que la même défaillance récidivera sous un autre nom. Le but du bilan est de changer le système pour que l'erreur devienne impossible ou inoffensive, pas d'identifier qui blâmer.

Pourquoi le blâme détruit l'information dont vous avez besoin

L'argument pratique contre le blâme n'est pas qu'il est cruel, même s'il l'est. C'est qu'il rend le bilan inutile en détruisant ses intrants. Dès que les gens comprennent que l'issue d'un bilan d'incident est de trouver un coupable, ils cessent de vous dire ce qui s'est vraiment passé. L'ingénieur qui a fait le changement cesse d'offrir le détail qui expliquerait pourquoi cela semblait correct sur le moment ; la personne qui a remarqué le signe avant-coureur cesse de mentionner qu'elle hésitait à escalader. Vous vous retrouvez avec un récit aseptisé qui protège les gens et n'enseigne à personne, et la vraie chaîne d'événements — celle qu'il fallait briser — reste cachée parce que la révéler est désormais dangereux.

Un bilan mené sans blâme obtient l'inverse : les gens expliquent leur raisonnement franchement, y compris celui qui s'est avéré faux, car il n'y a aucune pénalité à avoir eu tort d'une manière que le système a rendue facile. Cette franchise est toute la valeur de l'exercice. Vous ne pouvez pas corriger une défaillance que vous ne comprenez pas, et vous ne pouvez pas la comprendre si les personnes présentes gèrent leur exposition au lieu de vous dire ce qui s'est passé.

La question qui réoriente le bilan

La discipline consiste à demander sans cesse non « qui a fait cela » mais « comment était-ce possible ». Chaque erreur humaine est une invitation à trouver le système qui l'a permise :

• Un ingénieur a déployé un changement cassant un vendredi après-midi. Pourquoi était-il possible de déployer un changement qui casse la production tout court ? Où était la vérification ?
• Quelqu'un a exécuté une commande destructrice contre le mauvais environnement. Pourquoi la production et la préproduction ont-elles l'air identiques en ligne de commande ? Pourquoi cette commande n'a-t-elle aucune confirmation ?
• Une faute de frappe de configuration a mis le site hors ligne. Pourquoi une configuration valide syntaxiquement mais fausse a-t-elle atteint la production sans être attrapée ? Où était la validation ?

Dans chaque cas, l'action humaine est réelle, mais c'est le dernier maillon d'une chaîne, et chaque maillon antérieur est un endroit où le système aurait pu arrêter le résultat et ne l'a pas fait. Ces maillons antérieurs sont ce que le bilan existe pour trouver, car ils sont ce que vous pouvez réellement changer.

Ce que produit un bilan utile

Le résultat du bilan n'est pas un récit de qui a fait quoi. C'est un petit nombre de changements précis, assignés et datés au système, chacun qui aurait empêché ou réduit l'incident quelle qu'ait été la personne au clavier :

Incident : panne de production, 47 minutes
Facteurs contributifs (pas des causes-de-blame) :
- l'outil de deploiement a permis une sortie malgre une sonde en echec
- les invites de preprod et de prod sont visuellement identiques
- aucun retour arriere automatise ; la reprise fut manuelle

Actions :
- [ ] l'outil bloque la sortie si la sonde echoue       @alex  d'ici 20 oct
- [ ] l'invite de prod affiche une banniere rouge       @sam   d'ici 15 oct
- [ ] script de retour arriere en une commande, teste   @alex  d'ici 24 oct

Remarquez qu'aucune action n'est « être plus prudent » et qu'aucune ne nomme une faute. Chacune est un changement au système qui rend inoffensive la prochaine occurrence de la même action humaine. C'est le test d'une bonne action : elle fonctionne même si la personne refait exactement la même erreur, car l'enjeu n'a jamais été la personne.

La distinction qui garde le bilan honnête

Retirer le blâme n'est pas retirer l'imputabilité, et confondre les deux est ainsi que les équipes sombrent dans la recherche de coupables ou dérivent vers une négligence sans conséquence. L'imputabilité dans un bilan sain est collective et tournée vers l'avant : l'équipe s'approprie l'engagement de faire les changements précis qui préviennent la récidive, et répond de leur réalisation effective. Ce qui est retiré, c'est la recherche rétrospective d'un individu à punir, qui ne produit ni sécurité ni apprentissage. L'ingénieur qui a causé la panne est fréquemment la meilleure personne pour aider à concevoir le correctif, car il comprend la défaillance le plus intimement — et il ne le fera librement que dans un bilan qui ne cherche pas à le condamner.

Rendez les actions réelles

La façon la plus courante dont les bilans d'incident échouent n'est pas le blâme mais l'évaporation : le bilan a lieu, les actions sont listées, et rien n'est construit parce que les actions n'ont ni responsable ni date et concurrencent un travail de fonctionnalités qui semble plus urgent. Une action sans responsable nommé et sans échéance est un souhait. Traitez les actions du bilan comme un vrai travail, suivi comme tout autre engagement, avec la même visibilité, et revenez-y — un bilan dont les actions sont encore ouvertes quand le prochain incident semblable survient vous a dit exactement quoi prioriser, et vous a dit aussi que votre processus de bouclage est lui-même un système à corriger.

La norme à tenir

Jugez chaque bilan d'incident par une question : après ce bilan, le système est-il différent d'une manière qui rend cette défaillance moins probable ou moins grave, quel que soit celui qui l'exploite ? Si oui, le bilan a fait son travail. Si la seule chose qui a changé est que quelqu'un se sent mal et a résolu d'être plus prudent, alors rien n'a changé, car la prudence n'a jamais été l'ingrédient manquant — l'ingrédient manquant était un système qui ne dépendait pas d'un humain fatigué réussissant chaque étape au pire moment possible. Construisez ce système, un incident à la fois, et les bilans se composent en une fiabilité véritable plutôt qu'en une recherche récurrente de coupable.