Le métier de ML Engineer
C'est quoi, un ML Engineer ?
Un Machine Learning Engineer est l'ingénieur qui fait passer un modèle de machine learning du notebook à la production — et qui l'y maintient en vie. Là où le data scientist explore les données et prototype des modèles, le MLE construit le système qui entraîne, déploie, sert et surveille ces modèles, à l'échelle, de façon fiable et reproductible.
Concrètement, une semaine type de MLE ressemble à ça :
- transformer le notebook d'un data scientist en pipeline d'entraînement versionné et testé ;
- exposer un modèle derrière une API à faible latence (tiens, tiens…) ;
- mettre en place le monitoring : le modèle dérive-t-il ? les données d'entrée ont-elles changé ?
- optimiser les coûts : batching des requêtes, quantization, choix GPU/CPU ;
- automatiser le réentraînement quand les performances baissent.
MLE vs Data Scientist vs Data Engineer
| Rôle | Question centrale | Livrable typique |
|---|---|---|
| Data Scientist | « Que disent les données ? Quel modèle prédit le mieux ? » | Notebook, rapport, prototype de modèle |
| ML Engineer | « Comment ce modèle tourne-t-il en prod, vite et sans casser ? » | Pipeline, API de serving, monitoring |
| Data Engineer | « Comment les données arrivent-elles propres et à l'heure ? » | Pipelines de données, entrepôt, orchestration |
Les frontières sont poreuses — dans une petite boîte, une même personne porte souvent deux casquettes. Mais retiens le centre de gravité : le MLE est un ingénieur logiciel d'abord. C'est pour ça que la transition backend → MLE est l'une des plus naturelles qui soient.
Pourquoi ton profil backend est un atout (et pas un retard)
La partie difficile du ML en production n'est pas le modèle. Le papier fondateur de Google, Hidden Technical Debt in Machine Learning Systems (2015), le montre avec un schéma célèbre : le code ML est une petite boîte noire au milieu d'un océan d'infrastructure — ingestion de données, gestion de configuration, serving, monitoring… Autrement dit : 80 % du métier de MLE, tu le pratiques déjà.
Ce que tu as déjà :
- API & réseau : le serving de modèle est un problème de latence p99, de timeouts et de backpressure ;
- Bases de données & SQL : le feature engineering commence presque toujours par des requêtes ;
- CI/CD, Docker, tests : le MLOps, c'est littéralement appliquer ça aux modèles ;
- Debugging de systèmes distribués : un entraînement multi-GPU qui plante, ça se débogue comme un système distribué.
Ce qui te manque (et que ce cours couvre) :
- l'intuition mathématique minimale utile (pas de doctorat requis — des gradients et des distributions) ;
- le vocabulaire et les concepts du ML (features, loss, overfitting, métriques) ;
- les outils de l'écosystème (numpy, pandas, scikit-learn, PyTorch, MLflow…) ;
- les patterns de conception propres aux systèmes ML (feature store, batch vs temps réel, drift).
Le marché, en deux mots
La demande de MLE a explosé avec les LLMs : les entreprises ont compris qu'un modèle sans ingénierie de production ne vaut rien. Les offres « LLM Engineer », « AI Engineer » ou « MLOps Engineer » sont des variantes du même cœur de métier — celui que tu vas apprendre ici.
À retenir : le MLE est un ingénieur logiciel spécialisé. Ta base backend n'est pas un point de départ lointain — c'est déjà 80 % du chemin. Le cours se concentre sur les 20 % restants.