Le rate limiting : pourquoi un site vous dit « trop de requêtes »

Le rate limiting (limitation de débit) consiste à fixer un nombre maximum de demandes qu'un visiteur, un compte ou un programme peut envoyer en un temps donné. Au-delà, le site répond « trop de requêtes » et demande d'attendre. Ce n'est pas une panne : c'est une protection.

L'analogie : la porte de la boîte de nuit

Un videur laisse entrer les gens par petits groupes. Ce n'est pas pour embêter ceux qui attendent : si tout le monde se ruait à l'intérieur d'un coup, la salle ne pourrait plus fonctionner. Le rate limiting, c'est ce videur, posté devant votre application.

Ce que ça protège

• Les mots de passe. Sans limite, quelqu'un peut essayer des milliers de combinaisons sur une page de connexion. Avec une limite, il est stoppé après quelques essais. C'est un complément au hachage des mots de passe, qui protège ce qui est stocké, là où le rate limiting protège la porte d'entrée.
• Le serveur. Un programme mal écrit, un utilisateur trop pressé ou une attaque qui envoie un flot de demandes peuvent saturer l'application et la rendre lente pour tous.
• Les coûts. Chaque demande a un coût, et certaines, comme celles qui font appel à un service payant à l'usage, peuvent vite peser.
• L'équité. Un seul gros utilisateur ne doit pas prendre toute la place des autres.

Comment ça marche

L'application compte les demandes reçues pendant une période, par exemple par minute, pour une identité : une adresse IP, un compte, une clé d'accès. Quand le compteur dépasse la limite, les demandes suivantes sont refusées. Le refus porte en général le code 429 (« Too Many Requests »), parfois accompagné d'une indication du temps à attendre. Quand la période s'écoule, le compteur repart de zéro.

Les limites varient selon l'endroit : plus strictes sur la connexion ou la réinitialisation d'un mot de passe, plus larges sur la simple lecture de pages.

Ce qui peut mal tourner

• Une limite trop basse bloque de vrais utilisateurs. Plusieurs personnes peuvent partager la même adresse (un bureau, une école) : limiter par adresse seulement, c'est parfois les punir ensemble.
• Une limite absente laisse la porte ouverte.
• Une réponse mal gérée : si votre propre application appelle une API qui répond 429, elle doit attendre puis réessayer calmement, pas insister à toute vitesse. Une file d'attente est un bon moyen d'espacer ces appels.

À retenir

Le rate limiting borne le nombre de demandes par identité et par période. Il protège les connexions, le serveur et les coûts, à condition de choisir des limites adaptées à chaque usage.

Et pour votre produit ?

Une application sans limite sur sa page de connexion ou sur ses endpoints les plus coûteux est un oubli courant, surtout dans un code généré rapidement. Un audit de votre application permet de voir où des limites manquent. Nous pouvons en discuter lors d'un échange de 30 minutes.