← Blog
Qualité & Fiabilité

DataQuality

Des données incorrectes coûtent en moyenne 12,9 millions de dollars par an aux entreprises. Comprendre, mesurer et garantir la qualité — c'est le fondement de toute plateforme data fiable.

9 min de lecturedbt · Great Expectations · Soda · Monte Carlo
📋Complétude
🎯Exactitude
🔗Cohérence
⏱️Fraîcheur
🔄Unicité
Validité

Un pipeline qui tourne en silence n'est pas forcément un bon pipeline. Il peut ingérer des données manquantes, dupliquées ou obsolètes — et personne ne le saura jusqu'à ce qu'un analyste trouve un chiffre aberrant dans un dashboard. La Data Quality, c'est l'ensemble des pratiques qui empêchent ce scénario.

⚠️
Règle d'or : la qualité d'une donnée se dégrade à chaque étape du pipeline. Une anomalie détectée à la source coûte 10× moins cher à corriger qu'une anomalie découverte dans un rapport métier.

Les 6 dimensions de la qualité

Chaque dimension mesure un aspect différent — une donnée peut être complète mais inexacte, ou exacte mais obsolète.

📋
Complétude
Toutes les valeurs attendues sont-elles présentes ?
92%

Mesure le pourcentage de champs renseignés par rapport au total attendu. Une table à 70% de complétude signifie que 30% des valeurs manquent.

Exemple concret Colonne email NULL sur 15% des clients — les campagnes marketing touchent seulement 85% de la base.
🎯
Exactitude
Les valeurs correspondent-elles à la réalité ?
87%

Vérifie que les données reflètent fidèlement le monde réel. Difficile à mesurer sans source de référence — on s'appuie souvent sur des règles métier.

Exemple concret Montant de commande négatif, date de naissance en 2150, code pays inexistant.
🔗
Cohérence
Les données sont-elles identiques entre les systèmes ?
78%

Une même entité (client, produit) peut exister dans plusieurs systèmes. La cohérence garantit qu'elle y est représentée de manière identique.

Exemple concret Le CRM affiche 1 200 clients actifs, le data warehouse en compte 1 350 — 150 écarts non réconciliés.
⏱️
Fraîcheur
Les données sont-elles assez récentes pour l'usage prévu ?
94%

Une donnée exacte mais obsolète peut être aussi dangereuse qu'une donnée incorrecte. La fraîcheur se mesure par rapport au SLA défini.

Exemple concret Le stock affiche 50 unités disponibles, mais la donnée date d'hier — le stock réel est à 0.
🔄
Unicité
Chaque entité n'est-elle représentée qu'une seule fois ?
96%

Les doublons faussent tous les agrégats — CA doublé, nombre de clients gonflé. Ils apparaissent à l'ingestion (retry, CDC, merge raté).

Exemple concret Un client a passé commande une fois, mais apparaît deux fois dans la table → son CA est comptabilisé en double.
Validité
Les valeurs respectent-elles le format et les règles attendus ?
89%

Une donnée valide respecte le type, le format et les contraintes définies par le domaine. Elle peut être présente et exacte mais invalide (ex. email sans @).

Exemple concret Numéro de téléphone "0145abc78", email sans domaine, statut hors liste de valeurs autorisées.

L'impact des mauvaises données

$12.9M
Coût annuel moyen
par entreprise (Gartner, 2021)
27%
Du temps des data teams
passé à corriger des erreurs de données
1 sur 3
Décisions business
basées sur des données incorrectes
📉
Dashboard CA sous-évalué de 18%
Des doublons dans la table orders ont été supprimés par erreur lors d'une migration Silver — le Gold a recalculé un CA incorrect.
Critique
📧
Campagne email envoyée à des adresses invalides
23 000 emails bounced suite à une migration de CRM qui a tronqué les adresses à 40 caractères.
Élevé
🤖
Modèle ML dégradé en production
La feature "âge client" contenait des valeurs négatives depuis 2 semaines — le modèle de churn a perdu 12 points de précision.
Moyen
📊
KPI hebdomadaire en retard de 4h
Le job d'ingestion n'a pas respecté le SLA de fraîcheur — les données du dimanche sont arrivées lundi matin.
Faible

Les outils du Data Quality

Great Expectations
Validation · Open source
dbt tests
Tests SQL · Intégré à dbt
Soda Core
Checks déclaratifs · SodaCL
Monte Carlo
Observabilité · SaaS
Great Expectations
Framework Python qui définit des "expectations" sur les données et génère des rapports de validation lisibles par les équipes data et métier.
Great Expectations · Validation d'une table
import great_expectations as gx

context = gx.get_context()
batch = context.sources.pandas_default.read_csv("orders.csv")

# Définir les règles (expectations)
batch.expect_column_values_to_not_be_null("order_id")
batch.expect_column_values_to_be_unique("order_id")
batch.expect_column_values_to_be_between(
    "amount_eur", min_value=0, max_value=100_000
)
batch.expect_column_values_to_match_regex(
    "email", regex=r"^[^@]+@[^@]+.[^@]+$"
)

# Valider et générer le rapport HTML
results = batch.validate()
print(results.success)  # True / False

Intégrer la qualité dans le pipeline

Les contrôles de qualité se placent à chaque couche — pas seulement à la fin.

🗄️
Source
Avant ingestion
✓ Volume non nul✓ Schéma attendu✓ Fichier disponible
🥉
Bronze
Après ingestion
✓ Pas de perte de lignes✓ Champs techniques renseignés✓ Fraîcheur OK
🥈
Silver
Après transformation
✓ not_null sur clés✓ Unicité✓ Valeurs acceptées✓ Formats valides
🥇
Gold
Avant exposition
✓ KPIs dans les bornes historiques✓ Pas d'anomalie statistique✓ SLA fraîcheur
🚨
Stratégie de réponse aux incidents : quand un contrôle échoue, le pipeline doit décider — quarantaine (stocker les données invalides sans les propager), alerte (notifier sans bloquer) ou arrêt (bloquer le pipeline entier). Le bon choix dépend de la criticité métier du flux.

Monitoring en continu

La qualité n'est pas un état — c'est un processus. Les métriques doivent être surveillées en permanence.

📦Volume
Surveiller le nombre de lignes ingérées. Une chute soudaine signale une source cassée ou un pipeline bloqué.
Row countSpike detectionAlertes Slack
⏱️Fraîcheur
Mesurer le délai entre la donnée la plus récente et l'heure actuelle. Essentiel pour les SLAs temps réel.
MAX(updated_at)SLAAirflow SLAs
📐Schéma
Détecter les ajouts ou suppressions de colonnes, les changements de type. Un bug silencieux courant lors des migrations.
Schema driftColumn diffdbt source
📊Distribution
Surveiller la distribution statistique des valeurs clés (moyenne, écart-type). Une dérive signale souvent un bug amont.
Z-scorePercentilesMonte Carlo
Taux de complétude — colonne email⚠ Anomalie détectée J-3
J-14
J-13
J-12
J-11
J-10
J-9
J-8
J-7
J-6
J-5
J-4
J-3
J-2
J-1
Auj
≥ 95% (OK)80–95% (Alerte)< 80% (Critique)

Bonnes pratiques

01
Définir les règles avec les équipes métier
Un Data Engineer ne peut pas savoir seul qu'un montant de 0€ est invalide ou qu'une commande sans adresse est acceptable. Les règles de qualité naissent du dialogue avec les métiers.
Fondamental
02
Tester à la source, pas seulement en Gold
Détecter une anomalie en Bronze (ingestion) coûte 10× moins cher qu'en Gold. Chaque couche doit avoir ses propres contrôles.
Architecture
03
Traiter les données invalides séparément
Ne pas supprimer les lignes invalides — les déplacer dans une table de quarantaine pour analyse ultérieure. La donnée brute ne doit jamais être perdue.
Pattern
04
Rendre les métriques visibles à tous
Un dashboard de qualité accessible aux analystes et aux métiers crée une culture data partagée. La qualité n'est pas l'affaire du seul Data Engineer.
Culture
05
Versionner les règles de qualité
Les expectations et les tests dbt doivent être dans git, reviewés, et déployés en CI/CD comme n'importe quel code. Éviter les règles dans des interfaces graphiques non versionnées.
DevOps

La qualité des données n'est pas une fonctionnalité qu'on ajoute à la fin — c'est une discipline transversale qu'on intègre dès le premier pipeline. Une donnée de mauvaise qualité n'est pas neutre : elle active des décisions incorrectes, avec des conséquences métier bien réelles.

Commentaires

Soyez le premier à commenter cet article.

Laisser un commentaire

Votre commentaire sera visible après validation par l'administrateur.

0/2000
© 2026 Aboubacar Camara