Plateformes de données pour l'IA : lakehouse, warehouse et feature stores

Un modèle d'intelligence artificielle ne vaut que par les données qui l'alimentent. Cette évidence, souvent répétée, cache une réalité plus concrète : avant même qu'un algorithme n'entre en jeu, il faut une infrastructure capable de stocker, nettoyer, versionner et servir des volumes considérables d'information, au bon format et au bon moment. C'est le rôle des plateformes de données. En trois décennies, ces plateformes ont évolué du data warehouse rigide au data lake tentaculaire, puis au lakehouse qui réconcilie les deux mondes — et, plus récemment, au feature store qui fait le lien direct avec les projets d'apprentissage automatique. Cet article propose une lecture de fond de ces catégories d'architecture : ce qu'elles font, pourquoi elles existent, comment elles s'articulent, et ce qu'elles impliquent pour les équipes data et les décideurs qui bâtissent leurs cas d'usage IA.

Nous avancerons du général au concret. D'abord la trajectoire historique — comment on est passé de l'entrepôt à l'architecture ouverte. Ensuite l'anatomie du lakehouse et de ses formats de tables. Puis l'organisation interne des données avec l'architecture en médailles, les pipelines qui les transportent, et le feature store qui sert les modèles. Nous terminerons par les grands paradigmes organisationnels — data mesh et data fabric — et par les critères de choix qui comptent vraiment. Chaque affirmation technique s'appuie sur une source vérifiable, et lorsque les points de vue divergent, nous le disons plutôt que de trancher artificiellement.

Du data warehouse au lakehouse : trente ans d'architectures

Comprendre le paysage actuel suppose de retracer les grandes étapes qui ont façonné les architectures de données. En trois décennies, la discipline est passée d'entrepôts fermés à des écosystèmes ouverts capables d'alimenter des modèles d'apprentissage en quasi-temps réel. Chaque génération a résolu un problème précis et en a créé de nouveaux. Cette progression n'est pas une simple succession de modes : elle répond à des contraintes réelles de volume, de coût, de variété des données et, plus récemment, aux besoins spécifiques de l'IA.

L'ère du data warehouse : structuration et performance SQL

Le data warehouse (entrepôt de données) a dominé la gestion analytique pendant une vingtaine d'années, à partir des années 1990. Le principe est resté simple et remarquablement robuste : des données structurées sont chargées, via des traitements ETL (Extract, Transform, Load), dans un schéma relationnel optimisé pour les requêtes SQL. Ce modèle offre des performances élevées sur les données tabulaires. Les équipes de business intelligence y produisent des rapports fiables et reproductibles, avec une gouvernance forte : chaque colonne a un type, chaque table un propriétaire, chaque transformation une trace.

La contrepartie tient en un mot : la rigidité. Tout changement de schéma demande un travail conséquent, planifié à l'avance. Les données non structurées — textes libres, images, journaux applicatifs, signaux de capteurs — restent hors du périmètre. Historiquement, l'infrastructure était installée localement, dans les salles serveurs de l'entreprise, avec des coûts matériels et des licences propriétaires élevés. L'entrepôt excelle tant que les données restent prévisibles et volumétriquement maîtrisées ; il montre ses limites dès que la variété et le volume explosent. C'est précisément ce qui s'est produit au tournant des années 2010.

Le data lake : stockage brut et promesses en demi-teinte

L'essor du volume de données a poussé les organisations vers le data lake (lac de données). L'écosystème Apache Hadoop, puis le stockage objet dans le cloud, ont permis de conserver des pétaoctets de données brutes — structurées ou non — sur du matériel standard, à un coût de stockage bien inférieur à celui d'un entrepôt. La promesse était séduisante : tout stocker d'abord, analyser ensuite. On sépare le stockage, devenu bon marché, du calcul, mobilisé à la demande.

La réalité s'est révélée plus nuancée. Sans gouvernance rigoureuse, un lac de données se transforme en data swamp (marécage de données), où plus personne ne retrouve ce qu'il cherche. Les métadonnées manquent, la qualité se dégrade, et les performances des requêtes analytiques restent en retrait par rapport à un entrepôt. Surtout, le data lake classique n'offre pas de transactions ACID — atomicité, cohérence, isolation, durabilité —, ces garanties qui assurent qu'une écriture concurrente ne corrompt pas les données. Deux traitements simultanés pouvaient laisser une table dans un état incohérent. Les entreprises se retrouvaient donc avec deux systèmes en parallèle : un lac pour la science des données, un entrepôt pour la BI, avec des copies de données synchronisées entre les deux. Coûteux, lent, source d'incohérences.

La faiblesse structurelle des architectures à deux étages tient à la duplication permanente : les mêmes données vivent dans le lac et dans l'entrepôt, avec un décalage temporel et un risque d'incohérence à chaque synchronisation. C'est ce défaut fondamental que la génération suivante s'est attachée à résoudre.

L'émergence du lakehouse : réconcilier les deux mondes

Le concept de lakehouse a été formalisé dans un article de recherche présenté à la conférence CIDR en 2021, signé par Michael Armbrust et ses coauteurs, sous le titre « Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics ». L'idée est directe : fusionner le faible coût et l'ouverture du data lake avec les garanties transactionnelles, la gouvernance et la performance SQL du data warehouse, le tout sur une seule couche de stockage. Fini les deux systèmes en parallèle : une architecture unique sert à la fois la BI et l'apprentissage automatique, sur les mêmes données.

La brique technique qui rend cela possible s'appelle le format de table ouvert. Delta Lake, décrit dans un article publié à la conférence VLDB en 2020, ajoute une couche transactionnelle au-dessus de fichiers Parquet stockés dans un espace objet cloud. Un journal de transactions, compacté au format Parquet, apporte les propriétés ACID, le time travel (la possibilité d'interroger une version antérieure de la table), l'application du schéma et des opérations de métadonnées rapides sur de très grandes tables. Apache Iceberg et Apache Hudi apportent des réponses voisines, avec des choix d'ingénierie différents. Résultat : on exécute des requêtes SQL performantes directement sur le lac, sans dupliquer les données dans un entrepôt séparé.

Période indicative	Architecture	Apport majeur	Limite principale
Années 1990-2010	Data warehouse	Schéma relationnel, SQL performant, gouvernance forte	Rigidité du schéma, données non structurées exclues
Années 2010-2018	Data lake	Stockage brut à faible coût, tout format, calcul séparé	Absence d'ACID, gouvernance faible, risque de marécage
Depuis 2018-2020	Lakehouse	Formats ouverts avec ACID, une seule plateforme pour BI et ML	Intégration multi-moteurs à orchestrer, maturité outillage

Cette convergence a simplifié les pipelines et rapproché les métiers : ingénieurs data et scientifiques des données travaillent désormais sur une même plateforme, avec les mêmes données, sans silos. Le lakehouse a aussi ouvert la voie au traitement en flux (streaming), c'est-à-dire l'ingestion et l'analyse de données en continu, une capacité que ni les entrepôts classiques ni les lacs Hadoop ne proposaient nativement. La distinction entre traitement par lots et traitement en flux tend d'ailleurs à s'estomper : la même table de lakehouse peut recevoir des écritures en continu et être interrogée en batch.

Anatomie d'un lakehouse : couches, formats, moteurs

Derrière le terme lakehouse se cache une pile logicielle organisée en couches distinctes, chacune assurant une fonction précise. Comprendre cette décomposition aide à évaluer une architecture, à repérer les dépendances et à anticiper les points de vigilance. On peut décrire un lakehouse en quatre strates superposées.

• La couche de stockage — un espace objet cloud, peu coûteux et pratiquement illimité, qui conserve les fichiers physiques (le plus souvent au format colonnaire Parquet). C'est le socle. Les données y résident une seule fois.
• Le format de table — Delta Lake, Apache Iceberg ou Apache Hudi. Cette couche logique transforme un ensemble de fichiers en une table transactionnelle, avec un journal des versions, l'application du schéma, l'évolution des partitions et les propriétés ACID.
• Le moteur de calcul — le composant qui lit et écrit les données pour répondre aux requêtes : SQL analytique, transformations distribuées, entraînement de modèles. Plusieurs moteurs peuvent lire la même table, ce qui est l'un des atouts majeurs des formats ouverts.
• Le catalogue et la gouvernance — la couche qui recense les tables, gère les droits d'accès (au niveau ligne et colonne), trace le lignage des données et documente les métadonnées. Sans elle, un lakehouse redevient rapidement un marécage.

Le rôle central du format de table ouvert

Le format de table est le cœur de l'affaire. Il détermine la portabilité des données et le degré d'ouverture de l'architecture. Trois formats dominent la conversation technique, avec des philosophies distinctes, comme le détaillent plusieurs analyses comparatives publiées par des acteurs du secteur : Onehouse (2025) et Dremio (2023).

Format ouvert	Approche caractéristique	Point fort mis en avant
Apache Iceberg	Standard piloté par une spécification que n'importe quel moteur peut implémenter	Interopérabilité multi-moteurs, évolution de schéma et de partition, adoption large
Delta Lake	Couche de lakehouse historiquement liée au moteur Spark	Intégration profonde avec Spark, journal de transactions éprouvé, time travel
Apache Hudi	Système complet de gestion, avec ingestion, compaction et nettoyage intégrés	Traitement incrémental, mises à jour ligne à ligne, capture de changements (CDC)

Ces trois formats ne s'opposent pas frontalement : ils occupent des créneaux qui se recoupent. Iceberg s'est imposé comme un langage commun de l'interopérabilité, au point que des plateformes reposant sur d'autres formats exposent souvent leurs données en Iceberg pour permettre l'accès depuis plusieurs moteurs. Hudi excelle sur les charges à fortes mises à jour et sur la capture de changements en continu. Delta Lake conserve une intégration Spark très aboutie. L'approche pragmatique qui émerge consiste à choisir le format adapté à chaque charge de travail et à faire le pont entre eux plutôt qu'à imposer un format unique à toute l'organisation.

Un point mérite d'être souligné pour les décideurs : le choix du format de table est structurant pour la réversibilité de l'architecture. Des données conservées dans un format ouvert restent lisibles par de multiples moteurs et migrables vers un autre environnement sans réécriture massive. Un format propriétaire, à l'inverse, lie plus étroitement les données à un fournisseur donné. Ce critère, souvent relégué au second plan derrière la performance brute, pèse lourd sur le coût total à moyen terme et sur la liberté de négociation.

Séparation du stockage et du calcul : le principe qui change tout

Une caractéristique commune aux architectures modernes mérite une explication détaillée, car elle conditionne à la fois les performances et le modèle de coût : la séparation du stockage et du calcul. Dans un entrepôt traditionnel, les deux étaient couplés : ajouter de la puissance de calcul supposait souvent d'ajouter du stockage, et inversement. Les plateformes actuelles dissocient ces deux dimensions. Les données reposent dans l'espace objet, à un coût faible et stable. Les ressources de calcul, elles, se provisionnent à la demande, montent en charge pour une requête lourde, puis se libèrent.

Les bénéfices sont concrets. On peut faire tourner plusieurs charges de travail indépendantes sur les mêmes données sans qu'elles se gênent : un tableau de bord BI, un entraînement de modèle et une transformation par lots peuvent lire la même table simultanément. On ne paie le calcul que lorsqu'on l'utilise. Et l'on dimensionne finement chaque charge selon ses besoins réels. Le revers, à surveiller, est que cette élasticité peut conduire à une consommation mal maîtrisée si aucun garde-fou n'est posé : une ressource de calcul laissée active sans usage continue de coûter. La bonne pratique consiste à suivre la consommation par équipe et par charge, et à activer les mécanismes d'arrêt automatique.

L'architecture en médailles : bronze, argent, or

Stocker des données dans un lakehouse ne suffit pas : encore faut-il les organiser pour qu'elles gagnent en qualité et en valeur au fil de leur traitement. Le motif de conception le plus répandu pour cela s'appelle l'architecture en médailles (medallion architecture), popularisé par Databricks et documenté par Microsoft Learn. Il structure les données en trois couches successives — bronze, argent, or —, chacune améliorant progressivement la structure et la fiabilité de l'information.

Trois couches, une progression de qualité

Le principe est celui d'un raffinage graduel. On ne nettoie pas tout d'un coup ; on fait progresser la donnée par étapes, en conservant à chaque niveau une trace exploitable.

• La couche bronze (données brutes) — c'est le point d'atterrissage. On y dépose les données telles qu'elles arrivent des systèmes sources, sans transformation, en ajoutant seulement des métadonnées techniques : date de chargement, identifiant du traitement, système d'origine. Cette couche préserve l'historique intégral et permet de tout rejouer en cas de besoin.
• La couche argent (données validées) — les données y sont nettoyées, dédupliquées, conformées et reliées entre sources. On obtient une vue d'entreprise cohérente, exploitable pour l'analyse exploratoire et pour préparer l'apprentissage automatique. C'est le point d'entrée privilégié des analystes et des scientifiques des données.
• La couche or (données enrichies) — elle contient des agrégats métier et des tables prêtes à l'emploi pour les tableaux de bord, le reporting et l'entraînement des modèles. C'est le niveau consommé directement par les décideurs et les applications.

L'intérêt de ce découpage n'est pas seulement esthétique : il donne à chaque équipe un point d'entrée clair selon son besoin, il rend chaque transformation traçable, et il permet de reconstruire les couches supérieures à partir des couches inférieures si une règle change. On corrige une erreur en argent sans jamais perdre le brut de bronze.

Cette organisation favorise la réutilisation, la gouvernance et la performance. Elle garantit aussi que les propriétés ACID s'appliquent à mesure que les données traversent les validations et transformations successives, avant d'être rangées dans une disposition optimisée pour l'analyse. Pour une équipe qui bâtit ses premiers pipelines de qualité, l'architecture en médailles offre un cadre méthodique éprouvé, indépendant du fournisseur.

Les pipelines de données : ETL, ELT et flux continu

Faire circuler les données entre ces couches est le travail des pipelines de données. Deux grandes approches coexistent, et leur nuance a des conséquences pratiques réelles. Dans le schéma ETL (Extract, Transform, Load), on transforme les données avant de les charger dans la destination. Dans le schéma ELT (Extract, Load, Transform), on charge d'abord les données brutes, au plus près de leur forme d'origine, puis on applique les transformations à l'intérieur de la plateforme cible. L'ELT a gagné du terrain avec le lakehouse, précisément parce que le stockage bon marché permet de conserver le brut et de transformer à la demande.

Ces pipelines sont bien davantage qu'un simple tuyau. Les ingénieurs data y intègrent le nettoyage, la validation, la standardisation et la préparation des variables (features) qui alimenteront les modèles. La qualité des données produites conditionne directement la fiabilité des modèles en aval : un modèle est fondamentalement limité par la qualité des données sur lesquelles il apprend. Un pipeline ELT rigoureux, qui documente ses transformations et applique des règles de qualité automatiques à chaque ingestion, constitue donc une fondation aussi importante que l'algorithme lui-même.

À côté du traitement par lots, le traitement en flux continu (streaming) traite les événements au fil de l'eau, quelques secondes après leur production. Détection d'anomalies sur des transactions, mise à jour de tableaux de bord opérationnels, alimentation de modèles temps réel : les cas d'usage se multiplient. Les plateformes de lakehouse modernes unifient de plus en plus ces deux modes, si bien qu'une même table peut être écrite en continu et lue par lots. Cette convergence simplifie l'architecture : on cesse de maintenir deux chaînes de traitement distinctes pour les mêmes données.

Le feature store : le pont entre données et modèles

Nous abordons ici le composant le plus directement lié aux projets d'apprentissage automatique, et souvent le moins bien compris : le feature store (magasin de variables). Là où le lakehouse gère les données au sens large, le feature store gère spécifiquement les features — les variables calculées qui servent d'entrées aux modèles. Sa raison d'être découle d'un problème récurrent et coûteux de l'apprentissage automatique en production.

Pourquoi un magasin dédié aux variables

Une feature est une donnée transformée, prête à être consommée par un modèle : la moyenne des achats d'un client sur trente jours, le nombre de connexions dans la dernière heure, la catégorie encodée d'un produit. Ces variables sont calculées par des pipelines, souvent complexes. Le problème surgit lorsque la même variable doit être disponible à deux moments très différents : pendant l'entraînement du modèle (sur un large historique, par lots) et pendant l'inférence en production (sur une donnée fraîche, à faible latence, à la requête).

Un feature store est, selon la définition qu'en donnent Databricks et l'écosystème Feast, un système centralisé qui gère, stocke et sert les variables à la fois pour l'entraînement et pour l'inférence temps réel, en garantissant cohérence, réutilisabilité et gouvernance. Il s'organise typiquement en deux composants complémentaires.

• Le magasin hors-ligne (offline store) — une base optimisée pour le traitement par lots de gros volumes historiques. Il alimente l'entraînement des modèles avec des séries longues de variables, cohérentes dans le temps.
• Le magasin en ligne (online store) — une base à très faible latence qui sert les variables au moment de l'inférence, avec des garanties de fraîcheur et un lignage relié à un registre central. C'est ce qui permet à un modèle de répondre en quelques millisecondes en production.

Le fléau du décalage entraînement-service

Le bénéfice décisif du feature store tient à la lutte contre un problème redouté : le décalage entraînement-service (training-serving skew). Ce phénomène survient lorsque la logique de calcul d'une variable diffère entre l'environnement d'entraînement et l'environnement de production. Le modèle a appris sur une définition de la variable, mais il reçoit en production une variable calculée différemment. Les conséquences sont sévères et difficiles à diagnostiquer : le modèle qui semblait excellent en test se dégrade silencieusement une fois déployé.

Le décalage entraînement-service est l'un des problèmes les plus insidieux de l'apprentissage automatique en production, précisément parce qu'il ne provoque aucune erreur visible : le code s'exécute, les prédictions arrivent, mais leur qualité s'effondre. Un feature store résout ce défaut à la racine en garantissant que la même logique de calcul sert dans les deux mondes.

En centralisant la définition des variables, le feature store assure que la logique employée à l'entraînement est identique à celle employée en service. C'est le cœur de sa valeur. Il apporte aussi la réutilisabilité : une variable définie une fois par une équipe peut être partagée avec d'autres, ce qui évite de recalculer les mêmes transformations dans chaque projet et harmonise les définitions à l'échelle de l'organisation. Selon les analyses de l'écosystème (Feast, Tacnode), les solutions de feature store les plus évaluées se distinguent par leur approche : certaines fournissent l'infrastructure à assembler soi-même, d'autres intègrent le calcul des transformations de bout en bout dans un service managé.

Le feature store dans la chaîne MLOps

Le feature store ne vit pas isolé : il s'inscrit dans une chaîne plus large, le MLOps (opérationnalisation de l'apprentissage automatique). Cette discipline applique aux modèles les principes d'ingénierie éprouvés du développement logiciel : versionnage, intégration continue, surveillance, réentraînement programmé. La logique de calcul des variables employée à l'entraînement doit être fidèlement reproduite dans le pipeline de production ; le feature store est le mécanisme qui garantit cette fidélité. Une chaîne MLOps robuste relie ainsi les pipelines de données, le feature store, l'entraînement, le déploiement et la surveillance en un cycle continu.

Pour une équipe qui débute, il n'est pas toujours nécessaire de déployer un feature store dès le premier projet. Un modèle unique, entraîné et servi par lots, peut s'en passer. Le feature store devient précieux dès lors que plusieurs modèles partagent des variables, que l'inférence temps réel entre en jeu, ou que le décalage entraînement-service commence à se manifester. C'est un investissement de maturité, à introduire au bon moment plutôt que par principe.

Data mesh et data fabric : organiser la donnée à l'échelle

Au-delà des briques techniques, les organisations doivent définir un paradigme pour organiser leurs données à grande échelle. Deux approches structurent la réflexion contemporaine : le data mesh et la data fabric. Elles ne s'opposent pas terme à terme ; elles répondent à des questions différentes — l'une d'organisation, l'autre d'intégration technique.

Le data mesh : décentraliser la responsabilité

Le data mesh a été formalisé en 2019 par Zhamak Dehghani, alors chez Thoughtworks. C'est avant tout une réponse organisationnelle à un problème d'échelle : lorsqu'une équipe data centrale devient le goulot d'étranglement de toute l'entreprise, il faut décentraliser sans perdre la cohérence. Le data mesh repose sur quatre principes, tels que Dehghani les a exposés dans son architecture logique publiée sur martinfowler.com.

• La propriété par domaine — chaque équipe métier (finance, marketing, logistique) est responsable de ses propres données, plutôt qu'une équipe centrale unique.
• La donnée traitée comme un produit — chaque jeu de données a des consommateurs, une qualité mesurée, une documentation et un niveau de service, exactement comme un produit logiciel.
• La plateforme en libre-service — une infrastructure commune permet aux équipes de domaine de créer, gérer et consommer leurs produits de données sans expertise technique lourde.
• La gouvernance fédérée — des standards partagés garantissent l'interopérabilité entre tous les produits de données, promus par un groupe de gouvernance transversal.

Le data mesh est donc une philosophie d'organisation avant d'être une technologie. Il convient particulièrement aux grandes structures dont les domaines métier sont déjà autonomes et matures. Sa mise en œuvre exige des prérequis organisationnels réels : des équipes data réparties par domaine, un parrainage de la direction et une discipline de standardisation. Appliqué de façon trop dogmatique à une organisation qui n'a pas ces fondations, il peut se révéler difficile à faire aboutir.

La data fabric : automatiser l'intégration

La data fabric prend le problème par l'autre bout. Plutôt que de décentraliser la responsabilité, elle centralise l'automatisation. C'est un concept d'architecture technique : une couche d'intégration qui relie automatiquement des données dispersées à travers les systèmes hétérogènes de l'entreprise. Sa clé de voûte est la métadonnée active — l'analyse continue de la façon dont les données sont réellement utilisées —, enrichie d'apprentissage automatique pour connecter les sources et automatiser la gouvernance. L'équipe data centrale reste responsable, mais elle est démultipliée par l'automatisation.

Les deux approches ne s'excluent pas. Le mesh répond à une question d'organisation et de responsabilité ; la fabric à une question d'intégration technique. Une même entreprise peut adopter les principes produits du data mesh tout en s'appuyant sur les automatismes d'une data fabric. Dans la pratique, les architectures les plus abouties combinent souvent un socle de lakehouse en formats ouverts, une gouvernance répartie par domaine inspirée du mesh, et une couche d'automatisation du catalogage et du lignage inspirée de la fabric.

Critère	Data mesh	Data fabric
Nature	Paradigme d'organisation	Architecture d'intégration technique
Philosophie	Décentralisation par domaine métier	Automatisation centralisée
Responsabilité des données	Répartie entre les domaines	Centrale, augmentée par l'automatisation
Pierre angulaire	La donnée comme produit	La métadonnée active
Prérequis dominant	Maturité et autonomie des équipes	Outillage et modélisation des métadonnées

Formats ouverts et interopérabilité : la tendance de fond

Une dynamique traverse l'ensemble de ces paradigmes : la montée en puissance des formats ouverts et de l'interopérabilité. La convergence autour d'Apache Iceberg comme langage commun d'échange en est le signe le plus visible : des plateformes qui reposent nativement sur d'autres formats exposent désormais leurs données en Iceberg pour permettre un accès depuis plusieurs moteurs. Des projets de traduction entre formats de tables permettent même de lire les mêmes fichiers sous plusieurs formats sans copie physique.

Cette tendance profite directement aux organisations. Elle réduit la dépendance à un fournisseur unique, stimule la concurrence, et rend les architectures multi-plateformes plus réalistes. Le débat n'est plus tant « quelle plateforme choisir » que « comment orchestrer plusieurs moteurs de manière cohérente sur des données communes ». Pour une équipe qui conçoit son architecture aujourd'hui, privilégier les formats ouverts dès le départ est le choix qui préserve le mieux la liberté future.

Pourquoi l'infrastructure data conditionne les projets IA

Revenons au point de départ : le lien entre plateforme de données et projets d'intelligence artificielle. Ce lien est direct et souvent sous-estimé. Un projet IA qui cale bute rarement sur l'algorithme — ceux-ci sont matures, documentés et largement accessibles. Il bute sur l'amont : la qualité, l'accessibilité, la fraîcheur et la traçabilité des données qui l'alimentent. L'infrastructure data n'est pas un décor : c'est le facteur déterminant.

Ce que l'IA attend concrètement des données

Un modèle d'apprentissage a besoin de données répondant à quelques exigences fondamentales, qui recoupent directement les fonctions assurées par les plateformes décrites plus haut.

• La qualité — des données exactes, complètes et cohérentes. Le principe intemporel du garbage in, garbage out reste valable : un modèle alimenté par des données erronées produit des résultats erronés, aussi sophistiqué soit-il. Les pipelines de qualité et l'architecture en médailles répondent à ce besoin.
• La fraîcheur — des données à jour, servies au bon rythme. Un modèle temps réel exige un magasin en ligne à faible latence ; c'est précisément le rôle du feature store.
• La traçabilité — le lignage (data lineage) qui permet de retracer le parcours d'une donnée, de sa source à la prédiction. Indispensable au débogage des modèles, à la confiance des utilisateurs et à la conformité réglementaire. C'est une fonction de la couche de gouvernance du lakehouse.
• La cohérence — la garantie que la même variable a la même définition partout, à l'entraînement comme en production. Le feature store adresse ce point de front.

On voit ainsi que chaque composant d'architecture répond à une exigence précise de l'IA. Le lakehouse assure le stockage unifié et les garanties ACID ; l'architecture en médailles améliore la qualité ; les pipelines transportent et transforment ; le feature store garantit la cohérence entre entraînement et service ; la gouvernance trace et sécurise. L'ensemble forme une chaîne : sa robustesse dépend de son maillon le plus faible.

Investir dans une architecture data solide n'est pas un coût qui grève les projets IA : c'est l'accélérateur qui leur permet d'atteindre la production. Les organisations dotées de fondations data matures déploient leurs cas d'usage plus vite, précisément parce que leurs données sont prêtes quand les algorithmes le sont.

La prochaine étape : les données au service de l'IA agentique

La génération actuelle de cas d'usage pousse ces exigences un cran plus loin. L'IA agentique — des agents logiciels qui raisonnent sur les données d'entreprise et exécutent des actions dans un cadre supervisé — repose intégralement sur la qualité de l'infrastructure sous-jacente. Un agent qui raisonne sur des données erronées produit des recommandations erronées. Un agent qui met de longues minutes à accéder aux données est inutilisable en temps réel. Un agent dont on ne peut retracer le raisonnement n'inspire pas confiance.

Ces prérequis — qualité, lignage, gouvernance, faible latence — plaident pour les architectures data matures décrites dans cet article : lakehouse en formats ouverts, gouvernance unifiée, catalogage automatisé, feature store pour la fraîcheur. Autrement dit, les briques d'infrastructure qui alimentent l'IA analytique d'aujourd'hui sont exactement celles qui alimenteront les agents de demain. Les équipes qui structurent leurs données aujourd'hui préparent le terrain des cas d'usage les plus avancés, sans avoir à tout reconstruire.

Choisir son architecture : les critères qui comptent

Face à cette diversité de catégories — entrepôt, lac, lakehouse, feature store, mesh, fabric —, comment orienter un choix d'architecture ? Plutôt qu'une réponse universelle, qui n'existe pas, quelques critères structurants aident à cadrer la réflexion, indépendamment de tout fournisseur.

Portabilité, réversibilité, format ouvert

Trois critères stratégiques sont fréquemment sous-estimés dans les processus de sélection. La portabilité désigne la capacité à déplacer données et pipelines vers un autre environnement ; les formats ouverts (Delta Lake, Apache Iceberg, Apache Hudi) l'améliorent nettement. La réversibilité mesure le coût réel d'un changement d'environnement : migration des données, réécriture des pipelines, reformation des équipes. Plus la dépendance à un format propriétaire est forte, plus la réversibilité est coûteuse. Le débat format ouvert contre format propriétaire est devenu un axe de différenciation majeur, et la tendance penche clairement vers l'ouverture.

Le coût total de possession, au-delà de la facture visible

Un point pratique souvent négligé : le coût total de possession d'une plateforme de données dépasse largement le prix du calcul ou du stockage. Les postes à intégrer dans l'analyse incluent la formation des équipes, l'intégration avec l'écosystème existant (connecteurs, outils d'orchestration), la migration depuis l'existant, et la gouvernance. Ces coûts « invisibles » sont bien réels et peuvent représenter une part significative de la dépense sur plusieurs années. Les évaluer rigoureusement, plutôt que de se focaliser sur le seul coût de calcul, évite les mauvaises surprises budgétaires.

Besoin dominant	Catégorie d'architecture adaptée
Reporting BI sur données structurées, gouvernance forte	Data warehouse (ou couche or d'un lakehouse)
Volumes massifs, données variées, science des données	Lakehouse en formats ouverts
Qualité progressive et pipelines traçables	Architecture en médailles (bronze / argent / or)
Modèles ML partagés, inférence temps réel	Feature store (magasins hors-ligne et en ligne)
Passage à l'échelle organisationnel	Data mesh (propriété par domaine)
Intégration automatisée de sources dispersées	Data fabric (métadonnée active)

Une démarche progressive plutôt qu'une refonte massive

La recommandation la plus solide, pour une organisation qui structure son infrastructure data, est d'avancer par étapes. Commencer par un socle de lakehouse en formats ouverts, qui garantit la portabilité et unifie BI et science des données. Y appliquer l'architecture en médailles pour améliorer la qualité des données de manière traçable. Introduire un feature store lorsque plusieurs modèles partagent des variables ou que l'inférence temps réel devient nécessaire. Adopter progressivement les principes du data mesh à mesure que la maturité organisationnelle le permet. Cette trajectoire incrémentale limite le risque, produit des résultats visibles à chaque étape, et évite l'écueil des refontes titanesques qui s'enlisent.

Le fil conducteur de tout ce parcours reste inchangé : une plateforme de données bien conçue n'est pas une fin en soi, mais le socle sur lequel les projets d'intelligence artificielle produisent des résultats fiables. Les catégories présentées ici — du data warehouse historique au feature store, en passant par le lakehouse et l'architecture en médailles — forment une boîte à outils cohérente. Les combiner avec discernement, selon les besoins réels et le degré de maturité, c'est se donner les moyens de tirer parti de l'IA sur des fondations durables. La technologie des modèles progresse vite ; ce qui distingue les organisations qui en tirent une valeur mesurable, c'est la solidité des données qui les alimentent.

Sources

• Armbrust et al. (CIDR 2021) — Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics
• Armbrust et al. (VLDB 2020) — Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores
• Databricks — What is a Data Lakehouse ? (définition et principes)
• Microsoft Learn — L'architecture en médailles (bronze, argent, or) du lakehouse
• Databricks — What is Medallion Architecture ?
• Onehouse — Apache Iceberg vs Delta Lake vs Apache Hudi : comparaison des formats de tables (2025)
• Dremio — Architecture comparée d'Apache Iceberg, Delta Lake et Apache Hudi
• Databricks — What is a Feature Store ? (magasins hors-ligne et en ligne)
• Feast — What is a Feature Store ? (définition et décalage entraînement-service)
• Zhamak Dehghani (martinfowler.com) — Data Mesh Principles and Logical Architecture
• Thoughtworks — Les quatre principes du data mesh
• IBM — Data fabric versus data mesh : gestion augmentée des données