Feature store de zéro : les cinq composants d'une implémentation minimale fonctionnelle

Un feature store est une couche d'architecture qui centralise le calcul et le stockage des features des modèles de ML. L'analyse montre comment bâtir de zéro une implémentation minimale fonctionnelle, et où l'ère de l'IA réécrit le schéma classique.

Cinq composants obligatoires

Sans l'un d'eux, on se retrouve soit avec du code dupliqué, soit avec un décalage entre l'entraînement et l'inférence — le problème classique du training-serving skew.

• Ingestion pipeline — couche de chargement depuis les sources (Kafka, S3, Postgres) : elle calcule les features et les écrit dans le stockage
• Offline store — données historiques pour l'entraînement des modèles (Parquet ou Delta Lake sur S3)
• Online store — stockage à faible latence pour l'inférence en temps réel (Redis, DynamoDB)
• Feature registry — catalogue de métadonnées : nom, type, version, propriétaire, lineage
• Monitoring — suivi de la dérive des données et de la freshness de chaque feature

Une implémentation minimale tient en 200–300 lignes de Python : SQLite à la place d'un véritable offline store, Redis comme online store, fichiers YAML en guise de registre.

Comment est construite l'implémentation minimale

Les auteurs proposent de commencer avec trois fichiers. `feature_store.py` est le cœur, avec les méthodes `write()` et `read()` qui abstraient la séparation offline/online. `registry.yaml` contient les descriptions déclaratives des features. `pipeline.py` est un script ETL qui appelle `feature_store.write()` après chaque transformation.

Cette structure couvre la plupart des cas réels. Il ne faut la complexifier que lorsque des exigences concrètes apparaissent : inférence à forte charge, point-in-time lookups sans data leakage ou données en flux continu.

« La plupart des équipes surcomplexifient leur feature store au départ.

Commencez avec SQLite et YAML — vous serez surpris de voir jusqu'où cela vous mène. »

Là où l'IA réécrit les règles

Le schéma classique s'articulait autour de features numériques et catégorielles. L'ère des LLM ajoute trois nouvelles exigences.

Les embeddings vectoriels sont devenus des features de premier rang. On peut les stocker dans Redis, mais la recherche se fait par proximité et non par clé. Cela impose des index vectoriels (pgvector, Pinecone, Weaviate) et modifie le schéma de l'online store.

La génération automatique de features. Le feature engineering était jusqu'ici un processus manuel. Désormais, un LLM peut proposer une liste de features à partir de la description du problème, ou générer une transformation à partir d'un exemple de données d'entrée.

L'assistant LLM pour le registre. La documentation des features a toujours été mal renseignée. Un modèle de langage génère automatiquement descriptions et tags en analysant le code des transformations, sans intervention d'un ingénieur.

Ce que cela signifie

Le feature store n'est plus le privilège des grandes plateformes ML : on peut en assembler un en une journée à partir de composants open source. L'IA n'abolit pas ce pattern, elle l'étend : on y ajoute des stockages vectoriels et des métadonnées assistées par LLM. Si vous construisez un système ML sans feature store, c'est le moment d'ajouter cette couche.