La qualité des données ne se décrète pas, elle se construit. Attendre que les utilisateurs finaux découvrent des erreurs dans un dashboard est la pire des stratégies. La bonne approche est d’intégrer des tests de qualité directement dans les pipelines de données. De petites vérifications automatisées, exécutées à chaque étape, permettent de stopper les anomalies à la source, avant qu’elles ne contaminent tout l’écosystème analytique.
déplacer la qualité à gauche
L’objectif est de passer d’une détection tardive par les humains à une prévention précoce par le code.
prérequis
- Une suite de tests intégrée à votre outil d’orchestration (ex: dbt, Great Expectations).
- Des jeux de données de référence figés pour valider les transformations complexes.
- Une culture où un pipeline qui échoue à cause d’un test est une victoire, pas un problème.
idées clefs
Les tests de qualité efficaces couvrent plusieurs dimensions. Ils ne se limitent pas à vérifier le code, mais la donnée elle-même.
pas à pas
étape 1: valider le schéma et les types
C’est la base. Assurez-vous que la structure de vos données est celle que vous attendez. Des outils comme dbt rendent cela extrêmement simple.
# tests/schema.yml
# dbt va automatiquement traduire cela en tests SQL.
models:
- name: orders_v
columns:
- name: order_id
tests:
- unique
- not_null
- name: order_status
tests:
- accepted_values:
values: ['placed', 'shipped', 'completed', 'returned']
- name: amount_eur
description: "Doit toujours être positif."
tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
étape 2: vérifier les bornes et l’unicité
Allez au-delà du schéma pour tester la logique métier. Par exemple, un prix ne peut pas être négatif, et un email de client doit être unique.
-- test/assert_no_duplicate_customers.sql
-- Un test dbt personnalisé simple.
-- Le test passe si cette requête ne retourne aucune ligne.
SELECT
email,
COUNT(*) as email_count
FROM
{{ ref('customers') }}
GROUP BY
email
HAVING
email_count > 1
étape 3: surveiller la fraîcheur
Un test de fraîcheur vérifie que vos données sources ont bien été mises à jour récemment. C’est crucial pour les dashboards opérationnels.
-- test/assert_orders_are_fresh.sql
-- Le test échoue si la commande la plus récente a plus de 24 heures.
SELECT
MAX(order_date) as latest_order_date
FROM
{{ ref('orders_v') }}
HAVING
latest_order_date < CURRENT_DATE - INTERVAL '24 hour'
pièges frequents
-
Symptôme: La suite de tests prend des heures à tourner et signale des problèmes non pertinents.
- Cause: Tests trop bavards et pas ciblés.
- Correctif: Concentrez-vous sur l’essentiel. Mieux vaut 5 tests critiques qui bloquent la CI que 200 tests qui génèrent du bruit.
-
Symptôme: Les tests échouent de manière aléatoire, surtout ceux qui comparent des distributions.
- Cause: Les tests sont exécutés sur des données de production qui changent constamment.
- Correctif: Pour les tests complexes, utilisez des jeux de données de référence figés (“golden datasets”) qui garantissent un résultat stable.
-
Symptôme: Un test échoue, mais le pipeline continue et produit des données de mauvaise qualité.
- Cause: L’orchestrateur n’est pas configuré pour s’arrêter en cas d’échec de test.
- Correctif: Adopter le principe du “fail fast”. Un échec de test de qualité doit être considéré comme une erreur bloquante qui arrête immédiatement le DAG.
faq
-
Quelle est la différence entre dbt tests et Great Expectations ? Ils sont complémentaires. dbt est excellent pour les tests qui peuvent être exprimés en SQL et qui vivent avec votre code de transformation. Great Expectations est plus puissant pour les tests statistiques complexes (distribution, corrélation) et la génération automatique de documentation de qualité (“data docs”).
-
Par où commencer si je n’ai aucun test ? Commencez par le plus simple et le plus rentable : ajoutez des tests
uniqueetnot_nullsur les clés primaires de vos 5 tables les plus importantes. Cela prend 10 minutes et élimine déjà une classe entière de problèmes.