Le crawling web est le moteur derrière les moteurs de recherche, les moniteurs de prix et presque tous les grands jeux de données web, mais le terme cache beaucoup d'ingénierie. Un robot d'indexation n'est pas simplement une boucle qui télécharge des pages. C'est un système qui décide quels liens suivre, dans quel ordre, à quelle vitesse et comment éviter de télécharger deux fois la même page tout en terminant dans un délai raisonnable. Prenez ces décisions correctement et un crawl s'adapte proprement à des millions d'URLs. Prenez-les mal et il stagne, boucle ou se fait bloquer son IP dès les mille premières requêtes.
Ce guide parcourt les techniques de crawling web fondamentales qui distinguent un robot robuste d'un robot naïf, puis passe en revue les frameworks que les équipes utilisent quand elles ne veulent pas construire cette machinerie de zéro. À la fin, vous devriez comprendre comment un crawl traverse réellement le web, les compromis derrière chaque technique, et quel outil convient au travail que vous avez devant vous.
Qu'est-ce que le crawling web ?
Un robot d'indexation web, aussi appelé spider ou robot web, découvre et télécharge automatiquement des pages en suivant des liens. Il part d'un ensemble d'URLs de départ, récupère chaque page, extrait les liens qu'il y trouve et ajoute les nouveaux dans une file d'attente de pages encore à visiter. En répétant cette boucle, le robot parcourt un site ou le web plus large vers l'extérieur, construisant un enregistrement de ce qu'il a trouvé. Les moteurs de recherche constituaient le cas d'usage originel : leurs bots indexent le contenu des pages pour qu'il puisse apparaître dans les résultats.
En chemin, un robot collecte plus que du HTML brut. Il enregistre l'URL de chaque page, son titre et ses métadonnées, le contenu du corps, et les liens sortants et leurs destinations. Il garde une note des URLs déjà téléchargées pour ne pas récupérer deux fois la même page, et peut signaler des liens brisés ou comparer des versions d'une page au fil du temps. La même machinerie propulse des tâches pratiques comme l'archivage de sites, la constitution de catalogues de produits, la surveillance des prix des concurrents et le suivi des mentions dans les actualités et les sources sociales.
L'indexation et le scraping sont liés mais distincts. L'indexation est l'étape de découverte et de traversée : trouver et récupérer les pages. Le scraping est l'étape d'extraction : extraire des champs spécifiques du balisage une fois qu'on l'a. La plupart des vrais projets font les deux, mais les techniques ci-dessous concernent le crawl : comment traverser le web efficacement, poliment et sans rester bloqué.
Techniques fondamentales de crawling web
Les techniques de cette section sont les décisions que tout robot sérieux doit prendre, que vous les écriviez vous-même ou les héritiez d'un framework. Elles couvrent l'ordre dans lequel les pages sont visitées, comment la file d'attente de travail est gérée, comment le robot reste un bon citoyen des sites qu'il touche, et comment il gère les pages modernes qui se construisent avec JavaScript.
Traversée en largeur d'abord vs en profondeur d'abord
Le web est un graphe, et l'ordre dans lequel vous le parcourez change ce que vous collectez en premier. Le crawling en largeur d'abord visite toutes les pages à un lien des amorces, puis tout ce qui est à deux liens, et ainsi de suite, s'étendant en anneaux croissants. C'est le défaut habituel pour les crawls généraux car il atteint rapidement un échantillon large et peu profond d'un site et tend à trouver tôt les pages de grande valeur (souvent liées depuis de nombreux endroits). Le crawling en profondeur d'abord suit plutôt un chemin aussi loin qu'il va avant de revenir en arrière, plongeant profondément dans une seule branche avant d'explorer les branches voisines.
En pratique, la largeur d'abord, implémentée avec une file FIFO, domine les grands crawls car elle donne une couverture régulière et est facile à délimiter. La profondeur d'abord, soutenue par une pile, convient aux cas où vous voulez épuiser complètement une section avant de passer à la suivante, comme le crawl d'un catalogue profondément imbriqué. Beaucoup de robots utilisent un hybride, en priorisant la file par un score (popularité des liens, profondeur de page, fraîcheur) plutôt que par une stricte largeur ou profondeur, pour que les pages les plus utiles soient récupérées en premier.
La frontière d'URLs et la déduplication
La file d'attente des URLs en attente d'être crawlées s'appelle la frontière, et la gérer correctement représente l'essentiel de ce qui fait évoluer un robot. La frontière décide quelle URL vient ensuite, applique l'ordre et la priorité, et alimente les récupérateurs. À toute échelle réelle, elle doit vivre hors de la mémoire (dans une base de données ou une file distribuée) car la liste des URLs découvertes croît bien plus vite que la liste des URLs déjà visitées.
Le problème complémentaire est la déduplication. La même page est accessible via de nombreuses URLs, des paramètres de tracking et des chaînes de redirection, donc sans étape de déduplication, un robot télécharge le même contenu encore et encore et peut boucler indéfiniment. La solution standard est de normaliser chaque URL (mettre l'hôte en minuscules, supprimer les ports par défaut, abandonner les fragments et les paramètres de tracking connus) et de la vérifier contre un ensemble d'URLs déjà vues. Pour les très grands crawls, cet ensemble est souvent une structure efficace en mémoire comme un filtre de Bloom, qui répond à la question « ai-je déjà vu cette URL ? » en utilisant une fraction de la mémoire qu'une liste complète nécessiterait.
Politesse et limitation du débit
Un robot qui envoie des requêtes aussi vite qu'il le peut surchargera les petits serveurs et se fera limiter ou bannir. La politesse est la discipline de cadencer les requêtes pour que le crawl ne nuise pas aux sites qu'il visite. La règle de base est un délai par hôte : limitez le nombre de requêtes envoyées à un seul domaine par seconde, et ajoutez une courte attente entre les hits sur le même hôte, même pendant que vous crawlez de nombreux autres hôtes en parallèle.
Une bonne politesse combine quelques habitudes. Limitez la concurrence par domaine plutôt que globalement, pour qu'aucun site ne soit inondé. Respectez tout Crawl-delay qu'un site annonce, et reculez quand vous voyez des erreurs ou des réponses lentes, car un serveur en difficulté devrait être sollicité moins, pas plus. Au-delà d'être courtois, c'est pratique : un trafic doux et bien identifié est bien moins susceptible de déclencher des limites de débit qu'un crawl agressif, la politesse et la fiabilité pointent donc dans la même direction.
Respecter robots.txt
La plupart des sites publient un fichier robots.txt à leur racine qui indique quels chemins les robots peuvent et ne peuvent pas visiter, et à quels agents utilisateurs les règles s'appliquent. Un robot bien élevé récupère et analyse ce fichier avant de crawler un hôte, puis ignore les chemins non autorisés. Le fichier peut aussi annoncer un Crawl-delay et pointer vers le sitemap du site, qui est une liste prête à l'emploi d'URLs que le site veut voir crawlées.
Respecter robots.txt est l'attente de base pour le trafic automatisé et le signal le plus clair d'un robot responsable. Mettez en cache les règles analysées par hôte pour ne pas récupérer le fichier constamment, et rafraîchissez-les périodiquement car les règles changent. Les sitemaps valent la peine d'être utilisés directement : ils exposent souvent des pages que le seul suivi de liens manquerait, et ils donnent des indications sur la fraîcheur de chaque URL, ce qui alimente les décisions de priorisation ci-dessus.
Gérer le rendu JavaScript
Une part croissante du web construit son contenu dans le navigateur. Le HTML qu'une simple requête HTTP renvoie est presque vide jusqu'à ce que JavaScript côté client s'exécute et injecte le vrai contenu. Un robot qui ne lit que la réponse initiale ne voit presque rien sur ces pages. Pour les crawler, vous devez rendre la page comme le ferait un navigateur, ce qui signifie exécuter un navigateur sans interface graphique comme celui piloté par Puppeteer, Playwright ou Selenium qui exécute les scripts et renvoie le DOM entièrement construit.
Le rendu est puissant mais coûteux : un vrai navigateur utilise bien plus de CPU et de mémoire qu'une requête HTTP, vous ne voulez donc pas rendre chaque page. L'approche habituelle est de détecter quelles cibles en ont réellement besoin et de ne rendre que celles-là, en maintenant le chemin de récupération bon marché pour les pages statiques. Pour un regard plus approfondi sur cette séparation, voyez comment crawler les sites web JavaScript, qui couvre quand le rendu est requis et comment l'empêcher de dominer votre budget de crawl.
Crawling distribué
Une seule machine ne peut récupérer qu'un certain nombre de pages par seconde. Au-delà d'une certaine échelle, le crawl doit se répartir sur plusieurs workers, c'est le crawling distribué. La frontière devient une file partagée, plusieurs récupérateurs en tirent des URLs en parallèle, et l'ensemble de déduplication est partagé pour que deux workers ne crawlent pas la même page. Fait correctement, le débit s'adapte presque linéairement au nombre de workers.
Les parties difficiles sont la coordination et la politesse. Le travail doit être partitionné pour que toutes les requêtes vers un hôte donné passent par le même worker ou budget de débit, sinon dix workers chacun « poliment » touchant un site combinent pour former une inondation impolie. L'état (la frontière, l'ensemble vu, les résultats) doit être partagé et cohérent entre les machines. Ce surcoût de coordination est exactement pourquoi beaucoup d'équipes confient les grands crawls à un service géré plutôt que d'exploiter un cluster distribué elles-mêmes.
Le crawling distribué, la rotation, le rendu et les nouvelles tentatives sont les parties d'un robot difficiles à construire et encore plus difficiles à maintenir en fonctionnement. La Crawlbase Crawling API prend une URL et gère la rotation des IPs, le rendu JavaScript et les nouvelles tentatives automatiques sur les blocages, renvoyant du HTML propre pour que vous conserviez votre propre logique de traversée et d'analyse. Pour les grands jobs, le Crawler asynchrone vous permet de pousser des URLs et de recevoir les résultats via callback, pour que vous crawliez à grande échelle sans gérer vous-même un parc de workers ou un pool de proxies.
Crawling incrémental et ciblé
Crawler une seule fois est rarement tout le travail. Le web change, donc un robot qui a déjà indexé un site doit le revisiter sans tout re-télécharger. Le crawling incrémental suit ce qui a changé et récupère sélectivement, en utilisant des signaux comme la date de dernière modification d'une page, son entrée de sitemap, ou la fréquence à laquelle elle a changé auparavant, pour que les pages fréquemment mises à jour soient revisitées souvent et les pages statiques laissées de côté. Cela maintient un grand index à jour sans payer le coût total d'un recrawl complet à chaque fois.
Le crawling ciblé réduit l'autre axe : au lieu d'essayer de tout couvrir, il ne poursuit que les pages pertinentes pour un sujet ou un motif. Le robot score chaque lien découvert pour évaluer sa probabilité de mener vers le contenu cible et priorise les prometteurs, élaghant les branches qui s'éloignent du sujet. Un moniteur de prix vertical, par exemple, suit les liens de produits et de catégories et ignore le reste. Les deux techniques consistent à dépenser un budget de crawl fini là où cela compte plutôt que de crawler de manière indiscriminée.
Frameworks de crawling web
Peu d'équipes implémentent la frontière, la déduplication, la politesse et la machinerie de rendu de zéro. Les frameworks regroupent ces techniques dans des outils réutilisables pour que vous configuriez un crawl plutôt que de construire la plomberie. Les choix ci-dessous sont les options établies et largement utilisées, ordonnées approximativement de l'extrémité légère des scripts vers les systèmes lourds à l'échelle de la recherche, plus l'approche gérée pour les équipes qui préfèrent ne pas gérer l'infrastructure de crawl du tout.
Scrapy
Scrapy est le framework de crawling le plus populaire dans l'écosystème Python et le point de départ habituel pour les robots personnalisés. Il vous donne tout le pipeline : un moteur asynchrone qui récupère de nombreuses pages en même temps, un planificateur de requêtes qui gère la frontière, le suivi automatique des liens, les nouvelles tentatives et l'export intégré de données structurées en JSON, CSV ou XML. Vous écrivez des spiders qui définissent où commencer et comment analyser chaque page, et Scrapy gère la concurrence et la mise en file en dessous. C'est le bon choix pour les crawls récurrents de milliers à millions de pages où vous voulez structure et contrôle. Scrapy vanilla n'exécute pas JavaScript, bien qu'il s'intègre avec des outils de navigateur quand une cible en a besoin.
Apache Nutch
Apache Nutch est un robot mature et open-source conçu pour le crawling à l'échelle du web et l'intégration étroite avec le monde de la recherche. Il fonctionne sur Apache Hadoop, donc son crawl est distribué sur un cluster par conception, et il se connecte à des backends d'indexation comme Apache Solr ou Elasticsearch. Nutch est construit autour de la boucle de crawl classique des moteurs de recherche (générer une liste de récupération, récupérer, analyser, mettre à jour la base de données de crawl) et est extensible via un système de plugins pour les protocoles, les analyseurs et les filtres. Il est plus lourd à opérer que Scrapy et destiné aux équipes qui crawlent de très grandes parties du web et ont besoin d'un pipeline Hadoop éprouvé.
Heritrix
Heritrix est le robot d'indexation construit par l'Internet Archive et utilisé pour capturer des pages pour la Wayback Machine. Il est conçu pour des crawls complets de qualité archivistique et écrit sa sortie au format WARC standard, qui préserve les données complètes de requête et de réponse pour l'archivage à long terme. Heritrix est hautement configurable autour des règles de portée, de la politesse et de ce qu'il faut capturer, et respecte robots.txt rigoureusement par défaut. Optez pour lui quand la préservation fidèle et complète des pages est l'objectif, comme la constitution d'une archive web, plutôt que l'extraction de quelques champs pour l'analyse.
StormCrawler
StormCrawler est une collection de ressources pour construire des robots d'indexation web scalables à faible latence sur Apache Storm. Parce que Storm est un système de traitement de flux, StormCrawler crawle en continu plutôt que par lots, ce qui convient aux cas d'usage qui ont besoin de données fraîches de manière continue, comme les crawls d'actualités et de surveillance. Il est modulaire et basé sur Java, vous permettant d'assembler une topologie de crawl à partir de composants pour la récupération, l'analyse et l'indexation. Il se situe dans un territoire similaire à Nutch mais favorise le crawling continu en temps réel plutôt que le modèle orienté batch de Nutch.
Crawling géré avec Crawlbase
Les frameworks ci-dessus vous donnent la logique de crawl mais vous laissent les problèmes réseau : rotation des IPs, rendu JavaScript, résolution ou évitement des CAPTCHA, et nouvelles tentatives sur les requêtes bloquées. Un service de crawling géré absorbe cette couche. Avec Crawlbase, vous envoyez une URL et récupérez du HTML rendu, avec rotation des proxies et gestion anti-blocage côté serveur, et le Crawler asynchrone met en file de grands lots et livre les résultats par callback. Il ne remplace pas votre stratégie de crawl, la sélection des amorces, la traversée et l'analyse restent les vôtres, mais il supprime l'infrastructure la plus difficile à maintenir à grande échelle.
Frameworks en un coup d'oeil
Le tableau associe chaque framework à ce en quoi il excelle et au type de projet qui lui convient, pour que vous puissiez y projeter votre propre travail plutôt que de vous rabattre par défaut sur celui que vous avez utilisé en dernier.
| Framework | Idéal pour | Type |
|---|---|---|
| Scrapy | Crawls personnalisés, de milliers à millions de pages | Framework Python |
| Apache Nutch | Crawls de recherche Hadoop à l'échelle du web | Robot distribué |
| Heritrix | Capture de pages archivistique haute fidélité (WARC) | Robot d'archivage |
| StormCrawler | Crawls de surveillance continus à faible latence | Robot en flux |
| Crawlbase | Crawling géré sans infrastructure anti-blocage | Crawling API / Crawler async |
Aucune ligne unique n'est la réponse à chaque crawl. Scrapy couvre la plupart des travaux personnalisés, Nutch et StormCrawler gèrent les crawls à l'échelle du web et continus, Heritrix se spécialise dans l'archivage, et une API gérée prend en charge la rotation et le rendu qu'aucun des frameworks open-source ne résout directement.
Crawler de manière responsable
Quelle que soit la technique ou le framework que vous utilisez, crawlez avec retenue. Respectez les conditions de service de chaque site et son fichier robots.txt, concentrez-vous sur les données accessibles au public plutôt que sur quoi que ce soit derrière un login auquel vous n'êtes pas autorisé, et maintenez des taux de requêtes raisonnables pour ne pas solliciter les serveurs dont vous dépendez. Identifiez votre robot honnêtement via son agent utilisateur et fournissez un moyen de vous contacter. Un rythme responsable est aussi dans votre intérêt : un trafic doux et bien élevé est bloqué bien moins souvent qu'un crawl agressif, les bonnes manières et un crawling fiable tendent donc dans la même direction.
Points clés
- L'ordre de traversée importe. La largeur d'abord donne une couverture régulière et délimitée et est le défaut habituel ; la profondeur d'abord plonge dans une branche, et beaucoup de robots priorisent la frontière par un score à la place.
- La frontière et la déduplication sont le coeur. Une file d'attente d'URLs bien gérée plus la normalisation des URLs et un ensemble vu (souvent un filtre de Bloom à grande échelle) empêchent un crawl de boucler ou de re-télécharger des pages.
- La politesse vous maintient non bloqué. Les limites de débit par hôte, la concurrence limitée et le respect de robots.txt protègent les sites que vous crawlez et la fiabilité de votre propre crawl.
- JavaScript et l'échelle ajoutent du coût. Ne rendez que les pages qui nécessitent un navigateur, et distribuez sur des workers tout en acheminant chaque hôte via un seul budget de débit pour rester poli.
- Les frameworks regroupent la machinerie. Scrapy convient à la plupart des crawls personnalisés, Nutch et StormCrawler gèrent les jobs à l'échelle du web et continus, Heritrix archive, et une API gérée absorbe la rotation et le rendu.
Foire aux questions
Quelle est la différence entre le crawling web et le scraping web ?
Le crawling est l'étape de découverte et de traversée : partir des URLs de départ, suivre des liens et récupérer des pages pour en trouver d'autres. Le scraping est l'étape d'extraction : extraire des champs spécifiques du balisage une fois qu'on a une page. La plupart des projets font les deux, crawlant pour atteindre les pages et scrapant pour en extraire des données, mais ce sont des étapes distinctes avec des préoccupations différentes.
Un robot doit-il utiliser une traversée en largeur d'abord ou en profondeur d'abord ?
La largeur d'abord est le défaut courant pour les crawls généraux car elle donne une couverture large et régulière rapidement et est facile à délimiter avec une file FIFO. La profondeur d'abord convient aux cas où vous voulez épuiser complètement une section profonde avant de passer à la suivante. Beaucoup de robots en production n'utilisent ni l'une ni l'autre strictement, priorisant plutôt la frontière par un score comme la popularité des liens, la profondeur ou la fraîcheur pour que les pages les plus utiles soient récupérées en premier.
Qu'est-ce qu'une frontière d'URLs ?
La frontière est la file d'attente des URLs qu'un robot a découvertes mais pas encore visitées. Elle décide quelle URL vient ensuite, applique l'ordre et la priorité, et alimente les récupérateurs. À grande échelle, elle vit généralement dans une base de données ou une file distribuée plutôt qu'en mémoire, car la liste des URLs découvertes croît rapidement. Couplée à la déduplication, c'est ce qui maintient un crawl ordonné et empêche les boucles infinies.
Comment les robots évitent-ils de télécharger deux fois la même page ?
Ils normalisent chaque URL (mise en minuscules de l'hôte, suppression des ports par défaut, abandon des fragments et des paramètres de tracking) et la vérifient contre un ensemble d'URLs déjà vues avant de la mettre en file. Pour les très grands crawls, cet ensemble est souvent une structure efficace en mémoire comme un filtre de Bloom, qui peut répondre à la question de savoir si une URL a été vue en utilisant une petite fraction de la mémoire qu'une liste complète nécessiterait.
Les robots d'indexation web doivent-ils respecter robots.txt ?
Respecter robots.txt est l'attente de base pour un trafic automatisé bien élevé et la marque la plus claire d'un robot responsable. Un bon robot récupère et analyse le fichier avant de crawler un hôte, ignore les chemins non autorisés, respecte tout délai de crawl annoncé et utilise le sitemap qu'il indique. Combiné avec des limites de débit raisonnables et une identification honnête, c'est le coeur du crawling responsable.
Quel framework de crawling web devrais-je utiliser ?
Cela dépend du travail. Scrapy convient à la plupart des crawls personnalisés de milliers à millions de pages. Apache Nutch et StormCrawler ciblent le crawling à l'échelle du web et continu. Heritrix est conçu pour la capture archivistique haute fidélité. Si la partie difficile est de rester non bloqué plutôt que la logique de crawl, une API de crawling gérée gère la rotation, le rendu et les nouvelles tentatives pour que vous puissiez vous concentrer sur la traversée et l'analyse.
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.