Fiche concept

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

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

Qu'est-ce que SAP Datasphere décisionnel — faire correspondre le modèle classique sans le casser ?

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.

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.

Le Space remplace le silo projet. Chaque objet vit dans un Space — une partition gouvernée avec sa sécurité, ses connexions et son cycle de vie. La consommation inter-Space passe par le Catalog sous forme de Data Products versionnés, jamais par un partage de tables ad hoc. C'est la partie qui paraît bureaucratique à une équipe habituée à un schéma partagé, et c'est précisément celle qui évite l'effondrement final du schéma partagé.

La couche sémantique est consommée par plus que des rapports. Un Analytic Model alimente SAP Analytics Cloud, mais aussi la couche de grounding de Joule et des outils externes via Delta Sharing. Une définition écrite pour un rapport est désormais une définition que plusieurs types de consommateurs lisent, ce qui élève l'exigence de justesse et abaisse la tolérance aux variantes locales.

Pourquoi cela compte maintenant, sur le marché français

Tout grand client SAP exploitant ECC ou BW classique est sur une horloge : la feuille de route de SAP les oriente vers S/4HANA et une couche analytique cloud-native, et Datasphere est la zone d'atterrissage. La population adressable est vaste — environ quatre mille clients BW sur le principal marché européen plus quelque dix-sept mille clients ECC — et le cycle de migration qui en résulte est le plus grand depuis le passage de BW sur HANA.

Pour une pratique décisionnelle, c'est tout le pipeline des prochaines années. C'est aussi pourquoi l'erreur de correspondance coûte cher : 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.

La décision qui vous appartient réellement

Pas si Datasphere — pour une organisation déjà engagée sur S/4HANA et SAP Analytics Cloud, la réponse est de fait oui, parce que c'est la couche dans laquelle SAP investit pour la fédération, la modélisation sémantique et le grounding IA.

La vraie question est quelle quantité y construire. Pour un petit besoin de reporting touchant une ou deux tables sources, sans exigence de réutilisation, une connexion live SAP Analytics Cloud directement sur S/4HANA est plus rapide à livrer et parfaitement légitime. Datasphere gagne sa place par la réutilisation et la gouvernance. Une équipe qui y modélise tout, y compris les coups uniques, a recréé le goulot d'équipe centrale qui avait rendu le modèle décisionnel classique impopulaire au départ.

Pièges

L'appeler « le nouveau BW » devant un client. Cela installe la mauvaise attente de migration et autorise une conception lift-and-shift qui transporte la dette.

Charger par défaut. La fédération existe ; faites de la réplication une décision assortie d'une raison énoncée — latence, charge sur la source, disponibilité — et non une habitude.

Traiter les Spaces comme des dossiers. Ce sont des frontières de gouvernance ; la consommation entre eux est un Data Product avec une version et un propriétaire, et concevoir en contournant cette règle réintroduit l'échec du schéma partagé.

Modéliser les coups uniques. C'est la réutilisation qui justifie la couche. Sans elle, vous avez ajouté un saut et une équipe à un rapport qui n'avait besoin ni de l'un ni de l'autre.

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.

Sources

Ouvrir dans l'application →