Une représentation visuelle des dimensions de la qualité des données
La qualité d’un ensemble de données est définie comme le respect de certaines exigences par différentes caractéristiques de cet ensemble. Mesurer la qualité de données, c’est donc fondamentalement comparer : comparer ce qui est et ce qui devrait être.
Dans son chapitre consacré à la gestion qualité de données, la dernière édition du DMBOK (Data Management Book Of Knowledge), donne une version des 9 dimensions qui permettent de mesurer la qualité des données. Ces 9 dimensions n’ont pas de valeur normative mais sont communément partagées par les experts du milieu. Elles ont l’avantage d’être plus « pratico-pratiques » que celles fournies dans les normes ISO-8000, ISO-25012 ou dans le modèle Strong-Wang (cf. tableau comparatif en annexe A).
Il nous semblait intéressant de donner ci-dessous une représentation visuelle des 9 dimensions de la qualité des données, qui montre simplement ce qui est comparé à quoi pour chacune des dimensions.
En effet, ces dimensions peuvent apparaître comme des concepts abstraits au premier abord : qu’est-ce qui différencie la cohérence (consistency) de l’intégrité (integrity) ? La récence (currency) de la rapidité d’obtention (timeliness) ? Nous allons voir tout cela ensemble.
1. Validité (Validity)
Mesurer la validité d’un ensemble de données consiste à évaluer si ces données elles-mêmes, ou certaines caractéristiques extraites de ces données, répondent à un ensemble de standards prédéfinis.
Les caractéristiques en question peuvent être vues comme le résultat de « réductions » appliquées aux données : le type de données (numérique, alphabétique…), le format des données (nombre de caractères, position des caractères alphabétiques…)
Les standards peuvent quant à eux être vus comme un « domaine de valeurs » autorisé pour les données ou leurs caractéristiques.
Par exemple :
- Dans une certaine organisation, le format des dates peut prendre les valeurs « jj/mm/aaaa » ou « mm/jj/aaaa » :
- La caractéristique considérée est le format des champs dates
- Elle est comparée au standard qui correspond au domaine de 2 valeurs autorisées (« jj/mm/aaaa », « mm/jj/aaaa »)
- Un SIRET est considéré comme valide s’il appartient à la l’ensemble des SIRET enregistrés au répertoire SIRENE :
- Ici, c’est la donnée brute qui est considérée (le SIRET)
- Elle est comparée au standard qui correspond à l’ensemble des 36 millions de SIRET enregistrés au répertoire SIRENE
2. Exhaustivité (Completeness)
Mesurer l’exhaustivité d’un ensemble de données consiste à évaluer si l’ensemble des données qui doivent être présentes le sont bien.
Comme le précise le DMBOK, l’exhaustivité peut être évaluée à 3 niveaux :
- Colonne / Champ : est-ce que les champs qui doivent être complétés le sont systématiquement ?
- Ligne / Enregistrement (niveau de précision plus fin) : pour un enregistrement donné, est-ce que les champs qui doivent être complétés le sont systématiquement ?
- Table / Dataset : est-ce que l’ensemble des enregistrements est présent dans la table ?
On compare donc une complétion effective à une complétion attendue.
3. Cohérence (Consistency)
Contrairement aux 2 précédentes dimensions qui comparaient les données à un référentiel externe (standards, attentes de complétion), la cohérence est une notion « inter-données » : elle consiste à comparer pour plusieurs données distinctes la façon dont ces données sont « codées ».
Par exemple, si la colonne « Nom » d’une table contient à la fois des valeurs du type « Jean Dupont », « Dupont Jean » et « Dupont », on dira que les données de la colonne « Nom » ne sont pas cohérentes. Il en va de même pour des données de type « grandeurs physiques » (pression, température…) qui seraient exprimées dans des unités différentes sans mention de ces unités. Ou encore de données de consommation d’eau relevées annuellement le 31 décembre sauf en 2024 ou elles ont été relevées le 30 juin…
NB : Cette conception de la notion de « cohérence » est celle du DMBOK dans sa dernière version (2024) : elle n’est pas universellement partagée. Le groupe de travail DAMA France / ISACA-AFAI de 2022 en donne d’ailleurs une définition qui se rapproche davantage de ce que le DMBOK 2024 appelle « intégrité ».
4. Intégrité (integrity)
Comme la cohérence, l’intégrité est une notion inter-données : elle compare plusieurs données à la lumière d’une règle qui régit la relation entre ces données. Si cette règle n’est pas respectée (la relation est défaillante), alors l’intégrité est brisée.
Le sous-concept le plus évident est celui d’intégrité référentielle, avec par exemple la règle suivante : « si une facture mentionne un client, alors ce client doit exister dans le référentiel clients ». Une mesure de l’intégrité référentielle consiste à tester cette règle en détectant les éventuels clients de la table « Factures » qui n’existeraient pas dans le référentiel clients. Ces factures seront dites orphelines.
NB : Dans son chapitre traitant de la sécurité des données, le DMBOK définit également une conception de l’intégrité des données au sens de la sécurité :
« L’intégrité caractérise ce qui est entier – protégé de toute altération, ajout ou suppression inappropriée »
Cette définition rejoint celle donnée par le groupe de travail DAMA France / ISACA-AFAI mentionné précédemment : « [L’intégrité caractérise une] donnée non corrompue ou modifiée sur son cycle de vie ». Ces définitions se focalisent sur les événements qui jalonnent le cycle de vie de la donnée, alors que la 1e définition du DMBOK ne fait que constater le résultat (une relation non respectée).
5. Ponctualité (timeliness)
Nous allons maintenant aborder les 2 dimensions temporelles de la qualité de données, qui sont étroitement liées.
La première est la « ponctualité » (traduction imparfaite de l’anglais timeliness). La ponctualité est assimilable à un délai, qui s’exprime typiquement sous la forme « J + n ».
Le DMBOK la définit comme une exigence en tant que telle : elle mesure le délai théorique entre le moment où les données sont collectées / mises à jour d’une part, et le moment où elles doivent être accessibles (à l’utilisateur ou à un système client).
Mais on peut généraliser cette notion en y adjoignant la ponctualité effective : le délai entre le moment où les données sont collectées / mises à jour et le moment où elles sont effectivement accessibles.
Ponctualité théorique et effective ne sont pas forcément égales. On peut imaginer qu’un pipeline de données soit caractérisé par une ponctualité théorique de J+1, mais que pour des raisons de volume de données traités trop conséquents, la ponctualité effective soit de J+2.
6. Fraîcheur (currency)
Contrairement à la ponctualité (notion « dynamique », c’est-à-dire focalisée sur la réponse à un événement), la fraîcheur (ou récence) est une notion statique : on évalue « à froid » l’écart entre le moment présent et la date de dernière mise à jour des données.
Une forte ponctualité (i.e. un délai d’obtention faible) n’implique pas forcément des données fraîches, et inversement.
Par exemple :
- Si l’inventaire d’un stock est réalisé annuellement le 31 décembre, même si la ponctualité des données est très élevée, les données de stock au 30 novembre suivant seront « vieilles » de 11 mois
- Inversement, dans le cas d’un data pipeline particulièrement long, mal ordonnancé et surchargé, les données d’une table d’un système aval peuvent être mises à jour toutes les heures (donc très fraîches), mais avec un retard de plusieurs jours par rapport à la date de collecte en amont (ponctualité faible)
7. Vraisemblance (reasonableness)
Les 3 dernières dimensions vont mobiliser des comparaisons entre les données et le monde réel.
La vraisemblance mesure à quel point les données sont en adéquation avec nos attentes. Ces attentes peuvent être nourries à la fois par notre expérience du monde réel, mais aussi par d’autres données.
Par exemple, un élève de 19 ans dans une classe de CM1 peut constituer une donnée non vraisemblable à la fois selon notre « sens commun » et selon la distribution des âges des élèves de CM1.
La notion de vraisemblance est proche de celle de validité, dans le sens où elle compare les données à des standards / attentes préexistantes, mais les attentes sont plus malléables que les standards : typiquement, là où des données non valides seront tout simplement rejetées, des données non vraisemblables étonneront et devront faire l’objet d’une analyse, qui amènera potentiellement à la révision des attentes elles-mêmes.
8. Unicité (uniqueness)
Mesurer l’unicité consiste à s’assurer qu’aucun objet du monde réel n’est représenté plus d’une fois dans un ensemble de données. On cherche donc in fine à comparer deux à deux les objets du monde réel, et non directement les données elles-mêmes.
Ainsi la recherche de doublons d’enregistrements (deux enregistrements d’une table pour lesquels tous les champs auraient la même valeur) n’est qu’une partie de la mesure de l’unicité d’un ensemble de données : celle-ci passe aussi par la recherche de quasi-doublons (enregistrements d’une table pour lesquels une majorité de champs auraient la même valeur), ou encore par l’investigation des doublons de clé primaire (qui constitue aussi une rupture d’intégrité).
9. Exactitude (accuracy)
Enfin, l’exactitude est peut-être la dimension la plus intuitive à conceptualiser, mais aussi la plus coûteuse à mesurer : il s’agit tout simplement d’évaluer si la donnée représente bien un objet du monde réel.
La difficulté de la mesure réside dans l’essence de la comparaison, qui mobilise deux concepts « non miscibles » : d’une part de la donnée, et d’autre part un objet du monde réel. Pour confirmer l’exactitude d’une donnée, il est donc impératif de reproduire la collecte à partir du monde réel (c’est par exemple le principe d’un inventaire).
Le plus souvent, et notamment lorsque la collecte physique devient trop coûteuse, l’exactitude peut être inférée à partir d’autres dimensions : notamment la cohérence des données avec celles d’une source réputée exacte.
Une vue d'ensemble
A travers l’état des lieux de ces dimensions, nous avons un aperçu de la diversité des éléments qui sont mobilisés et comparés pour calculer une version de la qualité des données :
- Les données elles-mêmes
- Les standards de données (type, format…)
- Les règles de cohérence entre données
- Les exigences de complétion
- Les dates de collecte et de mise à jour des données
- Les attentes sur les valeurs des données
- Les objets du monde réel
La solution Data Quality AI novencia 
vous permet de mesurer la qualité de données sur l’ensemble de ces dimensions en nécessitant le moins possible de ces éléments. En effet, à travers son utilisation de l’IA, et en partant uniquement de vos données, la solution novencia est notamment capable de déduire nativement :
- Le format et le type de données attendu
- Les relations attendues entre plusieurs champs
- Les exigences de complétion des champs
- Les attentes sur les valeurs d’un champ
Certains éléments ne sont pas directement déduisibles de la donnée elle-même (comme les dates de collecte / de mise à jour ou bien les objets du monde réel). Mais si ces élements sont fournis par ailleurs (ex : mesure directe via objet connecté), la solution Data Quality AI novencia peut tout à fait être configurée pour les prendre en compte et ainsi donner une vision complète de la qualité de vos données.
