Bluesight construit une solution IA à base d'agents avec Amazon Bedrock

Amazon Bedrock AgentCore Evaluations : construire des agents IA fiables

Amazon a lancé AgentCore Evaluations, un service entièrement géré intégré à Amazon Bedrock, conçu pour mesurer la performance des agents d'IA tout au long de leur cycle de développement. Le problème que ce service cherche à résoudre est bien documenté dans l'industrie : un agent fonctionne parfaitement en démo, convainc les parties prenantes lors des tests, puis échoue en production face à de vrais utilisateurs. Les symptômes sont prévisibles — mauvais appels d'outils, réponses incohérentes, comportements imprévus — mais leur détection systématique exige une infrastructure que la plupart des équipes n'ont pas. AgentCore Evaluations propose un cycle continu : construction de cas de tests, exécution sur l'agent, notation automatisée, analyse des échecs et amélioration itérative. Chaque échec devient automatiquement un nouveau cas de test, ce qui permet de fermer progressivement l'écart entre le comportement attendu et le comportement réel. L'enjeu est structurel : les grands modèles de langage sont non-déterministes. Une même requête peut produire des sélections d'outils différentes, des raisonnements distincts et des réponses variées d'un run à l'autre. Un seul passage de test ne dit pas ce qui se passe habituellement — il dit seulement ce qui peut arriver. Pour obtenir une image fiable du comportement d'un agent, il faut répéter chaque scénario plusieurs fois et agréger les résultats. Sans cela, chaque modification de prompt devient un pari : les équipes ignorent si leurs changements améliorent ou dégradent les performances, et brûlent des crédits API sans visibilité réelle. AgentCore Evaluations adresse précisément cette incertitude en fournissant des métriques de qualité sur plusieurs dimensions — exactitude des sélections d'outils, validité des paramètres, précision des réponses finales — pour le développement comme pour la production. Ce lancement s'inscrit dans une tendance plus large : la maturité des agents d'IA dépasse désormais la phase d'expérimentation et entre dans celle de l'ingénierie de fiabilité. Construire l'infrastructure d'évaluation en interne — curation de datasets, hébergement de modèles de scoring, gestion des limites de débit, pipelines de transformation des traces, tableaux de bord — représente un coût fixe considérable que les équipes multiplient pour chaque agent déployé. Amazon positionne AgentCore Evaluations comme la réponse cloud à ce problème, en absorbant cette complexité dans un service managé. La concurrence est vive : des outils comme LangSmith, Braintrust ou PromptFoo couvrent des besoins similaires, mais l'intégration native dans l'écosystème Bedrock donne à AWS un avantage naturel pour les entreprises déjà engagées sur sa plateforme. La prochaine étape logique sera de voir si le service s'étend aux agents multi-modaux et aux architectures multi-agents, deux domaines où l'évaluation reste un problème ouvert.

KTern.AI développe une IA à base d'agents pour SAP sur Amazon Bedrock AgentCore

Comment KTern.AI, plateforme de transformation digitale dédiée à SAP, a bâti son IA agentique sur Amazon Bedrock AgentCore en s'appuyant sur le kit Strands Agents SDK. KTern.AI est partenaire SAP Spotlight et opère une plateforme certifiée SAP de Digital Transformation as a Service, structurée autour de cinq automatisations : Digital Maps, Digital Projects, Digital Process, Digital Labs et Digital Mines. Son moteur propriétaire de connaissance institutionnelle encode des années de patterns de transformation SAP et de bonnes pratiques, permettant, combiné à une hyperautomatisation pilotée par la donnée, des transformations sept fois plus rapides avec une réduction de 24 % de l'effort global. Les nouveaux agents déployés orchestrent de façon autonome des workflows allant de la rétro-ingénierie à l'analyse de code, en passant par le fit-to-standard et le repérage d'exceptions dans les processus Finance et Ventes, sans que l'entreprise ait eu à construire une infrastructure d'agents sur mesure. Cette bascule change concrètement la donne pour les grands comptes engagés dans des migrations S/4HANA ou des conversions système, des projets qui s'étalent sur des mois voire des années et mobilisent une expertise SAP difficile à faire monter en échelle avec des consultants humains seuls. Avant AgentCore, KTern.AI faisait tourner son application sur une pile de conteneurs auto-gérée, développée et maintenue en interne, ce qui détournait du temps d'ingénierie vers de l'infrastructure sans lien avec son cœur de métier : concevoir des agents capables de comprendre la transformation SAP. En migrant vers AgentCore, l'entreprise a pu se recentrer sur cette différenciation tout en gagnant en fiabilité de production. Le passage à l'agentique posait plusieurs défis techniques qu'aucune infrastructure maison ne pouvait résoudre proprement. Il fallait un contexte persistant à grande échelle, les agents devant retenir un état sur des centaines d'interactions et bâtir un contexte cumulatif sur toute la durée d'un projet sans le perdre à chaque session, tout en évitant de les saturer d'informations superflues, ce qui ralentit les réponses, augmente les coûts et le risque d'hallucination. S'y ajoutaient l'accès sécurisé et gouverné aux API SAP, aux systèmes ERP clients et aux référentiels de processus via des connexions authentifiées et auditables, la multi-location avec une configuration propre à chaque client sans développement spécifique par déploiement, une scalabilité dynamique pouvant faire passer d'une poignée d'agents pour un audit rapide à des dizaines d'agents tournant en continu pendant des mois lors d'une migration complète, et enfin une observabilité de niveau production, avec logs, traces et métriques détaillés pour rendre traçable chaque décision d'agent et chaque appel d'outil dans des environnements d'entreprise.

💬 Reste à voir si l'infra managée tient vraiment la charge sur des migrations S/4HANA qui durent des mois, mais l'idée de fond est bonne : le vrai métier de KTern.AI c'est de comprendre SAP, pas de maintenir une stack de conteneurs. C'est un pattern qu'on va voir se généraliser chez tous les éditeurs verticaux, arrêter de réinventer l'orchestration d'agents pour se concentrer sur la donnée métier propriétaire. Le détail qui compte, c'est la gestion du contexte sur des centaines d'interactions sans saturer le modèle : c'est exactement le genre de problème qu'aucune boîte n'a envie de résoudre elle-même en interne.

Le Fil IA développe une couche sémantique pour l'IA à base d'agents sur AWS avec Stardog et Amazon Bedrock AgentCore

AWS et Stardog ont présenté une architecture technique permettant de déployer une couche sémantique pour des agents d'intelligence artificielle directement sur les infrastructures cloud d'Amazon, sans extraction, transformation ni chargement de données (ETL). Le dispositif repose sur l'application Semantic AI de Stardog, connectée simultanément à Amazon Aurora et Amazon Redshift, et pilotée par un agent Strands Agents hébergé sur Amazon Bedrock AgentCore. Concrètement, cet agent peut répondre à des questions dites de « vision client à 360 degrés » en interrogeant les deux bases de données en même temps, sans qu'un ingénieur ait besoin de dupliquer ou de fusionner préalablement les données. Le même déploiement Stardog fonctionne aussi derrière d'autres services de calcul AWS, comme Amazon EKS, Amazon ECS ou AWS Lambda. Le choix d'AgentCore s'explique par le fait que ce service regroupe en une seule solution gérée l'authentification des accès entrants, l'hébergement de l'agent et la gestion des identifiants pour les outils tiers. Cette annonce s'inscrit dans un mouvement plus large que les auteurs appellent « l'analytique agentique », prolongement logique de vingt ans d'évolution des outils décisionnels, des rapports programmés aux tableaux de bord, puis au libre-service analytique. Jusqu'ici, même les outils en libre-service dépendaient d'un modèle de données déjà construit par un ingénieur, l'analyste humain restant le point de passage obligé pour toute question sortant du cadre prévu. Les agents génératifs promettent de lever ce goulot d'étranglement en raisonnant directement sur les données en temps réel, en écrivant leurs propres requêtes et en les affinant de manière autonome. Pour les entreprises, l'enjeu est direct : accélérer l'accès à une réponse fiable sans multiplier les développements sur mesure, tout en évitant le piège des réponses incohérentes lorsque deux agents interrogent des sources différentes pour la même question métier. Le véritable obstacle, selon AWS, n'est plus la capacité des modèles de fondation disponibles sur Bedrock à planifier des tâches complexes ou à générer du SQL, mais la fragmentation des données d'entreprise elles-mêmes. Un « client » n'a souvent pas la même définition dans un système de gestion de la relation client (CRM) que dans un système de facturation, tout comme le « chiffre d'affaires » peut varier selon l'équipe qui le calcule. Sur AWS, ces données sont réparties entre Aurora et les bases RDS pour les données opérationnelles, Redshift pour l'historique analytique, et S3 combiné à Athena pour les données non structurées, notamment via des formats ouverts comme Apache Iceberg. La génération augmentée par récupération (RAG), utilisée via Amazon Bedrock Knowledge Bases, fonctionne bien pour retrouver des passages de texte, mais s'avère insuffisante dès qu'une question exige de croiser des enregistrements entre systèmes tout en respectant des règles métier et des politiques d'accès aux données, d'où l'intérêt d'une couche sémantique dédiée.

💬 Le vrai sujet, c'est pas AWS ni Stardog, c'est la fragmentation des données d'entreprise. Un agent qui écrit du SQL tout seul, on sait déjà faire. Un agent qui sait que "client" veut pas dire la même chose dans le CRM et dans la facturation, c'est ça le boulot, et c'est là que ça coince depuis toujours. Bon, sur le papier c'est élégant : zéro ETL, une couche sémantique qui interroge Aurora et Redshift en même temps. Reste à voir si ça tient quand deux agents posent la même question métier et sortent deux réponses différentes, parce que c'est exactement le piège que ce genre d'archi est censé éviter.

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.