Limitation de débit : expliqué simplement.

La limitation de débit (rate limiting) est une technique qui plafonne le nombre de requêtes qu'un client (un utilisateur, une clé API ou une adresse IP) peut envoyer à un serveur sur une fenêtre de temps donnée, et qui rejette ou retarde les requêtes au-delà de ce seuil. Elle protège les API, les formulaires de connexion et les moteurs de recherche interne contre les pics de trafic, le scraping, les tentatives de force brute ou un simple script mal conçu, tout en gardant le service réactif pour les autres utilisateurs. Presque toutes les API publiques appliquent une forme de limitation de débit, que l'appelant s'en rende compte ou non.

Contrairement à une panne subie, la limitation de débit est une frontière volontaire et visible : une API bien conçue indique précisément combien de requêtes il reste à l'appelant et quand le quota se réinitialise, afin que les intégrations légitimes puissent ralentir et réessayer au lieu d'échouer silencieusement. Le principe déborde aussi du cadre des API pures : un formulaire de contact qui bloque un visiteur après dix envois en une minute, ou une barre de recherche qui met en pause l'autocomplétion pendant que l'utilisateur tape encore, appliquent le même principe à plus petite échelle.

Un limiteur de débit garde un compteur par clé client (souvent un jeton API ou une adresse IP) et le compare à un seuil avant de laisser passer une requête. Une réponse HTTP typique une fois le seuil dépassé ressemble à ceci :

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1758880000

Le code de statut 429 signale que la requête était valide mais refusée parce que l'appelant a dépassé son quota ; les en-têtes qui l'accompagnent lui indiquent combien de requêtes il obtient, combien il en reste et quand il peut réessayer. Un client bien conçu lit ces en-têtes et adapte son rythme au lieu de marteler l'API immédiatement après avoir été bloqué. La limitation de débit peut s'appliquer à plusieurs niveaux à la fois : au CDN ou au reverse proxy devant toute la plateforme, à un gateway API par route, et à l'intérieur même de l'application pour des opérations coûteuses comme un export de fichier ou un import massif.

• Fenêtre fixe : compte les requêtes par bloc de temps fixe (par minute, par exemple) ; simple, mais autorise une rafale juste à la frontière entre deux fenêtres.
• Fenêtre glissante : recalcule le compteur sur une période mobile, ce qui lisse le problème de rafale à la frontière d'une fenêtre fixe.
• Token bucket (seau à jetons) : un seau se remplit de jetons à un rythme constant ; chaque requête consomme un jeton, et des rafales sont autorisées tant que des jetons sont disponibles.
• Leaky bucket (seau percé) : les requêtes patientent dans une file et sont traitées à un rythme constant, ce qui lisse entièrement les rafales plutôt que de les autoriser.

Le choix entre ces algorithmes est avant tout un compromis entre simplicité d'implémentation et tolérance aux rafales courtes : un token bucket convient aux API qui attendent des pics occasionnels de jobs batch légitimes, tandis qu'un leaky bucket convient aux systèmes qui doivent garantir un rythme de traitement strictement constant en aval, comme une file de paiement.

• Limiter le débit par une clé pertinente (jeton API ou utilisateur authentifié) plutôt que par la seule IP brute, car de nombreux utilisateurs légitimes peuvent partager une IP derrière un réseau d'entreprise ou un opérateur mobile.
• Renvoyer des réponses 429 claires avec des en-têtes Retry-After plutôt qu'une erreur générique, pour que les applications clientes puissent implémenter un backoff exponentiel automatiquement.
• Fixer des seuils différents par endpoint : une route de connexion ou une barre de recherche a besoin d'une limite plus stricte qu'une requête d'asset statique, car les tentatives de force brute et de scraping s'y concentrent.
• Éviter de fixer des seuils si agressifs qu'ils cassent l'usage normal lors de pics de trafic légitimes (campagne, lancement, retombées presse) ; surveiller et ajuster en fonction des schémas de trafic réels.

Sans limitation de débit, un simple script ou une attaque coordonnée peut épuiser les ressources serveur, faire grimper les coûts d'infrastructure et dégrader l'expérience de tous les autres utilisateurs, dans une situation qui s'apparente à un déni de service auto-infligé. La limitation de débit constitue aussi une première ligne de défense contre les attaques par credential stuffing sur les formulaires de connexion et contre les scrapers qui copient des catalogues produits ou des bibliothèques de contenu entiers. Côté infrastructure, des volumes de requêtes prévisibles rendent la planification de capacité et l'estimation des coûts bien plus fiables, ce qui compte autant pour une petite API SaaS que pour un tunnel d'achat e-commerce à fort trafic pendant une vente saisonnière.

Quand nous développons des API sur mesure, des intégrations ou des pipelines d'automatisation pour nos clients, nous configurons la limitation de débit dès le premier jour, au niveau du gateway API ou de l'application, pour qu'un pic de trafic ou une intégration mal configurée ne fasse jamais tomber tout le système. Nous dimensionnons les seuils à partir de l'usage réel plutôt que de valeurs par défaut arbitraires, et nous fournissons des messages d'erreur clairs et des conseils de retry à nos partenaires d'intégration, pour qu'un pic d'usage légitime soit ralenti en douceur plutôt que de casser une relation client. Voir notre service web apps pour savoir comment nous concevons et sécurisons ces systèmes back-end.