Les projets MDM s'enlisent après le cadrage pour quatre raisons principales : des règles de gestion jamais arbitrées par les métiers, une reprise de données sous-estimée, un périmètre qui s'élargit en cours de route et un référentiel sans responsable une fois en service. Ces causes relèvent de l'organisation bien plus que de la technique.
Le cadrage d'un projet de Master Data Management se passe généralement bien. Les constats sont partagés, les domaines prioritaires sont identifiés, l'outil est choisi et le budget est voté. Le comité de pilotage repart avec un planning, un périmètre et une équipe.
Quelques mois plus tard, le tableau a changé. Les ateliers de règles se succèdent sans conclusion, la reprise des données accumule du retard, de nouvelles demandes s'ajoutent au périmètre et la date de mise en service recule à chaque comité. Personne ne parle d'échec, mais plus personne ne sait dire quand le référentiel sera utilisable.
Ce glissement suit presque toujours le même enchaînement. Le cadrage traite ce qui se décide en réunion, alors que l'enlisement naît de ce qui doit se décider ensuite, cas par cas, par les métiers. Comprendre où le projet décroche permet de le relancer sans tout reprendre depuis le début.
Un projet MDM enlisé n'est pas un projet arrêté. Il continue de consommer du budget et du temps, il produit des comptes rendus et des versions de paramétrage, mais il ne livre pas de référentiel utilisé. Cette situation est plus coûteuse qu'un arrêt, parce qu'elle se prolonge sans décision.
Le cadrage d'un projet MDM produit des livrables de haut niveau : les domaines concernés, les sources, les applications cibles, le style de référentiel, l'outil retenu, le planning. Ces décisions sont nécessaires, mais elles laissent ouvertes des centaines de questions de détail qui conditionnent le fonctionnement réel du référentiel.
Quelle adresse retenir quand le CRM et l'ERP divergent ? À partir de quand un client devient-il inactif ? Qui valide la création d'un fournisseur étranger ? Ces questions ne figurent pas dans le dossier de cadrage, et c'est leur accumulation sans réponse qui ralentit le projet.
Un projet arrêté libère des ressources et permet une décision claire : reprendre plus tard, autrement, ou renoncer. Un projet enlisé continue de mobiliser l'équipe projet, les licences de l'outil et le temps des participants aux ateliers, sans produire de bénéfice.
Le coût ne se limite pas au budget. Pendant que le projet piétine, les écarts entre les outils continuent de s'accumuler, et la reprise à venir s'alourdit d'autant. Les équipes métier, sollicitées sans voir de résultat, deviennent plus difficiles à mobiliser. Plus l'enlisement dure, plus la relance demande d'efforts pour regagner la confiance des métiers.
Cette dynamique explique pourquoi l'enlisement doit être reconnu tôt. Un comité de pilotage qui accepte chaque report sans en analyser la cause entretient, sans le vouloir, la situation qu'il cherche à éviter.
L'enlisement s'installe progressivement, ce qui le rend difficile à reconnaître de l'intérieur. Plusieurs signes, observables dans le fonctionnement du projet, permettent de l'identifier avant qu'il ne devienne irréversible :
Un référentiel applique des règles. Tant que ces règles ne sont pas écrites et validées, l'outil ne peut pas être paramétré correctement, les rapprochements ne peuvent pas être lancés et la reprise ne peut pas commencer. Les règles non arbitrées sont la première cause d'enlisement, et souvent la source des suivantes.
Les ateliers de règles réunissent des représentants de plusieurs services qui découvrent que leurs pratiques diffèrent. Le commerce considère qu'un client est actif s'il a été contacté dans l'année, la finance s'il a été facturé, la logistique s'il a été livré. Chacun a raison dans son périmètre.
Un atelier n'est pas le lieu pour trancher ce type de désaccord. Les participants n'ont généralement pas l'autorité pour engager leur direction, et le débat se termine par une demande de « retour en interne » qui reporte la décision à l'atelier suivant. Sans instance d'arbitrage identifiée, ce cycle peut durer des mois.
Une instance d'arbitrage n'a pas besoin d'être lourde. Elle peut prendre la forme d'un point mensuel du comité de pilotage consacré aux questions ouvertes, préparé par l'équipe projet. Chaque question y arrive avec les options possibles, leurs conséquences et une recommandation, ce qui permet de trancher en quelques minutes ce qui était débattu depuis plusieurs ateliers.
Pour ne pas perdre de temps, l'équipe technique commence souvent à paramétrer l'outil sur la base d'hypothèses. C'est une décision compréhensible, mais elle crée une dette : chaque règle finalement arbitrée différemment oblige à reprendre le paramétrage, les tests et parfois la reprise déjà effectuée.
Les règles qui bloquent le paramétrage relèvent de quelques familles bien identifiées. Ce sont elles qu'il faut faire arbitrer en priorité, avant tout le reste :
Les autres règles (formats d'affichage, contrôles secondaires, enrichissements) peuvent attendre un deuxième lot. Savoir distinguer les règles de gouvernance des données réellement utiles des règles accessoires évite d'alourdir les ateliers.
La reprise consiste à extraire les fiches des différentes sources, à les rapprocher, à arbitrer les cas douteux et à charger le résultat dans le référentiel. Elle est planifiée au cadrage comme une tâche technique. Elle se révèle, en cours de projet, comme un travail largement métier.
Les outils de MDM proposent des algorithmes de rapprochement qui comparent les noms, les adresses et les identifiants. Ils traitent efficacement les doublons évidents. Ils produisent aussi une zone grise de correspondances probables, que seule une personne connaissant le métier peut confirmer ou infirmer.
Cette zone grise est le point où la reprise ralentit. Deux entreprises au nom proche dans la même ville sont-elles des homonymes ou la même entité après un changement de raison sociale ? Deux références produits aux libellés différents désignent-elles le même article dans deux conditionnements ? Chaque cas douteux demande quelques minutes, et ces minutes multipliées par plusieurs milliers de fiches représentent des semaines de travail.
Ce travail s'apparente aux étapes classiques de fiabilisation des données. Les étapes de nettoyage, de normalisation et d'enrichissement s'appliquent à la reprise d'un référentiel, avec une contrainte supplémentaire : chaque décision devient la référence pour toutes les applications.
Les personnes capables d'arbitrer les cas douteux sont celles qui connaissent les clients, les produits ou les fournisseurs : des commerciaux, des acheteurs, des gestionnaires de catalogue. Elles ont un emploi du temps déjà rempli, et la reprise n'y figurait pas.
Le projet attend alors leurs retours, relance, attend encore. L'équipe technique, pour avancer, finit par charger les cas douteux avec une règle par défaut, ce qui introduit des erreurs dans un référentiel censé les supprimer. La migration de données d'un nouvel ERP rencontre exactement la même difficulté, pour les mêmes raisons.
Un projet de référentiel attire les demandes. Dès que les directions comprennent qu'un outil va centraliser les données de référence, chacune y voit l'occasion de régler ses propres difficultés. Le périmètre initial grossit, souvent sans que le planning ni le budget ne soient revus.
L'élargissement prend plusieurs formes, qui ont chacune une justification métier recevable prise isolément. C'est leur accumulation qui pèse sur le projet :
Chaque ajout semble modeste. Ensemble, ils transforment un premier lot conçu pour démontrer la valeur du référentiel en un programme dont la fin recule à chaque comité.
L'élargissement n'est pas un problème en soi. Il le devient quand aucune règle ne permet de décider si une demande entre dans le lot en cours ou attend le suivant. Faute de règle, l'équipe projet accepte pour ne pas bloquer, et le comité de pilotage découvre l'effet cumulé trop tard.
Un projet qui tient son périmètre dispose d'un principe simple : toute nouvelle demande est inscrite dans une liste d'attente et examinée en comité, avec son impact sur le planning. Seules les demandes indispensables au fonctionnement du premier lot y entrent. Les autres alimentent les lots suivants.
Certains projets MDM atteignent la mise en service, puis s'enlisent autrement. Le référentiel fonctionne techniquement, mais les demandes de création s'accumulent, les anomalies ne sont pas traitées et les utilisateurs recommencent à créer des fiches dans leurs outils habituels. Quelques mois plus tard, les écarts sont revenus.
Le dossier de cadrage prévoit généralement des Data Stewards pour traiter les demandes et un Master Data Manager pour piloter l'ensemble. Ces rôles sont souvent attribués à des personnes déjà occupées à plein temps, sans que leur charge soit réduite ailleurs.
Le résultat est prévisible. Les demandes de création attendent plusieurs jours, les utilisateurs pressés contournent le circuit et le référentiel perd sa fonction. Le problème n'est pas l'outil, ni même les règles : c'est le temps disponible pour les appliquer.
Le deuxième point faible de l'exploitation est le retour des erreurs. Un utilisateur qui constate une adresse fausse dans l'ERP la corrige souvent directement dans l'ERP, parce que c'est l'outil qu'il connaît. Si cette correction n'est pas faite dans le référentiel, elle sera écrasée à la prochaine synchronisation, ou elle créera un nouvel écart.
Un circuit de correction efficace répond à trois questions, à communiquer clairement à tous les utilisateurs :
Les quatre causes décrites interviennent à des moments différents de la vie du projet. Le schéma suivant les replace dans l'ordre où elles apparaissent, ce qui permet d'anticiper chacune au bon moment.
Un projet MDM enlisé peut être relancé sans tout reprendre depuis le cadrage. La relance consiste à réduire le périmètre au minimum utile, à replacer les décisions au bon niveau et à fixer une échéance au-delà de laquelle le projet sera réorienté ou arrêté.
La première mesure consiste à resserrer. Le projet revient à un seul domaine, celui où les règles sont les plus avancées et où le propriétaire métier est le plus engagé, et à un premier lot réduit (quelques attributs, deux sources, les applications où les erreurs coûtent le plus cher).
Ce resserrement est souvent mal vécu par les directions dont le besoin sort du lot. Il est pourtant la condition pour livrer un premier résultat, et donc pour obtenir les moyens de traiter les besoins suivants. Les principes qui permettent d'éviter que la gouvernance des données devienne une usine à gaz s'appliquent directement à cette étape.
La deuxième mesure consiste à lister toutes les questions en suspens, à les classer par domaine et à les soumettre aux propriétaires concernés avec une date de réponse. Les désaccords entre directions remontent au comité de pilotage, qui les tranche en séance.
Cette remise à plat produit souvent un effet immédiat. Des questions débattues depuis des mois en atelier trouvent une réponse en quelques jours, dès qu'une personne disposant de l'autorité nécessaire est sollicitée directement. Un glossaire métier partagé permet ensuite de conserver ces définitions et d'éviter qu'elles soient rediscutées.
La troisième mesure est la plus difficile : fixer une date à laquelle le comité décidera, sur des critères connus à l'avance, de poursuivre, de réorienter ou d'arrêter le projet. Sans cette échéance, la relance risque de devenir un nouveau cycle d'enlisement.
Les critères de cette décision doivent être simples et mesurables. Ils reprennent les objectifs du premier lot : nombre de fiches reprises et validées, délai de traitement des demandes de création, baisse des incidents ciblés. La démarche est la même que pour tout cas d'usage data dont il faut décider s'il faut l'arrêter ou le réorienter : une décision prise à date fixe vaut mieux qu'une prolongation par défaut.
Une relance qui reste confinée au comité de pilotage a peu de chances de produire ses effets. Les équipes métier sollicitées depuis des mois ont besoin de savoir ce qui change, ce qu'on attend d'elles et quand elles verront un premier résultat.
Une communication courte suffit, à condition d'être précise. Elle annonce le domaine et le périmètre retenus pour le premier lot, les demandes reportées et leur calendrier indicatif, les personnes qui arbitrent les questions ouvertes et la date à laquelle le comité fera le point. Une relance annoncée avec un périmètre réduit et une date précise est plus crédible qu'une promesse de couvrir tous les besoins.
Cette communication engage aussi le comité. Une fois la date de décision annoncée, la reporter sans explication reviendrait à reproduire le glissement de planning qui caractérisait l'enlisement.
Le tableau suivant relie chaque symptôme observé à sa cause probable et à l'action de relance correspondante.
| Symptôme observé | Cause probable | Action de relance |
|---|---|---|
| Ateliers de règles qui se répètent sans conclusion | Désaccords entre directions sans instance d'arbitrage | Faire trancher par le propriétaire du domaine ou le comité de pilotage, avec une date de réponse |
| Paramétrage repris à plusieurs reprises | Outil configuré sur des hypothèses non validées | Geler le paramétrage tant que les règles d'identification et de survie ne sont pas arbitrées |
| Reprise qui accumule du retard | Cas douteux sans personne disponible pour les arbitrer | Estimer la charge sur un échantillon et réserver le temps des équipes métier |
| Date de mise en service qui recule à chaque comité | Périmètre élargi sans règle d'acceptation | Revenir à un seul domaine et un seul lot, inscrire les autres demandes en liste d'attente |
| Écarts revenus après la mise en service | Rôles d'exploitation non pourvus et absence de circuit de correction | Libérer du temps pour les Data Stewards et communiquer un canal unique de signalement |
Un projet MDM enlisé n'est pas condamné. Il signale presque toujours une décision qui n'a pas été prise au bon niveau, ou un temps métier qui n'a pas été réservé. Une fois ces deux points corrigés, le référentiel peut redémarrer sur un périmètre réduit, avec des règles validées et des responsables qui disposent du temps nécessaire pour les faire appliquer.
Un projet MDM prend du retard après le cadrage parce que les décisions de détail, indispensables au fonctionnement du référentiel, n'ont pas été prises. Le cadrage fixe les grandes orientations, mais laisse ouvertes de nombreuses questions qui relèvent des métiers.
Plusieurs symptômes permettent de repérer un projet MDM qui s'enlise, avant que la situation ne devienne difficile à corriger. Ils portent sur le fonctionnement du projet plutôt que sur l'outil.
Les règles de gestion d'un projet MDM doivent être arbitrées par le propriétaire métier du domaine concerné. Quand un désaccord oppose plusieurs directions, la décision remonte au comité de pilotage du projet.
La reprise de données d'un MDM est longue parce que le rapprochement automatique ne traite que les cas évidents. Les correspondances probables demandent un examen humain par des personnes qui connaissent le métier, et ces personnes sont rarement disponibles.
Un projet MDM enlisé se relance en réduisant le périmètre, en replaçant les décisions au bon niveau et en fixant une échéance de décision. Il n'est généralement pas nécessaire de reprendre le cadrage depuis le début.
Un référentiel MDM se dégrade après sa mise en service quand les rôles d'exploitation ne disposent pas du temps nécessaire et qu'aucun circuit de correction n'est en place. Les utilisateurs contournent alors le référentiel et les écarts réapparaissent.
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
%20copie.png)
.png)
.png)
.png)