Accueil › Glossaire › Feature Store

Feature Store

Un feature store est un dépôt centralisé qui stocke, gère, version et sert les features (variables d’entrée) utilisées par les modèles de machine learning, en garantissant la cohérence entre l’entraînement et l’inférence en production.

Si vous avez déjà passé des semaines à recréer des features qu’un collègue avait déjà calculées pour un autre modèle, ou si votre modèle se comporte différemment en production parce que les features ne sont pas calculées exactement comme lors de l’entraînement, vous comprenez le problème que résout un feature store. C’est le chaînon manquant entre vos pipelines de données et vos modèles ML : il garantit que la bonne donnée arrive au bon modèle, au bon moment, dans le bon format.

Pourquoi un feature store est nécessaire

Dans un projet de machine learning, les features sont les variables d’entrée qui alimentent le modèle : le montant moyen d’une transaction, le nombre de connexions par jour, le ratio de clics sur les 7 derniers jours. Calculer ces features est souvent plus complexe et plus chronophage que construire le modèle lui-même. Sans feature store, chaque équipe recalcule les mêmes features indépendamment, avec des définitions parfois différentes, ce qui multiplie le travail et introduit des incohérences.

Le problème du training-serving skew

C’est le problème numéro un que résout un feature store. Le training-serving skew se produit quand les features utilisées pendant l’entraînement ne correspondent pas exactement à celles servies en production. Cela arrive fréquemment quand un data scientist calcule ses features dans un notebook Pandas, mais qu’un ingénieur ML réimplémente les mêmes calculs en Spark ou en SQL pour la production. Même de petites différences (arrondi, gestion des nulls, fenêtre temporelle) peuvent dégrader catastrophiquement les performances du modèle en production. Un feature store élimine ce problème en servant exactement les mêmes features dans les deux contextes.

Réutilisation des features entre modèles

Chez Meta, les 100 features les plus populaires de leur feature store sont réutilisées dans plus de 100 modèles différents. Sans feature store, chaque modèle recalcule ces features depuis zéro, gaspillant du calcul, du temps d’ingénierie et de l’argent cloud. Un feature store crée un catalogue partagé où les data scientists découvrent et réutilisent les features existantes au lieu de les recréer.

Point-in-time correctness

Pour l’entraînement, les features doivent être calculées avec les données disponibles au moment exact de chaque observation, pas les données actuelles. Utiliser des données futures (feature leakage) produit un modèle artificiellement performant à l’entraînement mais catastrophique en production. Les feature stores gèrent nativement les jointures point-in-time correctes, un pattern spécifique au ML que les data warehouses classiques ne supportent pas.

Serving en temps réel

Les modèles de production (détection de fraude, recommandation, pricing dynamique) ont besoin de features en sub-milliseconde. Calculer des agrégats complexes à la volée n’est pas réaliste. Un feature store pré-calcule et matérialise les features dans un online store optimisé pour la lecture à faible latence (Redis, DynamoDB, Bigtable, RonDB).

Architecture d’un feature store

Un feature store moderne se compose de cinq composants interconnectés :

Feature Registry (catalogue)

Le registry est le point d’entrée central. Il stocke les définitions de features (nom, description, type, propriétaire, logique de transformation), les métadonnées (date de création, fréquence de mise à jour, modèles consommateurs) et la documentation. C’est l’équivalent d’un catalogue de données, mais spécifiquement conçu pour les features ML. Un bon registry permet la découverte : un data scientist peut chercher « features liées aux transactions des 30 derniers jours » et trouver ce qui existe déjà.

Offline Store (stockage batch/historique)

L’offline store contient l’historique complet des features pour l’entraînement et le backtesting. Il est construit sur un stockage scalable : Delta Lake, Parquet sur S3, BigQuery, Snowflake ou Hive. Les volumes sont importants (téraoctets à pétaoctets) et les requêtes sont de type batch, avec des jointures point-in-time correctes. C’est ici que les data scientists récupèrent leurs datasets d’entraînement.

Online Store (serving temps réel)

L’online store maintient uniquement les valeurs les plus récentes de chaque feature pour chaque entité (utilisateur, produit, transaction). Optimisé pour des lectures en sub-milliseconde et des volumes élevés de requêtes, il est typiquement construit sur un key-value store : Redis, DynamoDB, Bigtable, Cassandra ou RonDB (Hopsworks). Quand un modèle en production a besoin des features d’un utilisateur pour faire une prédiction, il interroge l’online store.

Feature Pipelines (transformations)

Les feature pipelines transforment les données brutes en features exploitables. Trois types de transformations coexistent :

Batch : exécutées périodiquement (horaire, quotidien) sur des données historiques. Exemple : calculer le chiffre d’affaires moyen par client sur les 90 derniers jours. Typiquement avec Spark, SQL ou Python.

Streaming : traitent les événements en temps réel via Kafka, Flink ou Spark Streaming. Exemple : calculer le nombre de transactions d’un utilisateur dans les 5 dernières minutes pour la détection de fraude.

On-demand : calculées au moment de la requête d’inférence. Exemple : l’heure de la journée, le jour de la semaine, la distance entre deux coordonnées GPS. Ces features ne nécessitent pas de stockage car elles sont dérivées du contexte de la requête.

Monitoring

Un feature store doit monitorer la qualité des données servies : fraîcheur (les features sont-elles à jour ?), validité (les valeurs sont-elles dans les ranges attendus ?), drift (la distribution statistique a-t-elle changé ?). Ce monitoring s’intègre aux outils d’observabilité existants et déclenche des alertes quand les features se dégradent.

Les outils de feature store en détail

Feast : le standard open source

Feast (Feature Store), développé initialement par Go-Jek et Google Cloud, est aujourd’hui gouverné par la Linux Foundation avec Tecton comme contributeur principal. C’est le feature store open source le plus adopté.

L’architecture de Feast est modulaire et « pluggable » : vous connectez vos propres systèmes de stockage (BigQuery, Snowflake, Redis, DynamoDB, PostgreSQL) et Feast gère la synchronisation entre offline et online stores, le serving temps réel et les jointures point-in-time correctes.

# Définir un feature view dans Feast
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64
from datetime import timedelta

# Source de données
transactions_source = FileSource(
    path="data/transactions.parquet",
    timestamp_field="event_timestamp"
)

# Entité
user = Entity(name="user_id", join_keys=["user_id"])

# Feature view
user_transaction_features = FeatureView(
    name="user_transaction_features",
    entities=[user],
    ttl=timedelta(days=1),
    schema=[
        Field(name="avg_transaction_amount_30d", dtype=Float32),
        Field(name="transaction_count_7d", dtype=Int64),
        Field(name="max_transaction_amount_24h", dtype=Float32),
    ],
    source=transactions_source,
)

# Récupérer des features pour l'entraînement (offline)
from feast import FeatureStore
store = FeatureStore(repo_path=".")

training_df = store.get_historical_features(
    entity_df=entity_df,  # DataFrame avec user_id + event_timestamp
    features=[
        "user_transaction_features:avg_transaction_amount_30d",
        "user_transaction_features:transaction_count_7d",
    ],
).to_df()

# Récupérer des features en temps réel (online)
online_features = store.get_online_features(
    features=[
        "user_transaction_features:avg_transaction_amount_30d",
        "user_transaction_features:transaction_count_7d",
    ],
    entity_rows=[{"user_id": 12345}],
).to_dict()

Le point fort de Feast est sa flexibilité : vous gardez le contrôle total de votre infrastructure. Le compromis est que Feast ne fait pas le feature engineering lui-même (c’est fait en amont) et nécessite une équipe capable de gérer l’infrastructure sous-jacente (Redis, Kafka, Spark). L’outil n’inclut ni UI native ni système de sécurité intégré.

Tecton : le managé enterprise

Tecton a été fondé par l’équipe qui a créé Michelangelo, la plateforme ML d’Uber. C’est un feature store managé, opinioné et conçu pour la production critique à grande échelle.

Tecton se différencie par son DSL déclaratif : vous définissez vos features en Python, SQL ou Spark, et Tecton gère automatiquement les pipelines de transformation (batch, streaming, temps réel), la matérialisation dans les stores offline/online, le monitoring et les alertes. La gestion est GitOps : les définitions de features vivent dans un repo Git, et les changements sont déployés via CI/CD.

L’intégration est native avec AWS, Databricks, Snowflake et Kubernetes. Le pricing est consumption-based et orienté enterprise. Tecton est le choix des organisations qui ont besoin de performances garanties pour des cas d’usage critiques (fraude en temps réel, pricing dynamique, recommandation personnalisée) et qui préfèrent payer pour un service managé plutôt que gérer l’infrastructure elles-mêmes.

Hopsworks : la plateforme intégrée

Hopsworks se positionne comme un « AI Lakehouse » complet dont le feature store est un composant central. Construit sur RonDB (un fork de NDB Cluster optimisé pour le ML), Hopsworks revendique des latences sub-milliseconde et des performances 4x supérieures à Feast pour le serving online.

L’avantage de Hopsworks est l’intégration verticale : feature engineering, feature store, model training, model registry et model serving dans une seule plateforme. Pour les industries réglementées (finance, santé, secteur public), Hopsworks est souvent le seul choix viable car il supporte le déploiement on-premise et la souveraineté des données, en plus du cloud.

Des organisations comme Siemens, Intel et Safran utilisent Hopsworks pour gérer des workflows de gouvernance AI où les features sont partagées entre équipes avec des pistes d’audit complètes. Hopsworks est disponible en open source (AGPL-v3) et en version Enterprise managée.

Feature stores cloud natifs

Le Databricks Feature Store mérite une attention particulière. Avec l’intégration Unity Catalog, il offre la gouvernance, le lineage et le partage cross-workspace des features. Quand un modèle est entraîné via le feature store, MLflow enregistre automatiquement les dépendances aux features. Au moment de l’inférence, le modèle sait quelles features il a besoin et le feature store les récupère automatiquement. C’est l’intégration la plus fluide entre feature store et model registry du marché.

Comparatif des feature stores

Quand avez-vous besoin d’un feature store ?

Un feature store n’est pas nécessaire pour chaque projet ML. Il devient pertinent quand vous observez ces signaux :

Plusieurs équipes construisent des modèles qui pourraient partager des features. Si deux équipes calculent indépendamment « le montant moyen des transactions sur 30 jours », vous gaspillez du compute et risquez des définitions incohérentes.

Vous avez des problèmes de cohérence training/serving. Si vos modèles performent bien en validation mais se dégradent en production, le training-serving skew est probablement en cause.

Vos data scientists passent plus de temps sur le feature engineering que sur la modélisation. Un catalogue de features réutilisables accélère drastiquement le développement de nouveaux modèles.

Vous servez des modèles en temps réel. Si vos prédictions doivent être en sub-seconde, vous avez besoin d’un online store avec des features pré-calculées.

La conformité exige de la traçabilité. Savoir quelles features ont été utilisées par quel modèle, avec quelle version, est un prérequis réglementaire dans la finance, la santé et l’assurance.

Implémenter un feature store : par où commencer

Étape 1 : Identifier un cas d’usage pilote

Choisissez un modèle en production avec un impact métier clair, où la gestion des features est douloureuse. La détection de fraude, la recommandation produit ou le scoring de crédit sont des candidats classiques. Implémentez le feature store uniquement pour les features de ce modèle.

Étape 2 : Installer Feast (ou votre outil)

# Installation de Feast
pip install feast

# Initialiser un projet
feast init my_feature_store
cd my_feature_store

# Structure du projet
# my_feature_store/
#   feature_store.yaml    # Configuration (stores, provider)
#   features.py           # Définitions de features
#   data/                 # Données sources

# feature_store.yaml
project: fraud_detection
registry: data/registry.db
provider: local
online_store:
  type: redis
  connection_string: "localhost:6379"
offline_store:
  type: file

Étape 3 : Définir et matérialiser les features

# features.py
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64, String
from datetime import timedelta

# Entités
user = Entity(name="user_id", join_keys=["user_id"])
merchant = Entity(name="merchant_id", join_keys=["merchant_id"])

# Sources
user_features_source = FileSource(
    path="data/user_features.parquet",
    timestamp_field="event_timestamp",
)

# Feature views
user_spending_features = FeatureView(
    name="user_spending",
    entities=[user],
    ttl=timedelta(hours=24),
    schema=[
        Field(name="avg_amount_30d", dtype=Float32),
        Field(name="total_transactions_7d", dtype=Int64),
        Field(name="max_amount_24h", dtype=Float32),
        Field(name="distinct_merchants_7d", dtype=Int64),
    ],
    source=user_features_source,
    description="Features d'activité de dépenses utilisateur"
)

# Appliquer les définitions
feast apply

# Matérialiser les features dans l'online store
feast materialize-incremental $(date -u +"%Y-%m-%dT%H:%M:%S")

Étape 4 : Intégrer avec l’entraînement et l’inférence

from feast import FeatureStore
import pandas as pd

store = FeatureStore(repo_path=".")

# Pour l'entraînement : récupérer les features historiques
entity_df = pd.DataFrame({
    "user_id": [1001, 1002, 1003],
    "event_timestamp": pd.to_datetime(["2026-03-15", "2026-03-15", "2026-03-15"])
})

training_data = store.get_historical_features(
    entity_df=entity_df,
    features=[
        "user_spending:avg_amount_30d",
        "user_spending:total_transactions_7d",
        "user_spending:max_amount_24h",
    ],
).to_df()

# Pour l'inférence en temps réel : récupérer les features actuelles
online_response = store.get_online_features(
    features=[
        "user_spending:avg_amount_30d",
        "user_spending:total_transactions_7d",
    ],
    entity_rows=[{"user_id": 1001}],
)
features_dict = online_response.to_dict()

Étape 5 : Documenter et étendre

Ajoutez des descriptions à chaque feature : ce qu’elle représente, comment elle est calculée, sa fréquence de mise à jour, ses cas d’usage. Un feature store sans documentation est un feature dump. Étendez progressivement en migrant les features des autres modèles qui partagent des features communes.

Bonnes pratiques

Standardisez les définitions

Chaque feature doit avoir un nom clair, un propriétaire, une description de sa logique de calcul et un SLA de fraîcheur. Le feature registry est inutile si les features s’appellent feat_1 ou tmp_amount. Adoptez une convention de nommage : {entité}_{métrique}_{fenêtre} (ex: user_avg_spend_30d, merchant_fraud_rate_90d).

Validez les données

Implémentez des checks de qualité dans vos feature pipelines : valeurs dans les ranges attendus, pas de nulls inattendus, distributions statistiques stables. Des outils comme Great Expectations s’intègrent nativement dans les pipelines de features. Bloquez la matérialisation si les checks échouent plutôt que de servir des features corrompues.

Versionnez les features

Quand la logique de calcul d’une feature change, créez une nouvelle version plutôt que de modifier l’existante. Les modèles entraînés avec user_avg_spend_30d_v1 doivent continuer à recevoir cette version, pas la v2 avec une logique différente. Cela évite de casser silencieusement des modèles en production.

Respectez le point-in-time

Lors de la génération des datasets d’entraînement, utilisez toujours des jointures point-in-time correctes. Feast gère cela nativement via get_historical_features(). Ne faites jamais de jointures directes sur la dernière valeur d’une feature : c’est du feature leakage, et votre modèle sera artificiellement bon en validation mais mauvais en production.

Monitorez le drift

Les distributions de features changent avec le temps. Un changement soudain peut indiquer un bug dans le pipeline ou un vrai shift dans les données. Monitorez les statistiques de base (moyenne, écart-type, percentiles) de chaque feature et alertez quand elles dévient des baselines établies.

Feature stores et applications GenAI

Les feature stores évoluent pour supporter les cas d’usage GenAI et RAG. Les vector stores (Pinecone, Weaviate, Qdrant) gèrent les embeddings pour la recherche sémantique, tandis que les feature stores classiques gèrent les features structurées (numériques, catégorielles). Dans une application RAG hybride, le modèle peut avoir besoin simultanément de features structurées (historique d’achat du client) et de résultats de recherche sémantique (documents pertinents). L’intégration entre feature stores et vector stores est un domaine en pleine évolution.

Hopsworks supporte nativement la recherche par vecteurs (approximate nearest neighbor) dans son online store, ce qui permet de combiner features classiques et embeddings dans une seule plateforme. Feast travaille également sur l’intégration de backends vectoriels.

Verdict

Un feature store est l’investissement infrastructure le plus rentable pour une équipe ML qui dépasse le stade du prototype. Il élimine le problème du training-serving skew (la cause numéro un des modèles qui se dégradent en production), permet la réutilisation des features entre modèles (économie de calcul et d’ingénierie), et fournit le serving temps réel nécessaire aux applications ML critiques.

Commencez avec Feast si vous voulez la flexibilité maximale et le contrôle de votre infrastructure. Passez à Tecton si vos cas d’usage temps réel sont critiques et que vous préférez un service managé. Choisissez Hopsworks si vous êtes dans une industrie réglementée avec des exigences on-premise. Et si vous êtes sur Databricks, utilisez leur Feature Store natif : l’intégration avec Unity Catalog et MLflow en fait le choix le plus naturel de votre écosystème.