Data Science

Feature Store en 2025 : est-ce encore utile en production IA ?

Jean-Michel Helem

07 nov. 2025 • 7 min read

Les feature stores ont fait beaucoup de bruit dans le monde du MLOps il y a quelques années. Présentés comme la solution miracle pour industrialiser le machine learning, ils promettaient de résoudre tous nos problèmes de gestion de features. Mais aujourd'hui, en 2025, alors que les architectures de ML ont considérablement évolué, la question mérite d'être posée : est-ce que les feature stores sont toujours pertinents ?

Spoiler : la réponse n'est pas binaire.

C'est quoi, un feature store, déjà ?

Pour ceux qui découvrent le concept, un feature store est essentiellement une base de données spécialisée pour stocker, gérer et servir les features (caractéristiques) utilisées par vos modèles de machine learning.

Le problème qu'ils résolvent : quand vous entraînez un modèle ML, vous créez des features à partir de vos données brutes. Par exemple, pour prédire si un utilisateur va acheter un produit, vous calculez peut-être "nombre d'achats dans les 30 derniers jours", "montant moyen du panier", "temps depuis la dernière visite", etc.

Le souci : ces calculs doivent être identiques entre :

L'entraînement de votre modèle (sur des données historiques)
L'inférence en production (sur des données temps réel)

Sinon, vous avez un training-serving skew : votre modèle s'est entraîné sur des features calculées d'une façon, mais en production il reçoit des features calculées différemment. Résultat ? Performance catastrophique.

La promesse du feature store : un endroit unique où vous définissez vos features une fois, et où elles sont calculées de la même façon partout.

Architecture d'un Feature Store

Voici comment s'intègre un feature store dans une architecture ML moderne :

┌─────────────────────────────────────────────────────────────────────────┐
│                        SOURCES DE DONNÉES                                │
├─────────────────┬─────────────────┬─────────────────┬───────────────────┤
│   Bases SQL     │   Data Lake     │   Streaming     │   APIs externes   │
│   (PostgreSQL)  │   (S3/Parquet)  │   (Kafka)       │   (CRM, etc.)     │
└────────┬────────┴────────┬────────┴────────┬────────┴─────────┬─────────┘
         │                 │                 │                   │
         └─────────────────┴────────┬────────┴───────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                      FEATURE ENGINEERING                                 │
│  ┌─────────────────────────────────────────────────────────────────┐    │
│  │  Transformations : agrégations, calculs, encodages, embeddings  │    │
│  └─────────────────────────────────────────────────────────────────┘    │
└────────────────────────────────┬────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                         FEATURE STORE                                    │
│  ┌──────────────────────┐      ┌──────────────────────────────────┐     │
│  │    OFFLINE STORE     │      │         ONLINE STORE             │     │
│  │    (historique)      │      │         (temps réel)             │     │
│  │  ─────────────────   │      │  ──────────────────────────────  │     │
│  │  - Delta Lake/Parquet│      │  - Redis/DynamoDB               │     │
│  │  - Pour training     │      │  - Latence < 10ms               │     │
│  │  - Time-travel       │      │  - Pour inférence               │     │
│  └──────────────────────┘      └──────────────────────────────────┘     │
│                                                                          │
│  ┌───────────────────────────────────────────────────────────────┐      │
│  │  REGISTRY : métadonnées, versions, lineage, documentation     │      │
│  └───────────────────────────────────────────────────────────────┘      │
└──────────────┬──────────────────────────────────┬────────────────────────┘
               │                                  │
               ▼                                  ▼
┌──────────────────────────────┐    ┌──────────────────────────────────────┐
│        TRAINING              │    │           INFERENCE                   │
│  ────────────────────────    │    │  ────────────────────────────────    │
│  - Requête features batch    │    │  - Requête features temps réel       │
│  - Point-in-time correct     │    │  - API REST / gRPC                   │
│  - Dataset reproductible     │    │  - Latence garantie                  │
└──────────────────────────────┘    └──────────────────────────────────────┘
               │                                  │
               ▼                                  ▼
┌──────────────────────────────┐    ┌──────────────────────────────────────┐
│     MODÈLE ENTRAÎNÉ          │───▶│         PRÉDICTIONS                  │
└──────────────────────────────┘    └──────────────────────────────────────┘

Les composants clés :

Offline Store : stockage historique pour l'entraînement (point-in-time queries)
Online Store : cache temps réel pour l'inférence (latence ultra-faible)
Registry : catalogue des features avec métadonnées et versioning

L'âge d'or : 2019-2022

Entre 2019 et 2022, les feature stores étaient LA tendance MLOps. Des solutions comme Feast, Tecton, Hopsworks ou AWS SageMaker Feature Store ont explosé.

Pourquoi cet engouement ?

Réutilisabilité : définir une feature une fois, l'utiliser dans 10 modèles différents
Cohérence : garantir que training = serving
Versioning : suivre l'évolution de vos features
Monitoring : tracer les drifts de features
Performance : servir les features rapidement en production

Pour les équipes data science qui commençaient à industrialiser leurs modèles, c'était le chaînon manquant.

2025 : le paysage a changé

Mais beaucoup de choses ont évolué depuis.

1. Les LLMs ont tout bouleversé

L'émergence massive des Large Language Models a radicalement changé la donne. Pour beaucoup d'applications :

On ne fait plus du feature engineering classique
On envoie directement du texte brut au modèle
Les "features" sont implicites dans les prompts

Exemple concret : avant, pour classifier un email, vous auriez créé des features comme "longueur du mail", "nombre d'URLs", "présence de mots-clés", etc. Aujourd'hui ? Vous envoyez le mail brut à un LLM.

Les feature stores sont peu utiles dans ce paradigme.

2. Le real-time streaming a maturé

Les architectures de streaming modernes (Kafka, Flink, etc.) gèrent maintenant très bien les features temps réel. Beaucoup d'équipes ont réalisé qu'elles pouvaient calculer leurs features directement dans leur pipeline de streaming sans passer par un feature store.

Avantage : moins de complexité, moins d'outils à maintenir, latence réduite.

3. Le mode "feature store maison" s'est banalisé

Avec l'amélioration des outils modernes :

DuckDB pour les calculs analytiques légers
Polars pour la manipulation de données rapide
Redis ou DynamoDB pour le serving temps réel
Delta Lake ou Iceberg pour le stockage historique

...beaucoup d'équipes se sont rendu compte qu'elles pouvaient construire un "feature store light" adapté à leurs besoins spécifiques, sans la complexité d'un produit générique.

4. Le coût de complexité est réel

Déployer et maintenir un feature store, c'est :

Un outil de plus à opérer
Une courbe d'apprentissage pour l'équipe
Des migrations de données
Un point de défaillance supplémentaire
Des coûts d'infrastructure

Pour beaucoup d'entreprises, le ROI n'est pas évident si elles n'ont que quelques modèles en production.

Quand un Feature Store est Indispensable

Le feature store n'est pas mort. Dans certains contextes, il reste absolument nécessaire.

1. Vous avez beaucoup de modèles en production

Seuils indicatifs :

10+ modèles utilisant des features communes
Réutilisation massive de features entre modèles
Équipes multiples qui partagent des features

Exemple : une plateforme e-commerce avec des modèles de recommandation, pricing dynamique, détection de fraude, prédiction de churn, scoring crédit... tous partageant des features utilisateur.

2. Vous faites du ML "classique" à grande échelle

Si vous n'êtes pas (que) sur du LLM :

Prédictions sur des données tabulaires
Feature engineering complexe
Modèles type XGBoost, LightGBM, réseaux de neurones custom
Millions de prédictions par jour

3. Vous avez des contraintes réglementaires fortes

Secteurs concernés : finance, santé, assurance

Besoin de traçabilité complète (quelle feature, quelle version, quel moment)
Audits de conformité réguliers
Reproductibilité stricte des prédictions

4. Vous avez des features temps réel critiques

Contraintes de performance :

Latence < 10ms requise
Millions de requêtes par seconde
Features calculées en streaming avec fenêtres glissantes

Exemple idéal : une fintech avec 50 modèles de détection de fraude partageant 200+ features temps réel calculées sur des transactions.

5. Votre training-serving skew est un vrai problème

Si vous avez déjà eu des incidents en production à cause de :

Features calculées différemment entre training et serving
Données historiques mal reconstituées
Incohérences temporelles (data leakage)

Un feature store résout ce problème de manière structurelle.

Alternatives au Feature Store

Si vous décidez qu'un feature store complet est overkill pour votre situation, voici les alternatives qui fonctionnent bien en 2025.

1. dbt + Data Warehouse

Pour qui : équipes data matures, features principalement batch

-- models/features/user_activity.sql
{{ config(materialized='table') }}

SELECT
    user_id,
    COUNT(*) as actions_last_7d,
    AVG(amount) as avg_purchase_amount,
    MAX(timestamp) as last_action_at,
    {{ current_timestamp() }} as computed_at
FROM {{ ref('events') }}
WHERE timestamp > {{ current_timestamp() }} - INTERVAL 7 DAYS
GROUP BY user_id

Avantages :

Versioning Git natif
Lineage automatique
Tests intégrés (data quality)
Documentation générée
Vous l'avez probablement déjà

Inconvénients :

Pas de serving temps réel natif
Point-in-time queries manuelles

2. Polars pour features batch haute performance

Pour qui : features complexes, gros volumes, latence batch critique

import polars as pl

features = (
    pl.scan_parquet("events/*.parquet")
    .filter(pl.col("timestamp") > pl.datetime(2025, 1, 1))
    .group_by("user_id")
    .agg([
        pl.count().alias("event_count"),
        pl.col("amount").mean().alias("avg_amount"),
        pl.col("amount").quantile(0.5).alias("median_amount"),
        pl.col("category").mode().first().alias("top_category"),
        pl.col("timestamp").max().alias("last_event")
    ])
    .collect()
)

Polars est 10-100x plus rapide que Pandas pour ces transformations.

3. DuckDB pour l'analytique sans serveur

Pour qui : petites/moyennes équipes, features SQL, pas d'infra à gérer

import duckdb

features = duckdb.query("""
    SELECT
        user_id,
        histogram(category) as category_distribution,
        quantile_cont(amount, 0.5) as median_purchase,
        count(*) as purchase_count
    FROM read_parquet('transactions/*.parquet')
    WHERE timestamp > now() - INTERVAL 30 DAYS
    GROUP BY user_id
""").df()

DuckDB = SQLite pour l'analytique : zéro config, ultra-rapide, in-process.

4. Redis + TTL pour serving temps réel

Pour qui : features temps réel, architecture simple

import redis
from datetime import timedelta

r = redis.Redis()

# Écriture avec expiration automatique
def cache_user_features(user_id, features):
    r.hset(f"user:{user_id}:features", mapping=features)
    r.expire(f"user:{user_id}:features", timedelta(hours=1))

# Lecture en < 1ms
def get_user_features(user_id):
    return r.hgetall(f"user:{user_id}:features")

Avantages : latence < 1ms, simple, mature, vous le connaissez.

5. Le "Feature Store Maison"

Pour qui : équipes tech solides, besoins spécifiques

Combinez les outils ci-dessus :

┌─────────────────────────────────────────────────────────────┐
│                  "FEATURE STORE MAISON"                      │
│                                                              │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│   │    dbt      │───▶│   Parquet   │───▶│   Redis     │     │
│   │ (transform) │    │  (offline)  │    │  (online)   │     │
│   └─────────────┘    └─────────────┘    └─────────────┘     │
│          │                  │                  │            │
│          ▼                  ▼                  ▼            │
│   ┌─────────────────────────────────────────────────┐       │
│   │  Script Python : sync offline → online          │       │
│   │  + validation + monitoring custom               │       │
│   └─────────────────────────────────────────────────┘       │
└─────────────────────────────────────────────────────────────┘

Coût : 2-3 semaines de dev

Maintenance : quelques heures/mois

Avantage : 100% adapté à vos besoins

6. Feature Store Managé Cloud

Pour qui : entreprises déjà sur AWS/GCP/Azure, pas d'envie de gérer l'infra

Cloud	Solution	Points forts
AWS	SageMaker Feature Store	Intégration SageMaker, S3 natif
GCP	Vertex AI Feature Store	BigQuery intégré, monitoring
Azure	Azure ML Feature Store	Synapse, Databricks compatible

Avantages : zéro infra, SLA garantis, intégration native

Inconvénients : vendor lock-in, coûts variables, moins flexible

Les compromis intelligents en 2025

Stratégie Progressive

Phase 1 : MVP (Mois 1-3)

Features calculées dans le pipeline de données existant
Cache Redis simple pour le temps réel
Versioning via Git

Phase 2 : Croissance (Mois 4-6)

Monitoring des features (drift, qualité)
Documentation centralisée
Tests automatisés

Phase 3 : Scale (Mois 7+)

Si vous atteignez les limites → évaluer un vrai feature store

Architecture Hybride

Requête ML
    │
    ├─ Feature simple/stable (80% des cas)
    │   → Cache Redis alimenté par batch job
    │   → Latence < 5ms
    │
    └─ Feature complexe/temps réel (20% des cas)
        → Feature Store (Feast/Tecton)
        → Garanties de cohérence

Avantages : coûts maîtrisés, complexité ciblée, évolutif.

Ma recommandation pour 2025

Commencez sans feature store. Vraiment.

Utilisez vos outils existants :

SQL + data warehouse pour features batch
Cache (Redis/Memcached) pour features temps réel
Git pour le versioning
Tests pour la cohérence

Passez à un feature store seulement si :

Vous atteignez les limites de cette approche
Vous avez 10+ modèles en production
Vous avez des contraintes de latence < 10ms sur features partagées
Votre équipe grandit et a besoin de standardisation

Si vous devez en prendre un :

Open-source : Feast (le plus mature)
Cloud managé : celui de votre cloud provider
Entreprise : Tecton (si budget conséquent)

Conclusion : pragmatisme avant tout

Les feature stores ne sont pas morts en 2025. Mais ils ne sont plus l'outil universel qu'on pensait qu'ils seraient.

Ce qui a changé :

Les LLMs ont réduit le besoin de feature engineering classique
Les outils modernes (DuckDB, Polars, dbt) permettent de faire beaucoup sans feature store
Le coût de complexité est mieux compris

Ce qui reste vrai :

Pour les cas d'usage complexes à grande échelle, ils sont toujours indispensables
La cohérence training/serving reste un problème réel
La réutilisation de features a de la valeur

Mon conseil : évaluez honnêtement votre besoin. Ne déployez pas un feature store "parce que c'est une best practice". Déployez-le quand vous avez un vrai problème qu'il résout mieux que les alternatives.

Et si vous êtes une petite équipe qui débute en MLOps ? Oubliez les feature stores pour l'instant. Concentrez-vous sur mettre vos modèles en production de manière fiable, avec des outils simples. Vous aurez toujours le temps de complexifier plus tard.

---

Et vous, vous utilisez un feature store en 2025 ? Partagez votre expérience dans les commentaires !