Chaque année, le Data+AI Summit de Databricks réunit la communauté mondiale de la data et de l’IA. Cette année, 82 000 inscrits, dont près de 29 000 en présentiel à San Francisco — et j’en faisais partie. Cette première édition est entièrement dédiée à ce que j’ai vu, entendu et ressenti depuis l’intérieur de l’événement.

L’événement de l’intérieur

Le Moscone Center au cœur de San Francisco, pris d’assaut par des milliers de personnes portant le même badge rouge. L’événement déborde sur plusieurs bâtiments — Moscone South, North et West, le Marriott, le Theater at YBCA — tout se fait à pied, avec une application dédiée pour s’orienter entre les sessions.

Ce que l’on ne sait pas avant d’y être — ces dispositifs n’existent pas en version distante :

Les certifications. Un espace dédié permet de passer ses certifications Databricks sur place. Ceux qui réussissent reçoivent une veste avec le badge de la certification — un signal visible dans les couloirs.

Les BrainDates. Des sessions informelles avec un Solution Architect Databricks, pour poser les vraies questions sur des cas d’usage concrets. Un format très utile pour aller au-delà du discours commercial.

Les Executive Forums. Réservés aux clients VIP, avec des présentations spécifiques et la possibilité d’échanger directement avec des représentants d’OpenAI, par exemple.

Les keynotes se tiennent de 8h à 11h dans Moscone South, une salle monumentale avec des dizaines d’écrans muraux et suspendus. Ali Ghodsi, CEO de Databricks, ouvre et clôture chaque journée. Sur les trois jours, j’ai suivi une quinzaine de sessions en plus des deux keynotes.

Les keynotes

Ali Ghodsi a ouvert sur une question qui a planté le décor : l’AGI — l’Intelligence Artificielle Générale, capable de comprendre et de s’adapter à n’importe quelle tâche cognitive, de transférer ses compétences entre domaines — est-elle déjà là ? Pas de réponse définitive depuis la scène, mais le fait que le CEO de Databricks pose la question frontalement, devant 29 000 personnes, dit quelque chose sur où en est l’industrie. Ce n’est plus un horizon de science-fiction ; c’est une hypothèse de travail qui va revenir dans tous les débats des prochains mois.

Le fil rouge de ces deux jours : Databricks ne parle plus seulement de plateforme data. Il parle de plateforme agentique. D’abord supprimer ce qui complique inutilement — pipelines de synchronisation, tâches opérationnelles répétitives, fossé permanent entre le métier et la donnée. Puis encadrer ce qui reste. Parce qu’une plateforme qui agit plus, plus vite, avec moins d’intervention humaine pose une question inévitable : qui contrôle quoi, et comment ?

Genie Ontology / Genie One — Au-delà de la précision des LLMs sur des données brutes, l’enjeu est de fournir aux agents un contexte cohérent et structuré : les métriques de l’entreprise, ses concepts métiers, les relations entre entités. Genie One est le coworker IA que Databricks construit sur cette fondation — pas une feature supplémentaire, mais une réorganisation de ce qui existait autour d’un contexte d’entreprise unifié. La différence de résultat est concrète : 84,5 % de précision avec l’ontologie sur des questions de production, contre 25 à 52 % pour des coding agents travaillant sur les mêmes données sans ce contexte.

Ontology, ça sonne comme une nouvelle spécialité à l’hôpital. Le principe, c’est celui de l’onboarding : on explique à un nouvel arrivant l’organigramme, les acronymes, les indicateurs. Quelques semaines plus tard, elle est opérationnelle. Maintenant, imaginez onboarder plusieurs nouveaux collaborateurs chaque jour.
Même problème côté agentique : sans contexte — ou avec un contexte erroné — les réponses seront à côté. L’ontologie expose un référentiel global, centralisé et régulièrement mis à jour, sur lequel tous les agents s’appuient. Point de vigilance : construire cette base implique de scanner CRM, bases documentaires, etc. — ce qui nécessite des ouvertures de flux à valider côté sécurité en amont.
Une tendance de fond à suivre — le sujet reviendra dans les prochaines éditions.

Genie ZeroOps — La surveillance des incidents de production devient une responsabilité de l’agent. Dans la démo, 13 incidents actifs dont des dashboards cassés suite à un changement de schéma : l’agent remonte à la cause racine, prépare un correctif, le valide sur un shallow clone, et attend une validation humaine avant toute action. La ligne entre automation et supervision reste explicitement tracée.

Une aide à l’exploitation, pas un remplacement. Le système règle une partie des incidents opérationnels sans attendre une intervention humaine — et capitalise sur les problèmes récurrents. Ça ne signifie pas qu’il n’y a plus de travail pour opérer la plateforme, mais le curseur se déplace : de la résolution vers la supervision. À tester sur des cas réels pour mesurer l’écart entre la démo et la pratique.

Lakehouse//RT — Le franchissement d’un seuil que beaucoup considéraient comme structurel : la latence minimale d’une seconde pour requêter des données fraîches dans le Lakehouse. Sur le dataset NYC taxi, la démo passe de 1,16 s à 7 ms. Le moteur derrière cette performance, Reyden, est présenté comme entraîné sur des zettaoctets de données de production et supérieur à tous les benchmarks existants au seuil de 1 To.

À ne pas systématiser, mais à étudier cas par cas. C’est pertinent pour des usages qui exigent un fort taux de rafraîchissement et une mise à disposition très rapide des données. Attention : ça reste de l’analytique. Pour du transactionnel, c’est Lakebase.

LTAP (Lake Transactional/Analytical Processing) — Une seule copie de données pour servir à la fois le transactionnel (Lakebase) et l’analytique (Lakehouse), sans CDC ni pipeline de synchronisation intermédiaire. L’industrie travaillait à ce problème depuis une décennie sans parvenir à l’adresser sans compromis majeur.

LTAP répond à l’enjeu du HTAP (Hybrid Transactional/Analytical Processing). Plus besoin d’utiliser Lakebase CDF pour synchroniser vers des tables Lakehouse, ni Lakehouse Sync dans l’autre sens. Un seul stockage, deux types d’exploitation. De nombreux cas d’usage sont facilités — notamment le reverse ETL : produire de la donnée depuis l’analytique pour l’exposer à du transactionnel.

Omnigent / Agent Bricks — Le problème de fond : on utilise plusieurs agents en parallèle — un pour coder, un pour chercher, un pour reviewer — et on passe son temps à copier-coller entre eux. Chaque harness (Claude Code, Codex, Pi…) est un silo avec son propre contexte, ses propres contrôles. Rien ne passe de l’un à l’autre. Omnigent est la couche qui se place au-dessus : un meta-harness open source (Apache 2.0), signé Matei Zaharia, qui enveloppe n’importe quel agent derrière une interface commune. L’analogie est juste : Kubernetes est aux serveurs ce qu’Omnigent est aux agents. On ne gère plus des processus individuels, on pilote une flotte. Trois axes : composition (combiner plusieurs harnesses dans un workflow YAML), contrôle (politiques stateful — plafonds de dépenses, validation humaine conditionnelle, sandbox OS) et collaboration (sessions partageables en temps réel, co-pilotage, accessibles depuis n’importe quel appareil). Agent Bricks est la version enterprise construite sur cette fondation, intégrée nativement dans Databricks avec Unity Catalog et gouvernance incluse.

L’annonce n’est pas évidente à saisir au premier abord. Ce qu’il faut retenir : Omnigent permet de faire travailler plusieurs agents ensemble sans réécrire de code, de centraliser la gouvernance de ce qu’ils peuvent faire, et de collaborer à plusieurs autour d’une même session. Une brique discrète, mais qui change l’échelle à laquelle on peut déployer des architectures multi-agents.

Unity AI Gateway — L’ambition : administrer l’ensemble des usages IA d’une organisation, qu’il s’agisse de LLMs exposés aux métiers ou des outils du quotidien des équipes techniques. La démo s’appuyait sur un cas réel parlant : 82 % des sessions interrogeaient Claude Opus indépendamment de la complexité de la tâche, pour un surcoût de plus de 500 dollars. Le Smart Routing adresse ça automatiquement — Kimi 2.7 pour les tâches simples, GPT-5.5 pour les complexes. Mais la dimension la plus intéressante reste peut-être la gouvernance : politiques contextuelles en SQL, contrôle des MCP autorisés, guardrails par utilisateur ou par équipe.

Une gouvernance IA est indispensable sur plusieurs plans : maîtrise des coûts, sécurité, stratégie. Unity AI Gateway peut couvrir les usages IA au sein de Databricks, mais aussi à l’échelle de l’organisation entière — y compris les coding agents utilisés par les équipes. L’avantage structurel : la gouvernance ne repose pas sur un outil en particulier. Au vu de la vitesse des évolutions, c’est une décision d’architecture qui s’avèrera payante.

Databricks Apps — Databricks revendique 5 000 clients et 150 000 apps créées, avec un objectif d’un milliard d’apps d’ici 2028. Trois briques complémentaires pour y parvenir : Genie App Builder (création assistée par IA, Unity Catalog natif, AppKit SDK TypeScript), App Spaces (versioning, sécurité, contrôle des déploiements) et Serverless Micro Apps (scale-to-zero pour les cas légers). Le Databricks Marketplace s’ouvre en parallèle aux applications tierces — 20 partenaires au lancement, les droits Unity Catalog s’appliquent par défaut, sans mouvement de données.

L’ambition est claire : permettre aux utilisateurs métiers de créer leurs propres applications, sans dépendre systématiquement de la DSI. Genie App Builder ouvre la porte, App Spaces pose le cadre pour éviter les dérives, Genie ZeroOps veille en production. La chaîne création-gouvernance-supervision est complète — sur le papier.

Genie Code for ML + Genie ZeroOps for ML — Même logique que pour les Apps, appliquée aux modèles : Genie Code automatise la production de code ML, Genie ZeroOps for ML surveille les systèmes en production et propose des correctifs. La promesse : multiplier les modèles sans multiplier la charge opérationnelle.

Même logique que pour les Apps : donner aux équipes plus d’autonomie pour créer et déployer des agents. Mais qui dit prolifération d’agents dit charge de monitoring en proportion. Genie Code for ML et Genie ZeroOps for ML fonctionnent en binôme — l’un crée, l’autre surveille. Le même pari qu’App Spaces : la gouvernance doit suivre le rythme de la création.

CustomerLake — Une CDP agentique intégrée pour résoudre l’identité client à grande échelle et personnaliser les campagnes en continu.

Techniquement bien pensé. Je reste néanmoins sceptique sur la capacité de Databricks à convaincre des équipes marketing solidement installées dans leur stack — c’est un marché déjà très occupé, avec des acteurs spécialisés depuis des années.

Lakewatch — Un SIEM agentique pour détecter les menaces en temps réel, présenté avec Panther.

J’ai observé quelque chose de révélateur pendant la keynote : une partie de l’audience a décroché sur CustomerLake, une deuxième vague est partie avec Lakewatch. La sécurité ne remplit pas les salles. C’est précisément le problème.

OpenSharing — La prochaine évolution de Delta Sharing : partager des données, des modèles, et désormais des Genie Agents entre organisations, le tout gouverné par Unity Catalog. SecureConnect supprime la gestion des IP allowlists par destinataire ; Global Distribution réplique automatiquement les assets cross-cloud et cross-région sans frais d’egress. Le fait de pouvoir partager un Genie Agent — et non seulement des données — change la nature du produit : on ne partage plus de la matière première, on partage une capacité d’analyse.

Ce que change vraiment le partage des Genie Agents : quand on partage des données avec un partenaire, il faut généralement tout re-documenter de son côté — descriptions de tables et de colonnes, règles de calcul, requêtes de référence. Partager un agent, c’est embarquer le modèle sémantique avec. Le partenaire hérite du contexte, pas seulement de la matière première. Moins de perte en ligne, plus de cohérence dans l’exploitation.

Derrière toutes ces annonces, la même conviction : une plateforme qui fait plus avec moins d’intervention humaine n’a de valeur que si elle reste gouvernable. Simplification et gouvernance ne sont pas deux sujets — c’est le même, vu des deux côtés.

Databricks articule sa plateforme autour de quatre piliers : Contexte, Contrôle, Coût, Choix. Le quatrième — le Choix — se matérialise par un engagement fort sur l’open source : Omnigent, Delta Lake, Spark Declarative Pipelines. Ali Ghodsi a été direct sur les formats : peu importe que vous utilisiez Delta Lake ou Iceberg, ou les deux. Ce débat est devenu anecdotique face aux vrais enjeux.

Sur les fonctionnalités existantes

Quelques jalons qui méritent d’être notés. Lakeflow Connect atteint une centaine de connecteurs, Lakeflow Designer passe en GA, et Lakeflow Jobs franchit un cap avec l’External Orchestration : déclencher un job Snowflake, une API REST, une alerte PagerDuty depuis un pipeline Databricks, compute suspendu pendant l’attente — avec 40+ exemples d’opérateurs à venir sur GitHub. Unity Catalog s’étend désormais aux modèles, agents et services MCP, avec lineage externe en GA, namespace cross-cloud à 4 niveaux et type FILE multimodal.

AI-First Data Engineering — Les fonctions SQL natives ai_extract, ai_classify, ai_parse_document, ai_translate ne sont pas des nouveautés, mais les résultats terrain arrivent : Kard les utilise sur des milliards de transactions, Banco Bradesco cite -50 % de temps de développement. L’IA n’est plus un module en bout de chaîne — elle devient une primitive du pipeline.

Ces fonctions ne sont pas des nouveautés — elles existent depuis le début d’année. Ce qui change, c’est qu’on commence à en voir les résultats en conditions réelles. Les cas d’usage se diversifient : enrichissement de pipelines ETL, mais aussi préparation de données non structurées pour de l’embedding. Des résultats probants qui donnent confiance sur la direction prise.

Sessions : ce qui m’a marqué

Sur la quinzaine de sessions suivies en parallèle des keynotes, trois m’ont particulièrement interpellé.

Observability : quand la télémétrie devient une donnée comme les autres

J’avais choisi cette session avant les keynotes, sans savoir de quelles fonctionnalités, il allait être question. C’est sur place que j’ai découvert qu’elle portait précisément sur l’une des annonces phares de la première journée : Lakehouse//RT. Une belle illustration du fait que certaines sessions prennent tout leur sens une fois le contexte des annonces posé.

La promesse de cette session tient en une seule requête SQL :

SELECT t.trace_id, t.duration_ms, c.account_name, c.arr
FROM   telemetry.prod.traces t
JOIN   sales.crm.accounts c ON t.attributes['customer.id'] = c.customer_id
WHERE  c.account_tier = 'enterprise'
  AND  t.start_timestamp > now() - INTERVAL 5 MINUTES
  AND  t.duration_ms > 2000
ORDER BY c.arr DESC

« Every enterprise-tier request over 2 seconds in the last 5 minutes, ranked by revenue at risk. One statement on one platform. »

Cette requête — impossible ailleurs — devient triviale dès lors que la télémétrie (logs, métriques, traces) cohabite avec les données métier dans le même Lakehouse. C’est l’idée centrale de la session : ingérer les données OpenTelemetry via ZeroBus, les stocker dans des tables Delta, et les requêter via Lakehouse//RT avec une latence inférieure à 200 ms.

L’objection historique — « Delta est trop lent pour l’observabilité » — est levée. Pour ceux déjà sur OpenTelemetry, la migration est littéralement un changement de configuration : pointer l’exporteur vers l’endpoint ZeroBus et configurer le token. La possibilité de dual-export permet une transition progressive sans lock-in.

Ce cas d’usage illustre quelque chose de plus large : la télémétrie n’est que de la donnée. En la faisant cohabiter avec les données CRM ou le feature store, on débloque des analyses croisées qui n’existaient pas, ou s’avéraient impossibles dans des délais aussi courts.

Benchmark Lakebase : chasser le bottleneck

Cette session est une leçon d’ingénierie autant qu’une annonce produit.

Le référentiel utilisé est un workload OLTP dérivé du standard TPC-C, qui mesure le nombre de nouvelles commandes traitées par minute (NOPM). Databricks l’a exécuté sur quatre configurations de Lakebase — 1, 4, 16 et 24 vCPU — en comparant les résultats à d’autres offres Postgres managées déployées dans la même région cloud.

Le résultat de départ — 77 800 NOPM — a été porté à 614 000 NOPM sur 16 vCPU, soit un gain de 7,9×, via trois optimisations successives. Le saut le plus important vient d’une particularité structurelle : l’architecture de Lakebase sépare entièrement le compute du stockage, ce qui rend inutile un mécanisme de protection standard de PostgreSQL conçu pour les crashes disque. Désactivé intelligemment au niveau de la couche storage, ce seul changement a éliminé 94 % du volume WAL et doublé le débit. À noter : entre 16 et 24 vCPU, le gain devenait négligeable. Le bottleneck n’était plus le compute.

En face, le meilleur concurrent testé plafonnait à 444k NOPM sur le même benchmark, à latence p95 équivalente. Ces performances restent en conditions de laboratoire, avec un déploiement progressif en production prévu dans les prochains mois — mais la méthodologie est rigoureuse et le dispositif de comparaison est publié.

Lakebase permet de réduire le chemin entre l’analytique et le transactionnel mais s’avère aussi être une offre managée de Postgres extrêmement performant !

Phishing Triage : le knowledge graph comme mémoire institutionnelle

99 % des emails signalés par les utilisateurs sont bénins. Mais chaque cas est une investigation fraîche, et le 1 % malveillant ne peut pas être manqué.

L’équipe de CVS Health a présenté Langphish, un système agentique qui automatise ce triage. La clé de l’architecture : un knowledge graph qui mémorise chaque campagne résolue. Quand un nouvel email arrive, le système calcule dans quelle mesure ses éléments — expéditeur, URLs, corps du message — correspondent à des cas déjà traités. Dans la démo, 73 % des nœuds du nouvel email étaient déjà présents dans la mémoire du graphe.

C’est ce contexte qui donne aux agents leur pertinence. Sept agents spécialisés (Llama 3.3 70B) analysent en parallèle chaque dimension de l’email — en-têtes, expéditeur, URLs, comportement, historique. Un huitième agent (Claude Sonnet 4 avec extended thinking) synthétise et produit un VerdictReport structuré, cité, auditable.

Le verdict sur l’email de démonstration : « CREDENTIAL PHISHING · confidence VERY_HIGH — Spoofed Microsoft 365 expiry lure, correlated to campaign C-8821 (14 prior cases). » Pas un label. Une investigation avec ses preuves.

Ce qui m’a frappé ici, c’est le rôle central du knowledge graph. Un agent seul, sans mémoire, voit chaque email pour la première fois. Avec le graphe, il hérite de l’expérience accumulée de chaque analyste ayant traité un cas similaire avant lui. C’est exactement ce que Genie Ontology essaie de faire pour la donnée métier — la même logique appliquée à la cybersécurité.

Pour conclure

Trois jours, deux keynotes, une quinzaine de sessions, des dizaines de conversations dans les jardins de Yerba Buena. Ce que je retiens de cette édition 2026 : Databricks ne parle plus seulement de plateforme data. Il parle de plateforme agentique. Et la différence n’est pas cosmétique — elle se traduit dans chaque annonce, chaque session, chaque démo.

La prochaine édition reviendra sur l’actualité autour de Databricks avec notamment les nouvelles fonctionnalités — leurs intérêts, leurs impacts réels — et sur ce que l’IA change concrètement dans nos architectures et nos pratiques. Avec, en toile de fond, l’écosystème data au sens large.

Vous vous demandez lesquelles de ces nouveautés sont réellement pertinentes pour votre contexte ? Échangeons ensemble pour identifier les cas d’usage les plus adaptés à votre organisation.

À bientôt.

Donatien Tessier — Head of Data, I-Shane | Databricks Champion

Brick Pulse est publié par I-SHANE pour partager une lecture indépendante des évolutions de l’écosystème Databricks et des plateformes Data & IA.