L’erreur 500 est la plus frustrante des pannes : le serveur vous dit qu’il a échoué, sans dire pourquoi. Sur PrestaShop, elle survient le plus souvent après un changement — une mise à jour de module, un changement de version de PHP, une restauration incomplète — et parfois sans que personne n’ait rien touché, quand une tâche planifiée a rempli un disque ou qu’un hébergeur a modifié une limite.
La bonne nouvelle : il y a toujours un message d’erreur réel derrière ce 500. Il est simplement caché. Tout l’enjeu est d’aller le lire, parce qu’une fois qu’on l’a, la correction prend souvent quelques minutes.
Ce qui suit est la méthode que j’applique, dans cet ordre, quand j’interviens sur une boutique bloquée.
Réponse rapide
Une erreur 500 signifie qu’une erreur PHP fatale s’est produite sans être affichée. Pour la voir : activez l’affichage des erreurs dans config/defines.inc.php (_PS_MODE_DEV_ à true) ou, si le back-office est inaccessible, via un fichier .user.ini contenant display_errors = on. Consultez ensuite var/logs/ et les journaux d’erreurs de votre hébergeur. Les causes les plus fréquentes : module incompatible, override en conflit, mémoire PHP insuffisante, version de PHP incompatible avec votre version de PrestaShop, cache corrompu après une mise à jour. Corrigez la cause identifiée, videz le cache, puis remettez le mode développement à false.
Ce que signifie réellement une erreur 500
Le code 500 est un message du serveur web, pas de PrestaShop. Il dit : « j’ai demandé à PHP de produire une page, PHP s’est interrompu, je n’ai rien à vous montrer ». Le détail de l’interruption existe, mais il est masqué — et c’est normal : afficher une erreur PHP à un visiteur, c’est lui révéler des chemins de fichiers et parfois des informations sensibles.
Sur une boutique en production, l’affichage des erreurs est donc désactivé. Votre premier travail n’est pas de deviner la cause, mais de rendre le message visible, pour vous seul.
Distinguer le 500 de la page blanche
Une page entièrement blanche, sans message ni code d’erreur, relève d’un mécanisme légèrement différent — je le traite dans l’article consacré à la page blanche PrestaShop. Dans les deux cas, la démarche de diagnostic reste la même : rendre l’erreur visible avant toute chose.
Faire apparaître le message d’erreur réel
Trois chemins, selon ce à quoi vous avez encore accès.
1. Le mode développement, si vous avez accès aux fichiers
Dans config/defines.inc.php, repérez la ligne qui définit _PS_MODE_DEV_ et passez-la à true. Rechargez la page en erreur : le message PHP complet s’affiche, avec le fichier et la ligne fautive.
Cette modification expose vos erreurs à tout visiteur. Faites-la le temps du diagnostic, jamais plus, et remettez false immédiatement après.
2. Le fichier .user.ini, quand le back-office est inaccessible
Sur un hébergement mutualisé en PHP-FPM, déposez à la racine de la boutique un fichier .user.ini contenant :
display_errors = onerror_reporting = E_ALL
La prise en compte n’est pas immédiate — comptez quelques minutes selon la configuration du serveur. C’est la méthode qui m’a le plus souvent débloqué des situations où plus rien n’était accessible, pas même l’administration.
3. Les journaux, toujours
Deux endroits à consulter systématiquement :
var/logs/dans votre installation PrestaShop : les journaux applicatifs, avec la trace complète pour les erreurs interceptées par le framework.- Les journaux d’erreurs de votre hébergeur (souvent un fichier
error_logà la racine, ou une section dédiée dans le panneau d’administration) : c’est là que se trouvent les erreurs fatales, celles qui arrêtent PHP avant que PrestaShop ait pu écrire quoi que ce soit.
Regardez l’horodatage : la ligne qui vous intéresse est celle qui correspond à votre dernier essai, pas la plus alarmante du fichier.
Les causes que je rencontre le plus souvent
Un module incompatible ou à demi installé
Le cas classique : un module mis à jour appelle une classe ou une méthode qui n’existe pas dans votre version de PrestaShop. Le message ressemble à Call to undefined method ou Class not found. Le nom du module apparaît presque toujours dans le chemin du fichier.
Correction : renommez le dossier du module dans modules/ (par exemple monmodule en monmodule_off), videz le cache, vérifiez que la boutique revient. Vous pourrez ensuite décider de le mettre à jour correctement, de le remplacer ou de le supprimer proprement depuis le back-office.
Un override en conflit
Deux modules qui surchargent la même classe, ou un override écrit pour une version antérieure : le fichier override/classes/… ou override/controllers/… apparaît dans la trace. Déplacez le fichier hors du dossier override/, supprimez var/cache/, et testez. Attention : retirer un override peut faire disparaître une fonctionnalité — notez ce que vous enlevez.
Une version de PHP incompatible
Très fréquent après une intervention de l’hébergeur. Votre PrestaShop tourne depuis des années en PHP 7.4, l’hébergeur bascule tout le parc en PHP 8.2, et une syntaxe désormais invalide fait tomber la boutique. Le message contient typiquement syntax error, unexpected ou une erreur sur un type d’argument.
Solution immédiate : revenir à la version de PHP précédente depuis votre panneau d’hébergement. Solution durable : monter de version PrestaShop, car une version de PHP abandonnée ne reçoit plus de correctifs de sécurité. Voir la montée de 1.7 vers 9 ou le cas particulier de 1.6.
La mémoire PHP
Message Allowed memory size of X bytes exhausted. Souvent sur une page précise : une catégorie avec beaucoup de produits, un export, une régénération de vignettes. Augmenter memory_limit débloque, mais ce n’est un correctif durable que si la consommation est légitime. Une page produit qui réclame 512 Mo cache généralement un module qui charge tout le catalogue en mémoire.
Un cache corrompu
Après une mise à jour interrompue ou une restauration partielle, les fichiers compilés dans var/cache/ peuvent référencer des classes qui n’existent plus. Supprimez le contenu de var/cache/prod/ (et var/cache/dev/ le cas échéant) par FTP. C’est sans risque : ces fichiers sont régénérés automatiquement.
Le .htaccess
Une directive non supportée par le serveur provoque un 500 sur toutes les pages, y compris les fichiers statiques. Test rapide : renommez temporairement .htaccess. Si la boutique revient (sans mise en forme, c’est normal), régénérez-le depuis Paramètres de la boutique → Trafic & SEO.
La méthode, dans l’ordre
Quand j’arrive sur une boutique en erreur 500, je procède toujours ainsi :
- Sauvegarder avant de toucher à quoi que ce soit. Fichiers et base de données. Une panne peut toujours s’aggraver, et vous devez pouvoir revenir en arrière.
- Demander ce qui a changé. Mise à jour, nouveau module, intervention de l’hébergeur, changement de PHP, restauration ? Dans neuf cas sur dix, la réponse pointe la cause.
- Rendre l’erreur visible par l’une des trois méthodes ci-dessus.
- Lire le message, pas l’interpréter. Le fichier et la ligne indiqués sont l’information la plus fiable dont vous disposez.
- Isoler : désactiver le module suspect, déplacer l’override, revenir à la version de PHP précédente. Un seul changement à la fois, avec un test entre chaque.
- Vider le cache après chaque modification. Sans cela, vous testez encore l’ancien état.
- Remettre le mode développement à false et retirer le
.user.ini. Cette étape s’oublie très facilement — et laisse vos erreurs visibles de tous.
Les erreurs à éviter pendant une panne
La panique fait faire des choses coûteuses. Les quatre que je rencontre le plus :
Restaurer une sauvegarde au hasard. Vous perdez les commandes passées depuis, et si la cause est externe (version de PHP, quota disque), le 500 revient aussitôt.
Tout désactiver d’un coup. La boutique revient peut-être, mais vous ne savez plus quel élément était fautif, et vous devrez tout réactiver un par un de toute façon.
Modifier le cœur de PrestaShop. Corriger une erreur en éditant un fichier du cœur crée une dette invisible : la prochaine mise à jour l’écrasera, et le problème réapparaîtra sans que personne ne comprenne pourquoi.
Laisser le mode développement actif. J’ai vu des boutiques tourner ainsi pendant des mois, affichant à tout visiteur leurs chemins serveur et le détail de leur configuration.
Éviter que ça recommence
Une erreur 500 est rarement un coup du sort. C’est presque toujours le symptôme d’un environnement qui n’est plus tenu à jour ou d’un processus de modification trop direct.
Trois mesures qui évitent la majorité des pannes :
Un environnement de préproduction. Une copie de la boutique où l’on teste les mises à jour avant de les appliquer. C’est le seul moyen fiable de savoir qu’un module cassera quelque chose avant qu’il ne le casse en production.
Des sauvegardes testées. Une sauvegarde dont on n’a jamais vérifié la restauration n’est pas une sauvegarde, c’est une intention.
Une version de PHP maîtrisée. Savoir sur quelle version vous tournez, et quelle version votre PrestaShop supporte réellement, vous met à l’abri du jour où l’hébergeur décidera de faire évoluer son parc.
C’est exactement ce que couvre un accompagnement de maintenance e-commerce : les mises à jour testées ailleurs qu’en production, et quelqu’un qui connaît déjà votre boutique le jour où elle tombe.
Checklist
- Sauvegarder les fichiers et la base avant toute manipulation
- Identifier ce qui a changé juste avant la panne
- Rendre l’erreur visible (mode développement ou
.user.ini) - Lire
var/logs/et le journal d’erreurs de l’hébergeur - Isoler la cause en ne modifiant qu’une chose à la fois
- Vider
var/cache/après chaque modification - Vérifier la boutique en navigation privée, pas seulement le back-office
- Remettre le mode développement à
falseet retirer le.user.ini - Tester une commande complète avant de considérer la panne résolue
Questions fréquentes
Mon back-office est aussi en erreur 500. Que faire ?
Passez par le FTP : c’est le scénario où le fichier .user.ini est le plus utile. Déposez-le à la racine, rechargez, lisez l’erreur. En parallèle, videz var/cache/ : à lui seul, ce geste débloque un bon nombre de situations après une mise à jour interrompue.
L’erreur n’apparaît que sur une seule page. Est-ce vraiment un 500 ?
Oui, et c’est une bonne nouvelle : le périmètre est réduit. Une seule page en erreur pointe généralement vers un produit, une catégorie ou un module précis. Comparez avec une page équivalente qui fonctionne pour isoler la différence.
Puis-je simplement augmenter la mémoire PHP ?
Si l’erreur mentionne explicitement la mémoire, oui, cela débloquera. Mais demandez-vous pourquoi une page de boutique réclame autant : une consommation anormale révèle presque toujours un module qui charge des données sans limite.
Combien de temps faut-il pour résoudre une erreur 500 ?
Une fois le message d’erreur réel sous les yeux, souvent moins d’une heure. C’est l’accès aux journaux et l’identification de ce qui a changé qui prennent du temps — pas la correction elle-même.
Ma boutique est en panne maintenant, pouvez-vous intervenir ?
Écrivez-moi directement sur WhatsApp en décrivant le symptôme et ce qui a changé avant la panne. Je vous dis rapidement si je peux prendre le sujet et sous quel délai. Voir la page dépannage e-commerce.