Protéger votre facture IA des abus par IP
Votre site appelle une IA, et chaque requête vous coûte de l'argent. Un script ou un visiteur mal intentionné peut envoyer mille requêtes en cinq minutes : votre facture grimpe pendant que vous dormez. C'est le denial of wallet : on ne casse pas votre site, on vide votre portefeuille.
Cette masterclass vous donne un rate limiter par adresse IP : simple, en mémoire, sans dépendance lourde, taillé pour un site de trafic modéré. Vous posez votre tableau de routes (chemin, limite, fenêtre), et le prompt écrit le middleware complet à partir de lui.
Ce que cet exercice ne peut pas casser
L'exercice se fait sur papier : vous listez des routes et des limites, vous ne touchez pas encore au code. Et quand vous brancherez la protection, le prompt vous donnera la procédure de test pour vérifier qu'elle bloque vraiment, sans rien casser.
Ce que vous saurez faire à la fin
- Poser votre tableau de routes : chemin, limite, fenêtre, et la valeur par défaut pour le reste.
- Brancher un compteur par adresse IP en toute première ligne de route, avant tout appel à l'IA.
- Renvoyer un refus propre au-delà de la limite : délai côté serveur, message calme et compte à rebours côté visiteur.
- Vérifier en production que la protection bloque vraiment au-delà de la limite.
- Niveau membre· le prompt prêt à coller qui écrit votre middleware complet à partir de votre tableau de routes.
- Niveau Pro· je pose la protection avec vous, sur votre vraie API, et on la teste ensemble en production.
Chaque requête passe par le compteur avant de toucher l'IA : deux sorties possibles.
Six pièces, dans cet ordre
Un rate limiter solide n'est pas une bibliothèque de plus : c'est six pièces simples, posées dans le bon ordre. Chacune répond à une faille précise. Sans la vraie adresse, vous bloquez tout le monde ou personne. Sans branchement en tête de route, l'IA a déjà été payée quand le compteur parle. Sans test en production, vous croyez protégé un site qui laisse tout passer.
1Le compteur par adresse IPdoute : « il faut une base de données pour ça ? »
Non : une fonction en mémoire suffit pour un site de trafic modéré. Pour une adresse donnée, une limite et une fenêtre, elle répond trois choses : la requête est-elle autorisée, combien il en reste, et quand le compteur se remet à zéro. Pas de dépendance lourde : la simplicité bat la sophistication quand on est seul.
2Le branchement en toute première lignedoute : « où exactement dans ma route ? »
Avant l'authentification et avant tout appel à l'IA : si le compteur parle après, la requête vous a déjà coûté de l'argent. Et surtout, récupérez la vraie adresse du visiteur depuis l'en-tête transmis par votre proxy (Vercel, Cloudflare), pas l'adresse de la connexion directe : celle-là, c'est celle du proxy, la même pour tout le monde.
3La réponse au-delà de la limitedoute : « je bloque, mais je dis quoi ? »
Côté serveur : un code de statut « trop de requêtes », un délai avant nouvel essai et les en-têtes correspondants. Côté visiteur : un message calme et un compte à rebours qui réactive le champ tout seul à la fin du délai. Un abus se fait bloquer, un humain pressé se sent rassuré.
4Les limites par routedoute : « une seule limite pour tout le site ? »
Non : chaque route a son usage, donc sa limite. Elles se déclinent depuis votre tableau (chemin, limite, fenêtre), plus une valeur par défaut pour toutes les routes que vous n'avez pas listées. C'est votre tableau qui pilote, pas le code.
5Le nettoyage et le journal RGPDdoute : « et la mémoire qui gonfle ? »
Un nettoyage périodique vide le registre en mémoire des adresses inactives. Et le journal des blocages n'enregistre jamais l'adresse complète, seulement son début : vous gardez la trace des abus en restant conforme au RGPD.
6Le test, en production seulementdoute : « pourquoi pas en local ? »
En local, vous n'avez pas de proxy devant vous : la vraie adresse ne se comporte pas comme en ligne, et vous pourriez croire que votre protection marche alors qu'elle laisse tout passer. Le test se fait donc en production : au-delà de la limite, la route doit renvoyer un refus.
À vous de jouer : votre tableau de routes
Prenez une feuille, une ligne par route. Cochez à mesure : c'est ce tableau que le prompt attend.
Le résultat, en 30 secondes
À partir de votre seul tableau et de votre stack, le prompt déroule la protection complète, commentée en français.
Six blocs : le compteur par adresse IP, le branchement en tête de route avec la récupération de la vraie adresse, la réponse au-delà de la limite (côté serveur et côté visiteur, avec le compte à rebours), la table des limites par route, le nettoyage et le journal anonymisé, et les commandes de test à lancer en production avec ce que vous devez voir.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur backend senior, spécialiste des API publiques et de leur protection contre les abus. Tu es rigoureux et prudent : tu ne t'appuies QUE sur ce que je te donne. Ce qui manque, tu me le demandes, tu ne l'inventes jamais. Si un choix technique dépend de ma stack et que je ne te l'ai pas précisée, tu me poses la question au lieu de supposer. # CONTEXTE Je veux protéger mon API contre le denial of wallet : un script ou un visiteur abusif qui envoie trop de requêtes et fait grimper ma facture d'IA. Je veux un rate limiter par adresse IP, simple, sans dépendance lourde, faisable en mémoire pour un site de trafic modéré. Ma stack (si je la connais) : [framework backend, hébergeur, proxy éventuel comme Vercel ou Cloudflare, base de données pour le journal].
Le prompt écrit votre middleware complet à partir de votre tableau : compteur par IP, branchement avant tout appel à l'IA, réponse au-delà de la limite, nettoyage, journal anonymisé et procédure de test en production. Pas encore de tableau ? Il passe en mode interview et vous questionne route par route. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous venez de brancher votre rate limiter. Pour le tester, vous lancez cinquante requêtes rapides en local : aucune n'est bloquée. Que faut-il en conclure ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un confrère qui code son premier rate limiter : pourquoi le test se fait en production et jamais en local ? Si vous savez le dire sans notes, c'est acquis.
Ce que vous savez faire maintenant
- Un compteur par adresse IP en mémoire, sans dépendance lourde.
- Le branchement en tête de route, avant l'authentification et avant l'IA, avec la vraie adresse du visiteur.
- Des limites par route pilotées par votre tableau, avec une valeur par défaut pour le reste.
- Un journal des blocages conforme au RGPD et un test qui se fait en production, jamais en local.
La simplicité bat la sophistication quand on est seul.
Faites-le avec moi
Je pose la protection avec vous, sur votre vraie API : tableau de routes, branchement, et le test en production fait ensemble. Votre facture IA redevient prévisible.