Monitoring en production : feedback, traces, alertes

Pourquoi le monitoring change de nature avec un LLM

Un système applicatif classique se surveille avec des signaux quasi binaires : code d'erreur HTTP, temps de réponse, taux de succès. Un système LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire en production ne casse presque jamais de cette façon. Il répond toujours quelque chose, avec un code 200, dans un temps raisonnable — et cette réponse peut pourtant être fausse, hors sujet, incohérente avec le tour précédent, ou dangereuse pour l'utilisateur. Le monitoring d'un système LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire doit donc surveiller une dimension que les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire d'observabilité classiques ignorent par construction : la qualité du contenu généré, pas seulement la disponibilité du service.

Ce chapitre s'appuie sur les méthodes d'évaluation vues précédemment (golden sets, LLM-as-judgeLLM-as-judgeIAÉvaluation automatisée où un LLM note ou compare des sorties selon des critères définis, souvent en complément de métriques classiques.Voir dans le glossaire) mais change de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire. Hors ligne, on contrôle le jeu de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire et on peut se permettre des évaluations coûteuses. En production, le volume est trop grand pour tout relire, la distribution des requêtes diverge toujours un peu de ce qui a été anticipé en test, et la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire peut survenir sans qu'aucun code n'ait changé côté équipe.

Un système LLM en bonne santé technique — latence correcte, taux d'erreur serveur proche de zéro — peut être en pleine dérive de qualité sans qu'aucune alerte infrastructure classique ne se déclenche. Le monitoring applicatif standard est nécessaire, mais structurellement insuffisant.

Les trois couches de signaux à instrumenter

Un dispositif robuste combine trois couches complémentaires, chacune répondant à une question différente.

La trace de bout en bout répond à « que s'est-il passé, techniquement, pour produire cette réponse ? ». Elle reconstitue le cheminement complet d'une requête : récupération de contexte, construction du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, appel au modèle, appels d'outils, post-traitement. Sans elle, un incident signalé reste une boîte noire.

Le feedback utilisateur répond à « cette réponse a-t-elle été utile, du point de vue de la personne qui l'a reçue ? ». C'est le seul signal qui capture directement la perception de qualité côté usage réel, plutôt qu'une approximation calculée a posteriori.

Les métriques agrégées répondent à « la qualité globale se dégrade-t-elle dans le temps ? ». Elles transforment les deux couches précédentes en séries temporelles exploitables pour détecter une tendance, avant qu'elle ne devienne un incident isolé remonté par un utilisateur mécontent.

Ces trois couches s'articulent en pipeline : la trace documente l'événement, le feedback le qualifie, l'agrégation le transforme en signal de pilotage. Retirer l'une d'elles laisse un angle mort — la trace seule ne dit rien de la satisfaction, le feedback seul ne diagnostique pas une cause technique, l'agrégation seule masque les cas individuels à relire.

Tracer une requête LLM de bout en bout

Chaque requête entrante devrait être associée à un identifiant unique (trace_id) qui relie tous les événements produits pendant son traitement : appels de récupération de contexte (retrieval), construction du prompt final envoyé au modèle, appel au modèle lui-même avec ses paramètres, appels d'outils déclenchés par le modèle, et post-traitement de la réponse avant retour à l'utilisateur. Chaque étape constitue un span — une portion de la trace avec son propre horodatage, sa propre durée, et ses propres métadonnées.

Cette granularité sert un objectif précis : quand un feedback négatif ou une alerte signale un problème, l'équipe doit pouvoir reconstituer ce que le modèle a reçu en entrée, pas seulement ce qu'il a produit en sortie. Une réponse fausse peut avoir deux origines à diagnostiquer différemment : un modèle qui hallucine à partir d'un contexte correct, ou un contexte de récupération déjà erroné que le modèle a fidèlement restitué. Sans trace du prompt final réellement envoyé, ces deux causes sont indiscernables après coup.

Pour une requête de support technique avec récupération documentaire, une trace utile enregistre au minimum : trace_id, horodatage, requête brute, documents récupérés avec score de pertinence, prompt final assemblé, réponse brute du modèle, appels d'outils avec résultats, réponse post-traitée envoyée à l'utilisateur, latence par span, coût en tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire. Un incident remonté trois semaines plus tard reste diagnosticable seulement si cette trace a été conservée intégralement, pas résumée.

Deux précautions s'imposent. D'abord, la durée de rétention des traces doit être définie explicitement — les conserver indéfiniment pose un problème de conformité, les supprimer trop tôt empêche le diagnostic d'un incident signalé tardivement. Ensuite, les traces contenant des données personnelles doivent respecter les mêmes règles d'accès et d'anonymisation que le reste des données utilisateur : la trace n'est pas un espace de journalisation exempté des politiques de confidentialité en vigueur.

Feedback utilisateur : implicite et explicite

Le feedback explicite est le signal le plus visible mais souvent le moins abondant. Pouce levé ou baissé, note sur une échelle, commentaire libre : ce feedback est directement interprétable, mais il souffre d'un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire de participation bien documenté — les utilisateurs qui prennent le temps de noter sont disproportionnellement ceux qui ont vécu une expérience extrême, très bonne ou très mauvaise. Un taux de 2 à 5 % du volume total est courant, ce qui limite sa représentativité sur les segments d'usage peu fréquents.

Le feedback implicite compense cette limite en captant un signal sur tout le volume, sans action volontaire. Plusieurs signaux se sont révélés informatifs en pratique :

• La régénération de réponse — l'utilisateur redemande une réponse à la même question, signe fort d'insatisfaction.
• La reformulation rapprochée — l'utilisateur reformule sa question dans les secondes qui suivent, signe que la réponse n'a pas répondu à son besoin réel.
• L'abandon de session — l'utilisateur quitte la conversation sans poursuivre un échange qui aurait dû continuer (support non résolu, par exemple).
• L'escalade vers un humain — dans un système hybride, le passage à un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire humain signale un échec du système automatisé sur ce cas précis.
• La copie ou l'export de la réponse — à l'inverse, signal positif indirect : la réponse est jugée assez utile pour être réutilisée ailleurs.

Aucun de ces signaux n'est fiable isolément — une reformulation peut aussi signifier que l'utilisateur affine sa question, sans que la première réponse ait été mauvaise. C'est leur combinaison, suivie dans le temps par cohorte de requêtes similaires, qui produit un signal exploitable.

Détecter la dérive silencieuse

Un système LLM en production peut se dégrader sans qu'aucun changement n'ait eu lieu du côté de l'équipe qui l'exploite. Trois mécanismes de dérive silencieuse reviennent régulièrement.

La mise à jour du modèle par le fournisseur. Un modèle accessible par API évolue parfois sans préavis explicite — correctif de sécurité, réoptimisation interne, changement de version mineure. Le comportement peut changer sur des cas limites précis sans qu'aucune documentation ne le signale à l'avance.

La dérive de la distribution des requêtes. Les cas soumis au système évoluent avec le temps : nouveaux types de demandes, nouveau vocabulaire métier, saisonnalité des sujets traités. Un système calibré sur une distribution vieille de six mois peut se dégrader progressivement, non parce que le modèle a changé, mais parce que les cas soumis ont changé.

La modification non revalidée d'un composant en amont. Changement de prompt système, mise à jour de la base documentaire, ajustement des paramètres de génération : chacun de ces changements, même mineur, peut dégrader la qualité globale sans qu'un test unitaire classique ne le détecte, faute d'être passé par le pipeline d'évaluation avant déploiement.

Aucun de ces trois mécanismes ne se signale de lui-même. C'est pour cette raison que le monitoring continu, et non la seule évaluation ponctuelle avant mise en production, constitue la seule protection réelle contre ce type de dégradation.

La contre-mesure la plus fiable consiste à rejouer régulièrement un golden set stable sur le système en production, à intervalle fixe (quotidien ou hebdomadaire selon l'enjeu), y compris quand aucun changement de code n'a été effectué. Un score qui chute sur un golden set inchangé pointe directement vers une dérive côté modèle ou fournisseur.

Construire des alertes qui restent utiles

La tentation naturelle consiste à fixer des seuils absolus — alerter si le taux de feedback négatif dépasse 10 %, ou si la latence moyenne dépasse deux secondes. Cette approche fonctionne mal, pour deux raisons. D'abord, le volume et la nature des requêtes varient selon l'heure et le jour, rendant un seuil fixe trop sensible en période creuse ou trop tardif en période de forte charge. Ensuite, un système en évolution constante déplace sa propre baseline légitimement — un taux d'escalade normal la semaine dernière ne l'est plus forcément après une amélioration de prompt qui a changé la nature des cas escaladés.

Une approche plus robuste consiste à définir les alertes par rapport à une baseline mobile — moyenne et écart-type observés sur une fenêtre glissante récente (sept à quatorze jours) — et à déclencher l'alerte sur un écart significatif à cette baseline plutôt que sur une valeur absolue. Un taux d'escalade de 12 % peut être normal pour un système donné et alarmant pour un autre ; ce qui compte, c'est l'écart au comportement récent habituel du même système.

Un système qui déclenche des alertes trop fréquentes, ou trop de faux positifs, finit par voir ses alertes ignorées — exactement comme n'importe quel système d'alerte mal calibré. Mieux vaut un nombre restreint d'alertes à fort taux de vrai positif, avec un routage clair, qu'une liste longue de signaux écartés sans lecture. Revoir périodiquement le taux de faux positifs de chaque alerte fait partie de la maintenance du dispositif, au même titre que sa mise en place initiale.

Le rôle de l'échantillonnage humain

Aucune alerte automatisée ne remplace la relecture humaine, elle en oriente le placement. Un dispositif mature combine deux flux complémentaires.

L'échantillonnage aléatoire continu — relire manuellement un pourcentage fixe du volume (1 à 5 % selon l'enjeu), indépendamment de tout signal d'alerte. Ce flux protège contre les dérives que ni le feedback utilisateur ni les alertes ne détectent, notamment quand l'utilisateur ne se rend pas compte que la réponse était fausse.

Le routage prioritaire par signal — diriger vers la relecture humaine les cas associés à un feedback négatif, une régénération, une alerte déclenchée, ou un désaccord entre juges automatiques si un dispositif LLM-as-judge est en place. Ce flux concentre l'effort humain, nécessairement limité, sur les cas où la probabilité d'un problème réel est la plus élevée.

Les cas identifiés en production comme problématiques, une fois vérifiés par un relecteur humain, constituent la meilleure source d'enrichissement pour le golden set. Ce circuit fermé — production vers golden set vers évaluation avant déploiement — évite que le même type d'erreur ne se reproduise à chaque nouvelle version du système.

Dashboard et triage en production

Un dashboard efficace organise l'information par niveau de décision, pas seulement par type de métrique. Trois niveaux répondent à trois besoins différents.

Le niveau opérationnel, consulté quotidiennement, affiche les métriques agrégées sur les dernières vingt-quatre à quarante-huit heures : taux de feedback négatif, taux d'escalade, latence, volume par type de requête, alertes actives. C'est le tableau de bord de la surveillance courante.

Le niveau diagnostic, consulté lors du traitement d'une alerte, permet de descendre jusqu'à la trace individuelle : filtrer par période, par segment d'utilisateurs, par type de requête, jusqu'à isoler les cas concrets à l'origine de la dégradation observée au niveau agrégé.

Le niveau tendanciel, consulté à fréquence hebdomadaire ou mensuelle, trace l'évolution des métriques clés sur plusieurs mois — il révèle les dérives lentes qu'aucune alerte ponctuelle ne capture, parce qu'aucun jour pris isolément ne s'écarte assez de la baseline pour déclencher un signal, alors que la tendance sur trois mois est nette.

Séparer ces trois niveaux évite l'écueil le plus courant des dashboards de monitoring : un tableau unique surchargé, consulté par personne parce qu'aucune des personnes concernées n'y trouve l'information dont elle a besoin pour sa décision propre.

Checklist avant mise en production

• Chaque requête produit une trace complète associée à un identifiant unique, couvrant contexte récupéré, prompt final, réponse brute, post-traitement et appels d'outils.
• La durée de rétention des traces est définie explicitement et respecte les règles de confidentialité des autres données utilisateur.
• Un canal de feedback explicite est disponible, même si son taux de participation reste faible.
• Au moins deux signaux de feedback implicite sont instrumentés (régénération, reformulation, abandon, escalade).
• Les alertes sont calibrées sur une baseline mobile plutôt que sur des seuils absolus, sauf plancher métier fixe (latence, escalade critique).
• Le taux de faux positifs de chaque alerte est revu périodiquement pour éviter la fatigue d'alerte.
• Un golden set stable est rejoué à intervalle régulier en production, indépendamment de tout déploiement de code.
• Un flux d'échantillonnage aléatoire et un flux de routage prioritaire par signal alimentent la relecture humaine.
• Les cas confirmés problématiques sont réinjectés dans le golden set d'évaluation hors ligne.
• Le dashboard distingue un niveau opérationnel, un niveau diagnostic et un niveau tendanciel.

Le monitoring d'un système LLM en production n'est pas une étape terminale après le déploiement, c'est un dispositif qui continue de produire de la connaissance tant que le système fonctionne. Sans lui, les méthodes d'évaluation hors ligne restent valables au moment du déploiement, mais aveugles à tout ce qui se produit ensuite — et c'est précisément ensuite que la majorité des dérives réelles se manifestent.