La réponse concise
Le Master Data Management (MDM) n'est pas un référentiel, mais un contrat. Ce contrat définit qui détermine l'entité, qui est autorisé à la modifier, comment deux enregistrements sont identifiés comme la même entité, et ce qui se passe lorsque des systèmes divergent. La technologie ne fait qu'appliquer ce qui a été convenu.
L'erreur la plus courante est de commencer par le choix de l'outil. Une organisation qui n'a pas défini ce qui constitue un "client" se retrouvera avec un outil qui consolidera précisément la même ambiguïté, mais plus rapidement et à un coût plus élevé.
Ce qui entre dans le Master et ce qui n'y entre pas
| Type de donnée | Exemple | Est une donnée Master |
|---|---|---|
| Données Master | Client, produit, fournisseur, site | Oui |
| Données de Référence | Pays, devises, codes d'activité | Gestion séparée et plus simple |
| Transactionnel | Commande, facture, Case | Non |
| Analytique | Segmentation, scoring, prévision | Non - dérivée |
Cette distinction est cruciale car chaque type de donnée requiert une gouvernance différente. Les données de référence sont gérées dans une petite table avec un seul propriétaire ; les données transactionnelles restent dans le système qui les a générées ; les données analytiques ne doivent jamais devenir une source de vérité, car elles sont le produit d'un calcul variable.
Les trois styles de mise en œuvre
Registre – Gère uniquement une table d'identifiants reliant les enregistrements entre différents systèmes. Économique, rapide, n'altère aucun système existant, et fournit une vision unifiée pour la lecture. Presque toujours approprié comme première étape.
Consolidation – Génère un Golden Record à des fins de reporting et d'analyse, sans le réinjecter dans les systèmes sources. Convient lorsque le principal problème est le reporting redondant.
Centralisé – Le Master devient la source de vérité contraignante, et les systèmes s'y approvisionnent. Offre la valeur la plus élevée, mais aussi les exigences les plus strictes en matière de gouvernance et de processus d'approbation. Les organisations qui sautent directement à cette étape découvrent qu'elles n'ont pas de Stewards pour le gérer.
L'approche pragmatique est une échelle : un registre pour une entité unique, puis une extension – basée sur la valeur prouvée et non sur un plan directeur.
Survivorship : les règles qui déterminent ce qui perdure
Le cœur du Golden Record réside dans les règles de Survivorship au niveau du champ : pour chaque champ, une source préférée est définie, ainsi qu'une règle de secours si la source préférée est vide. Parallèlement, les identifiants des systèmes sources sont toujours conservés, afin de pouvoir expliquer chaque valeur.
Un principe qui évite les débats : le Golden Record ne supprime pas les enregistrements sources et n'a pas vocation à les remplacer. C'est une surcouche qui y fait référence. Cela signifie qu'il est possible de corriger une règle et de recalculer – une capacité absente pour ceux qui ont tout fusionné lors de la phase de chargement.
Une analyse plus approfondie de la détermination de la propriété est présentée dans Source de Vérité dans l'Organisation, et le nettoyage des doublons qui le précède est détaillé dans Nettoyage des doublons Salesforce.
Stewardship : le rôle qui détermine le succès
Toute gouvernance MDM génère une file d'attente de décisions : correspondances incertaines pour le système, demandes de création de nouvelles entités et contradictions entre les sources. Si personne n'est désigné pour gérer cette file d'attente, elle s'accumulera jusqu'à ce qu'elle soit ignorée.
Portée réaliste : dans une organisation de taille moyenne, cela représente quelques heures par semaine pour une seule entité, généralement assurées par une personne du côté métier plutôt que de l’IT. C’est cet investissement qui détermine si le MDM reste actif ou devient une infrastructure silencieuse.
Cas d'usage : un fabricant avec trois systèmes et un client unique
Un fabricant industriel gérait ses clients dans trois systèmes : un ERP, Salesforce et un système de service. La même corporation apparaissait sous trois entités distinctes, et un rapport "revenus par client" était généré manuellement dans Excel chaque trimestre.
Au lieu d'un projet MDM complet, l'organisation a commencé par un Registre : une table d'identifiants a été construite dans Data 360, reliant les trois enregistrements via un numéro d'identification fiscale et une clé secondaire. Ce n'est qu'après cela qu'un Golden Record a été créé à des fins de lecture. Salesforce n'a pas modifié sa structure ; il a reçu un champ d'identifiant global et une vue "Toutes les activités du groupe".
Le résultat après un trimestre : le rapport manuel a été supprimé, et les commerciaux ont vu pour la première fois l'exposition au crédit au niveau du groupe – ce qui a incité une décision de tarification unique qui a remboursé le coût de cette phase. L'extension vers un modèle Centralisé a été envisagée uniquement après qu'il ait été prouvé qu'un Steward gérait effectivement la file d'attente.
Risques courants et mesures préventives
| Risque | Comment il se manifeste concrètement | Mesures préventives |
|---|---|---|
| Commencer par l'outil | Un référentiel unifié reflétant les ambiguïtés existantes | Définition de l'entité et de la propriété avant le choix de l'outil |
| Trop d'entités | Projet long sans valeur visible | Une entité jusqu'à la mise en production, puis extension |
| Absence de Steward | File d'attente de correspondances qui s'accumule et est ignorée | Rôle avec du temps alloué et un SLA |
| Fusion destructive | Incapacité d'expliquer ou de restaurer une valeur | Conservation des identifiants sources et recalcul |
| Centralisé trop tôt | Tous les systèmes dépendent d'une infrastructure immature | Commencer par un Registre |
Comment mesurer le succès
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Couverture | Pourcentage d'enregistrements liés à un identifiant global | Mensuel |
| Précision | Taux de liens annulés ou corrigés | Mensuel |
| File d'attente Stewardship | Éléments ouverts et temps moyen de résolution | Hebdomadaire |
| Valeur métier | Rapports manuels supprimés, décisions au niveau du groupe | Trimestriel |
La mise en place d'une gouvernance MDM échelonnée est réalisée dans le cadre des services d'intégration et de données.
Liste de contrôle avant de démarrer un projet MDM
- ☐ Jusqu'à trois entités sélectionnées pour la première phase
- ☐ Une définition métier écrite existe pour chaque entité
- ☐ Style de mise en œuvre choisi : Registry, Consolidation ou Centralisé
- ☐ Clés d'identification robustes identifiées pour chaque source
- ☐ Règles de Survivorship rédigées au niveau du champ
- ☐ Les identifiants sources sont conservés et permettent le recalcul
- ☐ Un Steward avec du temps dédié et un SLA est nommé
- ☐ Un processus d'approbation est défini pour la création de nouvelles entités
- ☐ Une mesure de valeur unique est définie pour la première phase
- ☐ Une décision existe quant au moment d'envisager un outil dédié
Ressources professionnelles
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data