Lancer une API publique : poser les limites avant que les clients arrivent

Un éditeur SaaS ouvre son API aux intégrateurs. Deux semaines plus tard, un partenaire ERP synchronise 200 000 fiches produit en boucle — sans pagination — un week-end. Lundi matin : base PostgreSQL à 100 % CPU, factures Cloud triplées, clients principaux en timeout. La réunion post-mortem révèle qu'il n'y avait ni quota, ni alerte, ni 429 documenté.

Ouvrir une API publique, ce n'est pas exposer des endpoints. C'est accepter que des inconnues contrôleront votre charge — parfois par malice, souvent par erreur d'intégration. Les limites doivent exister avant le premier client, pas après la première panne.

Les quatre garde-fous non négociables

Une API sans 429 est une API qui confond politesse et robustesse. Rejeter proprement protège tout le monde.

Rate limiting : stratégie par tier

Exemple de grille publique :

Implémentation :

• Nginx limit_req_zone pour plafond IP global.
• Redis compteur par api_key pour quotas journaliers.
• Gateway (Traefik, Kong) pour centraliser sans redeploy app.

Répondez en 429 avec Retry-After et corps JSON explicite — pas en laissant le client deviner un timeout TCP.

Pour le détail technique, voir Rate limiting : protéger une API sans punir les bons clients.

Dimensionnement hébergement : la base compte plus que le CPU API

Une requête API « simple » peut coûter :

• 1 SELECT indexé → 2 ms
• 1 SELECT sans index + JOIN → 800 ms × 500 req/s → mort

Checklist infra :

1. Pagination obligatoire (limit max 100, cursor preferred).
2. Cache Redis sur lectures idempotentes (catalogue, référentiels).
3. Pool connexions (PgBouncer) — voir Pool de connexions.
4. Workers séparés sync lourde vs API interactive.
5. Autoscaling sur queue depth, pas seulement CPU.

Mutualisé : non pour API publique sérieuse. VPS minimum ; cloud avec load balancer dès plusieurs clients payants.

Versioning, dépréciation et communication

Limites techniques sans limites produit = dette :

• Préfixe /v1/ figé ; breaking change = /v2/.
• Header Sunset et email 90 jours avant retrait.
• Page statut ou RSS incidents — les intégrateurs ne lisent pas toujoin Slack interne.

Observabilité : métriques qui alertent avant Twitter

• p95/p99 latence par endpoint (pas seulement moyenne).
• Taux 429 par clé — détecte intégration bancale avant saturation.
• Connexions DB actives vs pool max.
• Top consumers : tableau hebdo des clés les plus gourmandes.

Alerte si p95 > SLA interne pendant 5 min ou si une clé dépasse 80 % quota à 14 h.

Le sommet : le pire client est celui qui a signé un contrat

Marketing veut « API ouverte ». Finance veut prévisibilité. L'exploitation doit imposer des murs souples : assez hauts pour les bons usages, assez visibles pour arrêter les erreurs avant la base.

Décider et avancer sans angle mort

1. Publiez limites + exemples 429 avant la première clé.
2. Load-test avec scénario « client qui boucle » (pas seulement happy path).
3. Redis + PgBouncer avant le lancement partenaire.
4. Dashboard top consumers revu chaque semaine le premier mois.
5. Runbook : couper une clé, mode dégradé read-only, communiquer statut.

Comparez VPS et cloud dans notre annuaire et comparateur.

Questions fréquentes

Faut-il un rate limit dès la v1 ?

Oui — même modeste — pour éviter boucles accidentelles et cadrer les quotas tôt.

Où placer le rate limiting ?

Nginx + clé API minimum ; gateway pour politiques avancées ; code pour règles métier.

Comment dimensionner l'hébergement d'une API ?

Pics par client, p95 cible, coût DB/requête ; cache et pagination avant scale horizontal.

Que documenter avant l'ouverture ?

Limites par tier, 429, Retry-After, dépréciation, statut incident.

Une API publique mature refuse des requêtes avec élégance — avant que la base ne refuse tout le monde sans préavis.