Boutique PrestaShop inaccessible : les vérifications à faire avant d’intervenir

Lorsqu’une boutique PrestaShop devient inaccessible, la priorité n’est pas de modifier des fichiers, de vider tous les caches ou de désactiver des modules au hasard. Ces actions peuvent masquer le symptôme, aggraver la panne ou compliquer le retour arrière. Avant toute intervention, il faut qualifier précisément l’incident, vérifier ce qui est réellement touché et conserver les éléments utiles au diagnostic. Cette méthode permet de distinguer une panne d’hébergement, une erreur applicative PrestaShop, un problème de base de données, de DNS ou de certificat SSL.

1. Déterminer exactement ce qui est inaccessible

Le terme « site inaccessible » recouvre des situations très différentes. Relevez l’URL testée, l’heure, le message affiché et les actions effectuées juste avant la panne : mise à jour de module, changement de version PHP, restauration, modification DNS, renouvellement de certificat ou déploiement de thème.

• Erreur 500 ou 503 : le serveur répond, mais l’application ou son environnement rencontre une erreur.
• Page blanche : une erreur PHP fatale peut être masquée par la configuration de production.
• Erreur 502 ou 504 : le proxy web n’obtient pas de réponse correcte ou assez rapide de PHP-FPM, Apache ou du serveur amont.
• Erreur de connexion à la base de données : PrestaShop ne parvient pas à joindre MySQL/MariaDB avec ses identifiants actuels.
• Erreur DNS, « connexion non privée » ou délai d’attente : le problème peut être antérieur à PrestaShop.
• Front-office seul indisponible : vérifiez séparément /admin-dev ou le dossier d’administration renommé.
• Back-office seul indisponible : le catalogue et les commandes peuvent continuer à fonctionner côté client ; évitez alors les changements globaux inutiles.

Testez la boutique depuis une connexion mobile et depuis un autre réseau. Un blocage limité à votre adresse IP, à votre navigateur ou à un réseau d’entreprise ne constitue pas une indisponibilité générale. Testez également les variantes https://domaine.tld, https://www.domaine.tld et une page simple comme /robots.txt. Une redirection en boucle entre HTTP et HTTPS se repère ainsi rapidement.

2. Vérifier la disponibilité réseau, le DNS et le certificat

Avant d’ouvrir le code, contrôlez que le nom de domaine pointe vers la bonne infrastructure. Une modification récente des enregistrements A, AAAA ou CNAME, ou un ancien enregistrement IPv6, peut envoyer une partie des visiteurs vers un serveur différent. Comparez les adresses IP renvoyées par le DNS avec celles indiquées dans le panneau d’hébergement ou chez le prestataire CDN.

Si un CDN ou un pare-feu applicatif est utilisé, testez son tableau de bord : incident de service, règle de sécurité trop restrictive, certificat en erreur ou origine devenue injoignable. Ne désactivez pas durablement le pare-feu pour « tester ». Une désactivation courte, documentée et suivie d’un nouveau test peut isoler le CDN de l’origine, à condition de conserver une protection minimale et de la réactiver immédiatement.

Examinez le certificat SSL : nom de domaine couvert, date d’expiration et chaîne valide. Un certificat expiré n’empêche pas forcément le serveur de répondre, mais il bloque souvent les visiteurs et les appels externes. Si le navigateur affiche un avertissement de sécurité, ne saisissez pas d’identifiants d’administration sur la boutique tant que l’origine de l’alerte n’est pas identifiée.

3. Consulter l’état de l’hébergement avant de toucher à PrestaShop

Les indicateurs de l’hébergement donnent souvent la cause réelle : dépassement d’espace disque, quota d’inodes atteint, processus PHP saturés, service MySQL arrêté, changement de version PHP ou opération de maintenance. Une boutique peut tomber après l’épuisement du disque par des sauvegardes, des journaux ou des images, même si les fichiers PrestaShop n’ont pas changé.

• Contrôlez l’espace disque et les inodes disponibles.
• Vérifiez l’état de PHP, du serveur web et de MySQL/MariaDB dans le panneau d’hébergement.
• Consultez les journaux d’erreurs PHP et web sur le créneau exact de la panne.
• Repérez une modification automatique de version PHP, de limite mémoire ou d’extensions PHP.
• Vérifiez que les tâches cron, sauvegardes et imports ne consomment pas toutes les ressources.

Dans les logs, cherchez notamment Allowed memory size exhausted, PHP Fatal error, Permission denied, No space left on device, Too many connections ou une erreur de version de fonction PHP. Copiez quelques lignes avant et après l’erreur, avec l’horodatage. Elles sont plus exploitables qu’une simple capture d’écran d’une erreur 500.

4. Identifier une incompatibilité PHP, module ou thème

Une mise à niveau de PHP est une cause fréquente d’erreurs immédiates sur une installation ancienne ou un module non maintenu. Relevez la version PHP actuellement active, celle utilisée avant l’incident et les extensions activées. Ne supposez pas qu’un module est compatible parce qu’il s’installe : il doit être compatible avec votre version précise de PrestaShop et de PHP.

Si la panne survient juste après l’installation ou la mise à jour d’un module, gardez le nom, la version et l’heure de l’opération. Vérifiez les logs avant de désactiver quoi que ce soit. Une désactivation manuelle par renommage du dossier du module peut être utile pour une urgence, mais elle peut laisser des hooks ou une configuration incohérente. Effectuez-la uniquement après une sauvegarde, puis contrôlez le front-office, le panier, la connexion client et le tunnel de commande.

Activer le mode debug de manière temporaire

Lorsque la boutique affiche une page blanche ou une erreur 500 sans détail, le mode debug peut révéler l’exception. Sur de nombreuses installations PrestaShop 1.7 et 8, le paramètre se trouve dans config/defines.inc.php : passez temporairement _PS_MODE_DEV_ à true. Sur une boutique en production, ne laissez jamais ce mode actif : il peut afficher des chemins de fichiers, des requêtes ou d’autres informations techniques. Reproduisez l’erreur, notez le message complet, puis rétablissez la valeur précédente.

Ne confondez pas diagnostic et correction. Une erreur mentionnant une classe absente, un override ou un contrôleur permet d’orienter la recherche vers un module, un thème ou un déploiement incomplet ; elle ne justifie pas automatiquement une réinstallation complète de PrestaShop.

5. Contrôler la connexion à la base de données sans exposer les accès

PrestaShop dépend de sa base pour afficher le catalogue, charger la configuration et ouvrir le back-office. Pour les installations PrestaShop 1.7 et 8, les paramètres sont généralement dans app/config/parameters.php. Pour PrestaShop 1.6, ils se trouvent généralement dans config/settings.inc.php. Vérifiez le nom d’hôte, le nom de base, l’utilisateur et le préfixe des tables, sans publier ni transmettre le mot de passe dans un ticket non sécurisé.

Un test via phpMyAdmin ou la console de l’hébergeur permet de déterminer si la base répond et si les tables existent. Une base accessible depuis phpMyAdmin mais inaccessible depuis PrestaShop peut indiquer des identifiants modifiés, un hôte MySQL incorrect, un utilisateur non autorisé ou une configuration restaurée partiellement. Une erreur Too many connections doit être traitée côté serveur ou application : n’augmentez pas arbitrairement les limites sans comprendre les processus qui ouvrent les connexions.

6. Vérifier les fichiers, droits et caches avec prudence

Après une migration, une restauration ou un déploiement, comparez la date des fichiers modifiés et recherchez les fichiers incomplets. Les permissions doivent permettre au serveur web de lire les fichiers et d’écrire dans les répertoires nécessaires au cache, aux logs et aux images, sans ouvrir l’ensemble de l’installation en écriture. Évitez les permissions 777, qui ne corrigent pas une mauvaise propriété de fichiers et dégradent la sécurité.

Le cache peut contenir des classes ou des templates devenus obsolètes après une mise à jour. Si le back-office reste accessible, utilisez sa fonction de vidage de cache. S’il est inaccessible, effectuez une sauvegarde puis supprimez uniquement le contenu des répertoires de cache adaptés à votre version, et non les dossiers de structure. Sur les versions récentes, il s’agit souvent de var/cache/prod et var/cache/dev. Ne supprimez ni img, ni upload, ni les fichiers de configuration sous prétexte de « nettoyer » la boutique.

7. Préparer une intervention réversible

Avant toute correction, créez une sauvegarde exploitable des fichiers et de la base de données, ou vérifiez qu’un point de restauration daté est disponible. Notez l’heure de début de panne, le code d’erreur, les extraits de logs, les changements récents et les versions de PrestaShop, PHP et MySQL/MariaDB. Si des commandes sont en cours, évitez une restauration globale qui pourrait les effacer ou créer des écarts de stock.

1. Stabilisez l’accès : DNS, SSL, serveur et espace disque.
2. Identifiez le composant fautif grâce aux logs et au mode debug temporaire.
3. Appliquez une seule correction à la fois : rollback d’un module, retour PHP, réparation de permissions ou correction de configuration.
4. Testez une page produit, le panier, la connexion client, le paiement et le back-office.
5. Surveillez les logs après remise en ligne pour confirmer que l’erreur ne réapparaît pas.