# 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.

- Source canonique : [https://allaux.fr/guides/lire-logs-erreurs-prestashop](https://allaux.fr/guides/lire-logs-erreurs-prestashop)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## Réponse directe

> Commencez par l’onglet Paramètres avancés puis Logs du back-office, qui liste les erreurs internes de PrestaShop. Si le back-office est inaccessible, passez directement aux fichiers du dossier var/logs (app/logs sur les 1.7.0 à 1.7.3) ou aux journaux du serveur fournis par l’hébergeur.

## Les trois sources de logs, dans l’ordre à consulter

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## var/logs/prod.log (extrait typique)

```
[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é.

## FAQ

### Je n’ai aucun accès FTP, puis-je quand même consulter les logs ?

Seul l’onglet Logs du back-office est accessible sans accès aux fichiers. Pour var/logs ou les journaux serveur, un accès FTP, SFTP, SSH ou au panneau d’hébergement est indispensable.

### Les logs contiennent-ils des données personnelles de mes clients ?

Cela peut arriver, notamment si une erreur survient pendant le traitement d’une commande et que le message inclut des données de la requête. Ils doivent être traités avec la même prudence que le reste de la base de données.

### Combien de temps les logs sont-ils conservés ?

PrestaShop ne purge pas automatiquement l’onglet Logs, il peut grossir indéfiniment. Les journaux serveur suivent en général une politique de rotation définie par l’hébergeur, souvent entre quelques jours et quelques semaines.

### Le message d’erreur est en anglais et très technique, est-ce normal ?

Oui, les journaux PHP et Symfony restent en anglais quelle que soit la langue de l’interface PrestaShop. Le message contient malgré tout des informations exploitables : nom de fichier, ligne, type d’erreur.