Limite de débit

Les fournisseurs posent des limites pour des raisons simples. La capacité est finie et partagée : un script fou ne doit pas ralentir tout le monde. Les limites contiennent aussi le coût et freinent les abus, comme une clé volée qui servirait à inonder un service. Sans elles, un bogue dans une boucle pourrait envoyer des milliers d’appels en une minute. Pense à une boulangerie qui sert une file : laisser un seul client acheter tous les pains dès la première minute est injuste pour les autres, alors le boulanger plafonne chacun, et une bonne limite n’est qu’une part équitable écrite en chiffre.

Les limites prennent plusieurs formes. Une courte limite par minute absorbe les rafales. Une plus longue, par jour, borne l’usage total, soit en fenêtre fixe qui repart à heure fixe, soit en fenêtre glissante qui regarde toujours la période écoulée. Certains services comptent les requêtes, d’autres les jetons, et certains plafonnent aussi le nombre d’appels simultanés. Les limites dépendent souvent de l’offre : un palier supérieur obtient un plafond plus haut.

Bien gérer une limite est un petit savoir-faire. Lis l’en-tête Retry-After quand il est présent et attends ce délai. Sinon, réessaie avec un recul exponentiel et un peu de hasard, jamais en boucle serrée. Réduis le nombre d’appels en mettant les réponses en cache et en regroupant le travail, et étale la charge dans le temps. Et souviens-toi qu’une limite de débit n’est pas une limite de dépense : un solde épuisé est une autre erreur, dont le remède diffère. Les bibliothèques encapsulent souvent cette logique pour toi, en réessayant poliment avec des pauses ; quand tu écris ton propre client, note chaque 429 avec son horodatage pour voir si ce sont des rafales ou une charge soutenue qui le provoquent.

La documentation de l’API NeverNo fixe la règle. Chaque compte dispose d’un nombre de requêtes API par période glissante de 24 heures, selon son offre. Au-delà, les appels reçoivent une erreur 429 de code rate_limited jusqu’à ce que la fenêtre avance. Une courte limite par minute s’applique aussi, et le 429 s’accompagne alors d’un en-tête Retry-After. Chaque appel compte pour une requête, quel que soit le nombre de jetons ou d’images, tandis que le point d’accès qui compte les jetons ne compte pas. Comme la fenêtre est glissante, la capacité revient peu à peu à mesure que les anciens appels vieillissent, et non d’un coup à minuit.

Les chiffres exacts par offre sont dans le tableau de la documentation de l’API, et nous ne les répétons pas ici pour que cette page ne devienne jamais périmée. Manquer de crédits est un autre cas : l’API répond 402 avec insufficient_credits. L’abonnement Dev reprend la limite de requêtes de Pro+. Comme la documentation est la source unique des chiffres, un script devrait y lire le plafond plutôt que de le deviner, et traiter une hausse soudaine des erreurs 429 comme un signal pour ralentir et mettre son travail en file.