Amazon SageMaker AI : l'inférence asynchrone supporte désormais les payloads intégrés

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.

Amazon SageMaker AI prend en charge l'API compatible OpenAI

Amazon a annoncé ce mois-ci que SageMaker AI supporte désormais une API compatible avec celle d'OpenAI pour ses endpoints d'inférence en temps réel. Concrètement, les développeurs qui utilisent le SDK OpenAI, LangChain ou le framework Strands Agents peuvent désormais router leurs appels vers des modèles hébergés sur SageMaker AI en changeant uniquement l'URL de l'endpoint. Plus besoin de client personnalisé, de wrapper SigV4, ni de réécriture de code. Les endpoints SageMaker exposent un chemin /openai/v1 qui accepte les requêtes au format Chat Completions et renvoie les réponses du conteneur telles quelles, y compris en streaming. L'authentification repose sur des tokens bearer à durée limitée (jusqu'à 12 heures), générés à partir des credentials AWS existants via le SDK Python SageMaker, sans clé API supplémentaire. Ce changement simplifie radicalement l'intégration de SageMaker dans les stacks d'IA existantes. Pour les équipes qui orchestrent des agents multi-LLM via une gateway (comme Bifrost, mentionnée par Giorgio Piatti, ingénieur ML chez Caffeine.AI), SageMaker devient un fournisseur interchangeable sans adaptation technique. Les cas d'usage sont nombreux : workflows agentiques tournant entièrement sur de l'infrastructure dédiée en compte AWS, hébergement multi-modèles sur un seul endpoint via les inference components (par exemple Llama pour les tâches générales, un Mistral fine-tuné pour un domaine métier, et un petit modèle de classification), ou encore déploiement de modèles open source fine-tunés sans toucher au code applicatif existant. Pour les entreprises soumises à des contraintes de souveraineté des données ou de conformité, c'est un gain concret : elles peuvent utiliser les mêmes frameworks standardisés OpenAI tout en gardant les modèles dans leur propre compte AWS. Cette annonce s'inscrit dans une bataille plus large pour capter les workloads d'inférence IA en entreprise. Le standard OpenAI s'est imposé de facto comme protocole universel pour les LLMs, et les grands fournisseurs cloud (AWS, Google, Azure) cherchent à réduire les frictions pour attirer des équipes déjà investies dans cet écosystème. Amazon avait déjà investi massivement dans Bedrock et SageMaker, mais l'adoption restait freinée par les incompatibilités d'API qui forçaient les migrations de code. En adoptant la compatibilité OpenAI directement au niveau de SageMaker AI, AWS ferme cet écart et concurrence frontalement des solutions comme Azure OpenAI Service ou les endpoints Vertex AI de Google. Le notebook d'exemple avec Qwen3-4B (modèle d'Alibaba disponible sur Hugging Face) illustre aussi l'ouverture vers les modèles open source, un segment en forte croissance face aux modèles propriétaires.

💬 C'est le genre de truc qui semble anodin et qui change tout en pratique. Changer juste l'URL pour basculer d'OpenAI vers SageMaker, sans toucher au code, c'est exactement ce que les équipes enterprise attendaient pour switcher sans se battre avec leur DSI. Bon, ça reste AWS, donc la facture peut vite grimper, mais pour les boîtes avec des contraintes de souveraineté data, l'argument est solide.

Amazon Bedrock AgentCore Identity permet désormais de référencer ses propres secrets AWS Secrets Manager

Amazon a annoncé une nouvelle fonctionnalité pour Amazon Bedrock AgentCore Identity qui permet désormais aux développeurs de référencer leurs propres secrets AWS Secrets Manager existants, plutôt que de laisser le service en créer automatiquement de nouveaux. Jusqu'à présent, AgentCore Identity gérait de façon autonome un coffre-fort de jetons qui créait et administrait un secret dans Secrets Manager pour chaque fournisseur d'identité externe configuré. Cette approche fonctionnait, mais elle privait les équipes de toute maîtrise sur la configuration de ces secrets : impossible d'y apposer des tags personnalisés, d'imposer une politique de rotation, ou d'appliquer un chiffrement via une clé KMS gérée par le client. La nouvelle capacité, disponible dès aujourd'hui, lève ces contraintes en permettant de fournir directement l'ARN d'un secret préconfiguré à la ressource de fournisseur d'identité. Concrètement, les organisations conservent désormais un contrôle total sur le cycle de vie de leurs secrets d'API utilisés par leurs agents IA : chiffrement avec une clé KMS maison, politique de rotation automatique, réplication, tags pour l'allocation des coûts ou la conformité, et politiques de ressources IAM granulaires. Quand la valeur d'un secret est mise à jour suite à une rotation, AgentCore Identity récupère automatiquement la nouvelle valeur à la prochaine lecture, sans qu'il soit nécessaire de recréer ou de modifier la configuration du fournisseur de credentials. Il est également possible de référencer un secret hébergé dans un autre compte AWS, dans la même région, et les secrets importés via des connecteurs externes Secrets Manager permettent l'intégration avec des gestionnaires de secrets tiers comme HashiCorp Vault. Cette annonce s'inscrit dans une tendance plus large : la montée en puissance des agents IA en production dans les entreprises, qui soulève des exigences de sécurité et de gouvernance de plus en plus strictes. Les équipes cloud des grandes organisations opèrent souvent dans des environnements régulés, avec des politiques SCP et RCP imposant un chiffrement obligatoire par clés gérées par le client, ou des audits de conformité exigeant une traçabilité précise par tags. En permettant à AgentCore de s'insérer dans les workflows de gestion des secrets déjà en place, AWS répond directement à ces contraintes sans obliger les entreprises à dupliquer leur infrastructure ou à contourner leurs propres politiques de sécurité. La prochaine étape naturelle sera probablement l'extension à des secrets cross-région, aujourd'hui encore absente.

Le modèle tabulaire NEXUS de Fundamental est désormais disponible sur Amazon SageMaker JumpStart

Amazon Web Services vient d'annoncer la disponibilité de NEXUS, le modèle de fondation développé par la startup Fundamental, sur Amazon SageMaker JumpStart. NEXUS est un "Large Tabular Model" conçu spécifiquement pour les données structurées -- tableurs, bases de données relationnelles, systèmes ERP et CRM -- là où réside la majorité des données critiques des entreprises. Contrairement aux LLMs classiques, il a été pré-entraîné sur des milliards de tâches de prédiction réelles issues de datasets structurés. Il peut être déployé en tant qu'endpoint SageMaker managé sur une instance ml.p5en.48xlarge équipée de 8 GPU NVIDIA H200, avec accès via un SDK Python compatible scikit-learn incluant des estimateurs NEXUSClassifier et NEXUSRegressor. NEXUS s'attaque à un problème concret que rencontrent quotidiennement les équipes data des grandes entreprises : générer des prédictions fiables à partir de données tabulaires prend habituellement entre trois et six mois de travail pour une équipe de data scientists, entre le feature engineering, l'entraînement, la validation et le déploiement. Fundamental promet de ramener ce délai à quelques jours. L'un des atouts clés du modèle est son architecture déterministe : là où les LLMs produisent des réponses différentes à des questions identiques, NEXUS garantit des résultats reproductibles pour chaque prédiction individuelle. Il gère nativement les nombres, catégories, dates et textes sans prétraitement manuel, tolère les données manquantes, traite des datasets de plusieurs milliards de lignes sans troncature, et reconnaît que l'ordre des colonnes ne change pas la sémantique des données -- une propriété appelée permutation invariance, absente des architectures transformer classiques. Ce lancement s'inscrit dans une tendance plus large de spécialisation des modèles de fondation par type de données. Si les LLMs comme GPT-4 ou Claude ont démontré leur puissance sur le texte et les modèles de diffusion sur les images, les données tabulaires sont longtemps restées le terrain des approches ML traditionnelles -- gradient boosting, random forests -- ou de tentatives maladroites d'adapter des LLMs à des formats pour lesquels ils n'étaient pas conçus. La tokenisation numérique dans les LLMs introduit en effet des erreurs de contexte qui les rendent peu fiables sur des données structurées à haute précision. Fundamental parie que les données tabulaires méritent leur propre classe de modèles de fondation, et l'intégration avec SageMaker JumpStart lui donne accès à l'écosystème cloud d'AWS pour une diffusion à grande échelle auprès des entreprises. Le modèle est distribué via AWS Marketplace, positionnant clairement Fundamental sur le marché B2B des outils data enterprise.