Évaluation des agents IA : le blueprint Motorway expliqué
- Thierry de Lapasse
- 7 days ago
- 6 min read
Un agent IA qui répond vite et avec assurance n'est pas forcément un agent qui répond juste. C'est le constat de départ d'un billet publié par AWS le 23 juillet 2026, qui documente comment Motorway, marketplace automobile britannique, a construit un cadre d'évaluation pour son agent de service client. Le résultat chiffré : un taux d'erreurs divisé par 6, passant d'environ 1 réponse fautive sur 8 à environ 1 sur 50.
Le problème : un agent qui a l'air sûr de lui n'est pas un agent fiable
Le cas Motorway : 8 000 concessionnaires, 2 500 véhicules aux enchères par jour
Motorway connecte des vendeurs particuliers à un réseau de 8 000 concessionnaires britanniques, avec environ 2 500 véhicules mis aux enchères chaque jour, selon les chiffres cités dans le billet AWS du 23 juillet 2026. L'entreprise a déployé un agent conversationnel pour répondre aux questions des vendeurs sur les enchères, les statuts de transaction et le processus de vente. Un agent de ce type ne se contente pas de générer du texte : il appelle des outils, interroge des bases de données, prend des décisions séquentielles. Chaque maillon de cette chaîne est un point de défaillance potentiel.
Les quatre modes de défaillance d'un agent : mauvais outil, mauvaise interprétation sémantique, dérive de contexte, non-déterminisme
Le billet identifie quatre familles de défaillance récurrentes. L'agent peut appeler le mauvais outil, ou le bon outil avec les mauvais paramètres. Il peut mal interpréter le sens d'une requête ambiguë. Il peut perdre le fil d'une conversation longue, une dérive de contexte qui le fait répondre hors sujet après plusieurs échanges. Et il peut, pour une même question posée deux fois, donner deux réponses différentes : c'est le non-déterminisme inhérent aux modèles de langage génératifs. Un test unique, réussi une fois, ne dit rien sur la fiabilité de l'agent le lendemain.
Pourquoi évaluer un agent diffère d'évaluer un LLM
Six dimensions à mesurer : complétion, choix d'outil, cohérence du raisonnement, consistance, sécurité, coût
Évaluer un grand modèle de langage seul revient souvent à mesurer la qualité d'une réponse à une question isolée. Évaluer un agent suppose de suivre une chaîne d'actions. Le blueprint AWS retient six dimensions : la complétion de la tâche demandée, la justesse du choix d'outil à chaque étape, la cohérence du raisonnement qui mène à la décision, la consistance des réponses répétées, la sécurité (absence de fuite de données ou d'action non autorisée), et le coût d'exécution en tokens ou en appels d'API. Un agent peut réussir la tâche tout en coûtant trois fois plus cher que nécessaire, ou en exposant des données qu'il ne devrait pas manipuler.
Le non-déterminisme : pourquoi un test unique ne prouve rien
Le même prompt, envoyé deux fois au même modèle, peut produire deux chemins de raisonnement différents. C'est une propriété structurelle des modèles génératifs, pas un bug ponctuel. En conséquence, un test qui valide une seule exécution ne prouve que cette exécution. La fiabilité se mesure sur des lots répétés, avec un taux de réussite observé sur N tentatives plutôt qu'un verdict binaire réussi/échoué.
Le framework à trois couches et la métrique pass^k
Usage des outils, raisonnement, qualité de sortie
Le cœur du blueprint tient en trois couches d'évaluation, indépendantes de l'outil utilisé pour les implémenter. La première couche vérifie l'usage des outils : l'agent a-t-il appelé la bonne fonction, avec les bons paramètres, au bon moment. La deuxième couche évalue le raisonnement : la séquence de décisions est-elle logique, cohérente avec les informations disponibles à chaque étape. La troisième couche juge la qualité de sortie : la réponse finale est-elle exacte, complète, formulée correctement pour l'utilisateur. Séparer ces trois couches permet d'identifier précisément où un agent échoue, plutôt que de constater un échec global sans savoir s'il vient d'un mauvais outil, d'un mauvais raisonnement ou d'une mauvaise formulation.
pass^k : mesurer la consistance sur plusieurs essais
La métrique centrale du blueprint est notée pass^k : elle mesure la proportion de scénarios pour lesquels l'agent réussit sur k tentatives consécutives, et pas seulement une fois. Un agent qui obtient un pass^1 élevé mais un pass^5 faible est un agent instable : il peut réussir par chance, mais pas de façon fiable. C'est cette métrique qui a permis à l'équipe Motorway de détecter des scénarios où l'agent réussissait occasionnellement tout en échouant systématiquement sur des variantes proches de la même question.
Deux phases : tester avant, surveiller après
Build-time avec strands-agents-evals
Avant la mise en production, l'équipe construit des suites de tests avec le SDK open source strands-agents-evals, disponible sur GitHub depuis le 23 juillet 2026. L'outil permet de définir des scénarios types (une question de vendeur sur le statut de son enchère, une demande de modification de prix de réserve) et de les exécuter en lot pour calculer le pass^k avant tout déploiement. Cette phase de build-time sert à détecter les régressions avant qu'elles n'atteignent un utilisateur réel.
Production avec AgentCore Evaluations et les portes de qualité (quality gates)
Une fois l'agent en production, la surveillance continue avec Amazon Bedrock AgentCore Evaluations, documenté par AWS. Le principe des portes de qualité (quality gates, seuils automatiques qui bloquent ou signalent un déploiement si un score chute sous un plancher défini) permet de ne pas attendre une remontée client pour détecter une dérive. Si le pass^k mesuré en continu descend sous un seuil fixé, l'équipe reçoit une alerte avant que le problème ne s'aggrave. C'est le principe de ce que le secteur appelle le GenAIOps : appliquer à un agent génératif la même discipline d'observation continue qu'à n'importe quel service en production.
Coûts réels et prérequis constatés
Selon le billet AWS du 23 juillet 2026, un cycle d'évaluation coûte entre 5 et 10 dollars, un montant qui dépend directement du nombre de scénarios testés et du nombre de répétitions k choisi pour le calcul du pass^k. Ce coût reste modeste comparé à celui d'un incident en production, mais il n'est pas nul : multiplier les scénarios et les répétitions fait grimper la facture proportionnellement. Le prérequis principal n'est pas financier mais humain : mettre en place ce type de suite de tests demande de la compétence Python et, pour l'implémentation AWS spécifiquement, une familiarité avec l'infrastructure as code de type CDK. Le billet évoque un temps de personnalisation de l'ordre de 2 à 3 heures pour adapter les scénarios de test à un cas d'usage métier propre.
Ce que ce blueprint ne fait pas
Ce framework réduit le risque, il ne l'élimine pas. Un pass^k élevé sur des scénarios de test ne garantit pas qu'un cas imprévu, absent des scénarios couverts, ne provoquera pas une erreur en production. L'évaluation dépend entièrement de la qualité et de la diversité des scénarios écrits par l'équipe : des tests mal conçus donnent une fausse impression de fiabilité.
Le blueprint documenté par AWS s'appuie sur l'écosystème AWS (Strands Agents SDK, Amazon Bedrock AgentCore) : la métrique pass^k et le framework à trois couches sont réutilisables ailleurs, mais l'outillage prêt à l'emploi ne l'est pas.
La mise en œuvre demande des compétences Python et, pour la version AWS, une connaissance de CDK. Ce n'est pas un outil no-code.
Le coût de personnalisation initial, estimé à 2-3 heures selon le cas d'usage, s'ajoute au coût récurrent de 5 à 10 dollars par cycle d'évaluation.
L'évaluation ne remplace pas un audit de sécurité complet : elle mesure des dimensions définies à l'avance, pas tous les risques imaginables.
Un agent évalué reste un système probabiliste : la surveillance continue en production reste nécessaire même après un déploiement validé.
Par où commencer
Cartographier les modes de défaillance de votre agent actuel : listez 15 à 20 scénarios réels tirés de tickets ou de conversations passées, en distinguant choix d'outil, raisonnement et qualité de sortie.
Mettre en place une mesure de pass^k sur ces scénarios, même sans outillage AWS : exécutez chaque scénario 5 fois avec le même agent et calculez le taux de réussite consistant, avant tout déploiement.
Instaurer une porte de qualité simple avant la mise en production suivante : fixez un seuil minimal de pass^k en dessous duquel le déploiement est bloqué, et documentez qui a l'autorité pour lever ce blocage.
Sources
Evaluating AI agents: A production blueprint with Strands and AgentCore — AWS, AWS Machine Learning Blog, 23/07/2026
strands-agents/evals — Strands Agents (AWS), GitHub, 23/07/2026
Evaluations - Amazon Bedrock AgentCore — AWS, AWS Documentation, 23/07/2026
sample-evaluating-agents-on-aws-with-strands-and-agentcore — AWS Samples, GitHub, 23/07/2026
Strands Agents SDK — Strands Agents (AWS), strandsagents.com, 23/07/2026
Cet article a été rédigé et illustré par un système d'intelligence artificielle à partir des sources citées ci-dessus, puis publié automatiquement, sans relecture humaine préalable. Si vous relevez une erreur factuelle, merci de nous la signaler.
Comments