Mode debug PrestaShop 1.6 à 9 : activer, lire l'erreur, désactiver

Q: Le mode debug n'affiche rien, où chercher ?

Dans les journaux de var/logs/, puis dans le journal d'erreurs PHP de l'hébergeur. Une erreur qui se produit très tôt, comme une version de PHP incompatible, n'apparaît que dans ce dernier.

Mis à jour le 1er novembre 2026. Ce guide regroupe désormais notre article « Débogage PrestaShop 8 et 9 ». Corrections : le mode debug de PrestaShop 1.7 ne passe pas par un fichier .env, les journaux de PrestaShop 9 sont découpés par jour, et une ligne php_value dans le .htaccess peut elle-même casser la boutique. Commandes et chemins vérifiés sur PrestaShop 9.2.

Page blanche, erreur 500 sans message, module qui casse une page : le mode debug est le premier réflexe, car il affiche l’erreur exacte que PrestaShop masque d’habitude. Il doit rester temporaire : il affiche aux visiteurs des chemins de fichiers et des détails techniques utiles à un attaquant, et ralentit nettement la boutique.

Faites le diagnostic sur une copie de la boutique quand c’est possible. Sinon, activez le mode le moins longtemps possible et désactivez-le dès l’erreur relevée.

PrestaShop 8 et 9 : trois façons de l’activer

Depuis le back-office

Ouvrez Paramètres avancés > Performances.
Section Mode debug, passez « Mode debug » sur Oui.
Enregistrez, puis rechargez la page qui pose problème.

La même section propose Désactiver toutes les surcharges : utile quand l’erreur vient d’un fichier du dossier override/ installé par un module.

En ligne de commande

Si vous avez un accès SSH, PrestaShop fournit une commande dédiée, qui évite de modifier un fichier à la main :

# Afficher l'état actuel
php bin/console prestashop:debug

# Activer le mode debug
php bin/console prestashop:debug on

# Le désactiver dès le diagnostic terminé
php bin/console prestashop:debug off

La commande accepte aussi true/false et 1/0. Elle est décrite dans la documentation développeur de PrestaShop.

Dans le fichier `defines.inc.php`

C’est la seule méthode quand le back-office est inaccessible, et celle que donne la documentation officielle de la mise à jour dans ce cas.

Copiez d’abord config/defines.inc.php pour pouvoir revenir en arrière.
Ouvrez-le par FTP ou avec le gestionnaire de fichiers de l’hébergeur.
Remplacez false par true sur la ligne :

define('_PS_MODE_DEV_', true);

Pour ne pas modifier un fichier du cœur, la documentation indique qu’on peut aussi définir la constante dans config/defines_custom.inc.php, lu avant defines.inc.php.

PrestaShop 1.7 et 1.6

Sur ces versions, le mode debug passe par la même constante _PS_MODE_DEV_ dans config/defines.inc.php (la procédure ci-dessus). PrestaShop 1.7 propose aussi l’option dans Paramètres avancés > Performances.

Contrairement à ce qu’indiquait une ancienne version de cet article, PrestaShop 1.7 n’utilise pas de fichier .env pour le mode debug. Sur PrestaShop 9, un fichier .env existe à la racine, mais il sert à activer des fonctionnalités expérimentales, pas le mode debug.

Ces versions ne reçoivent plus de correctifs de sécurité : le diagnostic est souvent l’occasion de préparer une migration.

Restreindre l’affichage à votre adresse IP

Sur une boutique en ligne en 1.6 ou 1.7, vous pouvez limiter l’affichage des erreurs à votre adresse. Remplacez la ligne define('_PS_MODE_DEV_', false); de config/defines.inc.php par ce bloc, après avoir sauvegardé le fichier :

/* Mode debug réservé à votre adresse IP */
if (!defined('_PS_MODE_DEV_')) {
    define('_PS_MODE_DEV_', in_array($_SERVER['REMOTE_ADDR'] ?? '', ['VOTRE_IP_PUBLIQUE', '127.0.0.1', '::1'], true));
}

Derrière un CDN ou un proxy (Cloudflare…), REMOTE_ADDR contient l’adresse du proxy et non la vôtre : la restriction ne fonctionne pas telle quelle. Sur les versions récentes, préférez une activation courte depuis le back-office ou la commande.

Lire les journaux

Le mode debug affiche l’erreur à l’écran, mais les journaux la conservent, même quand rien ne s’affiche :

Version	Emplacement des journaux de PrestaShop
PrestaShop 9	`var/logs/`, un fichier par jour : `prod-2026-11-01.log`, ou `dev-…` en mode debug
PrestaShop 1.7 et 8	`var/logs/`
PrestaShop 1.6	`log/` à la racine

Le journal d’erreurs PHP et celui du serveur web (Apache, Nginx, LiteSpeed) sont des fichiers distincts, accessibles depuis le panneau de l’hébergeur (souvent sous le nom error_log). Consultez-les aussi : une erreur fatale de PHP n’arrive pas toujours dans les journaux de PrestaShop.

# Les 50 dernières lignes du journal du jour (PrestaShop 9, depuis la racine)
tail -n 50 var/logs/prod-$(date +%F).log

# Seulement les erreurs graves
grep -iE "critical|fatal|error" var/logs/prod-$(date +%F).log | tail -n 20

# Suivre le journal en direct pendant que vous reproduisez l'erreur (Ctrl+C pour arrêter)
tail -f var/logs/dev-$(date +%F).log

Les erreurs les plus fréquentes

Page blanche

Si la page reste blanche même en mode debug, l’erreur se produit souvent avant que PrestaShop puisse l’afficher : erreur de syntaxe PHP, version de PHP incompatible, extension manquante. Le journal d’erreurs PHP de l’hébergeur donne alors la cause.

« Class … not found »

Après l’installation ou la suppression d’une surcharge, ou une mise à jour de module, supprimez l’index des classes ; PrestaShop le reconstruit seul :

# PrestaShop 1.7, 8 et 9
rm var/cache/prod/class_index.php var/cache/dev/class_index.php

# PrestaShop 1.6
rm cache/class_index.php

« Allowed memory size … exhausted »

La mémoire PHP est insuffisante. La documentation de PrestaShop 9 recommande au moins 512 Mo pour memory_limit. Réglez cette valeur dans le panneau de l’hébergeur ou dans un fichier .user.ini à la racine.

N’utilisez pas php_value memory_limit dans le .htaccess, souvent proposé ailleurs : sur la plupart des hébergements actuels, où PHP ne tourne pas comme module Apache, cette ligne provoque elle-même une erreur 500.

Erreur après une mise à jour

Un module tiers incompatible est la cause la plus fréquente. Désactivez les modules non natifs, puis réactivez-les un par un pour trouver le coupable. Si le back-office est inaccessible, renommez le dossier du module suspect dans modules/. Les autres causes sont détaillées dans Erreur 500 PrestaShop : 10 causes et leur solution.

Pour les développeurs : `dump()`

La fonction dump() de Symfony n’est disponible que lorsque le mode debug est actif. Elle affiche le contenu d’une variable pendant un test. Retirez les appels avant de remettre la boutique en production.

Avant de désactiver le mode debug

L’erreur est relevée (fichier, ligne, message) et corrigée.
Les journaux du jour ne contiennent plus d’erreur grave.
Le mode debug est revenu à « Non », ou prestashop:debug off a été lancé, ou la constante est revenue à false.
Les surcharges sont réactivées si vous les aviez désactivées.
Le cache est vidé : voir Vider le cache PrestaShop 8 et 9.

Questions fréquentes

Le mode debug peut-il rester actif en production ?

Non. Il ralentit nettement la boutique et affiche des détails techniques à tous les visiteurs. Activez-le le temps de relever l’erreur, de préférence sur une copie.

Back-office, commande ou fichier : quelle méthode choisir ?

Le back-office est le plus simple, la commande la plus rapide si vous avez un accès SSH. Le fichier defines.inc.php reste la seule solution quand le back-office ne s’affiche plus.

Le mode debug n’affiche rien, où chercher ?

Dans les journaux de var/logs/, puis dans le journal d’erreurs PHP de l’hébergeur. Une erreur qui se produit très tôt, comme une version de PHP incompatible, n’apparaît que dans ce dernier.

Le mode debug corrige-t-il l’erreur ?

Non. Il l’affiche, avec le fichier et la ligne en cause. La correction dépend ensuite du message : module à mettre à jour, cache à vider, réglage du serveur à changer.

Sources

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →