Pourquoi versionner sérieusement
Le versionning des modèles est le plus souvent traité comme une formalité : « on push le modèle sur S3, voilà ». C'est suffisant pour une démo. C'est inopérant en production. Quatre raisons concrètes :
- Audit AI Act. L'article 11 exige une documentation technique du modèle, de ses données d'entraînement, des méthodes d'évaluation. Sans versionning rigoureux, vous ne pouvez pas la produire trois ans après.
- Rollback. Une nouvelle version casse la qualité. Vous devez pouvoir revenir à la précédente en 30 secondes, pas en 3 jours.
- Reproductibilité. Le même fine-tuning lancé six mois plus tard doit donner le même modèle. Sans versioning des données, du code, des hyperparamètres — impossible.
- A/B testing. Comparer deux versions en production demande de pouvoir les servir simultanément, traçablement, avec attribution des trajectoires.
Quoi versionner — bien au-delà des poids
Un modèle de production, en 2026, c'est rarement juste un fichier de poids. C'est un bundle de plusieurs artefacts qui doivent tous être versionnés ensemble.
| Artefact | Format typique | Pourquoi versionner |
|---|---|---|
| Poids modèle | safetensors, GGUF, FP8 | Le cœur. Évidence. |
| Adapter LoRA | safetensors (50-500 MB) | Si fine-tuning LoRA, l'adapter est ce qui change. Plus léger que les poids complets. |
| Tokenizer | tokenizer.json + vocab | Modifier un tokenizer casse silencieusement la cohérence. |
| Config inférence | JSON / YAML | Température, top_p, stop tokens, max_tokens — ça change le comportement. |
| Prompts système | YAML / Markdown | Le prompt EST une partie du modèle effectif. Modifier sans tracking = régression invisible. |
| Dataset eval | JSONL | Les métriques ne se comparent que si l'eval set est figé. Versionner avec hash de contenu. |
| Dataset training | JSONL / Parquet | Pour reproductibilité fine-tuning et audit AI Act art. 11. |
| Métriques d'éval | JSON dans run MLflow | Pour justifier la promotion en production. |
| Carte modèle | Markdown | Description, limites connues, usages attendus. Exigée par l'AI Act. |
Une version de modèle, c'est un bundle versionné atomiquement qui contient tous les artefacts ci-dessus. Promouvoir une version, c'est promouvoir tout le bundle d'un seul atome — pas modifier le prompt sans changer la version.
Semantic versioning pour les modèles
Le semver classique (MAJOR.MINOR.PATCH) s'adapte aux modèles avec des conventions spécifiques. Notre convention chez nos clients :
- MAJOR : changement de modèle base (Mistral 7B → Mistral 22B), incompatibilité tokenizer, changement d'interface (input/output schema).
- MINOR : nouveau fine-tuning, ajout de capability, nouvelle version d'adapter LoRA, changement majeur de prompt système.
- PATCH : bugfix prompt, modification mineure de config inférence, mise à jour de tokenizer compatible.
Exemple concret : acpr-rag/2.4.1 = base v2, fine-tuning v4, patch v1. Le passage de 2.4.1 à 2.5.0 est rétrocompatible. Le passage à 3.0.0 ne l'est pas — l'équipe RAG doit s'adapter.
Où entreposer — comparatif
MLflow Model Registry
Notre choix par défaut quand on a une plateforme MLflow déjà déployée (ce qui est le cas dans 100 % de nos missions). Le Registry gère le versioning, les stages (Staging / Production / Archived), l'approval workflow, les signatures de schéma.
Avantage : tout est dans MLflow, traçable depuis le run d'entraînement. Inconvénient : pour partager le modèle hors entreprise (clients, partenaires), il faut un autre canal.
Hugging Face Hub privé
Hub privé, accès par token, intégration native avec transformers et vllm. Très utile quand votre équipe consomme déjà des modèles du Hub.
Limite : hébergé chez HF (US-controlled même si la société est française). Pour des charges souveraines, on évite et on garde tout en MLflow on-premise.
S3 / MinIO avec convention
Stockage objet plat, avec une convention de nommage {model_family}/{version}/bundle.tar.gz. Simple, robuste, pas de surcouche. À combiner avec une base de métadonnées (Postgres) pour les lookups.
Notre stack idéale pour les charges souveraines : MLflow Registry pour le tracking et l'UI, S3-compatible (MinIO on-premise ou Outscale OOS) pour les artefacts en backend MLflow.
BentoML, KServe, Seldon
Plus que des registries — ce sont des plateformes de serving avec registry intégré. Utiles si vous voulez le full bundle « registry + déploiement K8s + scaling auto ». Plus lourd à mettre en place, à réserver aux organisations qui en ont vraiment besoin.
Stratégies cold / warm / hot
Tous les modèles ne sont pas égaux en accès. Une stratégie de stockage tiérée économise massivement le coût.
- Hot : les 2-3 versions actives en production. Stockées sur NVMe local des nœuds GPU, ou bucket S3 standard ultra-rapide. Coût élevé, accès instantané.
- Warm : les versions récentes en Staging ou en rollback potentiel. Bucket S3 standard, fetching à la demande (10-60s pour charger). Coût modéré.
- Cold : les versions archivées (Archived). Bucket S3 Glacier ou équivalent. Plusieurs heures pour restaurer. Coût très bas. Indispensable pour conformité AI Act (rétention 6-10 ans).
Un modèle Mistral Large 3 quantifié AWQ pèse ~60 GB. À l'échelle de 50 versions archivées, c'est 3 TB sur Glacier — quelques euros par mois. Sur du stockage hot, c'est plusieurs centaines d'euros. Le tiering n'est pas optionnel à grande échelle.
Stratégies de promotion : canary, blue-green, shadow
Promouvoir une nouvelle version en production demande de la prudence. Trois stratégies coexistent, à choisir selon le profil de risque.
Canary
5 % du trafic est routé vers la nouvelle version. Le reste continue sur l'ancienne. Si les métriques (qualité, latence, coût, erreurs) tiennent sur 24-48h, on passe à 25 %, puis 50 %, puis 100 %. À la moindre alerte, retour à 0 %.
Idéal pour les changements de modèle de prod en place. Demande un routeur de trafic (Istio, Linkerd, ou simplement un wrapper Python).
Blue-green
Deux environnements complets (blue et green) en parallèle. Le trafic est routé à 100 % vers l'un. Pour déployer, on bascule à 100 % vers l'autre. Rollback instantané en re-basculant.
Plus brutal que canary mais plus simple. Pertinent pour les changements majeurs avec validation prélable forte.
Shadow
La nouvelle version traite le trafic en parallèle de l'ancienne, mais sans renvoyer ses réponses à l'utilisateur. On compare les sorties (similarité, métriques) sans risque pour l'utilisateur final.
Indispensable avant de canaryer un changement majeur. Coût : tokens doublés sur la fenêtre du shadow. Bénéfice : détection de régression sans impact production.
Pour un changement majeur de modèle : shadow pendant 1-2 semaines → canary 5 % pendant 48h → 25 % pendant 48h → 100 %. Toujours avec un kill switch qui revient à l'ancienne version en 30 secondes.
Pour l'AI Act : la rétention
L'AI Act exige (art. 12) que les logs d'événements et la traçabilité du modèle soient conservés « pour une période adaptée au but du système, en tout cas pas inférieure à 6 mois ». Pour les systèmes à haut risque (banque, santé, défense), nos clients vont typiquement à 6-10 ans de rétention.
Concrètement : les anciens modèles, leurs prompts, leurs datasets, leurs métriques d'éval, leurs traces — tout doit rester accessible (même en cold) pour la durée prescrite. Ne jamais supprimer une version, seulement l'archiver.
Coût d'opportunité : stocker 5 ans de modèles archivés sur Glacier coûte quelques milliers d'euros par an pour une plateforme moyenne. C'est dérisoire comparé au risque juridique de ne pas pouvoir produire la trace lors d'un audit ANSSI ou CNIL.
Notre architecture de référence
Chez nos clients, l'architecture de référence que nous mettons en place est :
- MLflow Tracking + Registry hébergé on-premise ou sur cloud souverain (Postgres pour métadonnées, S3-compatible pour artefacts).
- Convention semver avec règles claires pour MAJOR/MINOR/PATCH adaptées aux modèles.
- Workflow GitHub Actions qui versionne automatiquement à chaque release : tag git, push MLflow, génération de la model card.
- Stratégie de promotion shadow → canary → full implémentée via un routeur simple (Python wrapper ou Istio selon la maturité du SI).
- Politique de rétention avec migration automatique hot → warm → cold après N mois sans accès, et conservation 6 ans minimum.
Versionning à mettre en place ?
Convention semver adaptée à vos modèles, MLflow Registry self-host, workflow CI/CD, stratégie de promotion canary/shadow, conformité AI Act art. 11-12. Première analyse de faisabilité offerte.
Échanger avec un expert