Amazon Bedrock AgentCore Evaluation transforme les régressions d’agents en pull requests refusées

Amazon a intégré l’évaluation Amazon Bedrock AgentCore dans un véritable contrôle qualité GitHub Actions, remplaçant les vérifications subjectives des agents par quatre tests notés.

Le pipeline de référence déploie un agent IA et un serveur Model Context Protocol protégé par OAuth, puis sollicite l’agent avec des prompts représentatifs. Il note les traces obtenues et fait échouer la pull request lorsqu’une métrique requise descend sous le seuil configuré.

Cela redéfinit le débat sur les tests d’agents. L’enjeu immédiat n’est pas AWS face à un autre fournisseur cloud. Il s’agit d’évaluations automatisées et reproductibles face aux contrôles manuels ponctuels que de nombreuses équipes de développement utilisent encore avant de fusionner des modifications d’agents.

Amazon a publié cette implémentation le 8 septembre 2026. Le pipeline d’évaluation relie AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK et GitHub Actions.

L’important n’est pas l’ajout d’un tableau de bord de test. Une réponse défaillante peut désormais entraîner l’échec d’un build logiciel, avant qu’un comportement d’agent modifié n’atteigne un environnement partagé ou la production.

Amazon Bedrock AgentCore Evaluation devient une condition de fusion

AWS a fait de la qualité des agents une condition de pull request plutôt qu’une opinion formulée lors de la revue.

Le workflow de référence s’exécute lorsqu’une pull request ciblant la branche principale modifie le code de l’agent, le code du serveur MCP, l’infrastructure ou les scripts d’évaluation. Il crée une pile de développement temporaire contenant deux runtimes AgentCore.

Un runtime héberge un agent fondé sur Strands. L’autre héberge un serveur MCP, qui expose des outils via un protocole standard reliant les applications IA à des capacités externes.

Un pool d’utilisateurs Amazon Cognito partagé protège les deux runtimes. Le workflow déploie cette infrastructure via AWS Cloud Development Kit, puis lit les identifiants des runtimes et les points de terminaison d’authentification dans les sorties du déploiement.

GitHub Actions obtient des identifiants AWS temporaires via une fédération OpenID Connect. OIDC permet à GitHub d’échanger un jeton d’identité de courte durée contre un rôle AWS, évitant ainsi de conserver une clé d’accès AWS permanente dans les secrets du dépôt.

Le workflow stocke toujours l’ARN du rôle AWS comme secret GitHub. Toutefois, les identifiants AWS obtenus sont temporaires et limités par les politiques de confiance et d’autorisation du rôle. GitHub documente ce modèle de sécurité OIDC.

Après le déploiement, le pipeline attend que les deux runtimes soient prêts. Cette attente est importante sur le plan opérationnel, car un runtime nouvellement créé ne peut pas accepter immédiatement des requêtes.

AWS indique qu’un appel précoce renvoie une réponse 424 Failed Dependency. Le workflow fourni interroge le service de contrôle AgentCore et préchauffe le serveur MCP avant de démarrer ses tests.

Le pipeline récupère ensuite un jeton d’accès OAuth et envoie des prompts de test au point de terminaison HTTPS de l’agent. Chaque prompt reçoit un identifiant de session distinct, ce qui permet au processus d’évaluation d’associer les traces émises à la bonne interaction.

L’ensemble de données d’exemple couvre plusieurs types de comportements. Il demande à l’agent de calculer une somme simple, de renvoyer l’heure UTC actuelle, de trouver le cours de l’action Apple et de récupérer un effectif d’employés.

Ces exemples évaluent davantage que la formulation des réponses. Ils testent les capacités intégrées, les outils MCP publics, les outils métier protégés, la sélection d’outils et les paramètres transmis à chaque outil choisi.

Le script d’évaluation applique quatre évaluateurs intégrés :

• GoalSuccessRate détermine si la session a atteint l’objectif de l’utilisateur.

• Correctness compare la réponse aux attentes ou au contexte disponibles.

• ToolSelectionAccuracy vérifie si l’agent a choisi un outil approprié.

• ToolParameterAccuracy vérifie si l’agent a fourni des arguments adéquats.

La configuration de référence utilise 0,8 sur une échelle de zéro à un comme seuil d’acceptation. Si un score requis tombe sous cette valeur, le script se termine en échec et GitHub marque la tâche comme échouée.

Le workflow peut également publier les résultats d’évaluation dans la pull request. Les réviseurs voient l’échec mesuré à côté de la modification du code, au lieu de devoir reconstituer le comportement de l’agent à partir de journaux ou de conversations locales.

Enfin, l’étape de nettoyage s’exécute même lorsque l’évaluation échoue. Elle détruit la pile CDK temporaire afin que les pull requests en échec ne laissent pas des runtimes de développement actifs indéfiniment.

Cette séquence crée la tension centrale. Les tests manuels peuvent révéler un problème évident, mais ils fournissent rarement une règle reproductible que chaque pull request concernée doit respecter.

Pourquoi les tests manuels d’agents sont désormais sous pression

Le pipeline met sous pression les équipes qui considèrent une réponse d’agent comme un élément à inspecter, plutôt que comme un artefact que la livraison logicielle doit valider.

Les tests d’applications traditionnelles produisent des résultats clairs. Une fonction renvoie la valeur attendue, une API respecte un schéma ou une opération de base de données préserve un invariant.

Les agents IA compliquent ce modèle. Leurs réponses peuvent varier, et une phrase finale correcte ne prouve pas que l’agent a suivi un chemin acceptable.

Un agent utilisant des outils peut sélectionner le mauvais service, divulguer un résultat non autorisé ou envoyer des paramètres mal formés. Il peut aussi parvenir à une réponse plausible par une séquence d’appels coûteuse ou non sûre.

Les changements de prompts posent un autre problème. Un léger ajustement des instructions système peut modifier le choix des outils, le comportement de refus, le niveau de détail des réponses ou l’accomplissement des tâches dans des scénarios sans rapport.

Les mises à jour de modèles et les changements de dépendances introduisent des risques similaires. Les tests unitaires classiques peuvent confirmer que l’application s’exécute, tout en passant à côté d’une dégradation significative du comportement.

Les équipes compensent souvent avec des ensembles de prompts manuels. Un développeur saisit plusieurs questions familières, lit les réponses et fusionne les changements lorsque rien ne semble manifestement incorrect.

Cette méthode offre une couverture limitée et un jugement incohérent. Elle fournit également peu d’éléments permettant de savoir quel comportement a changé entre deux révisions.

Le pipeline AWS ajoute un parcours d’évaluation commun à chaque pull request concernée. Il déploie le code proposé, exécute ce code, collecte la télémétrie et applique les mêmes évaluateurs.

AgentCore fonctionne avec des spans OpenTelemetry, qui sont des enregistrements structurés d’appels de modèles, d’activités d’outils et d’autres opérations au sein d’une interaction. AgentCore Observability envoie ces traces vers CloudWatch.

Pour une évaluation à la demande, le pipeline sélectionne les spans d’une session donnée et les transmet au service d’évaluation. Les modes d’évaluation incluent également la surveillance en ligne et l’analyse asynchrone par lots.

Cette distinction est importante pour les équipes de livraison. L’évaluation à la demande convient à une pull request, car elle cible un ensemble réduit et contrôlé d’interactions et renvoie des scores détaillés.

L’évaluation en ligne répond à un autre objectif. Elle échantillonne le trafic déployé et suit le comportement après la mise en production, lorsque les utilisateurs réels formulent des requêtes qu’un jeu de données de test n’avait pas anticipées.

L’évaluation par lots traite de plus grandes collections de sessions. Elle convient mieux aux comparaisons de référence, aux audits périodiques et aux analyses avant/après modification.

Le contrôle de pull request ne remplace pas ces modes. Il rapproche du changement de code le premier point de contrôle mesurable.

Cette approche modifie également la personne qui doit réagir à une régression. Sans contrôle obligatoire, les équipes qualité ou les utilisateurs découvrent souvent le problème après le déploiement.

Avec une vérification GitHub requise, l’auteur doit corriger le comportement défaillant avant la fusion. Le retour arrive alors que les décisions relatives au code et aux prompts concernés sont encore récentes.

C’est particulièrement utile pour les équipes qui maintiennent des agents partagés. Une modification de réponse qui semble acceptable pour un développeur peut casser un workflow d’outils détenu par un autre groupe.

Un jeu de données d’évaluation soigneusement conçu peut préserver ces attentes. Il devient un registre exécutable des tâches que l’agent doit continuer à accomplir.

Les développeurs ont toujours besoin d’accéder au contexte qui sous-tend ces attentes. Une base de connaissances d’ingénierie peut aider les équipes à relier les cas d’évaluation aux spécifications, aux incidents et aux décisions de conception.

Le changement plus large est organisationnel. La qualité des agents devient une partie de la définition d’une modification fusionnable, plutôt qu’une revue facultative réalisée lorsque quelqu’un dispose d’assez de temps.

OAuth rend les tests de bout en bout plus difficiles que le scoring

La partie difficile n’est pas de demander un score d’évaluation. C’est de reproduire le parcours complet des outils d’un agent protégé au sein d’un runner CI sans interface.

L’architecture de référence place à la fois l’agent et le serveur MCP derrière Cognito. Les utilisateurs interactifs s’authentifient via un flux de code d’autorisation et reçoivent des jetons contenant des scopes et des revendications de rôle personnalisées.

Ces rôles déterminent les outils MCP auxquels un utilisateur peut accéder. Un utilisateur de la finance et un utilisateur des ressources humaines ne devraient pas automatiquement recevoir les mêmes capacités métier.

GitHub Actions ne dispose pas d’utilisateur interactif. Il ne peut pas ouvrir un écran de consentement, terminer une connexion dans un navigateur et transporter le contexte de rôle d’une personne tout au long du test.

AWS présente trois manières de gérer cet écart. Chacune valide une partie différente du système.

La première approche évalue des traces stockées. Un processus de staging appelle l’agent au préalable, capture une télémétrie représentative et enregistre ces traces comme fixtures de test.

Les tâches de pull request évaluent les fixtures sans appeler un agent ou un serveur MCP en direct. Cette approche est prévisible et évite le problème d’authentification en CI.

Elle présente aussi une limite importante. Les scores décrivent un comportement précédemment capturé, pas nécessairement le code de l’agent présent dans la pull request actuelle.

Les traces stockées peuvent valider des changements d’évaluateurs ou préserver une référence historique. Elles ne peuvent pas prouver que le code d’exécution nouvellement modifié produit toujours la trajectoire attendue.

La deuxième approche utilise un compte de service dédié. Un opérateur termine une autorisation interactive une fois, puis stocke son jeton de rafraîchissement dans un gestionnaire de secrets.

La CI peut alors agir comme un utilisateur connu avec des rôles définis. Cela permet de tester les limites d’autorisation et l’accès aux outils pour une identité précise.

Les jetons de rafraîchissement expirent ou deviennent invalides. Les équipes doivent prévoir leur rotation, leur réautorisation et un contrôle rigoureux des privilèges du compte.

L’implémentation AWS choisit une troisième voie : l’authentification machine à machine. Cognito émet un jeton via l’autorisation OAuth client_credentials.

Le script d’évaluation envoie l’identifiant client, le secret client et le scope demandé au point de terminaison de jetons de Cognito. Il appelle ensuite AgentCore Runtime via HTTPS avec le jeton porteur renvoyé.

Le middleware MCP distingue ces jetons des jetons utilisateur. Les jetons machine possèdent des scopes, mais aucune revendication de rôle personnalisée ; l’exemple leur permet donc d’accéder à tous les outils.

Les jetons interactifs portent toujours des rôles, et le serveur MCP applique des restrictions au niveau des outils pour ces utilisateurs. Le même pool Cognito prend ainsi en charge à la fois l’accès CI et l’autorisation humaine.

Cette conception permet des tests en direct, de bout en bout, du code présent dans la pull request. L’agent peut appeler le serveur MCP déployé et produire de nouvelles traces à évaluer.

Toutefois, elle ne teste pas l’application des rôles. L’identité CI contourne ces contrôles de rôle par conception.

Cette frontière constitue la réserve la plus importante de l’architecture. Un pipeline validé montre que l’identité machine peut accomplir les tâches évaluées. Il ne montre pas que FinanceUser et HRUser reçoivent des résultats autorisés différents.

Les équipes qui ont besoin de ces deux formes d’assurance doivent ajouter des tests d’autorisation distincts. Elles peuvent utiliser des comptes de service dotés de rôles spécifiques ou des tests directs contre le middleware MCP.

L’identifiant machine devient également un actif sensible. AWS indique que seul le pipeline CI et l’environnement d’exécution de l’agent devraient pouvoir l’obtenir.

Cette affirmation dépend des détails de l’implémentation. Les autorisations du dépôt, les validations de workflow, les politiques IAM, l’exposition des secrets, le comportement des forks et le masquage des journaux influencent tous la véritable frontière de sécurité.

La connexion OIDC de GitHub protège le côté AWS contre les identifiants de dépôt à longue durée de vie. Elle n’élimine pas tous les secrets, car le client OAuth utilise toujours un secret client.

Le rôle IAM doit également respecter le principe du moindre privilège. Un accès de déploiement étendu à Cognito, ECR, aux ressources CDK, Bedrock et AgentCore peut conférer davantage d’autorité qu’un job de pull request de routine n’en nécessite.

Les protections d’environnement peuvent réduire le risque. Les équipes peuvent limiter les branches et workflows qui endossent le rôle, exiger une approbation pour les modifications non fiables et séparer les rôles de déploiement des identités d’évaluation.

L’architecture teste donc conjointement le comportement de l’agent et l’intégration CI. La justesse de l’autorisation reste un objectif d’acceptation distinct.

Le contrôle qualité évalue les traces, pas seulement les réponses

L’évaluation Amazon Bedrock AgentCore est importante, car elle peut juger le parcours de l’agent dans une tâche, et pas uniquement son texte final.

Le script d’évaluation utilise le kit de démarrage AgentCore pour recueillir les traces CloudWatch pertinentes. Il applique ensuite des évaluateurs à la session sélectionnée.

L’API Evaluate brute accepte sessionSpans, une collection d’intervalles de télémétrie appartenant à une session. AWS avertit que le mélange d’intervalles provenant de plusieurs sessions produit une erreur de validation.

Cette frontière de session permet à l’évaluateur de reconstruire une interaction. Il peut examiner l’entrée utilisateur, la sortie du modèle, les outils sélectionnés, les paramètres des outils et la réponse produite.

GoalSuccessRate fonctionne au niveau de la session. Il vérifie si l’interaction complète a atteint l’objectif demandé par l’utilisateur.

Correctness examine la réponse au niveau de la trace. Il peut utiliser une réponse attendue lorsque le test en fournit une.

ToolSelectionAccuracy et ToolParameterAccuracy fonctionnent au niveau de l’appel d’outil. Ils distinguent le choix de la bonne opération de l’appel correct de cette opération.

Cette séparation a produit un résultat instructif dans le test de régression délibéré d’AWS. Les auteurs ont modifié le prompt système afin que l’agent renvoie toujours un refus peu utile.

GoalSuccessRate est tombé à 0.0. Correctness a également obtenu 0.0, tout comme ToolParameterAccuracy.

ToolSelectionAccuracy est toutefois resté à 1.0. L’agent pouvait apparemment identifier un outil approprié tout en échouant à satisfaire la demande globale.

C’est pourquoi une mesure agrégée unique peut masquer des problèmes. Les différents évaluateurs capturent des dimensions indépendantes, et un score réussi ne peut pas compenser tous les comportements défaillants.

Après que les auteurs ont restauré le prompt système prévu, GoalSuccessRate est revenu à 1.0. Correctness a atteint 0.9, tandis que les deux mesures d’outils ont atteint 1.0.

Les quatre ont alors dépassé le seuil d’exemple de 0.8. GitHub a débloqué la pull request.

AgentCore accepte également des entrées de référence pour les tests nécessitant un comportement attendu. Ces entrées peuvent inclure une réponse attendue, des assertions en langage naturel ou une trajectoire d’outils attendue.

Une trajectoire décrit la séquence d’outils qu’un agent doit appeler. AWS propose des évaluateurs d’ordre exact, d’ordre relatif et d’ordre indifférent pour différentes contraintes de workflow.

Un test d’ordre exact convient à un processus où chaque étape dépend de la précédente. Un test d’ordre indifférent convient à des opérations de récupération indépendantes dont la séquence n’affecte pas la justesse.

Le service prend également en charge les évaluateurs personnalisés. Les équipes peuvent définir leurs propres instructions, modèle juge et échelle de notation pour des exigences propres à leur domaine.

Les évaluateurs fondés sur du code offrent une option plus déterministe. Ils invoquent une fonction AWS Lambda capable de vérifier des schémas, motifs, mots-clés ou règles métier.

Cette combinaison compte, car toutes les exigences ne nécessitent pas un juge fondé sur un modèle. La validité JSON, les champs interdits, les nombres maximaux d’appels et les identifiants exacts peuvent souvent être vérifiés par du code classique.

Selon le guide des évaluateurs personnalisés, les évaluateurs peuvent fonctionner au niveau de la session, de la trace ou de l’appel d’outil. La logique personnalisée peut utiliser un modèle ou une fonction Lambda.

Un contrôle pratique doit faire correspondre le type d’évaluateur à l’exigence. La notation fondée sur un modèle convient aux qualités sémantiques telles que la pertinence, la réussite de tâche ou la fidélité.

Le code déterministe convient aux contraintes binaires. Les vérifications de trajectoire d’outils conviennent à la structure attendue du workflow.

Le meilleur signal provient de la combinaison de ces méthodes. Une réponse peut être sémantiquement correcte tout en violant un schéma, et un schéma valide peut malgré tout contenir une réponse non pertinente.

La vérité terrain mérite également une utilisation attentive. Toute réponse acceptable n’a pas une formulation exacte unique, notamment pour les résumés ou les analyses ouvertes.

Les assertions peuvent exprimer les faits ou comportements qui doivent apparaître sans imposer une réponse unique. Les trajectoires attendues peuvent spécifier le comportement des outils indépendamment du style de rédaction.

Cela transforme l’ensemble de tests en plus qu’une simple collection de prompts. Chaque scénario peut définir ce que signifie la réussite aux niveaux de la réponse, de la tâche et des outils.

Un score réussi comporte toujours des angles morts

Le contrôle détecte les régressions définies, mais sa fiabilité dépend de la couverture des tests, de la stabilité des scores, de la conception des identités et du calendrier opérationnel.

AWS indique que le pipeline complet prend environ 10 minutes. Le déploiement, le démarrage de l’environnement d’exécution, la propagation des traces et l’évaluation fondée sur un modèle expliquent cette durée.

Ce délai est acceptable pour de nombreuses pull requests. Il est trop long pour une vérification locale avant commit et peut devenir coûteux dans les dépôts recevant des mises à jour fréquentes.

La disponibilité des traces ajoute de l’incertitude. AWS a observé des délais de propagation de 30 à 90 secondes après l’invocation de l’agent.

Le script de référence réessaie toutes les 30 secondes pendant une durée pouvant aller jusqu’à 10 minutes. Interroger CloudWatch immédiatement peut donc produire un échec apparent avant que la trace n’existe.

L’architecture d’exécution crée un autre obstacle d’implémentation. AgentCore Runtime exige des images de conteneur ARM64, tandis que les runners GitHub hébergés standards utilisent des processeurs x86-64.

Le workflow utilise QEMU et Docker Buildx pour construire des images multiplateformes. Cette exigence augmente le temps de build et introduit un autre point de défaillance possible, sans rapport avec la qualité de l’agent.

La limitation la plus importante provient du jugement fondé sur un modèle. Un évaluateur LLM peut attribuer des scores légèrement différents lorsqu’il évalue la même trace à plusieurs reprises.

Un seuil strict peut donc créer des pull requests instables près de la limite. Une exécution peut réussir à 0.81, tandis qu’une autre échoue à 0.79 sans différence significative dans le code.

AWS recommande de laisser une marge entre le seuil d’acceptation et l’objectif de fiabilité souhaité. Les équipes doivent également mesurer la variance de l’évaluateur avant de rendre un contrôle obligatoire.

Des exécutions répétées peuvent estimer cette variance, mais elles augmentent aussi l’usage de l’évaluation. L’exemple de référence utilise quatre évaluateurs sur cinq prompts, produisant 20 appels au modèle juge pour une pull request.

La source n’attribue aucun prix à ces appels. Elle conseille néanmoins aux équipes de surveiller l’utilisation de Bedrock à mesure que les dépôts et jeux de données se développent.

La couverture des tests présente un problème familier, mais plus aigu. Un contrôle qualité ne mesure que les scénarios inclus dans son jeu de données.

Quatre ou cinq prompts pratiques ne peuvent pas représenter chaque requête de production, état d’autorisation, mode de défaillance, langue ou entrée adversariale.

Le jeton machine de l’exemple peut accéder à tous les outils. Par conséquent, l’exécution de bout en bout ne prouve pas que les outils protégés par rôle restent inaccessibles aux utilisateurs ordinaires.

Un score global peut également masquer des performances inégales. Une moyenne générale peut réussir alors qu’un scénario critique échoue.

Les tâches à haut risque doivent avoir des exigences au niveau des scénarios. Une action sur la paie, une suppression de compte ou une recherche de données personnelles ne devraient pas emprunter leur réussite à plusieurs prompts arithmétiques simples.

Les métriques ont également besoin d’un responsable. Les développeurs doivent savoir qui approuve les modifications de seuil, ajoute de nouveaux scénarios et enquête sur les divergences entre évaluateurs.

Sinon, un contrôle défaillant peut créer une pression pour abaisser le seuil. L’organisation préserve alors la vitesse de livraison en affaiblissant la mesure.

La fausse confiance constitue un autre risque. Une vérification verte montre que la version testée a satisfait des critères spécifiés à un moment donné.

Elle ne certifie pas chaque réponse, n’élimine pas l’injection de prompts et ne valide pas l’infrastructure en dehors de la pile de tests déployée. Elle ne remplace pas non plus un examen de sécurité.

La télémétrie de production reste essentielle, car les utilisateurs trouveront des combinaisons qu’un jeu de données sélectionné a manquées. L’évaluation en ligne d’AgentCore peut échantillonner des sessions réelles et publier les résultats dans CloudWatch.

La documentation des résultats indique que les scores en ligne apparaissent comme métriques CloudWatch. Les événements d’évaluation détaillés sont stockés dans des groupes de journaux dédiés.

L’évaluation par lot peut ensuite comparer des fenêtres plus larges avant et après des modifications de modèle, de prompt ou d’outil. Cette comparaison fournit une référence plus solide qu’une seule exécution de pull request.

Un système mature doit relier ces étapes. Les échecs en production doivent devenir de nouveaux scénarios d’évaluation, et les échecs CI répétés doivent orienter la conception de l’agent.

Le contrôle qualité est le plus crédible lorsque son jeu de données évolue au rythme des incidents. Un benchmark statique finit par récompenser la familiarité avec le test plutôt qu’un comportement fiable.

Ce qu’il faut surveiller après le premier contrôle GitHub Actions

Le prochain test consistera à déterminer si les équipes peuvent rendre ces contrôles suffisamment stables, sensibles à la sécurité et représentatifs pour devenir des vérifications obligatoires.

Le premier signal sera l’adoption d’évaluations fondées sur la vérité terrain et déterministes dans les workflows de pull request. Les quatre métriques intégrées offrent un point de départ utile, mais elles n’expriment pas toutes les règles métier.

Il faudra observer si les équipes ajoutent des réponses attendues, des assertions et des trajectoires d’outils pour les scénarios à forte valeur. Un usage accru des vérifications fondées sur Lambda montrerait que l’évaluation des agents devient une vérification logicielle ordinaire.

Cette évolution renforcerait l’intérêt de l’évaluation Amazon Bedrock AgentCore. Elle réduirait la dépendance à un unique modèle juge et rendrait certaines défaillances plus faciles à reproduire.

Le deuxième signal sera la couverture CI tenant compte des rôles. AWS identifie ouvertement la limite du jeton machine, puisque le flux choisi contourne les vérifications de rôles utilisateur.

Les équipes devraient publier des modèles permettant de tester des identités utilisateur distinctes sans créer d’opérations fragiles de rafraîchissement de jetons. Les comptes de service, les tests d’autorisation directs et les locataires de test isolés sont des pistes plausibles.

Si les contrôles propres aux rôles deviennent courants, l’architecture se rapprochera d’une assurance complète de bout en bout. S’ils restent distincts ou absents, un score vert d’agent en dira peu sur la justesse des autorisations.

Le troisième signal sera le lien entre les contrôles de pull request et les résultats de production. Un petit jeu de données de développement ne peut pas rester représentatif sans retour des sessions réelles.

Il faudra surveiller les workflows qui transforment les traces de production à faible score en cas de régression examinés. La surveillance en ligne doit découvrir les défaillances, tandis que les tests CI sélectionnés doivent empêcher leur retour.

L’outillage d’évaluation des jeux de données d’AWS constitue une autre évolution pertinente. Ses runners de jeux de données peuvent invoquer des agents, attendre la télémétrie et évaluer les scénarios via un processus coordonné.

Une adoption plus large réduirait l’orchestration personnalisée actuellement visible dans le workflow de référence. Elle faciliterait également la maintenance de jeux d’évaluation plus vastes et versionnés.

Pour les développeurs, la question pratique n’est plus de savoir s’il faut tester les réponses des agents. Elle est de déterminer quels comportements doivent bloquer une fusion, lesquels nécessitent une surveillance et lesquels exigent une application déterministe.

Commencez par les défaillances susceptibles d’entraîner un retour en arrière, un incident de sécurité ou la rupture d’un workflow métier. Attribuez à chacune un scénario explicite et une méthode d’évaluation adaptée à son niveau de risque.

Ensuite, provoquez délibérément une défaillance de l’agent et vérifiez que le garde-fou échoue pour la raison attendue. Un contrôle ne devient fiable qu’après avoir détecté une régression connue.

Amazon a proposé une voie crédible pour passer des tests de prompts aux vérifications de statut GitHub obligatoires. La prochaine étape revient aux équipes d’ingénierie : définir les comportements qu’elles refusent de livrer, les encoder et maintenir cette définition à jour.