Qualité des données

Un chiffre faux publié avec assurance fait plus de dégâts qu'un chiffre absent : il sert de base à des décisions et il détruit la confiance dans tout le reste. Or la plupart des défauts de…

Guide≈ 9 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : QUA

Pourquoi ce thème#

Un chiffre faux publié avec assurance fait plus de dégâts qu'un chiffre absent : il sert de base à des décisions et il détruit la confiance dans tout le reste. Or la plupart des défauts de données ne naissent pas dans le datamart : ils viennent de la saisie terrain, des interfaces entre applications et de règles métier non respectées. Corriger dans l'aval est un puits sans fond ; mesurer, attribuer et corriger à la source est le seul traitement durable. Ce thème porte sur la mesure de la qualité et sur l'engagement qui en découle, pas sur les tests du code (voir matrice DL — tests) ni sur la recette de chiffres (REC).

Ce que mesure le thème#

Axe : de la découverte de l'erreur par l'utilisateur à la prévention à la source.
Indicateur clé : taux de conformité aux seuils de qualité des données critiques et part des anomalies détectées avant l'utilisateur.
Unité : % de contrôles conformes ; % d'anomalies détectées en interne ; délai moyen de correction.
Dimensions de référence (repères courants, cf. DAMA-DMBOK et la norme ISO/IEC 25012) : exactitude, complétude, validité, unicité, cohérence, fraîcheur (actualité) ; on y ajoute la disponibilité dans les engagements de service de données.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Subie	L'utilisateur découvre les erreurs ; le correctif arrive après la plainte.	< 20 % des anomalies détectées en interne
2	Contrôlée	Les erreurs les plus graves sont arrêtées ou signalées à chaque chargement.	Contrôles de base sur ≥ 50 % des tables critiques
3	Engagée	Chaque donnée critique a des seuils par dimension et un engagement de service (SLA) connu de ses consommateurs.	≥ 80 % de tables critiques avec seuils ; fraîcheur publiée
4	Pilotée	La qualité est suivie dans le temps, les causes racines sont traitées chez le producteur et les tendances se corrigent.	≥ 90 % d'anomalies détectées en interne ; récurrence < 10 %
5	Préventive	Les défauts sont empêchés à la saisie ou à l'interface, et les dérives sont prédites avant impact.	Défauts critiques résiduels proches de 0 ; dette de qualité soldée

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PD-QUA-1.1	Les erreurs signalées par les utilisateurs sont enregistrées.	Registre d'anomalies avec date, objet, impact.
PD-QUA-1.2	Les échecs de chargement sont visibles (journal consultable).	Journal des traitements avec statut et horodatage.
PD-QUA-1.3	Les anomalies sont attribuées à une cause probable (saisie, interface, règle, code).	Champ « cause » renseigné sur le registre.
PD-QUA-1.4	Au moins une vérification manuelle des totaux entre source et datamart est faite à chaque livraison.	Trace de la comparaison dans la note de livraison.
PD-QUA-2.1	Des contrôles automatiques de base existent : doublons de clé, valeurs nulles interdites, volumes anormaux.	Requêtes ou tests exécutés à chaque chargement, résultats archivés.
PD-QUA-2.2	Les clés étrangères orphelines sont comptées et signalées.	Rapport d'orphelins par table de faits.
PD-QUA-2.3	Un chargement en échec bloque la publication ou signale explicitement la donnée périmée.	Comportement testé : un échec ne laisse pas passer silencieusement des données partielles.
PD-QUA-2.4	Le défaut le plus coûteux de chaque domaine est identifié et traité en priorité.	Liste Top-5 des défauts avec plan.
PD-QUA-3.1	Les dimensions de qualité sont définies pour chaque donnée critique, avec des seuils (ex. complétude ≥ 98 %).	Fiche de qualité par table critique.
PD-QUA-3.2	Un SLA de données est publié : fraîcheur (ex. disponible avant 7 h), complétude, délai de correction.	Engagement écrit consultable par les consommateurs.
PD-QUA-3.3	Le profilage des sources précède toute nouvelle intégration.	Rapport de profilage joint à la fiche de cadrage (VAL).
PD-QUA-3.4	Les valeurs inconnues sont traitées par une convention explicite (membre « Inconnu », pas de NULL silencieux).	Règle documentée et vérifiée dans les dimensions.
PD-QUA-4.1	Les indicateurs de qualité sont historisés et tracés dans le temps.	Tableau de bord de tendance sur ≥ 6 mois.
PD-QUA-4.2	Chaque anomalie récurrente a une analyse de cause racine et une action chez le producteur.	Fiches de cause racine avec statut côté source.
PD-QUA-4.3	≥ 90 % des anomalies sont détectées par l'équipe avant les utilisateurs.	Ratio calculé sur le registre sur un trimestre.
PD-QUA-4.4	Les seuils sont révisés selon l'impact réel (usage, décisions concernées).	Compte rendu de revue des seuils.
PD-QUA-5.1	Des contrôles à la saisie ou à l'interface (validations, listes fermées) réduisent les défauts de production.	Mesure avant/après sur un défaut traité à la source.
PD-QUA-5.2	Les dérives (volumes, distributions) sont détectées automatiquement avant l'échec visible.	Alertes de dérive déclenchées sur des cas réels.
PD-QUA-5.3	Un budget de défauts (équivalent d'un budget d'erreurs) arbitre entre livrer et corriger.	Règle écrite et appliquée au moins une fois.
PD-QUA-5.4	La qualité est un critère de contractualisation avec les producteurs (voir CTR).	Seuils de qualité présents dans les contrats de données.

Lecture détaillée par niveau#

🟢 Niveau 1 — Subie#

Signes : « le chiffre est faux » arrive par mail ; on corrige à la main dans le datamart ; personne ne sait si l'erreur est revenue le mois suivant.
Gain : rien d'autre que la réactivité.
Ne garantit pas : que le même défaut ne revienne pas à chaque cycle.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Contrôlée#

Signes : des requêtes de contrôle tournent en fin de chargement ; une table orpheline fait échouer ou alerte ; les totaux source/datamart sont comparés.
Gain : les erreurs grossières n'arrivent plus aux utilisateurs.
Ne garantit pas : le sens des données (une valeur plausible mais fausse passe).
Difficulté : 2/5 · Effort : 2/5.

-- Contrôle de base : clés étrangères orphelines d'une table de faits (T-SQL)
SELECT COUNT(*) AS NbOrphelins
FROM   [fact].[Releve]          AS R WITH (NOLOCK)
LEFT JOIN [dim].[PointDeVente]  AS P WITH (NOLOCK) ON P.PDV_ID = R.PDV_ID
WHERE  P.PDV_ID IS NULL;
-- Seuil : > 0 => signaler ; > 0,5 % des lignes => bloquer la publication

🟡 Niveau 3 — Engagée#

Signes : une fiche par table critique ; un SLA affiché (« chargé avant 7 h, complétude ≥ 98 % ») ; le profilage fait partie du cadrage.
Gain : le consommateur sait ce qu'il peut attendre ; l'équipe sait quand elle a failli.
Ne garantit pas : que les seuils soient pertinents ni que le producteur corrige.
Difficulté : 3/5 · Effort : 3/5.

🧪 Exemple

Dans une application de force de vente, 4 % des relevés arrivent sans point de vente valide. Au niveau 2, on les compte. Au niveau 3, le seuil est « ≤ 1 % d'orphelins » avec un membre « Inconnu » dans la dimension. Au niveau 4, la cause racine (saisie hors-ligne avec une liste périmée) est traitée côté application : le taux tombe sous 0,3 %. C'est la correction à la source qui change l'ordre de grandeur.

🟡 Niveau 4 — Pilotée#

Signes : tendances mensuelles ; chaque récurrence a une fiche de cause racine ; le ratio « détecté avant l'utilisateur » est suivi.
Gain : la qualité devient une trajectoire ; les producteurs reçoivent des preuves.
Ne garantit pas : l'exactitude réelle (un contrôle de cohérence interne ne détecte pas une erreur commune aux deux systèmes) ; voir la réconciliation externe en REC.
Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Préventive#

Signes : les défauts sont refusés à la saisie ou à l'interface ; des alertes de dérive parlent avant l'utilisateur ; la qualité se négocie dans les contrats.
Gain : un coût de non-qualité qui diminue au lieu de croître avec le volume.
Ne garantit pas : l'immunité : une règle métier qui change reste invisible tant qu'on ne la surveille pas.
Difficulté : 5/5 · Effort : 5/5.

Atteinte partielle et notation#

Notez sur les cinq tables de faits les plus consommées et leurs dimensions. Un jalon est à 1 si la pratique couvre les cinq, 0,5 si deux à quatre, 0 sinon. Pour PD-QUA-4.3, mesurez le ratio réel sur un trimestre à partir du registre (sans registre, 0).

Un « 5 partiel » : la saisie bloque les défauts sur le formulaire le plus critique (5.1 à 0,5), des alertes de volume ont déjà évité une publication erronée (5.2 à 0,5), mais ni budget de défauts ni clause contractuelle n'existent (5.3 et 5.4 à 0). Le score reste honorable : 4,0 + 0,25 × 0,99 ≈ 4,2.

⚠️ Piège

Le contrôle qui ne contrôle rien : un test qui retourne toujours « OK » (jointure LEFT sans filtre, seuil à 100 %). Symptôme : 100 % de conformité, utilisateurs mécontents. Cause : contrôle jamais éprouvé. Remède : tout contrôle est testé à l'envers une fois (injecter un défaut, vérifier qu'il échoue). Ne comptez jamais « nombre de tests » : comptez les défauts réels interceptés.

⚠️ Piège

Corriger dans l'aval : un UPDATE de rustine dans le datamart. Le défaut revient au prochain chargement complet. Reportez la correction chez le producteur, et ne conservez la rustine que comme mesure transitoire tracée.

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage	Leviers possibles
1 → 2	Un registre d'anomalies ; une dizaine de requêtes de contrôle rejouées à chaque chargement ; un statut de traitement visible.
2 → 3	Écrire la fiche de qualité avec le propriétaire (GOV) ; publier la fraîcheur dans le rapport (date de dernière actualisation).
3 → 4	Historiser chaque résultat de contrôle ; une revue mensuelle des tendances avec les producteurs ; frameworks de tests de données (dbt, Great Expectations, Soda ou requêtes maison — état 2026-10, choix d'outil secondaire).
4 → 5	Négocier des validations à la saisie ; ajouter des contrôles statistiques de dérive ; budget de défauts.

Pièges transverses : (1) Faux positif — beaucoup de contrôles, aucun sur le défaut qui coûte ; partez du registre d'incidents. (2) Goodhart — un taux de complétude « amélioré » en remplissant des valeurs par défaut : mesurez aussi l'exactitude sur échantillon. (3) Seuils décoratifs — un seuil jamais franchi ou toujours franchi n'informe pas ; calibrez sur l'historique.

🤖 IA

Utile : proposer des règles de contrôle depuis un profilage, détecter des anomalies statistiques, résumer un registre d'incidents. Limites : faux positifs en volume, règles plausibles mais non métier, risque de masquer l'erreur en « corrigeant » automatiquement. Une correction automatique de valeurs se trace et se valide.

Voir aussi#

Même matrice : 02 Gouvernance · 04 Contrats · 07 Recette · 10 Exploitation · README
Autres matrices : DL — tests · DL — observabilité et fiabilité · BI — tests et fiabilité des chiffres · BI — couche données et ETL
Pratique : méthodes spécifiques data · CI/CD pour la data · difficultés et pièges (SQL Server SaaS) · checklist reporting
Glossaire · Notation

✻ Rédigé par Claude Sonnet 5.5