Un essai gratuit est un pari : vous offrez quelques jours de votre produit en espérant que les bonnes personnes restent. L'abus d'essais gratuits, c'est quand la même personne, ou le même script, rejoue le pari encore et encore. Un nouvel email, un nouveau compte, 14 jours de plus ou un nouveau lot de crédits gratuits. Le marché parle de multi-accounting ou d'abus de promotions (promo abuse) ; pour vous, c'est un coût qui grandit à chaque nouveau compte et ne rapporte jamais.
Comment fonctionne l'abus d'essais gratuits
- À la main. Une personne se réinscrit avec une autre adresse à la fin de l'essai. Les alias d'email (
nom+1@) et les boîtes jetables rendent la chose instantanée. - Avec un script. Un bot d'inscription crée des comptes en série, chacun pour récupérer des crédits gratuits, un quota d'API ou des tokens d'IA, souvent pour les revendre.
- Avec une ferme. Navigateurs anti-detect et proxies résidentiels donnent à chaque compte un fingerprint et une adresse IP neufs, si bien que les comptes semblent sans lien au premier regard.
Le premier cas est une gêne. Le deuxième et le troisième sont ceux où l'argent part, et où un produit qui offre du calcul, du stockage ou des appels de modèle perd le plus.
Ce qui trahit le multi-accounting
Un fraudeur peut changer d'email, d'adresse IP et de fingerprint. Ce qui est difficile, c'est de changer tout le reste, pour chaque compte, en même temps et de façon cohérente :
- Un appareil, beaucoup de comptes. Le même navigateur derrière plusieurs réseaux, ou un token de session utilisé depuis plusieurs endroits.
- Un fingerprint, beaucoup de sessions. Un navigateur anti-detect qui réutilise un profil apparaît sur de nombreuses sessions et de nombreux sous-réseaux.
- Des sessions neuves à la chaîne. Dix nouvelles sessions depuis un même sous-réseau et un même User-Agent en quelques minutes, ce n'est pas un foyer.
- La façon dont le formulaire a été rempli. Les gens bougent une souris ou touchent l'écran et tapent touche après touche ; les scripts collent le texte et cliquent sans bouger.
- Un navigateur qui se contredit. Un User-Agent qui annonce un système pendant que le navigateur en signale un autre.
Aucun de ces signaux n'est une preuve à lui seul, et un VPN seul ne l'est jamais. Ensemble, sur une fenêtre de quelques minutes, ils dessinent une ferme.
Vérifier à l'inscription, agir sur la récompense
Demandez une décision sur votre serveur, avant de créer le compte, avec l'IP du visiteur, le User-Agent et le token que le tag a laissé dans le navigateur. Décidez ensuite de ce que reçoit le compte, pas seulement s'il existe :
- bot high : refusez l'inscription.
- bot : créez le compte sans les crédits gratuits ; accordez-les une fois l'email vérifié, une carte enregistrée ou un numéro de téléphone confirmé.
- unknown, human, human high : l'essai complet, comme d'habitude.
Retenir la récompense plutôt que bloquer le formulaire garde bas le coût d'une erreur : un vrai prospect à la configuration inhabituelle entre quand même et attend seulement ses crédits. Un script qui ne peut pas les encaisser n'a aucune raison de revenir.
Boucler la boucle
Quand un compte devient un client payant, dites-le à Bot Protection par un feedback ; quand un compte se révèle frauduleux, dites-le aussi. Les visites suivantes d'un bon client gagnent la confiance ; un appareil lié à un abus, non. Et enregistrez la classe avec chaque nouveau compte, pour que la conversion de votre essai soit mesurée sur des personnes, pas sur des scripts.
Rester fail-open
La vérification se trouve dans votre inscription, elle ne doit donc jamais faire tomber l'inscription. Utilisez un timeout court et laissez passer le visiteur à la moindre erreur : quelques essais en trop pendant une panne coûtent moins cher qu'une page d'inscription qui ne marche plus. Plus de détails dans pourquoi une vérification anti-bots doit être fail-open.