Agent de Retour d'Expérience d'Incident
Transforme une chronologie confuse en un retour d'expérience qui met en cause le système
- 8règles strictes
- Ce qu'il ne doit jamais faire, appliqué à chaque exécution
- 5règles de transfert
- Les cas où il s'arrête et confie le travail à une personne
- 11champs de sortie
- Un résultat structuré, pas un paragraphe à relire
- ≤5étapes par exécution
- Travail borné : au plus 3 appels d'outils, imposé par le moteur d'exécution
Lecture seule par conception. Cet agent n'a aucun moyen d'envoyer, de dépenser, de publier ou de valider quoi que ce soit. Là où cette limite est le produit, la retirer supprimerait la raison de faire confiance au résultat.
Aperçu
Tout le monde s’accorde à dire qu’un post-mortem doit être sans mise en cause, et la plupart ne le sont pas. Sans mauvaise intention : à minuit, « la mise en production de configuration de 17 h 40 » est la phrase vraie la plus facile à écrire, et dès qu’une personne est sur la page, le document cesse de parler du système.
Cet agent ne peut pas nommer une personne. Il reconstitue la chronologie depuis vos journaux, vos alertes et vos échanges, sépare ce qui s’est passé de ce que l’on croyait sur le moment, et pose les questions qui trouvent des causes systémiques : pourquoi l’alerte ne s’est pas déclenchée, pourquoi le retour arrière a pris neuf minutes, pourquoi cette configuration pouvait partir sans relecture.
Ses actions sont précises et vérifiables, et il marque celles qui ne sont en réalité que des vœux. « Faire plus attention » n’est pas une action ; « exiger une relecture des changements de configuration en production » en est une. Et il sépare ce qui est su de ce qui est supposé, pour que le mois prochain personne ne prenne une théorie du document pour un fait établi.
Bénéfices
Écrit le jour même
Un post-mortem écrit une semaine plus tard est une reconstitution.
Sûr à faire circuler
Rien dedans ne peut se lire comme une accusation.
Des actions qui changent quelque chose
Des points vérifiables plutôt que des résolutions.
Ce qu'il fait
Ne peut pas nommer une personne
Une règle dure, pas une préférence de ton. Il parle de rôles et de systèmes, ce qui le maintient sans mise en cause.
Sépare le fait de la croyance
Ce qui était vrai, et ce que pensaient les intervenants sur le moment. Les deux comptent, et les confondre, c’est ainsi que naissent les mythes.
Trouve les causes systémiques
Pas ce qui l’a déclenché, mais ce qui a rendu un déclencheur suffisant pour provoquer une panne.
Des actions que vous pouvez vérifier
Chacune a un rôle responsable et une vérification de son effet. « Faire plus attention » est marqué comme un vœu.
Les manques de détection et de reprise
Le temps avant que quelqu’un sache, et ce qui a rendu la reprise plus lente que nécessaire.
Marque l’inconnu
Une question non résolue est un constat, pas un trou à combler avec une théorie.
Ce que cela change
Ce que cela change à votre semaine
- Ce qu'il reprend
- Transformer un canal d’incident en document avec causes et actions.
- Fait aujourd'hui par
- Un ingénieur à minuit, ou une semaine plus tard de mémoire.
- À quelle fréquence
- Chaque incident.
- Effort manuel habituel
- Un post-mortem correct, c’est une demi-journée tant que tout est frais.
Pourquoi Informatique et gestion des services en particulier. Il ne peut pas nommer une personne. Si un seul ingénieur a pu provoquer la panne, le système l’a permis — et c’est le constat qui évite la suivante.
Fonctionne sans surveillance
Lancé par vous ou par un événement, il termine seul. Rien n'attend que quelqu'un soit à son bureau.
La même exigence à chaque fois
Le deux centième élément est tenu au niveau du premier. La régularité est la part que les humains ne tiennent pas.
Il ne peut pas agir de lui-même
Agent de Retour d'Expérience d'Incident n'a aucun moyen d'envoyer, de dépenser ou d'engager quoi que ce soit. C'est précisément cette limite qui rend son résultat sûr à exploiter.
Comment il fonctionne
Cet agent s'exécute côté serveur via l'environnement d'exécution PROMIVO. Chaque exécution est journalisée étape par étape et chaque appel d'outil est soumis à une vérification des autorisations avant d'être exécuté.
- 1EntréeValidée par rapport au schéma d'entrée de l'agent
- 2Modèleclaude-sonnet-5 avec repli automatique
- 3Outilsextract_structured_data
- 4PermissionsExécute automatiquement les actions READ ; tout ce qui est au-dessus attend une validation
- 5SortieRésultat structuré conforme au schéma de sortie
- 6JournalisationJetons, durée et chaque étape sont enregistrés
Démo
Données de démonstrationIllustrative sample output, abridged.
Entrée
{
"severity": "SEV2",
"timeline": "…",
"incidentReference": "INC-402"
}Sortie
{
"summary": "A configuration change reduced the connection pool below what peak traffic required. Requests queued, then timed out. Service was restored by reverting the change.",
"escalate": false,
"unknowns": [
"Why the pool size was reduced. The record does not say, and the change carried no description."
],
"disclaimer": "Blameless by construction: roles and systems only, never a person, and no finding attributes cause to human error. Actions are proposals; nothing has been changed.",
"actionItems": [
{
"action": "Require review for production configuration changes.",
"status": "actionable",
"ownerRole": "Platform team",
"testForSuccess": "An unreviewed config change is rejected in a test attempt."
},
{
"action": "Be more careful with configuration.",
"status": "not-actionable",
"ownerRole": "—",
"testForSuccess": "None possible."
}
],
"recoveryGap": "9 minutes of the 14-minute recovery was the redeploy. A config rollback would have been under a minute.",
"detectionGap": "23 minutes from first failed request to anyone knowing. The signal came from customers, not monitoring.",
"contributingConditions": [
"Production configuration could be changed without review.",
"No alert existed on connection pool saturation, so the first signal was customer reports.",
"The revert path required a full redeploy rather than a configuration rollback."
]
}Prérequis
Intégrations
Aucune intégration requise.
Avant de commencer
- La chronologie de l’incident : alertes, journaux, échanges, historique de déploiement
- Nécessite le forfait Démarrage ou supérieur
Cas d'usage
Après une panne
Transformer le canal d’incident en document en quelques minutes.
Incidents récurrents
Trouver la cause que les trois derniers post-mortems ont manquée.
Résumés pour les clients
Une base factuelle pour ce que vous leur direz, sans détail interne.
Tarifs
Démarrage
Facturé mensuellement via votre abonnement PROMIVO. Résiliable à tout moment.
Les exécutions consomment le quota de votre offre pour les exécutions d’agents et les tokens. Voir les limites de l’offre
FAQ
Pourquoi ne nomme-t-il pas le responsable ?
Parce que si une personne peut provoquer une panne à elle seule, le système l’a permis, et c’est cela le constat. La nommer met fin trop tôt à l’enquête et apprend à tous les autres à se taire davantage au prochain incident.
Peut-il écrire la note destinée aux clients ?
Il peut en rédiger la base factuelle, sans détail interne de systèmes. Communiquer ou non sur un incident, et comment, est une décision au poids commercial et juridique, qui reste à une personne.
Et si la chronologie est incomplète ?
Il marque les trous comme inconnus et liste ce qu’il faut vérifier. Un post-mortem au milieu inventé avec assurance est pire qu’un post-mortem avec un trou honnête.
Avis
Les avis s'ouvrent une fois que des clients ont exécuté cet agent.
Vous voulez que cet agent fonctionne autrement ?
Dites-nous ce qui doit changer et notre équipe cadrera une version sur mesure pour votre entreprise.
Personnaliser cet agent