1. Pourquoi la qualite des donnees compte
Chaque equipe data a une histoire d horreur : un dashboard annonce +40% de revenu, le CEO le partage, puis quelqu un trouve une jointure dupliquee. La Data Quality n est pas la perfection mais le fait d attraper avant les decideurs.
Le cout des mauvaises donnees
Gartner estime que la mauvaise qualite coute en moyenne $12.9M par an. Le cout cache est la perte de confiance : une fois perdue, les decideurs reviennent aux decisions au feeling.
La data quality apporte trois resultats :
Confiance
Les parties prenantes consomment car elles savent que c est teste. Plus de "laisse moi revérifier".
Vitesse
Probleme trouves a la source au lieu de debugguer des dashboards. Minutes au lieu d heures.
Echelle
Des checks automatiques scalent avec vos donnees. Les controles manuels ne scalent pas avec 500 tables.
Retour terrain
Les equipes qui reussissent traitent la qualite comme les tests unitaires : on ne shippe pas sans tests, et on ne shippe pas de donnees sans checks. C est une assurance, pas une charge.
2. Les six dimensions de la qualite
Toutes les erreurs ne se ressemblent pas. Ces six dimensions servent de cadre pour savoir quoi tester.
Completude
Tout est-il present ?
Test : Taux de null sur champs obligatoires = 0%
Exactitude
Les valeurs refletent-elles la realite ?
Test : Reconciliation avec les systemes sources
Coherence
Meme format partout ?
Test : Formats de date, enums, conventions de nommage
Fraicheur
Assez recentes ?
Test : max(updated_at) dans la fenetre SLA
Validite
Respect des regles metier ?
Test : Status in ('active','inactive'), price > 0
Unicite
Pas de doublons non souhaites ?
Test : Cle primaire unique, pas de commandes dupliquees
| Dimension | Question | Echec classique |
|---|---|---|
| Completude | Tout est-il la ? | Nulls dans champs requis |
| Exactitude | Est-ce correct ? | Caches perimes, mauvaises jointures |
| Coherence | Identique partout ? | Formats de date differents |
| Fraicheur | Assez frais ? | Retards de pipeline, SLA non tenu |
| Validite | Cela a-t-il du sens ? | Prix negatifs, dates futures |
| Unicite | Des doublons ? | Doublons issus de fan-out |
3. Ou tester dans votre pipeline
Principe "tester aux frontieres" : valider a l entree et a la sortie. On capture ainsi les problemes upstream et les bugs de transformation.
Etape 1 : Validation source (ingestion)
Tester les donnees a l arrivee des systemes externes. Premiere ligne de defense.
A verifier :
- • Schema conforme (pas de colonnes nouvelles/manquantes)
- • Volume dans la plage attendue
- • Champs obligatoires non nuls
- • Donnees recues dans les temps (freshness)
Etape 2 : Tests de transformation
Tester le resultat des transformations. Capture les bugs de logique SQL/Python.
A verifier :
- • Cles primaires uniques (pas de fan-out)
- • Les aggregations somme correctement
- • Regles metier appliquees
- • Integrite referentielle preservee
Etape 3 : Validation de sortie (delivery)
Tester avant les dashboards et consommateurs. Derniere chance d attraper un probleme.
A verifier :
- • Metriques dans les bornes attendues
- • Pas d anomalies vs l historique
- • Les dashboards critiques sont remplis
- • SLAs respectes
Astuce
Fail fast, fail loud
Mieux vaut une pipeline qui echoue a 6h avec un message clair qu une pipeline silencieuse qui alimente un board avec de mauvaises donnees. Configurer les tests pour bloquer la propagation des donnees corrompues.
4. Ce qu il faut tester (checks pratiques)
Commencez par ces checks a forte valeur et faible effort. Ils couvrent 80% des problemes.
Bornes de volume
Verifier que le nombre de lignes est dans la plage attendue (ex : 900K-1.1M). Detecte les chargements tronques ou dupliques.
expect_table_row_count_to_be_between(min=900000, max=1100000)Seuils de null
Les champs obligatoires doivent avoir 0% de nulls. Les optionnels doivent avoir un taux stable (alerte si variation >10%).
expect_column_values_to_not_be_null(column="customer_id")Contraintes d unicite
Les cles primaires doivent etre uniques. Detecte le fan-out qui explose les metriques.
expect_column_values_to_be_unique(column="order_id")SLA de fraicheur
Les donnees ne doivent pas depasser votre SLA. Checker max(updated_at) ou la partition.
expect_column_max_to_be_between(column="updated_at", min=now()-24h)Plages de valeurs
Les champs numeriques doivent rester dans des bornes valides. Revenue > 0, age 0-150, pourcentage 0-100.
expect_column_values_to_be_between(column="price", min=0, max=100000)Validation d enum
Les statuts ne doivent contenir que les valeurs attendues. Detecte fautes de frappe et etats inattendus.
expect_column_values_to_be_in_set(column="status", value_set=["active", "inactive", "pending"])Exemple : test de schema dbt
# models/marts/orders.yml
version: 2
models:
- name: orders_mart
description: "Order-level facts for analytics"
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- not_null
- relationships:
to: ref('dim_customers')
field: customer_id
- name: order_total
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0
max_value: 10000005. Alertes sans fatigue
Le risque majeur du monitoring n est pas de rater un probleme mais la fatigue d alerte. Trop de faux positifs et l equipe ignore tout. Voici comment garder du signal.
A faire
- • Tiering des alertes : P1 (pager), P2 (Slack), P3 (email digest)
- • Detection d anomalies pour les metriques naturellement variables
- • Contexte dans l alerte : ce qui a casse, impact, lien runbook
- • Seuils bases sur l historique
- • Revue mensuelle et ajustements
A eviter
- • Pager sur chaque test echoue
- • Seuils hard-code qui ne s adaptent pas
- • Alertes sans owner clair
- • Ignorer les tests "flaky" au lieu de les corriger
- • Pas de runbook pour les pannes courantes
Severite des alertes
P1 - Pager immediat
Donnees fausses dans les dashboards prod. Dirigeants impactes. Risque revenu.
P2 - Alerte Slack
Qualite degradee mais non critique. A corriger sous 4h.
P3 - Digest quotidien
Mineur, informatif. Revue au prochain sprint.
Retour terrain
J ai rejoint une equipe avec 200+ alertes par jour. Personne ne regardait. Nous sommes passes a 15 alertes a fort signal et les corrections se faisaient dans la journee. Moins mais mieux.
6. Outils pour la Data Quality
| Outil | Ideal pour | Approche | Tarification |
|---|---|---|---|
| dbt tests | Tests de transformation | Tests de schema + custom | Gratuit (OSS) |
| Great Expectations | Validation exhaustive | Suites d expectations | Gratuit (OSS) |
| Monte Carlo | Observabilite data | Detection d anomalies ML | Enterprise |
| Soda | Monitoring | Checks SodaCL | Gratuit + offres payantes |
| elementary | Observabilite native dbt | Detection d anomalies | Gratuit (OSS) |
Tests proactifs
Vous definissez les regles. Les tests tournent a chaque run. Explicite et deterministe.
Outils : dbt tests, Great Expectations, Soda
Detection d anomalies
Le ML apprend le pattern "normal" et alerte en cas d ecart. Capture les inconnues.
Outils : Monte Carlo, elementary, Bigeye
7. Checklist des bonnes pratiques
Tester aux frontieres
Valider a l ingestion (problemes upstream) et a la livraison (problemes de transformation). Attraper tot.
Commencer par les tables critiques
Cibler d abord les tables des dashboards executifs et rapports critiques. Prouver la valeur puis elargir.
Combiner regles et anomalies
Les regles trouvent les connus (nulls, doublons). L anomalie detecte les inconnus (variation soudaine de volume).
Tiering des alertes
Tout echec ne merite pas un pager. P1 impact revenu, P2 degrade, P3 info.
Runbooks lies aux alertes
Chaque alerte renvoie vers un doc : signification, investigation, correctifs types.
Suivre les metriques de qualite
Mesurer : taux de reussite des tests, mean time to detection, mean time to resolution. Ameliorer en continu.
Inclure la qualite dans le CI/CD
Tests sur chaque PR. Bloquer les merges qui degradent la qualite. Shift left.
Revoir mensuellement
Les seuils derivent, les patterns changent. Revue mensuelle pour garder les tests pertinents.
Astuce
Le test "Je parierais de l argent ?"
Avant de publier une metrique, demandez-vous : "Je parierais 1 000$ que ce nombre est juste ?" Si non, il faut plus de tests. La qualite vise la confiance, qui vient de la validation.
8. FAQ
Quelles sont les dimensions cles de la qualite des donnees ?
Completude, Exactitude, Coherence, Fraicheur, Validite, Unicite. Respectivement : pas de manquant, juste, meme format, suffisamment frais, respecte les regles, pas de doublons.
Comment mesurer la qualite ?
Tests auto : volumes, taux de null, unicite, fraicheur, drift de schema, regles metier. Suivre l evolution et definir des seuils d alertes.
Quels outils choisir ?
Great Expectations, tests dbt, Monte Carlo, Soda, elementary. Choisir selon le besoin : tests explicites vs detection d anomalies.
Tester avant ou apres les transformations ?
Les deux. Tests sources avant (fail fast) et tests de sortie apres pour valider la logique. On capture ainsi les erreurs a l entree comme a la sortie.
Documentez votre strategie Data Quality
Construisez des diagrammes clairs de vos pipelines avec des points de controle de qualite. Montrez aux parties prenantes ou et comment la validation se fait.
Guides lies
Documentation des pipelines
Documenter des pipelines que les nouveaux peuvent debuguer jour 1
Data Lineage Best Practices
Tracer les donnees de la source au dashboard
Data Contracts
Definir des SLAs de qualite avec des contrats
Architecture Medallion
Layeriser la qualite Bronze, Silver, Gold
Architecture pipeline ML
Appliquer le monitoring qualite aux features ML