AWS· sujet

Construire une plateforme d'IA à base d'agents sur Amazon Bedrock AgentCore

Faire passer un agent en production se heurte moins au modèle ou aux outils qu'à tout ce qui les entoure : comment de nombreuses équipes peuvent construire dans un environnement sécurisé, qui possède chaque modèle et chaque outil, comment l'exploitation des agents et la gestion des erreurs restent dans un cadre prédéfini, et comment les équipes plateforme, métier et finance suivent les coûts et la santé du parc sur plusieurs comptes. AWS détaille une architecture de référence pour une plateforme d'IA agentique d'entreprise fondée sur Amazon Bedrock et Amazon Bedrock AgentCore, ce dernier fournissant des services modulaires (runtime, gateway, identité, mémoire, politiques, registre, évaluations). Le « Enterprise Agentic AI Platform Blueprint » y ajoute, sous forme d'infrastructure as code déployable, les contrats d'entreprise : propriété, frontières de comptes, livraison logicielle, observabilité, gouvernance des coûts et retrait. L'architecture repose sur un modèle multi-comptes, un plan de contrôle géré par l'équipe Plateforme, un schéma de déploiement reproductible pour chaque « Workstream » (équipe produit ou métier qui construit et possède ses agents), des passerelles distinctes pour l'inférence et les outils, et un pipeline d'évaluation qui conditionne la mise en production de chaque agent. L'enjeu est d'éviter que chaque équipe réassemble ses propres contrôles, ce qui provoque une dérive, des goulets d'étranglement sur les services partagés et une propriété difficile à auditer. Chaque Workstream doit disposer d'une « voie balisée » : modèles et outils approuvés, identité de charge de travail à courte durée de vie, runtime et mémoire isolés, évaluation automatisée, retour arrière, télémétrie et attribution des coûts. Pour les organisations, cela signifie que les équipes peuvent livrer et revenir en arrière de façon autonome, sans attendre l'équipe plateforme ni disposer d'un accès direct en écriture à l'infrastructure. Les ingénieurs d'exploitation obtiennent journaux, métriques, traces et quotas, les responsables de Workstream voient le coût par agent face à leur budget, la finance peut facturer par équipe ou unité via AWS Cost Explorer et le rapport CUR, et les responsables sécurité disposent de preuves indiquant quelle charge de travail a appelé quel modèle ou outil. Ces principes répondent à cinq besoins récurrents exprimés par les clients. Premièrement, un accès gouverné aux modèles : toute requête d'inférence non fiable passe par une passerelle approuvée qui applique les garde-fous (Amazon Bedrock Guardrails ou un fournisseur tiers), limite les modèles et les Régions AWS autorisés par Workstream, impose limites de débit, quotas de jetons et budgets pour qu'aucune équipe n'épuise la capacité partagée, et transporte l'identité tout en émettant les données d'attribution. Deuxièmement, un accès gouverné aux outils : les agents ne découvrent et n'invoquent que des outils approuvés via une passerelle Model Context Protocol (MCP) authentifiée, avec cibles exactes, rôles d'exécution à moindre privilège, décisions de politique et propriétaire auditable. S'y ajoutent la livraison déléguée, les opérations de parc avec suivi des coûts, ainsi que la preuve bornée et la gestion du cycle de vie de chaque version d'agent. Face à la multiplication des cas d'usage agentiques en entreprise, AWS positionne ainsi la plateforme comme un produit à concevoir et à exploiter, plutôt qu'un assemblage laissé à chaque équipe.

Créer une recherche à base d'agents sur une Knowledge Base Amazon Bedrock managée avec CDK

Les systèmes de génération augmentée par récupération (RAG) classiques suivent tous le même schéma : la question est convertie en vecteur, les fragments les plus proches sont extraits d'un seul index, un modèle les reçoit et produit la réponse. Une récupération, une génération. Amazon détaille désormais, dans un guide technique, comment construire une récupération « agentique » d'entreprise sur une Managed Knowledge Base d'Amazon Bedrock, avec l'AWS Cloud Development Kit (CDK) en Python. Une seule commande déploie l'ensemble : un agent qui choisit entre deux bases de connaissances, interroge les données via une Gateway et renvoie une réponse sourcée et citée. L'application provisionne aussi deux tableaux de bord Amazon CloudWatch couvrant sept couches de télémétrie, ainsi que deux formes d'évaluation, à la demande et en continu. CDK déduit lui-même l'ordre de déploiement, là où il fallait auparavant séquencer les piles à la main. Le design en une passe a ses limites. Si la réponse couvre deux corpus, une seule récupération n'en ramène que la moitié, ce qui est pire que rien : la réponse paraît fluide mais reste incomplète. Si la bonne source dépend de la question, un index unique n'a aucun moyen de choisir. Si un second regard sur le corpus est nécessaire après le premier résultat, rien ne le permet. Placer un agent de raisonnement dans la boucle résout ces trois cas, puisqu'il décide s'il faut récupérer, quelle base consulter et s'il doit y retourner avant de répondre. Le prix à payer est opérationnel : un agent emprunte un chemin différent à chaque question, et par défaut on ne voit ni ce chemin ni la qualité de la réponse. L'observabilité devient alors la seule façon de savoir si le système fonctionne, d'où l'intérêt de la fournir dès le déploiement plutôt que de l'ajouter après coup. Ce guide fait suite à un article d'août 2024 qui déployait l'architecture en une passe : un bucket Amazon S3, une collection et un index OpenSearch Serverless, une base de connaissances et une source de données. Trois évolutions ont changé la donne. Amazon Bedrock propose maintenant une base de connaissances gérée (Type: MANAGED), qui prend en charge l'ingestion, le stockage, l'indexation et la récupération, ce qui supprime la collection OpenSearch et ses unités de calcul facturées. Amazon Bedrock AgentCore fournit la partie agentique : une Gateway expose chaque base comme outil via le Model Context Protocol (MCP), un Runtime héberge l'agent, et l'API AgenticRetrieveStream reclasse les résultats en interne et renvoie une réponse synthétisée et citée. Cette récupération agentique n'est disponible que sur la base gérée. Le chemin du bucket S3 à la base reste familier, mais le magasin vectoriel disparaît, et environ la moitié de ce que l'application déploie sert à rendre compte de ce que l'agent a fait.

💬 Un RAG classique, c'est une question, une récupération, une réponse. Dès que la réponse se trouve dans deux corpus, tu obtiens un texte fluide qui répond à moitié, et c'est pire qu'une erreur franche. Amazon met donc un agent dans la boucle, et le plus intéressant n'est pas là : environ la moitié de ce que l'application déploie sert à observer ce que l'agent a fait. Selon Le Fil IA, avec un agent, la question n'est plus de savoir s'il répond bien, mais si tu peux voir le chemin qu'il a pris, et l'observabilité devient le vrai produit. Bon, sur le papier c'est propre, reste à voir si ça tient en prod.

TorchTPU : Google répond à AWS sur l’entrainement des modèles

Google a présenté TorchTPU lors de la PyTorch Conference 2026, une pile logicielle qui permet d'exécuter PyTorch directement sur ses puces TPU, sans couche d'adaptation intermédiaire. L'annonce suit de près celle d'Amazon Web Services, qui venait de lancer TorchNeuron pour ses puces Trainium. Le projet est publié sous licence Apache 2.0 et son dépôt GitHub est déjà en ligne. Il propose deux modes d'exécution : « eager », qui exécute le programme ligne par ligne et facilite la recherche d'erreurs, et « torch.compile », qui analyse l'ensemble du programme avant de l'exécuter. Les développeurs peuvent commencer avec le premier et basculer vers le second si nécessaire. TorchTPU couvre l'entraînement comme l'inférence. Selon Google, TorchTitan, conçu pour répartir l'entraînement sur des milliers de puces, a affiché une montée en charge linéaire jusqu'à 8 129 TPU. Le dépôt de XLA, la solution utilisée jusqu'ici pour exploiter les TPU depuis PyTorch, est désormais déprécié et sera archivé le 15 novembre. Google insiste sur la compatibilité avec l'écosystème existant, point central de son annonce. Pour vLLM et SGLang, les ordonnanceurs, les modèles de travail et les serveurs d'API d'origine sont conservés, et les piles d'inférence existantes peuvent être reprises telles quelles. Pour VeRL, outil d'apprentissage par renforcement, le code des modèles et des algorithmes reste indépendant du matériel. Ray, pour la répartition des étapes des chaînes de traitement, et llm-d figurent aussi parmi les projets pris en charge. Avec Hugging Face, un simple paramètre (device_map="tpu") suffit à cibler les puces. Concrètement, les équipes qui développent déjà avec PyTorch peuvent envisager les TPU sans réécrire leur code ni adopter un outillage jugé peu naturel. Cela abaisse nettement le coût de migration, qui constitue souvent le principal frein au changement de matériel. Cette annonce s'inscrit dans une bataille autour de la dépendance de l'écosystème IA à NVIDIA. PyTorch a besoin d'une couche intermédiaire pour traduire les opérations en instructions comprises par le matériel. Dans la grande majorité des cas, cette couche est CUDA, technologie propriétaire que NVIDIA a longtemps travaillée pour que tous types de calculs puissent s'exécuter sur ses GPU. Cet avantage logiciel a verrouillé le marché bien plus que les seules performances des puces. Google et Amazon cherchent donc à réduire les frictions pour attirer les développeurs vers leurs propres processeurs, les TPU d'un côté, Trainium de l'autre. Google met en avant son partenariat avec Meta, à l'origine de PyTorch, pour asseoir la légitimité de sa démarche. Reste à voir si l'adoption suivra, et si ces solutions atteindront la maturité et la richesse de l'écosystème CUDA. Elles restent néanmoins limitées à leurs clouds respectifs.

💬 Le vrai verrou de NVIDIA, c'est CUDA, pas le silicium, et Google comme AWS viennent de le comprendre : ils ne vendent plus des puces, ils vendent l'absence de réécriture. Un `device_map="tpu"` qui suffit pour cibler la puce, bon, sur le papier c'est séduisant, et l'archivage de XLA le 15 novembre montre que Google y croit. Reste à voir si ça tient en prod à 8 000 TPU, et surtout si tu acceptes de rester enfermé dans un seul cloud pour économiser sur le GPU.

Écrivez votre propre boucle d'entraînement sans gérer de GPU grâce aux API de sessions d'entraînement d'Amazon SageMaker

Amazon Web Services élargit la personnalisation sans serveur de modèles dans Amazon SageMaker AI avec de nouvelles API de « sessions d'entraînement ». Elles permettent d'écrire soi-même la boucle d'entraînement d'un grand modèle de langage depuis son propre processus Python, sans gérer les GPU. Des opérations comme forwardbackward(), optimstep() et sample() deviennent des appels d'API SageMaker. Le développeur les assemble selon sa technique : réglage supervisé (SFT), optimisation des préférences, apprentissage par renforcement (RL) ou algorithme inédit. Ces appels visent une session active et persistante : le modèle reste chargé sur les GPU d'une étape à l'autre, avec un adaptateur LoRA. Le service prend en charge l'initialisation de l'environnement, l'exécution distribuée, la synchronisation des gradients, la reprise sur panne et l'isolation entre clients. L'API repose sur trois clients du SDK Python de SageMaker, créés en séquence. Le ServiceClient porte les paramètres de plateforme (rôle d'exécution, groupe de packages de modèles, emplacement de sortie sur Amazon S3, clé AWS KMS et configuration VPC facultatives) et démarre la session. Il instancie un TrainingClient (forward, forwardbackward, optimstep, saveweightsforsampler), qui crée à son tour un SamplingClient (sample et computelogprobs, pour la génération et l'évaluation). Ce choix lève un arbitrage ancien. Les services entièrement gérés conviennent quand une recette standard répond au problème, mais ils figent l'algorithme. Les services moins gérés laissent plus de contrôle, au prix d'une infrastructure et de frameworks d'entraînement à administrer soi-même. Dès qu'il faut une fonction de perte personnalisée, un curriculum de données, une fonction de récompense pour le RL ou un algorithme d'alignement publié la semaine précédente, les équipes devaient assumer ce travail d'infrastructure. Ici, l'abstraction ne masque plus l'algorithme mais le calcul. Il n'y a ni fichier décrivant tout le job à l'avance, ni étape de création de cluster. Le développeur pilote chaque étape de façon interactive, ce qui accélère l'itération et le débogage. Les chercheurs et ingénieurs peuvent ainsi se concentrer sur leurs données, leurs environnements de RL, leurs agents et leur algorithme, tandis qu'AWS gère l'allocation des GPU, le chargement du modèle et de LoRA, le stockage des points de contrôle et la sécurité. Cette annonce s'inscrit dans l'extension de l'offre de personnalisation sans serveur de SageMaker AI, qui se situe désormais entre les recettes préemballées et les clusters à gérer soi-même. Le RL et l'alignement évoluent vite, et les équipes veulent essayer des méthodes récentes sans reconstruire une pile d'entraînement à chaque fois. AWS publie en parallèle un « cookbook » de sessions d'entraînement, avec des recettes SFT et RL prêtes à l'emploi, utilisables comme modèles pour des boucles sur mesure. L'article en détaille deux usages : une boucle de RL minimale sur des problèmes de mathématiques de niveau primaire (GSM8K), puis une charge réaliste du cookbook, soit du RL sur des problèmes de programmation compétitive où le code généré est noté en l'exécutant contre des tests unitaires.

💬 Bon, sur le papier, c'est le genre de truc qu'on attendait : écrire sa propre boucle de RL ou d'alignement sans monter un cluster. Selon Le Fil IA, la vraie bascule est là : l'abstraction ne cache plus l'algorithme mais le calcul, et le goulot d'étranglement de la personnalisation passe de l'infrastructure à la qualité des données et des récompenses. Reste à voir si ça tient en prod, et ce que la facture dit quand tu laisses une session GPU persistante ouverte pendant que tu itères.

Au-delà du cache KV : entraînement et déploiement du modèle à attention linéaire Laplace 3B d'i14 sur AWS Trainium2 avec PyTorch natif

Les grands modèles de langage reposent pour la plupart sur des architectures transformer à attention softmax, dont le cache clé-valeur (KV) grossit avec la longueur de la conversation ou du document. Cela limite la concurrence, renchérit le service et pousse les applications agentiques à abandonner une partie de leur historique. La société de recherche i14 a conçu Laplace 3B comme une alternative à attention linéaire : son état récurrent reste fixé à 29,5 Mo par séquence, quelle que soit la longueur du contexte. Avec l'aide d'AWS, i14 a porté ce modèle sur les puces Trainium2 grâce à TorchNeuron Native, le backend PyTorch natif d'AWS Trainium, en conservant son architecture Gated Linear Attention (GLA) et l'optimiseur Muon. Sur une seule instance trn2.48xlarge, le modèle s'entraîne à environ 120 000 tokens par seconde et, en inférence, produit 11 544 tokens de sortie par seconde pour 1 280 séquences concurrentes. Pour les équipes qui déploient des modèles à long contexte, l'enjeu est la prévisibilité des coûts. Avec un état de taille fixe, la mémoire d'accélérateur par séquence ne dépend plus de l'historique, ce qui profite aux agents de longue durée, à l'analyse de gros documents et aux applications nécessitant une mémoire persistante. L'attention d'entraînement passe d'une complexité quadratique O(T²) à une complexité linéaire O(T). La contrepartie est qu'une attention linéaire compresse l'historique au lieu de conserver chaque clé et chaque valeur : la qualité de récupération d'information doit donc être évaluée selon chaque usage. Le travail montre aussi qu'une architecture sur mesure, d'abord écrite pour des noyaux Triton optimisés pour GPU, peut tourner sur un accélérateur AWS sans repartir de zéro. L'adaptation a demandé trois changements, réalisés avec le AWS Generative AI Innovation Center. Le noyau GPU fusedchunksimplegla a été remplacé par des opérateurs PyTorch standards, en découpant le calcul en 16 blocs de 128 tokens pour correspondre aux 128 partitions du tampon sur puce d'un NeuronCore. L'équipe a retenu la version bêta de TorchNeuron Native après l'avoir comparée à une réécriture purement PyTorch, car elle offrait de meilleures performances. Elle a ensuite repensé les communications de Muon : deux collectives allto_all dans MuonFSDP2 réduisent le trafic par rang d'un facteur 24 et augmentent le débit d'un facteur 1,63. Enfin, les 16 étapes de la récurrence GLA ont été déroulées statiquement dans la passe arrière, afin de respecter les limites de taille de graphe et de mémoire sur puce du compilateur. Une instance trn2.48xlarge réunit 16 puces Trainium2, 64 NeuronCores logiques, de la mémoire à haute bande passante et l'interconnexion NeuronLink-v3.

💬 Selon Le Fil IA, le vrai sujet n'est plus la vitesse du modèle mais la prévisibilité de son coût : avec un état fixe de 29,5 Mo par séquence, la mémoire cesse de grimper avec le contexte, et c'est là que les agents longue durée gagnent ou perdent leur rentabilité. Bon, sur le papier c'est séduisant. Mais une attention linéaire compresse l'historique, donc tu perds de la précision de rappel, et ça se teste cas d'usage par cas d'usage. Le portage de Triton vers Trainium2 sans tout réécrire, par contre, c'est plutôt une bonne nouvelle pour sortir de la dépendance aux GPU Nvidia.

Des données aux décisions : l'analyse conversationnelle de la supply chain avec Amazon Quick et Amazon Bedrock AgentCore

Amazon Web Services détaille un schéma d'architecture qui permet aux équipes supply chain d'interroger leurs systèmes en langage naturel, en combinant Amazon Quick, l'interface conversationnelle, et Amazon Bedrock AgentCore, la couche d'intelligence qui expose des serveurs MCP (Model Context Protocol) d'entreprise comme autant d'outils composables. Le scénario type suit une perturbation de bout en bout dans une seule conversation. L'utilisateur demande d'abord quels outils sont disponibles : Quick liste les quatre serveurs MCP métier publiés dans l'AWS Agent Registry, dont les paramètres de connexion sont préremplis dès lors qu'un administrateur a activé l'intégration. Il consulte ensuite les perturbations actives, et l'outil Disruption Alerts en renvoie trois, avec gravité, région et nombre de références touchées. Sur la plus critique, l'arrêt de production chez TechComp, un appel à assessdisruptionimpact corrèle commandes, clients et stocks : 750 000 dollars exposés, 23 commandes et trois jours de stock. La demande de recommandations enchaîne ensuite le serveur Governance, qui vérifie les fournisseurs alternatifs approuvés, et le serveur Quoting, qui produit un devis conforme aux contrats. L'utilisateur peut enfin programmer une alerte quotidienne en cas de nouvelle perturbation critique. L'enjeu est la compression du temps entre le signal et la décision. Une matinée type d'un responsable supply chain mobilise l'ERP pour les exceptions de stock, un outil de surveillance pour les alertes, le module d'achats pour les alternatives, la messagerie pour les demandes de devis et un tableur de suivi. Cela représente 45 à 60 minutes, cinq systèmes et plus d'une douzaine de changements de contexte. Le même parcours se réduit à trois requêtes, par exemple repérer les perturbations touchant les références les plus rentables, évaluer l'arrêt TechComp et lancer un appel d'offres d'urgence, puis valider l'envoi. Les réponses proviennent des systèmes de référence en temps réel et de documents ancrés, et non de la mémoire du modèle. Chaque modification attend la validation d'une personne nommément identifiée, ce qui répond à l'une des principales craintes des entreprises face aux agents autonomes. Le problème décrit n'est pas un manque de données, mais leur éloignement de ceux qui décident. L'expertise métier est détenue par les responsables, tandis que l'information opérationnelle est dispersée entre ERP, outils de surveillance, achats et courriels, et la corrélation se fait à la main. Répondre à une question comme « quelles références à fort chiffre d'affaires sont exposées à la fermeture d'un port, et à quel coût ? » supposait de savoir quel système détenait chaque pièce. L'approche d'AWS s'inscrit dans la montée en puissance du protocole MCP comme standard de connexion entre agents et systèmes d'entreprise, avec un registre central qui facilite la découverte des outils. Le billet explique aussi comment déployer soi-même ce modèle, ce qui laisse penser que le même schéma pourrait être décliné vers d'autres fonctions comme la finance ou les achats.

Découvrir des outils à l'exécution avec AWS Agent Registry

Face à des catalogues d'outils qui gonflent, AWS propose de ne plus câbler les capacités d'un agent au moment de la compilation, mais de les découvrir à l'exécution grâce à AWS Agent Registry. Ce service managé référence les serveurs MCP (Model Context Protocol), les agents et les compétences d'agents. Les éditeurs y enregistrent des descripteurs propres à chaque protocole et des descriptions interrogeables. Un exemple en Python illustre une boucle « Discover, Instantiate, Execute ». Il déploie un serveur MCP de gestion de commandes via Amazon Bedrock AgentCore Gateway, deux agents A2A (agent-à-agent) sur AgentCore Runtime, un registre et un orchestrateur sans connaissance préalable des outils. Lors de la découverte, l'orchestrateur envoie une requête en langage naturel au plan de données du registre. La réponse contient l'identité de l'enregistrement, son nom, sa description, son type, son statut, sa version et les descripteurs (métadonnées du serveur MCP ou carte d'agent A2A), mais aucun identifiant d'invocation. Pour chaque résultat, l'orchestrateur construit ensuite un client adapté. Pour le serveur MCP, le descripteur pointe vers le point d'accès de la Gateway, et un jeton OAuth Cognito est obtenu séparément pour créer le MCPClient. Pour les agents A2A, la carte d'agent indique l'URL d'un point d'accès AgentCore Runtime, appelé via le client boto3 qui signe la requête avec les identifiants AWS de l'appelant. Enfin, un agent interne éphémère est construit avec les seuls outils découverts, le modèle choisit les plus pertinents et la réponse est synthétisée. L'agent et ses clients sont détruits après le tour, et la requête suivante déclenche une nouvelle recherche. L'enjeu est très concret pour les entreprises. Des outils codés en dur fonctionnent pour une poignée de cas, se dégradent à quelques dizaines et deviennent ingérables au-delà. Or les systèmes d'entreprise exposent des centaines d'API internes (tarification, support, commandes, stocks, données clients). Le modèle peut alors consommer davantage de jetons à distinguer des noms d'outils qu'à raisonner sur la demande de l'utilisateur. Chaque nouvelle capacité exige aujourd'hui une modification du code de l'orchestrateur, un redéploiement et une publication coordonnée entre des équipes qui préféreraient livrer à leur propre rythme. Avec le registre, une nouvelle intégration devient utilisable après son enregistrement et son approbation, sans toucher à l'orchestrateur. La séparation entre découverte et authentification constitue aussi un point de sécurité notable : le registre fournit uniquement des métadonnées de connexion, et l'application doit obtenir ses identifiants par un chemin de configuration distinct et fiable. Ce schéma apparaît dans de nombreux projets de logiciels en mode SaaS d'entreprise, où des équipes exposent de vastes surfaces d'API à des consommateurs agentiques. Le câblage à la compilation devient alors un goulet d'étranglement à mesure que le catalogue s'étend. Le modèle d'architecture décrit s'appuie sur plusieurs briques de l'écosystème Amazon Bedrock AgentCore : un orchestrateur unique tourne sur AgentCore Runtime, interroge le registre, appelle les serveurs MCP via la Gateway et les agents A2A directement sur leur runtime. L'approche suppose toutefois une gouvernance du catalogue, puisque seuls les enregistrements approuvés et découvrables sont renvoyés, et une gestion rigoureuse des identifiants en dehors du registre. Le dépôt d'exemple contient le script de déploiement, l'orchestrateur, les modules utilitaires et le script de nettoyage.

💬 Quand tu as des centaines d'API internes, câbler les outils à la compilation, c'est du flan : le modèle brûle ses jetons à lire des noms d'outils au lieu de raisonner sur ta demande. Selon Le Fil IA, le vrai sujet n'est plus de construire des agents mais de gouverner un catalogue, et le registre d'outils devient le goulot où se décide qui a le droit de faire quoi. Bon, sur le papier, une intégration utilisable sans toucher à l'orchestrateur, c'est séduisant. Reste à voir si ça tient en prod, parce que tout repose sur la discipline d'approbation des enregistrements.

Avec TorchNeuron, Amazon veut faciliter l’entraînement des modèles sur ses puces Trainium

Amazon Web Services a présenté TorchNeuron, un projet open source destiné à simplifier l'entraînement de modèles d'intelligence artificielle sur ses puces Trainium, dont la troisième génération a été lancée en décembre 2025. Le projet s'appuie sur le mécanisme d'extension que PyTorch propose pour accueillir du matériel tiers. Dans le cas le plus simple, les développeurs n'ont qu'à remplacer dans leur code le périphérique cible « cuda » par « neuron ». PyTorch, bibliothèque créée par Meta et confiée à la Linux Foundation depuis 2022, sert à construire et entraîner des modèles. Entre elle et le matériel, une couche logicielle traduit les opérations en instructions compréhensibles par la puce. Chez NVIDIA, c'est le rôle de CUDA, technologie propriétaire de calcul généraliste sur GPU. TorchNeuron joue ce rôle pour Trainium, même si NVIDIA n'est jamais nommée dans l'annonce. La simplicité affichée reste toutefois théorique. L'exemple choisi par AWS, celui de Deepgram, concurrent d'ElevenLabs dans la synthèse vocale, montre que certaines fonctions de PyTorch ne sont pas encore prises en charge. Une partie des tests officiels de PyTorch est ignorée, faute de traduction de certains opérateurs de calcul. Deepgram affirme avoir obtenu 70 % d'audio supplémentaire pour chaque dollar dépensé, mais la mise en place de son flux de travail a exigé plusieurs mois. Pour les équipes d'ingénierie, l'enjeu est la baisse du coût de changement de puce. Amazon soutient que, si l'on peut changer sans pénalité, les fabricants devront mériter leur clientèle. Colin Brace, d'Annapurna Labs, filiale qui conçoit les puces d'Amazon, a répété à TechCrunch les arguments maison : l'infrastructure et l'écosystème d'AWS, et la possibilité d'employer la même puce pour l'entraînement et l'inférence, afin de réaffecter la capacité inutilisée. Ce lancement s'inscrit dans la lutte des grands acteurs du cloud contre leur dépendance à NVIDIA, dont la domination tient autant à son écosystème logiciel qu'à ses processeurs. Amazon n'est pas seul : Microsoft développe ses puces Maia et Google ses TPU. Amazon affirme que son approche dépasse son propre matériel. L'entreprise modifie PyTorch en amont, avec la communauté, pour retirer le code qui lie le framework à des puces spécifiques. L'objectif déclaré est de rendre PyTorch plus indépendant du matériel pour tous les développeurs, pas seulement pour les utilisateurs de Trainium. Cette neutralité vise en réalité NVIDIA, car la dépendance à CUDA peut allonger la configuration. Reste à savoir si la communauté PyTorch adoptera ces changements et si la couverture des opérateurs sera assez complète pour que le passage à Trainium ne demande plus des mois d'efforts.

💬 Selon moi, le vrai sujet n'est pas Trainium, c'est le prix de sortie de CUDA. Passer de « cuda » à « neuron » tient en une ligne sur le papier, mais Deepgram a mis plusieurs mois à monter son flux, et une partie des tests PyTorch est carrément ignorée. Tant que le coût de changement se compte en mois d'ingénieurs, NVIDIA garde son verrou, peu importe le prix de la puce. Reste à voir si ça tient en prod, et si la communauté PyTorch suit le nettoyage du code lié au matériel.

Pegasus 1.5 de TwelveLabs est désormais disponible sur Amazon Bedrock

Le 9 octobre 2026, Amazon Web Services a annoncé la disponibilité de Pegasus 1.5, le modèle de langage vidéo de TwelveLabs, sur Amazon Bedrock. Ce modèle transforme de longues vidéos en métadonnées structurées et horodatées. L'utilisateur décrit les moments qui comptent pour son flux de travail, par exemple des séquences éditoriales, des actions sportives, des changements d'interlocuteur ou des apparitions de marques, et le modèle renvoie chaque segment correspondant au format JSON, avec heures de début et de fin et les champs demandés. Pegasus 1.5 introduit aussi la segmentation vidéo, le prompt multimodal avec images de référence et le traitement à la volée, sans indexation préalable. Il analyse des vidéos jusqu'à deux heures en une seule requête, contre une heure pour Pegasus 1.2. Le modèle (identifiant twelvelabs.pegasus-1-5-v1:0) est proposé en inférence à la demande dans la région US West (Oregon), via les API InvokeModel et InvokeModelWithResponseStream. Deux modes existent : « général », avec un prompt texte et une réponse en texte ou en JSON selon un schéma fourni, et « timebasedmetadata », avec des définitions de segments et une liste de segments en retour. La vidéo peut être transmise par un URI Amazon S3, avec l'identifiant du compte propriétaire du bucket, ou par une chaîne base64. L'enjeu est considérable, car la vidéo reste l'une des catégories de données non structurées les plus vastes et les plus difficiles à exploiter. Jusqu'ici, en extraire des informations utilisables exigeait une revue manuelle fastidieuse ou un assemblage d'outils disparates. Avec Pegasus 1.5, les équipes des médias, du sport, de la publicité ou de la conformité peuvent obtenir directement des résultats exploitables par leurs systèmes, sans construire de pipeline d'ingestion. Le prompt multimodal permet par exemple de repérer un produit, un logo ou une personne précise à partir d'une image de référence, et de savoir ce que cette personne fait à l'écran. Les données restant dans le périmètre de données d'AWS, le modèle répond aussi à des exigences de confidentialité fréquentes en entreprise. La prise en charge multilingue est complète pour l'anglais et partielle pour l'arabe, le chinois, le français, l'allemand, l'italien, le japonais, le coréen, le portugais, le russe, l'espagnol, le thaï et le vietnamien. Cette sortie prolonge la lignée des modèles Pegasus, dont la version précédente permettait déjà de pointer un clip, de poser une question et d'obtenir une réponse. Pegasus 1.5 conserve les acquis de la version 1.2 : génération de texte à partir de vidéo, compréhension visuelle fine des objets, du texte à l'écran et des contenus numériques, localisation temporelle d'événements, et analyse combinant image, audio et texte. Le passage d'un modèle qui répond à une question à un modèle qui parcourt l'intégralité d'une vidéo et en extrait tous les segments pertinents marque une évolution vers des usages industriels. Pour l'heure, la disponibilité se limite à une région AWS et à l'inférence à la demande, ce qui laisse attendre des extensions géographiques. L'annonce s'inscrit dans la stratégie d'Amazon Bedrock, qui rassemble des modèles de fournisseurs tiers derrière une interface unique.

Comment Deepgram a optimisé son IA vocale à grande échelle avec AWS Trainium

Deepgram, dont les modèles couvrent la reconnaissance vocale, la synthèse vocale et les agents vocaux, traite désormais des quadrillions de jetons audio par an pour plus de 200 000 développeurs et 1 400 organisations. Avec l'équipe d'ingénierie de déploiement avancé (FDE) d'AWS, l'entreprise a porté son modèle de transcription Nova-3 sur les puces AWS Trainium2, pour les charges de travail par lots hors ligne comme l'analyse de centres de contact ou la transcription médicale. Le travail, étalé sur plusieurs mois, est parti du code PyTorch standard de Deepgram. La configuration finale fait tourner huit réplicas du modèle sur une seule instance Amazon EC2 trn2.3xlarge. Sur les charges orientées débit de Deepgram, elle traite entre 11 et 70 % d'audio en plus par dollar que les options de calcul utilisées jusque-là, d'après les tarifs d'instance en vigueur lors de l'évaluation. Techniquement, les équipes ont utilisé TorchNeuron, l'intégration native du compilateur Neuron à PyTorch, qui gère l'exécution immédiate comme torch.compile. Nova-3 a d'abord tourné en mode eager pour repérer les opérations retombant sur le processeur, puis a été compilé. Le chemin compilé exécute toutes les opérations sur Trainium2, sans repli CPU détecté. L'encodeur et le décodeur sont compilés en graphes distincts à formes statiques. La précision a été contrôlée à deux niveaux : cohérence des sorties couche par couche face au CPU, et taux d'erreur de mots (WER) de bout en bout, qui devait rester conforme aux valeurs de référence de Deepgram. L'optimisation a ensuite remplacé plusieurs couches par des noyaux fusionnés issus de la bibliothèque publique NKILib, écrits avec le Neuron Kernel Interface (projections QKV fusionnées, réseaux feed-forward fusionnés, convolution 1D en profondeur). Des tailles de lot de 1 à 128 ont été testées pour trouver celle qui maximise le débit. L'enjeu est économique : pour Deepgram, l'efficacité d'inférence détermine la quantité d'audio traitable pour un budget d'infrastructure donné. Sur des volumes massifs en lots, chaque heure d'accélérateur mieux utilisée permet de servir plus d'audio avec la même flotte. Ces gains aident l'entreprise à passer à l'échelle, à continuer de publier de meilleurs modèles et à les proposer à des prix plus bas. Ils peuvent aussi profiter aux clients qui hébergent les modèles dans leur propre cloud privé virtuel (VPC) via Amazon SageMaker AI, où Deepgram et AWS poursuivent l'amélioration de la simplicité de mise en place, de la fiabilité et de l'observabilité. Ce projet illustre la montée de la voix comme modalité à part entière de l'IA, et la recherche d'alternatives aux accélérateurs classiques pour en contenir le coût. La démarche suit un cycle d'optimisation répété : activer un noyau NKI, profiler la charge avec des outils comme Neuron Explorer, puis affiner ou remplacer le noyau selon les résultats, jusqu'à atteindre l'objectif de performance. Les auteurs précisent que le débit est exprimé en gain relatif par rapport à une configuration de référence, et non en secondes d'audio traitées. Ils décrivent aussi un environnement d'exécution Rust en parallélisme de données, qui permet au serveur de modèles de Deepgram d'appeler Trainium directement.

💬 Le vrai sujet, ce n'est pas Trainium, c'est que le coût d'inférence est devenu le terrain de jeu des acteurs de la voix : quand tu traites des quadrillions de jetons audio, gagner 11 à 70 % d'audio en plus par dollar vaut plus qu'un nouveau modèle. Bon, sur le papier c'est joli, mais la fourchette est énorme et le gain reste relatif à une référence maison, pas en secondes d'audio. Et ça ne vaut que pour le batch hors ligne, pas pour le temps réel qui fait vivre les agents vocaux. Reste à voir si ça tient en prod, et surtout si les prix baissent vraiment côté clients.

Présentation de Reflection Beam : un modèle open-weight pour le code à base d'agents sur AWS

Reflection AI a présenté Beam, un modèle à poids ouverts conçu pour le codage agentique et les tâches de longue haleine : maintenance de code, utilisation d'outils, interprétation de résultats intermédiaires et exécution de workflows en plusieurs étapes. Il s'agit d'un modèle de type mixture d'experts parcimonieux, doté de 501 milliards de paramètres au total mais de seulement 23 milliards actifs par token. Reflection annonce une longueur de contexte effective d'un million de tokens. Les poids sont publiés sur Hugging Face sous licence Apache 2.0, en trois variantes de checkpoint (BF16, FP8 et NVFP4) qui offrent des empreintes mémoire et des compatibilités matérielles différentes. Amazon Web Services détaille trois voies de déploiement : un endpoint temps réel Amazon SageMaker JumpStart entièrement managé, JumpStart sur SageMaker HyperPod Inference pour ceux qui veulent un contrôle Kubernetes via Amazon EKS, et enfin SGLang ou vLLM sur HyperPod pour maîtriser l'image de service, les arguments d'exécution, la quantification et l'exécution distribuée. Au lancement, Beam est disponible dans JumpStart dans les régions US East (Virginie du Nord) et US East (Ohio). Cette publication importe parce qu'un modèle de cette taille, librement modifiable, devient exploitable en production sans dépendre d'une API fermée. Les équipes peuvent choisir leur environnement d'exécution, personnaliser le modèle et conserver la maîtrise de leurs données et de leurs coûts. Le choix entre les trois voies dépend du compromis entre simplicité et contrôle : l'endpoint JumpStart évite d'opérer Kubernetes, tandis que HyperPod expose le cluster, le routage, la mise en cache et l'autoscaling. Les 501 milliards de paramètres déterminent le stockage des checkpoints, la mémoire nécessaire aux poids, le partitionnement et le parallélisme, alors que les 23 milliards de paramètres actifs pèsent sur le calcul par token. Le dimensionnement doit aussi intégrer le cache KV, la longueur de contexte, le batching et la charge d'exécution, à partir de la concurrence et des objectifs de latence mesurés. Il faut également disposer d'un quota et d'une capacité GPU adaptés, d'un compte AWS avec les permissions voulues, de l'AWS CLI et de Python 3.11 ou supérieur, et accepter les conditions du modèle. Cette annonce s'inscrit dans la stratégie de Reflection AI, qui affirme vouloir rendre l'intelligence ouverte et accessible à tous grâce à des poids ouverts, des recherches publiées et des logiciels open source. L'entreprise développe une pile complète couvrant modèles, logiciels de base, infrastructure de production et applications, et Beam la décline vers les développeurs de systèmes d'ingénierie logicielle et d'agents. Pour AWS, l'enjeu est de proposer des modèles ouverts de pointe sur son infrastructure, en concurrence avec les offres fermées et avec les autres clouds. La disponibilité limitée à deux régions américaines au lancement laisse attendre une extension géographique, et la possibilité de passer de JumpStart à HyperPod ou à des runtimes personnalisés permet de monter en charge progressivement.

💬 Un modèle de 501 milliards de paramètres sous Apache 2.0, c'est le genre de truc qu'on attendait pour sortir de la dépendance aux API fermées. Mais lis bien le mode d'emploi : 23 milliards actifs par token, ça allège le calcul, pas la mémoire, donc il te faudra quand même un gros parc de GPU. Selon Le Fil IA, un modèle « ouvert » à cette taille reste surtout ouvert pour ceux qui ont déjà le quota cloud, et AWS vend ici la maîtrise de tes données avec le péage qui va avec. Reste à voir si ça tient en prod, d'autant que pour l'instant ça tourne uniquement en Virginie et dans l'Ohio, pas franchement idéal pour une boîte européenne.

Génère des présentations avec Amazon Bedrock AgentCore

Une équipe de services financiers passe chaque semaine un temps considérable à fabriquer à la main des présentations PowerPoint pour ses clients à partir de rapports trimestriels, de documents de conformité et d'analyses de marché. Amazon Web Services décrit un système d'agents IA, bâti sur Amazon Bedrock AgentCore, qui automatise ce travail et le termine en moins de 90 secondes lors de tests internes. Un agent superviseur est déployé sur le runtime AgentCore et s'appuie sur le framework open source Strands Agents. Il choisit entre deux outils : generatepptx, qui appelle une fonction AWS Lambda conteneurisée pour récupérer le contenu, produire le plan des diapositives, créer les images et assembler le fichier, et generatesummary, qui synthétise l'information de la base de connaissances par recherche documentaire. Claude Sonnet 4.6, disponible sur Amazon Bedrock, rédige le contenu. Amazon Titan Text Embeddings v2 alimente la recherche vectorielle, et Stability AI Stable Image Inpaint génère les visuels. Le stockage vectoriel et la recherche sémantique multimodale reposent sur Amazon OpenSearch Serverless, et une API REST en .NET 8 permet de l'intégrer aux applications d'entreprise par de simples appels HTTP. Le code est publié dans un dépôt public. L'enjeu pratique est double : gagner du temps et garder les contenus ancrés dans les documents sources. Un analyste n'a plus à lire des centaines de pages, extraire les données clés, structurer les diapositives et chercher des illustrations, ce qui libère du temps pour l'analyse et la relation client. L'architecture par outils rend aussi le système extensible : une nouvelle capacité s'ajoute en définissant un outil dans le code de l'agent, sans toucher aux existants. Pour des secteurs réglementés comme la finance, la sécurité compte autant que la vitesse. La solution isole les ressources dans un Amazon VPC, chiffre les données avec AWS KMS et applique le principe du moindre privilège via IAM. L'agent s'exécute dans un conteneur isolé, avec gestion de session, identité intégrée et observabilité. Cette approche répond à une difficulté connue des agents : un agent unique chargé de produire des documents à partir de grandes bases de connaissances doit récupérer du contenu, structurer un plan, écrire, créer des images et assembler un fichier. Plutôt que de réunir ces responsabilités dans une fonction monolithique, l'architecture les répartit entre outils spécialisés orchestrés par un superviseur. Elle repose sur la génération augmentée par récupération (RAG), qui ancre les réponses dans les données de l'entreprise plutôt que dans les seules connaissances d'entraînement du modèle. Les documents sont déposés dans Amazon S3, puis découpés et analysés par Amazon Bedrock Knowledge Bases, qui associe recherche vectorielle et modèles de langage pour récupérer le contexte pertinent avant de générer. AWS positionne AgentCore comme une plateforme pour construire et exploiter des agents à grande échelle, avec n'importe quel framework ou modèle, face à une concurrence croissante sur l'orchestration d'agents d'entreprise.

Créer des agents à long horizon avec Grok 4.7 sur Amazon Bedrock

SpaceXAI a rendu son modèle Grok 4.7 disponible sur Amazon Bedrock, la plateforme d'AWS qui propose des modèles de fondation de plusieurs fournisseurs. Selon SpaceXAI, ce modèle est entraîné pour travailler plus longtemps sur des tâches difficiles et pour vérifier son propre travail. Il repose sur un modèle de base plus grand que Grok 4.6 et sur un apprentissage par renforcement plus long, orienté vers des problèmes qui demandent de nombreuses heures. Les gains publiés sont nets sur le travail soutenu : Terminal-Bench 4.0 passe de 20,3 % à 37,6 %, EEBench (ingénierie électrique) de 53,0 % à 64,0 %, CursorBench 4.0 de 40,4 % à 46,3 %, HealthBench Professional de 48,5 % à 56,7 % et le Harvey Legal Agent Benchmark de 15,8 % à 19,6 %. Le modèle offre une fenêtre de contexte de 500 000 jetons, accepte texte et image en entrée, et produit du texte. Sur Bedrock, il gère le raisonnement paramétrable, l'appel d'outils et la sortie structurée. Pour mesurer l'effet du réglage de l'effort de raisonnement, les auteurs ont construit un agent appelant des outils et l'ont testé sur trois tâches de recherche : diagnostiquer une panne touchant deux services à partir des alertes, planifier une maintenance sous contraintes croisées, et choisir un ensemble optimal de migrations sous budget. Chaque tâche a une seule bonne réponse, vérifiée par force brute. Avec six essais par niveau d'effort, soit 72 exécutions, l'agent a répondu juste 67 fois. Au niveau xhigh, il a réussi les 18 essais ; au niveau low, il en a réussi 15 sur 18 en consommant environ huit fois moins de jetons de sortie. Ce résultat chiffre un compromis que les équipes peuvent régler requête par requête. Pour les agents, qui enchaînent de nombreuses étapes et doivent vérifier ce qu'ils découvrent, il ne suffit pas de chercher une information : il faut formuler une réponse candidate, la confronter à ce qui a été appris, puis l'affiner. Un effort élevé garantit ici la fiabilité maximale, tandis qu'un effort faible réduit fortement la consommation pour une perte de précision modeste. Les auteurs choisissent de rapporter des quantités de jetons plutôt que des montants, car les tarifs évoluent alors que les volumes permettent à chacun de calculer ses propres coûts. Ils insistent aussi sur la méthode : les benchmarks publics décrivent un comportement moyen, mais seule une mesure sur des tâches proches de la charge réelle indique quel niveau d'effort retenir, et un suivi en production permet ensuite d'ajuster ce choix. L'accès se fait par le point d'entrée bedrock-runtime, via un profil d'inférence inter-régions plutôt qu'un identifiant de modèle seul. Le profil us.xai.grok-4.7 maintient le routage dans la géographie américaine, utile en cas d'exigence de résidence des données, tandis que global.xai.grok-4.7 répartit les requêtes sur les régions commerciales d'AWS pour obtenir la plus grande capacité. Ce routage inter-régions augmente le débit sans obliger à gérer la capacité région par région. Le modèle est compatible avec les API Chat Completions et Responses d'OpenAI ainsi qu'avec l'API Converse d'Amazon Bedrock, où le raisonnement est renvoyé dans un bloc reasoningContent à côté du texte. Dans la configuration d'inférence, il faut seulement définir maxTokens et placer les paramètres propres au modèle ailleurs. Cette arrivée s'inscrit dans la stratégie d'AWS de proposer un large choix de modèles concurrents, au moment où l'industrie se concentre sur des agents capables de mener des tâches longues de façon autonome.

💬 Passer l'effort de xhigh à low donne 15 réussites sur 18 au lieu de 18, pour environ huit fois moins de jetons de sortie. Ce n'est pas un détail de réglage, c'est le vrai sujet des agents à long horizon : la fiabilité devient un curseur qu'on paie au jeton, requête par requête. Bon, sur le papier, c'est propre. Mais 18 essais par niveau sur trois tâches à réponse unique, c'est maigre, et les gains de Grok 4.7 restent des chiffres maison. Reste à voir si ça tient sur tes vraies charges, et c'est exactement ce que les auteurs te disent de mesurer.

Peut-on modifier l'architecture d'un modèle d'IA sans le réentraîner de zéro ?

Les modèles Transformer paient une « taxe mémoire » qui croît avec le nombre de jetons traités, un coût qui s'alourdit à mesure que les agents d'IA mènent des sessions plus longues et des raisonnements plus profonds. Pour y remédier, plusieurs architectures hybrides combinent attention parcimonieuse (qui ne retient qu'un sous-ensemble des jetons passés), attention à fenêtre glissante (qui ne conserve que les jetons les plus récents) et modèles à espace d'états (qui compressent tout l'historique dans un état de taille fixe). Jusqu'ici, comparer ces approches imposait d'entraîner chaque architecture de zéro, avec des milliers de milliards de jetons et des centaines de milliers d'heures de GPU. Une équipe d'Amazon Web Services publie « Priming : modèles hybrides à espace d'états issus de Transformers préentraînés », une méthode qui réutilise les poids d'un Transformer existant comme point de départ et réduit de plus de 99 % le coût de préentraînement d'un hybride. Les chercheurs ont comparé trois types de modèles à espace d'états : Gated KalmaNet (GKA), Gated DeltaNet (GDN) et Mamba-2. Dans des conditions contrôlées, GKA arrive en tête, suivi de GDN puis de Mamba-2. Les modèles à espace d'états surpassent systématiquement l'attention à fenêtre glissante, même lorsque celle-ci dispose d'un budget mémoire doublé. Un hybride de 32 milliards de paramètres basé sur GKA égale son Transformer d'origine sur des tests de raisonnement, tout en décodant jusqu'à deux fois plus vite avec 128 000 jetons de contexte et en atteignant la bonne réponse en seulement deux tiers du temps réel. L'enjeu est d'abord économique et scientifique. Quand chaque expérience coûte un entraînement complet, seuls quelques grands laboratoires peuvent explorer l'espace de conception des architectures, et les comparaisons rigoureuses restent rares. Avec le priming, les développeurs peuvent désormais tester des questions jusque-là inabordables à grande échelle : quelles couches d'attention remplacer par des couches plus efficaces, combien en remplacer sans perdre en qualité, quelle couche à espace d'états est la meilleure, et à quoi ressemble le compromis entre vitesse et précision. Les résultats livrent aussi un enseignement concret : un résumé approximatif de tout l'historique vaut mieux qu'un enregistrement parfait du passé récent. GKA offre en outre une particularité précieuse, un calcul d'inférence de longueur variable sans réentraînement, qui permet à l'utilisateur de choisir lui-même sa position sur la frontière vitesse-précision. Pour les entreprises qui déploient des agents à long contexte, cela se traduit par des réponses plus rapides et des coûts de serveur réduits. Ces travaux s'inscrivent dans la multiplication des architectures hybrides, qui cherchent à contourner la limite structurelle de l'attention. Dans un Transformer, chaque jeton produit une requête, une clé et une valeur par multiplication avec des matrices de projection apprises. La pertinence se calcule en comparant la requête courante à la clé de chaque jeton précédent, et le contexte à conserver grandit avec chaque jeton généré. Les approches hybrides diffèrent par la manière dont elles retiennent et exploitent le passé. Pour encourager la recherche, l'équipe d'AWS publie sous licence Apache 2.0 un ensemble de modèles hybrides primés à 8 et 32 milliards de paramètres, destinés au raisonnement à long contexte et au suivi d'instructions, avec le code d'entraînement, des noyaux optimisés et un plugin de service pour vLLM. Reste à voir si la communauté s'emparera de ces outils pour confronter systématiquement les architectures.

💬 Selon Le Fil IA, la vraie nouveauté n'est pas une architecture de plus, c'est que tester une architecture ne coûte plus un entraînement complet, donc que la recherche sur les hybrides s'ouvre à ceux qui n'ont pas des milliers de GPU. Réduire de 99 % le coût de préentraînement, c'est le genre de truc qu'on attendait depuis 2 ans. Et le résultat qui m'accroche : un résumé approximatif de tout l'historique bat un souvenir parfait du passé récent. Bon, un hybride 32B qui égale son Transformer sur du raisonnement, c'est encourageant, mais reste à voir si ça tient en prod sur de vrais agents.

Un seul prompt a suffi à détourner tous les agents IA d'un compte AWS, selon les chercheurs de Zenity

Des chercheurs de Zenity Labs ont montré qu'un seul agent d'intelligence artificielle accessible publiquement sur Amazon Bedrock AgentCore suffisait à prendre le contrôle de tous les agents AgentCore du même compte AWS et de la même région. L'attaque exploite une interface interne d'AWS qui délivre des identifiants cloud temporaires, et que les agents pouvaient joindre sans aucune restriction. Une seule instruction malveillante adressée à l'agent exposé a donc suffi à ouvrir l'accès à tous les autres. AWS a depuis corrigé la faille et resserré de façon significative les permissions par défaut accordées aux agents. L'enjeu dépasse ce cas précis. Les entreprises déploient de plus en plus d'agents qui cohabitent dans un même compte cloud, avec des niveaux de sensibilité très différents. Un agent public de support client peut ainsi côtoyer des agents qui manipulent des données internes. Si la compromission du plus exposé donne accès à tous les autres, la séparation censée les isoler n'existe plus en pratique. Les équipes qui utilisent AgentCore ont donc intérêt à revoir leurs configurations et les droits attribués à chacun de leurs agents. Cette découverte s'ajoute aux travaux qui montrent que les agents IA, capables d'agir et pas seulement de répondre, élargissent la surface d'attaque des environnements cloud. L'injection de prompt reste le point d'entrée privilégié, et des permissions trop larges transforment une faille mineure en compromission généralisée. En durcissant les droits par défaut, AWS applique le principe du moindre privilège dès la conception plutôt que de le laisser à la charge des clients. La question est maintenant de savoir si d'autres plateformes d'agents présentent des faiblesses comparables.

💬 Un seul agent public qui ouvre la porte à tous les autres, ça veut dire que l'isolation entre agents d'un même compte cloud n'existait que sur le schéma d'architecture. Le bot de support client exposé à Internet et l'agent qui brasse des données internes partageaient en fait les mêmes clés. Bon, AWS a corrigé et resserré les droits par défaut, tant mieux, mais le vrai sujet reste ailleurs : si ton agent public peut joindre quoi que ce soit d'interne, une injection de prompt suffit. Reste à voir combien d'autres plateformes d'agents ont le même trou, et je ne parierais pas sur zéro.

Claude Haiku 5.5 est disponible sur AWS

AWS et Anthropic annoncent la disponibilité de Claude Haiku 5.5 sur Amazon Bedrock et sur Claude Platform on AWS. Selon Anthropic, il s'agit du modèle le plus rapide et le plus efficace de la famille Claude 5.5, conçu pour les sous-agents et les tâches à gros volume sensibles aux coûts. Il coûte environ 75 % de moins que Claude Haiku 4.5 pour la plupart des usages. C'est aussi le premier modèle Haiku doté de contrôles d'effort, qui permettent d'ajuster le compromis entre coût et intelligence tâche par tâche plutôt que d'imposer un seul réglage à toute une charge de travail. Anthropic le présente comme son Haiku le plus performant en programmation, utilisation d'outils, utilisation d'ordinateur et tâches agentiques. Sur Bedrock, les données restent dans l'infrastructure AWS avec une résidence régionale, et le service s'intègre aux outils déjà employés par les équipes : IAM pour les accès, CloudTrail pour l'audit, CloudWatch pour la surveillance et Bedrock Guardrails. La consommation apparaît sur la facture AWS. Claude Platform on AWS offre pour sa part l'accès à l'expérience native d'Anthropic (mêmes API, mêmes fonctionnalités, même console) via la console AWS, avec facturation et authentification unifiées. L'enjeu est surtout économique et opérationnel. Haiku 5.5 vise le travail rapide et répétitif exécuté à grande échelle : routage de requêtes, revue de code, classification de longs documents, extraction d'informations dans des documents de taille petite à moyenne, premiers balayages et réponses rapides sur une base de connaissances. Il traite aussi les tâches classiques de traitement du langage (classification, résumé, génération de texte) à un volume et un coût compatibles avec une production. Il gère le codage agentique, les enchaînements d'outils en plusieurs étapes et les images haute résolution. Il peut servir de sous-agent d'utilisation d'ordinateur pour des tâches répétitives dans un navigateur ou sur un bureau, ainsi que pour itérer vite sur l'interface et l'expérience utilisateur ou pour de petites modifications ciblées réparties sur plusieurs fichiers. Sa rapidité permet aussi de lancer de nombreux sous-agents en parallèle. Haiku 5.5 s'inscrit dans une logique d'architecture à deux niveaux avec Claude Opus 5.5, annoncé récemment. Opus 5.5 planifie, découpe les problèmes complexes, choisit l'approche et assume le raisonnement le plus difficile, comme le débogage de versions, la revue de sécurité de grosses pull requests ou les longues analyses aboutissant à un rapport. Haiku 5.5 forme la couche rapide de sous-agents : routage, classification, résumé, réécriture de longs documents, application de changements ciblés sur de nombreux fichiers. Dans un rôle de relecteur, il peut vérifier l'ordre des opérations et la direction générale pour qu'Opus consacre ses jetons aux raisonnements les plus ardus. Pour l'essayer sur Bedrock, il suffit d'ouvrir la console, de choisir Test puis Playground et de sélectionner Haiku 5.5. Le modèle est aussi accessible par programmation via l'API Anthropic Messages, avec le SDK Anthropic, sur bedrock-runtime.

Évaluer l'explicabilité et l'utilité de systèmes multi-agents avec Amazon Bedrock AgentCore

Amazon Web Services détaille comment évaluer les systèmes multi-agents avec Amazon Bedrock AgentCore Evaluations, une capacité entièrement gérée de la plateforme Amazon Bedrock AgentCore, conçue pour construire, connecter et optimiser des agents à grande échelle, avec n'importe quel framework ou modèle. L'outil mesure la performance des agents en développement comme en production, sur plusieurs dimensions de qualité : exactitude, réussite des tâches et comportement. Il propose des évaluateurs intégrés, prêts à l'emploi, qui couvrent des critères courants comme l'utilité, la réussite de la tâche ou le respect des instructions. Il permet aussi de créer des évaluateurs personnalisés pour des vérifications propres à un métier. L'explicabilité y est traitée comme une dimension d'évaluation à part entière. Les évaluateurs intégrés jugent la clarté générale des réponses. Les évaluateurs personnalisés vérifient que l'agent énonce explicitement la justification de ses décisions, cite les données ou les résultats d'outils qui l'appuient et explique les arbitrages, comme le compromis entre coût et niveau de service. La démonstration repose sur une entreprise fictive, AnyCompany Retail, un distributeur multinational avec commerce en ligne, centres logistiques régionaux et milliers de magasins. Elle y construit un système multi-agents de décision pour la chaîne d'approvisionnement, avec le SDK Strands Agents et Amazon Bedrock AgentCore. Ce sujet compte parce que le passage de l'expérimentation à la production fait apparaître un problème central : garantir que ces systèmes restent utiles, exacts et explicables dans des situations réelles. Les entreprises les utilisent pour des tâches qui dépassent la simple question-réponse, comme la planification logistique, l'analyse financière ou les opérations clients. Ces agents coordonnent des spécialistes, exécutent des flux de travail et formulent des recommandations. Des réponses fluides ne suffisent plus. Les agents doivent suivre les consignes de façon fiable, choisir les bons outils, respecter les contraintes métier et exposer leur raisonnement. Les méthodes qui ne jugent que la qualité de la réponse du modèle deviennent insuffisantes, car la justesse dépend aussi du choix des outils, de l'exécution du flux et du respect des règles de l'entreprise. Pour un planificateur, savoir pourquoi un agent préconise tel transfert de stock ou tel transporteur conditionne la confiance qu'il peut lui accorder. Le contexte est celui d'une adoption rapide des agents en entreprise, qui oblige à industrialiser leur contrôle. AWS associe l'évaluation à Amazon Bedrock Guardrails, qui apporte des garde-fous configurables comme le filtrage de contenu, la détection de sujets interdits et la validation d'ancrage factuel. La différence est de moment : les évaluations jugent la qualité de l'agent après l'exécution, tandis que les Guardrails imposent des contraintes de sécurité pendant celle-ci. Le cas d'AnyCompany illustre des problèmes concrets : ruptures de stock dans certaines régions pendant les promotions, surstocks ailleurs, et arbitrages entre rapidité de livraison, capacité des transporteurs et coût. L'assistant envisagé doit optimiser l'allocation des stocks, recommander des ajustements de distribution, analyser la santé des stocks et simuler des scénarios d'acheminement ou d'exécution des commandes.

💬 Un agent qui répond bien mais choisit le mauvais outil ou ignore une règle métier, c'est un agent qui échoue avec le sourire, et noter seulement la qualité du texte ne le verra jamais. Selon Le Fil IA, la vraie unité d'évaluation d'un système multi-agents n'est plus la réponse mais la justification qui l'accompagne : un agent qui ne cite pas ses données ni ses arbitrages n'est pas déployable, quelle que soit sa fluidité. Évaluer l'explicabilité avec des critères maison, c'est malin, bon, sur le papier. Reste à voir si un LLM qui juge un autre LLM tient en prod.

Ajoutez une recherche web sécurisée à Claude Desktop avec Amazon Bedrock AgentCore

Claude Desktop sur Amazon Bedrock est limité par la date de coupure des connaissances du modèle : documentation récente, tarifs en direct ou météo lui échappent. AWS propose de combler cette lacune avec Web Search, une capacité de recherche web entièrement gérée et compatible avec le protocole MCP (Model Context Protocol), exposée via AgentCore Gateway, un composant d'Amazon Bedrock AgentCore. Elle s'appuie sur un index web d'Amazon couvrant des dizaines de milliards de documents. Tout le trafic de requêtes reste dans l'infrastructure AWS, sans clé API externe à gérer. Web Search est disponible dans trois régions : US East (Virginie du Nord, us-east-1), Europe (Irlande, eu-west-1) et Asie-Pacifique (Tokyo, ap-northeast-1). Le tutoriel d'AWS décrit une configuration en plusieurs étapes. Elle commence par la création d'un pool d'utilisateurs Amazon Cognito, via la CLI AWS, qui sert d'émetteur de jetons OpenID Connect pour la passerelle. Claude Desktop se connecte ensuite à la passerelle en tant que serveur MCP géré, avec la cible Web Search activée. L'intérêt tient surtout à la sécurité et à la gouvernance. Beaucoup d'entreprises utilisent déjà AWS IAM Identity Center pour l'authentification unique. Elles peuvent donc donner à Claude Desktop un accès à la recherche web par un flux d'identité qu'elles maîtrisent déjà, sans identifiants distincts ni fournisseur d'identité tiers. Les requêtes ne quittent pas le périmètre AWS, ce qui répond à une préoccupation courante des organisations soumises à des exigences de confidentialité : éviter que des questions internes transitent par des services de recherche externes. Pour les équipes techniques, cela évite aussi de gérer, de renouveler et de protéger des clés API supplémentaires. Les utilisateurs obtiennent des réponses à jour, sans quitter leur assistant ni contourner les règles de sécurité de l'entreprise. Sur le plan technique, la solution enchaîne plusieurs briques. IAM Identity Center authentifie les utilisateurs par SAML (Security Assertion Markup Language). Amazon Cognito sert de couche de fédération et émet des jetons JWT (JSON Web Token) selon le flux OAuth 2.0 avec code d'autorisation. AgentCore Gateway valide ces jetons à chaque requête, de sorte que toute la chaîne d'authentification reste dans AWS. Les prérequis sont un compte AWS autorisé à créer des rôles IAM et des ressources AgentCore, un accès administrateur au compte de gestion d'AWS Organizations, IAM Identity Center déjà configuré, Claude Desktop paramétré avec Bedrock comme fournisseur d'inférence, la CLI AWS v2, Python 3.10 ou supérieur et une version à jour du SDK Boto3. Cette approche s'inscrit dans la volonté d'AWS de faire d'AgentCore une plateforme pour construire, connecter et optimiser des agents à grande échelle, avec n'importe quel framework ou modèle. Le protocole MCP s'impose comme la manière standard de brancher des outils externes aux assistants d'IA.

💬 Une recherche web managée, c'est un détail pour un particulier, mais c'est un feu vert pour une DSI. Selon moi, ce qui bloque l'IA en entreprise n'est plus la qualité du modèle, c'est de savoir où passent les questions internes et qui détient les clés. AWS répond en gardant tout dans son périmètre, sans clé API à renouveler, et avec la région Irlande côté Europe. Bon, sur le papier. Entre Cognito, SAML, JWT et IAM Identity Center, le tuto est long pour une simple recherche web, et reste à voir si ça tient en prod.

Créer un pipeline de production musicale multi-agents sur Amazon Bedrock AgentCore Runtime Instances

Amazon Web Services a détaillé le déploiement d'un pipeline de production musicale à trois agents sur Amazon Bedrock AgentCore, en s'appuyant sur une nouvelle option d'hébergement baptisée Runtime Instances. Contrairement aux microVM serverless, dont les sessions plafonnent à 8 heures et qui hébergent un seul agent par runtime, les Runtime Instances reposent sur des instances EC2 gérées par AWS, dans le compte du client. Elles autorisent des sessions allant jusqu'à 14 jours, l'accès à des GPU, un stockage persistant sur Amazon EBS et la cohabitation de plusieurs agents sur une même machine. Le pipeline de démonstration comprend un agent de composition, un agent de livraison et un agent de conformité. Le premier transforme la demande d'un producteur en brief musical grâce à Claude Sonnet 4.6, puis génère l'audio avec ACE-Step, un modèle open source de génération musicale, sur le GPU de l'instance. Le deuxième lit le fichier .wav sur le volume partagé, le mesure, demande à Claude Sonnet 4.6 une chaîne de traitement (égalisation, compression, limitation) à partir de ces mesures plutôt que du son lui-même, applique un vrai traitement du signal, puis vérifie que la cible de livraison est atteinte. Le troisième re-mesure indépendamment le résultat, le compare aux cibles annoncées et le confronte au catalogue du studio pour détecter d'éventuelles similarités harmoniques. En cas d'objection, il demande un remplacement à l'agent de composition et relance la vérification. L'enjeu dépasse la musique. Dès que plusieurs agents doivent collaborer sur un flux de travail créatif s'étalant sur plusieurs jours, en partageant contexte et fichiers intermédiaires, les sessions serverless limitées à quelques heures deviennent un obstacle. Avec les Runtime Instances, deux runtimes rattachés au même fournisseur de capacité peuvent être invoqués avec le même identifiant de session (runtimeSessionId) et atterrissent sur la même instance EC2, où ils partagent un système de fichiers. Les agents peuvent ainsi se passer directement des artefacts volumineux, comme un fichier audio, sans les transférer par des API. Les entreprises gardent en outre la main sur les coûts : l'infrastructure tourne dans leur compte, ce qui leur permet d'utiliser leurs Savings Plans et leurs réservations de capacité à la demande (ODCR), là où les microVM sont facturées à la consommation. Les deux modèles proposent les mêmes API de runtime et prennent en charge CrewAI, LangGraph, LlamaIndex, Strands Agents, MCP et A2A, ce qui limite les efforts de migration. Cette annonce s'inscrit dans le passage des organisations d'agents mono-tâche, comme un assistant de requêtes clients, à des systèmes multi-agents dont les besoins d'infrastructure changent : durée, mémoire partagée, calcul accéléré. Les agents peuvent être livrés sous différentes formes, images de conteneur dans Amazon ECR pour les deux premiers, archive zip pour l'agent de conformité, ce qui illustre la flexibilité du déploiement. L'article, qui guide pas à pas la création de fournisseurs de capacité, l'orchestration entre agents par sessions partagées et la persistance sur plusieurs jours, vise à faire d'AgentCore une plateforme adaptée aux charges de travail longues et gourmandes en GPU, face aux offres concurrentes de Google Cloud et de Microsoft. La suite dépendra de l'adoption de ce modèle par les entreprises qui souhaitent héberger des équipes d'agents spécialisés sur une infrastructure qu'elles contrôlent.

💬 Les sessions de 8 heures, c'était bien pour un chatbot, pas pour une équipe d'agents qui bossent pendant des jours sur les mêmes fichiers. Selon Le Fil IA, le vrai sujet n'est pas la musique, c'est que le multi-agents fait glisser le problème de l'orchestration vers l'infra : durée de session, disque partagé, GPU. Bon, sur le papier, deux agents qui se passent un .wav via un volume EBS plutôt que par API, c'est propre, et héberger ça dans ton propre compte pour garder tes Savings Plans, ça parle aux DSI. Reste à voir si ça tient en prod, parce que tu reprends aussi la gestion des instances EC2.

Une intelligence proche d'Astra pour le travail quotidien avec GPT-6.1 Sol sur Amazon Bedrock

GPT-6.1 Sol est désormais disponible en disponibilité générale sur Amazon Bedrock, où il s'exécute sur un moteur d'inférence conçu pour la performance, la sécurité et la fiabilité à grande échelle. Présenté comme une mise à niveau majeure de GPT-6 Sol, le modèle vise le codage agentique, l'utilisation d'ordinateur et les tâches professionnelles. Selon OpenAI, il apporte une intelligence « proche d'Astra » aux usages quotidiens. Sur le benchmark DeepSWE v1.1, il égalerait GPT-6 Astra pour environ un cinquième du coût par tâche, et dépasserait de 6,4 points de pourcentage le meilleur score de GPT-6 Sol, tout en mobilisant un effort de raisonnement moindre. Il s'approcherait aussi d'Astra pour l'analyse de documents complexes et améliorerait GPT-6 Sol sur les flux de travail à plusieurs étapes à travers des outils métier. Codex, disponible en application de bureau, en ligne de commande et dans certains environnements de développement, peut être configuré pour utiliser le modèle via Bedrock afin d'enquêter, d'implémenter et de tester du code. Pour le développement sur AWS, l'Agent Toolkit for AWS relie Codex à la documentation, aux API et aux services d'Amazon par une seule commande de terminal. Dans l'application de bureau, ChatGPT Work peut rassembler des informations issues de fichiers et d'applications pour produire des livrables finis. L'enjeu est d'abord économique. Pour un agent d'IA, le coût réel d'une tâche ne se résume pas au prix des jetons : il dépend aussi du nombre d'interactions nécessaires et de leur réussite. Un agent doit collecter des informations, utiliser des outils, tester plusieurs approches, corriger ses erreurs et vérifier son résultat, et chaque décision conditionne la suite. Une mauvaise piste ajoute des appels au modèle, des appels d'outils, de la latence et parfois une intervention humaine. Un meilleur raisonnement réduit donc le coût total en évitant ces détours. Le modèle serait aussi plus fiable face aux limites : selon OpenAI, il progresse sur des évaluations exigeantes de transparence, de respect de l'intention de l'utilisateur et de restrictions explicites, ce qui permet de signaler un outil défaillant, une action interdite ou une information manquante avant que l'agent ne poursuive avec des données incomplètes. Ce lancement s'inscrit dans la stratégie d'Amazon Bedrock, qui se positionne comme l'infrastructure de production pour ces modèles, avec des contrôles de gouvernance côté entreprise. Via les API Bedrock prises en charge, les développeurs définissent les outils accessibles au modèle et décident comment l'application réagit lorsqu'une action exige une approbation ou ne peut aboutir, afin de garder des humains dans la boucle lors de décisions lourdes de conséquences. Ces usages permettent de bâtir des outils internes de synthèse documentaire, des agents qui coordonnent le travail entre systèmes et des applications clientes qui évaluent plusieurs entrées. La présence d'un modèle OpenAI sur la plateforme d'AWS illustre la concurrence entre fournisseurs de modèles et de cloud, où le rapport qualité-coût des agents devient un critère central. Les chiffres de performance cités proviennent d'OpenAI et n'ont pas été vérifiés de façon indépendante.

Création d'une plateforme d'analyse de contrats par IA avec Amazon Quick et Amazon Bedrock AgentCore

Un directeur des contrats qui gère des centaines de contrats fournisseurs perd un temps considérable à extraire à la main des données enfermées dans des PDF : valeurs, dates d'expiration, statut de signature, contacts. AWS décrit l'architecture d'une plateforme d'intelligence contractuelle qui automatise ce travail avec Amazon Quick et Amazon Bedrock AgentCore. Des agents d'IA extraient les champs clés, une approche multi-modèles en vérifie l'exactitude, puis les résultats alimentent des tableaux de bord intégrés et un moteur de requêtes en langage naturel, le tout depuis une seule application web. L'exemple retenu est un portefeuille de 250 contrats de 10 à 20 pages, soit jusqu'à 5 000 pages. Les analystes y répondent à quatre questions récurrentes : la valeur totale du portefeuille, les contrats déjà expirés, l'accord le plus coûteux et le contrat signé le plus récemment. Faute d'outil adapté, ils ouvrent chaque PDF et recopient les valeurs dans un tableur, ce qui représente plus d'une semaine de travail avant même l'arrivée d'un nouveau contrat. L'enjeu dépasse le gain de temps, car les outils de chat IA du marché échouent précisément sur ce type de question. Ils reposent sur la génération augmentée par récupération (RAG), qui découpe les documents en fragments, les indexe sous forme de vecteurs et ne renvoie au modèle que les k fragments les plus proches de la question. Cette méthode fonctionne très bien pour une recherche ciblée, comme les conditions de paiement d'un contrat précis. Mais pour une question d'agrégation, par exemple la valeur totale des 250 contrats, le système ne totalise que les fragments récupérés. Le portefeuille n'est jamais placé en entier devant le modèle. La réponse arrive donc vite, avec assurance, et elle est fausse. Selon AWS, il ne s'agit pas d'un défaut d'un produit en particulier mais d'une limite structurelle du RAG, qu'aucune amélioration de la formulation des requêtes ne corrigera. La solution proposée consiste à changer d'architecture plutôt que d'améliorer la récupération : l'IA convertit les documents non structurés en données structurées à grande échelle, puis une base de données et des outils d'analyse font les calculs, ce pour quoi ils sont conçus. Les contrats d'origine restent disponibles dans une base de connaissances pour les questions portant sur un seul document, où le RAG garde toute sa pertinence. Cette répartition des rôles reflète une tendance plus large en entreprise, où l'on cesse de demander à un modèle de langage de tout faire pour l'associer à des systèmes déterministes. Le recours à plusieurs modèles pour vérifier les extractions répond à une préoccupation centrale dans les domaines juridique et financier, où une valeur mal lue peut fausser une décision. En proposant cette architecture de référence sur ses services Bedrock et Quick, AWS cherche aussi à positionner ses agents et son offre d'analyse décisionnelle sur un cas d'usage très concret pour les directions juridiques et achats.

💬 Le RAG ne sait pas additionner, et c'est la vraie leçon de cet article : demander la valeur totale de 250 contrats à un chat qui ne voit que quelques fragments, ça donne une réponse rapide, assurée et fausse. AWS a raison de sortir de là, l'IA transforme les PDF en données structurées, et un vrai calcul fait le reste. Bon, c'est aussi une vitrine Bedrock et Quick, mais le principe vaut pour n'importe quelle stack. Reste à voir si la vérification multi-modèles tient sur des contrats mal scannés.

Grok 4.7 est désormais disponible sur Amazon Bedrock

xAI vient de rendre Grok 4.7 disponible sur Amazon Bedrock, le catalogue de modèles d'Amazon Web Services. Ce modèle, présenté par xAI comme son plus performant pour le code et le travail de connaissance, offre une fenêtre de contexte de 500 000 tokens et un niveau de raisonnement réglable sur quatre paliers : low, medium, high et xhigh. Il est servi sur le point d'accès bedrock-runtime via des profils d'inférence inter-régions et prend en charge les API Responses, Chat Completions et Converse. Selon xAI, dont l'annonce date du 21 septembre 2026, le modèle repose sur une base plus grande et sur un entraînement par renforcement plus long, pondéré vers des problèmes qui demandent de nombreuses heures de travail. Il travaille plus longtemps sur les tâches difficiles et vérifie davantage ses propres résultats avant de poursuivre. xAI met aussi en avant de meilleures capacités de génération de documents et de présentations, ainsi que des progrès sur des métiers comme juriste, infirmier ou analyste financier. Les évaluations indépendantes d'Artificial Analysis confirment une progression par rapport à Grok 4.6. L'indice d'intelligence passe de 44 à 46 et l'indice des agents de code de 47 à 56. Sur le travail de connaissance de longue durée (AA-Briefcase), le score Elo monte de 1 546 à 1 657, et sur les livrables professionnels (GDPval-AA) de 1 605 à 1 695. Le taux d'hallucination recule de 34 % à 29 %. Ces gains ont un coût : le modèle, mesuré au niveau xhigh, produit environ 81 000 tokens de sortie par tâche de l'indice, contre 38 000 environ pour son prédécesseur, soit à peu près le double. Pour les équipes qui développent des agents, la vérification de ses propres sorties est le point le plus utile, car sur de longues séquences, une erreur précoce se répercute sur toutes les étapes suivantes. Il faut donc choisir délibérément le niveau de raisonnement plutôt que de garder la valeur par défaut, afin de maîtriser la consommation de tokens. Cette arrivée s'inscrit dans la course des fournisseurs de cloud à proposer les modèles de pointe de plusieurs laboratoires au sein d'une même plateforme, ce qui évite aux entreprises de multiplier les contrats et les intégrations. xAI met en avant des résultats sur des bancs d'essai variés : CursorBench et DeepSWE pour le génie logiciel, Terminal-Bench pour le travail en terminal, EEBench pour l'ingénierie électrique, le Harvey Legal Agent Benchmark pour le droit et HealthBench Professional pour le raisonnement clinique. L'entreprise affirme aussi avoir doté ce modèle d'une pile de sécurité entièrement nouvelle et le présente comme le plus solide qu'elle ait testé en matière de refus et de résistance aux tentatives de contournement. Le modèle a par ailleurs été entraîné à comprendre nativement l'environnement Grok Bot, ce qui, selon xAI, améliore les tâches conversationnelles et le travail de connaissance général.

💬 Deux fois plus de tokens de sortie pour deux points d'indice d'intelligence (44 à 46), voilà le vrai prix de Grok 4.7. Le gain qui compte est ailleurs : les agents de code passent de 47 à 56 et l'hallucination recule à 29 %, donc le modèle se relit avant d'avancer, ce qui évite qu'une erreur précoce contamine tout le run. Selon Le Fil IA, la nouvelle course au modèle ne se joue plus sur l'intelligence brute mais sur le coût par tâche réussie, et le niveau de raisonnement devient un réglage de facture autant que de qualité. Bon, sur le papier c'est solide, reste à voir ce que ça donne en prod quand tu laisses xhigh tourner toute la nuit.

Claude Sonnet 5.5 est disponible sur AWS

Claude Sonnet 5.5 est désormais disponible sur Amazon Bedrock et sur Claude Platform on AWS. Présenté comme un modèle Sonnet plus intelligent et plus efficace, il vise le codage ciblé et le travail de connaissance, avec un coût par tâche réduit pour la majorité des usages et une vitesse accrue. Sur Bedrock, les données restent dans l'infrastructure AWS avec une résidence régionale, et le modèle s'intègre aux contrôles déjà en place : AWS IAM pour les accès, CloudTrail pour l'audit, CloudWatch pour la supervision et Bedrock Guardrails. La consommation apparaît sur la facture AWS. Les progrès concernent surtout les tâches bien délimitées : qu'on lui confie une fonctionnalité ou un correctif, Sonnet 5.5 mène le travail à terme et vérifie le résultat par rapport aux exigences énoncées. Il produit aussi des documents et visuels plus soignés que Sonnet 5, comme des fiches d'une page, des schémas d'architecture ou des diapositives de synthèse. Ces qualités le destinent aux charges de travail continues ou à grande échelle. Côté ingénierie, il est cité pour la première réponse aux alertes, la surveillance permanente d'agents, la génération de SQL, les tests d'interface et d'expérience utilisateur, ou encore des agents de codage rapides dans l'éditeur avec un plafond de dépenses fixe. En entreprise, il convient à des analyses circonscrites, à de courtes modifications de tableurs et à des tâches documentaires courantes pour de larges populations d'utilisateurs. L'intérêt tient à la répartition des rôles avec Opus 5.5, annoncé récemment : Opus prend les décisions qui exigent du jugement (débogage de versions, empilements de pull requests, revue de sécurité de grosses modifications, migrations de code, analyses longues débouchant sur un tableur, une présentation ou un rapport, recherche financière, révision de contrats), tandis que Sonnet exécute rapidement les tâches dont l'approche est déjà claire, à moindre coût que son grand frère. Pour l'essayer, il suffit d'ouvrir la console Amazon Bedrock, d'aller dans Test puis Playground et de sélectionner Sonnet 5.5. L'accès programmatique passe par l'API Messages d'Anthropic via le SDK Anthropic sur bedrock-runtime, ou par les API Invoke et Converse avec l'AWS CLI et les SDK AWS. Il faut un compte AWS actif avec accès à Bedrock, l'AWS CLI configurée, Python 3.10 ou supérieur, Boto3 et les permissions IAM bedrock:InvokeModel et bedrock:InvokeModelWithResponseStream. L'exemple fourni appelle l'identifiant global.anthropic.claude-sonnet-5-5 depuis la région us-east-1 pour générer une fonction Python de « slugification » de texte. Cette arrivée s'inscrit dans la stratégie d'AWS et d'Anthropic de proposer des modèles complémentaires au sein d'un même environnement de gouvernance, afin que les entreprises combinent puissance de raisonnement et maîtrise des coûts sans quitter leur cloud.

Claude Opus 5.5 est disponible sur AWS

Anthropic a annoncé la disponibilité de Claude Opus 5.5 sur Amazon Bedrock et sur Claude Platform on AWS, marquant le premier lancement de la famille de modèles Claude 5.5. Ce modèle est présenté comme le plus capable de la gamme Opus, conçu pour le codage agentique, le travail de connaissance et les tâches longues et complexes. Selon Anthropic, Opus 5.5 accomplit davantage avec moins de tokens que son prédécesseur Opus 5, une amélioration d'efficacité renforcée par une nouvelle tarification : prix par token réduits et lecture du cache nettement moins chère, ce qui se traduit par un coût moyen par tâche inférieur. Le modèle intègre également un raisonnement adaptatif activé en permanence, Opus 5.5 déterminant lui-même le niveau de réflexion nécessaire selon la tâche, remplaçant ainsi la gestion manuelle des budgets de réflexion par un simple curseur d'effort. Pour y accéder, les développeurs peuvent utiliser la console Amazon Bedrock via l'onglet Test puis Playground, ou l'appeler par programmation grâce à l'API Anthropic Messages sur bedrock-runtime et bedrock-mantle, ou encore via les API Invoke et Converse à travers l'AWS CLI et le SDK AWS, l'identifiant du modèle étant global.anthropic.claude-opus-5-5. Cette annonce compte pour les entreprises qui déploient des agents IA à grande échelle sur l'infrastructure AWS, un marché où le coût par tâche et la fiabilité des sessions longues pèsent directement sur la rentabilité des déploiements. En développement logiciel, Opus 5.5 améliore la communication du modèle pendant son exécution : il indique plus clairement ce qu'il a fait, ce qu'il a trouvé et ce dont il a besoin, ce qui facilite le suivi, la vérification et la confiance dans des sessions de travail prolongées. Pour les tâches de rédaction et d'analyse de documents longs, Anthropic indique que le modèle nécessite moins de corrections que Opus 5. La baisse des prix combinée aux gains d'efficacité permet aux équipes de faire tourner des workflows agentiques plus ambitieux sans voir leurs coûts d'infrastructure exploser, un enjeu central alors que les entreprises cherchent à industrialiser l'usage d'agents autonomes plutôt que de simples chatbots. Sur le plan de la sécurité, Claude Opus 5.5 est le premier modèle Opus doté de classificateurs de sécurité similaires à ceux déjà déployés sur Claude Fable 5.1, portant sur la biologie, la cybersécurité et le développement de l'IA. Concrètement, le modèle refusera davantage de requêtes sensibles que les versions Opus précédentes, une évolution qui s'inscrit dans la stratégie plus large d'Anthropic de renforcer les garde-fous à mesure que ses modèles gagnent en capacité agentique. Ce lancement s'ajoute à la disponibilité croissante des modèles Claude chez les grands fournisseurs cloud, Amazon Bedrock jouant un rôle clé dans la distribution d'Anthropic auprès des entreprises déjà installées sur AWS, aux côtés d'Amazon dont l'investissement dans Anthropic reste stratégique pour les deux groupes.

ADP et AWS s’allient pour sécuriser l’IA générative RH à grande échelle

ADP, l'un des plus grands fournisseurs mondiaux de solutions de paie et de gestion des ressources humaines, a annoncé le 8 septembre 2026 avoir choisi Amazon Web Services (AWS) comme fournisseur cloud stratégique pour accélérer le déploiement de son intelligence artificielle générative RH, baptisée ADP Assist. L'entreprise gère la paie de plus de 42 millions de salariés répartis chez 1,1 million de clients dans 140 pays, et migre désormais ses systèmes de gestion du capital humain vers l'infrastructure d'AWS, notamment via Amazon Bedrock. Pour éviter tout risque de fuite de données sensibles (salaires, numéros d'identification fiscale, évaluations de performance), ADP fait transiter ses flux par des connexions séparées de type Virtual Private Cloud et AWS PrivateLink, empêchant les informations de circuler sur l'internet ouvert. La migration des milliers d'applications de paie s'appuie sur des outils spécialisés, AWS Transform et AWS Kiro, et ADP promet une accélération de 50 % de certaines étapes de configuration pour les nouveaux clients de sa plateforme Lyric HCM. Cette alliance illustre le défi central que pose l'IA générative dans les ressources humaines : traiter des données personnelles à très grande échelle sans les exposer à des modèles de langage entraînés sur des données publiques. En s'appuyant sur Amazon Bedrock, dont la documentation garantit que les requêtes des utilisateurs ne servent jamais à entraîner les algorithmes d'Amazon ou d'Anthropic, ADP cherche à rassurer les directions des systèmes d'information et des ressources humaines sur la confidentialité des dossiers salariés. Concrètement, des agents intelligents peuvent désormais identifier en quelques secondes des erreurs de cotisations, ce qui représente un gain de temps opérationnel notable pour les gestionnaires de paie. Mais l'enjeu dépasse la simple efficacité : la moindre faille dans le cloisonnement des accès pourrait provoquer des fuites de données entre entreprises clientes concurrentes, ce qui rend l'étanchéité de l'architecture déterminante pour l'adoption réelle de ces outils dans le secteur privé. Ce déploiement s'inscrit aussi dans un contexte réglementaire tendu en Europe, où l'AI Act classe les systèmes d'IA utilisés pour le recrutement et le suivi des salariés comme des outils à haut risque, imposant des contrôles de biais systématiques et une explicabilité des décisions algorithmiques. Le choix d'un hébergeur américain ravive par ailleurs les débats sur le Cloud Act, qui permet aux autorités judiciaires des États-Unis de réclamer l'accès à des données hébergées par une entreprise américaine, même si les serveurs se trouvent en Europe. La viabilité à long terme de ce partenariat entre ADP et AWS dépendra donc autant de sa capacité technique à protéger les données que de sa conformité aux exigences européennes de souveraineté numérique.

💬 Le VPC et PrivateLink, c'est du sérieux, pas du marketing de conformité. Mais ça règle le problème technique, pas le problème légal : tant que les serveurs restent chez un hébergeur américain, le Cloud Act s'applique, promesse Bedrock ou pas. Selon Le Fil IA, la vraie bataille de l'IA RH en Europe ne se joue pas sur le chiffrement des flux, elle se joue sur la souveraineté des données, et ADP n'y répond pas.

Au-delà du prix par token : bien choisir son modèle OpenAI sur Amazon Bedrock selon son usage

Amazon Web Services a publié les résultats d'un banc d'essai comparant cinq modèles d'OpenAI utilisés en production, dans un article technique sur son blog IA. Trois modèles sont disponibles via Amazon Bedrock, la plateforme d'IA générative d'AWS : gpt-5.6-sol, gpt-5.6-terra et gpt-5.6-luna. Ils sont confrontés à deux modèles économiques accessibles directement via l'API d'OpenAI, gpt-5.4-mini et gpt-5.4-nano, choisis comme référence car ce sont les modèles que beaucoup d'équipes utilisent déjà par défaut pour réduire leurs coûts. Les tests reposent sur un outil open source, baptisé benchmarks-openai, qui interroge les cinq modèles via une interface identique, l'API Responses d'OpenAI, sur trois types d'épreuves : des problèmes de mathématiques de compétition (AIME), des questions scientifiques de niveau doctorat (GPQA Diamond), un test de connaissances générales multidisciplinaire (MMLU-Pro), ainsi que des tâches de recherche web en plusieurs étapes et des livrables professionnels notés par un autre modèle, gpt-5.5, servant de juge. Sur un échantillon de 48 à 198 questions selon les épreuves, gpt-5.6-sol résout 75 % des problèmes AIME contre 37 % pour gpt-5.4-mini, obtient 68 % sur GPQA Diamond contre 43 %, et 82 % sur MMLU-Pro contre 59 %. L'enjeu de cette étude dépasse le simple classement de performances : elle remet en cause la façon dont les entreprises choisissent leurs modèles d'IA, généralement en comparant le prix par million de jetons affiché sur les grilles tarifaires. Or un modèle moins cher au jeton peut se révéler plus coûteux à l'usage s'il se trompe plus souvent et nécessite des relances, ou si, dans un agent conversationnel, chaque nouveau tour de dialogue réexpédie tout l'historique grandissant de la conversation, ce qui fait gonfler la facture réelle. AWS propose donc de raisonner en coût par réponse correcte plutôt qu'en coût par jeton, une distinction concrète pour toute organisation qui déploie des agents IA en production, que ce soit pour du support client, de la recherche ou de l'analyse financière. Cette publication s'inscrit dans la bataille commerciale que se livrent AWS et OpenAI pour convaincre les entreprises d'exécuter leurs modèles via Bedrock plutôt que via l'API directe d'OpenAI. AWS précise toutefois une limite méthodologique importante : les modèles testés sur Bedrock tournaient avec le raisonnement désactivé, tandis que les modèles de référence sur l'API OpenAI utilisaient leurs réglages par défaut, ce qui en fait une comparaison de configurations de déploiement pratiques plutôt qu'une mesure neutre des capacités intrinsèques des modèles. Le code du banc d'essai étant public, AWS invite les entreprises à reproduire elles-mêmes ces tests sur leurs propres cas d'usage avant de trancher.

💬 Le prix par jeton, c'est un peu comme comparer des voitures au prix du litre d'essence sans regarder la consommation. Si un modèle se trompe une fois sur deux et qu'il faut relancer, ou si l'historique de conversation gonfle à chaque tour, la note finale explose, peu importe le tarif affiché. Reste que l'étude vient d'AWS qui vend justement Bedrock face à l'API OpenAI directe, donc je regarderais les chiffres avec un métronome à la main plutôt que les yeux fermés.

Réalisez vos projets les plus ambitieux avec GPT-6 Astra sur Amazon Bedrock

OpenAI a annoncé la disponibilité générale de son modèle GPT-6 Astra sur Amazon Bedrock, le moteur d'inférence cloud d'AWS conçu pour la performance, la sécurité et le passage à l'échelle en production. Présenté comme le modèle le plus capable d'OpenAI à ce jour, GPT-6 Astra peut être appelé directement via les API d'Amazon Bedrock ou configuré pour fonctionner avec ChatGPT Work et Codex. Il dispose d'une fenêtre de contexte pouvant atteindre 1 million de tokens en entrée, ce qui lui permet par exemple d'analyser plusieurs centaines de pages de contrats en une seule requête. OpenAI lance en parallèle de nouveaux plugins d'entreprise pour ChatGPT Work, qui étendent les capacités de navigation web du modèle à des applications professionnelles courantes. Le modèle a été évalué selon le Preparedness Framework d'OpenAI, un dispositif qui mesure les capacités sensibles pour la sécurité et renforce progressivement les garde-fous en conséquence ; il devient ainsi le premier modèle d'OpenAI à atteindre la classification "Critical" pour ses capacités en cybersécurité, ce qui déclenche une surveillance automatisée en temps réel capable de suspendre toute activité jugée excessive. Cette disponibilité sur Bedrock cible directement les entreprises qui font déjà tourner des agents IA en production pour écrire du code, analyser des données ou automatiser des workflows complexes. GPT-6 Astra promet un raisonnement plus profond pour des tâches à fort enjeu : réconcilier des sources financières contradictoires, repérer les clauses contractuelles les plus risquées dans un document volumineux, ou diagnostiquer un bug à travers les dépendances d'une base de code entière jusqu'à la correction testée. L'enjeu pour les entreprises est aussi la gouvernance : Amazon Bedrock chiffre les données en transit et au repos, interdit tout accès des opérateurs AWS aux invites et réponses au niveau matériel, journalise chaque appel dans AWS CloudTrail et permet de router le trafic via des endpoints VPC privés. Surtout, les données d'inférence ne sont jamais utilisées pour l'entraînement du modèle, un argument central pour convaincre les directions juridiques et sécurité d'adopter l'IA générative à grande échelle. Ce lancement s'inscrit dans le resserrement des liens entre OpenAI et Amazon Web Services, qui cherche à rivaliser avec l'offre Azure de Microsoft et avec Google Cloud sur le marché de l'IA d'entreprise. Pour réduire les coûts et la latence des usages répétitifs, comme la relecture récurrente de documents ou l'analyse continue d'un même code, GPT-6 Astra prend en charge la mise en cache de contexte, implicite ou explicite via des points de rupture définis par l'utilisateur. La classification "Critical" en cybersécurité illustre par ailleurs la trajectoire des modèles les plus avancés, dont les capacités croissantes imposent des mécanismes de contrôle renforcés, un débat appelé à s'intensifier à mesure que ces systèmes gagnent en autonomie sur des tâches sensibles.

💬 GPT-6 Astra qui décroche direct la classification "Critical" en cybersécurité, avec surveillance temps réel capable de couper le modèle, ça vaut plus que la fenêtre de contexte à 1 million de tokens dont tout le monde va parler. C'est la première fois qu'OpenAI colle ce niveau d'alerte à un modèle en disponibilité générale, pas juste en interne. Et ça dit un truc simple : plus les modèles deviennent utiles en entreprise, plus les garde-fous qu'on leur colle dessus vont peser dans le choix d'y aller ou pas.

IPO d’Anthropic : que va révéler son prospectus sur les vrais coûts de l’IA générative ?

Anthropic prévoit de publier son dossier d'introduction en bourse (formulaire S-1) juste après la fête du Travail américaine, avec une cotation envisagée fin septembre ou début octobre 2026, selon des informations relayées par Reuters et confirmées par plusieurs sources financières dont le compte Wall St Engine le 27 août 2026. L'entreprise, connue pour sa gamme de modèles Claude, a vu sa valorisation grimper à 965 milliards de dollars lors de sa récente levée de série H, portant le total des fonds réunis à plus de 130 milliards de dollars destinés à financer ses infrastructures de calcul. D'après les estimations de la plateforme d'analyse Sacra, Anthropic afficherait un chiffre d'affaires annuel récurrent d'environ 65 milliards de dollars, dont près de 80 % proviendraient de contrats B2B passés via les plateformes cloud d'Amazon Web Services et de Google Cloud Platform. La société envisagerait aussi de permettre à ses actionnaires historiques de céder des titres dès l'introduction, tout en imposant des périodes de blocage plus longues que la normale pour les nouveaux investisseurs. Cette opération financière revêt une importance particulière car elle va forcer, pour la première fois, la divulgation détaillée de la structure de coûts réelle d'un géant de l'intelligence artificielle générative. Les dirigeants informatiques et les investisseurs pourront enfin vérifier si le coût de traitement des requêtes diminue réellement avec l'augmentation des volumes, ou si les remises accordées par les fournisseurs de cloud masquent une consommation de calcul insoutenable à long terme. Le résultat déterminera si les marges brutes de l'IA générative peuvent un jour s'approcher de celles du logiciel SaaS traditionnel, ou si le développement de modèles toujours plus puissants continuera d'absorber l'essentiel de la trésorerie. Les entreprises clientes s'attendent à des répercussions directes sur la tarification des API, facturées au nombre de jetons consommés, avec un risque d'ajustements tarifaires si les marges se révèlent trop étroites. Cette échéance boursière intervient dans un contexte de doutes croissants sur la soutenabilité économique du secteur de l'IA, marqué par des dépenses d'infrastructure colossales face à des revenus encore concentrés sur un nombre restreint de grands partenaires cloud. Anthropic conserve par ailleurs son statut de Public Benefit Corporation, une structure juridique censée concilier rentabilité et engagements de sécurité, dont la compatibilité avec les exigences de rendement des marchés financiers reste à démontrer. Cette IPO, l'une des plus attendues de l'année, devrait ainsi servir de référence pour évaluer d'autres acteurs du secteur, dans un climat où certains observateurs évoquent déjà les contours d'une bulle spéculative autour de l'intelligence artificielle.

💬 L'IPO va enfin nous montrer ce que ça coûte vraiment de servir un modèle à des millions de requêtes, et je parie que c'est moins joli que les 80% de revenu B2B ne le laissent croire. Selon Le Fil IA, l'IPO d'Anthropic sera le premier test public de la thèse "l'IA générative peut avoir des marges SaaS", et si ce n'est pas le cas, c'est toute la tarification par jeton qui doit être repensée, chez Anthropic comme ailleurs. Reste à voir si le S-1 dit la vérité sur les remises cloud ou s'il les planque bien dans les petites lignes.

AWS et NVIDIA dopent le Big Data : une nouvelle ère de performance pour vos pipelines IA

Amazon Web Services et NVIDIA ont annoncé le 26 août 2026 une extension majeure de leur collaboration stratégique, avec le déploiement de deux millions de GPU NVIDIA supplémentaires sur l'infrastructure mondiale d'AWS d'ici 2028, dans la continuité de seize années de coopération entre les deux groupes. Au delà de la puissance brute destinée à l'entraînement des modèles, l'annonce porte surtout sur l'intégration native des bibliothèques logicielles NVIDIA cuDF et cuVS au sein d'Amazon EMR et d'Amazon OpenSearch. Sur les nouvelles instances EC2 G7, les traitements ETL sous Apache Spark s'exécutent jusqu'à 3,7 fois plus vite qu'avec des configurations CPU classiques, pour un coût de calcul réduit de 30 %, sans qu'il soit nécessaire de modifier une seule ligne de code Spark existant. Côté bases de données vectorielles, la suite cuVS permet de délester la construction des index sur des GPU dédiés au sein d'Amazon OpenSearch, portant la vitesse d'indexation jusqu'à neuf fois supérieure pour un quart du coût initial. Ces capacités sont accessibles via OpenSearch Serverless ainsi que via les clusters Amazon EMR et EKS. Cette évolution cible un maillon souvent négligé des projets d'intelligence artificielle : la préparation et l'indexation des données en amont, plutôt que le seul entraînement des grands modèles de langage. Pour les entreprises qui déploient des architectures RAG ou des applications agentiques, la gestion de milliards de vecteurs et les cycles de rafraîchissement des données constituent un goulot d'étranglement opérationnel et financier majeur. En réduisant drastiquement les temps de traitement, AWS et NVIDIA permettent de remplacer des cycles d'indexation nocturnes, qui pouvaient durer plusieurs jours, par des flux de données mis à jour en continu. Pour les directions informatiques, cela change la logique de calcul du coût total de possession : même si le tarif horaire d'une instance GPU dépasse celui d'un serveur CPU classique, la baisse du temps d'exécution rend la facture par traitement plus faible et plus prévisible. Cette annonce s'inscrit dans une course plus large à l'infrastructure IA, où AWS, Microsoft Azure et Google Cloud investissent massivement dans les capacités GPU pour répondre à l'explosion des volumes de données générés par l'IA générative et les agents autonomes. En misant sur une accélération matérielle transparente, qui ne requiert aucune refonte applicative, AWS et NVIDIA cherchent à lever un frein concret à l'adoption de pipelines IA à grande échelle. La montée en puissance annoncée jusqu'en 2028 laisse présager de nouvelles intégrations logicielles similaires sur d'autres services AWS dans les mois à venir.

💬 Deux millions de GPU d'ici 2028, on retient le chiffre, mais le vrai move est ailleurs : cuDF et cuVS intégrés nativement dans EMR et OpenSearch, sans toucher au code Spark existant. C'est ça le signal à suivre, pas l'entraînement des LLM : l'indexation vectorielle passe de la nuit entière à du continu, et ça déplace le vrai goulot d'étranglement des architectures RAG, qui n'a jamais été le modèle mais la donnée en amont. Reste à voir si le 3,7x annoncé tient sur des pipelines Spark bien crades en prod, parce que les benchmarks constructeur adorent les cas propres.

Amazon Bedrock AgentCore Payments est disponible en version generale : des agents peuvent transiger de facon sure et autonome, a grande echelle

Amazon a annoncé la disponibilité générale (GA) d'AgentCore payments, un service permettant aux agents IA de payer de façon autonome pour des API, des serveurs MCP ou du contenu, développé en collaboration avec Coinbase et Stripe. Le service était en préversion depuis mai 2026 et passe désormais en production pour les entreprises. AgentCore payments s'appuie sur des portefeuilles en stablecoins fournis par Coinbase et par Privy (Stripe), conçus pour des micropaiements de quelques centimes. Les utilisateurs finaux alimentent le portefeuille de leur agent par carte bancaire ou en USDC, puis délèguent à l'agent le droit de dépenser en leur nom. Les identifiants développeurs sont stockés dans l'AgentCore Identity Secrets Manager et l'agent ne voit jamais les identifiants bruts, seulement des jetons à durée de vie limitée. Pour la GA, Amazon ajoute une option "Quick Create" pour provisionner des identifiants Coinbase directement depuis la console ou la CLI, ainsi qu'une prise en charge du protocole Machine Payment Protocol (MPP), coécrit par Stripe et Tempo, en complément du protocole x402 déjà supporté depuis la préversion. Une nouvelle option "upto" au sein d'x402 permet aussi de fixer un plafond de dépense plutôt qu'un prix fixe, autorisant une facturation à l'usage réel. Cette évolution répond à un problème concret : les agents IA autonomes savent désormais raisonner, choisir des outils et enchaîner des tâches sans supervision humaine, mais butent dès qu'un paiement est nécessaire, faute de moyen sécurisé de transiger seuls. En parallèle, les fournisseurs de services et de contenus délaissent progressivement les abonnements forfaitaires au profit de modèles à l'usage, facturés à l'exécution, parfois pour quelques centimes seulement. AgentCore payments comble ce vide en donnant aux agents un véritable moyen de paiement sécurisé, avec garde-fous et traçabilité, ce qui ouvre la voie à une économie de la micro-transaction machine-à-machine : paiement à l'inférence, au calcul consommé ou à l'appel d'API, sans négociation humaine préalable. Ce lancement s'inscrit dans la montée en puissance des architectures agentiques chez les grands fournisseurs cloud, où Amazon cherche à consolider AgentCore comme plateforme de référence pour déployer des agents en production. La fonctionnalité de "session de paiement", qui encadre chaque transaction dans un contexte limité à une interaction précise, vise à limiter les risques inhérents à la nature non déterministe des agents, qui peuvent mal interpréter une réponse ou déclencher des paiements redondants lors de tentatives répétées. L'intégration de standards ouverts comme x402 et MPP, ainsi que l'amélioration de la découvrabilité des points de terminaison payants via le Gateway MCP d'AgentCore, suggère qu'Amazon mise sur l'interopérabilité pour s'imposer comme infrastructure de paiement de référence dans cet écosystème naissant, aux côtés de Coinbase, Stripe et Tempo.

💬 Ce qui bloquait vraiment les agents autonomes, c'était pas le raisonnement, c'était le portefeuille : impossible de payer une API ou un serveur MCP sans un humain qui valide la carte bleue. Amazon règle ça avec des stablecoins, des sessions de paiement bornées et des protocoles ouverts comme x402, et ça pousse tout le secteur du forfait vers la facturation à l'appel, au centime près. Reste à voir si les boîtes vont vraiment laisser un agent dépenser seul en prod, garde-fous ou pas, ou si ça va rester un joli cas d'usage de conférence pendant encore un moment.

Accélération de la cyberdéfense avec OpenAI et AWS : Daybreak Red et Daybreak Blue disponibles sur Amazon Bedrock

AWS et OpenAI ont annoncé la disponibilité de Daybreak Red et Daybreak Blue, deux modèles d'intelligence artificielle spécialisés en cybersécurité, sur la plateforme Amazon Bedrock pour les clients éligibles. Daybreak Red donne accès à GPT-5.6 Cyber, un modèle entraîné spécifiquement pour les tâches de sécurité informatique, tandis que Daybreak Blue s'appuie sur GPT-5.6 Sol, doté de garde-fous calibrés pour un usage défensif. Ces deux outils font partie de Daybreak, l'initiative de cyberdéfense d'OpenAI qui donne aux équipes de sécurité un accès encadré à ses modèles les plus avancés, incluant des agents autonomes, des services de red teaming applicatif et des outils permettant de passer de la détection d'une faille à un correctif testé. John Sheehan, vice-président de la sécurité chez AWS, a précisé que les équipes de sécurité d'AWS utilisent déjà les deux modèles pour analyser du code source, découvrir des vulnérabilités et mener des recherches offensives, le tout sous les mêmes contrôles d'infrastructure appliqués à toute charge de travail critique sur Bedrock. Preuve concrète de leur efficacité, selon OpenAI, des chercheurs ont utilisé GPT-5.6 Cyber via Daybreak Red pour identifier deux vulnérabilités jusqu'alors inconnues dans V8, le moteur JavaScript de Chrome, dont l'enchaînement pouvait provoquer une corruption mémoire et une évasion du bac à sable. La faille initiale a été corrigée et référencée sous CVE-2026-15903, l'une des quatre seules entrées réussies au concours V8 CTF en 2026. Cette annonce répond à une urgence bien réelle du secteur : la fenêtre entre la découverte d'une vulnérabilité et son exploitation par des attaquants ne cesse de se réduire, alors que les modèles d'IA les plus puissants sont accessibles autant aux défenseurs qu'aux assaillants. Pour les équipes de sécurité, l'enjeu n'est plus de repérer des failles potentielles mais de confirmer rapidement lesquelles sont réellement exploitables, de les corriger sans introduire de régression, puis de déployer le correctif avant que la fenêtre ne se referme, tout en gardant le code sensible dans un environnement qu'elles maîtrisent et peuvent auditer. En intégrant ces modèles à Bedrock, AWS permet à ses clients de bénéficier de capacités d'analyse comparables à celles des attaquants les plus sophistiqués, sans exposer leurs données à des infrastructures tierces non contrôlées. Le défi central de ces outils tient à la nature intrinsèquement double usage de la cybersécurité : une demande de reproduction d'une vulnérabilité ou de rétro-ingénierie d'une chaîne d'exploitation semble identique, que l'intention soit défensive ou malveillante, ce qui pousse généralement les modèles génériques à refuser la requête. Daybreak Red et Daybreak Blue lèvent cette ambiguïté grâce au contexte d'usage, à l'identité vérifiée de l'utilisateur et aux garde-fous propres à l'environnement Bedrock. Daybreak Blue reste le point d'entrée recommandé pour la majorité des équipes, couvrant la découverte de vulnérabilités, l'ingénierie de détection et la réponse aux incidents, tandis que Daybreak Red s'adresse aux tâches les plus avancées comme la recherche de vulnérabilités et le développement de mesures d'atténuation, avec un seuil de refus abaissé compensé par des contrôles d'accès renforcés.

💬 Daybreak, c'est la démonstration que les modèles offensifs et défensifs, c'est le même modèle avec des garde-fous différents, pas deux technos séparées. Deux failles V8 trouvées et une CVE en poche, ça prouve que l'outil marche, mais faut voir ce que ça donne entre les mains d'une équipe sécu moyenne, pas juste chez les chercheurs qui l'ont conçu. Et le vrai enjeu, c'est pas la détection, on sait déjà en trouver, c'est de patcher plus vite que l'attaquant en face qui a accès au même GPT-5.6.

Novo Nordisk et AWS intègrent l'IA à base d'agents dans la découverte de médicaments

Novo Nordisk a annoncé un accord élargi avec Amazon Web Services (AWS) pour intégrer l'intelligence artificielle agentique dans ses processus de découverte de médicaments, notamment pour l'identification de cibles thérapeutiques, la conception de traitements et les flux de recherche. Dans le cadre de cet accord, AWS devient le fournisseur cloud privilégié et le partenaire stratégique IA du laboratoire pharmaceutique danois. Les deux entreprises ont créé un hub de co-innovation au sein du site londonien déjà existant de Novo Nordisk, où des ingénieurs AWS travailleront directement avec les données et les résultats de recherche des scientifiques de l'entreprise, aux côtés de spécialistes IA et d'équipes de services professionnels. Thilde Hummel Bøgebjerg, vice-présidente exécutive IT et Qualité chez Novo Nordisk, a souligné que l'impact réel de l'IA vient de la combinaison de la technologie avec l'expertise scientifique et une attention portée aux patients. Novo Nordisk utilise déjà largement les outils AWS : plus de 25 000 employés se servent d'une plateforme d'IA générative bâtie sur Amazon Bedrock, couvrant plus de 2 500 cas d'usage, dont l'un traite une base de 140 000 documents et plus de 26 000 requêtes par mois. Un système basé sur Claude 3.5 d'Anthropic via Bedrock a par ailleurs réduit de plus de 90% le temps de production de certains documents cliniques, un travail auparavant réalisé par 40 à 50 personnes en 15 semaines désormais accompli en quelques minutes par une équipe de trois personnes, sous supervision médicale. Ce nouvel accord vise à réduire les ruptures entre l'analyse computationnelle et la recherche en laboratoire lorsque des candidats médicaments potentiels progressent dans leur développement, dans le but de raccourcir le délai entre l'identification d'une cible thérapeutique et la première administration à l'humain. Concrètement, Novo Nordisk utilisera Amazon Bio Discovery, un service donnant accès à plus de 40 modèles d'IA biologiques, où des agents IA sélectionnent et coordonnent les modèles adaptés à chaque tâche de recherche, en combinant si besoin des modèles hébergés par AWS avec des modèles propriétaires du laboratoire. La plateforme pourra générer et classer des candidats médicaments avant leur synthèse et leurs tests en laboratoire, les résultats expérimentaux étant ensuite réinjectés dans le flux computationnel pour affiner les modèles, un système bouclé reliant conception numérique et validation physique. Cette expansion s'inscrit dans une tendance plus large d'intégration de l'IA agentique dans la recherche pharmaceutique, portée notamment par Amazon Bedrock AgentCore, l'infrastructure d'AWS pour déployer et faire fonctionner des agents IA. Novo Nordisk prévoit aussi d'exploiter Bedrock pour construire des applications capables de croiser données cliniques, génomiques et d'imagerie, afin que les résultats de recherche précoce influencent directement la conception des essais cliniques. Ce partenariat associe l'expertise du laboratoire dans les maladies chroniques à l'infrastructure cloud, aux services d'IA et aux technologies dédiées aux sciences de la vie d'AWS, illustrant la course des géants du cloud à s'imposer comme partenaires technologiques incontournables de l'industrie pharmaceutique.

Se retirer d'une action unique : nouvelles fonctionnalités de contrôle des agents et des coûts dans Amazon Bedrock AgentCore

Amazon a annoncé de nouvelles fonctionnalités pour Bedrock AgentCore, sa plateforme dédiée à la construction et au déploiement d'agents IA en entreprise. La mise à jour introduit les politiques temporelles, propulsées par Dogwood, un nouveau langage de politique open source conçu spécifiquement pour les agents IA, ainsi qu'une limitation de débit au niveau de la passerelle (gateway) d'AgentCore. Cette passerelle sert de point d'entrée managé et serverless pour tout le trafic IA, orientant les requêtes vers les serveurs MCP (Model Context Protocol), les modèles de langage, les agents et les bases de connaissances. Jusqu'ici, les politiques de sécurité d'AgentCore évaluaient chaque action de façon isolée et sans état, vérifiant à chaque appel qui pouvait utiliser quel outil et sous quelles conditions. Les politiques temporelles changent cette logique en examinant l'historique complet des actions menées par un agent au cours d'une session avant d'autoriser ou de refuser un nouvel appel. Amazon s'appuie sur des chiffres de McKinsey, tirés de ses études State of AI Trust in 2026 et Trust in the age of AI agents 2026, selon lesquels environ 80% des organisations ont déjà constaté des comportements à risque de la part de leurs agents IA. Cette évolution répond à un problème concret de sécurité: un agent autonome peut enchaîner des actions parfaitement légitimes prises individuellement mais problématiques une fois mises bout à bout. Amazon cite l'exemple d'un agent consultant le compte d'un client puis virant de l'argent vers un numéro de compte différent, chaque appel étant validé séparément sans qu'aucun contrôle ne vérifie la cohérence de la séquence. Autre cas évoqué: une série de commandes passées sous le seuil d'approbation individuel mais qui, cumulées, dépassent largement le budget alloué, ou encore un agent bloqué sur un outil défaillant qui relance ses requêtes toute la nuit et épuise son quota de tokens. Avec les politiques temporelles, une entreprise peut désormais exiger qu'une valeur transmise dans un appel corresponde à celle retournée par un appel précédent, plafonner les dépenses cumulées d'une session, imposer un ordre strict aux étapes d'un processus, ou encore exiger une approbation humaine enregistrée pour toute action significative. Cette annonce s'inscrit dans un contexte où la sécurité et la confiance sont devenues, selon McKinsey, le principal frein à l'adoption des agents IA en entreprise, davantage que les questions de performance ou de coût. Amazon défend une approche où les contrôles de sécurité sont intégrés directement dans la couche d'infrastructure plutôt que codés différemment par chaque équipe applicative, un principe qui guide la conception d'AgentCore depuis son lancement. En rendant ces garde-fous systématiques et fiables au niveau de la plateforme, l'entreprise cherche à transformer l'approbation d'un nouvel agent en un processus géré à grande échelle plutôt qu'en une négociation ponctuelle, ce qui pourrait accélérer le déploiement d'agents autonomes dans des environnements sensibles comme la finance ou les achats automatisés.

IA d'entreprise sur AWS : au-delà du RAG, la compression de connaissances adaptée à la tâche

Compression de l'information privilégiant les tâches spécifiques, cette technique baptisée TAKC (Task-Aware Knowledge Compression) vient d'être détaillée par AWS pour dépasser les limites du RAG (Retrieval-Augmented Generation) classique sur les tâches analytiques complexes. Le problème identifié concerne les analyses portant sur des centaines de documents, comme un audit de due diligence financière ou une revue de conformité réglementaire, où la recherche par similarité du RAG traditionnel peine à relier des informations disséminées dans des sources sans proximité lexicale. AWS illustre le cas d'un fonds de private equity évaluant une acquisition de 500 millions de dollars dans le secteur manufacturier, avec une équipe devant croiser les états financiers de 12 filiales sur 5 ans, plus de 200 contrats fournisseurs, des rapports de conformité environnementale de 8 sites et plus de 50 dossiers juridiques en cours. TAKC compresse l'intégralité de la base documentaire hors ligne, une fois par document et par type de tâche, en utilisant un LLM pour produire des résumés ciblés qui conservent uniquement les informations pertinentes pour un usage donné, par exemple les chiffres de revenus et de marges pour une analyse financière, ou les citations réglementaires pour un contrôle de conformité. Le système propose quatre niveaux de compression selon la complexité de la requête, allant d'une réduction de 87,5% du contexte pour les tâches de raisonnement multi-étapes jusqu'à 96,9% pour les recherches factuelles simples, avec un facteur de compression global variant de 8x à 64x. L'enjeu principal réside dans la capacité de cette approche à préserver les connexions entre documents que le RAG classique manque systématiquement, puisque la compression analyse les textes ensemble plutôt qu'isolément fragment par fragment. Pour les entreprises manipulant de gros volumes documentaires dans des secteurs réglementés, comme la finance ou le droit, cela change concrètement la donne : un analyste peut interroger le système sur les risques financiers consolidés en tenant compte simultanément des conditions fournisseurs actuelles et des litiges en cours, une question à laquelle le RAG traditionnel ne peut pas répondre faute de récupérer les bons fragments au bon moment. La différenciation par type de tâche évite aussi la dilution d'information propre aux résumés génériques, qui tentent de tout couvrir sans répondre précisément à aucun usage. Un même rapport annuel produit ainsi des versions compressées radicalement différentes selon qu'il sert une analyse financière ou une évaluation des risques juridiques. Cette architecture s'inscrit dans une tendance plus large d'optimisation des systèmes RAG pour les cas d'usage professionnels intensifs, où le simple découpage en chunks similaires atteint ses limites face à la complexité réelle des documents d'entreprise. AWS propose une implémentation open source complète, déployable directement sur ses propres comptes cloud, avec des recommandations pratiques comme le stockage versionné des prompts de compression via AWS Systems Manager Parameter Store ou un préfixe dédié Amazon S3, afin de garantir la traçabilité des modifications et de déclencher une recompression lorsque les prompts évoluent. Un analyseur de complexité des requêtes route automatiquement les questions vers le niveau de compression adapté, redirigeant vers un palier moins compressé si la représentation disponible manque de détail. Cette approche s'adresse en priorité aux organisations traitant des volumes documentaires massifs dans des contextes à fort enjeu réglementaire ou financier, où la précision et la traçabilité des réponses générées par IA deviennent critiques.

💬 Le vrai apport ici, c'est pas la compression, c'est le routage par tâche. Un même rapport annuel donne des résumés différents selon que tu fais de l'analyse financière ou du juridique, ça évite le piège classique du résumé fourre-tout qui répond mal à tout. Reste à voir si ça tient en prod sur des vrais corpus de 500 documents, parce que sur le papier les chiffres de compression sont beaux, mais AWS n'a testé que ses propres cas d'usage.

OpenAI GPT-5.6 Sol, Terra et Luna sont désormais disponibles sur Amazon Bedrock

OpenAI a annoncé la disponibilité générale de sa nouvelle famille de modèles GPT-5.6, baptisée Sol, Terra et Luna, sur Amazon Bedrock, le service d'inférence cloud d'AWS. Cette annonce marque un changement de nomenclature chez OpenAI : le chiffre 5.6 identifie la génération, tandis que les noms Sol, Terra et Luna désignent des niveaux de capacité distincts pouvant évoluer selon leur propre calendrier. Sol, le modèle phare de raisonnement, atteint un score record de 80 points sur l'index Artificial Analysis Coding Agent, soit 2,8 points de plus que le meilleur concurrent, tout en utilisant moins de la moitié des tokens de sortie, un temps d'exécution divisé par deux et un coût inférieur d'environ un tiers. Sur ExploitBench, un test dédié à la recherche en cybersécurité, Sol obtient 73,5%, contre 47,9% pour GPT-5.5 à budget de tokens comparable. Sur Agents' Last Exam, une évaluation portant sur des flux de travail professionnels de longue durée dans 55 domaines, Sol établit un nouveau record de 53,6, devançant son plus proche rival de 13,1 points. Terra, positionné comme le modèle équilibré pour la production quotidienne, surpasse GPT-5.5 à moindre coût, tandis que Luna cible les tâches à fort volume comme la classification ou le routage, où la latence et le coût par token priment. Les tarifs correspondent aux prix directs d'OpenAI et l'usage s'impute sur les engagements AWS existants des clients. Cette mise à disposition répond aux besoins d'entreprises qui déploient des agents autonomes sur des centaines d'étapes consécutives, que ce soit pour générer du code en production, mener des recherches sur des failles de sécurité ou analyser des séquences génétiques complètes. Ces charges de travail traitent souvent des données sensibles et exigent un débit stable même en cas de pics d'usage imprévisibles, dans des environnements où la résidence des données et la sécurité ne souffrent aucun compromis. En proposant trois niveaux de modèles aux performances et coûts différenciés, Amazon Bedrock permet aux équipes techniques d'ajuster précisément la puissance de calcul à chaque tâche, réduisant les dépenses inutiles sur les usages simples tout en réservant la puissance maximale aux problèmes complexes. Le nouveau moteur d'inférence d'Amazon Bedrock a été conçu pour absorber la nature imprévisible du trafic généré par les agents, où une seule requête utilisateur peut déclencher des centaines d'appels au modèle. Le système mutualise la capacité tout en isolant le débit de chaque client, et l'inférence reste cantonnée à la région AWS choisie pour répondre aux exigences réglementaires de résidence des données. Autre nouveauté clé : la mise en cache des prompts avec des points de rupture explicites, qui permet de réutiliser le contexte déjà traité, comme les instructions système ou les définitions d'outils, lors des appels suivants. Cette fonctionnalité vise directement les charges de travail agentiques et multi-étapes, où une grande partie du contexte se répète d'un appel à l'autre, réduisant ainsi coûts et latence pour les architectures d'intelligence artificielle les plus exigeantes.

💬 Ce qui m'accroche ici c'est pas les 80 points sur l'index de code, c'est le bond sur ExploitBench : 73,5% contre 47,9% pour GPT-5.5, sur un test taillé pour la recherche de failles de sécurité. Tu vois où ça mène : un modèle qui trouve mieux les vulnérabilités, ça sert la défense autant que l'attaque, et personne n'en parle vraiment. Le vrai coup, lui, c'est la distribution : atterrir sur Bedrock au prix OpenAI direct, c'est vendre la techno via la ligne AWS que les boîtes ont déjà signée, sans nouveau contrat à faire approuver.

Créer et connecter un serveur MCP e-commerce prêt pour la production avec Amazon Bedrock AgentCore

Amazon a publié un guide technique détaillant la construction d'un serveur MCP (Model Context Protocol) prêt pour la production dans le secteur de l'ecommerce, combinant Amazon Bedrock AgentCore et Mistral AI Studio. Le tutoriel montre comment développer un serveur en Python avec le framework FastMCP, exposant six outils dédiés au commerce en ligne via un point de terminaison /mcp et un endpoint /health pour le monitoring. Le serveur s'appuie sur cinq tables Amazon DynamoDB à capacité à la demande, couvrant les produits, les clients, les commandes, les avis et les retours. L'authentification repose sur un système à deux niveaux de jetons JWT, avec Amazon Cognito gérant l'identité des utilisateurs via le protocole OAuth 2.1. Le déploiement s'effectue avec AWS Cloud Development Kit (CDK), et l'exécution est prise en charge par AgentCore Runtime, qui construit les images de conteneurs dans le cloud grâce à AWS CodeBuild, sans nécessiter Docker en local. Une fois déployé, ce serveur est connecté à Vibe, l'interface conversationnelle de Mistral AI disponible sur web, iOS et Android, permettant aux utilisateurs d'interagir en langage naturel avec les fonctions de recherche de produits, de passation de commandes, de soumission d'avis et de traitement des retours. Cette approche répond à un problème concret pour les équipes ecommerce : le développement d'assistants IA connectés nécessite habituellement des semaines d'intégration sur mesure, avec du code API spécifique pour chaque client, une gestion complexe de l'infrastructure de conteneurs et des mécanismes d'authentification à construire de zéro. En s'appuyant sur le standard MCP, un unique serveur peut être interrogé par plusieurs clients IA différents, éliminant le besoin de développer une intégration distincte pour chacun d'entre eux. AgentCore Runtime prend en charge la gestion des conteneurs, l'isolation des sessions, la validation des jetons JWT et l'observabilité, ce qui décharge les équipes techniques de la maintenance des load balancers et des middlewares d'authentification. Pour les entreprises du secteur, cela signifie un temps de mise sur le marché considérablement réduit pour des expériences client conversationnelles, tout en garantissant l'isolation des données propres à chaque client grâce à la gestion d'identité de Cognito. Ce projet illustre la stratégie plus large d'Amazon Web Services consistant à positionner Bedrock AgentCore comme plateforme de référence pour construire, connecter et faire évoluer des agents IA à grande échelle, en misant sur l'interopérabilité offerte par le protocole MCP plutôt que sur des intégrations propriétaires fermées. Le partenariat avec Mistral AI Studio, dont l'interface Vibe sert de vitrine grand public, s'inscrit dans une tendance où les fournisseurs cloud et les éditeurs de modèles collaborent pour rendre les agents IA directement exploitables par les entreprises, sans développement d'infrastructure supplémentaire. Ce guide, accompagné d'une démonstration vidéo, cible les équipes techniques cherchant à évaluer concrètement comment déployer un agent conversationnel connecté à leurs propres systèmes de données, avec des exigences de sécurité et de scalabilité déjà prises en compte dès la conception.

Face aux géants américains, Mistral AI et Naver misent sur l’IA industrielle souveraine

Naver Cloud, le géant sud-coréen du cloud, a officialisé le 8 juillet 2026 un partenariat mondial avec la start-up française Mistral AI. L'objectif affiché est de déployer des solutions d'intelligence artificielle souveraines au sein des entreprises manufacturières européennes et asiatiques. Les deux groupes veulent construire une alternative aux plateformes généralistes dominées par les hyperscalers américains, à un moment où les dépenses mondiales en infrastructures cloud ont atteint 129 milliards de dollars au premier trimestre 2026, un marché toujours contrôlé par Amazon Web Services, Microsoft et Google. Mistral apporte ses modèles et une expertise en ingénierie industrielle acquise auprès de groupes comme Airbus, BMW et ASML, tandis que Naver Cloud fournit son infrastructure, sa connaissance du marché sud-coréen et un accès direct aux industriels asiatiques. Lors de son AI Now Summit de mai 2026, Mistral avait déjà présenté une pile d'IA dédiée à l'ingénierie industrielle couvrant la conception, la simulation et la production, illustrée notamment par son accord avec Airbus pour étendre l'IA à l'aviation commerciale, aux hélicoptères, à la défense et au spatial, sous des exigences strictes de sécurité pour des données confidentielles ou militaires. Cette alliance illustre une stratégie de contournement face à des concurrents financièrement hors de portée. Plutôt que de rivaliser sur la taille des centres de données, Mistral et Naver choisissent de déplacer la bataille vers l'intégration fine de l'IA dans les processus industriels, un terrain où la puissance de calcul brute ne suffit pas. Les premiers cas d'usage ciblés, la détection en temps réel des anomalies de qualité et l'optimisation de la sélection des composants, ont déjà été expérimentés chez des fabricants européens et seront désormais proposés aux industriels coréens. Pour les entreprises manufacturières, l'enjeu est de taille : elles pourraient accéder à une IA capable de dialoguer avec leurs systèmes existants et leurs données métiers spécifiques, sans dépendre exclusivement des plateformes américaines, un argument de souveraineté numérique de plus en plus recherché en Europe comme en Asie. La commercialisation débutera en Corée du Sud, où Naver Cloud proposera les modèles et la plateforme de Mistral via sa propre infrastructure, pendant que Mistral enverra des ingénieurs de déploiement directement chez les clients coréens pour résoudre les difficultés d'intégration. Cette approche répond à un constat structurel : selon Synergy Research Group, AWS, Google et Microsoft représentaient encore fin 2025 près des deux tiers du marché mondial des infrastructures cloud, une domination que la croissance de l'IA ne fait que renforcer grâce à leur capacité d'investissement massif dans les centres de données et les accélérateurs. Face à cette asymétrie de moyens, Mistral et Naver misent sur la spécialisation sectorielle et la souveraineté des données comme véritables leviers commerciaux, pariant que l'avenir de l'IA industrielle se jouera moins sur la taille des infrastructures que sur la capacité à s'insérer durablement dans des chaînes de production complexes et sensibles.

Marché entreprise : les acteurs de l’IA misent sur des ingénieurs placés chez le client

Microsoft et Amazon ont annoncé coup sur coup la création de divisions dédiées au Forward Deployed Engineering (FDE), c'est-à-dire au placement direct d'ingénieurs IA chez leurs clients entreprise. Chez Microsoft, cette nouvelle entité baptisée Microsoft Frontier Company doit mobiliser 2,5 milliards de dollars d'investissement et réunir 6 000 experts métier et ingénieurs. Selon Judson Althoff, CEO de Microsoft Commercial Business, elle doit devenir « l'organisation d'ingénierie la plus importante, compétente et orientée vers l'obtention de résultats concrets et mesurables pour les clients », chargée de co-concevoir et déployer des systèmes d'IA à grande échelle avec les entreprises clientes. De son côté, Amazon Web Services a annoncé plus tôt dans la semaine sa propre division Forward Deployed Engineering, avec un investissement de 1 milliard de dollars. OpenAI avait ouvert le bal dès le mois de mai en rachetant l'ESN Tomoto pour créer The OpenAI Deployment Company, financée par 19 investisseurs pour plus de 4 milliards de dollars. Une semaine auparavant, Anthropic avait dévoilé un dispositif comparable, en s'associant à des acteurs financiers pour bâtir une structure commerciale où ses ingénieurs travaillent aux côtés d'intégrateurs partenaires afin d'accélérer le déploiement de projets fondés sur les modèles Claude, sans que le montant investi soit précisé. Google Cloud a lui aussi annoncé début juin son intention de recruter massivement sur ce créneau. Cette course au FDE traduit un changement de modèle économique pour les géants de l'IA, qui ne se contentent plus de vendre des accès API ou du cloud mais placent désormais des compétences humaines directement dans les équipes de leurs clients pour garantir des résultats métiers concrets. Pour les entreprises, cela promet des déploiements plus rapides et mieux adaptés à leurs cas d'usage réels, mais soulève aussi la question du contrôle : Microsoft insiste ainsi sur sa capacité à proposer des modèles OpenAI, Anthropic, Microsoft AI ou open source « sans jamais perdre le contrôle au profit d'un acteur unique », signe que la crainte d'un enfermement chez un fournisseur unique est bien présente chez les clients. Le concept de FDE a été popularisé par Palantir, qui en a fait une marque de fabrique jusque dans des contrats sensibles, à l'image de la DGSI française, où la société française ChapsVision vient justement de lui souffler le contrat en mettant en avant cette même approche de proximité terrain. Face à la difficulté persistante des entreprises à transformer leurs projets d'IA en résultats mesurables, les hyperscalers et laboratoires d'IA généralisent désormais cette méthode, ouvrant une nouvelle guerre des talents autour des ingénieurs de déploiement.

💬 Microsoft, Amazon, Google, OpenAI, Anthropic : tout le monde envoie ses ingénieurs bosser directement chez le client, et ça dit tout du vrai problème de l'IA en entreprise. Ce n'est plus une histoire d'accès API, c'est une guerre de service après-vente à coups de milliards, parce que sans quelqu'un sur place pour faire tourner le truc, les projets IA restent des PowerPoint. Et ce qui devrait alerter les DSI, c'est que ChapsVision vient de piquer le contrat de la DGSI à Palantir avec exactement la même recette : la vraie bataille n'est plus le modèle, c'est qui a les mains dans le cambouis.

Anthropic relance Claude Fable 5 dans le monde après la levée des restrictions américaines à l'export

Anthropic a restauré aujourd'hui l'accès mondial à Claude Fable 5, son modèle grand public le plus puissant, après que le département du Commerce américain a levé la veille les contrôles d'exportation d'urgence qu'il avait imposés au modèle. Cet ordre, émis le 12 juin 2026, avait contraint Anthropic à suspendre l'accès mondial à la fois à Fable 5 et à son pendant orienté cybersécurité, Claude Mythos 5, quelques jours seulement après leur lancement. Fable 5 est désormais de nouveau disponible pour les utilisateurs du monde entier sur l'ensemble de l'écosystème Anthropic, incluant la Claude Platform, Claude.ai, Claude Code et Claude Cowork. Le média VentureBeat, qui a tenté d'y accéder via Claude Code en ligne de commande juste avant la publication de son article, a toutefois constaté que l'accès restait désactivé. Pour les entreprises passant par les grands fournisseurs cloud, Anthropic affirme œuvrer à rétablir l'accès sur Amazon Web Services, Google Cloud et Microsoft Foundry « aussi vite que possible », sans que VentureBeat ait pu confirmer, à ce stade, un retour effectif sur ces plateformes. Le cas de Mythos 5 reste différent : une lettre attribuée au secrétaire au Commerce Howard Lutnick, adressée au dirigeant d'Anthropic Tom Brown et publiée sur X, indique qu'aucune licence n'est plus requise pour l'exportation, la réexportation ou le transfert national de Fable et Mythos. Mais Anthropic, dans son propre communiqué, précise que l'accès à Mythos 5 n'a été rétabli que pour « un ensemble d'organisations américaines », à la suite d'une approbation gouvernementale obtenue le 26 juin, l'entreprise disant continuer de coordonner avec les autorités l'élargissement de l'accès via son programme de test de cybersécurité sur invitation, Project Glasswing. Cette décision a un impact direct sur les directions informatiques qui évaluent le retour de ces modèles, car elle s'accompagne de conditions structurelles distinctes et d'un coût élevé : Anthropic facture Fable 5 et Mythos 5 à 10 dollars par million de tokens en entrée et 50 dollars par million en sortie, ce qui en fait les modèles de pointe les plus chers du marché mondial, très loin devant des concurrents comme DeepSeek, MiniMax, LongCat, Gemini, Qwen ou Grok, dont les tarifs varient de 0,40 à environ 4 dollars par million de tokens combinés. Mythos 5 se retrouve ainsi dans une situation intermédiaire : juridiquement dégagé du contrôle d'exportation d'urgence, mais toujours pas disponible en accès général, Anthropic ayant choisi de le maintenir derrière un modèle d'accès vérifié où le gouvernement américain continue de peser sur les approbations et les standards. Sur X, Lutnick a expliqué qu'Anthropic et l'administration avaient « travaillé en étroite collaboration » pour « analyser et approuver Fable 5 », tandis que la cheffe de cabinet de la Maison-Blanche Susie Wiles a de son côté présenté cette décision comme un enjeu de leadership américain en IA, affirmant que les États-Unis restent le « vainqueur incontesté de la course à l'IA » et que la priorité partagée est de « déployer les meilleures technologies aussi rapidement et sûrement que possible ». Ce revirement fait suite aux critiques de responsables de la cybersécurité et d'experts en politique de l'IA, qui estimaient que cet ordre risquait de fragiliser l'industrie américaine tout en ouvrant un boulevard aux laboratoires chinois. L'ancien responsable de la sécurité de Facebook, Alex Stamos, avait qualifié la restriction sur Fable 5 de « énorme erreur stratégique pour les États-Unis », avertissant que les entreprises de cybersécurité pourraient se tourner vers des modèles chinois faute d'accès fiable aux modèles américains. D'autres critiques ont pointé le caractère improvisé de cette intervention réglementaire, qui donnait l'impression que dépendre des plateformes d'IA américaines constituait désormais un risque stratégique en soi. L'épisode illustre les tensions persistantes entre les impératifs de sécurité nationale, la compétition technologique avec la Chine et la volonté de Washington de préserver l'avance commerciale de ses champions de l'IA, un équilibre que les autorités américaines devront continuer d'ajuster à mesure que ces modèles se diffusent auprès de nouveaux partenaires domestiques et internationaux.

💬 Le vrai frein pour Fable 5, c'est pas Washington, c'est la facture : à 10 dollars l'entrée et 50 la sortie par million de tokens, c'est le modèle de pointe le plus cher du marché, loin devant Gemini, Qwen ou Grok. Bon, sur le papier la levée des restrictions règle le problème de dispo, mais VentureBeat n'arrivait toujours pas à s'en servir via Claude Code au moment de publier, alors si tu comptais y rebasculer demain matin, attends encore un peu. Et Mythos 5, le modèle cybersécurité, reste coincé en accès restreint, Washington continuant de décider qui a le droit de s'en servir.

AWS investit 1 milliard de dollars pour déployer des ingénieurs en IA chez ses clients

AWS a annoncé le 30 juin 2026, lors de son AWS Summit à Washington D.C., le lancement d'AWS Forward Deployed Engineering (FDE), une nouvelle organisation d'ingénierie dotée d'un investissement d'un milliard de dollars. Le principe : des équipes d'environ cinq à six ingénieurs AWS sont directement intégrées chez les clients pour concevoir, développer et mettre en production des systèmes d'IA adaptés à leurs données, leur gouvernance et leurs contraintes métier. Francesca Vasquez, vice-présidente en charge de l'ingénierie et des services d'IA avancés chez AWS, explique que cette organisation regroupe des capacités jusqu'ici dispersées au sein de l'entreprise, désormais réunies sous une structure unique avec un cadre commun de déploiement. L'objectif affiché est ambitieux : réduire les délais de mise en œuvre de plusieurs mois à quelques jours seulement, grâce à une combinaison d'expertise humaine et d'IA agentique, les ingénieurs travaillant aux côtés d'agents qui automatisent une partie des tâches techniques. Cette initiative répond à un changement de posture des entreprises face à l'IA : elles ne veulent plus simplement expérimenter la technologie, mais l'intégrer rapidement dans leurs opérations pour obtenir un retour sur investissement concret et rapide. Contrairement à une mission de conseil classique qui s'arrête une fois le projet livré, AWS insiste sur le fait que ses équipes forment progressivement les collaborateurs clients à devenir autonomes, avec documentation complète, graphes de connaissances et procédures d'exploitation à l'appui. Autre argument mis en avant par AWS : les systèmes restent hébergés dans l'environnement du client, avec chiffrement de bout en bout, isolation matérielle et gouvernance garantissant que les données ne quittent jamais leur périmètre sécurisé, un point sensible pour les grandes entreprises soucieuses de leur conformité. Ce mouvement s'inscrit dans une bataille plus large entre hyperscalers et laboratoires d'IA pour capter la demande d'intégration d'agents en entreprise. Le modèle d'ingénieurs embarqués n'est pas inédit : Palantir le pratique depuis plusieurs années avec ses grands comptes. Mais AWS devient le premier hyperscaler à structurer cette activité à cette échelle, avec un investissement dédié d'un milliard de dollars. La manœuvre fait aussi écho à des annonces récentes de ses concurrents directs dans l'IA générative. En mai 2026, Anthropic a lancé une société de services soutenue par Blackstone, Hellman & Friedman et Goldman Sachs pour aider les entreprises à déployer Claude. Quelques jours plus tard, OpenAI dévoilait à son tour OpenAI Deployment Co., appuyée notamment par TPG, Advent International, Bain Capital et Brookfield Asset Management, avec une ambition similaire d'intégrer des ingénieurs directement chez les clients. AWS, en misant sur son infrastructure cloud existante, cherche à ne pas laisser ce terrain stratégique aux seuls fournisseurs de modèles.

💬 Un milliard de dollars pour caser des ingénieurs chez les clients, ça dit une chose : le goulot d'étranglement de l'IA en entreprise, c'est plus le modèle, c'est l'intégration. Anthropic, OpenAI et maintenant AWS lancent tous leur bras "déploiement" à quelques semaines d'écart, ça sent moins la coïncidence que la course à qui capte la vraie valeur, celle qui se joue après la démo. Bon, sur le papier ça promet des jours au lieu des mois, reste à voir si ça tient une fois que les cinq ingénieurs repartent et que le client se retrouve seul avec ses agents.

Amazon Bedrock AgentCore Observability : déboguer les agents en production

Amazon vient de détailler le fonctionnement d'AgentCore Observability, un outil intégré à sa plateforme Bedrock destiné à déboguer les agents d'intelligence artificielle en production. Contrairement aux applications traditionnelles qui génèrent des erreurs explicites, les agents IA échouent souvent en silence : ils peuvent retourner des réponses plausibles mais incorrectes, entrer dans des boucles de raisonnement infinies, ou sélectionner de mauvais outils sans déclencher la moindre alerte. AgentCore Observability répond à ce problème en exposant trois couches d'instrumentation : des métriques agrégées, des traces d'exécution pas à pas, et des journaux structurés. L'outil permet de suivre chaque étape de raisonnement de l'agent, d'inspecter les appels d'outils, et de localiser précisément où l'exécution dévie des attentes, même en l'absence d'erreur explicite. Le service s'appuie sur Amazon CloudWatch et nécessite l'activation de la fonctionnalité CloudWatch Transaction Search. L'enjeu est considérable pour les équipes qui déploient des agents en production : jusqu'ici, un monitoring classique pouvait afficher 100 % de succès d'exécution pendant que les utilisateurs recevaient de fausses informations. AWS identifie trois grandes familles de défaillances. Les problèmes de qualité regroupent les hallucinations, les erreurs factuelles, et les erreurs de raisonnement : un agent peut citer des politiques inexistantes ou répéter un calcul erroné. Dans les architectures multi-agents, ces erreurs se propagent en cascade lorsque la sortie d'un agent alimente l'entrée d'un autre. Les problèmes de fiabilité couvrent les échecs d'appels d'outils (erreurs 401, 403, 400), les pertes de contexte de session, et les workflows incomplets. Enfin, les problèmes d'efficacité affectent les coûts et les performances sans nécessairement compromettre l'exactitude : latence excessive, consommation de tokens gonflée par des réponses trop verbeuses ou des appels d'outils répétés faute de mise en cache. Ce lancement s'inscrit dans la course que mènent les grands fournisseurs cloud pour rendre les agents IA opérationnellement viables en entreprise. AWS, Microsoft Azure et Google Cloud investissent massivement dans des couches d'observabilité spécifiques aux LLMs, un segment qui n'existait pas il y a deux ans. La complexité croissante des architectures agentiques, où plusieurs modèles coopèrent et s'enchaînent, rend l'observabilité traditionnelle insuffisante. AgentCore Observability est présenté comme une première partie d'une série en deux volets : une seconde publication couvrira l'optimisation des performances et la gestion de la mémoire. La direction prise par AWS suggère que l'outillage autour des agents autonomes va devenir un différenciateur clé des plateformes cloud dans les prochains mois.

Les applications d'IA à base d'agents sur AWS avec une stratégie moderne de maillage de données

Amazon Web Services a publié un guide architectural détaillé pour construire des applications d'IA agentique sur un maillage de données distribué, en réponse aux lacunes de gouvernance que les systèmes actuels de type RAG (Retrieval Augmented Generation) ne permettent pas de combler. L'architecture proposée repose sur trois composants clés : Amazon S3 Vectors pour les bases de connaissances vectorielles, qui réduit les coûts de stockage et de requête jusqu'à 90 % par rapport aux bases de données vectorielles spécialisées dans des charges de travail à fréquence modérée ; Amazon S3 Tables avec support natif d'Apache Iceberg, qui offre jusqu'à dix fois plus de transactions par seconde que les tables Iceberg auto-gérées, avec sécurité au niveau des lignes, colonnes et cellules individuelles via AWS Lake Formation ; et enfin, une exposition du maillage de données sous forme d'outils MCP (Model Context Protocol) via AgentCore Gateway, avec des intercepteurs Lambda pour un contrôle d'accès déterministe à chaque invocation. L'enjeu est considérable pour les entreprises qui déploient des agents IA en production. Contrairement aux pipelines RAG classiques, où l'agent se contente de récupérer des extraits d'un index vectoriel préexistant, les agents autonomes modernes découvrent dynamiquement des schémas de bases de données, construisent des requêtes SQL et synthétisent des données issues de sources multiples. Ce comportement expose des failles de gouvernance que le modèle à point de contrôle unique ne peut pas gérer : un agent de service client qui interroge simultanément des bases de commandes, des politiques de retour et des données clients peut contourner des restrictions d'accès si le contrôle n'est pas appliqué à chaque étape de la chaîne. L'architecture décrite impose des autorisations distinctes au niveau de la couche agent, de la passerelle, des outils et du maillage de données lui-même, sans point de défaillance unique. Ce travail s'inscrit dans une évolution plus large de l'écosystème AWS vers l'IA agentique d'entreprise. Un article précédent d'AWS avait déjà abordé le contrôle d'accès fin pour les applications RAG sur des lacs de données serverless. La nouvelle architecture l'étend en intégrant Amazon Bedrock AgentCore Runtime, un environnement d'hébergement serverless qui déploie les agents dans des microVM isolés avec isolation de session, et le framework LangGraph pour orchestrer les appels aux outils MCP. Les intercepteurs de requêtes valident les jetons JWT et appliquent les périmètres d'autorisation, tandis que les intercepteurs de réponses gèrent la rédaction des données sensibles et la journalisation d'audit. AWS Bedrock Guardrails surveille en temps réel les injections de prompts et les contenus dangereux à chaque invocation d'outil. Cette architecture cible directement les équipes data et les architectes cloud qui doivent mettre en production des agents IA tout en respectant des contraintes de conformité et de sécurité strictes.

Nokia et AWS renforcent leur collaboration pour créer des réseaux autonomes dédiés à l’IA

Nokia a annoncé le 24 juin 2026 l'extension de son partenariat stratégique avec Amazon Web Services pour déployer sa plateforme Autonomous Network Fabric directement dans le cloud AWS. L'objectif est de permettre aux opérateurs télécoms d'atteindre un niveau d'autonomie réseau de niveau 4, c'est-à-dire des infrastructures capables d'analyser, de décider et d'agir en temps réel sans intervention humaine. La solution sera disponible plus tard en 2026 et s'intégrera aux outils d'orchestration, de supervision et d'inventaire déjà proposés par Nokia sur AWS. L'architecture repose sur quatre piliers : une gestion unifiée des données réseau, une IA agentique dédiée aux opérations, des jumeaux numériques permettant de simuler l'impact des changements avant déploiement, et un pilotage par les intentions capable de traduire automatiquement des objectifs métiers en actions concrètes. Pour les opérateurs télécoms, cet accord représente un accès immédiat à l'élasticité mondiale d'AWS et à ses services d'intelligence artificielle, notamment Amazon Bedrock et Amazon SageMaker, sans avoir à investir massivement dans leurs propres capacités de calcul. Nokia affirme par ailleurs avoir optimisé son architecture cloud pour réduire les besoins en calcul et en stockage par rapport aux déploiements sur site traditionnels. L'enjeu économique est considérable : automatiser les boucles de détection et de résolution d'anomalies, orchestrer des réseaux multi-domaines et multi-fournisseurs, et disposer d'une vision unifiée de la topologie réseau permettrait de réduire significativement les coûts opérationnels tout en accélérant le lancement de nouveaux services à valeur ajoutée. Ce rapprochement s'inscrit dans une tendance de fond qui voit les équipementiers historiques des télécoms pivoter vers le cloud et l'IA face à la complexité croissante des infrastructures réseau. L'explosion des usages liés à l'IA générative et à la 5G contraint les opérateurs à gérer des réseaux toujours plus distribués et dynamiques, que les outils de gestion manuelle peinent à absorber. Nokia, concurrent direct d'Ericsson et de Huawei, mise sur AWS pour accélérer la transition de ses clients vers ce qu'il appelle les "réseaux autonomes", un segment où plusieurs acteurs se positionnent simultanément. Pour AWS, l'enjeu est de s'imposer comme le cloud de référence du secteur télécoms, un marché à forte valeur où Google Cloud et Microsoft Azure jouent également des coudes. La disponibilité annoncée d'ici fin 2026 fixe un calendrier concret sur lequel les opérateurs pourront commencer à évaluer le saut opérationnel que promet cette alliance.

NVIDIA et AWS s'associent pour déployer l'IA en production à grande échelle

NVIDIA et Amazon Web Services (AWS) ont annoncé un approfondissement de leur collaboration pour faciliter le déploiement de l'intelligence artificielle à grande échelle en production. Les nouvelles instances Amazon EC2 G7, équipées des GPU NVIDIA RTX PRO 4500 Blackwell Server Edition, offrent jusqu'à 4,6 fois les performances d'inférence IA et 2,1 fois les performances graphiques par rapport aux instances G6 précédentes. Ces instances supportent jusqu'à huit GPU, 256 Go de mémoire GPU totale, 700 Gbps de réseau EFA et jusqu'à 7,6 To de stockage NVMe local, dans des configurations allant d'un à huit GPU. Parallèlement, la bibliothèque NVIDIA cuVS devient le moteur par défaut de l'indexation vectorielle dans Amazon OpenSearch Serverless, avec des performances jusqu'à dix fois supérieures à un coût quatre fois inférieur aux solutions CPU seules. AWS a par ailleurs obtenu le statut NVIDIA Exemplar Cloud sur les GPU GB300, certification attestant que la plateforme répond aux seuils de performance de référence de NVIDIA pour les charges d'entraînement. Ces avancées changent concrètement la donne pour les équipes qui construisent des systèmes d'IA en production. L'intégration de cuVS comme choix par défaut dans OpenSearch Serverless transforme la recherche vectorielle accélérée par GPU d'un projet d'optimisation spécialisé en une capacité AWS standard. Cela signifie que des bases de données vectorielles à l'échelle du milliard d'entrées deviennent réalisables en moins d'une heure, ce qui rend les applications de type RAG (retrieval-augmented generation), recherche sémantique ou IA agentique accessibles à un bien plus grand nombre d'entreprises. Pour les équipes médias et data, les instances G7 permettent également de traiter des workflows vidéo haute résolution, du rendu 3D et des pipelines analytiques sur le même type d'instance, réduisant la complexité opérationnelle. Cette collaboration s'inscrit dans une course entre les grands fournisseurs cloud à offrir la meilleure infrastructure IA clé en main. NVIDIA cherche à s'imposer comme couche matérielle incontournable, aussi bien pour l'entraînement que pour l'inférence et la recherche vectorielle, tandis qu'AWS veut simplifier le passage de l'expérimentation à la production. Le statut Exemplar Cloud sur les GB300, fruit d'un co-engineering approfondi entre les deux entreprises, positionne AWS comme plateforme de référence pour les charges d'entraînement les plus exigeantes. Les instances G7 seront prochainement disponibles sur Amazon SageMaker AI, ce qui étendra encore leur portée. L'enjeu sous-jacent est de réduire la friction entre infrastructure et application pour les entreprises qui n'ont pas les ressources pour gérer leurs propres clusters GPU.

Together AI et Hugging Face profitent de l'essor de l'open source

Together AI, la néo-infrastructure cloud spécialisée dans les modèles d'IA open source, a relevé ses projections de revenus annuels au moins trois fois au cours des derniers mois. Son PDG Vipul Ved Prakash a révélé que la plateforme générait environ un milliard de dollars de revenus annualisés en mars 2026, portée par une explosion du volume de calcul : le nombre de tokens traités via son cloud est passé de 30 milliards par mois il y a un an à 400 000 milliards ce mois-ci, une grande partie de cette croissance s'étant produite au cours des six derniers mois. Chez Hugging Face, dépôt de référence pour les modèles open source, le nombre d'abonnés payants a doublé entre janvier et juin, a indiqué le cofondateur et PDG Clem Delangue, sans préciser les chiffres absolus. Dans le même élan, Not Diamond, startup spécialisée dans les "model routers", des logiciels permettant aux entreprises de basculer facilement entre différents modèles selon la tâche, a connu "une forte hausse de la demande ces six derniers mois", selon son PDG Tomás Hernando Kofman. Ces routeurs, utilisés notamment par Cisco et Adobe, permettraient d'économiser entre 20 % et 40 % sur les coûts d'utilisation des modèles Anthropic les plus onéreux. Cette dynamique illustre un basculement stratégique dans l'industrie : les entreprises cherchent activement à reprendre le contrôle de leurs coûts d'IA et à réduire leur dépendance à un fournisseur unique. Thomas Wolf, cofondateur de Hugging Face, parle d'un "grand réveil sobre" chez ses clients professionnels, préoccupés par les prix en hausse des modèles propriétaires et les risques d'enfermement technologique. Si l'on rapporte la croissance de Together AI aux tarifs actuels, par exemple 18 centimes par million de tokens pour DeepSeek v4 Pro, l'écart entre 30 milliards et 400 000 milliards de tokens représenterait environ 70 millions de dollars de dépenses mensuelles supplémentaires. Vipul Ved Prakash estime que les modèles open source représenteront à terme la grande majorité des usages d'IA dans le monde. Ce mouvement s'inscrit dans un contexte plus large de maturité du marché de l'IA en entreprise. OpenAI et Anthropic continuent de défendre leurs modèles premium en arguant que leurs performances justifient les prix pratiqués, mais la concurrence ouverte s'intensifie. Parallèlement, Amazon Web Services accélère sur un autre front : le géant du cloud forme actuellement ses "solution architects" pour qu'ils deviennent des ingénieurs déployés directement chez les clients, à l'image du modèle dit FDE (forward-deployed engineer) popularisé par Palantir et désormais adopté par OpenAI, Anthropic, Salesforce et Snowflake. AWS s'appuie sur des équipes pluridisciplinaires, incluant ingénieurs, scientifiques appliqués et stratèges en IA, comme au siège d'Atlanta de Cox Automotive début 2025. Ces consultants hybrides, à mi-chemin entre développeur, chef de produit et conseiller stratégique, répondent à une demande croissante des grandes entreprises qui ne disposent pas encore des compétences internes pour déployer l'IA de manière autonome.

Créer un assistant de recherche sur les protéines avec Amazon Bedrock AgentCore

Amazon Web Services a publié un guide technique détaillant la construction d'un assistant conversationnel dédié à la recherche sur les protéines, baptisé "protein research copilot", reposant sur Amazon Bedrock AgentCore. Le système permet aux chercheurs de soumettre des requêtes en langage naturel, par exemple "Trouve 10 peptides similaires au peptide du virus de la dengue LPAIVREAI", et d'obtenir automatiquement des résultats de similarité structurelle accompagnés d'une synthèse scientifique générée par IA. L'architecture s'appuie sur le SDK Strands Agents pour orchestrer trois outils spécialisés au sein d'un agent unique : un parseur de requêtes, un moteur de recherche vectorielle, et un summariseur. Les embeddings protéiques sont calculés via le modèle ESM-C 300M déployé comme endpoint serverless sur Amazon SageMaker AI, puis comparés par similarité cosinus dans une base Amazon Aurora PostgreSQL avec l'extension pgvector. L'interface utilisateur tourne sur AWS Fargate via Streamlit, et le modèle de langage central est Claude Sonnet 4.6 d'Anthropic, accessible via l'API Bedrock Converse. Ce type d'outil répond à un problème concret dans les laboratoires de biologie computationnelle : la recherche manuelle de peptides structurellement similaires parmi des milliers de séquences est lente, sujette aux erreurs, et exige une expertise pointue pour interpréter les résultats. En automatisant l'ensemble du pipeline, de la formulation de la question à la synthèse des résultats, le copilote réduit drastiquement le temps passé sur des tâches répétitives et rend la recherche accessible à des profils moins spécialisés en bioinformatique. Le pattern "LLM-as-parser" utilisé pour extraire des paramètres structurés depuis du langage naturel est directement réutilisable dans d'autres domaines scientifiques où les données sont complexes et la formulation des requêtes peu standardisée. Cette publication s'inscrit dans la stratégie d'AWS de positionner Bedrock AgentCore comme plateforme de référence pour déployer des agents IA en production, face à des concurrents comme Google Vertex AI ou Microsoft Azure AI Studio. Le secteur biotech et pharmaceutique représente une cible prioritaire : la recherche sur les épitopes viraux, le dataset utilisé ici est celui de l'IEDB (Immune Epitope Database), est au coeur du développement de vaccins et de thérapies antivirales. Le modèle ESM-C, développé par EvolutionaryScale, est l'un des modèles de langage protéique les plus performants du moment. Le déploiement complet est estimé entre 30 et 45 minutes, mais implique des coûts sur Bedrock, SageMaker, Aurora Serverless v2 et Fargate qu'AWS invite explicitement à consulter avant de lancer l'infrastructure. Les prochaines étapes naturelles seraient l'intégration de bases de données protéiques publiques comme UniProt ou PDB, et l'extension à d'autres types de molécules biologiques.

AWS juge les agents IA insuffisants en contexte métier et sécurité, et lance deux services pour y remédier

Lors de son sommet à New York, AWS a dévoilé deux nouveaux services destinés à combler les lacunes des agents IA en entreprise. Le premier, baptisé Continuum, détecte automatiquement les vulnérabilités dans le code, les priorise et propose des correctifs sans intervention humaine. Le second, Context, construit un graphe de connaissances à partir des données internes de l'entreprise afin de fournir aux agents IA le contexte métier dont ils ont besoin pour opérer correctement. Ces deux services s'attaquent à un problème central qui freine l'adoption des agents IA dans les environnements professionnels : ces systèmes produisent du code rapidement, mais commettent trop souvent des erreurs, qu'il s'agisse de failles de sécurité ou de décisions inadaptées faute de comprendre le fonctionnement réel de l'organisation. Continuum réduit la surface d'attaque en automatisant la détection de vulnérabilités, tandis que Context évite les hallucinations et les erreurs de jugement en ancrant les agents dans la réalité de l'entreprise, ses processus, ses données, ses contraintes. Cette annonce intervient alors que les grands fournisseurs cloud rivalisent pour s'imposer comme l'infrastructure de référence pour les agents IA d'entreprise. Microsoft Azure, Google Cloud et AWS se disputent un marché en pleine expansion, où la promesse d'automatisation se heurte encore à des problèmes de fiabilité et de sécurité. En proposant des couches de correction et de contextualisation natives, AWS cherche à rassurer les DSI et RSSI qui hésitent encore à déployer ces agents en production sur des systèmes critiques.

💬 AWS dit tout haut ce que les DSI savent depuis un moment : les agents IA produisent du code vite, mais sans contexte métier ni filet de sécurité, ça casse en prod. Context et Continuum s'attaquent enfin aux deux vrais blocages, ce qui change quelque chose pour les équipes qui hésitaient à franchir le pas en environnement critique. C'est le genre de couche infrastructure qui manquait pour que les agents IA deviennent un outil sérieux, pas juste une démo.

Amazon Bedrock AgentCore intègre la recherche web

Amazon a annoncé la disponibilité générale de Web Search on Amazon Bedrock AgentCore, une fonctionnalité de recherche web entièrement gérée et compatible avec le protocole MCP (Model Context Protocol). Concrètement, elle permet aux agents d'IA déployés sur Bedrock d'accéder en temps réel à des informations issues du web, sans que les équipes techniques aient à gérer une API de recherche tierce, des clés d'accès, des quotas ou du code d'extraction de résultats. Le service s'intègre via l'AgentCore Gateway avec une simple authentification IAM ou JWT, et les agents le découvrent via un appel standard tools/list, comme n'importe quel autre outil MCP. Derrière ce connecteur repose un index web propriétaire maintenu par Amazon, couvrant des dizaines de milliards de documents, mis à jour en continu avec un délai de rafraîchissement de quelques minutes. Le service inclut également un graphe de connaissances pour les réponses factuelles à haute confiance, et une extraction sémantique de passages optimisée pour les fenêtres de contexte des modèles de langage. L'ensemble du trafic de requêtes reste dans l'infrastructure AWS, sans transmission externe. L'enjeu est structurel pour quiconque construit des agents d'IA en production : ces systèmes ont une connaissance figée à la date de leur entraînement. Interroger un agent sur un cours de bourse, un score sportif ou une annonce publiée il y a une heure retourne au mieux une réponse périmée, au pire une hallucination confiante. Web Search on AgentCore supprime ce plafond sans imposer aux équipes de construire et maintenir elles-mêmes une infrastructure de recherche, tâche qui représente en réalité plusieurs projets distincts, gestion des quotas, normalisation des formats, politique de rétention des données, fraîcheur de l'index. Pour les entreprises qui déploient des agents sur des cas d'usage temps réel (veille concurrentielle, support client, analyse de marché), la disponibilité générale de ce service réduit significativement le coût et la complexité d'un composant jusqu'ici souvent bricolé. Ce lancement s'inscrit dans la montée en puissance des architectures agentiques au sein des grands fournisseurs cloud, où Amazon, Google et Microsoft se disputent le rôle de plateforme de référence pour les agents d'entreprise. L'adoption du protocole MCP comme standard d'interopérabilité est un signal fort : Amazon ne cherche pas à enfermer les développeurs dans un écosystème propriétaire, mais à s'imposer comme couche d'infrastructure de confiance. La proposition de valeur repose sur trois piliers que les solutions tierces peinent à réunir simultanément : fraîcheur de l'index, confidentialité des requêtes garantie dans AWS, et qualité de l'extraction pour les modèles. La prochaine étape logique sera probablement l'intégration native avec d'autres outils AgentCore (mémoire, orchestration multi-agents), consolidant Bedrock comme environnement d'exécution complet pour les agents d'IA en production.

💬 Ce qui me frappe plus que la feature en elle-même, c'est qu'Amazon a choisi MCP plutôt qu'une API proprio. En faisant ça, Bedrock se positionne comme couche d'infrastructure neutre pour les agents enterprise, pas comme un silo de plus, et c'est le genre de pari discret qui pèse plus lourd que ça en a l'air dans les décisions d'architecture. Si tu construis des agents avec des besoins temps réel, tu viens de perdre une bonne excuse pour bricoler ta propre pile de recherche.