Comment reconstituer un incident et en rechercher les causes profondes ?
D’après Gestion des incidents
Les faits, chronologie et preuves, pas d’opinions
On reconstitue la trame à partir d’artefacts : journaux horodatés, tickets ITSM, messages, tableaux d’observabilité, ordres de changement, captures EDR/APM.
Les assertions s’appuient sur des pièces, les hypothèses sont marquées comme telles.
Chaque événement porte une heure, un auteur, un contexte.
Les zones d’ombre sont explicites, on note ce qui manque et pourquoi.
Cette rigueur calme les débats, réduit les conflits de mémoire et prépare la recevabilité externe (assureur, régulateur, client).
Elle n’étouffe pas le récit, elle l’épure.
L’objectif n’est pas l’exhaustivité infinie mais la suffisance probante : de quoi trancher des décisions.
Les faits sont partagés sans jugement, dans un espace où l’on peut reconnaître une erreur sans craindre la stigmatisation.
À ce prix, la vérité circule.
Causes racines, du symptôme aux mécanismes
Chercher une cause unique est confortable et faux.
Les incidents naissent souvent de combinaisons : une régression non détectée plus un monitoring bruité, un privilège trop large plus un processus d’approbation contourné, une dépendance SaaS sousdimensionnée plus un pic d’usage.
On utilise des méthodes sobres : « 5 pourquoi », arbres de défaillance, diagrammes d’Ishikawa.
On remonte jusqu’aux mécanismes stables : dette technique accumulée, défaut de standardisation, manque de tests de restauration, absence de budget d’erreur, gouvernance hésitante.
La cause racine est celle sur laquelle une décision structurelle produit un effet durable.
Elle n’est pas toujours technique.
Elle tient souvent à la façon de prioriser, de déployer, de donner mandat. La lucidité fait gagner des mois.