Contexte et émergence du rôle
Nick Ursa, lead data engineer et co‑fondateur de MotherDuck, affirme que l’IA a éliminé son backlog : « c’est la première fois de ma carrière sans backlog ». Malgré l’absence de tickets, il reste plus occupé, car chaque réponse générée par un LLM ou un agent doit être vérifiée. Cette situation a conduit à la proposition, le 4 novembre lors du Data Outpost, du titre Data Intelligence Engineer. Le terme désigne la fonction émergente au sein d’équipes data « AI‑enabled », où la rapidité de décision dépend de la capacité à transformer une question business en réponse fiable.
Fonctionnement et responsabilités
Le processus traditionnel ressemble à un relais : un responsable marketing signale un pic de churn, un analyste ouvre un ticket, découvre un manque d’export, sollicite un data engineer, qui modifie le pipeline, teste, backfill, puis rend le ticket. Chaque main‑mise introduit un délai et une perte de contexte, réduisant la « half‑life » de l’utilité de la réponse. L’IA modifie ce schéma en permettant aux agents de générer du SQL, d’ajuster les requêtes et de réitérer en mode multi‑turn, comme le ferait un analyste humain. Ainsi, un même agent peut exécuter une première requête, analyser le résultat, puis affiner la requête sans intervention humaine immédiate.
Un exemple concret présenté par l’auteur montre une application construite avec MotherDuck et le modèle Claude. En combinant quatre sources de données, il a créé des visualisations interactives et animées sans écrire une seule ligne de code ou de SQL. Cette démonstration illustre que, dès à présent, la création de tableaux de bord ou d’applications peut être pilotée uniquement par des prompts, réduisant le besoin de compétences spécialisées.
Par ailleurs, le même data engineer a migré une instance d’Airflow vers une version supérieure en un week‑end, alors que la même opération aurait requis une semaine auparavant. Cette accélération résulte de l’automatisation des tâches d’infrastructure par des agents capables de produire les scripts de migration.
Impacts techniques et limites
Si les agents peuvent écrire du code, la responsabilité finale demeure humaine. Le Data Intelligence Engineer doit garantir la qualité des données, valider les modèles de données, annoter les ontologies et s’assurer que les termes métier (par ex. « revenue » vs « commissionable revenue ») sont correctement interprétés. Un modèle ne possède pas la connaissance contextuelle de la façon dont une entreprise calcule ses indicateurs ; il ne sait pas non plus identifier la table officielle parmi plusieurs variantes (ex. revenue_cpx_new_revised_v2_use_this_one).
Cette dépendance au contexte impose deux contraintes majeures : premièrement, la nécessité de maintenir un modèle de données propre et documenté, sinon les agents consommeront davantage de tokens pour reconstituer le contexte, ce qui augmente les coûts et le temps de réponse. Deuxièmement, la supervision humaine reste indispensable pour signer les livrables, car aucune garantie n’existe que les résultats générés respectent les règles de conformité ou les exigences de gouvernance.
En résumé, l’émergence du Data Intelligence Engineer reflète la transition d’une chaîne de tickets à un flux d’interaction homme‑machine. L’IA accélère la production de requêtes SQL, de pipelines et de visualisations, mais la fiabilité, la gouvernance et la clarté du modèle de données restent des prérequis indispensables pour éviter les dérives de qualité.
