Erreur 500 PrestaShop : 10 causes fréquentes et solutions rapides

Table des matières :

1. Ce qu’un HTTP 500 implique côté stack PrestaShop (et comment éviter les faux diagnostics)
2. Rendre l’erreur actionnable : debug contrôlé et collecte de logs (PrestaShop 8/9)
3. 10 causes fréquentes d’erreur 500 PrestaShop et solutions rapides (ordre de tri recommandé)
4. Dépannage orienté parcours : front, back‑office, checkout, cron et API
5. Réduire la probabilité de 500 en production : déploiement, observabilité, sécurité

Une erreur 500 PrestaShop (HTTP 500 Internal Server Error) n’est pas un diagnostic : c’est un symptôme. Elle signifie uniquement que le serveur a planté avant de produire une réponse valide. La cause peut être dans PHP (fatal error), dans PrestaShop (exception), dans un module/override, dans la base, ou dans la couche web (Nginx/Apache, WAF, règles de réécriture).

Référentiel utile à garder en tête : la RFC 9110 définit le code 500 ainsi : “The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.” (RFC 9110, §15.6.1).

Dans la pratique, sur une boutique PrestaShop 8.1.x / 9.1+ (Symfony 6.4) avec PHP 8.1 → 8.3, un 500 est souvent l’effet de bord d’un déploiement incomplet (vendor manquant, cache incohérent), d’un module incompatible, ou d’une contrainte runtime (mémoire/timeout) qui se transforme en fatal error.

Pour gagner du temps, traitez le 500 comme un incident “observabilité” avant de le traiter comme un incident “code” :

• Quelle URL exacte (front / BO / endpoint AJAX / API) ?
• À partir de quand (timestamp) et après quel changement (module, thème, PHP, conf serveur, import) ?
• Sur quel périmètre (toutes les pages, seulement produit, seulement panier, seulement BO) ?
• Quel serveur si vous avez plusieurs nœuds (load balancer) ?

Un mini-réflexe utile : notez 3 infos avant toute action (pour éviter le “cache-purge roulette”) : URL + heure + IP client. Cela permet de recouper immédiatement avec les logs Nginx/Apache et PHP-FPM.

Ce qu’un HTTP 500 implique côté stack PrestaShop (et comment éviter les faux diagnostics)

Un 500 peut être généré à plusieurs niveaux. Exemple typique : PHP déclenche un fatal error (TypeError, out-of-memory), PHP-FPM renvoie un échec au serveur web, et Nginx/Apache répond 500. PrestaShop n’a parfois pas le temps d’écrire un log applicatif, d’où la nécessité de regarder d’abord les logs PHP-FPM / serveur web.

Ne confondez pas 500 avec d’autres statuts très proches en e-commerce : 502 (Bad Gateway) signale souvent que Nginx n’arrive pas à parler à PHP-FPM, 503 est fréquemment une maintenance volontaire (ou un backend saturé), 504 est un timeout upstream. Un checkout “qui fait 500” peut, en réalité, être un 504 masqué par un proxy, ou un 499 côté Nginx (client qui coupe) suite à un TTFB trop long.

Côté SEO et exploitation, un 500 est un incident sévère : il casse le parcours client, et côté robots, il réduit la confiance d’exploration (crawl). Si vous êtes déjà sur des problématiques de latence (TTFB élevé, back-office lent), recoupez avec votre diagnostic serveur : voir aussi PrestaShop lent : diagnostic TTFB, bots et optimisation serveur.

Pour éviter les faux diagnostics, gardez en tête deux cas très fréquents sur des hébergements mutualisés ou managés (OVHcloud, cPanel/Plesk, etc.) :

• WAF / ModSecurity : certaines règles peuvent provoquer des erreurs côté application (ou masquer un blocage). Un POST au checkout (adresse, message, code promo) peut déclencher une règle et se traduire par un 500 générique si la plateforme ne renvoie pas un 403 propre.
• Isolation utilisateur / permissions : après une mise à jour faite via FTP, les owners/group peuvent changer (ex. fichiers appartenant à un utilisateur FTP différent), et PrestaShop ne peut plus écrire dans var/cache / var/logs → l’erreur apparaît “comme par magie” au prochain warmup.

Pour vous aider à trier rapidement, voici une grille de lecture “signal → endroit → action” :

Signal observé	Où regarder en premier	Cause probable	Première action sûre
500 immédiat + page blanche	PHP-FPM / error.log	fatal error (TypeError, OOM)	lire fichier/ligne, rollback module/thème
500 seulement sur une page (produit/panier)	logs PHP + logs PrestaShop	module sur hook	désactiver le module en cause, purge cache
500 après déploiement	logs Symfony + var/cache	cache corrompu / vendor absent	purge cache + vérifier artefact / vendor
500 intermittent (pics)	métriques FPM/DB + error log	saturation FPM/DB, timeout	regarder timeouts + charge + slow queries
500 après réglage SEO URL / migration	Nginx/Apache error log	rewrite/htaccess invalide	valider conf, revenir à un template minimal

Rendre l’erreur actionnable : debug contrôlé et collecte de logs (PrestaShop 8/9)

Prérequis : accès FTP/SFTP ou SSH, et idéalement accès aux logs Nginx/Apache + PHP-FPM. Risque : activer un mode debug en production peut exposer des chemins, des tokens, voire des données (PII) dans une stacktrace. Faites-le sur une fenêtre courte, sur IP whitelist si possible, et désactivez après diagnostic.

Sur PrestaShop 8.x / 9.x, le basculement debug se fait classiquement via config/defines.inc.php :

define('_PS_MODE_DEV_', true);

En environnement Symfony (PrestaShop 9.x), vous pouvez aussi cibler l’erreur via les logs Symfony (selon packaging) dans var/logs/ (ou var/log/ suivant la distribution). Pour les cas “page blanche / 500” causés par un fatal PHP, la méthode est la même que pour une page blanche : partir des logs runtime. Voir le pas-à-pas connexe : PrestaShop page blanche : diagnostiquer l’erreur fatale PHP rapidement.

Ensuite, l’ordre de lecture efficace (et reproductible) :

1. Nginx/Apache error log (ex. /var/log/nginx/error.log, /var/log/apache2/error.log).
2. PHP-FPM log (ex. journalctl -u php8.2-fpm -n 200 --no-pager ou log fichier). Pour comprendre où “ça casse” entre le serveur web et PHP-FPM : PHP-FPM : comprendre le flux d’exécution avec Nginx et Apache.
3. Logs applicatifs PrestaShop : var/logs/, var/cache/ (exceptions pendant warmup), logs modules.

Commandes minimales côté Linux (à adapter) :

# Nginx
sudo tail -n 200 /var/log/nginx/error.log

# PHP-FPM via systemd
sudo journalctl -u php8.2-fpm -n 200 --no-pager

# PrestaShop
ls -la var/logs
find var/logs -type f -maxdepth 1 -name "*.log" -print -exec tail -n 80 {} \;

Deux ajouts très utiles quand vous collectez des preuves (surtout en contexte d’équipe / prestataire / hébergeur) :

• Capturer l’ID de requête si vous en avez (reverse proxy / CDN) et la réponse exacte :

  curl -I https://votre-boutique.tld/produit-test

• Vérifier l’espace disque (un disque plein casse l’écriture de cache/logs et peut se transformer en 500) :

  df -h
  du -sh var/cache var/logs 2>/dev/null

Enfin, pensez au “debug contrôlé” : si vous ne pouvez pas activer _PS_MODE_DEV_ globalement, testez sur une fenêtre courte et reproduisez sur une URL unique. Le but est d’obtenir une stacktrace exploitable, pas de laisser le mode dev activé.

10 causes fréquentes d’erreur 500 PrestaShop et solutions rapides (ordre de tri recommandé)

Avant de “corriger”, isolez : une URL, un environnement, un timestamp. Beaucoup d’équipes perdent 2 heures à nettoyer des caches alors que l’incident est un fatal error déclenché par un seul hook sur une page produit. Idéalement : reproduisez sur staging, ou à défaut sur une fenêtre de prod en faible trafic.

Risque opérationnel : plusieurs correctifs ci-dessous impliquent un restart PHP-FPM, une purge de cache ou la désactivation d’un module. Sur une boutique à fort trafic, prévoyez un mode maintenance court, et un rollback. Pour fiabiliser la partie cache et invalidation, gardez comme référence votre stratégie : Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN.

1) Fatal error PHP (TypeError, appel méthode inexistante, etc.)

Signature : 500 immédiat, et dans les logs PHP : PHP Fatal error: (souvent accompagné d’un fichier/ligne). Correctif : corriger le code (module/override/thème), ou faire un rollback. Si c’est sporadique, cherchez un chemin conditionnel (ex. objet null selon contexte boutique/langue/devise).

À vérifier tout de suite :

• l’erreur a-t-elle commencé après mise à jour d’un module ou de PHP ?
• l’erreur ne se produit-elle que sur une boutique (multi-boutique), une langue, ou une devise ?

Mini-scenario typique : un module ajoute un champ optionnel, mais sur une langue le champ est vide → appel à une méthode sur null → fatal → 500 uniquement pour une partie des visiteurs.

2) Mémoire insuffisante (Allowed memory size ... exhausted)

Signature : message explicite dans les logs PHP-FPM. Correctif rapide : augmenter memory_limit (temporairement) et investiguer la fuite (boucle sur gros catalogue, export, facettes, images). Sur PrestaShop, des hooks lourds sur listings + facettes peuvent exploser en mémoire.

Bon réflexe : si le 500 se produit sur une catégorie à fort volume (des milliers de produits), testez avec une pagination plus restrictive et désactivez temporairement les modules de navigation à facettes/filtrage (ou leurs options les plus coûteuses).

3) Timeout applicatif (maxexecutiontime / requestterminatetimeout)

Sur Nginx+PHP-FPM, un script peut être tué côté FPM si request_terminate_timeout est trop bas ou si le worker sature. Correctif : ajuster les timeouts, mais surtout réduire la charge (profiling SQL, pagination, limiter les traitements synchrones au checkout).

Indices fréquents :

• le 500 survient après 30s / 60s de chargement (seuils classiques de timeout) ;
• le log Nginx contient des erreurs de type upstream timed out (qui peuvent se traduire en 504, mais parfois remonter en 500 selon proxy/CDN).

Avant d’augmenter des timeouts “au hasard”, identifiez la requête lente : souvent un export, une génération de PDF, une synchronisation ERP, ou un hook au checkout qui appelle un service externe.

4) Extension PHP manquante ou incompatibilité de version

Après upgrade/downgrade PHP, l’absence de intl, mbstring, zip, gd, etc. peut provoquer des exceptions très tôt (container Symfony, PDF, images). Correctif : installer l’extension, ou réaligner la version PHP supportée par votre PrestaShop et vos modules. Sur OVHcloud, le changement de version passe souvent par .ovhconfig : OVHcloud .ovhconfig : changer version PHP, moteur et mode d’exécution.

Astuce pratique : quand vous basculez de version PHP, vérifiez aussi le mode d’exécution (FPM vs CGI) et la cohérence des extensions entre CLI et FPM. Une commande qui “marche en SSH” peut échouer côté web si PHP-FPM n’a pas les mêmes modules activés.

5) Cache Symfony/Smarty corrompu ou non-écrivable (permissions)

Signature : 500 après déploiement, ou après changement de thème/module, avec erreurs d’écriture dans var/cache/ ou var/logs/. Correctif : vérifier owner/group, puis purger var/cache/* et (selon config) var/cache/prod, var/cache/dev. Attention : la purge peut provoquer un pic CPU (warmup).

Checklist rapide (sans changer tout de suite la prod) :

• var/ est-il écrivable par l’utilisateur du processus web/PHP-FPM ?
• le disque est-il plein (voir df -h) ?
• un déploiement a-t-il restauré des fichiers avec de mauvais owners (classique via FTP) ?

Sur certaines plateformes, un 500 “après purge cache” peut en réalité être un problème de warmup qui échoue (exception Symfony) : regardez les premiers logs créés au moment où le cache se reconstruit.

6) Déploiement incomplet : vendor/ absent ou autoload cassé

Signature : Class not found, require vendor/autoload.php failed, erreurs au boot du kernel Symfony. Correctif : exécuter composer install --no-dev --classmap-authoritative sur l’artefact, ou corriger votre pipeline (build en CI, déploiement d’artefacts, pas de composer install “en prod” si vous voulez des releases déterministes).

Point d’attention : des 500 “juste après release” peuvent venir d’un déploiement non atomique (fichiers mis à jour progressivement). Un visiteur tombe au mauvais moment sur un mix entre anciens fichiers et nouvel autoload → crash. D’où l’intérêt du schéma releases + symlink et d’un rollback instantané.

7) Module tiers qui plante sur un hook critique

Signature : 500 uniquement sur certaines pages (produit, panier, checkout) et stacktrace pointant modules/<module>/.... Correctif rapide : désactiver le module. Sans back-office, deux options : renommer le dossier du module (si le code supporte l’absence), ou désactiver en base :

UPDATE ps_module SET active = 0 WHERE name = 'nomdumodule';

Puis purge cache.

Pour confirmer rapidement sans “casser” la boutique entière, testez :

• une page qui ne déclenche pas le hook (ex. page CMS simple) ;
• la même page avec un paramètre différent (langue, devise) ;
• une requête avec et sans cookies (pour isoler la partie panier/session).

8) Override incompatible (surtout après upgrade PrestaShop 9.x)

Les overrides sont une source classique de 500 après montée de version : signature de méthode changée, classes déplacées, logique de chargement. Correctif : isoler en renommant temporairement override/ (ou l’override incriminé), puis reconstruire l’index de classes / cache. Pour une approche compatible 9.2 : PrestaShop 9.2 : bonnes pratiques d’override et tests de compatibilité.

Bon réflexe en upgrade : avant de toucher à la prod, faites un inventaire de ce qui est “hors core” :

• overrides PHP ;
• surcharges de classes via modules ;
• modifications de thème impactant le front (TPL/JS) ;
• jobs cron et scripts maison qui bootstrappent PrestaShop.

9) Règles de réécriture / .htaccess ou config Nginx incorrecte

Signature : 500 sur toutes les pages front, souvent après modification SEO URL, migration, ou régénération partielle. Sur Apache : un .htaccess avec directive non autorisée (selon AllowOverride) peut générer 500. Correctif : valider la conf, régénérer le .htaccess depuis le BO si accessible, ou repartir d’un template minimal.

À connaître : sur Nginx, l’équivalent du .htaccess est dans la conf serveur. Un copier-coller d’une conf “générique” peut casser :

• la résolution des fichiers front controller (index.php) ;
• les règles de réécriture pour les URLs réécrites ;
• la gestion des assets et du cache.

Si vous êtes derrière un CDN ou un reverse proxy, vérifiez aussi que la réécriture n’a pas créé une boucle (redirection → réécriture → redirection), parfois visible dans les logs.

10) Base de données : schéma incohérent, migration incomplète, saturation connexions

Signature : exceptions PDO/Doctrine, SQLSTATE[...], deadlocks, ou erreurs “too many connections”. Correctif rapide : vérifier credentials (app/config/parameters.php), santé MariaDB/MySQL, et regarder le slow query log / verrous. Pour une méthode propre : PrestaShop MySQL : analyser slow query log et optimiser index.

Cas courant : après migration (ou restauration), certaines tables ont un moteur/charset incohérent, ou des indexes manquent. Résultat : une requête qui passait en 50 ms passe en 10 s → timeout → erreurs en chaîne, surtout au moment du panier/checkout.

Dépannage orienté parcours : front, back‑office, checkout, cron et API

Quand l’erreur 500 n’apparaît que sur le checkout, partez du principe qu’un module de paiement/livraison ou un appel externe (PSP, anti-fraude, ERP) déclenche l’incident. Tracez les requêtes réseau côté serveur (logs applicatifs + logs HTTP sortants si vous en avez), et corrélez avec les latences.

Très concret : si le 500 arrive “au clic payer”, isolez la dernière action serveur :

• endpoint AJAX (validation adresse / transporteur) ;
• création commande ;
• callback module paiement ;
• appel API externe.

Un test simple consiste à reproduire avec un panier minimal (1 produit, 1 transporteur, 1 mode de paiement) : si ça fonctionne, l’erreur dépend probablement d’une condition (zone de livraison, règle de taxes, bon de réduction, module de gift/wrapping…).

Pour un focus “parcours commande” et métriques, vous pouvez recouper avec : Optimisation PrestaShop : audit performance checkout et plan d’action.

Si le 500 est uniquement dans le back-office, suspectez en priorité : droits d’écriture (cache, logs), surcharge CPU, module admin, ou incompatibilité Symfony/JS admin après mise à jour. Le back-office (Symfony) a tendance à révéler plus tôt des erreurs de container/services que le front. En PrestaShop 9, les modules “admin” doivent être alignés sur Symfony 6.4 (autowiring, DI) : voir PrestaShop modules : optimiser la compatibilité Symfony 6.4 et Admin API.

Pour les crons et tâches CLI, distinguez : exécution via HTTP (soumise aux timeouts proxy/FPM) vs exécution en CLI (soumise à la mémoire et aux variables d’environnement). Un cron qui “marche en CLI” mais fait 500 en HTTP pointe souvent un problème de timeout, ou de contexte (utilisateur, token, shop context).

Deux vérifications rapides :

• l’URL du cron est-elle appelée par un robot externe avec un timeout court (certaines plateformes coupent à 30s) ?
• le cron écrit-il dans var/logs et échoue-t-il si les permissions ne sont pas bonnes ?

Pour les API, un 500 doit être reproduit avec curl -v et des payloads minimaux. Si vous utilisez le Webservice natif : API Webservice PrestaShop : guide CRUD et ressources développeur.

Réduire la probabilité de 500 en production : déploiement, observabilité, sécurité

Sur PrestaShop, la majorité des 500 “mystère” viennent d’un manque de déterminisme : déploiements non atomiques, caches partagés incohérents, et absence de logs corrélables. Objectif : pouvoir répondre en 5 minutes à “qu’est-ce qui a changé ?” (code, conf, data, infra). Dans l’esprit Twelve-Factor, gardez une discipline de logs : “Logs are treated as event streams.” (The Twelve-Factor App, section Logs). En clair : logs structurés, centralisés, et corrélés par release + request-id.

Côté delivery, privilégiez : build d’artefact en CI, composer install en build (pas en prod), et un déploiement atomique (répertoire release + symlink). Ajoutez un healthcheck applicatif (page légère qui bootstrape PrestaShop sans dépendre du cache complet) et un rollback immédiat. Si vous n’avez pas d’environnement miroir, créez-en un : Staging PrestaShop : créer un environnement Docker fidèle à la production.

Côté observabilité, instrumentez le minimum vital : métriques PHP-FPM (process idle/busy, slowlog), latence DB, erreurs 5xx, et saturation disque (un df -h à 100% finit souvent en 500 par impossibilité d’écrire cache/logs).

Une bonne pratique “terrain” sur des boutiques françaises/UE à trafic variable (pics soldes, campagnes TV, newsletters) : posez des alertes simples sur :

• taux de 5xx (front + BO) ;
• temps de réponse (p95/p99 si possible) ;
• saturation FPM (workers tous occupés) ;
• connexions DB et requêtes lentes.

Pour l’outillage, vous pouvez partir d’un monitoring simple et exploitable : Netdata : activer et configurer les collectors pour monitoring temps réel ou industrialiser avec alerting : Prometheus : configuration des alertes, métriques et requêtes PromQL.

Dernier point non négociable : sécurité. Une boutique infectée (skimmer) ou un module vulnérable peut provoquer des comportements erratiques (crash PHP, surcharge DB, WAF qui bloque), avec 500 comme symptôme secondaire. Si vous suspectez une compromission, traitez-la comme un incident sécurité (freeze, acquisition de preuves, rotation secrets), pas comme un “bug”. Pour cadrer un plan de durcissement, voir : Audit sécurité PrestaShop : méthodologie, livrables et durcissement.

Références externes (pour recouper rapidement)

• RFC 9110 (HTTP Semantics), §15.6.1 – 500 Internal Server Error
• Documentation Nginx – logs et debug
• Documentation PHP – erreurs fatales et configuration
• Documentation Symfony – environnements et cache (utile pour PrestaShop 9.x)
• Google Search Central – erreurs réseau et HTTP (impact crawl/indexation)