Relier n'est pas maîtriser

🌐 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)

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

Chapitre 6 de Data Architect, Partie 1 : Devenir architecte de données. Précédent : Qualité et gouvernance des données.

« Il nous faut une source unique de vérité. » C’est l’une des phrases les plus répétées en architecture, et l’une des moins examinées. Pour quoi ? Prenez un compte. L’ERP peut posséder sa raison sociale, son adresse de facturation et sa limite de crédit ; Salesforce son responsable de compte et son niveau de support ; une plateforme de consentement ses préférences marketing. Trois autorités sur un seul enregistrement, et c’est normal. Alors quand quelqu’un dit « Salesforce est notre source unique de vérité pour le client », ma question suivante est toujours : quelle vérité ?

Ce chapitre consiste à répondre délibérément à cette question. L’autorité s’attribue attribut par attribut. Relier des enregistrements, ce n’est pas les maîtriser. Et Salesforce vous donne des outils différents pour des travaux différents : la gestion des doublons et la fusion à l’intérieur d’une organisation ; la résolution d’identité de Data 360 pour une vue unique à travers les sources ; une plateforme MDM dédiée quand les valeurs doivent être décidées une fois puis renvoyées partout. Il se termine par le point de contrôle 1, où la partie 1 se rassemble sur Steve Trucking.

Image générée par IA.

Les positions de ce chapitre

• La vérité attribut par attribut. Demandez où chaque donnée est créée, modifiée et référencée, et à quelle vitesse elle change. Montrez l’autorité externe dans le schéma avec un préfixe de système, comme sap_ ou erp_.
• Les prospects sont différents. Ils vivent dans Salesforce avant que l’ERP les connaisse ; l’autorité de l’ERP s’applique après la conversion.
• Le registre est la norme dans les projets Salesforce, puis la consolidation et la coexistence ; le MDM centralisé pur est rare.
• Ne fusionnez que s’il y a un gagnant clair. Gardez les doublons issus de chargements externes quand vous risquez d’avoir besoin de remonter à la source ; la fusion détruit cet historique. Et décidez de ce qui arrive aux enfants : déplacez-les, ne les chargez pas, ou gardez-les sur un enregistrement inactif.
• Un profil unifié est une carte ; un golden record est une décision. Cela peut prêter à confusion : la résolution d’identité crée un individu unifié, mais pas un golden record.
• La sévérité du rapprochement est une décision de risque. Là où mélanger coûte cher, sous-rapprochez délibérément.
• Trois outils pour trois travaux : fusion, résolution d’identité, MDM.
• Les hiérarchies ont une maîtrise partagée. Décidez de l’autorité branche par branche.
• « Le plus difficile, ce sont les bidirectionnels. » Une intégration à double sens ne fait pas deux maîtres. Décidez quels champs voyagent ensemble comme une seule transaction avant la première collision.
• Rendez les données maîtres visibles. C’est un champ qui dit qu’il s’agit de données maîtres (la clé de l’ERP ou un indicateur) 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 : un client présent dans deux ERP devient 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.

Trois outils pour trois travaux

Le travail	L’outil	Ce qu’il fait aux sources
Des doublons dans une organisation, avec un gagnant clair	Gestion des doublons et fusion	Fusionne jusqu’à trois enregistrements ; les autres vont à la Corbeille
Une identité et une vue unique à travers les sources	Résolution d’identité de Data 360	Les relie ; n’en modifie aucune (un registre)
Une valeur gouvernée, renvoyée à chaque système	Une plateforme MDM dédiée	Décide de la valeur et la distribue (coexistence ou centralisé)

Le parcours de ce chapitre

Six modules et un défi, chacun autonome.

1. Une source de vérité par attribut. La carte des autorités, le golden record hybride, et les signaux de confiance.
2. Les quatre façons de maîtriser les données. Registre, consolidation, coexistence et centralisé, et pourquoi un modèle commun n’est pas une vérité commune.
3. Rapprochement, fusion et survivance. Le coût d’un faux rapprochement, ce que fait vraiment une fusion Salesforce (et ce qui arrive aux enfants), et la survivance comme déclaration de confiance.
4. Une carte n’est pas une décision. Règles et méthodes de rapprochement, règles de réconciliation, et pourquoi un profil unifié n’est pas un golden record.
5. Quand l’autorité est partagée. Demandes contre mises à jour, boucles et collisions, hiérarchies à maîtrise partagée, et un client dans deux ERP.
6. Le défi du point de contrôle 1, puis Point de contrôle 1 : Steve Trucking, ce que j’architecturerais. Essayez d’abord le défi : dessinez et défendez la conception de la partie 1, puis comparez-la avec la mienne, et voyez ce qui change par rapport au paysage du chapitre 4.

Quand vous avez terminé, testez-vous avec le guide d’étude du chapitre : une liste de contrôle pour l’examen, les habitudes qui vont au-delà, les mots à connaître et quelques questions. Il clôt la partie 1 ; le guide d’étude de la partie 1 rassemble les six chapitres.

Ce qu’un architecte décide ici

• Quel système fait autorité pour chaque attribut important, et comment cela se voit dans le modèle.
• Quel style de maîtrise convient à chaque domaine de données, et quelle autorité reçoit la couche de maîtrise.
• Quand fusionner, quand relier, et qui possède chaque règle de survivance.
• À quel point le rapprochement doit être strict, selon ce que coûte un faux rapprochement.
• Où les données à double sens et les hiérarchies partagées ont besoin de frontières explicites.

Au-delà de l’examen : les agents ont besoin d’une identité sur laquelle agir, et cela augmente les enjeux dans les deux sens. Le sur-rapprochement devient un incident de protection des données, et un agent qui « met à jour le client » doit écrire dans le système d’enregistrement de chaque attribut, pas dans le profil unifié. Chaque module se termine par ce que l’IA change.

Pour aller plus loin

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) et Identity Resolution Reconciliation Rules (opens in a new tab) (en anglais), consulté le 2026-10-14.

Suivant : la partie 2 commence avec Concevoir pour le volume (coming soon).