Qu'est-ce que la limitation de débit ? Guide en langage clair 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 (en général 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 qu'un utilisateur très actif ne ralentisse tout le monde et évite les dépenses qui s'emballent.
Vous rencontrez la limitation de débit de deux côtés : les services que vous appelez limitent vous, et votre propre application doit 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 (modèles d'IA, e-mail, SMS, 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.
- Maîtrise des coûts. Si votre application possède une zone « demander à l'IA » sans limite, un robot peut lui envoyer des milliers de requêtes pendant la nuit. Vous payez chacune d'elles.
- Sécurité. Sans limite sur le formulaire de connexion, un attaquant peut tester des milliers de mots de passe sur un compte. Une limite de quelques tentatives par minute rend cette méthode impraticable.
- Rester en ligne. Un script qui se comporte mal, parfois votre propre code bloqué dans une boucle, peut surcharger votre base de données et faire tomber l'application.
- Respecter les limites des autres services. Quand votre application appelle une API externe trop souvent, c'est vous qui recevez les erreurs 429, et les fonctionnalités tombent en panne pour vos utilisateurs.
Les générateurs d'applications construisent ce que vous demandez. Si vous ne mentionnez pas de limites, elles sont souvent omises.
Une analogie du quotidien
Pensez à la règle de recharge gratuite d'un café : « Une recharge gratuite par client et par visite. »
- Elle n'empêche personne de profiter de son café.
- Elle empêche une personne de rester au comptoir toute la journée à remplir une thermos pour tout le bureau.
- Quand quelqu'un demande une quatrième recharge, le serveur répond poliment « pas pour le moment » : c'est le
429.
Une bonne limite de débit est invisible pour les clients normaux et ne se remarque que chez quelqu'un qui fait quelque chose d'inhabituel.
Comment fonctionne 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 | Les requêtes de qui sont comptées ? | Par compte utilisateur, par adresse IP, par clé d'API |
| Combien | Quelle est la limite ? | 5, 60, 1 000 requêtes |
| Par quelle durée | Sur quelle fenêtre ? | Par seconde, minute, heure, jour |
Quand une requête arrive, l'application vérifie le compteur de ce « qui ». Sous la limite : la requête passe et le compteur augmente. Au-delà : 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 à heure fixe, par exemple chaque minute pile | Simple, mais permet une rafale à la jonction de 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 à rythme constant ; chaque requête consomme un jeton | Autorise de courtes rafales tout en maintenant une moyenne stable |
Les compteurs doivent être stockés quelque part de rapide et partagé. Sur un petit serveur unique, la mémoire suffit. Dès qu'une application tourne sur plusieurs machines, le compteur se trouve en général dans un stockage 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
Quand une requête dépasse la limite, une API bien conçue répond :
- Code de statut
429 Too Many Requests. - Souvent un en-tête
Retry-After, qui indique le nombre de secondes à attendre. - Parfois des en-têtes indiquant votre limite et le nombre de requêtes restantes dans cette fenêtre (les noms varient selon le fournisseur).
Votre application doit réagir à un 429 en attendant puis en réessayant plus tard, idéalement avec un backoff exponentiel : attendre un peu plus longtemps après chaque échec (1 seconde, puis 2, puis 4) plutôt que de marteler le service.
Un exemple concret : un assistant d'écriture par IA
Imaginons une application où les utilisateurs collent un texte et reçoivent une réécriture par l'IA.
Sans limites : quelqu'un écrit un script qui envoie 20 000 requêtes pendant la nuit. Votre facture chez le fournisseur d'IA explose, et votre compte atteint la 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 sur la formule gratuite, 300 sur les formules payantes. Au-delà de la limite, l'utilisateur voit : « Vous avez atteint la limite de cette heure. Réessayez dans 12 minutes, ou passez à une formule supérieure. »
- 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 un 429, votre serveur attend et réessaie une ou deux fois, puis affiche un message aimable « service occupé, réessayez ».
Les limites sont vérifiées côté 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 autorisées dans une fenêtre de temps. |
| Quota | Une allocation plus large, souvent par jour ou par mois, parfois liée à une formule payante. |
| 429 | Le code de statut 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. |
| Backoff exponentiel | Attendre de plus en plus longtemps entre deux tentatives. |
| Rafale (burst) | Un pic court de nombreuses requêtes d'un coup. |
| Attaque par force brute | Essayer un très grand nombre de mots de passe ou de codes jusqu'à trouver le bon. |
Idées reçues courantes
- « La limitation de débit ne concerne que les grosses applications. » Les petites applications sont aussi des cibles, car les robots scrutent tout Internet à la recherche de formulaires ouverts et de points d'accès d'IA. Le coût des abus ne dépend pas de la taille de votre application.
- « Cacher le bouton suffit. » Les limites côté navigateur sont une politesse, 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 dès que les personnes sont connectées.
- « Un 429 signifie que le service est en panne. » Cela 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 peu souvent. 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 bugs ; le plafond de dépenses du fournisseur est votre filet de sécurité.
Quoi demander à votre générateur d'applications IA
- « Ajoute une limitation de débit côté serveur sur la connexion, l'inscription, la réinitialisation du mot de passe et le point d'accès à l'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. »
- « Quand une API externe renvoie un 429, réessaie avec un backoff exponentiel jusqu'à 3 fois, puis affiche une erreur conviviale. »
- « Où sont stockés les compteurs de limitation ? Fonctionneront-ils encore si l'application tourne sur plusieurs machines ? »
- « Journalise chaque fois qu'un utilisateur ou une adresse IP atteint une limite, pour 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 directe à ce sujet pour les fonctionnalités d'IA : les limites de débit, la sécurité et les contrôles de coûts des applications que vous créez vous appartiennent et sont à concevoir par vous. Voir Créer une application d'IA. Demandez à l'agent d'ajouter des limites dans le même message que celui où vous demandez la fonctionnalité. Sur l'offre Pro, un service publié peut tourner 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 complémentaires : qu'est-ce qu'une API, comment utiliser les API de LLM et la liste de contrôle 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 envoyer sur une période donnée, par exemple 5 tentatives de connexion par minute ou 100 appels d'API par heure. Les requêtes qui dépassent la limite sont refusées jusqu'à la réinitialisation de la fenêtre.
Que signifie l'erreur 429 Too Many Requests ?
Le code de statut HTTP 429 indique 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 : ralentir, réessayer après une pause, ou réduire la fréquence des appels de votre application vers le service.
Pourquoi mon application qui utilise l'IA a-t-elle besoin d'une limitation de débit ?
Chaque requête d'IA vous coûte de l'argent en tokens. Sans limite, un utilisateur ou un robot peut envoyer des milliers de requêtes, faire exploser votre facture ou épuiser votre quota chez le fournisseur, et rendre la fonctionnalité indisponible pour tout le monde. Des limites par utilisateur gardent les coûts prévisibles.
La limitation de débit, est-ce la même chose que le throttling ?
Les deux notions sont très proches et souvent utilisées l'une pour l'autre. La limitation de débit consiste en général à rejeter les requêtes au-delà d'une limite, alors que le throttling peut aussi signifier les ralentir ou les mettre en file d'attente plutôt que de les refuser directement.
La limitation de débit protège-t-elle contre les attaques DDoS ?
Elle aide contre les petites vagues de trafic et les abus venant d'utilisateurs ou d'adresses IP isolés, mais une attaque distribuée de grande ampleur vient de nombreuses adresses à la fois. La protection contre ce type d'attaque se situe en général au niveau du réseau ou du CDN, avant que le trafic n'atteigne votre application.