Un checkout WooCommerce peut être cassé alors que la page charge encore. C'est la difficulté principale : l'uptime dit que le site répond, mais le parcours d'achat ne produit plus de commande exploitable.
Ce guide sert de point d'entrée. Il aide à localiser la famille de panne avant d'ouvrir le guide spécialisé : panier vidé, checkout bloqué, paiement refusé, erreur 500, validation impossible ou confirmation absente.
Cartographier les symptômes
Les symptômes les plus fréquents ne racontent pas tous la même histoire :
- Panier vide après ajout : suspicion cache, session, cookie, domaine ou Store API.
- Bouton commander absent ou inactif : suspicion thème, script, validation ou Checkout Blocks.
- Moyens de paiement invisibles : suspicion gateway, devise, livraison, SSL, webhook ou configuration.
- Loader infini : suspicion Ajax, `update_order_review`, iframe de paiement, timeout ou 3DS.
- Erreur 500 ou page blanche : suspicion PHP fatale, plugin, thème, endpoint serveur ou conflit après mise à jour.
- Absence de page merci : suspicion retour gateway, création de commande, redirection ou confirmation.
Chaque symptôme doit ensuite être vérifié avec le guide précis. Par exemple, un panier WooCommerce vidé ne se traite pas comme un paiement refusé WooCommerce.
Vérifier dans le bon ordre
Commencez toujours par le premier signal perdu. Si l'ajout panier échoue, inutile de tester le paiement. Si le panier est stable mais que les moyens de paiement disparaissent, la recherche doit se concentrer sur gateway, éligibilité, scripts et configuration. Si tout va bien jusqu'au clic final, contrôlez requête de commande, passerelle et confirmation.
Documentez chaque étape avec le résultat attendu et le résultat observé. Une bonne preuve ne se limite pas à "checkout cassé" ; elle dit "panier stable, checkout chargé, moyen de paiement absent après recalcul livraison" ou "commande envoyée, retour 500 sur requête finale".
| Premier signal perdu | Ce qu'il est inutile de tester ensuite | Où concentrer la recherche |
|---|---|---|
| L'ajout au panier échoue | Le paiement | Panier, session, cache, Store API |
| Le panier tient, les moyens de paiement disparaissent | Le clic final | Passerelle, éligibilité, scripts, configuration |
| Tout tient jusqu'au clic final | Les étapes amont | Requête de commande, passerelle, confirmation |
Interpréter sans mélanger les causes
Un incident transitoire n'est pas forcément un faux positif. Si le signal échoue une fois puis revient, il peut s'agir d'une panne brève, d'une saturation ou d'une dépendance externe. Le faux positif, lui, se démontre en trouvant une limite du test : sélecteur trop fragile, produit de test indisponible, règle volontaire ou environnement non représentatif.
Une panne persistante demande une action immédiate. Une panne transitoire demande une trace et une surveillance renforcée. Un faux positif demande une correction du monitor. Les trois cas doivent apparaître différemment dans le rapport.
Exemple documenté de laboratoire
Point de départ : boutique de test à jour, un plugin de livraison ajouté la veille. Panne reproduite : le produit synthétique s'ajoute au panier, le panier reste correct, puis le checkout affiche un loader infini après recalcul. Le statut HTTP de la page reste 200. Le signal utile n'est donc pas l'uptime, mais l'absence d'état final : pas de moyens de paiement stables, pas de commande, pas de confirmation.
Les hypothèses écartées orientent le diagnostic : ce n'est pas un panier perdu (il est intact à l'entrée du checkout), pas un refus de paiement (aucune tentative n'est transmise), pas une simple lenteur (l'attente ne se résout jamais). La preuve indique alors le premier run en échec, la requête de recalcul concernée, la classe d'erreur, le dernier run cassé et le premier run revenu au vert. Elle évite les données personnelles, les détails de carte et le contenu panier client.
Confirmer la résolution
Un checkout revient au vert lorsque le même parcours contrôlé revalide les étapes critiques. Pour un incident panier, le panier doit survivre jusqu'au checkout. Pour un incident paiement, les moyens attendus doivent être visibles et l'étape de paiement cohérente. Pour une erreur serveur, le statut et le contenu doivent revenir ensemble.
Prévenir la récidive
La plupart des checkout cassés suivent une mise en production : plugin ajouté ou mis à jour, changement de thème, bascule de cache ou de passerelle. Gardez une trace datée de ces changements, rejouez le parcours contrôlé juste après chaque déploiement, et conservez un monitor permanent sur l'étape qui avait cassé pour détecter une rechute avant le client.
La méthode complète de surveillance est détaillée dans comment CashFlowCanary surveille un checkout WooCommerce. Pour cadrer un premier site, lancez Mon Audit Gratuit, puis vérifiez la couverture disponible dans les tarifs.