# Atomique, blue-green, canary : le glossaire du déploiement WordPress > Définitions claires des principales stratégies de déploiement, leurs prérequis techniques et ce qu'elles impliquent concrètement pour un projet WordPress. - Auteur : Clément Hadrot - Publié le : 2026-06-08 - Mis à jour le : 2026-06-08 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/glossaire-strategies-deploiement-wordpress/ ## L’essentiel - Chaque stratégie répond à un risque précis, pas à tous à la fois - Le déploiement atomique est le socle sur lequel les autres s'appuient - Canary et blue-green demandent un trafic suffisant pour être pertinents Les termes « blue-green », « canary » ou « déploiement atomique » circulent souvent sans définition précise, empruntés tels quels à l'écosystème des applications web plus large sans être toujours reformulés pour WordPress. Ce glossaire ne détaille pas la mise en œuvre pas à pas de chaque stratégie — d'autres articles s'en chargent — mais pose des définitions nettes, leurs prérequis, et le risque précis auquel chacune répond. ## Le déploiement en place (la référence à laquelle tout se compare) La méthode la plus répandue reste le déploiement en place : les nouveaux fichiers écrasent directement les anciens, sur le même serveur, généralement via `rsync` ou une extraction d'archive directement dans le dossier servi. Simple à comprendre, mais avec un défaut structurel : pendant la durée du transfert, le site sert un mélange incohérent d'anciens et de nouveaux fichiers, ce qui peut provoquer des erreurs transitoires si un visiteur charge une page au mauvais instant. ## Le déploiement atomique Le déploiement atomique corrige précisément ce défaut. Chaque nouvelle version est déployée intégralement dans un nouveau dossier isolé (une *release*), puis un lien symbolique unique (souvent nommé `current`) est repointé d'un coup vers ce nouveau dossier une fois le déploiement terminé et validé. Le changement de version, du point de vue du serveur web, se résume à changer une seule cible de lien symbolique — une opération quasi instantanée, sans état intermédiaire incohérent. ``` releases/ ├── 20260601-1200/ ├── 20260605-0900/ └── 20260608-0745/ releases/20260608-0745/ ``` C'est le socle sur lequel reposent la plupart des outils de déploiement modernes pour WordPress (Deployer, par exemple), et c'est aussi le prérequis technique implicite des trois autres stratégies présentées ici : sans releases isolées, ni le blue-green ni le canary ne peuvent fonctionner proprement. > L'essentiel à retenir : Chaque stratégie répond à un risque précis, pas à tous à la fois ; Le déploiement atomique est le socle sur lequel les autres s'appuient ; Canary et blue-green demandent un trafic suffisant pour être pertinents ## Le déploiement blue-green Le blue-green maintient deux piles applicatives complètes et identiques, une seule active à la fois, et bascule le trafic entre elles au niveau d'un proxy ou d'un équilibreur de charge. Le prérequis principal : les deux piles doivent pouvoir cohabiter, ce qui pose la question de la base de données partagée entre elles et impose des migrations de schéma rétrocompatibles pendant la période de transition. Le risque auquel il répond : réduire à quasiment zéro le temps de rollback en cas de problème détecté après bascule, puisque revenir en arrière consiste simplement à repointer le proxy vers la pile précédente. ## Le déploiement canary Le déploiement canary consiste à exposer la nouvelle version à une fraction seulement du trafic réel — cinq pour cent des visiteurs, par exemple, sélectionnés aléatoirement ou par cookie — pendant que la majorité continue d'utiliser l'ancienne version. Si aucune anomalie n'est détectée sur cette fraction pendant une période d'observation, la proportion de trafic redirigée vers la nouvelle version augmente progressivement jusqu'à cent pour cent. Le risque auquel il répond diffère du blue-green : il ne s'agit pas de réduire le temps de rollback, mais de limiter le nombre d'utilisateurs affectés si un défaut échappe aux tests et à la recette. Pour WordPress, cette stratégie exige un mécanisme de routage capable de maintenir un même visiteur sur la même version pendant toute sa session (via un cookie ou une règle d'affinité), sous peine d'incohérences visibles s'il bascule d'une version à l'autre entre deux pages consultées. | Stratégie | Répond à quel risque | Prérequis principal | | --- | --- | --- | | Déploiement atomique | Incohérence pendant le transfert de fichiers | Releases isolées + lien symbolique | | Blue-green | Temps de rollback trop long | Deux piles complètes + proxy de bascule | | Canary | Nombre d'utilisateurs exposés à un défaut | Routage par fraction de trafic + affinité de session | ## Ce qui distingue vraiment ces stratégies entre elles La confusion la plus fréquente consiste à opposer ces stratégies comme si une seule devait être choisie. En réalité, elles se combinent souvent : un déploiement atomique reste la base technique de tous les projets sérieux, le blue-green s'y ajoute pour les projets où l'indisponibilité a un coût direct, et le canary s'y superpose encore pour les projets à très fort trafic où même une bascule complète représente un risque jugé trop large. > Quand un client nous demande « lequel de ces trois on devrait utiliser », la réponse commence presque toujours par une autre question : votre site a-t-il déjà un déploiement atomique en place ? La plupart du temps, la réponse est non, et c'est cette étape-là qui apporte le plus grand gain immédiat. ## Notion connexe : le rolling deployment Sur une infrastructure à plusieurs serveurs ou plusieurs pods (dans un contexte Kubernetes, par exemple), le déploiement en continu remplace progressivement les instances une par une, plutôt que de basculer d'un bloc entre deux piles complètes. Il partage avec le canary l'idée d'une transition progressive, mais sans nécessairement isoler une fraction contrôlée du trafic pour observation ciblée. ## Pour aller plus loin Ce glossaire pose les définitions ; la mise en œuvre concrète de chaque stratégie — configuration du proxy, gestion des migrations partagées, mécanisme de routage par cookie — mérite un traitement dédié propre à chaque contexte d'hébergement, tant les implémentations varient d'un hébergeur à l'autre et d'un projet à l'autre.