Pour changer le serveur d'une boutique PrestaShop sans perdre de commande, on prépare le nouveau serveur avec une version de PHP compatible, on y copie fichiers et base, on teste la boutique avant de toucher au DNS, puis on fait une dernière synchronisation de la base en mode maintenance juste avant la bascule. La coupure se limite à quelques minutes, annoncées et maîtrisées, au lieu d'une boutique cassée pendant des heures.
Ce guide suit la documentation officielle de PrestaShop (versions 1.6 à 9), consultée le 27 octobre 2026. Il couvre le cas le plus courant : même nom de domaine, nouvel hébergeur ou nouveau serveur.
Changer de serveur n'est pas changer de version
C'est la confusion qui casse le plus de boutiques. Un nouvel hébergeur propose souvent PHP 8 par défaut. Or chaque version de PrestaShop n'accepte qu'une plage précise de versions de PHP : une boutique 1.7 copiée telle quelle sur un serveur en PHP 8 affiche une page blanche ou une erreur 500. Voici les plages officielles :
| Version de PrestaShop | PHP accepté | PHP recommandé |
|---|---|---|
| 1.6.1.x | 5.2 à 7.1 | 7.1 |
| 1.7.0 à 1.7.3 | 5.4 à 7.1 | 7.1 |
| 1.7.4 | 5.6 à 7.1 | 7.1 |
| 1.7.5 et 1.7.6 | 5.6 à 7.2 | 7.2 |
| 1.7.7 | 7.1 à 7.3 | 7.3 |
| 1.7.8 | 7.1 à 7.4 | 7.4 |
| 8.0 à 8.2 | 7.2 à 8.1 | 8.1 |
| 9.0 | 8.1 à 8.4 | 8.4 |
| 9.1 | 8.1 à 8.5 | 8.5 |
Deux conséquences pratiques. D'abord, le nouveau serveur doit proposer la version de PHP de votre boutique, quitte à choisir une version plus ancienne dans son panneau. Ensuite, une boutique 1.6 ou 1.7 ne peut tourner que sur des versions de PHP qui ne reçoivent plus de correctifs de sécurité : le déménagement règle un problème d'hébergeur, pas ce risque-là. Pour passer à PHP 8, il faut migrer la boutique vers PrestaShop 9. Le détail par version est dans notre article sur PrestaShop et PHP 8.
Préparer le nouveau serveur
Avant de copier quoi que ce soit, vérifiez que le serveur d'arrivée remplit les conditions de PrestaShop. Pour PrestaShop 9, la documentation demande Apache 2.4 ou Nginx, MySQL 5.7 ou MariaDB 10.2 au minimum, un memory_limit d'au moins 512 Mo, allow_url_fopen activé et une liste d'extensions PHP : CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO et PDO MySQL, SimpleXML, Zip.
Le plus simple est l'outil officiel phppsinfo : un fichier PHP à déposer sur le serveur, qui compare la configuration aux exigences de PrestaShop. Supprimez-le une fois le contrôle fait, il affiche des informations sur votre serveur.
Relevez aussi ce que l'ancien serveur faisait sans que personne n'y pense :
- les tâches planifiées (cron) : flux de prix, relances de paniers, synchronisation de stock, sauvegardes ;
- les e-mails : PrestaShop envoie-t-il par la fonction mail du serveur ou par un SMTP ? Si c'est le serveur, son adresse IP doit être autorisée dans l'enregistrement SPF du domaine ;
- les listes d'adresses IP autorisées chez vos partenaires : transporteur, ERP, logiciel de caisse ou banque qui n'accepte que l'IP de l'ancien serveur ;
- les réglages PHP spécifiques (taille maximale d'envoi de fichier, durée d'exécution) que vos imports de catalogue utilisent.
Copier fichiers et base de données
La copie se fait en deux temps : une première copie complète, faite sans pression pendant que la boutique tourne, puis une resynchronisation de la base au moment de la bascule (voir plus bas).
- Fichiers : copiez tout le dossier de la boutique, images produits et modules compris, de préférence de serveur à serveur (
rsyncou SFTP) plutôt que par votre ordinateur. Conservez les droits d'écriture sur les dossiers que PrestaShop modifie (img,varoucache,upload,download,modules,themes). - Base de données : exportez-la avec
mysqldumpou l'outil de l'hébergeur, en UTF-8, puis importez-la dans une base créée sur le nouveau serveur. - Connexion à la base : sur PrestaShop 1.7, 8 et 9, les accès sont dans
app/config/parameters.php(sur 1.6 :config/settings.inc.php). Modifiez uniquement l'hôte, le nom de la base, l'utilisateur et le mot de passe. Gardez le reste du fichier tel quel : il contient aussi les clés propres à votre boutique, qu'une réinstallation remplacerait. - Cache : la documentation demande de vider le cache après toute modification de ce fichier, en supprimant le contenu de
var/cache/prodetvar/cache/dev(sur 1.6, les dossiers de cache Smarty).
Tester la boutique avant de changer le DNS
PrestaShop redirige vers le domaine enregistré dans sa base. Pour tester le nouveau serveur avec le vrai nom de domaine sans que vos clients y arrivent, modifiez le fichier hosts de votre ordinateur : il force votre seule machine à joindre la nouvelle adresse IP. Vous naviguez alors sur la nouvelle copie comme un client le fera après la bascule.
Le parcours à vérifier :
- page d'accueil, catégories, fiches produits avec leurs images et déclinaisons ;
- recherche, création de compte, connexion à un compte client existant ;
- panier, calcul des frais de port, paiement en mode test si votre module le permet ;
- e-mail de confirmation de commande bien reçu ;
- back-office : connexion, liste des commandes, modules, et page Paramètres avancés > Informations qui signale les fichiers modifiés ou les droits manquants.
Pensez au certificat HTTPS : il doit être prêt sur le nouveau serveur avant la bascule, sinon les visiteurs verront une alerte de sécurité. Certains hébergeurs ne peuvent le générer qu'une fois le DNS pointé : demandez-leur la marche à suivre à l'avance.
Basculer sans perdre de commande
Entre la première copie et la bascule, la boutique a continué de vendre. Si vous basculez sur l'ancienne copie de la base, les commandes et inscriptions des derniers jours disparaissent. La bascule se fait donc ainsi :
- Quelques jours avant, baissez la durée de vie (TTL) de l'enregistrement DNS du domaine, par exemple à quelques minutes. Les résolveurs gardent l'ancienne adresse pendant la durée du TTL : un TTL court rend la bascule rapide pour tout le monde.
- Le jour J, à une heure creuse, mettez l'ancienne boutique en maintenance (Paramètres de la boutique > Général > Maintenance), en ajoutant votre adresse IP pour garder l'accès.
- Coupez les connecteurs qui écrivent dans la base : la documentation précise que le Webservice reste actif en mode maintenance. Une synchronisation de stock continuerait donc d'écrire dans l'ancienne base.
- Réexportez la base de l'ancien serveur et réimportez-la sur le nouveau, avec les fichiers ajoutés depuis la première copie (nouvelles images, factures).
- Changez le DNS vers la nouvelle adresse IP, puis contrôlez depuis un autre réseau, un téléphone en 4G par exemple, que vous arrivez bien sur le nouveau serveur.
- Retirez la maintenance sur le nouveau serveur, réactivez les connecteurs et les tâches planifiées, et passez une commande réelle de contrôle.
Gardez l'ancien serveur, boutique en maintenance, pendant au moins une semaine. Si un problème apparaît, revenir en arrière ne demande qu'un changement de DNS. C'est aussi votre sauvegarde la plus récente : vérifiez qu'elle existe avant de résilier l'ancien contrat (notre méthode de sauvegarde PrestaShop s'applique dès le nouveau serveur).
Et si le nom de domaine change aussi ?
C'est un autre chantier. Il faut déclarer le nouveau domaine dans Paramètres de la boutique > Trafic et SEO (domaine de la boutique et domaine SSL), régénérer le fichier .htaccess, et surtout rediriger chaque ancienne URL vers la nouvelle en 301 pour ne pas perdre le référencement. Faites-le dans une seconde étape, une fois le changement de serveur validé : deux changements simultanés rendent le diagnostic impossible si quelque chose casse.
Les erreurs fréquentes après un changement de serveur
| Symptôme | Cause la plus probable | Vérification |
|---|---|---|
| Page blanche ou erreur 500 | Version de PHP hors de la plage de la boutique, extension manquante | Journal d'erreurs PHP, outil phppsinfo |
| « Link to database cannot be established » | Accès à la base erronés dans le fichier de configuration | Hôte, nom de base, utilisateur, mot de passe |
| Redirection vers l'ancien domaine ou boucle | Domaine enregistré en base différent, HTTPS forcé sans certificat | Trafic et SEO, certificat du nouveau serveur |
| Images manquantes, mise en page cassée | Fichiers incomplets, droits d'écriture, cache ancien | Dossier img, droits, vider le cache |
| Plus d'e-mails de commande | Envoi par le serveur non autorisé dans le SPF, SMTP non repris | Paramètres avancés > E-mail, envoi de test |
| Stock ou prix qui ne se mettent plus à jour | Tâches cron non recréées, IP du connecteur non autorisée | Crontab, journaux du connecteur |
Une erreur de mémoire pendant un import ou une génération d'images vient en général d'un memory_limit plus bas que sur l'ancien serveur : voir notre article sur la mémoire PHP insuffisante. Si un connecteur de stock ou de comptabilité ne répond plus, la clé Webservice et ses droits sont expliqués dans notre guide de l'API PrestaShop.
Faire faire le changement de serveur
Nous préparons le serveur, faisons la copie et les tests, et menons la bascule à l'heure qui vous dérange le moins, avec l'ancien serveur gardé en secours. Le changement de serveur se fait sur devis écrit : décrivez-nous votre boutique (version, hébergeur actuel et futur). Si la boutique est déjà cassée après un déménagement, voyez notre dépannage PrestaShop en urgence. Et pour qu'un serveur reste à jour et surveillé ensuite, il y a la maintenance PrestaShop.
Sources
- PrestaShop DevDocs : exigences système de PrestaShop 9 (consulté le 27/10/2026)
- PrestaShop DevDocs : exigences système de PrestaShop 8 (consulté le 27/10/2026)
- PrestaShop DevDocs : exigences système de PrestaShop 1.6 et 1.7 (consulté le 27/10/2026)
- PrestaShop DevDocs : fichiers de configuration (parameters.php) (consulté le 27/10/2026)
- PrestaShop 8, guide utilisateur : mode maintenance (consulté le 27/10/2026)
- RFC 1035 : durée de vie (TTL) des enregistrements DNS (consulté le 27/10/2026)
