Accueil › Glossaire › ETL

ETL (Extract, Transform, Load)

ETL signifie Extract, Transform, Load : un processus d’intégration de données qui extrait les données depuis des sources diverses, les transforme dans un format structuré exploitable, puis les charge dans un système cible (data warehouse, data lake) pour l’analyse et le reporting.

L’ETL est la méthode historique d’intégration de données, inventée dans les années 1970 avec l’essor des data warehouses. Son principe est simple : nettoyer et structurer les données avant de les stocker. Depuis, l’approche inverse (ELT, qui charge d’abord puis transforme) a largement pris le dessus grâce aux cloud data warehouses. Mais comprendre l’ETL reste essentiel car il définit le vocabulaire et les concepts fondamentaux de tout data pipeline.

Les trois étapes de l’ETL

Extract (Extraction)

L’extraction consiste à récupérer les données brutes depuis les systèmes sources. Ces sources peuvent être des bases de données relationnelles (PostgreSQL, MySQL, Oracle), des bases NoSQL (MongoDB, Cassandra), des APIs (REST, GraphQL), des fichiers plats (CSV, JSON, XML, Parquet), des systèmes SaaS (Salesforce, Stripe, HubSpot, Google Analytics) ou des flux d’événements (Kafka, Kinesis).

L’extraction peut être complète (full extract : toutes les données à chaque exécution) ou incrémentale (seules les données modifiées depuis la dernière extraction). L’extraction incrémentale est préférable pour les volumes importants car elle réduit la charge sur les systèmes sources et le temps de traitement. Elle s’appuie sur des marqueurs de temps (updated_at), des colonnes d’audit ou du CDC (Change Data Capture) qui capture les changements via le journal de transactions de la base source.

Dans un processus ETL classique, les données extraites sont placées dans une zone de staging (un espace temporaire) avant d’être transformées. En ELT moderne, elles sont chargées directement dans le système cible.

Transform (Transformation)

La transformation est l’étape qui donne sa valeur aux données brutes. Elle couvre un spectre large d’opérations :

Nettoyage : suppression des doublons, gestion des valeurs nulles, correction des formats incohérents (dates, devises, unités).

Validation : vérification que les données respectent les règles métier (un âge ne peut pas être négatif, un email doit contenir un @, un montant de transaction doit être positif).

Standardisation : uniformisation des formats (ISO 8601 pour les dates, UTF-8 pour l’encodage, codes ISO pour les pays et devises).

Enrichissement : jointures avec des données de référence, calcul de champs dérivés (âge à partir de la date de naissance, catégorie de client à partir du chiffre d’affaires).

Agrégation : calcul de métriques résumées (chiffre d’affaires mensuel par client, nombre moyen de sessions par utilisateur sur 30 jours).

Filtrage : exclusion des données non pertinentes ou non conformes (données de test, entrées incomplètes, enregistrements hors périmètre).

Dans un ETL classique, ces transformations s’exécutent sur un serveur de traitement dédié (staging server) avant le chargement. En ELT, elles s’exécutent directement dans le data warehouse, en SQL, avec la puissance de calcul du warehouse.

Load (Chargement)

Le chargement dépose les données transformées dans le système cible. Deux modes de chargement existent :

Full load : le contenu entier de la table cible est remplacé à chaque exécution. Simple mais coûteux en temps et en calcul pour les gros volumes.

Incremental load : seules les nouvelles données ou les modifications sont ajoutées/mises à jour dans la table cible. Plus efficace mais plus complexe à implémenter (gestion des upserts, détection des suppressions).

La destination peut être un data warehouse (Snowflake, BigQuery, Redshift, Synapse), un data lake (S3 + Delta Lake, Iceberg), un feature store pour le ML, ou toute autre base de données analytique.

ETL vs ELT : la différence fondamentale

La question ETL vs ELT est l’un des débats les plus importants en data engineering moderne. La réponse courte : ELT est le standard en 2026 pour la majorité des cas d’usage. Mais l’ETL classique conserve des niches légitimes.

Pourquoi l’ELT a gagné

L’essor de l’ELT est directement lié à l’émergence des cloud data warehouses (Snowflake, BigQuery, Redshift) qui offrent une puissance de calcul quasi illimitée et élastique. Quand le warehouse peut transformer des téraoctets en quelques minutes, il n’y a plus de raison de transformer les données sur un serveur séparé avant de les charger.

L’ELT offre trois avantages décisifs :

Les données brutes sont conservées. En ETL, les données originales sont perdues après transformation. En ELT, elles restent dans le warehouse. Si vous avez besoin de créer une nouvelle transformation dans 6 mois, les données sources sont toujours là. Vous n’avez pas besoin de ré-extraire depuis les systèmes sources.

Les transformations sont en SQL. Avec dbt, les analystes et data engineers écrivent des transformations en SQL versionné dans Git, testable et documentable. Pas besoin de maîtriser un outil ETL propriétaire : le SQL est la compétence la plus répandue en data.

La séparation ingestion/transformation. L’ingestion (Fivetran, Airbyte) et la transformation (dbt) deviennent deux responsabilités distinctes avec des outils spécialisés. Chacun fait une chose et la fait bien.

Quand l’ETL classique reste pertinent

L’ETL classique conserve des avantages dans certains scénarios :

Données sensibles (PII/GDPR). Si vous ne devez jamais charger de données personnelles non anonymisées dans votre warehouse, l’ETL permet de les masquer ou supprimer avant le chargement. Avec l’ELT, les données brutes (potentiellement PII) sont chargées dans le warehouse, ce qui nécessite une gouvernance stricte dans le warehouse lui-même.

Systèmes legacy on-premise. Certaines organisations avec des data warehouses on-premise (Oracle, Teradata) n’ont pas la puissance de calcul cloud pour faire des transformations lourdes dans le warehouse. L’ETL sur un serveur dédié reste pertinent dans ce contexte.

Intégration avec des systèmes tiers rigides. Quand le système cible exige un format très spécifique et ne supporte aucune transformation, le ETL qui normalise les données avant chargement est la seule option.

Les outils ETL et ELT en détail

dbt : la transformation en tant que code

dbt (data build tool) est l’outil de transformation le plus influent de la décennie. Plus de 80 000 équipes l’utilisent, dont Siemens, Roche et Condé Nast. En octobre 2025, dbt Labs a signé un accord de fusion avec Fivetran, créant une entité combinée avec ~600M$ de revenu annuel. dbt Core reste open source sous sa licence actuelle.

dbt se concentre uniquement sur le « T » de ELT : il transforme les données déjà chargées dans le warehouse en écrivant des modèles SQL. Chaque modèle est un fichier .sql dans un repo Git, avec des tests automatisés, de la documentation et du lineage.

-- models/staging/stg_orders.sql
-- Nettoyage et standardisation des commandes brutes

WITH source AS (
    SELECT * FROM {{ source('ecommerce', 'raw_orders') }}
),

cleaned AS (
    SELECT
        id AS order_id,
        user_id AS customer_id,
        CAST(created_at AS TIMESTAMP) AS ordered_at,
        CAST(amount AS DECIMAL(10,2)) AS order_amount,
        LOWER(TRIM(status)) AS order_status,
        LOWER(TRIM(payment_method)) AS payment_method
    FROM source
    WHERE id IS NOT NULL
      AND amount > 0
)

SELECT * FROM cleaned

# Exécuter les transformations
dbt run

# Tester la qualité des données
dbt test

# Générer la documentation avec lineage
dbt docs generate
dbt docs serve

Fivetran et Airbyte : l’ingestion automatisée

Fivetran et Airbyte gèrent le « E » et le « L » : l’extraction depuis les sources et le chargement dans le warehouse. Ils automatisent les connecteurs vers des centaines de sources (SaaS, bases de données, APIs, fichiers).

Fivetran est une solution managée, propriétaire, avec 300+ connecteurs certifiés. Le pricing est basé sur le volume de données (Monthly Active Rows). La fiabilité est excellente mais le coût peut escalader rapidement pour les gros volumes. Avec la fusion dbt Labs annoncée fin 2025, Fivetran évolue vers une plateforme « ingestion + transformation » intégrée.

Airbyte est open source (licence ELv2 pour le core) avec 600+ connecteurs (officiels + communautaires). L’architecture est transparente et extensible. Airbyte peut être self-hosted (gratuit hors infrastructure) ou utilisé en version cloud managée. C’est le choix des équipes qui veulent le contrôle total et un coût prévisible.

Outils ETL classiques

Les outils ETL traditionnels restent utilisés dans les grandes entreprises avec des systèmes legacy :

Informatica PowerCenter : le leader historique de l’ETL entreprise. Interface graphique, transformations complexes, intégration avec SAP, Oracle, Teradata. Coûteux mais exhaustif.

Talend : plateforme d’intégration de données open source (Community Edition) et commerciale. Interface drag-and-drop pour construire des jobs ETL. Racheté par Qlik en 2023.

Apache Spark : moteur de traitement distribué pour les transformations à grande échelle. Pas un outil ETL au sens strict, mais largement utilisé pour les transformations batch et streaming dans les pipelines de données et de ML.

Apache NiFi : plateforme open source de data flow pour l’automatisation des flux de données entre systèmes. Interface web visuelle, traçabilité native des données.

ETL et machine learning

Les pipelines ETL/ELT jouent un rôle critique dans l’infrastructure ML. Ils alimentent les feature stores en features calculées, préparent les datasets d’entraînement et maintiennent les données de référence pour l’inférence.

La particularité des pipelines ML est l’exigence de reproductibilité : chaque dataset d’entraînement doit être traçable, versionné et reconstituable. DVC ou lakeFS s’intègrent aux pipelines ELT pour fournir le versionnage des données, tandis que l’experiment tracking (MLflow, W&B) enregistre quelle version du dataset a produit quel modèle.

Le point-in-time correctness est un autre enjeu spécifique au ML : les features d’entraînement doivent être calculées avec les données disponibles au moment de chaque observation, pas les données actuelles. Un pipeline ELT qui recalcule les features avec les dernières données introduit du feature leakage, un problème que les feature stores résolvent avec des jointures temporelles correctes.

Bonnes pratiques ETL/ELT

Idempotence

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é. Utilisez MERGE (upsert) ou INSERT OVERWRITE plutôt que INSERT INTO pour éviter les doublons en cas de ré-exécution.

Traitement incrémental

Ne retraitez pas l’intégralité des données à chaque exécution. Les modèles dbt incremental ne traitent que les nouvelles données. Le CDC (Change Data Capture) ne capture que les modifications. Cela réduit le temps d’exécution et les coûts de compute de 90%+ pour les gros volumes.

Lineage et documentation

Chaque transformation doit être traçable : d’où viennent les données, quelles transformations ont été appliquées, qui consomme le résultat. dbt génère automatiquement un graphe de lineage depuis les sources jusqu’aux marts. Dagster étend ce lineage à l’ensemble du pipeline (ingestion + transformation + serving).

Tests de qualité

Testez les données produites, pas seulement le code qui les produit. Des tests dbt sur chaque modèle (unicité, non-nullité, ranges, intégrité référentielle) garantissent que le pipeline ne livre pas de données corrompues. Exécutez dbt test après chaque dbt run et bloquez la livraison si les tests échouent.

Séparation des responsabilités

Séparez l’ingestion (Fivetran/Airbyte), la transformation (dbt) et l’orchestration (Dagster/Airflow). Chaque composant a un rôle unique et peut être remplacé indépendamment. Un pipeline monolithique qui fait tout est difficile à maintenir et à debugger.

Monitoring et alertes

Définissez des SLO pour vos pipelines : « les données de vente sont disponibles dans le warehouse avant 8h avec une fraîcheur < 2h ». Alertez sur les violations de SLO, pas sur chaque erreur transitoire. Un pipeline qui retry et réussit ne nécessite pas d'intervention.

Tendances ETL/ELT en 2026

Consolidation du marché

La fusion Fivetran + dbt Labs (annoncée en octobre 2025) est le signal le plus fort de la consolidation du modern data stack. L’entité combinée (~600M$ ARR, 10 000+ clients) crée une plateforme « ingestion + transformation » intégrée. La priorité annoncée est le support des formats de tables ouvertes (Apache Iceberg), ce qui pourrait réduire la dépendance aux warehouses propriétaires comme Snowflake pour le stockage.

Formats de tables ouvertes

Apache Iceberg s’impose comme le standard de facto pour les data lakes de nouvelle génération. Les pipelines ELT évoluent pour charger directement dans des tables Iceberg (au lieu de tables propriétaires Snowflake ou BigQuery), offrant la portabilité entre moteurs de requête (Spark, Trino, DuckDB, Snowflake).

Pipelines pilotés par l’IA

Les outils d’ingestion et de transformation intègrent de plus en plus l’IA pour automatiser la création de connecteurs, la détection d’anomalies dans les pipelines et la génération de transformations SQL. Dagster a lancé des cours sur la construction de pipelines ELT assistés par des agents de code IA. C’est encore émergent, mais la direction est claire.

Verdict

L’ETL en tant que concept (extraire, transformer, charger) est le fondement de toute infrastructure de données. Mais en pratique, l’approche ELT (charger d’abord, transformer ensuite dans le warehouse) est le standard en 2026 pour la grande majorité des cas d’usage. La stack recommandée : Airbyte ou Fivetran pour l’ingestion, dbt pour les transformations SQL versionnées, et un orchestrateur (Dagster pour les nouveaux projets, Airflow pour l’existant).

L’ETL classique (transformation avant chargement) reste pertinent pour les systèmes legacy on-premise, les environnements avec des contraintes GDPR strictes où les données PII ne doivent jamais toucher le warehouse, et les intégrations avec des systèmes tiers qui exigent des formats très spécifiques.

Quel que soit l’approche, les principes restent les mêmes : idempotence, traitement incrémental, tests de qualité, lineage, et monitoring avec des SLO clairs. Un pipeline qui fonctionne mais n’est ni testé ni monitoré est une bombe à retardement.