DataCette semaine en dataSoftware & SaaS

Fivetran et dbt Labs ont redessiné l'infrastructure data pour les agents : est-ce que votre pile est prête ?

Au dbt Summit 2026, Fivetran et dbt Labs ont annoncé un ensemble de capacités dont l'objectif déclaré est de rendre les données d'entreprise consommables par des agents IA, et non plus seulement par des humains. Ce débrief examine ce qui a réellement été annoncé, ce que cela implique pour un CDO, et le signal que la plupart des équipes sont en train de rater.

Le fil conducteur de cette semaine est simple : plusieurs annonces distinctes, venues du même sommet, pointent toutes dans la même direction. L'infrastructure data a été conçue pour des humains qui posent des questions via des interfaces. Les agents IA, eux, consomment des données de façon programmatique, en continu, sans passer par un tableau de bord. Ce décalage structurel est devenu le problème central que les vendeurs de données tentent maintenant de résoudre, et dbt Summit 2026 a été l'occasion pour Fivetran et dbt Labs de présenter leur réponse.

dbt v2 et dbt State en disponibilité générale : quels gains de coûts

Selon dbt Labs (éditeur de l'outil de transformation SQL du même nom, chiffres et positionnement à lire comme des affirmations commerciales), dbt v2 est désormais en disponibilité générale, accompagné de dbt State. Ce dernier mérite qu'on s'y arrête : dbt State évite de reconstruire les modèles qui n'ont pas changé depuis la dernière exécution. L'équipe de Fanatics, selon dbt Labs, aurait réduit ses coûts de calcul en warehouse en appliquant ce mécanisme d'exécution différentielle.

Pour un CDO, l'intérêt n'est pas uniquement le coût. Avec des agents qui interrogent les données en continu plutôt qu'à la demande d'un analyste, la fréquence d'exécution des pipelines de transformation augmente mécaniquement. Un système qui recalcule tout à chaque run devient rapidement intenable, financièrement et opérationnellement. dbt State répond à ce problème précis, même si la portée réelle dépendra de la complexité du graphe de dépendances propre à chaque organisation.

Ce qu'un CDO devrait faire : si vous utilisez dbt Core ou dbt Cloud, planifier la migration vers v2 et tester dbt State sur un projet à fort volume. C'est un levier de réduction des coûts vérifiable, indépendamment de tout contexte agents.

Que doit savoir un agent IA de vos données avec le Fivetran Context Layer ?

L'annonce la plus structurante du sommet, toujours selon dbt Labs et Fivetran (deux vendeurs avec un intérêt commercial direct à positionner leur offre comme indispensable aux projets agents), est le Fivetran Context Layer. L'idée : fournir aux agents IA un accès structuré à des métadonnées sur les données, pas seulement aux données elles-mêmes. Provenance, fraîcheur, définitions, règles de qualité, ces informations constituent ce qu'un analyste humain porte dans sa mémoire. Un agent, lui, en est dépourvu sans un mécanisme explicite pour les lui transmettre.

C'est exactement le problème que soulève The New Stack dans un article de cette semaine : les agents IA ont besoin d'une "frontière de contexte sûre", un périmètre qui définit ce qu'un agent peut consommer sans exposer des secrets, des données sensibles ou des définitions contradictoires. Sans cette couche, un agent qui requête un warehouse peut obtenir une réponse techniquement correcte mais sémantiquement fausse parce qu'il a utilisé la mauvaise définition du "revenu" ou la mauvaise granularité géographique.

C'est ici quela gestion des métadonnées actives devient opérationnelle plutôt que théorique. Un catalogue de données bien alimenté cesse d'être un outil de gouvernance documentaire pour devenir l'interface que les agents traversent avant d'accéder à vos tables.

Ce qu'un CDO devrait faire : auditer l'état de vos métadonnées sémantiques aujourd'hui. Si vos définitions de métriques ne sont pas formalisées et accessibles programmatiquement, le Context Layer n'aura rien d'utile à exposer. L'outil est inutile sans le travail de fond.

dbt Charts et l'open lakehouse : une direction produit, pas un produit

dbt Labs annonce également dbt Charts et ce qu'il appelle une "vision open lakehouse". dbt Charts permet de produire des visualisations directement depuis les modèles dbt, sans exporter vers un outil tiers. La vision open lakehouse, elle, articule une architecture où la couche de transformation dbt sert de pont entre les plateformes de stockage et les consommateurs de données, humains ou agents.

Il faut lire ces annonces pour ce qu'elles sont : une direction produit, avec un positionnement compétitif évident face à Databricks, Snowflake et leurs propres couches sémantiques. dbt Labs reconnaît d'ailleurs explicitement, dans un autre contenu publié cette semaine, que "votre plateforme de calcul et votre logique de transformation sont deux décisions séparées" et que la plupart des directions les approuvent ensemble, ce qui crée des dépendances inutiles. L'argument est cohérent, même si la conclusion pousse à adopter davantage de produits dbt.

Pour un CDO, dbt Charts mérite un regard pragmatique : si vos analystes passent du temps à exporter des résultats dbt vers des outils de visualisation pour des vérifications intermédiaires, consolider ces étapes a du sens. Mais remplacer votre couche de visualisation existante sur la base d'une annonce de sommet serait prématuré.

Modéliser les données pour les tokens des LLM, pas pour les tables

Un article publié par dbt Labs cette semaine décrit comment l'équipe data de Gong a remodélisé ses transcriptions d'appels dans le warehouse avec dbt, réduisant les coûts de consommation API pour les LLM d'un facteur 20. Le chiffre vient du vendeur et doit être traité comme tel, mais le principe sous-jacent mérite qu'on s'y attarde.

Jusqu'ici, la modélisation data optimisait pour les jointures, les agrégations et la lisibilité humaine. Avec des agents et des LLM comme consommateurs, le critère d'optimisation change : il faut réduire le nombre de tokens envoyés au modèle tout en préservant la densité sémantique. Ce n'est pas la même chose. Une table bien normalisée pour un analyste peut être coûteuse et bruitée pour un LLM.

C'est le signal que la plupart des équipes data sous-estiment cette semaine.Concevoir des data products orientés agents nécessitera probablement de définir de nouveaux contrats de sortie, avec des critères de format, de densité et de fraîcheur que les pratiques actuelles ne formalisent pas.

Pourquoi votre pile data reste calibrée pour des requêtes humaines ?

L'ensemble des annonces de dbt Summit 2026 suppose que l'infrastructure data existante des entreprises est structurée pour répondre à des requêtes humaines ponctuelles. Cette hypothèse est correcte pour la quasi-totalité des organisations. Ce que les annonces

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. 2Métadonnées actives et data catalogArchitecture data moderne
  3. 3La couche de métriques et la couche sémantiqueAnalytics, BI & decision intelligence
  4. 4Data lineage & metadata management : savoir où vos données sont néesData governance & compliance
  5. 5Data products : définition, design et gestion du cycle de vieArchitecture data moderne

Vous avez lu cet article ?

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