Pipelines de données orchestrés par agents : construire la pile Dagster + dbt + MCP

Points clés

• Fivetran et dbt Labs ont finalisé leur fusion le 1er juin 2026 (ARR combiné d'environ $600M, plus de 100 000 équipes data) et lancé Agents Schema — une norme ouverte qui transforme un schéma d'entrepôt en couche de contexte partagé et gouverné pour les agents.
• Databricks rapporte que plus de 80% des bases de données de son unité Neon sont provisionnées par des agents IA, et non par des humains — le principal consommateur de la pile de données est déjà passé de l'analyste à l'agent.
• Trois schémas agentiques définissent le nouveau pipeline — les agents écrivent et échafaudent le code du pipeline, les pipelines s'auto-réparent en proposant et en appliquant des correctifs, et les agents trient les échecs d'exécution en chat — chacun nécessitant une lignée lisible par machine, et non un tableau de bord affiché.
• La pile comporte trois couches gouvernées — Dagster pour la lignée des actifs, dbt pour les transformations testées et le contexte partagé, et un module MCP pour un accès à périmètre défini par politique — de sorte qu'un agent lit la structure du pipeline sous les mêmes contrôles qu'un humain.

La pile de données a été conçue pour des analystes humains : exécuter le pipeline la nuit, lire un tableau de bord le matin, ouvrir un ticket quand un chiffre paraît faux. Les agents IA consomment les données différemment. Comme l'a formulé la fusion Fivetran + dbt Labs dans ces termes, les agents « opèrent en continu, en parallèle, et à la vitesse de la machine » — et ils ont besoin de la structure du pipeline (lignée, tests, définitions), pas seulement de sa sortie. En un seul trimestre, les plus grands fournisseurs de déplacement et de transformation de données se sont reconstruits autour de ce constat : la fusion Fivetran + dbt a lancé Agents Schema et ouvert le code du moteur dbt Fusion sous le nom dbt Core v2.0, et Databricks a racheté Electric pour donner à chaque agent son propre Postgres jetable.

Ce guide construit ce schéma dans un contexte d'approvisionnement B2B : un pipeline qui ingère des catalogues fournisseurs, des prix et des stocks, et les expose à un agent RFQ. Il couvre les trois couches — Dagster pour l'orchestration centrée sur les actifs, dbt pour la transformation gouvernée, et un module MCP pour un accès agent à périmètre défini — ainsi que les trois schémas agentiques qui permettent au pipeline de s'entretenir lui-même. Vous saurez à la fin ce qu'apporte chaque couche, pourquoi la lignée des actifs est le choix porteur, et où l'humain reste dans la boucle.

Pourquoi l'orchestration centrée sur les actifs est le fondement

La plupart des échecs d'orchestration pour les agents commencent par un mauvais modèle mental. Les ordonnanceurs centrés sur les tâches (la conception classique cron-plus-DAG) répondent à « ce job s'est-il exécuté ? ». Un agent qui demande « pourquoi le prix d'Acme est-il obsolète ? » a besoin d'une réponse différente : « quel actif de données est périmé, de quoi dépend-il, et qu'est-ce qui l'alimente ? » C'est une question d'actif, et c'est pourquoi le modèle centré sur les actifs de Dagster est ici le fondement plutôt qu'une préférence.

Dans Dagster, on déclare la chose que l'on produit — supplier_catalog, normalized_prices, availability_snapshot — et ses dépendances. L'orchestrateur connaît alors le graphe de lignée complet. La Declarative Automation de Dagster permet à un actif de se rafraîchir quand son amont change plutôt que sur une horloge fixe, si bien que « périmé » devient une propriété que le système peut raisonner. Ce graphe de lignée est exactement ce dont un agent a besoin pour remonter un chiffre erroné jusqu'à sa source sans deviner.

import dagster as dg

@dg.asset(group_name="procurement")
def supplier_catalog(context: dg.AssetExecutionContext) -> dg.MaterializeResult:
    rows = fetch_supplier_feed()  # NetSuite, EDI, CSV drop, etc.
    write_bronze("supplier_catalog", rows)
    return dg.MaterializeResult(metadata={"row_count": len(rows)})

@dg.asset(deps=[supplier_catalog], group_name="procurement",
          automation_condition=dg.AutomationCondition.eager())
def normalized_prices() -> None:
    # dbt owns the transformation logic; Dagster owns the lineage + trigger
    run_dbt(select="normalized_prices")

deps et automation_condition sont tout l'enjeu : l'agent (et la boucle d'auto-réparation ci-dessous) peut lire ce graphe comme une donnée. Airflow est arrivé à la même conclusion depuis l'autre direction — Airflow 3.2 a ajouté un Common AI Provider et une planification consciente des actifs — et la consolidation est bien réelle : Prefect a racheté Dagster en juillet 2026. Quel que soit l'orchestrateur retenu, l'exigence reste la même : des actifs à lignée déclarée, pas des tâches opaques.

Pourquoi dbt possède la transformation et le contexte gouverné

Dagster déclenche le travail et suit la lignée ; il ne doit pas contenir votre logique métier. Celle-ci appartient à dbt, où chaque transformation est un modèle SQL versionné, avec tests, documentation et définition sémantique attachés. Pour les agents, ce n'est pas un confort, c'est la frontière de confiance. La position de dbt lui-même est que la couche de transformation est ce qui rend les pipelines agentiques dignes de confiance : un agent qui écrit du SQL contre des tables non définies et non testées automatise le chaos plus vite.

L'ajout le plus important post-fusion est Agents Schema : un schéma d'entrepôt dédié qui stocke les définitions de métriques, les modèles sémantiques, la lignée dbt et la documentation métier sous forme de tables SQL ordinaires. Plutôt que chaque agent redérive ce que signifie « disponibilité en stock », la définition vit à un seul endroit gouverné et détenu par le client, que l'agent consulte. C'est le pendant côté données d'un module connecteur gouverné — une source unique et à périmètre défini de contexte partagé, plutôt qu'une copie par agent qui dérive.

-- models/marts/availability_snapshot.sql
select
    sku,
    warehouse_id,
    on_hand - allocated as available_qty,   -- the governed definition
    updated_at
from {{ ref('normalized_inventory') }}

-- schema.yml: the test that gates the agent's trust
-- - name: available_qty
--   tests: [not_null, {dbt_utils.accepted_range: {min_value: 0}}]

Un test qui échoue est un signal que l'agent ne doit pas citer cette ligne. Ce seul fait — un pass/fail lisible par machine sur chaque modèle — est ce qui permet aux deux prochains schémas de fonctionner sans qu'un humain surveille chaque étape.

Où l'agent se connecte : un module MCP, pas un identifiant de base de données

Un agent ne devrait jamais détenir d'identifiants bruts de l'entrepôt. Il devrait appeler un module MCP gouverné qui expose un petit ensemble d'outils typés — get_availability(sku, warehouse), get_tier_price(sku, customer_tier), list_substitutes(sku) — chacun mappé à un modèle dbt testé et portant un périmètre de politique, des limites de débit et une journalisation d'audit. C'est le même modèle de module utilisé pour les connecteurs ERP et commerce, appliqué à la sortie propre du pipeline. Cela maintient un petit rayon d'impact : l'agent peut lire availability_snapshot mais ne peut pas exécuter du SQL arbitraire, et chaque appel est journalisé.

Cette frontière est aussi là où l'état par agent trouve sa place. Le rachat d'Electric par Databricks — un Postgres WASM (PGlite) à l'intérieur du bac à sable de l'agent, synchronisé avec l'état central gouverné — existe parce que les agents « ont besoin de milliers de petites bases de données jetables » pour leur contexte de travail, tenues séparées des tables durables et gouvernées. La règle de base : les données durables, partagées et gouvernées vivent derrière le module MCP ; le contexte de travail éphémère, propre à chaque exécution, vit dans le bac à sable de l'agent lui-même.

Les trois schémas agentiques que cette pile rend possibles

Avec la lignée (Dagster), des définitions testées et un contexte partagé (dbt + Agents Schema), et un accès à périmètre défini (MCP) en place, trois schémas deviennent praticables :

• Développement agentique. Les agents échafaudent de nouveaux actifs et transformations — rédiger le modèle dbt, proposer le test de schéma, câbler l'actif Dagster — contre le graphe de lignée existant. Dagster propose dagster-io/skills pour Claude Code et Codex et un assistant Slack Compass ; Bruin expose un serveur MCP dans le même but. L'humain relit une pull request, pas un fichier vide.
• Pipelines auto-réparateurs. Quand un test de schéma échoue ou qu'un actif amont casse, l'agent lit la lignée, isole le modèle défaillant, propose un correctif et l'applique en canari ou dépose une PR. Comme Dagster connaît le graphe de dépendances et dbt sait quel test a échoué, le correctif est conscient de la lignée plutôt qu'une simple reprise à l'aveugle.
• Dépannage agentique. En cas d'échec, l'agent lit les journaux d'exécution et les métadonnées et répond dans Slack ou Teams avec la cause probable et un correctif proposé — le schéma sur lequel sont bâtis Dagster Compass et Snowflake Cortex. Le débogage d'astreinte passe de la lecture de tableaux de bord à la relecture du diagnostic d'un agent.

Aucun de ces schémas ne supprime l'humain. Chaque changement appliqué passe par un verrou de test, un canari ou une revue — la même discipline que les keynotes du dbt Summit 2026 ont présentée comme le prix à payer pour laisser des agents toucher aux données de production.

La pile, en un coup d'œil

Un exemple de construction concret

Un distributeur exploitant NetSuite, deux entrepôts et trois catalogues fournisseurs voulait un agent RFQ capable de coter sans qu'un humain n'aille chercher la disponibilité à la main. Le pipeline était le blocage, pas le modèle. Nous avons déclaré les actifs de catalogue, de prix et de stock dans Dagster avec une lignée explicite ; déplacé la logique de tarification et de disponibilité dans des modèles dbt testés avec un Agents Schema qui fixait la définition de « disponible à la promesse » ; et exposé trois outils typés via un module MCP à périmètre lecture seule. La boucle d'auto-réparation détecte désormais un flux fournisseur cassé et dépose une PR avec le correctif avant l'exécution des devis du matin ; le temps d'astreinte sur les pannes de pipeline a diminué car la première réponse de l'agent est un diagnostic, pas une alerte. L'agent cote sur des données testées ou refuse — il ne cote jamais sur une ligne qui a échoué à son test.

Lecture connexe

• Pannes de pipeline en cascade : comment un agent réduit le débogage d'astreinte de 75 % — les schémas d'auto-réparation et de dépannage agentique comme cas d'usage opérationnel, avec les chiffres d'astreinte
• Norme de code du module MCP — le schéma structurel derrière le module MCP gouverné et à périmètre défini qui se place devant le pipeline
• Observabilité des agents IA : ce que vous ne voyez pas vous nuira — pourquoi les journaux d'exécution et les métadonnées de lignée sont le substrat dont dépend le dépannage agentique

Construire un pipeline orchestré par agents sur votre propre pile — NetSuite, un entrepôt, des flux fournisseurs — commence par savoir quels actifs existent et où vivent les définitions.

Demandez une construction délimitée. Découverte d'une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.