Erreur 429 : arrêter de perdre des appels API

Votre code est bon. Vos tests passent. Et pourtant, à 19 h, la fonctionnalité qui marchait ce matin renvoie une erreur à un client sur trois.

Le corps de la réponse tient en une ligne : 429 Too Many Requests.

Ce n’est pas un bug. C’est une limite de débit, et elle vient de rappeler une chose désagréable : votre application ne dépend pas de votre code, elle dépend d’une clé API qui, elle, a un plafond. Une seule clé, un seul plafond, un seul point de rupture.

Il existe une réponse évidente à ce problème. Elle est mauvaise, et je vais expliquer pourquoi avant de décrire celle que j’ai construite.

Ce qu’un 429 vous dit vraiment

Un 429 n’est pas un refus définitif, c’est une mise en attente. Le fournisseur vous signale que vous avez dépassé un quota sur une fenêtre de temps : requêtes par minute, jetons par minute, appels par jour. Souvent il joint un en-tête Retry-After qui indique combien de secondes patienter.

Le piège est là. Cette information arrive après l’échec. Votre utilisateur, lui, a déjà vu la page d’erreur.

Pourquoi le retry ne suffit pas

La parade classique consiste à réessayer avec un délai qui grandit à chaque tentative. C’est utile, et parfaitement insuffisant, pour trois raisons.

D’abord, le temps. Un backoff correct attend une seconde, puis deux, puis quatre. Sur une requête interactive, vous avez déjà perdu votre utilisateur.

Ensuite, l’effet de meute. Si vos dix processus rencontrent la même limite, ils réessaient tous, et souvent au même moment. Vous ne réparez pas la saturation, vous la synchronisez.

Enfin, et c’est le point que l’on découvre trop tard : réessayer sur la même clé, c’est réessayer sur le même plafond. Le quota n’est pas revenu. Vous frappez une porte fermée, plus poliment.

La vraie question n’est donc pas « comment attendre mieux », mais « pourquoi n’ai-je qu’une seule porte ».

L’idée : un pool, une seule clé pour vous

ApiSwitch est un proxy BYOK, pour *Bring Your Own Keys*. Vous apportez vos propres clés et vos propres points de terminaison. Le service n’impose aucun fournisseur et ne revend aucune clé : il n’en détient aucune qui lui appartienne.

Votre application ne connaît plus qu’une seule clé, celle d’ApiSwitch. Derrière, il y a un pool.

POST /api/proxy

{
  "provider": "gemini",
  "endpoint": "/v1beta/models/gemini-2.5-flash:generateContent",
  "payload": {
    "contents": [
      { "role": "user", "parts": [{ "text": "Bonjour" }] }
    ]
  }
}

Un seul point d’entrée, et toute la logique de survie de l’autre côté.

Le mécanisme, étape par étape

Ce qui se passe entre votre appel et la réponse tient en quelques opérations, dans cet ordre précis :

1. Identification du pool visé, par fournisseur ou par groupe.
2. Vérification du plafond mensuel de votre plan, un INCR dans Redis.
3. Chargement des clés actives et non épuisées de ce pool.
4. Tri par quota restant décroissant. Une clé sans quota connu passe en tête.
5. Lecture de la configuration de connexion portée par la clé : hôte, méthode d’authentification, paramètre, préfixe.
6. Tentative, transmission de la réponse, enregistrement de la destination réellement appelée.
7. Si un 429 tombe : la clé est marquée épuisée, et l’appel bascule sur la suivante.
8. Si une limite quotidienne ou mensuelle que vous avez fixée est atteinte : même traitement, bascule.
9. Si tout le pool est à sec : un 503 honnête, avec un retry_after.

L’étape 7 est le coeur du sujet. Le 429 ne remonte pas jusqu’à vous, il déclenche une bascule. Votre utilisateur ne voit rien.

Un cron horaire repasse ensuite sur les clés marquées épuisées, détecte le changement de jour ou de mois, et remet les compteurs à zéro. Le pool se répare tout seul.

Le détail qui change tout : le failover entre fournisseurs

Faire tourner cinq clés OpenAI, c’est bien. Mais si c’est OpenAI qui limite, cinq clés du même fournisseur peuvent toutes se heurter au même mur.

D’où les groupes. Vous étiquetez vos clés avec un nom de votre choix, par exemple llm, sans vous soucier de qui les émet. Vous appelez ensuite le groupe, plus le fournisseur :

POST /api/proxy

{
  "group": "llm",
  "endpoint": "/v1/chat/completions",
  "payload": {
    "model": "gpt-4o",
    "messages": [
      { "role": "user", "content": "Bonjour" }
    ]
  }
}

Une clé OpenAI et une clé Anthropic peuvent vivre dans le même groupe. Si la première sature, l’appel part chez l’autre. Vous n’avez pas seulement multiplié les clés, vous avez supprimé la dépendance à un fournisseur unique.

Ce que vous découvrez sans l’avoir demandé

À chaque appel réussi, la destination exacte est enregistrée : nom d’hôte plus chemin, sans la chaîne de requête.

api.openai.com/v1/chat/completions
api.rapidapi.com/v2/translate

Cela paraît anodin. C’est en réalité la réponse à une question que se posent tous ceux qui utilisent un agrégateur comme RapidAPI avec une clé unique : quelles APIs mon application appelle-t-elle vraiment, et à quelle fréquence ? Le tableau de bord affiche le détail par clé et par destination, avec le nombre d’appels, la dernière utilisation et le quota restant. Personne ne l’a configuré, la découverte est automatique.

Et mes clés, dans tout ça

C’est la question qui doit venir en premier, et je préfère y répondre franchement.

Les clés tierces sont chiffrées au repos en AES-256-GCM, stockées sous la forme iv:chiffré:tag, avec une clé maîtresse de 32 octets. Elles ne sont jamais renvoyées en clair par l’API, pas même à vous. Le tableau de bord n’en montre que des fragments.

Dit autrement : ApiSwitch n’est pas un revendeur de clés API. Il en est le coffre-fort et le chef d’orchestre.

Le moteur, et ce qu’il encaisse

Sous le capot, il n’y a ni couche d’abstraction, ni file d’attente, ni base relationnelle sur le chemin critique. Le serveur, evoyx.js, tourne en cluster sur deux instances et s’appuie sur Redis pour tout ce qui doit être décidé en une fraction de milliseconde : quel pool, quelle clé, quel quota restant, quel plafond mensuel. Un compteur Redis se lit et s’incrémente en mémoire. C’est ce choix, et lui seul, qui permet d’ajouter une couche d’aiguillage sans la faire payer à l’utilisateur.

Un article qui parle de performance sans chiffres ne vaut rien. Voici ceux relevés à l’autocannon sur l’infrastructure de production, en juin 2026 :

• Sonde Redis, 50 connexions : 17 600 req/s, p50 à 2 ms, p99 à 9 ms.
• Rejet d’une clé invalide, 50 connexions : 25 500 req/s, p50 à 1 ms, p99 à 6 ms.
• Page de statut, lectures multiples, 50 connexions : 2 100 req/s, p50 à 22 ms, p99 à 48 ms.
• Test de résistance, 200 connexions simultanées : 20 300 req/s, p50 à 8 ms, p99 à 23 ms.

Ces chiffres mesurent exactement ce qui est ajouté à votre appel : l’aiguillage. C’est la seule chose dont ApiSwitch est responsable, le reste du temps de réponse appartient au fournisseur que vous visez. À 25 500 requêtes par seconde sur la couche d’authentification et un p99 à 6 millisecondes, le proxy disparaît dans le bruit de mesure d’un appel réseau ordinaire.

Autrement dit : vous gagnez la bascule automatique, la rotation et le chiffrement, et vous ne payez rien en latence perceptible.

La page de statut, un outil dans l’outil

Quand un appel échoue, la première question coûte toujours du temps : est-ce moi, est-ce le proxy, ou est-ce le fournisseur ? Tant qu’on ne sait pas, on cherche au mauvais endroit.

La page de statut répond aux trois en un écran, et elle est publique, sans compte.

• L’état du service et de ses composants, mesuré par un ping toutes les 60 secondes, pas déclaré à la main.
• La disponibilité sur 7 et 30 jours, la latence moyenne, et un graphique des 24 dernières heures point par point.
• Et surtout, les liens directs vers les pages d’état des grands fournisseurs, OpenAI, Anthropic, Stripe. Si la panne est chez eux, vous le voyez sans quitter la page.

Elle se rafraîchit toute seule. C’est le premier réflexe à avoir quand quelque chose cloche, avant même d’ouvrir vos journaux.

La feuille de route est publique, et vous votez

Onze fonctionnalités y sont listées, avec leur état réel. Sept sont livrées : historique d’activité, portail d’administration, page de statut, factures Factur-X, vérification d’e-mail, SDK Node.js, webhook de paiement.

Trois sont annoncées et attendent votre avis : statistiques avancées du tableau de bord, comptes multi-utilisateurs, et un serveur MCP pour brancher des agents IA directement sur le proxy.

Chacun peut voter, une voix par fonctionnalité et par semaine, sans créer de compte. L’ordre de développement suit les votes. Si ce qui vous manque n’y figure pas, c’est le bon endroit pour le faire savoir.

Ce qu’ApiSwitch ne fait pas

• Il ne crée pas de quota. Si toutes vos clés sont à sec, la réponse est un 503, pas un miracle.
• Il ne met pas les réponses en cache. Deux appels identiques partent deux fois.
• Il ne traduit pas les formats entre fournisseurs. Un groupe qui mélange deux APIs suppose des charges utiles compatibles, ou un appel par format.

Un outil qui prétend tout faire ment sur au moins un point.

Questions fréquentes

Que signifie l’erreur 429 ?

429 Too Many Requests indique que vous avez dépassé la limite de débit autorisée par le fournisseur sur une fenêtre de temps donnée. Ce n’est pas une erreur d’authentification ni une panne : le quota se réinitialise, souvent après le délai indiqué par l’en-tête Retry-After.

La rotation de clés API est-elle autorisée ?

Utiliser plusieurs clés que vous détenez légitimement, sur des comptes que vous possédez, relève de votre organisation. Ce qui pose problème, c’est la création de comptes multiples destinée à contourner un plafond, interdite par la plupart des conditions d’utilisation. ApiSwitch orchestre vos clés, il ne vous en fournit aucune.

Faut-il changer de code pour l’utiliser ?

Vous remplacez l’appel direct au fournisseur par un appel à /api/proxy avec votre clé ApiSwitch, en passant le point de terminaison et la charge utile d’origine. La configuration de connexion, hôte et méthode d’authentification, est portée par chaque clé enregistrée.

Quelle est la disponibilité du service ?

Le serveur tourne en cluster sur deux instances indépendantes, l’une prend le relais de l’autre. La disponibilité n’est pas une promesse commerciale : elle est mesurée toutes les 60 secondes, conservée sur 30 jours et publiée sur la page de statut, avec l’historique sur 7 et 30 jours. Vous pouvez la vérifier avant de vous inscrire, et n’importe quand après.

Combien ça coûte ?

Le plan Starter est gratuit, plafonné à 10 000 requêtes par mois, un groupe et deux clés. Le plan Pro est à 29 EUR HT par mois pour 1 000 000 de requêtes, groupes et clés illimités. Au-delà, le volume se discute.

Pour finir

Le 429 n’est pas une fatalité, c’est un problème d’architecture : vous avez confié votre disponibilité à une ressource unique. La solution n’est ni d’attendre mieux, ni de payer un plan supérieur, mais de faire en sorte qu’aucune clé ne soit indispensable.

Voir ApiSwitch ou revenir au répertoire des produits.