« Les chiffres sont faux » : c’est la phrase qui ruine la confiance dans un tableau de bord. Derrière, les causes sont variées : un client compté deux fois, des ventes d’hier pas encore chargées, un code postal mal saisi. Pour agir, il faut d’abord nommer le problème et le mesurer. Les dimensions de la qualité des données donnent ce vocabulaire commun.
La qualité dépend de l’usage
Une donnée n’est pas bonne ou mauvaise dans l’absolu : elle est adaptée ou non à un usage. Un fichier clients sans numéro de téléphone convient à une campagne d’emailing, pas à une campagne d’appels. Avant de mesurer, on se demande donc : qui utilise cette donnée, pour quoi faire, et quelle erreur aurait des conséquences ?
Les six dimensions usuelles
Les référentiels ne listent pas tous exactement les mêmes dimensions, mais ces six reviennent partout :
| Dimension | Question | Exemple de défaut |
|---|---|---|
| Complétude | La valeur est-elle renseignée ? | email vide |
| Validité | Respecte-t-elle le format ou le domaine attendu ? | code postal de 4 chiffres, email sans @ |
| Exactitude | Correspond-elle à la réalité ? | mauvaise adresse, bien formée |
| Cohérence | Est-elle compatible avec les autres données ? | « France » ici, « FR » ailleurs ; date de livraison avant la commande |
| Unicité | Chaque objet réel est-il présent une seule fois ? | même client saisi deux fois |
| Fraîcheur (actualité) | Est-elle assez récente pour l’usage ? | ventes d’hier absentes à 9 h |
Deux confusions fréquentes :
- validité et exactitude :
[email protected]est un email valide, mais s’il appartient à quelqu’un d’autre, il est inexact. La validité se vérifie par une règle ; l’exactitude demande souvent une source de référence ou une vérification humaine ; - unicité et doublon technique : deux lignes identiques sont un doublon évident ; deux lignes « Marie Dupont » et « M. Dupont » avec le même email sont le même client, plus difficile à détecter.
Certaines équipes ajoutent l’intégrité (les références pointent vers des objets existants), la précision (le niveau de détail suffisant) ou l’accessibilité.
De l’exigence à la règle mesurable
Une exigence vague (« les données clients doivent être propres ») ne se mesure pas. On la traduit en règles :
- Complétude : « l’email est renseigné pour au moins 98 % des clients actifs » ;
- Validité : « le code postal français comporte exactement 5 chiffres » ;
- Plausibilité (une forme d’exactitude vérifiable) : « la date de naissance est dans le passé et après 1900 » ;
- Unicité : « aucun email n’est partagé par deux clients actifs » ;
- Fraîcheur : « les ventes de la veille sont disponibles chaque jour à 7 h ».
Chaque règle a un seuil (100 % n’est pas toujours réaliste ni nécessaire) et un responsable.
Calculer un indicateur
Un indicateur de qualité est un ratio simple : lignes conformes / lignes contrôlées. Attention au dénominateur : la validité d’un email se calcule sur les emails renseignés, sinon on mélange complétude et validité.
SELECT
100.0 * COUNT(email) / COUNT(*) AS pct_email_renseigne,
100.0 * SUM(CASE WHEN email LIKE '%_@_%' THEN 1 ELSE 0 END)
/ COUNT(email) AS pct_email_valide
FROM clients;
En SQL, COUNT(colonne) ignore les NULL : c’est pratique pour la complétude. Attention aux chaînes vides, qui ne sont pas NULL : selon la source, un email absent peut être '', NULL ou 'n/a'.
Suivre la qualité dans le temps
Une mesure ponctuelle ne suffit pas : on calcule les indicateurs à chaque chargement et on les enregistre. Un graphique de l’évolution montre si la qualité se dégrade (nouvelle version d’un formulaire, nouvelle source) et si les actions correctives fonctionnent. Les outils de transformation (tests dbt) et les outils spécialisés (Great Expectations, Soda, ou les fonctions de qualité des plateformes cloud) automatisent ces contrôles. Mais le choix des règles et des seuils reste une décision métier, prise avec les utilisateurs des données.
Exercices
Les solutions et les tests restent sur le serveur. Dans l'espace étudiant, ton code est exécuté et corrigé, et le tuteur donne des indices avant la solution.
Mesurer la qualité d'un fichier clients
Données (
clients.csv) :client_id,email,code_postal,date_naissance,pays 1,[email protected],69001,1990-04-12,FR 2,,75011,1985-11-30,FR 3,[email protected],7501,1979-02-15,FR 4,[email protected],33000,2031-01-01,FR 5,[email protected],69001,1990-04-12,FR 6,[email protected],13008,,France 7,sam.ex.fr,44000,1992-07-08,FR 8,[email protected],59000,1988-09-21,FR 9,[email protected],31000,1995-03-03,FR 10,,67000,2000-12-24,FRCalculez, à la main, dans un tableur ou en SQL :
- la complétude de l’email (en % des 10 lignes) ;
- le nombre d’emails renseignés mais invalides (sans
@précédé et suivi d’au moins un caractère) ; - le nombre de codes postaux invalides (pas exactement 5 chiffres) ;
- le nombre de dates de naissance impossibles (dans le futur) ;
- le nombre de lignes dont le
paysn’est pas au format attenduFR; - le nombre de lignes en double (même email, même date de naissance qu’une autre ligne).
- Complétude de l'email calculée sur 10 lignes
- Validité de l'email calculée uniquement sur les emails renseignés
- Chaque indicateur est rattaché à sa dimension (complétude, validité, exactitude/plausibilité, cohérence, unicité)
- Les lignes concernées sont identifiées par leur client_id
Quelle dimension ?
À 9 h, le tableau de bord des ventes n’affiche pas encore les ventes de la veille, qui arrivent vers 11 h. Quelle dimension de la qualité est en défaut ?
- Unicité
- Fraîcheur (actualité)
- Validité
Écrire des règles mesurables
Le service client exprime trois attentes : « on doit pouvoir joindre les clients », « pas de client en double » et « les adresses doivent être à jour ». Traduisez chacune en une règle mesurable, avec la dimension concernée, la formule de l’indicateur et un seuil.
- Chaque règle nomme une dimension (complétude, unicité, fraîcheur ou exactitude)
- Chaque règle a une formule de calcul explicite (numérateur et dénominateur)
- Chaque règle a un seuil chiffré
- La règle sur les adresses précise comment l'exactitude ou la fraîcheur est vérifiée (date de dernière confirmation, référentiel d'adresses)
Quiz de fin de leçon
Un email
[email protected]appartient en réalité à un autre client. Quelle dimension est en défaut ?- Validité
- Exactitude
- Complétude
« Pays = France » dans une table, « FR » dans une autre : quelle dimension ?
- Cohérence
- Fraîcheur
- Unicité
Pourquoi calculer la validité de l’email sur les seuls emails renseignés ?
- Pour ne pas mélanger complétude et validité
- Parce que SQL l'impose
- Pour obtenir un meilleur score
Qui fixe le seuil d’acceptation d’une règle de qualité ?
- Le data engineer seul
- Les utilisateurs métier de la donnée, avec l'équipe data
- L'outil de qualité automatiquement
La suite du cours
- Les contrats de données16 min
- Catalogue de données et lignage16 min
- RGPD et données personnelles dans les plateformes de données18 min
- Construire un plan d'amélioration de la qualité16 min