Erreur 500 après une mise à jour PrestaShop : trouver la vraie cause

Vous venez de mettre à jour PrestaShop, un module, votre thème ou la version de PHP de l'hébergement, et la boutique ne répond plus. Enchaîner les solutions glanées sur les forums fait perdre des heures et ajoute parfois une seconde panne à la première. Une erreur 500 n'est pas une cause : c'est le code HTTP que renvoie le serveur quand PHP a planté. La cause est écrite quelque part : lisez-la avant d'agir.

Le symptôme, sous ses différentes formes

Selon l'endroit où PHP s'arrête, vous verrez :

• une page blanche, sans aucun texte ;
• la page « 500 Internal Server Error » du serveur web ;
• côté boutique, une page grise titrée « 500 Server Error » avec le message « Oops, something went wrong. » : c'est le fichier error500.html livré à la racine de PrestaShop, affiché quand une exception survient hors mode debug ;
• côté back-office, une page « Oops… looks like an unexpected error occurred » (traduite selon la langue de votre back-office) sur les pages construites avec Symfony.

Les déclencheurs habituels : mise à jour du cœur avec le module autoupgrade (« 1-Click Upgrade », renommé « Update Assistant » dans ses versions récentes), mise à jour d'un module ou du thème, ou changement de version de PHP par vous ou par votre hébergeur.

Avant tout : une sauvegarde de l'état actuel

Même en panne, la boutique contient des commandes et des clients. Sauvegardez la base de données et les fichiers dans leur état actuel. Si vous disposez d'une sauvegarde automatique quotidienne antérieure à la mise à jour, repérez-la : c'est votre plan de repli. Le détail de la procédure est dans notre guide sauvegarder sa boutique avant une intervention.

Étape 1 : lire l'erreur réelle

Activer le mode debug

Le mode debug fait afficher le message PHP complet au lieu de la page générique. Par FTP, ouvrez config/defines.inc.php et passez la constante à true :

// config/defines.inc.php
if (!defined('_PS_MODE_DEV_')) {
    define('_PS_MODE_DEV_', true);
}

Ce chemin et ce nom de constante sont identiques en 1.7.8, 8 et 9. Écrivez true et non 1, et vérifiez qu'un fichier config/defines_custom.inc.php n'impose pas une autre valeur. Tous les détails, y compris le mode debug limité à un cookie de PrestaShop 9, sont dans notre article activer le mode debug et lire les journaux.

Ouvrir les journaux de PrestaShop

Depuis la 1.7.4, les journaux sont dans var/logs/ (en 1.7.0 à 1.7.3, ils étaient dans app/logs/). Deux familles de fichiers vous intéressent :

Fichier	Versions	Contenu
var/logs/AAAAMMJJ_exception.log	1.7.4 et suivantes	chaque exception PrestaShop, avec ou sans mode debug
var/logs/prod.log / dev.log	1.7.8	journal Symfony, sans rotation
var/logs/prod-AAAA-MM-JJ.log / dev-AAAA-MM-JJ.log	8 et 9	journal Symfony, un fichier par jour, 30 conservés par défaut

En SSH, depuis la racine de la boutique :

# racine de la boutique
ls -lt var/logs/ | head
tail -n 40 var/logs/$(date +%Y%m%d)_exception.log

Consulter le journal du serveur

Certaines erreurs surviennent avant que PrestaShop ait chargé son propre système de journalisation : version de PHP incompatible, mémoire épuisée, erreur de syntaxe dans un fichier PHP. Elles n'apparaissent que dans le journal d'erreurs du serveur. Son emplacement dépend de l'hébergement : rubrique « Logs » ou « Journaux » de l'espace client, Plesk, cPanel ou Virtualmin, fichier error_log à la racine du site, ou, sur un serveur que vous administrez, les journaux d'Apache, de Nginx ou de PHP-FPM (le gestionnaire de processus PHP). À défaut, demandez-le à votre hébergeur.

Dans tous les cas, lisez la première erreur de la série et repérez le fichier en cause. Un chemin en modules/ désigne un module, override/ une surcharge, themes/ le thème, vendor/, classes/ ou src/ le cœur.

Étape 2 : remonter à la cause

Une version de PHP incompatible

Première cause après un changement de PHP, fréquente aussi après une mise à jour du cœur. Compatibilités officielles :

PrestaShop	PHP pris en charge	PHP recommandé
1.7.8	7.1 à 7.4	7.4
8.0, 8.1, 8.2	7.2 à 8.1	8.1
9.0	8.1 à 8.4	8.4
9.1	8.1 à 8.5	8.5

La 9.2, sortie fin septembre 2026, n'a pas encore sa ligne dans la documentation officielle au moment où nous écrivons : vérifiez-la avant de changer de PHP.

Une boutique 1.7.8 passée en PHP 8 ou une 8.x passée en PHP 8.2 sort de ce cadre : revenez à une version prise en charge dans le panneau de l'hébergeur. Attention, certains hébergeurs ont une version de PHP différente pour la ligne de commande (CLI, command line interface) et pour le site.

Un cache non régénéré

Après une mise à jour, le cache peut contenir du code compilé pour l'ancienne version : conteneur Symfony, templates Smarty, index des classes. Notre méthode : supprimer le dossier cache situé dans var/, que PrestaShop reconstruit à la requête suivante.

# racine de la boutique
rm -rf var/cache/*

Les autres caches à purger sont décrits dans vider vraiment tous les caches.

Un module incompatible

Si l'erreur pointe vers modules/nom_du_module/, désactivez ce module sans passer par le back-office en renommant son dossier, par exemple nom_du_module en nom_du_module.off. PrestaShop vérifie la présence du fichier principal du module avant de le charger : un dossier introuvable est ignoré. Videz ensuite var/cache/. Ses données restent en base ; rétablissez le nom une fois une version compatible disponible. Limite : si le module a installé un override, celui-ci reste actif.

Un override cassé

Les overrides (surcharges de classes du cœur, dans override/) cassent souvent lors d'une mise à jour, car la méthode surchargée a changé. Supprimez d'abord var/cache/prod/class_index.php (et var/cache/dev/class_index.php), l'index que PrestaShop reconstruit en parcourant override/. Si le back-office répond, l'option « Désactiver tous les overrides » du bloc Mode debug de Paramètres avancés > Performances permet de confirmer le diagnostic. Corrigez ensuite l'override en cause plutôt que de les laisser tous désactivés.

Mémoire ou temps d'exécution insuffisants

Les messages Allowed memory size … exhausted ou Maximum execution time … exceeded sont sans ambiguïté. La documentation officielle recommande un memory_limit d'au moins 256M en 1.7 et 8, et 512M en 9. Le max_execution_time n'a pas de valeur officielle ; il se règle chez l'hébergeur, comme la mémoire.

Droits de fichiers

Permission denied ou failed to open stream sur un fichier de var/ signifie que PHP ne peut pas écrire. Les dossiers qu'il doit pouvoir modifier incluent notamment var/cache, var/logs, img, modules, translations, upload, download, config et app/config. Cas typique : des fichiers copiés sous un autre utilisateur système que celui de PHP.

Un .htaccess à régénérer

Si seules certaines URL renvoient une erreur, ou si le serveur signale une directive invalide, le fichier .htaccess (configuration Apache à la racine) est en cause. Renommez-le, puis enregistrez la page des réglages d'URL du back-office : PrestaShop le régénère.

Une mise à jour incomplète

Class "…" not found ou failed opening required sur un fichier du cœur indiquent souvent une copie interrompue. Comparez l'arborescence avec l'archive officielle de la même version, téléchargée depuis le dépôt GitHub de PrestaShop, et recopiez uniquement les fichiers manquants du cœur, sans écraser config/, app/config/parameters.php, img/, vos modules et votre thème.

Le tableau de diagnostic

Message dans le journal	Cause probable	Que faire
Parse error: syntax error, unexpected …, Call to undefined function …	version de PHP non prise en charge ou extension PHP manquante	revenir à une version de PHP prise en charge, vérifier les extensions
Declaration of … must be compatible with … dans override/	override incompatible	supprimer class_index.php, corriger l'override
erreur dans modules/xxx/	module incompatible	renommer le dossier, vider var/cache/
ServiceNotFoundException, erreur dans var/cache/	cache obsolète	supprimer le contenu de var/cache/
Allowed memory size … exhausted	mémoire PHP	augmenter memory_limit
Maximum execution time … exceeded	délai PHP	augmenter max_execution_time
Permission denied, failed to open stream	droits	rendre le dossier inscriptible par PHP
Class "…" not found dans classes/ ou src/	fichiers manquants	comparer avec l'archive officielle
Invalid command ou RewriteRule dans le journal Apache	.htaccess	le régénérer

Après la correction

1. Repassez _PS_MODE_DEV_ à false.
2. Videz de nouveau var/cache/.
3. Testez la page d'accueil, une catégorie, une fiche produit, le panier, puis plusieurs pages du back-office.
4. Passez une commande test complète, jusqu'à l'e-mail de confirmation.
5. Relisez var/logs/ le lendemain : une erreur qui ne bloque plus l'affichage peut subsister.

Les pièges à éviter

• Laisser le mode debug actif en production : vos visiteurs voient des chemins de fichiers et des requêtes SQL, et la boutique ralentit.
• Intervenir sans sauvegarde de la base et des fichiers : une correction ratée sur une boutique déjà en panne est très difficile à rattraper.
• Réinstaller par-dessus à l'aveugle : recopier une archive complète écrase vos réglages, peut mélanger deux versions et masque la cause au lieu de la traiter.
• Changer plusieurs choses à la fois : une modification, un test, sinon vous ne saurez pas laquelle a agi.