Ce qu'un retour d'expérience doit produire
Pas un coupable. Pas un compte rendu. Un changement.
Un retour d'expérience qui se termine par « il faudra faire plus attention » n'a rien produit : l'attention n'est pas un mécanisme, elle ne survit pas à la fatigue ni au remplacement des personnes.
Le seul résultat qui compte est une modification du système, de la procédure ou de la surveillance, avec un responsable et une échéance.
Le format qui tient en une page
La chronologie. Heure par heure, ce qui s'est passé et ce qui a été fait. Les horloges synchronisées de la leçon sur les journaux servent exactement ici.
L'impact. Qui a été touché, combien de temps, ce qui a été perdu. En termes de service, pas de composants.
Ce qui a permis la détection. Une alerte, ou un appel d'utilisateur ? La réponse est un verdict sur votre supervision, et c'est la ligne la plus instructive du document.
Les causes. Au pluriel : une panne a rarement une cause unique.
Les actions. Chacune avec un responsable et une date. Sans cela, la liste est décorative.
Chercher la cause, sans chercher un coupable
Une panne déclenchée par une commande mal tapée n'a pas pour cause l'inattention de la personne. Elle a pour causes une commande dangereuse sans confirmation, une absence de test avant application, un environnement de production accessible sans garde-fou.
Ce déplacement du regard n'est pas de l'indulgence, c'est de l'efficacité : on ne peut pas corriger une inattention, on peut ajouter une confirmation.
La conséquence pratique est immédiate. Dans une équipe qui cherche des coupables, les incidents cessent d'être signalés et sont réparés en silence, ce qui prive tout le monde de l'information.
La question la plus productive
Pourquoi a-t-il fallu quarante minutes pour comprendre ?
Le temps de diagnostic est presque toujours plus long que le temps de réparation, et c'est sur lui que la marge de progrès est la plus grande.
Les réponses reviennent souvent : l'alerte ne disait pas quoi regarder, les journaux étaient sur trois machines, personne ne savait qui appeler, la documentation décrivait un système d'il y a deux ans.
Chacune de ces réponses est une action concrète.
Le suivi, sans lequel rien ne change
Les actions décidées après un incident se perdent en trois semaines si elles ne rejoignent pas la file de travail ordinaire, avec la même visibilité que le reste.
Un contrôle simple : au retour d'expérience suivant, relire les actions du précédent. Si aucune n'a été faite, le problème n'est pas l'incident, c'est le processus.
À retenir
Un retour d'expérience produit un changement, pas un compte rendu. Notez ce qui a permis la détection, cherchez les causes au pluriel, et travaillez le temps de diagnostic plutôt que le temps de réparation. Les actions rejoignent la file ordinaire, sinon elles n'existent pas.