« Blameless » dans un postmortem d’incident est souvent interprété comme « aucune conséquence pour personne », une lecture qui décourage justement l’objectif recherché : un postmortem sans reproche individuel encourage les personnes impliquées à décrire honnêtement ce qui s’est passé, y compris leurs propres erreurs, plutôt que de minimiser leur rôle par crainte de sanction.
Ce que « blameless » signifie réellement
Un postmortem blameless sépare deux activités distinctes : la reconstitution factuelle de la chronologie d’un incident (qui a fait quoi, dans quel ordre, avec quelles informations disponibles à ce moment précis), et l’évaluation de la performance individuelle, qui reste un sujet de management, jamais du document de postmortem lui-même. Ces deux activités continuent d’exister toutes les deux, simplement dans des canaux séparés.
Le piège le plus fréquent : nommer une personne dans le récit
Un postmortem qui écrit « Jean a supprimé la mauvaise base de données » plutôt que « une commande de suppression a été exécutée contre l’environnement de production au lieu de l’environnement de test » casse la confiance nécessaire pour que la prochaine personne dans la même situation décrive honnêtement son propre rôle. La reformulation autour de l’action et du contexte système (pourquoi cette confusion entre environnements était possible en premier lieu) plutôt qu’autour de la personne est ce qui distingue un postmortem blameless d’un simple compte-rendu poli qui blâme quand même implicitement.
Ce que ça n’élimine pas : les conséquences réelles
Un postmortem blameless n’empêche en rien qu’une conversation de performance ait lieu séparément, si le comportement en question relève réellement d’un problème individuel (négligence répétée, contournement délibéré d’un processus de sécurité) plutôt que d’un système qui rendait l’erreur facile à commettre pour n’importe qui à sa place. La distinction entre les deux n’est pas toujours évidente, mais la question à se poser reste constante : une personne différente, dans exactement le même contexte, aurait-elle pu commettre la même erreur ?
Pourquoi ça sert la fiabilité, pas juste le confort
Un incident dont la cause réelle reste cachée (parce que la personne impliquée a minimisé son rôle par crainte de représailles) empêche de corriger le vrai problème systémique, laissant la même classe d’erreur se reproduire indéfiniment. Cette logique rejoint directement celle des expériences de chaos engineering : provoquer volontairement une défaillance en environnement contrôlé n’a de valeur que si l’équipe documente honnêtement ce qui a réellement cassé, sans filtre défensif.
À retenir
« Blameless » ne signifie pas l’absence de conséquences, mais la séparation entre la reconstitution factuelle d’un incident (dans le document de postmortem) et l’évaluation individuelle (dans un canal de management séparé). Nommer une personne dans le récit des faits plutôt que de décrire l’action et le contexte système casse la confiance nécessaire à l’honnêteté du prochain rapport. Cette culture sert directement la fiabilité : un incident dont la cause réelle reste cachée par crainte de représailles laisse la même classe d’erreur se reproduire, un risque bien plus coûteux à long terme que l’inconfort d’une reformulation honnête.