Détection de bots et antifrod logique

Résumé succinct

Une protection efficace contre les bots et la fraude est une combinaison de couches : collecte de signaux (client, réseau, appareil, comportement), balayage des risques en temps réel, règles (deterministic) + modèles ML (probabilistic), analyse graphique des liens et processus d'escalade rigoureux. L'objectif est de bloquer les dommages tout en conservant l'UX et la conversion.

Menaces et vecteurs

Bots et scrapers : enregistrement, login-surpoids, phare de codes promotionnels, promotion des bilans, mise en circulation automatique des demandes/paris.
Compte Takeover (ATO) : credential stuffing, phishing, vols de session.
Payment fraud : cartes volées, test des limites, chargeback-farming.
Bonus abuse : multi-accounting, « familles » d'appareils/adresses, proxy/émulateurs.
Abus Affiliate/CPA : faux enregistrements/dépôts, clic-frod.

Architecture antibot/antifrod pile

1. Capteurs et télémétrie : avant-JS/SDK (signaux humains), SDK mobile, métriques réseau/NTR, événements backend.

2. Feature Store (en ligne/hors ligne) : normalisation, agrégats par fenêtre T + N (1 min, 1 h, 24 h).

3. Moteur real-time : règles + ML inference (faible latence), orchestration challenge.

4. Moteur graphique : communications des utilisateurs par appareils, paiements, IP/ASN, cookies, adresses.

5. Entrepôt d'incidents et marquage : formation active des modèles, RCA.

6. Orchestrateur de réponses : bloc/challenge/gel/limite/contrôle manuel.

7. Observabilité/SLO : métriques de qualité (TP/FP/FN), temps de décision, effet sur la conversion.

Signaux et « empreintes »

Client et appareil

Device fingerprint : Dérivations user-agent, plate-forme/CPU/GPU, rendu Canvas/WebGL, polices, timezone, langage, capteurs ; résistance à la rotation.
Haut-parleur du navigateur : événements souris/tache, vitesse/rythme d'entrée, focus/blur, scroll, séquences de transitions, modèles idle.
Métriques mobiles : jailbreak/ruth, signes émulateurs, drapeaux de débage, signaux SDK.
Réseau : IP/ASN/geo, proxy/VPN/hébergement-ASN, fréquence des postes IP, stabilité RTT, empreintes JA3/TLS.

Comportement et contexte commercial

Velocity-metrics (inscriptions/logins/dépôts/taux par fenêtre).
Anomalies des zones temporelles/locales/monnaies, incohérence du dispositif géo.
Modèles répétés de chemins/requêtes, séquences de formulaires (typiques des scripts).
Économie de l'action : incohérence LTV, combinaisons non naturelles promo/conclusions.

Analyse graphique (familles et clusters)

Sommets : utilisateurs, appareils, IP/ASN, outils de paiement, adresses, cookies.
« Il s'est logé », « a payé par », « a partagé l'appareil », « a coïncidé avec le fingerprint ».

• 'K-core ≥ 3 'utilisateurs par instrument de paiement → vérification manuelle.
• Composant de connectivité de taille> X créé en <24 h → congélation promo et KYC-rhubarbe.
• Centralisation élevée sur le nœud IP (indice Gini) dans la zone d'enregistrement → antibot challenge.

Règles (déterministes) et scoring (ML)

Caractéristiques de l'approche hybride

Règles : rapides et compréhensibles (CUS/conformité, bloc de front).
ML : attrape les « zones grises » et les nouveaux modèles ; travaillez en mode shadow avant d'activer les actions.

Règles types (exemple de pseudo-code)

yaml
- id: ATO_LoginBurst when:
path: "/login"
failures_last_10m_by_ip > 20 distinct_accounts_last_10m_by_ip > 5 action: challenge_mfa

- id: Bonus_MultiAccount when:
promo_code = "WELCOME100"
devices_shared_with_accounts >= 2 first_deposit_time_delta < 10m action: freeze_bonus_and_review

- id: Payment_CardTesting when:
card_decline_rate_30m_by_ip > 0. 6 unique_cards_attempted_30m_by_ip > 5 action: block_24h_and_notify

ML-fiches (avec exemples)

Temps : fréquences/intervalles, saisonnalité par heure/jour.
Catégorique : ASN, pays, appareil, navigateur.
Graphiques : node degree, clistering coefficient, pagerank du nœud IP/périphérique.
Technique : longueur de session, entropie des données saisies, rareté des séquences de clics.
Financier : chèque moyen, variance, time-to-withdraw, taux de refus de paiement.

Challenges et réponses (response orchestration)

Soft : JS-challenge, proof-of-work, revalidation e-mail/téléphone, limitation de vitesse/quotas.
Fort : MFA/JIT-KYC, gel temporaire des fonds/bonus, ban temporaire.
Adaptive : augmentation du seuil à haut risque (TOR/ASN hébergement), feuilles de grace pour VIP/partenaires.
Principes UX : vérifications invisibles par défaut ; les défis explicites ne sont qu'à risque.

Antifrod pour promo et gaming

Intégration promo : limites sur les promotions per-device/per-payment-instrument ; lien promo avec le statut KYC.
Multiaccounting : graphes device/IP, similitudes de trajectoires comportementales ; « famille » → limite des récompenses/gel.
Boosting des gains : corrélation anormale des taux entre les comptes liés → enquête.
iGaming KPI : protection de conversion (registratsiya→depozit), Time-to-Wallet ; ne pas « étrangler » les joueurs.

Antifrod de paiement (en résumé)

3-D Secure/multifacteur : dynamique par le risque.
mTLS/signature PSP Webhooks : obligatoire.
Idempotence : clé de l'opération de retrait/dépôt.
Signaux de paiement : BIN/issuer, résultats AVS/CVV, taux de défaillance, non-conformité géographique.

Données, fichestore, fenêtres d'agrégation

Unités en ligne (low-latency) : 1/5/15 minutes pour velocity, unicité, refus.
Temps proche-réel : 1-24 heures pour la promo et la logique bonus.
Fiches hors ligne : 7-90 jours pour la formation des modèles.
Qualité des données : déduplication des événements, protection contre la réémission, schémas de validation.

Observabilité, SLO et métriques de qualité

• p95 décisions (antifrod) ≤ 50 ms sur les voies critiques (login, dépôts).
• Disponibilité du moteur de scoring ≥ 99. 95 %/mois.
• La proportion d'événements « incognito » sans fich ≤ 0. 1%.

• TP/FP/FN sur les scénarios d'ATF/promotions/paiements ; business-cost FP.
• Conversion impact (Δ registratsii→depozit, Δ checkout success).
• Hit-rate challenge (combien de challenges confirment le risque).
• Drift-monitoring (fiches/estimations/latence).

Confidentialité et conformité

Minimisation des données : stocker exactement le nécessaire ; PII - Tokenizer/crypter.
Transparence : explication des décisions (surtout en cas de refus et de restrictions).
GDPR/PCI DSS : segmentation des domaines de données, accès uniquement par rôle ; Loger l'accès et les modifications des règles.
Éthique et bias : audit régulier des fiches/seuils de discrimination.

Opérations et incidents

Runbooks : spike ATO, card-testing, assaut promotionnel, dégradation du SDK.
Feature flags : affaiblissement/renforcement rapide des règles, changement de modèle, challenges « kill-switch ».
Exercices : repli d'attaques historiques, campagnes « grises », dérive soudaine de signes.
RCA/marquage : Marqueurs de borderline et retour en training-datacet (apprentissage actif).

Exemples d'artefacts

1) agrégats SQL pour le scoring (concept)

sql
-- velocity of logins by IP in 10 minutes
SELECT COUNT() AS logins_10m
FROM auth_events
WHERE ip =:ip AND ts > now() - interval '10 minutes';

-- unique accounts by device_id in 24 hours
SELECT COUNT(DISTINCT user_id) AS accounts_24h
FROM sessions
WHERE device_id =:device_id AND ts > now() - interval '24 hours';

2) Règle dans OPA/Rego (simplifié)

rego package antifraud. login

default action:= "allow"

high_risk_ip {
input. ip. asn in {"AS9009, ""AS14061,"" AS16509"} # example input. metrics. failures_10m_by_ip > 20 input. metrics. distinct_accounts_10m_by_ip > 5
}

action:= "challenge_mfa" { high_risk_ip }

3) Pseudo-code d'orchestration challenge

python risk = score(features) # 0..1 if risk >= 0. 9: block()
elif risk >= 0. 7: challenge("MFA")
elif risk >= 0. 5: throttle(rate="low")
else: allow()

Erreurs typiques

Parier uniquement sur le capot : les bots le contournent ; Il faut une pile multifactorielle de signaux.
Longs délais de scoring : déchire l'UX, l'échec augmente.
Bans mondiaux IP/ASN pour toujours : coupe de trafic léger ; utiliser la TTL et la révision.
Pas de comte : les multi-accounts restent « invisibles ».
Règles strictes sans canaries/shadow : sursaut de FP dans la vente.
Cycle fidbek zéro : les modèles ne sont pas réapprises, les règles ne sont pas mises à jour.

Feuille de route pour la mise en œuvre

1. Inventaire des voies à risque : inscription, login, promo, dépôts/conclusions.
2. Collecte de signaux et SDK : Front-JS/mobile, réseau, événements de serveur ; un schéma unique.
3. Fichestor en ligne : fenêtres 1/5/15/60 minutes ; déduplication et SLA fich.
4. Profil de base des règles : velocity + anomalies + heuristiques graphiques simples.
5. ML en mode shadow : comparer le ROC/PR, évaluer l'effet d'entreprise, inclure partiellement.
6. Analyse graphique : regroupement de familles, marquage automatique lors de la confirmation manuelle.
7. Orchestration des réponses : matrice (risk×stsenary→deystviye), contrôle A/B sur UX.
8. Observation et SLO : dashboards de qualité et de technique, alerting, pools de test post-incident.
9. Vie privée/conformité : minimisation des IPI, tokenisation, accès par rôle, reporting.

Total

Un système antifrod fort est un circuit multicouche et adaptatif où les capteurs et le comportement se transforment en fiches, les décisions sont prises par un hybride de règles et de ML, et le graphe de liaison révèle des familles d'abus. Ajoutez l'orchestration des réponses en temps réel, l'observabilité avec SLO et la vie privée - et vous assurerez un équilibre entre la sécurité, l'UX et les métriques d'entreprise, même sous la pression de bots et de réseaux frod bien organisés.