Quand un site PrestaShop bascule en page blanche, ça donne l’impression que tout s’est arrêté net. Pas d’erreur claire, juste un écran vide. Et dans les premières minutes, on pense rarement à la racine du problème, on pense surtout à faire revenir le panier, la navigation, les paiements. Le vrai défi, c’est d’abord de relancer vite sans empirer la situation, puis de comprendre pourquoi ça s’est produit, pour que ça ne revienne pas à la première mise à jour, au premier changement de thème, ou au prochain pic de trafic.
Je vais te guider comme on le fait sur le terrain, avec une logique de dépannage site internet: sécuriser, diagnostiquer, restaurer, puis durcir. Et oui, je vais aussi te parler de maintenance et de mise à jour ratée, parce que dans beaucoup d’incidents PrestaShop, l’étincelle vient d’un changement récent, comme on le voit aussi sur WordPress (erreur 500, erreur critique WordPress, site WordPress en panne après une mise à jour). Les mécanismes sont différents, mais la méthode de travail se ressemble.
La page blanche, ce que ça veut vraiment dire dans PrestaShop
Une page blanche PrestaShop peut venir de plusieurs couches, et c’est pour ça que “c’est cassé” ne suffit pas. Dans la pratique, tu peux avoir:
- un problème PHP (erreur fatale, mémoire épuisée, extension manquante, syntaxe cassée)
- un souci de permissions (fichiers ou dossiers inaccessibles)
- une erreur de cache (carte bloquée par une classe non chargée)
- un thème ou un module qui plante au chargement
- une config serveur (opcache, mode production, déclenchement de log désactivés)
- parfois, un élément plus sérieux comme une compromission (moins fréquent, mais à ne pas ignorer)
Le point commun, c’est le manque d’information à l’écran. Donc la première priorité n’est pas d’improviser, c’est de récupérer des indices. Sur un site WordPress en panne, on fait souvent apparaître l’erreur en mode debug. Sur PrestaShop, c’est la même idée, mais avec des paramètres et emplacements légèrement différents.
Les 10 premières minutes: relancer sans casser davantage
Avant de toucher à 40 choses, j’essaie de suivre un ordre simple. Pas “magique”, juste rationnel. Tu as besoin de revenir en ligne et de limiter les dégâts pendant que tu fais le diagnostic.
1) Vérifie que tu n’as pas uniquement un souci côté navigateur Un écran blanc peut aussi venir de cache navigateur, d’une extension bloquante, ou d’un souci CDN. Essaie tout de suite un test depuis un autre appareil, ou en navigation privée. Puis vérifie si l’ensemble du site est blanc, ou seulement certaines pages (category, product, back office). Si le front est blanc mais le back office répond, ça oriente déjà fortement.
2) Contrôle l’accès au back office Si le back office s’affiche et que tu peux te connecter, tu as plus de marge pour inspecter des modules, des fichiers, et vider les caches proprement. Si même l’admin est blanc, le problème touche probablement le socle PHP ou un fichier central.
3) Regarde les logs C’est là que tout se joue. Sur l’hébergement, tu as généralement des logs d’erreur PHP (Apache ou Nginx), parfois un fichier spécifique dans la console. Cherche les timestamps autour du moment où la page blanche a démarré. Une erreur du type “Fatal error” ou “Allowed memory size exhausted” suffit déjà à orienter.
4) Ne modifie pas en aveugle Si tu supprimes un module au hasard, tu peux retirer la cause mais aussi retirer la solution. Si tu reconstruis un thème mal configuré, tu peux rendre le site encore moins lisible. L’objectif, c’est d’alterner prudence et efficacité.
5) Prépare un plan de retour arrière Même si tu n’as pas l’habitude, crée un point de repère: copie d’un fichier de configuration, export rapide, snapshot si ton hébergeur le permet. Quand on fait un dépannage WordPress, on protège aussi la base et les fichiers. Ici, même logique, mais en ciblant PrestaShop.
À ce stade, si les logs pointent vers un fichier précis (un module, un override, un thème), tu peux souvent revenir vite en remplaçant par la version précédente ou en désactivant le module responsable.
Diagnostiquer avec méthode: où chercher la cause (sans perdre une journée)
Le plus gros piège dans la page blanche, c’est de “changer des choses” sans vérifier. Tu veux un diagnostic court, pas une chasse au trésor.
1) Le PHP et les erreurs fatales
Sur beaucoup d’incidents, la cause est un code qui ne peut plus s’exécuter. Exemple typique: une incompatibilité après mise à jour. PrestaShop et PHP évoluent, et un module conçu pour une version plus ancienne peut planter lors du chargement.
Ce que je cherche dans les logs:
- un message “Fatal error” avec le fichier exact
- des classes manquantes (“Class not found”)
- des erreurs de syntaxe (souvent après une mise à jour ou un upload interrompu)
- des problèmes de mémoire
Si tu vois “Allowed memory size exhausted”, tu as souvent une double situation: mémoire trop basse et module trop lourd. Tu peux parfois relancer en augmentant temporairement la mémoire, mais si le module continue à générer la même surcharge, ça revient. Le but est de corriger la cause, pas seulement de survivre.
2) Les modules et le thème
Une page blanche au chargement initial arrive souvent quand un module s’exécute trop tôt, ou quand un override PHP déclenche un fatal error. Dans ce cas, tu peux relancer en désactivant temporairement le module responsable.
Si tu sais quel module a été modifié récemment, tu gagnes un temps énorme. Les “changements récents” sont rarement anodins: mise à jour PrestaShop ratée, ajout de plugin, modification du thème, insertion d’un script de tracking, ou changement d’extension serveur.
3) Le cache
Le cache de PrestaShop peut figer un état cassé. Si une mise à jour a généré un contenu incohérent, le cache peut continuer à servir “cassé” pendant un moment.
L’astuce ici, c’est d’agir sans faire n’importe quoi: vider le cache de manière ciblée et vérifier si le site redevient normal après purge.
4) Les permissions et l’accès aux fichiers
Un autre scénario fréquent: après une intervention (migration, changement de droits, déploiement via un outil), certains fichiers deviennent non accessibles. PrestaShop ne peut plus lire un fichier central et le résultat ressemble à une page blanche.
Dans ce cas, tu vois parfois des erreurs liées aux droits dans les logs, ou un comportement constant sur toutes les pages.
5) La piste “site piraté”
C’est délicat à aborder, mais nécessaire. Une page blanche peut aussi venir d’un fichier modifié par une intrusion, d’un script malveillant, ou d’un blocage. On retrouve la même logique côté WordPress: site WordPress piraté, réparation site WordPress piraté, et urgence WordPress quand le front devient inservable.
Je ne dis pas que c’est ton cas. Je dis juste qu’il faut vérifier si des fichiers clés ont été modifiés récemment et si tu as des traces (fichiers créés, scripts inattendus, connexions anormales). La réponse peut être simple (un override ou un fichier injecté) ou plus complexe, mais mieux vaut le savoir tôt.
Relancer concrètement: actions qui marchent souvent
La relance, c’est un mix entre “rétablir” et “isoler”. Selon que tu as ou non accès au back office, tu n’agis pas au même endroit.
Si le back office est accessible
Tu peux:
- désactiver temporairement les modules récemment installés
- purger le cache
- vérifier la compatibilité des modules avec ta version PrestaShop et ta version PHP
- vérifier les paramètres de performance ou de mode (production, debug)
Ce sont des actions “propres”. Et si ton incident vient d’un module ou d’un override, ça revient souvent en quelques minutes.
Si le back office est inaccessible
Là, tu dépends de l’accès FTP ou SSH. Tu cherches un chemin rapide:
- désactiver les modules par renommage ou via dossiers si ton hébergeur le permet
- restaurer un fichier depuis une sauvegarde
- recharger le bundle de base si un fichier central a été corrompu
Dans ces moments-là, la sauvegarde est ton filet de sécurité. Si tu n’en as pas, tu dois te contenter d’un “pansement” pour relancer, puis faire une réparation site PrestaShop plus profonde.
Une checklist simple pour sortir de la page blanche (sans te perdre)
Je te mets une liste courte, parce que dans l’urgence, tout le monde a besoin d’un cadre. Si tu coches mentalement ces points, tu évites les erreurs typiques.
- Vérifier si c’est “toute la boutique” ou “une partie” (front seulement, panier, catégories, back office)
- Consulter les logs PHP au moment exact du problème et repérer le fichier cité dans l’erreur
- Tester un vidage du cache PrestaShop (ou une purge depuis les réglages si accessible)
- Désactiver le dernier module ajouté ou mis à jour, surtout ceux qui touchent au front
- Comparer les fichiers modifiés récemment (thème, overrides, dossiers du module suspect)
C’est souvent suffisant pour trouver la cause dans l’après-midi, même quand on n’a pas tous les détails au départ.
Quand la cause est liée à une mise à jour ratée
La mise à jour ratée, c’est un grand classique. Ça peut concerner PrestaShop directement, mais aussi le thème, un module, ou la version de PHP côté hébergeur.
Quelques signaux:
- l’incident commence juste après une mise à jour PrestaShop ratée
- un module a été mis à jour en même temps
- des pages spécifiques échouent (produit, paiement, recherche), puis ça finit en blanc complet
- les logs montrent une classe introuvable ou une fonction dépréciée
La réparation ici n’est pas seulement de “rétablir”. Il faut empêcher la répétition. Concrètement:
- revenir à la version précédente du module ou du thème
- vérifier la compatibilité avec ta version PHP
- réappliquer la mise à jour proprement, de préférence en mode staging, puis en fenêtre de déploiement
Si tu as déjà vécu un “même scénario” sur WordPress, genre une mise à jour WordPress ratée qui déclenche une erreur critique WordPress ou une erreur 500 WordPress, tu vois le parallèle. La différence, c’est le mécanisme d’extension. Mais la discipline de test reste la même.
Le piège du “ça refonctionne” sans comprendre: comment éviter que ça revienne
Relancer est une chose. Empêcher le retour de la page blanche, c’est une autre histoire, plus longue. Et c’est là que beaucoup de boutiques perdent du temps, parce qu’elles traitent le symptôme au lieu de traiter la fragilité.
Mettre en place une routine de maintenance PrestaShop
Une maintenance WordPress existe aussi, et la logique s’applique. Ici, l’objectif est simple: réduire le nombre de changements “en production” sans filet.
Ce que je recommande, en mode pragmatique:
- gérer les mises à jour par paquets (un module à la fois, pas tout en même temps)
- faire une sauvegarde avant chaque changement significatif
- vérifier la compatibilité PHP, surtout si l’hébergeur change de version
- surveiller la santé serveur: CPU, mémoire, erreurs PHP
Je préfère un rythme stable à un sprint d’urgence permanent. Le site tombe rarement “par hasard”, il tombe souvent au moment où quelqu’un installe, désinstalle ou met à jour.
Séparer “staging” et “production”
Si tu n’as pas de staging, au minimum fais un test sur un environnement cloné quand c’est possible. La page blanche vient souvent d’un module mal adapté, ou d’un conflit. En staging, tu le vois avant que le client ne le voie.
Corriger ce qui rend la boutique fragile
Par exemple:
- modules trop lourds ou mal codés
- thème avec overrides inutiles ou obsolètes
- dépendances cassées (bibliothèques, extensions PHP)
- cache mal géré après déploiement
Le diagnostic doit aboutir à un “choix” technique: on garde, on retire, on remplace. Pas juste “on purge et on prie”.
Cas particulier: WooCommerce en panne et ce qu’on apprend pour PrestaShop
Même si ton problème est PrestaShop, je te parle vite de WooCommerce en panne parce que la posture de dépannage WordPress/WooCommerce aide beaucoup à structurer le diagnostic.
Sur WooCommerce, on voit souvent des pannes d’affichage ou des pages qui ne chargent plus quand:
- un plugin commerce dépend d’un framework
- le cache se contredit après une mise à jour
- la compatibilité PHP n’est plus au niveau
La leçon transposable à PrestaShop: tu dois toujours corréler l’erreur à un moment de changement. Et tu dois toujours identifier le composant fautif plutôt que de continuer à empiler des actions “au feeling”.
Comment savoir si tu dois passer en mode “réparation profonde”
Si tu as juste une page blanche ponctuelle, tu peux souvent corriger en purgeant cache et en désactivant un module.
Mais passe en mode réparation site PrestaShop plus complète si tu observes:
- la page blanche revient après une purge
- les logs montrent des erreurs répétées, sur des fichiers différents
- plusieurs modules sont touchés, pas uniquement un
- tu détectes des modifications de fichiers anormales
- des signaux de sécurité apparaissent (fichiers récents, redirections inconnues, comportements bizarres)
Dans ces cas, la logique devient: audit plus large, restauration d’éléments, durcissement, et parfois nettoyage complet. Sur WordPress on appelle ça réparation site WordPress piraté quand c’est nécessaire. L’esprit est le même, même si les outils et emplacements diffèrent.
Sécurité et durcissement: éviter que la page blanche cache un problème plus grave
Un site qui devient blanc peut être “juste” un bug. Mais si tu as un doute sur une compromission, tu ne veux pas redéployer dans l’état actuel.
Quelques actions responsables:
- comparer l’ensemble des fichiers “a date” avec la baseline de ton déploiement
- vérifier les tâches cron, les utilisateurs admin, et les entrées de scripts inhabituels
- surveiller les comptes FTP, SSH, et les clés
- renforcer les permissions et limiter l’écriture là où elle ne doit pas exister
Je ne te conseille pas de bricoler au hasard côté sécurité. Si tu as déjà eu un site WordPress piraté ou si tu gères plusieurs sites, tu sais que la première erreur, c’est de restaurer vite sans nettoyer. Ça marche parfois au début, puis ça rechute.
Dépannage site internet: gérer l’urgence côté métier (pas seulement côté technique)
Pendant qu’on “récupère la boutique”, tu dois aussi gérer l’impact commercial. Quand un site PrestaShop est en panne, les commandes se bloquent. Le support reçoit des tickets. Les clients paniquent.
J’ai vu des équipes se focaliser exclusivement sur le code, pendant que personne ne surveillait:
- le trafic réel (le site est-il “blanc” pour tout le monde ou seulement une région)
- le panier et la page paiement (parfois le front “semble” chargé, mais l’ordre échoue)
- les emails (confirmation commande, reset mot de passe)
- la disponibilité API éventuelle (paiement, livraison)
Une stratégie simple consiste à rétablir d’abord les pages vitales, même si d’autres zones restent temporairement dégradées. C’est la même philosophie que l’urgence WordPress: d’abord le service, ensuite la chirurgie.
Ce que je ferais après coup: un plan d’action sur 7 jours
Une fois le site revenu, ne te contente pas de “c’est bon”. Fais un cycle court, mais carré. Tu veux réduire le risque de récidive.
Sur 7 jours, je ferais en général:
- analyser précisément les logs et garder un résumé écrit (date, erreur, fichier, action qui a corrigé)
- verrouiller les mises à jour en séquence (et pas en rafale)
- vérifier la compatibilité PHP et relire la configuration d’hébergement (mémoire, limites, extensions)
- contrôler les modules “front” et leurs hooks
- refaire une sauvegarde de référence propre, puis mettre à jour la documentation interne
Le plus important est le “pourquoi”. Sans pourquoi, tu auras la même panne la prochaine fois. Et quand ça touche une boutique, tu finis par payer deux fois, une fois en temps, une fois en pertes.
Questions fréquentes (et réponses honnêtes)
“Pourquoi je n’ai aucune erreur à l’écran?”
Parce que la production masque parfois les erreurs PHP. Dans ce cas, les logs restent la meilleure source. Ne force pas l’affichage si ton hébergement n’est pas configuré pour. Mieux vaut diagnostiquer via les logs et ajuster prudemment.
“J’ai vidé le cache, ça marche, mais je ne suis pas sûr que ce soit fini.”
Si la cause est une erreur PHP, le site peut marcher “pour cette fois” mais replanter au prochain appel au même chemin. La preuve, c’est la répétition dans les logs. Si tu ne vois plus rien, c’est bon signe. Si les mêmes erreurs reviennent, il faut traiter le module ou le fichier fautif.
“Et si c’était une incompatibilité PHP?”
C’est fréquent après un changement côté hébergeur. https://datasweb.fr/ Ici, la réparation passe souvent par la mise à niveau de modules, le remplacement de dépendances, ou parfois un retour vers une version PHP compatible. Le bon choix dépend du niveau de risque et de ton calendrier de maintenance PrestaShop.
Si tu me décris ce que tu vois dans les logs (le message exact, le fichier indiqué, et ce qui a été modifié juste avant), je peux t’aider à affiner la piste la plus probable et à choisir la stratégie la plus sûre pour relancer vite, puis éviter que la page blanche revienne.