Fiabilité des agents

Boucle d'évaluation agentique : du prototype à une production fiable

Évaluer des agents IA avec des jeux de tâches, l'analyse des traces, des décisions de mise en production, les retours terrain et une attribution précise des échecs.

10 avril 20265 min de lectureÉvaluation agentiqueAgents IA

Un agent peut réussir une démonstration impressionnante tout en restant dangereux à mettre en production. Les échecs les plus difficiles ne se limitent pas à une mauvaise phrase finale. L'agent peut sélectionner le mauvais outil, transmettre des arguments invalides, répéter une action, ignorer des preuves insuffisantes ou accomplir la tâche en contournant une règle métier. J'évalue donc les agents comme des workflows complets, et non comme des réponses de modèle isolées. Une boucle d'évaluation ne sert pas à produire un score unique. Elle doit transformer les échecs réels en tests reproductibles, rendre les décisions de mise en production explicites et réduire le délai entre un incident et la validation de sa correction.

Commencer par le contrat de la tâche

Avant de choisir les métriques, il faut définir ce qu'est une exécution réussie pour chaque famille de tâches. Un contrat utile précise :

l'intention utilisateur et le contexte nécessaire ;
les outils et effets de bord autorisés ;
les décisions intermédiaires attendues ;
les preuves requises avant de répondre ;
la solution de repli ou le chemin d'escalade acceptable ;
les comportements qui ne doivent jamais se produire.

Pour un agent de consultation documentaire, la réussite peut exiger la bonne source, une réponse sourcée et un refus explicite lorsque les preuves sont insuffisantes. Pour un workflow capable d'agir, le contrat doit aussi couvrir l'autorisation, la validation des arguments, l'idempotence et la confirmation avant toute action irréversible. Le jeu d'évaluation doit représenter ces contrats. Je préfère un ensemble compact de tâches à forte valeur à une grande collection de prompts faciles. Il doit inclure les parcours normaux, les demandes ambiguës, les données manquantes, les pannes d'outils, les frontières de permissions, les instructions adversariales et les régressions déjà observées.

Évaluer la trace, pas seulement la réponse

Un score appliqué uniquement à la réponse finale masque l'endroit où le workflow a échoué. L'évaluation des traces décompose le système en décisions observables :

Couche	Questions à évaluer
Routage	L'agent a-t-il sélectionné le bon workflow et la bonne politique de risque ?
Recherche	A-t-il interrogé la bonne source et conservé les preuves pertinentes ?
Outils	L'outil, les arguments, la séquence et les nouvelles tentatives étaient-ils valides ?
Synthèse	La réponse est-elle sourcée, complète et correctement nuancée ?
Politique	Les règles d'autorisation, de confidentialité et d'escalade ont-elles été respectées ?
Exploitation	Les signaux de latence, de coût et d'échec permettent-ils le diagnostic ?

Certains contrôles doivent rester déterministes. La validité d'un schéma, un appel d'outil interdit, l'existence d'une citation ou une confirmation obligatoire n'ont pas besoin d'un modèle juge. Les dimensions plus subjectives, comme la complétude ou l'utilité, peuvent utiliser des évaluateurs fondés sur une grille, mais ceux-ci doivent être calibrés avec des exemples et revus régulièrement par des humains.

Transformer l'évaluation en décision de mise en production

Une campagne d'évaluation n'est utile que si elle change la décision de l'équipe. J'utilise trois familles de règles :

des blocages stricts pour les échecs de sécurité, de confidentialité, d'autorisation ou d'action destructive ;
des contrôles segmentés pour les intentions critiques, les langues, les sources et les groupes d'utilisateurs ;
des contrôles de tendance pour détecter une régression masquée par une moyenne globale.

Les seuils doivent venir du niveau de risque du produit et d'une référence établie, pas d'un chiffre universel repris d'un autre système. Un assistant interne à faible risque et un agent capable de modifier des données financières ne peuvent pas partager la même politique de mise en production. Chaque critère en échec doit pointer vers un responsable et une trace inspectable. Sinon, l'équipe obtient un tableau de bord rouge sans savoir s'il faut modifier le prompt, la recherche documentaire, le contrat de l'outil, le modèle ou le code applicatif. Le plan d'alertes de régression montre comment transformer ces critères en alertes comparables reliées aux décisions de mise en production et de retour arrière.

La boucle utile est opérationnelle : les signaux de production deviennent des cas reproductibles, puis des corrections vérifiées.

Fermer la boucle avec les retours de production

Les tests réalisés hors production protègent les comportements connus, mais le trafic réel révèle de nouvelles formulations, de nouvelles intentions, des lacunes documentaires et des pannes d'intégration. La boucle de retour d'expérience doit collecter :

les retours utilisateurs associés à leur trace ;
les solutions de repli et escalades humaines ;
les erreurs d'outils, dépassements de délai et appels répétés ;
les recherches documentaires peu fiables et citations manquantes ;
les corrections des experts métier ;
les incidents regroupés par famille de tâches et cause racine.

Toutes les conversations de production ne doivent pas rejoindre le jeu d'évaluation. Les données sensibles doivent être supprimées ou protégées, les doublons consolidés et les comportements attendus explicités. Le résultat est un corpus de régression éditorialisé, pas une archive brute de journaux. Cette discipline opérationnelle apparaît dans mon étude de cas publique sur DAISI, où les traces d'évaluation, les tests d'intégration, les contrôles de sécurité et les tests de charge sont présentés comme des dimensions distinctes de la préparation à la production. Cette étude illustre la démarche de livraison ; la politique d'évaluation exacte reste propre à chaque produit et à son niveau de risque.

Diagnostiquer avant de changer de modèle

Lorsqu'une évaluation échoue, changer immédiatement de modèle est souvent la réponse la plus coûteuse. Je qualifie d'abord l'échec :

contrat incomplet : le comportement attendu n'était pas défini ;
contexte insuffisant : une information requise manquait ou était périmée ;
échec de la recherche documentaire : la bonne preuve n'a pas été trouvée ou classée ;
échec d'orchestration : le workflow a choisi une mauvaise branche ou séquence ;
échec d'outil : une intégration a renvoyé une erreur ou un résultat ambigu ;
échec de génération : le modèle a mal interprété de bonnes preuves ;
échec de politique : un garde-fou ou une confirmation a été contourné ;
échec de l'évaluation : le test ou le juge est lui-même peu fiable.

Cette taxonomie évite d'appliquer un correctif de prompt à un problème de données ou de logiciel. Elle clarifie aussi les responsabilités entre les équipes produit, plateforme, données, sécurité et métier.

Déployer la démarche progressivement

Il faut commencer par un petit jeu de tâches métier critiques et des contrôles déterministes autour des outils et de la sécurité. On ajoute ensuite des grilles d'évaluation des traces uniquement pour les décisions qui nécessitent réellement du jugement. La suite est exécutée à chaque changement significatif du workflow, et les résultats sont conservés avec la version du code et de la configuration. Une fois cette boucle stable, on peut intégrer l'échantillonnage de production, les corrections d'experts et les tableaux de bord segmentés. Elle devient réellement utile lorsque chaque échec sérieux permet de répondre à trois questions : pouvons-nous le reproduire, savons-nous qui en est responsable et pouvons-nous prouver que la correction n'a rien cassé ailleurs ?

Sources et références

Documentation LangSmith sur l'évaluationSuivi des expérimentations, jeux de données, évaluateurs et analyse des traces
Documentation RAGASConcepts d'évaluation de la recherche documentaire et de la génération sourcée
OpenAI EvalsPatterns pour évaluer les modèles et workflows de manière reproductible

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Voir les études de cas Consulter mon CV

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.

7 avril 20265 min de lectureArchitecture agentiqueAgents IA