InfrastructureAWS ML Blog6sem· 2 min de lecture

Du data lake à l'analyse compatible IA : nouvelle source de données avec S3 Tables dans Amazon QuickSight

Amazon a annoncé l'intégration des S3 Tables au format Apache Iceberg comme nouvelle source de données dans Amazon QuickSight, son service d'analyse et de business intelligence piloté par l'IA. Cette mise à jour permet aux entreprises de requêter directement des tables Iceberg stockées dans un S3 table bucket, sans passer par des couches intermédiaires comme un entrepôt de données ou un système OLAP. QuickSight supporte désormais deux modes d'interrogation pour ces tables : Direct Query, qui offre un accès en quasi-temps réel aux données, et SPICE (Super-fast, Parallel, In-memory Calculation Engine), son moteur de calcul en mémoire haute performance. Pour illustrer le cas d'usage, Amazon cite l'exemple d'AnyCompany Corp., une institution financière mondiale qui ingère des transactions en temps réel via Amazon Kinesis Data Streams et Amazon Data Firehose vers un S3 table bucket, permettant une détection de fraude et un suivi des taux d'approbation quasi instantanés depuis des sources hétérogènes : terminaux de paiement, applications mobiles, objets connectés et passerelles en ligne.

Cet ajout représente une avancée concrète pour les équipes data et analytique des grandes entreprises. Jusqu'ici, analyser des données à grande échelle stockées dans un data lake nécessitait généralement de les déplacer vers un entrepôt de données ou un système OLAP, ce qui introduisait de la latence, des coûts supplémentaires et une complexité opérationnelle importante. En permettant de requêter directement le data lake depuis QuickSight, Amazon élimine ces pipelines de transformation coûteux. Les utilisateurs métiers peuvent ainsi explorer des jeux de données massifs, interagir en langage naturel et obtenir des visualisations à jour sans dépendre de processus batch ni nécessiter d'expertise en machine learning. La scalabilité constitue un autre avantage clé : les requêtes portent sur des volumes importants stockés dans S3 sans contrainte de taille ni besoin de réplication préalable.

Cette annonce s'inscrit dans la montée en puissance des architectures de données modernes autour des formats de table ouverts comme Apache Iceberg, conçus pour offrir de meilleures performances, une gouvernance simplifiée et des coûts réduits par rapport aux entrepôts traditionnels. Amazon, Microsoft et Google se livrent une concurrence intense sur le segment de l'analytique cloud, chacun cherchant à rendre ses services d'analyse plus accessibles et plus proches des données sources. En intégrant les S3 Tables à QuickSight, AWS renforce son positionnement autour du concept de "source unique de vérité" dans le data lake, tout en réduisant la dépendance aux solutions tierces comme Snowflake ou Databricks. La prochaine étape logique pourrait être une intégration plus poussée des capacités d'IA générative de QuickSight avec ces nouvelles sources, afin d'automatiser davantage la détection d'anomalies et la génération d'insights à la volée.

Dans nos dossiers

Microsoft AWS

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

1Le Big Data

Comment Uber optimise ses millions de trajets et son IA avec Amazon

Uber a annoncé un renforcement significatif de son partenariat avec Amazon Web Services pour optimiser en temps réel la gestion de ses millions de trajets quotidiens à l'échelle mondiale. Au cœur de cette collaboration, deux puces développées par AWS jouent des rôles complémentaires : Graviton4, conçue pour les calculs cloud intensifs, et Trainium3, spécialisée dans l'entraînement de modèles d'intelligence artificielle à partir de volumes massifs de données. Concrètement, Uber migre une part croissante de ses opérations critiques vers ces architectures matérielles, notamment ses Trip Serving Zones, des serveurs chargés de traiter en continu la localisation des chauffeurs, leur disponibilité et le calcul des itinéraires. Rich Geraffo, vice-président d'AWS, a qualifié Uber de l'une des applications en temps réel les plus exigeantes au monde, soulignant l'ampleur du défi technique que représente cette infrastructure. L'enjeu est considérable : à chaque ouverture de l'application, le système dispose de moins d'une seconde pour attribuer un chauffeur, définir un itinéraire et estimer le délai d'arrivée, et ce pour des millions d'utilisateurs simultanément, sans marge d'erreur même lors des pics de demande. Le passage à Graviton4 permet à Uber d'améliorer sa réactivité, de réduire sa consommation énergétique et de mieux absorber les surcharges de trafic qui peuvent atteindre 2 à 25 fois le niveau normal selon AWS. En parallèle, Trainium3 permet d'affiner les algorithmes d'IA qui analysent des millions de trajets et de livraisons pour améliorer la sélection des chauffeurs, la précision des temps d'arrivée et l'optimisation des options de livraison. Cette montée en puissance technologique vise à maintenir la qualité de service à mesure que les volumes de données traitées augmentent. Ce partenariat s'inscrit dans une tendance lourde du secteur : les grandes plateformes de mobilité à la demande investissent massivement dans des infrastructures cloud sur mesure pour rester compétitives. Uber, qui opère dans des dizaines de pays et traite des milliards de points de données quotidiens, ne peut plus se contenter d'architectures génériques. Toutefois, plusieurs défis subsistent. La migration vers ces nouvelles puces implique d'adapter des algorithmes complexes, de tester chaque scénario de calcul et d'assurer la compatibilité avec les systèmes existants, ce qui représente un investissement en temps, en expertise et en budget considérable. Par ailleurs, même les architectures les plus robustes peuvent être prises de court par des événements imprévisibles, qu'il s'agisse de pics explosifs lors du Black Friday ou d'incidents de circulation en temps réel. L'IA reste tributaire de la qualité et de la fraîcheur des données disponibles, ce qui constitue une limite structurelle que la puissance matérielle seule ne peut pas résoudre.

InfrastructureActu

1 source

2AWS ML Blog

Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore

Amazon a enrichi son service Bedrock AgentCore Gateway de deux mécanismes de sécurité complémentaires destinés à contrôler le comportement des agents IA en entreprise. Le premier, appelé Policy, permet de définir des règles d'accès aux outils à l'aide de Cedar, un langage déclaratif d'Amazon qui évalue chaque requête selon un principal, une action et une ressource, puis délivre une décision déterministe d'autorisation ou de refus, automatiquement journalisée. Le second mécanisme, les intercepteurs Lambda, permet d'exécuter du code personnalisé avant ou après chaque appel d'outil, pour effectuer de la validation dynamique, de l'enrichissement de payload, des échanges de tokens ou du filtrage de réponses. Pour illustrer ces capacités, Amazon présente un agent de données baptisé "lakehouse data agent", conçu pour une compagnie d'assurance fictive. Cet agent permet à trois types d'utilisateurs, titulaires de contrats, experts en sinistres et administrateurs, d'interroger des données de réclamations stockées dans Amazon S3 Tables au format Apache Iceberg, via Amazon Athena et AWS Lake Formation. L'interface Streamlit authentifie les utilisateurs via Amazon Cognito et transmet des JWT à l'agent, qui expose cinq outils MCP distincts. Les métadonnées de rôles, les mappings IAM par tenant et la géographie des utilisateurs sont stockés dans Amazon DynamoDB. Ces nouvelles fonctionnalités répondent à un problème de gouvernance concret que rencontrent les grandes organisations déployant des agents IA à l'échelle. Contrairement aux applications traditionnelles qui exécutent une logique fixe, les agents pilotés par un LLM décident au moment de l'exécution quels outils invoquer, avec quels arguments et dans quel ordre. Il devient donc impossible d'auditer le graphe d'appels à l'avance. Sur des plateformes unifiées comptant des centaines d'agents et des milliers d'outils MCP répartis entre différentes équipes et unités métier, ce manque de contrôle crée un risque réel. La combinaison Cedar pour l'autorisation déterministe et Lambda pour la validation contextuelle dynamique, notamment basée sur la géographie de l'utilisateur, offre une architecture de sécurité en couches adaptée à cette réalité. Ce développement s'inscrit dans un mouvement plus large d'industrialisation de l'IA agentique au sein des entreprises, où les questions de sécurité et de conformité deviennent aussi critiques que la performance des modèles eux-mêmes. Le Model Context Protocol, promu initialement par Anthropic, s'impose progressivement comme standard d'interopérabilité entre agents et outils, et AWS prend position en intégrant nativement la gouvernance des outils MCP dans Bedrock. Lake Formation assure par ailleurs une sécurité au niveau des lignes et des colonnes directement à l'exécution des requêtes, garantissant que même un agent mal configuré ne puisse pas exfiltrer de données hors de son périmètre autorisé. La prochaine étape probable pour Amazon sera d'étendre ces mécanismes à des scénarios multi-agents, où la chaîne de confiance entre agents orchestrateurs et agents subalternes soulève des défis de sécurité encore plus complexes.

InfrastructureActu

1 source

3VentureBeat AI

Databricks affirme avoir résolu le problème des pipelines de données qui freinait les agents IA depuis des décennies

Lors du Data + AI Summit de mardi, Databricks a annoncé deux nouveaux produits conçus pour résoudre un problème vieux de plusieurs décennies dans le domaine des données : la coexistence des bases de données transactionnelles et analytiques. La première annonce, Lakehouse//RT, promet une latence de requête en quelques millisecondes directement sur les tables Delta et Iceberg gouvernées, supprimant la couche de service temps réel distincte que les entreprises maintenaient en parallèle de leurs lakehouses. La seconde, LTAP (Lake Transactional/Analytical Processing), stocke les données transactionnelles natives de Postgres directement en format Delta et Iceberg dès l'écriture, éliminant ainsi les pipelines ETL qui reliaient depuis des décennies les systèmes opérationnels et analytiques. Reynold Xin, cofondateur de Databricks, a qualifié cette simplification de "saint Graal pour les agents" lors d'un entretien avec VentureBeat. L'enjeu est structurel pour les systèmes d'IA agentiques : un agent qui raisonne en continu et agit sur des données en direct ne peut pas se permettre de traverser des pipelines de transformation avant d'accéder à l'information dont il a besoin. LTAP répond à ce défi en unissant les données au niveau de la couche de stockage, là où des approches comme l'HTAP (Hybrid Transactional/Analytical Processing, popularisé par Gartner en 2014) avaient tenté une convergence au niveau des moteurs de requête. La clé technique réside dans la conversion ligne-colonne effectuée en amont, dans la couche de cache entre les instances Postgres et le stockage objet : cette compression réduit les données d'un facteur supérieur à dix, rendant viable un accès OLTP sur un stockage objet qui présente normalement des latences de l'ordre de la seconde. Databricks n'est pas le premier à tenter cette unification. Des acteurs comme SingleStore (anciennement MemSQL), SAP HANA ou Oracle MySQL HeatWave ont commercialisé des solutions HTAP sans jamais véritablement s'imposer comme standard. Xin considère d'ailleurs l'HTAP comme "un échec de l'industrie plutôt qu'un succès". Lakebase, le service PostgreSQL serverless de Databricks mis en disponibilité générale en février, constitue la fondation de cette nouvelle architecture. Avec la montée en puissance du "vibe coding" et des applications générées par IA, la complexité de l'infrastructure de données devient un goulot d'étranglement critique pour les agents qui doivent raisonner analytiquement en temps réel. La promesse de Databricks est simple : un seul exemplaire de la donnée, accessible simultanément par Postgres pour le transactionnel et par Spark pour l'analytique, sans copie, sans gouvernance fragmentée, sans pipeline intermédiaire.

UELes entreprises européennes déployant des agents IA sur des architectures lakehouse pourraient bénéficier directement de l'élimination des pipelines ETL et d'une latence réduite pour l'accès aux données transactionnelles en temps réel.

InfrastructureOpinion

1 source

4VentureBeat AI

Amazon S3 Files offre aux agents IA un espace de travail fichier natif, mettant fin à la séparation objet/fichier

Amazon Web Services a lancé S3 Files, une nouvelle fonctionnalité qui permet de monter directement un bucket S3 dans l'environnement local d'un agent IA ou d'un développeur, comme s'il s'agissait d'un répertoire ordinaire. Disponible dès maintenant dans la plupart des régions AWS, cette solution repose sur la technologie Elastic File System (EFS) d'Amazon, connectée directement à S3 pour offrir une sémantique de fichiers complète et native. Aucune migration de données n'est nécessaire : les fichiers restent dans S3, accessibles simultanément via l'API objet classique et via le système de fichiers monté. Andy Warfield, vice-président et ingénieur distingué chez AWS, a expliqué à VentureBeat que cette approche a produit "une accélération considérable" pour des outils comme Kiro et Claude Code lors de tests internes. Le problème que S3 Files résout est fondamental pour les pipelines d'IA agentique. Les agents IA fonctionnent naturellement avec des chemins de fichiers et des outils de navigation de répertoires, mais l'essentiel des données d'entreprise réside dans des systèmes de stockage objet comme S3, accessibles uniquement via des appels API. Jusqu'ici, les équipes devaient télécharger les données localement avant que l'agent puisse les traiter, ce qui créait un problème critique de persistance d'état : lorsque l'agent compressait sa fenêtre de contexte, il "oubliait" ce qu'il avait déjà téléchargé, forçant l'utilisateur à répéter les instructions. Dans des pipelines multi-agents, où plusieurs agents doivent accéder simultanément aux mêmes données, la situation devenait ingérable. Avec S3 Files, un développeur peut simplement indiquer le chemin d'un répertoire de logs, et l'agent y accède directement sans étape intermédiaire. AWS annonce que des milliers de ressources de calcul peuvent se connecter simultanément à un même système de fichiers S3. Les tentatives précédentes de combler le fossé entre stockage objet et système de fichiers reposaient sur des couches logicielles dites FUSE (Filesystems in USErspace), comme Mount Point d'AWS, gcsfuse de Google ou blobfuse2 de Microsoft. Ces outils simulaient un système de fichiers en surface, mais butaient sur des limitations profondes : S3 ne supporte pas le déplacement atomique d'objets et ne possède pas de répertoires au sens strict. Ces pilotes bricolaient des métadonnées supplémentaires dans les buckets, cassant la vue API objet, ou refusaient les opérations fichier que le stockage ne pouvait pas exécuter. S3 Files rompt avec cette approche en intégrant directement EFS à S3, sans compromis entre les deux interfaces. Cette évolution s'inscrit dans la course des grands fournisseurs cloud à rendre leurs infrastructures compatibles avec les nouveaux usages de l'IA agentique, où la fluidité d'accès aux données devient un avantage concurrentiel direct.

UEDisponible dès maintenant dans la plupart des régions AWS, cette fonctionnalité est accessible aux développeurs et entreprises européens utilisant S3 pour leurs pipelines d'IA agentique.

InfrastructureActu

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, rédigé par un humain · désinscription en un clic