Migration d’un mutualisé vers un VPS : ce qui casse et comment le réparer

Un site qui ralentit aux heures de pointe ou qui réclame des logiciels absents de son offre peut avoir dépassé l’hébergement mutualisé. Passer sur un VPS apporte davantage de contrôle, mais transfère aussi au propriétaire la gestion du serveur.

Les incidents surviennent souvent après le transfert : images invisibles, erreurs de connexion à la base de données, permissions de fichiers incorrectes ou certificat SSL absent. Une migration web préparée et testée avant le changement de DNS aide à repérer ces problèmes sans exposer les visiteurs.

A retenir :

• Inventaire précis des fichiers, versions PHP et tâches planifiées
• Sauvegardes distinctes des fichiers et de la base de données
• Validation complète du site avant la modification du DNS
• Ancien hébergement conservé pendant la période de vérification

Migration vers un VPS : repérer les pannes avant le transfert

Une fois les limites de l’ancien hébergement identifiées, l’inventaire technique permet d’éviter de reproduire ses dépendances à moitié. Selon le guide de migration de Mathieu Bernard, il faut notamment relever les versions logicielles, les tâches planifiées et les réglages particuliers.

Compatibilité PHP et configuration serveur

La compatibilité PHP mérite une vérification avant toute copie : une extension absente ou une version différente peut bloquer le site. Par exemple, une boutique utilisant une extension PHP non installée sur le VPS risque d’afficher une erreur dès son premier chargement.

Documentez aussi les règles personnalisées, les tâches cron, les services externes et les paramètres de messagerie. Selon la documentation PHP et celle de votre application, contrôlez les versions et modules effectivement requis plutôt que d’installer des composants au hasard.

Les symptômes orientent souvent le diagnostic, mais une même erreur peut avoir plusieurs causes. Le tableau distingue les vérifications initiales à effectuer avant d’intervenir sur les données.

Symptôme	Cause à vérifier	Contrôle utile
Page blanche ou erreur PHP	Version PHP ou extension manquante	Comparer les prérequis de l’application
Erreur de connexion au site	Identifiants ou nom de base erronés	Vérifier le fichier de configuration
Images inaccessibles	Chemins copiés ou permissions incorrectes	Comparer fichiers et droits de lecture
Courriels non distribués	Configuration SMTP ou DNS de messagerie	Tester le service et ses enregistrements

Un premier transfert de fichiers avec rsync peut ensuite être comparé à l’inventaire initial. Cette comparaison réduit le risque d’oublier un fichier de configuration, une image ou un contenu récemment modifié.

Vérifications techniques avant copie :

• Versions PHP et extensions exigées par le site
• Règles serveur, tâches cron et variables d’environnement
• Fichiers cachés, certificats et paramètres de messagerie
• Export récent des fichiers et de la base de données

Réparer les erreurs après le transfert des fichiers et de la base

Après l’inventaire, le transfert révèle les écarts entre les deux environnements. Une copie complète ne garantit pas que le serveur web puisse lire les fichiers ni que l’application retrouve sa base.

Permissions de fichiers et connexion à la base de données

Sur un serveur Linux, le compte utilisé par Nginx ou Apache doit pouvoir lire les fichiers nécessaires. Si les permissions de fichiers sont trop restrictives, les pages ou les médias échouent ; si elles sont trop larges, la sécurité se dégrade.

Vérifiez le propriétaire des fichiers et attribuez uniquement les droits nécessaires, plutôt que d’appliquer des permissions ouvertes à tout le monde. Pour la base de données, contrôlez séparément son import, le nom de la base, l’utilisateur autorisé et les identifiants indiqués dans la configuration du site.

Dépannage Nginx, PHP-FPM et certificat SSL

Selon le guide de Mathieu Bernard, la configuration Nginx doit être testée avant son rechargement. Une erreur de syntaxe dans un bloc serveur peut rendre le site inaccessible ; les journaux Nginx et PHP-FPM aident alors à isoler la panne.

Le certificat SSL doit correspondre aux noms de domaine réellement utilisés, avec et sans préfixe www si les deux sont actifs. Testez le site par une modification temporaire du fichier hosts, puis vérifiez les pages, la connexion, les images et les formulaires.

Contrôles fonctionnels sur le nouveau serveur :

• Pages principales et accès à l’administration
• Images, pièces jointes et liens internes
• Formulaires, paiements et services externes
• HTTPS, tâches planifiées et envoi de courriels

Service	Test avant bascule	Indice de réparation
Nginx	Valider la configuration du site	Corriger le bloc serveur signalé
PHP-FPM	Ouvrir les pages dynamiques	Vérifier le socket et les extensions
Base de données	Se connecter avec l’application	Revoir identifiants et privilèges
HTTPS	Charger le domaine sécurisé	Émettre un certificat adapté au domaine

Quand ces contrôles réussissent sur le VPS, la bascule DNS devient l’étape suivante. Elle ne doit pas interrompre les commandes ou les achats encore enregistrés sur l’ancien site.

Bascule DNS vers le VPS sans perdre les nouvelles données

Une fois le nouveau serveur validé, le changement de DNS dirige progressivement les visiteurs vers sa nouvelle adresse. Selon le guide de Mathieu Bernard, réduire le TTL à 300 secondes avant la bascule facilite l’actualisation des enregistrements.

Organiser le changement DNS et surveiller le certificat

Modifiez l’enregistrement A lorsque le site est prêt, puis vérifiez son accès depuis plusieurs réseaux. Les caches DNS ne se mettent pas tous à jour au même moment : gardez l’ancien hébergement actif et surveillez les erreurs pendant cette période.

Sur une boutique ou un site qui reçoit des formulaires, les visiteurs peuvent encore écrire sur l’ancienne plateforme pendant la propagation. Il faut décider à l’avance qui autorise la bascule et comment réconcilier commandes, comptes ou contenus créés des deux côtés.

Sauvegardes, suivi et retour arrière

Le maintien temporaire de l’ancien compte permet de récupérer un fichier oublié ou de comparer une donnée manquante. Définissez une procédure de retour arrière, mais évitez de rediriger le DNS sans savoir quelle base contient les écritures les plus récentes.

Un VPS implique aussi de gérer les mises à jour, la surveillance et les sauvegardes, auparavant prises en charge en partie par l’hébergeur. Prévoyez des copies régulières des fichiers et de la base, conservées hors du serveur, puis testez leur restauration.

Actions après le changement de DNS :

• Surveillance des pages, journaux et formulaires
• Comparaison des commandes et contenus récents
• Sauvegarde externe et essai de restauration
• Conservation de l’ancien hébergement le temps des vérifications

Une migration réussie se mesure au fonctionnement réel du site après la bascule, pas seulement à la copie des fichiers. Une configuration contrôlée, des sauvegardes restaurables et une décision claire sur les données limitent les conséquences d’une panne.

Source : Mathieu Bernard, « De l’hébergement mutualisé au VPS — guide de migration », 4 février 2026.