PrestaShop page blanche : diagnostiquer l’erreur fatale PHP rapidement

Table des matières :

1. Ce qu’on appelle vraiment une « PrestaShop page blanche » (WSOD)
2. Rendre l’erreur fatale visible sans exposer la prod
3. Localiser l’erreur fatale en moins de 10 minutes (pipeline de triage)
4. Causes récurrentes d’erreur fatale PHP sur PrestaShop 8/9 (et correctifs concrets)
5. Page blanche après mise à jour / déploiement : le scénario « normal » en production
6. Instrumenter pour ne plus déboguer une page blanche à l’aveugle (logs, métriques, SEO)

Ce qu’on appelle vraiment une « PrestaShop page blanche » (WSOD)

Une page blanche PrestaShop n’est pas un symptôme unique. Côté navigateur, vous voyez souvent un HTML vide ou un rendu interrompu, mais côté serveur cela peut correspondre à : un HTTP 500 (erreur d’exécution PHP), un HTTP 200 avec un body vide (sortie coupée avant echo), un timeout masqué par un reverse proxy/CDN, ou une réponse cachée par un cache (Smarty, full-page cache, CDN) qui sert une version vide.

Sur PrestaShop 8.x/9.x (PHP 8.1+), la cause la plus fréquente reste l’erreur fatale PHP (E_ERROR / uncaught Exception) qui stoppe l’exécution avant que le front ne rende quoi que ce soit. La seconde cause est une fatalité “silencieuse” : display_errors=Off + absence de logging exploitable = vous n’avez aucun signal côté navigateur. Le cœur PrestaShop n’aide pas toujours : en prod, beaucoup d’hébergements mutualisés neutralisent l’affichage, et PrestaShop ne “rattrape” pas proprement certains scénarios (autoload cassé, fichiers manquants, vendor incomplet).

Pour éviter de partir dans la mauvaise direction, gardez une lecture “réseau” du problème. Une WSOD peut ressembler à la même chose visuellement, mais ne se traite pas du tout pareil selon le statut HTTP et la taille de réponse :

Ce que vous observez	Indice technique	Piste prioritaire
Navigateur blanc + HTTP 500	Erreur serveur franche	Logs PHP-FPM / Monolog / modules
Navigateur blanc + HTTP 200 + body minuscule	Sortie interrompue / cache d’une réponse vide	Cache CDN/Smarty, buffering PHP, proxy
Chargement “infini”, puis blanc	Timeout côté proxy ou FPM	fastcgi_read_timeout, request_terminate_timeout, slow queries
Blanc uniquement sur BO /admin	Symfony/BO	var/logs/*, cache Symfony, vendor
Blanc uniquement sur front (produit/panier)	Smarty / modules / overrides	module hook, override, thème, cache

Dernier point à trancher immédiatement : front-office vs back-office. Une page blanche uniquement sur /admin oriente vers la couche Symfony (PrestaShop 8/9 back-office), alors qu’une page blanche sur une page produit/panier pointe souvent vers un module, un override, un template Smarty/Twig, ou une corruption de cache. Si vous voyez une page blanche “partout”, suspectez d’abord un problème global (PHP version, extensions, droits fichiers, vendor/composer, config, opcache).

Rendre l’erreur fatale visible sans exposer la prod

Le diagnostic rapide dépend d’un principe simple : la vérité est dans les logs, pas dans le navigateur. La recommandation officielle PHP est explicite : sur la directive display_errors : « This feature should never be used on production systems » (PHP manual, display_errors) : PHP manual — display_errors. Donc oui, activer l’affichage peut dépanner, mais uniquement de façon temporaire, idéalement sur une IP (via ACL Nginx/Apache) ou en staging.

Sur PrestaShop 8.1.x / 9.0+ (exemples réalistes en 2026 : PHP 8.2–8.3), vous avez trois leviers complémentaires :

1) Mode debug PrestaShop (si vous avez encore accès au BO) : Paramètres avancés → Performance (ou équivalent selon version) et bascule debug. Si le BO est KO, passez en dur via config/defines.inc.php :

// config/defines.inc.php
define('_PS_MODE_DEV_', true);

2) Logs Symfony/Monolog (notamment BO) : vérifiez var/logs/ (souvent prod.log / dev.log selon env) et les logs PHP-FPM/Apache. En pratique, cherchez en priorité :

• les “Uncaught Exception” et “Fatal error” (PHP),
• les erreurs de permissions (impossibilité d’écrire dans var/, log/, img/),
• les erreurs de class not found (autoload/composer),
• les erreurs DB (connexion, droits, migration incomplète).

3) Configuration PHP : forcer le logging (sans afficher) via php.ini / .user.ini (mutualisé) :

; logging recommandé
log_errors=On
error_reporting=E_ALL
display_errors=Off
; optionnel: chemin explicite
error_log=/var/log/php/error.log

Deux précautions utiles en production (souvent oubliées) :

• Vérifiez que le chemin error_log est réellement accessible par l’utilisateur PHP-FPM (sinon vous “activez le logging” vers un fichier… jamais écrit).
• Si vous êtes sur FPM, les directives .htaccess de type php_flag / php_value ne fonctionnent généralement pas : privilégiez la conf FPM (pool) ou .user.ini selon l’hébergement.

Sur OVHcloud mutualisé, l’écosystème est particulier (moteurs CGI/FCGI, version PHP par .ovhconfig). Si votre page blanche commence “après un switch de version”, commencez par vérifier le moteur et la version réellement servis, puis alignez CLI et web. Voir l’article interne : OVHcloud .ovhconfig : changer version PHP, moteur et mode d’exécution.

Enfin, si vous suspectez un problème “pré-requis” (extensions PHP, versions compatibles), recoupez avec la documentation officielle des exigences système PrestaShop (utile pour valider rapidement qu’il ne manque pas intl, zip, etc.) : PrestaShop system requirements (devdocs)

Localiser l’erreur fatale en moins de 10 minutes (pipeline de triage)

Objectif : obtenir un stack trace ou, à défaut, un point d’arrêt (fichier/ligne). Première étape : récupérer le statut HTTP et éliminer les faux positifs (cache, CDN). En SSH :

curl -I https://votre-domaine.tld/
curl -sS -D- https://votre-domaine.tld/ -o /dev/null

Ajoutez un contrôle très simple mais révélateur : la taille de la réponse. Une WSOD “200 OK” sort souvent avec quelques octets (ou carrément 0) :

curl -sS https://votre-domaine.tld/ -o /dev/null -w "HTTP=%{http_code} bytes=%{size_download}\n"

Si vous avez un CDN, testez en by-pass (header spécifique si vous en avez un) ou directement sur l’IP/origine. Une “page blanche” cachée derrière un HTTP 200 peut être un cache qui a stocké une réponse vide. Dans ce cas, purgez le cache CDN et PrestaShop (Smarty, CCC) après avoir identifié la cause (sinon vous masquez juste le symptôme). Pour les mécanismes de cache côté PrestaShop, vous pouvez recouper avec PrestaShop : optimiser performance via cache Smarty, CCC et CDN.

Deuxième étape : suivre les logs en temps réel pendant la reproduction. Sur Nginx + PHP-FPM (Debian/Ubuntu typiques) :

# logs Nginx
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

# logs PHP-FPM (chemin variable selon version)
sudo journalctl -u php8.2-fpm -f
# ou
sudo tail -f /var/log/php8.2-fpm.log

Astuce “triage” : faites deux requêtes successives (une front, une BO) et comparez ce qui s’écrit dans les logs au même moment. Si le front fait un 200 avec 0 octet mais qu’aucune ligne n’apparaît côté FPM, le problème peut être avant PHP (cache, CDN, WAF, rewrite, fichier statique servi). Si au contraire une erreur surgit dans FPM, vous êtes sur une fatale ou une exception.

Pour comprendre où se produit la rupture entre Nginx/Apache et PHP-FPM, relisez le flux d’exécution (headers, fastcgi params, timeouts) : PHP-FPM : comprendre le flux d’exécution avec Nginx et Apache. Une page blanche peut être un timeout (ex. fastcgi_read_timeout) qui coupe la réponse, pas une fatale PHP.

Troisième étape : réduire le périmètre applicatif. En pratique, sur PrestaShop, les crash “après une action” viennent très souvent d’un module/hook/override. La méthode brutale (mais efficace) :

• désactiver temporairement le cache var/cache/* (purge) :

rm -rf var/cache/prod/* var/cache/dev/*

• neutraliser un module suspect sans BO : renommer son dossier sous /modules/ (ex. modules/monmodule → modules/_monmodule.off) puis re-tester. Risque : si le module est critique (paiement), vous cassez le checkout, donc faites ça hors heures de vente.

• neutraliser les overrides en renommant /override le temps d’un test (même logique). Les overrides restent une zone à risques : collision de classes, signatures PHP 8 incompatibles, méthodes final/readonly, etc.

Mini-scenario (très courant en France sur mutualisé) : une boutique bascule de PHP 8.1 vers 8.3 via .ovhconfig. Tout marche en navigation simple, puis le panier devient blanc. En logs, vous trouvez une fatale dans un module de livraison qui surcharge une méthode avec une signature non compatible PHP 8. Résolution rapide : retour temporaire à PHP 8.1 pour rétablir la vente, désactivation du module incriminé, puis mise à jour du module (ou remplacement) avant de re-tenter PHP 8.3.

Causes récurrentes d’erreur fatale PHP sur PrestaShop 8/9 (et correctifs concrets)

Incompatibilités de version PHP / extensions manquantes

Le cas classique en 2026 : PrestaShop 8.x tourne, vous passez PHP 8.3, et un module “ancien” plante (typed properties, dépréciations transformées en exceptions, signatures incompatibles, etc.). À l’inverse, certains environnements restent en PHP 8.0/7.4 et installent une base PrestaShop qui requiert une version plus récente : vous obtenez une page blanche dès le bootstrap.

Actions rapides :

• Vérifier la version réellement servie par le web (pas seulement php -v en CLI). Sur Nginx, un phpinfo() temporaire (protégé) ou les en-têtes/variables de pool FPM.
• Vérifier les extensions (ex. intl, mbstring, gd/imagick, zip, curl) et surtout leur cohérence entre environnements.
• En mutualisé OVHcloud, la bascule passe souvent par .ovhconfig (voir lien plus haut). En dédié/VPS, alignez vos pools FPM (8.2 vs 8.3) et vérifiez les sockets.

Checklist express côté serveur (utile quand “ça marchait hier”) :

• php -m (CLI) et l’équivalent côté FPM (via phpinfo() temporaire) donnent-ils la même liste d’extensions ?
• intl est-il chargé ? Son absence provoque des erreurs en cascade (notamment sur des fonctionnalités de formatage).
• Avez-vous des modules qui appellent Imagick alors que seule gd est installée (ou inversement) ?
• Après upgrade PHP, l’OPcache a-t-il gardé des scripts compilés incompatibles (rare mais réel sur certains déploiements) ? Un redémarrage FPM peut clarifier.

Pour cadrer les attentes côté compétences et stack moderne (Symfony/PHP 8), l’article interne Développeur PrestaShop senior : compétences PHP 8 et Symfony attendues pose bien les prérequis techniques.

Vendor/composer incomplet, autoload cassé, cache Symfony incohérent

Si votre page blanche arrive après un déploiement Git/FTP (ou une extraction zip), suspectez un vendor/ incomplet ou des fichiers manquants. Sur PrestaShop 8/9, une partie du BO et de la stack dépend fortement de Composer. Une classe introuvable (Class "..." not found) se traduit souvent par une fatale.

Actions :

• Si vous déployez depuis une CI/CD (recommandé), le bon pattern est souvent : build (composer install) dans un artefact, puis déploiement de l’artefact (sans lancer composer en prod). Cela réduit les surprises (droits, mémoire, manque de binaires).
• Purger puis réchauffer le cache (au minimum purge, le warmup dépend de votre stack) :

rm -rf var/cache/prod/*

• Vérifier droits fichiers (var/, img/, log/) et propriétaire (www-data vs user). Une exception lors d’un write de cache/log peut provoquer un écran blanc si elle n’est pas correctement loggée.

Point d’attention typique : un BO blanc juste après déploiement, avec front OK, arrive quand vendor/ n’est pas aligné avec le code Symfony du back-office. Dans ce cas, cherchez aussi des indices dans var/logs/prod.log (ou dev.log si vous avez basculé en dev).

Surconsommation mémoire / recursion / erreurs “fatales” non triviales

La “page blanche” peut être un OOM PHP (Allowed memory size of ... exhausted) ou un crash à la compilation d’un template. Typiquement : un module ajoute une requête monstrueuse en hook sur une page catégorie, puis la page devient blanche au-delà d’un certain volume de produits.

Correctifs :

• Monter temporairement memory_limit pour confirmer l’hypothèse (diagnostic, pas solution). Si la page revient immédiatement avec plus de mémoire, vous avez une piste claire (template trop lourd, requête trop large, hook surchargé).
• Activer le slowlog PHP-FPM et profiler (Xdebug en staging) pour isoler la fonction problématique. Pour la mise en place côté dev, voir Xdebug : installer et activer Xdebug 3 pour PHP CLI et web et Xdebug : configurer le débogage PHP dans Visual Studio Code.
• Côté code, cherchez les boucles sur Hook::exec(), les appels récursifs, ou les requêtes N+1 en front (cf. Optimisation de code PrestaShop : diagnostiquer lenteurs et requêtes SQL et PrestaShop MySQL : analyser slow query log et optimiser index).

Deux commandes utiles côté serveur quand vous suspectez un OOM “dur” (et pas seulement une exception PHP) :

• dmesg -T | tail -n 50 pour repérer un éventuel OOM killer Linux (si le kernel tue le process PHP-FPM, vous pouvez voir des “Killed process”).
• les logs du service PHP-FPM (via journalctl) : si le worker redémarre en boucle ou atteint des limites (pm.max_children), vous aurez des indices.

Overrides et collisions de signatures (spécial PHP 8)

Les overrides restent l’une des sources les plus toxiques de pages blanches : méthodes surchargées qui ne respectent plus les signatures (types, valeurs par défaut), classes renommées, ou comportement divergent après upgrade. En PHP 8, une signature incompatible est un fatal (pas un warning), donc l’écran blanc est immédiat.

La stratégie pragmatique :

• isoler en renommant /override puis purge cache;
• comparer l’override avec la classe core correspondante dans la version cible;
• migrer autant que possible vers des hooks (quand c’est faisable) ou vers des services Symfony côté BO.

Bon réflexe : même après avoir renommé /override, purgez le cache car PrestaShop peut conserver un index de classes/overrides en cache. Si la page reste blanche, vous savez que l’override n’est probablement pas la cause principale (ou qu’il y a un second problème).

Si vos modules s’appuient sur des hooks dynamiques ou une logique regex, gardez en tête que la moindre régression de signature va remonter brutalement en prod. Référence utile : Hooks PrestaShop : comprendre les hooks dynamiques et les regex.

Page blanche après mise à jour / déploiement : le scénario « normal » en production

Une page blanche juste après une montée de version PrestaShop (ou une mise à jour de module) n’a rien de “mystique”. Dans la majorité des cas, c’est un process de release non atomique : fichiers mis à jour mais cache non cohérent, base modifiée mais code pas aligné, ou dépendances vendor non installées. Le cœur PrestaShop n’est pas transactionnel sur ce point : si vous faites un upgrade “à la main” sur un site qui vend, vous prenez un risque réel.

Dans un contexte e-commerce, le bon ordre de priorités est souvent : 1) Rétablir la capacité à vendre (rollback, retour version PHP, désactivation du module fautif), 2) Capturer la cause (logs + reproduction en staging), 3) Corriger proprement (update module/thème, refactor override, ajustement infra).

Si vous venez d’une mise à jour ratée, attaquez le diagnostic avec un plan de récupération structuré plutôt que du bricolage en FTP. L’article interne Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement couvre le workflow typique (sauvegardes, rollback, réparation). Et si vous préparez une montée de version, la checklist est ici : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests.

Deux anti-patterns à éviter parce qu’ils produisent exactement des pages blanches :

• Déployer sans staging : vous ne voyez les fatales qu’en prod, avec un cache froid, un opcache non préchauffé et des vraies données. Montez un staging fidèle (mêmes versions PHP/MariaDB, même config FPM) : Staging PrestaShop : créer un environnement Docker fidèle à la production.
• Changer plusieurs variables à la fois (version PHP + version PrestaShop + modules + thème). Séparez les changements pour que la causalité soit observable. Sinon, votre “page blanche” est un puzzle.

Pratique simple qui évite beaucoup de WSOD post-déploiement : après mise à jour, purgez explicitement (et au bon moment) :

• var/cache/ (Symfony/PrestaShop),
• cache Smarty/CCC si activé,
• cache OPcache (au minimum un reload/restart FPM si vous contrôlez le serveur),
• cache CDN si vous en avez un (mais uniquement après avoir stabilisé l’origine).

Instrumenter pour ne plus déboguer une page blanche à l’aveugle (logs, métriques, SEO)

La manière la plus fiable d’éviter la page blanche “sans traces” est de traiter votre boutique comme un service : logs structurés, corrélation, alerting. La référence la plus claire côté bonnes pratiques est The Twelve-Factor App : « A log is the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. » (12factor, Logs) : The Twelve-Factor App — Logs. Appliqué à PrestaShop : centralisez Nginx/Apache + PHP-FPM + logs applicatifs (Monolog) avec un request_id commun.

Concrètement, vous pouvez pousser les logs vers OpenSearch/Elasticsearch (self-hosted ou managé) pour requêter instantanément les fatales et regrouper par URL/module. Si vous êtes sur OVHcloud, l’article interne OVHcloud Managed OpenSearch : moteur NoSQL managé pour logs et recherche est une base solide. À minima, mettez en place : rotation (logrotate), conservation, et une alerte sur le taux de 5xx.

Côté métriques, une page blanche n’est pas qu’un bug : c’est souvent un signal de saturation (CPU, RAM, FPM max_children, IO). Une surveillance simple (load, mémoire, latence PHP-FPM, erreurs Nginx) permet de distinguer un crash applicatif d’un effondrement infra. Pour démarrer vite : Netdata : activer et configurer les collectors pour monitoring temps réel ou une stack Prometheus si vous avez déjà la culture SRE : Prometheus : configuration des alertes, métriques et requêtes PromQL.

Enfin, ne sous-estimez pas l’impact SEO/UX. Une page blanche peut être indexée comme un contenu vide si vous renvoyez 200 OK avec un body nul (ou un HTML tronqué). D’un point de vue technique SEO, c’est un cas de “page vide” à traiter comme un incident de rendu et de statut HTTP, pas comme un problème de contenu. Pour le diagnostic côté crawl, statuts, et effets d’indexation, recoupez avec Page web vide : diagnostic SEO technique et actions correctives.

La mitigation pragmatique est simple : renvoyer des 5xx en cas de crash (pas des 200), désactiver le cache qui sert du vide, et mettre un fallback (page d’erreur propre) uniquement si vous avez la certitude de ne pas masquer un incident. Dans une logique “GEO/SEO technique”, c’est aussi le moyen le plus propre d’éviter les signaux ambigus côté moteurs quand une URL “répond” mais ne rend rien.

• Sur un serveur où Composer est disponible :

composer install --no-dev --prefer-dist --optimize-autoloader

• Si vous déployez depuis une CI/CD (recommandé), le bon pattern est souvent : build (composer install) dans un artefact, puis déploiement de l’artefact (sans lancer composer en prod). Cela réduit les surprises (droits, mémoire, manque de binaires).
• Purger puis réchauffer le cache (au minimum purge, le warmup dépend de votre stack) :

rm -rf var/cache/prod/*

• Vérifier droits fichiers (var/, img/, log/) et propriétaire (www-data vs user). Une exception lors d’un write de cache/log peut provoquer un écran blanc si elle n’est pas correctement loggée.

Point d’attention typique : un BO blanc juste après déploiement, avec front OK, arrive quand vendor/ n’est pas aligné avec le code Symfony du back-office. Dans ce cas, cherchez aussi des indices dans var/logs/prod.log (ou dev.log si vous avez basculé en dev).

Surconsommation mémoire / recursion / erreurs “fatales” non triviales

La “page blanche” peut être un OOM PHP (Allowed memory size of ... exhausted) ou un crash à la compilation d’un template. Typiquement : un module ajoute une requête monstrueuse en hook sur une page catégorie, puis la page devient blanche au-delà d’un certain volume de produits.

Correctifs :

• Monter temporairement memory_limit pour confirmer l’hypothèse (diagnostic, pas solution). Si la page revient immédiatement avec plus de mémoire, vous avez une piste claire (template trop lourd, requête trop large, hook surchargé).
• Activer le slowlog PHP-FPM et profiler (Xdebug en staging) pour isoler la fonction problématique. Pour la mise en place côté dev, voir Xdebug : installer et activer Xdebug 3 pour PHP CLI et web et Xdebug : configurer le débogage PHP dans Visual Studio Code.
• Côté code, cherchez les boucles sur Hook::exec(), les appels récursifs, ou les requêtes N+1 en front (cf. Optimisation de code PrestaShop : diagnostiquer lenteurs et requêtes SQL et PrestaShop MySQL : analyser slow query log et optimiser index).

Deux commandes utiles côté serveur quand vous suspectez un OOM “dur” (et pas seulement une exception PHP) :

• dmesg -T | tail -n 50 pour repérer un éventuel OOM killer Linux (si le kernel tue le process PHP-FPM, vous pouvez voir des “Killed process”).
• les logs du service PHP-FPM (via journalctl) : si le worker redémarre en boucle ou atteint des limites (pm.max_children), vous aurez des indices.

Overrides et collisions de signatures (spécial PHP 8)

Les overrides restent l’une des sources les plus toxiques de pages blanches : méthodes surchargées qui ne respectent plus les signatures (types, valeurs par défaut), classes renommées, ou comportement divergent après upgrade. En PHP 8, une signature incompatible est un fatal (pas un warning), donc l’écran blanc est immédiat.

La stratégie pragmatique :

• isoler en renommant /override puis purge cache;
• comparer l’override avec la classe core correspondante dans la version cible;
• migrer autant que possible vers des hooks (quand c’est faisable) ou vers des services Symfony côté BO.

Bon réflexe : même après avoir renommé /override, purgez le cache car PrestaShop peut conserver un index de classes/overrides en cache. Si la page reste blanche, vous savez que l’override n’est probablement pas la cause principale (ou qu’il y a un second problème).

Si vos modules s’appuient sur des hooks dynamiques ou une logique regex, gardez en tête que la moindre régression de signature va remonter brutalement en prod. Référence utile : Hooks PrestaShop : comprendre les hooks dynamiques et les regex.

Page blanche après mise à jour / déploiement : le scénario « normal » en production

Une page blanche juste après une montée de version PrestaShop (ou une mise à jour de module) n’a rien de “mystique”. Dans la majorité des cas, c’est un process de release non atomique : fichiers mis à jour mais cache non cohérent, base modifiée mais code pas aligné, ou dépendances vendor non installées. Le cœur PrestaShop n’est pas transactionnel sur ce point : si vous faites un upgrade “à la main” sur un site qui vend, vous prenez un risque réel.

Dans un contexte e-commerce, le bon ordre de priorités est souvent : 1) Rétablir la capacité à vendre (rollback, retour version PHP, désactivation du module fautif), 2) Capturer la cause (logs + reproduction en staging), 3) Corriger proprement (update module/thème, refactor override, ajustement infra).

Si vous venez d’une mise à jour ratée, attaquez le diagnostic avec un plan de récupération structuré plutôt que du bricolage en FTP. L’article interne Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement couvre le workflow typique (sauvegardes, rollback, réparation). Et si vous préparez une montée de version, la checklist est ici : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests.

Deux anti-patterns à éviter parce qu’ils produisent exactement des pages blanches :

• Déployer sans staging : vous ne voyez les fatales qu’en prod, avec un cache froid, un opcache non préchauffé et des vraies données. Montez un staging fidèle (mêmes versions PHP/MariaDB, même config FPM) : Staging PrestaShop : créer un environnement Docker fidèle à la production.
• Changer plusieurs variables à la fois (version PHP + version PrestaShop + modules + thème). Séparez les changements pour que la causalité soit observable. Sinon, votre “page blanche” est un puzzle.

Pratique simple qui évite beaucoup de WSOD post-déploiement : après mise à jour, purgez explicitement (et au bon moment) :

• var/cache/ (Symfony/PrestaShop),
• cache Smarty/CCC si activé,
• cache OPcache (au minimum un reload/restart FPM si vous contrôlez le serveur),
• cache CDN si vous en avez un (mais uniquement après avoir stabilisé l’origine).

Instrumenter pour ne plus déboguer une page blanche à l’aveugle (logs, métriques, SEO)

La manière la plus fiable d’éviter la page blanche “sans traces” est de traiter votre boutique comme un service : logs structurés, corrélation, alerting. La référence la plus claire côté bonnes pratiques est The Twelve-Factor App : « A log is the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. » (12factor, Logs) : The Twelve-Factor App — Logs. Appliqué à PrestaShop : centralisez Nginx/Apache + PHP-FPM + logs applicatifs (Monolog) avec un request_id commun.

Concrètement, vous pouvez pousser les logs vers OpenSearch/Elasticsearch (self-hosted ou managé) pour requêter instantanément les fatales et regrouper par URL/module. Si vous êtes sur OVHcloud, l’article interne OVHcloud Managed OpenSearch : moteur NoSQL managé pour logs et recherche est une base solide. À minima, mettez en place : rotation (logrotate), conservation, et une alerte sur le taux de 5xx.

Côté métriques, une page blanche n’est pas qu’un bug : c’est souvent un signal de saturation (CPU, RAM, FPM max_children, IO). Une surveillance simple (load, mémoire, latence PHP-FPM, erreurs Nginx) permet de distinguer un crash applicatif d’un effondrement infra. Pour démarrer vite : Netdata : activer et configurer les collectors pour monitoring temps réel ou une stack Prometheus si vous avez déjà la culture SRE : Prometheus : configuration des alertes, métriques et requêtes PromQL.

Enfin, ne sous-estimez pas l’impact SEO/UX. Une page blanche peut être indexée comme un contenu vide si vous renvoyez 200 OK avec un body nul (ou un HTML tronqué). D’un point de vue technique SEO, c’est un cas de “page vide” à traiter comme un incident de rendu et de statut HTTP, pas comme un problème de contenu. Pour le diagnostic côté crawl, statuts, et effets d’indexation, recoupez avec Page web vide : diagnostic SEO technique et actions correctives.

La mitigation pragmatique est simple : renvoyer des 5xx en cas de crash (pas des 200), désactiver le cache qui sert du vide, et mettre un fallback (page d’erreur propre) uniquement si vous avez la certitude de ne pas masquer un incident. Dans une logique “GEO/SEO technique”, c’est aussi le moyen le plus propre d’éviter les signaux ambigus côté moteurs quand une URL “répond” mais ne rend rien.