Les 6 dimensions de la qualité des données, expliquées

Complétude, unicité, validité, cohérence, exactitude et actualité — ce que signifie chaque dimension, un exemple de violation, et le contrôle qui la détecte.

2026-09-10 · 10 min read

Les six dimensions de la qualité des données sont la complétude, l'unicité, la validité, la cohérence, l'exactitude et l'actualité. Chacune désigne une manière distincte dont des données peuvent être fausses et, ensemble, elles forment le cadre de référence pour décrire, mesurer et rapporter l'état de santé d'un jeu de données. Une dimension n'est pas un contrôle : c'est une catégorie de contrôles, et c'est précisément ce qui la rend utile. Une règle en échec vous apprend qu'une colonne est cassée ; la couverture par dimension vous dit si vous surveillez seulement les bons types de défaillance.

Ce cadre est issu de la littérature sur la gestion des données (le DAMA-DMBOK et le document du DAMA UK sur les dimensions sont les références habituelles) et il est suffisamment conventionnel pour qu'un rapport de couverture signifie à peu près la même chose d'une équipe et d'un outil à l'autre. Certaines taxonomies renomment une dimension — conformité pour validité, fraîcheur pour actualité — mais les six ci-dessous constituent l'ensemble de travail.

En résumé

1. Complétude

Définition. La complétude mesure si toutes les données qui devraient être présentes le sont effectivement — au niveau de la valeur (aucune valeur nulle dans les champs obligatoires), de l'enregistrement (aucune ligne manquante) et du jeu de données (aucune partition manquante).

Exemple de violation. Un chargement nocturne échoue à mi-parcours. Chaque ligne atterrie est parfaite prise isolément, mais customer_id est nul sur 4 % des commandes, parce que la jointure s'est faite avec une table clients qui n'avait pas encore été rafraîchie. Aucune erreur n'a été levée ; les lignes portent simplement des valeurs nulles.

Le contrôle. Comptez les valeurs nulles dans chaque colonne obligatoire, et comparez le nombre de lignes à un plancher attendu :

SELECT
    count(*)                                      AS row_count,
    count(*) FILTER (WHERE customer_id IS NULL)   AS missing_customer,
    count(*) FILTER (WHERE order_id IS NULL)      AS missing_order_id
FROM sales.orders
WHERE created_at >= current_date - 1;

Les contrôles de nombre de lignes sont la moitié sous-estimée de la complétude : un contrôle de valeurs nulles sur une table qui n'a reçu aucune ligne passe haut la main.

2. Unicité

Définition. L'unicité mesure si chaque entité du monde réel est représentée exactement une fois. Elle couvre aussi bien les doublons exacts d'une clé que les quasi-doublons qui représentent la même entité sous des valeurs différentes.

Exemple de violation. Un rechargement est relancé sans purge préalable, et chaque commande des sept derniers jours existe désormais en double. Rien n'est nul, aucune valeur n'est hors plage, et tous les agrégats en aval sont faux.

Le contrôle. Comptez les valeurs de clé qui apparaissent plus d'une fois :

SELECT count(*) AS violations
FROM (
    SELECT order_id
    FROM sales.orders
    WHERE order_id IS NOT NULL
    GROUP BY order_id
    HAVING count(*) > 1
) dupes;

Un index unique empêcherait le problème dès l'écriture, mais les tables analytiques en ont rarement un : CREATE TABLE AS SELECT ne transporte aucune contrainte, si bien qu'un modèle dbt reconstruit n'a rien qui impose sa clé. Le contrôle de doublons est le seul rempart qui reste.

3. Validité

Définition. La validité — également appelée conformité — mesure si chaque valeur respecte le format, le type, la plage ou l'ensemble autorisé défini pour son champ. C'est une propriété syntaxique : une valeur valide est bien formée, ce qui ne veut pas dire qu'elle est correcte.

Exemple de violation. Une nouvelle intégration en amont se met à écrire "COMPLETE" dans une colonne status dont les consommateurs raisonnent sur 'pending', 'paid', 'shipped' et 'refunded'. Chaque CASE en aval retombe sur sa branche ELSE, et les commandes disparaissent discrètement du rapport de tunnel de conversion.

Le contrôle. Testez l'appartenance, le motif et la plage :

SELECT count(*) AS violations
FROM sales.orders
WHERE status IS NOT NULL
  AND status NOT IN ('pending', 'paid', 'shipped', 'refunded');

La garde IS NOT NULL n'est pas décorative. La logique à trois valeurs du SQL résout NULL NOT IN (...) en NULL plutôt qu'en true : un statut nul ne satisfait donc jamais la clause WHERE et n'atteint jamais le compteur. Retirez la garde, et une colonne qui a totalement cessé d'être alimentée obtient un score de validité parfait — c'est pourquoi validité et complétude doivent être mesurées par des règles distinctes plutôt que fondues dans une seule requête.

4. Cohérence

Définition. La cohérence mesure si les valeurs liées s'accordent — entre colonnes d'une même ligne, entre tables d'une base, ou entre systèmes. Elle couvre l'intégrité référentielle, la logique inter-colonnes et le rapprochement inter-systèmes.

Exemple de violation. Un rechargement partiel laisse 12 000 commandes dont le customer_id n'existe pas dans la table clients. Chaque ligne est complète, unique et valide prise isolément, et le problème reste invisible jusqu'à ce que la jointure interne d'un tableau de bord les écarte en silence et que le chiffre d'affaires semble baisser de 3 %.

Le contrôle. Les clés étrangères orphelines, et les combinaisons de champs impossibles :

SELECT count(*) AS orphans
FROM sales.orders o
LEFT JOIN sales.customers c ON o.customer_id = c.id
WHERE o.customer_id IS NOT NULL
  AND c.id IS NULL;

La cohérence inter-colonnes, c'est la même idée à l'intérieur d'une seule table : shipped_at >= ordered_at, un remboursement qui n'excède jamais son paiement, des lignes de facture dont la somme fait le total. Elles encodent des invariants métier, et ce sont les contrôles qui attrapent de véritables erreurs de gestion plutôt que des erreurs de tuyauterie.

5. Exactitude

Définition. L'exactitude mesure si les valeurs décrivent correctement l'objet du monde réel auquel elles se réfèrent. C'est la dimension la plus difficile, parce que la vérifier exige une source de vérité extérieure au jeu de données.

Exemple de violation. L'adresse d'un client est bien formée, complète, unique et cohérente en interne — et correspond au bâtiment qu'il a quitté il y a deux ans. Tous les contrôles syntaxiques passent ; le colis part au mauvais endroit.

Le contrôle. Trois approches, par ordre décroissant de rigueur :

• Le rapprochement. Comparez à un système faisant autorité — le chiffre d'affaires de l'entrepôt face au grand livre comptable, le nombre de clients face au CRM. C'est le seul contrôle qui mesure l'exactitude directement, et il vaut l'effort pour la poignée de chiffres que l'entreprise publie.
• Les données de référence. Validez contre une liste externe : des codes postaux qui existent, des codes devise ISO 4217, des numéros de TVA qui se résolvent.
• Les bornes de plausibilité. Des contrôles de plage en guise d'approximation. Un total de commande à -40 ou à 4 000 000 n'est pas démontrablement faux, mais il l'est assez souvent pour valoir la peine d'être détecté :

SELECT count(*) AS violations
FROM sales.orders
WHERE total_amount IS NOT NULL
  AND (total_amount < 0 OR total_amount > 100000);

Soyez honnête sur la distinction : les bornes de plausibilité sont un contrôle de validité déguisé en contrôle d'exactitude. Elles attrapent des valeurs aberrantes, pas des erreurs.

6. Actualité

Définition. L'actualité — souvent appelée fraîcheur — mesure si les données sont assez récentes pour la décision qu'elles soutiennent. Elle a deux volets : la latence (le délai entre la survenue d'un événement et le moment où il devient interrogeable) et la fraîcheur courante (l'ancienneté de la ligne la plus récente à cet instant).

Exemple de violation. Un pipeline s'arrête le vendredi soir. Le tableau de bord du lundi s'affiche parfaitement, tous les contrôles passent, et tous les chiffres datent de vendredi. Aucune règle portant sur le contenu des données ne peut détecter cela, parce que le contenu est irréprochable.

Le contrôle. Comparez l'horodatage le plus récent à un seuil :

SELECT count(*) AS violations
FROM sales.orders
WHERE created_at < now() - interval '24 hours';

Préférez un type d'horodatage conscient du fuseau horaire : un timestamp nu se compare au fuseau de la session, quel qu'il soit, et le même contrôle donne deux réponses différentes à deux clients. Et fixez le seuil à partir de la décision, pas de la planification : une table chargée toutes les heures qui n'alimente qu'un rapport hebdomadaire n'a besoin d'aucune alerte horaire.

Utiliser les dimensions, et pas seulement les nommer

Le cadre justifie son existence dès que vous avez une centaine de règles. Prises une à une, elles forment une liste ; regroupées par dimension, elles deviennent une matrice de couverture — et les trous de cette matrice sont généralement plus instructifs que n'importe quel contrôle en échec.

La lacune caractéristique : une couverture abondante sur la complétude et la validité, parce que ces contrôles sont faciles à écrire, et presque rien sur la cohérence ou l'actualité, parce que celles-ci exigent de réfléchir aux relations et aux planifications. L'équipe se retrouve bien défendue contre les défaillances bon marché à détecter, et sans défense contre celles qui mettent un tableau de bord à terre. Deux pratiques en découlent :

1. Étiquetez chaque règle avec sa dimension et rapportez la couverture par jeu de données. Une table critique sans aucune règle d'actualité est un constat à remonter, même quand tous les contrôles sont au vert.
2. Pondérez par criticité, pas par nombre de tables. Une couverture complète sur les six dimensions pour vos dix jeux de données les plus consommés vaut mieux qu'une couverture partielle sur quatre cents.

L'Open Data Contract Standard fait de la dimension un champ de premier rang sur chaque règle de qualité, ce qui permet de calculer la couverture plutôt que de l'estimer. Catalyst modélise directement ces six mêmes dimensions : chaque règle en porte une, et les résultats se consolident dans une vue de couverture par jeu de données, aux côtés du détail pass / fail.

Voir aussi : ce qu'est la validation des données, ce qu'est un contrat de données, et le guide de la validation des données pour le SQL et la planification.

Questions fréquentes

Quelles sont les 6 dimensions de la qualité des données ?

La complétude (les données attendues sont-elles présentes), l'unicité (chaque entité apparaît-elle exactement une fois), la validité (chaque valeur respecte-t-elle son format ou son ensemble autorisé), la cohérence (les valeurs liées s'accordent-elles entre elles), l'exactitude (les valeurs décrivent-elles correctement le monde réel) et l'actualité (les données sont-elles assez récentes pour être utiles).

N'existe-t-il que six dimensions de la qualité des données ?

Six constitue l'ensemble de travail courant, mais les taxonomies varient. Le document du DAMA UK en liste six ; d'autres cadres ajoutent l'intégrité, la précision, la pertinence ou l'accessibilité. Le nombre exact importe bien moins que le fait d'en choisir un et de s'y tenir, afin que les rapports de couverture signifient la même chose d'une équipe à l'autre.

Quelle est la différence entre validité et exactitude ?

La validité est syntaxique : la valeur est bien formée et appartient à l'ensemble ou à la plage autorisés. L'exactitude est sémantique : la valeur décrit correctement l'objet du monde réel. Une valeur valide mais inexacte est le cas difficile classique — une adresse postale correctement formatée pour le bâtiment que le client a quitté il y a deux ans passe tous les contrôles de validité et reste fausse.

Quelle dimension de la qualité des données est la plus importante ?

Cela dépend de la décision que les données soutiennent, mais l'actualité et la complétude causent en pratique le plus d'incidents : un pipeline arrêté ou un chargement partiel casse tout l'aval d'un coup, tout en laissant chaque valeur individuellement correcte. L'exactitude compte le plus pour les chiffres publiés à l'extérieur, et c'est la seule dimension qui exige une source de vérité extérieure au jeu de données.

Comment mesurer les dimensions de la qualité des données ?

Rattachez chaque règle à une dimension, exprimez-la sous forme de requête renvoyant un nombre de violations, et rapportez à la fois le taux de réussite par règle et la couverture par dimension. La couverture est la partie que les équipes sautent : savoir que quatre-vingt-dix-huit contrôles sur cent sont passés est bien moins utile que savoir qu'aucun des cent n'était un contrôle d'actualité.