Guides

Comment stopper l'abus de crédits gratuits sur une app d'IA

Les crédits gratuits d'un produit d'IA coûtent une vraie inférence. Comment fonctionnent les fermes de crédits, pourquoi les limites par compte ne les arrêtent pas et à quel moment de l'inscription décider.

8 min de lecture · Mis à jour le 2026-10-31 · Attrelix

Pourquoi les crédits gratuits d'un produit d'IA sont différents

Sur la plupart des SaaS, un faux compte coûte une ligne en base et un peu de bruit dans les statistiques. Sur un produit d'IA, chaque compte gratuit peut dépenser de l'argent réel : chaque prompt exécute une inférence sur des GPU que vous payez. Les crédits gratuits sont en fait de l'argent, et tout ce qui se convertit en argent attire l'automatisation.

Cela change qui abuse de l'offre gratuite. En plus des personnes qui veulent simplement plus d'usage gratuit, vous avez des fermes de crédits : des scripts qui créent de nombreux comptes, récupèrent les crédits gratuits de chacun, puis revendent l'accès ou s'en servent pour faire tourner leurs propres charges via votre API.

Comment fonctionne une ferme de crédits

Les détails varient, mais la forme est constante :

  1. Les comptes sont créés par un script, généralement un navigateur headless piloté par Puppeteer, Playwright ou Selenium, parfois un navigateur anti-détection qui randomise son empreinte.
  2. Les boîtes sont jetables : domaines jetables, domaines catch-all appartenant au fermier, ou un compte Gmail écrit de dizaines de façons avec des points et des plus.
  3. Le trafic vient de serveurs : le cloud et l'hébergement sont bon marché, donc beaucoup de fermes y tournent, parfois derrière des proxys ou Tor.
  4. Les crédits sont vidés vite, souvent dans les premières minutes, avant qu'une alerte d'usage ait le temps de réagir.

Pourquoi les limites par compte n'aident pas

Les limites de débit vous protègent d'un compte qui consomme trop. Une ferme ne fait jamais ça : chaque compte reste sagement dans son quota gratuit. L'abus est dans le nombre de comptes, donc la défense doit intervenir à l'inscription, avant l'attribution des crédits — pas plus tard, au niveau de l'usage.

La bonne question n'est pas « cette requête est-elle abusive ? » mais « ce nouveau compte doit-il recevoir des crédits gratuits, et combien ? ».

Les signaux qui trahissent une ferme à l'inscription

Automatisation

Les navigateurs pilotés par automatisation laissent des traces : navigator.webdriver à true, un user agent HeadlessChrome, un client du protocole DevTools attaché, un rendu WebGL logiciel, une fenêtre de taille nulle. Un opérateur soigneux peut corriger chacune, c'est pourquoi elles fonctionnent mieux combinées. Notre guide pour détecter les navigateurs headless les passe en revue une à une.

Réseau

Les vrais utilisateurs s'inscrivent depuis des réseaux domestiques et mobiles. Les inscriptions depuis des plages cloud (AWS, Google Cloud, Oracle, DigitalOcean, Linode) et des sorties Tor méritent plus d'attention, tout comme une adresse ou un sous-réseau qui a créé beaucoup de comptes aujourd'hui.

Boîte e-mail

Domaines jetables, domaines qui ne reçoivent pas de courrier et alias Gmail d'un compte existant. Voir Points et alias + de Gmail.

Liens entre comptes

Le signal le plus fort d'une ferme, c'est que ses comptes vont ensemble : même appareil, même boîte normalisée, même empreinte de carte. Un compte lié est un indice faible ; dix, c'est une ferme.

Où placer la vérification

Appelez votre vérification anti-fraude côté serveur après l'envoi du formulaire d'inscription et avant de créditer le compte. Si les crédits sont attribués par une tâche en arrière-plan ou à la confirmation de l'e-mail, placez la vérification juste avant cette étape. L'important est que la décision existe avant les crédits.

// Node.js, avant d'attribuer des crédits gratuits
const res = await fetch("https://attrelix.com/v1/check", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.ATTRELIX_SECRET}`, "Content-Type": "application/json" },
  body: JSON.stringify({ email, ip, visitor: req.body.attrelix_visitor }),
  signal: AbortSignal.timeout(3000),
}).catch(() => null);
const decision = res?.ok ? (await res.json()).decision : "allow";

const credits = { allow: 100, review: 10, block: 0 }[decision] ?? 100;
await grantCredits(user.id, credits);

Des crédits gradués plutôt que des blocages nets

Un schéma qui marche bien pour les produits d'IA consiste à moduler les crédits gratuits selon le risque au lieu de choisir entre tout ou rien :

  • Autoriser : le quota gratuit complet.
  • Examiner : un petit quota — assez pour essayer le produit — et le reste après une carte, un téléphone ou un e-mail vérifié.
  • Bloquer : pas de crédits gratuits ; proposez l'offre payante.

Les utilisateurs honnêtes qui tombent en examen peuvent toujours essayer le produit, et une ferme qui reçoit un dixième des crédits par compte perd l'essentiel de sa rentabilité.

Sachez ce que cela vous coûte

Chiffrez le problème : multipliez la valeur des crédits gratuits qu'un nouveau compte reçoit par le nombre de comptes que votre vérification aurait envoyés en examen ou bloqués. C'est le coût mensuel de l'inaction, et cela vous dit combien de friction il vaut la peine d'ajouter. Le tableau de bord d'Attrelix fait ce calcul à partir de la valeur de vos crédits.

En résumé

  • Les fermes de crédits restent dans les limites par compte ; arrêtez-les à l'inscription.
  • Combinez signaux d'automatisation, de réseau, de boîte e-mail et de liens entre comptes.
  • Décidez avant que les crédits n'existent, et laissez passer si la vérification est indisponible.
  • Modulez les crédits selon le risque plutôt que de bloquer d'emblée.

Plus de guides