L'IA agentique et son adéquation avec le travail data

Le rapport 2025 State of Analytics Engineering de dbt Labs a révélé que 70 % des professionnels de l’analytics utilisent l’IA pour le développement de code. La plupart utilisent des outils généralistes (ChatGPT, Copilot) qui ne voient pas la codebase, ne connaissent pas les conventions du projet et nécessitent du copier-coller constant. Les propriétés structurelles du travail data — répétition, changements de contexte, débogage cross-layer — en font un terrain particulièrement favorable à l’approche agentique, où un outil lit le projet, en comprend les patterns et agit en conséquence.

L’argument de la répétition

Le travail data est riche en patterns. Les modèles de base suivent des structures prévisibles : sélection depuis la source, déduplication, renommage, cast, filtrage. Seuls les détails changent — différentes tables sources, différents noms de colonnes, différentes clés de déduplication. Il en va de même sur l’ensemble de l’architecture trois couches : les modèles intermédiaires joignent et enrichissent selon des patterns cohérents, les marts agrègent à des granularités spécifiques.

Ce type de travail est particulièrement adapté aux agents parce que le pattern est bien établi et que la variation porte sur les détails. Vous n’avez pas besoin d’expliquer comment écrire un modèle de base à chaque fois. Vous devez simplement dire « crée un modèle de base pour raw_shopify.orders en suivant mes patterns de modèles de base existants ». Un agent qui peut lire vos modèles existants, détecter le pattern et l’appliquer à de nouvelles tables sources fait en quelques secondes ce qui prend à un humain dix minutes de copier-coller-adapter.

Voici un exemple simplifié. Supposons que vous ayez un modèle de base existant :

{{ config(materialized='table', tags=['base', 'stripe']) }}

WITH source AS (
    SELECT * FROM {{ source('stripe', 'payments') }}
),

deduplicated AS (
    SELECT *
    FROM source
    QUALIFY ROW_NUMBER() OVER (
        PARTITION BY id ORDER BY _loaded_at DESC
    ) = 1
),

renamed AS (
    SELECT
        id AS payment__id,
        customer_id AS customer__id,
        amount AS payment__amount_cents,
        CAST(created_at AS TIMESTAMP) AS payment__created_at,
        status AS payment__status
    FROM deduplicated
)

SELECT * FROM renamed

Un agent lit ceci, assimile la convention de nommage (entity__field), la structure des CTE (source → deduplicated → renamed), la stratégie de matérialisation et le pattern de déduplication. Quand vous demandez un nouveau modèle de base pour raw_shopify.orders, il ne génère pas quelque chose de générique. Il génère quelque chose qui ressemble à ce qui appartient à votre projet.

Un chatbot peut faire cela aussi, mais vous devriez coller l’exemple, décrire la convention, spécifier la structure. Avec un agent, le budget d’instruction est nul parce que l’agent lit le projet lui-même.

L’argument des changements de contexte

Un seul modèle dbt implique du SQL, du templating Jinja, de la configuration YAML et parfois du Python. Une tâche typique — disons, construire un modèle intermédiaire — peut nécessiter :

1. Écrire du SQL avec des CTE et des fonctions fenêtre
2. Utiliser les macros Jinja {{ ref() }} et {{ source() }}
3. Configurer la matérialisation et les tags dans un bloc {{ config() }}
4. Définir des tests et des descriptions de colonnes dans un fichier de schéma YAML
5. Éventuellement appeler une macro personnalisée utilisant du control flow Jinja

Chacun de ces éléments est un « langage » différent avec des règles de syntaxe différentes. Dans un workflow traditionnel, vous basculez constamment entre eux — écriture du SQL, onglet vers le fichier YAML, vérification de la référence de macro, retour au SQL. Le coût mental n’est dans aucun langage individuel ; il est dans le changement constant.

Un agent qui comprend tous ces éléments ensemble — pas comme des extraits isolés mais comme des parties d’un seul projet — supprime le coût de changement. Vous décrivez ce que vous voulez en langage naturel. L’agent génère le SQL, le YAML et le bloc de config en une seule passe, tous cohérents entre eux et avec les patterns existants de votre projet. La nature multi-langages du travail dbt qui le rend fastidieux pour les humains est exactement ce qui le rend productif pour les agents.

L’argument du débogage cross-layer

Quand un modèle mart échoue, le problème peut se trouver n’importe où dans la chaîne de lignage. Un chiffre incorrect dans mrt__sales__daily_revenue pourrait remonter à :

• Un changement de schéma dans la table source que le modèle de base n’a pas géré
• Un type cast dans le modèle de base qui convertit silencieusement les NULL
• Une jointure dans le modèle intermédiaire qui change la granularité
• Un filtre dans le mart qui exclut des enregistrements qu’il ne devrait pas
• Une macro récemment mise à jour avec un changement de logique subtil

Dans l’ancien workflow, vous traceriez cela manuellement : ouvrir le mart, lire le SQL, suivre les appels ref() en amont, interroger chaque table intermédiaire, comparer les comptages de lignes, vérifier la source. C’est lent parce que chaque étape vous demande de garder le contexte complet en tête tout en naviguant entre les fichiers.

Un agent fait cela naturellement. Vous dites « les chiffres de revenus semblent incorrects dans le mart des ventes — tracez les modèles en amont et trouvez où le calcul diverge ». L’agent lit le SQL du mart, identifie les dépendances en amont, interroge chaque couche et localise le point de divergence. Il peut faire cela en une seule passe parce qu’il a un accès simultané à chaque fichier de votre projet. Le traçage de lignage qui est fastidieux pour les humains est trivial pour les agents. Consultez Débogage dbt avec Claude Code pour les mécaniques pratiques de fonctionnement.

Ce qui différencie le travail data du code applicatif

Le code applicatif a aussi des patterns, des changements de contexte et du débogage. Mais le data engineering a des propriétés qui amplifient l’avantage agent :

Densité de patterns plus élevée. Une application web typique a des dizaines de patterns architecturaux différents (routage, authentification, gestion d’état, endpoints API, accès base de données). Un projet dbt typique en a trois principaux — base, intermédiaire, mart — appliqués de façon répétée sur des centaines de modèles. Le ratio « patterns que l’agent doit apprendre » / « instances où il les applique » est beaucoup plus favorable.

Moindre ambiguïté des critères de succès. Un modèle de base suit la convention de nommage ou pas. Les tests passent ou pas. Le SQL compilé s’exécute ou pas. Comparé au code applicatif, où « correct » dépend souvent de jugements UX, le succès d’une transformation de données est plus mécaniquement vérifiable — du moins pour les aspects structurels. (La justesse de la logique métier est une autre histoire ; voir The Context Gap in AI Data Engineering.)

Dépendance aux conventions plus forte. La valeur d’un modèle dbt dépend fortement du fait qu’il suive les conventions du projet. Un modèle qui fonctionne correctement mais utilise un nommage différent, une matérialisation différente ou des patterns de test différents est une charge de maintenance. Les agents qui lisent votre projet existant et répliquent ses conventions résolvent exactement le problème qui rend l’assistance IA ad hoc insuffisante.

Périmètre de l’adéquation

Le travail data est bien adapté à l’IA agentique dans ses dimensions mécaniques — patterns répétitifs, coordination multi-fichiers, suivi de templates. Le gap de contexte demeure : la logique métier, le jugement sur la qualité des données et les décisions architecturales ne suivent pas des patterns qu’un agent peut lire depuis une codebase. L’agent gère la traduction de l’intention vers l’implémentation ; savoir quoi construire reste une responsabilité humaine. Le niveau d’outil importe moins que de comprendre quelles tâches relèvent du suivi de patterns et lesquelles nécessitent du jugement.