ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Architectures des outils ELT managés : Fivetran, Airbyte et dlt

Comment les trois outils d'ingestion de données dominants abordent le même problème différemment — connecteurs entièrement managés, open source auto-hébergé et bibliothèques Python natives.

Planté
dltdata engineeringetl

Fivetran, Airbyte et dlt sont les trois outils d’ingestion de données dominants en 2026. Tous déplacent des données de sources vers un entrepôt, mais ils adoptent des approches architecturales différentes qui déterminent dans quel contexte chacun est le choix approprié.

Fivetran : ELT entièrement managé

Fivetran a été le pionnier du modèle ELT entièrement managé. Vous configurez les connecteurs via une interface web, et Fivetran gère tout : extraction, détection de schéma, chargement incrémental et livraison vers votre entrepôt. Aucune infrastructure à gérer, aucun code à écrire.

L’architecture est délibérément opinionée. Les connecteurs de Fivetran sont construits et maintenus par leurs propres ingénieurs. Lorsque Salesforce modifie son API, lorsque Google Ads publie une nouvelle version d’API, lorsque Meta ajuste ses fenêtres d’attribution — l’équipe de Fivetran met à jour son connecteur. Vous n’avez pas à vous en préoccuper. C’est le produit.

Les compromis sont réels. Vous n’avez aucune visibilité sur le fonctionnement interne du connecteur et une capacité limitée à modifier son comportement. Vous obtenez le schéma de Fivetran et son planning de synchronisation. Vous souhaitez extraire un champ qu’il n’inclut pas ? Appliquer des transformations au moment de l’extraction ? Ce n’est pas ainsi que fonctionne Fivetran. Vous travaillez dans leur modèle ou vous n’utilisez pas leur connecteur.

Le modèle commercial suit l’architecture : vous payez par ligne active mensuelle (MAR), ce qui signifie que vos coûts évoluent avec le volume de données d’une manière qui peut être difficile à prévoir. Le changement de tarification de mars 2025 a supprimé les remises en volume et introduit un système MAR par paliers par connecteur, ce qui a considérablement modifié l’économie pour les équipes disposant de nombreuses connexions ou de données marketing à volume élevé.

Fivetran est le plus pertinent lorsque la fiabilité et la maintenance nulle importent plus que le coût et le contrôle. Leur SLA est de 99,9 % de disponibilité avec des mises à jour automatiques. Lorsque vous avez besoin de synchronisations depuis plusieurs outils SaaS qui fonctionnent simplement, il tient ses promesses.

Airbyte : le challenger open source

Airbyte a démarré comme une alternative open source avec une architecture à base de connecteurs familière aux utilisateurs de Fivetran. Vous disposez d’une interface web, de configurations de connecteurs et de synchronisations planifiées — mais vous pouvez l’auto-héberger sur Kubernetes ou utiliser leur offre cloud.

Le modèle open source signifie que deux catégories de connecteurs coexistent : les connecteurs officiels maintenus par l’équipe d’ingénierie d’Airbyte, et les connecteurs contribués par la communauté maintenus par leurs auteurs respectifs. C’est à la fois la force et la faiblesse.

Architecturalement, Airbyte est plus lourd qu’il n’y paraît initialement. Chaque connecteur s’exécute dans son propre conteneur Docker. Airbyte lui-même nécessite un cluster Kubernetes avec ses propres exigences opérationnelles — PostgreSQL externe, stockage objet pour les logs, et l’expertise opérationnelle pour maintenir le cluster en bonne santé. L’interface abstrait cette complexité, mais elle est bien présente.

La version auto-hébergée conserve les données dans votre infrastructure, ce qui importe pour les organisations soucieuses de la conformité. La version cloud échange le contrôle opérationnel contre une infrastructure managée.

Airbyte a introduit une tarification basée sur la capacité en février 2025, remplaçant la tarification par crédits par un modèle volumétrique : 15 $ par million de lignes pour les sources API, 10 $ par Go pour les sources de bases de données et de fichiers. C’est généralement plus prévisible que le modèle MAR de Fivetran pour la plupart des charges de travail, mais l’auto-hébergement ajoute des coûts d’infrastructure qui ne sont pas toujours évidents au départ. Voir Tarification Airbyte et Coûts d'Auto-hébergement pour la vue complète.

dlt : bibliothèque Python native

dlt (data load tool) prend un chemin entièrement différent. C’est une bibliothèque Python que vous installez via pip. Pas d’interface, pas de conteneurs, pas de serveurs d’orchestration. Vous écrivez des scripts Python qui définissent vos pipelines, et ces scripts s’exécutent partout où Python peut s’exécuter — votre ordinateur portable, un DAG Airflow, une Cloud Function ou une GitHub Action.

La bibliothèque gère les parties complexes : inférence de schéma, chargement incrémental, coercition de type, normalisation JSON imbriqué. Vous gérez la logique du pipeline. Un pipeline complet ciblant BigQuery peut tenir en 20 à 30 lignes de Python :

import dlt
from dlt.sources.rest_api import rest_api_source
source = rest_api_source({
"client": {
"base_url": "https://api.example.com/v1",
"auth": {"type": "bearer", "token": dlt.secrets.value}
},
"resources": [
{
"name": "campaigns",
"endpoint": {"path": "campaigns"},
"write_disposition": "merge",
"primary_key": "id"
}
]
})
pipeline = dlt.pipeline(
pipeline_name="campaigns",
destination="bigquery",
dataset_name="marketing"
)
load_info = pipeline.run(source)

La différence architecturale est totale. Fivetran et Airbyte sont des plateformes avec des connecteurs. dlt est une bibliothèque avec un framework. Lorsque vous utilisez Fivetran, vous configurez leur système. Lorsque vous utilisez dlt, vous écrivez du code qui utilise leur framework. Cette distinction détermine ce que vous pouvez et ne pouvez pas contrôler.

dlt ne coûte rien au-delà de l’infrastructure que vous choisissez pour l’exécuter. Il est sous licence Apache 2.0 open source. Vos coûts sont le calcul (souvent quelques centimes pour des Cloud Functions serverless) et votre entrepôt de destination. La flexibilité de déploiement est réelle — le même pipeline s’exécute localement pour le développement et en production sans modification de code.

Le compromis est que dlt requiert une maîtrise de Python et une infrastructure auto-gérée. Il n’y a pas de tableau de bord de monitoring, pas d’alertes automatiques, pas d’équipe de support dédiée. Si une API source change, vous gérez la mise à jour. Si une exécution échoue, vous déboguez.

Le spectre que cela crée

Les trois outils forment un spectre :

FivetranAirbytedlt
ConfigurationInterface web, minutesInterface web + Kubernetes, jourspip install, minutes
MaintenanceQuasi nulleFaible (cloud) / Élevée (auto-hébergé)Vous en êtes responsable
CoûtBasé sur MAR, coûteux à grande échelleBasé sur la capacité, modéréInfrastructure uniquement
ContrôleFaibleMoyenTotal
Python requisNonNonOui
MonitoringIntégréIntégré (cloud)Externe

Aucune position sur ce spectre n’est objectivement meilleure. Les équipes avec des propriétaires de données non techniques, des exigences de conformité d’entreprise ou une tolérance zéro aux défaillances de pipeline se tournent vers Fivetran. Les équipes maîtrisant Python avec des contraintes budgétaires ou des exigences de sources personnalisées se tournent vers dlt. Airbyte sert les équipes du milieu — soucieuses des coûts mais pas encore prêtes à adopter une approche entièrement code-first.

La plupart des équipes data matures finissent par utiliser un mélange, en utilisant différents outils pour différentes sources selon le volume, la disponibilité des connecteurs et la surcharge opérationnelle acceptable.