Erreur 500 PrestaShop : diagnostiquer et corriger la cause

Ce guide traite le diagnostic d’une erreur HTTP 500. Si la boutique ne répond pas du tout ou présente un problème DNS ou TLS, commencez par les vérifications d’un site PrestaShop inaccessible.

Une erreur 500 sur PrestaShop signifie que le serveur a reçu la requête, mais qu’il n’a pas pu terminer l’exécution de PHP ou de sa configuration web. Le navigateur n’affiche alors qu’une page blanche, un message « Internal Server Error » ou une erreur générique. Elle peut toucher la boutique, le tunnel de commande, le back-office ou seulement une fiche produit. La priorité est de récupérer le message d’erreur réel, puis d’isoler le dernier changement effectué : mise à jour, installation d’un module, changement de version PHP, modification du fichier .htaccess ou intervention de l’hébergeur.

Commencer par identifier le périmètre de la panne

Avant toute correction, vérifiez précisément les URL affectées, en navigation privée et connecté au back-office. Une erreur présente uniquement dans l’administration n’a pas les mêmes causes qu’une erreur sur toutes les pages. Testez notamment la page d’accueil, une catégorie, une fiche produit, le panier et l’URL réelle du dossier d’administration de votre installation.

• Toute la boutique est inaccessible : recherchez d’abord une incompatibilité PHP, un fichier .htaccess invalide, une erreur de droits ou une panne serveur.
• Une page ou une action précise échoue : un module, un override, un contrôleur ou un thème est plus probable.
• L’erreur apparaît après une mise à jour : revenez sur les extensions, le thème, la version PHP et les fichiers modifiés pendant l’opération.
• Seul le back-office répond en erreur 500 : vérifiez les modules d’administration, les droits sur les fichiers et les limites PHP.

Évitez de modifier plusieurs éléments à la fois. Faites une sauvegarde des fichiers et de la base de données avant chaque intervention, puis retestez après une seule action. Cette méthode permet de savoir quelle correction a réellement résolu l’incident.

Lire l’erreur détaillée sans l’exposer aux visiteurs

Consultez d’abord les journaux PHP et web dans le panneau de l’hébergeur. Relevez l’heure, l’URL et le message exact. Un dépassement de mémoire, une classe absente ou une méthode inconnue orientent le diagnostic, sans prouver à eux seuls quelle correction appliquer.

Si un débogage applicatif est nécessaire, reproduisez l’erreur sur une préproduction protégée par authentification. Le mode développement peut afficher des chemins et des requêtes : ne l’activez pas sur une boutique publique. Sur les branches concernées, le réglage se trouve dans les paramètres de performances ou dans config/defines.inc.php via _PS_MODE_DEV_. Suivez la documentation de votre version et rétablissez le mode production après le test.

Contrôler les règles .htaccess sans retirer les protections

Sur Apache ou LiteSpeed, une directive non autorisée ou une règle invalide peut provoquer une erreur 500. Sauvegardez le fichier, consultez la ligne signalée dans le journal et reproduisez la correction sur préproduction. Ne renommez pas globalement le fichier en production : il peut contenir les protections d’accès et les redirections de la boutique.

Si les règles générées par PrestaShop doivent être régénérées, conservez les règles personnalisées et faites valider le résultat par l’hébergeur. Sur Nginx, .htaccess n’est pas utilisé ; la configuration du serveur doit être examinée.

Contrôler la version et les limites PHP

PrestaShop est sensible à la compatibilité entre sa version, ses modules et la version de PHP. Une bascule PHP opérée dans le panneau d’hébergement peut rendre un ancien module incompatible, tandis qu’une version trop ancienne de PHP peut ne plus convenir à une version récente de PrestaShop. Consultez les prérequis correspondant exactement à votre branche PrestaShop avant de changer de version en production.

Testez la compatibilité PHP sur une préproduction. Consultez les paramètres effectifs dans le panneau de l’hébergeur, sans déposer de page phpinfo() accessible publiquement. Vérifiez ensuite les erreurs du front-office et de l’administration.

Mémoire, délai et extensions PHP

Une erreur 500 peut être causée par une mémoire PHP saturée durant la compilation du cache, l’import d’un catalogue, une génération d’images ou l’exécution d’un module lourd. Le journal peut afficher un dépassement de memory_limit. Recherchez d’abord une boucle ou un traitement anormal ; si les besoins sont légitimes, ajustez cette limite dans la configuration PHP de l’hébergement, si votre offre le permet, plutôt que dans un fichier applicatif qui pourrait être ignoré. Contrôlez aussi max_execution_time pour les traitements longs et les extensions nécessaires à votre installation, telles que PDO MySQL, cURL, ZIP, GD ou Imagick selon les fonctions utilisées.

Isoler un module, un thème ou un override défaillant

Les modules sont une cause fréquente lorsqu’une erreur 500 apparaît juste après une installation, une mise à jour ou l’activation d’une fonctionnalité. Si le back-office reste accessible, désactivez d’abord le dernier module modifié depuis le gestionnaire de modules. Videz ensuite le cache et retestez l’action qui échouait.

Si l’administration est indisponible, faites examiner le module cité dans les journaux sur une copie de la boutique. Renommer son dossier ne constitue pas une désinstallation propre et peut laisser des hooks ou des dépendances incohérents. Une intervention d’urgence doit être ciblée, sauvegardée et suivie d’une vérification du panier, du paiement et des commandes.

Les overrides peuvent également casser le chargement des classes après une mise à niveau. Vérifiez le dossier override/, notamment si l’erreur cite une classe du cœur ou une méthode absente. Désactivez temporairement l’override concerné sur une copie du site, puis reconstruisez le cache. Pour un problème lié à l’affichage, testez un thème natif compatible : une erreur Twig, Smarty ou un appel de variable inexistant dans un template peut ne toucher que certaines pages.

Vider le cache sans masquer la cause

Un cache compilé après une mise à jour incomplète peut contenir des classes ou templates obsolètes. Depuis le back-office, utilisez le bouton de vidage du cache dans les paramètres de performances. En cas d’accès impossible, la suppression du contenu des dossiers de cache peut être nécessaire, mais elle doit être faite avec prudence et jamais en supprimant les fichiers de protection du dossier. Selon la version, le cache se trouve notamment sous var/cache/.

Ne confondez pas cette opération avec la réparation d’une erreur de code : vider le cache peut révéler l’erreur au lieu de la résoudre. Après chaque essai, réactivez le mode production et vérifiez le panier, la connexion client, une commande test et les URLs réécrites.

Vérifier droits, propriété des fichiers et ressources serveur

Des permissions ou un propriétaire de fichiers incorrects empêchent PHP d’écrire dans les répertoires de cache, d’images ou de logs. Cela se produit souvent après une migration réalisée avec un autre compte système. Les valeurs habituelles sont 755 pour les dossiers et 644 pour les fichiers, mais l’hébergement peut imposer une configuration différente. N’appliquez pas 777 à l’ensemble de l’installation : cette pratique dégrade la sécurité et ne corrige pas une mauvaise propriété de fichiers.

Si les logs signalent une erreur de connexion MySQL, un processus PHP interrompu, un manque d’espace disque ou un quota dépassé, l’action relève souvent de l’hébergeur. Ouvrez un ticket en transmettant l’heure précise, l’URL, le code d’erreur, les extraits de logs et les changements récents. Demandez la vérification des limites de ressources, des erreurs PHP-FPM et des règles de sécurité serveur susceptibles de bloquer la requête.

Si le diagnostic demande une intervention sur la boutique, notre dépannage PrestaShop urgent permet de cadrer les vérifications nécessaires.