Dans les chapitres précédents, nous avons conçu des agents dotés d'outils, usant de mémoire et répartis à plusieurs. C'est là que beaucoup de développeurs se heurtent à un mur : « je l'ai bien construit, mais je ne sais pas s'il fonctionne vraiment correctement ». Comme un agent fonctionne de façon probabiliste, il n'agit jamais exactement pareil à instruction identique. C'est justement pourquoi « un mécanisme pour mesurer (l'évaluation) » et « un mécanisme pour rendre visible (l'observabilité) » sont vitaux pour une mise en production réelle. Dans ce chapitre, on pose le socle pour saisir la qualité en chiffres, reproduire les échecs et faire tourner l'amélioration en continu.
L'objectif : « améliorer l'agent non à l'instinct, mais sur des chiffres mesurés »
Pourquoi l'évaluation est ce qui compte le plus
Un programme ordinaire renvoie le même résultat pour une même entrée. Mais au cœur de l'agent se trouve un LLM, dont la sortie est probabiliste. À instruction identique, les outils choisis, la marche à suivre et les tournures varient légèrement à chaque fois. Autrement dit, ce n'est pas parce qu'il a bien fonctionné une fois qu'il réussira la fois suivante.
Il y a là un piège propre au développement d'agents. Il marchait à merveille en démo, mais dès qu'un vrai utilisateur formule sa demande un peu différemment, il se brise — ce n'est pas rare. La cause est simple : « ça a marché » ne veut pas dire « c'est correct ». Il a peut-être juste tiré la bonne réponse par hasard, et se trompe peut-être 3 fois sur 10. Pour le savoir, il n'y a qu'à compter.
💡 On ne peut améliorer ce qu'on ne mesure pas. « J'ai l'impression que ça s'est amélioré » n'est pas une amélioration. En changeant le prompt, le taux de réussite a-t-il monté ou baissé ? En ajoutant un outil, n'a-t-on pas rendu les choses inutilement lentes et coûteuses ? Ce n'est qu'en pouvant comparer sur des chiffres qu'on juge si un changement est un progrès ou un recul. L'évaluation n'est pas « un devoir d'après-coup » : c'est le socle du développement.
Autre point important : ne pas remettre l'évaluation à plus tard. Pas besoin d'un dispositif d'évaluation parfait dès le début. Mais si l'on procède en « je construis d'abord, et je penserai à l'évaluation une fois que ça marche », l'évaluation ne se construit en général jamais. Aussi petit soit-il, se mettre à mesurer juste après avoir fait son premier agent est, malgré les apparences de détour, le chemin le plus court. Pour la vue d'ensemble, Le guide pratique de l'évaluation des agents IA ; pour ce que cela désigne au juste, Qu'est-ce que l'évaluation d'agents (evals) sont de bonnes portes d'entrée.
Qu'évalue-t-on — le résultat et la trajectoire
À « évaluer », beaucoup ne pensent qu'à si la réponse finale est juste. C'est bien un point de départ, mais pour un agent cela ne suffit pas. Car « ce qu'il a fait en chemin » compte énormément. Même arrivé à la bonne réponse, s'il a appelé inutilement des outils 10 fois et gaspillé temps et argent, il est inutilisable en pratique. À l'inverse, il arrive que la réponse soit hélas fausse, mais que les décisions en chemin aient été justes.
On répartit donc l'objet de l'évaluation en 4 facettes. Les garder en tête dissipe l'hésitation « je ne sais pas quoi mesurer ».
A-t-il atteint l'objectif confié ? La réponse est-elle exacte, remplit-elle les exigences ? L'indicateur le plus fondamental.
Quels outils, dans quel ordre, et pourquoi les a-t-il appelés ? Le cheminement est-il pertinent ? Y a-t-il des détours ou des étapes superflues ?
A-t-il appelé le bon outil, avec les bons arguments ? N'a-t-il pas appelé un outil inexistant ou laissé passer un échec ?
Volume de tokens, prix et temps consommés par exécution. Est-ce en rapport avec la qualité ?
📊 Mesurer la « trajectoire » est le nerf de l'évaluation d'agents. Là où l'évaluation d'une sortie d'IA ordinaire est une « correction de copie », l'évaluation d'agents regarde « la réponse + le cheminement qui y mène ». Un agent au cheminement brouillon s'effondre facilement dès que les conditions changent un peu. À l'inverse, un agent au cheminement cohérent sait se rétablir même s'il dévie. C'est parce qu'on regarde le cheminement qu'on trouve les leviers d'amélioration.
Les 5 méthodes d'évaluation
« Alors, comment mesurer ? » — c'est ici le cœur de la pratique. Il existe plusieurs méthodes d'évaluation, chacune avec ses forces et ses faiblesses. Plutôt que de s'en tenir à une, la règle est de les combiner selon ce qu'on veut mesurer. Passons en revue les 5 représentatives, avec leurs avantages et inconvénients.
On confronte une « bonne réponse » préparée à la sortie de l'agent et on mesure la concordance. Adapté aux tâches dont la réponse est unique : classification, extraction, calcul.
Avantage : clair, facile à automatiser, sans fluctuation.
Inconvénient : peu utilisable pour les rédactions libres « sans réponse unique ».
On juge mécaniquement sur des conditions fixées : « les mots requis sont-ils présents », « est-ce un JSON valide », « pas de mots interdits ».
Avantage : rapide, peu coûteux, fort pour vérifier format et conditions de sécurité.
Inconvénient : incapable de mesurer une qualité floue comme « le sens est-il juste ».
On donne des critères à un autre LLM et on lui fait évaluer la qualité de la sortie. Permet de mesurer des tâches sans réponse unique : qualité d'un résumé, amabilité d'une réponse.
Avantage : évaluer automatiquement, en masse, rédactions libres et qualité subjective.
Inconvénient : le juge lui-même fluctue / est biaisé. Exige critères explicites et contrôle par échantillonnage humain.
On regroupe des tâches représentatives en un jeu de test et on le fait tourner en bloc à chaque changement. Le mécanisme qui préserve « ce qui passait hier n'a pas été cassé par la correction d'aujourd'hui ».
Avantage : détecter tôt la dégradation (régression) due à un changement.
Inconvénient : constituer et maintenir le jeu de test demande du travail.
Après la mise en ligne, on observe en continu les exécutions des vrais utilisateurs. On suit l'évolution du taux de réussite, du coût et de la latence, et on recueille les évaluations des utilisateurs (👍 / 👎) pour suivre la performance réelle.
Avantage : découvrir les problèmes qui n'apparaissent qu'en conditions réelles et les usages imprévus.
Inconvénient : a posteriori. On ne connaît le problème « qu'une fois survenu ». À combiner avec une évaluation en amont.
⚠️ La combinaison est la base. Format et conditions de sécurité par règles, ce qui a une réponse fixe par confrontation à la vérité terrain, les rédactions libres par LLM-as-judge, à chaque changement par tests de non-régression, et après la mise en ligne par supervision en production. Ne pas chercher à tout couvrir avec une seule méthode. Filtrer l'essentiel avec les méthodes rapides et bon marché (①②) et n'employer les méthodes coûteuses (③) que là où c'est nécessaire permet de maîtriser le coût tout en gardant la précision. Pour plus de détails, voyez Qu'est-ce que l'évaluation de LLM.
Constituer les données d'évaluation (le jeu de test)
Quelle que soit la méthode, le socle est « la matière de ce qu'on mesure » = les données d'évaluation (le jeu de test). C'est en somme un ensemble de tâches représentatives du type « pour telle entrée, je veux tel résultat ». Si c'est pauvre ici, aucune méthode d'évaluation, si belle soit-elle, n'est fiable. À l'inverse, avec un bon jeu de test, 80 % de l'évaluation est comme déjà réussie.
La constitution est simple et suit l'ordre ci-dessous. Plutôt que de viser la perfection, la règle d'or est de commencer petit et faire grandir.
Réunir les demandes susceptibles d'être réellement adressées à l'agent, en incluant cas typiques, cas limites et cas propices à l'échec.
Écrire le « je veux que cela donne ceci » de chaque tâche. Une bonne réponse, des conditions à remplir, ou des critères de notation, au choix.
10 à 20 cas suffisent au début. Privilégier la « qualité » qui reflète la réalité du terrain, plutôt que le nombre.
Ajouter au jeu de test les cas d'échec trouvés en production. Un actif qui devient plus intelligent à l'usage.
✅ Ne sous-estimez pas « seulement 10 cas ». Vous vous direz peut-être « l'échantillon est trop petit pour avoir un sens ». Pourtant, 10 cas choisis avec soin sont bien plus utiles que 1000 cas amassés à la va-vite. Rendre d'abord mesurables 10 cas représentatifs qui posent réellement problème. Cela seul permet de juger sur-le-champ si un changement de prompt ou d'outil va dans le bon ou le mauvais sens. Le jeu de test n'est pas fait une fois pour toutes : c'est un actif vivant, qu'on nourrit d'un cas à chaque échec découvert.
L'observabilité — rendre visible le comportement
Si l'évaluation consiste à « mesurer le bon et le mauvais », l'observabilité consiste à pouvoir « retracer pourquoi c'est arrivé ». Même en constatant à l'évaluation que « le taux de réussite a baissé », si l'on ne peut pas voir ce qui s'est passé à l'intérieur, on ne peut rien corriger. Comme l'agent fait tourner plusieurs étapes en interne, vu de l'extérieur il devient une boîte noire : « on met une entrée, il se passe quelque chose, un résultat sort ». L'observabilité, c'est ouvrir cette boîte pour en voir l'intérieur.
Trois éléments soutiennent principalement l'observabilité.
L'enregistrement d'une exécution du début à la fin. On peut suivre en entier, dans l'ordre chronologique, l'enchaînement « entrée → réflexion → appel d'outil → résultat → décision suivante ».
À chaque étape : quel prompt envoyé, avec quels arguments l'outil appelé, ce qui a été renvoyé. On y laisse aussi la consommation de tokens et le temps écoulé.
Pouvoir retracer à nouveau, avec la même entrée et le même état, une exécution où un problème est survenu. Ce n'est qu'une fois reproductible qu'on peut identifier la cause et valider la correction.
On peut ajouter cela à la main dans les logs, mais en pratique on utilise couramment un outil de traçage. Un outil de traçage capture automatiquement chaque étape de l'agent et la visualise lisiblement en un arbre chronologique. On voit d'un coup d'œil « à quelle étape ça a pris du temps », « où l'appel d'outil a échoué », « à quelle décision il a dévié dans une mauvaise direction ».
📊 La trace, « l'œil du débogage ». Dans l'exemple ci-dessus, l'appel d'outil échoue en ④, et l'agent se rétablit lui-même en ⑤. Vu du seul résultat, c'est un « succès » ; mais la trace révèle une faiblesse : « il se trompe facilement de numéro de colonne ». Cette prise de conscience mène à l'amélioration suivante. L'approche de l'observabilité est expliquée de façon systématique dans Qu'est-ce que l'observabilité de l'IA.
Faire tourner la boucle d'amélioration
L'outillage vu jusqu'ici — évaluation et jeu de test, ainsi qu'observabilité — est utile chacun pris isolément, mais sa vraie valeur apparaît quand on le fait tourner comme une seule boucle. Le développement d'agents n'est pas « construit une fois, terminé » : c'est une œuvre où l'on améliore peu à peu par le cycle mesurer, repérer les faiblesses, corriger, remesurer.
Faire tourner l'évaluation sur le jeu de test et sortir en chiffres le taux de réussite, le coût et la latence.
Lire la trace des exécutions échouées et déterminer où et pourquoi il s'est trompé.
Changer une seule chose touchant la cause : prompt, description d'outil, marche à suivre, répartition.
Réévaluer sur le même jeu de test et vérifier si l'amélioration visée est là et si rien d'autre ne s'est dégradé.
Cette boucle recèle une astuce importante : ne changer, autant que possible, qu'une seule chose à la fois. Si l'on modifie prompt, outils et marche à suivre en même temps, même quand le taux de réussite monte on ne sait plus « quel changement a fait effet ». C'est parce qu'on change une chose à la fois puis on mesure que le lien de cause à effet entre changement et résultat s'établit, et que le savoir s'accumule. C'est modeste, mais c'est la frontière entre « une amélioration au petit bonheur » et « une amélioration sûre ».
✅ Faire tourner la boucle vite et petit. Plutôt qu'une grosse refonte d'un coup, enchaîner de petits changements rapidement et souvent améliore finalement plus vite. Avec 10 cas dans le jeu de test, on mesure aussitôt après un changement. Une fois ce rythme « changer → mesurer aussitôt » acquis, le développement d'agents cesse d'être un pari à l'instinct pour devenir un travail d'ingénierie qui progresse sûrement.
- Un agent est probabiliste et « ça a marché » ne veut pas dire « c'est correct ». Sans mesure, pas d'amélioration.
- Quatre facettes à évaluer — résultat final, trajectoire, appels d'outils, coût et latence. La « trajectoire » est le nerf de l'évaluation d'agents.
- Cinq méthodes — confrontation à la vérité terrain, règles, LLM-as-judge, tests de non-régression, supervision en production — à combiner selon l'objet.
- Les données d'évaluation : des tâches représentatives, en petit nombre. 10 cas soignés valent mieux que 1000 amassés. Nourrir des échecs.
- L'observabilité : trace d'exécution, log de chaque étape, reproduction de l'échec. Rendre visible avec un outil de traçage.
- L'amélioration est la boucle mesurer → repérer les faiblesses → corriger → remesurer. Un changement à la fois, petit et rapide.
Une fois la qualité mesurée et le comportement rendu visible, l'étape suivante est « comment prévenir dérapage, erreur et abus ». Apprenons à manier en sécurité l'autonomie accrue au chapitre 4, « Conception multi-agent ». Passons au chapitre 6, « Garde-fous et sécurité ».