Erreur 429 Too Many Requests : causes et solutions complètes

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

L'erreur HTTP 429 est un code de statut client qui signifie Too Many Requests (trop de requêtes). Le serveur vous indique que vous avez envoyé trop de requêtes dans un laps de temps donné et qu'il refuse temporairement d'en traiter davantage tant que vous ne ralentissez pas.

Cette erreur est définie dans la RFC 6585 et fait partie du mécanisme de limitation de débit HTTP. C'est l'une des erreurs les plus fréquentes rencontrées par les développeurs travaillant avec des API, mais les utilisateurs ordinaires peuvent aussi la rencontrer en naviguant sur le web.

Le code de statut 429 se distingue des autres erreurs 4xx. Une erreur 403 signifie que l'accès vous est refusé. Une erreur 401 signifie que vous n'êtes pas authentifié. L'erreur 429, elle, indique que vos identifiants sont valides — vous envoyez simplement vos requêtes trop rapidement.

Lorsqu'un serveur renvoie une réponse 429, il peut inclure un en-tête Retry-After qui vous indique précisément combien de temps attendre avant d'envoyer la prochaine requête.

À quoi ressemble l'erreur 429 ?

L'erreur 429 se présente différemment selon le navigateur, l'application ou le client API que vous utilisez. Voici les variantes les plus courantes :

Contrairement aux erreurs 500 qui signalent un problème côté serveur, l'erreur 429 est une erreur côté client — le serveur fonctionne parfaitement, mais il se protège contre un volume de requêtes trop élevé.

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

La limitation de débit est une technique utilisée par les serveurs pour contrôler le nombre de requêtes qu'un client peut effectuer dans une fenêtre de temps donnée. Lorsque la limite est dépassée, le serveur répond avec une erreur HTTP 429.

Il existe plusieurs algorithmes courants de limitation de débit :

• 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.

La plupart des API communiquent leurs limites de débit via des en-têtes de réponse. Les en-têtes courants sont X-RateLimit-Limit (nombre maximal de requêtes autorisées), X-RateLimit-Remaining (requêtes restantes dans la fenêtre en cours) et X-RateLimit-Reset (moment de la réinitialisation de la fenêtre).

Comprendre l'algorithme utilisé par un service vous aide à concevoir votre client de manière à rester dans les limites et à éviter les erreurs 429.

Causes fréquentes de l'erreur HTTP 429

L'erreur 429 peut être déclenchée par de nombreux scénarios différents. Voici les causes les plus courantes, classées selon le profil de l'utilisateur concerné :

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. L'erreur 429 est temporaire — le serveur vous demande de ralentir, il ne vous bloque pas définitivement.

Attendez 30 secondes à quelques minutes, puis réessayez. La plupart des limites de débit se réinitialisent en 1 à 5 minutes. Si la page affiche toujours l'erreur 429, patientez plus longtemps — certains services appliquent des limites horaires ou quotidiennes.

N'actualisez pas la page de manière répétée. Chaque actualisation envoie une nouvelle requête et peut prolonger la période de limitation.

2. Vider le cache et les cookies du navigateur

Parfois, les données en cache ou les cookies peuvent déclencher une limitation de débit. Les supprimer peut résoudre le problème :

• Chrome : appuyez sur Ctrl+Shift+Delete (Windows) ou Cmd+Shift+Delete (Mac) → sélectionnez « Cookies » et « Images et fichiers en cache » → cliquez sur « Effacer les données »

• Firefox : appuyez sur Ctrl+Shift+Delete → sélectionnez « Cache » et « Cookies » → cliquez sur « Effacer maintenant »

• Edge : appuyez sur Ctrl+Shift+Delete → cochez « Cookies » et « Données en cache » → cliquez sur « Effacer maintenant »

• Safari : allez dans Safari → Réglages → Confidentialité → Gérer les données de sites web → Tout 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 probablement une adresse IP avec des centaines d'autres utilisateurs. Lorsque leurs requêtes cumulées dépassent la limite du serveur, tous les utilisateurs de cette IP se retrouvent limités.

Essayez de vous déconnecter de votre VPN et d'accéder au site via votre connexion internet classique. Si l'erreur 429 disparaît, c'est l'IP du VPN qui posait problème.

Si vous avez besoin du VPN, essayez de basculer vers un autre emplacement de serveur pour obtenir une nouvelle adresse IP.

4. Désactiver les extensions du navigateur

Certaines extensions de navigateur envoient des requêtes en arrière-plan à votre insu. Les bloqueurs de publicités, les comparateurs de prix, les extensions SEO et les plugins d'actualisation automatique peuvent tous générer des requêtes supplémentaires qui déclenchent la limitation de débit.

Pour vérifier, ouvrez le site dans une fenêtre de navigation privée (qui désactive la plupart des extensions par défaut). Si l'erreur 429 disparaît, l'une de vos extensions en est la cause.

Désactivez les extensions une par une pour identifier celle qui pose problème. Dans Chrome, rendez-vous sur chrome://extensions/ et désactivez-les individuellement.

5. Essayer un autre réseau

Si aucune autre solution ne fonctionne, le serveur limite peut-être spécifiquement votre adresse IP. Essayez ceci :

Passez du Wi-Fi aux données mobiles (ce qui vous attribue une IP différente). Testez le site depuis un réseau entièrement différent. Si vous êtes sur un réseau d'entreprise ou scolaire, essayez depuis chez vous — les grands réseaux partagent une seule IP publique.

Vous pouvez vérifier votre adresse IP actuelle avec notre outil Quelle est mon IP pour confirmer qu'elle a bien changé.

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

Si vous développez une application qui appelle des API, l'erreur 429 signifie que votre code envoie des requêtes trop rapidement. Voici comment la gérer correctement.

1. Implémenter un backoff exponentiel

Le backoff exponentiel est la stratégie de réessai standard de l'industrie. Au lieu de réessayer immédiatement après une erreur 429, vous augmentez progressivement le temps d'attente entre chaque tentative :

Première tentative : attendre 1 seconde. Deuxième tentative : attendre 2 secondes. Troisième tentative : attendre 4 secondes. Quatrième tentative : attendre 8 secondes. Et ainsi de suite.

Voici une implémentation de base en JavaScript :

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    
    if (response.status !== 429) return response;
    
    // Check Retry-After header first
    const retryAfter = response.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.pow(2, attempt) * 1000; // Exponential backoff
    
    console.log(`Rate limited. Retrying in ${delay / 1000}s...`);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
  throw new Error('Max retries exceeded');
}

Ajoutez du jitter (variation aléatoire) au délai pour éviter que plusieurs clients ne réessaient exactement au même moment. Remplacez le calcul du délai par Math.pow(2, attempt) * 1000 + Math.random() * 1000.

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

Lorsqu'un serveur renvoie une réponse 429, il inclut souvent un en-tête Retry-After qui vous indique exactement combien de temps attendre. Cet en-tête peut contenir soit un nombre de secondes, soit une date HTTP :

Retry-After: 60 signifie qu'il faut attendre 60 secondes. Retry-After: Thu, 06 Mar 2026 12:00:00 GMT signifie qu'il faut attendre jusqu'à cette heure précise.

Vérifiez toujours cet en-tête avant d'appliquer votre propre logique de backoff. Le serveur sait mieux que votre code combien de temps vous devez attendre.

import requests
import time

def make_request(url):
    response = requests.get(url)
    
    if response.status_code == 429:
        retry_after = response.headers.get('Retry-After', '5')
        wait_time = int(retry_after)
        print(f"Rate limited. Waiting {wait_time} seconds...")
        time.sleep(wait_time)
        return make_request(url)  # Retry after waiting
    
    return response

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);
  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 légitimement besoin de plus d'appels API, contactez le fournisseur du service. De nombreuses API proposent des limites de débit plus élevées pour les plans payants ou les applications vérifiées.

Lorsque vous demandez des limites plus élevées, expliquez votre cas d'usage et fournissez des estimations du volume de requêtes prévu. Des services comme les API Google, l'API Twitter et l'API GitHub disposent tous de procédures pour demander des limites plus élevées.

Certaines API proposent également des endpoints en lot (bulk) qui permettent de récupérer plusieurs ressources en une seule requête, réduisant ainsi 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 des utilisateurs légitimes déclenchent des erreurs 429, vos limites de débit sont probablement trop restrictives. Révisez-les et ajustez-les.

Avec Nginx, le module de limitation de débit (ngx_http_limit_req_module) contrôle le rythme des requêtes :

# 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/ {
        # Allow bursts of 20, no delay for first 10
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Le paramètre burst est essentiel — il autorise les pics de trafic ponctuels sans déclencher d'erreur 429. Sans ce paramètre, même une navigation normale peut atteindre la limite.

Avec Apache, utilisez mod_ratelimit ou mod_evasive. Avec Node.js, utilisez des paquets comme express-rate-limit.

2. Ajouter les IP de confiance à la liste blanche

Si certains clients (services de surveillance, processeurs de paiement, vos propres microservices) sont limités par le rate limiting, ajoutez leurs adresses IP à la liste blanche.

Avec Nginx, vous pouvez utiliser une directive map pour contourner la limitation de débit pour les IP de confiance :

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;

Ajoutez également les robots des moteurs de recherche (Googlebot, Bingbot) à la liste blanche s'ils sont limités — les bloquer nuit à votre référencement. Vous pouvez vérifier l'identité des robots à l'aide de requêtes DNS inversé.

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é, leurs règles de limitation de débit peuvent être à l'origine des erreurs 429 — et non votre serveur d'origine.

Dans Cloudflare, vérifiez Sécurité → WAF → Règles de limitation de débit. Vous pouvez voir quelles règles se déclenchent et ajuster les seuils. Le mode « I'm Under Attack » de Cloudflare est particulièrement agressif.

Dans AWS WAF, vérifiez les règles de votre Web ACL basées sur le débit. Le seuil minimum est de 100 requêtes par 5 minutes — assurez-vous que ce seuil est adapté à votre niveau de trafic.

Analysez les statistiques de votre CDN pour distinguer le trafic légitime du trafic de bots avant de modifier les limites.

4. Optimiser les performances du serveur

Parfois, les erreurs 429 apparaissent parce que le serveur ne peut pas supporter la charge et que la limitation de débit s'active comme mécanisme de sécurité. Améliorer les performances du serveur vous permet de relever les limites en toute sécurité.

Les optimisations clés comprennent : 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, implémenter le pooling de connexions pour la base de données et effectuer une mise à l'échelle horizontale avec de la répartition de charge si le trafic le justifie.

Utilisez notre outil En-têtes HTTP pour vérifier que vos en-têtes de mise en cache sont correctement configurés.

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 : l'erreur 429 est temporaire et intentionnelle. Le serveur est en bonne santé — il choisit activement de rejeter votre requête pour se protéger. Les erreurs 5xx, en revanche, indiquent qu'un dysfonctionnement s'est réellement produit.

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.