PrestaShop : page blanche ou erreur 500, que faire ?La boutique ou le back-office ne s'affiche plus : la marche à suivre.

1. Faites une copie des fichiers et de la base, et notez ce qui a changé.
2. Activez le mode debug (Performances, ou _PS_MODE_DEV_ dans config/defines.inc.php).
3. Lisez les journaux du dossier var/logs et de l'hébergeur.
4. Videz le cache, depuis le back-office ou en vidant var/cache/prod et var/cache/dev.
5. Écartez le module ou la surcharge en cause, puis videz à nouveau le cache.
6. Remettez une version de PHP acceptée : 8.1 au plus pour PrestaShop 8.
7. Coupez le mode debug et passez une commande test.

Dans ce guide

• Les causes, de la plus fréquente à la plus rare
• Les versions de PHP acceptées par PrestaShop
• La marche à suivre, dans l'ordre
• Ce que nous ferions à votre place
• Questions fréquentes

1. Un module installé ou mis à jour, incompatible avec votre version de PrestaShop, de PHP ou avec un autre module. Ou la surcharge (override) qu'il a déposée dans le dossier override et qui ne correspond plus au code de PrestaShop.
2. Le cache : après une mise à jour, l'ajout d'un module ou un transfert, le dossier var/cache garde d'anciens fichiers qui ne correspondent plus au reste de la boutique.
3. La version de PHP : PrestaShop 8 n'accepte pas PHP 8.2 et plus. Si l'hébergeur fait monter la version de PHP, la boutique s'arrête. Le tableau plus bas donne les versions acceptées.
4. La mémoire de PHP épuisée : PrestaShop 8 demande au moins 256 Mo, PrestaShop 9 au moins 512 Mo.
5. Le thème : une mise à jour, ou un fichier de gabarit (.tpl) modifié à la main avec une erreur.
6. Une mise à jour de PrestaShop ratée, ou des fichiers incomplets après un transfert ; des droits d'écriture refusés sur le dossier var.
7. Plus rarement, une intrusion : les boutiques sont visées par des failles de modules, parfois pour glisser un faux formulaire de paiement. Un fichier inconnu dans le journal, un module que vous n'avez pas installé : c'est une intrusion repérée, voyez notre page site piraté.

Le problème : PHP 8.1, la version la plus récente qu'accepte PrestaShop 8, ne reçoit plus de correctif de sécurité depuis le 31 décembre 2025. Les hébergeurs poussent vers PHP 8.2 et plus, et une boutique en PrestaShop 8 qui y passe s'arrête. Revenir à PHP 8.1 la remet en ligne, mais ce n'est qu'un sursis : la vraie réponse est la mise à jour vers PrestaShop 9, préparée sur une copie, modules compris.

1. Une copie, et ce qui a changé

Sauvegardez les fichiers et la base depuis l'espace de l'hébergeur avant de toucher à quoi que ce soit. Notez ce qui a changé juste avant : un module installé ou mis à jour, une mise à jour de PrestaShop, un changement de version de PHP, une modification du thème.

2. Faites parler la boutique : le mode debug

En production, PrestaShop cache les erreurs à vos clients : d'où la page blanche. Si le back-office répond, ouvrez Paramètres avancés, puis Performances, et passez « Mode debug » sur Oui. Sinon, par FTP ou avec le gestionnaire de fichiers de l'hébergeur, ouvrez le fichier config/defines.inc.php et remplacez, dans la ligne qui définit _PS_MODE_DEV_, false par true :

define('_PS_MODE_DEV_', true);

Rechargez la page blanche : l'erreur s'affiche, avec le fichier en cause. Un chemin qui passe par modules/un-dossier désigne un module, par override un fichier de surcharge, par themes le thème. Le mode debug affiche ces erreurs à tous les visiteurs : laissez-le actif le moins longtemps possible.

3. Lisez les journaux

Les erreurs sont aussi écrites dans le dossier var/logs de la boutique, dans des fichiers dont le nom commence par prod (ou dev quand le mode debug est actif) ; ouvrez le plus récent et lisez la fin. Le journal des erreurs de l'hébergeur (sous cPanel, Métriques, puis Erreurs) et la page des journaux (Logs) des paramètres avancés du back-office complètent le tableau.

4. Videz le cache

Depuis le back-office : Paramètres avancés, puis Performances, bouton « Vider le cache » en haut à droite. Sans back-office : par FTP, supprimez le contenu des dossiers var/cache/prod et var/cache/dev (les dossiers eux-mêmes peuvent rester). PrestaShop les reconstruit à la visite suivante, qui sera un peu plus lente. C'est sans risque pour vos produits, vos clients et vos commandes, qui sont dans la base de données.

5. Écartez le module fautif

Si le back-office répond : Modules, puis Gestionnaire de modules, et désactivez le module désigné. Pour tester sans chercher, la page Performances propose aussi « Désactiver les modules non natifs de PrestaShop » et « Désactiver toutes les surcharges » : si la boutique revient avec ces options, le coupable est un module ajouté ou une surcharge. Sans back-office : renommez le dossier du module dans modules (par exemple en ajoutant .off), puis videz var/cache. Une surcharge se trouve dans override/classes ou override/controllers : mettez le fichier de côté, puis videz le cache.

6. Remettez une version de PHP acceptée

Dans l'espace de l'hébergeur (sous cPanel : « Sélectionner une version de PHP » ou « MultiPHP Manager »), choisissez une version acceptée par votre PrestaShop, d'après le tableau ci-dessus : 8.1 pour PrestaShop 8. La version de votre boutique est indiquée dans Paramètres avancés, puis Informations. Ne changez jamais de version de PHP sans vérifier aussi vos modules.

7. Donnez à PHP ce que PrestaShop demande

Dans les réglages de PHP de l'espace de l'hébergeur : memory_limit à 256M au moins pour PrestaShop 8, 512M pour PrestaShop 9, et allow_url_fopen sur On, que PrestaShop exige pour joindre les services de paiement. Le dossier var, où PrestaShop écrit son cache et ses journaux, doit rester accessible en écriture.

8. Après une mise à jour ratée

Si l'erreur suit une mise à jour de PrestaShop, revenez à la copie faite avant, plutôt que de réparer fichier par fichier une boutique à moitié mise à jour. Si le module de mise à niveau a fait sa propre sauvegarde, il permet de revenir en arrière. Puis préparez la mise à jour sur une copie de la boutique, avec la liste des modules à vérifier.

9. Une fois la boutique revenue

Repassez le mode debug sur Non (ou _PS_MODE_DEV_ sur false), videz le cache une dernière fois, puis passez une commande test : panier, livraison, paiement, e-mail de confirmation. Une boutique qui s'affiche n'est pas forcément une boutique qui vend.

• Erreur 500 WordPress : « Internal Server Error » : le fichier .htaccess, une extension, la version de PHP ou la mémoire.
• Erreur de connexion à la base de données : WordPress ne joint plus la base où sont rangés vos contenus : identifiants, serveur, tables.
• Certificat SSL expiré ou invalide : « Votre connexion n'est pas privée », NET::ERR_CERT_DATE_INVALID et les autres alertes du navigateur.
• Erreurs Cloudflare 520, 521 et 522 : Cloudflare répond, mais le serveur qui héberge le site, non.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 20 octobre 2026. Manipulations vérifiées le 20 octobre 2026 pour PrestaShop 8 et 9 ; les chemins valent aussi pour PrestaShop 1.7.

• PrestaShop, configuration requise de PrestaShop 8 (PHP 7.2 à 8.1, memory_limit 256M, allow_url_fopen).
• PrestaShop, configuration requise de PrestaShop 9 (PHP 8.1 à 8.5 selon la version, memory_limit 512M).
• PrestaShop, configurer PrestaShop (mode debug, _PS_MODE_DEV_, config/defines.inc.php).
• PHP, versions encore suivies, consulté le 20 octobre 2026.

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.