Corriger une erreur PrestaShop sans aggraver la panne

Une erreur PrestaShop ne se corrige pas en supprimant le cache, en mettant à jour des modules au hasard ou en modifiant la base de données dans l’urgence. Ces actions peuvent effacer des indices utiles, rendre le diagnostic plus difficile ou créer une seconde panne. La méthode la plus sûre consiste à stabiliser la boutique, sauvegarder son état, afficher l’erreur réelle, puis ne modifier qu’un élément à la fois. Cette procédure s’applique aussi bien à une page blanche, une erreur 500, un tunnel de commande défaillant, un back-office inaccessible ou une page 404 inhabituelle.

1. Stopper les changements et relever précisément le symptôme

Avant toute intervention, notez l’URL concernée, l’heure d’apparition, le message affiché, les actions effectuées juste avant la panne et les zones touchées : front-office, administration, fiche produit, panier, paiement ou connexion client. Testez la même page dans une fenêtre de navigation privée et, si possible, avec un autre compte client. Cela évite de confondre un problème de session, de navigateur ou de cache local avec une panne générale.

Ne lancez pas simultanément une mise à jour de PrestaShop, du thème, de PHP et de plusieurs modules. Si une intervention est en cours, annulez-la uniquement si l’outil utilisé le permet explicitement. Une installation interrompue ne doit pas être relancée sans avoir consulté les erreurs : un module peut avoir créé ou modifié des tables, des fichiers de configuration ou des surcharges.

2. Créer un point de retour avant toute correction

Une sauvegarde exploitable comprend les fichiers de la boutique et la base de données MySQL ou MariaDB. Vérifiez qu’elle est datée, stockée hors de l’hébergement si possible, et qu’elle correspond à l’état antérieur au problème. Une sauvegarde automatique ancienne reste utile, mais elle peut contenir des commandes, clients ou produits manquants si vous devez restaurer.

• Exportez la base de données depuis l’outil d’hébergement ou phpMyAdmin.
• Conservez une copie des fichiers, notamment app/config/parameters.php sur PrestaShop 1.7 et 8, ainsi que config/settings.inc.php sur PrestaShop 1.6.
• Si la boutique vend en ligne, prévoyez une fenêtre de maintenance ou limitez les manipulations pendant les périodes de commande.
• Ne restaurez pas immédiatement toute la boutique pour un simple défaut d’affichage : vous pourriez perdre des données récentes sans traiter la cause.

3. Afficher l’erreur utile, sans exposer les détails aux visiteurs

Le mode debug PrestaShop affiche souvent l’exception PHP, le fichier et la ligne impliqués. Dans le back-office, activez-le depuis Paramètres avancés > Performances lorsque l’administration reste accessible. Si elle ne l’est pas, sur PrestaShop 1.7 et 8, modifiez temporairement config/defines.inc.php et remplacez define('_PS_MODE_DEV_', false); par define('_PS_MODE_DEV_', true);. Sur PrestaShop 1.6, le réglage se trouve aussi dans ce fichier.

Faites cette opération pendant un temps limité. Le mode debug peut révéler des chemins de fichiers, des requêtes ou des informations techniques qu’il ne faut pas laisser accessibles publiquement. Reproduisez l’erreur, copiez le message complet et l’heure exacte, puis repassez le mode debug à false.

Consulter les journaux au bon endroit

Le message affiché n’est pas toujours suffisant. Consultez les logs PHP et serveur dans le panneau d’hébergement : ils peuvent mentionner une limite mémoire, une erreur de droits, une extension PHP absente ou une erreur fatale. Dans PrestaShop 1.7 et 8, examinez également les journaux applicatifs dans var/logs/. Une erreur 500 accompagnée de Allowed memory size exhausted n’appelle pas la même correction qu’une erreur indiquant une classe introuvable après l’installation d’un module.

4. Isoler la cause en commençant par le dernier changement

La cause la plus probable est souvent le dernier élément modifié : installation ou mise à jour d’un module, changement de thème, passage à une autre version de PHP, modification d’un override, import de données ou déploiement de fichiers. Comparez cette chronologie avec l’horodatage des logs. Ne vous fiez pas uniquement au nom du fichier signalé : il peut être le point où l’erreur apparaît, pas son origine.

Pour une erreur survenue après une mise à jour de module, désactivez d’abord ce module via le back-office. Si celui-ci est inaccessible, renommez temporairement son dossier dans modules/ par FTP ou SFTP, par exemple modules/monmodule en modules/monmodule.disabled. Testez ensuite la boutique. Cette méthode est préférable à la suppression du dossier : elle permet un retour immédiat et préserve les fichiers nécessaires à l’analyse.

Après chaque test, videz le cache PrestaShop depuis Paramètres avancés > Performances. Si l’administration est indisponible, le cache de PrestaShop 1.7 et 8 se situe généralement dans var/cache/. Supprimez le contenu des sous-dossiers de cache, pas le dossier var lui-même. Ne videz pas aveuglément des dossiers inconnus ni les répertoires de téléchargements, d’images ou de documents.

5. Traiter les cas fréquents sans action destructive

Erreur 500 ou page blanche

Activez le debug et lisez les logs avant de modifier le serveur. Vérifiez la version de PHP réellement utilisée par le domaine, ainsi que les extensions requises par votre version de PrestaShop et vos modules. Un changement de PHP peut rendre un ancien module incompatible. Revenez à la version PHP précédente uniquement comme mesure de stabilisation, puis planifiez la mise à niveau des composants concernés sur une copie de test.

Erreur après changement de thème ou d’override

Repassez temporairement sur le thème précédemment fonctionnel depuis le back-office. Si un override est suspect, identifiez le fichier ajouté ou modifié dans override/ au lieu de supprimer tout le répertoire. Les overrides sont chargés par PrestaShop et peuvent nécessiter une régénération du cache après correction. Une suppression globale peut casser des fonctions encore utilisées par d’autres modules.

Page 404 ou liens réécrits défaillants

Contrôlez d’abord l’URL canonique, la fiche produit ou catégorie concernée et les réglages d’URL simplifiée. Dans Paramètres de la boutique > Trafic & SEO, enregistrez à nouveau les réglages pour demander la régénération des règles de réécriture lorsque cela est pertinent. Vérifiez aussi que le fichier .htaccess est lisible et que la réécriture d’URL est prise en charge par le serveur. Ne copiez pas un .htaccess générique trouvé en ligne : ses règles peuvent ne pas correspondre à votre hébergement ni à votre sous-dossier d’installation.

Panier ou paiement qui ne fonctionne plus

Testez avec un produit simple, un client de test et un seul moyen de paiement. Consultez les logs du module de paiement et les paramètres de retour configurés chez le prestataire. Ne désactivez pas tous les modules de commande en production : isolez celui qui déclenche l’erreur, puis vérifiez sa compatibilité avec la version de PrestaShop, PHP et le thème utilisé.

6. Vérifier le correctif et documenter l’intervention

Une correction n’est validée qu’après des tests ciblés : chargement de la page initialement en erreur, navigation sur plusieurs pages, ajout au panier, connexion client et test de commande si la panne touchait le tunnel. Contrôlez les logs après le test pour vous assurer qu’aucune erreur répétée ne subsiste. Réactivez le cache et désactivez le mode debug.

Consignez enfin la cause, les fichiers ou réglages modifiés, les versions concernées et la sauvegarde disponible. Cette trace facilite une future mise à jour et évite de réappliquer une manipulation risquée. Pour les modifications de code, de thème, de PHP ou de modules essentiels, reproduisez d’abord l’opération sur une préproduction disposant d’une copie de la boutique et de versions comparables.