Chronologie factuelle et preuves
Construire une chronologie horodatée et sourcée qui résiste aux contestations et facilite l'analyse de cause racine.
À retenir
- Chaque événement de la chronologie doit être adossé à une preuve vérifiable et horodatée.
- Aligner tous les horodatages sur un fuseau horaire de référence mentionné explicitement.
- Distinguer clairement faits confirmés, causes contributives, cause racine et hypothèses écartées.
- Conserver les preuves brutes dans un dossier interne référencé, même non jointes au rapport client.
Pourquoi la chronologie est la colonne vertébrale du rapport
Toute contestation client sur un RCA porte presque toujours sur la chronologie : « vous dites que ça a démarré à 9h12, mais nous avons constaté le problème dès 8h50. » Une chronologie mal sourcée fragilise tout le reste du rapport, même si la cause racine identifiée est correcte.
Point clé
chaque ligne de chronologie doit être adossée à une preuve vérifiable — log système, ticket, capture d'écran de supervision, horodatage d'appel — et non à un souvenir reconstitué après coup.
Construire la chronologie pas à pas
- Rassembler toutes les sources horodatées disponibles : outils de supervision, journal d'astreinte, tickets, enregistrements d'appels client.
- Aligner les horodatages sur un même fuseau horaire de référence, mentionné explicitement en en-tête du rapport.
- Ne retenir que les événements factuels et vérifiables ; les hypothèses ou déductions sont indiquées séparément, hors de la ligne chronologique.
- Faire relire la chronologie par une deuxième personne ayant participé à l'incident, pour vérifier la cohérence entre les sources.
Exemple de chronologie horodatée
| Heure (UTC+1) | Événement | Source |
|---|---|---|
| 08:47 | Alerte automatique de supervision sur la baie B-12 (température haute) | Outil de supervision |
| 08:52 | Premier appel du client signalant une latence anormale | Journal d'appels |
| 08:58 | Technicien d'astreinte confirme une défaillance d'une unité de climatisation | Ticket INC-4521 |
| 09:10 | Bascule sur l'unité de secours activée | Journal d'intervention |
| 09:22 | Température revenue dans la plage normale | Outil de supervision |
| 09:35 | Confirmation de service restauré au client | Appel de clôture |
Sur le terrain
en cas de désaccord sur une heure, présentez la source plutôt que de discuter l'heure elle-même ; le débat se déplace alors sur des faits vérifiables et non sur des impressions.
Séparer faits, hypothèses et causes contributives
| Catégorie | Définition | Exemple |
|---|---|---|
| Fait confirmé | Événement observé et sourcé | L'unité de climatisation C2 s'est arrêtée à 08:45 |
| Cause contributive | Facteur ayant aggravé la situation sans être la cause première | Le seuil d'alerte de température était réglé trop haut |
| Cause racine | Origine première ayant déclenché l'incident | Défaillance d'un composant électronique de l'unité C2 |
| Hypothèse écartée | Piste envisagée puis invalidée par l'analyse | Surcharge électrique de la baie (écartée après contrôle des compteurs) |
Attention
mentionner explicitement les hypothèses écartées renforce la crédibilité du rapport, car cela montre que l'analyse a été rigoureuse et pas seulement orientée vers la première explication disponible.
Astuce
conservez les preuves brutes (exports de logs, captures) dans un dossier d'incident interne référencé dans le rapport, même si elles ne sont pas jointes à la version envoyée au client ; elles doivent être mobilisables rapidement en cas de question complémentaire.