Rate limit et quotas

Comment ça marche

Un service d’IA sert des millions d’utilisateurs sur des machines coûteuses et limitées. Pour que personne ne l’écrase, chaque compte a des plafonds : tant de requêtes par minute, tant de tokens par jour, tant de crédits par mois. Dépassé le plafond, le service répond « trop de demandes, réessayez plus tard ». C’est le rate limit.

Dans une interface de chat, ça se traduit par un message d’attente. Dans une automatisation, c’est plus sérieux : un programme qui envoie 500 documents d’un coup en verra 450 refusés. La règle est de lisser les envois, de lire ce que le service indique comme délai, d’attendre, et de réessayer avec des pauses croissantes. Les bonnes bibliothèques le font ; les bricolages, non.

Un exemple concret

1. Première tentative : un script envoie les 3 000 fiches à réécrire en une rafale. Après 60 requêtes, le service refuse tout. Le script s’arrête avec 2 940 fiches non traitées et aucune trace de ce qui a été fait.
2. Deuxième version : le script envoie 50 fiches par minute, enregistre chaque résultat au fur et à mesure, et en cas de refus attend le délai indiqué avant de reprendre là où il s’était arrêté.
3. Troisième version : comme rien n’est urgent, les 3 000 fiches partent en un seul lot via l’API de traitement différé, à moitié prix, avec les résultats le lendemain matin.

La troisième version a demandé une heure de travail de plus et a coûté deux fois moins cher que la deuxième.

Ce que ça change pour une équipe

• Les limites conditionnent l’architecture. Une automatisation qui traite des volumes se conçoit autour des plafonds : rythme, reprise sur erreur, lots.
• Le choix de l’abonnement se fait sur les limites autant que sur le prix. Un plan pas cher avec des plafonds bas coûte en interruptions.
• La visibilité compte. Savoir où l’on en est de ses quotas, recevoir une alerte à 80 %, évite les mauvaises surprises en pleine journée.
• Le traitement par lots devient un réflexe. Tout ce qui peut attendre quelques heures gagne à passer en différé : moins cher, sans contrainte de rythme.

Les limites et les erreurs fréquentes

• Réessayer immédiatement et sans fin. C’est la pire réponse à un refus : elle aggrave la situation et peut faire suspendre le compte. Attendre, puis attendre plus longtemps.
• Ne pas enregistrer la progression. Un traitement interrompu sans trace recommence à zéro et paie deux fois.
• Partager une seule clé entre tout le monde. Les limites s’appliquent par compte ou par clé : une automatisation gourmande peut bloquer les usages de toute l’équipe. Séparer les clés par usage.
• Confondre limite de débit et panne. Un refus pour dépassement se lit dans la réponse du service ; une erreur serveur est autre chose et se gère autrement. Le programme doit distinguer les deux.