SÉRIE — LES COUCHES DE L'IA · 01 / 06 — DONNÉES
Trois semaines à comparer XGBoost et LightGBM. Des nuits entières à régler des hyperparamètres. Zéro heure passée à vérifier si la feature « chiffre d'affaires des trente derniers jours » est calculée de la même manière en entraînement et en production. Ce décalage silencieux porte un nom — le training-serving skew — et il fait partie des bugs les plus coûteux du machine learning moderne. Le modèle performe en évaluation, dégrade en production, et personne ne comprend pourquoi. Parce que personne n'a regardé la couche d'en dessous.
Avant les algorithmes, avant les GPU, avant les transformers, il y a les données. Leur schéma, leur fraîcheur, leur cohérence entre sources. Une donnée brute n'est pas une information : c'est un signal, dont la valeur dépend entièrement de l'infrastructure qui l'a produite, transformée, stockée et servie. La qualité de ce socle détermine l'utilité de tout ce qui s'y construit. Un modèle de deep learning sur données médiocres apprend les erreurs avec une précision redoutable. Un clustering rudimentaire sur données propres identifie des structures réelles. C'est ce socle de données, précisément parce qu'il est invisible, qui mérite d'être examiné en premier — il conditionne toutes les techniques que la suite de la série explore.
La matière première : structurées, non-structurées, semi-structurées
Toute conversation sur les données pour l'IA commence par une typologie qu'on entend beaucoup et qu'on définit peu. Les données structurées sont celles que l'on range dans des tables : colonnes typées, contraintes, clés étrangères. C'est le terrain historique des entrepôts de données — comptabilité, transactions, relevés de capteurs, journaux d'événements normalisés. La plupart des modèles de machine learning classique vivent ici.
Les données non-structurées forment la masse silencieuse : textes, images, sons, vidéos, fichiers PDF, conversations clients, contenus web bruts. Elles ne se rangent pas dans des colonnes ; on y accède par fichier, par identifiant ou par embedding vectoriel. Les LLM, les modèles de vision et les systèmes de reconnaissance vocale puisent tous dans cette catégorie.
Entre les deux, les données semi-structurées dominent la réalité opérationnelle des pipelines modernes : JSON d'API, événement Avro publié sur Kafka, fichier Parquet exporté par un job Spark, document XML d'un partenaire. Ni rigides ni amorphes, elles imposent leurs propres règles d'interprétation. Choisir une architecture de stockage revient à choisir comment on accueille ces trois types dans la même maison.
Warehouse, lake, lakehouse : trois silos, une convergence
Le data warehouse est l'aîné. Il fonctionne en schema-on-write : la structure est définie et validée avant tout chargement. Toute donnée entrante doit se conformer au schéma cible. Requêtes SQL rapides, prévisibles, transactionnelles ; en contrepartie, modifier un schéma coûte cher et toute donnée hors grille est perdue. Snowflake, Amazon Redshift et Google BigQuery en sont les représentants modernes.
Le data lake a inversé le problème. Stockage brut sur object storage — S3, Azure Data Lake Storage, Google Cloud Storage — au format Parquet, JSON, Avro ou ORC, avec un schema-on-read appliqué uniquement au moment de la requête. Tout entre, rien n'est rejeté. Le revers porte un nom évocateur : le data swamp. Sans gouvernance, le lac devient un marécage où les données existent mais où personne ne sait lesquelles sont fiables, fraîches ou correctement labellisées.
Le lakehouse est la synthèse adoptée par l'industrie depuis 2022. Object storage à la base, formats de table ouverts par-dessus — Apache Iceberg v3 en preview publique chez Databricks depuis juin 2025, avec Row Lineage natif et Deletion Vectors, et Delta Lake comme alternative mature. Garanties ACID, gouvernance unifiée, accès SQL et ML dans la même architecture. Signal marché difficile à ignorer : Databricks a acquis Tabular, fondé par les créateurs d'Iceberg, en juin 2024 pour un montant estimé à plusieurs milliards de dollars selon plusieurs sources sectorielles.
| Data Warehouse | Data Lake | Lakehouse | |
|---|---|---|---|
| Schéma | schema-on-write | schema-on-read | les deux |
| Données | structurées | toutes | toutes (gouvernées) |
| ACID | oui | non natif | oui (Iceberg, Delta) |
| Usage | BI, reporting SQL | data science, ML | SQL + ML + streaming |
| Risque | rigidité | data swamp | complexité initiale |
ETL est mort, vive l'ELT (et dbt)
Pendant deux décennies, la chaîne canonique a été l'ETL : Extract depuis les sources, Transform dans un middleware dédié — Informatica, Talend, SSIS — puis Load dans un entrepôt déjà propre. Ce modèle a été conçu pour des entrepôts on-premise au compute limité, où transformer en amont coûtait moins cher que dans la base.
L'arrivée des entrepôts cloud à compute élastique — Snowflake, BigQuery, Redshift — a renversé l'équation. Transformer directement dans l'entrepôt devient plus rapide et moins cher qu'un middleware externe. Les données brutes sont disponibles immédiatement après chargement, ce qui débloque les data scientists. Les transformations peuvent être itérées sans rechargement des sources. Le modèle ELT — Extract, Load, Transform — supplante l'ETL sur la quasi-totalité des projets nouvellement bâtis.
L'outil emblématique de cette bascule est dbt. Il transforme du SQL en pipeline versionné, testé, documenté comme du code. Les documents de dbt Labs, mis à jour en avril 2026, le formulent sans détour : « dbt is not a loader — it enters after extractors and loaders have funneled sources into a warehouse. » dbt n'extrait pas, ne charge pas, il transforme — et c'est précisément ce qui en fait un standard.
dbt entre en scène après que les extracteurs ont chargé les données brutes. Il ne charge pas — il transforme.
Au-dessus de la transformation, l'orchestration. Apache Airflow 3.0, publié en 2025, introduit un nouveau airflow.sdk qui découple l'écriture des DAG des internals de la plateforme, via une Task Execution API qui rend les pipelines compatibles avec une architecture orientée services. Pour les pipelines de streaming, Apache Kafka reste le standard de fait, couplé à Apache Iceberg comme format de table cible. Une nuance utile pour les projets on-premise à petit volume : l'ETL classique reste pertinent. La règle n'est pas « ELT toujours », c'est « ELT par défaut quand le compute est élastique ».
Le feature store : la mémoire du ML
Sans feature store, chaque équipe ML qui a besoin de la feature « chiffre d'affaires des trente derniers jours » la recalcule à sa façon. L'une la calcule en jours calendaires, l'autre en jours ouvrés. L'une exclut les retours, l'autre non. Deux modèles entraînés sur la même donnée nominale produisent des résultats incohérents, et le bug se loge précisément là où personne ne regarde.
Le pire n'est pas l'incohérence entre équipes. C'est l'incohérence entre l'entraînement et la production d'un même modèle. En entraînement, la feature est calculée en batch sur l'historique. En production, elle est recalculée à l'inférence, parfois avec une fenêtre temporelle légèrement différente, parfois avec un filtre absent. Le modèle prédit alors sur une réalité qu'il n'a jamais apprise. C'est le training-serving skew, et il dégrade silencieusement, sans alerte. Seules les métriques de production finissent par trahir le décalage — souvent trop tard.
Un feature store centralise le calcul, le stockage et la récupération des features ML. Son architecture est duale par nécessité. Un offline store, sur Parquet ou Iceberg, sert l'entraînement batch et l'analyse historique ; un online store — Redis, DynamoDB, RonDB — sert l'inférence en temps réel avec un objectif de latence sous les dix millisecondes. La même définition de feature alimente les deux, ce qui élimine mécaniquement le skew. Les benchmarks publiés par Hopsworks à SIGMOD 2024 mesurent un facteur 10 à 45 entre DuckDB couplé à ArrowFlight et un accès JDBC/ODBC traditionnel pour la récupération de données d'entraînement.
Trois acteurs structurent le marché 2024-2026. Feast, projet open source hébergé par la Linux Foundation, se branche sur Snowflake, BigQuery, Redshift et un online store Redis. Tecton, plateforme managée d'entreprise, vise les applications critiques temps réel. Hopsworks propose une pile tout-en-un — offline, online et base vectorielle — déployable on-premise pour les cas d'usage réglementés.
Un algorithme amplifie la qualité des données. Il ne la compense pas.
Six dimensions de qualité — et la lignée qui prouve d'où ça vient
La littérature praticienne et académique converge depuis longtemps sur six dimensions canoniques de la qualité des données. Une étude ArXiv de juin 2024 les recense formellement : completeness (proportion de valeurs non-null dans les champs critiques), accuracy (conformité des valeurs à la réalité), consistency (cohérence entre systèmes sources), timeliness (fraîcheur, données pas obsolètes), uniqueness (absence de doublons), validity (conformité au type et au format attendu). Chaque dimension défaillante a un impact ML précis : completeness manquante introduit un biais de sélection ; accuracy défaillante apprend des patterns faux ; timeliness dégradée fait prédire le passé.
L'argument n'est pas seulement théorique. Une étude empirique publiée dans Information Systems en 2025 teste ces six dimensions sur dix-neuf algorithmes de machine learning — classification, régression, clustering. Sous le scénario S0, qui simule un biais systématique aligné sur les six dimensions dégradées, la performance moyenne tombe à 15,55%. Sur tous les algorithmes, sans exception. La conclusion empirique est nette : la qualité des données est le déterminant principal de la performance ML, avant même le choix de l'algorithme. Le vieil adage garbage in, garbage out n'est pas un slogan folklorique : c'est une mesure.
Connaître la qualité d'une donnée est une chose. Savoir d'où elle vient en est une autre. Le data lineage — la lignée de données — est la capacité à tracer l'origine, les transformations et les consommations d'une donnée depuis sa source jusqu'à son utilisation finale. Trois granularités existent : job-level (quel pipeline a lu et écrit quel dataset), column-level (quelle colonne source alimente quelle colonne cible), feature-level (quelle feature ML dérive de quelles données brutes — la plus précieuse pour l'audit).
En 2026, ce n'est plus optionnel. L'EU AI Act, entré en vigueur le 1er août 2024, devient pleinement applicable le 2 août 2026 : les systèmes d'IA classés haut-risque doivent documenter et tracer leurs données d'entraînement, dans une classification en six catégories exigée par la Commission européenne depuis janvier 2025. L'Opinion 28/2024 de l'EDPB, publiée en décembre 2024, va plus loin : les LLM entraînés sur des données personnelles sont, dans la majorité des cas, soumis au RGPD. Sans lineage, ni le droit à l'explication ni le droit à l'oubli ne sont techniquement adressables.
L'EU AI Act pose une question simple : d'où vient chaque donnée qui a servi à entraîner votre modèle ? Sans lineage, vous ne pouvez pas répondre.
Côté outils, OpenLineage, hébergé par la Linux Foundation, s'est imposé comme le standard ouvert de collecte de lineage, avec Marquez comme implémentation de référence. DataHub, plateforme metadata issue de LinkedIn, ajoute la recherche et la curation assistée. Au-delà de la conformité, le bénéfice opérationnel est immédiat : retrouver la source d'une dégradation dans un pipeline qui enchaîne cinquante transformations passe de cinq jours à cinq minutes.
Du brut au prêt-à-l'emploi : pipeline ETL/ELT vers feature store — la chaîne que personne ne voit, et que tout modèle suppose parfaite.
Pourquoi cette couche est invisible — et critique
L'invisibilité n'est pas un défaut de communication. Elle est structurelle, et tient à cinq mécanismes distincts.
Premier mécanisme : les pipelines data sont en amont. Le data scientist voit le dataset final, pas les quinze transformations qui l'ont produit. Les erreurs de qualité — un cast manqué, une colonne renommée, une jointure qui perd cinq pour cent des lignes — sont silencieuses et ne se détectent qu'à l'aval, parfois après plusieurs cycles de modélisation.
Deuxième mécanisme : le data swamp. Dans une organisation sans gouvernance, le data lake accumule des fichiers dont personne ne connaît la fraîcheur, la source ni la fiabilité. On sait qu'ils sont là ; on ne sait pas si l'un d'entre eux vaut quelque chose. Les data scientists travaillent alors sur les sources qu'ils ont apprises à reconnaître, ce qui crée des poches d'expertise locales et des angles morts collectifs.
Troisième mécanisme : le training-serving skew. Sans feature store qui centralise le calcul, l'écart entre comment une feature est produite en entraînement et comment elle est servie en production existe presque toujours. Il dégrade les performances sans déclencher d'alerte, parce qu'aucune métrique de pipeline ne mesure cette différence — c'est une question d'invariant entre deux mondes qui ne se parlent que par le modèle.
Quatrième mécanisme : la freshness silencieuse. Un pipeline qui cesse de recevoir des données nouvelles ne génère pas d'erreur — il continue de servir la dernière version connue. Le modèle prédit alors sur des signaux périmés, et le monitoring de fraîcheur n'est presque jamais un réflexe natif. Il faut le construire, le tester, l'alerter.
Cinquième mécanisme : le coût caché. Gartner identifie régulièrement la mauvaise qualité de données parmi les sources de pertes les plus importantes pour les organisations. Le chiffre exact compte moins que la régularité du constat, qui revient sous des formes voisines depuis plus d'une décennie.
Sans données fiables, les algorithmes ne sont que du bruit appliqué à du bruit. Les rendre visibles — les instrumenter, les gouverner, les tracer — est le premier travail de toute initiative IA sérieuse. Tout ce que cette série explore ensuite suppose ce socle propre. Si la donnée ment, l'algorithme ment avec elle, quel que soit son degré de sophistication.
Une question, un projet IA ?
Vous explorez une architecture, évaluez un modèle ou planifiez un déploiement — échangeons sur votre contexte.
Prendre contact →