Pare-feu, limites de débit et pages d'erreur

Cette page rassemble ce qui protège un projet à l'entrée et ce que voit un visiteur quand une requête est refusée : le budget de requêtes que l'edge applique à chaque projet, les limites d'une requête, les limites de débit de l'API pour vos jetons, et les pages d'erreur que vous pouvez personnaliser. Elle dit aussi ce qui n'est pas encore disponible.

Le pare-feu applicatif

Un pare-feu applicatif par projet, réglé par vous (règles de blocage, limitation de débit par chemin, listes d'adresses), est prévu par l'opération firewall.configure. Il n'est pas encore disponible : l'opération est déclarée au registre, mais aucune implémentation ne lui répond aujourd'hui, et la route rend 404. Elle est déclarée au rang Propriétaire et fermée aux agents, quelle que soit leur portée.

En attendant, un projet est protégé par les mécanismes ci-dessous, qui ne demandent aucun réglage. Pour restreindre l'accès à une prévisualisation (mot de passe, membres du projet, liste d'adresses IP), voir Prévisualisations.

Le budget de requêtes du projet

L'edge tient, pour chaque projet, un budget de requêtes déduit de son palier. Toutes les routes du projet le partagent : sa production, ses prévisualisations et les adresses de ses déploiements.

Une rafale passe à pleine vitesse ; au-delà, l'edge répond 429 sans que votre application voie la requête. Le refus porte Retry-After: 1 et les en-têtes RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset et RateLimit-Policy. Une requête refusée ne consomme rien : un flot de requêtes refusées ne retarde pas le retour du service.

Ce budget est appliqué avant tout le reste : la protection des prévisualisations, les règles de routage, le cache et l'application. Un projet pris dans un pic ne coûte donc rien à ses voisins. Ce n'est pas un quota commercial : les requêtes ne sont facturées à aucun palier.

Le trafic sortant suit une règle voisine : au-delà du débit sortant soutenu du palier (20, 50, 200 et 500 Mb/s), l'edge espace l'envoi sans rien refuser. Voir Limites.

Les limites d'une requête

Ces limites valent pour tout nom servi par la plateforme. Chaque refus est une réponse HTTP qui nomme la limite, en français et en anglais.

Les limites de débit de l'API

L'API compte les appels par jeton, sur une fenêtre de 60 secondes :

Chaque réponse porte RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset (en secondes) et RateLimit-Policy, par exemple 600;w=60, 60;w=60. Au-delà, l'appel est refusé en 429 avec le code rate_limited et un Retry-After. La page de référence de chaque opération indique ses politiques.

Conseil. Un agent qui relit l'état d'un travail long doit espacer ses lectures : task_read ne maintient aucune connexion, et chaque lecture compte dans la politique general.

Les pages d'erreur personnalisées

Quand la plateforme sert elle-même une erreur (application injoignable, délai dépassé, limite de débit, service suspendu), le visiteur voit une page de la plateforme, en français et en anglais. Vous pouvez remplacer son titre et son message pour sept codes.

Une page est un titre (100 caractères au plus) et un message (1 000 caractères au plus), en texte brut, par code et par langue (fr ou en). Un retour à la ligne sépare deux paragraphes du message. Les caractères < et > et les caractères de contrôle sont refusés. L'edge écrit ce texte dans sa propre page, avec sa feuille de style : une page d'erreur ne charge ni script ni ressource externe.

Les pages sont servies par l'edge sans redéploiement, même quand votre application est à l'arrêt. Un code ou une langue que vous ne posez pas garde la page de la plateforme. Une erreur que votre application rend elle-même, avec son propre corps, reste la sienne.

Ne se personnalisent pas : le 403 d'un projet gelé pour abus, qui porte la référence du dossier, et les états qui précèdent tout projet, comme un nom d'hôte inconnu ou un certificat en attente.

Depuis la console

Ouvrez Domaines, puis dépliez Pages d'erreur en bas de l'écran. Chaque code a un titre et un message par langue ; un champ laissé vide garde la page de la plateforme. Enregistrer les pages les met en ligne à la passe suivante de l'edge ; Tout retirer rétablit les pages de la plateforme.

Par la ligne de commande ou l'API

errorpage.configure remplace la liste entière : une page absente de la liste est retirée, et une liste vide les retire toutes. Elle compte 14 pages au plus (sept codes, deux langues), sans doublon.

{
  "projectId": "prj_01JQ8ZK4M7NP2RSTVWXYZ34567",
  "pages": [
    {
      "status": 503,
      "language": "fr",
      "title": "Retour dans un instant",
      "message": "La boutique est en mise à jour.\nRevenez dans quelques minutes."
    },
    {
      "status": 503,
      "language": "en",
      "title": "Back in a moment",
      "message": "The shop is being updated.\nPlease come back in a few minutes."
    }
  ],
  "idempotencyKey": "pages-maintenance-2026-10-23"
}

bastide errorpage read --project-id prj_01JQ8ZK4M7NP2RSTVWXYZ34567
bastide errorpage configure --project-id prj_01JQ8ZK4M7NP2RSTVWXYZ34567 --pages "$(cat pages.json)"

Par l'API : GET et PUT /v1/projects/{projectId}/error-pages sur https://api.bastide.app. Poser des pages demande le rang Mainteneur ; les lire, le rang Lecteur. Ces opérations sont réservées à une personne : elles n'ont pas d'outil MCP et ne s'ouvrent pas aux comptes de service.

Erreurs fréquentes

Voir aussi

• Prévisualisations
• Routage
• Cache et images
• Limites
• Sécurité
• errorpage.configure, firewall.configure

Signaler une erreur sur cette page