Votre agent IA est en production : instrumentation, seuils d'alerte et retour arrière

---

title: "Votre agent IA est en production : instrumentation, seuils d'alerte et retour arrière" seoTitle: "Agent IA en production : surveiller et revenir" description: "Un agent validé avant la mise en ligne se dégrade sans prévenir. Voici les traces à poser, les quatre signaux qui bougent avant les clients, les seuils qui déclenchent une action, et le retour arrière d'un prompt, d'un modèle ou d'un index sans casser les conversations en cours." seoDescription: "Traces, signaux d'alerte et retour arrière d'un prompt, d'un modèle ou d'un index : exploiter un agent IA une fois qu'il est en production." date: "2026-09-19" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "qualité"] category: "IA & Automatisation" keywords: ["agent IA en production", "observabilité LLM", "traces LLM", "évaluation en ligne", "seuils d'alerte IA", "retour arrière prompt", "versionner un prompt", "LLMOps", "surveiller un agent IA", "rollback modèle LLM"]

L'agent est passé en production un mardi. Il avait été évalué correctement : 200 cas réels, un taux de réussite de 92 %, un seuil de mise en ligne discuté et assumé. Six semaines plus tard, un client grand compte remonte trois réponses fausses en deux jours. L'équipe ouvre les logs et découvre qu'elle ne peut répondre à aucune des trois questions qui comptent : depuis quand est-ce que ça dérape, qu'est-ce qui a changé, et est-ce qu'on peut revenir à l'état d'avant. Le dépôt montre onze modifications de prompt depuis la mise en ligne, deux réindexations de la base documentaire, et une bascule vers une version plus récente du modèle faite « sans risque » parce que les tests passaient.

Personne n'a mal travaillé. L'équipe a fait ce que la plupart des équipes font : elle a mis toute son énergie sur la validation d'avant-production, et considéré la mise en ligne comme une ligne d'arrivée. C'est l'inverse. La validation d'avant-production dit qu'on a le droit d'ouvrir ; elle ne dit rien de ce qui se passe ensuite, et elle cesse d'être informative le jour même où le trafic réel commence.

Cet article ne revient pas sur la construction du jeu d'évaluation ni sur les garde-fous — c'est le travail d'avant, et nous l'avons décrit dans l'évaluation qui manque à un agent qui marche 8 fois sur 10. Il traite de ce qui vient après : ce qu'on instrumente, ce qui déclenche une alerte, et comment annuler une modification sans casser les conversations en cours.

Ce que vous perdez le jour de la mise en ligne

Un jeu d'évaluation est une photographie. Il a été constitué à un moment donné, à partir des cas qu'on connaissait alors, et il ne bouge plus. Trois mécanismes le rendent progressivement aveugle.

Le premier est la dérive des entrées. Les utilisateurs réels ne posent pas les questions que vous aviez anticipées. Sur les reprises que nous menons, entre 20 et 40 % des requêtes du premier mois ne ressemblent à aucun cas du jeu d'évaluation — formulations elliptiques, questions à deux intentions, demandes qui relèvent d'un autre service. Votre taux de réussite mesuré reste à 92 %, mais il mesure une population qui n'est plus celle que vous servez.

Le deuxième est la dérive du système lui-même. Le prompt bouge, la base documentaire s'enrichit, un outil change de format de réponse, le fournisseur met à jour le modèle derrière un alias. Chaque changement est petit et justifié ; leur cumul déplace le comportement sans que personne n'ait décidé de le déplacer.

Le troisième est le plus pervers : les échecs en production sont silencieux. Une réponse fausse mais bien écrite ne produit aucune erreur applicative, aucun code HTTP 500, aucune alerte. Votre supervision d'infrastructure vous dira que tout va bien — et elle aura raison, du point de vue de l'infrastructure. C'est la raison pour laquelle les dégradations d'agents se découvrent presque toujours par un client, jamais par une métrique.

La trace, pas le log

La première chose à installer, et celle sans laquelle rien d'autre n'est possible, c'est une trace par interaction — pas une ligne de log par appel HTTP. La différence est décisive : un agent est une chaîne d'étapes, et un incident se diagnostique en reconstituant la chaîne, pas en lisant sa dernière étape.

Une trace exploitable contient, pour chaque interaction : l'identifiant de session et de tour de conversation, l'entrée utilisateur, la version du prompt système utilisée, l'identifiant exact du modèle avec son numéro de version, la liste des appels d'outils avec leurs arguments et leurs retours, les identifiants des passages récupérés si le système fait du RAG, le nombre de jetons en entrée et en sortie, la latence de chaque étape, la sortie finale, et l'issue observable (réponse rendue, escalade vers un humain, abandon, erreur).

Trois champs de cette liste sont systématiquement absents des projets que nous reprenons, et ce sont exactement les trois qui permettent de répondre à « qu'est-ce qui a changé » : la version du prompt, la version précise du modèle, et les identifiants des passages récupérés. Sans eux, une trace raconte ce que l'agent a répondu mais pas avec quoi il l'a produit, ce qui la rend inutilisable pour un diagnostic de régression. Si vous héritez d'un système sans ces éléments, c'est le premier chantier avant toute optimisation — c'est aussi par là que commence une reprise de projet IA, parce qu'aucun verdict technique n'est défendable sans données d'exécution.

Trois précautions d'usage. Les traces contiennent des données personnelles : décidez d'une durée de conservation, masquez les identifiants directs à l'écriture, et documentez ce choix — c'est aussi une pièce du dossier de conformité. Le volume coûte : au-delà de quelques dizaines de milliers d'interactions par jour, échantillonnez les traces complètes à 10 ou 20 %, mais conservez systématiquement les métriques agrégées et 100 % des interactions en échec ou escaladées. Enfin, attachez le coût à la trace : c'est la seule manière de relier une dérive de dépense à un changement précis, et cela évite la découverte tardive décrite dans notre article sur la facture d'API qui triple.

Les quatre signaux qui bougent avant les clients

Une fois les traces en place, quatre familles de signaux se dégradent avant qu'un client ne se plaigne. Aucune n'est suffisante seule ; ensemble, elles donnent un préavis de plusieurs jours.

Les signaux d'usage. Ce sont les moins coûteux à mesurer et les plus fiables. Taux d'escalade vers un humain, taux d'abandon en cours de conversation, taux de reformulation — la proportion d'utilisateurs qui reposent la même question autrement dans le tour suivant. Cette dernière métrique est remarquablement sensible : elle monte quand l'agent répond à côté, bien avant que quiconque ne prenne la peine de signaler une erreur. Sur les systèmes que nous suivons, un taux de reformulation qui passe de 8 à 14 % précède de cinq à dix jours la première remontée client.

La distribution des entrées. Classez les requêtes entrantes par intention, chaque semaine, avec le modèle lui-même sur un échantillon. Ce que vous cherchez n'est pas le volume total mais l'apparition de catégories nouvelles et la part des requêtes hors périmètre. Une nouvelle intention qui atteint 5 % du trafic est soit une opportunité produit, soit une source d'erreurs garantie — dans les deux cas, elle exige une décision.

Les signaux internes de la chaîne. Nombre de tours d'agent par résolution, taux de retries sur les appels d'outils, taux d'échec de la récupération documentaire, latence au 95e centile, part des réponses tronquées par la limite de sortie. Une hausse du nombre moyen de tours d'agent est le signe le plus précoce d'un prompt dégradé : l'agent compense en tâtonnant, la qualité tient encore, le coût et la latence montent déjà.

L'évaluation en ligne. C'est le seul signal qui mesure la qualité elle-même. Faites juger un échantillon du trafic réel — 2 à 5 % suffisent — par un modèle juge, sur les mêmes critères que votre évaluation hors ligne. Ajoutez une revue humaine hebdomadaire de 30 cas tirés au sort, dont la moitié parmi les interactions que le juge a mal notées. Cette revue sert deux fins : elle contrôle le juge, et elle alimente le jeu d'évaluation avec les cas réels qui lui manquaient. Un jeu d'évaluation qui n'a pas grossi depuis la mise en ligne est un jeu d'évaluation périmé.

Des seuils qui déclenchent une action, pas une réunion

Un seuil n'a d'intérêt que s'il est rattaché à une action décidée à l'avance et à un propriétaire nommé. « Surveiller le taux d'escalade » n'est pas un seuil. Trois niveaux suffisent.

Niveau information. La métrique sort de sa plage habituelle mais reste tolérable : entrée dans la revue hebdomadaire, pas de réveil. Typiquement, un taux de reformulation qui gagne 2 points, ou une nouvelle intention qui dépasse 3 % du trafic.

Niveau alerte. Un responsable identifié doit ouvrir les traces dans les 24 heures. Par exemple : le score de l'évaluation en ligne perd plus de 5 points par rapport à la référence des deux premières semaines, le taux d'escalade augmente de moitié, ou le coût moyen par conversation dépasse de 30 % sa valeur de référence.

Niveau coupure. L'action est automatique et ne demande l'avis de personne : bascule en mode dégradé, c'est-à-dire réponse de repli et redirection vers un humain. On y met les cas où le service vaut mieux arrêté que rendu : taux d'erreur applicative au-delà de 5 %, latence au 95e centile qui double, budget horaire dépassé, ou déclenchement d'un garde-fou de sécurité sur plus de 1 % des réponses.

Deux règles rendent ces seuils utilisables. D'abord, calculez-les en relatif sur une fenêtre glissante, à partir d'une référence mesurée pendant les deux premières semaines d'exploitation — un seuil absolu fixé avant la mise en ligne sera toujours soit inactif, soit hurlant. Ensuite, imposez un effectif minimum avant toute alerte : sous 50 interactions dans la fenêtre, aucune alerte ne part. Sans cette règle, votre astreinte se fera réveiller tous les dimanches matin par trois utilisateurs et un taux d'échec de 33 %. Une alerte qui se révèle fausse deux fois de suite est désactivée par l'équipe dans le mois — autant la calibrer correctement du premier coup.

Revenir en arrière : trois objets, trois mécaniques

Un agent en production n'a pas une mais trois surfaces de changement, et elles ne s'annulent pas de la même façon. La règle commune : tout ce qui influence la sortie doit être versionné, référencé dans la trace, et réversible en moins de dix minutes sans déploiement de code. Si revenir sur un prompt exige une livraison applicative, vous ne reviendrez pas en arrière — vous attendrez la prochaine fenêtre de déploiement, c'est-à-dire trop tard.

Le prompt. Traitez-le comme un artefact versionné, stocké hors du code applicatif, désigné par un pointeur que l'exploitation peut basculer. Le point délicat est ailleurs : une conversation commencée avec la version 7 doit se terminer avec la version 7. Épinglez la version à la session, pas à l'instant de l'appel. Sinon, un retour arrière en milieu de journée fait changer de personnalité, de format de sortie et parfois de langue à toutes les conversations ouvertes, et vos utilisateurs constatent une panne là où vous croyiez corriger une régression.

Le modèle. Épinglez une version datée explicite, jamais un alias qui suit la dernière version disponible : un alias transforme une mise à jour du fournisseur en modification non tracée de votre production. Vérifiez aussi que la version précédente reste disponible — un retour arrière vers un modèle retiré du catalogue n'existe pas, et les calendriers de dépréciation se comptent en mois. Enfin, testez le retour arrière avant d'en avoir besoin : un modèle plus ancien peut ne pas honorer le même format d'appel d'outils ni le même schéma de sortie structurée, et le retour arrière échoue alors plus bruyamment que la régression qu'il devait corriger.

L'index documentaire. C'est celui qu'on oublie, parce qu'une réindexation ressemble à une tâche de maintenance. Elle ne l'est pas : elle change les réponses. Ne réindexez jamais en place. Construisez le nouvel index à côté, faites pointer l'application sur un alias, basculez l'alias, et conservez l'index précédent une à deux semaines. Attention au couplage avec le modèle d'embedding : changer ce modèle rend l'ancien index incompatible, et le retour arrière doit alors porter sur les deux ensemble. Si la qualité chute après une réindexation, la méthode de diagnostic est celle décrite dans notre article sur les RAG qui répondent à côté : isolez l'étape de récupération avant de toucher au reste.

Deux effets de bord à connaître. Un retour arrière invalide le cache de prompt : attendez-vous à un pic de coût et de latence pendant quelques minutes, ce n'est pas un second incident. Et si votre agent écrit une mémoire ou des résumés de conversation, ces artefacts ont été produits par la version que vous annulez ; ils survivent au retour arrière et peuvent continuer à porter le défaut. Prévoyez de pouvoir les invalider séparément.

Le tableau de bord qu'on regarde vraiment

Un tableau de bord utile tient sur un écran et porte six chiffres, chacun comparé à sa référence : volume d'interactions, taux de résolution sans escalade, score d'évaluation en ligne, coût moyen par conversation, latence au 95e centile, et nombre d'alertes déclenchées sur la période. Tout le reste appartient aux traces, qu'on ouvre quand un de ces six chiffres bouge.

Autour, un rituel de trente minutes par semaine : lire les six chiffres, relire les 30 cas de la revue humaine, ajouter au jeu d'évaluation les échecs qui n'y figuraient pas, décider s'il faut agir. Ce rituel a un propriétaire nommé. Sans propriétaire, il disparaît en quatre semaines — c'est le mode de défaillance le plus fréquent de tout ce dispositif, avant tout problème technique.

Par où commencer cette semaine

Si votre agent est déjà en ligne et que rien de tout cela n'existe, l'ordre de mise en place compte plus que l'exhaustivité, et deux semaines suffisent pour l'essentiel.

Commencez par la trace complète avec les trois champs de version, et conservez 100 % des échecs : sans elle, aucune des étapes suivantes n'a de sens. Ajoutez ensuite les signaux d'usage, qui ne demandent aucune intelligence artificielle et donnent le préavis le plus long. Mesurez deux semaines de référence avant de fixer le moindre seuil. Mettez en place l'évaluation en ligne échantillonnée et la revue hebdomadaire de 30 cas. Puis, seulement, écrivez les seuils et leurs actions, avec un nom en face de chacun.

En parallèle, vérifiez une chose simple, et faites-en un exercice réel plutôt qu'une hypothèse : combien de temps vous faut-il, aujourd'hui, pour annuler la dernière modification de prompt ? Si la réponse dépasse dix minutes ou passe par un déploiement, c'est le chantier à ouvrir en premier, avant même la supervision. Savoir qu'on se dégrade sans pouvoir revenir en arrière ne fait que rendre l'incident plus documenté.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.