Migration PrestaShop vers un nouveau serveur : résoudre les erreurs courantes

Introduction

Migrer un site PrestaShop vers un nouveau serveur est une opération délicate qui peut provoquer des erreurs en cascade si l'on ne respecte pas un ordre précis. Page blanche, back-office inaccessible, erreur 500 sur certaines pages… Ces symptômes sont quasi systématiques lors d'une migration mal préparée.

Dans cet article, je détaille la méthodologie complète pour diagnostiquer et corriger les problèmes post-migration, du plus simple au plus complexe.

Étape 1 : vérifier l'accès de base au back-office

Avant toute investigation avancée, il faut déterminer quel niveau d'accès fonctionne encore. Testez ces URLs dans l'ordre :

1. **Page de login du back-office** : `https://votre-site.com/admin-xxx/`
2. **Dashboard legacy** : `https://votre-site.com/admin-xxx/index.php?controller=AdminDashboard`
3. **Une page Symfony** (ex. Produits dans PS 1.7.7+) : `https://votre-site.com/admin-xxx/index.php/sell/catalog/products`

Interpréter les résultats

RésultatDiagnostic probable Aucun accès, page blanche ou 500Problème .htaccess ou permissions serveur Login OK, dashboard OK, pages Symfony KOCache Symfony corrompu ou incompatible Tout le BO KO sauf les controllers legacyProblème Symfony (cache, routes, configuration PHP) Login OK mais menu videTable `ps_tab` vide ou corrompue dans la base de données

Cette distinction entre pages legacy (anciens controllers PHP classiques) et pages Symfony (introduites progressivement depuis PS 1.7.4) est fondamentale. Si les pages legacy fonctionnent mais pas les pages Symfony, le problème vient du framework Symfony embarqué dans PrestaShop, et non de PrestaShop lui-même.

Étape 2 : le fichier .htaccess

Le .htaccess est souvent la première cause de dysfonctionnement après migration. Les règles de réécriture d'URL contiennent des chemins qui peuvent ne plus correspondre au nouveau serveur.

Solution rapide

Renommez le .htaccess à la racine pour le désactiver temporairement :

mv .htaccess .htaccess.bak

Si le site redevient accessible, le problème est confirmé. Régénérez alors un .htaccess propre :

1. Connectez-vous au back-office
2. Allez dans **Paramètres de la boutique → Trafic et SEO**
3. Désactivez l'option **URL simplifiée** puis enregistrez
4. Réactivez-la et enregistrez à nouveau

PrestaShop regénère automatiquement le .htaccess avec les bons chemins.

Pour PrestaShop 8.x

Sur PS 8.x avec Apache, vérifiez également que le module mod_rewrite est bien activé sur le nouveau serveur :

apache2ctl -M | grep rewrite
# Doit afficher : rewrite_module (shared)

# Si absent :
sudo a2enmod rewrite
sudo systemctl restart apache2

Si vous utilisez Nginx (de plus en plus courant en 2025-2026), le .htaccess est ignoré. Il faut transposer les règles dans la configuration Nginx. PrestaShop fournit un fichier d'exemple dans docs/nginx.conf.dist.

Étape 3 : vérifier la base de données

Après migration, certaines tables peuvent être incomplètes ou corrompues. Un point de contrôle essentiel : la table ps_tab.

Cette table contient la structure complète du menu du back-office. Si elle est vide ou partiellement importée, le back-office affichera un menu vide ou des erreurs sur chaque page.

SELECT COUNT(*) FROM ps_tab;
-- PrestaShop 1.7 : environ 170-180 lignes attendues
-- PrestaShop 8.x : environ 180-200 lignes attendues

Si le résultat est 0 ou anormalement bas, votre import SQL est incomplet. Réimportez la base en vérifiant :

• L'encodage est bien **utf8mb4** (et non latin1)
• Le fichier SQL n'a pas été tronqué lors du transfert
• La taille maximale d'import de phpMyAdmin n'a pas coupé le fichier (utilisez la ligne de commande pour les bases volumineuses) :

mysql -u utilisateur -p nom_base < dump_complet.sql

Étape 4 : permissions et propriétaire des fichiers

C'est le problème le plus fréquent et le plus sous-estimé lors d'une migration. Les fichiers transférés par FTP, rsync ou tar héritent souvent du mauvais propriétaire.

Vérifier le propriétaire actuel

ls -la /var/www/prestashop/
# Le propriétaire doit correspondre à l'utilisateur du serveur web

Corriger les permissions

Pour un serveur Apache (utilisateur www-data sous Debian/Ubuntu) :

# Propriétaire : utilisateur du serveur web
sudo chown -R www-data:www-data /var/www/prestashop/

# Permissions recommandées
sudo find /var/www/prestashop/ -type d -exec chmod 755 {} \;
sudo find /var/www/prestashop/ -type f -exec chmod 644 {} \;

# Répertoires nécessitant l'écriture
sudo chmod -R 775 /var/www/prestashop/var/
sudo chmod -R 775 /var/www/prestashop/img/
sudo chmod -R 775 /var/www/prestashop/upload/
sudo chmod -R 775 /var/www/prestashop/download/
sudo chmod -R 775 /var/www/prestashop/config/
sudo chmod -R 775 /var/www/prestashop/cache/
sudo chmod -R 775 /var/www/prestashop/themes/

Astuce de diagnostic : en cas de doute, passez temporairement tout en 777 (chmod -R 777 /var/www/prestashop/) pour confirmer que le problème vient bien des permissions. Ne laissez jamais 777 en production — c'est une faille de sécurité majeure. Revenez aux permissions correctes dès que le diagnostic est confirmé.

Pour PHP-FPM (courant avec Nginx), l'utilisateur peut être différent. Vérifiez dans votre pool de configuration :

grep -E '^(user|group)' /etc/php/8.2/fpm/pool.d/www.conf

Étape 5 : purger le cache Symfony

Le cache Symfony est la cause numéro un des pages Symfony inaccessibles après migration. Le cache contient des chemins absolus compilés qui pointent encore vers l'ancien serveur.

Méthode recommandée : ligne de commande

# En production
php ./bin/console cache:clear --env=prod

# Si vous êtes en mode debug
php ./bin/console cache:clear --env=dev

Si la commande échoue

Il arrive que le cache soit tellement corrompu que même la commande cache:clear plante. Dans ce cas, supprimez manuellement les répertoires de cache :

rm -rf var/cache/prod/
rm -rf var/cache/dev/

Puis rechargez une page du back-office : PrestaShop reconstruira automatiquement le cache.

Pour PrestaShop 8.x

PS 8.x utilise Symfony 4.4. La commande reste identique, mais assurez-vous d'utiliser la bonne version de PHP :

# Vérifier la version PHP CLI
php -v

# Si plusieurs versions coexistent, spécifiez le chemin
/usr/bin/php8.2 ./bin/console cache:clear --env=prod

PS 8.x exige PHP 8.1 minimum. Une migration depuis un serveur en PHP 7.4 nécessite de recompiler entièrement le cache avec la bonne version.

Étape 6 : mettre à jour les URLs en base de données

Étape souvent oubliée : la table ps_configuration contient les URLs du site en dur.

SELECT name, value FROM ps_configuration 
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL', 'PS_SSL_ENABLED');

Mettez à jour si nécessaire :

UPDATE ps_configuration SET value = 'nouveau-domaine.com' 
WHERE name = 'PS_SHOP_DOMAIN';

UPDATE ps_configuration SET value = 'nouveau-domaine.com' 
WHERE name = 'PS_SHOP_DOMAIN_SSL';

UPDATE ps_configuration SET value = '1' 
WHERE name = 'PS_SSL_ENABLED';

Vérifiez aussi la table ps_shop_url :

SELECT * FROM ps_shop_url;
-- Mettez à jour domain et domain_ssl si nécessaire

Checklist complète de migration

Voici l'ordre optimal pour migrer PrestaShop sans accroc :

1. **Transférer les fichiers** (rsync ou tar, éviter le FTP pour les gros volumes)
2. **Importer la base de données** (en ligne de commande, pas phpMyAdmin)
3. **Mettre à jour `PS_SHOP_DOMAIN`** et `PS_SHOP_DOMAIN_SSL` en base
4. **Corriger le propriétaire** des fichiers (`chown www-data:www-data`)
5. **Appliquer les permissions** (755 dossiers, 644 fichiers, 775 pour var/img/upload)
6. **Supprimer le cache** (`rm -rf var/cache/prod/ var/cache/dev/`)
7. **Régénérer le .htaccess** via le back-office ou renommer l'ancien
8. **Vérifier la version PHP** et les extensions requises
9. **Tester le front-office ET le back-office** (pages legacy et Symfony)
10. **Activer le mode production** (`define('_PS_MODE_DEV_', false);` dans `config/defines.inc.php`)

Conclusion

La migration d'un site PrestaShop se résume à trois piliers : permissions correctes, cache purgé, et URLs à jour en base de données. En respectant la checklist ci-dessus dans l'ordre, vous éviterez 95 % des problèmes post-migration. En cas de doute, procédez toujours par élimination : un diagnostic structuré vaut mieux que des modifications à l'aveugle.