La plupart des guides de scraping optimisent une seule chose : obtenir les données sans se faire arrêter. C’est un objectif légitime, mais il saute la partie qui décide si votre pipeline survit au-delà du premier mois. Un scraper qui martèle une cible aussi vite qu’il peut n’est pas seulement grossier, il est fragile. Il fait grimper la charge du site, déclenche toutes les limites de débit et règles anti-bot qu’il possède, et transforme une source que vous vouliez lire discrètement en une source qui essaie activement de vous exclure.
Le point contre-intuitif, c’est que la façon responsable de scraper et la façon durable de scraper sont la même chose. Vous comporter en client attentionné, un qui respecte les limites, répartit la charge et ne demande que ce dont il a besoin, est exactement le profil qui reste sous les seuils de détection et continue de fonctionner. C’est le côté étiquette de la même médaille que comment éviter de se faire bloquer : ce billet parle de ne pas ressembler à un bot, celui-ci de ne pas se comporter comme un bot nuisible. Faites le second et le premier se règle presque tout seul.
Voici à quoi ressemble, en pratique, un scraping responsable et durable.
Lisez robots.txt, et prenez-le au sérieux
Tout site bien géré publie un robots.txt à sa racine qui indique quels chemins les clients automatisés ne devraient pas toucher et, parfois, un Crawl-delay. Ce n’est pas un contrat légal ni une barrière technique, c’est le site qui vous dit ses préférences au seul endroit fait pour cela. L’ignorer entièrement est le signal le plus clair que vous n’êtes pas un visiteur de bonne foi.
La posture pratique : récupérez robots.txt une fois au début d’une exécution, mettez-le en cache et respectez ses chemins interdits pour le user-agent que vous présentez. S’il spécifie un délai de crawl, traitez-le comme un plancher, pas une suggestion. Il existe des raisons légitimes pour que certains projets divergent de parties de ce fichier, mais « je n’ai jamais regardé » n’en est pas une. Le lire vous dit aussi où le site garde un sitemap, qui est souvent une façon bien plus propre de découvrir des URLs que de crawler lien par lien.
Limitez votre débit avant que le site n’ait à le faire
La chose la plus nuisible qu’un scraper fasse est d’envoyer des requêtes aussi vite que le réseau le permet. Une cible dimensionnée pour du trafic humain peut être poussée vers des temps de réponse dégradés, voire au-delà, par un seul client agressif. Cela nuit à de vrais utilisateurs, et c’est le moyen le plus rapide de faire bloquer toute votre plage d’IP.
Fixez un débit de requêtes délibéré et restez en dessous. Quelques requêtes par seconde par hôte suffisent largement pour la plupart des travaux, et plus lent est plus sûr sur les petits sites. Ajoutez un petit jitter aléatoire entre les requêtes plutôt qu’un intervalle de métronome fixe, pour que votre trafic ne paraisse pas mécaniquement uniforme. Le but est d’être un visiteur modeste parmi d’autres, pas un pic sur le tableau de bord de surveillance de quelqu’un. Si vous avez besoin de plus de débit total, répartissez-le dans le temps et à travers un pool rotatif plutôt que d’augmenter la pression sur un seul hôte.
Ralentissez quand le site dit non
Un 429 Too Many Requests ou un 503 est le serveur qui vous dit explicitement de ralentir. La mauvaise réponse est de réessayer immédiatement, exactement ce qu’un serveur surchargé ne peut pas gérer. La bonne réponse est le backoff exponentiel : attendez, réessayez, et si ça échoue encore attendez plus longtemps, en doublant le délai à chaque fois jusqu’à un plafond. Respectez un en-tête Retry-After quand le serveur en envoie un, il vous dit précisément combien de temps attendre.
C’est différent de réessayer une requête réellement échouée. Une connexion coupée ou un timeout est une tentative cassée qui vaut la peine d’être réessayée rapidement ; un 429 est un serveur qui fonctionne et qui demande de l’espace. Traitez-les différemment. Réessayer aveuglément les 429 dans une boucle serrée, c’est ainsi qu’un scraper transforme une limite de débit souple en un bannissement dur.
Mettez en cache agressivement et ne récupérez jamais deux fois la même chose
La requête la moins chère est celle que vous n’envoyez pas. Avant de monter en échelle, regardez de près combien vous re-récupérez. Mettre en cache les réponses, respecter ETag et Last-Modified avec des requêtes conditionnelles, et dédupliquer votre frontière d’URLs réduit régulièrement le volume réel de requêtes de larges marges. Chaque requête évitée est de la charge que vous n’avez pas mise sur la cible, de la bande passante que vous n’avez pas dépensée, et un événement de risque de blocage qui n’a jamais eu lieu.
Cela recoupe directement le coût. La même discipline qui fait de vous un invité plus léger réduit aussi votre facture de bande passante de proxy : ne demandez que les pages dont vous avez besoin, ne récupérez que les champs que vous utilisez, et sautez les ressources comme les images et les polices quand vous ne voulez que le HTML. Courtoisie et efficacité sont le même ensemble d’habitudes.
Scrapez pendant les heures creuses
Si vous pouvez contrôler quand un travail s’exécute, exécutez-le quand la cible est calme. Un lot qui serait perceptible à midi est invisible face au faible trafic nocturne dans le fuseau horaire local du site. C’est la différence entre ajouter de la charge quand le serveur peut le moins se le permettre et emprunter une capacité qui serait sinon inutilisée. Pour les gros tirages récurrents, planifiez face à la fenêtre creuse de la cible, pas la vôtre.
Identifiez-vous honnêtement là où vous le pouvez
Il y a ici une vraie tension, et il vaut la peine d’être direct là-dessus. La bonne étiquette de scraping signifie traditionnellement envoyer un User-Agent descriptif qui nomme votre bot et un moyen de vous contacter, pour qu’un administrateur qui remarque votre trafic puisse vous joindre au lieu de recourir à un blocage. Beaucoup de crawlers sérieux et réglementaires font exactement cela.
En même temps, les sites bloquent de plus en plus tout ce qui se déclare automatisé quel que soit le comportement, ce qui pousse les scrapers à se présenter comme un navigateur ordinaire. Les deux postures sont défendables selon votre cas d’usage. Ce qui n’est pas défendable, c’est de se faire passer pour un service précis que vous n’êtes pas, ou d’usurper le crawler d’une autre entreprise. Choisissez une présentation honnête pour votre situation et gardez-la cohérente. Si vous collectez des données pour une entreprise, avoir une page publique qui explique ce que fait votre crawler et comment vous contacter ne coûte rien et désamorce beaucoup de conflits.
Ne prenez que des données publiques, et surveillez ce qu’elles contiennent
Le scraping responsable signifie des pages publiques, atteintes sans franchir un mur d’authentification ni accepter des conditions que vous ignorez ensuite. Les données derrière un login sont une catégorie légale et éthique différente, et savoir si le scraping lui-même est légal dépend fortement de cette ligne. Restez de son côté public.
Soyez tout aussi attentif à ce que contiennent les données qu’à leur provenance. Si les pages incluent des informations personnelles, vous héritez d’obligations de confidentialité dès l’instant où vous les stockez, et collecter des données personnelles à grande échelle fait entrer en jeu le RGPD et des régimes similaires. La posture la plus propre est d’exclure les données personnelles de votre collecte sauf raison licite spécifique de les détenir, et de ne pas conserver ce dont vous n’avez pas besoin.
Où s’insèrent les proxys, et pourquoi les bons vous rendent plus doux
Rien de ce qui précède n’est un argument contre les proxys, c’est un argument pour les utiliser correctement. Un pool résidentiel de qualité est ce qui vous permet de répartir un débit de requêtes raisonnable sur de nombreuses IP et géographies au lieu de concentrer la pression sur une cible depuis une seule adresse. Bien utilisé, c’est un outil de répartition de charge et de localisation, pas un moyen de frapper un site plus fort.
La qualité du pool décide aussi à quelle fréquence vous réessayez tout court. Des IP propres avec une bonne réputation passent là où les IP marquées sont défiées, donc un meilleur pool signifie moins de tentatives échouées, moins de réessais, et moins de charge totale que vous générez pour les mêmes données. Tourner avec bon sens, une identité par unité logique de travail plutôt qu’une nouvelle IP en milieu de session (sticky vs rotatif), garde votre empreinte cohérente et légère. Et maintenir la latence basse signifie que chaque requête se termine et libère vite au lieu de s’accumuler.
Une courte liste
- Récupérez et respectez
robots.txt; utilisez le sitemap qu’il pointe. - Fixez un débit délibéré par hôte avec jitter aléatoire ; quelques requêtes par seconde suffisent en général.
- Ralentissez exponentiellement sur
429/503; respectezRetry-After. Ne confondez pas avec réessayer une requête cassée. - Mettez en cache, utilisez les requêtes conditionnelles, dédupliquez. La requête la moins chère est celle que vous sautez.
- Ne récupérez que les pages et champs dont vous avez besoin ; sautez les ressources que vous n’utiliserez pas.
- Préférez les heures creuses dans le fuseau horaire de la cible pour les gros travaux.
- Choisissez une identité honnête et cohérente. N’usurpez jamais le crawler d’une autre entreprise.
- Données publiques uniquement. Excluez les données personnelles que vous n’avez pas de raison licite de conserver.
- Utilisez un pool résidentiel propre pour distribuer la charge, pas pour l’intensifier.
En résumé
Les scrapers qui continuent de tourner pendant des années ne sont pas les plus agressifs, ce sont ceux que la cible remarque à peine. Chaque pratique ici, limitation de débit, backoff, mise en cache, planification hors pointe, identification honnête, pointe dans la même direction : prenez ce dont vous avez besoin, laissez le site en bonne santé, et ressemblez au client attentionné que vous êtes vraiment. C’est la façon éthique de scraper, et il se trouve que c’est la façon qui ne vous fait pas bloquer.
Si vous voulez une infrastructure conçue pour distribuer la charge plutôt que la concentrer, nos proxys résidentiels tournent sur un pool propre et rotatif, et la page tarifs propose des forfaits au Go pour qu’un scraping plus léger et plus intelligent vous coûte, de fait, moins cher.