Chaque équipe engineering a le même rituel post-incident. L’incident se produit. Quelqu’un rédige un résumé rapide dans Slack. Quelqu’un d’autre promet de mettre à jour le runbook. Un post-mortem est planifié. Deux semaines plus tard, le runbook n’a toujours pas été mis à jour, le document de post-mortem est à moitié terminé, et la prochaine fois que le même incident se produit, l’ingénieur d’astreinte repart de zéro.
Le problème n’est pas la paresse. C’est que rédiger de la documentation après un incident stressant est la dernière chose que quiconque a envie de faire, et cela entre en concurrence avec le travail de fonctionnalités du sprint suivant. La dette de documentation s’accumule jusqu’à ce que les runbooks soient si obsolètes que plus personne ne leur fait confiance.
Le workflow Incident Response
Le starter pack Engineering inclut un workflow appelé Incident Response. Il prend les données brutes de l’incident — timeline, symptômes, actions prises, cause racine — et produit trois sorties en une seule passe.
-
Rapport d’incident — Un rapport post-incident structuré avec : résumé de l’incident, chronologie des événements, évaluation d’impact (utilisateurs affectés, durée, sévérité), analyse des causes racines, facteurs contributifs et actions immédiates prises. Le format est cohérent d’un incident à l’autre, ce qui rend la reconnaissance de patterns possible sur des mois de rapports.
-
Mise à jour du runbook — L’IA prend les détails de l’incident et génère des ajouts ou mises à jour au runbook pertinent. Si l’incident a révélé un nouveau mode de défaillance, elle rédige les étapes de détection, les commandes de diagnostic et les procédures de remédiation. Si c’est un mode de défaillance connu avec une nouvelle nuance, elle met à jour la section existante. La sortie est structurée comme du contenu prêt pour le runbook, pas un résumé narratif.
-
Revue du responsable Engineering (porte d’approbation) — Avant de publier quoi que ce soit, le workflow se met en pause pour revue. Le responsable engineering vérifie l’exactitude de la timeline, valide l’analyse des causes racines et approuve les ajouts au runbook. Cette porte est critique — les runbooks générés par l’IA ont besoin d’un humain qui était présent pour confirmer que les procédures sont correctes.
-
Génération du post-mortem — Après approbation, l’IA génère un document de post-mortem complet : ce qui s’est passé, pourquoi c’est arrivé, ce qui a empêché une résolution plus rapide, et les actions pour prévenir la récurrence. Chaque action a un propriétaire suggéré et une priorité.
Pourquoi la cohérence est importante pour les documents d’incident
Quand les rapports d’incident suivent des formats différents, vous ne pouvez pas les comparer. Vous ne pouvez pas demander « combien d’incidents P1 ce trimestre ont été causés par des problèmes de base de données ? » à moins que chaque rapport utilise la même échelle de sévérité et catégorisation. Vous ne pouvez pas savoir si les temps de remédiation s’améliorent à moins que chaque rapport inclue les mêmes champs de timing.
La Recipe Incident Report impose un schéma cohérent. Chaque rapport a les mêmes sections, les mêmes catégories de sévérité, les mêmes champs de timing. Au fil du temps, cela devient un jeu de données structuré que vous pouvez interroger, pas simplement un dossier de documents.
Ce que l’ingénieur fait toujours
Le workflow a besoin d’une entrée précise. L’ingénieur fournit :
- Ce qui s’est passé — Chronologie des événements, symptômes observés, alertes déclenchées
- Ce qu’il a fait — Étapes de diagnostic prises, commandes exécutées, correctifs appliqués
- Ce qui l’a causé — Cause racine et facteurs contributifs
L’IA n’investigue pas l’incident — elle le documente. L’investigation, le débogage, le correctif — c’est l’expertise de l’ingénieur. Le travail de l’IA est de transformer cette expertise en documentation bien structurée que le prochain ingénieur d’astreinte peut réellement utiliser.
Les mises à jour de runbook sont particulièrement précieuses ici. Un ingénieur qui vient de passer deux heures à déboguer un problème de production sait exactement quelles étapes suivre la prochaine fois. Normalement, cette connaissance reste dans sa tête ou dans un fil Slack. Le workflow la capture dans une section de runbook avec des commandes spécifiques et des points de décision.
Le workflow Feature Launch
Le pack Engineering inclut également un workflow Feature Launch qui gère l’autre lacune documentaire : les communications de release.
- Rédiger les entrées de changelog à partir de l’historique des commits et descriptions de PR
- Générer des release notes orientées utilisateur avec le bon niveau de détail
- Mettre à jour la documentation API si les endpoints ont changé
- Packager le tout pour revue
Et le workflow Sprint Cycle automatise la documentation de planification et de rétrospective : générer les objectifs du sprint à partir des éléments du backlog, créer des plans de documentation pour les nouvelles fonctionnalités et structurer les notes de rétrospective en améliorations actionnables.
Le pack Engineering complet
Le starter pack Engineering inclut deux workflows supplémentaires en plus d’Incident Response :
- Feature Launch — Release notes, changelog et mises à jour de documentation en une seule passe
- Sprint Cycle — Automatisation de la planification, documentation et rétrospective
Les Recipes autonomes — tech spec writer, API documentation generator, code review feedback, architecture decision records — fonctionnent individuellement ou comme blocs de construction pour des workflows engineering personnalisés.