Posons la question naïvement. Pourquoi un agent IA, censé raisonner en continu et agir sur des données vivantes, devrait-il attendre qu’un pipeline recopie l’information d’une base à l’autre avant de pouvoir l’utiliser ?
C’est ce décalage que Databricks affirme avoir supprimé. À son Data + AI Summit, l’éditeur a dévoilé deux briques qui visent un problème vieux de plusieurs décennies : la séparation entre les bases qui enregistrent (transactionnelles) et celles qui analysent. Et derrière l’annonce produit, une thèse : pour les agents, le goulot s’est déplacé du modèle vers la donnée, trop lente à arriver.
Le problème que personne n’avait vraiment réglé
Depuis toujours, les entreprises maintiennent deux mondes. D’un côté la base opérationnelle, qui encaisse les écritures en temps réel (une commande, un paiement). De l’autre l’entrepôt analytique, qui répond aux grosses requêtes. Entre les deux, un pipeline d’ETL (extraction, transformation, chargement) recopie et reformate les données.
Ce pont fonctionne tant qu’un humain consulte un tableau de bord rafraîchi chaque nuit. Avec un agent, il devient un mur. Un système qui décide en boucle ne peut pas tolérer un tampon entre lui et l’information sur laquelle il agit. La latence cesse d’être un confort dégradé : elle devient structurelle.
Comment ça marche, étage par étage
La première brique, Lakehouse//RT, promet une latence de requête de l’ordre de la milliseconde directement sur les tables gouvernées aux formats Delta et Iceberg. Traduction : plus besoin de maintenir, à côté de l’entrepôt, une couche dédiée au temps réel. On interroge la donnée là où elle vit.
La seconde, baptisée LTAP (Lake Transactional/Analytical Processing), s’attaque à la racine. Elle stocke les données transactionnelles natives PostgreSQL directement aux formats Delta ou Iceberg, dès l’écriture. Le pipeline qui reliait opérationnel et analytique disparaît, parce qu’il n’y a plus deux copies à réconcilier : une seule donnée, lue à la fois par le moteur transactionnel et par le moteur analytique.
Une image pour fixer l’idée. Plutôt que de tenir deux registres et de recopier l’un dans l’autre chaque soir, on écrit une seule fois dans un cahier que les deux services consultent en même temps. PostgreSQL reste le moteur qui écrit ; Spark et le Lakehouse restent les moteurs qui analysent. Ce qui change, c’est le sol commun sous leurs pieds.
Tenir la milliseconde
Le défi d’ingénierie tient en un mot : la vitesse. Le stockage objet, sur lequel repose toute cette architecture, répond en secondes. Beaucoup trop lent pour des charges transactionnelles qui exigent la sous-milliseconde. Comment tenir l’écart ?
La réponse de Databricks passe par une couche de cache entre les instances PostgreSQL et le stockage objet. Et par une décision de conception précise : la conversion des données du format ligne vers le format colonne se fait dans cette couche, en exploitant la capacité CPU inutilisée. Reynold Xin, cofondateur de Databricks, avance un chiffre parlant : « Quand on convertit de la ligne vers la colonne, ça compresse typiquement plus de dix fois. » Moins de volume à transférer, donc moins de coût réseau entre le cache et le stockage.
L’édifice repose sur Lakebase, le service PostgreSQL serverless de Databricks rendu disponible en février. Auparavant, Lakebase rangeait les données PostgreSQL au format PostgreSQL, qu’il fallait convertir avant que les moteurs analytiques puissent les exploiter. Avec LTAP, la conversion a déjà eu lieu en amont.
Pari sur le stockage, pas sur le moteur
L’idée d’unifier transactionnel et analytique n’est pas neuve. En 2014, le cabinet Gartner forgeait le terme HTAP (Hybrid Transactional/Analytical Processing) pour décrire les éditeurs qui tentaient de fusionner les deux mondes au niveau du moteur de requête. SingleStore, SAP HANA ou MySQL Heatwave d’Oracle s’y sont essayés. Plus récemment, Snowflake a relancé l’idée avec Unistore et ses tables hybrides, qui répliquent une même donnée vers un format analytique au niveau de la table.
Databricks assume une lecture sévère de cet héritage. « HTAP, pour nous, c’est plutôt un échec de l’industrie qu’un succès », tranche Xin. D’où le déplacement du curseur : unifier non plus au niveau du moteur, mais au niveau du stockage. On garde le meilleur outil pour chaque tâche côté requête, et on s’assure simplement qu’il n’existe qu’une seule copie de la donnée en dessous.
Pourquoi ça compte pour qui orchestre l’IA
Le résultat, si la promesse tient en production, est moins de plomberie à maintenir et une donnée fraîche par construction. Pour un agent qui doit agir sur un état qui bouge en permanence, ce n’est pas un détail de confort : c’est la condition pour qu’il décide juste. Xin résume sa thèse sans détour : une pile de données plus simple est « le Saint-Graal pour les agents », car ils vont d’autant plus vite que l’infrastructure s’efface.
Reste la part d’ombre, qu’aucune annonce de conférence ne dissipe. La latence de la milliseconde sur du stockage objet repose entièrement sur la couche de cache : sa tenue sous charge réelle, son coût et son comportement aux pics restent à vérifier hors démo. Et déplacer l’unification vers le stockage ne supprime pas la complexité, il la relocalise.
Une chose est nette, en revanche. Tant que le débat se concentrait sur les modèles, le terrain de jeu était les LLM. En posant la fraîcheur de la donnée comme le verrou des agents, Databricks déplace la bataille vers le data plane. C’est là, désormais, que se jouera une part de l’avantage agentique.
