Aller au contenu

ETL vs ELT : schémas de pipelines, compromis et quand choisir l'un ou l'autre

L'ETL transforme les données avant l'entrepôt ; l'ELT les charge brutes et les transforme sur place. Fonctionnement des deux pipelines, coûts et critères de choix.

· Fondateur et développeur

Publié le

Deux couloirs superposés. ETL : Postgres des commandes, moteur de transformation, entrepôt avec fct_orders, tableaux de bord BI. ELT : Postgres, loader qui hache les PII, entrepôt avec raw.orders, modèles dbt et marts.fct_orders, puis BI. Une note d'ordre d'exécution est en dessous.

Le service financier demande le chiffre d'affaires par code de réduction sur les deux dernières années. Dans une entreprise, c'est une petite modification SQL suivie d'une reconstruction, car chaque ligne de commande jamais chargée reste dans une table brute. Dans une autre, le job nocturne n'a jamais conservé la colonne de réduction : quelqu'un modifie le job et ré-extrait deux ans d'historique depuis la production.

La différence tient à l'endroit où tourne la transformation. L'ETL (extract, transform, load) met les données en forme sur un moteur distinct avant qu'elles n'atteignent l'entrepôt. L'ELT (extract, load, transform) copie les données brutes dans l'entrepôt et les met en forme sur place avec du SQL. Ce choix détermine votre facture de calcul, la fraîcheur des données, la facilité à modifier la logique et l'endroit où finissent les données personnelles.

Cet article détaille les deux pipelines, les compare, montre où l'ETL gagne encore et l'hybride courant, et se termine par un schéma côte à côte.

Comment fonctionne un pipeline ETL

En ETL, un moteur de transformation se place entre les sources et l'entrepôt. Une exécution nocturne :

  1. Extrait les lignes nouvelles et modifiées, avec une requête sur une colonne updated_at ou depuis un flux de change data capture.
  2. Transforme ces lignes sur le moteur : nettoyer les valeurs, supprimer les doublons, joindre les données de référence, masquer les données personnelles et remodeler le résultat en tables de faits et de dimensions.
  3. Charge le résultat dans l'entrepôt avec des insertions ou des merges.

Le moteur peut être Informatica, SQL Server Integration Services (SSIS), un job Spark ou un script Python. Les extractions brutes restent souvent dans une zone de staging que le job vide après une exécution réussie : l'entrepôt ne peut donc pas répondre à une question que le job n'avait pas anticipée.

Comment fonctionne un pipeline ELT

En ELT, c'est l'entrepôt qui fait le travail de transformation :

  1. Extraction et chargement. Un loader tel que Fivetran ou Airbyte copie les tables sources dans un schéma raw presque sans modification, en ajoutant des colonnes de métadonnées comme _fivetran_synced ou _airbyte_extracted_at qui enregistrent la date de synchronisation de chaque ligne.
  2. Transformation. Des modèles SQL, généralement gérés avec dbt, lisent les tables brutes et construisent des tables nettoyées et jointes dans d'autres schémas.
  3. Service. Les outils de BI interrogent les tables finales, généralement appelées marts.

L'ELT s'est répandu avec les entrepôts cloud qui séparent le stockage du calcul, comme BigQuery et Snowflake : les copies brutes coûtent peu à conserver et la capacité de transformation évolue avec l'entrepôt. Comme chaque ligne chargée reste disponible, vous pouvez corriger un modèle, ajouter une colonne ou définir une nouvelle métrique et reconstruire à partir de l'historique sans toucher à la source.

ETL vs ELT : comparaison

ETL ELT
Où tourne la transformation Un moteur distinct, avant l'entrepôt Dans l'entrepôt, en SQL
Ce qui arrive dans l'entrepôt Uniquement des tables modélisées Des tables brutes, puis des tables modélisées
Données brutes conservées Rarement ; les extractions sont vidées Oui, dans un schéma raw
Nouvelles colonnes source Ignorées tant que personne ne les mappe Le loader peut les ajouter aux tables brutes ; les modèles les utilisent une fois le SQL modifié
Modification de la logique métier Modifier le job, ré-extraire l'historique Modifier le SQL, reconstruire depuis le brut
Coût de calcul Serveurs ou clusters du moteur, plus l'entrepôt Calcul de l'entrepôt à chaque exécution de modèle, plus le stockage brut
Données personnelles Masquées avant d'arriver Arrivent telles quelles, sauf si le loader les masque
Fraîcheur Mise à jour à la fin de tout le job Données brutes selon le planning du loader ; marts à l'exécution des modèles
Outils typiques Informatica, SSIS, AWS Glue, Spark Fivetran ou Airbyte, dbt, et BigQuery, Snowflake, Redshift ou Databricks

Les plannings comptent plus que l'acronyme : la synchronisation par défaut de Fivetran s'exécute toutes les six heures, ce qui est moins frais qu'un job ETL horaire.

Quand l'ETL gagne encore

  • Les données personnelles ne doivent pas arriver brutes. Si des adresses e-mail ou des numéros de carte en clair ne doivent jamais atteindre l'entrepôt, masquez-les avant le chargement. Les politiques de masquage de l'entrepôt ne changent pas ce qui est stocké : le Dynamic Data Masking de Snowflake, une fonctionnalité de l'édition Enterprise, masque les valeurs en clair au moment de la requête.
  • La cible ne sait pas transformer. Un entrepôt hérité à capacité fixe, un index de recherche ou un dépôt de fichiers chez un partenaire attendent des données finies.
  • Un enrichissement que le SQL gère mal, comme des appels d'API par ligne, du géocodage, l'analyse de PDF ou le scoring par modèle, convient souvent mieux à Python ou Spark.
  • Du streaming à faible latence. Apache Flink ou Kafka Streams transforment les événements quelques secondes après leur apparition ; le schéma d'architecture Kafka montre d'où ils lisent.
  • Un volume que vous ne voulez pas conserver. 10 000 capteurs à une mesure par seconde produisent 864 millions de lignes par jour (10 000 × 86 400). Des moyennes à une minute calculées avant le chargement ramènent ce chiffre à 14,4 millions (10 000 × 1 440), soit 60 fois moins.

L'hybride courant

En pratique, de nombreux pipelines ELT incluent une petite transformation avant le chargement, parfois appelée EtLT. Ne transformez en vol que ce qui ne doit jamais arriver brut ; faites tout le reste dans l'entrepôt, où c'est versionné, testé et facile à reconstruire.

Pour les données personnelles, le hachage de colonnes de Fivetran hache une colonne pendant la synchronisation avec SHA-256 et un sel propre à chaque destination, si bien que les e-mails hachés restent joignables ; le blocage de données supprime une colonne entièrement. Les mappings d'Airbyte peuvent hacher ou chiffrer des champs par flux. Quel que soit l'outil, préférez un hachage salé : un SHA-256 simple d'une adresse e-mail peut être comparé à une liste d'adresses connues. Deux autres réserves : le hachage ne couvre que les synchronisations futures, l'historique demande donc une nouvelle synchronisation, et un hachage salé est pseudonyme, pas anonyme. Selon le RGPD, les données pseudonymisées restent des données personnelles (considérant 26). Cet article n'est pas un avis juridique ; lisez le texte officiel avec votre équipe vie privée et tenez une cartographie des données des flux de données personnelles.

ELT avec des modèles SQL en couches

Le guide de structure de projet de dbt décrit trois couches qui fonctionnent avec n'importe quel outil SQL :

Couche Rôle Matérialisée en Lue par
Staging Un modèle par table source, comme stg_shop__orders : renommer, convertir les types, passer des centimes aux dollars ; ni jointures ni agrégations Vues Autres modèles
Intermediate Étapes dédiées, comme agréger les lignes de commande en commandes Modèles éphémères, ou vues dans un schéma séparé Autres modèles
Marts Une table large par entité métier, comme les commandes ou les clients Tables ou modèles incrémentaux Outils de BI et analystes

Les lakehouses reprennent la même idée sous les noms bronze, silver et gold ; voir le schéma d'architecture medallion.

dbt fournit quatre tests de données génériques, unique, not_null, accepted_values et relationships, et toute requête qui renvoie des lignes en échec peut devenir un test. Les contrôles de fraîcheur détectent un loader arrêté sans bruit. Une seule définition de source déclare les deux :

sources:
  - name: shop
    schema: raw_shop
    config:
      loaded_at_field: _fivetran_synced
      freshness:
        warn_after: {count: 12, period: hour}
        error_after: {count: 24, period: hour}
    tables:
      - name: orders
        columns:
          - name: id
            data_tests:
              - unique
              - not_null

dbt source freshness (ou dbt freshness dans dbt v2) émet un avertissement quand la valeur _fivetran_synced la plus récente a plus de 12 heures et signale une erreur après 24.

Orchestration et qualité des données

Un orchestrateur exécute les étapes dans l'ordre. Dans Airflow, un DAG (des tâches avec dépendances et un planning) déclenche la synchronisation du loader, l'attend, puis lance dbt. L'intégration dbt de Dagster transforme chaque modèle dbt en asset, une table qui doit exister, si bien qu'un mart peut dépendre directement de la table qu'écrit une synchronisation Fivetran.

Dans les deux cas, dbt build garde les mauvaises données hors des tableaux de bord : il exécute modèles, tests, snapshots et seeds dans l'ordre du DAG, et un test en échec fait sauter tout ce qui est en aval. Ajoutez des contrôles de fraîcheur et une alerte vers l'équipe responsable, et les données fausses comme les données anciennes apparaissent avant qu'un décideur ne les remarque.

Le Reverse ETL, qu'Airbyte appelle data activation, va dans l'autre sens : il copie les données modélisées de l'entrepôt vers des outils comme un CRM ou un support desk. Au moment de la rédaction (novembre 2026), Hightouch le propose comme produit autonome, et Fivetran (qui a racheté Census) et Airbyte l'intègrent à l'ingestion.

Le schéma ETL vs ELT

Deux couloirs superposés. ETL : Postgres des commandes, moteur de transformation, entrepôt avec fct_orders, tableaux de bord BI. ELT : Postgres, loader qui hache les PII, entrepôt avec raw.orders, modèles dbt et marts.fct_orders, puis BI. Une note d'ordre d'exécution est en dessous.

21 composants · 8 connexions

Ouvrir dans Archboard
Contenu du diagramme
  • ETL: extract, transform, then load
  • ELT: extract, load, then transform in the warehouse
  • Warehouse
  • Orders DB (Postgres)
  • Transform engine (Spark, SSIS)
  • fct_orders
  • BI dashboards
  • Loader (Fivetran, Airbyte)
  • raw.orders (as loaded)
  • dbt models: staging, intermediate
  • marts.fct_orders
  • raw rows
  • cleaned, conformed rows
  • SQL queries
  • raw rows, PII hashed
  • raw tables
  • built tables
La même base de commandes alimente deux pipelines. L'ETL transforme les lignes sur son propre moteur : seules les tables modélisées atteignent l'entrepôt. L'ELT hache les PII dans le loader, charge les lignes brutes et exécute des modèles SQL dans l'entrepôt.

Comment le lire :

  • Deux couloirs, mêmes extrémités : la même base de commandes Postgres et les mêmes tableaux de bord BI. Seul le milieu change.
  • L'ambre marque la transformation : un moteur distinct avant l'entrepôt en ETL, le cadre des modèles dbt dans l'entrepôt en ELT.
  • Les cadres de l'entrepôt montrent ce qui est stocké. Celui de l'ETL ne contient que fct_orders ; celui de l'ELT contient raw.orders tel que chargé, les modèles et marts.fct_orders.
  • L'arête violette est l'hybride : le loader hache les données personnelles avant que les lignes n'arrivent.
  • Le bloc Markdown liste l'ordre d'exécution de l'ELT, les seuils de fraîcheur et le schéma lu par la BI.

Dessiner clairement des schémas ETL et ELT

  • Placez la transformation là où elle tourne. Dessiner la transformation de l'ELT hors de l'entrepôt cache son principal coût et son principal risque.
  • Dessinez l'entrepôt comme une frontière. Raw, staging et marts dans un même cadre sont des schémas d'un seul système, pas des bases séparées.
  • Étiquetez les arêtes avec ce qui circule (lignes brutes, lignes hachées, tables construites) et le planning quand il compte.
  • Indiquez où les données personnelles sont masquées et où elles existent encore en clair.
  • Montrez les couches, pas chaque modèle. Une table d'exemple par couche suffit ; le lignage relève de la documentation générée par dbt.
  • Séparez le flux de contrôle. Dessinez les déclencheurs de l'orchestrateur en arêtes pointillées pour que personne ne les confonde avec des données.

Le schéma d'architecture de pipeline de données montre un pipeline complet avec CDC, Kafka et un entrepôt.

Le construire dans Archboard

  1. Connectez-vous avec Google ou GitHub et créez un diagramme.
  2. Ajoutez deux nœuds Cadre du pack Base, l'un au-dessus de l'autre, pour les couloirs ETL et ELT, et un Cadre imbriqué pour l'entrepôt dans chaque couloir, à la même position horizontale.
  3. Dans le couloir ETL, ajoutez un nœud Postgres du pack Données, une Boîte Base pour le moteur de transformation, un nœud Entrepôt de données du pack Données pour fct_orders dans le cadre de l'entrepôt, et une Boîte Base pour la BI. Étiquetez les arêtes : raw rows, cleaned and conformed rows, SQL queries.
  4. Dans le couloir ELT, ajoutez un nœud Postgres et une Boîte Base pour le loader. Dans le cadre de l'entrepôt, ajoutez des nœuds Entrepôt de données pour raw.orders et marts.fct_orders, avec une Boîte Base pour les modèles dbt entre eux. Terminez par une Boîte Base pour la BI et étiquetez les arêtes de la même façon.
  5. Colorez les deux boîtes de transformation en ambre et l'arête sortante du loader en violet. Ajoutez des notes Texte Base sous les nœuds qui demandent une explication et une courte légende des couleurs.
  6. Ajoutez un bloc Markdown du pack Base avec l'ordre d'exécution et les seuils de fraîcheur.

Si le pipeline existe déjà sous forme d'organigramme Mermaid, collez-le dans l'outil Mermaid vers diagramme modifiable pour obtenir un premier brouillon. L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre ETL et ELT ? L'endroit où tourne la transformation. L'ETL transforme les données sur un moteur distinct et ne charge que le résultat. L'ELT charge d'abord les données brutes dans l'entrepôt et les transforme sur place avec du SQL, si bien que la copie brute reste disponible pour les reconstructions.

L'ETL est-il dépassé ? Non. L'ELT est le choix par défaut habituel sur les entrepôts cloud, mais l'ETL reste adapté quand les données personnelles doivent être masquées avant d'arriver, quand la cible ne sait pas transformer, et pour l'enrichissement lourd ou le streaming à faible latence.

dbt est-il un outil ETL ? dbt couvre le T de l'ELT. Il exécute des modèles SQL et des tests dans votre entrepôt mais n'extrait ni ne charge de données ; c'est le rôle d'un loader comme Fivetran ou Airbyte.

L'ELT coûte-t-il moins cher que l'ETL ? Cela dépend du volume et des habitudes. L'ELT supprime le moteur distinct mais facture chaque exécution de modèle en calcul d'entrepôt et stocke des copies brutes. Les modèles incrémentaux maintiennent les coûts bas ; les reconstructions complètes horaires de grandes tables, non.

Qu'est-ce que le reverse ETL ? Copier des données modélisées de l'entrepôt vers des outils opérationnels comme un CRM. Il doit lire depuis les marts, s'exécuter selon un planning et recevoir les mêmes tests et la même responsabilité que n'importe quel autre pipeline.

Commencez gratuitement — un siège, sans carte bancaire.

Articles associés

← Retour au blog

Ouvrez un canevas en une minute

Connectez-vous avec Google ou GitHub. Gratuit pour un siège. Passez à un forfait supérieur quand l’équipe vous rejoint.