Erreur 429 lors du parsing : 6 raisons en dehors du proxy.

Vous changez de proxy, achetez un nouveau pool d'adresses IP, mais le parser tombe toujours avec l'erreur 429 Too Many Requests ? C'est une situation classique : 70 % des cas de blocage ne sont pas liés à l'adresse IP, mais à la façon dont la requête elle-même est formulée. Nous examinons six raisons réelles pour lesquelles le site continue de vous bloquer même après avoir changé de proxy — et que faire dans chaque cas.

Que signifie l'erreur 429 et pourquoi le proxy n'est pas une panacée

Le code HTTP 429 Too Many Requests signifie formellement « limite de requêtes dépassée ». Mais en pratique, les sites — en particulier Wildberries, Ozon, Avito, Yandex.Market — utilisent ce code comme un signal universel « nous pensons que vous êtes un bot ». La raison peut être la fréquence des requêtes, mais tout aussi probablement — dans les en-têtes, l'empreinte du navigateur, l'absence de session cookie ou dans les limites liées non pas à l'IP, mais à votre compte.

C'est pourquoi changer de proxy n'aide souvent pas : si le système bloque non pas l'IP, mais le modèle de la requête (empreinte, en-têtes, vitesse des clics), alors avec la nouvelle adresse IP, vous obtiendrez le même 429 dans quelques minutes. Nous allons examiner chaque raison en détail et montrer comment la vérifier et la résoudre sans acheter un nouveau pool de proxies.

Important : les proxies restent un outil nécessaire — mais uniquement comme partie d'un système, et non comme solution unique. Les IP résidentielles et mobiles réduisent la probabilité d'être mis sur liste noire en raison de la réputation de l'IP, mais ne protègent pas contre les blocages dus au comportement ou aux en-têtes.

Raison 1 : Fréquence de requêtes trop élevée

La raison la plus évidente, mais aussi la plus souvent mal diagnostiquée. Beaucoup pensent : « puisque je change de proxy à chaque requête — la fréquence n'est pas importante ». C'est faux. Les systèmes anti-bots modernes (par exemple, Wildberries et Ozon utilisent des solutions de niveau Cloudflare ou leurs propres WAF) analysent non seulement la fréquence d'une seule IP, mais aussi la charge totale sur un point de terminaison API ou une page produit sur une période de temps de toutes les sources combinées avec des signaux comportementaux.

Si votre parser effectue 50 à 100 requêtes par seconde sur la même section du catalogue, le système voit une poussée anormale de trafic, peu importe combien d'IP différentes vous utilisez. La solution n'est pas de changer de proxy, mais d'implémenter des délais artificiels (throttling) entre les requêtes : 1 à 3 secondes de délai aléatoire au lieu d'un intervalle fixe, plus un backoff exponentiel lors de la réception d'un 429 (augmentation de la pause de moitié après chaque blocage).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Si vous utilisez un parser prêt à l'emploi sans code (par exemple, un service cloud de surveillance des prix), vérifiez les paramètres de l'intervalle entre les requêtes — la plupart de ces outils ont un curseur « vitesse de scan ». Réduire la vitesse de 30 à 40 % élimine souvent complètement le 429, même sans changer de proxy.

Raison 2 : En-têtes incorrects ou manquants

De nombreux parsers envoient des requêtes avec un ensemble minimal d'en-têtes ou utilisent la chaîne User-Agent par défaut de la bibliothèque (par exemple, « python-requests/2.28.1 »). Un tel en-tête révèle instantanément un bot — un vrai navigateur envoie des dizaines d'en-têtes : Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer et d'autres dans un ordre strictement défini.

Wildberries et Ozon comparent l'ensemble des en-têtes avec l'« empreinte » attendue d'un vrai navigateur Chrome ou Safari. Si les en-têtes sont trop peu nombreux, ne sont pas dans le bon ordre ou si le User-Agent ne correspond pas aux autres paramètres (par exemple, Chrome sur Windows est déclaré, mais l'empreinte TLS ressemble à Python) — la requête est bloquée avec un 429 indépendamment de l'IP.

En-tête	Erreur typique	Solution
User-Agent	Version obsolète ou chaîne de bibliothèque explicite	UA actuel d'un vrai Chrome/Safari, rotation depuis le pool
Accept-Language	Manquant ou ne correspondant pas à la géolocalisation de l'IP	ru-RU pour les marketplaces russes
Referer	Vide, alors qu'un vrai passage se fait toujours avec un Referer	Indiquer la page précédente du catalogue
Sec-Fetch-*	Complètement absents (non client de navigateur)	Copier l'ensemble complet depuis DevTools d'un vrai navigateur

Le plus simple est de copier l'ensemble complet des en-têtes depuis l'onglet Réseau dans DevTools d'un vrai navigateur, en ouvrant la page souhaitée manuellement, et d'utiliser cet ensemble dans le parser — en tenant compte de l'ordre des en-têtes, si la bibliothèque le permet (par exemple, curl_cffi ou httpx avec un ordre explicite).

Raison 3 : Absence de rotation des sessions et des cookies

Une erreur souvent négligée : le parser change d'IP à chaque requête, mais utilise la même session cookie ou ne conserve pas du tout les cookies. Un utilisateur réel reçoit lors de sa première visite un ensemble de cookies (tokens de session, identifiants d'appareil, étiquettes de protection antibot comme Cloudflare __cf_bm ou similaires chez Ozon/WB) et les utilise dans toutes les requêtes suivantes dans le cadre de la session.

Si vous envoyez une requête sans cookies obtenus sur une page « réchauffée », le système anti-bot voit une session « nulle » — et c'est immédiatement suspect, surtout lors de l'accès directement aux points de terminaison API, en contournant la page principale. La solution consiste à émuler un scénario complet : d'abord charger la page principale ou la page de catégorie, obtenir les cookies, attendre 1 à 2 secondes, puis accéder à l'API ou à la fiche produit souhaitée, en conservant les cookies dans la même session tout au long de la chaîne de requêtes.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Réchauffement de la session
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Requête principale déjà avec des cookies
response = session.get(target_url)

Si vous utilisez un navigateur anti-détection comme Dolphin Anty ou AdsPower pour surveiller manuellement les fiches produits ou via une automatisation intégrée, assurez-vous que le profil conserve les cookies entre les sessions et ne démarre pas chaque fois « à partir de zéro » — cela déclenche également la suspicion du système.

Raison 4 : Comportement similaire à celui d'un bot

Même avec des en-têtes et des cookies parfaits, le parser peut se révéler par des modèles comportementaux : ordre d'accès strictement linéaire aux produits (par ID croissant), intervalle identique entre les requêtes jusqu'à la milliseconde, absence de requêtes « inutiles » sur les ressources statiques (images, CSS, JS) que le navigateur ordinaire charge automatiquement.

Les systèmes de protection avancés de Wildberries et Ozon analysent non seulement les requêtes HTTP, mais aussi si le JavaScript a été exécuté sur la page (via la détection headless), si la « souris » a bougé, s'il y a eu défilement. Si vous effectuez des requêtes HTTP pures sans rendu JS, et que le site attend l'exécution d'un script pour obtenir un token (par exemple, un challenge JavaScript anti-bot), la requête sans exécution de ce script reçoit automatiquement un 429 ou un 403.

La solution dépend de l'échelle : pour de petits volumes, l'utilisation d'un navigateur headless (Playwright, Puppeteer) avec émulation des mouvements de la souris et des délais aléatoires convient. Pour le parsing industriel — randomisation de l'ordre de parcours des produits, ajout de « bruit » sous forme de requêtes sur des ressources secondaires, variabilité des intervalles de temps selon une distribution normale, et non selon un pas fixe.

Raison 5 : Empreinte TLS/JA3 et HTTP/2

C'est la raison technique la plus « discrète », que 90 % des personnes s'occupant de parsing sans formation technique approfondie ne connaissent pas. Chaque client TLS (bibliothèque requests, curl, urllib) laisse une empreinte unique lors de l'établissement d'une connexion HTTPS — un ensemble de chiffrements pris en charge, de versions de protocole, d'extensions TLS. Cette empreinte est appelée empreinte JA3/JA4.

Les systèmes anti-bots de niveau Cloudflare, Akamai et les solutions internes des grandes marketplaces comparent l'empreinte JA3 avec une base de données de bots et de bibliothèques connus. Les requests Python standard ou le module https de Node.js ont une empreinte facilement détectable, complètement différente de l'empreinte d'un vrai Chrome. Même avec des en-têtes et des cookies parfaits, la requête est bloquée précisément au niveau du handshake TLS, avant que le serveur ne voie les en-têtes HTTP.

De plus, de nombreuses marketplaces exigent HTTP/2 avec des paramètres spécifiques (ordre des frames SETTINGS, priorisation des flux) — les bibliothèques basées sur HTTP/1.1 se distinguent automatiquement dans ce contexte. La solution consiste à utiliser des bibliothèques qui émulent l'empreinte d'un vrai navigateur : curl_cffi (émule l'empreinte TLS de Chrome), tls-client, ou de véritables navigateurs headless basés sur Chromium, qui donnent une empreinte « réelle » par définition.

pip install curl_cffi

Exemple : curl_cffi.requests.get(url, impersonate="chrome120") — la bibliothèque insère automatiquement une empreinte TLS identique à celle de Chrome 120.

Raison 6 : Limite au niveau du compte ou de la clé API

Si vous travaillez via l'API officielle ou semi-officielle de la marketplace (par exemple, l'API vendeur Wildberries ou l'API vendeur Ozon), le 429 peut être lié non pas à l'IP, mais au compte vendeur lui-même ou au token API. Dans ce cas, changer de proxy est totalement inutile — la limite est stockée côté serveur liée à votre identifiant de compte, et n'importe quelle IP de ce compte recevra la même restriction.

Cette situation est typique pour les vendeurs qui surveillent simultanément les prix des concurrents via leur espace personnel et interrogent l'API pour extraire les stocks — les deux flux de requêtes s'additionnent dans la limite totale du compte. La solution consiste à répartir la charge dans le temps, à utiliser les quotas API officiels de manière plus économique (cacher les données qui ne changent pas chaque minute), et pour la surveillance pure des prix des concurrents, à utiliser un flux de requêtes non autorisé séparé, non lié au compte vendeur.

Vérifier cela est simple : si le 429 persiste même lors d'une requête depuis une nouvelle IP propre et sans aucun cookie des sessions précédentes, mais que vous êtes connecté à votre espace personnel dans un onglet voisin — il est fort probable que la limite soit liée au compte.

Comment diagnostiquer la véritable raison

Avant de changer d'infrastructure, effectuez un diagnostic selon l'algorithme suivant. D'abord, ouvrez la page manuellement dans un navigateur normal et assurez-vous que le 429 ne se produit pas avec un comportement réel — cela confirmera que le problème vient du parser, et non d'un blocage global de la région.

Ensuite, comparez les en-têtes de votre parser avec ceux d'un vrai navigateur via DevTools (onglet Réseau → Copier en tant que cURL). Si la différence est minimale, vérifiez l'empreinte TLS via des services comme tls.peet.ws — envoyez une requête avec votre bibliothèque et comparez le hachage JA3 avec celui du navigateur de référence. Si la requête échoue au stade du handshake TLS (la connexion est interrompue avant la réception de la réponse HTTP) — la raison est dans l'empreinte, et non dans la fréquence ou les en-têtes.

Ensuite, vérifiez si la limite est liée à l'IP ou au compte : faites une requête depuis une nouvelle IP propre sans autorisation. Si le 429 disparaît — le problème était dans la réputation de l'IP précédente ou dans la fréquence depuis cette adresse. Si le 429 persiste — cherchez la raison dans les en-têtes, TLS ou le comportement, et non dans le proxy.

Checklist pour résoudre le 429 sans changer de proxy

Ajoutez des délais aléatoires de 1 à 4 secondes entre les requêtes au lieu d'un intervalle fixe.
Copiez l'ensemble complet des en-têtes d'un vrai navigateur, y compris Sec-Fetch-* et Accept-Language.
Conservez et transmettez les cookies dans le cadre d'une seule session, en commençant par le réchauffement de la page principale.
Vérifiez l'empreinte TLS de votre bibliothèque — utilisez curl_cffi ou un navigateur headless au lieu d'un client HTTP pur.
Randomisez l'ordre de parcours des pages et ajoutez des requêtes « bruit » sur des ressources statiques.
Répartissez la charge de l'API du compte et de la surveillance anonyme des prix sur différents flux.
Implémentez un backoff exponentiel lors de la réception d'un 429, et non une répétition immédiate de la requête.
Ce n'est qu'après avoir vérifié tous les points ci-dessus que vous devriez changer de proxy ou élargir le pool d'IP.

Quand les proxies sont-ils nécessaires et lesquels choisir

Après avoir éliminé toutes les six raisons, les proxies restent un élément important de l'infrastructure — mais désormais comme moyen d'évoluer, et non comme unique moyen de lutter contre les blocages. Si votre tâche consiste à surveiller parallèlement des milliers de fiches Wildberries et Ozon depuis différents « utilisateurs virtuels », vous avez besoin d'un pool d'IP avec une bonne réputation, afin de ne pas accumuler l'historique des blocages sur une seule adresse.

Pour la surveillance massive des prix et des catalogues des marketplaces, les proxies résidentiels sont les mieux adaptés — ils utilisent de vraies IP de fournisseurs domestiques, donc les systèmes anti-bots perçoivent les requêtes comme du trafic de clients ordinaires, et non de centres de données. C'est critique, car Wildberries et Ozon ont depuis longtemps des listes noires de plages d'IP de centres de données.

Si la tâche est liée à la vérification de la version mobile du site, au travail via l'application de la marketplace ou à la test de publicités sur TikTok Ads et Facebook Ads avec une précision géographique jusqu'à la ville, les proxies mobiles sont pertinents — ils ont le niveau de confiance maximal auprès de la plupart des systèmes de protection, car les IP appartiennent à de véritables opérateurs de téléphonie mobile.

Pour des tâches moins sensibles — par exemple, le parsing de catalogues ouverts sans autorisation sur de petits volumes — vous pouvez utiliser des proxies de centres de données : ils sont beaucoup moins chers et plus rapides, mais nécessitent une configuration plus minutieuse des en-têtes et de l'empreinte TLS, car ils comportent eux-mêmes un risque plus élevé d'être suspectés.

Type de proxy	Quand cela résout le 429	Quand cela ne fonctionnera pas
Résidentiels	IP déjà sur liste noire pour réputation	Blocage par empreinte TLS ou en-têtes
Mobiles	Nécessite une confiance maximale de l'IP pour des scénarios sensibles	Limite liée au compte, et non à l'IP
Centre de données	Parsing simple de pages ouvertes sans autorisation	Systèmes anti-bots stricts avec vérification de la réputation des plages

Conclusion

L'erreur 429 lors du parsing se résout rarement par un simple bouton « changer de proxy ». Dans la plupart des cas, le problème réside dans la fréquence des requêtes, des en-têtes incomplets, l'absence de session cookie, une empreinte TLS détectable, des modèles comportementaux ou des limites liées au compte, et non à l'adresse IP. Passez en revue chaque point des six mentionnés dans cet article avant de dépenser votre budget pour élargir le pool de proxies.

Lorsque la partie technique est correctement configurée — les en-têtes correspondent à un vrai navigateur, l'empreinte TLS ne révèle pas la bibliothèque, et les requêtes imitent le comportement naturel d'un utilisateur — les proxies deviennent un véritable outil d'évolutivité. Pour la surveillance des prix sur Wildberries et Ozon à grande échelle, nous recommandons de commencer par des proxies résidentiels : ils offrent le meilleur équilibre entre coût et niveau de confiance des systèmes anti-bots.