Feature Store vs Data Warehouse : que choisir pour un projet IA ?

Feature store ou data warehouse ? Cette question revient systématiquement quand une équipe data commence à industrialiser ses modèles ML. La confusion est compréhensible : les deux stockent des données, les deux alimentent des modèles. Mais leurs objectifs et architectures sont fondamentalement différents.

Ce guide compare objectivement ces deux solutions pour vous aider à faire le bon choix selon votre contexte.

Tableau comparatif synthétique

Comprendre les différences fondamentales

Data Warehouse : analyse du passé

Un data warehouse est conçu pour répondre à des questions business :

• Quel était le chiffre d'affaires du Q3 par région ?
• Quels produits ont le meilleur taux de conversion ?
• Comment évoluent les coûts d'acquisition client ?

-- Requête typique data warehouse
SELECT
    region,
    product_category,
    SUM(revenue) as total_revenue,
    COUNT(DISTINCT customer_id) as unique_customers
FROM fact_sales
JOIN dim_product ON fact_sales.product_id = dim_product.id
JOIN dim_date ON fact_sales.date_id = dim_date.id
WHERE dim_date.quarter = 'Q3-2025'
GROUP BY region, product_category
ORDER BY total_revenue DESC;

Architecture typique :

Sources → ETL → Data Warehouse → BI Tools
                     ↓
              Marts analytiques

Feature Store : prédiction du futur

Un feature store est conçu pour alimenter des modèles ML en production :

• Quelles features donner au modèle pour prédire si ce client va churner ?
• Comment récupérer en 5ms les 50 features nécessaires à la détection de fraude ?
• Comment garantir que les features en production sont identiques à l'entraînement ?

features = feature_store.get_online_features(
    entity_rows=[{"customer_id": "C12345"}],
    features=[
        "customer:avg_purchase_30d",
        "customer:days_since_last_order",
        "customer:lifetime_value",
        "customer:support_tickets_90d"
    ]
)

Architecture typique :

Sources → Feature Pipeline → Feature Store → ML Models
                                  ↓
                         Offline Store (training)
                         Online Store (inference)

Cas d'usage : qui utilise quoi ?

Data Warehouse uniquement

Scénario : Équipe data classique sans ML en production

• Reporting et dashboards
• Analyses ad-hoc
• Data science exploratoire (notebooks)
• Modèles batch simples alimentés par requêtes SQL

import pandas as pd
from sklearn.ensemble import RandomForestClassifier

query = """
SELECT customer_id, age, tenure, monthly_spend, is_churned
FROM analytics.customer_features
WHERE snapshot_date = CURRENT_DATE - 1
"""
df = pd.read_sql(query, dwh_connection)

X = df[["age", "tenure", "monthly_spend"]]
y = df["is_churned"]
model = RandomForestClassifier().fit(X, y)

Feature Store uniquement

Scénario : Startup ML-first sans legacy BI

• Modèles temps réel uniquement
• Pas de besoins analytiques complexes
• Équipe ML sans analystes BI
• Sources de données directement dans le feature store

from feast import FeatureStore

fs = FeatureStore(repo_path=".")

@feature_view(entities=[customer], ttl=timedelta(days=1))
def customer_features(transactions: DataFrame):
    return transactions.groupby("customer_id").agg(...)

training_df = fs.get_historical_features(
    entity_df=entities,
    features=["customer_features:avg_spend", "customer_features:frequency"]
).to_df()

online_features = fs.get_online_features(
    entity_rows=[{"customer_id": "123"}],
    features=["customer_features:avg_spend"]
)

Les deux ensemble (architecture moderne)

Scénario : Entreprise mature avec BI et ML en production

┌─────────────────┐
                    │   Data Sources  │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │   Data Lake     │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            │                │                │
   ┌────────▼────────┐ ┌─────▼─────┐ ┌────────▼────────┐
   │  Data Warehouse │ │  Feature  │ │  Operational    │
   │  (Snowflake,    │ │   Store   │ │  Database       │
   │   BigQuery)     │ │  (Feast,  │ │  (PostgreSQL)   │
   │                 │ │   Tecton) │ │                 │
   └────────┬────────┘ └─────┬─────┘ └─────────────────┘
            │                │
   ┌────────▼────────┐ ┌─────▼─────┐
   │   BI & Reports  │ │ ML Models │
   │   (Tableau,     │ │ (Training │
   │    Looker)      │ │ + Serving)│
   └─────────────────┘ └───────────┘

Flux de données :

1. Le data lake centralise les données brutes
2. Le data warehouse agrège pour l'analyse
3. Le feature store transforme pour le ML
4. Chaque outil sert son audience

Critères de choix détaillés

1. Latence requise

Exemple concret :

df = spark.sql("SELECT ... FROM sales_mart").toPandas()  # 2-5 secondes OK

features = fs.get_online_features(...)  # Doit être <10ms
prediction = model.predict(features)     # Avant que la transaction timeout

2. Type de requêtes

Data warehouse - Agrégations sur des ensembles :

-- "Quel est le panier moyen par segment ?"
SELECT segment, AVG(basket_value)
FROM orders
GROUP BY segment;

Feature store - Lookup par entité :

features = fs.get_online_features(
    entity_rows=[{"customer_id": "C789"}],
    features=["customer:*"]
)

3. Cohérence training/serving

Le data warehouse ne garantit pas la cohérence entre entraînement et production :

train_df = dwh.query("SELECT * FROM features WHERE date = '2025-01-01'")
model.fit(train_df)

prod_features = dwh.query("SELECT * FROM features WHERE date = CURRENT_DATE")

Le feature store garantit la cohérence par design :

@feature_view
def customer_features(transactions):
    return transactions.groupby("customer_id").agg(
        avg_amount=("amount", "mean")  # Définition unique
    )

train_df = fs.get_historical_features(...)

prod_features = fs.get_online_features(...)

4. Point-in-time correctness

Pour le ML, vous devez éviter le data leakage : utiliser des données du futur pour prédire le passé.

Data warehouse - Risque de leakage :

-- DANGER : cette requête utilise les données actuelles
-- pour des événements passés
SELECT
    o.order_id,
    o.order_date,
    c.current_lifetime_value  -- Valeur ACTUELLE, pas au moment de la commande
FROM orders o
JOIN customers c ON o.customer_id = c.id;

Feature store - Point-in-time correct :

training_df = fs.get_historical_features(
    entity_df=orders_df,  # Contient order_id, customer_id, event_timestamp
    features=["customer:lifetime_value"]
)

5. Gouvernance et découverte

Patterns d'intégration

Pattern 1 : Feature Store alimenté par le Data Warehouse

Le data warehouse fait les transformations lourdes, le feature store sert le ML :

features_df = spark.sql("""
    SELECT
        customer_id,
        AVG(amount) as avg_purchase_30d,
        COUNT(*) as order_count_30d,
        MAX(order_date) as last_order_date
    FROM dwh.fact_orders
    WHERE order_date >= CURRENT_DATE - 30
    GROUP BY customer_id
""")

fs.materialize_incremental(
    feature_views=["customer_features"],
    end_date=datetime.now()
)

Pattern 2 : Feature Store temps réel, DWH batch

Événements temps réel ──→ Feature Store (streaming)
                                  │
                                  ▼
                         Modèles temps réel

Données historiques ──→ Data Warehouse ──→ Rapports BI
                              │
                              ▼
                    Feature Store (batch sync)

Pattern 3 : Synchronisation bidirectionnelle

spark.sql("SELECT ... FROM dwh.customer_agg").write.to_feature_store()

predictions_df = model.predict_batch(fs.get_historical_features(...))
predictions_df.write.to_dwh("ml.predictions")

Matrice de décision

Choisissez un Data Warehouse seul si :

• Votre équipe fait principalement du reporting et de l'analyse
• Vos modèles ML tournent en batch (quotidien ou moins fréquent)
• Vous n'avez pas de contraintes de latence (<1 seconde)
• Votre feature engineering est simple (agrégations SQL)
• Vous avez 1-2 modèles en production maximum

Choisissez un Feature Store seul si :

• Vous êtes une startup ML-first sans legacy BI
• Tous vos modèles nécessitent du temps réel
• Vous n'avez pas de besoins analytiques business
• Votre équipe est 100% ML engineering

Utilisez les deux si :

• Vous avez des besoins BI ET des modèles ML temps réel
• Plusieurs équipes (analystes + ML engineers) travaillent sur les mêmes données
• Vous avez des contraintes de latence pour certains cas d'usage
• Vous voulez mutualiser le feature engineering

Coûts comparés

Data Warehouse (exemple Snowflake)

Feature Store (exemple Feast + Redis)

Feature Store managé (exemple Tecton)

Recommandations par maturité

Conclusion

Data warehouse et feature store ne sont pas interchangeables :

• Le data warehouse excelle pour l'analyse, le reporting, et l'exploration des données
• Le feature store excelle pour servir des features ML en temps réel avec cohérence garantie

La plupart des organisations matures ont besoin des deux, chacun servant son audience et ses cas d'usage. L'erreur courante est de vouloir utiliser le data warehouse comme feature store (trop lent, pas de cohérence training/serving) ou inversement (le feature store n'est pas fait pour l'analyse).

Commencez par le data warehouse si vous débutez en ML. Ajoutez un feature store quand vous avez des contraintes de latence ou plusieurs modèles partageant des features.

Pour approfondir les cas d'usage du feature store, consultez notre article : Feature Store : quand est-ce vraiment indispensable en production IA ?

Pour une vue d'ensemble sur les feature stores : Feature Store en 2025 : est-ce encore utile en production IA ?