## Pourquoi c'est important

Résoudre une vulnérabilité boucle la boucle avec le chercheur, mais cela ne répond pas à la question que votre auditeur (et votre propre équipe) posera ensuite : *pourquoi est-ce arrivé, et qu'avons-nous changé pour que cela ne puisse pas se reproduire ?* Un post-mortem est cette réponse, consignée une fois et conservée pour le registre.

Chaque rapport reçoit **un seul** post-mortem — une analyse des causes profondes privée et structurée, entièrement détenue par votre équipe.

> [!IMPORTANT]
> Un post-mortem est **strictement interne**. Il n'est jamais montré au chercheur externe et n'est jamais inclus dans un [partage avec des pairs](/docs/sharing-reports-with-peers). Écrivez avec franchise sur les systèmes, les erreurs et les personnes — rien de tout cela ne quitte votre équipe.

## Ce qu'il contient

Un post-mortem associe des champs structurés à trois sections narratives en texte libre :

| Champ | Ce qu'il consigne |
|-------|-------------------|
| Résumé | Description en une ligne de l'incident |
| Sévérité | Le niveau de sévérité de l'incident |
| Catégorie | La classe de cause profonde (par ex. configuration, défaut de code, lacune de processus) |
| Survenu / Détecté / Résolu | Horodatages du moment où le problème a commencé, a été détecté et a été corrigé |
| Temps de résolution | Calculé automatiquement à partir des horodatages de survenue et de résolution |
| Cause profonde | Ce qui n'a réellement pas fonctionné, sous le symptôme |
| Actions correctives | Ce que vous avez changé (ou changerez) pour éviter que cela ne se reproduise |
| Enseignements tirés | Ce que l'équipe en retient — processus, outillage, responsabilités |

Vous pouvez aussi attacher des **fichiers de preuve** — captures d'écran, journaux, liens vers le commit ou le ticket de correction.

Lorsque vous ouvrez un nouveau post-mortem, Kit le **préremplit** à partir du rapport : la sévérité, la chronologie de résolution et un résumé de départ sont renseignés pour vous, afin que vous partiez du contexte plutôt que d'une page blanche.

## Qui peut rédiger

Tout membre de votre équipe CSIRT peut créer ou modifier le post-mortem d'un rapport — il n'y a pas de restriction d'administrateur distincte. Il est disponible partout où la gestion des rapports CSIRT l'est, de sorte que tout programme actif avec accès aux rapports peut l'utiliser.

## L'onglet Post-mortem

Ouvrez un rapport et sélectionnez l'onglet **Post-mortem**. Si aucun n'existe encore, un état vide encadré d'un cadenas vous invite à rédiger le premier. La création et la modification se font sur des formulaires dédiés en pleine page, pour vous laisser de la place pour écrire.

## La piste d'audit

Chaque enregistrement écrit une **révision immuable et attribuée** — qui a changé quoi, et quand. Les révisions ne sont jamais écrasées ni supprimées, de sorte que le post-mortem porte son propre historique des modifications. Chaque révision apparaît également dans la **chronologie** du rapport, aux côtés des transitions de statut et des évaluations, ce qui vous donne un registre chronologique unique de l'ensemble de l'incident.

## Le dossier PDF

Depuis l'onglet Post-mortem, vous pouvez télécharger un **dossier PDF par rapport** — le rapport complet *et* son post-mortem dans un seul fichier. C'est votre artefact de preuve à un instant donné : déposez-le dans un dossier d'audit, joignez-le à un ticket, ou remettez-le à un auditeur comme registre complet d'un incident unique.

## Conformité

Une analyse des causes profondes par rapport correspond exactement à ce que plusieurs référentiels exigent :

- **SOC 2** — satisfait le test de preuve Vanta *« Rapport d'incident ou analyse des causes profondes »*. Voir [Intégration Vanta](/docs/vanta-integration).
- **ISO 22301:2019** — répond aux exigences de continuité d'activité des §10.1.1, §10.1.2 et §10.1.3 (non-conformité, action corrective et amélioration continue).

> [!NOTE]
> Le contenu des post-mortems reste dans Kit. Le dossier PDF est généré à la demande pour vos archives — rien dans le post-mortem n'est transmis à Vanta ni à aucun autre système connecté.

## Gérer avec l'IA

Deux outils MCP permettent à un assistant IA de lire et de maintenir les post-mortems :

- `csirt_get_postmortem` — lit le post-mortem d'un rapport, y compris les trois sections narratives, `time_to_fix_seconds` et `revisions_count`.
- `csirt_set_postmortem` — crée ou met à jour un post-mortem (upsert). Seuls les champs que vous transmettez sont modifiés ; les autres restent intacts.

Consultez la [Référence des outils MCP](/docs/mcp-tools-reference) pour les paramètres et permissions complets.

## Pour aller plus loin

- [Triage des rapports](/docs/triaging-reports) — résolvez un rapport, puis consignez son post-mortem
- [Métriques et exports](/docs/metrics-and-exports) — packages de preuves SOC 2 en masse, en complément des dossiers par rapport
- [Intégration Vanta](/docs/vanta-integration) — transformez les vulnérabilités triées en preuves de conformité en direct