Un canary deployment déplace le trafic progressivement, fraction par fraction, en jugeant sur des métriques à chaque étape. Le blue-green fait l’inverse : bascule tout le trafic d’un coup, d’un environnement complet vers un autre, sans étape intermédiaire. Ce choix radical a un prix précis, et un bénéfice qu’aucune autre stratégie n’égale aussi simplement.

Deux environnements complets, pas deux versions d’un même environnement

Le blue-green fait tourner deux environnements de production identiques et complets simultanément : « blue » sert tout le trafic actuel, « green » héberge la nouvelle version, entièrement déployée et testée, mais sans recevoir aucun trafic réel avant la bascule. Cette séparation totale élimine tout risque d’interaction entre deux versions du code exécutées en même temps, un risque que le rolling update et le canary acceptent implicitement (les deux versions cohabitent forcément le temps de la transition).

# Deux Services distincts pointent vers deux Deployments
# complets, "green" ne reçoit aucun trafic avant la bascule
apiVersion: v1
kind: Service
metadata:
  name: app-active
spec:
  selector:
    version: blue   # bascule vers "green" en une seule modification

La bascule : un changement de sélecteur, pas un déploiement progressif

Une fois « green » validé (tests de fumée, vérifications manuelles, trafic de test synthétique), la bascule elle-même se résume à rediriger le trafic de « blue » vers « green », souvent en changeant un simple sélecteur de Service ou une règle d’Ingress. Cette simplicité est le cœur de la valeur du blue-green : la bascule est quasi instantanée, et surtout, le rollback l’est tout autant, puisque « blue » reste disponible et inchangé, prêt à reprendre le trafic en inversant la même bascule.

# Rollback : la même opération inversée,
# "blue" n'a jamais cessé d'exister ni d'être à jour
kubectl patch service app-active -p '{"spec":{"selector":{"version":"blue"}}}'

Le prix réel : deux fois l’infrastructure, pendant la transition

Faire tourner deux environnements de production complets simultanément coûte, sans surprise, environ le double des ressources habituelles pendant la fenêtre de transition, contre une consommation additionnelle marginale pour un rolling update classique (quelques instances en plus, temporairement). Sur un service à fort trafic, ce doublement peut représenter un coût d’infrastructure significatif, à mettre en balance avec la vitesse de rollback qu’il achète.

Ce que le blue-green ne teste jamais en conditions réelles

Le canary expose une fraction de trafic réel à la nouvelle version avant de généraliser, ce qui révèle des problèmes qui n’apparaissent que sous charge de production authentique (contention de connexions base de données, comportement sous un vrai mélange d’utilisateurs). Le blue-green, en basculant tout d’un coup, ne bénéficie jamais de cette phase d’observation en conditions réelles partielles : la nouvelle version passe directement de zéro trafic réel à 100 %, un saut que seuls des tests synthétiques préalables peuvent partiellement compenser.

Où le blue-green gagne face au canary

Le blue-green excelle quand le rollback doit être instantané et sans ambiguïté, en particulier pour une migration de schéma de base de données ou un changement qui ne se prête pas à une coexistence progressive de deux versions (voir le pattern expand/contract pour la nuance base de données spécifiquement). Il excelle aussi quand la simplicité opérationnelle prime : pas de configuration de pourcentage de trafic à ajuster progressivement, pas de métriques de comparaison à définir à l’avance, juste une bascule binaire, validée avant coup.

À retenir

Le blue-green bascule tout le trafic d’un coup entre deux environnements complets, contre un déplacement progressif et jugé pour le canary : le bénéfice est un rollback instantané et sans ambiguïté, le prix est une infrastructure doublée pendant la transition et l’absence de phase d’observation sous trafic réel partiel. Le choix entre les deux n’est pas une question de maturité technique mais de nature du risque à gérer : rollback binaire rapide contre validation progressive sous charge réelle, une décision qui s’inscrit dans la même logique que le reste d’une industrialisation CI/CD.