Trame de rapport post-incident
Structurer un rapport post-incident client (RCA) lisible, en distinguant résumé, chronologie, impact, cause racine et actions.
À retenir
- Un RCA client répond dans l'ordre à : que s'est-il passé, quel impact, pourquoi, et quelles garanties.
- Rédiger le résumé exécutif en dernier, une fois la chronologie et la cause racine stabilisées.
- Ne jamais publier une cause racine non confirmée pour gagner du temps.
- Distinguer clairement ce qui se communique au client de ce qui reste strictement interne.
Un rapport pour le client, pas un compte rendu interne
Un rapport post-incident (souvent appelé RCA, « Root Cause Analysis ») destiné à un client n'a pas le même objectif qu'un compte rendu d'astreinte interne. Il doit être compréhensible par un lecteur non technique, tout en restant précis et vérifiable.
Point clé
un bon RCA client répond à quatre questions dans l'ordre où le client se les pose : que s'est-il passé, quel a été l'impact pour moi, pourquoi c'est arrivé, et comment vous garantissez que ça ne se reproduira pas.
Structure type d'un RCA client
- Résumé exécutif (5 à 8 lignes) : ce qui s'est passé, la durée, le périmètre impacté et le statut actuel, sans jargon technique.
- Chronologie factuelle horodatée : chaque événement significatif avec heure, action et responsable.
- Impact : services et utilisateurs affectés, durée d'indisponibilité, éventuel impact contractuel (SLA).
- Cause racine : la cause technique confirmée, distincte des causes contributives ou hypothèses écartées.
- Actions correctives : mesures immédiates déjà appliquées et actions de fond à venir, chacune datée et assignée à un responsable.
- Engagements : ce que le fournisseur garantit pour éviter la récidive, avec une date de revue.
Sur le terrain
rédigez toujours le résumé exécutif en dernier, une fois la chronologie et la cause racine stabilisées ; un résumé écrit trop tôt oblige souvent à tout réécrire.
Ce qui se communique et ce qui reste interne
| Se communique au client | Reste interne |
|---|---|
| Chronologie factuelle des événements visibles ou ayant un impact | Détails de configuration sensibles (mots de passe, schémas réseau précis) |
| Cause racine confirmée et actions correctives | Débats internes sur les responsabilités entre équipes |
| Engagements datés et vérifiables | Sanctions ou mesures RH liées à l'incident |
| Impact mesuré (durée, périmètre, SLA) | Coût interne de la remédiation, sauf clause contractuelle contraire |
Attention
ne jamais publier une cause racine non confirmée pour aller plus vite. Une cause annoncée puis démentie détruit davantage la confiance qu'un délai d'analyse plus long mais fiable.
Le ton du rapport
Le registre doit rester factuel et sobre, sans dramatisation ni minimisation. Évitez le conditionnel flou (« il semblerait que ») dans la version finale : soit le fait est confirmé et s'exprime à l'indicatif, soit il reste une hypothèse et doit être présenté comme telle explicitement.
Astuce
faites relire le rapport par une personne qui n'a pas participé à l'incident ; si elle ne comprend pas un paragraphe sans explication orale, il doit être reformulé.