C'est quoi le rate limiting par IP ?

Le rate limiting par IP est un mécanisme qui limite le nombre de requêtes qu'une adresse IP peut envoyer à un serveur pendant une période donnée. Si vous dépassez la limite, le serveur refuse temporairement vos requêtes, généralement avec une erreur HTTP 429 ("Too Many Requests"). C'est l'un des outils les plus courants pour protéger les serveurs contre les abus, les attaques par déni de service et le scraping automatisé.

Vous l'avez probablement déjà rencontré sans le savoir. Quand un site vous affiche "Vous avez fait trop de tentatives, réessayez dans 5 minutes" après plusieurs connexions échouées, c'est du rate limiting. Quand une API vous renvoie une erreur après un certain nombre d'appels par minute, c'est du rate limiting. Quand un moteur de recherche bloque temporairement vos requêtes parce que vous avez cherché trop vite, c'est encore du rate limiting.

Pourquoi c'est nécessaire

Un serveur web a des ressources limitées : CPU, mémoire, bande passante, connexions à la base de données. Chaque requête consomme une part de ces ressources. Sans aucune limitation, un seul utilisateur (ou un script automatisé) pourrait monopoliser le serveur en envoyant des milliers de requêtes par seconde, rendant le service inaccessible pour tous les autres.

Le rate limiting protège contre plusieurs types de menaces :

Attaques DDoS et brute force. Une attaque par déni de service distribué (DDoS) inonde un serveur de requêtes pour le rendre indisponible. Le rate limiting ne suffit pas à bloquer une attaque DDoS massive (qui vient de milliers d'adresses IP différentes), mais il limite les dégâts qu'une seule IP peut causer. Pour les attaques par brute force (essayer des milliers de mots de passe), le rate limiting est la première ligne de défense : limiter à 5 ou 10 tentatives de connexion par minute rend l'attaque impraticable.

Scraping et crawling abusif. Les bots qui extraient le contenu d'un site (prix, articles, données) envoient des centaines de requêtes par seconde. Le rate limiting ralentit ces bots au point de rendre l'extraction massive non viable économiquement (trop lent, trop de temps serveur nécessaire).

Abus d'API. Les API publiques (météo, géolocalisation, IA, paiement) ont un coût par requête pour le fournisseur. Sans rate limiting, un utilisateur pourrait consommer des ressources disproportionnées, que ce soit par erreur (une boucle dans son code) ou intentionnellement. La plupart des API imposent des limites par clé API et par adresse IP.

Équité entre utilisateurs. Même sans intention malveillante, un utilisateur "gourmand" (qui rafraîchit une page 50 fois par minute, ou un script mal écrit) peut dégrader l'expérience pour les autres. Le rate limiting garantit un partage équitable des ressources.

Comment ça fonctionne techniquement

Le principe est simple : le serveur associe chaque requête à une adresse IP, compte le nombre de requêtes reçues de cette IP dans une fenêtre de temps, et refuse les requêtes qui dépassent le seuil défini. Mais l'implémentation concrète varie selon l'algorithme utilisé.

Fenêtre fixe (Fixed Window). Le temps est découpé en intervalles fixes (par exemple, des fenêtres d'une minute). Le serveur compte les requêtes par IP dans chaque fenêtre. Si vous atteignez 100 requêtes dans la fenêtre en cours, les suivantes sont refusées jusqu'au début de la fenêtre suivante. C'est l'algorithme le plus simple, mais il a un défaut : si vous envoyez 100 requêtes à la fin d'une fenêtre et 100 au début de la suivante, vous avez envoyé 200 requêtes en quelques secondes, soit le double de la limite prévue.

Fenêtre glissante (Sliding Window). Au lieu de fenêtres fixes, le serveur regarde les N dernières secondes à tout moment. Chaque requête est comptée sur une période glissante. Cela lisse la distribution et élimine le problème de la fenêtre fixe, mais demande plus de mémoire et de calcul côté serveur.

Token Bucket (seau à jetons). Chaque IP dispose d'un "seau" contenant un nombre fixe de jetons. Chaque requête consomme un jeton. Les jetons se régénèrent à un rythme constant (par exemple, 10 par seconde). Si le seau est vide, la requête est refusée. Ce modèle permet des rafales courtes (burst) : vous pouvez envoyer beaucoup de requêtes d'un coup si votre seau est plein, puis vous devez attendre la régénération. C'est l'algorithme le plus utilisé en production parce qu'il est à la fois flexible et prévisible.

Leaky Bucket (seau percé). Les requêtes entrent dans une file d'attente (le seau) et sont traitées à un rythme constant (le débit de fuite). Si le seau est plein, les nouvelles requêtes sont rejetées. Contrairement au Token Bucket, le Leaky Bucket impose un débit de sortie strictement constant, sans rafales. C'est utile quand vous voulez un flux de traitement parfaitement régulier.

Où le rate limiting est appliqué

Le rate limiting peut être appliqué à différents niveaux de l'infrastructure réseau, et c'est souvent le cas en pratique : plusieurs couches se superposent.

Au niveau du serveur web. Nginx, Apache et la plupart des serveurs web intègrent des modules de rate limiting. Nginx, par exemple, utilise l'algorithme Leaky Bucket avec sa directive limit_req. Vous définissez un nombre de requêtes par seconde par IP, et Nginx gère le reste. C'est efficace pour une protection de base, mais le serveur doit quand même recevoir et traiter partiellement chaque requête avant de la rejeter.

Au niveau du reverse proxy ou du load balancer. Placer le rate limiting devant les serveurs applicatifs (sur un reverse proxy comme Nginx ou HAProxy, ou un load balancer) permet de bloquer les requêtes avant qu'elles n'atteignent l'application. C'est plus efficace en termes de ressources.

Au niveau du CDN ou du pare-feu applicatif (WAF). Les services comme Cloudflare, AWS WAF ou Akamai appliquent le rate limiting en bordure de réseau (edge), avant même que la requête n'atteigne votre infrastructure. C'est la couche la plus efficace contre les attaques volumétriques, parce que la requête est bloquée au plus près de sa source.

Au niveau de l'application. L'application elle-même peut implémenter du rate limiting, souvent avec plus de granularité : par utilisateur connecté, par endpoint, par type d'opération. Par exemple, une API peut autoriser 1 000 requêtes GET par minute mais seulement 10 requêtes POST sur un endpoint de création de compte, parce que les tentatives de création de compte abusives sont un vecteur d'attaque courant.

Les en-têtes HTTP liés au rate limiting

Quand un serveur applique du rate limiting, il communique généralement les informations de limite via des en-têtes HTTP dans la réponse. Il n'y a pas de standard universel, mais les conventions les plus courantes sont :

X-RateLimit-Limit : le nombre maximum de requêtes autorisées dans la fenêtre de temps en cours. X-RateLimit-Remaining : le nombre de requêtes restantes avant d'atteindre la limite. X-RateLimit-Reset : le moment (en timestamp Unix ou en secondes restantes) où la fenêtre se réinitialise et le compteur repart à zéro. Retry-After : un en-tête standard HTTP qui indique combien de temps attendre avant de réessayer, renvoyé avec la réponse 429.

Un draft IETF (RFC 6585 pour le code 429 et des propositions plus récentes) tente de standardiser ces en-têtes, mais en pratique chaque API utilise sa propre convention. Si vous développez une application qui consomme des API, lisez toujours la documentation de l'API pour savoir comment elle communique ses limites.

Pourquoi l'IP seule ne suffit pas toujours

Le rate limiting par IP a un problème fondamental : une adresse IP ne correspond pas toujours à un seul utilisateur.

Le CGNAT. De nombreux opérateurs mobiles et certains FAI utilisent le CGNAT (Carrier-Grade NAT), qui fait partager une même adresse IPv4 publique à des centaines ou des milliers d'utilisateurs. Si vous limitez une IP à 100 requêtes par minute, vous limitez en réalité tous les utilisateurs derrière ce CGNAT à un total combiné de 100 requêtes. Un seul utilisateur normal peut épuiser le quota pour tous les autres.

Les réseaux d'entreprise et universitaires. Des milliers d'employés ou d'étudiants peuvent accéder à internet via une seule adresse IP publique (ou un petit nombre d'adresses). Le rate limiting par IP les pénalise collectivement.

Les VPN et proxys. Les utilisateurs de VPN partagent souvent une adresse IP avec des centaines d'autres personnes. Un rate limiting strict par IP peut bloquer des utilisateurs légitimes simplement parce qu'ils utilisent le même serveur VPN qu'un bot.

Les adresses IP dynamiques. À l'inverse, un attaquant peut changer facilement d'adresse IP (en utilisant un pool de proxys, un botnet, ou simplement en basculant son téléphone en mode avion) et contourner le rate limiting par IP. Si la limite est par IP et que l'attaquant a accès à 10 000 adresses, la limite effective est multipliée par 10 000.

C'est pourquoi les systèmes de rate limiting modernes combinent généralement l'IP avec d'autres identifiants : clé API, token d'authentification, empreinte du navigateur, cookie de session. L'IP reste un critère utile, mais rarement suffisant seul.

Que se passe-t-il quand vous êtes limité

La réponse la plus courante est un code HTTP 429 (Too Many Requests). Le serveur peut aussi renvoyer un code 503 (Service Unavailable) si la limitation est due à une surcharge générale plutôt qu'à un dépassement individuel.

Certains services ne bloquent pas complètement l'accès mais dégradent le service : ils ralentissent les réponses (throttling), réduisent la qualité des résultats, ou ajoutent un CAPTCHA pour vérifier que vous êtes un humain.

D'autres services bloquent silencieusement sans renvoyer d'erreur explicite. Ils continuent de répondre avec un code 200 (OK) mais renvoient des données vides ou des résultats dégradés. Ce "rate limiting silencieux" (shadow banning) est courant sur les réseaux sociaux et certains moteurs de recherche, et il est conçu pour être difficile à détecter par les bots.

Comment les développeurs gèrent le rate limiting

Si vous développez une application qui consomme une API, vous devez gérer le rate limiting proprement. La méthode standard est le "exponential backoff" : quand vous recevez une réponse 429, vous attendez un temps donné avant de réessayer, et vous doublez ce temps à chaque échec successif. Par exemple : première tentative après 1 seconde, deuxième après 2 secondes, troisième après 4 secondes, etc.

Les bonnes pratiques incluent :

Lire les en-têtes Retry-After et X-RateLimit-Reset pour savoir exactement quand réessayer, au lieu de deviner. Implémenter un cache pour éviter de refaire les mêmes requêtes. Regrouper les requêtes (batching) quand l'API le permet. Distribuer les requêtes dans le temps plutôt que de les envoyer en rafale. Prévoir un circuit breaker qui arrête d'appeler l'API pendant un moment si les erreurs 429 s'accumulent, pour éviter d'aggraver la situation.

Rate limiting et vie privée

Le rate limiting par IP implique que le serveur identifie et suit les requêtes par adresse IP. C'est une forme de traitement de données personnelles (l'adresse IP étant considérée comme une donnée personnelle dans de nombreuses juridictions, notamment sous le RGPD en Europe). Les entreprises qui implémentent du rate limiting doivent en théorie mentionner ce traitement dans leur politique de confidentialité.

Du point de vue de l'utilisateur, le rate limiting par IP signifie aussi que votre activité est comptabilisée. Si vous utilisez un VPN ou un proxy pour des raisons de confidentialité, le rate limiting peut paradoxalement vous pénaliser : vous partagez une IP avec d'autres utilisateurs et le quota commun s'épuise plus vite.

Contourner le rate limiting

Changer d'adresse IP (via un VPN, un proxy rotatif, ou le mode avion sur mobile) permet de contourner un rate limiting basé uniquement sur l'IP. Les services de scraping commerciaux utilisent des pools de milliers d'adresses IP résidentielles pour distribuer les requêtes et rester sous les seuils par IP.

Mais les systèmes de protection modernes ne se limitent pas à l'IP. Ils combinent l'analyse de l'empreinte du navigateur, le comportement de navigation (rythme des clics, mouvements de souris, temps passé sur les pages), les CAPTCHA, et l'analyse des patterns de requêtes pour distinguer les humains des bots, même quand l'IP change à chaque requête.

La course entre les systèmes de rate limiting et les techniques de contournement est permanente. Les méthodes qui marchent aujourd'hui peuvent être détectées demain. Si vous êtes du côté du serveur, la meilleure stratégie est de combiner plusieurs couches de protection plutôt que de compter sur l'IP seule.

Exemples de limites courantes

Ces limites varient énormément selon le service, le plan tarifaire et le contexte. Une API payante offre généralement des limites bien plus élevées qu'un plan gratuit. Un endpoint sensible (connexion, paiement, création de compte) a des limites bien plus basses qu'un endpoint de lecture de données.

Le rate limiting par IP est une protection essentielle pour tout serveur exposé à internet. Il empêche les abus, protège les ressources et garantit un accès équitable. Mais l'adresse IP seule est un identifiant de moins en moins fiable avec le CGNAT, les VPN et les proxys. Les systèmes modernes combinent l'IP avec d'autres signaux pour distinguer le trafic légitime du trafic abusif, et c'est cette combinaison qui fait la différence entre une protection efficace et un simple filtre facile à contourner.