Isabelle Boydens(*), Isabelle Corbesier(**) et Gani Hamiti(**)

(*) Data Quality Expert, Research Team

(**) Data Quality Analyst, Databases Team

De oorsprong van het concept ‘observability’

De term observability in IT komt oorspronkelijk uit de software engineering.

Observability is een concept op hoog niveau dat betrekking heeft op het analyseren van de algemene toestand van een systeem van bijzonder heterogene en talrijke componenten, om kritisch gedrag te diagnosticeren en de oorzaken ervan te helpen identificeren (1). In de praktijk betekent dit het continu verzamelen en analyseren van basisinfrastructuurgegevens zoals processor- of opslagruimtegebruik in de loop van de tijd, evenals mogelijk complexere toepassings- of trackinglogs. Met de toename aan technologieën en componenten in moderne informatiesystemen kan genoeg observability bereiken soms veel ontwikkelingswerk vergen. Deze moeilijkheid heeft gezorgd voor een vruchtbare bodem voor de opkomst van tools voor observability, die kunnen worden gebruikt om gegevens te exploiteren die al door een systeem zijn geproduceerd, of om functionaliteiten voor gegevensproductie te enten op de componenten om het gedrag ervan beter zichtbaar te maken. (2)

Het soms geforceerde onderscheid tussen monitoring en observability kan in twijfel worden getrokken, in zoverre dat, net als observability, praktijken met het label ‘monitoring’ nooit worden ontwikkeld als een doel op zich, maar ook de toestand van het systeem willen diagnosticeren en incidenten voorkomen of corrigeren. Sommige referenties leggen overigens een verband tussen de twee concepten, omdat monitoring (meestal APM of Application Performance Monitoring ) en observability in dezelfde definitie zijn opgenomen, die dezelfde producten dekt.  Ook al liggen de twee concepten niet op een lijn, ze zijn tenminste nauw verwant. Een goed niveau van observability vereist namelijk voldoende monitoring, goede documentatie en een grondige kennis van het systeem bij de teams die verantwoordelijk zijn voor het observeren ervan.

Van software naar data

Figuur 1 – Informatiesysteem: heterogene componenten en feedbackloops

In navolging van data profiling (een kwaliteitsaudit van gegevens (3) die meestal voorafgaat aan de standaardiserings- en matchingfasen (4) in data quality tools) in de jaren 90, is data observability een recente omzetting (de term werd massaal populair rond 2022-2023) die is overgenomen door de infrastructuurwereld. Net zoals observability in deze context bestaat uit het kunnen diagnosticeren en verbeteren van de toestand van het systeem op basis van wat we ervan zien, is data observability het kunnen diagnosticeren van de algemene toestand van de gegevens van een systeem op basis van een gedetailleerd beeld dat is opgebouwd via de metadata. Data observability zal daarom gericht zijn op het samenbrengen van het monitoren, traceren en sorteren van gegevensgerelateerde incidenten, met als uiteindelijke doel het voorkomen of minimaliseren van de downtime die hieraan kan worden toegeschreven.

In een boek dat in 2022 gezamenlijk werd uitgegeven (5), identificeert Barr Moses, CEO van Monte Carlo Data, verschillende pijlers van data observability die al in de jaren 90 bestonden bij data profiling en sindsdien op grote schaal zijn hergebruikt. We onthouden de 4 volgende essentiële punten:

• De freshness: de bevestiging dat de gegevens up-to-date zijn en op gepaste wijze vernieuwd worden.
• De distribution: de bevestiging dat de gegevens zich in een aanvaardbaar interval bevinden, waarbij onverwachte waarden of nulwaarden vermeden worden.
• De completeness: de controle dat een dataset volledig is (aantal records of kolommen) zodat mogelijke problemen geïdentificeerd kunnen worden aan de bron. Merk op dat completeness fundamenteel onmogelijk met zekerheid te meten kan zijn; dit is bijvoorbeeld het geval bij de totale populatie van mensen die aan Alzheimer lijden of kanker hebben , waarbij ze in een vroeg stadium soms niet op de hoogte zijn.
• Lineage: de documentatie en het begrip van alle datasystemen van een organisatie, met inbegrip van upstream databronnen en downstream doelsystemen. In de praktijk zien we ook feedbackloops waarbij het gebruik van downstreamgegevens (bijvoorbeeld in ‘machine learning’- of BI-projecten) leidt tot veranderingen in het upstreamsysteem (zie Figuur 1). Op deze manier overschrijdt lineage de grenzen van technische benaderingen en vereist het aanzienlijke menselijke tussenkomst en een bijbehorend budget. Andere obstakels, die hieronder worden genoemd, kunnen zich voordoen bij het aan elkaar koppelen van informatiesystemen.

Verschillen tussen “data observability tools”, “data quality tools” (curatieve aanpak) en “ATMS-backtracking” (preventieve aanpak)

De documentatie over “data observability” tools verwijst naar “lineage” in technische zin. Dit houdt in dat je observeert hoe gegevens evolueren doorheen de verschillende componenten van een systeem; bijvoorbeeld van een front-end waar gegevens worden ingevoerd, via een REST API in back-end, een transactionele database, dan een datawarehouse, tot business intelligence of reportingsystemen. In tegenstelling tot ‘back tracking’, waarbij de gegevensstroom binnen het complexe informatiesysteem wordt bestudeerd, maar vooral stroomopwaarts en stroomafwaarts van het informatiesysteem (zie Figuur 2), hebben we het hier over ‘lineage’ tussen de componenten van het informatiesysteem waartoe de beheerders van de observability tool volledige toegang zouden moeten hebben om de mutatie van de gegevens in realtime te volgen.

Een reeks relatief recente tools dragen het label ‘data observability’ waarbinnen monitoring van data soms samengaat met systeemmonitoring ( (Bigeye, Collibra, Databand (IBM), DataBuck (FirstEigen), Kensu, Metaplane, Monte Carlo, Soda, …). Merk op dat bepaalde leveranciers van data quality tools zoals Informatica of Precisely naast profiling al ‘data observability’ opnemen. De term is vandaag blijkbaar erg in de mode. Het zal interessant zijn om de ontwikkeling van de tools in kwestie te volgen en, indien nodig, ze te testen.

Data quality tools (4) beperken zich daarentegen niet tot het observeren van gegevens, maar zijn bedoeld om er direct op in te grijpen. Dit is het doel van standaardisatiefunctionaliteiten (inclusief adressen) in batch of realtime (bijvoorbeeld via REST API), evenals mogelijk “fuzzy” ”data matching” door gebruik te maken van algoritmische families die specifiek zijn voor de te verwerken business cases.

Figuur 2 – Preventieve en curatieve aanpakken

Kortom, tools voor data observability, die verwant zijn aan realtime ‘data profiling’, kunnen inspanningen ondersteunen om de gegevenskwaliteit te verbeteren, in het bijzonder door managers te helpen bij het identificeren en waarschuwen voor kwaliteitsproblemen. Het is echter nog steeds noodzakelijk om:

• specifieke hulpmiddelen voor data quality (4) te gebruiken in synergie met de business om strategieën te implementeren voor het oplossen van de gedetecteerde problemen (curatieve aanpakken);
• en/of een ATMS (6) te hebben waarmee backtracking kan worden uitgevoerd en problemen in een vroeg stadium kunnen worden voorkomen (preventieve aanpak).

Conclusie: recente op te volgen tools

In het algemeen kunnen we hieruit afleiden dat, opdat de observability die deze tools bieden een meetbare positieve impact heeft in een volwaardige bedrijfscontext:

• De organisatie die de tool gebruikt structureel gecentraliseerde toegang moet toestaan tot gegevensbronnen van verschillende aard en mate van kritiekheid. Dit punt brengt waarschijnlijk een groot aantal technische, juridische en organisatorische uitdagingen met zich mee:
  • Scheiding van omgevingen: niet alle databronnen bevinden zich altijd in productieomgevingen.
  • Netwerk- en stroomproblemen: alle benodigde componenten met elkaar laten communiceren is niet triviaal in de meeste organisaties van een bepaalde grootte en met een bepaald niveau van beveiligingseisen.
  • Hoe zit het met toegangsrechten en GDPR? Niet zozeer vanuit het oogpunt van de technische haalbaarheid van de implementatie van GDPR-vereisten, maar vooral vanuit organisatorisch oogpunt.
  • Scheiding van projecten en teams: de teams die verantwoordelijk zijn voor het toepassingsysteem vallen niet noodzakelijk onder dezelfde hiërarchie of dezelfde practices als de teams die de infrastructuur beheren of de teams die de gegevens stroomafwaarts exploiteren voor datamining of BI.
• Als het eerste punt behaald en opgelost is, moeten de systeembeheerders ook serieus samenwerken met de business over de indicatoren die gemonitord moeten worden, de kritische drempels, de waarschuwingen die geconfigureerd moeten worden en de definitie van de rollen: wie is verantwoordelijk voor welke gegevens en welke reacties worden verwacht in het geval van een probleem?

We zijn dus nog ver verwijderd van de bijna magische plug-and-play die door sommige online content wordt aangeprezen. Daarbij komt nog de realiteit van het onderzoeken van niet-triviale gegevensproblemen, die vaak verder gaat dan de grenzen van een technisch informatiesysteem, hoe complex ook. Om deze redenen is data quality meer dan ooit afhankelijk van menselijke tussenkomst en interpretatie wanneer de inzet dit rechtvaardigt.

Referenties

• (1) https://about.gitlab.com/blog/2022/06/14/observability-vs-monitoring-in-devops/
• (2) https://www.ibm.com/topics/observability
• (3) Olson Data Quality: The Accuracy Dimension (The Morgan Kaufmann Series in Data Management Systems), 2003.
• (4) BOYDENS I., CORBESIER I. et HAMITI G., Data Quality Tools : retours d’expérience et nouveautés, 07/12/2021.
• (5) https://www.oreilly.com/library/view/data-quality-fundamentals/9781098112035/
• (6) BOYDENS I., HAMITI G. et VAN EECKHOUT R., Un service au cœur de la qualité des données. Présentation d’un prototype d’ATMS. In Le Courrier des statistiques, Paris, INSEE, juni 2021, nr. 6, p. 100-122. PDF-bestand / Link naar het Blad en naar het artikel.

Deze post is een gezamenlijke bijdrage van Isabelle Boydens, Data Quality Expert bij Smals Research, Isabelle Corbesier en Gani Hamiti, Data Quality Analisten bij Smals, Databases Team. Dit artikel is geschreven onder hun eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

(*) Data Quality Expert, Research Team

(**) Data Quality Analyst, Databases Team

Version en français

De kwaliteit van een gegeven is de geschiktheid ervan voor gebruik en voor de beoogde doelstellingen (‘fitness for use’) (Boydens, 1999, Boydens 2014). In dit artikel gaan we bekijken hoe een rigoureuze typologie van de anomalieën een kader biedt voor de verbetering van de kwaliteit van de gegevens, in verschillende domeinen, waaronder machine learning. Over ML zullen we in een later artikel aantonen hoe deze techniek de functionaliteiten van een ‘data quality tool’ kan verbeteren, bijvoorbeeld in de matchingoperaties,  zoals aangekondigd in ons artikel van december 2021.

Een goed ontworpen operationele relationele database steunt op de ‘gesloten wereld’-hypothese: het definitiedomein specificeert de reeks waarden die zijn toegestaan binnen het databasemodel of schema (de integriteitsbeperkingen); ‘business rules’ zijn ook te vinden in de toepassingscode en dragen dus bij tot de definitie van de gegevens. In deze hypothese wordt een waarde die niet in het definitiedomein is opgenomen als foutief beschouwd en moet deze geweigerd worden uit de database.

Onder anomalie binnen een database verstaan we hier een formele fout (bv. een verplichte waarde die niet is vervolledigd), maar ook een veronderstelde fout die menselijke interpretatie vereist (bv. veronderstelde dubbels tussen sterk gelijkende records, opduiken van een nieuwe categorie van activiteit waarmee in de referentietabellen geen rekening is gehouden, enz.)

Hieraan moet worden toegevoegd dat een empirische databank in de loop der tijd evolueert met de interpretatie van de waarden die zij oplevert (Boydens, 1999, 2011, Bade, 2011). Bijgevolg is er nooit een één-op-één projectie tussen een database en de waarneembare werkelijkheid vertegenwoordigd. Totale kwaliteit bestaat niet. Dit maakt het des te complexer om een evaluatie- en verbeterstrategie op te zetten voor de gegevenskwaliteit, naargelang het gebruik ervan zoals machine learning (de Valeriola, 2020, 2021), op het gebied van justitie, gezichtsherkenning, ziektebehandeling of journalisme, … toegepast op zeer bijzondere doeleinden (Redman, 2018, Dierickx, 2022).

Laten we Redman en zijn eloquente voorbeelden aanhalen:

“Yet today, most data fails to meet basic “data are right” standards. Reasons range from data creators not understanding what is expected, to poorly calibrated measurement gear, to overly complex processes, to human error. To compensate, data scientists cleanse the data before training the predictive model. It is time-consuming, tedious work (taking up to 80% of data scientists’ time), and it’s the problem data scientists complain about most. Even with such efforts, cleaning neither detects nor corrects all the errors, and as yet, there is no way to understand the impact on the predictive model. What’s more, data does not always meet[s] “the right data” standards, as reports of bias in facial recognition and criminal justice attest.”

(…)

“Increasingly-complex problems demand not just more data, but more diverse, comprehensive data. And with this comes more quality problems. For example, handwritten notes and local acronyms have complicated IBM’s efforts to apply machine learning (e.g., Watson) to cancer treatment.”

Figuur 1. Preventieve en curatieve aanpakken

Naast het evidente belang voor gegevenskwaliteit is de studie naar anomalieën eveneens belangrijk omwille van het hoge percentage ervan dat de informaticasystemen structureel beïnvloedt: tot 10% van het gegevensvolume (Boydens, 2011, Van Der Vlist, 2011). Wanneer de inzet (menselijk, sociaal, financieel, juridisch, wetenschappelijk, medisch, enz.) het echter vereist, moeten deze anomalieën semiautomatisch of zelfs handmatig worden onderzocht, vaak langzaam en vervelend, zonder een ad-hocprogramma met preventieve en curatieve maatregelen, Figuur 1, (Boydens, 2014).

De typologie die we voorstellen kan nuttig zijn in alle disciplines die een beroep doen op Data: Database Management, Master Data Management, machine learning (Dierickx, 2022, Redman, 2018), … als een algemeen kader voor ‘Data Quality’-actie en helpt bij het identificeren van de meest geschikte verwerking.

Vanwaar komen de anomalieën, wat is de typologie ervan en hoe kunnen we ze van daar uit het beste beheren? Om op deze vragen te antwoorden, moeten we eerst terugkomen op het begrip ‘gegeven’ zoals we het kennen sinds 1999 en dat onlangs overgenomen werd in 2021 (Boydens I., Hamiti G. en Van Eeckhout R., 2021).

DETERMINISTISCHE GEGEVENS VS EMPIRISCHE GEGEVENS

In de wereld van de databases is een gegeven een triptiek (t, d, w) bestaande uit de volgende elementen:

• een titel (t), verwijzend naar een concept (een administratieve activiteitencategorie, bijvoorbeeld);
• een definitiedomein (d), bestaande uit formele beweringen die alle waarden in de database specificeren voor dit concept (een gecontroleerde lijst met alfabetische waarden van een maximale lengte l, bijvoorbeeld), eventueel aangevuld met business rules gevonden in de toepassingscode (zie hoger, hypothese van de gesloten wereld).
• En uiteindelijk een waarde (w) met een tijdstip t (de chemiesector, bijvoorbeeld).

We onderscheiden dan de deterministische gegevens van de empirische gegevens (Boydens, 1999, 2011).

• De eerste kenmerken zich door het feit dat we op eender welk moment over een theorie beschikken waarmee bepaald kan worden of een waarde w  al dan niet correct is. Dit is het geval met een eenvoudige algebraïsche bewerking die betrekking heeft op een object dat zelf deterministisch is, zoals de som van waarden die betrekking hebben op een gegeven numeriek veld in een database op een tijdstip t. De algebraregels evolueren niet doorheen de tijd, we kunnen dus op elk moment weten of het resultaat van een dergelijke som al dan niet correct is. We hebben immers een stabiele referentie hiervoor.

• In het geval van empirische gegevens, onderworpen aan menselijke ervaring, evolueert de norm daarentegen in de tijd met de interpretatie van de waarden die erdoor kunnen worden waargenomen. Dit is bijvoorbeeld het geval op medisch gebied (waar de theorie evolueert met de waarnemingen van patiënten die aan een pathologie lijden, zoals blijkt uit het huidige onderzoek naar het coronavirus), maar ook op juridisch en administratief gebied, waar de interpretatie van juridische concepten verandert met de voortdurende evolutie van de behandelde werkelijkheid en met die van de jurisprudentie. Hoe kan de geldigheid van deze concepten worden beoordeeld bij gebrek aan een absolute referentie hiervoor?

TYPOLOGIE VAN DE ANOMALIEÊN EN MOGELIJKE BEHANDELINGEN

Vervolgens ontstaat een typologie van anomalieën, afhankelijk van hun mogelijke oorzaak en de manier waarop ze worden beschouwd:

• zekere formele fout: bijvoorbeeld een verplicht veld dat bij handmatige gegevensinvoer door een mens niet is ingevuld;
• veronderstelde formele fouten: bv. a) veronderstelde duplicaten als gevolg van redundante processen voor gegevensvastlegging stroomopwaarts, of b) inconsistentie met een referentietabel waarvan niet bekend is dat deze actueel is, bv. op het gebied van hernieuwbare energie (figuur 2);
• een fout die a priori niet formeel kan worden opgespoord: bijvoorbeeld het weglaten van een bijwerking.

Figuur 2. Beheer van de anomalieën, ATMS, Monitoring & Back tracking

De laatste twee gevallen in bovenstaande typologie kunnen wijzen op anomalieën als gevolg van de evolutie in de tijd van het vertegenwoordigde empirische domein en het ontstaan van nieuwe concepten waarmee geen rekening is gehouden (Figuur 2). Bijvoorbeeld: een integriteitstest voordat de gegevens in de hoofddatabase worden ingevoerd, ontdekt een formele anomalie. De behandeling van de anomalie (validatie of correctie) wordt opgeslagen in het ATMS (waardoor de anomalieën en de behandeling ervan in de tijd kunnen worden gevolgd, zoals verderop in dit artikel wordt aangegeven) en gevoed door een dashboard dat, door de monitoring van de anomalieën en de behandelingen, zal helpen bij het besluitvormingsproces met het oog op de verbetering van de gegevenskwaliteit.

Afhankelijk van de behoeften van de business wordt besloten deze anomalieën te beschouwen als:

• blokkerend: ze worden uit de database verwijderd op grond van de bovengenoemde ‘gesloten wereld’-hypothese;
• niet-blokkerend: de waarden worden nog steeds geïntegreerd in het informatiesysteem met de overeenkomstige record, om twee soorten redenen:
  • door ze uit het systeem te weigeren zou het businessproces worden vertraagd (bv. de inning van sociale bijdragen) en ze worden niet als ‘strategisch’ beschouwd;
  • ze moeten in het informatiesysteem in aanmerking worden genomen, omdat ze als strategisch worden beschouwd en verband houden met empirische gegevens waarvan de definitie kan evolueren. Vanaf een bepaalde drempel die door de specialisten op het terrein moet worden beoordeeld, vereist hun verwerking menselijke interpretatie, aangezien zij kunnen wijzen op het ontstaan van nieuwe verschijnselen waarmee in het informatiesysteem rekening moet worden gehouden (Figuur 2), door middel van versiebeheer. Bovendien zijn ze mogelijk afkomstig uit de stromen die de database voeden, een probleem dat, eenmaal geïdentificeerd, structureel kan worden opgelost met back tracking (Boydens, 2018, Boydens e.a., 2021).  

De beslissing om ‘niet-blokkerende’ empirische anomalieën te identificeren is gevoelig, omdat ze gebaseerd is op voorspellende kennis van de realiteit die op een bepaald moment wordt verwerkt, wat zelf een evoluerend element is dat binnen het informatiesysteem onderhevig kan zijn aan gecoördineerde aanpassing. Dit brengt ons terug bij de epistemologische kwestie van de ‘hermeneutische lus’.

De hermeneutische benadering bestaat erin de empirische verschijnselen te beschouwen in termen van interacties in vergelijking met een eerder algemeen conceptueel kader dat is opgebouwd om er betekenis aan te geven. Elke interpretatieve benadering roept echter een paradox op: die van de ‘hermeneutische cirkel’ (Aron, 1969). Elke observatie heeft alleen zin wanneer ze wordt geconfronteerd met een geheel, met een ‘voorbegrip’. De semantiek van het geheel is echter zelf gebaseerd op de interpretatie van de samenstellende elementen. Het constructieproces dat de hermeneutiek impliceert, is van nature altijd onvolledig. Het is echter gepast om een weloverwogen stop te maken om voorlopige resultaten te leveren (Boydens, 1999).

Hoe kunnen ‘niet-blokkerende anomalieën’ en de behandeling ervan in aanmerking worden genomen zonder de prestaties of de integriteit van de gegevens in productie aan te tasten? Met het ATMS, ofwel Anomalies and Transactions Management System (Boydens e.a., 2021) – eventueel gekoppeld aan Data Quality Tools (Boydens e.a., 2021b) – in combinatie met Back Tracking (Boydens, 2018), gaan we van de ‘gesloten wereld’-hypothese naar die van een ‘open wereld’ onder geautomatiseerde controles binnen beheerdatabases. En daarbij wordt een geconsolideerd programma gebouwd om de datakwaliteit te beoordelen en structureel te verhelpen. Dit programma is nooit een ‘one shot’ omdat het in continuïteit moet worden uitgevoerd, inclusief een onderhoudsproces. 

TOEPASSING OP MACHINE LEARNING: PERSPECTIEVEN

Voor het opzetten van de ML-cyclus

In het geval van machine learning (de Valeriola, 2020, Dierickx, 2019, 2022) kan het programma (analyse en bijbehorende oplossingen) – eerder in deze blogpost geschetst – stroomopwaarts worden toegepast op de gemobiliseerde gegevens om een voorspellend model te trainen en in de tijd te onderhouden voordat de ML-cyclus wordt geïmplementeerd.

De kern van de ML-cyclus (figuur 3)

In de kern van het ML-systeem kan men kwaliteitsindicatoren inbouwen die passen bij de gekozen ML-algoritmen en -modellen, bijvoorbeeld: 

• annotaties die mogelijk via crowdsourcing zijn verkregen, in het geval van gesuperviseerde modellen (Northcutt e.a., 2021, Gupta e.a., 2021)
• de vertekeningen (of foutmarges) die al dan niet worden getolereerd, afhankelijk van de toepassingen die in synergie met IT en de business (ontwerpers van gegevens, gebruikers van het voorspellende model) worden bepaald.

Het in (Gupta e.a., 2021) aanbevolen systeem zou kunnen worden verrijkt door gebruik te maken van een ATMS aan de bron, zoals hierboven vermeld, en stelt ook voor in te spelen op de kwaliteit van reeds voor ML voorbewerkte gegevens.

Deze referentie illustreert het probleem van de slechte kwaliteit van gegevens binnen het ML-model. Zo kan een verkeerde verdeling van een kenmerk een vertekening inhouden die op haar beurt ethische kwesties oproept: in het geval van de risicogebaseerde beoordeling van kredietaanvragen, die in september 2022 door de EU wordt herzien:

 “… algoritmen kunnen vertekeningen bevatten. Zo zal een model waarschijnlijk vaak krediet weigeren aan 30-jarigen en nooit aan 57-jarigen. Waarom? Simpelweg omdat er veel dossiers van 30-jarigen waren die de machine tijdens de training bekeek, zodat de kans om fouten te vinden groot was, terwijl er slechts één of twee voorbeelden waren van 57-jarige aanvragers en zij hun krediet telkens volledig betaalden (een echter zo ruwe fout dat ze meestal wordt voorkomen, maar andere afwijkingen kunnen schadelijker zijn).“

Figuur 3. Bron: Dierickx, 2022

Verklaarbaarheid van ML-voorspellingen: wetgeving, ethische en gegevenskwaliteitskwesties, nieuwe onderzoeksgebieden

In andere door de EU genoemde gevallen is de ondoorzichtigheid van deep learning-modellen zodanig dat zelfs ingenieurs geen precieze redenen meer kunnen geven voor de voorspellingen die daaruit voortvloeien.

Er wordt een wet voorbereid om te proberen de gebruikte procedures te reguleren, de AI Act, die de GDPR moet versterken. Met betrekking tot procedures naar analogie van kredietaanvragen menen deskundigen dat “Dit niet betekent dat de gegeven verklaringen zeker en vast zullen zijn (onmogelijk bij sommige modellen), maar dat ze zeer waarschijnlijk zullen zijn – sommige ingenieurs spreken inderdaad meer van interpreteerbaarheid dan van verklaarbaarheid.” 

Het bovengenoemde programma (ATMS, data quality tools) vóór de ML-cyclus, gekoppeld aan de inrekeningname van een kwaliteitsbeoordeling in de kern van het ML-proces, wat allemaal gedocumenteerd moet worden, zou ook kunnen worden toegepast om gebruikers van voorspellende gegevens gerichter te informeren over de ‘verklaarbaarheid’ en de relatieve kwaliteit ervan, aangezien totale kwaliteit niet bestaat.

Er ontstaan geleidelijk nieuwe onderzoeksgebieden in deze richting:

Data Centric AI of ook Causal AI. Het probleem stelt zich dus stroomopwaarts, in de kern en stroomafwaarts van de gegevenslevenscyclus bij ML. 

Wat ML betreft, zullen we in een later artikel laten zien hoe deze techniek de functionaliteiten van een ‘data quality tool’ kan verbeteren, bijvoorbeeld bij matchingoperaties, zoals aangekondigd in ons artikel van december 2021.

Referenties

Aron, R., 1969. La philosophie critique de l’histoire. 1969. Édition Librairie philosophique J. Vrin. Collection Points – Sciences humaines. ISBN 2560848158182.

Bade D., It’s about Time!: Temporal Aspects of Metadata Management in the Work of Isabelle Boydens. In Cataloging & Classification Quarterly (The International Observer), volume 49, n° 4, 2011, pp. 328-338. (lien vers l’article).

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).  (Introduction et Première partie, pp. 30-126) – bibliothèques

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

Boydens I., Dix bonnes pratiques pour améliorer et maintenir la qualité des données. Bruxelles, Smals, Research Section, post de blog, 16/06/2014 (dernière mise à jour :  décembre 2021). /dix-bonnes-pratiques-pour-ameliorer-et-maintenir-la-qualite-des-donnees/

Boydens I., «  Data Quality & Back Tracking : depuis les premières expérimentations à la parution d’un Arrêté Royal  ». Bruxelles, Smals, Research Section, post de blog, 14/05/2018./data-quality-back-tracking-depuis-les-premieres-experimentations-a-la-parution-dun-arrete-royal/ 

Boydens I., Hamiti G. et Van Eeckhout R., Data Quality : “Anomalies & Transactions Management System” (ATMS), prototype & “work in progress”. Bruxelles, Smals, Research Section, post de blog,  8/12/2020. 

/data-quality-anomalies-transactions-management-system-atms-prototype-work-in-progress/

Boydens I., Hamiti G. et Van Eeckhout R., Un service au cœur de la qualité des données. Présentation d’un prototype d’ATMS. In Le Courrier des statistiques, Paris, INSEE, juin-juillet 2021, n°6,  p. 100-122.

https://www.insee.fr/fr/information/5398691?sommaire=5398695

Boydens I., Corbesier I. et Hamiti G., Data Quality Tools : retours d’expérience et nouveautés. Bruxelles, Smals, Research Section, post de blog, 07/12/2021. /data-quality-tools-retours-dexperience-et-nouveautes/

Brown S., Why it’s time for “data Centric Artificial Intelligence” ? MIT Management Sloan School, juin, 2022. https://mitsloan.mit.edu/ideas-made-to-matter/why-its-time-data-centric-artificial-intelligence

De Valeriola S., L’ordinateur au service du depouillement de sources historiques. ´ Eléments d’analyse semi-automatique d’un corpus diplomatique homogène.  In Histoire & Mesure, 35, 2 (2020), 171–196.

De Valeriola, S. Can historians trust centrality ? Historical network analysis and centrality metrics robustness. In Journal of Historical Network Research 6 (2021), 45–85.

Dierickx L.,  «  Apprentissage automatique : les challenges de la qualité des données dans la perspective d’une adéquation aux usages», Conférence, Groupe de contact FNRS « Analyse critique et amélioration de la qualité de l’information », ULB, mai 2022.  https://mastic.ulb.ac.be/2022/02/reunion-du-groupe-de-contact-fnrs-analyse-critique-et-amelioration-de-la-qualite-de-linformation-numerique-%EF%BF%BC/

Dierickx, L. (2019, February). Why news automation fails. In Computation+ Journalism Symposium, Miami, FL.

Gupta N, Patel H, Afzal S, et al. (2021) Data Quality Toolkit: Automatic assessment of data
quality and remediation for machine learning datasets. arXiv [cs.LG]. Available at:
http://arxiv.org/abs/2108.05935.

Northcutt CG, Athalye A and Mueller J (2021) Pervasive label errors in test sets destabilize
machine learning benchmarks. arXiv [stat.ML]. Available at: http://arxiv.org/abs/2103.14749.

Redman T. C., If Your Data is Bad, your Machine Learning Tools are useless. Harvard, Business Review, avril 2018. https://hbr.org/2018/04/if-your-data-is-bad-your-machine-learning-tools-are-useless.

Sgaier S. et al., The Case for Causal AI, Stanford Innovation Social Review, summer 2020. https://ssir.org/articles/entry/the_case_for_causal_ai

Van Der Vlist, E. 2011. Relax NG. Mai 2011. Édition O’Reilly Media. ISBN: 0596004214

Dit is een ingezonden bijdrage van Isabelle Boydens, Data Quality Expert, Research Team en Gani Hamiti, Data Quality Analist, Databases Team. Dit artikel is geschreven onder hun eigen naam en heeft geen invloed op het standpunt van Smals. Het werd vertaald uit het Frans: Typologie des anomalies, un cadre pour l’action : le cas du machine learning.

(*) Data Quality Expert, Research Team

(**) Data Quality Analyst, Databases Team

Nederlandstalige versie

La qualité d’une donnée désigne son adéquation aux usages et objectifs visés (« fitness for use ») (Boydens, 1999, Boydens 2014). Dans cet article nous allons voir comment une typologie rigoureuse des anomalies offre un cadre pour l’amélioration de la qualité des données, dans de nombreux domaines, dont le machine learning. A propos du ML, dans un article ultérieur, nous montrerons comment cette technique peut améliorer les fonctionnalités d’un “data quality tool”, par exemple dans les opérations de matching, comme annoncé dans notre article de décembre 2021.

Toute base de données relationnelle opérationnelle bien conçue repose sur une hypothèse, celle du « monde clos » : le domaine de définition spécifie l’ensemble des valeurs admises au sein du modèle ou du schéma de la base de données (les contraintes d’intégrité) ; les « règles métier » peuvent aussi se décliner dans le code applicatif et contribuer ainsi à la définition des données. En vertu de cette hypothèse, une valeur non incluse dans le domaine de définition est considérée comme erronée et doit être rejetée de la base.

Par anomalie au sein d’une base de données, nous entendons ici une erreur formelle (par exemple, valeur obligatoire non complétée) mais aussi une présomption d’erreur demandant une interprétation humaine (par exemple : présomption de doublons entre enregistrements fortement similaires, émergence d’une nouvelle catégorie d’activité non prise en compte dans les tables de référence, etc.).

Ajoutons qu’une base de données empiriques évolue dans le temps avec l’interprétation des valeurs qu’elle permet d’appréhender (Boydens, 1999, 2011, Bade, 2011). Dès lors, il n’y a jamais de projection biunivoque entre une base de données et le réel observable représenté. La qualité totale n’existe pas. Ceci rend d’autant plus complexe la mise en place d’une stratégie d’évaluation et d’amélioration de la qualité des données, en fonction de leurs usages tels le machine learning (de Valeriola, 2020, 2021), dans le domaine de la justice, de la reconnaissance faciale, du traitement des maladies ou encore du journalisme, …  appliqué à des usages eux aussi bien particuliers (Redman, 2018, Dierickx, 2022).

Citons Redman et ses exemples éloquents  :

« Yet today, most data fails to meet basic “data are right” standards. Reasons range from data creators not understanding what is expected, to poorly calibrated measurement gear, to overly complex processes, to human error. To compensate, data scientists cleanse the data before training the predictive model. It is time-consuming, tedious work (taking up to 80% of data scientists’ time), and it’s the problem data scientists complain about most. Even with such efforts, cleaning neither detects nor corrects all the errors, and as yet, there is no way to understand the impact on the predictive model. What’s more, data does not always meets “the right data” standards, as reports of bias in facial recognition and criminal justice attest.”

(…)

“Increasingly-complex problems demand not just more data, but more diverse, comprehensive data. And with this comes more quality problems. For example, handwritten notes and local acronyms have complicated IBM’s efforts to apply machine learning (e.g., Watson) to cancer treatment.”

Figure 1. Approches préventives et curatives

Outre son intérêt évident pour la qualité des données, l’étude des anomalies est également importante en raison de leur pourcentage élevé qui affecte structurellement les systèmes d’information : jusqu’à 10 % du volume des données (Boydens, 2011, Van Der Vlist, 2011). Or, quand les enjeux (humains, sociaux, financiers, juridiques, scientifiques, médicaux, etc.) le demandent, ces anomalies doivent faire l’objet d’un examen semi-automatique, voire manuel, souvent lent et fastidieux, sans programme ad hoc recourant à des mesures préventives et curatives, Figure 1, (Boydens, 2014).

La typologie que nous proposons peut être utile dans toutes les disciplines ayant recours aux Data : Database Management, Master Data Management, machine learning (Dierickx, 2022, Redman, 2018), … en tant que cadre global pour l’action Data Quality et aide à l’identification du traitement le plus approprié.

D’où viennent les anomalies, quelle en est la typologie et de là, comment les gérer au mieux ? Afin de répondre à ces questions, il convient de revenir préalablement sur la notion de donnée telle que nous l’avons posée dès 1999 et reprise notamment en 2021 (Boydens I., Hamiti G. et Van Eeckhout R., 2021).

DONNÉES DÉTERMINISTES ET DONNÉES EMPIRIQUES

Dans le monde des bases de données, une donnée est un triplet (i, d, v) composé des éléments suivants :

• un intitulé (i), renvoyant à un concept (une catégorie d’activité administrative, par exemple) ;
• un domaine de définition (d), composé d’assertions formelles spécifiant l’ensemble des valeurs admises dans la base pour ce concept (une liste contrôlée de valeurs alphabétiques d’une longueur maximale l, par exemple), complétées éventuellement de règles métier se trouvant dans le code applicatif (voir plus haut, hypothèse du monde clos).
• et enfin, une valeur (v) à un instant t (le secteur de la chimie, par exemple).

On distingue alors les données déterministes des données empiriques (Boydens, 1999, 2011).

• Les premières se caractérisent par le fait que l’on dispose à tout moment d’une théorie qui permet de décider si une valeur v est correcte ou pas. Ainsi en est-il d’une opération algébrique simple portant sur un objet lui-même déterministe, comme la somme de valeurs relatives à tel champ numérique d’une base de données à un instant t. Les règles de l’algèbre n’évoluant dans le temps, on peut savoir à tout moment si le résultat d’une telle somme est correct ou pas. On dispose en effet d’un référentiel stable à cette fin.
• En revanche, en ce qui concerne les données empiriques, sujettes à l’expérience humaine, la norme évolue dans le temps avec l’interprétation des valeurs qu’elle permet d’appréhender. Ainsi en est-il par exemple du domaine médical (où la théorie évolue au fil des observations sur les patients atteints par une pathologie, comme en témoignent les recherches actuelles sur le coronavirus) mais aussi des domaines juridiques et administratifs où l’interprétation des concepts légaux se transforme avec l’évolution continue de la réalité traitée et avec celle de la jurisprudence. Comment en évaluer la validité en l’absence de référentiel absolu à cette fin ?

TYPOLOGIE DES ANOMALIES ET TRAITEMENTS POSSIBLES

Une typologie des anomalies se profile alors, en fonction de leur cause potentielle et de la manière de les envisager :

• erreur formelle certaine : par exemple, un champ obligatoire non complété lors de l’encodage manuel des données par un humain;
• présomptions d’erreurs formelles : par exemple a) présomptions de doubles dues à des processus de capture de données redondantes en amont, ou encore b) une incohérence avec une table de référence dont on ignore si elle est à jour, par exemple dans le domaine de l’énergie renouvelable (Figure 2) ;
• erreur indétectable formellement a priori : par exemple, omission d’une mise à jour.

Figure 2. Gestion des anomalies, ATMS, Monitoring & Back tracking

Les deux derniers cas de figure de la typologie qui précède peuvent dénoter de cas d’anomalies dues à l’évolution dans le temps du domaine empirique représenté et à l’émergence de nouveaux concepts non pris en compte (Figure 2). Par exemple : un test d’intégrité avant l’entrée des données dans la base de données principale détecte une anomalie formelle. Le traitement de l’anomalie (validation ou correction) est stocké dans l’ATMS (permettant le suivi des anomalies et de leur traitement dans le temps, comme indiqué plus loin dans cet article) et alimente un tableau de bord lequel, moyennant un monitoring des anomalies et traitements aidera à la prise de décision en vue d’améliorer la qualité des données.

Selon les besoins du métier, on décidera de considérer ces anomalies comme :

• bloquantes : elles sont rejetées de la base de données en vertu de l’hypothèse du monde clos précédemment évoquée ;
• non bloquantes : les valeurs sont tout de même intégrées selon des modalités variables au sein du système d’information avec l’enregistrement correspondant, pour deux familles de raisons :
  • les rejeter du système ralentirait le processus métier (par exemple, le prélèvement des cotisations sociales) et elles ne sont pas considérées comme « stratégiques »;
  • les prendre en considération dans le système d’information est indispensable, car elles sont considérées comme stratégiques et sont liées à des données empiriques dont la définition est potentiellement évolutive. À partir d’un certain seuil à évaluer par les spécialistes du domaine, leur traitement demande une interprétation humaine, car elles peuvent dénoter de l’émergence de phénomènes nouveaux qu’il importera de prendre en considération dans le système d’information (Figure 2), moyennant une gestion de versions. En outre, elles trouvent potentiellement leur origine dans les flux alimentant la base de données, problématique qui, une fois identifiée, pourra être structurellement résolue avec le back tracking (Boydens, 2018, Boydens et al., 2021).  

La décision consistant à identifier les anomalies empiriques « non bloquantes » est sensible en ce qu’elle relève d’une connaissance prévisionnelle des réalités traitées à un instant t, élément lui-même évolutif susceptible de faire l’objet d’une adaptation concertée au sein du système d’information. Ceci nous renvoie à la question épistémologique de la « boucle herméneutique »

La démarche herméneutique consiste à envisager les phénomènes empiriques en termes d’interactions par rapport à un cadre conceptuel plus général construit en vue de leur conférer un sens. Cependant, toute démarche interprétative soulève un paradoxe : celui du « cercle herméneutique » (Aron, 1969). Chaque observation ne prend sens que confrontée à un ensemble, à une « précompréhension ». Or, la sémantique de l’ensemble repose elle-même sur l’interprétation des éléments qui le constituent. Le processus de construction que suppose l’herméneutique est par nature toujours inachevé. Il convient toutefois d’y poser ponctuellement un arrêt en connaissance de cause afin de livrer des résultats provisoires (Boydens, 1999).

Comment prendre en considération les « anomalies non bloquantes » et leurs traitements, sans affecter ni la performance, ni l’intégrité des données en production ? Avec l’ATMS, ou Anomalies and Transactions Management System (Boydens et al., 2021) – éventuellement couplé aux Data Quality Tools (Boydens et al, 2021b) – associé au Back Tracking (Boydens, 2018), on passe de « l’hypothèse du monde clos » à celle d’un « monde ouvert » sous contrôles automatisés au sein des bases de données de gestion. Et l’on bâtit, ce faisant un programme consolidé permettant d’évaluer la qualité des données et d’y remédier structurellement. Ce programme n’est jamais un « one shot » car il doit être mené dans la continuité, incluant un processus de maintenance. 

APPLICATION AU MACHINE LEARNING : PERSPECTIVES

Avant la mise en place du cycle de ML

Dans le cas du machine learning (de Valeriola, 2020, Dierickx, 2019, 2022), le programme (analyse et solutions associées) – exposé plus haut dans cet article de blog – peut s’appliquer en amont aux données mobilisées pour entraîner un modèle prédictif et en assurer la maintenance dans le temps avant la mise en place du cycle de ML.

Au coeur du cycle de ML (Figure 3)

Au coeur du système de ML, on peut construire les indicateurs de qualité adéquats aux algorithmes et modèles de ML choisis, par exemple, indicateurs de la qualité : 

• des annotations potentiellement obtenues par crowdsourcing, dans le cas de modèles supervisés (Northcutt et al, 2021, Gupta et al, 2021)
• des biais (ou marges d’erreur) tolérés ou pas selon les usages déterminés en synergie avec l’IT et le business (concepteurs des données, utilisateurs du modèle prédictif).

Le système préconisé dans (Gupta et al, 2021) pourrait être enrichi en ayant recours à un ATMS à la source, comme mentionné plus haut et par ailleurs, suggère d’agir sur la qualité de données déjà pré-traitées pour le ML.

Cette référence illustre la problématique de données de qualité insuffisante au sein du modèle de ML. Par exemple, la mauvaise distribution d’un attribut peut constituer un biais qui, à son tour, soulèvera des problèmes éthiques : dans le cas de l’évaluation des demandes de crédit en fonction du risque, en cours d’examen par l’UE en septembre 2022 : “… les algorithmes peuvent comporter des biais. Par exemple, un modèle est susceptible de refuser fréquemment un crédit aux individus de 30 ans et jamais aux personnes de 57 ans. Pourquoi ? Simplement parce que les dossiers des trentenaires étudiés par la machine lors de son entraînement étaient nombreux, donc la probabilité d’y trouver des défauts également, alors qu’il n’y avait qu’un ou deux exemples de candidats de 57 ans et qu’ils ont à chaque fois payé l’intégralité de leur crédit (une erreur toutefois si grossière qu’elle est généralement anticipée, mais d’autres biais peuvent être plus pernicieux).“

Figure 3. Source : Dierickx, 2022

L’explicabilité des prédictions du ML : législations, questions éthiques et de data quality, nouveaux domaines de recherche

Dans d’autres cas évoqués par l’UE, l’opacité des modèles d’apprentissage profond est telle que même les ingénieurs ne peuvent plus motiver précisément les prédictions produites en résultat.

Une loi est en cours de préparation pour tenter de réguler les procédures utilisées, l’AI Act, censé renforcer le RGPD. S’agissant de procédures analogues aux demandes de crédit, les experts estiment que “Cela ne veut pas dire pour autant que les explications données seront sûres et certaines (impossible avec certains modèles), mais qu’elles seront fortement probables – des ingénieurs parlent d’ailleurs plus d’interprétabilité que d’explicabilité.” 

Le programme évoqué plus haut (ATMS, data quality tools) avant le cycle du ML, couplé à la prise en compte d’une évaluation de la qualité au coeur du processus de ML, le tout devant être documenté, pourrait s’appliquer aussi afin de donner plus d’informations ciblées aux utilisateurs des données prédictives sur “l’explicabilité” et la qualité relative de ces dernières, la qualité totale n’existant pas.

De nouveau domaines de recherche se présentent peu à peu dans ce sens : Data Centric AI ou encore, Causal AI. La problématique se pose donc en amont, au coeur et en aval du cycle de vie des données en ML. 

A propos du ML, dans un article ultérieur, nous montrerons par ailleurs, comment cette technique peut améliorer les fonctionnalités d’un “data quality tool”, par exemple dans les opérations de matching, comme annoncé dans notre article de décembre 2021.

Références

Aron, R., 1969. La philosophie critique de l’histoire. 1969. Édition Librairie philosophique J. Vrin. Collection Points – Sciences humaines. ISBN 2560848158182.

Bade D., It’s about Time!: Temporal Aspects of Metadata Management in the Work of Isabelle Boydens. In Cataloging & Classification Quarterly (The International Observer), volume 49, n° 4, 2011, pp. 328-338. (lien vers l’article).

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).  (Introduction et Première partie, pp. 30-126) – bibliothèques

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

Boydens I., Dix bonnes pratiques pour améliorer et maintenir la qualité des données. Bruxelles, Smals, Research Section, post de blog, 16/06/2014 (dernière mise à jour :  décembre 2021). /dix-bonnes-pratiques-pour-ameliorer-et-maintenir-la-qualite-des-donnees/

Boydens I., «  Data Quality & Back Tracking : depuis les premières expérimentations à la parution d’un Arrêté Royal  ». Bruxelles, Smals, Research Section, post de blog, 14/05/2018./data-quality-back-tracking-depuis-les-premieres-experimentations-a-la-parution-dun-arrete-royal/ 

Boydens I., Hamiti G. et Van Eeckhout R., Data Quality : “Anomalies & Transactions Management System” (ATMS), prototype & “work in progress”. Bruxelles, Smals, Research Section, post de blog,  8/12/2020. 

/data-quality-anomalies-transactions-management-system-atms-prototype-work-in-progress/

Boydens I., Hamiti G. et Van Eeckhout R., Un service au cœur de la qualité des données. Présentation d’un prototype d’ATMS. In Le Courrier des statistiques, Paris, INSEE, juin-juillet 2021, n°6,  p. 100-122.

https://www.insee.fr/fr/information/5398691?sommaire=5398695

Boydens I., Corbesier I. et Hamiti G., Data Quality Tools : retours d’expérience et nouveautés. Bruxelles, Smals, Research Section, post de blog, 07/12/2021. /data-quality-tools-retours-dexperience-et-nouveautes/

Brown S., Why it’s time for “data Centric Artificial Intelligence” ? MIT Management Sloan School, juin, 2022. https://mitsloan.mit.edu/ideas-made-to-matter/why-its-time-data-centric-artificial-intelligence

De Valeriola S., L’ordinateur au service du depouillement de sources historiques. ´ Eléments d’analyse semi-automatique d’un corpus diplomatique homogène.  In Histoire & Mesure, 35, 2 (2020), 171–196.

De Valeriola, S. Can historians trust centrality ? Historical network analysis and centrality metrics robustness. In Journal of Historical Network Research 6 (2021), 45–85.

Dierickx L.,  «  Apprentissage automatique : les challenges de la qualité des données dans la perspective d’une adéquation aux usages», Conférence, Groupe de contact FNRS « Analyse critique et amélioration de la qualité de l’information », ULB, mai 2022.  https://mastic.ulb.ac.be/2022/02/reunion-du-groupe-de-contact-fnrs-analyse-critique-et-amelioration-de-la-qualite-de-linformation-numerique-%EF%BF%BC/

Dierickx, L. (2019, February). Why news automation fails. In Computation+ Journalism Symposium, Miami, FL.

Gupta N, Patel H, Afzal S, et al. (2021) Data Quality Toolkit: Automatic assessment of data
quality and remediation for machine learning datasets. arXiv [cs.LG]. Available at:
http://arxiv.org/abs/2108.05935.

Northcutt CG, Athalye A and Mueller J (2021) Pervasive label errors in test sets destabilize
machine learning benchmarks. arXiv [stat.ML]. Available at: http://arxiv.org/abs/2103.14749.

Redman T. C., If Your Data is Bad, your Machine Learning Tools are useless. Harvard, Business Review, avril 2018. https://hbr.org/2018/04/if-your-data-is-bad-your-machine-learning-tools-are-useless.

Sgaier S. et al., The Case for Causal AI, Stanford Innovation Social Review, summer 2020. https://ssir.org/articles/entry/the_case_for_causal_ai

Van Der Vlist, E. 2011. Relax NG. Mai 2011. Édition O’Reilly Media. ISBN: 0596004214

Ce post est une contribution d’Isabelle Boydens, Data Quality Expert, Research Team et de Gani Hamiti, Data Quality Analist, Databases Team. Cet article est écrit en leur nom propre et n’impacte en rien le point de vue de Smals.

(*) Data Quality Expert, Research Team

(**) Data Quality Analyst, Databases Team

La problématique de la qualité des données (ou “fitness for use“, adéquation aux usages) est maintenant reconnue au plan international comme étant un facteur de succès à prendre en compte dans tout projet impliquant des bases de données. En 2016, T. Redman chiffrait ainsi les coûts de la “non qualité” aux USA, dans son livre “Getting in front on Data” (p. 25) : “$3,1 Trillions/year in the US, which is about 20 percent of the Gross Domestic Product”. 

Les “data quality tools” professionnels et commerciaux sont nés dans les années 1980 avec la nécessité pour les entreprises du monde entier de disposer de fichiers d’adresses et de coordonnées précises concernant leurs clients et transactions. Avec le temps, ces outils ont pris un essor considérable, tant du point de vue de l’ampleur des domaines couverts, traitant tout type de chaîne alphanumérique, que des dizaines de milliers d’algorithmes “ad hoc” développés à cette fin. Vu le caractère stratégique de la qualité des données dans les entreprises, organismes internationaux et administrations, la recherche est très active dans le domaine et de nouveaux algorithmes sont régulièrement proposés et intégrés dans ces outils. Pour ces raisons, dans un cadre professionnel, on peut difficilement leur substituer un développement “home made” et leur acquisition est recommandée en vue d’une approche “data quality” sérieuse et complète. 

Aussi, depuis plus de 10 ans, Smals a acquis un “Data Quality Tool” professionnel, toujours parmi les leaders du marché à l’heure actuelle, dans le cadre de son Data Quality Competency Center. Depuis lors, plus de trente projets d’envergure ont mobilisé cet outil dans le cadre de la sécurité sociale belge et en dehors de celle-ci.

Nous proposons ici, sur la base de l’expérience acquise  : 

• de rappeler et d’illustrer les fonctionnalités les plus usitées de l’outil, ainsi que quelques bonnes pratiques;
• d’annoncer plusieurs nouveautés qui sont autant d’extensions de l’outil dans le courant de cette année 2021.

1. Retour d’expérience : une approche curative très efficace en vue de traiter les problèmes de qualité au sein des bases de données

En parallèle et en complément des approches préventives destinées à éviter en amont l’émergence de problèmes de qualité de données (“back tracking” reposant sur un ATMS, Anomalies and Transactions Management System) à propos desquelles un article de blog a été publié respectivement en 2018 et en 2020 ainsi qu’un article scientifique édité à Paris par le Courrier des Statistiques (Paris, INSEE, juillet 2021), les “data quality tools” représentent une approche curative très efficace pour traiter les anomalies déjà présentes dans les bases de données (Figure 1).

Figure 1. Approches curatives et préventives.

Celle-ci est destinée à l’amélioration semi-automatique de la qualité des données :

• on the fly, “online”, par exemple dès la saisie d’un enregistrement dans le système (approche API, voir point relatif aux nouveautés)
• en batch, par exemple en traitant périodiquement l’entièreté d’une ou plusieurs tables dans une base de données préexistante ou un ATMS .

Généralement, les data quality tools couvrent une à trois des grandes familles de fonctionnalités présentées ici, l’outil acquis par Smals incluant les trois dans le cadre d’une suite comportant un grand nombre d’algorithmes de traitement de données génériques ou “ad hoc”. 

Ceci est fondamental car l’expérience montre que ces trois fonctionnalités (Figure 2) sont interdépendantes de manière cyclique et itérative en synergie avec le business (qui doit être impliqué aux côté de l’IT, s’agissant d’un outil commercial demandant une importante courbe d’apprentissage). Nous les présentons brièvement :  

Figure 2 : Profiling, standardisation et matching : les trois familles de fonctionnalités majeures et itératives. 

• profiling : analyser qualitativement et quantitativement des données pour en évaluer la qualité, isoler ou quantifier des problèmes déjà connus mais dont l’ampleur n’a jamais été évaluée et, souvent, débusquer automatiquement et semi-automatiquement des problèmes inattendus. Exemple : distribution de la longueur des valeurs d’une colonne, inférence de type, vérification ou découverte de dépendances fonctionnelles ;
• standardisation : transformer les données en vue des les conformer à un standard défini avec le business ou à un référentiel existant (“data cleansing”), pouvant être fourni avec l’outil. Exemple : nettoyage et uniformisation de la représentation des numéros de téléphone, correction, enrichissement et validation d’adresses postales. L’outil acquis par Smals est particulièrement puissant dans cette dernière fonctionnalité qui couvre la Belgique et est en voie d’extension (voir nouveautés ci-dessous) ;
• comparaison, détection d’incohérences et dédoublonnage, via des algorithmes de matching (qui se déclinent en familles bien spécifiques sur le plan théorique) : détecter les duplicats et incohérences dans les enregistrements au sein d’un jeu de données ou entre plusieurs (issus potentiellement de bases de données distinctes, en vue d’une intégration ou dans le cadre d’un reengineering, par exemple). La comparaison se base sur des colonnes discriminantes et des algorithmes tolérants à l’erreur (mesure de la distance d’édition, comparaison de l’empreinte phonétique, etc.), déterminés avec le business. Les outils les plus avancés permettent ici de conserver et lier les enregistrements originaux pertinents (après validation par le Business) sans les écraser. Les meilleures valeurs identifiées pour chaque colonne serviront à construire le «survivor » ou « golden record », représentant chaque grappe ainsi repérée et utilisé pour dédoublonner le(s) jeu(x) de données si nécessaire. Notons que la problématique est telle que les règles d’établissement d’un “golden record” sont formalisées dans la loi ou dans des règlements administratifs pour certaines sources authentiques, telles que le Registre National ou la Banque Carrefour des Entreprises belges, par exemple. Enfin, vu le nombre de records à comparer entre eux et d’opérations associées, des mécanismes de gestion de la performance (“blocking” ou “windowing“) doivent être utilisés de manière itérative dans les opérations de matching d’envergure. 

Deux points importants :

• les fonctionnalités de “drill down” de l’outil permettent un échange aisé entre l’IT et le business quand des enquêtes intellectuelles doivent être réalisées sur des résultats donnés, comme le montrent les fonctionnalités de la figure 2, le drill down s’appliquant aussi au matching. 
• tout projet “data quality” doit être documenté, à différents niveaux de granularité, en fonction du public (IT ou business) visé ; cela vaut donc bien sûr pour les projets reposant sur des data quality tools.

Typiquement, ces outils interviennent en « batch », c’est-à-dire en ciblant, en différé, un ou plusieurs jeux de données déjà existants. Certains permettent cependant également d’intervenir plus en amont, en exposant ces fonctionnalités sous la forme d’une API que l’application peut appeler au cas par cas au moment où les données entrent dans le système. Nous revenons sur cette fonctionnalité au point suivant car il s’agit d’une nouveauté qui est en cours de standardisation dans la suite des fonctionnalités dont dispose Smals en complément du batch (Figure 3).

Figure 3. Data Quality Tool : approche batch

2. Nouveautés

2.1. Une REST API standardisée

La suite de fonctionnalités Batch, fondamentale pour les gros volumes de données, est maintenant complétée par une REST API développée en 2020 et en cours de standardisation en 2021 (Figure 4). Celle-ci permet de transformer des valeurs en vue de les conformer à un standard défini (“data cleansing”), de détecter des incohérences ou de dédoublonner les données avant leur écriture dans la base et même, si besoin, de conditionner cette écriture par la réussite des opérations qui la précèdent. L’outil implémente ainsi effectivement un pare-feu de données complémentaire au système de détection d’anomalies déjà mis en place par l’application. L’API est par exemple utile pour la standardisation de numéros de téléphone, la validation d’adresse ou la vérification de l’existence de duplicats dans une base de données avant l’insertion d’un nouveau record. L’API dataQualityImprovment est documentée sur l’ict-reuse, au fil de son enrichissement. 

Figure 4. Data Quality Tool : REST API standardisée

2.2. Une extension de la fonctionnalité de validation d’adresses à l’international via OpenStreetMap

Une autre nouveauté en 2021 réside dans l’extension de la fonctionnalité de correction et de validation d’adresses. Particulièrement puissante pour la Belgique dans le Data Quality Tool dont dispose Smals, cette fonction est en cours d’extension pour inclure désormais les adresses internationales via OpenStreetMap, outil de cartographie Open Source et collaboratif pour lequel une API a été développée au sein de la section Recherche.

La qualité des adresses traitées avec ce nouveau module pourra, selon les cas, être moindre que celle concernant les adresses belges, et la performance sera variable en fonction des projets. Cela dit, ce développement n’en demeure pas moins très intéressant pour toutes les bases de données incluant des adresses étrangères et demandant un traitement Batch ou via une REST API en ayant recours aux fonctionnalités du data quality tool évoquées plus haut. 

La possibilité d’intégrer les données issues d’OpenStreetMap à l’outil dont dispose Smals permet également d’envisager, à moyen terme, la mise en place d’un service de géocodage en complément des fonctionnalités déjà existantes.

2.3. Data quality et machine learning

Dans un futur proche, les liens entre les “Data Quality Tools” et le Machine Learning seront envisagés pratiquement, notamment pour répondre aux deux questions suivantes :

• Comment améliorer la qualité des “Big Data” en amont afin de rendre les résultats du ML plus adéquats aux attentes des utilisateurs ? Les données alimentant les modèles de ML se distinguent souvent tant par leur volume que par une certaine tolérance aux données aberrantes ; la qualité des données reste cependant un composant critique dans la construction de modèles fiables et durables.
• Comment le ML peut-il enrichir le résultat de certains algorithmes au coeur des “Data Quality Tools” au regard du “fitness for use” ? L’approche déterministe a l’avantage de fournir des résultats relativement prévisibles mais requiert une connaissance préalable des conditions précises auxquelles une opération (par exemple un “match” positif) peut avoir lieu ; il pourrait être intéressant d’étudier dans quelle mesure le recours à des algorithmes “apprenant” eux-mêmes ces conditions pourrait contribuer à des résultats encore plus précis.

En conclusion, le service Data Quality chez Smals ne cesse de s’étendre et les applications concrètes abondent. Un point de contact unique existe désormais pour toute question ou demande relative à ce sujet : dataquality@smals.be

Ce post est une contribution collective d’Isabelle Boydens, Data Quality Expert chez Smals Research, Isabelle Corbesier et Gani Hamiti, Data Quality Analysts chez Smals, Databases Team. Cet article est écrit en leur nom propre et n’impacte en rien le point de vue de Smals.

Gani Hamiti donnera un cours-conférence à l’ULB le 13 mars 2019 de 18 heures à 20 heures, suivi d’une réception.

Dans le cadre du cours STIC-B-510 « Qualité de l’information et des documents numériques » de la filière STIC de l’Université libre de Bruxelles, Gani Hamiti, Data Quality Analyst chez Smals, donnera un cours-conférence intitulé « Data Quality Tools : concepts and practical lessons from a vast operational environment ».

L’événement aura lieu le mercredi 13 mars 2019 de 18 heures à 20 heures à l’Université libre de Bruxelles. L’exposé sera suivi d’une séance de questions-réponses ainsi que d’une réception.

Celui-ci s’adresse à un public multidisciplinaire. Le cours-conférence abordera, d’une part, l’analyse critique et l’amélioration de la qualité des bases de données auxquelles peuvent être confrontés des utilisateurs non-informaticiens.  D’autre part, plusieurs fonctionnalités avancées des « data quality tools », parmi les plus élaborées à l’heure actuelle et parfois méconnues de la communauté IT, seront évoquées dans le cadre d’une approche rigoureuse reposant sur une expérience et des exemples concrets.

Le cours-conférence ainsi que l’orateur seront brièvement présentés par Isabelle Boydens, titulaire du cours STIC-B-510, Professeur à l’Université libre de Bruxelles et Data quality Expert au sein du Département « Recherche » de Smals.

Vous trouverez sur le site web du Master en Sciences et Technologies de l’Information et de la Communication de l’ULB toutes les informations pratiques concernant le lieu, l’organisation ainsi que l’abstract de l’exposé et la biographie de l’orateur.

Certaines parties de cet article, plus techniques, seront masquées. Si les détails vous intéressent, il vous suffira de cliquer sur les liens « Cliquer ici pour plus de détails », ou de cliquer ici pour montrer toutes les parties d’un seul coup.

Supposons qu’un organisme public soit responsable de la gestion de la sous-traitance entre entreprises, et que, chaque fois qu’une entreprise fait appel à un sous-traitant, elle doive le déclarer auprès de cet organisme. Les données issues de ces déclarations peuvent alors être vues comme un graphe, dans lequel un nœud représente une entreprise, et une relation entre deux nœuds A et B, le fait que B est un sous-traitant de A. Si A sous-traite auprès de B, et B auprès de C, on notera cela de la façon suivante (en s’inspirant de la notation de Cypher, langage de Neo4j) :

(A)-->(B)-->(C)

Imaginons une loi (un peu simpliste et fantaisiste) disant qu’une entreprise ne peut pas être sa propre sous-traitante, ni directement, ni indirectement. Les structures suivantes seraient donc considérées comme « frauduleuses » :

(A)-->(A)
(A)-->(B)-->(C)-->(A)

Du point de vue de la théorie des graphes, on veut en fait s’assurer qu’il n’y a pas de cycle dans le graphe de description des sous-traitances, graphe étant dirigé, puisque les arcs ont une direction. On parle dès lors de « Graphe Dirigé Acyclique » (DAG). Le schéma ci-dessous montre une structure acceptable, dans laquelle aucune entreprise n’est son propre sous-traitant, même indirectement.

En Cypher (dont la syntaxe a été brièvement présentée dans notre article précédent), en supposant que les entreprises soient de type « Company », et les relations de type « Subcontractor », on pourra écrire la requête suivante, qui retournera une entreprise, et le cycle dont elle fait partie :

(1)    MATCH p=(a:Company)-[:Subcontractor*]->(a)
       RETURN a, p

Pour des raisons de performances, il sera souvent préférable de limiter la longueur des cycles : (a:Company)-[:Subcontractor*..5]->(a).

Qualité des données

Supposons maintenant que le système de déclaration ne soit pas très contraignant, et que, quand une entreprise déclare une sous-traitance, elle ne soit pas obligée de donner un identifiant officiel de l’entreprise en question (un numéro d’entreprise ou d’employeur attribué par l’état), mais puisse se contenter d’en donner le nom, et éventuellement l’adresse. On peut donc avoir une situation dans laquelle (A) déclare correctement sa sous-traitance vers (B) (c’est-à-dire avec un numéro d’entreprise officiel), idem pour (B) envers (C), mais par contre, (C) déclare sa sous-traitance vers (A) sans en préciser l’identifiant, mais uniquement le nom. On aura dans la base de données associée à la déclaration, deux nœuds, avec les attributs suivants :

• (A) : ID : 12345, Nom : « Mon Entreprise SA »
• (A’) : ID : <vide>, Nom : « Mon Entreprise SA »

L’organisme récoltant les données n’a ici aucun moyen de s’assurer que les entreprises (A) et (A’) sont en fait la même entreprise. Il existe des multitudes de synonymes d’entreprise. On trouve des « Coiffeur Rolland » dans bon nombre de villes, et les boulangeries « La baguette dorée » sont légion.

La cycle ci-dessus devient alors une chaîne (non fermée) : (A)–>(B)–>(C)–>(A’) , et la recherche évoquée plus haut ne permet plus de détecter le comportement frauduleux.

L’approche classique

Une approche classique de ce problème consiste à utiliser des outils de « Data Quality » (comme l’outil open-source OpenRefine, ou le logiciel commercial Trillium aux fonctionnalités beaucoup plus avancées), pour, en fonction de critères définis, fusionner certains enregistrements de la base de données. On peut par exemple décider que si on trouve deux enregistrements avec exactement le même nom d’entreprise, se trouvant dans la même rue, on les fusionne en considérant qu’il s’agit de la même entreprise. On peut par ailleurs décider que si les deux noms sont similaires, mais ont la même adresse, alors on les fusionne également.

Les outils, en particulier les suites professionnelles comme Trillium, permettent de définir finement le degré de proximité que l’on acceptera entre deux dénominations ou adresses (ou, plus généralement, toute information) pour les considérer comme « identiques » (on ne va pas uniquement considérer des chaînes de caractères exactement identiques). Par ailleurs, nous n’évoquons ici que la problématique de la détection de (présomption de) doublons : le domaine de la « Data Quality » s’intéresse à bien d’autres aspects : incohérence de données, comparaison entre différentes sources, profilage des données, standardisation…

Notons qu’on va souvent effectuer cette fusion non pas dans les données de production, mais dans une copie servant à faire des analyses et des recherches de fraude.

Mais cette approche, très efficace dans de nombreuses situations, a principalement deux limites :

• Elle permet de fusionner des informations tabulaires plates (une entreprise avec un nom, une adresse, éventuellement une catégorie d’entreprise, le nom du gérant, voire des dates de création ou autres événements), mais est plus complexe pour des structures plus élaborées. On s’en sort encore sans trop de dommages si on considère que chaque entreprise peut avoir plusieurs adresses (correspondant à plusieurs implantations, ou à l’historique du siège principal), mais si l’on veut considérer, en l’absence d’adresse, les travailleurs communs aux « deux » entreprises, ou les administrateurs (ou autres client, fournisseur…), cette approche relativement statique n’est plus tenable.
• Elle impose de choisir, avant l’analyse des données, les critères de fusion. Or il s’avère parfois utile de faire ce choix plus tard dans l’analyse, soit parce que, en fonction de l’analyse, on veut être plus ou moins stricte sur la façon de faire cette fusion, soit parce que, dans une analyse particulière, on veut identifier un schéma passant par plusieurs « chemin de duplicatas », n’ayant pas tous le même degré de certitude.

Nous proposons dès lors une approche qui combine à la fois les possibilités offertes par les bases de données orientées graphes (« Graph Databases ») et les outils de gestion de qualité de données (« Data Quality tools »).

Une autre approche

L’approche que nous décrivons ici permet de traiter les doublons d’entreprises, mais une approche très similaire pourra être utile pour détecter les doublons de personnes, ou de toute autre entité.

La première étape de notre approche consistera à identifier les entreprises dont le nom est identique, ou similaire (selon un niveau d’exigence que l’on peut définir). Dans cette première étape, on ne considère que le nom de l’entreprise, et pas les autres attributs (adresses, travailleurs…)

Cliquer ici pour plus de détails à propos de cette première étape.

Après ces étapes de nettoyage, toutes les entreprises (ou plus précisément tous les enregistrements d’entreprise) dont le nom est considéré comme identique ou presque, seront regroupées (mais pas fusionnés). Dans notre base de données, on créera alors un nœud d’un nouveau type (nous avions déjà implicitement un type de nœud « Company »), que nous appellerons « Denomination_group »

Gestion des adresses

En parallèle avec cette gestion de dénomination, il s’agira également de traiter les adresses dont on dispose pour une entreprise. Il peut s’agir d’une seule adresse, mais également de plusieurs adresses par entreprise, soit parce que celle-ci dispose de plusieurs sites, soit parce que l’on dispose de l’historique des adresses.

Cliquer ici pour plus de détails à propos de la qualité des adresses

Une fois les adresses normalisées, on va considérer dans notre base de données un nœud par rue, et un lien (avec en attribut le numéro de la boite) entre une entreprise et la rue où celle-ci a un siège.
Nous pourrions éventuellement considérer un nœud par adresse (et non par rue), mais cela fera exploser le nombre de nœuds, et donnera moins de souplesse par la suite, comme nous le verrons plus loin.

Autres liens

On peut imaginer qu’un organisme dispose d’autres informations. Par exemple, un système dans lequel les entreprises doivent déclarer leurs travailleurs, et où le contrôle au niveau de l’entreprise est faible (ce qui est typiquement le cas des travailleurs « détachés », ayant leur employeur dans un pays A, mais travaillant – généralement temporairement – dans un pays B. Ils doivent alors être déclarés dans le pays B, mais qui peut alors difficilement imposer un système d’identification standardisé).
Dans de tels cas, on pourrait utiliser les travailleurs comme entités supplémentaires. On peut aussi se servir des administrateurs ou des gérants si l’on dispose de ce type d’information.

Combiner noms et adresses

Considérons maintenant plusieurs enregistrements dans notre base de données de sous-traitance. Nous supposons que « Ma Société » a déménagé, on trouve donc des données à deux adresses différentes :

On aura dans notre base de données graphes trois nœuds « Company » : (-, « Ma société S.A »), (-, « MA SOCIETE »), et (1234, « Ma Société »), et deux rues : « Avenue Fonsny » et « Boulevard Industriel » (nous supposons que les adresses ont été normalisées au préalable), comme on peut le voir dans la figure ci-dessus.

Les versions nettoyées des trois sociétés donnent la même chaîne de caractères, et seront regroupées autour d’un nœud « Denomination_group », comme le montre le schéma ci-dessus.

On pourra maintenant rechercher un cycle entre deux compagnies A1 et A2, avec de forts soupçons de doublons.

(2)    MATCH
      (A1:Company)-[:Subcontractor*]->(A2:Company),
      (A1)-->(:Denomination_group)<--(A2),
      (A1)-->(:Street)<--(A2)
      RETURN …

La première ligne indique donc qu’il y a un chemin de sous-traitance entre A1 et A2 ; la seconde que A1 et A2 portent le même nom (après nettoyage, ou éventuellement après application d’un algorithme tel que la distance de Levenshtein), et la troisième que A1 et A2 sont renseignées dans la même rue.

Dans le schéma ci-dessus, la requête (1) plus haut aurait retourné la chaîne

(C1)–>(C2)–>(C3)–>(C1).

La requête (2) retournera quant à elle

(C10)–>(C3)–>(C1)–>(C2)–>(C9),

avec D1 comme nœud « Denomination_group » et S1 comme « Street », A1 et A2 correspondant respectivement à C10 et C9.

Cliquer ici pour plus de détails à propos des adresses identiques

(2bis) MATCH
      (A1:Company)-[:Subcontractor*]->(A2:Company),
      (A1)-->(:Denomination_group)<--(A2),
      (A1)-[str1:Address]->(:Street)<-[str2:Address]-(A2)
      WHERE str1.NUMBER = str2.NUMBER
      RETURN …

On peut aussi imaginer que l’on va considérer comme fortement suspect deux entreprises de même nom, ayant un même sous-traitant (sans considérer les adresses, qui pourraient être souvent manquantes) :

(3)     MATCH
       (A1:Company)-[:Subcontractor*]->(A2:Company),
       (A1)-->(: Denomination_group)<--(A2),
       (A1)- [:Subcontractor]->(B:Company)<- [:Subcontractor]-(A2)
        RETURN …

Cette requête retournera alors

(C6)–>(C1)–>(C2)–>(C3)–>(C4),

C5 correspondant à B, et D3 au « Denomination_group ».

Cliquer ici pour voir comme gérer plusieurs duplicatas

(4)     MATCH
       (A1:Company)-[:Subcontractor*]->(B1:Company) -->(:Duplication_group)
           <-- (B2:Company)-[:Subcontractor*]->(A2:Company),
       (A1)-->(:Duplication_group)<--(A2),
       (A1)-->(:Street)<--(A2)
       RETURN …

Technique hybrides

Plutôt que de gérer la totalité des doublons dans la base de données graphes, en se servant uniquement des Data Quality tools pour corriger les adresses et détecter les homonymes d’entreprises, on peut aussi considérer une technique hybride. On peut par exemple considérer une première phase, basée sur un Data Quality tool, de fusion de tous les enregistrements qui constituent à coup sûr un doublon (ou avec un niveau de certitude choisi) : par exemple, exactement la même dénomination, exactement la même adresse (les outils avancés permettent bien sûr de faire des choses bien plus complexes que ceci, gérant des dénominations similaires plutôt qu’exactes). Nous avons par exemple dans une base de données que nous exploitons plus de 1000 fois la même entreprise décrite, avec le même nom et la même adresse (mais où le numéro d’entreprise n’a pas été déclaré).

Les données ainsi « compactées » pourront alors être intégrées dans une base de données graphe, dans laquelle on recherchera des structures de doublons plus complexes (en se servant également d’autres informations, comme les travailleurs ou mandataires communs, ou plus généralement le voisinage), ou plus faible.

On pourrait aussi utiliser les techniques décrites ci-dessus pour fusionner, directement dans la base de données graphe, tous les nœuds considérés comme des doublons. Cela permettra de simplifier les requêtes par la suite, tout en permettant de garder une certaine souplesse : on fusionnera uniquement les cas « sûrs » (selon des critères que l’on devra définir), et laissera la possibilité de considérer des doublons moins certains dans les requêtes.

Conclusion

Notre expérience dans la lutte contre la fraude nous a montré ces dernières années qu’il est primordial de tenir compte de la qualité des données sur lesquelles on travaille. Mais elle nous a aussi montré que, dans le cadre d’un travail de « datamining », traiter la totalité de la problématique de qualité en amont, dans une phase de pré-traitement, n’est pas toujours optimal. Le degré de certitude exigé peut varier d’une analyse à l’autre et une certaine souplesse peut être nécessaire dans des phases plus avancées.

Néanmoins, en aucun cas il ne sera envisageable de se passer des outils de Data Quality :

• Nous n’évoquons ici que l’aspect « détection de (présomption de) doublons » ; les outils de Data Quality ont de nombreuses autres fonctionnalités indispensables.
• Notre approche suppose que l’on est capable de déterminer que deux dénominations d’entreprises sont « considérées comme identiques », même s’il y a des différentes orthographiques ou syntaxiques. Si l’on veut pour ce faire utiliser des méthodes plus avancées que des simples distances de Levenshtein, l’utilisation d’outil adapté sera nécessaire.
• Nous supposons également que nous sommes capable d’identifier que deux adresses sont identiques, ce qui est bien plus complexe que de vérifier la similitude entre deux chaînes de caractères. Pour cette tâche, l’utilisation d’outils disposant de base de connaissance sera indispensable.

L’approche que nous proposons ici permet de combiner, pour la problématique du dédoublonnage et dans le cadre d’une analyse effectuée sur une base de données graphe, travail partiel de Data Quality en pré-traitement et analyse métier tenant compte des résultats obtenus. L’idée générale sera d’appliquer le principe de « Keep the power where it belongs » : combiner de façon optimale un outil de Data Quality (pour la comparaison de contenus textuels) et Graph Database (pour l’exploitation des relations).

En appliquant cette méthodologie sur des cas concrets, de multiples cas problématiques (c’est-à-dire des suspicions de fraude) ont pu être trouvés et soumis à divers services d’inspection, que des analyses plus classiques n’avaient jusqu’ici pas permis de déceler.

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

Les bases de données se prêtent aux métaphores financières. Ne les désigne-t-on pas souvent par le terme « banques de données » ? Elles évoqueraient ainsi un capital d’information sur lequel on peut faire des retraits à la demande. A condition que le compte soit correctement approvisionné…(*)

Vu l’actualité des enjeux soulevés, dès lors que l’information est un instrument d’action sur le réel, nous envisageons successivement ici les coûts de la “non qualité” des données, leurs causes les plus fréquentes et ensuite dix bonnes pratiques en vue d’améliorer et de maintenir dans le temps la qualité de l’information (**).

Les coûts de la « non qualité des données »

En 2016, T. Redman chiffrait ainsi les coûts de la “non qualité” aux USA, dans son livre “Getting in front on Data” (p. 25) : “$3,1 Trillions/year in the US, which is about 20 percent of the Gross Domestic Product.” Les chiffres précis et récents sont rares : pour des raisons d’image, les entreprises ne les communiquent pas volontiers publiquement … On estime que de nombreuses bases de données dans les secteurs financiers, bancaires, médicaux ou administratifs incluent en moyenne 10 % d’anomalies formelles sur la totalité des valeurs répertoriées. La qualité des données désigne leur adéquation relative aux usages et objectifs attendus (on parle de « fitness for use »). Elle relève toujours d’un arbitrage de type « coût-bénéfice ». Ces coûts peuvent être ventilés en terme :

• de frais de manpower de vérification de l’information et de traitement des incohérences;
• de traitement des plaintes, procès et réparation éventuelle des préjudices, en cas où des données dotées d’un statut juridique de force probante occasionnent un préjudice à une autre partie ;
• d’investissements humains et techniques lors d’un reengineering ou de l’introduction d’une nouvelle technologie.

Ils incluent également des paramètres critiques non mesurables :

• pertinence du service rendu (application de la législation, soin apporté aux patients, par exemple);
• crédibilité;
• stratégie à long terme.

On pourra chiffrer plus précisément les coûts et le ROI liés à une approche “qualité” lorsque l’on précise le topic abordé, comme dans l’étude “Email address reliability“.

A quoi sont dus les problèmes de « non qualité » des données ?

L’émergence toujours actuelle de problèmes dus à la « non qualité » tient principalement aux facteurs suivants :

1. Une vision à « court terme » lors de la conception d’un projet, l’accent étant trop souvent exclusivement porté sur les aspects purement  techniques, au détriment de l’analyse du domaine d’application qui est négligée (en témoignent les problèmes qu’a connue la mise en œuvre de la réforme « Obamacare » aux USA en 2013 : les blocages du portail fédéral étaient dus à une analyse insuffisante de la complexité du domaine assurantiel). Ce n’est d’ailleurs que depuis peu que la communauté purement IT s’intéresse de près à la question de la qualité de l’information.
2. Une attention insuffisante accordée :
   1. • aux usages et au partage des données (l’adage “use it or lose it” illustre le fait que la qualité de données peu utilisées et peu partagées se détériore au fil du temps)
   • • à la documentation des données et des processus
   • • à la gouvernance des données sur le long terme, pourtant indispensable en raison de la complexité de nombreux domaines d’application empiriques évolutifs (pensons aux domaines législatifs, médicaux, scientifiques, …)
   • • à la génération d’une redondance non contrôlée d’information, faute de source authentique, au sein d’une même entité : le concept de « ghost factory » (usine fantôme) désigne le temps et l’argent consacrés par une entreprise à produire des défauts et à les corriger…

Dix bonnes pratiques

En raison de l’importance  de la problématique, nous rappelons dix bonnes pratiques afin d’améliorer et de maintenir la qualité des données dans le temps.

1. Définir les objectifs et usages des données en fonction des enjeux selon le principe du «  fitness for use » évoqué plus haut : dans certains cas, une tolérance à l’erreur sera acceptable (exploitation marketing, statistique, …) alors que dans d’autres, l’ensemble du système d’information devra être traité avec la plus grande précision (en cas d’impact juridique, médical, financier, …). Dès que l’on se penche sur un domaine d’application « grandeur nature », ce travail de définition s’avère complexe et demande des choix et des arbitrages explicites. En effet, dans tout domaine d’application empirique (sujet à interprétation humaine), le système d’information est susceptible d’évoluer dans le temps avec l’interprétation des valeurs qu’il permet d’appréhender (ce sera le cas des nomenclatures des catégories d’activités d’une entreprise, par exemple, sachant que l’univers socio-économique évolue de manière continue).
2. Etablir une organisation pluridisciplinaire impliquant le management, des spécialistes du domaine d’application et des informaticiens en charge du suivi transversal de la qualité de l’information (à travers toutes les bases de données et processus inclus dans l’entreprise et impactés par les mêmes concepts). Cette organisation doit être souple et flexible. Son ampleur varie en fonction des ressources et des enjeux du domaine d’application. La mise en place d’une organisation trop lourde ne sera pas suivie d’effet et sera contre-productive.
3. Une fois les objectifs définis et l’organisation mise en place, identifier les flux d’alimentation, les processus, les champs les plus critiques au sein du système ainsi que les événements principaux susceptibles de les affecter (suppression, modification de définition, …) ; l’identifiant unique d’une entreprise ayant plus d’importance que son numéro de fax, par exemple. Une fois ces éléments identifiés, c’est sur ceux-ci que les efforts seront concentrés dans un premier temps.
4. Distinguer les bases de données de gestion des sources authentiques et dans le cadre d’une gestion collaborative des anomalies, se référer prioritairement à la source authentique et la traiter en premier lieu pour tous les concepts stratégiques identifiés (voir : J. Bizingre, J. Paumier et P. Rivière, “Les référentiels du système d’information. Données de référence et architecture d’entreprise”, Paris, Dunod, 2013). 
5. Etablir pour ceux-ci un ensemble d’indicateurs de qualité quantifiables (par exemple, nombre de valeurs absentes pour un champ, nombre de valeurs incohérentes en comparaison avec une source authentique, …), dont l’historique sera associé à la base de données et inclura la prise en compte du suivi du traitement des anomalies formelles (valeurs violant les contraintes d’intégrité de la base de données). A ces indicateurs, permettant d’assurer le suivi de la qualité, il faudra associer des objectifs à atteindre en fonction des enjeux ainsi que des mesures d’amélioration potentielles pour remédier aux problèmes « types » connus (par exemple, mieux documenter les instructions de saisie de la base de données quand des problèmes d’interprétation sont à la source d’erreurs massives). Ces mesures pourront s’enrichir avec le temps, en fonction de l’évolution du domaine et des objectifs stratégiques.
6. Prendre conscience que la définition des indicateurs, des objectifs à attendre et des solutions associées repose sur des compromis (tel que l’arbitrage entre la fiabilité de l’information et sa rapidité de sa diffusion, ou encore, entre la précision et l’exhaustivité des données, …).
7. Mettre en place des stratégies de gestion continues transversales reposant sur ces indicateurs et objectifs : 
   1. le suivi des anomalies formelles permet par exemple de détecter, dans les domaines d’application empiriques fortement évolutifs, l’émergence de nouveaux phénomènes observables demandant une adaptation régulière des contraintes d’intégrité et du schéma de la base de données en vue de diminuer le nombre d’anomalies fictives à traiter. Ainsi, en Belgique, lors de la mise en place d’une directive administrative en faveur du secteur non marchand, la question s’est posée (au regard de la réalité qui avait été progressivement appréhendée au sein de la base) de savoir s’il fallait inclure dans ce secteur les maisons de repos privées, qui en étaient a priori exclues du fait de leur finalité lucrative. Initialement considérées comme des cas erronés au regard du domaine de définition spécifiant le secteur non marchand, ces entreprises y ont finalement été intégrées après interprétation juridique (ce qui a impliqué une restructuration du schéma de la base de données). Dans ce cas, la restructuration d’une base de données résulte d’une décision humaine tendant à rendre le modèle conforme (au moins transitoirement) aux nouvelles observations. En l’absence d’une telle intervention, l’écart entre la base de données et le réel se creuserait. En effet, si l’on omet d’adapter le schéma, les anomalies correspondant à ces cas vont continuer d’apparaître et devenir de plus en plus nombreuses, nécessitant un examen manuel potentiellement lourd et susceptible de ralentir considérablement le traitement des dossiers administratifs. 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.
   2. une méthode originale de « back tracking » (inspirée du « data tracking » de Thomas Redman) permettant, sur la base d’un échantillon d’anomalies représentatives, d’en détecter l’origine à la source et d’y remédier structurellement (erreur de programmation, d’interprétation de la loi, …). Les expériences menées à ce propos ont donné le jour à un ROI très important ainsi qu’à la parution d’un Arrêté Royal, le 2/2/2017, assurant la mise en place de la méthode dans le secteur de la sécurité sociale belge. Voir en particulier l’article suivant publié en juillet 2021 dans une revue scientifique à Paris et synthétisant toute l’approche Data quality depuis ses débuts incluant les dernières nouveautés de décembre 2021 sur les “data quality tools” : Boydens I., Hamiti G. et Van Eeckhout R., Un service au cœur de la qualité des données. Présentation d’un prototype d’ATMS. In Le Courrier des statistiques, Paris, INSEE, juin-juillet 2021, n°6,  p. 100-122.
8. Pour les bases de données « legacy » incluant des erreurs (présomptions de duplicats, adresses nationales ou internationales incohérentes, …) ou les projets de migration, recourir à une approche curitative via les data quality tools (et selon les besoins, à leurs fonctionnalités de profiling, standardisation ou matching), on line (via une REST API) ou en batch, en vue de la détection semi automatique des présomptions de doubles et d’incohérences ainsi que de leur traitement. En particulier, il est conseillé de recourir tôt et fréquemment au data profiling. Il s’agit d’une approche complémentaire à l’approche “préventive” du back tracking, vue au point précédent.
9. Documenter la base de données et les indicateurs dans le temps, dont les définitions sont validées via un workflow d’approbation (dans le cadre des solutions de “case management”). Un système de documentation performant repose sur :
   1. une organisation transversale (recourant au Master Data Management et éventuellement, à des recommandations européennes, telles que ISA, Interoperability Solutions for European Public Administrations);
   2. un worklflow de validation (avec prise en compte du multilinguisme);
   3. une gestion des versions et un historique des modifications;
   4. une conception aussi économe que possible recourant au principe de l’héritage de façon à minimiser l’ampleur du travail de mise à jour manuel et le risque d’erreur;
   5. le principe du « WOPM » « Write Once Publish Many » de façon à exploiter chaque mise à jour à des fins opérationnelles (en vue de l’adaptation des contraintes d’intégrités et des tables de référence) et documentaires (en vue de la diffusion de ces mêmes mises à jour sous des formats lisibles par l’être humain);
   6. une documentation du processus de traitement des anomalies en vue de s’assurer que la base de données est mise à jour de manière homogène et cohérente.
10. Assurer une formation continue des gestionnaires et utilisateurs de la base de données, tirer les enseignements des difficultés rencontrées et communiquer les success stories. 

Une approche en vue d’évaluer, d’améliorer et de maintenir la qualité d’une base de données est nécessairement continue, itérative et sujette à adaptation dans le temps. Recourir aux dix bonnes pratiques que nous venons d’évoquer, en fonction des enjeux de l’information et des budgets disponibles, permet assurément de tendre vers cet objectif et d’en mesurer les effets.

(*) Extrait de : Boydens I., “Les bases de données sont-elles solubles dans le temps ?“. In “La Recherche”, Hors série n°9, Paris, 2002, p. 32-34.

(**) On trouvera la définition précise de concepts importants évoqués dans ce post (“données”,  “base de données”, …) dans plusieurs de nos publications antérieures, telles que : Boydens I. “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In Assar S., Boughzala I. et Boydens I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 113-130 (chapter 7). Voir aussi : Boydens I., Informatique, normes et temps. Bruxelles, Bruylant, 1999. Boydens I., “L’océan des données et le canal des normes“, In Carrieu-Costa M.-J., Bryden A. et Couveinhes P., eds, Les Annales des Mines, Series “Responsabilité et Environnement” (thematic issue : “La normalisation : principes, histoire, évolutions et perspectives”), Paris, n° 67, Juillet 2012, pp. 22-29

Cet ouvrage collectif  sur la qualité des données est inédit car il émane exclusivement de la communauté des web software developpers (Python, Perl script,  Parallel R, NLP, cloud computing,  …), web predictive analytics et architectes IT … Il compte même un  hacker parmi ses co-auteurs. Ces auteurs n’avaient a priori aucune prédilection pour l’étude des données : « In fact, I dare say that I don’t quite care for data » (p. 1). Mais, quotidiennement affectés par les problèmes de data quality dans leur job, ils ont programmé une pause entre deux lignes de code pour partager leur longue et douloureuse expérience dans les domaines d’application les plus variés :  “Bad Data …. include data that eats up your time, causes you to stay late at the office, drives you to tear out your hair in frustration. It’s data that you can’t access, data that you had and then lost, data that’s not the same today as it was yesterday…” (p. 1).

En soi, les principaux apports pratiques de cet ouvrage, en ce qui concerne le thème “Database Quality”, sont déjà connus par certains (“The ideas presented here are born from (often painful) experience and are likely not new to anyone who has spent any extended time looking at data“, p. 226). Ils sont par exemple plus largement intégrés dans l’approche opérationnelle  du Data Quality Competence Center de Smals (voir le data tracking, la gestion intégrée des anomalies, le recours aux “Data Quality Tools”, la documentation du système ou encore, la mise en place d’une organisation). S’agissant de l’egovernment, nos travaux sont synthétisés dans un ouvrage coédité à New York chez Springer en 2011 et dans un article paru aux Annales des Mines à Paris en 2012 : ils placent la question de l’évolution de l’information dans le temps au coeur de la réflexion conceptuelle,  appliquant la critique historique aux sources informatiques à des fins opérationnelles en termes de coûts-bénéfices et de gestion.

Nous présentons toutefois ici un aperçu de ce “Bad Data Handbook” et des catégories de questions qu’il aborde car il comporte au moins quatre aspects très intéressants et, en soi, particulièrement innovants  :

• les très nombreux cases studies présentés sont extraordinairement riches, inédits et variés dans des domaines d’applications stratégiques (police criminelle, marchés financiers internationaux, chimie urologique, egov, …);
• c’est la première fois que la communauté “geek” des développeurs & architectes IT aborde la question “data quality”, sujet sur lequel elle ne publie en général jamais, se concentrant essentiellement sur la complexité technique, algorithmique et mathématique;
• on y trouve une reconnaissance des impacts financiers énormes que suscite l’inadéquation des données aux usages (“non qualité”)  : “For large entreprises, this could be a multi-million dollar problem” (p. 163);
• sans aucune référence bibliographique explicite, plusieurs auteurs font preuve d’une finesse d’analyse et d’une acuité assez impressionnantes sur le plan épistémologique (certains d’entre eux ont fait leur thèse de doctorat en physique théorique, ce qui explique sans doute que K. Popper ne leur soit pas étranger).

Les apports de l’ouvrage retenus sont ici structurés en deux catégories logiquement liées et utiles non seulement pour les développeurs IT et les architectes mais aussi, la communauté des bases de données, les décideurs et utilisateurs finaux

A. “Data format, storage & infrastructure” : 5 pistes pour faciliter l’accès aux données

Avant d’aborder la qualité de l’information, … il s’agit d’abord d’accéder physiquement et logiquement aux données.  Or, notre longue expérience en “data profiling” le confirme, c’est souvent l’étape la plus fastidieuse.

Ceci est encore plus vrai dans le cadre du Web, espace ouvert, dynamique et non contrôlé : “in some (regrettably rare) cases, all the information about the data is provided” (K. Fink, p. 9); “the first, and sometimes, hardest part of doing any data analysis is acquiring the data from which you hope to extract information” (A. Laiacano, p. 69). Ceci amène les auteurs à s’interroger sur l’opacité des Media sociaux dont l’étude soulève de nombreux défis (P. Warden, How to Feed and Care for Your Machine-Learning Experts, ch. 16), qu’il s’agisse d’effectuer une “root cause analysis” des Web sites (R. Draper, Data Traceability, ch. 17) ou encore, de vérifier l’impact des données effacées, de liens en liens, sur les réseaux sociaux (J. Valeski, Social Media: Erasable Ink?, ch. 18). Cela étant dit, voici 5 pistes concrètes en vue de faciliter l’accès aux données.

1. Eviter, à la source, la production non organisée de volumineux ensembles de données stratégiques dans un format peu lisible par la machine, comme les spreadsheets. Il est très fréquent que les utilisateurs “business” utilisent de tels formats qui conviennent bien à la lecture humaine mais génèrent des “silos de données” redondants dont le traitement automatisé ultérieur est ardu. S’appuyant sur son expérience en matière de statistiques dans le domaine scolaire en Nouvelle Zélande, P. Murell propose des conseils de développement en R pour coder des données issues de tableurs dans un format réutilisable (P. Murrell, Data Intended for Human Consumption, Not Machine Consumption, ch. 3). Dans un autre chapitre appliqué au domaine de la chimie, R. Cotton plaide en faveur de processus de codage organisés, incluant contrôles et gestion des versions  (R. Cotton, Blood,Sweat, and Urine, ch. 8), proposant une cure de “Rehab for Chemists (and Other Spreadsheet Abusers)” (p. 115) et s’exclamant au passage : “Live Fast, Die Young and Leave a Good-Looking Corpse Code Repository” (p. 114).
2. Prendre en considération la variété des systèmes d’encodage hétérogènes sur le web (ASCII, différentes normes ISO, UTF, …).  J. Levy propose des conseils de programmation (“text processing “) en Python à cette fin offrant même au lecteur intéressé une série d’exercices (J. Levy, Bad Data Lurking in Plain Text, ch. 4).
3. Identifier le pattern d’organisation des sites web analysés et en conserver l’historique des versions off line en vue d’un parsing ultérieur. En raison du caractère imprévisible et dynamique de la mise à jour des sites web, cette démarche est indispensable. A. Laiacano propose plusieurs exemples de parsing et de reengineering du pattern de sites web en Python, Ajax et MATLAB scripts (A. Laiacano, (Re)Organizing the Web’s Data, ch. 5).
4. Evaluer les avantages et inconvénients des différents modèles logiques de bases de données, en fonction des usages et des modèles de coûts. Deux chapitres discutent cette question essentielle pour le stockage et l’analyse des données issues du Web. S’inspirant d’une étude des “social media”, l’un plaide en faveur d’un format simple de type “plain text” avec des flat files, lorsque les données sont volumineuses et statiques.  Ceci en facilite la préservation à long terme, la rapidité de traitement et la sauvegarde, contrairement à certaines bases de données NoSql reposant sur le MapReduce paradigm (T. McNamara, When Databases Attack: A Guide for When to Stick to Files, ch. 12).  L’autre évalue les coûts de gestion en terme de performance des différents modèles, reconnaissant la précision du modèle relationnel qui peut cependant être coûteux en terme de performance, évoquant “the Delicate Sound of a Combinatorial Explosion…” (p. 167). Il conseille un modèle en graphe qui constitue une abstraction simplifiée mais utile quand il s’agit de gérer à la fois la complexité des interactions entre données et la performance de leur gestion (B. Norton, Crouching Table, Hidden Network, ch. 13).
5. Utiliser le “cloud computing” avec prudence, en fonction du domaine d’application. Sur la base d’un exemple réaliste, les risques de perte de performance, de coûts élevés et de pertes de données, lorsque le « cloud computing » est appliqué sans précaution sont évoqués (S. Francia, Myths of Cloud Computing, ch. 14).

B. From “big data” to “long data” : 5 pistes pour faciliter l’interprétation des données

Une fois les données accédées, il s’agit de les interpréter pour les exploiter. Il est impensable d’étudier le phénomène “big data” sur le web sans prendre en considération la question historique du temps. Dans un blog publié en février 2013 par le journal Le Monde, la notion de  “long data” est préconisée pour envisager la prise en compte de l’évolution des phénomènes dans le temps. Certains changements “brutaux” et récents (étude de la surpêche, de la déforestation, du climat, …) prennent par exemple leur source dans des évolutions datant de plusieurs siècles. Mais cette étude est complexe car elle demande l’examen de l’évolution du sens des données et des mots dans le temps et dans l’espace. Dans cet esprit, citons par exemple l’application Google Ngrams, “qui vise à tracer l’historique de l’usage d’un mot depuis l’an 1500, grâce à une analyse des livres numérisés par Google Books. Évidemment, cela ne commence qu’à l’invention de l’imprimerie et le fonds n’est pas exhaustif. Mais c’est un début qui a lancé un nouveau champ d’études, la culturomique, reposant sur une analyse quantitative des termes étudiés.”

Associant le concept de « big data » à celui de « long data », voici 5 conseils relevés dans l’ouvrage en vue de faciliter l’interprétation des données.

1. Prendre en considération le caractère interdisciplinaire d’une approche « data quality », à travers des échanges permanents entre « connaissance métier » et « culture technique ».  Dans son chapitre déjà cité, “Blood, Sweat, and Urine” (Ch 8), R. Cotton présente une expérience  dans ce sens dans le domaine de la chimie urologique. Pendant une semaine, en tant que développeur IT, il a échangé son poste avec celui d’un chimiste en vue d’un apprentissage réciproque. Dans un paragraphe éloquent,« How Chemists Make Up Numbers” (p. 108),  il relate sa stupeur devant l’exigence de précision de l’approche scientifique face à la complexité du réel observable et l’importance des enjeux humains et médicaux associés. Il en tire avec humour les conclusions hypothétiques pour son propre métier d’informaticien : “They have an endless list of documents and rules on good laboratory practice, how to conduct experiments, how to maintain the instruments … The formal adherence to all these rules was a huge culture shock to me. All the chemists are required to carry a lab book around, in which they have to record the details of how they conducted each experiment. And if they forget to write it down ? Oops, the experiment is invalid. Run it again. I sometimes wonder what would happen if the same principles were applied to data scientists. You didn’t document this function. Delete. I can’t determine the origin of this dataset. Delete. There is no reference for this algorithm. Delete, delete, delete. The outcry would be enormous, but I’m sure standards would improve.” (p. 108). A l’inverse, cet échange permet à son collègue chimiste, spécialiste du domaine d’application, de tirer des “best practices” quant au traitement des données (éviter l’encodage intensif et non contrôlé sur des tableurs (cfr supra), à la source de redondance et de “data silos”, remplacer le double encodage humain et les phases de réencodage (à la source d’erreurs et coûteuses en terme de manpower) par un workflow structuré organisant tâches humaines de validation et contrôles automatisés ou encore, associer d’emblée aux données un modèle de base de données auquel correspondent des business rules, des règles de validation et une gestion des versions. L’auteur conclut : « Sometimes, technology just works…” (p. 116).
2. Adopter une approche statistique itérative face à la complexité du domaine d’application incluant des facteurs exogènes imprévus sur le Web. Dans un chapitre à propos des taux de consultation des données et du trafic sur le Web, qu’il s’agisse du “Pay per click” ou de la consultation de Wikipedia, F. Fink (It Just Me, or Does This Data Smell Funny ?, ch. 2)  montre comment aux effets saisonniers qui diminuent structurellement le taux de consultation («Superbowl Sunday” aux USA, congés scolaires, week-ends) se mêlent malicieusement des bugs dans les logs de Wikipedia qui complexifient l’interprétation des séries temporelles . On trouve un phénomène analogue dans un chapitre (J. Perkins,  “Detecting Liars and the Confused in Contradictory Online Reviews”, ch.6) consacré à l’analyse des sentiments sur le web (à propos des restaurants, par exemple) où l’auteur découvre des contradictions (apparemment intentionnelles) entre les scores (ratings) attribués et les commentaires associés qui incluent parfois des doubles négations, sources de confusion en langage naturel. Dans l’approche, l’auteur  montre comment construire un “sentiment classifier” en Python Natural Language sur la base d’un training set et d’une étude itérative en vue de détecter ces “mensonges volontaires”.
3. Face à certaines anomalies non élucidées par le modèle d’observation, ne pas hésiter à retourner sur le terrain pour réinspecter le domaine d’application (quand c’est matériellement possible). Le chapitre correspondant (P. K. Janert, Will the Bad Data Please Stand Up, ch. 7) est introduit en ces termes : “there is no such thing as bad weather – only inappropriate clothing  ; there is no such thing as bad data – only inappropriate approaches” (p. 95). L’auteur relate  plusieurs expériences d’analyse des données en industrie visant à évaluer, sous contrainte de coût, le nombre d’appels en entreprise ou encore, les critères de production des produits défectueux. Les modèles statistiques employés (courbe de Gauss, modèle de Poisson), ont chaque fois permis de détecter des exceptions qui ont requis une nouvelle inspection du domaine d’application (par exemple, au sein de la chaîne de production, des sources de destruction accidentelles n’avaient pas été intégrées dans la structure de l’échantillon). L’auteur plaide pour une approche empirique scientifique invitant à un réexamen régulier du modèle d’observation et des hypothèses associées : “It was not the data that was the problem. The problem was de discrepancy between the data and our ideas (assumptions) about what the data should be like  …  this discrepancy can lead to a form of “creative tension, which brings with it the opportunity for additional insights” (p. 104).
4. Prendre en considération le fait que des données non valides peuvent avoir, à l’insu de l’observateur, un impact (financier, par exemple) sur le réel empirique étudié. Dans certains cas, l’inadéquation des données au modèle d’observation a un impact direct sur les réalités observées (S. Burns, When Data and Reality Don’t Match, ch. 9).  Ainsi, les données sur l’état des marchés financiers diffusées sur Internet (Google Finance – Yahoo! Finance) peuvent faire, en quelques minutes, partie intégrante du marché étudié où l’on observe “a tight feedback loop where data about the state of the market affects the market (e.g. rising prices may cause people to push prices up further)” (p. 119). Même si un algorithme de « data cleansing » permet a posteriori de détecter facilement les anomalies, celles-ci ont eu, entre temps, un impact concret sur le marché. Ainsi, le cas s’est-il présenté le 6 septembre 2008, lorsque le spider de Google News a diffusé par défaut à la date du jour des données plus anciennes non datées (et en fait obsolètes) concernant la banqueroute d’une valeur cotée sur le marché.  En quelques minutes, cette information a donné lieu à des mouvements de vente massifs de la part des traders, avant que l’on ne se rende compte de l’erreur (p. 125). De tels phénomènes se sont souvent produits dans le secteur financier. Comment considérer le statut de ces données formellement erronées ex post, lorsqu’elles ont agi sur le marché réel ? D’importantes questions d’interprétation doivent être en effet abordées, lorsqu’on étudie un domaine d’application empirique critique, au sein duquel le système d’information est un instrument d’action sur les réalités qu’il représente.
5. Accepter les compromis, dans le cadre d’un double arbitrage “fitness for use” & “coût-bénéfice”. On déduira facilement des recommandations qui précèdent que la “qualité parfaite” n’existe pas (Vaisman M., The Dark Side of Data Science, ch. 15) . Dans le domaine de la police criminelle, par exemple, au sein du Chicago Police Department’s Predictive Analytics Group (B. J.  Goldstein,  Don’t Let the Perfect Be the Enemy of the Good: Is Bad Data Really Bad?, ch. 11),  les séries statistiques temporelles relatives aux appels d’urgence (“Reported Crime Information“, “Sale of Narcotics“, …) sont exploitées en vue de prévoir l’émergence de crimes par secteur géographique. Naturellement, dans la pratique, certains appels ne donnent pas lieu à la détection d’un délit (parce que les auteurs ont été prévenus entre-temps, par exemple). Ces informations sont toutefois utiles, pragmatiquement. Ainsi, le responsable du département conclut en ces termes  :  “In order to make informed strategic and tactical decisions in an environment with imperfect data, one must make compromises. … Still, I have repeatedly noted that it is better to have an informed decision built on imperfect data than to have decision built on no data at all. When one accepts that imperfection, it opens up the ability to integrate data into all supports of projects and policies” (p. 148). On trouve le même type d’analyse dans le domaine du recensement aux USA et des enquêtes réalisées par le Congressional Budget Office ou la U. S. Social Security Administration (J. A. Schwabish, Subtle Sources of Bias and Error, ch. 10).   C’est sur cette sage relativité que l’ouvrage se termine, privilégiant le pragmatisme et l’expérience à toute velléité stérile d’une représentation idéale du réel (Q. E. McCallum & K. Gleason, Data Quality Analysis Demystified: Knowing When Your Data Is Good Enough, ch. 19) :

“Things change (and break)

…

Indeed”.

Le code mort est le code devenu inutile car plus jamais utilisé dans une application.

Pourquoi du code mort ? Lors des opérations de maintenance correctives ou évolutives les développeurs (disciplinés) créent assez spontanément une nouvelle version de leur code … mais n’élimine que trop (très) peu souvent le code devenu inutile. Au mieux est-il commenté, ce qui finira de toutes façons par constituer une gêne. Autre phénomène tout aussi fréquent : la désynchronisation des commentaires d’avec le code (ou comment apparaissent des commentaires eux-mêmes morts).

Le code mort rend le code utile plus confus et plus complexe, avec comme conséquence immédiate une augmentation des coûts de maintenance.

Selon certaines études le pourcentage de code mort se situerait entre 10 et 15% pour les applications de 5 ans d’âge, et entre 30 et 40% pour les applications au delà de 20 ans d’âge.

D’autres études situent le coût d’une ligne de code autour de 3 à 4 euros, tests compris. L’éradication du code mort peut donc constituer une belle économie sur le budget de maintenance.

L’intérêt pour l’éradication du code mort est encore plus vrai et immédiat dans le cas d’une migration. Confronté par exemple à l’abandon de son mainframe (voulu ou obligé) toute organisation aurait intérêt à se poser la question de l’opportunité d’une telle opération avant de se lancer dans la migration de son code. Que ce soit par la voie d’une traduction automatisée ou par réécriture.

Dans le premier cas la facturation se faisant généralement à la ligne de code l’explication est simple. Et à supposer que la balance entre la réduction du coût de la traduction et le coût de l’éradication du code mort ne soit pas positive , ou pas assez, la justification peut être facilement trouvée dans la volonté de profiter du moment de la migration pour réduire la dette technique (dont l’éradication du code mort est une composante importante).

Dans le second cas, la qualité des documentations étant habituellement ce que nous savons tous, éliminer le code mort ne pourra être que profitable lorsqu’il s’agit de “plonger” dans le code pour en rédécouvrir la finalité. Pas de temps perdu à la redécouverte de code inutile, et pas de parasitage sur la compréhension du code utile par le code inutile.

Une opération d’éradication du code mort se doit d’être automatisée. Des outils existent pour ce faire, tel que l’outil Kris de la firme Telebig, spécialisée dans la migration de systèmes legacy. Il est possible de télécharger une version gratuite qui vous permet de situer votre code mort mais pas de l’éliminer. Il semble que la solution devrait à terme être rendue disponible en mode SaaS.

L’éradication du code mort ? Un outil de réduction des coûts, de gestion de la qualité et une source d’économie sans doute importante dans une opération de migration.