Fiche concept

SAP Datasphere vs SAP Analytics Cloud — quelle couche possède quoi

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

Qu'est-ce que SAP Datasphere vs SAP Analytics Cloud — quelle couche possède quoi ?

« Datasphere ou SAP Analytics Cloud ? » est le faux choix le plus fréquent de la pile analytique SAP, et il coûte cher parce qu'il est en général posé par quelqu'un qui s'apprête à n'en acheter qu'un. Ce ne sont pas des alternatives. Datasphere est l'endroit où la donnée est modélisée et gouvernée ; SAP Analytics Cloud est l'endroit où elle est consommée — stories, tableaux de bord, planification. L'un est la cuisine, l'autre la salle : un restaurant a besoin des deux.

La décision réelle est plus étroite et bien plus utile : quelle part de la modélisation sémantique appartient à Datasphere et quelle part peut vivre dans SAC — et il existe une réponse défendable qui ne dépend pas du goût de chacun.

Ce que chaque couche possède réellement

Datasphere est la couche de données et de sémantique unifiée : fédération (requête en pass-through, sans copie), réplication (mouvement delta vers son propre stockage) et modélisation (vues graphiques, SQL ou scriptées qui transforment des données brutes ou fédérées en objets prêts pour le métier). Elle tourne sur HANA Cloud avec un Delta Lake intégré. Tout vit dans un Space — une partition gouvernée avec sa sécurité, ses connexions et son cycle de vie — et la consommation inter-Space passe par le Catalog sous forme de Data Products versionnés, jamais par un partage de tables ad hoc.

SAP Analytics Cloud est la surface de consommation : stories, applications analytiques et moteur de planification. Il atteint Datasphere par connexion live (requête poussée, rien de copié) ou import (données remontées dans le stockage de SAC), et peut aussi se connecter directement à S/4HANA sans Datasphere entre les deux.

La décision qui est vraiment devant vous

Modéliser dans Datasphere quand la logique sera réutilisée. Dès qu'une deuxième story, un modèle de planification, un agent Joule ou un outil de BI tiers a besoin de la même mesure, la définition doit vivre là où tous peuvent la lire. Un KPI défini dans une story SAC est invisible pour tout le reste, et le deuxième consommateur le ré-implémentera discrètement, un peu différemment. C'est ainsi que deux tableaux de bord se mettent à ne plus être d'accord sur le chiffre d'affaires.

Modéliser dans SAC quand la logique est présentationnelle et locale. Une mesure calculée propre à une story, une règle de format, une restriction au niveau d'un graphique : les pousser dans Datasphere n'apporte rien et ajoute un cycle de déploiement.

Se passer entièrement de Datasphere pour un petit besoin de reporting touchant une ou deux tables sources, sans exigence de réutilisation : une connexion live SAC directement sur S/4HANA est plus rapide à livrer et parfaitement légitime. Datasphere gagne sa place par la réutilisation et la gouvernance, pas par sa présence sur le schéma.

Live ou import : une autre question, que l'on fusionne à tort avec celle-ci

Une connexion live garde une seule copie de la vérité et pousse la requête ; une connexion import copie les données dans SAC et accepte une fraîcheur dégradée contre de la vitesse d'interaction. Les équipes attribuent régulièrement à « la performance de Datasphere » ce qui relève en réalité d'un choix live/import fait par défaut. Tranchez-le explicitement, modèle par modèle, et écrivez pourquoi.

Là où ça dérape

Acheter SAC seul et modéliser dans les stories. Ça marche pour les trois premiers tableaux de bord puis cesse de passer à l'échelle : chaque nouveau consommateur re-dérive la sémantique et personne ne possède la définition. Le coût arrive tard — c'est pourquoi cette erreur survit au pilote.

Acheter Datasphere seul et attendre que les utilisateurs métier se servent. Datasphere n'est pas un front de restitution. Sans couche de consommation, l'investissement est invisible pour ceux qui le financent.

Confondre Datasphere et HANA Cloud. Datasphere est la fabrique de gouvernance et de consommation au-dessus de HANA Cloud, pas son remplaçant — les traiter comme une seule ligne double-compte la capacité et fait exploser le budget de sizing dès le premier jour.

Modéliser deux fois. La même mesure définie dans un Analytic Model Datasphere et de nouveau dans une story SAC n'est pas de la redondance : c'est une contradiction future avec une date dessus.

Pourquoi c'est important

Acheter l'un des deux et tout modéliser dedans est le choix par défaut le plus coûteux de cette pile, et la facture arrive après que le pilote a été déclaré réussi.

Sources

Ouvrir dans l'application →