Limitation du Débit d'API

La limitation du débit est mise en œuvre via plusieurs algorithmes, chacun avec des compromis différents. Fenêtre Fixe (Fixed Window) : compte les requêtes par fenêtre définie (par exemple, 1 000 requêtes par heure). Simple mais vulnérable aux pics de trafic aux limites de la fenêtre. Fenêtre Glissante (Sliding Window) : une fenêtre de temps glissante (par exemple, 1 000 requêtes sur toute période de 60 minutes) élimine les pics aux limites. Seau à Jetons (Token Bucket) : les clients accumulent des "jetons" à un rythme constant jusqu'à un maximum, et chaque requête coûte un jeton. Permet un trafic en rafale jusqu'à la taille du seau tout en imposant des limites moyennes soutenues — le plus proche des modèles d'utilisation réels. Seau Perforé (Leaky Bucket) : traite les requêtes à un rythme fixe, mettant en file d'attente les requêtes excédentaires — lisse complètement le trafic mais introduit de la latence pendant les rafales. La plupart des plateformes SaaS utilisent le Seau à Jetons ou la Fenêtre Glissante car ils équilibrent la flexibilité pour les modèles d'utilisation légitimes en rafale avec une protection contre les abus soutenus ou le code incontrôlable.

Les erreurs de limite de débit (HTTP 429 "Too Many Requests") sont fréquemment diagnostiquées à tort comme des bugs plutôt que comme un comportement API attendu. Le support doit : d'abord vérifier que le client dépasse réellement la limite de débit de son plan (vérifier les données d'utilisation de l'API dans le tableau de bord d'administration) ; informer sur la réponse 429 et son en-tête retry-after (la réponse API inclut le temps avant que la prochaine requête ne soit acceptée — les clients corrects devraient implémenter un "exponential backoff" lorsqu'ils reçoivent des 429 plutôt que de réessayer immédiatement) ; enquêter si l'implémentation du client gère correctement les limites de débit (de nombreux bugs d'intégration proviennent de boucles de réessai infinies qui aggravent le problème de limite de débit) ; déterminer si le client a un besoin légitime d'une limite de débit plus élevée (un client d'entreprise dont le cas d'utilisation nécessite un débit plus élevé peut justifier une limite personnalisée ou une mise à niveau de plan) ; et documenter systématiquement les questions de limite de débit pour déterminer si les limites au niveau du plan sont appropriées ou nécessitent un ajustement.

Les limites de débit sont une décision de conception produit et commerciale, pas seulement une contrainte technique. Les Product Ops devraient s'assurer que les limites de débit sont : documentées explicitement dans la référence API publique (y compris les limites par endpoint, pas seulement les limites globales) ; différenciées par niveau de tarification (les clients des plans supérieurs reçoivent des limites plus élevées — cela crée un avantage concret et tangible aux mises à niveau) ; affichées en temps réel via un tableau de bord d'utilisation dans le produit (les clients devraient pouvoir voir leur consommation actuelle par rapport à leur limite, avec des alertes avant d'atteindre le plafond) ; et accompagnées d'un chemin de mise à niveau clair (une bannière ou un e-mail déclenché lorsqu'un client atteint 80% de sa limite de débit les dirige vers une mise à niveau plutôt que de simplement échouer avec des 429). Les mises à niveau basées sur les limites de débit sont un moteur de revenus d'expansion mesurable que les Product Ops suivent aux côtés d'autres déclencheurs d'expansion.