Un guide pratique pour les programmeurs agentiques

Tu ne livrerais pas une application web sans tests. Tu ne déploierais pas une migration de base de données sans l'avoir roulée contre un environnement de staging. Pourtant, chaque jour, des équipes livrent des fonctionnalités propulsées par des LLM avec rien de plus que « on a essayé deux-trois fois, ça avait l'air correct ».

Ça, ce n'est pas tester. C'est espérer.

Les évaluations — les evals — sont la suite de tests des systèmes d'IA. C'est ainsi que tu sais si un changement à ton prompt, à ton modèle ou à ton pipeline de retrieval a réellement amélioré les choses ou si ça t'a juste semblé mieux. WHOOP l'a appris à la dure : un changement de prompt sur leur agent Memory qui semblait meilleur aux tests manuels s'est révélé mesurablement pire quand ils ont roulé leur suite d'evals. Sans evals, cette régression se serait rendue en production.

Ce guide couvre ce que sont les evals, comment les bâtir, et pourquoi la plupart des équipes s'y prennent mal.

Pourquoi l'évaluation des LLM est difficile

Le logiciel traditionnel a des sorties déterministes. Même input, même output. Tu écris des assertions : assertEquals(expected, actual). Fini.

Les LLM sont stochastiques. Pose la même question deux fois, tu pourrais obtenir deux réponses différentes — toutes les deux correctes, formulées autrement. Il n'y a pas de « bonne réponse » unique à comparer. La sortie est en langage naturel, ce qui veut dire qu'évaluer demande du jugement, pas juste du string matching.

Ça mène à trois problèmes qui poussent les équipes à abandonner les evals trop vite :

Pas de ground truth stable. Pour bien des tâches, il y a plusieurs réponses valides. Une réponse du support client peut être correcte dans dix formulations différentes. Les métriques traditionnelles basées sur des références (BLEU, ROUGE) pénalisent les paraphrases valides.

Qualité multidimensionnelle. Une réponse peut être factuellement correcte mais mal écrite, ou magnifiquement écrite mais complètement fausse. Tu dois mesurer l'exactitude, la pertinence, la groundedness, le ton, la sécurité et la complétude — souvent en même temps.

L'évaluation à grande échelle coûte cher. L'évaluation humaine est l'étalon-or mais coûte trop cher pour du développement itératif. Tu ne peux pas faire réviser chaque test case par un humain à chaque changement de prompt.

Aucun de ces problèmes n'est insoluble. Ils demandent juste un autre état d'esprit de testing.

Les trois méthodes d'évaluation

1. Évaluation par code

L'approche la plus simple : écris des vérifications programmatiques sur la sortie. Est-ce que la réponse contient le mot-clé attendu ? Est-elle sous la limite de tokens ? Inclut-elle une citation ? Correspond-elle à un pattern regex ?

Les evals par code sont rapides, déterministes et pas chères. Elles attrapent les défaillances structurelles — le modèle a oublié un champ requis, a dépassé la limite de longueur, ou a retourné du JSON invalide. Elles ne mesurent pas la qualité, mais elles attrapent un nombre surprenant de défaillances en production.

Utilise les evals par code comme première ligne de défense. Elles roulent en CI, ne coûtent rien, et attrapent les régressions immédiatement.

2. LLM-as-a-judge

Utilise un modèle fort (typiquement un modèle frontier comme GPT-4o ou Claude) pour évaluer la sortie de ton système. Tu donnes au juge l'input, l'output, optionnellement une réponse de référence, et une grille de notation. Le juge retourne un score et une explication.

C'est le cheval de trait des frameworks d'evals modernes. Ça scale, c'est relativement peu cher, et bien calibré, ça corrèle étonnamment bien avec le jugement humain. La clé, c'est d'écrire de bonnes grilles. Une grille comme « note la qualité de 1 à 5 » est inutile. Une grille comme « la réponse contient-elle une recommandation spécifique basée sur les données de l'utilisateur, plutôt qu'un conseil générique ? Oui = 1, Non = 0 » est actionnable.

Le framework G-Eval formalise ça : il utilise du chain-of-thought pour générer des étapes d'évaluation à partir de tes critères, puis score la sortie contre ces étapes. DeepEval, Ragas et la plupart des frameworks d'evals modernes implémentent des variantes de cette approche.

Pièges : le modèle juge a ses propres biais. Il tend à préférer les réponses plus longues, le langage formel, et les réponses qui ressemblent à ses propres outputs. Calibre ton juge contre des étiquettes humaines sur un petit ensemble avant de lui faire confiance à grande échelle.

3. Évaluation humaine

Des humains révisent les outputs et les notent contre des critères. C'est la méthode la plus précise et la plus chère. Utilise-la stratégiquement : étiquette 25 à 50 test cases représentatifs pour calibrer tes métriques automatisées, puis n'utilise la revue humaine que sur les outputs flaggés en production.

Le workflow pratique : roule le LLM-as-a-judge sur tout, envoie les échecs et les cas limites à des réviseurs humains, et utilise leur feedback pour améliorer la grille du juge. Ça crée une boucle de rétroaction où l'évaluation humaine devient moins chère avec le temps, pas plus chère.

Bâtir ta suite d'evals

Étape 1 : Définir ce que tu mesures

Avant d'écrire un seul test case, décide de tes métriques. Dimensions courantes pour les systèmes agentiques :

  • Exactitude : le contenu factuel est-il correct ?
  • Groundedness / Fidélité : les affirmations sont-elles soutenues par le contexte récupéré (pour les systèmes RAG) ?
  • Pertinence : la réponse adresse-t-elle vraiment ce qui a été demandé ?
  • Complétude : a-t-elle couvert tous les points importants ?
  • Sécurité : évite-t-elle le contenu nuisible, biaisé ou contraire aux politiques ?
  • Exactitude de l'utilisation d'outils : l'agent a-t-il appelé les bons outils avec les bons arguments ?
  • Complétion de tâche : l'agent a-t-il atteint l'objectif énoncé ?

Pour les systèmes RAG spécifiquement, mesure le retrieval et la génération séparément. Les métriques de retrieval (précision, rappel, pertinence des chunks récupérés) te disent si ta recherche fonctionne. Les métriques de génération (fidélité, qualité de la réponse) te disent si le modèle utilise bien le contexte. Si tu ne mesures que la réponse finale, tu ne peux pas diagnostiquer si une mauvaise réponse vient d'un mauvais retrieval ou d'une mauvaise génération.

Étape 2 : Bâtir ton dataset

Un bon dataset d'evals a trois propriétés :

  1. Représentatif de la production. Ne teste pas sur des questions propres et bien formées si tes utilisateurs tapent des requêtes brouillonnes avec des fautes et des références ambiguës.
  2. Couvre les cas limites. Inclus des inputs adversariaux, des questions hors scope, des questions sans bonne réponse, et des inputs conçus pour déclencher des modes de défaillance connus.
  3. Étiqueté avec les résultats attendus. Pas nécessairement une « bonne réponse » unique, mais au minimum une classification de ce à quoi ressemble une bonne réponse — faits requis, affirmations interdites, formats acceptables.

Commence petit. 25 à 50 test cases de haute qualité, étiquetés par un expert du domaine, valent plus que 1 000 générés automatiquement. Tu peux élargir plus tard avec de la génération de données synthétiques, mais le set de calibration initial doit être curaté par des humains.

WHOOP a bâti des « Personas » synthétiques — des profils de membres reproductibles avec des caractéristiques de données spécifiques — pour tester leurs agents contre des scénarios réalistes. Cursor utilise les signaux réels d'acceptation/rejet des utilisateurs comme données d'evals. Les deux approches fonctionnent ; la bonne dépend de si tu as déjà des données de production.

Étape 3 : Automatiser et intégrer

Les evals devraient rouler automatiquement à chaque changement. Traite-les comme des tests unitaires :

# Using DeepEval (pytest-style)
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric

def test_refund_policy_question():
    test_case = LLMTestCase(
        input="What is the refund policy for enterprise customers?",
        actual_output=get_model_response("What is the refund policy for enterprise customers?"),
        retrieval_context=["Enterprise customers can request a full refund within 30 days..."]
    )
    metric = AnswerRelevancyMetric(threshold=0.7)
    assert_test(test_case, [metric])

Roule les evals en CI/CD. Bloque les déploiements sur les résultats des evals. Suis les métriques dans le temps pour attraper le drift. C'est exactement ce que WHOOP fait avec AI Studio — chaque déploiement d'agent passe par une porte d'évaluation avant d'atteindre les utilisateurs.

Étape 4 : Monitorer en production

Les evals pré-déploiement attrapent les régressions. Le monitoring en production attrape les défaillances que tu n'avais pas anticipées. Échantillonne 1 à 5 % des outputs en production et roule tes métriques d'evals. Flague les outputs où les utilisateurs ont donné un feedback négatif. Envoie les outputs faiblement notés en revue humaine.

Tab RL chez Cursor pousse ça à l'extrême : chaque suggestion acceptée ou rejetée est un signal d'eval en production qui réentraîne le modèle plusieurs fois par jour. Tu n'as pas besoin d'aller aussi loin, mais il te faut un signal quelconque de l'usage en production qui revient nourrir ton dataset d'evals.

Erreurs courantes

Évaluer trop tard. Les équipes bâtissent tout le système, puis ajoutent les evals après coup. Rendu là, tu as pris des décisions architecturales dont tu ne peux pas mesurer l'impact. Commence par les evals. C'est ta boussole.

Mesurer la mauvaise chose. Optimiser pour une métrique qui ne corrèle pas avec la satisfaction des utilisateurs est pire que de ne rien mesurer. Aligne tes métriques avec les résultats d'affaires : taux de résolution de ticket, rétention des utilisateurs, taux de complétion de tâche — pas des scores de qualité abstraits.

Faire aveuglément confiance au juge. Les juges LLM ont des modes de défaillance. Ils manquent des erreurs factuelles dans des domaines qu'ils ne comprennent pas. Ils ne savent pas compter. Ils préfèrent les réponses verbeuses. Calibre ton juge contre des étiquettes humaines, et recalibre périodiquement.

Évaluer seulement la sortie finale. Dans les systèmes agentiques avec du raisonnement multi-étapes, des appels d'outils et du retrieval — évalue chaque étape indépendamment. Une réponse finale correcte qui a utilisé le mauvais outil ou récupéré les mauvais documents, c'est un système qui va échouer sur des inputs légèrement différents.

À retenir

Les evals ne sont pas optionnelles. Ce n'est pas un luxe pour équipes matures. C'est le mécanisme par lequel tu sais si ton système fonctionne. Sans elles, chaque changement est un coup de dés.

La bonne nouvelle : tu n'as pas besoin d'une plateforme d'évaluation sur mesure pour commencer. Un chiffrier avec 30 test cases étiquetés et un script qui roule ton modèle contre eux, c'est un framework d'évaluation légitime. WHOOP a commencé avec des chiffriers. Toi aussi, tu peux. Commence, point.

Pour aller plus loin