Évaluations d'agents IA : le guide pratique pour mesurer ce qui compte

#Pourquoi évaluer ses agents ?

Tu as construit un agent IA. Il appelle des outils, raisonne sur plusieurs tours, modifie des fichiers, envoie des requêtes. En démo, tout marche. Mais en production, tu découvres des comportements inattendus — et tu ne les vois qu'après coup, quand un utilisateur se plaint.

C'est le piège classique : sans évaluations (evals), tu navigues à l'aveugle. Tu corriges un bug, tu en crées un autre. Tu changes un prompt, et trois cas d'usage cassent silencieusement.

Les évaluations, c'est le filet de sécurité. Elles te permettent de :

• Détecter les régressions avant qu'elles atteignent tes utilisateurs
• Mesurer les améliorations de façon objective, pas au feeling
• Comparer les modèles quand une nouvelle version sort
• Communiquer avec ton équipe sur ce qui marche et ce qui ne marche pas

Anthropic a publié un guide d'ingénierie complet sur le sujet. Cet article en synthétise les concepts clés et les rend actionnables.

#Le vocabulaire des evals

Avant de plonger, posons les bases. Ces termes reviennent partout dans la littérature :

La distinction importante : un agent ne produit pas juste une réponse textuelle. Il modifie un environnement (fichiers, bases de données, APIs). L'évaluation doit vérifier l'état final de cet environnement, pas seulement ce que l'agent dit avoir fait.

#Les trois types de graders

Le grader est le composant central d'une eval. C'est lui qui décide si l'agent a réussi ou échoué. Il en existe trois familles, chacune avec ses forces.

#Graders déterministes (code)

Ce sont des vérifications programmatiques : correspondance de chaînes, regex, exécution de tests unitaires, analyse statique, vérification d'état.

# Exemple : vérifier que l'agent a bien corrigé le bug
def grade_auth_fix(outcome):
    # Le test de sécurité passe-t-il ?
    tests_pass = run_tests(["test_empty_pw_rejected.py"])
    # Le fichier a-t-il été modifié ?
    file_changed = has_diff("src/auth/handler.py")
    return tests_pass and file_changed

Forces : rapides, reproductibles, objectifs, faciles à débugger. Limites : fragiles face aux variations valides. Si l'agent résout le problème d'une manière inattendue mais correcte, le grader peut échouer.

#Graders basés sur un modèle (LLM-as-judge)

Un second LLM évalue la sortie de l'agent selon une rubrique (un ensemble de critères en langage naturel).

# Rubrique : qualité du code
- Le code est-il lisible et bien structuré ?
- Les conventions du projet sont-elles respectées ?
- Y a-t-il des failles de sécurité évidentes ?
- La solution est-elle minimale (pas d'over-engineering) ?

Forces : flexibles, capables de juger des aspects subjectifs (ton, qualité, pertinence). Limites : non-déterministes, plus coûteux, nécessitent une calibration avec des jugements humains.

#Graders humains

Des experts vérifient manuellement un échantillon de résultats.

Forces : gold standard, capturent les nuances qu'aucun grader automatique ne voit. Limites : lents, chers, ne passent pas à l'échelle.

#Quelle combinaison utiliser ?

En pratique, tu combines les trois. La règle : privilégie le déterministe quand c'est possible, utilise le LLM quand c'est nécessaire, et l'humain pour calibrer.

#Evals de capacité vs evals de régression

C'est une distinction fondamentale qui change la façon dont tu interprètes les résultats.

Evals de capacité : elles mesurent ce que ton agent ne sait pas encore bien faire. Le taux de réussite démarre bas (20-30%) et tu cherches à le faire monter. C'est ta "colline à gravir".

Evals de régression : elles vérifient que ton agent continue de faire ce qu'il sait déjà faire. Le taux de réussite doit rester proche de 100%. Toute baisse est un signal d'alarme.

Le cycle naturel : une eval de capacité dont le score atteint 95%+ se transforme en eval de régression. Tu la gardes dans ta suite pour empêcher les régressions, et tu crées de nouvelles evals de capacité pour les prochains défis.

#Gérer la non-déterminisme

Les modèles de langage ne donnent pas toujours la même réponse. Tu lances la même tâche 10 fois, tu obtiens 10 résultats différents. Deux métriques capturent cette réalité :

pass@k : la probabilité d'obtenir au moins un succès en k essais. Plus k augmente, plus le score monte. Utile pour savoir si l'agent peut résoudre le problème.

pass^k : la probabilité que tous les k essais réussissent. Plus k augmente, plus le score baisse. Utile pour savoir si l'agent est fiable.

#Evals par type d'agent

Le design des evals dépend du type d'agent que tu construis.

#Agents de code

Ils écrivent, testent et débuggent du code. La combinaison classique :

1. Tests unitaires (déterministe) : le code produit passe-t-il les tests ?
2. Analyse statique (déterministe) : linting, typage, sécurité
3. Rubrique qualité (LLM) : lisibilité, conventions, minimalisme
4. Vérification du transcript : l'agent a-t-il lu les fichiers pertinents avant de modifier ?

Des benchmarks comme SWE-bench Verified valident cette approche à grande échelle.

#Agents conversationnels

Ils gèrent du support, de la vente, du coaching. L'évaluation doit couvrir deux axes : le résultat (le ticket est-il résolu ?) et la qualité de l'interaction (l'agent a-t-il été empathique, clair ?).

Astuce : simule des utilisateurs avec un second LLM pour tester des scénarios adverses (utilisateur confus, en colère, hors sujet).

#Agents de recherche

Ils collectent et synthétisent de l'information. Le défi : la qualité est subjective et les sources changent.

Combine des vérifications de fondement (les affirmations sont-elles supportées par les sources citées ?), des vérifications de couverture (les faits clés sont-ils présents ?) et des vérifications de qualité des sources (les citations proviennent-elles de sources fiables ?).

#Agents d'utilisation d'ordinateur

Ils interagissent via des captures d'écran, des clics, du clavier. L'évaluation nécessite des environnements sandboxés et vérifie l'état final (le formulaire a-t-il été soumis ? la page affiche-t-elle le bon contenu ?).

#Construire ses evals pas à pas

Voici la feuille de route recommandée par Anthropic.

#Commencer petit

Ne vise pas 500 tâches d'emblée. 20 à 50 tâches tirées de vrais échecs suffisent pour démarrer. En début de développement, les changements ont des effets importants — un petit échantillon suffit pour les détecter.

#Convertir les tests manuels

Tu fais probablement déjà des vérifications avant chaque release — manuellement. Transforme ces vérifications en tâches automatisées. Priorise par impact utilisateur.

#Écrire des tâches sans ambiguïté

Si deux experts du domaine ne sont pas d'accord sur le verdict (réussi/échoué), la tâche est ambiguë. Reformule-la.

Chaque tâche devrait inclure une solution de référence qui prouve qu'elle est résolvable.

#Équilibrer les jeux de tests

Teste les cas positifs (l'agent doit agir) ET les cas négatifs (l'agent ne doit PAS agir). Exemple : une eval de recherche web doit couvrir "quand chercher" ET "quand répondre de mémoire".

#Isoler les environnements

Chaque essai doit démarrer dans un environnement propre. Des fichiers résiduels, du cache, des ressources épuisées introduisent des corrélations parasites qui faussent les métriques.

#Évaluer les résultats, pas les chemins

C'est un principe fondamental : ne vérifie pas la séquence d'étapes. Les agents trouvent régulièrement des approches valides que le concepteur de l'eval n'avait pas anticipées. Si tu imposes un chemin spécifique, tu pénalises la créativité sans raison.

#Lire les transcripts

C'est peut-être le conseil le plus sous-estimé. Lis régulièrement les transcripts de tes evals. Quand une tâche échoue, le transcript révèle si l'agent a fait une vraie erreur ou si le grader a rejeté une solution valide.

#Surveiller la saturation

Une eval dont le score atteint 100% ne mesure plus les progrès — elle ne détecte que les régressions. SWE-bench Verified est passé de 30% à plus de 80% avec les modèles récents. Quand une eval sature, crée-en de nouvelles, plus exigeantes.

#Le modèle Swiss Cheese

Aucune méthode d'évaluation ne suffit seule. Anthropic recommande le modèle Swiss Cheese : empiler plusieurs couches, chacune avec ses trous, pour que les failles d'une couche soient couvertes par les autres.

L'idée : les evals automatisées tournent à chaque commit, le monitoring capture le réel, les reviews humaines calibrent le tout.

#Les outils pour se lancer

Tu n'as pas besoin de construire ton infrastructure from scratch. Plusieurs frameworks open-source accélèrent la mise en place :

• Promptfoo : configuration YAML déclarative, assertions allant du string matching au LLM-as-judge
• Braintrust : évaluation offline + observabilité en production, suivi d'expériences
• LangSmith : tracing, évaluations offline/online, gestion de datasets
• Langfuse : alternative open-source auto-hébergée pour les contraintes de résidence des données

Le framework compte moins que la qualité de tes tâches et l'itération sur tes graders. Choisis celui qui s'intègre le mieux dans ton workflow existant.

#Ce qu'il faut retenir

Les évaluations d'agents ne sont pas un luxe — c'est ce qui sépare le prototypage du produit fiable. Les équipes qui investissent tôt dans leurs evals itèrent plus vite, détectent les régressions avant les utilisateurs, et upgradent vers de nouveaux modèles en jours plutôt qu'en semaines.

Trois principes à garder en tête :

1. Commence petit : 20-50 tâches tirées de vrais échecs, pas un benchmark théorique
2. Évalue les résultats, pas les chemins : laisse l'agent être créatif
3. Empile les couches : evals automatisées + monitoring + humains, pas l'un ou l'autre

Le domaine évolue vite. Les agents gèrent des tâches de plus en plus longues, collaborent entre eux, et traitent des sujets de plus en plus subjectifs. Les techniques d'évaluation devront s'adapter — mais les fondamentaux décrits ici resteront solides.