Documenter une panne pour votre équipe technique.
Rassembler les alertes et les changements récents quand un site ou un outil interne ne fonctionne plus.
Une chronologie sourcée, les symptômes rapportés, les informations manquantes et les pistes à vérifier par le responsable technique.
Ce qu’il vous faut
Un incident passé sur un seul service, une fenêtre horaire définie, des extraits autorisés d’alertes et de journaux, et la liste datée des changements connus. Retirer les secrets, jetons d’accès et données personnelles inutiles avant de partager les fichiers avec un assistant approuvé. Conserver les fuseaux horaires et les références d’origine. Des journaux incomplets et une proximité dans le temps ne suffisent pas à établir la cause d’une panne; le responsable technique valide les conclusions et la suite.
Pour commencer
- Choisir un incident clôturé et donner une référence à chaque extrait, avec son horodatage, son fuseau horaire et le service concerné.
- Demander une chronologie qui sépare les observations, les informations absentes et les hypothèses, avec les passages qui soutiennent chaque élément.
- Faire vérifier le dossier par le responsable technique, puis comparer avec ce qui est connu de l’incident avant de décider des prochaines vérifications.
Ce que vous pouvez mesurer pendant un pilote
Qualité des informations, actions oubliées et temps de préparation.
La source · Adaptation locale
OpenAI · réunir les éléments d’un incident ↗La source décrit le principe ou le workflow. Cette adaptation et ses résultats ne sont pas testés indépendamment.
Source consultée le 27 oct. 2026