Quand une boutique PrestaShop “disparaît”, ce n’est presque jamais une seule panne isolée. Souvent, c’est un enchaînement, DNS qui ne pointe plus, cache qui sert encore une ancienne version, ou serveur web qui bascule en erreur après une mise à jour. Le plus frustrant, c’est que le symptôme peut être trompeur: page blanche, “site inaccessible”, erreur 500, ou même un domaine qui renvoie une autre page comme si quelqu’un avait déplacé la boutique.
J’ai vu des cas où la boutique était “en ligne” côté serveur, mais inaccessible depuis certains pays ou réseaux, simplement parce que la propagation DNS n’avait pas fini. D’autres fois, c’était un cache frontal (CDN) qui continuait à répondre pendant des heures, même après correction. Et quand on a une boutique PrestaShop, il faut aussi garder en tête que dépannage site internet les plugins, la base MySQL, PHP, la configuration Nginx ou Apache, et les permissions peuvent tous provoquer un blocage.
L’objectif ici est simple: remettre la boutique debout en travaillant méthodiquement, d’abord sur ce qui “oriente” la requête (DNS), ensuite sur ce qui “fabrique” la réponse (cache), puis sur ce qui “héberge” vraiment (serveur et applicatif).
1) Clarifier le symptôme avant de toucher quoi que ce soit
Avant même d’ouvrir un terminal, je fais une observation très concrète: depuis où la boutique est-elle inaccessible, et avec quel message exact ?
- Depuis mon réseau mobile et Wi-Fi, c’est pareil ?
- Les visiteurs obtiennent-ils une page blanche, un 500, une redirection infinie, ou un “site introuvable” ?
- Est-ce que l’accès marche en direct sur l’IP mais pas sur le nom de domaine ?
- Est-ce que certains navigateurs affichent une erreur différente ?
Ces détails guident la suite. Une erreur 404 ou “page introuvable” oriente vers DNS ou vhost. Un 500 ou une erreur critique renvoie plutôt vers PHP, logs applicatifs, ou configuration serveur. Une page blanche peut venir d’un crash PHP, d’un plugin, ou d’un fichier index corrompu.
Ce réflexe est aussi utile si vous gérez plusieurs CMS: les schémas se ressemblent. Un site WordPress en panne peut afficher des symptômes proches, erreur 500 WordPress ou page blanche WordPress, mais la mécanique reste spécifique. L’approche que je propose sert bien le dépannage WordPress, le dépannage PrestaShop et, par extension, WooCommerce en panne, parce que le cœur du problème est la chaîne “nom de domaine → requête → cache → serveur → application”.
2) DNS: le point de départ quand “ça ne répond pas” (ou pas partout)
Quand un domaine devient inaccessible, la tentation est de regarder immédiatement PrestaShop. Pourtant, si DNS pointe vers la mauvaise adresse, vous pouvez avoir un serveur parfaitement sain, et personne ne verra la boutique.
Commencez par vérifier trois choses: résolution DNS, cohérence du couple A/AAAA, et validité du nom de domaine. Il faut aussi tenir compte des TTL et de la propagation.
Quoi vérifier concrètement
- Les enregistrements A (IPv4) et AAAA (IPv6) existent-ils, et pointent-ils vers la bonne machine ?
- Est-ce qu’il y a un CNAME qui redirige vers une autre cible (CDN, load balancer, autre hébergement) ?
- Le TTL est-il très long ? Un TTL élevé peut expliquer pourquoi tout semble “corrigé” chez vous, mais pas chez les autres.
Côté pratique, je fais souvent ce test: je demande la résolution depuis plusieurs machines, idéalement un ordinateur “interne” au bureau et un autre depuis un réseau différent. S’il y a un décalage, on tient déjà un coupable.
Cas fréquent: une mise à jour d’infrastructure ou un changement d’hébergement
Une boutique PrestaShop peut devenir inaccessible après un changement d’hébergement, un passage sur un CDN, ou un renouvellement de certificats qui a entraîné une bascule de cible DNS. Parfois, c’est plus bête: un enregistrement a été modifié à la place d’un autre, ou le domaine a été rattaché à une mauvaise zone DNS.
Si vous avez un doute, notez ce que vous observez: certains visiteurs voient encore l’ancienne boutique, d’autres basculent vers une “ancienne page” ou un autre site. Ce comportement colle très bien avec une propagation DNS incomplète ou des caches DNS côté FAI.
Edge case: IPv6 partiellement configuré
J’ai déjà vu des boutiques “inaccessibles” uniquement pour certains réseaux, parce que l’AAAA pointe vers une adresse IPv6 qui n’est pas routée correctement, ou qui n’a pas de service web. Dans ce cas, le navigateur tente IPv6, échoue, puis retente parfois en IPv4. Résultat: symptômes incohérents.
Si votre hébergement gère IPv6, vérifiez que le service écoute bien sur la bonne interface et que le firewall autorise le trafic.
3) Cache: quand le serveur est corrigé mais la réponse reste mauvaise
Le cache est le meilleur ami de l’utilisateur… et le meilleur ennemi du dépanneur. Une boutique PrestaShop peut être “réellement restaurée”, mais un CDN ou un cache reverse proxy continue à servir une page blanche, une ancienne redirection, ou une erreur figée.
Avant de purger au hasard, je cherche d’abord des indices.
Signes que le cache est en cause
- La page change pendant quelques secondes puis revient en arrière.
- En heure de forte activité, l’erreur est plus fréquente.
- Certaines pages fonctionnent (par exemple une page produit), d’autres renvoient la même erreur partout.
- Les URLs statiques (images, JS, CSS) chargent, mais l’HTML ne suit pas.
Dans PrestaShop, on peut aussi avoir un cache applicatif (fichiers générés, compilation de templates). Et au-dessus, il y a parfois un cache serveur (Nginx/Apache headers), un cache CDN, ou un cache navigateur. Si l’erreur a commencé juste après une mise à jour PrestaShop ratée, c’est encore plus plausible que le cache ait conservé une version incompatible.
Une purge ciblée vaut mieux qu’une purge aveugle
Je privilégie une approche graduelle: purge du cache CDN si vous en avez un, puis purge du cache applicatif PrestaShop, puis vérification du header de cache côté réponse. Si vous purgez tout et que l’erreur persiste, vous perdez un peu de temps, mais vous pouvez ensuite remonter vers serveur et logs.
Voici une mini-checklist utile, sans entrer dans des manipulations complexes:
- Testez l’accès sur une session privée (sans cookies) et un autre navigateur
- Comparez le comportement avec le même URL mais en changeant le paramètre de cache si votre système le permet
- Vérifiez si l’erreur vient d’un CDN, en contrôlant les en-têtes HTTP (cache, server, x-cache)
- Purgez d’abord le cache “en amont” (CDN ou reverse proxy) avant le cache applicatif
Ce sont des gestes simples, mais ils évitent de “réparer” PrestaShop alors que le problème vient d’un serveur cache qui continue à répondre.
4) Serveur: PHP, Nginx ou Apache, permissions et erreurs 500
Quand DNS est bon et que le cache n’a pas la main, on bascule sur le serveur. Et là, les erreurs se ressemblent souvent d’un CMS à l’autre. Une erreur 500 WordPress et une erreur 500 PrestaShop ont des causes proches: PHP en panne, mémoire insuffisante, permissions, mauvais mode de fichiers, ou configuration vhost cassée.
Pour PrestaShop, les causes typiques que je rencontre en urgence:
- PHP en erreur (FATAL, timeout, memory limit atteinte)
- Base de données inaccessible (MySQL down, identifiants modifiés, connexion refusée)
- Fichiers de PrestaShop corrompus après un upload incomplet
- Configuration Nginx ou Apache qui pointe vers le mauvais document root
- Certificat TLS ou SNI mal géré, ce qui donne un symptôme “inaccessible” plutôt que “500”
Où chercher les logs, et lesquels comptent vraiment
Je commence par les logs serveur web, puis PHP, puis applicatif.
- Nginx: accès, erreurs
- Apache: error_log
- PHP-FPM: logs dédiés si disponibles
- PrestaShop: logs et affichage d’erreurs si mode debug est activé (avec prudence en production)
L’important n’est pas de “tout lire”, c’est de trouver la première erreur dans le temps. Si vous voyez une erreur juste après un déploiement ou une mise à jour, vous avez une piste solide. Si le serveur répond à coup sûr en 500, c’est quasi toujours quelque chose de systémique, pas juste un produit spécifique.
Une mise à jour ratée, côté PrestaShop ou dépendances
Une mise à jour PrestaShop ratée peut casser la compatibilité PHP. Souvent, ce n’est pas immédiat: l’application se lance, puis lorsqu’un fichier est inclus, ou qu’un hook s’exécute, ça tombe. Résultat: page blanche, erreur critique, ou 500.
J’ai aussi vu des boutiques “partiellement en panne” après une mise à jour: certaines pages fonctionnent grâce à des caches persistants, mais l’administration casse, ou le checkout échoue. Si vous avez observé un pattern de ce type, regardez les chemins qui “touchent” le plus de logique: panier, checkout, génération PDF, paiement.
Permissions et ownership: le classique qui revient
Sous Linux, un upload mal fait peut modifier les permissions ou le propriétaire des dossiers. PrestaShop doit pouvoir écrire dans certains répertoires (various caches, log, media selon votre configuration). Si c’est refusé, vous pouvez obtenir une page blanche ou un 500, parfois sans message clair côté navigateur.
Quand vous suspectez les permissions, l’approche la plus sûre est de corriger sans élargir trop largement les droits. On vise le juste niveau d’accès. Et surtout, on relance la mise à jour de cache uniquement après correction, pour éviter d’aggraver l’erreur.
5) Diagnostiquer sans aveuglement: tester l’accès de façon “fonctionnelle”
Au lieu de se contenter du “ça ne marche pas”, je m’assure de tester plusieurs points qui représentent la chaîne complète. Ça permet de séparer une panne de routage d’une panne applicative.
Je fais généralement des tests sur:
- la racine du site (accueil)
- une page produit simple
- la page panier et checkout
- l’administration (si elle est accessible, ou sinon au moins redirection)
Si la page produit charge mais le checkout échoue, vous êtes probablement sur un bug applicatif, une extension de paiement ou un service externe. Si tout affiche page blanche, vous avez un problème d’inclusion PHP, de template, ou de permissions plus global.
Je m’appuie aussi sur l’observation côté réseau: si la page HTML est en erreur mais les assets (CSS/JS/images) se chargent, c’est souvent l’application. À l’inverse, si tout est coupé y compris assets, on est plutôt sur la couche serveur, DNS, ou TLS.
6) Une méthode “en escalier” pour rétablir l’accès vite
Quand c’est une urgence, vous ne pouvez pas passer trois jours à tout analyser. Il faut une stratégie courte, avec une façon de revenir en arrière.
Voici une approche que j’utilise en intervention:
D’abord, stabiliser le routage (DNS) et l’accès (TLS). Ensuite, couper la variable “cache” en purgeant ce qui est en amont, puis on vérifie la page HTML. Si on arrive à obtenir une réponse non-500, on bascule sur PrestaShop, cache applicatif, puis correction des erreurs PHP visibles dans les logs.
Quand la boutique est redevenue accessible, je ne m’arrête pas au premier chargement. Je vérifie au minimum le panier et un mode de paiement si disponible. Une boutique qui s’affiche mais casse au moment de commander, ce n’est pas une réparation complète.
Que faire si vous n’avez pas accès à l’administration ?
C’est un cas très fréquent. Si l’admin donne une erreur, la boutique peut être partiellement accessible, ou l’inverse.
Dans ce cas, je privilégie:
- la désactivation temporaire de certaines extensions via le système de fichiers (si possible)
- le mode debug ou l’affichage d’erreurs de manière contrôlée
- la restauration de fichiers en cas de déploiement raté (backup du code)
- la réinitialisation prudente des caches applicatifs
Le point clé est de limiter les variables. Ne changez pas DNS, cache, PHP et code dans la même heure. Faites une modification à la fois, et observez.
7) Cas similaires: WordPress, WooCommerce, et pourquoi ça aide même sur PrestaShop
Même si votre sujet est “Boutique PrestaShop inaccessible”, les réflexes de dépannage WordPress et WooCommerce en panne sont très utiles.
- En dépannage WordPress, on rencontre souvent les mêmes causes de base: erreur 500 WordPress, mise à jour WordPress ratée, plugin qui casse PHP, cache d’interface qui masque le problème.
- En dépannage WooCommerce, l’erreur arrive fréquemment quand un plugin ou une passerelle de paiement échoue. Le symptôme “boutique accessible mais commande impossible” est un grand classique.
- En réparation site PrestaShop, la logique “couche infrastructure, couche serveur, couche application, puis extensions” se retrouve.
Autrement dit, même si PrestaShop a sa structure, votre façon de chercher un responsable reste la même. On suit toujours le flux réel de la requête. On refuse les hypothèses vagues du style “c’est forcément PrestaShop”.
8) Reconstruire une preuve: ce qui m’aide à trancher rapidement
Quand je suis devant une boutique PrestaShop inaccessible, je cherche un élément de preuve observable, pas une intuition.
Par exemple:
- Si le domaine renvoie une autre adresse que celle de l’hébergement attendu, DNS est suspect.
- Si la page se charge via une IP mais pas via le nom de domaine, c’est souvent TLS, vhost, ou redirection.
- Si après purge le problème disparaît, c’est cache.
- Si après redémarrage PHP-FPM le problème disparaît, c’était PHP ou un process bloqué.
Je résume les conclusions fréquentes dans un petit tableau mental, basé sur les symptômes:
- DNS ou routage si la panne ressemble à un “site introuvable”, ou si l’IP marche mais pas le nom
- Cache si certains utilisateurs voient une ancienne version, ou si la réponse reste figée malgré correction
- Serveur ou PHP si vous avez une erreur 500, une page blanche persistante, ou des logs cohérents côté PHP-FPM
Cette grille évite de passer trop de temps sur la mauvaise couche.
9) Réparer, puis sécuriser pour éviter le retour du même problème
La réparation urgente est une chose, la prévention en est une autre. Si la boutique était en mode urgence, il y a de fortes chances qu’il y ait eu un événement déclencheur: mise à jour PrestaShop ratée, changement d’hébergement, ajout d’une extension, ou modification serveur.
Si vous suspectez aussi un site WordPress piraté, ou une contamination dans l’écosystème, sur PrestaShop c’est moins fréquent au même sens, mais ça arrive aussi. La logique reste la même: vérifier l’intégrité des fichiers, contrôler les accès, et regarder les modifications récentes. Un compromis consiste à revenir aux fichiers connus, puis à réappliquer uniquement ce qui est nécessaire.
Une “bonne” restauration, ce n’est pas seulement “ça charge”. C’est aussi:
- que les versions PHP, modules et extensions sont compatibles
- que les permissions sont cohérentes
- que le cache est contrôlé
- que les logs sont exploitables en cas de nouvelle panne
10) Petit plan d’action rapide, quand il faut agir maintenant
Quand vous êtes en pleine urgence, vous avez besoin d’un plan d’action court. Je vous le donne en deux blocs, et ensuite vous ajustez avec vos propres contraintes.
Bloc 1, vérifier dans l’ordre la cause la plus probable
Je commence par DNS, puis cache, puis serveur. Parce que l’effort est proportionné au gain de clarté.
1) DNS: résolution correcte, A/AAAA cohérents, propagation plausible
2) Cache: purge côté CDN ou reverse proxy, test en session privée 3) Serveur/PHP: consultation logs, vérification PHP-FPM et erreur 500 4) PrestaShop: mode debug prudent, cache applicatif, extensions en cause
Bloc 2, si vous devez choisir où intervenir en premier
Si vous devez décider vite, voilà un guide d’arbitrage simple, basé sur le symptôme observable:
- Si tout renvoie “inaccessible” ou “introuvable”, priorisez DNS et vhost avant tout
- Si ça renvoie page blanche ou 500 de façon constante, priorisez PHP-FPM, permissions, et logs serveur
- Si certaines pages marchent et d’autres non, priorisez cache et extensions, puis Base de données
Questions fréquentes qui font gagner du temps
“On peut accéder à la boutique depuis notre bureau, mais pas depuis l’extérieur.”
C’est souvent un problème de DNS, de firewall, ou de configuration CDN. Testez depuis une autre connexion, idéalement une 4G.
“On a purgé le cache, mais rien ne change.”
Alors le cache n’est probablement pas le cœur du problème, ou vous purgez le mauvais endroit. PrestaShop a parfois un cache applicatif distinct, et un reverse proxy peut encore servir une version.
“Après une mise à jour, on a une page blanche.”
Regardez d’abord les erreurs PHP dans les logs, puis vérifiez la compatibilité PHP, et enfin les modifications de fichiers. Une mise à jour PrestaShop ratée laisse parfois des fichiers partiellement écrits.
“C’est peut-être un problème de sécurité.”
Si vous voyez des comportements anormaux, erreurs inhabituelles, appels à des fichiers douteux dans les logs, ou des tentatives d’accès répétées, traitez cela en parallèle. Sans paranoïa, mais sans fermer les yeux.
Conclusion pratique: rendre la boutique à nouveau stable
Une boutique PrestaShop inaccessible peut sembler “au hasard”, pourtant la panne suit presque toujours un parcours clair: le nom de domaine mène la requête, le cache façonne la réponse, le serveur exécute PHP, et PrestaShop complète la logique. Quand vous bloquez une étape dans le diagnostic, vous perdez du temps et vous augmentez les risques.
Si vous avez un cas précis, notez ce que vous voyez côté navigateur (erreur exacte, code HTTP si disponible), ce que disent les logs serveur et PHP, et ce que ça donne sur une session privée. Avec ces éléments, on peut généralement identifier si le problème vient de DNS, de cache, ou du serveur, puis restaurer la boutique avec une méthode propre, sans aggraver la situation.
Si vous le souhaitez, décrivez le symptôme exact (page blanche, erreur 500, message “site inaccessible”), le type d’hébergement (CDN oui/non, Nginx/Apache si vous savez), et le moment où le souci a commencé. Je peux vous aider à prioriser les vérifications les plus rentables pour votre configuration.