Stripe Radar excelle dans ce qu'il fait : noter une transaction au moment précis où l'argent circule. Mais le moment où l'argent ne circule pas est exactement là où se logeait notre problème.
Nous proposons un essai gratuit de 7 jours. Pour le démarrer, un utilisateur enregistre une carte mais n'est jamais débité — en coulisses, il s'agit d'un SetupIntent Stripe, pas d'un paiement. Pas de débit signifie pas d'événement au moment du débit, ce qui signifie que les règles les plus puissantes de Radar n'ont rien à évaluer au moment qui compte le plus : lorsqu'un compte frauduleux est en train d'être créé et commence à consommer des crédits d'essai.
Voici l'histoire de la façon dont nous sommes passés de la lutte contre la fraude au cas par cas dans des conversations à l'exploitation d'une couche anti-fraude automatisée, minute par minute — construite sur notre propre produit, Zero.
Radar est excellent. « Excellent » n'est pas « parfait ».
Stripe Radar est réellement bon dans ce qu'il fait. Entraînés sur plus de 1 000 milliards de dollars de volume de paiement annuel, ses modèles reconnaissent une carte déjà vue 92 % du temps, et Stripe rapporte que Radar réduit la fraude de 32 % en moyenne pour les entreprises qui l'utilisent.
Relisez ce chiffre, toutefois : il réduit, il n'élimine pas. Une baisse moyenne de 32 % est importante — mais elle signifie qu'une large part de la pression frauduleuse arrive toujours à votre porte, et Stripe est d'une honnêteté rafraîchissante sur le pourquoi. Selon leurs propres termes, « réduire le nombre de faux positifs augmente souvent la probabilité que davantage de fraude réelle passe entre les mailles du filet. » La fuite n'est pas un défaut du modèle ; c'est le coût délibéré de ne pas bloquer vos vrais clients. Chaque équipe anti-fraude choisit, volontairement, la quantité de fraude à laisser passer.
Pour un produit porté par l'essai, cette fuite est plus large que ne le suggère le chiffre annoncé — parce que la partie la plus puissante de Radar ne s'exécute même jamais.
Pourquoi une barrière ne peut que réduire
Il y a une raison plus profonde pour laquelle un moteur agissant au moment du débit peut réduire la fraude sans jamais y mettre fin, et elle ne tient pas aux modèles de Stripe — elle tient au timing et à l'information. À l'instant où une carte est ajoutée, le client n'a encore rien fait. Pas d'historique de connexion, pas de comportement produit, pas de schéma d'usage dont apprendre — juste une carte et une poignée de signaux réseau. Radar prend sa meilleure décision sur la tranche de preuves la plus mince possible, au seul moment où il a le moins d'éléments.
C'est là le vrai plafond. On peut régler une barrière, mais on ne peut pas lui donner des données qui n'existent pas encore. L'information qui distingue réellement un fraudeur d'un client est en grande partie créée après que la barrière a déjà dû décider.
Étape 1 : la lutte contre l'incendie dans la fenêtre de chat
Notre première réponse était entièrement manuelle. Quand une vague d'abus frappait, quelqu'un ouvrait une conversation avec notre agent et traitait l'incident en direct : récupérer les inscriptions récentes, examiner les cartes, trouver le schéma, fermer les comptes à la main.
Ça marchait, mais ça ne passait pas à l'échelle. Chaque incident repartait de zéro. Le savoir — à quoi ressemble ce réseau, quels signaux sont fiables — vivait dans la tête d'une seule personne et dans un seul fil de discussion, et s'évaporait dès la fenêtre fermée.
Nous avons aussi appris une leçon coûteuse du bon côté de l'entonnoir : lorsque nous avons voulu reconquérir de vrais utilisateurs ayant abandonné le paiement, un e-mail de relance négligent envoyé à une adresse frauduleuse cause de réels dégâts — il confirme que l'adresse est active. Toute automatisation que nous construirions devrait faire la différence entre un vrai prospect et un leurre.
Étape 2 : renforcer la porte d'entrée avec Radar
Notre coup suivant a été de pousser tout ce que nous pouvions en amont dans Radar — listes de blocage et règles de vélocité à l'étape de l'ajout de carte, ajustées à la pression que nous observions. C'est le bon premier coup, et il a stoppé les attaques les plus grossières.
Mais deux plafonds sont apparus vite. Le premier est celui que Stripe nomme lui-même : un moteur agissant au moment du débit est un curseur de compromis, pas un mur — montez-le et vous bloquez de vrais clients, baissez-le et davantage de fraude passe. Le second est structurel et propre aux essais : ces 32 % sont gagnés au moment du débit, et un essai en SetupIntent n'a aucun débit à noter. À moins d'activer explicitement Radar sur les moyens de paiement enregistrés, le moteur ne s'exécute pas du tout — et même quand il le fait, seules les règles Block, Allow et 3DS s'appliquent sur un SetupIntent. L'action « Review », celle qui offre à un humain un second regard, ne se déclenche jamais.
Ainsi, la couche la plus performante de la pile reste, par défaut, sur la touche au moment précis où nous en avions le plus besoin. Radar est une barrière à la porte d'entrée. Il nous fallait une patrouille derrière elle.
Étape 3 : une seconde couche, construite sur Zero
Après l'inscription, le tableau de l'information s'inverse. Le compte commence à laisser une trace — et la partie la plus riche de cette trace vit dans un système que le processeur de paiement ne voit jamais : notre fournisseur d'identité, Clerk.
Nous y avons donc donné accès à Zero. Clerk sait des choses que Stripe ignore : comment le compte a été créé, la méthode d'inscription et l'e-mail, la session et l'appareil derrière, et le timing précis par rapport à toutes les autres inscriptions de la journée. Stripe connaît la carte. Aucun système, à lui seul, ne raconte toute l'histoire — mais l'agent peut lire les deux et les corréler. L'abus invisible à la barrière devient évident côte à côte : un compte tout neuf dont l'identité de connexion ne correspond pas à son identité de facturation, créé à quelques instants d'une grappe de sosies. Ce rapprochement inter-systèmes est exactement ce qu'une barrière au moment du débit ne peut pas faire — et exactement ce qu'un agent posé au-dessus des deux systèmes peut faire.
Sur cette base de preuves plus riche, nous exécutons un ensemble de tâches Zero planifiées toutes les quelques minutes sur les données d'inscription et de facturation en direct. Trois principes les façonnent :
1. Patrouiller, pas seulement filtrer. Au lieu d'évaluer un seul moment, l'agent balaie chaque inscription récente en boucle courte, corrélant les données de compte et les métadonnées de paiement pour faire remonter les comptes passés par la porte d'entrée.
2. Graduer la réponse selon la confiance. Tous les signaux ne méritent pas la même action. Les schémas à haute confiance sont traités automatiquement — le compte est suspendu et son essai annulé sur-le-champ, parce que l'action est réversible et que le coût de l'attente est réel. Les signaux à plus faible confiance ne déclenchent jamais d'action automatique ; ils sont rassemblés dans un rapport pour examen humain. Décisif là où c'est sûr, prudent là où ça ne l'est pas.
3. Conserver une piste d'audit humaine. Chaque action automatique enregistre le signal exact qui l'a déclenchée, pour qu'elle puisse être examinée — et annulée — en quelques secondes. Une automatisation que l'on ne peut pas auditer est une automatisation à laquelle on ne peut pas se fier.
Nous avons appliqué la même rigueur au côté amical de l'entonnoir. Une tâche distincte trouve les véritables utilisateurs ayant abandonné le paiement et rédige un e-mail de reconquête qu'un humain approuve — derrière un filtre anti-fraude délibérément lourd, pour ne jamais valider une mauvaise adresse. Même moteur, objectif opposé.
Ce que cela a changé pour l'économie
Une fois la patrouille en place, les chiffres ont bougé immédiatement. Regardez l'inscription au 90e centile — les comptes lourds qui causaient les vrais dégâts. Le calcul d'essai que l'un d'eux consommait dans ses premières heures est passé d'environ 4 $ à environ 0,25 $ — une baisse de 94 %. En moyenne sur chaque nouvelle inscription sur la même fenêtre, la perte par compte a chuté d'environ 85 %.
La forme du changement est révélatrice. La plupart des inscriptions ne nous coûtaient jamais rien ; la perte était toujours concentrée dans une longue queue lourde de comptes qui n'existaient que pour drainer des crédits d'essai. La patrouille n'a pas rétréci l'entonnoir — elle a coupé cette queue. Pas moins d'inscriptions. Des inscriptions plus propres.
Pourquoi un agent, et pas un script
Nous aurions pu écrire une tâche cron. Nous ne l'avons pas fait, pour une raison : la menace évolue plus vite qu'un cycle de release. Quand un attaquant change de tactique, nous mettons à jour les instructions d'une tâche en langage clair et la nouvelle logique est en place dès l'exécution suivante — pas de déploiement, pas de migration de schéma, pas de ticket. Les « règles » sont un prompt, et le prompt est aussi rapide à changer que l'attaquant l'est.
C'est là la vraie leçon. Radar est le bon outil pour le risque au moment du débit, et nous nous appuyons fortement dessus. Mais une entreprise portée par l'essai a un angle mort structurel qu'aucun outil agissant au moment du débit ne peut couvrir — et le remède n'est pas un moteur de règles plus gros. C'est une seconde couche rapide, auditable et toujours active, que vous pouvez reprogrammer à la vitesse de la menace.
À retenir pour les équipes portées par l'essai
- Cartographiez vos moments sans débit. Partout où un utilisateur obtient de la valeur avant qu'un paiement soit noté, il y a une faille qu'un outil agissant au moment du débit ne peut pas voir.
- Superposez, ne remplacez pas. Gardez Radar à la porte d'entrée. Ajoutez derrière une patrouille post-inscription continue.
- Rapprochez à travers les systèmes. Votre processeur de paiement et votre fournisseur d'identité détiennent chacun la moitié du tableau. La fraude est visible dans le recoupement.
- Graduez vos actions selon la confiance, et journalisez-les toutes. N'agissez automatiquement que là où l'action est réversible et le signal fort ; acheminez le reste vers un humain.
- Optimisez pour la vitesse d'adaptation. En matière de fraude, l'équipe qui peut changer ses règles le plus vite gagne.
Curieux de savoir ce qu'un agent toujours actif pourrait automatiser dans votre propre stack ? Découvrez Zero.
Notes : les chiffres de Radar sont les données publiées par Stripe (stripe.com/radar ; « A primer on machine learning for fraud detection »). Les chiffres de perte reflètent le coût de calcul par nouvelle inscription dans les premières heures suivant l'enregistrement, mesuré sur des fenêtres comparables avant et après le lancement, comptes internes exclus ; l'échantillon post-lancement est encore récent et se consolidera avec le temps.