Accueil › Glossaire › Model Versioning

Model Versioning

Le model versioning (ou versionnage de modèles) est la pratique qui consiste à suivre, stocker et gérer systématiquement les différentes versions d’un modèle de machine learning tout au long de son cycle de vie, depuis l’entraînement jusqu’au déploiement en production.

Si vous avez déjà perdu un modèle performant parce que personne ne savait quel jeu de données, quels hyperparamètres ou quel commit de code l’avait produit, vous comprenez immédiatement l’intérêt du model versioning. C’est l’équivalent de Git pour vos modèles ML : chaque itération est enregistrée, traçable et réversible. Sans cette discipline, la mise en production de modèles devient de l’archéologie forensique.

Pourquoi le model versioning est indispensable

Un modèle de machine learning n’est pas un logiciel classique. Il dépend simultanément du code, des données d’entraînement, des hyperparamètres, de la configuration matérielle et de l’environnement logiciel. Modifier un seul de ces éléments produit un modèle fondamentalement différent, même si l’architecture reste identique. Le model versioning résout ce problème en traitant chaque combinaison comme un artefact unique et traçable.

Reproductibilité

Quand un modèle de scoring de crédit rejette un dossier et qu’un auditeur demande pourquoi, vous devez pouvoir reconstruire exactement le modèle qui a pris cette décision. Cela suppose de retrouver la version des données d’entraînement, le commit de code, les hyperparamètres et les métriques d’évaluation associées à cette version précise. Sans versionnage, cette traçabilité est impossible.

Rollback sécurisé

Les modèles peuvent se dégrader en production (data drift, bug dans le pipeline de features, données corrompues). Le model versioning permet de revenir instantanément à une version antérieure validée, exactement comme un git revert en développement logiciel. C’est une assurance vie pour vos systèmes critiques.

Collaboration d’équipe

Dans une équipe ML, plusieurs data scientists expérimentent simultanément sur le même modèle. Sans versionnage centralisé, les résultats se perdent dans des notebooks Jupyter non partagés et des fichiers model_final_v3_FINAL.pkl. Un model registry centralisé élimine ce chaos en donnant à chaque version un identifiant unique et un historique complet.

Conformité réglementaire

Le EU AI Act et des réglementations sectorielles (finance, santé, assurance) exigent une traçabilité complète des décisions prises par des systèmes automatisés. Le model versioning fournit le registre d’audit nécessaire : qui a entraîné quoi, avec quelles données, quand, et avec quels résultats.

Ce que vous devez versionner (et pourquoi)

Versionner uniquement les poids du modèle est une erreur courante. En réalité, le model versioning couvre un ensemble d’artefacts interconnectés. Changer un seul élément produit un modèle différent, donc chaque composant doit être tracé.

Les outils de model versioning en détail

Le paysage des outils de versionnage de modèles se structure autour de trois catégories : les plateformes open source, les registres cloud natifs et les solutions commerciales. Voici l’analyse des acteurs principaux.

MLflow : le standard open source

MLflow est la plateforme open source la plus adoptée pour le tracking d’expériences et la gestion de modèles. Son composant Model Registry centralise le stockage des versions de modèles avec un système complet de métadonnées.

MLflow 3, lancé courant 2025, a marqué un tournant majeur. Cette version introduit une architecture centrée sur le modèle (LoggedModel) avec ses propres métadonnées (paramètres, métriques), un support natif des applications GenAI et des agents, et un système d’alias flexible (@champion, @production) qui remplace les stages rigides (Staging/Production/Archived). Les stages restent disponibles par rétrocompatibilité mais sont dépréciés.

Concrètement, enregistrer et versionner un modèle avec MLflow se fait en quelques lignes :

import mlflow

# Pendant l'entraînement
with mlflow.start_run(run_name="resnet50-v2"):
    mlflow.log_params({"learning_rate": 0.001, "epochs": 50, "batch_size": 32})
    mlflow.log_metrics({"accuracy": 0.94, "f1_score": 0.92})

    # Enregistrer et versionner automatiquement
    mlflow.sklearn.log_model(
        model,
        artifact_path="model",
        registered_model_name="fraud-detector"
    )

# Promouvoir via alias (MLflow 3+)
from mlflow import MlflowClient
client = MlflowClient()
client.set_registered_model_alias("fraud-detector", "champion", version=3)

MLflow 3.10, sorti en février 2026, ajoute le support multi-workspace, l’évaluation de conversations multi-tour, le tracking des coûts LLM dans les traces et une interface repensée. L’intégration avec Databricks Unity Catalog ajoute la gouvernance d’entreprise (contrôle d’accès, lineage cross-workspace).

DVC + lakeFS : le versionnage des données

DVC (Data Version Control) a été acquis par lakeFS en novembre 2025. Le projet reste 100 % open source sous la même licence, mais bénéficie désormais des ressources et de la vision de lakeFS.

DVC fonctionne comme une extension Git pour les fichiers volumineux. Au lieu de stocker les données directement dans Git, il crée des métafichiers (.dvc) qui pointent vers le stockage distant (S3, GCS, Azure). Cela permet de versionner des datasets de plusieurs gigaoctets avec la même sémantique que Git : commits, branches, tags.

# Initialiser DVC dans un projet Git
dvc init

# Tracker un dataset
dvc add data/training_set.parquet

# Le fichier .dvc est un pointeur léger
git add data/training_set.parquet.dvc .gitignore
git commit -m "v2: ajout données janvier 2026"

# Pousser les données vers le stockage distant
dvc push

lakeFS, de son côté, opère à une échelle différente. C’est un système de contrôle de version pour data lakes entiers, avec des sémantiques Git (branches, commits, merges) sur des stockages objet S3-compatibles. Il gère des pétaoctets de données multimodales et s’intègre nativement aux écosystèmes Spark, Hive et Iceberg.

La complémentarité est claire : DVC pour les data scientists individuels et les petites équipes, lakeFS pour les plateformes data d’entreprise à grande échelle. Ensemble, ils couvrent tout le spectre du versionnage de données associé aux modèles.

Weights & Biases : tracking + registry intégré

Weights & Biases (W&B) propose un écosystème complet : experiment tracking, versionnage de datasets et modèles, et un registry avec alias et lineage. W&B est en train de migrer son ancien Model Registry vers un nouveau système nommé W&B Registry, qui élargit les capacités de versionnage à tous les types d’artefacts ML.

Le point fort de W&B est son interface utilisateur. Les dashboards interactifs pour comparer les runs, visualiser les métriques et générer des rapports collaboratifs sont supérieurs à ceux de MLflow. W&B s’intègre nativement avec PyTorch, TensorFlow, scikit-learn, et de nombreux autres frameworks.

import wandb

# Initialiser un run
run = wandb.init(project="fraud-detection", name="xgboost-v3")

# Logger les artefacts du modèle
artifact = wandb.Artifact("fraud-model", type="model")
artifact.add_file("model.pkl")
run.log_artifact(artifact)

# Lier au registry
run.link_artifact(artifact, "model-registry/fraud-model", aliases=["production"])

W&B est cloud-first (hébergé), mais propose aussi des déploiements on-premise et dédiés. Le pricing est plus élevé que MLflow (gratuit) pour les équipes, ce qui en fait un choix orienté vers les organisations qui valorisent la collaboration et l’interface utilisateur par-dessus la flexibilité d’infrastructure.

Neptune : métadonnées et audit

Neptune se distingue par ses capacités de requêtage et de filtrage sur les métadonnées d’expériences. Pour les industries réglementées (finance, santé, automobile) qui ont besoin de pistes d’audit détaillées, Neptune excelle avec un système de recherche et comparaison d’expériences historiques très robuste.

Registres cloud natifs

Les trois grands cloud providers proposent leurs propres model registries intégrés :

Ces registres s’intègrent naturellement avec les services de calcul et de déploiement de leur cloud respectif, ce qui réduit la friction pour les équipes déjà engagées sur un provider unique. Mais ils créent une dépendance forte. Pour les organisations multi-cloud, MLflow reste le choix le plus portable.

Comparatif des outils de model versioning

Bonnes pratiques de model versioning

Adoptez le semantic versioning

Appliquez les conventions de versionnage sémantique à vos modèles. Un schéma comme v{MAJOR}.{MINOR}.{PATCH} donne une sémantique claire :

MLflow utilise des entiers auto-incrémentés (v1, v2, v3) par défaut, mais le système d’alias (@champion, @production, @staging) permet de créer des pointeurs mutables vers des versions spécifiques sans coder en dur les numéros.

Métadonnées minimales par version

Chaque version enregistrée dans votre registry doit inclure au minimum :

Le nom et la version du modèle, le propriétaire (équipe ou individu), la référence au dataset d’entraînement (version ou hash), le commit de code, les hyperparamètres, les métriques d’évaluation (accuracy, precision, recall ou KPIs métier), les détails d’environnement (versions des frameworks, matériel), les dépendances, le statut d’approbation et les emplacements de déploiement (staging, production). Pour les industries réglementées, ajoutez qui a approuvé la mise en production et quand.

Garantissez l’immutabilité

Une version de modèle, une fois enregistrée, ne doit jamais être modifiée. Si vous devez corriger quelque chose, créez une nouvelle version. Cette immutabilité est la base de la reproductibilité et de l’auditabilité. MLflow l’applique nativement : chaque ModelVersion est un snapshot immuable avec un numéro de version auto-incrémenté.

Maintenez la lineage complète

La lineage connecte chaque modèle en production à son run d’entraînement, son dataset, son code et ses métriques. MLflow fait cela automatiquement en liant chaque version à l’expérience et au run qui l’a produite. W&B offre des graphes de lineage visuels pour les artefacts. Cette chaîne de traçabilité est ce qui permet de répondre à la question « comment ce modèle a-t-il été créé ? » des mois après sa mise en production.

Intégrez le versioning dans votre CI/CD

Le model versioning prend tout son sens quand il est connecté à un pipeline CI/CD ML. Le flux typique :

1. Un data scientist entraîne un modèle et l’enregistre dans le registry avec le statut « staging ».
2. Un pipeline automatisé exécute les tests de validation (performance sur un holdout set, tests de biais, tests de latence).
3. Si les tests passent, le modèle est promu en « production » (via alias @champion dans MLflow 3).
4. Le déploiement est déclenché automatiquement, avec la version précédente archivée mais toujours accessible pour rollback.

Cette automatisation élimine les promotions manuelles et garantit que seuls les modèles validés atteignent la production.

Utilisez des environnements de staging

Avant de promouvoir un modèle en production, déployez-le en staging avec du trafic réel (via shadow testing ou canary release). Comparez ses performances avec le modèle en production (A/B testing). Le model versioning permet d’identifier précisément quelles versions sont en staging et en production à tout moment.

Implémenter le model versioning : guide pas à pas

Voici un workflow concret avec MLflow, qui est le choix le plus universel. Les concepts s’appliquent à tous les outils.

Étape 1 : Installer et configurer MLflow

# Installation
pip install mlflow

# Démarrer le serveur de tracking (développement local)
mlflow server --host 0.0.0.0 --port 5000

# Production : backend PostgreSQL + stockage S3
mlflow server 
  --backend-store-uri postgresql://mlflow:password@db:5432/mlflow 
  --default-artifact-root s3://mlflow-artifacts/ 
  --host 0.0.0.0 --port 5000

Le backend PostgreSQL stocke les métadonnées (runs, métriques, paramètres). Le stockage S3 héberge les artefacts volumineux (poids du modèle, datasets). Cette séparation permet de scaler indépendamment les métadonnées et les artefacts.

Étape 2 : Logger les expériences

import mlflow
import mlflow.pytorch

mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("recommandation-produit")

with mlflow.start_run(run_name="transformer-v2") as run:
    # Logger les paramètres
    mlflow.log_params({
        "model_type": "transformer",
        "hidden_dim": 256,
        "num_layers": 6,
        "learning_rate": 3e-4,
        "batch_size": 64,
        "epochs": 30,
        "dataset_version": "train/v2026-03-15"
    })

    # Entraîner le modèle
    model = train_model(config)

    # Logger les métriques
    mlflow.log_metrics({
        "accuracy": 0.946,
        "f1_score": 0.931,
        "latency_p99_ms": 12.4,
        "model_size_mb": 89.2
    })

    # Logger et enregistrer le modèle
    mlflow.pytorch.log_model(
        model,
        artifact_path="model",
        registered_model_name="product-recommender"
    )

Étape 3 : Gérer les versions avec les alias

from mlflow import MlflowClient

client = MlflowClient()

# Voir toutes les versions
versions = client.search_model_versions("name='product-recommender'")
for v in versions:
    print(f"v{v.version} - Status: {v.status} - Métriques: {v.run_id}")

# Promouvoir la version 5 en production
client.set_registered_model_alias(
    name="product-recommender",
    alias="champion",
    version=5
)

# Charger le modèle champion pour le serving
import mlflow.pyfunc
model = mlflow.pyfunc.load_model("models:/product-recommender@champion")

Étape 4 : Automatiser avec un pipeline CI/CD

def promote_model_if_better(model_name: str, new_version: int):
    """Compare une nouvelle version au champion actuel et promeut si meilleure."""
    client = MlflowClient()

    # Récupérer le champion actuel
    try:
        champion_version = client.get_model_version_by_alias(model_name, "champion")
        champion_run = client.get_run(champion_version.run_id)
        champion_f1 = champion_run.data.metrics.get("f1_score", 0)
    except Exception:
        champion_f1 = 0  # Pas de champion existant

    # Récupérer la nouvelle version
    new_run = client.get_run(
        client.get_model_version(model_name, new_version).run_id
    )
    new_f1 = new_run.data.metrics.get("f1_score", 0)

    # Promouvoir si la nouvelle version est meilleure
    if new_f1 > champion_f1:
        client.set_registered_model_alias(model_name, "champion", new_version)
        print(f"v{new_version} promu champion (F1: {new_f1:.4f} > {champion_f1:.4f})")
        return True
    else:
        print(f"v{new_version} rejetée (F1: {new_f1:.4f} <= {champion_f1:.4f})")
        return False

Model versioning pour les LLM et applications GenAI

Le versionnage de modèles de deep learning classiques (classification, détection, recommandation) est bien établi. Mais les applications GenAI introduisent de nouveaux défis de versionnage.

Versionnage des prompts

Dans une application basée sur un LLM, le prompt system est un artefact aussi critique que les poids du modèle. Modifier un prompt peut radicalement changer le comportement de l’application. MLflow 3 a introduit un Prompt Registry dédié qui réutilise l’infrastructure du model registry pour versionner, gérer et tester les prompts avec l’intégration Unity Catalog.

Versionnage des agents

Les agents IA (comme ceux construits avec LangChain ou LlamaIndex) combinent un LLM, des tools, des prompts et une logique d’orchestration. MLflow 3 traite ces agents comme des modèles versionnables, avec le tracing (observabilité des étapes intermédiaires), l’évaluation avec juges LLM, et le tracking des coûts par span.

Versions de fine-tuning

Si vous faites du fine-tuning sur un LLM de base, chaque itération de fine-tuning produit un modèle distinct qui doit être versionné avec sa configuration LoRA/QLoRA, son dataset de fine-tuning et ses métriques d’évaluation. Le model versioning suit la chaîne : modèle de base → adaptateur LoRA → modèle fusionné → modèle quantifié pour l’inférence.

Anti-patterns à éviter

Versionner uniquement les poids

Le modèle seul ne suffit pas. Sans la version des données, du code et de l’environnement, vous ne pouvez pas reproduire le résultat. Traitez le versionnage comme une discipline multi-artefact.

Utiliser le filesystem comme registry

Stocker des fichiers model_v1.pkl, model_v2.pkl dans un dossier partagé est l’équivalent ML du versionning manuel de fichiers rapport_final_v3_VRAI_FINAL.docx. Aucune métadonnée, aucune lineage, aucun contrôle d’accès. Utilisez un vrai model registry.

Ignorer les données

Deux modèles entraînés avec le même code mais des données différentes sont des modèles fondamentalement différents. Pourtant, de nombreuses équipes ne versionnent que le code et les poids. Intégrez DVC ou lakeFS pour le versionnage des données dès le départ.

Pas de tests automatisés avant promotion

Promouvoir manuellement un modèle en production sans validation automatisée (tests de performance, de biais, de latence) est une recette pour les incidents. Connectez votre registry à un pipeline CI/CD qui exécute ces tests avant toute promotion.

Supprimer les anciennes versions

La suppression de versions dans un model registry est irréversible. Conservez toutes les versions, même celles qui n’ont jamais atteint la production. Elles constituent votre historique d’expérimentation et peuvent être nécessaires pour des audits réglementaires. Archivez plutôt que supprimer.

Model Versioning et Model Cards

Un model card est un document standardisé qui décrit un modèle ML : ses capacités, ses limites, ses biais connus et ses conditions d’utilisation prévues. Le model versioning et les model cards sont complémentaires : chaque version du modèle devrait être accompagnée d’un model card mis à jour.

Le registry fournit les données techniques (métriques, lineage, hyperparamètres) tandis que le model card ajoute le contexte humain (pour quel usage, quelles populations, quels biais mesurés). Ensemble, ils forment une documentation complète pour la gouvernance des modèles.

Verdict

Le model versioning n’est pas optionnel si vous mettez des modèles ML en production. Sans lui, vous opérez à l’aveugle : aucune reproductibilité, aucun rollback possible, aucune traçabilité pour les audits. L’investissement en temps est minime (quelques lignes de code avec MLflow) comparé au coût d’un incident de production où personne ne sait quel modèle tourne ni comment le remplacer.

Pour démarrer, la combinaison MLflow (gratuit, open source, standard de fait) + DVC (versionnage des données) couvre 90 % des besoins. Ajoutez W&B si la collaboration UI et les dashboards interactifs sont prioritaires pour votre équipe. Réservez les registres cloud natifs (SageMaker, Vertex, Azure ML) aux organisations déjà profondément engagées sur un seul provider.

L’arrivée de MLflow 3 avec le support GenAI natif (tracing, Prompt Registry, évaluation d’agents) élimine le dernier argument contre l’adoption : même les équipes travaillant avec des LLM et des agents peuvent désormais versionner l’ensemble de leurs artefacts dans un seul outil.