Dossier AWS — page 7

Grok arrive sur Amazon Bedrock

xAI a annoncé la disponibilité générale de son modèle Grok 4.3 sur Amazon Bedrock, une intégration coécrite avec Eric Jiang, responsable chez xAI (filiale de SpaceX). xAI devient ainsi fournisseur de modèles sur la plateforme Bedrock d'Amazon. Grok 4.3 se distingue par un niveau d'effort de raisonnement configurable, quatre paliers disponibles (aucun, faible, moyen, élevé) que les développeurs peuvent ajuster selon chaque requête. Le modèle accepte du texte et des images en entrée, dispose d'une fenêtre de contexte d'un million de tokens et tourne sur Mantle, le nouveau moteur d'inférence d'Amazon Bedrock qui utilise des API compatibles OpenAI plutôt que l'API Runtime classique de Bedrock. Selon les benchmarks internes publiés par xAI au moment du lancement, Grok 4.3 s'est classé numéro un sur le test Omniscience d'Artificial Analysis, avec le taux d'hallucination le plus bas parmi les modèles de pointe comparés. Il occupe également la première place du benchmark Tau2 Telecom d'Artificial Analysis, qui évalue l'appel d'outils dans des scénarios de support client, ainsi que des tests Vals AI portant sur le droit jurisprudentiel et la finance d'entreprise. xAI affirme que le modèle se situe sur la frontière de Pareto entre intelligence et coût, avec un rapport allant jusqu'à dix fois plus d'intelligence par dollar dépensé que d'autres modèles concurrents. Cette annonce compte pour les équipes qui développent des agents et des flux de travail automatisés en entreprise, car elle leur offre un modèle unique capable de couvrir tout un éventail de tâches sans changer d'outil. Une simple classification peut tourner avec un effort de raisonnement nul pour minimiser la latence, tandis qu'une analyse de contrat ou de jurisprudence peut mobiliser le niveau élevé lorsque la profondeur d'analyse prime sur la vitesse de réponse. Cette flexibilité, combinée à la gestion fiable des appels d'outils et au respect des instructions, rend le modèle particulièrement adapté à des usages comme la révision de contrats, l'analyse de conventions de crédit ou les questions-réponses sur des documents financiers volumineux, des tâches où le modèle doit à la fois raisonner sur de longs textes et interagir avec des systèmes externes. Cette intégration s'inscrit dans la stratégie d'Amazon Web Services visant à diversifier les modèles disponibles sur Bedrock au-delà de ses partenaires historiques, en ouvrant la porte à des fournisseurs tiers comme xAI. Pour les développeurs, l'accès à Grok 4.3 passe par le SDK OpenAI ou des requêtes HTTPS directes vers l'API Chat Completions ou l'API Responses, via une URL propre à chaque région AWS, par exemple https://bedrock-mantle.us-west-2.api.aws/openai/v1 pour la région us-west-2. Les paramètres par défaut diffèrent aussi légèrement de la norme OpenAI : la température est fixée à 0,7 au lieu de 1, le top_p à 0,95 au lieu de 1, et le nombre maximal de tokens de complétion à 131 072 par défaut, des réglages que les équipes doivent ajuster explicitement si leur application l'exige.

Un hôte téléphonique IA pour restaurants avec Amazon Bedrock AgentCore et Amazon Nova 2 Sonic

Les restaurants manquent en moyenne 150 appels téléphoniques par établissement chaque mois, et environ 60% de ces appels proviennent de clients qui souhaitent passer commande ou réserver une table. La majorité de ces appels arrivent pendant le service du dîner, au moment précis où l'hôte accueille les clients, où les serveurs tournent les tables, et où le téléphone passe au second plan. Amazon vient de détailler, via son blog technique AWS, comment construire un système de commande vocale capable de répondre à un numéro de téléphone et de gérer l'intégralité d'une commande, de l'accueil jusqu'à la confirmation. La solution s'appuie sur Amazon Bedrock AgentCore pour héberger et exécuter l'agent conversationnel, et sur Amazon Nova 2 Sonic pour la synthèse et la reconnaissance vocale en temps réel, le tout relié à un backend de restaurant via le protocole MCP (Model Context Protocol). L'architecture complète se déploie avec AWS CDK et fait transiter l'appel téléphonique vers l'agent grâce à une passerelle SIP hébergée sur Amazon ECS et AWS Fargate, avec un pont SIP fourni par Amazon Chime SDK Voice Connector. Ce système répond à un problème concret pour l'industrie de la restauration: détourner un employé du service pour répondre au téléphone dégrade deux expériences à la fois, celle du client au comptoir et celle de l'appelant. Une application ou un site web de commande en ligne n'aide en rien les clients qui préfèrent simplement appeler. En automatisant cette interaction vocale, les restaurants peuvent capter des commandes et des réservations qui seraient autrement perdues, sans mobiliser de personnel supplémentaire. Le système va jusqu'à préchauffer la session de l'agent pendant que le téléphone sonne encore, afin que l'appelant n'entende jamais de silence mort en décrochant. Cette architecture modulaire, où la logique de commande reste indépendante du canal d'appel, permet aussi d'ajouter facilement d'autres points d'entrée, comme une application mobile ou une borne en magasin, sans réécrire le backend. Techniquement, la solution repose sur quatre couches distinctes. Le backend utilise Amazon DynamoDB pour stocker les données clients, commandes, menus et paniers, Amazon Location Service pour la géolocalisation et le calcul d'itinéraires, AWS Lambda pour la logique métier, et Amazon API Gateway sécurisé par IAM pour exposer ces services. AgentCore Gateway transforme ensuite ces points d'accès en outils MCP que l'agent peut découvrir et appeler par leur nom, ce qui évite de redéployer l'agent à chaque modification du backend. Chaque appel s'exécute dans sa propre microVM pour garantir l'isolation. Cette démonstration illustre la stratégie d'AWS visant à positionner Bedrock AgentCore et Nova 2 Sonic comme des briques standards pour construire des agents vocaux d'entreprise, dans un secteur de la restauration où l'automatisation téléphonique reste un chantier largement inexploité malgré son potentiel de revenus immédiat.

💬 150 appels ratés par mois et par resto, c'est du chiffre d'affaires qui part direct chez le concurrent, pas juste un désagrément pour le client qui poireaute au comptoir. Le détail malin, c'est de préchauffer la session pendant que le téléphone sonne encore, histoire que personne n'entende de blanc en décrochant, enfin presque. Le vrai chantier de l'IA vocale en entreprise, c'est pas le chatbot du site que personne n'ouvre, c'est ce bon vieux téléphone qu'aucun resto n'avait les moyens de décrocher à chaque sonnerie.

Déploiement de modèles quantifiés sur Amazon SageMaker AI avec Unsloth

Déployer des modèles quantifiés en production coûte cher lorsqu'ils restent en pleine précision 16 bits (BF16 ou FP16), car cela impose des instances GPU volumineuses et ralentit les cycles d'itération. Amazon Web Services a publié, avec Unsloth, un article co-écrit par Daniel Han et Michael Han détaillant comment déployer des modèles quantifiés dynamiquement sur son infrastructure. Unsloth propose une méthode appelée quantification dynamique, qui ne réduit pas uniformément la précision de toutes les couches d'un modèle. Selon Daniel Han, cofondateur d'Unsloth, un modèle nécessitant initialement 1,5 To de mémoire peut être ramené à 217 Go grâce à cette technique, soit une réduction de 86 % de la taille, pour seulement 14 % de perte de précision. Concrètement, un modèle standard utilise 16 bits par paramètre ; une quantification à 4 bits réduit la taille de 75 %, ce qui fait passer un modèle de 8 milliards de paramètres d'environ 16 Go à environ 5 Go. Le processus se déroule en trois étapes : une analyse couche par couche pour mesurer la sensibilité de chacune à la perte de précision, une allocation dynamique du nombre de bits qui conserve une précision élevée (par exemple 16 bits) pour les couches critiques tout en compressant fortement les autres (4 bits ou moins), puis un réglage fin pour que la qualité globale reste proche de l'original malgré la compression. Cette approche change trois paramètres essentiels au moment du déploiement sur AWS. D'abord le choix de l'instance : un modèle qui nécessitait auparavant plusieurs GPU peut désormais tourner sur un seul GPU, voire sur CPU. Ensuite, le profil de démarrage et de stockage : des fichiers de modèle plus légers se déplacent, se stockent et se déploient plus rapidement entre environnements. Enfin, la flexibilité de déploiement : les équipes peuvent choisir un fichier plus compact pour une inférence sensible aux coûts, une version plus fidèle pour les cas exigeant une haute qualité, ou une représentation fusionnée pour un débit plus élevé. Pour les entreprises qui opèrent des modèles de fondation à grande échelle, ces gains de mémoire et de coût peuvent se traduire par des économies substantielles sur la facture cloud. L'article présente quatre schémas de déploiement pour des modèles déjà quantifiés avec Unsloth sur l'infrastructure AWS : l'utilisation directe d'instances Amazon EC2, le service managé Amazon SageMaker AI pour l'inférence, ainsi qu'une intégration via Amazon EKS ou Amazon ECS lorsque l'inférence doit s'insérer dans une architecture de conteneurs existante. Cette publication s'inscrit dans une tendance plus large où les fournisseurs cloud et les éditeurs d'outils open source collaborent pour rendre les grands modèles de langage plus accessibles économiquement, alors que la course à des modèles toujours plus volumineux continue de faire grimper les coûts d'inférence pour les entreprises qui les déploient en production.

💬 Le chiffre qui compte : 86% de mémoire en moins pour seulement 14% de perte de précision, c'est le genre de ratio qui devrait faire revoir la facture GPU de pas mal de boîtes qui tournent des modèles en prod. Passer de plusieurs GPU à un seul, voire du CPU, ça change le calcul économique du déploiement, pas juste un détail d'ingé. Reste que la quantification dynamique demande une vraie analyse couche par couche en amont, donc c'est pas un bouton magique qu'on active en cinq minutes.

Traduction concise et factuelle du sens réel

Le géant du cloud Amazon vient de détailler les bonnes pratiques pour entraîner des agents conversationnels multi-tours grâce à l'apprentissage par renforcement (RL) sur Amazon SageMaker AI. Ce nouveau service, baptisé SageMaker AI MTRL, permet d'entraîner des agents capables de résoudre des tickets de support ou de modérer du contenu à travers une séquence d'actions liées entre elles : lecture d'instructions, appels d'outils, analyse des résultats, prise de décision et correction d'erreurs avant de livrer une réponse finale. L'agent peut tourner sur Amazon Bedrock AgentCore, Amazon EKS, Amazon EC2, AWS Fargate ou toute autre infrastructure choisie par le développeur, connectée via un petit adaptateur qui expose la surface d'outils au serveur d'exécution. Le service embarque une bibliothèque native d'algorithmes incluant PPO, CISPO et plusieurs estimateurs d'avantage par groupe comme GRPO ou RLOO, ainsi qu'une exécution serverless facturée au token, sans gestion de clusters GPU à prévoir. Les exemples cités s'appuient sur SOP-Bench, un benchmark d'Amazon Science qui évalue la capacité des agents à suivre des procédures opérationnelles standard complexes dans douze secteurs d'activité différents. Cette annonce compte parce que l'entraînement par renforcement multi-tours est nettement plus délicat que l'entraînement mono-tour classique. Plus un agent dispose de façons d'agir, plus il existe de moyens détournés de satisfaire la fonction de récompense sans réellement accomplir la tâche demandée, ce qui peut corrompre silencieusement le signal d'apprentissage. Pour les entreprises qui développent des agents IA destinés à des usages métiers critiques comme le support client ou la modération, disposer d'un cadre fiable permettant de mesurer la réussite en dehors de la seule récompense, de suivre les trajectoires d'exécution tour par tour dans MLflow, et d'obtenir des rapports d'évaluation avant déploiement vers un endpoint SageMaker AI ou Amazon Bedrock représente un gain de temps et de fiabilité considérable. Cela réduit le risque de déployer des agents qui paraissent performants en entraînement mais échouent une fois confrontés à des situations réelles. Le contexte plus large est celui d'une course entre grands fournisseurs cloud pour industrialiser l'entraînement d'agents IA autonomes, alors que les entreprises cherchent à automatiser des tâches complexes à plusieurs étapes plutôt que de simples réponses ponctuelles. Amazon met l'accent sur la nécessité de construire des environnements d'entraînement isolés et reproductibles, où les appels d'outils suivent les mêmes schémas et logiques métier que la production mais restent déconnectés du trafic réel, notamment parce qu'une session d'entraînement type génère plusieurs milliers de trajectoires simulées. Cette approche s'inscrit dans une tendance de fond où les fournisseurs de cloud proposent de plus en plus d'infrastructures clé en main pour le fine-tuning et le RL d'agents, un terrain où Amazon Web Services affronte directement Google Cloud et Microsoft Azure, tandis que la fiabilité des environnements simulés et la conception des récompenses deviennent des enjeux techniques centraux pour la fiabilité des futurs agents d'entreprise.

Modèle de sélection simplifié dans Amazon Bedrock grâce au Model Profiler open source

Amazon vient de rendre open source le Model Profiler, un outil qui centralise la comparaison des modèles disponibles sur Amazon Bedrock, sa plateforme de génération de texte gérée. Bedrock donne accès à plus de 100 modèles fondation de fournisseurs comme Anthropic, OpenAI, Meta, Mistral AI, Cohere et Amazon lui-même, mais comparer leurs capacités, tarifs, disponibilité régionale, taille de fenêtre de contexte et débit obligeait jusqu'ici à naviguer entre plusieurs pages de console, documentations et appels API régionaux distincts. Le Model Profiler agrège ces données dans une interface web unique, avec filtrage avancé, comparaisons côte à côte et fiches détaillées par modèle. En coulisses, un pipeline serverless entièrement automatisé collecte les informations depuis sept sources différentes, cinq API AWS et deux URL publiques, incluant les spécifications des modèles Bedrock, les tarifs on-demand et batch, les quotas de débit (tokens par minute et requêtes par minute) sur 33 régions, les profils d'inférence cross-région, ainsi que les tailles de fenêtre de contexte via la base LiteLLM et le statut de cycle de vie via la documentation AWS. Le pipeline repose sur AWS Step Functions et orchestre 17 fonctions Lambda réparties en quatre phases, avec un système de cache S3 inter-Lambda qui réduit le nombre d'appels API d'environ 480 à 29 par exécution, soit un taux de succès de cache de 97%. L'ensemble tourne quotidiennement à 6h UTC et se termine en 8 à 12 minutes. Pour les équipes qui évaluent des modèles pour de nouveaux projets, cherchent à optimiser coûts et performances, ou migrent depuis d'autres systèmes d'IA, cet outil supprime une friction concrète: le temps perdu à croiser manuellement des documents épars pour prendre une décision éclairée. Comprendre les quotas est central dans ce choix. Le débit en tokens par minute (TPM) fixe le plafond de traitement, sachant que 1 000 tokens représentent environ 750 mots de texte, tandis que le nombre de requêtes par minute (RPM) limite les appels API indépendamment de leur taille, ces deux quotas variant selon le modèle et la région choisie. En rendant ces informations accessibles et à jour quotidiennement dans une seule interface, l'outil accélère la phase d'expérimentation et raccourcit le délai avant la mise en production. Cette initiative s'inscrit dans une tendance plus large où les grands fournisseurs cloud cherchent à simplifier l'accès à des catalogues de modèles de plus en plus vastes et fragmentés en termes de tarification, de régions et de capacités techniques. Amazon mise ici sur l'open source et sur une architecture serverless réutilisable, déployable en moins de cinq minutes via un template AWS CloudFormation, dont la fréquence de mise à jour est configurable par une règle Amazon EventBridge. Le projet embarque également un système agentique d'auto-réparation, propulsé par Bedrock, capable de détecter des lacunes dans les données collectées et d'appliquer automatiquement des correctifs de configuration jugés sûrs. À mesure que le nombre de modèles disponibles sur Bedrock continue de croître, cet outil pourrait devenir une référence pour les équipes techniques cherchant à arbitrer rapidement entre coût, performance et couverture géographique sans dépendre exclusivement des interfaces officielles d'AWS.

Sécuriser le déploiement des modèles de pointe auprès des clients

Voici la traduction/résumé en français : Amazon Web Services (AWS) a annoncé que les modèles Claude Fable 5 d'Anthropic redeviennent disponibles dès demain pour les clients de Bedrock, sa plateforme d'intelligence artificielle, avec des garde-fous renforcés contre les usages malveillants. Cette annonce s'inscrit dans la continuité de Bedrock Mantle, lancé l'an dernier pour offrir une protection renforcée des poids des modèles et de la confidentialité des données. AWS travaille également en étroite collaboration avec Anthropic et d'autres acteurs du secteur dans le cadre du Projet Glasswing, une initiative visant à encadrer le déploiement de modèles de nouvelle génération comme Claude Mythos, dont les capacités en cybersécurité sont particulièrement avancées. L'équipe de sécurité offensive d'AWS (Red Team) a directement contribué, aux côtés d'Anthropic, à améliorer les protections de Fable 5. Lorsque ses garde-fous se déclenchent, le modèle bascule automatiquement vers Opus 4.8, déjà accessible publiquement. Cette annonce illustre un dilemme central pour l'industrie de l'IA : comment mettre des capacités avancées de cybersécurité entre les mains des équipes de défense sans donner simultanément aux attaquants les moyens de mener des recherches de vulnérabilités plus poussées. AWS souligne que l'objectif prioritaire des garde-fous est justement d'empêcher les acteurs malveillants d'accéder à ce niveau de recherche offensive, tout en laissant aux entreprises, gouvernements et institutions académiques le temps de renforcer leurs défenses avant que ces capacités ne soient exploitées à grande échelle. Pour les clients de Bedrock, cela signifie un accès plus rapide aux modèles les plus récents, avec les standards de sécurité et de confidentialité attendus d'AWS, sans avoir à choisir entre performance et prudence. Cette collaboration s'inscrit dans un contexte plus large où les modèles frontières gagnent rapidement en puissance, notamment sur des tâches sensibles comme l'analyse de vulnérabilités logicielles. Anthropic a publié de son côté un billet de blog intitulé "Redeploying Fable 5", détaillant sa manière d'évaluer les capacités de cette nouvelle génération de modèles ainsi que ses engagements et délais de réponse en cas de signalement de problèmes après déploiement. AWS salue cette transparence et annonce vouloir continuer à faire évoluer les garde-fous au fur et à mesure que de nouveaux modèles sortent et que les enseignements s'accumulent sur l'efficacité des protections actuelles. Les deux entreprises présentent cette coopération comme une première tentative structurée de définir des niveaux de gravité et des protocoles de réponse spécifiques aux modèles capables d'assister en cybersécurité, un cadre appelé à s'affiner avec le reste du secteur.

💬 Le détail qui compte, c'est le fallback automatique : si Fable 5 dérape, il bascule tout seul vers Opus 4.8. Sur le papier ça règle le dilemme de la cybersécu offensive, mais Glasswing c'est surtout l'aveu que les modèles progressent plus vite que les garde-fous qu'on sait construire autour. Reste à voir si ça tient face à un vrai attaquant motivé, pas juste face à un red team maison.

« Construire une interface utilisateur générative pour agents IA sur Amazon Bedrock AgentCore avec le protocole AG-UI »

Le géant du cloud AWS a dévoilé une intégration entre Amazon Bedrock AgentCore et le protocole ouvert AG-UI (Agent-User Interaction Protocol), conçue pour permettre aux agents IA de communiquer avec des interfaces utilisateur dynamiques plutôt que de se limiter à un simple chat textuel. Ce protocole, compatible avec plusieurs frameworks d'agents comme Strands Agents, LangGraph et CrewAI, ainsi qu'avec des bibliothèques frontend telles que React, Angular ou Vue, permet à un agent de générer des graphiques interactifs en ligne, de mettre à jour un canevas partagé en temps réel, ou de suspendre son exécution pour demander une validation humaine. L'intégration s'appuie sur le Fullstack AgentCore Solution Template (FAST), un projet de démarrage prêt à déployer qui connecte AgentCore Runtime, Gateway, Identity, Memory et Code Interpreter à un frontend React avec authentification Amazon Cognito, le tout défini via AWS Cloud Development Kit (CDK). La version FAST v0.4.1 a ajouté deux nouveaux modèles d'agents, agui-strands-agent et agui-langgraph-agent, qui partagent un seul et même analyseur frontend. AgentCore Runtime agit comme un proxy transparent gérant l'authentification via Signature Version 4 (SigV4) ou OAuth 2.0 par Cognito, l'isolation des sessions, la mise à l'échelle et l'observabilité, pendant que le conteneur de l'agent expose un point d'accès POST /invocations pour les requêtes AG-UI et un GET /ping pour les vérifications de santé sur le port 8080. Cette avancée répond à un besoin concret des développeurs d'agents IA: découpler le code backend de l'agent du code frontend, afin de choisir librement le meilleur framework pour chaque côté sans sacrifier l'interopérabilité. Pour les équipes qui construisent des applications agentiques destinées aux entreprises, cela signifie des interfaces plus riches que le simple chat, avec des composants visuels générés à la volée, des états partagés bidirectionnels et des mécanismes de supervision humaine intégrés nativement au protocole plutôt que bricolés au cas par cas. Cela réduit la complexité d'ingénierie et accélère le déploiement d'agents capables d'interactions plus naturelles et plus sûres, un enjeu central à mesure que les entreprises cherchent à industrialiser leurs cas d'usage d'IA générative au-delà des simples assistants conversationnels. Le protocole AG-UI s'inscrit dans un écosystème plus large de protocoles déjà supportés par AgentCore Runtime, aux côtés du Model Context Protocol (MCP), qui relie les agents aux outils, et d'Agent2Agent (A2A), qui relie les agents entre eux. Pour illustrer concrètement ces capacités, AWS a présenté un exemple combinant FAST avec CopilotKit, qui remplace l'interface de chat intégrée par défaut pour ajouter une génération d'interface utilisateur, un canevas de tâches à état partagé, et un planificateur de réunions illustrant l'intervention humaine en cours d'exécution, le tout déployé sur AgentCore Runtime avec authentification Cognito, connectivité MCP via AgentCore Gateway et conversations persistantes grâce à AgentCore Memory.

Créer un agent de prise de rendez-vous médicaux avec Amazon Nova 2 Sonic

Amazon Web Services publie une architecture complète pour déployer un agent vocal capable de gérer automatiquement les rappels de rendez-vous médicaux, en combinant Amazon Nova 2 Sonic et Amazon Bedrock AgentCore. Le taux d'absences non justifiées dans les établissements de santé américains oscille entre 5 et 30 % selon les spécialités, chaque créneau vide représentant une perte de revenus, du temps médical gaspillé et des soins retardés. L'agent décrit authentifie les patients par reconnaissance vocale, gère les rendez-vous en temps réel, confirmation, annulation, reprogrammation, collecte des informations de santé pré-consultation et transfère l'appel à un agent humain si la situation l'exige. Le système repose sur Bedrock AgentCore en mode serverless, Amazon Cognito pour l'authentification, DynamoDB pour la persistance des données, Amazon SNS pour les notifications, et un frontend React qui streame l'audio bidirectionnel via des connexions WebSocket authentifiées. La différence fondamentale avec les approches traditionnelles tient au traitement natif parole-à-parole de Nova 2 Sonic. Les pipelines classiques enchaînent trois services distincts, transcription automatique, modèle de langage, synthèse vocale, et perdent à chaque transfert les nuances acoustiques du patient : hésitations, ton anxieux, confusion. Nova 2 Sonic traite la voix dans un seul modèle unifié, préservant le contexte vocal à travers chaque tour de dialogue. En santé, où l'état émotionnel d'un patient devrait influencer directement la réponse de l'agent, cette rétention de contexte améliore concrètement la qualité des échanges. Le modèle gère en outre les bruits de fond courants en environnement domestique et clinique, les accents régionaux, et peut basculer en cours de conversation vers la langue préférée du patient sans aucune reconfiguration. Amazon positionne Nova 2 Sonic comme une réponse directe aux limites des pipelines textuels dans les interactions vocales à fort enjeu. L'architecture s'appuie sur le SDK Strands Agents, qui intègre sept outils spécifiques au secteur médical pour l'authentification, la gestion des plannings et l'escalade vers le personnel soignant. Pour connecter l'agent à de vraies lignes téléphoniques en mode sortant, AWS recommande d'intégrer Amazon Connect, non inclus dans cette démonstration qui se concentre sur la couche agentique. Dans un secteur où les appels de confirmation un par un ne passent plus à l'échelle, cette architecture cible directement les réseaux de cliniques et d'hôpitaux qui absorbent chaque année des millions d'interactions téléphoniques routinières, et cherchent à les automatiser sans sacrifier la dimension humaine de la relation patient.

Les lois d'échelle, examinées avec rigueur

Les lois d'échelle (scaling laws) constituent l'une des découvertes empiriques les plus déterminantes de l'apprentissage profond moderne. Le principe est d'une élégante simplicité : la perte d'entraînement L d'un modèle diminue de manière prévisible lorsque l'on augmente simultanément trois paramètres, la taille du modèle N, la quantité de données d'entraînement D, et la puissance de calcul C. Cette relation suit une courbe en loi de puissance, qui se traduit par une droite sur un graphe log-log. En d'autres termes, plus on investit en calcul, en données et en paramètres, plus le modèle s'améliore, et ce de façon quantifiable à l'avance. L'enjeu pratique est considérable : ces lois permettent aux équipes de recherche d'allouer leur budget de calcul de façon optimale entre deux leviers, augmenter la taille du modèle ou augmenter le volume de données. Pour des entraînements qui coûtent des dizaines ou centaines de millions de dollars, la capacité à prédire les gains avant même de lancer un run est une information stratégique de premier ordre. Ce cadre théorique a été formalisé par les chercheurs d'OpenAI autour de Jared Kaplan en 2020, puis significativement révisé par DeepMind avec le papier Chinchilla en 2022, qui démontrait que la plupart des grands modèles étaient sous-entraînés en données par rapport à leur taille. Aujourd'hui, alors que les entreprises approchent de limites physiques et économiques, la question centrale est de savoir si ces lois continueront de tenir, ou si l'ère du scaling pur touche à sa fin.

ComfyUI sur Amazon SageMaker : exécuter des workflows de traitement

Amazon Web Services a publié un guide technique détaillant comment exécuter des workflows ComfyUI sur Amazon SageMaker AI, via ses "processing jobs", pour automatiser la génération de contenu visuel à grande échelle. La solution repose sur AWS Cloud Development Kit (CDK) et des instances GPU accélérées avec une facturation à la seconde et arrêt automatique à la fin du job. En pratique, le dispositif permet de générer des centaines d'images haute qualité en un seul batch, à partir de workflows ComfyUI exportés au format JSON. AWS illustre également l'intégration du modèle Z-Image Turbo, un modèle texte-vers-image reposant sur une architecture Transformer à flux unique (S3DiT) de 6 milliards de paramètres, 30 couches, une taille cachée de 3 840 et 32 têtes d'attention, avec une technique de fusion précoce qui traite uniformément les tokens texte et image dans le même Transformer. Pour les équipes marketing et créatives des grandes entreprises, cette automatisation change concrètement les règles du jeu. Là où un designer devait itérer manuellement pour produire des visuels adaptés à chaque marché ou segment d'audience, il devient possible de générer en une heure des centaines de visuels cohérents avec la charte graphique, des voix synthétisées multilingues pour des campagnes publicitaires, ou des clips vidéo avec scripts et images générés par IA. La facturation à la seconde de SageMaker élimine le gaspillage de compute, tandis que l'architecture en file d'attente traite plusieurs demandes en parallèle sans intervention manuelle. L'enjeu commercial est direct : chaque heure gagnée en production de contenu peut être réinvestie dans le lancement d'une campagne supplémentaire ou le ciblage d'un nouveau segment d'audience. Cette initiative s'inscrit dans une tendance de fond : les hyperscalers intègrent de plus en plus les outils open-source de l'IA générative dans leurs plateformes cloud managées, pour capter les workflows déjà adoptés par les praticiens. ComfyUI s'est imposé comme standard de facto pour composer des pipelines d'IA générative complexes sans coder chaque étape, grâce à son interface visuelle modulaire et ses workflows versionnables. En le portant sur SageMaker, AWS vise les entreprises qui utilisent déjà ComfyUI en local mais peinent à le faire passer à l'échelle en production. La prise en charge de modèles comme Z-Image Turbo, avec son architecture decoder-only inspirée des grands modèles de langage, signale aussi que la frontière entre génération de texte et génération d'image continue de s'estomper sur le plan architectural, ouvrant la voie à des pipelines multimodaux encore plus intégrés.

Intelligence contextuelle pour vos données et agents IA à grande échelle

Amazon Web Services a annoncé lors de l'AWS Summit New York City le lancement prochain d'AWS Context, un nouveau service conçu pour donner aux agents d'intelligence artificielle un accès structuré et gouverné à l'ensemble des données d'une organisation. Le service construit automatiquement un graphe de connaissances en cartographiant les relations entre les sources de données existantes, lacs de données, entrepôts, bases de données, flux en temps réel, et expose ce graphe via des API de recherche agentique et des outils MCP. Les équipes data peuvent gérer ce graphe depuis une console dédiée, valider les relations inférées automatiquement, les promouvoir en production, et y attacher des définitions métier ou des règles d'usage. AWS Context s'appuie sur la technologie qui alimente déjà Amazon QuickSight Q, un graphe de connaissances personnel utilisé quotidiennement par des centaines de milliers d'utilisateurs et traitant des millions de requêtes par jour. La nouveauté : ce graphe devient organisationnel, partagé entre tous les agents et applications d'une entreprise. Les métadonnées clés sont publiées au format Apache Iceberg dans Amazon S3, ce qui les rend interrogeables via Athena, Redshift ou Spark. L'enjeu est fondamental pour les entreprises qui déploient des agents IA en production : un agent ne peut prendre de décisions fiables que s'il dispose du bon contexte au bon moment. Aujourd'hui, ce contexte est dispersé entre des dizaines de systèmes hétérogènes, et une grande partie de la connaissance institutionnelle n'est tout simplement pas écrite. AWS Context vise à combler ce vide en créant une couche de contexte centralisée, gouvernée et accessible en temps réel. Pour les utilisateurs existants d'Amazon QuickSight Q, le bénéfice est immédiat : une fois AWS Context activé, leurs agents accèdent automatiquement au graphe étendu, incluant les relations inter-systèmes et les règles métier qui dépassent ce qu'un graphe personnel peut offrir. AWS Glue Data Catalog, Amazon SageMaker Unified Studio et AWS Lake Formation s'intègrent nativement au service. Ce lancement s'inscrit dans une course industrielle plus large autour de ce qu'AWS appelle l'« intelligence de contexte ». Les grands fournisseurs cloud rivalisent pour proposer des infrastructures permettant aux agents IA de raisonner sur des données d'entreprise réelles, sans que les équipes aient à construire des pipelines de récupération complexes. AWS Context se distingue par deux caractéristiques : son graphe apprend automatiquement de l'usage des agents, propageant les chemins de jointure corrects et les ambiguïtés résolues à l'ensemble de l'organisation sans intervention humaine ; et son architecture ouverte, basée sur Apache Iceberg, garantit que les métadonnées restent portables et auditables, indépendamment des outils choisis. Le service est également conçu pour se connecter à des catalogues tiers, étendant le graphe au-delà de l'écosystème AWS. La disponibilité générale n'a pas encore été précisée.

Premier avis de sinistre automatisé : Strands Agents et Amazon Bedrock AgentCore pour un traitement intelligent des déclarations

Amazon Web Services a présenté un système d'automatisation de la déclaration de sinistre initiale (FNOL, ou "First Notice of Loss") combinant deux de ses technologies : le SDK open source Strands Agents et l'outil Amazon Bedrock AgentCore Browser Tool. Le dispositif s'appuie également sur Amazon Nova Act, un client capable d'interpréter des instructions en langage naturel pour piloter des interfaces web. Concrètement, Nova Act orchestre les interactions avec les portails de gestion de sinistres, ouvrir un dossier non traité, déclencher une analyse d'images, tandis que les agents construits avec Strands Agents appliquent les règles métier propres à l'assurance : interprétation des preuves, corrélation entre différents types de médias, évaluation de la complexité du dossier. Les modèles de fondation sont servis via Amazon Bedrock, et les sessions de navigation sont gérées dans des environnements Chrome isolés, avec enregistrement et visualisation en temps réel pour garantir la traçabilité. L'enjeu est considérable pour les compagnies d'assurance. À chaque déclaration de sinistre, les experts reçoivent un ensemble hétérogène d'informations non structurées : photos prises sur le terrain, vidéos panoramiques des dégâts, documents scannés, notes dictées ou enregistrées. Avant même de pouvoir exercer leur jugement, ils doivent naviguer dans des portails, vérifier l'exhaustivité des pièces justificatives et interpréter manuellement chaque élément. Les estimations sectorielles indiquent que cette phase de validation représente une part significative du temps d'un expert lors du traitement initial d'un dossier. Lors de pics de sinistres, catastrophes naturelles, vagues saisonnières, ces délais s'accumulent, créent des files d'attente et dégradent l'expérience client. Le système proposé délivre aux experts des dossiers pré-analysés, avec les preuves étiquetées et contextualisées, prêts pour la prise de décision plutôt que pour la validation. Cette initiative s'inscrit dans un mouvement plus large d'automatisation des processus assurantiels par l'IA générative, un secteur où les grands acteurs du cloud, AWS, Microsoft Azure, Google Cloud, se livrent une concurrence intense pour conquérir les équipes claims et underwriting. L'approche d'AWS est notable car elle ne cherche pas à remplacer l'expert humain mais à éliminer le travail répétitif d'écran, en préservant la supervision et l'auditabilité. Les données d'intake étiquetées deviennent également un actif opérationnel durable, utilisable pour affiner le routage des dossiers, détecter des patterns de fraude ou améliorer les workflows sur l'ensemble du cycle de vie des sinistres. La prochaine étape naturelle sera l'intégration avec des systèmes de gestion de sinistres existants comme Guidewire ou Duck Creek, où la valeur de l'automatisation multimodale sera pleinement testée à l'échelle.

Comment déployer des opérations IA autonomes à grande échelle sur Amazon Bedrock

Amazon Web Services a dévoilé Amazon Bedrock Ops Alert, une solution de supervision automatisée en trois couches conçue pour les organisations qui déploient des applications d'IA générative à grande échelle. Utilisé par plus de 100 000 organisations dans le monde, d'entreprises naissantes aux multinationales, Amazon Bedrock fournit l'infrastructure sur laquelle reposent des centaines de workloads de production. La nouvelle solution surveille en continu les quotas de requêtes par minute (RPM) et de tokens par minute (TPM) alloués à chaque client, détecte les anomalies opérationnelles avant qu'elles n'impactent la production, ajuste dynamiquement les seuils d'alarme, et ouvre automatiquement des tickets de support AWS enrichis en contexte. Elle intègre également un mécanisme anti-doublons qui bloque la création d'un nouveau ticket si un cas non résolu de même nature est déjà ouvert, évitant ainsi de diluer l'attention des équipes d'ingénierie. Pour les équipes SRE spécialisées en IA, l'enjeu est considérable : gérer manuellement les quotas et escalades de support à mesure que l'adoption interne s'accélère est un travail chronophage qui détourne les ingénieurs de l'innovation. Bedrock Ops Alert réduit ce surcoût opérationnel en automatisant le triage, en fournissant des notifications contextualisées directement exploitables, et en raccourcissant le temps moyen de résolution des incidents. La solution permet aussi d'anticiper les besoins d'augmentation de quotas avant que les limitations ne se matérialisent en erreurs pour les utilisateurs finaux, un gain critique dans des environnements où plusieurs modèles de fondation tournent simultanément en production. Cette annonce s'inscrit dans une tendance plus large chez AWS : réduire la friction liée à l'échelle des workloads d'IA générative sans exiger systématiquement une augmentation de quotas. Amazon Bedrock propose déjà l'inférence inter-régions géographique et, plus récemment, l'inférence inter-régions mondiale (global cross-region inference), qui route automatiquement les requêtes vers les régions AWS commerciales les mieux disponibles dans le monde entier, offrant un accès à un pool de ressources nettement plus large et une réduction de coût d'environ 10 % par rapport à l'inférence géographique classique. Le prompt caching, autre fonctionnalité optionnelle, permet quant à lui de réduire la latence et les coûts en token en évitant de recalculer des portions de contexte identiques. Ensemble, ces mécanismes forment une réponse structurée d'AWS à la pression croissante que font peser des milliers d'organisations sur une infrastructure d'IA devenue critique pour leurs opérations quotidiennes.

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

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

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.

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.

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.

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.

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

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

Amazon Bedrock AgentCore : créer des agents IA pour le support métier

Works Human Intelligence (WHI), éditeur japonais du système RH intégré "COMPANY" utilisé par de grandes entreprises et organismes publics nippons, a collaboré avec le AWS Generative AI Innovation Center (GenAIIC) pour développer deux agents d'IA reposant sur Amazon Bedrock AgentCore. Le premier, le Commuting Allowance Agent, automatise la validation des demandes d'indemnités de transport lors d'événements comme les déménagements d'employés. Le second, le Browser Operation Agent, accède au système "COMPANY" au nom des clients pour vérifier des contenus, effectuer des opérations et collecter des preuves. Le résultat le plus marquant de cette collaboration est une réduction des coûts allant jusqu'à 97 %, combinée à une amélioration mesurable de l'efficacité opérationnelle des équipes support. Pour les départements RH de grandes organisations, la gestion quotidienne d'un système comme "COMPANY" génère un volume considérable de tâches répétitives : changements organisationnels, révisions des politiques salariales, mises à jour d'informations employés. L'automatisation via des agents d'IA permet de décharger les équipes opérationnelles de ces traitements routiniers, libérant du temps pour des missions à plus forte valeur ajoutée. La réduction de 97 % des coûts illustre concrètement ce que peut apporter une architecture bien conçue : WHI auto-hébergeait auparavant Langfuse pour surveiller ses agents, ce qui entraînait des coûts d'exploitation récurrents. La migration vers AgentCore Observability a supprimé cette charge. Pour l'industrie RH, ce cas démontre qu'il est possible de déployer des agents multi-tenants fiables, avec authentification via Amazon Cognito et gestion des tenants par Amazon DynamoDB, sans infrastructure monolithique difficile à faire évoluer. WHI avait initialement lancé un proof of concept avec LangGraph, Amazon ECS et AWS Fargate, mais la mise en disponibilité générale d'Amazon Bedrock AgentCore en cours de projet a conduit l'équipe à repenser l'architecture. Plutôt que de maintenir un ECS task monolithique où tous les composants s'exécutaient en bloc, la nouvelle architecture décompose les sous-agents pour les faire tourner individuellement sur l'AgentCore Runtime, ce qui facilite leur évolution future indépendante. Slack a été intégré comme point d'entrée, avec une authentification déclenchée au moment de chaque appel. WHI envisage également de remplacer l'agent superviseur actuel par Strands Agents à terme. Ce projet illustre une tendance croissante : les éditeurs de logiciels métier cherchent à enrichir leurs solutions avec des couches d'IA agentique en s'appuyant sur des services cloud managés pour absorber la complexité opérationnelle, plutôt que de maintenir leur propre outillage d'orchestration.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

IA agentique en entreprise – Partie 2 : Conseils par persona

Dans la deuxième partie de cette série de l'AWS Generative AI Innovation Center, les auteurs s'adressent directement aux dirigeants d'entreprise pour leur expliquer comment déployer concrètement des agents IA selon leur rôle. Pour les responsables métier (P&L owners), la recommandation clé est de rédiger une "fiche de poste" pour l'agent — avec des objectifs précis liés aux KPIs existants (délais, coûts, taux d'erreurs) — avant de penser à la technologie. L'entrée en matière idéale est un agent qui consolide les handoffs entre équipes et pré-instruit les dossiers, générant des économies rapides qui permettent d'obtenir le soutien du CFO pour des projets plus ambitieux.