L'erreur classique lors de l'échelle d'un scraper est d'acheter des proxies "à l'aveugle" : on prend 100 IP, on lance le scraper, et on reçoit des bans au bout de 30 minutes. Le problème n'est pas le nombre d'adresses, mais le fait que personne ne calcule la charge réelle sur chaque IP. Analysons la formule de calcul du pool de proxies, basée sur le RPS (requêtes par seconde), les délais et les limites du site cible — avec des chiffres concrets et du code en Python.
Pourquoi compter le pool par le nombre d'IP est une erreur
L'approche typique d'un novice en scraping : "il faut collecter 50 000 fiches produits, donc achetons 500 proxies et répartissons la charge". La logique semble saine, mais elle ne prend pas en compte l'essentiel : des sites comme Wildberries et Ozon ne bannissent pas en fonction du nombre absolu de requêtes, mais en fonction de l'intensité des requêtes d'une seule IP dans un laps de temps donné. Ainsi, 500 proxies, chacun envoyant 20 requêtes par seconde, seront bannis instantanément — les systèmes anti-bot détectent un schéma similaire à un DDoS.
D'un autre côté, si vous avez 50 proxies, mais que chacun fait 1 requête toutes les 5-10 secondes avec des pauses aléatoires, imitant le comportement humain, vous pouvez scraper de manière stable pendant des semaines sans aucun ban. Le nombre d'IP n'est pas la cause de la stabilité, mais la conséquence d'une charge correctement calculée. C'est pourquoi la formule doit se baser non pas sur "combien d'IP acheter", mais sur "quel RPS doit-on atteindre et quelle est la charge sûre par IP".
Un autre point : différents types de proxies ont une "marge de sécurité" différente par IP. Les proxies de centre de données sont bannis plus rapidement à haute fréquence de requêtes, car leurs sous-réseaux sont facilement reconnus comme des hébergements. Les IP résidentiels et mobiles ressemblent à des utilisateurs ordinaires, et on peut leur permettre une fréquence légèrement plus élevée sans risque de blocage — mais cela ne signifie pas qu'on peut ignorer les limites complètement.
Formule de base pour le calcul du pool de proxies
La formule pour calculer le nombre de proxies dans le pool est la suivante :
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Où :
- N — nombre nécessaire de proxies dans le pool ;
- RPS_target — vitesse cible de scraping (requêtes par seconde sur l'ensemble du système) ;
- Delay_per_ip — pause minimale sûre entre les requêtes d'une seule IP (en secondes) ;
- Concurrency_per_ip — combien de flux parallèles vous autorisez sur une seule IP (généralement 1, maximum 2 pour les proxies résidentiels).
La logique est simple : si vous souhaitez maintenir 10 requêtes par seconde au total, et que la pause sûre entre les requêtes d'une seule IP est de 8 secondes, alors une IP peut physiquement émettre seulement 1 requête toutes les 8 secondes, soit 0,125 RPS. Pour obtenir 10 RPS au total, il vous faut 10 / 0,125 = 80 proxies. C'est ce calcul qui remplace la supposition de "500 IP au cas où".
Comment calculer le RPS cible pour le scraping
Avant de calculer le pool, il faut déterminer le RPS_target — combien de requêtes par seconde vous avez réellement besoin pour collecter les données dans un délai raisonnable. La formule ici est inverse :
RPS_target = Total_requests / Time_budget_seconds
Exemple : il faut collecter 100 000 fiches produits de Wildberries en 8 heures (28 800 secondes). Si chaque fiche nécessite 1 requête, RPS_target = 100 000 / 28 800 ≈ 3,47 requêtes par seconde. Ce n'est pas autant que cela peut sembler au premier abord — beaucoup surestiment la vitesse nécessaire et achètent un nombre excessif de proxies.
Si la tâche implique plusieurs types de requêtes (par exemple, d'abord obtenir la liste des catégories, puis les fiches produits, puis les avis), calculez le RPS pour chaque étape séparément — elles peuvent se dérouler en parallèle avec différents pools de proxies, et la charge totale sur la plateforme sera répartie sur différents points de terminaison.
Limites par IP : combien de requêtes par minute est sûr
Delay_per_ip est le paramètre le plus important dans la formule, et il doit être déterminé empiriquement pour chaque site. Voici des repères généraux, basés sur la pratique du scraping des marketplaces :
| Plateforme | Pause sûre entre les requêtes d'1 IP | Maximum de requêtes/min avec 1 IP |
|---|---|---|
| Wildberries (API des fiches produits) | 4-6 sec | 10-15 |
| Ozon (pages produits) | 5-8 sec | 8-12 |
| Avito (annonces) | 6-10 sec | 6-10 |
| Yandex.Market | 5-7 sec | 8-12 |
Ces chiffres sont un point de départ, pas une dogme. Commencez avec des valeurs conservatrices (limite supérieure de la pause), surveillez le pourcentage d'erreurs 429 et 403, et réduisez progressivement la pause si les bans n'augmentent pas. Augmenter brusquement le RPS sans tests progressifs est la manière la plus courante de perdre tout le pool de proxies en un jour.
Calculs pratiques : Wildberries, Ozon, Avito
Analysons trois scénarios réels avec un calcul complet selon la formule.
Scénario 1 : surveillance des prix sur Wildberries. Il faut mettre à jour les prix de 20 000 produits toutes les 2 heures. RPS_target = 20 000 / (2 × 3600) ≈ 2,78 RPS. Avec une pause de 5 sec par IP et Concurrency = 1 : N = (2,78 × 5) / 1 ≈ 14 proxies. Pour une marge en cas de ban d'une partie des IP, il est recommandé de prendre un pool avec un coefficient de 1,5-2x, soit 21-28 proxies.
Scénario 2 : collecte unique du catalogue Ozon. 500 000 fiches en 24 heures. RPS_target = 500 000 / 86 400 ≈ 5,79 RPS. Avec une pause de 6 sec : N = (5,79 × 6) / 1 ≈ 35 proxies. Avec une marge — 50-60 proxies.
Scénario 3 : surveillance des concurrents sur Avito en temps réel. 5000 annonces, mise à jour toutes les 15 minutes. RPS_target = 5000 / 900 ≈ 5,56 RPS. Avec une pause de 8 sec : N = (5,56 × 8) / 1 ≈ 45 proxies. Ici, il est important de noter qu'Avito bannit activement les sous-réseaux de centres de données, donc pour cette tâche, il est plus raisonnable d'utiliser directement des IP résidentiels ou mobiles.
Proxies résidentiels, mobiles et de centre de données dans la formule
Le type de proxy influence directement le Delay_per_ip et, par conséquent, le N final dans la formule. Les proxies de centre de données sont moins chers et plus rapides, mais nécessitent des pauses plus longues entre les requêtes et sont plus souvent bannis à des fréquences élevées — en fait, pour les mêmes 5 RPS, vous pourriez avoir besoin de 2-3 fois plus d'IP de centre de données que de résidentiels.
| Type de proxy | Délai moyen par IP | Quand utiliser |
|---|---|---|
| Proxies de centre de données | 8-15 sec | APIs ouvertes, sites sans anti-bot strict |
| Proxies résidentiels | 4-8 sec | Wildberries, Ozon, Avito et autres marketplaces avec anti-bot |
| Proxies mobiles | 3-6 sec | Les protections les plus agressives, réseaux sociaux, APIs mobiles |
Pour le scraping de marketplaces comme Wildberries et Ozon, le choix optimal est généralement les proxies résidentiels — ils équilibrent le prix et la stabilité, permettant de maintenir des pauses plus courtes sans augmentation brutale des bans. Les proxies de centre de données ne devraient être envisagés que pour des sites sans anti-bot agressif ou pour des tâches ponctuelles avec un RPS faible.
Implémentation du pool en Python : code avec rotation
Ci-dessous, une implémentation simplifiée d'un pool de proxies avec contrôle de la fréquence des requêtes pour chaque IP. La logique : chaque proxy conserve le temps de dernière utilisation, et le planificateur choisit uniquement les IP pour lesquelles suffisamment de temps s'est écoulé depuis la dernière requête.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # pause sûre en secondes
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# choisir au hasard parmi les disponibles, pour éviter le schéma de file d'attente
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Formule : N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Exemple d'utilisation
rps_target = 5.79 # calculé à partir du volume de la tâche et du temps
delay_per_ip = 6.0 # pause sûre pour Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Proxies nécessaires dans le pool : {n_proxies}") # ~35, avec une marge de 50-60
Dans un scraper réel, cette logique doit être complétée par une file d'attente de tâches (par exemple, via asyncio ou multiprocessing), pour que les workers attendent l'apparition d'un proxy libre, plutôt que de se terminer avec une erreur en leur absence. Il est également judicieux d'ajouter un backoff exponentiel lors de la réception de 429/403 — cela augmentera automatiquement la pause pour une IP spécifique en cas de signes de blocage.
Surveillance et correction dynamique du pool
Le calcul statique selon la formule est un point de départ, pas une solution finale. En exploitation réelle, il est nécessaire de suivre trois métriques clés :
- Taux de succès — pourcentage de requêtes réussies (code 200) par rapport au nombre total. Une chute en dessous de 90-95% signale qu'il faut augmenter le Delay_per_ip ou ajouter des proxies au pool ;
- Taux de ban — proportion de proxies montrant des signes de blocage (captcha, 403, redirection vers un formulaire de vérification) au cours de la dernière heure ;
- RPS réel — vitesse réelle de traitement des requêtes, qui peut différer de celle calculée en raison de timeouts et de tentatives répétées.
Règle pratique : si le taux de ban dépasse 5-7% par heure, augmentez le Delay_per_ip de 20-30% et recalculer N selon la formule. Si le taux de succès reste constamment supérieur à 98% pendant plusieurs heures, vous pouvez progressivement réduire la pause et diminuer la taille du pool — cela représente une économie directe du budget pour les proxies sans perte de stabilité.
Une bonne pratique consiste à tenir un journal pour chaque IP séparément : temps de dernière requête réussie, nombre d'erreurs consécutives, temps de réponse moyen. Cela permet d'exclure automatiquement les proxies "défectueux" de la rotation pendant 30-60 minutes au lieu de continuer à envoyer des requêtes à travers eux et de recevoir un captcha à chaque étape.
Erreurs fréquentes lors du calcul du pool de proxies
Même en connaissant la formule, il est facile de se tromper dans les détails du calcul. Voici une liste des erreurs typiques :
- Ignorer la marge pour les bans. Même avec un calcul parfait, 5-10% des proxies seront temporairement indisponibles en raison de blocages ou de problèmes réseau. Ajoutez toujours un coefficient de 1,3-2x au N de base ;
- Delay_per_ip identique pour tous les points de terminaison. La page de catégorie et la page de fiche produit peuvent avoir des limites différentes — calculez séparément ;
- Concurrency supérieure à 1 sans test. Les requêtes parallèles d'une seule IP augmentent considérablement le risque de ban, surtout sur des proxies résidentiels — commencez avec Concurrency = 1 ;
- Absence de rotation des User-Agent et des en-têtes. Même un pool de proxies correctement calculé ne sauvera pas si toutes les requêtes proviennent de la même empreinte de navigateur ;
- Pause fixe sans jitter. Un intervalle strictement identique entre les requêtes (par exemple, exactement 5,0 sec) est un schéma facilement reconnaissable par les anti-bots. Ajoutez une variation aléatoire de ±20-30%.
Conclusion
La formule N = (RPS_target × Delay_per_ip) / Concurrency_per_ip transforme le calcul du pool de proxies d'une devinette en une tâche d'ingénierie avec des chiffres concrets. Commencez par déterminer la vitesse cible de scraping en fonction du volume de données et du temps, puis trouvez empiriquement la pause sûre pour la plateforme spécifique, et seulement après cela, calculez le nombre nécessaire d'IP — avec une marge de 30-100% pour les bans et les pannes.
Cette approche permet d'économiser le budget : au lieu d'acheter un nombre excessif d'IP "au cas où", vous payez exactement pour le volume de proxies nécessaire pour atteindre le RPS cible sans risque de blocages. Pour le scraping des marketplaces et d'autres sites protégés, nous recommandons de commencer avec des proxies résidentiels — ils offrent le meilleur équilibre entre stabilité et coût lors de l'interaction avec les systèmes anti-bots de Wildberries, Ozon et Avito.