Lors du scraping des marketplaces, de l'automatisation des réseaux sociaux ou de la collecte de données via API, il est crucial de choisir la bonne stratégie d'envoi des requêtes. Une mauvaise configuration entraîne des blocages d'IP, des CAPTCHA et une perte de temps. Dans ce guide, nous allons examiner quand utiliser des requêtes parallèles pour une vitesse maximale et quand utiliser des requêtes séquentielles pour la sécurité.
Différences entre requêtes parallèles et séquentielles
Requêtes séquentielles — c'est lorsque votre script ou programme envoie des requêtes une par une : il attend la réponse à la première requête, puis envoie la deuxième. C'est lent, mais sûr et cela semble très naturel pour le site cible.
Requêtes parallèles — c'est lorsque plusieurs requêtes (5, 10, 50 ou même des centaines) sont envoyées simultanément, sans attendre les réponses aux précédentes. C'est beaucoup plus rapide, mais cela crée une charge sur le serveur et peut susciter des soupçons des systèmes anti-fraude.
Imaginez le scraping des prix de 10 000 produits sur Wildberries. Séquentiellement avec un délai de 2 secondes entre les requêtes — cela prend 20 000 secondes ou 5,5 heures. Si vous lancez 20 flux parallèles — seulement 16 minutes. La différence est évidente, mais il y a des nuances.
Important : Les requêtes parallèles ne signifient pas « envoyer 1000 requêtes en même temps ». C'est une parallélisation contrôlée — par exemple, 10-50 flux actifs, chacun avec des délais. Sans contrôle, vous obtiendrez immédiatement un ban.
Comparaison des méthodes
| Paramètre | Séquentielles | Parallèles |
|---|---|---|
| Vitesse | Lente (1 requête à la fois) | Rapide (10-100+ simultanément) |
| Risque de blocage | Faible | Moyen-élevé |
| Charge sur le proxy | Minimale | Élevée |
| Complexité de configuration | Simple | Nécessite de l'expérience |
| Consommation de mémoire | Faible | Élevée |
| Gestion des erreurs | Plus facile à suivre | Plus difficile à logger |
Quand utiliser des requêtes parallèles
Les requêtes parallèles sont le choix lorsque la vitesse est critique et que le volume de données est important. Mais il est important de comprendre : cela fonctionne uniquement avec une configuration correcte des proxies et un contrôle de la charge.
Scénarios idéaux pour les requêtes parallèles
1. Scraping de marketplaces avec un grand catalogue
Si vous devez collecter les prix de 50 000 produits sur Wildberries ou Ozon, le scraping séquentiel prendra des jours. Avec 20-30 flux parallèles et des proxies de datacenter, la tâche est résolue en quelques heures.
Configuration : 20-30 flux, chacun avec une IP distincte, délai de 1-3 secondes entre les requêtes à l'intérieur du flux. Rotation des IP toutes les 100-200 requêtes.
2. Collecte de données à partir d'API publiques
De nombreuses API (par exemple, services météorologiques, bases de données d'entreprises, services de géolocalisation) ont des limites sur les requêtes à partir d'une seule IP : 100-1000 par jour. Les requêtes parallèles via un pool de proxies permettent de contourner ces limites.
Exemple : Vous devez collecter des données sur 10 000 entreprises via une API. Limite — 500 requêtes/jour par IP. Vous utilisez 20 proxies en parallèle = 10 000 requêtes par jour au lieu de 20 jours.
3. Vérification de la disponibilité des ressources
Si vous vérifiez la disponibilité des sites, le fonctionnement des miroirs ou surveillez le statut des serveurs — les requêtes parallèles font gagner des heures. Ici, il n'est pas nécessaire d'imiter le comportement humain, seule la vitesse compte.
4. Vérification massive des proxies
Lors de l'achat de grands pools de proxies (1000+ IP), il est nécessaire de vérifier rapidement leur fonctionnalité, leur vitesse, leur géolocalisation. La vérification séquentielle prendra des heures, la vérification parallèle prendra des minutes.
Attention : Les requêtes parallèles NE conviennent PAS pour travailler avec des plateformes protégées (Facebook Ads, Instagram API, Google Ads), où l'imitation du comportement d'un utilisateur réel est importante. Utilisez des requêtes séquentielles là-bas.
Exigences clés pour les requêtes parallèles
- Grand pool de proxies (minimum 10-20 IP, mieux 50-100+)
- Rotation automatique des IP en cas d'erreurs
- Contrôle du nombre de flux simultanés (pas plus de 50-100)
- Délai entre les requêtes même à l'intérieur des flux (0.5-2 sec)
- Journalisation des erreurs pour analyser les causes des blocages
- Système de retry (tentatives de répétition) en cas de timeouts
Quand utiliser des requêtes séquentielles
Les requêtes séquentielles sont le choix de la sécurité et de la fiabilité par rapport à la vitesse. Elles imitent le comportement d'un utilisateur réel et minimisent le risque de blocage sur des plateformes protégées.
Scénarios obligatoires pour les requêtes séquentielles
1. Travail avec des tableaux de bord publicitaires
Facebook Ads, TikTok Ads, Google Ads suivent non seulement les IP, mais aussi les modèles de comportement. Les requêtes parallèles à partir d'un seul compte susciteront immédiatement des soupçons. Un compte = un flux = actions séquentielles avec des délais de 5-15 secondes.
Exemple : Vous gérez 20 tableaux de bord Facebook via un navigateur anti-détection Dolphin Anty. Chaque tableau fonctionne dans un profil distinct avec un proxy mobile, les actions sont strictement séquentielles : connexion → vérification des statistiques → ajustement des enchères → déconnexion. Délai de 7-12 secondes entre les actions.
2. Automatisation des actions sur les réseaux sociaux
Instagram, TikTok, VK ont des limites strictes sur les actions : likes, abonnements, commentaires. Dépasser les limites ou agir trop rapidement = shadowban ou blocage total. Seules les requêtes séquentielles avec des délais aléatoires de 20-60 secondes sont acceptables.
Configuration pour Instagram : Un compte peut faire un maximum de 60 likes/heure. Cela représente 1 like par minute avec des délais de 45-75 secondes (la randomisation est importante !). Utilisez un proxy distinct pour chaque compte.
3. Authentification et travail avec des comptes personnels
Toute action nécessitant une connexion à un compte (services email, banques, marketplaces en tant que vendeur) doit être effectuée séquentiellement. Les tentatives de connexion parallèles à partir de différentes IP sur un seul compte mènent directement à un blocage.
4. Sites avec une protection anti-bot stricte
Les plateformes avec Cloudflare, Akamai, PerimeterX analysent non seulement la fréquence des requêtes, mais aussi leurs modèles. Si 10 requêtes arrivent simultanément d'une seule IP ou User-Agent — c'est un signe évident de bot. Les requêtes séquentielles avec des délais de 3-10 secondes semblent naturelles.
5. Petit volume de données
Si vous devez scraper 50-100 pages, la différence de temps entre le scraping séquentiel et parallèle est insignifiante (5 minutes contre 1 minute). Cependant, la méthode séquentielle garantit l'absence de problèmes.
Délais appropriés pour les requêtes séquentielles
| Plateforme/tâche | Délai entre les requêtes | Randomisation |
|---|---|---|
| Facebook Ads (actions dans le tableau de bord) | 7-15 secondes | ±30% |
| Instagram (likes, abonnements) | 45-90 secondes | ±40% |
| TikTok (vues, likes) | 30-60 secondes | ±35% |
| Google Ads (requêtes API) | 5-10 secondes | ±25% |
| Scraping avec Cloudflare | 3-7 secondes | ±30% |
| Sites ordinaires sans protection | 1-3 secondes | ±20% |
Conseil : La randomisation des délais est cruciale. Si votre script effectue une requête exactement toutes les 5.00 secondes — c'est un modèle de bot. Utilisez random entre 4 et 7 secondes pour imiter un humain.
Risques de blocage selon les méthodes
Comprendre les risques aide à choisir la bonne stratégie et à configurer la protection. Les blocages se produisent non seulement à cause de la fréquence des requêtes, mais aussi à cause de leurs modèles.
Ce que surveillent les systèmes anti-fraude
1. Fréquence des requêtes depuis une seule IP
Si 100 requêtes par minute arrivent d'une seule IP — c'est clairement un bot. Les limites varient : les sites ordinaires tolèrent 10-30 requêtes/minute, les plateformes protégées — 2-5 requêtes/minute.
Solution pour les requêtes parallèles : Répartissez les requêtes sur un grand pool d'IP. Par exemple, 1000 requêtes/minute = 50 IP avec 20 requêtes chacune. Cela ressemble à 50 utilisateurs ordinaires.
2. Intervalles identiques entre les requêtes
Des requêtes exactement toutes les 2.00 secondes — signe d'automatisation. Un humain clique avec des intervalles différents : 1.8 sec, 3.2 sec, 2.1 sec.
Solution : Ajoutez de la randomisation ±30-50% par rapport au délai de base. Au lieu de 5 secondes fixes, utilisez random(3.5, 7.5).
3. Absence de comportement typique d'utilisateur
Un utilisateur réel ne va pas directement sur la page du produit — il commence par la page d'accueil, cherche la catégorie, clique sur le produit. Un bot demande immédiatement une URL spécifique.
Solution pour les plateformes critiques : Imitez le parcours complet de l'utilisateur. Avant de scraper le produit, effectuez 2-3 requêtes : accueil → catégorie → produit. Cela ralentit le travail, mais réduit le risque de blocage de 70-80%.
4. User-Agent et en-têtes suspects
User-Agent obsolètes (par exemple, Chrome 95 en 2024), absence d'en-têtes Accept-Language, Referer — signes d'un bot.
Solution : Utilisez des User-Agent actuels (Chrome 120+, Firefox 120+), ajoutez un ensemble complet d'en-têtes comme dans un vrai navigateur. Faites tourner le User-Agent avec l'IP.
Comparaison des risques de blocage
| Scénario | Risque en séquentielles | Risque en parallèles |
|---|---|---|
| Scraping d'une marketplace (10K requêtes) | Faible (5-10%) | Moyen (20-30%) |
| Travail avec Facebook Ads | Faible (2-5%) | Critique (80-95%) |
| Automatisation Instagram | Moyen (15-25%) | Élevé (60-80%) |
| APIs publiques (dans les limites) | Très faible (1-3%) | Faible (5-10%) |
| Sites avec Cloudflare | Moyen (10-20%) | Élevé (40-60%) |
Quels proxies conviennent à chaque méthode
Le type de proxy influence directement la possibilité d'utiliser des requêtes parallèles ou séquentielles. Un mauvais choix entraînera des blocages ou des surcoûts.
Proxies pour requêtes parallèles
Proxies de datacenter — le choix optimal pour le scraping massif et les requêtes parallèles. Ils sont bon marché (à partir de 1-3 $ par IP/mois), rapides (ping de 20-50 ms) et disponibles en grandes quantités. Inconvénient — facilement identifiables comme proxies, donc pas adaptés pour les plateformes protégées.
Quand utiliser : Scraping de marketplaces, collecte de données à partir de sources publiques, vérification de la disponibilité des ressources, requêtes API massives vers des services sans protection stricte.
Configuration : Achetez un pool de 50-100 IP, configurez 20-30 flux parallèles, chaque flux utilise sa propre IP. Rotation toutes les 100-200 requêtes ou en cas d'erreur.
Proxies résidentiels — plus chers (à partir de 3-7 $ par 1 Go de trafic), mais ressemblent à de vrais utilisateurs. Conviennent pour des requêtes parallèles vers des plateformes protégées, si la vitesse est nécessaire, mais avec prudence.
Quand utiliser : Scraping de réseaux sociaux (sans authentification), collecte de données sur des sites avec Cloudflare, travail avec des plateformes qui bloquent les datacenters. Pour des requêtes parallèles, un grand pool d'IP avec rotation automatique est nécessaire.
Important : Lors de requêtes parallèles via des proxies résidentiels, surveillez la consommation de trafic. 10 000 requêtes peuvent « manger » 5-10 Go, ce qui coûtera entre 20 et 50 $. Les datacenters sont moins chers : trafic illimité pour 100-200 $/mois pour 100 IP.
Proxies pour requêtes séquentielles
Proxies mobiles — le type le plus fiable pour travailler avec des plateformes protégées. Les IP ressemblent à de vrais appareils mobiles (opérateurs 4G/5G), ce qui minimise le risque de blocage. Inconvénient — coûteux (à partir de 50-150 $ par IP/mois).
Quand utiliser : Facebook Ads, Instagram, TikTok, Google Ads — tout ce qui nécessite une sécurité maximale et l'imitation d'un utilisateur réel. Un compte = un proxy mobile = actions séquentielles.
Configuration : Chaque tableau de bord publicitaire ou compte de réseau social est lié à une IP mobile distincte. Les actions sont strictement séquentielles avec des délais de 10-60 secondes. Les IP ne sont pas rotatives (un compte fonctionne toujours avec la même IP).
Proxies résidentiels — une bonne alternative aux mobiles, si le budget est limité. Conviennent pour des tâches moins critiques : scraping avec authentification, automatisation SMM, travail avec des marketplaces en tant que vendeur.
Quand utiliser : Gestion des comptes de marketplaces (Wildberries, Ozon en tant que vendeur), automatisation des publications sur les réseaux sociaux (pas en masse), scraping de données nécessitant une authentification.
Recommandations pour le choix des proxies
| Tâche | Type de proxy | Méthode de requêtes | Nombre d'IP |
|---|---|---|---|
| Scraping de marketplaces (grand volume) | Datacenters | Parallèles | 50-100+ |
| Facebook Ads (multi-comptes) | Mobiles | Séquentielles | 1 IP par compte |
| Automatisation Instagram | Mobiles/résidentiels | Séquentielles | 1 IP par compte |
| Scraping avec Cloudflare | Résidentiels | Parallèles (avec prudence) | 20-50 |
| APIs publiques (collecte massive) | Datacenters | Parallèles | 10-30 |
| Marketplaces (compte vendeur) | Résidentiels | Séquentielles | 1 IP par compte |
Paramètres optimaux : délais, flux, timeouts
La configuration correcte des paramètres est cruciale pour équilibrer vitesse et sécurité. Des paramètres trop agressifs entraîneront des blocages, des paramètres trop prudents entraîneront une perte de temps.
Configuration des requêtes parallèles
Nombre de flux simultanés (concurrence)
C'est un paramètre clé. Trop de flux = surcharge des proxies et du serveur cible. Trop peu = faible vitesse.
Recommandations :
- Scraping de marketplaces : 20-50 flux avec un pool de 50+ proxies
- APIs publiques : 10-30 flux, en fonction des limites de l'API
- Sites protégés : 5-15 flux, plus = risque de blocage
- Vérification des proxies : 50-100 flux (ici, la vitesse est plus importante)
Délai à l'intérieur des flux
Même en travaillant en parallèle, chaque flux doit faire des pauses entre ses requêtes. Cela réduit la charge sur une seule IP et diminue le risque de blocage.
Recommandations :
- Sites simples : 0.5-2 secondes entre les requêtes dans un même flux
- Marketplaces : 1-3 secondes avec randomisation ±30%
- Sites avec Cloudflare : 2-5 secondes avec randomisation ±40%
- APIs avec limites : calculez en fonction de la limite (par exemple, 100 requêtes/minute = 0.6 sec/requête, faites 1 sec pour la marge)
Timeouts (timeout)
Temps d'attente pour une réponse du serveur. Un timeout trop court = perte de données à cause de réponses lentes. Un timeout trop long = blocage des flux.
Recommandations :
- Sites rapides : 10-15 secondes
- Sites/API lents : 20-30 secondes
- Via proxies résidentiels : +5-10 secondes (ils sont plus lents que les datacenters)
- Connection timeout : 5-10 secondes (temps d'établissement de la connexion)
Retry (tentatives de répétition)
En cas d'erreurs (timeout, 503, blocage de proxy), il faut répéter la requête avec une autre IP. Sans retry, vous perdrez une partie des données.
Configuration : 2-3 tentatives par requête, changement de proxy après chaque tentative infructueuse, pause de 3-5 secondes avant le retry.
Configuration des requêtes séquentielles
Délai de base entre les requêtes
Dépend de la plateforme et du type d'actions. La règle principale : imiter un utilisateur réel.
Recommandations par plateforme :
- Facebook Ads (transitions entre les sections du tableau de bord) : 7-15 secondes
- Instagram (likes) : 45-90 secondes, maximum 60 likes/heure
- Instagram (abonnements) : 60-120 secondes, maximum 30 abonnements/heure
- TikTok (vues) : 30-60 secondes
- Scraping avec authentification : 3-7 secondes
- Marketplaces (actions dans le tableau de bord du vendeur) : 5-10 secondes
Randomisation
Obligatoire pour toutes les requêtes séquentielles. Utilisez une déviation de ±30-50% par rapport au délai de base.
Exemple : Délai de base de 10 secondes, randomisation ±40% → les délais réels seront de 6-14 secondes (valeur aléatoire à chaque fois).
Timeouts
Pour les requêtes séquentielles, vous pouvez utiliser des timeouts plus longs, car il n'y a pas de risque de blocage de tous les flux.
Recommandations : 30-60 secondes pour les plateformes protégées (Facebook, Instagram), 15-30 secondes pour les sites ordinaires.
Conseil pratique : Commencez par des paramètres conservateurs (moins de flux, plus de délais), augmentez progressivement l'agressivité en surveillant le pourcentage d'erreurs. Si les erreurs >5-10% — revenez en arrière d'un pas.
Outils pour mettre en œuvre les deux méthodes
Le choix de l'outil dépend de votre tâche et de vos compétences techniques. Pour les tâches commerciales (arbitrage, SMM, e-commerce), utilisez des solutions prêtes à l'emploi sans code. Pour les tâches techniques — bibliothèques et frameworks.
Solutions prêtes à l'emploi sans code (pour les entreprises)
Navigateurs anti-détection pour le multi-comptes
Si vous travaillez avec des tableaux de bord publicitaires ou des réseaux sociaux, les navigateurs anti-détection sont la norme de l'industrie. Ils gèrent automatiquement les proxies, les empreintes de navigateur et isolent les comptes.
Solutions populaires :
- Dolphin Anty : leader pour les arbitragistes Facebook/TikTok, tarif gratuit pour 10 profils, configuration simple des proxies
- AdsPower : bon pour l'e-commerce (Amazon, eBay), automatisation via RPA (sans code)
- Multilogin : le plus cher (100 $+/mois), mais protection maximale pour un arbitrage sérieux
- GoLogin : alternative économique (25 $/mois), adaptée pour SMM et petites équipes
Comment ils fonctionnent avec des proxies : Créez un profil de navigateur → associez un proxy → toutes les actions dans ce profil passent par cette IP. Un profil = un compte = actions séquentielles. Pour un travail parallèle, ouvrez plusieurs profils simultanément (chacun avec son proxy).
Parseurs et scrapers (prêts à l'emploi)
Pour collecter des données à partir de marketplaces et de sites, il existe des outils prêts à l'emploi avec une interface graphique, ne nécessitant pas de programmation.
- Octoparse : constructeur visuel de parseurs, support des proxies, possibilité de configurer des flux parallèles via l'interface
- ParseHub : équivalent d'Octoparse, tarif gratuit pour 200 pages, configuration des délais via l'interface graphique
- Scrapy Cloud : service cloud pour exécuter des spiders Scrapy (nécessite des connaissances minimales en Python)
Automatisation SMM (sans code)
Pour gérer les réseaux sociaux, il existe des services avec automatisation via une interface.
- Jarvee : automatisation Instagram, TikTok, Twitter, support intégré des proxies, configuration des délais via l'interface graphique (attention : une automatisation agressive entraîne des bans)
- Ingramer (Inflact) : automatisation sécurisée d'Instagram, fonctionne via leurs proxies
- Combin : abonnements/likes ciblés sur Instagram, support des proxies externes
Outils techniques (pour développeurs)
Si vous écrivez vos propres scripts pour le scraping ou l'automatisation, utilisez des bibliothèques éprouvées.
Python (le plus populaire pour le scraping) :
- Requests + threading/asyncio : pour des requêtes parallèles simples, facile à configurer avec des proxies
- aiohttp : bibliothèque asynchrone pour des requêtes hautement parallèles (1000+ simultanément)
- Scrapy : framework pour le scraping, support intégré de la rotation des proxies, middleware pour les délais
- Selenium : pour les sites avec JavaScript, plus lent, mais contourne de nombreuses protections
- Playwright : alternative moderne à Selenium, plus rapide et plus pratique
JavaScript/Node.js :
- Axios : bibliothèque populaire pour les requêtes HTTP, configuration simple des proxies
- Puppeteer : bibliothèque pour contrôler Chrome, idéale pour le scraping de sites JavaScript
- Node-fetch : pour des requêtes HTTP simples, similaire à Axios