Rate limiting : définition, algorithmes et mise en place

Le rate limiting, c'est quoi exactement ?

Le rate limiting est une technique qui limite le nombre de requêtes qu'un même client peut adresser à un serveur pendant un laps de temps défini. En français, on parle de limitation de débit ou de limitation du taux de requêtes. Le principe tient en une phrase : passé un seuil, par exemple cent requêtes par minute, les demandes suivantes sont refusées ou mises en attente jusqu'à la fenêtre suivante.

Le client peut être identifié de plusieurs façons. Le plus souvent, c'est son adresse IP. Sur une application où l'on se connecte, ce sera plutôt le compte utilisateur ou la clé d'API. Chaque identifiant dispose de son propre compteur, ce qui permet de freiner un seul visiteur trop gourmand sans pénaliser tous les autres.

La documentation technique anglophone résume souvent l'idée ainsi : « rate limiting is a strategy to limit the rate of requests a client can make ». Vous croiserez aussi le verbe « rate-limit » et les expressions « requests per second » ou « requests per minute ». Ce sont les mêmes notions, simplement en anglais, la langue de la plupart des outils.

Ce que voit le visiteur quand il dépasse la limite

Quand un client dépasse le plafond, le serveur lui renvoie en principe le code HTTP 429, qui signifie « Too Many Requests ». Ce code fait partie de la famille des codes de réponse HTTP de la série 4xx, réservée aux erreurs côté client. Une bonne configuration ajoute l'en-tête Retry-After, qui indique combien de secondes attendre avant de réessayer.

Beaucoup d'API ajoutent aussi des en-têtes d'information à chaque réponse, comme X-RateLimit-Limit pour le plafond, X-RateLimit-Remaining pour le solde restant et X-RateLimit-Reset pour l'heure de remise à zéro. Le développeur qui consomme le service sait alors où il en est et peut ralentir avant d'être bloqué.

À quoi sert le rate limiting pour une entreprise ?

Pour un dirigeant de PME, le sujet peut sembler très technique. Pourtant, ses effets touchent directement le chiffre d'affaires : un site lent ou en panne ne vend rien, et une facture de serveur qui explose rogne la marge. Le rate limiting sert avant tout à garder le contrôle sur les ressources de votre infrastructure.

Protéger le site contre les abus et les attaques

Un robot malveillant peut tester des milliers de mots de passe sur votre page de connexion. Limiter le nombre de tentatives par minute rend ce genre d'attaque par force brute beaucoup plus lente, donc beaucoup moins rentable pour l'attaquant. Le même raisonnement vaut pour les formulaires de contact pris d'assaut par le spam.

Face à une attaque DDoS, le rate limiting aide aussi, mais il ne suffit pas seul. Quand le trafic vient de milliers de machines différentes, chacune reste sous le seuil. Il faut alors le combiner avec un CDN ou un pare-feu applicatif capable d'absorber le volume en amont.

Garder un service rapide pour tous les utilisateurs

Les ressources d'un serveur sont finies : processeur, mémoire, connexions à la base de données. Si un seul client en monopolise une grande partie, tous les autres attendent. La limitation de débit répartit équitablement la capacité disponible, ce qui maintient des temps de réponse corrects même lors d'un pic de trafic.

Maîtriser les coûts et les services tiers

De nombreux services facturent à l'usage : hébergement cloud, envoi d'e-mails, appels à un modèle d'IA, géolocalisation. Un script qui tourne en boucle ou un robot qui aspire votre catalogue peut générer une facture imprévue. Fixer une limite par utilisateur évite qu'un comportement anormal se transforme en dépense.

À l'inverse, vous subissez aussi le rate limiting des autres. Les fournisseurs d'API comme Google, Stripe ou Mapbox imposent leurs propres quotas. Docker Hub limite par exemple le nombre de téléchargements d'images pour les comptes anonymes, ce qui bloque parfois des déploiements automatisés. Votre application doit savoir réagir quand elle reçoit un 429 de leur part.

Comment fonctionne le rate limiting : les quatre algorithmes

Derrière chaque limiteur se cache un algorithme qui décide quand une requête passe ou non. Il en existe quatre grands, chacun avec ses forces. Le choix dépend de la régularité attendue du trafic et de la précision souhaitée.

La fenêtre fixe (fixed window)

Le fixed window découpe le temps en tranches régulières, par exemple une minute. Un compteur s'incrémente à chaque requête et repart à zéro au début de la tranche suivante. Si le compteur dépasse la limite, les requêtes sont refusées jusqu'à la remise à zéro.

C'est la méthode la plus simple à coder et la moins gourmande en mémoire. Son défaut est connu : un client peut envoyer tout son quota dans les dernières secondes d'une fenêtre, puis tout le quota suivant dans les premières secondes de la suivante. Il double ainsi brièvement la limite prévue.

La fenêtre glissante (sliding window)

Le sliding window corrige ce défaut. Au lieu de tranches figées, il regarde toujours la période écoulée juste avant la requête, par exemple les soixante dernières secondes. Le nombre de requêtes est donc compté sur une fenêtre qui avance en continu.

Il existe deux variantes. La première garde l'horodatage de chaque requête, ce qui est très précis mais consomme de la mémoire. La seconde estime le total en pondérant le compteur de la fenêtre précédente, un bon compromis utilisé par de nombreux outils.

Le seau à jetons (token bucket)

Imaginez un seau qui contient un nombre maximal de jetons. Chaque requête consomme un jeton, et le seau se remplit à vitesse constante. Tant qu'il reste des jetons, les requêtes passent ; quand le seau est vide, elles sont refusées.

L'intérêt de ce bucket est d'accepter des rafales courtes. Un utilisateur qui charge une page déclenchant dix appels d'un coup ne sera pas bloqué, tant que sa consommation moyenne reste raisonnable. C'est l'algorithme le plus répandu dans les API publiques.

Le seau percé (leaky bucket)

Le leaky bucket fonctionne à l'envers. Les requêtes entrent dans une file d'attente, et elles en sortent à un rythme fixe, comme l'eau qui s'écoule d'un seau percé. Si la file est pleine, les nouvelles requêtes débordent et sont rejetées.

Cet algorithme lisse parfaitement le débit sortant, ce qui protège un service fragile situé derrière. En contrepartie, il ajoute un délai : une requête peut attendre dans la file avant d'être traitée. Le module limit_req de Nginx s'inspire de ce principe.

• Fenêtre fixe : simple et légère, mais laisse passer des pics en bordure de fenêtre.
• Fenêtre glissante : plus juste, un peu plus coûteuse à calculer.
• Token bucket : tolère les rafales courtes, idéal pour une API.
• Leaky bucket : débit très régulier, au prix d'une petite latence.

Mettre en place le rate limiting sur votre site ou votre API

On peut poser une limite à plusieurs étages de l'infrastructure. Plus elle est placée tôt, plus elle économise de ressources, car la requête rejetée n'atteint jamais votre application. Dans la pratique, on combine souvent deux niveaux.

Au niveau du CDN ou du pare-feu

Un CDN comme Cloudflare propose des règles de rate limiting configurables depuis son tableau de bord. Vous choisissez une adresse à protéger, par exemple la page de connexion, un seuil de requêtes et une action : bloquer, afficher un défi ou simplement journaliser. Cette couche filtre le trafic avant qu'il touche votre serveur.

Un pare-feu applicatif offre le même type de règles, souvent avec une détection plus fine des robots. Pour une PME, c'est la façon la plus rapide de se protéger sans toucher au code du site.

Au niveau du serveur web

Nginx dispose de directives natives, limit_req_zone et limit_req, qui définissent une zone de mémoire, une clé d'identification et un débit autorisé. Apache propose des modules équivalents. Cette solution reste efficace et peu coûteuse, à condition d'avoir accès à la configuration du serveur, ce qui n'est pas le cas sur tous les hébergements mutualisés.

Dans le code de l'application

Les frameworks modernes intègrent des outils prêts à l'emploi. En Express.js, le paquet express-rate-limit s'ajoute en quelques lignes comme middleware. Laravel fournit une façade RateLimiter et un middleware throttle. Côté Java, les équipes Spring Boot s'appuient souvent sur la bibliothèque Bucket4j, qui implémente le token bucket.

Pour une application Next.js, la limite se pose généralement dans le middleware ou dans les routes d'API. Comme ces applications tournent souvent sur plusieurs instances ou en fonctions serverless, le compteur ne peut pas vivre dans la mémoire d'un seul processus. Il faut un stockage partagé.

Avec Redis pour partager les compteurs

Redis est la solution la plus courante pour ce stockage. Cette base en mémoire est très rapide et propose des commandes atomiques, comme INCR, ainsi qu'une expiration automatique des clés. Toutes les instances de l'application lisent et écrivent le même compteur, ce qui garantit une limite cohérente quel que soit le serveur qui répond.

C'est aussi la configuration que nous retenons le plus souvent lors d'une création de logiciel sur mesure avec une API exposée à des partenaires. La limite est alors définie par clé d'API, avec des paliers différents selon le niveau d'abonnement du client.

Les erreurs courantes à éviter

Un rate limiting mal réglé peut faire plus de dégâts qu'il n'en évite. Le risque principal est de bloquer de vrais clients, parfois sans que personne s'en aperçoive. Voici les pièges que nous rencontrons le plus souvent lors d'audits.

Fixer une limite sans regarder le trafic réel

Choisir un seuil au hasard est la première erreur. Avant de régler quoi que ce soit, il faut observer combien de requêtes un visiteur normal envoie sur une page donnée. Les logs serveur donnent cette information. Une page produit riche peut déclencher des dizaines d'appels légitimes, et une limite trop basse casserait l'affichage.

Identifier les clients uniquement par l'IP

Plusieurs personnes peuvent partager la même adresse IP : salariés d'une même entreprise, clients d'un opérateur mobile, visiteurs passant par un VPN. Une limite par IP trop stricte risque alors de bloquer tout un bureau à cause d'un seul collègue. Quand c'est possible, mieux vaut s'appuyer sur le compte connecté ou la clé d'API.

Oublier de prévenir le client

Renvoyer une page blanche ou une erreur 500 au lieu d'un 429 propre empêche le client de comprendre ce qui se passe. Un message clair, l'en-tête Retry-After et, pour une API, les en-têtes X-RateLimit permettent aux développeurs d'adapter leur code. Côté visiteur, une page explicative évite un appel agacé au service client.

Bloquer les robots utiles

Googlebot et les robots des moteurs d'IA explorent votre site pour l'indexer. Les freiner trop durement peut ralentir la prise en compte de vos nouvelles pages. Les CDN proposent en général une liste de robots vérifiés à traiter à part. Gardez un œil sur la Search Console après toute nouvelle règle.

Ne pas gérer les limites des services que vous consommez

Votre application appelle peut-être une API de paiement, de cartographie ou d'IA. Si elle ne gère pas les réponses 429 de ces services, une simple surcharge chez eux devient une panne chez vous. La bonne pratique consiste à réessayer avec un délai croissant, ce qu'on appelle le backoff exponentiel, et à mettre en cache les réponses qui changent peu.

• Mesurer le trafic normal avant de fixer un seuil.
• Préférer l'identifiant du compte à l'adresse IP quand c'est possible.
• Renvoyer un 429 avec Retry-After, jamais une erreur générique.
• Exclure ou traiter à part les robots des moteurs de recherche.
• Prévoir des réessais espacés face aux quotas des API tierces.

Ressources pour aller plus loin

Le rate limiting fait partie d'un ensemble de protections plus large. Pour sécuriser les points d'entrée les plus exposés, notre guide pour sécuriser un formulaire de contact complète utilement cet article. La documentation officielle de votre CDN, de Nginx ou de votre framework reste la référence pour la syntaxe exacte, qui évolue au fil des versions.

Questions fréquentes