À mesure que les agents prennent en charge les tâches d’exécution en analytics engineering, le rôle du praticien évolue de la production du travail analytique à sa direction — de programmeur à manager. Un praticien a décrit son travail avec OpenClaw ainsi : « Il a remplacé le moi qui écrivait du code, endossant vraiment le rôle de programmeur et me libérant pour agir comme manager. » Ce changement survient plus rapidement avec les agents qu’il ne l’a fait quand les ingénieur·es senior·es passaient à des rôles de tech lead ; l’agent prend en charge les tâches d’exécution presque immédiatement.
De Producteur à Superviseur
Avant les agents, une heure pouvait être consacrée à l’écriture de SQL — comprendre l’exigence, la traduire en code, la tester, corriger les erreurs, la documenter. Avec un agent, cette même heure est consacrée à revoir le SQL généré, détecter les erreurs que l’agent ne pouvait pas détecter et apporter le jugement que l’agent n’a pas. Addy Osmani de Google l’a décrit comme être « le directeur du spectacle » : l’agent gère l’exécution tandis que le praticien définit la direction et prend les décisions de jugement.
Un agent peut exécuter dbt test sur l’intégralité de votre projet à 3h du matin et avoir les résultats disponibles dans Slack à 7h. Il ne peut pas décider si un échec de test représente un bug de qualité des données, un comportement attendu pour un nouveau cas limite, ou un faux positif d’un schéma amont récemment mis à jour. Cette décision nécessite un contexte que l’agent n’a pas et ne peut pas acquérir à partir d’une définition de schéma.
Un agent peut écrire une description de colonne pour subscription_start_at. Il ne peut pas écrire une description de colonne qui dit « le moment où un abonnement devient actif, qui peut différer de order__created_at pour les clients enterprise avec des flux d’onboarding personnalisés » — parce que connaître cette distinction nécessite de comprendre suffisamment profondément le métier pour savoir ce dont la prochaine personne qui lit le schéma a réellement besoin.
C’est la structure du rôle de directeur : vous définissez le travail, révisez les sorties et prenez les décisions qui nécessitent de savoir des choses que l’agent ne peut pas savoir.
Ce qui Reste Humain
L’étude de cas Recce sur les projets dbt générés par l’IA documente cette frontière. Claude Code, confronté à un projet dbt complet de bout en bout, a suivi les conventions de nommage, utilisé les CTEs et rendu les tables incrémentales sans y être invité. Mais il a utilisé des jointures internes là où des jointures gauches étaient nécessaires, reconstruit une dimension de date qui existait déjà, et filtré silencieusement les valeurs nulles sans signaler si elles étaient des bugs ou un comportement attendu. La conclusion de l’étude : « L’analytics engineering assisté par l’IA n’est pas un problème de prompting. C’est un problème d’infrastructure. »
L’IA écrit du SQL valide ; ce qui lui manque, c’est le contexte qui rend les décisions SQL correctes pour une entreprise spécifique. Les éléments du territoire humain issus de ce schéma d’échec :
Contexte métier et expertise domaine. Un agent peut calculer le churn. Il ne peut pas vous dire que la définition du churn de ce client particulier exclut les pauses saisonnières car l’équipe customer success les gère séparément, ou que le lookback de 90 jours a été choisi en raison d’une négociation contractuelle spécifique il y a deux ans. Ces connaissances institutionnelles ne vivent dans aucun schéma.
Jugements sur la qualité des données. Quand 15% des enregistrements ont un org_id manquant, s’agit-il d’un bug de qualité des données, d’un comportement attendu pour les utilisateurs du tier gratuit ou d’un nouveau cas limite d’un récent changement produit ? La réponse nécessite de connaître le produit, les données et l’histoire. L’agent voit l’écart ; vous en comprenez la signification.
Modélisation sémantique. L’écart entre « horodatage de création » et une description de colonne qui dit réellement à l’ingénieur·e suivant·e ce qu’il·elle doit savoir est l’écart entre un agent et un·e expert·e domaine. La bonne modélisation sémantique nécessite de savoir ce qui va semer la confusion chez les personnes qui lisent le schéma, ce qui implique de connaître suffisamment le métier pour anticiper la confusion.
Communication avec les parties prenantes. Concevoir ce que la data analytics devrait mesurer est un processus collaboratif. Quels KPIs importent pour le board deck de ce trimestre. Quel niveau de granularité l’équipe marketing a réellement besoin. Comment présenter une métrique qui a baissé sans déclencher de panique. Ce type de travail nécessite de lire les personnes, pas seulement les données.
Gouvernance et confiance. S’assurer que les produits data sont fiables, documentés et conformes aux réglementations. Quand le cron job d’un agent traite des données personnelles, la responsabilité de ce traitement des données ne peut pas être déléguée au processus autonome. Une personne humaine doit être responsable. Dans le conseil en Europe où le RGPD touche presque chaque pipeline, cette responsabilité est opérationnelle, pas théorique.
Orchestration stratégique. Décider quoi construire, pour qui, quand et pourquoi. La priorisation du backlog, les compromis entre vitesse et exactitude, le jugement sur quel projet client nécessite de l’attention cette semaine — ce sont des décisions de niveau directeur.
La Question de la Démocratisation
Les analytics engineers créent de la valeur en concevant des workflows plutôt qu’en les exécutant, en décidant ce qui doit être testé plutôt qu’en écrivant chaque test, et en gouvernant la qualité des pipelines plutôt qu’en construisant chaque pipeline. Comme l’a noté Tristan Handy (PDG de dbt Labs), les data engineers seront poussés dans trois directions : vers le domaine métier, vers l’automatisation ou vers la plateforme sous-jacente. Les équipes où les analytics engineers gèrent le travail domaine — conversations avec les parties prenantes, jugements sur la qualité des données, modélisation sémantique — tandis que les agents gèrent l’exécution sont mieux positionnées que les équipes où les analytics engineers faisaient principalement de l’exécution.
Implications Pratiques
Investissez plus de temps dans les spécifications. Le fichier CLAUDE.md, les définitions de skills, les attentes de tests sont les principales sorties du directeur. Un système bien spécifié avec des garde-fous clairs produit de meilleures sorties d’agents qu’un système vaguement spécifié avec un agent capable.
Développez une pratique de revue critique. Les modes d’échec du SQL généré par l’IA sont prévisibles — mauvais types de jointure, filtres temporels incohérents, filtrage silencieux des données. Revoir les sorties des agents exige de vérifier l’exactitude sémantique (« ce SQL est-il correct pour ce dont nous avons réellement besoin ? »), pas seulement la validité syntaxique.
Investissez dans l’expertise domaine. À mesure que les agents gèrent plus de travail mécanique, la valeur qu’un praticien apporte est de comprendre suffisamment le métier pour prendre les décisions que les agents ne peuvent pas. Documenter les connaissances tacites qui rendent les pipelines corrects pour une entreprise spécifique sert à la fois la performance des agents et la continuité institutionnelle.
Gouvernez activement l’accès des agents. Le gradient de confiance va d’observateur (lecture seule, rapport des résultats) à déployeur (merge et déploiement en production). La plupart des agents devraient opérer à l’extrémité inférieure de ce gradient. Posture de sécurité pour les agents IA couvre la mécanique.
Implications pour l’Évolution de Carrière
- Début de carrière : Apprenez les fondamentaux en profondeur d’abord — SQL, modélisation de données, logique métier, mécanique des entrepôts. L’IA amplifie les compétences existantes ; elle ne compense pas les lacunes. Être capable d’évaluer si le SQL généré par l’IA est correct nécessite une base sur laquelle l’évaluer.
- Milieu de carrière : Construire des compétences d’orchestration IA maintenant — des workflows qui combinent jugement humain et exécution par agent — est l’investissement au plus fort levier. Suffisamment d’expérience pour évaluer les sorties IA de manière critique fait de cette étape le point d’entrée le plus productif.
- Rôles senior et de leadership : Définir comment les agents s’intègrent dans le workflow de l’équipe, construire les garde-fous et les processus de revue, établir les cadres de gouvernance qui préviennent les décisions silencieuses sur la qualité des données. Cela inclut de décider ce qui est automatisé et ce qui ne l’est pas.