Une vague de commandes fictives sur WooCommerce n’est pas seulement gênante. Elle peut polluer les statistiques, déclencher des e-mails et des réservations de stock, augmenter les coûts du prestataire de paiement et masquer une attaque de card testing : des robots essaient alors de nombreuses cartes ou identités pour vérifier lesquelles fonctionnent.
La bonne réponse n’est pas d’empiler immédiatement plusieurs CAPTCHA et plugins de sécurité. Il faut d’abord identifier le type d’abus, protéger le point d’entrée concerné et vérifier que les vrais clients peuvent toujours commander.
1. Identifier ce qui arrive réellement
Commencez par examiner un petit échantillon de commandes suspectes. Relevez uniquement les signaux utiles : heure, statut, moyen de paiement, pays, adresse e-mail, répétition du téléphone ou de l’adresse, rythme des tentatives et éventuels journaux du prestataire de paiement.
Trois scénarios reviennent souvent :
- des commandes gratuites ou en paiement à la livraison créées par un formulaire automatisé ;
- des paiements refusés répétés, typiques du test de cartes ;
- des inscriptions de comptes clients sans achat réel.
Ces situations ne demandent pas exactement les mêmes protections. Un blocage fondé uniquement sur l’adresse IP fonctionne mal quand les attaquants utilisent un réseau distribué. À l’inverse, une règle trop agressive sur le pays ou l’e-mail peut bloquer de vrais clients.
2. Mettre à jour avant d’ajouter une extension
Vérifiez WordPress, WooCommerce, le thème, la passerelle de paiement et les extensions du checkout. Une boutique en retard de plusieurs versions est plus difficile à diagnostiquer et peut conserver des comportements déjà corrigés.
Avant la mise à jour :
- réalisez une sauvegarde exploitable ;
- testez le panier, le checkout classique ou Blocks et les e-mails ;
- vérifiez les moyens de paiement réellement utilisés ;
- retirez les extensions abandonnées ou en doublon.
Une boutique propre et à jour offre une base plus fiable pour mesurer l’effet des protections suivantes.
3. Activer les protections du paiement
Le prestataire de paiement voit des signaux que WordPress ne possède pas : tentatives sur une carte, historique du réseau, empreinte de l’appareil ou rythme global. Activez d’abord ses protections antifraude et examinez les motifs de refus.
WooCommerce documente également des contrôles de fraude capables de demander une vérification supplémentaire ou de bloquer une transaction suspecte. Pour les attaques automatisées, les protections utiles sont généralement :
- une limite de tentatives sur une période courte ;
- une détection de vélocité par session, e-mail, téléphone ou adresse ;
- la mise en attente des commandes à risque plutôt que leur suppression immédiate ;
- une vérification avant capture du paiement quand elle est disponible.
L’objectif est d’arrêter l’abus avant qu’il ne génère des frais ou une commande exploitable, tout en conservant une possibilité de contrôle manuel.
4. Ajouter un challenge anti-bot au bon endroit
Un challenge tel que Cloudflare Turnstile ou reCAPTCHA peut réduire les soumissions automatisées. Il doit protéger le formulaire réellement attaqué : checkout, création de compte ou récupération de mot de passe.
Après activation, testez au minimum :
- une commande invité sur mobile ;
- une commande avec compte client ;
- chaque moyen de paiement important ;
- les erreurs de validation du formulaire ;
- le comportement quand le service anti-bot est indisponible.
Évitez deux CAPTCHA concurrents sur le même checkout. Ils peuvent doubler les scripts, créer des incompatibilités et dégrader la conversion sans améliorer réellement la sécurité.
5. Utiliser des règles de vélocité plutôt qu’une blacklist infinie
Une blacklist manuelle peut arrêter un motif évident, mais elle vieillit vite. Les règles de vélocité sont souvent plus robustes : trop de tentatives depuis une même session, plusieurs commandes proches avec des identités légèrement différentes, ou trop d’échecs de paiement sur une courte période.
Commencez avec des seuils prudents. Placez les cas suspects en attente et observez les faux positifs avant d’automatiser un blocage définitif. Une boutique B2B qui reçoit cinq commandes similaires d’une même entreprise n’a pas le même profil qu’un commerce destiné aux particuliers.
6. Protéger les effets secondaires du checkout
Même lorsqu’une commande est bloquée, vérifiez qu’elle ne déclenche pas inutilement :
- une réservation prolongée du stock ;
- une notification vers l’équipe ou le fournisseur ;
- la création d’un abonnement ;
- un appel vers un ERP ou un service de livraison ;
- des coûts d’API ou de transaction.
Les intégrations doivent réagir au bon statut de commande, pas à la simple création d’un brouillon. C’est particulièrement important avec le checkout Blocks, où une commande peut exister avant la fin du paiement.
Plan d’intervention en 30 minutes
- Exporter les identifiants des commandes suspectes et leur motif commun.
- Contrôler les journaux WooCommerce et du prestataire de paiement.
- Mettre à jour la boutique et supprimer les protections en doublon.
- Activer la limitation de tentatives ou la détection de vélocité.
- Ajouter un challenge anti-bot uniquement au formulaire attaqué.
- Passer deux vraies commandes de test, sur desktop et mobile.
- Surveiller les blocages et les faux positifs pendant plusieurs jours.
WooCommerce recommande de combiner les contrôles du checkout, les limites de tentatives et la revue des commandes à risque plutôt que de dépendre d’une seule règle. Consultez sa documentation sur la protection contre la fraude avant de choisir une extension supplémentaire.
Conclusion
Une protection efficace contre les commandes spam est progressive : observer, limiter, vérifier, puis automatiser. Un checkout qui bloque tous les robots mais aussi une partie des clients n’est pas sécurisé ; il est simplement inutilisable.
Si votre boutique subit une attaque ou si les commandes fictives reviennent malgré plusieurs plugins, nous pouvons réaliser un diagnostic technique et vérifier le checkout, les journaux, les intégrations et les protections déjà actives.