Analytics Legends La plateforme de connaissance SAP Analytics
Guide

Architecture SAP Datasphere — les quatre arbitrages qui coûtent

À jour au 2026-08-14

Datasphere est la couche de données et de sémantique unifiée de l'écosystème analytique SAP : fédération, réplication et modélisation dans un seul produit, sur HANA Cloud avec un Delta Lake intégré. Dessiner cela est simple. Le travail d'architecture tient dans quatre décisions en dessous, et chacune se paie cher si on la reprend une fois les objets créés.

Décision 1 — quelle couche détient la sémantique

Datasphere modélise et gouverne ; SAP Analytics Cloud consomme. Ce sont des couches, pas des alternatives, et la vraie question est la part de modélisation sémantique qui revient à chacune.

Le critère est la réutilisation, pas la préférence. Dès qu'un deuxième récit, un modèle de planification, un agent d'intelligence artificielle ou un outil tiers a besoin du même indicateur, la définition doit vivre là où tous peuvent la lire. Un ratio défini dans un seul récit est invisible pour le reste, et le deuxième consommateur le réimplémente légèrement différemment — c'est ainsi que deux tableaux de bord cessent d'être d'accord sur le chiffre d'affaires.

Décision 2 — fédérer ou charger, objet par objet

La fédération est ici de première classe, ce qui inverse l'habitude du décisionnel classique. Dans le modèle historique, tout est chargé avant d'être modélisé ; ici, une requête en direct traverse jusqu'à la source sans rien copier. Charger devient un choix qu'on justifie, pas un réflexe qu'on hérite.

La justification tient en trois motifs : la latence, la charge du système source, ou sa disponibilité. Écrivez-la objet par objet. Les équipes qui sautent cette étape répliquent tout par habitude et paient stockage et maintenance pour des données interrogées deux fois par mois.

Décision 3 — comment découper les espaces

Chaque objet vit dans un espace : une partition gouvernée avec sa propre sécurité, ses connexions et son cycle de vie. La consommation d'un espace à l'autre passe par le catalogue, sous forme de produit de données versionné, jamais par un partage de table improvisé.

Découpez sur la propriété et la cadence de livraison : un responsable de la donnée, un cycle de vie. Découper par projet laisse un cimetière d'espaces sans propriétaire quand les projets s'arrêtent ; découper par système source reproduit la couche de préparation à l'intérieur du modèle de gouvernance.

Décision 4 — un lakehouse a-t-il sa place ici

Trois architectures, et le choix ne porte pas sur la capacité technique. Datasphere seul, consommé par SAP Analytics Cloud : la bonne réponse quand personne sur le projet n'utiliserait Spark si on le lui donnait, et ce n'est pas l'architecture au rabais. Datasphere plus un Databricks autonome, fédérés : pertinent quand une pratique Databricks mature existe déjà, car la migrer vers l'outillage natif SAP coûte presque toujours plus cher que de la fédérer. Business Data Cloud : l'assemblage précâblé, où l'on achète l'intégration au lieu de la construire.

Ce dernier suppose un patrimoine majoritairement SAP — de l'ordre de soixante-dix à quatre-vingts pour cent des données analytiques dans le périmètre SAP. Inversez ce ratio et vous payez l'emballage pour garder une minorité de vos analyses en natif.

La première question sur les trois n'est pas technique : quelqu'un exploitera-t-il un lakehouse au quotidien ? Business Data Cloud change qui facture Databricks, pas qui doit maîtriser Spark, Delta et le catalogue de gouvernance.

La fenêtre hybride est une architecture, pas un accident

Dans presque toute transition S/4HANA pluriannuelle, ECC et S/4HANA coexistent trois à cinq ans, les directions métier migrant à des rythmes différents. Le rôle de Datasphere est d'unifier l'analytique des deux côtés, une seule couche de modèles abstrayant la provenance du chiffre.

Ce qui borne la fenêtre : des dates de sortie calendées par région ou direction métier, revues chaque trimestre. Les organisations qui conçoivent la sortie dès le départ convergent en deux à quatre ans ; celles qui traitent chaque décision comme un correctif tactique exploitent encore deux plateformes sept à dix ans plus tard.

Questions fréquentes

SAP Datasphere remplace-t-il BW ?

Ce n'est pas le nouveau BW, et le présenter ainsi autorise le lift-and-shift. Ce qu'il remplace, c'est un motif : extractions point à point, entrepôts artisanaux, requêtes fragiles — au profit d'un produit gouverné.

Faut-il SAP Analytics Cloud en plus de Datasphere ?

Pour la consommation, oui : Datasphere modélise et gouverne, SAP Analytics Cloud restitue récits, applications et planification. N'acheter que la restitution disperse la sémantique dans des récits que personne ne détient.

Faut-il fédérer ou répliquer par défaut ?

Fédérer, et justifier chaque réplication par la latence, la charge de la source ou sa disponibilité. On inverse au-delà d'environ 100 Go de faits ou cinquante utilisateurs simultanés.

Sur quoi cette page s'appuie

À lire ensuite