Les analytics engineers font face à un choix inconfortable pour charger des données dans leurs data warehouses. Payer plus de 12 000 $ par an pour des outils managés comme Fivetran, ou passer des semaines à construire des pipelines custom qui nécessitent une maintenance continue. dlt propose une troisième voie qui gagne du terrain parmi les équipes data à l’aise avec Python.
Le problème que dlt résout
Adrian Brudaru a fondé dltHub à Berlin après une décennie de freelance en data engineering. Son constat était simple : chaque projet data nécessitait de recréer des solutions similaires from scratch. On réinventait la roue en permanence.
Les chiffres confirment que ce n’est pas un cas isolé. Selon Wakefield Research, les data engineers consacrent 44 % de leur temps à construire et maintenir des pipelines, ce qui coûte aux entreprises environ 520 000 $ par an. Le développement d’un connecteur custom prend à lui seul 50 à 100 heures.
dlt s’attaque à ce que ses créateurs appellent « le problème non résolu de l’ingestion de données Pythonic ». La librairie comble un vide spécifique entre les solutions SaaS coûteuses qui facturent à la ligne et le développement complet from scratch avec requests et pandas.
La philosophie est code-first et Python-native. Les pipelines sont des scripts Python standards, pas des configurations YAML ni des builders visuels. On l’installe avec pip, on écrit du Python et on exécute les pipelines partout où Python tourne. Pas besoin de conteneurs, de serveurs d’orchestration ni d’API externes pour démarrer.
Concepts fondamentaux pour les analytics engineers
dlt organise le chargement de données autour de quatre concepts : sources, resources, pipelines et schemas.
Les sources sont des regroupements logiques déclarés avec le décorateur @dlt.source. Elles définissent la configuration commune (URL de base, authentification) partagée par plusieurs endpoints.
Les resources sont des briques modulaires représentant des extractions de données spécifiques. Déclarées avec @dlt.resource, elles peuvent être des générateurs Python qui produisent des données de manière incrémentale pour optimiser la mémoire :
@dlt.resource(write_disposition="merge", primary_key="id")def users(): for page in paginate_api("/users"): yield pageLes pipelines exécutent le travail concret. On en crée un avec dlt.pipeline() en spécifiant la destination et le nom du dataset. Le pipeline gère l’extraction, la normalisation et le chargement tout en maintenant l’état entre les exécutions.
Les schemas sont inférés automatiquement à partir des données. dlt détecte les types, normalise les structures imbriquées en tables relationnelles et gère l’évolution automatiquement. Quand les données source ajoutent de nouveaux champs, dlt déclenche des migrations de tables automatiques. Pour les pipelines de production, les schema contracts permettent d’imposer des contraintes de qualité plutôt que d’accepter n’importe quel changement.
Trois write dispositions contrôlent comment les données atterrissent :
replace: remplacement complet de la table à chaque exécutionappend: ajout de nouveaux enregistrements aux données existantesmerge: upsert via des primary keys ou merge keys
Ces briques s’articulent bien en pratique. Un script dlt basique peut tenir en 20 lignes de Python tout en gérant la pagination, le rate limiting, l’inférence de schéma et le chargement incrémental automatiquement.
Intégration BigQuery
Pour les analytics engineers sur BigQuery, dlt inclut des optimisations natives qui valent le détour.
L’installation ajoute les extras BigQuery :
pip install "dlt[bigquery]"La configuration se trouve dans secrets.toml avec les credentials du service account :
[destination.bigquery]project_id = "your-project"private_key = "-----BEGIN PRIVATE KEY-----\n..."client_email = "sa@your-project.iam.gserviceaccount.com"dlt propose deux stratégies de chargement pour BigQuery. Les streaming inserts conviennent aux chargements append-only à faible latence, où les données apparaissent rapidement mais coûtent plus cher par ligne. Le GCS staging gère mieux les gros volumes : dlt uploade vers un bucket Cloud Storage, puis lance une commande COPY vers BigQuery. Au-delà de petits datasets, le staging est le bon choix et peut avoir un impact significatif sur vos coûts BigQuery.
La fonction bigquery_adapter() expose le partitionnement et le clustering :
from dlt.destinations.adapters import bigquery_adapter
@dlt.resourcedef events(): yield from get_events()
# Partitionner par date, clusterer par user_idbigquery_adapter( events, partition="event_date", cluster=["user_id"])Les structures JSON imbriquées sont normalisées automatiquement en tables parent-enfant. Une API renvoyant des utilisateurs avec des adresses imbriquées crée à la fois une table users et une table enfant users__addresses, liées par les colonnes _dlt_id et _dlt_parent_id. On peut contrôler la profondeur d’imbrication avec max_table_nesting. Un réglage à 2-3 produit des schemas lisibles sans prolifération excessive de tables.
dlt crée aussi des tables de métadonnées dans votre dataset : _dlt_loads suit les exécutions du pipeline, _dlt_pipeline_state stocke l’état du chargement incrémental et _dlt_version enregistre les versions de schéma.
Chargement incrémental
Le chargement incrémental sépare les pipelines jouets des pipelines de production, tout comme les modèles incrémentaux dans dbt séparent les prototypes des transformations de production. dlt gère cela avec un suivi par curseur qui nécessite un minimum de configuration.
Le chargement incrémental par curseur utilise dlt.sources.incremental() avec un cursor path :
@dlt.resource(primary_key="id")def orders( updated_at=dlt.sources.incremental( "updated_at", initial_value="2024-01-01T00:00:00Z" )): for page in api.get_orders(since=updated_at.last_value): yield pageAu premier run, dlt utilise la valeur initiale. Aux exécutions suivantes, il suit automatiquement la valeur maximale du curseur et ne récupère que les enregistrements plus récents. L’état persiste dans votre destination, donc aucun state store externe n’est nécessaire.
Pour les sources REST API, la configuration est déclarative :
{ "name": "orders", "endpoint": { "path": "/orders", "params": { "since": { "type": "incremental", "cursor_path": "updated_at", "initial_value": "2024-01-01T00:00:00Z" } } }}L’efficacité mémoire vient du fait de produire les données page par page plutôt que d’accumuler des datasets entiers. Une resource basée sur un générateur peut traiter des millions d’enregistrements sans tous les charger en mémoire.
Maturité pour la production
Les chiffres aident à évaluer si un outil est prêt pour des charges de production.
Le dépôt GitHub de dlt affiche environ 4 700 stars, plus de 400 forks, 146 contributeurs et plus de 4 000 commits. La version 1.19.1 est sortie en décembre 2025. La librairie a atteint le statut stable 1.0 et reste activement développée. Plus de 1 300 dépôts utilisent dlt, avec 113 releases publiées au total.
Plus important que les métriques GitHub : les déploiements en production.
Un praticien a rapporté un « coût ETL divisé par 182 par mois, temps de synchronisation amélioré de 10x » après avoir migré de Fivetran vers dlt.
La communauté Slack de dlt offre un support actif, ce qui aide quand on débogue un pipeline à 2 h du matin.
Limites
dlt a de vraies contraintes qui influencent s’il convient à votre équipe.
Pas de dashboard de monitoring intégré. Soit vous construisez l’observabilité vous-même, soit vous attendez la plateforme prévue par dltHub. En attendant, les équipes s’intègrent avec les interfaces Dagster ou Airflow, ou construisent un logging custom.
Pas d’interface visuelle. Tout passe par le code. C’est un avantage pour certaines équipes et un blocage pour d’autres. Les utilisateurs non techniques ne peuvent pas configurer les connecteurs eux-mêmes.
Opérations en autonomie. Les équipes gèrent le déploiement, le scaling, la sécurité et le monitoring. dlt fournit les primitives de chargement, mais le faire tourner en production demande du travail d’infrastructure. La planification, les alertes et la reprise sur erreur sont de votre responsabilité.
Pas de connecteurs CDC natifs. Si vous avez besoin de change data capture depuis des bases de données avec un outil comme Debezium, il faudra construire cette intégration ou utiliser un autre outil.
Nombre limité de connecteurs pré-construits. dlt propose plus de 60 sources vérifiées contre plus de 700 chez Fivetran. Le REST API builder permet de générer des pipelines pour de nombreuses autres API, mais vous écrivez de la configuration plutôt que de cliquer sur « activer ».
Ces compromis déplacent les coûts des frais d’abonnement vers le temps d’ingénierie.
Quand dlt est le bon choix
dlt convient bien à des profils d’équipe spécifiques.
Équipes compétentes en Python qui veulent garder le contrôle. Si vos data engineers sont à l’aise pour écrire et maintenir du Python, dlt paraît naturel. L’approche code-first signifie que les pipelines sont versionnés, testables et auditables comme n’importe quel autre code.
Équipes soucieuses du budget, prêtes à investir du temps d’ingénierie. dlt est sous licence Apache 2.0 sans frais. Vous ne payez que le compute et le stockage. Pour les équipes avec de la capacité d’ingénierie mais un budget outillage limité, l’équation économique est claire.
Projets greenfield ou sources custom. Quand vous construisez quelque chose de nouveau et devez ingérer depuis des API sans connecteurs pré-construits, la source REST API et les patterns à base de décorateurs de dlt permettent d’avancer vite.
Équipes qui orchestrent déjà avec Airflow ou Dagster. dlt s’intègre bien aux orchestrateurs existants. Si vous faites déjà tourner Airflow, ajouter des pipelines dlt comme tâches est simple, et certainement plus simple que de faire cohabiter Fivetran et un orchestrateur. Les équipes utilisant Google Cloud Functions pour dbt peuvent déployer les pipelines dlt sur la même infrastructure.
Besoins de prototypage rapide. dlt peut tourner en local avec DuckDB comme destination. On peut prototyper un pipeline en un après-midi, vérifier la forme des données, puis basculer vers BigQuery pour la production.
Quand regarder ailleurs
dlt ne convient pas à tous les cas de figure.
Équipes data non techniques. Si vos praticiens data n’écrivent pas de Python, dlt crée une dépendance forte à l’ingénierie pour chaque modification de connecteur.
Besoin immédiat de 700+ connecteurs. Si vous devez ingérer depuis des dizaines d’outils SaaS dès demain, Fivetran ou Airbyte fournit des connecteurs pré-construits que dlt n’a pas.
Exigences de conformité demandant SOC 2 clé en main. dlt hérite de la sécurité de votre infrastructure, ce qui fonctionne pour certaines organisations. D’autres ont besoin de l’attestation qui accompagne les outils managés.
Pas de capacité d’ingénierie pour la maintenance des pipelines. Les API changent, les schemas évoluent, des cas limites apparaissent. Quelqu’un doit maintenir les pipelines dlt. Si cette capacité n’existe pas, les outils managés ont plus de sens malgré des coûts plus élevés.
Fréquence de synchronisation très élevée. Bien que dlt puisse tourner selon n’importe quel planning défini par votre orchestrateur, la charge opérationnelle des synchronisations infra-horaires est la vôtre. Les outils managés gèrent cela pour vous.
La vision stratégique
Le marché de l’intégration de données est en mouvement. Le changement de tarification de Fivetran en mars 2025 (passage d’un MAR mutualisé à un MAR par connecteur) a provoqué une frustration significative chez les utilisateurs, avec des rapports de hausse de 2 à 8x. Les données marketing à haute fréquence de mise à jour sont particulièrement touchées.
Cette pression tarifaire pousse davantage d’équipes à évaluer sérieusement les alternatives. dlt occupe une position spécifique : un chargement de données de niveau production sans aucun coût de licence, mais qui requiert des compétences Python et une prise en charge par l’ingénierie.
Pour la bonne équipe, dlt élimine la fausse dichotomie build vs buy. La librairie gère la pagination, le chargement incrémental, l’évolution de schéma et les spécificités de chaque destination, donc on ne construit pas from scratch. Mais le pipeline reste votre code, tournant sur votre infrastructure, évoluant sous votre contrôle.