Que devient DBT quand l'IA écrit le code ?

La question qui traverse chaque réunion data en 2026

Dans presque toutes les équipes data que nous voyons chez nos clients, une question identique revient : si demain un agent IA écrit mes modèles DBT à ma place, qu'est-ce qui me reste ? La question est posée sur un ton qui oscille entre inquiétude et curiosité, rarement les deux séparément. Elle traverse les standups du matin, les revues d'architecture, les comités budgétaires. Elle est souvent posée par la bonne personne au mauvais moment — un analytics engineer senior qui doit recruter, un directeur data qui arbitre entre DBT Cloud et une stack maison, un CTO qui doit expliquer à son CEO pourquoi on continue d'investir dans un outil que « l'IA va remplacer ».

Le 17 avril 2026, le podcast AI Engineering Podcast y a consacré un épisode long avec Benoît Perigot, ingénieur dans l'équipe Developer Experience de DBT Labs depuis quatre ans, qui travaille aujourd'hui sur les intégrations IA du produit. Ce n'est pas un analyste externe qui parle de loin — c'est quelqu'un qui écrit chaque jour le code qui fait rencontrer DBT et les agents. Son constat est nuancé, étayé de chiffres, et par endroits contre-intuitif. Cet article en restitue les arguments principaux, dans l'ordre où Benoît les présente : les quatre ans d'apprentissage DBT Labs sur l'IA, les trois leviers techniques qu'ils ont construits, le problème structurel du token design, les trous du benchmark Analytics Engineering, le contexte business comme angle mort, et la position honnête de Benoît sur DBT Core vs DBT Cloud. L'écoute du podcast reste la meilleure source.

Quatre ans d'investissement IA chez DBT Labs

Quand Benoît est arrivé chez DBT Labs il y a quatre ans, l'IA générative n'était pas un sujet de tous les jours. Depuis dix-huit mois, c'est devenu la préoccupation structurante de l'entreprise. En interne, DBT Labs est passé de « on expérimente avec les LLMs » à « toutes les discussions de roadmap se croisent avec l'IA ». L'équipe Developer Experience de Benoît regroupe les sujets qui touchent à comment DBT change avec les agents — et comment les agents changent DBT.

La vision interne de l'entreprise est que la plupart du code DBT, à un horizon court, sera écrit par des agents plutôt que par des humains. Cela ne signifie pas que les humains disparaissent — Benoît insiste sur le contraire — mais cela signifie que tout le produit doit être repensé pour accueillir des agents comme utilisateurs de première classe. DBT Labs consomme d'ailleurs l'IA en interne à large échelle sur ses propres projets, dont son plus gros projet DBT interne qui compte plusieurs milliers de modèles. C'est ce projet qui sert de terrain d'essai pour ce qui ne remonte jamais dans les benchmarks publics.

De cette auto-observation sont nés les trois leviers techniques sur lesquels DBT Labs investit aujourd'hui : les skills (instructions de raisonnement pour l'agent), le MCP server (exposition des outils DBT à l'agent), et le tout nouveau DBT Index (contexte massif livré à l'agent avec un budget token minimal). Les trois ne sont pas en concurrence — ils adressent des couches différentes du problème.

Trois leviers pour que les agents écrivent du DBT

Premier levier : les skills. Les modèles frontières — GPT-5.4, Claude Opus, Gemini — connaissent DBT. Ils savent écrire du SQL, ils savent le syntaxer en modèle, ils savent déclarer des sources. Ce qu'ils savent beaucoup moins, c'est le processus. L'ordre dans lequel on pense avant de coder. Quelles commandes lancer et dans quelle séquence. Comment décider s'il faut créer un nouveau modèle ou enrichir un existant. Les skills que DBT Labs a publiées codifient ce processus. Elles ne remplacent pas le modèle ; elles lui expliquent comment raisonner. Faire un dbt run ou un dbt build, le LLM sait le faire tout seul. Décider que telle source doit devenir un modèle intermédiaire avant d'alimenter une table finale, il ne sait pas — les skills le lui disent.

Deuxième levier : le MCP server. L'idée est de donner à l'agent tous les outils DBT (inspecter les modèles, lancer des tests, explorer le lineage) via le protocole Harness Engineering standard. Mais l'enjeu n'est pas d'ouvrir l'accès — c'est de l'ouvrir avec le moins de tokens possible. Sur un projet DBT jouet (le Jaffle Shop avec ses dix modèles), n'importe quel MCP serveur fonctionne. Sur le projet interne DBT Labs à plusieurs milliers de modèles, un MCP mal conçu explose la fenêtre de contexte au premier appel. C'est ce problème qui a justifié la construction du troisième levier.

Troisième levier : DBT Index. Benoît présente ce composant comme un nouveau skylight conçu spécifiquement pour les agents. Les humains pourront l'utiliser aussi, mais sa raison d'être est que l'agent puisse obtenir du contexte rapidement, sans brûler de tokens, sans s'enfermer dans des boucles de tool calling. C'est une grosse optimisation côté budget contextuel, pour que l'agent ait toutes les données dont il a besoin sans faire dix tours d'appels intermédiaires. L'outil n'est pas encore publiquement release à la date du podcast, mais arrive bientôt.

Le problème du token, ou pourquoi un MCP naïf tue un projet

Sur ce point, le podcast s'attarde et Benoît donne les chiffres. Le diagnostic de départ est simple : si votre MCP serveur consomme trop de tokens, c'est qu'il est mal designé. Ce n'est pas la faute de l'agent, ni du modèle, ni du protocole. C'est la faute de celui qui a exposé les outils.

Benoît le formule sans ambiguïté dans le podcast : « Le design du MCP serveur ne doit pas être juste un wrap sur ton API. Ça doit être un truc vraiment malin. » Traduction concrète : si vous avez un outil get_models qui retourne la liste complète des 2 000 modèles d'un projet, vous pourrissez la fenêtre de contexte au premier appel. Le bon design consiste à paginer (get_models_paginated), à offrir une recherche (get_models_with_search_pattern), à filtrer par critère (get_models_in_schema). Le retour du tool ne doit pas être un JSON brut — c'est inefficient côté tokens. Il doit être du Markdown pré-formaté avec juste l'information pertinente, ou du CSV. Une mesure que Benoît cite : sur un tool qui retourne la liste des métriques du semantic layer, passer de JSON à CSV a divisé les tokens par environ 70% pour la même information.

La contre-mesure s'étend à l'orchestration des tools entre eux. Au lieu de faire cinq appels de tool successifs depuis l'agent (avec cinq round-trips LLM et cinq fois la charge du contexte), on regroupe ces cinq appels dans le serveur MCP et on n'expose qu'un seul tool. Moins de décisions à prendre pour le LLM, moins de tokens dépensés en raisonnement intermédiaire. Cette philosophie rejoint le pattern code mode que Cloudflare a popularisé au printemps 2026 pour son propre MCP (2 600 endpoints réduits à deux tools search et execute) — même intuition, même résultat.

Le talk de Sunil Pie (CTO Cloudflare) à AI Engineer Europe, cité par l'hôte du podcast, quantifie le problème côté Cloudflare : exposer brut les 2 600 endpoints de Cloudflare en MCP coûte environ un million de tokens. Autrement dit, votre agent dépense toute sa fenêtre avant même d'avoir commencé à travailler. C'est le même phénomène à l'échelle DBT : un projet à 2 000 modèles produit un MCP serveur naïf qui ne rentre pas dans la fenêtre de Claude Opus ou de GPT-5.4. Le redesign est la seule issue.

Le benchmark Analytics Engineering et ses trous

Pour mesurer l'efficacité de tout ce travail, DBT Labs a co-créé — avec Ben Stensil — un benchmark public appelé Analytics Engineering Benchmark (anciennement Data and Analytics Engineering Benchmark). Il consiste en un ensemble de tâches réalistes : « il y a un problème dans cette requête SQL, débugue-la et corrige le modèle », « crée ce modèle avec ces contraintes », « explore ce lineage et explique-moi ». Le benchmark est aujourd'hui adopté par plusieurs acteurs : Cortex Code, Ultimate Code, et d'autres harnais data utilisent ce référentiel pour se mesurer.

Mais Benoît est lucide sur ses limites. Le benchmark a deux trous que les équipes qui le maintiennent essaient de combler. Premier trou : il ne contient pas de projet open source à plusieurs milliers de modèles. Il a des projets à plusieurs centaines de modèles, mais aucun projet public à 2 000 ou 5 000 modèles. Benoît note la tentation d'utiliser le projet interne DBT Labs (parfait candidat, à la bonne échelle), mais la confidentialité commerciale l'interdit. Il mentionne le projet GitLab qui est open source, mais sans les données de production — il faudrait générer des fake data en entrée. Aujourd'hui, il n'existe pas de projet DBT open source à 1 500 modèles avec ses données connectées. C'est un manque industriel qui limite la capacité à benchmarker les harnais sur des projets réels.

Deuxième trou : le risque de leak dans les training pools. Un benchmark publié devient accessible aux laboratoires qui entraînent les modèles. Rien n'empêche en théorie qu'Anthropic ou OpenAI incluent les questions et les solutions dans leur corpus d'entraînement, améliorant artificiellement le score de leur prochain modèle. L'équipe discute de garder certaines questions privées pour disposer d'un lot de contrôle invisible aux labos. C'est une précaution défensive qui rappelle que tous les benchmarks publics ont une durée de validité finie.

Au-delà, Benoît pose la vraie question : pour un utilisateur qui adopte un harnais data spécifique, la performance qui compte n'est pas la victoire sur un benchmark générique — c'est l'incrément entre les versions successives d'un même modèle, dans son contexte à lui. Comparer GPT-5.3 à GPT-5.4 a du sens. Comparer ClaudeCode à Cortex Code sur SoftwareBench en dit peu sur ce qui se passera quand l'un ou l'autre entrera dans son propre projet de 2 000 modèles. Le benchmark reste un indicateur marketing, utile mais biaisé — à lire avec des pincettes.

Le contexte business, l'angle mort irréductible

Ce qui manque le plus aux agents aujourd'hui, ce n'est pas la capacité à écrire du DBT correct. Les modèles frontières savent. Ce qui manque, c'est le contexte business : quelle table utiliser pour quelle question, quel champ a changé de sémantique il y a six mois, quelle règle métier n'est documentée nulle part parce qu'elle vit dans la tête d'un data analyst senior. Benoît insiste : « Il y aura toujours un intérêt à avoir des human in the loop » pour cette raison précise.

L'anecdote qu'il raconte est éclairante. La veille du podcast, Benoît crée des modèles DBT qui utilisent les fonctions AI natives de Snowflake (AI_CLASSIFY). Il laisse l'agent itérer et générer du code. Au bout d'un moment, il se rend compte que l'agent fait des AI_CLASSIFY en boucle, consommant des crédits Snowflake Cortex à chaque appel. L'agent n'avait pas la connaissance que ces appels coûtaient de l'argent réel — aucune alerte, aucun garde-fou, juste le modèle qui fait son travail nominal. Benoît l'arrête manuellement avant que la facture devienne sérieuse. L'humain, ici, apporte ce que le modèle n'a pas : la conscience du coût opérationnel de chaque décision.

Cette dépendance au contexte business pose la question subsidiaire : où documente-t-on ce contexte pour que l'agent puisse y accéder ? Dans DBT lui-même (les descriptions de modèles, les tests, les macros) ? Dans Notion avec des pages qui dérivent depuis trois ans et plus personne ne met à jour ? Dans un semantic layer dédié ? Benoît reconnaît qu'aucune solution parfaite n'a émergé. Plusieurs boîtes travaillent sur des agents d'agentic analytics qui essaient de combiner projet DBT et documentation d'entreprise, mais aucune ne gagne encore clairement sur ce terrain. C'est un problème ouvert, et probablement le plus important des années à venir — il rejoint directement la thèse de Tony Seale sur l'Agent Sémantique, où l'ontologie de l'entreprise devient le seul vrai actif non-commodity.

DBT survit, DBT Cloud doit se réinventer

Benoît est invité à se prononcer sur la question existentielle : DBT en tant que framework va-t-il disparaître si les agents écrivent tout le SQL ? Sa réponse est nuancée et s'appuie sur une analogie empruntée au CEO de DBT Labs, qui avait partagé un post de Slack sur le sujet. L'analogie est Ruby on Rails. Un framework ancien, plus vieux que DBT, dont beaucoup prédisaient la mort il y a cinq ans. Et pourtant, selon l'interview récente de DHH qu'il cite, Rails est en petit revival : les agents adorent travailler avec les frameworks bien établis. Pourquoi ? Parce qu'ils sont dans le corpus d'entraînement — les modèles les connaissent — et parce qu'ils sont token-efficients. Demander à un agent de réimplémenter une logique d'orchestration from scratch coûte beaucoup plus de tokens que de lui dire « lance un dbt run ». Le framework encapsule des décisions que le modèle n'a pas besoin de reprendre.

Pour DBT, la logique est identique. Un agent qui construit un projet DBT fait quelques SELECT, un dbt build, et laisse le framework gérer l'ordre d'exécution, les dépendances, les tests, la matérialisation. L'agent n'a pas besoin de penser à l'orchestration ; DBT le fait pour lui. Cette efficacité structurelle explique pourquoi, à court et moyen terme, les agents vont continuer à utiliser DBT. Benoît va plus loin : dans les mois qui viennent, il pense que des agents pourront construire des projets DBT entièrement from scratch — on leur donnera du CSV ou du JSON, et ils produiront un mini-projet de dix modèles fonctionnels, sans qu'un humain ait besoin de regarder le code.

Mais cette projection ouvre la question suivante : si l'agent écrit, teste, maintient le projet, qu'est-ce qui justifie d'acheter DBT Cloud plutôt que de faire tourner DBT Core en auto-hébergement ? La question est posée frontalement dans le podcast, et Benoît y répond sans esquiver. Pour les petites équipes, la partie commerciale de DBT Labs perd de la valeur relative : un agent peut maintenir une stack DBT simple, tourner les jobs, alerter en cas d'échec. Mais pour les grandes entreprises, DBT Cloud reste justifié par ses enterprise features — SLA commerciaux, support structuré, gestion multi-projet, gouvernance — que les agents ne remplacent pas. Et paradoxalement, il est possible que DBT Cloud prenne plus d'importance dans le monde agentique : quand les agents produisent dix fois plus de modèles qu'avant, la plateforme qui organise ce volume devient plus nécessaire, pas moins. C'est la tension que Benoît décrit sans la trancher.

Perspective SFEIR

Cette conversation résonne avec ce que nous observons sur nos projets data grands comptes. Les équipes analytics engineering qui ont adopté DBT il y a trois à cinq ans sont aujourd'hui en train de redéfinir leur rapport à l'outil, pas d'en sortir. Les chantiers qui émergent sont trois : la stack AI-Ready autour du projet DBT (typage fort, conventions, tests), l'instrumentation de leur contexte métier pour que les agents puissent y accéder sans inventer, et la formation des analytics engineers à un métier qui glisse vers l'architecture de contexte et l'arbitrage. La question « faut-il continuer à apprendre DBT » est dépassée ; elle est remplacée par « comment structurer notre domaine data pour que nos agents soient efficaces dessus ».

Le pont avec l'article Agent Sémantique publié le même jour est direct : un projet DBT mature est, en pratique, une ontologie exécutable sur les données. Les modèles, les sources, les tests, les macros forment le graphe typé dans lequel les agents naviguent. C'est ce que Tony Seale appelle la moitié non-commodity de l'équation. Le harness engineering côté code et l'ontologie DBT côté données se rejoignent dans une architecture cohérente — celle de l'agent sémantique data.

Conclusion

Que devient DBT quand l'IA écrit le code ? D'après Benoît Perigot, DBT devient plus important, pas moins. Les agents connaissent le framework, l'utilisent de manière token-efficiente, et s'appuient sur lui pour ne pas réinventer l'orchestration. Mais la valeur de l'écosystème se déplace. Du code écrit vers la qualité du harness qui entoure les agents. Du savoir syntaxique vers la capacité à structurer le contexte business. De l'artisanat SQL vers l'arbitrage architectural. Les analytics engineers ne disparaissent pas ; leur métier mute. Et ce qui fait la différence entre une équipe qui tire parti de cette mutation et une équipe qui la subit, c'est la rigueur avec laquelle elle pense ses skills, son MCP serveur, et son ontologie métier. Exactement ce que DBT Labs fait en interne depuis quatre ans.

Source : cet article est une restitution fidèle de l'épisode « Que devient dbt quand l'IA écrit le code ? (and news) » du podcast AI Engineering Podcast, diffusé le 17 avril 2026. Interlocuteur : Benoît Perigot, Developer Experience, DBT Labs. Citation Anthropic sur le harness et chiffre Cloudflare 2600 endpoints tous rapportés par les intervenants du podcast. Épisode complet sur YouTube.