Fiche concept

SAP Business Data Cloud vs Datasphere — ce que BDC ajoute réellement

À jour au 1er novembre 2026

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

SAP Business Data Cloud vs Datasphere : quelle est la différence ?

« Business Data Cloud ou Datasphere ? » est une vraie question — contrairement à la plupart des « versus » de cette pile — mais pas sous la forme où on la pose. BDC n'est pas un produit différent qui concurrencerait Datasphere. BDC contient Datasphere, et ajoute quatre pièces autour.

Ce que BDC ajoute au Datasphere que vous connaissez déjà

Cinq composants, dont un seul est une capacité nouvelle plutôt qu'une intégration nouvelle.

Datasphere continue de faire exactement ce qu'il faisait — Analytic Models, hiérarchies, conversion de devises, exécution poussée vers HANA Cloud — sauf qu'il résout désormais son catalogue depuis le périmètre BDC et non depuis un tenant autonome. Un lakehouse managé par Databricks fournit le stockage au format Delta, gouverné par Unity Catalog, accessible par notebooks Spark, MLflow ou DBSQL, pré-provisionné et facturé par SAP plutôt que négocié dans un contrat Databricks séparé. Les agents Joule consomment les Analytic Models Datasphere pour le contexte métier et peuvent réécrire via des actions encadrées. Le Knowledge Graph est en dessous, reliant Client, Matériel, Commande et les autres entités cœur, exposées à Joule comme à Datasphere en tant que contexte interrogeable.

Puis le Catalog — la pièce qui fait que les quatre autres se comportent comme une pile et non comme quatre produits sur une facture commune. C'est la couche de métadonnées unifiée qui porte les types sémantiques, la traçabilité, les Data Products et les règles DAC des deux côtés, Datasphere et Databricks. Sans lui, BDC ne serait effectivement qu'un lot. Avec lui, une règle de gouvernance écrite une fois s'applique à ce que Joule expose dans une réponse comme à ce qu'un notebook Spark lit.

L'arbitrage, dit honnêtement

Coût et verrouillage contre vitesse et cohérence. C'est toute la décision.

Choisir BDC plutôt qu'une architecture assemblée soi-même — Datasphere autonome, Databricks autonome, gouvernance sur mesure entre les deux — achète du time-to-value, parce que le câblage sémantique et de gouvernance arrive pré-construit au lieu d'être du travail d'intégration qu'un intégrateur facturerait. Le prix est de s'engager sur l'empaquetage, la tarification et le rythme de roadmap de SAP pour ce câblage, au lieu de choisir les meilleurs composants et de les intégrer à son propre calendrier.

De quel côté ça tombe en général

Le problème pour lequel BDC a été construit est un binaire qui n'avait pas de milieu acceptable : rester entièrement dans SAP et perdre l'outillage lakehouse et machine learning moderne, ou passer à une pile ouverte et dépenser dix-huit mois de projet à reconstruire la sémantique métier SAP depuis zéro — en se trompant, typiquement, sur une part significative de cette modélisation, parce que ce n'était jamais l'équipe de SAP qui la faisait. La réponse de BDC est de garder la sémantique native, puisque Datasphere plus le contenu S/4 livré arrivent avec les modèles pré-construits, et de rendre le lakehouse natif lui aussi, puisque Databricks tourne désormais dans le périmètre de facturation et de gouvernance de SAP.

Pour un client dont le parc analytique est réellement à majorité SAP — la forme que BDC suppose, environ soixante-dix à quatre-vingts pour cent des données pertinentes pour l'analytics dans le périmètre SAP — l'arbitrage penche généralement pour BDC. Pour un client dont l'empreinte de données est vraiment équilibrée, ou à majorité pile ouverte, un Datasphere autonome fédérant vers un lakehouse que le client gouverne déjà est la réponse mieux ajustée et moins verrouillante.

Notez qu'aucune des deux branches ne dit « n'utilisez pas Datasphere ». Cette option n'est pas sur la table.

Pièges

Vendre BDC comme « Datasphere avec des options ». Cela sous-vend l'unification de la gouvernance, qui est le vrai différenciateur, et installe la mauvaise attente de migration chez le client — l'erreur de positionnement la plus fréquente sur ce produit.

Croire que BDC supprime le besoin d'un spécialiste Databricks. Il change qui facture le lakehouse ; il ne change pas le fait que quelqu'un doit comprendre Spark, Delta et Unity Catalog au quotidien.

Traiter la capacité comme une seule ligne. Le modèle de consommation de BDC a son arithmétique d'unités de capacité ; reporter un sizing Datasphere autonome dans une proposition BDC produit un chiffre faux dans une direction que personne ne remarque avant la facture.

Acheter le lot pour régler un problème de gouvernance qu'on n'a pas encore défini. Le Catalog applique des règles ; il ne les invente pas. Un client sans modèle de propriété des données convenu achète un excellent moteur d'application et rien à appliquer.

L'angle Joule, septembre 2026

Le véritable rôle IA du Catalog n'est pas de cataloguer — c'est d'être l'endroit unique que lisent à la fois le SAP Knowledge Graph et la couche de grounding de Joule, de sorte qu'une réponse d'agent et une lecture de lakehouse soient soumises aux mêmes définitions d'entités et aux mêmes Data Access Controls. C'est le mécanisme concret derrière l'affirmation abstraite que BDC « contient » Datasphere : sans le Catalog, un agent Joule ancré sur les Analytic Models de Datasphere et un notebook Databricks lisant la même donnée source via Delta Sharing n'auraient aucune garantie partagée que « Client » signifie la même chose pour les deux, et les règles DAC écrites pour SAC ne s'étendraient pas automatiquement à une lecture du lakehouse. Le Catalog est ce qui rend cette garantie structurelle plutôt qu'une question de discipline que l'équipe projet doit faire respecter à la main.

Cela a une incidence directe sur l'alternative « assemblage maison » à laquelle cette fiche compare BDC. Une équipe qui monte Datasphere autonome plus un lakehouse Databricks fédéré obtient l'ancrage Joule côté Datasphere et les agents Mosaic AI côté Databricks, mais rien ne force les deux à s'accorder sur les définitions d'entités ou les règles de sécurité, à moins que l'équipe ne construise elle-même cette réconciliation — typiquement sous la forme d'une correspondance maintenue à la main entre le DAC de Datasphere et les permissions Unity Catalog de Databricks, qui dérive dès que l'un des deux côtés change indépendamment. Nommer cela explicitement pendant une conversation de cadre de décision transforme une affirmation abstraite d'unification de gouvernance en une question concrète à laquelle le client peut répondre pour son propre parc : qui, aujourd'hui, maintient synchronisés les modèles de permissions SAP et Databricks, et que se passe-t-il la semaine où quelqu'un l'oublie.

Une mise en garde à porter dans les conversations de cadrage 2026 : le partenariat SAP+Anthropic propre à SAP route le raisonnement de Claude via MCP vers le même AI Core et service d'orchestration qui s'ancre sur le Knowledge Graph, ce qui signifie que l'argument de qualité IA pour acheter BDC plutôt que d'assembler les pièces n'est pas seulement « vous obtenez Joule » — c'est « vous obtenez le chemin d'ancrage de Joule déjà câblé vers les modèles de raisonnement les plus avancés que SAP a accepté de supporter », un coût de câblage qui retombe carrément du côté du client dans l'alternative assemblage maison.

Mise à jour — octobre 2026. Le catalogue des sessions de SAP TechEd 2026 (14 octobre 2026 ; 364 sessions, 27–29 octobre) montre le déplacement du vocabulaire. SAP Business Data Cloud apparaît dans 31 descriptions de sessions, SAP HANA dans 21 et SAP Knowledge Graph dans 14, alors que SAP Datasphere n'apparaît dans aucune et SAP Analytics Cloud dans seulement 3. Le billet précise qu'il s'agit de descriptions de sessions et non d'annonces produit, lesquelles viendront avec les keynotes des 27 et 28 octobre. Pour la question de cette fiche, cela conforte la lecture de Datasphere comme composant de BDC plutôt que comme choix commercial distinct. Au cadrage, attendez-vous à ce que les contenus et sessions SAP sur la plateforme de données passent sous le nom Business Data Cloud, et adaptez le vocabulaire en conséquence face au client. Les articles Sapiens et McKinsey sur les knowledge graphs concernent d'autres éditeurs et n'affectent pas cette comparaison.

Pourquoi c'est important

C'est l'une des rares vraies décisions acheter-ou-construire de la pile analytique SAP, et la version qu'on en débat — « quel produit est le meilleur » — n'a pas de réponse, puisque l'un contient l'autre.

Points clés

BDC ne concurrence pas Datasphere : il CONTIENT Datasphere et ajoute quatre composants autour.
Les cinq pièces : Datasphere (sémantique), un lakehouse managé Databricks (stockage), Joule (surface IA), le Knowledge Graph (couche d'entités), et le Catalog.
Le Catalog est ce qui en fait une pile plutôt que quatre produits sur une facture — types sémantiques, lignage, Data Products et règles DAC des DEUX côtés.
Datasphere dans BDC se comporte comme avant, sauf qu'il résout son catalogue depuis le périmètre BDC plutôt que depuis un tenant autonome.
Le lakehouse est pré-provisionné et facturé via SAP au lieu d'être négocié comme un contrat Databricks séparé.
Le vrai compromis est coût-et-verrouillage contre vitesse-et-cohérence — vous achetez le câblage ou vous le construisez.
BDC suppose un parc à dominante SAP (une majorité des données pertinentes pour l'analytique dans le périmètre SAP — ordre de grandeur indicatif, pas un ratio publié par SAP). Un parc équilibré ou à dominante open-stack va mieux à Datasphere autonome.
Le problème que BDC résout : l'ancien dilemme entre rester entièrement dans SAP sans outillage lakehouse moderne, ou reconstruire la sémantique SAP depuis zéro sur un projet de dix-huit mois.
Aucune des deux branches de la décision ne dit « n'utilisez pas Datasphere » — cette option n'est pas sur la table.
BDC change QUI FACTURE le lakehouse ; cela ne supprime pas le besoin d'un spécialiste Spark/Delta/Unity Catalog.

Pièges courants

« BDC est Datasphere avec des extras » — Signal : Le pitch ne mentionne jamais le Catalog ou l'unification de gouvernance. Correctif : Ouvrir avec la couche de métadonnées unifiée des deux côtés — c'est le différenciateur.
Spécialiste Databricks supposé inutile — Signal : Aucune compétence Spark/Delta nommée dans le plan de staffing. Correctif : La staffer. BDC déplace la frontière de facturation, pas l'exigence opérationnelle.
Dimensionnement autonome reporté dans une proposition BDC — Signal : Une seule ligne de capacité réutilisée d'un devis Datasphere. Correctif : Re-dériver contre le propre modèle de capacity unit de BDC avant de chiffrer.
Bundle acheté pour corriger une gouvernance non définie — Signal : Aucun propriétaire de données nommé nulle part dans le programme. Correctif : Convenir de la propriété d'abord ; un moteur d'application sans rien à appliquer est du shelfware.
Cadrer cela comme quel produit est le meilleur — Signal : Une grille comparant BDC et Datasphere fonctionnalité par fonctionnalité. Correctif : L'un contient l'autre — comparer BDC à l'alternative « assemblez-le vous-même » à la place.

Cadre de décision

Cadre de décision
Décision	Option A	Choisir A quand	Option B	Choisir B quand
Où résident les données analytiques	Parc à majorité SAP (ordre de grandeur indicatif, pas un ratio SAP)	BDC — le packaging garde la majorité de votre sémantique native et préconstruite.	Équilibré ou majoritairement sur une pile ouverte	Datasphere autonome fédérant vers un lakehouse que vous gouvernez déjà — meilleur ajustement, moins d'enfermement propriétaire.
Qui construit le câblage de gouvernance	SAP, préconstruit	BDC. Vous le payez en packaging et en rythme de feuille de route, pas en jours d'intégrateur.	Vous / votre intégrateur	Assemblage maison. Vous gardez le choix best-of-breed et votre propre calendrier.
Existe-t-il un modèle de propriété des données convenu	Oui	Le Catalog a des règles à appliquer, et il les applique des deux côtés.	Pas encore	Corriger cela d'abord — le Catalog applique des règles, il ne les invente pas.
Compétences lakehouse dans l'équipe	Présentes ou financées	Les deux chemins fonctionnent.	Absentes	Aucun des deux chemins ne fonctionne encore — BDC change la facture, pas l'exigence de compétence.
Tolérance à la dépendance à la feuille de route	À l'aise	BDC — SAP fixe le rythme de l'intégration entre les pièces.	Besoin d'un calendrier indépendant	Assemblage maison, et budgéter l'intégration explicitement.

Chiffres à citer

BDC unifie Datasphere, un lakehouse géré par Databricks, les agents Joule, le SAP Knowledge Graph et un Catalog partagé en une seule pile gouvernée et facturée d'un bloc plutôt que quatre produits licenciés séparément.
Le profil client type visé par BDC a généralement déjà l'essentiel de ses données pertinentes pour l'analytique dans le périmètre SAP et le reste dans des systèmes adjacents (ordre de grandeur éditorial, pas un ratio publié par SAP).
SAP ne publie pas de plancher fixe en capacity units pour un tenant BDC ; dimensionnez avec l'estimateur de capacité officiel de SAP (SAP Discovery Center).
Une Capacity Unit est un ratio de mesure, pas un lot matériel fixe : la consommation de chaque service (par exemple des Go-heures de calcul à mémoire optimisée) est convertie en CU par une valeur de Capacity Unit propre au service dans la grille tarifaire SAP.
SAP ne publie aucun chiffre sur la capacité consommée par des agents Joule inactifs ; à mesurer sur votre propre tenant (non confirmé par une source primaire en novembre 2026).
Databricks tourne pré-provisionné et facturé par SAP à l'intérieur du périmètre de gouvernance de BDC — aucun contrat Databricks autonome séparé à négocier.
SAP ne publie pas de plancher fixe en capacity units pour un tenant BDC ; dimensionnez avec l'estimateur de capacité officiel de SAP (SAP Discovery Center).

Sources

Ouvrir dans l'application →

Les guides qui répondent avec cette page

Ces guides citent cette page parmi les sources sur lesquelles leur réponse s'appuie.

Prix SAP Datasphere : ce qui est public, ce qui ne l'est pas

Missions ouvertes

165 postes et missions SAP Datasphere ouverts en ce moment — voir les missions SAP Datasphere · missions freelance SAP.