Un projet MDM doit commencer par le domaine qui réunit trois conditions : une douleur visible et chiffrable, un propriétaire métier prêt à s'engager, et un périmètre que l'équipe peut traiter en quelques mois. Ce n'est pas forcément le domaine le plus stratégique : c'est celui qui permettra de démontrer la valeur du référentiel et de roder la méthode.
Une fois la décision de lancer un Master Data Management prise, la question du point de départ arrive très vite. Les clients semblent prioritaires parce qu'ils touchent le chiffre d'affaires, les produits parce qu'ils alimentent le catalogue et le site, les fournisseurs parce qu'ils concentrent les risques de paiement. Chaque direction défend son domaine avec de bons arguments.
La tentation consiste à tout traiter en parallèle pour ne froisser personne. Le projet se retrouve alors avec quatre groupes de travail, quatre jeux de règles à écrire, des dizaines d'interfaces à développer et aucun résultat visible avant longtemps. L'adhésion se perd bien avant la première livraison.
Le choix du premier domaine relève moins d'une priorité stratégique que d'une décision de séquencement. Le premier domaine doit réussir, parce que c'est lui qui donnera le droit de traiter les suivants. Il se choisit donc sur des critères de faisabilité autant que d'enjeu.
Le premier domaine d'un projet MDM n'est pas un domaine parmi d'autres. Il joue un double rôle, qui dépasse largement son périmètre : il sert de preuve auprès de la direction et de banc d'essai pour l'organisation.
Un projet de référentiel mobilise des budgets et du temps métier pendant plusieurs mois. La direction qui l'a financé attend un premier résultat tangible, et ce résultat viendra du premier domaine traité.
Si ce domaine produit un gain mesurable (moins d'incidents de livraison, moins de doublons fournisseurs, un reporting commercial enfin cohérent), le projet obtient la légitimité nécessaire pour la suite. S'il s'enlise, c'est l'ensemble de la démarche qui est remis en question, quel que soit l'intérêt des domaines suivants.
Pour que la démonstration fonctionne, plusieurs conditions doivent être réunies dès le choix du domaine :
Le premier domaine sert aussi à tout apprendre : comment écrire les règles, comment animer les ateliers, comment trancher les cas ambigus de la reprise, comment paramétrer l'outil, comment faire valider une création. Les erreurs commises à ce stade coûtent moins cher qu'elles ne coûteraient sur plusieurs domaines à la fois.
Les rôles se construisent également sur ce premier périmètre. Le Data Owner du domaine découvre ce que représente concrètement son engagement, et le Data Steward installe les routines de traitement des demandes. Ces pratiques serviront de modèle aux domaines suivants.
Le choix du premier domaine repose sur trois critères, à examiner ensemble. Un domaine qui en remplit deux sur trois présente un risque identifiable. Un domaine qui n'en remplit qu'un seul est à écarter, même s'il paraît prioritaire.
Le premier critère est l'existence d'un problème que l'organisation subit déjà et qu'elle sait décrire. Un domaine où les écarts entre outils provoquent des incidents réguliers offre un point de départ concret et un indicateur de réussite évident.
La douleur doit pouvoir se traduire en éléments observables. Plusieurs types de constats permettent de l'objectiver sans recourir à des estimations générales :
Un premier audit de qualité des données sur les domaines candidats permet de comparer ces constats de façon homogène, plutôt que de se fier à la direction qui se plaint le plus fort.
Le deuxième critère est souvent décisif. Un domaine de données de référence sans propriétaire métier ne peut pas avancer, parce que personne n'a l'autorité pour écrire et valider les règles.
L'engagement attendu dépasse le simple accord de principe. Le propriétaire doit accepter de consacrer du temps aux ateliers, de trancher les désaccords entre services, de valider les règles par écrit et de répondre de la qualité du domaine une fois le référentiel en service. Un sponsor enthousiaste mais indisponible vaut moins qu'un responsable moins visible mais présent à chaque arbitrage.
La question de la responsabilité sur la qualité des données est rarement tranchée avant le projet. Savoir qui est réellement responsable de la qualité des données aide à identifier le bon interlocuteur pour chaque domaine candidat.
Le troisième critère porte sur la taille du domaine : le nombre de sources qui créent des fiches, le nombre d'applications qui les consomment, le volume de fiches à reprendre et le nombre d'attributs à gérer.
Un domaine alimenté par deux sources et consommé par trois applications se traite beaucoup plus vite qu'un domaine présent dans une douzaine d'outils. Le périmètre n'est pas figé pour autant : il peut être réduit volontairement pour tenir dans un délai raisonnable, à condition de ne pas retirer ce qui fait la valeur du projet.
Ces trois critères agissent comme des filtres successifs. Le schéma suivant montre comment ils réduisent la liste des domaines candidats jusqu'au premier domaine retenu.
Les trois critères s'appliquent différemment selon les domaines. Chaque grande famille de données de référence présente des caractéristiques qui en font un bon ou un mauvais candidat de départ, selon le contexte de l'organisation.
Les données fournisseurs sont rarement citées en premier, et c'est pourtant un candidat solide dans beaucoup d'organisations. Le périmètre est généralement plus restreint que celui des clients, les sources sont peu nombreuses (souvent l'ERP et un outil achats) et les enjeux sont concrets.
Plusieurs caractéristiques rendent ce domaine favorable à un premier chantier, notamment pour une organisation qui découvre le MDM :
Les données clients sont le candidat le plus souvent avancé, parce qu'elles touchent directement le chiffre d'affaires et la relation commerciale. Elles sont aussi le domaine le plus complexe à traiter en premier.
La complexité vient de plusieurs facteurs qui se cumulent. Les fiches clients sont créées par de nombreux canaux (commerciaux, site web, service client, marketing), elles portent des hiérarchies parfois disputées (groupe, filiale, établissement, point de livraison) et elles mobilisent plusieurs directions qui n'ont pas la même définition d'un client.
Commencer par les clients reste possible, à condition de réduire nettement le périmètre : un seul segment (les clients professionnels, par exemple), un seul pays ou une seule activité. Sans cette réduction, le premier domaine risque de devenir un projet à part entière.
Les données produits sont un bon candidat pour les organisations qui vendent sur plusieurs canaux ou qui gèrent un catalogue étendu. Les écarts entre l'ERP, l'outil de gestion de catalogue et le site e-commerce se traduisent par des erreurs visibles : prix incohérents, descriptions incomplètes, références absentes d'un canal.
La difficulté tient au nombre d'attributs. Une fiche produit peut compter des dizaines de caractéristiques, techniques, logistiques, commerciales et réglementaires, chacune avec un responsable différent. Un premier chantier produit gagne à se concentrer sur un sous-ensemble d'attributs critiques, ceux dont l'erreur bloque une commande ou une livraison.
Les référentiels de sites (usines, entrepôts, magasins) ou d'organisations internes sont souvent plus petits et plus stables. Ils peuvent constituer un premier domaine pertinent pour tester la méthode à faible risque, mais leur faible visibilité limite l'effet de démonstration.
Les données collaborateurs posent une question différente : elles sont généralement déjà gérées dans le système RH, avec des contraintes de confidentialité fortes. Elles rejoignent un projet MDM plutôt dans un second temps, quand il s'agit de les rapprocher d'autres domaines (habilitations, rattachements organisationnels).
Le tableau suivant résume les forces et les points de vigilance de chaque domaine lorsqu'il est envisagé comme premier chantier.
Un domaine qui coche les critères de douleur et de propriétaire peut rester trop large. La réduction du périmètre permet alors de le rendre traitable, à condition de conserver ce qui fait sa valeur. Trois leviers peuvent être actionnés, seuls ou combinés.
Une fiche client ou produit compte souvent des dizaines de champs. Le référentiel n'a pas besoin de les gérer tous dès le départ. Il peut se concentrer sur les attributs dont l'erreur provoque les incidents identifiés lors de l'analyse de la douleur.
Pour sélectionner ces attributs, une série de questions simples suffit, à poser champ par champ avec le propriétaire du domaine :
Les attributs qui répondent positivement aux trois premières questions et disposent d'une définition stable forment le premier lot. Les autres attendront le deuxième.
Le deuxième levier consiste à ne traiter qu'une partie des flux. Le premier lot peut se limiter aux deux sources qui créent la majorité des fiches et aux applications où les erreurs coûtent le plus cher. Les autres sources continuent de fonctionner comme avant, en attendant d'être raccordées.
Ce choix réduit fortement le nombre d'interfaces à développer, qui est l'un des principaux postes de charge d'un projet de référentiel. Il impose en revanche de documenter clairement ce qui est couvert et ce qui ne l'est pas, pour éviter que les utilisateurs considèrent le référentiel comme complet.
Le troisième levier porte sur les fiches elles-mêmes. Reprendre l'historique complet, y compris des fiches inactives depuis des années, alourdit la reprise sans bénéfice proportionné. Le premier lot peut se limiter aux fiches actives, ou à un segment (une zone géographique, une activité, une catégorie de produits).
Une reprise limitée aux fiches réellement utilisées réduit la charge d'arbitrage manuel, souvent la partie la plus longue du projet. Les fiches anciennes peuvent être archivées ou reprises plus tard, selon des règles plus simples.
Le choix du premier domaine semble simple sur le papier. Dans la pratique, plusieurs logiques tirent la décision dans de mauvaises directions, souvent pour des raisons politiques plutôt que pour des raisons de faisabilité.
Le domaine le plus stratégique est souvent aussi le plus complexe et le plus disputé entre directions. Le choisir en premier revient à démarrer par la partie la plus difficile, avec une méthode qui n'a pas encore été éprouvée.
Ce choix se justifie seulement si un projet structurant l'impose, comme un remplacement d'ERP qui exige la reprise des clients à une date donnée. Dans les autres cas, un domaine moins exposé mais plus mûr fournit une démonstration plus sûre. La logique est la même que pour piloter des cas d'usage Data & IA : la valeur se juge aussi à la probabilité de réussite.
L'erreur inverse consiste à choisir un domaine trop facile, comme un petit référentiel de codes internes, pour être certain de réussir. Le projet livre dans les temps, mais personne n'en perçoit le bénéfice. La démonstration échoue faute d'enjeu, et le financement des domaines suivants devient difficile à obtenir.
Le domaine trop simple pose aussi un problème de méthode. Les règles de rapprochement, les circuits de validation et les arbitrages de la reprise ne sont pas réellement éprouvés, puisque les cas difficiles n'apparaissent pas. L'organisation croit disposer d'une méthode qui n'a jamais rencontré les situations qu'elle devra traiter sur les domaines suivants.
Un bon premier domaine présente une difficulté réelle mais circonscrite. Il doit permettre de tester les règles de rapprochement, la validation et la diffusion, sans cumuler toutes les complexités possibles.
Ce piège est le plus coûteux. Un domaine retenu pour son enjeu ou sa simplicité, mais sans responsable métier engagé, bloque dès les premiers ateliers. Les règles restent en discussion, les arbitrages de la reprise ne sont pas pris et l'équipe projet finit par décider seule, ce qui expose le résultat à la contestation.
Mieux vaut décaler un domaine prioritaire de quelques mois, le temps de trouver son propriétaire, que de le lancer sans arbitre. Pendant ce temps, un autre domaine qui dispose d'un responsable peut servir de premier chantier.
Le premier domaine est choisi quand plusieurs éléments sont réunis et validés. Ils forment un dossier court, que le comité de pilotage peut examiner avant d'engager l'équipe et l'outil. Ce dossier évite de découvrir en cours de route qu'une condition essentielle manquait.
Les éléments suivants constituent ce dossier de lancement, à compléter pour le domaine retenu :
Avec ce dossier, le choix du premier domaine cesse d'être un débat entre directions pour devenir une décision argumentée. Les domaines écartés savent pourquoi ils attendent et ce qui leur manque pour passer en tête de liste, ce qui prépare déjà le deuxième lot.
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
%20copie.png)
.png)
.png)