Sécurité et anti-fraude pour une boutique en ligne

La lutte anti-fraude en e-commerce n’est pas un « mur », c’est un thermostat. On équilibre en permanence deux risques : laisser passer une mauvaise transaction et perdre une bonne. Toute « dureté » coûte en conversion ; toute « souplesse » coûte en chargebacks et pertes. Gagne celui qui dose la friction : liberté quand le signal est propre, challenge mesuré quand le contexte inquiète.

Carte des menaces : qui nous attaque et comment

Les scénarios sont concrets :

• Carding et tests de plages BIN : micro-paiements massifs pour trouver des cartes actives et des patterns 3DS.
• Credential stuffing : essai de couples login/mot de passe issus de fuites, puis vol de points/adresses.
• Scraping/vitaling : aspiration de prix/stock pour du dumping ou l’achat de pénuries.
• Social : retours « sans article », faux accusés de réception, litiges « non reçu ».
• Intégrations faibles : interception/altération de webhooks, fuite de secrets, re-débits sans idempotence.

Marqueurs de risque : ce qui signale vraiment

Un seul signal décide rarement ; c’est l’ensemble qui compte.

• Contexte appareil/réseau : appareil inconnu pour ce compte, changement soudain de pays/ASN, décalage fuseau/locale, langue du navigateur et devise incohérentes.
• Comportement de session : parcours « éclair » vers le paiement, copier-coller dans des champs sensibles, timings trop réguliers, boucles « erreur → retry » avec micro-pauses (bots).
• Panier : article peu cher + livraison express coûteuse, multiples cartes cadeaux, combinaisons de tailles atypiques.
• Paiement : série d’échecs depuis un même BIN, cartes différentes pour une même adresse/téléphone, divergence billing/shipping.
• Historique : « nouveau client — panier cher — demande d’expédition accélérée », changements fréquents d’adresse, modification e-mail/téléphone avant paiement.

Au final — un risk score (0…1) qui choisit la route : passer, demander un facteur supplémentaire, imposer un 3DS challenge ou refuser.

3DS2 : où ça sauve et où ça casse

3DS2 a deux visages : frictionless (l’émetteur confirme sans action) et challenge (code/biométrie). Plus vous envoyez de contexte au PSP/émetteur, plus la voie frictionless s’ouvre.

• Transmettez des données « riches » : adresses, user-agent, empreinte d’appareil, historique du compte.
• Déclenchez le challenge au seuil de risque (nouvel appareil + panier cher + adresses incohérentes, etc.).
• Suivez step-up rate, challenge success rate et les codes de refus d’émetteurs.

L’erreur classique : forcer 3DS pour tout le monde — vous vous protégerez… de votre conversion.

Biométrie comportementale : « comment il saisit » > « qui il est »

Il s’agit de micro-patterns : rythme de frappe, trajectoire du curseur, inertie de scroll, équilibre tactile/clavier, micro-tremblements gyro sur mobile. Utile comme couche additionnelle, pas comme substitut.

Usages fins :

• Inscription/login : détecter les patterns non humains sans multiplier les CAPTCHAs.
• Checkout : distinguer un vrai client sur nouvel appareil d’un bot « qui tape trop régulier ».
• Support/retours : schémas anormaux lors du remplissage.

Vie privée : stockez des agrégats, pas les « traces brutes » ; respectez l’opt-out.

Bots, rate-limits et pièges doux

• Empreinte appareil/session (Canvas/WebGL, polices, codecs) — comme couche, pas comme pilier.
• Pièges invisibles : champs « miel » cachés, tâches JS difficiles pour les headless.
• Limites intelligentes : pas seulement l’IP. Croisez « IP + appareil + compte + BIN + adresse », captez les rafales (10 essais/3s) et les essaims d’un même ASN.
• Marécages anti-carding : augmentez la latence quand les échecs s’enchaînent.
• Challenges par paliers : petites tâches calculatoires, puis seulement CAPTCHA, et uniquement par segment à risque.

Webhooks et secrets : les détails qui font tomber le système

• Signez chaque webhook : HMAC du corps + timestamp ; vérifiez côté serveur avec rotation de secrets et fenêtre temporelle.
• Idempotence : un même event_id rejoué doit être sans danger.
• Ne comptez pas que sur des listes d’IPs : préférez mTLS ou signature utile.
• Secrets en coffre avec rotation/audit ; accès au plus-petit-privilège.
• Logguez les retries de webhooks comme des événements de premier ordre.

Les logs comme radiographie : où regarder

• Un trace_id unique du PDP jusqu’au PSP et au webhook retour.
• Couches : décision du moteur de risque, réponses émetteur/PSP, comportement client.
• Tableaux attaques : erreurs par BIN/ASN, rafales accélérées, cartes de chaleur horaires.
• Métriques 3DS : parts frictionless/challenge, succès de challenge, codes de refus — par pays/banque/appareil.
• Webhooks : part de retries, médiane de délai, désynchronisations PSP.

Liste panique : hausse des échecs depuis un ASN, pic do_not_honor, chute de frictionless sur une banque, avalanche de retries webhook.

Ne pas tuer la conversion : friction dosée

• Nouvel appareil + panier cher + express → step-up/3DS challenge.
• Compte ancien + appareil connu → passage sans friction.
• Répétitions sur un même BIN → « marécage » + limites, pas CAPTCHA global.
• Champs d’adresse : validez par locale pour améliorer l’acceptation PSP.

Chaque friction doit se justifier par une baisse mesurable du risque — pas par « on se sent mieux ».

Mini-pratique : squelette de moteur de risque

• Signaux : appareil, réseau, géo, comportement, panier, historique.
• Modèle : régression logistique/boosting + règles (fréquences, listes noires, routes interdites).
• Orchestration : branches allow / step-up / deny selon seuils et contraintes.
• Feedback : taguez chargebacks/litiges/« non reçu », stockez les raisons.
• Expériences : holdout de trafic pour mesurer l’apport réel et faciliter l’rollback.

Final : qu’est-ce qu’un succès ?

La cible n’est pas « zéro fraude », mais le coût du risque minimal pour un niveau de revenus donné.

• Opérationnel : approval rate, part frictionless, step-up rate, succès challenge, latence checkout.
• Financier : fraud-rate, chargeback-rate, marge brute par session en tenant compte de la friction.
• Détection : temps jusqu’à détection d’un pattern, temps jusqu’au déploiement d’un contre-mesure, qualité d’annotation.

Conclusion : réglez le thermostat : rotation des secrets, exercices réguliers, rapports d’incident et audits de friction — les courbes bougeront dans le bon sens sans sacrifier la conversion.