Les proxys résidentiels sont ce que nous vendons, il peut donc sembler étrange que nous écrivions sur le moment où vous n’en avez pas besoin. Mais les équipes qui achètent des proxys pour chaque tâche dépensent trop, et les équipes 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 coûteuse 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 proxys résidentiels Shifter avec des sorties US. Les deux séries ont utilisé 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’via des sorties résidentielles. Les onze restantes ont échoué dans les deux cas, pour des raisons qu’une IP résidentielle ne corrige pas.
Notre test : 30 pages, IP de centre de données contre proxys résidentiels
Les cibles couvraient six types de sites : des API publiques et des données ouvertes, des sites de référence et de documentation, des pages d’accueil d’actualités, des pages de recherche e-commerce, des 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 du 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 un statut 200, ce qui est fréquent, comptaient donc comme des échecs.
Nous avons choisi les marqueurs en inspectant des réponses enregistrées des deux réseaux avant l’exécution finale, et avons écarté cinq pages candidates où nous ne pouvions pas distinguer le 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 a été bloqué sur les deux réseaux. Un vrai navigateur ou une API de scraping qui gère les vérifications de navigateur pourraient très bien réussir sur ces sites ; ce test ne l’a pas tenté.
Par catégorie, les résultats s’additionnent ainsi :
| Catégorie | Pages | Aucun proxy nécessaire | IP résidentielle nécessaire | Échec dans les deux cas |
|---|---|---|---|---|
| API publiques et données ouvertes | 5 | 5 | 0 | 0 |
| Référence et documentation | 6 | 5 | 0 | 1 |
| Actualités | 6 | 3 | 0 | 3 |
| Recherche e-commerce | 5 | 1 | 1 | 3 |
| Voyage | 5 | 1 | 2 | 2 |
| Social, emploi et recherche | 3 | 1 | 0 | 2 |
| Total | 30 | 16 | 3 | 11 |
Ce que montre le test sur 30 pages
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 essayé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é 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 du contenu réel à un serveur cloud trois fois sur trois. Pour une collecte à faible volume sur 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.
Amazon et Airbnb ont chacun fonctionné trois fois sur trois depuis l’IP de centre de données et deux fois sur trois via des sorties résidentielles. Avec trois tentatives par site, un échec reste dans la variation normale, et ne prouve pas que les IP résidentielles font moins bien à cet endroit. Chaque requête résidentielle part d’une connexion domestique différente, et une sortie individuelle peut être lente, ou avoir été récemment vue par le même site, d’une manière qu’un serveur cloud fixe ne l’est pas. La leçon est de tester plusieurs fois avant de décider, ce que la vérification ci-dessous facilite.
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 ont 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 proxys 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 depuis 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 comment fonctionnent ces vérifications.
Certaines pages ont besoin d’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 de ce type, 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 répartir 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 recherchez, 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. Ensuite, exécutez-la 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 tournera réellement (un serveur cloud, pas votre ordinateur portable, si c’est là que la production se déroule), plusieurs fois au cours d’une journée. Les résultats correspondent à une décision :
| Ce que vous observez 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 la mise à l’échelle |
| Blocages ou défis, et contenu réel depuis une connexion domestique | Le site bloque selon la réputation de l’IP | Proxys résidentiels |
| Blocages sur tous les réseaux | Le site vérifie le client | Un vrai 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 les pays. Si vous avez besoin de données telles que vues depuis l’Allemagne, testez depuis l’Allemagne.
Quand les données spécifiques à une localisation ont besoin d’un proxy résidentiel
Notre test posait une seule question : le site sert-il son contenu, tout simplement ? Une seconde question compte souvent davantage : sert-il le contenu qu’une personne réelle à un endroit donné verrait ?
Un serveur cloud se trouve dans une poignée d’emplacements de centres de données, et de nombreux sites reconnaissent les adresses de centres de données et leur montrent une version par défaut : la page d’accueil globale, des prix en dollars US, aucun stock local, ou aucune publicité du tout. Si votre tâche dépend de ce que les utilisateurs d’un pays ou d’une ville précise voient, vous avez besoin d’une sortie à cet endroit, sur un réseau que ces utilisateurs utilisent réellement. Cela couvre :
- Les résultats de recherche et classements locaux, qui changent selon la ville.
- Les prix, la disponibilité et les options de livraison, que les détaillants et les sites de voyage définissent par marché.
- Les publicités et pages d’atterrissage, que les annonceurs ciblent par localisation et qui souvent ne s’affichent pas pour le trafic de centre de données. Les vérifier est au cœur de la vérification publicitaire.
- Le contenu sous licence ou restreint par pays.
Dans ces cas, le site peut ne jamais bloquer une IP de centre de données, et vous collecteriez quand même les mauvaises données sans une sortie résidentielle au bon endroit.
Les options intermédiaires
Le choix ne se limite pas à « aucun proxy » ou « proxys résidentiels ».
- Les IP de centre de données sont bon marché et rapides, et conviennent pour les sites qui ne les bloquent pas. Notre comparaison des proxys ISP et de centre de données couvre les cas où elles suffisent.
- Les proxys ISP sont des adresses enregistrées auprès de fournisseurs d’accès internet grand public, conservées pour vous sur une période plus longue. Elles conviennent aux sessions longues et aux connexions à vos propres comptes. Les proxys ISP de Shifter restent dans la ville et sur le FAI (ASN) que vous choisissez pendant toute la période de facturation et sont fournis avec 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 à votre place, et facture par page réussie plutôt que par gigaoctet. C’est souvent l’option la moins coûteuse 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 proxys 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 scraping web ?
Pas toujours. Dans notre test, 16 des 30 pages publiques, y compris chaque API publique et la plupart des sites de documentation, ont servi du contenu réel à un serveur cloud sans aucun proxy. Testez d’abord vos cibles, depuis l’endroit où votre scraper tournera.
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 toujours 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 vrai navigateur ou une API de scraping est la solution, pas une IP différente.
Les proxys 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.
Quelle est la différence entre une IP de centre de données et une IP résidentielle ?
Une IP de centre de données appartient à un fournisseur d’hébergement ou de cloud. Une IP résidentielle appartient à un fournisseur d’accès internet grand public et est utilisée par une connexion domestique réelle. De nombreux sites font davantage confiance aux adresses résidentielles, car les visiteurs ordinaires les utilisent.
Comment tester si un site bloque les IP de centre de données ?
Requêtez quelques pages depuis un serveur cloud et vérifiez la réponse pour un marqueur qui n’apparaît que dans le contenu réel, pas seulement le code de statut. Puis répétez via une sortie résidentielle. Si le serveur cloud est refusé et la sortie résidentielle servie, le site bloque selon la réputation de l’IP.
Ai-je besoin d’un proxy résidentiel pour des données spécifiques à une localisation ?
Généralement, oui. Même les sites qui ne bloquent jamais les serveurs cloud leur montrent souvent une version par défaut de la page. Pour voir les résultats locaux, les prix ou les publicités que les utilisateurs d’un pays ou d’une ville voient, vous avez besoin d’une sortie à cet endroit.
Pourquoi Amazon et Airbnb ont-ils moins bien fonctionné via les proxys résidentiels dans votre test ?
Chacun a échoué une fois sur trois tentatives résidentielles, ce qui reste dans la variation normale pour trois essais. Chaque requête résidentielle part d’une connexion domestique différente, et une seule sortie peut être lente ou avoir été récemment vue par le site. Testez plusieurs fois avant de tirer une conclusion.
En résumé
Un proxy résidentiel résout un problème précis : 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 tournera, classez-la dans l’un de ces groupes, et ne payez du trafic résidentiel que là où cela change le résultat. Nos bonnes pratiques de scraping web couvrent le reste d’une collecte responsable.