Erreur 500 PrestaShop : comment la diagnostiquer et la corriger

Une erreur 500 sur PrestaShop peut couper toute la boutique. Parfois, elle n’apparaît que dans le back-office, sur une fiche produit, dans le panier ou au moment du paiement. Le problème, c’est que le message Internal Server Error ne dit presque rien à lui seul.

Le bon réflexe n’est pas de tout modifier en même temps. Vous devez d’abord retrouver le vrai message d’erreur, puis tester dans un ordre logique : mode debug, logs, dernière modification, modules, cache et environnement serveur. À la fin de ce guide, vous saurez quoi vérifier, dans quel ordre, et à quel moment il vaut mieux arrêter les essais pour éviter d’aggraver la panne.

Ce que signifie vraiment une erreur 500 sur PrestaShop

Le code 500 est un symptôme générique. Avant de toucher aux fichiers ou au serveur, commencez par préciser le périmètre exact de la panne.

Comprendre pourquoi le code 500 ne suffit pas à lui seul

Selon MDN, au 20 octobre 2026, le code HTTP 500 signifie que le serveur a rencontré une condition inattendue sans pouvoir renvoyer un code 5xx plus précis. Autrement dit, la 500 n’est pas une cause. C’est le symptôme visible d’une erreur plus précise que vous devez retrouver dans le mode debug ou dans les logs.

Un même symptôme peut venir d’un module incompatible, d’un cache obsolète, d’un changement PHP, d’un .htaccess invalide, d’un manque de mémoire ou de permissions incorrectes. Si vous restaurez tout trop tôt, vous risquez de perdre du temps et d’ajouter un retour arrière lourd alors que le correctif pouvait être ciblé.

Identifier si la panne touche tout le site, le back-office ou une action précise

Avant tout test, notez ce qui casse exactement :

• toute la boutique ;
• seulement le front-office ;
• seulement le back-office ;
• une action précise : ouverture d’une fiche produit, ajout au panier, passage de commande, génération d’un PDF, etc.

Cette étape vous fait gagner du temps, car vous n’allez pas chercher au même endroit si tout le site tombe ou si seule une étape du tunnel casse. Si vous voulez élargir le diagnostic au-delà de la seule 500, vous pouvez aussi consulter les causes fréquentes d’un site PrestaShop en panne.

Faire apparaître le vrai message d’erreur avec le mode debug et les logs

Tant que vous n’avez pas le message réel, vous avancez à l’aveugle. L’objectif de cette étape est simple : faire parler PrestaShop, puis recouper avec les journaux PHP et serveur.

Activer le mode debug si le back-office est inaccessible

Par défaut, PrestaShop masque les erreurs côté front. La documentation officielle indique, au 20 octobre 2026, d’activer le mode debug en mettant _PS_MODE_DEV_ à true dans /config/defines.inc.php, ou depuis le back-office s’il reste accessible : documentation PrestaShop 9.

Faites ce test uniquement le temps du diagnostic. La même documentation précise que le mode debug a un impact significatif sur les performances et doit être désactivé après analyse. Le but est d’obtenir le message précis, le nom du fichier, la classe, le module ou la fonction en cause, puis de repasser en configuration normale.

Si votre administration ne répond plus du tout, le diagnostic dépasse vite la simple lecture d’erreur. Dans ce cas, vous pouvez comparer vos symptômes avec la page dédiée à un back-office PrestaShop inaccessible.

Lire les logs utiles : PrestaShop, PHP, Apache ou Nginx

Le mode debug aide, mais ce sont souvent les logs qui donnent la cause exploitable. Reproduisez la panne, notez l’heure exacte, puis lisez les entrées correspondantes dans :

• les logs applicatifs disponibles côté PrestaShop ;
• les logs PHP ;
• les logs du serveur web, côté Apache ou Nginx selon votre hébergement.

Le manuel PHP rappelle qu’en production il ne faut pas laisser l’affichage des erreurs activé, et que log_errors permet d’enregistrer les erreurs dans le log défini par error_log. Côté serveur, les journaux d’erreurs sont des actifs de diagnostic majeurs. Ce que vous cherchez n’est pas un long historique, mais la première erreur utile au moment précis où vous reproduisez la 500.

Concrètement, relevez le fichier concerné, le module cité, une erreur mémoire, une incompatibilité de version, une directive refusée ou une erreur de syntaxe. Sans cette ligne précise, vous risquez de corriger un effet secondaire au lieu de la cause.

Revenir d’abord sur la dernière modification faite sur la boutique

La bonne question est souvent simple : qu’est-ce qui a changé juste avant la panne ? C’est souvent le meilleur point d’entrée, bien avant les hypothèses générales.

Tester les modules installés ou mis à jour juste avant la 500

Le centre d’aide PrestaShop indique, au 18 juillet 2025, qu’une erreur 500 après installation ou mise à jour d’un module peut venir d’incompatibilités entre modules, d’une incompatibilité avec la version de PrestaShop, d’un cache obsolète, d’un conflit de code ou d’une mise à jour incomplète : aide PrestaShop sur l’erreur 500 après mise à jour de module.

Commencez donc par la liste des modifications récentes :

• module installé juste avant la panne ;
• module mis à jour partiellement ;
• changement manuel dans les fichiers du module ;
• combinaison de plusieurs modules qui touchent la même zone.

La méthode utile est simple : vérifiez la compatibilité annoncée, puis désactivez les modules récemment installés ou mis à jour un par un pour identifier le fautif. Si vous devez choisir un seul point de contrôle prioritaire après lecture des logs, commencez par le dernier module modifié. Pour éviter ce type de coupure en amont, vous pouvez aussi lire comment repérer un module PrestaShop mal codé avant installation.

Vider le cache proprement avant d’aller plus loin

Vider le cache peut suffire si la panne est apparue après une installation, une mise à jour ou une modification de code qui n’a pas été correctement prise en compte. PrestaShop recommande soit de supprimer le dossier ./var/cache/prod via FTP, soit de le faire depuis le back-office quand celui-ci reste accessible.

En revanche, n’en faites pas un réflexe universel. Si vos logs montrent clairement une incompatibilité PHP, une erreur mémoire ou une directive serveur invalide, vider le cache ne réglera pas la cause. Utilisez-le comme test ciblé, pas comme réponse automatique à toute 500.

Vérifier le socle serveur : .htaccess, version PHP, mémoire et permissions

Si la panne ne vient pas d’un module récent, remontez d’un cran : l’environnement d’exécution. C’est souvent là que se cachent les erreurs apparues après un changement d’hébergement ou de configuration serveur.

Contrôler le fichier .htaccess sans en faire une cause universelle

PrestaShop cite un .htaccess mal configuré parmi les causes possibles d’une erreur 500, notamment autour de la réécriture d’URL et des Friendly URLs. Mais ce contrôle n’est pertinent que si votre boutique tourne sur Apache. La documentation système de PrestaShop 9 rappelle en effet, au 20 octobre 2026, que PrestaShop peut fonctionner sur Apache ou sur Nginx.

Sur Apache, la syntaxe du .htaccess est stricte. Une directive non autorisée ou une erreur de syntaxe peut provoquer une 500, généralement visible dans l’error log. Si la panne est apparue juste après une modification de réécriture, un collage de règle ou une régénération hasardeuse, vérifiez ce fichier rapidement. Si vous êtes sur Nginx, ne perdez pas de temps sur ce point : cherchez plutôt la configuration serveur et les logs correspondants.

Comparer la version de PHP et la mémoire disponible avec les prérequis de PrestaShop

Un changement de version PHP peut casser une boutique qui fonctionnait la veille. C’est typiquement le cas après une modification d’hébergement, un basculement de version côté panel ou une montée de version sans vérification de compatibilité.

Selon les prérequis système de PrestaShop 9, au 20 octobre 2026, PrestaShop 9.0 supporte PHP 8.1 à 8.4. La branche 9.1 supporte PHP 8.1 à 8.5, avec PHP 8.5 recommandé pour 9.1. La même documentation recommande un memory_limit minimum de 512M.

Deux points pratiques :

• si la 500 est apparue juste après un changement PHP, comparez la version active avec celle attendue par votre version de PrestaShop ;
• si les logs parlent de mémoire épuisée ou si la panne survient sur des actions lourdes, contrôlez le memory_limit.

Ne mélangez pas les prérequis de PrestaShop 9 avec ceux d’une autre branche. Le bon diagnostic dépend de votre version réelle.

Vérifier les permissions sans ouvrir trop largement les droits

Le centre d’aide PrestaShop cite aussi les permissions incorrectes parmi les causes possibles d’une erreur 500. Le point important est de rester mesuré : des droits trop restrictifs bloquent l’exécution, mais des droits trop ouverts dégradent la sécurité.

Si la panne apparaît après un déploiement manuel, un transfert FTP, une migration ou une intervention sur les fichiers, comparez ce qui a changé. Et ne prenez pas chmod 777 comme correctif standard. Les permissions attendues dépendent du serveur et de sa configuration. Ici encore, le log serveur est souvent le meilleur arbitre.

Avancer dans le bon ordre selon la zone touchée

Vous n’avez pas besoin du même chemin de diagnostic selon que toute la boutique tombe ou qu’une seule action casse. Voici l’ordre le plus rentable pour éviter les détours.

Si toute la boutique renvoie une 500

Quand tout le site est touché, procédez dans cet ordre :

1. reproduire la panne et noter l’heure exacte ;
2. activer brièvement le mode debug pour faire ressortir le vrai message si possible ;
3. lire les logs PHP et serveur sur la même plage horaire ;
4. vérifier la dernière modification : module, mise à jour, changement PHP, intervention serveur ;
5. vider le cache seulement si le contexte s’y prête ;
6. contrôler ensuite .htaccess, version PHP, mémoire et permissions.

Ce qu’il faut éviter : restaurer une sauvegarde comme premier réflexe sans avoir identifié la cause. C’est un retour arrière lourd, pas un outil de diagnostic. Tant que vous n’avez pas un indice précis, concentrez-vous sur les logs et sur le dernier changement effectué.

Si seule une zone casse : back-office, fiche produit, panier ou checkout

Quand la 500 ne touche qu’une zone, le diagnostic devient plus rapide. Reproduisez exactement l’action qui casse, puis cherchez le log correspondant au même moment. Une 500 sur une fiche produit n’oriente pas vers les mêmes composants qu’une 500 au moment du paiement.

Quelques repères simples :

• back-office seulement : regardez en priorité les dernières modifications qui touchent l’administration, puis les logs au moment de la connexion ou de l’action bloquante ;
• fiche produit ou catégorie : remontez vers le module ou le code ajouté sur cette zone ;
• panier ou checkout : ciblez d’abord les modules et surcharges qui interviennent dans le tunnel, puis reproduisez le scénario complet.

Si l’erreur n’apparaît qu’au moment de commander, la coupure peut coûter immédiatement du chiffre d’affaires. Vous pouvez alors comparer vos symptômes avec la page dédiée au bug de panier ou de checkout PrestaShop.

Quand passer la main pour remettre la boutique en ligne sans aggraver la panne

Le bon moment pour arrêter les essais, c’est quand ils n’apportent plus d’information nouvelle. À partir de là, il vaut mieux transmettre un dossier propre que multiplier les tests risqués.

Les signaux qui justifient une intervention technique immédiate

Arrêtez les manipulations si vous êtes dans l’un de ces cas :

• toute la boutique renvoie une 500 ;
• le back-office est inaccessible et vous n’avez pas d’accès clair aux logs ;
• le panier ou le paiement casse ;
• la panne est apparue après un changement serveur ou PHP que vous ne maîtrisez pas ;
• vous avez déjà désactivé le dernier module modifié, vidé le cache et lu les logs sans comprendre la cause réelle ;
• vous commencez à tester au hasard.

À ce stade, le risque n’est plus seulement de perdre du temps. Vous pouvez aussi masquer la cause initiale, créer une deuxième panne ou retarder le retour à la normale.

La checklist minimale à transmettre pour gagner du temps

Si vous confiez le diagnostic, envoyez au minimum :

• la zone touchée : toute la boutique, front, back-office ou action précise ;
• l’URL ou l’étape exacte qui déclenche la 500 ;
• l’heure de reproduction de la panne ;
• la dernière modification faite avant l’incident ;
• le message remonté par le mode debug, si vous l’avez ;
• l’extrait utile des logs PHP et serveur ;
• votre version de PrestaShop et de PHP si vous les connaissez.

Avec ces éléments, le diagnostic démarre tout de suite dans le bon sens.

Si vous avez besoin d’une intervention, la page diagnostic et correction d’une erreur 500 PrestaShop présente le cadre d’intervention. Et si la boutique est coupée ou que le tunnel de commande est bloqué, vous pouvez aussi demander une prise en charge en urgence sur PrestaShop : diagnostic gratuit, réponse sous 24 h, devis sous 24 h ouvrées et tarif annoncé d’avance à 70 € HT/h.

Questions fréquentes

Comment activer le mode debug PrestaShop si le back-office est inaccessible ?

Si le back-office ne répond plus, vous pouvez activer le mode debug directement dans les fichiers de la boutique. La documentation PrestaShop 9 indique de passer la constante _PS_MODE_DEV_ à true dans /config/defines.inc.php. Faites-le uniquement le temps du diagnostic : le but est d’obtenir le vrai message d’erreur, puis de désactiver ce mode une fois l’analyse terminée.

Où trouver les logs utiles pour une erreur 500 : PrestaShop, PHP, Apache ou Nginx ?

Commencez par les logs qui correspondent à l’instant exact où vous reproduisez la panne. Les plus utiles sont les journaux PHP et ceux du serveur web, côté Apache ou Nginx selon votre hébergement. Si PrestaShop remonte aussi un message en mode debug, recoupez-le avec ces logs. Cherchez la première erreur exploitable : fichier, module, mémoire, syntaxe ou directive refusée.

Une erreur 500 peut-elle venir d’un module installé ou mis à jour juste avant ?

Oui. Le centre d’aide PrestaShop cite parmi les causes possibles une incompatibilité avec la version de PrestaShop, un conflit entre modules, un cache obsolète, un conflit de code ou une mise à jour incomplète. Le bon test consiste à repartir de la dernière modification faite, vérifier la compatibilité, puis désactiver les modules récemment installés ou mis à jour un par un.

Comment savoir si le fichier .htaccess est responsable de l’erreur 500 ?

Le .htaccess est une piste utile seulement si votre boutique tourne sur Apache. Sur ce serveur, une erreur de syntaxe ou une directive non autorisée peut déclencher une 500, généralement visible dans l’error log. Si vous êtes sur Nginx, ce fichier n’est pas le bon angle de recherche. Vérifiez donc d’abord votre type de serveur avant de passer du temps sur ce point.

La version de PHP peut-elle casser une boutique PrestaShop du jour au lendemain ?

Oui, surtout après un changement d’hébergement ou une modification de version côté serveur. Si votre boutique ou un module n’est pas compatible avec la version PHP active, une erreur 500 peut apparaître immédiatement. Au 20 octobre 2026, la documentation PrestaShop 9 indique que la branche 9.0 supporte PHP 8.1 à 8.4 et la branche 9.1 PHP 8.1 à 8.5.

Un manque de mémoire PHP (`memory_limit`) peut-il provoquer une erreur 500 ?

Oui. Si le processus manque de mémoire pendant une action lourde, la requête peut échouer et remonter une erreur 500. Le plus sûr est de le confirmer dans les logs ou avec le message obtenu en mode debug. Pour PrestaShop 9, la documentation officielle recommande un memory_limit minimum de 512M au 20 octobre 2026.