Erreur 500 PrestaShop : que vérifier avant de paniquer ?

Voir une erreur 500 s’afficher à la place de sa boutique, c’est l’un des moments les plus stressants pour un e-commerçant. Plus de page d’accueil, plus de catalogue, parfois même plus d’accès au back-office. Et le plus déroutant : aucune explication. Juste un message générique, « Erreur 500 » ou « Internal Server Error ».

La première chose à comprendre, c’est que l’erreur 500 ne vous dit pas ce qui ne va pas. Ce n’est pas un diagnostic, c’est un symptôme. Le serveur a rencontré un problème qui l’empêche de répondre, mais le détail — celui qui permet vraiment de corriger — est ailleurs.

La bonne nouvelle, c’est qu’une 500 est souvent réparable rapidement quand on procède dans le bon ordre. La mauvaise, c’est qu’en paniquant et en multipliant les manipulations à l’aveugle, on transforme souvent un petit incident en gros problème.

Une erreur 500, ça veut dire quoi exactement ?

Une erreur 500 est une erreur côté serveur. Concrètement, PHP a tenté d’exécuter le code de votre boutique et s’est arrêté en cours de route : une exception non gérée, un fichier manquant, une incompatibilité, un dépassement de mémoire, une configuration invalide.

Ce qui s’affiche à l’écran est volontairement vague. En production, PrestaShop et le serveur masquent les détails techniques pour ne pas exposer d’informations sensibles aux visiteurs. C’est une bonne chose pour la sécurité, mais ça explique pourquoi vous ne voyez « rien ».

Le vrai message, lui, existe. Il est simplement écrit ailleurs : dans les journaux. Et c’est là que commence tout diagnostic sérieux.

Le premier réflexe : retrouver le vrai message d’erreur

Avant de toucher quoi que ce soit, l’objectif est de lire le message réel derrière la 500. Trois endroits à regarder :

• Les logs PrestaShop : le dossier var/logs/ contient les erreurs applicatives récentes. C’est souvent le premier indice exploitable.
• Les logs du serveur : les journaux Apache/Nginx et surtout le log d’erreurs PHP. C’est là qu’apparaît la ligne exacte, le fichier et la nature de l’erreur (mémoire, classe introuvable, syntaxe…).
• Le mode debug PrestaShop : activer temporairement le mode développeur affiche l’erreur complète à l’écran. C’est très efficace, mais à manier avec précaution sur une boutique en ligne — on l’active le temps du diagnostic, jamais en permanence en production.

Selon votre version de PrestaShop et votre hébergement, le message utile peut se trouver côté PrestaShop (dans var/logs/) ou côté hébergeur (logs PHP, Apache ou Nginx) — souvent, il faut regarder les deux. Tant qu’on n’a pas ce message précis, on travaille à l’aveugle. Avec lui, la cause saute souvent aux yeux en quelques minutes.

Les causes les plus fréquentes sur PrestaShop

Sur le terrain, la grande majorité des erreurs 500 sur PrestaShop tournent autour de quelques causes récurrentes :

• Un module récemment installé ou mis à jour. C’est un cas très fréquent. Un module mal codé, incompatible avec votre version ou en conflit avec un autre, et toute la boutique tombe.
• Un problème de version ou de configuration PHP. Une boutique qui change d’hébergement ou dont le PHP est mis à jour peut casser si le code n’est plus compatible, si une extension manque ou si la limite de mémoire est trop basse.
• Le cache et les classes compilées. PrestaShop met en cache du code généré dans var/cache/. Quand ce cache se retrouve dans un état incohérent (après une modification, une migration partielle, un déploiement interrompu), il peut provoquer une 500. Le vider règle une partie des cas.
• Un .htaccess corrompu ou une règle invalide. Une directive en trop, une réécriture d’URL mal formée, et le serveur refuse de répondre.
• Des droits de fichiers incorrects. Après une copie, une restauration ou une intervention FTP, des permissions mal réglées peuvent empêcher l’exécution.
• Une surcharge (override) fautive. Un override laissé en place, devenu incompatible après une mise à jour, est un classique des boutiques qui ont vécu.
• La base de données. Connexion impossible, identifiants changés, table corrompue : le code ne peut plus tourner et renvoie une 500.

L’erreur exacte lue dans les logs vous dira laquelle de ces pistes suivre. C’est tout l’intérêt de ne pas sauter cette étape.

Erreur 500 sur tout le site, ou seulement le back-office ?

Un détail qui oriente beaucoup le diagnostic : où apparaît l’erreur.

• Sur tout le site (front + back-office) : la cause est souvent globale — PHP, base de données, .htaccess, mémoire, un composant chargé partout.
• Uniquement sur le back-office, le front restant accessible : on regarde plutôt du côté d’un module d’administration, d’un onglet spécifique, d’un cache d’admin ou d’un droit particulier.
• Uniquement sur certaines pages (une fiche produit, une catégorie, le tunnel de commande) : la piste se resserre sur la fonctionnalité concernée et les modules qui s’y greffent.

Plus vous délimitez précisément où ça casse, plus vite vous trouvez la cause.

Ce qu’il ne faut surtout pas faire

Quand une boutique est à l’arrêt, l’urgence pousse à agir vite. C’est justement là que beaucoup de situations s’aggravent. Quelques règles simples :

• Ne pas enchaîner les manipulations au hasard. Désactiver des modules un par un en aveugle, modifier des fichiers sans savoir pourquoi, tout cela brouille les pistes et peut créer de nouveaux problèmes.
• Toujours sauvegarder avant de modifier. Avant de toucher au .htaccess, à un fichier de configuration ou à la base, on garde une copie. C’est ce qui permet de revenir en arrière proprement.
• Ne pas laisser le mode debug actif en production. Le temps du diagnostic, oui. Une fois le problème compris, on le désactive immédiatement.
• Ne pas réinstaller ou « mettre à jour pour voir ». Sur une boutique en production, une réinstallation ou une montée de version improvisée en pleine panne est le meilleur moyen de transformer une 500 en sinistre.

Quand il vaut mieux passer la main

Si la boutique est à l’arrêt, que les ventes s’arrêtent avec elle et que les logs pointent vers quelque chose que vous ne maîtrisez pas, ce n’est pas le moment d’expérimenter. Une erreur 500 sur une boutique en production est exactement le type de bug bloquant où un dépannage PrestaShop urgent fait gagner un temps précieux : retrouver le vrai message, identifier la cause, corriger proprement et remettre la boutique en ligne sans casser autre chose au passage.

L’objectif n’est pas seulement de « faire repartir le site ». C’est de comprendre pourquoi il est tombé, pour que ça ne recommence pas à la prochaine mise à jour.

Questions fréquentes

Comment voir le vrai message derrière une erreur 500 ? En consultant les logs : var/logs/ côté PrestaShop, et surtout le log d’erreurs PHP et serveur. Le mode debug PrestaShop affiche aussi l’erreur complète, à activer uniquement le temps du diagnostic.

J’ai une erreur 500 juste après avoir installé ou mis à jour un module. C’est la cause la plus fréquente. Le module est probablement incompatible ou en conflit. La priorité est de retrouver l’erreur dans les logs pour confirmer, puis de neutraliser proprement le module en cause, idéalement après une sauvegarde.

L’erreur 500 n’apparaît que sur le back-office, est-ce grave ? Pas forcément. Si le front fonctionne, la cause est souvent localisée (module d’administration, cache d’admin, droit particulier). Le diagnostic est généralement plus simple, mais il faut quand même identifier la source pour éviter que ça s’étende.

Faut-il réinstaller PrestaShop pour régler une erreur 500 ? Non, presque jamais. Une 500 est un symptôme à diagnostiquer, pas une raison de réinstaller. Dans l’immense majorité des cas, la cause est précise et se corrige sans toucher au cœur de la boutique.

Votre boutique est bloquée par une erreur 500 ?

Si votre PrestaShop est à l’arrêt et que vous préférez ne pas tâtonner en pleine panne, mieux vaut un diagnostic rapide et méthodique. L’idée est simple : retrouver la cause réelle, corriger proprement et sécuriser la suite.

Décrire mon problème →