OutilsAWS ML Blog · 27 avr. 2026, 19:50· 2 min de lecture

Créer des agents Strands avec les modèles SageMaker AI et MLflow

Amazon Web Services a publié un guide technique détaillant la construction d'agents d'intelligence artificielle en combinant trois de ses outils : le SDK open source Strands Agents, les endpoints de modèles Amazon SageMaker AI, et la plateforme d'observabilité MLflow hébergée sur SageMaker Serverless. Le SDK Strands, à approche pilotée par le modèle, permet de créer un agent fonctionnel en quelques lignes de code en associant un modèle de langage, un prompt système et un ensemble d'outils. Les modèles sont déployés via SageMaker JumpStart, un hub machine learning qui permet d'évaluer et de sélectionner rapidement des modèles de fondation selon des critères de qualité et de responsabilité prédéfinis. L'intégration de MLflow permet ensuite de tracer les appels d'agents, de versionner les modèles et d'implémenter des tests A/B entre plusieurs variantes de modèles pour en évaluer les performances à l'aide de métriques objectives.

Cette architecture répond à un besoin concret des grandes entreprises qui ne peuvent pas se contenter des services de modèles entièrement gérés : contrôle précis sur les instances de calcul, politiques de mise à l'échelle, configuration réseau compatible avec les architectures de sécurité existantes, et conformité en matière de résidence des données. Là où Amazon Bedrock simplifie l'accès aux modèles de fondation en masquant l'infrastructure, SageMaker AI laisse à l'organisation la maîtrise de l'endroit et de la manière dont l'inférence se produit, ce qui est décisif pour les secteurs réglementés comme la finance ou la santé. La couche MLflow ajoute une dimension industrielle : les équipes peuvent comparer les performances de différents modèles dans des conditions réelles, réduire les coûts en sélectionnant le modèle le plus efficace pour chaque tâche, et maintenir un historique d'expériences exploitable dans le temps.

La publication de ce guide s'inscrit dans une course plus large pour capter les déploiements d'agents IA en production. AWS répond ainsi à la demande croissante des équipes MLOps qui veulent bénéficier de la commodité du cloud tout en conservant une maîtrise fine de l'infrastructure, une position souvent impossible avec les APIs gérées de type Bedrock ou OpenAI. Strands Agents, rendu open source par Amazon, concurrence directement des frameworks comme LangChain ou CrewAI, avec l'avantage d'une intégration native dans l'écosystème AWS. L'accent mis sur les tests A/B et l'évaluation continue des agents signale que le secteur entre dans une phase de maturité : il ne s'agit plus seulement de faire fonctionner un agent, mais de le mesurer, le comparer, et l'améliorer de façon systématique en production.

Impact France/UE

Cette architecture de déploiement d'agents avec contrôle fin sur la résidence des données répond aux exigences du RGPD, la rendant pertinente pour les secteurs réglementés européens comme la finance et la santé.

Dans nos dossiers

AWS Open weight & Open source OpenAI Agents IA

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog

Monitoring des modèles de machine learning discriminatifs avec Amazon SageMaker AI et MLflow

Amazon Web Services a publié une architecture de référence pour surveiller en production les modèles de machine learning discriminatifs (classification et régression), combinant Amazon SageMaker AI, MLflow et la bibliothèque open source Evidently. Le constat de départ est simple : la précision d'un modèle commence à se dégrader dès la fin de son entraînement, sous l'effet de deux phénomènes distincts. Le premier, appelé dérive des données (data drift), correspond à un changement dans les propriétés statistiques des données d'entrée, par exemple une source de données amont qui change silencieusement le type d'une colonne, ou l'arrivée de nouvelles gammes de produits jamais vues à l'entraînement. Le second, la dérive de modèle (model drift), traduit une perte de justesse des prédictions parce que les motifs probabilistes appris ne correspondent plus à la réalité, un phénomène qui peut survenir par exemple lors d'un changement de comportement des consommateurs dû à une évolution économique. L'architecture proposée couvre tout le cycle de vie, de l'entraînement jusqu'au déploiement, avec un cas d'usage en inférence par lot : un job d'entraînement calcule les métriques du modèle et les stocke dans MLflow, le jeu de données de référence est conservé séparément dans un bucket Amazon S3, puis un job de transformation par lot exécute les prédictions en production dont les résultats sont eux aussi archivés dans S3. Cette approche répond à un besoin concret des équipes qui utilisent des services managés comme SageMaker AI mais qui ont besoin de davantage de flexibilité, que ce soit pour maîtriser les coûts sur l'ensemble du cycle de vie du modèle, pour surveiller des cas d'usage spécifiques non couverts par les outils managés standards, ou pour intégrer la surveillance de modèles dans des tableaux de bord et pipelines d'observabilité déjà existants dans l'entreprise. Concrètement, les résultats produits par cette chaîne de surveillance peuvent alimenter un tableau de bord personnalisé, déclencher des alertes vers des outils comme Slack pour prévenir les équipes concernées, ou même lancer automatiquement un pipeline de réentraînement du modèle dès qu'une dérive significative est détectée. Pour les organisations qui opèrent des modèles critiques en production, cette capacité à réagir avant que la baisse de performance ne devienne problématique représente un enjeu direct de fiabilité et de confiance envers les systèmes d'IA. Ce travail s'inscrit dans la distinction plus large qu'AWS établit entre le monitoring des modèles discriminatifs classiques et celui des grands modèles de langage génératifs, ces derniers faisant l'objet d'une architecture de surveillance séparée et dédiée sur les endpoints d'inférence temps réel de SageMaker AI. La démarche illustre une tendance de fond dans l'industrie du machine learning en production : au-delà du simple déploiement, la capacité à détecter automatiquement les dérives de données et de modèle devient un pilier de la gouvernance des systèmes d'IA, aux côtés des outils d'observabilité plus classiques qui surveillent la latence et la disponibilité des applications. En s'appuyant sur des briques open source comme Evidently plutôt que sur des solutions entièrement fermées, AWS laisse aux équipes techniques la liberté d'adapter la granularité et les métriques de surveillance à leurs propres exigences métier.

OutilsActu

1 source

2AWS ML Blog

« Évaluer les agents IA : un modèle de production avec Strands et AgentCore »

Motorway, une place de marché britannique de voitures d'occasion en ligne, organise chaque jour une enchère où jusqu'à 8 000 concessionnaires se disputent jusqu'à 2 500 véhicules. L'entreprise a collaboré avec l'équipe AWS Prototyping and AI Customer Engineering (PACE) pour développer un agent IA de recherche de stock destiné à ses concessionnaires, capable de remplacer des heures de filtrage manuel par de simples requêtes en langage naturel. Ensemble, elles ont construit un pipeline d'évaluation de bout en bout qui a fait chuter le taux de résultats erronés d'une requête sur huit à une sur cinquante, tout en réduisant le temps de détection des problèmes de plusieurs heures à quelques minutes seulement. L'agent repose sur le SDK Strands Agents combiné à Amazon Bedrock AgentCore, le service entièrement géré d'AWS pour déployer et exploiter des agents IA à grande échelle. Il expose huit outils associant un filtrage structuré sur plus de 89 attributs de véhicules à une recherche par similarité vectorielle, propulsée par la base LanceDB et les embeddings Amazon Titan Text Embeddings V2. Un concessionnaire peut désormais demander « des SUV diesel à moins de 25 000 livres près de mon site » ou « quelque chose de sportif et automatique pour une famille », plutôt que de parcourir des fichiers CSV et des filtres rigides pendant des heures. Le système absorbe environ 1 500 utilisateurs simultanés aux heures de pointe. Cette fiabilité n'est pas un détail cosmétique : de l'argent réel est en jeu à chaque enchère. Une erreur de sélection d'outil par l'agent renvoie de mauvais résultats et érode la confiance des concessionnaires ; une mauvaise interprétation sémantique fait remonter des annonces hors sujet ; une dérive du contexte au fil d'une conversation à plusieurs tours fait perdre les critères affinés par l'utilisateur ; et la nature non déterministe des réponses rend les tests à essai unique peu fiables. Une requête aussi banale que « voitures essence, hybrides et électriques de moins de cinq ans » exige déjà que l'agent interprète correctement plusieurs contraintes combinées. Sans méthode d'évaluation rigoureuse, ces failles restent invisibles jusqu'à ce qu'un concessionnaire tombe sur un résultat absurde, avec un impact direct sur la confiance et, potentiellement, sur les transactions. AWS a publié un dépôt compagnon documentant une méthodologie transposable à d'autres agents, au-delà de son propre écosystème. Elle repose sur une évaluation en deux temps : des tests réalisés en amont du déploiement avec la bibliothèque open source strands-agents-evals, puis une surveillance en production via Amazon Bedrock AgentCore Evaluations. S'y ajoute un cadre à trois niveaux, évaluant l'usage des outils, le raisonnement et la qualité des réponses, ainsi qu'un pipeline de déploiement en cinq étapes doté de portes de qualité qui bloquent une mise en production si les métriques passent sous un seuil défini, notamment via l'indicateur pass^k mesurant la constance des réponses. Le déploiement initial prend de 30 à 45 minutes, son adaptation à un autre domaine deux à trois heures, pour un coût d'environ 5 à 10 dollars de calcul via Bedrock. Le dépôt applique par ailleurs des rôles IAM à privilèges minimaux et stocke les clés API dans AWS Systems Manager Parameter Store plutôt que dans des variables d'environnement.

OutilsActu

1 source

3AWS ML Blog

Traçabilité de bout en bout avec DVC et Amazon SageMaker AI MLflow

Les équipes de machine learning en production font face à un problème récurrent : retracer précisément l'origine d'un modèle déployé. Quelle version du jeu de données l'a entraîné ? Peut-on reproduire à l'identique un modèle mis en production il y a six mois ? Amazon Web Services propose une réponse concrète en combinant trois outils : DVC (Data Version Control), Amazon SageMaker AI et SageMaker AI MLflow Apps. L'architecture s'articule en quatre étapes : un job SageMaker Processing prétraite les données brutes et les versionne via DVC en les poussant vers Amazon S3 ; un job SageMaker Training clone le dépôt DVC à un tag Git précis, récupère le dataset exact via dvc pull, entraîne le modèle et enregistre tout dans MLflow. Chaque run MLflow stocke un identifiant datagitcommit_id, soit le hash DVC pointant vers le dataset exact dans S3. Le modèle entraîné est ensuite enregistré dans le MLflow Model Registry et peut être déployé sur un endpoint SageMaker. La chaîne de traçabilité complète devient alors : modèle en production → run MLflow → commit DVC → dataset dans Amazon S3. Cet enchaînement répond à un besoin critique dans les secteurs régulés : santé, services financiers, véhicules autonomes. Dans ces domaines, les exigences d'audit imposent de relier chaque modèle déployé à ses données d'entraînement précises, et de pouvoir exclure à la demande des enregistrements individuels des futurs cycles d'entraînement. Sans ce niveau de traçabilité, une question apparemment simple, "quelles données ont servi à entraîner le modèle actuellement en production ?", peut mobiliser plusieurs jours d'enquête dans des logs dispersés, des notebooks et des buckets S3. La solution proposée réduit ce risque opérationnel en rendant la traçabilité structurelle plutôt qu'optionnelle. DVC est un outil open source gratuit qui étend Git pour gérer des datasets volumineux et des artefacts ML que Git seul ne peut pas versionner. MLflow, de son côté, assure le suivi des expériences, le registre des modèles et la lignée. Les deux outils couvrent chacun la moitié du problème de traçabilité, et leur combinaison ferme la boucle. L'implémentation requiert un compte AWS avec des permissions sur SageMaker, S3, CodeCommit et IAM, Python 3.11 ou 3.12, et le SDK SageMaker v3.4.0 minimum. Les notebooks utilisent AWS CodeCommit comme backend Git pour les métadonnées DVC, mais l'architecture est compatible avec GitHub, GitLab ou Bitbucket moyennant un simple remplacement de l'URL remote. AWS publie des notebooks d'accompagnement permettant de déployer les deux patterns décrits, traçabilité au niveau du dataset et traçabilité au niveau de l'enregistrement individuel, directement dans un compte AWS existant.

UELa traçabilité structurelle décrite répond directement aux exigences de documentation et d'auditabilité imposées par l'AI Act européen pour les systèmes d'IA à haut risque dans les secteurs régulés (santé, finance, véhicules autonomes).

OutilsTuto

1 source

4AWS ML Blog

Créer un portail personnalisé avec les applications MLflow d'Amazon SageMaker AI intégrées

Amazon Web Services propose une approche architecturale permettant aux équipes de machine learning d'intégrer Amazon SageMaker AI MLflow Apps directement dans un portail interne sur mesure, sans distribuer d'URLs présignées ni accorder d'accès individuels à la console AWS. La solution repose sur quatre composants déployés via AWS Cloud Development Kit (CDK) : un Application Load Balancer (ALB) comme point d'entrée unique, une application React embarquant l'interface MLflow dans un iframe, un reverse proxy Flask tournant sur Amazon EC2, et le service managé SageMaker AI MLflow Apps en backend. L'authentification AWS Signature Version 4 (SigV4) est gérée de façon transparente par le proxy Flask, qui intercepte chaque requête, la signe avec des identifiants temporaires obtenus via un rôle IAM dédié, puis la transmet à l'endpoint MLflow. Le résultat est une URL unique et permanente donnant accès à l'intégralité de l'interface MLflow, y compris le suivi des expériences, les métriques, les paramètres et les artefacts. Pour les équipes data comptant plusieurs dizaines de data scientists, ce modèle résout un problème opérationnel concret : l'impossibilité de distribuer des URLs présignées à grande échelle, et la charge administrative que représente la gestion des accès individuels à la console AWS. En intégrant MLflow au même portail SSO que les autres outils internes, les data scientists n'ont plus besoin de s'authentifier séparément ni de gérer des identifiants AWS. Les pipelines CI/CD et les scripts d'automatisation peuvent également interagir avec l'API REST MLflow via ce même endpoint proxy, sans modification côté client. Pour les responsables infrastructure, cela signifie moins de tickets d'accès, un onboarding simplifié et une surface d'attaque réduite, l'accès direct au service AWS restant invisible pour l'utilisateur final. MLflow s'est imposé comme standard de facto pour le suivi des expériences de machine learning, mais son intégration dans des environnements d'entreprise avec SSO et portails internes reste un point de friction fréquent. AWS, qui a intégré MLflow nativement dans SageMaker il y a moins d'un an, cherche à faciliter son adoption en entreprise en éliminant les barrières opérationnelles. Cette architecture de proxy inverse n'est pas nouvelle, elle s'applique à de nombreux services AWS accessibles via navigateur, mais sa documentation officielle pour MLflow marque une étape vers un usage plus industrialisé. La solution reste cependant incomplète en production : l'implémentation présentée utilise HTTP sans chiffrement, et AWS recommande explicitement d'ajouter HTTPS via AWS Certificate Manager avant tout déploiement réel. L'intégration SSO effective, mentionnée comme cas d'usage principal, n'est pas non plus couverte dans le guide, laissant aux équipes le soin d'assembler cette couche supplémentaire.

OutilsTuto

1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic