Projet démo : migration d'un site WordPress vers un VPS cloud

Ce projet démonstratif reproduit une situation courante : un site WordPress hébergé sur un hébergement mutualisé, devenu lent et difficile à faire évoluer, que l'on souhaite migrer vers un serveur cloud maîtrisé. Il ne s'agit pas d'un projet client, mais d'un environnement que nous maintenons pour illustrer notre méthode.

Le site modélisé est un site éditorial avec plusieurs milliers d'articles, des extensions habituelles (SEO, formulaires, cache) et une équipe de rédaction qui publie quotidiennement et ne peut pas se permettre d'interruption prolongée.

L'objectif est de montrer comment passer d'un hébergement où l'on ne contrôle ni la version de PHP, ni le cache, ni les sauvegardes, à une infrastructure reproductible, documentée et surveillée.

Sur un hébergement mutualisé, les ressources sont partagées et opaques : le site ralentit aux heures de pointe, les mises à jour se font en production sans environnement de test et les sauvegardes dépendent de l'hébergeur.

Migrer sans méthode expose à des pertes de contenu, des liens cassés, une baisse de référencement et une interruption pendant la bascule DNS.

Un VPS cloud héberge l'ensemble des services dans des conteneurs Docker orchestrés par Docker Compose : Nginx en frontal, PHP-FPM pour WordPress, MariaDB pour la base et Redis pour le cache d'objets.

Nginx sert directement les fichiers statiques, applique un cache de pages pour les visiteurs non connectés et termine le TLS avec des certificats Let's Encrypt renouvelés automatiquement.

Un CDN placé devant le serveur absorbe la majorité du trafic sur les médias et les pages en cache et filtre les requêtes malveillantes.

Un environnement de recette identique à la production, protégé par mot de passe, permet de tester les mises à jour de WordPress, du thème et des extensions.

Un pipeline GitHub Actions déploie le thème et la configuration versionnés vers la recette puis vers la production, et des sauvegardes chiffrées (base et médias) sont envoyées chaque nuit vers un stockage objet externe.

La migration commence par un inventaire : version de PHP, extensions, tâches planifiées, taille de la base et des médias, URL et redirections existantes. Cet inventaire sert à préparer la configuration Docker et à identifier les extensions incompatibles ou devenues inutiles.

Le site est copié vers le nouveau serveur, d'abord dans l'environnement de recette, où l'on vérifie page par page le rendu, les formulaires, les redirections et les tâches planifiées. Les URL sont réécrites proprement dans la base, et le cache d'objets Redis est activé via une extension dédiée.

Le jour de la bascule, une dernière synchronisation de la base et des médias est effectuée, le TTL DNS ayant été abaissé au préalable. Le DNS est ensuite pointé vers le CDN et le nouveau serveur ; l'ancien hébergement reste en place quelques jours pour permettre un retour arrière.

Après la migration, la surveillance (disponibilité, temps de réponse, espace disque, expiration des certificats) est mise en place et les sauvegardes sont vérifiées par une restauration réelle sur l'environnement de recette.