Tous les quelques mois, quelqu’un de l’équipe repose la même question sur Slack : « On ne ferait pas juste un spider Scrapy pour ça ? » Et à chaque fois, ma réponse dépend entièrement de qui demande et de ce qu’il veut obtenir. En vrai, ça résume déjà tout l’article, mais laissez-moi quand même gagner mon salaire et expliquer pourquoi.
J’ai passé l’essentiel de la dernière décennie dans le SaaS et l’automatisation — d’abord chez Automation Anywhere, à voir les entreprises automatiser tout sauf le moment où quelqu’un devait encore copier-coller des données depuis un site web, puis chez Thunderbit, où « copier-coller depuis un site web » est précisément le problème qu’on veut supprimer. Scrapy, lui, alimente discrètement les flux de données du web depuis bien avant que « IA agentique » ne soit à la mode au dîner. Les comparer, ce n’est pas vraiment mettre Thunderbit face à Scrapy pour désigner un gagnant. C’est plutôt comparer un couteau suisse à un atelier d’usinage parfaitement équipé : dans les deux cas, on obtient une pièce découpée, mais le processus, le niveau de compétence requis et le bazar à nettoyer ensuite n’ont rien à voir.
Réponse rapide
Si vous voulez la version courte avant d’entrer dans les détails : Thunderbit est un extracteur Web agentique managé — vous l’ouvrez sur une page, vous cliquez une fois, et il comprend la structure pour vous, que vous travailliez dans le navigateur, dans la Web App, via l’Open API, le MCP Server ou la CLI. Scrapy est un framework Python open source mature — vous écrivez le spider, définissez les sélecteurs, construisez le pipeline et assumez chaque ligne de code qui touche à vos données.
Aucun des deux n’est « meilleur » dans l’absolu. Ils sont conçus pour des profils et des besoins différents, et franchement, si autant d’articles se contentent d’un verdict unique, c’est en partie pour ça que j’avais envie d’écrire quelque chose de vraiment utile.
En un coup d’œil
Voici le tableau que j’aurais aimé trouver la première fois que j’en ai cherché un. Chaque article sur « Thunderbit vs Scrapy » que j’ai lu noie soit les deux outils dans un comparatif plus large autour de Scrapy et BeautifulSoup, soit vous sert un petit widget de répertoire sans note ni contexte. Alors on a fait le vrai.
| Dimension | Scrapy | Thunderbit |
|---|---|---|
| Ce que c’est | Framework Python open source (spiders, pipelines, middleware, moteur asynchrone) | Extracteur Web agentique sans code — extension navigateur, Web App, Open API, MCP Server, CLI |
| Mise en route | Installer l’environnement Python, écrire un spider, définir les sélecteurs, configurer le pipeline | Ouvrir la page cible, cliquer sur One Click Extract — l’extraction démarre automatiquement (Run Now en option) sur les pages compatibles et autorisées |
| Compétences requises | Python, sélecteurs XPath/CSS, notions asynchrones | Aucun code requis pour le flux navigateur ; l’API/CLI/MCP demandent une configuration technique standard |
| Contenu JS/dynamique | Besoin de scrapy-playwright ou d’une intégration de type Selenium | Fonctionne à partir de la page déjà rendue ouverte dans le navigateur, y compris certaines sessions connectées prises en charge — pas garanti sur tous les sites |
| Gestion anti-bot | Middleware manuel (rotation de proxy, détection de blocage), aucun contournement garanti | Rendu géré sur les pages compatibles et autorisées, aucun contournement garanti non plus |
| Volume / tâches récurrentes | Pensé pour des crawls massifs, scriptables et planifiés | Planification disponible selon le plan et la surface utilisée ; mieux adapté aux tâches ciblées ou de volume modéré |
| Export | Codé sur mesure (JSON, CSV, base de données, pipelines) | Export vers des destinations prises en charge comme Excel, Google Sheets, Airtable ou Notion, plus des formats de téléchargement |
| Maintenance | Les spiders cassent lors des changements de structure ; nécessite du temps de développement | L’extraction assistée par IA s’adapte à certaines variations de mise en page, sans être à l’abri d’une rupture structurelle |
| Modèle de coût | Gratuit / open source + temps de dev + hébergement + coûts de proxy | Abonnement / crédits — consultez la page tarifaire avant d’annoncer des chiffres |
Qu’est-ce que Thunderbit ?
Thunderbit est né d’un constat assez agaçant : la plupart des personnes qui ont besoin de données issues du web ne sont pas développeurs, alors que la plupart des outils d’extraction supposent que vous l’êtes. Cet écart, c’est littéralement la raison d’être du produit.
Le flux principal dans le navigateur est volontairement simple, et c’est tout l’intérêt. Vous ouvrez la page dont vous voulez extraire les données, vous cliquez sur One Click Extract, et l’agent prend le relais — il lit la page, repère ce qui peut être extrait (listes de produits, offres d’emploi, informations de contact, peu importe ce qui s’affiche) et prépare automatiquement les champs. Il existe un bouton Run Now si vous voulez lancer l’opération tout de suite, mais si vous attendez tranquillement avec votre café, l’extraction démarre toute seule. Pas de sélecteurs, pas de schéma à écrire, pas de chirurgie de « inspecter l’élément ».
Au-delà du flux navigateur en un clic, Thunderbit s’étend sur plusieurs surfaces selon ce que vous construisez :
- L’extension Chrome répond au besoin « je suis en train de regarder cette page et je veux ces données maintenant ».
- La Web App couvre la collecte cloud et récurrente pour les utilisateurs métier qui ne veulent pas toucher au code.
- L’Open API expose des points de terminaison Distill et Extract structurés pour les workflows backend et applicatifs.
- Le MCP Server permet à des agents IA dans Claude, Cursor ou Windsurf d’appeler Thunderbit directement comme un outil.
- La CLI s’adresse aux développeurs et agents de code qui vivent dans le terminal.
L’outil gère aussi la pagination et l’enrichissement des sous-pages sur les sites compatibles, et vous pouvez affiner les champs avec des consignes en langage naturel plutôt qu’avec des regex. Rien de tout cela ne garantit un fonctionnement parfait sur tous les sites du monde — j’y reviendrai avec un peu d’honnêteté — mais l’idée est qu’un responsable commercial ou un analyste immobilier n’ait jamais besoin d’ouvrir un éditeur de code.
Qu’est-ce que Scrapy en 2026 ?
Scrapy n’est pas un vieux logiciel abandonné dans un coin. Le site officiel de Scrapy indique la version 2.17.0 comme version stable actuelle, et le projet continue d’évoluer — la dernière version a même ajouté la prise en charge HTTP/2 et SOCKS dans sa couche de téléchargement. Ce n’est pas une histoire du genre « l’IA a tué l’ancien framework ». Scrapy est bel et bien vivant et, honnêtement, toujours très bon dans ce qu’il fait.
Au cœur du système, Scrapy est un framework Python construit autour d’un moteur de crawling asynchrone. Vous écrivez une classe Spider, vous définissez les URL de départ (ou une méthode de départ), et Scrapy envoie des requêtes avec des fonctions de callback qui traitent la réponse. Ensuite, vous sélectionnez les données avec des sélecteurs CSS ou XPath (ou des regex, si vous aimez les méthodes à l’ancienne), vous les empaquetez dans des Items, puis vous les faites passer dans des pipelines pour le nettoyage, la validation et le stockage. La documentation d’introduction officielle déroule tout ce cycle, et c’est un système vraiment élégant une fois qu’on le maîtrise.
Ce que vous obtenez en échange de cet investissement d’apprentissage, c’est un vrai contrôle : cookies et sessions, authentification, cache, respect de robots.txt, limitation de profondeur de crawl, et AutoThrottle pour éviter de vous faire bannir par un administrateur serveur de mauvaise humeur. Il existe aussi un écosystème très riche de middleware et d’extensions — rotation de proxy, gestionnaires de téléchargement personnalisés, hooks de supervision, et plus récemment des add-ons pour le rendu via Playwright, ainsi que des outils d’assistance au codage par IA qui génèrent pour vous le squelette du spider.
Un point mérite d’être dit avec précision : le moteur de base de Scrapy est un crawler HTTP, pas un navigateur. Il ne rend pas JavaScript tout seul. Si vous en avez besoin, il faut ajouter scrapy-playwright, un middleware de type Selenium ou un service de rendu externe. Ce n’est pas vraiment un défaut — c’est un choix de conception assumé qui garde le framework léger et rapide — mais cela veut dire que « gérer un site très orienté JS » relève d’une décision de projet, pas d’un comportement par défaut.
Différence fondamentale : workflow agentique managé vs framework maîtrisé par le code
Temps jusqu’au premier jeu de données
Je ne vais pas inventer des chiffres au chronomètre ici — j’ai vu trop d’articles prétendre que Scrapy a une « courbe d’apprentissage abrupte » sans jamais le démontrer. Comptons simplement les étapes réelles.
Chemin Scrapy pour, disons, extraire une page de listing produit :
- Créer un environnement virtuel Python et installer Scrapy.
- Générer un spider depuis un modèle.
- Inspecter le HTML de la page et écrire des sélecteurs XPath/CSS pour chaque champ.
- Configurer un pipeline d’items pour le nettoyage et l’export.
- Lancer le spider, corriger les écarts de sélecteurs, relancer.
Chemin Thunderbit pour la même tâche :
- Ouvrir la page dans votre navigateur.
- Cliquer sur One Click Extract.
- L’agent identifie les champs extractibles et démarre (ou vous cliquez sur Run Now).
Cinq étapes avec un environnement Python à configurer contre trois étapes sans aucune installation spécifique. Je ne dis pas que le nombre d’étapes est le seul critère qui compte — les cinq étapes de Scrapy vous donnent bien plus de contrôle sur ce qui se passe exactement — mais si votre objectif est littéralement « mettre ce tableau dans un tableur aujourd’hui », la différence est là, et elle dit tout.
Contrôle et extensibilité
C’est là que Scrapy prend l’avantage, et je vous manquerais de respect en prétendant le contraire. Comme vous possédez le code source, vous pouvez construire à peu près n’importe quoi : logique de retry personnalisée, pagination exotique, authentification en plusieurs étapes, intégration avec votre entrepôt de données existant, bref, tout ce que votre architecture exige. L’approche agentique de Thunderbit est optimisée pour « obtenir vite des données structurées sans coder », ce qui signifie par définition qu’elle prend des décisions à votre place au lieu d’exposer chaque levier. Pour 80 % des tâches métier d’extraction, c’est un excellent compromis. Pour les 20 % restants — les logiques de crawl réellement atypiques et sur mesure — il faut un framework que vous puissiez plier à votre volonté.
Propriété de la maintenance et des opérations
Les spiders cassent. Ce n’est pas un reproche à Scrapy — tout scraper, qu’il soit agentique ou codé à la main, dépend du site qu’il vise. Mais quand un spider Scrapy tombe en panne parce qu’un site a refondu son HTML, quelqu’un dans votre équipe doit le constater, diagnostiquer le problème et le corriger. C’est du vrai temps de dev, à chaque fois.
L’extraction assistée par IA de Thunderbit peut s’adapter automatiquement à certains changements de mise en page puisqu’elle raisonne sur la structure de la page plutôt que de s’appuyer sur un chemin de sélecteur codé en dur. Cela dit, soyons honnêtes : ce n’est pas une immunité. Des changements structurels suffisamment importants peuvent toujours le faire dérailler. La différence tient surtout à celui qui adapte : un algorithme qui tente la meilleure estimation possible, ou un développeur qui réécrit du XPath à 23 h.
Cas d’usage concrets
Liste ou tableau de produits ponctuel
Si vous avez besoin d’un tableau d’annonces de restaurants, de prix produits ou de détails d’événements à partir d’une seule page ou d’une courte série de pages, lancer un projet Scrapy est franchement excessif — vous écririez un spider que vous n’utiliserez qu’une fois avant de l’oublier. On est clairement dans le terrain de jeu de l’extension navigateur Thunderbit : ouvrir, cliquer, extraire, exporter vers Google Sheets, terminé.
Crawl personnalisé à grande échelle avec règles métier
Imaginez maintenant que vous devez parcourir 50 000 pages produits sur une douzaine de domaines, appliquer une logique de déduplication sur mesure et alimenter un modèle de tarification propriétaire. Là, on est chez Scrapy. L’architecture en pipelines, les contrôles de concurrence, l’écosystème de middleware — tout cela existe précisément pour ce type de mission, à cette échelle et avec autant de logique métier.
Site dynamique très chargé en JavaScript
Les deux outils ont besoin d’aide dans ce cas, mais pas du même type. Scrapy doit recevoir un moteur de rendu explicite comme scrapy-playwright, ce qui ajoute une dépendance et une surface de maintenance supplémentaire. L’extension navigateur de Thunderbit travaille à partir de la page telle qu’elle est déjà rendue dans votre navigateur — y compris certaines sessions connectées prises en charge — ce qui évite une bonne partie de cette configuration. Mais je veux être clair : aucune des deux approches ne garantit de gagner face à des systèmes anti-bot agressifs ou à des schémas de contenu dynamique inhabituels. Quiconque vous dit le contraire essaie probablement de vendre quelque chose.
Intégration avec un agent IA ou une application
Si vous construisez un workflow d’agent IA dans Claude ou Cursor et que vous voulez qu’il récupère des données web en direct au fil de son raisonnement, écrire une intégration Scrapy sur mesure représente un vrai effort. Le MCP Server de Thunderbit est conçu exactement pour ça : il expose l’extraction comme un outil que votre agent peut appeler directement.
Précision, échelle et maintenance
La précision de Scrapy est déterministe au bon sens du terme — un sélecteur bien écrit récupère exactement le champ que vous lui avez demandé, à chaque fois, jusqu’à ce que le HTML sous-jacent change. Cette prévisibilité est réellement précieuse pour les pipelines de production où il faut savoir précisément pourquoi quelque chose a échoué.
La détection agentique de Thunderbit fonctionne autrement. Elle interprète la page comme le ferait un humain et décide ce qui ressemble probablement au prix, au titre, à la description. C’est remarquablement utile pour la rapidité et la souplesse, mais c’est un autre modèle de précision — plus proche de « généralement juste, parfois besoin d’un petit ajustement » que de « exactement ce que dit le sélecteur ». Je préfère être transparent sur ce compromis plutôt que de prétendre qu’une extraction par IA est parfaite.
En débit brut, le moteur asynchrone de Scrapy est conçu pour traiter efficacement des volumes massifs de requêtes — cela fait vraiment partie de son ADN. Thunderbit est davantage optimisé pour des tâches ciblées, de volume modéré, où il est plus important d’obtenir rapidement un résultat propre et structuré que de crawler un million de pages pendant la nuit. Si vous planifiez un crawl vraiment massif, vérifiez les limites actuelles du plan avant de supposer que l’un ou l’autre outil montera en charge comme vous l’espérez.
Dernier point valable pour les deux : l’usage autorisé compte. Quel que soit l’outil choisi, respecter robots.txt, les conditions du site et la loi applicable n’est pas optionnel — c’est simplement faire les choses correctement.
Prix, licence et coût total
Je vois tout le temps la même erreur : confondre « gratuit » et « sans coût ». Scrapy n’a pas de frais de licence — il est open source, point final. Mais un logiciel gratuit a quand même besoin d’un endroit où tourner, et cet endroit coûte de l’argent : hébergement, services de proxy si vous travaillez à gros volume, outils d’automatisation de navigateur si vous avez besoin du rendu JS, supervision pour savoir quand un spider meurt silencieusement, et — c’est le plus gros poste — du temps développeur pour le construire, le tester et le réparer quand il casse.
Thunderbit fonctionne sur un modèle d’abonnement et de crédits, et je vous renvoie vers la page tarifaire officielle plutôt que de citer un montant ici, parce que les grilles tarifaires évoluent et que je préfère que vous voyiez les conditions actuelles directement. Ce que cet abonnement achète, c’est surtout la suppression d’une grande partie de la charge de configuration et de maintenance — en tout cas pour les workflows pris en charge.
La vraie question n’est pas « lequel coûte le moins cher sur le papier ? » mais plutôt « quelle devise votre équipe a-t-elle en plus grande quantité — des heures d’ingénierie ou un budget d’abonnement ? » Une équipe data de cinq personnes avec du temps disponible pourra trouver que le coût total de Scrapy est plus faible une fois ses compétences déjà en place prises en compte. Une équipe ops de trois personnes sans aucun ingénieur en interne constatera que ce framework « gratuit » lui coûte en réalité un devis de prestataire et trois semaines de retard avant de voir la moindre ligne de données.
Qui devrait choisir Thunderbit ?
Thunderbit est particulièrement pertinent si vous êtes un opérateur non technique — ventes, marketing, e-commerce, immobilier, recrutement — et que vous avez besoin de données structurées tout de suite, sans ouvrir un ticket pour l’équipe d’ingénierie. C’est aussi un bon choix pour les développeurs qui veulent un accès programmatique sans reconstruire la logique d’extraction à partir de zéro, puisque l’Open API et la CLI gèrent cette couche pour vous. Si vos workflows concernent la génération de leads, la surveillance e-commerce ou le scraping de profils LinkedIn pour du recrutement ou de la veille, c’est généralement l’option la plus rapide.
Qui devrait choisir Scrapy ?
Scrapy est le bon choix si vous avez des développeurs Python dans l’équipe, si vous construisez une infrastructure de crawling appelée à durer des années, et si vous avez besoin d’un contrôle total sur la logique de requêtes, les retries et les pipelines de données. C’est aussi le meilleur choix si des contraintes de conformité ou d’architecture imposent que le code vous appartienne entièrement — auditabilité, hébergement interne, aucune dépendance externe.
Peut-on utiliser les deux au sein d’une même équipe ?
Beaucoup d’équipes le font, et je ne pense pas que ce soit une réponse de fuite. Les développeurs peuvent faire tourner des spiders Scrapy robustes et à grande échelle pour l’infrastructure de crawling qui doit exister en permanence, tandis que le reste de l’organisation utilise Thunderbit pour la recherche ponctuelle, les extractions ad hoc et le travail exploratoire qui ne justifie pas un sprint d’ingénierie complet. Il n’existe pas d’intégration officielle entre les deux outils — je veux être clair là-dessus — mais sur le plan opérationnel, rien ne vous empêche de les utiliser côte à côte selon le travail et l’outil le plus adapté.
Verdict
Si je devais tout résumer en une seule question de bon sens : cherchez-vous avant tout le contrôle ou la vitesse ? Scrapy vous donne un contrôle total au prix du temps de mise en place et de la maintenance continue. Thunderbit vous donne de la vitesse et de l’accessibilité au prix d’une partie de la flexibilité. Aucun des deux n’est objectivement « le bon » choix — tout dépend de savoir si la personne qui extrait les données connaît Python ou connaît son pipeline commercial. Pour aller plus loin sur la façon dont l’extraction par IA se compare aux méthodes traditionnelles, nos analyses sur le scraping web avec l’IA et le scraping web sans coder couvrent le paysage global au-delà de cette seule comparaison.
FAQ
Scrapy est-il gratuit ? Le framework Scrapy lui-même est open source et n’implique pas de frais de licence, selon le site officiel de Scrapy. Vos coûts réels viennent de l’hébergement, des proxies, des outils de rendu si vous avez besoin du support JS, et du temps développeur pour créer et maintenir les spiders.
Scrapy rend-il le JavaScript tout seul ? Non. Le cœur de Scrapy est un crawler HTTP, pas un navigateur, donc il n’exécute pas JavaScript nativement. Les équipes ajoutent généralement scrapy-playwright ou un middleware de type Selenium lorsqu’elles doivent extraire des sites riches en JS, selon la documentation officielle de Scrapy.
Thunderbit prend-il en charge l’accès via API et MCP ? Oui. Thunderbit propose une Open API avec des points de terminaison Distill et Extract structurés pour un usage programmatique, ainsi qu’un MCP Server qui permet à des agents IA dans des outils comme Claude et Cursor d’appeler Thunderbit directement.
Lequel est le plus rapide pour les utilisateurs métier ? Thunderbit, par conception. Le flux One Click Extract de l’extension navigateur lance l’extraction automatiquement après analyse de la page, sans sélecteurs ni configuration de schéma — un chemin bien plus court que d’installer Python et d’écrire un spider.
Lequel est le meilleur pour des crawls très personnalisés ? Scrapy. Son middleware, son architecture en pipelines et l’accès complet au code source offrent aux développeurs le niveau de contrôle nécessaire pour des logiques de crawling très spécifiques, des tâches planifiées à grande échelle et des pipelines de données sur mesure qu’un outil agentique n’a pas vocation à remplacer.
