Je retiens surtout un virage très clair vers l’IA en production. Databricks pousse Genie One, LTAP, Unity AI Gateway et Lakewatch SIEM pour industrialiser les agents, réduire les pipelines et mieux contrôler les coûts. Le vrai sujet, c’est ce qui est prêt maintenant et ce qui reste à surveiller.
Besoin d'aide ? Découvrez les solutions de notre agence IA.
Quelles annonces changent vraiment la donne ?
Ce que je retiens vraiment, c’est que Databricks a changé de sujet. On n’est plus seulement dans “comment construire un agent IA”. On passe à “comment l’exploiter en entreprise sans exploser les coûts, la sécurité, la gouvernance et les nerfs de la DSI”.
Les annonces les plus structurantes, pour moi, sont assez claires : Genie One en disponibilité générale, LTAP pour rapprocher transactionnel et analytique, Unity AI Gateway pour mieux contrôler les dépenses des agents, et l’acquisition de Panther pour muscler Lakewatch SIEM, la brique cybersécurité de Databricks.
Genie One est important parce qu’il pousse l’usage de la donnée vers les métiers. Un utilisateur peut poser des questions, explorer ses données, produire des analyses, sans dépendre à chaque fois d’une équipe Data. C’est souvent là que les projets data se coincent chez mes clients : La donnée existe, mais l’accès métier reste trop lent.
LTAP, ça veut dire qu’on rapproche deux mondes qui étaient souvent séparés : Le transactionnel, avec les opérations en temps réel, et l’analytique, avec les analyses sur gros volumes. Si Lakebase OLTP est bien disponible en production, ça peut simplifier beaucoup d’architectures. Moins de copies, moins de latence, moins de tuyauterie fragile.
Unity AI Gateway est aussi une annonce très concrète. Quand des agents appellent des modèles IA toute la journée, les coûts peuvent partir vite. Là, l’idée est de mettre des plafonds, des règles, du routage vers différents modèles, et de la supervision. C’est moins sexy qu’une démo d’agent, mais c’est exactement ce qu’il faut pour passer à l’échelle.
Les chiffres donnent un signal intéressant : Environ 30K participants en personne, plus de 100K agents construits sur Agent Bricks, plus d’un quadrillion de tokens traités par an. Ça ne prouve pas que tout marche partout. Mais ça montre que l’adoption est déjà massive.
Le vrai point de vigilance, c’est la maturité. Tout n’est pas prêt pour la production. Genie One et Lakebase OLTP sont annoncés comme generally available, donc utilisables plus sereinement. CustomerLake, Genie App Builder, Genie ZeroOps, Agent Memory Service, Databricks Sandbox et plusieurs briques restent en aperçu privé, preview ou bêta. Pour une DSI, une équipe Data ou une direction métier, ça change tout. On ne pilote pas un déploiement production comme un test de laboratoire.
| Annonce | Statut | Intérêt business | Point de vigilance |
| Genie One | Generally available | Accès plus direct à l’analyse pour les métiers | Qualité des données et droits d’accès à cadrer sérieusement |
| Lakebase OLTP et LTAP | Generally available | Rapprochement du transactionnel et de l’analytique | Architecture à valider sur les cas critiques avant migration large |
| Unity AI Gateway | Disponible selon les usages Databricks | Contrôle des coûts, des modèles et des appels agents | Règles de gouvernance à définir avant l’ouverture aux équipes |
| Panther et Lakewatch SIEM | Acquisition annoncée | Renforcement de la sécurité et de la détection d’incidents | Intégration produit à suivre dans les prochains mois |
| CustomerLake, Genie App Builder, Genie ZeroOps, Agent Memory Service, Sandbox | Aperçu privé, preview ou bêta | Promesse forte pour industrialiser les agents IA | À traiter comme des expérimentations, pas comme des fondations production |
Pourquoi Genie One devient central ?
Genie One devient central parce qu’il déplace l’IA là où les équipes travaillent vraiment. Ce n’est pas juste un outil pour data scientists ou ingénieurs data. C’est pensé comme un assistant IA inter-départemental, disponible en disponibilité générale sur web, iOS et Android, donc utilisable par les ventes, la finance, les opérations, le marketing, le support.
Je le vois comme une couche d’accès conversationnelle aux données et aux usages IA de l’entreprise. Au lieu de demander un nouveau dashboard, d’ouvrir un ticket BI, ou d’attendre qu’un analyste sorte une requête SQL, un métier peut poser une question en langage naturel. SQL, c’est le langage utilisé pour interroger les bases de données, mais soyons honnêtes, ce n’est pas le quotidien de la plupart des équipes.
Ce que ça change concrètement, c’est l’accès. Une personne peut demander pourquoi les ventes baissent sur une région, comparer des segments clients, retrouver une tendance, ou comprendre un indicateur sans repartir de zéro à chaque fois. Le dashboard figé reste utile, mais il ne répond pas toujours à la question du moment. Genie One essaie de combler cet espace entre la donnée disponible et la décision à prendre.
Je reste prudent quand même. Un assistant IA ne rend pas magiquement les données propres. Il ne règle pas tout seul les droits d’accès, la gouvernance, les définitions contradictoires entre équipes, ou le manque de contexte métier. Si votre chiffre d’affaires n’a pas la même définition entre la finance et le commerce, l’IA risque surtout d’amplifier la confusion.
Les autres briques annoncées vont dans la même direction, mais elles restent à surveiller de près :
- Genie App Builder peut simplifier la création d’applications IA à partir des données et des processus internes.
- Genie ZeroOps peut réduire la charge d’exploitation, c’est-à-dire tout ce qui concerne le déploiement, la maintenance et le suivi technique.
- CustomerLake reste en aperçu privé, donc intéressant, mais je ne le vendrais pas encore comme une capacité acquise.
Chez beaucoup de clients, le vrai blocage n’est pas l’envie d’utiliser l’IA. L’envie est là. Le problème, c’est la capacité à donner un accès fiable, sécurisé et compréhensible aux bonnes données. C’est exactement là que Genie One peut devenir utile, à condition que la gouvernance suive.
Genie One est prometteur pour démocratiser l’IA dans l’entreprise. Sa vraie valeur dépendra moins de l’interface conversationnelle que de la qualité du socle data, des règles d’accès, et de la confiance que les équipes auront dans les réponses.
LTAP peut-il vraiment remplacer l’ETL ?
Oui, LTAP peut réduire fortement le besoin d’ETL et de CDC. Mais non, je ne dirais pas que ça remplace tous les pipelines dans tous les cas. Le vrai sujet, c’est qu’on arrête de déplacer de la donnée juste pour la rendre utilisable ailleurs.
Le problème classique, vous le connaissez sûrement. D’un côté, les bases opérationnelles qui font tourner les applications. De l’autre, les tables analytiques dans le lakehouse ou le data warehouse. Entre les deux, on empile des pipelines ETL, des flux CDC, des jobs de réplication, des contrôles, des reprises sur erreur, des alertes. Et malgré tout ça, il reste souvent un décalage entre ce que l’application voit et ce que l’analytique raconte.
LTAP, pour Lakehouse Transactional Analytical Processing, répond à cette friction. L’idée est de rapprocher les usages transactionnels et analytiques sur une même architecture, avec moins de copies, moins de synchronisation, et une donnée disponible plus vite. Chez Databricks, ça passe notamment par Lakebase, une couche transactionnelle Postgres serverless OLTP, annoncée generally available plus tôt en 2026, et intégrée à l’écosystème Databricks.
Concrètement, Lakebase vise les applications transactionnelles. OLTP veut dire Online Transaction Processing, donc les bases conçues pour gérer des opérations fréquentes, comme créer une commande, mettre à jour un client, enregistrer un événement produit. Le point intéressant, c’est que cette base opérationnelle s’inscrit dans le même monde que le lakehouse analytique, avec une copie de données plus maîtrisée et des formats ouverts.
Databricks a aussi présenté Lakebase Search en bêta, avec une recherche hybride vecteur plus texte. C’est utile pour l’IA, parce qu’un agent ne cherche pas toujours un mot exact. Il peut chercher une information proche sémantiquement, tout en ayant besoin de précision textuelle.
Lakehouse RT ajoute une autre brique importante. C’est le moteur de requête temps réel alimenté par Reyden. Je reste prudent sur ce qu’on peut en conclure, mais le signal est clair : si on veut des agents et des applications IA utiles, ils doivent travailler sur des données fraîches, pas sur un snapshot de la veille.
Je garde une nuance importante. Supprimer des pipelines ne veut pas dire supprimer la modélisation, les contrôles qualité, la sécurité ou l’observabilité. Dans mes missions, c’est souvent là que les projets gagnent ou perdent du temps.
LTAP est pertinent dans ces cas :
- Applications data-driven qui doivent lire et écrire sur des données proches de l’analytique.
- IA opérationnelle avec agents, recommandations, assistants internes ou automatisations métier.
- Analytics quasi temps réel sur des événements récents.
- Réduction des copies entre bases opérationnelles et lakehouse.
- Simplification des flux CDC quand la synchronisation devient trop lourde.
Avant la production, je vérifierais surtout :
- Statut réel des composants, entre disponibilité générale, bêta et limites annoncées.
- Gouvernance des accès, des données sensibles et des usages IA.
- Performances sur vos volumes, vos écritures et vos requêtes critiques.
- Coûts serverless, stockage, requêtes temps réel et montée en charge.
- Intégration avec l’existant, surtout si votre SI a déjà beaucoup de pipelines et d’outils CDC.
Comment Databricks encadre les agents IA ?
Databricks encadre les agents IA avec une logique assez saine à mon avis : il ne vend pas juste “un agent magique”, il empile plusieurs briques pour construire, exécuter, sécuriser, tester et limiter les dégâts. C’est exactement là que les vrais sujets commencent en entreprise.
Agent Bricks est la brique centrale. Je le vois comme une plateforme développeur pour passer du prototype sympa en démo à un agent exploitable en production. On y retrouve la construction, le déploiement et la gouvernance. Databricks met aussi en avant un signal d’adoption fort : plus de 100K agents auraient été construits avec Agent Bricks. C’est intéressant, mais je reste prudent. Construire beaucoup d’agents ne veut pas dire qu’ils sont tous utiles, rentables, maintenables ou correctement gouvernés. J’ai déjà vu des clients avec dix pilotes IA, et seulement deux vrais cas d’usage qui tenaient la route.
Agent Memory Service adresse un point souvent sous-estimé : la mémoire. Un agent utile doit garder du contexte. Ce qu’il a déjà fait, ce que l’utilisateur préfère, ce qui a échoué, ce qui marche. Databricks propose une mémoire gérée construite sur Lakebase, avec un niveau court terme et un niveau long terme. L’intégration avec LangGraph et OpenAI Agents SDK est aussi prévue, ce qui évite de repartir de zéro côté framework. Mais c’est encore en aperçu. Et une mémoire mal contrôlée peut vite poser problème : coût qui grimpe, données sensibles conservées trop longtemps, réponses polluées par du mauvais contexte.
Databricks Sandbox répond à un autre sujet très concret : que se passe-t-il quand un agent génère ou exécute du code ? Là, l’isolation devient sérieuse. La Sandbox utilise des machines virtuelles isolées, avec un accès Unity Catalog restreint, pour exécuter du code d’agent non fiable sans exposer tout l’environnement data.
Omnigent, lui, est un meta-harness open-source sous licence Apache 2.0. Dit simplement, ça sert à combiner plusieurs frameworks d’agents. C’est utile parce que personne n’a envie d’être enfermé dans un seul framework alors que l’écosystème agentique change tous les trois mois.
Unity AI Gateway est probablement l’annonce la plus pragmatique côté pilotage. On peut définir des plafonds de dépense stricts pour arrêter automatiquement des agents trop coûteux. Un agent qui boucle, qui appelle trop souvent un modèle ou qui traite trop de contexte peut coûter cher très vite. Le plafond sert de garde-fou.
| Brique | Rôle | Maturité | Risque adressé |
| Agent Bricks | Construire, déployer et gouverner des agents | Plateforme mise en avant, adoption annoncée à plus de 100K agents | Passage du prototype à la production |
| Agent Memory Service | Gérer la mémoire court terme et long terme sur Lakebase | En aperçu | Perte de contexte, coût mémoire, confidentialité, qualité des réponses |
| Databricks Sandbox | Exécuter du code non fiable dans des machines virtuelles isolées | Brique de sécurité dédiée | Exécution dangereuse, accès excessif aux données |
| Omnigent | Combiner plusieurs frameworks d’agents | Open-source Apache 2.0 | Verrouillage fournisseur ou framework |
| Unity AI Gateway | Définir des plafonds de dépense et stopper les agents coûteux | Annonce concrète de gouvernance | Dérive des coûts et appels modèles incontrôlés |
Que faut-il surveiller avant de déployer ?
Je retiens surtout une chose avant de déployer quoi que ce soit : il ne faut pas confondre une annonce de sommet avec une brique prête pour une production maîtrisée. Databricks avance vite, très vite même, mais chaque nouveauté doit être regardée avec une grille simple : statut réel, gouvernance, sécurité, observabilité, coûts et intégration avec votre existant.
Plusieurs fonctionnalités annoncées restent en aperçu privé, en preview ou en bêta. Je pense à CustomerLake, Genie App Builder, Genie ZeroOps, Agent Memory Service, Databricks Sandbox ou Lakebase Search. Ces briques peuvent être très intéressantes, clairement. Mais avant de les brancher à des données sensibles ou à des processus critiques, je regarde la roadmap, le niveau de support, les SLA, c’est-à-dire les engagements de disponibilité, la conformité, et les dépendances techniques.
| Ce que je peux tester maintenant | Des démonstrations, des prototypes, des cas non critiques, avec des jeux de données limités et des coûts suivis dès le départ. |
| Ce que je peux cadrer en pilote | Un cas d’usage métier à fort impact, un périmètre court, des droits bien définis, un rollback prévu, et des décisions documentées. |
| Ce que je garde en veille | Les briques encore trop jeunes, sans garantie claire de support, de conformité ou d’intégration avec les standards internes. |
L’acquisition de Panther est aussi un signal important. Elle renforce Lakewatch SIEM, un SIEM étant un outil qui centralise les logs de sécurité pour détecter les incidents, alerter et aider à auditer. Dès qu’on industrialise des agents, des accès data et des traitements automatisés, la sécurité et l’observabilité deviennent centrales. Plus les agents ont de droits et d’autonomie, plus il faut tracer ce qu’ils font, détecter les comportements bizarres, alerter vite et garder une preuve exploitable.
Sur le terrain, j’ai rarement vu un problème d’IA échouer uniquement à cause du modèle. Ça bloque souvent sur les accès, la donnée pas prête, les responsabilités floues ou l’absence de monitoring. Le modèle marche en démo, puis la vraie vie arrive.
La bonne méthode reste assez simple. Je choisis un cas d’usage où la valeur business est claire, je limite le périmètre, je mesure les coûts, je vérifie les droits, je prévois un retour arrière et je documente les choix. Databricks avance vers une plateforme Data plus IA plus agents, c’est évident. Mais la décision saine, c’est de distinguer les composants GA, donc disponibles officiellement, des previews, et de démarrer là où l’impact est réel.
Alors on teste quoi en premier ?
Je retiens une chose simple : Databricks pousse fort vers l’IA vraiment exploitable en entreprise. Genie One rend l’assistant IA plus accessible aux équipes. LTAP cherche à réduire la plomberie ETL entre transactionnel et analytique. Agent Bricks, Sandbox, Memory Service, Omnigent et Unity AI Gateway adressent les sujets qui font mal en production : gouvernance, sécurité, mémoire, frameworks et coûts. Mais je ne mettrais pas tout dans le même panier. Les briques GA peuvent être étudiées sérieusement, les previews doivent rester des pilotes cadrés. Le bénéfice pour vous, c’est une lecture plus claire de ce qui peut créer de la valeur maintenant, sans vous faire embarquer trop vite.
FAQ
- Qu’est-ce que le Databricks Data + AI Summit 2026 met surtout en avant ?
Le sommet met surtout en avant le passage des agents IA du prototype à l’exploitation entreprise. Les annonces tournent autour de Genie One, LTAP, Agent Bricks, Unity AI Gateway, Lakebase et Lakewatch SIEM. Le message est clair : construire des agents ne suffit plus, il faut les gouverner, les sécuriser, contrôler leurs coûts et les connecter à des données fiables. - Genie One est-il prêt pour une utilisation en entreprise ?
Genie One est annoncé en disponibilité générale sur web, iOS et Android. C’est donc l’une des annonces les plus concrètes côté maturité. Il peut servir d’assistant IA inter-départemental, mais sa valeur dépendra surtout de la qualité des données, des droits d’accès, de la gouvernance et du contexte métier disponible. - LTAP supprime-t-il vraiment les pipelines ETL et CDC ?
LTAP vise à réduire fortement le besoin de pipelines ETL et CDC en rapprochant les données transactionnelles et analytiques sur une seule copie de données au format ouvert. Je resterais prudent sur le mot supprimer. Même avec moins de synchronisation, il faut toujours gérer la qualité, la sécurité, la modélisation et l’observabilité. - À quoi sert Unity AI Gateway pour les agents IA ?
Unity AI Gateway sert notamment à mettre des plafonds de dépense stricts sur les agents IA. C’est important parce qu’un agent peut multiplier les appels modèles, traiter trop de contexte ou boucler sur une tâche. Un plafond permet d’arrêter automatiquement un agent trop coûteux avant qu’il ne devienne un problème financier. - Quelles fonctionnalités Databricks faut-il encore traiter avec prudence ?
Les fonctionnalités en preview, bêta ou aperçu privé doivent être traitées comme des sujets de veille ou de pilote cadré. C’est le cas de CustomerLake, Genie App Builder, Genie ZeroOps, Agent Memory Service, Databricks Sandbox et Lakebase Search. Elles peuvent être prometteuses, mais elles ne doivent pas être considérées comme des briques production sans vérification sérieuse.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes Data, marketing et tech via l’agence webAnalyste et l’organisme Formations Analytics. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer un projet Data, IA ou automatisation sans partir dans tous les sens, je peux vous aider. Contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.