Post-mortem blameless : quand votre franchise se retourne contre vous

La culture Site Reliability Engineering a popularisé une pratique vertueuse : le post-mortem sans blâme (blameless). L'idée, héritée de Google, est simple. Après un incident majeur, on rédige un compte rendu factuel qui se concentre sur les causes systémiques (un timeout mal configuré, une alerte absente, un runbook obsolète) plutôt que sur la faute d'une personne. Le but est d'encourager la transparence : un ingénieur qui sait qu'il ne sera pas puni racontera ce qui s'est réellement passé. Cette honnêteté nourrit ensuite les actions correctives qui empêchent l'incident de se reproduire.

Cette approche est excellente pour la fiabilité à long terme. Mais elle crée un paradoxe juridique rarement anticipé : pour ne blâmer personne, le post-mortem décrit avec une précision chirurgicale tout ce qui a dysfonctionné. Timeline minute par minute, décisions prises, configuration fautive, délai de détection, durée du downtime, ampleur de l'impact utilisateur. C'est un document d'une honnêteté redoutable, dont la valeur d'ingénierie repose précisément sur le fait qu'il ne masque rien.

Or, lorsque vous opérez en tant qu'ingénieur SRE indépendant ou prestataire pour une scale-up, ce document ne reste pas dans le périmètre protégé de votre équipe. Il circule : on le partage avec le management du client, on l'attache à un ticket, on l'évoque dans un comité de pilotage. Et dans certains cas, il devient une pièce à charge. Ce que vous avez écrit pour progresser peut être relu, des mois plus tard, par un avocat dont l'unique objectif est d'établir votre faute.

Imaginez le scénario suivant. Vous opérez la plateforme d'un e-commerçant sous contrat de prestation avec un SLA de 99,95 %. Un incident provoque six heures d'indisponibilité du tunnel de paiement un samedi de soldes. Vous rédigez, en bon professionnel, un post-mortem blameless impeccable qui établit que l'incident a été causé par une règle d'autoscaling mal calibrée que vous aviez déployée.

Le client, qui a perdu un chiffre d'affaires considérable, vous réclame une indemnisation. Son avocat demande, lors de la phase contentieuse, la communication des documents techniques. Votre post-mortem y figure. Il y lit, écrit noir sur blanc et signé de votre main : cause racine : configuration d'autoscaling erronée déployée le [date] par l'équipe SRE.

Le blameless protège l'humain en interne. Il n'efface jamais la responsabilité contractuelle du prestataire envers son client.

Le document que vous avez rédigé pour apprendre devient l'argument central de votre adversaire. Vous avez documenté votre propre faute professionnelle avec la rigueur qui fait votre métier. C'est précisément là que la distinction entre responsabilité morale interne et responsabilité juridique externe devient cruciale.

En droit français, le prestataire de services informatiques est tenu d'une obligation de moyens renforcée, voire d'une obligation de résultat lorsque le contrat stipule un niveau de service chiffré (un SLA). L'article 1231-1 du Code civil prévoit que le débiteur est condamné au paiement de dommages et intérêts en cas d'inexécution ou de retard, sauf à prouver une cause étrangère.

Concrètement, si votre contrat garantit 99,95 % de disponibilité et que votre erreur d'automatisation cause un dépassement, le client n'a pas grand-chose à prouver : le manquement est objectif. Et votre post-mortem en apporte la démonstration technique complète. Le préjudice indemnisable peut couvrir :

• les pénalités de retard prévues au contrat ;
• le chiffre d'affaires perdu pendant l'indisponibilité ;
• parfois les conséquences en cascade (clients finaux mécontents, atteinte à la réputation).

Ce sont des préjudices immatériels, souvent les plus lourds dans les métiers du numérique, et ceux que votre patrimoine personnel ne peut pas absorber.

Un point mérite une attention particulière : la charge de la preuve. Dans une obligation de moyens classique, c'est au client de prouver votre faute, ce qui n'est pas toujours évident face à des systèmes complexes. Mais dès lors que le contrat fixe un seuil de disponibilité chiffré, le débat se simplifie radicalement. Le client n'a qu'à constater le dépassement du seuil ; à vous de démontrer une cause exonératoire (force majeure, fait d'un tiers, faute du client lui-même). Et c'est précisément là que votre post-mortem, en attribuant la cause racine à votre propre configuration, ferme la porte à toute exonération. Vous avez vous-même écarté l'hypothèse de la cause étrangère.

Autrement dit, le document que vous destiniez à l'amélioration continue devient, dans le débat probatoire, l'aveu qui prive votre défense de son meilleur argument. Ce n'est pas une raison pour mal documenter, c'est une raison pour bien s'assurer.

La bonne nouvelle : il n'y a aucune raison d'abandonner le post-mortem blameless, qui reste une excellente pratique d'ingénierie. Il faut simplement dissocier deux logiques.

1. Distinguer le document d'apprentissage du document contractuel

Le post-mortem technique interne sert à améliorer la fiabilité. La communication contractuelle au client (constat d'incident, déclenchement des clauses SLA) doit être rédigée séparément, avec prudence et idéalement après avis juridique. Ne transmettez pas spontanément votre post-mortem brut au client.

2. Cadrer la responsabilité dans le contrat

Négociez des clauses limitatives de responsabilité, plafonnez les pénalités, excluez les dommages indirects. Un SLA bien rédigé borne le risque que le post-mortem pourrait sinon laisser ouvert.

3. Transférer le risque financier à un assureur

C'est là que l'assurance RC Pro joue son rôle décisif. Elle prend en charge l'indemnisation du préjudice immatériel subi par le client et vos frais de défense si le litige se judiciarise. Votre post-mortem peut établir la faute : peu importe, c'est l'assureur qui paie la facture, pas vous. Pour les ingénieurs SRE, c'est la différence entre un incident absorbé sereinement et une faillite personnelle.

Vis-à-vis de votre propre assureur RC Pro, le post-mortem change radicalement de nature : il devient un atout. Un compte rendu rigoureux qui démontre que vous avez détecté, diagnostiqué et corrigé l'incident selon les règles de l'art prouve votre professionnalisme. Il facilite l'instruction du dossier et accélère l'indemnisation, car l'assureur dispose d'emblée d'une chronologie claire et d'une cause racine établie.

C'est même un renversement intéressant. Le document qui peut vous fragiliser face à un client adverse vous renforce face à votre assureur, parce qu'il prouve que vous n'avez rien dissimulé et que vous avez agi avec diligence. Un sinistre bien documenté est un sinistre que l'assureur instruit vite et défend bien.

La discipline du post-mortem rejoint ici celle de la gestion de sinistre : documenter, dater, conserver. Les ingénieurs SRE ont déjà ce réflexe dans l'ADN. La seule chose à ajouter, c'est de comprendre quand un document doit rester interne et quand il peut sortir. Découvrez le détail des métiers couverts sur notre page dédiée à votre activité : assurance pour ingénieur SRE.

Le blameless protège votre culture. La RC Pro protège votre patrimoine. Les deux sont complémentaires, jamais substituables. L'un vous rend meilleur ingénieur, l'autre vous garde solvable le jour où, malgré tout votre talent, un incident dérape.