Sur un déploiement de boutique, la partie la plus stressante n’est pas la mise à jour elle-même. C’est l’après. Celui où tout a l’air “à peu près” en place, sauf que la boutique ne vend plus, que certaines pages tournent en boucle, ou que l’accès aux fiches produits devient erratique. Le scénario arrive souvent quand une mise à jour PrestaShop est lancée sans finition complète: le code a été remplacé, mais pas la base, pas les caches, ou pas les répertoires qui comptent vraiment.
Dans ce billet, je vous raconte comment je gère ce type de dépannage PrestaShop, comment éviter les erreurs classiques qui aggravent la panne, et surtout comment remettre la boutique en état sans repartir de zéro. Même si le sujet est PrestaShop, les réflexes ressemblent beaucoup à ceux du dépannage WordPress et de la réparation site WordPress quand on se retrouve face à une erreur critique ou une erreur 500.
Le symptôme typique: “ça ressemble à une boutique”, mais…
Une mise à jour PrestaShop ratée se présente rarement avec un gros drapeau rouge unique. Le plus souvent, c’est une somme de micro-signaux. Je pense à une boutique de taille moyenne où l’accueil chargeait, mais les catégories renvoyaient une erreur 500, et la page panier affichait un mélange incompréhensible de texte et de boutons sans action. Le back-office, lui, répondait. Pas longtemps. Puis il est devenu lent, puis capricieux.
Quand je vois ce pattern, je suspecte un déploiement incomplet avant même de regarder les logs. Les causes les plus fréquentes que j’ai rencontrées:
- une version de PrestaShop mise à jour en fichiers, mais pas les scripts nécessaires dans la base de données
- un cache non vidé, ou mal re-généré, donc des classes et templates vieux restent en mémoire
- une configuration de PHP ou d’extensions qui n’est plus compatible avec la nouvelle version
- des dossiers non transférés correctement (par exemple
cache/,var/, ou des fichiers de thème modifiés) - un mode maintenance qui n’est jamais sorti, ou un fichier de maintenance laissé en place
Le point commun, c’est que tout semble “presque bon”, et c’est précisément là que les équipes se trompent. Elles repartent en modifiant plusieurs choses à la fois. Résultat: au lieu de corriger la panne, elles brouillent le diagnostic. Quand on fait du dépannage site internet, la première urgence est de retrouver un signal clair.
Comprendre ce qui a vraiment été déployé (avant de toucher)
La meilleure réparation site PrestaShop commence par un inventaire. Pas un inventaire théorique, concret: qu’est-ce qui a été remplacé, qu’est-ce qui a été migré, qu’est-ce qui a été laissé.
J’ai pris l’habitude de demander (ou de vérifier si j’ai accès) ces éléments juste après l’incident:
1) Quelle commande ou méthode a été utilisée pour la mise à jour
Module en ligne, mise à jour manuelle, remplacement via FTP, déploiement CI/CD, script, etc. La manière change tout.
2) À quel moment ça a cassé
Pendant le transfert des fichiers, juste après la migration, après un vidéage de cache, ou après un redémarrage PHP-FPM.
3) Quelle est l’erreur visible
Page blanche PrestaShop, erreur 500, erreurs PHP affichées, redirections infinies, impossibilité d’accéder aux pages du front, ou accès back-office partiel.
4) Quelles données ont été modifiées
Tables de base de données touchées, scripts exécutés, index recalculés, réglages de “maintenance”.
Cette phase est importante aussi pour le dépannage WordPress. Quand une mise à jour WordPress ratée laisse une boutique en état instable, on retrouve le même mécanisme: les fichiers et la base ne sont pas synchronisés, et l’erreur critique (souvent un comportement de type “erreur 500 WordPress” ou un plantage plus net) masque la cause réelle.
Détecter la nature de la panne: front, back-office, ou les deux
Sur PrestaShop, distinguer le front du back-office est un levier de diagnostic très puissant. Un exemple concret:
- Si le back-office se charge mais pas le front, je pense d’abord à un souci de cache, de thème, de droits sur fichiers, ou à des classes front-end (smarty, templates, override, hooks) qui ne correspondent plus au code actuel.
- Si le front charge mais que certaines pages renvoient une page blanche PrestaShop, je soupçonne un template ou un contrôleur qui échoue, souvent lié à une base incohérente ou à un fichier manquant.
- Si les deux sont instables, je regarde la configuration globale: PHP, extensions, limites mémoire, et état de la base.
Ce tri permet d’éviter la “chasse au bug” à l’aveugle. J’ai vu des équipes s’acharner sur le thème alors que le problème était un script de migration inachevé dans la base, ou inversement: elles ont réparé la base sans résoudre un répertoire inaccessible au PHP.
Les pièges qui aggravent après une mise à jour PrestaShop ratée
Il y a deux pièges typiques, ceux qui font perdre des heures:
Piège 1: relancer la mise à jour en boucle
Quand on pense que “ça a peut-être raté”, on relance la mise à jour. Mais si la base est déjà partiellement migrée, relancer peut créer une incohérence. On bascule alors d’un problème localisé vers une panne plus générale. Dans les cas extrêmes, on se retrouve avec une boutique inaccessible, et le back-office refuse de démarrer correctement.
Piège 2: toucher aux fichiers sans plan
Remplacer des dossiers “au feeling” peut remettre une page à peu près, mais casser un autre point plus tard. Dans une maintenance PrestaShop, je préfère une approche chirurgicale. On remet à niveau ce qui doit l’être, puis on valide étape par étape, sinon on ne sait plus ce qui a corrigé.
Premier diagnostic rapide: quoi vérifier en 15 à 30 minutes
Avant d’ouvrir tous les dashboards, je commence par des checks rapides, parce qu’ils donnent un axe immédiatement. Je l’utilise aussi en réparation site WordPress, notamment quand on doit différencier une panne classique d’une intrusion (par exemple un site WordPress piraté qui déclenche des comportements inattendus).
Voici les signes qui reviennent dans les mises à jour PrestaShop incomplètes:
- Page blanche ou écran blanc sur le front, parfois avec des erreurs PHP en arrière-plan
- Erreur 500 sur une partie des pages, souvent cohérente avec des routes spécifiques
- Redirections vers la maintenance, ou absence de sortie propre du mode maintenance
- Back-office lent, incohérent, ou qui charge sans fonctionnalités
- Logs qui mentionnent des classes manquantes, des méthodes absentes, ou des migrations incomplètes
Pour un diagnostic rapide, je cible:
- le log applicatif (erreurs PHP)
- le log serveur (Apache/Nginx, parfois 502/504 qui masquent autre chose)
- l’état des répertoires de cache et des permissions
- la compatibilité PHP (version exacte, extensions disponibles)
Je ne force pas “toutes les réparations”. Je cherche d’abord à comprendre ce qui manque ou ce qui ne correspond plus.
Mettre la boutique en sécurité avant réparation (oui, même en urgence)
Quand on parle d’urgence WordPress ou d’urgence sur PrestaShop, on pense “réparer vite”. Mais une réparation site internet mal cadrée peut aggraver l’impact, notamment si vous avez déjà un trafic réel.
Même si vous êtes pressé, j’insiste pour faire au minimum:
- une sauvegarde base de données (dump) et une sauvegarde des fichiers avant toute correction lourde
- un accès limité pendant la maintenance, pour éviter des modifications pendant qu’on corrige
- une mise en place d’un environnement de test si vous avez la possibilité (parfois sur un sous-domaine avec une copie)
Dans un cas où je devais intervenir sur une boutique PrestaShop inaccessible, on avait “juste assez” de temps pour faire un dump minimal. Ça a sauvé la situation quand une étape de migration a cassé des index et qu’on a pu revenir en arrière.
Vérifier la compatibilité de l’environnement PHP
On oublie souvent que la mise à jour, ce n’est pas seulement “le code PrestaShop”. C’est aussi l’environnement. Et sur un hébergement, l’environnement change parfois sans que personne ne le signale: upgrade PHP côté serveur, réglage de memory_limit, extension manquante, opcache, etc.
J’ai déjà vu une boutique passer d’un PrestaShop compatible à un autre qui exige un minimum d’extensions. Le résultat n’était pas toujours un gros crash immédiat. Parfois, c’était subtil: certains écrans marchaient, d’autres plantaient. Et si vous voyez des erreurs de type “Class not found” ou des warnings qui deviennent fatals, c’est souvent là qu’il faut regarder.
Si vous observez une erreur 500, vérifiez:
- la version de PHP
- les extensions (selon la version PrestaShop)
- les limites mémoire
- les droits sur les dossiers (cache, logs)
Dans le dépannage WordPress, cette vérification est aussi un classique, notamment quand un site WordPress en panne commence à afficher une erreur 500 WordPress après une mise à jour ou un changement d’hébergement.
Réparer après déploiement incomplet: stratégie de remise à niveau
Une fois le diagnostic orienté, le travail consiste à aligner fichiers et base. Sur PrestaShop, j’utilise une logique en trois temps: restaurer la cohérence, vider et régénérer ce qui doit l’être, puis vérifier les points de rupture.
1) Ré-aligner les fichiers PrestaShop “propres”
Si le déploiement s’est fait par copie partielle, c’est un candidat numéro un. Je remplace le cœur de PrestaShop par la version attendue, en veillant à préserver:
- les thèmes personnalisés
- les modules installés (au moins ceux nécessaires)
- les répertoires de logs si vous voulez garder une trace
- les configurations spécifiques (selon le cas)
Ensuite, je vérifie si des overrides ou des templates modifiés persistent. Sur PrestaShop, un thème custom ou un module qui s’appuie sur des comportements anciens peut déclencher des pages cassées après mise à jour.
2) Vérifier l’état de la base
Si des migrations ont été lancées en partie, certaines tables ou structures peuvent être incohérentes. Dans ce cas, on a deux approches: relancer proprement les scripts de migration ou corriger l’état avec les bonnes commandes, selon ce que PrestaShop attend.
La prudence est importante. Relancer “comme ça” peut empirer, surtout si la base a déjà été touchée. Je m’appuie sur ce que j’observe dans les logs et sur l’état réel des tables plutôt que sur une supposition.
3) Vider les caches et régénérer
Même quand la base et les fichiers sont OK, un cache vieux peut provoquer une page blanche PrestaShop, un comportement étrange ou une erreur sur des routes précises.
Je vide et je régénère ce qui est cohérent avec la version. Si vous utilisez un cache serveur (reverse proxy, varnish, cache navigateur), il faut aussi le purger. Sinon, vous “réparez” mais vous regardez encore une version servie depuis un cache externe.
C’est là qu’on confond souvent dépannage et maquillage. Une purge de cache n’est pas une solution si la base reste cassée, mais elle est indispensable pour valider une correction.
Gestion du cas particulier: page blanche et erreurs sur des routes spécifiques
La page blanche est le symptôme qui fait paniquer parce qu’elle donne peu d’information. Pourtant, elle est souvent le résultat d’un plantage PHP non correctement journalisé, ou d’un template qui ne peut pas être rendu.
Quand j’ai une page blanche, je fais généralement ceci dans l’ordre:
- activer/collecter les logs si c’est possible (ou utiliser les logs existants)
- isoler la route qui plante (produit, catégorie, panier, paiement, compte)
- comparer les pages qui marchent et celles qui cassent
- vérifier si un module spécifique est impliqué (paiement, livraison, search, optimisation)
Si la route “panier” casse, je pense à une incohérence produit/stock, à un module de paiement, ou à une configuration qui a changé de structure.
Dans d’autres contextes, on retrouve la même logique côté WordPress: une erreur critique WordPress ou une erreur 500 WordPress qui apparaît sur certaines pages seulement indique souvent un plugin ou un thème touché, ou une différence de configuration en base.
Et si ce n’est pas seulement une mise à jour ratée: vérifier la piste “site piraté”
Parfois, le diagnostic “mise à jour incomplet” n’est qu’une hypothèse rassurante. J’ai déjà vu des situations où un site WordPress piraté ou une compromission déclenche des comportements qui ressemblent à une panne de déploiement. Le timing coïncide, les symptômes aussi, et on s’arrête à tort à la mise à jour.
Sur PrestaShop, le même principe vaut. Si vous constatez des éléments inhabituels dans les fichiers, des modules récemment injectés, ou des redirections, il faut prendre au sérieux la piste d’un accès non autorisé.
Ce que je regarde en priorité, avec bon sens:
- présence de fichiers créés récemment dans des zones sensibles
- modifications de scripts PHP hors période de déploiement
- comptes administrateurs ajoutés sans trace
- templates modifiés au-delà du thème prévu
Si vous êtes dans une situation de réparation site WordPress piraté, le réflexe est le même: ne pas “réparer le symptôme” tant que l’origine n’est pas traitée.
Exemple de plan de correction concret (sans tomber dans le chaos)
Dans un incident récent, après une mise à jour PrestaShop, l’accueil était là, mais le catalogue renvoyait des erreurs et le front donnait parfois des messages d’exception. On a d’abord essayé d’améliorer le thème, puis on a perdu une demi-journée. La vraie cause était un ensemble de fichiers remplacés sans synchroniser les éléments de base. Le cache gardait ensuite des traces de l’ancien fonctionnement, ce qui rendait l’état incohérent.
Une approche plus robuste, que j’applique dans ce genre de situation, ressemble à ceci:
1) Geler toute modification pendant le diagnostic, et ne réexécuter aucune migration “pour voir” 2) Restauration des fichiers du cœur de PrestaShop à la bonne version, en préservant ce qui est custom 3) Vérifier l’état des migrations et corriger seulement ce qui est nécessaire 4) Purger caches et valider route par route, en commençant par les pages les plus simples
C’est une séquence simple sur le papier, mais elle évite le “bricolage progressif”.
Cas proche: WooCommerce en panne et le parallèle avec PrestaShop
Même si WooCommerce est un plugin WordPress, les incidents qui suivent une mise à jour ratée se ressemblent. WooCommerce en panne n’implique pas forcément un problème WooCommerce lui-même, parfois c’est le thème, l’état de la base, ou une incompatibilité de versions.
Ce parallèle aide à structurer le dépannage site internet: on cherche toujours la cohérence entre code et base, on contrôle l’environnement, et on isole la fonctionnalité cassée. Une boutique qui ne peut plus afficher les produits, ou qui bloque le checkout, se traite de manière comparable à PrestaShop, même si la mécanique interne change.
Comment réduire les risques lors des prochaines mises à jour PrestaShop
On ne peut pas éliminer le risque, mais on peut le rendre rare et gérable. Les équipes qui s’en sortent bien ne sont pas celles qui “font moins d’essais”. Ce sont celles qui industrialisent la vérification.
Je recommande d’instaurer, avant la mise à jour:
- un test sur copie de la boutique
- une fenêtre de déploiement courte, avec notification claire
- une checklist technique et un plan de rollback
- des règles pour ne pas toucher au code custom pendant la migration
Le but n’est pas d’ajouter une usine à gaz. C’est de s’éviter la situation où, après un déploiement incomplet, tout le monde cherche la cause en même temps.
Dans l’univers WordPress, ces mêmes pratiques existent sous la forme de maintenance WordPress propre, et elles évitent les “mise à jour WordPress ratée” qui se traduisent par une erreur critique WordPress, voire une erreur 500 WordPress persistante.
Checklist de sortie de panne (courte et utile)
Une fois la boutique réparée, je fais une validation stricte, pas uniquement “ça charge”. Voici ce que je vérifie, en restant concis:
- accueil et navigation catégories, avec 2 ou 3 produits testés
- ajout au panier et mise à jour quantité, même en mode catalogue restreint
- page produit complète, y compris images, options et disponibilité
- passage en maintenance désactivé, et vérification du fichier de configuration concerné
- back-office: ajout ou édition rapide d’une fiche produit en test
Si une seule de ces étapes échoue, je considère que la panne n’est pas complètement résolue, parce qu’un utilisateur ne pardonne pas un panier qui casse après une belle page d’accueil.
Réparer n’est pas seulement “remettre en marche”, c’est retrouver la confiance
Le vrai coût d’une mise à jour PrestaShop ratée, ce n’est pas le temps passé sur la correction. C’est la perte de confiance. Les clients qui ne comprennent pas “pourquoi ça marche aujourd’hui et pas demain”, les équipes marketing qui n’ont plus de visibilité, et l’angoisse de la prochaine maintenance.
Quand je termine un dépannage PrestaShop bien fait, je laisse toujours une trace claire de ce qui a été corrigé, et surtout de ce qui a été évité: quels ajustements ont été tentés, ce qui a été écarté, et ce qui reste surveillé.
Si vous êtes en situation de site PrestaShop en panne, ou si vous subissez une page blanche maintenance PrestaShop PrestaShop, ne confondez pas la rapidité et l’efficacité. Un correctif réfléchi, guidé par les logs et la cohérence code-base, remet la boutique durablement d’aplomb.
Et si, en parallèle, vous avez aussi un site WordPress en panne sur la même infrastructure, les réflexes restent les mêmes: diagnostic, cohérence, environnement, caches, et attention à la piste “site WordPress piraté” quand quelque chose ne colle pas au scénario attendu.
Si vous me décrivez votre symptôme exact (erreur 500, page blanche, redirection maintenance, back-office fonctionnel ou non) et la méthode de déploiement utilisée, je peux vous proposer une séquence de vérification plus ciblée, adaptée à votre cas.