Les outils de codage IA comportent un risque de second ordre au-delà des bugs dans le code généré par l’IA : l’atrophie de la compréhension développeur. L’essai contrôlé randomisé d’Anthropic (janvier 2026, n=52) a révélé que les développeurs assistés par IA ont obtenu des scores 17 % inférieurs aux tests de compréhension du code par rapport aux développeurs travaillant sans assistance IA.
Délégation vs. interrogation
L’étude a révélé une division marquée selon la façon dont les développeurs utilisaient les outils IA. Les développeurs qui déléguaient la génération de code — « écris-moi une fonction qui fait X » — ont obtenu des scores inférieurs à 40 % aux tests de compréhension. Les développeurs qui utilisaient l’IA pour l’interrogation conceptuelle — « explique comment cette fonction fonctionne », « quels sont les compromis entre ces deux approches ? » — ont obtenu des scores de 65 % ou plus.
La différence n’est pas subtile. C’est la différence entre comprendre votre codebase et avoir une codebase qui fonctionne par hasard. Les deux développeurs livrent des fonctionnalités. L’un d’eux peut déboguer des incidents de production à 2h du matin. L’autre doit demander à l’IA ce que fait son propre code.
Pourquoi c’est important pour le data engineering
Le data engineering présente une vulnérabilité spécifique ici. La plupart de notre travail implique des transformations SQL, l’orchestration de pipelines et de la configuration — exactement le type de travail riche en patterns et en boilerplate où la délégation à l’IA semble la plus productive. Écrire un modèle de base qui renomme et caste des colonnes ? Laisser l’IA le faire. Générer des tests schema.yml ? Laisser l’IA le faire. Écrire un modèle incrémental avec une fenêtre de lookback ? Laisser l’IA le faire.
Chaque délégation individuelle est raisonnable. L’effet cumulatif est un ingénieur qui ne peut pas tracer un problème de qualité des données à travers son propre DAG sans l’assistance de l’IA. Quand un modèle mart rapporte des chiffres incorrects, le débogage nécessite de comprendre chaque transformation dans la chaîne — les type casts du modèle de base, la logique de jointure du modèle intermédiaire, la granularité d’agrégation du mart. Si vous avez délégué l’écriture des trois sans en internaliser le fonctionnement, le débogage devient une conversation avec l’IA plutôt qu’une investigation que vous contrôlez.
La constatation de Thomson Reuters — 73 % des analyses SQL temporelles générées par IA avaient des filtres temporels incohérents — devient bien plus inquiétante quand l’humain qui révise ces requêtes ne comprend pas pleinement la sémantique des filtres temporels parce qu’il délègue la génération SQL depuis des mois.
Le compromis vitesse vs. compréhension
Les outils IA apportent de vrais gains de vitesse — une accélération de 2 à 10 fois sur les tâches adaptées est bien documentée. Si cette accélération se fait au détriment de la compréhension, l’effet net sur le long terme peut être négatif : livraison plus rapide ce trimestre, débogage plus lent le prochain, erreurs subtiles qui s’accumulent parce que personne ne comprend pleinement la codebase.
L’observation de Zach Wilson : « L’IA n’a pas tué le data engineering. Elle a tué le fait de prétendre que le data engineering consistait à taper du code. Si votre valeur était la maîtrise de la syntaxe, cette valeur est désormais banalisée. » La maîtrise de la syntaxe est banalisée, mais le modèle mental de comment les données circulent, se transforment et s’agrègent est plus difficile à acquérir par délégation que par la pratique.
L’argument n’est pas contre les outils IA mais pour des choix délibérés sur quelles tâches déléguer et lesquelles faire directement, même quand la délégation est plus rapide.
Atténuation pratique
Quelques patterns qui préservent la compréhension tout en capturant les avantages de vitesse de l’IA :
Réviser, pas seulement approuver. Quand l’IA génère un modèle, lisez chaque ligne avant de committer. Pas pour attraper des erreurs de syntaxe — l’IA les gère. Lisez pour comprendre ce que cela fait. Tracez les jointures mentalement. Vérifiez la granularité. Contrôlez les filtres temporels. Cette révision est autant pour votre compréhension que pour la correction.
Écrire vous-même les parties difficiles. Déléguez le boilerplate (modèles de base, scaffolding schema.yml, ébauches de documentation) mais écrivez manuellement la logique métier complexe. Le modèle d’attribution de session, le calcul de reconnaissance des revenus, la formule de valeur vie client — ce sont les modèles où comprendre la logique est non négociable. Utilisez l’IA pour réviser votre implémentation, pas pour la générer.
Utiliser l’IA pour l’interrogation, pas seulement la génération. Au lieu de « écris-moi un modèle incrémental pour les sessions », essayez « explique les compromis entre merge et insert_overwrite pour une table de sessions avec 500M de lignes ». Le second prompt construit votre modèle mental. Vous écrivez ensuite l’implémentation — ou vous demandez à l’IA d’en faire un brouillon, et vous savez quoi chercher lors de la révision parce que vous venez de vous engager avec les concepts.
Maintenir une pratique de débogage. Déboguez périodiquement des problèmes sans assistance IA. Non pas parce que c’est plus rapide (ce ne l’est pas), mais parce que le débogage vous force à comprendre le système. Si vous pouvez tracer un problème de qualité des données depuis le mart jusqu’à la source sans l’aide de l’IA, votre compréhension est intacte. Si vous ne pouvez pas, c’est un signal que vous avez délégué trop agressivement.
Construire vous-même les documents de contexte. Écrire un CLAUDE.md from scratch vous force à articuler explicitement les conventions de votre projet. Chaque règle que vous écrivez reflète quelque chose que vous comprenez sur le fonctionnement du projet. C’est un des cas où le processus d’écriture du document est aussi précieux que le document lui-même.
L’étude d’Anthropic suggère un pattern cohérent : utiliser l’IA comme partenaire de réflexion plutôt que comme usine à code — posez-lui des questions, demandez-lui d’expliquer des compromis, explorez des approches avant de vous engager. Quand l’IA écrit le code, révisez-le suffisamment en profondeur pour internaliser ce qu’il fait. La vitesse et la compréhension ne sont en tension que lorsque le code généré par l’IA est traité comme une sortie plutôt que comme une entrée pour la compréhension propre du praticien.