Aller au contenu principal
OutilsAWS ML Blog · 2 min de lecture

Comment TReNDS automatise l'analyse des causes racines avec Amazon Bedrock

Source originale ↗·

Le centre de recherche TReNDS (Center for Translational Research in Neuroimaging and Data Science), structure conjointe de Georgia State University, du Georgia Institute of Technology et d'Emory University, a détaillé dans un billet co-écrit avec Vitaly Omelchenko, membre de son équipe technique, l'architecture d'analyse automatisée des causes racines d'incidents qu'il utilise désormais en production. TReNDS héberge son infrastructure sur Amazon Web Services depuis 2019, avec des applications tournant sur Amazon EKS (Elastic Kubernetes Service) dont les journaux sont acheminés vers Amazon CloudWatch via l'outil FluentBit. Le nouveau système combine des filtres d'abonnement CloudWatch, des fonctions AWS Lambda, le kit de développement Strands Agents et le service Amazon Bedrock. Un filtre CloudWatch surveille en continu les journaux à la recherche de motifs d'erreur (ERROR, Exception, FATAL, CRITICAL) et déclenche automatiquement une fonction Lambda dès qu'une correspondance apparaît. Cette fonction exécute un agent Strands propulsé par un modèle de fondation hébergé sur Bedrock, qui enrichit l'erreur avec le contexte des journaux et le code source récupéré sur GitHub, puis publie une analyse structurée sur un sujet Amazon SNS transmis à l'équipe d'ingénierie.

Cette automatisation cible directement la partie la plus chronophage de la réponse aux incidents. Selon TReNDS, l'investigation manuelle d'une erreur simple prenait auparavant entre 15 et 30 minutes à un ingénieur, ouvrant CloudWatch Logs, lisant les traces de pile et retraçant mentalement le chemin d'exécution dans le code source ; pour des pannes complexes impliquant plusieurs services, le délai était nettement plus long. En confiant cette investigation à un agent capable de raisonner sur l'erreur, le code et son contexte, l'équipe espère réduire drastiquement le temps de résolution des incidents à mesure que le volume d'erreurs augmente avec la croissance de ses applications. Le choix architectural a aussi une dimension réglementaire : parce que TReNDS manipule des données de recherche liées à la santé potentiellement soumises à la loi américaine HIPAA, faire tourner l'analyse via Bedrock au sein du même compte AWS, sans envoi de données vers des points de terminaison externes, permet de garder les journaux et le code source dans un périmètre de conformité déjà maîtrisé.

Le déclencheur du projet est un constat classique en ingénierie : disposer d'alertes et de supervision permet de savoir qu'un système est en panne, mais pas d'en comprendre la cause. L'équipe de TReNDS a identifié que cette phase d'investigation, faite de lecture de traces et de code, correspondait exactement au type de tâche qu'un modèle de fondation doté des bons outils peut exécuter seul. Grâce au SDK Strands Agents, qui gère l'orchestration des appels d'outils, le modèle décide lui-même quand récupérer un fichier source, chercher une gestion d'erreur associée ou approfondir son analyse, sans chemin d'investigation prédéfini par les développeurs. Ce projet illustre une tendance plus large dans l'usage des agents IA pour l'automatisation des tâches de fiabilité applicative (SRE) et de réponse aux incidents en production.

Dans nos dossiers

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Amazon Nova Act automatise l'analyse concurrentielle des prix
1AWS ML Blog 

Amazon Nova Act automatise l'analyse concurrentielle des prix

Amazon a lancé Nova Act, un SDK open-source de navigation web conçu pour construire des agents capables d'automatiser des tâches complexes dans un navigateur via des instructions en langage naturel. Présenté comme un service AWS, Nova Act permet aux développeurs de structurer des automatisations en Python en combinant des commandes ciblées et une logique programmatique, tests, assertions, parallélisation par thread-pooling. Son cas d'usage phare : la surveillance automatisée des prix des concurrents dans le e-commerce, un domaine où des équipes entières passent encore des heures chaque jour à consulter manuellement des dizaines de sites rivaux, à relever des prix et à consolider ces données dans des tableurs. Le problème que Nova Act cherche à résoudre est réel et coûteux. Dans un environnement où les prix fluctuent plusieurs fois par jour, décider sur la base de données vieilles de quelques heures suffit à faire perdre des revenus ou à rater des opportunités. Les scripts traditionnels basés sur des sélecteurs CSS rigides cassent dès qu'un site concurrent modifie son interface, ce qui arrive constamment avec les promotions éphémères et les rotations de composants. Nova Act contourne ce problème grâce à une approche pilotée par le langage naturel, ce qui rend les agents plus résilients face aux évolutions de layout. L'impact dépasse le e-commerce : assureurs comparant des contrats, banques analysant des taux de crédit, agences de voyage suivant les tarifs de vols et d'hôtels, tous sont confrontés aux mêmes goulets d'étranglement. Amazon Nova Act s'inscrit dans une tendance de fond : la course des grands clouds à proposer des outils d'automatisation web capables de rivaliser avec des solutions comme Playwright ou Puppeteer, mais orientés vers des agents IA plutôt que vers de simples tests. AWS positionne Nova Act directement dans l'écosystème du "commerce agentique", un segment en pleine émergence où des agents autonomes prennent en charge des workflows multi-étapes, surveillance, mise à jour de catalogues, validation de contenus. En rendant le SDK open-source et en l'intégrant nativement à ses services cloud, Amazon cherche à attirer les équipes techniques qui construisent des pipelines de veille concurrentielle à grande échelle, tout en ancrant ces workloads dans l'infrastructure AWS.

UELes équipes e-commerce et retail européennes peuvent adopter Nova Act pour automatiser leur veille tarifaire concurrentielle, réduisant une charge manuelle coûteuse dans des secteurs comme la grande distribution, les assurances et le voyage.

OutilsOutil
1 source
Automatiser le tri et la priorisation de vos boîtes mail avec Amazon Bedrock
2AWS ML Blog 

Automatiser le tri et la priorisation de vos boîtes mail avec Amazon Bedrock

Amazon Web Services a publié un guide technique détaillant une solution d'intelligence artificielle destinée aux organismes du secteur public, en particulier aux collectivités locales britanniques, pour trier et prioriser automatiquement leurs courriels entrants grâce à Amazon Bedrock. Le système fonctionne ainsi : les messages électroniques sont déposés dans un espace de stockage Amazon S3, via Amazon Simple Email Service, une intégration tierce ou le SDK AWS. Chaque nouvel objet S3 déclenche une notification transmise à Amazon EventBridge, qui l'achemine vers une file d'attente Amazon SQS de type FIFO. Cette file est reliée, via EventBridge Pipes, à une machine à états AWS Step Functions, laquelle récupère le contenu du courriel puis interroge un modèle Amazon Bedrock, en l'occurrence Amazon Nova Pro, par le biais de l'API InvokeModel. Un prompt spécifique demande au modèle de classer chaque message selon le service municipal concerné (transports, aides sociales, taxe d'habitation, action sociale, gestion des déchets, environnement, informatique, protection de l'enfance, logement) et d'en évaluer le degré d'urgence, dans un format structuré. En cas d'échec de traitement, les messages sont redirigés vers une file d'attente de lettres mortes pour investigation. Cette automatisation répond à trois difficultés concrètes identifiées par AWS dans la gestion actuelle des courriels des collectivités. D'abord une crise des délais de réponse, avec des centaines de messages reçus chaque jour où les demandes urgentes se retrouvent noyées dans le flux général. Ensuite, un usage inefficace du temps des agents, qui consacrent des heures au tri manuel, un même message pouvant être examiné à plusieurs reprises par différents services avant d'aboutir au bon interlocuteur. Enfin, une évaluation de la gravité des demandes qui manque de cohérence d'un agent à l'autre. En automatisant ce triage, la solution vise à garantir que les dossiers urgents reçoivent une attention immédiate, tout en libérant le personnel administratif pour des tâches à plus forte valeur ajoutée dans le service aux citoyens. Cette initiative s'inscrit dans une tendance plus large d'adoption de l'IA générative par les administrations publiques, confrontées à des contraintes budgétaires et des effectifs limités alors que les attentes des usagers en matière de rapidité de traitement ne cessent de croître. AWS présente cette architecture comme une base de départ, conçue pour être adaptée et enrichie par les organismes qui l'adoptent plutôt que comme un produit fini. Le déploiement s'appuie exclusivement sur des services managés d'AWS, ce qui limite la charge d'exploitation pour des collectivités locales disposant rarement d'équipes informatiques dédiées à l'intelligence artificielle, tout en respectant les bonnes pratiques de sécurité recommandées pour le stockage de données sensibles sur Amazon S3, notamment le chiffrement et le principe du moindre privilège.

OutilsOutil
1 source
Détection des pannes et analyse des causes racines des agents IA avec Strands Evals
3AWS ML Blog 

Détection des pannes et analyse des causes racines des agents IA avec Strands Evals

Amazon a publié Strands Evals, un kit de développement Python conçu pour automatiser le diagnostic des pannes dans les agents IA en production. Disponible via pip install strands-agents-evals et compatible avec Amazon Bedrock, l'outil introduit un système de "détecteurs" capables d'analyser automatiquement les traces d'exécution d'un agent et d'identifier les causes racines des défaillances. Là où les évaluations classiques se contentent d'un score global, "l'agent a réussi 60 % de ses objectifs", Strands Evals descend au niveau de chaque étape individuelle (chaque "span") pour catégoriser les erreurs, mesurer leur gravité par un score de confiance, et retracer la chaîne causale qui a conduit à l'échec. Le pipeline fonctionne en deux phases pilotées par un LLM : une première phase de détection qui passe en revue neuf catégories de pannes (hallucination, mauvaise sélection d'outil, erreurs d'orchestration, non-conformité aux instructions, erreurs d'exécution, problèmes de gestion du contexte, comportements répétitifs, sorties LLM mal formées, et incompatibilités de configuration), puis une seconde phase d'analyse des causes racines qui classe chaque défaillance en primaire, secondaire ou tertiaire et génère des recommandations de correction ciblées. L'enjeu est directement opérationnel : lorsqu'un taux de succès chute de 85 % à 70 % après un déploiement, les ingénieurs passaient jusqu'ici des heures à inspecter manuellement des centaines de traces pour comprendre ce qui avait changé. Strands Evals promet de ramener ce diagnostic de plusieurs heures à quelques minutes. L'outil indique non seulement quelle étape a échoué, mais aussi si la correction doit porter sur le prompt système ou sur la définition des outils, une distinction qui évite des cycles d'itération coûteux. Pour les équipes qui opèrent des agents à grande échelle, intégrer ces détecteurs dans le pipeline d'évaluation automatisé signifie que chaque run de test produit désormais un diagnostic structuré, pas seulement un score. Ce lancement s'inscrit dans la montée en maturité de l'écosystème des agents IA autonomes, où l'observabilité devient aussi critique qu'elle l'est depuis longtemps dans le développement logiciel classique. Amazon Bedrock AgentCore fournit déjà des primitives de sessions, traces et spans ; Strands Evals se positionne comme la couche d'analyse au-dessus. La dépendance à Amazon Bedrock pour faire tourner les LLM d'analyse est une contrainte notable, les équipes utilisant d'autres fournisseurs devront adapter leur infrastructure. La prochaine étape logique pour l'écosystème sera d'étendre ces capacités de diagnostic à des frameworks d'agents tiers, alors que des acteurs comme LangChain, AutoGen ou CrewAI construisent leurs propres couches d'observabilité en parallèle.

OutilsOutil
1 source
Automatiser le triage des alertes anti-blanchiment avec Amazon Q et Snowflake Cortex AI
4AWS ML Blog 

Automatiser le triage des alertes anti-blanchiment avec Amazon Q et Snowflake Cortex AI

Amazon Web Services et Snowflake ont présenté une architecture conjointe permettant d'automatiser le traitement des alertes de lutte contre le blanchiment d'argent (LBA) dans les institutions financières. Lors de tests internes, le système construit sur Amazon Quick et Snowflake Cortex AI a réduit le temps d'investigation par alerte de 30 à 90 minutes à moins de 5 minutes. La solution repose sur le protocole MCP (Model Context Protocol), un standard ouvert qui permet à Amazon Quick Flows d'orchestrer des appels vers les agents Cortex de Snowflake sans connecteurs personnalisés, tout en maintenant une authentification OAuth. Concrètement, un analyste entre un identifiant d'alerte, et le système valide les données, interroge les transactions structurées via Cortex Analyst, fouille les documents de conformité via Cortex Search, puis génère automatiquement un rapport de disposition complet. L'enjeu est considérable pour les équipes de conformité des grandes banques : selon des études sectorielles, entre 90 et 95 % des alertes LBA sont des faux positifs. À raison de 30 à 90 minutes par alerte traitée manuellement, les départements compliance des établissements de taille moyenne à grande se retrouvent submergés de travail répétitif à faible valeur ajoutée. En automatisant la phase de triage, les deux plateformes permettent aux analystes de concentrer leur attention sur les cas réellement suspects, d'accélérer les délais réglementaires et de réduire les coûts opérationnels. La même logique d'orchestration peut s'appliquer à d'autres processus structurés similaires, comme le suivi des coûts cloud en FinOps, la gestion d'incidents pour les équipes SRE ou les enquêtes de conformité en général. Cette solution s'inscrit dans une tendance plus large de l'IA d'entreprise, qui évolue des simples assistants conversationnels vers des pipelines automatisés capables d'orchestrer plusieurs systèmes. Snowflake et AWS entretiennent déjà plus de 50 intégrations natives, incluant Amazon S3, AWS Glue, Amazon SageMaker et Amazon Bedrock. Amazon Quick, le service d'IA générative d'entreprise d'AWS, intègre désormais Quick Flows pour transformer des requêtes utilisateur en séquences d'appels standardisés sans code sur mesure. Le protocole MCP joue ici un rôle central en servant de langage commun entre les orchestrateurs et les agents spécialisés. À mesure que ces architectures se généralisent dans le secteur financier, la question n'est plus de savoir si l'IA peut automatiser la conformité, mais à quelle vitesse les institutions sauront déployer ces pipelines sur leurs propres infrastructures réglementées.

UELes banques et institutions financières européennes, soumises aux directives AMLD5 et AMLD6, pourraient déployer ce type de pipeline pour réduire leur charge de conformité et accélérer le traitement des alertes LBA réglementaires.

OutilsOutil
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic