CI CD pour le ML

Déployer un modèle de machine learning en production est intrinsèquement risqué. Contrairement à une application web classique, un modèle peut échouer non seulement à cause de son code, mais aussi à cause des données qu’il reçoit. La CI/CD pour le ML est un filet de sécurité qui automatise les validations à chaque étape. Elle vérifie que le code, les données et le modèle lui-même respectent un contrat avant de permettre un déploiement, rendant la mise en production d’un nouveau modèle aussi banale que possible.

prérequis

Repo unique (monorepo): Le code du modèle, les tests, la configuration des données et le pipeline de déploiement vivent au même endroit.
Environnements isolés: Des environnements distincts et reproductibles pour le développement, le staging et la production.
Registre de modèles: Un outil pour versionner et stocker les modèles entraînés (ex: MLflow, Vertex AI Model Registry).

idées clefs

Tester plus que le code: La CI doit valider le code (tests unitaires), les données d’entraînement (tests de schéma, de distribution) et la performance du modèle (tests de non-régression).
Promotion basée sur des preuves: Un nouveau modèle n’est promu en production que si ses métriques (ex: AUC, F1-score) sont objectivement meilleures que celles du modèle actuel.
Rollback facile: Le processus de déploiement doit permettre de revenir à la version précédente du modèle en un clic ou une commande.

pas à pas

étape 1: tests automatisés dans la pull request (CI)

Chaque modification de code ou de configuration de données doit déclencher un pipeline de CI qui agit comme un gardien. Si les tests ne passent pas, la PR ne peut pas être mergée.

# Exemple de commandes exécutées dans une CI sur une pull request

# 1. Tester la logique du code (fonctions de feature engineering, etc.)
pytest -q --cov=src

# 2. Valider le schéma des données d'entraînement par rapport à des attentes définies
great_expectations checkpoint run training_data_schema

étape 2: promotion conditionnelle du modèle

Après l’entraînement, le pipeline compare la performance du nouveau modèle à celui actuellement en production. La promotion est automatique si les conditions sont remplies.

# Concept de gate de performance dans un pipeline (ex: GitHub Actions)
- name: "evaluate and compare models"
  id: evaluate
  run: |
    # Ce script compare les métriques et retourne 'true' ou 'false'
    PROMOTION_APPROVED=$(python scripts/compare_models.py --new-model-path ./new_model --prod-model-uri models:/fraud_detector/production)
    echo "::set-output name=approved::$PROMOTION_APPROVED"

- name: "promote model if approved"
  if: steps.evaluate.outputs.approved == 'true'
  run: |
    # Promouvoir le modèle dans le registre
    mlflow models transition-stage ...

étape 3: déploiement automatique en production (CD)

Une fois qu’un modèle est promu (tagué comme “production” dans le registre), le pipeline de CD prend le relais pour le déployer automatiquement sur l’infrastructure de serving.

# Exemple simple de déploiement continu avec Kubernetes
# Le pipeline détecte un nouveau modèle "production" et déclenche un redémarrage du service

echo "Nouveau modèle détecté, déploiement en cours..."
kubectl rollout restart deployment/fraud-detector-api

exemples concrets

cas: une gate de performance en python

Le cœur de la promotion conditionnelle est souvent un simple script qui compare des métriques.

# Extrait de scripts/compare_models.py

import mlflow

# Charger les métriques des deux modèles
new_model_metrics = mlflow.get_run(new_run_id).data.metrics
prod_model_metrics = mlflow.get_run(prod_run_id).data.metrics

new_auc = new_model_metrics.get("auc")
prod_auc = prod_model_metrics.get("auc")

# La "gate" : le nouveau modèle doit être au moins 1% meilleur
MIN_IMPROVEMENT_THRESHOLD = 0.01
assert new_auc > (prod_auc + MIN_IMPROVEMENT_THRESHOLD), "La performance du modèle n'est pas suffisante pour une promotion."

print("Promotion approuvée.")

erreurs courantes et solutions

Symptôme: Un modèle fonctionne parfaitement en dev mais échoue en production.
- Cause: Divergence entre les environnements (versions de librairies, etc.).
- Correctif: Utiliser des images de conteneurs immuables (Docker) pour garantir que l’environnement est identique du test au déploiement.
Symptôme: Les tests du modèle sont instables et non reproductibles.
- Cause: Utilisation de données de test qui changent tout le temps.
- Correctif: Définir un jeu de données de test fixe et versionné (“golden dataset”) pour l’évaluation, afin de garantir que les comparaisons de performance sont justes.
Symptôme: Les déploiements sont lents, manuels et sources d’erreurs.
- Cause: Absence d’automatisation et de processus déclaratif.
- Correctif: Définir tout le pipeline de déploiement dans un fichier déclaratif (ex: github-actions.yml, gitlab-ci.yml). Le déploiement doit être un non-événement.

faq

En quoi la ci/cd pour le ml est-elle différente de la ci/cd classique ? Elle ajoute deux dimensions critiques : la validation des données (le schéma et la distribution peuvent changer) et la validation du modèle (la performance est une condition de déploiement). Le pipeline ne teste pas seulement si le code fonctionne, mais aussi si le modèle est meilleur.
Faut-il une plateforme mlops complexe pour commencer ? Non. Vous pouvez commencer avec des outils standards que vous utilisez déjà (GitHub/GitLab, Docker, pytest) et des scripts Python simples. Les plateformes MLOps intégrées (Vertex AI, SageMaker, MLflow) deviennent utiles lorsque vous devez gérer des dizaines de modèles à l’échelle.

Menu