Le code 429 Too Many Requests signifie que le client a dépassé un nombre de requêtes autorisé sur une période. C’est une décision du serveur ou d’un service placé devant, pas une exception dans le code de la page. L’en-tête Retry-After, lorsqu’il est présent, indique combien de temps attendre avant de réessayer. Sans lui, le client ne sait pas quand le plafond se rouvre.
Un 429 protège une ressource. Le supprimer partout recrée le problème qu’il empêchait : essais de mots de passe, moisson d’API, ou tests de cartes.
Ce qui répond 429
- Une extension de limitation des connexions WordPress, après plusieurs mots de passe faux sur
wp-login.php. - L’API REST, ou une clé WooCommerce, lorsque le quota horaire du compte est atteint. Le corps du message cite souvent la limite et la fenêtre.
- Une règle Cloudflare de rate limiting, ou le mode de lutte contre les bots, qui compte les requêtes par IP ou par empreinte.
- Un plafond sur
xmlrpc.phpou sur l’URL de coupon, posé après des rafales. - Un limiteur applicatif sur la recherche interne ou sur l’ajout au panier, déclenché par un script de surveillance trop bavard.
- Une règle unique pour tout le monde, si basse que le robot d’indexation la franchit en explorant le catalogue.
Le site peut rester en 200 sur la page d’accueil pendant que seule l’URL limitée répond 429. Mesurer la mauvaise URL fait croire à une panne générale.
Identifier le limiteur
- Notez l’URL, l’IP et l’heure. Un 429 sur
/wp-login.phpn’a pas la même origine qu’un 429 sur/wp-json/. - Lisez les en-têtes.
Retry-Afterdonne le délai. Un en-tête du typeX-RateLimit-Remainingou un message Cloudflare nomme le palier. - Comparez une autre IP, par exemple un partage mobile. Si elle passe, le blocage est lié à l’adresse, pas à l’application.
- Regardez quel composant a écrit la page : HTML du plugin de sécurité, page d’erreur Cloudflare, ou JSON de votre API. Ce n’est pas le même réglage à ouvrir.
- Contrôlez l’URL depuis l’extérieur avec un test d’URL. Un seul appel ne doit pas recevoir 429. S’il le reçoit, le plafond est déjà saturé ou la règle bloque des clients qui n’ont presque rien envoyé.
Les fonctions de contrôle automatique décrites dans les fonctionnalités de surveillance doivent elles-mêmes rester sous le plafond : un contrôle toutes les minutes sur une URL limitée finit par fabriquer le 429 qu’il surveille.
Assouplir sans tout ouvrir
| Origine du 429 | Ajustement |
|---|---|
| Connexion WordPress | Laisser le plafond sur wp-login.php, allonger un peu la fenêtre si vos équipes se bloquent elles-mêmes |
| API | Augmenter le quota du compte qui intègre, ou espacer les appels |
| Cloudflare | Relever le seuil de la règle, exclure les IP d’administration, garder un seuil bas sur la connexion |
| Robot d’indexation | Vérifier le robot, puis lui appliquer une règle distincte |
| Script de supervision | Baisser sa fréquence sur cette URL au lieu de couper la protection |
| Coupon ou recherche | Plafonner ces URL seulement, pas tout le nom de domaine |
Attendez la fin de Retry-After avant de déclarer le correctif bon. Un essai immédiat retombe dans le même compteur.
Ce qu’il ne faut pas faire
Ne désactivez pas la limite sur la page de connexion et sur le paiement pour faire disparaître l’erreur. Ne mettez pas l’ensemble du site en liste blanche. Ne traitez pas le 429 comme une surcharge à résoudre par un 503 : le serveur n’est pas forcément à court de ressources, il applique une règle. Ne multipliez pas les relances automatiques sans lire Retry-After.
Une fois la règle identifiée, vérifiez qu’une page qui ne devrait jamais être limitée, par exemple une fiche produit, répond toujours 200. C’est le même réflexe que pour tester si un site répond vraiment : le code de l’URL qui compte, pas une moyenne du domaine.