Limites de scraping : 429, Retry-After et concurrence

Une limite de débit de scraping est une décision du serveur, pas un réglage de capacité du navigateur. Une réponse HTTP 429 signale trop de requêtes sur une période ; elle n’identifie pas la clé de comptage et n’autorise pas une autre route. BotBrowser documente les proxys au niveau du navigateur et de chaque contexte, mais ne modifie pas les quotas et ne garantit pas l’accès. Le diagnostic part de la réponse, de la charge permise et du journal des envois, puis distingue fréquence, travail en cours et nouvelles tentatives.

Lorsque les données exploitables laissent place à un défi pendant le même traitement, le diagnostic d’un CAPTCHA pendant le scraping relie la dernière réponse utile au premier défi sans transformer la séquence en cause.

Résumé

• Conserver HTTP 429, l’heure de réception et toute valeur de Retry-After avant de modifier la configuration.
• Considérer la clé de comptage comme inconnue tant que la documentation du service ou les journaux d’un serveur propre ne l’établissent pas.
• La concurrence compte le travail inachevé ; le débit compte les envois par intervalle. Une navigation peut produire plusieurs requêtes.
• Sur une installation propre, cesser d’augmenter la charge au premier 429. Ne pas sonder un service tiers pour découvrir sa limite opérationnelle.
• Respecter la borne temporelle et le budget de reprises ensemble. Une requête différée peut expirer sans nouvelle tentative.

Sommaire

• Ce qu’établit une réponse 429
• Trouver le périmètre de comptage dans les preuves serveur
• Mesurer débit et concurrence séparément
• Interpréter les deux formes de Retry-After
• Garder une file partagée et un budget fini
• Conserver un relevé expliquant l’arrêt
• Configuration de BotBrowser et politique serveur
• Conclusion pratique

Ce qu’établit une réponse 429

RFC 6585, section 4 définit 429 comme une réponse de limitation de débit. Elle peut inclure Retry-After ; son absence ne permet pas un trafic illimité. Le corps peut expliquer la situation, mais le statut seul n’établit ni bannissement de compte, ni verdict de réputation IP, ni détection d’empreinte du navigateur. Séparer le statut observé de ces explications possibles jusqu’à disposer d’une preuve pour l’une d’elles. Pour les échecs précédant toute réponse 429, le diagnostic par couche du scraper bloqué sépare preuves DNS, TLS, HTTP et données de page.

Identifier la requête qui a reçu cette réponse. Le document principal, un endpoint de données de même origine et une ressource correspondent à des requêtes distinctes. Une navigation réussie ne prouve pas la réussite de l’appel de données ; une application peut afficher une enveloppe périmée après la limitation de cet appel. Relier la réponse au champ ou enregistrement manquant plutôt que classer la page selon son apparence. Les exigences de charge SERP distinguent navigation terminée et données acceptées, distinction également utile ici.

Conserver l’URL finale sans secrets inutiles dans les paramètres, son statut, l’heure de réception, certains en-têtes et le rôle de la requête. En présence de redirections, garder les statuts séparément au lieu d’attribuer le 429 final à chaque saut. Un délai dépassé sans réponse n’est pas un 429 observé. Une page de défi renvoyée avec un autre statut exige aussi sa propre catégorie ; qualifier les deux de limites de débit fausse les comparaisons ultérieures.

La source établit une signification HTTP, pas une promesse de reprise. Atteindre l’heure suggérée ne réserve aucune capacité et ne garantit pas la réussite suivante. L’ordonnanceur a toujours besoin d’une autorisation, d’un budget restant et d’une opération pouvant être répétée. Conserver la réponse initiale même si une requête ultérieure fonctionne, afin qu’un compteur final de succès n’efface pas l’incident.

Trouver le périmètre de comptage dans les preuves serveur

RFC 6585 laisse volontairement au serveur l’identification de l’utilisateur et le comptage des requêtes. Une règle peut couvrir une ressource, un service plus large ou un compte authentifié. Un seul 429 ne distingue donc pas une règle par IP d’une règle par compte ou session. La référence MDN de 429 décrit un statut, pas la politique particulière du serveur ayant répondu.

Pour un service propre, examiner la configuration du limiteur et relier sa décision à l’identifiant de requête. Noter l’identifiant de règle, le groupe de ressources, la fenêtre de mesure et la catégorie documentée de clé. Stocker une référence expurgée plutôt que cookies, identifiants secrets ou compte en clair. Si passerelle et application limitent le trafic, identifier le composant ayant répondu avant d’attribuer sa politique à l’autre couche.

Pour une intégration tierce, utiliser ses quotas publiés ou une réponse autorisée du support. Si aucun ne précise le périmètre, écrire scope=unknown. Changer IP, cookie ou compte jusqu’à obtenir une autre réponse modifie plusieurs entrées sans établir la règle initiale. Cela peut aussi contrevenir à la politique du service. Un périmètre inconnu est un résultat d’incident valable ; une identité supposée n’améliore pas le diagnostic.

Séparer intention de configuration et observation. Un déploiement peut chercher à isoler les tâches par contexte alors que le serveur les compte dans un quota de compte partagé. Une route proxy peut être distincte tandis que la session applicative reste commune. Conserver ces faits séparément. Les frontières de stockage et les chemins réseau ne certifient pas à eux seuls la partition des quotas ni le modèle d’autorisation du serveur.

Mesurer débit et concurrence séparément

Le débit compte les envois par intervalle, par exemple les requêtes par seconde. La concurrence mesure les opérations encore en cours. Aucun des deux n’est le nombre d’onglets ouverts. Compter à la couche concernée par la politique : tâches, navigations et requêtes HTTP peuvent avoir des totaux différents. Une page demande parfois scripts, images et données en plus de son document ; des tâches par minute ne décrivent pas tout le débit HTTP.

À titre illustratif, 2 envois par seconde avec une durée moyenne de 3 secondes peuvent maintenir environ 6 requêtes inachevées dans une charge stable. C’est une approximation de planification, pas une mesure du navigateur ni un quota recommandé. Rafales, durées variables et requêtes dérivées peuvent invalider ce modèle. Conserver les horodatages et nombres réels d’opérations en cours sur une installation propre, au lieu de les déduire du nombre de travailleurs configuré.

inflight ≈ dispatches_per_second * mean_request_seconds

Définir séparément fréquence d’envoi et plafond d’opérations simultanées. Une concurrence de 4 n’impose aucun débit précis : des réponses rapides permettent beaucoup d’envois dans un court intervalle. Inversement, un faible débit peut accumuler du travail si les réponses ralentissent. Conserver ancienneté de file, durées, travail actif, reprises envoyées et enregistrements acceptés pour distinguer file croissante et rendement utile.

Une montée bornée sur une installation propre

Avant une vérification de charge, convenir avec le responsable du débit permis, de la concurrence maximale, de la durée de fenêtre, des plafonds de ressources et des conditions d’arrêt. Partir de la faible charge déclarée et progresser uniquement par niveaux préapprouvés. Au premier HTTP 429, arrêter les nouveaux envois, annuler le travail non commencé et conserver la réponse. Ne pas poursuivre pour découvrir combien de trafic supplémentaire le limiteur tolère. Le travail en cours nécessite une politique explicite d’annulation ou d’achèvement, car il peut déjà avoir atteint le serveur.

Le dernier niveau sans 429 n’est qu’une observation pour cet échantillon. Ce n’est ni une limite stable ni une autorisation de fonctionner indéfiniment à ce rythme. Le limiteur peut utiliser une fenêtre plus longue ou partager le quota avec d’autres clients autorisés. Répéter uniquement dans le plan convenu et interpréter à l’aide des journaux serveur. La grille de choix du navigateur traite la concurrence soutenable comme une preuve bornée par une charge, pas comme la capacité universelle d’une marque.

Interpréter les deux formes de Retry-After

HTTP Semantics, section 10.2.3 définit Retry-After comme une date HTTP ou un entier non négatif de secondes. La référence MDN Retry-After illustre les deux. Analyser l’en-tête avant de programmer et conserver le texte original avec son interprétation. Cela évite de prendre un intervalle pour des millisecondes ou une date pour une durée.

Avec Retry-After: 120, la borne proposée est 120 secondes après la réception de cette réponse. Si l’heure enregistrée est 12:00:00 GMT, la borne arithmétique est 12:02:00 GMT. Ce sont des données illustratives, pas un échange capturé. Mesurer depuis la réception, non depuis la création de tâche, le lancement du navigateur ou la lecture tardive d’un travailleur. Un consommateur de journaux retardé ne devrait pas recommencer un intervalle écoulé sans le signaler.

Retry-After: Mon, 09 Nov 2026 12:02:00 GMT désigne une date plutôt qu’une durée. La précision des horloges compte lors de la comparaison avec l’heure locale. Conserver l’heure de réception et l’en-tête serveur Date, s’il existe, comme éléments de diagnostic ; sa présence ne prouve pas l’exactitude d’une horloge. Une date passée ne crée aucune attente future, mais n’autorise pas non plus une boucle immédiate de reprises.

Employer une seule unité temporelle dans le calcul. Les champs suivants sont proposés pour le relevé d’incident ; ce ne sont ni une API du navigateur ni un algorithme obligatoire. headerNotBefore est la borne interprétée ; policyNotBefore, un délai plus strict de la politique documentée. L’échéance de tâche détermine si attendre reste utile :

eligibleAt = max(headerNotBefore, policyNotBefore)
if eligibleAt > jobDeadline: stop

Si l’en-tête manque, est mal formé ou dépasse les plages numériques ou calendaires prises en charge, conserver cet état au lieu de le convertir silencieusement en zéro. Appliquer une politique établie si elle existe ; sinon, arrêter pour décision. Retry-After: 0 diffère d’une valeur absente ou invalide, mais aucun de ces cas ne justifie des tentatives immédiates illimitées. Un analyseur prudent doit également signaler les formes non prises en charge au lieu d’accepter toute chaîne ressemblant à une date via un parseur permissif.

Garder une file partagée et un budget fini

L’attente indépendante de chaque travailleur peut synchroniser les redémarrages en fin de délai. Employer un répartiteur propriétaire de la borne temporelle du périmètre de quota connu, au lieu de laisser chaque navigateur reprendre simultanément. Si le périmètre est inconnu, suspendre les envois de l’intégration concernée sans inventer de quotas par contexte. C’est une politique opérationnelle proposée pour contenir la charge, pas une description du regroupement interne du serveur.

Conserver au moins trois budgets indépendants : échéance de tâche, tentatives maximales et quantité de travail autorisé restante. Une requête peut devenir admissible dans le temps tout en restant exclue par une échéance dépassée ou des tentatives épuisées. La file doit produire un résultat terminal, non la replacer en tête. Garder attemptsUsed, eligibleAt et jobDeadline dans le même relevé proposé pour permettre l’inspection de la décision.

Attente progressive et variation aléatoire sont deux contrôles distincts. Une politique documentée peut allonger le délai après des échecs répétés ; une variation non négative peut répartir les reprises autorisées plus tard. Aucun ne doit raccourcir une attente valide indiquée par le serveur. Ne pas ramener 120 secondes à 10 parce que le travailleur expire plus tôt : arrêter ou différer la tâche hors de ce travailleur. Le budget justifie de ne pas réessayer, pas de réessayer avant l’heure.

La sûreté d’une reprise dépend aussi de l’opération. Une lecture et une soumission d’achat n’ont pas les mêmes conséquences lorsqu’elles sont répétées. HTTP 429 seul ne détermine pas si une opération métier antérieure a modifié l’état. Exclure les opérations modificatrices d’une file générique de scraping et suivre les protections documentées contre les doublons. Éviter les reprises imbriquées dans ordonnanceur et bibliothèque sans budget commun ; une tâche visible pourrait produire plusieurs requêtes non comptées.

Conserver un relevé expliquant l’arrêt

Le relevé doit relier réponse HTTP et décision de planification. Utiliser un identifiant opaque d’exécution, une révision de l’installation ou de l’intégration, les versions du navigateur et du paquet et une référence de route expurgée. Noter heure, statut, rôle de requête, Retry-After original, état d’analyse, débit, concurrence et ancienneté de file. Ce sont des champs proposés pour un diagnostic borné, pas une affirmation que tout navigateur les expose automatiquement.

Observation	Valeur conservée	Décision étayée
Réponse	Statut, identifiant et réception	Une requête précise a reçu 429
En-tête	Texte original et état d’analyse	Attente interprétée ou inconnue
Périmètre	Règle documentée ou unknown	Quelle file est suspendue et pourquoi
Charge	Envois, travail en cours et reprises	Débit distinct du nombre de travailleurs
Budget	Tentatives, échéance et eligibleAt	Attendre, expirer ou arrêter
Résultat	Enregistrement accepté ou raison terminale	Navigation distincte de données acceptées

Séparer observations et politique. pauseReason=429 consigne un événement ; resumePolicy=documented-window, une règle choisie. « Probablement IP bloquée » relève, si conservé, d’une hypothèse non confirmée, pas des faits serveur. Cette séparation permet de réviser le diagnostic sans réécrire ce que contenait réellement la réponse.

Garder un journal de requêtes pour la fenêtre bornée. Inclure les tentatives échouées dans les totaux même sans enregistrement accepté. Compter séparément annulations avant et après envoi. Pour les pages à plusieurs ressources, conserver leur rôle pour ne pas confondre variation des images et variation de collecte des données. Limiter le contenu de réponse conservé au nécessaire, expurger les secrets et suivre la politique de conservation.

Après l’incident, comparer configuration effective et enregistrée avant toute reprise autorisée. Vérifier si un autre processus partage le quota documenté, si une couche de reprises est activée deux fois et si l’attente dépasse le temps restant. Ce sont des questions concrètes de configuration. Un nouveau navigateur, une route ou un contexte ne constitue pas une correction au seul motif qu’une réponse ultérieure diffère.

Configuration de BotBrowser et politique serveur

La documentation proxy de BotBrowser décrit --proxy-server et les réglages de routage pris en charge. La documentation du proxy dynamique décrit la modification du proxy d’un BrowserContext via une session CDP au niveau navigateur. Ce sont des capacités de configuration. Aucun de ces documents n’établit clé de comptage, fenêtre de réinitialisation ou débit autorisé d’un service externe.

Garder la route déclarée stable pendant le diagnostic pour que des changements sans rapport ne masquent pas la séquence de réponses. Conserver une référence expurgée de contexte et de route si l’intégration nécessite cette distinction. BotBrowser ne garantit pas qu’un autre contexte dispose d’un quota séparé, qu’un changement de route supprime un 429 ou qu’une configuration terminée accorde une autorisation. Une frontière imposée par le serveur reste applicable à la charge.

FAQ

Moins de travailleurs signifie-t-il toujours moins de requêtes ?

Non. Réponses rapides, ressources dérivées et reprises imbriquées peuvent augmenter les envois même avec moins de travailleurs. Mesurer le nombre et l’intervalle pertinents à la politique documentée.

Chaque 429 contient-il Retry-After ?

Non. RFC 6585 le rend facultatif. Consigner l’absence d’instructions puis appliquer la politique établie de l’intégration ou décider d’arrêter.

Changer de proxy prouve-t-il une limite par IP ?

Non. Un résultat différent n’identifie pas la règle initiale. Utiliser documentation du service ou décisions d’un serveur propre, sans changer de route pour contourner un quota.

Une heure de reprise dépassée garantit-elle le succès ?

Non. C’est une borne temporelle, pas une capacité réservée ni une promesse d’accès. Autorisation, sûreté de l’opération et budget restant s’appliquent toujours.

Sources

• RFC 6585, section 4 : 429 Too Many Requests
• RFC 9110, section 10.2.3 : Retry-After
• MDN : 429 Too Many Requests
• MDN : Retry-After
• BotBrowser : configuration proxy
• BotBrowser : proxy dynamique
• Exigences navigateur pour la collecte SERP
• Critères de sélection du navigateur

Conclusion pratique

Commencer par la réponse 429 précise et le journal des envois. Établir le périmètre depuis les preuves serveur, distinguer concurrence et débit, et laisser borne temporelle interprétée et budget fini gouverner toute reprise autorisée. Conserver les inconnues sans les remplacer par des suppositions d’identité. L’action immédiate consiste à suspendre les nouveaux envois et garder la réponse avant de modifier la charge.