Sommaire
Après avoir construit un agent IA, on se heurte toujours au même mur : « D'accord, mais est-ce que ça marche vraiment ? » Vous avez changé le prompt, remplacé le modèle, ajouté un outil — et le mécanisme qui permet de décider si cela a rendu les choses meilleures ou pires avec des données plutôt qu'au feeling, ce sont les evals (évaluations).
Un LLM peut produire une sortie différente à chaque fois pour la même entrée (il est probabiliste). Livrer sur un « ça a l'air de marcher » mène donc à des régressions silencieuses et à des échecs sur les cas limites en production. Cet article couvre ce que sont les evals, cinq façons de mesurer la qualité, l'évaluation propre aux agents, et comment démarrer petit — écrit pour les praticiens.
L'essentiel, en 30 secondes
Si vous ne lisez qu'une chose
1. Pourquoi vous avez besoin d'evals
Un logiciel ordinaire est déterministe : même entrée, même sortie. C'est pourquoi un test unitaire qui vérifie « la sortie correspond-elle à la valeur attendue » fonctionne. Mais un LLM est probabiliste — même une question identique revient formulée ou cadrée un peu différemment à chaque fois. Dans les termes de l'IA agentique vs RPA, ce n'est pas une « main » déterministe mais un « cerveau » probabiliste, si bien que les tests de correspondance exacte ne fonctionnent pas tels quels.
Trois modes de défaillance ont tendance à apparaître ici.
Vous essayez deux ou trois exemples à la main et vous décidez que ça « semble mieux ». Vous ne remarquez jamais qu'un autre cas s'est cassé.
Vous changez un prompt ou un modèle et un seul type d'entrée se dégrade. Vous l'apprenez par une réclamation en production.
« Ça renvoie parfois quelque chose de bizarre. » Comme c'est probabiliste, un seul essai ne le reproduit pas, impossible donc d'en tracer la cause.
Les evals préviennent ces trois maux d'un coup. Préparez un jeu de données d'évaluation, notez l'ensemble à chaque changement, et comparez les scores — cela seul transforme le « feeling » en « données » et rend les régressions visibles. Plus vous déléguez de jugement à un agent, plus les evals deviennent le socle de la qualité, aux côtés des garde-fous.
2. Ce que sont les evals
Les evals (évaluations) = mesurer si la sortie d'une IA ou le comportement d'un agent fonctionne correctement et de façon stable, comme prévu. En termes humains, c'est de la notation. Les briques de base sont simples et se décomposent en trois parties.
L'ensemble d'entrées sur lequel vous évaluez. Rassemblez des exemples d'usage réel, d'anciens journaux et les cas limites attendus.
Comment vous transformez une sortie en score : correspondance exacte, vérifications par règles, ou notation par une autre IA.
Notez l'ensemble et comparez avant vs. après un changement pour décider si c'est mieux ou pire.
Les evals ne sont pas « on construit une fois et c'est fini » — l'essentiel est de les faire tourner comme un test de régression à chaque fois que vous changez un prompt, un modèle ou un outil. Comme du code de test, c'est un actif qu'on fait grandir.
3. Cinq façons de mesurer la qualité
Il existe cinq approches de notation représentatives. La règle empirique est de choisir selon la nature de la tâche et d'en combiner plusieurs.
Préparez la sortie attendue (étiquette de référence) pour chaque entrée et notez par taux de correspondance. Idéal pour les tâches à réponse fixe : classification, extraction, oui/non.
Vérifiez mécaniquement regex, correspondance exacte, validité du JSON, présence des clés requises. Puissant pour vérifier « doit toujours renvoyer ce format » — rapide et bon marché.
Faites noter un autre LLM selon une grille (rubric). Pour les tâches où la réponse n'est pas unique : qualité de résumé, ton, pertinence.
Comparez les scores sur le même jeu de données avant et après un changement de prompt/modèle. Détecte une « régression cachée » où l'ensemble monte mais une partie baisse.
Notez et observez en continu les journaux en direct. Surveillez le taux d'échec, le coût, la latence et la dérive des entrées pour détecter tôt la dégradation.
| Méthode | Convient à | Coût | Objectivité |
|---|---|---|---|
| ① Vérité terrain | Classification, extraction, décisions | Faible | ◎ Élevée |
| ② Par règles | Vérifications de format / structure | Faible | ◎ Élevée |
| ③ LLM-as-judge | Résumé, génération, qualité de dialogue | Moyen | ○ Dépend de la grille |
| ④ Régression | Détecter les régressions dues aux changements | Moyen | ◎ Relative |
| ⑤ Surveillance en production | Détecter la dégradation en direct | Moyen–Élevé | ○ Continue |
La clé, c'est la stratification : « mesurez mécaniquement ce que vous pouvez (① ②), utilisez le LLM-as-judge pour la qualité que vous ne pouvez pas (③), et continuez à le faire tourner via la régression et la production (④ ⑤). » Le LLM-as-judge (③) est pratique, mais le LLM juge lui-même varie, alors rédigez explicitement la grille et, dans la mesure du possible, calibrez-la sur des notes humaines.
4. L'évaluation propre aux agents
Pour une réponse unique (une entrée → une sortie), les cinq ci-dessus suffisent. Mais un agent IA effectue plusieurs étapes, appelle lui-même des outils et prend des décisions en cours de route. Il faut donc évaluer non seulement la sortie finale mais le processus.
A-t-il atteint l'objectif au final (p. ex. effectué la bonne réservation) ? La métrique principale d'un agent.
A-t-il appelé le bon outil, avec les bons arguments, dans le bon ordre ? Repérez les appels erronés ou redondants.
Le chemin des étapes et décisions est-il raisonnable ? Évaluez les détours, les boucles infinies et les nouvelles tentatives inutiles.
À réussite égale, moins de tokens, d'étapes et de latence, c'est mieux. Ça compte en production.
Observer cela nécessite un traçage qui enregistre chaque étape (entrée, raisonnement, appel d'outil, résultat). De nombreux frameworks et les outils ci-dessous livrent traçage et évaluation ensemble. Pour un système multi-agents, conservez des traces hiérarchiques pour repérer quel agent a échoué.
5. Comment démarrer — voir petit
Vous n'avez pas besoin d'une plateforme d'évaluation parfaite dès le premier jour. Démarrer avec un jeu de données de 20 items est réaliste.
- Collectez des exemples d'échec : d'abord, 10 à 20 « entrées qui ont mal tourné ». Les vrais journaux et réclamations sont une mine d'or — c'est le cœur du jeu d'évaluation.
- Décrivez le comportement attendu : associez à chaque entrée une « bonne réponse » ou des « conditions à satisfaire ». Tout n'a pas besoin d'une réponse stricte (mesurez la qualité avec ③).
- Choisissez un scoreur : vérifications de format → ② par règles ; réponse fixe → ① vérité terrain ; qualité → ③ LLM-as-judge. Un ou deux pour commencer, c'est très bien.
- Lancez une fois et fixez une référence : enregistrez le score actuel. C'est votre point de repère.
- Lancez-le à chaque changement : après un changement de prompt/modèle, relancez et comparez avec la régression ④. Si ça baisse, ne livrez pas.
- Ajoutez l'observation en production : une fois en ligne, continuez à surveiller le taux d'échec et le coût avec la surveillance ⑤, et réinjectez les mauvais exemples réels dans le jeu d'évaluation.
💡 Astuce : pondérez votre jeu d'évaluation vers « les échecs que vous ne voulez pas voir arriver » plutôt que « les réussites courantes ». Inclure des cas limites, des entrées adverses et des demandes floues vous permet de vous prémunir de façon proactive contre ce qui casse au changement. Une bonne grille, comme une bonne conception de prompt, devient d'autant plus reproductible qu'elle est concrète.
6. Les pièges courants
- Jeu de données trop petit / trop biaisé : ne collecter que des réussites fait manquer les échecs du monde réel. Mélangez délibérément échecs et cas limites.
- Faire aveuglément confiance au LLM-as-judge : le LLM juge varie aussi et a des biais. Rédigez la grille explicitement et calibrez périodiquement sur des notes humaines. Méfiez-vous de l'auto-complaisance (le même modèle écrit et loue sa propre sortie).
- Ne regarder que la sortie finale : pour les agents, le processus est primordial. Sans appels d'outils, trajectoire et coût, vous bénirez un résultat « obtenu par chance ».
- Décider sur un seul run : puisque c'est probabiliste, pour les evals importantes lancez plusieurs fois et regardez la variance.
- Ne pas mettre à jour les evals : les specs et les usages changent. Continuez d'ajouter les nouveaux échecs de production au jeu d'évaluation.
7. Les outils clés
Vous pouvez démarrer avec vos propres scripts, mais il existe un ensemble croissant d'outils dédiés qui gèrent traçage et évaluation ensemble. Exemples représentatifs (tous des sites officiels).
| Outil | Ce qu'il fait |
|---|---|
| Anthropic Console / Evals | Tester et évaluer des prompts pour Claude dans une interface. Aussi pour comparer les choix de modèle. |
| OpenAI Evals | Un framework open source pour définir et exécuter des evals. La forme de base jeu de données + scoreur. |
| LangSmith | Traçage + évaluation. Enregistre chaque étape de l'agent, jusqu'à la régression et la surveillance en production. |
| Langfuse | Observabilité LLM open source. Traçage, évaluation et surveillance des coûts réunis. |
| Ragas | Évaluation spécialisée pour le RAG (génération augmentée par récupération) : pertinence, fidélité, et plus. |
Quel que soit l'outil, l'essentiel est le même : un jeu de données + un scoreur + la discipline de comparer. Les outils ne font que faciliter cela. Le meilleur départ, c'est un petit jeu d'évaluation, même dans un script sur votre machine.
En résumé
- Ce que sont les evals : de la « notation » qui mesure la sortie et le comportement d'une IA avec des chiffres — décider mieux/pire avec des données, pas au feeling.
- Pourquoi il en faut : les LLM sont probabilistes et varient, si bien que les tests unitaires collent mal et que régressions et cas limites passent inaperçus.
- Cinq méthodes : ① vérité terrain ② par règles ③ LLM-as-judge ④ régression ⑤ surveillance en production. Mesurez mécaniquement ce que vous pouvez, jugez la qualité avec un LLM, et continuez à le faire tourner.
- Les agents ont aussi besoin d'une évaluation du processus : taux de réussite des tâches, appels d'outils, trajectoire, coût. Le traçage en est le prérequis.
- Comment démarrer : 20 exemples d'échec. Fixez-en la référence, puis lancez à chaque changement.
Entre « je l'ai construit » et « c'est utilisable » se trouve un pont appelé evals. Si les garde-fous sont la défense qui arrête les emballements, les evals sont l'attaque qui mesure la qualité et ne cesse de la relever. Un seul petit jeu d'évaluation fait passer le développement d'agents du « feeling » à l'ingénierie.
FAQ
Q. En quoi les evals diffèrent-elles des tests unitaires classiques ?
Les tests unitaires vérifient « la sortie correspond-elle exactement à la valeur attendue ». Mais un LLM est probabiliste et produit une sortie différente à chaque fois, si bien que la correspondance exacte ne fonctionne pas telle quelle. Les evals diffèrent en combinant une mesure adaptée à une sortie probabiliste — vérifications par règles, notation par un LLM, et observation de la variance sur plusieurs runs — par-dessus la correspondance à la vérité terrain.
Q. Peut-on faire confiance au LLM-as-judge (laisser une IA noter) ?
C'est pratique mais pas une baguette magique. Le LLM juge peut varier et être biaisé. Ce qui compte, c'est rédiger une grille concrète, calibrer périodiquement sur des notes humaines, et séparer les rôles/modèles pour la génération et la notation afin d'éviter l'auto-complaisance. La comparaison relative (lequel de A ou B est meilleur) tend à être plus stable que des scores absolus.
Q. Combien d'items d'évaluation me faut-il ?
Vous pouvez très bien commencer avec 10 à 20. Même quelques-uns aident à la comparaison relative « le score a-t-il monté ou baissé après un changement ». Réalistement, faites-le grandir en ajoutant les échecs trouvés en production. Plus important que le nombre : inclure correctement les échecs, exceptions et cas limites.
Q. Faut-il vraiment évaluer la « trajectoire » d'un agent ?
Si vous le faites tourner en production, oui. Même quand la sortie finale est correcte, détours, appels d'outils inutiles et boucles infinies nuisent au coût et à la fiabilité. Ajoutez un traçage qui enregistre chaque étape et regardez le processus aux côtés du taux de réussite des tâches. Plus le cas d'usage implique de permissions et d'effets de bord — comme les cas d'usage d'automatisation métier ou l'automatisation des opérations cloud — plus l'évaluation du processus est rentable.
