Données maîtres et identité

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Guide d’étude du chapitre 6 du cours Data Architect. Lisez d’abord les six modules, y compris le parcours commenté du point de contrôle 1 ; cette page vous aide à vérifier ce que vous en avez retenu.

À propos de ce guide d’étude. Il est construit uniquement à partir du contenu de ce cours et de la liste des objectifs publiée dans le guide d’examen de Salesforce. Il ne s’appuie jamais sur de vraies questions d’examen et ne prétend pas savoir ce que contient l’examen. Si vous avez passé l’examen, merci de ne pas m’en envoyer les questions : l’accord de certification interdit de les partager, et apprendre des réponses par cœur n’est de toute façon pas la bonne manière de devenir architecte.

Ce chapitre porte la section Master Data Management de l’examen (5 %) et la vue unique du client de Salesforce Data Management. C’est une petite section en pondération, mais ses idées (autorité, rapprochement, survivance) apparaissent dans beaucoup d’autres scénarios. Les chiffres de la plateforme changent, alors vérifiez les valeurs actuelles avant de vous y fier.

Pour l’examen

Cochez-les au fur et à mesure. Chacun renvoie à l’endroit où il est enseigné.

MDM-2 : un golden record et un système de vérité

• Je sais que l’autorité s’attribue par attribut, pas par enregistrement : un compte peut avoir des champs maîtrisés dans l’ERP et des champs maîtrisés dans Salesforce. (La vérité appartient à un attribut)
• Je demande où chaque attribut est créé, modifié et référencé, et sa latence de changement. (Créé, modifié, référencé, et à quelle vitesse ?)
• Je sais construire une carte des autorités, et je sais que le propriétaire métier et le système qui fait autorité ne sont pas la même chose. (Construisez une carte des autorités)
• Je sais que l’autorité peut changer au fil du cycle de vie (un prospect dans Salesforce devient un client gouverné par l’ERP), et qu’une copie n’est pas une autorité. (L’autorité change au fil du cycle de vie, Une copie n’est pas une autorité)

MDM-1 : les techniques de MDM

• À savoir pour l’examen : je connais les quatre styles de mise en œuvre du MDM, registre, consolidation, coexistence et centralisé : ce que chacun centralise et s’il renvoie les valeurs. (Les quatre côte à côte)
• Je sais distinguer les quatre styles de MDM : registre, consolidation, coexistence et centralisé, et choisir le plus léger qui résout le problème. (Les quatre côte à côte)
• Je sais qu’un modèle de données canonique harmonise la structure, mais ne décide pas de l’autorité. (Un modèle commun n’est pas une vérité commune)
• Je connais l’ordre : harmoniser, puis rapprocher, puis consolider. (Harmoniser, puis rapprocher, puis consolider)
• Je sais que les seuils reflètent la tolérance à l’erreur, et que l’enrichissement a besoin de provenance. (Seuils, revue et enrichissement)
• À savoir pour l’examen : je connais la gestion des hiérarchies : le champ Compte parent construit la hiérarchie (la vue Lightning affiche jusqu’à 2 000 comptes, sans les comptes personnels), les hiérarchies ont souvent une maîtrise partagée, et une entreprise peut avoir plusieurs hiérarchies valides. (Les hiérarchies sont aussi des données maîtres, Une hiérarchie, plusieurs maîtres)

MDM-3 : choisir les attributs gagnants

• Je garde séparés le rapprochement, la fusion et la survivance. (Rapprochement, fusion et survivance)
• Je connais les règles de survivance : la plus récente, la plus fréquente, la priorité des sources, et je sais que chaque règle a besoin d’un propriétaire. (La survivance : quelle valeur l’emporte ?)
• Je sais qu’un rapprochement n’exige pas une fusion, et je ne fusionne qu’avec un gagnant clair, en décidant d’abord de ce qui arrive aux enfants. (Un rapprochement n’exige pas une fusion, Ma règle de fusion : un gagnant clair)
• À savoir pour l’examen : je sais ce que fait une fusion de comptes Salesforce : jusqu’à trois enregistrements, un principal, le Créé par et la Date de création les plus anciens conservés, les autres à la Corbeille, et les objets de point de contact non fusionnés pour les comptes personnels. (Ce que fait réellement une fusion Salesforce)

SDM-3 : une vue unique du client

• Je sais que la résolution d’identité de Data 360 relie les profils sources en un profil unifié et garde les liens de retour : c’est le plus proche d’un registre. (La résolution d’identité répond à « qui ? »)
• À savoir pour l’examen : je connais les règles de rapprochement de Data 360 : tous les critères d’une règle doivent correspondre, n’importe quelle règle peut rapprocher ; plus de critères pour la précision, moins pour la consolidation. (Les règles de rapprochement)
• Je connais les méthodes de rapprochement (Exact, Exact Normalized, Fuzzy à trois niveaux de précision) : une méthode moins précise augmente la consolidation, et le risque de faux rapprochements. (Les règles de rapprochement)
• À savoir pour l’examen : je sais que les règles de réconciliation (Last Updated, Most Frequent, Source Priority) décident de ce qu’affiche le profil unifié, mais ne modifient pas les sources ; les points de contact ne sont pas réconciliés. (La réconciliation n’est toujours pas la maîtrise)
• Je sais choisir entre la gestion des doublons, la résolution d’identité et une plateforme MDM dédiée selon le travail. (Trois outils pour trois travaux)

MDM-4 et les données à double sens

• Je sais que des données à double sens ne veulent pas dire deux maîtres : une modification dans Salesforce d’un champ possédé par l’ERP est une demande, donc je conçois demander → valider → accepter → publier, avec un état en attente. (Des données à double sens ne veulent pas dire deux maîtres, Quand le maître dit non)
• Je sais éviter les boucles et les collisions : distinguer un changement d’origine de son écho, et décider quels champs voyagent ensemble comme une seule transaction. (Boucles et collisions)
• Pour un client présent dans deux ERP, je sais choisir entre une hiérarchie, des comptes pairs ou un compte avec un enfant par ERP, selon la manière dont le client garde ses ERP synchronisés. (Un client, deux ERP, Demandez comment ils synchronisent leurs ERP)

Point de contrôle 1 : assembler la partie 1

• À savoir pour l’examen : je sais quelles licences externes ont le partage standard : Customer Community Plus et Partner Community, qui ont besoin de rôles pour les utilisateurs externes ; Customer Community utilise des ensembles de partage. (Qui voit quoi, et qui a besoin d’une licence)

Au-delà de l’examen

L’examen est le plancher, pas le plafond. Voici les habitudes de ce chapitre dont un architecte a besoin, qu’une question les aborde ou non.

• « Source unique de vérité » : quelle vérité ? C’est une architecture de la vérité, pas un enregistrement unique.
• Rendez l’autorité visible dans le schéma : un préfixe pour les champs qu’un autre système possède.
• La confiance demande plus qu’une valeur : la source, la dernière confirmation, qui l’a modifiée.
• Commencez par le problème, pas par le produit MDM. Le MDM est une décision métier sur l’autorité.
• Relier n’est pas maîtriser.
• Là où les faux rapprochements coûtent cher, sous-rapprochez délibérément.
• Gardez les doublons issus de chargements externes quand vous risquez d’avoir besoin de remonter à la source.
• Un profil unifié est une carte. Un golden record est une décision.
• L’affichage n’est pas l’autorité.
• Unifier l’identité n’efface pas les frontières de sécurité.
• Le plus difficile, ce sont les bidirectionnels. L’autorité partagée n’est pas le problème ; l’autorité ambiguë, si.
• Ne laissez jamais une demande rejetée se transformer en vérité concurrente.
• C’est un champ qui dit qu’il s’agit de données maîtres qui pilote la modifiabilité, pas un type d’enregistrement.
• Nous ne contrôlons pas les ERP. Nous contrôlons la façon dont nous les représentons dans Salesforce.

Les mots à connaître

Terme	En une ligne
Gestion des données maîtres (MDM)	Établir et gouverner l’identité et les valeurs qui font autorité des données clés à travers les systèmes
Carte des autorités	Pour chaque attribut : qui le crée, qui possède la décision, quel système fait autorité, qui peut le modifier
Golden record	Une décision gouvernée sur les valeurs qui font autorité
Golden record hybride	Un enregistrement dont certains attributs sont maîtrisés ailleurs et copiés dedans, et d’autres possédés localement
Registre	Un MDM qui relie des enregistrements comme une même entité sans modifier les sources
Consolidation	Un MDM qui combine les données de façon centrale, généralement pour l’analytique, sans les renvoyer
Coexistence	Un MDM qui décide de la valeur maîtrisée et la republie vers les sources
MDM centralisé	Un MDM où les données gouvernées sont créées dans le maître puis distribuées
Modèle de données canonique	Une forme d’entreprise convenue pour un concept, qui sert à faire correspondre les systèmes entre eux
Harmonisation	Rendre les valeurs comparables : formats, codes et abréviations standard
Rapprochement	Décider si des enregistrements représentent la même chose
Survivance	Les règles qui décident quelle valeur l’emporte quand les sources ne sont pas d’accord
Enregistrement principal	Dans une fusion Salesforce, l’enregistrement qui survit et conserve ses champs masqués et en lecture seule
Méthode de rapprochement	La façon dont un critère de rapprochement Data 360 compare les valeurs : exacte, exacte normalisée ou approximative (fuzzy)
Résolution d’identité	Le rapprochement par Data 360 de profils sources en profils unifiés
Profil unifié	Un ensemble de clés qui relient les enregistrements sources représentant une personne ou une entreprise
Règles de réconciliation	Les règles Data 360 qui décident quelle valeur affiche un profil unifié
Hiérarchie à maîtrise partagée	Une hiérarchie dont les branches sont possédées par des systèmes différents

Testez-vous

De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.

1. « Salesforce est notre source unique de vérité pour le client. » Que demandez-vous ?

Quelle vérité ? L’autorité est par attribut : l’ERP peut posséder la raison sociale, l’adresse de facturation et la limite de crédit pendant que Salesforce possède le responsable de compte et le niveau de succès client. Construisez une carte des autorités. Relisez La vérité appartient à un attribut.

2. Les agents de service doivent voir qu'un contact Salesforce est la même personne qui a acheté en ligne. Personne n'a besoin que les systèmes changent. Quel style de MDM ?

Un registre : relier les enregistrements comme une seule identité sans modifier les sources, ce que fait la résolution d’identité de Data 360. Choisissez le modèle le plus léger qui résout le problème. Relisez Le registre : dites-moi qui est qui.

3. La survivance est réglée sur « la plus récente l'emporte » pour chaque champ. Quelqu'un modifie la copie Salesforce de la raison sociale possédée par l'ERP. Que se passe-t-il, et qu'est-ce qui ne va pas ?

La valeur la plus récente l’emporte, et la copie écrase l’autorité. « La plus récente » est une déclaration de confiance qui convient à certains attributs (un numéro de cellulaire) et pas à d’autres. Là où la carte des autorités dit que l’ERP possède le champ, l’ERP l’emporte. Relisez La survivance : quelle valeur l’emporte ?.

4. Des fiches client héritées sont importées et correspondent à des comptes existants. Faut-il les fusionner ?

Soyez prudent. Un rapprochement n’exige pas une fusion, et fusionner détruit les ID hérités et les anciennes valeurs dont vous pourriez avoir besoin pour remonter à la source. Reliez-les, sauf s’il y a un gagnant clair et que le doublon n’apporte rien dont vous ayez besoin. Relisez Ma règle de fusion : un gagnant clair.

5. Le profil unifié dans Data 360 affiche Dallas. L'équipe dit que Dallas est désormais la valeur de référence pour chaque système. Est-ce le cas ?

Non. La réconciliation décide de ce qu’affiche le profil unifié ; elle ne modifie pas les sources et ne prend pas de décision de maîtrise. Si chaque système doit utiliser une seule valeur gouvernée, c’est de la coexistence ou du MDM centralisé, avec un propriétaire. Relisez La réconciliation n’est toujours pas la maîtrise.

6. Rapprocher des dossiers médicaux et rapprocher des fiches marketing : mêmes règles ?

Non. Un faux rapprochement en marketing envoie la mauvaise offre ; dans des données médicales, il combine les antécédents de deux personnes. Fixez la sévérité selon le coût de l’erreur, et sous-rapprochez là où mélanger coûte cher. Relisez Le coût de l’erreur.

7. Les commerciaux veulent mettre à jour depuis Salesforce une adresse de facturation possédée par l'ERP. Comment le concevez-vous ?

Comme une demande, pas une modification : Salesforce envoie la valeur proposée, l’ERP la valide, l’accepte et republie la valeur qui fait autorité. Gardez un état en attente jusque-là, et gérez les rejets, les collisions et les échos. Relisez Des données à double sens ne veulent pas dire deux maîtres.

8. Chez Steve Trucking, le même John Smith apparaît dans les manifestes de deux partenaires distributeurs. Faut-il l'unifier ?

Non, délibérément. Chaque partenaire ne doit jamais voir les destinataires d’un autre, et une identité unifiée est la passerelle par laquelle cela fuit. Sous-rapprochez là où mélanger coûte cher ; si un partenaire veut reconnaître les destinataires récurrents, limitez-le à ce seul partenaire. Relisez Unifierais-je les destinataires entre partenaires ?.

9. Un commercial envoie une nouvelle rue pour une adresse possédée par l'ERP pendant que, la même minute, quelqu'un dans l'ERP change la ville. Que décidez-vous ?

Si l’adresse voyage comme une seule transaction. Si c’est le cas, les champs passent tous ensemble ou aucun ne passe, et la demande est rejetée parce que l’adresse a changé entre-temps. Décidez-le avant la première collision, et souvenez-vous que la demande demande à changer la valeur de l’ERP, elle ne la change pas. Relisez Boucles et collisions.

10. Un client a un même client final dans deux ERP, et personne ne garde les deux enregistrements synchronisés. Les ventes veulent un seul compte. Que recommandez-vous ?

Pas un seul compte. S’il ne sait pas garder les enregistrements synchronisés dans ses propres ERP, Salesforce ne peut pas le faire à sa place : représentez-les comme des comptes pairs ou une hiérarchie, et montrez la structure que les ventes connaissent déjà. Un compte avec un enfant par ERP exige un client qui garde les valeurs partagées synchronisées. Relisez Demandez comment ils synchronisent leurs ERP.

Pour aller plus loin

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-09-25) : la liste officielle des objectifs et de leurs pondérations. Vérifiez toujours la version actuelle avant de réserver l’examen.
• La section Pour aller plus loin de chaque module liste la documentation Salesforce derrière ses faits, avec la date de vérification.