Feature stores : anatomie d'un maillon souvent mal compris de la chaîne ML

Le terme "feature storefeature storeA centralised repository managing ML features, ensuring consistency between training and serving environments.Voir la définition complète →" circule dans toutes les conversations sur la maturité ML depuis quelques années, souvent cité comme la solution aux problèmes de cohérence des données entre équipes. Dans les faits, beaucoup d'organisations ont déployé un feature store sans avoir clairement défini ce qu'il devait résoudre, et d'autres en ont besoin sans le savoir. C'est ce décalage entre la promesse et la mécanique réelle qui 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 →ée des décisions d'investissement ratées.

Pourquoi ce sujet concerne directement un CDO

Un CDO pilote la chaîne de valeur de la donnée de bout en bout. Or la chaîne ML a une particularité que la chaîne analytique classique n'a pas : la donnée qui sert à entraîner un modèle doit être strictement identique à celle qui alimente le modèle en production. Si ce n'est pas le cas, le modèle se comporte différemment en production qu'en test. Ce phénomène, appelé training-serving skew, est l'une des causes les plus fréquentes d'échec silencieux des déploiements ML.

Le CDO est souvent la seule personne capable de voir que ce problème n'est pas technique mais organisationnel : plusieurs équipes calculent la même variable (par exemple, le chiffre d'affaires des 30 derniers jours d'un client) de manière légèrement différente, avec des fenêtres temporelles ou des règles de filtrage qui divergent. Le résultat : un data scientist utilise une version, l'ingénieur qui déploie le modèle en production en calcule une autre. Sans gouvernance explicite sur les features, ce glissement est invisible jusqu'à ce qu'il coûte cher.

Airbnb a formalisé ce problème dès 2017 avec Zipline, leur système interne de gestion de features, avant que le concept de feature store ne soit largement popularisé. Uber a suivi avec Michelangelo. Ces entreprises n'ont pas résolu un problème de performance de modèle : elles ont résolu un problème de gouvernance de la donnée d'entraînement.

Comment ça fonctionne concrètement

Un feature store est un registre centralisé qui stocke, versionne et sert des features calculées à partir de données brutes. Il a deux interfaces principales : une pour le training (accès en batch à des données historiques) et une pour l'inférence (accès en temps quasi réel à des valeurs récentes). Ces deux interfaces puisent dans la même définition de la feature, ce qui garantit la cohérence.

Prenons un exemple concret dans un contexte bancaire. Un modèle de scoring de crédit utilise la variable "ratio_charges_revenus_6m" : la somme des charges fixes divisée par le revenu moyen des six derniers mois. Sans feature store, un data scientist calcule cette variable sur un dump SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Voir la définition complète → historique pendant l'entraînement. Quand le modèle est déployé, l'ingénieur recalcule la variable à la volée via une requête différente, potentiellement avec une logique de netting légèrement modifiée. Le modèle reçoit une entrée numériquement différente de celle sur laquelle il a été calibré.

Avec un feature store, la logique de calcul est définie une seule fois dans 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 → (souvent en Python, avec des outils comme Feast, Tecton ou Hopsworks). Ce pipeline génère des valeurs stockées dans deux couches : une couche offline (entrepôt ou lac de données, pour l'entraînement) et une couche online (base clé-valeur rapide comme Redis ou DynamoDB, pour l'inférence en production). Le data scientist et l'ingénieur ML consomment la même feature depuis le même registre. La définition est versionnée, documentée, et réutilisable par d'autres équipes.

La réutilisabilité mérite d'être mentionnée séparément. Chez LinkedIn, le catalogue interne de features comptait plusieurs milliers d'entrées à la fin des années 2010. Un nouveau modèle de recommandation pouvait démarrer avec des dizaines de features existantes plutôt que de repartir de zéro. Le gain de temps sur le cycle de développement d'un modèle n'est pas marginal : il peut représenter 30 à 50 % du temps de préparation des données selon les estimations internes de plusieurs grandes plateformes, bien que ces chiffres proviennent de communications de ces entreprises elles-mêmes et non de recherches indépendantes.

Quand en déployer un, et quand s'en passer

Un feature store a du sens dans quatre situations précises : plusieurs équipes développent des modèles en parallèle et recalculent les mêmes variables de manière indépendante ; l'organisation constate des écarts de performance entre les phases de test et de production ; les modèles doivent être mis à jour fréquemment avec des données récentes ; et les features doivent être accessibles en temps réel avec des contraintes de latence inférieures à quelques dizaines de millisecondes.

En revanche, pour une organisation qui déploie deux ou trois modèles par an, dont aucun n'a de contrainte temps réel, un feature store ajoute une couche d'infrastructure qui coûte plus en maintenance qu'elle ne rapporte en cohérence. Les éditeurs comme Tecton (startup spécialisée) ou Databricks (qui a intégré des fonctionnalités de feature store dans sa plateforme) ont naturellement tendance à présenter leurs outils comme adaptés à toutes les tailles d'organisation. Ces argumentaires commerciaux méritent d'être lus avec un regard critique et croisés avec des retours d'expérience indépendants.

L'autre piège est d'implémenter un feature store sans gouvernance associée. L'outil seul ne résout rien si personne ne définit qui est responsable de la qualité d'une feature, comment une modification de définition est communiquée aux équipes consommatrices, et comment les features obsolètes sont dépréciées. Des travaux du groupe de recherche MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Voir la définition complète → Community, qui publie des études sur les pratiques de déploiement ML, montrent régulièrement que les échecs de feature stores en entreprise sont rarement dus à l'outil lui-même.

Un feature store bien gouverné réduit le training-serving skew et accélère le réemploi des variables entre équipes. Mais c'est d'abord un contrat organisationnel entre producteurs et consommateurs de features, et ensuite seulement un choix technologique. Le CDO qui prend cette décision dans cet ordre obtient de meilleurs résultats que celui qui commence par évaluer des éditeurs.