Les bonnes pratiques DevOps pour la Data Science : guide MLOps complet 2026

Pourquoi le DevOps ne suffit pas pour la Data Science

Le DevOps classique excelle dans le déploiement continu d’artefacts déterministes : du code, des configurations, des conteneurs. Une fois déployé, le comportement est connu et stable.

Le Machine Learning ajoute trois complexités fondamentales.

Complexité 1 : les données sont non déterministes

Le code d’entraînement peut être parfait, mais si les données d’entrée changent (nouvelle source, erreur amont, changement de comportement utilisateur), le modèle se dégrade silencieusement.

En DevOps : git commit capture l’état du code. En MLOps : il faut capturer l’état du code ET des données.

Complexité 2 : la performance est probabiliste et se dégrade

Un modèle à 95 % de précision aujourd’hui peut tomber à 85 % dans trois mois, sans aucun changement de code. La dérive du concept (concept drift) — la relation entre features et cible qui évolue — est une réalité dans tout système dynamique.

En DevOps : l’application marche ou ne marche pas. En MLOps : le modèle “marche moins bien” progressivement. Il faut le détecter avant l’impact métier.

Complexité 3 : l’entraînement est coûteux et long

Tester une nouvelle version d’une application Java prend 5 minutes. Réentraîner un modèle sur 10 To de données prend 8 heures et coûte 500 $.

En DevOps : itérations rapides, tests fréquents. En MLOps : itérations lourdes, besoin de sélection intelligente des candidats à l’entraînement.

Les quatre piliers du MLOps

La littérature et les retours d’expérience convergent vers quatre piliers structurants.

Pilier 1 : Versioning (code, données, modèles)

Tout artefact participant à la production d’une prédiction doit être versionné : le code, les données d’entraînement, les hyperparamètres, les poids du modèle. Sans versioning, pas de reproductibilité, pas de rollback, pas d’audit.

Pilier 2 : Tests automatisés (validation et non-régression)

Avant chaque mise en production, un ensemble de tests doit valider que le nouveau modèle n’est pas moins performant que l’actuel sur des métriques métier, et que les données d’entrée respectent le schéma attendu.

Pilier 3 : CI/CD adapté (déploiement progressif)

Le déploiement d’un modèle ne se fait jamais en “big bang”. Les pratiques de shadow mode, canary et blue/green sont essentielles pour détecter les régressions avant qu’elles n’impactent les utilisateurs.

Pilier 4 : Monitoring multidimensionnel (données, concept, opérations)

La surveillance d’un modèle en production couvre trois dimensions : les données d’entrée (drift), la relation features-cible (concept drift), et les performances système (latence, mémoire).

Versioning des données et des modèles

Versioning des données : au-delà de Git

Git n’est pas conçu pour les fichiers volumineux (quelques Go maximum). Plusieurs solutions existent.

Bonne pratique : Ne versionnez pas les données brutes. Versionnez les transformations et les échantillons qualifiés qui servent à l’entraînement de référence.

# Initialisation d'un dépôt DVC
dvc init
git commit -m "Initialize DVC"

# Ajout d'un dataset
dvc add data/train.parquet
git add data/train.parquet.dvc .gitignore
git commit -m "Add raw training dataset"

# Pousser les données vers le remote (S3/GCS)
dvc remote add -d myremote s3://mybucket/dvcstore
dvc push

Versioning des modèles : MLflow Model Registry

MLflow est devenu le standard de facto pour le tracking et le versioning des modèles.

import mlflow
from mlflow.tracking import MlflowClient

client = MlflowClient()

# Création d'une nouvelle version du modèle
client.create_model_version(
    name="customer_churn_model",
    source="gs://models/churn/v2.3/",
    run_id="e3d5a1b2c4f6",
    description="XGBoost avec feature engineering v3"
)

# Transition d'une version à "Staging"
client.transition_model_version_stage(
    name="customer_churn_model",
    version=5,
    stage="Staging"
)

L’importance du hash de reproductibilité

La reproductibilité en ML repose sur la combinaison (code hash + data hash + params hash). Un seul changement déclenche un nouvel artefact.

# reproducible_hash.yaml
code_version: a3f5c91
dataset_version: 2026-06-01_train_v2
params:
  learning_rate: 0.01
  max_depth: 7
model_artifact: gs://models/churn/2026-06-06/
resulting_metric: f1=0.89

Tests automatisés pour pipelines ML

Les quatre familles de tests

Exemple : validation des données avec Great Expectations

import great_expectations as ge

# Chargement du DataFrame d'entrée
df = ge.read_parquet("gs://input/inference_batch.parquet")

# Validation du schéma et des contraintes
validation_results = df.expect_column_values_to_not_be_null("user_id")
validation_results = df.expect_column_values_to_be_between("age", 0, 120)
validation_results = df.expect_column_values_to_be_in_set("country", ["FR", "BE", "CH"])

# Si échec, déclencher alerte et bloquer l'inférence
if not validation_results.success:
    raise ValueError(f"Data validation failed: {validation_results}")

CI/CD pour modèles : workflow type

Un pipeline CI/CD pour ML suit généralement cette séquence.

name: MLOps Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test-light:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run data validation (sample)
        run: python tests/test_data_validation.py --sample 1000
      - name: Run unit tests
        run: pytest tests/unit/
  
  train-and-register:
    needs: test-light
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: [self-hosted, gpu]
    steps:
      - name: Full training
        run: python train.py --full-data --model-version ${{ github.sha }}
      - name: Evaluate vs baseline
        run: python tests/check_regression.py --threshold 0.02
      - name: Register to MLflow
        run: python scripts/mlflow_register.py --stage Staging
  
  deploy-staging:
    needs: train-and-register
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging endpoint
        run: python scripts/deploy.py --env staging --traffic 0
      - name: Validate staging (shadow mode)
        run: python tests/validate_staging.py --duration 3600
  
  promote-to-prod:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Canary 5% traffic
        run: python scripts/deploy.py --env prod --traffic 5
      - name: Monitor canary
        run: python tests/monitor_canary.py --duration 7200 --alert-threshold 0.01
      - name: Full rollout
        run: python scripts/deploy.py --env prod --traffic 100

Stratégies de déploiement sans risque

Stratégie 1 : Shadow mode (mode ombre)

Le nouveau modèle tourne en parallèle de l’ancien, mais ses prédictions ne sont pas servies aux utilisateurs. On compare les deux sorties pendant plusieurs jours pour détecter des comportements aberrants.

# Principe du shadow mode
def shadow_inference(request):
    prediction_old = model_old.predict(request)
    prediction_new = model_new.predict(request)
    
    # Log des divergences pour analyse
    if abs(prediction_new - prediction_old) > threshold:
        log_divergence(request, prediction_old, prediction_new)
    
    # Seule l'ancienne version répond
    return prediction_old

Stratégie 2 : Canary deployment

5 à 10 % du trafic est dirigé vers le nouveau modèle. Surveillance renforcée pendant 24 à 48 heures. Si aucune alerte, augmentation progressive à 25 %, 50 %, 100 %.

# Principe du canary (routage aléatoire)
def canary_inference(request):
    if random.random() < 0.05:  # 5% de trafic canary
        return model_new.predict(request)
    else:
        return model_old.predict(request)

Stratégie 3 : Blue/Green deployment

Deux environnements identiques (blue = production actuelle, green = nouvelle version). Après validation du green, bascule du routeur (load balancer) du blue vers le green en une fois. Rollback : rebascule immédiate.

Avantage : bascule instantanée, pas de code gérant deux versions. Inconvénient : double infrastructure pendant la validation.

Stratégie 4 : Automated rollback conditionnel

Des métriques de santé (latence p99, taux d’erreur, métrique métier échantillonnée) sont surveillées en continu. Si un seuil critique est dépassé, le système bascule automatiquement vers la version précédente.

if (
    latency_p99 > 2000  # ms
    or error_rate > 0.05
    or sampled_accuracy < baseline_accuracy - 0.02
):
    rollback_to_previous_version()
    alert_oncall_engineer()

Monitoring multidimensionnel d’un modèle en production

Dimension 1 : Dérive des données (Data drift)

La distribution des features d’entrée change par rapport au jeu d’entraînement.

À surveiller : distribution de chaque feature (PSI - Population Stability Index), valeurs manquantes, valeurs hors domaine.

Seuil typique : alerte si PSI > 0.15 (significatif) ou > 0.25 (alerte critique).

Dimension 2 : Dérive du concept (Concept drift)

La relation entre les features et la cible évolue. Plus difficile à détecter car nécessite la vérité terrain (qui arrive avec délai).

À surveiller : performance réelle sur échantillon annoté, confusion matrix, lift sur sous-populations.

Dimension 3 : Dérive opérationnelle

Les performances système se dégradent.

À surveiller : latence p50/p95/p99, taux d’erreur (4xx, 5xx), utilisation CPU/GPU, mémoire.

Implémentation de référence

# Configuration du monitoring sur Vertex AI
from google.cloud import aiplatform

endpoint = aiplatform.Endpoint(endpoint_id="churn_endpoint")
endpoint.deploy(
    model=model,
    monitoring_config={
        "enable_data_drift_detection": True,
        "drift_threshold": 0.15,
        "sampling_rate": 0.1,  # 10% des prédictions échantillonnées
        "alert_webhook": "https://hooks.slack.com/..."
    }
)

Checklist MLOps : du notebook à la production

Voici une checklist progressive pour faire passer un modèle de l’expérimentation à la production.

Phase 1 : Fondations (score 0 → 1)

• Le code d’entraînement est versionné dans Git
• Les données d’entraînement sont versionnées (DVC ou LakeFS)
• Les hyperparamètres sont explicitement enregistrés
• Un notebook de reproductibilité existe (chaque cellule est exécutable)
• Le modèle exporté est reproductible (hash code + data + params)

Phase 2 : Tests et validation (score 1 → 2)

• Validation du schéma des données d’entrée (Great Expectations)
• Tests unitaires sur les fonctions de preprocessing
• Test de non-régression sur un échantillon gelé
• Le modèle bat une baseline simple (random, moyenne)
• La documentation du modèle (intention d’usage, limites) est écrite

Phase 3 : CI/CD (score 2 → 3)

• Pipeline CI déclenché sur chaque PR (tests légers)
• Pipeline CD déclenché sur merge main (entraînement complet)
• MLflow Model Registry avec étapes Staging → Production
• Validation finale par un ingénieur MLOps ou un MLE senior avant promotion
• Rollback automatisé sur détection d’anomalie opérationnelle ou de performance

Phase 4 : Production robuste (score 3 → 4)

• Monitoring des données (data drift) et alerting
• Monitoring de la performance dès que la vérité terrain arrive
• Déploiement en canary (5% → 100%) avec automated rollback
• SLA de latence documenté et surveillé
• Plan de réentraînement documenté (fréquence, déclenchement)

Stack MLOps recommandée par taille d’équipe

Petite équipe (2-5 data scientists, < 5 modèles en prod)

Équipe moyenne (5-20 data scientists, 5-50 modèles)

Grande entreprise (>20 data scientists, >50 modèles)

Les organisations ayant déjà investi dans les plateformes MLOps comparées bénéficient d’outils natifs réduisant la fragmentation.

Articles connexes

Pour approfondir les sujets abordés dans cet article :