Scraping poli qui reste évolutif : un guide sur la limitation de débit
Marteler un site vous fait bannir ; explorer un site une requête à la fois ne vous mène nulle part. Le juste milieu évolutif est un rythme adaptatif par domaine, réparti sur des IP propres — poli pour le site, rapide pour vous.
Près de la moitié du trafic Internet est désormais automatisé, et les sites web le savent. La limitation de débit est leur première et plus basique défense — une limite de vitesse qui décide de combien vous pouvez prendre et à quelle vitesse. La tentation est de la traiter comme un obstacle à franchir par la force brute, mais cela vous fait bannir. L'erreur opposée, explorer une requête prudente à la fois, ne vous mène nulle part à grande échelle. La réponse évolutive est le scraping poli : rythme chaque cible comme le ferait un utilisateur lourd mais légitime, répartissez la charge sur des IP propres, et laissez les réponses du site ajuster votre vitesse. C'est ainsi que vous restez rapide sans devenir le trafic qui fait bloquer tout le monde.
Sachez quelle limite vous atteignez
Les serveurs comptent vos requêtes par rapport à un identifiant — généralement votre IP, parfois une clé API ou un compte — sur une fenêtre temporelle, et agissent lorsque vous franchissez un seuil. Les trois modèles courants se comportent différemment : une fenêtre fixe compte les requêtes par minute calendaire ; un seau de jetons vous remet un nombre fixe de jetons (disons 100 par minute) et en dépense un par requête, forçant une attente lorsque le seau est vide ; une fenêtre glissante compte sur les 60 dernières secondes roulantes à tout instant. La conséquence pratique est qu'une rafale est plus dangereuse qu'un flux constant — dix requêtes en une seconde peuvent déclencher une limite qu'une centaine répartie sur une minute ne déclencherait pas.
Les limites existent aussi en différentes saveurs. Les limites douces sont légères : le serveur vous ralentit, ou renvoie 429 Too Many Requests avec un en-tête Retry-After vous indiquant exactement combien de temps attendre (l'erreur 1015 de Cloudflare est de ce type). Certains sites tolèrent de petites rafales — permettant 100 par minute mais ne limitant qu'à 120 — tandis que d'autres limitent tôt, disons à 15 par minute, et ne bloquent complètement qu'à 30. Les limites strictes sont des plafonds rigides : une API qui permet 1 000 requêtes par heure vous verrouille complètement une fois que vous les dépassez. Poussez une limite douce de manière répétée et elle s'intensifie : 429 devient 403, puis une interdiction temporaire de quelques minutes à quelques heures dont la fenêtre s'allonge chaque fois que vous la déclenchez, et enfin une liste noire permanente de votre IP ou de tout le sous-réseau.
Lisez la réponse, ne devinez pas
La plus grande amélioration pour un scraper est de réagir à ce que le serveur vous dit au lieu de balancer un taux fixe. Apprenez le vocabulaire : 429 signifie ralentir et respecter Retry-After ; 403 signifie que cette identité est signalée, donc tournez plutôt que de réessayer ; 503 est souvent un défi ou un rejet temporaire ; et un 200 qui retourne une page CAPTCHA est un blocage doux, pas un succès. Traitez chacun différemment. La mauvaise décision — réessayer la même IP brûlée sur un 403, ou ignorer Retry-After et marteler à travers un 429 — est ce qui transforme un avertissement doux en une interdiction permanente. Nos analyses approfondies sur la résolution des 429 couvrent en détail la gestion des réponses.
import time, requests
def polite_get(session, url, max_tries=4):
for attempt in range(max_tries):
r = session.get(url, timeout=20)
if r.status_code == 200 and "captcha" not in r.text.lower():
return r
if r.status_code == 429: # obey the server
wait = int(r.headers.get("Retry-After", 2 ** attempt))
time.sleep(wait)
continue
if r.status_code in (403, 503): # this exit is burned
rotate_ip(session) # fresh IP, then retry
time.sleep(2 ** attempt) # exponential backoff
continue
return r
return None
Budgétisez les requêtes par domaine
Un crawler qui touche de nombreux sites ne devrait jamais appliquer un taux global à tous. Un petit blog et une place de marché renforcée tolèrent des charges très différentes, donc donnez à chaque domaine son propre budget. Un seau de jetons par hôte est le modèle propre : attribuez un taux conservateur par domaine, remplissez-le au fil du temps, et laissez les requêtes vers différents hôtes s'exécuter en parallèle tandis que les requêtes vers le même hôte restent dans sa limite. Commencez lentement sur une nouvelle cible et laissez les codes de réponse vous indiquer si vous pouvez accélérer.
import time
from collections import defaultdict
class DomainLimiter:
def __init__(self, per_min=30):
self.gap = 60.0 / per_min # min seconds between hits per host
self.last = defaultdict(float)
def wait(self, host):
now = time.time()
delay = self.gap - (now - self.last[host])
if delay > 0:
time.sleep(delay)
self.last[host] = time.time()
# 30 req/min to any single host; different hosts proceed independently
limiter = DomainLimiter(per_min=30)
limiter.wait("example.com")Répartissez la charge pour que chaque IP reste polie
Voici le mouvement qui réconcilie "poli" avec "évolutif" : la politesse est mesurée par IP, mais votre débit total est la somme sur les IP. Si une cible tolère 30 requêtes par minute par adresse, une IP vous limite à 30 — mais dix IP propres, chacune effectuant 30, vous donnent 300 par minute tandis que chaque sortie individuelle reste courtoise. Une passerelle résidentielle rotative fait cela automatiquement, fournissant une IP fraîche par requête sur plus de 90 millions d'adresses pour qu'aucune sortie unique ne semble agressive. Ce n'est pas un tour pour marteler plus fort ; c'est distribuer une charge réelle pour qu'aucun serveur ne supporte un pic suspect. Les fondamentaux de la rotation des IP sont dans ce qu'est la rotation des IP et pourquoi elle est cruciale.
Répartissez la charge sur des IP rotatives propres
Prenez moins, cachez plus, choisissez vos heures
La requête la plus polie est celle que vous n'envoyez jamais. Trois habitudes réduisent la charge sans vous coûter de données. Premièrement, cachez de manière agressive et utilisez des requêtes conditionnelles — envoyez If-Modified-Since ou If-None-Match pour qu'une page inchangée renvoie un petit 304 au lieu du corps complet, ce qui épargne le serveur et votre bande passante. Deuxièmement, budgétisez la concurrence délibérément : un sémaphore limitant les requêtes en cours par domaine vous empêche de faire des rafales accidentelles. Troisièmement, programmez les tâches lourdes pour les heures creuses de la cible, lorsque votre trafic représente une part plus petite du leur et est moins susceptible de déclencher un seuil. Combinées, ces habitudes peuvent réduire de moitié les requêtes nécessaires à une tâche — la discipline derrière notre liste de contrôle anti-interdiction plus large.
Une chose de plus qui vaut la peine d'être dite clairement : vérifiez robots.txt et respectez les attentes de crawl déclarées d'un site. La politesse n'est pas seulement de l'auto-préservation — être un bon citoyen garde le web ouvert et accessible à tous. Notre guide sur robots.txt en pratique couvre ce qu'il fait et ne lie pas.
Questions fréquemment posées
Comment éviter la limitation de débit lors du scraping ?
Rythmez chaque domaine avec son propre budget de requêtes, respectez Retry-After sur les 429, reculez de manière exponentielle, et répartissez la charge sur un pool rotatif d'IP propres pour qu'aucune adresse unique ne semble agressive. Ajoutez la mise en cache et les requêtes conditionnelles pour envoyer moins de requêtes au total, et programmez les tâches lourdes pour les heures creuses de la cible.
Que signifie HTTP 429 et comment dois-je le gérer ?
429 Too Many Requests est une limite de débit douce — le serveur vous demande de ralentir, pas de vous bannir. Lisez l'en-tête Retry-After et attendez exactement aussi longtemps avant de réessayer ; s'il est absent, reculez de manière exponentielle. Ne l'ignorez jamais et ne continuez pas à marteler, car des 429 répétés escaladent en 403 puis en interdictions temporaires ou permanentes.
Combien de requêtes par minute est sûr ?
Il n'y a pas de nombre universel — cela dépend entièrement de la cible. Un petit site peut tolérer seulement quelques requêtes par minute ; un grand, bien plus. Commencez prudemment (disons 20–30 par minute par IP), surveillez les 429, et ajustez à partir des réponses. Augmentez le débit total en ajoutant des IP, pas en augmentant le taux sur une seule.
Les proxies rotatifs sont-ils considérés comme impolis ?
Pas lorsqu'ils sont utilisés pour distribuer une charge réelle. La rotation garde chaque IP individuelle dans un taux courtois tandis que votre débit global augmente — le serveur ne voit jamais un pic suspect d'une seule adresse. Cela devient impoli seulement si vous l'utilisez pour dépasser ce que le site peut raisonnablement gérer en tout ; rythme l'ensemble, pas seulement le taux par IP.
Poli et évolutif ne sont pas opposés. Lisez les signaux, respectez Retry-After, budgétisez par domaine, cachez ce que vous pouvez, et répartissez le reste sur des IP rotatives propres. Vous finissez plus rapide que le scraper imprudent — parce que vous êtes celui qui ne se fait jamais bannir.