Une erreur 500 signifie que le serveur a bien reçu votre requête, mais que l’exécution du code PHP s’est interrompue avant de produire une page. Le message est volontairement muet : PrestaShop, en mode production, masque les détails techniques pour ne pas exposer votre infrastructure aux curieux.

La méthode tient en trois temps : on rend l’erreur visible (mode debug), on lit ce qu’elle raconte (logs applicatifs et serveur), on corrige la cause identifiée. Sauter la première étape et bricoler au hasard est le meilleur moyen de transformer une panne de dix minutes en week-end perdu.

Dans la pratique, l’écrasante majorité des erreurs 500 sur PrestaShop remonte à un module fraîchement installé ou mis à jour, à un changement de version PHP côté hébergeur, ou à un cache Symfony corrompu. Trois causes, trois corrections rapides.

L’erreur 500 (« Internal Server Error », parfois « HTTP ERROR 500 » selon le navigateur) est une erreur fatale PHP ou une directive serveur invalide. Le code s’est arrêté net.

La page blanche, l’écran totalement vide sans le moindre message, est presque toujours la même chose qu’une 500, à ceci près que l’affichage des erreurs est désactivé et que le serveur renvoie un code 200. Le traitement est identique : mode debug, puis logs.

L’erreur 503 signale un service temporairement indisponible : mode maintenance activé, PHP-FPM saturé, ou serveur en surcharge. Ce n’est pas un bug de code, c’est un problème de disponibilité ou de charge.

Une nuance à connaître si vous passez par Cloudflare ou un CDN : une erreur 520 ou 521 vient de l’intermédiaire, pas de votre boutique. Testez toujours en accédant au site en direct avant de chercher dans le code.

Un point que les guides techniques oublient systématiquement, et qui compte pour un e-commerçant. Googlebot interprète une erreur 500 comme un incident serveur temporaire : il réduit sa fréquence de crawl et repasse plus tard. Sur quelques heures, l’impact SEO est nul. Si la panne dure plusieurs jours, en revanche, les pages concernées commencent à sortir de l’index et le retour en position n’est pas instantané.

Traduction concrète : vous avez le droit de prendre trente minutes pour diagnostiquer proprement plutôt que de paniquer. Vous n’avez pas le droit de laisser traîner une semaine.

Ce classement suit l’ordre dans lequel nous testons en intervention : du plus fréquent et du plus rapide à vérifier, vers le plus rare et le plus lourd. Suivez-le dans l’ordre, vous éviterez de démonter votre serveur pour un module à cinquante euros.

C’est contre-intuitif quand le chiffre d’affaires s’arrête, mais une manipulation ratée sur une boutique en panne peut transformer une erreur 500 en perte de données. Copiez le dossier config/, le dossier override/ et exportez la base. Dix minutes, et vous travaillez sans filet en moins.

Si votre hébergeur propose des snapshots automatiques, notez l’horodatage de la dernière sauvegarde saine avant d’intervenir. C’est votre point de retour.

Une erreur 500 ne surgit jamais de nulle part. Il y a toujours un événement déclencheur, et il s’est produit dans les heures qui précèdent : installation de module, mise à jour PrestaShop, modification de thème, changement de version PHP, migration d’hébergement, import de catalogue, ou pic de trafic.

Reconstituez cette chronologie avant d’ouvrir un seul fichier. Dans la plupart des cas, elle vous donne directement le coupable, et les étapes suivantes ne servent qu’à le confirmer.

Tant que la boutique renvoie une erreur 500, chaque visiteur repart avec une mauvaise impression et chaque passage de Googlebot enregistre un incident. Si vous avez encore accès au back-office, activez le mode maintenance : PrestaShop renvoie alors un code 503 avec un message propre, ce que Google interprète correctement comme une indisponibilité temporaire.

Si le back-office est lui aussi hors service, un .htaccess de redirection vers une page statique fait l’affaire, à condition de ne pas oublier de le retirer après réparation.

Par défaut, PrestaShop masque le détail des erreurs en production. C’est un choix de sécurité parfaitement justifié : une stack trace expose vos chemins serveur, vos versions de bibliothèques et parfois vos identifiants. Mais tant qu’il est actif, vous cherchez une aiguille dans le noir.

Le mode debug bascule une constante, _PS_MODE_DEV_, de false à true. Le message générique laisse alors place au fichier fautif, au numéro de ligne et à la chaîne d’appels qui a mené à l’erreur.

Si l’administration répond, c’est la voie la plus sûre. Rendez-vous dans Paramètres avancés > Performances, section Mode debug, et basculez l’interrupteur sur Oui. Rechargez ensuite la page en erreur.

Si le back-office est bloqué, connectez-vous en FTP ou SSH et ouvrez le fichier config/defines.inc.php à la racine de votre boutique. Cherchez, généralement dans les trente premières lignes, la déclaration define('_PS_MODE_DEV_', false); puis remplacez false par true, enregistrez et rechargez la page en erreur.

Ce chemin est identique de PrestaShop 1.5 à PrestaShop 9. Sur une installation 1.4 ou antérieure (cela existe encore), le fichier concerné est config/config.inc.php.

Activer le debug sur une boutique en production, c’est afficher vos entrailles techniques à tous les visiteurs, y compris à ceux qui scannent le web à la recherche de sites vulnérables. La parade consiste à conditionner la constante à votre adresse IP : au lieu de false, écrivez $_SERVER['REMOTE_ADDR'] === '203.0.113.42' en remplaçant l’adresse par la vôtre. Un service comme « quelle est mon IP » vous la donne en une seconde.

Les visiteurs continuent de voir la page d’erreur générique, vous seul voyez la stack trace.

Soit le cache n’a pas été vidé et PrestaShop sert une page compilée antérieure : supprimez le contenu de var/cache/prod/ (PrestaShop 1.7 et supérieur) ou de cache/smarty/compile/ et cache/smarty/cache/ (PrestaShop 1.6).

Soit l’erreur se produit avant le chargement de defines.inc.php, typiquement une directive .htaccess invalide ou un problème de connexion à la base.

Soit votre hébergeur force display_errors à off au niveau serveur, et il faut alors passer par les logs. Dans ces trois cas, direction l’étape 2.

Le mode debug affiche l’erreur à l’écran. Les logs, eux, la conservent, y compris celles survenues cette nuit à trois heures pendant un cron d’import. Sur une panne intermittente, ils sont votre seule source fiable.

Sur PrestaShop 1.7, 8 et 9, tout se trouve dans var/logs/. Vous y verrez des fichiers nommés selon l’environnement et la date, du type prod-2026-08-06.log. Ouvrez le plus récent et allez directement à la fin : les dernières lignes correspondent à l’erreur que vous venez de déclencher en rechargeant la page. Sur PrestaShop 1.6, le dossier est simplement log/, avec des fichiers d’exception horodatés.

En SSH, tail -n 50 var/logs/prod-$(date +%Y-%m-%d).log vous affiche les cinquante dernières lignes.

Ce sont eux qui capturent les erreurs survenues avant que PrestaShop ne démarre : .htaccess invalide, PHP-FPM qui refuse de se lancer, extension manquante. Une erreur 500 absente des logs PrestaShop mais présente dans les logs serveur pointe presque toujours vers la configuration, pas vers le code.

Leur emplacement dépend entièrement de l’hébergeur. Sur un serveur dédié ou un VPS, le chemin classique est /var/log/apache2/error.log sous Apache, /var/log/nginx/error.log sous Nginx. Pensez aussi à /var/log/php8.x-fpm.log : les erreurs de démarrage de PHP-FPM n’apparaissent nulle part ailleurs.

Enfin, quel que soit l’hébergeur, certaines configurations déposent un fichier error_log directement dans le répertoire où l’erreur s’est produite. Cherchez-le à la racine du site et dans le dossier admin/.

Sur un hébergement mutualisé OVH. Connectez-vous en FTP : à la racine du compte, à côté du dossier www/, se trouve un dossier logs/. Il contient les journaux classés par mois, sous la forme <votredomaine>.log et surtout <votredomaine>-errors.log. C’est ce second fichier qui vous intéresse. Le même contenu est consultable depuis l’espace client OVH, rubrique Hébergements > Statistiques et logs, avec un accès sécurisé par mot de passe distinct de vos identifiants FTP.

Particularité OVH à connaître absolument : la version PHP n’est pas seulement définie dans l’espace client, elle peut être forcée par un fichier .ovhconfig placé à la racine du site, via la directive app.engine.version. Un fichier .ovhconfig oublié ou hérité d’une ancienne installation surcharge silencieusement le réglage du panneau. Nous avons vu plus d’une boutique rester bloquée sur une version PHP obsolète pour cette raison, alors que le client était persuadé d’avoir changé de version.

Sur un hébergement Infomaniak. Les journaux se consultent depuis le Manager, dans la section de votre hébergement web, rubrique Logs : erreurs et accès y sont téléchargeables directement. La version PHP se règle par site dans les paramètres avancés de l’hébergement, et non globalement. Un détail qui compte si vous hébergez plusieurs domaines sur la même offre, puisqu’un changement appliqué au mauvais site ne produira évidemment aucun effet sur la boutique en panne.

Le message d’erreur en tête, puis le fichier et la ligne concernés, puis la chaîne d’appels qui remonte jusqu’à l’origine. Vous cherchez deux choses : la nature de l’erreur, et un chemin de fichier contenant modules/ ou override/, parce que c’est là que se cachent 80 % des coupables.

Allowed memory size of X bytes exhausted : le script a dépassé la mémoire allouée. Cause n° 4.

Class 'X' not found ou Call to undefined method : un module appelle du code qui n’existe pas ou plus. Typiquement un module conçu pour PrestaShop 1.7 installé sur une version 8, ou l’inverse. Causes n° 1 et 6.

syntax error, unexpected... : du code PHP invalide. Soit un fichier corrompu pendant un transfert FTP, soit, bien plus fréquent, du code écrit pour une version PHP différente de celle qui tourne. Cause n° 2.

Cannot redeclare class : deux overrides déclarent la même classe. Deux modules se marchent dessus. Cause n° 6.

Invalid command 'php_value' dans les logs Apache : une directive PHP dans le .htaccess que le serveur refuse, cas classique quand l’hébergeur bascule de mod_php vers PHP-FPM. Cause n° 5.

SQLSTATE[HY000] [2002] ou Link to database cannot be established : la base ne répond pas ou les identifiants sont faux. Cause n° 10.

Uncaught Error: Call to undefined function intl_... : une extension PHP manque à l’appel. Cause n° 9.

C’est le suspect numéro un, et de loin. Un module mal codé, incompatible avec votre version de PrestaShop ou de PHP, suffit à mettre toute la boutique à terre. Le scénario type : vous installez ou mettez à jour un module, vous rechargez, écran d’erreur.

La correction. Connectez-vous en FTP, ouvrez modules/ et renommez le dossier du module suspect en lui ajoutant un suffixe, par exemple monmodule_off. PrestaShop ne le trouve plus et cesse de le charger. Videz ensuite var/cache/prod/ et rechargez.

Si vous ignorez quel module accuser, triez le dossier modules/ par date de modification : le plus récent est votre premier suspect. En SSH, ls -lt modules/ | head -20 vous le donne. Si la panne persiste, procédez par dichotomie : renommez modules/ entier en modules_off, créez un dossier modules/ vide, et vérifiez que le site remonte. Il ne remontera pas complètement, puisque PrestaShop a besoin de ses modules natifs, mais vous saurez si le problème vient bien de là. Réintroduisez ensuite les dossiers par moitiés successives.

Attention. Renommer un dossier ne désactive pas le module en base : PrestaShop le considère toujours comme actif. Une fois le site rétabli, désinstallez-le proprement depuis le back-office avant de supprimer les fichiers, sinon vous laissez des entrées orphelines dans la table ps_module et des hooks qui pointent dans le vide.

Deuxième cause la plus fréquente. Ce qui a changé, c’est la version PHP de votre serveur, modifiée par l’hébergeur au cours d’une maintenance ou par vous-même en cherchant à gagner en performance.

Chaque version de PrestaShop ne fonctionne que dans une plage PHP précise. PrestaShop 1.6 couvre PHP 5.4 à 7.1 ; les versions 1.7.0 à 1.7.6, de PHP 5.6 à 7.2 selon la sous-version ; la 1.7.7, de PHP 7.1 à 7.3 ; la 1.7.8, de PHP 7.1 à 7.4 ; les versions 8.0 et 8.1, de PHP 7.2.5 à 8.1 ; la 8.2, de PHP 8.1 à 8.2 ; et PrestaShop 9, de PHP 8.1 à 8.4.

PrestaShop 9, sorti en juin 2025, repose sur Symfony 6.4 LTS et réclame PHP 8.1 au minimum. À l’inverse, PrestaShop 1.7 plafonne à PHP 7.4 et ne peut pas fonctionner avec PHP 8.x. Le point est critique, puisque PHP 7.4 n’est plus maintenu depuis novembre 2022. Vérifiez toujours ces plages sur la documentation officielle avant une migration : elles évoluent avec les sous-versions.

La correction immédiate. Revenez à la version PHP qui fonctionnait. Chez OVH, cela se joue dans l’espace client Hébergements > Multisite, mais vérifiez d’abord qu’aucun fichier .ovhconfig à la racine ne surcharge ce réglage. Chez Infomaniak, la version se définit site par site dans les paramètres avancés. Sur un cPanel, la rubrique s’appelle « Select PHP Version ». Le site remonte en quelques secondes.

Si votre boutique tourne sous PrestaShop 1.7.8, vous êtes plafonné à PHP 7.4. Or PHP 7.4 n’a plus reçu le moindre correctif de sécurité depuis fin 2022. Le jour où votre hébergeur retire cette version de son catalogue, ce qui arrive sans préavis particulier, votre boutique tombe en erreur 500 et il n’existe aucun retour en arrière possible. Vous vous retrouvez alors à devoir migrer vers PrestaShop 8 dans l’urgence, boutique à l’arrêt, avec des modules à mettre à jour un par un. C’est le pire moment pour faire une migration, et c’est pourtant le scénario le plus courant que nous voyons arriver.

Si vous lisez ces lignes sans être en panne : vérifiez dès maintenant votre version dans Paramètres avancés > Informations. Une migration planifiée se mène en quelques jours sur un environnement de test. Une migration subie coûte plusieurs fois ce prix, en développement comme en chiffre d’affaires perdu.

Si vous êtes bloqué sur PHP 7.4 ou plus ancien, vous ne tournez pas seulement sur une configuration fragile : vous tournez sur une version PHP sans correctifs de sécurité depuis des années, sur un site qui traite des paiements. C’est un sujet de migration, pas de dépannage, et c’est exactement le genre de chantier que nous prenons en charge dans notre accompagnement PrestaShop.

Depuis PrestaShop 1.7, une partie du back-office et du routage repose sur Symfony, qui compile sa configuration dans un cache. Quand cette configuration change (mise à jour, nouveau module, changement de version PHP) et que le cache reste sur l’ancienne version, le décalage produit une erreur fatale.

La correction. En FTP, supprimez le dossier var/cache/prod/ dans son intégralité (le dossier prod, pas var/cache/ lui-même). PrestaShop le régénère à la requête suivante. En SSH, rm -rf var/cache/prod/* fait le travail.

Sur PrestaShop 1.6, l’équivalent consiste à vider cache/smarty/compile/ et cache/smarty/cache/, en conservant le fichier index.php de chaque dossier. Le premier chargement après purge sera lent, c’est normal : le cache se reconstruit.

Symptôme caractéristique : la régénération des vignettes, un import CSV volumineux, l’export de commandes, ou une page catégorie contenant des centaines de produits tombent en erreur, alors que le reste fonctionne. PrestaShop recommande d’allouer au minimum 256 Mo de mémoire par script. Beaucoup d’hébergements mutualisés livrent par défaut 128 Mo, voire 64.

La correction. Selon votre configuration, créez ou éditez un fichier .user.ini à la racine du site en y déclarant memory_limit = 512M et max_execution_time = 300. Sur un serveur avec php.ini accessible, modifiez-y directement les mêmes directives. Sur un mutualisé qui ne l’autorise pas, le panneau d’hébergement propose généralement ces réglages, ou il faut passer par le support.

Un avertissement : passer memory_limit à -1 ou à 4 Go n’est pas une solution, c’est un pansement. Si une page consomme 2 Go, il y a un module qui fuit ou une requête SQL non optimisée, et le problème reviendra avec les intérêts.

Le .htaccess est lu par Apache avant même que PHP ne démarre. Une seule directive qu’il ne comprend pas, et tout le site renvoie une 500, y compris les images et les fichiers CSS, ce qui est un excellent indice de diagnostic.

Le cas le plus courant : votre hébergeur bascule de mod_php vers PHP-FPM, et les directives php_value ou php_flag présentes dans le fichier deviennent illégales. Apache log alors Invalid command 'php_value'.

La correction. Renommez .htaccess en .htaccess_old et rechargez. Si le site remonte, vous tenez le coupable. Régénérez ensuite un fichier propre depuis le back-office : Paramètres de la boutique > SEO & URLs, puis enregistrez le formulaire sans rien modifier : PrestaShop réécrit le .htaccess à cette occasion.

Attention : si vous aviez des redirections 301 personnalisées dans l’ancien fichier, elles disparaissent. Ouvrez .htaccess_old et reportez-les manuellement à l’extérieur des blocs délimités par les commentaires de PrestaShop, qui sont écrasés à chaque régénération.

Le système d’override permet de modifier le comportement d’une classe PrestaShop sans toucher au cœur. Excellent principe, jusqu’au jour où deux modules décident de surcharger la même classe. PHP refuse alors de déclarer deux fois le même nom, et lève une erreur fatale.

La correction. Ouvrez le dossier override/ et repérez les fichiers récemment modifiés. Le message d’erreur vous indique généralement la classe concernée. Renommez ou déplacez le fichier fautif hors du dossier.

Point crucial que beaucoup oublient : PrestaShop maintient un index des overrides. Après toute modification du dossier, supprimez-le pour forcer sa reconstruction. Il se trouve dans var/cache/prod/class_index.php sur PrestaShop 1.7 et supérieur, dans cache/class_index.php sur PrestaShop 1.6. Sans cette suppression, votre correction ne prendra pas effet et vous conclurez à tort qu’elle n’a rien changé.

Après une restauration de sauvegarde, une migration de serveur ou un transfert FTP interrompu, les droits d’accès peuvent se retrouver dans un état que le serveur refuse. Apache et PHP-FPM rejettent notamment les fichiers accessibles en écriture à tous.

La correction. La règle est simple : 644 pour les fichiers, 755 pour les dossiers. En SSH, un find sur -type f avec -exec chmod 644, puis le même sur -type d avec -exec chmod 755, rétablissent l’ensemble en une passe.

Ne mettez jamais 777, sur aucun dossier, sous aucun prétexte. C’est un conseil qu’on lit encore sur des forums, et c’est une invitation ouverte à l’injection de fichiers malveillants. Sur une boutique qui manipule des paiements, le risque n’a aucune commune mesure avec le confort gagné.

Quand le disque est plein, PHP ne peut plus écrire ses fichiers de session ni son cache, et le serveur renvoie une 500. Indice révélateur : les logs eux-mêmes cessent de s’alimenter, ce qui rend le diagnostic déroutant.

La correction. Vérifiez l’espace disponible dans votre panneau d’hébergement, ou en SSH avec df -h. Les trois gisements classiques sur une boutique PrestaShop : le dossier var/logs/ quand personne n’a jamais fait de rotation, le dossier img/ rempli de vignettes de tous les formats jamais utilisés, et les sauvegardes générées depuis le back-office qui s’accumulent dans admin/backups/.

Une extension attendue par PrestaShop peut manquer à l’appel. Les indispensables sont intl, gd, curl, zip, mbstring, dom, fileinfo, iconv, simplexml, json, openssl et pdo_mysql.

La correction. Si le back-office répond, la page Paramètres avancés > Informations liste les extensions détectées et signale les manquantes. Sinon, déposez à la racine un fichier temporaire appelant phpinfo(), que vous supprimerez immédiatement après consultation, car il expose votre configuration serveur. L’activation se fait ensuite depuis le gestionnaire PHP de l’hébergement, ou via le support pour un mutualisé.

Plus rien ne répond, ni le front, ni le back, ni même l’installateur. Le message mentionne une connexion impossible ou un SQLSTATE.

La correction. Les identifiants se trouvent dans app/config/parameters.php sur PrestaShop 1.7 et supérieur, dans config/settings.inc.php sur PrestaShop 1.6. Vérifiez hôte, base, utilisateur et mot de passe contre ceux fournis par votre hébergeur. Ils changent lors d’une migration, et c’est le premier réflexe à avoir dans ce contexte.

Si les identifiants sont bons, le serveur MySQL est peut-être arrêté, ou vous avez atteint la limite de connexions simultanées de votre offre. Contactez l’hébergeur : ce n’est plus de votre ressort.