L'agent répond bien en démo. Les cas de test que l'équipe a construits pour la présentation passent tous. Le modèle retrouve les bonnes informations, l'outil s'appelle au bon moment, la réponse finale est cohérente. La direction valide. Le déploiement en production est planifié.
Trois mois plus tard, les premières remontées arrivent. Certaines requêtes obtiennent des réponses à côté. D'autres déclenchent des boucles d'outils qui ne s'arrêtent pas proprement. Un cas d'usage jugé secondaire au démarrage s'avère être celui que les utilisateurs sollicitent le plus, et il se trouve être exactement celui qui n'était pas dans les cas de test. La qualité globale est difficile à qualifier : pas un échec franc, pas une réussite claire. Une zone grise inconfortable.
Ce scénario est la règle, pas l'exception. Le rapport State of Agent Engineering de LangChain, mené auprès de 1 340 équipes en décembre 2025, révèle que 89% des organisations ont mis en place de l'observabilité sur leurs agents en production, mais seulement 52% font tourner des évaluations structurées sur des jeux de test documentés. L'écart entre "surveiller ce qui se passe" et "mesurer si les sorties sont bonnes" est de 37 points de pourcentage. Derrière cet écart, il y a des équipes qui savent que quelque chose dysfonctionne, mais qui ne peuvent pas le qualifier ni le régresser. Ce guide couvre ce qu'elles font, ou devraient faire.
La dérive silencieuse : pourquoi un agent se dégrade sans prévenir
Un agent IA en production n'est pas un système statique. Il évolue sous l'effet de plusieurs forces simultanées, et chacune peut dégrader la qualité de façon progressive et invisible.
La première force est le changement de modèle. Les API d'inférence des grands fournisseurs mettent à jour leurs modèles silencieusement ou avec un préavis minimal. Un modèle de novembre 2024 n'est pas identique à sa version de mars 2025. Il peut se comporter différemment sur certaines catégories de requêtes sans que rien dans les métriques d'infrastructure ne le signale : les latences restent stables, les taux d'erreur HTTP aussi, mais la qualité des réponses dérive.
La deuxième force est le changement de distribution des requêtes. En production, les utilisateurs posent des questions que l'équipe n'avait pas anticipées. Les cas couverts par les tests représentaient peut-être 80% des requêtes attendues au démarrage. Après six mois, les requêtes inattendues représentent 40% du trafic réel. L'agent n'a pas été évalué sur ces cas. On ne sait pas comment il s'en sort.
La troisième force est le changement du contexte externe : des documents mis à jour dans la base de connaissance d'un RAG, des APIs tierces dont les schémas évoluent, des outils dont les comportements changent avec leurs propres mises à jour. Chaque dépendance externe est une source potentielle de dérive, sans que l'agent lui-même ait changé une ligne de code.
Un survey publié sur arXiv en mars 2025 sur l'évaluation des agents fondés sur des LLMs identifie ce problème structurel : les évaluations statiques, construites une fois sur un jeu de données fixes, ne capturent pas la dérive dynamique des agents en production. L'évaluation doit être un processus continu, pas un audit ponctuel réalisé avant le déploiement.
Construire un eval set propriétaire : le point de départ non négociable
L'erreur la plus fréquente est d'évaluer son agent sur des benchmarks génériques : MMLU, HumanEval, SWE-bench. Ces benchmarks mesurent les capacités générales du modèle de base. Ils ne mesurent pas si votre agent répond correctement aux requêtes de vos utilisateurs réels, avec vos outils, dans votre contexte métier.
Un eval set propriétaire est un jeu de données construit à partir de vos propres requêtes de production. Sa construction suit quatre étapes.
Échantillonner les requêtes réelles. Dès le démarrage de la production, on collecte un échantillon représentatif des requêtes traitées : 200 à 500 exemples est un bon point de départ pour couvrir la distribution des cas d'usage. On veille à inclure les cas courants, les cas limites signalés par les utilisateurs, et les cas de refus légitimes, à savoir les requêtes hors périmètre que l'agent doit décliner proprement.
Annoter les sorties de référence. Pour chaque requête de l'échantillon, on documente la réponse attendue ou, pour les tâches agentiques multi-étapes, la trajectoire attendue : quels outils doivent être appelés, dans quel ordre, avec quels paramètres. Cette annotation est réalisée par des experts métier, pas uniquement par l'équipe technique. Le métier sait ce que "correct" signifie dans le contexte de l'organisation.
Fixer des seuils d'acceptabilité. On définit formellement le score minimum sur chaque dimension d'évaluation pour qu'une version de l'agent soit considérée déployable. Ces seuils sont validés par le métier avant le premier déploiement, pas revisités à la baisse quand les scores sont décevants.
Versionner le dataset. L'eval set évolue au fil du temps : on ajoute les nouveaux cas qui ont émergé en production, on retire les cas devenus obsolètes, on ajuste les réponses de référence quand le comportement attendu change. Chaque version du dataset est taguée pour qu'on puisse comparer des scores entre versions de façon valide.
Ce golden dataset est l'actif le plus précieux du projet, plus que le code de l'agent lui-même. Il encode la compréhension partagée entre l'équipe technique et le métier sur ce que "fonctionner" signifie concrètement. Sans lui, toute discussion sur la qualité reste subjective, et les décisions de déploiement restent politiques.
LLM-as-a-judge : un juge fiable si bien calibré
Annoter manuellement 300 requêtes avant le déploiement est faisable. Annoter manuellement les milliers de requêtes qui passent chaque semaine en production ne l'est pas. C'est là qu'intervient l'évaluation automatisée via LLM-as-a-judge : on utilise un LLM pour évaluer les sorties de l'agent selon des critères définis.
La méthode consiste à soumettre à un LLM juge (souvent un modèle distinct et plus puissant que celui utilisé en production) la requête originale, la réponse de l'agent, et un rubric d'évaluation précis. Le juge retourne un score et une justification. LangChain a publié des données sur l'utilisation de cette approche à l'échelle : le critère "answer correctness" a été appliqué plus de 8 millions de fois en une seule semaine de production en mars 2025.
L'approche a une limite importante. Des travaux publiés en 2025 documentent plusieurs biais systématiques des juges LLM : biais de récence (favoriser les réponses présentées en second), biais de position, biais de longueur (favoriser les réponses plus détaillées indépendamment de leur pertinence). Ces biais sont documentés, ils ne rendent pas la méthode inutile, mais ils rendent la calibration obligatoire.
La calibration se fait en double-labelling : on constitue un sous-ensemble de 100 à 200 exemples annotés manuellement par des experts, et on mesure le taux d'accord entre le juge LLM et les annotations humaines. Un accord de 75 à 90% est la cible standard. Si l'accord est inférieur à 70%, le rubric est trop ambigu ou le modèle juge est inadapté au domaine. La calibration n'est pas une étape optionnelle de fin de projet : c'est ce qui distingue un juge LLM fiable d'un oracle qui se trompe de façon systématique et silencieuse.
Les frameworks open-source comme DeepEval proposent des métriques LLM-as-a-judge préconstruites pour les cas courants : faithfulness (la réponse est-elle fondée sur le contexte fourni ?), answer relevancy (la réponse répond-elle à la question ?), task completion (l'agent a-t-il accompli la tâche demandée ?). Ces métriques sont des points de départ, pas des oracles. Les critères spécifiques à votre domaine nécessitent des métriques personnalisées construites avec votre équipe métier.
Les métriques à instrumenter en production
Un agent en production génère deux types de signaux : les signaux d'infrastructure (latence, coût token, taux d'erreur HTTP, longueur des réponses) et les signaux de qualité (pertinence, fidélité, complétion de tâche). Les équipes qui ne font que de l'observabilité capturent les premiers. Les équipes qui font de l'évaluation structurée capturent les deux.
Pour un agent de type RAG ou retrieval, les métriques de qualité prioritaires sont les suivantes.
Faithfulness. La réponse est-elle entièrement ancrée dans les documents récupérés, sans invention d'information absente du contexte ? Une faithfulness qui dérive signale souvent une dégradation de la qualité de la récupération ou un changement de comportement du modèle.
Answer relevancy. La réponse adresse-t-elle précisément la question posée, sans contenu hors sujet ou redondant ? Une baisse de relevancy signale que la distribution des requêtes a changé et sort du profil pour lequel l'agent a été optimisé.
Task completion rate. Pour les agents multi-étapes : quel pourcentage des tâches sont menées à terme sans interruption indue ? Un taux de completion qui baisse pointe souvent vers une régression dans la gestion des cas limites ou un changement de comportement d'un outil externe.
Pour les agents d'action (qui exécutent des tâches dans des systèmes tiers), on ajoute deux métriques complémentaires.
Tool call precision. L'agent appelle-t-il les bons outils, avec les bons paramètres, dans le bon ordre ? Une baisse de précision des appels outils est souvent le premier signal d'une dérive avant que les utilisateurs ne la signalent par des remontées.
Trajectory accuracy. Pour les cas du golden dataset dont on connaît la trajectoire attendue : quel pourcentage de runs aboutissent à la séquence d'actions correcte, pas seulement à une réponse finale acceptable ? Un agent peut produire une réponse plausible par un chemin d'exécution incorrect, ce qui fragilise la robustesse du système à mesure que les cas varient.
La combinaison de ces métriques dessine un tableau de bord de santé qualitative de l'agent. Ce tableau de bord n'est pas le même que le dashboard d'infrastructure, et il ne peut pas s'en déduire. Il faut les deux, en parallèle.
Détecter la dérive : canary sets et seuils d'alerte
Le monitoring de dérive s'appuie sur une technique précise : les canary sets. Un canary set est un sous-ensemble stable du golden dataset, typiquement 50 à 200 exemples, rejoué automatiquement en production à fréquence régulière (quotidienne ou hebdomadaire selon la criticité). Les scores de chaque run sont comparés à une baseline établie au déploiement initial.
La logique d'alerte suit des seuils progressifs. Une variation de moins de 2% sur les scores globaux entre deux runs consécutifs reste dans le bruit normal. Une baisse de 2 à 5% soutenue sur 24 à 48 heures justifie une investigation. Une baisse de plus de 5% déclenche une alerte prioritaire et une revue humaine des exemples dégradés.
Ce que la pratique terrain confirme en 2026 : les équipes qui font tourner des canary runs quotidiens sur leurs modèles en production détectent des dérives silencieuses sur un à deux model IDs par trimestre en moyenne. Ces dérives n'auraient pas été détectées par les métriques d'infrastructure, qui restent stables pendant une dérive de qualité pure. Le canary set est le seul dispositif qui rend visible ce type de régression.
La gestion des dérives suit trois niveaux de réponse. Si la dérive est faible et localisée sur une catégorie de requêtes : on enrichit le golden dataset avec ces cas et on ajuste le prompt système. Si la dérive est modérée et diffuse : on investigate si un outil externe ou le modèle sous-jacent a changé, et on évalue l'impact d'un rollback ou d'un changement de version de modèle. Si la dérive est forte (plus de 10% de baisse sur un critère critique) : on suspend la fonctionnalité ou on revient à une version précédente, le temps de diagnostiquer.
Autre pratique qui s'est standardisée : les drift drills trimestriels. On injecte délibérément une régression connue dans un environnement de staging, et on vérifie que les alertes se déclenchent correctement, que le rollback est opérationnel, et que la post-mortem capture bien la chronologie de la dégradation. C'est l'équivalent des exercices incendie pour l'infrastructure d'évaluation.
Intégrer l'évaluation dans le cycle de développement
La dernière pièce est organisationnelle : l'évaluation doit entrer dans la CI/CD exactement comme les tests unitaires d'un logiciel classique. Chaque modification du pipeline de l'agent (nouveau prompt, nouveau modèle, nouveau outil, nouvelle source de données) doit repasser sur le golden dataset avant déploiement.
Le pattern concret, adopté par les équipes les plus matures, est le suivant. Une action CI déclenche automatiquement une série d'évaluations sur le golden dataset à chaque pull request. Les scores sont publiés en commentaire de PR avec une comparaison à la baseline de référence. Si un score descend en dessous du seuil de qualité prédéfini, le déploiement est bloqué automatiquement. Un ingénieur doit alors soit corriger la régression, soit justifier explicitement l'abaissement du seuil et obtenir une approbation explicite du métier concerné.
Ce pattern change fondamentalement la dynamique d'équipe. Les discussions sur "est-ce que la qualité a baissé ?" deviennent des discussions sur "à quel score sommes-nous, et pourquoi ce score a changé ?". L'équipe n'argumente plus à partir d'impressions, mais à partir de données. Et les décisions de rollback deviennent objectivables, même pour des non-techniciens.
Les plateformes commerciales comme LangSmith (LangChain) et Braintrust ont toutes les deux intégré ce pattern d'évaluation en CI en 2025 et 2026. Les deux offrent des intégrations natives GitHub Actions qui bloquent le merge si les scores chutent sous les seuils. Le choix entre l'une et l'autre dépend principalement de la stack existante : LangSmith s'intègre nativement avec les workflows LangChain et LangGraph, Braintrust est model-agnostic et privilégie l'approche dataset-first sur n'importe quelle infrastructure.
Ce qu'on met en place en mission
Quand un client nous sollicite pour industrialiser un agent IA qui fonctionne en démo, on commence toujours par la même séquence.
D'abord, l'audit de l'existant : existe-t-il un golden dataset ? Sous quelle forme, avec quelle taille, annoté par qui ? Dans la plupart des projets que l'on reprend, la réponse est soit "non", soit "on a quelques exemples de démo" qui ne couvrent pas la distribution réelle des requêtes de production.
Ensuite, la construction du golden dataset avec les équipes métier. On échantillonne les requêtes de production existantes, ou on les construit avec le client si l'agent n'est pas encore déployé. On fixe les seuils d'acceptabilité ensemble, avec les personnes qui savent ce que "correct" signifie dans le contexte métier. Cette étape prend deux à cinq jours selon la complexité du domaine. Elle économise des semaines de debugging une fois en production.
Enfin, l'outillage : on branche les évaluations dans la CI/CD, on configure les canary runs automatiques, on définit les alertes et les procédures de réponse. Selon la stack et les contraintes de souveraineté du client, on s'appuie sur LangSmith, Braintrust, ou un framework open-source comme DeepEval hébergé dans le périmètre du client.
Le résultat n'est pas spectaculaire à montrer en démo. On ne change pas la qualité initiale de l'agent. Ce qu'on fait, c'est rendre la qualité visible, mesurable et défendable dans le temps. C'est la condition pour qu'un agent reste utile après six mois de production, et que les équipes métier lui fassent confiance sur la durée. Un agent sans évaluation continue est un agent qu'on ne peut pas maintenir. Et un agent qu'on ne peut pas maintenir finit toujours par être abandonné.
Vous voulez qu'on regarde votre cas ensemble ? Réservez un créneau, on bloque 30 minutes pour évaluer votre dispositif d'évaluation actuel et identifier les leviers qui vous permettront de mesurer et de maîtriser la qualité de votre agent en production.