Couches de validation de la qualité des données

La qualité des données se décompose en trois problèmes distincts qui opèrent à différents moments du cycle de vie des données, nécessitent des outils différents et capturent différentes catégories de défaillances. Traiter la « qualité des données » comme une préoccupation unique produit soit des solutions sur-ingéniérées, soit des lacunes où des catégories entières de problèmes passent inaperçues.

Les trois couches

Couche 1 : Prévention proactive (Contrats)

Les data contracts agissent avant que les données ne circulent. Ils établissent des accords entre producteurs et consommateurs qui empêchent certaines catégories de problèmes de se produire.

Un contrat peut stipuler qu’un événement payments inclut toujours amount comme décimal positif, currency comme code ISO à trois lettres, et customer_id comme chaîne non nulle. Si un développeur tente de déployer un changement qui supprime le champ currency ou change amount en chaîne, l’application du contrat bloque le déploiement. Le pipeline analytique ne voit jamais le changement cassant.

Ce que cette couche détecte :

• Les changements cassants de schéma à la source
• Les suppressions de champs, changements de type, renommages
• Les violations de SLA (données trop périmées, pipeline en panne)
• Les modifications non autorisées des structures de données convenues

Ce que cette couche manque :

• Les données structurellement correctes mais sémantiquement erronées (le montant est un décimal positif, mais dans la mauvaise devise)
• La dégradation progressive de la qualité (les taux de null augmentent lentement dans les tolérances)
• Les bugs de transformation dans votre propre pipeline
• Les nouvelles anomalies sans pattern antérieur

Outils : Contrats ODCS, Schema Registry (Kafka, PubSub), Data Contract CLI, Gable.ai

Couche 2 : Validation réactive (Tests)

Les tests de schéma et les vérifications de qualité des données valident les données après leur arrivée — après l’extraction, après la transformation, après le chargement. Ils sont réactifs : ils détectent les problèmes qui existent déjà plutôt que de les prévenir.

Cette couche comprend deux sous-couches :

La validation structurelle vérifie si la forme des données est correcte. Les clés primaires sont uniques. Les clés étrangères référencent des parents valides. Les champs obligatoires sont renseignés. Les champs catégoriels contiennent les valeurs attendues. Ce sont les tests génériques que vous appliquez à chaque modèle.

models:
  - name: mrt__finance__payments
    columns:
      - name: payment_id
        data_tests:
          - unique
          - not_null
      - name: customer_id
        data_tests:
          - relationships:
              to: ref('mrt__core__customers')
              field: customer_id
      - name: status
        data_tests:
          - accepted_values:
              values: ['pending', 'completed', 'failed', 'refunded']

La validation de contenu vérifie si les valeurs des données sont raisonnables. Les revenus sont positifs. Les dates ne sont pas dans le futur. Les adresses e-mail correspondent à une regex. Les taux de conversion se situent dans des plages attendues. Ces vérifications nécessitent une connaissance métier et utilisent typiquement des packages comme dbt-expectations :

columns:
  - name: amount
    data_tests:
      - dbt_expectations.expect_column_values_to_be_between:
          min_value: 0
          strictly: true
      - dbt_expectations.expect_column_mean_to_be_between:
          min_value: 10
          max_value: 10000
  - name: email
    data_tests:
      - dbt_expectations.expect_column_values_to_match_regex:
          regex: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
          row_condition: "email IS NOT NULL"

Ce que cette couche détecte :

• Les violations structurelles (doublons, nulls, enregistrements orphelins)
• Les violations de règles métier (valeurs invalides, combinaisons impossibles)
• Les bugs de transformation qui produisent des sorties incorrectes
• Les incohérences cross-tables

Ce que cette couche manque :

• Les problèmes non anticipés (on ne teste que ce qu’on pense à tester)
• La dérive graduelle qui reste dans les seuils
• Les changements en amont qui produisent des données valides mais différentes
• Les problèmes qui ne violent aucune règle explicite

Outils : Tests génériques dbt, tests unitaires dbt, dbt-expectations, dbt-utils, Great Expectations, Soda

Couche 3 : Détection des anomalies (Monitoring)

La détection des anomalies capture ce qu’on n’a pas pensé à tester. Plutôt que de définir des règles explicites, on entraîne une baseline à partir des données historiques et on alerte quand les données actuelles s’en écartent significativement.

Elementary est l’outil le plus courant natif à dbt pour cette couche. Il utilise les statistiques Z-score : si une métrique s’éloigne de plus de N écarts-types de sa moyenne historique, une alerte est déclenchée.

models:
  - name: mrt__finance__payments
    tests:
      - elementary.volume_anomalies:
          time_bucket:
            period: day
            count: 1
      - elementary.freshness_anomalies
    columns:
      - name: amount
        tests:
          - elementary.column_anomalies:
              column_anomalies:
                - average
                - null_count
                - zero_count
              anomaly_sensitivity: 3
              training_period:
                period: day
                count: 14

Ce que cette couche détecte :

• Les chutes ou pics de volume (une source arrête d’envoyer des données, ou en envoie 10 fois plus que d’habitude)
• Les glissements de distribution (la valeur moyenne des commandes chute soudainement de 40 %)
• La dégradation de la fraîcheur (des données qui se mettent à jour normalement toutes les heures n’ont pas été mises à jour depuis 6 heures)
• La dérive de schéma (de nouvelles colonnes apparaissent, des colonnes disparaissent)
• Les anomalies saisonnières que des seuils statiques manqueraient

Ce que cette couche manque :

• Les changements lents et progressifs qui restent dans la fenêtre d’entraînement
• Les problèmes de première occurrence sans baseline de comparaison
• Les problèmes dans les datasets nouvellement créés avec un historique insuffisant
• Les problèmes où l’état anormal devient la nouvelle normale (la baseline s’adapte)

Outils : Elementary, Monte Carlo, Bigeye, Anomalo, Metaplane

Pourquoi les trois sont nécessaires

Chaque couche a des angles morts que couvre une autre couche :

Le modèle à trois couches correspond à différents rôles organisationnels :

• Les contrats requièrent une coordination inter-équipes (les producteurs et consommateurs s’accordent sur les termes)
• Les tests requièrent une connaissance métier (les analytics engineers définissent les règles métier)
• La détection des anomalies requiert une configuration initiale mais s’exécute ensuite de façon autonome

Le chemin de maturité

La plupart des équipes devraient construire ces couches dans l’ordre inverse de la liste ci-dessus :

Commencez par les tests. Ajoutez unique et not_null à chaque clé primaire. Ajoutez relationships sur les clés étrangères critiques. Installez dbt-expectations pour les vérifications de plage et de pattern. C’est un travail du premier jour avec une valeur immédiate.

Ajoutez la détection des anomalies. Installez Elementary et activez les tests de volume, fraîcheur et anomalies de colonne sur vos modèles les plus critiques. Cela capture les « inconnues inconnues » que les tests explicites manquent. La configuration prend 2 à 5 jours.

Ajoutez ensuite les contrats. Commencez avec les contrats de modèles natifs de dbt sur les modèles marts publics. Étendez aux contrats ODCS quand vous avez besoin de formaliser des accords avec des équipes extérieures à votre projet dbt. C’est la couche la plus coûteuse en effort et la plus valeur, et elle nécessite un engagement organisationnel au-delà de l’équipe data.

L’ordre inversé — les contrats sont la couche la plus puissante mais adoptée en dernier — reflète une contrainte pratique : les contrats nécessitent une coordination inter-équipes, qui nécessite une crédibilité organisationnelle, qui nécessite des pratiques de qualité des données démontrées. Les équipes qui commencent par les contrats avant d’établir tests et monitoring échouent souvent car elles ne peuvent pas démontrer la valeur pour laquelle elles demandent aux autres équipes d’investir.