BDC et Datasphere : ce qui change, ce qui reste
Senior SAP BAIP Architect, Spadoom AG
Quand SAP a intégré Datasphere dans Business Data Cloud, les clients disposant d’un tenant Datasphere en production posaient toujours la même première question : qu’advient-il de ce que nous avons construit ? La réponse courte est rassurante. La partie la plus utile de la réponse, c’est ce que vous devriez cesser de construire.
En bref : votre investissement dans Datasphere est préservé : spaces, modèles, flux et compétences restent, et SAP Analytics Cloud ainsi que SAP BW deviennent des composants de la même plateforme. Ce qui change : l’emballage (un seul contrat BDC en unités de capacité), des produits de données gérés par SAP qui remplacent la réplication construite en interne pour les données SAP standard, SAP Databricks pour le machine learning au sein de la gouvernance SAP, et la gestion des données de référence qui rejoint BDC. Cessez de construire des flux pour des données que SAP livre déjà, et calez la conversion des licences sur votre prochain renouvellement.
Ce qui reste
Datasphere ne disparaît pas. Il reste la couche d’intégration et de modélisation sémantique au sein de BDC ; l’introduction de SAP à Business Data Cloud le range parmi les composants centraux :
- Spaces et modèles sont repris. Modèles sémantiques, vues et flux de données continuent de fonctionner. BDC les consomme au lieu de les remplacer. La documentation SAP Datasphere reste la référence pour la couche de modélisation.
- SAP Analytics Cloud reste la couche de visualisation et de planification, désormais incluse dans le bundle plutôt que sous contrat séparé.
- SAP BW reste accessible. BW et BW private cloud edition sont des composants de BDC ; les modèles d’entrepôt existants n’ont donc pas à être reconstruits dès le premier jour.
- Les compétences gardent leur valeur. Les personnes qui savent modéliser dans Datasphere sont celles qui relieront, dans BDC, les produits de données aux questions métier.
Si vous avez investi dans Datasphere ces dernières années, rien n’est perdu. Il s’agit d’une évolution de l’emballage autour d’un noyau qui demeure, pas d’un remplacement de plateforme comme les clients SAP en ont déjà connu (le passage de Sales Cloud V1 à V2 était une véritable reconstruction ; celui-ci ne l’est pas).
Ce qui change
Quatre choses sont réellement différentes.
- Emballage et licences. Un seul contrat BDC couvre Datasphere, SAP Analytics Cloud, SAP BW et SAP Databricks. SAP licencie BDC sur la base d’unités de capacité ; la conversion d’un contrat Datasphere ou SAC autonome dépend de votre contrat.
- Les produits de données remplacent l’extraction construite en interne. Un produit de données est « un jeu de données affiné, des métadonnées qui le décrivent et un point d’accès ou une API » (SAP News). Là où SAP en livre un (la première vague portait sur S/4HANA, SAP Ariba et SAP SuccessFactors), le flux de réplication que votre équipe avait construit pour les mêmes données devient un héritage. SAP maintient le produit de données à chaque release ; votre flux, personne ne le maintient à part vous. Pour les données CX comme Sales Cloud V2, vérifiez le catalogue de votre release et conservez la réplication Datasphere là où aucun produit de données n’existe encore.
- Le machine learning rentre dans l’enclos. Les charges de travail qui exigeaient autrefois de copier les données SAP vers une plateforme de ML distincte peuvent tourner dans SAP Databricks sous la même gouvernance, et BDC Connect partage les produits de données sans copie avec une plateforme Databricks, Snowflake ou d’un autre partenaire déjà en place. Avec la nLPD suisse et le RGPD, « les données n’ont jamais quitté la gouvernance SAP » est une phrase que votre délégué à la protection des données appréciera.
- La gestion des données de référence rejoint BDC. En mai 2026, SAP a fait de SAP Master Data Governance et de SAP HANA Cloud des composants centraux de BDC et a finalisé l’acquisition de Reltio, dont la gestion des données de référence multidomaine est intégrée à BDC (SAP News). La qualité des données de référence clients et articles, longtemps un projet à part, devient partie intégrante de la même plateforme.
Ce qu’il faut cesser de construire
Concrètement, dès aujourd’hui :
- Plus de nouveaux flux de réplication pour des données que SAP livre comme produit de données. Vérifiez d’abord le catalogue et ne construisez que pour combler les lacunes.
- Plus de modélisation d’entités génériques à partir de zéro. Client, commande client et facture arrivent modélisés sémantiquement là où un produit de données existe. Votre effort de modélisation se situe sur le dernier kilomètre : votre logique métier, vos indicateurs, vos champs d’extension.
- Plus de copies des données SAP pour le machine learning lorsque SAP Databricks ou un partage sans copie peut faire le travail à l’intérieur du périmètre de gouvernance.
- Plus d’analytique S/4HANA et CX en projets séparés. Dans la pile intégrée, un seul socle sert les deux. Les séparer recrée le problème des chiffres divergents que BDC doit résoudre. Les modèles d’intégration entre Sales Cloud V2 et BDC montrent comment le côté CRM s’y raccorde.
Une courte liste de contrôle pour la migration
| Étape | Quoi vérifier | Résultat |
|---|---|---|
| 1. Inventaire | Spaces, modèles, flux de réplication et requêtes BW utilisés | Liste des objets avec responsable et usage |
| 2. Comparaison avec le catalogue | Quels flux doublonnent un produit de données SAP de votre release | Flux à retirer, flux à conserver |
| 3. Contrat | Dates de renouvellement de Datasphere et SAC, consommation réelle | Calendrier de conversion et base de dimensionnement |
| 4. Parcours BW | Quels modèles BW restent, lesquels passent aux produits de données | Plan échelonné plutôt qu’une migration big bang |
| 5. Données de référence | Responsabilité des attributs clients et articles | Un responsable nommé par domaine |
| 6. Premier cas d’usage | Une question que la direction pose déjà | Périmètre de la première livraison BDC |
La négociation du renouvellement
Planifiez le passage aussi sur le plan commercial. Si votre contrat Datasphere ou SAC arrive à renouvellement dans les douze prochains mois, négociez la conversion vers BDC à ce moment-là. Apportez votre historique de consommation : le dimensionnement de la capacité avantage les clients qui connaissent leur usage réel plutôt que ceux qui acceptent une taille par défaut.
Gardez un périmètre modeste. La bonne première étape après la conversion n’est pas un projet de migration de plateforme, mais un domaine, les produits de données qui le servent et une analyse qui répond à une question que votre direction pose déjà. La responsabilité des données de référence vient en premier ; pourquoi les données CRM dépendent du socle de données explique l’ordre. Le travail de plateforme suit la demande, et non l’inverse.
Si vous souhaitez un deuxième regard sur l’inventaire, parlez-en avec nous. Spadoom livre le cœur ERP et la suite CX avec une seule équipe ; c’est pourquoi nous examinons les deux côtés du modèle de données en même temps.
Questions fréquentes
SAP Datasphere disparaît-il avec Business Data Cloud ?
Non. Datasphere reste le composant d’intégration et de modélisation au sein de BDC ; spaces, modèles et flux de données sont repris. Ce qui change, c’est l’emballage : nouvelles fonctions, produits de données et licences arrivent désormais sous l’ombrelle BDC.
Les licences Datasphere existantes se convertissent-elles en BDC ?
SAP licencie BDC sur la base d’unités de capacité ; la conversion d’un contrat Datasphere ou SAP Analytics Cloud autonome dépend de votre contrat. Le conseil pratique : caler la conversion sur votre prochain renouvellement, venir avec vos chiffres de consommation réels et négocier le bundle plutôt que les composants.
Faut-il encore lancer un nouveau projet Datasphere en 2026 ?
Lancez-le comme un projet BDC. Le travail reste largement le même (spaces, modèles, flux), mais le contrat et l’architecture devraient partir du packaging BDC, des produits de données partout où SAP les livre, et d’une réplication construite en interne uniquement là où aucun produit de données n’existe encore.
Qu’advient-il de SAP BW dans BDC ?
SAP BW, y compris BW private cloud edition, est l’un des composants de BDC. Les modèles BW existants peuvent continuer de tourner pendant que les nouvelles analyses naissent sur les produits de données et Datasphere ; le passage peut donc être échelonné plutôt que mené en un seul projet de migration.
Demandez à Spadoom
Des réponses fondées sur ce que Spadoom a publié sur ce site, avec des liens vers les pages sources.
Essayez l'une de ces questions
Réponses générées par IA. À vérifier avant d'agir. Les questions sont enregistrées de manière anonyme, sans adresse IP, afin d'améliorer nos contenus. Merci de ne pas saisir de données personnelles.
SAP Business Data Cloud partenaire d'implémentation
Spadoom est le partenaire d'implémentation SAP Business Data Cloud en Suisse, Allemagne, Autriche et Italie. Médiane de go-live de 14 semaines. Clients en production dans tout le DACH.
Articles associes
Les produits de données de SAP Business Data Cloud expliqués
Les produits de données sont la brique de base de SAP Business Data Cloud. Ce qu'est un produit de données, lesquels SAP a livrés en premier, comment les applications intelligentes s'appuient dessus, en quoi ils diffèrent des extracteurs classiques et comment combler la lacune des données CX.
SAP Business Data Cloud expliqué : ce que c'est et quand cela compte
SAP Business Data Cloud réunit Datasphere, SAP Analytics Cloud, SAP BW et SAP Databricks avec des produits de données gérés par SAP. Le rôle de chaque composant, ce qui est nouveau et quand une PME suisse devrait s'y intéresser.
Chronologie de SAP Business Data Cloud 2025 à 2026 : ce que SAP a annoncé et ce qui s'est passé depuis
Du lancement en février 2025 à Sapphire 2026 : toutes les étapes de SAP Business Data Cloud en un seul endroit, ce que SAP a annoncé à chaque événement, ce qui a réellement été livré depuis et ce qui reste ouvert pour les clients SAP CX en octobre 2026.