Erreur 500 PrestaShop : causes, diagnostic et solutions

Mis à jour le 29 juillet 2026

Les 3 réflexes avant d'intervenir

Avant de transformer une page blanche en panne irréversible, il y a trois points à sécuriser.

• 1. Faites une sauvegarde. Avant toute suppression, renommage ou modification, sauvegardez votre boutique Prestashop.
• 2. Ne réinstallez rien. Une erreur 500 ne nécessite quasiment jamais de réinstaller PrestaShop. Dans l'immense majorité des cas, la panne vient d'un élément identifiable et se corrige en quelques minutes.
• 3. Notez ce qui a changé. Un module installé, une mise à jour lancée, un mail de l'hébergeur, une modification de fichier : c'est l'information qui va faire gagner le plus de temps dans le diagnostic.

Qu'est-ce qu'une erreur 500 ?

Une erreur 500 signifie que le serveur a rencontré un problème qu'il ne sait pas expliquer. Contrairement à une 404 (page introuvable) ou une 403 (accès refusé), le message ne dit rien de la cause.

Sur Prestashop, elle se manifeste par une page blanche, une page d'erreur générique qui peut être sur le front, le back office ou sur les deux.

Trouvez votre cas en une question

Une seule question à vous poser : dans quelle situation êtes-vous ? Trouvez la ligne qui correspond, allez directement au cas indiqué. Si la solution proposée ne règle rien, revenez à ce tableau et passez à la ligne suivante qui vous ressemble.

Vous ne savez pas dans quelle situation vous êtes ? Le mode debug répond à la question en trente secondes : il affiche le fichier exact qui plante.

Activer le mode debug

Avant de chercher la cause, il faut rendre l'erreur lisible. Par défaut, PrestaShop masque les messages d'erreur PHP. Deux façons de l'activer, selon si votre back office est accessible ou non.

Via le back office (toutes versions, si le back office répond) :

• Allez dans Paramètres avancés > Performances > Mode debug
• Activez le mode debug et sauvegardez
• Rechargez la page en erreur : le message PHP s'affiche

Via FTP (si le back office lui-même est en 500) :

• Connectez-vous en FTP et ouvrez config/defines.inc.php
• Passez la constante suivante à true :

define('_PS_MODE_DEV_', true);

Dans les deux cas, le message d'erreur PHP complet s'affiche avec le fichier concerné, le numéro de ligne et la nature de l'erreur. C'est le point de départ de tout diagnostic sérieux.

Cas 1 : l'hébergeur a changé la version PHP

Symptôme : la boutique et le back office sont tombés en même temps, du jour au lendemain, sans que personne n'ait touché au site. C'est le scénario le plus déroutant, et celui qui progresse le plus vite depuis que les hébergeurs poussent d'office les montées de version PHP.

Pourquoi : votre hébergeur a basculé le serveur sur une version de PHP plus récente, et votre version de PrestaShop n'est pas compatible avec elle. Le code s'arrête en erreur fatale dès la première ligne incompatible. Les plages de compatibilité exactes sont détaillées dans l'article dédié à la compatibilité PrestaShop et versions PHP.

Correction :

• 1. Vérifiez quelle version PHP tourne réellement. Créez par FTP un fichier info.php à la racine du site contenant <?php phpinfo();, ouvrez https://votre-site.com/info.php : la version s'affiche en haut de page. Supprimez ce fichier immédiatement après, il expose votre configuration serveur.
• 2. Croisez cette version avec le tableau de compatibilité de votre version de PrestaShop.
• 3. Depuis le panel de votre hébergeur, repassez sur une version PHP compatible. Chez la plupart des hébergeurs mutualisés, le changement est immédiat et réversible.
• 4. Rechargez la boutique.

Si vous êtes en PrestaShop 1.6 et que votre hébergeur ne propose plus de version PHP assez ancienne, il n'y a pas de solution de contournement durable : c'est le signal qu'une migration vers PrestaShop 8 devient nécessaire. Rester sur une version PHP obsolète pour faire tourner une boutique en fin de vie est un risque de sécurité, pas une économie.

Ça n'a rien changé ? Passez au cas 4 (.htaccess), qui produit le même symptôme d'erreur sur tout le site.

Cas 2 : cache Symfony corrompu

Symptôme : le back office renvoie une erreur 500, mais la boutique côté client fonctionne normalement. Parfois l'inverse, ou seulement certaines pages d'administration.

Pourquoi : PrestaShop 1.7, 8 et 9 s'appuient sur Symfony, qui génère un cache compilé dans var/cache/. Après une mise à jour, un changement de configuration ou une écriture interrompue, ce cache peut se retrouver dans un état incohérent. PrestaShop 8 utilise Symfony 4.4 et PrestaShop 9 Symfony 6.4 : plus la version est récente, plus le cache est volumineux et sensible aux coupures d'écriture.

Correction :

• 1. Connectez-vous en FTP et ouvrez le dossier var/cache/.
• 2. Supprimez tout le contenu du dossier, sans supprimer le dossier lui-même.
• 3. Rechargez la page : PrestaShop régénère le cache automatiquement au premier chargement, qui sera un peu plus lent que d'habitude.

Si vous avez accès à la ligne de commande sur votre serveur, une commande suffit :

php bin/console cache:clear --env=prod

Sur PrestaShop 1.6, ce cas ne s'applique pas : la 1.6 n'utilise pas Symfony, son cache se trouve dans cache/smarty/. Attention également si votre hébergeur applique un quota d'inodes (nombre de fichiers) : un quota atteint empêche la régénération du cache et reproduit l'erreur en boucle.

Ça n'a rien changé ? Passez au cas 3 (module ou thème).

Cas 3 : module ou thème en conflit

Symptôme : l'erreur est apparue juste après l'installation ou la mise à jour d'un module, ou bien elle ne touche qu'un seul type de page (les fiches produit, les catégories, le panier) pendant que le reste du site fonctionne.

Pourquoi : un module mal codé, incompatible avec votre version de PHP, ou en conflit avec un autre module génère une erreur fatale au moment où PrestaShop l'exécute. Si le module ne s'accroche qu'à certaines pages, seules ces pages tombent, ce qui explique les erreurs 500 partielles.

Correction :

• 1. Activez le mode debug et lisez le chemin du fichier en erreur. S'il contient /modules/nom-du-module/ ou /themes/nom-du-theme/, le coupable est identifié.
• 2. Connectez-vous en FTP et renommez le dossier du module fautif, par exemple monmodule en monmodule_off. PrestaShop cesse alors de le charger, sans passer par le back office.
• 3. Rechargez la page. Si elle s'affiche, la cause est confirmée.
• 4. Si le debug ne désigne aucun module précis, renommez les modules un par un en commençant par le dernier installé ou mis à jour, en rechargeant la page après chaque essai.

Sur PrestaShop 1.7, 8 et 9, des modules conçus pour la 1.6 utilisent des hooks ou des classes qui n'existent plus. C'est pour cette raison qu'une montée de version s'accompagne très souvent d'une erreur 500 : ce n'est pas le cœur de PrestaShop qui casse, ce sont les modules restés en arrière.

Ça n'a rien changé ? Passez au cas 6 (overrides), qui produit un symptôme proche.

Cas 4 : fichier .htaccess corrompu

Symptôme : l'erreur 500 s'affiche instantanément sur tout le site, et le mode debug lui-même ne donne aucun détail. C'est le signe que le blocage a lieu avant même que PHP ne s'exécute.

Pourquoi : le fichier .htaccess à la racine gère la réécriture des URL et plusieurs directives de sécurité. S'il contient une directive incompatible avec la configuration Apache de votre hébergeur, le serveur refuse de traiter la requête et renvoie une 500 sèche.

Correction :

• 1. Par FTP, renommez .htaccess en .htaccess_bak.
• 2. Rechargez la page. Si elle s'affiche, même avec des URL sans réécriture, le .htaccess est bien en cause.
• 3. Régénérez-le proprement depuis le back office, dans Paramètres boutique > Trafic et SEO > Générer le fichier .htaccess.
• 4. Si le back office est inaccessible, récupérez le .htaccess par défaut de votre version depuis le dépôt GitHub officiel de PrestaShop.

Un piège fréquent lors des migrations : le format du .htaccess diffère entre les versions. La 1.6 utilise un mod_rewrite classique, tandis que les versions 1.7 et supérieures ajoutent des règles spécifiques au routing Symfony. Un .htaccess de 1.6 copié tel quel sur une 1.7 ou une 8 provoque systématiquement une erreur 500.

Ça n'a rien changé ? Passez au cas 7 (permissions).

Cas 5 : mémoire PHP ou timeout dépassé

Symptôme : l'erreur va et vient. Elle apparaît pendant un import de catalogue, une régénération de vignettes, une mise à jour en masse, ou aux heures de forte affluence, puis disparaît d'elle-même.

Pourquoi : chaque script PHP dispose d'une quantité de mémoire et d'un temps d'exécution limités par le serveur. Quand l'un des deux plafonds est atteint, PHP interrompt le script en erreur fatale, ce qui se traduit par une 500. Le caractère intermittent est la signature de ce cas : le problème n'apparaît que sur les opérations lourdes.

Correction :

• 1. Activez le mode debug. Le message est explicite : Fatal error: Allowed memory size of X bytes exhausted pour la mémoire, ou Maximum execution time exceeded pour le temps d'exécution.
• 2. Augmentez la limite mémoire dans votre php.ini, ou à défaut dans le .htaccess.
• 3. Relancez l'opération qui déclenchait l'erreur.

php_value memory_limit 512M
php_value max_execution_time 300

PrestaShop 8 recommande un minimum de 256 Mo de mémoire. Sur des catalogues volumineux, au-delà de 5 000 produits, 512 Mo est souvent nécessaire. Si votre hébergeur bloque ces valeurs et refuse de les augmenter, c'est que la formule d'hébergement est sous-dimensionnée pour votre catalogue.

Ça n'a rien changé ? Passez au cas 8 (base de données), qui produit aussi des erreurs intermittentes.

Cas 6 : override PHP corrompu

Symptôme : l'erreur est apparue juste après une mise à jour de PrestaShop, et le mode debug affiche un chemin de fichier contenant /override/.

Pourquoi : les overrides sont une spécificité de PrestaShop. Ils permettent de surcharger les classes et les contrôleurs du cœur sans modifier les fichiers d'origine. Le problème est qu'un override écrit pour une version donnée peut entrer en conflit avec le cœur après une mise à jour, ce qui déclenche une erreur fatale PHP. Les fichiers concernés se trouvent dans /override/classes/ et /override/controllers/, et leur index compilé est /cache/class_index.php.

Correction :

• 1. Par FTP, supprimez ou renommez le fichier cache/class_index.php. PrestaShop le régénère automatiquement au chargement suivant. Cette seule étape suffit dans une partie des cas.
• 2. Si l'erreur persiste, renommez tout le dossier override/ en override_off/ pour le neutraliser entièrement, puis rechargez.
• 3. Si la boutique repart, remettez les overrides un par un pour identifier celui qui pose problème.

Ce cas est particulièrement fréquent sur les boutiques PrestaShop 1.6 anciennes, qui ont accumulé des années d'overrides parfois écrits par des prestataires successifs et rarement documentés. Lors d'une migration vers PrestaShop 8, ces overrides doivent être réécrits et non recopiés.

Ça n'a rien changé ? Passez au cas 7 (permissions).

Cas 7 : permissions de fichiers incorrectes

Symptôme : l'erreur est apparue après une restauration de sauvegarde, un transfert FTP complet ou un changement d'hébergeur.

Pourquoi : PrestaShop a besoin d'écrire en permanence dans certains dossiers (cache, logs, images, fichiers envoyés). Si les permissions sont trop restrictives, il ne peut pas écrire et s'arrête en erreur. Un transfert FTP ou une restauration ne conservent pas toujours les permissions d'origine, ce qui explique que l'erreur apparaisse pile après ce type d'opération.

Correction :

• 1. Depuis votre client FTP, vérifiez les permissions des dossiers cache/, log/, img/, upload/, et var/cache/ sur les versions 1.7 et supérieures.
• 2. Appliquez 755 sur les dossiers et 644 sur les fichiers. La plupart des clients FTP proposent d'appliquer récursivement aux sous-dossiers.
• 3. Rechargez la page.

Si ces dossiers sont en 444 ou 555, PrestaShop est en lecture seule et ne peut pas fonctionner. À l'inverse, ne mettez jamais un dossier en 777 pour "régler" le problème : certains hébergeurs refusent d'exécuter des fichiers avec ces droits, et c'est une faille de sécurité connue.

Ça n'a rien changé ? Passez au cas 8 (base de données).

Cas 8 : base de données saturée

Symptôme : boutique ancienne, de plus en plus lente depuis des mois, avec des erreurs 500 qui apparaissent puis disparaissent, souvent aux heures de forte affluence.

Pourquoi : PrestaShop enregistre par défaut beaucoup de données de suivi : visites, sessions invité, recherches internes, logs. Sur une boutique qui tourne depuis plusieurs années sans entretien, ces tables peuvent atteindre plusieurs millions de lignes. Les requêtes deviennent alors si lentes qu'elles dépassent le temps d'exécution autorisé, ce qui produit une erreur 500 intermittente.

Correction :

• 1. Sauvegardez la base de données avant toute chose. Cette opération supprime des données de façon définitive. La méthode complète est détaillée dans le guide sur la sauvegarde d'une boutique Prestashop.
• 2. Ouvrez phpMyAdmin depuis votre panel hébergeur et triez les tables par taille pour repérer celles qui ont grossi anormalement.
• 3. Les tables de statistiques et de suivi sont les premières concernées : connections, connections_source, guest, statssearch, log, précédées du préfixe de votre boutique.
• 4. Videz ces tables de suivi, ou purgez les enregistrements les plus anciens. Elles ne contiennent ni commandes, ni clients, ni produits.

Une fois la base allégée, désactivez les modules de statistiques que vous n'utilisez pas dans le back office, sans quoi les tables se rempliront à nouveau. C'est aussi l'un des leviers classiques d'optimisation des performances Prestashop.

Si aucun cas ne correspond

Vous n'avez pas su dans quelle situation vous placer, ou vous avez essayé plusieurs cas sans succès. Reprenez alors la checklist complète, dans cet ordre précis. C'est la séquence que j'applique systématiquement, du plus probable au plus rare.

• 1. Activer le mode debug : lire le message d'erreur PHP exact. Sans ça, tout le reste est de la divination.
• 2. Vérifier la version PHP : consulter le panel hébergeur et croiser avec la table de compatibilité. Cause n°1 sur les hébergements mutualisés.
• 3. Vider le cache : var/cache/ sur 1.7 et supérieur, cache/smarty/ et cache/class_index.php sur 1.6.
• 4. Désactiver le dernier module installé ou mis à jour : renommer son dossier via FTP.
• 5. Vérifier le .htaccess : le renommer temporairement pour le neutraliser.
• 6. Vérifier les permissions : sur cache/, var/cache/, img/, upload/.
• 7. Vérifier les overrides : supprimer cache/class_index.php et tester.
• 8. Vérifier la mémoire PHP : augmenter memory_limit à 256 ou 512 Mo.
• 9. Vérifier la base de données : repérer les tables de suivi anormalement volumineuses.

Si l'erreur persiste après ces neuf points, le message de debug pointe vers un fichier du cœur de PrestaShop ou vers une configuration serveur spécifique. C'est à ce stade qu'intervenir seul devient risqué, surtout sur une boutique en production. Je vous accompagne en tant que consultant SEO spécialisé PrestaShop sur ces diagnostics techniques, avec plus de 30 boutiques accompagnées et 13 ans d'expérience sur la plateforme.

Éviter que ça se reproduise

Une erreur 500 est rarement un hasard. Dans la quasi-totalité des cas vus plus haut, elle vient d'un changement non anticipé. Cinq réflexes suffisent à faire disparaître la majorité de ces pannes.

• Sauvegardez avant chaque intervention. Avant d'installer un module, de lancer une mise à jour ou de modifier un fichier, une sauvegarde fichiers et base de données transforme une panne bloquante en simple retour en arrière.
• Testez les modules ailleurs qu'en production. Une copie de la boutique sur un sous-domaine permet d'installer et de vérifier un module sans risquer d'arrêter les ventes.
• Surveillez les annonces de votre hébergeur. Les montées de version PHP sont presque toujours annoncées par mail avant d'être appliquées. C'est l'information qui permet d'anticiper le cas 1 au lieu de le subir.
• Ne laissez pas votre version prendre du retard. Plus l'écart avec les versions supportées se creuse, plus les modules et les versions PHP disponibles deviennent incompatibles. Une migration vers PrestaShop 8 ou 9 planifiée coûte toujours moins cher qu'une migration dans l'urgence après une panne.
• Purgez régulièrement les tables de suivi. Quelques minutes par trimestre suffisent à éviter la saturation décrite au cas 8, et la boutique reste rapide.

Si vous devez intervenir sur la boutique et que l'opération est risquée, passez-la en mode maintenance le temps des manipulations : vos visiteurs verront une page d'attente propre plutôt qu'une erreur serveur.