Une boutique PrestaShop qui affiche une erreur critique, c’est rarement un petit bug sans conséquence. Page blanche, erreur 500, panier qui ne fonctionne plus… et très vite, plus aucune commande. Dans la pratique, ces situations arrivent souvent après une mise à jour, l’installation d’un module ou une modification serveur. La bonne nouvelle, c’est qu’on peut généralement corriger sans casser le reste — à condition d’agir dans le bon ordre.
Identifier le type d’erreur avant de toucher à quoi que ce soit
Beaucoup de corrections échouent simplement parce que le diagnostic est mauvais. Une erreur 500 n’a rien à voir avec un conflit de module, et une page blanche n’est pas toujours liée au code.
Les cas les plus fréquents :
– Erreur 500 : souvent liée à un problème PHP (version incompatible, limite mémoire, erreur fatale)
– Page blanche : erreur PHP masquée ou module défectueux
– Bug du tunnel de commande : conflit entre modules de paiement ou surcharge du thème
– Back-office inaccessible : problème de session, module admin ou sécurité serveur
Avant toute action, active le mode debug. Sur PrestaShop, ça se fait en modifiant le fichier /config/defines.inc.php et en passant :
define(‘_PS_MODE_DEV_’, true);
Ça va afficher l’erreur réelle au lieu d’un message générique. C’est souvent là que tout devient clair.
Consulter les logs serveur (souvent plus fiables que PrestaShop)
Le mode debug aide, mais il ne montre pas toujours tout. Les logs serveur restent la source la plus fiable pour comprendre ce qui se passe réellement.
Sur un hébergement classique (OVH, o2switch, etc.), tu trouveras :
– les logs Apache ou Nginx
– les logs PHP (erreurs fatales, mémoire, timeout)
Exemple concret : une erreur 500 peut venir d’un simple dépassement de mémoire (memory_limit trop bas), surtout après l’ajout d’un module un peu lourd.
Désactiver les modules sans passer par le back-office
Quand le back-office est bloqué, il faut contourner. C’est une situation classique après l’installation d’un module incompatible.
La méthode la plus rapide :
– se connecter en FTP
– aller dans /modules/
– renommer le dossier du module suspect (ex : stripe → stripe_old)
PrestaShop va automatiquement désactiver le module. Ça permet souvent de récupérer l’accès au site ou au back-office.
Sur le terrain, les conflits viennent souvent de :
– modules de paiement (Stripe, PayPal)
– modules de livraison
– modules SEO mal configurés
Vérifier la compatibilité PHP et PrestaShop
Une mise à jour serveur peut casser une boutique du jour au lendemain. Typiquement : passage en PHP 8 alors que la boutique tourne sur une version PrestaShop non compatible.
Résultat : erreurs critiques, warnings, ou site totalement inaccessible.
À vérifier immédiatement :
– version PHP utilisée
– version PrestaShop installée
– compatibilité officielle entre les deux
Exemple réel : PrestaShop 1.7.6 fonctionne mal avec PHP 8 sans correctifs. Dans ce cas, repasser en PHP 7.4 peut suffire à rétablir le site en quelques minutes.
Rétablir les fonctions essentielles en priorité
Quand une boutique est en panne, l’objectif n’est pas de tout réparer parfaitement d’un coup. Il faut d’abord remettre en route ce qui génère du chiffre.
Priorités :
– affichage du catalogue
– fonctionnement du panier
– tunnel de commande
– module de paiement
Il arrive qu’un site soit accessible, mais que le panier ne fonctionne plus. Dans ce cas, le problème est souvent lié à un module JS ou à une surcharge du thème.
Un test simple : essayer avec le thème par défaut de PrestaShop. Si le problème disparaît, le bug vient du thème ou d’une personnalisation.
Attention aux modifications directes en production
Corriger “en live” est tentant, surtout en urgence. Mais c’est aussi la meilleure façon d’aggraver la situation.
Dans la pratique, on voit souvent :
– des fichiers modifiés sans sauvegarde
– des corrections partielles qui créent d’autres bugs
– des tentatives successives sans logique globale
Le minimum :
– faire une sauvegarde complète (fichiers + base de données)
– si possible, reproduire le bug en local ou en préproduction
– tester les corrections avant mise en ligne
Réparer une base de données corrompue
Moins fréquent, mais ça arrive, surtout après une coupure serveur ou une migration ratée.
Symptômes :
– erreurs aléatoires
– données manquantes
– pages qui ne chargent pas correctement
Actions possibles :
– réparer les tables via phpMyAdmin
– vérifier les préfixes de tables
– restaurer une sauvegarde récente
Une base corrompue peut donner l’impression d’un bug code, alors que le problème est purement structurel.
Cas fréquent : page blanche après mise à jour
C’est probablement le scénario le plus courant.
En général :
– un module incompatible avec la nouvelle version
– une surcharge non compatible
– une erreur PHP bloquante
La méthode efficace :
1. activer le mode debug
2. identifier le fichier ou module en cause
3. désactiver ou corriger
4. vider le cache PrestaShop (/var/cache)
Beaucoup oublient cette dernière étape. Pourtant, un cache corrompu peut maintenir une erreur même après correction.
Quand faire appel à une intervention urgente PrestaShop
Il y a un moment où insister seul devient contre-productif. Surtout quand :
– le site ne génère plus de commandes
– plusieurs erreurs apparaissent en même temps
– aucune sauvegarde exploitable n’est disponible
Une intervention rapide (souvent 1 à 2 heures) permet :
– d’identifier précisément la cause
– de corriger sans toucher inutilement au reste
– de sécuriser la boutique pour éviter une rechute
Sur des cas critiques, on voit régulièrement des erreurs liées à plusieurs facteurs combinés (module + PHP + cache). Sans méthode, ça devient vite ingérable.
Ce qui évite 80% des erreurs critiques
Avec un peu de recul, les mêmes causes reviennent constamment.
Quelques bonnes pratiques simples :
– éviter d’installer des modules non maintenus
– tester les mises à jour sur une préproduction
– maintenir une version PHP compatible
– automatiser les sauvegardes
– limiter les surcharges du thème
Ce n’est pas très “technique”, mais c’est exactement ce qui fait la différence entre une boutique stable et une boutique fragile.
Comment activer le mode debug PrestaShop sans accès au back-office ?
Vous pouvez activer le mode debug directement via les fichiers du serveur. Accédez au fichier config/defines.inc.php et remplacez la valeur false par true sur la ligne définissant _PS_MODE_DEV_. Cela affichera les erreurs PHP à l’écran pour identifier plus facilement la source du problème.
Que faire si mon site affiche une page blanche après une mise à jour ?
Une page blanche est souvent liée à une erreur PHP ou à un module incompatible. Commencez par activer le mode debug, puis vérifiez les derniers modules installés ou mis à jour. Vous pouvez aussi désactiver temporairement les modules via FTP pour isoler la cause.
Comment accéder à ma boutique si le back-office est bloqué ?
Si le back-office est inaccessible, utilisez un accès FTP ou votre hébergeur pour intervenir directement. Vous pouvez renommer le dossier d’un module défectueux dans /modules/ pour le désactiver, ou activer le mode maintenance afin de sécuriser la boutique pendant les corrections.
Quels fichiers vérifier en priorité lors d’une erreur critique PrestaShop ?
Les fichiers clés à contrôler sont config/defines.inc.php, .htaccess et les logs serveur (error_log). Vérifiez aussi le dossier /var/logs/ pour les versions récentes. Ces éléments permettent d’identifier rapidement les erreurs système ou de configuration.
Comment éviter de perdre des données lors d’un dépannage PrestaShop ?
Avant toute intervention, effectuez une sauvegarde complète des fichiers et de la base de données. Travaillez si possible sur une copie de la boutique ou en mode maintenance. Cela permet de tester les corrections sans impacter les commandes ou les clients en cours.