Feature stores : en avez-vous vraiment besoin ?

Ce qu'un feature store résout vraiment

Un feature store répond à trois douleurs précises :

• Le training-serving skew : les features calculées à l'entraînement divergent de celles calculées en production, car elles sont implémentées deux fois.
• La duplication : cinq équipes recalculent chacune « l'ancienneté client » à leur manière, avec cinq définitions légèrement différentes.
• Le point-in-time correctness : garantir qu'une feature d'entraînement n'utilise que des données disponibles à l'instant de la décision — la fuite temporelle est le bug le plus sournois du ML.

Si aucune de ces phrases ne vous fait grimacer de reconnaissance, un feature store ne résoudra rien pour vous.

Ce qu'il coûte (rarement dans la brochure)

En contrepartie, vous ajoutez : une infrastructure à opérer (stores online/offline, synchro entre les deux), un modèle conceptuel à enseigner à chaque nouvelle recrue, une dépendance centrale — quand le feature store tombe, tous les modèles tombent — et une friction au quotidien : ajouter une feature devient un projet, pas une ligne de code.

Les cinq questions à se poser

1. Combien de modèles partagent les mêmes features ? En dessous de trois, la mutualisation ne paie pas.
2. Avez-vous déjà subi un incident de training-serving skew ? Un vrai, documenté — pas une crainte théorique.
3. Vos features temps réel existent-elles ? Si tout est batch quotidien, une vue SQL matérialisée suffit.
4. Qui l'opèrera ? Sans plateforme dédiée, le store devient le fardeau de l'équipe qui l'a demandé.
5. Quel est le plan de sortie ? Si migrer hors de l'outil est inenvisageable, n'y entrez pas à la légère.

Mon arbitrage, et l'alternative simple

Dans mon contexte — quatre modèles en production, features batch — la réponse a été non. À la place, nous avons :

-- Un schéma dédié "features", des tables versionnées par date de calcul
-- et UNE définition SQL partagée entre entraînement et scoring
CREATE TABLE features.customer_recency AS
SELECT
    customer_id,
    CURRENT_DATE - MAX(order_date) AS days_since_last_order,
    COUNT(*)                       AS total_orders,
    SUM(amount)                    AS lifetime_value
FROM orders
GROUP BY customer_id;

-- Le pipeline d'entraînement ET le job de scoring lisent la même table.
-- Une seule définition = zéro skew.

Le jour où nous aurons dix modèles temps réel partageant des features, je revisiterai la décision — avec le sourire, car elle se justifiera alors d'elle-même.