Data Engineering Weekly a sondé les praticiens sur ce qui reste essentiel quand l’IA écrit de plus en plus de code : 53% ont cité l’architecture et les arbitrages, 25% la découverte produit et problème, 20% la qualité et la propriété. L’IA génère du SQL, du boilerplate, des descriptions de colonnes et des configurations de modèles incrémentiels — la couche d’exécution mécanique. Les décisions d’architecture, de propriété et de modélisation temporelle restent hors de portée de ce que l’IA peut produire à partir du contexte disponible.
Ce que sont réellement les décisions architecturales
Tristan Handy a spécifiquement mentionné « concevoir l’architecture globale du DAG, y compris la modularisation, les frontières d’équipes et la propriété » comme une tâche fondamentalement humaine. Cela vaut la peine d’être décomposé car « architecture » est un terme surchargé.
Dans un projet dbt, l’architecture signifie :
Structure du DAG. Comment les modèles se connectent. Quelles transformations sont en amont de quelles autres. S’il faut centraliser la logique partagée dans des modèles intermédiaires ou laisser les marts la dupliquer. L’pattern en trois couches (base, intermédiaire, marts) est une décision architecturale, et elle détermine si un projet passe à l’échelle ou s’effondre sous son propre poids.
Modèles de propriété. Quelle équipe possède quels modèles. Où se trouvent les frontières entre domaines. Si l’équipe marketing peut modifier des modèles qui alimentent les rapports de l’équipe finance. Ce ne sont pas des questions techniques — ce sont des questions organisationnelles qui nécessitent de comprendre comment l’entreprise fonctionne.
Comment répartir les responsabilités entre domaines. La valeur à vie client doit-elle vivre dans le domaine marketing ou le domaine finance ? Les deux équipes en ont besoin. Les deux équipes la calculent différemment. La réponse dépend de la structure de prise de décision de l’organisation, pas d’une contrainte technique.
Évaluation des arbitrages. Chaque choix architectural est un arbitrage. Les modèles incrémentiels réduisent les coûts mais ajoutent de la complexité. Des conventions de nommage strictes améliorent la découvrabilité mais ralentissent le développement initial. Les contrats sur les marts garantissent la stabilité du schéma mais nécessitent plus de maintenance. L’IA peut lister les arbitrages. Elle ne peut pas les évaluer dans un contexte spécifique.
L’IA peut générer des modèles individuels. Elle ne peut pas prendre ces décisions structurelles. L’information nécessaire — comment fonctionne l’organisation, quelles équipes collaborent, où se trouvent les frontières politiques, ce qui a échoué par le passé — n’est encodée nulle part où l’IA peut la lire.
La logique temporelle comme architecture
La découverte de Thomson Reuters — que 73% des analyses basées sur le temps avaient des filtres temporels incohérents — est une histoire d’architecture, pas d’écriture de requêtes.
Les incohérences temporelles reflètent des décisions de conception sur la façon dont le temps est modélisé à travers le warehouse. Quelles tables utilisent le temps d’événement vs le temps de traitement ? Comment les dimensions à évolution lente tracent-elles l’historique ? Quand des données arrivant en retard sont incorporées, quelles requêtes en aval doivent tenir compte du délai ? Comment la stratégie incrémentale interagit-elle avec le modèle temporel ?
Ces choix se propagent à travers chaque requête en aval. Une IA générant du SQL contre une architecture temporelle bien conçue produit de meilleurs résultats qu’une IA travaillant avec une architecture confuse, parce que l’architecture contraint ce qui est possible. Bien modéliser le temps à la fondation laisse moins de marge pour que les requêtes générées par IA se trompent.
C’est pourquoi l’architecture compte d’autant plus que l’IA écrit plus de code. Quand un humain écrit chaque requête, les incohérences temporelles sont localisées — un analyste fait une erreur, cela affecte son travail. Quand l’IA génère des centaines de requêtes contre le même warehouse, un mauvais choix architectural sur le fonctionnement du temps se multiplie à travers chaque requête générée.
Le facteur différenciateur en ingénierie
Le blog technique de Kestra a capturé la transformation avec précision : « L’IA est en train de commoditiser la partie ‘données’. N’importe qui peut écrire du SQL avec de l’assistance. La partie ‘ingénierie’ devient le facteur différenciateur : la fiabilité, la réponse aux incidents, les coûts. »
C’est un cadrage utile car il sépare deux choses qui étaient autrefois regroupées. « L’ingénierie des données » était à la fois « travailler avec des données » (comprendre les schémas, écrire des transformations, construire des pipelines) et « ingénierie de systèmes » (assurer la fiabilité, gérer les coûts, gérer les pannes avec grâce). L’IA gère de mieux en mieux la première partie. La seconde nécessite un jugement sur :
-
La fiabilité. Que se passe-t-il quand ce modèle échoue à 3h du matin ? Qui est contacté ? Quelle est la procédure de récupération ? Les données sont-elles assez fraîches pour le rafraîchissement du dashboard à 7h00, ou faut-il construire un mécanisme de retry ?
-
La réponse aux incidents. Le rapport de revenu affiche des chiffres 30% en dessous d’hier. Est-ce un problème de données, une défaillance de pipeline, un changement de schéma, ou un événement commercial réel ? Le diagnostic nécessite de savoir à quoi ressemble le « normal », ce qui est une connaissance accumulée, pas quelque chose qu’on peut promter.
-
Les coûts. Une requête qui scanne 2 To de données toutes les heures coûte de l’argent réel. Une stratégie incrémentale qui remplace des partitions entières vs une qui scanne la table complète à chaque exécution a des implications de coût significatives. Ces décisions nécessitent de comprendre à la fois les patterns des données et le modèle de coût du warehouse.
-
La propriété. Quand un modèle casse, qui le corrige ? Quand une partie prenante remet en question un chiffre, qui enquête ? L’IA génère du code. Les humains en prennent la responsabilité.
Zach Wilson a résumé la transformation : « 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. » Si la valeur ajoutée était la maîtrise de la syntaxe — connaître la bonne incantation de fonctions fenêtre ou la bonne syntaxe Jinja pour un modèle incrémental — cette valeur est commoditisée. Ce qui reste, c’est le jugement qui détermine si le code doit exister en premier lieu, où il s’inscrit dans le système, et qui est responsable quand il produit des résultats erronés.
Implications
Pour les praticiens : la pensée architecturale — comprendre pourquoi le pattern en trois couches existe, choisir insert_overwrite vs merge pour les bonnes raisons — est la compétence moins commoditisée.
Pour les organisations : la valeur a changé de « les personnes qui peuvent écrire des transformations » à « les personnes qui décident quelles transformations devraient exister et qui est responsable quand elles cassent ». Le jugement architectural se développe à travers des années de construction, de casse et de correction de systèmes. Il n’apparaît pas automatiquement chez les praticiens embauchés uniquement pour leurs compétences SQL, et il ne se transfère pas depuis les outils IA.