Erreur 500 PrestaShop : diagnostic pour non technicien

Vous ouvrez votre back-office un matin — ou pire, c’est un client qui vous prévient par téléphone — et tout ce que vous voyez, c’est un écran blanc avec la mention « Internal Server Error 500 ».

Pas de message explicite, pas de piste, juste un site à l’arrêt. Et pendant ce temps, les commandes ne rentrent plus. C’est le scénario le plus stressant pour un marchand en ligne.

Votre boutique n’est pas « morte » ! Elle est bloquée. Vos données — clients, commandes, catalogue — sont toujours là. C’est le mécanisme qui affiche vos pages qui coince, pas votre base de données.

Ce guide vous donne une méthode claire pour identifier la cause, sans avoir besoin d’être développeur. Et surtout, pour savoir à quel moment vous pouvez agir seul et à quel moment il vaut mieux passer le relais.

Sommaire

Comprendre l’erreur 500 PrestaShop : ce qu’elle signifie vraiment

Ce que le serveur essaie de vous dire

Quand vous tapez l’adresse de votre boutique, votre navigateur envoie une requête au serveur qui héberge votre site. Le serveur traite la demande, assemble la page et la renvoie. S’il n’y arrive pas, il envoie un code d’erreur à la place.

Le code 500 veut dire, en substance : « quelque chose a empêché le traitement de la page, mais je ne sais pas l’expliquer plus précisément ». C’est un message fourre-tout. Il ne vous dit pas ce qui a cassé — il vous dit juste que quelque chose a cassé côté serveur.

C’est précisément pour ça que l’erreur 500 est frustrante : elle ne pointe vers rien de concret. Mais ça veut aussi dire qu’il y a forcément une cause identifiable derrière. Il suffit de la chercher au bon endroit.

Pourquoi c’est plus grave sur un site e-commerce

Sur un blog personnel, une erreur 500 est embêtante. Sur une boutique PrestaShop, c’est une urgence commerciale. Tant que l’erreur est là, aucun visiteur ne peut consulter vos produits, ajouter au panier ou passer commande.

Le deuxième effet négatif, moins visible et encore plus coûteux : l’impact sur votre référencement naturel et vos publicités en cours.

Google a confirmé par la voix de John Mueller (Search Advocate chez Google) que des erreurs 500 persistantes entraînent d’abord un ralentissement de l’exploration du site par Googlebot, puis un retrait progressif des pages concernées de l’index. Concrètement, si votre boutique reste en erreur 500 pendant plusieurs heures, vos pages produits commencent à disparaître des résultats de recherche. Et récupérer ces positions prend bien plus de temps que les quelques heures d’indisponibilité.

Chaque heure compte en cas d’erreur 500 PrestaShop. D’où l’importance d’un diagnostic rapide.

Les 6 causes principales de l’erreur 500 PrestaShop — et laquelle est la vôtre ?

L’erreur 500 sur PrestaShop n’a pas une cause unique. Elle en a une demi-douzaine de récurrentes. Le tableau ci-dessous les classe par symptôme, parce que c’est par là qu’on commence : ce que vous observez sur votre écran.

Symptôme observé	Cause probable	Fréquence
Erreur 500 partout (front-office + back-office)	Version PHP incompatible, fichier .htaccess corrompu, ou base de données saturée	Très fréquent
Erreur 500 uniquement en back-office	Cache Symfony corrompu (dossier `/var/cache/`)	Fréquent sur PS 1.7, PS 8 et PS 9
Erreur 500 sur une seule page ou un seul type de page	Module défaillant ou conflit entre deux modules	Fréquent
Erreur 500 juste après une mise à jour PrestaShop	Modules devenus incompatibles avec la nouvelle version de PrestaShop	Fréquent
Erreur 500 intermittente (ça marche, puis ça plante, puis ça revient)	Mémoire PHP insuffisante, timeout du serveur, ou sessions saturées	Modéré ou progressif sur quelques mois
Erreur 500 sans aucune action de votre part	Montée de version PHP par l’hébergeur, sans prévenir	En forte hausse depuis 2025

Ce dernier cas mérite qu’on s’y attarde. Depuis fin 2024, de nombreux hébergeurs (OVH, o2switch, Ionos, Hostinger et d’autres) retirent progressivement PHP 7.4 et PHP 8.0 de leurs serveurs pour des raisons de sécurité. Si votre boutique tourne sur une version de PrestaShop qui ne supporte pas PHP 8.2 ou 8.3, le résultat est immédiat : erreur 500 ou page blanche, sans que vous ayez touché à quoi que ce soit.

Diagnostic en 3 questions : trouver la cause sans être développeur PrestaShop

Face à une erreur 500, la tentation est de toucher à tout — vider des caches au hasard, désactiver des modules sans méthode, relancer le serveur en espérant que ça passe. Ça fonctionne rarement, et ça complique souvent le diagnostic de l’expert PrestaShop par la suite. On vous le dit en connaissance de cause 😉

Voici les trois questions que nous posons systématiquement et dans cet ordre. Elles permettent de cerner l’origine du problème en quelques minutes.

Question 1 — Où l’erreur apparaît-elle exactement ?

C’est le premier filtre, et c’est celui que la plupart des marchants oublient.

L’erreur 500 ne se manifeste pas de la même façon selon qu’elle touche le front-office (ce que voient vos clients), le back-office (votre interface d’administration), ou les deux en même temps. Et chaque scénario pointe vers une famille de causes différente.

Si l’erreur touche uniquement le back-office — dans la majorité des cas, c’est un problème de cache Symfony. C’est le « classique » de PrestaShop 1.7 et des versions suivantes.

Si l’erreur touche uniquement le front-office — pensez d’abord à un conflit de module ou à un problème de thème. Le back-office, lui, utilise son propre jeu de fichiers.

Si l’erreur touche les deux — c’est un problème plus profond : version PHP, fichier .htaccess, base de données, ou configuration serveur.

Cette simple distinction réduit déjà le champ d’investigation de moitié.

Question 2 — Qu’est-ce qui a changé récemment ?

L’erreur 500 ne tombe presque jamais du ciel. Dans 90 % des cas, un événement l’a déclenchée. Passez en revue les derniers jours :

Avez-vous installé ou mis à jour un module ?
Avez-vous lancé une mise à jour de PrestaShop ?
Votre hébergeur a-t-il effectué une maintenance ou une mise à jour serveur ?
Avez-vous modifié un fichier manuellement (thème, .htaccess, configuration) ?

Si rien n’a changé de votre côté, la piste de l’hébergeur est la première à creuser. Connectez-vous à votre espace client (cPanel, Plesk, ou tableau de bord) et vérifiez la version PHP active. Comparez-la avec la version supportée par votre PrestaShop. Si elles ne correspondent plus, vous tenez probablement votre coupable.

Question 3 — Que dit le mode debug ?

Le mode debug, c’est un interrupteur intégré à PrestaShop qui remplace le message générique « Erreur 500 » par le vrai message d’erreur technique — le nom du fichier en cause, la ligne de code, la nature du problème.

Si vous avez accès au back-office : rendez-vous dans Paramètres avancés → Performance → Mode debug, passez-le sur « Oui », enregistrez, puis rechargez la page qui pose problème.

Si le back-office est lui-même en erreur 500 (ce qui arrive souvent), il faut passer par FTP :

Connectez-vous à votre serveur avec votre client FTP (FileZilla, par exemple)
Ouvrez le fichier config/defines.inc.php
Trouvez la ligne define('_PS_MODE_DEV_', false);
Remplacez false par true
Enregistrez et rechargez la page

💡 Bon à savoir : si votre boutique est en production et que vous ne voulez pas que vos clients voient les messages d’erreur techniques, vous pouvez restreindre l’affichage du debug à votre seule adresse IP. Remplacez la ligne par :

if ($_SERVER['REMOTE_ADDR'] === 'VOTRE_IP') {
    define('_PS_MODE_DEV_', true);
} else {
    define('_PS_MODE_DEV_', false);
}

Le message d’erreur qui s’affiche ensuite vous donne la piste. Vous n’avez pas besoin de le comprendre dans le détail — il suffit souvent de repérer un nom de module, le mot « cache », une mention de version PHP, ou une référence à une table de base de données pour orienter la suite.

Solutions selon votre cas

Maintenant que vous avez identifié la zone et la piste, voici les actions correctives pour les quatre cas les plus courants.

Cas 1 — Le cache Symfony est corrompu

Symptôme typique : erreur 500 en back-office, front-office qui fonctionne normalement.

C’est le grand classique des boutiques sous PrestaShop 1.7, 8 et 9. Le framework Symfony génère des fichiers de cache pour accélérer l’affichage du back-office. Il arrive que ces fichiers se corrompent — après une mise à jour interrompue, un pic de charge, ou parfois sans raison apparente. Le bug est même documenté sur le dépôt Github officiel des bogues de PrestaShop depuis la version 1.7.4.

La solution est simple et sans risque : supprimer le contenu des dossiers de cache via FTP.

Connectez-vous en FTP à votre serveur
Naviguez vers le dossier /var/cache/
Supprimez le contenu des sous-dossiers prod/ et dev/ (pas les dossiers eux-mêmes, juste leur contenu)
Rechargez le back-office

PrestaShop régénère automatiquement le cache au prochain chargement. Dans la plupart des cas, le back-office redevient accessible immédiatement.

⚠️ Attention : n’utilisez pas le bouton « Vider le cache » du back-office pour résoudre ce problème, car ce bouton peut lui-même déclencher une erreur 500 quand le cache est corrompu. Passez par FTP.

Cas 2 — Un module est en conflit

Symptôme typique : erreur 500 sur certaines pages, ou erreur 500 apparue juste après l’installation ou la mise à jour d’un module.

La méthode de diagnostic la plus fiable consiste à désactiver les modules un par un, en commençant par le dernier installé ou mis à jour. Et quand le back-office est inaccessible, la seule façon de le faire est de passer par FTP.

Connectez-vous en FTP
Naviguez vers le dossier /modules/
Renommez le dossier du module suspect (par exemple, renommez monmodule en monmodule_OFF)
Rechargez la page

Si l’erreur disparaît : coupable trouvé. Si elle persiste, remettez le nom d’origine et passez au module suivant.

⚠️ Attention : ne supprimez jamais un dossier de module pour faire un test. Le renommage suffit et il est réversible en deux secondes. Supprimer un module sans passer par le processus de désinstallation peut laisser des résidus en base de données et créer d’autres problèmes.

Pour aller plus loin sur ce sujet, consultez notre guide dédié aux conflits de modules PrestaShop.

Cas 3 — La version PHP a changé sans prévenir

Symptôme typique : erreur 500 soudaine sans aucune action de votre part, souvent accompagnée de mentions « deprecated » ou « Fatal error » dans le mode debug.

Chaque version de PrestaShop est conçue pour fonctionner avec des versions précises de PHP. Les incompatibilités les plus courantes en 2026 :

PrestaShop 1.6 ne fonctionne pas au-delà de PHP 7.2 (voire 7.4 avec des patchs)
PrestaShop 1.7 fonctionne avec PHP 7.2 à 8.1, selon la sous-version
PrestaShop 8.0-8.1 supporte PHP 8.1 à 8.2
PrestaShop 8.2 et 9.x supporte PHP 8.2 et 8.3

Solution d’urgence : connectez-vous au panel de votre hébergeur et rétrogradez la version PHP à celle qui était active avant le changement. Votre boutique devrait redémarrer immédiatement.

Solution durable : une rétrogradation PHP est un pansement temporaire. Les anciennes versions de PHP ne reçoivent plus de correctifs de sécurité. Il faut planifier une migration vers une version de PrestaShop compatible avec les versions PHP actuelles.

Cas 4 — La base de données étouffe

Symptôme typique : le site ralentit progressivement sur plusieurs semaines, puis finit par tomber en erreur 500. Le mode debug mentionne parfois « MySQL server has gone away » ou un timeout de requête.

PrestaShop enregistre par défaut chaque visite, chaque clic, chaque source de trafic dans sa base de données — via les tables ps_connections, ps_connections_source et ps_guest. Sur une boutique active depuis plus de deux ans, ces tables peuvent peser plusieurs gigaoctets. La base devient trop lourde pour le serveur MySQL, les requêtes mettent trop de temps, et le serveur renvoie une erreur 500.

Pour vérifier : ouvrez phpMyAdmin, sélectionnez votre base PrestaShop, et triez les tables par taille. Si ps_connections ou ps_guest pèsent plusieurs centaines de mégaoctets (voire plusieurs Go), vous tenez votre cause.

La correction consiste à vider ces tables avec un TRUNCATE — une opération qui supprime les données de statistiques sans toucher aux commandes, aux clients ou au catalogue.

Il est peut-être temps de passer sur un hébergement optimisé pour PrestaShop ou même dédié à votre site pour ne plus être pollué par vos colocataires de serveur mutualisé.

⚠️ Attention : faites toujours une sauvegarde complète de votre base de données avant toute manipulation SQL. Si vous n’êtes pas à l’aise avec phpMyAdmin, confiez cette opération à un technicien.

Comment éviter l’erreur 500 à l’avenir

La meilleure erreur 500 est celle qui n’arrive jamais. Voici les cinq réflexes de prévention les plus efficaces, classés par ordre de priorité :

Vérifiez la compatibilité PHP avant toute mise à jour. Consultez le tableau de compatibilité officiel PrestaShop/PHP et assurez-vous que vos modules supportent aussi la version cible.
Nettoyez les tables de statistiques tous les 3 mois. Configurez le module « Récupération des données statistiques » pour purger automatiquement les données au-delà de 90 jours. Ou mieux : déléguez vos statistiques à un outil externe comme Google Analytics ou Matomo.
Testez chaque module en staging avant la production. Un environnement de test (même basique) vous évite de découvrir un conflit de module en direct, devant vos clients.
Demandez à votre hébergeur de ne pas mettre à jour PHP sans prévenir. Certains hébergeurs permettent de fixer la version PHP. Activez cette option et gérez les montées de version à votre rythme.
Mettez en place des sauvegardes quotidiennes fichiers + base de données, avec une rétention d’au moins 30 jours. La sauvegarde de votre hébergeur ne suffit généralement pas — c’est un sujet qu’on détaille dans un guide dédié aux sauvegardes PrestaShop.

Si vous cherchez une vue d’ensemble sur les pannes les plus courantes et les bonnes pratiques de dépannage, consultez notre page dédiée au dépannage PrestaShop.

📊 Donnée terrain CYBERIAL : En 2025, sur 150 boutiques dépannées par notre équipe, l’erreur 500 était impliquée dans au moins 35 % des interventions d’urgence. Dans la grande majorité de ces cas, la cause a été identifiée en moins de 30 minutes avec la méthode décrite dans cet article — et la boutique remise en ligne dans les minutes suivantes.

Votre boutique affiche une erreur 500 en ce moment ? Notre équipe intervient 7 j / 7 pour diagnostiquer le problème et remettre votre site en ligne. Forfait dépannage PrestaShop à 150 €. Ligne directe 09 72 03 59 17.

👉 Demander un dépannage express →

Pour ne plus subir les pannes sans filet de sécurité : le forfait maintenance CYBERIAL à 69 € / mois inclut la surveillance quotidienne, les sauvegardes automatiques et l’intervention prioritaire en cas de problème.

👉 Découvrir le forfait maintenance →

Erreur 500 PrestaShop : diagnostic et solution