Master Data Management, lessons learned : un outil de MDM dédié est-il indispensable ?
Les composantes du MDM ayant été introduites dans un précédent article de blog, à partir d’enquêtes auprès d’entreprises (voir références ci-dessous), nous en évoquons ici les points d’attention. Un outil de MDM dédié est-il indispensable ?
Nous ne revenons pas sur les “bonnes pratiques” évoquées dans le précédent article de blog qui doivent être prises en compte afin d’obtenir des “AI Ready Data“. Nous rappelons toutefois dans un premier temps quelques points importants relatifs au Master Data Management. Dans un second temps, nous passons en revue les différents “éléments critiques” relatifs à la mise en place d’un MDM, pour conclure sur quelques pistes.
MDM : les points importants
Le “Master data management” (MDM) est une discipline “business” dont la mise en production repose sur une technologie (choix d’une architecture de MDM, d’un outil de MDM) où des ensembles de données liées sémantiquement entre elles sont transmises entre bases de données pour des besoins applicatifs.
L’approche repose sur une gouvernance des données pour éviter les silos de data isolées. Un “data catalog” (ou système de méta-information) est également indispensable. Il en assure la définition complète et à jour (via un worklow de validation IT et business, une gestion des versions avec génération de deltas entre versions de méta-données et des contre-parties applicatives). Dans notre secteur, les raisons légales du maintien de versions entre méta-données tiennent à la durée de prescription, période durant laquelle les données et métadonnées doivent être conservées, en cas de procès et de dossiers encore ouverts. Cette durée peut varier dans le domaine de la sécurité sociale entre 5 à 30 ans, voir plus.
Une approche “data quality” en amont et en aval de l’architecture d’échange est également indispensable afin d’assurer la qualité des bases de données “sources”, mais aussi pour identifier les “golden records” validés par le business. Les “golden records” seront échangés de façon à assurer la traçabilité des Master Data (“data lineage”) entre bases de données. La figure suivante illustre l’application de règles (établies par le business) afin d’identifier un golden record par type de clusters de présomptions de duplicats (identifiés via une procédure de “matching“).
Sur cette base, il est possible d’appliquer ces règles en quelques heures sur des millions de records représentant des sous-ensembles de duplicats présumés, via une gestion de la performance (on conserve toujours l’historique des records “non retenus” au cas où les propriétaires de la base de données souhaiteraient adapter les règles a posteriori). La figure suivante montre un exemple d’établissement d’un “golden record” via le “data quality tool” Trillium.
Ensuite, les données doivent être transférées via une architecture de MDM (voir figure suivante), à choisir. Nous en avons identifié les avantages et inconvénients dans notre précédent article de blog. Ces derniers seront complétés dans la partie relative aux points d’attention.
Mise en place du MDM : points d’attention
Les interviews reprises dans les références ci-dessous indiquent plusieurs points d’attention lors de la mise en place d’un système de MDM.
La qualité des données
Toutes les références ci-dessous sans exception insistent sur le fait qu’une approche “data quality continue” manque dans la pratique et doit être mise en place pour toutes les bases de données sources, avant l’identification du golden record : profiling (audit des données), standardization (par exemple, nettoyage d’adresses) et matching (par exemple, déduplication).
L’intégration des données
À part l’architecture de type “répertoire virtuel”, toutes les autres demandent une intégration des données. Dans le secteur privé des multinationales (4), la centralisation est souvent choisie et imposée. Cette approche n’est pas viable dans le cadre de l’e-government pour des raisons de sécurité et de vie privée, vu la sensibilité des données gérées.
On trouve toutefois dans ce domaine des applications spécifiques sécurisées nécessitant une intégration des données, par exemple, le SumEHR (Summarized Electronic Health Record ou “dossier du patient”) dont voici une présentation schématique (JC Trigaux, 2009) avec l’échange de golden records et la génération d’un identifiant unique au sein de l’application SumEHR.
Mais en 2025, un message adressé aux médecins indique que la qualité des données n’est pas toujours au rendez-vous.
Les outils de MDM
À cela s’ajoutent, selon les références citées ci-dessous, lorsque l’on utilise un outil de MDM avec intégration des données (ce que proposent la plupart de ces outils), des problèmes potentiels de synchronisation, certaines données étant transférées en batch, d’autres en continu. Des questions de standardisation hétérogènes peuvent également se présenter, constituant un obstacle à la traçabilité des données. Les outils de MDM présentent aussi parfois une certaine lenteur d’intégration ainsi qu’un coût important (certains facturent leur outil par “golden record” intégré). Certains d’entre eux sont opaques quant à l’identification du “golden record”. Par ailleurs, une fois les données intégrées, l’utilisateur n’a plus nécessairement de prise sur celles-ci.
Le recours au cloud (privé la plupart du temps : Microsoft Azure, Google Cloud, Amazon Web, …) offre des solutions moins chères qu’un développement on-prem, mais est-ce une approche viable dans le cadre de l’e-government ?
https://www.socialsecurity.be/lambda/portail/glossaires/dmfa.nsf/web/gl… quelques outils de MDM parmi les plus connus : Profisee, Pilog Group, Semarchy, … Certains d’entre eux font partie de firmes ayant cumulé sous forme de “suite” les acquisitions de logiciels divers (data catalog tools, data quality tools, MDM tools, …), qui ne sont pas nécessairement compatibles entre eux : Informatica, par exemple. Il existe également des outils de MDM open source (avec cloud ou on-prem), incluant certains modules payants, comme Altrocore, par exemple. Mais par rapport au volume des bases de données gérées au sein de l’e-government en Belgique, ces derniers peuvent poser des questions de “passage à l’échelle”. Dans tous les cas, en cas d’acquisition d’un outil de MDM, il faut préalablement avoir mis en place une data governance et une organisation, des rôles associés, effectué un test sur un PoC représentatif et prévoir un planning.
Une solution “in house” ? Un exemple dans le domaine de la sécurité sociale
A côté des solutions du marché, une solution “in house” pourrait-elle être envisagée ? Nous en présentons un exemple dans le domaine de la sécurité sociale. Dans le cadre d’une architecture de type “répertoire virtuel” assurant un échange sécurisé des données avec gestion des accès, à l’instar de la banque carrefour de la sécurité sociale, nous disposons d’un “data catalog”, à savoir les “glossaires de la sécurité sociale”, dont voici un exemple s’agissant de la DmfA (Déclaration multifonctionnelle – multifunctionele Aangifte) documentant les données échangées avec gestion des versions de méta-données, worfkow de validation, gestion du multilinguisme. Ces derniers assurent également la mise à jour des applicatifs liés aux bases de données concernées avec validation IT et business pour chacune d’entre elles. Ce système de méta-information contribue actuellement au prélèvement et à la redistribution annuels de 95 milliards d’euros de cotisations et prestations sociales. Ce data catalog est en cours de lente migration vers des “glossaires egov 3.0“. Enfin, le centre de compétence “data quality” dont dispose Smals permettrait de gérer la qualité des bases de données sources ainsi que les golden records échangés entre institutions.
Conclusion provisoire
Une solution “in house”, telle que présentée ci-dessus, demanderait certainement des adaptations par rapport à l’existant. Son caractère réaliste et généralisable devrait être examiné. Mais il s’agit peut-être d’une piste à envisager à côté des “outils de MDM” commerciaux, si un Master Data Management doit être mis en place dans notre environnement.
En effet les outils commerciaux, même si certains d’entre eux couvrent pour une petite part de marché le secteur public, comme Semarchy (1), s’adressent surtout aux multinationnales vendant des produits ou services, telles que Procter & Gamble (P&G), Coca-Cola, General Electric ou encore, Wal-Mart (4).
A côté de cela, il restera utile de suivre l’évolution des outils open source, évoqués plus haut, dont la maturité pourrait prendre de l’ampleur.
Références
(1) GARTNER : rapports (2024, 2025) et en particulier Voice of the Customers for Master Data Management, Gartner, 30 juin 2025, Peer Lessons Learned for Master Data Management Solution Implementation, Gartner, août 2025.
Enquêtes auprès de clients et de fournisseurs d’outils de MDM.
(2) LEPENIOTIS P, Master data management: its importance and reasons for failed implementations. Doctoral Thesis, Sheffield Hallam University Press (UK), 2020.
Analyse du MDM dans deux entreprises commerciales anglaises (UK) : interviews, audits de données, …
(3) PANSARA R. (MDM Specialist, TESLA, USA), Master Data Management Challenges, In International Journal of Computer Science and Mobile Computing, Vol.10 Issue.10, October- 2021, p. 47-49.
(4) PANSARA R.,Strategies for Master Data Management Integration and Their Benefits, In Scholars Journal of Engineering and Technology, 2024, p. 40-47.
Recherche bibliographique, case studies, sondages et interviews dans les mulitinationales américaines suivantes : Procter & Gamble (P&G), Coca-Cola, General Electric, Wal-Mart.
(5) SMITH H. A. et al. (Queen’s School of Business, Queen’s University, Canada), Developments in Practice XXX: Master Data Management: Salvation Or Snake Oil ? In Communications of the Association for Information Systems, Volume 23, Article 4, pp. 63-72, juillet 2008.
Interviews auprès d’IT Managers de 15 organisations industrielles.
Ce post est une contribution d’Isabelle Boydens, Data Quality Expert chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals
