Les quatre façons de maîtriser les données
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)
Module 2 sur 6 du chapitre Données maîtres et identité, chapitre 6 du cours Data Architect. Chaque module est autonome. Précédent : Une source de vérité par attribut · Suivant : Rapprochement, fusion et survivance
La question à laquelle répond ce module : comment les organisations maîtrisent-elles leurs données, et quel style convient ?
Le module 1 disait que l’autorité s’attribue attribut par attribut. Maintenant : que faisons-nous quand ces attributs vivent dans plusieurs systèmes à la fois ? Des informations client dans Salesforce, l’ERP, la facturation, le support, peut-être Data 360, peut-être un entrepôt de données, chacun avec sa propre version. C’est le problème que la gestion des données maîtres (MDM) tente de résoudre, et le MDM n’est pas une architecture unique. Vous entendrez parler de quatre modèles : registre, consolidation, coexistence et centralisé. Ce ne sont pas des réglages de produit. Ce sont quatre réponses à une seule question : quelle autorité a la couche de maîtrise ?
Commencez par le problème, pas par le produit
Section intitulée « Commencez par le problème, pas par le produit »Les gens entendent MDM et partent à la recherche d’un produit MDM. Je commencerais par le problème. Avons-nous seulement besoin de savoir que plusieurs enregistrements sont le même client ? Avons-nous besoin d’une vue combinée pour l’analytique ? Avons-nous besoin de décider quelles valeurs font autorité et de les renvoyer aux autres systèmes ? Ou voulons-nous qu’un système central crée les données maîtres pour tout le monde ? Des exigences très différentes, des architectures très différentes.
Le registre : dites-moi qui est qui
Section intitulée « Le registre : dites-moi qui est qui »Le modèle le plus léger. Un registre ne remplace pas les sources. L’ERP garde son client, Salesforce son compte, la facturation son client, et le registre établit que ces enregistrements représentent la même entité : le compte Salesforce 001…, le client ERP SAP-43821 et le client de facturation BILL-9127 appartiennent à un même client. Les sources restent où elles sont et ne sont pas écrasées. Maintenant, « montre-moi tout ce que nous savons sur ce client » a une réponse.
Mais remarquez ce à quoi un registre ne répond pas. Salesforce dit 123 Main Street, l’ERP 125, la facturation « 123 Main St., Suite 200 ». Le registre sait qu’ils vont ensemble. Il ne décide pas lequel doit changer. Relier n’est pas maîtriser.
D’après mon expérience, le registre est la norme dans les projets Salesforce, puis la consolidation et la coexistence ; le MDM centralisé pur est rare. Le registre est courant parce qu’il n’est pas invasif. Vous ne reconcevez pas chaque système opérationnel avant d’en tirer de la valeur. Salesforce continue de faire ce qu’il fait, l’ERP continue de faire ce qu’il fait, et vous ajoutez une couche d’identité. C’est un changement bien plus petit que de dire à chaque système « vous ne contrôlez plus les données clients ; c’est ce nouveau système central qui le fait ».
Le registre répond : quels enregistrements appartiennent à la même entité ?
La consolidation : rassembler les données
Section intitulée « La consolidation : rassembler les données »La consolidation prend les données de plusieurs sources et les combine dans une représentation centrale, pour les rapports, l’analytique, la segmentation, la connaissance client. Un entrepôt de données en est l’exemple familier : Salesforce envoie le client, l’ERP les données financières, la facturation les paiements, et le métier peut enfin analyser le client à travers les systèmes. Les sources existent toujours et peuvent toujours faire autorité. Le sens compte : les données circulent vers le système consolidé, qui ne renvoie généralement pas de changements maîtrisés. Une meilleure image du client, sans en devenir l’autorité opérationnelle.
On confond facilement registre et consolidation. La différence, c’est ce qui est centralisé : le registre centralise l’identité (« ceux-là vont ensemble ») ; la consolidation centralise davantage les données (« rassemblons les attributs pour pouvoir les utiliser »). Aucun des deux ne dit « ce système central est désormais le maître et chaque application doit accepter ses valeurs ».
La consolidation rassemble les données sans retirer la propriété aux sources.
La coexistence : décider, et renvoyer
Section intitulée « La coexistence : décider, et renvoyer »Dans la coexistence, la couche de maîtrise reçoit une vraie autorité. Les données vivent toujours dans plusieurs systèmes opérationnels, mais le processus MDM décide de la valeur maîtrisée et la republie. Salesforce, l’ERP et la facturation ont chacun une raison sociale différente ; le processus MDM détermine celle qui est gouvernée et la distribue aux trois. Les systèmes coexistent, mais ils convergent vers la valeur maîtrisée.
C’est une forme de MDM bien plus forte. Elle ne dit pas « ceux-là vont ensemble » ; elle dit « pour cet attribut, voici la valeur que l’entreprise utilise ». Cela demande plus que le rapprochement : des règles métier, une propriété, de la survivance, une intégration à double sens, une gestion des erreurs et une gouvernance, car quelqu’un doit décider pourquoi une valeur l’emporte.
La coexistence ne se contente pas de relier les enregistrements. Elle décide des valeurs maîtrisées et les renvoie.
Le centralisé : le maître crée la vérité
Section intitulée « Le centralisé : le maître crée la vérité »Le modèle le plus fort. Dans le MDM centralisé, les données maîtres gouvernées sont créées et maintenues dans le maître central et distribuées à tous les autres. Au lieu que chaque système crée son propre client et que le MDM les réconcilie ensuite, vous créez le client gouverné dans le maître, puis l’envoyez à Salesforce, à l’ERP et à la facturation. Une gouvernance très forte, et un changement très important : les processus existants créent leurs propres clients, les utilisateurs ont leurs habitudes de travail, les intégrations supposent une création locale, et les unités commerciales ne s’accordent peut-être même pas sur ce qu’est un client. C’est pourquoi il est rare dans les paysages Salesforce que je vois. Il peut être le bon choix. C’est une décision bien plus grande que l’installation d’un outil.
Le MDM centralisé déplace la création et l’autorité dans le maître.
Les quatre côte à côte
Section intitulée « Les quatre côte à côte »| Style | Ce qui est centralisé | Les sources restent-elles ? | Renvoie-t-il les valeurs gouvernées ? |
|---|---|---|---|
| Registre | L’identité et les liens | Oui | Généralement non |
| Consolidation | L’identité plus les données combinées | Oui | Généralement non |
| Coexistence | L’identité, les données et les décisions maîtrisées | Oui | Oui |
| Centralisé | La création et l’autorité | Oui, comme consommateurs | Oui |
En descendant le tableau, la couche de maîtrise reçoit plus d’autorité, et l’organisation doit généralement changer davantage.
À savoir pour l’examen. Connaissez les quatre styles de mise en œuvre du MDM : registre (relie les identités ; les sources gardent leurs données), consolidation (rassemble les données, généralement pour l’analyse), coexistence (décide des valeurs maîtrisées et les republie vers les sources) et centralisé (le maître crée les données ; les sources les consomment).
Il n’y a donc pas de « le centralisé est le plus mature, donc tout le monde doit y arriver ». Choisissez le modèle le plus léger qui résout le problème. Besoin de savoir que des enregistrements vont ensemble ? Pensez registre. Une vue combinée pour l’analytique ? Consolidation. Des valeurs gouvernées synchronisées vers plusieurs systèmes opérationnels ? Coexistence. Un seul processus qui crée et contrôle les données maîtres pour tout le monde ? Centralisé.
Où se place Data 360 ?
Section intitulée « Où se place Data 360 ? »Data 360 construit des profils unifiés à travers de nombreuses sources, ce qui ressemble beaucoup à du MDM, et il résout effectivement une partie du problème. Sa résolution d’identité rapproche les profils sources en une identité unifiée et garde les liens vers les enregistrements sources (Data 360 Architecture (opens in a new tab), en anglais). Cela le rapproche le plus d’un registre. Il peut aussi afficher des valeurs réconciliées sur le profil unifié. Mais cela n’en fait pas un système centralisé de golden records qui réécrit les sources. Une vue unifiée n’est pas automatiquement un enregistrement d’entreprise maîtrisé. Le module 4 porte entièrement sur cette différence.
Un modèle commun n’est pas une vérité commune
Section intitulée « Un modèle commun n’est pas une vérité commune »Vous entendrez aussi parler de modèle de données canonique. Le compte de Salesforce, le partenaire commercial de l’ERP et le client de la facturation correspondent tous à un concept d’entreprise convenu, Client, avec des identifiants et des attributs convenus, pour que chaque intégration n’ait pas à comprendre la forme de chaque autre système. Le modèle de données de Data 360 est un exemple d’harmonisation de sources en concepts communs. Mais un modèle canonique répond à comment représenter cela de façon cohérente ? Le MDM répond à comment l’identifier, le gouverner et le maîtriser à travers les systèmes ? Faites correspondre parfaitement les trois systèmes à une même forme Client, et Salesforce dit toujours 123 Main Street pendant que l’ERP dit 125. Vous avez résolu la structure, pas l’autorité. Harmoniser et maîtriser ne sont pas interchangeables.
Une entreprise, plusieurs modèles
Section intitulée « Une entreprise, plusieurs modèles »Alors « Steve Trucking a besoin de MDM » n’est pas une exigence. Pour quoi ? Les partenaires distributeurs, les centres de distribution, les équipes, les camions, les destinataires sont des domaines différents avec des autorités différentes : les partenaires distributeurs gouvernés dans Salesforce et l’ERP financier, l’identité des camions venant de FleetLink, chaque destinataire fourni par un partenaire pour chaque livraison. Des domaines différents peuvent suivre des modèles différents, et au sein d’un domaine, les attributs peuvent avoir des autorités différentes. Alors ne dessinez pas une boîte étiquetée MDM au milieu du diagramme en considérant le problème résolu. Demandez ce que fait la boîte.
Le style change aussi l’intégration. Le registre a besoin de liens d’identité ; la consolidation, de flux entrants fiables ; la coexistence, de données dans les deux sens ; le centralisé, d’une distribution depuis le maître plus des contrôles qui empêchent les autres systèmes de créer une vérité concurrente. À mesure que l’autorité grandit, la coordination grandit aussi, et la gestion des échecs avec : que se passe-t-il si le MDM change la raison sociale et que l’ERP la rejette ? C’est pourquoi la coexistence et le centralisé ne sont pas « un registre avec plus de fonctionnalités ». Ils portent des responsabilités opérationnelles différentes.
Le MDM est une décision métier
Section intitulée « Le MDM est une décision métier »Le point le plus important : le MDM n’est pas fondamentalement une décision technologique. C’est une décision sur l’autorité. Qui crée le client, qui peut le modifier, qui décide quelle valeur l’emporte, quels systèmes doivent l’accepter, ce qui se passe quand ils ne sont pas d’accord. Un outil peut mettre en œuvre ces décisions ; il ne peut pas faire que l’organisation s’accorde sur elles. C’est pourquoi un projet MDM peut avoir une excellente technologie et échouer quand même : l’équipe technique a résolu le rapprochement, et le métier n’a jamais résolu la propriété.
La leçon générale que j’ai apprise à la dure : quand plusieurs systèmes maîtrisent les mêmes données, Salesforce ne peut pas réconcilier ce sur quoi ils ne sont pas d’accord. Quand une entreprise fait tourner deux ERP, je demande comment elle les garde synchronisés. Si elle n’y arrive pas, Salesforce n’y arrivera pas non plus. Le module 5 raconte cette histoire (Un client, deux ERP).
Ce qu’un architecte décide ici
Section intitulée « Ce qu’un architecte décide ici »- Si le problème a besoin de liens d’identité, de données combinées, de valeurs maîtrisées renvoyées, ou d’une création centrale.
- Quel modèle convient à chaque domaine de données, plutôt qu’un seul modèle pour toute l’entreprise.
- Quelle autorité reçoit la couche de maîtrise, et quels systèmes doivent accepter ses décisions.
- Si un modèle canonique est nécessaire, sans confondre harmonisation et autorité.
- Comment le modèle choisi change le sens de l’intégration, la propriété et la gestion des échecs.
Quand quelqu’un place une boîte MDM sur un diagramme, demandez ce qu’elle fait. Sait-elle quels enregistrements vont ensemble ? Combine-t-elle leurs données ? Décide-t-elle quelles valeurs l’emportent ? Renvoie-t-elle ces décisions ? Crée-t-elle les données au départ ? Les réponses vous disent quelle architecture vous avez réellement, et où vit l’autorité.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Salesforce Architects, Data 360 Architecture (opens in a new tab) (en anglais), consulté le 2026-10-14.