MLOps et GitOps

Un modèle en production n'est pas figé : nouvelle version du modèle ouvert, nouvelle quantification, nouvelle invite système, nouvel index RAG, réglages du serveur. Chacun de ces changements peut améliorer… ou dégrader silencieusement les réponses. Le MLOps applique au cycle de vie des modèles ce que la CI/CD et le GitOps apportent au code : versionner, tester, déployer progressivement, observer, revenir en arrière. Cette leçon est théorique.

Ce que vous saurez à la fin : identifier tout ce qui doit être versionné dans un service d'IA, distribuer des modèles comme des artefacts OCI, construire une étape d'évaluation dans un pipeline, déployer une nouvelle version de modèle par GitOps et en canary, et surveiller un service d'inférence en production.

1. Qu'est-ce qui change ?

Élément	Exemple	Où le versionner
poids du modèle	Qwen3-8B, révision a1b2c3, quantifié AWQ	registre de modèles ou OCI, référencé par empreinte
configuration du serveur	--max-model-len, image vLLM	manifestes dans Git
invite système, outils	consignes, schémas d'outils	Git, à côté du code de l'application
index RAG	découpage, modèle de plongement	Git (la recette), stockage (l'index), avec une version
jeu d'évaluation	questions et réponses attendues	Git

Une réponse en production doit pouvoir être reliée à la combinaison exacte qui l'a produite.

2. Des modèles comme des images

Les registres de conteneurs savent stocker autre chose que des images : des artefacts OCI. Un modèle peut y être poussé, versionné, signé et analysé comme une image (leçons C.5 et D.2), et tiré depuis votre registre interne plutôt que depuis Internet :

oras push registre.exemple.fr/modeles/qwen3-8b-awq:2026-10 ./qwen3-8b-awq/ --artifact-type application/vnd.exemple.modele

Côté Kubernetes, un volume de type image (ou le mode modelcar de KServe) monte le contenu d'une image OCI dans le pod : le modèle devient une dépendance déclarée dans le manifeste, référencée par empreinte, et mise en cache par les nœuds comme une image ordinaire. Les registres de modèles dédiés (MLflow, Kubeflow Model Registry) ajoutent métadonnées, lignage et étapes de validation.

3. Évaluer dans le pipeline

Un changement de modèle ou d'invite passe par une demande de fusion, et le pipeline évalue avant toute fusion :

demande de fusion ─▶ déployer la candidate (namespace éphémère) ─▶ rejouer le jeu d'évaluation ─▶ comparer à la version en service
                                                                                                 ─▶ commentaire : justesse, latence, coût

• Justesse : taux de bonnes réponses sur vos questions, fidélité aux sources pour un RAG (leçon IA.3), respect du format (JSON valide).
• Sécurité : jeu de requêtes d'injection et de demandes interdites (leçon IA.6).
• Performance : délai avant le premier jeton, jetons par seconde, mémoire.
• Coût : jetons consommés par tâche.

Un LLM juge (un modèle qui note les réponses d'un autre selon une grille) aide à évaluer à grande échelle ; il se calibre sur un échantillon noté par des humains.

4. Déployer par GitOps

Le modèle, sa configuration et son invite vivent dans le dépôt GitOps (leçons D.4 et D.5). Mettre en service une nouvelle version, c'est fusionner une demande de fusion qui change une référence :

# apps/assistant/prod/kustomization.yaml
images:
  - name: registre.exemple.fr/modeles/qwen3-8b-awq
    digest: sha256:5e1f…           # la nouvelle version, évaluée par le pipeline

Comme pour une application (leçon D.6), on déploie en canary : 10 % des requêtes vers la nouvelle version, comparaison des métriques et des retours utilisateurs, puis généralisation, ou git revert. KServe sait répartir le trafic entre deux versions d'un InferenceService ; une Gateway API le fait avec des poids.

5. Observer en production

Signal	Pourquoi
délai avant le premier jeton, jetons par seconde	expérience utilisateur
requêtes en attente, utilisation du cache KV	saturation, mise à l'échelle (leçon IA.2)
utilisation et mémoire des GPU (exportateur DCGM)	capacité et coût
jetons par requête et par équipe	budget, détection d'abus
taux d'erreur, réponses tronquées, refus	santé fonctionnelle
retours des utilisateurs (pouce levé ou baissé)	qualité perçue

Les traces OpenTelemetry (conventions « gen_ai ») relient une requête utilisateur à chaque appel au modèle, à chaque recherche RAG et à chaque appel d'outil : indispensable pour comprendre pourquoi une réponse est fausse. Attention : les invites et réponses enregistrées peuvent contenir des données personnelles ; durée de conservation et accès se décident à l'avance.

6. La dérive

La qualité se dégrade aussi sans aucun changement de votre côté : les questions des utilisateurs évoluent, les documents changent, un fournisseur d'API met à jour son modèle. Rejouez le jeu d'évaluation régulièrement (un CronJob), enrichissez-le avec les questions réelles mal traitées, et surveillez les tendances des retours utilisateurs.

Validez la leçon avec le questionnaire.