Rate limiting et throttling : protéger votre API des abus sans bloquer vos clients

Une API mal protégée est une porte ouverte aux abus. Que ce soit un client qui lance 10 000 requêtes en une minute, un concurrent qui scrape vos données, ou simplement un développeur inexpérimenté qui boucle sans limite, les risques sont réels : surcharge serveur, coûts cloud explosifs, expérience dégradée pour les utilisateurs légitimes.

Le rate limiting et le throttling sont deux mécanismes complémentaires pour maîtriser ce flux. Contrairement aux idées reçues, il ne s'agit pas de bloquer méchamment vos clients, mais de mettre en place des règles justes et transparentes qui protègent votre infrastructure tout en permettant une utilisation normale.

Comprendre la différence : rate limiting vs throttling

Bien que souvent confondus, ces deux termes désignent des stratégies distinctes.

Rate limiting : la limite stricte

Le rate limiting refuse les requêtes qui dépassent un quota. Exemples courants :

• 100 requêtes par minute par adresse IP
• 1 000 requêtes par jour par clé API
• 10 uploads simultanés par utilisateur

Quand la limite est atteinte, l'API répond avec un code HTTP 429 (Too Many Requests). Le client doit attendre ou implémenter une stratégie de retry exponentiellement croissante.

Throttling : ralentir progressivement

Le throttling ralentit la réponse plutôt que de refuser. L'API traite les requêtes, mais avec des délais augmentant progressivement. C'est moins agressif qu'un refus net, idéal pour les pics de charge tempérés.

Pourquoi c'est essentiel pour une PME

Vous pensez peut-être que le rate limiting ne concerne que les grandes platefmes. C'est faux. En tant que PME :

• Vos serveurs coûtent cher au dépassement. Un bot qui scrape votre API peut générer des milliers de requêtes sans valeur.
• Vous partagez l'infrastructure. Un client malfaisant ralentit tous les autres.
• Vous dépendez de partenaires externes. Une intégration mal codée peut étouffer votre API.
• Vous ne disposez pas d'équipes de sécurité dédiées. Automatiser cette protection est indispensable.

Les stratégies pratiques à mettre en place

1. Rate limiting par clé API

C'est la base. Chaque client reçoit une clé API avec un quota associé :

• Plan Gratuit : 100 requêtes/jour
• Plan Pro : 10 000 requêtes/jour
• Plan Entreprise : illimité (avec responsabilité contractuelle)

Stockez les compteurs en cache (Redis) pour éviter une requête base de données à chaque appel. C'est critique pour les performances.

2. Rate limiting par adresse IP

Pour les endpoints publics sans authentification, limitez par IP. Attention cependant : derrière un proxy ou load balancer, l'IP vue peut être celle du proxy, pas du client réel. Utilisez l'en-tête X-Forwarded-For avec prudence.

3. Bucketing adapté à votre métier

Ne limitez pas toutes les opérations de la même façon. Par exemple pour une boutique WooCommerce avec API :

• Lectures de produits : 1 000 req/min
• Créations de commandes : 50 req/min
• Uploads de médias : 10 req/min

Les opérations coûteuses en ressources doivent avoir des quotas plus serrés.

4. Exemples et fenêtres glissantes

Préférez les fenêtres glissantes aux fenêtres fixes :

• Fenêtre fixe (moins bon) : le quota se réinitialise à l'heure pile. Un client peut envoyer 100 requêtes à 23h59 et 100 à 00h01 = 200 en 2 minutes.
• Fenêtre glissante (mieux) : le quota se base sur les 60 dernières minutes réelles.

C'est plus complexe à implémenter mais beaucoup plus juste.

Communiquer les limites

Ne cachez pas vos règles. Chaque réponse HTTP doit inclure des en-têtes informatifs :

• X-RateLimit-Limit: 1000 (quota total)
• X-RateLimit-Remaining: 847 (requêtes restantes)
• X-RateLimit-Reset: 1706745600 (timestamp du reset)

Vos clients sauront à l'avance s'ils approchent de la limite et pourront adapter leur code. C'est la base de la confiance.

Intégration dans votre stack technique

Où implémenter le rate limiting ?

• Au niveau du reverse proxy (Nginx, HAProxy) : très performant, mais config limitée.
• Dans le middleware applicatif (Express, Laravel, Symfony) : plus flexible, permet des règles métier sophistiquées.
• Via une API gateway (Kong, Tyk) : idéal pour une architecture SaaS multi-tenant avec quotas par client.

Pour une PME, commencez par le middleware applicatif avec un cache Redis. C'est simple, efficace et maintenable.

Cas réel : intégration sans surprises

Imaginons une PME qui expose son ERP Dolibarr via API à ses partenaires. Sans rate limiting, un partenaire qui lance un script de synchronisation mal optimisé peut paralyser le serveur en quelques secondes. Avec un plan :

• Rate limit par partenaire : 500 req/min
• Bulk endpoints spécifiques : 10 req/min (mais traitant 100 enregistrements chacun)
• Fenêtre glissante sur 5 minutes pour lisser les pics

Résultat : les partenaires savent à quoi s'attendre et peuvent plannifier leurs syncs. Votre infrastructure reste stable. Tout le monde gagne.

Monitorer et ajuster

Mettez en place des alertes :

• Client qui atteint 90 % de son quota chaque jour ? Il a peut-être un besoin légitime d'augmentation.
• Pic anormal de requêtes d'une IP ? Possible attaque, il faut enquêter.
• Certains endpoints jamais ratés, d'autres constamment limités ? Les quotas ne sont pas bien calibrés.

Une bonne équipe technique doit analyser ces métriques mensuellement et ajuster.

Conclusion : le rate limiting n'est pas punition, c'est clarté. En définissant des règles justes et transparentes dès le départ, vous protégez votre infrastructure, maintenez une expérience fiable pour vos clients légitimes et évitez les surprises désagréables. Prenez une heure pour l'implémenter correctement : c'est du temps bien investi.

Questions fréquentes