Accueil › Glossaire › Data Pipeline

Data Pipeline

Un data pipeline est une séquence automatisée d’étapes qui extraient des données depuis une ou plusieurs sources, les transforment, les valident et les chargent vers une ou plusieurs destinations (data warehouse, data lake, plateforme ML, dashboard) pour les rendre exploitables.

Les data pipelines sont le système circulatoire de toute organisation data-driven. Derrière chaque rapport, chaque dashboard, chaque modèle ML en production, il y a un pipeline qui déplace et transforme les données depuis leur point d’origine jusqu’au point où elles créent de la valeur. Quand les pipelines fonctionnent, personne ne les remarque. Quand ils cassent, tout s’arrête.

Anatomie d’un data pipeline

Un data pipeline, aussi simple soit-il, se décompose en quatre étapes fondamentales. La complexité vient de la gestion des erreurs, des garanties de livraison, de l’ordonnancement et de l’observabilité.

1. Ingestion (extraction)

L’ingestion capture les données depuis les sources : bases de données (PostgreSQL, MySQL, MongoDB), APIs (REST, GraphQL), flux d’événements (Kafka, Kinesis), fichiers (CSV, JSON, Parquet), systèmes SaaS (Salesforce, Stripe, HubSpot). Les outils d’ingestion managés comme Fivetran, Airbyte ou Stitch automatisent cette étape pour les sources courantes. Pour les sources custom, vous écrivez vos propres connecteurs.

Deux modes d’ingestion coexistent : le batch (extraction périodique de blocs de données) et le streaming (capture continue des événements en temps réel). Le CDC (Change Data Capture) est un hybride qui capture les changements dans une base de données source en temps réel via son journal de transactions (WAL pour PostgreSQL, binlog pour MySQL).

2. Transformation

La transformation convertit les données brutes en données exploitables : nettoyage (suppression des doublons, gestion des nulls), normalisation, agrégation, jointures entre sources, calcul de métriques dérivées. Deux approches dominent :

ETL (Extract, Transform, Load) : les données sont transformées avant d’être chargées dans la destination. Approche traditionnelle, utile quand la transformation est lourde ou quand le stockage de destination est coûteux.

ELT (Extract, Load, Transform) : les données sont chargées brutes dans la destination (data warehouse ou data lake), puis transformées sur place avec la puissance de calcul du warehouse. C’est l’approche dominante en 2026, portée par des outils comme dbt qui permettent de définir les transformations en SQL versionné.

3. Validation

La validation vérifie que les données transformées respectent les attentes : types corrects, valeurs dans les ranges attendus, unicité des clés, cohérence référentielle, pas de dégradation statistique. Sans validation, un pipeline peut silencieusement produire des données corrompues qui contaminent les rapports et les modèles ML en aval. Des outils comme Great Expectations, dbt tests ou Soda permettent de définir des « data contracts » automatisés.

4. Chargement et serving

Le chargement livre les données transformées et validées à leurs destinations : data warehouse (Snowflake, BigQuery, Redshift) pour l’analytique, data lake (S3, GCS, Delta Lake) pour le stockage brut à grande échelle, feature store pour le ML, index de recherche (Elasticsearch, Algolia), ou directement des APIs consommées par des applications.

Types de data pipelines

Patterns d’architecture

Le stack ELT moderne

C’est l’architecture dominante en 2026 pour l’analytique. Le flux est simple : un outil d’ingestion (Fivetran, Airbyte) extrait les données des sources et les charge brutes dans un cloud data warehouse. Ensuite, dbt transforme ces données en modèles SQL versionnés, testés et documentés. Un orchestrateur (Airflow, Dagster, Prefect) coordonne le tout.

-- Exemple de modèle dbt : calcul du revenu par client
-- models/marts/customers/customer_revenue.sql

WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}
),

payments AS (
    SELECT * FROM {{ ref('stg_payments') }}
    WHERE status = 'completed'
),

customer_revenue AS (
    SELECT
        orders.customer_id,
        COUNT(DISTINCT orders.order_id) AS total_orders,
        SUM(payments.amount) AS lifetime_revenue,
        MIN(orders.ordered_at) AS first_order_date,
        MAX(orders.ordered_at) AS last_order_date
    FROM orders
    INNER JOIN payments ON orders.order_id = payments.order_id
    GROUP BY orders.customer_id
)

SELECT * FROM customer_revenue

Ce modèle dbt est versionné dans Git, testé automatiquement (unicité de customer_id, non-nullité de lifetime_revenue), et documenté. C’est la transformation en tant que code.

Lambda Architecture

La Lambda architecture combine un batch layer (traitement historique complet, haute précision) avec un speed layer (traitement streaming, faible latence, approximatif). Les résultats des deux layers sont fusionnés dans un serving layer. C’est une architecture puissante mais complexe à maintenir car vous maintenez deux pipelines parallèles pour la même logique.

Kappa Architecture

La Kappa architecture simplifie Lambda en utilisant un seul chemin streaming pour tout : les données passent par un log distribué (Kafka) et sont traitées par un moteur de streaming (Flink). Le retraitement se fait en rejouant le log depuis le début. Plus simple à maintenir que Lambda, mais exige un système de messaging robuste et scalable.

Data Mesh

Le Data Mesh est une approche organisationnelle où chaque domaine métier (marketing, produit, finance) possède et opère ses propres pipelines de données. Les domaines publient des « data products » qui respectent des standards partagés (schémas, qualité, SLA). Un plan de contrôle central assure la découverte et la gouvernance. C’est l’architecture pour les grandes organisations où un pipeline centralisé unique ne peut pas scaler avec la complexité métier.

Les orchestrateurs de pipelines

Un orchestrateur coordonne l’exécution des étapes d’un pipeline : ordonnancement, gestion des dépendances, retries, monitoring et alertes. C’est le chef d’orchestre qui s’assure que chaque étape s’exécute dans le bon ordre, au bon moment, et que les erreurs sont gérées correctement.

Apache Airflow : le standard éprouvé

Airflow est l’orchestrateur le plus adopté, développé initialement par Airbnb. Il définit les pipelines comme des DAGs (Directed Acyclic Graphs) en Python. Airflow 3, sorti en avril 2025, a apporté une UI modernisée, l’isolation des tâches et les workflows event-driven.

Airflow excelle pour les pipelines batch/ETL planifiés avec un écosystème de « providers » massif (centaines de connecteurs). Ses limites : le développement local est lourd (dépendances complexes), les tests unitaires sont difficiles, et l’architecture n’a pas été conçue pour la conteneurisation native. Airflow convient aux organisations avec un historique de DAGs existants et des workflows principalement schedule-based.

# Exemple de DAG Airflow
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.providers.snowflake.operators.snowflake import SnowflakeOperator
from datetime import datetime, timedelta

default_args = {
    "retries": 3,
    "retry_delay": timedelta(minutes=5),
}

with DAG(
    dag_id="daily_revenue_pipeline",
    schedule_interval="@daily",
    start_date=datetime(2026, 1, 1),
    default_args=default_args,
    catchup=False,
) as dag:

    extract = PythonOperator(
        task_id="extract_from_api",
        python_callable=extract_sales_data,
    )

    transform = SnowflakeOperator(
        task_id="transform_in_warehouse",
        sql="CALL analytics.daily_revenue_refresh();",
        snowflake_conn_id="snowflake_prod",
    )

    validate = PythonOperator(
        task_id="validate_data_quality",
        python_callable=run_great_expectations_suite,
    )

    extract >> transform >> validate

Dagster : l’approche asset-centric

Dagster représente un changement de paradigme : au lieu de modéliser des tâches (ce que vous faites), vous modélisez des assets (ce que vous produisez). Chaque table, fichier ou feature est un « software-defined asset » avec son lineage, son statut de fraîcheur et ses contrôles de qualité.

Cette approche offre une observabilité supérieure : vous pouvez voir quels assets sont à jour, lesquels doivent être rafraîchis, et quel code les a produits. L’intégration avec dbt est la meilleure du marché : chaque modèle dbt devient un asset Dagster avec lineage natif. Le développement local est excellent (pas besoin de Docker pour tester), et les tests unitaires sont simples à écrire.

Dagster est le choix recommandé pour les équipes qui démarrent un nouveau projet et qui valorisent le lineage des données, la qualité des données intégrée, et une expérience développeur moderne.

Prefect : flexibilité Python-first

Prefect est l’orchestrateur avec la plus faible friction de démarrage. Vous décorez vos fonctions Python avec @flow et @task, et vous obtenez scheduling, retries et UI sans la complexité d’Airflow ou Dagster.

Prefect excelle pour les workflows dynamiques et event-driven, où la structure du pipeline change à l’exécution. Son modèle est centré sur les tâches (pas les assets), ce qui le rend plus flexible mais moins structuré que Dagster pour les plateformes data complexes. Prefect est le meilleur choix pour les petites équipes qui ont besoin d’un orchestrateur fonctionnel rapidement, sans investir dans une infrastructure lourde.

Comparatif des orchestrateurs

Bonnes pratiques de data pipelines

Rendez vos pipelines idempotents

Un pipeline idempotent produit le même résultat, qu’il soit exécuté une fois ou dix fois. C’est la propriété la plus importante pour la fiabilité. Concrètement : utilisez INSERT OVERWRITE plutôt que INSERT INTO, partitionnez par date et réécrivez la partition entière plutôt que d’ajouter des données. Si un pipeline échoue et doit être relancé, l’idempotence garantit qu’il ne duplique pas les données.

Testez les données, pas seulement le code

Les tests unitaires vérifient que votre code fonctionne. Les data tests vérifient que les données produites sont correctes. Avec dbt, définissez des tests sur chaque modèle : unicité des clés primaires, non-nullité des colonnes critiques, intégrité référentielle, plages de valeurs acceptables. Un pipeline qui passe les tests de code mais produit des données corrompues est plus dangereux qu’un pipeline qui échoue visiblement.

Investissez dans l’observabilité

Vous ne pouvez pas corriger ce que vous ne voyez pas. Instrumentez vos pipelines comme vous instrumentez vos services : métriques (volume de données traitées, latence, taux d’erreur), logs structurés, traces end-to-end. Définissez des SLI/SLO pour vos pipelines (« les données marketing sont disponibles avant 8h avec une fraîcheur < 4h ») et alertez quand les SLO sont violés.

Gérez l’évolution des schémas

Les schémas des sources changent sans prévenir : une colonne ajoutée, un type modifié, un champ renommé. Un bon pipeline gère ces évolutions gracieusement plutôt que de casser silencieusement. Utilisez un schema registry pour les flux streaming (Confluent Schema Registry) et des data contracts pour les pipelines batch (dbt contracts, Great Expectations).

Privilégiez le traitement incrémental

Retraiter l’intégralité des données à chaque exécution est coûteux et lent. Les modèles dbt incremental ne traitent que les nouvelles données depuis la dernière exécution, avec un fallback en full refresh si nécessaire. Cela réduit drastiquement les coûts de compute et le temps d’exécution.

Configurez des retries intelligents

Les échecs transitoires (timeout réseau, indisponibilité temporaire d’une API, lock sur une table) sont normaux. Configurez des retries avec backoff exponentiel : 1 minute, 5 minutes, 15 minutes. Mais limitez le nombre de retries (3-5 max) et alertez si le pipeline échoue après les retries. Un pipeline qui retry indéfiniment masque un problème structurel.

Outils de transformation : dbt en détail

dbt (data build tool) a transformé la façon dont les équipes data construisent leurs pipelines de transformation. Au lieu de scripts Python ou de procédures stockées, dbt permet de définir les transformations en SQL pur, versionné dans Git, avec des tests automatisés et une documentation générée.

dbt Core vs dbt Cloud

dbt Core est le moteur open source (gratuit) qui compile et exécute les modèles SQL. dbt Cloud est la version managée qui ajoute un IDE web, le scheduling intégré, le CI/CD natif, et la gestion des environnements. Pour les équipes qui ont déjà un orchestrateur (Dagster, Airflow), dbt Core suffit. dbt Cloud convient aux équipes analytiques qui veulent un environnement tout-en-un sans gérer l’infrastructure.

Modèles et couches de transformation

dbt organise les transformations en couches, suivant le pattern Medallion (Bronze/Silver/Gold) ou le pattern staging/intermediate/marts :

Staging (stg_) : nettoyage minimal des données brutes. Renommage des colonnes, casting des types, filtrage des doublons évidents. Un modèle staging par source.

Intermediate (int_) : transformations intermédiaires complexes. Jointures entre sources, agrégations préliminaires, logique métier réutilisable.

Marts : les tables finales optimisées pour la consommation. Un mart par domaine métier (marketing, finance, produit). C’est ce que les analystes et les modèles ML consomment directement.

Tests et data contracts

# tests/schema.yml : définition des tests dbt
version: 2

models:
  - name: customer_revenue
    description: "Revenu lifetime par client"
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: lifetime_revenue
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0
              inclusive: true
      - name: total_orders
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 1

Ces tests s’exécutent après chaque dbt run via dbt test. Si un test échoue, l’orchestrateur bloque la suite du pipeline et alerte l’équipe. C’est le principe du « fail fast » : mieux vaut un pipeline qui s’arrête proprement qu’un pipeline qui livre des données corrompues silencieusement.

Observabilité et monitoring des pipelines

L’observabilité d’un data pipeline repose sur trois piliers, identiques à ceux de l’observabilité des services logiciels :

Métriques

Les métriques quantifient la santé du pipeline : volume de données traitées (lignes insérées, octets transférés), latence end-to-end (temps entre la production de la donnée source et sa disponibilité dans la destination), taux d’erreur (pourcentage de runs échoués), et fraîcheur (âge de la donnée la plus récente dans la destination). Définissez des SLI (Service Level Indicators) et des SLO (Service Level Objectives) pour chaque métrique. Par exemple : « le rapport marketing doit contenir des données de moins de 4 heures de retard, 99.5 % du temps ».

Logs structurés

Chaque étape du pipeline doit produire des logs structurés (JSON) avec un identifiant de run, le timestamp, le nombre de lignes traitées, les erreurs rencontrées et le temps d’exécution. Ces logs permettent de diagnostiquer les problèmes en quelques minutes plutôt qu’en quelques heures. Dagster et Airflow fournissent des interfaces de logs par tâche dans leur UI.

Alertes

Configurez des alertes sur les violations de SLO, pas sur chaque erreur individuelle. Un pipeline qui échoue puis réussit au retry ne nécessite pas d’intervention humaine. Un pipeline qui n’a pas livré de données depuis 6 heures en nécessite une. Les alertes pertinentes via Slack, PagerDuty ou email sont essentielles. Trop d’alertes (alert fatigue) est aussi dangereux que pas assez.

Des outils spécialisés comme Monte Carlo (data observability), Soda et Elementary (dbt-native) automatisent la détection d’anomalies dans les données : distribution inhabituelle, volume anormalement bas, schéma modifié, fraîcheur dégradée.

Data pipelines pour le machine learning

Les data pipelines ML ont des exigences supplémentaires par rapport aux pipelines analytiques classiques :

Versionnage des données : chaque run d’entraînement doit être lié à une version exacte du dataset. DVC ou lakeFS fournissent le versionnage Git-like pour les données volumineuses.

Feature engineering : les pipelines ML produisent des features qui alimentent le feature store. La logique de feature engineering doit être identique entre l’entraînement (offline) et l’inférence (online) pour éviter le training-serving skew.

Point-in-time correctness : les jointures dans un pipeline ML doivent respecter la temporalité pour éviter le feature leakage. Chaque observation ne peut utiliser que les données disponibles au moment de cette observation.

Reproductibilité : combiné avec l’experiment tracking et le model versioning, le pipeline ML doit garantir que chaque modèle en production peut être reconstruit exactement.

Les orchestrateurs ML spécialisés (Kubeflow Pipelines, Vertex AI Pipelines, SageMaker Pipelines) ajoutent des abstractions pour l’entraînement distribué, le tuning d’hyperparamètres et le déploiement de modèles. Mais pour les pipelines de données qui alimentent le ML, Dagster ou Airflow restent les choix les plus courants.

Verdict

Un data pipeline bien conçu est la fondation invisible sur laquelle repose toute stratégie data et IA. La tendance de fond en 2026 est claire : ELT plutôt qu’ETL, dbt pour les transformations SQL versionnées, et un orchestrateur moderne (Dagster pour les nouveaux projets, Airflow pour les environnements existants). L’observabilité et les data contracts ne sont plus optionnels : les pipelines qui servent des modèles ML ou des décisions métier critiques doivent être monitorés et testés avec la même rigueur que des services de production.

Commencez simple : un outil d’ingestion (Airbyte ou Fivetran), dbt pour les transformations, et un orchestrateur. Ajoutez le streaming, le CDC et les architectures event-driven quand vos cas d’usage l’exigent, pas avant. La sur-ingénierie d’un pipeline est aussi dangereuse que la sous-ingénierie.