Crawlee, testé : un framework Node, deux moteurs d’extraction

La plupart des gens découvrent Crawlee en cherchant à répondre à une autre question : « quel navigateur headless dois-je utiliser ? » Ce n’est pas la bonne question, et Crawlee est justement là pour le montrer. Ce n’est pas un navigateur. C’est un framework Node/TypeScript qui en embarque un quand c’est nécessaire, et s’en passe quand ce n’est pas le cas.

J’ai passé quelques jours à mettre Crawlee 3.17.0 à l’épreuve sur un ensemble contrôlé de fixtures et quelques sites de démonstration publics, sous Node v22.22.3 et macOS. La promesse mise en avant — une seule bibliothèque, une seule API, avec au choix un crawler HTTP ou un vrai navigateur en dessous — était précisément ce que je voulais vérifier, car c’est elle qui détermine si Crawlee mérite d’entrer dans votre stack ou si vous feriez mieux d’appeler directement Playwright. Réponse courte : la logique des deux moteurs tient la route, avec quelques réserves que je détaille plus bas.

Ce qu’est vraiment Crawlee — et ce qu’il n’est pas

Crawlee se présente comme une bibliothèque de web scraping et d’automatisation de navigateur pour Node.js, conçue pour créer des crawlers fiables. Le positionnement officiel est large : extraction de données pour l’IA, les LLM, le RAG ou les GPT ; téléchargement de HTML, PDF, JPG, PNG et autres fichiers ; compatibilité avec Puppeteer, Playwright, Cheerio, JSDOM et le HTTP brut ; mode avec interface ou headless ; rotation de proxy incluse. Le périmètre est vaste, donc il est utile de préciser ce que Crawlee n’est pas.

Ce n’est pas un moteur de rendu. Il n’embarque pas son propre navigateur. Quand vous avez besoin d’exécuter du JavaScript, Crawlee pilote Playwright ou Puppeteer, qui pilotent ensuite Chromium (ou un autre navigateur). Ce n’est pas non plus un service hébergé que vous appelez à distance : c’est une dépendance que vous installez et exécutez vous-même. Plus précisément, Crawlee est la couche au-dessus du fetcher : les classes de crawler, la file de requêtes, le stockage, la logique de suivi des liens. Voyez-le comme le framework de crawl, avec un moteur interchangeable en dessous.

Pour information, la version testée était la 3.17.0 (publiée le 2026-06-04), en TypeScript, sous licence Apache-2.0, et le dépôt affichait environ 24,6 k étoiles au 2026-07-09 sur apify/crawlee. Les étoiles évoluent — le dépôt en a gagné 53 pendant les deux jours où je l’ai surveillé — donc il faut considérer ce chiffre comme une photo à l’instant T, pas comme une donnée figée.

Les deux moteurs : CheerioCrawler contre PlaywrightCrawler

C’est ici que la conception prend tout son sens, et c’est là que j’ai passé l’essentiel de mon temps.

CheerioCrawler suit la voie HTTP. Il récupère le HTML brut via le réseau et le parse avec Cheerio — pas de navigateur, pas d’exécution JavaScript, pas de rendu. C’est rapide et peu coûteux. PlaywrightCrawler, lui, emprunte la voie navigateur. Il lance un vrai Chromium, rend la page y compris le JavaScript qui construit le DOM, et peut même prendre des captures d’écran.

Deux moteurs différents, avec de vraies capacités différentes. L’idée de Crawlee, c’est qu’ils partagent la même interface. Tous deux acceptent un requestHandler. Tous deux exposent run(). Tous deux suivent les liens avec enqueueLinks. Passer de l’un à l’autre revient à changer de classe, pas à réécrire votre logique — j’ai vérifié cela en gardant une extraction strictement identique et en ne changeant que la classe de crawler qui l’encapsulait.

Il y a un point important à noter, car c’est là que la parité s’arrête : l’objet de contenu n’est pas le même. Dans un handler CheerioCrawler, on reçoit $ — un DOM statique, déjà parsé, que l’on interroge comme avec jQuery. Dans un handler navigateur, on reçoit un objet page vivant. La file, le routage et le tuyau « pousser cette donnée, suivre ces liens » restent identiques, mais la façon de lire réellement la page change. La documentation de Crawlee le dit d’ailleurs clairement : l’interface commune couvre les opérations de crawl, tandis que l’accès au contenu est ce qui varie.

Moteur	Mode de récupération	Exécute JavaScript ?	Mon test (1 page dynamique)	Idéal pour
CheerioCrawler	HTTP brut + parse Cheerio	Non	~0,035 s	HTML statique, API JSON, vitesse
PlaywrightCrawler	Vrai Chromium via Playwright	Oui	~4,967 s	Pages rendues en JS, captures d’écran

Ces temps proviennent d’une seule machine et d’un seul passage — ce n’est pas un benchmark, juste l’illustration du compromis. Le mode navigateur a coûté environ deux ordres de grandeur de plus sur la même URL. C’est le prix du rendu, et la raison pour laquelle on ne l’utilise pas par défaut.

Le test : même URL, 0 contre 8/8

Les promesses sont faciles à faire. Si je fais confiance à l’histoire des deux moteurs, c’est parce que j’ai pu la faire échouer, puis la corriger en changeant une seule classe.

J’ai créé une fixture dynamique locale — une page catalogue où les cartes produits sont injectées par JavaScript après le chargement, le genre de page devenue standard sur le web moderne. J’ai pointé CheerioCrawler dessus. Résultat : 0 carte produit. Ce n’est pas un bug ; c’est une conséquence logique. Cheerio n’a jamais exécuté le JavaScript, donc les cartes n’ont jamais existé dans le HTML analysé. Ensuite, j’ai envoyé PlaywrightCrawler sur exactement la même URL, sans rien changer d’autre, et il a rendu 8 produits sur 8 tout en capturant une capture d’écran comme preuve.

Pour m’assurer qu’il ne s’agissait pas d’une particularité de ma propre fixture, j’ai appliqué le même schéma à un site public — la page de démonstration JavaScript Quotes to Scrape, qui génère ses citations côté client. Même résultat, même sens : CheerioCrawler a vu 0 citation, PlaywrightCrawler en a récupéré 10.

Je veux être précis sur ce que cela prouve. C’est une reproduction propre d’une capacité que Crawlee documente déjà — le framework partage la même base et la même interface entre ses types de crawler depuis la version 3.0. Il s’agit donc d’une vérification, pas d’une découverte. Mais c’est exactement ce qui compte : la promesse marketing « une seule interface, HTTP ou navigateur » est bien réelle, et voici le reçu du passage de 0 à l’ensemble des données, sur une fixture que je contrôle comme sur un site extérieur.

Là où la voie HTTP gagne

Il serait tentant de lire la section précédente comme : « utilisez toujours le navigateur ». Surtout pas. Toute la valeur de cette architecture à deux moteurs, c’est justement que le navigateur est le filet de secours coûteux, pas le choix par défaut.

Sur du contenu statique, CheerioCrawler s’est montré rapide et précis. Ma fixture de catalogue statique a retourné 12 produits sur 12 avec un rappel complet, en suivant la pagination via enqueueLinks({ selector: '.next-page' }), en environ 0,155 seconde. Une page d’article a livré son titre et ses 3 paragraphes sur 3, tout en séparant proprement le boilerplate de connexion/abonnement/droits d’auteur du contenu utile.

Le point le plus important à retenir : une page dont les données sont chargées en JavaScript dispose souvent, derrière elle, d’une API JSON. Les données de ma fixture dynamique vivaient à une URL d’API, et lorsque j’ai pointé CheerioCrawler directement sur cette API, il a récupéré 8 produits sur 8 — sans navigateur, en environ 0,035 seconde. Les mêmes données que le navigateur a mis presque cinq secondes à afficher. La leçon est ancienne, mais toujours vraie : si vous pouvez reproduire la requête source, faites-le plutôt que de lancer Chromium. Crawlee vous permet de faire ce choix crawler par crawler, sans changer de framework.

La partie “framework de crawl” — la vraie raison de choisir Crawlee plutôt qu’une simple librairie navigateur

Si tout ce qu’il vous fallait était de rendre une seule page, vous n’auriez pas besoin de Crawlee — Playwright ou Puppeteer suffiraient. Une simple librairie navigateur ne vous donne pas un crawl : pas de file, pas de déduplication, pas de contrôle de profondeur, pas de retries. C’est cette partie-là de Crawlee qui ne concerne pas les moteurs.

J’ai lancé un crawl sur le même hostname depuis la racine de la fixture, en utilisant enqueueLinks avec suivi de profondeur. Crawlee a parcouru 11 pages réparties sur les profondeurs {0:1, 1:3, 2:7} — une racine, trois pages à un clic, sept pages à deux clics — et a respecté maxRequestsPerCrawl comme condition d’arrêt. RequestQueue a géré toute la mécanique de suivi. Quand j’ai envoyé une requête vers une page renvoyant une erreur HTTP 500, Crawlee a retenté, puis a fait remonter l’échec via failedRequestHandler au lieu d’avaler silencieusement l’erreur ou de faire tomber l’exécution.

C’est l’argument le plus solide en faveur de Crawlee face à un outil navigateur autonome : l’orchestration du crawl est intégrée et, surtout, elle reste la même que le moteur en dessous soit HTTP ou navigateur. Vous écrivez votre logique de file et de suivi une seule fois. Vous décidez séparément si chaque crawler doit rendre le JavaScript.

Installation et téléchargement caché du navigateur

L’installation s’est déroulée sans difficulté majeure, avec un piège toutefois, qui surprendra les nouveaux utilisateurs.

npm install crawlee playwright s’est exécuté proprement — 0 vulnérabilité signalée. Mais PlaywrightCrawler ne se lancera pas tant que vous n’aurez pas exécuté npx playwright install chromium, qui télécharge un binaire Chromium d’environ 81,7 MiB. Installer seulement le package crawlee ne récupère pas de navigateur. Si vous sautez cette étape et passez directement à un crawler navigateur, vous tomberez sur une erreur de lancement pas forcément évidente si vous ne connaissez pas déjà le modèle de packaging de Playwright. C’est un comportement hérité de Playwright, pas un défaut de Crawlee, mais c’est un vrai point de friction au premier lancement qu’il vaut mieux signaler.

Un autre détail opérationnel : par défaut, Crawlee écrit dans un répertoire local storage/. Mon harness de test redirigeait cela vers un dossier temporaire et désactivait la persistance pour garder un environnement propre, mais une exécution classique laissera un dossier storage/ dans votre projet. Ce n’est pas un problème, juste quelque chose à savoir avant qu’il n’apparaisse dans votre git status.

Un troisième moteur, rapidement

L’histoire de la parité ne s’arrête pas à Cheerio et Playwright. Il y a aussi PuppeteerCrawler, et j’ai vérifié jusqu’où va la promesse de « même interface » — au niveau des classes et de l’API, pas via un crawl réel.

Les trois classes de crawler remontent toutes à la même base BasicCrawler. CheerioCrawler passe par un HttpCrawler; PlaywrightCrawler et PuppeteerCrawler passent tous deux par un BrowserCrawler partagé. En introspectant le package installé, 24 méthodes publiques sont communes aux trois moteurs, y compris les opérations de file et de stockage sur lesquelles repose toute l’architecture — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. PuppeteerCrawler et PlaywrightCrawler exposent même exactement le même ensemble de méthodes publiques. Les seules différences inter-moteurs se situent à l’interface HTTP versus navigateur, ce qui est exactement là où on s’y attend.

Il faut toutefois être clair sur la limite : je n’ai pas exécuté de crawl réel avec PuppeteerCrawler. La dépendance peer puppeteer est optionnelle et n’était pas installée dans mon environnement de test, et l’exercer aurait impliqué un autre téléchargement de navigateur. La parité de Puppeteer est donc validée structurellement — même base, mêmes méthodes partagées, même forme de handler — et non par une exécution effective. Et même lorsque l’interface correspond, le comportement interne n’est pas parfaitement identique : la documentation de Crawlee précise que Playwright attend automatiquement les éléments, alors que Puppeteer demande des attentes explicites. C’est une différence propre au moteur, pas un défaut de Crawlee, mais cela signifie que « même API » ne veut pas dire « même code à l’intérieur de chaque handler ».

Ce que je n’ai pas testé

Voici ce que cette série d’essais a volontairement laissé de côté, pour éviter d’interpréter mes résultats plus largement qu’ils ne le permettent.

• La montée en charge. Tout s’est déroulé sur de petites fixtures et des crawls courts sur des sites publics. Pas de test de 100 à 1 000 pages, donc je ne peux rien affirmer sur l’autoscaling de Crawlee ni sur sa stabilité en charge réelle.
• La persistance de la file et la reprise. Je n’ai jamais interrompu un crawl en cours pour voir si RequestQueue reprenait proprement après un crash. C’est une fonctionnalité clé pour les longs traitements, et elle n’a pas été testée ici.
• L’export Dataset et KeyValueStore. J’ai écrit moi-même mes exports JSON/CSV dans le harness. L’ergonomie des exports intégrés Dataset/KeyValueStore — probablement l’un des vrais bénéfices du framework — n’a pas été exercée.
• Les pools de proxies et de sessions. Crawlee inclut la rotation de proxy et des fonctionnalités de fingerprinting. Je les considère strictement comme un sujet de conformité et d’exploitation, pas comme un argument de contournement anti-bot, et je ne les ai pas non plus poussés dans leurs retranchements.

Et, sur toute la ligne, les temps mesurés correspondent à une seule machine et un seul passage. Ils montrent la forme du coût HTTP versus navigateur. Ce ne sont pas des benchmarks, et je ne les citerais pas comme tels.

Avantages et inconvénients

Avantages

• Une seule surface d’API pour le crawl HTTP et navigateur — le changement de moteur est réellement un changement de classe, vérifié par le passage de 0 aux données complètes sur une fixture locale et un site public.
• Un vrai framework de crawl : RequestQueue, enqueueLinks avec contrôle de profondeur, retries et failedRequestHandler, pas seulement un moteur de rendu de page.
• Une extraction HTTP précise (12/12 sur le statique, 3/3 paragraphes d’article, 8/8 via API JSON) quand le JavaScript n’intervient pas.
• Le moteur navigateur récupère ce que le HTTP ne peut physiquement pas voir, et prend des captures d’écran.
• Licence Apache-2.0, TypeScript, maintenu activement.

Inconvénients

• Les crawlers navigateur nécessitent un npx playwright install chromium séparé (~81,7 MiB) que npm install crawlee ne gère pas — facile à oublier.
• Le rendu navigateur entraîne un coût réel par page (~5 s contre moins d’une seconde dans mon test sur une page).
• Le dossier storage/ est créé par défaut lors d’une exécution simple.
• La montée en charge, la reprise après crash, et l’ergonomie d’export intégrée n’ont pas été démontrées dans mes tests.
• Les fonctions de proxy et de fingerprinting doivent être utilisées dans le respect des conditions d’un site et de la loi — une responsabilité, pas un argument d’évasion à mettre en avant.

Quand choisir Crawlee plutôt qu’une API managée

Crawlee est un outil à construire soi-même, et c’est le bon choix pour beaucoup d’équipes. Adoptez-le si vous voulez posséder le crawler dans votre propre base Node, mélanger crawl HTTP et navigateur dans un même projet sans changer de framework, et garder la main sur la file et le stockage. Si vous êtes à l’aise avec l’exploitation, puis à terme la montée en charge d’une flotte de navigateurs, Crawlee vous offre une colonne vertébrale propre et bien pensée pour cela.

L’autre option consiste à ne pas gérer cette infrastructure vous-même. Si vous ne voulez pas passer votre temps à surveiller des instances Chromium, la rotation de proxy et la gestion anti-bot, une API managée est l’alternative — et c’est là qu’intervient notre propre stack pour développeurs chez Thunderbit. Pour les profils techniques, Thunderbit n’est pas l’extension Chrome ; c’est une API d’extraction IA, un serveur MCP et une CLI. Vous appelez POST /distill pour transformer une page en Markdown propre, prêt pour les LLM, ou POST /extract avec un JSON Schema pour récupérer des données structurées, avec un renderMode none, basic ou full afin de choisir quand un rendu navigateur complet vaut réellement le coup. Le serveur MCP permet à un agent IA (Claude, Cursor et autres clients MCP) de scraper en cours de tâche, et la CLI s’exécute depuis le terminal ou en CI :

Essayez Thunderbit pour l’extraction de données web

npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md

La différence importante pour les développeurs : Crawlee vous fournit la matière brute — HTML rendu, nœuds parsés — et vous gérez le pipeline ; une API managée vous renvoie du JSON structuré conforme au schéma, avec rendu JavaScript, CAPTCHAs et protection anti-bot gérés côté serveur. Ce sont deux usages différents. Si vous voulez un contrôle maximal et que l’exploitation ne vous fait pas peur, Crawlee. Si vous voulez les données sans la flotte de navigateurs, la voie managée. Beaucoup d’équipes finissent par utiliser les deux : l’une pour les crawls sur mesure, l’autre pour les cas « donnez-moi juste les données structurées ». Vous pouvez voir le compromis de coût sur la tarification de Thunderbit.

Verdict

Faut-il utiliser Crawlee ? Oui — si vous êtes développeur Node ou TypeScript et que vous voulez un framework unique capable de couvrir à la fois le crawl HTTP et navigateur, avec une vraie file de crawl en dessous. La promesse des deux moteurs est précisément la raison de le choisir, et elle a tenu sans accroc sur mes fixtures : la même URL est passée de 0 aux données complètes par simple changement de classe, l’extraction statique était rapide et fiable, et le crawl par file et profondeur s’est comporté comme documenté.

Il faut simplement avoir deux choses en tête. Prévoyez le téléchargement caché du navigateur lors de votre première utilisation de PlaywrightCrawler, et n’imaginez pas que les parties que je n’ai pas testées — montée en charge, reprise après crash, exports intégrés — fonctionneront aussi bien que celles que j’ai vérifiées tant que vous ne les aurez pas exécutées sur votre propre charge de travail. Comme base pour construire votre propre crawler, Crawlee est une pièce d’ingénierie solide et bien conçue. Comme pipeline de données final, sans intervention, c’est un point de départ, pas une destination.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

Crawlee est-il gratuit, et sous quelle licence est-il distribué ? Oui. Crawlee est open source sous licence Apache-2.0 et s’installe via npm (npm install crawlee). La version que j’ai testée était la 3.17.0. L’exécution des crawlers navigateur nécessite un téléchargement séparé de Chromium via Playwright, qui est lui aussi gratuit mais ajoute environ 81,7 MiB à votre installation.

CheerioCrawler ou PlaywrightCrawler — lequel choisir ? Utilisez CheerioCrawler lorsque les données se trouvent dans le HTML brut ou dans une API JSON sous-jacente — il est bien plus rapide et ne lance jamais de navigateur. Utilisez PlaywrightCrawler lorsque le contenu est rendu en JavaScript, ce que vous repérerez si la voie HTTP renvoie des résultats vides. Dans mes tests, le moteur HTTP a renvoyé 0 élément sur une page rendue en JS, et le moteur navigateur a tout récupéré. Comme ils partagent la même API, le passage de l’un à l’autre se fait par changement de classe, pas par réécriture.

Crawlee a-t-il besoin d’un navigateur pour fonctionner ? Seulement pour les crawlers navigateur. CheerioCrawler n’en a pas besoin du tout. PlaywrightCrawler (et PuppeteerCrawler) ont besoin d’un binaire de navigateur — installez-le avec npx playwright install chromium. Notez que npm install crawlee seul ne télécharge pas de navigateur, ce qui est le piège le plus fréquent au premier lancement.

Crawlee peut-il gérer la pagination et les crawls multi-pages ? Oui, et c’est l’une des raisons centrales de le choisir plutôt qu’une simple bibliothèque navigateur. enqueueLinks suit les liens (y compris les sélecteurs de pagination comme .next-page), RequestQueue déduplique et pilote le crawl, et vous disposez du contrôle de profondeur ainsi que des limites maxRequestsPerCrawl. Lors de mes essais, un crawl sur le même hostname a parcouru 11 pages sur les profondeurs 0 à 2, et les requêtes en échec ont remonté via failedRequestHandler.

Comment Crawlee se compare-t-il à une API de scraping hébergée ? Crawlee est auto-hébergé : vous écrivez et exécutez le crawler, et vous assumez la montée en charge, les proxys et la gestion anti-bot. Une API managée comme les endpoints distill/extract de Thunderbit renvoie du Markdown propre ou du JSON structuré conforme au schéma, avec rendu et anti-bot gérés côté serveur, via une API, un serveur MCP et une CLI. Choisissez Crawlee pour garder un contrôle maximal sur votre propre pipeline ; choisissez une API managée si vous préférez ne pas exploiter ni faire monter en charge vous-même l’infrastructure navigateur.