Limite de trafic pour le scraping de Wildberries et Ozon : comment ne pas épuiser un mois de forfait proxy en une nuit

Le vendeur lance un scraper de prix des concurrents la nuit, et le matin reçoit une notification : le trafic est épuisé, le forfait est consommé à 90 %. Une situation familière ? Le plus souvent, ce n'est pas le scraper lui-même qui est en cause, mais l'absence de limites au niveau des proxies et du script. Dans cet article, nous examinerons comment le trafic « fuit » inutilement et comment mettre en place une protection pour que le forfait mensuel de proxies résidentiels ou mobiles dure jusqu'à la fin de la période de calcul.

Pourquoi le trafic s'épuise en une nuit

Le scraping de Wildberries, Ozon ou Avito semble être une tâche simple : vous envoyez une requête — vous recevez un JSON avec le prix. Mais en pratique, le trafic est consommé non seulement pour des données utiles. Les principales sources de surconsommation sont :

• Chargement d'images et de médias. Si le scraper ouvre la page du produit entièrement via un navigateur (et ne fait pas de requête directe à l'API), il charge automatiquement des images, des vidéos, des bannières — ce qui représente des dizaines de mégaoctets par fiche produit.
• Requêtes répétées à cause des captchas et des blocages. Le marketplace reconnaît le bot, affiche un captcha ou bloque temporairement l'IP, le script fait une nouvelle requête — le trafic est gaspillé, et les données ne parviennent pas.
• Absence de mise en cache des requêtes. Sans logique « déjà scrappé cette heure — ne pas répéter », le script peut interroger les mêmes fiches plusieurs fois par nuit.
• Flux parallèles sans limitation. Lancer 50-100 flux simultanément semble accélérer le travail, mais le trafic est consommé beaucoup plus rapidement que prévu, et une partie des requêtes est simplement bloquée.
• Mauvais choix de type de proxy. Les proxies résidentiels et mobiles sont généralement facturés en fonction du volume de trafic (Go), contrairement aux proxies de centres de données, où le paiement se fait souvent par nombre d'IP ou durée de location. Si le scraper est configuré sur un pool résidentiel sans contrôle — la limite s'épuise rapidement.

La combinaison de ces facteurs conduit à ce qu'un script, prévu pour un mois de travail, consomme un forfait de trafic en une seule session nocturne de scraping de 10-20 000 fiches produits.

Comment le trafic est calculé pour différents types de proxies

Avant de définir des limites, il est important de comprendre pour quoi vous payez exactement. Différents types de proxies calculent la consommation de manière différente, et cela influence directement la stratégie d'économie.

Type de proxy	Tarification	Risque de surconsommation	Quand appliquer
Proxies résidentiels	Par volume de trafic (Go)	Élevé sans limites	Scraping avec contournement de la protection anti-bot des marketplaces
Proxies mobiles	Par volume de trafic ou par temps	Élevé, le trafic est plus cher	Scraping des versions mobiles des sites, contournement des blocages stricts
Proxies de centres de données	Par nombre d'IP / temps de location	Faible, le trafic est généralement illimité	Scraping massif sans protection anti-bot stricte

Si vous scrapez Wildberries ou Ozon, où la protection contre les bots est active, les IP résidentielles ou mobiles sont presque toujours nécessaires — les adresses de centres de données sont rapidement bloquées. Mais c'est précisément à cause de la tarification par trafic qu'il est particulièrement important de définir des limites à l'avance.

Combien de trafic est réellement nécessaire pour le scraping

Pour définir une limite adéquate, il faut se baser sur des chiffres réels, et non sur des impressions. Les dépenses approximatives en pratique :

• Requête à l'API de la fiche produit (JSON, sans images) : 5-30 Ko par fiche. Pour 10 000 fiches — environ 50-300 Mo.
• Chargement de la page produit via un navigateur sans tête avec images : 1-3 Mo par fiche. Pour les mêmes 10 000 fiches — 10-30 Go.
• Surveillance des prix toutes les heures pour 1000 SKU : avec des requêtes allégées — environ 1-5 Go par jour, avec chargement complet des pages — 50-100 Go par jour.

La différence entre le scraping « léger » et « lourd » est de plusieurs ordres de grandeur. Par conséquent, la première étape pour économiser du trafic est de désactiver le chargement des images, des vidéos et des scripts tiers là où c'est possible, et de travailler directement avec l'API du marketplace ou la version mobile du site, qui pèse moins que la version de bureau.

Limites dans les navigateurs anti-détection et les gestionnaires de proxies

Pour ceux qui scrappent via un navigateur anti-détection (par exemple, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) ou un gestionnaire de proxies personnel, le moyen le plus simple de limiter la consommation est de configurer des limites au niveau du profil et du compte du fournisseur de proxies.

1. Connectez-vous au tableau de bord du fournisseur de proxies et trouvez la section de gestion du trafic ou des limites pour les sous-utilisateurs/ports.
2. Créez un sous-compte ou un port séparé pour le scraping — n'utilisez pas le même pool de proxies que pour le farming de comptes sur Instagram ou TikTok. La séparation par tâches montre immédiatement où va le trafic.
3. Définissez une limite de trafic quotidienne ou horaire sur ce sous-compte — par exemple, 5 Go par jour au lieu de consommer tout le forfait mensuel en une seule session.
4. Dans le navigateur anti-détection, désactivez le chargement automatique des images pour les profils utilisés uniquement pour la collecte de données, et non pour la visualisation des pages.
5. Configurez un calendrier de lancement des profils de manière à ce que le scraping se fasse non pas en une longue session, mais en courtes intervalles avec des pauses — cela réduit le risque de blocage et permet de suivre la consommation de trafic entre les lancements.

Cette approche est particulièrement importante pour les agences et les freelances qui effectuent le scraping de plusieurs marketplaces simultanément : sans séparation par sous-comptes, il est difficile de comprendre quel projet « consomme » le trafic.

Limitation du trafic au niveau du script et de l'API

Si le scraper est écrit en Python ou Node.js, les limites peuvent et doivent être intégrées directement dans le code — cela permet un contrôle plus précis que les paramètres de l'interface du fournisseur de proxies.

Exemple d'un simple compteur de trafic en Python utilisant requests :

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # limite de 5 Go par jour
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("La limite quotidienne de trafic est atteinte, le scraping est arrêté")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# exemple d'appel
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Trafic utilisé :", round(used_bytes / 1024 / 1024, 2), "Mo")

La logique est simple : le script calcule le volume de chaque réponse en octets et s'arrête dès que la limite définie est atteinte. Cela protège contre la situation où, en raison d'une erreur dans la boucle ou d'une répétition infinie des requêtes, le script « consomme » un forfait mensuel de trafic en quelques heures.

Il est également utile d'ajouter :

• Délai exponentiel en cas d'erreurs (retry avec backoff) — au lieu de répéter immédiatement la requête en cas de captcha ou de blocage, le script attend un intervalle croissant (5 sec, 15 sec, 60 sec), ce qui réduit le nombre de requêtes inutiles.
• Limitation du nombre de flux parallèles — par exemple, pas plus de 10-20 connexions simultanées via le pool de proxies, afin de ne pas provoquer de blocages et de ne pas gaspiller le trafic.
• Désactivation du chargement des ressources dans le navigateur sans tête — si le scraping se fait via Selenium ou Puppeteer, dans les paramètres du navigateur, vous pouvez bloquer le chargement des images, des polices et des CSS, ne laissant que les réponses HTML/JSON.

Surveillance de la consommation en temps réel

Une limite sans surveillance fonctionne moins bien, car vous ne découvrez le problème qu'après l'arrêt du script. Pour contrôler la consommation en temps réel :

• Activez les notifications dans le tableau de bord du fournisseur de proxies lorsque 50 %, 80 % et 100 % du forfait mensuel de trafic sont atteints — la plupart des services prennent en charge de telles alertes par email ou sur Telegram.
• Tenez un simple journal dans le script lui-même : enregistrez dans un fichier ou une base de données le volume de trafic par heure, afin de voir les pics de consommation et de trouver rapidement la source du problème.
• Divisez le trafic par tâches via des sous-comptes ou des étiquettes séparées — séparément pour le scraping de Wildberries, séparément pour Ozon, séparément pour Avito. Cela simplifie l'analyse de quel projet consomme le plus.
• Comparez la consommation avec le volume de données attendu : si 20 Go ont été consommés pour 10 000 fiches au lieu des 300 Mo prévus, cela signifie que des ressources supplémentaires sont chargées ou que des requêtes répétées sont effectuées.

Liste de contrôle pour le contrôle du budget de trafic

Erreurs fréquentes des débutants

En pratique, la plupart des forfaits de trafic « brûlés » s'expliquent par plusieurs erreurs typiques :

• Lancement du scraping « la nuit sans surveillance » sans limites. Le script fonctionne 8-10 heures sans interruption, et si un cycle de requêtes répétées se produit quelque part, le trafic est consommé en continu jusqu'au matin.
• Un pool de proxies commun pour toutes les tâches. Le farming de comptes sur Instagram, les tests de publicité sur Facebook Ads et le scraping d'Ozon utilisent le même trafic — il est impossible de comprendre ce qui le consomme.
• Ignorer le captcha. Au lieu de réduire la fréquence des requêtes aux premiers signes de captcha, le script continue de frapper le site avec la même intensité, gaspillant du trafic sur des réponses inutiles avec un code d'erreur.
• Choix de proxies résidentiels là où des proxies de centres de données suffisent. Si le marketplace ne bloque pas strictement les IP de centres de données, le surcoût pour le trafic du pool résidentiel n'est pas justifié — pour des objectifs moins protégés, des proxies de centres de données avec un autre modèle de tarification conviennent.
• Absence de test préalable. Avant de lancer un scraping complet sur des milliers de fiches, il est conseillé de faire passer le script sur 50-100 fiches et de mesurer la consommation réelle de trafic pour extrapoler sur le volume total.

Conclusion

Le trafic pour le scraping « s'épuise » non pas à cause du volume de données, mais en raison de l'absence de contrôle : images superflues, requêtes répétées lors des blocages, flux parallèles sans limites et pool de proxies commun pour toutes les tâches. La solution consiste à diviser le trafic par projets, à définir des limites quotidiennes au niveau du compte de proxy, à intégrer un compteur de consommation dans le script lui-même et à configurer une surveillance avec notifications avant que le forfait ne soit réellement épuisé.

Si vous scrapez des marketplaces avec une protection active contre les bots comme Wildberries ou Ozon, nous vous recommandons d'utiliser des proxies résidentiels pour contourner les blocages et, de plus, des IP mobiles pour les scénarios les plus sensibles à la protection anti-bot — mais dans les deux cas, assurez-vous de définir des limites de trafic à l'avance pour que le forfait mensuel ne soit pas épuisé en une seule session nocturne.