C’est le cauchemar de tout e-commerçant. Vous vous connectez un matin, et là : rien. Une page blanche. Ou pire, un message effrayant : « Internal Server Error 500« .
Le téléphone sonne, les ventes s’arrêtent, le stress monte.
Pas de panique. En tant qu’expert PrestaShop intervenant sur des centaines de boutiques (de la vénérable 1.6 à la toute dernière 9.0), je peux vous le dire : tout se répare.
Souvent, le site n’est pas « mort ». Il est juste « malade ». Une base de données saturée par des statistiques (le grand classique de la 1.7), un module incompatible ou une mise à jour PHP trop audacieuse.
Voici ma méthode de « chirurgien » pour diagnostiquer, opérer et relancer votre machine à vendre.
Le téléphone sonne, les ventes s’arrêtent, le stress monte.
Pas de panique. En tant qu’expert PrestaShop intervenant sur des centaines de boutiques (de la vénérable 1.6 à la toute dernière 9.0), je peux vous le dire : tout se répare.
Souvent, le site n’est pas « mort ». Il est juste « malade ». Une base de données saturée par des statistiques (le grand classique de la 1.7), un module incompatible ou une mise à jour PHP trop audacieuse.
Voici ma méthode de « chirurgien » pour diagnostiquer, opérer et relancer votre machine à vendre.
Étape 1 : Allumer la Lumière (Le Mode Debug)
Face à une page blanche, la première erreur est de toucher à tout. La première chose à faire est de faire parler PrestaShop.
Activer le _PS_MODE_DEV_
(La technique Pro)
Il faut modifier le fichier
L’astuce de l’expert : J’active le mode debug uniquement pour mon adresse IP.
/config/defines.inc.php. Mais attention ! Si vous passez simplement le mode à true, tous vos clients verront les messages d’erreur techniques. C’est catastrophique pour votre image.L’astuce de l’expert : J’active le mode debug uniquement pour mon adresse IP.
Bash
if ($_SERVER['REMOTE_ADDR'] == 'VOTRE_IP_ICI') {
define('_PS_MODE_DEV_', true);
} else {
define('_PS_MODE_DEV_', false);
}Ainsi, la boutique reste « en panne » (ou blanche) pour le public, mais moi, je vois l’origine exacte du problème (le nom du fichier et la ligne coupable).
Le Tueur Silencieux :
La Base de Données Saturée (Spécial PrestaShop 1.7)
C’est un cas que je rencontre une fois sur deux sur les boutiques qui ont quelques années, particulièrement sur la version 1.7.
Le Symptôme : Le site ralentit progressivement, le back-office devient inutilisable, puis c’est l’erreur 500 fatale. Le Diagnostic : Votre base de données a explosé. J’ai vu des bases de 500 Mo passer à 5 Go ou 10 Go à cause de trois tables spécifiques.
Le Symptôme : Le site ralentit progressivement, le back-office devient inutilisable, puis c’est l’erreur 500 fatale. Le Diagnostic : Votre base de données a explosé. J’ai vu des bases de 500 Mo passer à 5 Go ou 10 Go à cause de trois tables spécifiques.
Les tables ps_connections, ps_connections_source et ps_guest
PrestaShop, par défaut, enregistre chaque visite, chaque clic, chaque source de trafic dans la base de données pour ses statistiques internes. Sur un site à fort trafic, cela génère des millions de lignes. La base devient trop lourde pour le serveur MySQL, et le site s’écroule sous son propre poids.
La Solution (Le Nettoyage Chirurgical)
- Sauvegarde : On ne touche jamais à la BDD sans un dump complet.
- Nettoyage (TRUNCATE) : Je vide ces tables historiques (sans toucher aux commandes ni aux clients !).
- Configuration : Je configure le module « Récupération des données statistiques » (Data mining for statistics) pour purger automatiquement les données vieilles de plus de 3 mois.
- L’Alternative : Je recommande de déléguer les stats à Matomo (auto-hébergé) pour soulager définitivement PrestaShop.
Votre site est en panne ? Appelez le Mécano.
Ne laissez pas votre boutique fermée une minute de plus. Une erreur 500 qui dure, c’est du référencement Google perdu et des clients qui vont chez la concurrence.
Que vous soyez sur une vieille 1.6 que vous chérissez ou une 8.0 qui fait des siennes, je connais la mécanique sous le capot.
Que vous soyez sur une vieille 1.6 que vous chérissez ou une 8.0 qui fait des siennes, je connais la mécanique sous le capot.
Les Spécificités par Version (De l’Ancien au Moderne)
Chaque génération de PrestaShop a ses maladies chroniques.
PrestaShop 1.6 (Le Vétéran)
Il y a encore de très gros sites qui tournent sur la 1.6 (et qui performent !).
- Le Bug fréquent : Incompatibilité PHP. La 1.6 supporte mal PHP 7.3 ou plus. Souvent, un hébergeur met à jour PHP automatiquement et le site casse.
- La Réparation : Fixer la version PHP ou patcher le cœur pour supporter PHP 7.4/8.0 (ce que je fais pour maintenir ces sites en vie).
PrestaShop 1.7 (L’Adolescent Difficile)
C’est la version de la transition vers Symfony.
- Le Bug fréquent : Le cache Symfony (
/var/cache/). Il se corrompt souvent, provoquant des pages blanches en back-office. - La Réparation : Vider manuellement le dossier cache via FTP ou SSH est souvent la « reboot » magique de la 1.7.
PrestaShop 8 & 9 (L’Ère Moderne)
ATTENTION : Ces versions sont plus strictes.
- Le Bug fréquent : Elles ne tolèrent plus les « bricolages » de code dans les vieux modules. Une simple fonction dépréciée en PHP 8.1 peut bloquer une page.
- La Réparation : Il faut identifier le module obsolète et le mettre à jour ou le réécrire proprement.
Bug de Code ou Saturation Serveur (OOM) ?
Parfois, PrestaShop n’est pas coupable. C’est le serveur qui étouffe. Si les logs affichent « Out Of Memory » (OOM), c’est que votre processus PHP a consommé toute la RAM allouée.
- La cause : Souvent un module de génération de PDF, d’import de catalogue ou de traitement d’images qui est trop gourmand.
- La solution : Augmenter la
memory_limitdans lephp.iniou, si vous êtes sur un mutualisé limité, migrer vers un Serveur Dédié IONOS où nous avons la main sur les ressources.
J’ai une erreur 500, est-ce que j’ai tout perdu ?
Non ! Une erreur 500 signifie simplement que le serveur n’arrive pas à exécuter le script. Vos données (clients, commandes, catalogue) sont stockées dans la base de données et sont, dans 99% des cas, intactes. Il faut juste réparer le « moteur » qui les affiche.
Pouvez-vous intervenir sur un PrestaShop 1.6 très modifié ?
Oui. Je maintiens encore plusieurs grosses boutiques en 1.6. Je connais parfaitement l’architecture « Legacy » (Smarty) de cette version et je sais comment la sécuriser en 2026.
Le nettoyage de la base de données (stats) est-il risqué ?
S’il est fait par un expert, non. Il s’agit de vider des tables de « logs » (connexions, invités) qui n’ont aucune valeur commerciale (contrairement aux commandes). Cela n’efface pas votre chiffre d’affaires, mais cela peut diviser par deux la taille de votre base de données et accélérer votre site instantanément.
Combien de temps faut-il pour réparer un site ?
Le diagnostic (trouver la cause) prend généralement moins d’une 1/2 heure avec les bons outils (logs, mode debug). La réparation dépend de la gravité, mais la plupart des sites sont remis en ligne dans les 3 heures qui suivent.
