« Je ne veux pas les détails » : la question qui change vraiment un post-mortem

Il y a quelques mois, le responsable produit Michael Heap s'est retrouvé en réunion avec son homologue ingénieur et le patron de celui-ci, un vice-président senior de l'ingénierie, après un incident qui n'aurait pas dû se produire. Quand il a commencé à expliquer comment c'était arrivé, il a été coupé net : « Michael, je ne veux pas les détails ». Il raconte la scène et ce qu'il en a retenu dans un billet publié le 23 septembre.

Une phrase moins dure qu'il n'y paraît

Son supérieur a poursuivi en substance ainsi : si l'on entre dans les détails, les raisons seront parfaitement raisonnables, il comprendra les choix de chacun et fera preuve d'empathie, puis cela se reproduira. Ce qu'il voulait savoir, c'était ce que l'on allait changer. Heap y a d'abord vu de la désinvolture, avant de comprendre qu'il s'agissait d'un acte de confiance : le dirigeant présumait la compétence de ses équipes et passait directement à la suite.

Poser la bonne question

Après un incident, la plupart des organisations demandent « pourquoi cela est-il arrivé ? ». On reconstitue la chronologie, on explique les dépendances, on remet un document, et chacun conclut que « cela se tient » avant de passer à autre chose. Or comprendre n'est pas corriger, et une bonne explication peut même aggraver les choses : dès que tout le monde estime que le comportement était raisonnable, l'urgence de changer quoi que ce soit disparaît, et le même incident revient six mois plus tard. La question que Heap recommande à la place : qu'allons-nous changer pour qu'une défaillance de cette nature soit moins probable la prochaine fois ?

Des personnes raisonnables, un système à corriger

Le point de départ est de considérer que des personnes raisonnables ont produit ce résultat, et de se demander ce qui doit changer. L'auteur donne trois exemples :

• « Nous l'avons manqué parce qu'Alice était en congé et que Bob pensait que c'était l'affaire d'une autre équipe » : comment rendre la responsabilité sans ambiguïté quand quelqu'un est absent ?
• « Les exigences ont changé trois jours avant le lancement » : que se passe-t-il quand elles changent dans la fenêtre de lancement ?
• « L'alerte s'est déclenchée, mais l'ingénieur d'astreinte avait déjà traité vingt alertes sans importance dans la soirée » : comment améliorer le rapport entre les vraies alertes et le bruit ?

Le principe : agir sur le système, car ce sont rarement les personnes qu'il faut changer.

Une explication n'est pas une correction

Si un bilan d'incident est plein de phrases comme « nous devrions impliquer le support plus tôt », « il faut mieux communiquer » ou « nous ferons plus attention la prochaine fois », Heap y voit un ensemble de vœux pieux déguisés en progrès. Une mesure qui dépend du souvenir d'une conversation vieille de six mois relève, écrit-il, du folklore d'organisation. Son test : si toutes les personnes impliquées quittaient l'entreprise demain, la correction tiendrait-elle encore ? Sinon, les gens ont peut-être appris quelque chose, mais le système reste promis à l'échec. Une bonne question de contrôle : si la même situation se produisait demain, qu'est-ce qui conduirait à un résultat différent ?

Sans tomber dans la procédure pour la procédure

L'auteur prévient qu'on peut aller trop loin : tout échec ne mérite pas un nouveau processus, sinon on construit des environnements où personne ne veut travailler. Parfois, le coût de prévention dépasse celui d'accepter occasionnellement l'erreur, et c'est acceptable, à condition de le faire les yeux ouverts. « Nous acceptons consciemment ce risque » n'a rien à voir avec « nous avons promis de faire plus d'efforts ». Au final, conclut-il, ce que le dirigeant exprimait était une déclaration de confiance : la bonne phrase, pour un responsable, pourrait être « je vous crois, je n'ai pas besoin des détails, dites-moi ce que nous changeons ».

À lire avec recul

Le point de départ est une anecdote personnelle, racontée du point de vue d'un seul participant et sans que le dirigeant soit nommé : elle ne peut pas être vérifiée de l'extérieur. Les conseils qui en découlent relèvent du retour d'expérience de manager, et non de données, mais ils valent la peine d'être discutés bien au-delà de l'informatique, dès qu'une organisation traite ses erreurs.