2026 Web Crawler Benchmark : De l'indexation à l'agentic Intelligence
Nous avons comparé quatre API d'exploration sur trois domaines de difficulté variable (amazon.com, entrepreneur.com, theregister.com) à trois niveaux de profondeur maximum (5, 10, 20) avec une limite de 1 000 pages, en mesurant la couverture d'exploration, le temps d'exécution, la découverte de liens, la qualité des liens Markdown et la précision de l'extraction des titres.
Si votre objectif est de :
- Transformez les pages web en données structurées, consultez notre guide sur l'extraction de données web .
- Explorez des sites web entiers, poursuivez votre lecture.
Analyse comparative des robots d'exploration Web
Vous pouvez consulter notre méthodologie d'analyse comparative.
Nombre moyen de pages indexées par rapport au coût pour 1 000 pages
Pages explorées sur différents domaines par profondeur maximale
Le robot Firecrawl a exploré de manière constante une centaine de pages sur theregister.com, quelle que soit la profondeur maximale d'exploration, environ 90 pages sur entrepreneur.com à tous les niveaux de profondeur, et seulement une trentaine de pages sur amazon.com, probablement en raison du système de protection anti-robots très strict d'Amazon. Il est à noter que l'augmentation de la profondeur maximale n'a eu pratiquement aucun impact sur le nombre de pages explorées par Firecrawl sur l'ensemble des domaines.
Apify a démontré les performances les plus constantes, atteignant la limite d'exploration maximale de 1 000 pages sur chaque domaine à chaque niveau de profondeur sans aucune difficulté apparente, même sur des sites fortement protégés comme Amazon.
Cloudflare a montré un comportement incohérent d'un test à l'autre :
- Sur theregister.com, à une profondeur maximale de 5, il n'a exploré que 100 pages, mais à une profondeur maximale de 20, il a atteint près de 1 000 pages.
- Comme nous l'avons constaté lors de tests précédents, Cloudflare explore parfois une seule page avant d'interrompre complètement son exploration. Nous avons confirmé qu'il ne s'agit pas d'un problème de cache (le cache était désactivé) et avons effectué des tests avec des temps d'attente entre les exécutions allant jusqu'à une minute, mais le problème persiste. À une profondeur maximale de 10 sur theregister.com, ce problème précis s'est produit : Cloudflare n'a exploré qu'une seule page avant de s'arrêter.
- Sur entrepreneur.com, Cloudflare a exploré 780 pages à une profondeur de 5, puis 885 à une profondeur de 10, avant de chuter brutalement à seulement 172 pages à une profondeur de 20. Cette chute pourrait être liée à une dépriorisation ou à un dépassement de délai des chaînes de liens plus profondes par le planificateur d'exploration de Cloudflare, ou refléter une limite de concurrence interne qui provoque l'arrêt prématuré de la tâche lorsque la zone d'exploration devient trop importante à des profondeurs plus élevées.
- Sur amazon.com, Cloudflare a exploré 905 pages à une profondeur de 5, mais le nombre a diminué régulièrement à mesure que la profondeur maximale augmentait, tombant à 809 à une profondeur de 10 et à 795 à une profondeur de 20, suggérant que des configurations d'exploration plus profondes peuvent amener Cloudflare à passer plus de temps sur la surcharge de découverte des liens plutôt que sur la récupération réelle des pages.
Le script Nimble a atteint ou presque atteint la limite de 1 000 pages sur theregister.com à tous les niveaux de profondeur (1 000 / 1 000 / 999). Sur entrepreneur.com, il a exploré 1 000 pages à la profondeur 5, mais a légèrement diminué aux profondeurs supérieures (896 à la profondeur 10, 983 à la profondeur 20), probablement en raison de l'expiration du délai de 7 heures avant la fin de l'exploration aux niveaux plus profonds. Toutes les exécutions du script Nimble se sont terminées par un dépassement de délai. Amazon s'est avéré plus difficile :
- À la profondeur 5, il n'a atteint que 319 pages, mais à la profondeur 10, il est passé à 988 pages, puis est retombé à 906 à la profondeur 20.
- Cette incohérence reflète probablement la combinaison des mécanismes de protection contre les robots d'Amazon et des contraintes de délai d'expiration de Nimble, les explorations plus approfondies prenant plus de temps pour traiter chaque page et pouvant rencontrer davantage de résistances aux robots.
Temps d'exécution dans les différents domaines en fonction de la profondeur maximale
Le serveur Firecrawl s'est avéré le plus rapide sur l'ensemble des domaines, effectuant ses analyses en moins de 5 minutes, généralement entre 75 et 265 secondes. Cette rapidité a toutefois un coût : la couverture est limitée, car Firecrawl a également analysé le moins de pages. En résumé, sa rapidité est due à sa capacité à s'arrêter prématurément.
L'exécution de Apify a pris environ 2 200 à 2 400 secondes (soit environ 40 minutes) sur theregister.com, quelle que soit la profondeur de recherche. Sur entrepreneur.com et amazon.com, les temps d'exécution étaient nettement plus longs, de 8 300 à 15 900 secondes (2 à 4 heures), reflétant la taille et la complexité accrues de ces sites. Malgré ces temps d'exécution plus longs, Apify a systématiquement atteint la limite de 1 000 pages, ce qui en fait l'outil le plus fiable en termes de couverture par rapport au temps d'exécution.
Cloudflare a affiché un timing qui reflète ses comptages d'exploration incohérents :
- Sur theregister.com, à la profondeur 10, l'opération s'est terminée en seulement 1 seconde, car elle n'a exploré qu'une seule page avant de s'arrêter.
- Sur entrepreneur.com, à une profondeur de 20, l'opération s'est terminée en 10 secondes après avoir exploré seulement 172 pages.
- Lorsque Cloudflare effectue un crawl complet, les temps varient de 3 500 à 25 200 secondes.
- À mesure que la profondeur maximale augmente, Cloudflare semble privilégier l'exploration des pages profondes plutôt que l'exploration en largeur, en explorant moins de pages mais plus rapidement. Sur amazon.com, le temps d'exécution est passé de 25 200 secondes (délai d'attente dépassé) à une profondeur de 5 à seulement 5 660 secondes à une profondeur de 20, tandis que le nombre de pages explorées a également diminué, passant de 905 à 795. Cela suggère que le robot d'exploration de Cloudflare modifie sa stratégie aux profondeurs plus élevées, consacrant moins de temps à la découverte générale et davantage à l'exploration en profondeur.
Le script Nimble a atteint le délai d'expiration de 7 heures (25 200 secondes) à chaque exécution, quel que soit le domaine ou le niveau de profondeur. Ce résultat est notable car, lors de nos tests rapides précédents avec une profondeur maximale de 1, Nimble s'était exécuté sans expiration. Lors du test complet, avec des profondeurs de 5 à 20 et une limite de 1 000 pages, il a fonctionné systématiquement jusqu'à expiration du délai. Malgré cela, Nimble a tout de même réussi à explorer un grand nombre de pages dans la plupart des cas (environ 900 à 1 000 sur theregister.com et entrepreneur.com), ce qui signifie qu'il explore activement les sites web pendant les 7 heures, mais sans jamais signaler la fin de l'exploration.
Taux de remplissage du texte des liens chez les fournisseurs selon la profondeur maximale
Pour évaluer la qualité du rendu Markdown, nous avons mesuré le pourcentage de liens contenant un texte d'ancrage (la partie cliquable) dans le rendu Markdown de chaque fournisseur. L'absence de texte d'ancrage (par exemple, [](/about) au lieu de [About Us](/about)) indique que le robot d'exploration n'a pas pu extraire l'étiquette du lien.
- Nimble : 100 % à toutes les profondeurs
- Cloudflare : 91-94%
- Firecrawl : 90%
- Apify : 77-78 %, soit environ 1 lien sur 5 sans texte d'ancrage
La profondeur d'exploration a eu un impact minimal sur les taux de remplissage pour tous les fournisseurs, ce qui suggère qu'il s'agit d'une caractéristique du moteur d'analyse de chaque fournisseur plutôt que d'un paramètre d'exploration.
Taux de remplissage des liens par domaine chez les différents fournisseurs
L'analyse des taux de remplissage sur différents domaines révèle comment la complexité du site affecte la qualité de l'extraction de liens de chaque fournisseur.
- Nimble maintenu à 100% sur tous les domaines.
- Le lien Apify a présenté la plus grande variation : 89 % sur amazon.com, contre seulement 66 % sur entrepreneur.com, ce qui signifie qu’un tiers de ses liens sur ce site étaient dépourvus de texte d’ancrage. Cela suggère que Apify rencontre davantage de difficultés avec les sites riches en contenu et dotés de structures de navigation complexes.
- Firecrawl a obtenu les meilleurs résultats sur theregister.com (98%), mais est tombé à 81% sur entrepreneur.com, suivant un modèle similaire à celui de Apify.
- Cloudflare était le plus constant après Nimble, restant entre 89 et 94 % quel que soit le domaine.
Entrepreneur.com s'est avéré être le domaine le plus difficile pour l'extraction de texte de lien, Apify (66%) et Firecrawl (81%) y ont obtenu leurs scores les plus bas, probablement en raison de l'utilisation intensive de menus de navigation imbriqués et d'éléments de contenu dynamiques plus difficiles à convertir proprement en markdown.
Nombre total de liens dans le rendu Markdown sur l'ensemble des domaines, par profondeur maximale
Le nombre de liens extraits des mêmes pages varie considérablement d'un fournisseur à l'autre (74 à 97 %), ce qui indique que les fournisseurs extraient un nombre très différent de liens. Afin d'obtenir une vision plus détaillée de cette disparité, nous avons mesuré le nombre total de liens Markdown par fournisseur.
- Apify a généré le plus grand nombre de liens, notamment sur amazon.com avec plus de 420 000 liens à la profondeur 5 (environ 423 par page). Sur entrepreneur.com, ce nombre s'est stabilisé autour de 63 000, quelle que soit la profondeur. Ses résultats incluent les traqueurs publicitaires et les pixels de suivi, en plus des liens présents dans le contenu des pages.
- Cloudflare a atteint un pic de 303K sur entrepreneur.com à une profondeur de 10, mais est tombé à 53K à une profondeur de 20. Sur la même page d'accueil d'entrepreneur.com, Cloudflare a extrait 434 liens contre 143 pour Apify, capturant des menus de navigation et des sous-menus complets.
- Firecrawl a systématiquement renvoyé 5 à 9 000 liens dans toutes les configurations, limité par son faible nombre de pages.
- Le service Nimble a renvoyé entre 3 000 et 40 000 liens au total, soit en moyenne 5 à 28 liens par page, contre 60 à 420 pour d'autres fournisseurs. Sur la page d'accueil d'entrepreneur.com, Nimble a renvoyé 13 liens, contre 434 pour Cloudflare, limités aux titres des articles principaux. Son taux de remplissage de 100 % indique que tous les liens inclus comportaient un texte d'ancrage, et non une couverture exhaustive. Nimble ne génère pas de liens Markdown standard. Son décompte inclut les liens HTML échappés présents dans le code Markdown généré.
Taux actuel des titres chez les fournisseurs
La similarité des titres entre les différents fournisseurs a affiché un écart inférieur à 1 % sur l'ensemble des tests et des domaines, confirmant ainsi que, lorsqu'ils extraient un titre, les fournisseurs renvoient systématiquement le même résultat. Le taux de présence des titres est également resté compris entre 98 et 100 % à tous les niveaux de profondeur d'exploration, démontrant que la profondeur d'exploration n'a pas d'impact significatif sur l'extraction des titres.
Une analyse par domaine a révélé certaines différences :
Sur entrepreneur.com et theregister.com, la plupart des fournisseurs ont atteint des taux de présence des titres de 99 à 100 %. Amazon.com était le seul domaine où des différences significatives sont apparues : le taux de présence des titres pour Firecrawl a chuté à 93 % et celui de Nimble à 95,9 %, tandis que celui de Apify s’est maintenu à 99,6 %. Cela s’explique par le renforcement des mesures de protection contre les robots d’Amazon, qui peuvent bloquer ou altérer les réponses des pages, ce qui peut amener certains fournisseurs à renvoyer des pages sans titres exploitables.
Qu'est-ce qu'un robot d'exploration Web ?
Un robot d'exploration Web, parfois appelé « spider » ou « agent », est un bot qui parcourt Internet pour indexer le contenu.
Les robots d'exploration ne se limitent plus aux moteurs de recherche ; ils constituent désormais la couche de données agentique. Ils servent d'yeux aux agents d'IA autonomes tels que Claude Code et OpenAI Operator, les assistant dans des tâches en temps réel comme la veille concurrentielle et les transactions complexes.
Que fait un robot d'exploration Web ?
L'exploration du Web a été divisée en trois modes, chacun conçu pour un objectif d'exploration différent.
- Mode de découverte (traditionnel) : Les robots des moteurs de recherche comme Googlebot explorent les URL pour les indexer, aidant ainsi les utilisateurs à trouver des résultats via les moteurs de recherche.
- Mode de récupération (RAG) : les bots IA comme ChatGPT-User ou PerplexityBot récupèrent des pages spécifiques en temps réel pour répondre aux requêtes des utilisateurs. Ils utilisent le Markdown au lieu du HTML afin de respecter les limites de jetons du modèle d’IA.
- Mode agentique (orienté vers l'action) : Ce nouveau type de robot d'exploration, prévu pour 2026, ne se contente pas de lire du contenu. Grâce au protocole MCP (Model Context Protocol), ces robots peuvent interagir avec les sites web pour réserver des vols ou exécuter des commandes logicielles.
Auparavant, les robots d'exploration utilisaient des sélecteurs tels que XPath ou CSS pour extraire des données. L'extraction native par IA est désormais la norme.
Des outils comme Firecrawl et Crawl4AI utilisent des instructions en langage naturel pour extraire des données. Au lieu de définir des règles pour chaque élément, les développeurs peuvent demander au robot d'exploration d'« extraire le prix du produit », et l'IA trouvera la valeur correcte même si le code du site web est modifié.
Développer ou acheter des robots d'exploration Web à l'ère de l'IA
1. Construire son propre robot chenillé
Idéal pour protéger la propriété intellectuelle essentielle et permettre une personnalisation poussée. Le développement nécessite désormais la création d'une couche d'agent propriétaire, et non plus seulement l'écriture de scripts Scrapy basiques.
- Quand développer votre propre robot d'exploration : Choisissez cette approche si votre robot vous confère un avantage concurrentiel unique. Par exemple, développez le vôtre si vous créez un moteur de recherche spécialisé ou si vous avez besoin d'un contrôle total sur des données sensibles ou réglementées.
- L'ensemble d'outils : vous n'avez plus besoin de repartir de zéro. Les développeurs exploitent désormais le protocole MCP (Model Context Protocol) pour permettre aux agents d'IA internes d'interagir avec le Web.
2. Utilisation des outils et API d'exploration du Web
Les outils gérés ont évolué, passant de simples aspirateurs de sites web à des agents autonomes.
- Extraction sans maintenance : des outils modernes comme Kadoa et Firecrawl utilisent une IA auto-réparatrice. Vous spécifiez les données requises, telles que le « Prix du produit », plutôt que leur emplacement dans le code. Si la mise en page du site web change, l’outil s’adapte automatiquement.
- Conformité en tant que service : De nombreux fournisseurs proposent une conformité intégrée à la loi européenne sur l’IA. Ils gèrent les journaux d’audit obligatoires et les vérifications de retrait du droit d’auteur, des opérations difficiles à mettre en œuvre de manière indépendante.
- Rapidité de mise en œuvre : L'achat d'une plateforme peut permettre de passer de la conception à la production de votre projet en quelques semaines.
Figure 5 : Explication du fonctionnement d'une frontière d'URL.
Les robots d'exploration du Web sont-ils légaux ?
En général, l'exploration du Web est légale , mais selon la manière dont vous l'explorez et les données que vous explorez, vous pourriez rapidement vous retrouver dans une situation juridique délicate. Quatre grands critères déterminent la légalité de l'exploration (et du web scraping qui en découle généralement) :
1. Public vs. privé : Ne collecter que les données accessibles au public sans compte.
2. Informations personnelles : Évitez de divulguer des informations personnelles identifiables (noms, adresses électroniques et adresses postales) sauf si vous avez une base légale.
3. Santé du serveur : utilisez des limites de débit pour éviter de ralentir le serveur ; évitez de lancer une attaque DDoS contre un site web.
4. Droits d'auteur : Les articles et les images sont protégés par le droit d'auteur, mais les faits (prix, dates) ne le sont pas.
Quelle est la différence entre le web crawling et le web scraping ?
Le web scraping consiste à utiliser des robots d'exploration web pour analyser et stocker l'intégralité du contenu d'une page web cible. Autrement dit, le web scraping est un cas d'utilisation spécifique de l'exploration web permettant de créer un ensemble de données ciblé, par exemple en extrayant toutes les actualités financières à des fins d'analyse d'investissement ou en recherchant des noms d'entreprises spécifiques.
Traditionnellement, une fois qu'un robot d'exploration avait parcouru et indexé tous les éléments d'une page web, un extracteur de données web en extrayait les données. Cependant, de nos jours, les termes « extraction de données » et « exploration » sont souvent utilisés indifféremment, le terme « robot d'exploration » désignant généralement les robots des moteurs de recherche. Avec l'essor des entreprises autres que les moteurs de recherche dans l'utilisation des données web, le terme « extracteur de données web » a progressivement remplacé celui de « robot d'exploration ».
Quels sont les défis du web crawling ?
1. Fraîcheur de la base de données
Le contenu des sites web est régulièrement mis à jour. Les pages web dynamiques, par exemple, modifient leur contenu en fonction des activités et des comportements des visiteurs. Cela signifie que le code source du site web n'est plus inchangé après son exploration. Afin de fournir à l'utilisateur les informations les plus récentes, le robot d'exploration doit explorer ces pages web plus fréquemment.
2. Pièges à chenilles
Les sites web utilisent différentes techniques, comme les pièges à robots d'exploration, pour empêcher les robots d'accéder à certaines pages et de les explorer. Un piège à robot d'exploration, ou piège à araignées, oblige un robot à effectuer un nombre infini de requêtes et à s'enfermer dans un cercle vicieux d'exploration. Les sites web peuvent également créer ces pièges involontairement. Dans tous les cas, lorsqu'un robot d'exploration rencontre un piège, il entre dans une sorte de boucle infinie qui gaspille ses ressources.
3. Bande passante du réseau
Le téléchargement d'un grand nombre de pages Web non pertinentes, l'utilisation d'un robot d'exploration Web distribué ou le réexploration de nombreuses pages Web entraînent tous un taux élevé de consommation de capacité réseau.
4. Pages en double
Les robots d'exploration du Web parcourent la plupart des contenus dupliqués présents sur le web ; cependant, une seule version d'une page est indexée. La présence de contenus dupliqués complique la tâche des robots des moteurs de recherche, qui doivent déterminer quelle version indexer et classer. Lorsque le robot Google détecte un groupe de pages Web identiques dans les résultats de recherche, il n'en indexe et n'en sélectionne qu'une seule pour répondre à la requête de l'utilisateur.
Les 3 meilleures pratiques d'exploration du Web
1. Politesse/Vitesse de déplacement
Les sites web définissent une fréquence d'exploration afin de limiter le nombre de requêtes effectuées par les robots d'exploration. Cette fréquence indique le nombre de requêtes qu'un robot d'exploration peut effectuer sur votre site web pendant un intervalle de temps donné (par exemple, 100 requêtes par heure). Elle permet aux propriétaires de sites web de préserver la bande passante de leurs serveurs et de réduire leur surcharge. Un robot d'exploration doit respecter la limite d'exploration du site web cible.
2. Conformité au fichier robots.txt
Un fichier robots.txt est un fichier texte placé à la racine d'un site web qui indique aux robots d'exploration les pages auxquelles ils sont autorisés ou non à accéder. Il s'agit d'une norme volontaire : les robots compatibles la respectent, mais elle n'empêche pas techniquement l'accès aux pages. Respecter le fichier robots.txt d'un site web est considéré comme une bonne pratique, et dans de nombreuses juridictions, l'ignorer peut vous exposer à des risques juridiques ou à une atteinte à votre réputation.
3. Rotation IP
Les sites web utilisent différentes techniques anti-extraction de données, comme les CAPTCHA, pour gérer le trafic des robots d'exploration et limiter les activités d'extraction de données. Par exemple, l'empreinte numérique du navigateur est une technique de suivi utilisée par les sites web pour recueillir des informations sur les visiteurs, telles que la durée de leur session ou le nombre de pages consultées.
Cette méthode permet aux propriétaires de sites web de détecter le trafic non humain et de bloquer l'adresse IP du robot. Pour éviter d'être détecté, vous pouvez intégrer des proxys rotatifs , tels que des proxys résidentiels , à votre robot d'exploration web.
méthodologie d'analyse comparative des robots d'exploration Web
Nous avons testé quatre API de crawl (Apify, Nimble, Cloudflare, Firecrawl) sur trois domaines de difficulté variable : amazon.com (protection renforcée contre les robots), entrepreneur.com (site au contenu complexe) et theregister.com (site d'actualités).
Configuration partagée
Tous les fournisseurs ont reçu des paramètres de base identiques afin de garantir une comparaison équitable :
- Plan du site : désactivé, les fournisseurs doivent uniquement accéder aux pages via des liens HTML.
- Liens externes : désactivés, les robots d’exploration restent au sein du domaine cible.
- Sous-domaines : activés, les pages de sous-domaines sont suivies (ex. : india.entrepreneur.com)
- Rendu JavaScript : activé, tous les fournisseurs utilisent un navigateur sans interface graphique
- Cache : désactivé
- Limite de pages : 1 000 pages par exécution
- Délai d'expiration : 7 heures (25 200 secondes)
- Gestion des limitations de débit : attente de 20 secondes avec jusqu’à 3 tentatives en cas d’erreur HTTP 429
Chaque fournisseur a été testé à trois niveaux de profondeur maximum (5, 10 et 20) sur les trois domaines, pour un total de 36 explorations. Les fournisseurs ont été testés séquentiellement (et non en parallèle), chaque combinaison a été exécutée une seule fois, et l'état de l'exploration a été interrogé toutes les secondes.
Le processus Apify était configuré avec l'acteur website-content-crawler utilisant Playwright/Firefox comme navigateur sans interface graphique. L'accès aux sous-domaines était contrôlé par des modèles glob, et le proxy intégré de Apify était utilisé pour toutes les requêtes.
Les éléments Nimble, Cloudflare et Firecrawl ont été configurés à l'aide de leurs API REST respectives, avec les paramètres communs décrits ci-dessus. Aucune configuration supplémentaire spécifique au fournisseur n'a été appliquée au-delà des paramètres standardisés.
Pour Cloudflare, nous avons utilisé le forfait « Travailleurs payés ». Le coût indiqué correspond aux dépenses engagées pour l'exploration de 1 000 pages avec ce forfait. La facturation de Cloudflare est basée sur le temps de rendu du navigateur et non sur le nombre de pages.
Pour Firecrawl, nous avons utilisé le forfait Loisirs. Le coût indiqué correspond au montant au prorata pour 1 000 crédits inclus dans ce forfait. Le coût effectif par page varie selon le niveau du forfait et l’achat ou non de packs de crédits supplémentaires.
À lire ensuite
Les 5 meilleures extensions Chrome gratuites pour le web scraping
Comparatif des navigateurs Web IA : Guide de sélection complet 2026
Le web scraping est-il légal ? Lois et bonnes pratiques de 2026
Les 5 meilleurs outils d'extraction de données Web Indeed
Extraction de données de Craigslist : Les meilleurs outils d'extraction de données de Craigslist
Analyse comparative des 5 meilleurs outils d'extraction de données web pour Walmart
Commentaires 1
Partagez vos idées
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.
Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.