- Avec l’automatisation par l’IA de l’écriture du code et de la génération de pipelines, le cœur de l’ingénierie des données se déplace : il ne s’agit plus simplement de déplacer des données, mais de traiter leur signification (meaning)
- La structure ETL (Extract, Transform, Load) traditionnelle ne parvient pas à préserver le sens des données, et un nouveau framework, ECL (Extract, Contextualize, Link), émerge pour la remplacer
- ECL structure le sens après l’extraction des données grâce à la contextualisation (Contextualize) et à la liaison (Link), afin de construire des pipelines centrés sur le sens combinant l’IA et le jugement humain
- Les contrats de données (Data Contract), les pipelines de Contextualize et le Context Store en sont les composants clés, pour maintenir la fiabilité des données et la cohérence du sens
- À l’avenir, l’ingénieur data devra évoluer : non plus simple constructeur de pipelines, mais « Context Architect », autrement dit architecte du sens des données
Les limites de l’ère ETL et le tournant à venir
- ETL (Extract, Transform, Load) était une structure conçue à l’origine pour déplacer les données entre systèmes, afin de résoudre les problèmes d’incompatibilité de formats et de silos
- Mais l’étape de Transform enfouissait les règles métier dans le code, rendant leur gestion difficile et imposant de modifier tout le pipeline à chaque changement de définition
- Avec l’automatisation de la génération de code par l’IA, les simples opérations de transformation ne constituent plus un facteur de différenciation
- L’essence de l’ingénierie des données se redéfinit : non plus déplacer la donnée, mais traiter son sens
ECL — Extract, Contextualize, Link
- Extract reste indispensable, et exige des arbitrages architecturaux autour de la fiabilité des données, de la latence, du volume ou encore des modes de défaillance
- Contextualize est le processus qui attribue un sens aux données : l’IA prend en charge la définition des champs, la classification des entités et l’inférence des relations, puis l’humain valide
- Exemple : la définition de « revenue » varie selon les départements, ou la signification d’une valeur null diffère d’un système à l’autre
- Link est le processus qui relie les entités issues de systèmes différents pour rendre le sens transportable
- Relier des fiches clients, des données utilisateurs ou des logs d’événements permet d’assurer une cohérence contextuelle
Early Binding — des contrats de données exécutables
- Early Binding consiste à expliciter le sens dès le moment où la donnée est produite, via un contrat de données (Data Contract)
- Ce contrat précise le schéma, les attentes de qualité, la propriété et le sens des champs
- Il ne doit pas s’agir d’une simple documentation, mais de contraintes exécutables (Executable Constraint) définissant explicitement le moment de l’échec
- Cela inclut des validations automatisées, comme l’échec du pipeline en cas de changement de schéma ou des alertes en cas de non-respect de la qualité
- Dans un environnement IA, l’ambiguïté d’un contrat s’amplifie en erreurs à grande échelle, d’où la nécessité de contrats clairs
Les limites de l’Early Binding
- Dans une architecture Medallion (Bronze–Silver–Gold), le sens des données se perd progressivement à mesure qu’elles circulent
- La couche Gold est un résultat optimisé pour certaines questions, et le sens d’origine peut s’en trouver altéré
- L’Early Binding seul ne suffit pas à empêcher l’érosion progressive du sens
- Pour compenser cela, un pipeline Contextualize est nécessaire
Late Binding — un pipeline Contextualize fondé sur des agents
- Le Late Binding repousse l’application des règles métier au moment de la requête, mais exigeait encore que les définitions existent à l’avance
- La nouvelle approche consiste à faire générer et valider dynamiquement les définitions elles-mêmes par un pipeline dédié
- Déclenchement automatique par triggers événementiels lors de l’arrivée d’un nouveau dataset ou d’un changement de schéma
- Des agents IA analysent la structure des données, des échantillons, des statistiques et la lineage pour en inférer le sens
- Un LLM-as-Judge approuve automatiquement les inférences à forte confiance, tandis que les éléments incertains sont examinés par des experts métier
- Les résultats validés sont stockés dans le Context Store, qui devient ensuite le point de référence sémantique pour toutes les IA et toutes les requêtes
Critères de choix entre Early et Late Binding
- Pour les données contrôlables au sein de l’organisation, l’Early Binding est adapté
- Les contrats peuvent être négociés et imposés, et la définition explicite du sens peut être maintenue
- Pour les données externes ou issues de sources non contrôlables, le Late Binding via un pipeline Contextualize est nécessaire
- Les changements de schéma et l’inférence du sens doivent pouvoir être automatisés
- Le critère central n’est pas la position dans l’organisation, mais l’existence ou non d’une responsabilité (accountability)
- S’il y a responsabilité, Early Binding ; sinon, Contextualize
- Grâce aux validations répétées, le sens découvert peut être promu au rang de contrat officiel
Context Propagation — une structure de relais plutôt qu’un pipeline
- Le contexte (Context) ne se déplace pas le long du pipeline de données : il se propage en parallèle via les métadonnées et la lineage
- L’Early Binding attache des métadonnées contractuelles à la source, puis les outils de lineage les transmettent à travers les étapes Bronze–Silver–Gold
- Le pipeline Contextualize lit cette lineage pour inférer le sens, puis stocke les résultats validés dans le Context Store
- Analogie avec Git : les données sont les fichiers commités, la lineage est le
git log, et le Context Store est l’historique versionné du sens
Context Store — une nouvelle surface d’ingénierie
- Le Context Store est un dépôt des définitions métier, non pas sous forme de wiki, mais sous forme d’artefacts versionnés et validés
- Les conflits de définition autour de « revenue » y sont résolus par un processus fondé sur le niveau de confiance
- Il constitue un point clé de la fiabilité des données, permettant de détecter et de corriger les données dont le sens a été altéré
- Pour garantir la fiabilité des données générées et consommées par l’IA, la gestion du Context Store et la conception des workflows de validation deviennent essentielles
- Les questions de propriété interne, d’arbitrage des conflits et de procédure de promotion du sens restent encore expérimentales
Le nouvel ingénieur data — Context Architect
- L’ingénieur data de demain aura pour mission de concevoir l’architecture du sens
- Conception des contrats, mise en place de l’infrastructure de lineage, gestion du pipeline Contextualize et du Context Store
- Décider quand le sens doit être explicite et quand il doit être découvert
- Au-delà du rôle technique, il jouera aussi un rôle de coordinateur en concevant le partage du sens et les structures de responsabilité entre organisations
- C’est pourquoi l’intitulé « Context Architect » semble plus approprié que celui de « data engineer »
Une frontière encore ouverte
- ECL n’est pas une méthodologie achevée, mais une direction, et les outils comme les modèles de gouvernance associés restent en cours d’évolution
- Les organisations qui traiteront les contrats comme une infrastructure exécutable et géreront la lineage et le Context Store comme des actifs d’ingénierie centraux définiront probablement les standards de l’ingénierie des données pour les dix prochaines années
- Même à l’ère de l’IA, le domaine que l’humain doit continuer d’assumer est celui de l’architecture et des arbitrages,
et sa forme concrète apparaît désormais à travers ECL et le rôle de Context Architect
Aucun commentaire pour le moment.