J'ai changé d'hébergeur et maintenant mon site ne fonctionne plus — comment le réparer ?

Vous avez déplacé votre site vers un nouvel hébergeur, suivi le tutoriel, et vous voici face à une page blanche, un message d'erreur ou l'ancien site qui refuse de disparaître. C'est frustrant, mais voici la bonne nouvelle : presque tous les problèmes d'après-migration entrent dans trois catégories claires — et chacune a une cause logique, pas un mauvais sort.

Dans cet article, je vous montre comment diagnostiquer rapidement ce qui a cassé : la propagation DNS (le site paraît ancien ou oscille entre deux versions), les fichiers manquants (page blanche ou erreurs 404/500) et la connexion à la base de données (le classique « Error establishing a database connection »). Pas besoin d'être développeur — juste de la patience et le bon ordre de vérifications.

D'abord, respirez : ne supprimez rien sur l'ancien hébergeur

L'erreur la plus coûteuse après une migration, c'est de résilier l'ancien compte le jour même. Tant que l'ancien hébergeur est actif, vous avez une copie fonctionnelle de votre site et un filet de sécurité.

Avant toute réparation, faites ceci :

• Gardez l'ancien compte actif au moins une semaine après la migration.
• Téléchargez une copie complète en local : les fichiers (via FTP ou gestionnaire de fichiers) et la base de données (export SQL depuis phpMyAdmin).
• Notez exactement ce que vous avez changé et quand — cela aide à revenir en arrière si ça dérape.

Une migration n'est pas irréversible tant que vous détenez une sauvegarde. La panique vous fait supprimer précisément ce dont vous aurez besoin plus tard.

Le site paraît ancien ou clignote ? C'est la propagation DNS

Si vous voyez tantôt le nouveau site, tantôt l'ancien, ou qu'un collègue voit autre chose que vous, c'est presque à coup sûr le DNS qui se propage encore. En clair, internet se souvient encore de l'ancien emplacement de votre site.

Ce qu'il faut vérifier, dans l'ordre :

• Les serveurs de noms ou l'enregistrement A dans votre compte de domaine pointent-ils vraiment vers le nouvel hébergeur ? C'est là que la plupart des gens se trompent.
• Utilisez un outil « DNS checker » pour voir si la nouvelle adresse IP s'est propagée dans le monde.
• Videz le cache DNS local et essayez depuis les données mobiles ou une fenêtre de navigation privée.

La propagation peut prendre de quelques minutes à un ou deux jours, selon la valeur TTL. Si l'IP est correcte partout, il n'y a plus rien à réparer — il faut juste attendre.

Page blanche ou erreur 404/500 ? Des fichiers manquent ou sont mal configurés

Si le DNS est correct mais que la page est vide ou renvoie une erreur, le problème vient des fichiers copiés. Les transferts FTP s'interrompent souvent et laissent les choses à moitié faites.

Vérifiez un par un :

• Les fichiers sont dans le bon dossier (en général public_html ou www), pas dans un sous-dossier.
• Les fichiers cachés comme .htaccess ont été copiés — leur absence provoque souvent une erreur 500.
• Le nombre de fichiers sur le nouvel hébergeur correspond à celui de l'ancien.
• Les permissions sont standard : généralement 644 pour les fichiers et 755 pour les dossiers.

Si vous ne voyez que du texte brut sans design, en général les fichiers du thème n'ont pas été chargés ou les chemins CSS sont erronés. Rechargez tout le dossier concerné, pas seulement quelques fichiers.

« Error establishing a database connection » ? C'est l'erreur la plus claire

Ironie du sort, ce message est amical : il vous dit exactement où regarder. Le site trouve ses fichiers mais ne parvient pas à parler à la base de données.

Sur un site WordPress, ouvrez le fichier wp-config.php et comparez-le aux informations de votre nouvelle base de données :

• Le nom de la base (DB_NAME) — sur le nouvel hébergeur, il porte presque toujours un autre nom.
• L'utilisateur (DB_USER) et le mot de passe (DB_PASSWORD) — à recréer sur le nouveau serveur.
• L'hôte (DB_HOST) — parfois ce n'est pas « localhost » mais une adresse fournie par le nouvel hébergeur.

Assurez-vous ensuite d'avoir bien importé la base exportée (le fichier .sql) dans le nouveau phpMyAdmin et que l'utilisateur y a les droits. La plupart de ces erreurs viennent d'un mot de passe mal recopié ou d'une base importée à moitié.

Quand il vaut la peine de demander de l'aide — et comment nous travaillons

Si vous avez vérifié le DNS, les fichiers et la base de données et que rien ne fonctionne, ou si vous ne voulez tout simplement pas trafiquer wp-config et phpMyAdmin sur le site d'où viennent vos clients, il est tout à fait raisonnable de confier le problème.

Chez MPO Web Studio, nous travaillons entièrement à distance — peu importe que vous soyez à Cluj, à Bucarest ou dans un village de Transylvanie. Vous nous donnez l'accès à l'hébergement, nous examinons les trois suspects ci-dessus, et nous vous disons honnêtement ce qui s'est passé et combien ça coûte, sans surprise.

Et si vous envisagez de toute façon de remplacer entièrement le site, nous pouvons construire une démo prête à l'emploi avant tout paiement — vous voyez le résultat, puis vous décidez. Envoyez-nous un message WhatsApp avec l'adresse de votre site et l'erreur que vous voyez, et nous vous dirons vite s'il s'agit d'une réparation de quelques minutes ou de quelque chose de plus sérieux.