Un bug PrestaShop peut prendre des formes très différentes : page blanche, erreur 500, panier qui ne se met plus à jour, paiement refusé, produits absents d’une catégorie ou back-office inaccessible. La correction ne consiste pas à modifier des fichiers au hasard. Il faut d’abord isoler le contexte, rendre l’erreur exploitable, puis tester une cause à la fois sur une copie de la boutique. Cette méthode limite les interruptions de vente et évite de transformer un incident ponctuel en panne plus grave.
Qualifier le bug avant toute intervention
Commencez par noter précisément ce qui se produit. Une erreur observée sur la fiche produit ne se diagnostique pas comme un échec de paiement ou un problème d’administration. Reproduisez le scénario avec un navigateur en navigation privée et consignez les éléments utiles :
- l’URL exacte, la date et l’heure du problème ;
- le terminal et le navigateur utilisés ;
- le compte client concerné, sans jamais noter son mot de passe ;
- les étapes qui déclenchent l’erreur ;
- le message affiché, le code HTTP et une capture d’écran ;
- les changements récents : module, thème, mise à jour, configuration PHP, certificat SSL ou import de données.
Vérifiez également l’étendue de l’incident. Si seule une référence produit pose problème, contrôlez ses déclinaisons, son stock, ses images et ses catégories. Si toutes les pages échouent, la piste de l’hébergement, de PHP, de la base de données ou d’un module chargé globalement devient prioritaire. Une erreur réservée aux visiteurs connectés peut provenir d’un groupe client, d’une règle panier ou d’un module de paiement.
Afficher les erreurs sans exposer la boutique
Le mode debug de PrestaShop affiche les erreurs PHP et SQL qui sont masquées en production. Activez-le uniquement le temps du diagnostic et, si possible, sur une préproduction protégée. Sur PrestaShop 1.7 et 8, éditez le fichier config/defines.inc.php et remplacez la valeur de _PS_MODE_DEV_ par true. Videz ensuite le cache dans le back-office, ou supprimez le contenu de var/cache/ en conservant les dossiers eux-mêmes si le back-office est inaccessible.
Sur des versions plus anciennes, le réglage peut être situé dans config/config.inc.php. Ne copiez pas aveuglément une procédure prévue pour une autre version : l’emplacement et le mécanisme de cache ont évolué. Dès que l’erreur a été relevée, remettez le mode développement à false. Laisser une trace SQL, un chemin de serveur ou une exception visible aux visiteurs constitue un risque de sécurité.
Lire les bons journaux
Une page blanche ou une erreur 500 n’indique pas nécessairement une erreur PrestaShop. Consultez en priorité le journal d’erreurs PHP de l’hébergement et les logs du serveur web à l’heure exacte du bug. Recherchez notamment PHP Fatal error, Allowed memory size exhausted, Maximum execution time exceeded ou une incompatibilité de type avec la version de PHP.
Les erreurs applicatives peuvent aussi se trouver dans var/log/ selon la version et la configuration. Dans le navigateur, ouvrez les outils de développement, onglet Réseau. Une action qui semble ne rien faire peut en réalité retourner une réponse AJAX en 403, 404 ou 500. La réponse affichée permet souvent d’identifier un contrôleur, un module ou une route cassée.
Identifier les causes les plus fréquentes
Incompatibilité entre PrestaShop, PHP et les modules
Une mise à niveau de PHP peut révéler du code obsolète dans un thème ou un module. Vérifiez la matrice de compatibilité communiquée par l’éditeur de votre version de PrestaShop, puis celle de chaque module critique : paiement, transport, recherche, avis, synchronisation ERP et connecteurs marketing. Ne mettez pas PHP à jour directement sur la boutique de production sans essai sur un clone.
Un message du type Class not found, Declaration ... must be compatible ou une fonction supprimée pointe souvent vers une extension non compatible. La bonne correction est une mise à jour du module validée sur préproduction, son remplacement, ou une adaptation par un développeur. Modifier les fichiers du cœur PrestaShop masque parfois le symptôme, mais rend les futures mises à jour difficiles et fragiles.
Cache, compilation et fichiers de thème
Après une mise à jour de thème, de module ou de surcharge, videz le cache avant de conclure à une panne. En environnement de test, vous pouvez désactiver temporairement le cache Smarty et forcer la compilation afin de voir immédiatement les modifications. Ces options dégradent les performances : réactivez les réglages de production après les vérifications.
Si l’erreur survient uniquement sur le front-office, comparez le comportement avec le thème classique ou un thème de test. Une erreur dans un fichier .tpl, un JavaScript non chargé ou une variable Smarty inexistante est plus facile à isoler ainsi. Contrôlez aussi la console JavaScript : une erreur bloquante peut empêcher l’ajout au panier, le calcul de livraison ou l’affichage d’une déclinaison sans générer d’erreur PHP.
Module récemment installé ou mis à jour
Un module est une cause fréquente lorsqu’un bug apparaît juste après son installation ou sa mise à jour. Désactivez d’abord le module depuis le back-office, videz le cache et retestez le scénario. Si l’administration est inaccessible, renommez temporairement son dossier dans modules/ via SFTP, puis videz le cache. Cette méthode permet de confirmer l’hypothèse, mais ne remplace pas une désinstallation propre : une fois l’accès retrouvé, examinez les hooks, les paramètres et les éventuelles modifications de base de données avant toute suppression définitive.
Corriger selon le type d’incident
Erreur 500 ou page blanche
- Activez le mode debug temporairement et consultez le log PHP du serveur.
- Contrôlez la version active de PHP, les extensions requises et les limites mémoire définies par l’hébergement.
- Videz
var/cache/et testez sans le dernier module modifié. - Vérifiez les droits de lecture et d’écriture nécessaires sur les dossiers de cache, d’images et de téléchargement, sans appliquer des permissions trop ouvertes.
- Restaurez un fichier ou un module depuis une sauvegarde uniquement après avoir identifié ce qui a changé.
Une erreur 500 consécutive à une mise à jour partielle peut aussi provenir de fichiers manquants. Comparez alors l’archive officielle correspondant exactement à votre version, sans écraser la boutique en direct. Une mise à niveau interrompue doit être reprise sur une copie restaurée et testée.
Panier, commande ou paiement bloqué
Testez une commande avec un produit simple, une adresse connue et un transporteur actif. Vérifiez ensuite les conditions propres au contexte : devise autorisée, pays, groupe client, zone de livraison, montant minimum et disponibilité du transporteur. Pour un module de paiement, consultez ses journaux et le tableau de bord du prestataire. Un statut « paiement accepté » chez le prestataire mais une commande absente dans PrestaShop peut signaler un appel de notification non reçu, une URL de retour mal configurée, un secret invalide ou un blocage réseau.
Ne créez pas manuellement une commande en base de données pour « réparer » le flux. Réconciliez plutôt les transactions avec les références du prestataire, puis utilisez les fonctions prévues par le module ou une procédure documentée par son éditeur.
Produits, prix ou stock incohérents
Contrôlez la boutique, la langue et le groupe client sélectionnés dans le contexte du back-office, surtout en multiboutique. Examinez les règles de prix spécifiques, les taxes, les devises, les déclinaisons par défaut et la gestion avancée du stock si elle est utilisée. Après un import CSV ou une synchronisation, vérifiez les identifiants produits et déclinaisons : un mauvais identifiant peut mettre à jour un autre article sans provoquer d’erreur visible.
Travailler sur une copie et sécuriser le retour en production
Avant toute correction structurelle, créez une sauvegarde complète et vérifiable : fichiers, base de données et configuration. Une sauvegarde utile doit pouvoir être restaurée. Clonez ensuite la boutique dans un sous-domaine ou un environnement local, avec une base séparée. Désactivez les e-mails sortants et les passerelles de paiement réelles sur cette copie afin d’éviter les commandes ou notifications involontaires.
Appliquez une seule modification à la fois, notez-la, testez le parcours concerné puis contrôlez les logs. Avant la mise en production, prévoyez un créneau calme, un mode maintenance si nécessaire et une procédure de retour arrière. Testez enfin les pages essentielles : accueil, catégorie, fiche produit, panier, livraison, paiement, connexion client et accès au back-office. Cette traçabilité accélère les prochains dépannages et permet de savoir précisément quel correctif a résolu le bug.
Comment passer temporairement une boutique PrestaShop en maintenance ?
Dans le back-office, ouvrez Paramètres de la boutique puis Général et activez l’option de désactivation de la boutique. Ajoutez votre adresse IP aux IP autorisées afin de continuer à tester le site. Vérifiez l’affichage depuis une navigation privée avant et après l’intervention.
Peut-on vider le cache PrestaShop sans perdre les commandes ou les produits ?
Oui. La suppression du contenu du cache régénère des fichiers temporaires ; elle ne supprime ni le catalogue ni les commandes stockées en base de données. Utilisez en priorité le bouton de vidage du cache dans le back-office. Si nécessaire, intervenez sur le contenu de var/cache après sauvegarde.
Pourquoi une erreur n’apparaît-elle que pour certains clients ?
Le comportement peut dépendre du groupe client, de la devise, du pays, d’une règle panier, d’un transporteur ou d’un moyen de paiement disponible. Reproduisez le problème avec le même compte, la même adresse et le même panier pour comparer les règles appliquées.
Faut-il mettre PrestaShop à jour pour corriger un bug ?
Pas systématiquement. Une mise à jour peut corriger une anomalie connue, mais elle peut aussi nécessiter des adaptations de thème et de modules. Identifiez d’abord la cause, vérifiez les prérequis de la version cible et testez la mise à jour sur une copie complète de la boutique.
Quels éléments transmettre à un prestataire pour un dépannage PrestaShop ?
Transmettez l’URL concernée, les étapes de reproduction, l’heure du bug, les captures, les messages d’erreur, les versions de PrestaShop et PHP, ainsi que la liste des changements récents. Fournissez des accès temporaires et limités au back-office ou à l’hébergement, jamais des identifiants personnels non sécurisés.