Aucun outil unique ne couvre l’ensemble du pipeline de la source à la consommation. Les couches de validation de la qualité des données décrivent quels types de vérifications vous avez besoin (contrats, tests, détection d’anomalies). Les couches d’application du pipeline décrivent où ces vérifications s’exécutent. L’approche pratique est la défense en profondeur, où chaque couche attrape ce que la précédente a manqué.
Les quatre couches
Couche 1 : Pré-warehouse
C’est le point d’application le plus précoce — avant que les données n’atteignent votre warehouse.
Les registres de schéma appliquent la compatibilité sur les flux d’événements. Quand un producteur Kafka essaie de publier un message qui viole le schéma enregistré, le message est rejeté. Les données invalides n’atteignent jamais aucun consommateur.
Les outils EL avec support des contrats rejettent les mauvaises données pendant l’extraction et le chargement. Les modes de contrat de schéma de dlt (freeze, evolve, discard_rows, discard_columns) fournissent un contrôle granulaire par type d’entité. Si une API commence à retourner un nouveau champ ou change le type d’un champ, le pipeline échoue avant que quoi que ce soit n’atteigne le warehouse.
Fivetran et Airbyte offrent un contrôle limité à cette couche. Fivetran fournit des notifications de changement de schéma et un paramètre de blocage sans nuance. Le mode “Detect and manually approve” d’Airbyte met en pause les connexions pour révision lors de changements cassants mais nécessite une intervention humaine.
La couche pré-warehouse est la plus puissante car elle empêche les mauvaises données d’exister dans votre warehouse. C’est aussi la plus difficile à adopter, car elle nécessite soit de contrôler le système source (registre de schéma) soit d’utiliser un outil EL avec support natif des contrats (dlt).
Couche 2 : Post-chargement, pré-transformation
Entre “les données arrivent dans le warehouse” et “dbt construit des modèles dessus”, il y a une fenêtre pour la vérification des contrats.
Soda Data Contracts fournit un moteur de contrats dédié basé sur YAML. Vous exécutez les vérifications Soda après que votre outil EL a fini de charger et avant que dbt run commence. Si le schéma d’une table source a dérivé ou si les règles de qualité échouent, le pipeline s’arrête avant que la transformation commence.
Cette couche est particulièrement utile quand plusieurs projets dbt consomment les mêmes tables sources. Au lieu que chaque projet exécute des tests sources redondants, une seule étape de vérification Soda valide les données une fois, à la frontière.
Couche 3 : Transformation
C’est là que la plupart des équipes analytics ont déjà une application, car c’est là qu’opère dbt.
Les contrats natifs dbt sur les modèles de base détectent les inadéquations structurelles au moment de la compilation. Si une colonne source est manquante ou que son type a changé, le modèle échoue à se construire. Jeremy Cohen a recommandé de mettre des contrats sur les modèles de base se trouvant juste au-dessus des sources comme point de capture principal.
Les tests dbt-expectations sur les sources valident les ensembles de colonnes et les plages de valeurs. expect_table_columns_to_match_set détecte les colonnes ajoutées ou supprimées. expect_column_values_to_be_in_set valide les contraintes de contenu. Ceux-ci s’exécutent pendant dbt build, après que les données ont été chargées.
Elementary détecte les changements de schéma et les anomalies pendant l’exécution dbt. La détection des changements de schéma alerte sur les tables supprimées, les colonnes ajoutées ou supprimées, et les changements de type. Les tests d’anomalies de volume et de fraîcheur détectent les écarts statistiques par rapport aux baselines historiques.
La couche de transformation est réactive — elle valide les données déjà dans le warehouse. Mais c’est là où la plupart des équipes commencent, car cela s’appuie sur des outils que vous avez déjà (dbt) sans nécessiter d’infrastructure supplémentaire.
Couche 4 : Observabilité continue
Après que les modèles sont construits et publiés, la surveillance continue détecte la dérive et la dégradation dans les tables de production.
Des outils comme Elementary, Monte Carlo, ou Soda Cloud surveillent en continu les anomalies de volume, les problèmes de fraîcheur, les changements de distribution, et la dérive de schéma. Cette couche opère indépendamment des exécutions de pipeline — elle surveille l’état de votre data warehouse en permanence et alerte quand quelque chose change.
La quatrième couche attrape les problèmes qui passent à travers les trois premières : dégradation graduelle de la qualité, dérive lente du schéma, anomalies liées à la saisonnalité. C’est le filet de sécurité pour tout ce que les vérifications explicites ne couvrent pas.
Par où commencer
Vous n’avez pas besoin des quatre couches dès le premier jour. Commencez par la couche la plus proche de là où vous ressentez de la douleur.
Pour la plupart des équipes analytics, commencez par la couche 3. Vous avez déjà dbt. Ajouter des tests sources dbt-expectations à vos cinq sources les plus critiques prend un après-midi et attrape les cassures les plus courantes — dérive des colonnes, valeurs inattendues, changements structurels. Combiner cela avec des contrats sur les modèles de base vous donne une protection à la compilation gratuitement.
Si les changements de schéma source sont votre principal problème, investissez dans la couche 1. Si vous évaluez des outils EL, prenez en compte le support des contrats de schéma — les contrats natifs de dlt sont un vrai différenciateur par rapport aux options limitées de Fivetran et Airbyte. Si vous êtes lié à Fivetran ou Airbyte, passez à la couche 2 avec la vérification Soda.
Si plusieurs projets consomment les mêmes sources, ajoutez la couche 2. La vérification des contrats Soda vous donne une porte centralisée entre le chargement et la transformation, plutôt que des tests sources redondants dans chaque projet.
Ajoutez la couche 4 une fois la fondation solide. L’observabilité continue est la plus utile quand vous avez suffisamment de couverture dans les trois premières couches pour que la détection d’anomalies attrape de vraies surprises plutôt que des problèmes que vous auriez dû anticiper avec des tests explicites.
Intégration CI/CD
Les couches se connectent via CI/CD. Un pipeline bien structuré exécute les étapes dans l’ordre, avec chaque étape conditionnant la suivante :
- Vérifications de fraîcheur des sources — vérifier que les sources ont été mises à jour dans les fenêtres attendues
- Vérification Soda (si vous l’utilisez) — valider les schémas sources et les règles de qualité
dbt buildavec contrats et tests — application des contrats à la compilation, puis construction des modèles avec tests- Détection d’anomalies Elementary — vérifications statistiques par rapport aux baselines historiques
Le flag --empty dans dbt 1.8+ est particulièrement utile pour le CI : dbt build --select state:modified+ --empty --defer --state ./ effectue des exécutions à sec de schéma uniquement sans traiter les données. Cela maintient le CI rapide tout en validant que les contrats sont satisfaits et que les modèles se compilent correctement. La construction complète des données s’exécute en production ; le CI valide les contrats.
Relation avec les couches de validation
Cette note décrit où l’application se produit (pré-warehouse, post-chargement, transformation, observabilité). La note sur les couches de validation de la qualité des données décrit quel type d’application c’est (contrats proactifs, tests réactifs, détection d’anomalies). Les deux frameworks se superposent :
| Type de validation | Pré-warehouse | Post-chargement | Transformation | Observabilité |
|---|---|---|---|---|
| Contrats proactifs | Registre de schéma, dlt freeze | Vérifications contrats Soda | Contrats modèles dbt | — |
| Tests réactifs | — | Règles de qualité Soda | dbt-expectations, tests dbt | — |
| Détection d’anomalies | — | — | Elementary (pendant le build) | Elementary, Monte Carlo |
L’insight est que la prévention proactive est possible à chaque étape du pipeline, pas seulement à la source. Les contrats de modèles dbt sont proactifs dans la couche de transformation (ils empêchent les mauvais modèles de se matérialiser). Les contrats Soda sont proactifs à la frontière du warehouse (ils empêchent la transformation de commencer sur de mauvaises données). Chaque couche ajoute un point de défense.
Vers où cela évolue
Le paysage de l’application évolue vers la validation au moment de l’écriture — rejeter les mauvaises données avant qu’elles ne soient persistées plutôt que les vérifier après qu’elles ont atterri. Les registres de schéma fonctionnent déjà ainsi pour les flux d’événements. dlt le fait pour les pipelines batch. Le manque reste dans les outils EL managés, où Fivetran et Airbyte ajoutent lentement des contrôles plus granulaires mais n’y sont pas encore.
La dimension organisationnelle s’applique également à l’application en amont. Ajouter des vérifications Soda ou des contrats de schéma dlt est une décision technique. Amener l’équipe qui possède l’API à participer aux définitions des contrats en est une organisationnelle. L’approche en couches aide car vous pouvez commencer à appliquer là où vous avez le contrôle (votre projet dbt, votre configuration EL) et vous étendre vers l’extérieur au fur et à mesure que la culture des contrats s’installe.