ETL — Extract, Transform, Load

Définition complète

L'ETL — Extract, Transform, Load — est le pattern d'ingestion de données analytiques dans lequel trois étapes se déroulent dans un ordre séquentiel précis. L'extraction (E) consiste à lire les données depuis les systèmes sources : bases de données relationnelles (PostgreSQL, MySQL, Oracle), APIs SaaS (Salesforce, HubSpot, Stripe), fichiers plats (CSV, JSON, XML), flux événementiels. La transformation (T) se produit dans un moteur de staging externe à l'entrepôt cible — les données sont nettoyées, jointes, agrégées, dédupliquées et converties dans le schéma cible. Le chargement (L) consiste enfin à écrire les données transformées dans l'entrepôt analytique de destination.

Ce qui distingue fondamentalement l'ETL de son successeur l'ELT — Extract, Load, Transform — est l'emplacement de la transformation. Dans l'ETL, la transformation se produit avant l'entrepôt ; dans l'ELT, les données brutes arrivent d'abord dans l'entrepôt, et la transformation s'effectue ensuite directement dans celui-ci via SQL. Ce déplacement de la logique de transformation a des implications profondes en termes de performance, de coût, de gouvernance des données brutes et de flexibilité de retraitement.

L'ETL est né dans les années 1990 dans un contexte où le stockage en entrepôt (data warehouse) était coûteux — chaque gigaoctet stocké avait un coût significatif — et où la puissance de calcul dans l'entrepôt était limitée. Il était donc logique de ne charger dans l'entrepôt que des données déjà transformées et structurées, en minimisant le volume et la complexité des opérations à effectuer une fois dans l'entrepôt. Avec l'avènement du cloud, cette contrainte économique a largement disparu, ce qui explique l'ascension de l'ELT.

Comment implémenter un pipeline ETL

Un pipeline ETL bien conçu suit une architecture en couches logiques. La couche d'extraction gère la connexion aux sources, la gestion des authentifications et des quotas d'API, la détection des modifications (incrémental vs. full-load), et la gestion des erreurs de connectivité. La couche de transformation applique les règles métier : nettoyage des données manquantes ou incohérentes, jointures entre sources, calculs d'agrégats, déduplication, et normalisation des formats. La couche de chargement gère l'écriture vers l'entrepôt cible — avec gestion des upserts (mise à jour si existe, insertion si nouveau) et validation post-chargement.

Le choix de l'orchestrateur est structurant pour un pipeline ETL. Apache Airflow reste le standard open-source pour l'orchestration de DAGs (Directed Acyclic Graphs) de pipelines batch ; Dagster et Prefect offrent des alternatives plus modernes avec meilleure observabilité. Pour les transformations volumineuses, Apache Spark est le moteur de référence. Pour les pipelines plus simples, un script Python bien structuré avec orchestration Airflow peut suffire et est plus facile à maintenir qu'une architecture Spark.

Exemple concret

Prenons une entreprise de retail en ligne française avec 85 000 commandes par mois, réparties sur trois canaux : site web propre, marketplace Amazon, et réseau de distribution B2B. Le DSI doit construire un pipeline analytique qui consolide ces trois sources dans un entrepôt pour le reporting financier mensuel et le pilotage opérationnel hebdomadaire.

Dans une architecture ETL : l'extraction lit chaque nuit les nouvelles commandes depuis les trois sources (API WooCommerce, export Amazon Seller Central, base PostgreSQL B2B). Le moteur de staging en Python/Pandas applique les transformations : normalisation des devises (commandes Amazon en USD converties en EUR au taux du jour), alignement des statuts de commande (chaque source a ses propres libellés), déduplication des commandes multi-canaux pour les clients qui commandent sur plusieurs canaux, calcul des marges unitaires en joignant les données de coût depuis l'ERP SAP. Les données transformées — environ 2,8 Go par mois — sont ensuite chargées dans BigQuery où les équipes accèdent aux rapports. Coût de calcul du staging : environ 180 € par mois pour l'infrastructure Spark sur GCP.

Un architecte data senior évaluerait ici si la transformation dans BigQuery directement (approche ELT) serait préférable. La réponse dépend d'un facteur critique : les données de coût proviennent de SAP, un système on-premise hébergé en France. La contrainte RGPD de l'entreprise interdit d'envoyer ces données de coût vers BigQuery (hébergé aux États-Unis) sans traitement préalable. Dans ce cas précis, l'ETL avec transformation on-premise est le bon choix — pas par réflexe, mais pour une raison de gouvernance des données justifiée.

Analyse approfondie

La transition de l'ETL vers l'ELT comme pattern dominant n'est pas une mode mais une conséquence directe de l'économie du cloud. Dans les architectures on-premise des années 1990–2010, le stockage dans l'entrepôt (Oracle, Teradata) coûtait plusieurs dizaines d'euros par gigaoctet. Il était donc rationnel de ne charger dans l'entrepôt que des données déjà réduites et transformées. Avec Snowflake, BigQuery et Redshift, le coût de stockage est tombé à quelques centimes par gigaoctet, et la puissance de calcul SQL est devenue suffisamment puissante et bon marché pour exécuter des transformations complexes directement dans l'entrepôt. L'ETL a perdu son avantage économique fondamental.

L'un des principaux avantages pratiques de l'ELT sur l'ETL est la préservation des données brutes. Dans un pipeline ETL classique, les données sources sont transformées avant d'entrer dans l'entrepôt — les données brutes ne sont pas stockées. Si la logique de transformation était incorrecte, ou si les besoins analytiques évoluent, il faut re-extraire depuis les sources. Dans un pipeline ELT, les données brutes sont toujours disponibles dans l'entrepôt — une modification de la logique de transformation (un modèle dbt) se répercute immédiatement sans ré-extraction. Cette flexibilité de retraitement est particulièrement précieuse dans les premières phases d'un projet analytique où les définitions métier évoluent.

L'ETL reste cependant indispensable dans des cas d'usage précis. Le premier est la résidence stricte des données — une entreprise soumise au RGPD qui ne peut pas envoyer certaines catégories de données personnelles vers un entrepôt cloud hors UE doit les transformer localement avant envoi, ou les anonymiser dans le pipeline avant qu'elles atteignent le cloud. Le deuxième est le traitement de flux temps réel : les architectures Kafka Streams ou Apache Flink effectuent des transformations en vol sur des flux d'événements en millisecondes — c'est de l'ETL temps réel, par opposition à l'ETL batch. Le troisième est les environnements on-premise hérités où le calcul dans l'entrepôt est encore coûteux ou techniquement limité.

L'évolution de l'outillage a brouillé la frontière entre ETL et ELT. Des outils comme Fivetran ou Airbyte sont souvent décrits comme des outils "EL" (Extract + Load) — ils extraient et chargent les données brutes, laissant la transformation à dbt dans l'entrepôt. Mais Fivetran applique des transformations légères (normalisation de types, gestion des doublons) dans le pipeline lui-même, ce qui est techniquement de l'ETL. La réalité est que la plupart des architectures modernes sont hybrides : un EL classique pour l'inbound depuis les SaaS, suivi de transformations SQL dans l'entrepôt pour la modélisation analytique, avec des pipelines ETL dédiés pour les sources sensibles ou les flux temps réel.

Du point de vue de la gouvernance des données, l'ETL offre un avantage souvent sous-estimé : la maîtrise de ce qui entre dans l'entrepôt. En filtrant et transformant les données avant leur entrée dans l'entrepôt, l'ETL agit comme une barrière de qualité — seules les données valides et conformes au schéma cible sont chargées. Dans un pipeline ELT, les données brutes — potentiellement mal formées, incomplètes ou non conformes — arrivent dans l'entrepôt et doivent être gérées par les modèles de transformation. Cela peut conduire à une prolifération de tables de staging brutes difficiles à gouverner si l'organisation n'est pas disciplinée.

Erreurs fréquentes dans les pipelines ETL

• ✗

  Choisir l'ETL par réflexe sans évaluer l'ELT : en 2026, la majorité des nouveaux pipelines analytiques sur infrastructure cloud devraient démarrer avec un pattern ELT. Construire un pipeline ETL complexe avec moteur de staging Spark pour des données qui pourraient être transformées directement dans Snowflake ou BigQuery ajoute une couche de complexité opérationnelle, de coûts d'infrastructure et de points de défaillance sans bénéfice correspondant. Posez la question avant tout projet : "Pourquoi avons-nous besoin de transformer avant de charger ?"

• ✗

  Ne pas stocker les données brutes en zone d'atterrissage : dans un pipeline ETL classique, les données brutes sont transformées et les originaux ne sont pas conservés. Si la logique de transformation contient une erreur — une jointure incorrecte, une règle de nettoyage trop agressive — il faut re-extraire depuis les sources. La pratique recommandée est de toujours stocker les données brutes dans une zone d'atterrissage (landing zone, raw bucket) avant transformation, même dans un pipeline ETL. Ce surcoût de stockage est négligeable comparé au risque de re-extraction.

• ✗

  Confondre ETL batch et ETL temps réel dans la même architecture : les pipelines ETL batch (exécution nocturne, latence en heures) et les pipelines ETL temps réel (Kafka Streams, Flink, latence en secondes) ont des architectures, des outils et des contraintes opérationnelles radicalement différents. Tenter de faire du temps réel avec des outils conçus pour le batch conduit à des architectures fragiles et coûteuses. Identifiez en amont la latence requise par chaque flux de données et choisissez l'outillage correspondant.

Comment Fairview gère l'ingestion de données

Fairview gère l'intégralité du pipeline d'ingestion pour vous — qu'il s'agisse de sources de facturation (Stripe, Chargebee, Paddle), de CRM (HubSpot, Salesforce), ou d'outils analytiques. L'architecture d'ingestion de Fairview applique des transformations légères au niveau du pipeline (normalisation des devises, résolution des identifiants clients, déduplication des événements) avant de charger les données dans la couche analytique — un pattern hybride ETL/ELT adapté à chaque source.

Pour les opérateurs, cela signifie que vous n'avez pas à construire ni à maintenir de pipeline ETL : Fairview le fait pour vous et expose directement les métriques opérationnelles calculées — MRR, marge de contribution, churn — avec des définitions centralisées et une fraîcheur garantie. La complexité de l'ingestion est absorbée par la plateforme ; vous accédez directement à des données fiables pour prendre vos décisions. Si vous avez des sources de données spécifiques à intégrer, l'équipe Fairview évalue le pattern d'ingestion le plus adapté selon vos contraintes de gouvernance.

Questions fréquentes