osFoundry / Platform
Rate limiting d'application publique
Limites de débit ajustables par IP et par token sur les applications publiques. Valeurs par défaut qui encaissent le pic.
Présentation
La limitation de débit des apps publiques d'osFoundry place un régulateur configurable devant toute app que vous exposez publiquement. Vous fixez les limites de deux façons complémentaires : par IP, qui plafonne le nombre de requêtes qu'une même adresse cliente peut émettre dans une fenêtre de temps, et par token, qui plafonne l'usage lié à un jeton d'accès ou une clé d'API précise. La limite par IP émousse un déferlement venu d'une seule source ; la limite par token empêche qu'une identifiant partagé ou fuité ne s'empare de votre quota. Comme osFoundry fonctionne avec vos propres clés (BYOK), les requêtes que votre app publique répartit vers les modèles finissent par consommer des clés qui vous appartiennent : un endpoint sans limites n'est donc pas qu'un problème de charge, c'est aussi un problème de facturation. Les limites de débit sont la frontière qui empêche un pic de se transformer en mauvaise surprise sur la facture de votre fournisseur.
Au sein d'osFoundry, cela vit dans la couche Apps & Backend, aux côtés du reste des mécanismes qui empaquettent et exposent une app. Quand vous rendez une app publique, les limites sont déjà actives avec des valeurs par défaut choisies pour survivre à l'afflux soudain, ce moment où un lien est largement partagé et où le trafic arrive plus vite que prévu. Plutôt que de s'effondrer ou de vider une clé, les requêtes en excès sont refusées en périphérie afin que le trafic légitime continue de circuler. À partir de là, chaque limite est ajustable : relevez le plafond d'une app que vous attendez très fréquentée, resserrez-le sur quelque chose d'expérimental, ou définissez des limites par token par identifiant pour que chaque consommateur reçoive un budget distinct.
Cela compte parce qu'une app d'IA publique présente une surface de coût que la plupart des sites statiques n'ont pas. Une seule URL partagée, un scraper ou un client emballé peut générer des milliers d'appels de modèle en quelques minutes. Les limites par IP et par token vous donnent un pire cas prévisible : vous décidez de la dépense et de la charge maximales que votre app peut encaisser avant de commencer à dire non. Associées au modèle local-first d'osFoundry sans marge de revente, vous gardez vos clés, vos données, et désormais aussi l'exposition des endpoints derrière lesquels ces clés se trouvent.
Fonctionnalités clés
- Fixez des limites de requêtes par IP pour plafonner le volume qu'une même adresse cliente peut envoyer à une app publique dans une fenêtre donnée
- Fixez des limites par token pour qu'un jeton d'accès ou une clé d'API précise dispose de son propre budget d'usage, indépendamment de l'IP source
- Livré avec des valeurs par défaut calibrées pour absorber l'afflux soudain, un pic de trafic dû à un lien partagé, sans aucune configuration manuelle
- Refuse les requêtes en excès en périphérie pour qu'un déferlement ne vide pas les clés BYOK du fournisseur sur lesquelles votre app consomme
- Ajustez chaque plafond à la hausse ou à la baisse, par app et par identifiant, à mesure que le trafic réel de l'app se dessine
Cas d’usage
- Développeur indépendant : partage un lien de démo public qui devient viral sans prévenir et s'appuie sur les limites par défaut pour le garder en ligne au lieu de brûler une clé d'API en une nuit
- Responsable d'équipe : émet des jetons d'accès distincts pour ses partenaires et fixe un budget par token sur chacun, afin qu'une intégration n'affame pas les autres
- Développeur orienté ops : resserre les limites par IP sur un endpoint expérimental pour borner le coût et la charge du pire cas avant de le promouvoir en production
Questions fréquentes
Quelle est la différence entre limites de débit par IP et par token ?
Par IP plafonne les requêtes d'une même adresse cliente, ce qui stoppe un déferlement venu d'une seule source. Par token plafonne l'usage lié à un jeton d'accès ou une clé d'API précise, quel que soit l'endroit d'où il est appelé, ce qui contient un identifiant partagé ou fuité. Vous pouvez utiliser les deux à la fois : par IP pour le trafic public anonyme, par token pour donner à des consommateurs nommés leurs propres budgets.
Que se passe-t-il si mon app publique reçoit soudain beaucoup de trafic ?
Les apps publiques sont livrées avec des limites par défaut choisies pour gérer l'afflux soudain : un lien partagé bien plus loin que prévu. Les requêtes au-delà de la limite sont refusées plutôt que transmises, si bien qu'un pic ne peut ni vider la clé du fournisseur sur laquelle votre app consomme, ni faire tomber l'app. Vous pouvez relever les limites pour les apps que vous attendez très fréquentées.
Dois-je configurer les limites de débit avant de rendre une app publique ?
Non. Des valeurs par défaut sensées sont déjà en place dès que vous rendez une app publique, vous êtes donc protégé sans aucune configuration. Tout est ajustable quand vous le souhaitez : relevez ou abaissez le plafond par IP, ou définissez des limites par token par identifiant, mais la base sûre est active dès le départ.