Évaluation des agents et benchmarking SWE-bench

1. Vue d’ensemble du concept et problème systémique

Le plus grand danger lors du développement de systèmes agentiques en 2026 est la dite « régression comportementale » (Behavioral Regression) :

• Vous modifiez une phrase dans le prompt système pour que l’agent formate mieux le Markdown, mais il cesse soudainement d’appeler l’outil de lecture de fichiers.
• Vous passez du modèle version v1.2 à v1.3, et l’agent commence à générer deux fois plus de commandes shell erronées.
• Sans tests automatisés, les projets agentiques se transforment en « chamanisme », où les développeurs évaluent la qualité du système avec deux ou trois requêtes manuelles dans le chat.

Agent Evals est une discipline d’ingénierie qui transpose les principes classiques du TDD et du CI/CD dans l’univers des agents linguistiques non déterministes. Elle permet de mesurer quantitativement le taux de réussite (Pass Rate), le coût en tokens (Cost per Task) et la latence d’exécution (Latency).

2. Taxonomie architecturale et modèle mental

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMIE D'ÉVALUATION DES AGENTS           │
├─────────────────────────────────────────────────────────────┤
│ 1. Évaluations basées sur l'état (État final de l'environnement) : │
│    • Réussite des tests unitaires / d'intégration (pytest, vitest == 0) │
│    • Vérification des différences dans le système de fichiers (les fichiers requis ont-ils été créés ?) │
├─────────────────────────────────────────────────────────────┤
│ 2. Évaluations basées sur la trajectoire (Évaluation du parcours de raisonnement) : │
│    • Précision des appels aux outils (le bon outil a-t-il été appelé ?) │
│    • Efficacité par étape (en combien d'étapes l'objectif a-t-il été atteint ?) │
│    • Pénalité pour actions redondantes (pénalités pour les répétitions) │
├─────────────────────────────────────────────────────────────┤
│ 3. Évaluations LLM-as-a-Judge (Vérification sémantique par un juge) : │
│    • Ton de la réponse & respect des guides de style        │
│    • Complétude & conformité aux exigences de sécurité      │
├─────────────────────────────────────────────────────────────┤
│ 4. Évaluations des ressources et économiques :              │
│    • Taux de consommation de tokens par problème résolu     │
│    • Temps d'exécution réel (Wall-Clock)                    │
└─────────────────────────────────────────────────────────────┘

3. Pipeline technique et mécanique interne

Un framework typique d’évaluation d’agents (par exemple, Inspect AI, Braintrust ou un Docker Harness personnalisé) fonctionne selon le cycle suivant :

1. Test Environment Reset : Lancement d’un conteneur Docker isolé avec le commit initial de la base de code, où le problème est encore présent.
2. Task Provisioning : L’agent reçoit uniquement la description du bug (issue.md).
3. Agent Trajectory Recording : L’agent exécute des commandes, lit des fichiers et effectue des modifications. Toutes les étapes sont enregistrées au format OpenTelemetry / JSONL (trajectoire des actions).
4. Harness Evaluation :
   • L’orchestrateur récupère le git diff généré.
   • Des tests de vérification cachés (Fail-to-Pass tests) sont exécutés.
   • Le statut est enregistré : RESOLVED, FAILED, TIMEOUT ou OUT_OF_BUDGET.
5. Metric Aggregation : Calcul du pourcentage global de tâches résolues (Resolve Rate) pour la release de l’agent.

4. Scénarios d’ingénierie pratiques en production

01. Gate CI/CD pour la mise à jour des prompts agentiques

Avant la fusion des modifications dans le fichier .cursorrules ou le prompt système du dépôt, une GitHub Action lance 30 tests synthétiques. Si l’agent résout moins de 90 % des tâches, la pull request est automatiquement bloquée.

02. Choix du fournisseur de modèles selon le critère ROI

L’équipe évalue : faut-il payer $15 par million de tokens pour un modèle haut de gamme, ou suffit-il d’un nouveau modèle open source à $0.50 ? Le lancement d’évals sur vos propres 100 tâches donne des chiffres précis : le modèle haut de gamme résout 78 % des tâches, le modèle économique en résout 74 %, mais coûte 20 fois moins cher.

5. Pièges, erreurs courantes et sécurité

• Contamination (Pollution de l’échantillon d’apprentissage) : Les benchmarks publics (comme HumanEval de base) finissent dans les données d’entraînement des nouveaux modèles, ce qui fait que le modèle « mémorise » la bonne réponse sans savoir raisonner. Utilisez uniquement vos propres évals privés ou SWE-bench Verified avec des tâches constamment renouvelées.
• Flaky Evals (Tests instables) : La non-déterminisme lié à la température du modèle peut donner 80 % de succès lors d’une exécution et 65 % lors d’une autre. Il est nécessaire d’effectuer au minimum 3 à 5 runs par évaluation.