Urgence PrestaShop en Belgique : que faire lorsqu’une boutique tombe en panne ?

Une panne PrestaShop peut interrompre les commandes, empêcher les clients de payer ou afficher une erreur 500 sur l’ensemble du catalogue. Dans ce contexte, la priorité n’est pas de modifier des fichiers au hasard : il faut limiter l’impact commercial, identifier le périmètre de la panne et restaurer un état fonctionnel sans endommager les données de commandes. Voici une procédure opérationnelle pour gérer une urgence PrestaShop, y compris lorsque votre activité est basée en Belgique ou cible plusieurs marchés européens.

Qualifier la panne avant toute intervention

Commencez par vérifier le site depuis une fenêtre de navigation privée, un téléphone en 4G/5G et, si possible, un outil de contrôle externe. Une erreur peut être locale : cookie corrompu, adresse IP bloquée par un pare-feu, problème DNS chez un fournisseur d’accès ou cache navigateur. Testez au minimum la page d’accueil, une fiche produit, le panier, le tunnel de commande et le back-office.

Notez précisément l’heure de début supposée, les URL concernées, le message affiché et les actions effectuées juste avant l’incident : mise à jour d’un module, changement de thème, modification DNS, renouvellement de certificat SSL, import de produits ou intervention de l’hébergeur. Ces informations réduisent fortement le temps de diagnostic.

• Tout le site est indisponible : vérifiez l’hébergement, PHP, la base de données, le DNS, le certificat et un éventuel incident CDN.
• Le front-office fonctionne, mais pas le back-office : suspectez un module d’administration, les droits de fichiers, la session PHP, une restriction IP ou une erreur applicative.
• Le panier ou le paiement échoue : contrôlez les modules de paiement, les clés API, les webhooks, le certificat SSL et les journaux de commandes.
• Une seule page affiche une erreur : recherchez une surcharge, un module associé à cette fonction, une règle de réécriture ou un cache obsolète.

Préserver les ventes et informer les clients

Si le tunnel de commande est inaccessible, évitez de laisser les visiteurs face à une erreur technique. Activez temporairement une page de maintenance uniquement si le site entier doit être stabilisé. Elle doit indiquer un moyen de contact réel, par exemple une adresse e-mail ou un numéro professionnel. Ne promettez pas de délai que vous ne maîtrisez pas.

Si le catalogue reste accessible mais que le paiement ne fonctionne plus, un bandeau discret peut prévenir les clients sans bloquer la navigation : « Un incident technique affecte temporairement le paiement en ligne. Notre équipe intervient. » Vérifiez ensuite les commandes créées pendant la période concernée. Certaines peuvent apparaître avec un statut de paiement en attente, annulé ou erreur, selon le module utilisé.

Pour une boutique belge, testez les moyens de paiement réellement proposés à vos clients, notamment Bancontact si votre configuration l’utilise, ainsi que les cartes, PayPal ou virement. Une panne limitée à un prestataire de paiement n’exige pas forcément de mettre tout PrestaShop hors ligne.

Consulter les erreurs PrestaShop sans exposer le site

Une page blanche ou une erreur HTTP 500 masque souvent une exception PHP. En production, PrestaShop n’affiche généralement pas son détail afin de ne pas divulguer de chemins serveur, de versions ou de données techniques. Activez temporairement le mode débogage depuis le back-office lorsque celui-ci est accessible : Paramètres avancés > Performances > Mode debug. Désactivez-le immédiatement après le diagnostic.

Si le back-office est indisponible, la constante _PS_MODE_DEV_ peut être activée dans config/defines.inc.php sur de nombreuses installations PrestaShop. Cette opération doit être réalisée avec prudence et idéalement après une sauvegarde du fichier. Le message obtenu peut révéler un module précis, une classe introuvable ou une incompatibilité de version PHP. Il ne faut pas laisser ce mode actif sur une boutique publique.

Consultez également les logs PHP et les journaux de l’hébergement. Selon l’environnement, ils sont accessibles depuis le panneau d’hébergement ou dans des fichiers tels que var/logs/ sur les versions récentes. Recherchez l’horodatage de l’incident, puis remontez aux premières erreurs : les messages qui suivent sont souvent des conséquences.

Isoler un module, un thème ou le cache

Les modules sont une cause fréquente de panne après une mise à jour. Si l’erreur est apparue juste après l’installation ou l’actualisation d’un module, commencez par le désactiver. Quand le back-office n’est plus accessible, renommer temporairement le dossier du module dans /modules/ peut empêcher son chargement. Par exemple, renommer /modules/monmodule en /modules/monmodule.disabled permet de tester sans supprimer ses fichiers.

Ne désactivez pas plusieurs composants en même temps : vous perdriez la capacité à confirmer la cause. Après chaque action, videz le cache PrestaShop depuis le back-office ou supprimez uniquement le contenu du répertoire de cache adapté à votre version, sans effacer les fichiers de protection tels que index.php. Le cache applicatif, un CDN comme Cloudflare et le cache serveur peuvent chacun continuer à servir une version erronée ou ancienne.

Après une mise à jour de thème, repassez temporairement sur le thème précédemment fonctionnel si cela est possible. Une erreur Smarty, un template absent ou une surcharge incompatible peut casser uniquement le front-office. Vérifiez aussi que les permissions de fichiers n’ont pas été modifiées lors d’un déploiement.

Contrôler l’hébergement, la base de données et le domaine

Une boutique PrestaShop dépend de plusieurs services. Une page « Error establishing a database connection », une lenteur extrême ou des erreurs intermittentes peuvent signaler une base de données saturée ou inaccessible. Contrôlez l’état du serveur dans le panneau d’hébergement, l’espace disque disponible, les erreurs MySQL/MariaDB et les éventuelles limites de ressources PHP.

Vérifiez la version PHP imposée par l’hébergement et sa compatibilité avec votre version de PrestaShop et vos modules. Changer de version PHP en urgence sans environnement de test peut provoquer des erreurs fatales, notamment sur une ancienne boutique. Si une mise à niveau PHP vient d’être appliquée, revenir à la version précédente compatible peut être une mesure de rétablissement, avant de planifier les mises à jour nécessaires.

En cas de domaine inaccessible, contrôlez la date de renouvellement, les enregistrements DNS et le certificat SSL. Un certificat expiré ne provoque pas toujours une panne complète, mais il peut faire abandonner le tunnel de commande ou empêcher des appels API sécurisés. Si vous utilisez un CDN ou un proxy DNS, testez l’origine serveur avec prudence avant de modifier les enregistrements.

Restaurer une sauvegarde sans perdre les commandes récentes

La restauration est utile lorsqu’une mise à jour, une infection ou une manipulation a rendu la boutique instable. Elle ne doit toutefois pas être le premier réflexe. Restaurer simultanément les fichiers et la base de données à une heure antérieure peut supprimer des commandes, comptes clients, stocks ou messages reçus après la date de sauvegarde.

1. Identifiez la dernière sauvegarde complète fonctionnelle : fichiers, base de données et date exacte.
2. Exportez d’abord la base actuelle, même si la boutique est en erreur : elle peut contenir les commandes les plus récentes.
3. Restaurez de préférence sur un environnement de préproduction pour valider l’affichage, les comptes clients et le paiement.
4. Si la restauration en production est indispensable, mettez la boutique en maintenance et documentez l’heure de bascule.
5. Après retour en ligne, rapprochez les commandes du prestataire de paiement avec celles de PrestaShop afin de repérer les paiements non enregistrés.

Vérifier le retour à la normale et éviter une nouvelle interruption

Une boutique n’est pas rétablie parce que la page d’accueil s’affiche. Effectuez une commande de test avec un produit peu coûteux ou un environnement de paiement prévu à cet effet. Contrôlez la réception de l’e-mail de confirmation, le changement de statut de commande, la décrémentation du stock, la génération de facture si elle est activée et le retour depuis la page du prestataire de paiement.

Documentez ensuite la cause, les fichiers ou paramètres modifiés et l’action corrective. Mettez en place des sauvegardes automatisées exportées hors de l’hébergement, une surveillance HTTP des pages critiques, des alertes d’expiration de domaine et SSL, ainsi qu’un environnement de préproduction pour tester les mises à jour de PrestaShop, PHP, thèmes et modules. Cette préparation transforme une urgence future en intervention contrôlée plutôt qu’en arrêt prolongé des ventes.