Aller au contenu
Qualité des données

Qualité des données et contrats

Les tests de qualité vérifient automatiquement qu'une table respecte ce qu'on attend d'elle : clés uniques, valeurs présentes, données fraîches, volume normal. On les lance à chaque chargement.

  • qualité
  • test
  • unicité
  • non-nullité
  • fraîcheur
  • volume
  • contrat de données
  • data contract

Syntaxe

Modèle
Convention : un test est une requête qui renvoie les lignes en faute.  0 ligne  → test réussi  ≥ 1 ligne → test en échec (bloquer ou alerter selon la gravité)Unicité      SELECT cle, COUNT(*) FROM t GROUP BY cle HAVING COUNT(*) > 1Non-nullité  SELECT * FROM t WHERE colonne IS NULLFraîcheur    dernière date chargée plus vieille que le seuil convenuVolume       nombre de lignes du lot hors de la plage habituelleContrat de données : schéma, types, sens des colonnes, fraîcheur promiseet responsable, convenus entre producteur et consommateurs, versionnés.

Exemple

Exemple concret
CREATE TABLE commandes (commande_id INTEGER, client_id TEXT, montant REAL, charge_le TEXT);INSERT INTO commandes VALUES  (1, 'C1',  120.0, '2026-11-01 04:10'),  (2, 'C2',   45.0, '2026-11-01 04:10'),  (2, 'C2',   45.0, '2026-11-01 04:10'),   -- doublon  (3, NULL,   80.0, '2026-11-01 04:10');   -- client manquant-- Unicité de commande_idSELECT commande_id, COUNT(*) AS n FROM commandesGROUP BY commande_id HAVING COUNT(*) > 1;-- 2 | 2        → échec-- Non-nullité de client_idSELECT * FROM commandes WHERE client_id IS NULL;-- 3 | NULL | 80.0 | 2026-11-01 04:10   → échec-- Fraîcheur : retard de plus de 6 h ? (heure du contrôle : 2026-11-01 07:00)SELECT * FROM (  SELECT MAX(charge_le) AS dernier,         ROUND((julianday('2026-11-01 07:00') - julianday(MAX(charge_le))) * 24, 1) AS retard_h  FROM commandes) WHERE retard_h > 6;-- aucune ligne → réussi (retard de 2,8 h)-- Volume : un lot normal compte environ 1 000 lignesSELECT COUNT(*) AS nb FROM commandes HAVING COUNT(*) < 500;-- 4        → échec : lot probablement tronqué

À retenir

  1. Distinguez les tests bloquants (clé en double dans une table de faits) des avertissements (quelques valeurs manquantes dans une colonne secondaire) : tout bloquer rend le pipeline fragile, tout tolérer le rend inutile.
  2. Les seuils de volume se calent sur l'historique (moyenne des derniers jours, jour de la semaine) plutôt que sur une valeur fixe qui devient fausse dès que l'activité change.
  3. Un contrat de données se vérifie chez le producteur, avant publication : dbt (contrats de modèles), Great Expectations ou Soda permettent de l'automatiser.
  4. Piège : ne tester que la table finale. Une erreur repérée dans les marts oblige à remonter toute la chaîne ; testez dès la couche staging, au plus près de la source.

Voir aussi