Fiche concept

Espaces et espaces de travail

À jour au 2026-07-24T14:00: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 Espaces et espaces de travail ?

Un Space est une frontière de livraison, pas un tenant d'isolation — tout le tenant Datasphere continue de partager un seul pool HANA Cloud, un seul budget CU, un seul Catalog et un seul modèle d'auth.

Ce que c'est

Un Space dans SAP Datasphere est une partition logique au sein d'un tenant qui porte ses propres tables, vues, modèles analytiques, hiérarchies, devises et permissions. C'est l'unité fondamentale de livraison et de gouvernance dans Datasphere — chaque objet qu'un modélisateur construit vit à l'intérieur d'exactement un Space, détenu par une équipe, avec une cadence de livraison.

Pourquoi c'est important

La conception des Spaces est la décision architecturale unique à la plus longue portée dans un programme Datasphere. Bien la réussir, et la collaboration inter-équipes circule à travers des contrats propres et versionnés ; la rater, et la plateforme se fige soit en un monolithe que personne ne peut modifier en toute sécurité, soit en un labyrinthe de dépendances point à point entre Spaces qui transforme chaque changement de schéma en négociation inter-équipes. Comme les Spaces déterminent aussi la sécurité, la visibilité des coûts et la propriété du cycle de vie, la décision prise en semaine un d'un programme façonne encore la difficulté ressentie en année trois.

Comment ça marche

Pourquoi c'est important, en pratique

Au-delà de quatre ou cinq Spaces fonctionnels, le partage inter-Spaces dépasse typiquement 50 % des objets — le signal que l'organigramme a été projeté sur la plateforme au lieu d'un modèle de livraison.
L'accès direct via Shared Object entre Spaces contourne le contrat Data Product et crée un couplage non documenté qui casse dès que l'équipe productrice refactore.
Le schéma canonique Tier-1 est 3-4 Spaces fonctionnels plus un Shared Space pour les master data — le mid-market doit se réduire à 1-2 Spaces, pas reproduire par défaut le pattern enterprise.

Points clés

Space = frontière de livraison (une équipe, une cadence, un contrat). PAS un tenant.
Modèle Tier-1 : 3-4 Spaces fonctionnels + 1 Shared Space de données de référence. Au-delà de 5 Spaces = signal d'alerte.
Partage inter-Space via les Data Products dans le Catalog — des contrats versionnés, pas des Shared Objects.
Cycle de vie d'un Space : provisionnement (piloté par l'opérateur) → construction (pilotée par la delivery) → publication (validation du steward) → maintien (hygiène trimestrielle).
Modèle de permissions à quatre rôles : Admin / Modeler / Integrator / Viewer. DAC se superpose au-dessus.
Le pool de CU est au niveau du tenant ; la refacturation par Space se fait via le Tenant Monitor sur 30 jours glissants, pas par des plafonds imposés par la plateforme.
Multi-région avec résidence stricte = multi-tenant + fédération Delta Sharing ; pas du multi-Space au sein d'un seul tenant.
L'hygiène trimestrielle du Catalog élimine 30-40 % du poids mort accumulé dans tout Space vieux de 2 ans ou plus.
Spaces & Workspaces n'est maîtrisé que lorsqu'il change une décision d'acheteur nommée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.

Termes employés sur cette page

Space: Frontière logique de livraison au sein d'un tenant Datasphere. Détient les tables, vues, modèles et permissions d'un domaine. Ce n'est PAS un tenant.
Shared Space: Space dédié aux données de référence transverses (Customer, Material, Time, Currency, Cost Centre). En lecture par défaut pour les autres Spaces.
Data Product: Contrat de schéma versionné et documenté, publié dans le Catalog. Le mécanisme canonique de partage inter-Spaces.
Catalog: Couche de métadonnées à l'échelle du tenant, hébergeant les types sémantiques, le lignage, les Data Products et les règles DAC. Se situe au-dessus de tous les Spaces.
Space Admin: Rôle qui gère les membres du Space et les intégrations. Un par Space, idéalement le data steward de la LoB.
Modeler: Rôle qui crée et édite les objets (tables, vues, Analytic Models). En général 2 à 4 par Space.
Integrator: Rôle qui configure les Connections et les Replication Flows. En général 1 à 2 par Space.
Tenant Monitor: Tableau de bord intégré affichant la consommation de CU par Space, la charge de requêtes et la santé de la réplication.

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 →