Presque tous les classements des « meilleurs scrapers open source » ont le même défaut discret : personne n’exécute les outils sur les mêmes pages. Scrapy est testé sur un article d’actualité, Playwright sur une démo e-commerce, Colly sur ce que l’auteur avait sous la main — puis tout ça est comparé comme si ces chiffres parlaient la même langue. En réalité, ce genre de classement vous dit surtout quelque chose sur les pages, pas sur les outils.
Du coup, j’ai fait la chose la plus simple, mais aussi la plus barbante, que ces listes évitent d’habitude : j’ai construit un ensemble unique de fixtures, puis j’ai fait passer les neuf outils dessus — un catalogue statique, un catalogue rendu en JavaScript, un article noyé dans le nav et le footer, une erreur HTTP 500 volontaire, un petit graphe de liens internes, plus deux sites publics d’entraînement. Même vérité de référence, mêmes mesures, à chaque exécution. Les scripts et les résultats bruts sont disponibles dans un dépôt public de benchmark pour que tu puisses tout relancer toi-même. Le résultat n’est pas le tableau de bord propre et net promis par les comparatifs : il n’y a pas de gagnant unique. Il y a trois types de travaux, et les neuf outils s’y répartissent presque tout seuls.
Essayez Thunderbit pour l’extraction de données web
Comment le benchmark a été construit, et la seule limite que je veux dire clairement
Chaque outil a été confronté aux mêmes types de fixtures : 12 produits statiques répartis sur deux pages, 8 produits injectés par JavaScript après un délai, un article entouré de contenu de navigation et de pied de page autour de trois vrais paragraphes, une erreur serveur 500 intentionnelle, et un graphe de liens internes. C’est cette conception qui permet de comparer les résultats — « 8/8 produits dynamiques » veut exactement la même chose, que le rendu vienne de Puppeteer ou de Crawlee.
Voici la limite que la plupart des comparatifs passent sous silence. Le jeu de fixtures de chaque outil reflète ses propres copies de ces pages, donc les nombres absolus de caractères ne sont pas strictement comparables d’un outil à l’autre — il faut les lire comme des signaux internes à chaque outil, jamais comme un score croisé. Les chiffres qui sont comparables sont le recall (à interpréter comme un taux), la réussite ou l’échec sur JavaScript, et le comportement structurel. Même logique pour un autre point de périmètre : le test statique de Crawl4AI ne couvrait que la première page, donc son 6/6 correspond à un recall complet sur un périmètre plus étroit, tandis que les autres outils ont exploré les deux pages pour un 12/12 — un champ plus réduit, pas un manque partiel. L’explication complète, fixture par fixture, est dans la documentation méthodologique.
Dernière précision avant de regarder les chiffres. Chaque pack inclut aussi un score de recherche provisoire, mais je ne les affiche pas volontairement sous forme de classement. Ce sont des aides internes pour vérifier chaque outil à partir de ses propres preuves, pas un palmarès — et les publier comme tel recréerait exactement le faux problème de précision que tout ce travail cherche à éviter. Ce qui suit est une synthèse du benchmark, pas un podium.
Tout le terrain, sur un seul bench
Lisez les deux colonnes « Rends JavaScript ? » et « File de crawl intégrée » dans ce tableau, et les trois usages apparaissent presque d’eux-mêmes.
| Outil | Langage | Rends JavaScript ? | Recall statique | Sortie structurée | File de crawl intégrée | Poids d’installation | Licence |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Oui (navigateur) | 6/6 (page 1) | Schéma CSS | BFS/DFS intégré | Lourd (2 piles navigateur) | Apache-2.0 |
| Firecrawl | Auto-hébergé | Oui (playwright-service) | Markdown complet | Oui | /v1/crawl | Le plus lourd (6 conteneurs) | AGPL-3.0 |
| trafilatura | Python | Non | 3/3 article | Non (texte uniquement) | Non | Léger | Apache-2.0 |
| Crawlee | Node/TS | Optionnel selon le moteur | 12/12 | Via extraction | Oui (RequestQueue) | Moyen (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Oui | 12/12 | Manuel | Non (BFS codé à la main) | Moyen (navigateur) | Apache-2.0 |
| Puppeteer | Node | Oui (Chrome) | 12/12 | Manuel | Non (BFS codé à la main) | Moyen (Chrome) | Apache-2.0 |
| Scrapy | Python | Non | 12/12 | Export de flux (JSON/CSV/XML) | Oui (intégrée) | Moyen (dépendances Twisted) | BSD-3 |
| Colly | Go | Non | 12/12 | Via callbacks | Contrôle de profondeur | Léger (1 binaire + Go) | Apache-2.0 |
| Scrapling | Python | Non (récupérateur HTTP) | 12/12 | Oui | Non | Moyen ([fetchers]) | BSD-3 |
Petite note sur les métadonnées de ce tableau et de tout ce qui suit : les compteurs de stars et les numéros de version ont été relevés début juillet 2026, et ils évoluent vite. Vérifie-les sur les pages GitHub et package de chaque projet avant de les considérer comme actuels.
L’index des revues outil par outil
Chaque projet de ce comparatif a sa revue détaillée correspondante :
- Revue de Crawl4AI
- Revue de Firecrawl
- Revue de trafilatura
- Comparatif Playwright vs Puppeteer
- Revue de Crawlee
- Revue de Scrapy
- Revue de Colly
- Revue de Scrapling
Voici leurs couvertures — ainsi que deux vraies captures du test de rendu JavaScript, pour que l’affirmation « 8/8 dynamiques » ne soit pas juste un chiffre sur une page.
Travail n°1 : transformer une page en texte prêt pour les LLM
Si tu cherches du Markdown propre à injecter dans un pipeline RAG, trois outils se disputent la place — et ils ne pourraient pas être plus différents dans leur approche.
Crawl4AI est, derrière le marketing, un générateur de Markdown adossé à un navigateur. Il faut oublier le récit de « sélecteur adaptatif auto-apprenant » qu’on voit partout dans les résultats de recherche : il n’existe pas tel quel — c’est une autre bibliothèque qui fait ça (j’y reviens avec Scrapling). En pratique, l’outil fait bien ce qu’il promet. Sur le site d’entraînement Books to Scrape, il a produit 13 476 caractères de Markdown, il gère l’extraction par schéma CSS pour les extractions structurées, et son crawl profond BFS intégré a parcouru 5 pages sur la fixture de graphe tout en rendant une page JavaScript et en capturant une capture d’écran. Deux limites bien réelles, toutefois. Son Markdown brut conserve les éléments de structure de la page à moins d’activer un filtre de contenu, et l’erreur 500 volontaire est revenue avec success=false — non pas parce que Crawl4AI a proprement détecté l’erreur HTTP, mais parce que son propre heuristique de contenu a vu un corps d’erreur minuscule et l’a étiqueté minimal_text ... blocked. Côté installation, cela ajoute aussi deux piles navigateur sur ton disque. Version 0.9.0, Apache-2.0, environ 71k stars début juillet.
Firecrawl est le poids lourd, et l’auto-hébergement fonctionne vraiment — je dis « vraiment » parce que la pile à six conteneurs (api, playwright-service, redis, rabbitmq, nuq-postgres et foundationdb) a effectivement démarré et a produit 9 222 caractères de Markdown prêt pour LLM à partir de la même page Books to Scrape. Il a rendu une page JavaScript via son playwright-service embarqué, et la citation d’Einstein apparue après le script s’est retrouvée dans le résultat, preuve que le rendu était bien réel. Les deux problèmes que j’ai rencontrés venaient de l’environnement, pas de Firecrawl, et je veux être précis pour que personne n’applique le mauvais correctif : une compilation à partir des sources a buté sur un bug intermittent du snapshotter containerd sous colima (je suis passé aux images précompilées), et la plage DNS 198.18.x.x de colima a déclenché la protection SSRF de Firecrawl, que j’ai levée avec ALLOW_LOCAL_WEBHOOKS=true — une rustine de dev local, pas quelque chose à désactiver en production. Le cœur auto-hébergé n’inclut pas non plus Fire-engine, la couche cloud anti-blocage, et je n’ai pas testé l’API cloud. Le drapeau le plus important reste la licence : le cœur auto-hébergé de Firecrawl est en AGPL-3.0, ce qui demande un vrai travail juridique avant tout usage commercial, pas une note de bas de page. Environ 148k stars début juillet.
trafilatura est le contre-exemple du groupe, et c’est aussi celui que les listes dopées à l’IA oublient le plus souvent. Pas de navigateur. Pas de lignes structurées. Juste du texte d’article propre et rapide en Python pur. Sur la fixture d’article, il a récupéré le titre ainsi que les 3 paragraphes réels sur 3, a supprimé complètement le bruit de fond — aucun « Login », « Subscribe » ni « Copyright » n’a filtré — et a aussi récupéré l’auteur et la date. Sur une page produit publique, il a renvoyé 1 324 caractères de texte propre. Sa limite est exactement celle que son design annonce : envoie-lui un catalogue, et il te rend 12 noms de produits en texte, mais 0 ligne structurée — le texte est là, la structure non, et il ne rend aucun JavaScript. Version 2.1.0 (la version actuelle), Apache-2.0, environ 6,2k stars. Pour l’extraction d’articles pure, c’est le premier outil vers lequel je me tournerais.
Les deux volumes de caractères Markdown — 13 476 pour Crawl4AI, 9 222 pour Firecrawl — proviennent de la même page publique, mais il ne faut pas les lire comme un écart de qualité. Ils reflètent des stratégies Markdown différentes (combien d’habillage de page chacun conserve), pas un verdict sur la qualité du rendu. C’est la règle du signal interne à chaque outil, évoquée plus haut, qui se manifeste ici au grand jour.
Travail n°2 : rendre JavaScript de façon fiable
Certaines données n’apparaissent tout simplement pas dans le HTML tant que les scripts n’ont pas tourné, et c’est là qu’un vrai navigateur cesse d’être optionnel. Trois outils couvrent ce travail — et deux d’entre eux se sont révélés être, presque, le même outil.
Playwright et Puppeteer ont obtenu exactement le même résultat sur tous les tests que je leur ai soumis. Tous deux ont rendu 8/8 produits dynamiques sur la fixture locale et 10 sur le site public Quotes JS, tous deux ont atteint 12/12 de recall statique, et tous deux ont géré l’erreur 500 proprement (Puppeteer renvoie un objet response au lieu de lever une exception). Aucun des deux n’embarque de file de crawl, donc il a fallu écrire un BFS manuel, qui a atteint 12 pages sur les profondeurs 0 à 2 du graphe de crawl. La seule vraie différence concerne la portée : Playwright pilote Chromium, Firefox et WebKit et parle Python et .NET, tandis que Puppeteer est d’abord orienté Chrome et uniquement Node. Deux précisions, car les versions évoluent vite : j’ai testé Playwright 1.56.0 par rapport à la version actuelle 1.61.1, et uniquement avec Chromium ; Puppeteer 24.16.0 par rapport à la version actuelle 25.3.0 — à relancer ou à relativiser en conséquence. Les deux sont sous Apache-2.0 ; environ 92k et 95k stars respectivement.
Crawlee est celui qui résout le problème de file que les deux autres laissent ouvert. Il encapsule un moteur Cheerio (HTTP) et un moteur Playwright (navigateur) derrière une API unique, et le contraste sur une seule page résume tout son intérêt : le moteur Cheerio a vu 0 élément injecté par JavaScript, alors que le moteur Playwright en a vu 8/8 en local (et 10 sur le site public), avec un simple changement d’une ligne pour passer de l’un à l’autre. Il fournit aussi une vraie RequestQueue, ce qui lui vaut sa place dans ce travail plutôt que dans le travail n°3. Le bémol que personne n’écrit dans le titre : le moteur navigateur nécessite un npx playwright install séparé, soit environ 80 MiB que npm install crawlee ne télécharge pas pour toi. Version 3.17.0, TypeScript, Apache-2.0, environ 24,6k stars.
Travail n°3 : crawler vite, sans navigateur
Pas de JavaScript sur la page signifie qu’un navigateur est un luxe coûteux et inutile. Trois outils orientés HTTP se disputent cette catégorie, chacun dans une philosophie de langage différente, et leurs différences sont intéressantes.
Scrapy est le framework le plus solide d’un point de vue ingénierie — spiders, exports de flux en JSON/CSV/XML, AutoThrottle, tout y est. Il a atteint 12/12 de recall statique, a récupéré les 3/3 paragraphes de l’article, a parcouru 11 pages sur les profondeurs 0 à 2 du graphe de crawl, et a bien intercepté l’erreur 500 via handle_httpstatus_list. Sa philosophie est la partie la plus intéressante : il ne rend pas la page, il reproduit la requête. Jeté sur la page JavaScript, il a obtenu 0 nœud — puis l’API JSON derrière cette même page lui a donné 8/8. C’est la logique Scrapy en un point de donnée : trouve la requête que la page envoie et rejoue-la, n’ouvre pas un navigateur. Le prix à payer, c’est une pile de dépendances assez lourde (Twisted, lxml, parsel), et je ne l’ai testée que sur de petites fixtures. Version 2.17.0, BSD-3-Clause, environ 63k stars.
Colly est la réponse de Go, et il est agréablement direct sur ce qu’il est : un binaire statique unique, piloté par callbacks via OnHTML, OnResponse et OnError, avec contrôle de profondeur. Il a parfaitement atteint 12/12 de recall statique, a récupéré 8/8 depuis l’API JSON via OnResponse, a intercepté l’erreur 500 via OnError, et a atteint 17 pages avec un crawl de profondeur 2 — et je le formule exactement ainsi, parce que ce comptage vient du harness lui-même, pas d’une garantie de complétude de Colly. Ce qu’il ne fait pas, c’est le JavaScript : la fixture dynamique et le site Quotes JS sont tous deux revenus à 0, par conception. Il vous faut une toolchain Go pour le compiler, et la version du module (v2.3.0) avance actuellement plus vite que la release taguée (v2.2.0). Apache-2.0, environ 25k stars.
Scrapling est l’outil spécialisé, et il mérite vraiment ce qualificatif. Ses sélecteurs adaptatifs sont conçus pour retrouver un élément après une modification du balisage — ainsi, quand j’ai renommé la classe HTML cible de product-name en product-title, un sélecteur classique a renvoyé 0, alors que le réappariement adaptatif a retrouvé l’élément suivi. Sur l’extraction HTTP classique, il a obtenu 12/12 en statique et 8/8 sur l’API JSON. Le point que sa documentation ne cache pas : dans un test synthétique à plusieurs éléments, il a récupéré 1 élément sur 3 — il s’agit d’un suivi d’élément résilient, pas d’une récupération totale, donc ne le survends pas mentalement. Son installation de base pip install scrapling a aussi besoin de l’option [fetchers] pour démarrer, et son StealthyFetcher est une réserve de conformité, pas une fonctionnalité que je mettrais en avant dans une slide. Version 0.4.10 (la version actuelle), BSD-3-Clause, environ 68,7k stars.
Le motif qui se cache derrière les trois travaux
Si l’on aligne les neuf outils, une structure nette apparaît. Un recall statique complet — un solide 12/12 — est le minimum vital pour tous les outils orientés HTTP ; aucun n’a raté ce cas simple, donc ce n’est pas un critère de différenciation. Les outils navigateur ne justifient leur poids supplémentaire que lorsque JavaScript est réellement en jeu, et ils le paient tous en installation : une pile de navigateur, une installation supplémentaire ou tout un parc de conteneurs. Et la colonne « file de crawl intégrée » trace en réalité la frontière entre un framework et un moteur — Scrapy et Crawlee apportent l’orchestration, tandis que Playwright et Puppeteer vous obligent à écrire le BFS vous-même. Voilà la forme du marché. Personne ne gagne au général parce que personne ne joue au même jeu.
Alors, lequel devriez-vous réellement choisir ?
Le benchmark refuse de couronner un vainqueur, parce que la bonne réponse n’est pas un outil, mais une question : quel travail fais-tu parmi les trois ?
- Besoin de Markdown prêt pour les LLM ? Choisis trafilatura si tu vises du texte d’article propre, Crawl4AI si tu veux aussi l’extraction CSS et le rendu JavaScript dans une seule bibliothèque, et Firecrawl si tu cherches spécifiquement un service auto-hébergé et que tu peux assumer à la fois la licence AGPL-3.0 et la lourdeur des six conteneurs.
- Besoin de rendu JavaScript ? Playwright ou Puppeteer pour le rendu brut — choisis selon le moteur et le langage, car à ce niveau ils sont à égalité — et Crawlee si tu veux aussi l’orchestration du crawl sans l’écrire à la main.
- Crawl de pages statiques ou d’API reproductibles à grande échelle ? Scrapy pour un framework Python complet, Colly pour la vitesse brute en Go dans un seul binaire, et Scrapling quand survivre aux variations de balisage est ta douleur précise et récurrente.
Associe l’outil au bon usage, et chacun de ces choix est défendable. Prends la mauvaise catégorie — un outil navigateur pour des pages statiques, ou un parseur HTTP pour une application JavaScript — et même la bibliothèque la mieux notée de tout Internet te laissera tomber.
Où se place une API d’IA managée à la place
Tous les outils ci-dessus sont gratuits, open source, et à toi d’exploiter. C’est aussi le compromis commun que le benchmark fait apparaître sans cesse : tu prends en charge l’environnement navigateur, le code de crawl, la course à l’anti-bot et toute la maintenance. Pour beaucoup d’équipes, ce contrôle est justement l’objectif, et la carte des licences compte quand on s’engage — la plupart des outils sont permissifs (Apache-2.0 pour Crawl4AI, Crawlee, Playwright, Puppeteer et Colly ; BSD-3 pour Scrapy et Scrapling), avec le cœur auto-hébergé de Firecrawl en AGPL-3.0, qui mérite un vrai examen avant toute utilisation commerciale.
Mais regarde aussi ce que le benchmark met en évidence : ce que ces outils ne font pas. Rendre, crawler, structurer et contourner les blocages — rarement tout à la fois, et jamais sans maintenance de ton côté. Une API d’extraction IA managée condense toute cette pile en un appel. Notre propre surface développeur chez Thunderbit est une option dans cette catégorie, et pour un public technique, ce sont surtout l’API, le serveur MCP et la CLI qui comptent, pas l’extension navigateur. POST /distill renvoie du Markdown propre et POST /extract renvoie du JSON défini par schéma, avec le rendu JavaScript et la défense anti-bot gérés côté serveur plutôt que sur ta machine. Il existe un serveur MCP officiel pour les agents et les assistants de code — thunderbit_suggest_fields est gratuit pour préparer une extraction, puis thunderbit_distill (1 crédit) et thunderbit_extract (20 crédits) exécutent le travail — ainsi qu’une CLI installable avec npx @thunderbit/thunderbit-cli pour les usages terminal et cron. Pour les non-développeurs de ton équipe, il y a aussi une extension Chrome sans code, et la tarification couvre les deux usages.
Le compromis reste le même que celui que tout ce benchmark met en lumière : exploiter et maintenir jusqu’à neuf bibliothèques toi-même à coût nul par appel, ou confier la plomberie et payer à la requête. Aucun choix n’est mauvais. Tout dépend de la part de la pile que tu veux vraiment posséder. Si tu préfères voir à quoi ressemble l’extraction en pratique, la chaîne YouTube de Thunderbit propose des démonstrations.
Verdict
Il n’existe pas de meilleur scraper open source unique, et toute liste qui t’en donne un avec assurance cache discrètement la vraie question qui décide tout : quel travail fais-tu ? Transformer une page en texte, rendre JavaScript, ou crawler vite sans navigateur — le marché se répartit proprement dans ces trois cases, et à l’intérieur de chacune, le choix dépend du langage et du poids d’installation, pas d’un champion universel.
Si tu ne dois retenir qu’une habitude, retiens celle-ci : teste sur tes propres pages avant de t’engager. Tous les chiffres ici sont reproductibles dans le dépôt de benchmark pour exactement cette raison — parce que l’outil qui domine un comparatif générique et celui qui résiste à tes cibles réelles ne sont pas toujours le même.
Essayez Thunderbit pour l’extraction de données web Get Started Free
FAQ
Quel est le meilleur scraper web open source ? Il n’en existe pas un seul — tout dépend du travail à faire. Pour du texte prêt pour les LLM, trafilatura ou Crawl4AI ; pour le rendu JavaScript, Playwright, Puppeteer ou Crawlee ; pour un crawl HTTP rapide, Scrapy ou Colly. Sur un banc d’essai commun, chaque outil était le plus fort dans sa propre catégorie et nettement plus faible en dehors, ce qui explique pourquoi les classements « taille unique » sont trompeurs.
Quels scrapers open source rendent JavaScript ? Crawl4AI, Firecrawl, Playwright, Puppeteer et le moteur Playwright de Crawlee rendent tous JavaScript. Scrapy, Colly, trafilatura et le récupérateur HTTP par défaut de Scrapling ne le font pas — ils ont soit besoin d’une API reproductible derrière la page (l’approche de Scrapy, qui a obtenu 8/8 sur le point de terminaison JSON), soit d’un mode navigateur séparé.
Ai-je besoin d’un navigateur headless pour scraper un site ? Seulement si les données apparaissent après l’exécution de JavaScript. Si une requête HTTP simple, combinée à un parseur, permet d’atteindre le contenu, un navigateur est un surcoût inutile — Scrapy, Colly ou Scrapling seront alors beaucoup plus légers et plus rapides.
Lequel a la licence la plus souple pour un usage commercial ? La plupart sont permissives : Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) ou BSD-3-Clause (Scrapy, Scrapling). L’exception est le cœur auto-hébergé de Firecrawl, sous AGPL-3.0, et il mérite un vrai examen de licence avant de construire un produit commercial dessus.
Ces chiffres de benchmark sont-ils reproductibles ? Oui. Chaque exécuteur, chaque fixture et chaque résultat brut se trouvent dans un dépôt public sous licence MIT. Une seule réserve à garder en tête : le recall et les résultats structurels sont comparables entre outils, mais les volumes absolus de caractères ne sont valables qu’à l’intérieur d’un même outil, car chaque pack reflète les fixtures au lieu d’utiliser une copie canonique unique — compare donc les taux et les réussites/échecs, pas les totaux bruts de caractères.
