Fiche concept

Databricks

À jour au 2026-09-27

Édité par Cédric Mary, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Databricks ?

Databricks est une plateforme de données et d'IA bâtie autour de l'idée de lakehouse : une couche de stockage unique portant des formats de tables ouverts, et des moteurs SQL, streaming, science des données et apprentissage automatique qui lisent les mêmes tables au lieu d'en garder chacun une copie. Longtemps, du point de vue d'une pratique SAP, c'était une pile voisine — quelque chose que le client possédait aussi, et que quelqu'un d'autre administrait.

Cela a changé quand SAP l'a embarquée dans Business Data Cloud. BDC livre une capacité Databricks à l'intérieur du patrimoine SAP, et ce qui compte pour un consultant n'est pas la technologie : c'est que la frontière a bougé. Des questions auxquelles on répondait « ça, c'est du côté plateforme de données » atterrissent désormais dans une conversation SAP, et le consultant présent est censé avoir un avis.

Ce à quoi elle est réellement bonne, dit simplement. Databricks gagne sa place là où le travail est de la transformation à grande échelle, de l'ingestion en flux et de l'apprentissage automatique sur des données qui ne sont pas seulement SAP — les charges qu'une couche de modélisation sémantique n'est pas faite pour porter. SAP Datasphere gagne la sienne là où le travail est la sémantique métier, la réutilisation gouvernée et un paradigme de modélisation que la donnée SAP parle déjà. Aucune ne remplace l'autre, et une architecture qui pose le choix en « l'une ou l'autre » finit généralement par reconstruire la couche sémantique à la main dans des notebooks.

Le joint, c'est la donnée, pas l'outil. Ce qui rend l'attelage praticable est le partage ouvert des tables entre les deux côtés plutôt qu'une copie de plus : le côté SAP garde la sémantique et la gouvernance, le côté lakehouse garde l'échelle et la surface ML. Le mode de défaillance qui mérite d'être nommé est la duplication — dès que la même entité métier est définie une fois dans un modèle sémantique et une autre fois dans un notebook, les deux définitions dérivent, et la question « quel chiffre est le bon » n'a plus de propriétaire.

Où se situe la valeur d'un consultant. Pas dans l'exploitation de clusters. Elle est dans le fait d'être celui qui sait dire quelles questions vont de quel côté, ce qui traverse la frontière, et qui possède la définition quand elle la traverse. C'est une conversation de sémantique et de gouvernance, et c'est celle qu'un consultant SAP analytics est le mieux placé pour tenir.

Les pièces qu'il faut savoir nommer. Sous le marketing, la plateforme est quatre choses qu'un consultant doit savoir situer. Delta Lake est le format de tables ouvert qui donne un comportement transactionnel à des fichiers posés sur du stockage objet — la raison pour laquelle un lakehouse peut être lu et écrit sans risque par plusieurs moteurs à la fois. Unity Catalog est la couche de gouvernance : catalogues, schémas, tables, propriété, accès et traçabilité au même endroit, et la surface sur laquelle se tient toute conversation crédible sur « qui a le droit de voir ça ». Delta Sharing est un protocole ouvert pour donner à une autre plateforme un accès en lecture vivant à une table sans la copier. Mosaic AI et MLflow sont le côté modèles — entraînement, suivi, exposition. Tout le reste d'un patrimoine Databricks s'accroche à ces quatre-là.

Comment SAP l'a réellement branchée. SAP a lancé Business Data Cloud en février 2025 comme une offre conjointe avec Databricks, avec un SAP Databricks embarqué à l'intérieur du patrimoine SAP, puis a livré BDC Connect pour les clients qui exploitent déjà leur propre espace de travail Databricks. Les deux chemins reposent sur la même idée : partager les tables plutôt que les copier. Ce qui compte pour un consultant est le détail en dessous — les métadonnées sémantiques SAP peuvent voyager avec la donnée partagée, si bien que le côté lakehouse lit le contexte métier SAP au lieu de le redériver à partir de noms de champs. C'est la différence entre un partage et un export, et c'est tout l'argument de cette architecture.

La décision, et l'arbitrage qu'elle cache. La question que pose le client est « Datasphere ou Databricks » ; celle qui mérite une réponse est : lesquelles de ses vraies questions vont de quel côté, et qui possède chaque définition métier une fois la frontière tracée. L'arbitrage est réel : poser une définition côté lakehouse gagne l'échelle et la portée ML mais quitte la couche sémantique SAP ; la garder côté SAP gagne la réutilisation gouvernée mais fait payer le déplacement quand la charge ML en a besoin. Ce qui n'est pas un arbitrage, c'est de la définir deux fois — ce n'est pas un choix, c'est un défaut qui refait surface dans un audit six mois plus tard.

L'angle Joule, septembre 2026

La frontière sémantique-contre-échelle que nomme cette fiche est la même frontière qui décide quelle surface IA raisonne sur quel côté d'un parc conjoint SAP-Databricks, et un consultant devrait tracer les deux frontières dans la même conversation plutôt que de traiter l'IA comme un chantier séparé. Côté Databricks, le Mosaic AI Agent Framework construit des agents multi-étapes nativement sur des tables gouvernées par Unity Catalog, des modèles enregistrés et des index Vector Search, et Genie répond à des questions en langage naturel à tour unique sur de la donnée résidente Databricks en utilisant des définitions en texte libre et des exemples SQL de confiance — les deux lisent le lakehouse directement, sans dépendance à la couche sémantique propre de SAP. Côté SAP, les agents Joule ancrent leur raisonnement dans le SAP Knowledge Graph, construit à partir de donnée modélisée comme data product gouverné à l'intérieur de Datasphere, pas à partir de tables brutes du lakehouse. Cela signifie que la question « qui possède la définition » que cette fiche cadre déjà pour la BI a un pendant exact au niveau IA : un agent Joule qui répond à une question a besoin que le modèle sémantique côté SAP existe comme data product Datasphere, et un agent Mosaic AI qui répond à la même question métier sous-jacente depuis le côté lakehouse n'a besoin d'aucun artefact côté SAP — les deux surfaces IA ne convergent pas automatiquement simplement parce que BDC laisse les deux côtés partager les tables sous-jacentes.

La conséquence pratique pour cadrer un travail IA sur un parc conjoint SAP-Databricks : router selon la forme de la charge, la même logique que cette fiche applique déjà à la BI. Une question qui a besoin du contexte processus SAP — statut d'approbation, cycle de vie d'un document, hiérarchie organisationnelle — relève d'un agent Joule qui lit le Knowledge Graph, car Genie et les agents Mosaic AI n'ont pas d'équivalent de modèle structuré des processus métier SAP. Une question qui est fondamentalement une tâche d'entraînement ML ou d'ingénierie de features à grande échelle — un modèle de churn, une prévision de demande ré-entraînée chaque nuit sur des téraoctets d'historique transactionnel — relève de Mosaic AI, car les agents Joule ne sont pas construits pour l'entraînement et le service de modèles à cette échelle. Se tromper sur ce routage, dans un sens ou dans l'autre, reproduit, au niveau IA, exactement l'échec de duplication que cette fiche nomme déjà pour la sémantique : définir la même logique métier une fois dans l'ancrage d'un agent Joule et une seconde fois dans le code outil d'un agent Mosaic AI, et les deux dériveront, sans que personne ne possède celle qui fait autorité.

La réserve honnête pour quiconque cite l'ensemble des capacités IA de Databricks dans une conversation SAP : la base de faits propre à cette plateforme ne porte pas de dates GA ou de numéros de version durs pour le Mosaic AI Agent Framework ou Genie de la même façon qu'elle le fait pour les propres versions Joule de SAP, car le rythme de sortie propre de Databricks n'est pas un contenu rédigé par SAP — vérifier directement la documentation actuelle de Databricks avant de citer une capacité spécifique comme livrée, plutôt que de traiter le simple fait que cette fiche les nomme comme une confirmation de statut.

Pourquoi c'est important

Depuis que BDC l'embarque, Databricks n'est plus une pile sur laquelle un consultant SAP peut se dispenser d'avoir un avis — la frontière est entrée dans le patrimoine SAP.
Elle reste une compétence rare sur le marché que suit cette plateforme : 244 des 9 116 fiches au 2026-09-16 cabinet au 2026-09-16 que l'annuaire portait au 2026-09-16 mentionnent Databricks contre 4 184 qui mentionnent S/4HANA, et 60 des 3 307 lignes d'opportunités vives la nomment (mesuré le 2026-08-29 sur public/api/company-profiles.json et public/api/contracts.json).
La décision qu'elle impose — la sémantique ici, l'échelle là, qui possède la définition — est justement celle qui n'a aucun propriétaire par défaut, et c'est pourquoi il vaut la peine d'être celui qui sait la trancher.

Points clés

Plateforme lakehouse : une couche de stockage en formats ouverts, plusieurs moteurs lisant les mêmes tables au lieu d'en garder chacun une copie.
Quatre pièces à savoir situer : Delta Lake (format de tables ouvert), Unity Catalog (gouvernance), Delta Sharing (protocole ouvert de partage), Mosaic AI/MLflow (cycle de vie des modèles).
SAP a lancé Business Data Cloud avec Databricks en février 2025 et embarqué un SAP Databricks dans le patrimoine SAP ; BDC Connect couvre les clients qui possèdent déjà un espace de travail.
Le joint est un PARTAGE, pas une copie — et les métadonnées sémantiques SAP peuvent voyager avec la donnée partagée, donc le contexte métier n'est pas redérivé de noms de champs.
Elle porte la transformation à grande échelle, le flux et le ML sur de la donnée pas seulement SAP ; Datasphere porte la sémantique métier et la réutilisation gouvernée.
Aucune ne remplace l'autre ; poser le choix en « l'une ou l'autre » revient à reconstruire la couche sémantique à la main dans des notebooks.
Le mode de défaillance est la DUPLICATION d'une définition métier des deux côtés — après quoi « quel chiffre est le bon » n'a plus de propriétaire.
La valeur d'un consultant ici est un travail de frontière — router les questions, nommer ce qui traverse, attribuer la propriété — pas exploiter des clusters.

Sources

Ouvrir dans l'application →

Databricks

Qu'est-ce que Databricks ?

L'angle Joule, septembre 2026

Pourquoi c'est important

Points clés

Sources

Concepts liés

Modules d'académie associés

Études approfondies

Guides SAP analytics & TJM