---
title: Déploiement Blue-Green
created: 2026-06-06
updated: 2026-06-06
type: concept
tags: [devops, architecture, tech]
confidence: high
contested: false
sources: [synthesized]
---
# 🔵 Déploiement Blue-Green

## Définition Courte
Stratégie de déploiement qui maintient **deux environnements identiques** (Blue et Green) et bascule le trafic de l'un à l'autre instantanément, permettant un **rollback immédiat** en cas de problème.

## Explication Détaillée
**Principe** :
- Blue = version actuelle en production.
- Green = nouvelle version, déployée mais ne reçoit pas (encore) le trafic.
- Tests sont exécutés sur Green (smoke tests, canary interne).
- Bascule du load balancer : tout le trafic va sur Green.
- Blue devient l'environnement de rollback (stand-by).

**Avantages** : 
- Zéro downtime (la bascule est instantanée).
- Rollback en 1 seconde (re-basculer).
- Pas de "version N+1" partielle, tout le monde est sur la même version.

**Inconvénients** : 
- Double infrastructure (coût).
- Gestion des migrations de BDD délicate.
- Pas de progression graduelle (vs canary).

## Cas d'Usage
- Apps avec SLA serré (zéro downtime).
- Déploiements critiques (banque, e-commerce).
- Bases de données compatibles avec un switch rapide.

## Outils Liés
- **Kubernetes** : services + labels, rollout de Deployment.
- **AWS** : Elastic Beanstalk, CodeDeploy.
- **Cloudflare Load Balancer** : pools de serveurs.

## Pages Liées
- [[canary-deployment]]
- [[ci-cd]]
- [[load-balancing]]
- [[checklist-mise-en-production]]
- [[haute-disponibilite]]

## Questions Ouvertes
- Blue-Green vs Canary : quand choisir l'un ou l'autre ?
- Comment gérer les migrations de schéma DB pendant un blue-green ?

## Liens
- [[feature-flags]]