Choisir un proxy pour le scraping est en réalité une question de cible, pas de proxy. Un site sans défenses et un site protégé par DataDome nécessitent des configurations complètement différentes, et payer des tarifs résidentiels pour le premier gaspille de l’argent tandis que pointer des IP datacenter vers le second gaspille du temps.
Ce guide couvre quel type de proxy convient à quel travail de scraping, comment les utiliser sans se faire bloquer, et quand une API de scraping est une meilleure réponse que des proxies bruts.
Les Quatre Types, pour le Scraping
| Type | Source des IP | Vitesse | Taux de blocage | Coût | Travail de scraping le plus adapté |
|---|---|---|---|---|---|
| Datacenter | Fournisseurs d’hébergement | Le plus élevé | Élevé sur les sites défendus | Le plus bas | Sites non protégés, API, récupération en masse |
| Résidentiel | FAI grand public, vrais foyers | Modérée | Faible | Moyen, par GB | Retail, voyage, recherche, tout ce qui est défendu |
| ISP | FAI grand public, hébergé en datacenter | Élevée | Faible à modéré | Par IP par mois | Sessions connectées, tâches longue durée |
| Mobile | Opérateurs mobiles | Modérée à faible | Le plus bas | Le plus élevé | Les cibles les plus difficiles, API d’applications |
Une correction qui mérite d’être faite, car l’inverse est largement diffusé et cet article le répétait auparavant : les IP datacenter ne sont pas délivrées par des FAI. Elles sont enregistrées auprès de fournisseurs d’hébergement et de cloud et ne transitent jamais par un fournisseur internet grand public. C’est exactement pour cette raison qu’elles sont identifiables : les plages sont publiques, donc un site peut les classer au premier coup d’œil.
Les proxies ISP et mobiles comptent tous deux pour le scraping et sont généralement laissés de côté dans des comparaisons comme celle-ci. Les proxies ISP sont la réponse chaque fois qu’un scraping implique une connexion, car l’adresse reste fixe. Les proxies mobiles sont le dernier recours pour les cibles qui déjouent tout le reste.
Rotation et Gestion des Sessions
La stratégie de rotation compte plus que le type de proxy pour éviter le blocage.
La rotation par requête fournit une nouvelle IP à chaque requête. C’est le bon choix par défaut pour collecter des pages indépendantes : listes de produits, résultats de recherche, entrées d’annuaire. Aucune adresse unique n’accumule un schéma suspect.
Les sessions persistantes conservent une IP pendant une durée définie, typiquement de 1 à 30 minutes. Utilisez-les chaque fois que les requêtes dépendent les unes des autres : pagination portant un curseur, tout ce qui suit une connexion, parcours de paiement en plusieurs étapes. Une session qui change d’IP à mi-chemin ressemble à un vol de compte et déclenche des vérifications.
La règle pratique : tournez par requête sauf si quelque chose dans le flux exige de la continuité, auquel cas conservez la fenêtre persistante la plus courte qui la couvre.
Débit de Requêtes et Concurrence
La plupart des blocages sont causés par le débit, pas par le type de proxy. Une IP résidentielle qui frappe un site 20 fois par seconde est plus manifestement automatisée qu’une IP datacenter qui le frappe une fois toutes les 10 secondes.
- Débit par IP. Sur un site défendu, limitez chaque adresse à environ une requête toutes les 2 à 5 secondes. Sur un site non protégé, vous pouvez être bien plus agressif.
- Concurrence. Le débit total est le nombre d’adresses simultanées multiplié par le débit par IP. Pour obtenir 10 requêtes par seconde en toute sécurité, vous voulez de l’ordre de 30 à 50 adresses en vol, pas 10 adresses allant trois fois plus vite.
- Randomisez. Des intervalles fixes constituent une signature en soi. Ajoutez du jitter pour que les écarts varient.
- Reculez en cas d’échec. Lorsque les taux d’erreur augmentent, ralentissez plutôt que de réessayer plus fort. Réessayer face à un blocage est la manière dont une limitation de débit légère devient un bannissement définitif.
En-têtes et Empreintes
Une IP vous amène à la porte. La requête doit avoir l’air correcte une fois sur place.
- Envoyez un ensemble d’en-têtes complet et cohérent. Les vrais navigateurs envoient
Accept,Accept-Language,Accept-Encoding,User-AgentetSec-Ch-Uadans une combinaison cohérente. UnUser-Agentisolé sur une requête par ailleurs dépouillée est un signal fort de bot. - Gardez la cohérence des en-têtes avec l’IP. Une IP allemande envoyant
Accept-Language: en-USest une incohérence à éviter quand vous ciblez géographiquement. - Faites correspondre le comportement TLS et HTTP au client que vous prétendez être. Les systèmes avancés relèvent l’empreinte de la poignée de main TLS et l’ordonnancement des trames HTTP/2, donc un client Python prétendant être Chrome est détectable indépendamment des en-têtes.
- Utilisez un vrai navigateur quand la page en a besoin. Les sites qui rendent le contenu en JavaScript nécessitent un navigateur headless, et les navigateurs headless ont leurs propres empreintes qu’il faut gérer.
Systèmes Anti-Bot Modernes
Cloudflare, DataDome, PerimeterX et Akamai ne sont pas des listes noires d’IP. Ils évaluent une combinaison de la réputation de l’adresse, de l’empreinte de la requête, du comportement et des résultats de défis JavaScript.
Cela a deux conséquences. Faire tourner les IP seules ne les déjouera pas, car votre empreinte reste inchangée. Et une IP résidentielle est nécessaire mais pas suffisante : elle élimine le signal le plus facile, laissant les plus difficiles.
Quand vous en rencontrez un :
- Lisez correctement la réponse. Un 403 avec une page de défi est différent d’une limitation 429 et nécessite une correction différente. Vérifiez le corps, pas seulement le code de statut.
- Ralentissez d’abord. Le débit est la chose la moins coûteuse à modifier et souvent la cause réelle.
- Montez dans l’échelle de confiance. Datacenter vers résidentiel, résidentiel vers mobile.
- Rendez le défi. Si le site nécessite l’exécution de JavaScript, un client HTTP simple ne passera jamais, quelle que soit l’IP utilisée.
- Reconsidérez l’approche. Si une cible coûte plus en tentatives répétées que la valeur des données, une API gérée est moins chère que de continuer à la combattre.
Coût, Volume et Quand Utiliser une API
Estimer un projet commence par le poids des pages. Une page HTML typique fait 0,5 à 2 MB, donc 100 000 pages représentent environ 50 à 200 GB. Le rendu JavaScript multiplie cela plusieurs fois, car vous récupérez aussi les scripts, styles et images.
Le chiffre qui décide réellement de votre facture est le taux de blocage. Une configuration qui échoue sur 40% des requêtes et les retente paie cette bande passante deux fois. Les proxies bon marché avec un taux d’échec élevé coûtent fréquemment plus cher par page réussie que les proxies chers.
Les proxies bruts sont le bon choix quand vous contrôlez le scraper, que la cible est comprise, et que vous voulez le coût le plus bas par unité. Une API gérée est le meilleur choix quand la cible résiste fortement, quand vous devriez sinon maintenir des empreintes de navigateur et des solveurs de défis, ou quand le temps d’ingénierie est la ressource rare plutôt que l’argent.
L’API de Web Scraping de Shifter gère la rotation de proxies, le rendu JavaScript et les défis derrière une seule requête, et l’API SERP fait de même spécifiquement pour les résultats de recherche, qui sont sinon l’une des cibles les plus pénibles à maintenir. Pour les proxies bruts, les proxies résidentiels et les proxies ISP couvrent les deux extrémités de la question de session, et les tarifs actuels se trouvent sur la page des tarifs.
Un Cadre de Décision Rapide
- La cible n’a pas de protection anti-bot et vous avez besoin de volume à bas coût : proxies datacenter.
- La cible limite le débit ou vous met au défi, sans connexion impliquée : résidentiel rotatif.
- Le scraping nécessite une session connectée ou doit conserver une identité : proxies ISP.
- La cible déjoue le résidentiel, ou vous avez besoin d’un accès au niveau de l’application : proxies mobiles.
- La cible coûte plus en maintenance que la valeur des données : une API de scraping.
La plupart des projets réels combinent tout cela. La collecte tourne sur du résidentiel rotatif, la poignée de tableaux de bord authentifiés tourne sur ISP, et l’unique cible impossible passe par l’API.
Conclusion
Il n’existe pas de meilleur proxy unique pour le scraping. Adaptez le type à la difficulté avec laquelle la cible se défend, adaptez la rotation au fait que vos requêtes dépendent ou non les unes des autres, et traitez le débit de requêtes comme la première chose à ajuster quand les blocages apparaissent.
Pour la taxonomie plus large, voir types de proxies, et pour le cas d’usage complet, l’aperçu du web scraping.