Mis à jour le 1er novembre 2026. Ajouts : où trouver les journaux sur PrestaShop 9, six causes fréquentes qui manquaient (version de PHP, mémoire, cache, surcharges, fichiers manquants, pare-feu de l’hébergeur), un tableau de diagnostic rapide et les commandes utiles.
L’erreur 500 est une panne générique côté serveur : elle dit que quelque chose a échoué, pas quoi. La bonne méthode consiste à lire d’abord le message exact, puis à tester les causes dans l’ordre, des plus probables aux plus rares. Ce guide vaut pour PrestaShop 8 et 9 ; les chemins de fichiers ont été vérifiés sur PrestaShop 9.2.
Diagnostic rapide
| Ce que vous constatez | Cause probable | Où regarder |
|---|---|---|
| « Allowed memory size … exhausted » | Mémoire PHP insuffisante | Cause 4 |
« Class … not found » ou erreur dans override/ | Surcharge d’un module, cache des classes | Cause 6 |
| Erreur juste après une mise à jour de PrestaShop | Cache, module incompatible, fichiers manquants | Causes 5, 7 et 8 |
| Erreur après un changement de version de PHP | Version de PHP non prise en charge, extension absente | Cause 2 |
| Tout le site en erreur, même les images | Fichier .htaccess | Cause 1 |
| Erreur seulement pendant un import ou une régénération | Délai d’exécution | Cause 9 |
| Erreur seulement en envoyant un formulaire précis | Pare-feu de l’hébergeur | Cause 10 |
| Erreur seulement dans le back-office | Module d’administration, mémoire, cache | Causes 4 à 7 |
Étape 0 : lire le message d’erreur
Sans le message exact, vous testez à l’aveugle. Trois sources, dans cet ordre :
- Les journaux de PrestaShop, dans le dossier
var/logs/. Sur PrestaShop 9, ils sont découpés par jour :prod-2026-11-01.logpour la boutique en production,dev-…en mode debug. - Le journal d’erreurs PHP ou celui du serveur web, accessible depuis le panneau de votre hébergeur (cPanel, Plesk…), souvent sous le nom
error_log. - Le mode debug, qui affiche l’erreur à l’écran. Si le back-office est inaccessible, passez
_PS_MODE_DEV_àtruedansconfig/defines.inc.php, comme l’indique la documentation officielle. Remettez-le àfalsedès le diagnostic terminé : il affiche des détails techniques aux visiteurs.
# Les 50 dernières lignes du journal du jour (depuis la racine de la boutique)
tail -n 50 var/logs/prod-$(date +%F).logLa démarche complète est détaillée dans notre guide de débogage PrestaShop 8 et 9.
500, 502, 503 ou 504 : ce n’est pas la même panne
| Code | Signification | Piste |
|---|---|---|
| 500 | Erreur dans le code ou la configuration | Causes de cet article |
| 502 | Le serveur web ne reçoit pas de réponse de PHP | PHP arrêté ou planté : hébergeur |
| 503 | Service indisponible | Maintenance, surcharge, limite de ressources |
| 504 | Délai dépassé | Script trop long : voir la cause 9 |
Cause 1 : le fichier .htaccess
Une seule ligne invalide dans ce fichier suffit à mettre tout le site en erreur 500, y compris les images. Deux cas fréquents :
- Des directives refusées par le serveur. Les lignes
php_valueouphp_flag, ajoutées par un module ou un tutoriel, provoquent une erreur 500 sur les hébergements où PHP ne tourne pas comme module Apache, ce qui est aujourd’hui le cas le plus courant. Réglez ces valeurs dans le panneau de l’hébergeur ou dans un fichier.user.ini. - Des règles de réécriture abîmées, après une modification manuelle ou un module.
Pour tester : renommez le fichier en .htaccess.bak. Si le site revient (sans les URL simplifiées), le problème est confirmé. Pour le régénérer proprement, enregistrez la page Paramètres de la boutique > Trafic et SEO : PrestaShop réécrit le fichier. Le centre d’aide officiel suggère aussi de désactiver puis réactiver les URL simplifiées.
# Repérer les directives PHP dans le .htaccess
grep -n "php_value\|php_flag" .htaccessCause 2 : une version de PHP incompatible
Un hébergeur qui change la version de PHP, ou une mise à jour de sécurité comme celle du 21 octobre 2026, peut faire tomber une boutique. Chaque version de PrestaShop accepte une plage de versions de PHP : selon la documentation officielle, PrestaShop 9.1 fonctionne avec PHP 8.1 à 8.5 et recommande la 8.5. Les versions 8 de PrestaShop n’acceptent pas les PHP les plus récents. Vérifiez le tableau de la documentation pour votre version exacte, puis choisissez la bonne version de PHP dans le panneau de l’hébergeur.
Une extension PHP manquante donne le même symptôme. PrestaShop 9 a besoin notamment de curl, dom, fileinfo, gd, iconv, intl, json, mbstring, openssl, pdo_mysql, simplexml et zip.
Cause 3 : les permissions et le propriétaire des fichiers
Le centre d’aide recommande 755 pour les dossiers, plutôt que 777, peu sûr : toute personne ou tout programme qui accède au serveur peut y écrire. Les fichiers se règlent en 644. Sur beaucoup d’hébergements, un fichier ou un dossier en 777 provoque d’ailleurs lui-même une erreur 500.
Le propriétaire des fichiers compte autant que les droits. Après un envoi FTP ou une restauration faits avec un autre utilisateur, PHP ne peut plus écrire dans var/, img/ ou upload/. Votre hébergeur peut rétablir le bon propriétaire.
# Depuis la racine de la boutique : dossiers en 755, fichiers en 644
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;Cause 4 : la mémoire PHP est épuisée
Le journal affiche « Allowed memory size of … bytes exhausted ». La documentation de PrestaShop 9 recommande une limite memory_limit d’au moins 512 Mo. Un module gourmand, un gros catalogue ou une génération de sitemap peuvent dépasser une limite plus basse. Augmentez-la dans le panneau de l’hébergeur ou dans .user.ini, puis cherchez le module en cause si le problème revient.
Cause 5 : le cache de PrestaShop est corrompu
Après une mise à jour, un changement de module ou un envoi de fichiers interrompu, le cache peut contenir des fichiers incohérents. Videz-le depuis Paramètres avancés > Performances si le back-office répond, sinon à la main :
# Supprimer le cache de production (PrestaShop le reconstruit seul)
rm -rf var/cache/prodVoir notre article sur le vidage du cache PrestaShop 8 et 9.
Cause 6 : une surcharge (override) d’un module
Certains modules modifient le cœur de PrestaShop avec des fichiers placés dans override/. Après une mise à jour, ces surcharges peuvent ne plus correspondre au code et provoquer une erreur 500, souvent « Class … not found » ou une erreur dans un fichier de override/.
- Si le back-office répond : Paramètres avancés > Performances, section Mode debug, option Désactiver toutes les surcharges.
- Sinon : renommez le fichier
override/concerné, puis supprimezvar/cache/prod/class_index.php, l’index des classes que PrestaShop reconstruit.
Cause 7 : un module incompatible ou ancien
C’est la cause la plus fréquente après une mise à jour de PrestaShop, notamment d’une version majeure à l’autre. Le centre d’aide propose de :
- vérifier que chaque module est compatible avec votre version de PrestaShop ;
- vider le cache ;
- désactiver les modules récemment installés ou mis à jour, un par un, jusqu’à retrouver la panne.
Si le back-office est inaccessible, renommez le dossier du module suspect dans modules/ : PrestaShop l’ignore alors. Pour une migration, voir Migration de PrestaShop 8 vers 9.
Cause 8 : des fichiers manquants ou une base en défaut
Fichiers manquants. Un envoi FTP interrompu pendant une mise à jour laisse des fichiers absents ou tronqués, souvent dans vendor/. Le journal parle alors d’un fichier introuvable. La solution : renvoyer les fichiers de la même version depuis l’archive officielle.
Base de données. Une table endommagée, trop de connexions simultanées ou des identifiants changés dans app/config/parameters.php donnent aussi une erreur 500. Pour une erreur de création d’index lors d’une installation ou d’une migration, voir Erreur MySQL 1071 sur PrestaShop.
Espace disque. Un hébergement plein (espace ou nombre de fichiers) empêche PrestaShop d’écrire son cache et ses journaux. Vérifiez le quota dans le panneau de l’hébergeur.
Cause 9 : le délai d’exécution
Un import CSV, une sauvegarde, le chargement des traductions ou la régénération des miniatures peut dépasser le délai maximal du serveur. Le centre d’aide cite une limite fréquente de 30 secondes, insuffisante pour ces opérations. Selon le serveur, le dépassement donne une erreur 500 ou 504. Demandez à votre hébergeur d’augmenter le délai, au moins le temps de l’opération, ou découpez le traitement en petits lots.
Cause 10 : le pare-feu de l’hébergeur
Beaucoup d’hébergeurs filtrent les requêtes avec un pare-feu applicatif (ModSecurity, LiteSpeed). Quand une saisie ressemble à une attaque, le pare-feu bloque la requête et renvoie une erreur 403 ou 500. Le symptôme est typique : l’erreur n’apparaît qu’en enregistrant un contenu précis, par exemple un texte contenant certains mots ou du code, et le journal de PrestaShop reste vide. Nous l’avons constaté sur une boutique où un simple texte de FAQ était bloqué. Seul l’hébergeur peut assouplir la règle en cause : transmettez-lui l’heure exacte et l’adresse de la page.
L’ordre de diagnostic résumé
- Lisez le message dans
var/logs/ou le journal du serveur (étape 0). - Si tout le site est en erreur, testez le
.htaccess. - Vérifiez la version de PHP et ses extensions, surtout après un changement chez l’hébergeur.
- Contrôlez la mémoire, les permissions et le propriétaire des fichiers.
- Videz le cache, puis désactivez les surcharges.
- Désactivez les modules récents, un par un.
- Vérifiez les fichiers, la base et l’espace disque.
- En dernier recours, restaurez une sauvegarde récente.
Si la panne persiste ou si la boutique ne peut pas rester arrêtée, l’agence Genisoft assure le dépannage PrestaShop.
Questions fréquentes
L’erreur 500 peut-elle venir d’un piratage ?
Oui. Un fichier modifié par un attaquant, ou un code malveillant mal écrit, peut provoquer l’erreur. Si elle apparaît sans aucune intervention de votre part et sans cause trouvée dans les journaux, contrôlez les fichiers et la base : voir Boutique PrestaShop piratée : que faire, dans l’ordre et en urgence.
Dois-je activer le mode debug sur la boutique en ligne ?
Le moins longtemps possible, et de préférence sur une copie : il affiche des détails techniques aux visiteurs. Les journaux de var/logs/ donnent souvent la même information sans rien montrer au public.
L’erreur 500 n’apparaît que dans le back-office, est-ce plus grave ?
Pas forcément, mais la piste est différente : un module d’administration, une surcharge ou un manque de mémoire sont les causes les plus probables. Le site public continue souvent de vendre pendant le diagnostic.
Faut-il réinstaller PrestaShop ?
Presque jamais. Une réinstallation fait perdre du temps et ne corrige pas un module ou un réglage de serveur défaillant. Trouvez d’abord le message exact ; si vous devez remplacer des fichiers, reprenez ceux de la même version depuis l’archive officielle.
Sources
- Centre d’aide PrestaShop, « How to resolve a 500 error? » : help-center.prestashop.com
- Centre d’aide PrestaShop, « Error 500 after installing or updating a module » : help-center.prestashop.com
- Documentation PrestaShop 9, configuration requise : devdocs.prestashop-project.org
