dbt vous laisse-t-il encore charger les données vous-même ?

dbt, désormais une seule entreprise avec Fivetran, est explicitement un outil de transformation. Il n’extrait pas, et il ne charge pas depuis l’extérieur de l’entrepôt. C’est un choix de conception clair, et il impose à chaque équipe un second produit à acheter, configurer et payer avant que le premier modèle ne tourne.

Pourquoi la lacune coûte plus qu’il n’y paraît

• Deux produits, deux factures. L’ingestion est tarifée selon ses propres termes, par ligne ou par connecteur, et la transformation selon les siens, par licence ou par usage. Aucune des deux ne connaît l’autre.
• Deux schémas. L’outil d’ingestion dépose les données dans sa propre structure. La couche de staging de dbt consacre ensuite ses premiers modèles à convertir cette structure en une structure que le projet peut utiliser.
• Un passage de relais, tous les incidents. Un changement de schéma côté chargement se découvre sous la forme d’une exécution dbt en échec. La responsabilité du correctif est une discussion avant d’être un ticket.
• Une fusion ne corrige pas l’architecture. Depuis le 1er juin 2026, Fivetran et dbt Labs sont une seule entreprise, et toujours deux produits avec des tarifications séparées. Le schéma de chargement n’est toujours pas le modèle.

Où l’ingestion devrait se situer

• À côté du modèle. L’outil qui connaît les clés métier et les règles d’historique est l’outil le mieux placé pour charger la source comme le modèle l’attend.
• Tarifée avec l’entrepôt, pas par ligne. Charger via la plateforme s’appuie sur des ressources de calcul que vous possédez déjà, sans second décompte.
• Avec un seul responsable. Un pipeline sans passage de relais ne laisse aucune place au débat sur le côté qui a cassé.

Ce qui change avec Datavault Builder

Datavault Builder ingère et modélise dans la même plateforme : chargements batch, delta et CDC depuis des bases de données, des fichiers, des API REST, des sources NoSQL et Python, avec des flux comme Kafka qui arrivent en micro-batches, mappés directement en hubs, links et satellites.

• Pas de second produit pour le chargement. Les sources se connectent à la plateforme qui génère l’entrepôt. Un contrat, un outil, un seul endroit où regarder quand quelque chose échoue.
• Pas de structure à défaire. La table de chargement est mappée au modèle telle qu’elle arrive. Il n’y a pas de schéma intermédiaire qu’une couche de staging doive inverser.
• Les changements de schéma sont gérés au point de chargement. Une nouvelle colonne est une mise à jour de mapping, pas une exécution en échec le lendemain matin.
• La couche de livraison suit dans le même outil. Les marts et les produits de données se construisent par glisser-déposer sur la couche sémantique, avec des règles métier versionnées. Les équipes qui gardent l’exploitation dans dbt obtiennent les modèles dbt générés à partir du même modèle.
• La longue traîne peut rester. Un connecteur managé reste un bon choix pour les petites sources SaaS. Le vault ne se soucie pas de la route qu’une table a prise.

Ce qu’il faut décider

Listez les sources où le schéma de l’outil d’ingestion et le modèle de staging dbt qui le défait sont maintenus par deux personnes différentes. Ce sont les sources à charger en premier via la plateforme.