Erreur 500 sur PrestaShop - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant toute intervention, identifie où l'erreur 500 se déclenche : c'est l'information qui oriente tout le reste du diagnostic. Une 500 globale, une 500 sur certaines routes seulement (checkout, page catégorie) et une 500 limitée au back-office après une mise à jour ne pointent pas vers les mêmes causes.

Distingue aussi deux affichages différents. Le message explicite — « HTTP 500 – Internal Server Error », « Erreur interne du serveur », « Le serveur a rencontré une erreur interne » — indique que le serveur web a bien remonté l'échec PHP. La page entièrement blanche est plus traître : elle signifie le plus souvent qu'une erreur fatale PHP s'est produite alors que display_errors est désactivé. Le débogage est identique, mais la page blanche t'oblige à passer par les logs ou le mode debug pour voir quoi que ce soit.

• Page blanche ou message « Internal Server Error » sur tout ou partie du site
• Back-office inaccessible juste après une mise à jour PrestaShop ou d'un module
• Erreur déclenchée uniquement au checkout ou sur les pages catégories, alors que l'accueil répond
• Pics d'erreurs corrélés dans les logs PHP, Apache/Nginx et var/logs/prod.log
• Messages de log du type Fatal error: Allowed memory size exhausted ou InactiveScopeException

1. Note l'URL exacte qui échoue et celles qui fonctionnent encore (accueil, fiche produit, BO).
2. Ouvre la console réseau du navigateur (F12 → Réseau) et confirme un code HTTP 500 sur la requête, pas un 502, 503 ou 504.
3. Reproduis l'erreur en navigation privée pour écarter un cache navigateur ou un cookie de session corrompu.
4. Repère le déclencheur temporel : la 500 est-elle apparue après une mise à jour, l'install d'un module, un import CSV, une régénération d'images ou un pic de trafic ?

Distinction avec les autres erreurs 5xx

Toutes les erreurs serveur ne sont pas des 500, et confondre les codes envoie sur la mauvaise piste. La 500 (Internal Server Error) vient de ton application : PHP a planté en exécutant PrestaShop. Les autres 5xx viennent généralement de l'infrastructure et se corrigent côté serveur, pas dans le code PrestaShop.

• 500 Internal Server Error : erreur PHP/application (module, override, mémoire) — c'est l'objet de ce guide.
• 502 Bad Gateway : le reverse proxy (Nginx) n'obtient pas de réponse valide de PHP-FPM — souvent PHP-FPM tombé ou socket mal configurée.
• 503 Service Unavailable : serveur saturé ou en maintenance — vérifier la charge, le pool PHP-FPM ou un mode maintenance actif.
• 504 Gateway Timeout : la requête dépasse le délai du proxy — typiquement un script trop long (import, génération de PDF) que max_execution_time n'a pas suffi à finir.

Impact business immédiat

Une erreur 500 n'est pas un incident technique abstrait : c'est une coupure de revenu en temps réel. Si elle touche le tunnel de commande ou le catalogue, tu perds des ventes à chaque visite, et tu ne le vois pas toujours dans ton monitoring si seules certaines routes échouent pendant que l'accueil reste vert.

Au-delà de la perte directe, l'effet se propage. Le trafic payant que tu envoies via Google Ads ou Meta atterrit sur des pages cassées : tu paies des clics pour zéro conversion et tu dégrades ton Quality Score. Côté SEO, si Googlebot rencontre des 500 répétées, il réduit son crawl et peut désindexer temporairement les URL concernées. Et chaque client qui tombe sur la panne génère du support et une image de marque abîmée.

• Perte immédiate de commandes tant que les pignons de vente renvoient une 500
• Budget Ads brûlé sur des pages en erreur, avec dégradation du Quality Score
• Risque de baisse de crawl et de désindexation SEO si les 500 persistent plusieurs heures
• Surcharge du support client et érosion de la confiance

Causes classées par probabilité

Sur les centaines d'incidents 500 traités, la cause racine se concentre sur une poignée de coupables. Les voici dans l'ordre où il faut les suspecter, du plus fréquent au plus rare. Cette hiérarchie te fait gagner le plus de temps : commence par le haut.

Indice fort : si l'erreur est apparue juste après une action précise (install module, mise à jour, déploiement), la cause est presque toujours liée à cette action. Si elle est apparue sans rien toucher, oriente-toi vers la mémoire, les permissions ou un pic de trafic.

• 1. Module incompatible ou obsolète (cause n°1, ~7 cas sur 10) : un module récemment installé ou mis à jour, incompatible avec ta version PrestaShop ou de Symfony.
• 2. Override ou hook cassé après déploiement : une surcharge dans override/ qui référence une classe ou méthode qui n'existe plus après mise à jour.
• 3. memory_limit PHP trop bas : Fatal error: Allowed memory size exhausted, fréquent sur les pages lourdes ou la régénération d'images.
• 4. Cache var/cache/ non vidé après mise à jour (PS 8/9) : le conteneur Symfony sert des références obsolètes.
• 5. .htaccess corrompu : règles de réécriture cassées, souvent après une migration ou une régénération ratée.
• 6. Permissions CHMOD incorrectes sur var/, img/, cache : PHP ne peut plus écrire.
• 7. Incompatibilité version PHP : ta version de PHP n'est pas supportée par ta version de PrestaShop.
• 8. Timeout d'exécution (max_execution_time) sur import CSV, sauvegarde ou régénération de vignettes.
• 9. Module PHP manquant (GD, cURL, OpenSSL, Zip, PDO) après changement d'hébergement.
• 10. Requête SQL lourde ou table gonflée (ex. ps_connections saturée par un bot) qui fait tomber la connexion.

Diagnostic : les commandes à lancer

Ne corrige rien tant que tu n'as pas la vraie exception. L'objectif de cette phase est d'obtenir le nom de classe, le fichier et la ligne qui plantent — c'est ce qui te mène droit au module ou à l'override fautif.

Prérequis sécurité avant de toucher quoi que ce soit : sauvegarde les fichiers et la base. Une 500 ne doit pas se transformer en perte de données.

# Dump base de données
mysqldump -u USER -p NOM_BASE > backup_avant_fix_$(date +%F).sql
# Archive des fichiers sensibles (config, modules, override)
tar czf backup_files_$(date +%F).tar.gz config/ modules/ override/ .htaccess

# Apache (mod_php)
tail -f /var/log/apache2/error.log

# Nginx + PHP-FPM (VPS / FastCGI) : c'est le log PHP-FPM qui parle
tail -f /var/log/nginx/error.log
tail -f /var/log/php-fpm/www-error.log

# Filtrer directement les erreurs fatales PHP des dernières lignes
grep -iE "PHP (Fatal|Parse) error|Allowed memory" /var/log/apache2/error.log | tail -n 30

# Log Symfony côté production : la stack trace complète y est
tail -n 50 var/logs/prod.log
tail -n 50 var/logs/dev.log    # si environnement dev

# PrestaShop 1.6 : log applicatif dans /log/
tail -n 50 log/*.log

// PS 1.6 / 1.7 / 8 : config/defines.inc.php
define('_PS_MODE_DEV_', true);   // false en production

// PS 8.x / 9 : alternative via .env (Symfony)
// APP_ENV=dev
// APP_DEBUG=1

// À placer temporairement en tête de index.php pour révéler une fatale masquée
@ini_set('display_errors', 'on');
error_reporting(E_ALL);

# Overrides modifiés en dernier (du plus récent au plus ancien)
ls -lt override/classes/ override/controllers/ override/modules/

# Modules touchés récemment
ls -lt modules/ | head -n 15

# En CLI
php -i | grep -iE "memory_limit|max_execution_time"
php -m | grep -iE "gd|curl|openssl|zip|pdo"

# Ou via un fichier jetable (à supprimer juste après)
# echo '<?php phpinfo();' > info.php   puis ouvrir /info.php

-- Table de connexions souvent saturée par les bots
SELECT COUNT(*) FROM ps_connections;
-- Si plusieurs millions de lignes, purger l'ancien :
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Repérer les tables corrompues
CHECK TABLE ps_orders, ps_cart, ps_product;

Lire et interpréter la stack trace

C'est l'étape que la plupart des guides sautent. Activer le debug ne sert à rien si tu ne sais pas lire ce qu'il affiche. Une exception PrestaShop te donne trois informations qui désignent presque toujours le coupable.

Cas concret typique rencontré sur une boutique PS 8.1 après mise à jour d'un module de cross-selling : la page produit renvoyait une 500, et var/logs/prod.log contenait une ligne du type Error: Class "PrestaShop\Module\CrossSell\..." not found in /modules/crosssell/crosssell.php on line 142. Le triptyque nom de classe / fichier / ligne pointait directement le module : le déploiement avait laissé un fichier de classe manquant. Désactivation du module → résolution immédiate, puis réinstallation propre.

• Le type d'exception : Fatal error: Allowed memory size → mémoire ; Class ... not found → autoload/override/module ; InactiveScopeException → conteneur Symfony / cache obsolète.
• Le chemin du fichier : s'il contient /modules/NOM/ tu tiens le module fautif ; s'il contient /override/ c'est une surcharge à corriger ou retirer.
• Le numéro de ligne : il confirme l'endroit exact, utile pour distinguer un vrai bug d'une simple incompatibilité de version.

Solutions pas-à-pas

Applique les correctifs dans l'ordre de probabilité, en commençant par ce que la stack trace ou le déclencheur t'a indiqué. Règle absolue : ne désactive jamais tous les modules en bloc — tu perdrais la configuration business. Procède par bisection (isolement progressif).

1. Module fautif, back-office accessible : va dans le BO, désactive le dernier module installé ou mis à jour, recharge la page en erreur. Si c'est résolu, garde-le désactivé et réinstalle proprement la version compatible.
2. Module fautif, back-office en 500 : désactive le module par renommage de dossier en SSH, puis vide le cache. Exemple : mv modules/ps_emailalerts modules/ps_emailalerts_disabled. Procède un module à la fois en partant du dernier touché.
3. Override cassé : déplace le fichier d'override suspect hors du dossier (mv override/classes/Product.php /tmp/) et vide le cache. Si la 500 disparaît, le correctif est dans cet override.
4. Mémoire insuffisante : passe memory_limit à 512M (256M acceptable, 128M minimum). Via php.ini : memory_limit = 512M. Sans accès php.ini, via .htaccess : php_value memory_limit 512M. Recharge.
5. Cache obsolète (surtout PS 8/9 après MAJ) : vide le cache applicatif. rm -rf var/cache/* puis supprime var/cache/prod/class_index.php et var/cache/dev/class_index.php. PS 1.6 : c'est le dossier /cache/.
6. OPcache après mise à jour : si tu es sur PHP-FPM/FastCGI et que la 500 persiste après vidage de var/cache/, recharge PHP pour purger l'OPcache : sudo systemctl reload php8.1-fpm (adapte la version).
7. htaccess corrompu : neutralise-le avec mv .htaccess .htaccess.bak, recharge. Si ça repart, régénère-le proprement depuis le BO (voir spécificités par version).
8. Permissions : remets les bons CHMOD — fichiers 644, dossiers 755, dossiers inscriptibles 775. Ne mets jamais 777 (faille de sécurité). Voir le bloc commandes ci-dessous.
9. Timeout sur tâche longue (import, vignettes) : passe max_execution_time à 300 (défaut 30) dans php.ini, relance l'opération. Pour les imports massifs, fractionne le fichier CSV.
10. Module PHP manquant : installe l'extension absente repérée par php -m (ex. sudo apt install php8.1-gd) et redémarre PHP-FPM.
11. Désactive le mode debug une fois corrigé : repasse _PS_MODE_DEV_ à false (ou APP_DEBUG=0 / APP_ENV=prod) et retire tout display_errors ou info.php laissé en place. Laisser le debug actif en production est une fuite d'informations sensibles.

# Fichiers en 644, dossiers en 755 sur toute l'installation
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

# Dossiers que PrestaShop doit pouvoir écrire : 775
chmod -R 775 var/ img/ upload/ download/ mails/ themes/

Spécificités par version

Le mode debug, le cache et la régénération du .htaccess changent selon ta version. Identifie la tienne (visible en bas du back-office ou dans config/) avant d'appliquer.

Point clé souvent ignoré : sur PS 8.x et 9, une grande partie des 500 vient du conteneur Symfony et du cache var/cache/ non régénéré après une mise à jour. Le réflexe « vider var/cache/ » résout beaucoup d'incidents post-MAJ sur ces versions, là où sur 1.6 le cache vivait dans /cache/ et le mécanisme était plus simple.

• PS 1.6.x — PHP 5.4 à 7.1. Debug via define('_PS_MODE_DEV_', true) dans config/config.inc.php. Cache dans /cache/. Régénération .htaccess : Préférences > SEO & URLs.
• PS 1.7.x — PHP 7.1 à 7.4. Debug dans config/defines.inc.php. Cache dans var/cache/ + log applicatif var/logs/prod.log. Régénération .htaccess : Paramètres de la boutique > Trafic & SEO.
• PS 8.x — PHP 7.2.5 minimum, 8.1 recommandé. Debug no-code : BO > Paramètres avancés > Performances > Mode debug > Oui. Ou via .env (APP_DEBUG=1, APP_ENV=dev). Beaucoup de 500 = cache Symfony à vider.
• PS 9.x — base Symfony renforcée, PHP 8.1+. Même logique que 8.x : .env, BO > Performances, et vidage de var/cache/ prioritaire après toute mise à jour ou modification d'override.

// Dans config/defines.inc.php : debug actif uniquement pour TON adresse IP
if (!defined('_PS_MODE_DEV_') && in_array($_SERVER['REMOTE_ADDR'],
    array('::1', 'localhost', '127.0.0.1', 'xx.xx.xx.xx'))) {
    define('_PS_MODE_DEV_', true);
} else {
    define('_PS_MODE_DEV_', false);
}

Prévention : éviter la prochaine 500

La plupart des 500 sont évitables avec quelques garde-fous, surtout autour des mises à jour et des installs de modules — les deux principaux déclencheurs.

• Teste toute mise à jour PrestaShop ou de module sur un environnement de staging avant la production.
• Sauvegarde fichiers + base avant chaque déploiement ou install de module.
• Vérifie la compatibilité PHP × version PrestaShop avant de mettre à jour PHP côté hébergeur.
• Garde memory_limit à 512M et max_execution_time à 300 pour absorber les tâches lourdes.
• Purge régulièrement ps_connections et surveille la taille des tables sensibles.
• Vide systématiquement var/cache/ après toute mise à jour sur PS 8/9.
• Ne déploie jamais d'override sans vérifier qu'il référence des classes existantes dans la version cible.

Quand appeler un expert

Tu peux corriger seul une 500 dans la majorité des cas avec ce protocole. Appelle un expert quand : la stack trace pointe le cœur de PrestaShop ou du conteneur Symfony et non un module, quand la 500 touche le checkout en pleine période de ventes et que chaque minute compte, ou quand le débogage révèle plusieurs causes imbriquées (override + module + base) que la bisection ne suffit pas à démêler.

Si tu es bloqué ou que l'incident impacte ton chiffre d'affaires en direct, l'équipe BugRescue traite ce type d'urgence PrestaShop régulièrement — diagnostic à partir des logs, isolement par bisection sans casser ta config, et remise en ligne. Mieux vaut un diagnostic ciblé qu'une cascade de modifications hasardeuses sur une boutique en production.

FAQ