postmortem

Présentation du skill postmortem

Ce que fait le skill postmortem

Le skill postmortem est un workflow de mentorat exécutif qui aide à transformer un lancement raté, un objectif manqué, un mauvais recrutement, une vente perdue ou une défaillance opérationnelle en analyse des causes racines, sans recherche de coupable. Il guide l’agent dans la définition précise de l’événement, un questionnement rigoureux selon la méthode des 5 pourquoi, puis la création d’un registre de changements, afin que le résultat ne se limite pas à des « enseignements », mais débouche sur des évolutions concrètes du système.

Idéal pour le leadership et le Quality Management

Ce postmortem skill est particulièrement utile aux fondateurs, dirigeants, responsables opérationnels, leaders produit, engineering managers et équipes de Quality Management qui doivent comprendre pourquoi un résultat s’est écarté du plan. Il convient aux situations où l’objectif est la prévention et l’amélioration des processus, pas la sanction. Pour les cas d’usage postmortem for Quality Management, sa valeur principale consiste à traduire les échecs en contrôles, responsables identifiés et actions de suivi mesurables.

Ce qui le distingue d’un prompt générique

Un prompt générique du type « analyse ce qui s’est mal passé » produit souvent des commentaires très larges. Ce skill est plus ciblé et plus opérationnel : il pousse à définir clairement l’événement, distingue les symptômes des causes, décourage la recherche de boucs émissaires et interroge les conditions qui ont rendu l’échec probable. Son principal différenciateur est le registre de changements, qui aide à convertir les enseignements en responsabilités, échéances et corrections au niveau du système.

Points importants avant adoption

Le chemin du dépôt contient un seul fichier SKILL.md, sans scripts d’assistance, références ni fichiers de métadonnées. L’installation de postmortem est donc légère, mais le skill dépend fortement de la qualité du contexte fourni. Utilisez-le lorsque vous pouvez partager suffisamment d’éléments factuels pour nourrir une rétrospective sérieuse ; évitez-le si l’événement reste politiquement risqué, juridiquement sensible ou fondé uniquement sur des rumeurs.

Comment utiliser le skill postmortem

Installation de postmortem et fichiers à examiner

Installez-le depuis la source GitHub du skill avec :

npx skills add alirezarezvani/claude-skills --skill postmortem

La source se trouve ici :

c-level-advisor/executive-mentor/skills/postmortem/SKILL.md

Lisez d’abord SKILL.md, car il contient le modèle de fonctionnement complet. Il n’y a pas de dossiers supplémentaires rules/, resources/, references/ ou scripts/ à rapprocher, donc votre principale décision d’installation consiste à vérifier si ce workflow mono-fichier correspond à votre façon de mener les rétrospectives.

Comment appeler le skill en pratique

Le skill est conçu autour du schéma de commande suivant :

/em:postmortem <event>

Une invocation faible serait :

/em:postmortem Q3 release slipped

Une invocation plus solide donne à l’agent assez de matière pour distinguer les faits, les hypothèses et les causes :

/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.

Entrées qui améliorent l’usage de postmortem

Pour tirer le meilleur parti de postmortem, fournissez le résultat attendu, le résultat réel, la chronologie, les premiers signaux d’alerte, l’impact, les décisions clés, les contraintes et ce qui était connu à ce moment-là. Ajoutez à la fois des preuves quantitatives et du contexte humain : écart de chiffre d’affaires, nombre de défauts, calendrier de recrutement, jalon manqué, impact client, responsables de décision, goulots d’étranglement dans les validations et priorités concurrentes.

Évitez de demander au skill de « trouver qui a causé cela ». Demandez-lui plutôt d’identifier les conditions systémiques : responsabilité floue, chemins d’escalade faibles, hypothèses de planification irréalistes, contrôles qualité manquants, conflits d’incitation ou visibilité trop tardive des risques.

Workflow conseillé pour obtenir un résultat utile

Commencez par une note factuelle sur l’événement, puis demandez une première version du postmortem. Vérifiez si la chaîne des 5 pourquoi s’arrête trop tôt ou saute vers une explication commode. Itérez ensuite avec des éléments probants : « Pressure-test the root cause against the timeline », « Separate controllable causes from external shocks » ou « Convert these lessons into a change register suitable for the next exec review ».

Le meilleur livrable final inclut généralement : définition de l’événement, synthèse de l’impact, facteurs contributifs, causes racines, non-causes, décisions qui semblaient raisonnables à l’époque, changements systémiques recommandés, responsables, échéances et métriques de vérification.

FAQ du skill postmortem

postmortem convient-il aux débutants ?

Oui, si l’utilisateur peut fournir une description claire de l’événement. La structure du skill réduit le besoin de maîtriser à l’avance les méthodes formelles de rétrospective. Les débutants devraient préparer une courte chronologie et l’écart entre résultat attendu et résultat obtenu avant de l’appeler ; sinon, le modèle risque de combler les manques de contexte par des hypothèses plausibles mais non vérifiées.

Quand ne faut-il pas utiliser ce skill ?

Ne l’utilisez pas comme entretien de performance, outil disciplinaire, enquête juridique ou déclaration publique d’incident sans revue humaine. Il est aussi mal adapté lorsque la direction veut seulement un récit bien présenté plutôt qu’une analyse causale inconfortable. Si l’organisation ne peut pas agir sur les conclusions, un postmortem risque de créer de la frustration plutôt que de l’amélioration.

En quoi diffère-t-il d’une revue d’incident ?

Une revue d’incident se concentre souvent sur les défaillances de services techniques et la reprise opérationnelle. Ce postmortem skill est plus large : trimestres manqués, lancements ratés, mauvais recrutements, ventes perdues, échecs produit et décisions de leadership entrent tous dans son périmètre. Il peut soutenir le Quality Management, mais il ne remplace pas une documentation CAPA, d’audit ou de conformité réglementée, sauf adaptation par des relecteurs qualifiés.

Le skill impose-t-il un écosystème particulier ?

Non. Le skill est en markdown simple et peut être installé dans un workflow de skills compatible avec la commande ci-dessus. Comme il ne contient ni scripts ni ressources externes, il est portable entre des contextes business, produit, engineering et opérations. La contrepartie est qu’il n’ingère pas automatiquement les dashboards, systèmes de tickets ou journaux d’incidents ; vous devez résumer ou coller les éléments de preuve pertinents.

Comment améliorer le skill postmortem

Fournir de meilleures données brutes au postmortem

Le moyen le plus rapide d’améliorer les résultats de postmortem consiste à fournir un dossier de preuves compact. Incluez : objectif, résultat réel, chronologie, points de décision, signaux manqués, contraintes, parties prenantes, impact et hypothèses existantes. Signalez clairement les affirmations incertaines. Par exemple : « Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope. »

Surveiller les modes d’échec fréquents

L’échec le plus courant est une cause racine superficielle comme « mauvaise communication » ou « manque de responsabilité ». Demandez à l’agent de descendre d’un niveau : quelle structure a fait échouer la communication ? Pourquoi la responsabilité était-elle floue ? Pourquoi le processus de planification a-t-il permis cette ambiguïté ? Un autre mode d’échec consiste à surcorriger avec trop d’actions. Poussez plutôt vers un nombre réduit de changements, attribués, observables et susceptibles d’éviter une récurrence.

Transformer les conclusions en registre de changements

Un bon registre de changements doit nommer le changement, la cause racine qu’il traite, le responsable, l’échéance, l’indicateur de succès et la cadence de revue. Pour un usage Quality Management, ajoutez le type de contrôle, la méthode de vérification et les preuves requises. Cela rend la sortie du skill plus facile à opérationnaliser dans les revues de direction, la planification trimestrielle, la gouvernance des releases, les changements de processus de recrutement ou les programmes d’amélioration continue.

Itérer après la première réponse

Après la première version, posez des questions ciblées : « Which conclusions are evidence-backed versus inferred? », « What would have prevented this without slowing the team unnecessarily? », « What early warning metric should we add? » ou « Rewrite the change register for executive accountability. » Le skill postmortem fonctionne au mieux lorsqu’il est traité comme un partenaire d’enquête structurée, et non comme un générateur de rapport en une seule passe.