Erreurs fréquentes PrestaShop : résoudre les pannes liées à l’hébergement

Une erreur 500 ou une page blanche peut immobiliser votre boutique en quelques secondes.

Ce guide vous donne une méthode fiable et reproductible pour identifier la cause (logs, configuration, ressources, permissions, réécriture d’URL), appliquer les correctifs sans empirer la situation, puis valider que le front-office, le back-office et le tunnel d’achat sont stables.

Si vous voulez une vue d’ensemble côté hébergement et exploitation, consultez la page PrestaShop ETHERSYS.

Prérequis et préparation

• Accès indispensables : FTP/SFTP, SSH (si possible), accès base de données (MySQL/MariaDB), et accès au panneau hébergeur.
• Accès aux journaux : logs web (Apache/Nginx), PHP-FPM, logs applicatifs PrestaShop si activés.
• Fenêtre de maintenance : prévoyez une période calme et informez l’équipe (support, marketing, service client).
• Durée & difficulté : de “rapide” (droits/htaccess) à “avancé” (conflits modules/override, limites serveur, migration).
• Règle de sécurité : avant toute action, sauvegarde fichiers + base (un retour arrière doit être possible).

Objectif : éviter de “réparer à l’aveugle”. En hébergement, les problèmes viennent souvent d’un triptyque config (PHP/MySQL), droits (écriture cache), ressources (timeout/mémoire). C’est aussi le moment de noter le “jour prestashop” (date/heure de l’incident) et ce qui a changé (mise à jour, nouveau thème, module, import).

Checklist serveur (à cocher avant de toucher au code)

• PHP : version supportée par votre PrestaShop (compatibilité), memory_limit, max_execution_time, extensions manquantes.
• MySQL/MariaDB : identifiants, droits utilisateur DB, saturation (connexions, disque, verrous).
• Droits système : dossiers en écriture (cache, upload, logs), propriétaires cohérents.
• Limites ressources : CPU/RAM, I/O disque, quotas, limites imposées par l’hébergement.
• Réseau : DNS/SSL, règles WAF/anti-bot, ports DB si externe.

Ne changez qu’un paramètre à la fois, et documentez : “symptôme → action → résultat → ligne de log associée”. C’est ce qui vous évite les corrections contradictoires.

Diagnostiquer les erreurs PrestaShop (contexte + logs + debug)

• Cartographiez : quelles pages cassent (home, produit, panier, paiement, admin) ?
• Reproduisez : action précise (connexion BO, ajout panier, génération image, import CSV).
• Lisez les logs serveur : corrélez l’heure exacte avec l’erreur.
• Activez le debug (temporairement) pour faire apparaître l’exception et le fichier en cause.
• Désactivez le cache le temps du diagnostic, sinon vous poursuivez un fantôme.

Côté serveur web, commencez par le journal d’erreurs : c’est “le premier endroit où regarder quand un problème survient”. Référence utile : Apache HTTP Server documentation (logs) et la directive ErrorLog. Pour Nginx, le réglage error_log et les niveaux (error, warn, info, debug) sont décrits dans NGINX documentation.

Activer le mode debug (snippet)

PrestaShop permet d’activer le mode debug depuis le back-office ou via FTP. La procédure officielle est décrite par PrestaShop Help Center (et côté dev dans PrestaShop Developer Documentation).

// Fichier : /config/defines.inc.php
/* Debug only */
if (!defined('_PS_MODE_DEV_')) {
    define('_PS_MODE_DEV_', true);
}

Important : en production, le debug peut exposer des chemins, des requêtes, voire des données sensibles. Activez-le uniquement le temps du diagnostic, idéalement en mode maintenance ou filtré par IP (selon votre contexte et votre politique de sécurité).

Corriger les permissions et propriétaires des fichiers

• Réparez l’écriture : cache, compilation, logs, upload images doivent pouvoir écrire.
• Vérifiez les propriétaires : l’utilisateur système qui exécute PHP doit pouvoir lire/écrire où nécessaire.
• Contrôlez les répertoires critiques : cache, thèmes compilés, images, téléchargements.
• Surveillez l’espace disque : un disque plein mime une panne applicative (erreurs, timeouts).
• Re-testez immédiatement le scénario qui cassait (exemple : régénération miniature image).

Symptôme typique : erreurs intermittentes (ou uniquement sur certaines pages) après un déploiement, une restauration, une migration, ou un changement de méthode d’upload. Une incohérence propriétaire/droits provoque des “échecs d’écriture” qui finissent en erreur 500, ou en comportement incomplet (cache non purgé, fichiers temporaires absents).

Point de vigilance : permissions trop permissives

Évitez la “solution” 777 généralisée : elle masque le vrai problème et dégrade fortement la sécurité. Préférez des droits minimaux nécessaires + un propriétaire cohérent, adaptés au modèle d’exécution (PHP-FPM, suPHP, etc.).

Régénérer le .htaccess et fiabiliser la réécriture d’URL

• Régénérez le .htaccess depuis le back-office (SEO & URLs) si vous suspectez une corruption.
• Validez la réécriture : si la réécriture n’est pas supportée, les URLs simplifiées peuvent rendre le site inaccessible.
• Contrôlez le SSL : redirections HTTP→HTTPS et canonical doivent être cohérentes.
• Multiboutique : attention aux domaines, préfixes et règles spécifiques.
• Testez : page produit, catégorie paginée, CMS, recherche interne.

Pour rappel, les URLs simplifiées nécessitent une configuration serveur compatible réécriture (ex. mod_rewrite sous Apache). La documentation officielle PrestaShop le souligne sur la page “SEO et URL” : Documentation PrestaShop 8.

Flux : [Navigateur demande une URL] → [Serveur applique règles (rewrite/SSL)] → [Front controller PrestaShop] → [Contrôleur + module + thème] → [Réponse HTTP + logs]

Si vous voyez des 404 sur des pages qui existent, des redirections infinies, ou un basculement HTTP/HTTPS instable, isolez d’abord : (1) règles .htaccess, (2) configuration du serveur, (3) paramètres PrestaShop SEO/URL, (4) modules de redirection/canonical.

Ajuster les ressources PHP et les timeouts (sans “sur-allouer”)

• Augmentez la mémoire si vous observez des erreurs fatales “Allowed memory size…”.
• Allongez le temps d’exécution pour les tâches lourdes (import, régénération images).
• Cadrez les uploads : cohérence entre post_max_size et upload_max_filesize.
• Réduisez la charge : import en lots, régénération d’images par tranches.
• Mesurez : TTFB, saturation CPU/RAM, I/O disque, et erreurs PHP-FPM.

Les directives PHP structurantes sont documentées dans le manuel : memory_limit (limite de mémoire par script) est détaillée dans PHP Manual. Pour les uploads, la relation entre post_max_size et upload_max_filesize (et les effets en cas de dépassement) est rappelée dans PHP Manual (file uploads).

Point de vigilance : limites imposées par l’hébergement

Même avec un php.ini correct, l’hébergeur peut imposer des plafonds (process manager PHP-FPM, quotas CPU/RAM, limites I/O, limite de requêtes, règles WAF). Si vous êtes bloqué, la bonne approche est de déplacer la charge (batch, cron, files d’attente) ou de dimensionner la machine/les ressources réservées — plutôt que d’augmenter “au hasard” des valeurs qui aggravent la consommation et la surface d’attaque.

Stabiliser modules, thème et mises à jour

• Vérifiez la compatibilité entre versions PHP, PrestaShop, thème et modules.
• Mettez à jour ce qui est obsolète (modules et overrides en priorité).
• Isolez un conflit : désactivation progressive (un par un) en reproduisant le bug.
• Surveillez la base : schémas, colonnes manquantes après update, données incohérentes.
• Sauvegardez avant chaque changement (fichiers + base) pour rollback rapide.

Beaucoup d’erreurs “hébergement” sont en réalité des incompatibilités applicatives qui se déclenchent sous charge (ou après upgrade). Si une page blanche apparaît après une mise à jour, partez du principe qu’un module (ou override) appelle une fonction absente, ou qu’une dépendance attend une version différente. Le correctif n’est pas “plus de RAM” : c’est la remise en cohérence des versions + un plan de mise à jour contrôlé.

Validation et résultats attendus

• Testez : front-office, back-office, tunnel d’achat, paiement, emails transactionnels.
• Contrôlez les codes HTTP (200/301/302/404/500) et l’absence d’erreurs récurrentes.
• Relisez les logs après correctif : l’objectif est “zéro nouvelle erreur”.
• Vérifiez la performance : TTFB, temps de génération, pics CPU/RAM, latence DB.
• Désactivez debug et remettez le cache selon la stratégie prévue.

Dans un contexte infogéré orienté performance, la validation ne s’arrête pas au “ça s’affiche”. Vous cherchez : stabilité + absence d’erreurs + latence maîtrisée. En production, une correction est “terminée” quand elle est vérifiable dans les journaux et reproductible en test.

Matrice : symptômes d’hébergement → correctifs rapides

Utilisez cette matrice comme “raccourci” : vous gagnez du temps en validant la cause la plus probable avant de modifier la configuration au hasard.

FAQ — pannes habituelles PrestaShop côté hébergement

Erreur 500 qui persiste après correction des droits (délai : 30 minutes) : que faire ?

Revenez au factuel : (1) notez l’heure précise, (2) lisez le log d’erreurs web + PHP-FPM, (3) activez temporairement le mode debug pour obtenir la trace, puis (4) identifiez si l’erreur est une surcharge (timeout/mémoire), une dépendance manquante, ou un conflit module/override. Tant que vous n’avez pas une ligne de log corrélée à l’erreur, vous n’êtes pas en diagnostic, vous êtes en suppositions.

Page blanche après mise à jour (retour arrière en moins d’1 heure) : comment agir ?

Activez le debug pour faire apparaître l’exception, puis désactivez les modules non essentiels un par un jusqu’à retrouver l’affichage. Si vous avez un override, testez aussi sans override. Enfin, restaurez fichiers + base si l’objectif est un retour en service immédiat, puis refaites l’update en environnement de préproduction avec un plan (versions, compatibilité, sauvegarde, tests).

Connexion base de données impossible (incident brutal) : quelles causes les plus fréquentes ?

Les causes typiques sont : identifiants modifiés, droits DB insuffisants, serveur DB indisponible, nombre de connexions saturé, ou espace disque DB plein. Validez d’abord la disponibilité du serveur DB et les logs côté base, puis vérifiez la configuration applicative et les permissions. Évitez de “réinstaller” : vous risquez d’endommager des données.

Redirections infinies SSL (impact immédiat SEO) : comment corriger proprement ?

Une boucle vient souvent d’une incohérence entre : réglages HTTPS dans PrestaShop, règles .htaccess, et terminaison TLS (proxy/CDN). Simplifiez : imposez une seule stratégie (HTTPS partout), vérifiez le domaine canonical, puis testez avec et sans cache. Enfin, contrôlez les en-têtes et les codes 301/302 sur les pages clés (home, produit, panier, paiement).

Timeout sur import catalogue (gros volume, sans casser la performance) : quelles solutions ?

Ne forcez pas uniquement le max_execution_time. Préférez un import par lots (fichiers plus petits), planifiez hors pic, et surveillez la charge serveur (CPU/RAM/I/O). Si l’import est structurellement lourd, basculez vers un traitement asynchrone (cron/queue) et limitez la régénération d’images à des fenêtres dédiées.

Synthèse des actions prioritaires côté hébergement

• Priorité 1 : logs (web + PHP) + reproduction + heure exacte.
• Priorité 2 : debug temporaire + cache OFF pour identifier l’erreur réelle.
• Priorité 3 : droits/propriétaires + dossiers d’écriture (cache/upload).
• Priorité 4 : .htaccess + réécriture URL + SSL/canonical cohérents.
• Priorité 5 : ressources/timeouts + stabilisation modules/thème + plan de mise à jour.

En prévention, mettez en place un monitoring minimal (disponibilité HTTP, charge, espace disque, erreurs récurrentes) et une routine de sauvegarde/restauration testée : c’est ce qui transforme une panne en incident maîtrisé plutôt qu’en crise.