Les outils agentiques transforment le workflow data engineering : au lieu de traduire manuellement une intention en code, il s’agit désormais de décrire l’intention et de réviser le résultat. La traduction mécanique — recherche de schéma, adaptation de template, compilation Jinja, génération de tests — est prise en charge par l’agent. L’attention du praticien se déplace vers les parties nécessitant du jugement.
La couche de traduction
Pour les data engineers, une part considérable du travail est de la traduction. Des besoins métier vers des modèles de données. Des schémas bruts vers des couches de base propres. Des questions des parties prenantes vers des requêtes SQL. De la connaissance tacite vers de la documentation. Chaque traduction a la même structure : vous comprenez l’input (ce qui est nécessaire), vous connaissez le format de sortie (SQL, YAML, Markdown), et le travail consiste à créer le pont entre les deux.
Avant les outils agentiques, ce pont était manuel. Vous mainteniez les deux côtés en tête et tapiez la traduction caractère par caractère. Se rappeler la syntaxe, chercher les signatures de fonctions, adapter les templates, corriger les fautes de frappe — c’est ce qui remplissait le temps entre « je sais quoi construire » et « je l’ai construit ».
Les outils agentiques compressent ce pont. Vous décrivez ce dont vous avez besoin en langage naturel, l’agent génère le code, et vous révisez si la sortie correspond à votre intention. La traduction se produit toujours — mais l’agent gère la mécanique tandis que vous gérez l’intention.
C’est le plus évident pour les traductions répétitives. Un modèle de base pour une nouvelle table source est une traduction de « schéma brut » vers « modèle propre, nommé de façon cohérente, correctement typé, testé ». Les règles de traduction sont les mêmes à chaque fois : votre convention de nommage, votre pattern de déduplication, vos attentes de test. Un agent qui a lu votre projet (ou reçu un CLAUDE.md) connaît ces règles et les applique sans qu’on le lui dise.
Ce qui change en pratique
Ce changement n’est pas abstrait. Il modifie les rythmes quotidiens :
Création de modèles. Au lieu de passer 20 minutes à construire un modèle from scratch (recherche de schéma, copie de template, mapping de colonnes, config, tests, compilation, débogage), vous passez 2 minutes à écrire un prompt et 5 minutes à réviser la sortie. Le gain de temps net est réel, mais le changement le plus important est cognitif : vous passiez ces 20 minutes à faire un travail mécanique avant. Vous passez maintenant 5 minutes à faire un travail de jugement (ce modèle est-il correct ? capture-t-il la bonne logique métier ?).
Changements multi-fichiers. Renommer une colonne qui circule dans quatre modèles downstream signifiait autrefois ouvrir chaque fichier, trouver la référence, la mettre à jour, espérer ne pas en avoir manqué une, lancer le build complet pour vérifier. Maintenant : « Renomme customer_id en customer__id dans tous les modèles de la chaîne de lignage orders. » L’agent lit le DAG, trouve chaque référence, les met toutes à jour et lance le build. Consultez Workflows avancés de Claude Code pour dbt pour l’approche systématique.
Documentation. Écrire des descriptions de colonnes et la documentation des modèles est un travail de traduction — vous savez ce que fait le modèle et vous devez l’exprimer en YAML. C’est exactement le type de travail qu’un agent gère bien : il lit le SQL, comprend la transformation et génère des descriptions qu’un humain révise et affine ensuite.
Débogage. Quand un modèle produit des résultats incorrects, l’ancien workflow consiste à : émettre une hypothèse, interroger une table intermédiaire, analyser, réémettre une hypothèse, interroger une autre table, répéter. Le nouveau workflow : décrire le symptôme (« les revenus sont incorrects pour le client X »), laisser l’agent tracer le lignage, et réviser le diagnostic. L’investigation a toujours lieu — c’est juste que vous n’en pilotez plus chaque étape.
Le passage du « comment » au « quoi »
Avant les outils agentiques, une part significative du temps d’un data engineer allait aux questions d’implémentation : comment écrire cette requête, gérer cette syntaxe Jinja, structurer ce YAML. Avec les outils agentiques, plus de temps va aux décisions de modélisation : que doit contenir ce modèle, quelle est la bonne granularité, quelle logique métier s’applique, quels tests sont nécessaires. Le travail facile (syntaxe, templates, boilerplate) est automatisé ; le travail de modélisation reste humain.
Le risque — exploré en profondeur dans Atrophie des compétences développeur avec l’IA — est que déléguer entièrement le « comment » entraîne une perte de la compréhension qui découle du travail mécanique. Ce changement de workflow est soutenable quand réviser le code généré par l’IA construit la même compréhension que l’écrire autrefois.
La compétence de révision
Ce changement crée une nouvelle compétence fondamentale : réviser le code généré par l’IA. C’est différent de la revue de code traditionnelle.
Dans la revue de code traditionnelle, vous cherchez des erreurs humaines — fautes de frappe, erreurs logiques, incohérences de style, cas limites manquants. Dans la révision de code généré par l’IA, la syntaxe est presque toujours correcte. Ce que vous cherchez, ce sont des erreurs contextuelles :
- L’agent a-t-il utilisé le bon type de jointure ? (Un LEFT JOIN peut être syntaxiquement correct mais incorrect si la relation est en réalité one-to-one et que vous attendez un INNER JOIN.)
- A-t-il géré les NULL correctement pour votre contexte métier ?
- A-t-il appliqué les bons filtres temporels ? (Le gap de contexte montre que c’est là où l’IA échoue le plus silencieusement.)
- A-t-il suivi les conventions de façon cohérente, ou a-t-il introduit un pattern légèrement différent ?
- A-t-il ajouté quelque chose d’inutile ? (Les agents ont tendance à sur-ingénier — gestion d’erreurs superflue, abstractions inutiles, commentaires expliquant du code évident.)
Un modèle mental utile : traitez l’agent comme un junior compétent — rapide, productif, bon à suivre les patterns — avec le praticien lisant chaque ligne avant qu’elle ne soit livrée.
Ce qui ne change pas
Ce changement est réel mais limité. Les outils agentiques ne changent pas la nature fondamentale du travail data. Vous avez toujours besoin de :
- Comprendre le métier suffisamment pour savoir quels modèles sont nécessaires
- Concevoir le modèle de données (limites des couches, définitions des entités, décisions de granularité)
- Définir ce que « correct » signifie pour chaque transformation
- Porter des jugements de qualité qui dépendent de la connaissance organisationnelle
- Communiquer avec les parties prenantes sur ce que les données peuvent et ne peuvent pas répondre
Ce sont les parties qui font du data engineering une profession qualifiée plutôt qu’un exercice de frappe. Ce changement de workflow rend la partie frappe plus rapide. La partie réflexion reste la vôtre.