Amazon dévoile une architecture d'analyse agentique fondée sur SageMaker, Athena et Quick

AWS a présenté une architecture dans laquelle l'assistant agentique Amazon Quick transforme l'analyse d'un lakehouse en self-service pour les équipes métier. Le schéma associe S3, SageMaker, AWS Glue et Athena afin que l'utilisateur puisse interroger les données en langage naturel plutôt que via SQL.

Comment fonctionne le schéma

Dans sa démonstration, AWS utilise le jeu de données TPC-H et bâtit dessus un lakehouse à plusieurs couches. Les données sont stockées dans Amazon S3, les métadonnées sont gérées par AWS Glue, et Amazon Athena sert de couche SQL unique pour interroger différents formats de stockage. L'exemple utilise simultanément des tables CSV externes classiques, des tables Iceberg en Parquet et des S3 Tables gérées.

Cette approche ne vise pas l'élégance architecturale : l'entreprise montre qu'une même question métier peut être adressée à des sources hétérogènes sans construire à la main des data marts pour chaque scénario.

Par-dessus, Amazon Quick assemble la couche utilisateur :

• des datasets dans SPICE pour des réponses et des tableaux de bord rapides
• Topic comme couche sémantique pour les termes métier
• un tableau de bord avec requêtes en langage naturel
• une Knowledge Base fondée sur la documentation et les spécifications
• Quick Space et un chat agent comme interface unique

Ce que fait l'agent

L'élément clé n'est pas un simple chat au-dessus de tables, mais l'association de Topic, Space et Knowledge Base. Topic joue le rôle de couche sémantique : il relie des formulations familières comme le chiffre d'affaires, le segment de clientèle ou le trimestre dernier à des champs, des dates et des filtres précis du dataset.

Dans Quick, les données sont d'abord chargées dans SPICE, si bien que les tableaux de bord et les réponses aux questions courantes devraient rester rapides même quand le lakehouse source grossit. Pour les gros jeux de données, AWS conseille de joindre les tables au préalable dans Athena via Custom SQL, puis de transmettre le résultat à plat à Quick.

Pour que l'agent réponde au-delà des chiffres, AWS ajoute du contexte non structuré aux tables structurées. La spécification TPC-H au format PDF est chargée dans la Knowledge Base via un web crawler, et un Quick Space réunit le Topic, la base de connaissances et un tableau de bord prêt à l'emploi. Le chat agent dispose alors d'un seul environnement de connaissances géré : il peut répondre à des questions sur le chiffre d'affaires et les statuts de commandes, mais aussi tirer de la documentation les définitions des champs, la logique métier des requêtes et le sens des requêtes de benchmark. L'idée est simple : une interface à la place d'un ensemble d'écrans BI et de pages wiki éparpillés.

Où se situe l'effet

Pour l'entreprise, le principal gain est que l'analyse cesse d'être une file d'attente devant les spécialistes SQL et l'équipe BI. L'utilisateur peut demander en langage courant le chiffre d'affaires par segment, l'évolution des commandes, les remises ou les références produits, et obtenir une réponse liée aux données et aux visualisations.

AWS souligne séparément que ce modèle n'est pas conçu seulement pour le mode démo : l'accès est limité par des rôles, et les périmètres de visibilité sont hérités d'IAM et de Lake Formation. Autrement dit, l'employé ne voit que les tables, colonnes et sources pour lesquelles il dispose déjà d'autorisations.

Mais le billet montre aussi le prix de ce confort. Avant le lancement, il faut configurer le catalogue Glue, les droits dans Lake Formation, la connexion à Athena, le chargement dans SPICE, le Topic, le Space, le tableau de bord et un agent distinct. AWS ne promet donc pas de magie clé en main : l'analyse agentique apparaît là où un lakehouse, des modèles d'accès et une sémantique de données soignée existent déjà. En échange, l'entreprise obtient un chemin plus court de la question à la réponse et moins de travail manuel pour les analystes.

Ce que cela signifie

AWS promeut en pratique la prochaine étape du BI : non pas un nouveau tableau de bord, mais une couche d'interface agentique au-dessus d'un lakehouse existant. Si l'approche s'impose, les utilisateurs métier se tourneront de plus en plus vers les données par le dialogue, et les équipes data se concentreront non sur des extractions ponctuelles, mais sur la qualité des modèles, des droits et du contexte.