Comment évaluer la capacité de planification d'un Agent ? Profondeur de raisonnement, décomposition de tâches et auto-correction

L’évaluation de l’Agent a tourné toute la nuit : 94 % de précision, un résultat flatteur. Déployé en production, onze réclamations utilisateurs en trois jours : la tâche bloque à mi-chemin, boucle infinie sur le même outil, ou étapes importantes sautées.

Les méthodes d’évaluation traditionnelles posent problème. 94 % de précision ne prouve qu’une bonne réponse ponctuelle, pas la capacité à mener une tâche de sept ou huit étapes de raisonnement. Comme un examen à choix multiples pour juger le travail — bonne note, mais incapable d’exécuter.

Comment mesurer la planification d’un Agent ? Pourquoi la précision seule ne suffit-elle pas ? Comment construire un système d’évaluation qui détecte vraiment les problèmes ? Cet article détaille la méthodologie — profondeur de raisonnement, décomposition de tâches, auto-correction — et compare AgentBench, ToolBench, ACPBench.

1. Pourquoi l’évaluation des Agents est plus complexe que celle des modèles ?

L’évaluation d’un modèle est assez directe : une question, une réponse correcte ou non. Choix A ou B, code qui passe les tests, qualité de traduction — beaucoup de dimensions, mais une logique claire.

Un Agent, c’est différent. L’équipe d’ingénierie d’Anthropic l’a souligné dans un billet de 2025 : la capacité d’un Agent est une « capacité de processus », pas une « capacité ponctuelle ». On ne mesure pas « ce qu’il sait », mais « s’il peut prendre une série de bonnes décisions dans un environnement complexe ».

Concrètement, un Agent requiert six capacités fondamentales :

1. Appel d’outils : savoir quand utiliser quel outil, avec les bons paramètres
2. Décomposition de tâches : découper un grand objectif en étapes exécutables, avec des dépendances cohérentes
3. Raisonnement : gérer le raisonnement multi-sauts, pas en une seule étape mais pas à pas
4. Mémoire : conserver le contexte précédent, ne pas oublier la première étape à la deuxième
5. Auto-correction : détecter les erreurs, s’ajuster, ne pas persister aveuglément
6. Planification long terme : enchaîner des dizaines d’étapes sans dévier

Les métriques classiques — précision, F1, BLEU — visent toutes une sortie ponctuelle. Un Agent exige d’évaluer le « processus », et c’est nettement plus complexe.

Exemple concret. Vous demandez à un Agent de réserver un vol Pékin–Shanghai demain après-midi, budget max 800 ¥. La tâche semble simple, mais elle implique :

• Consulter les vols (appel d’outil)
• Filtrer selon les critères (raisonnement)
• S’il n’y a pas de correspondance exacte, décider d’assouplir l’horaire ou le budget (décision)
• Appeler l’API de réservation (outil)
• Gérer les erreurs d’interface (auto-correction)

Une seule étape en échec, la tâche échoue. Mais si vous ne regardez que le résultat final — « réservé ou non » — vous manquez beaucoup d’information. Horaire incorrect, budget dépassé sans que l’Agent s’en rende compte, erreur d’API sans nouvelle tentative.

C’est pourquoi le développement piloté par l’évaluation (eval-driven development) compte autant dans le domaine Agent. Anthropic recommande : concevoir l’évaluation dès le développement, guider l’itération par les métriques, plutôt que découvrir les problèmes après la mise en ligne.

2. Dimensions clés de l’évaluation de la planification

L’évaluation de la planification repose sur trois dimensions : décomposition de tâches, profondeur de raisonnement, cohérence long terme. Un détail pour chacune.

Décomposition de tâches

En bref : l’Agent peut-il découper un grand objectif en petites étapes exécutables, avec des relations logiques entre elles ?

L’indicateur central s’appelle Plan Graph Coherence (cohérence du graphe de planification). On modélise les étapes générées par l’Agent en graphe orienté : chaque nœud est une sous-tâche, chaque arête une dépendance. Deux vérifications :

1. Validité de l’ordre topologique : existe-t-il un ordre d’exécution cohérent, sans « faire B avant A, mais A avant B » ?
2. Absence de cycles : le graphe ne doit contenir aucune boucle

J’ai déjà vu cet échec : demander un rapport d’analyse de données, l’Agent produit :

1. Collecter les données
2. Nettoyer les données
3. Analyser les données
4. Générer le rapport
5. Compléter la collecte selon les résultats d’analyse

Le problème ? L’étape 5 revient à l’étape 1, alors que les étapes précédentes sont déjà passées. L’Agent ne détecte pas la boucle et le flux tourne indéfiniment.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Trois échecs typiques de décomposition :

• Dépendances circulaires : comme l’exemple ci-dessus
• Saut d’étapes : conclusion directe, étapes intermédiaires omises
• Sous-tâches incomplètes : le découpage ne suffit pas à atteindre l’objectif

Profondeur de raisonnement

Cette dimension mesure la capacité à traiter un raisonnement en plusieurs étapes. DeepSeek-V3-0324 atteint 91 % sur les tests multi-sauts, selon son rapport technique. Mais que signifie « multi-sauts » ?

Partir d’un fait connu, dériver la réponse finale en N étapes. Exemple :

• Donné : A > B, B > C
• Question : A ou C est plus grand ?
• C’est un problème à 2 sauts

En production, les chaînes font souvent 5 sauts ou plus. « Trouve le produit le plus vendu le mois dernier, puis analyse pourquoi il performe » :

1. Interroger les ventes du mois passé
2. Trier et identifier le leader
3. Analyser ses caractéristiques
4. Comparer aux autres produits
5. Synthétiser les causes

Chaque étape s’appuie sur la précédente. L’indicateur est la précision multi-sauts, déclinée par nombre de sauts : souvent correct à 3 sauts, effondrement à 5.

Cohérence de planification long terme

Dimension la plus piégeuse. Sur une tâche de 50 étapes, à l’étape 30, l’Agent se souvient-il encore du contexte initial ?

L’indicateur est le State Drift Rate (taux de dérive d’état) : nombre de fois où l’état interne diverge de l’état attendu, divisé par le nombre total d’étapes.

Cas réel : un Agent SAV traite un remboursement, tout va bien, puis l’utilisateur dit « non, je parlais d’une autre commande ». L’Agent se perd, toute la suite porte sur « l’autre commande », alors que le remboursement visé reste le premier. C’est une dérive d’état — perte de l’ancrage contextuel initial dans une longue conversation.

Le State Drift Rate idéal reste sous 0,05 : au plus 5 incohérences sur 100 étapes. En pratique, beaucoup d’Agents open source affichent 0,15 à 0,25 — un écart considérable.

3. Comparaison approfondie des benchmarks majeurs

Les benchmarks Agent sont nombreux, chacun avec son angle. Quatre références principales et des conseils de choix.

AgentBench : le généraliste

AgentBench, publié à ICLR’24 par l’équipe de Tsinghua, couvre le plus large spectre. Il mesure la capacité globale d’un LLM en tant qu’Agent, sur 8 environnements :

• Interaction système d’exploitation
• Requêtes base de données
• Raisonnement sur graphe de connaissances
• Scénario shopping
• Moteur de recherche
• Planification ménagère
• Navigation web
• Jeu vidéo

29 LLM majeurs testés, données comparatives complètes. Pour situer rapidement le niveau d’un modèle, la version simplifiée d’AgentBench suffit.

Limite notable : pas d’évaluation de l’auto-correction. Il teste « réussir du premier coup », pas « détecter et corriger une erreur ». Or l’auto-correction est cruciale en production.

ACPBench : expert en profondeur de raisonnement

ACPBench d’IBM se concentre sur le raisonnement logique en planification. ACP signifie Action, Change, Planning — le nom dit tout.

Sa force : la vérification formelle du raisonnement. Pas seulement le résultat final, mais la conformité du processus aux règues logiques. Pour un itinéraire, chaque étape est validée : préconditions satisfaites, causalité respectée.

Adapté quand vous devez tester en profondeur le raisonnement de planification, pas seulement le résultat. Inconvénient : couverture étroite, surtout logique de planification ; peu d’outils, multimodalité, etc.

ToolBench : spécialiste appels d’outils

ToolBench mesure la capacité d’appel d’API. Pour un Agent outillé — assistant invoquant des API externes — c’est le benchmark le plus pertinent.

Scénarios massifs de planification API, évaluant :

• Choix correct de l’API
• Paramètres corrects
• Enchaînement logique de plusieurs API
• Gestion des échecs d’appel

Très pratique pour évaluer l’usage d’outils.

DeepPlanning : planification longue durée

DeepPlanning cible la planification agentique sur le long terme. Là où d’autres benchmarks s’arrêtent à 5-10 étapes, DeepPlanning teste des chaînes de 20 à 50 étapes ou plus.

Essentiel pour la cohérence long terme : l’Agent se souvient-il de l’objectif initial après des dizaines d’étapes ? Se perd-il en route ? DeepPlanning révèle ces dérives.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Conseils de sélection

Mon conseil : AgentBench pour établir une baseline, puis un benchmark spécialisé selon votre besoin métier. Agent centré outils → ToolBench ; planification complexe → ACPBench et DeepPlanning.

4. Évaluation pratique de l’auto-correction

Ce chapitre est peut-être le plus important. En production, un Agent ne peut pas être infaillible. La question : détecte-t-il ses erreurs ? Peut-il se corriger ?

Pourquoi l’auto-correction compte

Les chiffres parlent. Reflexion, framework de réflexion classique, porte HumanEval de 80 % à 91 % — +11 points, ce n’est pas négligeable. Sur AlfWorld, Reflexion résout 130 défis sur 134, soit 97 %.

"Reflexion est un framework de réflexion qui, après échec, fait analyser à l’Agent la cause et ajuster la stratégie — HumanEval passe de 80 % à 91 %, AlfWorld atteint 97 % (130/134)."

Une étude de l’équipe Galileo montre que la réflexion améliore la résolution de problèmes de 9 % à 18,5 %.

Fonctionnement de l’architecture Reflexion

Le mécanisme est simple, en quatre étapes :

1. Exécution : l’Agent tente la tâche
2. Réflexion : en cas d’échec, analyse de la cause
3. Correction : ajustement de stratégie d’après la réflexion
4. Nouvelle tentative : réessai avec la nouvelle stratégie

Le cœur est la « réflexion » : pas un simple « réessayer », mais expliquer « pourquoi c’était faux » et « comment corriger ». Cela exige une métacognition — examiner son propre raisonnement.

Comment évaluer l’auto-correction ?

Plan opérationnel en trois étapes :

Étape 1 : injecter des erreurs contrôlées

Dans l’environnement de test, provoquer des scénarios d’erreur reproductibles :

• Timeout d’appel d’outil
• Code d’erreur API
• Format de paramètre incorrect
• Ressource inexistante

Étape 2 : observer la réaction de l’Agent

Enregistrer :

• L’Agent détecte-t-il l’erreur ?
• Analyse-t-il la cause ?
• Quelle stratégie de correction adopte-t-il ?
• La correction réussit-elle ?
• Combien de tentatives ?

Étape 3 : calculer les métriques

Trois indicateurs clés :

1. Taux de récupération : proportion d’erreurs corrigées autonomement avec succès final
2. Nombre moyen de tentatives : essais nécessaires de l’erreur au succès
3. Taux d’achèvement final : toutes tâches confondues, y compris celles nécessitant correction

Une bonne évaluation distingue « réussir du premier coup » et « échouer puis corriger » — la première reflète la capacité de base, la seconde l’auto-correction.

Exemple concret

J’ai testé un Agent : interroger la base utilisateurs puis générer un rapport.

Première exécution : requête SQL incorrecte, résultat vide. Deux comportements :

• Sans auto-correction : rapport avec « aucune donnée trouvée » partout
• Avec auto-correction : détecte le résultat vide, réfléchit aux conditions de requête, corrige et réessaie

L’évaluation capture cette différence. Dans le rapport, séparez :

• Taux de succès au premier essai
• Taux de succès après correction
• Taux d’échec définitif

Ces trois chiffres composent le profil complet de l’Agent.

5. Construire votre système d’évaluation Agent

Assez de théorie — voici une architecture en trois couches, directement utilisable.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Architecture en trois couches

Couche 1 : capacités de base

Compétences unitaires, chaque capacité testée isolément :

• Précision des appels d’outils : API et paramètres corrects
• Précision de décomposition sur petites tâches
• Précision de raisonnement en une étape

Approche tests unitaires, chaque test indépendant.

Couche 2 : scénarios métier

Tâches simulant des flux réels :

• Quelques processus métier typiques
• 5 à 15 étapes par flux
• Branches normales et anomalies (scénarios nécessitant correction)

Cette couche teste la combinaison de capacités.

Couche 3 : évaluation globale

Agrégation de tous les résultats :

• Synthèse par dimension
• Score composite pondéré (poids selon l’importance métier)
• Rapport visualisé

Standardisation du flux d’évaluation

Pour un système reproductible :

# Démarrer l'environnement d'évaluation
docker compose -f eval-spec.yml up --build

# Lancer le benchmark, 3 essais pour la moyenne
python run_eval.py --benchmark agentbench-v2.1 --num-trials 3

# Exporter le rapport
python export_report.py --format markdown --output eval_results.md

Point clé : « 3 essais ». La sortie d’un Agent a une part d’aléatoire ; une seule exécution est instable, la moyenne sur plusieurs runs est plus fiable.

Liste des métriques clés

Ces seuils sont des références empiriques. Adaptez-les à votre contexte — certains exigent plus, d’autres peuvent assouplir.

Conclusion

Le message central : l’évaluation Agent ne regarde pas le résultat final, mais la qualité du processus. Les métriques classiques disent seulement « bon ou mauvais » ; un Agent exige une analyse fine — comment il est arrivé là, s’il a pris des détours, s’il s’est corrigé.

Le développement piloté par l’évaluation devrait être la norme. Ne attendez pas la mise en ligne pour découvrir les problèmes : construisez l’évaluation dès le développement et laissez les données guider l’itération.

Pour commencer maintenant :

1. AgentBench pour une baseline — où se situe votre Agent
2. 2-3 benchmarks spécialisés selon votre scénario métier
3. Architecture en trois couches, flux standardisé
4. Évaluation à chaque itération, comparaison par les données

La fiabilité d’un Agent ne se juge pas au feeling — elle se prouve par les métriques. J’espère que cette méthodologie et ce guide pratique vous éviteront quelques pièges.

Références

• Anthropic Engineering: Demystifying evals for AI agents - Blog ingénierie officiel, 2025
• AgentBench: Evaluating LLMs as Agents (ICLR’24) - Équipe Tsinghua, benchmark académique
• Survey on Evaluation of LLM-based Agents - Synthèse arXiv, 2026
• Self-Reflection in LLM Agents - Article Reflexion
• ACPBench: Reasoning about Action, Change, and Planning - Recherche IBM