Un scraper est bloqué lorsque son trafic ne correspond pas à ce que la cible attend d'un visiteur réel. La requête provient d'une adresse à mauvaise réputation, transporte un ensemble d'en-têtes trop maigre ou incohérent, s'exécute plus vite qu'un humain ne pourrait cliquer, ou demande une page que le site ne sert jamais aux robots. L'un de ces indices suffit à un système anti-bot moderne pour retourner un 403, un CAPTCHA, ou une page vide à la place des données souhaitées.
Ce guide couvre les tactiques pratiques qui permettent à un scraper de ressembler à un navigateur : rotation des IP résidentielles, envoi d'en-têtes et de user-agents réalistes, limitation et randomisation des intervalles, respect du robots.txt, rendu JavaScript lorsque la page le nécessite, gestion des CAPTCHAs, gestion des sessions et des cookies, et surveillance des codes de statut pour reculer avant qu'un ralentissement temporaire ne devienne un bannissement définitif. Aucune de ces techniques n'est une solution miracle, mais combinées dans le bon ordre, elles font passer la plupart des cibles d'un mur de blocages à un flux régulier de 200.
Pourquoi les scrapers sont bloqués
Avant les tactiques, il est utile de comprendre à quoi vous faites face. Les systèmes anti-bot signalent le trafic automatisé sur trois grands signaux, et presque chaque blocage se ramène à l'un d'eux.
- Empreinte. Un vrai navigateur transporte un ensemble cohérent de signaux : un jeu complet d'en-têtes, un handshake TLS correspondant au user-agent déclaré, un moteur JavaScript, des cookies persistants entre les requêtes. Un client HTTP par défaut n'en possède presque aucun, et un client à moitié falsifié porte des signaux qui se contredisent. Dans les deux cas, il se démarque.
- Cadence. Les sites comptent les requêtes par IP et par session dans le temps. Un trafic arrivant plus vite qu'un humain ne pourrait le générer, ou à intervalles parfaitement réguliers, est identifié comme un script quelle que soit la propreté de chaque requête individuelle.
- Réputation IP. Les adresses appartenant à des plages de datacenters connus, figurant sur des listes de blocage partagées, ou ayant un historique d'abus, sont traitées avec méfiance dès la première requête. L'IP d'où vous venez fixe votre crédibilité initiale avant même que vous n'envoyiez un seul en-tête.
Chaque tactique ci-dessous fonctionne en corrigeant l'un de ces signaux. Appliquez d'abord les moins coûteuses, mesurez votre taux de blocage, et ne recourez aux solutions lourdes que lorsqu'une cible vous y oblige réellement.
Faire tourner les IP résidentielles
Le blocage le plus courant est aussi le plus simple : trop de requêtes depuis une seule adresse. Un site compte les hits par IP et commence à retourner des 429 ou une page de blocage dès que vous dépassez son seuil. Répartir le même volume de requêtes sur de nombreuses IP empêche toute adresse individuelle d'atteindre la limite. C'est pourquoi l'infrastructure de scraping est essentiellement une infrastructure de proxy : le proxy effectue la requête à votre place, de sorte que la cible voit son adresse plutôt que la vôtre.
Le type d'IP est aussi important que la rotation. Les IP de datacenter sont rapides et bon marché, mais elles appartiennent à des plages d'hébergement que n'importe quelle cible peut identifier par une simple recherche, ce qui les fait paraître automatisées sur les sites renforcés. Les IP résidentielles passent par de vraies connexions grand public et ressemblent à des visiteurs ordinaires, à un coût plus élevé et une vitesse moindre. Le compromis complet est détaillé dans datacenter vs residential proxies. Achetez exactement le niveau de confiance que la cible exige, pas plus : résidentiel pour les sites stricts, datacenter pour les sites tolérants.
La rotation manuelle consiste à maintenir un pool d'adresses, à les faire tourner par requête, puis à supprimer celles qui sont grillées. Une passerelle rotative masque cela derrière un seul point de terminaison et change l'IP de sortie pour vous, soit nouvelle à chaque requête, soit fixe par session lorsque vous devez conserver une identité sur plusieurs pages.
Envoyer des en-têtes et des user-agents réalistes
Un client HTTP par défaut se trahit dès la première ligne qu'il envoie. La bibliothèque requests de Python annonce User-Agent: python-requests/2.x et n'envoie presque aucun autre en-tête, tandis qu'un vrai navigateur en envoie une douzaine dans un ordre précis. Les sites qui ne font rien d'autre que lire cet en-tête bloqueront la première requête et laisseront passer la seconde.
Définissez un user-agent de navigateur actuel et réel, et alternez entre un petit pool plutôt que de marteler indéfiniment la même chaîne. Envoyez ensuite les en-têtes qui l'accompagnent toujours : Accept, Accept-Language, Accept-Encoding, et un Referer plausible. L'objectif n'est pas un en-tête magique, c'est la cohérence interne. Un user-agent Chrome associé à des valeurs Accept de style Firefox est plus suspect qu'une absence totale de falsification.
import requests headers = { "User-Agent": ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "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)
Un niveau plus profond se trouve l'empreinte TLS. Avant qu'un seul octet HTTP ne soit envoyé, votre client ouvre un handshake TLS dont la forme exacte constitue une signature souvent résumée comme un hash JA3. Un vrai Chrome produit une signature bien connue ; un client Python en produit une entièrement différente. Lorsque vous envoyez un user-agent Chrome via une pile TLS Python, les deux ne concordent pas, et une vérification d'empreinte signale la discordance quelle que soit la perfection de vos en-têtes. Combler cet écart nécessite un client qui imite le handshake d'un navigateur, ou de piloter un vrai moteur de navigateur qui en produit un authentique nativement.
Limiter et randomiser le timing
Même réparti sur de nombreuses IP, un scraper qui envoie des requêtes à cadence fixe est identifié comme automatisé. Un intervalle parfaitement régulier de 500 ms entre les requêtes est lui-même une empreinte, car les humains ne cliquent pas comme un métronome. Ajoutez un délai aléatoire entre les requêtes plutôt qu'un délai constant, et maintenez une concurrence à un niveau que la cible peut absorber sans remarquer le pic.
Le conseil historique d'utiliser un schéma de scraping irrégulier et humain reste valable : variez vos intervalles, ne parcourez pas les pages dans un ordre rigide, et évitez d'envoyer simultanément de nombreuses requêtes vers le même hôte. L'autre aspect du timing est de réduire la charge que vous n'avez pas besoin de générer. Mettez en cache les pages déjà récupérées pour ne jamais les demander deux fois, et ne scrapez que le contenu dont vous avez réellement besoin plutôt que l'ensemble du site.
Respecter robots.txt et éviter les honeypots
Avant toute technique d'évasion, lisez le fichier robots.txt du site. Il déclare les chemins que l'opérateur accepte de voir crawlés et, souvent, un Crawl-delay indiquant l'intervalle minimum attendu entre les requêtes. Le respecter est à la fois une question de courtoisie et d'autoprotection : ignorer les règles déclarées est le moyen le plus rapide d'être signalé, et c'est la ligne où les questions de conditions d'utilisation commencent. Vérifiez également les conditions d'utilisation du site ; s'il interdit explicitement le scraping, c'est un signal pour reconsidérer la cible.
Un piège connexe est le honeypot, un lien caché aux yeux humains par du CSS (display:none, taille nulle, ou positionnement hors écran) mais toujours présent dans le HTML. Un crawler naïf qui suit chaque balise <a> y tombe directement et se révèle immédiatement être un robot, car aucun vrai utilisateur ne pourrait cliquer sur un lien qu'il ne voit pas. Ne suivez que les liens qu'un navigateur rendu afficherait réellement, et ignorez tout ce qui est visuellement caché.
Rendre JavaScript comme un navigateur
De nombreuses pages retournent un HTML presque vide et construisent leur vrai contenu avec JavaScript après le chargement. Récupérez l'une d'elles avec un simple client HTTP et vous obtenez une coquille sans données. Certains sites vont plus loin et servent un défi JavaScript : un petit script qui doit s'exécuter et réussir avant que la vraie page ne soit livrée, ce qu'un client non-navigateur ne peut jamais franchir.
Dans les deux cas, vous avez besoin d'un vrai moteur de navigateur. Un navigateur headless tel que Playwright, Puppeteer ou Selenium pilotant Chrome charge la page, exécute ses scripts, et vous remet le DOM qu'un utilisateur verrait. Il produit également une vraie empreinte TLS de navigateur et un vrai objet navigator, ce qui lui permet de passer une classe de vérifications qu'un client brut ne peut pas. Le coût est son poids : un navigateur headless utilise bien plus de CPU et de mémoire par page qu'une simple requête, donc réservez-le aux pages qui nécessitent vraiment un rendu. Pour une présentation plus complète, voir how to crawl JavaScript websites et le guide Python pour scraper des pages JavaScript.
Gérer les CAPTCHAs
Un CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) est un défi qu'un site affiche lorsqu'il soupçonne qu'une requête est automatisée. De nombreux sites intègrent des algorithmes qui évaluent chaque visiteur et déclenchent un CAPTCHA lorsque le score paraît robotique. Une fois que vous en déclenchez un, aucun ajustement d'en-tête ne vous permettra d'obtenir les données de cette requête.
La solution durable est d'éviter de les déclencher en premier lieu : une IP résidentielle propre, une empreinte cohérente et un rythme humain maintiennent votre score robot assez bas pour que le défi ne se déclenche jamais. Lorsqu'une cible en affiche quand même, un point de terminaison de scraping géré qui résout ou contourne les CAPTCHAs côté serveur est bien plus fiable que d'intégrer un solveur dans votre propre infrastructure. Pour les détails, how to bypass CAPTCHAs in web scraping couvre les options.
Lorsqu'une cible nécessite plus qu'une IP propre, la Crawling API gère l'ensemble de la pile pour vous : elle fait tourner un large pool de sorties datacenter, résidentielles et mobiles, envoie une empreinte crédible, rend JavaScript lorsque la page le requiert, et traite les CAPTCHAs et les blocages côté serveur. Si vous n'avez besoin que de la couche IP rotative, le Smart AI Proxy achemine les requêtes ordinaires à travers le même réseau depuis un seul point de terminaison. Vous envoyez une URL et obtenez le résultat final. Testez votre vraie cible avec le niveau gratuit en premier.
Gérer les sessions et les cookies
De nombreux sites définissent un cookie à la première visite et s'attendent à le voir dans chaque requête ultérieure. Supprimer les cookies entre les requêtes vous fait apparaître comme un visiteur nouveau et bizarrement sans état à chaque fois, ce qui déclenche des vérifications comportementales supposant qu'un vrai utilisateur accumule de l'état au fur et à mesure de sa navigation. Utilisez une session qui persiste les cookies entre les requêtes afin qu'un flux multi-étapes (recherche, pagination, ouverture d'une page de détail) porte la même identité tout au long.
Les sessions interagissent avec la rotation IP, coordonnez donc les deux. Si vous changez d'IP en milieu de session, le cookie émis pour votre ancienne adresse arrive désormais d'une autre, ce qui constitue en soi un signal d'alerte. Maintenez une IP fixe pendant la durée d'une session logique, puis faites tourner lorsque vous en commencez une nouvelle. L'exemple ci-dessous utilise un requests.Session pour maintenir cookies et en-têtes cohérents entre les appels.
import requests session = requests.Session() session.headers.update(headers) # Cookies set on the first call ride along on the rest. session.get("https://example.com/search?q=phones") session.get("https://example.com/search?q=phones&page=2")
Surveiller les codes de statut et reculer
Votre scraper doit traiter les codes de statut HTTP comme des retours en temps réel, pas seulement comme un succès ou un échec. Une série de réponses 429 (Too Many Requests) ou 503 est le serveur qui vous dit de ralentir. Respectez-le : reculez exponentiellement, respectez l'en-tête Retry-After lorsque le serveur en envoie un, et traitez une rafale de 429 comme un signal pour réduire votre taux global plutôt que pour réessayer plus fort. Marteler un point de terminaison limité en débit à pleine vitesse est exactement ce qui transforme un ralentissement temporaire en bannissement définitif.
D'autres codes ont leur propre signification. Un 403 signifie généralement un blocage d'empreinte ou de réputation IP, donc changer le taux de requête n'aidera pas ; vous avez besoin d'une meilleure IP ou d'une empreinte plus crédible. Un 200 soudain qui retourne une page CAPTCHA au lieu du contenu est un blocage déguisé, donc validez le corps, pas seulement le code.
import time, random def fetch(session, url, tries=4): for attempt in range(tries): resp = session.get(url) 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")
Scraper de manière responsable
Rester non bloqué et scraper de manière responsable sont la même discipline vue sous deux angles. Lisez les conditions d'utilisation de chaque site et son robots.txt et respectez ce qu'ils déclarent, restez sur les pages publiques plutôt que sur tout ce qui se trouve derrière une connexion, et maintenez votre taux de requête à un niveau que la cible peut servir sans contrainte. Mettez en cache ce que vous avez déjà récupéré pour ne pas le re-demander, et ne récupérez que les données dont vous avez réellement besoin. Un scraper qui se comporte comme un visiteur attentionné a bien moins de chances d'être bloqué et bien moins de chances de causer un problème valant la peine d'être bloqué.
Points clés
- Les blocages proviennent de trois signaux. L'empreinte, la cadence et la réputation IP couvrent presque chaque blocage, et chaque tactique fonctionne en corrigeant l'un d'eux.
- Faites d'abord tourner les IP résidentielles. La plupart des blocages sont des limites de taux par IP, donc répartir les requêtes sur un pool d'adresses crédibles est la correction la moins chère et à plus fort impact.
- Gardez vos signaux cohérents. Des en-têtes réalistes, une empreinte TLS correspondante, des cookies persistants et un taux aléatoire sont plus convaincants ensemble que l'un d'eux seul.
- Respectez le site. Honorez robots.txt et les conditions d'utilisation, évitez les honeypots, restez sur les données publiques, et reculez dès qu'un 429 ou 503 vous le demande.
- Déléguez quand c'est difficile. Lorsqu'une cible résiste sur le rendu, les CAPTCHAs et la réputation à la fois, une crawling API gérée ou un smart proxy absorbe l'ensemble de la pile pour que vous n'ayez pas à la maintenir vous-même.
Foire aux questions
Pourquoi mon scraper web continue-t-il à être bloqué ?
Parce que son trafic ne ressemble pas à un vrai navigateur sur au moins l'un des trois axes : empreinte, cadence ou réputation IP. La requête peut provenir d'une IP de datacenter signalée, transporter un ensemble d'en-têtes maigre ou incohérent, ou arriver plus vite et plus régulièrement qu'un humain ne pourrait cliquer. Les systèmes anti-bot n'ont besoin que d'un seul de ces indices pour retourner un 403, un CAPTCHA ou une page vide.
Quelle est la méthode la plus efficace pour éviter les requêtes de scraping bloquées ?
Faire tourner un pool de bonnes IP, idéalement résidentielles pour les cibles strictes. Le blocage le plus courant est une limite de taux par IP, et répartir le même volume de requêtes sur de nombreuses adresses signifie qu'aucune ne dépasse jamais le seuil. C'est la correction la moins chère avec le plus grand impact, ce qui explique pourquoi c'est généralement la première technique à appliquer avant d'ajuster les en-têtes ou le timing.
Changer le user-agent suffit-il à stopper les blocages ?
Sur les sites les moins protégés, 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, à des cookies persistants et à un taux de requête crédible. Un user-agent falsifié sur une pile TLS de client HTTP par défaut est une contradiction que les vérifications d'empreinte détectent facilement.
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 lorsque le serveur en envoie un, et traitez une série de 429 comme un signal pour réduire votre taux de requête global. Marteler un point de terminaison limité en débit à pleine vitesse est ce qui transforme un ralentissement temporaire en bannissement permanent.
Ai-je besoin d'un navigateur headless pour éviter d'être bloqué ?
Seulement lorsque la page construit son contenu avec JavaScript après le chargement ou sert un défi JavaScript qu'un client simple ne peut pas passer. Un navigateur headless rend la page et produit une vraie empreinte de navigateur, ce qui passe des vérifications qu'une requête brute ne peut pas, mais cela coûte bien plus de CPU et de mémoire par page. Pour le HTML statique, une requête HTTP bien configurée est plus rapide, moins chère et tout aussi non bloquée.
Quand une crawling API gérée est-elle plus judicieuse que de construire la sienne ?
Lorsqu'une cible résiste sur plusieurs couches à la fois. Maintenir un pool de proxies résidentiels, la rotation des en-têtes et TLS, les sessions de cookies, la logique de recul, une flotte headless et un chemin CAPTCHA est une vraie charge d'ingénierie, et un nouveau défi peut tout casser du jour au lendemain. Une crawling API ou un smart proxy absorbe tout cela derrière une seule requête, vous échangez donc un coût par requête et un peu de contrôle contre le fait de ne pas gérer vous-même l'infrastructure anti-bot.
Crawlez n'importe quel site à grande échelle, sans combattre l'infrastructure.
Crawlbase gère les proxies, les empreintes et les CAPTCHA afin que votre équipe livre des pipelines de données au lieu de maintenir la plomberie de crawl. 1 000 requêtes gratuites, sans carte requise.