Le passage du copilote à l’agent change quelles compétences en analytics engineering sont les plus pertinentes. Les copilotes valorisent la maîtrise SQL, les instincts de modélisation et la connaissance du domaine. Les agents gèrent davantage l’exécution directement, déplaçant la valeur vers la direction de l’exécution, la revue des sorties et les jugements que les agents ne peuvent pas prendre de manière autonome.
Sept domaines de compétences sont décrits ci-dessous, correspondant aux endroits où ce déplacement est le plus prononcé.
1. Orchestration IA
Configurer des Skills, des MCPs, des hooks et des garde-fous. Pas prompter des agents, mais les configurer.
La distinction est importante. Le prompting est au niveau de la session : vous décrivez ce que vous voulez, l’agent le fait, la session se termine. L’orchestration est au niveau du projet : vous définissez ce que l’agent doit toujours faire, ce qu’il ne doit jamais faire, à quels outils il a accès, comment il doit gérer les échecs et ce qu’il doit rapporter. La couche d’orchestration est ce qui transforme un agent en système plutôt qu’en chatbot rapide.
Un CLAUDE.md bien conçu est de l’orchestration. Une bibliothèque de skills testés est de l’orchestration. Des hooks de production qui bloquent les modifications des schémas de production et exécutent automatiquement SQLFluff après chaque modification — également de l’orchestration. Ce sont les artefacts qui séparent les sorties d’agents utiles des cycles de correction constants.
Cette compétence est distincte de tout outil spécifique — OpenClaw, Claude Code, dbt Agent Skills ont chacun des mécanismes de configuration différents, mais la discipline sous-jacente de définir précisément le comportement des agents est la même.
# Exemple : Un garde-fou dans CLAUDE.md qui prévient une classe d'erreurs spécifique
## Règles de Sécurité- NE JAMAIS exécuter `dbt run` sans d'abord exécuter `dbt compile`- NE JAMAIS modifier des modèles dans marts/ sans vérifier d'abord l'impact en aval (`dbt ls --select +model_name+`)- NE JAMAIS committer des modifications sans exécuter des tests sur les modèles affectésLe jugement clé est de savoir quelles règles doivent exister — quels comportements d’agents, laissés sans contraintes, produiront des erreurs qui dépassent la surcharge de configuration.
2. Ingénierie des Spécifications
Écrire des exigences que les machines peuvent suivre.
C’est différent de la documentation traditionnelle. La documentation est écrite pour des humains qui interpréteront, appliqueront du jugement et poseront des questions de clarification quand quelque chose est ambigu. Les spécifications pour l’IA doivent être suffisamment précises pour qu’un agent sans aucun jugement sur le contexte puisse les suivre correctement.
Pensez-y comme écrire un ticket détaillé pour un·e ingénieur·e junior très capable qui n’a pas accès à vous pour des questions de suivi et qui interprétera chaque instruction littéralement. Là où un humain déduirait du contexte, un agent fera exactement ce que vous avez dit — et si ce que vous avez dit était ambigu, il fera un choix que vous n’aviez pas prévu.
CLAUDE.md est l’artefact principal de l’ingénierie des spécifications pour le travail dbt. Mais la compétence s’étend à la façon dont vous rédigez les descriptions de skills, comment vous formulez les prompts pour des tâches complexes, et comment vous structurez les attentes de tests. La capacité à écrire des instructions précises et non ambiguës devient une compétence centrale car elle détermine directement la qualité des sorties d’agents.
Une bonne ingénierie des spécifications produit :
- Des conventions de nommage claires qui ne laissent aucune place à l’interprétation (« base__, pas base_ »)
- Des séquences de workflow explicites (« compiler d’abord, puis exécuter, puis tester — dans cet ordre »)
- Des limites négatives qui définissent ce que l’agent ne DOIT PAS faire, pas seulement ce qu’il doit faire
- Le contexte expliquant pourquoi les règles existent, pour que l’agent les applique correctement dans les cas limites
Ce dernier point est sous-estimé. Les instructions sans justification sont appliquées mécaniquement. Les instructions avec justification sont appliquées avec quelque chose qui se rapproche du jugement :
# Sans justification (appliqué mécaniquement, peut rater un cas limite)- Utiliser LEFT JOIN lors de la jointure sur la table orders
# Avec justification (appliqué avec jugement)- Utiliser LEFT JOIN lors de la jointure sur la table orders — certains clients ont des comptes mais pas encore de commandes, et nous ne voulons jamais les exclure des analyses à grain client3. Revue Critique du Code
Détecter les modes d’échec spécifiques de l’IA avant qu’ils n’atteignent la production.
Le code généré par l’IA tend à sembler correct — il suit des patterns, utilise un nommage cohérent et se compile sans erreurs. Les échecs sont typiquement sémantiques, pas syntaxiques, et nécessitent une compréhension de ce que les données devraient représenter pour être détectés.
Les modes d’échec sont suffisamment prévisibles pour être vérifiés délibérément :
Erreurs de type de jointure. L’échec silencieux le plus courant. Une jointure interne là où une jointure gauche était nécessaire supprime des enregistrements sans aucune erreur visible. Les rapports de revenus semblent plus propres que prévu. L’écart est invisible jusqu’à ce que quelqu’un vérifie les comptages de lignes par rapport à la source.
-- L'agent a écrit ceci (supprime les clients sans commandes)SELECT c.customer_id, SUM(o.revenue) AS total_revenueFROM customers cINNER JOIN orders o ON c.customer_id = o.customer_idGROUP BY 1
-- Devrait être ceci (préserve tous les clients)SELECT c.customer_id, COALESCE(SUM(o.revenue), 0) AS total_revenueFROM customers cLEFT JOIN orders o ON c.customer_id = o.customer_idGROUP BY 1Incohérences de filtres temporels. Appliquer des filtres de date à une table dans une jointure mais pas à la table jointe. La conclusion de Thomson Reuters — 73% des analyses temporelles générées par l’IA avaient cette erreur — signifie que ce n’est pas un cas limite. C’est le mode d’échec par défaut quand un agent applique des filtres sans comprendre le modèle temporel de l’entrepôt.
Filtrage silencieux des données. Les agents prennent des décisions de qualité des données sans les signaler. Valeurs nulles filtrées, enregistrements exclus par une condition imprévue, lignes supprimées parce qu’une clé de jointure était mal appariée. La sortie est plus petite que l’entrée et personne ne sait pourquoi.
Références de couches incorrectes. Dans un projet dbt à trois couches, un modèle intermédiaire qui référence directement une source (en contournant la couche base) ou un mart qui référence directement un modèle base (en contournant la transformation intermédiaire) viole l’architecture sans produire d’erreurs. Le modèle s’exécute correctement de manière isolée et échoue subtilement dans le système.
La revue critique du code pour les sorties d’agents est une compétence différente de la revue de code pour les sorties humaines. Pour les humains : cherchez les erreurs logiques, les cas limites, les problèmes de performance. Pour les agents : cherchez les inadéquations sémantiques — l’agent a-t-il compris ce que les données signifient, ou juste à quoi elles ressemblent ?
4. Expertise Métier
La valeur passe de taper du SQL à comprendre les questions métier.
Cette compétence existe à chaque étape de l’analytics engineering, mais elle devient relativement plus importante à mesure que les agents gèrent davantage d’exécution. Quand l’exécution est commoditisée, la valeur différenciée est une connaissance profonde du métier qui rend l’exécution correcte.
Un agent peut calculer l’attribution. Il ne peut pas vous dire que le modèle d’attribution de ce client a une fenêtre de lookback de 30 jours parce que son cycle de vente est long, et que l’équipe marketing fait pression pour la réduire à 14 jours, et que les données soutenant le modèle à 14 jours existent mais que la décision métier n’a pas encore été prise. Ce contexte est ce qui fait la différence entre produire un modèle techniquement correct et un qui est réellement utile pour la décision en cours.
L’expertise domaine s’accumule à travers l’investissement dans les parties prenantes : du temps avec les personnes qui utilisent les données, la documentation des connaissances tacites qui rendent les pipelines corrects pour une entreprise spécifique, et la compréhension des décisions qui n’ont pas encore été finalisées.
5. Gouvernance des Données et Éthique
S’assurer que les pipelines générés par l’IA répondent aux standards de qualité, de conformité et réglementaires.
Cela devient particulièrement critique quand les agents fonctionnent de manière autonome. Quand un humain écrit chaque transformation, les décisions de gouvernance sont visibles et délibérées. Quand un agent génère des transformations par lots, les décisions de gouvernance se produisent implicitement — et à moins que vous n’ayez défini ce que « conforme » signifie dans la configuration de l’agent, l’agent optimisera pour la fonctionnalité sans conscience des contraintes réglementaires.
Pour le conseil en Europe, le RGPD touche presque chaque pipeline. Quelles tables contiennent des données personnelles. Où ces données peuvent être traitées. Combien de temps elles peuvent être conservées. Qui peut y accéder. Un agent qui génère un pipeline sans ces contraintes n’est pas malveillant — il manque simplement de contexte. Les contraintes de gouvernance doivent être encodées dans les spécifications que l’agent suit.
La question de responsabilité est pratique, pas théorique : quand le cron job d’un agent traite des données personnelles d’une manière qui s’avère violer le RGPD, qui est responsable ? Pas l’agent. La personne qui l’a configuré et supervisé. Cela déplace la responsabilité de gouvernance de « s’assurer que le code est conforme » à « s’assurer que l’agent ne produit que du code conforme ». Même résultat, compétence différente.
6. Architecture et Pensée Systémique
Concevoir la plateforme data globale, pas des modèles individuels.
Un agent peut construire un modèle. Il ne peut pas concevoir une plateforme. Les méta-décisions — quels outils s’intègrent dans le stack, où tracer les limites des couches, comment gérer les données à travers les frontières organisationnelles, quels compromis accepter entre flexibilité et gouvernance — nécessitent une compréhension du système dans son ensemble.
L’ère des agents rend la pensée systémique plus importante, pas moins, pour une raison structurelle : quand les agents écrivent plus de code, les décisions architecturales se multiplient à travers plus de code. Une bonne décision architecturale sur la modélisation du temps dans l’entrepôt rend chaque requête générée par l’IA plus susceptible d’être correcte. Une mauvaise décision architecturale sur la logique temporelle est reproduite dans chaque modèle généré qui touche le temps.
Cela inclut de savoir quand utiliser quel outil : quand OpenClaw versus Claude Code, quand un modèle incrémental versus un rafraîchissement complet, quand dbt Core versus dbt Cloud, quand construire une solution personnalisée versus utiliser un package. Ce sont des choix architecturaux. L’agent implémente quelle que soit l’architecture que vous lui donnez.
7. Maîtrise des Outils IA
Comprendre le point fort de chaque outil dans votre stack.
L’outillage évolue rapidement. Rester au courant de ce qui est disponible et de ce qui est réellement prêt pour la production (versus prêt pour une démo) est en soi une compétence. Le modèle mental en quatre couches aide ici — assistant IDE, agent de codage, couche d’orchestration, couche de revue — car il fournit un cadre stable pour évaluer les nouveaux outils par rapport aux rôles qu’ils remplissent.
La maîtrise des outils n’est pas de suivre chaque nouvelle version. C’est de savoir, pour n’importe quelle tâche :
- Quel outil lui est le mieux adapté
- Quels sont les modes d’échec de cet outil pour cette tâche
- Quels garde-fous doivent être en place avant de s’appuyer dessus pour ce type de travail
Un exemple concret : Claude Code est excellent pour construire des modèles de bout en bout à partir d’une spécification, mais filtre silencieusement les nulls lors de prises de décisions sur la qualité des données. Ce mode d’échec signifie que chaque modèle que Claude Code construit devrait être révisé avec une attention particulière à la gestion des nulls. OpenClaw est excellent pour le monitoring planifié mais présente un profil de sécurité sérieux à considérer avant de l’utiliser avec des données client. Posture de sécurité pour les agents IA couvre cela. Connaître ces limitations est ce qui permet d’utiliser les outils sans être surpris par leurs modes d’échec.