Qualité des données en 2026 : au-delà des tests dbt basiques

Les quatre tests natifs de dbt (unique, not_null, accepted_values et relationships) ont marqué un tournant à leur lancement. Pour la première fois, les analytics engineers pouvaient versionner leurs assertions de qualité des données aux côtés de leurs transformations. Mais en 2026, ces tests sont un minimum requis, pas une stratégie de tests.

Le sondage 2025 de dbt Labs sur l’état de l’analytics engineering le confirme : 56 % des praticiens citent désormais la mauvaise qualité des données comme leur principal défi, contre 41 % en 2022. Et 38 % prévoient d’investir davantage dans les outils de qualité et d’observabilité des données cette année. La communauté a compris que quatre tests génériques ne suffisent pas pour des pipelines de production.

La bonne nouvelle : l’écosystème dbt a mûri pour répondre à ce besoin. Vous pouvez implémenter la détection d’anomalies, le monitoring de fraîcheur, la protection contre les dérives de schéma et les data contracts sans quitter votre projet dbt. Voici comment.

Les limites des tests natifs dbt

Avant d’ajouter des outils, il faut comprendre ce qui manque. Les tests natifs dbt ne s’exécutent qu’au moment du build. Ils vérifient si les données respectent des contraintes à l’instant T, mais ne suivent pas si le taux de réussite d’hier était normal. Ils ne peuvent pas vous dire si le nombre de lignes de votre table a chuté de 30 % par rapport à la moyenne hebdomadaire.

Prenons une table source qui reçoit normalement 10 000 lignes par jour. Un matin, elle en reçoit 2 000. Un test not_null sur la clé primaire passe. Un test unique passe. Chaque contrainte au niveau de la ligne que vous avez écrite passe. Mais vos dashboards en aval affichent désormais 80 % de données en moins.

Les tests natifs valident des règles. Les pipelines de production ont besoin de reconnaissance de patterns.

Six patterns de tests pour les pipelines de production

Les tests avancés se répartissent en six catégories, chacune ciblant un mode de défaillance spécifique.

Monitoring de fraîcheur

Vos données ne valent rien si elles sont périmées. Les tests de fraîcheur vérifient que les données arrivent dans les délais attendus.

dbt-expectations fournit expect_row_values_to_have_recent_data et expect_grouped_row_values_to_have_recent_data pour les assertions de SLA au niveau des tables et des partitions. Elementary complète avec freshness_anomalies, qui surveille le temps entre les mises à jour, et event_freshness_anomalies, qui suit le décalage entre le moment où un événement s’est produit et celui où il a été chargé.

tests:
  - dbt_expectations.expect_row_values_to_have_recent_data:
      column_name: loaded_at
      interval: 1
      interval_type: hour

Détection d’anomalies de volume

Quand des pipelines en amont échouent silencieusement, on n’obtient pas forcément zéro ligne. On en obtient moins. Les tests de volume établissent des baselines et signalent les écarts.

Le test volume_anomalies d’Elementary utilise des méthodes statistiques pour apprendre ce qui est « normal » pour chaque table. Il alerte quand le comptage du jour sort des bornes attendues. Pour les cas plus simples, dbt_expectations.expect_table_row_count_to_be_between permet une validation manuelle par seuils.

tests:
  - elementary.volume_anomalies:
      where: "event_date = current_date()"
      time_bucket:
        period: day
        count: 1

Détection de dérive de schéma

Un renommage de colonne dans votre système source casse tous les modèles qui la référencent. Les tests de schéma détectent ces changements avant qu’ils ne se propagent.

Le test schema_changes d’Elementary alerte sur les tables supprimées, les colonnes ajoutées ou supprimées, et les changements de type. La variante schema_changes_from_baseline valide par rapport à un schéma explicitement défini, ce qui est utile quand vous devez garantir une structure de colonnes précise pour les consommateurs en aval.

Vérifications de distribution

Certains problèmes de qualité des données sont invisibles pour les tests au niveau de la ligne. Une colonne float qui affiche habituellement une moyenne de 50 et passe soudainement à 500 satisfait toutes les contraintes, mais produit des rapports absurdes.

Les tests de distribution détectent les outliers statistiques sur des fenêtres temporelles. Le test dbt_expectations.expect_column_values_to_be_within_n_moving_stdevs repère les valeurs qui s’écartent des patterns historiques. Elementary suit les anomalies au niveau des colonnes sur plusieurs métriques : moyenne, écart-type, min, max, nombre de nulls, pourcentage de nulls, nombre de zéros et count distinct.

tests:
  - elementary.column_anomalies:
      column_name: order__amount
      column_anomalies:
        - average
        - max
      anomaly_sensitivity: 3

Validation sémantique

Les règles métier doivent figurer dans les tests, pas seulement dans la documentation. Les tests sémantiques encodent la logique métier directement.

Les tests regex comme expect_column_values_to_match_regex valident les contraintes de format : patterns d’email, numéros de téléphone, codes produit. Elementary a introduit la validation assistée par IA avec des attentes en langage naturel :

tests:
  - elementary.ai_data_validation:
      prompt: "There should be no contract date in the future"

Pour les règles métier complexes difficiles à exprimer en SQL, les tests en langage naturel permettent de capturer l’intention directement.

Tests unitaires pour la logique SQL

dbt 1.8 a introduit les tests unitaires natifs, qui valident la logique de transformation avec des entrées mock statiques avant que la requête ne touche votre warehouse. Contrairement aux tests de données qui s’exécutent sur des données réelles, les tests unitaires vérifient que votre SQL fait bien ce que vous attendez.

unit_tests:
  - name: test_revenue_calculation
    model: mrt__finance__orders
    given:
      - input: ref('base__shopify__orders')
        rows:
          - {order_id: 1, order__quantity: 2, order__unit_price: 10}
    expect:
      rows:
        - {order_id: 1, order__revenue: 20}

Les tests unitaires détectent les erreurs de logique sans coûts de compute warehouse et sans dépendre de données spécifiques dans votre environnement.

Les packages qui alimentent les tests avancés

Trois packages forment l’épine dorsale des tests dbt avancés.

dbt-expectations (actuellement en version 0.10.x, maintenu par Metaplane) fournit plus de 60 tests inspirés du framework Great Expectations. Il couvre les validations de schéma et regex, la fraîcheur des séries temporelles, les distributions statistiques et la logique inter-colonnes. Si vous ne devez ajouter qu’un seul package pour étendre les tests natifs, commencez par celui-ci.

dbt-utils (version 1.3.0) ajoute des macros utilitaires comme fewer_rows_than, at_least_one et cardinality_equality. Elles complètent dbt-expectations sans le remplacer.

Elementary (version 0.22.0) offre une observabilité native pour dbt avec détection d’anomalies intégrée. Plus de 5 000 professionnels de la data lui font confiance, et il fournit à la fois le framework de tests et le dashboard pour visualiser les résultats.

Le choix entre ces packages n’est pas exclusif. La plupart des projets matures utilisent dbt-expectations pour les tests explicites basés sur des règles et Elementary pour la détection d’anomalies et l’observabilité.

Data contracts : quand imposer le schéma

dbt a introduit les data contracts natifs en version 1.5. Une fois activés, ils imposent la structure des colonnes à chaque dbt build, échouant immédiatement en cas de violation avant que les données ne soient écrites.

models:
  - name: mrt__core__customers
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: string
        constraints:
          - type: not_null
          - type: unique
      - name: customer__email
        data_type: string
      - name: customer__created_at
        data_type: timestamp

Trois types de contracts se sont imposés en pratique :

  • Les schema contracts imposent les noms de colonnes, les types de données, l’ordre et la précision
  • Les semantic contracts valident les écarts de métriques, la logique métier et l’intégrité référentielle
  • Les SLA contracts vérifient les attentes de fraîcheur et les calendriers de mise à jour

Le retour d’expérience des équipes qui utilisent les contracts : ils sont « conçus pour ralentir les gens ». Cette friction est intentionnelle. Appliquez les contracts de manière stratégique sur les modèles publics à haute criticité (les marts qui alimentent les dashboards de la direction, les tables qui servent au reporting réglementaire) plutôt que partout. La friction est acceptable là où le coût d’une rupture est élevé.

Détection d’anomalies par ML

Les tests basés sur des règles vous obligent à anticiper les modes de défaillance. La détection par ML apprend ce qui est « normal » et alerte sur des écarts que vous n’aviez pas prévus.

Elementary utilise une détection basée sur le Z-score avec une sensibilité configurable. Une sensibilité de 3 signifie qu’une alerte se déclenche quand les valeurs s’écartent de plus de 3 écarts-types de la moyenne. Cela fonctionne bien dans la plupart des cas, mais ne peut pas s’adapter aux patterns saisonniers complexes.

tests:
  - elementary.column_anomalies:
      column_anomalies:
        - average
      anomaly_sensitivity: 2
      training_period:
        period: day
        count: 14

Des outils plus sophistiqués comme Monte Carlo et Anomalo utilisent du ML avancé qui apprend des patterns historiques, en gérant automatiquement la saisonnalité et les changements de tendance. Les clients de Monte Carlo rapportent une réduction de 80 % du temps d’indisponibilité des données. Ces solutions ont un coût et une complexité d’intégration plus élevés.

Pour la plupart des équipes centrées sur dbt, l’approche d’Elementary offre le meilleur compromis : une détection d’anomalies pertinente sans quitter l’écosystème dbt ni ajouter de coûts significatifs.

Intégrer les contrôles qualité dans le CI/CD

Tester en production détecte les problèmes, mais tester en CI les empêche d’atteindre la production.

Le pattern Slim CI de dbt Cloud n’exécute que les modèles modifiés et leurs dépendances en aval :

Terminal window
dbt build --select state:modified+ --defer --state ./

Ce mécanisme utilise la comparaison de manifestes pour éviter de rebuilder les modèles inchangés, ce qui réduit considérablement les coûts de compute tout en détectant les régressions.

Pour GitHub Actions ou des systèmes CI similaires :

name: dbt CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint SQL
        run: sqlfluff lint models/
      - name: Build and test modified models
        run: dbt build --select state:modified+ --defer --state ./
      - name: Run data tests
        run: dbt test

Outils qui améliorent les workflows CI :

  • Datafold compare les données entre votre branche PR et la production, en détectant les changements de valeurs qui passent les tests de schéma
  • Recce analyse le lineage au niveau des colonnes pour catégoriser les changements comme breaking, partiellement breaking ou non-breaking
  • SQLFluff assure la cohérence du style SQL

Une étude Forrester Total Economic Impact a constaté un gain de productivité de 30 % pour les développeurs et 60 % d’économies sur le temps de reprise des données pour les équipes adoptant dbt Cloud avec des workflows CI.

Ce que ça coûte en pratique

L’investissement dans la qualité des données n’est pas abstrait. Le sondage 2025 de dbt Labs révèle que les analytics engineers consacrent encore 57 % de leur temps à maintenir et organiser les datasets plutôt qu’à développer de nouvelles fonctionnalités.

À l’échelle du secteur, les chiffres sont éloquents : les organisations perdent environ 12,9 millions de dollars par an à cause de la mauvaise qualité des données, selon Gartner. Un sondage Monte Carlo indique que les data engineers consacrent 40 % de leur temps de travail aux problèmes de qualité des données.

Des incidents retentissants illustrent les enjeux :

Un sondage Monte Carlo a révélé que le temps d’indisponibilité des données a presque doublé d’une année sur l’autre, avec un temps de résolution en hausse de 166 %. La prévention coûte bien moins cher que la remédiation.

Par où commencer

Inutile de tout implémenter d’un coup. Choisissez un pattern en fonction de votre problème actuel :

Si vos dashboards deviennent obsolètes sans prévenir : commencez par le monitoring de fraîcheur. Ajoutez freshness_anomalies d’Elementary à vos sources les plus critiques.

Si des changements en amont cassent vos modèles : implémentez la détection de dérive de schéma. Les tests schema_changes détectent les problèmes avant qu’ils ne se propagent.

Si vous avez déjà été impacté par des baisses de volume : ajoutez volume_anomalies aux tables qui reçoivent des chargements réguliers.

Si vous devez garantir un contrat envers les consommateurs en aval : activez les data contracts sur vos marts publics.

L’écosystème dbt a dépassé le stade des tests basiques. Les outils existent, ils sont matures et s’intègrent directement dans votre workflow existant. Choisissez celui qui résout votre problème le plus urgent aujourd’hui.