Une erreur est survenue lors du traitement de votre commande : la réparer 🔧

Le client clique sur « Commander » et, au lieu de la page de remerciement, un bandeau rouge s’affiche : « Une erreur est survenue lors du traitement de votre commande », suivi d’une invitation à vérifier son moyen de paiement et son historique de commandes avant de recommencer. Ce message générique cache presque toujours une cause précise, que l’on retrouve vite quand on sait où regarder.

Que signifie « Une erreur est survenue lors du traitement de votre commande » ?

Ce message veut dire que le navigateur n’a pas reçu la réponse attendue du serveur quand la commande a été envoyée, et il ne dit rien de la cause réelle. C’est la traduction du texte anglais « There was an error processing your order » de WooCommerce.

Sur une page de commande classique (construite avec le shortcode de WooCommerce et non avec le bloc « Validation de commande »), le clic sur « Commander » envoie le formulaire en arrière-plan (requête AJAX, c’est-à-dire sans recharger la page) vers l’adresse /?wc-ajax=checkout. Le serveur doit renvoyer un petit texte au format JSON qui commence par {"result":"success". Si la réponse n’est pas du JSON valide, si le serveur répond par une erreur (500, 403, 504…) ou si la requête n’aboutit pas, WooCommerce affiche ce message générique. La fiche de notre décodeur consacrée à l’erreur « There was an error processing your order » en résume les causes en quelques lignes.

Point capital : la commande a parfois bel et bien été créée, et même payée, car l’erreur survient souvent pendant une étape annexe (e-mail, facture, synchronisation). C’est la source des doubles débits. Si votre boutique est à l’arrêt et que vous préférez confier le diagnostic, notre service de dépannage WooCommerce intervient à distance, partout en France.

Pourquoi cette erreur apparaît-elle au moment de payer ?

L’erreur vient presque toujours d’un code PHP qui plante ou affiche du texte pendant le traitement, et non du client ni de sa carte. Les causes, de la plus fréquente à la plus rare :

• Une erreur fatale dans une extension qui se branche sur la commande (facture PDF, e-mails, fidélité, synchronisation de caisse ou de CRM). Signe : réponse HTTP 500 et ligne « PHP Fatal error » dans les journaux.
• Un avertissement PHP affiché à l’écran (Warning, Notice, Deprecated), souvent après une mise à jour de PHP. Signe : du HTML comme <b>Deprecated</b> avant le JSON, et « Unable to fix malformed JSON » dans la console du navigateur.
• Une passerelle de paiement en échec : clés d’API invalides, mode test et mode réel mélangés, extension trop ancienne. Signe : l’erreur ne touche qu’un mode de paiement.
• Un pare-feu qui bloque la requête : ModSecurity chez l’hébergeur (un pare-feu qui filtre les requêtes), Cloudflare, extension de sécurité. Signe : réponse 403.
• Un traitement trop long : serveur SMTP qui ne répond pas, service externe lent. Signe : la roue tourne 30 secondes ou plus, puis réponse 502, 504 ou requête en échec.

Comment diagnostiquer l’erreur de commande WooCommerce, étape par étape ?

On lit d’abord la réponse du serveur, puis les journaux, et seulement ensuite on désactive des extensions. Sauvegardez avant tout les fichiers et la base de données, et travaillez si possible sur une copie de préproduction (un clone privé du site).

1. Vérifiez si la commande a quand même été enregistrée

Dans WooCommerce > Commandes, une commande « En attente de paiement » ou « Échouée » à l’heure de la tentative montre que l’erreur est survenue en cours de route. Comparez avec le tableau de bord du prestataire de paiement : si le client a été débité, prévenez-le avant qu’il ne recommande.

2. Reproduisez l’erreur avec un mode de paiement simple

Activez temporairement « Virement bancaire » dans WooCommerce > Réglages > Paiements, puis passez une commande test en navigation privée. Si l’erreur disparaît, la passerelle est en cause et notre guide sur le paiement WooCommerce refusé vous aidera à contrôler les clés et les webhooks. Sinon, cherchez du côté des extensions, du thème ou du serveur.

3. Lisez la réponse du serveur dans l’onglet Réseau

C’est l’étape qui fait gagner le plus de temps. Sur la page de commande, appuyez sur F12, ouvrez l’onglet Réseau (Network), tapez wc-ajax dans le filtre, puis cliquez sur « Commander ». Cliquez sur la ligne ?wc-ajax=checkout et regardez son code de statut et l’onglet Réponse. Une réponse saine ressemble à ceci :

{"result":"success","redirect":"https:\/\/votre-boutique.fr\/commande\/commande-recue\/1234\/?key=wc_order_..."}

Une réponse polluée par un avertissement PHP ressemble plutôt à cela (le nom de l’extension fautive apparaît dans le chemin du fichier) :

<br />
<b>Deprecated</b>:  ... in /home/compte/www/wp-content/plugins/nom-extension/includes/fichier.php on line 42<br />
{"result":"success","redirect":"https:\/\/votre-boutique.fr\/..."}

Selon le code de statut :

• 200 avec du texte avant le JSON : un avertissement PHP est affiché, voir l’étape 5.
• 500 : erreur fatale PHP, voir les étapes 4 et 5.
• 403 : la requête est bloquée par un pare-feu, voir l’étape 7.
• 502, 504 ou « (failed) » après une longue attente : délai dépassé, voir l’étape 8.

Si votre page utilise le bloc « Validation de commande » (le réglage par défaut des boutiques créées depuis WooCommerce 8.3), le message affiché diffère et la requête part vers wc/store/v1/checkout, mais la lecture est identique.

4. Consultez les journaux de WooCommerce

WooCommerce enregistre lui-même les erreurs fatales. Allez dans WooCommerce > État > Journaux et ouvrez le fichier dont la source est fatal-errors à la date de la tentative. Le chemin du fichier en cause (wp-content/plugins/nom-extension/…) désigne l’extension fautive. Ces fichiers sont stockés par défaut dans wp-content/uploads/wc-logs/, et les extensions de paiement y ajoutent les leurs si leur option de journalisation est activée.

5. Activez le journal de débogage de WordPress sans rien afficher

Le mode débogage enregistre toutes les erreurs PHP dans un fichier. Ajoutez ou modifiez ces lignes dans wp-config.php, juste avant la ligne qui commence par /* C’est tout (ou /* That's all, stop editing! dans un fichier en anglais) :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY à false empêche les messages de s’afficher, donc de casser la réponse JSON. Refaites une commande test, puis lisez la fin du fichier wp-content/debug.log par FTP, ou en SSH depuis la racine du site :

tail -n 50 wp-content/debug.log
grep -n "PHP Fatal" wp-content/debug.log | tail -n 20

Si rien n’apparaît, consultez le journal d’erreurs PHP de votre hébergeur. Une fois le problème réglé, remettez WP_DEBUG à false, car debug.log grossit vite et peut contenir des informations sensibles.

6. Faites un test de conflit sans casser la boutique

Si les journaux ne désignent pas de coupable, testez les extensions une par une. En production, ne désactivez jamais tout d’un coup : utilisez l’extension officielle « Health Check & Troubleshooting », dont le mode Dépannage désactive les extensions uniquement pour votre session, ou travaillez sur la copie de préproduction. Sur cette copie, avec WP-CLI (l’outil en ligne de commande de WordPress) :

wp plugin list --status=active
wp plugin deactivate --all --exclude=woocommerce
wp plugin activate nom-extension

Désactivez tout sauf WooCommerce, testez, puis réactivez les extensions une à une en testant après chacune. Sans WP-CLI, renommez par FTP le dossier de l’extension suspecte dans wp-content/plugins/. Faites ensuite le même test avec un thème par défaut : si l’erreur disparaît, regardez dans WooCommerce > État si des fichiers modèles sont signalés obsolètes.

7. Vérifiez le pare-feu de l’hébergeur et du CDN

Une réponse 403 indique un blocage. Cherchez dans le journal ModSecurity de l’hébergeur, les événements de sécurité de Cloudflare ou votre extension de sécurité une entrée à l’heure du test visant /?wc-ajax=checkout, et notez l’identifiant de la règle déclenchée.

8. Traquez les délais trop longs

Si la requête dure plus de 30 secondes, quelque chose bloque. Souvent, c’est l’e-mail de confirmation envoyé vers un serveur SMTP injoignable : testez l’envoi depuis votre extension SMTP. Vérifiez aussi max_execution_time dans Outils > Santé du site > Informations > Serveur, et cherchez « cURL error 28 » (délai dépassé vers un service externe) dans les journaux.

Comment corriger l’erreur selon sa cause ?

Une fois la cause identifiée, la correction est rapide :

• Extension en erreur fatale : mettez-la à jour ; si la dernière version est en cause, revenez à la précédente (wp plugin install nom-extension --version=1.2.3 --force, avec le numéro qui fonctionnait), prévenez son éditeur ou remplacez-la.
• Avertissement PHP affiché : WP_DEBUG_DISPLAY à false rétablit la vente tout de suite, puis mettez à jour l’extension fautive.
• Passerelle de paiement : mise à jour, clés d’API du bon mode (test ou réel) et adresse du webhook à vérifier chez le prestataire.
• Pare-feu : exception sur la règle identifiée, ou demande au support de l’hébergeur avec l’heure exacte et l’adresse bloquée.
• Cache : excluez les pages Panier, Commande et Mon compte du cache, comme expliqué dans notre guide sur le panier WooCommerce qui ne fonctionne plus.

Pour vérifier la réparation, passez une commande complète en navigation privée avec le mode test de votre passerelle : vous devez arriver sur la page « Commande reçue », avec le bon statut et les deux e-mails envoyés. Annulez ensuite cette commande test.

Comment éviter que l’erreur revienne ?

Quelques habitudes simples évitent l’essentiel de ces pannes :

• Testez les mises à jour sur une copie, puis passez une commande test après chaque mise à jour en ligne.
• Gardez WP_DEBUG_DISPLAY à false sur le site en ligne.
• Consultez chaque semaine les journaux fatal-errors de WooCommerce.
• Vérifiez la compatibilité de vos extensions avant tout changement de version de PHP.

Notre offre de maintenance WordPress peut aussi s’en charger pour vous.

Quand faire appel à un professionnel ?

Passez la main si des clients ont été débités sans commande visible, si l’erreur est aléatoire, si les journaux désignent WooCommerce lui-même ou si vous n’avez ni accès FTP ni copie de test. D’après notre page de tarification, une erreur causée par une extension se règle en 30 minutes à 1 heure (35 à 70 € TTC au tarif normal), et une boutique bloquée après une mise à jour majeure demande 2 à 4 heures (140 à 280 € TTC). L’audit est gratuit, et nos autres guides sont sur la page Résoudre une panne.