Comment scraper un site web sans se faire bloquer (guide 2026)

Pour scraper un site sans se faire bloquer, voici l'ordre que je conseille : respecter le robots.txt et les conditions d'utilisation, limiter la cadence à un rythme humainement plausible avec backoff exponentiel, envoyer des headers de navigateur réalistes, garder les cookies cohérents par session, puis répartir le volume légitime sur des IP résidentielles rotatives en surveillant les codes de statut.

Se faire bloquer n'est pas une question de malchance. C'est la pile anti-bot d'un site qui identifie correctement un trafic qui ne ressemble pas à une personne en train de naviguer — ou un trafic auquel il a explicitement demandé de partir. Concevant et exploitant moi-même des systèmes web en production, je connais aussi le point de vue du site qui subit ce trafic, et il éclaire chaque conseil qui suit. Ce guide couvre les pratiques d'ingénierie qui permettent aux projets de scraping légitimes (veille tarifaire, suivi SEO, vérification publicitaire, données d'entraînement IA, études de marché) de fonctionner de manière fiable, et il est explicite sur les lignes que nous n'aidons personne à franchir. Pour une vue d'ensemble du fonctionnement du scraping de bout en bout, commencez par notre guide du web scraping.

Commencer par les règles : robots.txt et conditions d'utilisation

Avant d'optimiser quoi que ce soit de technique, demandez-vous d'abord si vous devriez scraper cette cible.

1. Récupérez et analysez le robots.txt. Ce fichier à la racine du site déclare quels chemins sont interdits aux crawlers et inclut souvent une directive Crawl-delay. Le respecter est le signal le plus clair que votre projet agit de bonne foi, et la plupart des frameworks de scraping matures peuvent l'appliquer automatiquement.
2. Lisez les conditions d'utilisation. Certains sites interdisent purement et simplement l'accès automatisé ; d'autres restreignent des usages spécifiques. L'opposabilité des clauses de CGU varie selon la juridiction et l'affaire — notre synthèse sur la légalité du web scraping couvre les décisions majeures — mais connaître ce que dit le site est une obligation de base, pas une option.
3. Privilégiez les canaux officiels. Si le site propose une API, un flux de données ou un programme de licence couvrant votre cas d'usage, utilisez-le. C'est plus stable que le scraping et cela supprime entièrement le problème du blocage.
4. Délimitez votre collecte. Ne prenez que les champs nécessaires, uniquement sur des pages publiques, et excluez tout ce qui identifie des individus. Sous le RGPD et les régimes équivalents, les données personnelles emportent des obligations que la plupart des projets de scraping ne sont pas en mesure de respecter.

Notre position de conformité, énoncée clairement : ProxyFacts ne fournit aucune aide pour contourner des paywalls ou des murs de connexion, déjouer des CAPTCHA à grande échelle via des fermes de résolution, scraper des données personnelles ou automatiser des achats (sneaker bots, revente de billets, création de comptes). L'ingénierie anti-blocage, telle que traitée ici, vise à rendre fiable un accès légitime — pas à obtenir un accès qui ne vous a jamais été autorisé.

Comprendre pourquoi les sites bloquent les scrapers

Les systèmes anti-bot recherchent des schémas qu'aucun humain ne produit. Connaître les couches de détection vous indique quoi corriger :

Deux conséquences en découlent. Premièrement, la rotation d'IP seule ne corrige qu'une seule couche — un scraper avec une IP rotative mais un User-Agent Python par défaut se fait toujours attraper à la couche deux. Deuxièmement, les couches se cumulent : des headers cohérents avec des sessions incohérentes paraissent plus suspects que chaque défaut pris isolément. Un travail anti-blocage efficace consiste à faire raconter à chaque couche la même histoire, véridique : un client raisonnable effectuant un nombre raisonnable de requêtes.

Rate limiting et backoff : le correctif au meilleur rendement

Le moyen le plus rapide de se faire bloquer est d'envoyer des requêtes aussi vite que votre connexion le permet. Le correctif ne coûte presque rien :

• Fixez une cadence de base prudente. Une requête toutes les quelques secondes par domaine est un point de départ raisonnable pour la plupart des sites. Si le robots.txt déclare un Crawl-delay, traitez-le comme un plancher, pas comme une suggestion.
• Ajoutez du jitter. Rendez aléatoire le délai entre les requêtes (par exemple, un délai de base multiplié par un facteur aléatoire entre 0,5 et 1,5). Des intervalles parfaitement réguliers sont une signature de machine.
• Implémentez un backoff exponentiel. Sur un HTTP 429 ou 503, attendez, puis réessayez avec un délai doublé : 1 seconde, 2, 4, 8, et ainsi de suite, plafonné à un maximum raisonnable. Si la réponse inclut un header Retry-After, respectez-le à la lettre.
• Budgétez la concurrence par domaine, pas globalement. Vingt workers simultanés répartis sur vingt sites, c'est acceptable ; vingt workers sur un seul site, c'est une rafale qui ressemble à une attaque.
• Planifiez en dehors des heures de pointe. Crawler un e-commerçant pendant son pic de trafic revient à concurrencer de vrais clients pour les ressources du serveur. Le crawl en heures creuses est à la fois plus poli et moins susceptible de déclencher les défenses basées sur la charge.

Devant un scraper qui se fait bloquer, la cadence est d'ailleurs ce que je vérifierais en premier — avant les headers, avant les proxies. Un scraper qui respecte ces règles n'a souvent besoin d'aucun autre travail anti-blocage pour les projets de petite et moyenne envergure. Tout ce qui suit compte surtout à mesure que le volume augmente.

Envoyer des headers réalistes et cohérents

Les headers par défaut d'un client HTTP annoncent exactement ce que vous êtes. Corrigez les signes les plus évidents :

1. Définissez un User-Agent de vrai navigateur — une chaîne Chrome ou Firefox récente, pas la valeur par défaut d'une bibliothèque ni une version de navigateur datant de plusieurs années.
2. Envoyez le jeu complet de headers que ce navigateur enverrait : Accept, Accept-Language, Accept-Encoding, et les headers de client hints Sec-CH-UA qu'inclut un Chrome moderne. Un User-Agent Chrome sans client hints est une contradiction que les systèmes de fingerprinting repèrent.
3. Gardez les headers cohérents entre eux. Accept-Language doit correspondre à la géographie que votre IP revendique. Une IP résidentielle allemande associée à un unique header de langue en-US est une incohérence.
4. Définissez un Referer plausible. Les pages profondes d'un site sont normalement atteintes depuis quelque part, pas invoquées à partir de rien.
5. Faites tourner les User-Agents avec parcimonie et correctement. Si vous faites de la rotation, faites tourner l'ensemble cohérent de headers d'un bloc — ne mélangez jamais le User-Agent d'un navigateur avec les client hints d'un autre.

Si la cible génère son contenu en JavaScript et défie les clients non navigateurs, le travail sur les headers ne suffira pas ; il vous faudra un vrai navigateur headless, et à ce stade une API de scraping managée est souvent plus judicieuse que de construire la pile vous-même — voyez notre comparatif API de scraping ou proxies bruts pour savoir où bascule l'arbitrage.

Gérer les sessions et les cookies délibérément

Les sites utilisent les cookies pour suivre la continuité d'un visiteur. Les scrapers se font repérer quand cette continuité se rompt :

• Acceptez et persistez les cookies au sein d'une session logique. Un client qui reçoit un cookie de session et ne le renvoie jamais paraît défectueux ou hostile.
• Gardez l'IP et le jar de cookies appariés. Un cookie de session qui arrive de trois pays en dix minutes est un voyageur impossible. Si vous faites tourner les IP, faites tourner les jars de cookies avec elles.
• Adaptez le type de session à la tâche. Les tâches sans état — récupérer des milliers de pages produit indépendantes — conviennent à une rotation d'IP par requête sans cookies persistants. Les parcours avec état — paginer une liste de résultats de recherche, avancer dans une annonce multipage — exigent une session sticky où IP et cookies restent fixes pendant toute la durée.
• Faites expirer les sessions comme le ferait un humain. Personne ne navigue en continu sur un même site pendant 72 heures. Retirez les identités de session après une durée de vie plausible et repartez de zéro.

Les grands fournisseurs de proxies résidentiels exposent un contrôle de session précisément pour cette raison. Selon leurs pages produit (consultées en juillet 2026) : Oxylabs propose la rotation plus des sessions sticky jusqu'à 24 heures ; Decodo (anciennement Smartproxy) propose la rotation par requête et des sessions sticky de quelques minutes à plusieurs jours ; IPRoyal prend en charge des intervalles sticky jusqu'à 7 jours ; et Bright Data offre à la fois les modes sticky et rotatif. La fenêtre dont vous avez besoin dépend entièrement de la durée de votre parcours avec état le plus long.

Des IP résidentielles rotatives pour un volume légitime

Quand un projet a légitimement besoin d'échelle — par exemple surveiller 100 000 pages produit par jour ou vérifier des positions de recherche depuis 20 pays — une seule IP ne peut pas porter la charge sans dépasser toute cadence par IP raisonnable. Répartir les requêtes sur un pool d'IP résidentielles maintient la cadence par IP humainement plausible pendant que le travail global se termine dans les temps. Les IP résidentielles bénéficient en outre d'une réputation grand public normale, contrairement aux plages datacenter que beaucoup de sites bloquent en bloc — les fondamentaux sont couverts dans notre explication sur ce qu'est un proxy résidentiel.

Les quatre fournisseurs que nous suivons publient les capacités pertinentes suivantes (tous les chiffres proviennent de leurs pages produit et de politique, consultées en juillet 2026 ; les tailles de pool sont des déclarations des fournisseurs, non vérifiées de manière indépendante) :

Notez la dernière ligne. Chaque fournisseur sérieux vérifie ses clients parce que son activité dépend de sa capacité à tenir les abus à l'écart de son réseau. Bright Data restreint l'accès à son réseau résidentiel aux entreprises vérifiées ayant passé un processus KYC à examen humain, selon sa FAQ KYC. Oxylabs exige un formulaire KYC de chaque client à l'inscription avec escalade selon le risque, selon sa politique KYC et sécurité. Decodo effectue des contrôles antifraude automatisés et un KYC à chaque inscription et bloque activement les cibles à haut risque comme la banque et la billetterie, selon sa page sécurité et conformité. IPRoyal réalise son KYC via le prestataire tiers iDenfy, selon sa politique KYC. Si votre cas d'usage ne survit pas à l'examen de conformité d'un fournisseur, le problème vient du cas d'usage, pas du fournisseur.

Le point de vue de l’ingénieur (Hinata) : Si je montais un pipeline de veille tarifaire, je ne choisirais pas mon fournisseur sur la taille du pool : je commencerais par le calcul de bande passante. Entre 4 et 7 dollars le Go, une page HTML de 80 Ko coûte une fraction de centime — mais un navigateur headless qui charge images et scripts multiplie vite cette facture par dix, et c'est ce ratio, pas le tarif affiché, qui décide entre proxies bruts et API managée. Enfin, un KYC strict est à mes yeux un signal d'achat, pas une friction : un réseau qui filtre ses clients vieillit mieux en réputation d'IP, et cette réputation est précisément ce que vous payez.

Conseils pratiques de rotation pour un volume légitime :

• Dimensionnez le pool selon la cadence, pas selon l'ego. Ce qui compte, c'est que le nombre de requêtes par IP et par heure reste humainement plausible sur votre cible spécifique, pas le chiffre affiché du pool. Le Proxy Market Research 2026 de Proxyway (données collectées en mars–avril 2026) situe la médiane des pools résidentiels annoncés à 54M d'IP — chaque grand fournisseur dispose de plus d'adresses que n'en exige n'importe quel projet légitime.
• Utilisez le ciblage géographique à bon escient. Si vous surveillez des prix français, demandez des IP françaises et envoyez des headers cohérents avec la France. Le ciblage géographique sert à voir ce que voient les vrais utilisateurs locaux, pas à contourner des bannissements régionaux.
• Gardez la rotation et la stratégie de session alignées, comme décrit dans la section sur les sessions ci-dessus.

Pour des critères de choix de fournisseur au-delà du blocage — structures tarifaires, essais, support — consultez notre comparatif des meilleurs proxies résidentiels.

Pourquoi les proxies gratuits aggravent le blocage au lieu de l'éviter

Le raccourci tentant échoue face aux faits. Une étude académique longitudinale de 30 mois portant sur plus de 640 600 proxies gratuits issus de 11 fournisseurs, présentée à NDSS MADWeb 2024, a montré que seuls 34,5 % ont été actifs à un moment donné, a identifié 4 452 vulnérabilités distinctes sur les IP des proxies — dont 1 755 permettant l'exécution de code à distance — et a surpris 16 923 proxies en train de manipuler le contenu en transit.

Pour l'anti-blocage en particulier, les proxies gratuits sont contre-productifs : les IP sont partagées par tous les autres scrapers gratuits visant les mêmes cibles, si bien qu'elles arrivent déjà grillées sur les listes noires des grands sites. Vous héritez de la mauvaise réputation des autres en plus de votre propre risque. Personnellement, je ne ferais jamais transiter du trafic de production par une machine dont j'ignore l'opérateur — quelques dollars par gigaoctet chez un fournisseur vérifié sont une assurance bon marché. L'argumentaire complet se trouve dans notre analyse proxies gratuits ou payants.

Surveiller les signaux de blocage en continu

Les blocages arrivent rarement d'un coup ; ils montent en puissance. Instrumentez votre scraper pour voir cette escalade tôt :

1. Répartition des codes de statut par domaine. Une part croissante de réponses 403, 429 ou 503 est la première alarme. Alertez sur les tendances, pas sur les échecs isolés.
2. Détection des CAPTCHA et pages de défi. Beaucoup de sites renvoient un HTTP 200 avec une page de défi à la place du contenu. Identifiez l'empreinte des pages de défi (motifs de titre, balisage connu) et comptez-les comme des échecs, sinon vos métriques de réussite vous mentent.
3. Anomalies de taille et de contenu des réponses. Une page produit qui renvoie soudain 5 Ko au lieu de 80 Ko, ou dont l'analyse ne produit aucun champ extrait, est probablement une page de blocage ou des données leurres.
4. Variations de latence. Un ralentissement progressif — des réponses passant de 300 ms à 5 secondes — est un signal de blocage doux qui précède les bannissements durs.
5. Taux de réussite par sous-réseau de proxy et par session. Si les échecs se concentrent sur certaines plages d'IP, retirez ces plages ; s'ils se concentrent sur les sessions longues, raccourcissez la durée de vie de vos sessions.

Quand les signaux se déclenchent, la bonne réponse est de ralentir et de diagnostiquer — pas d'augmenter l'agressivité. Divisez votre cadence par deux, vérifiez que vos headers correspondent toujours à un navigateur récent, regardez si le site a changé sa structure ou ses conditions, et seulement ensuite reprenez. Les scrapers qui répondent aux blocages en forçant davantage transforment un ralentissement temporaire en bannissement permanent.

Ce que nous refusons délibérément de couvrir

Certaines questions d'anti-blocage ont des réponses que nous ne publierons pas, parce que la technique n'existe que pour déjouer des contrôles d'accès :

• Contourner des paywalls ou des murs de connexion. Le contenu derrière une authentification est protégé par conception. L'automatiser pour contourner ce contrôle constitue un accès non autorisé, quel que soit l'outillage.
• Les fermes de résolution de CAPTCHA. Un CAPTCHA, c'est un site qui dit non à l'automatisation. La résolution à échelle industrielle n'existe que pour passer outre ce refus.
• Le scraping de données personnelles. Noms, e-mails, profils et coordonnées emportent des obligations légales (RGPD, CCPA) et un réel potentiel de nuisance. Les fournisseurs sérieux bloquent ces cas d'usage dans leurs politiques d'usage acceptable, à juste titre.
• L'automatisation des achats. Sneaker bots, revente de billets et fermes de comptes sont les usages qui ont donné mauvaise réputation aux proxies et que les programmes KYC des fournisseurs existent pour filtrer.

Si un projet a besoin de l'un de ces éléments, il n'a pas un problème de blocage ; il a un problème d'autorisation, et aucune ingénierie ne règle cela.

Check-list : une configuration anti-blocage éthique

• Lire le robots.txt et les CGU ; confirmer que les données sont publiques et non personnelles
• Privilégier une API ou un flux officiel quand il en existe un
• Limiter la cadence par domaine avec du jitter ; respecter Retry-After ; appliquer un backoff exponentiel
• Envoyer un jeu de headers de navigateur complet, cohérent et à jour
• Persister les cookies au sein des sessions ; apparier jars de cookies et IP ; faire expirer les sessions de façon plausible
• Utiliser des IP résidentielles rotatives d'un fournisseur imposant le KYC quand le volume l'exige réellement
• Aligner les fenêtres de session sticky sur votre parcours avec état le plus long
• Surveiller par domaine les codes de statut, les pages de défi, les anomalies de contenu et la latence
• Répondre aux signaux de blocage en ralentissant et en diagnostiquant, jamais en escaladant

Abordé ainsi, l'anti-blocage n'est pas une course à l'armement — c'est de la courtoisie élémentaire traduite en ingénierie. Les sites bloquent le trafic qui se comporte mal ; le correctif durable, c'est un trafic qui se comporte bien. Pour le contexte plus large sur les outils, la légalité et l'architecture, poursuivez avec notre guide complet du web scraping.