Dossier AWS — page 2

Les clés de la flexibilité de l'IA en Europe : guide sur l'inférence interrégionale pour le traitement des données et l'accès aux modèles

Amazon Web Services a introduit une fonctionnalité appelée Cross-Region Inference (CRIS) dans Amazon Bedrock, son service d'IA générative managé, permettant aux entreprises européennes de router automatiquement leurs requêtes d'inférence vers plusieurs régions AWS au sein de zones géographiques prédéfinies. Concrètement, lorsqu'une application envoie une requête à un modèle comme Claude d'Anthropic ou un modèle Amazon Nova, CRIS peut la rediriger dynamiquement vers la région disposant de la meilleure capacité disponible, tout en maintenant les données dans un périmètre géographique contrôlé. Pour l'Europe, AWS propose des profils EU CRIS dont toutes les régions de destination sont situées exclusivement au sein de l'Union européenne. Les données transmises restent chiffrées et circulent uniquement sur le réseau privé AWS, sans jamais transiter par l'internet public. Ce mécanisme répond à un problème concret que rencontrent les entreprises européennes : la saturation des capacités de calcul GPU en période de forte demande, qui se traduit par des latences élevées ou des erreurs de disponibilité. En distribuant les requêtes sur plusieurs régions, les applications deviennent plus résilientes aux pics de charge et aux pannes locales. Du point de vue réglementaire, les profils EU CRIS sont conçus pour faciliter la conformité au RGPD, puisque le traitement reste borné à l'UE, un critère déterminant pour les secteurs soumis à des exigences strictes de résidence des données comme la finance, la santé ou les services publics. AWS souligne également que certains modèles sont disponibles à tarif réduit via les profils globaux CRIS, ajoutant un argument économique à l'argument technique. La pression réglementaire européenne sur le traitement des données par des fournisseurs cloud américains s'est intensifiée ces dernières années, notamment après les décisions de la CJUE sur les transferts transatlantiques de données. Les grands hyperscalers comme AWS, Google Cloud et Microsoft Azure ont tous investi massivement dans des infrastructures européennes et des offres de souveraineté pour répondre à ces contraintes. CRIS s'inscrit dans cette logique : plutôt que de forcer les clients à choisir une seule région et à subir ses limitations de capacité, AWS propose une abstraction qui optimise automatiquement tout en respectant les frontières réglementaires. La prochaine étape logique sera l'extension de ces profils géographiques à d'autres zones comme le Moyen-Orient ou l'Asie-Pacifique, et l'intégration de contrôles plus fins permettant aux entreprises de définir elles-mêmes les régions autorisées selon leurs obligations contractuelles ou sectorielles.

Amazon Bedrock AgentCore permet d'héberger des agents de codage en toute sécurité

Amazon a lancé Bedrock AgentCore Runtime, un service cloud conçu pour héberger les agents de codage, Claude Code, Codex, Kiro, Cursor CLI, Gemini CLI ou tout autre outil similaire, sans que le développeur n'ait à garder son ordinateur portable allumé et ouvert. Chaque session obtient un microVM Linux isolé avec un espace de travail persistant, un shell réel et une exécution déterministe des commandes. Le service embarque également trois composantes clés : une couche d'identité qui fait agir l'agent au nom de l'utilisateur qui l'a déclenché, une passerelle MCP (Model Context Protocol) unique donnant accès à GitHub, Jira, Slack et aux services internes avec les vrais tokens stockés hors de portée de l'agent, et une intégration native à Amazon CloudWatch pour tracer chaque action effectuée. Amazon annonce que plusieurs agents concurrents, Claude Code, Codex, Kiro et Cursor, pourront être lancés simultanément sur le même dépôt, chacun dans son propre environnement isolé, et évalués sur la latence, le coût et le taux de réussite des tests. L'enjeu va bien au-delà du confort : héberger un agent de codage sur un laptop expose l'ensemble de l'environnement du développeur. L'agent partage le shell, le système de fichiers, les clés SSH, les credentials AWS stockés dans ~/.aws/credentials, les tokens npm, et le VPN actif. Un fichier README piégé suffit à déclencher une exécution malveillante avec accès complet aux secrets. La parallélisation pose un problème distinct : lancer deux agents via git worktree ne règle que la partie git, les deux processus se battent toujours pour le même localhost:5432, le même port :3000, le même trousseau SSH. Trois agents sur trois branches, c'est trois processus en compétition sur une seule machine. Enfin, fermer le couvercle du laptop tue la session : dépendances à moitié installées, refactoring en cours, suite de tests en attente, tout disparaît. Un chantier de 90 minutes ou une migration nocturne exige que l'écran reste allumé pendant toute la durée. La montée en puissance des agents de codage autonomes a rendu ce problème structurel. Ces outils peuvent désormais tenir des tâches longues, audit de codebase, migrations de schéma, refactoring multi-fichiers, qui dépassent largement la durée d'une session de travail classique. Les équipes qui veulent en tirer parti à l'échelle se heurtent aux limites du modèle "un agent par laptop ouvert". Amazon positionne AgentCore comme la réponse infrastructure à ce changement de régime : un environnement cloud dédié par agent, cloisonné par défaut, observable dès le départ, et déconnecté du cycle de vie de la machine du développeur. Le service s'inscrit dans une compétition plus large entre AWS, Google et Microsoft pour capter les workflows d'IA des équipes engineering, à mesure que les agents de codage passent du statut d'expérimentation à celui d'outil de production.

Inférence ML chiffrée de bout en bout avec Amazon SageMaker AI et le chiffrement homomorphe

Amazon Web Services propose une nouvelle approche pour exécuter des modèles de machine learning dans le cloud sans jamais exposer les données traitées, même au fournisseur d'infrastructure. La méthode repose sur le chiffrement homomorphe intégral (FHE, pour Fully Homomorphic Encryption), une technique cryptographique qui permet d'effectuer des calculs directement sur des données chiffrées, sans jamais les déchiffrer. Concrètement, un client envoie une requête chiffrée à un modèle hébergé sur Amazon SageMaker AI, le modèle produit une prédiction chiffrée, et seul le client peut déchiffrer le résultat final. La bibliothèque open source concrete-ml, compatible avec l'API scikit-learn, sert de couche de haut niveau pour entraîner et déployer ces modèles FHE sans avoir à coder les algorithmes cryptographiques à la main. L'enjeu est considérable pour plusieurs secteurs régulés. Dans le domaine médical, un assureur pourrait déployer un modèle prédictif sur des données diagnostiques de patients sans que ces données quittent le contrôle du médecin, en conformité avec les réglementations sur la vie privée. Dans le secteur énergétique, une entreprise pétrolière pourrait analyser des photos satellites de sites sensibles géopolitiquement sans les confier en clair à un tiers. Un opérateur télécom pourrait filtrer des e-mails clients pour détecter du spam sans violer les obligations de protection des communications personnelles. Dans tous ces cas, le cloud fournit la puissance de calcul, mais reste cryptographiquement aveugle au contenu traité, y compris Amazon lui-même, selon AWS. Cette publication fait suite à un premier article d'AWS qui démontrait le FHE appliqué à SageMaker en construisant manuellement un algorithme de régression linéaire via la bibliothèque bas niveau SEAL. L'approche présentée ici est plus généraliste : concrete-ml prend en charge plusieurs types de modèles standards et s'intègre directement dans les workflows SageMaker existants, via des conteneurs personnalisés. Le FHE se distingue également des environnements d'exécution confidentiels comme AWS Nitro Enclaves, où les données sont déchiffrées dans un enclave isolé avant traitement. Avec le FHE, aucun déchiffrement n'a lieu nulle part dans la chaîne. Le principal frein reste la performance, le FHE est significativement plus lent que le calcul en clair, ce qui limite pour l'instant son usage aux modèles relativement simples, mais la progression rapide des bibliothèques spécialisées laisse entrevoir des applications plus larges à moyen terme.

Le nouveau Colab CLI de Google permet aux développeurs et agents IA d'exécuter Python sur des GPU et TPU distants depuis le terminal

L'équipe Google AI a publié cette semaine le Colab CLI, un outil en ligne de commande qui connecte le terminal local d'un développeur aux runtimes distants de Google Colab. Disponible en open source sous licence Apache 2.0 et installable en une seule commande via uv tool install, l'outil permet d'allouer des sessions de calcul cloud depuis le terminal avec des options matérielles allant du CPU classique aux GPU T4, L4, A100 et H100, ainsi qu'aux puces TPU v5e1 et v6e1. L'interface repose sur un petit ensemble de commandes : colab new pour provisionner une session, colab exec pour exécuter du code Python depuis un fichier local ou l'entrée standard, colab stop pour libérer la machine virtuelle, et colab download ou colab log pour récupérer les résultats sous forme de notebooks .ipynb, fichiers Markdown ou JSONL. Google fournit également un fichier COLAB_SKILL.md qui donne aux agents IA un contexte intégré sur l'utilisation du CLI. Ce qui rend ce lancement significatif, c'est moins la fonctionnalité elle-même que la cible visée : les agents IA. Le Colab CLI est explicitement conçu pour que des outils comme Claude Code, Codex ou l'agent maison Antigravity puissent piloter des pipelines de machine learning de bout en bout sans intervention humaine. Google en fait la démonstration avec un exemple concret : le fine-tuning du modèle Gemma 3 1B via QLoRA sur un jeu de données Text-to-SQL, réalisé par l'agent Antigravity en cinq commandes, sans qu'un seul paramètre de provisionnement cloud ne soit saisi manuellement. Le modèle affiné est ensuite téléchargé localement et prêt à être servi. Pour les développeurs travaillant sur des machines sans GPU, le CLI permet aussi d'externaliser l'entraînement vers le cloud sans quitter leur environnement de travail habituel. Google Colab existe depuis 2017 comme environnement de notebooks Python basé sur le navigateur, largement utilisé dans la communauté recherche et éducation pour son accès gratuit ou peu coûteux aux accélérateurs. Le CLI ne remplace pas cette interface web, il cible un usage radicalement différent : les workflows scriptés, automatisés et pilotés par des agents. Cette distinction reflète une tendance plus large dans l'outillage IA : les agents de codage comme Claude Code ou Codex ont besoin d'accéder à des ressources de calcul sans passer par des interfaces graphiques pensées pour des humains. En positionnant Colab comme une infrastructure compatible avec ces agents, Google s'inscrit dans la course aux plateformes d'exécution pour l'IA agentique, un espace où AWS, Modal et RunPod cherchent aussi à capter les développeurs qui automatisent leurs pipelines ML.

💬 Ce qui m'intéresse, c'est pas le CLI en lui-même : c'est le COLAB_SKILL.md livré avec, un fichier d'instructions taillé pour que des agents comme Claude Code sachent louer un H100 et lancer un fine-tuning sans intervention humaine. Google ne fait pas un outil pour les développeurs, il fait un outil pour que les agents des développeurs aient accès à du calcul cloud sans passer par une interface pensée pour des humains. Reste à voir ce que ça coûte en crédits Colab quand un agent part en vrille à 3h du mat.

Le futuriste IA de Microsoft explique comment il utilise Copilot et les problèmes concrets que les entreprises résolvent avec des agents

Lors de sa conférence Build 2026, Microsoft a dévoilé cette semaine une série d'annonces destinées à ancrer les agents d'intelligence artificielle au cœur des systèmes d'entreprise. La firme a présenté Microsoft IQ, une couche contextuelle unifiée couvrant GitHub Copilot, Microsoft Foundry et Copilot Studio, ainsi que des API Work IQ dont le lancement est prévu le 16 juin. S'y ajoutent Fabric IQ pour les données métier structurées, Foundry IQ pour la récupération d'informations à travers les bases de connaissances d'entreprise et le web en temps réel, et Web IQ, un moteur de recherche conçu spécifiquement pour les agents. Microsoft a également introduit Scout, un assistant personnel de travail autonome, et annoncé sept nouveaux modèles maison regroupés sous la famille MAI, dont MAI-Thinking-1, optimisés pour l'efficience en tokens et la personnalisation sur données propriétaires. En parallèle, Claude Opus 4.8 d'Anthropic est désormais disponible sur Azure Foundry, aux côtés des modèles OpenAI GPT, témoignant d'une stratégie délibérée de choix multiple de modèles. Ces annonces marquent un tournant dans la façon dont Microsoft positionne son infrastructure IA : ce n'est plus l'accès à un modèle puissant qui fait la différence, mais la capacité à donner aux agents un contexte fiable, une identité, une mémoire et un accès sécurisé aux données d'entreprise. Pour les DSI et équipes techniques, cela se traduit concrètement par la possibilité de déployer des agents gérés dans Foundry, avec gestion automatique du dimensionnement et de la conteneurisation, sans avoir à construire cette infrastructure from scratch. L'enjeu est de taille : les entreprises qui parviennent à brancher leurs agents sur leurs données internes et leurs workflows existants pourront automatiser des processus complexes à grande échelle, là où les expériences pilotes restaient jusqu'ici cantonnées à des cas d'usage isolés. Marco Casalaina, VP Products Core AI et "AI Futurist" de Microsoft, est au cœur de cette stratégie. Ancien responsable de l'équipe Einstein AI chez Salesforce et diplômé en informatique de Cornell, il a rejoint Microsoft début 2022 pour prendre la tête des Azure Cognitive Services avant d'étendre son périmètre à l'ensemble des outils pour développeurs IA, incluant Foundry, VS Code, GitHub et GitHub Copilot. Son rôle de futuriste a une définition très concrète chez Microsoft : il est systématiquement le premier à tester chaque nouvelle fonctionnalité en provenance de toutes les équipes de la firme. Cette position d'observatoire lui permet de tracer ce qu'il appelle "le futur immédiat", c'est-à-dire l'horizon à douze mois des capacités agentiques. La compétition pour devenir la plateforme de référence des agents d'entreprise est désormais ouverte, avec Google et AWS comme principaux rivaux dans une course où le contexte, la gouvernance et l'intégration des données deviennent les véritables différenciateurs.

💬 Microsoft assume enfin que la guerre se joue sur la plomberie, pas sur les modèles. Donner aux agents un contexte fiable, une identité et un accès sécurisé aux données internes, c'est précisément ce qui bloquait les pilotes depuis deux ans. Et avoir Claude d'Anthropic sur Azure aux côtés d'OpenAI, c'est malin : un argument de neutralité que Google et AWS n'ont pas encore.

IBM et Google Cloud veulent accélérer l’adoption de l’IA dans les entreprises

IBM et Google Cloud ont annoncé le 4 juin 2026 une expansion significative de leur partenariat stratégique, avec le lancement d'une Google Cloud Practice dédiée au sein d'IBM Consulting. Cette nouvelle entité regroupe des milliers de consultants IBM certifiés Google Cloud ainsi que des équipes d'ingénierie spécialisées, avec pour mission d'accompagner les grandes organisations dans le déploiement d'agents IA à l'échelle industrielle. Concrètement, les deux groupes combinent la plateforme Gemini Enterprise Agent de Google Cloud avec l'expertise sectorielle d'IBM Consulting pour couvrir huit domaines prioritaires : banque, assurance, administrations publiques, télécommunications, énergie, commerce de détail, cybersécurité et sciences de la vie. Les consultants IBM pourront désormais concevoir, déployer et gérer directement des agents IA sur l'infrastructure Google Cloud, en s'appuyant sur des composants préconfigurés et des méthodologies éprouvées. L'enjeu est de résoudre l'un des blocages les plus coûteux de l'industrie : la difficulté à transformer les projets pilotes en déploiements opérationnels rentables. De nombreuses entreprises ont expérimenté l'IA sans parvenir à en extraire une valeur concrète à grande échelle, faute d'intégration avec les systèmes critiques existants et de garanties suffisantes en matière de gouvernance et de conformité réglementaire. En proposant un cadre commun avec des agents sectoriels préconstruits, IBM et Google entendent réduire drastiquement le délai entre la conception et la mise en production, tout en permettant aux organisations d'automatiser des processus métiers complexes sans multiplier les développements sur mesure. Pour les secteurs fortement réglementés comme la finance ou la santé, la promesse est d'intégrer l'IA aux flux de travail existants tout en respectant les contraintes légales et sécuritaires. Cette initiative s'inscrit dans une tendance de fond qui voit les grands acteurs du cloud et du conseil former des alliances de plus en plus intégrées pour capter le marché de l'IA d'entreprise, estimé à plusieurs milliards de dollars. IBM, qui a repositionné une large partie de sa stratégie autour du conseil en transformation numérique depuis la cession de son activité infrastructure à Kyndryl en 2021, cherche à capitaliser sur sa présence dans les grandes entreprises pour distribuer les technologies de ses partenaires cloud. Google Cloud, de son côté, intensifie la mise en marché de Gemini via des alliances avec des intégrateurs disposant d'une relation de confiance établie avec les directions générales et les DSI. La prochaine étape attendue sera la mise sur le marché effective de ces agents sectoriels et les premiers retours de déploiements en production, qui conditionneront la crédibilité commerciale de cette alliance face à des concurrents comme Microsoft et Accenture ou AWS et Deloitte.

💬 Le vrai problème des pilotes IA qui restent des pilotes, IBM et Google s'y attaquent enfin avec du concret. Des milliers de consultants certifiés, des agents préconstruits par secteur, un cadre commun qui évite de tout recoder à chaque client, c'est le genre d'approche qui peut débloquer des grands comptes paralysés depuis deux ans sur les mêmes questions de conformité. Reste à voir ce que ça donne en prod, parce que Microsoft et Accenture ne regardent pas ça les bras croisés.

Generalist lève 400 millions de dollars pour développer ses modèles d'IA généralistes

Generalist AI Inc. a annoncé une levée de fonds de 400 millions de dollars, portant son financement total à plus de 500 millions depuis sa création en 2024. Le tour a été mené par Radical Ventures, avec de nouveaux entrants incluant 8VC, Union Square Ventures, Hanabi Capital et Norwest, auxquels s'ajoutent les investisseurs historiques NVentures (NVIDIA), Boldstart Ventures, Spark Capital et Bezos Expeditions. Parmi les investisseurs individuels figurent Fei-Fei Li, Eric Yuan (PDG de Zoom), Bin Lin et Naval Ravikant. Basée à San Mateo, en Californie, la startup développe des modèles fondamentaux destinés à des robots généralistes, capables d'opérer sur différentes architectures matérielles. En novembre 2025, elle avait lancé GEN-0, présenté comme le premier modèle à appliquer les lois de mise à l'échelle (scaling laws) à la robotique physique. En avril 2026, elle a publié GEN-1, avec des métriques communiquées par la société elle-même: taux de succès moyen de 99 % sur des tâches où les modèles précédents atteignaient 64 %, vitesse d'exécution environ trois fois supérieure sur des manipulations dextères, et seulement une heure de données robotiques nécessaires par compétence apprise. Ces chiffres, s'ils se confirment en conditions industrielles réelles, représenteraient un changement structurel pour la commercialisation de la robotique généraliste. Le principal verrou du secteur reste logiciel: la plupart des intégrateurs investissent encore des semaines de collecte de données pour chaque nouvelle tâche. Un modèle nécessitant une heure de données par compétence transformerait radicalement l'économie du déploiement. Cela dit, les métriques publiées proviennent exclusivement des communications internes de Generalist AI, sans validation indépendante ni précision sur les conditions de benchmark ou la nature des tâches testées. Le concept de "data flywheel", selon lequel les déploiements chez des clients industriels génèrent les données qui alimentent le modèle suivant, est éprouvé dans le logiciel; sa transposition à la robotique physique, avec ses contraintes de sécurité et de variabilité du monde réel, reste à démontrer à l'échelle. Generalist AI a été fondée en 2024 par Pete Florence (CEO), Andy Zeng (Chief Scientist) et Andrew Barry (CTO), trois chercheurs issus des milieux académiques et industriels de la robotique. La startup s'inscrit dans un marché en forte compétition: Physical Intelligence avec son modèle Pi-0, Figure AI avec le Figure 03, Boston Dynamics, Apptronik et 1X Technologies ciblent tous le même segment des modèles d'IA généralistes pour robots physiques. En Europe, Enchanted Tools et Wandercraft progressent sur des verticales plus ciblées. Avec cette levée, Generalist AI prévoit d'accélérer le développement de modèles de nouvelle génération, d'étendre son infrastructure d'entraînement et de renforcer son moteur de collecte de données physiques. La prochaine étape observable sera la documentation de déploiements industriels concrets chez des clients identifiés, seul critère qui permettra de distinguer les performances en laboratoire de la viabilité commerciale annoncée.

💬 500 millions en deux ans, c'est du sérieux. Ce qui m'intéresse vraiment, c'est pas le chèque, c'est cette histoire d'une heure de données par compétence apprise (contre des semaines pour les intégrateurs actuels). Si ça tient en conditions industrielles, tu changes complètement l'économie du déploiement robotique, mais tous les chiffres sortent de chez eux sans validation externe, donc faut voir les premiers clients réels avant de s'emballer.

Amazon déploie son assistant shopping IA chez les enseignes, dont Kate Spade

Amazon commercialise désormais sa technologie d'assistant shopping par intelligence artificielle auprès d'autres enseignes de distribution, via un nouvel outil baptisé Agentic Shopping Assistant, construit sur AWS. Kate Spade, filiale du groupe Tapestry, figure parmi les premiers retailers à l'adopter, en déployant un "AI Gift Concierge" capable de guider les clients dans leurs achats cadeaux via une interface conversationnelle. Selon Amazon, plus de 300 millions de clients ont utilisé son propre assistant shopping l'année dernière, générant près de 12 milliards de dollars de ventes incrémentales. La société affirme que les enseignes peuvent déployer ces agents conversationnels "en quelques semaines" plutôt qu'en plusieurs années si elles partaient de zéro. L'offre comprend une architecture technique, du code prêt à l'emploi, et un accompagnement par des experts AWS et des intégrateurs partenaires. Le système repose sur Amazon Bedrock pour les applications d'IA générative, AgentCore pour l'orchestration des agents, et OpenSearch pour la recherche et la récupération de données. L'enjeu commercial est significatif : Amazon indique que les sessions de shopping conversationnel génèrent des taux de conversion 3,5 fois supérieurs aux recherches traditionnelles par mots-clés. Pour Kate Spade, l'assistant cible précisément le moment d'achat cadeau, un contexte que 53 % des consommateurs jugent stressant selon les données internes d'Amazon. Fabio Luzzi, directeur des données et de l'analytique chez Tapestry, a expliqué que l'outil est né d'une écoute directe des consommateurs. Le groupe a testé l'assistant pendant environ deux mois et demi avant de le rendre accessible au grand public. En offrant cette technologie clé en main à d'autres retailers, Amazon transforme ses infrastructures IA en service commercial à part entière, potentiellement accessible à n'importe quelle marque dotée d'un budget AWS. Ce lancement s'inscrit dans une accélération plus large de la stratégie IA d'Amazon. En mai 2026, la société avait déjà déployé Alexa for Shopping aux États-Unis, permettant aux utilisateurs de poser des questions d'achat directement dans la barre de recherche Amazon et d'obtenir des réponses conversationnelles. Cette fonctionnalité fusionne Rufus, l'assistant shopping lancé en 2024, et Alexa+. En externalisant cette technologie via AWS, Amazon cherche à s'imposer comme la couche d'infrastructure IA du commerce en ligne mondial, face à des concurrents comme Google Shopping ou les solutions propres développées par de grands retailers. La question centrale pour l'industrie est désormais de savoir si ce modèle d'assistant conversationnel deviendra la norme d'expérience d'achat en ligne, et dans quelle mesure Amazon captera une part des transactions réalisées sur des sites tiers.

💬 Le playbook AWS, version shopping : tu bâtis une infra pour toi, ça marche, tu la revends à tout le monde. Les 3,5x de conversion, bon, c'est Amazon qui le dit, mais même à moitié ça reste sérieux. Kate Spade c'est juste le logo de lancement, dans six mois c'est la moitié du retail mondial qui tourne sur un agent Bedrock sans le savoir.

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

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

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

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

Baz améliore la précision de la revue de code par agents IA grâce à Amazon Bedrock AgentCore

Baz, une startup spécialisée dans l'automatisation des revues de code, a développé un agent IA capable de vérifier non seulement la qualité technique du code, mais aussi sa conformité aux spécifications produit et aux maquettes de design. Baptisé Spec Review Agent, ce système repose sur Amazon Bedrock et Amazon Bedrock AgentCore, les services d'IA managés d'AWS. Concrètement, l'agent s'active automatiquement à l'ouverture d'une pull request GitHub, interroge simultanément Figma pour récupérer les spécifications visuelles et Jira pour les exigences fonctionnelles, puis décompose l'ensemble en critères vérifiables. Il spawne ensuite des sous-agents parallèles, un par exigence, qui analysent le code source et interagissent avec l'environnement de prévisualisation via l'outil AgentCore Browser Tool, capable d'inspecter le DOM, de simuler des interactions utilisateur et de comparer visuellement l'interface rendue avec les maquettes Figma. L'enjeu est considérable pour les équipes de développement modernes. Jusqu'ici, la vérification qu'une fonctionnalité correspondait réellement à ce que le product owner avait demandé ou que le designer avait conçu reposait entièrement sur des tests manuels effectués par des équipes QA. Ces vérifications prenaient des heures, introduisaient des incohérences d'une release à l'autre et s'appuyaient sur une connaissance interne non documentée et donc fragile. En automatisant cette couche de validation, Baz cherche à supprimer le délai systématique entre la livraison du code et la détection des écarts, réduisant ainsi les régressions et accélérant les cycles de mise en production. Pour les équipes engineering qui travaillent à haute vélocité, c'est potentiellement une transformation profonde du workflow de review, qui passe d'une vérification de syntaxe à une validation de comportement réel. Ce projet s'inscrit dans une tendance plus large d'industrialisation des agents IA dans le cycle de développement logiciel, après l'émergence des assistants de génération de code comme GitHub Copilot. Amazon Bedrock AgentCore, lancé récemment par AWS, propose des primitives spécifiquement conçues pour l'orchestration d'agents multi-étapes en production, incluant la navigation web autonome, la gestion de la mémoire et l'exécution de code dans des environnements isolés. Baz exploite ces capacités pour bâtir une infrastructure d'orchestration déployée sur Amazon EKS, avec un Application Load Balancer en entrée. La prochaine étape logique pour ce type de système sera d'étendre la couverture au-delà des critères d'acceptation Jira et des maquettes Figma, vers des dimensions comme la performance ou l'accessibilité, transformant progressivement la revue de code en audit produit complet piloté par l'IA.

IA d’entreprise : Snowflake et Anthropic renforcent la gouvernance des modèles IA

Snowflake et Anthropic ont annoncé le 2 juin 2026, lors du Snowflake Summit 2026, un renforcement significatif de leur partenariat autour de l'IA d'entreprise. Concrètement, les modèles Claude d'Anthropic s'intègrent désormais plus profondément dans Snowflake Cortex AI, notamment pour alimenter Snowflake Cortex Code et Snowflake Intelligence. L'objectif est de permettre aux organisations de déployer des agents IA directement dans leur environnement de données existant, sans avoir à externaliser ou déplacer des données sensibles. Des entreprises comme Block, Indeed, Carvana, Notion ou eSentire utilisent déjà cette combinaison en production. Christian Kleinerman, EVP Product chez Snowflake, a indiqué que Snowflake Cortex Code serait devenu le produit à la croissance la plus rapide de toute l'histoire du groupe. L'enjeu central de ce partenariat est la gouvernance : les entreprises des secteurs réglementés, finance, santé, cybersécurité, retail, ne peuvent pas déployer l'IA sur des données critiques sans garanties fortes en matière de sécurité, de conformité et de traçabilité. En combinant la couche de gouvernance et de contrôle d'accès de Snowflake avec les capacités de raisonnement de Claude, les deux groupes proposent une architecture où le modèle devient une extension native de la plateforme data de l'entreprise plutôt qu'un outil externe. Cela change concrètement le profil de risque de l'IA générative pour les décideurs : Block automatise ainsi des workflows de conformité pour Square et Cash App, eSentire automatise des analyses SOC de niveau 1 pour libérer ses analystes humains des tâches répétitives, et Carvana optimise ses opérations logistiques et financières grâce à cette architecture. Ce renforcement s'inscrit dans la continuité d'un accord élargi signé fin 2025, qui avait déjà permis l'intégration native de Claude dans Cortex AI sur les principaux clouds. Le marché de l'IA d'entreprise est en train de basculer d'une phase d'expérimentation vers des déploiements opérationnels à grande échelle, et plusieurs acteurs, Microsoft avec Azure OpenAI, Google avec Vertex AI, AWS avec Bedrock, se livrent une concurrence intense pour capter cette demande. Snowflake, en tant que plateforme data indépendante du cloud, joue une carte différente : celle de la neutralité et de la gouvernance centralisée. Anthropic, de son côté, accélère sa distribution en entreprise via des partenariats stratégiques plutôt que par une offre cloud propriétaire. Les prochaines étapes du partenariat devraient porter sur l'extension de Claude Marketplace au sein de l'écosystème Snowflake, ouvrant la porte à un modèle de distribution plus large pour les modèles d'Anthropic dans les environnements data d'entreprise.

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

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

Créez une suite de tests évolutive pour votre agent avec la gestion de datasets dans Amazon Bedrock AgentCore

Amazon a annoncé une fonctionnalité de gestion de jeux de données dans Amazon Bedrock AgentCore, conçue pour stabiliser l'évaluation des agents d'intelligence artificielle. Le principe repose sur la constitution de jeux de tests versionnés : chaque scénario contient une entrée, une sortie attendue, des assertions à vérifier et la séquence d'outils que l'agent doit appeler. Ces jeux de données sont d'abord éditables dans un état brouillon, puis publiés en versions numérotées immuables. Une fois verrouillée, une version ne peut plus changer, ce qui garantit que deux évaluations successives comparent exactement les mêmes entrées. Lorsqu'un bug survient en production, la trace fautive est capturée et intégrée définitivement au jeu de test, de sorte que toute modification future de l'agent sera systématiquement confrontée à ce cas limite. L'enjeu est de taille parce que les agents LLM sont non-déterministes par nature : la même requête peut produire des réponses différentes d'une exécution à l'autre. Sans entrées stables, il est impossible de distinguer une vraie amélioration de l'agent d'une simple variation statistique du modèle. Par ailleurs, un juge LLM peut apprécier si une réponse semble pertinente, mais il ne peut pas vérifier si un cours boursier est exact, si une séquence d'appels d'outils s'est déroulée dans le bon ordre, ou si des données personnelles ont fuité entre deux sessions. Seule la vérité terrain, c'est-à-dire la réponse attendue et les assertions explicites, transforme un score subjectif en mesure vérifiable. C'est précisément ce que les datasets versionnés apportent : stabilité des inputs et ancrage dans le réel. La fonctionnalité répond à deux cycles de travail distincts dans le développement d'agents. Le premier est la boucle courte du développeur, qui modifie un outil, relance une évaluation et observe le score en quelques minutes : sans jeu de tests stable en dessous, une amélioration du score peut simplement signifier que les questions sont devenues plus faciles. Le second est la pipeline CI/CD, qui doit valider chaque changement avant déploiement. La plupart des équipes ont ce verrou, mais peu disposent d'un socle de scénarios versionnés avec assertions explicites, ce qui signifie qu'un pipeline peut valider une build simplement parce que les questions ont changé, ratant les régressions réelles. En ancrant les deux boucles sur le même dataset publié, Amazon Bedrock AgentCore vise à faire du score qui convainc le développeur en local le même score que celui que surveille la CI en production.

AWS SMGS transforme sa gestion commerciale avec un assistant conversationnel IA sur Amazon Bedrock AgentCore

Amazon Web Services a déployé en interne un assistant conversationnel basé sur l'intelligence artificielle, baptisé NarrateAI, pour transformer la façon dont les dirigeants de son organisation SMGS (Sales, Marketing and Global Services) accèdent aux données métier. Développé sur Amazon Bedrock AgentCore et accessible via l'interface Amazon Quick, l'outil permet à tous les niveaux hiérarchiques, du PDG aux équipes terrain, de poser des questions en langage naturel sur la performance commerciale et d'obtenir des réponses immédiatement exploitables. L'architecture repose sur deux couches distinctes : une couche de traitement par lots qui génère en amont des narratives personnalisées par utilisateur à partir de requêtes SQL paramétrées sur Amazon Redshift, et une couche temps réel qui répond aux questions de manière conversationnelle. AWS Lambda transforme les données extraites en JSON structuré, tandis que des templates Jinja les restituent en textes lisibles. Le recours à Bedrock AgentCore a permis de réduire le délai de déploiement de plusieurs mois à quelques semaines, en évitant de construire une infrastructure d'orchestration sur mesure. L'enjeu concret est significatif : les dirigeants AWS consacraient auparavant plusieurs heures à préparer manuellement leurs revues métier, en naviguant entre de multiples tableaux de bord et en réconciliant des sources de données disparates. NarrateAI supprime cette friction en livrant des analyses contextualisées à la demande, sans intermédiaire. Les équipes de reporting ne sont plus un goulot d'étranglement, et les décisions stratégiques peuvent être prises sur la base de données fraîches plutôt qu'en attendant des rapports consolidés. Pour une organisation de la taille d'AWS SMGS, qui opère à l'échelle mondiale sur des hiérarchies complexes, cette capacité à accéder instantanément à une vue unifiée de la performance représente un avantage opérationnel direct sur la réactivité des décisions commerciales. Ce projet s'inscrit dans une tendance de fond chez les grandes entreprises tech qui cherchent à remplacer la business intelligence traditionnelle, fondée sur des dashboards statiques, par des interfaces conversationnelles pilotées par des agents IA. Amazon Bedrock AgentCore, le service serverless d'AWS pour l'orchestration d'agents, est ici utilisé en interne avant d'être commercialisé auprès des clients, une stratégie classique chez AWS qui consiste à "dogfooder" ses propres services. La publication de ce retour d'expérience détaillé, incluant les patterns d'ingénierie et les choix architecturaux, vise clairement à convaincre les entreprises clientes d'adopter la même stack. Alors que les concurrents comme Microsoft et Google avancent eux aussi sur les agents IA d'entreprise, AWS positionne NarrateAI comme une vitrine de ce qu'il est possible de construire rapidement et en production avec Bedrock AgentCore.

Paiements par agents autonomes : exploration technique d'AgentCore

Amazon a lancé en avant-première AgentCore Payments, un nouveau service managé intégré à Amazon Bedrock AgentCore, conçu pour permettre aux agents d'intelligence artificielle d'effectuer des paiements autonomes en temps réel. Le service prend en charge les stablecoins pour des microtransactions inférieures au centime, une API unifiée compatible avec les protocoles machine-à-machine comme x402, ainsi que des garde-fous de dépenses configurables permettant aux développeurs de fixer des budgets et des limites de transactions précises. Là où l'intégration de solutions de paiement tierces pour agents pouvait auparavant mobiliser plusieurs mois de développement, Amazon promet de réduire ce délai à quelques jours grâce à une abstraction complète de la complexité d'orchestration, de conformité réglementaire et d'observabilité. Ce lancement répond à un problème structurel qui freine l'essor des agents autonomes : lorsqu'un agent tente d'accéder à un service payant, une API ou du contenu sous abonnement, il se heurte à un mur. Les méthodes de paiement classiques comme les cartes bancaires imposent des frais fixes d'environ 0,30 dollar par transaction, ce qui les rend économiquement inviables pour des milliers d'appels valant chacun quelques fractions de centime. Sans solution native, chaque développeur devait câbler manuellement des portefeuilles tiers, gérer des comptes de facturation distincts chez chaque fournisseur et construire ses propres mécanismes de gouvernance financière. AgentCore Payments centralise tout cela en un seul appel API, rendant enfin viables les workflows d'agents qui consomment massivement des services externes à très faible coût unitaire. Ce service s'inscrit dans une tendance de fond qui redessine l'économie du web : le trafic automatisé généré par des agents dépasse désormais le trafic humain sur de nombreuses plateformes, poussant éditeurs, CDN et fournisseurs d'API à faire évoluer leurs modèles commerciaux vers du paiement à l'usage. Des protocoles comme x402 émergent pour standardiser les échanges financiers machine-à-machine, et les grands acteurs du cloud s'y positionnent en priorité. AWS, avec AgentCore, construit une infrastructure complète pour l'ère agentique, comprenant déjà la gestion de la mémoire, la sécurité et désormais les paiements. Si des milliards d'agents doivent opérer de façon autonome dans les prochaines années, la couche de paiement représente un maillon critique, et le premier à proposer un service managé mature dans ce domaine pourrait capturer une part substantielle de cette nouvelle infrastructure de l'économie numérique.

💬 Le problème des microtransactions pour agents, c'est le genre de mur qui tuait les workflows avant même de démarrer. Payer 0,30 dollar par transaction quand l'appel vaut un centième de centime, c'est mathématiquement mort, et jusqu'ici chaque dev bricolait ça en solo avec trois portefeuilles tiers et aucune gouvernance. AWS centralise tout ça proprement, enfin du concret, même si les devs européens vont devoir passer par la case MiCA avant de déployer.

Construire des systèmes multi-agents LangGraph serverless et scalables sur AWS avec Amazon Bedrock AgentCore

Amazon Web Services a présenté une architecture de référence pour déployer des systèmes multi-agents d'IA générative à grande échelle sur AWS, en combinant LangGraph, AWS Lambda, AWS Step Functions et les deux nouveaux services Amazon Bedrock AgentCore Memory et AgentCore Observability. L'approche repose sur une infrastructure entièrement serverless : les agents LangGraph sont packagés dans des conteneurs Docker exécutés sur Lambda, ce qui permet une montée en charge automatique sans gestion d'infrastructure. Pour illustrer le concept, AWS décrit un système concret de révision de campagnes marketing orchestrant trois agents spécialisés en parallèle, un agent "persona reviewer" qui évalue la résonance du contenu auprès de différents profils démographiques, un agent "validator" qui vérifie la conformité juridique et les chartes de marque, et un agent "finalizer" qui synthétise les retours en recommandations actionnables. Une interface React permet aux utilisateurs de télécharger leurs documents et de consulter les résultats en temps réel. Ce type d'architecture répond à un problème concret que rencontrent les entreprises en production : les agents IA performants en démo s'effondrent souvent sous la charge réelle, perdent le contexte entre les sessions et restent des boîtes noires difficiles à déboguer. AgentCore Memory résout la question de la mémoire en offrant à la fois un contexte conversationnel à court terme et une base de connaissances persistante entre sessions. AgentCore Observability capture quant à lui chaque invocation avec ses entrées et sorties LLM, la latence, et les métriques de chaîne d'outils sur l'ensemble des composants distribués. Pour les équipes en charge de systèmes critiques, c'est un changement de paradigme : il devient possible d'auditer exactement comment un agent a raisonné, quelle décision il a prise à quelle étape, et pourquoi. Cette publication s'inscrit dans une accélération visible chez AWS pour proposer une pile complète d'IA agentique cloud-native, face à la concurrence de Google (Vertex AI Agents) et Microsoft (Azure AI Foundry). LangGraph, développé par LangChain, s'impose progressivement comme standard de facto pour l'orchestration d'agents grâce à son modèle d'exécution en graphe orienté qui rend le flux de contrôle déterministe, parallélisable et conditionnel. L'intégration native avec Lambda et Step Functions est particulièrement stratégique pour les charges de travail "bursty" typiques des agents IA, où la demande est imprévisible et les coûts d'une infrastructure dédiée permanente seraient prohibitifs. La prochaine étape logique pour AWS sera d'étendre ces patterns à des workflows plus complexes impliquant des boucles de feedback humain et des agents à longue durée de vie, un segment encore largement inexploré en production.

De l'idée à l'application IA : créer des assistants de recherche intelligents avec Strands

Amazon Web Services a publié Strands Agents, un framework open source sous licence Apache 2.0 qui permet de construire un assistant de recherche IA fonctionnel en une trentaine de lignes de Python. L'outil s'appuie sur les modèles fondamentaux d'Amazon Bedrock pour doter les agents d'une capacité de raisonnement autonome, sans avoir à coder manuellement chaque étape logique. AWS affirme déjà utiliser Strands Agents en production dans plusieurs de ses propres services, notamment Amazon Q et AWS Glue. L'annonce s'accompagne de la présentation de Kiro, un environnement de développement intégré alimenté par l'IA, qui intègre un mécanisme d'extensions appelé "Kiro Powers" : plus de cinquante modules préconfigurés couvrant la conception, le déploiement, la sécurité et l'observabilité, installables en un clic. Le module Strands, par exemple, embarque la documentation du SDK, des guides de démarrage et les patterns d'API corrects pour que Kiro puisse générer des agents fiables dès le premier essai. L'enjeu est de taille pour les équipes de développement : orchestrer plusieurs appels d'API, gérer l'état des conversations et construire des agents capables de planifier leurs actions représentait jusqu'ici un chantier réservé aux spécialistes du traitement du langage naturel et des systèmes distribués. Strands Agents casse cette barrière grâce à une approche model-driven où c'est le LLM lui-même qui prend en charge la logique et l'enchaînement des outils, le développeur n'ayant plus qu'à fournir un prompt et une liste de fonctions décorées avec @tool. Le framework est agnostique en matière de fournisseur : il fonctionne avec Amazon Bedrock, Anthropic et OpenAI, et supporte des architectures allant du simple agent isolé aux réseaux multi-agents hiérarchiques. Les réponses en streaming temps réel le rendent particulièrement adapté aux interfaces interactives. Cette publication s'inscrit dans une offensive plus large d'AWS pour capter les développeurs dans l'écosystème d'agents IA, un marché en pleine structuration où Google, Microsoft et Anthropic proposent leurs propres frameworks et plateformes. En rendant Strands open source et en le couplant à un IDE maison, AWS mise sur l'effet de réseau et la fidélisation par les outils plutôt que par le seul accès aux modèles. La compatibilité native avec AWS Lambda et IAM Identity Center facilite le passage du prototype à la production sans réécriture, ce qui constitue un argument décisif pour les entreprises déjà ancrées dans l'écosystème cloud d'Amazon. Les prochaines étapes probables incluent l'extension de la bibliothèque de Kiro Powers par la communauté et l'intégration plus étroite de Strands avec d'autres services AWS d'analyse et d'automatisation.

Construire une solution d'observabilité d'entreprise pour Amazon QuickSight

Amazon Web Services propose une architecture de référence pour centraliser l'observabilité d'Amazon Q, sa plateforme d'IA générative d'entreprise. La solution, publiée par AWS, agrège les données opérationnelles issues de deux sources principales : les journaux CloudWatch Vended Logs, qui capturent les conversations, les retours utilisateurs, la consommation des agents et le stockage d'index, ainsi que les événements AWS CloudTrail, qui enregistrent toutes les actions effectuées par les utilisateurs et les services sur la plateforme. Ces données transitent via des filtres d'abonnement CloudWatch vers des flux Amazon Data Firehose, sont transformées par des fonctions AWS Lambda, puis stockées dans un data lake sécurisé sur Amazon S3. Le tout est chiffré au repos via une clé AWS KMS gérée par le client avec rotation automatique. Les équipes d'administration peuvent ensuite interroger ce lac de données avec Amazon Athena, visualiser les métriques dans un tableau de bord QuickSight, ou poser des questions en langage naturel à un agent conversationnel Amazon Q personnalisé. Le déploiement s'appuie sur AWS CDK et requiert Python 3.9 minimum, Node.js 20 et AWS CLI V2. Pour les organisations qui déploient Amazon Q à grande échelle, cette solution répond à un besoin concret : obtenir une vue unifiée de l'adoption, de la satisfaction des utilisateurs, des coûts et de la gouvernance depuis un seul tableau de bord. Sans cela, les données sont éparpillées entre plusieurs services AWS et deviennent rapidement inexploitables à l'échelle de centaines ou milliers d'utilisateurs. La protection des données sensibles est intégrée dès la collecte via des politiques de masquage dans CloudWatch, capables de détecter et anonymiser automatiquement des clés privées, informations financières, données personnelles ou de santé. AWS Lake Formation apporte en complément un contrôle fin des accès au niveau des tables et des colonnes. Amazon Q s'est imposé comme la réponse d'AWS au déploiement d'IA générative en entreprise, en intégrant dans un seul produit des espaces collaboratifs, des agents conversationnels, des flux automatisés, des outils de recherche et des capacités de business intelligence via QuickSight. Mais la croissance de ces déploiements a mis en évidence un angle mort : l'absence d'outil natif pour piloter l'usage à l'échelle. Cette architecture d'observabilité comble ce manque en s'appuyant entièrement sur des services AWS managés, sans infrastructure supplémentaire à maintenir. Elle s'inscrit dans une tendance plus large où les plateformes d'IA d'entreprise doivent désormais justifier leur ROI avec des métriques d'usage précises, répondre aux exigences d'audit réglementaire, et permettre aux directions métier de piloter les investissements IA en temps réel.

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

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

Intégration du serveur MCP AWS API avec Amazon Q via Amazon Bedrock AgentCore Runtime

Amazon Web Services a publié un tutoriel détaillant comment connecter Amazon Q, son assistant IA conversationnel, à l'ensemble de l'infrastructure cloud via une architecture combinant Amazon Bedrock AgentCore Runtime et le Model Context Protocol (MCP). Le dispositif s'appuie sur un serveur AWS API MCP pour transformer des requêtes en langage naturel en commandes AWS CLI exécutées directement dans l'environnement cloud. Concrètement, un ingénieur peut demander "Montre-moi toutes les instances EC2 actives dans us-east-1" et obtenir une réponse structurée sans mémoriser la syntaxe des API ni jongler entre plusieurs interfaces. L'authentification repose sur Amazon Cognito via un flux OAuth 2.0 et des tokens JWT, tandis que les commandes s'exécutent sous un rôle IAM à privilèges minimaux. La mise en place est estimée à 30 à 45 minutes, et le coût mensuel pour un utilisateur Enterprise effectuant environ 500 requêtes reste modeste. Ce type d'intégration répond à une friction bien documentée dans les équipes SRE et DevOps : les ingénieurs passent une part significative de leur temps à basculer entre la console AWS, la documentation CLI et les tableaux de bord des dizaines de services disponibles. Un diagnostic d'incident oblige à croiser manuellement les logs CloudWatch, l'état des instances EC2 et les politiques IAM dans des interfaces séparées. La planification de capacité nécessite des requêtes manuelles sur plusieurs services, et les audits de sécurité exigent des séquences d'appels API répétitives, longues à scripter. Avec cette architecture, une seule intégration réutilisable standardise l'accès de l'agent IA à tous les services AWS, tout en conservant une piste d'audit complète via CloudWatch pour les exigences de conformité. Cette solution s'inscrit dans la montée en puissance du Model Context Protocol, standard ouvert publié par Anthropic en novembre 2024 qui permet aux agents IA de se connecter à des outils externes de façon cohérente. AWS l'a intégré dans Bedrock AgentCore Runtime, sa couche d'orchestration pour agents IA, qui joue ici le rôle de passerelle sécurisée entre Amazon Q et le serveur MCP. L'utilisation d'Amazon Q requiert un abonnement Enterprise au niveau Professional minimum, ce qui cible en priorité les grandes organisations avec une infrastructure AWS significative. La démarche illustre une tendance plus large chez les hyperscalers : positionner leurs assistants IA internes comme interface unique pour opérer l'ensemble du stack cloud, réduisant la dépendance aux outils tiers tout en consolidant la chaîne de valeur autour de leurs propres services.

Amazon Bedrock AgentCore lève la limite de la fenêtre de contexte

Amazon Web Services a présenté une approche pour contourner la limite fondamentale des fenêtres de contexte des grands modèles de langage, en combinant Amazon Bedrock AgentCore Code Interpreter et le SDK Strands Agents. La technique repose sur les Recursive Language Models (RLM), introduits dans un article académique de Zhang et al. (arXiv:2512.24601), qui réorganisent radicalement la façon dont un modèle interagit avec des documents volumineux. Concrètement, plutôt que d'injecter l'intégralité d'un document dans le contexte du modèle, le système charge le document dans un environnement Python sandboxé persistant, puis orchestre des appels itératifs à des sous-modèles pour analyser des sections spécifiques. Les résultats intermédiaires restent stockés comme variables Python dans le sandbox, sans jamais encombrer la fenêtre de contexte du modèle racine. L'exemple illustratif est celui d'une analyse financière : comparer deux années de rapports annuels d'une même entreprise, soit 300 à 500 pages chacun, auxquels s'ajoutent les dépôts SEC et les rapports d'analystes, pour un total de plusieurs millions de caractères, impossible à traiter d'un seul tenant pour n'importe quel modèle existant. Cette avancée répond à deux échecs classiques des LLM face aux très longs documents. Le premier : la requête dépasse la fenêtre de contexte maximale et est simplement rejetée. Le second, plus insidieux : le document entre en contexte mais le modèle peine à tenir compte des informations situées en son milieu, un phénomène connu sous le nom de "lost in the middle". Les RLM contournent les deux en découpant le problème : un modèle racine génère du code Python pour naviguer et découper le document, tandis que des sous-LLM sont appelés ponctuellement pour les tâches de compréhension sémantique. Le résultat est une architecture sans limite théorique de taille de document, potentiellement transformatrice pour des secteurs comme la finance, le droit ou la recherche médicale, où l'analyse de corpus massifs est quotidienne. Le problème de la fenêtre de contexte n'est pas nouveau : les chercheurs et les ingénieurs y butent depuis l'émergence des LLM à grande échelle. Les solutions précédentes incluaient la recherche par similarité vectorielle (RAG), qui fragmente les documents en chunks et ne récupère que les passages pertinents, mais au prix d'une perte de cohérence globale. L'approche RLM se positionne comme une alternative plus puissante : le modèle racine explore activement le document comme un environnement, décide quelles sections méritent une analyse approfondie, et délègue ces tâches à des sous-modèles via une fonction llm_query() injectée dans le sandbox d'AgentCore. Ce dernier fonctionne en mode réseau PUBLIC, ce qui permet aux appels vers Amazon Bedrock de s'effectuer directement depuis l'environnement sandboxé. AWS s'appuie ici sur son infrastructure Bedrock pour proposer une solution intégrée, combinant orchestration, exécution de code et appels LLM dans un pipeline unifié, sans nécessiter d'infrastructure tierce.

Créer des agents d'automatisation de tableaux de bord propulsés par l'IA avec le NLP sur Amazon Bedrock AgentCore

Amazon Web Services a dévoilé une solution d'automatisation de tableaux de bord basée sur l'intelligence artificielle, combinant trois de ses services : Amazon Bedrock AgentCore, le framework Strands Agents et Amazon QuickSight. L'architecture repose sur un système multi-agents composé de trois entités spécialisées : un agent de découverte (Find Dashboard Agent) chargé d'explorer les tableaux de bord et leurs métadonnées, un agent de modification (Modify Dashboard Agent) qui exécute les changements de configuration et crée de nouvelles versions, et un agent orchestrateur qui route les requêtes en langage naturel vers les agents appropriés. Concrètement, un analyste peut saisir une instruction comme "Ajoute le champ 'lastname' au tableau de bord testing" et le système interprète, valide et déploie la modification de façon autonome, tout en conservant une version originale pour permettre un retour arrière si nécessaire. L'enjeu est significatif pour les équipes métier : là où les processus traditionnels imposent plusieurs jours d'attente, soumission d'une demande à l'IT, interprétation des besoins, navigation dans la documentation d'API, déploiement, cette approche réduit le délai à quelques secondes. Le modèle de langage Amazon Nova assure la classification des requêtes entre interactions conversationnelles simples et opérations techniques réelles. Les modifications sont validées contre les colonnes disponibles dans les datasets avant exécution, ce qui maintient les contrôles de sécurité et génère des pistes d'audit. Pour les entreprises dont les décisions dépendent de données fraîches et de visualisations actualisées, supprimer ce goulot d'étranglement entre l'expression d'un besoin et sa concrétisation dans un dashboard représente un gain opérationnel direct. Cette solution s'inscrit dans la dynamique plus large d'AWS de rendre Amazon Bedrock AgentCore accessible comme plateforme d'hébergement d'agents en production, sans gestion d'infrastructure. La mémoire de session intégrée (AgentCore Memory) maintient le contexte des conversations, tandis que le module d'observabilité enregistre les décisions des agents et trace les appels API, deux composantes critiques pour déployer des agents autonomes dans des environnements d'entreprise régulés. Le framework Strands Agents, orienté code-first avec intégration native aux services AWS, positionne AWS face à des concurrents comme LangChain ou AutoGen sur le terrain des orchestrateurs d'agents. La prochaine étape logique pour ce type de système serait d'étendre la couverture au-delà de QuickSight vers d'autres services de données, voire de permettre aux agents de proposer eux-mêmes des modifications pertinentes en détectant des anomalies dans les métriques surveillées.

Amazon SageMaker AI prend en charge l'API compatible OpenAI

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

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

Google lance une API d'agents gérés : déploiement simplifié, mais moins de contrôle sur l'exécution

Lors de Google I/O, Google a annoncé les Managed Agents dans son API Gemini, un service conçu pour réduire à un simple appel API ce qui nécessitait auparavant plusieurs semaines de travail d'infrastructure. Disponible en préversion via de nouveaux modèles personnalisés dans Google AI Studio, ce service s'accompagne du lancement du CLI Antigravity. Concrètement, avant même d'écrire le moindre agent, les équipes passaient des jours à configurer des environnements d'exécution, gérer des sandboxes et câbler l'infrastructure d'appels d'outils. Google promet désormais d'absorber toute cette complexité dans sa plateforme, en optimisant conjointement le modèle, le harnais d'exécution et le sandbox dans des environnements sécurisés entièrement gérés par Google. L'impact pour les équipes de développement est direct : en déléguant la couche d'exécution à Google, les développeurs peuvent se concentrer sur le comportement métier spécifique de leurs agents et itérer à un rythme radicalement différent. René Sultan, responsable chez Ramp, cité dans l'annonce de Google, résume ce basculement : le runtime d'agent passe désormais dans la plateforme, libérant les développeurs de la gestion du sandbox, de l'infrastructure et de la boucle d'exécution. Pour les entreprises qui démarrent avec les agents, cette proposition est séduisante. Elle supprime la plupart des obstacles au déploiement tout en conservant un contrôle sur le comportement applicatif. La concurrence s'intensifie sur ce segment précis du marché, ce qui accélère la maturité des outils disponibles pour tous. Ce mouvement s'inscrit dans une transformation plus large de l'architecture des systèmes multi-agents. Jusqu'à récemment, l'orchestration reposait sur des frameworks indépendants qui se plaçaient au-dessus du modèle, laissant aux équipes le contrôle du routage et de l'exécution. Cette couche est désormais absorbée par les plateformes elles-mêmes. Anthropic a adopté une approche différente avec ses Claude Managed Agents, en plaçant l'orchestration au niveau du modèle plutôt que sur une plateforme d'exécution séparée. AWS, via Bedrock AgentCore, propose pour sa part des harnais managés pour simplifier le déploiement initial. Google pousse vers une intégration verticale plus poussée, contrôlant l'ensemble de la pile. Ce choix n'est pas sans risques : Arie Trouw, fondateur et PDG de XYO, avertit que remplacer des services déterministes par des services probabilistes peut introduire des comportements imprévisibles pour les utilisateurs, voire de la corruption de données. Un rappel que l'enthousiasme autour des agents ne doit pas occulter les arbitrages fondamentaux entre contrôle, fiabilité et vitesse de développement.

💬 L'infra agent, c'était le vrai mur avant de démarrer. Des semaines à configurer des sandboxes, à câbler les appels d'outils, avant même d'avoir une ligne de logique métier qui tourne, et Google absorbe tout ça dans un appel API. Reste que troquer du déterministe contre du probabiliste pour gagner en vitesse de déploiement, ça va faire des dégâts chez quelques équipes qui n'auront pas lu les petites lignes.

AWS s'associe à fal, startup IA générative pour la création de contenu média, et devient son fournisseur cloud privilégié

fal, une startup californienne spécialisée dans la création de médias par intelligence artificielle générative, a annoncé avoir sélectionné Amazon Web Services (AWS) comme partenaire cloud privilégié. L'entreprise, valorisée à 4,5 milliards de dollars après une levée de fonds de 300 millions de dollars en Série D menée par Sequoia Capital, propose une plateforme unifiée donnant accès à plus de 1 000 modèles d'IA en production, des modèles propriétaires comme ChatGPT-Images-2.0 d'OpenAI ou Nano Banana Pro 2 de Google, jusqu'aux alternatives open source. Sa base d'utilisateurs dépasse les 2,5 millions de développeurs dans le monde, et ses clients entreprises incluent Canva, Adobe et Amazon MGM Studios. Les termes financiers de l'accord avec AWS n'ont pas été divulgués. Ce partenariat marque une étape importante dans la maturité du secteur de l'IA générative : l'enjeu n'est plus seulement de construire des modèles fondamentaux, mais de les déployer à grande échelle pour un usage commercial massif. fal joue un rôle comparable à celui de Stripe dans le paiement en ligne, abstraire toute la complexité d'infrastructure pour permettre aux développeurs de se concentrer uniquement sur l'expérience utilisateur. Grâce à AWS, la plateforme vise une disponibilité garantie à 99,99 %, avec la capacité d'absorber des millions d'appels API quotidiens. Pour les entreprises créatives et les équipes de développement, cela signifie un accès fiable et élastique à des capacités de génération d'images, vidéos, audio et contenu 3D, sans avoir à gérer soi-même des clusters GPU fragmentés. La montée en puissance de fal s'inscrit dans une transformation plus large de l'écosystème IA : à mesure que les modèles génératifs quittent le stade expérimental pour entrer en production, les infrastructures capables de tenir la charge deviennent un avantage concurrentiel déterminant. Avant ce partenariat, fal opérait sur plusieurs clouds simultanément, le fournisseur de stockage Tigris mentionnait une "flotte mondiale de GPU répartie sur de nombreux clouds", et la startup était également disponible sur le Google Cloud Marketplace depuis septembre 2025, sans que Google Cloud n'alimente pour autant son infrastructure GPU. En choisissant AWS comme couche de fiabilité et de distribution principale, fal se positionne pour capter la demande enterprise croissante en matière de génération de médias à l'échelle mondiale, dans un secteur où la course à l'infrastructure est désormais aussi stratégique que la course aux modèles.

Étendre la mémoire conversationnelle de Kiro CLI avec Amazon Bedrock AgentCore Memory

Amazon Web Services a présenté une solution pour doter Kiro CLI d'une mémoire conversationnelle persistante entre les sessions, en s'appuyant sur Amazon Bedrock AgentCore Memory. Kiro CLI est l'interface en ligne de commande qui permet aux développeurs d'interagir directement depuis leur terminal avec les agents IA de Kiro, l'IDE agentique d'AWS. Le problème résolu est concret : chaque nouvelle session repart de zéro, forçant le développeur à réexpliquer le contexte de son projet, ses préférences et ses conventions à chaque démarrage. La solution repose sur un serveur MCP (Model Context Protocol) personnalisé, open source et disponible sur GitHub, qui fait le pont entre Kiro CLI et le service managé Bedrock AgentCore Memory. Ce serveur expose trois catégories d'outils : des outils conversationnels pour stocker et retrouver l'historique par sujet ou période, des outils de supervision pour consulter les statistiques d'utilisation mémoire, et des outils d'administration pour supprimer des sessions ou des données ciblées. La récupération du contexte repose sur une stratégie à deux niveaux : une recherche sémantique via l'API retrievememoryrecords d'AgentCore Memory, avec repli automatique sur une correspondance directe dans les contenus bruts si le premier niveau n'a pas encore terminé son indexation. L'impact pour les équipes de développement travaillant sur des bases de code volumineuses est direct. Un développeur qui revient sur un projet après plusieurs jours n'a plus besoin de réexpliquer l'architecture, les contraintes métier ou ses préférences de style à l'agent IA : celui-ci retrouve automatiquement les sessions précédentes, identifiables par des formulations naturelles comme "hier soir" ou "la semaine dernière". Cette continuité de contexte réduit la friction cognitive et le temps perdu en répétition, deux freins majeurs à l'adoption productive des outils IA dans les workflows de développement au quotidien. Amazon Bedrock AgentCore Memory est un service entièrement managé lancé par AWS pour répondre à un besoin croissant dans l'écosystème des agents IA : la persistance de la mémoire à long terme. Jusqu'ici, les agents IA des IDEs et des outils de développement souffraient d'une amnésie structurelle entre les sessions, limitant leur utilité réelle sur des projets complexes et de longue durée. Le Model Context Protocol, standardisé par Anthropic, est devenu le mécanisme central d'extensibilité pour les agents IA, permettant à des services tiers d'exposer des capacités via une interface unifiée. AWS positionne ainsi AgentCore Memory comme une brique d'infrastructure réutilisable pour tout éditeur souhaitant ajouter de la mémoire à ses propres agents MCP-compatibles. La mise à disposition du code source en exemple sur GitHub signale une volonté d'adoption large, au-delà de Kiro, vers l'ensemble des clients AWS qui construisent des outils agentiques sur Bedrock.

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

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

Les puces IA d'Amazon commencent à séduire les développeurs face à Nvidia

Les puces Trainium d'Amazon commencent à séduire les développeurs d'intelligence artificielle, marquant une étape importante dans la stratégie du géant du cloud pour concurrencer Nvidia. Anthropic et OpenAI, qui ont conclu des accords d'investissement et d'infrastructure de plusieurs milliards de dollars avec Amazon, se sont déjà engagés à louer de grandes quantités de capacité Trainium, aussi bien les générations actuelles que futures. Des améliorations logicielles récentes ont en outre convaincu une demi-douzaine de développeurs plus modestes, selon des personnes qui utilisent ou travaillent avec ces puces, d'envisager de transférer davantage de leurs charges de travail vers cette architecture propriétaire d'AWS. Ce changement de perception est significatif pour l'industrie. Nvidia contrôle aujourd'hui plus de 80 % du marché des puces d'entraînement d'IA, ce qui lui confère un pouvoir de fixation des prix considérable. Si Amazon parvient à convaincre même une fraction des développeurs de basculer vers Trainium, cela pourrait réduire la dépendance structurelle de l'écosystème IA envers un seul fournisseur et faire pression sur les marges exceptionnelles de Nvidia. Amazon développe ses propres siliciums depuis plusieurs années, après le rachat d'Annapurna Labs en 2015. La stratégie repose sur l'intégration verticale : proposer des puces optimisées pour les services AWS, avec des prix potentiellement inférieurs à ceux des GPU H100 et H200 de Nvidia. L'adhésion d'acteurs aussi stratégiques qu'Anthropic, dans lequel Amazon a investi plus de 4 milliards de dollars, constitue à la fois une validation technique et un levier commercial pour attirer d'autres clients vers l'écosystème Trainium.

💬 Quand Anthropic et OpenAI "adoptent" Trainium, faut garder en tête qu'Amazon leur a mis des milliards sur la table, donc c'est une validation arrangée autant que technique. Ce qui compte vraiment, c'est la demi-douzaine de développeurs indépendants qui commencent à y basculer des workloads pour des raisons de coût, sans deal en arrière-plan. C'est ce signal-là qui a du poids.

Des évaluateurs personnalisés basés sur du code dans Amazon Bedrock AgentCore

Amazon a lancé les évaluateurs personnalisés basés sur du code dans Amazon Bedrock AgentCore Evaluations, une fonctionnalité permettant aux équipes de développement d'intégrer des fonctions AWS Lambda comme moteur d'évaluation pour leurs agents IA. Contrairement aux juges LLM classiques, ces évaluateurs produisent des résultats déterministes : le même input donne toujours le même score. Ils peuvent être utilisés en mode on-demand, comme porte de validation dans les pipelines CI/CD, ou en mode online pour scorer du trafic de production en temps réel. L'annonce a été portée par une équipe pluridisciplinaire incluant Stephanie Yuan, Lefan Zhang, Ritvika Pillai, Vivek Singh et plusieurs ingénieurs et chefs de produit d'AWS. Pour les entreprises des secteurs financiers et spécialisés, cette capacité répond à des exigences concrètes que les LLM-as-a-Judge ne couvrent pas bien. Un agent de veille de marchés financiers doit citer des cours boursiers dans une fourchette de tolérance configurable, respecter un workflow d'identification du courtier avant d'accéder aux profils clients, retourner des sorties d'outils conformes à un schéma JSON strict, et ne jamais exposer d'informations personnelles identifiables. Un LLM est sujet à des erreurs arithmétiques, peut coûter cher à chaque appel, et ne convient pas à la vérification de règles objectives. Un évaluateur en code appelle directement le système de référence, calcule l'écart de tolérance, et signale chaque anomalie avec une précision que même un écart de 0,1 % peut déclencher, un seuil qui peut influencer une décision de trading. Le lancement s'inscrit dans un problème plus large que rencontre l'industrie : la transition des agents IA du prototype vers la production. Un agent fonctionnel en démo peut, en conditions réelles, produire des données mal formées suite à un bug de parsing ou une panne d'API tierce, divulguer des données confidentielles par inadvertance, ou ne pas respecter l'ordre des appels d'outils requis par une politique interne. Amazon propose désormais quatre dimensions d'évaluation adaptées au code : la validation de schéma des réponses d'outils, la précision numérique par rapport à une source de référence, la conformité au contrat de workflow, et la détection de PII ou de secrets via des services externes comme Amazon Comprehend. Ces évaluateurs peuvent être combinés avec les évaluateurs intégrés d'AgentCore et fonctionnent indépendamment du framework agent utilisé en production. L'enjeu est de donner aux équipes un filet de sécurité déterministe là où les capacités linguistiques des LLM atteignent leurs limites.

Promptimus : améliorer automatiquement des prompts LLM déjà performants

Amazon Web Services a dévoilé Promptimus, une méthode d'optimisation automatique des prompts pour grands modèles de langage (LLM), destinée aux entreprises qui cherchent à améliorer des prompts déjà bien rodés sans repartir de zéro. La particularité du système repose sur une boucle d'itération en quatre étapes : il prend en entrée un prompt existant, un petit jeu de données JSONL de 20 à 50 exemples, et des métriques de performance définies par l'utilisateur. Trois agents IA spécialisés collaborent en coulisses, un analyseur de métriques, un agent de débogage et un agent de nettoyage de code, pour identifier précisément les points de défaillance, en diagnostiquer les causes profondes, et affiner chirurgicalement le prompt en conséquence. Le système inclut également un mode édition qui permet de modifier uniquement les parties défaillantes d'un prompt complexe, sans toucher à la logique métier qui fonctionne déjà. L'enjeu est considérable pour les entreprises. Dans les déploiements industriels, les prompts ne sont pas de simples instructions génériques : ils encodent des exigences légales précises, comme la conformité HIPAA pour les systèmes de santé, ou des règles de tolérance au risque pour les plateformes de trading financier. Ces prompts sont construits par des experts métier sur des semaines, voire des mois. Or, chaque fois qu'un fournisseur comme Anthropic, OpenAI, Google, Meta ou Alibaba sort un nouveau modèle, ces prompts soigneusement calibrés perdent en efficacité, les différences de comportement entre modèles suffisent à dégrader les performances. Promptimus est conçu pour être agnostique au modèle : il peut réoptimiser un prompt conçu pour un modèle source et l'adapter rapidement à un modèle cible, en comparant les résultats entre les deux. La difficulté sous-jacente que Promptimus cherche à résoudre est bien connue des équipes d'ingénierie prompt : les méthodes d'optimisation automatique existantes fonctionnent bien pour créer des prompts depuis zéro, mais peinent à améliorer ceux qui sont déjà excellents. Les suggestions génériques comme « sois plus créatif » ou « ajoute des exemples » n'ont aucun effet sur un prompt déjà optimisé, dont les marges d'amélioration restent très spécifiques et difficiles à cibler. Les scores scalaires comme retour d'information ne donnent aucune indication sur le pourquoi des échecs. Face à la cadence d'évolution des modèles fondamentaux, la reoptimisation manuelle est coûteuse et retarde l'adoption de modèles plus performants. Promptimus vise à industrialiser ce processus de migration, en automatisant entièrement l'analyse des métriques et la génération des points de contrôle de débogage via du code Python importable.

L'IA physique s'approche des usines à mesure que les entreprises testent des robots humanoïdes

La société britannique Humanoid s'apprête à déployer ses robots humanoïdes dans les usines de l'équipementier industriel allemand Schaeffler, avec un objectif de 1 000 à 2 000 machines installées sur les sites de production mondiaux du groupe d'ici 2032. Les premières livraisons sont prévues entre décembre 2026 et juin 2027 sur deux sites allemands : Herzogenaurach, où les robots s'occuperont de la manutention de cartons, et Schweinfurt, qui servira de terrain de test à plus grande échelle. En parallèle, Schaeffler deviendra fournisseur privilégié d'Humanoid pour ses actionneurs articulaires jusqu'en 2031, un contrat portant sur plus d'un million de pièces et couvrant plus de la moitié des besoins d'Humanoid pour ses plateformes humanoïdes à roues. Le montant total de l'accord n'a pas été divulgué. De son côté, la startup sud-coréenne RLWRLD collecte activement des données de mouvement auprès de travailleurs dans des hôtels, des entrepôts logistiques et des commerces de détail, notamment au Lotte Hotel Seoul, chez le groupe logistique CJ et dans des magasins de la chaîne japonaise Lawson, afin d'entraîner ses systèmes robotiques sur des gestes réels. Ces déploiements marquent une accélération concrète de l'IA physique dans les environnements industriels et de service, après des années de promesses restées au stade expérimental. La dextérité manuelle, identifiée comme priorité par les ingénieurs de RLWRLD, est au cœur des enjeux : les robots doivent reproduire des gestes précis comme plier des serviettes ou insérer un objet dans une boîte avant de la poser sur un tapis roulant. Pour Schaeffler, l'automatisation de tâches répétitives dans ses lignes de production représente un levier de compétitivité dans un contexte de pression sur les coûts industriels. Pour les startups comme Humanoid et RLWRLD, ces contrats valident leur modèle et leur permettent de financer le développement technologique à travers des déploiements réels. Le secteur se structure rapidement autour d'une échéance commune : 2028, année à laquelle plusieurs acteurs, dont RLWRLD, anticipent un déploiement à grande échelle des robots industriels. Hyundai Motor prévoit d'introduire des humanoïdes Boston Dynamics dans ses usines mondiales dès cette date, en commençant par son site de Géorgie. Samsung Electronics ambitionne quant à lui de transformer l'ensemble de ses sites de fabrication en "usines pilotées par l'IA" d'ici 2030, avec humanoïdes et robots spécialisés en production. Ces annonces suscitent l'inquiétude des syndicats sud-coréens, qui alertent sur les risques pour l'emploi et sur l'érosion des compétences techniques qualifiées. La Confédération coréenne des syndicats appelle gouvernement et employeurs à associer les travailleurs aux décisions, avant que le mouvement ne devienne irréversible.

💬 Après des années de prototypes qui trébuchent, on passe enfin à des bons de commande et des dates de livraison. Le détail qui compte chez Schaeffler, c'est qu'ils sont simultanément client d'Humanoid et fournisseur de leurs actionneurs, un deal croisé qui ancre vraiment la relation dans le long terme. 2028 comme horizon commun pour tout le secteur, on verra si les chaînes d'approvisionnement suivent le rythme.

Créer un système de traitement de documents financiers avec Pulse AI et Amazon Bedrock

Pulse AI et Amazon Bedrock s'associent pour proposer un pipeline de traitement intelligent des documents financiers complexes, ciblant les établissements bancaires, les fonds d'investissement privés et les grandes entreprises. Contrairement aux outils OCR traditionnels qui traitent les documents comme de simples images, la solution combine les modèles de langage visuels de Pulse avec des composants de machine learning classiques spécifiquement conçus pour comprendre la structure des documents financiers : bilans comptables, comptes de résultats, dépôts SEC, rapports de recherche et documents d'audit. Le résultat le plus concret : un lot d'environ 1 000 documents financiers complexes, qui nécessitait auparavant plusieurs jours de traitement, est désormais traité en moins de trois heures, produisant des sorties structurées et auditables prêtes pour l'analyse. La solution est déjà déployée chez Samsung, Cloudera, Howard Hughes, ainsi que dans plusieurs institutions financières du classement Fortune 500. L'enjeu est critique pour le secteur financier : une erreur OCR dans un bilan ou un tableau à cellules fusionnées ne reste pas isolée, elle se propage en cascade à travers les calculs interconnectés, faussant l'ensemble de l'analyse. Le pipeline Pulse-Bedrock extrait les données de façon structurée et sémantiquement consciente, puis utilise Amazon Bedrock pour affiner les modèles Nova d'Amazon sur ces données de haute qualité. L'organisation obtient ainsi un modèle de langage personnalisé, entraîné sur ses propres conventions financières, capable de traiter les nouveaux documents avec une compréhension spécifique à l'entreprise. La révision manuelle, qui prenait des jours, se réduit à quelques heures. Ce développement s'inscrit dans une course à l'automatisation documentaire dans laquelle les institutions financières investissent massivement, sous la pression de volumes croissants de rapports réglementaires et de due diligence. Amazon Bedrock se positionne ici comme infrastructure de fine-tuning clé en main, sans gestion d'infrastructure ML ni planification de capacité, ce qui réduit la barrière d'entrée pour les équipes sans expertise MLOps. Pour Pulse AI, ce partenariat valide son approche hybride vision-langage face aux acteurs OCR historiques comme ABBYY ou aux offres cloud génériques de Google Document AI et Azure Form Recognizer. La prochaine étape logique est l'extension à d'autres verticales documentaires lourdes, comme le juridique ou le médical, où les mêmes problèmes de structure complexe et de dépendances contextuelles se posent.

Affiner un LLM avec Databricks Unity Catalog et Amazon SageMaker AI

Amazon Web Services et Databricks ont publié un guide technique détaillant comment affiner des grands modèles de langage (LLM) en combinant Amazon SageMaker AI, Amazon EMR Serverless et Databricks Unity Catalog, le tout en maintenant une gouvernance stricte des données. L'architecture présentée repose sur un flux en quatre étapes : les données d'entraînement sont lues depuis une table gérée par Unity Catalog, prétraitées via un job EMR Serverless utilisant Apache Spark, puis utilisées pour affiner le modèle Ministral-3B-Instruct de Mistral AI via SageMaker AI Training. Les artefacts du modèle entraîné sont enfin réenregistrés dans Unity Catalog, avec traçabilité complète de la lignée des données. Les credentials OAuth sont stockés dans AWS Secrets Manager, et les données transitent exclusivement via Amazon S3 sans jamais contourner les contrôles d'autorisation d'Unity Catalog. Cette intégration répond à un problème concret qui touche les entreprises opérant dans des secteurs régulés : lorsque SageMaker accède directement aux objets S3 sans passer par Unity Catalog, la traçabilité des données disparaît. Impossible alors de savoir quelles données ont servi à entraîner quel modèle, ce qui constitue un risque de conformité majeur dans les environnements de production. En forçant tout accès à transiter par les API REST ouvertes d'Unity Catalog avec authentification OAuth, la solution préserve la visibilité complète sur la lignée des données, de la source brute jusqu'au modèle final enregistré. Cela permet aux équipes data de continuer à utiliser SageMaker AI Studio comme environnement d'orchestration et d'entraînement sans sacrifier les politiques de gouvernance centralisées imposées par les équipes de conformité. Ce guide s'inscrit dans une tendance plus large de l'industrie cloud : les hyperscalers et les éditeurs de plateformes de données cherchent à proposer des intégrations natives pour éviter que la flexibilité des services managés ne crée des angles morts réglementaires. Databricks, valorisé à 62 milliards de dollars lors de sa dernière levée de fonds en 2024, a fait de Unity Catalog le pilier central de sa stratégie de gouvernance des données et de l'IA, et multiplie les partenariats avec AWS pour que ses couches de contrôle s'appliquent même lorsque le calcul est délégué à des services tiers comme SageMaker ou EMR. Pour les entreprises qui ont standardisé sur Databricks pour la gouvernance tout en restant attachées aux services ML d'AWS, cette architecture offre un chemin viable pour affiner des LLM en production sans compromettre leurs obligations d'audit. La prochaine étape logique sera d'étendre ce patron à d'autres modèles et à des workflows d'inférence, pas seulement d'entraînement.

Conformité au règlement européen sur l'IA pour l'affinage de LLM sur Amazon SageMaker

Depuis le 2 août 2025, l'AI Act européen impose aux organisations qui affinent des grands modèles de langage (LLM) de mesurer précisément la quantité de calcul consommée, exprimée en opérations virgule flottante (FLOPs). L'enjeu est réglementaire : selon le volume de calcul utilisé, une entreprise peut basculer du statut d'utilisateur en aval, qui exploite un modèle existant, à celui de fournisseur de modèle à usage général (GPAI), avec des obligations légales beaucoup plus lourdes. Amazon Web Services a publié en réponse un outil open source, le Fine-Tuning FLOPs Meter, conçu pour s'intégrer directement dans les pipelines Amazon SageMaker AI. Le seuil de référence, dit "règle du tiers", est fixé à 3,3 x 10²² FLOPs par défaut, c'est-à-dire lorsque le calcul de pré-entraînement du modèle de base est inconnu ou inférieur à 10²³ FLOPs. Pour les modèles dont le pré-entraînement dépasse 10²³ FLOPs et dont le chiffre est documenté, le seuil devient 30 % du calcul original. À titre d'exemple concret, affiner Llama-3-70B, dont le pré-entraînement est estimé à au moins 1,5 x 10²⁴ FLOPs, déclenche un seuil de 4,5 x 10²³ FLOPs avant de devenir fournisseur GPAI. Ce changement réglementaire touche directement les équipes data et ML des entreprises européennes qui personnalisent des modèles pour des usages sectoriels, qu'il s'agisse de finance, de santé ou de services juridiques. Franchir le seuil oblige à fournir une documentation détaillée sur l'architecture du modèle, le processus d'entraînement et à respecter l'ensemble des obligations de transparence imposées aux fournisseurs GPAI, sous peine de sanctions. L'outil d'AWS permet de déterminer son statut de conformité avec un seul paramètre de configuration et génère automatiquement les documents d'audit nécessaires. Dans la pratique, la majorité des organisations appliquera le seuil par défaut, car les fournisseurs de modèles comme Meta ou Mistral ne publient pas toujours leurs FLOPs de pré-entraînement avec précision. L'AI Act, premier cadre réglementaire complet sur l'IA au monde, a progressivement élargi son périmètre depuis son adoption en 2024. La distinction entre utilisateur et fournisseur GPAI est au coeur des débats depuis que l'affinage à grande échelle s'est démocratisé grâce aux techniques comme LoRA ou QLoRA, qui permettent d'adapter des modèles de plusieurs dizaines de milliards de paramètres avec des ressources relativement modestes. Le seuil du tiers repose sur une analyse réglementaire selon laquelle consommer plus d'un tiers du calcul original transforme suffisamment le comportement du modèle pour créer, de fait, un nouveau système avec ses propres risques. Le positionnement d'AWS est stratégique : en intégrant la conformité directement dans son infrastructure managée, le cloud provider réduit la friction pour les entreprises européennes hésitant à adopter le fine-tuning par crainte des obligations légales.

💬 C'est le genre de truc qui va faire peur à plein d'équipes ML alors que la plupart n'ont rien à craindre : affiner un Llama-70B en LoRA sur quelques epochs, tu es encore très loin du seuil. Ce qui est malin chez AWS, c'est d'intégrer la conformité dans leur infra avant que les équipes légales des boîtes européennes leur bloquent le fine-tuning par précaution. Reste que si Meta ne publie pas ses FLOPs de pré-entraînement proprement, tout le monde travaille avec un seuil par défaut un peu arbitraire.

Claude sur AWS : toute la plateforme d'Anthropic

Anthropic a annoncé ce 11 mai 2026 que l'intégralité de sa plateforme Claude est désormais accessible directement depuis Amazon Web Services, sous forme de disponibilité générale. Concrètement, les clients AWS peuvent désormais utiliser l'ensemble des fonctionnalités de l'API Claude, Claude Managed Agents pour déployer des agents IA à grande échelle, exécution de code Python via API, recherche web intégrée, et un système de Skills permettant à Claude d'apprendre des comportements ou méthodes de travail spécifiques, sans quitter leur environnement cloud habituel. L'intégration couvre l'authentification IAM, la facturation unifiée AWS, les audits via CloudTrail, et un accès immédiat aux nouvelles fonctionnalités au fil de leur sortie. Jusqu'ici, plusieurs capacités avancées de Claude restaient réservées à l'API native d'Anthropic. Pour les équipes techniques en entreprise, le gain est avant tout opérationnel : plus besoin de gérer des systèmes parallèles de connexion, de facturation ou de permissions. Cette simplification réduit la friction à l'adoption et abaisse la barrière d'entrée pour les organisations déjà investies dans AWS. Anthropic précise toutefois que le traitement des données sur cette plateforme s'effectue en dehors de l'infrastructure AWS classique, une nuance importante pour les entreprises soumises à des contraintes strictes de souveraineté ou de conformité. Pour celles-là, Anthropic maintient une offre distincte via Amazon Bedrock, où AWS reste l'opérateur principal et les données demeurent dans l'infrastructure Amazon, deux positionnements qui ciblent deux profils d'entreprises différents. Cette annonce s'inscrit dans une bataille industrielle plus large où les plateformes cloud sont devenues les principales portes d'entrée de l'IA générative. OpenAI pousse ChatGPT Enterprise, Google multiplie les intégrations Gemini dans son écosystème, Microsoft verrouille ses capacités IA dans Azure, et Anthropic devait muscler son jeu pour ne pas rester un fournisseur de modèles sans ancrage infrastructure. Le partenariat entre Anthropic et Amazon, qui s'est matérialisé par un investissement massif d'Amazon dans Anthropic ces dernières années, trouve ici une nouvelle expression concrète. En intégrant Claude profondément dans AWS, Anthropic gagne en distribution et en crédibilité enterprise, tandis qu'Amazon renforce l'attractivité de son cloud pour les projets IA. La prochaine étape sera de voir si cette intégration accélère effectivement l'adoption de Claude dans les grandes organisations, ou si la question non résolue de la localisation des données freinera les déploiements dans les secteurs les plus régulés.

Amazon Nova Multimodal Embeddings au service de l'intelligence industrielle

Amazon a présenté Nova Multimodal Embeddings, un modèle disponible sur sa plateforme Bedrock capable de traiter simultanément du texte, des images et des pages de documents en les projetant dans un espace vectoriel commun. Concrètement, une requête textuelle peut désormais retrouver un schéma d'ingénierie, et inversement, une image peut servir de requête pour récupérer une spécification écrite, les deux modalités partagent le même système de coordonnées mathématiques. Pour démontrer l'intérêt du système, les ingénieurs d'Amazon ont construit un pipeline de recherche documentaire appliqué à des documents d'ingénierie aérospatiale, en l'évaluant sur 26 requêtes types et en comparant les résultats avec une pipeline classique basée uniquement sur du texte. Le modèle propose quatre niveaux de dimensions d'embedding configurables : 256, 384, 1 024 et 3 072, avec un mode spécifique appelé DOCUMENT_IMAGE conçu pour les pages à contenu mixte. L'enjeu est particulièrement critique pour les secteurs industriels comme l'aérospatial, l'automobile ou la fabrication lourde, où les documents techniques mêlent systématiquement du texte à des courbes de fatigue, des diagrammes CAO, des photographies d'inspection ou des cartographies thermiques. Un système de recherche purement textuel, même assisté d'OCR, rate ces informations visuelles : il peut mal interpréter les annotations sur un schéma en coupe, ignorer les relations spatiales dans un diagramme, ou rater une valeur de couple encodée graphiquement dans un plan d'ingénierie plutôt qu'écrite dans un paragraphe. Avec les embeddings multimodaux, le modèle traite l'image directement et génère un vecteur dans le même espace que le texte, ce qui permet, par exemple, de retrouver la section d'un schéma de turbopompe en posant simplement une question en langage naturel sur le type de roulements utilisés. Cette approche s'inscrit dans une compétition plus large entre les fournisseurs cloud pour dominer l'infrastructure des systèmes RAG (retrieval-augmented generation) d'entreprise. Amazon positionne Nova Multimodal Embeddings comme une brique native de Bedrock, couplée à Amazon S3 Vectors pour le stockage et la recherche de proximité, ce qui réduit la friction d'intégration pour les équipes déjà dans l'écosystème AWS. La capacité à unifier texte et image dans un même index vectoriel répond à un blocage réel pour les industries à forte documentation technique, où une fraction significative de la connaissance métier est piégée dans des visuels non interrogeables. Les prochaines étapes naturelles concerneront la prise en charge de vidéos et de documents multi-pages complexes, ainsi que l'extension à d'autres secteurs comme la médecine ou le droit, où les mêmes limites de l'OCR s'appliquent.

Miro utilise Amazon Bedrock pour améliorer le routage des bugs logiciels et réduire le délai de résolution de plusieurs jours à quelques heures

Miro, la plateforme de collaboration visuelle utilisée par plus de 95 millions d'utilisateurs dans le monde, a développé un système d'intelligence artificielle baptisé BugManager pour automatiser le tri et l'affectation des rapports de bugs à ses équipes d'ingénierie. Avant cette solution, une part significative des bugs manquait les délais internes de résolution, principalement à cause d'erreurs d'affectation et de multiples réassignations entre équipes. L'entreprise estimait ces dysfonctionnements à 42 années cumulées de productivité perdue chaque année. BugManager a été développé en partenariat avec l'équipe AWS Prototyping and Cloud Engineering (PACE) et s'appuie sur Amazon Bedrock, Amazon Nova Pro et Claude Sonnet 4 d'Anthropic. Le résultat est saisissant : six fois moins de réassignations entre équipes, et un temps de résolution réduit de plusieurs jours à quelques heures. L'impact est d'abord opérationnel : les développeurs passent moins de temps à gérer des tickets mal orientés et peuvent se concentrer sur la résolution réelle des problèmes. Pour une organisation comptant près de 100 équipes, chacune responsable d'une portion spécifique du produit, un mauvais routage engendre des investigations redondantes, de la frustration, et des retards visibles pour les utilisateurs finaux. En passant d'une logique de classification traditionnelle à une approche basée sur la génération augmentée par récupération (RAG), Miro s'affranchit également de la nécessité de réentraîner ses modèles à chaque réorganisation interne, ce qui représente un gain stratégique considérable dans un environnement où les équipes fusionnent, se créent ou évoluent régulièrement. Les approches précédentes de Miro reposaient sur des modèles fine-tunés comme BERT ou GPT, qui se dégradaient rapidement dès que la structure organisationnelle changeait, faute de données d'entraînement suffisantes pour les nouvelles configurations. BugManager adopte une architecture radicalement différente : lorsqu'un bug est soumis, le système commence par analyser les éléments non textuels (captures d'écran, enregistrements vidéo) via les capacités multimodales d'Amazon Nova Pro, puis enrichit le rapport via des bases de connaissances contenant des tickets Jira déjà résolus, des pull requests GitHub, de la documentation Confluence et des fichiers README. Claude Sonnet 4, via Amazon Bedrock, synthétise ensuite ces informations pour affecter le bug à l'équipe la plus pertinente, sans nécessiter aucun réentraînement. Cette approche "zero-training" représente une tendance de fond dans l'industrie : déléguer la classification complexe à des grands modèles de langage enrichis de contexte métier, plutôt que de maintenir des pipelines d'entraînement coûteux et fragiles.

Halliburton améliore la création de workflows sismiques avec Amazon Bedrock et l'IA générative

Halliburton, l'un des plus grands groupes de services pétroliers au monde, a développé en partenariat avec l'AWS Generative AI Innovation Center un assistant intelligent intégré à son logiciel Seismic Engine, une application cloud dédiée au traitement des données sismiques. Concrètement, la configuration d'un workflow de traitement nécessitait jusqu'ici la sélection et le paramétrage manuel d'environ 100 outils spécialisés, un processus long et exigeant une expertise pointue. Désormais, les géoscientifiques et data scientists peuvent décrire leurs besoins en langage naturel, et le système génère automatiquement les workflows exécutables correspondants. La solution repose sur Amazon Bedrock, Amazon Bedrock Knowledge Bases, le modèle Amazon Nova et Amazon DynamoDB. Techniquement, une application FastAPI déployée sur AWS App Runner reçoit les requêtes utilisateurs via une interface en streaming ; un routeur d'intention alimenté par Amazon Nova Lite détermine si la demande concerne la génération d'un workflow ou une question documentaire, puis redirige vers l'agent approprié. Pour la création de workflows, le modèle Claude d'Anthropic, accessible via Amazon Bedrock, sélectionne parmi 82 outils disponibles et produit des fichiers YAML directement exploitables. Les résultats du proof-of-concept font état d'une accélération allant jusqu'à 95 % du temps de création des workflows. Cet outil change fondamentalement le rapport des ingénieurs à un logiciel jusqu'ici réservé aux experts maîtrisant des dizaines de paramètres techniques. En rendant Seismic Engine accessible via une conversation, Halliburton élargit le cercle des utilisateurs capables de configurer des traitements sismiques complexes sans formation approfondie sur chaque outil. Pour l'industrie pétrolière et gazière, où l'interprétation des données de subsurface conditionne directement les décisions d'exploration et les investissements en milliards de dollars, réduire d'un ordre de grandeur le temps consacré à ces tâches représente un gain opérationnel considérable. La gestion du contexte conversationnel via DynamoDB permet en outre des échanges multi-tours, rendant possible l'ajustement itératif des workflows sans repartir de zéro à chaque interaction. Cette initiative s'inscrit dans un mouvement plus large d'adoption de l'IA générative dans les industries à forte intensité de données techniques, où les workflows complexes freinent depuis longtemps la productivité. Halliburton, qui opère dans plus de 70 pays, dispose d'une base d'utilisateurs pour laquelle chaque gain de temps sur l'analyse sismique se traduit directement en avantage concurrentiel. Le choix d'AWS comme partenaire reflète la domination du cloud américain dans les déploiements d'IA en entreprise, Amazon Bedrock servant de couche d'abstraction pour accéder à plusieurs modèles fondateurs, dont ceux d'Anthropic. La prochaine étape probable est le passage de ce proof-of-concept à une intégration production dans la suite Landmark DS365, potentiellement étendue à d'autres modules d'analyse de subsurface.

5 % d'utilisation GPU : le problème d'infrastructure IA à 401 milliards de dollars que les entreprises ne peuvent plus ignorer

Les entreprises ont dépensé des milliards pour sécuriser des GPU à tout prix, et la facture est désormais présentée. Selon Gartner, l'infrastructure IA représente 401 milliards de dollars de nouvelles dépenses en 2025, mais des audits terrain révèlent une réalité bien plus sombre : le taux d'utilisation moyen des GPU en entreprise stagne à 5 %. Pendant deux ans, la panique du « GPU scramble » a poussé DSI et directions financières à constituer des réserves de capacité sous des cycles d'amortissement de trois à cinq ans. Ces actifs sont désormais des coûts fixes inscrits aux bilans, indépendamment de leur usage effectif. Les chiffres du Q1 2026 confirment le basculement : dans le baromètre de VentureBeat, le critère « accès aux GPU » est passé de 20,8 % à 15,4 % en un seul trimestre comme moteur principal des décisions d'achat, tandis que le coût par inférence et le TCO (coût total de possession) bondissaient de 34 % à 41 %, dépassant la performance pure comme critère dominant. À 5 % d'utilisation, l'arithmétique est brutale : pour chaque dollar investi en silicium, 95 centimes partent directement dans la marge des fournisseurs cloud. Dans n'importe quel autre département, un taux de gaspillage de 95 % serait un motif de licenciement ; dans l'infrastructure IA, on appelait ça de la « préparation ». Les grands groupes comme Intuit, Mastercard ou Pfizer, qui bénéficiaient de relations privilégiées avec AWS, Azure et GCP pour sécuriser des réservations de capacité, se sont retrouvés riches en GPU mais pauvres en production : des équipes internes paralysées par la gouvernance des données, la gravité des données et une immaturité architecturale persistante ont empêché toute valorisation réelle de ces ressources. Le discours dominant sur la rareté du silicium a servi d'écran commode pour masquer cette inefficacité structurelle. Ce virage marque la fin de l'ère du chèque en blanc. Le passage à une tarification à l'usage en 2026 transforme les architectures héritées des phases pilotes, pensées avec des tokens en coûts fixes, en véritables passifs financiers. Les agents en contexte long et les pipelines de récupération complexes, construits quand les tokens étaient un coût noyé dans des licences forfaitaires, deviennent intenables sous une facturation mesuréé. L'inférence n'est plus un projet tactique : c'est un modèle économique stratégique dont les unités économiques sont, pour la plupart des entreprises, encore insoutenables. La question n'est plus de savoir si les investissements passés étaient justifiés, mais comment extraire un retour mesurable d'une infrastructure déjà déployée avant que les cycles d'amortissement ne l'emportent.

💬 5 % d'utilisation, c'est le genre de stat qui ferait renvoyer n'importe quel responsable infra dans un département classique. La panique du GPU scramble a servi de couverture : on achetait du silicium pour ne pas rater le train, sans se demander si les équipes data étaient capables d'en faire quelque chose. Le basculement vers le pay-as-you-go va transformer ces réserves en passifs, et ça va faire des dégâts.

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

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

Amazon Bedrock AgentCore Payments : les agents IA peuvent désormais effectuer des transactions, avec Coinbase et Stripe

Amazon a annoncé le 7 mai 2026 le lancement en préversion d'Amazon Bedrock AgentCore Payments, une nouvelle couche de fonctionnalités permettant aux agents d'intelligence artificielle d'accéder à des ressources payantes et de régler des transactions de manière autonome, en temps réel. Développée en partenariat avec Coinbase et Stripe, qui fournissent respectivement l'infrastructure de portefeuilles numériques et les rails de paiement, cette solution s'intègre nativement à la plateforme AgentCore d'AWS. Des entreprises comme Cox Automotive, Thomson Reuters et le PGA TOUR utilisent déjà AgentCore pour orchestrer des agents capables de raisonner et d'agir sur des flux de travail complexes. Avec cette annonce, ces mêmes agents peuvent désormais payer des flux de données en temps réel, des publications sous paywall, des serveurs MCP privés ou d'autres agents spécialisés, le tout au sein d'une seule boucle d'exécution. Les limites de dépenses sont configurées par session, et AgentCore gère l'authentification des identifiants, le cycle de vie des tokens et la négociation de protocoles de paiement comme x402, ACP ou MPP. Ce lancement représente un tournant concret pour les développeurs d'agents autonomes. Jusqu'ici, brancher un agent à des services payants exigeait de négocier des relations de facturation distinctes avec chaque fournisseur, de sécuriser les identifiants, de gérer la conformité réglementaire et d'écrire une logique d'orchestration sur mesure, soit plusieurs mois d'ingénierie avec des enjeux financiers réels à la clé. AgentCore Payments supprime cette friction : un agent de recherche financière peut payer à la volée un article de presse spécialisé ou un flux de données boursières, un agent de développement peut appeler un registre de packages privé ou un environnement d'exécution isolé sans que le développeur ait à câbler chaque relation commerciale manuellement. La gouvernance des dépenses et l'observabilité restent centralisées dans la même infrastructure que les autres actions de l'agent, ce qui réduit la surface d'erreur sur des flux qui, contrairement à une mauvaise réponse, déplacent de l'argent réel. Ce mouvement s'inscrit dans une tendance de fond : le déploiement à grande échelle d'agents capables non seulement de chercher et raisonner, mais aussi de consommer des services et d'effectuer des achats au nom des utilisateurs. Les premiers protocoles de paiement pour agents, notamment x402 d'Ethereum et d'autres standards émergents, restaient jusqu'ici expérimentaux et fragmentés. Amazon, en s'associant à Coinbase pour la couche crypto et à Stripe pour les paiements traditionnels, positionne AWS comme l'infrastructure centrale d'une économie agentique encore naissante. L'étape suivante annoncée est la capacité pour les agents de réserver des billets d'avion, des hôtels et d'effectuer des achats auprès de plateformes marchandes, ouvrant la voie à des agents commerciaux pleinement autonomes.

💬 Brancher un paiement dans une boucle d'agent, jusqu'ici c'était plusieurs mois d'ingénierie rien que pour les credentials et la conformité. AWS compresse tout ça en une ligne de config, avec Stripe pour le classique et Coinbase pour la couche crypto, et c'est là que ça devient vraiment pratique pour qui orchestre des flux complexes. Reste que quand un agent se plante sur une réponse ça coûte rien, sur une transaction c'est une autre histoire.

Sage et AWS veulent démocratiser l’IA agentique dans les PME

Sage et AWS ont annoncé lors du salon Sage Future à San Francisco un renforcement significatif de leur partenariat stratégique, centré sur l'IA agentique à destination des petites et moyennes entreprises. L'accord porte sur quatre axes concrets : le développement de logiciels financiers cloud enrichis par l'IA, l'intégration des solutions Sage Developer sur Amazon Bedrock AgentCore, la distribution via AWS Marketplace, et l'accélération des migrations des outils de bureau vers le cloud. Concrètement, les agents IA de Sage automatiseront des tâches financières critiques : comptabilité fournisseurs, gestion de trésorerie, paie et rapports de conformité. Steve Hare, PDG de Sage, a résumé la philosophie du projet : "L'IA représente une opportunité majeure pour les PME, mais son adoption dépend avant tout de la confiance, des outils disponibles et de la simplicité d'intégration." Pour les PME, ce partenariat représente un changement de paradigme potentiellement significatif. Aujourd'hui, beaucoup d'entre elles s'appuient encore sur des logiciels financiers installés localement, difficiles à maintenir et inadaptés à l'IA moderne. L'enjeu n'est pas simplement de gagner du temps sur des tâches répétitives : il s'agit de permettre aux dirigeants d'accéder plus rapidement à des données financières fiables pour prendre de meilleures décisions. Via AWS Marketplace, les solutions de Sage pourront être déployées directement dans les environnements que les clients utilisent déjà, sans friction technique supplémentaire. Julia White, directrice marketing d'AWS, estime que les entreprises en croissance "ne devraient plus avoir à choisir entre simplicité et puissance technologique." Ce rapprochement s'inscrit dans une tendance de fond : selon l'International Data Corporation, les dépenses mondiales en IA devraient progresser de 31,9 % par an entre 2025 et 2029. Le marché sort de la phase expérimentale pour entrer dans un déploiement opérationnel à grande échelle, mais les PME restent à la traîne face aux coûts de modernisation et à la complexité des migrations cloud. En combinant l'expertise de Sage dans les logiciels financiers pour PME avec l'infrastructure d'AWS et la puissance de Bedrock AgentCore, les deux groupes cherchent à abaisser ces barrières. Le modèle ouvre également une opportunité aux éditeurs indépendants partenaires de Sage, qui pourront développer des applications compatibles avec AgentCore et les distribuer via la marketplace d'AWS sans reconstruire une infrastructure commerciale de zéro, ce qui pourrait accélérer l'émergence d'un écosystème d'outils financiers agentiques dédiés aux PME.

💬 Sage est déjà dans les compta de milliers de PME françaises, c'est ça qui rend l'annonce intéressante. Pas besoin de convaincre quelqu'un de changer d'outil, juste de lui glisser des agents dans ce qu'il utilise déjà. Reste à voir si la promesse "simple à intégrer" tient quand c'est le comptable d'une menuiserie de 12 personnes qui s'y colle.

Déploiement rentable de modèles vision-langage pour la détection du comportement animal sur AWS Inferentia2

Tomofun, la startup taïwanaise à l'origine de la caméra connectée Furbo, a migré une partie de son infrastructure d'inférence IA des instances GPU Amazon EC2 vers des instances EC2 Inf2, propulsées par les puces AWS Inferentia2 conçues en interne par Amazon. Le système Furbo analyse en temps réel les flux vidéo provenant de centaines de milliers de caméras domestiques pour détecter des comportements animaux précis, aboiements, courses, activités inhabituelles, et envoyer des alertes instantanées aux propriétaires. Le modèle central est BLIP (Bootstrapping Language-Image Pre-Training), un modèle vision-langage compilé via le SDK Neuron d'AWS pour s'exécuter nativement sur Inferentia2. L'architecture déployée s'appuie sur deux couches d'Auto Scaling EC2 derrière un Elastic Load Balancer : la première traite les requêtes API, la seconde héberge les conteneurs d'inférence. Amazon CloudFront achemine les images des caméras vers ce pipeline, tandis que CloudWatch surveille la latence, le débit et les taux d'erreur en continu. La motivation principale de cette migration est économique. L'inférence toujours active à grande échelle est fondamentalement différente de l'entraînement : elle ne nécessite pas la puissance brute des GPU, mais exige une disponibilité permanente et un coût par requête minimal. En remplaçant une partie des GPU par des instances Inf2, Tomofun réduit significativement ses dépenses d'infrastructure tout en maintenant la précision et le débit du modèle. La transition a été conçue pour être transparente : l'API Furbo peut désormais router les requêtes vers des conteneurs GPU ou Inferentia2 sans modifier la logique d'alerte en aval ni l'expérience utilisateur. Cette flexibilité permet aussi d'ajuster dynamiquement le mix en fonction de la charge et des coûts, ce qui est particulièrement précieux pour un service dont le trafic fluctue selon les heures de la journée dans de nombreux fuseaux horaires. Cette initiative s'inscrit dans une tendance plus large du marché cloud : les grandes plateformes développent leurs propres puces d'inférence, Inferentia2 chez AWS, TPU chez Google, et les futures puces de Meta, pour offrir une alternative moins coûteuse aux GPU Nvidia dans les déploiements de production à grande échelle. Pour les entreprises gérant des millions de requêtes d'inférence quotidiennes sur des modèles de vision stabilisés, l'argument économique des accélérateurs spécialisés devient difficile à ignorer. Le cas Tomofun illustre concrètement ce compromis : conserver les GPU pour la flexibilité et les pics, tout en basculant la charge de base vers Inferentia2. Avec la prolifération des objets connectés embarquant de l'IA en périphérie, ce modèle hybride pourrait devenir la norme pour les acteurs du secteur de la "pet tech" et plus largement de l'IoT intelligent.