Qu'est-ce que la limitation de débit? Un guide en langage simple pour les créateurs d'applications
La limitation de débit est une règle qui plafonne le nombre de requêtes qu'une personne peut envoyer à un système pendant une durée donnée, par exemple 5 tentatives de connexion par minute ou 100 appels d'API par heure. Une fois la limite atteinte, les requêtes suivantes sont refusées (généralement avec le code d'erreur 429 Too Many Requests) jusqu'à la réinitialisation de la fenêtre de temps. Elle protège les applications contre les abus, empêche un utilisateur très actif de ralentir tout le monde et évite les dépenses incontrôlées.
Vous rencontrez la limitation de débit de deux côtés : les services que vous appelez vous limitent, et votre propre application devrait limiter ses utilisateurs.
Pourquoi la limitation de débit compte quand on crée avec l'IA
Les applications créées avec l'IA se connectent souvent à des services payants, comme les modèles d'IA, les courriels, les SMS ou les cartes, et chaque appel coûte de l'argent. La limitation de débit est donc à la fois une fonctionnalité de sécurité et un outil de contrôle budgétaire.
- Contrôle des coûts. Si votre application comporte une case « demander à l'IA » sans limite, un robot peut lui envoyer des milliers de requêtes pendant la nuit. Vous payez pour chacune d'elles.
- Sécurité. Sans limite sur le formulaire de connexion, un attaquant peut essayer des milliers de mots de passe sur un compte. Une limite de quelques tentatives par minute rend cela impraticable.
- Rester en ligne. Un seul script défaillant, parfois votre propre code coincé dans une boucle, peut surcharger votre base de données et faire tomber l'application.
- Respecter les limites des autres services. Si votre application appelle une API externe trop souvent, c'est vous qui recevez les erreurs 429, et les fonctionnalités cessent de fonctionner pour vos utilisateurs.
Les générateurs d'applications construisent ce que vous demandez. Si vous ne mentionnez pas les limites, elles sont souvent omises.
Une analogie du quotidien
Pensez à la politique de recharge gratuite d'un café : « Une recharge gratuite par client et par visite. »
- Cela n'empêche personne de profiter de son café.
- Cela empêche une personne de rester au comptoir toute la journée à remplir une thermos pour tout le bureau.
- Lorsqu'une personne demande une quatrième recharge, le barista répond poliment « pas pour le moment » : c'est le
429.
Une bonne limite de débit est invisible pour les clients ordinaires et ne se remarque que chez quelqu'un qui fait quelque chose d'inhabituel.
Fonctionnement de la limitation de débit
Un limiteur de débit a besoin de trois éléments :
| Élément | Question à laquelle il répond | Exemples |
|---|---|---|
| Qui | Quelles requêtes compte-t-on? | Par compte utilisateur, par adresse IP, par clé d'API |
| Combien | Quelle est la limite? | 5, 60, 1 000 requêtes |
| Par quelle période | Sur quelle fenêtre? | Par seconde, minute, heure, jour |
Lorsqu'une requête arrive, l'application vérifie le compte de ce « qui ». Sous la limite : la requête passe et le compteur augmente. Au-delà de la limite : la requête est refusée.
Il existe quelques méthodes courantes de comptage :
| Méthode | Fonctionnement | Compromis |
|---|---|---|
| Fenêtre fixe | Le compteur se réinitialise à l'horloge, par exemple chaque minute pile | Simple, mais permet une rafale à la limite entre deux fenêtres |
| Fenêtre glissante | Regarde les 60 dernières secondes à partir de maintenant | Plus régulier, calcul légèrement plus lourd |
| Seau à jetons (token bucket) | Chaque utilisateur dispose d'un seau qui se remplit à un rythme constant; chaque requête prend un jeton | Permet de courtes rafales tout en maintenant la moyenne stable |
Les compteurs doivent être stockés à un endroit rapide et partagé. Sur un petit serveur unique, la mémoire suffit. Lorsqu'une application s'exécute sur plusieurs machines, le compteur se trouve généralement dans un magasin partagé comme Redis ou la base de données; sinon, chaque machine compte de son côté et la limite réelle devient plusieurs fois plus élevée.
À quoi ressemble une réponse limitée
Lorsqu'une requête dépasse la limite, une API bien conçue répond avec :
- Le code d'état
429 Too Many Requests. - Souvent un en-tête
Retry-After, qui indique le nombre de secondes à attendre. - Parfois des en-têtes montrant votre limite et le nombre de requêtes restantes dans cette fenêtre (les noms varient selon le fournisseur).
Votre application doit réagir à une erreur 429 en attendant puis en réessayant plus tard, idéalement avec un recul exponentiel, c'est-à-dire en attendant un peu plus longtemps après chaque échec (1 seconde, puis 2, puis 4) plutôt que de marteler le service.
Exemple concret : un assistant d'écriture par IA
Supposons que vous ayez créé une application où les utilisateurs collent du texte et obtiennent une réécriture par IA.
Sans limites : quelqu'un écrit un script qui envoie 20 000 requêtes pendant la nuit. La facture de votre fournisseur d'IA grimpe, et votre compte atteint la propre limite de débit du fournisseur; les vrais utilisateurs voient donc des erreurs toute la matinée.
Avec des limites raisonnables :
- Par utilisateur connecté : 30 réécritures par heure dans le forfait gratuit, 300 dans les forfaits payants. Au-delà de la limite, l'utilisateur voit : « Vous avez atteint la limite de cette heure. Réessayez dans 12 minutes, ou passez à un forfait supérieur. »
- Par adresse IP sur le formulaire d'inscription : 5 inscriptions par heure, pour empêcher les robots de créer des milliers de comptes gratuits afin de contourner la limite par utilisateur.
- Un plafond de dépenses défini dans le tableau de bord de votre fournisseur d'IA, comme dernier rempart si tout le reste échoue.
- Gérer les limites du fournisseur : si le fournisseur d'IA renvoie une erreur 429, votre serveur attend et réessaie une ou deux fois, puis affiche un message convivial du type « Service occupé, veuillez réessayer ».
Les limites sont vérifiées sur le serveur. Une limite qui n'existe que dans le navigateur (par exemple désactiver le bouton après 30 clics) peut être contournée par quiconque appelle directement votre API.
Termes clés
| Terme | Signification |
|---|---|
| Limite de débit (rate limit) | Le nombre maximal de requêtes permises dans une fenêtre de temps. |
| Quota | Une allocation plus large, souvent par jour ou par mois, parfois liée à un forfait payant. |
| 429 | Le code d'état HTTP signifiant « trop de requêtes ». |
| Retry-After | Un en-tête de réponse indiquant combien de temps attendre avant de réessayer. |
| Throttling | Ralentir ou refuser les requêtes au-delà d'une limite. Souvent utilisé comme synonyme. |
| Recul exponentiel (exponential backoff) | Attendre de plus en plus longtemps entre les tentatives. |
| Rafale (burst) | Une brève poussée de nombreuses requêtes à la fois. |
| Attaque par force brute | Tester un très grand nombre de mots de passe ou de codes jusqu'à ce que l'un fonctionne. |
Idées fausses courantes
- « La limitation de débit ne sert que pour les grandes applications. » Les petites applications sont aussi des cibles, car les robots scrutent tout Internet à la recherche de formulaires et de points d'accès d'IA ouverts. Le coût d'un abus ne dépend pas de la taille de votre application.
- « Cacher le bouton suffit. » Les limites côté navigateur sont une simple courtoisie, pas une protection. Les vraies limites doivent être appliquées sur le serveur.
- « Les limites par adresse IP sont toujours équitables. » Beaucoup de personnes peuvent partager une même adresse IP : un bureau, une école, un réseau mobile. Les limites par utilisateur sont plus justes une fois les personnes connectées.
- « Une erreur 429 signifie que le service est en panne. » Elle signifie que vous l'appelez trop souvent. Vérifiez votre code pour détecter les boucles, et mettez en cache les résultats qui changent rarement; voir qu'est-ce que la mise en cache.
- « La limitation de débit remplace un plafond de dépenses. » Utilisez les deux. Les limites de votre application peuvent contenir des bogues; le plafond de dépenses du fournisseur est votre filet de sécurité.
Quoi demander à votre générateur d'applications
- « Ajoute une limitation de débit côté serveur à la connexion, à l'inscription, à la réinitialisation du mot de passe et au point d'accès d'IA. Propose des limites raisonnables. »
- « Limite chaque utilisateur connecté à [N] requêtes d'IA par heure, et affiche un message clair avec le temps d'attente lorsqu'il atteint la limite. »
- « Lorsqu'une API externe renvoie une erreur 429, réessaie avec un recul exponentiel jusqu'à 3 fois, puis affiche une erreur conviviale. »
- « Où les compteurs de limite sont-ils stockés? Fonctionneront-ils encore si l'application s'exécute sur plusieurs machines? »
- « Consigne chaque fois qu'un utilisateur ou une adresse IP atteint une limite, afin que je puisse repérer les abus. »
- « Quels services externes cette application appelle-t-elle, et quelles sont leurs limites de débit? »
La limitation de débit dans Mythex
La documentation de Mythex est claire à ce sujet pour les fonctionnalités d'IA : les limites de débit, de sécurité et de contrôle des coûts dans les applications que vous créez vous appartiennent et relèvent de votre conception; voir Créer une application d'IA. Demandez à l'agent d'ajouter des limites dans le même message où vous demandez la fonctionnalité. Avec le forfait Pro, un service publié peut fonctionner sur jusqu'à trois machines lorsque le trafic est élevé (voir Limites d'hébergement); demandez donc des compteurs stockés dans la base de données plutôt que dans la mémoire d'un seul serveur.
Lectures connexes : qu'est-ce qu'une API, comment utiliser les API de LLM et la liste de vérification de sécurité pour les applications créées avec l'IA.
Questions
Qu'est-ce que la limitation de débit, en termes simples?
La limitation de débit est une règle qui plafonne le nombre de requêtes qu'un utilisateur, un appareil ou une application peut faire pendant une période donnée, par exemple 5 tentatives de connexion par minute ou 100 appels d'API par heure. Les requêtes au-delà de la limite sont refusées jusqu'à la réinitialisation de la fenêtre.
Que signifie une erreur 429 Too Many Requests?
Le code d'état HTTP 429 signifie que vous avez envoyé trop de requêtes en trop peu de temps et que vous avez atteint une limite de débit. La réponse contient souvent un en-tête Retry-After qui indique combien de temps attendre. La solution consiste à ralentir, à réessayer après une pause ou à réduire la fréquence des appels de votre application au service.
Pourquoi mon application propulsée par l'IA a-t-elle besoin d'une limitation de débit?
Chaque requête d'IA vous coûte de l'argent en jetons. Sans limite, un seul utilisateur ou un robot peut envoyer des milliers de requêtes, faire grimper la facture ou épuiser le quota de votre fournisseur, et rendre la fonctionnalité inaccessible à tout le monde. Des limites par utilisateur gardent les coûts prévisibles.
La limitation de débit est-elle la même chose que le throttling?
Les deux notions sont étroitement liées et souvent utilisées l'une pour l'autre. La limitation de débit consiste généralement à rejeter les requêtes au-delà d'une limite, tandis que le throttling peut aussi signifier les ralentir ou les mettre en file d'attente au lieu de les refuser complètement.
La limitation de débit arrête-t-elle les attaques DDoS?
Elle aide contre les petites inondations de requêtes et les abus provenant d'utilisateurs ou d'adresses IP individuels, mais une grande attaque distribuée vient de nombreuses adresses à la fois. La protection contre ces attaques se fait généralement au niveau du réseau ou du CDN, avant que le trafic n'atteigne votre application.