Votre API publique explose en trafic après une intégration viral. Les premiers appels viennent d'un agrégateur partenaire — 200 req/s légitimes. Votre limite globale à 100 req/s par IP le bloque. Pendant ce temps, un bot distribué sur 500 IP free tier grignote l'endpoint /search sans être inquiété.
Le rate limiting mal conçu protège le serveur contre les mauvais clients et contre les bons en même temps.
Objectifs clairs
Protéger CPU/DB, garantir équité entre tenants, monétiser tiers premium, absorber bursts courts. Ce n'est pas de la sécurité seule — un attaquant déterminé contourne des limites basiques.
Algorithmes
| Algo | Comportement | Cas d'usage |
|---|---|---|
| Fixed window | Simple, pics en bordure | Interne bas volume |
| Sliding window | Plus juste | API publique |
| Token bucket | Autorise burst contrôlé | Partenaires B2B |
| Leaky bucket | Sortie régulière | Files d'attente |
Redis + Lua ou services gateway managés (Cloudflare, Kong, AWS API GW).
Clés de quota
Hiérarchie : clé API → plan → endpoint sensible. IP en dernier recours. Authentifiés vs anonymes : pools séparés.
Whitelist temporaire pour lancement partenaire avec plafond signé contractuellement.
UX côté client
Documentez limites dans OpenAPI. Exemples de backoff exponentiel + jitter. 429 explicite vaut mieux qu'un timeout silent.
Surconsommation : 402/403 métier vs 429 technique — distinguez quota billing et surcharge.
Tests de charge
Simulez burst 3× la limite, vérifiez recovery < 1 min. Mesurez faux positifs sur IP corporate. Ajustez après observabilité réelle, pas seulement spreadsheet.
Calibrer sans punir
Commencez par mesurer trafic baseline 14 jours : p50/p95/p99 par endpoint et par clé API. Fixez limite à 2× p99 du plus gros client légitime sur endpoint cher.
Implémentez token bucket avec burst 2× sustained. Annoncez headers avant d'activer enforce.
Créez tier « sandbox » bas pour dev keys et tier « production » contractuel. Sur-vendre sans quota documenté = tickets support.
Observez 429 rate : si >1 % requêtes legit, limite trop basse. Si scraper inchangé, limite mal ciblée (IP vs key).
Révisez après chaque gros client onboarded — leur traffic profile change la médiane pour tous si mal isolé.
Dimensionner avec des chiffres réels
Exportez sept jours de logs access : comptez requêtes par minute par clé API et par route. La limite globale « 1000 req/min » masque un endpoint /export qui en génère 800 seul. Limitez par route sensible : auth, search, export, webhook inbound.
Les crawlers respectueux (Googlebot) versus scrapers agressifs : rate limit IP seul pénalise le premier derrière NAT corporate. Combinez comportement (pas de User-Agent, séquence endpoints suspecte) avec quota clé.
Communiquez un calendrier de migration : « Limite enforce à partir du 1er octobre » avec headers preview mode avant blocage dur. Les SDK partenaires intègrent Retry-After ; les scripts maison non — prévenez.
Sur VPS petit budget, Redis local pour compteurs suffit jusqu'à quelques milliers req/s. Au-delà, edge CDN rate limit évite que le compteur devienne votre propre DDoS sur Redis.
Les partenaires B2B demandent souvent « pas de limite » — répondez par quota contractuel chiffré + burst + prix overage, pas absence de limite.
Distinction 429 technique vs 402 billing : mélanger les deux dans la même doc API crée tickets support sans fin.
Graph dashboard : top consumers par clé — identifie scrapers authentifiés avant qu'ils ne deviennent incident sécurité.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Edge rate limit
Redis local VPS puis CDN edge au-delà milliers req/s.
Décider et avancer sans angle mort
- Mesurer quatorze jours de baseline — p50/p95/p99 par endpoint et par clé API.
- Fixer la limite à 2× le p99 du plus gros client légitime sur l'endpoint le plus coûteux.
- Token bucket avec burst — annoncez les headers RateLimit avant d'activer l'enforcement.
- Tiers sandbox et production — quotas contractuels documentés pour éviter les tickets support.
- Revoir après chaque gros client — le profil trafic change la médiane pour tous si mal isolé.
Dimensionnez CPU et réseau via l'annuaire, le comparateur et le blog API.
Questions fréquentes
Limiter par IP suffit-il ?
Non pour les clients derrière NAT ou CDN. Préférez clé API + IP en fallback, avec quotas par tenant.
Token bucket ou fixed window ?
Token bucket lisse les bursts. Fixed window crée des effets de falaise en fin de fenêtre ; sliding window coûte plus cher mais plus juste.
Quel header renvoyer ?
429 + Retry-After + X-RateLimit-Remaining/Limit/Reset aide les SDK clients à backoff proprement.
Rate limit au edge ou app ?
Edge (CDN, API gateway) stoppe le flood tôt. App garde des limites métier fines (coût par endpoint).
Publiez vos limites dans la doc avant le prochain lancement — les bons clients planifient, les bots non.