Accueil›Blog›Test technique MLOps : CI/CD pour le ML, MLflow, déploiement de modèles

Guide recrutement data

Test technique MLOps : CI/CD pour le ML, MLflow, déploiement de modèles

MLOps est le point de friction entre Data Science et Data Engineering. En entretien, on évalue la capacité à industrialiser un modèle ML : versioning, déploiement, monitoring et retraining automatisé.

Data Builder·Juin 2025·9 min de lecture·Data Scientist · ML Engineer

Sommaire

Principes MLOps
MLflow : tracking et registry
CI/CD pour le ML
Déploiement de modèles
Monitoring et data drift
Feature store
Grille par niveau

Un Data Scientist qui ne peut pas déployer ses modèles en production est un coût, pas une valeur. MLOps est le pont entre le notebook de recherche et le système de production fiable. En entretien, on distingue les profils qui ont réellement industrialisé des modèles de ceux qui ont seulement entraîné des modèles.

1Principes MLOps : les niveaux de maturité

Question discriminante

Décrivez les 3 niveaux de maturité MLOps (MLOps 0, 1, 2). À quel niveau se situe votre organisation actuelle ?

MLOps 0 — Manual : déploiement manuel, un notebook exporté en script, pas de versioning du modèle, pas de monitoring. La plupart des équipes data sont ici
MLOps 1 — ML pipeline automation : pipeline d'entraînement automatisé, versioning avec MLflow, déploiement semi-automatisé, monitoring basique de la performance
MLOps 2 — CI/CD pipeline automation : pipeline complet automatisé de la donnée jusqu'au déploiement, tests automatisés, retraining déclenché automatiquement, monitoring avancé avec alertes

Signal GO Senior : le candidat sait identifier le niveau de maturité de son organisation et peut expliquer les étapes pour progresser vers le niveau supérieur.

2MLflow : tracking, registry et serving

Question discriminante

Quelle est la différence entre MLflow Tracking, MLflow Model Registry et MLflow Serving ?

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier

# MLflow Tracking : loguer les expériences
with mlflow.start_run(run_name="RF_v2_features_v3"):
    mlflow.log_param("n_estimators", 100)
    mlflow.log_param("max_depth", 5)
    
    model = RandomForestClassifier(n_estimators=100, max_depth=5)
    model.fit(X_train, y_train)
    
    accuracy = model.score(X_test, y_test)
    mlflow.log_metric("accuracy", accuracy)
    mlflow.log_metric("f1_score", f1)
    
    # Loguer le modèle avec sa signature
    mlflow.sklearn.log_model(
        model,
        "random_forest",
        signature=infer_signature(X_train, model.predict(X_train))
    )

# MLflow Model Registry : promouvoir vers production
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="churn_predictor",
    version=3,
    stage="Production"  # Staging → Production
)

MLflow Tracking — loguer les paramètres, métriques, artefacts et modèles de chaque expérience
MLflow Model Registry — centraliser et versionner les modèles, gérer les transitions Staging/Production/Archived
MLflow Serving — exposer un modèle comme API REST (mlflow models serve)
Model signature — décrire les inputs/outputs attendus, essentiel pour la validation en production

3CI/CD pour le Machine Learning

Question discriminante

Qu'est-ce qu'un test de modèle ML dans un pipeline CI/CD ? Quels types de tests implémentez-vous ?

Tests de données — valider le schema, les distributions, l'absence de data leakage dans le dataset d'entraînement (Great Expectations, pytest)
Tests de performance — vérifier que le nouveau modèle performe mieux que le modèle en production sur un dataset de validation fixe
Tests de régression — vérifier que les prédictions sur des cas connus n'ont pas changé de manière inattendue
Tests d'inférence — vérifier que le modèle déployé répond correctement (latence, format de réponse)
Shadow mode — déployer le nouveau modèle en parallèle sans l'exposer aux utilisateurs pour comparer les prédictions

# Exemple de test de performance dans un pipeline CI
def test_model_performance():
    model = load_model("models/churn_v3")
    X_test, y_test = load_validation_set()
    
    score = f1_score(y_test, model.predict(X_test))
    baseline = 0.82  # performance du modèle en production actuel
    
    assert score >= baseline * 0.98, (
        f"Nouveau modèle trop faible: {score:.3f} vs baseline {baseline:.3f}"
    )

4Déploiement de modèles en production

Question discriminante

Quelles sont les différentes stratégies de déploiement d'un modèle ML ? Dans quel cas choisissez-vous chacune ?

Stratégie	Description	Cas d'usage
Batch scoring	Pipeline planifié, prédictions en lot stockées en base	Recommandations email nocturnes, scoring client mensuel
Real-time API	FastAPI/Flask, prédiction à la demande, faible latence	Score crédit en temps réel, détection de fraude
Streaming	Kafka + modèle embarqué, prédiction sur chaque event	Anomaly detection temps réel, IoT
Embedded model	Modèle dans l'application (mobile, edge)	NLP offline, vision par ordinateur sur device

Containerisation — Docker + Kubernetes pour le déploiement de l'API, scaling automatique
Canary deployment — exposer 5-10% du trafic au nouveau modèle avant le déploiement complet
A/B testing — comparer deux modèles sur des sous-populations aléatoires pour mesurer l'impact business réel

5Monitoring et data drift

Question discriminante

Qu'est-ce que le concept drift et le data drift ? Comment les détectez-vous en production ?

Data drift — la distribution des features d'entrée change par rapport aux données d'entraînement (ex : le comportement des clients change après une crise économique)
Concept drift — la relation entre les features et la target change (ex : un modèle de churn entraîné avant une pandémie devient obsolète)
Détection : tests statistiques (PSI - Population Stability Index, KS test, chi-squared) sur les distributions des features et prédictions
Outils : Evidently AI, WhyLogs, Arize, Fiddler, ou custom avec Prometheus/Grafana
Alertes — déclencher un retraining automatique quand le drift dépasse un seuil, ou alerter l'équipe

6Feature store

Question discriminante

À quoi sert un feature store ? Dans quel cas en avez-vous besoin ?

Feature store — registre centralisé des features ML, garantit la cohérence entre entraînement et inférence (training-serving skew)
Problème résolu — éviter que les features calculées à l'entraînement soient différentes de celles calculées en production (source majeure de bugs ML)
Outils : Feast (open source), Tecton, Hopsworks, Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS)
Quand en avez-vous besoin ? — plusieurs modèles qui partagent les mêmes features, ou features coûteuses à calculer qui doivent être pré-calculées

7Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	MLflow Tracking, déploiement manuel d'une API FastAPI, containerisation Docker	A loggué des expériences avec MLflow, a dockerisé un modèle, comprend le concept de train/test split	Ne sait pas ce qu'est MLflow, n'a jamais déployé un modèle hors du notebook
Confirmé	MLflow Registry, CI/CD ML basique, tests de performance, batch vs real-time	A promu un modèle via MLflow Registry, a écrit des tests de performance, a déployé en batch et en API	Ne sait pas différencier batch scoring et real-time, n'a pas de tests sur ses modèles
Senior	Pipeline CI/CD complet, monitoring drift, canary deployment, feature store	A implémenté la détection de data drift, a fait du canary deployment, connaît les feature stores	Ne sait pas ce qu'est le data drift, n'a jamais mis en place de monitoring de modèle
Lead	Architecture MLOps 2, standards équipe, A/B testing rigoureux, gouvernance des modèles	A défini l'architecture MLOps de son équipe, a mis en place des A/B tests rigoureux avec analyse d'impact business	Ne peut pas expliquer comment passer de MLOps 0 à MLOps 2 dans son contexte

Vous recrutez un Data Scientist ou ML Engineer ?

Premier entretien gratuit. Rapport GO/NO-GO sous 48h.

Tester gratuitement Réserver un appel