Limitation de taux API : throttling pratique et prévention des abus

Quel problème vous résolvez (en termes simples)

Une API publique, c'est comme une réception qui ne ferme jamais. La plupart des gens arrivent, demandent une chose et repartent. L'abus, c'est quand quelqu'un (ou un code buggy) frappe cette réception tellement souvent que tout le monde se retrouve à attendre.

L'abus n'est rarement une seule chose. Ça peut être du scraping (extraire beaucoup de données rapidement), des tentatives de force brute (deviner mots de passe ou clés API), ou un client incontrôlé qui relance en boucle après une erreur. Parfois ce n'est même pas malveillant : un mauvais déploiement peut transformer une app normale en votre « attaquant » le plus bruyant.

Il est tentant de « juste bloquer », mais des règles brutales punissent les vrais utilisateurs. Beaucoup de clients partagent une adresse IP (bureaux, écoles, cafés). Les réseaux mobiles font tourner les IP. Certains SDK font des retries automatiquement. Si votre règle est trop large, vous bloquez les mauvaises personnes et vous ratez le vrai abuseur.

Les signes avant‑cours apparaissent souvent dans les logs et tableaux de bord : pics de trafic qui ne correspondent pas à l'usage habituel, hausse des erreurs (timeouts, 429, 5xx), réponses plus lentes, mélange d'endpoints étrange (un endpoint de liste appelé des milliers de fois par minute), ou beaucoup d'échecs d'auth et de requêtes « presque valides ».

L'objectif de la limitation de taux est simple : garder l'API disponible et prévisible pour les utilisateurs normaux, même quand le trafic devient chaotique. De bonnes limites ralentissent les mauvais patterns, donnent un feedback clair aux clients légitimes, et vous achètent du temps pour réagir sans tout faire tomber.

Cartez vos surfaces API et les points à risque

Avant de choisir des chiffres, clarifiez ce que vous protégez. La limitation de taux fonctionne mieux quand elle colle à la vraie forme de votre API, pas à une règle globale.

Commencez par lister chaque point d'entrée public qu'un tiers peut toucher, y compris ceux qu'on oublie parce qu'ils « semblent internes » (endpoints mobiles, appels JSON du web, routes partenaires). Puis marquez quels endpoints sont susceptibles d'être abusés et lesquels sont simplement coûteux.

Les zones à haut risque sont souvent prévisibles : login, inscription, refresh de token, réinitialisation et codes de vérification, endpoints de recherche/filtre coûteux, upload de fichiers ou traitement média, et toute action de type admin exposée par erreur.

Ensuite, décidez à qui s'applique une limite :

• Le trafic anonyme a souvent besoin de limites basées sur l'IP, mais les IP sont partagées et peuvent tourner.
• Le trafic authentifié peut utiliser l'ID utilisateur, la clé API, le client OAuth, ou l'ID d'organisation/espace de travail.
• Les produits B2B bénéficient souvent de limites au niveau de l'organisation pour qu'un client ne puisse pas priver les autres.

Pour rester gérable, classez les endpoints par « coût » pour ne pas tout traiter pareil. Par exemple : lectures bon marché, listes normales avec pagination, recherches/exports/uploads/ appels IA coûteux, et flux critiques d'auth/mot de passe.

Puis définissez l'usage raisonnable en termes simples. Vous vous souciez des rafales courtes (100 requêtes en 10 secondes) ou d'un drain soutenu (10 000 par jour) ? Beaucoup de produits ont besoin des deux : une petite rafale pour le chargement de pages, plus un plafond plus long pour empêcher le scraping lent.

Si vous héritez d'une API générée par IA, faites d'abord cette cartographie. Des équipes comme FixMyMess trouvent souvent des endpoints « coûteux » cachés sous des noms innocents, plus des contrôles d'auth manquants qui font de la limitation votre dernier rempart.

Choisissez un modèle de throttling adapté au trafic réel

Une bonne limitation devrait être invisible pour les utilisateurs normaux et très bruyante pour les abuseurs. Cela signifie généralement supporter un comportement en rafales (chargements de page, reconnexions mobiles, retries) sans permettre une extraction soutenue à haut volume.

Les principaux modèles (et quand les utiliser)

Le token bucket est le choix commun « bonne UX ». Chaque utilisateur a un seau qui se remplit avec le temps. Chaque requête dépense un jeton. Si le seau est plein, l'utilisateur peut faire une courte rafale, puis ralentir naturellement quand les jetons s'épuisent.

Leaky bucket est plus strict. Les requêtes entrent dans un entonnoir qui s'écoule à vitesse constante. Il lisse bien les rafales, ce qui peut protéger des backends fragiles, mais il peut sembler dur pour des clients légitimes qui ont un usage en rafales normales (ouvrir plusieurs pages rapidement).

Le fixed window est le plus simple : « 100 requêtes par minute. » Le piège est la frontière. Un client peut faire 100 requêtes à 12:00:59 et 100 autres à 12:01:00, soit 200 requêtes en deux secondes. C'est souvent acceptable pour des endpoints à faible risque ou quand la simplicité vaut plus que l'équité.

En pratique, beaucoup d'équipes standardisent sur un modèle par défaut et gardent une option plus stricte pour les endpoints sensibles :

• Par défaut : token bucket pour la plupart des APIs lecture/écriture
• Plus strict : leaky bucket (ou token bucket avec une très petite rafale) pour les routes coûteuses
• Option simple : fixed window pour les endpoints à faible impact
• Règles séparées pour l'auth, la recherche et les actions en masse

Cela garde la politique simple tout en protégeant les routes réellement ciblées par les attaquants.

Décidez sur quoi vous limitez (et ce qu'il faut éviter)

La limitation n'est juste que si l'identifiant que vous choisissez est pertinent. Choisissez le mauvais « qui » et vous bloquez de bons utilisateurs pendant que les abuseurs passent.

L'option la plus propre est une clé API (ou client OAuth) parce qu'elle correspond à un client réel et n'est pas partagée par accident. Un ID utilisateur connecté est aussi solide, mais peut se compliquer quand une personne ouvre plusieurs sessions ou change d'appareil. Un ID d'organisation permet d'appliquer des limites de forfait, mais peut masquer un utilisateur bruyant dans un gros compte.

Les limites basées sur l'IP fonctionnent avant l'auth, mais elles punissent aussi les innocents car les IP sont partagées (bureaux, écoles, opérateurs mobiles). Si vous dépendez uniquement de l'IP, un utilisateur lourd peut bloquer tout un campus.

Une approche plus sûre est de combiner les signaux pour qu'aucun ne domine :

• Par utilisateur ou par clé API : protège les clients les uns des autres
• Par IP : attrape tôt les inondations et le trafic de bots bon marché
• Par endpoint : limites plus strictes sur les routes coûteuses (login, recherche, exports)
• Par org : applique les limites de plan sans micro‑gérer les individus

Pour le trafic non authentifié, supposez un risque plus élevé. Gardez des plafonds plus stricts, mais donnez aux utilisateurs légitimes un chemin vers plus de confiance : petites rafales autorisées, puis ralentissement, et encouragez l'authentification avant les actions à fort volume.

Exemple : pour un endpoint public search, limitez à la fois par clé API et par IP. Ainsi un scraper qui fait tourner les clés tombe sur un mur IP, et un client réel dans un bureau partagé utilise toujours son budget par clé.

Si vous héritez d'un code généré par IA, vérifiez que les identifiants sont cohérents entre les services. FixMyMess voit souvent des limites liées à des valeurs instables (headers bruts), ce qui rend le throttling aléatoire pour les clients.

Étape par étape : implémenter des limites sans casser les clients

La limitation marche mieux quand elle est prévisible pour les vrais utilisateurs et pénible seulement pour les abuseurs. Vous n'essayez pas de bloquer le trafic ; vous essayez de le modeler.

1) Commencez par des niveaux et des règles simples

Définissez quelques niveaux qui correspondent à l'usage réel : visiteurs anonymes, utilisateurs connectés gratuits, utilisateurs payants, et outils internes. Gardez la première version simple. Vous ajouterez des nuances plus tard.

2) Tarifiez les endpoints par risque (et coût)

Toutes les requêtes ne se valent pas. Faites payer plus les endpoints coûteux ou sensibles que les lectures basiques. Login, réinitialisation, recherche et export sont des aimants pour l'abus.

Une approche pratique est les requêtes pondérées : lectures = 1, login = 5 à 10, exports = 50+, et tout ce qui déclenche de lourds travaux en base de données coûte plus. Cela ralentit le scraping et la force brute sans punir la navigation normale.

3) Renvoyez des 429 clairs et des en‑têtes cohérents

Quand un client atteint la limite, répondez avec HTTP 429 et un message simple expliquant ce qui s'est passé et quoi faire ensuite. Incluez des en‑têtes cohérents pour que les clients s'auto‑corrigent. Si votre stack le permet, envoyez le quota restant, le temps de reset et un Retry-After.

4) Donnez des consignes de retry sûres

Soyez explicite sur quand il est raisonnable de réessayer (rafales courtes) et quand ce n'est pas le cas (plafonds durs ou endpoints comme le login où les retries répétés ressemblent à une attaque). Un mauvais comportement de retry peut transformer un petit pic en incident sérieux.

5) Surveillez, puis ajustez avec des données réelles

Suivez la fréquence des hits aux limites, quels endpoints déclenchent des 429, et quelles identités sont les plus fautives. Si vous corrigez une app générée par IA (prototype avec auth cassée et retries bruyants), vous trouverez souvent des boucles clients accidentelles qui ressemblent à de l'abus. Corriger le comportement client peut réduire la douleur des limites plus que relever les plafonds.

Patterns de protection contre les bots qui n'ennuient pas les vrais utilisateurs

La bonne protection contre les bots consiste moins à construire un mur qu'à ajouter de petits ralentisseurs là où les bots tirent le plus de valeur : inscription, réinitialisation, refresh de token. Les utilisateurs normaux frappent ces routes rarement, donc les contrôles supplémentaires sont moins gênants.

Avant de défier quiconque, enregistrez des signaux qui distinguent la mauvaise automatisation du comportement normal : pics de nouveaux comptes depuis une même plage IP, tentatives de connexion/re‑reset répétées, refresh de token sans usage réel de l'API ensuite, user‑agents inhabituels, ou trafic qui ne touche que des listes/recherches.

Utilisez des challenges progressifs plutôt que des bans instantanés. Commencez par un 429 clair et un court cooldown. Si le pattern continue, ralentissez le client, puis bloquez pour une courte période (minutes, pas jours). Cela réduit le risque de déconnecter un Wi‑Fi de café où plusieurs vrais utilisateurs partagent une IP.

Traitez le credential stuffing différemment des pics généraux. Pour le login, limitez par identifiant de compte plus IP, et appliquez des seuils plus stricts sur les tentatives échouées. Pour le trafic général, gardez les limites plus tolérantes et concentrez‑vous sur les patterns soutenus et répétitifs.

Quotas par utilisateur et règles d'usage équitable

Les limites par minute arrêtent les pics, mais elles ne répondent pas à la question d'équité : qui consomme le plus sur la durée ? Les quotas par utilisateur (ou organisation) plafonnent l'utilisation totale par jour ou par mois pour qu'un client lourd ne prive pas silencieusement les autres.

Commencez avec une unité simple : requêtes par jour, tokens par mois, ou « jobs » par cycle de facturation. Dans les produits d'équipe, les quotas appartiennent généralement à l'organisation avec des sous‑limites par utilisateur optionnelles, afin qu'un coéquipier ne brûle pas toute la réserve.

Les limites souples évitent les ruptures surprises. Un pattern simple : alerter à 80 %, avertir à 95 %, bloquer à 100 %. Même sans système de facturation, ces seuils aident les clients à s'ajuster avant la panne.

Quand quelqu'un dépasse le quota, rendez la réponse évidente et exploitable. Utilisez un statut clair (souvent 429) et incluez l'utilisation actuelle, la limite, le temps de reset, et comment demander une augmentation.

Exemple concret : si une app générée par IA est publiée sans quotas, une clé API fuyante peut générer une semaine d'utilisation en quelques heures. Des équipes comme FixMyMess voient souvent ça après un prototype en ligne. Ajouter des plafonds mensuels au niveau org plus des avertissements précoces arrête généralement les dégâts sans bloquer des clients légitimes qui ont juste besoin d'un plan supérieur ou d'un coup de pouce ponctuel.

Où stocker les limites : choix d'architecture robustes en production

Le lieu d'application des limites compte autant que les chiffres. Une même règle peut être fiable ou inutile selon l'endroit où le compteur vit et comment il est mis à jour.

La plupart des équipes appliquent les limites à l'un de ces endroits :

• En mémoire (par serveur) : rapide et simple, mais foire avec plusieurs instances
• Redis (cache partagé) : un choix par défaut courant, partagé entre instances, supporte des mises à jour atomiques
• Base de données : plus simple à auditer, mais souvent trop lente et coûteuse pour des vérifications par requête
• Passerelle API ou CDN : excellent quand disponible, mais peut être limité pour des clés/custom responses

Si vous hésitez, Redis plus une petite couche applicative est un bon point de départ pour des APIs publiques.

Réalités distribuées et multi‑région

Dans les systèmes distribués, les conditions de concurrence sont un mode de défaillance discret. Deux requêtes peuvent passer la vérification en même temps à moins que votre incrément‑et‑comparaison soit atomique. Utilisez des incréments atomiques (ou un script/une transaction unique) et gardez les clés cohérentes, par exemple userId + route + time window. Des clés inconsistantes créent des failles que les abuseurs trouvent vite.

Le trafic multi‑région force un compromis entre enforcement strict et disponibilité. Des limites globales strictes nécessitent un compteur partagé ou une forte coordination, ce qui ajoute de la latence et peut échouer en mode fermé. Beaucoup d'équipes acceptent des limites « souples » par région (cohérence éventuelle) car cela garde l'API réactive et bloque quand même la plupart des abus.

Évitez d'interroger votre base principale juste pour décider d'autoriser une requête. La limitation doit être une lecture rapide, et votre logique métier ne doit tourner que si la requête est autorisée.

Si vous héritez d'un backend généré par IA (fréquent avec des outils comme Replit ou v0), c'est souvent là que ça casse : les limites sont en processus, reset au déploiement, et échouent dès que vous scalez.

Erreurs courantes et pièges

La plupart des échecs ne sont pas causés par des attaquants sophistiqués. Ils arrivent parce que les limites sont trop simples, trop brutales ou invisibles une fois en production.

Un piège courant est d'avoir une limite globale unique et de s'en tenir là. C'est rassurant, mais ça pénalise vos meilleurs clients (power users, partenaires) et vos outils internes. Séparez les classes de trafic (public, authentifié, partenaire, interne) et donnez‑leur des plafonds différents.

Un autre piège est de compter uniquement sur l'IP. Les IP sont partagées et tournent. Si vous bloquez par IP seule, vous bloquerez des innocents et vous manquerez des bots distribués.

Surveillez les retry storms. Un client reçoit un 429, réessaye immédiatement, reçoit encore un 429, et multiplie le trafic au pire moment. Votre réponse 429 doit encourager le backoff.

Vérifiez aussi l'auto‑throttling : votre frontend appelle l'API lors d'un lancement pendant que des jobs en arrière‑plan l'appellent pour synchroniser des données. Si les deux partagent la même clé ou token, ils peuvent se throttler mutuellement et créer des échecs aléatoires.

Ne restez pas aveugle. Si vous ne voyez pas quels utilisateurs, clés, plages d'IP ou endpoints déclenchent les throttles, vous ne pouvez pas affiner les règles avant que les clients se plaignent.

Checklist rapide avant mise en production

Avant d'activer les limites pour tout le monde, passez vite sur les endroits qui causent habituellement des problèmes :

• Séparez le trafic en au moins deux buckets : anonyme (risque plus élevé) et connecté (plus identifiable).
• Rendre les endpoints sensibles plus stricts que les lectures normales : flux d'auth, réinitialisation, refresh de token, signup, et recherches/rapports/exports coûteux.
• Rendre les réponses 429 claires : langage simple + Retry-After pour que les clients bien conçus reculent.
• Ajouter de la supervision avant le lancement : principaux fautifs (clé/IP/utilisateur) et endpoints les plus bloqués.
• Prévoir des exceptions : le support doit avoir un moyen sûr et temporaire de contournement avec logging.

Scénario d'exemple : stopper le scraping sans bloquer les clients réels

Vous avez un endpoint public de recherche comme GET /search?q=.... Ça marche jusqu'à ce qu'un scraper commence à parcourir toutes les combinaisons de mots‑clés et filtres toute la journée. Les clients réels utilisent toujours le service, mais votre API passe son temps à répondre aux requêtes automatisées. La latence augmente, et votre facture DB aussi.

Une politique qui marche souvent combine contrôle de rafale (pour attraper les pics), un plafond soutenu (pour l'équité), et un coût plus élevé pour les endpoints faciles à abuser.

Un réglage pratique :

• Rafale par IP : 30 requêtes par 10 secondes par IP, puis 429 pour un court cooldown
• Plafond par utilisateur : 120 requêtes par minute par utilisateur authentifié (cléée sur l'ID utilisateur, pas l'IP)
• Garde pour pagination de recherche : limitez la profondeur (par ex. pas plus de page 20) sauf pour les utilisateurs vérifiés
• Coût d'export : traiter POST /export comme 10× le coût d'une recherche normale
• Utilisateurs anonymes : limites plus basses et imposez un petit délai après plusieurs 429 répétés

Les utilisateurs normaux remarquent rarement. Ils cherchent, cliquent et rafraîchissent peut‑être une fois. Le scraper atteint vite le plafond de rafale, puis tombe sur des caps soutenus s'il continue.

La première semaine, surveillez si les limites pénalisent plus les vrais utilisateurs qu'elles ne ralentissent les bots. Suivez les faux positifs (qui a reçu des 429 et où), la latence (p95 avant/après), les changements de 401/403/429 et les 5xx en aval, les tickets support depuis des réseaux partagés, et les récidivistes dans le temps.

Si c'est sur un backend hérité généré par IA, prudence : une auth bordélique et des ID utilisateur incohérents rendent les quotas par utilisateur peu fiables. Corrigez l'identité et le logging d'abord, puis durcissez les limites.

Étapes suivantes et quand demander de l'aide

Commencez par les chemins à plus haut risque et coût : flux d'auth (login, reset, refresh) et endpoints coûteux (recherche, exports, appels IA, rapports). Déployez les changements par petites étapes pour ne pas surprendre les clients réels. Mesurez ce que signifie « normal », puis durcissez progressivement.

Un ordre de déploiement sûr :

• Logs seulement : enregistrez les blocs potentiels sans bloquer
• Limites souples : renvoyez des avertissements ou ajoutez des délais pour les gros consommateurs
• Application : renvoyez des 429 clairs avec fenêtres de retry cohérentes
• Ajustement : augmenter les limites pour les clients fiables, les baisser pour les automatisations évidentes

Rédigez les règles en langage simple : quoi est limité, la fenêtre (par seconde/minute/jour), ce qui se passe quand la limite est atteinte, et comment demander plus de quota.

Faites appel à de l'aide quand les limites sont faciles à contourner, des utilisateurs légitimes sont bloqués sans explication évidente dans les logs, l'auth et les clés sont en désordre (tokens partagés, IDs manquants), ou vous suspectez des problèmes de sécurité plus larges (secrets exposés, injections, contrôles d'accès brisés).

Si votre API a commencé comme prototype généré par IA et que le throttling ou l'auth semble instable, une remédiation ciblée est souvent plus rapide qu'une suite de rustines. FixMyMess (fixmymess.ai) peut réaliser un audit gratuit, puis aider à réparer la limitation de taux, l'authentification et le durcissement de sécurité pour rendre le projet prêt pour la production, typiquement en 48–72 heures.