Post-mortem incident, format blameless

---
name: rca-post-mortem-blameless
description: "Rédige un post-mortem structuré et blameless après un incident production : résumé exécutif, timeline UTC, root cause, impact chiffré, actions correctives avec owner et deadline. À utiliser quand un dev, un SRE ou un tech lead doit produire un RCA partageable à l'équipe et à la direction sans pointer du doigt une personne, en se concentrant sur les causes systémiques et les actions de remédiation."
metadata:
  iaskills_title: "Post-mortem incident, format blameless"
  metier_slug: dev
  metiers:
    - Dev
  secteur: "Tech & DSI"
  tier: free
  compatible:
    - claude-code
    - cowork
    - cursor
    - codex
  version: "1.0.0"
  author: "iaskills"
  editorial:
    pitch: "Transforme une nuit blanche en post-mortem clair, factuel et actionnable. Timeline UTC, root cause, actions correctives avec owner et deadline. Sans blâme, sans verbiage."
    long_description: "Après un incident production, le post-mortem est souvent rédigé à chaud, dans la fatigue, avec un mélange d'émotions et de raccourcis. Résultat : un document confus, qui pointe une personne, sans actions concrètes. Ce skill produit un RCA blameless qui répond aux questions de l'équipe et du management : que s'est-il passé, pourquoi, qui a été impacté, qu'est-ce qu'on fait pour que ça ne se reproduise pas. Format calé sur les standards Google SRE et Etsy : timeline UTC, contributing factors, action items typés. Le skill rejette systématiquement le langage qui blâme une personne et reformule en termes systémiques (process manquant, alerte absente, doc périmée)."
    bullets:
      - "Résumé exécutif en 2 phrases lisibles par un non-tech"
      - "Timeline UTC avec horodatage précis des événements"
      - "Root cause distinguée des causes contributives"
      - "Impact chiffré : utilisateurs, revenu, durée"
      - "Actions correctives avec owner et deadline"
      - "Reformulation systématique du blâme en cause systémique"
    exemple_avant: "Note Slack collée dans Notion à 3h du matin : Le déploiement de Marc a cassé le checkout. On a rollback. Désolé. À traiter en sprint plan. Le management lit ça le lendemain et n'a aucune idée de la durée de l'incident, du nombre de clients touchés, ni de ce qu'on va faire pour éviter le prochain."
    exemple_apres: "Post-mortem 4 pages structuré : résumé exécutif (incident 47 min, 1 240 transactions impactées, ~8 200€ de revenu en attente), timeline UTC minute par minute, root cause (migration DB lancée sans review du plan d'exécution), 5 actions correctives typées prévention/détection/atténuation avec owner et deadline trackées dans Linear."
    recommended_metiers:
      - dirigeant-pme
    secteurs:
      - tech-dsi
      - startup-vc
      - assurance-banque
      - tourisme-hotellerie
      - marketing-commerce
      - secteur-public-associatif
    metiers_individuels:
      - dev-backend
      - dev-frontend
      - devops
      - cto
      - architecte-si
      - chef-de-projet-it
      - dsi
      - rssi-cybersecurite
      - mlops
    connecteurs:
      - notion
      - slack
---

# Post-mortem incident, format blameless

## Quand utiliser ce skill

Déclencher quand un dev, un SRE, un tech lead, un CTO ou un DSI doit rédiger un RCA après un incident production : panne, dégradation, leak de données, déploiement raté, rollback en urgence, escalade externe d'un client mécontent. Le skill structure un document partageable à l'équipe interne, à la direction et, si pertinent, à un client final affecté.

Ne pas utiliser pour un bug isolé sans impact production, pour une analyse de performance non liée à un incident, ou pour pointer la responsabilité d'une personne précise.

## Ce que tu dois faire

1. Demander à l'utilisateur les éléments factuels de base : date et heure de début et fin de l'incident en UTC, services impactés, sévérité (P0, P1, P2), équipe d'astreinte concernée.
2. Récupérer la timeline brute : commits déployés, alertes Datadog, Sentry, Logtail, échanges Slack pertinents, actions de remédiation prises et leur horodatage.
3. Identifier la root cause en distinguant la cause technique immédiate (commit, requête, config) des causes contributives (process, monitoring, documentation, charge cognitive de l'équipe).
4. Quantifier l'impact en valeurs lisibles : nombre d'utilisateurs touchés, revenu en attente ou perdu, durée totale, SLA cassé ou non.
5. Lister les actions correctives en les typant : prévention (empêcher la cause), détection (réduire le temps de détection), atténuation (réduire l'impact si ça se reproduit). Chaque action a un owner identifié et une deadline.
6. Reformuler systématiquement les phrases qui blâment une personne. Si l'utilisateur écrit `Marc a poussé sans tester`, transformer en `Le process de revue ne bloque pas les déploiements sans tests passants`.
7. Renvoyer le post-mortem complet en Markdown, prêt à coller dans Notion ou un Google Doc.