Dans un projet de transformation de données, nous travaillons avec différentes sources, souvent alimentées par la brique d’ingestion de données de notre organisation. Ces sources peuvent être gérées par une équipe de Data Engineers ou par des outils dédiés comme Fivetran ou Airbyte, qui automatisent l’ingestion des données dans notre entrepôt.

Dans les différentes entreprises où j’ai eu l’occasion d’intervenir, j’ai souvent observé une confiance aveugle accordée à ces sources de données. Pourtant, j’ai aussi constaté à maintes reprises que les erreurs dans le pipeline de données provenaient fréquemment de sources contenant des données erronées, ce qui pouvait impacter directement la qualité des analyses et la prise de décision.

Dans cet article, je vous propose d’explorer les erreurs causées par des sources de données de mauvaise qualité et de voir comment s’en prémunir efficacement.

Pourquoi une source de données n’est jamais totalement fiable ?

Selon moi, il existe trois raisons principales pour lesquelles une source de données ne peut jamais être fiable à 100 %.

1. Les erreurs humaines en amont

Une grande partie des sources de données proviennent d’une saisie manuelle, ce qui introduit naturellement un facteur d’erreur. C’est souvent le cas dans les outils comme les CRM, où les commerciaux saisissent le statut des clients, les montants des transactions, ou encore dans les systèmes de Customer Care, où les équipes classent des tickets manuellement.

Toutes ces interventions humaines sont sujettes à des erreurs, parmi lesquelles :

Mauvaise saisie des données (fautes de frappe, oublis, erreurs de catégorisation).
Erreurs de configuration des systèmes sources, entraînant des enregistrements incohérents.
Mauvaise compréhension des besoins métiers, ce qui peut conduire à des valeurs mal renseignées ou inutilisables.

2. Les problèmes techniques

Si l'humain est faillible, la machine l’est aussi ! Les systèmes automatisés d’ingestion ne sont pas exempts d’erreurs, et on observe régulièrement des problèmes tels que :

Pannes des systèmes d’ingestion (API indisponibles, connecteurs en échec, jobs ETL non exécutés).
Données incomplètes ou corrompues lors des transferts.
Retards ou échecs d’actualisation, qui entraînent une obsolescence des données.

3. Les changements de structure des sources

Un autre problème courant vient des changements non anticipés dans les sources de données. Les équipes en charge des sources effectuent parfois des modifications sans avertir les équipes aval, provoquant des erreurs critiques dans les pipelines.

Voici quelques exemples typiques de ces changements :

Modification des schémas de base de données sans notification préalable.
Ajout ou suppression de colonnes qui brise la logique des transformations en aval.
Évolution des règles métiers appliquées aux données, entraînant des incohérences dans les analyses.

Les conséquences d’une mauvaise qualité des sources de données

Toutes ces erreurs, qu’elles soient ponctuelles ou récurrentes, peuvent avoir des conséquences désastreuses sur vos données et votre activité. Voici quelques-unes des principales répercussions :

Données manquantes ou partielles
- Rapports faussés menant à des décisions erronées.
- Difficulté à avoir une vision fiable et complète des opérations.
Données dupliquées
- Biais dans les analyses (double comptage, inflation des KPIs).
- Sur-allocation de ressources et coûts inutiles.
Données obsolètes
- Utilisation d’informations non à jour, faussant les stratégies.
- Retards dans la détection d’opportunités ou de risques.
Incohérences de formats
- Problèmes d'intégration dans les pipelines.
- Calculs et agrégations erronés dus à des types de données incohérents.
Perte de traçabilité
- Impossibilité de remonter à la source des erreurs.
- Complexité accrue dans la résolution des problèmes.

Ces impacts soulignent l’importance de ne pas sous-estimer la qualité des sources et de mettre en place des mécanismes de contrôle et de correction.

Comment s’en prémunir ? Stratégies et bonnes pratiques

Pour garantir la fiabilité des sources de données, voici quelques bonnes pratiques à adopter :

1. Définir un SLA avec vos fournisseurs de données

Il est crucial de formaliser les attentes vis-à-vis des sources de données en établissant des SLA (Service Level Agreements), qui définissent :

Le format attendu des données.
Le contenu requis.
La fréquence de mise à jour et les délais de disponibilité.

Ces engagements permettent d’établir une base solide pour assurer la qualité des données en entrée.

2. Déclarer ses sources dans dbt

Définir ses sources dans un fichier YAML de dbt est une pratique simple mais essentielle. Cela apporte plusieurs avantages :

Identification rapide des sources utilisées dans les modèles.
Mise en place simplifiée de tests de qualité.
Documentation centralisée et versionnée via Git.
Exécution ciblée des modèles en fonction des sources concernées.

Exemple de déclaration dans dbt :

version: 2

sources:
  - name: google_analytics
    schema: google_analytics_4

    tables:
        - name: audience_page
          columns:
            - name: _fivetran_id
            - name: date
            - name: property
            - name: _fivetran_synced
            - name: page_path
            - name: sessions
            - name: total_users

3. Tester la freshness des sources

Grâce à dbt, il est possible d’automatiser des tests de freshness afin de vérifier que les données sources sont bien actualisées dans les délais attendus.

Exemple de test de freshness dans un fichier YAML :

version: 2

sources:
  - name: google_analytics
    schema: google_analytics_4

    tables:
      - name: audience_page
        columns:
          - name: _fivetran_id
            description: "Unique identifier generated by Fivetran for each record."
          - name: date
            description: "Date of the event or measurement."
          - name: property
            description: "Property or attribute associated with the event."
          - name: _fivetran_synced
            description: "Synchronization date"
          - name: page_path
            description: "Path of the visited page."
          - name: sessions
            description: "Number of recorded sessions."
          - name: total_users
            description: "Total number of unique users."
        loaded_at_field: _fivetran_synced
        freshness:
          warn_after: {count: 6, period: hour}
          error_after: {count: 24, period: hour}

Cela permet d’être alerté si une source devient obsolète.

4. Tester les types de champs et la structure des sources

Des tests automatiques peuvent être mis en place pour valider que la structure des sources correspond toujours aux attentes (types de colonnes, contraintes, etc.).

Exemple de test en utilisant Elementary :

version: 2

sources:
  - name: google_analytics
    schema: google_analytics_4

    tables:
      - name: audience_page
        tests:
          - elementary.schema_changes:
              tags: ["elementary"]
              config:
                severity: warn
        columns:
          - name: _fivetran_id
            description: "Unique identifier generated by Fivetran for each record."
          - name: date
            description: "Date of the event or measurement."
          - name: property
            description: "Property or attribute associated with the event."
          - name: _fivetran_synced
            description: "Synchronization date"
          - name: page_path
            description: "Path of the visited page."
          - name: sessions
            description: "Number of recorded sessions."
          - name: total_users
            description: "Total number of unique users."
        loaded_at_field: _fivetran_synced
        freshness:
          warn_after: {count: 6, period: hour}
          error_after: {count: 24, period: hour}

Ce test permet de tester automatiquement le schema de la source et de déclencher une alerte dès qu'il y a un changement par rapport à l'éxécution précédente du test. Il est également possible de définir les types de chaque colonne et de définir le test elementary.schema_changes_from_baseline (Documentation)

5. Vérifier les règles métier critiques

Enfin, aller au-delà des tests basiques en vérifiant des règles métier spécifiques permet d’assurer la cohérence des données au regard des objectifs business.

Conclusion

Faire confiance aux sources de données sans les contrôler est une erreur courante qui peut avoir de lourdes conséquences. Mettre en place des mécanismes de validation dès l’ingestion et tout au long du pipeline permet de gagner en fiabilité et en réactivité face aux anomalies.

En appliquant ces bonnes pratiques, vous pourrez détecter les problèmes plus rapidement et garantir des données de qualité pour vos analyses et prises de décision.

Pensez à auditer vos sources de données dès aujourd’hui et à mettre en place des tests adaptés à vos besoins !

L’importance de tester ses sources dans un projet dbt

Kévin Bénard