Qualité des données : définition, tests et outils pour la contrôler

Tester la qualité des données, c'est vérifier que les données sont complètes, exactes, cohérentes, uniques, valides et à jour avant que quiconque ne s'appuie dessus. Concrètement, on écrit des assertions automatisées sur les jeux de données, comme « cette colonne n'est jamais vide », « cet identifiant est unique » ou « le chargement d'hier est bien arrivé », et on les exécute à chaque étape du pipeline avec des outils comme Great Expectations, les tests dbt ou Soda. Ce guide présente les dimensions de la qualité des données, les contrôles à poser à chaque étape et la comparaison des principaux outils.

Qu'est-ce que la qualité des données ?

La qualité des données désigne l'aptitude d'un jeu de données à servir l'usage auquel il est destiné : alimenter un tableau de bord, une facture, un reporting réglementaire ou un modèle d'apprentissage automatique. Une donnée n'est pas « bonne » dans l'absolu ; elle est bonne si elle respecte des attentes explicites sur son contenu, sa structure et sa date de mise à jour.

Qu'est-ce qu'un test de qualité des données ?

Un test de qualité des données est la vérification automatisée qu'un jeu de données respecte ces attentes. Chaque attente est une règle qui passe ou échoue, par exemple « commande_id est unique » ou « montant est strictement positif ». Un échec arrête le pipeline ou alerte le responsable de la donnée avant que l'erreur n'atteigne un tableau de bord, un rapport ou un modèle d'IA.

Quelles sont les dimensions de la qualité des données ?

Les dimensions les plus utilisées sont la complétude, l'exactitude, la cohérence, l'unicité, la validité et la fraîcheur. Chacune se traduit en contrôles concrets et automatisables.

En quoi le test de données diffère-t-il du test logiciel ?

Les tests logiciels vérifient du code avec des entrées fixes ; les tests de qualité des données vérifient des données qui changent chaque jour, même quand aucune ligne de code n'a bougé. Une transformation peut être parfaitement correcte et produire pourtant des résultats faux parce qu'un système amont a envoyé un fichier vide ou une nouvelle catégorie. Il faut donc les deux : des tests unitaires sur la logique de transformation, exécutés en CI à chaque commit, et des contrôles de données exécutés en production à chaque chargement. Notre guide sur l'intégration des tests dans un pipeline CI/CD couvre la première partie, et notre page Automatisation des tests : définition, outils, étapes replace ces deux familles dans une stratégie de test complète.

Quels contrôles poser à chaque étape d'un pipeline de données ?

Validez tôt et à chaque passage de relais, pour attraper un problème là où il entre plutôt que dans le rapport final.

1. Ingestion : vérifier le schéma et les types à l'arrivée des données, avec des contrats de données exprimés en JSON Schema, Avro ou modèles Pydantic ; rejeter ou mettre en quarantaine les enregistrements invalides.
2. Transformation : tester les sorties des traitements dbt ou Spark sur les clés, les relations entre tables et les règles métier.
3. Chargement : rapprocher les volumes et les totaux entre la source et la cible, et vérifier l'absence de doublons introduits par une relance.
4. Consommation : surveiller la fraîcheur et les indicateurs clés utilisés par les tableaux de bord, et alerter quand ils sortent des bornes attendues.

Qu'est-ce que Great Expectations ?

Great Expectations est un framework Python open source de validation de données. On y déclare des « Expectations » comme expect_column_values_to_not_be_null ou expect_column_values_to_be_between, on les regroupe en suites, puis on valide des lots de données issus de fichiers, de dataframes ou de bases SQL. Les résultats de validation peuvent être rendus sous forme de « Data Docs » lisibles par des humains. Il convient aux pipelines écrits en Python et aux équipes qui veulent des contrôles de données écrits en code.

Comment fonctionnent les tests dbt ?

Dans dbt, un test de données est une requête qui renvoie les lignes qui violent une règle : si la requête ne renvoie aucune ligne, le test passe. Quatre tests génériques sont intégrés, unique, not_null, accepted_values et relationships, et se déclarent en YAML à côté du modèle :

models:
  - name: commandes
    columns:
      - name: commande_id
        data_tests:
          - unique
          - not_null

Les tests singuliers sont des fichiers SQL personnalisés pour les règles métier :

-- tests/montant_positif.sql : échoue si la requête renvoie des lignes
select *
from {{ ref('commandes') }}
where montant <= 0

dbt test exécute les tests, et dbt build exécute modèles et tests dans l'ordre des dépendances : un test en échec empêche la construction des modèles situés en aval.

Qu'est-ce que Soda ?

Soda est un outil de qualité des données dont le moteur open source, Soda Core, exécute des contrôles écrits en SodaCL, un langage basé sur YAML, sur des sources comme PostgreSQL, Snowflake ou BigQuery :

checks for commandes:
  - row_count > 0
  - missing_count(email) = 0
  - duplicate_count(commande_id) = 0

Ces contrôles, comme les seuils de fraîcheur, sont lisibles par les analystes autant que par les ingénieurs, ce qui fait de Soda un bon choix quand les équipes métier participent à la définition des règles.

Great Expectations, tests dbt ou Soda : lequel choisir ?

Si vos transformations vivent déjà dans dbt, commencez par les tests de données dbt ; ajoutez Great Expectations pour les pipelines Python et les contrôles statistiques plus riches, ou Soda pour des contrôles lisibles sur des entrepôts partagés avec les équipes métier.

Quels indicateurs de qualité des données surveiller ?

Surveillez quelques indicateurs sur les tables qui comptent le plus pour le métier, plutôt que tout, partout :

• Taux de nullité des champs obligatoires ;
• Taux de doublons sur les clés ;
• Volumétrie comparée au volume attendu ;
• Délai depuis le dernier chargement réussi ;
• Distribution des principales valeurs numériques.

Un décalage soudain de distribution révèle souvent une source amont cassée avant même qu'une règle n'échoue ; les méthodes statistiques et d'apprentissage automatique qui détectent ces anomalies sont présentées dans notre article IA et Machine Learning pour les tests.

Comment démarrer les tests de qualité des données ?

Choisissez vos tables les plus critiques et ajoutez-leur cinq contrôles : clés non nulles, clés uniques, volumétrie au-dessus d'un minimum, fraîcheur dans le délai convenu et valeurs autorisées sur les principales colonnes de statut. Exécutez-les après chaque chargement, envoyez les échecs au responsable de la table, et ajoutez un contrôle chaque fois qu'un incident révèle un trou. Les techniques de données de test issues du test logiciel aident aussi : voir notre guide du Data-Driven Testing.

Questions fréquentes