Solution · AI Operations

Gestion des incidents des agents IA : la fonction qui répond quand quelque chose casse en production — tri, astreinte, rollback et postmortem — pas quand le client réclame

La supervision détecte que quelque chose ne va pas ; quelqu'un doit répondre. Sans fonction de gestion des incidents, chaque panne d'agent en production est une course improvisée : personne ne sait qui répond, quelle gravité c'est, s'il faut faire rollback ou tenir, ni pourquoi c'est revenu la semaine suivante. Ce n'est pas éteindre un feu une nuit ; c'est la fonction qui tourne — gravités, astreinte, runbooks, rollback, cause racine et actions correctives — pour qu'un incident IA se résolve vite et ne se répète pas.

On le monte chez moi Voir comment ça marche

Le problème

Quand un agent tombe en production, personne ne sait qui répond, à quelle priorité, ni comment le clore pour qu'il ne revienne pas

L'incident est traité par celui qui regardait, à la main et de mémoire : pas de gravités, pas d'astreinte, pas de runbook, donc la même panne reçoit une réponse différente selon qui la prend.
La décision de faire rollback ou de tenir se prend à chaud et sans critère : parfois on laisse un agent cassé donner de mauvaises réponses des heures, parfois on abat toute la production pour un défaut mineur.
Pas de cause racine ni de postmortem : on éteint le feu, on souffle et on continue — jusqu'à ce que le même incident revienne la semaine suivante parce que personne n'a clos l'action corrective.
Le coût de l'incident est invisible jusqu'à ce qu'il soit énorme : mauvaises réponses aux clients, une boucle d'agent qui fait exploser la facture, ou une action erronée sur un vrai système, sans personne pour mesurer le temps de détection et de résolution.

Le coût de ne rien changer

Un agent en production sans gestion des incidents, ce n'est pas un qui ne tombe pas — c'est un où, quand ça casse, les dégâts courent librement pendant que quelqu'un improvise la réponse. La différence entre un incident de dix minutes et un de deux jours, ce n'est pas la chance : c'est avoir ou non la fonction qui répond. Et un incident qui n'est pas clos avec une cause racine n'est pas un incident, ce sont tous ceux qui viennent : ce qu'on n'apprend pas, on le répète, et chaque répétition est la même facture — en confiance client, en coût et en temps de l'équipe qui rééteint le même feu.

La solution

Une fonction de réponse aux incidents pour tes agents : gravités, astreinte, runbook, rollback et postmortem — montée et opérante

1On définit les gravités et la classification : ce qui est un incident critique (un agent qui agit mal sur un vrai système ou fait exploser le coût) face à un mineur, pour que la réponse soit proportionnée et ne dépende pas de qui le prend.
2On monte l'astreinte et l'escalade : qui répond, dans quel ordre et avec quel runbook par type d'incident — y compris le rollback sûr de l'agent, du prompt ou du modèle à la dernière bonne version — avec le contexte déjà récupéré de la supervision.
3On clôt chaque incident avec une cause racine et un postmortem : ce qui s'est passé, pourquoi, quelle action corrective évite le retour, et qui la porte. L'action est suivie jusqu'à ce qu'elle soit faite, pas jusqu'à ce qu'on l'oublie.
4On le laisse avec un tableau de bord : temps de détection, temps de résolution (MTTR), incidents par gravité et % de récurrence. Une fonction qui tourne, pas un héros d'astreinte qui crame.

Ce qui change

Ce que tu arrêtes de perdre

L'incident se résout par processus, pas par celui qui regardait : gravité, runbook et astreinte donnent à la même panne la même réponse rapide à chaque fois.
Mécanisme
La panne cesse de se répéter parce que chaque incident est clos avec une cause racine et une action corrective avec responsable et suivi, pas un « c'est bon, on continue ».
Mécanisme
Ce qu'on mesure : temps de détection, temps de résolution (MTTR), incidents par gravité et % d'incidents récurrents.
Ce qu'on mesure

Fiche technique

Travail supprimé: répondre aux pannes des agents en production à l'improviste, sans gravité, sans runbook et sans clore la cause racine
Mise en place habituelle: 2–4 semaines
Entrée: une alerte de la supervision ou une panne d'un agent en production
Sortie: incident trié, traité par runbook (avec rollback si besoin) et clos avec une cause racine et une action corrective avec un responsable
Compatible avec: PagerDutyOpsgenieJira
Peut se connecter à: Tes agents et leurs journaux de productionTa supervision / observabilité IATon gestionnaire d'incidents ou ticketingTon canal d'alertes et ton astreinte
Ce qu’on mesure: temps pour détecter un incidenttemps pour résoudre (MTTR)incidents par gravité% d'incidents récurrents
Adapté pour: entreprises avec des agents IA en production qui supervisent déjà mais répondent aux incidents à l'improviste, sans gravité, astreinte ni postmortem
Pas adapté pour: la détection en direct du problème (c'est la supervision, en amont) et la décision métier de ce que fait l'agent, qui reste dans ton équipe

Questions fréquentes

Elles sont complémentaires et consécutives, pas la même chose. La supervision est en amont : elle surveille en direct latence, coût, pannes et dérive, et lance l'alerte quand quelque chose dérive. La gestion des incidents, c'est ce qui se passe après cette alerte : qui répond, à quelle gravité, quel runbook on suit, si un rollback a lieu et comment on clôt avec une cause racine pour que ça ne revienne pas. Superviser sans gestion des incidents, c'est avoir des alarmes que personne ne sait traiter ; gérer les incidents sans supervision, c'est répondre à l'aveugle. Elles se montent ensemble, et c'est pourquoi les deux pointent vers le parapluie AI Operations.

Surveiller n'est pas une fonction ; c'est une personne qui crame et un processus qui casse le jour où elle est en congé. Une vraie fonction d'incidents donne ce que la bonne volonté ne peut pas : des gravités pour que la réponse soit proportionnée, une astreinte pour qu'il y ait toujours quelqu'un pour répondre, des runbooks pour que la panne se résolve pareil qui que ce soit qui la prenne, et des postmortems pour en apprendre. La différence entre un incident de dix minutes et un de deux jours, ce n'est pas l'attention ; c'est avoir le processus monté avant que ça arrive.

Ça tourne. On ne te remet pas un PDF de « politique d'incidents » et adieu : on monte les gravités, l'astreinte et l'escalade dans ton gestionnaire d'incidents, les runbooks de réponse et le rollback sûr connectés à tes agents, et le cycle de postmortem avec les actions correctives suivies jusqu'à clôture. Et on le laisse avec un tableau de bord — MTTR, incidents par gravité, récurrence — pour que tu voies la fonction opérer, pas exister dans un document. Une fonction avec un responsable, pas un manuel dans un tiroir.

On le monte chez toi ?

Tu as ciblé le problème. On livre la solution et on la laisse mesurée.

Voir le service