Model Registry : versionner et gouverner ses modèles en production

Entre le notebook où un modèle est entraîné et le service qui le sert en production, il existe un maillon souvent improvisé : un fichier pickle déposé sur un stockage partagé, un nom de dossier suffixé par « final_v2 », un message Slack pour annoncer la mise en production. Ces pratiques fonctionnent tant qu'une seule personne gère un seul modèle, puis elles s'effondrent dès qu'il faut savoir quelle version tourne, qui l'a validée et avec quelles données elle a été produite. Le Model Registry répond à ce besoin en centralisant le versionnement, les métadonnées et le cycle de vie des modèles.

Comment retrouver le modèle exact qui a produit une prédiction contestée il y a trois mois ? Comment basculer en quelques secondes vers la version précédente après une régression ? Comment imposer qu'aucun modèle n'atteigne la production sans avoir passé des tests et reçu une approbation ? Ces questions deviennent incontournables dès que l'on industrialise le Machine Learning, et elles se posent aussi bien pour un modèle de scoring que pour un modèle de langage.

Le registre de modèles est la brique qui fait le lien entre l'entraînement et le déploiement. Il est proposé par MLflow, par Databricks avec Unity Catalog, par Vertex AI et par SageMaker, avec des vocabulaires proches mais des mécanismes différents. Dans cet article, nous allons expliquer le rôle d'un registre, détailler ses concepts clés avec un exemple MLflow, décrire un workflow de promotion et son intégration en CI/CD, puis comparer les principales offres du marché.

À quoi sert un Model Registry ?

Un registre de modèles est un catalogue centralisé où chaque modèle entraîné est enregistré, versionné et documenté. Il ne remplace ni le suivi d'expériences, qui conserve l'historique de tous les essais, ni la plateforme de service, qui exécute le modèle. Il s'insère entre les deux : seuls les modèles jugés dignes d'intérêt y sont enregistrés, et c'est de là que partent les déploiements.

Un point de vérité unique

Sans registre, la question « quel modèle est en production ? » n'a pas de réponse fiable. Le code de déploiement pointe vers un chemin de stockage, ce chemin a été écrasé par un réentraînement, et personne ne sait si le fichier actuel correspond à celui qui a été testé. Le registre impose une identité stable : un nom de modèle, un numéro de version immuable et une référence vers l'artefact exact.

Cette immutabilité est la propriété centrale. Une version enregistrée ne change jamais, ce qui permet de la tester, de l'auditer et de la redéployer à l'identique. Pour faire évoluer le modèle, on crée une nouvelle version, jamais une modification de l'ancienne.

Ce que le registre apporte à l'équipe

Au-delà du simple stockage, un registre apporte plusieurs bénéfices concrets :

• Reproductibilité : chaque version est reliée à l'exécution d'entraînement qui l'a produite, avec son code, ses hyper-paramètres et ses données.
• Retour arrière rapide : repasser à la version précédente consiste à déplacer une référence, sans réentraîner ni redéployer manuellement.
• Collaboration : Data Scientists, ML Engineers et équipes métier consultent le même catalogue, avec les mêmes descriptions et les mêmes métriques.
• Conformité : on sait qui a approuvé quoi et quand, ce qui facilite les audits, notamment pour les modèles encadrés par des exigences réglementaires.

Le registre s'appuie sur des outils de suivi comme MLflow, qui conservent l'historique des expériences, et sur des catalogues de features comme Feast qui garantissent la cohérence des données d'entrée.

À lire : découvrez notre formation MLOps

Les concepts clés d'un registre

Les vocabulaires varient d'une plateforme à l'autre, mais on retrouve partout les mêmes notions : un modèle enregistré, des versions, un moyen de désigner la version active et des métadonnées.

Versions, alias et stages

Un modèle enregistré (registered model) regroupe toutes les versions d'un même modèle métier, par exemple un modèle de détection de fraude. Chaque enregistrement crée une version numérotée, qui pointe vers un artefact figé.

Pour désigner la version à utiliser, deux mécanismes coexistent. Les stages (None, Staging, Production, Archived) ont longtemps été la solution de MLflow : ils imposent un cycle de vie linéaire, avec une seule version par stage. MLflow les a depuis dépréciés au profit des alias, des références nommées et modifiables que l'on associe librement à une version, comme champion ou challenger. Un alias est plus souple : on peut en définir autant que nécessaire, par exemple un par environnement, et le code de chargement reste identique quelle que soit la version ciblée.

Métadonnées et lignage

Une version de modèle sans contexte a peu de valeur. Un bon registre conserve plusieurs familles d'informations :

• Métriques et paramètres : performance mesurée sur le jeu de test, hyper-paramètres, version de la bibliothèque d'entraînement.
• Lignage : le run d'entraînement, le commit du code, la version ou l'empreinte du jeu de données. C'est l'extension, côté modèles, du Data Lineage appliqué aux données.
• Signature : le schéma des entrées et des sorties attendues, qui permet de détecter une incompatibilité avant le déploiement.
• Tags et description : propriétaire, cas d'usage, statut de validation, limites connues du modèle.

Enregistrer et charger un modèle avec MLflow

Voici un exemple avec MLflow, qui enregistre un modèle à la fin d'un entraînement, lui associe des tags puis le désigne comme candidat grâce à un alias :

import mlflow
from mlflow import MlflowClient
from mlflow.models import infer_signature
from sklearn.ensemble import RandomForestClassifier

mlflow.set_tracking_uri("http://mlflow.interne:5000")
client = MlflowClient()

# Entraînement et enregistrement du modèle dans le registre
model = RandomForestClassifier(n_estimators=200).fit(X_train, y_train)
signature = infer_signature(X_train, model.predict(X_train))

with mlflow.start_run() as run:
    mlflow.log_metric("f1", f1_score(y_test, model.predict(X_test)))
    mlflow.sklearn.log_model(
        model,
        name="model",
        signature=signature,
        registered_model_name="fraud_detector",
    )

# Récupération de la dernière version créée
version = client.search_model_versions("name='fraud_detector'")[0].version

# Métadonnées de lignage et de validation
client.set_model_version_tag("fraud_detector", version, "dataset", "transactions_2026_10")
client.set_model_version_tag("fraud_detector", version, "validation_status", "pending")

# Le modèle devient candidat à la production
client.set_registered_model_alias("fraud_detector", "challenger", version)

Le paramètre registered_model_name crée le modèle enregistré s'il n'existe pas, puis ajoute une version. Les tags portent l'information de lignage et de validation. L'alias challenger désigne la version à évaluer, sans toucher à celle qui sert la production. Côté consommation, le service d'inférence charge toujours le modèle par son alias :

import mlflow

# Le code ne change pas quand l'alias est déplacé vers une autre version
model = mlflow.pyfunc.load_model("models:/fraud_detector@champion")
predictions = model.predict(batch)

Pour promouvoir une version, il suffit de réaffecter l'alias champion : le prochain chargement utilisera le nouveau modèle, et le retour arrière revient à replacer l'alias sur l'ancienne version.

Workflow de promotion et approbation

Le registre devient réellement utile lorsqu'il structure le chemin d'un modèle vers la production. Ce chemin suit généralement les mêmes étapes, quelle que soit la plateforme.

Du candidat à la production

Le parcours typique d'un modèle comporte quatre temps :

• Enregistrement : la fin de l'entraînement crée une nouvelle version, marquée comme candidate.
• Validation automatique : des tests vérifient la performance minimale, l'absence de régression face au modèle actuel, la compatibilité de la signature et parfois des critères d'équité.
• Approbation : un humain, par exemple un responsable métier ou un référent risque, valide la mise en production quand le contexte l'exige.
• Promotion : l'alias de production est déplacé vers la nouvelle version, et la version précédente reste disponible pour un retour arrière.

Le niveau de rigueur dépend du risque. Un modèle de recommandation peut être promu automatiquement dès que les tests passent, alors qu'un modèle de crédit exigera une approbation formelle et une trace conservée.

Intégration dans une chaîne CI/CD

La promotion s'automatise dans une chaîne d'intégration continue, par exemple avec GitLab CI/CD. Le principe est de séparer le pipeline qui entraîne le modèle de celui qui le déploie : le premier enregistre une version, le second réagit à son apparition. Voici un exemple de pipeline de promotion :

stages:
  - validate
  - approve
  - promote

validate_model:
  stage: validate
  script:
    - python scripts/validate_model.py --name fraud_detector --alias challenger
  rules:
    - if: $CI_PIPELINE_SOURCE == "trigger"

approve_model:
  stage: approve
  script:
    - echo "Approbation manuelle requise avant la mise en production"
  when: manual
  needs: [validate_model]

promote_model:
  stage: promote
  script:
    - python scripts/promote.py --name fraud_detector --from challenger --to champion
  needs: [approve_model]

Le script de validation charge la version challenger, calcule ses métriques sur un jeu de référence et les compare à celles de la version champion. L'étape manuelle matérialise l'approbation, et le script de promotion déplace l'alias. Le déploiement lui-même peut ensuite être déclenché par un outil GitOps ou par un serveur d'inférence comme KServe, qui recharge le modèle désigné. Pour les modèles de langage, ces mêmes principes s'étendent aux prompts et aux configurations, comme le décrit l'article sur le LLMOps.

Le registre ferme aussi la boucle avec la surveillance : lorsqu'une dérive est détectée, comme on le voit dans l'article sur le Data Drift et le Concept Drift, le pipeline de réentraînement crée une nouvelle version qui repasse par le même parcours de validation.

À découvrir : notre formation MLOps

Comparer les principales offres

Les grandes plateformes proposent chacune un registre, intégré à leur écosystème. Les concepts sont proches, mais les modèles de gouvernance diffèrent.

MLflow est la solution open source de référence : elle est portable et simple à adopter, mais la gestion des accès et l'exploitation du serveur restent à la charge de l'équipe. Unity Catalog place les modèles dans le même catalogue que les tables, sous un espace de noms à trois niveaux (catalogue, schéma, modèle). Le lignage entre données, modèles et notebooks est alors capturé automatiquement, et les droits d'accès sont uniformes. On l'utilise avec MLflow en pointant le registre vers databricks-uc.

Vertex AI Model Registry gère les versions d'un modèle et s'intègre aux pipelines et aux endpoints de Google Cloud, avec des alias pour désigner la version à servir. SageMaker Model Registry organise les versions en groupes de modèles et expose un statut d'approbation (en attente, approuvé ou rejeté). Le changement de statut peut déclencher un déploiement, ce qui en fait un mécanisme d'approbation natif.

Comment choisir ?

Le choix dépend avant tout de l'écosystème existant. Une organisation standardisée sur Databricks, AWS ou Google Cloud a intérêt à utiliser le registre natif, qui réduit la charge d'exploitation et s'intègre aux outils de sécurité de la plateforme. Une équipe multi-cloud, ou souhaitant conserver la maîtrise de sa stack, se tournera vers MLflow, qui fonctionne partout, y compris sur Kubernetes. Dans tous les cas, les bonnes pratiques restent les mêmes : des noms de modèles explicites, des versions immuables, un lignage renseigné systématiquement et une promotion qui passe par un pipeline plutôt que par une action manuelle ponctuelle.

Conclusion

Un registre de modèles apporte au Machine Learning ce que le gestionnaire de versions apporte au code : une identité stable, un historique et la possibilité de revenir en arrière. En enregistrant chaque modèle sous forme de version immuable, accompagnée de ses métriques, de sa signature et de son lignage, il rend les déploiements reproductibles et les audits possibles.

Les alias, qui ont remplacé les stages dans MLflow, offrent un moyen souple de désigner la version active et de promouvoir un modèle sans modifier le code d'inférence. Associés à un pipeline de validation, à une étape d'approbation et à une chaîne CI/CD, ils transforment la mise en production en un processus traçable. Face aux offres de MLflow, d'Unity Catalog, de Vertex AI et de SageMaker, c'est surtout l'écosystème existant et le niveau de gouvernance attendu qui orientent la décision.

Savoir structurer le cycle de vie des modèles, de l'entraînement à la mise en production, est devenu une compétence différenciante pour les Machine Learning Engineers et les Data Scientists. Le registre est la brique qui permet de passer d'un modèle qui fonctionne dans un notebook à un service fiable et gouverné.