De componenten van het MDM werden geïntroduceerd in een vorig blogartikel, en op basis van enquêtes bij bedrijven (zie referenties hieronder) bespreken we hier de aandachtspunten ervan. Is een dedicated MDM-tool noodzakelijk?

We komen niet terug op de ‘best practices’ die in het vorige blogartikel werden genoemd en waarmee rekening moet worden gehouden om ‘AI Ready Data’ te verkrijgen. We herhalen wel eerst enkele belangrijke punten over Master Data Management. Vervolgens bespreken we de verschillende ‘kritieke elementen’ met betrekking tot de implementatie van een MDM, om af te sluiten met enkele suggesties.

MDM: de key points

‘Master Data Management’ (MDM) is een ‘business’-discipline waarvan de implementatie gebaseerd is op een technologie (keuze van een MDM-architectuur, een MDM-tool) waarbij semantisch met elkaar verbonden datasets tussen databases worden uitgewisseld voor toepassingsdoeleinden.

De aanpak is gebaseerd op data governance om geïsoleerde gegevenssilo’s te voorkomen. Een ‘data catalog’ (of meta-informatiesysteem) is ook onmisbaar. Deze zorgt voor een volledige en actuele definitie van de data (via een IT en business validation workflow, versiebeheer met het genereren van delta’s tussen versies van metagegevens en de overeenkomstige applicaties). In onze sector hebben de wettelijke redenen voor het bijhouden van versies tussen metagegevens te maken met de verjaringstermijn, de periode waarin de gegevens en metagegevens moeten worden bewaard in geval van rechtszaken en nog lopende dossiers. Deze termijn kan in de sociale zekerheid variëren van 5 tot 30 jaar, of zelfs meer. 

Een ‘data quality’-aanpak stroomopwaarts en stroomafwaarts van de uitwisselingsarchitectuur is eveneens essentieel om de kwaliteit van de ‘brondatabases’ te waarborgen, maar ook om de door de business gevalideerde ‘golden records’ te identificeren. De ‘golden records’ worden uitgewisseld om de traceerbaarheid van de Master Data (‘data lineage’) tussen databases te garanderen. De volgende figuur illustreert de toepassing van regels (vastgesteld door de business) om een golden record te identificeren per type cluster van vermoedelijke duplicaten (geïdentificeerd via een ‘matching’-procedure).

Op basis hiervan is het mogelijk om deze regels binnen enkele uren toe te passen op miljoenen records die vermoedelijke duplicaten bevatten, via performance management (de geschiedenis van de ‘niet-geselecteerde’ records wordt altijd bewaard voor het geval de eigenaars van de database de regels achteraf willen aanpassen). De volgende afbeelding toont een voorbeeld van het opstellen van een ‘golden record’ via de ‘data quality tool’ Trillium. 

Vervolgens moeten de gegevens worden overgedragen via een te bepalen MDM-architectuur (zie volgende afbeelding). We hebben de voor- en nadelen hiervan geïdentificeerd in ons vorig blogartikel. Deze zullen worden aangevuld in het deel over aandachtspunten.

Invoering van MDM: aandachtspunten

De interviews in de onderstaande referenties wijzen op verschillende aandachtspunten bij het opzetten van een MDM-systeem. 

De kwaliteit van de gegevens

Alle onderstaande referenties benadrukken zonder uitzondering dat een ‘continue data quality’-aanpak in de praktijk ontbreekt en moet worden geïmplementeerd voor alle brondatabases, voordat het ‘golden record’ wordt geïdentificeerd: profilering (data audit), standaardisatie (bijvoorbeeld het opschonen van adressen) en matching (bijvoorbeeld deduplicatie). 

Integratie van de gegevens

Behalve de architectuur van het type ‘virtual directory’ vereisen alle andere architecturen een integratie van de gegevens. In de privésector van multinationals (4) wordt vaak gekozen voor centralisatie en wordt deze ook opgelegd. Deze aanpak is door veiligheid en privacy niet haalbaar in het kader van e-government, gezien de gevoeligheid van de beheerde gegevens.

Er zijn echter specifieke beveiligde toepassingen op dit gebied die gegevensintegratie vereisen, bijvoorbeeld het SumEHR (Summarized Electronic Health Record of ‘patiëntendossier’), waarvan hier een schematische weergave wordt gegeven (JC Trigaux, 2009) met de uitwisseling van ‘golden records’ en het genereren van een unieke identificatiecode binnen de SumEHR-toepassing.

Maar in 2025 blijkt uit een bericht aan artsen dat de kwaliteit van de gegevens niet altijd optimaal is. 

MDM-tools

Daarnaast zijn er volgens de hieronder genoemde referenties, wanneer een MDM-tool met gegevensintegratie wordt gebruikt (wat de meeste van deze tools bieden), mogelijke synchronisatieproblemen, omdat sommige gegevens in batches worden overgedragen en andere continu. Er kunnen ook heterogene standaardisatiekwesties aan de orde komen  die een belemmering vormen voor de traceerbaarheid van gegevens. MDM-tools worden soms ook traag geïntegreerd en brengen hoge kosten met zich mee (sommige tools worden gefactureerd per geïntegreerde ‘golden record’). Sommige tools zijn ondoorzichtig wat betreft de identificatie van het ‘golden record’. Bovendien heeft de gebruiker, zodra de gegevens zijn geïntegreerd, niet noodzakelijkerwijs nog controle over deze gegevens. 

Het gebruik van de cloud (meestal privé: Microsoft Azure, Google Cloud, Amazon Web, enz.) biedt goedkopere oplossingen dan een on-prem-ontwikkeling, maar is dit een haalbare aanpak in het kader van e-government?

Enkele van de bekendste MDM-tools zijn: Profisee, Pilog Group, Semarchy, … Sommige daarvan maken deel uit van bedrijven die verschillende softwareprogramma’s (data catalog tools, data quality tools, MDM tools, …) hebben verzameld in de vorm van een ‘suite’, die niet noodzakelijkerwijs onderling compatibel zijn: Informatica bijvoorbeeld. Er bestaan ook open source MDM-tools (met cloud of on-prem), waaronder bepaalde betaalde modules, zoals bijvoorbeeld Altrocore. Maar gezien de omvang van de databases die binnen de e-government in België worden beheerd, kunnen deze tools vragen oproepen over de ‘schaalbaarheid’.  In elk geval moet bij de aanschaf van een MDM-tool eerst een data governance en een organisatie met bijbehorende rollen worden opgezet, een test op een representatieve PoC worden uitgevoerd en een planning worden opgesteld.

Een ‘in house’ oplossing? Een voorbeeld op het gebied van sociale zekerheid

Zou naast de oplossingen die op de markt beschikbaar zijn, ook een ‘in house’ oplossing overwogen kunnen worden? We geven hier een voorbeeld uit het domein van de sociale zekerheid. In het kader van een architectuur van het type ‘virtual directory’, die een beveiligde gegevensuitwisseling met toegangsbeheer via de directory garandeert, naar het voorbeeld van de kruispuntbank van de sociale zekerheid, beschikken we over een ‘data catalog’, namelijk de ‘glossaria van de sociale zekerheid’, waarvan hier een voorbeeld is met betrekking tot de DmfA (Déclaration Multifonctionnelle – Multifunctionele Aangifte).  De data catalog oplossing voorziet in een documentatie van de uitgewisselde gegevens, inclusief versiebeheer van metadata, een validatieworkflow en beheer van meertaligheid. Deze mechanismen zorgen ook voor de actualisering van de toepassingen die verband houden met de betreffende databases, met IT- en businessvalidatie voor elk van deze databases. Dit meta-informatiesysteem draagt momenteel bij aan de jaarlijkse inning en herverdeling van 95 miljard euro aan sociale bijdragen en uitkeringen. Deze data catalog wordt momenteel langzaam gemigreerd naar de ‘glossaria egov 3.0’. Ten slotte zou het competentiecentrum ‘data quality’ van Smals het mogelijk maken om de kwaliteit van de brondatabanken en de tussen instellingen uitgewisselde ‘golden records’ te beheren.

Voorlopige conclusie

Een ‘in house’ oplossing, zoals hierboven beschreven, zou zeker aanpassingen ten opzichte van het bestaande systeem vereisen. De haalbaarheid en algemene toepasbaarheid ervan zouden moeten worden onderzocht. Maar het is misschien een optie om te overwegen naast de commerciële “MDM-tools” als er in onze omgeving een Master Data Management moet worden geïmplementeerd.

Commerciële tools, ook al dekken sommige een klein deel van de publieke sector af – zoals Semarchy (1) – richten zich vooral op multinationals die producten of diensten verkopen, zoals Procter & Gamble (P&G), Coca-Cola, General Electric of Wal-Mart (4). 

Daarnaast blijft het nuttig om de ontwikkeling van de hierboven genoemde open source-tools te blijven volgen, waarvan de volwassenheid nog zou kunnen toenemen. 

Referenties

(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.

Interviews bij klanten en leveranciers van MDM-tools

(2) LEPENIOTIS P, Master data management: its importance and reasons for failed implementations. Doctoral Thesis, Sheffield Hallam University Press (UK), 2020.

Analyse van MDM in twee Engelse handelsondernemingen (VK): interviews, gegevensaudits, enz.

(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.

Bibliografische opzoeking, case study’s, peilingen en interviews in de volgende Amerikaanse multinationals: 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 bij IT Managers van 15 industriële organisaties

Deze blogpost werd geschreven door Isabelle Boydens, Data Quality Expert bij Smals Research. Dit artikel is geschreven onder haar eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

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 applications correspondantes). 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 ?

Citons 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 via l’annuaire 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

In dit artikel illustreren we de problematiek waarop Master Data Management (MDM) een antwoord biedt. Vervolgens definiëren we deze tak van de informatica aan de hand van voorbeelden en tonen we de verbanden met data governance en datamanagement. We stellen ook een implementatiemethode voor, evenals de bijbehorende architecturen met hun voor- en nadelen. 

De probleemstelling

Master Data Management heeft als doel twee soorten problemen op te lossen.

Enerzijds kunnen bepaalde gegevens verspreid, gedupliceerd en heterogeen zijn in verschillende semantisch met elkaar verbonden toepassingen en databases (DB’s).

Anderzijds kunnen gegevens tussen verschillende DB’s verschillen (bijvoorbeeld wat betreft het formaat of het definitiedomain) of in een verschillend tempo evolueren. Dit kan leiden tot ernstige bedrijfsproblemen. Zo vormen een gebrek aan traceerbaarheid tussen onderling afhankelijke databases of een gebrek aan “AI-ready” gegevens, een belemmering voor de efficiënte implementatie van AI-projecten, die momenteel in opkomst zijn.

Master Data Management is dus een vakgebied dat zich richt op het elimineren van inconsistenties en operationele storingen en het verbeteren van de kwaliteit van de gegevens en de dienstverlening.

Definitie en voorbeelden

Master Data Management is meer een vakgebied dan een softwareprogramma en is gebaseerd op data governance en datamanagement. 

Bij data governance legt het management van een instelling verschillende zaken vast. Een verantwoordingskader op hoog niveau moet de voorwaarden voor het beheer van masterdata vastleggen (“policy settings”). Deze masterdata zijn van fundamenteel belang voor het bedrijf (bijvoorbeeld het adres van de werkgever of het bedrijf) en worden gedeeld tussen verschillende databases. Daartoe moeten rollen worden vastgesteld op verschillende niveaus: business- en technisch beheer van MDM, van het meta-informatiesysteem, van de datakwaliteit, van de architectuur, enz. Ten slotte wordt een passende organisatie opgezet voor de evaluatie, creatie, consumptie en controle van de data.

Op basis van de policy settings maakt datamanagement het mogelijk om op iteratieve en incrementele wijze masterdata te identificeren, definiëren en modelleren via een eerste case study die door de betrokken business wordt gevalideerd, met het oog op een bredere aanpak die drie gelijktijdige assen omvat.

In de eerste plaats moet een meta-informatiesysteem of transversale woordenlijst (“glossarium”) met data met een hoge toegevoegde waarde (“Data Catalog”) worden opgezet, een onderwerp waarover we in maart 2025 een blogartikel in het Frans en het Nederlands hebben gepubliceerd (6). De Data Catalog kan ook data beheren die niet tussen databases wordt gedeeld en waarvan de documentatie belangrijk is.

Ten tweede moet een aanpak worden geïmplementeerd die gericht is op de kwaliteit van de data (6, 7, 8, 9, 10, 11). Deze omvat twee soorten methoden. Correctieve methoden (9), via datakwaliteitsinstrumenten (Batch en Rest API in de ReUse-catalogus), maken het mogelijk om problemen (afwijkingen, vermoedelijke dubbele vermeldingen, te verwijderen adressen, enz.) aan te pakken wanneer deze zich al in de databases voordoen. Preventieve methoden (7, 8, 11) maken het mogelijk om het ontstaan van afwijkingen te voorkomen door de oorzaak (of oorzaken) ervan op te sporen tussen instellingen en verzenders in de informatiestromen (bijvoorbeeld problemen met de interpretatie van de wet, het ontstaan van een nieuw concept (virusmutaties, …), inconsistente definities, bugs, …) en deze structureel aan de bron te verwijderen, zodat ze niet meer/niet in de data voorkomen (in de toekomst, zie ReUse-catalogus).

Onderstaande figuur illustreert op schematische wijze de twee methoden, die op elkaar kunnen inwerken.

Ten derde zorgt een Master Datamanagement-systeem voor de keuze van een integratie tussen de betreffende databases en de datacatalogus (of meta-informatiesysteem). Er bestaan verschillende architecturen, die we later zullen bespreken.

Deze belangrijke stappen maken het mogelijk om gesynchroniseerde gegevens in verschillende projecten en toepassingen transversaal te beheren. Het doel van de MDM-aanpak is om inspanningen te bundelen en de synchronisatie, kwaliteit, uitwisseling en controle van data tussen de verschillende silo’s te waarborgen. En dit vrijwel in realtime of in uitgestelde modus (wanneer een goedkeuringsworkflow nodig is voor de validatie van wijzigingen en versies).

Bijvoorbeeld (2, 5): MDM maakt het mogelijk om gevallen te behandelen waarin twee verschillende termen in dezelfde betekenis worden gebruikt en moeten worden geharmoniseerd (bv. te betalen bedrag, verschuldigd bedrag) of gevallen waarin eenzelfde term verschillende betekenissen kan hebben (zo kan loon bijvoorbeeld brutoloon, basisloon, loon en salaris, of nettoloon betekenen, enz.). In onze Belgische context moet ook rekening worden gehouden met de harmonisatie tussen de termen in de verschillende gebruikte talen, wat een extra factor van complexiteit is. Er is namelijk geen noodzakelijk één-op-één verband tussen de verschillende termen in de verschillende landstalen voor een bepaald concept.

Masterdata zijn dus de kleinste samenhangende sets van identifiers en attributen die op unieke wijze de belangrijkste entiteiten van een instelling of onderneming beschrijven en worden gebruikt in verschillende conceptueel en functioneel met elkaar verbonden databases en businessprocessen.

Masterdatamanagement: implementatiemethode

Aangezien een Master Datamanagement-project in de eerste plaats een businessproject is, omvat het, voordat een IT-systeem wordt geïmplementeerd, de volgende, vaak iteratieve stappen (1, 3, 4): 

• Bepaal de omvang van het project (begin met een “bescheiden” essentieel project, dat incrementeel en iteratief kan zijn, “nice to have”)
• Een agenda (planning) voor de implementatie opstellen, een continu project (ontwerp en onderhoud) ondersteund door de hiërarchie, met inbegrip van de volgende punten:
• Accent leggen (analyse) en identificeren:
  • De gebruikers van de data, hun doelstellingen
  • De authentieke bronnen
  • De belangrijkste concepten en de masterdata (unieke identificatie, hoofdcategorieën, …). Let op: soms zijn compromissen nodig, de keuze van de masterdata is niet noodzakelijkerwijs deterministisch
  • Gebeurtenissen/processen die van invloed kunnen zijn op de masterdata (bijwerking, delen en verwijderen als gevolg van wetgevende wijzigingen of de werkelijke situatie – bijvoorbeeld: mutaties van virussen en veranderingen in medische concepten, enz.)
  • De bijbehorende organisatie (bijv. validatieworkflow)
  • Het beheer van versies van masterdata en metadata (6)
  • De kwaliteit van de data: evaluatie en verbetering (6, 7, 8, 9, 10, 11) – zie hierboven
  • Beveiliging en privacy
• Definieer KPI’s of metrics om de resultaten van de MDM-aanpak te valideren, meten en opvolgen, bijvoorbeeld:
  • Kwaliteitsbarometers DmfA: opvolging van anomalieën, financiële indicatoren (AR-KB 2017), … (11)
  • Metingen van de traceerbaarheid tussen semantisch gekoppelde databases.
• Zoals hierboven vermeld, stapsgewijs een referentiekader of glossarium van data of een meta-informatiesysteem (6) opstellen, rekening houdend met de belangrijke functionaliteiten voor een latere productie:
  • Versiebeheer (planning) van masterdata en metadata (evoluerende wetgeving, verjaringstermijn, bewijskracht, opkomst van nieuwe concepten, …)
  • Validatieworkflow
  • Meertaligheid
  • Erfenis
  • Standaard en uitwisselingsformaat (“Write Once Publish Many”)
  • Multibase en meertalig zoeken
• Een strategie voor evolutie en change management opstellen voor de overgang van de huidige situatie (“AS IS”) naar de toekomstige situatie (“TO BE”)
• Rollen en business- en IT-teams (MDM, Data Quality, Architectuur, …) opstellen
• Standaarden definiëren (aanbevolen voor analyse: (12))
• Een methode bepalen voor de integratie van de betrokken databases; via het referentiekader of glossarium voor transversale data, dat we in het volgende punt zullen bekijken: de integratiearchitecturen, met hun voor- en nadelen op het vlak van:
  • datakwaliteit (10)
  • beveiliging en privacy
  • prestaties
  •  mate van intrusiviteit in de betrokken informatiesystemen

Integratiearchitecturen tussen databases en eventueel gekoppelde Data Catalogs, met hun voor- en nadelen 

De volgende schema’s zijn aangepast uit (5) en gewijzigd in overeenstemming met de huidige oplossingen (1, 2, 3, 4)

1. Virtuele directories 

Met een virtuele directory maakt het dataregister (in het midden van het schema, in het rood) het mogelijk om, op basis van een kennisbank met toegangsrechten, data uit de brondatabases over te dragen naar de gebruikers. Er zijn overeenkomsten met de KSZ, een stellair netwerk dat de uitwisseling van data tussen instellingen mogelijk maakt. Wat de sociale zekerheid betreft, kunnen gegevensgebruikers een glossarium van de data (of “Data Catalog” in het schema) raadplegen in de verschillende versies, online op het portaal van de sociale zekerheid (6). Dit is een goede oplossing in de genoemde context.

• Voordelen: eerbiediging van de privacy, veiligheid, de brondata hoeven niet te worden gewijzigd
• Nadelen: mogelijke prestatieproblemen, de dataproducenten moeten hun Data Catalog delen, uniformiseren, in hetzelfde tempo bijwerken en toegankelijk maken voor de gebruikers.   

2. Consolidatie

Bij consolidatie worden de brondata in één keer (“one shot”) naar een gemeenschappelijke database gekopieerd. Er staat geen “Data Catalog” op het schema, omdat de gemeenschappelijke database vervolgens wordt gedesynchroniseerd van de “brondata” die zij geacht wordt te vertegenwoordigen. Deze oplossing wordt niet aanbevolen. Ze werd in het verleden in de toepassing gebracht voor het beheer van zorgpremies, maar werd later opgegeven. 

• Voordelen: eenvoudig voor data-producenten: de brondatabases hoeven niet te worden gewijzigd
• Nadelen: de brondatabases en hun Data Catalog kunnen in hun eigen tempo evolueren en de gemeenschappelijke database in een ander tempo (“ghost factory”, bron van redundantie): er doen zich problemen voor op het vlak van de kwaliteit van de ‘geconsolideerde’ data, het delen van een “gemeenschappelijke Data Catalog” heeft geen zin meer.

3. Samenwerking

Bij samenwerking delen de brondatabases de gemeenschappelijke “masterdata” in een nieuwe database en blijven ze hun niet-gemeenschappelijke data beheren. Voor gemeenschappelijke data die in één exemplaar worden beheerd (dus zonder redundantie), wordt een “Data Catalog” ter beschikking gesteld van alle datagebruikers en gezamenlijk bijgewerkt door de dataproducenten. Dit is een goede oplossing als de brondatabases moeten worden geherstructureerd omdat ze bijvoorbeeld technisch en conceptueel verouderd zijn

• Voordelen: de masterdata zijn op één plek toegankelijk (wat goed is voor de datakwaliteit) en hun ‘Data Catalog’ is gemeenschappelijk, het voor datagebruikers toegankelijke deel wordt verspreid. De privacy en veiligheid zijn gewaarborgd. Elke data-producent blijft zijn eigen data beheren en deze worden niet gedeeld.
• Nadelen: de brondatabases moeten worden geherstructureerd, mogelijke prestatieproblemen.

4. Centralisatie

Voorlopige conclusies 

Wat de voorgestelde architecturen betreft (en rekening houdend met alle voorafgaande stappen die in dit artikel zijn geïllustreerd), lijkt de virtuele directory met “Data Catalog” de beste oplossing. Als een (herstructurering van) de brondatabases nodig is, kan samenwerking worden overwogen. 

In een volgende blogartikel over Master Data Management zullen we kijken naar de lessen die in België en in het buitenland zijn geleerd over het gebruik van Master Data Management op basis van de tools en implementatiemethoden, en zullen we een typologie van MDM-tools geven met een kritische en constructieve blik. 

Referenties

(1) DUBOIS P. et al. (University of Paris), Harnessing Data Integrity: A Study of Master Data Management Best Practices. MZ Computing Journal, vol 5, issue 1, 2023.

(2) Hype Cycle for Data and Analytics Governance 2025, Gartner, 19 June 2025 – ID G00827117.

(3) LEPENIOTIS P, Master data management: its importance and reasons for failed implementations. Doctoral Thesis, Sheffield Hallam University Press, 2020 (3 vol.).

(4) SINGH A. et al., Best Practices for Creating and Maintaining Material Master Data in Industrial Systems In International journal of research and analytical reviews, vol 10, issue 1, Janvier 2023.

(5) TRIGAUX J.-C., Master Data Management – Mise en place d’un référentiel de données. Bruxelles,  Smals Research, Deliverable 2009/TRIM4/01. 

(6) BOYDENS I., De kern van data governance: ‘data catalogs’ of Metadata Management Systemen, Brussel, Smals Research, blogartikel, 19/03/2025 (link beschikbaar naar de Franstalige versie).

(7) BOYDENS I., HAMITI G. en VAN EECKHOUT R., A service at the heart of database quality. Presentation of an ATMS prototype. In Le Courrier des statistiques, Parijs, INSEE, 2023, nr. 6, 11 p. (gepubliceerd op 2/10/2023). Link naar het artikel.

(8) BOYDENS I., HAMITI G. en VAN EECKHOUT R., Data Quality: “Anomalies & Transactions Management System” (ATMS), prototype & “work in progress”, Brussel, Smals Research, blogartikel, 02/12/2020, last update 04/07/2025. (link beschikbaar naar de Franstalige versie).

(9) BOYDENS I., CORBESIER I. en HAMITI G., Data Quality Tools : retours d’expérience et nouveautés, Brussel, Smals Research, blogartikel, 07/12/2021.

(10) BOYDENS I., Dix bonnes pratiques pour améliorer et maintenir la qualité des données, Brussel, Smals Research, blogartikel, 16/06/2014, last update: december 2021.

(11) BOYDENS I., Data Quality & Back Tracking : depuis les premières expérimentations à la parution d’un Arrêté Royal, Brussel, Smals Research, blogartikel, 14/05/2018.

(12) XLS en het FedVoc-bestand gepubliceerd op GitHub van BelgIF GitHub – belgif/fedvoc: Federal Vocabularies

Dans cet article, nous illustrons la problématique à laquelle répond la gestion des Master Data (« Master Data Management (MDM) »). Nous définissons ensuite cette branche de l’informatique sur la base d’exemples et montrons ses liens avec la gouvernance et la gestion de données (“data governance” et “data management”). Nous présentons également une méthode de mise en œuvre ainsi que des architectures associées avec leurs avantages et inconvénients. 

La problématique à résoudre

La gestion des Master Data vise à résoudre deux types de difficultés.

D’une part, certaines données peuvent être dispersées, dupliquées et hétérogènes dans différentes applications et bases de données (DB) sémantiquement liées entre elles.

D’autre part, d’une DB à l’autre, les données peuvent diverger (quant au format ou au domaine de définition, par exemple) ou évoluer à des rythmes différents. En conséquence, des problèmes métier graves peuvent se poser. On observe ainsi un manque de traçabilité entre bases de données interdépendantes ou encore, l’absence de données de qualité « AI ready », ce qui constitue un obstacle à la mise en place efficace des projets d’IA croissants à l’heure actuelle.

Les buts de la gestion des Master Data sont donc l’élimination des incohérences et des dysfonctionnements opérationnels ainsi que l’amélioration de la qualité des données et du service rendu.

Définition et exemples

Le Master Data Management est davantage une discipline métier qu’un logiciel et repose sur la gouvernance des données et le data management. 

La gouvernance des données (“data governance”) est la spécification par la direction de l’institution de plusieurs éléments. Un cadre de responsabilité de haut niveau doit spécifier les modalités de gestion des Master Data (« policy settings »). Celles-ci sont fondamentales pour le business (par exemple : adresse de l’employeur ou de l’entreprise) et sont partagées entre plusieurs bases de données. A cette fin, des rôles doivent être identifiés à différents niveaux : gestion métier et technique du MDM, du système de méta-information, de la qualité des données, de l’architecture, … Enfin, une organisation appropriée pour l’évaluation, la création, la consommation et le contrôle des données est mise en place.

Le « data management » permet, sur la base des  « policy settings », de manière itérative et incrémentale, l’identification, la définition et la modélisation des Master Data, via un premier “case study” validé par le métier concerné, en vue d’une approche plus large, ce qui comporte trois axes concommitants.

En premier lieu, un système de méta-information ou glossaire transversal de données à haute valeur ajoutée (« data catalog ») doit être mis en place, sujet à propos duquel nous avons publié un article de blog en français et néerlandais en mars 2025 (6). Le catalogue de données peut aussi gérer les données non partagées entre bases de données et dont la documentation est importante.

En second lieu, une approche focalisée sur la qualité des données (6, 7, 8, 9, 10, 11) doit être mise en place. Elle inclut deux types de méthodes. Les méthodes curatives (9), via des data quality tools, (Batch et Rest API sur le catalogue ReUse) permettent de traiter les problèmes (anomalies, présomptions de doublons, adresses à nettoyer,…) quand ils sont déjà présents dans les bases de données. Les méthodes préventives (7, 8, 11) permettent quant à elles de prévenir l’émergence d’anomalies en en détectant la cause (ou les causes) entre institutions et expéditeurs dans les flux d’information (par exemple, problème d’interprétation de la loi, émergence d’un nouveau concept (mutations de virus, …), définitions incohérentes, bugs, …) et en les supprimant structurellement à la source, de sorte qu’elles ne se présentent plus/pas dans les bases de données (à venir, voir Catalogue ReUse).

La figure ci-dessous illustre les deux méthodes schématiquement, lesquelles peuvent interagir entre elles.

Enfin, en troisième lieu, un système de Master Data Management assure le choix d’une intégration entre les DB concernées et le catalogue de données (ou système de méta-information), il existe différentes architectures, que nous verrons plus loin.

Ces étapes importantes permettront de gérer transversalement des données synchronisées dans différents projets et applications. L’objectif de l’approche MDM est de mutualiser les efforts et d’assurer la synchronisation, la qualité, le partage et le contrôle des données à travers les différents silos. Et ce, quasiment en temps réel ou en mode différé (quand un workflow d’approbation s’impose pour la validation des modifications et des versions).

Par exemple (2, 5) : le MDM permettra de traiter les cas où deux termes différents sont utilisés dans le même sens et doivent être harmonisés (montant à payer, montant dû) ou encore, ceux où un même terme peut avoir plusieurs sens différents (ainsi, salaire peut signifier salaire brut, salaire de base, salaire et traitements, ou encore, salaire net, …). Dans notre contexte belge, il faudra prendre également en considération l’harmonisation entre les termes des différentes langues usitées, ce qui est un facteur de complexité supplémentaire. En effet, il n’y a pas de relation biunivoque nécessaire, pour un concept donné, entre les différents termes des différentes langues nationales.

Plus rigoureusement, on distingue des données suivantes dans le cadre du MDM (pour plus de facilté, nous parlerons par la suite de Master Data) :

• • Master Data  : le plus petit nombre d’ensembles cohérents d’identifiants et d’attributs qui décrivent de manière unique les entités principales d’une institution ou d’une entreprise et sont utilisés dans plusieurs bases de données et processus métier liés conceptuellement et fonctionnellement entre eux.
  • Data “non master” : donnée (provisoirement) non partagée par plus d’une base de données à un instant t (exemple fictif : nom de l’ouvrier affilié à l’ONVA, Office National des Vacances Annuelles – prélève et redistribue les pécules des ouvriers)
  • Reference Data :  taxonomies, listes de codes partagés (exemple : codes pays) – bijlage – annexes dans les glossaires de la sécurité sociale
  • Operationnal Data : données sensibles potentiellement constituées des trois premières et d’un traitement confidentiel, demandant un échange sécurisé (exemple : le montant de prestations de maladie professionnelles dues au travailleur T, dont le n° de RN est … pour l’instant t.).

Master Data Management : méthode de mise en oeuvre

Sachant qu’un projet de Master Data Management est avant tout un projet métier, avant la mise en place d’un système informatique, il comporte les étapes suivantes souvent itératives (1, 3, 4) : 

• Définir l’étendue du projet (commencer par un projet “modeste” essentiel, qui peut être incrémental et itératif, “nice to have”)
• Définir un agenda haut niveau (planning) de mise en œuvre, projet continu (conception et maintenance) soutenu par la hiérarchie, ce qui inclut les points suivants :
• Mettre du relief (analyse), et identifier :
  • Les utilisateurs des données, leurs objectifs
  • Les sources authentiques
  • Les concepts principaux, et les Master Data (identifiant unique, catégories principales, …). Attention : des compromis sont parfois nécessaires, le choix des Master Data n’est pas nécessairement déterministe
  • Les événements/processus pouvant affecter les Master Data (mise à jour, partage, et suppression, dus à l’évolution de la législation ou du réel appréhendé – par exemple : mutations de virus et évolution des concepts en médecine, …)
  • l’organisation associée (p. ex. workflow de validation)
  • La gestion des versions des Master Data et des métadonnées (6)
  • La qualité des données : évaluation et amélioration (6, 7, 8, 9, 10, 11) – voir supra
  • La sécurité et la vie privée
• Définir des KPI ou métriques pour valider, mesurer et suivre les résultats de l’approche MDM, par exemple : 
  • Baromètres de qualité DmfA: suivi des anomalies, indicateurs financiers (AR-KB 2017), … (11)
  • Mesures de la traçabilité entre bases de données sémantiquement liées entre elles.
• Établir de façon incrémentale, comme évoqué plus haut, un référentiel ou glossaire des données ou système de méta-information (6) en retenant les fonctionnalités importantes pour une mise en production ultérieure :
  • Gestion des versions (planning) des Master Data et des métadonnées (législation évolutive, durée de prescription, force probante, émergence de nouveaux concepts, …)
  • workflow de validation
  • Multilinguisme
  • Héritage
  • Standard et format d’échange (« Write Once Publish Many”)
  • Recherche multibase et multilingue
• Établir une stratégie d’évolution, de gestion du changement pour le passage de la situation antérieure ou actuelle (« AS IS ») à la situation à venir (« TO BE »)
• Établir des rôles et des équipes business et IT (MDM, Data Quality, Architecture, …)
• Définir les standards (recommandé pour l’analyse : (12))
• Établir une méthode d’intégration des bases de données concernées ; via le référentiel ou glossaire transversal des données, ce que nous allons voir au point suivant : les architectures d’intégrations, avec leurs avantages et inconvénients sur le plan :
  • de la qualité des données (10)
  • de la sécurité et de la vie privée
  • de la performance
  • du caractère plus ou moins intrusif dans les systèmes d’information concernés

Architectures d’intégration entre bases de données et data catalogs éventuellement liés, avec leurs avantages et inconvénients 

Les schémas qui suivent sont adaptés de (5) et modifiés selon les solutions actuelles (1, 2, 3, 4)

1. Les répertoires virtuels 

Avec un Répertoire virtuel, l’annuaire des données (au centre du schéma, en rouge) permet, en fonction d’une base de connaissance sur les autorisations de consultation, le transfert des données des bases de données sources vers les consommateurs. Il y a des similarité avec la BCSS qui est un réseau stellaire permettant l’échange de données entre institutions. S’agissant de la sécurité sociale, les consommateurs de données peuvent consulter un glossaire des données (ou “data catalog” dans le schéma) au fil des versions, en ligne sur le portail de la sécurité sociale (6). Il s’agit d’une bonne solution dans le contexte évoqué.

• Avantages : respect de la vie privée, sécurité, les bases de données sources ne doivent pas être modifiées
• Désavantages : questions de performance éventuelles, les producteurs de données doivent partager leur data catalog, l’unifier, en assurer la mise à jour au même rythme et le rendre accessible aux consommateurs.   

2. la consolidation

Dans la consolidation, les bases de données sources sont copiées dans une base de données commune en une seule fois (“one shot”). Aucun “data catalog” ne se trouve sur le schéma car la base de données commune est ensuite désynchronisée des bases de “données sources” qu’elle est censée représenter. Cette solution n’est pas conseillée. Elle fut appliquée par le passé à la gestion des bons de cotisations en soins de santé, puis abandonnée. 

• Avantages : simple pour les producteurs de données : les bases de données sources ne doivent pas être modifiées
• Désavantages : les bases de données sources et leur data catalog peuvent évoluer à leur propre rythme et la base de donnée commune à un autre rythme (“ghost factory”, source de redondance) : des problèmes se posent au niveau de la qualité des données “consolidée”, partager un “data catalog commun” n’a plus de sens

3. La coopération

Avec la coopération, les bases de données sources partagent les “Master Data” communes dans une nouvelle base de données et continuent à gérer leurs données qui ne sont pas communes. Pour les données communes qui sont gérées en un seul exemplaire (donc, sans redondance), un “data catalog” est mis à disposition de tous les consommateurs de données et mis à jour de manière collégiale par les producteurs de données. Il s’agit d’une bonne solution si les bases de données sources demandent une restructuration parce que, par exemple, elles sont devenues obsolètes techniquement et conceptuellement.

• Avantages : les Master Data sont accessibles en un endroit unique (ce qui est bon pour la qualité des données) et leur “data catalog” est commun, la partie accessible pour les consommateurs de données est diffusée. Le respect de la vie privée et la sécurité sont assurés. Chaque producteur de données continue à gérer les données qui lui sont propres et ne sont pas partagées.
• Désavantages : les bases de données sources doivent être restructurées, questions de performance éventuelles

4. La centralisation

Avec la centralisation, les bases de données sources partagent leurs Master Data dans une nouvelle base de données unique sur laquelle les producteurs de données n’ont plus seuls le pouvoir. Cette nouvelle base de données est gérée selon une organisation collégiale coordonnée et imposée aux producteurs de données. Un seul “data catalog” en définit le contenu harmonisé (on le voit représenté en rouge dans le schéma et à l’extérieur, accessible à toutes les parties, producteurs et consommateurs). Ce « data catalog » est également géré de manière collégiale et coordonnée, imposée aux producteurs de données.

Pour les raisons évoquées (dans les inconvénients ci-dessous), au sein du domaine d’application de l’administration publique, cette solution n’est pas conseillée. Elle est parfois pratiquée dans le secteur privé au sein d’une multinationale, par exemple (elle fut appliquée dans les années 1990 chez AT&T Laboratories aux USA).

• Avantages : les Master Data et leur catalogue sont accessibles en un endroit unique (ce qui est bon pour la qualité des données) et leur data catalog est commun
• Inconvénients : les bases de données sources doivent être restructurées et perdent leur pouvoir sur les données dont elles avaient la gestion seules, il y a des questions potentiellement graves de vie privée, de sécurité et de performance (beaucoup de requêtes)

Conclusions provisoires 

En ce qui concerne les architectures proposées (et toutes les étapes préalables illustrées dans cet article étant prises en compte), le répertoire virtuel avec “data catalog“ semble la meilleure solution. Si un (reengineering) de bases de données source est requis, la coopération peut-être envisagée. 

Dans un prochain article de blog sur le Master Data Management, nous envisagerons les “lessons learned” en Belgique et à l’étranger sur le recours aux Master Data Management selon les outils et les méthodes de mise en oeuvre, ainsi qu’une typologie des MDM Tools avec un regard critique et constructif. 

Références

(1) DUBOIS P. et al. (University of Paris), Harnessing Data Integrity: A Study of Master Data Management Best Practices. MZ Computing Journal, vol 5, issue 1, 2023.

(2) Hype Cycle for Data and Analytics Governance 2025, Gartner, 19 June 2025 – ID G00827117.

(3) LEPENIOTIS P, Master data management: its importance and reasons for failed implementations. Doctoral Thesis, Sheffield Hallam University Press, 2020 (3 vol.).

(4) SINGH A. et al., Best Practices for Creating and Maintaining Material Master Data in Industrial Systems In International journal of research and analytical reviews, vol 10, issue 1, Janvier 2023.

(5) TRIGAUX J.-C., Master Data Management – Mise en place d’un référentiel de données. Bruxelles,  Smals Research, Deliverable 2009/TRIM4/01. 

(6) BOYDENS I., Au coeur de la “data governance”: les “data catalogs” ou systèmes de méta-information, Bruxelles, Smals Research, article de blog, 19/03/2025 (inclut un lien vers la version néerlandaise).

(7) BOYDENS I., HAMITI G. et VAN EECKHOUT R., A service at the heart of database quality. Presentation of an ATMS prototype. In Le Courrier des statistiques, Paris, INSEE, 2023, n°6, 11 p. (publié le 2/10/2023). Lien vers l’article.

(8) BOYDENS I., HAMITI G. et VAN EECKHOUT R., Data Quality : “Anomalies & Transactions Management System” (ATMS), prototype & “work in progress”, Bruxelles, Smals Research, article de blog, 02/12/2020, last update 04/07/2025. (inclut un lien vers la version néerlandaise).

(9) BOYDENS I., CORBESIER I. et HAMITI G., Data Quality Tools : retours d’expérience et nouveautés, Bruxelles, Smals Research, article de blog, 07/12/2021.

(10) BOYDENS I., Dix bonnes pratiques pour améliorer et maintenir la qualité des données, Bruxelles, Smals Research, article de blog, 16/06/2014, last update : décembre 2021.

(11) BOYDENS I., Data Quality & Back Tracking : depuis les premières expérimentations à la parution d’un Arrêté Royal, Bruxelles, Smals Research, article de blog, 14/05/2018.

(12) XLS et le fichier FedVoc publié sur le GitHub de BelgIF GitHub – belgif/fedvoc: Federal Vocabularies

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

Annexe (3)

Data Centric IT

De meeste informatici weten wel wat data is, en wat databases zijn, maar zijn toch vooral ‘opgevoed’ met een focus op applicaties, algoritmes, enz. De applicatie is uiteraard erg belangrijk: ze verricht het nuttige werk van een computersysteem. Toch moeten we dit nuanceren. Een applicatie is eigenlijk enkel een hulpmiddel voor het manipuleren van de data. Als we er eens bij stil staan, dan komen we tot de vaststelling dat nagenoeg elke applicatie die we kennen, dient om data uit te lezen, in te voeren, mooi/anders weer te geven of te bewerken. Dit geldt zowel voor eindgebruikersapplicaties als voor applicaties die enkel I/O doen (b.v. de zogenaamde ‘batch’ applicaties). Dus eigenlijk is de data de centrale asset van een IT-systeem!

Dan kunnen we ons de vraag stellen of we hier bij het ontwikkelen van de architectuur van computersystemen niet meer rekening mee zouden moeten houden? We kunnen de data voorop stellen als centrale entiteit bij de communicatie tussen verschillende applicaties en gebruikers, en ook binnen verschillende subsystemen binnen applicaties. Doen we dit consequent, dan evolueren we stilaan naar een Data-Centric aanpak van IT.

REST

REST staat als acroniem voor ‘Representational State Transfer’. Deze wijze van data-overdracht heeft een aantal verschillende eigenschappen, waaronder dat men heel eenvoudig via http(s!) en via gebruik van eenvoudige principes als CRUD (Create – Read – Update – Delete) verschillende systemen kan laten communiceren. Voor de rest ga ik hier niet meer verder over uitweiden in deze blog, behalve één belangrijke eigenschap: een goedgemaakte REST API biedt een zelf-descriptief overzicht op data (zogenaamde resources), en niet op methodes. (Voor een mooie en praktische uitleg over REST, kan ik verwijzen naar stackoverflow en ook naar deze leuke.)

Men kan dit principe nog anders uitleggen: de namen die men aan de functies geeft die men in een REST API (Application Programming Interface) kan oproepen om een resultaat te bekomen, zullen geen werkwoorden zijn, maar naamwoorden. Een voorbeeld maakt dit een stuk duidelijker:

Nemen we een applicatie die als één van haar functionaliteiten een lijst van personen/gebruikers beheert. Het is de bedoeling dat andere applicaties personen kunnen zoeken, opvragen, toevoegen, veranderen en verwijderen. In plaats van op de traditionele manier een programmatorische  API of een SOAP (Simple Object Access Protocol) webservice aan te bieden, openen we via een RESTful webservice een raam op de door de applicatie beheerde gegevens. Dit ziet er dan b.v. als volgt uit:

• “GET www.app.be/rest/user”: geeft alle beheerde personen (meestal geeft men daarbij slechts een beperkt aantal gegevens per persoon)
• “POST /user” (we laten het eerste deel van de url vanaf nu achterwege, dit is altijd hetzelfde): laat toe om de gegevens voor een nieuwe persoon door te sturen.
• “GET /user/100023”: geeft detailgegevens over persoon met volgnummer 100023

Het is dus eigenlijk alsof je rechtstreeks in een hiërarchische structuur van je gegevens alle nodige bewerkingen kan uitvoeren. Uiteraard zal de achterliggende applicatie niet zomaar alles toelaten: ze zal nog steeds verantwoordelijk zijn voor controle op input, en voor authenticatie en autorisatie van de systemen die van de RESTful service gebruik maken. De beveiliging in een dergelijke aanpak gebeurt best volgens de principes van Data-Centric Security, daar deze als van nature in een dergelijke Data-Centric Architecture thuishoren.
Uiteindelijk kan veelvuldig toepassen van RESTful principes om applicaties aan te sturen, leiden tot een mooi Data-Centric Ecosysteem, waar de principes van deze architectuur doorgetrokken zijn over een groot aantal verschillende applicaties: In plaats van elke applicatie nog een aparte url te geven, zal men eerder een algemene url opzetten voor de data binnen de gehele groep samenwerkende applicaties (e.g. ‘data.socialsecurity.be’ zou dit kunnen zijn voor alle applicaties binnen de sociale zekerheid). Vele applicaties samen, elk verantwoordelijk voor hun stukje van de hiërarchie, zullen instaan voor deze ene grote RESTful data API, en alle applicaties zullen er op hun beurt weer gebruik van kunnen maken, zonder dat ze zich iets hoeven aan te trekken van waar de data vandaan komt of naartoe gaat (of door welke applicatie ze wordt beheerd). De applicaties hoeven elkaar op deze manier niet meer te kennen of te adresseren; ze hebben enkel het adres nodig van de data. In een enterprise omgeving zal men typisch gebruik maken van een ‘API management suite‘ om zo’n RESTful API, of groep ervan, te beheren.

Men kan het toepassen van dit principe ook zien als een vorm van Data Virtualization, aangezien men services aanbiedt om de data, die normaal gezien in onderliggende databases zit, virtueel te ontsluiten. Indien men deze architectuur via Cloud-technologie implementeert, kan men het ook zien als een vorm van Data-as-a-Service (DaaS). Wanneer men de data ook aanbiedt aan externe partijen, kan het eventueel gaan om Open Data.

Het doortrekken van deze architectuur over de gehele organisatie, of zelfs over meerdere samenwerkende organisaties, kan sterke synergieën teweeg brengen, doordat de data voor alle applicaties éénvormig beschikbaar wordt, en doordat het gemakkelijker wordt om reeds door RESTful services ontsloten data te gaan hergebruiken vanuit meerdere applicaties. Dit leidt uiteindelijk tot wat men noemt, een bloeiende ‘API economy‘. Uiteraard is een goede governance over de data, een Enterprise Information Model, en een sterk Master Data Management van belang om hiermee echt succesvol te zijn.

Communiceren via REST of via EDA ?

Via RESTful services kan je dus in principe alle applicaties die dit vereisen, met elkaar laten communiceren. Dezelfde mogelijkheden heb ik echter eerder al voorgesteld in de context van Event Driven Architecture (EDA) in twee eerdere blogs (basis en geavanceerd). Je kan je afvragen of dit niet redundant is, of welke van de twee nu de beste oplossing is?

Het antwoord is – je had het allicht zien aankomen – dat beide oplossingen hun plaats hebben in een gedistribueerd ecosysteem. Events werken namelijk typisch asynchroon, terwijl REST synchroon kan worden gebruikt. Dit betekent dat een applicatie onmiddellijk op de hoogte kan worden gebracht, indien er een voor haar interessant Event beschikbaar is. Indien de applicatie echter meer data nodig heeft, die zich niet in een beschikbaar huidig Event bevindt, dan kan het deze gaan opvragen d.m.v. het gebruik van een RESTful service. Het besluit is dus dat we Events kunnen gebruiken om nieuwe gegevens zo snel mogelijk over het netwerk te verspreiden, naar alle belanghebbenden, en dat we RESTful services kunnen gebruiken om reeds gekende informatie universeel ter beschikking te stellen op het netwerk, waar alle geïnteresseerden ze kunnen gaan raadplegen. Een mooi complementair geheel dus – en het goede nieuws is dat de beide benaderingen meestal ondersteund kunnen worden door één en dezelfde onderliggende middleware technologie (typisch, de ‘Enterprise Service Bus‘ (ESB) ).

Besluit

Net zoals REST, passen Events heel goed in een Data-Centric Architectuur: Events, zeker business Events, zijn namelijk ook data, en een belangrijke informatiebron voor Analytics. Samen met REST hebben we dus de twee stukken van de communicatiepuzzel binnen Data-Centric IT volledig in handen.

Comme nous l’avons vu dans la première partie de ce post, il n’y a jamais de projection biunivoque nécessaire entre un domaine d’application empirique et le système d’information correspondant. La métaphore de la carte et du territoire proposée par l’informaticien William Kent en fournit une illustration imagée dans son excellent ouvrage “Data and reality. Basic Assumption in Data Processing Reconsidered” :

“A message to mapmakers : highways are not painted red. Rivers don’t have county lines running down the middle and you can’t see contour lines on a mountain.” (I)  

Comme Kent l’indique, le processus de généralisation et d’abstraction d’une réalité est toutefois indispensable en vue de conférer un pouvoir opérationnel aux données dans le contexte informatique. Nous avons observé de ce fait, à travers la notion de “temporalités étagée”, qu’il y a, dans le domaine de l’administration publique, des interactions permanentes entre l’évolution asynchrone des trois ordres de réalité suivants :

• les textes légaux;
• les systèmes d’information administratifs censés les représenter et en assurer la mise en oeuvre opérationnelle
• et, enfin, de la réalité correspondante, le monde de la population assujetie à la législation.

La prise en compte de ces trois niveaux de réalité hétérogènes et de leurs interactions permet d’avoir une vue d’ensemble sur les données, préalable indispensable en vue d’en envisager la simplification. Nous en avons présenté, sur la base d’exemples dans la partie I de ce post, une schématisation originale référencée ci-dessous. Ce modèle,  que nous avons proposé pour la première fois dans (Boydens I., “Informatique, normes et temps”, … voir II) est cité et développé par David Bade, de l’Université de Chicago, dans sa recension parue en 2011 (III)  et fut récemment appliqué à grande échelle et cité lors de la  “Metadata and Semantics Research – 8th Research Conference, MTSR 2014“, qui s’est tenue à Karlsruhe (VII). Celle-ci permet de formuler des recommandations opérationnelles afin de simplifier et faciliter la gestion des données que nous allons présenter ici.

Transformation mechanisms to interpret administrative data 

(source : I. Boydens, “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In Assar S., Boughazala I. et Boydens I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 120.) 

I. Approche pragmatique : synergies et collaborations

Théoriquement, afin de faciliter et de simplifier la gestion d’un tel ensemble, deux positions extrêmes et caricaturales pourraient être formulées  :

• L’informatique, au service du législateur, peut tout faire, quelle que soit la complexité des lois, leur enchevêtrement au fil des ans et la quantité d’exceptions (point de vue juridique extrême)
• Si la loi était formulée de manière logique et univoque, sous une forme statique, déterministe et algébrique, aucun problème de qualité et d’interprétation de données ne se poserait sur le plan opérationnel (point de vue informatique extrême).

Face à ces deux assertions, il est possible de répondre que, d’une part, l’informatique ne peut pas tout modéliser à n’importe quel coût et que l’abondance d’exceptions et de définitions hétérogènes est ingérable pratiquement. Et d’autre part, nous pouvons affirmer que la loi doit nécessairement traiter une réalité complexe et évolutive, avec l’évolution parfois imprévisible des moeurs et des droits sociaux, au fil des négociations entre partenaires, réalité qui ne peut répondre a priori a un formalisme purement logique.

Aussi, nous efforcerons-nous, dans l’esprit des initiatives menées par l’ASA, d’avoir un point de vue réaliste, entre ces deux points de vues extrêmes. Nous insisterons sur les synergies nécessaires et les bonnes pratiques à adopter idéalement, tant sur le plan juridique, que sur le plan opérationnel de la gestion d’un système d’information. Une collaboration entre les différents intervenants étant la seule piste envisageable. A cette fin, nous nous inspirons d’initiatives récentes menées en 2015 tant en Belgique qu’à l’étranger (Union Européenne, OCDE, United Nations, …) et ce, tant dans les secteurs publics que privés.

2. Initiatives de simplification sur le plan juridique

Dans l’esprit pragmatique d’une synergie, plusieurs initiatives concernent tendantiellement davantage l’environnement juridique.

Une analyse d’impact de la réglementation, tel que le modèle AIR de l’ASA-DAV, permet potentiellement d’évaluer les conséquences transversales de certaines modifications sur l’environnement concerné.

A propos de la simplification des lois ou de la réglementation, il existe un arbitrage entre deux approches :

• l’élaboration de spécifications très détaillées qui peut demander un temps important de négociation et est moins résistante au changement;
• l’élaboration de spécifications plus génériques, éventuellement plus clairement négociées, plus résistantes au changement mais laissant la place à un certain flou dans la mise en oeuvre pratique.

La seconde piste peut être recommandée, quand la teneur des réalités à réglementer le permet, pour sa résistance au temps, sa généricité et sa simplicité, elle demande toutefois lors de sa traduction pratique et opérationnelle les précautions suivantes :

• une grande rigueur de mise en oeuvre pratique au niveau des business rules au sein des bases de données;
• une collaboration continue entre les intervenants concernés en vue de maintenir une interprétation cohérente et homogène;
• une prise en compte de la hiérarchie des normes, des conventions collectives particulières et sectorielles pouvant toujours spécifier un arrêté royal, par exemple.

3. Initiatives de simplification sur le plan des systèmes d’information administratifs et IT

Plusieurs recommandations concernent en particulier le niveau IT :

• une bonne gouvernance, afin d’éviter l’émergence de silos d’information hétérogènes (on parle de risque de “death by silos“) en établissant des liens entre équipes, la société privée Colruyt Group mais aussi le dernier rapport des Nations Unies en matière d’egovernment (année 2014) appellent le principe du “(wo)man in the middle” via des “overlapping teams”.
• la mise en oeuvre continue des bonnes pratiques en matière de data quality (voir notre post : “Dix bonnes pratiques en vue d’améliorer et de maintenir la qualité des données“, juin 2014) à haut potentiel en terme de ROI et de simplification structurelle de la gestion de l’information.
• la mise en oeuvre de certaines technologies qui en facilitent l’application, telles que l’harmonisation des systèmes d’accès à l’information (“electronic identity management“) pour le monitoring des services online.

4. En conclusion : nécessité d’un partenariat entre les niveaux législatif, administratif et IT

Afin d’assurer le lien entre les initiatives préconisées ci-dessus, il est fondamental :

• d’établir un contact permanent entre les juristes en charge de la réglementation et les analystes et spécialistes IT en charge des bases de données opérationnelles correspondantes afin de maintenir la cohérence entre l’évolution des lois et des systèmes d’information administratifs. A cet égard, l’ASA-DAV préconise la désignation, par service public fédéral et organisme public d’un “agent de simplicitation” en charge de la coordination de telles initiatives.
• qu’une collaboration étroite existe entre les initiatives de synergie IT (Gcloud, mutualisations technologiques) et les projets d’harmonisation administratifs comme la Loi “Only Once” du 5 mai 2014 relative à la collecte unique des données.

***

Références bibliographiques

I. Kent W., Data and reality. Basic Assumption in Data Processing Reconsidered. New York : Elsevier North-Holland Inc., 1981.p. I.

II.  Boydens I., Informatique, normes et temps. Bruxelles : Bruylant, 1999, 570 p.  (Cet ouvrage s’est vu décerner le prix de la Fondation L. Davin, conféré par l’Académie Royale des sciences, des lettres et des beaux-arts de Belgique, 1999).

III. Bade, D.: It’s about Time!: Temporal Aspects of Metadata Management in the Work of Isabelle Boydens”. Cataloging & Classification Quarterly 49(4), 2011, pp. 328–338.

IV. Boydens I., “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In Assar S., Boughazala I. et Boydens I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011

Telle l’abstraction d’un visage en ses traits saillants,  l’esquisse épurée d’un mouvement de la main ou d’une silhouette aperçue dans la rue (I), “La loi (doit être) plus ferme dans ses principes et plus modeste dans ses détails” écrivent en juin 2015 Robert Badinter et Antoine Lyon-Caen dans leur dernier ouvrage paru chez Fayard, “Le travail et la loi“. Ces derniers proposent en substance (Revol M., “Code du travail : plaidoyer pour un choc de simplification”. Le point, 17/06/2015) de “désépaissir le Code du travail passé en France de 600 articles à 8 000 depuis 1974, (selon leurs calculs) et surtout, le simplifier.”

En effet, “l’extrême confusion des règles, loin de protéger les salariés inclus dans le monde du travail, exclut ceux qui voudraient y entrer. Et effraient les petits patrons, obligés de passer des heures à comprendre ce maquis plutôt qu’à dynamiser leur entreprise. Une dernière phrase, extraite là encore du livre : “Le droit du travail (…) joue contre les travailleurs qu’il est censé protéger.” 

Cette problématique se pose sous des formes diverses dans de nombreux pays, à l’instar d’un “millefeuille administratif“.

Vu les enjeux en termes de coûts-bénéfices soulevés, tant du point de vue des assurés sociaux, entreprises, employeurs et citoyens, que du point de vue de l’administration, nous approfondissons la thématique cette année. Le but de l’étude est de voir comment la question est traitée en Belgique et dans d’autres pays (secteurs publics et privés), d’en dégager une synthèse, des recommandations pratiques et si possible, de confronter certaines de ces propositions au terrain. Deux posts précéderont la publication d’un rapport de recherche plus complet. Dans cette première partie (Part I), nous avons pour objectif de poser le problème en offrant, sur la base d’exemples concrets et actuels, quelques définitions et un cadre d’analyse global. Dans un second post (Part II.) plusieurs pistes opérationnelles, dont certaines sont déjà esquissées ici, seront approfondies.

Rappelons d’emblée les initiatives passées déjà menées en Belgique dès les années 1990 en vue d’harmoniser et de simplifier la législation. Ces travaux de simplification ont donné le jour à la mise en place de la Banque Carrefour de la Sécurité Sociale (BCSS-KSZ) et à la Déclaration Multifonctionnelle (DmfA). Nous renvoyons à cet égard aux publications de Frank Robben et Pierre Vandervorst (et notamment, sa monographie : “Le paysage informatique comme métaphore” (2011, compte-rendu en FR, pp. 787-790, NL, bl. 783-786).

Enfin, de telles entreprises demandant un suivi continu, signalons le système de quantification (des coûts et bénéfices) administratifs Kafka mis en place par l’Agence de la Simplification Administrative (ASA-DAV) ainsi que, sur le site de cette même agence, la loi “Only Once” du 6 mai 2014 demandant une collecte unique et une réutilisation des données issues de sources authentiques identifiées via une clé unique. Parmi les initiatives en cours, citons enfin le projet de la BCSS en vue de faciliter l’octroi des droits liés au statut social, ce qui implique à terme, l’harmonisation de plusieurs concepts importants, comme la composition de ménage. Cette démarche en cours va dans le sens éthique de l’ouvrage de Badinter et al. paru en juin 2015 et cité au seuil de ce post.

1. Définitions et exemples concrets : nature du droit et des données administratives

En 1915, le philosophe allemand, Heinrich Rickert a très clairement formulé la question du droit en ces termes : “La justice n’existe que pour se réaliser […] Un principe juridique ne peut être appliqué avant que les phénomènes réels ne lui soient soumis. […] Les principes juridiques […] ne sont souvent liés qu’à des phénomènes transitoires, et il peut arriver que les concepts qui y sont employés, autrefois sans équivoque, ne puissent plus, face à une situation qui s’est transformée, être employés avec sûreté, voire ne soient pas même compris.”(II)
Par nature, le droit est donc empirique, sujet à l’interprétation et à l’évolution dans le temps. Ainsi, le droit se révèle au fil de son application et l’interprétation de la norme juridique interagit avec celle des faits (voir : Boydens I., Informatique, normes et temps, …  , partie II, chap 6) (III), par exemple : “Une loi contre le racisme, telle que “The Race Relations Act 1976” ne peut énumérer la liste infinie des actes de discrimination raciale : elle ne peut que déterminer les critères de reconnaissance de cette catégorie d’acte. Il revient alors au juge de décider si le fait, par exemple, d’inscrire “Sorry, no travellers” sur la porte d’un pub constitue une infraction à cette loi […] si l’expression “travellers” désigne les membres d’une race ou simplement des personnes sans domicile fixe.” (IV)

Inversément et dans le même temps, l’interprétation des faits interagit avec celle de la norme, dans le cadre d’une dynamique contextuelle, appelée “cercle herméneutique” (I. Boydens, op. cit.). In fine, une prise de décision et un arrêt sont toutefois rendus, lors de l’application du droit dans les enceintes des tribunaux, par exemple. Aux directives d’interprétation s’ajoutent des “règles de blocage” afin de mettre un terme, implicite ou explicite, à ce processus d’interprétation potentiellement infini. Parmi celles-ci, citons par exemple la séparation des pouvoirs, qui suppose que l’on ne discute pas le bien-fondé d’une loi dans les enceintes des tribunaux, l’enfermement des jurés jusqu’à ce qu’ils s’accordent sur une décision ou encore, la prescription qui limite dans le temps la prise en compte légale des cas à traiter (V).

Deux exemples récents illustrent encore cette dynamique :

• L’harmonisation progressive des statuts d’ouvrier et d’employé en Belgique : la loi entrée en vigueur le 1er janvier 2012, fixe de nouveaux délais de préavis afin de rapprocher le régime des ouvriers et des employés, l’illégalité de la différence de régime selon le statut du travailleur ayant été dénoncée par la Cour Constitutionnelle. Comme l’évoque le cabinet juridique Troxquet – Lambert & partenaires, “La distinction historique entre les prestations intellectuelles et manuelles qui a conduit à distinguer deux statuts avec des régimes très distincts entre ouvrier et employé n’est plus d’actualité. Le travail intellectuel d’un opérateur de machine informatisée n’a plus rien de manuel alors que le travail d’un archiviste ou d’un employé subalterne est beaucoup plus manuel qu’intellectuel dans un travail parfois de routine” (voir aussi : Van Kerrebroeck et al., Harmonisation des statuts ouvriers–employés. Larcier, 2014). On observe naturellement un inévitable décalage temporel entre l’évolution de la norme et celle du réel normé comme le synthétisera le cadre d’analyse général du point 2 de ce post.
• La reconnaissance, par la Cour constitutionnelle allemande le 1er novembre 2013, en plus des sexes masculin ou féminin, d’un troisième genre, à savoir du statut “intersexuel” offre un autre exemple d’évolution juridique. Déjà d’application dans d’autres continents, cette mesure qui met un terme au caractère binaire du genre pourrait, si elle s’étend, avoir un impact considérable, en terme de reengineering au sein des bases de données administratives, entre autres, sur tous les identifiants uniques, comme le numéro NISS en Belgique, au sein duquel, on a commis l’imprudence de coder le sexe de manière binaire, toute démarche d’abstraction impliquant une démarche prévisionnelle, l’identifiant unique doit être idéalement dépourvu d’information porteuse de contenu.

Ceci nous amène à la nature des données administratives (et plus largement, empiriques) :

• dont la gestion doit être d’autant plus rigoureuse (nous renvoyons le lecteur à notre post daté du 16 juin 2014 “Dix bonnes pratiques pour améliorer et maintenir la qualité des données“), de manière à éviter, en connaissance de cause, les syndromes de la  “ghost factory” ou “death by silos“.
• dont la cohérence requiert une bonne collaboration entre les instances juridiques, administratives et informatiques; idéalement – et certaines administrations, comme l’Office National de Sécurité Sociale, sont dotées d’un service “ad hoc” – avant la parution de chaque nouvelle loi, une analyse des données existantes est réalisée afin de s’assurer de la pertinence d’éventuelles modifications juridiques et ce, en vue de maintenir la pérennité des concepts génériques abstraits.

Naturellement ces questions s’appliquent à tous les concepts empiriques, sujets à l’interprétation humaine : la structure des systèmes d’information les concernant évolue avec l’interprétation des valeurs qu’ils permettent d’appréhender. De la même manière que la notion de genre a évolué dans le temps, avec l’impact juridique et administratif évoqué plus haut, les bases de données médicales, évoluent avec l’interprétation des maladies et des recherches associées… lesquelles permettent d’identifier de nouveaux faits, qui à leur tour, ont un impact sur la théorie médicale … comme en témoigne PubMed, le site de ressources de la “US National Library of Medecine“. Plus en amont, la codification des unités de mesure évolue sur la base des découvertes scientifiques, lesquelles reposent sur ces mêmes standards… évolutifs au fil des découvertes et des conventions ultérieures entre pays (à propos de la métrologie, on consultera avec intérêt les travaux du Bureau International des Poids et Mesures et les multiples évolutions et débats dont ces standards font l’objet : voir par exemple le rapport du 20 mai 2015 rapportant les échanges du “World Metrology Day” dont le thème était cette année : “Measurements and Light“).

 2. Modèle global d’analyse : “temporalités étagées” (ou “stratified time”)

En vue d’une consolidation des données, le rapport  “United Nations E-Government Survey 2014”  livre deux enseignements qui nous encouragent à considérer l’importance des interactions et d’une collaboration entre la législation, l’appareil de représentation informatique et administratif et, enfin, la population représentée :

• “In some countries, there is a tendency to separate information management and issues related to the application of ICTs from the mainstream of public administration transformation, and this can only cause conflict and inefficiencies“. (p. 81)
• “One of the greatest challenges to promoting effective collaborative governance is that too much emphasis has been placed on interoperability as being merely a technical issue. While technology certainly plays an important role, there are other important factors instrumental to effective collaboration and service integration“. (p. 90)

Ces recommandations nous incitent à partir du modèle en temporalités étagées qui a guidé nos précédents travaux et que nous illustrons ici d’exemples récents.

 Transformation mechanisms to interpret administrative data (source : I. Boydens, “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In Assar S., Boughazala I. et Boydens I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 120.) 

Ce modèle,  que nous avons proposé pour la première fois dans (Boydens I., “Informatique, normes et temps, … voir III) est cité et développé par David Bade, de l’Université de Chicago, dans sa recension parue en 2011 (VI)  et fut récemment appliqué à grande échelle et cité lors de la  “Metadata and Semantics Research – 8th Research Conference, MTSR 2014“, qui s’est tenue à Karlsruhe (VII). Nous en rappelons les principales articulations.

Les faits empiriques (sujets à interprétation humaine) doivent être évalués par rapport à un principe unificateur, un horizon de similitude de sens. L’approche herméneutique consiste en une mise en relation sans cesse renouvelée entre les observations et le contexte dans lequel celles-ci s’insèrent. La question du temps est donc centrale. Nous recourrons à deux modèles temporels que nous offre l’herméneutique, la temporalité étagée de Fernand Braudel (VIII) et le continuum évolutif de Norbert Elias (IX).

 Le concept de temporalités étagées est une construction permettant d’identifier au sein d’un objet d’étude une hiérarchie entre plusieurs séquences de transformation coexistant. Dans le modèle de Braudel, les séquences relativement les plus rapides (les évolutions politiques, par exemple) sont conditionnées par des séquences relativement plus lentes (comme les évolutions de la géographie et celles du climat). Appliqué à un système d’information empirique, nous avons montré que ce concept clarifiait le processus de construction de l’information : il permet d’identifier plusieurs échelles de transformation inter-agissantes, dont l’évolution est solidaire, mais asynchrone. Par exemple, dans un système d’information administratif, nous pouvons distinguer le temps long de la législation (qui est une théorie normée), évoluant d’un trimestre ou d’une année à l’autre (en témoignent les modifications trimestrielles de la DmfA ou encore, l’harmonisation progressive citée plus haut entre les statuts d’ouvrier et d’employé), le temps intermédiaire de l’appareil de représentation administratif et informatique, dont les transformations s’opèrent d’une semaine ou d’un mois à l’autre (pensons, en 2015, à la mise en place du GCloud et des synergies IT au sein de l’administration fédérale belge) et, enfin, le temps court, celui du réel observable faisant l’objet de la norme et de la représentation informatique et dont l’évolution est quotidienne. Régulièrement, en effet, des entreprises fusionnent ou, au contraire se scindent, d’autres disparaissent, alors que de nouvelles professions ou de nouvelles catégories d’activité non prises en compte par les nomenclatures officielles voient peu à peu le jour, avec, par exemple, la diversification des métiers de l’informatique.

D’un point de vue dynamique, une base de données idéale devrait donc calquer le rythme de ses mises à jour sur la répartition – imprévisible – en temporalités étagées des évolutions de la réalité qu’elle appréhende. À ce qui ressemble à une gageure s’ajoute la nécessité, toujours révélée a posteriori, d’intégrer des observations imprévues a priori interdites par l’hypothèse d’un monde clos (selon laquelle toute valeur violant une contrainte d’intégrité formelle est considérée comme fausse).

 Mais la construction temporelle braudélienne doit se traduire par une stratification relative du temps au sein de laquelle les interactions entre séquences de transformation ne sont pas unidirectionnelles. Il arrive en effet que des séquences relativement plus rapides aient un impact sur des séquences de transformation relativement plus lentes, c’est-à-dire que les faits observés aient une incidence sur les théories qui en ont guidé l’observation (nous avons cité, à cet égard, pour le cas de l’Allemagne, sous la pression des groupes concernés (issu du temps court du “réel observé”), la prise en compte d’un troisième genre par la Cour constitutionnelle allemande depuis 2013, ce qui pourrait avoir un impact important pour l’identification des citoyens). Le modèle de Braudel peut alors être complété par le concept du continuum évolutif de Norbert Elias. Celui-ci montre que le temps est une construction résultant de la mise en relation de deux ou de plusieurs séquences de transformations (chaque séquence s’apparentant à un continuum évolutif) dont l’une est normalisée en vue de servir d’étalon pour mesurer les autres. Ce processus de construction lui-même évolutif est intimement lié à l’état du fonds de savoirs dont dispose la société dans lequel il s’insère. En d’autres termes, plusieurs continuums évolutifs coexistent, chacun d’entre eux étant à la fois objet normé et référentiel normatif

 Ainsi, par exemple, dans le domaine des bases de données de la sécurité sociale, l’identification de la catégorie d’activité des employeurs est déterminante pour le calcul du taux de cotisations sociales qu’ils doivent payer à l’Etat. En Belgique, comme nous l’avons déjà mentionné, ces cotisations s’élèvent annuellement à 45 milliards d’euros environ. Les enjeux sociaux et financiers sont donc colossaux. Pour catégoriser les employeurs, la législation administrative utilise une nomenclature des activités européennes mise à jour selon une périodicité pluriannuelle. Mais entre chacune de ces mises à jour, la réalité économique ne cesse d’évoluer de manière quasi continue (pensons, par exemple à l’évolution des types d’énergie renouvelable et à la législation les concernant, variable d’un pays à l’autre).

 On observe de nos jours le même phénomène de stratification temporelle dans les exemples évoqués  au seuil de ce post (médecine et métrologie). En soi, les itérations de la norme aux faits et des faits à la norme sont infinies. Dans notre approche, des critères d’arrêts sont guidés par un principe d’ordre pratique tenant compte des contraintes de budgets : il s’agit d’analyser la nature des arbitrages auxquels sont confrontés les gestionnaires d’un système d’information en vue d’harmoniser la loi (par les instances qui en ont le pouvoir), les normes administratives ou encore d’améliorer le processus de gestion des bases de données en tenant compte des enjeux. A cette fin, nous avons proposé un modèle conceptuel d’identification et de suivi de l’historique des anomalies (violations fictives de contraintes d’intégrité) en vue du déploiement de stratégies de gestion de la base. Il est par exemple possible d’évaluer la rapidité de traitement des anomalies afin de déterminer quel est le moment le plus opportun pour exploiter la base de données ou de détecter non seulement les augmentations anormales du nombre d’anomalies (en fonction d’un seuil donné), mais aussi les augmentations des validations d’anomalies lors de la phase de traitement des données. Une opération de validation signifie qu’après examen, un agent a estimé que l’anomalie, qui est une présomption d’erreur, correspondait à une valeur pertinente. L’opérateur de saisie peut en effet « forcer » le système à accepter ladite valeur. Si le taux de telles validations d’anomalies est élevé et récurrent, la probabilité est grande que la structure de la base elle-même ne soit plus pertinente pour certaines données. Un algorithme émet alors un signal à destination du gestionnaire de la base afin que celui-ci examine si une modification structurelle de son schéma est requise. Lorsque les cas de validations d’erreurs sont importants, il est intéressant d’approfondir le phénomène : comme nous l’avons vu, un cas de figure inédit est peut-être apparu, ce qui requiert une adaptation de la structure de la base.  Pour la Sécurité sociale belge, la mise en œuvre de cette méthode a permis d’améliorer la précision et la rapidité du traitement des cotisations sociales en réduisant potentiellement de 50 % le volume des anomalies formelles (qui représentaient jusqu’alors chaque trimestre de 100 000 à 300 000 occurrences nécessitant une gestion manuelle). Nous avons publié, prototype à l’appui, toutes les modalités conceptuelles et logiques d’un tel système dans notre rapport relatif à la gestion intégrée des anomalies de mars 2011.

Dans la suite de cette étude relative à la simplification des données (et notamment dans le post suivant, Part II), nous nous inspirerons encore de la structure en temporalités étagées présentée ci-dessus en vue de situer les interactions entre les différentes solutions opérationnelles.

3. Quelles pistes opérationnelles ? Synergies et collaborations…

Les pistes de solutions en vue de simplifier les données et leur gestion reposent naturellement sur les acquis déjà cités dans les parties qui précèdent. Nous verrons qu’elles  peuvent varier selon que l’on se situe au niveau national ou international, dans les secteurs public ou privés :

• au sein du secteur privé, les opérations de simplification peuvent, dans le meilleur des cas, bénéficier d’un management potentiellement plus fort et d’une meilleure gouvernance, le champ d’action étant plus clair et ciblé. Nous avons cité et exposé dans une note de recherche de 2012 (Data Tracking : le “Return On Investment” de l’analyse des flux d’information) :
  • les méthodes de “data tracking” appliquées chez AT&T Laboratories aux USA ainsi que le ROI du “reengineering” qui en a découlé (les gains financiers de l’opération furent évalués aux deux tiers du montant antérieurement consacré au traitement de l’information : gain en temps de traitement, en manpower et en montant facturé). Naturellement, la firme AT&T disposait en terme de management d’un pouvoir important pour contraindre tous ses partenaires à un reengineering et à une harmonisation complète de leurs bases de données.
  • Nous avons appliqué à méthode à une base de l’ONSS en l’adaptant (voir rapport supra) et le ROI qui en a résulté est important également : diminution des anomalies et du manpower en terme de temps de correction au sein des institutions et chez les expéditeurs de l’information (de 50 % à un facteur 20 dans des opérations stratégiques et ciblées), sans compter les gains qualitatifs en terme de crédibilité, de qualité et de justice sociale. Toutefois, dans le secteur public, il est plus complexe, voire impossible, d’avoir une approche holistique, pour des raisons de management et aussi d’échelle (une application à l’échelle nationale est impensable, à ce stade).
  • Dans le même ordre d’idée, lors d’un séminaire IT Works (Integratie-Oplossingen in de Praktijk:Vandaag en Morgen, 21 Mei 2015), Colruyt Group (qui inclut en Belgique non seulement Colruyt mais aussi Laagste Prijs, Spar, Dreamland, Dreambaby, Bio-Planet, …) faisait état d’une gestion très contrôlée en terme de gouvernance, de Product Information Management (PIM) et de charge back vis à vis du business, tout en devant faire face aux évolutions légales et au risque de “death by silos“, en cas de défaut de gouvernance. Il sera utile de s’inspirer d’initiatives de ce type, comme nous l’avons fait pour le “data tracking”.

• dans le secteur public, au plan national :
  • nous avons cité pour la Belgique (voir supra) plusieurs grandes initiatives d’harmonisation réalisées par le passé ainsi que les projets en cours en 2015.
  • le plus souvent, à côté de ces vastes initiatives, (comme dans le cas de l’harmonisation des régimes ouvriers et employés), on parle plus couramment de “consolidation“, c’est-à-dire qu’on harmonise ponctuellement à l’occasion d’une refonte législative ou d’une obligation légale.
  • par ailleurs, nous avons évoqué l’importance du partenariat entre le niveau législatif et le niveau administratif et IT (les deux premières séquences de la temporalité étagée) :
    • en donnant l’exemple d’une cellule, au sein de l’ONSS en contact permanent avec les développeurs afin de maintenir la cohérence de l’évolution des concepts administratifs.
    • il serait souhaitable qu’une collaboration plus étroite existe, dans l’autre sens, entre les initiatives de synergie IT (Gcloud, mutualisations technologiques) et les projets d’harmonisation administratifs comme la loi “Only Once” de 2014 et d’autres projets de consolidation législative.
  • la cohérence des données (ou même leur simplification) peuvent être facilitées également par un système de Master Data Management, analogue aux glossaires de la sécurité sociale (avec workflow de validation, historique, gestion des version, …), cette documentation étant par ailleurs diffusée aux citoyens concernés (troisième strate temporelle du modèle temporel).
  • enfin, nous avons rappelé (post cité au point 2 supra) les grands principes en vue d’améliorer et maintenir la qualité des données, dont le recours aux Data Quality Tools, s’inscrivant dans un service plus large dont Smals dispose.

• dans le secteur public, au plan international et européen :
  • pour certains postes, l’harmonisation est devenue une obligation sur de nombreux plans, au niveau monétaire, par exemple. L’actualité nous montre toutefois régulièrement combien cette harmonisation est complexe : en témoignent les vifs débats autour de la législation bancaire ou de l’espace Schengen.
  • il existe de nombreuses recommandations en vue de proposer une meilleure interopérabilité (plateformes, standards génériques de type “linked data“, …) : ainsi lors de l’UE Semantic interoperability conference qui s’est tenue à Riga ce 5 mai 2015, dans le cadre du programme européen ISA (interoperability solutions for European public administrations, businesses and citizens). Toutefois, les efforts pour les appliquer réellement dans chaque contexte national ne sont pas négligeables et demandent souvent une adaptation “sur mesure”.
  • Il sera utile de voir dans quelle mesure un partenariat “public – privé” peut s’avérer réaliste, sur la base des précédents en la matière. Ainsi, lors de la conférence de Riga, un représentant de Gartner a donné une conférence faisant état de nombreux points communs entre les systèmes d’information des différents secteurs, insistant notamment sur :
    • l’importance du “knowledge management” : “If only HP knew what HP knows, we would be three times more productive“;
    • la nécessité de commencer par des “quick wins” et de s’adapter aux moyens disponibles : “Follow the money : do what you can and not what you want”…

L’ensemble de ces pistes seront approfondies et exemplifiées dans un prochain post. En conclusion, retenons à ce stade, dans une perspective de “data simplification“, que ces solutions devront reposer sur une méthode d’abstraction et de gestion des données poursuivant un double objectif  :

• prendre au mieux en compte les évolutions pertinentes issues des interactions entre les différents niveaux de la dynamique en temporalité étagée (nouveaux phénomènes issus du réel observable, obsolescence de certaines lois au regard de l’état du réel observable à un instant t, notamment à travers une gestion adéquate de l’historique des anomalies (voir points 1 et 2, supra);
• exploiter cette même dynamique pour renforcer les synergies et éviter l’émergence inutile de définitions hétérogènes pour un même concept tant au niveau législatif qu’au niveau “data”, sur les plans administratifs et IT. 

 ***

Références complémentaires aux liens figurant dans ce post

(I) Croquis réalisés par Clara Leclercq, 2014.

(II) Rickert H., Théorie de la définition. Paris : Gallimard, 1997, pp. 238-239 (édition originale : “Zur Lehre von den Definition”, 1915).

(III) Boydens I., Informatique, normes et temps. Bruxelles : Bruylant, 1999, 570 p.  (Cet ouvrage s’est vu décerner le prix de la Fondation L. Davin, conféré par l’Académie Royale des sciences, des lettres et des beaux-arts de Belgique, 1999).

(IV) McEvoy S., La question de l’arrêt : le cas de l’argumentation dans le droit. In Bourcier D. et Mackay P., éds, Lire le droit. Langue, texte, cognition. Paris : Librairie Générale de Droit et de Jurisprudence, 1992, p. 185.

(V)  Huet J., Droit, informatique et rationalité. In Droit et informatique. L’hermine et la puce, Collection F. R. BULL. Paris : Masson, 1992, p. 83.

(VI) Bade, D.: It’s about Time!: Temporal Aspects of Metadata Management in the Work of Isabelle Boydens”. Cataloging & Classification Quarterly 49(4), 2011, pp. 328–338.

(VII) Radio E., “Information Continuity: A Temporal Approach to Assessing Metadata and Organizational Quality in an Institutional Repository“. In Closs S. et al., éds, Metadata and Semantics Research – 8th Research Conference, MTSR 2014, Karlsruhe, Germany, November 27-29, 2014. Proceedings, Springer, pp. 226-237.

(VIII)  Braudel, F., La Méditerranée et le monde méditerranéen à l’époque de Philippe II, Paris, Armand Colin, 1949.

(IX) Elias N., Du temps, Paris, Fayard, 1996.

Au final, les données sont généralement peu valorisables car dupliquées dans plusieurs silos fonctionnels, chacun exploitant sa propre base de données avec ses propres structures de données, sa propre interprétation de leur contenu et ses propres règles métier.

L’enjeu du Master Data Management (MDM) est de faciliter la gestion des données de référence transversalement à différentes applications en mettant en place une organisation de circonstance supportée par un référentiel de données. La mise en place d’un tel référentiel permettrait de se réapproprier ses données métier, de les enrichir et d’assurer leur pérennité, indépendamment des processus qui les manipulent. D’un point de vue opérationnel, l’approche MDM permet de mutualiser les efforts et d’assurer la synchronisation, le partage et la qualité des données à travers plusieurs silos d’informations en quasi temps réel.

L’approche MDM est directement liée au partage des données entre acteurs de la sécurité sociale et/ou des soins de santé. Aussi bien la BCSS que eHealth ont été des précurseurs dans ce domaine. Chaque jour, de nombreuses banques de données gèrent et partagent des données ; quelques exemples révélateurs sont : la signalétique des citoyens, la signalétique des travailleurs, la carrière des employés, l’identification des entreprises, les vaccinations, les dons d’organes, la description des médicaments, etc.

Clairement, l’approche MDM est au cœur du eGovernment et de eHealth. L’appropriation des concepts MDM par les institutions gouvernementales représente une opportunité pour faciliter la collaboration entre les consommateurs et les fournisseurs de données, faciliter la mise en place d’une approche SOA, améliorer les services associés aux banques de données et enfin mutualiser les efforts en terme de synchronisation des données, d’amélioration de leur qualité et de gestion des anomalies.

En revanche, les outils MDM doivent être manipulés avec précaution. Même si la complémentarité des technologies peut devenir un avantage indéniable, leur intégration est encore difficile au sein d’un seul outil. De plus, le support lié à la gouvernance des données est pour l’instant la pierre angulaire qui manque crucialement aux outils MDM. Enfin, l’intégration de ces outils avec les applications existantes peut s’avérer délicate.