Erreur 500 sur PrestaShop : diagnostiquer et corriger votre boutique

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 /admin 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.

Afficher l’erreur détaillée sans exposer la boutique

Le code HTTP 500 ne donne pas sa cause. Sur PrestaShop, le mode débogage permet généralement d’afficher l’exception PHP, le fichier concerné et la ligne en cause. Sur une installation PrestaShop 1.7 ou 8 accessible, activez-le depuis Paramètres avancés > Performances > Mode débogage. Désactivez-le dès la fin du diagnostic : les messages détaillés peuvent révéler des chemins de serveur, des requêtes SQL ou des informations techniques.

Si le back-office est inaccessible, modifiez le fichier config/defines.inc.php via SFTP ou le gestionnaire de fichiers de l’hébergeur. Repérez la ligne suivante :

define('_PS_MODE_DEV_', false);

et remplacez false par true. Rechargez ensuite la page concernée. Une erreur telle que Allowed memory size exhausted indique une limite de mémoire PHP insuffisante. Un message Class not found, Call to undefined method ou une erreur dans le dossier d’un module oriente vers un code incompatible ou incomplet.

Consultez aussi les journaux d’erreurs : le panneau d’hébergement, les fichiers error_log, et, selon la configuration, les logs PHP-FPM ou Apache/Nginx. Relevez l’horodatage, l’URL appelée et le chemin du fichier signalé. Ces éléments sont beaucoup plus exploitables pour un prestataire ou un hébergeur qu’une simple capture de la page 500.

Régénérer un fichier .htaccess défectueux

Un fichier .htaccess incorrect peut provoquer immédiatement une erreur 500 sur un serveur Apache ou LiteSpeed. Cela arrive après un transfert de site, une modification manuelle de règles de réécriture, l’installation d’un module SEO ou l’activation forcée de directives non autorisées par l’hébergeur.

1. Téléchargez une copie du fichier .htaccess situé à la racine de PrestaShop.
2. Renommez-le temporairement en .htaccess.old.
3. Testez la boutique. Si elle répond à nouveau, le fichier était impliqué.
4. Dans le back-office, allez dans Paramètres de la boutique > Trafic & SEO, puis enregistrez les réglages pour régénérer les règles d’URL simplifiées.

Si vous utilisez des redirections personnalisées, des règles de sécurité ou des ajustements de cache dans ce fichier, réintroduisez-les une par une après la régénération. Ne copiez pas un .htaccess trouvé sur un autre site : les règles peuvent dépendre de la version de PrestaShop, du sous-dossier d’installation et du serveur web. Sur Nginx, le fichier .htaccess n’est pas lu ; il faut alors contrôler la configuration Nginx auprès de l’hébergeur.

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.

Effectuez le test sur un environnement de préproduction quand c’est possible. Après un changement PHP, videz le cache de PrestaShop et surveillez les erreurs sur le front-office comme dans le back-office. Vérifiez également les paramètres effectifs avec un fichier phpinfo() temporaire, à supprimer immédiatement après usage, ou avec les informations fournies par l’hébergeur.

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. Augmentez alors 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, renommez via SFTP le dossier du module suspect dans modules/, par exemple modules/monmodule en modules/monmodule.disabled. Ne supprimez pas son dossier sans sauvegarde : vous risqueriez de perdre des fichiers nécessaires à une désinstallation propre. Si la boutique revient, restaurez le module dans une version compatible avec votre version de PrestaShop et de PHP, ou contactez son éditeur avec le message d’erreur exact.

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.