Erreur en production : un retour d'expérience sans blâme

Prenons une situation simple : une intervention de maintenance coupe une application utilisée par la comptabilité. Le service revient, puis le DSI demande qui a lancé la commande. Le nom arrive immédiatement. L’explication, beaucoup moins.

Je ne considérerais pas le dossier comme clos parce que l’auteur du geste a été identifié. Ce qui m’intéresse, c’est de comprendre pourquoi cette opération paraissait appropriée, comment elle a pu toucher ce périmètre et ce qui permettrait au prochain intervenant d’éviter le même piège. Le retour d’expérience commence après le rétablissement, avec cette intention annoncée à l’équipe.

Choisir les événements à examiner avec l’équipe

Je définirais les motifs d’un retour d’expérience avant la prochaine panne. Un impact métier important, un incident qui revient, une protection qui n’a pas fonctionné ou une récupération reposant sur un heureux hasard constituent des points de départ. L’équipe doit aussi pouvoir proposer un événement dont elle ne comprend pas bien le déroulement.

Le chapitre de Google sur la culture du retour d’expérience recommande de fixer les critères de déclenchement en amont et de rechercher les facteurs contributifs sans mettre les personnes en accusation. Je retiens ce cadre, sans transposer l’organisation d’une grande équipe d’exploitation à une DSI d’ETI.

Tout ne nécessite pas une réunion. Une erreur connue, sans conséquence nouvelle, peut rejoindre une correction déjà suivie. À l’inverse, attendre une panne spectaculaire laisse de côté les incidents évités de justesse. Je demanderais ce qui a empêché l’impact : une protection prévue ou la présence fortuite d’un collègue ? La réponse aide à décider si l’analyse mérite du temps.

Préparer une chronologie qui distingue faits et interprétations

Avant la séance, je demanderais aux intervenants de compléter une chronologie commune. Elle contiendrait l’objectif de l’opération, les informations disponibles avant d’agir, les manipulations effectuées, les premiers symptômes et les éléments ayant permis la reprise. Les journaux techniques et le ticket servent d’appui ; ils ne racontent pas seuls ce que chacun avait compris.

Dans notre exemple, écrire que la commande a arrêté l’application décrit un enchaînement. Écrire que l’administrateur a été imprudent introduit déjà un jugement. Je demanderais plutôt quel environnement il pensait viser, ce que l’écran affichait et quelle vérification était réellement possible avant validation.

Les horaires incertains et les souvenirs contradictoires resteraient signalés. Une chronologie propre mais reconstruite à partir de suppositions donne une assurance trompeuse. Si un point manque, je lui associerais une recherche précise, sans retarder toute la discussion pour obtenir un récit parfait.

Je ferais également préciser l’impact par le métier concerné. Une application redevenue accessible peut laisser des opérations à reprendre. Les messages diffusés pendant la panne, traités dans l’article sur la communication d’incident, fournissent des traces utiles, mais ne remplacent pas cette vérification après coup.

Donner un cadre de parole que le DSI respecte lui-même

J’inviterais les personnes qui ont agi, celles qui connaissent les protections attendues et un représentant du métier si son éclairage est nécessaire. La présence de toute la hiérarchie n’est pas un gage de qualité. Je préciserais au départ ce qui sera consigné et à qui le document sera transmis.

Microsoft recommande une analyse sans blâme conduite par un animateur impartial. Si j’ai demandé d’accélérer la maintenance ou accepté une préparation incomplète, je confierais l’animation à un collègue capable de me questionner. Mon arbitrage doit apparaître dans la discussion au même titre que la commande exécutée.

Je commencerais par laisser les intervenants raconter ce qu’ils cherchaient à faire, sans correction immédiate par ceux qui connaissent maintenant l’issue. L’animateur demanderait ensuite les informations manquantes et reformulerait les reproches en questions sur le travail réel.

Ce cadre a une limite : annoncer une séance sans blâme ne répare pas une confiance déjà abîmée. Si les participants craignent que chaque phrase leur soit reprochée ensuite, il faut entendre cette difficulté. Je ne promettrais pas une confidentialité absolue impossible à tenir, et je séparerais explicitement cette analyse collective d’un éventuel entretien individuel sur un comportement.

Remplacer les jugements par des questions vérifiables

Identifier la personne qui a agi ne dit pas quelle protection manquait.

Je refuserais de terminer l’analyse par une formule comme manque de vigilance. Elle n’explique ni pourquoi la vérification a été omise, ni pourquoi cette omission a suffi à provoquer la panne. Voici une grille de reformulation que j’utiliserais pendant la séance.

Dans l’exemple de maintenance, une cible mal identifiée peut se combiner avec un périmètre trop large et une procédure difficile à consulter depuis le poste utilisé. Je ne chercherais pas à faire entrer tout cela dans une cause unique.

Je demanderais aussi ce qui a aidé : une personne a signalé son doute, une vérification a limité l’impact, un collègue connaissait le moyen de revenir en arrière. Ces éléments méritent d’être conservés. Sinon, la réunion produit uniquement une liste d’interdictions, sans reconnaître les pratiques qui ont permis la reprise.

Retenir des corrections réalisables et démontrer leur effet

Le guide pratique de Google sur les postmortems insiste notamment sur des actions dont l’état final est vérifiable. Je demanderais, pour chaque proposition, quelle observation permettra de dire que la situation a changé.

Pour notre maintenance, afficher clairement la cible, limiter la portée de la commande ou prévoir une vérification préalable sont des pistes à examiner. Leur pertinence dépend du mécanisme réellement en cause. Ajouter une confirmation que chacun validera machinalement peut allonger la procédure sans protéger davantage.

Je retiendrais un ensemble limité de corrections, avec un responsable, une échéance et un essai prévu. Le responsable coordonne la réalisation ; il ne devient pas le coupable désigné si elle tarde. Un contrôle de cible pourrait être vérifié dans un environnement isolé en présentant volontairement une configuration incohérente et en observant si l’opération est bloquée.

Une formation peut être utile lorsqu’une compétence manque. Elle ne remplace pas une protection contre une confusion prévisible. De même, imposer une double validation à toute manipulation peut créer une attente permanente. Je réserverais cette contrainte aux opérations pour lesquelles un second regard apporte une vérification précise et indépendante.

Fermer l’analyse et garder les actions dans le planning

Je ferais relire le compte rendu aux participants pour corriger les faits, conserver les désaccords non résolus et vérifier les responsabilités acceptées. Une synthèse pourrait ensuite être partagée avec les équipes concernées : événement, facteurs identifiés, protections retenues et points encore ouverts. Les secrets techniques et les données personnelles inutiles n’ont pas leur place dans cette diffusion.

Le DSI doit ensuite réserver la capacité nécessaire. Une correction inscrite dans un compte rendu mais absente du planning reste une intention. Si elle est reportée, je noterais la raison, le risque conservé et la date du prochain arbitrage. Le travail sur les interruptions et le temps de projet s’applique aussi à ces actions de fiabilisation.

Pour démarrer la semaine suivante, je choisirais un événement récent encore bien documenté et préparerais la chronologie avec ses intervenants. La séance devrait aboutir à des questions résolues, des inconnues attribuées et des corrections testables. Lors du suivi, je regarderais leurs résultats avec l’équipe. Si le même incident revient, je rouvrirais l’analyse avant de conclure que les personnes n’ont pas retenu la leçon.