Blameless post-mortem : ce que je dois à John Allspaw et à l'équipe technique d'Etsy

Mercredi 1er avril 2026, 8h35, gare de Meaux. J’ai programmé un post LinkedIn à 8h30. Je dois coller un lien en commentaire. Je cherche l’URL sur mon blog tech.

Unreachable.

L’incident

8h37. La connexion est capricieuse à la gare, alors je fais comme tout le monde fait : je tape “test” dans DuckDuckGo. Des résultats s’affichent. Internet fonctionne. Pas mon site.

8h38. Je teste mes autres services. afk.live, mon news agrégateur et plateforme de veille — down. Mon journal littéraire sylvain.artois.me — down. Mon instance Bluesky — down. Personnal Global Outtage… Tout ce que j’héberge est tombé. Je ne suis pas Etsy, je fais dix connexions par jour sur mon blog tech et une centaine sur afk.live. La Terre ne va pas s’arrêter de tourner. Mais je viens de lancer kairos.ing, ma société de conseil. Ce n’est pas le moment.

8h39. Je contacte ma compagne. Au cœur de mon infrastructure, posé sur la cheminée du salon, il y a un vieux Linux auto-hébergé, volontairement coupé d’internet. Est-ce qu’il est up ? On télétravaille tous les deux, et je refuse d’ouvrir un accès distant sur cette machine — question de sécurité.

9h07. Réponse : le serveur domestique tourne. Le problème vient donc de mon instance Scaleway, celle qui sert les pages HTML pré-calculées de mes sites. Et là, je sais. Je sais exactement ce qui s’est passé, parce que j’ai déjà vécu cette panne. La semaine précédente. Mon VPS a redémarré dans la nuit — probablement une maintenance chez l’hébergeur — et ma stack Docker a redémarré sans l’argument --env-file. Sans ses variables d’environnement, le serveur web ne peut pas fonctionner.

9h20. J’arrive à Paris. Je me connecte au back-office Scaleway pour ajouter ma clé SSH sur mon Mac. Trente minutes perdues. Si la clé avait déjà été là, j’aurais pu tout relancer depuis le train.

9h30. Tout est up. Je poste mon commentaire sur LinkedIn. Temps total d’indisponibilité : environ deux heures. Temps de résolution effective : dix minutes.

Les questions

Tellement de questions. J’en retiens deux.

Pourquoi n’avais-je aucune sonde de monitoring sur mes services ? Une simple alerte m’aurait prévenu à 7h30, café en main, dans mon bureau. J’aurais résolu l’incident avant même qu’il n’ait de conséquences.

Pourquoi Docker n’était-il pas configuré pour redémarrer automatiquement avec la bonne configuration ? J’avais déjà rencontré cette panne. Je l’avais corrigée à la main. Je n’avais pas corrigé le système.

Les actions

Deux choses à faire aujourd’hui, pas demain :

Installer des sondes de monitoring sur les deux serveurs. Et être ingénieux : si Scaleway tombe, le serveur auto-hébergé ne pourra pas enregistrer son propre statut par les voies habituelles. Il faudra un mécanisme de supervision croisée.
Configurer Docker pour qu’il redémarre systématiquement avec le bon fichier d’environnement. Plus jamais de --env-file oublié.

Un lecteur attentif remarquera que ce petit récit suit un schéma précis. Une chronologie factuelle, sans jugement. Des questions ouvertes, orientées vers le système plutôt que vers la personne. Des actions concrètes, immédiates. Pas de coupable. Pas de “j’aurais dû”. Pas de honte.

Ce schéma, je ne l’ai pas inventé. Je l’ai appris.

Paris, 2014–2017

J’ai rejoint Etsy France en 2014. Pour ceux qui ne connaîtraient pas, Etsy est une marketplace américaine dédiée à l’artisanat et à la création. Mais derrière la vitrine chaleureuse des bijoux faits main et des carnets en cuir, il y avait une équipe d’ingénierie qui, à l’époque, était en train de redéfinir silencieusement la manière dont notre industrie pense les incidents, les erreurs et la responsabilité.

À la tête de cette révolution tranquille : John Allspaw, le CTO d’Etsy. Allspaw n’est pas un manager comme les autres. C’est un chercheur déguisé en ingénieur, un homme qui cite Sidney Dekker¹ et Erik Hollnagel² dans ses articles sur le blog technique d’Etsy, et qui avait la conviction — rare dans notre métier — que les pannes ne sont jamais la faute d’une seule personne.

En 2016, Allspaw est venu nous rendre visite à Paris. Je me souviens de cette journée avec une netteté particulière. Il y a des rencontres professionnelles qu’on oublie, et il y a celles qui déplacent quelque chose dans votre manière de penser, définitivement.

Il nous a parlé du blameless post-mortem.

Ce que “blameless” veut vraiment dire

Le terme est souvent mal compris. “Blameless” ne signifie pas que tout le monde s’en tire sans rendre de comptes. Ce n’est pas l’amnistie. Ce n’est pas l’indifférence.

C’est un pacte. Un pacte qui dit : si tu me racontes exactement ce que tu as fait, ce que tu as observé, ce que tu pensais qu’il allait se passer, et pourquoi ton action te semblait sensée à ce moment-là — alors je m’engage à ne pas te punir pour ça. Parce que ta punition me coûterait bien plus cher que ton erreur.

Allspaw appelait ça une Just Culture — une culture juste. L’idée est limpide : un ingénieur qui craint la sanction ne donnera jamais les détails nécessaires à la compréhension réelle d’une panne. Il minimisera, il arrondira les angles, il fera du Cover-Your-Ass engineering. Et sans ces détails, on ne comprend pas ce qui s’est passé. Et ce qu’on ne comprend pas, on le revit.

Allspaw décrivait le cycle toxique avec une précision chirurgicale : un ingénieur commet une erreur, on le punit, la confiance s’érode entre le terrain et le management, les ingénieurs se taisent, le management perd la visibilité sur la réalité du travail quotidien, les conditions latentes d’échec s’accumulent dans l’ombre, et la prochaine panne arrive. Plus violente. Moins comprise.

La “Second Story”

Ce qui m’a le plus marqué dans l’approche d’Allspaw, c’est le concept de Second Story — la seconde histoire. Quand un incident survient, il y a toujours une première histoire, celle qui saute aux yeux : “l’ingénieur n’a pas fait attention”, “il n’a pas suivi la procédure”, “il a déployé sans vérifier”. C’est rassurant, une première histoire. Ça donne un coupable, une cause simple, et l’illusion qu’il suffit de dire aux gens d’être plus prudents pour que le problème disparaisse.

La seconde histoire est plus riche, plus inconfortable, et infiniment plus utile. Elle demande : pourquoi l’action de cet ingénieur lui semblait-elle raisonnable au moment où il l’a prise ? Quel était son contexte ? Quelles informations avait-il ? Quelles informations lui manquaient ? Qu’est-ce que le système — l’outillage, les interfaces, la culture, la pression — a rendu possible, voire probable ?

Allspaw citait Erik Hollnagel : “Les accidents n’arrivent pas parce que les gens jouent et perdent. Ils arrivent parce que la personne croit que ce qui va se passer est impossible, ou sans lien avec ce qu’elle fait, ou que le résultat espéré vaut largement le risque.”

Dans le guide de facilitation qu’Etsy a publié en open source en 2016³, il y a un exemple qui ne m’a jamais quitté. Un ingénieur déploie du code, provoque une panne. En réunion de post-mortem, il baisse la tête : “I just wasn’t paying attention, I guess. This is on me.” L’équipe est soulagée. On a notre coupable. On peut remplir le formulaire et passer à autre chose.

Mais le facilitateur ne lâche pas. Il demande à l’ingénieur de revenir en arrière, de décrire ses gestes, de montrer son écran. Et là, on découvre qu’un tableau de bord récemment redessiné affiche le chiffre 8 dans une police italique avec des zéros barrés — et que ce 8 ressemble à s’y méprendre à un 0. La moitié de la salle avait lu zéro, elle aussi. Le problème n’était pas l’inattention d’un homme. C’était un choix typographique dans une interface.

Sans les bonnes questions, on n’aurait jamais trouvé. On aurait dit à Phil de “faire plus attention la prochaine fois”. Et quelqu’un d’autre, un mois plus tard, aurait lu le même zéro.

Le facilitateur

Ce que j’ai aussi appris à Etsy, c’est que le blameless post-mortem ne fonctionne pas tout seul. Il faut un facilitateur. Quelqu’un dont le rôle n’est pas de juger, ni même de résoudre, mais de faire parler. De rassembler les perspectives multiples. De résister à la tentation de la cause unique. De poser les questions que personne ne pose parce qu’elles semblent naïves, ou parce que la réponse fait peur.

Todd Conklin, que citait souvent l’équipe d’Allspaw, l’exprime mieux que quiconque : “The skill is not in knowing the right answer. Right answers are pretty easy. The skill is in asking the right question. The question is everything.”

La compétence n’est pas dans la bonne réponse. Les bonnes réponses, c’est facile. La compétence, c’est la bonne question.

Ce que je leur dois

Je pourrais raconter mon incident du 1er avril comme une histoire simple : j’ai oublié de configurer Docker correctement, j’ai été négligent, j’ai perdu deux heures, c’est ma faute. Première histoire. Elle tient en une ligne. Et elle ne m’apprend rien.

La seconde histoire est plus intéressante. Pourquoi n’avais-je pas de monitoring ? Parce que je suis solo, que mon infrastructure a grandi par couches successives, et que la supervision est le genre de chose qu’on repousse quand on n’a pas d’astreinte ni de collègue pour vous rappeler que c’est important. Pourquoi Docker n’avait-il pas la bonne configuration de redémarrage ? Parce que j’avais résolu le symptôme la première fois sans toucher à la cause, pressé par autre chose — un backlog, une urgence du jour. La rustine avait tenu dix jours.

Je suis seul sur cette infrastructure, je n’ai pas de facilitateur, pas de salle de réunion, pas d’équipe à rassembler. Et pourtant, le réflexe est là. Chronologie factuelle. Questions ouvertes sur le système. Actions concrètes. Pas de coupable — même quand le coupable, c’est moi.

Ce réflexe, je le dois aux trois années passées avec l’équipe technique d’Etsy France, entre 2014 et 2017. Je le dois à John Allspaw, bien sûr, mais aussi à tous les cadres techniques qui portaient cette culture au quotidien, dans les stand-ups, dans les revues de code, les architecture review, dans les conversations de couloir. Des gens qui avaient compris que la sécurité d’un système ne se construit pas dans la peur, mais dans la confiance.

Les organisations, les groupes humains, cherchent des coupables. Des boucs émissaires⁴. Je l’ai constaté tout au long de ma carrière. “C’est la faute du dev qui vient de démissionner” — les absents ont toujours tort. Pire : “C’est la faute de l’alternant, un peu weirdo, il n’a pas suivi la procédure.” Les plus fragiles paient pour tout le monde.

Parfois on est dans des univers très bienveillants, et on n’arrive pas davantage à se dire les choses. Par peur de blesser ? Mais c’est justement ça, le “blameless” : c’est un cadre pour que les équipes bienveillantes n’aient pas de crainte à creuser les incidents complexes et remonter aux causes racines — toujours complexes, toujours multifactorielles.

Parfois on est dans une start-up qui lutte pour sa survie, et on pose une rustine pour revenir au backlog et aux urgences du jour. La rustine tiendra dix jours.

On se doit de faire des blameless post-mortems. Non pas parce que c’est à la mode, ou parce qu’un article de blog nous y a invités. Mais parce que c’est la seule manière honnête de faire progresser nos organisations. De transformer chaque panne en leçon plutôt qu’en procès. De regarder nos systèmes — techniques et humains — avec assez de courage pour y voir ce qui ne fonctionne pas, sans détourner le regard vers le premier coupable venu.

C’est ce que j’ai appris chez Etsy. C’est ce que je n’oublierai pas.

Sidney Dekker est un chercheur suédois en facteurs humains et sécurité des systèmes complexes. Son ouvrage The Field Guide to Understanding ‘Human Error’ (2014) a profondément influencé la manière dont l’industrie logicielle pense les incidents. C’est lui qui a formalisé la distinction entre first story et second story — et la critique de ce qu’il appelle la “Bad Apple Theory”, l’idée qu’il suffirait d’éliminer les mauvais éléments pour éliminer les erreurs. ↩
Erik Hollnagel est un chercheur danois, pionnier de l’ingénierie de la résilience. Là où l’approche traditionnelle de la sécurité consiste à cataloguer ce qui va mal, Hollnagel propose d’étudier ce qui va bien — comment les humains s’adaptent, compensent, et maintiennent les systèmes en fonctionnement malgré leur complexité. Allspaw le cite abondamment dans son article fondateur, Blameless PostMortems and a Just Culture (2012) : “Les accidents n’arrivent pas parce que les gens jouent et perdent.” ↩
Etsy’s Debriefing Facilitation Guide for Blameless Postmortems (2016). Allspaw y détaille la pratique concrète du post-mortem : le rôle du facilitateur, l’art de poser les bonnes questions, et pourquoi un debriefing doit être d’abord une occasion d’apprendre, pas de corriger. Le guide complet est disponible en open source sur GitHub. ↩
Voir René Girard, La violence et le sacré (1972). Le bouc émissaire est un réflexe fondamental des groupes humains : désigner une victime unique pour éviter de questionner les structures collectives. Girard voit dans les évangiles le premier récit qui prend le parti de la victime plutôt que celui de la foule. C’est précisément cette bienveillance envers la victime qui sous-tend le blameless : refuser de sacrifier un individu pour préserver le confort du groupe, et avoir le courage d’examiner le système plutôt que de chercher un coupable. ↩