Erreur HTTP 429 Too Many Requests : sens et solutions

Qu'est-ce que l'erreur HTTP 429 ?

HTTP 429 Too Many Requests signifie que le serveur limite votre débit : vous, votre adresse IP ou votre application avez envoyé plus de requêtes qu'il n'en autorise sur une période donnée. C'est temporaire. Le serveur fonctionne ; il choisit simplement de ne pas vous répondre pour l'instant.

Le code a été ajouté dans la RFC 6585 (2012) précisément pour ce cas, et la réponse peut contenir un en-tête Retry-After qui indique combien de temps attendre. Vous le rencontrerez en naviguant sur des sites très fréquentés, en appelant des API, en téléchargeant en masse ou avec un VPN dont l'adresse IP est partagée par beaucoup de monde.

Il se distingue de ses voisins : un 401 signifie que vous n'êtes pas connecté, un 403 que vous n'avez pas le droit d'accéder, et un 429 que vous en avez le droit, mais que vous allez trop vite.

À quoi ressemble l'erreur 429 ?

Le message dépend de qui répond. Voici ceux que les gens recherchent :

Contrairement à une erreur 500, qui signifie qu'un élément a cassé côté serveur, un 429 est une erreur client au sens HTTP : le serveur se protège d'un trop grand nombre de requêtes.

Comment fonctionne la limitation de débit (rate limiting)

La limitation de débit est une technique que les serveurs utilisent pour contrôler le nombre de requêtes qu'un client peut envoyer dans une fenêtre de temps. Quand la limite est dépassée, le serveur répond généralement 429 (certains répondent 403 ou 503 à la place).

Plusieurs algorithmes de limitation sont courants :

• Fenêtre fixe (Fixed Window) — Le serveur autorise N requêtes par fenêtre de temps (par exemple, 100 requêtes par minute). Le compteur se réinitialise à intervalles fixes.
• Fenêtre glissante (Sliding Window) — Similaire à la fenêtre fixe, mais la fenêtre de temps glisse avec chaque requête. Cela empêche les pics aux limites de la fenêtre.
• Seau à jetons (Token Bucket) — Le serveur attribue des jetons qui se régénèrent à un rythme constant. Chaque requête consomme un jeton. Lorsqu'il n'y a plus de jetons, les requêtes sont rejetées.
• Seau percé (Leaky Bucket) — Les requêtes sont traitées à un rythme constant, indépendamment du volume de pics. Les requêtes excédentaires sont mises en file d'attente ou supprimées.

Beaucoup d'API annoncent leurs limites dans les en-têtes de réponse. Chez GitHub, par exemple, ce sont x-ratelimit-limit (requêtes autorisées par heure), x-ratelimit-remaining, x-ratelimit-used et x-ratelimit-reset (le moment où la fenêtre est réinitialisée, en secondes Unix). Un brouillon de l'IETF propose des en-têtes standard RateLimit et RateLimit-Policy pour le même usage.

Savoir quel algorithme et quelle fenêtre un service utilise vous aide à concevoir votre client pour rester dans la limite.

Causes fréquentes de l'erreur HTTP 429

La cause dépend de la personne concernée :

Comment corriger l'erreur 429 (pour les visiteurs)

Si vous rencontrez une erreur 429 en naviguant sur un site web, voici les solutions à essayer. Commencez par la plus simple et progressez vers les solutions plus avancées.

1. Patienter et réessayer

La solution la plus simple est d'attendre. Un 429 est temporaire : le serveur vous demande de ralentir, il ne vous bannit pas.

La durée dépend de la limite du site : certaines se réinitialisent en moins d'une minute, d'autres sont horaires ou quotidiennes. Si la page ou l'API envoie un en-tête Retry-After, c'est la durée exacte à attendre. Chargez ensuite la page une seule fois.

N'actualisez pas sans cesse : chaque actualisation est une requête de plus et compte pour la même limite.

2. Supprimer les cookies du site

Cela compte rarement, mais certains sites comptent les requêtes par cookie de session. Supprimez les cookies de ce seul site pour obtenir une session neuve, sans vous déconnecter de tout le reste :

• Chrome / Edge : ouvrez chrome://settings/content/all (Edge : edge://settings/content/all), recherchez le site et supprimez ses données
• Firefox : cliquez sur le cadenas dans la barre d'adresse → Effacer les cookies et les données de sites…
• Safari : Safari → Réglages → Confidentialité → Gérer les données de sites web → trouvez le site → Supprimer

Après le nettoyage, fermez et rouvrez votre navigateur avant de revisiter le site.

3. Déconnecter le VPN ou le proxy

Si vous utilisez un VPN ou un proxy, vous partagez peut-être votre adresse IP avec des centaines d'autres utilisateurs. Quand leurs requêtes cumulées dépassent la limite du serveur, tous ceux qui passent par cette IP sont limités.

Essayez de déconnecter votre VPN et d'accéder au site avec votre connexion internet habituelle. Si l'erreur 429 disparaît, l'IP du VPN était en cause.

Si vous avez besoin du VPN, passez sur un autre emplacement de serveur : son adresse est peut-être partagée par moins de monde.

4. Désactiver les extensions du navigateur

Certaines extensions envoient des requêtes en arrière-plan aux sites que vous visitez : les suivis de prix, les outils SEO et les extensions d'actualisation automatique peuvent finir par atteindre une limite de débit. (Les bloqueurs de publicités font généralement l'inverse et réduisent les requêtes.)

Pour tester, ouvrez le site dans une fenêtre de navigation privée, où la plupart des extensions sont désactivées. La navigation privée démarre aussi sans cookies : si le 429 disparaît, une extension ou une limite basée sur la session est en cause.

Désactivez les extensions une par une pour trouver la coupable. Dans Chrome, allez sur chrome://extensions/ et désactivez-les individuellement.

5. Vérifier si votre adresse IP est partagée

Beaucoup de personnes peuvent partager une même adresse IP publique : un réseau d'entreprise ou d'école, le réseau d'un opérateur mobile (CGNAT) ou un serveur VPN. Leurs requêtes comptent pour la même limite que les vôtres.

Si vous êtes sur un tel réseau, charger le site depuis votre connexion personnelle ou en données mobiles vous dit si l'adresse partagée est en cause. Si la limite porte sur votre propre adresse, attendez sa réinitialisation plutôt que de changer de réseau pour la contourner. Vous pouvez vérifier votre IP publique actuelle avec Quelle est mon adresse IP ?.

Comment corriger l'erreur 429 (pour les développeurs)

Si votre code reçoit des 429, il envoie des requêtes plus vite que l'API ne l'autorise. Traitez le problème dans cet ordre : lire Retry-After, réessayer avec un backoff et du jitter, puis réduire le nombre de requêtes.

1. Implémenter un backoff exponentiel

Le backoff exponentiel est la stratégie de nouvelle tentative standard : au lieu de réessayer immédiatement après un 429, vous doublez l'attente à chaque fois (1 seconde, 2, 4, 8…) et vous ajoutez du jitter, un délai aléatoire supplémentaire, pour que de nombreux clients ne réessaient pas tous au même instant.

Cette version utilise Retry-After quand le serveur en envoie un valide, dans l'un de ses deux formats, retombe sinon sur un backoff avec jitter, et abandonne après quelques essais. (Dans un navigateur qui appelle l'API d'un autre site, Retry-After n'est lisible que si l'API l'expose avec Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Respecter l'en-tête Retry-After

Quand un serveur envoie Retry-After avec un 429, il indique exactement combien de temps attendre. La RFC 9110 autorise deux formes : un nombre de secondes ou une date HTTP.

Retry-After: 60 signifie attendre 60 secondes. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT signifie attendre jusqu'à cette heure. Vérifiez-le avant votre propre logique de backoff : le serveur en sait plus que votre code.

En Python, gérez les deux formes et arrêtez-vous après quelques essais au lieu de faire de la récursion à l'infini :

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Mettre en cache les réponses API

Si votre application effectue le même appel API plusieurs fois, mettez en cache la réponse au lieu de solliciter l'API à chaque fois. Cela réduit considérablement le nombre de requêtes.

Utilisez un cache en mémoire (comme Redis ou un simple Map) pour les données fréquemment consultées. Définissez un TTL (time-to-live) raisonnable en fonction de la fréquence de mise à jour des données.

Par exemple, si vous consultez les enregistrements DNS d'un domaine, les résultats ne changeront probablement pas dans les 5 prochaines minutes — mettez-les en cache.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Utiliser des webhooks au lieu du polling

Si vous interrogez une API en boucle pour vérifier les changements (par exemple, vérifier le statut d'une commande toutes les 10 secondes), passez aux webhooks si le service les prend en charge.

Avec les webhooks, le serveur envoie les mises à jour à votre application lorsqu'un changement survient — plus besoin de polling constant. Cela peut réduire vos appels API de plusieurs milliers par heure à une poignée seulement.

La plupart des API modernes (Stripe, GitHub, Twilio, Shopify) prennent en charge les webhooks. Consultez la documentation de l'API pour configurer les webhooks.

5. Demander des limites plus élevées

Si vous avez réellement besoin de plus d'appels API, contactez le fournisseur du service. Beaucoup d'API proposent des limites plus élevées pour les offres payantes ou les applications vérifiées.

Quand vous demandez des limites plus élevées, expliquez votre cas d'usage et donnez une estimation du volume de requêtes attendu. Beaucoup d'API, dont celles de Google, proposent un formulaire ou une offre payante pour des limites supérieures.

Certaines API proposent aussi des endpoints groupés qui permettent de récupérer plusieurs ressources en une seule requête, ce qui réduit le nombre total d'appels.

Comment corriger l'erreur 429 (pour les propriétaires de sites)

Si vos visiteurs ou les consommateurs de votre API reçoivent des erreurs 429, le problème se situe dans la configuration de votre serveur. Voici comment diagnostiquer et résoudre la situation.

1. Ajuster vos limites de débit

Si de vrais utilisateurs reçoivent des 429, trouvez quelle couche répond en premier : votre CDN ou WAF, votre serveur web ou votre application. Ajustez ensuite les limites de cette couche.

Dans nginx, c'est limit_req qui fait le travail. Notez qu'il répond 503 par défaut : ajoutez limit_req_status 429; pour que les clients sachent qu'ils doivent ralentir au lieu de croire que le serveur est en panne :

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Le paramètre burst laisse passer de courts pics sans 429 ; sans lui, un chargement de page normal qui déclenche beaucoup de requêtes peut atteindre la limite.

Apache n'a pas de limiteur de débit de requêtes intégré : son mod_ratelimit limite la bande passante, pas le nombre de requêtes, et le module tiers mod_evasive répond 403. Utilisez un reverse proxy, un WAF ou votre application pour obtenir des 429. Dans Node.js, express-rate-limit répond 429 par défaut.

2. Ajouter les IP de confiance à la liste blanche

Si certains clients (services de supervision, processeurs de paiement, vos propres microservices) sont limités, mettez leurs adresses IP sur liste blanche.

Dans nginx, geo et map donnent aux adresses de confiance une clé vide, et nginx ne compte pas les requêtes dont la clé est vide. Cela remplace la ligne limit_req_zone de l'exemple précédent :

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Ne limitez pas les robots des moteurs de recherche par erreur : Google traite un 429 comme une erreur serveur et ralentit son exploration (Google Search Central). Vérifiez les vraies requêtes de Googlebot et de Bingbot avec une recherche DNS inverse confirmée par une recherche directe de ce nom, ou exemptez les plages d'IP publiées par les robots.

3. Vérifier les paramètres du WAF et du CDN

Si vous utilisez Cloudflare, AWS WAF, Sucuri ou un autre service de sécurité, ses règles de limitation de débit peuvent répondre avant même que votre serveur voie la requête.

Cloudflare affiche aux visiteurs « Error 1015: You are being rate limited » quand une règle de limitation se déclenche. Trouvez la règle dans les règles de sécurité du tableau de bord, consultez ses événements, puis relevez le seuil ou réduisez son périmètre.

Les règles basées sur le débit d'AWS WAF comptent les requêtes par IP (ou une autre clé) sur une fenêtre de 1, 2, 5 ou 10 minutes, avec une limite minimale de 10. Une requête bloquée reçoit 403 par défaut ; définissez une réponse personnalisée 429 pour que les clients sachent qu'ils doivent ralentir.

Consultez les statistiques du CDN pour distinguer les vrais visiteurs des bots avant de modifier quoi que ce soit.

4. Optimiser les performances du serveur

Certains services limitent plus fortement quand ils sont sous charge, par sécurité. Améliorer les performances du serveur vous permet de relever les limites sans risque.

Les optimisations clés : activer la mise en cache des réponses pour réduire la charge du backend, utiliser un CDN pour les ressources statiques, ajouter un cache de requêtes de base de données avec Redis ou Memcached, mettre en place un pool de connexions pour la base de données, et monter en charge horizontalement avec un répartiteur de charge si le trafic le justifie.

Utilisez notre Vérificateur d'en-têtes HTTP pour vérifier que vos en-têtes de cache sont correctement définis.

Erreur 429 vs autres erreurs HTTP

Il est facile de confondre l'erreur 429 avec d'autres codes de statut HTTP. Voici ce qui les distingue :

La distinction essentielle : le 429 est délibéré et temporaire : le serveur choisit de vous refuser pour le moment. La plupart des codes 5xx signifient qu'un élément a échoué côté serveur, même si un 503 peut aussi être une maintenance planifiée ou, avec nginx, une limite de débit.

Comment prévenir les erreurs 429

Mieux vaut prévenir que guérir. Voici les bonnes pratiques pour éviter les erreurs 429 en amont :

• Lire la documentation de l'API — Prenez connaissance des limites de débit avant d'écrire du code. La plupart des services publient clairement leurs limites.
• Surveiller votre consommation — Suivez les en-têtes X-RateLimit-Remaining pour savoir à quel point vous approchez de la limite.
• Regrouper les requêtes — Utilisez les endpoints en lot (bulk) lorsqu'ils sont disponibles, au lieu d'effectuer des appels individuels.
• Répartir les requêtes — Étalez vos appels API uniformément dans le temps au lieu d'envoyer des rafales.
• Utiliser des clés API — Les requêtes authentifiées bénéficient généralement de limites de débit plus élevées que les requêtes anonymes.
• Implémenter des disjoncteurs (circuit breakers) — Si vous recevez des erreurs 429 répétées, cessez totalement d'envoyer des requêtes pendant une période de refroidissement.
• Tester avec des simulateurs de rate limiting — Simulez des réponses 429 en développement pour vous assurer que votre gestion des erreurs fonctionne correctement.
• Journaliser les réponses 429 — Enregistrez quand et où la limitation de débit se produit pour optimiser vos schémas de requêtes.