Le déploiement blue-green repose sur un principe simple à énoncer et plus subtil à mettre en œuvre correctement : au lieu de mettre à jour un serveur en place, on maintient deux piles applicatives complètes et identiques — appelées conventionnellement « bleue » et « verte » — dont une seule reçoit le trafic réel à un instant donné. Déployer une nouvelle version consiste à l’installer sur la pile inactive, la valider tranquillement, puis basculer le trafic vers elle d’un coup, au niveau du proxy.
Pour WordPress, ce schéma résout élégamment le problème des fichiers applicatifs (thème, extensions, cœur), mais se heurte à une difficulté propre à toute application avec état persistant : la base de données. Ce chapitre détaille l’architecture complète, y compris ce point de friction.
L’architecture à deux piles
┌─────────────┐
Trafic réel ──▶ │ Proxy │
│ (nginx / │
│ load bal.) │
└──────┬──────┘
│ pointe vers une seule pile à la fois
┌────────────┴────────────┐
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Pile BLEUE │ │ Pile VERTE │
│ (active) │ │ (en attente) │
│ PHP-FPM │ │ PHP-FPM │
│ code v1.4 │ │ code v1.5 │
└───────┬───────┘ └───────┬───────┘
│ │
└────────────┬────────────┘
▼
┌───────────────────┐
│ Base de données │
│ partagée (unique)│
└───────────────────┘
Les deux piles exécutent le même code WordPress, chacune sur son propre jeu de conteneurs ou de serveurs, mais elles se connectent généralement à la même base de données — c’est là que réside toute la difficulté du schéma appliqué à WordPress.
La bascule au niveau du proxy
La bascule elle-même est l’opération la plus simple du schéma : il s’agit de changer la cible du proxy (nginx, un équilibreur de charge cloud, ou un service comme un Ingress Kubernetes) pour qu’il redirige le trafic entrant vers la pile verte plutôt que bleue. Correctement configurée, cette bascule est quasi instantanée et réversible tout aussi vite :
# exemple simplifié avec un upstream nginx
upstream pile_active {
server pile-verte.interne:9000;
# server pile-bleue.interne:9000; <- commenté après bascule
}
Un rechargement de configuration nginx (nginx -s reload) suffit à appliquer le changement sans interruption de service perceptible, contrairement à un redémarrage complet qui couperait les connexions en cours.
Le point délicat : la base de données partagée
Si les deux piles applicatives partagent la même base, un problème structurel se pose dès qu'une migration de schéma accompagne le déploiement : la nouvelle version (pile verte) peut avoir besoin d'une colonne ou d'une table que l'ancienne version (pile bleue) ne connaît pas, ou inversement, l'ancienne version peut être perturbée par une structure de données modifiée par la migration.
La pratique qui limite ce risque consiste à n'accepter, dans ce schéma, que des migrations rétrocompatibles à double sens : ajouter une colonne sans en supprimer, ou l'ajouter avec une valeur par défaut que l'ancien code ignore sans erreur. Toute migration destructrice (suppression de colonne, renommage) doit être reportée à un déploiement ultérieur, une fois que la pile bleue a été définitivement mise hors service.
Ce que le blue-green apporte concrètement
- Un rollback quasi instantané : si un problème est détecté après bascule, repointer le proxy vers l'ancienne pile ramène l'état précédent en quelques secondes, sans réinstallation ;
- Une phase de validation en conditions réelles avant bascule : la nouvelle version peut être testée directement sur son infrastructure de production, en accès restreint, avant d'être exposée au trafic public ;
- Une absence totale de temps d'indisponibilité perceptible lors du déploiement lui-même, contrairement à une mise à jour en place qui immobilise brièvement le serveur.
Ce que ça coûte
Le coût le plus évident est celui de l'infrastructure : deux piles complètes tournent en permanence (ou au minimum sont provisionnées à chaque déploiement), ce qui double potentiellement la facture de calcul par rapport à un serveur unique. Le coût le moins visible, mais souvent plus contraignant en pratique, est la discipline imposée sur les migrations de base de données, qui empêche certains changements de structure simples et rapides en mise à jour classique.
Le blue-green n'élimine pas le besoin de réfléchir aux migrations de base : il rend simplement leurs conséquences beaucoup plus visibles, beaucoup plus vite, ce qui est en réalité une bonne discipline à adopter même sans ce schéma.
En résumé
Le déploiement blue-green offre à WordPress un vrai gain en matière de rollback instantané et de validation en conditions réelles avant bascule, au prix d'une infrastructure doublée et d'une discipline stricte sur les migrations de base de données partagée. C'est une architecture qui se justifie pour des sites où l'indisponibilité, même de quelques secondes, a un coût réel — pas pour un site vitrine à faible trafic, où la complexité ajoutée dépasserait largement le bénéfice.
