Tous les guides « Scrapy vs. Selenium » sur Internet répètent toujours la même rengaine : Scrapy va plus vite, Selenium gère JavaScript, à vous de choisir votre poison. L’idée de base n’est pas fausse, mais les affirmations généralisées du genre « tant de pages par minute » ne tiennent pas vraiment la route. Le débit dépend de la cible, du réseau, de la concurrence, du cycle de vie du navigateur, des temps d’attente et des mécanismes anti-bot.
Ce guide compare les architectures et les compromis opérationnels qui restent valables d’un projet à l’autre. Il couvre aussi ce que la plupart des comparatifs laissent de côté : comment l’automatisation navigateur change le modèle de consommation des ressources, pourquoi le rendu sélectif est souvent plus efficace qu’un crawl entièrement basé sur navigateur, et dans quels cas une API d’extraction managée est plus adaptée que l’un ou l’autre framework.
Verdict rapide : Scrapy vs. Selenium en 2026
Pour aller droit au but : Scrapy l’emporte sur la vitesse, l’échelle et l’efficacité des ressources pour tout contenu rendu côté serveur. Selenium prend l’avantage quand il faut un vrai navigateur qui fait de vraies actions de navigateur — cliquer, saisir du texte, attendre qu’une fenêtre modale s’anime. Aucun des deux n’est vraiment prêt d’emblée face aux défenses anti-bot modernes, et Playwright a discrètement récupéré la plupart des cas d’usage pour lesquels on se tournait autrefois vers Selenium.
Voici la matrice de décision que j’utilise vraiment :
| Votre situation | À privilégier |
|---|---|
| Pages statiques ou rendues côté serveur, gros volume | Scrapy |
| SPA très JavaScript avec connexion, clics, parcours en plusieurs étapes | Selenium ou Playwright |
| Site mixte — surtout statique, avec quelques sections uniquement en JS | Architecture hybride Scrapy-Playwright |
| URL connues, besoin de données structurées, maintenance minimale | API d’extraction IA (Thunderbit et équivalents) |
À la mi-2026, Scrapy 2.17.0 est disponible, Selenium 4 continue d’étendre la prise en charge de WebDriver BiDi, et scrapy-playwright propose une solution maintenue pour faire passer certaines requêtes Scrapy par un navigateur. Gardez cette matrice en tête — la suite de l’article explique pourquoi elle fonctionne.
Que sont Scrapy et Selenium, et pourquoi les développeurs en débattent encore
Comparer Scrapy à Selenium, c’est un peu comme comparer un camion de livraison à une voiture. Les deux transportent quelque chose d’un point A à un point B, mais l’un a été pensé pour acheminer de gros volumes efficacement, tandis que l’autre a été conçu pour être conduit par quelqu’un qui doit interagir avec la route. Le débat continue parce que les deux outils peuvent faire du scraping — ils ont simplement été créés pour des usages différents, et beaucoup d’équipes choisissent le mauvais avant de s’en rendre compte.
Scrapy : le moteur de crawl asynchrone
Scrapy est un framework Python basé sur le modèle événementiel non bloquant de Twisted. Ce n’est pas un navigateur — et ça ne l’a jamais été — il envoie simplement des requêtes HTTP et analyse le HTML reçu en retour. C’est le principe même. Comme il n’a jamais à attendre qu’un navigateur rende une page, il peut lancer des dizaines de requêtes en parallèle sans bloquer.
Par défaut, Scrapy inclut des spiders, des pipelines d’items, des exportateurs de flux, une logique de retry et de limitation de débit. Ce n’est pas un framework du genre « il faudra tout construire soi-même » — une bonne partie des besoins de production est déjà prise en charge. La documentation d’architecture de Scrapy présente le moteur, le scheduler, le downloader et le pipeline d’items comme des composants séparés et interchangeables, ce qui explique exactement pourquoi le framework vieillit si bien : on peut le faire évoluer sans réécrire le cœur.
Le revers : sans navigateur, pas d’exécution JavaScript. Si vos données sont chargées via un appel fetch côté client après le rendu de la page, Scrapy ne verra rien. Il lit simplement la réponse HTML initiale, point.
Selenium : le navigateur programmable
Selenium pilote de vrais navigateurs — Chrome, Firefox, Edge — via le protocole W3C WebDriver, la spécification standard qui rend Selenium indépendant du langage et du navigateur, au lieu d’être un simple bricolage limité à Chrome. Il rend JavaScript, exécute des appels AJAX, et peut cliquer, faire défiler et saisir du texte exactement comme un humain.
Cela en fait le bon choix pour tout ce qui repose sur l’interaction : connexions en plusieurs étapes, assistants de saisie, scroll infini, menus déroulants qui déclenchent des appels API. Mais chaque session de navigateur est lourde. Les recommandations de dimensionnement de Selenium Grid suggèrent de prévoir environ 1 Go de RAM par session navigateur uniquement pour la planification — et cela avant même de parler de la charge CPU liée au rendu réel des pages.
Un piège qui fait trébucher beaucoup de monde : le chargement de la page ne veut pas dire que l’interface est prête. La documentation de Selenium déconseille même de mélanger attentes implicites et explicites, car les délais deviennent vite imprévisibles. Si votre script Selenium est instable, c’est souvent là que ça coince.
Scrapy vs. Selenium : des performances sans faux chiffres universels
Un benchmark digne de confiance doit publier les pages cibles, l’état du cache, les conditions réseau, la concurrence, la stratégie de réutilisation du navigateur, les conditions d’attente et l’intégralité du code. Sans ce contexte, un chiffre de pages par minute relève du marketing, pas d’une preuve. La comparaison architecturale reste néanmoins utile :
| Caractéristique de charge | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML rendu côté serveur | Chemin HTTP direct | Chemin navigateur complet | Utilise le chemin direct de Scrapy |
| Contenu rendu en JavaScript | Nécessite un moteur de rendu supplémentaire | Exécution native dans le navigateur | Rendu navigateur sélectif |
| Modèle de concurrence | Planificateur asynchrone de requêtes | Sessions navigateur gérées par votre code ou par Grid | Planificateur Scrapy + contextes navigateur |
| Profil de ressources | Sans surcharge de rendu navigateur | Surcharge CPU et mémoire du navigateur | Coût navigateur uniquement pour les requêtes ciblées |
| Meilleure mesure | Éléments par minute à un taux d’erreur sûr | Parcours terminés par minute à un taux d’erreur sûr | Débit séparé pour requêtes statiques et rendues |
Le réglage de concurrence par défaut de Scrapy constitue une limite haute, pas un chiffre de débit garanti. La vitesse réelle dépend de la latence, des limites par domaine, du throttling, des retries, de la taille des réponses, du travail d’analyse et du rythme acceptable pour le site cible. Selenium peut réutiliser une session navigateur, donc il n’est pas limité par nature à un nouveau navigateur par page, mais chaque session active exécute et rend quand même un environnement de navigateur.
Le modèle hybride est séduisant parce qu’il garde les requêtes ordinaires sur le chemin HTTP de Scrapy et n’envoie dans le navigateur que les pages qui ont besoin d’un rendu. Cela réduit souvent le travail navigateur, mais ce n’est pas automatiquement plus rapide : mesurez séparément les chemins statiques et rendus, incluez les taux d’échec et de retry, et ajustez la concurrence à la fois pour la sécurité du site cible et pour la mémoire disponible.
Différences fondamentales qui orientent votre choix
La vitesse n’est pas le seul critère. Une poignée de facteurs très concrets comptent tout autant dès qu’on passe en production.
Rendu JavaScript et contenu dynamique
Scrapy seul est aveugle à tout ce qui est rendu côté client. Selenium voit tout parce que c’est un vrai navigateur. L’entre-deux — Scrapy-Splash (plus ancien, scriptable en Lua) et scrapy-playwright (plus moderne, recommandé) — permet de rendre sélectivement du JS dans la boucle de crawl de Scrapy, au lieu de s’engager sur un navigateur complet pour chaque requête. Si 80 à 90 % de vos pages cibles sont du HTML statique et que seules quelques-unes ont besoin de JS, le rendu sélectif est l’architecture logique. Tout rendre via un navigateur parce que certaines pages en ont besoin, c’est du gaspillage de ressources.
Scalabilité et concurrence
Passer de 1 000 à 1 000 000 de pages avec Scrapy relève surtout d’une question de capacité : augmenter le nombre de requêtes simultanées, éventuellement répartir la charge sur plusieurs workers via Redis. Faire évoluer Selenium revient à ajouter linéairement des instances de navigateur, donc à ajouter linéairement de la RAM et du CPU, ce qui vous amène à gérer une ferme de navigateurs avec Selenium Grid et à vous occuper de la reprise après incident. Ce n’est pas que Selenium ne puisse pas passer à l’échelle — c’est que l’échelle, ici, devient un projet d’infrastructure, pas un simple réglage de configuration.
Pipelines de données et export
Le pipeline d’items de Scrapy gère la validation, la déduplication et l’export vers JSON, CSV ou base de données comme fonctionnalité intégrée. Selenium ne vous donne rien de tout cela — vous devez écrire vous-même la sérialisation et le stockage. Si la qualité des données et l’intégration en aval comptent pour vous (et elles devraient), Scrapy vous donne une vraie longueur d’avance.
Maintenance et fiabilité à long terme
Voici un schéma que j’ai souvent observé : les spiders Scrapy vieillissent plutôt bien parce que l’architecture fondée sur des middlewares impose une certaine structure. Les scripts Selenium deviennent fragiles — les mises à jour du navigateur cassent les drivers, les problèmes de timing provoquent des exécutions instables, et chaque changement du DOM oblige à mettre à jour les sélecteurs. J’ai vu des développeurs dire franchement sur des forums qu’un scraper basé sur Selenium « ne semblait pas être le meilleur choix pour quelque chose qu’on va vendre à un client », et honnêtement, ce réflexe est juste si le projet doit survivre plus de quelques mois sans qu’on y retouche.
Réalité anti-bot : comment chaque outil se comporte face aux défenses de 2026
C’est la partie que tous les autres comparatifs survolent, alors qu’elle décide en pratique si votre scraper fonctionne ou non. Ni Scrapy ni Selenium n’ont été conçus en tenant compte de l’infrastructure anti-bot moderne, et prétendre le contraire, c’est s’exposer à une mauvaise surprise en production.
| Couche de défense | Scrapy | Selenium | Scrapy-Playwright | API Thunderbit |
|---|---|---|---|---|
| Rendu JS | ❌ Nécessite un middleware | ✅ | ✅ | ✅ Intégré |
| Empreinte TLS | ⚠️ Détectable | ⚠️ Détectable | ⚠️ Mieux, sans résolution totale | ✅ Pris en charge |
| Résolution de CAPTCHA | ❌ Manuelle | ❌ Manuelle | ❌ Manuelle | ✅ Intégré |
| Rotation de limitation de débit | ⚠️ Proxies à gérer soi-même | ⚠️ Proxies à gérer soi-même | ⚠️ Proxies à gérer soi-même | ✅ Géré |
Scrapy échoue frontalement aux contrôles d’empreinte navigateur parce qu’il n’y a justement pas de navigateur à identifier — c’est juste un client HTTP, et beaucoup de fournisseurs anti-bot bloquent le trafic qui ne ressemble pas à celui d’un vrai navigateur. Selenium passe les vérifications JS de base puisqu’il s’agit vraiment d’un navigateur, mais il reste détectable via des signaux comme navigator.webdriver, un indicateur standard qui passe à vrai sous automatisation. Des correctifs comme undetected-chromedriver essaient de le masquer, mais ils jouent à « tape-taupe » contre des fournisseurs de détection qui mettent régulièrement leurs signatures à jour.
La course à la furtivité, et pourquoi le bricolage maison est fragile
La vérité inconfortable à propos des correctifs anti-détection, c’est qu’ils demandent une maintenance continue : ce n’est pas une solution, c’est un tapis roulant. undetected-chromedriver et playwright-stealth marchent jusqu’à ce que Cloudflare Turnstile ou DataDome publie une mise à jour qui repère la technique utilisée. Ensuite, il faut repatcher. J’ai vu des équipes passer plus de temps d’ingénierie à maintenir leur couche de furtivité qu’à construire le scraper lui-même.
La limitation de débit mérite aussi d’être mentionnée. Lorsqu’un serveur renvoie 429 Too Many Requests, l’en-tête Retry-After n’est qu’une suggestion, pas une obligation — beaucoup de sites ne l’envoient pas du tout, et certains vous brident via d’autres signaux. Le AutoThrottle de Scrapy aide en ajustant le délai selon la latence observée, mais il réagit après coup ; il ne prévient pas.
C’est là qu’une API d’extraction managée devient vraiment intéressante : la gestion anti-bot devient le problème d’ingénierie de quelqu’un d’autre, pas le vôtre. J’y reviens plus loin.
L’effet Playwright : pourquoi « Scrapy vs. Selenium » ne suffit plus
Présenter ça comme un duel à deux outils ne reflète plus ce qui s’est passé dans la communauté scraping ces dernières années. Les forums de développeurs sont remplis de personnes disant, en substance, « je suis passé à Playwright depuis Selenium et j’en suis très content » — pourtant, la plupart des articles comparatifs ne mentionnent Playwright qu’en passant, voire pas du tout.
Playwright, développé par Microsoft, pilote Chromium, Firefox et WebKit via une seule API. Son modèle d’actionabilité attend qu’un élément soit visible, stable et réellement interactif avant d’exécuter une action — ce qui réduit fortement les problèmes de timing qui rendent beaucoup de scripts Selenium capricieux. Il gère aussi les contextes de navigateur plus efficacement, en permettant de créer des sessions isolées sans devoir lancer un nouveau navigateur complet à chaque fois.
Quand Playwright remplace totalement Selenium
Pour le scraping spécifiquement — et non pour des tests navigateur avec une infrastructure Selenium déjà en place — Playwright est souvent tout simplement le meilleur outil en 2026. Création de contexte plus rapide, empreinte par page plus légère, support natif de l’asynchrone, interception réseau intégrée. Si vous lancez un projet de scraping de zéro sans suite de tests Selenium à préserver, il y a peu de raisons de choisir Selenium en premier.
L’exception : si votre équipe dispose déjà d’une infrastructure de test Selenium, ou si vous avez besoin d’une personnalisation très spécifique du profil navigateur que Playwright ne gère pas aussi proprement, Selenium garde sa place.
Comment fonctionne scrapy-playwright
scrapy-playwright est un gestionnaire de téléchargement pour Scrapy qui envoie uniquement les requêtes marquées meta={"playwright": True} dans un vrai navigateur — tout le reste reste sur le chemin HTTP rapide et asynchrone de Scrapy. Voici un spider simplifié qui parcourt un catalogue paginé où les fiches produit sont rendues côté client en JS :
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Seules les pages qui ont vraiment besoin d’un rendu passent par le navigateur. C’est tout le sens de l’approche hybride : vous ne payez pas le coût du navigateur sur chaque requête, seulement sur celles qui l’exigent.
Scrapy-Splash vs. Scrapy-Playwright : quel middleware choisir
Scrapy-Splash exige de déployer un service Docker Splash séparé et d’écrire des scripts Lua pour les interactions — ça fonctionne, mais c’est plus lourd et plus ancien. scrapy-playwright s’intègre directement à la boucle événementielle asynchrone de Scrapy, prend en charge les trois grands moteurs de navigateur et gère les interactions complexes sans ajouter un deuxième langage de script. Si vous démarrez un nouveau projet en 2026, il n’y a franchement plus de raison de choisir Splash.
Architecture hybride prête pour la production
La plupart des articles disent « vous pouvez combiner Scrapy et Selenium » puis s’arrêtent là. Ce n’est pas une architecture. C’est une suggestion. Voici à quoi ressemble une vraie configuration de production.
Le flux : un scheduler Scrapy envoie les requêtes vers un routeur d’URL qui vérifie si une page est statique ou dynamique. Les requêtes statiques passent directement par le downloader standard de Scrapy. Les requêtes dynamiques sont taguées puis envoyées vers le middleware Playwright, qui gère un pool de contextes navigateur. Les deux chemins convergent ensuite vers le même pipeline d’items pour validation, déduplication et export — que les données viennent d’un HTML brut ou d’un DOM rendu, elles finissent dans la même sortie JSON, CSV ou base de données.
Quelques conseils de déploiement si vous passez en production : conteneurisez avec Docker pour que les binaires navigateur Playwright soient livrés de manière cohérente entre les environnements, limitez le nombre de contextes Playwright en fonction de la RAM disponible (je ne dépasserais pas 8 à 10 contextes sur une machine standard de 4 Go), et lancez les tâches planifiées via cron ou une chaîne CI/CD plutôt que de laisser un processus tourner sans fin.
Cette configuration vous donne un contrôle maximal. Elle signifie aussi que vous êtes désormais responsable des mises à jour des binaires navigateur, des bugs du cycle de vie des contextes (des pages non fermées peuvent bloquer un crawl), de la rotation des proxies et de tous les correctifs anti-bot que vous devrez ajouter. C’est un vrai engagement d’ingénierie, et mieux vaut l’assumer clairement avant de se lancer.
Pour les équipes qui veulent une sortie structurée sans porter cette infrastructure, la CLI de Thunderbit attaque le même problème sous un autre angle :
thunderbit batch extract --schema schema.json --file urls.txt
Même sortie JSON structurée. Pas de code de spider, pas de pool de navigateurs, pas de plomberie anti-bot à maintenir. Vous échangez une partie de la personnalisation contre une mise en production plus rapide — c’est un compromis légitime, pas une amélioration universelle, et tout dépend du niveau de contrôle dont votre projet a réellement besoin.
La voie « sans framework » : quand une API de scraping IA surpasse les deux
À un moment, un développeur se rend compte qu’il n’a en réalité pas besoin d’un framework de crawl. Il lui faut des données structurées à partir de 500 URL connues, et construire un spider, un pool de navigateurs et une couche anti-bot pour ça ressemble à un surdimensionnement — parce que c’en est souvent un.
C’est le vide que Thunderbit est conçu pour combler, et je le dis tout de suite : ce n’est pas un remplacement de Scrapy pour un crawl complexe, récursif, avec logique personnalisée. C’est un autre outil pour un problème différent et plus ciblé.
API ouverte : POST /extract prend un schéma JSON et renvoie des données structurées qui le respectent — pas du HTML brut, ni un bloc de Markdown que vous devez analyser vous-même. POST /distill fait l’inverse et renvoie un Markdown propre, prêt à être injecté dans un pipeline RAG ou un LLM. Le service managé prend en charge le rendu JavaScript et la gestion anti-bot, donc vous n’avez pas à gérer cette infrastructure vous-même. Le guide Distill vs. Extract indique actuellement 1 crédit par page Distill et 20 par page Extract ; vérifiez la documentation en ligne avant de budgéter, car les conditions produit peuvent évoluer.
Serveur MCP : pour les agents IA comme Claude ou Cursor, le serveur MCP de Thunderbit expose la distillation, l’extraction structurée, la suggestion de champs et les jobs batch comme outils, permettant à un agent de récupérer des données web fraîches pendant sa tâche sans quitter son environnement.
CLI : la CLI Thunderbit documentée prend en charge des commandes comme thunderbit extract <url> --schema schema.json et s’intègre naturellement aux workflows terminal et aux tâches planifiées. Tu peux rediriger le Markdown distillé vers un autre outil pour des recherches ponctuelles rapides.
Si tu préfères éviter complètement le code, l’extension Chrome Thunderbit couvre le même terrain avec une interface point-and-click, ce qui vaut le coup d’œil si ton équipe comprend des non-développeurs qui ont besoin de données sans toucher au terminal. J’ai aussi écrit davantage sur le paysage plus large du scraping web IA et du scraping web sans code si tu veux une vue d’ensemble plus complète.
Sois honnête sur le camp dans lequel tu es : Scrapy reste le bon choix pour des crawls multi-sites complexes avec logique personnalisée et suivi récursif des liens. Selenium ou Playwright pour les parcours riches en interactions. Mais « j’ai besoin de données structurées à partir de ces URL connues » est un problème bien plus étroit que ce pour quoi ces deux outils ont été pensés, et une API peut réellement t’éviter le code du spider, la plomberie anti-bot et la maintenance continue qu’implique le fait de porter cette infrastructure.
Scrapy vs. Selenium vs. Playwright vs. API IA : comparaison côte à côte
| Fonctionnalité | Scrapy | Selenium | Scrapy-Playwright | API Thunderbit |
|---|---|---|---|---|
| Langages pris en charge | Python uniquement | Python, Java, C#, JS, Ruby | Python | REST (n’importe quel langage) |
| Rendu JavaScript | Non (nécessite un middleware) | Oui | Oui | Oui, intégré |
| Asynchrone / concurrence | Natif, élevé | Limité par instance | Natif via Scrapy | Géré côté serveur |
| Gestion anti-bot | À gérer soi-même | À gérer soi-même | Partielle | Intégrée |
| Pipeline/export de données | Intégré | À construire soi-même | Intégré | JSON structuré en sortie |
| Complexité d’installation | Modérée | Faible au départ, élevée à grande échelle | Modérée à élevée | Minime |
| Charge de maintenance | Faible à modérée | Élevée | Modérée | Quasiment nulle |
| Idéal pour | Crawls statiques à gros volume | Parcours riches en interactions | Sites mixtes statiques/dynamiques | URL connues, sortie structurée |
Si tu évalues d’autres options de scraping au-delà de ces quatre-là, jette aussi un œil à la façon dont les alternatives à Instant Data Scraper et les meilleurs extracteurs web IA se positionnent — le marché s’est beaucoup densifié, et tous les outils ne résolvent pas le même problème.
Notes juridiques et éthiques pour le web scraping en 2026
Je vais être bref, car ce n’est pas le cœur du sujet, mais c’est important. Le paramètre ROBOTSTXT_OBEY de Scrapy permet à ton spider de respecter les règles du robots.txt — c’est une bonne pratique, tout en sachant que le Robots Exclusion Protocol précise lui-même que ses règles ne constituent pas une autorisation d’accès légale. Selenium et Playwright n’offrent aucun respect du robots.txt intégré — c’est entièrement à ta charge. Quel que soit l’outil, vérifie les conditions d’utilisation du site et la législation applicable dans ta juridiction avant de scraper et de réutiliser des données ; le simple fait que ce soit « visible publiquement » ne veut pas dire que c’est automatiquement autorisé partout.
Choisir le bon outil pour votre projet de scraping en 2026
La décision se résume vraiment à quatre questions : quel est le type de contenu, quelle est l’échelle, quel niveau d’interaction faut-il, et combien de maintenance continue êtes-vous prêt à assumer. Pour des pages statiques à grande échelle, prenez Scrapy. Pour des pages très JavaScript avec de vraies interactions, prenez Selenium ou Playwright. Pour un mix des deux, construisez l’hybride. Pour des URL connues où vous voulez simplement des données structurées avec peu de maintenance, une API comme celle de Thunderbit vous fera probablement gagner plus de temps qu’elle ne vous en coûtera.
« Scrapy vs. Selenium » n’a jamais été la vraie question — c’était juste le seul cadrage disponible à l’époque. Playwright a changé le milieu de terrain, et les API d’extraction IA ont ouvert une nouvelle voie pour ceux qui ont compris qu’ils construisaient de l’infrastructure au lieu de résoudre un problème métier. Ça vaut la peine d’essayer la version gratuite avant de t’engager dans une direction ou une autre — suggest-fields est gratuit et distill consomme un seul crédit, donc tu peux vérifier si l’approche API te convient avant d’écrire une seule ligne de code de spider.
FAQ
Scrapy est-il plus rapide que Selenium pour le web scraping ? Dans mes tests, oui — souvent d’un ordre de grandeur sur les pages statiques, car l’architecture asynchrone de Scrapy évite complètement la surcharge du navigateur. L’écart se réduit lorsque Scrapy utilise le middleware Playwright pour des pages très JavaScript, mais Scrapy garde généralement l’avantage en débit global sur des charges mixtes, car les pages sans JS restent sur le chemin rapide.
Scrapy peut-il gérer des pages rendues en JavaScript ?
Pas tout seul — Scrapy ne voit que la réponse HTML initiale. Ajouter scrapy-playwright ou l’ancien Scrapy-Splash comme middleware permet de rendre sélectivement certaines requêtes dans un vrai navigateur tout en gardant le reste du crawl sur le chemin natif plus rapide de Scrapy.
Quand faut-il utiliser Selenium plutôt que Scrapy ? Quand tu as besoin d’une interaction complète avec le navigateur — connexions en plusieurs étapes, clics dans des assistants, remplissage de formulaires — et que le nombre de pages reste modéré plutôt qu’énorme. C’est aussi le choix logique si tu disposes déjà d’une infrastructure de test basée sur Selenium que tu veux réutiliser pour le scraping.
Playwright est-il meilleur que Selenium pour le scraping en 2026 ? Pour le scraping spécifiquement, en général oui — Playwright offre souvent de meilleures performances, un auto-wait intégré et une empreinte plus légère par contexte navigateur. Selenium garde toutefois un avantage pour les équipes qui exploitent déjà des suites de tests multi-navigateurs établies que Playwright n’a pas vocation à remplacer.
Qu’est-ce qu’une API de scraping IA, et quand remplace-t-elle Scrapy ou Selenium ? Une API de scraping IA, comme l’Open API de Thunderbit, gère côté serveur le rendu JS, les défenses anti-bot et l’extraction des données, puis renvoie du JSON structuré conforme au schéma que vous avez défini. C’est le bon choix quand vous avez des URL connues et que vous voulez une sortie structurée sans construire ni maintenir l’infrastructure de crawl — ce n’est pas un remplacement de Scrapy pour des crawls complexes, récursifs et fondés sur une logique personnalisée.
En savoir plus
