Feature stores : anatomie de la chaîne d'approvisionnement des données ML

Un modèle de machine learning n'est jamais meilleur que les données qu'il consomme, et plus précisément que la façon dont ces données sont préparées, versionnées et acheminées. C'est là qu'intervient le concept de feature storefeature storeA centralised repository managing ML features, ensuring consistency between training and serving environments.Voir la définition complète →, souvent mentionné dans les roadmaps data sans être réellement compris. La confusion autour du terme est double : certains le réduisent à un simple entrepôt de variables calculées, d'autres le confondent avec un data warehousedata warehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.Voir la définition complète → classique. Ni l'une ni l'autre de ces lectures ne capte ce qui rend le concept stratégiquement important pour un CDO.

Pourquoi le sujet concerne directement le CDO

La majorité des organisations qui déploient des équipes de data science en 2026 se heurtent au même problème : les data scientists recalculent les mêmes variables encore et encore, parfois différemment selon les équipes, et les modèles en production consomment des features calculées selon une logique légèrement différente de celle utilisée lors de l'entraînement. Ce dernier point, le "training-serving skew", est l'une des causes les plus fréquentes de dégradation silencieuse des modèles en production.

D'un point de vue organisationnel, cela signifie que chaque équipe produit, crcrThe percentage of visitors or prospects who complete a desired action (purchase, sign-up, contact form), calculated as conversions divided by total opportunities.Voir la définition complète →édit, fraude ou recommandation reconstruit sa propre infrastructure de transformation de données. Uber, qui a développé l'un des premiers feature stores internes (Michelangelo, documenté publiquement dès 2017), estimait que ses data scientists consacraient plus de 60 % de leur temps à des tâches de préparation de données répétitives. Ce chiffre, issu d'une communication interne d'Uber publiée sur leur blog ingénierie, illustre un coût d'opportunité massif : chaque heure passée à recalculer une variable "ancienneté client" est une heure non consacrée à améliorer un modèle.

Pour un CDO, le feature store représente donc une décision d'infrastructure qui conditionne directement la vélocité et la fiabilité des équipes ML.

Comment ça fonctionne concrètement

Un feature store est un système centralisé qui gère le cycle de vie complet des features ML : leur calcul, leur stockage, leur versioning et leur mise à disposition, aussi bien pour l'entraînement que pour l'inférence en temps réel.

Il comporte généralement deux couches de stockage distinctes. La première est un stockage hors ligne ("offline store"), typiquement une table dans un data warehouse comme BigQuery ou Snowflake, qui conserve l'historique des features pour entraîner les modèles. La seconde est un stockage en ligne ("online store"), souvent une base clé-valeur comme Redis ou DynamoDB, qui sert les features avec une latence de quelques millisecondes pendant l'inférence en production.

Prenons un exemple concret : une banque qui veut modéliser le risque de défaut de paiement. La feature "ratio dépenses / revenus sur 90 jours" doit être calculée de manière identique lors de l'entraînement du modèle (sur des données historiques) et lors de son appel en production (sur les données en temps réel du client qui vient de faire une demande de crédit). Sans feature store, deux ingénieurs différents écrivent deux versions de ce calcul. Avec un feature store, une seule définition existe, versionnée, et les deux contextes la consomment de façon identique.

Les solutions du marché se divisent en deux catégories. Les plateformes open source comme Feast (initialement développé par Gojek, aujourd'hui maintenu par une communauté active) offrent de la flexibilité mais requièrent une infrastructure interne. Les solutions managées comme Tecton ou Hopsworks (éditeurs commerciaux, dont les contenus marketing sont à croiser avec des retours d'expérience indépendants) simplifient l'exploitation au prix d'une dépendance fournisseur. Databricks et AWS SageMaker Feature Store ont intégré des capacités similaires dans leurs plateformes respectives, ce qui crée une pression vers la consolidation.

Quand l'adopter, et quand y renoncer

Un feature store apporte de la valeur dans des contextes précis. Si une organisation maintient plus d'une dizaine de modèles en production, avec des features partagées entre plusieurs cas d'usage (churn, LTVLTVLifetime Value: the total revenue (or profit) a customer generates throughout their entire relationship with your business.Voir la définition complète →, fraude), la mutualisation du calcul génère rapidement des économies mesurables. Si des modèles en temps réel imposent des contraintes de latence strictes, la séparation entre offline et online store devient structurellement nécessaire.

En revanche, pour une organisation qui déploie deux ou trois modèles batch sans contrainte de latence, un feature store représente une complexité opérationnelle injustifiée. La tentation d'adopter des outils d'infrastructure avancés avant d'avoir les usages correspondants est un piège classique : on se retrouve à maintenir un système sophistiqué pour des besoins qui auraient été couverts par un schémamaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → dbt bien pensé dans le data warehouse existant.

Il y a aussi un arbitrage de gouvernance à considérer. Un feature store centralise la définition des features, ce qui est un avantage pour la cohérence, mais crée un point de friction organisationnel si les équipes n'ont pas établi de processus clairs pour la validation et le versioning. Chez LinkedIn, dont l'équipe AI a publié des retours sur son Feature Store interne ("Feathr", open sourcé en 2022), la mise en place du système a nécessité plusieurs mois de travail sur les conventions de nommage et les processus de revue, avant même d'écrire une ligne de code d'infrastructure. Ce détail mérite attention : la dimension technique est souvent plus simple que la dimension organisationnelle.

Le critère de décision le plus opérationnel reste le suivant : si vos data scientists passent plus de 30 % de leur temps à recalculer des features que d'autres équipes ont déjà calculées, et si vous avez des modèles en production qui dégradent sans raison apparente, le feature store traite exactement ces deux problèmes. Dans les autres cas, consolidez d'abord votre couche de transformation avec des outils plus simples.

La chaîne d'approvisionnement des données ML mérite le même niveau d'attention stratégique que la chaîne logistique dans une entreprise manufacturière. Un CDO qui ne contrôle pas la façon dont les features arrivent dans ses modèles ne contrôle pas réellement la fiabilité de ses systèmes d'IA. Commencer par auditer combien de features sont recalculées indépendamment par plusieurs équipes est le point de départ le plus direct.