Data Spaces : organiser les données par marque ou région

Un Data Space est une partition logique de Data Cloud qui permet de cloisonner des données au sein d'un même org : par marque, par filiale, par région géographique (utile notamment pour le respect de réglementations comme le RGPD selon les pays), ou par ligne de métier. Chaque org Data Cloud dispose d'un Data Space par défaut ; en créer de nouveaux devient nécessaire dès que plusieurs entités doivent partager la même instance technique sans que leurs données ou leurs configurations d'Identity Resolution ne se mélangent.

Ce qui est cloisonné par Data Space

Chaque Data Space possède ses propres instances de plusieurs objets de configuration :

• Identity Resolution Rulesets : une marque peut avoir des règles de matching différentes d'une autre.
• Segments : les segments sont définis et exécutés dans le contexte d'un Data Space spécifique.
• Calculated Insights : peuvent être définis par Data Space ou partagés selon la configuration.
• Data Streams : chaque stream est rattaché à un Data Space cible lors de sa création.

En revanche, le modèle de données (DMO) reste globalement partagé au niveau de l'org : ce sont les données elles-mêmes, et certaines configurations opérationnelles, qui sont cloisonnées par Data Space, pas la structure du modèle sémantique.

Quand créer plusieurs Data Spaces

La décision de multiplier les Data Spaces doit rester exceptionnelle et répondre à un besoin réel de cloisonnement, pour deux raisons : chaque Data Space additionnel augmente la complexité de maintenance, et certaines configurations (comme l'Identity Resolution) doivent être dupliquées et maintenues séparément. Les cas légitimes les plus courants :

• Plusieurs marques juridiquement ou commercialement distinctes qui ne doivent jamais partager de profils clients unifiés entre elles.
• Des contraintes réglementaires de résidence ou de traitement des données différentes selon les régions.
• Des filiales avec des cycles de vie produit et des équipes marketing totalement indépendants.

À l'inverse, si l'objectif est simplement de segmenter l'analyse (par exemple, filtrer les rapports par pays) sans besoin de cloisonnement strict des règles de matching, un attribut de filtrage classique sur les DMO est souvent suffisant et plus simple à maintenir qu'un Data Space dédié.

Créer et configurer un Data Space

Depuis Data Cloud > Data Spaces > New Data Space, vous nommez le Data Space puis l'associez progressivement aux Data Streams, Identity Resolution Rulesets et Segments qui doivent lui être rattachés. Pour un Data Stream déjà existant destiné à alimenter plusieurs Data Spaces (cas d'une source commune type CRM central), il faut définir explicitement le mapping de Data Space au niveau du Data Stream, souvent via un champ discriminant présent dans la source (un champ "Marque" ou "Business Unit" sur l'objet Salesforce d'origine).

Partage de données entre Data Spaces

Data Cloud permet, dans certains cas, de partager des objets spécifiques entre Data Spaces via des règles de partage dédiées (par exemple, un référentiel produit commun à toutes les marques). Ce partage doit être configuré explicitement et avec parcimonie : l'intérêt principal du cloisonnement en Data Spaces est justement d'éviter les fuites de données non maîtrisées entre entités, et un partage mal configuré peut recréer les problèmes que le Data Space visait à éviter.

Avant de créer un nouveau Data Space, posez la question inverse : quelles données doivent explicitement être partagées entre les entités malgré le cloisonnement (référentiel produit, catalogue commun) ? Cadrer ce périmètre de partage dès la conception évite des retouches coûteuses une fois les Rulesets et Segments déjà construits séparément.

Impact sur les licences et la gouvernance

La stratégie de Data Spaces doit être décidée en amont avec les équipes IT et conformité, car elle structure durablement l'architecture du projet : migrer des données d'un Data Space vers un autre après coup n'est pas une opération triviale, contrairement à un simple changement de filtre de rapport. Pour un déploiement multi-marques ou multi-pays, documentez la matrice Data Space / Data Streams / Rulesets dès le cadrage, et assignez un propriétaire fonctionnel par Data Space pour éviter les dérives de configuration au fil du temps.