Limiter le débit des APIs publiques pour arrêter les abus sans bloquer les vrais utilisateurs : limites pratiques, quotas par clé, flux de verrouillage et conseils de déploiement.
La limitation de taux pour les APIs publiques ne sert pas à punir les utilisateurs. C'est une soupape de sécurité qui maintient votre service disponible quand le trafic devient étrange, que cette « étrangeté » soit malveillante ou simplement liée à un bug client.
L’« abus » ressemble souvent à du trafic normal au départ : un scraper qui parcourt chaque endpoint pour copier des données, des tentatives de brute-force sur des connexions, du stuffing de tokens contre des routes d'auth, ou un client défaillant qui relance la même requête en boucle après un timeout. Parfois, personne ne vous attaque vraiment : une mise à jour d'application mobile embarque une mauvaise règle de cache et soudain chaque appareil interroge votre API chaque seconde.
Le but est simple : protéger la disponibilité et maîtriser les coûts sans bloquer les vrais utilisateurs qui font un travail normal. Si votre backend est facturé (compute, base de données, envoi d'e-mails/SMS, appels AI), un acteur bruyant peut rapidement faire grimper la facture.
La limitation seule ne suffit pas non plus. Sans supervision et réponses d'erreur claires, vous obtenez des échecs silencieux, des clients confus et des tickets support qui ressemblent à « votre API est en panne » alors qu'elle fait simplement du throttling.
Une protection complète comporte généralement plusieurs éléments distincts :
Si vous construisez un backend API sur une plateforme comme AppMaster, ces règles restent pertinentes. Même avec du code propre et régénéré, vous voudrez des valeurs par défaut protectrices afin qu’un mauvais client ne fasse pas tomber tout votre service.
Ces notions sont souvent confondues, mais elles résolvent des problèmes différents et se ressentent différemment pour les utilisateurs.
Une rate limit est une limite de vitesse : combien de requêtes un client peut faire sur une courte fenêtre (par seconde, par minute). Un quota est un budget : l’usage total sur une fenêtre plus longue (par jour, par mois). Une limite de concurrence plafonne le nombre de requêtes en cours simultanément, utile pour des endpoints coûteux même si le taux de requêtes semble normal.
Où vous attachez la limite compte :
Le soft throttling ralentit le client (délai, réduction de la capacité de rafale) pour qu'il puisse récupérer sans casser les workflows. Le blocage dur rejette les requêtes immédiatement, généralement avec un HTTP 429.
Un lockout est plus sévère qu'un 429 classique. Un 429 dit « réessayez bientôt ». Un lockout dit « arrêtez jusqu'à ce qu'une condition soit remplie », comme une période de refroidissement, une revue manuelle ou une réinitialisation de clé. Réservez les lockouts aux signaux d'abus clairs (credential stuffing, scraping agressif, authentifications invalides répétées), pas aux pics de trafic normaux.
Si vous bâtissez une API avec un outil comme AppMaster, considérez ces contrôles séparément : limites courte fenêtre pour les rafales, quotas longs pour les coûts, et lockouts uniquement pour les mauvais comportements répétés.
De bonnes limites commencent par un objectif : protéger le backend tout en laissant les utilisateurs normaux terminer leur travail. Vous n'avez pas besoin de chiffres parfaits dès le premier jour. Il vous faut une base sûre et un moyen de l'ajuster.
Un point de départ simple est une limite par clé API qui correspond au type d'API que vous exploitez :
Ensuite, segmentez les limites par type d'endpoint. Les lectures sont généralement moins coûteuses et peuvent tolérer des limites plus élevées. Les écritures modifient des données, déclenchent souvent une logique supplémentaire et méritent des plafonds plus stricts. Un pattern courant : 1 000/min pour les GET et 100–300/min pour les POST/PUT/DELETE.
Identifiez aussi les endpoints coûteux et traitez-les séparément. Recherche, génération de rapports, exports, uploads de fichiers et tout ce qui touche plusieurs tables ou exécute une logique lourde devraient avoir un bucket plus petit même si le reste de l'API est généreux. Si votre backend utilise des workflows visuels (par exemple des Business Process flows), chaque étape ajoutée représente du travail réel qui se multiplie en charge.
Prévoyez les rafales avec deux fenêtres : une courte pour absorber les pics rapides et une plus longue pour contrôler l'usage soutenu. Un combo courant est 10 secondes + 10 minutes. Cela aide les utilisateurs qui cliquent vite sans donner une vitesse illimitée aux scrapers.
Enfin, décidez ce qui arrive quand le client dépasse la limite. La plupart des APIs publiques retournent HTTP 429 avec un temps de retry clair. Si le travail peut être différé (comme un export), envisagez de le mettre en file d'attente plutôt que de bloquer durement pour que les vrais utilisateurs obtiennent quand même un résultat.
Les quotas par clé sont souvent la solution la plus équitable car ils s'alignent sur l'usage réel des clients : un compte, une clé API, une responsabilité claire. Les limites basées sur l'IP restent utiles, mais elles pénalisent souvent des innocents.
Les IP partagées sont la principale raison : tout un bureau peut sortir par une seule IP publique, et les opérateurs mobiles peuvent placer des milliers d'appareils derrière un petit pool d'IP. Si vous comptez seulement sur des plafonds par IP, un utilisateur bruyant peut ralentir tout le monde. Une politique par clé évite cela, et vous pouvez conserver une petite limite par IP comme filet pour les inondations évidentes.
Pour que les quotas paraissent justes, liez-les aux paliers clients sans piéger les nouveaux venus. Une clé gratuite ou d'essai doit permettre des tests réels, mais pas à l'échelle qui vous nuirait. Un pattern simple : rafales généreuses, taux soutenu modéré et un quota journalier conforme au plan.
Une politique par clé prévisible :
Pour décourager le partage de clé et les inscriptions automatisées, vous n'avez pas besoin d'une surveillance lourde. Commencez par des vérifications simples : changements géographiques inhabituel, trop d'IP distinctes par heure pour une même clé, ou beaucoup de nouvelles clés créées depuis la même source. Signalez et ralentissez d'abord ; verrouillez seulement après signaux répétés.
Le trafic anonyme est là où des plafonds plus stricts ont du sens. Si vous proposez des clés d'essai, limitez-les fortement et exigez une vérification de base avant d'augmenter les limites. Si votre API alimente un formulaire public, envisagez un endpoint anonyme séparé avec son propre quota pour protéger le reste du backend.
Si vous bâtissez votre API avec une plateforme comme AppMaster, la logique par clé est plus facile à garder cohérente car auth, règles métiers et gestion des réponses vivent au même endroit.
La limitation de taux ne fonctionne durablement que si les clients comprennent ce qui s'est passé et quoi faire ensuite. Visez des réponses ennuyeusement prévisibles : même code d'état, mêmes champs, même signification sur tous les endpoints.
Quand un client atteint une limite, retournez HTTP 429 (Too Many Requests) avec un message clair et un délai concret. Le gain le plus rapide est d'ajouter Retry-After, car même des clients simples peuvent ainsi attendre correctement.
Un petit ensemble d'en-têtes rend les limites explicites. Gardez des noms cohérents et incluez-les à la fois dans les réponses réussies (pour que les clients puissent s'auto-rythmer) et dans les 429 (pour qu'ils puissent récupérer) :
Retry-After : secondes à attendre avant de retenterX-RateLimit-Limit : requêtes autorisées dans la fenêtre couranteX-RateLimit-Remaining : requêtes restantes dans la fenêtre couranteX-RateLimit-Reset : quand la fenêtre se réinitialise (epoch seconds ou ISO time)X-RateLimit-Policy : texte court du type "60 requests per 60s"Faites le corps d'erreur aussi structuré que vos réponses de succès. Un schéma courant est un objet d'erreur avec un code stable, un message lisible et des indications de récupération.
{
"error": {
"code": "rate_limit_exceeded",
"message": "Too many requests. Please retry after 12 seconds.",
"retry_after_seconds": 12,
"limit": 60,
"remaining": 0,
"reset_at": "2026-01-25T12:34:56Z"
}
}
Dites aux clients comment reculer quand ils voient des 429. L'exponential backoff est un bon défaut : attendre 1s, puis 2s, puis 4s, en plafonnant (par exemple à 30–60 secondes). Soyez aussi explicite sur le moment d'arrêter les retries.
Évitez les surprises près des quotas. Quand une clé est proche d'un plafond (par exemple 80–90% consommé), incluez un champ ou un en-tête d'avertissement pour que les clients ralentissent avant d'échouer. Cela compte d'autant plus quand un script peut frapper plusieurs routes rapidement et brûler le budget plus vite que prévu.
Un déploiement fonctionne mieux quand vous traitez les limites comme un comportement produit, pas comme une règle ponctuelle de firewall. L'objectif reste : protéger le backend tout en laissant les clients normaux avancer.
Commencez par un inventaire rapide. Listez chaque endpoint, puis marquez-les par coût (CPU, travail base de données, appels tiers) et risque (login, reset de mot de passe, recherche, upload). Cela évite d'appliquer une seule limite brutale partout.
Un ordre de déploiement qui évite généralement les surprises :
Rendez la première release conservatrice. Il est plus facile d'assouplir ensuite que de débloquer des utilisateurs en colère.
Surveillez et ajustez, puis versionnez votre politique. Suivez combien de requêtes atteignent les limites, quels endpoints déclenchent les limites et combien de clés uniques sont affectées. Quand vous changez des chiffres, traitez cela comme un changement d'API : documentez-le, déployez progressivement et gardez règles anciennes et nouvelles séparées pour pouvoir revenir en arrière rapidement.
Si vous construisez votre API avec AppMaster, planifiez ces règles en même temps que vos endpoints et votre logique métier afin que les limites reflètent le coût réel de chaque workflow.
Les lockouts sont la ceinture de sécurité. Ils doivent arrêter l'abus évident rapidement, tout en offrant aux utilisateurs normaux une voie claire pour récupérer si quelque chose tourne mal.
Adoptez une approche calme avec pénalités progressives. Supposez que le client est peut‑être mal configuré, pas forcément malveillant, et n'escaladez que si le même schéma se répète.
Utilisez un petit ensemble d'étapes faciles à expliquer et à implémenter :
Le choix de ce que l'on verrouille compte. Par clé API est généralement le plus juste car cela cible l'appelant, pas tout le monde derrière un réseau partagé. Par compte aide quand les utilisateurs tournent des clés. Par IP peut aider pour le trafic anonyme, mais génère des faux positifs pour les NATs, bureaux et opérateurs mobiles. En cas d'abus sérieux, combinez les signaux (par exemple, verrouillez la clé et exigez des contrôles supplémentaires pour cette IP), mais gardez le rayon d'impact réduit.
Rendez les lockouts basés sur le temps avec des règles simples : « bloqué jusqu'à 14:05 UTC » et « se réinitialise après 30 minutes de comportement correct ». Évitez les bannissements permanents pour des systèmes automatisés. Un client bogué peut boucler et consommer des limites très vite, donc concevez des pénalités qui décroissent avec le temps. Une période soutenue à faible débit devrait réduire le niveau de pénalité.
Si vous développez votre API dans AppMaster, cette échelle correspond bien à des compteurs stockés plus un Business Process qui décide d'autoriser, ralentir ou bloquer et écrit l'heure de déverrouillage pour la clé.
Pour les récidivistes, conservez une voie de revue manuelle. Ne vous embrouillez pas avec les utilisateurs. Demandez des IDs de requête, des timestamps et le nom de la clé API, puis décidez sur la base des preuves.
Les faux positifs surviennent quand vos défenses bloquent des utilisateurs normaux. Ils apparaissent généralement quand les règles sont trop simplistes pour la façon dont les gens utilisent réellement votre API.
Une erreur classique est une limite globale pour tout. Si vous traitez un endpoint de lecture peu coûteux et un export cher de la même façon, vous allez soit surprotéger le cheap (ennuyeux), soit sous-protéger le cost‑heavy (dangereux). Séparez les limites par coût d'endpoint et rendez les chemins lourds plus stricts.
Le limitation uniquement par IP est un autre piège courant. Beaucoup d'utilisateurs réels partagent une IP publique (bureaux, écoles, opérateurs mobiles). Un utilisateur intensif peut bloquer tout le monde, et cela ressemble à des pannes aléatoires. Préférez la limitation par clé API en priorité, puis utilisez l'IP comme signal secondaire pour les abus évidents.
Les défaillances peuvent aussi créer des faux positifs. Si votre magasin de limites tombe, "fail closed" peut mettre toute votre API hors service. "Fail open" peut inviter un pic qui prend votre backend. Choisissez un fallback clair : gardez un petit cap d'urgence à la périphérie et dégradez gracieusement sur les endpoints non critiques.
La gestion côté client compte plus que ce que la plupart des équipes imaginent. Si vous retournez un 429 générique sans message clair, les utilisateurs réessaient plus fort et déclenchent davantage de blocages. Envoyez toujours Retry-After et gardez le texte d'erreur spécifique ("Too many requests for this key. Try again in 30 seconds.").
Le problème le plus évitable est la confidentialité. Des limites cachées ressemblent à des bugs quand les clients montent en charge en production pour la première fois. Partagez une politique simple et maintenez-la stable.
Checklist rapide pour éviter les faux positifs :
Retry-AfterSi vous construisez votre API avec un outil comme AppMaster, cela signifie souvent définir des plafonds différents par endpoint et renvoyer des payloads d'erreur cohérents pour que les clients puissent reculer sans deviner.
La limitation de taux ne fonctionne que si vous voyez ce qui se passe en temps réel. L'objectif n'est pas d'attraper chaque pic, mais de repérer les schémas qui deviennent des pannes ou des clients furieux.
Commencez par un petit ensemble de signaux qui expliquent à la fois le volume et l'intention :
Pour séparer « mauvais trafic » et « on vient de déployer », ajoutez du contexte aux tableaux de bord : heure de déploiement, changements de feature flags, envois marketing. Si le trafic monte juste après une release et que le mix 429/5xx reste sain, c'est généralement de la croissance, pas de l'abus. Si la montée est concentrée sur une clé, une plage d'IP ou un endpoint coûteux, traitez-la comme suspecte.
Les alertes doivent être ennuyeuses. Utilisez des seuils avec cooldowns pour éviter d'être dérangé chaque minute pour le même événement :
Quand une alerte se déclenche, gardez une note d'incident courte : ce qui a changé, ce que vous avez vu (top clés/endpoints) et ce que vous avez ajusté (limites, caches, blocages temporaires). Avec le temps, ces notes deviennent votre vrai playbook.
Exemple : vous lancez un nouvel endpoint de recherche et le trafic double. Si la plupart des appels ciblent cet endpoint sur de nombreuses clés, augmentez légèrement le quota par clé et optimisez l'endpoint. Si une clé tape des exports en continu et fait monter la latence, calez ce endpoint séparément et contactez le propriétaire.
Une bonne configuration est ennuyeuse quand elle fonctionne. Cette checklist attrape les problèmes qui causent généralement des faux positifs ou laissent des trous évidents.
Effectuez ces vérifications en staging et de nouveau juste après le lancement :
Si vous bâtissez sur AppMaster, traitez chaque nouvel endpoint comme une décision de niveau de coût : une recherche simple peut être généreuse, tandis que tout ce qui déclenche une logique métier lourde devrait commencer plus strict.
Protégez le backend tout en permettant aux vrais utilisateurs de récupérer :
Avant d'augmenter les limites pour un client, vérifiez son pattern normal de requêtes, la répartition des endpoints et s'il peut mutualiser ou ajouter du backoff. Confirmez aussi qu'il ne partage pas une clé entre plusieurs apps.
Chaque mois, passez en revue : endpoints limités les plus fréquents, pourcentage de trafic atteint par les limites, nouveaux endpoints coûteux et si vos quotas correspondent toujours à l'usage réel.
Imaginez que vous exploitez une API publique utilisée par deux apps : un portail client (fort volume, trafic stable) et un outil admin interne (faible volume, mais actions puissantes). Les deux utilisent des clés API, et le portail a aussi un endpoint de login pour les utilisateurs finaux.
Un après-midi, un partenaire publie une intégration bugguée. Elle commence à relancer les requêtes échouées en boucle, envoyant 200 requêtes par seconde depuis une seule clé API. Sans garde‑fous, cette clé peut évincer tout le monde.
Les limites par clé contiennent le rayon d'impact. La clé bugguée atteint son cap par minute, reçoit des 429 et le reste des clients continue de fonctionner. Vous pouvez aussi avoir une limite plus basse pour les endpoints coûteux (comme les exports) afin que même le trafic « autorisé » ne surcharge pas la base.
En même temps, une attaque brute‑force sur le login commence à marteler l'endpoint d'auth. Plutôt que de bloquer toute une plage d'IP (qui toucherait des utilisateurs réels derrière un NAT), vous le ralentissez puis le verrouillez selon le comportement : trop d'échecs par compte plus par IP sur une courte fenêtre. L'attaquant subit des délais progressivement plus longs, puis un verrouillage temporaire.
Un vrai client qui a mal tapé son mot de passe quelques fois peut récupérer parce que vos réponses sont claires et prévisibles :
Retry-After pour que le client sache quand retenterPour confirmer la correction, vous surveillez quelques métriques :
C'est à quoi ressemble une limitation protectrice : elle protège le backend sans punir les utilisateurs normaux.
Vous n'avez pas besoin d'un modèle parfait dès le premier jour. Commencez par une politique petite et claire et améliorez‑la en apprenant le comportement réel des utilisateurs.
Une première version solide contient généralement trois parties :
Ajoutez des lockouts uniquement quand le risque d'abus est élevé et que l'intention est facilement inférable. Signup, login, reset de mot de passe et création de tokens sont des candidats typiques. Gardez les lockouts courts au départ (minutes, pas jours) et préférez la friction progressive : ralentir, bloquer temporairement, puis exiger une vérification plus forte.
Écrivez la politique en clair pour que le support puisse l'expliquer sans aide d'ingénierie. Incluez ce qui est limité (par clé API, par IP, par compte), la fenêtre de réinitialisation et comment un client peut récupérer.
Si vous implémentez cela en construisant un nouveau backend, AppMaster peut être un choix pratique : vous pouvez créer des APIs, définir des workflows métiers (y compris compteurs et décisions de verrouillage) visuellement, puis déployer sur des clouds ou exporter le code source généré quand vous avez besoin d'un contrôle total.
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
