# Mon site est cassé depuis le changement d’hébergeur

> Les fichiers sont là, la base est là, et pourtant une fonction refuse de marcher. Dans presque tous les cas que je traite, rien n’a été perdu pendant la copie : le nouveau serveur n’est simplement pas configuré comme l’ancien, et le site s’appuyait sur des détails de l’ancien environnement que personne n’avait documentés.

- Source canonique : [https://allaux.fr/problemes/panne-apres-changement-d-hebergeur](https://allaux.fr/problemes/panne-apres-changement-d-hebergeur)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Mettez d’abord l’adresse du site à jour en base : table ps_shop_url sur PrestaShop, wp_options.siteurl et home sur WordPress. Une adresse restée sur l’ancien serveur fausse tout le reste du diagnostic. Comparez ensuite les extensions PHP chargées entre les deux hébergeurs, intl, gd, zip et curl étant les plus souvent absentes, et vérifiez que .htaccess est bien lu, sinon aucune réécriture d’URL ne fonctionne.

## Les six différences qui cassent un site

1. **La version de PHP** — C’est la première à vérifier. Un serveur récent propose une version plus récente par défaut, et un module ancien qui tolérait la précédente s’arrête net. Le symptôme est une erreur fatale, pas un avertissement.
2. **Les extensions PHP absentes** — Traitement d’images, archives, chiffrement, connexion à un service externe : chacune dépend d’une extension. Si elle n’est pas installée, la fonction correspondante échoue seule, le reste du site marche, et le diagnostic part dans la mauvaise direction.
3. **La réécriture d’adresses** — Si le module de réécriture n’est pas actif, l’accueil s’affiche et toutes les autres pages renvoient une page introuvable. C’est le symptôme le plus reconnaissable de la liste.
4. **Les droits sur les fichiers** — Une copie faite avec un autre compte laisse des répertoires que le serveur web ne peut plus écrire : envoi d’images impossible, cache non régénéré, journaux vides.
5. **L’encodage de la base** — Une base recréée avec un jeu de caractères différent transforme les accents en symboles dans tout le catalogue, sans qu’aucune erreur ne soit levée.
6. **Les tâches planifiées et l’envoi de courrier** — Ni les tâches automatiques ni la configuration d’envoi ne se copient avec les fichiers. Elles doivent être recréées, et leur absence ne se voit qu’au bout de plusieurs jours.

## Ce qui se voit tout de suite et ce qui se voit plus tard

Les pannes visibles immédiatement — page blanche, adresses en erreur, accents cassés — sont les moins coûteuses : elles sont traitées le jour même. Les pannes silencieuses sont plus ennuyeuses. Une tâche planifiée non recréée ne se manifeste que le jour où le flux produit n’est plus à jour. Un envoi de courrier non configuré ne se remarque que lorsqu’un client signale qu’il n’a pas reçu sa confirmation.

C’est pourquoi je considère qu’un changement d’hébergeur n’est pas terminé le jour de la bascule, mais après une semaine de vérifications : commande de test complète, envoi de courrier vérifié, tâches planifiées exécutées au moins une fois, sauvegardes reconfigurées et vérifiées.

## Gardez l’ancien serveur accessible quelques semaines

> Tant que l’ancien hébergement reste en place, une comparaison est possible : version de PHP, extensions actives, réglages du serveur, contenu d’un répertoire. Résilier immédiatement pour économiser un mois d’abonnement supprime la seule référence disponible.

## Continuer sur la bonne page

- **Changer d’hébergeur sur PrestaShop** — La procédure complète et les réglages spécifiques à PrestaShop. ([/prestashop/migration/changer-d-hebergeur](/prestashop/migration/changer-d-hebergeur))
- **Changer d’hébergeur sans interruption sur WordPress** — La bascule côté WordPress, avec la synchronisation finale de la base. ([/wordpress-woocommerce/migration/hebergeur-sans-interruption](/wordpress-woocommerce/migration/hebergeur-sans-interruption))
- **Droits de fichiers sur un serveur e-commerce** — Si l’envoi d’images ou l’écriture du cache ne fonctionne plus. ([/guides/droits-fichiers-serveur-ecommerce](/guides/droits-fichiers-serveur-ecommerce))
- **Passer à PHP 8** — Si la nouvelle version de PHP est à l’origine des erreurs. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))

## FAQ

### Comment savoir quelle version de PHP tournait avant ?

Si l’ancien hébergement est encore actif, l’information est dans son panneau d’administration. Sinon, les journaux d’erreurs du site en gardent souvent la trace, tout comme les fichiers de configuration du CMS.

### Toutes les pages sauf l’accueil renvoient une erreur, que faire ?

C’est la signature d’une réécriture d’adresses inactive. Selon le serveur, il faut activer le module correspondant ou reporter les règles de réécriture dans la configuration du serveur.

### Mes accents sont devenus des symboles, est-ce récupérable ?

Oui si la base d’origine est encore disponible : on la réimporte avec le bon jeu de caractères. Si la conversion a déjà été enregistrée par-dessus, la reprise devient beaucoup plus lourde.

### Faut-il tout recopier depuis le début ?

Rarement. Une fois la différence d’environnement identifiée, la correction porte sur un réglage précis. Tout recopier reproduit souvent la même situation.

### Combien de temps faut-il prévoir pour une migration propre ?

Le transfert lui-même est court. C’est la préparation et la vérification qui prennent du temps, et je préfère annoncer une fenêtre de vérification plutôt qu’un délai de bascule seul.