L’ensemble de la recherche sur l’IA appliquée à l’ingénierie des données converge vers un constat : la qualité du contexte détermine la qualité des résultats. La principale source d’erreurs de Claude Code était le désalignement avec les conventions du projet, un problème résolu par des fichiers d’instructions structurés. Les échecs de Thomson Reuters provenaient d’un contexte temporel absent. La précision de Tiger Data a progressé de 27 % grâce aux catalogues sémantiques. La discipline émergente est l’ingénierie du contexte — comment structurer ce que l’IA doit savoir, et pas seulement comment la solliciter.
De l’ETL à l’ECL
Ananth Packkildurai a proposé de remplacer entièrement le paradigme ETL par ECL : Extract, Contextualize, Link. L’argument est que le travail mécanique de construction des pipelines — le « Transform » et le « Load » — n’est plus un différenciateur. L’IA s’en charge. Ce qui différencie, c’est de savoir ce que le pipeline doit faire, pourquoi, et comment il s’inscrit dans un système plus large.
« Contextualize » est la nouvelle étape intermédiaire. Elle consiste à ajouter la couche de sens : que représente cette colonne, quels sont les cas limites, comment cette table est-elle reliée aux autres, quelles règles métier s’appliquent. « Link » signifie connecter les données contextualisées aux consommateurs en aval de manière à préserver le sens — pas seulement joindre des tables, mais s’assurer que les jointures ont du sens pour la question métier posée.
Ce recadrage capture quelque chose de réel. En 2026, la partie la plus difficile de la construction d’un pipeline de données n’est pas le SQL. C’est de savoir ce que le SQL doit faire. Le fossé de contexte est le goulot d’étranglement, et l’ingénierie du contexte est la discipline qui y répond.
Ce qu’est l’ingénierie du contexte en pratique
L’ingénierie du contexte pour les pipelines de données implique plusieurs pratiques concrètes :
Les catalogues sémantiques. Des descriptions lisibles par machine de ce que signifient les tables et les colonnes. Pas seulement « customer_id : integer » mais « customer_id : identifiant unique d’un compte client, généré à la création du compte dans Stripe, peut ne pas correspondre aux IDs client CRM pour les comptes créés avant la migration de 2023. » Tiger Data a montré que ces descriptions améliorent la précision de l’IA de 27 %. Elles n’ont pas besoin d’être parfaites — des descriptions générées par LLM et relues par des humains suffisent à faire la différence.
Les fichiers d’instructions structurés. CLAUDE.md est l’exemple le plus simple — un fichier qui indique à Claude Code comment ce projet spécifique fonctionne. Mais le modèle s’étend à tout système IA qui a besoin du contexte d’un projet : conventions de code, standards de nommage, décisions architecturales, choses à éviter. Chaque instruction prévient une classe d’erreurs.
La documentation comme entrée IA. Descriptions de colonnes, descriptions de modèles, définitions de sources — toutes les métadonnées que le système de documentation de dbt capture. Traditionnellement rédigées pour la consommation humaine, ces descriptions sont désormais tout aussi importantes comme entrée pour l’IA. Une meilleure documentation dans votre projet dbt signifie de meilleures requêtes générées par l’IA sur votre entrepôt.
Les suites de tests comme spécification. Les tests encodent ce que « correct » signifie. Un test unique + not_null sur order_id indique à l’IA qu’il s’agit d’une clé primaire. Un test relationships lui indique comment les tables sont connectées. Un test accepted_values lui indique quels états sont valides. La suite de tests est une spécification lisible par machine de la correction des données.
La lineage comme contexte. Comment les modèles se connectent, quelles tables sont en amont de quelles autres, où la logique métier est appliquée. Le DAG de dbt capture cela automatiquement. Les outils IA capables de lire la lineage comprennent mieux la chaîne de transformation que l’IA travaillant avec des requêtes isolées.
Le risque de compréhension
L’essai contrôlé randomisé d’Anthropic lui-même, conduit en janvier 2026 avec 52 développeurs, a révélé que les développeurs assistés par IA obtenaient des scores de compréhension du code 17 % inférieurs (50 % contre 67 %). L’écart le plus important concernait le débogage. Les développeurs qui déléguaient la génération de code à l’IA obtenaient des scores inférieurs à 40 %. Ceux qui utilisaient l’IA pour des requêtes conceptuelles obtenaient 65 % ou plus.
La façon dont vous utilisez l’IA détermine si elle renforce ou érode votre capacité. Utiliser l’IA pour écrire du code que vous pourriez écrire vous-même — mais plus rapidement — est un gain de productivité. Utiliser l’IA pour écrire du code que vous ne comprenez pas est une perte de compréhension. Au fil du temps, les pertes de compréhension s’accumulent : on ne peut pas déboguer ce qu’on ne comprend pas, on ne peut pas concevoir ce qu’on n’a pas construit, et on ne peut pas fournir le contexte dont l’IA a besoin si on ne sait pas quel est ce contexte.
Cela importe parce que l’ingénierie du contexte exige une compréhension approfondie. On ne peut pas écrire des descriptions de catalogue sémantique pour des tables qu’on n’a pas travaillées. On ne peut pas documenter des cas limites pour des règles métier qu’on n’a jamais rencontrées. Les personnes les mieux positionnées pour faire de l’ingénierie du contexte sont celles qui ont passé des années à apprendre les données à la dure.
Le risque sur la chaîne de compétences
L’étude Digital Economy de Stanford a constaté que l’emploi des développeurs logiciels âgés de 22 à 25 ans a chuté de près de 20 % par rapport au pic de fin 2022. Marc Benioff a annoncé que Salesforce n’embaucherait « aucun nouvel ingénieur » en 2025. Le risque est structurel : les seniors au sommet, l’IA à la base, et très peu de juniors qui apprennent le métier entre les deux.
Matt Garman, PDG d’AWS, a répliqué directement : « C’est l’une des choses les plus stupides que j’aie jamais entendues… Comment cela va-t-il fonctionner dans dix ans quand vous n’aurez personne qui ait appris quoi que ce soit ? »
La vraie question est de savoir si les organisations maintiennent la chaîne de personnes qui développent le jugement que l’IA ne possède pas. L’enquête 2026 de Joe Reis auprès de 1 101 praticiens a révélé que 82 % utilisent l’IA quotidiennement, mais que 64 % sont bloqués dans « l’expérimentation » ou les « tâches tactiques ». L’écart entre l’utilisation de l’IA pour générer du code standard et la compréhension de pourquoi ce code doit avoir cette forme est là où l’expertise se développe.
Si les juniors n’ont jamais l’occasion d’écrire du mauvais SQL, de le déboguer, d’apprendre pourquoi il était incorrect et d’intérioriser la correction, ils ne développent jamais le savoir tacite qu’exige l’ingénierie du contexte. On se retrouve avec une génération de praticiens capables de solliciter l’IA efficacement mais incapables d’évaluer si le résultat est correct — ce qui est exactement la situation où les modes de défaillance du SQL généré par IA deviennent les plus dangereux.
La discipline émergente
Comme l’a formulé Zach Wilson : « L’IA n’a pas tué l’ingénierie des données. Elle a tué le fait de prétendre que l’ingénierie des données consistait à taper du code. » La maîtrise syntaxique est banalisée. Ce qui demeure, c’est le contexte et le jugement.
Le contexte métier et le jugement architectural ne sont pas fournis par les mises à jour de modèles ; ils viennent du travail avec les données assez longtemps pour savoir ce que « Status » signifie réellement. L’ingénierie du contexte opérationnalise cette connaissance : catalogues sémantiques, fichiers d’instructions, documentation complète, suites de tests comme spécifications, et lineage comme architecture lisible par machine.