Comment scraper des sites web sans être bloquéLes solutions qui fonctionnent, dans l''ordre

Un scraper se fait bloquer parce qu'il ne ressemble pas au trafic que la cible attend. Les vrais navigateurs portent un ensemble cohérent de signaux : une IP plausible, un jeu d'en-têtes complet, une empreinte TLS correspondant au User-Agent qu'ils revendiquent et un rythme de requêtes qui ne ressemble pas à un métronome. Supprimez l'un de ces éléments et un système anti-bot moderne le remarque. La majeure partie du travail pour scraper sans se faire bloquer consiste à remettre ces signaux en place, dans le bon ordre, en ne payant pour les plus lourds que quand la cible le requiert réellement.

Cet article parcourt les techniques dans l'ordre approximatif où elles portent leurs fruits : faites pivoter votre IP, envoyez une requête crédible, lissez votre débit, respectez ce que le site déclare, rendez JavaScript quand la page en a besoin, et confiez le tout à un endpoint géré quand quelques en-têtes ne suffisent plus. Aucune n'est une solution miracle. Empilées dans le bon ordre, elles vous font passer d'un mur 403 à un 200 stable, sur la plupart des cibles, la plupart du temps.

Les gains les plus rapides, dans l'ordre

Commencez par le haut, mesurez votre taux de blocage et ne montez que quand la cible vous y oblige. Recourir à une flotte de navigateurs headless pour scraper une page de prix statique est un effort gaspillé ; recourir à plain requests contre un mur de connexion fortifié est des requêtes gaspillées.

Faire pivoter votre IP

Le blocage le plus courant est le plus simple : trop de requêtes depuis une seule adresse. Un site compte les requêtes par IP et commence à retourner des 429 ou une page de blocage une fois que vous dépassez son seuil. Répartissez ces requêtes sur de nombreuses IP et aucune adresse ne déclenche jamais la limite. C'est toute la raison pour laquelle l'infrastructure de scraping est essentiellement de l'infrastructure de proxy : le proxy fait la requête pour vous de sorte que la cible voit son IP, pas la vôtre.

L'IP par laquelle vous effectuez la rotation importe autant que la rotation elle-même. Les IP de datacenter sont rapides et bon marché mais se trouvent dans des plages d'hébergement connues, de sorte qu'une cible qui effectue une recherche ASN les signale immédiatement. Les IP résidentielles sortent de vraies connexions grand public et se lisent comme des visiteurs ordinaires, à un coût plus élevé et une vitesse inférieure. Le compromis complet se trouve dans datacenter vs proxies résidentiels, et le juste milieu des proxies résidentiels statiques dans proxies ISP vs résidentiels. Achetez exactement autant de confiance que la cible exige, pas un niveau de plus.

Faire pivoter les IP à la main signifie maintenir une liste et la parcourir par requête. Une passerelle proxy rotative masque cela derrière un seul endpoint et échange l'IP de sortie pour vous, soit par requête soit en session sticky quand vous devez maintenir une identité.

# Rotate exits through a single gateway endpoint.
# The gateway picks a fresh IP; your logic stays here.
import requests

proxies = {
    "http": "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012",
    "https": "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012",
}
resp = requests.get("https://example.com/product/123", proxies=proxies, verify=False)
print(resp.status_code)

Envoyer une requête comme un vrai navigateur

Un client HTTP par défaut se trahit dès la première ligne. La bibliothèque Python requests envoie User-Agent: python-requests/2.x et presque aucun autre en-tête ; un vrai navigateur en envoie une douzaine, dans un ordre spécifique. Les sites qui ne font rien de plus que lire ces en-têtes bloqueront le premier et laisseront passer le second.

Définissez un User-Agent de navigateur actuel et réel et faites pivoter sur un petit pool plutôt que de marteler une seule chaîne. Envoyez ensuite les en-têtes qui voyagent toujours avec lui : Accept, Accept-Language, Accept-Encoding et un Referer plausible. L'objectif n'est pas un seul en-tête magique, c'est la cohérence interne : un User-Agent Chrome associé à des en-têtes Accept de style Firefox est plus suspect qu'aucune usurpation du tout.

import requests

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    ),
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Referer": "https://www.google.com/",
}
resp = requests.get("https://example.com", headers=headers)

Faire correspondre votre empreinte TLS à votre User-Agent

Les en-têtes sont la couche évidente ; TLS est celle qui attrape les scrapers qui ont corrigé les en-têtes et se sont arrêtés là. Avant qu'un seul octet HTTP ne soit envoyé, votre client ouvre un handshake TLS, et la forme exacte de ce handshake (ordre des chiffrements, extensions, groupes supportés) forme une empreinte généralement résumée comme un hash JA3. Un vrai Chrome produit une empreinte bien connue. Python requests en produit une complètement différente. Quand vous envoyez un User-Agent Chrome sur une pile TLS Python, les deux sont en désaccord, et une vérification d'empreinte signale la discordance quelle que soit la perfection de vos en-têtes.

La solution est de faire ressembler le handshake lui-même à un navigateur. Utilisez un client qui imite le profil TLS d'un vrai navigateur (en Python, curl_cffi avec son option impersonate est le choix courant), ou pilotez un vrai moteur de navigateur, qui produit un handshake authentique gratuitement. C'est là que le scraping fait maison commence à devenir coûteux, et où un endpoint géré qui gère déjà les empreintes commence à sembler attrayant.

Limiter et reculer

Même sur de nombreuses IP, un scraper qui envoie des requêtes plus vite qu'aucun humain ne pourrait cliquer se lit comme automatisé. Ajoutez un délai aléatoire entre les requêtes plutôt qu'un délai fixe (un écart fixe de 500ms est lui-même une empreinte), et maintenez la concurrence à un niveau que la cible peut absorber sans le remarquer.

Plus important que le délai en régime stable est la façon dont vous réagissez à la résistance. Quand un serveur retourne 429 ou 503, il vous dit de ralentir. Respectez-le : reculez exponentiellement, respectez l'en-tête Retry-After quand il est présent, et traitez une série de 429 comme un signal pour baisser votre débit global, pas pour réessayer plus fort. Réessayer un endpoint limité en débit à pleine vitesse est la façon dont un throttle doux devient un bannissement ferme.

import time, random, requests

def fetch(url, headers, tries=4):
    for attempt in range(tries):
        resp = requests.get(url, headers=headers)
        if resp.status_code == 200:
            return resp
        if resp.status_code in (429, 503):
            wait = int(resp.headers.get("Retry-After", 2 ** attempt))
            time.sleep(wait + random.uniform(0, 1))
            continue
        resp.raise_for_status()
    raise RuntimeError("exhausted retries")

Si vous peinez à déchiffrer ce que signifie chaque code de statut, les codes d'erreur de statut proxy détaille les plus courants et ce que chacun vous dit réellement.

Respecter robots.txt et rester sur les données publiques

Avant les techniques d'évasion, une discipline qui vous évite des ennuis : lisez le robots.txt du site, respectez son délai de crawl et ses chemins interdits, et scrapez les pages publiques plutôt que tout ce qui se trouve derrière un accès connecté. C'est en partie de la courtoisie et en partie de la préservation de soi. Le scraping authentifié lie chaque requête à un compte que le site peut bannir en un clic, et ignorer les règles déclarées est à la fois la façon la plus rapide d'être signalé et la ligne où les questions juridiques commencent.

Un piège connexe est le honeypot : un lien caché aux yeux humains par CSS (display:none, taille zéro, positionnement hors écran) mais présent dans le HTML. Un crawler naïf qui suit chaque <a> y marche directement et se dénonce comme un bot. Ne suivez que les liens qu'un navigateur rendu afficherait réellement, et ignorez tout ce qui est visuellement caché.

Rendre JavaScript quand la page en a besoin

De nombreuses pages renvoient un HTML presque vide et construisent leur vrai contenu avec JavaScript après le chargement. Récupérez l'une d'elles avec un client HTTP ordinaire et vous obtenez une coquille sans données. Pire, certains sites servent un challenge JavaScript : un petit script qui doit s'exécuter et réussir avant que la vraie page soit délivrée, qu'un client non-navigateur ne peut jamais passer.

Pour les deux cas, vous avez besoin d'un vrai moteur de navigateur. Un navigateur headless (Playwright, Puppeteer ou Selenium pilotant Chrome) charge la page, exécute ses scripts et vous remet le DOM que l'utilisateur verrait. Il produit également une véritable empreinte TLS de navigateur et un vrai objet navigator, il passe donc une classe de vérifications qu'un client brut ne peut pas. Le coût est le poids : un navigateur headless utilise beaucoup plus de CPU et de mémoire par page qu'une requête HTTP, réservez-le donc aux pages qui ont vraiment besoin d'être rendues. Pour un tutoriel plus approfondi, consultez le scraping web avec Python et Selenium.

Une mise en garde : un navigateur headless par défaut est détectable. Le flag navigator.webdriver, des listes de plugins manquants ou inhabituels et des particularités spécifiques au mode headless fuient tous. Les plugins stealth dissimulent les signes révélateurs courants, mais c'est une course aux armements, et sur une cible fortifiée c'est souvent le moment d'arrêter de maintenir votre propre flotte.

Quand confier à une API gérée

Chaque technique ci-dessus est une couche que vous construisez et maintenez : un pool de proxies, un rotateur d'en-têtes, un client imitant TLS, une politique de recul, une flotte headless avec des patches stealth. Sur des cibles tolérantes, vous n'aurez peut-être besoin que des deux premières. Sur une cible fortifiée, vous finissez par assembler et surveiller toutes ces couches, et un CAPTCHA ou un nouveau challenge JS peut casser toute la pipeline du jour au lendemain.

Une API de crawling réduit cette pile à une seule requête. Vous envoyez une URL ; le fournisseur choisit l'origine IP, envoie une empreinte cohérente, rend la page quand un navigateur est requis, réessaie sur les blocages côté serveur et renvoie le HTML complet. Le compromis est honnête : vous payez par requête et cédez un certain contrôle de bas niveau, en échange de ne pas gérer une infrastructure anti-bot comme second emploi.

# Send the URL; rotation, fingerprint, rendering,
# and retries are handled server-side.
import requests

resp = requests.get(
    "https://api.crawlbase.com/",
    params={
        "token": "_YOUR_TOKEN_",
        "url": "https://example.com/product/123",
        "javascript": "true",  # render the page in a browser
    },
)
print(resp.text)

Que vous construisiez ou achetiez, la question du proxy en dessous ne disparaît pas. Si vous êtes encore en train de choisir la couche IP, les meilleurs proxies pour les scrapers web associe les types de cibles au type de proxy adapté, et comment utiliser des proxies rotatifs couvre le câblage de la rotation dans votre code.

Foire aux questions

Quelle est la raison la plus courante pour laquelle un scraper se fait bloquer ?

Trop de requêtes depuis une seule adresse IP. Les sites comptent les requêtes par IP et commencent à retourner des 429 ou des pages de blocage une fois que vous dépassez un seuil. Faire pivoter les requêtes sur un pool d'IP pour qu'aucune adresse ne déclenche la limite est la correction à l'impact le plus élevé, c'est pourquoi la rotation IP est généralement la première technique à appliquer.

Changer le User-Agent suffit-il pour éviter les blocages ?

Sur les sites les moins défendus, parfois. Sur tout ce qui est sérieux, non. Un User-Agent réaliste doit être associé au jeu complet d'en-têtes qu'un navigateur envoie, une empreinte TLS correspondant à ce navigateur et un débit de requêtes crédible. Un User-Agent usurpé sur une pile TLS de client HTTP par défaut est une contradiction que les vérifications d'empreinte repèrent facilement.

Ai-je toujours besoin d'un navigateur headless pour scraper ?

Non. Un navigateur headless n'est nécessaire que quand la page construit son contenu avec JavaScript après le chargement, ou sert un challenge JavaScript qu'un client non-navigateur ne peut pas passer. Pour du HTML statique, une requête HTTP ordinaire est beaucoup plus rapide et moins coûteuse. Réservez le navigateur headless aux pages qui nécessitent vraiment un rendu, car il coûte beaucoup plus de CPU et de mémoire par page.

Comment gérer une réponse 429 Too Many Requests ?

Ralentissez plutôt que de réessayer plus fort. Reculez exponentiellement, respectez l'en-tête Retry-After quand le serveur en envoie un, et traitez une série de 429 comme un signal pour baisser votre débit global de requêtes. Marteler un endpoint limité en débit à pleine vitesse est la façon dont un throttle temporaire se transforme en bannissement ferme.

Dois-je scraper des données derrière un accès connecté ?

Évitez-le autant que possible. Les requêtes authentifiées lient chaque appel à un compte que le site peut bannir instantanément, et elles soulèvent des questions juridiques et de conditions d'utilisation que le scraping de pages publiques ne pose pas. Lisez le robots.txt du site, restez sur les données publiques et ignorez les liens honeypot cachés aux vrais utilisateurs.

Quand une API de scraping gérée a-t-elle plus de sens que de construire la sienne ?

Quand la cible résiste sur plusieurs couches à la fois. Maintenir un pool de proxies, la rotation des en-têtes, un client imitant TLS, une logique de recul et une flotte headless avec des patches stealth est une véritable charge d'ingénierie, et un nouveau CAPTCHA ou challenge peut tout casser du jour au lendemain. Une API de crawling absorbe tout cela derrière une seule requête, vous échangez donc un coût par requête et un certain contrôle contre le fait de ne pas gérer vous-même une infrastructure anti-bot.

FQ

Farah Qadeer

Visualisation de contenu · Crawlbase

Spécialiste de la visualisation de contenu chez Crawlbase, elle transforme des sujets denses de proxys et de web scraping en visuels clairs et en guides pas à pas.