Quelques notes du Databricks Data + AI Summit 2026 : pourquoi la couche de données compte à nouveau
Après le Databricks Data + AI Summit de cette année, je me suis surpris à penser moins à une annonce en particulier qu’à une question qui m’habite depuis un certain temps :
Quand l’IA passe réellement en production, que devient la couche de données ?
Ma réponse actuelle est simple, même si ses implications ne le sont pas : dans ce cycle, la couche de données est la partie de la stack IA qui a été réévaluée le plus lentement. Cela commence à changer.
Les données : la partie de la stack IA que le marché n’a pas encore valorisée
Les algorithmes ont été réévalués publiquement. Les modèles s’améliorent rapidement, et l’industrie peut voir les progrès presque chaque semaine. Le calcul a été réévalué par NVIDIA, les fournisseurs cloud et les marchés de capitaux. Tout le monde comprend que les GPU comptent.
Les données ont évolué plus lentement. Pas parce qu’elles comptent moins. C’est l’inverse. Les données sont lentes à être réévaluées parce qu’il est difficile d’en parler et encore plus difficile de les corriger. Les données d’entreprise sont désordonnées, dispersées, dupliquées, périmées et pleines d’autorisations que personne ne comprend vraiment entièrement. Les sémantiques métier ne s’alignent pas proprement entre les systèmes. Ce que les gens appellent « temps réel » reste souvent une tâche planifiée qui s’est exécutée à un moment donné la nuit dernière.
Ce travail est pénible. Il n’est pas non plus très glamour. Mais une fois que l’IA passe des démonstrations à la production, la douleur devient impossible à cacher.
Dans les conversations avec des personnes qui construisent et entraînent des modèles, y compris chez OpenAI et Anthropic, la discussion revient souvent au même point. Les modèles convergent. Le calcul peut s’acheter, du moins si l’on a assez d’argent. La couche défendable devient de plus en plus les données : leur qualité, leur fraîcheur, les autorisations qui les entourent et la vitesse à laquelle elles peuvent être transformées en contexte utile.
Ce n’est pas seulement un problème de couche applicative. Au sein des entreprises de modèles, la qualité des modèles dépend encore fortement du pipeline de données. Une exécution d’entraînement peut nécessiter des jours de préparation avant que la première expérience sérieuse ne commence. Si un champ en amont est sale, qu’un lot est mal étiqueté ou qu’une règle de filtrage est incorrecte, des jours de calcul et d’attente peuvent disparaître avant que quiconque ne remarque que la courbe de perte a dérivé.
Les agents IA rendent le problème des données impossible à cacher
Les agents exposent le même problème sous une forme plus opérationnelle.
Quand les agents IA échouent en production, la première cause n’est souvent pas que le modèle est incapable. C’est que le modèle agit sur le mauvais contexte : un enregistrement auquel il ne peut pas accéder, un document qui a expiré il y a six heures, une source de données qui a changé discrètement pendant la nuit, ou un chemin de récupération trop coûteux pour être utilisé assez souvent. J’ai récemment vu une équipe solide perdre près d’une semaine à cause d’un pipeline de contexte périmé. L’agent répondait avec assurance à la question d’hier. Le modèle n’était pas stupide. Le contexte était mauvais, et le système n’avait aucun moyen propre de prouver où l’erreur était entrée dans la boucle.
C’est ce mode de défaillance qui compte. Le prochain goulot d’étranglement de l’infrastructure n’est pas simplement un meilleur raisonnement. C’est un contexte frais, fiable, peu coûteux et auditable au moment où un modèle ou un agent prend une décision.
C’est pourquoi je pense que la couche de données est la prochaine partie de la stack IA à être réévaluée.
Databricks vise le bon problème
Je suis sceptique à l’égard de nombreux produits qui se qualifient de « plateformes de données IA ». Trop souvent, le récit arrive avant le système.
Databricks est suffisamment différent pour que je pense qu’il mérite une attention sérieuse. Deux choses m’ont frappé au Summit.
La première reste la culture d’ingénierie. À l’échelle de Databricks, il serait facile pour l’entreprise de devenir purement guidée par les ventes. Pourtant, les fondateurs sont encore sur scène à parler de moteurs d’exécution, de transactions, d’analytique en temps réel et des tuyaux sous-jacents au produit. Je respecte cela. On sent quand une entreprise a encore l’intuition produit et ingénierie en son cœur. Cela se voit dans de petites décisions architecturales bien avant d’apparaître dans une keynote.
Le deuxième est la base de clients. Les utilisateurs avec lesquels j’ai échangé au Summit ne parlaient pas de l’IA comme d’une couche de démonstration. Ils essayaient de pousser l’IA dans des systèmes de production, et les problèmes qu’ils décrivaient étaient beaucoup plus concrets : les agents doivent lire et écrire l’état métier ; l’analytique en temps réel ne peut pas continuer à payer le coût du déplacement des données ; les pipelines doivent devenir plus autonomes ; le comportement des agents doit être gouverné à l’exécution, pas seulement a posteriori.
C’est pourquoi des annonces telles que Lakebase, Lakehouse//RT, les agents de données et la gouvernance de l’IA sont importantes. Les noms importent moins que la direction. Rapprocher les transactions du lac. Ramener l’analytique en temps réel vers le même socle de données. Automatiser davantage le pipeline. Étendre la gouvernance de « qui peut voir cet ensemble de données » à « qu’est-ce que cet agent est autorisé à faire à cette étape précise ? »
Je ne vois pas cela comme une mauvaise direction. J’y vois la preuve que beaucoup d’entre nous regardent le même avenir sous des angles différents.
La base de données s’étend. Elle n’est plus seulement un endroit où stocker et interroger des données. Elle devient le socle des faits, de l’état, de la sémantique, de la gouvernance et de l’action.
La carte est bonne. Mais elle n’est pas terminée.
Databricks va dans la bonne direction. Cela ne signifie pas que l’architecture a atteint sa forme finale.
Photo : Le domaine des données connues · Databricks Data + AI Summit 2026
Je vois trois domaines où la carte reste incomplète.
Le lakebase lui-même.
Commencer par Postgres est un point d’entrée intelligent. Les développeurs le connaissent. L’écosystème est immense. La compatibilité réduit les frictions d’adoption. C’est important.
Mais l’architecture qui fait entrer les gens n’est pas toujours celle qui remporte la charge de travail finale.
Les systèmes opérationnels de l’ère de l’IA ont besoin de transactions, de mémoire, de vecteurs, de données multimodales, de traces, de branchements, de restauration arrière et d’une isolation des locataires très fine. Un cœur relationnel traditionnel peut exposer certains de ces éléments via des extensions et des services environnants, mais cela ne les rend pas natifs. Le Postgres classique n’a pas été conçu pour une mise à l’échelle distribuée cloud-native, ni pour des agents qui créent des bases de données éphémères, bifurquent l’état, écrivent en mémoire, génèrent des traces et disparaissent.
Rapprocher Postgres du stockage objet n’efface pas ces questions. Le stockage objet est peu coûteux et fiable, mais il n’est pas à faible latence par défaut. Pour le rendre rapide en apparence, il faut une couche de cache à la fois agressive et correcte. Un cache qui reste stable sous une véritable charge transactionnelle est l’un des problèmes systèmes les plus difficiles dans les bases de données. Donc ma question sincère à propos de Lakebase n’est pas de savoir si la démonstration est impressionnante. C’est de savoir si le système peut porter de vraies charges OLTP à l’échelle de la production sans faire de ce cache la chose qui réveille les gens à 3 heures du matin.
Les données multimodales.
Databricks a tracé une carte solide couvrant l’OLTP, l’entreposage de données, l’analytique en temps réel, la science des données et la gouvernance. Mais les applications d’IA consomment de plus en plus du texte, des images, de l’audio, de la vidéo, des embeddings, des journaux de comportement et des traces d’agents. Ce ne sont pas simplement des objets posés à côté des tables. Ce sont les données que les agents récupèrent, sur lesquelles ils raisonnent, qu’ils transforment et qu’ils réécrivent.
Si les données multimodales restent en dehors de la carte centrale, alors les actifs de données les plus importants pour l’IA vivent encore dans les marges.
L’utilisateur par défaut.
Une grande partie de la surface produit suppose encore un utilisateur humain : tableaux de bord, BI en langage naturel, workflows de type Excel et expériences destinées aux analystes. Tout cela a de la valeur. Mais les agents utilisent les bases de données différemment.
Un agent n’ouvre pas un tableau de bord une fois par jour. Il fonctionne en boucle. Il récupère du contexte, prend une décision, appelle un outil, écrit l’état, vérifie une politique et recommence. Chaque étape peut devoir être auditée. Chaque récupération peut influencer l’action suivante. Chaque écriture peut nécessiter une restauration arrière. Chaque vérification d’autorisation peut devoir se produire à l’exécution.
C’est une charge de travail de base de données différente.
Photo : Unity AI Gateway · Gouvernance —— Databricks Data + AI Summit 2026
Quand l’utilisateur de la base de données est un agent
Pendant des décennies, une base de données pouvait surtout se concentrer sur une question : comment exécuter cette requête correctement et rapidement.
À l’ère des agents, la question devient plus large :
Comment un agent obtient-il le contexte le plus récent, le plus fiable, le moins coûteux et le plus auditable au moment où il prend une décision ?
Ce n’est pas seulement un problème d’optimisation de requête. C’est un problème de systèmes qui traverse le stockage, l’indexation, la gouvernance, la traçabilité, la relecture, le contrôle des coûts et l’application des politiques à l’exécution.
C’est là que la catégorie commence à évoluer. Un système de données ne peut plus être seulement un système d’intelligence : vous posez une question, il renvoie une réponse. Il doit se rapprocher d’un système d’exploitation pour l’IA : l’endroit où les agents lisent le contexte, prennent des décisions, appellent des outils, écrivent de l’état et laissent derrière eux une trace que les humains et les autres systèmes peuvent inspecter.
L’auditabilité ne peut pas être ajoutée après coup. Si un agent donne la mauvaise réponse, prend la mauvaise action ou dépense trop d’argent, la première question sera : qu’a-t-il exactement vu à ce moment-là ?
Pour répondre à cela, le système doit savoir quels documents ont été récupérés, quels vecteurs ont été mis en correspondance, quels filtres de métadonnées ont été appliqués, quel reranker a modifié l’ordre, quel outil a été appelé, quelle politique a été appliquée et quel état a été réécrit. Le débogage et la gouvernance deviennent le même flux de travail.
C’est l’architecture que, selon moi, personne n’a encore pleinement résolue.
Ce que « AI-native » devrait réellement signifier
« AI-native » devient l’une de ces expressions qui peuvent vouloir dire presque n’importe quoi. Je ne pense pas qu’il existe encore de définition nette. Mais si nous partons à rebours des charges de travail réelles des agents, un système de données AI-native doit bien faire au moins quelques choses.
Les données multimodales doivent être de première classe
Le texte, les images, l’audio, la vidéo, les embeddings, les journaux et les traces ne devraient pas être dispersés entre une table relationnelle, une colonne vectorielle, un bucket objet et plusieurs index secondaires. Ils doivent vivre dans un seul système logique où la récupération, le filtrage, le classement et la gouvernance peuvent se faire ensemble.
La partie difficile n’est pas de stocker ces actifs. La partie difficile est de les rendre interrogeables ensemble sans transformer l’architecture en un autre problème de pipeline.
L’élasticité doit partir de la charge de travail
Le trafic des agents est irrégulier. Un système peut rester silencieux pendant une heure, puis recevoir un flot de demandes de récupération, de mémoire et d’utilisation d’outils. Le lac de données ou le stockage objet devrait devenir la fondation durable : bon marché, fiable et découplée du calcul.
Mais le calcul ne devrait pas rester coûteux simplement parce que le corpus existe. Si personne ne recherche, le système devrait dépenser très peu. Si une charge de travail se réveille, le calcul devrait arriver rapidement. Dans ce monde, l’unité naturelle de tarification n’est pas toujours un cluster permanent. Cela peut être la requête, la session ou la minute de calcul actif.
Le multi-tenant doit passer au niveau de l’agent
Les systèmes multi-tenant traditionnels supposent souvent un nombre gérable de grands tenants. Les systèmes agentiques peuvent créer des millions ou des milliards de petits états isolés, éphémères. Chaque agent peut porter sa propre mémoire, ses permissions, ses traces, ses branches temporaires et ses chemins d’écriture.
Une conception pensée pour des milliers de grands tenants aura du mal lorsque le tenant devient l’exécution de l’agent elle-même.
Le branchement et le rollback deviennent des fonctionnalités centrales de la base de données
Les agents écriront la mauvaise chose. Ce n’est pas un cas limite. Cela fait partie de la charge de travail.
Une couche de données IA utile a besoin d’un branchement de type Git et d’un rollback rapide pour l’état des données. Une exécution d’agent devrait pouvoir créer une branche de travail, tester une action, écrire un état temporaire, puis l’abandonner ou le promouvoir. Si une mauvaise mise à jour est appliquée, le système devrait pouvoir revenir rapidement à un point fiable connu.
Le versionnement n’est plus seulement une commodité analytique. Il devient un mécanisme de sécurité opérationnelle.
La trace et la relecture déterministe sont obligatoires
Quand un agent échoue, la question n’est pas seulement « quelle était la réponse finale ? » C’est « qu’est-ce que l’agent a vu, récupéré, classé, décidé, appelé et écrit ? »
Cela exige une trace de chaque étape significative. Plus important encore, cela exige une relecture. Le système devrait être capable de reconstruire le contexte de décision tel qu’il existait à ce moment-là, et non tel qu’il apparaît après qu’un document a changé ou qu’un index a été reconstruit.
Pour les agents, l’auditabilité et la débogabilité se confondent en une même exigence.
Les permissions doivent régir les actions, pas seulement les lignes
L’autorisation traditionnelle demande qui peut lire une table, une colonne ou une ligne. Les systèmes agentiques ont besoin d’une question plus dynamique : qu’est-ce que cet agent est autorisé à récupérer, appeler, modifier, divulguer et dépenser à cette étape précise ?
La difficulté se déplace du chemin de lecture vers le chemin d’action. L’application des politiques doit avoir lieu pendant que l’agent fonctionne, pas seulement lorsqu’un humain ouvre un tableau de bord.
Les opérations doivent devenir autonomes
Le passage à l’échelle au niveau des agents casse l’infrastructure opérée par des humains. Aucune équipe ne peut gérer manuellement les index, la compaction, le préchauffage des caches, le placement des locataires, la reprise et l’ordonnancement des ressources à travers des millions de petites charges de travail rapides et changeantes.
Le système doit s’exploiter lui-même. Sinon, l’architecture peut fonctionner dans un diagramme mais échouer au seul endroit qui compte : la production.
SQL ne suffit pas comme interface finale
Il y a une autre question à laquelle je pense de plus en plus : l’interface elle-même.
SQL était la bonne interface pour l’ère des analystes. Il reste essentiel. Mais pour les entreprises construites autour des bases de données et de l’analytique, SQL peut aussi devenir une forme de dépendance au sentier. La surface produit, le modèle utilisateur et même l’organisation supposent souvent que l’utilisateur principal est quelqu’un qui sait écrire une requête.
L’interface finale pour les données à l’ère de l’IA ne sera pas un éditeur SQL légèrement amélioré. Ce ne sera pas non plus un chatbot collé devant la base de données.
Le point d’aboutissement le plus intéressant est un système de données headless, natif du langage naturel : un système où une personne ou un agent peut énoncer directement l’intention et où le système peut répondre, agir ou préparer le bon plan d’exécution sans exposer chaque étape interne comme un exercice d’écriture de requêtes.
Mais cela doit être natif à la base de données, et non un agent séparé placé devant elle.
Si le langage naturel n’est qu’une couche applicative, le système réintroduit précisément les coutures qu’il essaie de supprimer : une étape de traduction de plus, une fenêtre de contexte obsolète de plus, une faille de gouvernance de plus. La base de données elle-même doit comprendre la question, les données, les politiques et le chemin d’exécution.
C’est beaucoup plus difficile que de construire une interface conviviale. Cela signifie que la base de données doit posséder la sémantique.
Le moat qui compte encore
Je n’ai pas de conclusion parfaitement nette. C’est peut-être approprié. Le marché évolue trop vite, et trop d’anciennes hypothèses sont évacuées plus rapidement que prévu.
Un dialecte de requête propriétaire n’est plus le moat qu’il était. Le coût de migration est plus faible lorsque les agents peuvent réécrire le code d’intégration. Une interface utilisateur familière compte moins lorsque le prochain utilisateur pourrait ne pas être humain. Même l’avantage discret de simplement posséder les données est plus faible lorsque les formats de tables ouverts, les interfaces en langage naturel et les agents utilisant des outils rendent le mouvement plus facile.
Le moat auquel je crois encore est moins glamour : la capacité à créer une vraie valeur utilisateur sur une longue période, patiemment et de façon répétée.
C’est pourquoi je suis reparti du Summit en prenant Databricks au sérieux. Je pense que Databricks a une vraie chance de devenir la prochaine entreprise à mille milliards de dollars dans la data. Pas parce que chaque annonce produit est la réponse finale. Certaines changeront. Certaines seront probablement erronées. C’est normal. Ce qui compte, c’est que l’entreprise continue de revenir vers le bon problème.
Et le bon problème n’est plus seulement l’analytique, l’entreposage de données ou le stockage transactionnel. C’est le socle de données pour des systèmes d’IA qui agissent.
Du côté de Zilliz, nous sommes arrivés à une conclusion similaire par un autre chemin. Les bases de données vectorielles ne disparaissent pas. Elles deviennent le moteur de service au sein d’une architecture plus large pour les données non structurées et multimodales. C’est pourquoi nous pensons en termes de Vector Lakebase : non pas un remplacement des bases de données vectorielles, mais la prochaine architecture construite autour d’elles à mesure que les charges de travail d’IA deviennent plus continues, élastiques et agentiques.
La carte n’est pas terminée. C’est la meilleure partie.
Le bon marché l’emporte sur le coûteux. Le fiable l’emporte sur le non fiable. Le prudent l’emporte sur le négligent. Le patient l’emporte sur l’impatient.
La base de données native de l’IA est encore en train d’être dessinée. Pour tous ceux qui construisent dans cet espace, c’est une très bonne nouvelle.
Une dernière chose : Zilliz Vector Lakebase est disponible en aperçu public
Nous avons lancé l’aperçu public de Zilliz Vector Lakebase — une évolution majeure de Zilliz Cloud, qui passe d’une base de données vectorielle pure à une fondation de données native du lac pour l’IA, combinant le service vectoriel à faible latence avec l’ouverture, l’évolutivité et l’économie d’un data lake.
Fonctionnalités principales de Zilliz Vector Lakebase :
- Service par niveaux optimisé pour différents compromis performance-coût en temps réel
- Recherche à la demande pour les charges de travail à grande échelle ou exploratoires sans calcul toujours actif
- Recherche dans un data lake externe — indexez et recherchez directement dans vos données de lac existantes
- Recherche sur tout le spectre à travers les vecteurs, le texte, JSON et les données géospatiales avec récupération hybride et reclassement
- Stockage unifié natif du lac basé sur Vortex, un format ouvert offrant des lectures aléatoires plus rapides et moins coûteuses que Lance ou Parquet
Si votre pile actuelle sépare le service et la découverte en systèmes distincts, Vector Lakebase pourrait mériter votre attention. Essayez-le sur Zilliz Cloud — les nouvelles inscriptions avec une adresse e-mail professionnelle reçoivent 100 $ de crédits gratuits — ou contactez-nous au sujet de votre cas d’utilisation.
Continuer à lire
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
The Great AI Agent Protocol Race: Function Calling vs. MCP vs. A2A
Compare Function Calling, MCP, and A2A protocols for AI agents. Learn which standard best fits your development needs and future-proof your applications.
Introducing DeepSearcher: A Local Open Source Deep Research
In contrast to OpenAI’s Deep Research, this example ran locally, using only open-source models and tools like Milvus and LangChain.