Quand une boutique WooCommerce tombe en panne, ce n’est pas juste un “site lent”. Très vite, on reçoit des messages clients: “j’ai été débité”, “je ne vois pas ma commande”, “le paiement n’aboutit pas”, ou pire, “ma page reste blanche”. Dans l’urgence, on a tendance à tout remettre comme avant et à espérer que “ça repart”. Sauf que, dans le cas d’un paiement bloqué ou d’un suivi de commande qui ne bouge plus, ce sont souvent des réglages, des logs ou des dépendances qui ont bougé à la suite de la panne, d’une mise à jour, ou d’une erreur critique WordPress.
J’ai déjà vécu ce scénario où l’équipe avait fait une mise à jour WordPress ratée, puis une réinstallation partielle, et la boutique semblait “en ligne”. Sauf que WooCommerce ne finalisait plus les paiements, et les commandes restaient coincées au statut “en attente” ou ne se déclenchaient plus dans l’interface de suivi. Le site était accessible, mais l’expérience acheteur était cassée. On ne parle plus d’un détail technique. On parle de chiffre d’affaires et de confiance.
Dans cet article, je te propose une méthode de dépannage WooCommerce orientée “paiement” et “suivi de commande”, avec des pistes concrètes sur les causes les plus fréquentes après panne. On va aussi croiser, quand c’est utile, les problématiques qu’on voit dans d’autres CMS comme WordPress ou PrestaShop, parce que les symptômes se ressemblent, mais les causes ne sont pas toujours les mêmes.
Les symptômes qui orientent vraiment (et ceux qui trompent)
Avant de toucher à quoi que ce soit, prends deux minutes pour classifier le problème. “WooCommerce en panne” peut vouloir dire beaucoup de choses.
Quand le paiement est instable, tu verras généralement:
- le client arrive jusqu’à la page de paiement, puis ça échoue, ou ça charge indéfiniment
- la page affiche une erreur après retour de paiement
- la banque ou le prestataire indique un paiement accepté, mais aucune commande n’apparaît
Quand le suivi de commande est cassé, ça ressemble plutôt à:
- une commande est passée, mais elle ne se déclenche pas dans ton workflow (email de confirmation manquant, traitement interne absent)
- le numéro de suivi n’est jamais renseigné
- le statut ne change jamais, même si tu as expédié
Et parfois, le souci est plus “bête” en apparence. Une page blanche PrestaShop ou une page blanche WordPress peut rendre l’ensemble du parcours impossible, mais tu peux aussi avoir un site WordPress en panne côté front, alors que le panier et les logs existent encore côté back-end. L’inverse arrive aussi: le site répond, mais WooCommerce est en état incohérent.
Le bon réflexe, c’est d’observer ce que fait la boutique au moment précis où ça casse. Un paiement, ce n’est pas “un clic”, c’est une suite d’appels, de redirections, de validations et de mises à jour de statut. Si un maillon rompt, tout le reste suit.
Comprendre le chemin du paiement WooCommerce (pour mieux diagnostiquer)
WooCommerce gère le paiement via des passerelles, souvent basées sur:
- un retour serveur après paiement (webhook ou endpoint)
- une mise à jour du statut de commande
- un envoi d’emails transactionnels
- parfois une synchronisation avec un système tiers (transporteur, ERP, marketplace)
Après une panne, ce chemin est souvent perturbé par trois catégories de causes.
Première catégorie: WordPress et WooCommerce ne sont plus dans l’état attendu. Une erreur 500 WordPress, une désactivation de plugin, un autoload cassé, ou un thème partiellement modifié peuvent suffire à casser des endpoints WooCommerce. On obtient alors des retours “incomplets” ou des requêtes qui échouent sans être visibles pour le client.
Deuxième catégorie: le plugin de paiement ou son paramétrage a été modifié. Une mise à jour WooCommerce ou une modification manuelle des paramètres de paiement peut changer le comportement du “retour”, ou invalider des identifiants, clés API, ou URL de webhook.
Troisième catégorie: la boutique “réussit” le paiement, mais n’enregistre pas la commande correctement, ou ne déclenche pas les statuts. Cela arrive quand:
- des hooks WooCommerce ne s’exécutent plus (thème ou plugin qui remplace des filtres)
- des actions planifiées (cron) ne tournent plus
- la base de données ou des tables associées ne sont plus cohérentes après une restauration incomplète
Ce modèle mental évite de tourner en rond. Tu cherches où le flux se casse, pas seulement “pourquoi ça ne marche pas”.
Sécuriser l’urgence: éviter d’empirer la situation
Quand une boutique est touchée, la meilleure action n’est pas toujours de “corriger” immédiatement. Parfois, c’est de stabiliser et de limiter l’impact.
Si tu constates des paiements acceptés côté prestataire mais des commandes absentes, ne continue pas à tester en boucle avec des cartes réelles. Utilise si possible les environnements de test, ou au minimum des montants faibles, et garde une trace. Dans mes interventions, le moment le plus pénible a été de rattraper un ensemble de tentatives dont personne ne savait lesquelles étaient “vraies” côté banque.
Trois actions aident généralement à garder le contrôle:
Même si tu fais du dépannage site internet de façon classique, le bon réflexe ici est de réduire la variabilité. Plus tu testes dans le désordre, plus tu perds le fil du diagnostic.
Diagnostic: vérifier l’état de WooCommerce et des endpoints de paiement
Une fois le calme retrouvé, on passe à la vérification technique. L’objectif est simple: confirmer que WooCommerce fonctionne, que les endpoints liés au paiement répondent, et que les statuts peuvent être mis à jour.
1) WooCommerce est-il réellement “actif” dans WordPress ?
Après une panne, j’ai déjà vu des cas où WooCommerce était installé mais pas activé, ou où des classes n’étaient plus chargées parce que le fichier de bootstrap était incomplet. C’est rare, mais ça arrive après des restaurations.
Dans WordPress, vérifie aussi:
- que les plugins WooCommerce et celui de la passerelle de paiement sont bien activés
- que le thème actif n’introduit pas d’erreurs (un thème “custom” peut casser des hooks)
- que tu n’es pas en mode maintenance global (ou qu’un plugin de cache n’a pas figé la boutique)
Si tu vois une erreur critique WordPress, une erreur 500 WordPress dans les logs, corrige d’abord la couche WordPress. Un site WordPress en panne peut donner l’illusion que “WooCommerce est le problème”, alors que l’origine est plus profonde.
2) Vérifier les logs: erreurs PHP et logs WooCommerce
C’est souvent là que tout se clarifie. Cherche au moment où un paiement échoue:
- des erreurs “fatal” ou “undefined function”
- des timeouts côté serveur
- des erreurs liées à l’appel d’API vers la passerelle de paiement
- des erreurs liées à la mise à jour du statut de commande
Quand le suivi de commande ne se met pas à jour, tu peux aussi trouver des indices dans les logs d’emails ou d’actions planifiées. Une commande peut être “passée” mais ne pas déclencher l’étape suivante, parce qu’une action ne s’exécute pas.
3) Cron WordPress: le suspect silencieux
Le cron de WordPress (ou l’équivalent côté hébergement) est un point de fragilité. Si le cron ne s’exécute plus, certains traitements WooCommerce ne tournent pas au bon moment. Par exemple, des tâches liées à:
- la synchronisation
- l’envoi d’emails
- des transitions de statut
- la mise à jour du traitement backend
Je ne prétends pas que “tout vient du cron”, mais après une panne et une restauration, c’est un classique. Si tu as restauré un site WordPress ou récupéré une sauvegarde, le cron peut être dans un état inattendu.
Cas fréquents après une panne: ce qui casse vraiment paiement et suivi
On passe maintenant aux scénarios que je rencontre le plus souvent, avec le type de symptômes qu’ils produisent.
Mise à jour ratée WordPress ou plugin
Une mise à jour WordPress ratée peut provoquer:
- des fichiers partiellement remplacés
- une incompatibilité de dépendances
- une base de données qui n’a pas fini ses migrations comme prévu
Résultat typique: l’interface charge, mais certaines routes internes ou endpoints échouent. Le client peut payer, mais le retour serveur ne met pas à jour la commande. Ou l’inverse, la commande est créée mais reste en attente.
Dans ce cas, l’approche est souvent la restauration propre de la partie WordPress, puis la reprise d’une mise à jour contrôlée. Si tu suspectes aussi un site WordPress piraté ou une réparation site WordPress piraté, il faut être prudent: corriger l’erreur sans vérifier l’intégrité peut remettre de la “casse” ailleurs.
Thème ou plugin qui override des hooks WooCommerce
Quand une boutique a été bricolée (même proprement), un plugin ou un thème peut surcharger des comportements WooCommerce. Après une panne, l’ordre de chargement peut changer. Là encore, le symptôme est trompeur: le checkout “voit” bien le formulaire, mais l’étape de confirmation ne déroule pas correctement.
Webhook de la passerelle de paiement non déclenché
Beaucoup de passerelles reposent sur des webhooks. Si la panne a modifié l’URL du site, le schéma (http vs https), ou les paramètres “retour”, le webhook peut arriver, mais être rejeté ou ignoré. Ce n’est pas forcément visible côté client. Parfois, côté banque, le paiement est validé, puis la commande reste inchangée.
Un détail qui revient souvent: la boutique a récupéré un certificat, ou a basculé en HTTPS, et la passerelle n’a pas été mise à jour. Le client voit une page qui se ferme, https://datasweb.fr/ mais le serveur ne traite pas le retour comme prévu.
Problème de base de données ou restauration incomplète
Après une restauration, la base peut être cohérente pour afficher la boutique, mais des tables ou options spécifiques à WooCommerce peuvent être en décalage. C’est plus fréquent quand on restaure “à la main” ou quand une sauvegarde a été partielle.
Le signe: des commandes partiellement créées, ou des statuts qui ne correspondent pas à l’état réel d’un paiement.
Étapes de dépannage concrètes (dans l’ordre où ça marche en pratique)
Voici comment je procède, en restant efficace et sans casser le reste.
1) Reproduire le problème avec une commande de test
Choisis une commande de test, idéalement sur un environnement de staging ou, si ce n’est pas possible, en utilisant les modes de test de la passerelle. L’idée est de pouvoir comparer:
- la trace côté navigateur (retours, pages, erreurs)
- la trace côté serveur (logs)
- l’état côté WooCommerce (statut de commande)
Une bonne reproduction évite de confondre “un paiement qui échoue” et “un paiement qui réussit mais dont la commande n’est pas mise à jour”.
2) Vérifier le statut et l’historique de la commande WooCommerce
Dans WooCommerce, ouvre la commande test, regarde:
- le statut actuel
- les notes de commande (souvent très parlantes)
- les événements qui auraient dû se produire
Si la commande devrait passer en “en cours de traitement” ou “payée” mais ne le fait pas, alors le problème est soit dans la passerelle (retour non traité), soit dans le mécanisme qui applique le statut.
3) Contrôler les paramètres de la passerelle de paiement
Même si ça paraît évident, après une panne, je vois des paramètres qui ont été modifiés sans que personne ne sache pourquoi: mode de test, clés API, URL de retour, activation de webhooks, etc.
Si tu as migré, changé le domaine, ou basculé en HTTPS pendant la panne, c’est une piste majeure.
4) Activer la journalisation et lire les erreurs au moment du paiement
Si WooCommerce ou la passerelle propose une journalisation, active-la. L’objectif n’est pas d’accumuler des fichiers illimités, c’est d’attraper l’erreur au moment précis. Sur une période courte, tu obtiens la cause.
Si tu vois une erreur 500 WordPress, corrige d’abord ce qui empêche le serveur de répondre correctement. Une passerelle ne peut pas “faire son travail” si le serveur tombe.
5) Vérifier les emails transactionnels et les actions planifiées
Quand le suivi de commande ne bouge pas, les emails de confirmation peuvent servir d’indicateur indirect. Si aucun email ne part, il y a souvent un souci de déclencheur, d’action planifiée, ou de traitement.
C’est là que le cron devient utile à vérifier, surtout après restauration.
Mini-checklist d’urgence (avant de changer des choses “au hasard”)
Cette checklist est courte parce qu’en dépannage WooCommerce, chaque minute compte, mais que tu ne veux pas non plus agir en aveugle.
- Tester un paiement en environnement de test, si possible, pour éviter de polluer les historiques.
- Consulter les logs serveur et les logs WooCommerce au moment exact de l’échec.
- Vérifier que le plugin de paiement et WooCommerce sont bien activés et compatibles avec la version WordPress.
- Contrôler le statut de la commande et les notes associées.
- Vérifier cron WordPress et la configuration des webhooks ou retours de paiement.
Si tu exécutes ces cinq points, tu as presque toujours assez d’indices pour orienter une réparation site WordPress, au lieu de faire une réparation à l’aveugle.
Quand le suivi de commande est “cassé”, ce n’est pas forcément le paiement
Parfois, la commande est bien marquée “payée”, et pourtant le suivi ne s’affiche pas ou ne s’actualise pas.
Les causes typiques:
- plugin de suivi transporteur désactivé ou incompatible
- clé API transporteur expirée
- règle de mapping des statuts modifiée
- envoi du numéro de suivi à un système tiers qui ne reçoit plus les données
- cache agressif qui masque les mises à jour dans l’interface client
Dans ces cas, je fais souvent le lien avec des problèmes qu’on retrouve en dépannage PrestaShop, même si l’architecture diffère. Sur PrestaShop, une page blanche PrestaShop ou une maintenance PrestaShop peut empêcher l’affichage des états, alors que le back-office fonctionne. Dans WooCommerce, c’est pareil mais moins “visuel”: le statut est mis à jour, mais l’acheteur ne le voit pas, ou les emails ne partent pas.
Le bon réflexe consiste à vérifier la séparation:
- WooCommerce met-il à jour le statut en back-office ?
- la synchronisation avec le transporteur est-elle exécutée ?
- l’affichage client et les emails reflètent-ils bien cette mise à jour ?
Et si le site est compromis, ou qu’une réparation a été faite sans audit ?
Il arrive qu’une panne s’accompagne d’un autre problème, un site WordPress piraté, ou une réparation site WordPress piraté mal menée. Les symptômes peuvent ressembler à un simple bug de paiement, parce que des scripts injectés perturbent des routes, des pages de checkout, ou des réponses serveur.
Les indices que je prends au sérieux:
- des erreurs critiques WordPress qui apparaissent sans logique claire
- des modifications de fichiers “trop récentes” sur des templates
- des tentatives externes, pics de trafic suspects, ou redirections
- une passerelle de paiement qui ne reçoit plus les retours correctement
Dans ce cas, je ne recommande pas de “bricoler WooCommerce” pendant que la sécurité est incertaine. D’abord, on stabilise et on rassure. Ensuite seulement on rétablit le flux.
Relation avec PrestaShop: pourquoi ça aide, même si tu dépannes WooCommerce
Tu n’as pas demandé PrestaShop, mais c’est utile, parce que les comportements “site inaccessible” ou “paiement partiellement traité” suivent parfois des patterns similaires.
- Sur PrestaShop, une maintenance PrestaShop mal configurée ou une mise à jour PrestaShop ratée peut rendre le front instable, avec des pages blanches ou des retours cassés.
- Sur WooCommerce, une maintenance WordPress, une erreur 500 WordPress, ou une désynchronisation de configuration peut provoquer un checkout qui semble fonctionner, mais une commande qui ne passe jamais au bon statut.
En pratique, quand tu as déjà eu affaire à un site PrestaShop inaccessible, tu sais où regarder: webhooks, retours, statuts, et logs. Le vocabulaire change, mais la mécanique reste comparable.
Réparer proprement: restaurer, mettre à jour, puis valider
Une fois que tu as identifié la cause, la réparation doit être propre, sinon tu risques une récidive au prochain pic de trafic ou après une prochaine mise à jour.
Voici comment je sécurise la phase “retour à la normale”:
- Restaurer avec une sauvegarde complète, pas une moitié: si tu as une sauvegarde de fichiers et une sauvegarde de base de données, elles doivent correspondre dans le temps.
- Mettre à jour de manière contrôlée: d’abord WordPress, puis WooCommerce, puis les plugins de paiement, jamais dans tous les sens à la fois.
- Revalider le flux de bout en bout: depuis le panier jusqu’au statut final de la commande, y compris emails et suivi.
Tu peux aussi prévoir une fenêtre de maintenance WordPress courte. Même si c’est pénible côté client, c’est souvent plus rapide que de corriger des effets secondaires liés à des utilisateurs qui achètent pendant que tu changes la boutique.
Cas particulier: le paiement réussit côté prestataire, mais la commande ne se crée pas
C’est un cas que je traite souvent en priorité, parce qu’il crée de la tension client.
Le diagnostic typique:
- retour du prestataire vers l’endpoint WooCommerce qui échoue
- webhook ignoré ou rejeté (URL, clé, paramètre)
- erreur serveur lors de la mise à jour du statut
- plugin de paiement en mode test ou configuration incohérente
La réparation consiste à:
- corriger la configuration du retour et des webhooks
- restaurer les endpoints WooCommerce cassés si nécessaire
- vérifier les logs sur les requêtes reçues
Le suivi de commande se rétablit ensuite, parce que le statut “payé” retombe au bon endroit et déclenche les étapes suivantes.
Cas particulier: la commande existe, mais le statut reste bloqué
Si la commande est créée mais reste coincée, tu as généralement:
- un traitement qui ne se déclenche pas (hooks ou cron)
- une règle de statut modifiée
- une erreur dans l’exécution de la passerelle de paiement ou du plugin de livraison
Ici, le diagnostic se joue sur:
- les notes de commande
- les événements enregistrés lors du paiement
- la présence d’emails transactionnels
- l’exécution des tâches planifiées
Une fois le déclencheur restauré, le statut revient à une trajectoire normale.
Ce que tu peux dire au client pendant que tu répares
Je l’ai compris en faisant du dépannage site internet “en direct”, il faut aussi gérer le message client.
Si tu sais qu’un paiement a eu lieu mais que la commande n’apparaît pas, tu peux rassurer sans mentir:
- expliquer que tu vérifies les retours serveur et la synchronisation
- indiquer que tu traiteras le statut manuellement si nécessaire
- demander une preuve de transaction (souvent une référence) pour retrouver la trace
Le but est de transformer “je suis bloqué” en “je suis suivi”. Techniquement, tu auras parfois besoin d’intervenir manuellement, mais si tu le fais avec rigueur, tu limites l’impact.
Valider la fin du dépannage: tests fonctionnels simples, mais indispensables
Après réparation, je ne me contente pas de “ça charge”. Je fais une validation courte, mais complète.
Tu veux confirmer au minimum:
- le checkout affiche la bonne passerelle
- le paiement aboutit et la commande passe au bon statut
- les emails de confirmation partent
- le suivi de commande apparaît ou se met à jour comme attendu
Si tu as aussi des intégrations externes (ERP, transporteur, marketplace), valide également le déclencheur de synchronisation.
C’est souvent à ce moment-là qu’on repère un dernier décalage, un cache qui bloque l’interface, ou une option de webhooks qui n’est pas tout à fait revenue.
Pour aller plus loin: mieux prévenir la prochaine panne
Une boutique qui a déjà vécu une erreur critique WordPress ou une mise à jour ratée ne doit pas repartir sans un minimum de garde-fous.
Sans basculer dans le “trop de process”, tu peux:
- planifier des mises à jour dans un environnement de préproduction
- garder des sauvegardes cohérentes (fichiers et base)
- surveiller les erreurs serveur et la santé WordPress
- s’assurer que les webhooks et retours de paiement sont corrects après tout changement (domaine, HTTPS, configuration)
La prévention, c’est aussi une façon d’éviter les discussions interminables quand “le paiement a été pris mais la commande n’existe pas”.
Si tu veux, donne-moi les éléments suivants et je te proposerai un plan de diagnostic encore plus précis, adapté à ton cas: type de passerelle de paiement (et si webhooks sont activés), statut actuel des commandes bloquées, version WordPress et WooCommerce, et un extrait des logs au moment du paiement (en masquant les clés).