Notre position est claire : nous sommes Geonode et nous vendons des proxys, ce qui est précisément le produit que la plupart des articles sur ce sujet cherchent à vendre. Si l'on classe les options par ordre d'importance, les proxys arrivent en sixième position, et les cinq options qui les précèdent sont gratuites. La gestion du rythme, l’identification, la mise en cache, le respect de Retry-After et la lecture de robots.txt permettront d’éviter davantage de blocages que n’importe quelle rotation d’adresses, car ces mesures s’attaquent à la cause réelle pour laquelle les sites bloquent les robots d’indexation — la charge et l’imprévisibilité — plutôt qu’au symptôme. Les proxys aident véritablement à résoudre un problème spécifique, abordé plus loin. Si vous vous tournez vers eux en premier lieu, vous dépenserez de l’argent et serez tout de même bloqué.
Pourquoi les robots d'indexation se font-ils bloquer ?
Quatre causes, classées par ordre décroissant de fréquence.
Fréquence. Vous avez envoyé trop de requêtes trop rapidement. C'est de loin la cause la plus courante, et vous pouvez entièrement la contrôler. Un site ne sait pas qui vous êtes et s'en moque lorsqu'il décide que trente requêtes par seconde provenant d'une même adresse constituent un problème.
Imprévisibilité. Pics de trafic, tentatives répétées en cas d'erreur, exploration répétée des mêmes pages, suivi d'espaces URL infinis. Une charge que le site ne peut pas anticiper est pire qu'une charge qu'il peut prévoir.
Anonymat. Un client non identifié générant un trafic inexpliqué est un problème qu’il faut stopper. Un client identifié relève d’une décision à prendre, et souvent, cette décision est de l’autoriser.
Signaux d’identité. Type d’adresse, empreinte TLS, composition des en-têtes. Réels, et en dernier sur cette liste car ils importent principalement une fois qu’un site a déjà décidé qu’il ne voulait pas d’automatisation non identifiée — et parce qu’ils sont les plus difficiles à modifier en toute honnêteté.
Notez que trois des quatre points concernent le comportement. L’accent mis par le secteur sur le quatrième point dépend de ce qui est le plus facile à vendre, et non de ce qui provoque le plus de blocages.
Commencez par éviter d’avoir à explorer le site
La mesure la plus rentable, et celle qui est le plus souvent négligée.
Vérifiez s’il existe une API. De nombreux sites en publient une ; celle-ci est stable, structurée et validée. Explorer un site qui propose une API revient à fournir plus d’efforts pour un résultat moins satisfaisant.
Vérifiez s’il existe un flux partenaire ou affilié. Des secteurs entiers — l’emploi, l’immobilier, la vente au détail, le voyage — publient des flux en masse spécialement destinés aux agrégateurs, car ceux-ci leur apportent du trafic. Demandez avant de vous lancer. Un nombre surprenant de sites répondent par l’affirmative.
Vérifiez s’il existe un plan du site. Il vous fournit un inventaire des URL ainsi que des horodatages d’lastmod, ce qui vous permet de récupérer uniquement ce qui a changé plutôt que l’intégralité du contenu.
Vérifiez s’il y a des données structurées intégrées. Le JSON-LD dans un bloc <script type="application/ld+json"> est conçu pour être lu par les machines, résiste aux refontes et se trouve déjà dans la page que vous alliez récupérer.
Vérifiez si les données existent ailleurs. Ensembles de données publics, archives, documents officiels.
Chacune de ces solutions élimine le problème à la source plutôt que de simplement l’atténuer. Le réflexe de commencer par écrire un robot d’exploration est l’habitude la plus coûteuse dans ce domaine, et c’est pourquoi nous avons placé cette section avant toute autre partie technique. Nous avons abordé l’intégralité de la hiérarchie des sources dans comment trouver toutes les pages d’un site web.
Lisez d'abord les règles : le protocole «
robots.txt » est désormais une norme RFC 9309, et le respecter correctement relève à la fois de la conformité et de l'intérêt personnel.
Les éléments importants sur le plan opérationnel : la correspondance s'effectue par spécificité plutôt que par ordre — la règle de correspondance la plus longue l'emporte ; une réponse 5xx signifie une interdiction totale, et non « continuez » ; une réponse 404 signifie qu’il n’y a aucune restriction ; et le fichier doit être actualisé au moins toutes les 24 heures plutôt que d’être récupéré une seule fois au démarrage.
Utilisez un analyseur syntaxique mis à jour. La règle de spécificité et la normalisation par encodage en pourcentage sont toutes deux faciles à mal interpréter, et un robot d’indexation qui lit mal le fichier est un robot qui se croit conforme alors qu’il ne l’est pas. Nous avons abordé les détails dans comment lire un fichier robots.txt.
Lisez ensuite les conditions d’utilisation. « robots.txt » ne signifie pas « autorisation » — la RFC le précise clairement — et un site peut interdire l’accès automatisé, indépendamment de ce que le fichier autorise. Mieux vaut le savoir avant de commencer que de le découvrir par courrier.
Adoptez un rythme adapté
C'est la mesure technique la plus efficace, et la moins coûteuse.
Une requête toutes les une à deux secondes par domaine constitue une valeur par défaut raisonnable. Ralentissez le rythme pour les petits sites, et n'accélérez pas sans preuve que la cible le tolère.
Respectez la valeur « Crawl-delay » lorsque robots.txt en définit une. Il s’agit d’une extension plutôt que d’une partie intégrante de la norme ; la respecter ne coûte rien et témoigne de bonne foi.
Ajoutez de la variation. Des requêtes à intervalles parfaitement réguliers constituent une signature qu’aucun être humain ne produit. Une variation aléatoire entre, disons, 1,0 et 2,5 secondes permet de l’éliminer sans aucun coût.
Limitez la concurrence par domaine, et non globalement. Huit requêtes simultanées réparties sur huit domaines, c’est courtois. Huit requêtes sur un seul domaine, ça ne l’est pas.
Effectuez l’exploration pendant les heures creuses lorsque c’est possible. La tolérance d’un site est moindre lorsqu’il est très sollicité, et une tâche qui s’exécute pendant la nuit ne vous coûte rien de plus.
Et élargissez votre fenêtre de temps avant d’augmenter la capacité. C’est le recadrage le plus utile qui soit : cinquante mille pages réparties sur vingt-quatre heures nécessitent environ deux connexions simultanées ; ces mêmes cinquante mille pages en deux heures en nécessitent vingt. Si rien ne dépend de l’achèvement rapide de la tâche — et ce n’est généralement pas le cas —, le planning est le levier le moins coûteux dont vous disposez. Nous avons détaillé ces calculs dans « De combien de proxys avez-vous besoin ? ».
Identifiez-vous
Contre-intuitif, mais toujours efficace.
User-Agent: AcmePriceBot/1.2 (+https://acme.example.com/bot)
Un nom, une version et une URL où l’on peut découvrir qui vous êtes et comment vous contacter. Trois avantages, tous bien réels :
**robots.txt
peut s’adresser à vous spécifiquement.** Les règles s’appliquent en fonction du jeton du produit ; un site peut donc accorder à votre robot d’indexation une autorisation qu’il n’accorde pas à tout le monde. Cela ne peut pas se produire si vous restez anonyme.
Les opérateurs peuvent vous contacter au lieu de vous bloquer. Cela arrive plus souvent qu’on ne le pense, et c’est une issue bien plus favorable que de découvrir un blocage trois semaines plus tard.
Cela facilite la demande d’accès. « Nous sommes le robot d’indexation identifié comme AcmePriceBot ; voici ce que nous collectons et pourquoi » est une conversation qui peut mener à quelque chose.
L’alternative — une chaîne Chrome copiée — crée une contradiction plutôt qu’un déguisement, car un agent utilisateur de navigateur sur une connexion dont l’empreinte TLS et l’ensemble d’en-têtes ne correspondent manifestement pas à celles d’un navigateur est plus identifiable qu’un aveu honnête. Nous avons abordé ce sujet dans la configuration d’un agent utilisateur personnalisé avec curl.
Mise en cache et utilisation des requêtes conditionnelles
La mesure qui permet de réduire la charge sans diminuer la couverture.
Ne récupérez jamais deux fois la même ressource inchangée. Enregistrez ce que vous avez récupéré, ainsi que ses valeurs « ETag » et « Last-Modified », puis envoyez des requêtes conditionnelles :
curl -sS -H 'If-None-Match: "abc123"' https://example.com/page
Un fichier « 304 Not Modified » ne pèse que quelques centaines d’octets, contre une page entière. Lors d’une nouvelle exploration où la plupart des pages sont inchangées, cela réduit à la fois votre facture de bande passante et la charge du site cible d’un ordre de grandeur.
Utilisez les balises « lastmod » du plan du site pour déterminer ce qu’il faut récupérer. Un site comptant cinquante mille pages, dont deux cents ont été modifiées aujourd’hui, nécessite un exploration de deux cents pages, et non de cinquante mille.
Stockez les réponses brutes. Lorsqu’un analyseur rencontre un problème, réanalysez ce dont vous disposez plutôt que de récupérer à nouveau les données. C’est à la fois une économie et une marque de courtoisie.
Dédupliquez correctement les URL. Normalisez les barres obliques finales, l’ordre des paramètres de requête, la casse des noms d’hôte et supprimez les paramètres de suivi. Un robot d’exploration qui ne procède pas à cette normalisation visite plusieurs fois la même page et donne l’impression d’être un client beaucoup plus lourd qu’il ne l’est en réalité.
Gérer les erreurs selon les instructions du serveur
Les serveurs vous indiquent la marche à suivre. Lire ces instructions est non seulement la bonne approche, mais aussi le moyen le plus rapide de rétablir le fonctionnement.
429 Too Many Requests est défini dans la RFC 6585 comme indiquant « que l'utilisateur a envoyé trop de requêtes dans un laps de temps donné (« limitation de débit ») ». La réponse « PEUT inclure un en-tête Retry-After indiquant le délai à respecter avant d'effectuer une nouvelle requête ».
503 Service Unavailable signifie que le serveur « est actuellement incapable de traiter la requête en raison d’une surcharge temporaire ou d’une maintenance programmée », et qu’il « PEUT envoyer un champ d’en-tête Retry-After… pour suggérer au client un délai d’attente approprié ».
Retry-After prend soit une date HTTP, soit un nombre de secondes, conformément à la RFC 9110 — « Retry-After: 120 » signifie « attendre deux minutes ».
Comportement correct en cas de code 429 ou 503 :
Cesser toute requête vers ce domaine. Pas simplement ralentir, mais cesser complètement, pendant au moins l’intervalle indiqué.
Si aucune valeur Retry-After n’est fournie, réduisez le débit de manière exponentielle en partant d’une valeur généreuse.
Réduisez ensuite votre débit en régime permanent, car on vient de vous signaler qu’il était trop élevé.
Ne réessayez jamais immédiatement. Réessayer alors qu’une limite de débit est en vigueur, c’est ce qui transforme une restriction temporaire en blocage permanent, et c’est l’erreur la plus courante commise par les robots d’exploration.
Notez également que la RFC 6585 stipule que « les réponses avec le code d’état 429 NE DOIVENT PAS être stockées par un cache » — une couche de mise en cache ne vous protégera donc pas contre la répétition de cette erreur.
Dans quels cas les proxys sont-ils vraiment utiles ?
Notre propre produit, décrit aussi précisément que possible.
Ils sont utiles lorsque : vous avez optimisé votre débit mais avez encore besoin d’un débit qu’une seule adresse ne peut pas fournir ; vous avez besoin d’accéder à du contenu spécifique à une région, où l’essentiel est de donner l’impression de se trouver à un certain endroit ; vous exploitez des robots d’exploration distribués et souhaitez qu’ils apparaissent comme des clients distincts plutôt que comme une seule machine comportant de nombreux threads ; ou encore l’adresse que vous utilisez souffre d’une mauvaise réputation sans que cela soit de votre faute.
Ils ne sont d’aucune utilité lorsque : vous allez trop vite — le même débit provenant d’un plus grand nombre d’adresses reste le même débit, et vous venez de signaler un pool au lieu d’une simple adresse. Ni lorsque le profil de vos requêtes est identifié par l’empreinte TLS ou la composition des en-têtes, puisque ceux-ci vous accompagnent partout. Ni lorsque le règlement d’un site interdit l’accès automatisé, ce que l’utilisation d’un plus grand nombre d’adresses ne change en rien.
Quel type choisir : un centre de données pour la plupart des activités d’exploration, car c’est nettement moins cher et les pages publiques ne nécessitent généralement rien de plus — nos tarifs commencent à 0,14 $/Go. Passez à l’hébergement résidentiel, à partir de 0,79 $/Go, uniquement lorsque le centre de données échoue manifestement ou lorsque vous avez besoin d’une géolocalisation sur le réseau grand public. Chiffres tirés de notre page de tarification, vérifiés en septembre 2026.
Le coût qui surprend le plus : les navigateurs « headless ». Un navigateur récupère chaque image, police et script, ce qui fait grimper la bande passante d’environ un ordre de grandeur par rapport au protocole HTTP brut. Si une page ne nécessite pas de JavaScript, ne la rendez pas — et si c’est le cas, bloquez les types de ressources dont vous n’avez pas besoin.
Distinguer un blocage « dur » d’un blocage « souple »
Le mode de défaillance le plus coûteux, car il ne ressemble pas à une défaillance.
Un blocage « dur » renvoie un code 403, une page d’authentification ou un refus de connexion. C’est flagrant, évident et permet une intervention immédiate.
Un blocage « soft » renvoie un code 200 avec un contenu réduit : moins d’éléments, des champs supprimés, des données obsolètes ou une page générique à la place de la page spécifique. Votre taux de réussite reste à 99 % et la qualité de vos données se dégrade discrètement. C’est la réponse la plus courante des sites sophistiqués, précisément parce qu’elle gaspille votre budget sans vous avertir.
Méfiez-vous-en explicitement :
Vérifiez le contenu, pas le statut. Recherchez un indicateur connu pour être stable sur la page et considérez son absence comme une erreur. Vérifiez les nombres. Si une page de catégorie n’a jamais compté moins de vingt éléments, considérez qu’un nombre inférieur à vingt est un échec. Segmentez les indicateurs par cible. Douze cibles à 99 % et une à 40 % donnent une moyenne qui semble satisfaisante. Comparez régulièrement avec un navigateur. Récupérez manuellement une page et comparez-la à ce que votre robot d’indexation a reçu.
Il s’agit du même schéma d’échec silencieux que nous avons décrit dans Pourquoi il est important de tester les proxys, et c’est la raison pour laquelle « nous avons été bloqués pendant trois semaines sans nous en rendre compte » constitue une catégorie d’incident bien réelle.
Quand s'arrêter
La partie qu'un fournisseur de proxy a le moins envie de rédiger.
Lorsque les conditions d'utilisation l'interdisent. Certains sites le précisent explicitement et veillent au respect de cette règle. Contourner une interdiction clairement énoncée est une décision dont les conséquences vont bien au-delà du simple aspect technique.
Lorsqu’on vous a demandé d’arrêter. Une demande directe de la part d’un exploitant de site met fin à la discussion.
Lorsque l’effort dépasse la valeur ajoutée. Si vous devez repenser votre approche tous les quinze jours, les données coûtent plus cher qu’elles n’en valent la peine. Il s’agit là d’une conclusion commerciale, et non d’un échec technique.
Lorsqu’il existe une voie légitime. Une API, un flux, un ensemble de données sous licence. Payer pour un accès autorisé revient souvent moins cher que le temps de développement passé à le contourner, et cela ne pose aucun problème.
Lorsque le site a déployé des pièges. Les « tarpits » et les labyrinthes générés sont conçus pour vous coûter plus cher qu’ils ne coûtent au site : ils servent du contenu mis en cache tandis que vous payez au gigaoctet et à l’heure de calcul. Cette asymétrie est délibérée et ne cède pas face à vos efforts.
Demandez d’abord. Un e-mail expliquant qui vous êtes, ce dont vous avez besoin et en quelle quantité résout ce problème plus souvent qu’on ne le pense, et vous permet d’obtenir un accès qui fonctionne durablement.
Questions fréquentes
Pourquoi mon robot d'indexation est-il sans cesse bloqué ?
Généralement à cause du débit. Un nombre trop élevé de requêtes envoyées trop rapidement depuis une même adresse est, de loin, la cause la plus courante, et vous pouvez entièrement la contrôler. Les schémas imprévisibles, les tentatives répétées en cas d'erreur et l'identification anonyme représentent la majeure partie des autres causes.
À quelle vitesse puis-je explorer un site web ?
Commencez par une requête toutes les une à deux secondes par domaine et n’accélérez que si vous avez la certitude que la cible le tolère. Respectez la limite de requêtes par seconde (Crawl-delay) si robots.txt en définit une. Si vous avez besoin d’un débit plus élevé, élargir votre fenêtre temporelle est moins coûteux et plus sûr que d’augmenter le nombre de requêtes simultanées.
Les proxys vous empêchent-ils d’être bloqué ?
Uniquement pour les blocages spécifiques à une adresse. Si vous allez trop vite, le même débit provenant de plusieurs adresses reste le même et déclenche désormais un signalement sur l’ensemble du pool. Si le profil de vos requêtes est identifié via l’empreinte TLS ou les en-têtes, ceux-ci vous suivent quelle que soit l’adresse.
Dois-je faire tourner les agents utilisateurs ?
Non. Une rotation aléatoire au sein d’une même session donne l’impression que le client change de navigateur en cours de visite, ce qui constitue une incohérence plutôt qu’un camouflage. Un agent utilisateur unique et honnête, accompagné d’une URL de contact, est moins souvent bloqué que n’importe quel système de rotation.
Que dois-je faire lorsque j’obtiens un code 429 ?
Cessez toute requête vers ce domaine et attendez au moins le temps spécifié par l’en-tête Retry-After. En l’absence de cet en-tête, réduisez vos requêtes de manière exponentielle à partir d’un seuil de départ généreux, puis diminuez votre débit en régime permanent — on vient de vous signaler qu’il était trop élevé. Ne réessayez jamais immédiatement.
Comment savoir si je fais l’objet d’un blocage souple ?
Vérifiez le contenu plutôt que les codes d’état. Recherchez un marqueur connu pour être stable sur chaque page, vérifiez que le nombre d’éléments correspond aux attentes, segmentez les indicateurs de réussite par cible plutôt que de manière agrégée, et comparez périodiquement une page explorée à celle affichée dans un navigateur.
L’exploration d’un site web est-elle légale ?
Cela dépend de la juridiction, des conditions d’utilisation du site, des données concernées et de l’usage que vous en faites. Respecter les robots.txt, identifier votre robot d’exploration et maintenir un débit modéré constituent des pratiques courantes, et aucune de ces mesures ne prévaut sur les conditions d’utilisation ou le droit d’auteur. Demandez conseil pour toute activité à caractère commercial.
Quelle est la mesure la plus efficace que je puisse prendre ?
Prenez votre temps et vérifiez si vous avez réellement besoin d’effectuer un crawling. Une API, un flux partenaire ou un plan du site comportant des horodatages lastmod élimine le problème plutôt que de l’atténuer — et lorsque le crawling est véritablement nécessaire, le fait de modérer la fréquence permet d’éviter davantage de blocages que toutes les autres mesures combinées.
En conclusion
Ce qui rend cette question abordable, c’est de considérer que le blocage est une réponse à la charge et à l’imprévisibilité, et non à l’identité. Les sites ne s’opposent pas à être consultés ; ils s’opposent à être submergés par quelque chose qu’ils ne peuvent ni prévoir ni contacter.
Ce qui place les mesures efficaces dans un ordre que la plupart des articles inversent. Vérifiez si vous avez réellement besoin d’effectuer un crawl, car une API ou un flux partenaire peut éliminer complètement le problème. Lisez le document « robots.txt » et respectez-le scrupuleusement, y compris les parties concernant la correspondance de spécificité et la signification du code d’erreur 5xx (« stop »). Adoptez un rythme modéré et ajoutez du jitter. Identifiez-vous à l’aide d’un nom et d’une URL de contact. Mettez en cache de manière intensive et utilisez des requêtes conditionnelles afin de ne jamais récupérer à nouveau ce qui n’a pas changé. Suivez les conseils donnés sur Retry-After.
Tout cela est gratuit et vous évitera davantage de blocages que n’importe quel achat d’infrastructure. Les proxys aident à résoudre un problème bien précis et plus restreint — le débit dépassant le plafond d’une seule adresse, et le contenu variant selon les régions — mais ils ne sont d’aucune utilité pour le reste de la liste.
Et gardez à l’esprit la dernière section. Un site qui a énoncé ses conditions, mis en place des pièges ou vous a demandé de cesser vos activités vous a fait passer un message, et les alternatives consistant à contourner ces mesures techniques sont généralement moins coûteuses et toujours plus durables.