AWS montre comment construire des agents IA sur SageMaker et tester des modèles via MLflow

Le 27 avril 2026, AWS a publié une description pratique de la façon d'exécuter des agents IA sur sa propre infrastructure gérée, pas seulement sur des services entièrement gérés. L'entreprise a démontré une combinaison de Strands Agents SDK, SageMaker AI et Serverless MLflow, où un agent peut être rapidement assemblé, déployé sur un endpoint, observer son comportement en production et comparer plusieurs variantes de modèle sans modifier l'architecture générale. Pour les équipes qui privilégient le contrôle, les coûts prévisibles et les exigences de sécurité, cela ressemble à une tentative de transformer les systèmes d'agents d'une couche expérimentale en un processus normal de MLOps.

Au cœur de l'approche se trouve Strands Agents SDK, un framework open source pour construire des agents à partir d'un modèle, d'une invite et d'un ensemble d'outils. Dans l'exemple d'AWS, il montre d'abord un scénario basique avec un modèle dans Bedrock, puis transfère la même idée aux modèles exécutés dans SageMaker AI. Le point clé est que Strands peut fonctionner avec les endpoints d'inférence SageMaker comme fournisseur de modèle s'il prend en charge une API de complétion de chat compatible avec OpenAI.

La démonstration utilise deux versions de Qwen3 de SageMaker JumpStart — 4B et 8B. La première est déployée en tant qu'endpoint principal, après quoi l'agent accède à des outils tels que les requêtes HTTP et une calculatrice, et peut exécuter des tâches typiques en haut de sa propre infrastructure de modèle.

Pourquoi déplacer la logique des agents vers SageMaker s'il y a des API prêtes à l'emploi sur le marché ? AWS mise sur quatre arguments. Premièrement — contrôle de l'infrastructure : vous pouvez choisir avec précision les instances, les paramètres réseau et les règles de mise à l'échelle pour la latence et le SLA requis.

Deuxièmement — flexibilité avec les modèles : en plus des foundation models prêts à l'emploi, vous pouvez utiliser des variantes personnalisées ou affinées, ainsi que des modèles open-source. Troisièmement — une économie plus prévisible pour les grandes charges de travail grâce aux endpoints dédiés et à l'ajustement précis des ressources. Quatrièmement — un cadre enterprise approprié autour des agents : traçabilité, versioning, tests A/B et audit, qui sont nécessaires non pas dans les démos mais en production.

AWS souligne séparément l'observabilité. Pour cela, MLflow sans serveur SageMaker AI est utilisé : le service écrit automatiquement les traces d'exécution, les étapes de l'agent, les appels d'outils et les métriques, sans forcer l'équipe à instrumenter manuellement le code avec une télémétrie personnalisée. Après activation d'autolog, les données circulent vers l'interface MLflow, où vous pouvez afficher la liste des exécutions, développer une trace spécifique, voir la boucle Agent, un arborescence de spans, les entrées et sorties de chaque étape.

C'est important non seulement pour le débogage. Ce niveau de transparence est nécessaire quand un agent commence à prendre des décisions dans des processus commerciaux sensibles, et l'équipe doit comprendre exactement où il a échoué, pourquoi il a choisi un outil spécifique et comment son comportement change après une mise à jour du modèle.

La partie la plus pratique du matériel est le test A/B entre variantes de modèles. AWS montre comment attacher deux variations de production au même endpoint, dans l'exemple Qwen3 4B et Qwen3 8B, et diviser initialement le trafic entre eux 50/50. Après cela, vous pouvez comparer les réponses en direct ou créer deux agents séparés, chacun regardant sa propre variante cible.

Ensuite, l'évaluation MLflow GenAI est connectée : l'équipe collecte un ensemble unique de cas de test, définit les attentes en matière de faits et d'outils utilisés, puis exécute les deux variantes via les mêmes scorers. L'exemple utilise à la fois des contrôles déterministes et des métriques LLM-as-a-judge comme la justesse et la pertinence. Ce scénario transforme la sélection du modèle d'un débat sur les sentiments en une procédure reproductible : la nouvelle version ne semble pas seulement plus intelligente, mais passe les mêmes tests, après quoi elle peut être progressivement définie par défaut en changeant les poids.

La conclusion est simple : AWS ne vend pas un autre SDK d'agent, mais un schéma d'ingénierie dans lequel un agent devient un composant de produit géré. Si les entreprises ont besoin de leurs propres modèles, de leur propre périmètre, d'un audit des actions des agents et d'un déploiement soigneux des nouvelles versions, la combinaison Strands, SageMaker et MLflow résout ce scénario beaucoup plus proche de la réalité d'entreprise que de nombreuses piles de démonstration rapides. Pour le marché, c'est un autre signal que la prochaine compétition en IA porte désormais non seulement sur la qualité du modèle, mais sur la qualité de l'infrastructure qui l'entoure.