Une présentation de retour d’expérience après incident doit expliquer ce que les utilisateurs ont subi, comment le service a été rétabli, ce que les faits permettent de comprendre et quelles modifications méritent d’être examinées. Il ne s’agit pas de reprendre tous les messages du canal d’incident. Un diaporama bien ordonné ne doit pas non plus donner une cause pour certaine alors que l’enquête reste ouverte.
Partez du compte rendu vérifié. Les diapositives servent à rendre les distinctions importantes plus faciles à discuter : traitements touchés ou personnes touchées, reprise du service ou résorption du retard, observation ou explication. Le cas ci-dessous montre ce que ces différences changent dans la présentation.
Définir la question à résoudre pendant la revue
Avant de préparer le support, formulez la décision attendue. Pour une équipe technique, elle pourrait être : « Comprenons-nous suffisamment la défaillance pour reprendre ce déploiement, et quels travaux doivent passer en premier ? » Une revue avec les clients peut plutôt devoir préciser les conséquences de l’incident et la prochaine communication. Utilisez la version approuvée pour ce public.
Le guide SRE de Google, en anglais présente le postmortem comme un document décrivant les conséquences, les mesures prises, les causes et les actions à mener. Il invite à examiner les conditions dans lesquelles les personnes ont décidé, plutôt qu’à chercher un coupable. Pour préparer vos slides, constituez donc le dossier avant de l’expliquer. Le support ne remplace pas l’investigation.
Si vous présentez l’avancement courant plutôt qu’une défaillance précise, adoptez une structure de rapport hebdomadaire. Intégrer tout le suivi d’activité à une revue d’incident risque de masquer les questions encore sans réponse.
Cas pratique : la génération des rapports reprend, puis le retard est résorbé
Prenons un exemple fictif de service produisant des rapports téléchargeables. Toutes les heures correspondent à la même journée et sont exprimées en UTC.
| Heure | Ce que le dossier établit | Source à conserver dans un cas réel |
|---|---|---|
| 09:00 | Un déploiement commence. Les premières erreurs enregistrées sur les tâches de génération apparaissent également à 09:00. | Historique de déploiement et journaux des tâches, avec la précision des horodatages. |
| 09:04 | Une alerte informe l’équipe d’astreinte que des tâches échouent. | Événement d’alerte et trace de sa transmission. |
| 09:12 | L’équipe commence le retour à la version précédente. | Journal d’incident et historique du retour arrière. |
| 09:27 | La supervision montre que les nouvelles tâches se terminent à nouveau normalement. | Contrôle de rétablissement et période d’observation utilisée. |
| 10:00 | Le rapprochement des identifiants indique que les 180 tâches identifiées comme touchées sont terminées. | Vérification tâche par tâche, en tenant compte des relances. |
Les notes indiquent que les processus de traitement ont enregistré un statut inconnu pendant la défaillance. Elles ne permettent pas encore de savoir quel composant l’a introduit ni pourquoi les contrôles avant déploiement ne l’ont pas détecté. Le dossier contient 180 identifiants de tâches distincts, mais aucun décompte vérifié de clients distincts et aucune estimation des conséquences commerciales.
Ces éléments suffisent pour préparer une revue utile sans inventer ce qui manque. Gardez les références des journaux à portée de main. Ne projetez ni données sensibles, ni jetons d’accès, ni informations personnelles sur les clients.
Distinguer le rétablissement du service et le traitement du retard
Une accroche tentante serait : « Une panne de 27 minutes a touché 180 clients. » Elle demande deux corrections. L’exemple décrit des erreurs de génération de rapports, pas une indisponibilité totale du service. Il compte des tâches, pas des personnes : une même personne peut avoir demandé plusieurs rapports.
Un titre plus exact serait : « Des erreurs de génération ont été observées pendant 27 minutes ; les 180 tâches touchées identifiées étaient rapprochées et terminées à 10:00. » Faites apparaître deux intervalles :
- 09:00–09:27 : de la première erreur enregistrée au retour à un traitement normal des nouvelles tâches.
- 09:27–10:00 : les 33 minutes supplémentaires nécessaires pour achever le rapprochement des tâches touchées.
Le second intervalle compte pour une personne qui attend encore son rapport, même si les nouvelles demandes aboutissent. Ne dites pas que chaque tâche a subi une heure de retard : ce calcul demanderait son heure de soumission et son heure de fin. De même, « tâches terminées » ne prouve ni l’exactitude du contenu de tous les rapports, ni l’absence de perte de données.
Sur la diapositive, utilisez une frise horizontale avec deux repères distincts : reprise et fin du rattrapage. Précisez le fuseau horaire à côté de l’axe. Si l’heure de la première erreur n’est qu’une estimation dans votre dossier, indiquez cette incertitude au lieu de lui substituer l’heure du déploiement.
Organiser la revue en sept diapositives fondées sur les faits
Sept diapositives constituent un point de départ adapté à ce cas. Réduisez ce nombre lorsque les faits sont simples ; ajoutez des pages d’appui lorsqu’un point contesté exige un examen détaillé.
- Ce qui s’est passé et ce qui demande une décision. Présentez les conséquences établies, l’état actuel du service et la décision de déploiement encore ouverte.
- Qui ou quoi a été touché. Montrez les 180 tâches distinctes, le parcours concerné et l’absence de décompte des clients. Une estimation plausible ne remplace pas une donnée inconnue.
- Le déroulement de l’incident. Reprenez les cinq heures enregistrées, en séparant alerte, retour arrière, reprise et rattrapage.
- Ce que les éléments disponibles expliquent. Placez l’observation du statut inconnu à côté de la question à instruire. La chronologie du retour arrière est pertinente, mais elle ne suffit pas à établir tout le mécanisme de défaillance.
- Ce qui a aidé ou ralenti la réponse. Discutez des informations, outils ou difficultés de coordination documentés. N’inventez pas d’« enseignements » pour équilibrer visuellement la page.
- Les modifications proposées. Séparez prévention et amélioration de la réponse, avec un responsable et un moyen de vérifier l’achèvement.
- Les points à trancher ensemble. Confirmez les priorités, les preuves manquantes et les conditions d’un nouvel examen du déploiement.
Conservez les journaux détaillés, les conditions de test et les définitions du rapprochement dans les documents d’appui. Une diapositive de synthèse pour les décideurs, expliquée dans ce guide en anglais, peut orienter un public plus large. Elle doit toutefois conserver la différence entre la reprise des traitements et les conséquences qui persistent.
Expliquer l’état de l’analyse sans clore artificiellement la cause
« Quelqu’un a déployé une mauvaise modification » n’aide guère le prochain ingénieur à reconnaître ou à prévenir le problème. Cette formule évite aussi les questions soulevées par le cas : quelles versions des composants producteurs et des processus de traitement fonctionnaient ensemble, quels statuts acceptaient-elles et que couvraient réellement les vérifications avant déploiement ?
Divisez la diapositive en trois parties : observation, explication envisagée et éléments encore nécessaires. Ici, l’observation est l’erreur de statut inconnu. Une incompatibilité éventuelle reste une hypothèse tant que les versions concernées et une reproduction ne l’étayent pas. La suite de l’enquête peut donc comparer ces versions et tenter de reproduire le cas dans un environnement de test approprié.
Si deux sources donnent des heures différentes, conservez-les toutes les deux pendant la résolution de l’écart. Si la cause est contestée, limitez le titre à ce qui est établi. La revue peut tout à fait aboutir à la décision de poursuivre l’enquête ; elle n’exige pas une explication causale achevée pour être utile.
Proposer des actions plus précises que « faire davantage attention »
Pour notre incident fictif, les actions suivantes sont des pistes à discuter. Elles ne sont ni des corrections déjà réalisées ni des engagements acceptés.
| Modification proposée | Question traitée | Élément permettant de vérifier l’achèvement |
|---|---|---|
| Ajouter un test de compatibilité entre les versions des composants producteurs et des processus de traitement concernés. | Le processus de déploiement peut-il révéler cette défaillance avant la mise en service ? | Un test documenté reproduit le statut rejeté avec la combinaison défaillante et consigne le comportement attendu avec la combinaison corrigée. |
| Ajouter une section « reprise et rattrapage » à la procédure d’incident. | L’équipe peut-elle distinguer les nouvelles tâches rétablies des tâches touchées encore en attente ? | Une procédure relue et une répétition enregistrent séparément reprise, rapprochement et tâches non résolues. |
Demandez aux équipes concernées de confirmer les responsables, les priorités et les échéances. N’attribuez pas une action à une personne au seul motif qu’elle a été la première à intervenir. Évitez « cela ne se reproduira plus » : ni un test ni une procédure ne le démontre. Expliquez la défaillance ou le délai précis que chaque action cherche à traiter.
Préparer le support dans Presenti à partir du dossier vérifié
Préparez un brief débarrassé des informations sensibles : définition des conséquences, chronologie, références, constats établis, questions ouvertes et actions proposées. Utilisez le parcours texte vers présentation de Presenti, présenté sur cette page en anglais, pour obtenir une première version des sept diapositives. Demandez de conserver les deux repères 09:27 et 10:00 et de laisser le nombre de clients inconnu.
Relisez le plan avant de choisir le style graphique. Si le brouillon transforme « incompatibilité possible » en « cause confirmée », corrigez l’affirmation avant d’aller plus loin. Dans la version modifiable, laissez assez de place aux libellés de la frise et gardez le critère d’achèvement à côté de chaque action. Presenti peut organiser l’explication ; il ne peut ni valider les journaux d’incident ni décider que le déploiement est sûr.
Téléchargez le brief d’incident et le plan en sept diapositives, ou reprenez cette consigne :
Crée un brouillon de revue d’incident à partir du dossier fourni. Sépare les conséquences, la détection, le retour arrière, la reprise des nouvelles tâches et le rapprochement des tâches touchées. Distingue observations et hypothèses. Conserve les inconnues, les références et les fuseaux horaires. N’invente ni clients touchés, ni pertes financières, ni causes, ni responsables ayant accepté une action, ni actions achevées.
Terminez la réunion en consignant les accords réels et les éléments encore attendus. Reprenez ces points précis lors de la prochaine revue. Le résultat utile est un récit plus clair de l’incident et des choix étayés sur la suite, pas une diapositive affirmant que toute récidive est impossible.
