Pendant deux ans, tous les sites que j’héberge ont tourné sur un seul serveur. Il a bien rempli son rôle, mais un seul serveur, c’est aussi un seul point de panne : si la machine tombe, les sites, la supervision et les outils tombent avec elle. En octobre 2026, j’ai tout déménagé sur une nouvelle infrastructure. Voici les choix et la façon dont la migration s’est passée.
Deux serveurs, deux rôles
L’infrastructure tient maintenant sur deux machines, chacune avec un rôle clair :
- le serveur des sites fait tourner les sites WordPress des clients, en production et en préproduction, chacun dans son conteneur ;
- le serveur de pilotage fait tourner les outils : supervision, tableau de bord de maintenance, mises à jour automatisées, statistiques de visite.
Les deux sont reliés par un tunnel chiffré WireGuard. Les outils internes n’écoutent que sur ce tunnel : ils ne sont pas exposés sur internet.
Deux hébergeurs français
Les deux serveurs sont chez deux hébergeurs différents, en France : OVH pour les sites, Scaleway pour le pilotage. Un incident chez l’un ne coupe pas l’autre, et surtout les sauvegardes ne sont jamais sur la machine qu’elles protègent. J’ai écarté les offres hors de France et les hébergeurs dont les tarifs ont fortement augmenté cette année.
Des sauvegardes croisées, impossibles à effacer
Chaque nuit, chaque serveur sauvegarde ses données sur l’autre avec restic : bases de données (exportées proprement avant la sauvegarde), fichiers des sites, configuration. Les sauvegardes sont chiffrées, incrémentales et dédupliquées.
Le point important : le serveur de réception est en ajout seul. Le serveur des sites peut déposer une sauvegarde, pas en effacer. Un attaquant qui prendrait la main sur un site ne pourrait pas supprimer l’historique pour empêcher la restauration. La purge des anciennes sauvegardes est faite par le serveur qui les reçoit.
Rétention : 6 sauvegardes quotidiennes, 4 hebdomadaires, 6 mensuelles, et un point par semestre gardé deux ans. Une sauvegarde qui n’a pas réussi depuis plus de 26 heures déclenche une alerte.
Une sauvegarde n’existe que si on sait la restaurer. La restauration d’un site à une date donnée est un playbook Ansible, testé sur une préproduction : quelques secondes pour revenir à l’état de la veille. Le test sera refait chaque trimestre.
Tout est décrit en code
Rien n’est configuré à la main. Pare-feu, reverse proxy, bases de données, comptes de chaque site, sauvegardes, supervision : tout est décrit dans des rôles Ansible, versionnés dans GitLab et relus avant d’être appliqués. Monter un troisième serveur, ou reconstruire l’un des deux, revient à rejouer ces rôles.
Chaque site a sa propre base et son propre compte de base de données, ses propres secrets, ses plafonds de mémoire et de processus. Les principes de sécurité sont détaillés dans Sécuriser une infrastructure WordPress auto-hébergée.
Une migration site par site, sans coupure
Chaque site a été déménagé seul, avec la même procédure :
- création de ses comptes sur le nouveau serveur ;
- déploiement de son code par la CI, comme d’habitude, mais vers le nouveau serveur ;
- copie de la base et des médias, puis vérification du site sur le nouveau serveur alors que le public voit encore l’ancien ;
- nouvelle copie des données juste avant la bascule, pour ne rien perdre ;
- changement du DNS, puis certificat HTTPS et contrôles automatiques.
Pendant la propagation du DNS, l’ancien et le nouveau serveur répondent tous les deux : les visiteurs ne voient pas de coupure. L’ancien serveur garde le site une à deux semaines, en secours, avant d’être nettoyé.
Ce que ça change
Pour les sites que j’héberge : une panne d’un hébergeur n’emporte plus les sauvegardes, les sauvegardes ne peuvent plus être effacées depuis le serveur attaqué, et la restauration est testée. Pour moi : une infrastructure que je peux reconstruire à l’identique, et que je pourrai confier à un administrateur système sans lui transmettre de savoir caché. La supervision a aussi changé : j’en parle dans une note dédiée.
Vous cherchez un hébergement WordPress en France, avec un interlocuteur qui connaît votre site ? Écrivez-moi à contact@juzed.dev.
Stack : Ansible · Docker · WireGuard · restic · Traefik · MariaDB · Redis · CrowdSec · GitLab CI/CD