Fiche concept

SAP Datasphere vs Databricks — cadre de décision pour la plateforme de données SAP

À jour au 2026-08-02T20:00:00Z

Qu'est-ce que SAP Datasphere vs Databricks — cadre de décision pour la plateforme de données SAP ?

Demandez à un architecte data SAP « Datasphere ou Databricks ? » et la première réponse honnête est que la question a une fausse forme.

Demandez à un architecte data SAP « Datasphere ou Databricks ? » et la première réponse honnête est que la question a une fausse forme. Dans l'architecture de SAP, les deux ne sont pas des rivaux qui se disputent la même place : Business Data Cloud embarque un lakehouse managé par Databricks comme couche de stockage en format ouvert, pré-provisionné et facturé par SAP plutôt que négocié dans un contrat Databricks séparé. Datasphere est la couche sémantique et de gouvernance ; Databricks est le lakehouse et le moteur de machine learning en dessous. Demander lequel gagne revient à demander s'il faut le moteur ou la boîte de vitesses.

La décision réelle — celle qui coûte cher quand elle est mal prise — porte sur la part du câblage entre les deux que vous construisez vous-même. C'est un choix à trois branches, et cette page en est le cadre.

Les trois architectures entre lesquelles vous arbitrez vraiment

A — Datasphere seul. La couche sémantique, ses espaces, ses vues et ses Analytic Models, consommés par SAP Analytics Cloud, sans lakehouse derrière. Le bon choix quand la charge de travail est de la modélisation et du reporting pour utilisateurs métier sur des données SAP, et qu'aucune équipe de data engineering n'est là pour opérer davantage. Ce n'est pas une architecture au rabais : c'est la bonne dès que personne sur le projet n'utiliserait Spark si on le lui donnait.

B — Datasphere plus un Databricks autonome, fédérés. Deux plateformes licenciées séparément, reliées par BDC Connect et le protocole Delta Sharing, sans qu'aucune ne copie les données de l'autre. Le bon choix quand une pratique Databricks mature existe déjà — modèles suivis dans MLflow, pipelines Spark, une équipe fluide dans cet écosystème — et que le besoin neuf est l'accès gouverné aux données métier SAP. Migrer cette pratique vers l'outillage natif SAP coûterait presque toujours bien plus cher que la fédérer.

C — Business Data Cloud. Le paquet pré-câblé : Datasphere en couche sémantique, le lakehouse Databricks en stockage, Joule en surface IA, le SAP Knowledge Graph en substrat sémantique, un catalogue unique au-dessus. Vous achetez l'intégration au lieu de la construire, et vous acceptez l'empaquetage et la facturation SAP pour le lakehouse.

Ce qui tranche

La première question n'est pas technique. Elle est de savoir si quelqu'un sur la mission va opérer un lakehouse au quotidien. BDC change qui facture la capacité Databricks ; il ne supprime pas le besoin de quelqu'un qui comprend Spark, Delta et Unity Catalog. Une équipe qui adopte l'option C sans cette personne a acheté un composant qu'elle ne sait pas faire tourner.

La deuxième est de savoir où se trouve déjà la gravité des données. Le client pour lequel BDC est conçu a une forme précise : soixante-dix à quatre-vingts pour cent des données pertinentes pour l'analytics à l'intérieur du périmètre SAP, le reste sur des plateformes adjacentes. Inversez ce ratio et l'argument du stockage empaqueté par SAP faiblit nettement — la sémantique que vous payez pour garder native ne couvre plus qu'une minorité de ce que vous analysez.

La troisième est de savoir si vous acceptez de porter le contrat d'intégration. Les options A et C vous livrent une couture supportée. L'option B vous laisse propriétaire de l'évolution des schémas sur deux plateformes qui peuvent chacune lire et écrire les mêmes tables Delta — ce qui exige un contrat écrit sur qui a le droit de changer quoi, pas seulement une connexion qui fonctionne.

Ce qu'est réellement la connexion

Delta Sharing, ouvert par Databricks en 2021 et sous licence Apache, est le protocole que les deux côtés parlent. Il est authentiquement multi-consommateur et non un tuyau réservé à Databricks : la même sortie Datasphere gouvernée est lisible par le mode direct query de Power BI et par Tableau. BDC Connect est la couche de fédération côté SAP qui enregistre les sources externes — Databricks, mais aussi Snowflake, Amazon S3 ou les tables Iceberg, et BigQuery — dans le catalogue BDC, si bien que la modélisation Datasphere et la couche de grounding de Joule les voient comme des objets natifs. BDC Connect for Databricks est en disponibilité générale depuis le 6 octobre 2025 et dialogue directement avec le point d'accès Delta Sharing d'Unity Catalog, sans pilote spécifique à SAP.

Le protocole étant bidirectionnel, un notebook Databricks peut réécrire un score de churn ou une prévision de demande dans un emplacement que SAP enregistre comme data product, ce qui referme la boucle sans étape d'export.

Pièges

Trois reviennent, et chacun a déjà coûté de l'argent à un projet.

Confondre zéro-copie et zéro-coût. Chaque requête sur une table Delta partagée consomme du compute côté lecteur. Une charge analytique lourde contre un data product exposé par BDC génère des frais Databricks que personne n'avait budgétés quand la suppression du pipeline a été vendue comme une économie pure.

Croire que la gouvernance voyage gratuitement. La sécurité au niveau ligne définie dans les Data Access Controls de Datasphere doit être vérifiée comme héritée côté lecture Databricks, pas supposée. Un partage mal configuré expose plus que ce que l'Analytic Model source prévoyait, et il le fait en silence.

Présenter BDC comme « Datasphere avec des options en plus ». Cela sous-vend l'unification de la gouvernance, qui est le vrai différenciateur, et cela installe la mauvaise attente de migration chez le client — c'est ainsi qu'un projet découvre au quatrième mois qu'il a vendu un paquet qu'il n'est pas staffé pour opérer.

Pourquoi c'est important

Se tromper ici, c'est acheter un lakehouse que personne dans l'équipe ne sait opérer, ou payer deux fois une gouvernance que SAP empaquette déjà. C'est l'un des deux ou trois arbitrages d'architecture qu'un client ne peut pas revenir en arrière à bas coût.

Sources

Ouvrir dans l'application →