Sur un site e-commerce, une mise à jour qui “se passe mal”, ce n’est pas un simple incident technique. C’est une friction directe avec vos ventes, vos clients et, parfois, votre image. J’ai déjà vu des boutiques tourner en boucle sur la même page, d’autres qui basculent en “page blanche”, et quelques cas plus pénibles où l’administration semblait accessible mais le front explose au moment de charger des ressources ou des overrides.
Le scénario le plus fréquent que j’entends sur le terrain ressemble à ça : vous lancez une mise à jour PrestaShop (souvent via le back-office ou par le mécanisme de mise à jour système), ça commence, puis ça coince. Résultat, la boutique n’affiche plus correctement, certaines pages renvoient des erreurs, ou la boutique ne “revient” pas après plusieurs minutes de patience.
Dans cet article, je vais vous raconter comment je gère une mise à jour PrestaShop ratée quand il faut remettre en service vite, puis contrôler proprement les modules. L’idée n’est pas de “bricoler” jusqu’à ce que ça marche, mais de retrouver un fonctionnement stable, en limitant les risques de récidive.
Ce que “mise à jour ratée” veut vraiment dire côté PrestaShop
PrestaShop est tolérant quand tout est bien préparé, mais il n’aime pas les demi-mesures. Une mise à jour peut échouer de différentes manières, et la stratégie de dépannage change selon les symptômes.
Par exemple, si l’erreur vient du back-office, vous pouvez parfois restaurer une bonne partie du contexte (fichiers, base de données) sans perdre la main. Si le problème est surtout côté front (pages boutique, catégorie, panier, paiement), il faut regarder ce qui charge au moment où le navigateur demande les pages.
Même logique si vous avez déjà “touché” à l’habillage, au thème, ou à des modules qui surchargent le comportement du catalogue. Une mise à jour PrestaShop peut être compatible avec le noyau, mais pas avec un module qui s’accroche à une ancienne architecture.
Et quand je dis “module”, je ne parle pas uniquement des modules installés depuis PrestaShop Addons. Je pense aussi aux modules maison, aux “addons” qui dépendent d’une version PHP ou d’une version de librairies, et aux plugins SEO et cache qui modifient l’output.
Les premiers réflexes avant de retomber dans le piège “on re-teste et ça empire”
Quand le site est instable, la pire chose à faire est de multiplier les tests dans le même temps, surtout si vous avez un cache agressif (côté PrestaShop, sur le serveur, via un CDN, ou via un plugin). Les symptômes se brouillent. Un essai peut “masquer” un autre problème.
J’agis souvent dans cet ordre, même quand je suis en urgence :
1) stabiliser l’accès
2) récupérer les indices (logs et messages) 3) revenir à un état connu, quand c’est possible 4) ne re-activer les modules qu’après avoir validé l’environnement
Ça rejoint aussi ce que je pratique en dépannage WordPress. Quand un site WordPress affiche une erreur critique WordPress, ou pire une erreur 500 WordPress, je commence par la même logique : stopper l’escalade, vérifier les logs, et éviter les cycles de rechargement qui finissent par casser davantage.
Sur un hébergement mutualisé, c’est encore plus vrai. Un pic de requêtes ou une dépendance PHP qui saute, et vous avez des comportements “fantômes” qui donnent l’impression que tout est cassé alors que la racine est plus précise.
Comprendre le symptôme pour choisir la bonne réparation
Sur PrestaShop, les symptômes les plus fréquents après une mise à jour ratée, ce sont :
- La boutique renvoie une page blanche, surtout après un clic dans l’administration ou au moment de charger le front.
- Certaines pages fonctionnent, d’autres échouent (souvent panier, commande, compte client).
- L’administration répond, mais le front casse (cache, overrides, modules).
- Des erreurs apparaissent en cascade dans les logs (fichiers manquants, classes introuvables, erreurs PHP).
Je ne vous demande pas de deviner au hasard. Le bon réflexe, c’est d’utiliser ce que le site vous dit.
Si vous êtes en mesure d’accéder aux logs d’erreur PHP ou au journal d’erreur du serveur, vous gagnez un temps énorme. Sur beaucoup d’installations, on trouve des messages du style “class not found”, “call to undefined function”, “fatal error”, ou des problèmes d’incompatibilité de signatures.
Et souvent, ces messages pointent directement vers un module ou vers un fichier modifié. Ça ne veut pas dire que le module est coupable à 100%, mais c’est un indice.
Remettre en service : revenir à un état fonctionnel, puis isoler
La remise en service doit être rapide, mais pas au prix de la confusion. Mon objectif est simple : faire revenir un site utilisable, même avec des fonctionnalités dégradées, puis remettre l’ensemble d’aplomb.
Le “plan de terrain” dépend de votre situation de départ :
Si vous avez une sauvegarde fiable
Si vous avez une sauvegarde de fichiers et une sauvegarde de base de données avant la mise à jour, c’est le meilleur levier. Je commence par restaurer l’état précédent pour rétablir le service. Ensuite seulement, on investigue.
Une sauvegarde de base de données seule, sans les fichiers, peut suffire dans certains cas, mais ce n’est pas mon choix par défaut. PrestaShop, c’est un ensemble cohérent de fichiers et de tables. Les incohérences coûtent cher en temps.
Si vous n’avez qu’une partie des éléments
Si les fichiers ont été mis à jour, mais que la base de données a gardé son ancien état (ou l’inverse), vous pouvez vous retrouver avec des erreurs très spécifiques. Dans ce cas, je privilégie l’analyse avant restauration complète.
Concrètement, je compare les fichiers, je cherche les changements récents dans les dossiers critiques (cache, override, modules, themes), et je vérifie si des modules ont été partiellement mis à jour.
Si la boutique est inaccessible à grande échelle
Quand la boutique est réellement inaccessible, je travaille en mode “urgence”. L’objectif est de rétablir un minimum de pages, souvent la home et les catégories, pour couper la mortalité de trafic et réduire la gêne.
J’ai déjà géré des cas où l’on pouvait afficher l’essentiel en désactivant temporairement certains modules à gros impact (cache, SEO, tracking, paiement), puis en réactivant progressivement.
La vérification des modules : le vrai nœud du problème
Après une mise à jour PrestaShop ratée, la majorité des mauvaises surprises viennent d’un module qui n’est pas compatible avec la nouvelle version, ou qui s’exécute trop tôt, trop tard, ou avec une dépendance absente.
Je fais rarement un “tout est cassé” global. Au contraire, je préfère isoler. En général, les modules posent problème de trois manières :
- Un module appelle une classe ou une méthode qui n’existe plus (erreur fatale côté PHP).
- Un module dépend d’une version PHP qui a changé, ou d’une extension manquante.
- Un module modifie des hooks ou des templates qui ont été adaptés lors de la mise à jour, entraînant des collisions.
Quand je m’occupe d’une boutique qui a aussi un historique WooCommerce, je garde le même esprit. Avec WooCommerce, on voit parfois un “effet cascade” après changement de version, thème, ou plugin. Le mécanisme est similaire : le plugin qui s’accroche à un comportement interne et provoque une panne sur une route spécifique.
Si votre boutique PrestaShop est sur la même infrastructure que d’autres sites WordPress, ce n’est pas rare que vous ayez aussi à gérer une maintenance WordPress en parallèle (ou un incident WordPress en même temps). Ça arrive notamment quand vous avez des administrateurs qui utilisent les mêmes outils, les mêmes sauvegardes, ou les mêmes processus d’intervention.
Un diagnostic propre : quelles traces chercher et où
Avant de toucher au moindre module, je cherche des indices. Les logs ont souvent un niveau de détail suffisant pour faire gagner des heures.
Dans un dépannage WordPress, quand on voit une erreur 500 WordPress, je regarde dans les logs PHP, je vérifie si un plugin a été mis à jour juste avant l’incident, et je teste l’accès à l’administration en mode dégradé. Pour PrestaShop, la logique est similaire, juste avec des chemins différents.
Concrètement, je m’appuie sur :
- Les erreurs PHP dans les logs serveur
- Les messages d’erreur affichés dans le front, quand ils sont visibles
- Le comportement par zone : front, back-office, panier, commande
Si un module déclenche une erreur dès le chargement, vous le verrez presque immédiatement. Si l’erreur ne se produit que sur certaines pages, vous pouvez suspecter un hook ou un override spécifique.
Ce point est crucial : vous n’allez pas vérifier tous les modules dans le même temps si votre problème ne se manifeste que sur une page “paiement”. Là, votre investigation doit viser la chaîne de paiement, les modules de transport, et les règles de checkout.
Checklist de remise à plat des modules (sans tout casser)
Voici une façon de procéder que j’utilise quand je dois être efficace et méthodique. L’idée est d’avoir une liste courte, actionnable, et surtout contrôlable. Pas une chasse au module au hasard.
- Vérifier que le dossier de cache de PrestaShop est cohérent, et supprimer les caches seulement quand vous êtes prêt à recharger le site.
- Désactiver temporairement les modules “à hooks lourds” (cache, SEO, tracking, paiement) un par un, pas tous d’un coup.
- Inspecter les erreurs dans les logs après chaque désactivation pour confirmer la causalité.
- Vérifier les dépendances PHP côté serveur (versions, extensions nécessaires) par rapport aux modules en cause.
- Réactiver progressivement, en testant d’abord les routes critiques (home, catégorie, produit, panier, commande).
Cette séquence limite les risques. Vous évitez le classique “on désactive tout, ça marche, puis on ne sait pas ce qui a vraiment causé la panne”.
Quand vous devez remettre à jour ou reconfigurer un module
Parfois, le module n’est pas cassé par incompatibilité, il est cassé par configuration. Une mise à jour PrestaShop peut changer des paramètres attendus, ou déplacer des options.
Dans ces cas, vous verrez souvent une erreur qui ressemble à un élément manquant en base de données, ou à une valeur “null” là où le module attend un identifiant.
Je m’en sors avec une approche très pragmatique : je replace le module dans un état “minimum viable”, puis je réintroduis la configuration.
Exemple typique : un module SEO ou un module de redirection peut s’appuyer sur des champs spécifiques. Après la mise à jour, si le module a conservé une config partielle, il peut produire des URL invalides ou déclencher une erreur quand il construit la liste de règles.
Idem pour des modules de paiement : si la configuration de la devise, du pays, ou du mode de livraison change par effet de bord, certains modules se mettent à planter au moment du calcul final.
Le cas délicat : page blanche PrestaShop et collision d’override
La page blanche PrestaShop est un symptôme qui fait peur, mais il ne dit pas toujours “fatal error dans tout le système”. Souvent, c’est :
- une erreur PHP fatale exécutée au premier chargement
- un fichier modifié (thème, override, ou module)
- un cache qui persiste une sortie incohérente
Quand c’est une collision d’override, j’observe fréquemment une différence entre l’affichage front et l’accès au back-office. Parfois, le back-office répond, mais le front ne rend pas. Le point commun, c’est le moment où PrestaShop charge certains hooks.
Je commence par vérifier ce que j’ai le droit de considérer comme “suspect” :
- modules récemment ajoutés ou modifiés
- thème ou enfant de thème
- override custom (parfois de petits ajustements qu’on croit “sans impact”)
Un override qui dépend d’un ancien nom de classe peut provoquer une page blanche sans message utile dans le front, alors que les logs révèlent l’origine. C’est pour ça que je reviens toujours aux journaux.
Et si la boutique refuse de se lancer après la mise à jour, malgré tout ?
Quand je suis face à une situation où PrestaShop semble “refuser” de démarrer après une mise à jour, le diagnostic doit passer par un retour contrôlé.
Ce que je fais dans ces cas-là :
- Restaurer une version précédente si possible
- Réappliquer les changements de manière séquencée
- Vérifier l’environnement PHP, car un décalage de version peut rendre certains modules invisibles ou incompatibles
Il m’est arrivé aussi de voir des incidents où le problème n’était pas strictement PrestaShop, mais un environnement instable (mémoire PHP insuffisante, timeout serveur, limitations applicatives). C’est rare, mais ça arrive, surtout si la mise à jour a augmenté le volume de traitements au premier lancement.
Et si vous êtes en contexte WordPress à côté, vous pouvez retrouver un profil similaire : site WordPress en panne, maintenance WordPress mal faite, ou tentative de restauration après mise à jour WordPress ratée. Les deux univers partagent la même douleur quand l’hébergement ne suit plus.
Mini scénario réel (sans théâtre, juste le bon déroulé)
Je repense à une boutique qui avait tenté une mise à jour PrestaShop sur un hébergement assez chargé. Après la mise à jour, le front s’est mis à afficher des erreurs sur la page produit, puis sur le panier. L’administration, elle, restait accessible.
La première lecture des logs a montré un pattern. L’erreur pointait un module de personnalisation, et le message précisait une classe liée à un format plus ancien. Je n’ai pas cherché à deviner. J’ai désactivé le module concerné, puis j’ai rechargé uniquement la route produit.
Résultat : la boutique a repris vie, avec une fonctionnalité manquante (le module ne faisait plus le décor), mais au moins le client pouvait acheter. Ensuite, j’ai récupéré la version du module compatible avec la version de PrestaShop, puis j’ai réactivé progressivement.
C’est un bon exemple de la différence entre “mettre en ligne vite” et “mettre en ligne propre”. La première étape sauve le chiffre d’affaires, la deuxième évite que le même incident revienne.
Bonus utile : surveiller les risques de sécurité pendant la remise en service
Une mise à jour ratée ne veut pas dire piratage. Mais quand un site “fait n’importe quoi” après un changement, il faut au moins regarder les signaux.
Ce que je fais, c’est une vérification raisonnable, sans paranoïa : cohérence des fichiers, présence d’éléments inattendus dans les dossiers de modules, et contrôle des points d’entrée.
Dans un dépannage WordPress, je vois parfois des cas de site WordPress piraté, et dans ces situations, on doit gérer à la fois la sécurité et la réparation. Même logique en PrestaShop, même si les chemins sont différents. Si vous suspectez une compromission, la remise en service doit inclure la purge, la réinstallation de composants propres, et la rotation des accès.
Si vous n’avez aucun indicateur (pas d’utilisateur suspect, pas de modifications bizarres, pas de fichiers récemment créés), vous pouvez vous concentrer sur la compatibilité modules et l’environnement.
Quand demander de l’aide, et quoi préparer avant l’intervention
Vous pouvez faire beaucoup en autonomie, surtout si vous avez une sauvegarde et un accès aux logs. Mais il arrive un moment où multiplier les essais devient un coût.
J’estime qu’il faut externaliser ou faire intervenir quelqu’un quand :
- la boutique est bloquée sur un fatal error difficile à remonter
- les logs sont incomplets ou inexploitables
- il y a trop de modules custom et vous ne savez pas ce qui a été modifié
- la mise à jour a déjà été tentée plusieurs fois et l’état actuel est incohérent
Avant une intervention, je demande toujours la même matière. Ça accélère tout. Fournissez au minimum la version de PrestaShop avant/après, la date de la mise à jour, le symptôme exact (page blanche, erreur sur panier, erreur 500 PrestaShop si vous voyez un message), et, si possible, un extrait des erreurs dans les logs.
Si vous avez aussi un contexte WordPress, et que vous devez faire du dépannage WordPress en urgence en parallèle, précisez-le. Souvent, les équipes techniques utilisent les mêmes processus de maintenance WordPress et les mêmes contraintes d’hébergement.
Les deux erreurs classiques à éviter après une mise à jour ratée
Je les vois revenir très souvent :
D’abord, “on met à jour tout à nouveau”. Non seulement vous risquez d’aggraver l’incompatibilité, mais vous perdez la trace de ce qui causait la panne.
Ensuite, “on désactive tout et on prie”. Oui, ça peut remettre en ligne rapidement, mais vous finissez par réactiver plus tard et vous n’avez plus d’hypothèse solide. Vous ne savez plus quel module a déclenché quoi. La réparation devient une loterie.
La méthode que je privilégie consiste à isoler, confirmer, WooCommerce en panne puis traiter. C’est plus lent au départ que de tout couper, mais beaucoup plus rapide sur le résultat final, parce que vous gardez une chaîne de causalité.
Remettre en service, puis faire durer la solution
Une boutique revenue à la normale, ce n’est pas la fin du travail. Le vrai objectif, c’est la stabilité.
Après avoir identifié le module ou la cause principale, je recommande de vérifier :
- que le cache est sain
- que les versions de modules critiques sont compatibles
- que le thème n’a pas d’override fragile
- que l’environnement PHP reste aligné
Et surtout, je conseille de ne pas laisser un “patch de fortune” en place. Par exemple, désactiver un module de paiement pour sauver le front, pourquoi pas temporairement, mais il faut ensuite sécuriser la version compatible. Pareil pour un module de SEO : si vous le laissez désactivé, vous perdez en visibilité et ça crée une deuxième urgence.
J’ai déjà vu des équipes basculer dans une spirale, d’abord une mise à jour PrestaShop ratée, puis une maintenance WordPress en parallèle, puis une tentative de correction trop tardive. On finit avec un site internet difficile à diagnostiquer, surtout quand plusieurs couches ont bougé.
Si vous devez retenir une idée, ce serait celle-ci
Une mise à jour PrestaShop ratée se traite mieux quand vous séparez deux choses : la remise en service et la vérification des modules.
Remettre en service, c’est redonner accès au front rapidement, même avec quelques fonctions dégradées. Vérifier les modules, c’est comprendre ce qui ne passe plus et remettre une compatibilité propre, en testant route par route.
Cette approche marche aussi quand vous gérez d’autres plateformes en parallèle, comme du dépannage WordPress, une réparation site WordPress, ou une urgence WordPress avec erreur critique. Les détails changent, la méthode reste la même : isoler, lire les indices, valider la cause, puis corriger sans brûler les étapes.
Si vous me décrivez votre cas (version de PrestaShop, ce que vous voyez à l’écran, et si vous avez accès aux logs), je peux vous proposer un chemin de diagnostic adapté, module par module, sans vous faire tourner en rond.