Fiche concept

SAP Datasphere

À jour au 2026-10-10

É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 SAP Datasphere ?

SAP Datasphere est la couche de données et sémantique unifiée qui se trouve au centre de l'écosystème analytique moderne de SAP.

Ce que c'est

SAP Datasphere est la couche de données et sémantique unifiée qui se trouve au centre de l'écosystème analytique moderne de SAP. Construite sur SAP HANA Cloud avec un Delta Lake intégré, elle permet à une organisation de modéliser, gouverner et exposer les données d'entreprise — SAP et non-SAP — sous forme d'objets sémantiques fiables et réutilisables qui alimentent SAP Analytics Cloud, l'assistant IA Joule, et des outils de BI tiers via des protocoles de partage ouverts. En pratique, Datasphere remplace ce qui était auparavant un patchwork d'extractions point à point, d'entrepôts de données construits à la main et de requêtes BEx fragiles, par une seule structure de données gouvernée.

Pourquoi c'est important

Chaque grand client SAP fonctionnant sous ECC ou BW classique est sous pression temporelle : la feuille de route de SAP les oriente tous vers S/4HANA et une couche analytique cloud-native, et Datasphere est la zone d'atterrissage de cette migration. C'est aussi la couche de consommation sous SAP Business Data Cloud, donc bien poser les fondations de modélisation et de gouvernance dans Datasphere détermine la performance de chaque agent IA, tableau de bord et application de planification en aval. Une équipe qui se trompe sur Datasphere paie deux fois — une première fois sur le projet initial, une seconde fois dans chaque application consommatrice qui doit contourner le problème.

Comment ça fonctionne

Datasphere combine trois capacités qui exigeaient auparavant des produits séparés : la fédération (interrogation en direct d'un système source, sans copie de données), la réplication (déplacement des données par delta vers le stockage propre de Datasphere), et la modélisation (vues graphiques, SQL ou scriptées qui transforment des données brutes ou fédérées en modèles sémantiques prêts pour le métier). La consommation se fait ensuite soit via les connexions live ou import de SAP Analytics Cloud, soit via Delta Sharing vers des plateformes externes comme Databricks ou Snowflake, soit via la couche de grounding de Joule pour les agents IA. Tout s'exécute à l'intérieur d'un Space — une partition gouvernée avec sa propre sécurité, ses connexions et son cycle de vie — et la consommation inter-Space passe par le Catalog via des Data Products versionnés, jamais par un partage de table ad hoc.

Quand l'utiliser — et quand ne pas l'utiliser

La décision la plus importante n'est pas « faut-il adopter Datasphere » — pour toute organisation déjà engagée sur S/4HANA et SAP Analytics Cloud, la réponse est presque toujours oui, car c'est la seule couche dans laquelle SAP investit activement pour la fédération, la modélisation sémantique et le grounding IA. La vraie question de cadrage décisionnel est combien construire là versus les alternatives. Pour un besoin de reporting restreint touchant une ou deux tables sources sans exigence de réutilisation, une connexion live directe de SAP Analytics Cloud vers S/4HANA peut être livrée plus vite et coûter moins cher à exploiter que de monter un modèle Datasphere — le compromis (trade-off) est l'absence de réutilisation sémantique, de couche de gouvernance, et de chemin vers le grounding IA plus tard. Pour des besoins véritablement transverses à l'entreprise, multi-consommateurs et multi-sources, Datasphere est le seul choix raisonnable face à la construction d'un entrepôt de données sur mesure sur HANA Cloud brut ou un lakehouse externe, car il livre l'outillage sémantique et de gouvernance qu'une plateforme brute exigerait des mois d'ingénierie sur mesure pour reproduire. Le compromis ici porte sur le coût et la complexité : Datasphere est licencié en Capacity Units, découplées des sièges utilisateurs, et un tenant sous-dimensionné crée son propre plafond de performance.

Une deuxième décision de cadrage revient constamment : fédérer ou répliquer, décidée par objet source plutôt que par système source. La fédération est le bon choix par défaut lorsque le système source peut absorber la concurrence de requêtes, lorsque la fraîcheur quasi temps réel compte réellement, et lorsque les volumes de données restent modérés — son compromis est que chaque requête ajoute de la charge au système source de production. La réplication est le bon choix par défaut pour les données de faits à fort volume ou les sources qui ne peuvent tolérer une pression concurrente de requêtes analytiques — son compromis est le coût de stockage, la latence du pipeline et la charge opérationnelle de gestion de la capture de changement de données (CDC).

Pièges et anti-patterns

L'erreur la plus coûteuse consiste à traiter Datasphere comme un simple remplacement de HANA Cloud et à budgétiser les deux séparément — les Capacity Units de Datasphere intègrent déjà le calcul HANA Cloud sous-jacent, donc un double budget gonfle le business case et crée de la confusion en négociation fournisseur. Le deuxième anti-pattern récurrent consiste à opter par défaut pour « tout répliquer » parce que cela paraît plus sûr que la fédération ; en pratique, cela fait exploser les fenêtres de batch nocturne dès que les volumes de tables de faits croissent, et les équipes finissent par réingénierer la stratégie de chargement sous pression de production plutôt que par conception. Un troisième anti-pattern consiste à construire des modèles sémantiques avant que la structure de gouvernance des Spaces et du Catalog ne soit convenue — les équipes qui modélisent d'abord et organisent ensuite finissent avec une logique dupliquée entre Spaces qu'il faudra consolider plus tard, à un coût réel. Enfin, traiter chaque besoin de reporting comme digne de Datasphere, sans considération d'échelle ou de réutilisation, consomme des Capacity Units et des efforts de modélisation sur des cas d'usage jetables qu'une connexion directe aurait tout aussi bien servis. La discipline qui distingue un programme Datasphere bien mené d'un programme en difficulté n'est presque jamais la compétence technique — c'est l'application constante de ces quelques règles de décision avant que le premier modèle ne soit construit.

L'angle Joule, septembre 2026

Le rôle de Datasphere a changé cette année d'une façon précise et vérifiable : Joule est désormais intégré directement à l'intérieur même de l'interface Datasphere — navigation en langage naturel, exécution de tâches, questions-réponses inter-spaces pour les architectes, analystes et utilisateurs métier, disponible en GA selon un document help.sap.com daté du 24/09/2026 — plutôt que d'être un assistant séparé rapporté de l'extérieur. C'est une affirmation plus étroite que « Datasphere a de l'IA maintenant » : il s'agit spécifiquement d'un accès conversationnel à la surface de modélisation et d'administration, pas d'un changement dans le fonctionnement de la couche sémantique sous-jacente. Séparément, et de façon plus déterminante pour les décisions d'architecture, les Analytic Models et Data Products de Datasphere sont ce que le SAP Knowledge Graph et le grounding document/DB du service d'orchestration lisent réellement lorsqu'un agent Joule ou une application adossée au generative AI hub a besoin d'ancrer une réponse métier dans de vraies entités SAP plutôt que dans la mémoire paramétrique du modèle. C'est pourquoi la discipline de modélisation Datasphere porte désormais un enjeu de fiabilité IA au-delà de la seule justesse des dashboards : un Analytic Model au nommage négligé, à la conversion de devise non résolue, ou sans Data Access Control produit une réponse Joule aussi fausse ou trop permissive qu'un mauvais dashboard, avec simplement plus d'apparence d'autorité.

La décision que cela impose à un consultant est de savoir quelle couche du modèle exposer pour le grounding, et ce n'est pas automatique. Ancrer une référence du Knowledge Graph, ou un filtre de document grounding du service d'orchestration, sur une table brute répliquée plutôt que sur un Analytic Model ou Data Product publié, catalogué et protégé par DAC, contourne silencieusement le même contrôle d'accès que respecte tout autre consommateur — Joule n'a pas un modèle de sécurité séparé et plus faible, mais seulement si l'objet qu'il lit a été construit dès le départ pour porter la DAC. La règle pratique : traiter « ancrable pour l'IA » comme une propriété à concevoir au moment de la modélisation, de la même façon que « consommable par SAC » l'est déjà, et non comme un souci d'intégration en aval.

Une distinction supplémentaire à tenir précisément face à un client : Datasphere se situe sous SAP Business Data Cloud, lui-même désormais intégré à la SAP Business AI Platform plus large (BTP + BDC + Business AI, unifiés depuis Sapphire le 12/05/2026). Rien dans cette ombrelle de marque ne change ce que Datasphere fait techniquement — cela change qui signe le contrat et comment la roadmap est communiquée. Un consultant ne doit pas présenter l'annonce de la Business AI Platform comme une nouvelle capacité de Datasphere ; la véritable nouvelle capacité est l'interface Joule intégrée et le chemin de grounding vers le Knowledge Graph, tous deux datés et vérifiables en GA indépendamment de l'ombrelle de marque.

Ce qui a changé depuis fin septembre 2026

28 septembre 2026 — un billet du groupe d'apprentissage SAP Community sur les technologies d'intégration de Datasphere décrit un schéma en deux temps proche d'une architecture BW en couches : intégration rapide et capable de delta des données brutes par flux de réplication, pour ménager la source, puis flux de transformation pour les jointures, le nettoyage et l'harmonisation, avec une couche de données métier au-dessus. Pour le praticien, ce découpage est une décision de coût et de latence ; il détermine aussi quels objets modélisés un chemin d'ancrage IA pourra lire ensuite (source).
29 septembre 2026 — SAP a publié un pas-à-pas pour les flux de réplication vers AWS S3 par un chemin privé : SAP Cloud Connector sur un hôte EC2 placé dans le même VPC et le même sous-réseau qu'un point de terminaison d'interface S3 (RHEL 9 ou Amazon Linux 2023, au moins 2 vCPU / 4 Go), de sorte que le trafic reste dans le réseau AWS. Les équipes sécurité qui refusent les points de terminaison S3 publics ne bloquent plus l'alimentation sortante, mais il faut budgéter et exploiter un hôte Cloud Connector (source).
29 septembre 2026 — un billet de membre, « Dynamic Top-N Waterfall Analysis in SAP Analytics Cloud: Why I Moved Ranking to SAP Datasphere », plaide pour sortir la logique de classement de la story SAC et la placer dans la couche Datasphere. C'est le sens que recommande cette fiche : une logique modélisée une fois dans Datasphere est réutilisable par tous les consommateurs, SAC comme IA (source).
1er octobre 2026 — un billet de questions-réponses sur les vues graphiques alimentant des modèles live SAC attribue les drill-downs défaillants à des clés primaires manquantes, des relations erronées, des hiérarchies absentes, des propriétés de colonne incorrectes et aux limites des modèles live. Concrètement : contrôler ces cinq points dans la vue avant d'ouvrir un ticket contre SAC (source).

Pourquoi c'est important, en pratique

Facturer 'HANA Cloud' à part de Datasphere revient à double-compter la dépense, puisque HANA Cloud est auto-provisionné à partir du plan Capacity Units du tenant.
L'arbitrage fédérer-vs-répliquer se décide objet source par objet source, pas système par système — le défaut 'tout répliquer' tue trois architectures sur quatre via la fenêtre batch nocturne.
Il existe un point d'ancrage de dimensionnement concret : un Analytic Model de 100 M de lignes avec rafraîchissement quotidien et 50 utilisateurs SAC simultanés tourne à ~32 CU en régime établi, contre un plancher de 64 CU à environ 52 k€/an.

Points clés

Successeur de Data Warehouse Cloud (DWC) ; rebaptisé au Q1 2023 ; la couche de consommation de BDC.
Tourne sur HANA Cloud + Delta managé — Datasphere est le tissu de modélisation/gouvernance, pas le moteur.
Trois piliers dans une seule plateforme : fédération (push-down live), réplication (Replication Flows, CDC), modélisation (Graphical / SQL / Script).
Modélisation à trois couches : raw → vue SQL → Analytic Model. Toujours envelopper les vues raw avant de les exposer à SAC.
Data Access Controls (DAC) à la portée du catalogue = une seule règle verrouille SAC + Joule + Delta Sharing + OData + JDBC.
Tarification en Capacity Units : 64 CU minimum, ~€52 k/an FY26 ; les CU sont découplées des sièges utilisateurs mais consommées par la concurrence × la taille des jeux de données.
La forme de déploiement BDC ajoute un lakehouse Databricks avec gouvernance bidirectionnelle — DAC atteint les tables Delta.
Performance : 100-500 ms p50 avec push-down HANA complet ; réplication à 50-200 k lignes/sec ; plafond de concurrence à 200-user sur SAC Live.

Sources

Ouvrir dans l'application →