Quand une boutique PrestaShop “pète” côté affichage, ce n’est pas un souci cosmétique. Ça finit presque toujours par toucher le panier, le paiement, ou la confirmation de commande. Et plus ça dure, plus vous perdez des ventes, parfois sans même le voir tout de suite, parce que l’erreur ne concerne qu’une partie des visiteurs, une devise, une adresse de livraison, ou un navigateur en particulier.
J’ai déjà vu des boutiques qui affichaient correctement la homepage, mais qui renvoyaient des erreurs au moment du checkout. La page semblait vivante, le thème chargeait, les produits étaient visibles… puis au clic “Commander”, tout devenait flou. Un mélange de caches, de versions de modules, et de mises à jour pas totalement terminées. Dans cet article, je vous propose une méthode de dépannage WordPress? Pas directement, mais je vais vous montrer comment raisonner “comme en dépannage site internet” : isoler le symptôme, trouver le point de bascule, et redonner au checkout un état stable. Que vous fassiez aussi du dépannage WordPress sur la même infrastructure, la logique est la même, et c’est souvent là que les surprises apparaissent.
Le genre d’erreur qui bloque le paiement (et pourquoi l’affichage trompe)
Les problèmes d’affichage sur PrestaShop se manifestent rarement tous de la même manière. Parfois, vous avez une page blanche PrestaShop sur certaines pages, parfois des blocs qui sautent, des images qui ne chargent plus, ou des scripts qui cessent de s’exécuter après un certain chargement. Le checkout, lui, est plus fragile que le reste, car il enchaîne plusieurs étapes qui dépendent de données côté serveur et côté navigateur.
Dans la pratique, les erreurs qui touchent le paiement se regroupent souvent autour de quelques causes récurrentes :
- Une incohérence entre le thème et le back-office (par exemple un template obsolète, ou un override partiellement mis à jour).
- Un module de paiement ou de livraison qui ne supporte plus la version exacte de PrestaShop ou PHP configurée sur le serveur.
- Un problème de cache (fichier de cache périmé, cache de thème, cache d’OPcache, ou cache CDN) qui sert des ressources incomptables.
- Une mise à jour PrestaShop ratée, ou un déploiement interrompu (vous avez peut-être relancé, puis “ça a eu l’air d’aller”, sauf que le checkout n’a pas récupéré les bons chemins, ou pas la bonne configuration).
- Une erreur de configuration du serveur qui n’impacte pas la page produit, mais bloque la génération du “carte d’adresse” ou la création de l’entité commande.
Ce qui rend le diagnostic pénible, c’est que l’erreur peut apparaître seulement quand on arrive à une étape spécifique, par exemple après choix de l’option de livraison. C’est très courant quand un module de transport ou un calcul de taxes renvoie une erreur côté serveur, mais que le front continue d’afficher des éléments déjà rendus.
Commencer par “le point de bascule” plutôt que par “l’écran cassé”
Une erreur d’affichage sur PrestaShop donne envie de regarder la page. C’est normal. Mais en dépannage, je préfère toujours chercher le point de bascule. Où exactement tout se met à dérailler ?
Avant de toucher aux modules ou aux fichiers, j’essaie de répondre à trois questions simples, observables en quelques minutes :
Sur un cas récent, la boutique affichait correctement les produits et le panier. Mais dans le checkout, une requête “Ajax” revenait en erreur, et le formulaire ne finissait jamais d’être validé. Le thème affichait un texte par défaut, ce qui masquait le problème. Sans regarder le réseau, on aurait juré que “la page est juste moche”. En réalité, c’était une dépendance serveur qui répondait mal.
Vérifications rapides côté navigateur (sans faire n’importe quoi)
Si vous avez accès au navigateur de test (pas sur votre mobile principal, idéalement dans une fenêtre privée), ouvrez les outils développeur et regardez :
- L’onglet “Console” : erreurs JavaScript, scripts bloqués, variables non définies.
- L’onglet “Network” : requêtes “cart”, “checkout”, “payment”, “carrier” (ou équivalents). Cherchez des codes HTTP anormaux, surtout 4xx et 5xx.
- Le chargement des ressources : est-ce que des fichiers JS/CSS ne se chargent pas, ou chargent des versions inattendues ?
Quand le checkout ne valide pas, ce sont souvent des problèmes de requêtes dynamiques. Si vous voyez une requête qui renvoie un 500, il faut arrêter de bricoler le CSS et passer en investigation serveur.
Et si vous tombez sur des soucis typiques que l’on retrouve aussi en dépannage WordPress, comme l’erreur 500 WordPress ou un effet “ça marche parfois”, gardez en tête que le même hosting peut être impliqué. Parfois, une maintenance WordPress ou une mise à jour WordPress ratée sur le même serveur a laissé des changements de PHP, de configuration de base, ou un rollback incomplet. PrestaShop peut alors se retrouver dans une zone grise.
Côté serveur : activer les traces sans mettre la boutique à genoux
Pour diagnostiquer un problème de checkout, j’aime bien faire la différence entre “il se passe quelque chose” et “on sait exactement quoi”. Les logs et erreurs serveur sont souvent le chemin le plus court, à condition de ne pas ouvrir la vanne trop fort sur une boutique en production.
L’idée est simple : augmenter la visibilité sur les erreurs, mais garder le contrôle.
Sans entrer dans des réglages risqués, vous vérifiez généralement :
- Les logs d’erreurs PHP (souvent via le fichier error log du serveur ou le mécanisme de supervision).
- Les logs applicatifs PrestaShop (selon la configuration, vous pouvez retrouver des traces liées aux modules, au calcul de taxes, aux commandes).
- La configuration PHP (version, extensions, limites mémoire, exécution max). Un checkout qui “tire” un gros calcul peut échouer si la mémoire est trop basse.
Un détail que j’ai vu plusieurs fois : le back-office reste accessible, donc tout a l’air “ok”, mais le front checkout déclenche une fonction qui consomme plus. Résultat, l’écran de paiement peut échouer, tandis que d’autres pages marchent. C’est la même logique quand une boutique WooCommerce ou WooCommerce en panne sur un autre site affiche bien les pages produit, mais casse à la couche de calcul ou de validation.
Les causes les plus fréquentes quand le checkout ne revient pas
Plutôt que de lister des “solutions miracles”, je vais vous donner les scénarios qui reviennent le plus souvent dans les dépannages PrestaShop, notamment sur des boutiques qui ont récemment subi une maintenance PrestaShop ou une mise à jour PrestaShop ratée.
1) Cache incohérent (et oui, ça peut casser uniquement le paiement)
Le cache peut provoquer une sensation très étrange : la page ressemble à la bonne version, mais des morceaux qui participent au checkout sont chargés depuis un ancien état.
Typiquement, le mécanisme ressemble à ceci :
- Vous avez fait une mise à jour du thème ou un changement de module.
- Ensuite, une couche de cache (PrestaShop, CDN, proxy, OPcache) continue à servir des assets ou une version d’un endpoint qui ne correspond plus à la nouvelle logique.
- Le front envoie donc des appels Ajax à des routes qui ne répondent pas correctement.
Dans ces cas, j’applique une séquence de purge adaptée, au lieu de juste “rafraîchir la page”. On purge PrestaShop et aussi les caches de niveau supérieur si vous en avez (CDN, plugin cache, reverse proxy). Si vous utilisez un service CDN, j’ai déjà vu des délais de purge qui laissent le checkout casser pendant un bon moment.
2) Module de paiement, de livraison, ou de taxes incompatible
Le checkout dépend de plusieurs pièces. Si un module particulier a été mis à jour trop tôt, ou si sa configuration a changé, vous pouvez avoir :
- une erreur quand le système tente de calculer la livraison,
- une erreur sur la page paiement (token, signature, appel API),
- ou une commande qui n’aboutit pas (dépend d’un retour module).
J’ai déjà résolu un cas où seul un mode de paiement échouait, alors que les autres fonctionnaient. Le problème venait d’un module dont le backend avait été mis à jour, mais pas le front. Résultat : le token envoyait une valeur attendue par une ancienne version.
3) Base de données pas alignée après mise à jour
Une mise à jour PrestaShop ratée peut laisser la base dans un état partiel, notamment si des migrations n’ont pas été exécutées ou interrompues.
On le détecte souvent via des erreurs applicatives côté serveur, mais parfois, c’est plus subtil : les pages affichent, mais des entités liées au checkout (commande, panier, règles fiscales) échouent.
Le signe fréquent : ça casse sur certaines étapes, pas sur tout. Le checkout est une bonne “sonde” de cohérence.
Une checklist de dépannage (du plus safe au plus direct)
Avant de toucher aux fichiers, voici une séquence courte que j’utilise pour les urgences, quand la boutique PrestaShop devient inaccessible ou que le checkout ne termine pas. Elle limite les pertes de temps, et elle évite les fausses pistes.
- Purger le cache PrestaShop, puis purger le cache CDN ou plugin (si présent), et tester en navigation privée.
- Désactiver temporairement les modules non essentiels, en commençant par ceux liés au paiement et à la livraison, puis tester le checkout.
- Vérifier les logs d’erreurs PHP et les traces applicatives au moment où vous lancez le paiement (recherchez un code 500 ou une exception).
- Contrôler la version PHP et les extensions actives, notamment si vous avez fait une maintenance PrestaShop ou un changement d’hébergement.
- Si une mise à jour PrestaShop a eu lieu récemment, comparer l’avant/après (fichiers modifiés, configuration de modules, backups disponibles) et revenir à un état stable si nécessaire.
Cette checklist ne remplace pas un diagnostic complet, mais elle fonctionne bien quand vous avez besoin de remettre le checkout en service, puis d’enquêter proprement.
Quand c’est “page blanche PrestaShop” mais que le checkout reste le vrai test
Une page blanche PrestaShop peut venir de plusieurs sources : limite mémoire, erreurs fatales PHP, fichiers manquants, conflits de hooks, ou problème de compilation de templates. Si vous avez une page blanche générale, c’est souvent plus simple à cerner, car les logs racontent la panne.
Mais parfois la boutique affiche le haut de page, ou certains composants, puis tombe en erreur. Dans ce cas, je traite le checkout comme un “laboratoire”. Si je peux obtenir une commande complète, même en mode dégradé (par exemple en désactivant certains modules), je sais que l’infrastructure et la base de PrestaShop sont globalement OK.
Ensuite seulement, je reviens sur l’affichage global.
Réparer sans casser davantage : le piège des “retouches” en direct
En urgence, on fait souvent des choses dans le bon sens, mais trop vite : modifier un fichier pour tester une théorie, uploader un thème différent, ou pousser une mise à jour en production pendant que le trafic passe.
Le risque, c’est de transformer un problème localisé en plusieurs problèmes. Par exemple, vous pouvez corriger l’erreur d’affichage, mais casser le checkout parce que le thème dépend d’un helper ou d’un hook qui n’existe plus.
Mon approche en cas de doute : je préfère un plan d’action en deux temps.
D’abord, rétablir un checkout stable, même imparfait. Ensuite, refaire propre, une fois la boutique de nouveau monétisable. C’est exactement le genre de stratégie qu’on applique aussi en dépannage WooCommerce, quand l’erreur se produit uniquement à l’étape de paiement. Réparer vite, contrôler, puis améliorer.
Et si la cause vient d’un incident plus large sur l’hébergement ?
Il arrive qu’une panne touche plusieurs sites dans la même infrastructure. Vous pouvez avoir un site WordPress en panne sur la même machine, ou un autre CMS qui tombe en erreur 500 WordPress, pendant que PrestaShop montre des symptômes d’affichage.
Ce scénario est fréquent quand un changement d’environnement a eu lieu :
- modification de la version PHP,
- ajustement de la mémoire ou max execution time,
- redéploiement Nginx ou Apache,
- rotation de logs,
- ou mise en place d’une couche de cache.
J’ai déjà vu des boutiques où une “maintenance rapide” a été faite sur WordPress, puis l’équipe a mis la boutique PrestaShop en production juste après, sans vérifier la compatibilité PHP. Le résultat, c’est un mélange de comportements : WordPress affiche parfois des pages, mais déclenche des erreurs critiques WordPress (et PrestaShop casse au checkout).
Si vous êtes dans ce cas, la meilleure preuve, c’est de regarder l’heure exacte du basculement, et de vérifier ce qui a changé à cette minute.
Sécurité : quand l’affichage casse parce que la boutique a été piratée
On ne veut pas y penser, mais c’est utile à garder en tête. Un site PrestaShop en panne peut aussi être le symptôme d’un site piraté, et pas uniquement d’un mauvais cache ou d’un module.
Il y a des signaux qui reviennent souvent lors d’une compromission :
- comportement incohérent selon les visiteurs,
- contenus injectés dans les pages ou dans des zones inattendues,
- redirections vers des URLs bizarres,
- création de fichiers récents dans des répertoires “non naturels”,
- ou en-têtes et scripts modifiés.
Si vous suspectez un site WordPress piraté sur un autre projet (parce que vous gérez tout pour le client), la logique est la même : vérifiez l’intégrité, regardez les modifications récentes, et isolez la cause. Le dépannage WordPress dans ce contexte ressemble beaucoup à la phase “assainissement” en PrestaShop : couper l’accès non sécurisé, analyser, restaurer un état sain depuis un backup.
Je ne vais pas vous donner des étapes d’attaque ou des outils dans l’absolu, mais je peux vous conseiller une discipline simple : si vous voyez des indicateurs de sécurité, commencez par isoler (mise en maintenance si nécessaire) et par revenir à un état fiable.
Rétablir le checkout en mode “dégradé”, puis améliorer
Quand le checkout est cassé, la priorité devient “commande possible”. Je recommande souvent d’adopter un mode dégradé le temps de réparer le fond.
Cela peut vouloir dire :
- désactiver temporairement un module de paiement le temps de tester,
- basculer sur un transport ou un mode de livraison alternatif,
- réduire certains plugins qui déclenchent des scripts côté front.
L’intérêt : vous récupérez des ventes rapidement, même si tout n’est pas “parfait visuellement”.
Dans un dépannage PrestaShop, c’est souvent ce qui évite que le client perde toute la journée. Et comme le checkout est l’étape la plus sensible, c’est aussi le meilleur indicateur pour savoir si la réparation tient.
Plan de stabilisation après la correction (pour éviter la rechute)
Une fois que vous avez remis le checkout debout, c’est tentant de refermer le ticket. C’est justement le moment où les pannes reviennent si vous n’avez pas solidifié le correctif.
Je fais alors une mini-méthode de stabilisation, en gardant le cap : documenter et verrouiller.
- Capturer les changements effectués (modules désactivés, purges de cache, versions impliquées).
- Tester un scénario complet : panier, adresse, livraison, paiement, confirmation de commande.
- Vérifier que les pages clés s’affichent sans erreurs console (pas uniquement “ça charge”).
- Prévoir une action de maintenance PrestaShop planifiée (au calme, sur un créneau) si des mises à jour ont été touchées.
- Mettre en place une reprise simple depuis backup, si vous devez rejouer une correction ultérieure.
Cette approche réduit la probabilité d’une nouvelle mise à jour PrestaShop ratée, ou d’une rechute liée à un module qui se réactive de manière inattendue.
Cas concrets : ce que j’ai vu dans la réalité (et comment ça se traduit dans vos tickets)
Je vous donne trois scénarios que vous risquez de rencontrer.
Cas 1 : checkout cassé sur un seul transport
Le client me dit que la commande échoue “quand on choisit tel mode de livraison”. Le panier est bon, l’étape adresse est bonne, puis au moment du calcul de livraison ça déraille.
Ce que je trouve souvent : un module de transport qui n’arrive pas à renvoyer une réponse cohérente. Parfois c’est une configuration d’API, parfois une dépendance PHP. La correction consiste à aligner la configuration, ou à remettre un module à une version compatible, puis à purger les caches.
Cas 2 : scripts qui ne s’exécutent plus après mise à jour du thème
Ici, le checkout affiche des champs, mais le bouton de paiement ne déclenche rien, ou déclenche une erreur silencieuse. En site WordPress en panne console, vous voyez une erreur “is not defined” ou des ressources 404.
Ce n’est pas forcément un problème de PrestaShop core. Très souvent, c’est un thème qui charge un fichier non présent, ou qui suppose une variable ajoutée par un module pas activé. La correction consiste à remettre la version cohérente du thème et à supprimer les restes d’un précédent déploiement.
Cas 3 : “ça marche pour moi” mais pas pour les nouveaux clients
C’est un classique : votre compte administrateur a plus d’autorisations, certains caches sont différents, ou des règles de panier ne s’appliquent pas aux comptes VIP. Du coup, vous testez, ça semble bon, mais les conversions s’effondrent.
Je traite ce problème en multipliant les tests : navigation privée, compte test sans historique, et appareils différents. On compare aussi les requêtes réseau, et on cherche une différence logique, pas seulement un détail visuel.
Checklist de diagnostic express (quand vous êtes en urgence le jour même)
Il y a une version encore plus courte à garder sous le coude. Pas pour remplacer l’analyse, mais pour gagner du temps quand la boutique est en pénurie de patience.
- Test sur navigation privée et navigateur différent, pour sortir des caches et extensions.
- Chercher une requête qui renvoie 5xx au moment du checkout.
- Désactiver temporairement le module de paiement le plus récent (ou le plus suspect) et tester à nouveau.
- Purger cache PrestaShop et cache de niveau supérieur, puis retester immédiatement.
- Si une mise à jour PrestaShop ratée a eu lieu récemment, revenir à l’état précédent qui fonctionnait.
Si vous faites déjà ça, vous prenez une longueur d’avance sur la majorité des interventions qui consistent à “modifier au hasard”.
Ce que je vous recommande pour éviter les prochains déboires
Les pannes PrestaShop, comme les incidents sur WordPress ou WooCommerce, ont souvent une racine commune : un changement déployé trop vite, sans validation sur un environnement proche, ou sans rollback prévu.
Votre meilleur outil, c’est un processus de mise à jour.
Si vous gérez plusieurs plateformes, comme un WordPress plus une boutique PrestaShop, je vous conseille de garder une cohérence de planification. Les équipes qui réparent WooCommerce en panne sur un site, puis qui subissent un site WordPress en panne, finissent souvent par mettre en place une “fenêtre de maintenance” standard et une méthode de retour en arrière.
Sur PrestaShop, je privilégie aussi :
- un staging quand c’est possible,
- une purge de cache systématique après certains changements,
- et une vérification du checkout avant de considérer la mise à jour comme “finie”.
Besoin d’un dépannage PrestaShop sur votre boutique ?
Si vous êtes dans une situation où la boutique PrestaShop est inaccessible, ou que vous voyez des erreurs d’affichage qui finissent par empêcher le checkout, le plus utile est de rassembler quelques éléments avant d’engager des corrections :
- l’heure à laquelle le problème est apparu,
- ce qui a changé juste avant (mise à jour PrestaShop, mise à jour thème, changement hébergement),
- le message exact ou le code HTTP observé,
- une capture de la console navigateur et des requêtes échouées.
Avec ça, on peut passer beaucoup plus vite de “on suppose” à “on sait”.
Et si vous avez aussi un autre site (WordPress, WooCommerce) qui connaît des soucis du même ordre, le diagnostic devient encore plus intéressant, parce que les causes d’hébergement et les changements transverses se repèrent plus facilement. C’est souvent là que se cache le vrai coupable, pas forcément dans PrestaShop lui-même.
Si vous voulez, décrivez-moi votre symptôme précis (page blanche PrestaShop, erreurs au checkout, transport qui bloque, message en paiement, code 500 ou autre), et ce qui a été fait juste avant. Je vous aiderai à orienter la recherche vers la cause la plus probable, sans vous faire perdre du temps.