MLOps en 2026 : MLflow, Model Registry et questions d'entretien technique

Les questions d'entretien MLOps sont passées d'une spécialité de niche à un pilier du recrutement en data science et en ingénierie du machine learning en 2026. Les équipes ne demandent plus seulement comment un modèle est entraîné ; elles examinent comment il est suivi, versionné, déployé et supervisé une fois qu'un trafic réel l'atteint. Ce guide parcourt les questions qui reviennent régulièrement dans les entretiens MLOps, regroupées par étape du cycle de vie, avec des exemples MLflow calqués sur des configurations de production.

Questions d'entretien MLOps sur le cycle de vie du machine learning

Q1 : Qu'est-ce que le MLOps et en quoi diffère-t-il du DevOps ?

Le MLOps applique au machine learning les principes du DevOps comme l'automatisation, la CI/CD et la supervision, puis y ajoute trois préoccupations absentes du logiciel traditionnel : le versionnage des données, le versionnage des modèles et la validation continue face aux distributions de données réelles. Dans le DevOps classique, le code est le seul artefact qui change. En MLOps, le code, les données et le modèle entraîné se versionnent chacun de façon indépendante, et n'importe lequel des trois peut dégrader silencieusement la qualité des sorties sans qu'une seule ligne de code ne change. L'article souvent cité Hidden Technical Debt in Machine Learning Systems souligne que le code du modèle ne représente qu'une infime partie d'un système ML réel, où les pipelines de données, la supervision et la configuration dominent la surface.

Q2 : Détaillez les étapes du cycle de vie d'un modèle ML en production.

Une bonne réponse nomme cinq étapes et l'artefact que chacune produit : l'ingestion et la validation des données (un jeu de données versionné), l'expérimentation (des runs suivis avec leurs métriques), l'enregistrement du modèle (un modèle versionné et promouvable), le déploiement (un endpoint de serving ou un job batch) et la supervision (une télémétrie de dérive et de performance qui alimente le réentraînement). Les recruteurs guettent la boucle de rétroaction : la supervision doit reboucler sur l'expérimentation, sinon le système n'est qu'un pipeline à sens unique qui se dégrade avec le temps.

Suivi des expérimentations avec un exemple de tutoriel MLflow

Le suivi des expérimentations est la fondation sur laquelle reposent la plupart des questions MLOps ; une réponse de type tutoriel MLflow qui montre un vrai logging pèse donc lourd. MLflow enregistre les paramètres, les métriques et les artefacts pour chaque run, ce qui rend tout résultat reproductible à partir de son run ID.

Q3 : Comment le suivi MLflow capture-t-il une expérimentation, et pourquoi le run ID est-il déterminant ?

Chaque appel à mlflow.start_run() ouvre un run qui journalise les hyperparamètres, les métriques et le modèle sérialisé. Le run ID est l'identifiant immuable qui relie une métrique au code, aux paramètres et au snapshot de données exacts qui l'ont produite, ce qui rend une expérimentation reproductible des mois plus tard.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

L'argument name remplace le artifact_path déprécié dans MLflow 3.x, un changement qui mérite d'être mentionné pour montrer sa connaissance de l'API actuelle. Les candidats qui évoquent le suivi des features et des jeux de données via les patterns de validation de pipeline ML obtiennent de meilleures notes, car la reproductibilité dépend de l'ensemble du pipeline, pas seulement du modèle.

Model Registry 2026 : versionnage et promotion

Le Model Registry de MLflow transforme un artefact de run en un objet gouverné et promouvable. Le changement récent le plus marquant, et une question fréquente en entretien en 2026, est l'abandon des stages nommés.

Q4 : Comment le Model Registry de MLflow promeut-il un modèle, et qu'est-ce qui a changé en 2026 ?

Les versions antérieures de MLflow promouvaient les modèles à travers des stages fixes nommés Staging, Production et Archived. MLflow 3.x déprécie ces stages au profit des alias et des tags, car une liste de stages figée ne pouvait pas exprimer les topologies de déploiement réelles telles que champion, challenger ou shadow. Un alias est un pointeur mutable vers une version, si bien que la promotion revient à réaffecter l'alias plutôt qu'à modifier le modèle.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Comme les consommateurs chargent models:/churn-classifier@champion, un rollback se résume à une seule réaffectation d'alias vers une version précédente, sans redéploiement. La documentation officielle du Model Registry de MLflow détaille en profondeur la gouvernance des alias et les déclencheurs par webhook.

Patterns de déploiement du machine learning et serving

Les questions de déploiement distinguent les candidats qui ont livré des modèles de ceux qui se sont contentés de les entraîner. Le choix du pattern découle du budget de latence, pas d'une préférence personnelle.

Q5 : Comparez les déploiements batch, online et streaming en machine learning.

| Pattern | Latence | Cas d'usage typique | Surface de serving | |---------|---------|------------------|-----------------| | Batch | De quelques heures au quotidien | Scoring de churn, rafraîchissement des recommandations | Job planifié écrivant dans une table | | Online (temps réel) | Dizaines de millisecondes | Contrôles de fraude, ranking à la requête | Endpoint REST ou gRPC | | Streaming | Infra-seconde, en continu | Détection d'anomalies sur des flux d'événements | Consumer sur une file de messages |

La question de relance porte presque toujours sur la façon de servir le cas online. Un modèle MLflow embarque son propre environnement, si bien que le servir tient en une seule commande pointant vers un URI du registry.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6 : Comment les déploiements blue-green et canary réduisent-ils le risque lors du déploiement d'un modèle ?

Le blue-green maintient deux environnements identiques et bascule tout le trafic d'un coup une fois que le nouveau modèle a passé les contrôles, offrant une voie de rollback instantanée. Le canary route un faible pourcentage du trafic vers la nouvelle version, surveille les métriques en direct, puis monte en charge progressivement. Pour les modèles, le canary est généralement plus sûr, car les problèmes de qualité d'un modèle n'apparaissent que face à des entrées réelles, et un canary limite le rayon d'impact à une fraction des utilisateurs.

Tests et CI/CD pour les pipelines de machine learning

Q7 : Que teste la CI/CD dans un pipeline ML que ne teste pas un pipeline logiciel standard ?

Un pipeline de CI logiciel exécute des tests unitaires et d'intégration sur le code. Un pipeline ML y ajoute des tests de données et de modèle : validation du schéma des données entrantes, contrôles de distribution pour qu'un run d'entraînement n'ingère pas silencieusement des features corrompues, et un quality gate de modèle qui fait échouer le build lorsqu'un candidat obtient un score inférieur au champion actuel sur un jeu de holdout fixe. La livraison continue pour le ML promeut donc un artefact de modèle, et non une simple image de conteneur, et la porte de promotion est un seuil de métrique plutôt qu'une seule suite de tests au vert. Un pipeline rigoureux fige aussi les snapshots de données et les versions de dépendances pour que toute réexécution soit déterministe, ce qui distingue un build reproductible d'un build qui passe par chance aujourd'hui.

Supervision, dérive des données et réentraînement des modèles

Un modèle déployé se dégrade à mesure que le monde évolue sous ses pieds ; c'est donc dans les questions de supervision qu'apparaît le signal de séniorité.

Q8 : Comment détecte-t-on la dérive des données, et quelle métrique la quantifie ?

La dérive des données signifie que la distribution des entrées en production s'est éloignée de la distribution d'entraînement. Le Population Stability Index (PSI) est une mesure courante et indépendante de tout framework : il découpe une distribution de référence en bins, compare les fréquences de production à ces bins, puis somme les différences logarithmiques pondérées.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Au-delà d'une métrique codée à la main, les équipes de production s'appuient sur des outils comme Evidently pour suivre la dérive des features, la dérive de la cible et la qualité des données de façon planifiée. Une réponse complète distingue la dérive des données (les entrées changent) de la dérive de concept (la relation entrée-sortie change), car la seconde ne peut pas être détectée en observant les seules entrées et exige des résultats labellisés.

Q9 : Qu'est-ce qui devrait déclencher un pipeline de réentraînement ?

Le réentraînement à cadence fixe fondé sur le temps est l'option la plus simple, mais il gaspille du calcul quand rien n'a changé et réagit lentement quand quelque chose casse. De meilleurs déclencheurs reposent sur des métriques : réentraîner lorsque le PSI franchit un seuil, lorsqu'une métrique d'évaluation en direct passe sous un plancher, ou lorsqu'un backtest planifié sur des données fraîchement labellisées régresse. Le job de réentraînement enregistre alors un challenger, qu'un déploiement canary compare au champion actuel avant toute réaffectation d'alias.

Questions d'entretien de system design MLOps

Q10 : Concevez une plateforme qui sert des centaines de modèles avec des features cohérentes.

La pièce maîtresse attendue est un feature store, qui résout le training-serving skew en calculant les features une seule fois et en servant des valeurs identiques à l'entraînement comme à l'inférence. Des outils comme Feast fournissent un store offline pour l'entraînement et un store online à faible latence pour le serving. Une conception complète nomme aussi un model registry pour le versionnage, un serveur de tracking pour le lignage, un orchestrateur pour les pipelines et une couche de supervision qui reboucle vers le réentraînement. Ancrer la réponse dans un vrai travail sur les features, comme les compromis abordés dans ce guide d'entretien sur le feature engineering, révèle une expérience de terrain plutôt qu'une simple récitation de schéma.

Conclusion

• Présenter le MLOps comme du DevOps augmenté du versionnage des données et des modèles : reproductibilité, sûreté de la promotion et supervision sont les trois axes que notent les recruteurs
• Connaître l'évolution de l'API MLflow 3.x : les alias et les tags remplacent les stages Staging et Production dépréciés, et log_model prend désormais name au lieu de artifact_path
• Adapter le pattern de déploiement au budget de latence, et privilégier le canary au blue-green pour les déploiements de modèles, car les problèmes de qualité n'apparaissent que face à des entrées réelles
• Quantifier la dérive avec une métrique concrète comme le PSI, et distinguer la dérive des données de la dérive de concept, puisqu'une seule est visible sans labels
• Déclencher le réentraînement sur des métriques plutôt que sur le calendrier, et faire passer le challenger obtenu par un canary avant de réaffecter l'alias champion
• Nommer un feature store dans toute réponse de system design pour combler le training-serving skew avant qu'il ne soit soulevé en relance