DataCette semaine en dataSoftware & SaaS

On attendait des agents plus autonomes, dbt Summit 2026 a surtout parlé de factures et de définitions

Quatre semaines après dbt Summit 2026, les annonces de Fivetran + dbt Labs et l'actualité réglementaire de la semaine vont dans le même sens : pour qu'un agent soit fiable et qu'il ne coûte pas trop cher, le sens et la gouvernance doivent être écrits dans le code de transformation. Ce débrief trie ce qui est livré de ce qui reste une promesse d'éditeur, et propose une règle de décision applicable dès lundi.

Un agent robot sous un projecteur reste immobile devant un réseau de blocs, tandis qu'un ingénieur en marque quelques-uns de rubans rouges.

Les développements de ces derniers jours ont un point commun. Un agent IA lit les données plus souvent qu'un humain, avec moins de discernement et pour un coût variable. Tout ce qui n'est pas défini, testé et mis en cache en amont se paie donc à chaque requête, en calcul, en tokens ou en risque d'audit. C'est la logique commune à la vague d'annonces de Fivetran + dbt Labs, au retour d'expérience de dbt Labs sur ses propres transcriptions Gong et aux signaux réglementaires américains relevés cette semaine par O'Reilly.

Ma thèse est la suivante. En 2026, la couche de transformation devient le point de contrôle du CDO sur le coût et la gouvernance de l'IA. Elle doit être décidée, budgétée et auditée séparément de la plateforme de calcul. Les sections qui suivent présentent les éléments à l'appui, en distinguant les faits des promesses commerciales.

Fivetran Context Layer et dbt v2 ramènent le contexte des agents dans l'entrepôt

Les faits datent du 16 septembre, mais leurs suites occupent encore les équipes. À Las Vegas, Fivetran + dbt Labs a annoncé la disponibilité générale de dbt v2 et de dbt State et présenté Fivetran Context Layer, de nouvelles expériences dbt Wizard, dbt Charts et une vision de lakehouse ouvert. Toutes ces informations viennent de l'éditeur lui-même, une entité née du rapprochement de Fivetran (ingestion) et de dbt Labs (transformation). Ce sont des annonces commerciales, à lire comme des promesses.

Sur le moteur, l'éditeur présente dbt v2 comme une réécriture complète en Rust, conçue pour l'échelle actuelle des équipes et pour la façon dont les agents écrivent du SQL. Selon lui, v2 analyse un projet de 10 000 modèles jusqu'à 10 fois plus vite que v1 et signale erreurs, contrôles de colonnes et lignage avant toute exécution. Pour les équipes en production, le changement concret est que l'ère des deux moteurs, Core et Fusion, se termine.

L'annonce la plus stratégique est la Context Layer. D'après dbt Labs, ce service unifie données et métadonnées pour fournir du contexte aux LLM et aux agents, en ajoutant au contexte structuré de dbt des connaissances non structurées comme la documentation et les fils Slack, via Agents Schema, un standard open source qui centralise ce contexte dans l'entrepôt. Le directeur produit, Anjan Kundavaram, résume le pari : selon lui, chaque modèle, chaque test et chaque métrique déjà écrits par les clients « capture déjà le contexte dont les agents IA ont besoin ».

Il faut regarder le tableau de statut publié par l'éditeur. Le Semantic Layer et le serveur MCP sont en disponibilité générale, la Context Layer en bêta privée et dbt Wizard en préversion publique. Les observateurs restent prudents. Un compte rendu indépendant publié sur Substack conclut qu'il est encore tôt et note que tous les exemples présentés au Summit passaient par du SQL direct et contournaient le modèle sémantique de dbt.

Pour un CDO, la portée est la suivante : le contexte que lisent les agents sort des prompts et des outils propriétaires pour devenir des tables SQL versionnées dans votre propre entrepôt. Il n'y a rien à signer sur la Context Layer pour l'instant. Il faut en revanche lire la spécification Agents Schema et vérifier si vos définitions de métriques sont assez propres pour y être exposées.

dbt State réduit-il vraiment la facture de calcul ?

Oui, chez certains clients et dans des proportions variables. Mais le mode de tarification fait que l'économie nette n'est pas garantie. Le mécanisme est simple : dbt State examine les métadonnées de l'entrepôt et le SQL des modèles, détermine si le résultat changerait réellement, puis construit, saute, clone ou diffère automatiquement vers la production. Selon dbt Labs, plus de 22 millions de modèles sont construits chaque jour sur dbt, et le plus souvent les données amont n'ont pas été rafraîchies, si bien que des milliers de modèles se reconstruisent pour produire un résultat identique.

Les chiffres d'économies viennent tous de l'éditeur et de clients qu'il a choisis de citer. Ils doivent être croisés avec vos propres mesures. dbt Labs annonce que les premiers utilisateurs ont économisé en moyenne 15 à 30 % de calcul. Le témoignage le plus mesuré est celui de CarGurus, dont le VP Data, Parag Shah, fait état d'une réduction de 9 % du calcul, de 35 % de modèles construits en moins et d'une baisse de 15 % des coûts Snowflake. Un autre client cité par l'éditeur annonce 59 % d'économies sur les jobs planifiés, soit 8 173,23 dollars sur les 60 premiers jours, sur un entrepôt Snowflake adaptatif. L'éditeur reconnaît lui-même que le gain le plus important vient des configurations ajustées ou du passage à un entrepôt adaptatif sur Snowflake, et non de la simple activation.

Il faut ensuite intégrer la tarification. Chaque réutilisation unique quotidienne d'un modèle, d'un test ou d'un snapshot est facturée (Daily Active Target Tables, ou DATT), à 0,094 dollar par DATT en paiement à l'usage, après un essai gratuit de 30 jours. Un analyste du cabinet Mammoth, qui publie des comparatifs de prix, rappelle en contrepartie qu'un modèle réutilisé ne compte pas comme un modèle construit dans le quota de la plateforme.

Mini-calcul de point mort (hypothétique)

Prenons un projet hypothétique dont 1 000 modèles sont sautés ou clonés chaque jour. Le coût de dbt State est de 1 000 × 0,094 × 30, soit 2 820 dollars par mois. Si la part de la facture d'entrepôt imputable à dbt est de 10 000 dollars par mois, il faut économiser 28,2 % pour atteindre le point mort. Avec la fourchette basse annoncée par l'éditeur (15 %, soit 1 500 dollars), l'opération perd 1 320 dollars par mois. Avec la fourchette haute (30 %), elle en gagne 180. Le résultat bascule si les modèles sautés sont lourds ou si la facture d'entrepôt est plus élevée. La question à se poser est le coût moyen d'un rebuild évité comparé à 0,094 dollar. Le nombre de modèles ne suffit pas à trancher.

C'est un sujet depilotage FinOps des coûts data, à confier au responsable de la facture d'entrepôt et non à la seule équipe d'analytics engineering. La période d'essai de 30 jours est le moment de faire la mesure.

Chez dbt Labs, modéliser les transcriptions Gong a divisé les tokens par 20

Ce cas est le plus instructif de la série, même s'il s'agit d'un retour d'expérience interne de dbt Labs, publié par l'éditeur pour illustrer ses propres produits. Le point de départ est banal. Quand l'usage de Claude s'est étendu en interne, les commerciaux ont interrogé Gong via un connecteur MCP branché sur l'API. Résultat, selon dbt Labs : une seule question sur l'historique d'un client consommait 8 300 tokens par transcription d'appel, soit environ 240 000 tokens de contexte pour un historique d'une trentaine d'appels, avec des plafonds d'appels à l'API atteints très vite.

Le diagnostic est familier à tout CDO. L'analyse de l'usage des connecteurs a montré que Claude allait chercher directement des sources déjà présentes dans l'entrepôt, alors que Fivetran alimentait déjà Snowflake en continu avec les données Gong. L'équipe a donc résumé chaque appel par modélisation dans l'entrepôt. Selon elle, le nettoyage des transcriptions a réduit le volume de données par 20 et fait passer un appel de 60 minutes de dizaines de milliers de tokens à quelques centaines. Servir ces résumés depuis l'entrepôt aurait fait baisser les coûts de tokens d'environ 98 % tout en maintenant ou en améliorant la qualité du contexte.

Un détail mérite l'attention : quand l'équipe avait modélisé Gong pour la BI, le retour sur investissement n'était pas au rendez-vous. L'arrivée des agents a changé le calcul. Une table jugée secondaire pour les tableaux de bord est devenue l'un des actifs les plus consultés de l'entrepôt.

La règle lecture / changement

Le cas Gong et dbt State reposent sur la même règle, assez simple pour tenir sur un tableau blanc :

Quand une donnée est lue ou recalculée plus souvent qu'elle ne change, on la modélise une fois et on sert la version modélisée.

Une transcription Gong ne change plus après l'appel, mais des dizaines de commerciaux la relisent. Un modèle dbt se reconstruit toutes les heures alors que sa source change une fois par jour. Dans les deux cas, le ratio lectures/changements dépasse 1 et chaque lecture brute est une dépense évitable. La règle donne aussi le sens de l'arbitrage. Une source qui change plus vite qu'on ne la lit (un flux de télémétrie consulté une fois par semaine) ne justifie pas un modèle dédié.

La FTC enquête, et la gouvernance de l'IA quitte la revue de fin de projet

C'est le volet non commercial de la semaine. Dans son épisode du 9 octobre, O'Reilly Radar rapporte que l'administration Trump a annoncé un accord volontaire avec les grands acteurs de l'IA prévoyant surveillance interne de la sécurité, audits externes et revues par des conseils indépendants, accord dépourvu de force juridique contraignante. En parallèle, la Federal Trade Commission a ouvert une enquête sur OpenAI, Anthropic et d'autres entreprises d'IA, centrée sur les risques pour les consommateurs. La conclusion d'O'Reilly pour les responsables techniques est directe : les équipes auront besoin de pratiques de gouvernance capables de résister à un examen extérieur.

KDnuggets, le 8 octobre, défend la même idée du point de vue de l'ingénierie : les équipes d'IA ne peuvent plus traiter la gouvernance comme une dernière revue de conformité, et les exigences doivent être prises en compte dès la sélection des données d'entraînement. L'article cite une étude selon laquelle 81 % des Américains estiment que les entreprises utilisent leurs données personnelles d'une manière qui les met mal à l'aise.

dbt Labs (éditeur, donc partie prenante) a publié une tribune qui relie ce sujet à l'architecture. Elle rappelle que, lors du rachat de Neon par Databricks en mai 2025, plus de 80 % des bases de données de la plateforme étaient créées par des agents IA plutôt que par des personnes, selon la télémétrie de Neon. L'argument suivant est intéressé, puisque dbt cherche à se distinguer de Databricks, mais la question qu'il pose est juste : quand un agent écrit votre modèle de chiffre d'affaires, quelqu'un doit encore être propriétaire de la définition. Si la logique vit dans une plateforme propriétaire, retracer une révision de chiffre d'affaires trimestriel demande, selon l'éditeur, un accès à la plateforme Databricks plutôt qu'un git diff.

Pour l'instant, l'enquête de la FTC ne crée aucune obligation nouvelle pour vos équipes data. Il faut suivre ce qu'elle exigera des fournisseurs de modèles en matière de documentation des données, car ces exigences remonteront dans vos contrats d'achat.

Le signal sous-estimé est la sémantique facturée à chaque requête d'agent

Le développement le moins commenté de ces dernières semaines n'apparaît dans aucun communiqué : la définition des métriques est devenue un coût variable. Datacoves, qui commercialise une plateforme dbt gérée concurrente du cloud de dbt Labs, a recensé la semaine dernière ce que facture l'éditeur : les builds de modèles, les requêtes au Semantic Layer, dbt State (0,094 dollar par DATT) et les tokens dbt Wizard aboutissent tous sur la facture à la consommation. Colrows, autre acteur commercial du secteur, chiffre la requête de métrique à environ 0,075 dollar, en plus des sièges, chaque métrique demandée par un outil ou un agent étant comptée. Ces chiffres sont à vérifier sur votre propre contrat.

La conséquence est rarement formulée. Pendant dix ans, unecouche sémantique bien conçue était un investissement fixe : on payait la conception, puis les lectures humaines étaient quasi gratuites. Avec des agents qui interrogent les métriques des centaines de fois par jour, chaque lecture d'une définition gouvernée a un prix. Le cas Gong montre que le chemin modélisé reste bien moins cher que le chemin brut. Mais le CDO doit désormais budgéter le trafic d'agents sur sa couche sémantique comme il budgète le calcul, avec des quotas par cas d'usage et un propriétaire par ligne. Les équipes qui ne le font pas découvriront leur facture de gouvernance après coup, au moment précis où elles voulaient la réduire.

Ce qu'il faut faire lundi

  • Extraire 30 jours de journaux des connecteurs MCP et lister les sources que les agents interrogent en direct alors qu'elles sont déjà chargées dans l'entrepôt. Le cas Gong a commencé exactement par cette analyse.
  • Appliquer la règle lecture/changement aux dix sources les plus interrogées par les agents et en désigner deux à modéliser en priorité.
  • Lancer l'essai gratuit de dbt State sur un seul projet, mesurer le coût moyen d'un rebuild évité et le comparer à 0,094 dollar avant toute extension.
  • Choisir un KPI présenté au comité exécutif et chronométrer le temps nécessaire pour reconstituer l'historique de sa définition. Au-delà d'une heure, c'est votre premier chantier d'auditabilité.
  • Dans la prochaine revue budgétaire, présenter la plateforme de calcul et la couche de transformation comme deux décisions distinctes, avec deux propriétaires.
  • Désigner une personne pour lire la spécification Agents Schema et suivre la bêta privée de Fivetran Context Layer, sans engagement contractuel.

L'annonce la plus solide de dbt Summit est la moins spectaculaire : un rebuild qui ne change pas le résultat est de l'argent perdu, et une lecture brute par un agent aussi. Les CDO qui chiffreront ces deux pertes avant la fin du trimestre pourront négocier leurs contrats d'IA en connaissant leurs coûts.

Pour aller plus loin

Les leçons qui prolongent cet article, en accès libre.

  1. 1dbt (data build tool) : la transformation SQL industrialiséeArchitecture data moderne
  2. 2La couche de métriques et la couche sémantiqueAnalytics, BI & decision intelligence
  3. 3Métadonnées actives et data catalogArchitecture data moderne
  4. 4Data FinOps : maîtriser le coût du cloud dataArchitecture data moderne
  5. 5Shift-left data quality : intégrer la gouvernance dans le pipeline d'ingénierieData governance & compliance

Vous avez lu cet article ?

Validez votre lecture pour gagner de l’XP et alimenter votre radar.