Au menu de ce numéro, des nouvelles courtes pour commencer : les briques concrètes derrière Genie Ontology, la gouvernance des accès et des coûts de l’IA, deux avancées côté ingénierie (les tests de pipelines et l’API Genie) et un outil du mois qui devrait devenir une habitude.
Puis, pour ceux qui veulent aller au fond, le dossier : Databricks a publié fin juin un article signé Reynold Xin, cofondateur, qui détaille l’architecture de Lakebase et de LTAP (Lake Transactional/Analytical Processing). On y comprend enfin pourquoi ces annonces sont possibles, pas seulement ce qu’elles promettent.

Les briques du contexte d’entreprise

Le premier numéro de Brick Pulse présentait Genie Ontology et son écart de précision spectaculaire face aux agents sans contexte. Ce qui a été moins mis en avant : l’ontologie ne se décrète pas, elle se construit. Trois briques Unity Catalog l’alimentent.

UC Metrics : des KPIs définis une fois, organisés par domaine, accessibles via API, MCP et SQL. Le même chiffre pour l’humain qui ouvre un dashboard et l’agent qui répond à une question. Le point important : UC Metrics fait partie du modèle sémantique. Il ne porte pas seulement le nom des indicateurs, mais aussi les formules à appliquer pour les calculer. Une IA qui connaît la définition exacte de la marge brute (quelles colonnes, quelles exclusions, quel niveau d’agrégation) répond juste ; sans cette connaissance, elle improvise.

Or, ce modèle sémantique vit souvent dans les outils de data viz (Tableau, Power BI), hors de portée des agents. Réponse de Databricks : la commande /importBI de Genie Code (Beta), qui prend un fichier Tableau ou Power BI et génère des metric views reflétant la logique métier, promouvables dans Unity Catalog. L’import reste perfectible face à un modèle mûri pendant des années, mais les cas qui coinçaient se comblent, comme le montre uc-semantics-patterns, des patterns prêts à l’emploi pour la time intelligence et les mesures semi-additives. Et sans rien migrer, importer régulièrement les seules couches sémantiques suffit à rendre les définitions de KPIs exploitables par Genie.

Glossary : des pages de définitions métier reliées entre elles, qui capturent concepts et taxonomies. Genie Code aide à les rédiger et, plus intéressant, signale les définitions qui dérivent de l’usage réel des données.

Domains : l’organisation des assets data et IA en catégories alignées sur le métier, pour donner aux agents comme aux équipes le périmètre pertinent.

C’est ici que se joue la réussite des projets agentiques en 2026-2027 : pas dans le choix du LLM, mais dans ce travail de fond, définir ses métriques, documenter ses concepts, structurer ses domaines. Un travail sans démo spectaculaire, mais c’est lui qui explique l’écart de précision vu dans le premier numéro (84,5 % avec l’ontologie contre 25 à 52 % sans). Bonne nouvelle : ce sont des chantiers qu’on sait cadrer et livrer.

Gouverner les accès et les coûts de l’IA

Trois annonces resserrent le contrôle de la plateforme, des permissions jusqu’à la facture.

Governance Hub : une console centralisée pour les data stewards et les admins. Données, IA, coûts et performance depuis une seule interface, au lieu de quatre écrans pour reconstituer l’état de la plateforme.

ABAC en GA, RBAC en Public Preview :

• Disponible en production : ABAC, le contrôle d’accès par attributs (filtrage de lignes, masquage de colonnes), avec classification de données et governed tags. Sur la feuille de route : règles basées sur les propriétés utilisateur de l’IDP, contexte de la requête (agent, workspace, application) et propagation des tags vers les tables dérivées.
• RBAC, le contrôle d’accès par rôles : l’utilisateur assume un rôle (implémenté comme un groupe Databricks) et, le temps de la session, les permissions du rôle remplacent les siennes au lieu de s’y ajouter. C’est ce qui permet l’accès exclusif : cloisonner par projet, par client ou par essai clinique, sans mélange possible entre les périmètres, avec des actions auditées au nom du rôle.

AI Spend Controls : le premier numéro de Brick Pulse présentait Unity AI Gateway (passé en GA le 4 août) ; voici le volet budgets. Des alertes intégrées aux budgets Databricks, sur quatre granularités cumulables : compte, workspace, cas d’usage (via resource tags, c’est ainsi qu’on gouverne les coding agents en tant que catégorie) et utilisateur. Le scénario qui justifie tout : un job nocturne qui échoue à mi-parcours et dont les retries multiplient le coût par dix en une nuit. Le profil de coût de l’IA n’est pas celui du cloud classique.

Deux précisions avant de déployer. Historiquement de simples alertes, les budgets incluent désormais des plafonds de dépense durs, confirmés par l’annonce de la GA ; leur périmètre reste toutefois limité à l’inférence pay-per-token et ai_query. Et la granularité par cas d’usage repose sur les resource tags : la convention de tagging se pose dès le départ, un tagging fait après coup ne rattrape rien.

Le fil commun : plus la plateforme agit seule (agents, apps, tâches planifiées), plus accès et dépenses doivent être gouvernés par des règles qui s’appliquent partout, pas posés à la main. C’est pourquoi l’ABAC n’est pas un sujet de conformité mais le prérequis des projets agentiques : à prioriser avant, pas après.

Côté ingénierie : embarquer Genie, tester ses pipelines

Deux avancées qui parleront aux équipes de delivery.

Genie sort de l’UI

L’API Agent mode des Genie Agents (Beta, activation via l’équipe de compte Databricks) permet d’exécuter le raisonnement de Genie programmatiquement : on envoie une question en langage naturel, l’agent construit un plan, exécute des requêtes SQL, itère, et renvoie un rapport avec citations.

La valeur de Genie n’est plus captive du workspace : elle s’embarque dans un intranet, un portail métier, ou un rapport du lundi matin généré sans intervention humaine.

L’API est simple ; la valeur se joue dans la curation de l’agent : instructions, métadonnées, questions de référence. C’est là que se concentre le travail. Trois points à annoncer avant de promettre une intégration : un timeout de flux de 90 minutes (à vérifier côté proxys et serverless), une seule réponse en cours par conversation, et les partner-powered AI features à faire valider côté conformité.

Tester (enfin) ses pipelines déclaratifs

Le chaînon manquant des Lakeflow Spark Declarative Pipelines arrive en Beta : des tests unitaires sur données mockées, exécutés dans un schéma de test isolé. Trois primitives (TestPipeline.active(), une fixture test_spark qui redirige toutes les lectures et écritures vers un schéma temporaire, un run() synchrone), des assertions pytest standard, y compris sur les APIs propriétaires comme l’Auto CDC et les expectations.

L’exemple qui vaut la démo : vérifier qu’un événement CDC arrivé en retard n’écrase pas un état plus récent. C’est le bug que tout data engineer a rencontré et que personne ne teste.

Limite à ne pas maquiller : l’exécution se fait depuis l’éditeur web uniquement, sans intégration CI/CD aujourd’hui. C’est un outil de développement, pas un gate de non-régression automatisé. Attention aussi au périmètre de l’isolation : elle ne couvre que les tables référencées par nom. Une lecture ou une écriture par chemin ou par connecteur (Kafka, Auto Loader) la contourne et agit sur la production. Enfin, les données mockées ignorent row filters et column masks : sur un projet où le RLS est critique, prévoir une validation séparée. Le statut Beta peut bouger vite ; à revalider dans les release notes.

L’outil du mois : Lakemeter

Databricks Labs publie Lakemeter, un outil open source d’estimation de coûts : devis multi-workloads (Jobs, DBSQL, Model Serving, Lakebase, Apps…), par cloud, région et tier de pricing, avec un assistant IA pour décrire son workload en langage naturel et un export Excel prêt pour les réponses RFP. L’installation tient en une commande, et détail parlant : Databricks utilise ses propres briques, l’outil tourne sur Databricks Apps, Lakebase et Claude via les Foundation Model APIs.

Limites à garder en tête : les estimations reposent sur les prix du catalogue sans tenir compte des remises négociées et c’est un projet Databricks Labs sans SLA.

Ironie du sort : l’outil de chiffrage peut lui-même consommer pour rien. Lakemeter déploie une Databricks App et une instance Lakebase : deux ressources qui tournent tant qu’on ne leur dit pas de s’arrêter. Après usage, pensez à arrêter l’app et à configurer le scale-to-zero de Lakebase à 5 minutes d’inactivité. Le réflexe vaut au-delà de Lakemeter : toute app déployée « pour essayer » mérite le même traitement.

Le dossier : Lakebase, de Neon à LTAP

Le rachat de Neon, ce n’était pas seulement s’offrir un Postgres serverless avec compute et stockage découplés : l’article de Reynold Xin montre une refonte de la base de données depuis la couche de stockage, dont LTAP est la conséquence directe.

Le point de départ : le monolithe

Presque toutes les bases transactionnelles hébergent sur le disque d’une seule machine leurs deux éléments critiques : le write-ahead log (WAL), qui rend les écritures rapides et sûres, et les fichiers de données, qui rendent les lectures rapides. De cette cohabitation découlent les problèmes classiques de l’OLTP : perte de données si le disque meurt, réplicas et haute disponibilité qui exigent des clones physiques complets, analytique qui dégrade le transactionnel.

La réponse Lakebase : un Postgres sans état

Lakebase rend le compute Postgres stateless : l’instance qui traite vos requêtes ne détient plus aucun état en propre (seulement des caches reconstruisibles) et peut être arrêtée, remplacée ou multipliée sans rien perdre. L’état vit dans des services externes, un pour chacune des deux actions fondamentales d’une base, écrire et lire :

Écrire : le WAL devient le SafeKeeper. Un commit est durable une fois répliqué sur plusieurs nœuds, plus quand un disque local prétend avoir flushé. Aucun coût de latence : toute installation Postgres sérieuse imposait déjà une réplication synchrone.

Lire : les fichiers de données deviennent le PageServer. Un cache en écriture au-dessus de l’object storage, qui reçoit le flux du WAL et matérialise les pages dans le stockage objet. Buffer pool et cache disque local restent en place : le taux de hit ne change pas.

Ce qui en découle mécaniquement : stockage illimité, scale-to-zero, haute disponibilité sans clone physique, et, le plus utile au quotidien, le branching instantané : brancher une base de production devient une opération de métadonnées, en quelques secondes. La base de données se met enfin à bouger aussi vite que le code.

Le benchmark du premier numéro de Brick Pulse prend ici tout son sens : les gains venaient surtout de la désactivation d’une protection Postgres contre les crashes disque, devenue inutile avec cette architecture. Pas une astuce de tuning, une conséquence de la refonte.

LTAP : là où la refonte prend tout son sens

Séparer compute et stockage, d’autres l’avaient déjà fait. La vraie différence de Lakebase : les données opérationnelles atterrissent sur du stockage objet standard, en format ouvert. Et c’est ce choix qui débloque LTAP.

En matérialisant les pages vers le stockage objet, le PageServer transcode les données du format ligne vers du columnar (Parquet, exposé en Delta et Iceberg), sans rien prélever sur le compute transactionnel. Résultat : une seule copie durable, lue par Postgres pour le transactionnel et par les moteurs Lakehouse pour l’analytique. Plus de CDC, plus de liste de tables à répliquer : une table qui existe est déjà dans le lake, déjà requêtable.

Et la fraîcheur, écueil habituel de ces designs ? Une requête analytique demande d’abord à Postgres son LSN courant (un simple numéro de position dans le log), lit l’essentiel depuis le stockage objet, et récupère les tout derniers changements auprès du PageServer. Postgres ne sert aucune lecture analytique : le transactionnel ne ralentit pas parce que quelqu’un a lancé un gros rapport.

Là où le HTAP (Hybrid Transactional/Analytical Processing) courait après un moteur unique capable de tout faire, sans jamais s’imposer, LTAP unifie au niveau du stockage et garde le meilleur moteur pour chaque usage. Vigilance sur le déploiement, progressif sur les prochains mois : Databricks double lui-même les écritures ligne et colonne pendant la transition pour vérifier les données.

Lakebase Search : la même architecture, appliquée au retrieval

Une troisième conséquence de cette refonte vient d’arriver en Beta (AWS et Azure) : Lakebase Search, de la recherche hybride vectorielle et full-text directement dans Postgres, via deux extensions natives, lakebase_vector et lakebase_text.

Le problème que ça résout : les index vectoriels classiques doivent tenir en RAM, alors que la majorité des données de recherche sont rarement interrogées. On paie très cher pour héberger du froid. Avec la hiérarchie de stockage de Lakebase, seules les données réellement utilisées occupent la RAM et le cache ; le reste dort dans le stockage objet à coût quasi nul. Sur le benchmark publié (100 millions de vecteurs), un index qui exigeait 512 Go de RAM tourne sur 192 Go. Et comme tout reste du Postgres standard, une recherche combinant vecteurs, mots-clés et jointures sur les tables applicatives tient dans une seule requête SQL.

La cible assumée : les agents. Leur boucle (récupérer du contexte, raisonner, agir, mémoriser) mêle lecture et écriture en continu. Avec Search intégré, mémoire et retrieval vivent dans le même backend transactionnel, au lieu d’une base vectorielle synchronisée à côté de la base applicative. On retrouve le motif de tout ce dossier : supprimer une copie et le pipeline qui va avec. Pour un service géré de bout en bout (ingestion, embedding, reranking), Databricks AI Search reste la réponse.

Et le réseau ?

Dès qu’une application métier attaque Lakebase, la question du RSSI arrive : le trafic sort-il sur Internet ? La réponse existe désormais en Public Preview sur Azure : un second type de Private Link entrant, dédié aux services performance-intensive (Lakebase Autoscaling, Zerobus Ingest).

C’est toutefois un chantier réseau à part entière (sous-réseau dédié, DNS manuel) avec deux pièges : la portée est au niveau du compte et affecte tous les workspaces Premium de la région ; et Private Link ne ferme pas l’accès public, qui reste un réglage indépendant à désactiver explicitement.

Un audit qui coche « Private Link en place » sans vérifier l’accès public valide une protection incomplète.

Pour conclure

Un fil relie tous ces sujets : Databricks ne construit plus des fonctionnalités, il s’attaque aux fondations. Le stockage transactionnel, le contexte métier, le contrôle des accès et des coûts, et l’outillage pour industrialiser le tout, des tests de pipelines aux APIs d’agents. Ce sont des chantiers moins visibles qu’une démo de keynote, mais ce sont eux qui détermineront quelles plateformes tiendront la charge de l’ère agentique.

Vous vous interrogez sur ce que LTAP ou l’ABAC changeraient dans votre architecture ? Échangeons ensemble pour l’évaluer sur votre contexte.

À bientôt.

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

Sources

• From monolith to Lakebase to LTAP: rethinking the database from storage up — Databricks Blog, 30 juin 2026
• What’s new in Databricks Data+AI Summit Edition Part 1 — NextGenLakehouse, 20 juillet 2026
• Import BI files using Genie Code — Documentation Azure Databricks
• Announcing Lakebase Search: agent-native retrieval built into Lakebase Postgres — Databricks Blog, 16 juin 2026
• Configure inbound Private Link for performance-intensive services — Documentation Azure Databricks
• Introducing AI spend controls with Unity AI Gateway — Databricks Blog, 19 mai 2026
• Unity AI Gateway is Generally Available — Databricks Blog, 4 août 2026
• Role-based access control (RBAC) — Documentation Databricks
• Unit testing for pipelines — Documentation Databricks
• Agent mode APIs in Genie Agents — Documentation Databricks
• Lakemeter — User Guide (Databricks Labs)
• uc-semantics-patterns — patterns pour Unity Catalog semantics (GitHub databricks-solutions)

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.