Accueil › Glossaire › Blue-Green Deployment

Blue-Green Deployment

Le blue-green deployment est une stratégie de déploiement qui maintient deux environnements de production identiques (« blue » pour la version actuelle, « green » pour la nouvelle version) et bascule le trafic de l’un à l’autre en une seule opération, permettant des mises à jour sans interruption de service et un rollback instantané en cas de problème.

Le concept, popularisé par Jez Humble et David Farley dans leur ouvrage « Continuous Delivery » (2010), a été adopté massivement dans le DevOps logiciel avant de devenir une pratique standard en MLOps. Pour les modèles ML en production, le blue-green deployment résout un problème critique : comment mettre à jour un modèle sans exposer les utilisateurs à une indisponibilité ou à un modèle défaillant ? La réponse : vous ne touchez jamais à l’environnement actif. Vous préparez, validez et testez la nouvelle version dans un environnement séparé, puis vous basculez instantanément le trafic.

Comment fonctionne le blue-green deployment

Le processus étape par étape

1. L’environnement blue est en production. Il sert 100 % du trafic réel. C’est votre modèle actuel, stable et validé.

2. Provisionnement de l’environnement green. Vous créez un second environnement de production identique en termes d’infrastructure (compute, mémoire, réseau), mais avec la nouvelle version du modèle. Ce provisionnement peut être automatisé via Infrastructure as Code (Terraform, CloudFormation, Helm charts pour Kubernetes).

3. Validation du green en isolation. Le nouvel environnement est testé avec des données de test, des requêtes synthétiques et des benchmarks de performance, sans recevoir de trafic réel. Cette phase vérifie que le modèle fonctionne correctement, que la latence est acceptable et que les résultats sont conformes aux attentes.

4. Shadow testing (optionnel mais recommandé). Avant la bascule, vous pouvez dupliquer (mirror) un pourcentage du trafic réel vers l’environnement green sans que ses réponses soient renvoyées aux utilisateurs. Azure ML supporte nativement cette fonctionnalité. Le shadow testing permet de comparer les prédictions du green avec celles du blue sur des données réelles, sans risque pour les utilisateurs.

5. Bascule du trafic. Une fois la validation terminée, le load balancer redirige 100 % du trafic du blue vers le green. La bascule est quasi-instantanée (quelques secondes). Les utilisateurs ne perçoivent aucune interruption.

6. Surveillance post-bascule (baking period). L’environnement green sert maintenant tout le trafic. Pendant une période de surveillance (le « baking period »), les métriques sont monitorées intensivement. Si un problème est détecté, le trafic est immédiatement redirigé vers l’environnement blue, qui est toujours opérationnel. C’est le rollback instantané.

7. Décommissionnement du blue. Si le green fonctionne correctement après la période de surveillance, l’ancien environnement blue est décommissionné (ou conservé comme base pour la prochaine mise à jour).

Blue-green pour les modèles ML

Le blue-green deployment a des implications spécifiques dans le contexte ML qui le distinguent du déploiement logiciel classique.

Intégration avec le model registry

Chaque environnement pointe vers une version spécifique du modèle dans le model registry (MLflow, SageMaker Model Registry). Le blue pointe vers v1.0, le green vers v2.0. Le registry maintient la traçabilité complète : données d’entraînement, hyperparamètres, métriques d’évaluation, et date de promotion. Cette traçabilité est essentielle pour le rollback (savoir exactement à quelle version revenir) et pour la conformité réglementaire (EU AI Act Article 72 sur le monitoring post-marché).

Évaluation pré-bascule

Avant la bascule, le modèle green doit passer des quality gates automatisés. Le pipeline CI/CD compare les métriques du green au baseline du blue : si la precision, le recall, le F1 ou la latence ne respectent pas les seuils définis, le déploiement est bloqué automatiquement. Pour les applications LLM, un LLM-as-judge peut être intégré dans ces quality gates pour évaluer la qualité des réponses du nouveau modèle avant la mise en production.

Cohérence des features

Le training-serving skew (différence entre les features utilisées à l’entraînement et celles utilisées en production) est la cause n°1 d’échec silencieux des modèles en production. En blue-green deployment, les deux environnements doivent utiliser le même feature store pour garantir que les features servies sont identiques. Si le nouveau modèle a été entraîné avec de nouvelles features, le feature store doit les supporter avant la bascule.

Gestion des données et bases de données

C’est le défi le plus complexe du blue-green deployment. Si les deux versions du modèle partagent la même base de données (logs, prédictions, feedback), les schémas doivent rester compatibles. Les migrations de schéma doivent être rétro-compatibles : le blue doit pouvoir fonctionner avec le nouveau schéma en cas de rollback. Les stratégies incluent les migrations par colonnes additionnelles (jamais supprimer ou renommer), le versionnement des tables, et les patterns d’expansion/contraction.

Implémentation sur les plateformes cloud

Azure Machine Learning

Azure ML supporte le blue-green nativement via les managed online endpoints. Vous créez un endpoint unique, puis ajoutez des déploiements (blue, green) avec allocation de trafic configurable. Le shadow testing est intégré : vous pouvez dupliquer le trafic vers le green sans impacter les réponses aux utilisateurs. La bascule se fait via une simple mise à jour de l’allocation de trafic (blue=0, green=100). Azure gère automatiquement le load balancing, le scaling et le health monitoring.

AWS SageMaker

SageMaker propose des « deployment guardrails » avec support natif du blue-green. Le processus : SageMaker provisionne une nouvelle flotte (green), bascule le trafic selon le mode choisi (all-at-once, canary, ou linear), puis, après une période de surveillance (baking period), termine la flotte blue. Les trois modes de traffic shifting sont All-At-Once (bascule totale), Canary (petit pourcentage d’abord, puis 100 %), et Linear (augmentation progressive par paliers réguliers). L’auto-rollback est configurable : si les CloudWatch alarms se déclenchent pendant la bascule, le trafic revient automatiquement au blue.

Kubernetes

Sur Kubernetes, le blue-green se réalise via deux Deployments distincts (un pour blue, un pour green) et un Service qui pointe vers l’un ou l’autre via un sélecteur de labels. La bascule consiste à modifier le label selector du Service pour pointer vers le green. Des outils comme Argo Rollouts ou Flagger automatisent ce processus avec des analyses de métriques intégrées et un rollback automatique. C’est l’approche la plus flexible mais qui requiert le plus d’expertise.

Exemple concret : blue-green pour un modèle de classification d’images

Prenons un cas réel rapporté par un ingénieur MLOps (DataCamp) : le déploiement d’un modèle de classification d’images en production. La première mise à jour a été faite sans stratégie blue-green. Résultat : le Pod hébergeant le nouveau modèle ne démarrait pas à cause de différences entre l’environnement de test et l’environnement de production. Pendant ce temps, le Pod de l’ancien modèle avait déjà été remplacé. Aucun modèle en ligne, utilisateurs bloqués, rollback manuel et excuses.

Après passage au blue-green : le nouveau modèle est déployé dans un environnement green séparé, testé en isolation, puis le trafic est basculé. Si le green échoue, le blue est toujours opérationnel. Le rollback prend quelques secondes au lieu de dizaines de minutes de panique. Leçon : le surcoût du blue-green est un investissement dans la tranquillité d’esprit.

Monitoring post-bascule

La période qui suit immédiatement la bascule (le « baking period » dans la terminologie AWS SageMaker) est la phase la plus critique. Pendant cette période, vous devez monitorer intensivement les métriques suivantes.

Métriques de performance ML : accuracy, precision, recall, F1 score comparés au baseline du blue. Toute dégradation significative doit déclencher un rollback automatique. Les seuils sont définis à l’avance dans les deployment guardrails.

Métriques d’infrastructure : latence d’inférence (le green doit être comparable ou meilleur que le blue), throughput (requêtes par seconde), utilisation CPU/GPU/mémoire, et taux d’erreurs HTTP (4xx, 5xx). AWS SageMaker configure des CloudWatch alarms sur ces métriques pour l’auto-rollback.

Métriques de qualité des données : distribution des features d’entrée (détection de data drift), taux d’anomalies dans les inputs, et cohérence entre les données servies et les données d’entraînement. Un changement soudain dans la distribution des inputs peut indiquer un problème en amont du modèle, pas dans le modèle lui-même.

Métriques métier : taux de conversion (si applicable), taux de plaintes clients, volume de transactions traitées. Ces métriques prennent plus de temps à se stabiliser (jours plutôt que minutes) mais sont le test ultime de la valeur du nouveau modèle.

Blue-green vs canary release

La recommandation pour les applications ML à haut risque : combinez les deux. Shadow testing d’abord, puis canary (5-10 %) pour la validation en conditions réelles, puis bascule blue-green (100 %) quand les métriques sont confirmées. Les organisations qui implémentent cette combinaison rapportent 40 % d’incidents de production en moins par rapport aux déploiements sans stratégie de rollout progressif.

Verdict Polydesk

Le blue-green deployment est la stratégie de déploiement la plus sûre pour les modèles ML en production, grâce à son rollback instantané. Son coût d’infrastructure doublé est le prix de cette sécurité. Pour les applications critiques (détection de fraude, diagnostic médical, systèmes financiers), ce coût est amplement justifié par l’élimination du risque d’indisponibilité.

En pratique : si vous déployez sur Azure ML ou AWS SageMaker, le blue-green est supporté nativement et ne requiert que quelques lignes de configuration. Sur Kubernetes, utilisez Argo Rollouts pour automatiser la bascule et le rollback. Combinez avec le shadow testing pour valider sur du trafic réel sans risque, et avec le monitoring continu (évaluation de modèle automatique) pour détecter les régressions post-bascule.

Le piège courant : négliger la gestion des données. Si votre modèle écrit dans une base de données partagée entre blue et green, une migration de schéma mal gérée peut rendre le rollback impossible. Planifiez des migrations rétro-compatibles et testez le rollback avant chaque déploiement.

Anti-patterns à éviter

Décommissionner le blue trop tôt. Conservez l’ancien environnement pendant au moins 24-48h après la bascule. Certains problèmes ne se manifestent qu’avec le trafic de pointe ou les patterns d’usage spécifiques à certains jours/heures. Un rollback impossible après décommissionnement du blue est le scénario catastrophe.

Ignorer la compatibilité des schémas. Si le modèle green écrit dans un format de log différent du blue, le rollback peut corrompre les données. Toutes les modifications doivent être rétro-compatibles.

Tester uniquement en isolation. Les tests sur données synthétiques ne révèlent pas les problèmes de trafic réel (patterns imprévus, volumes de pointe, données corrompues). Le shadow testing sur trafic réel est indispensable avant la bascule.

Ne pas automatiser le rollback. Un rollback manuel à 3h du matin a toutes les chances d’être lent, stressant et sujet à erreurs. Configurez l’auto-rollback sur des métriques claires avant chaque déploiement.