Scraping

Web scraping à grande échelle : quand et pourquoi utiliser des proxys publics

5 min read Published Updated 993 words

La rotation de proxy est une béquille, pas une solution. La plupart des opérations de scraping échouent parce qu'elles traitent les adresses IP comme le seul signal mesuré par les systèmes anti-bot. En réalité, les gestionnaires anti-bot modernes — Akamai Bot Manager, Cloudflare Turnstile, Datadome — prennent en compte bien plus que votre IP source. Un pool rotatif de proxies publics gratuits ne vous apporte presque rien face à ces systèmes, et aggrave souvent la situation.

L'illusion de la rotation d'IP

Lorsque vous changez d'IP à chaque requête, vous vous annoncez comme un scraper. Les schémas de navigation humaine montrent des sessions persistantes (sticky sessions) — une seule IP pendant des minutes ou des heures, des empreintes de navigateur cohérentes et des intervalles de requêtes prévisibles. Des outils comme requests avec un objet Session et une liste de proxies rotative brisent tous ces signaux. L'en-tête X-Akamai-Device-Fingerprint d'Akamai et la corrélation cf-request-id de Cloudflare peuvent relier des requêtes provenant d'IP différentes lorsque les paramètres TLS, les réglages HTTP/2 et le timing restent identiques. Le défi JavaScript de Datadome recherche des artefacts de navigateur headless qui survivent aux changements de proxy. Changer d'IP sans changer l'empreinte complète du client, c'est comme changer de plaque d'immatriculation en conduisant la même voiture — les caméras de péage vous signalent toujours.

Pour du scraping à faible cadence et faible volume sur des sites qui utilisent uniquement une limitation de débit basée sur l'IP (par exemple, un throttle de 10 requêtes par minute sans défi JavaScript), une seule IP résidentielle suffit souvent. J'ai fait tourner des scrapers pendant des années sur des portails de données gouvernementaux et des API publiques avec une seule IP statique et un time.sleep(2) poli. Aucun proxy nécessaire. La règle est simple : si le site ne sert pas de page de défi ou de CAPTCHA après 50 requêtes, vous n'avez pas besoin de rotation.

Au-delà de l'adresse IP : l'empreinte numérique (fingerprinting)

Les systèmes anti-bot collectent désormais des dizaines de signaux par requête. La chaîne User-Agent est triviale à falsifier, mais l'ordre de Accept-Language, Sec-CH-UA, Connection et Accept-Encoding ne l'est pas. Plus critique encore, l'empreinte TLS — standardisée dans le hash JA3 (voir JA3) — identifie la bibliothèque cliente par l'ordre des suites de chiffrement et la liste des extensions TLS. La bibliothèque requests de Python (via urllib3) produit un hash JA3 distinct de celui de Chrome 124. Turnstile de Cloudflare et Datadome vérifient tous deux le JA3. Changer d'IP tout en conservant la même pile TLS donne l'impression que chaque requête provient du même client automatisé, sautant simplement entre des nœuds de sortie. Les proxies gratuits aggravent cela car ils utilisent souvent des versions obsolètes d'OpenSSL ou des configurations TLS de type bot déjà blacklistées.

L'empreinte HTTP/2 va plus loin. La trame SETTINGS, les valeurs de mise à jour de fenêtre et les paramètres de concurrence de flux forment une « empreinte HTTP/2 » unique que le Bot Manager d'Akamai suit à travers les sessions. Un pool de proxies rotatif qui ne change pas également l'implémentation HTTP/2 est trivial à regrouper. La seule façon d'éviter ces vérifications est d'utiliser un vrai moteur de navigateur (Puppeteer, Playwright) ou une pile TLS/HTTP soigneusement conçue qui imite une version spécifique de navigateur — et même dans ce cas, vous devez conserver la même empreinte sur toutes les requêtes d'une session donnée.

L'économie des pools de proxies publics gratuits

Les listes de proxies publics gratuits ont un taux d'échec de 60 à 80 % dans mes tests. La plupart des proxies sont soit morts à l'arrivée, soit limités par l'hôte, soit déjà signalés par les principaux gestionnaires anti-bot. La durée de vie moyenne d'un proxy SOCKS5 gratuit extrait d'un annuaire public est inférieure à 15 minutes. Maintenir un pool rotatif de 500 proxies signifie que vous brûlez des milliers d'IP par heure, et 80 % de vos requêtes expirent ou retournent une 403. La bande passante est peu fiable, les pics de latence sont fréquents, et de nombreux proxies gratuits injectent des publicités ou modifient les corps de réponse. Les réseaux de proxies résidentiels payants (par exemple Bright Data, Oxylabs) offrent des taux de succès de 95 %+ et des options de sessions persistantes, mais à un coût de 10 à 20 $ par Go. À grande échelle, le calcul favorise les proxies résidentiels uniquement lorsque vous devez contourner des blocages basés sur l'IP sur des cibles de grande valeur. Pour tout le reste, une seule IP propre avec un rythme de requêtes approprié surpasse un pool gratuit chaotique.

Quand la rotation fonctionne réellement

La rotation de proxy est efficace contre une menace spécifique : les limites de débit basées sur l'IP qui se réinitialisent par IP. Si un site utilise une simple vérification X-Forwarded-For ou un seau à jetons par IP, changer de proxy après chaque requête contourne la limite. C'est courant sur les petits sites e-commerce et les API héritées qui n'ont jamais mis à jour leur détection de bots. Dans ces cas, même un pool de proxies gratuits fonctionne — mais seulement si vous implémentez une logique de réessai qui écarte les proxies défaillants et en cycle rapidement de nouveaux.

Voici un exemple minimal en Python utilisant requests et une boucle de réessai avec rotation. Il suppose une liste d'URL de proxy dans proxy_list et une cible url :

import requests
from itertools import cycle

proxy_pool = cycle(proxy_list)
max_retries = 5

for attempt in range(max_retries):
    proxy = next(proxy_pool)
    try:
        resp = requests.get(
            url,
            proxies={"http": proxy, "https": proxy},
            timeout=10,
            headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."}
        )
        if resp.status_code == 200:
            break
    except (requests.ConnectionError, requests.Timeout):
        continue
else:
    raise RuntimeError("All proxies failed")

Ce modèle fonctionne uniquement lorsque la détection du site est purement basée sur l'IP. Ajoutez un time.sleep(random.uniform(1,3)) entre les requêtes pour imiter le timing humain. Pour les sites utilisant Turnstile ou Datadome, ce code échouera à chaque fois — la page de défi retournera une 403 ou un CAPTCHA quel que soit le proxy. Dans ces cas, vous avez besoin d'un navigateur headless avec une empreinte réelle, pas d'une liste d'IP rotative.

Les sessions persistantes (sticky sessions) — conserver la même IP pour un ensemble de requêtes liées — sont souvent plus efficaces qu'une rotation par requête. De nombreux sites e-commerce s'attendent à une seule IP pour une session de navigation (par exemple, ajouter des articles au panier, passer commande). Changer d'IP en cours de session déclenche des alertes de fraude. Utilisez un pool de proxies mais attribuez une IP par session, pas par requête. Les proxies gratuits supportent rarement les sessions persistantes car la même IP est réutilisée par plusieurs utilisateurs ; vous verrez une contamination croisée des données de session. Les proxies résidentiels payants offrent des durées de session persistante (5 à 30 minutes) qui correspondent au comportement de navigation naturel.

Choisissez la rotation uniquement lorsque vous comprenez la pile de détection de la cible. Testez d'abord avec une seule IP. Ajoutez la rotation uniquement si vous atteignez une limite de débit. Et ne comptez jamais sur des proxies gratuits en production — leur taux d'échec vous coûtera plus en temps d'ingénierie et en données perdues qu'un abonnement résidentiel bon marché.