Où trouver et comment lire les logs PrestaShop
PrestaShop consigne ses erreurs à trois endroits différents selon leur nature : dans sa propre table de logs, dans un dossier de fichiers, et dans les journaux du serveur lui-même. Savoir lequel consulter en premier fait gagner l’essentiel du temps de diagnostic.
Les trois sources de logs, dans l’ordre à consulter
-
L’onglet Logs du back-office
Accessible depuis Paramètres avancés > Logs, il liste les erreurs et avertissements générés par PrestaShop lui-même, avec un niveau de sévérité, l’heure et souvent le fichier PHP concerné. C’est la première source à vérifier si le back-office reste accessible.
-
Le dossier var/logs
À partir de PrestaShop 1.7.4, et donc sur 8 et 9, ce dossier contient les journaux générés par le framework Symfony sous-jacent, séparés par environnement (prod.log, dev.log). Sur les 1.7.0 à 1.7.3, ces mêmes journaux se trouvent dans app/logs. Le dossier est accessible uniquement par FTP, SFTP ou SSH.
-
Les journaux du serveur
Le panneau d’hébergement (cPanel, Plesk, ou un accès SSH direct) donne accès aux journaux d’erreurs PHP et aux journaux du serveur web (Apache ou Nginx), qui consignent les erreurs survenant avant même que PrestaShop ne s’exécute.
-
Croiser l’horodatage
Le point commun entre les trois sources est l’heure de l’incident. Repérer le moment exact où le problème est apparu permet de retrouver la même erreur dans plusieurs journaux et de confirmer la cause.
-
Activer le mode debug en complément
Si aucun journal n’est assez précis, activer temporairement _PS_MODE_DEV_ dans config/defines.inc.php affiche l’erreur en direct sur la page concernée, avec la pile d’appels complète.
[2026-07-24 09:14:02] request.CRITICAL: Uncaught PHP Exception ... {"exception":"[object] (Error(code: 0): Call to undefined method ..."}Ce que chaque source révèle et ce qu’elle ne révèle pas
L’onglet Logs du back-office est pratique parce qu’il ne demande aucun accès technique particulier, mais il ne fonctionne que si PrestaShop parvient à démarrer suffisamment pour écrire en base de données. Une erreur survenant très tôt dans le chargement, ou un problème de connexion à la base elle-même, n’y apparaîtra jamais.
Le dossier var/logs capture un spectre plus large d’erreurs, y compris celles qui empêchent l’affichage complet d’une page, mais reste propre à l’application : une erreur de configuration serveur, un manque de mémoire PHP ou un fichier .htaccess invalide n’y laisseront aucune trace.
Les journaux serveur sont la dernière ligne de défense : ils voient tout ce qui se passe au niveau du serveur web et de PHP, y compris les erreurs qui empêchent PrestaShop de s’exécuter du tout. C’est là qu’il faut aller quand ni le back-office ni var/logs n’expliquent rien.
Les erreurs courantes
- Chercher uniquement dans le back-office alors que le site est totalement hors ligne : dans ce cas, l’onglet Logs lui-même est probablement inaccessible.
- Ignorer l’horodatage et lire le premier message trouvé, qui peut dater de plusieurs semaines et n’avoir aucun rapport avec l’incident du jour.
- Ne jamais faire de rotation ou de nettoyage des logs : sur une boutique ancienne, ces fichiers peuvent atteindre plusieurs gigaoctets et devenir difficiles à consulter.
- Confondre un message de niveau « avertissement » avec la cause réelle d’une erreur 500 : seuls les messages de niveau critique ou erreur méritent d’être traités en priorité.
Questions fréquentes
Je n’ai aucun accès FTP, puis-je quand même consulter les logs ?
Les logs contiennent-ils des données personnelles de mes clients ?
Combien de temps les logs sont-ils conservés ?
Le message d’erreur est en anglais et très technique, est-ce normal ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.