AccueilBlogTest 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

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égieDescriptionCas d'usage
Batch scoringPipeline planifié, prédictions en lot stockées en baseRecommandations email nocturnes, scoring client mensuel
Real-time APIFastAPI/Flask, prédiction à la demande, faible latenceScore crédit en temps réel, détection de fraude
StreamingKafka + modèle embarqué, prédiction sur chaque eventAnomaly detection temps réel, IoT
Embedded modelModè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

NiveauMaîtrise attendueSignal GONO-GO
JuniorMLflow Tracking, déploiement manuel d'une API FastAPI, containerisation DockerA loggué des expériences avec MLflow, a dockerisé un modèle, comprend le concept de train/test splitNe 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-timeA promu un modèle via MLflow Registry, a écrit des tests de performance, a déployé en batch et en APINe sait pas différencier batch scoring et real-time, n'a pas de tests sur ses modèles
SeniorPipeline CI/CD complet, monitoring drift, canary deployment, feature storeA implémenté la détection de data drift, a fait du canary deployment, connaît les feature storesNe sait pas ce qu'est le data drift, n'a jamais mis en place de monitoring de modèle
LeadArchitecture MLOps 2, standards équipe, A/B testing rigoureux, gouvernance des modèlesA défini l'architecture MLOps de son équipe, a mis en place des A/B tests rigoureux avec analyse d'impact businessNe 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 gratuitementRéserver un appel