Fiche concept

SAP Datasphere décisionnel — faire correspondre le modèle classique sans le casser

À jour au 2026-08-02T22:40:00Z

Édité par Cédric-Olivier Mâry, é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 décisionnel — faire correspondre le modèle classique sans le casser ?

Arriver sur Datasphere avec le modèle décisionnel classique en tête produit une erreur de correspondance coûteuse — le traiter comme « le nouveau BW ». Trois différences cassent l'analogie : la fédération est de première classe, le Space remplace le silo projet, et la couche sémantique alimente plus que des rapports.

Les équipes SAP françaises disent encore décisionnel là où une présentation anglaise dit BI, et le mot transporte toute une architecture : un entrepôt, des univers, une couche sémantique tenue par une équipe centrale, et des rapports qu'un utilisateur métier demande plutôt qu'il ne construit. Quiconque arrive sur SAP Datasphere avec ce modèle en tête va faire une correspondance fausse — en général en traitant Datasphere comme « le nouveau BW » — et cette erreur de correspondance coûte cher parce qu'elle survit jusque dans la conception.

Datasphere n'est pas le nouveau BW, ni une couche d'univers

Datasphere est la couche de données et de sémantique unifiée au centre du parc analytique moderne de SAP : fédération, réplication et modélisation dans un seul produit, bâti sur HANA Cloud avec un Delta Lake intégré. Ce qu'il remplace n'est pas un prédécesseur mais un motif — la mosaïque d'extractions point à point, d'entrepôts construits à la main et de requêtes BEx fragiles qu'un parc décisionnel de longue vie accumule.

Trois différences comptent pour qui transporte le modèle classique.

La fédération est de première classe. Une requête live peut passer directement vers la source sans rien copier. Dans le modèle d'entrepôt classique, tout est chargé avant de pouvoir être modélisé ; ici, charger est un choix que l'on justifie, pas un défaut dont on hérite.

Pourquoi c'est important

Une équipe qui modélise Datasphere comme un BW réhébergé embarque la dette de l'ancien parc dans la nouvelle plateforme et la paie ensuite dans chaque application consommatrice.

Points clés

« Décisionnel » porte toute une architecture — entrepôt, univers, équipe sémantique centrale, rapports demandés — et la transposer naïvement sur Datasphere est l'erreur coûteuse.
Datasphere, c'est fédération + réplication + modélisation dans un seul produit, sur HANA Cloud avec un Delta Lake intégré.
Ce qu'il remplace n'est pas un prédécesseur mais un MOTIF : extraits point à point, entrepôts faits main, requêtes BEx fragiles.
Différence 1 — la fédération est de première classe : une requête live traverse sans rien copier. Le chargement devient un choix justifié, pas un défaut hérité.
Différence 2 — le Space remplace le silo projet ; la consommation inter-Space passe par un Data Product versionné via le Catalog, jamais par un partage de table ad hoc.
Différence 3 — un Analytic Model alimente SAC, la couche de grounding de Joule ET des outils externes via Delta Sharing. Plusieurs types de consommateurs lisent une seule définition.
Le contexte marché : ~4 000 clients BW sur le marché européen principal, sous l'horloge de la feuille de route SAP vers S/4HANA.
La décision n'est pas SI Datasphere — pour un engagement S/4HANA + SAC c'est effectivement tranché — mais COMBIEN y construire.
Un rapport ponctuel sur une ou deux tables est légitimement une connexion SAC live directe vers S/4HANA. Datasphere gagne sa place par la réutilisation.
Modéliser les cas ponctuels dans Datasphere recrée le goulot d'étranglement de l'équipe centrale qui a rendu le décisionnel classique impopulaire.

Termes employés sur cette page

Décisionnel: Le terme français pour business intelligence, qui transporte l'architecture classique : entrepôt, univers, équipe sémantique centrale, et rapports demandés plutôt que construits par l'utilisateur.
Fédération: Requête live en pass-through vers une source, sans déplacement de données — de première classe dans Datasphere, et la raison pour laquelle charger doit être un choix justifié.
Space: La partition gouvernée de Datasphere, avec sa sécurité, ses connexions et son cycle de vie. Une frontière de gouvernance, pas un dossier.
Data Product: L'unité versionnée et cataloguée par laquelle un Space consomme la sémantique d'un autre. L'alternative au partage de tables ad hoc.
Analytic Model: L'objet Datasphere qui porte la sémantique métier ; lu par SAC, par la couche de grounding de Joule et par des outils externes via Delta Sharing.
Requête BEx: L'objet de restitution classique de BW. Sa fragilité fait partie du motif que Datasphere remplace, ce n'est pas un composant à réhéberger.
Delta Lake: Le format de stockage ouvert intégré au socle HANA Cloud de Datasphere, et ce qui rend possible le partage externe multi-consommateurs.
Zone d'atterrissage: La plateforme vers laquelle la feuille de route SAP oriente les clients ECC et BW classique pour l'analytique — ce qui met le cycle de migration sur une horloge.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

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.