Traditionnellement, la lutte contre la fraude dans les produits digitaux était basée sur des règles strictes ou une modération manuelle, ce qui entraînait une forte charge opérationnelle et une rigidité du système. Avec le développement de l'apprentissage automatique, les entreprises ont commencé à mettre en œuvre des SDK de détection de fraude en temps réel, qui score chaque transaction selon la probabilité de fraude. La difficulté clé est que tout classificateur commet deux types d'erreurs : Faux Positif (blocage d'un utilisateur légitime) réduit directement le revenu, tandis que Faux Négatif (passage d'une fraude) augmente les rétrofacturations. Il est crucial pour les entreprises de mesurer le trade-off entre ces erreurs afin d'optimiser les seuils de score.
Les tests A/B standard sont impossibles, car le passage intentionnel de transactions frauduleuses dans le groupe de contrôle n'est pas acceptable d'un point de vue réputationnel et des exigences FinCEN/PCI-DSS. La simple comparaison des métriques avant et après l'implémentation est biaisée par la saisonnalité des attaques frauduleuses et le auto-sélection des utilisateurs (les plus loyaux mettent à jour l'application). Les utilisateurs à haut risque de fraude ont une conversion initialement différente de celle des utilisateurs à faible risque, donc la comparaison naïve entre les transactions approuvées et refusées donne une évaluation biaisée à cause du biais d'indication.
La méthode optimale est le Sharp Regression Discontinuity Design (RDD) autour du seuil de score de fraude (par exemple, 0,7), où il y a un changement abrupt dans la probabilité d'approbation de 1 à 0. Nous comparons les transactions avec un score de 0,69 (traitement, approuvé) et 0,71 (contrôle, refusé), en supposant une randomisation locale dans la fenêtre de bande passante (±0,05). Nous utilisons Local Linear Regression avec un noyau triangulaire pour évaluer le LATE (Effet de traitement moyen local). Pour améliorer la précision, nous appliquons Covariate-Adjusted RDD, ajoutant des prédicteurs (historique de l'appareil, géo) en tant que variables de contrôle. Pour évaluer le revenu net, nous calculons le Revenu Incrémental : la différence entre la fraude empêchée (rétrofacturation attendue) et le revenu perdu en raison des faux positifs, identifiés via RDD.
Dans une application mobile de marketplace, après intégration du SDK de détection de fraude d'un fournisseur externe, la conversion totale des achats est passée de 4,2 % à 3,5 %, tandis que le taux de fraude est tombé de 2,8 % à 0,4 %. L'équipe produit soupçonnait que le système était trop agressif et coupait des utilisateurs légitimes solvables, mais ne pouvait pas évaluer quantitativement l'ampleur du problème en raison de l'absence d'un groupe de contrôle.
Option A : Comparaison simple de la conversion avant et après l'implémentation (analyse pré-post). Avantages : charges de travail minimales, ne nécessite pas d'infrastructure spéciale. Inconvénients : ignore totalement la saisonnalité (la période après l'implémentation a coïncidé avec le début de la basse saison), auto-sélection lors de la mise à jour de l'application et changement du mix marketing (un nouveau canal avec une faible conversion a été lancé).
Option B : Répartition géographique (villes Groupe A avec système activé, Groupe B sans). Avantages : crée un vrai groupe de contrôle. Inconvénients : techniquement impossible en raison d'une base de code unique et du caching CDN ; les utilisateurs migrent entre les villes ; le profil de fraude varie considérablement entre les régions (hétérogénéité horizontale).
Option C : Regression Discontinuity Design autour du score de fraude continu au seuil de coupure de 0,65. Avantages : utilise une expérience naturelle, garantit une randomisation locale, permet d'isoler l'effet causal spécifiquement pour les transactions « seuils ». Inconvénients : nécessite un grand volume de données dans la fenêtre du seuil ; évalue le LATE, qui peut différer de l'ATE pour la population entière ; sensible à la manipulation du score (les fraudeurs peuvent apprendre à contourner le seuil).
Option D : Méthode de contrôle synthétique, création d'une combinaison pondérée de cohortes historiques pour simuler un groupe de contrôle. Avantages : fonctionne sans groupe de contrôle physique, prend en compte les tendances temporelles. Inconvénients : suppose que les facteurs d'influence sont stables dans le temps ; sensible aux anomalies dans le prétraitement ; difficile à valider autrement que par des tests de placebo.
L'Option C (RDD) avec une bande passante de 0,08 et un polynôme de premier degré a été choisie. L'analyse a montré que pour les transactions supérieures à 15 000 ₽, le taux de faux positifs est deux fois plus élevé que pour les petits achats. Sur cette base, des seuils dynamiques ont été configurés par catégorie de produits.
Résultat : Il a été possible d'évaluer quantitativement que 0,6 points de pourcentage des 0,7 de perte de conversion étaient dus aux faux positifs. Après calibration des seuils, 45% des revenus perdus (≈18 millions ₽ par mois) ont été restaurés tout en conservant 90% d'efficacité contre la fraude.
Comment distinguer l'effet causal du biais de sélection, lorsque les utilisateurs avec un score de fraude élevé ont initialement une propension d'achat plus faible, même en l'absence de systèmes de fraude ?
Réponse : C'est le problème classique du biais d'indication, lorsque l'indication pour le traitement (risque élevé) corrèle avec le résultat. Dans le RDD, il est crucial de vérifier le balance des covariables dans la fenêtre de bande passante : comparer la distribution de l'âge de l'appareil, des historiques d'achats, géo entre les groupes légèrement en dessous et au-dessus du seuil. Si un déséquilibre est observé, il est nécessaire d'appliquer un RDD corrigé pour le biais en incluant des covariables dans la régression ou d'utiliser l'approche de Randomisation Locale, testant formellement l'hypothèse de la randomisation de la distribution. Sans cette vérification, l'évaluation de l'effet sera mélangée avec les différences préexistantes entre les utilisateurs à haut risque et à faible risque.
Pourquoi une simple comparaison des taux d'approbation entre les utilisateurs ayant traversé différentes versions du modèle (v1 et v2) ne permet-elle pas d'évaluer correctement l'effet d'amélioration de l'algorithme ?
Réponse : Cette comparaison souffre de biais de sélection sur des éléments non observables et de dérive compositionnelle. Le nouveau modèle v2 peut être appliqué de manière sélective (par exemple, uniquement à de nouveaux utilisateurs ou dans des régions pilotes), créant des groupes non comparables. De plus, l'amélioration de la qualité du score modifie la composition des utilisateurs approuvés : v2 peut approuver une « zone grise » que v1 a rejetée, mais ces utilisateurs ont une conversion différente. Pour une évaluation correcte, il est nécessaire d'utiliser l'évaluation des politiques hors ligne avec Inverse Propensity Weighting (IPW) ou estimation doublement robuste sur des logs historiques, en évaluant contre-factuellement quel revenu aurait généré v1 sur les mêmes transactions que v2.
Comment tenir compte du problème de feedback retardé, lorsque la fraude est confirmée après 30 jours (rétrofacturation), alors que les analystes ont besoin d'une évaluation de l'effet en 7 jours pour des décisions opérationnelles ?
Réponse : Cela crée un problème de données censurées et d'asymétrie d'évaluation. Pour les transactions des 30 derniers jours, nous ne connaissons pas le label réel (fraude/non fraude). La solution consiste à utiliser l'Analyse de survie (modèle de risques proportionnels de Cox) pour évaluer le temps jusqu'à la fraude, permettant de travailler avec des données incomplètes. Alternativement, nous pouvons utiliser des Métriques de substitution (par exemple, caractéristiques de vitesse, changement de l'empreinte de l'appareil pendant la session), corrélées avec la fraude future, comme proxy. Il est important de comprendre que les faux positifs sont visibles immédiatement (refus immédiat), tandis que les faux négatifs se manifestent avec un retard, ce qui fausse la précision à la hausse sur un court terme. Pour le RDD, il est recommandé d'utiliser des données "gelées" avec un retard de 30 jours ou plus, acceptant la perte de fraîcheur pour la correction de l'inférence causale.