Un site WordPress qui commence à saturer un VPS unique déclenche souvent le même réflexe : louer une machine plus puissante, avec plus de vCPU et de RAM. Cette approche, appelée montée en charge verticale, fonctionne un temps, mais atteint rapidement une limite physique et budgétaire — au-delà d’un certain gabarit, les machines les plus puissantes coûtent disproportionnellement cher pour un gain de capacité de moins en moins net.
La montée en charge horizontale, qui consiste à répartir la charge entre plusieurs machines plutôt que d’en grossir une seule, demande davantage de travail d’architecture, mais offre une marge de croissance nettement plus large. Voici les étapes que nous suivons, dans l’ordre où elles apportent le plus de valeur pour un site WordPress à trafic croissant.
Étape 1 : séparer le serveur web de la base de données
Sur un VPS unique, nginx, PHP-FPM et MariaDB se partagent les mêmes ressources CPU et mémoire, ce qui signifie qu’un pic de requêtes en base ralentit directement le rendu des pages. La première étape de montée en charge consiste à déplacer MariaDB sur une machine dédiée, reliée au serveur web par un réseau privé plutôt que par l’Internet public, pour limiter la latence et exposer la base au minimum.
define( 'DB_HOST', '10.0.0.5' );
Ce seul changement, dans wp-config.php, libère des ressources sur le serveur web pour le rendu PHP, et permet de dimensionner indépendamment chaque machine selon son usage réel plutôt que selon une moyenne des deux besoins.
Étape 2 : ajouter un cache objet partagé
Dès qu’un site s’appuie sur plusieurs serveurs web, le cache objet WordPress (qui stocke en mémoire les résultats de requêtes coûteuses) ne peut plus rester local à chaque machine sans perdre en cohérence. Un serveur Redis dédié, partagé par tous les serveurs web, garantit que chaque instance de WordPress voit le même cache, quel que soit celui qui a traité la requête précédente.
Étape 3 : répartir le trafic entre plusieurs serveurs web
Une fois la base et le cache externalisés, plusieurs serveurs web identiques peuvent traiter les requêtes en parallèle, à condition qu’un répartiteur de charge (load balancer) distribue le trafic entre eux. HAProxy ou nginx lui-même, configuré en amont comme répartiteur, redirige chaque requête entrante vers l’un des serveurs disponibles :
upstream backend_wordpress {
server 10.0.0.10;
server 10.0.0.11;
}
server {
listen 80;
location / {
proxy_pass http://backend_wordpress;
}
}
Cette configuration exige que les fichiers uploadés (dossier wp-content/uploads) soient accessibles de façon identique depuis tous les serveurs web, généralement via un stockage partagé en réseau (NFS) ou un service de stockage objet compatible S3.
Étape 4 : répliquer la base de données
Pour éviter que la base de données ne devienne à son tour le point de blocage, MariaDB permet de mettre en place une réplication : un serveur principal (maître) traite les écritures, tandis que plusieurs serveurs secondaires (esclaves ou répliques) répondent aux lectures, bien plus nombreuses sur un site WordPress typique. Cette répartition exige d’adapter le code — via un plugin de répartition de requêtes comme HyperDB — pour diriger explicitement les lectures vers les répliques et les écritures vers le maître.
Ce qu’il ne faut pas sauter
- Un cache de page en amont (fastcgi_cache ou un CDN) reste souvent plus rentable que toute cette architecture pour un site majoritairement statique.
- La complexité opérationnelle augmente à chaque étape : plus de serveurs signifie plus de surveillance, plus de sauvegardes à coordonner.
- Chaque étape doit être justifiée par une mesure réelle de saturation, pas par anticipation d’un trafic qui n’arrivera peut-être jamais.
La montée en charge horizontale n’est pas un objectif en soi : c’est une réponse à un problème mesuré. L’ajouter par précaution, sans preuve de saturation, ajoute de la complexité sans bénéfice réel.
En résumé
La progression logique va de la séparation web et base de données, vers un cache objet partagé, puis vers la répartition de charge entre plusieurs serveurs web, et enfin la réplication de la base pour les sites qui l’exigent réellement. Chaque étape ajoute de la capacité, mais aussi de la complexité d’exploitation : elle ne se justifie que si une mesure concrète de saturation le confirme.
