# Boutique PrestaShop en erreur 500 ou page blanche

> Une page blanche ou une erreur 500 sur PrestaShop ne dit rien en soi : c’est un symptôme, pas un diagnostic. Il faut lire les vrais messages d’erreur pour savoir si le problème vient d’un module, d’un override, de la base ou du serveur.

- Source canonique : [https://allaux.fr/prestashop/erreur-500](https://allaux.fr/prestashop/erreur-500)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Passez _PS_MODE_DEV_ à true dans config/defines.inc.php : la page blanche laisse place au message d’erreur réel, avec le fichier et la ligne fautive. Lisez aussi var/logs/ (1.7, 8, 9) et le journal PHP de l’hébergeur. Si l’erreur est apparue après une mise à jour, videz var/cache et renommez le dossier override/ pour écarter une surcharge devenue caduque.

## Les situations que je traite

- Écran totalement blanc au chargement du front ou du back-office
- Erreur 500 apparue juste après une mise à jour de module ou de PrestaShop
- Erreur 500 uniquement sur certaines pages (fiche produit, panier, commande)
- Message « The file config/settings.inc.php is missing » après un transfert d’hébergeur
- Erreur 500 déclenchée après une modification manuelle d’un fichier override
- Site fonctionnel en local mais en erreur une fois déployé sur le serveur de production

## Comment je procède

1. **Activation du mode debug** — Je passe _PS_MODE_DEV_ à true dans config/defines.inc.php pour faire apparaître le message d’erreur réel de PHP ou de Smarty à la place de la page blanche générique.
2. **Lecture des logs** — Je consulte les logs PHP du serveur (souvent dans error_log ou les logs Apache/Nginx) et, sur PrestaShop 1.7/8, le dossier var/logs/ qui contient les erreurs Symfony.
3. **Isolation du fautif** — Je désactive les modules un par un via la table ps_module ou le FTP, et je vérifie le contenu du dossier override/ pour repérer un fichier qui entre en conflit avec le core.
4. **Vérification du serveur** — Je contrôle la version de PHP, les extensions actives, le memory_limit et les droits d’écriture sur var/cache, var/logs et config, des causes fréquentes après un changement d’hébergement.
5. **Correction et vidage du cache** — Une fois la cause identifiée, je corrige le fichier ou reconfigure le serveur, puis je vide var/cache/prod (ou cache/smarty en 1.6) avant de repasser le mode debug sur false.

## Page blanche PrestaShop : l’endroit où elle apparaît dit d’où elle vient

Avant même de lire les journaux, notez où la page blanche ou l’erreur 500 se produit. Cela réduit le champ de recherche de moitié.

Front et back-office blancs en même temps : la panne survient avant que PrestaShop ne distingue les deux. Regardez la configuration : version de PHP changée par l’hébergeur, app/config/parameters.php (1.7, 8, 9) ou config/settings.inc.php (1.6) incomplet, .htaccess invalide, droits d’écriture manquants.

Seulement le back-office : souvent un cache resté d’une version précédente dans var/cache/, ou un module qui s’accroche à un hook de l’administration.

Seulement le front, ou une seule page : un module greffé sur un hook d’affichage, un fichier du thème, ou une donnée propre à cette page.

Uniquement au passage de commande : le module de paiement ou de transport, qui n’est appelé qu’à cette étape.

Si la page reste blanche alors que _PS_MODE_DEV_ est actif, l’erreur se produit avant que PrestaShop ne soit chargé : c’est le journal d’erreurs PHP du serveur qu’il faut lire, pas var/logs.

## Les messages d’erreur les plus fréquents, et ce qu’ils désignent

Cannot declare class … ou Cannot redeclare class … : un override en double, ou resté en place après la désinstallation d’un module. Supprimer l’index des classes — var/cache/prod/class_index.php en 1.7 et au-delà, cache/class_index.php en 1.6 — oblige PrestaShop à le reconstruire.

Allowed memory size of … bytes exhausted : la limite mémoire de PHP est atteinte, typiquement pendant un import, une régénération de miniatures ou une indexation.

Call to undefined function each() ou create_function() : un module écrit pour une ancienne version de PHP. Ces fonctions ont disparu en PHP 8 ; voir passer PrestaShop à PHP 8.

SQLSTATE[42S02]: Base table or view not found : une table manque, après une migration, un import SQL interrompu ou un module mal désinstallé.

Link to database cannot be established : identifiants de base erronés dans le fichier de configuration, ou serveur MySQL indisponible. Voir erreur de connexion à la base de données.

Permission denied sur var/cache ou var/logs : droits d’écriture perdus, fréquent après un transfert FTP ou un changement d’hébergeur.

## Les causes les plus fréquentes

Sur PrestaShop, une erreur 500 vient rarement du hasard. Les cas que je rencontre le plus souvent :

Un fichier override mal écrit ou dupliqué entre override/ et un module, provoquant une redéclaration de classe.

Une incompatibilité de version PHP après une montée de version chez l’hébergeur (un module utilisant une fonction supprimée en PHP 8, par exemple).

Des droits d’écriture manquants sur var/cache, var/logs ou config après un transfert de fichiers en FTP.

Un fichier .htaccess corrompu ou une règle de réécriture invalide, qui casse le routage avant même que PrestaShop ne s’exécute.

Une table manquante ou corrompue en base de données suite à une migration ou un import SQL interrompu.

Sur 1.6, la page blanche cache souvent une erreur Smarty dans le cache de compilation (cache/smarty/compile) qui n’a pas été vidé après une mise à jour de thème.

## Vos commandes ne sont pas perdues

> Une erreur 500 bloque l’affichage, elle n’efface pas la base de données. Les commandes déjà enregistrées restent intactes ; le risque réel est de perdre les ventes pendant l’indisponibilité, pas l’historique.

## config/defines.inc.php

```
define('_PS_MODE_DEV_', true);
```

## Pages liées

- **Activer le mode debug PrestaShop** — La marche à suivre exacte selon la version, et comment le désactiver ensuite. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop))
- **Lire les journaux d’erreurs PrestaShop** — Où se trouvent les journaux et comment y repérer la ligne qui compte. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop))
- **Fiche produit impossible à enregistrer** — Quand l’erreur n’apparaît qu’au moment de sauvegarder un produit dans le back-office. ([/prestashop/problemes/fiche-produit-enregistrement-echoue](/prestashop/problemes/fiche-produit-enregistrement-echoue))
- **Module qui refuse de s’installer** — Erreur à l’installation, module qui disparaît : les causes côté fichiers et côté base. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation))
- **Moyen de paiement disparu après une mise à jour** — Quand la panne se limite au tunnel de commande. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj))
- **Erreurs à répétition : réparer ou refaire ?** — Sur une version ancienne, quand chaque correction en appelle une autre. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## FAQ

### Est-ce que je risque de perdre mes commandes ou mes clients ?

Non. L’erreur 500 empêche l’affichage des pages mais la base de données reste intacte : commandes déjà passées, comptes clients et catalogue ne sont pas touchés. C’est la couche d’exécution PHP qui s’arrête, pas le stockage.

### Quels accès dois-je vous fournir ?

Un accès FTP ou SSH, un accès à la base de données (phpMyAdmin ou identifiants directs) et, si possible, un accès à l’espace client de l’hébergeur pour vérifier la configuration PHP.

### Combien de temps prend le diagnostic ?

Dans la majorité des cas, l’activation du mode debug et la lecture des logs suffisent à identifier la cause dès la première session de travail. C’est le type de blocage qui se règle dans la journée quand l’accès serveur est disponible ; la correction elle-même dépend de ce qui est cassé.

### L’erreur peut-elle revenir après correction ?

Si elle vient d’un module tiers instable, oui, à la prochaine mise à jour automatique. Je peux verrouiller les mises à jour de modules sensibles pour éviter que ça se reproduise.

### Faut-il repartir d’une sauvegarde complète ?

Rarement. Restaurer une sauvegarde fait perdre les commandes et modifications passées depuis cette date. Je corrige en général directement le fichier ou la configuration en cause.

### Pourquoi ma boutique PrestaShop affiche-t-elle une page blanche sans aucun message ?

Parce que PrestaShop masque les erreurs en production : tant que _PS_MODE_DEV_ vaut false, le détail n’est pas affiché. Passez-le à true le temps d’un essai. Si la page reste blanche malgré cela, l’erreur se produit avant le chargement de PrestaShop — version de PHP, .htaccess, fichier de configuration — et c’est le journal d’erreurs du serveur qui la contient.