Les proxies résidentiels sont ce que nous vendons, il peut donc sembler étrange que nous écrivions sur les cas où vous n’en avez pas besoin. Mais les équipes qui achètent des proxies pour chaque tâche dépensent trop, et celles qui blâment le proxy pour chaque échec perdent des semaines. Savoir quels sites ont besoin d’une IP résidentielle, lesquels n’ont besoin de rien, et lesquels ont besoin de tout autre chose, est l’optimisation la moins chère en matière de collecte de données web.
Pour rendre cela concret, nous avons mené un petit test. Le 9 octobre 2026, nous avons requêté 30 pages publiques, trois fois chacune, depuis un serveur cloud avec une adresse IP de centre de données, puis à nouveau via des proxies résidentiels Shifter avec des sorties US. Les deux exécutions utilisaient le même client HTTP Python simple. Seize des 30 pages ont fonctionné depuis l’IP de centre de données à chaque fois. Trois n’ont fonctionné qu’avec les sorties résidentielles. Les onze restantes ont échoué dans les deux cas, pour des raisons qu’une IP résidentielle ne résout pas.
Le test
Les cibles couvraient six types de sites : API publiques et données ouvertes, sites de référence et de documentation, pages d’accueil de sites d’actualités, pages de recherche de e-commerce, pages de recherche de voyage, et un ensemble de pages sociales, d’emploi et de recherche. Chaque requête utilisait le même User-Agent de navigateur de bureau et était vérifiée pour un contenu réel, pas seulement un code de statut : une réponse n’était comptée comme un succès que si elle contenait un marqueur qui n’apparaît que dans le contenu réel, comme une carte de résultat de recherche. Les pages de blocage qui renvoient le statut 200, ce qui est courant, étaient donc comptées comme des échecs.
Nous avons choisi les marqueurs en inspectant des réponses sauvegardées des deux réseaux avant l’exécution finale, et avons abandonné cinq pages candidates où nous ne pouvions pas distinguer un contenu réel d’un mur de connexion ou d’une coquille JavaScript vide.
| Catégorie | Site | IP de centre de données | Sorties résidentielles | Verdict |
|---|---|---|---|---|
| API publiques et données ouvertes | en.wikipedia.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| API publiques et données ouvertes | api.github.com | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| API publiques et données ouvertes | data.sec.gov | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| API publiques et données ouvertes | api.worldbank.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| API publiques et données ouvertes | ecb.europa.eu | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Référence et documentation | docs.python.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Référence et documentation | developer.mozilla.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Référence et documentation | rfc-editor.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Référence et documentation | en.wikipedia.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Référence et documentation | arxiv.org | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Référence et documentation | stackoverflow.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Actualités | bbc.com | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Actualités | reuters.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Actualités | nytimes.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Actualités | theguardian.com | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Actualités | edition.cnn.com | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Actualités | bloomberg.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Recherche e-commerce | amazon.com | 3 sur 3 | 2 sur 3 | Aucun proxy nécessaire |
| Recherche e-commerce | walmart.com | 0 sur 3 | 3 sur 3 | IP résidentielle nécessaire |
| Recherche e-commerce | ebay.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Recherche e-commerce | bestbuy.com | 0 sur 3 | 0 sur 3 | Délai dépassé dans les deux cas |
| Recherche e-commerce | etsy.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Voyage | booking.com | 0 sur 3 | 2 sur 3 | IP résidentielle nécessaire |
| Voyage | expedia.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Voyage | airbnb.com | 3 sur 3 | 2 sur 3 | Aucun proxy nécessaire |
| Voyage | tripadvisor.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Voyage | kayak.com | 0 sur 3 | 3 sur 3 | IP résidentielle nécessaire |
| Social, emploi et recherche | linkedin.com | 3 sur 3 | 3 sur 3 | Aucun proxy nécessaire |
| Social, emploi et recherche | indeed.com | 0 sur 3 | 0 sur 3 | Bloqué dans les deux cas |
| Social, emploi et recherche | google.com | 0 sur 3 | 0 sur 3 | Nécessite un navigateur |
« Bloqué dans les deux cas » signifie qu’un client HTTP simple était bloqué sur les deux réseaux. Un véritable navigateur ou une API de scraping qui gère les vérifications de navigateur pourrait très bien réussir sur ces sites ; ce test ne l’a pas tenté.
Ce que disent les résultats
Les API publiques, les données ouvertes et la documentation n’ont besoin d’aucun proxy. Chaque API et page de référence que nous avons testée, sauf une, a fonctionné depuis une IP de centre de données à chaque tentative. Ces services sont conçus pour être utilisés par des programmes. Ce qu’ils veulent, c’est un User-Agent descriptif, des taux de requêtes raisonnables et, pour certains, une clé d’API. Un proxy ajoute un coût et rien d’autre.
De nombreux grands sites ne bloquent pas du tout les IP de centre de données. Trois des six pages d’accueil d’actualités, la recherche Amazon, la recherche Airbnb et une page d’entreprise LinkedIn ont servi un contenu réel à un serveur cloud trois fois sur trois. Pour une collecte à faible volume depuis des sites comme ceux-ci, commencer sans proxy est raisonnable, tant que vous restez dans les conditions d’utilisation et les limites de taux du site.
Certains sites bloquent selon la réputation de l’IP, et c’est là que les sorties résidentielles comptent. Walmart, Kayak et Booking.com ont refusé l’IP de centre de données à chaque fois et servi du contenu via des sorties résidentielles. Ces sites évaluent le réseau d’où provient une requête, et l’adresse d’un serveur cloud obtient un mauvais score. C’est exactement le cas pour lequel les proxies résidentiels existent.
Certains sites bloquent le client, pas l’IP. eBay, Etsy, Expedia, Tripadvisor, Indeed, Stack Overflow et trois sites d’actualités ont bloqué le client Python simple sur les deux réseaux. Ils vérifient comment le client se connecte et se comporte, comme son empreinte TLS, ses en-têtes HTTP et s’il exécute du JavaScript, avant de regarder d’où il vient. Une IP résidentielle ne corrige pas un client qui s’annonce comme un script. Notre guide sur l’empreinte TLS et HTTP/2 explique le fonctionnement de ces vérifications.
Certaines pages nécessitent un navigateur quel que soit le réseau. La recherche Google a renvoyé une page demandant du JavaScript aux deux réseaux, sans résultats dans le HTML. Pour des pages comme celle-ci, le choix se situe entre un navigateur headless et une API qui renvoie directement les données.
Comment déterminer ce dont un site a besoin
Vous pouvez classer la plupart des cibles dans ces groupes en un après-midi, avant d’acheter quoi que ce soit. La fonction ci-dessous est la vérification que nous avons utilisée dans le test : elle récupère une page et détermine si vous avez obtenu le contenu réel, un blocage, une erreur ou une coquille vide.
import re
import requests
BLOCK = re.compile(r"captcha|access denied|are you a robot|just a moment|unusual traffic|"
r"verify you are human|request blocked|pardon our interruption|enable javascript and cookies",
re.IGNORECASE)
HEADERS = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
}
def check(url, marker, proxies=None):
"""Did this request get the real content, or a block, an error or an empty shell?"""
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=30)
except requests.RequestException as error:
return {"url": url, "result": "error", "detail": type(error).__name__}
body = response.text
if response.status_code != 200:
result = "blocked" if response.status_code in (202, 401, 403, 429, 503) else "error"
elif BLOCK.search(body[:20000]) and marker.lower() not in body.lower():
result = "blocked"
elif marker.lower() not in body.lower():
result = "no content"
else:
result = "ok"
return {"url": url, "result": result, "status": response.status_code, "bytes": len(response.content)}Choisissez un marqueur qui n’apparaît que dans le contenu que vous voulez, comme le nom de classe d’une carte de résultat ou un nom de champ dans une réponse JSON. N’utilisez pas un mot du titre de la page : les pages de blocage et les murs de connexion le répètent souvent. Exécutez-la ensuite sur quelques pages de chaque cible :
from check import check
print(check("https://api.github.com/repos/python/cpython", '"full_name"'))
print(check("https://www.ebay.com/sch/i.html?_nkw=laptop", "srp-results")){'url': 'https://api.github.com/repos/python/cpython', 'result': 'ok', 'status': 200, 'bytes': 6617}
{'url': 'https://www.ebay.com/sch/i.html?_nkw=laptop', 'result': 'blocked', 'status': 403, 'bytes': 1832}Exécutez-la depuis l’endroit où votre scraper fonctionnera réellement (un serveur cloud, pas votre ordinateur portable, si c’est là que la production se déroule), plusieurs fois sur une journée. Les résultats se traduisent en une décision :
| Ce que vous voyez depuis un serveur cloud | Ce que cela signifie généralement | Ce qu’il faut utiliser |
|---|---|---|
| Contenu réel, de manière constante | Le site ne bloque pas le trafic de centre de données à votre volume | Aucun proxy, ou une IP de centre de données pour l’échelle |
| Blocages ou défis, et contenu réel depuis une connexion domestique | Le site bloque selon la réputation de l’IP | Proxies résidentiels |
| Blocages sur tous les réseaux | Le site vérifie le client | Un véritable navigateur ou une API de scraping, généralement avec des IP résidentielles en dessous |
| Coquilles vides sans données | Le contenu est rendu par JavaScript | Un navigateur headless, ou l’API que la page appelle |
| Murs de connexion | Le contenu n’est pas public | Ne le collectez pas sans autorisation |
Deux précisions :
- Le volume change la réponse. Un site qui ignore dix requêtes depuis un serveur cloud peut en bloquer dix mille. Retestez au rythme auquel vous prévoyez de fonctionner, pas une seule fois.
- La localisation change la réponse. Les sites servent un contenu différent et appliquent des règles différentes selon le pays. Si vous avez besoin de données telles que vues depuis l’Allemagne, testez depuis l’Allemagne.
Les options intermédiaires
Le choix ne se situe pas uniquement entre aucun proxy et des proxies résidentiels.
- Les IP de centre de données sont bon marché et rapides, et conviennent aux sites qui ne les bloquent pas. Notre comparaison des proxies ISP et de centre de données couvre les cas où elles suffisent.
- Les proxies ISP sont des adresses statiques enregistrées auprès de fournisseurs d’accès internet grand public. Ils conviennent aux sessions longues et aux connexions à vos propres comptes, où vous voulez la même IP pendant plusieurs jours. Les proxies ISP de Shifter sont assortis d’un trafic illimité, ils conviennent donc aussi aux charges de travail lourdes et constantes sur les sites qui les acceptent.
- Une API de scraping gère le navigateur, les nouvelles tentatives et le choix de l’IP pour vous, et facture par page réussie plutôt que par gigaoctet. C’est souvent l’option la moins chère pour les sites qui vérifient le client, car vous n’avez pas à construire et à maintenir vous-même la couche navigateur. Voir notre guide sur le scraping de sites riches en JavaScript.
- Les proxies résidentiels sont l’outil approprié lorsqu’un site juge le réseau d’où provient une requête : lorsque le même client réussit depuis une connexion domestique et échoue depuis un serveur cloud.
FAQ
Ai-je besoin d’un proxy pour le web scraping ?
Pas toujours. Dans notre test, 16 des 30 pages publiques, y compris chaque API publique et la plupart des sites de documentation, ont servi un contenu réel à un serveur cloud sans proxy. Testez d’abord vos cibles, depuis l’endroit où votre scraper fonctionnera.
Quand ai-je besoin d’un proxy résidentiel ?
Lorsqu’un site bloque les requêtes provenant d’IP de centre de données mais sert le même client depuis une connexion domestique. Dans notre test, trois des 30 sites (Walmart, Kayak et Booking.com) se sont comportés ainsi.
Pourquoi suis-je encore bloqué avec un proxy résidentiel ?
Généralement parce que le site vérifie le client, pas l’IP. De nombreux sites bloquent les clients HTTP dont l’empreinte TLS, les en-têtes ou l’absence de JavaScript les identifient comme des scripts. Onze des 30 pages de notre test ont échoué sur les deux réseaux avec un client Python simple. Un véritable navigateur ou une API de scraping est la solution, pas une IP différente.
Les proxies de centre de données suffisent-ils pour le scraping ?
Pour les API publiques, la documentation, de nombreux sites d’actualités et certains grands détaillants, oui, à des volumes modérés. Pour les sites qui évaluent la réputation de l’IP, non. Testez chaque cible plutôt que de supposer.
En résumé
Un proxy résidentiel résout un problème spécifique : un site qui juge les requêtes selon le réseau d’où elles proviennent. Il n’aide pas avec les sites qui vérifient le client, et il est inutile pour les API publiques et les sites qui ne bloquent pas le trafic cloud. Testez chaque cible depuis l’endroit où votre scraper fonctionnera, classez-la dans l’un de ces groupes, et ne payez pour du trafic résidentiel que là où cela change le résultat. Nos bonnes pratiques de web scraping couvrent le reste d’une collecte responsable.