La direction veut « zéro interruption de service ». L'équipe provisionne deux stacks identiques — double VPS, double Redis, double PostgreSQL « par sécurité ». La facture double, la migration n'a jamais été testée en parallèle. Le jour J, le basculement DNS révèle que la stack verte pointe encore vers l'ancienne variable d'environnement : retour arrière en cinq minutes, mais le coût mensuel du double reste.
Le déploiement blue-green réduit le risque de bascule ; il ne justifie pas automatiquement le double de chaque ressource. La discipline consiste à doubler ce qui bascule vite — application, workers — et à investir dans des migrations de données compatibles plutôt qu'à cloner aveuglément Postgres.
Ce qui doit être doublé — et ce qui peut être partagé
| Composant | Souvent doublé | Souvent partagé |
|---|---|---|
| App / API sans état | ✅ | — |
| Workers de file d'attente | ✅ ou montée temporaire | — |
| Cache Redis | ⚠️ selon invalidation | parfois |
| PostgreSQL | ⚠️ coûteux | migrations rétrocompatibles |
| Stockage objet | — | ✅ versions immuables |
Le schéma base partagée, double application repose sur des migrations rétrocompatibles : ajout d'une colonne nullable, pas de renommage brutal. Le retour arrière consiste à renvoyer le trafic, pas à restaurer la base.
Doubler PostgreSQL « au cas où » sans stratégie de migration = coût maximal, retour arrière illusoire.
Basculement de trafic et fenêtre de retour arrière
Déployez d'abord la stack verte et lancez des tests internes — en-tête X-Deploy: green ou nom d'hôte dédié. Vérifiez que cent pour cent des instances vertes passent le contrôle de disponibilité. Basculez ensuite le répartiteur, l'Ingress ou le DNS, progressivement si possible. Surveillez les erreurs applicatives et gardez la stack bleue inactive quelques heures.
Le retour arrière inverse le flux — instantané si l'état partagé reste compatible. Si la stack verte a écrit un format incompatible, le retour arrière applicatif exige une restauration de base, souvent nocturne.
Coût, autoscaling et fenêtres courtes
La stack bleue n'a pas besoin de tourner vingt-quatre heures sur vingt-quatre à capacité production : elle peut rester plus petite hors release, puis monter avant le déploiement. Certaines équipes ne maintiennent la stack verte chaude que le jour de la mise en production.
Sous Kubernetes : deux déploiements ou Argo Rollouts avec service de prévisualisation. Sur VPS : deux dossiers Compose, Traefik avec pondération. Optimisez la durée du double, pas seulement l'existence du pattern.
Données de session et sessions persistantes
Sessions en mémoire sur la stack bleue : les utilisateurs basculés vers la stack verte perdent leur session. Externalisez les sessions — Redis, par exemple — avant d'adopter blue-green. Même problème pour les fichiers uploadés localement sur le disque bleu : un stockage objet partagé est requis.
Tests et répétition
Organisez un exercice mensuel : déploiement fictif, basculement en préproduction, retour arrière chronométré. Documentez qui déclenche le switch et les critères d'abandon. Un déploiement blue-green non répété reste une procédure théorique le jour où la production tremble.
Le sommet : double stack, retour arrière simple — un mythe
Réduire le risque sans doubler aveuglément les coûts, c'est doubler le sans état, investir dans des migrations expansion-contraction, garder la stack bleue en réserve temporaire.
Décider et avancer sans angle mort
Cartographiez d'abord ce qui est sans état versus avec état dans votre architecture, puis validez que vos migrations de schéma restent compatibles avec les deux versions de code. Testez le basculement et le retour arrière en préproduction avant le jour J. Dimensionnez la stack bleue pour la fenêtre de release uniquement, pas pour une duplication permanente. Comparez répartiteurs, VPS et Kubernetes via l'annuaire et le comparateur, et parcourez les guides pour le release engineering. Votre métrique de succès : un retour arrière en préproduction en moins de cinq minutes sans restauration de base — sinon revoyez le pattern.
Questions fréquentes
Blue-green double-t-il toujours la facture ?
Non, si seule l'application sans état est doublée et la base partagée avec des migrations rétrocompatibles. Dupliquer toute la stack, base incluse, double presque tout — sans garantir un retour arrière simple.
Comment basculer le trafic proprement ?
Contrôle de santé complet sur la stack verte, puis switch du répartiteur ou du DNS — progressivement si possible. Gardez la stack bleue chaude quelques heures pour un retour arrière rapide.
Et les migrations de schéma ?
Appliquez expansion-contraction pour compatibilité ancien et nouveau code avant le switch. Sinon la stack verte ne démarre pas ou la bleue casse après retour arrière.
Blue-green vs rolling update ?
Blue-green : switch instantané et retour arrière rapide, surcoût ponctuel. Rolling update : progression graduelle, moins de surplus, retour arrière plus lent. Choix selon SLA et budget.
Un blue-green intelligent double ce qui bascule vite — pas ce qui coûte cher à synchroniser.