Évaluation du comportement des agents : résultats, trajectoires et retours d’information sur la production
Comment évaluer les systèmes agents au-delà de la réponse finale : associer LangChain, LangGraph et LangSmith à des rôles, analyser les trajectoires de score et le contexte, ainsi que prendre en compte les échecs de production dans les évaluations.
Sources: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Avec les modèles et frameworks actuels, il suffit d’une après-midi pour faire fonctionner un agent IA dans une démonstration. La difficulté commence lorsque cet agent est intégré à un produit réel : il choisit le mauvais outil, reçoit peu de contexte, emprunte une voie non planifiée ou fournit une réponse qui semble correcte mais ne l’est pas en réalité. Cet article examine le cycle de vie technique qui permet de rendre de tels systèmes fiables, en se concentrant sur l’évaluation : ce qu’il faut mesurer, au niveau approprié, et comment transformer chaque échec en production en un mécanisme de vérification pour éviter que cela ne se reproduise. Les exemples utilisent l’écosystème LangChain (LangChain, LangGraph, LangSmith et Deep Agents), mais ces principes s’appliquent à n’importe quel stack.
De une simple appel à un LLM à un système agent
La fonction de base d’un LLM est facile à imaginer : une requête est envoyée, un appel au modèle a lieu, puis une réponse est générée.
User → Prompt → LLM → Response
Un agent est un être différent. Face à un objectif, il peut diviser le travail en tâches, récupérer des documents, appeler des API, exécuter des outils, gérer un état, confier une partie du travail à un autre agent, examiner les résultats intermédiaires, se remettre des erreurs et choisir ensuite sa prochaine action. Vue simplifiée de ce flux de contrôle :
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
Remarquez la boucle en bas : l’agent continue de déterminer s’il reste du travail à effectuer, et chaque itération peut interagir avec des outils, de la mémoire ou des sous-agents. À ce stade, on ne transmet plus simplement une réponse issue d’un modèle ; on exécute un système. Cela est important pour la qualité, car la réponse finale n’est bonne que dans la mesure où la chaîne de décisions qui l’a produite l’est également. Un modèle correct mais avec une étape de récupération défaillante, ou un bon plan exécuté avec l’outil inadapté, produit toujours un résultat médiocre.
Affectation des rôles : LangChain, LangGraph et LangSmith
Une façon pratique de bien comprendre les trois principaux produits LangChain est de relier chacun d’eux à la question technique qu’il répond.
- LangChain offre des fonctionnalités liées au modèle : intégrations de modèles, outils, récupération de données et connexions à des sources externes. Sa question est : que doit être capable de faire l’application ?
- LangGraph gère l’orchestration lorsque les workflows deviennent agents, en prenant en charge l’état, les branches conditionnelles, les boucles, les appels d’outils, les étapes d’approbation humaine et la coordination entre plusieurs agents. Sa question est : comment le workflow doit-il s’exécuter ?
- LangSmith couvre ce qui se passe après que le système est en service : quels outils ont été utilisés, quel contexte le modèle a vu, où la latence a augmenté, quelle étape a échoué, pourquoi une décision a été prise, et si la nouvelle version est vraiment meilleure que l’ancienne. Sa question est : qu’est-ce qui s’est réellement passé, et était-ce positif ?
Lorsqu’elles sont superposées, les étapes s’enchaînent à partir d’un objectif business, en passant par les capacités et l’orchestration, jusqu’à obtenir un résultat qui est ensuite observé et évalué afin que l’équipe puisse en tirer des leçons.
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
La dernière flèche est la plus importante. L’observation n’est pas une étape finale ; elle alimente l’apprentissage. Si la distinction entre LangChain et LangGraph reste floue, notre comparaison des chaînes et graphes à état y consacre un examen approfondi.
Utiliser des agents pour améliorer les agents : le moteur LangSmith
Le suivi vous indique précisément ce qu’a fait un agent, mais une trace à elle seule ne résout rien. Quelqu’un doit encore la lire, déterminer ce qui a mal tourné, vérifier si le même problème apparaît ailleurs, trouver la cause racine, modifier le système et s’assurer que cette modification n’a endommagé rien d’autre. Cela est gérable pour un petit nombre de exécutions, mais impossible avec des milliers de traces en production.
LangSmith Engine, une fonctionnalité plus récente de LangSmith au moment de la rédaction, met en œuvre un agent pour cette analyse. Il scanne les traces en production à la recherche de motifs et d’échecs récurrents, regroupe les problèmes similaires, aide à les diagnostiquer et propose des améliorations. Ce qui est essentiel, c’est que les échecs qu’il détecte peuvent être soumis à une évaluation, de sorte qu’un problème découvert aujourd’hui devient une vérification explicite demain. Conceptuellement, le flux de travail se présente comme suit :
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
Chaque étape affine le problème : les traces brutes se transforment en motifs, les motifs deviennent des diagnostics, les diagnostics donnent naissance à des solutions potentielles, et ces solutions sont soumises à de nouvelles évaluations et tests de régression avant d’être examinées par un humain et déployées. Ensuite, le cycle reprend avec de nouvelles traces.
Le changement réside dans la manière dont les traces sont traitées. Au lieu d’être quelque chose que l’on consulte uniquement en cas d’incident, elles deviennent la matière première d’une amélioration continue. C’est précisément ainsi que fonctionne déjà l’ingénierie de la qualité avancée dans les logiciels conventionnels : une erreur en production ne devrait pas se résoudre par un correctif, mais par un test permettant d’empêcher que le même type de défaut ne réapparaisse discrètement. Cependant, le diagnostic automatisé n’élimine pas la nécessité d’une révision. Les corrections proposées pour les prompts ou les définitions d’outils peuvent avoir des effets secondaires, c’est pourquoi les étapes de révision et de tests de régression restent intégrées au processus.
Agents avancés pour des tâches à long terme
Pour l’accomplir, l’agent doit planifier, lire des fichiers, récupérer des connaissances, appeler des outils, éventuellement exécuter du code, conserver des résultats intermédiaires, déléguer certaines tâches spécialisées et se souvenir de ce qu’il a déjà appris. La nature de ce travail :
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents est l’outil d’agent de LangChain conçu pour ce type de tâches à long terme. Il regroupe la planification, les outils, la gestion des fichiers, la gestion du contexte, les compétences, la mémoire et les sous-agents, vous évitant ainsi de devoir assembler chaque élément vous-même.
Ce qui est intéressant, ce n’est pas que l’agent puisse faire plus, mais plutôt la manière dont son autonomie est structurée. Fournir à un agent vingt outils ne le rend pas meilleur ; cela aggrave souvent le choix des outils. Diviser chaque tâche en cinq sous-agents n’améliore pas non plus automatiquement l’architecture, car chaque transfert coûte des tokens et peut entraîner une perte de contexte. Plus les éléments constitutifs deviennent performants, plus les décisions de conception relatives à ces éléments prennent d’importance. Une approche utile consiste à n’ajouter un sous-agent que lorsque une sous-tâche nécessite un contexte isolé ou un ensemble d’outils différent, et à garder la liste des outils de chaque agent aussi courte que le permet la tâche.
Gérer des agents est un problème distinct : les agents profonds gérés
Créer un agent fiable et le faire fonctionner de manière stable en production sont deux tâches d’ingénierie distinctes. Un agent qui fonctionne sur le long terme doit être capable de survivre aux interruptions, de conserver son état, de travailler avec des fichiers, d’exécuter du code en toute sécurité, d’afficher l’avancement à l’interface utilisateur, de retenir la mémoire et d’émettre suffisamment de données telemétriques pour que les ingénieurs puissent reconstituer ce qui s’est passé.
Managed Deep Agents, une offre hébergée au sein du même écosystème au moment de la rédaction, vise ce niveau opérationnel. La relation entre les deux peut être représentée comme du comportement en surface et des infrastructures de runtime en dessous :
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
L’agent définit son comportement grâce à la planification, aux outils, aux fichiers et aux sous-agents. La couche gérée assure une exécution fiable, la persistance des données, des environnements isolés, la gestion de la mémoire, le streaming, l’identification et le suivi des activités, ainsi que leur évaluation. Cette leçon s’applique quel que soit le choix entre utiliser un service géré ou mettre en place sa propre solution : l’intelligence de modélisation n’est qu’un composant d’une architecture d’IA en production, et l’infrastructure qui la soutient mérite une attention égale. Notre comparaison des outils d’exécution et des frameworks composés examine le compromis entre développement personnalisé et adoption de solutions prêtes à l’emploi.
Pourquoi les agents brisent les méthodes de test traditionnelles
Les tests conventionnels reposent sur le déterminisme. On fournit à une fonction une entrée connue, on obtient une sortie, puis on vérifie cette dernière.
Input → Function → Output → Assertion
Lorsque l’on appelle une API avec une requête fixe, on peut vérifier le code d’état, le schéma de réponse, la charge utile, les en-têtes ainsi que les règles métier. Les agents ne correspondent pas à ce modèle. Demandez à l’un d’eux d’enquêter sur un incident en production afin de trouver la cause probable. Dans certains cas, il lit d’abord les journaux avant de consulter une base de données ; dans d’autres, il consulte la documentation, appelle une API, puis lit seulement les journaux. Les méthodes diffèrent, mais tous deux peuvent parvenir à une conclusion fiable.
Le cas inverse est également possible et plus dangereux : une réponse qui semble correcte alors que l’agent s’est appuyé sur une source peu fiable, a utilisé un outil inapproprié ou a abouti à la bonne conclusion pour de mauvaises raisons. Une assertion basée sur une correspondance exacte des résultats ne permet pas de distinguer ces cas. C’est là que les évaluations interviennent pour combler cette lacune.
Ce que mesure une évaluation
Une définition pratique : une évaluation mesure dans quelle mesure un système d’IA a performé par rapport aux normes importantes pour une tâche donnée. Les critères proviennent de la tâche elle-même, et non du cadre utilisé.
Prenons un agent qui génère des scénarios de test à partir d’une exigence. Le fait qu’il ait retourné dix cas de test au format JSON valide ne vous dit presque rien. Les indicateurs pertinents concernent la qualité :
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
En pratique, ces dimensions se transforment en questions concrètes :
- Les tests couvrent-ils réellement l’exigence ?
- Chacun d’eux est-il pertinent ?
- L’agent a-t-il inventé des comportements que le produit ne possède pas ?
- A-t-il omis un scénario négatif ou de cas limite important ?
- Faut-il que plusieurs des dix cas soient en réalité des doublons ?
Chaque question peut devenir un critère d’évaluation : certaines sont déterministes (détection des doublons via du texte normalisé ou des embeddings), d’autres nécessitent un ensemble de données de référence (vérification contre des exigences connues), et certaines requièrent généralement un LLM en tant que juge ou des étiquettes humaines (fonctionnalités hallucinées). Les vérifications structurelles telles que la validité du schéma méritent toujours d’être effectuées, mais elles constituent plutôt une base de référence que la définition du succès.
Trois niveaux d’évaluation : réponse, étape et trajectoire
Avec les agents, il n’est pas nécessaire d’évaluer uniquement la sortie finale. Il existe au moins trois cibles utiles :
- La réponse finale : la réponse est-elle correcte, complète et pertinente ?
- Une étape unique : par exemple, l’agent a-t-il choisi le bon outil pour ce sous-problème, en avançant des arguments sensés ?
Voici une trajectoire typique pour un agent de réponse à des questions :
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
La réponse finale n’est autre que le dernier nœud. Pour de nombreuses applications, le parcours est tout aussi important que la destination : par exemple, savoir si l’agent a consulté de la documentation avant d’interroger des données en production, ou s’il a effectué une appel API pour lequel il n’y avait aucune raison. L’évaluation de la trajectoire devient essentielle lorsque les agents peuvent modifier des données, ouvrir des tickets, exécuter du code, déclencher des workflows ou agir au sein de systèmes d’entreprise, car une action intermédiaire nocive constitue un échec même si le message final semble correct. Les vérifications de trajectoire peuvent être strictes (une séquence attendue exacte), indulgentes (les étapes requises présentes dans n’importe quel ordre, les étapes interdites absentes) ou évaluées par un modèle ; des vérifications indulgentes constituent généralement le bon point de départ compte tenu des variations de parcours décrites ci-dessus.
Évaluations hors ligne et en ligne dans une seule boucle
L’évaluation se divise naturellement en deux modes qui correspondent à des pratiques logicielles familières.
Hors ligne : libération des versions pour les cas connus
L’évaluation hors ligne s’effectue à l’aide de jeux de données et de scénarios soigneusement sélectionnés avant toute mise en production. Vous exécutez des cas représentatifs avec la version candidate de l’agent, les évaluez, les comparez à la version actuelle et décidez s’il convient d’être déployé.
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
C’est l’équivalent, pour les agents, d’un ensemble de tests de régression dans les processus CI. Comme les sorties des modèles varient d’une exécution à l’autre, il est utile de traiter chaque cas plus d’une fois et de comparer les distributions des scores plutôt que des résultats individuels.
En ligne : apprendre à partir du trafic réel
L’évaluation en ligne évalue ce qui se passe en production, et c’est justement là que se trouvent les imprévus. Les utilisateurs posent des questions auxquelles personne n’avait pensé, les outils externes tombent en panne, le contexte arrive incomplet, les données changent sous vos yeux, et les agents suivent des trajectoires non présentes dans aucun jeu de données. L’évaluation d’un échantillon de traces en temps réel met en évidence ces cas.
Fermer le cycle
Ces deux modes deviennent bien plus utiles lorsqu’ils sont connectés : chaque défaillance significative en environnement de production détectée en ligne est ajoutée à l’ensemble de données hors ligne, afin que la prochaine version puisse y être testée.
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
Au fil du temps, l’ensemble de données hors ligne cesse de refléter ce que l’équipe imaginait que les utilisateurs feraient pour commencer à refléter ce qu’ils font réellement. Soyez prudent en matière de confidentialité lorsque vous copiez des données de production dans des ensembles de données ; masquez ou synthétisez les champs sensibles avant qu’ils ne deviennent des données de test permanentes.
Le comportement de l’agent en tant que nouvelle dimension de qualité
Rien de tout cela ne remplace les tests traditionnels. Les tests d’interface utilisateur, d’API, d’intégration, de validation des données, de performance et de sécurité restent nécessaires pour tout produit fiable. Les systèmes agents ajoutent une couche supplémentaire : la qualité du comportement de l’agent. Cette couche soulève ses propres questions :
- L’outil qu’il a choisi était-il le bon ?
Organisées en modèle, ces questions diffèrent considérablement de la pyramide des tests classique :
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
La qualité des résultats concerne la correction, la pertinence et l’exhaustivité. La qualité de la trajectoire englobe l’utilisation des outils, les décisions prises et l’efficacité, se divisant en aspects liés à la mémoire (précision et pertinence des informations mémorisées) et en aspects de récupération (gestion des pannes et comportement en cas de tentative échouée). La qualité du contexte couvre son ancrage dans la réalité, sa pertinence et sa fraîcheur. Chaque élément de base peut être associé à un ou plusieurs évaluateurs, et ensemble ils fournissent une image bien plus complète qu’un simple jugement de réussite ou d’échec concernant la réponse finale. Développer ce cadre nécessite de nouvelles pratiques en matière de test des agents, d’observabilité, d’évaluation des trajectoires, de suites de tests de régression pour l’IA, d’évaluation en environnement de production et d’amélioration continue, domaines où les ingénieurs en qualité et les ingénieurs en IA se recoupent de plus en plus. Pour ce qui est de la sécurité dans le cadre du même problème, consultez notre guide sur les garde-fous et le middleware LangChain.
Changements pratiques pour vos propres projets d’agents
La leçon à retenir de tout cela est de ne pas adopter chaque nouvelle fonctionnalité. Il s’agit plutôt du contraire : être plus réfléchi quant à l’architecture.
- Définir des critères d’évaluation lors de la conception de l’agent, et non après sa mise en production.
- Considérer l’observabilité comme faisant partie de l’architecture initiale et non comme un ajout ultérieur.
- Renvoyer les traces de production aux équipes d’ingénierie en tant que retour d’information, et non seulement comme preuves d’incidents.
- S’assurer que chaque défaillance majeure en production fasse l’objet d’une évaluation ultérieure.
- Adapter la complexité au problème. Parfois, un agent simple suffit ; parfois, l’orchestration via LangGraph est justifiée ; parfois, une tâche bénéficie réellement d’agents secondaires, d’un contexte persistant ou d’une plateforme d’agent complète.
La technologie doit suivre le problème, et jamais l’inverse.
Le cycle d’amélioration
Les frameworks viennent et partent ; l’idée durable, c’est un cycle.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
On apprend un concept et on le met en pratique. La mise en œuvre révèle ce que l’on n’a pas compris. Le fonctionnement met en évidence des problèmes que l’on n’avait pas anticipés. L’évaluation remplace les suppositions par des preuves, les preuves stimulent l’amélioration, et cette amélioration révèle généralement ce qu’il reste à apprendre.
Points clés
- Un agent est un système de décisions ; évaluez les décisions, et non seulement le texte final.
- Attribuez à chaque outil une tâche précise : LangChain pour les capacités, LangGraph pour l’orchestration, LangSmith pour l’observation et l’évaluation.
- Évaluez à trois niveaux : la réponse, l’étape et la trajectoire, et privilégiez des vérifications de trajectoire plus souples lorsque les chemins valides varient.
- Reliez les évaluations en ligne et hors ligne afin que les pannes en production deviennent des cas de régression.
Les modèles, les frameworks et les produits hébergés dans ce domaine évoluent rapidement ; consultez donc la documentation actuelle pour en savoir plus sur des fonctionnalités telles que LangSmith Engine et Managed Deep Agents. La discipline consistant à observer, mesurer et à intégrer les enseignements obtenus dans le système est ce qui permettra à vos agents de rester fiables malgré l’évolution constante de leur environnement.