Databricks résout le problème vieux de 40 ans qui freinait les agents IA

Introduction : Le sommet où Databricks a misé sur les agents

Lors du Data + AI Summit à San Francisco le 16 juin 2026, Databricks n’a pas seulement lancé des produits. L’entreprise a fait un pari structurel : que le principal consommateur des bases de données d’entreprise n’est plus un analyste humain exécutant des requêtes SQL, mais un agent d’IA qui a besoin à la fois de données transactionnelles en temps réel et de données analytiques historiques — simultanément, et sans attendre.

La pièce maîtresse de ce pari est LTAP, une architecture qu’Ali Ghodsi, cofondateur et PDG de Databricks, a décrite comme résolvant « un problème de base de données vieux de 40 ans ». C’est une affirmation qui semble hyperbolique jusqu’à ce que l’on comprenne ce que LTAP fait réellement : elle fusionne deux paradigmes de bases de données qui étaient séparés depuis les années 1980 en une seule copie de stockage gouverné sur le lakehouse.

(Source : Forbes — Databricks CEO Says He’s Cracked A 40-Year-Old Database Problem With LTAP)

Le problème vieux de 40 ans : pourquoi OLTP et OLAP ne se sont jamais parlés

Pour comprendre pourquoi LTAP est important, il faut comprendre le schisme au cœur de chaque pile de données d’entreprise.

Depuis les années 1980, les bases de données sont divisées en deux catégories :

OLTP (Online Transaction Processing) : Conçu pour des opérations rapides et de petite taille — enregistrer une vente, mettre à jour un dossier client, traiter un paiement. Ces bases de données (PostgreSQL, MySQL, Oracle) gèrent des milliers d’écritures simultanées par seconde, mais peinent sur les requêtes analytiques lourdes.
OLAP (Online Analytical Processing) : Conçu pour des opérations de lecture lourdes — agréger des millions de lignes, exécuter des fonctions de fenêtrage, générer des rapports. Ces systèmes (Snowflake, BigQuery, Redshift) peuvent analyser des pétaoctets, mais ne sont pas conçus pour les écritures au niveau des lignes.

Pendant 40 ans, la solution a été l’ETL — Extract, Transform, Load. Les entreprises exécutaient des pipelines qui copiaient les données des systèmes transactionnels vers les entrepôts analytiques, généralement avec un délai. Le résultat : les requêtes analytiques s’exécutaient sur des données obsolètes, les pannes de pipeline étaient endémiques, et les organisations payaient pour stocker deux fois la même information.

Les agents d’IA rendent ce problème aigu. Un agent traitant un ticket de support client a besoin de données transactionnelles (qu’a acheté le client ? quel est son niveau de support ?) et de données analytiques (quel est le modèle de résolution pour des tickets similaires sur 10 000 cas ?) — dans la même requête, en temps réel.

(Source : The New Stack — Databricks wants to merge the two databases every company runs)

LTAP : Une seule copie des données, pas de pipelines

LTAP (Lake Transactional/Analytical Processing) est la réponse de Databricks. La promesse centrale de l’architecture : stocker les données une seule fois dans des formats ouverts (Delta Lake et Apache Iceberg), et laisser les charges de travail transactionnelles et analytiques opérer sur cette copie unique sans ETL, sans réplication et sans bases de données séparées.

Comment cela fonctionne sous le capot :

Lakebase, le moteur transactionnel serverless compatible Postgres de Databricks, gère les charges de travail OLTP.
Mooncake, la startup acquise par Databricks, reflète les modifications de Postgres dans le lakehouse en temps réel — de sorte que les requêtes analytiques s’exécutent sur des données à jour jusqu’à la dernière transaction, et non sur le lot de la veille.
Le branchement et les instantanés de type Git permettent aux équipes d’expérimenter en toute sécurité sur des données de production, en créant des copies isolées de l’état du lakehouse sans dupliquer physiquement les données.
Les opérations de base de données autonomes permettent aux agents d’IA de surveiller la santé de la base de données, de détecter les ralentissements de requêtes, de proposer des index et d’aider à la récupération — la base de données se gère elle-même.

L’élimination des pipelines CDC (Change Data Capture) et ETL n’est pas une optimisation marginale. Pour les grandes entreprises, ces pipelines représentent des milliers d’heures d’ingénierie, des chaînes de dépendances fragiles et la source la plus courante de problèmes d’actualité des données.

(Source : Databricks Press Release — Databricks Launches LTAP)

Lakehouse//RT : Requêtes en millisecondes sans couche de service

Parallèlement à LTAP, Databricks a dévoilé Lakehouse//RT, un moteur d’analyse en temps réel alimenté par un nouveau moteur vectoriel appelé Reyden. Il offre une latence de requête de l’ordre de la milliseconde, s’exécutant directement sur les tables Delta et Iceberg gouvernées.

C’est significatif car, historiquement, pour obtenir des vitesses de requête inférieures à la seconde, il fallait une « couche de service » distincte — une base de données temps réel dédiée (comme Apache Druid ou ClickHouse) contenant une copie pré-agrégée des données du lakehouse. Lakehouse//RT supprime complètement cette couche.

Mehrshad Setayesh, SVP ingénierie chez PointClickCare, a fourni un benchmark concret : Lakehouse//RT « a fonctionné plus d’un tiers plus rapidement en moyenne que notre précédent entrepôt sur notre ensemble de données de soins de santé, avec des requêtes 10 fois plus rapides », éliminant ainsi le besoin pour l’entreprise d’un système temps réel dédié en complément de son lakehouse.

(Source : The New Stack — Databricks wants to merge the two databases every company runs)

Lakehouse//RT est en version bêta, disponible pour les clients Lakehouse existants avec leurs abonnements actuels. LTAP est un chemin de mise à niveau pour les clients Lakebase.

L’angle agent : pourquoi c’est important maintenant

Databricks ne résout pas un problème de base de données pour le plaisir. La combinaison LTAP/Lakehouse//RT est conçue pour un monde où le volume de requêtes n’est pas généré par des humains cliquant sur des tableaux de bord, mais par des agents autonomes exécutant des workflows en plusieurs étapes.

Les chiffres parlent d’eux-mêmes :

Plus de 100 000 agents construits sur Agent Bricks depuis son lancement en avril 2026.
1 quadrillion de jetons par an traités via la plateforme.
1,7 milliard de dollars de revenus annuels de produits d’IA, contre 1,4 milliard de dollars en février 2026.

(Source : Let’s Data Science — Databricks Unveils Agent-Focused Lakehouse and Governance Tools)

Lors du sommet, Ghodsi a décrit une nouvelle dynamique de consommation : « Les agents génèrent beaucoup plus de requêtes. Nous avons tous ces agents, la plateforme d’agents que nous avons génère également des revenus, donc cela augmente simplement la consommation de tout ce qui nous entoure. »

C’est le double tranchant de la consommation pilotée par les agents. Plus de requêtes signifie plus de revenus — mais aussi plus de coûts de calcul. Ghodsi a reconnu que les marges brutes de Databricks se réduisent à mesure que l’utilisation des agents augmente, qualifiant cela de « modèle économique basé sur la consommation, l’IA agentique arrive. »

(Source : CNBC — Databricks revenue growth tops 80% to $6.9 billion annualized)

Pour gérer cela, Databricks a lancé Unity AI Gateway, qui permet aux organisations de définir des budgets d’IA et de recevoir des alertes à l’approche des limites de dépenses. Ghodsi a décrit le changement de paradigme du secteur, passant du « tokenmaxxing » — encourager les travailleurs à utiliser autant de jetons que possible — au « value-maxxing », optimisant l’efficacité tout en exploitant les capacités de l’IA.

L’histoire commerciale : 6,9 milliards de dollars et une croissance plus rapide que Snowflake

Les annonces de produits ont été renforcées par des chiffres financiers qui placent Databricks fermement en avance sur son rival du marché public.

Métrique	Databricks	Snowflake
Revenus annualisés	6,9 milliards $	~5,6 milliards $
Croissance annuelle	80%+	~30%
Valorisation / Capitalisation boursière	134 milliards $ (privé)	~83 milliards $ (public)
Revenus des produits d’IA	1,7 milliard $	N/A
Statut	Pré-IPO, discussions à 165-175 milliards $	Public depuis 2020

Les revenus de Databricks sont passés de 5,4 milliards de dollars annualisés au quatrième trimestre fiscal à 6,9 milliards de dollars lors du sommet — une augmentation de 1,5 milliard de dollars en environ un trimestre. Le taux de croissance s’accélère, il ne plafonne pas.

(Source : Netzender — Databricks sales growth tops 80%, but margins are shrinking from swarm of AI agents)

Alors qu’OpenAI, Anthropic et SpaceX dominent les gros titres des introductions en bourse, Databricks emprunte une voie différente. Ghodsi a refusé de s’engager sur un calendrier d’offre publique, même si la société serait en pourparlers pour un nouveau tour de financement à 165-175 milliards de dollars — ce qui en ferait l’une des sociétés privées les plus valorisées au monde.

La comparaison avec Snowflake est instructive. Snowflake est entré en bourse en 2020 et a réalisé la plus grande introduction en bourse de logiciels de l’histoire à l’époque. Aujourd’hui, Databricks génère plus de revenus annualisés que Snowflake tout en croissant près de trois fois plus vite — et elle est toujours privée.

Ce que cela signifie : Le marché des bases de données se réorganise autour des agents

LTAP et Lakehouse//RT représentent plus que de simples lancements de produits. Ils signalent une réorganisation structurelle du marché de l’infrastructure de données autour d’un nouvel utilisateur principal : l’agent d’IA.

Trois implications méritent d’être surveillées :

1. L’industrie de l’ETL est confrontée à une question existentielle. Si vous pouvez interroger directement les données transactionnelles depuis le lakehouse avec des performances analytiques, qu’advient-il de Fivetran, Airbyte et de tout l’écosystème CDC/pipeline ? La réponse n’est pas « ils disparaissent demain » — les systèmes existants ont une inertie — mais la proposition de valeur du déplacement des données diminue à chaque fois qu’une architecture unifiée est livrée.

2. Snowflake est désormais à la traîne en termes de revenus et d’architecture. La séparation du stockage et du calcul de Snowflake était révolutionnaire en 2014. Mais la couche de stockage unifiée de Databricks + la capacité transactionnelle en temps réel + la plateforme native pour les agents représentent un pari fondamentalement différent. Les récentes annonces de Cortex AI de Snowflake suggèrent qu’ils voient la menace.

3. Les agents piloteront les décisions d’infrastructure, et non l’inverse. Pendant deux décennies, l’infrastructure a été construite pour les analystes humains et les tableaux de bord. Le lancement de LTAP est une reconnaissance explicite que l’infrastructure de la prochaine décennie doit être construite pour des logiciels autonomes qui interrogent à la vitesse de la machine. Chaque fournisseur de bases de données devra éventuellement répondre à la même question : « Votre système peut-il servir des données fraîches à un millier d’agents à la fois, avec gouvernance, sans dupliquer le stockage ? »

Le message plus large du Data + AI Summit 2026 est clair : les guerres des bases de données ne portent plus sur les moteurs SQL en compétition pour l’attention des analystes. Elles portent sur l’architecture qui peut servir de couche mémoire pour une entreprise native de l’IA.

FAQ

Q : Quelle est la véritable différence entre LTAP et ce que Databricks avait déjà avec le Lakehouse ?

Le Lakehouse unifiait déjà les charges de travail d’entreposage de données et de lacs de données (analytique + ML sur une seule copie). LTAP ajoute le traitement transactionnel (OLTP) à cette même couche de stockage. Avant LTAP, si vous utilisiez une base de données Postgres pour votre application et souhaitiez effectuer des analyses sur ces données, vous aviez besoin d’un pipeline pour les copier dans le lakehouse. LTAP fait du lakehouse lui-même le magasin transactionnel, éliminant ainsi la copie.

Q : LTAP est-il généralement disponible, ou toujours en prévisualisation ?

LTAP est disponible en tant que mise à niveau pour les clients Lakebase existants. Lakehouse//RT est en version bêta, accessible aux clients Lakehouse avec leurs abonnements actuels.

Q : Comment la plateforme d’agents de Databricks se compare-t-elle à Snowflake Cortex AI ou AWS Bedrock ?

La différence clé est la localité des données. Agent Bricks exécute des agents directement sur les données du lakehouse gouverné avec Unity Catalog fournissant des contrôles d’accès, la traçabilité et l’audit. Les concurrents comme Bedrock ou Vertex AI Agent Builder se connectent à des sources de données externes. Pour les secteurs réglementés comme les services financiers (BBVA a déployé ChatGPT Enterprise auprès de 100 000 employés sur Databricks), le fait d’avoir des agents et des données dans le même environnement gouverné est un avantage en matière de conformité.

(Source : develeap — Agent Bricks: Data + AI Summit 2026)

Q : La compression des marges due aux requêtes des agents ne rendra-t-elle pas le modèle économique de Databricks insoutenable ?

C’est une tension réelle. Plus de requêtes d’agents → plus de revenus mais aussi plus de coûts de calcul → des marges plus faibles. La réponse de Ghodsi est que Unity AI Gateway fera passer le comportement du « tokenmaxxing » au « value-maxxing », et que la croissance absolue des revenus (80%+) l’emporte sur la compression des marges. Reste à savoir si les investisseurs seront d’accord lorsque Databricks entrera finalement en bourse.