La limitation de débit dans les API d'IA opère sur plusieurs dimensions simultanément, et comprendre chacune d'elles évite beaucoup de frustration. La plupart des fournisseurs imposent au moins deux limites : les requêtes par minute (RPM) et les tokens par minute (TPM). Le RPM plafonne le nombre d'appels API que vous pouvez faire, quelle que soit leur taille — le palier gratuit d'Anthropic pourrait autoriser 5 RPM, tandis que les paliers payants offrent plus de 1 000 RPM. Le TPM plafonne le volume total de tokens (entrée + sortie) transitant par minute. Vous pouvez atteindre l'une ou l'autre limite indépendamment. Une surprise courante : vous êtes bien en dessous de votre limite RPM mais atteignez le TPM parce que vous envoyez de longs prompts avec de grandes fenêtres de contexte. Certains fournisseurs imposent aussi des requêtes par jour (RPD) et des tokens par jour (TPD), créant un plafond quotidien qui se réinitialise à minuit UTC.
Les mécanismes d'application de ces limites par les fournisseurs suivent quelques patrons standards. Le plus courant est l'algorithme du seau à jetons (ou son proche cousin, la fenêtre glissante). Imaginez un seau qui contient, disons, 60 jetons de capacité. Il se remplit au rythme d'un par seconde. Chaque requête puise dans le seau proportionnellement à son nombre de tokens. Si le seau est vide, votre requête est rejetée avec un HTTP 429 (Too Many Requests). Les en-têtes de réponse vous disent ce que vous devez savoir : x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests, et leurs équivalents pour les tokens. Un code client intelligent lit ces en-têtes de manière proactive plutôt que d'attendre de recevoir un 429. Anthropic, OpenAI et la plupart des autres fournisseurs incluent ces en-têtes dans chaque réponse.
Quand vous êtes effectivement limité, l'approche standard est le backoff exponentiel avec gigue. Attendez 1 seconde après le premier 429, puis 2 secondes, puis 4, puis 8 — et ajoutez une composante aléatoire (gigue) pour que si 50 de vos workers parallèles ont tous reçu un 429 en même temps, ils ne retentent pas tous au même moment exact et ne se fassent pas immédiatement bloquer à nouveau. La plupart des SDK de fournisseurs (le SDK Python d'Anthropic, le SDK d'OpenAI) gèrent automatiquement la logique de base des nouvelles tentatives, mais les systèmes en production nécessitent généralement des approches plus sophistiquées : des files de requêtes avec des niveaux de priorité, une limitation de débit adaptative qui ralentit proactivement en fonction du quota restant, et des disjoncteurs qui échouent rapidement quand un fournisseur est clairement surchargé plutôt que d'empiler davantage de tentatives.
Les implications stratégiques des limites de débit façonnent l'architecture des applications sérieuses. Si vous devez traiter 100 000 documents avec Claude, vous ne pouvez pas simplement lancer 100 000 appels API simultanés. Vous devez gérer la concurrence, en exécutant probablement 20 à 50 requêtes parallèles alimentées depuis une file d'attente. Anthropic offre une API Batch avec une limite de débit séparée et plus élevée à 50 % de réduction — spécifiquement conçue pour ce cas d'utilisation. OpenAI a un endpoint batch similaire. Pour les applications nécessitant une capacité garantie, les paliers entreprise et les engagements d'utilisation offrent un débit dédié, isolé du pool partagé. La réalité implicite est que les limites de débit ne concernent pas seulement l'équité — elles concernent l'allocation de GPU. Chaque requête que vous faites nécessite du temps GPU, et les fournisseurs ne peuvent servir qu'autant de requêtes simultanées qu'ils ont de GPU. Les limites de débit sont le mécanisme qui maintient l'équilibre entre l'offre et la demande.