Scraper e-commerce: 4 fournisseurs benchmarkés

Nous avons benchmarké quatre fournisseurs de données web sur 100 domaines e-commerce, en récupérant 65 000 pages produit et de recherche chacun à des niveaux de 5 à 5 000 requêtes simultanées.

Temps de réponse et taux de réussite

En moyenne sur l’ensemble des niveaux de simultanéité, Bright Data a atteint le taux de réussite le plus élevé (76 %) avec une médiane de 16 secondes. Apify a enregistré le temps de réponse médian le plus élevé avec 46 secondes.

Le temps de réponse est indiqué comme la médiane (P50), la requête type, et la queue (P90), soit les 10 % de requêtes les plus lentes.

Les taux de réussite sont calculés en moyenne sur les niveaux de simultanéité de 5 et 100, car seuls Bright Data et Nimble ont terminé une exécution complète à 5 000.

Consultez notre méthodologie du benchmark e-commerce pour savoir comment nous avons testé.

Taux de réussite du scraper e-commerce par niveau de simultanéité

Bright Data a enregistré le taux de réussite global le plus élevé. À 5 000 requêtes parallèles, Bright Data a maintenu 71 % et Nimble 56 %.

La simultanéité correspond au nombre de requêtes envoyées en même temps. Le niveau de 5 000 requêtes met à l’épreuve les limites de débit et l’infrastructure d’un fournisseur.

Taux de réussite sur les pages produit et de recherche

Tous les fournisseurs ont obtenu de meilleurs résultats sur les pages produit (fiche) que sur les pages de recherche (liste).

• Pages de recherche (liste) renvoient de nombreux articles pour une requête ou une catégorie, souvent paginées et rendues dynamiquement, ce qui rend une extraction cohérente plus difficile.
• Pages produit (fiche) affichent un seul article avec des champs structurés tels que le titre, le prix, le SKU et les images.

Taux de réussite par fournisseur anti-bot

Nous avons identifié le fournisseur anti-bot pour chacun des 100 domaines, puis nous avons regroupé la même mesure de succès vérifiée par contenu par fournisseur. Akamai couvre 42 domaines, Cloudflare 16, AWS WAF 10, HUMAN 8 et DataDome 6, et 18 domaines utilisent des fournisseurs trop petits pour être représentés.

L’écart le plus large se situe sur DataDome, qui défend 6 des domaines. Bright Data y a obtenu 92.5 %, contre 46.0 % à 75.3 % pour les trois autres fournisseurs.

Sur Akamai, le plus grand groupe avec 42 domaines, les quatre fournisseurs se situent entre 65.7 % et 70.4 %, avec des intervalles qui se chevauchent.

Analyse des scrapers e-commerce

Bright Data fournit une API Web Scraper associée à une interface sans code, ainsi qu’un scraper e-commerce dédié et plus de 1 000 scrapers prêts à l’emploi couvrant des places de marché comme Amazon, eBay, AliExpress, Walmart et Target. La combinaison de l’accès à l’API et d’un panneau de contrôle sans code le rend utilisable aussi bien par les équipes techniques que non techniques. Dans notre benchmark, Bright Data a enregistré le taux de réussite global le plus élevé et a été l’un des rares fournisseurs à maintenir son taux sous une forte charge simultanée.

Performance :

• Taux de réussite global le plus élevé : 76 % sur 100 domaines.
• A maintenu son taux sous charge : l’un des deux fournisseurs à maintenir un succès à 5 000 requêtes simultanées (71 %).

Zyte API est une API de web scraping qui combine gestion des blocages, rendu sans tête et capacités d’extraction par IA pour structurer le HTML brut en données typées, telles que les noms de produits, les prix et les évaluations, à partir de pages produit de détaillants. Elle est accessible via REST et s’intègre au framework open source Scrapy, maintenu par Zyte, ainsi qu’à l’hébergement Scrapy Cloud. Dans notre benchmark, elle a enregistré le deuxième taux de réussite global le plus élevé et est restée régulière sur les grandes places de marché et sous une simultanéité élevée.

Performance :

• Deuxième taux de réussite global le plus élevé : 72 % sur 100 domaines.
• Régulier sur les grandes places de marché : Amazon 95 %, Walmart 97 %, Target 96 %, eBay 98 %.
• Écart produit-recherche le plus faible : 74 % sur les pages produit et 70 % sur les pages de recherche, l’écart le plus étroit entre les deux de tous les fournisseurs.

La place de marché d’Apify héberge des milliers d’Actors créés par Apify et sa communauté, destinés aux développeurs comme aux agents.

Dans le cadre de notre benchmark, nous avons utilisé son E-commerce Scraping Tool, un Actor universel unique qui extrait les données produit et prix, les détails de catégorie, les avis et les informations sur les vendeurs à partir de plateformes de vente au détail et de places de marché comme Amazon, Walmart et eBay, à partir d’une URL produit, d’une URL catégorie ou d’une recherche par mot-clé.

Performance :

• Succès à charge standard : 70 % au global, 96 % sur Amazon et 92 % sur Best Buy.
• Flexibilité : accepte une URL produit, une URL catégorie ou une recherche par mot-clé et exporte en JSON, CSV, Excel, XML ou HTML.
• Temps de réponse et charge : temps de réponse médian de 46 secondes.

Nimble propose une API de web scraping à usage général ainsi qu’une API e-commerce dédiée qui renvoie du JSON structuré par IA et NLP et prend en charge les grandes places de marché, notamment Amazon, Walmart et Google Shopping. L’API inclut des proxies résidentiels intégrés et un géociblage jusqu’au niveau du pays, de l’État, de la ville et du code postal. Dans notre benchmark, Nimble a maintenu son taux de réussite sous forte charge simultanée mieux que tous les fournisseurs à l’exception de Bright Data.

Performance :

• Deuxième plus résilient sous charge : a maintenu 56 % de succès à 5 000 requêtes simultanées, derrière Bright Data.
• Rapide : un temps de réponse médian d’environ 9 secondes.
• Force spécifique à un domaine : 100 % sur AliExpress, 90 % sur Best Buy et 25 % sur Amazon.

Couverture des scrapers dédiés par fournisseur

Les fournisseurs diffèrent dans leur manière d’extraire les données. Certains livrent un scraper dédié préconstruit pour chaque place de marché qui renvoie les champs structurés du site ; d’autres appliquent un moteur universel à n’importe quel site. Bright Data a offert la couverture dédiée la plus large sur les 100 domaines. Zyte et Apify utilisent un seul moteur d’extraction universel plutôt qu’une bibliothèque par place de marché.

Pour chaque fournisseur, la colonne des champs de métadonnées compte les attributs de données distincts dans un enregistrement produit JSON analysé, tels que le prix, la marque, l’évaluation, le SKU ou l’image. La valeur est la moyenne sur les pages produit ayant renvoyé un enregistrement produit analysé, et elle exclut les en-têtes HTTP, les métadonnées de requête et tout champ contenant le HTML brut de la page.

Les scrapers dédiés de Bright Data renvoient les données des pages produit. La couverture reflète le catalogue de chaque fournisseur au moment du benchmark.

Tarification des scrapers e-commerce

*La tarification de Bright Data se fait par enregistrement (un article extrait, par exemple un produit ou un avis), et non par requête. Sur les pages de recherche, une seule requête peut renvoyer plusieurs enregistrements.

Dans notre benchmark, le renvoi de 1 000 pages produit avec le contenu attendu a coûté $1.30 chez Nimble, $1.52 chez Bright Data, $3.32 chez Zyte et $7.50 chez Apify. Les requêtes échouées comptent dans les dépenses mais pas dans le total de pages ; il s’agit donc de tarifs effectifs plutôt que de prix catalogue.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Méthodologie du benchmark e-commerce

Sélection des domaines

Nous avons sélectionné les 15 premiers pays par PIB et exclu la Russie et la Chine. Pour chaque pays, nous avons pris les 5 principaux domaines de la catégorie e-commerce de SimilarWeb sur les trois derniers mois. Nous avons ajouté les 5 principaux sites mondiaux en électronique grand public et en épicerie. Pour les États-Unis, classés premiers, nous avons également pris les 20 premiers domaines de la catégorie retail de Semrush, car les listes publiques de Semrush affichent 20 sites là où SimilarWeb en affiche 5.

Nous avons ensuite inclus le top 20 mondial de la catégorie retail et le top 20 de la catégorie habillement/mode pour janvier 2026. Nous avons exclu les domaines desservant des pays hors de l’ensemble sélectionné, les sites exigeant une authentification pour naviguer et les sites exigeant une sélection de pays sur la page d’atterrissage avant de naviguer. Nous avons exclu les chemins régionaux des domaines mondiaux (par exemple, etsy.com/fr) mais conservé les sites régionaux disposant d’un domaine distinct. Lorsqu’une exclusion laissait un vide dans le top 5 d’un pays, nous l’avons comblé à partir du top 20 e-commerce de Semrush pour ce pays. Pour atteindre 100 domaines, nous avons ajouté 10 sélections provenant des principales places de marché e-commerce.

Deux domaines mono-marque, apple.com et consumer.huawei.com, ont renvoyé quelques centaines de produits distincts même après avoir parcouru toutes les catégories, en dessous de l’objectif par domaine. Nous les avons remplacés par deux domaines à fort trafic selon SimilarWeb, bol.com et argos.co.uk.

Collecte des URL

Pour chaque domaine, nous avons collecté à la fois des URL produit et des URL de listing, en conservant suffisamment d’URL de réserve pour que chaque exécution et test de charge utilise un ensemble frais. Nous avons découvert chaque URL sans récupérer la page cible par l’intermédiaire d’un fournisseur benchmarké, afin que ces pages restent non utilisées avant le benchmark lui-même.

Pour les URL produit, nous avons utilisé trois sources en séquence, en nous arrêtant lorsqu’un domaine atteignait son objectif :

• Le sitemap produit du site lui-même.
• Un crawl des pages de catégorie du site (de la page d’accueil jusqu’aux pages de catégorie et de sous-catégorie) lorsque le sitemap était manquant ou trop petit, en collectant les liens produit tout en récupérant les pages de catégorie mais jamais la page produit.
• Recherche Google limitée au site lorsqu’un domaine était encore insuffisant.

Chaque URL a été comparée à un motif produit propre au domaine pour écarter les pages non produit, et tout domaine encore en dessous de l’objectif a été signalé pour examen manuel ou remplacé par une solution de secours.

Pour les URL de recherche, nous avons généré des requêtes à partir du catalogue propre de chaque domaine plutôt qu’à partir d’une liste de mots externe. Les mots-clés provenaient des noms de catégories et des slugs de produits du site, donc ils sont dans la langue du site lui-même (un site japonais ou coréen est interrogé dans sa propre langue, sans étape de traduction distincte), et ont été optionnellement généralisés en termes de catégorie simples tels que « running shoes ». Nous avons exécuté les requêtes sur le point de terminaison de recherche du site, ou sur ses pages de catégorie lorsqu’aucune recherche par mot-clé n’existait, et avons conservé les requêtes qui renvoyaient plusieurs produits distincts. Toutes les URL ont ensuite été normalisées à une locale par domaine, débarrassées des paramètres de suivi et dédupliquées.

Validation des URL

Comme le benchmark récupère chaque URL avec chaque fournisseur, valider l’ensemble complet consommerait les URL non utilisées ; nous avons donc validé un échantillon d’environ une douzaine de pages de chaque type par domaine, soit environ 2 500 URL. Nous avons confirmé que les pages produit étaient en ligne et affichaient un prix, et que les pages de listing étaient en ligne et renvoyaient plusieurs produits distincts plutôt qu’une page vide ou un seul produit. Nous avons supprimé les sous-domaines de staging et de QA ainsi que les locales mixtes, et exclu chaque URL échantillonnée de l’ensemble livré.

Exécution du benchmark

Chaque fournisseur a récupéré les mêmes URL fraîches, avec un nombre égal de pages tirées de chaque domaine à chaque exécution. Lorsqu’un fournisseur proposait un scraper e-commerce dédié pour un domaine, nous l’avons utilisé ; sinon, nous avons utilisé le débloqueur web général du fournisseur. Tous les fournisseurs ont été exécutés depuis le même emplacement de serveur, de sorte que l’emplacement n’a avantagé aucun fournisseur.

Pour mesurer le comportement sous charge plutôt que le comportement optimal, nous avons exécuté l’ensemble complet à trois niveaux de simultanéité de 5, 100 et 5 000 requêtes parallèles. Un statut HTTP 200 ne comptait pas à lui seul comme un succès. Pour chaque URL, nous avons défini les données attendues à l’avance, puis vérifié la page renvoyée par rapport à celles-ci : une réponse ne comptait comme un succès que lorsque son contenu correspondait à cette vérité terrain via un sélecteur CSS ou un champ structuré (JSON) portant les données cibles (un prix et des champs produit sur une page produit, plusieurs produits distincts sur une page listing).

Une page de blocage, un captcha ou une coquille vide obtenait zéro même avec un statut 200. Chaque graphique de cet article utilise ce taux de réussite vérifié par le contenu. Nous avons journalisé le statut HTTP et le temps de réponse de bout en bout en parallèle, et rapportons le temps de réponse comme la médiane (P50) et la queue (P90) des requêtes réussies.

Seuls Bright Data et Nimble ont soutenu une exécution complète au niveau de 5 000 requêtes ; les deux autres fournisseurs étaient limités par la simultanéité au niveau du compte ou par des plafonds de crédit à cette charge, et non par leur capacité de scraping, ils ne sont donc pas présentés à cette simultanéité.

Détection anti-bot

Nous avons étiqueté chacun des 100 domaines séparément de l’exécution du benchmark, en envoyant deux requêtes aux mêmes URL produit et de recherche que celles utilisées par le benchmark, car les défenses anti-bot sont généralement armées sur ces chemins plutôt que sur une page d’accueil. Un simple client en ligne de commande, que 70 des 100 domaines bloquaient, obtient une page de blocage qui nomme son fournisseur. Les 30 autres sont identifiables à partir des cookies et des scripts de défense que transporte une réponse normale de type navigateur. Les domaines qui refusaient toute requête directe depuis notre emplacement ont été récupérés via un proxy.

Nous avons hiérarchisé les preuves plutôt que de traiter chaque signal comme équivalent. Un cookie ou un en-tête unique à un produit anti-bot, comme _abck d’Akamai ou datadome de DataDome, compte comme une pile armée, et une page de défi nommant son fournisseur compte de la même manière. Une page de refus générique établit l’entreprise, mais pas le produit, et les en-têtes de couche de livraison seuls ne constituent pas une revendication anti-bot. Nous avons vérifié les marqueurs ambigus par rapport à la documentation du fournisseur et aux déclarations de cookies du site, puis avons exécuté une passe qui tentait de réfuter chaque attribution. Elle en a corrigé plusieurs, notamment les cookies __uzm sur eBay, qui appartiennent à Radware plutôt qu’à Imperva.

Le scraping e-commerce est-il légal ?

Il est légal de collecter des informations publiques telles que les noms de produits, les prix et l’état des stocks, tant que vous ne contournez pas les identifiants ou n’accédez pas à des données privées.

Cependant, de nouvelles règles d’IA s’appliqueront à certaines plateformes. Par exemple, à partir de 2026, eBay a modifié son contrat d’utilisation pour interdire aux « LLM-driven bots » et aux « buy-for-me agents » d’utiliser sa plateforme sans autorisation écrite. Cette mise à jour répond à l’essor de l’« agentic commerce ». ¹

Bien que le scraping général reste légal, l’utilisation d’agents IA pour interagir avec les places de marché est désormais soumise à des règles plus strictes.

FAQ

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dogan2026,
  author = {Dogan, Sedat and Sarı, Ekrem},
  title  = {{Scraper e-commerce: 4 fournisseurs benchmarkés}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/ecommerce-scraper}},
  note   = {AIMultiple. Consulté le 14 Août 2026}
}

Liens de référence

1.

Security Measure | eBay

Sedat Dogan

CTO

Suivre

Sedat est un expert en technologies et sécurité de l'information, fort d'une expérience en développement logiciel, collecte de données web et cybersécurité. Sedat : - Possède 20 ans d'expérience en tant que hacker éthique et expert en développement, avec une vaste expertise des langages de programmation et des architectures serveur. - Conseille les dirigeants et membres du conseil d'administration d'entreprises dont les opérations technologiques critiques et à fort trafic sont telles que les infrastructures de paiement. - Allie un sens aigu des affaires à son expertise technique.

Voir le profil complet

Examiné techniquement par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et analyste de données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire