Feature stores : la colonne vertébrale oubliée de la chaîne d'approvisionnement ML

Un modèle de machine learning n'est jamais meilleur que les données qui l'alimentent. Cette évidence est répétée à l'envi, mais elle masque une réalité opérationnelle plus précise : le vrai problème n'est pas la qualité des données brutes, c'est la reproductibilité, la cohérence et la réutilisabilité des variables transformées que l'on appelle les features. Les feature stores ont été conçus pour résoudre exactement ce problème. Pourtant, dans la majorité des organisations, ce composant est soit absent, soit mal défini, soit confondu avec un simple catalogue de données. Cette confusion a un coût mesurable.

Pourquoi ce sujet concerne directement le CDO

La plupart des équipes data science passent entre 60 % et 80 % de leur temps à préparer des données, selon des estimations régulièrement citées par des cabinets comme Gartner et McKinsey. Une fraction significative de ce temps est consacrée à reconstruire des transformations que d'autres collègues ont déjà faites, parfois dans le même trimestre, parfois pour le même cas d'usage. Un data scientist qui travaille sur un modèle de scoring 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 recalcule le ratio d'endettement d'un client. Trois bureaux plus loin, un autre recalcule la même variable pour un modèle de détection de fraude. Résultats identiques en théorie, mais calculs distincts, pipelines distincts, et donc risque de divergence en production.

Pour un CDO, ce phénomène a trois conséquences directes. La productivité des équipes est grevée par des travaux redondants. Les modèles déployés en production utilisent parfois des définitions légèrement différentes d'une même variable selon l'équipe qui les a construits, ce qui crée des incohérences réglementaires et opérationnelles. Et lors du passage de l'entraînement à la production, les features calculées en batch pendant l'entraînement ne correspondent pas toujours aux features calculées en temps réel lors de l'inférence. C'est ce que les praticiens appellent le training-serving skew, et c'est l'une des causes les plus fréquentes d'un modèle qui performe bien en test mais dégrade en production.

Un feature storefeature storeA centralised repository managing ML features, ensuring consistency between training and serving environments.Voir la définition complète → bien conçu est l'infrastructure qui élimine ces trois problèmes simultanément. Ce n'est pas un outil de data scientist. C'est une décision d'architecture que le CDO doit valider et financer.

Comment ça fonctionne concrètement

Un feature store est un système qui centralise la définition, le calcul, le stockage et la mise à disposition des features transformées, à la fois pour l'entraînement des modèles et pour leur inférence en production.

L'architecture type comporte deux couches de stockage complémentaires. Unoffline store, généralement construit sur un entrepôt de données comme BigQuery, Snowflake ou un data lakedata lakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.Voir la définition complète → S3, qui contient l'historique des features avec leurs valeurs horodatées. C'est depuis là que les data scientists tirent leurs jeux d'entraînement. Et un online store, souvent une base clé-valeur à faible latence comme Redis ou DynamoDB, qui expose les valeurs les plus récentes d'une feature pour alimenter un modèle en production à la milliseconde.

Prenons un exemple concret. Uber a développé Michelangelo, son infrastructure ML interne, avec un feature store au centre du dispositif. Un exemple souvent cité dans leurs publications techniques : la feature "nombre de trajets effectués par ce chauffeur dans les 30 dernières minutes" est calculée une seule fois, stockée dans le store, et utilisée à la fois par le modèle de prédiction des temps d'attente et par le modèle de détection d'anomalies comportementales. La définition est unique, le calcul est unique, la valeur est cohérente entre les deux systèmes. Sans feature store, chaque équipe recalcule cette fenêtre glissante avec ses propres outils, ce qui produit inévitablement des écarts.

Le concept clé qui rend tout cela possible est le point-in-time correctness : lorsqu'un data scientist construit son jeu d'entraînement, il doit être certain que les valeurs de features associées à chaque événement passé sont celles qui étaient disponibles à cet instant précis, pas celles calculées rétrospectivement. Un feature store correctement implémenté gère cette logique automatiquement, évitant le data leakage temporel qui fausse silencieusement des milliers de modèles.

Des plateformes comme Feast (open source, initialement développé par GoJek), Tecton (société spécialisée, fondée par d'anciens ingénieurs d'Uber, avec une offre commerciale) ou Vertex AI Feature Store de Google Cloud proposent des implémentations de ce pattern. Tecton et Vertex sont des offres commerciales dont les arguments de performance doivent être évalués avec recul, comme pour tout éditeur.

Quand l'adopter, et quand s'en passer

Un feature store introduit de la complexité réelle. Avant de s'engager dans ce chantier, quelques critères permettent de juger si le moment est venu.

L'organisation doit avoir plusieurs équipes de data science travaillant en parallèle sur des cas d'usage distincts. Si une seule équipe gère deux ou trois modèles, les bénéfices de mutualisation ne justifient pas l'investissement. Le seuil de pertinence se situe généralement autour d'une dizaine de modèles en production ou de quatre à cinq équipes distinctes.

Les cas d'usage doivent inclure de l'inférence temps réel ou quasi-temps réel. Pour des modèles batch qui tournent une fois par nuit, le problème du training-serving skew est moins critique et un pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → Airflow classique suffit souvent.

Les risques réglementaires doivent être élevés. Dans les secteurs bancaire et assurantiel, la capacité à justifier précisément comment une feature a été calculée à un instant donné a une valeur réglementaire directe, notamment dans le cadre des exigences de l'EBA sur les modèles de risque de crédit.

À l'inverse, il faut résister à la tentation de déployer un feature store comme signal de maturité technique. Plusieurs organisations ont investi dans l'outil avant d'avoir défini une gouvernance des features, c'est-à-dire des règles claires sur qui peut créererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Voir la définition complète → une feature, comment elle est validée, documentée et dépréciée. Un store vide ou anarchique reproduit exactement le problème qu'il était censé résoudre.

La décision d'investir dans un feature store est finalement une décision sur l'économie de la fonction data science. Le CDO qui comprend les mécaniques de training-serving skew et de point-in-time correctness est en mesure de poser les bonnes questions lors des revues d'architecture et d'éviter que son organisation finance indéfiniment des silos parallèles. L'outil n'est qu'un moyen : c'est la discipline de gouvernance des features qui produit la valeur réelle.