La gestion d'incident ne s'arrête pas au rétablissement — Un modèle de postmortem (prévention de la récurrence) pour les petites équipes de développement

« On revoit la même erreur que vous aviez corrigée le mois dernier, mais cette fois sur un autre écran » — quiconque assure la maintenance d’un système a probablement déjà entendu cette phrase, et s’est retrouvé sans savoir quoi répondre.

La gestion d’incident elle-même — détecter, localiser la cause, corriger, livrer, s’excuser — est quelque chose que la plupart des équipes font déjà correctement. Le problème, c’est ce qui vient après. Dès le rétablissement, tout le monde retourne à son travail habituel, et la trace de l’incident finit par s’effacer, éparpillée entre la boîte mail et les journaux de discussion de quelqu’un. Six mois plus tard, une panne structurellement identique se reproduit ailleurs, et la même investigation est refaite depuis zéro. Traiter la gestion d’incident comme « on corrige, on s’excuse, terminé » revient à payer sans cesse le même prix d’apprentissage.

Sur ce blog, nous avons déjà couvert le versant technique de l’investigation d’incident — comment remonter jusqu’à la cause profonde — dans « Introduction à la collecte des dumps de crash Windows » et « Où placer le catch et la journalisation dans la gestion des exceptions ? ». Cet article traite de l’étape suivante : comment mener la rétrospective (le postmortem) qui garantit que le même incident ne se reproduira plus, une fois la cause déjà connue. Plutôt que les services web à grande échelle, nous nous concentrons étroitement sur un modèle qu’une petite équipe de deux à cinq personnes assurant la maintenance d’applications métier et de logiciels Windows peut réellement tenir dans la durée.

1. La conclusion d’abord

• Le rétablissement, l’investigation de la cause profonde et la prévention de la récurrence sont des tâches distinctes. Le rétablissement signifie « remettre en route l’activité du jour » ; l’investigation de la cause profonde signifie « être en mesure d’expliquer pourquoi c’est arrivé » ; la prévention de la récurrence signifie « changer le système ». Les mélanger fait que les trois restent inachevées.
• Ne pas chercher de coupable (être blameless) relève de la pragmatique, pas de l’éthique. Dans un contexte où les individus sont blâmés, l’information cesse de remonter et l’on n’atteint jamais la cause profonde. Supposer que toutes les personnes impliquées ont agi correctement compte tenu des informations dont elles disposaient à ce moment-là, puis chercher la faille du système — c’est le principe du postmortem blameless établi dans la pratique du SRE.¹
• Les mesures de prévention de la récurrence doivent s’incarner dans un système (code, tests, supervision, procédures), pas dans « être vigilant ». Les mesures qui dépendent de l’attention humaine disparaissent dès que la personne en charge change. Le chapitre 6 propose un tableau de décision pour évaluer la solidité d’une mesure donnée.
• Séparez la cause en une « cause directe » et des « facteurs contributifs ». Ce que l’on peut réellement corriger, ce sont généralement les facteurs contributifs, et l’astuce des « 5 pourquoi » consiste à ne pas s’arrêter à l’action d’une personne, mais à creuser jusqu’au système.
• N’appliquez pas un postmortem complet à chaque incident. Triez selon l’impact multiplié par la probabilité de récurrence (chapitre 7), et pour les incidents mineurs, laissez simplement une trace d’un paragraphe. Maintenir une charge de travail soutenable est la condition numéro un pour ne pas tuer la pratique.
• Dimensionnez le postmortem pour qu’il puisse être rédigé en une heure. Le chapitre 4 propose un modèle minimal. Laisser une trace grossière à chaque fois vaut mieux que rédiger zéro document soigné par mois.
• En développement en sous-traitance, distinguez la finalité du rapport d’incident destiné au client tout en réutilisant son contenu à partir du postmortem (chapitre 8). Ne pas mélanger le document de reddition de comptes et le document de prévention de la récurrence protège la qualité des deux.

2. Pourquoi les mêmes incidents se répètent

Les incidents qui se reproduisent suivent un schéma opérationnel, et non technique.

Dès que le rétablissement a lieu, on considère que c’est « terminé ». La gestion d’incident est une interruption d’urgence, donc une fois la situation revenue à la normale, tout le monde retourne au travail habituel accumulé entre-temps. Personne n’a bloqué de temps dans son agenda pour la rétrospective, et « quand ça se sera calmé » n’arrive jamais réellement.

Le rapport se termine par « nous serons plus vigilants à l’avenir ». La section prévention de la récurrence d’un rapport destiné à un client ou à un supérieur se conclut par des formules comme « nous vérifierons scrupuleusement » ou « nous procéderons à une double vérification ». Cette formulation ne change rien au système, si bien que quelques mois plus tard, une fois la vigilance retombée, tout le monde retombe dans le même piège.

Rejeter la faute sur un individu sans jamais corriger la structure. Clore le dossier par « c’est parce que cette personne a sauté le test », et la structure qui a permis de sauter ce test — aucune porte de test dans la procédure de livraison, omissions tacitement tolérées sous la pression des délais — reste intacte. La fois suivante, quelqu’un d’autre commet la même omission.

Aucune trace ne subsiste, et on retombe dans le même piège des années plus tard. La maintenance en petite équipe fonctionne un temps même sans traces, précisément parce que c’est toujours la même personne qui s’occupe de tout. Mais la mémoire de cette personne s’estompe au fil des années, et disparaît totalement lorsqu’elle quitte l’entreprise ou passe le relais. « J’ai l’impression d’avoir déjà vu cette erreur, mais je ne me souviens plus de ce qu’on avait fait » transforme une investigation qu’une trace écrite aurait ramenée à 10 minutes en une journée entière de travail.

Rien de tout cela n’est une question de compétence — c’est la conséquence du fait que la rétrospective n’a jamais été définie comme faisant partie du travail. C’est précisément pour cela qu’il vaut la peine de fixer d’avance un modèle (un format de document et des critères de déclenchement).

3. Qu’est-ce qu’un postmortem — Traduire le modèle SRE pour la maintenance à petite échelle

Un postmortem est un modèle de rétrospective destiné à documenter un incident — impact, cause profonde, chronologie de la réponse et actions de prévention de la récurrence — largement popularisé par la pratique du Site Reliability Engineering (SRE) de Google. Son cœur repose sur le principe d’être blameless (sans recherche de coupable). « Un postmortem blameless part du principe que toutes les personnes impliquées ont agi de bonne foi, en faisant ce qui leur semblait juste compte tenu des informations dont elles disposaient à ce moment-là » — au lieu de punir les personnes, on corrige le système qui a fait obstacle à la bonne décision.¹

Cette idée n’est pas propre à Google. Les directives d’architecture de Microsoft (l’Azure Well-Architected Framework) définissent elles aussi le postmortem comme « une revue structurée et sans recherche de coupable impliquant l’ensemble des équipes concernées », et recommandent de réinjecter les résultats de l’analyse de la cause profonde (RCA) dans le système sous forme d’améliorations du processus de réponse, de renforcement de la détection (observabilité) et d’améliorations de la conception.²

Il est facile de se dire « nous ne sommes pas un service web à grande échelle, donc cela ne nous concerne pas », mais je pense exactement l’inverse. Le postmortem porte ses fruits précisément dans le cas d’une petite équipe, sans personne détachée chez le client, qui assure la maintenance d’une application de bureau. Il y a trois raisons à cela.

1. C’est toujours la même personne qui traite les incidents, donc sans traces écrites, le savoir reste totalement enfermé dans une seule tête. Dans une grande organisation, quelqu’un d’autre s’en souvient généralement ; dans une équipe de deux ou trois personnes, « la personne qui se souvient » est la seule base de données existante. Le postmortem devient cette mémoire externe.
2. Les incidents sont espacés dans le temps. Contrairement à un service web, les incidents graves d’une application métier ne se comptent qu’en quelques-uns par an. Le suivant a tendance à survenir juste au moment où le souvenir de la réponse précédente s’est déjà estompé, ce qui rend la valeur d’une trace écrite d’autant plus élevée.
3. Ne pouvant pas se rendre sur place, les preuves et les traces deviennent la ligne de vie. En maintenance à distance, tout repose sur la capacité à reconstituer après coup « ce qui se passait réellement à ce moment-là », ce qui rejoint directement la chronologie consignée dans un postmortem.

Comme repère approximatif de ce qui justifie un postmortem, le livre SRE cite des exemples tels que les interruptions visibles par les utilisateurs, la perte de données, ou les cas ayant nécessité une intervention d’astreinte.¹ Nous revenons sur des critères adaptés à une petite équipe au chapitre 7.

4. Un modèle minimal de postmortem

La condition la plus importante pour tenir cette pratique dans la durée est la charge de travail qu’elle représente. Voici un modèle Markdown conçu avec pour plafond de pouvoir en rédiger la première version en une heure. Il est recommandé de le conserver sous forme de fichier daté dans un dossier tel que docs/postmortem/ du dépôt, versionné au même endroit que le code.

# Postmortem : la liste des commandes affiche des lignes en double
# de part et d'autre d'un changement de date (2026-07-15)

- Statut : Terminé / Actions en cours / Simple ouverture
- Auteur : Komura
- Gravité : Moyenne (l'activité s'est poursuivie, mais un
  rapprochement manuel a été nécessaire)

## Résumé (3 lignes maximum)
En ouvrant la liste des commandes pendant l'exécution du traitement
de clôture mensuelle, les bons de la veille apparaissaient en double.
Problème d'affichage uniquement ; les données en base étaient correctes.

## Impact (qui / quoi / combien)
- Personnes touchées : 3 employés du service commercial
- Ce qui s'est passé : lignes en double sur l'écran de liste. 1 cas
  où une expédition a failli être envoyée deux fois par erreur
- Durée : environ 09h10-11h40 le 15/07 (environ 2 h 30)

## Chronologie
- 09h10 Un utilisateur appelle : « le même bon apparaît sur deux
  lignes » (détection)
- 09h30 Partage d'écran à distance ; confirmation des conditions
  de reproduction
- 10h15 Solution provisoire : demander aux utilisateurs de ne pas
  ouvrir la liste pendant la clôture
- 11h40 Version corrigée déployée et rétablissement confirmé

## Cause directe
La requête de liste effectuait un UNION ALL entre la table
principale et les lignes que le traitement de clôture avait copiées
dans une table temporaire (sans verrouillage).

## Facteurs contributifs
- L'exécution simultanée du traitement de clôture et de la requête
  d'affichage n'était couverte par aucun scénario de test
- L'existence de la table temporaire n'avait jamais été consignée
  dans le document de conception, donc elle n'a pas été prise en
  compte lors de la modification de l'écran
- Aucun mécanisme ne détectait l'affichage en double ; la découverte
  reposait entièrement sur la vigilance des utilisateurs

## Ce qui a bien fonctionné
- L'utilisateur avait noté l'heure dans son propre journal
  d'opérations, ce qui a permis d'identifier rapidement les
  conditions de reproduction
- Le pipeline de déploiement était automatisé, ce qui a permis de
  livrer le correctif le jour même

## Actions de prévention de la récurrence (responsable et échéance)
- [ ] Ajouter une assertion de détection des doublons à la requête
      de liste (Komura, 22/07)
- [ ] Ajouter un test d'exécution simultanée clôture/consultation
      (Komura, 29/07)
- [ ] Abandonner l'approche par table temporaire et envisager une
      isolation par snapshot (Komura, décision de politique fin août)

Quelques remarques sur la façon de bien rédiger ce document.

• Limitez le « Résumé » à trois lignes maximum. La personne qui ira rechercher ce document plus tard, c’est votre futur vous. Pouvoir comprendre le contenu en trois lignes lors d’une recherche compte davantage qu’une structure élégante.
• La chronologie ne doit contenir que des faits, chacun horodaté. Séparez l’interprétation (« cela aurait dû… », « on aurait dû… ») dans les sections consacrées aux causes. Mélanger de l’interprétation à la chronologie fait perdre la capacité de reconstituer, à la relecture, ce qui s’est réellement passé.
• Notez toujours « ce qui a bien fonctionné ». Cela évite que la rétrospective ne tourne à l’autoflagellation, et donne un point d’entrée pour transformer en véritable mécanisme ce qui a fonctionné par chance (un journal qui se trouvait justement être là, par exemple).
• Chaque action doit obligatoirement avoir un responsable et une échéance. Une action sans les deux ne sera jamais réalisée. L’efficacité réelle d’un postmortem se mesure au fait qu’il soit relu et que ses actions soient suivies.¹

5. La pratique de l’analyse des causes — Séparer la cause directe des facteurs contributifs

Il y a une raison pour laquelle le modèle sépare le champ des causes en deux.

La cause directe est l’événement technique qui a directement déclenché l’incident — « une exception due à un contrôle NULL manquant », « un UNION ALL sans verrouillage ». C’est ce que le correctif répare réellement.

Les facteurs contributifs sont les conditions qui ont permis à la cause directe de s’introduire, de passer inaperçue ou d’aggraver les dégâts — « il n’existait aucun test pour ce cas », « ce n’était pas écrit dans le document de conception », « la détection reposait sur la vigilance de l’utilisateur ». C’est le principal terrain de jeu des mesures de prévention de la récurrence, et il y en a généralement plusieurs.

La raison de cette séparation est simple : ne corriger que la cause directe, en laissant subsister les facteurs contributifs, et une autre cause directe empruntera le même chemin. L’exemple « la même erreur, mais sur un autre écran » cité en ouverture de cet article en est l’illustration parfaite.

5.1 Ne laissez pas les « 5 pourquoi » s’arrêter à « l’action d’une personne »

La méthode des « 5 pourquoi » (5 Whys) est un outil efficace pour creuser une cause, mais si l’on creuse dans la mauvaise direction, elle se transforme en outil de chasse au coupable. L’échec type consiste à s’arrêter à « pourquoi ? — parce que la personne responsable a oublié de vérifier ». Ne vous arrêtez pas là ; creusez encore un cran.

• Pourquoi a-t-il été possible d’oublier cette vérification ? → Parce qu’elle ne figurait ni dans une procédure ni dans une checklist, et reposait uniquement sur la mémoire
• Pourquoi cela reposait-il sur la mémoire ? → Parce que la procédure de livraison n’était pas documentée et était improvisée à chaque fois

Lorsque l’action d’une personne apparaît comme réponse, ce n’est pas un point d’arrivée, mais l’entrée vers la question suivante, celle qui interroge le système. En partant du principe que les humains commettront toujours des erreurs, la question à creuser passe de « pourquoi a-t-il commis l’erreur » à « pourquoi l’erreur a-t-elle atteint la production sans être interceptée ».

5.2 Sans preuves, l’analyse ne peut même pas commencer

La qualité d’une analyse des causes est plafonnée par la qualité des preuves conservées au moment de l’incident. Un postmortem incapable de reconstituer la chronologie devient un exercice de fiction spéculative. Pour la maintenance d’une application Windows, voici le dispositif minimal en trois volets.

• Les dumps de crash : en configurant WER LocalDumps, un dump reste disponible en cas d’arrêt anormal, sans que l’utilisateur ait à faire quoi que ce soit. La configuration est détaillée dans « Introduction à la collecte des dumps de crash Windows », et la manière de les lire dans « Lire les dumps de crash avec WinDbg + SOS ».
• Les journaux d’application : horodatage, identifiant corrélable et écriture synchrone des événements critiques. Consultez « Concevoir des applications Windows pour conserver logs et dumps en cas de crash » pour garantir que la journalisation survit à un crash.
• Le journal d’événements : même si votre propre journalisation venait à échouer, le journal d’événements standard de l’OS conserve tout de même une trace du crash de l’application (Application Error). Son exploitation est détaillée dans « Introduction au journal d’événements Windows et à ETW ».

Si, en rédigeant le postmortem, vous n’arrivez pas à remplir la chronologie, cette incapacité constitue elle-même un facteur contributif — « les mécanismes de détection et de journalisation sont insuffisants » — et un candidat pour une action de prévention de la récurrence.

6. La qualité des mesures de prévention de la récurrence — Un tableau de décision sur la solidité

Une fois les actions de prévention de la récurrence rédigées, évaluez leur solidité. L’axe d’évaluation est le degré de dépendance de la mesure à la vigilance humaine.

La règle réaliste ici n’est pas « interdire les mesures faibles » mais « ne pas s’arrêter à une mesure faible ». Sensibiliser a du sens comme réponse provisoire déployable le jour même, mais ce qui doit figurer dans le champ de la solution pérenne doit être au minimum de niveau moyen, et de niveau fort si possible.

Lorsque seules des mesures faibles viennent à l’esprit, réexaminez-les avec les questions suivantes.

• « Si une personne qui vient d’arriver était placée dans exactement la même situation, cet incident se produirait-il quand même ? » Si la réponse est oui, ce n’est pas encore un système.
• « Cette erreur peut-elle être détectée par le compilateur, un test ou la CI ? » Par exemple, si le problème était « nous avalions une exception à l’arrêt », la mesure forte n’est pas de sensibiliser, mais d’implémenter, comme gestionnaire d’exception commun de l’application, une politique du type de celle exposée dans « Un tableau de décision pour choisir entre quitter et continuer après une exception inattendue ».
• « Peut-on rendre l’erreur impossible à commettre ? Peut-on la faire remarquer rapidement ? » Si la prévention est coûteuse, se rabattre sur la détection (supervision, alertes, tâche de rapprochement) constitue aussi une mesure forte tout à fait légitime. Réinjecter les leçons d’un incident dans un renforcement de la détection et une amélioration de la conception est exactement la structure recommandée par les directives de Microsoft.²

Les mesures fortes demandant un réel effort, l’approche pragmatique consiste à inscrire à la fois « une mesure moyenne à réaliser cette semaine » et « une mesure forte à réaliser le mois prochain » dans la liste d’actions, et à gérer les deux par échéance.

7. Pour quels incidents en faire un — Trier la mise en œuvre

Imposer un postmortem complet pour chaque incident, et en trois mois plus personne n’en rédigera. Décidez du niveau d’effort selon l’impact multiplié par la probabilité de récurrence.

Il y a trois points clés pour appliquer cela.

• La récurrence d’un incident de même nature fait monter le niveau d’un cran, indépendamment de l’impact. Le simple fait qu’il se soit reproduit prouve que la mesure précédente n’était pas devenue un véritable système.
• Même pour quelque chose de mineur, laissez toujours au moins une trace. Un paragraphe suffit. Avec seulement quatre points — date, symptôme, cause, réponse — votre futur vous sera sauvé par une recherche des années plus tard. Une fois que suffisamment de traces d’incidents mineurs se sont accumulées, des déséquilibres structurels deviennent aussi visibles, comme « cet écran-là concentre à lui seul la plupart des incidents ».
• En cas de doute, penchez du côté de la rédaction, mais réduisez le volume. Si vous passez du temps à hésiter entre version complète ou non, vous irez plus vite en commençant simplement la version légère.

8. Le traitement en développement en sous-traitance — La relation avec le rapport d’incident destiné au client

En sous-traitance ou dans le cadre d’un contrat de maintenance, les clients demandent un « rapport d’incident » après un incident. Clarifier à l’avance la relation entre le postmortem et ce rapport évite de faire le travail deux fois.

Environ 80 % du contenu peut être réutilisé directement. Le résumé, l’impact, la chronologie, la cause directe et les mesures de prévention de la récurrence sont exactement les composants d’un rapport destiné au client. Rédigez d’abord le postmortem interne, puis éditez-le pour le client, et vous n’aurez jamais à rédiger de prose uniquement pour le rapport.

Cela dit, gardez à l’esprit qu’il s’agit de deux documents aux finalités différentes, et maintenez-les séparés.

La principale raison de les séparer est que mélanger la discussion sur la responsabilité/l’indemnisation avec celle sur la prévention de la récurrence dénature les deux. Dans un document mêlé à une question de responsabilité, toutes les personnes impliquées écrivent inévitablement de façon défensive. Les facteurs contributifs disparaissent d’un document défensif, et la prévention de la récurrence se dégrade en « nous serons vigilants ». À l’inverse, remettre tel quel au client un postmortem interne rédigé franchement peut faire que des passages privés de contexte prennent une vie propre. L’approche sûre consiste à séparer « le document interne, rédigé franchement » et « le document externe, communiqué avec précision », et à en faire un sens unique : construire le second à partir du premier.

Une dernière chose : une fois qu’une mesure de prévention de la récurrence planifiée est inscrite dans un rapport destiné au client, elle devient une promesse envers ce client. Gérez son échéance de la même manière que les actions du postmortem, et rendez compte une fois qu’elle est réalisée. Cet aller-retour est précisément ce qui transforme un incident en une véritable occasion de construire la confiance.

9. En résumé

• La gestion d’incident ne s’arrête pas au rétablissement. Traitez le rétablissement, l’investigation de la cause profonde et la prévention de la récurrence comme des tâches distinctes, et intégrez la rétrospective (le postmortem) à votre travail habituel.
• Le principe directeur du postmortem est le caractère blameless. Blâmer les personnes fait cesser la remontée d’informations, et on n’atteint jamais la cause profonde. N’arrêtez pas l’analyse à l’action d’une personne — creusez jusqu’à la faille du système (les facteurs contributifs).¹
• Un modèle minimal rédigeable en une heure — résumé, impact, chronologie, cause directe, facteurs contributifs, ce qui a bien fonctionné, et des actions avec responsable et échéance — suffit amplement. Comme préalable pour pouvoir remplir la chronologie, mettez en place à l’avance la préservation des preuves : dumps de crash, journaux et journal d’événements.
• Faites monter les mesures de prévention de la récurrence de « être vigilant » (faible) vers une procédure écrite (moyenne), et si possible jusqu’à une prévention mécanique par des tests, des assertions, une supervision ou un changement de conception (forte). Réinjecter les leçons dans la détection et la conception est une structure commune aux directives du SRE et de Microsoft.¹²
• N’appliquez pas le processus complet à chaque incident. Triez selon l’impact multiplié par la probabilité de récurrence, et même pour les incidents mineurs, laissez toujours au moins une trace d’un paragraphe.
• En développement en sous-traitance, rédigez d’abord le postmortem interne, puis éditez à partir de celui-ci le rapport d’incident destiné au client. Séparer le document de responsabilité/indemnisation du document de prévention de la récurrence protège la qualité des deux.

Articles connexes

• Introduction à la collecte des dumps de crash Windows - WER/ProcDump/WinDbg
• Lire les dumps de crash avec WinDbg + SOS — Guide pratique de l’analyse après collecte
• Concevoir des applications Windows pour conserver logs et dumps en cas de crash
• Introduction au journal d’événements Windows et à ETW — Mettre les journaux de votre application métier sur les mécanismes standard de l’OS
• Où placer le catch et la journalisation dans la gestion des exceptions ?
• Un tableau de décision pour choisir entre quitter et continuer après une exception inattendue

Domaines de conseil associés

Komura Software LLC prend en charge aussi bien l’investigation et le diagnostic de bugs difficiles à reproduire, la mise en place de mécanismes de préservation des preuves (journalisation et collecte de dumps), que l’organisation d’un dispositif de maintenance et d’exploitation incluant la prévention de la récurrence. Nous accueillons également les demandes dès le stade où « le même incident se reproduit sans cesse » ou « les mesures de prévention de la récurrence de nos rapports d’incident sont devenues de pures formalités ».

• Investigation de bugs et analyse de la cause profonde
• Modernisation et maintenance des logiciels Windows existants
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce qu'un postmortem ? En quoi diffère-t-il d'un rapport d'incident ?

Un postmortem est un document et une activité de rétrospective structurée menée après le rétablissement d'un incident — une technique établie dans le domaine du SRE (Site Reliability Engineering). Partant du principe d'être blameless (sans recherche de coupable), il consigne la chronologie, la cause directe, les facteurs contributifs et les actions de prévention de la récurrence. Alors qu'un rapport d'incident destiné au client est un document qui remplit une obligation de rendre compte — « ce qui s'est passé et comment on y a répondu » — le postmortem est un document interne destiné à décider « comment changer le système pour que cela ne se reproduise plus jamais ». Comme la majeure partie du contenu se recoupe, il est cependant efficace de rédiger d'abord le postmortem, puis d'en tirer un rapport destiné au client.

Mes mesures de prévention de la récurrence se résument toujours à « nous serons plus vigilants à l'avenir ». Que faire ?

« Être vigilant » ou « sensibiliser » dépendent de la mémoire humaine et de la bonne volonté, si bien que leur effet s'estompe inévitablement avec le temps et les changements de personnel. Lorsque vous élaborez une mesure, reposez-vous la question : « si une personne qui vient d'arriver était placée dans exactement la même situation, cet incident se produirait-il quand même ? » Si la réponse est oui, ce n'est pas encore un système. Une mesure forte est une mesure détectée ou empêchée mécaniquement, sans que personne n'ait à faire preuve de vigilance : un test, une assertion, une contrainte intégrée au typage ou à la conception, une alerte de supervision. Si vous ne pouvez pas mettre en place immédiatement une mesure forte, utilisez une checklist ou une procédure écrite comme étape intermédiaire, et consignez la solution pérenne comme une action assortie d'une échéance.

Nous sommes une petite équipe de développement en sous-traitance et n'avons pas les moyens de rédiger un postmortem pour chaque incident.

Il n'est pas nécessaire de rédiger un postmortem complet pour chaque incident, et si vous essayiez, la pratique elle-même ne survivrait pas. Triez le niveau d'effort à appliquer selon l'impact et la probabilité de récurrence : appliquez le processus complet pour les incidents entraînant un arrêt d'activité ou une corruption de données, ou lorsqu'un incident de même nature se reproduit, et pour les incidents mineurs, laissez simplement une entrée d'un paragraphe dans le registre des incidents. Ce qui compte, c'est de toujours laisser au moins une trace, même pour quelque chose de mineur — pouvoir retrouver une trace passée par une recherche lorsque le même phénomène se reproduit des années plus tard change radicalement la durée de l'investigation.

« Ne pas chercher de coupable » (être blameless), n'est-ce pas simplement une façon de laisser la responsabilité dans le flou ?

Non. Le principe blameless consiste à déplacer l'attention de « qui a commis l'erreur » vers « pourquoi le système a-t-il permis à cette personne de commettre cette erreur ». Si un opérateur a commis une erreur de manipulation, il existe un facteur contributif dans l'interface ou la procédure qui a rendu cette erreur possible. Dans une organisation qui punit les individus, l'information se cache lors de l'incident suivant, et l'on n'atteint jamais la cause profonde. La responsabilité envers le client — ce qui s'est passé et comment cela sera compensé — doit être traitée comme un document et un processus distincts, ce qui n'entre pas en contradiction avec une rétrospective blameless. Séparer le document de mise en cause de la responsabilité et le document de prévention de la récurrence est la clé, en pratique.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.