• Actus

DLO (Data Lake Objects) et DMO (Data Model Objects)

Dans Salesforce Data 360, les données provenant du CRM, d’un site e-commerce, d’un outil marketing ou d’une plateforme externe ne peuvent pas être exploitées efficacement tant qu’elles restent organisées selon des structures différentes.

Les Data Lake Objects, ou DLO, et les Data Model Objects, ou DMO, interviennent à deux étapes distinctes de cette organisation.

Le DLO accueille les données issues d’une source. Le DMO leur donne ensuite une structure commune afin qu’elles puissent être rapprochées et utilisées dans Data 360.

Qu’est-ce qu’un Data Lake Object ?

Un Data Lake Object, généralement abrégé en DLO, est un objet utilisé pour accueillir les données ingérées ou fédérées dans Salesforce Data 360.

Salesforce le présente comme un conteneur fondamental dans lequel les données sont d’abord conservées avant d’être associées à un modèle harmonisé.

Lorsqu’une source est connectée à Data 360, un Data Stream organise l’arrivée des données. Les informations correspondantes sont ensuite représentées dans un ou plusieurs DLO.

Le DLO conserve une structure proche de celle de la source d’origine.

Par exemple, une plateforme e-commerce peut transmettre les champs suivants :

  • customer_id ;

  • customer_email ;

  • first_order_date ;

  • total_order_value.

Ces champs peuvent être conservés dans un DLO correspondant aux données clients de la plateforme e-commerce.

Quel est le rôle d’un DLO ?

Le DLO permet à Data 360 de recevoir et de rendre accessibles des données provenant de systèmes différents.

Il constitue une première couche entre la source et le modèle de données unifié.

Un DLO peut notamment contenir :

  • des données issues de Salesforce CRM ;

  • des commandes provenant d’un site e-commerce ;

  • des interactions marketing ;

  • des données de navigation ;

  • des tickets de support ;

  • des données provenant d’un entrepôt externe ;

  • des données accessibles par Zero Copy.

À ce stade, chaque source peut conserver ses propres noms de champs, formats et règles de structuration.

Deux systèmes peuvent donc représenter la même information différemment.

Un CRM peut utiliser le champ Email, tandis qu’un outil e-commerce utilise customer_email. Les deux informations ont la même signification métier, mais ne possèdent pas encore une structure commune.

Qu’est-ce qu’un Data Model Object ?

Un Data Model Object, ou DMO, est un objet qui organise les données selon un modèle harmonisé.

Salesforce définit le DMO comme un regroupement harmonisé de données provenant de Data Streams, d’insights ou d’autres sources. Les données d’un DLO sont standardisées en associant ses champs à ceux d’un DMO.

Le DMO permet donc de donner une signification commune aux données, indépendamment du système dont elles proviennent.

Plusieurs DLO peuvent être associés au même DMO.

Les données provenant du CRM, du site e-commerce et du service client peuvent, par exemple, être associées à des objets correspondant à une personne, un point de contact ou un engagement.

Quelle est la différence entre un DLO et un DMO ?

La différence principale réside dans leur rôle.

DLODMO
Accueille les données provenant d’une source Organise les données selon un modèle commun
Reste proche de la structure d’origine Utilise une structure harmonisée
Constitue une couche technique d’arrivée Apporte une signification exploitable dans Data 360
Peut contenir des noms de champs propres à la source Utilise des objets et des relations standardisés ou personnalisés
Est mappé vers un ou plusieurs DMO Peut recevoir des données provenant de plusieurs DLO

Une formulation simple permet de retenir la différence : Le DLO représente la manière dont la donnée entre dans Data 360. Le DMO représente la manière dont Data 360 comprend et organise cette donnée.

Exemple concret de passage d’un DLO à un DMO

Imaginons une entreprise qui utilise trois systèmes.

Dans le CRM

Le contact est identifié avec :

  • ContactId ;

  • FirstName ;

  • LastName ;

  • Email.

Dans la plateforme e-commerce

Le client est identifié avec :

  • customer_id ;

  • customer_name ;

  • customer_email.

Dans l’outil de support

L’utilisateur est identifié avec :

  • requester_id ;

  • requester_email ;

  • ticket_number.

Chaque système alimente un DLO différent.

Les champs Email, customer_email et requester_email peuvent ensuite être associés à un champ harmonisé représentant l’adresse e-mail d’un point de contact.

Les données restent issues de trois sources différentes, mais Data 360 dispose désormais d’une structure cohérente pour les exploiter.

Comment les DLO sont-ils associés aux DMO ?

L’association entre un DLO et un DMO est appelée mapping.

Le mapping consiste à indiquer quel champ de la source correspond à quel champ du modèle de données.

Par exemple :

Champ du DLOChamp du DMO
customer_id Party Identification Number
customer_email Email Address
first_name First Name
last_name Last Name

Cette étape exige une bonne compréhension des données.

Deux champs portant des noms différents peuvent avoir la même signification. À l’inverse, deux champs portant un nom similaire peuvent correspondre à des informations différentes.

Un mauvais mapping peut provoquer :

  • des profils incorrectement rapprochés ;

  • des données placées dans le mauvais objet ;

  • des segments incomplets ;

  • des analyses erronées ;

  • des activations marketing inadaptées.

Qu’est-ce que le Customer 360 Data Model ?

Le Customer 360 Data Model est le modèle standard proposé par Salesforce pour organiser les données dans Data 360.

Il contient différents objets et relations permettant de représenter notamment :

  • les personnes ;

  • les comptes ;

  • les coordonnées ;

  • les produits ;

  • les commandes ;

  • les engagements ;

  • les consentements ;

  • les interactions.

Les DMO standards facilitent l’utilisation de fonctionnalités communes à Data 360.

Une entreprise peut également créer des DMO personnalisés lorsqu’une donnée métier ne correspond pas correctement au modèle standard.

Où se situent les DLO et DMO dans le fonctionnement de Data 360 ?

Le parcours peut être résumé ainsi : Source de données → connecteur ou Zero Copy → Data Stream → DLO → mapping → DMO → unification → segmentation → activation

1. Connexion de la source

L’entreprise connecte une source telle qu’un CRM, un site e-commerce ou un entrepôt de données.

2. Création du Data Stream

Le Data Stream définit la manière dont les données sont récupérées et actualisées.

3. Création ou alimentation du DLO

Les données sont représentées dans un Data Lake Object selon une structure proche de leur source.

4. Mapping vers les DMO

Les champs du DLO sont associés aux objets et champs du modèle harmonisé.

5. Utilisation des données

Les DMO peuvent ensuite être exploités pour l’unification des profils, les insights, la segmentation ou l’activation.

Salesforce indique que les données ingérées sont stockées dans les DLO selon leur schéma initial avant d’être associées aux DMO du modèle Customer 360.

Pourquoi cette distinction est-elle importante ?

Comprendre la différence entre DLO et DMO permet d’éviter une confusion fréquente : connecter les données ne signifie pas qu’elles sont immédiatement prêtes à être utilisées.

Le DLO rend les données disponibles dans Data 360, mais le DMO leur apporte une structure cohérente.

Sans harmonisation, les mêmes notions peuvent rester réparties entre plusieurs champs ou plusieurs objets. Il devient alors difficile de :

  • rapprocher les identités ;

  • construire des segments fiables ;

  • analyser le parcours d’un client ;

  • utiliser les données dans un agent IA ;

  • activer les informations dans les autres outils.

Les erreurs fréquentes avec les DLO et les DMO

Mapper les champs uniquement selon leur nom

Le nom d’un champ ne permet pas toujours de comprendre son usage réel. Il faut également examiner son format, sa source et sa signification métier.

Créer trop de DMO personnalisés

Les objets personnalisés sont utiles, mais doivent répondre à un besoin qui ne peut pas être couvert correctement par le modèle standard.

Confondre harmonisation et unification

Le mapping vers un DMO harmonise la structure des données. Il ne détermine pas automatiquement si deux enregistrements correspondent à la même personne.

L’unification intervient ensuite, grâce à des règles de résolution d’identité.

Négliger les identifiants

Les clés primaires et les relations entre objets doivent être correctement définies. Une mauvaise gestion des identifiants peut créer des doublons ou rompre les relations entre les données.

Commencer le mapping sans modèle métier

Avant de configurer Data 360, l’entreprise doit déterminer ce que représentent ses données et comment elle souhaite les utiliser.

Questions fréquentes sur les DLO et les DMO

Un DLO est-il une base de données ?

Un DLO est un objet de stockage ou de représentation des données dans Data 360. Il ne doit pas être assimilé à une base de données indépendante.

Un DMO contient-il directement les données ?

Un DMO fournit une vue physique ou virtuelle des données harmonisées sous-jacentes, selon la manière dont la donnée a été connectée et configurée.

Plusieurs DLO peuvent-ils alimenter le même DMO ?

Oui. Plusieurs sources peuvent être associées à une structure harmonisée commune.

Un DLO peut-il être associé à plusieurs DMO ?

Selon la structure et les besoins de modélisation, les données d’un DLO peuvent servir à alimenter différents objets du modèle.

Le mapping fusionne-t-il automatiquement les profils ?

Non. Le mapping harmonise les données. La fusion ou le rapprochement des profils dépend ensuite des règles de résolution d’identité.

Faut-il toujours utiliser les DMO standards ?

Il est préférable de les utiliser lorsqu’ils correspondent au besoin. Des DMO personnalisés peuvent être créés pour les concepts métier qui ne trouvent pas leur place dans le modèle standard.

Pour aller plus loin

Vous souhaitez approfondir ce sujet ? Découvrez nos articles consacrés dans lesquels nous expliquons comment cette notion s’applique concrètement aux projets et aux enjeux des entreprises :