Aller au contenu principal

Dossier AWS — page 5

559 articles · page 5 sur 12

Ce qu'on suit chez AWS côté IA : Bedrock et ses modèles, SageMaker, les puces Trainium et Inferentia, l'investissement dans Anthropic et l'offre cloud IA.

L'optimisation des hyperparamètres sur Amazon Nova Forge
201AWS ML Blog LLMsActu

L'optimisation des hyperparamètres sur Amazon Nova Forge

Amazon a publié un guide technique détaillé sur l'optimisation des hyperparamètres dans Nova Forge, son service cloud dédié à la personnalisation de modèles de langage à grande échelle. Nova Forge permet aux entreprises de partir de points de contrôle anticipés des modèles Amazon Nova, de les entraîner sur leurs données propriétaires tout en les mélangeant à des jeux de données soigneusement sélectionnés par Amazon, et d'héberger les modèles résultants de façon sécurisée sur AWS. Le processus repose sur trois leviers principaux : le taux d'apprentissage, le ratio de mélange des données, la sélection du point de contrôle et les techniques d'entraînement. Selon Amazon, mal calibrer l'un de ces paramètres suffit à compromettre silencieusement toute une campagne d'entraînement, parfois très coûteuse en ressources de calcul. L'enjeu central est ce que les chercheurs appellent l'oubli catastrophique : lorsqu'un modèle est entraîné intensivement sur des données d'un domaine étroit, il tend à écraser les capacités générales acquises lors du pré-entraînement, comme le raisonnement, le suivi d'instructions ou la gestion de conversations multi-tours. Un modèle de service client affiné sur des tickets de support peut ainsi perdre sa capacité à traiter des requêtes ambiguës. Pour contrecarrer ce phénomène, Nova Forge s'appuie sur le mélange de données, qui intègre des corpus Amazon curatés aux données propriétaires pendant l'entraînement, et sur la sélection de point de contrôle, qui permet de doser la quantité d'alignement général conservée. Le taux d'apprentissage reste le paramètre le plus sensible : trop élevé, il déstabilise l'entraînement ou provoque un oubli rapide des capacités de base ; trop bas, il gaspille du calcul en convergeant très lentement. Nova Forge s'inscrit dans une dynamique plus large de démocratisation des modèles frontières propriétaires. Plutôt que de laisser les entreprises se limiter à du fine-tuning superficiel, le service leur permet d'accéder à des checkpoints précoces des modèles Nova et d'y injecter leur propre connaissance métier dès les premières couches d'entraînement. Ce positionnement concurrence directement les offres similaires d'OpenAI, Google et Mistral, qui proposent eux aussi des voies de personnalisation profonde pour les grandes entreprises. La publication de ce guide signale une volonté d'Amazon de réduire le taux d'échec des projets de personnalisation, souvent abandonnés faute de maîtrise des interactions entre hyperparamètres. Les prochaines étapes pour Nova Forge pourraient inclure des outils automatisés de recherche d'hyperparamètres, déjà expérimentés dans d'autres plateformes MLOps, afin de réduire encore la charge d'expertise requise.

1 source
Configurer un flux de code d'autorisation sécurisé avec AgentCore Gateway et des clients MCP
202AWS ML Blog 

Configurer un flux de code d'autorisation sécurisé avec AgentCore Gateway et des clients MCP

Amazon vient de détailler comment sécuriser les échanges entre les assistants de développement basés sur l'IA et les serveurs d'outils d'entreprise, à travers une configuration OAuth reposant sur son service Amazon Bedrock AgentCore. Le composant central de cette architecture est l'AgentCore Gateway, un point d'entrée géré qui centralise le routage et la sécurisation des communications entre agents IA et serveurs MCP (Model Context Protocol). La démonstration s'appuie sur Kiro, l'environnement de développement intégré d'Amazon orienté IA, qui joue le rôle de client OAuth. Côté fournisseur d'identité, l'exemple utilise Amazon Cognito, mais le schéma s'applique à tout IdP compatible, Okta, Microsoft Entra ID, ou tout autre système émettant des jetons de sécurité standards. Le flux fonctionne en plusieurs étapes : Kiro tente de se connecter au point d'accès MCP de la Gateway, reçoit un challenge HTTP 401 accompagné d'un en-tête pointant vers les métadonnées OAuth de la ressource protégée, puis récupère auprès de l'IdP un jeton d'identité valide avant que la requête ne soit enfin autorisée et transmise au serveur MCP sous-jacent. L'enjeu est concret : dans les environnements professionnels, les équipes cherchent à exposer des outils internes (bases de données, API métier, services cloud) à leurs assistants IA, sans sacrifier le contrôle d'accès. Sans mécanisme d'authentification robuste, n'importe quel agent pourrait interroger ces serveurs MCP sans vérification d'identité. Avec ce schéma, chaque requête émise par un assistant IA est associée à l'identité réelle de l'utilisateur qui a lancé la session, ce qui permet d'appliquer des politiques d'accès fines et d'auditer précisément qui a accédé à quoi. Pour les équipes de sécurité, c'est un changement de paradigme : l'IA cesse d'être un trou dans le périmètre de sécurité et devient un canal traçable comme n'importe quel autre. Ce tutoriel s'inscrit dans un mouvement plus large autour du protocole MCP, standardisé par Anthropic fin 2024 et rapidement adopté par l'ensemble de l'industrie comme lingua franca entre les agents IA et leurs outils. Amazon Bedrock AgentCore, lancé récemment, positionne AWS comme infrastructure d'hébergement de référence pour les agents en production, en ajoutant gestion du cycle de vie, monitoring et sécurité d'entreprise par-dessus les serveurs MCP. L'introduction d'un proxy OAuth optionnel dans l'architecture illustre la fragmentation encore existante entre les clients IA, les IdPs et les serveurs MCP : les standards évoluent vite, mais les implémentations concrètes nécessitent encore des couches d'adaptation. La prochaine étape probable est une intégration native de ces flux d'authentification directement dans les spécifications MCP, réduisant le besoin de proxies intermédiaires.

OutilsTuto
1 source
Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore
203AWS ML Blog 

Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore

Amazon a enrichi son service Bedrock AgentCore Gateway de deux mécanismes de sécurité complémentaires destinés à contrôler le comportement des agents IA en entreprise. Le premier, appelé Policy, permet de définir des règles d'accès aux outils à l'aide de Cedar, un langage déclaratif d'Amazon qui évalue chaque requête selon un principal, une action et une ressource, puis délivre une décision déterministe d'autorisation ou de refus, automatiquement journalisée. Le second mécanisme, les intercepteurs Lambda, permet d'exécuter du code personnalisé avant ou après chaque appel d'outil, pour effectuer de la validation dynamique, de l'enrichissement de payload, des échanges de tokens ou du filtrage de réponses. Pour illustrer ces capacités, Amazon présente un agent de données baptisé "lakehouse data agent", conçu pour une compagnie d'assurance fictive. Cet agent permet à trois types d'utilisateurs, titulaires de contrats, experts en sinistres et administrateurs, d'interroger des données de réclamations stockées dans Amazon S3 Tables au format Apache Iceberg, via Amazon Athena et AWS Lake Formation. L'interface Streamlit authentifie les utilisateurs via Amazon Cognito et transmet des JWT à l'agent, qui expose cinq outils MCP distincts. Les métadonnées de rôles, les mappings IAM par tenant et la géographie des utilisateurs sont stockés dans Amazon DynamoDB. Ces nouvelles fonctionnalités répondent à un problème de gouvernance concret que rencontrent les grandes organisations déployant des agents IA à l'échelle. Contrairement aux applications traditionnelles qui exécutent une logique fixe, les agents pilotés par un LLM décident au moment de l'exécution quels outils invoquer, avec quels arguments et dans quel ordre. Il devient donc impossible d'auditer le graphe d'appels à l'avance. Sur des plateformes unifiées comptant des centaines d'agents et des milliers d'outils MCP répartis entre différentes équipes et unités métier, ce manque de contrôle crée un risque réel. La combinaison Cedar pour l'autorisation déterministe et Lambda pour la validation contextuelle dynamique, notamment basée sur la géographie de l'utilisateur, offre une architecture de sécurité en couches adaptée à cette réalité. Ce développement s'inscrit dans un mouvement plus large d'industrialisation de l'IA agentique au sein des entreprises, où les questions de sécurité et de conformité deviennent aussi critiques que la performance des modèles eux-mêmes. Le Model Context Protocol, promu initialement par Anthropic, s'impose progressivement comme standard d'interopérabilité entre agents et outils, et AWS prend position en intégrant nativement la gouvernance des outils MCP dans Bedrock. Lake Formation assure par ailleurs une sécurité au niveau des lignes et des colonnes directement à l'exécution des requêtes, garantissant que même un agent mal configuré ne puisse pas exfiltrer de données hors de son périmètre autorisé. La prochaine étape probable pour Amazon sera d'étendre ces mécanismes à des scénarios multi-agents, où la chaîne de confiance entre agents orchestrateurs et agents subalternes soulève des défis de sécurité encore plus complexes.

InfrastructureActu
1 source
Amazon intègre les bases de données de séries temporelles pour l'analyse de marché via MCP
204AWS ML Blog 

Amazon intègre les bases de données de séries temporelles pour l'analyse de marché via MCP

Amazon vient de dévoiler une intégration du protocole MCP (Model Context Protocol) dans son service de business intelligence Amazon Q (Quick), permettant aux analystes financiers d'interroger des bases de données temporelles en langage naturel. L'exemple phare de cette architecture associe Amazon Q au serveur MCP de KDB-X, construit sur kdb+, un moteur d'analyse haute performance fonctionnant avec le langage vectoriel q, réputé dans le secteur financier pour traiter des millions de transactions boursières par seconde. Concrètement, un analyste peut désormais poser une question comme "quelle a été la volatilité du marché hier entre 10h et 12h ?" et obtenir une réponse sans écrire une seule ligne de code SQL. Le serveur MCP est déployé sur une instance Amazon EC2, tandis qu'Amazon Bedrock AgentCore Gateway assure la couche d'authentification et de routage, avec Amazon Cognito configuré comme fournisseur d'identité. Cette intégration transforme concrètement le quotidien des équipes qui dépendent de données temporelles denses : traders, ingénieurs DevOps, équipes IoT. Jusqu'ici, extraire des insights depuis kdb+ nécessitait des compétences en q ou SQL spécialisé, ce qui créait un goulot d'étranglement entre les analystes métier et la donnée brute. Avec cette architecture, Amazon Q traduit automatiquement les requêtes en langage naturel en instructions SQL, les envoie au serveur KDB-X via le gateway, et restitue les résultats directement dans l'interface de chat. Les outils exposés par le serveur MCP, hybridsearch, runsqlquery, similaritysearch, permettent également des cas d'usage avancés comme la recherche sémantique dans des dépôts réglementaires (fichiers SEC) ou le calcul de métriques de volatilité, sans que l'utilisateur ait besoin de connaître la structure sous-jacente des tables. Le protocole MCP, standardisé pour connecter des systèmes d'IA à des sources de données et outils externes, s'impose progressivement comme le trait d'union entre les LLM et les infrastructures d'entreprise. Amazon Q n'est pas le premier à l'adopter, Anthropic en est l'initiateur, et les principaux éditeurs l'ont rapidement intégré, mais l'associer à kdb+, standard de facto des salles de marché, envoie un signal clair vers les institutions financières. AWS positionne ici AgentCore Gateway comme une brique d'orchestration centrale, capable de gérer l'authentification et l'accès à plusieurs serveurs MCP simultanément. Le pattern architectural décrit dans cette publication est présenté comme réplicable à d'autres secteurs, ce qui laisse entrevoir une extension rapide vers les dashboards industriels, la surveillance d'infrastructure réseau, ou encore la santé connectée.

UELes institutions financières européennes utilisant kdb+ pourraient simplifier l'accès aux données de marché en langage naturel, mais aucune réglementation ou entreprise européenne n'est directement impliquée.

OutilsOutil
1 source
Formation de modèles de langage en azerbaïdjanais sur Amazon SageMaker AI
205AWS ML Blog 

Formation de modèles de langage en azerbaïdjanais sur Amazon SageMaker AI

Azercell Telecom LLC, principal opérateur télécom d'Azerbaïdjan, a développé en six semaines un grand modèle de langage (LLM) en azerbaïdjanais sur la plateforme Amazon SageMaker AI, en partenariat avec le AWS Generative AI Innovation Center. L'objectif : doter l'entreprise d'un chatbot client et d'outils spécialisés pour les usages télécoms, en partant de zéro dans une langue pour laquelle aucun blueprint d'entraînement n'existait. Le cadre technique mis en place repose sur trois étapes séquentielles : la création d'un tokenizer sur mesure, un pré-entraînement continu à partir du modèle Llama 3.2 1B de Meta, puis un affinage supervisé via la méthode LoRA. Sur une instance ml.p5.48xlarge, les optimisations au niveau noyau permises par la bibliothèque Liger Kernels ont abouti à un débit d'entraînement supérieur de 23 % et une consommation mémoire GPU au pic réduite de 58 %. Le tokenizer azerbaïdjanais personnalisé, quant à lui, divise par deux le nombre de tokens nécessaires par mot, ce qui double concrètement la quantité de texte exploitable dans la fenêtre de contexte du modèle. Ces résultats illustrent un défi bien réel pour l'IA appliquée aux langues à faibles ressources : l'azerbaïdjanais est une langue agglutinante, dans laquelle un seul mot peut encoder des informations grammaticales qu'une phrase anglaise exprime par plusieurs mots distincts. Les tokenizers optimisés pour l'anglais fragmentent ces formes complexes de façon inefficace, dégradant les performances et augmentant les coûts de calcul. En construisant un tokenizer monolingue sur mesure, Azercell et AWS ont résolu ce problème structurel avant même de commencer l'entraînement proprement dit, ce qui améliore chacune des étapes suivantes. Pour les entreprises qui opèrent dans des marchés linguistiques non dominants, cette approche modulaire représente un modèle reproductible : chaque composant (tokenizer, pré-entraînement, affinage) peut être optimisé indépendamment et réutilisé sur des tâches différentes. Le projet s'inscrit dans un mouvement plus large de souveraineté linguistique numérique, alors que les LLM généralistes peinent à performer dans les dizaines de langues mal représentées dans leurs données d'entraînement. L'azerbaïdjanais partage des caractéristiques morphologiques avec le turc, le kazakh ou l'ouzbek, ce qui rend cette méthodologie potentiellement transférable à tout un ensemble de langues turcophones d'Asie centrale. Azercell prévoit de passer à des modèles de plus grande taille, pour lesquels l'entraînement distribué sur SageMaker deviendra indispensable, alors que le proof-of-concept actuel à 1 milliard de paramètres n'en avait pas encore besoin. La collaboration avec le AWS Generative AI Innovation Center suit un modèle désormais courant : un géant du cloud apporte l'ingénierie d'infrastructure, l'entreprise locale apporte la donnée et la connaissance métier, et le résultat est un actif IA propriétaire impossible à obtenir via un modèle généraliste.

UELa méthodologie de tokenizer sur mesure pour langues agglutinantes pourrait inspirer des initiatives similaires pour les langues régionales européennes sous-représentées (basque, hongrois, finnois), sans impact direct sur la France ou l'UE.

LLMsTuto
1 source
Créer un portail personnalisé avec les applications MLflow d'Amazon SageMaker AI intégrées
206AWS 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
RAG (Retrieval-Augmented Generation) : une approche pour optimiser l’usage de l’IA
207Le Big Data 

RAG (Retrieval-Augmented Generation) : une approche pour optimiser l’usage de l’IA

La Retrieval-Augmented Generation, ou RAG, est une architecture technique qui associe un modèle de langage à une base documentaire externe, permettant à l'intelligence artificielle de consulter des informations précises avant de formuler une réponse. Concrètement, le processus se déroule en trois temps : les documents de l'entreprise sont d'abord découpés en fragments, puis convertis en représentations mathématiques appelées embeddings, qui transforment le sens d'une phrase en coordonnées numériques. Lorsqu'un utilisateur pose une question, sa requête est elle aussi encodée de cette façon, puis comparée aux vecteurs stockés pour identifier les passages les plus pertinents. Ces extraits sont ensuite injectés dans le prompt envoyé au modèle, qui rédige sa réponse à partir d'un contexte documenté et vérifiable. Contrairement à une recherche par mots-clés classique, le système reconnaît deux phrases sémantiquement proches même si elles n'ont pas de termes en commun. L'intérêt pour les entreprises est considérable. Les modèles de langage traditionnels fonctionnent uniquement à partir de leur corpus d'entraînement : toute information absente ou modifiée depuis génère inévitablement des erreurs, ce que les praticiens appellent les "hallucinations". Le RAG court-circuite ce problème en dotant l'IA d'une mémoire externe dynamique, mise à jour en temps réel. Un service client peut ainsi déployer un assistant conversationnel capable de consulter les procédures internes à jour avant chaque réponse, sans que les données quittent le périmètre de l'organisation. Pour des secteurs manipulant des documents sensibles, comme le juridique, la conformité ou l'ingénierie, cette architecture représente la différence entre un outil expérimental et un outil déployable en production. Le RAG s'est imposé comme l'une des réponses les plus pragmatiques aux limites structurelles des LLM depuis que ces modèles ont commencé à être déployés en entreprise à grande échelle. Les géants du cloud, d'AWS à Microsoft Azure en passant par Google Cloud, proposent désormais des services RAG managés, tandis qu'une constellation de startups comme Pinecone, Weaviate ou Qdrant se sont spécialisées dans les bases vectorielles qui en constituent le socle technique. La question qui reste ouverte est celle de la mise à l'échelle : indexer des dizaines de milliers de documents internes, maintenir la cohérence des embeddings lors des mises à jour, et gérer la latence de récupération sont des défis d'ingénierie non triviaux. Les prochaines évolutions du RAG s'orientent vers des architectures hybrides combinant recherche vectorielle et recherche structurée, ainsi que vers des systèmes capables de raisonner sur plusieurs documents simultanément plutôt que de simplement les concaténer.

LLMsTuto
1 source
L'Afrique du Sud dispose d'atouts en IA, mais son projet de politique ne les exploite pas
208IEEE Spectrum AI 

L'Afrique du Sud dispose d'atouts en IA, mais son projet de politique ne les exploite pas

L'Afrique du Sud détient environ 88 % des réserves mondiales de métaux du groupe du platine, des matériaux indispensables à la fabrication de semi-conducteurs et donc à l'infrastructure même de l'intelligence artificielle. Elle abrite le plus grand marché de centres de données du continent africain, évalué à 2,16 milliards de dollars en 2024. Pourtant, le projet de politique nationale sur l'IA, récemment retiré après avoir été rendu public, ne tire aucun parti de cette position stratégique exceptionnelle. Une nouvelle commission a été annoncée pour réviser ce texte, mais le mal est plus profond : aucun mécanisme de vérification n'a empêché la publication d'un document truffé de références erronées, révélant une défaillance systémique dans la façon dont les gouvernements adoptent l'IA. Le vide politique laissé par ce projet avorté se comble dans les faits par une compétition frontale entre les écosystèmes technologiques chinois et américain. Huawei propose désormais aux entreprises africaines un bundle combinant le modèle de langage DeepSeek à ses propres infrastructures cloud et stockage, à des prix inférieurs de plus de 90 % aux offres concurrentes. En face, Microsoft a annoncé un investissement de 5,4 milliards de rands (300 millions de dollars) en cloud et en IA en Afrique du Sud d'ici fin 2027, s'ajoutant à un précédent engagement de 20,4 milliards de rands. Google, AWS et Oracle disposent déjà de régions cloud dans le pays. Ces investissements ne sont pas neutres : l'infrastructure Huawei est documentée comme un vecteur d'objectifs stratégiques chinois, notamment via son réseau de surveillance Safe Cities, tandis que les hyperscalers américains imposent des modèles fermés, des tarifs fixés unilatéralement et des conditions d'accès que nul gouvernement africain n'a réellement négociées. L'ironie de la situation est saisissante : l'Afrique du Sud extrait les minerais qui rendent l'IA possible, mais se retrouve traitée dans sa propre politique comme simple consommatrice de systèmes qu'elle n'a pas façonnés. Sans politique précisant ce qu'elle exige en contrepartie de l'accès à son marché, son levier structurel reste inutilisé. C'est pourtant le seul pays en développement disposant d'un pouvoir de négociation suffisant pour obtenir des conditions réellement différentes de celles que dictent Pékin ou Silicon Valley. Si l'Afrique du Sud renonce à exercer ce rapport de force, elle offre un précédent révélateur : même une position géologique dominante ne suffit pas à imposer des termes équitables dans la gouvernance mondiale de l'IA.

UELe cas sud-africain illustre les risques de dépendance aux infrastructures IA étrangères, un enjeu que l'UE tente précisément d'adresser via l'AI Act et ses politiques de souveraineté numérique.

RégulationReglementation
1 source
L’IA physique : le prochain marché que surveille déjà Wall Street
209Robot Magazine FR 

L’IA physique : le prochain marché que surveille déjà Wall Street

Wall Street identifie désormais la "Physical AI" comme le prochain cycle d'investissement majeur après l'IA générative. Selon plusieurs cabinets spécialisés, le marché mondial de la robotique intelligente et de l'IA physique pourrait dépasser 3 000 milliards de dollars d'ici 2040. Goldman Sachs est plus précis sur le segment humanoïde : 150 milliards de dollars d'ici 2035, avec un marché global de robotique intelligente franchissant les 400 milliards. NVIDIA, valorisé à plus de 3 000 milliards de dollars en 2026, est présenté comme le principal bénéficiaire actuel de cette tendance, son PDG Jensen Huang ayant publiquement intégré la "Physical AI" à sa feuille de route. Tesla, de son côté, est repositionnée dans cette grille de lecture grâce à son robot humanoïde Optimus, au-delà de son coeur de marché automobile. À noter : ces chiffres sont des projections de marché, pas des revenus confirmés, et l'article ne cite aucune métrique opérationnelle de déploiement. La rupture que pointe cet article est structurelle : l'IA générative est restée confinée aux écrans (texte, images, code), tandis que la Physical AI vise à en faire une force de travail dans le monde réel, capable de manipuler des objets, se déplacer et exécuter des tâches physiques de manière autonome. Pour un COO industriel ou un intégrateur, ce changement de paradigme est pertinent dans un contexte de pénuries de main-d'oeuvre persistantes et d'accélération de l'automatisation. Ce qui change pour les décideurs B2B, c'est l'horizon de planification : les fonds se positionnent déjà, ce qui signifie que les valuations des acteurs émergents (robotique, simulation, edge computing industriel) vont probablement se comprimer dans les 18 à 36 prochains mois, avant même que des déploiements à grande échelle soient prouvés. Ce récit s'inscrit dans un cycle bien rodé : après le cloud (AWS, Azure), puis l'IA générative (NVIDIA, OpenAI), les analystes financiers cherchent le prochain thème de surperformance. NVIDIA a amorcé ce pivot avec ses plateformes Isaac (simulation robotique) et Cosmos (world model pour robots), et ses partenariats avec Figure, 1X, Agility Robotics ou Boston Dynamics. Tesla joue la même carte avec Optimus, dont les premières vidéos de ligne de production interne ont été diffusées fin 2024, sans chiffres de cadence publiés. L'article reste toutefois une analyse financière généraliste : il ne cite aucun robot spécifique avec des métriques techniques (DOF, payload, cycle time), aucun site de déploiement confirmé, et aucun acteur européen malgré la pertinence d'entreprises comme Wandercraft ou Enchanted Tools sur ce segment. Les prochaines étapes annoncées restent floues, ce qui est caractéristique du registre "thème d'investissement émergent" plutôt que d'un bilan opérationnel.

UELa dynamique d'investissement Wall Street sur la Physical AI devrait indirectement comprimer les valorisations des startups robotiques européennes dans les 18-36 mois, avant tout déploiement prouvé, ce qui rend la fenêtre de levée de fonds pour des acteurs comme Wandercraft ou Enchanted Tools potentiellement plus courte.

RobotiqueOpinion
1 source
Optimisation des flux de travail en radiologie grâce aux agents IA
210AWS ML Blog 

Optimisation des flux de travail en radiologie grâce aux agents IA

Des chercheurs et ingénieurs d'Amazon Web Services, en partenariat avec Radiology Partners, ont publié un article technique décrivant un système d'agents IA capables d'optimiser l'attribution des examens radiologiques. Le problème qu'ils cherchent à résoudre est documenté par une étude portant sur 62 hôpitaux et 2,2 millions d'examens : les systèmes traditionnels de liste de travail radiologique provoquent des retards moyens de 17,7 minutes sur les cas urgents, et génèrent des surcoûts estimés entre 2,1 et 4,2 millions de dollars par réseau hospitalier. La solution proposée repose sur Amazon Bedrock AgentCore et le Strands Agents SDK, deux outils AWS permettant de déployer des agents autonomes capables de raisonner sur des données cliniques complexes en temps réel. Le coeur du problème est structurel : les systèmes actuels fonctionnent à partir de règles fixes qui ignorent le contexte opérationnel. Ils ne tiennent pas compte de la spécialisation précise du radiologue disponible, de son niveau de fatigue après plusieurs heures consécutives d'interprétations complexes, ni de la difficulté réelle de l'examen à traiter. Ce déficit d'analyse pousse les radiologues à sélectionner les cas les plus simples ou les mieux rémunérés, laissant les études complexes en attente. Les agents IA proposés évaluent simultanément six facteurs : spécialisation, charge de travail actuelle, schémas de fatigue, complexité du cas, urgence clinique et disponibilité. Contrairement aux moteurs déterministes, le système apprend des historiques d'attribution et s'adapte continuellement, réduisant mécaniquement les comportements de sélection opportuniste. Ce développement s'inscrit dans une tendance plus large de l'IA agentique dans les environnements à forte criticité. Les systèmes de type worklist radiologique existent depuis des décennies, mais leur logique déterministe n'a jamais évolué sans intervention humaine manuelle : quand une règle produit un résultat sous-optimal, le même schéma se répète indéfiniment jusqu'à ce qu'un administrateur modifie le paramétrage. L'introduction d'agents fondés sur des modèles de fondation (foundation models) disponibles via Amazon Bedrock représente un changement de paradigme, passant de la gestion de tâches à une orchestration véritablement autonome. Radiology Partners, l'un des plus grands groupes de radiologie aux États-Unis, a choisi de s'associer à AWS pour déployer cette approche à l'échelle industrielle, signalant que l'IA agentique est désormais considérée comme une capacité opérationnelle critique, et non plus comme un projet expérimental.

OutilsOutil
1 source
Créer des agents IA pour la business intelligence avec Amazon Bedrock AgentCore
211AWS ML Blog 

Créer des agents IA pour la business intelligence avec Amazon Bedrock AgentCore

OPLOG, entreprise turque spécialisée dans la logistique e-commerce pilotée par l'IA et la robotique, traite des millions de colis chaque mois en Turquie, au Royaume-Uni et en Allemagne pour des marques internationales et des marketplaces globales. Face à une fragmentation critique de ses données métier réparties entre HubSpot CRM, Microsoft Teams, Databricks et plusieurs autres systèmes indépendants, la société a développé une plateforme de business intelligence (BI) basée sur des agents IA déployés via Amazon Bedrock AgentCore. Concrètement, OPLOG a construit trois agents distincts à l'aide du Strands Agents SDK d'AWS, intégrés avec le modèle Claude Sonnet d'Anthropic et Amazon Bedrock Knowledge Bases pour la recherche par RAG. Les résultats mesurés sont nets : réduction de 35 % des cycles de vente, amélioration de 91 % de la complétude des données CRM, et réduction de 98 % du temps consacré à la recherche manuelle. L'impact opérationnel est significatif pour toute organisation B2B confrontée à des silos de données. Avant ce système, les équipes d'OPLOG passaient plusieurs heures par jour à extraire manuellement des rapports de systèmes disparates, à synthétiser l'information et à préparer des mises à jour. Les rapports hebdomadaires manquaient 60 % des opportunités commerciales, les deals ayant déjà évolué avant que l'analyse soit disponible. Désormais, trois agents autonomes prennent en charge ces tâches en temps réel : le Deal Analyzer Agent tourne selon un calendrier aligné sur l'activité commerciale et analyse les deals HubSpot récents pour vérifier leur conformité méthodologique, en remontant les résultats directement dans Microsoft Teams. Le Sales Coach Agent réagit aux webhooks HubSpot lorsqu'un deal change de stade, valide les champs requis selon le modèle commercial (B2C, B2B, ou mixte), et crée automatiquement des tâches pour les données manquantes. Un troisième agent, dont le détail n'est pas entièrement publié, complète le dispositif côté recherche de prospects. Ce déploiement s'inscrit dans une tendance de fond : les grandes plateformes cloud cherchent à faire des agents IA le nouveau standard de l'automatisation d'entreprise. Amazon Bedrock AgentCore, l'environnement d'exécution managé d'AWS pour agents IA, vise à simplifier ce type d'architecture en éliminant la gestion d'infrastructure tout en offrant scalabilité et traçabilité. Le choix de Claude Sonnet (Anthropic) comme moteur de raisonnement positionne AWS dans une logique de multi-partenariat avec les principaux labs IA. Pour des entreprises comme OPLOG, dont la croissance rapide dépasse les capacités des outils BI traditionnels, cette approche par agents spécialisés et indépendants offre une voie pragmatique vers l'automatisation sans refonte complète du système d'information.

UEOPLOG, présent en Allemagne et au Royaume-Uni, illustre une architecture d'agents IA applicable aux entreprises logistiques et B2B européennes pour automatiser leur BI et réduire les silos de données.

OutilsOutil
1 source
Amazon SageMaker Feature Store accélère les pipelines ML avec de nouvelles fonctionnalités
212AWS ML Blog 

Amazon SageMaker Feature Store accélère les pipelines ML avec de nouvelles fonctionnalités

Amazon Web Services a annoncé le 16 avril 2026 trois nouvelles fonctionnalités pour SageMaker Feature Store, son dépôt managé dédié au stockage et au partage de features pour les modèles de machine learning. Ces nouveautés sont disponibles dès la version 3.8.0 du SDK Python SageMaker. La première est une intégration native avec AWS Lake Formation, qui permet d'appliquer automatiquement des contrôles d'accès granulaires, au niveau colonne, ligne et cellule, dès la création d'un groupe de features, sans configuration manuelle préalable. La deuxième porte sur la gestion du cycle de vie des métadonnées Apache Iceberg, avec de nouveaux paramètres pour contrôler la rétention des snapshots et éviter l'accumulation de fichiers. La troisième est la modernisation du SDK lui-même : architecture modulaire, performances améliorées, suppression des dépendances lourdes comme PyTorch, pour une installation plus rapide dans des environnements plus légers. Ces changements répondent à deux problèmes opérationnels concrets que rencontrent les équipes ML en production. Sur la question des coûts d'abord : une équipe d'analytique retail citée par AWS a accumulé plus de 50 téraoctets de fichiers de métadonnées Iceberg en moins d'un an sur Amazon S3, générant des frais inattendus et substantiels. Les nouvelles propriétés de table permettent de définir des politiques de rétention directement à la création du groupe de features, ou de les appliquer rétroactivement sur des groupes existants. Sur la question des accès ensuite : les équipes infrastructure réclamaient un contrôle des permissions qui s'active automatiquement, sans passer par des configurations répétitives après coup. L'intégration Lake Formation répond précisément à cela, en vérifiant l'existence d'au moins un Data Lake Administrator dans le compte avant d'activer le contrôle d'accès. SageMaker Feature Store existe depuis 2020 comme composant central de la plateforme ML d'AWS, permettant de stocker des features calculées une fois et de les réutiliser à travers plusieurs modèles et équipes. L'adoption du format Apache Iceberg pour le stockage offline avait apporté des gains en termes de requêtes et de versioning, mais avait aussi introduit ce problème de prolifération de métadonnées qui n'était pas anticipé à grande échelle. La prise en charge complète dans le SDK v3, qui inclut la gestion du cycle de vie des groupes, les opérations sur les enregistrements, et l'ingestion depuis Pandas et Spark, signale qu'AWS consolide son infrastructure ML autour de cette version modernisée. Pour les équipes qui font tourner des pipelines de features en production à haute fréquence, ces ajustements peuvent représenter des économies significatives et une réduction de la friction opérationnelle.

UEImpact indirect pour les entreprises européennes opérant des pipelines ML en production, qui peuvent bénéficier de réductions de coûts de stockage et d'une gouvernance des accès simplifiée.

OutilsActu
1 source
Agents vocaux en temps réel avec Stream Vision Agents et Amazon Nova 2 Sonic
213AWS ML Blog 

Agents vocaux en temps réel avec Stream Vision Agents et Amazon Nova 2 Sonic

Amazon et Stream ont annoncé une intégration combinant le framework open-source Vision Agents de Stream avec Amazon Nova 2 Sonic, un modèle de fondation voix-à-voix disponible via Amazon Bedrock. Cette solution permet de construire des agents vocaux en temps réel capables d'être déployés en production en quelques minutes. Nova 2 Sonic prend en charge l'intégralité du pipeline vocal, entrée audio, détection de tour de parole, appel de fonctions et sortie audio, sans recourir à des services séparés de reconnaissance ou de synthèse vocale. Vision Agents, côté Stream, est un framework Python open-source proposant plus de 25 intégrations, des SDK clients pour React, iOS, Android, Flutter et React Native, et une architecture modulaire basée sur des décorateurs. Le réseau edge mondial de Stream complète le dispositif, avec des temps de connexion inférieurs à 500 ms et une latence audio typique de moins de 30 ms. L'enjeu est considérable pour les équipes qui développent des applications vocales : une conversation naturelle exige que la totalité du pipeline, capture du micro, traitement, génération de réponse, restitution audio, s'exécute en quelques centaines de millisecondes. Jusqu'ici, les développeurs devaient consacrer l'essentiel de leur temps non pas à l'IA elle-même, mais à la gestion des connexions WebRTC, aux logiques de reconnexion automatique, à la compatibilité navigateur et à la dégradation gracieuse en cas d'indisponibilité d'un service. Cette charge infrastructure forçait les équipes soit à investir plusieurs mois dans des solutions maison, soit à se contenter de produits clés en main trop rigides. L'intégration Vision Agents + Nova 2 Sonic absorbe cette complexité et libère les développeurs pour se concentrer sur les cas d'usage : support client, automatisation de workflows, actions pilotées par API. La course à l'agent vocal de qualité production s'est intensifiée ces derniers mois, avec OpenAI, Google et Mistral qui proposent chacun des modèles natifs voix-à-voix. Amazon positionne Nova 2 Sonic comme une réponse enterprise via Bedrock, en s'appuyant sur l'écosystème AWS et le réseau de partenaires comme Stream pour accélérer l'adoption. Le support multilingue natif et les capacités de function calling de Nova 2 Sonic ouvrent la voie à des agents vocaux connectés à des systèmes tiers, CRM, bases de données, outils métier, sans couche d'intégration supplémentaire. La prochaine étape pour cet écosystème sera probablement l'extension vers des agents multimodaux combinant voix et vision, une direction que Vision Agents anticipe déjà avec son nom et son architecture.

UELes développeurs et entreprises européens utilisant AWS Bedrock peuvent désormais déployer des agents vocaux en production sans infrastructure supplémentaire grâce à cette intégration.

OutilsOutil
1 source
Des données cloisonnées aux analyses unifiées : accès Athena multi-comptes dans Amazon QuickSight
214AWS ML Blog 

Des données cloisonnées aux analyses unifiées : accès Athena multi-comptes dans Amazon QuickSight

Amazon vient d'annoncer une nouvelle fonctionnalité pour Amazon QuickSight, sa plateforme de business intelligence alimentée par l'IA : l'accès Athena inter-comptes (cross-account). Concrètement, les entreprises qui centralisent leur déploiement de QuickSight dans un seul compte AWS peuvent désormais interroger des données stockées dans d'autres comptes AWS via Amazon Athena, le service de requêtes SQL serverless d'Amazon qui analyse directement les données hébergées dans Amazon S3. Jusqu'à présent, ce scénario poussait les équipes à maintenir plusieurs abonnements QuickSight distincts, ou à faire absorber tous les coûts de requêtes par le compte central. Avec cette mise à jour, les frais de traitement sont facturés au compte où réside la donnée, et non au compte central. L'impact est direct pour les grandes organisations financières, industrielles ou multidivisionnelles qui fonctionnent avec une architecture AWS multi-comptes. Une banque, par exemple, peut avoir ses données de banque de détail dans un compte A, ses activités d'investissement dans un compte B et sa gestion des risques dans un compte C, tout en pilotant QuickSight depuis un compte central unique. Cette nouvelle fonctionnalité supprime le besoin de dupliquer les abonnements ou de centraliser les coûts de façon artificielle. Elle simplifie aussi la gouvernance : chaque unité métier conserve la maîtrise de ses données et de sa facturation cloud, pendant que les équipes analytiques accèdent à l'ensemble depuis un tableau de bord unifié. Le mécanisme technique repose sur un enchaînement de rôles IAM en deux étapes, appelé role chaining. QuickSight commence par endosser un rôle dit RunAsRole (Rôle A) dans le compte central, qui ne détient aucun accès aux données mais dispose uniquement de la permission de basculer vers un second rôle. Ce second rôle (Rôle B), situé dans le compte consommateur, détient lui les droits d'accès à Athena, au catalogue AWS Glue et aux fichiers S3. Pour éviter les attaques de type "confused deputy", un identifiant externe (ExternalId) lié à l'ARN de la source de données est intégré dans les politiques de confiance. Cette approche s'inscrit dans une tendance plus large d'AWS à décloisonner les silos de données tout en maintenant des contrôles d'accès granulaires, à mesure que les entreprises basculent vers des architectures data mesh distribuées où la donnée reste souveraine au niveau de chaque domaine métier.

UELes grandes organisations européennes fonctionnant avec une architecture cloud multi-comptes peuvent désormais centraliser leurs analyses BI sans dupliquer les abonnements ni concentrer artificiellement les coûts, simplifiant la gouvernance des données distribuées.

OutilsOutil
1 source
Des agents avec recherche web grâce à Strands et Exa
215AWS ML Blog 

Des agents avec recherche web grâce à Strands et Exa

AWS a publié une intégration native entre son SDK open source Strands Agents et le moteur de recherche Exa, permettant aux agents IA d'accéder au web en temps réel sans couche de post-traitement. Cette combinaison expose deux outils principaux : exasearch, qui effectue des recherches sémantiques avec prise en charge de catégories comme les articles d'actualité, les publications de recherche ou les dépôts de code, et exaget_contents, qui récupère le contenu complet de pages web ciblées. Le SDK Strands Agents, distribué en open source par AWS, repose sur une architecture pilotée par le modèle : plutôt que de définir des workflows figés, le développeur fournit un modèle de langage, un prompt système et une liste d'outils, puis c'est le modèle lui-même qui décide quels outils appeler, dans quel ordre, et quand la tâche est accomplie. Le SDK embarque déjà plus de 40 outils préconstruits couvrant la gestion de fichiers, l'exécution de code, les API AWS, la mémoire et la recherche web. Pour les développeurs qui construisent des agents dédiés à la veille, à la vérification des faits ou à l'intelligence concurrentielle, cette intégration élimine un obstacle persistant : la plupart des API de recherche généralistes renvoient des pages HTML chargées de balisage et des snippets courts optimisés pour la navigation humaine, ce qui oblige à construire des couches supplémentaires de parsing, de nettoyage et de reclassement avant de pouvoir injecter ces données dans une fenêtre de contexte LLM. Exa résout ce problème à la source en fournissant un contenu propre, structuré et directement exploitable. Concrètement, un agent peut enchaîner plusieurs appels de recherche, accumuler les résultats dans son historique de conversation et raisonner sur l'ensemble pour produire une réponse finale, sans que le développeur n'ait à orchestrer chaque étape manuellement. Exa se distingue des moteurs traditionnels par son approche sémantique : une requête comme "startups développant des solutions climatiques" retourne effectivement des entreprises du secteur, même si leurs pages ne contiennent pas cette formulation exacte, car le moteur travaille sur la similarité de sens plutôt que sur la correspondance de mots-clés. Le SDK supporte également le Model Context Protocol (MCP), ce qui facilite l'ajout de tout nouveau serveur d'outils sans travail d'intégration supplémentaire. L'intégration Exa est disponible via le package strands-agents-tools et s'ajoute à la liste d'outils en une ligne de code. Dans un contexte où les agents IA peinent encore à accéder à des informations récentes et fiables, cette combinaison d'un framework agentique piloté par le modèle et d'un moteur de recherche conçu pour les LLM ouvre des perspectives concrètes pour des cas d'usage comme l'analyse de marché, la recherche documentaire automatisée ou le suivi de l'actualité technologique en temps réel.

OutilsOutil
1 source
Réservez de la capacité GPU à court terme pour vos workloads ML avec EC2 Capacity Blocks et SageMaker
216AWS ML Blog 

Réservez de la capacité GPU à court terme pour vos workloads ML avec EC2 Capacity Blocks et SageMaker

Amazon Web Services propose deux solutions complémentaires pour sécuriser de la capacité GPU à court terme : les EC2 Capacity Blocks for ML et les SageMaker training plans. Les Capacity Blocks permettent de réserver un nombre précis d'instances GPU pour une fenêtre temporelle définie, jusqu'à huit semaines à l'avance, avec des durées allant de 1 à 14 jours (par paliers d'un jour) ou de 15 à 182 jours (par paliers de sept jours). Chaque bloc peut couvrir jusqu'à 64 instances d'un même type, et une organisation peut cumuler jusqu'à 256 instances sur une même date en combinant plusieurs blocs au sein d'AWS Organizations. Contrairement aux réservations de capacité à la demande classiques (ODCR), ces Capacity Blocks sont entièrement en libre-service et affichent une décote de 40 à 50 % par rapport aux tarifs à la demande, tout en offrant une bien meilleure disponibilité pour les instances de type P, particulièrement recherchées. Ces solutions répondent à un besoin concret et pressant : la demande mondiale de GPU pour l'entraînement, le fine-tuning et l'inférence de modèles d'intelligence artificielle dépasse largement l'offre disponible. Pour les équipes qui ont besoin de GPU de manière ponctuelle, que ce soit pour des tests de charge, la validation de modèles, des ateliers techniques ou la préparation d'une mise en production, les options existantes présentent des limites sérieuses. Les instances à la demande ne garantissent pas la disponibilité au moment du lancement, et relâcher une instance peut signifier ne plus pouvoir la récupérer. Les instances Spot, bien que jusqu'à 90 % moins chères, peuvent être interrompues à tout moment par AWS. Les Capacity Blocks éliminent cette incertitude : la capacité est garantie pendant toute la durée réservée, ce qui permet de planifier des workloads critiques en temps contraint sans risque de pénurie de ressources. Cette pénurie de GPU n'est pas nouvelle : depuis l'explosion des usages d'IA générative à partir de 2023, les grands hyperscalers comme AWS, Google Cloud et Microsoft Azure font face à une concurrence intense pour l'acquisition et la mise à disposition de puces Nvidia H100 et autres accélérateurs. AWS avait introduit les Capacity Blocks dès 2023 pour les instances P5, mais l'offre s'est depuis progressivement élargie. L'intégration avec les SageMaker training plans vise à couvrir également les usages managés, où AWS gère l'infrastructure sous-jacente. À terme, ces mécanismes de réservation structurée devraient devenir la norme pour toute organisation menant des expérimentations ML d'envergure, car ils permettent de concilier agilité opérationnelle et maîtrise des coûts sans recourir à des contrats pluriannuels.

UELes équipes françaises et européennes utilisant AWS pour leurs workloads ML peuvent sécuriser de la capacité GPU à court terme avec une décote de 40-50%, réduisant l'incertitude opérationnelle liée à la pénurie mondiale de GPU.

InfrastructureActu
1 source
Tutor Intelligence crée une Data Factory pour entraîner ses robots par IA dans le monde réel
217Robotics Business Review 

Tutor Intelligence crée une Data Factory pour entraîner ses robots par IA dans le monde réel

Tutor Intelligence a inauguré DF1, sa "Data Factory" installée dans une ancienne manufacture de Watertown, Massachusetts : un parc de 100 robots semi-humanoïdes bimanaux baptisés Sonny, destinés à collecter des données réelles pour entraîner son modèle vision-langage-action (VLA) Ti0. Fondée en 2021 par Josh Gruenstein (CEO) et Alon Kosowsky-Sachs (CTO) issus du MIT-CSAIL, la startup revendique avoir constitué la plus grande infrastructure de ce type aux États-Unis. Elle a levé 34 millions de dollars en Série A en décembre 2025, puis tenu une journée portes ouvertes en avril 2026. Entre 45 et 50 téléopérateurs distants au Mexique et aux Philippines pilotent les robots par téleopération proprioceptive pour leur enseigner des tâches de picking, kitting et préparation de commandes e-commerce. En évaluant simultanément le même comportement sur 100 unités, la détection d'anomalies s'effectue 100 fois plus vite qu'en opération solo : un cas limite normalement visible après 8 heures d'opération sur un robot unique devient détectable en 5 minutes de fonctionnement de la flotte. Une méthode de prétraitement baptisée "velocity normalization" standardise les profils de démonstration entre téléopérateurs pour homogénéiser le corpus d'entraînement. L'enjeu central est de s'affranchir de la dépendance à la simulation, un pari sur la donnée réelle là où la majorité des acteurs humanoïdes s'appuient encore sur des environnements synthétiques pour réduire leurs coûts de collecte. La thèse de Gruenstein est directe : sans équivalent robotique de Wikipédia, le transfert d'intelligence à l'échelle industrielle passe nécessairement par des humains enseignant des machines en conditions réelles. DF1 est conçue comme le premier maillon d'un cycle vertueux, déploiements commerciaux, données à l'échelle, amélioration continue de Ti0. Pour les intégrateurs et décideurs industriels, cette approche ouvre une trajectoire vers un modèle généraliste capable d'absorber de nouvelles tâches sans reprogrammation lourde, précisément le verrou économique du marché actuel. Les performances annoncées restent toutefois auto-déclarées, sans validation indépendante. Tutor Intelligence a émergé du MIT-CSAIL en 2021, avant l'essor commercial des VLA. La startup est membre de la première promotion du Physical AI Fellowship, programme co-animé par AWS, NVIDIA et MassRobotics, qui lui fournit ressources de calcul cloud et expertise technique. Dans un paysage concurrentiel où Physical Intelligence (pi0), Figure, Apptronik et Boston Dynamics développent chacun leurs propres stacks d'entraînement, Tutor se différencie en contrôlant à la fois le hardware d'entraînement (Sonny), la plateforme de téleopération et le modèle VLA, sans dépendre d'une simulation propriétaire. L'objectif déclaré est de lancer le premier déploiement commercial humanoïde généraliste, en alimentant la boucle de données depuis la production réelle pour piloter les itérations suivantes. Les conditions commerciales, les performances comparatives de Ti0 et les éventuels clients pilotes n'ont pas encore été communiqués.

RobotiqueOpinion
1 source
Hapag-Lloyd utilise Amazon Bedrock pour transformer les retours clients en informations exploitables
218AWS ML Blog 

Hapag-Lloyd utilise Amazon Bedrock pour transformer les retours clients en informations exploitables

Hapag-Lloyd, l'un des leaders mondiaux du transport maritime de conteneurs, a déployé une solution d'analyse automatisée des retours clients basée sur Amazon Bedrock, le service d'IA générative d'AWS. L'armateur allemand, qui exploite une flotte de 313 porte-conteneurs représentant 2,5 millions d'EVP de capacité de transport, emploie environ 14 000 personnes dans son segment de lignes régulières et gère plus de 400 bureaux dans 140 pays. Son équipe d'ingénierie produit, répartie entre Hambourg et Gdańsk, pilote cette initiative dans le cadre d'une ambition plus large de devenir une entreprise dite "AI-native". Le système s'appuie sur Amazon Bedrock, LangChain et LangGraph, ainsi qu'Elasticsearch pour collecter les commentaires clients, en extraire le sentiment, identifier des thèmes récurrents et produire des synthèses exploitables. L'enjeu est d'abord opérationnel : avant cette solution, les chefs de produit exportaient manuellement des fichiers CSV toutes les deux semaines, parcouraient des centaines de commentaires et les catégorisaient à la main, un travail qui pouvait mobiliser plusieurs heures, parfois plusieurs jours, avant chaque réunion de revue produit. Désormais, l'ensemble de ce flux est automatisé, de l'ingestion des données à la production d'insights. Les équipes peuvent ainsi se concentrer sur la stratégie et l'innovation plutôt que sur l'analyse répétitive. Pour une entreprise qui relie plus de 600 ports via 133 lignes régulières mondiales et traite un volume massif d'interactions clients, la capacité à lire rapidement les signaux du terrain constitue un avantage concurrentiel direct sur la qualité de service et la réactivité produit. Cette transformation s'inscrit dans une dynamique plus large de l'industrie du shipping, où la digitalisation s'accélère sous la pression de la concurrence et des attentes croissantes des chargeurs. Hapag-Lloyd a construit sa capacité sur une stack technologique qu'il maîtrise en propre, ce qui lui a permis d'itérer rapidement vers des usages d'IA générative sans dépendance contraignante. Le choix d'Amazon Bedrock est également révélateur : le service donne accès via une API unifiée aux modèles d'Anthropic, Meta, Mistral, DeepSeek et d'autres, avec des garanties de sécurité et de confidentialité adaptées aux exigences d'un groupe coté en bourse. À mesure que d'autres armateurs et acteurs logistiques adoptent des approches similaires, la capacité à transformer le feedback client en décisions produit en temps quasi réel pourrait devenir un standard du secteur plutôt qu'un avantage différenciant.

UEHapag-Lloyd, armateur allemand coté en bourse avec ses équipes à Hambourg et Gdańsk, automatise l'analyse de ses retours clients via Amazon Bedrock, signalant l'accélération de l'IA générative dans la logistique maritime européenne.

OutilsOutil
1 source
Des workflows guidés par agents pour accélérer la personnalisation de modèles dans Amazon SageMaker AI
219AWS ML Blog 

Des workflows guidés par agents pour accélérer la personnalisation de modèles dans Amazon SageMaker AI

Amazon a lancé une expérience agentique intégrée dans SageMaker AI pour simplifier radicalement la personnalisation des modèles de langage. Jusqu'ici, adapter un modèle fondation à un cas d'usage métier exigeait de maîtriser des techniques comme le Supervised Fine-Tuning (SFT), le Direct Preference Optimization (DPO) ou le Reinforcement Learning Verifiable Rewards (RLVR), de naviguer entre des APIs fragmentées et des formats de données spécifiques à chaque modèle, et de gérer des cycles d'expérimentation qui s'étiraient sur plusieurs mois. Désormais, un développeur peut décrire son cas d'usage en langage naturel, et l'agent de codage prend en charge l'ensemble du parcours: définition du problème, préparation des données, sélection de la technique d'entraînement, évaluation de la qualité du modèle, puis déploiement vers Amazon Bedrock ou un endpoint SageMaker AI. Amazon Kiro, l'agent de développement logiciel d'Amazon, est préconfiguré par défaut dans l'environnement JupyterLab de SageMaker AI Studio, avec complétion de code, débogage assisté et support interactif. Les agents compatibles avec le protocole ACP (Agent Communication Protocol), dont Claude Code d'Anthropic, peuvent également être intégrés et bénéficier des mêmes fonctionnalités. La version 4.1 ou supérieure de SageMaker AI Distribution est requise, ainsi qu'un rôle IAM avec la politique gérée AmazonSageMakerFullAccess. Le coeur du dispositif repose sur des "Skills", des modules d'instructions préconçus et modulaires qui encapsulent l'expertise AWS et data science sur l'ensemble du cycle de personnalisation. Lorsqu'un développeur décrit son besoin, l'agent active automatiquement les Skills pertinents, qui le guident à travers la validation des données, la configuration des hyperparamètres et l'évaluation du modèle via des métriques LLM-as-a-Judge. Chaque étape génère des notebooks directement exécutables, entièrement modifiables et réutilisables dans des workflows existants. Un avantage opérationnel concret: les Skills réduisent la consommation de tokens tout en augmentant la précision des réponses, car l'agent dispose d'un contexte spécialisé plutôt que de connaissances génériques. Les organisations peuvent personnaliser ces Skills pour les aligner sur leurs standards de gouvernance, leurs outils internes et leurs pratiques d'équipe, résolvant ainsi un problème récurrent avec les assistants de codage généralistes qui ne reproduisent pas de manière fiable les conventions maison. L'annonce s'inscrit dans une dynamique plus large où la personnalisation des modèles devient le principal levier de différenciation concurrentielle, tous les acteurs ayant accès aux mêmes modèles fondations publics. Amazon positionne SageMaker AI comme une plateforme bout-en-bout pour les équipes qui veulent exploiter leurs données propriétaires sans assembler elles-mêmes une chaîne d'outils dispersés. La prise en charge du protocole ACP ouvre la voie à un écosystème d'agents tiers, signalant une stratégie d'interopérabilité plutôt que de verrouillage. Les prochaines étapes naturelles incluent l'extension de ce type d'expérience agentique à d'autres phases du cycle MLOps, comme la surveillance des modèles en production ou la gestion des dérives de données.

UELes équipes data européennes utilisant AWS SageMaker AI peuvent accélérer leurs projets de fine-tuning de modèles fondation sans expertise MLOps avancée, réduisant les délais de personnalisation sur données propriétaires.

OutilsOutil
1 source
Intégrer la confiance dans l'IA
220Amazon Science 

Intégrer la confiance dans l'IA

Amazon a bâti un cadre formel d'intelligence artificielle responsable (RAI) qui s'applique à l'ensemble de ses produits, de la logistique d'entrepôt aux chatbots de service client, en passant par les services cloud AWS utilisés par des milliers d'entreprises. Ce dispositif repose sur quatre phases distinctes du cycle de vie des modèles : le pré-entraînement, le post-entraînement, l'évaluation et la surveillance par des tiers. Rahul Gupta, senior science manager et responsable RAI au sein de l'organisation AGI (Artificial General Intelligence) d'Amazon, résume l'ambition ainsi : "La responsabilité est intégrée dès le premier jour dans la conception du produit." À ce jour, Amazon a développé plus de 70 outils RAI internes et externes, financé ou publié plus de 500 articles de recherche, et dispensé des dizaines de milliers d'heures de formation à ses employés. L'enjeu est considérable pour les entreprises clientes d'AWS et pour les millions d'utilisateurs qui interagissent quotidiennement avec des systèmes alimentés par les modèles Amazon. Une IA mal calibrée peut produire des discriminations, diffuser des contenus dangereux ou se montrer incapable de respecter des réglementations locales très différentes d'un pays à l'autre. L'approche en trois volets d'Amazon vise précisément à anticiper ces risques avant qu'ils ne se matérialisent, à entraîner les modèles à naviguer dans les zones d'ambiguïté, et à construire des systèmes capables de s'adapter aux transitions gouvernementales, aux incidents médiatiques, aux nouvelles lois et aux évolutions sociales. Pour l'industrie, cela signifie que la sécurité n'est plus une couche ajoutée après coup mais une contrainte de conception à part entière. Les fondations de ce programme remontent aux travaux menés au sein d'Alexa AI, bien avant l'explosion des modèles génératifs, où Amazon avait développé des politiques et des méthodes d'évaluation qui ont ensuite été transposées à la construction de grands modèles de langage. Au stade du pré-entraînement, le chercheur Chentao Ye et son équipe enrichissent les corpus massifs de données publiques avec des jeux de données spécifiquement conçus pour inculquer des principes de sécurité, d'équité et de respect de la vie privée, dans plusieurs langues et cultures. Plutôt que de filtrer systématiquement les contenus sensibles, les chercheurs convertissent des documents de politique en exercices pédagogiques variés, forçant le modèle à raisonner sur des cas concrets de conformité ou de violation de règles. Cette approche, qui traite l'IA comme un apprenant nécessitant une éducation progressive, reflète une tendance de fond dans le secteur : à mesure que les régulateurs européens, américains et asiatiques durcissent leurs exigences, les grandes plateformes tech cherchent à démontrer que la gouvernance des modèles peut être industrialisée et mesurable.

UELes entreprises européennes clientes d'AWS sont directement concernées par ce cadre RAI, notamment au regard des exigences de conformité imposées par l'AI Act européen.

ÉthiqueActu
1 source
Exploiter l'analyse IA à base d'agents sur Amazon SageMaker avec Amazon Athena et Amazon Quick
221AWS ML Blog 

Exploiter l'analyse IA à base d'agents sur Amazon SageMaker avec Amazon Athena et Amazon Quick

Amazon a dévoilé une architecture d'analyse de données intégrant de l'intelligence artificielle agentique sur Amazon SageMaker, combinant Amazon Athena et Amazon QuickSight pour permettre aux utilisateurs métier d'interroger des lacs de données complexes en langage naturel. La solution repose sur une architecture lakehouse construite à partir des jeux de données de référence TPC-H (100 Go hébergés sur S3), et s'appuie sur plusieurs couches technologiques : Amazon S3 comme stockage principal, AWS Glue pour le catalogage des métadonnées, Athena pour les requêtes SQL serverless, et QuickSight avec son moteur SPICE (Super-fast, Parallel, In-memory Calculation Engine) pour la visualisation et l'interface conversationnelle. Les données sont stockées en trois formats distincts, CSV, Apache Iceberg-Parquet avec support ACID et time-travel, et Amazon S3 Tables avec support natif Iceberg, afin d'illustrer la polyvalence d'une architecture data lake moderne. Un agent IA conversationnel, alimenté par des bases de connaissances enrichies via un crawler web, permet ensuite d'interroger ces données structurées et non structurées depuis une interface en langage naturel. L'enjeu principal est la démocratisation de l'accès aux données au sein des grandes organisations. Aujourd'hui, interroger un lac de données pétaoctet exige des compétences pointues en SQL, en modélisation de données et en outils de business intelligence, autant de barrières qui ralentissent la prise de décision dans des secteurs comme la finance, la santé, le retail ou la logistique. En substituant ces interfaces techniques par un agent conversationnel, Amazon permet à des profils non-techniques d'obtenir des insights directement exploitables sans passer par des équipes data. Pour les entreprises, cela signifie moins de goulots d'étranglement, des cycles d'analyse raccourcis, et une gouvernance des données maintenue grâce aux contrôles de sécurité intégrés dans l'écosystème AWS. Cette annonce s'inscrit dans une course plus large entre les grands fournisseurs cloud, AWS, Google et Microsoft, pour intégrer des agents IA directement dans leurs plateformes analytiques. Amazon capitalise ici sur son écosystème existant : QuickSight Q, lancé il y a plusieurs années comme interface NLP pour la BI, monte en puissance avec l'intégration de bases de connaissances et d'espaces collaboratifs (Quick Spaces). La combinaison d'Athena, qui facture à la requête sans serveur à maintenir, et d'agents capables de mélanger données structurées et documentation non structurée, positionne AWS comme un acteur sérieux dans l'analytics agentique d'entreprise. La prochaine étape logique sera l'automatisation complète du cycle analyse-décision-action, où l'agent ne se contente plus de répondre mais déclenche directement des workflows métier.

UELes entreprises européennes déployées sur AWS peuvent adopter cette architecture d'analytics agentique pour réduire leur dépendance aux équipes data, mais l'annonce ne cible pas spécifiquement le marché ou les régulations européennes.

OutilsOutil
1 source
Groupe SoftBank lance une pépite robotique déjà valorisée 100 milliards
222Le Big Data 

Groupe SoftBank lance une pépite robotique déjà valorisée 100 milliards

SoftBank prépare le lancement d'une nouvelle entité baptisée Roze AI, dédiée à l'automatisation de la construction de centres de données, avec une introduction en bourse envisagée dès le second semestre 2026 aux États-Unis. Selon le Financial Times et le Wall Street Journal, le groupe japonais vise une valorisation de 100 milliards de dollars pour cette structure encore embryonnaire. L'idée centrale : déployer des robots autonomes pour accélérer, standardiser et réduire les coûts de construction des data centers, infrastructures devenues critiques pour alimenter la demande explosive en puissance de calcul liée à l'IA générative. L'enjeu est colossal. Construire un centre de données reste aujourd'hui un processus long, coûteux et très dépendant de la main-d'œuvre humaine. En automatisant cette chaîne, Roze AI pourrait réduire significativement les délais de mise en service au moment précis où hyperscalers, gouvernements et entreprises technologiques se disputent la capacité de calcul disponible. Si la formule fonctionne, SoftBank ne se contenterait plus d'être un investisseur dans l'écosystème IA : il deviendrait un acteur industriel direct, capturant une part de la chaîne de valeur physique de l'intelligence artificielle, au même titre qu'un grand fournisseur cloud comme AWS ou Microsoft Azure. SoftBank évolue depuis des années dans une logique de paris technologiques massifs, parfois triomphants comme avec Alibaba, parfois catastrophiques comme avec Zume, la startup de livraison de pizzas robotisées qui a tourné court. Cette fois, la stratégie change de nature : il ne s'agit plus de financer des startups prometteuses depuis l'extérieur, mais de créer de toutes pièces une entité industrielle intégrée. SoftBank n'est pas seul sur ce terrain : Jeff Bezos a cofondé Project Prometheus, initiative visant à racheter des entreprises industrielles pour les moderniser par l'IA, signalant une convergence plus large entre capital technologique et transformation des infrastructures physiques. En interne, le projet Roze AI suscite néanmoins des interrogations : selon le Financial Times, plusieurs employés du groupe doutent de la pertinence d'une valorisation à 100 milliards pour une entité qui n'a pas encore prouvé son modèle à grande échelle, et le calendrier d'IPO pour fin 2026 est jugé très ambitieux. La question reste entière : Roze AI deviendra-t-elle un standard de l'infrastructure IA mondiale, ou un nouveau pari à haut risque dans la longue histoire des investissements de SoftBank ?

RobotiqueOpinion
1 source
Organiser la mémoire des agents à grande échelle : patterns de conception par namespace dans AgentCore Memory
223AWS ML Blog 

Organiser la mémoire des agents à grande échelle : patterns de conception par namespace dans AgentCore Memory

Amazon a publié un guide technique détaillé sur la conception de namespaces dans AgentCore Memory, le système de mémoire à long terme intégré à Amazon Bedrock. La fonctionnalité, présentée dans un billet de blog officiel d'AWS, permet aux développeurs d'organiser les souvenirs de leurs agents IA sous forme de chemins hiérarchiques, similaires à des arborescences de fichiers. Concrètement, les préférences d'un utilisateur identifié comme customer-123 seront stockées sous /actor/customer-123/preferences/, tandis que les résumés de ses sessions individuelles seront rangés sous /actor/customer-123/session/session-789/summary/. Ces chemins sont générés automatiquement à partir de trois variables prédéfinies : {actorId} pour l'identifiant de l'utilisateur, {sessionId} pour la session en cours, et {memoryStrategyId} pour le type de stratégie mémoire utilisé. Le système prend en charge plusieurs stratégies superposées, notamment la mémoire sémantique pour les faits durables sur un utilisateur, et la mémoire de résumé pour les synthèses de sessions passées. L'enjeu est concret : sans organisation rigoureuse, les agents IA récupèrent du contexte non pertinent lors de leurs requêtes, ce qui dégrade la qualité des réponses et peut créer des failles de sécurité, notamment en exposant les souvenirs d'un utilisateur à un autre. Le système de namespaces résout ces deux problèmes à la fois. D'un côté, la structure hiérarchique permet une récupération à granularité variable : on peut interroger la mémoire d'une session précise, l'ensemble des préférences d'un utilisateur à travers toutes ses sessions, ou encore des données communes à tous les utilisateurs d'un même agent. De l'autre, AWS intègre des contrôles d'accès IAM natifs qui permettent de délimiter précisément qui peut lire ou écrire dans quelle portion de la mémoire, sans dupliquer le stockage physique. Les namespaces sont des partitions logiques au sein d'une même ressource mémoire, une approche que les équipes habituées aux clés de partition DynamoDB ou aux préfixes S3 reconnaîtront immédiatement. Ce guide s'inscrit dans une dynamique plus large : l'essor des agents IA en production crée une demande croissante pour des infrastructures mémoire robustes et sécurisées. Amazon Bedrock, qui concurrence directement les offres d'OpenAI, Google et Microsoft Azure dans l'espace des plateformes d'agents d'entreprise, cherche à se différencier par des primitives de bas niveau bien pensées. AgentCore Memory, présenté comme une brique fondamentale pour les agents à longue durée de vie, cible les équipes qui construisent des assistants client, des copilotes métier ou des agents autonomes nécessitant une continuité de contexte entre les sessions. La prochaine étape annoncée par AWS porte sur les patterns de récupération multi-niveaux et les stratégies d'isolation entre agents dans des architectures multi-tenants.

UEAmazon Bedrock étant déployé dans des régions AWS européennes, ces patterns de conception sont directement exploitables par les équipes françaises et européennes qui construisent des agents IA sur cette plateforme.

OutilsActu
1 source
Exécuter des proxies MCP personnalisés en serverless sur Amazon Bedrock AgentCore Runtime
224AWS ML Blog 

Exécuter des proxies MCP personnalisés en serverless sur Amazon Bedrock AgentCore Runtime

Amazon Web Services vient de détailler une architecture permettant de déployer des proxys MCP (Model Context Protocol) personnalisés en mode serverless sur Amazon Bedrock AgentCore Runtime. Cette solution s'adresse aux équipes qui souhaitent insérer une couche de contrôle programmable entre leurs agents IA et les outils auxquels ils accèdent, bases de données, API tierces, systèmes de fichiers, sans modifier ni le client ni le serveur MCP en amont. Le proxy s'exécute comme une charge de travail sans état sur AgentCore Runtime, découvre automatiquement les outils disponibles au démarrage, les réexpose avec la logique personnalisée appliquée, puis transfère les requêtes de manière transparente. L'infrastructure est entièrement gérée par AWS, avec mise à l'échelle automatique, observabilité intégrée via Amazon CloudWatch et OpenTelemetry, et gestion des identités via AgentCore Identity. L'intérêt concret est d'ordre gouvernance et conformité. En production, les interactions entre agents IA et outils doivent respecter des politiques de sécurité internes, des réglementations sectorielles et des exigences d'auditabilité spécifiques : nettoyage des entrées avant qu'elles atteignent les systèmes backend, génération de journaux d'audit dans des formats particuliers, ou encore rédaction de données sensibles au niveau du protocole. AgentCore Gateway propose déjà des intercepteurs Lambda pour intégrer ce type de logique, mais certaines organisations disposent de bibliothèques de filtrage MCP internes ou de systèmes de conformité on-premises qu'elles ne souhaitent pas refactoriser en fonctions Lambda. Le proxy serverless sur Runtime offre alors une alternative portable, réutilisable dans des environnements hybrides ou multi-systèmes, sans dépendance à un intercepteur spécifique à une plateforme. Ce développement s'inscrit dans l'adoption rapide du Model Context Protocol comme standard de facto pour connecter les agents IA à leurs outils. MCP, initialement proposé par Anthropic fin 2024, est désormais supporté par la plupart des grandes plateformes d'agents, et AWS positionne AgentCore comme son infrastructure de référence pour les déploiements en production. La solution présentée s'appuie sur une implémentation open source disponible sur GitHub, ce qui facilite l'adoption et la personnalisation. Elle peut également se connecter à AgentCore Gateway pour bénéficier de la découverte gérée des outils, de la gestion des credentials et de l'application de politiques à l'échelle, y compris sur des fonctions Lambda et des intégrations SaaS. Pour les équipes qui industrialisent leurs agents IA, ce pattern représente une brique d'infrastructure critique pour passer du prototype au déploiement régi par des exigences d'entreprise réelles.

UELes entreprises européennes déployant des agents IA sur AWS peuvent s'appuyer sur cette architecture pour implémenter des couches de conformité RGPD et AI Act sans refactoriser leurs bibliothèques de filtrage MCP existantes.

InfrastructureActu
1 source
Amazon Bedrock Knowledge Bases : créer et déployer une solution de synchronisation automatique
225AWS ML Blog 

Amazon Bedrock Knowledge Bases : créer et déployer une solution de synchronisation automatique

Amazon Web Services a publié la description d'une solution serverless permettant de synchroniser automatiquement les bases de connaissances Amazon Bedrock avec les documents stockés dans Amazon S3, sans aucune intervention manuelle. Conçue selon une architecture événementielle, elle repose sur cinq services AWS articulés ensemble : EventBridge capte les modifications dans les buckets S3 en temps réel, des fonctions Lambda traitent ces événements, des files SQS absorbent les pics de requêtes, Step Functions orchestre le flux de synchronisation, et DynamoDB assure le suivi des changements et des métadonnées de jobs. Le tout se déploie via AWS SAM (Serverless Application Model), sans infrastructure à provisionner ni à maintenir. Deloitte figure parmi les entreprises ayant adopté ce type d'approche pour moderniser leur infrastructure de tests et de traitement documentaire. L'enjeu est considérable pour les organisations qui utilisent Bedrock Knowledge Bases dans des environnements multi-utilisateurs ou des applications critiques comme les systèmes de support client. Amazon Bedrock impose des quotas stricts : au maximum cinq jobs d'ingestion simultanés par compte AWS, un seul job par base de connaissances et un seul par source de données. L'API StartIngestionJob est en outre limitée à 0,1 requête par seconde, soit une requête toutes les dix secondes et par région. Sans orchestration, lorsqu'une équipe contenu met à jour plusieurs fichiers lors d'une release, les requêtes s'accumulent, percutent ces plafonds et finissent par nécessiter une supervision manuelle. La solution absorbe ces rafales en mettant les demandes en file d'attente via SQS et en les émettant au rythme autorisé par l'API, de façon totalement transparente. Amazon Bedrock Knowledge Bases est le service RAG (Retrieval-Augmented Generation) d'AWS qui permet aux modèles de fondation et aux agents IA d'accéder aux données privées d'une organisation afin de produire des réponses plus précises et contextualisées. Jusqu'ici, toute modification dans S3, ajout, suppression ou mise à jour de métadonnées, exigeait une synchronisation déclenchée manuellement, processus sujet aux oublis et aux retards. Ce manque de synchronisation en temps réel constitue l'un des principaux points de friction dans le déploiement d'agents IA en production. La solution proposée élimine ce point de friction pour les équipes travaillant en continu sur des bases documentaires volumineuses, et représente une avancée concrète vers des systèmes d'IA d'entreprise capables de rester à jour sans supervision humaine permanente.

OutilsOutil
1 source
Créer des agents Strands avec les modèles SageMaker AI et MLflow
226AWS ML Blog 

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.

UECette 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é.

OutilsOutil
1 source
227AWS 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
228AWS ML Blog 

Amazon SageMaker AI accélère l'inférence d'IA générative avec les instances G7e

Amazon Web Services a annoncé la disponibilité des instances G7e sur Amazon SageMaker AI, une nouvelle génération de serveurs d'inférence propulsés par les GPU NVIDIA RTX PRO 6000 Blackwell Server Edition. Ces instances sont disponibles en configurations de 1, 2, 4 et 8 GPU, chaque carte offrant 96 Go de mémoire GDDR7. Concrètement, une instance G7e.2xlarge à GPU unique peut désormais héberger des modèles open source de 35 milliards de paramètres comme Qwen3.5-35B ou GPT-OSS-120B, tandis qu'une configuration à 8 GPU (G7e.48xlarge) atteint 768 Go de mémoire GPU totale et peut faire tourner des modèles de 300 milliards de paramètres sur un nœud unique. La bande passante réseau grimpe à 1 600 Gbps via EFA, soit quatre fois plus que la génération G6e et seize fois plus que les G5. Ces chiffres ont une implication directe pour les équipes d'ingénierie : des modèles qui nécessitaient auparavant plusieurs machines interconnectées peuvent désormais s'exécuter sur un seul nœud, supprimant la latence inter-nœuds et la complexité opérationnelle associée. Les performances d'inférence sont jusqu'à 2,3 fois supérieures à celles des G6e. Pour les applications temps réel comme les chatbots, les pipelines RAG ou les workflows agentiques, cette densité mémoire combinée à une bande passante CPU-GPU quatre fois plus élevée se traduit par des temps de réponse plus courts sous charge élevée. Les modèles multimodaux et de génération d'images, souvent limités par des erreurs de mémoire insuffisante sur les générations précédentes, bénéficient également directement de ce doublement de la capacité par GPU. Cette annonce s'inscrit dans une course aux accélérateurs cloud que se livrent AWS, Google et Microsoft, chacun cherchant à proposer les GPU les plus récents de NVIDIA au plus vite après leur lancement. Les puces Blackwell de NVIDIA, dont la RTX PRO 6000 Server Edition fait partie, représentent la cinquième génération de Tensor Cores avec support natif de la précision FP4, permettant de réduire encore la consommation mémoire pour les grands modèles. Le support de NVIDIA GPUDirect RDMA via EFAv4 ouvre également la voie à des scénarios d'inférence multi-nœuds à faible latence, jusqu'ici peu pratiques sur les instances G-series. À mesure que les modèles de langage et les systèmes agentiques continuent de grossir en taille et en complexité, la capacité à les déployer efficacement sur infrastructure managée comme SageMaker devient un avantage concurrentiel décisif pour les entreprises qui cherchent à maîtriser leurs coûts d'exploitation tout en montant en puissance.

UELes équipes techniques européennes utilisant Amazon SageMaker dans les régions AWS EU peuvent désormais déployer des modèles jusqu'à 300 milliards de paramètres sur un seul nœud, réduisant la complexité opérationnelle et les coûts d'inférence pour les applications temps réel.

InfrastructureActu
1 source
229AWS ML Blog 

Commandes omnicanales avec Amazon Bedrock AgentCore et Amazon Nova 2 Sonic

Amazon a présenté une architecture complète pour construire des systèmes de commande vocale omnicanaux en s'appuyant sur deux de ses services cloud : Amazon Bedrock AgentCore, une plateforme dédiée au déploiement d'agents IA en production, et Amazon Nova 2 Sonic, un modèle de fondation speech-to-speech disponible via Amazon Bedrock. La solution permet à une application de traiter des commandes vocales en temps réel sur plusieurs points de contact simultanément, application mobile, site web et interface vocale, tout en maintenant le contexte conversationnel entre les échanges. L'infrastructure s'appuie sur AWS CDK pour le déploiement, le protocole MCP (Model Context Protocol) pour connecter l'agent IA aux services métier, et une série de services managés : Amazon Cognito pour l'authentification OAuth 2.0, API Gateway pour exposer les endpoints REST, AWS Lambda pour la logique métier, DynamoDB pour le stockage des profils et commandes, et AWS Location Services pour les recommandations géolocalisées de points de retrait. L'intérêt principal de cette architecture réside dans sa capacité à isoler chaque composant pour les faire évoluer indépendamment. AgentCore Runtime exécute chaque session utilisateur dans une microVM isolée, ce qui garantit qu'un pic de charge sur une session n'affecte pas les autres, un problème classique des systèmes vocaux en production. Le MCP standardise la communication entre l'agent et les services backend, ce qui permet de modifier ou d'étendre la logique métier sans réécrire le code d'intégration. Pour les équipes qui construisent des expériences de commande vocale à grande échelle, restauration rapide, retail, logistique, cette séparation claire entre la couche IA, le frontend et le backend réduit significativement la complexité opérationnelle et les risques de régression lors des mises à jour. La publication de cette solution s'inscrit dans une compétition intense autour des agents IA en production. Google, Microsoft et des acteurs comme Anthropic proposent leurs propres infrastructures agentiques, mais AWS mise sur l'intégration native avec son écosystème de services cloud existants comme différenciateur clé. Nova 2 Sonic, le modèle speech-to-speech au coeur du système, représente l'entrée d'Amazon dans les interfaces vocales conversationnelles en temps réel, un segment où OpenAI s'est imposé avec GPT-4o Voice. En publiant ce tutoriel complet avec une architecture de restaurant fictive comme backend d'exemple, Amazon cherche à accélérer l'adoption par les développeurs et à établir AgentCore comme standard de fait pour le déploiement d'agents IA sur AWS. Les prochaines étapes logiques incluront probablement l'extension à d'autres modalités et l'intégration avec des systèmes de caisse et d'inventaire existants.

OutilsOutil
1 source
230AWS ML Blog 

Amazon Bedrock propose désormais une attribution détaillée des coûts

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité d'attribution granulaire des coûts pour Amazon Bedrock, son service d'inférence d'IA en cloud. Désormais, Bedrock attribue automatiquement chaque dépense d'inférence à l'identité IAM (Identity and Access Management) qui a effectué l'appel, qu'il s'agisse d'un utilisateur IAM classique, d'un rôle assumé par une application Lambda, ou d'une identité fédérée via un fournisseur comme Okta ou Microsoft Entra ID. Ces données apparaissent directement dans AWS Cost and Usage Reports (CUR 2.0) sans aucune ressource supplémentaire à gérer ni modification des workflows existants. Concrètement, un rapport peut montrer qu'Alice a dépensé 0,069 dollar en tokens d'entrée et 0,214 dollar en tokens de sortie avec Claude Sonnet 4.6, pendant que Bob a consommé 1,188 dollar au total avec Claude Opus 4.6, avec une précision à l'identité près. Il est également possible d'ajouter des tags de coût sur les identités IAM pour regrouper les dépenses par équipe, projet ou centre de coût dans AWS Cost Explorer. Cette visibilité fine répond à un besoin croissant des entreprises qui voient l'inférence IA représenter une part de plus en plus significative de leur facture cloud. Sans attribution précise, il est impossible de refacturer correctement les équipes internes, d'identifier les usages inefficaces ou de planifier les budgets. Grâce à cette fonctionnalité, un DSI peut désormais savoir exactement quelle équipe produit, quel service applicatif ou quel développeur génère quels coûts LLM, sans déployer d'infrastructure de monitoring supplémentaire. Pour les organisations qui font transiter leurs appels via une passerelle LLM centralisée, AWS recommande d'utiliser AssumeRole avec des tags de session dynamiques afin de préserver la granularité par utilisateur final, même derrière un proxy unique. Cette annonce s'inscrit dans une tendance de fond : les grands fournisseurs de cloud cherchent à rendre l'IA générative compatible avec les pratiques de gouvernance financière des entreprises. Amazon Bedrock, qui donne accès à des modèles de plusieurs éditeurs dont Anthropic, Mistral et Meta, doit convaincre les directions financières que la dépense IA est traçable et contrôlable. La concurrence avec Azure AI et Google Vertex AI pousse AWS à muscler ses outils de FinOps autour de l'IA. À mesure que les modèles comme Claude Opus deviennent plus coûteux à l'usage, la capacité à attribuer précisément chaque dollar dépensé devient un argument de vente central pour les déploiements en entreprise, où la responsabilisation budgétaire par équipe est souvent non négociable.

UELes entreprises européennes utilisant Amazon Bedrock peuvent désormais attribuer précisément leurs dépenses d'inférence IA par équipe ou projet, facilitant la gouvernance financière et la refacturation interne sans infrastructure supplémentaire.

InfrastructureActu
1 source
231AWS ML Blog 

Optimiser la recherche sémantique vidéo avec la distillation de modèles Amazon Nova sur Amazon Bedrock

Amazon Web Services a publié un tutoriel détaillé expliquant comment utiliser la technique de distillation de modèles sur Amazon Bedrock pour optimiser les systèmes de recherche sémantique vidéo. Le cœur du problème : les modèles de grande taille comme Claude Haiku d'Anthropic offrent une excellente précision pour interpréter l'intention de recherche des utilisateurs, mais ils allongent le temps de réponse à 2 à 4 secondes, représentant à eux seuls 75 % de la latence totale. La solution proposée consiste à transférer l'intelligence de routage d'un grand modèle dit "enseignant", Amazon Nova Premier, vers un modèle beaucoup plus léger dit "étudiant", Amazon Nova Micro. Le résultat : une réduction des coûts d'inférence de plus de 95 % et une baisse de la latence de 50 %, sans sacrifier la qualité de routage. L'enjeu est considérable pour les entreprises qui gèrent de larges catalogues vidéo. Lorsqu'un utilisateur tape "Olivia qui parle de son enfance dans la pauvreté", le système doit décider automatiquement quels aspects de la vidéo interroger en priorité : les métadonnées textuelles, la transcription audio, les données visuelles ou les informations structurées. Cette logique de routage devient rapidement complexe à l'échelle enterprise, où les attributs peuvent inclure les angles de caméra, le sentiment, les droits de diffusion ou des taxonomies métier propriétaires. Un modèle plus petit et distillé qui maîtrise cette tâche précise permet de traiter davantage de requêtes simultanément, à un coût marginal quasi nul, ce qui change fondamentalement l'équation économique des moteurs de recherche multimodaux. La distillation de modèles se distingue du fine-tuning supervisé classique par un avantage pratique majeur : elle ne nécessite pas de dataset entièrement étiqueté par des humains. Amazon Bedrock génère automatiquement jusqu'à 15 000 paires prompt-réponse en interrogeant le modèle enseignant, en appliquant des techniques de synthèse et d'augmentation de données. Dans ce pipeline, 10 000 exemples synthétiques ont été produits via Nova Premier, chargés sur Amazon S3, puis utilisés pour entraîner Nova Micro. Le modèle résultant est ensuite évalué via Amazon Bedrock Model Evaluation, comparé à la base Nova Micro et au Claude Haiku original. AWS a publié l'intégralité du notebook Jupyter, le script de génération des données et les utilitaires d'évaluation sur GitHub, rendant cette approche reproductible pour toute équipe souhaitant industrialiser la recherche vidéo à grande échelle.

OutilsTuto
1 source
NewBird AI : comment le virage technologique d’Allbirds a fait bondir son action de 600 %
232Le Big Data 

NewBird AI : comment le virage technologique d’Allbirds a fait bondir son action de 600 %

Le 15 avril 2026, Allbirds, fabricant américain de chaussures durables, a annoncé l'abandon total de son activité historique pour se repositionner sous le nom NewBird AI, avec pour nouvelle mission de fournir des infrastructures de calcul dédiées à l'intelligence artificielle. L'annonce a provoqué une envolée boursière spectaculaire : le titre a bondi jusqu'à 876 % en séance avant de clôturer à 16,99 dollars, soit une progression de 582 % en une seule journée depuis les 2,49 dollars du matin. Concrètement, l'entreprise a cédé l'ensemble de ses marques et actifs liés à la chaussure à American Exchange Group pour 39 millions de dollars, et a simultanément sécurisé une facilité de financement convertible de 50 millions de dollars auprès d'un investisseur institutionnel. Ces fonds serviront à acquérir des GPU haute performance et à construire une offre de type GPU-as-a-Service, c'est-à-dire la location de puissance de calcul à des entreprises souhaitant entraîner ou faire tourner des modèles d'IA. Ce pivot illustre de façon saisissante comment la pénurie mondiale de ressources de calcul est devenue un levier de création de valeur capable de transformer instantanément la perception d'une entreprise sur les marchés, même si celle-ci n'avait aucun lien historique avec la technologie. Pour les entreprises confrontées à des délais et des contraintes d'accès aux GPU chez les grands fournisseurs cloud, une offre alternative flexible représente une réponse concrète à un goulot d'étranglement structurel. NewBird AI ne cherche pas à concurrencer AWS, Google Cloud ou Azure frontalement, mais à occuper les interstices du marché : des clients qui ne peuvent pas obtenir de capacités de manière fiable ou rapide auprès des hyperscalers traditionnels. La proposition de valeur repose sur la disponibilité immédiate et des contrats de location à long terme. Allbirds avait été introduite en Bourse en novembre 2021 à 15 dollars l'action, levant près de 348 millions de dollars sur la promesse d'une marque de chaussures éco-responsables. Depuis, la trajectoire avait été régulièrement pénalisée par la baisse des ventes, des pertes croissantes et un recul d'image, ramenant le titre à moins de 3 dollars début 2026. Ce pivot radical s'inscrit dans une tendance plus large où des sociétés cotées en difficulté cherchent à capter l'enthousiasme des investisseurs pour l'IA en procédant à des rebranding agressifs, parfois sans historique technique ni infrastructure préexistante. La capacité de NewBird AI à réellement déployer des actifs GPU compétitifs et à attirer une clientèle stable face à des acteurs déjà établis dans le GPUaaS, comme CoreWeave, reste à démontrer dans les prochains trimestres.

BusinessOpinion
1 source
233AWS ML Blog 

Déploiements par cas d'usage sur SageMaker JumpStart

Amazon a annoncé le lancement des déploiements optimisés sur SageMaker JumpStart, une nouvelle fonctionnalité qui permet aux entreprises utilisant AWS de configurer leurs modèles d'intelligence artificielle en fonction de cas d'usage précis plutôt que de simples paramètres techniques génériques. Disponible dès maintenant dans SageMaker Studio, cette mise à jour concerne une trentaine de modèles au lancement, dont plusieurs variantes de Meta Llama 3.1 et 3.2 (de 1B à 70B paramètres), Mistral 7B et Mistral Small 24B, les modèles Qwen3 d'Alibaba (jusqu'à 32B), Phi-3 de Microsoft, Gemma de Google et Falcon3 de TII. Les utilisateurs choisissent d'abord un cas d'usage textuel, rédaction générative, interaction de type chat, résumé de contenu, questions-réponses, puis sélectionnent une contrainte d'optimisation parmi quatre options : coût, débit, latence ou performance équilibrée. Une configuration de déploiement préconfigurée est alors générée automatiquement pour l'endpoint SageMaker. Ce changement répond à une limite concrète du système précédent : JumpStart proposait jusque-là de configurer les déploiements selon le nombre d'utilisateurs simultanés attendus, avec visibilité sur la latence P50, le temps avant le premier token (TTFT) et le débit en tokens par seconde. Ce modèle était utile pour des scénarios généralistes, mais ignorait que les performances optimales varient radicalement selon le type de tâche. Un système de résumé de documents longs n'a pas les mêmes besoins qu'un chatbot temps réel ou qu'un pipeline de génération de contenu en batch. En exposant directement ces dimensions aux équipes produit et data, AWS réduit la friction entre la sélection d'un modèle et sa mise en production effective, sans exiger d'expertise fine en infrastructure GPU ni en tuning de serving. Cette évolution s'inscrit dans la compétition acharnée que se livrent les grands fournisseurs cloud, AWS, Google Cloud et Microsoft Azure, pour capter les budgets d'inférence IA des entreprises. SageMaker JumpStart existe depuis plusieurs années comme point d'entrée vers les modèles pré-entraînés sur AWS, mais la plateforme cherche à monter en valeur face à des alternatives comme Vertex AI Model Garden ou Azure AI Studio qui proposent également des expériences de déploiement guidées. Le support des modèles image et vidéo est annoncé comme prochaine étape, et la liste des modèles compatibles est présentée comme amenée à s'élargir rapidement. Pour les entreprises déjà dans l'écosystème AWS, cette simplification pourrait accélérer les cycles de mise en production de modèles open-source sans passer par des équipes MLOps dédiées.

UELes entreprises européennes déployant des modèles open-source sur AWS peuvent réduire leur dépendance aux équipes MLOps grâce à cette simplification du cycle de mise en production.

OutilsOutil
1 source
DustPhotonics : La nouvelle cible prioritaire d’Intel et Nvidia dans l’IA
234Le Big Data 

DustPhotonics : La nouvelle cible prioritaire d’Intel et Nvidia dans l’IA

La start-up israélienne DustPhotonics, fondée en 2017 et spécialisée dans les puces photoniques, serait en négociations avancées pour un rachat estimé à plusieurs centaines de millions de dollars. Intel, Nvidia et Amazon figurent parmi les acheteurs potentiels les plus sérieux, selon des informations publiées le 12 avril 2026 par le média israélien Calcalist. L'entreprise, qui a levé plus de 100 millions de dollars depuis sa création, développe des composants capables de transmettre des données à des vitesses comprises entre 400 Gbit/s et 1,6 Tbit/s en utilisant la lumière plutôt que l'électricité. En 2021, sous l'impulsion de son PDG Ronnen Lovinger, DustPhotonics a opéré un pivot stratégique en abandonnant les émetteurs-récepteurs et câbles pour se concentrer exclusivement sur le développement de puces intégrées, ce qui lui a permis de monter significativement en valeur dans la chaîne technologique. L'enjeu dépasse largement cette seule transaction. Les câbles en cuivre qui relient les processeurs dans les grands centres de données atteignent leurs limites physiques face aux exigences croissantes des clusters d'IA : latence trop élevée, consommation énergétique excessive, bande passante insuffisante. Les goulets d'étranglement ne se situent plus uniquement dans les GPU ou la mémoire, mais dans la circulation de l'information entre les composants. La photonique sur silicium, qui intègre directement des composants optiques dans les puces, s'impose comme une réponse structurelle à ce problème. Pour Nvidia, acquérir DustPhotonics permettrait d'internaliser une technologie critique et de réduire sa dépendance à des fournisseurs externes comme Coherent, avec qui le groupe a déjà contracté des engagements de plusieurs milliards de dollars. Amazon viserait une intégration directe dans ses infrastructures cloud, tandis qu'Intel chercherait à combler son retard dans la course à l'IA. La crédibilité de DustPhotonics repose aussi sur son actionnariat. Son président, Avigdor Willenz, a déjà orchestré deux sorties majeures : la vente de Habana Labs à Intel et celle d'Annapurna Labs à AWS, deux transactions qui ont rapporté plusieurs milliards de dollars. Ce palmarès renforce la probabilité d'un nouvel exit réussi. L'entreprise n'évolue pas seule sur ce marché en effervescence, Ayar Labs et Xscape Photonics développent des approches concurrentes, mais son positionnement sur les puces intégrées à haute vitesse la distingue. La consolidation autour des interconnexions optiques s'accélère à mesure que les géants technologiques cherchent à sécuriser chaque brique critique de leur infrastructure IA, un mouvement qui devrait s'intensifier dans les prochains mois.

InfrastructureOpinion
1 source
Supervision humaine dans les workflows d'agents autonomes en santé et sciences du vivant
235AWS ML Blog 

Supervision humaine dans les workflows d'agents autonomes en santé et sciences du vivant

Amazon Web Services a publié un guide technique détaillant quatre approches concrètes pour intégrer une supervision humaine dans les workflows d'agents IA déployés dans le secteur de la santé et des sciences du vivant. Ces architectures s'appuient sur le framework Strands Agents, Amazon Bedrock AgentCore Runtime et le Model Context Protocol (MCP), et sont conçues pour répondre aux exigences réglementaires GxP qui imposent une traçabilité complète de chaque décision sensible. Les quatre méthodes présentées couvrent des scénarios différents : interruption via un système de hooks dans la boucle agentique, contrôle intégré directement dans la logique des outils, délégation asynchrone à un approbateur externe via AWS Step Functions et Amazon SNS, et enfin l'élicitation native du protocole MCP pour une approbation interactive en temps réel via des événements server-sent (SSE). L'enjeu est considérable pour les établissements de santé et les laboratoires pharmaceutiques qui automatisent des opérations à fort impact : codification médicale, soumissions réglementaires, accès aux données de patients ou modification de protocoles d'essais cliniques. Sans point de contrôle humain formalisé, ces systèmes ne peuvent pas satisfaire aux exigences GxP, qui imposent une autorisation documentée avant toute action sur des données de santé protégées (PHI). L'architecture proposée distingue explicitement les niveaux de risque : une recherche du nom d'un patient s'exécute sans validation, la consultation de ses constantes vitales ou antécédents médicaux déclenche une demande d'autorisation humaine, et un acte comme une sortie hospitalière nécessite l'approbation d'un superviseur externe notifié par email. Cette gradation permet de préserver les gains d'efficacité de l'automatisation tout en maintenant la sécurité des patients et la conformité réglementaire. L'émergence des agents IA dans les environnements GxP crée une tension fondamentale entre autonomie des systèmes et obligations légales de surveillance. Le secteur pharmaceutique et hospitalier est soumis à des audits stricts qui exigent de pouvoir retracer qui a approuvé quoi, et à quel moment, pour chaque opération sensible. AWS positionne ici ses services managés comme une infrastructure d'entreprise capable d'absorber ces contraintes sans ralentir les pipelines de traitement clinique. Le choix d'une architecture serverless via AgentCore Runtime vise l'isolation des sessions et la scalabilité, deux propriétés critiques pour des environnements multi-établissements. Le code de l'ensemble des patterns est disponible publiquement sur GitHub, ce qui suggère une stratégie d'adoption large : AWS cherche à s'imposer comme la référence d'infrastructure pour l'IA agentique réglementée, un marché en forte croissance à mesure que les hôpitaux et les grands groupes pharmaceutiques passent à l'échelle leurs expérimentations en production.

UELes établissements de santé et laboratoires pharmaceutiques européens soumis aux réglementations GxP et à la certification HDS peuvent adapter ces patterns d'architecture pour conformer leurs déploiements d'agents IA aux exigences de traçabilité et d'approbation documentée imposées par les autorités sanitaires européennes.

OutilsOutil
1 source
Affinage par renforcement sur Amazon Bedrock : bonnes pratiques
236AWS ML Blog 

Affinage par renforcement sur Amazon Bedrock : bonnes pratiques

Amazon a intégré le Reinforcement Fine-Tuning (RFT) à sa plateforme Bedrock, permettant aux entreprises de personnaliser ses modèles maison Amazon Nova ainsi que plusieurs modèles open source sans avoir besoin de vastes jeux de données étiquetés. Selon les résultats publiés par l'entreprise, cette technique peut générer jusqu'à 66 % de gain de précision par rapport aux modèles de base, à un coût et une complexité réduits. Concrètement, le RFT fonctionne différemment de l'apprentissage supervisé classique : au lieu de s'entraîner sur des paires entrée/sortie correctes, le modèle génère des réponses candidates, qui sont ensuite notées par une fonction de récompense, et ses paramètres sont mis à jour pour favoriser les réponses les mieux notées. Cette boucle itéractive, générer, scorer, ajuster, permet au modèle de découvrir des stratégies que de simples exemples statiques ne pourraient pas lui enseigner. La fonction de récompense est implémentée via AWS Lambda, directement appelée par Bedrock pendant l'entraînement. Cette approche ouvre des possibilités concrètes pour deux grandes familles de tâches. D'un côté, les tâches à critères vérifiables automatiquement : génération de code devant passer des tests unitaires, raisonnement mathématique avec réponses exactes, extraction de données structurées devant respecter un schéma strict, ou orchestration d'API. C'est ce qu'Amazon appelle le RLVR (Reinforcement Learning with Verifiable Rewards). De l'autre côté, les tâches subjectives comme la modération de contenu, les chatbots ou la rédaction créative, où un modèle juge évalue les sorties selon une grille d'évaluation détaillée, approche baptisée RLAIF (Reinforcement Learning with AI Feedback). Pour les équipes techniques, l'intérêt est d'éviter la collecte laborieuse de milliers d'exemples annotés, particulièrement difficile à réaliser pour des tâches de raisonnement complexe où l'expertise humaine est coûteuse. Le RFT s'inscrit dans une tendance lourde de l'industrie IA depuis les succès de DeepSeek-R1 début 2025, qui avait démontré que l'entraînement par renforcement sur des tâches vérifiables pouvait produire des capacités de raisonnement spectaculaires à moindre coût. Amazon emboîte le pas en industrialisant cette technique dans un service cloud managé, ce qui la rend accessible aux équipes sans infrastructure d'entraînement propre. En proposant RFT directement dans Bedrock avec des métriques de suivi intégrées et des guidelines de tuning d'hyperparamètres, Amazon cherche à s'imposer face à Azure et Google Cloud sur le segment de la personnalisation de modèles en entreprise. Le dataset GSM8K, utilisé comme exemple de référence dans la documentation, illustre bien l'ambition : transformer des modèles généralistes en spécialistes fiables sur des domaines métier précis, sans expertise en machine learning approfondie.

UELes entreprises européennes sur AWS peuvent désormais affiner des modèles IA sans jeux de données annotés massifs ni infrastructure ML propre, abaissant la barrière d'entrée pour la personnalisation de modèles en production.

OutilsOutil
1 source
Amazon utilise des agents IA pour la détection de vulnérabilités à grande échelle
237Amazon Science 

Amazon utilise des agents IA pour la détection de vulnérabilités à grande échelle

En 2025, la base de données nationale des vulnérabilités américaine (NVD) a enregistré plus de 48 000 nouvelles failles de sécurité référencées (CVE), un volume rendu possible en grande partie par la prolifération des outils automatisés de détection. Face à cette explosion, Amazon Web Services a développé RuleForge, un système d'intelligence artificielle agentique conçu pour générer automatiquement des règles de détection à partir d'exemples de code d'exploitation de vulnérabilités. Déployé en production chez AWS, RuleForge affiche une productivité supérieure de 336 % à la création manuelle, tout en conservant le niveau de précision exigé pour des systèmes de sécurité industriels. Les règles produites sont au format JSON et alimentent directement MadPot, le système mondial de "honeypot" d'Amazon qui capture le comportement des attaquants, ainsi que Sonaris, le moteur interne de détection d'exploits suspects. Avant RuleForge, transformer une CVE en règle de détection opérationnelle était un processus entièrement manuel : un analyste téléchargeait le code de preuve de concept, étudiait le mécanisme d'attaque, rédigeait la logique de détection, la validait par itérations successives contre les journaux de trafic, puis soumettait le tout à une revue par un second ingénieur avant déploiement. Ce cycle, rigoureux mais lent, obligeait les équipes à prioriser strictement les vulnérabilités traitées, laissant potentiellement des failles critiques sans couverture. RuleForge comprime ce délai de façon drastique : le système ingère automatiquement le code d'exploitation public, attribue un score de priorité via une analyse de contenu croisée avec des sources de threat intelligence, puis génère en parallèle plusieurs règles candidates via un agent tournant sur AWS Fargate avec Amazon Bedrock. Chaque candidate est évaluée non pas par le modèle qui l'a produite, mais par un agent "juge" distinct, évitant ainsi l'auto-validation biaisée. Les humains restent dans la boucle pour l'approbation finale avant mise en production. Cette architecture reflète une tendance profonde dans la sécurité offensive et défensive : l'automatisation par IA ne remplace pas les experts, elle leur permet de travailler à une échelle autrement inaccessible. AWS anticipe une croissance continue du nombre de CVE à haute sévérité publiées, portée par les mêmes outils d'IA qui accélèrent la découverte de failles côté attaquants. RuleForge représente la réponse symétrique côté défense, en industrialisant la réactivité. L'approche modulaire, avec des agents spécialisés pour la génération, l'évaluation et le raffinement, plutôt qu'un seul modèle monolithique, s'inscrit dans la lignée des architectures multi-agents qui émergent comme standard pour les tâches complexes nécessitant fiabilité et auditabilité. D'autres grands acteurs du cloud font face aux mêmes défis, et la publication par Amazon des détails de RuleForge suggère une volonté de positionner cette approche comme référence sectorielle.

SécuritéActu
1 source
Amazon Bedrock Projects : gérer les coûts de l'IA
238AWS ML Blog 

Amazon Bedrock Projects : gérer les coûts de l'IA

Amazon a lancé une nouvelle fonctionnalité appelée Amazon Bedrock Projects, qui permet aux équipes techniques d'attribuer précisément les coûts d'inférence IA à des charges de travail spécifiques. Concrètement, chaque "projet" dans Bedrock constitue une frontière logique représentant une application, un environnement ou une expérimentation. Les développeurs associent des tags de ressources à ces projets et transmettent un identifiant de projet dans leurs appels API. Ces données remontent ensuite dans AWS Cost Explorer et AWS Data Exports, les outils de suivi financier d'Amazon Web Services, permettant de filtrer, regrouper et analyser les dépenses par dimension métier : application, équipe, environnement ou centre de coûts. La fonctionnalité est compatible avec les API OpenAI (Responses API et Chat Completions API), ce qui facilite l'intégration pour les équipes déjà habituées à ces standards. Les requêtes envoyées sans identifiant de projet sont automatiquement rattachées à un projet par défaut dans le compte AWS concerné. L'enjeu est direct pour les grandes organisations qui font tourner plusieurs applications IA en parallèle : sans attribution précise, impossible de savoir quelle équipe consomme quoi, ni d'effectuer des refacturations internes (chargebacks) ou d'investiguer des pics de dépenses inexpliqués. Bedrock Projects répond à ce besoin en donnant une visibilité granulaire sur la facture IA, département par département. Une équipe "CustomerExperience" peut ainsi être distinguée d'une équipe "DataScience", chacune avec son propre centre de coûts. Cela permet également de guider les décisions d'optimisation : identifier quels workloads sont disproportionnément coûteux par rapport à leur valeur métier, et agir en conséquence. Cette annonce s'inscrit dans une tendance plus large de maturité de la FinOps appliquée à l'IA. À mesure que les déploiements LLM passent du stade expérimental à la production à grande échelle, la gestion financière devient un enjeu stratégique autant que technique. AWS rejoint ainsi des préoccupations déjà bien présentes chez les DSI et les directeurs financiers, qui voient les budgets cloud IA gonfler rapidement sans toujours disposer des outils pour les piloter. La stratégie de tags recommandée par Amazon -- Application, Environment, Team, CostCenter -- reflète les pratiques standard de gouvernance cloud, mais appliquées désormais spécifiquement à la couche inférence. Les prochaines étapes logiques pourraient inclure des alertes budgétaires par projet ou des quotas d'utilisation, des mécanismes déjà existants dans AWS pour d'autres services et qui manquent encore à Bedrock Projects dans sa forme actuelle.

UELes organisations européennes utilisant AWS Bedrock peuvent désormais mieux contrôler et attribuer leurs coûts d'inférence IA, un enjeu croissant pour les DSI soumis à des contraintes budgétaires strictes.

OutilsActu
1 source
Amazon SageMaker AI accélère les appels d'outils des agents autonomes avec la personnalisation de modèles sans serveur
239AWS ML Blog 

Amazon SageMaker AI accélère les appels d'outils des agents autonomes avec la personnalisation de modèles sans serveur

Amazon a introduit une fonctionnalité de personnalisation de modèles sans serveur dans SageMaker AI, permettant aux équipes d'améliorer drastiquement les capacités d'appel d'outils des agents IA sans gérer d'infrastructure GPU. Dans un cas concret publié début avril 2026, des ingénieurs ont affiné le modèle Qwen 2.5 7B Instruct en utilisant la technique RLVR (Reinforcement Learning with Verifiable Rewards) et ont obtenu une amélioration de 57% du score de qualité des appels d'outils sur des scénarios inédits, c'est-à-dire des outils que le modèle n'avait jamais vus lors de l'entraînement. La méthode repose sur un principe simple : le modèle génère huit réponses candidates par prompt, une fonction de récompense vérifie lesquelles sont correctes, et l'algorithme GRPO (Group Relative Policy Optimization) renforce les comportements qui surpassent la moyenne du groupe. SageMaker AI prend en charge les familles de modèles Amazon Nova, Llama, Qwen et DeepSeek, avec un suivi des métriques via MLflow intégré. L'enjeu est concret : les agents IA en production échouent fréquemment lors des appels d'outils, qu'il s'agisse d'halluciner des fonctions inexistantes, de passer des paramètres incorrects, ou de déclencher une action là où ils devraient demander une clarification. Ces erreurs bloquent le déploiement en production et détruisent la confiance des utilisateurs. La nouvelle approche serverless d'Amazon supprime l'obstacle opérationnel majeur que représentait jusqu'ici le fine-tuning par renforcement : achat de GPU, orchestration mémoire entre les phases de rollout et d'entraînement, infrastructure de récompenses, gestion des checkpoints. Les équipes peuvent désormais se concentrer sur leurs données, leur modèle et leur fonction de récompense, le reste étant géré par la plateforme. Le fine-tuning supervisé classique (SFT) montre ses limites pour ce type de tâche : il nécessite des exemples étiquetés pour chaque comportement souhaité, mais peine à généraliser la prise de décision entre appeler un outil, demander des informations supplémentaires, ou refuser d'agir. RLVR contourne ce problème en exploitant la nature vérifiable des appels d'outils : soit le modèle a appelé la bonne fonction avec les bons paramètres, soit non. Cette objectivité binaire rend l'appel d'outils particulièrement adapté à l'apprentissage par renforcement. Amazon positionne cette offre dans un marché de l'IA agentique en forte croissance, où des acteurs comme Google (Vertex AI), Microsoft (Azure ML) et des startups spécialisées se disputent les équipes qui cherchent à industrialiser des agents fiables, avec un accès simplifié via SageMaker Studio et un compte AWS standard.

OutilsActu
1 source
Les domaines accessibles à vos agents IA sont désormais configurables
240AWS ML Blog 

Les domaines accessibles à vos agents IA sont désormais configurables

Amazon a dévoilé une architecture de sécurité pour ses agents IA déployés via Amazon Bedrock AgentCore, permettant aux entreprises de contrôler précisément quels domaines internet ces agents peuvent atteindre. La solution repose sur AWS Network Firewall, configuré dans un Amazon VPC (Virtual Private Cloud) privé, qui inspecte les en-têtes SNI (Server Name Indication) des connexions TLS pour filtrer le trafic sortant. Concrètement, les équipes peuvent définir une liste blanche de domaines autorisés — par exemple wikipedia.org ou stackoverflow.com — bloquer des catégories entières comme les réseaux sociaux ou les sites de jeux d'argent, et appliquer une politique de refus par défaut pour tout domaine non explicitement approuvé. Tous les tentatives de connexion sont journalisées, ce qui permet un suivi d'audit et une conformité réglementaire. AgentCore intègre trois outils managés concernés : un navigateur web (Browser), un interpréteur de code (Code Interpreter) et un environnement d'exécution (Runtime). Cette capacité de filtrage répond à un besoin critique pour les entreprises déployant des agents IA dans des secteurs réglementés — finance, santé, défense. Sans contrôle réseau, un agent web autonome peut être manipulé via une attaque par injection de prompt pour naviguer vers des sites non autorisés, exfiltrer des données sensibles ou contacter des domaines malveillants. En restreignant le navigateur à une liste de domaines approuvés, la surface d'attaque est drastiquement réduite, indépendamment des instructions reçues par l'agent. Pour les fournisseurs SaaS multi-locataires, la granularité est encore plus fine : chaque client peut avoir sa propre politique réseau, avec des règles d'autorisation ou de blocage différentes selon le tenant, voire selon la région géographique ou le type d'exécution. Cette annonce s'inscrit dans une tendance plus large de sécurisation des agents IA autonomes, un sujet qui monte en puissance à mesure que les déploiements en production se multiplient. Amazon Bedrock AgentCore est une plateforme relativement récente, et cette intégration avec Network Firewall constitue une première couche de défense en profondeur — AWS précise qu'elle peut être complétée par du filtrage DNS et de l'inspection de contenu. Des mécanismes complémentaires existent également côté accès entrant, via des politiques basées sur les ressources avec conditions sur l'IP source ou le VPC d'origine. La prochaine étape pour les entreprises sera probablement d'automatiser ces politiques réseau au niveau des pipelines CI/CD, pour que chaque déploiement d'agent embarque ses règles de filtrage dès le départ.

UELes entreprises européennes déployant des agents IA sur AWS dans des secteurs réglementés (finance, santé) peuvent enforcer des politiques réseau conformes aux exigences de l'AI Act et des réglementations sectorielles.

SécuritéActu
1 source
Un système alimenté par IA pour la collecte de preuves de conformité
241AWS ML Blog 

Un système alimenté par IA pour la collecte de preuves de conformité

Des équipes d'Amazon Web Services ont développé et documenté un système automatisé de collecte de preuves pour les audits de conformité, s'appuyant sur Amazon Bedrock et une extension de navigateur compatible Chrome et Firefox. Concrètement, l'outil exécute des workflows prédéfinis qui naviguent automatiquement dans des interfaces web — GitHub, consoles AWS, applications internes — en capturant des captures d'écran horodatées, puis les stocke de manière organisée dans Amazon S3. Le cœur intelligent du système repose sur le modèle Amazon Nova 2 Lite : lorsqu'un auditeur lui soumet un document de conformité en langage naturel, le modèle l'analyse et génère automatiquement les workflows JSON exécutables correspondants. En fin de cycle, Amazon SES produit et envoie un rapport de conformité par e-mail. L'authentification est gérée via Amazon Cognito couplé à AWS STS et IAM, garantissant des accès à privilèges minimaux vers Bedrock, S3 et SES. L'impact est direct pour les équipes de conformité et de sécurité des entreprises, qui consacrent aujourd'hui des dizaines d'heures par cycle d'audit à des tâches manuelles répétitives — naviguer de page en page, faire des captures d'écran, les renommer et les classer. Ce système rend le processus reproductible à l'identique d'un audit à l'autre, élimine les erreurs humaines de capture ou d'organisation, et produit une piste d'audit complète avec horodatage et chiffrement au repos. L'approche par extension navigateur présente un avantage structurel important : elle fonctionne avec n'importe quelle application web sans nécessiter d'accès API spécifique, et s'adapte aux évolutions d'interface grâce à l'automatisation pilotée par IA plutôt que par des sélecteurs CSS fragiles. Ce développement s'inscrit dans une tendance plus large d'industrialisation des agents IA pour des tâches d'entreprise à haute valeur réglementaire. Les audits SOC 2, ISO 27001 ou PCI-DSS imposent des volumes de preuves considérables, et la pression réglementaire sur les entreprises tech ne faiblit pas — notamment en Europe avec NIS2 et l'AI Act. AWS positionne ici Bedrock non pas comme un simple moteur de génération de texte, mais comme une couche d'orchestration capable de piloter des interfaces utilisateur réelles, ce qui représente un saut qualitatif par rapport aux intégrations API classiques. La prochaine étape logique sera l'extension de ces agents à des workflows multi-systèmes entièrement autonomes, où l'humain ne valide plus que l'exception — un modèle qui soulève déjà des questions sur la supervision et la responsabilité dans les processus réglementaires.

UELes entreprises européennes soumises à NIS2 ou à l'AI Act pourraient adopter des approches similaires pour automatiser la collecte de preuves d'audit, réduisant la charge de conformité réglementaire.

OutilsOutil
1 source
Ring optimise son support client mondial avec Amazon Bedrock Knowledge Bases
242AWS ML Blog 

Ring optimise son support client mondial avec Amazon Bedrock Knowledge Bases

Ring, la filiale de sécurité domestique d'Amazon, a déployé en production un chatbot de support client multilingue fondé sur la technologie RAG (Retrieval-Augmented Generation), en s'appuyant sur Amazon Bedrock Knowledge Bases. Le système couvre aujourd'hui 10 régions internationales — dont le Royaume-Uni, l'Allemagne et huit autres marchés — depuis une infrastructure centralisée unique. Résultat concret : chaque nouvelle locale ajoutée au dispositif coûte désormais 21 % moins cher qu'avec l'architecture précédente, qui exigeait des déploiements d'infrastructure distincts par région. La solution mobilise Amazon Bedrock, AWS Lambda, AWS Step Functions et Amazon S3, dans une logique entièrement serverless. Le projet a été développé en collaboration avec David Kim et Premjit Singh, ingénieurs chez Ring. Ce déploiement répond à des limites très concrètes de l'ancien système. Ring utilisait jusqu'ici un chatbot basé sur des règles prédéfinies, construit avec Amazon Lex : pendant les pics d'activité, 16 % des interactions client devaient être escaladées vers des agents humains, faute de réponses adaptées. Les ingénieurs consacraient par ailleurs 10 % de leur temps à la maintenance de ce système rigide. L'expansion internationale a rendu cette approche intenable : chaque territoire nécessite des informations produits spécifiques — spécifications électriques, conformité réglementaire locale, configurations matérielles distinctes — qui ne se réduisent pas à une simple traduction. Le nouveau système permet de servir ce contenu différencié depuis un référentiel unique, en appliquant un filtrage par métadonnées (balises de locale) pour délivrer les bonnes informations au bon marché, sans infrastructure dédiée par région. L'architecture repose sur une séparation en deux flux : l'ingestion et l'évaluation d'un côté, la promotion en production de l'autre. Cette organisation en deux phases permet à l'équipe éditoriale de Ring de publier des mises à jour de guides produits, articles de dépannage et documentation de support, qui se propagent automatiquement à toutes les locales sans intervention manuelle. La latence de bout en bout visée est de 7 à 8 secondes ; l'analyse de performance a montré que la latence liée à la distance géographique représente moins de 10 % du temps de réponse total, ce qui a justifié le choix d'une architecture centralisée plutôt que distribuée. Pour Ring, c'est un pivot stratégique : au lieu d'industrialiser la maintenance d'infrastructure, les équipes peuvent concentrer leurs efforts sur l'amélioration de l'expérience client. Le modèle est transposable à tout opérateur cherchant à étendre ses opérations de support à l'international sans faire exploser ses coûts opérationnels.

UELe déploiement couvre déjà le Royaume-Uni et l'Allemagne, améliorant le support client pour les utilisateurs européens des produits Ring.

OutilsActu
1 source
Construire un système de détection des éruptions solaires sur SageMaker AI avec des réseaux LSTM et les données ESA STIX
243AWS ML Blog 

Construire un système de détection des éruptions solaires sur SageMaker AI avec des réseaux LSTM et les données ESA STIX

Amazon Web Services propose une solution de détection automatique des éruptions solaires en combinant les réseaux de neurones LSTM (Long Short-Term Memory) et les données du spectromètre STIX de l'Agence spatiale européenne (ESA), le tout déployé sur la plateforme SageMaker AI. Le système analyse les émissions de rayons X solaires sur trois bandes d'énergie distinctes : basse (4–10 keV), moyenne (10–25 keV) et haute (25+ keV). Concrètement, l'architecture repose sur deux algorithmes complémentaires : le Random Cut Forest (RCF), un algorithme d'apprentissage non supervisé qui attribue des scores d'anomalie selon la densité des points de données, et le réseau LSTM, capable de mémoriser des dépendances temporelles sur de longues séquences — une propriété rare dans les réseaux de neurones classiques. L'instrument STIX, embarqué sur la sonde Solar Orbiter lancée par l'ESA, collecte en continu des volumes massifs de mesures X que ce pipeline est conçu à ingérer et analyser à grande échelle. L'enjeu est considérable : les éruptions solaires perturbent les communications radio, dégradent les orbites satellitaires et peuvent mettre en danger les astronautes. Une détection précoce et fiable conditionne directement la protection des infrastructures spatiales et des réseaux électriques terrestres. L'approche multi-canal apporte ici une valeur ajoutée concrète — les canaux basse énergie captent les phénomènes précurseurs, tandis que les canaux haute énergie trahissent les pics d'intensité les plus violents. Grâce aux propriétés de mémoire à long terme du LSTM, le modèle peut identifier des schémas d'évolution sur des périodes étendues, là où des méthodes statistiques classiques échoueraient. Pour les opérateurs de satellites commerciaux et les agences spatiales, cela se traduit par une fenêtre d'alerte élargie pour mettre en mode sécurisé les équipements sensibles. Cette publication s'inscrit dans une tendance plus large : l'application du machine learning à la physique solaire connaît une accélération marquée depuis que le volume de données issues des observatoires spatiaux dépasse les capacités d'analyse humaine. L'ESA et la NASA multiplient les missions dédiées à la météorologie spatiale — Solar Orbiter, Parker Solar Probe — générant des flux de mesures sans précédent. AWS, de son côté, cherche à positionner SageMaker comme la plateforme de référence pour les applications scientifiques à fort volume de données, en proposant des exemples concrets dans des domaines aussi variés que la climatologie ou l'astrophysique. La prochaine étape logique serait l'intégration de ce système dans des pipelines d'alerte opérationnels en temps réel, potentiellement couplés aux centres de prévision météorologique spatiale comme le Space Weather Prediction Center de la NOAA.

UEL'ESA est directement impliquée via l'instrument STIX de Solar Orbiter, et les opérateurs de satellites européens pourraient exploiter ce type de pipeline pour protéger leurs infrastructures face aux éruptions solaires.

OutilsOutil
1 source
Personnaliser l'expérience spectateur avec un assistant cinéma IA à base d'agents — Amazon Bedrock AgentCore et Nova Sonic 2.0
244AWS ML Blog 

Personnaliser l'expérience spectateur avec un assistant cinéma IA à base d'agents — Amazon Bedrock AgentCore et Nova Sonic 2.0

Amazon a dévoilé une architecture d'assistant IA conversationnel pour les plateformes de streaming vidéo, combinant Amazon Bedrock AgentCore et le nouveau modèle vocal Amazon Nova Sonic 2.0. Le système permet deux cas d'usage principaux : des recommandations de films personnalisées en temps réel selon l'humeur et le contexte de l'utilisateur, et une assistance contextuelle en cours de visionnage — permettant par exemple de demander à voix haute « qui est cet acteur ? » ou « résume ce qui vient de se passer » sans quitter le film. L'infrastructure repose sur AWS Fargate pour le traitement serveur, Amazon CloudFront et S3 pour le frontend, Amazon Cognito pour l'authentification, et OpenSearch combiné à S3 Vector pour la recherche sémantique. La communication entre le client et le serveur s'effectue via WebSocket avec validation de token JWT, tandis que le modèle vocal Nova Sonic 2.0 gère le streaming bidirectionnel en temps réel via un protocole RPC Smithy. Ce type de système représente un changement de paradigme pour les services de streaming : là où les moteurs de recommandation classiques — basés sur le filtrage collaboratif ou par contenu — se contentent de prolonger les habitudes passées, l'approche agentique intègre le contexte immédiat. Un utilisateur qui vient de regarder « Les Évadés » et veut se détendre ne se verra pas proposer un autre drame carcéral, mais quelque chose d'adapté à son état d'esprit exprimé en langage naturel. Pour les plateformes, cela ouvre la voie à une réduction du taux de désabonnement lié à la friction de découverte, l'une des principales causes d'attrition dans le secteur. Pour les utilisateurs, c'est l'équivalent d'un programmateur culturel personnel disponible en permanence. Le projet s'inscrit dans la montée en puissance des architectures dites « agentiques », où les modèles de langage ne se contentent plus de répondre à des requêtes isolées mais orchestrent des chaînes d'outils complexes. Amazon positionne ici son écosystème — Bedrock AgentCore, le protocole MCP (Model Context Protocol) pour exposer des fonctions Lambda comme outils d'agent, et Nova Sonic pour la voix — comme une pile verticale intégrée pour ce type d'application. C'est une réponse directe aux initiatives similaires de Google (avec Gemini Live) et d'OpenAI (avec les capacités vocales temps réel de GPT-4o). Le code source de la démonstration est disponible sur GitHub, signalant une stratégie d'adoption par les développeurs avant un déploiement commercial plus large. La bataille pour devenir l'infrastructure standard des expériences média augmentées par l'IA ne fait que commencer.

UELes plateformes de streaming européennes disposant d'une infrastructure AWS peuvent expérimenter cette architecture, mais aucune adoption ou réglementation spécifique à la France ou à l'UE n'est mentionnée.

OutilsOutil
1 source
Créer une IA adaptée à l'âge et au contexte avec Amazon Bedrock Guardrails
245AWS ML Blog 

Créer une IA adaptée à l'âge et au contexte avec Amazon Bedrock Guardrails

Amazon Web Services a dévoilé une architecture serverless permettant d'adapter automatiquement les réponses d'une IA générative selon le profil de l'utilisateur — son âge, son rôle professionnel et son niveau d'expertise. La solution repose sur Amazon Bedrock Guardrails, un système de filtrage centralisé qui sélectionne dynamiquement l'un des cinq profils de protection disponibles au moment de l'inférence : enfants (conforme COPPA), adolescents en contexte éducatif, professionnels de santé, patients, et adultes grand public. L'authentification passe par Amazon Cognito, les profils utilisateurs sont stockés dans Amazon DynamoDB, et l'ensemble est exposé via Amazon API Gateway et AWS Lambda, sans serveur à gérer. Concrètement, un même prompt reçoit une réponse différente selon que l'appelant est un pédiatre ou un enfant de dix ans. Cette approche répond à un problème réel dans les déploiements IA à grande échelle : les garde-fous basés uniquement sur le prompt sont contournables par des techniques de manipulation — les modèles peuvent être amenés à ignorer leurs instructions de sécurité. En centralisant les politiques dans une couche d'application indépendante du code métier, AWS rend les règles de modération non débordables par l'application elle-même. Pour les secteurs sensibles comme la santé ou l'éducation, où une réponse inappropriée peut avoir des conséquences réelles sur des utilisateurs vulnérables, ce niveau de contrôle devient un prérequis de conformité. Le résultat est aussi une réduction de la complexité opérationnelle : au lieu de maintenir des logiques de personnalisation dans chaque application, une seule configuration centralisée s'applique à l'ensemble du parc. La montée en puissance des applications IA dans des environnements réglementés — santé, éducation, services publics — a mis en lumière les limites du prompt engineering comme seule ligne de défense. Les grandes organisations déploient désormais des couches de gouvernance distinctes du modèle lui-même, une tendance que Google, Microsoft et AWS adressent chacun avec leurs propres systèmes de guardrails. La spécificité de cette implémentation Bedrock est d'associer l'identité authentifiée de l'utilisateur à une politique d'inférence en temps réel, plutôt que de laisser l'application décider. Les suites probables incluent une adoption dans les plateformes e-learning et les portails patients, où le respect du COPPA et du HIPAA est légalement contraignant, et où la traçabilité des décisions de modération devient un enjeu d'audit.

UEL'architecture proposée peut aider les entreprises européennes à se conformer à l'AI Act et au RGPD en déployant des garde-fous contextuels pour les secteurs réglementés comme la santé et l'éducation.

OutilsOutil
1 source
Affiner les LLM avec des données non structurées via SageMaker Unified Studio et S3
246AWS ML Blog 

Affiner les LLM avec des données non structurées via SageMaker Unified Studio et S3

Amazon Web Services a annoncé une intégration entre Amazon SageMaker Unified Studio et les buckets Amazon S3 grand public, permettant d'exploiter des données non structurées directement dans les workflows de machine learning. Le cas d'usage présenté illustre l'affinage du modèle Llama 3.2 11B Vision Instruct — développé par Meta — pour des tâches de questions-réponses visuelles (VQA), comme l'extraction automatique d'informations depuis des reçus ou documents scannés. Le modèle de base atteint un score ANLS de 85,3 % sur le benchmark DocVQA, une métrique mesurant la similarité entre réponse prédite et réponse attendue. Pour l'affinage, AWS utilise le dataset DocVQA de Hugging Face, qui contient 39 500 exemples d'entraînement associant image, question et réponse. Trois versions affinées sont produites avec des volumes de données variables : 1 000, 5 000 et 10 000 images, orchestrées entièrement via SageMaker Unified Studio et évaluées avec Amazon SageMaker MLflow en mode serverless. Cet affinement ciblé permet aux équipes data de dépasser les limites d'un modèle généraliste sans reconstruire une infrastructure complexe de bout en bout. Pour les entreprises traitant des documents à haute valeur — contrats, factures, rapports médicaux — gagner quelques points de précision au-delà de 85 % peut représenter une différence opérationnelle significative. L'intégration native entre S3 et le catalogue SageMaker supprime une friction majeure : les données non structurées (images, PDF, textes bruts) deviennent des actifs directement exploitables par les équipes ML sans pipeline d'ingestion personnalisé. Le suivi des expériences via MLflow serverless permet en outre de comparer objectivement les trois variantes affinées et de documenter les gains de performance, une exigence croissante dans les déploiements enterprise. Cette annonce s'inscrit dans la stratégie d'AWS pour faire de SageMaker Unified Studio une plateforme unifiée couvrant l'ensemble du cycle MLOps, depuis l'ingestion des données brutes jusqu'au déploiement en production. La montée en puissance des modèles multimodaux — capables de traiter simultanément texte et image — crée une demande forte pour des outils d'affinage accessibles, sans que chaque équipe doive maîtriser les subtilités de l'entraînement distribué. AWS positionne ici SageMaker JumpStart comme point d'accès aux modèles fondamentaux, tandis que l'infrastructure d'entraînement repose sur des instances p4de.24xlarge, des GPU haute performance nécessitant une demande d'augmentation de quota. La prochaine étape logique pour AWS sera d'élargir cette intégration à d'autres formats de données non structurées et à davantage de modèles fondamentaux, dans un contexte où Google, Microsoft Azure et les plateformes spécialisées comme Modal ou Together AI se disputent le même terrain des équipes ML entreprise.

OutilsOutil
1 source
Un aperçu des outils en ligne de commande
247Ben's Bites 

Un aperçu des outils en ligne de commande

Les agents d'intelligence artificielle fonctionnent en combinant un modèle de langage avec des outils concrets — et les interfaces en ligne de commande (CLI) constituent leur outil de prédilection. Concrètement, un agent peut exécuter une séquence de commandes bash pour renommer 400 photos produit selon un format SKU précis, les redimensionner en 1200x1200 pixels, les trier dans des sous-dossiers par catégorie, puis vérifier le résultat — le tout en quelques secondes, là où un humain y passerait plusieurs heures. Chaque étape correspond à une commande réelle : ls pour lister les fichiers, mkdir pour créer les dossiers, mogrify pour redimensionner les images, mv pour déplacer et renommer. L'agent enchaîne ces opérations de façon autonome, interprète les sorties, et s'adapte à ce qu'il découvre. Ce mécanisme de "tool use" est au cœur de ce qui distingue un agent d'un simple chatbot. Plus on lui donne accès à des CLIs spécialisées — Stripe CLI pour les données de paiement, Playwright pour contrôler un navigateur web, AWS CLI pour gérer une infrastructure cloud, Vercel CLI pour déployer un site en une commande — plus ses capacités s'étendent. Un agent équipé de bash seul peut organiser des fichiers ; ajoutez Stripe et il peut analyser vos revenus ; ajoutez Playwright et il peut naviguer sur le web ; ajoutez Vercel et il peut déployer ce qu'il vient de construire. C'est cette combinaison d'outils qui définit concrètement ce qu'un agent est capable d'accomplir. Des outils comme Claude Code permettent d'ailleurs de voir les commandes défiler en temps réel, ou de les retrouver via un panneau extensible. Ce modèle technique s'inscrit dans une période d'accélération notable pour les outils d'agents IA. Anthropic vient justement de lancer un "auto mode" pour Claude Code, un régime intermédiaire entre la validation manuelle de chaque action et l'exécution sans aucune permission — une réponse directe aux tensions entre autonomie et sécurité dans les workflows développeurs. En parallèle, les connecteurs Claude pour les outils professionnels sont désormais disponibles sur mobile, et Anthropic travaille sur une fonctionnalité "auto-dream" dédiée à la compaction de mémoire des agents pendant la nuit. Claude Code peut également envoyer des messages iMessage pour notifier l'utilisateur en cours de tâche. Ces annonces illustrent une tendance de fond : les grands labs ne cherchent plus seulement à améliorer les modèles, mais à rendre les agents réellement opérationnels dans des environnements de production réels, avec des garde-fous calibrés pour des usages professionnels quotidiens.

OutilsOutil
1 source
Amazon Bedrock propose l'ajustement par renforcement via des API compatibles OpenAI : guide technique
248AWS ML Blog 

Amazon Bedrock propose l'ajustement par renforcement via des API compatibles OpenAI : guide technique

Amazon Bedrock, la plateforme cloud d'IA d'AWS, propose depuis décembre 2025 le Reinforcement Fine-Tuning (RFT), une méthode avancée de personnalisation de modèles de langage. Le service a d'abord été lancé avec les modèles Nova d'Amazon, avant d'être étendu en février 2026 aux modèles open source comme OpenAI GPT OSS 20B et Qwen 3 32B. Concrètement, le RFT permet d'entraîner un modèle à partir d'un petit ensemble de prompts — sans avoir besoin de milliers d'exemples étiquetés — en lui faisant générer plusieurs réponses possibles, puis en lui attribuant des scores selon la qualité de chaque réponse. Le modèle apprend ensuite à privilégier les stratégies qui produisent les meilleurs résultats. L'exemple utilisé dans le tutoriel est le dataset mathématique GSM8K, appliqué au modèle gpt-oss-20B hébergé sur Bedrock. Ce qui distingue le RFT du fine-tuning supervisé classique, c'est sa capacité d'apprentissage en boucle fermée : le modèle génère lui-même les réponses sur lesquelles il s'entraîne, plutôt que de mémoriser des paires entrée-sortie figées. Cette approche est particulièrement puissante pour des tâches vérifiables comme les mathématiques ou la génération de code, où la correction peut être évaluée automatiquement sans intervention humaine. Au fil de l'entraînement, le modèle rencontre naturellement des scénarios de plus en plus complexes, ce qui lui permet de s'améliorer en continu sans que l'équipe doive constituer et annoter un dataset massif en amont. Le résultat : des gains de performance significatifs sur des tâches complexes comme le raisonnement logique ou les conversations multi-tours. Le Reinforcement Learning appliqué aux LLMs est la technique qui a permis à des modèles comme ChatGPT d'aligner leurs réponses sur les préférences humaines — une méthode connue sous le nom de RLHF. Amazon Bedrock l'industrialise ici en automatisant tout le pipeline, de l'authentification au déploiement d'une fonction de récompense via Lambda, jusqu'à l'inférence sur le modèle personnalisé.

OutilsTuto
1 source
Intégration d'Amazon Bedrock AgentCore avec Slack
249AWS ML Blog 

Intégration d'Amazon Bedrock AgentCore avec Slack

Amazon Bedrock AgentCore permet désormais d'intégrer des agents IA directement dans Slack, éliminant le besoin de basculer entre applications tout en gérant la mémoire conversationnelle, la sécurité et les délais de réponse. La solution repose sur AWS CDK avec trois fonctions Lambda, Amazon API Gateway, SQS et Secrets Manager, tandis que l'agent est conteneurisé et hébergé dans l'AgentCore Runtime via le SDK Strands Agents. L'architecture utilise le protocole MCP (Model Context Protocol) pour l'exécution des outils, et bien que l'exemple soit un agent météo, la couche d'intégration est entièrement réutilisable pour tout cas d'usage métier.

OutilsOutil
1 source
Une visite exclusive du laboratoire Trainium d'Amazon, la puce qui a conquis Anthropic, OpenAI et même Apple
250TechCrunch AI 

Une visite exclusive du laboratoire Trainium d'Amazon, la puce qui a conquis Anthropic, OpenAI et même Apple

Amazon a annoncé un investissement de 50 milliards de dollars dans OpenAI, et AWS a ouvert les portes de son laboratoire de puces Trainium en visite privée. Ce chip maison a séduit des acteurs majeurs de l'IA comme Anthropic, OpenAI et même Apple. Trainium s'impose ainsi comme un concurrent sérieux aux GPU Nvidia dans la course à l'infrastructure IA.

InfrastructureActu
1 source