AWS vient de publier un nouveau service dans Bedrock AgentCore : AgentCore Evaluations, une brique d'évaluation des agents IA en production qui fonctionne quel que soit le framework utilisé pour les construire — LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK, Claude Agent SDK ou Strands Agents. L'annonce, publiée le 26 août 2026 sur le blog Machine Learning d'AWS, répond à un problème très concret pour les équipes qui mettent des agents en production : chaque framework a historiquement son propre outillage d'évaluation, souvent incompatible avec les autres, ce qui rend difficile la comparaison ou la supervision unifiée d'un portefeuille d'agents hétérogène.
Pour les équipes qui industrialisent plusieurs agents construits avec des stacks différentes — un cas fréquent dès qu'une organisation dépasse le stade du POC — cette annonce mérite qu'on s'y arrête.
Le contexte
En production, un agent IA n'est pas un modèle qu'on interroge une seule fois : c'est une chaîne d'appels — raisonnement, appels d'outils, appels au modèle, retours utilisateur — qui peut dériver silencieusement d'une semaine à l'autre. Mesurer sa qualité suppose de capturer cette chaîne complète (ce qu'on appelle une « trace »), puis de la noter selon des critères comme la réussite de l'objectif, la justesse de la réponse ou l'utilité perçue par l'utilisateur final.
Le problème classique : chaque framework agent produit ses traces dans un format qui lui est propre. Historiquement, cela oblige soit à réécrire l'outillage d'évaluation à chaque changement de stack, soit à imposer un seul framework à toute l'organisation — rarement réaliste dans une entreprise qui grandit par acquisitions, par équipes autonomes, ou simplement parce que chaque cas d'usage appelle un outil différent.
Ce n'est pas un problème nouveau en soi : c'est exactement celui qu'a résolu OpenTelemetry pour la télémétrie applicative classique, il y a quelques années. Avant sa large adoption, chaque fournisseur d'APM (monitoring d'applications) imposait son propre agent d'instrumentation, et changer d'outil de supervision signifiait souvent réinstrumenter tout le code. L'écosystème s'est mis d'accord sur un format de trace commun, ce qui a permis à des dizaines d'outils de proposer des vues différentes sur les mêmes données. AWS parie que la même dynamique peut s'appliquer à l'observabilité des agents IA — avec OpenTelemetry, déjà éprouvé ailleurs, comme point de départ plutôt qu'un format maison à faire adopter par tout un écosystème.
Un socle commun : OpenTelemetry
AgentCore Evaluations contourne ce problème en s'appuyant sur OpenTelemetry, le standard ouvert d'instrumentation déjà largement utilisé pour la télémétrie applicative classique (traces, métriques, logs). Les traces d'agents transitent par AWS Distro for OpenTelemetry (ADOT) jusqu'à Amazon CloudWatch, où le service lit trois types de spans :
- les spans d'invocation d'agent — la requête de haut niveau, avec le prompt utilisateur et la réponse finale ;
- les spans d'inférence — les appels au modèle, avec l'historique des messages ;
- les spans d'exécution d'outil — le nom de l'outil appelé, ses paramètres et son résultat.
Pour reconnaître ces spans quel que soit le framework d'origine, le service accepte deux conventions sémantiques en parallèle : les conventions GenAI d'OpenTelemetry (attribut gen_ai.operation.name) et la spécification OpenInference (openinference.span.kind), avec un routage automatique vers le bon gestionnaire selon le préfixe détecté. En clair : tant que votre framework instrumente ses traces selon l'une de ces deux conventions — ce qui est déjà le cas pour LangGraph, l'OpenAI Agents SDK, LlamaIndex, Google ADK, le Claude Agent SDK et Strands Agents — AgentCore Evaluations peut les noter sans adaptation côté équipe.
Les évaluateurs intégrés
Trois évaluateurs sont fournis nativement : GoalSuccessRate (l'agent a-t-il atteint l'objectif de la tâche), Correctness (la réponse est-elle factuellement exacte) et Helpfulness (la réponse répond-elle réellement au besoin exprimé par l'utilisateur). Le service accepte aussi des évaluateurs LLM-as-a-judge personnalisés, pour les critères propres à un métier ou un cas d'usage — un point important pour toute équipe qui a déjà des grilles de notation maison à faire tourner en production plutôt que de repartir de zéro.
Deux modes d'évaluation, deux usages distincts
AgentCore Evaluations propose deux modes complémentaires, pensés pour deux moments différents du cycle de vie d'un agent :
- Le mode à la demande (on-demand), conçu pour les pipelines CI/CD, avec comparaison à une vérité terrain (ground truth). C'est le mode à utiliser avant un déploiement, pour vérifier qu'une nouvelle version de l'agent ne régresse pas sur un jeu de test connu — l'équivalent d'une suite de tests de non-régression, mais appliquée à un système dont les réponses ne sont pas déterministes.
- Le mode continu (online), qui surveille le trafic réel en production à un taux d'échantillonnage configurable. C'est le mode qui permet de détecter une dérive de qualité — un agent qui répond de moins en moins bien à mesure que les données ou les usages évoluent — sans attendre le prochain cycle de release pour s'en apercevoir.
Ce que l'article n'aborde pas encore
Point notable pour qui évalue ce service avant de l'adopter : l'annonce officielle ne cite pour l'instant aucun exemple client concret ni chiffre de performance (taux de faux positifs des évaluateurs, latence d'évaluation, coût par trace évaluée). C'est une brique technique fraîchement documentée, pas encore un retour d'expérience terrain — à garder en tête avant de baser un choix d'outillage dessus sans validation interne.
Comment l'adopter sans tout réinstrumenter
La bonne nouvelle pour une équipe déjà sur l'un des six frameworks supportés : si l'instrumentation OpenTelemetry est déjà active côté framework — ce qui est le cas par défaut pour LangGraph, l'OpenAI Agents SDK, LlamaIndex, Google ADK, le Claude Agent SDK et Strands Agents selon les conventions GenAI ou OpenInference — il n'y a rien à réécrire côté code applicatif pour commencer à envoyer des traces. Le travail se situe plutôt en amont : s'assurer que le pipeline ADOT est bien configuré pour router ces traces vers CloudWatch, puis choisir quels évaluateurs activer et sur quel échantillon de trafic.
Pour une équipe qui a construit son agent maison, sans passer par l'un de ces frameworks, la question à se poser est différente : est-ce que l'instrumentation actuelle suit déjà une des deux conventions supportées, ou faut-il l'adapter ? C'est le scénario où le coût d'adoption est le plus élevé — mais aussi celui où le futur gain est le plus net, puisque n'importe quel outil d'observabilité conforme à OpenTelemetry pourra ensuite lire les mêmes traces, pas seulement AgentCore Evaluations.
Ce que ça change pour les équipes IA
Pour une équipe qui opère un seul agent avec un seul framework, ce service n'est qu'une alternative de plus parmi les outils d'observabilité déjà disponibles sur le marché. Là où AgentCore Evaluations change vraiment la donne, c'est pour les organisations qui gèrent un portefeuille d'agents hétérogène — un agent support client en LangGraph, un agent de recherche interne en LlamaIndex, un agent de code en Claude Agent SDK, par exemple. Sans socle d'évaluation commun, comparer la qualité de ces agents entre eux, ou construire un tableau de bord unique pour un comité de pilotage, demande soit de réécrire l'outillage pour chaque framework, soit d'imposer une seule stack à toute l'organisation — rarement souhaitable quand chaque équipe a de bonnes raisons techniques d'avoir choisi son framework.
Le pari d'AWS avec ce découplage évaluation/framework, via OpenTelemetry comme langue commune, est aussi un signal plus large : la donnée d'observabilité agentique se standardise progressivement, à l'image de ce qui s'est passé pour la télémétrie applicative classique il y a quelques années. Les équipes qui instrumentent proprement leurs agents dès aujourd'hui, avec des spans conformes aux conventions GenAI ou OpenInference, évitent d'avoir à tout reconstruire le jour où elles voudront brancher un outil d'évaluation supplémentaire — celui-ci ou un autre.
Concrètement, pour une équipe qui audite ou industrialise des agents IA, la checklist de conception s'allonge d'un point utile : vérifier, dès les premières lignes de code, que l'instrumentation des traces suit une convention standard plutôt qu'un format propriétaire maison. C'est un choix qui coûte presque rien à la mise en place et qui évite un chantier de migration coûteux plus tard, quel que soit l'outil d'évaluation ou d'observabilité finalement retenu.
Autre implication pratique : la distinction entre mode à la demande et mode continu correspond à deux besoins organisationnels différents, souvent portés par des équipes différentes. Le mode CI/CD parle aux équipes de développement, qui veulent un signal binaire avant de merger une évolution de prompt ou de logique métier. Le mode continu parle aux équipes SRE/MLOps, qui veulent un signal de dérive dans le temps, indépendant de tout déploiement. Un service qui couvre les deux avec la même définition d'évaluateur évite l'écueil classique où le CI dit « ça passe » et la production dérive quand même, faute d'utiliser les mêmes critères des deux côtés.
Il y a enfin une dimension gouvernance à ne pas sous-estimer. Dès qu'une organisation opère plusieurs agents, la question « lequel de nos agents pose le plus de risque en ce moment » devient légitime pour un comité de pilotage ou une équipe sécurité — et elle est indécidable si chaque agent est évalué avec des critères différents, sur des échelles différentes, par des outils différents. Un socle d'évaluation commun ne règle pas la question de savoir quel seuil de qualité est acceptable pour quel cas d'usage — ça reste une décision humaine — mais il rend au moins la comparaison possible, ce qui est le préalable à toute politique de gouvernance sérieuse sur un portefeuille d'agents.
En bref
- AWS a publié AgentCore Evaluations le 26 août 2026 : un service d'évaluation d'agents IA agnostique du framework.
- Il fonctionne avec LangGraph, l'OpenAI Agents SDK, LlamaIndex, Google ADK, le Claude Agent SDK et Strands Agents, via les traces OpenTelemetry (conventions GenAI ou OpenInference).
- Trois évaluateurs intégrés (GoalSuccessRate, Correctness, Helpfulness), plus des évaluateurs LLM-as-a-judge personnalisés.
- Deux modes : à la demande pour le CI/CD avec vérité terrain, continu pour la surveillance de production en temps réel.
- L'intérêt principal : comparer et superviser un portefeuille d'agents construits sur des frameworks différents, sans réécrire l'outillage à chaque fois.
Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.
Photo de couverture : Photo by İsmail Enes Ayhan on Unsplash.