Rédiger un post-mortem après une panne de site web : le guide complet

Mis à jour le 18 octobre 2026 · 8 minutes de lecture

Le site est de nouveau en ligne, tout le monde respire. C'est précisément à ce moment-là que la plupart des TPE, PME et agences web referment le dossier — et c'est une erreur. Un post-mortem bien écrit transforme une panne subie en amélioration durable, en quinze à trente minutes seulement.

Pourquoi rédiger un post-mortem, même pour une panne de cinq minutes

Beaucoup considèrent qu'un post-mortem est réservé aux grandes entreprises tech, avec équipes DevOps et outils dédiés. En réalité, c'est l'inverse : plus une structure est petite, plus une panne non analysée a de chances de se reproduire, car il n'y a souvent personne pour observer le phénomène sur la durée.

• Mémoire courte. Sans trace écrite, les détails exacts de l'incident s'oublient en quelques semaines.
• Récidive invisible. Trois petites coupures « sans importance » en un mois sont souvent le même problème qui s'aggrave progressivement.
• Confiance client. Une agence capable d'expliquer précisément ce qui s'est passé inspire bien plus confiance qu'un simple « c'est réglé ».
• Budget justifié. Le post-mortem est l'argument le plus solide pour faire accepter un investissement en surveillance ou en infrastructure.

L'objectif n'est jamais de désigner un responsable. C'est un exercice tourné vers l'avenir : qu'est-ce qui doit changer pour que ce type d'incident devienne moins probable, ou moins grave ?

Les 5 sections d'un post-mortem efficace

Pas besoin d'un document de dix pages. Un post-mortem utile tient sur une seule page et répond à cinq questions, dans cet ordre précis.

1. Résumé en trois phrases

En haut du document : ce qui s'est passé, pendant combien de temps, et l'impact concret (chiffre d'affaires, demandes de devis perdues, clients ayant signalé le problème). Toute personne pressée doit comprendre l'essentiel sans lire le reste.

2. Chronologie précise, minute par minute

C'est la section la plus importante et la plus souvent négligée. Reconstituez les horaires exacts à partir de sources fiables plutôt que de votre mémoire :

• L'horodatage de la première alerte reçue (e-mail, SMS, notification de surveillance).
• L'heure à laquelle quelqu'un a commencé à investiguer.
• Chaque action tentée, avec son heure et son résultat.
• L'heure du retour à la normale confirmé, pas seulement supposé.

Un historique de surveillance externe est ici précieux : il donne une heure de début et de fin indiscutable, au lieu d'un vague « ça devait être en fin de matinée ».

3. Cause racine, pas seulement le symptôme

« Le site était en panne » n'est pas une cause, c'est une conséquence. Creusez jusqu'à la cause réelle : une extension mise à jour automatiquement, un certificat SSL non renouvelé, un quota d'hébergement dépassé, une erreur humaine lors d'une mise en production. Posez-vous trois fois la question « pourquoi » pour éviter de vous arrêter trop tôt.

Exemple : « Le site a retourné une erreur 500 » → pourquoi ? « Une extension était incompatible » → pourquoi a-t-elle été installée sans test ? → pourquoi n'existe-t-il pas d'environnement de pré-production ? C'est cette dernière réponse qui mérite une action corrective.

4. Ce qui a bien fonctionné

Souvent oubliée, cette section est pourtant utile : la détection a-t-elle été rapide ? La sauvegarde de la veille a-t-elle permis une restauration propre ? Noter les points positifs évite de tout remettre en cause après chaque incident et aide à identifier les pratiques à conserver.

5. Actions correctives, avec un responsable et une échéance

C'est la partie qui transforme réellement le post-mortem en progrès. Chaque action doit être concrète, assignée à une personne précise, et datée — jamais une intention vague du type « faire plus attention la prochaine fois ».

Communiquer le post-mortem à vos clients

Pour une agence gérant des sites pour le compte de clients, le post-mortem interne et le message envoyé au client ne sont pas le même document. Le second doit rester court, non technique et rassurant, tout en restant honnête sur ce qui s'est passé.

• Expliquez ce qui s'est passé, en une ou deux phrases simples, sans jargon.
• Précisez la durée réelle de l'incident, mesurée et non estimée.
• Indiquez la mesure corrective déjà mise en place pour éviter la récidive.
• Évitez de blâmer un prestataire tiers (hébergeur, CMS) même si c'est la cause : cela ne rassure jamais le client.

Un client qui reçoit ce type de message, même pour un incident de dix minutes, retient que son prestataire maîtrise la situation. C'est souvent cela, plus que l'absence totale de panne, qui construit la confiance sur la durée.

Pourquoi un post-mortem est impossible sans historique fiable

La difficulté numéro un pour rédiger un post-mortem sérieux n'est pas de l'écrire : c'est de reconstituer les faits. Sans historique, on reconstruit la chronologie de mémoire, avec des heures approximatives et des causes supposées plutôt que vérifiées.

Une surveillance externe de votre disponibilité, de votre certificat SSL et de votre nom de domaine conserve un historique précis : heure exacte de la coupure, heure exacte du retour, code d'erreur retourné par le serveur à chaque vérification. C'est la matière première indispensable d'un post-mortem crédible, et c'est aussi ce qui permet de calculer le véritable coût d'une panne de site web plutôt que de l'estimer approximativement.

Questions fréquentes