Sur une boutique qui traite plusieurs centaines de commandes par mois, la question de la fraude finit toujours par se poser : faut-il faire confiance au score de risque intégré à WooCommerce, activer Stripe Radar en plus, ou choisir l’un plutôt que l’autre ? Nous avons eu l’occasion de comparer les deux sur un même flux de commandes pendant plusieurs mois pour un client vendant du matériel électronique, une catégorie particulièrement ciblée par la fraude à la carte volée.
Le constat de départ est simple : ces deux outils ne mesurent pas la même chose, et les confondre conduit à une fausse impression de double protection alors qu’ils se chevauchent en réalité assez peu.
Deux logiques de calcul différentes
Le score antifraude natif de WooCommerce, exposé notamment via les extensions de paiement qui l’implémentent, repose principalement sur des règles locales : cohérence entre l’adresse de facturation et l’adresse IP, vitesse de passation de plusieurs commandes depuis la même session, écarts entre pays de la carte et pays de livraison. C’est une approche par règles, transparente, mais qui ne voit que ce qui se passe sur votre propre boutique.
Stripe Radar, à l’inverse, est un modèle de machine learning entraîné sur l’ensemble du volume de transactions traité par Stripe, tous marchands confondus. Il détecte des schémas invisibles à l’échelle d’une seule boutique : une carte testée sur plusieurs sites en quelques minutes, un appareil déjà associé à des rétrofacturations ailleurs, une empreinte de navigateur suspecte. C’est un signal statistique global, pas une règle métier explicite.
Ce que montrent les commandes réelles
Sur notre échantillon, environ 40 % des commandes signalées à risque élevé par Stripe Radar ne déclenchaient aucune alerte du score natif WooCommerce, et inversement. Les cas de recoupement — où les deux systèmes signalaient la même commande — concernaient presque exclusivement des tentatives grossières : IP de datacenter, adresse de livraison dans un pays différent de la carte et du pays de facturation, montant anormalement élevé pour un premier achat.
Les divergences intéressantes se situaient ailleurs. Stripe Radar a intercepté plusieurs cartes testées par petits montants (méthode dite du « card testing »), un schéma que le score local ne peut tout simplement pas voir puisqu’il n’a accès qu’aux commandes de la boutique elle-même. À l’inverse, le score natif WooCommerce a repéré des commandes suspectes en croisant des données propres au métier du client — un compte client créé le jour même, une adresse de livraison correspondant à un point relais déjà signalé manuellement par l’équipe logistique — que Stripe Radar, faute de contexte métier, ne pouvait pas pondérer de la même façon.
| Critère | Score natif WooCommerce | Stripe Radar |
|---|---|---|
| Source des données | Commandes de la boutique uniquement | Volume global Stripe |
| Type de détection | Règles explicites configurables | Modèle statistique opaque |
| Détection du card testing | Faible | Forte |
| Prise en compte du contexte métier local | Bonne | Nulle |
| Coût | Inclus dans l’extension de paiement | Facturé par transaction évaluée |
Le coût des faux positifs
Sur un panier moyen élevé, un faux positif coûte cher : un client légitime bloqué abandonne rarement sa commande sans se plaindre. Nous avons observé que Stripe Radar, en configuration par défaut, avait tendance à se montrer plus prudent sur les premières commandes de clients internationaux payant avec une carte étrangère à leur pays de livraison habituel — un schéma pourtant fréquent et légitime pour une boutique qui vend en Europe entière. Ajuster les règles Radar (notamment désactiver le blocage automatique et ne garder que le signalement pour revue manuelle) a réduit ces faux positifs sans rouvrir la porte au card testing.
Faut-il utiliser les deux ?
Notre conclusion, après plusieurs mois d’observation, est que les deux systèmes sont complémentaires plutôt que redondants. Le score natif WooCommerce reste pertinent pour les règles propres au métier du marchand, tandis que Stripe Radar apporte une couche de détection que seule l’échelle globale de Stripe permet. La bonne pratique consiste à configurer Radar en mode « signalement » plutôt que blocage automatique, et à laisser une équipe humaine trancher sur les commandes à risque moyen, en s’appuyant sur les deux scores plutôt que sur un seul.
Un score de risque n’est jamais une décision, c’est une priorité de relecture. Le vrai gain, c’est de faire remonter les dix commandes à vérifier avant l’expédition, pas de bloquer automatiquement.
Notre verdict
Aucun des deux outils ne suffit seul sur une boutique à volume significatif. Stripe Radar excelle sur la détection de schémas globaux (cartes volées en circulation, card testing), le score natif WooCommerce excelle sur le contexte métier local. Les faire cohabiter, avec Radar en mode signalement plutôt que blocage strict, donne le meilleur compromis entre sécurité et taux de conversion sur les commandes légitimes.
