Votre équipe relance un pipeline sans savoir si les données ont changé. Une autre corrige une colonne SQL après avoir attendu l'exécution dans l'entrepôt. Les annonces dbt de septembre touchent ces deux problèmes, avec des mécanismes et des coûts différents.
dbt v2 et dbt State sont désormais en disponibilité générale. Le premier renouvelle le moteur de transformation ; le second décide quand un résultat peut être réutilisé. Les adopter ensemble n'est pas une obligation. La bonne première étape consiste à vérifier le moteur sur un petit projet, puis à mesurer séparément l'intérêt de State.
Les annonces examinées ont été publiées le 16 septembre 2026, pendant le dbt Summit organisé du 15 au 18 septembre. Cet article est une analyse des annonces officielles et de la documentation vérifiée le 30 septembre, pas un compte rendu de sessions visionnées. Le projet téléchargeable ci-dessous a été exécuté localement avec dbt 2.0.6.
Ce que fait dbt, et ce qui change avec v2
Un projet dbt contient des modèles SQL, des dépendances déclarées avec ref, des configurations et des tests. Le moteur transforme cet ensemble en instructions adaptées à la base cible, puis construit les tables ou les vues. Il organise les transformations ; il ne remplace pas à lui seul l'ingestion de vos sources ni la définition de vos indicateurs. Voir les principes des modèles SQL.
Le moteur auparavant nommé Fusion devient dbt v2. Il repose sur Rust et ajoute une compréhension du SQL qui permet de repérer certaines erreurs avant l'exécution des modèles. L'annonce présente aussi un Information Schema en fichiers Parquet et une nouvelle expérience de documentation. Les gains de vitesse décrits par l'éditeur restent à mesurer sur votre projet. Annonce dbt v2.
Deux distributions coexistent : dbt, utilisable gratuitement en local avec les fonctionnalités avancées de compréhension SQL, et dbt OSS, composée uniquement de composants sous Apache 2.0. La gratuité d'usage et la licence open source sont deux critères distincts. Pour choisir, vérifiez les fonctions nécessaires et les règles de votre organisation. Comparaison officielle des distributions.
Une migration ne doit donc pas se résumer à remplacer le nom d'un paquet dans la CI. Il faut identifier le binaire effectivement lancé, la version, l'adaptateur et les consommateurs de ses fichiers de sortie. Sinon, deux développeurs peuvent parler de « dbt » tout en exécutant des distributions différentes.
Les annonces à répartir dans votre plan de travail
À tester sur un périmètre isolé : dbt v2. Les notes de version confirment Snowflake, BigQuery, Redshift et Databricks en local et sur la plateforme ; DuckDB est disponible en local. Le statut de chaque adaptateur doit être vérifié pour le mode de déploiement visé. Une disponibilité locale ne prouve pas une disponibilité identique sur la plateforme. Notes de septembre.
À évaluer avec une mesure économique : dbt State. Il compare la logique, la configuration et la fraîcheur des données pour choisir entre reconstruction et réutilisation, avec clonage lorsque c'est applicable. Son intérêt dépend de ce que vos jobs recalculent réellement. Fonctionnement de State.
À garder en expérimentation : Lake Compute. Cette bêta privée exécute des transformations sur Iceberg avec un moteur fondé sur DuckDB. Au 30 septembre, les régions documentées sont us-east-1 et us-west-2, avec Snowflake comme entrepôt pris en charge ; Databricks est limité à des partenaires de conception. Ce périmètre ne convient pas automatiquement à une plateforme française hébergée en Europe. Prérequis et limites.
À essayer sur un usage BI limité : dbt Charts. La bêta publique permet de décrire des tableaux de bord en YAML et de les versionner avec les modèles. La documentation distingue les requêtes SQL disponibles aujourd'hui de l'interrogation des métriques par nom via la Semantic Layer, encore prévue. Ne présumez donc pas que les indicateurs gouvernés de votre BI sont repris sans adaptation. Documentation Charts.
Enfin, Wizard et les annonces de contexte pour les agents élargissent le périmètre vers l'IA. Les statuts diffèrent selon le produit : l'annonce distingue notamment Wizard sur la plateforme en public preview, sa CLI en public beta et Desktop en private beta. Pour une équipe qui veut d'abord fiabiliser ses transformations, ces essais peuvent attendre la validation du moteur.
dbt State : calculer le gain net avant de l'activer partout
Avec une sélection classique comme state:modified, vous comparez un projet à un état de référence. Cela ne suffit pas, à lui seul, à déterminer si les données sources ont changé. State ajoute cette dimension et peut éviter des reconstructions ou préparer un environnement par clonage. La tolérance de fraîcheur devient un paramètre à discuter avec les utilisateurs des données, pas seulement une optimisation technique.
Son installation exige un compte dbt platform, même pour une utilisation locale ou avec votre orchestrateur. State est intégré à v2 et existe en plugin pour v1.7 à v1.12. Les plateformes documentées sont Snowflake, BigQuery, Databricks et Redshift. L'essai de 30 jours ne se met pas en pause une fois commencé. Le petit atelier DuckDB de cet article n'active pas State.
La documentation de facturation compte les daily active target tables, ou DATT : des cibles distinctes réutilisées dans une journée UTC. Les tests distincts entrent aussi dans ce décompte. Plusieurs réutilisations de la même cible le même jour ne deviennent pas autant de DATT.
Le tarif catalogue vérifié le 30 septembre est de 0,094 USD par DATT, avant les éventuelles conditions de contrat. Exemple purement arithmétique : 600 DATT chaque jour pendant 30 jours donnent 18 000 unités, soit 1 692 USD. Ce n'est ni un devis ni une estimation de votre usage.
Pour juger le pilote, comparer sur la même période :
- le calcul facturé par l'entrepôt avec et sans réutilisation ;
- le coût State, les éventuels coûts de stockage ou de clonage et le temps de maintenance ;
- la fraîcheur observée au moment où le métier consulte les données ;
- les incidents, reprises et résultats divergents.
Une baisse du nombre de requêtes ne garantit pas une baisse équivalente de la facture. Avec une capacité réservée ou une autre charge qui occupe déjà l'entrepôt, le gain peut d'abord être du temps disponible. Le pilote doit nommer le bénéfice qu'il cherche à prouver.
Trois cas concrets pour une équipe data
1. Une équipe retail corrige souvent des colonnes absentes
Situation illustrative : les analystes modifient les modèles de ventes, puis attendent le lancement d'un job pour découvrir une référence invalide. Un essai v2 sur une branche et un schéma dédiés peut vérifier si ces erreurs sont détectées plus tôt.
Mesurez le délai entre la modification et le premier diagnostic utile, puis vérifiez que les totaux restent identiques. Le risque est de confondre SQL valide et définition correcte du chiffre d'affaires : une commande annulée incluse par erreur peut rester parfaitement compilable. Le guide sur les modèles sémantiques traite la définition commune des indicateurs ; un nouveau moteur ne décide pas cette définition pour vous.
2. Une équipe finance reconstruit des tables peu modifiées
Situation illustrative : les chargements arrivent à quelques moments précis, mais les transformations sont lancées bien plus souvent. Avant d'ajouter State, rapprochez les horaires d'arrivée réels, les dépendances et l'heure limite de disponibilité pour la clôture.
Le critère de succès est un coût net inférieur avec des données suffisamment fraîches au moment attendu. Un pilote doit couvrir aussi un retard d'ingestion et une correction tardive. Un job rapide qui sert un chiffre trop ancien ne remplit pas le besoin. Faites valider la tolérance par le propriétaire de l'indicateur.
3. Une équipe plateforme maintient beaucoup de macros
Situation illustrative : des matérialisations personnalisées et des packages internes traversent tout le projet. La priorité est l'inventaire de compatibilité, puis un chemin de dépendances représentatif. Dans la configuration actuelle de v2, certaines matérialisations personnalisées désactivent l'analyse statique, avec un effet sur les descendants. Le niveau effectivement appliqué mérite donc un contrôle. Référence de l'analyse statique.
Le livrable utile est une liste de modèles couverts, de modèles à adapter et de résultats comparés. Comptez l'effort de correction des macros dans le coût de migration. Si les parties critiques restent hors couverture, garder l'existant le temps de les traiter peut être une décision solide.
Tutoriel : essayer dbt v2 sans compte d'entrepôt
L'objectif est précis : construire deux modèles, détecter une colonne absente, puis montrer qu'un test métier reste indispensable. Les données sont synthétiques. Ce test ne mesure ni State ni la performance d'un entrepôt.
Télécharger le projet complet, avec son mode d'emploi. L'exécution a été vérifiée le 30 septembre sur macOS arm64, avec Python 3.12 et dbt 2.0.6. L'installation officielle propose aussi d'autres méthodes et systèmes.
1. Isoler l'installation
Décompressez le projet dans un nouveau dossier et ouvrez-y un terminal. Sur macOS ou Linux :
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
dbt --version
Le fichier requirements.txt fixe dbt==2.0.6. Conservez votre installation de production. Le profil fourni utilise un fichier DuckDB local, sans identifiants cloud. La documentation DuckDB précise néanmoins des différences avec l'adaptateur v1, notamment autour des extensions et de l'analyse des fichiers plats. Notre exemple utilise des valeurs SQL intégrées pour rester simple.
2. Construire le résultat de référence
Le premier modèle contient trois commandes : deux payées, de 120 et 80 euros, et une annulée, de 40 euros. Le second calcule :
select sum(montant_eur) as ca_eur
from {{ ref('commandes') }}
where statut = 'payee'
Le projet configure l'analyse statique en mode strict et désactive State. Lancez :
dbt build --profiles-dir . --no-manage-state
dbt show --select ca_encaisse --profiles-dir . --no-manage-state
Résultat vérifié : deux modèles construits, un test réussi et ca_eur = 200. Le paramètre --profiles-dir . utilise le profil de l'atelier, pas celui de vos autres projets.
3. Provoquer une erreur de colonne
Dans models/ca_encaisse.sql, remplacez sum(montant_eur) par sum(montant_inexistant), puis exécutez :
dbt compile --profiles-dir . --no-manage-state
La compilation échoue. Dans notre exécution, le diagnostic dbt0209 indique que la colonne est introuvable. Le contrôle montre ce que l'analyse SQL apporte sur ce cas, sans extrapoler à toutes les fonctions de votre entrepôt.
4. Provoquer une erreur de sens métier
Rétablissez la colonne, puis écrivez sum(montant_eur) * 100. Cette requête reste valide, mais change l'unité du résultat. Relancez la compilation puis le build.
La compilation réussit. Le test ca_attendu échoue, car il recherche une valeur nulle ou différente de 200 :
select * from {{ ref('ca_encaisse') }}
where ca_eur is null or ca_eur <> 200.00
Le build a déjà construit les tables avant l'échec du test. En production, il faut organiser la promotion des résultats validés ; un statut en échec ne signifie pas que toutes les écritures sont annulées. Ici, rétablissez la formule initiale et relancez le build : les trois contrôles doivent réussir.
La constante 200 est notre référence pédagogique. Pour vos données réelles, construisez des cas attendus et des règles métier appropriées, comme dans le guide sur les data contracts. Pour nettoyer, quittez l'environnement avec deactivate, puis supprimez uniquement le dossier de cet atelier si vous n'en avez plus besoin.
Préparer une migration qui reste réversible
Le guide de migration v2 recommande de traiter les dépréciations et de vérifier les packages. Avec dbt v1.12, le paramètre --use-v2-parser permet aussi de tester le parseur avant de changer toute l'exécution. Cela ne remplace pas une comparaison des résultats.
Pour un pilote représentatif, choisissez un modèle simple, un modèle incrémental et un chemin avec vos macros usuelles. Figez les entrées ou consignez leur fenêtre. Comparez les schémas, les effectifs, les clés, les agrégats métier et les comportements lors d'une reprise. Conservez les versions des dépendances, les journaux et les commandes exactes.
Séparez trois conclusions dans le compte rendu : le projet fonctionne sur v2, l'expérience de développement s'améliore, la facture diminue. Chacune demande une preuve différente. La réussite du petit atelier ne suffit qu'à comprendre le mécanisme.
Pour commencer cette semaine : exécuter l'atelier, choisir un périmètre réel et définir le critère qui justifierait la migration. State vient ensuite si le recalcul inutile est un problème mesuré. Charts et Lake Compute restent des essais ciblés avec leurs limites actuelles. L'intérêt des annonces dbt se juge sur une décision d'équipe vérifiable, pas sur le nombre de nouveautés activées.
