Le problème à résoudre
Chaque data scientist recalcule dans son coin les mêmes variables (features), avec des définitions divergentes entre l’entraînement et la production. Résultat : duplication, incohérences et modèles qui se dégradent une fois déployés.
La promesse pour la direction
Votre data engineer met en place un feature store : un référentiel central de variables ML fiables, partagées et cohérentes entre entraînement et production — accélérant et fiabilisant tous les projets d’IA.
Ce que le parcours débloque
Garantie
Cohérence train/production
Mutualisée
Duplication des features
Accéléré
Délai de mise en production ML
Le cadre
| Élément | Valeur |
|---|---|
| Profil cible | Data engineer / ML engineer |
| Prérequis | Pipelines, Python, bases ML |
| Durée | 5 mois |
| Format | Blended · 70 % de pratique |
Pile technique maîtrisée à l’issue
Feast · Python · Spark · Redis · PostgreSQL · Airflow · Parquet
Les jalons
Une trajectoire pour un collaborateur déjà en poste. Chaque mois est validé par un livrable et un critère d’acceptation écrit à l’avance.
| Mois | Thème | Atelier | Validation |
|---|---|---|---|
| M1 | Problème des features Cohérence ML | Comprendre l’écart entr aînement/production | ✔ Écarts identifiés |
| M2 | Feature engineering industriel Calcul fiable | Industrialiser le calcul d’une feature | ✔ Feature calculée de façon fiable |
| M3 | Feature store Référentiel central | Mettre en place un feature store | ✔ Features centralisées et partagées |
| M4 | Cohérence online/offline Train/serve consistency | Garantir la même feature partout | ✔ Cohérence entraîn ement/production |
| M5 | Réutilisation Partage entre équipes | Partager les features entre projets | ✔ Features réutilisées entre équipes |
| M6 | Projet feature store Cas réel | Outiller un projet ML réel | ✔ Soutenance + cohérence prouvée |