Aller au contenu principal

Module 10 — Réentraînement automatique et retour arrière

Le dernier module ferme la boucle. La dérive détectée par le module 9 déclenche un réentraînement, la nouvelle version est validée par les tests du module 7, promue par le mécanisme du module 5, servie par l'image du module 6, et rétablie en une commande si elle échoue en production. Tous les modules précédents convergent ici.

Trois déclencheurs de réentraînement​

Un réentraînement n'a pas besoin d'être « automatique à tout prix ». Il a besoin d'être déclenché par la bonne cause, journalisé et reproductible. Trois familles de déclencheurs couvrent l'essentiel des besoins.

Déclencheur temporel. Le pipeline réentraîne chaque semaine, chaque mois ou chaque trimestre, quelle que soit la dérive. Simple, prévisible, sans surprise ; adapté aux domaines lents à évoluer (crédit, assurance sur risque long).

Déclencheur par dérive. Le job de surveillance produit un rapport ; si le PSI d'une variable importante dépasse 0,25 pendant trois jours consécutifs, ou si l'AUC recalculée sur la vérité terrain tombe sous un seuil, le réentraînement est planifié. C'est le déclencheur le plus fin mais aussi le plus délicat à calibrer.

Déclencheur par volume. Après N nouvelles observations étiquetées (par exemple 100 000 nouveaux abonnés dont on connaît le statut à 30 jours), le pipeline se relance pour capitaliser sur ces données récentes.

En pratique, une équipe mature combine les trois : un socle temporel mensuel, un déclencheur par dérive pour les urgences, un déclencheur par volume pour les domaines à forte cadence.

Le pipeline de réentraînement​

# .github/workflows/reentrainer.yml
name: reentrainer-churn
on:
  workflow_dispatch:
  schedule: [{cron: "0 3 1 * *"}]         # 1er du mois a 03h UTC
  repository_dispatch: {types: [derive_detectee]}

jobs:
  reentrainer:
    runs-on: [self-hosted, gpu]
    steps:
      - uses: actions/checkout@v4
      - uses: iterative/setup-dvc@v1
      - run: dvc pull data/dernier_extrait.parquet
      - run: uv run python -m src.entrainement --sortie modele/
      - run: uv run pytest tests/modele                     # seuils
      - run: |
          uv run python -m src.enregistrer_dans_mlflow \
            --alias candidat --auteur automate

Ce pipeline peut se déclencher de trois façons : manuellement, par horloge, ou par événement derive_detectee émis par le job de surveillance. Sa sortie unique est une nouvelle version dans le registre, avec l'alias candidat.

Validation avant promotion, en deux temps​

Une version candidate ne devient jamais champion par simple succès des tests unitaires. Deux validations supplémentaires s'imposent.

Validation hors ligne. La candidate est comparée à la champion sur le jeu de test figé, tranche par tranche. Cette comparaison est automatisable et rejoue les tests du module 7 avec le poids supplémentaire : « meilleur ou au moins équivalent sur chaque segment qui compte ».

Validation en ligne progressive. La candidate est servie à une petite fraction du trafic (5 %) pendant quelques heures ou quelques jours. On compare le comportement en conditions réelles : latence observée, distribution des probabilités, taux d'erreurs applicatives, et surtout les métriques métier disponibles à court terme (taux de clic sur une recommandation, taux d'appels à un centre de rappel).

Cette validation en ligne progressive porte plusieurs noms selon l'implémentation :

  • Canari (canary) : un petit pourcentage du trafic reçoit la nouvelle version, le reste continue avec l'ancienne.
  • Bleu-vert (blue-green) : deux environnements complets coexistent, on bascule tout le trafic d'un coup après validation.
  • Test A/B : deux versions coexistent durablement pour mesurer une métrique métier au propre.

Le canari est le plus économique pour un modèle ; le bleu-vert coûte plus mais rend le retour arrière trivial ; le test A/B répond à une question scientifique et sort du cadre d'une simple promotion.

Le retour arrière : le geste qui doit être trivial​

Un retour arrière compliqué n'est jamais fait à temps. Il doit être une seule commande, exécutable à trois heures du matin par l'astreinte, sans lire de documentation.

# revenir a la version champion precedente
python scripts/revenir_arriere.py churn-telecom

Sous le capot, ce script fait deux choses :

  • Retrouver, dans l'historique du registre, la version qui portait l'alias champion avant la promotion actuelle.
  • Réappliquer cet alias à cette version, ce qui déclenche le rechargement du service.

Le trafic revient à l'ancienne version en quelques secondes. La version défaillante est renommée retiree et son incident est journalisé pour l'analyse à froid.

Le coût, la donnée et la gouvernance​

Réentraîner coûte : temps de calcul, temps d'ingénieur, risque de casse. Trois quantités doivent être mesurées et comparées.

  • Coût de calcul par réentraînement : heures d'accélérateur, stockage temporaire, transfert de données.
  • Bénéfice attendu : amélioration marginale de la métrique métier, chiffrée sur le trafic. Si l'AUC repasse de 0,71 à 0,84 mais que la décision métier ne change pas, le bénéfice net est nul.
  • Risque introduit : probabilité qu'une nouvelle version dégrade la production, multipliée par le coût d'une telle dégradation.

La gouvernance impose enfin que toute promotion soit traçable : qui a approuvé, sur quelle base, avec quels tests. Les registres MLflow et Git fournissent le matériel ; une note de version signée formalise la décision. Dans les secteurs régulés (banque, santé, RH), cette traçabilité n'est pas un confort, c'est une obligation.

La règle des trois R

Réentraîner, revalider, revenir arrière. Un pipeline MLOps mature les rend triviaux : le premier prend une nuit sans intervention, le deuxième une matinée, le troisième une commande. Une équipe qui ne peut pas revenir arrière en dessous de trente minutes n'a pas terminé sa chaîne MLOps, indépendamment du reste.

En résumé​

  • Trois déclencheurs de réentraînement : temporel, par dérive, par volume ; en pratique on combine les trois.
  • La promotion suit deux validations : hors ligne par tranches, en ligne progressive (canari le plus souvent).
  • Le retour arrière est une seule commande qui redéplace l'alias champion ; s'il n'est pas trivial, il n'est pas fait à temps.
  • Coût, bénéfice et risque de chaque réentraînement sont mesurés ; la gouvernance impose traçabilité et signature.

Le récapitulatif dresse la carte complète de la chaîne, du carnet initial au service surveillé et autonome, et annonce l'examen de 40 questions.