Test de Puppeteer 24.16 : automatisation Chrome-first sans orchestration de crawl

Puppeteer est la bibliothèque Node de Google qui permet de piloter un vrai Chrome depuis JavaScript : tu écris l’automatisation, le Chrome DevTools Protocol transmet les commandes, et un navigateur complet affiche la page avant même que tu ne lises le moindre octet. Le projet se trouve sur puppeteer/puppeteer sur GitHub : licence Apache-2.0, développé en TypeScript, avec environ 95,3 k étoiles (95 307 au moment où j’ai pris la capture). Son positionnement officiel est volontairement précis — « une API JavaScript pour contrôler Chrome (et, à titre expérimental, Firefox) » — ce qui dit clairement ce qu’il est, et tout aussi utilement, ce qu’il n’est pas.

J’ai soumis Puppeteer 24.16.0 au même serveur de tests et aux mêmes démonstrations publiques que nous utilisons pour chaque bibliothèque d’automatisation de navigateur : un catalogue statique avec pagination, un article, un catalogue rendu en JavaScript, une API JSON, une route qui renvoie un 500, un petit graphe de crawl, ainsi que Books to Scrape et Quotes to Scrape. Le rendu s’est déroulé proprement, sans fioritures. En revanche, il m’a laissé exactement une tâche sur le bureau — la même que toutes les bibliothèques de navigateur headless laissent — et le fait d’assumer franchement cette limite est précisément ce qui distingue un vrai test d’un communiqué de presse.

Un chiffre a davantage retenu mon attention que les taux de rappel. Sur une page dont les données arrivent depuis un endpoint JSON, Puppeteer a récupéré les 8 enregistrements sans scraper le DOM du tout : il a exécuté le fetch dans la page et lu directement l’objet de réponse. C’est, avec le rendu natif et des captures d’écran fonctionnelles, la vraie nature de l’outil : un moteur de rendu Chrome mature, pas un framework de crawl — et cette différence compte avant même que tu n’écrives la moindre ligne.

Ce qu’est vraiment Puppeteer (et avec quoi il est en concurrence)

Le nom de la catégorie fait ici un vrai travail, alors commençons par là. Puppeteer est une bibliothèque d’automatisation de navigateur. Elle lance Chrome, ouvre des pages, laisse s’exécuter le JavaScript de la page, puis te renvoie le résultat rendu pour lecture ou capture. C’est exactement la raison pour laquelle on l’utilise plutôt qu’un client HTTP + parseur HTML : on veut la page après l’exécution des scripts, pas la coquille vide envoyée en premier par le serveur.

Dans sa philosophie, il se compare aux autres bibliothèques basées sur un vrai navigateur — Playwright et Selenium — et non aux frameworks de crawl comme Scrapy ou aux outils LLM-Markdown. Si tu pointes Puppeteer vers mille URLs en espérant qu’il les mette en file, déduplique, limite le débit proprement et écrive un jeu de données, tu as apporté un moteur de rendu à un problème de crawling. Il rendra chaque page à merveille, mais n’assurera aucune orchestration. (C’est une limite de périmètre, pas un bug — j’y reviens, car c’est sans doute le point le plus important à intégrer avant d’adopter l’outil.)

Puppeteer est né au sein de l’équipe Chrome de Google, d’où son ADN résolument Chrome-first et son API qui ressemble à un gant finement ajusté posé sur le protocole de débogage du navigateur. L’outil est suffisamment ancien pour être rassurant dans le bon sens du terme : les méthodes utiles sont stables depuis des années, la documentation est solide, et tout l’écosystème autour est très riche.

Rendu natif et extraction via fetch dans la page

Deux comportements méritent d’être isolés dans le tableau de résultats, car ils définissent la manière dont on utilise réellement l’outil.

D’abord, le rendu natif. Le catalogue rendu en JavaScript — une page qui construit sa grille produit côté client après le chargement — a renvoyé 8/8, avec une capture plein écran enregistrée sur disque. La configuration était minimale, mais incluait bien une attente sur le contenu cible après goto. La page publique Quotes to Scrape en JavaScript a renvoyé les dix citations selon le même schéma. Il s’agit de résultats observés sur des fixtures, pas d’un score général de rappel du rendu.

Ensuite, la fixture d’API JSON chargeait les produits depuis /api/dynamic-products. L’exécution d’un fetch en same-origin via page.evaluate a renvoyé les huit enregistrements sans analyser les lignes rendues. Il s’agit d’un pattern général d’évaluation dans le navigateur, pas d’une fonctionnalité de découverte propre à Puppeteer. Cela peut simplifier l’extraction lorsque le point de terminaison et le contrat de requête sont connus ; en revanche, les en-têtes d’authentification, les jetons runtime, les politiques de cookies, CORS/CSP, les service workers et la pagination peuvent toujours faire diverger la requête réelle de l’application.

Le troisième enseignement à retenir n’est pas un chiffre, mais le cadrage : Puppeteer est un moteur de rendu Chrome mature, et ce n’est pas un crawler. Les deux affirmations sont vraies, et la seconde est celle que les articles oublient souvent.

Comment Puppeteer communique avec Chrome

Sur Chrome, Puppeteer utilise le Chrome DevTools Protocol (CDP), le canal JSON sur WebSocket utilisé par les outils de développement du navigateur. puppeteer.launch() démarre Chrome et ouvre cette connexion ; des appels comme goto, $$eval et screenshot exposent les opérations du navigateur via une API de plus haut niveau. La prise en charge de Firefox suit la voie WebDriver BiDi décrite plus bas, donc toutes les opérations Puppeteer ne sont pas universellement des commandes CDP.

page.evaluate exécute une fonction dans le contexte d’une page ; un fetch('/api/...') relatif utilise donc l’origine de cette page et peut réutiliser les cookies et l’état de session éligibles. En revanche, il ne reproduit pas automatiquement les en-têtes d’autorisation créés par l’application, ni les options de requête, ni les jetons, ni le comportement des service workers. Sur cette fixture same-origin, il a renvoyé le JSON directement ; en production, il faut inspecter le contrat réel de la requête.

C’est aussi pour cela que Puppeteer est « lourd ». Chaque page est un vrai onglet de navigateur, avec un vrai moteur de rendu derrière. Cela te donne une meilleure fidélité sur les pages riches en JavaScript, mais te coûte davantage de mémoire et de temps de démarrage qu’un simple fetch HTTP. Il n’existe pas de rendu gratuit ; CDP a seulement le mérite de rendre la facture lisible.

La question du moteur, clairement posée

On entend souvent dire que Puppeteer est « réservé à Chrome ». Pour la version que j’ai testée, c’est faux, et corriger ce point change la comparaison.

Chrome for Developers et Mozilla ont tous deux mis en avant l’arrivée de Firefox lorsqu’elle a été annoncée. La version que j’ai exécutée, 24.16.0, est bien au-delà de la v23, donc dire « Chrome-only » sous-estime ce qui est réellement livré. L’absence de WebKit, ainsi que le caractère encore relativement jeune de son histoire multi-moteurs par rapport à Playwright, constituent la vraie différence de portée — pas « un moteur contre trois ».

Le chemin Firefox/BiDi est documenté et disponible dans la version testée, mais je n’ai pas exécuté mes fixtures dessus ; je rapporte donc une capacité, pas une mesure. Si Firefox est critique pour tes cibles, valide-le sur tes propres pages avant de t’engager. Pour les lecteurs qui veulent un face-à-face complet sur le moteur et le périmètre linguistique, notre comparatif Playwright vs Puppeteer exécute les deux bibliothèques sur ces mêmes tests et tranche la question du « lequel choisir » là-bas ; ici, le sujet est Puppeteer seul.

Installation et réalité du setup : le navigateur est la partie lourde

Le chemin par défaut npm install puppeteer télécharge une version compatible de Chrome for Testing. Ce comportement peut être désactivé ou redirigé via la configuration, et l’utilisateur peut pointer Puppeteer vers un autre exécutable ; l’alignement des versions dépend donc du choix de déploiement. Le téléchargement du navigateur a été la partie la plus lourde de cette installation ; un instantané d’audit du gestionnaire de paquets n’est pas considéré comme une propriété de sécurité durable.

Cette intégration automatique du navigateur est un vrai gain d’ergonomie, mais aussi un vrai coût en empreinte, et il faut nommer les deux. L’avantage : pas besoin de chercher un navigateur compatible ni d’épingler les versions à la main ; npm install te donne un duo fonctionnel. L’inconvénient : tu télécharges un navigateur, donc il faut prévoir du stockage et de la bande passante, surtout en CI, où un cache froid fait payer ce coût à chaque runner neuf.

C’est aussi une vraie différence avec Playwright, qui sépare les deux étapes : tu installes la bibliothèque, puis tu lances un npx playwright install séparé pour récupérer ses builds de navigateurs. Aucune des deux approches n’est douloureuse ; elles échouent simplement différemment. La commande unique de Puppeteer peut te surprendre par sa taille sur une connexion limitée, tandis que l’étape supplémentaire de Playwright peut tout simplement être oubliée. Il faut savoir dans quel scénario on se trouve.

Résultats pratiques

Chaque test a été exécuté sur un serveur de fixtures local sur 127.0.0.1 ainsi que sur deux sites publics de démonstration, avec Node v22.22.3, macOS arm64, Puppeteer 24.16.0 et son Chrome fourni. La vérité de référence de chaque fixture a été notée avant l’exécution, de sorte que le rappel est mesuré par rapport à un ensemble attendu fixe, et non à ce que Puppeteer a produit par hasard.

Le dossier de recherche public inclut le serveur de fixtures, le runner de tests et la vérité terrain. Le lockfile de dépendances et le résumé brut d’exécution ont volontairement été retirés du bundle de publication, car l’examen de sécurité strict a rejeté les données de lockfile et les éléments d’environnement propres aux endpoints. Pour reproduire la fixture locale sûre, exécute npm install, puis node run_puppeteer_material_tests.mjs dans tools/puppeteer/tests, et compare ensuite le résultat avec la vérité terrain publiée. Les pages de démonstration publiques peuvent changer, donc la fixture locale constitue la base stable pour les vérifications de comptage attendu.

Pour une reconstruction historique exacte des dépendances, crée et audite localement un nouveau lockfile au lieu de considérer un lock non publié comme une preuve publique.

Quelques-uns de ces résultats méritent une phrase de plus que le tableau.

Le code de pagination écrit pour le test a récupéré les 12 éléments attendus du catalogue. Le sélecteur d’article a récupéré le titre et les trois paragraphes attendus ; le boilerplate environnant restait accessible dans le DOM. Puppeteer fournissait le DOM rendu, tandis que la logique de sélection — et non Puppeteer lui-même — définissait ce qui comptait comme contenu de l’article.

Sur la route HTTP 500 testée, goto a renvoyé un objet de réponse avec un statut 500 inspectable et n’a pas levé d’exception. Cela ne dit rien des timeouts, des échecs DNS, des crashs du navigateur, des frames détachées ou d’autres erreurs de navigation, qui nécessitent toujours une gestion explicite.

Le graphe de crawl est celui qui raconte toute l’histoire. Parcourir les liens internes de la fixture jusqu’à 12 pages, en suivant la profondeur pour ne pas revisiter les URLs, a nécessité un breadth-first search écrit à la main — car Puppeteer n’a pas de file de crawl intégrée. Le parcours a trouvé les 12 pages aux profondeurs {0:1, 1:4, 2:7}, autrement dit mon BFS a fonctionné. Mais le BFS était à moi. Puppeteer rendait chaque page ; la logique de navigation sur le site était du code que j’avais écrit. Pour douze pages, cela représente une douzaine de lignes et ce n’est pas un problème. Pour des milliers d’URLs avec déduplication, retries et délais de politesse, cette douzaine de lignes devient un vrai projet.

Je répète un point de prudence, car il est facile de l’utiliser de travers : les artefacts incluent des temps par test, mais il s’agit d’observations sur une seule exécution, une seule machine, pas de benchmarks. Je ne classe pas la vitesse de Puppeteer par rapport à d’autres sur la base d’un seul ordinateur portable et d’un seul run. Ce que ces chiffres soutiennent, c’est le rappel et le comportement sur huit types de pages différents — pas une affirmation de chronomètre.

Ce que je n’ai pas testé

Pour éviter d’interpréter les résultats au-delà de ce qu’ils disent réellement, voici ce qui est resté hors de l’exécution, et donc hors de ces chiffres :

Rien de tout cela n’est un reproche. Ce sont simplement les limites de ce qu’un test sur fixtures peut revendiquer honnêtement.

Avantages et inconvénients

Avantages :

• Rendu JavaScript natif avec attente explicite du contenu : 8/8 sur la fixture dynamique et les dix citations sur la démo publique, avec captures d’écran.
• La pagination écrite à la main et les sélecteurs d’article ont récupéré les éléments attendus de la fixture.
• fetch dans la page a renvoyé les huit enregistrements depuis le point de terminaison same-origin connu, sans parsing du DOM.
• Le HTTP 500 testé est revenu sous forme de réponse inspectable, sans exception.
• L’installation par défaut télécharge une version compatible de Chrome for Testing ; il reste possible de configurer un exécutable alternatif ou de sauter le téléchargement.
• API mature centrée sur Chrome via CDP, avec un écosystème profond et une documentation solide. Apache-2.0.
• Plus large que sa réputation : prise en charge documentée de Firefox via WebDriver BiDi depuis la v23.

Inconvénients :

• Pas de file de crawl intégrée, pas d’écrivain de dataset, pas de throttle : à l’échelle du crawl, il faut écrire son propre code ou passer par un wrapper.
• Pas de moteur WebKit, et son histoire multi-moteurs est plus récente que celle de Playwright.
• Poids d’un vrai navigateur : un Chrome fourni à télécharger et un coût mémoire par page, comparé aux outils HTTP-only.
• Basé sur Node ; l’utiliser depuis un autre langage impose de créer et maintenir un pont.
• La version testée (24.16.0) est en retard d’une version majeure sur la dernière npm (25.3.0) — il faut revalider sur la version actuelle avant de faire confiance à des chiffres précis.

Pour qui c’est fait, et qui devrait passer son tour

Choisis Puppeteer si tu travailles dans Node, que tes cibles s’affichent correctement dans Chrome (c’est le cas de la plupart) et que tu veux une bibliothèque mature et ciblée qui transforme « la page après l’exécution du JavaScript » en quelque chose que tu peux lire et capturer. Pour extraire un ensemble de pages dynamiques, récupérer une API JSON avec la session de la page, ou produire des captures d’écran rendues comme preuve, c’est une option solide et sans drame. L’option Firefox via BiDi existe si tes besoins évoluent, et l’écosystème fait que la plupart des problèmes que tu rencontreras ont déjà été rencontrés auparavant.

Réfléchis à deux fois si ton vrai problème est l’orchestration du crawl plutôt que le rendu. Si tu dois parcourir des centaines ou des milliers d’URLs avec déduplication, retries et limites de débit, Puppeteer seul te fera reconstruire un crawler à la main — ce n’est pas son niveau d’abstraction. Évite complètement un navigateur headless si tes pages n’ont pas réellement besoin de JavaScript pour révéler leurs données ; lorsqu’une requête HTTP et un parseur suffisent à récupérer le contenu, un vrai navigateur devient une solution coûteuse et inutile qui brûle simplement de la mémoire et du temps de configuration. Et si tu as besoin de fidélité WebKit ou d’un client dans un langage autre que JavaScript, ce n’est pas l’outil adapté à cet axe-là.

Alternatives et place de Thunderbit

Le cadrage honnête d’abord : Puppeteer est gratuit, sous licence Apache-2.0, auto-hébergé, et tu es responsable de tout ce qui l’entoure — la flotte de navigateurs, le code de crawl que tu ajoutes, et la course permanente contre les systèmes anti-bot. Pour beaucoup de projets, cette responsabilité est exactement ce qu’il faut, et aucun service managé ne rendra une page autorisée moins cher qu’un navigateur que tu possèdes déjà.

Dans l’open source, les comparaisons utiles se font par usage, pas par logo. Pour du crawl à grande échelle, Crawlee est le compagnon naturel : son PuppeteerCrawler enveloppe Puppeteer avec la file de requêtes, le dataset et le throttling que la bibliothèque n’embarque pas volontairement, ce qui te laisse le rendu tout en récupérant l’orchestration. Si ton objectif de sortie est un Markdown propre pour un pipeline LLM plutôt qu’un DOM rendu, Crawl4AI pilote un vrai navigateur et produit précisément cela. Si tes pages n’ont pas besoin de navigateur, un framework HTTP-first comme Scrapy appartient à une autre catégorie, plus légère. Quand tu compares plusieurs de ces options, notre tour d’horizon des scrapers open source présente les catégories côte à côte.

Un service managé comme Thunderbit place l’exploitation du navigateur et l’extraction derrière une API. Il n’a pas été testé sur ces fixtures Puppeteer, donc cette revue ne prétend rien de comparable sur le rendu, les blocages, la qualité d’extraction ou le coût. La frontière décisive est celle de la responsabilité opérationnelle : gérer toi-même le navigateur et le code de crawl, ou payer un fournisseur pour opérer une partie de cette couche.

Avec Puppeteer, il n’y a pas de frais d’utilisation éditeur, mais le calcul, la bande passante, la maintenance du navigateur, l’orchestration et l’exploitation restent à ta charge. Une approche managée facture à l’usage et transfère une partie de cette responsabilité au fournisseur. Cette expérience n’a pas comparé les résultats.

Essayez Thunderbit pour l’extraction de données web

Verdict

Puppeteer 24.16.0 mérite d’être évalué si tu travailles dans Node et as besoin d’une automatisation de navigateur centrée sur Chrome. Le code de fixture écrit pour le test a récupéré 12 éléments statiques, huit éléments dynamiques et dix citations de la démo publique ; l’API same-origin connue a renvoyé huit enregistrements via page.evaluate ; les captures d’écran ont fonctionné ; et le HTTP 500 testé est resté inspectable. Ces résultats concernent les fixtures nommées et une version majeure plus ancienne, pas le rappel d’extraction en général.

Il faut cependant dimensionner correctement les promesses. Puppeteer est un moteur de rendu, pas un crawler : ma navigation sur 12 pages a nécessité un BFS écrit à la main car il n’existe pas de file intégrée, et à grande échelle cette absence représente un vrai travail — confie-le à Crawlee ou écris la mécanique toi-même. Il est Chrome-first avec une prise en charge documentée de Firefox via BiDi, mais sans WebKit, donc ce n’est pas l’outil de la diversité multi-moteurs. Il porte le poids d’un vrai navigateur. Et j’ai testé 24.16.0 alors que la version la plus récente est 25.3.0, donc relance sur la version actuelle avant de faire confiance à des chiffres exacts. Si tu gardes ces quatre points à l’esprit, Puppeteer est une excellente bibliothèque d’automatisation Chrome. En revanche, si tu t’attends à ce qu’il te fasse le crawl d’un site, tu te retrouveras à écrire le crawler que tu pensais télécharger.

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

FAQ

Puppeteer rend-il les pages JavaScript, ou faut-il un plugin ?
Il les rend nativement, sans plugin. Sur ma fixture dynamique, il a renvoyé 8 produits sur 8 construits côté client, avec un rappel de 1.0 et une capture plein écran ; la page publique Quotes to Scrape en JavaScript a renvoyé les 10 citations de la même manière — un simple goto, puis la lecture du DOM rendu. Comme Puppeteer pilote un vrai Chrome via le DevTools Protocol, les scripts de la page s’exécutent réellement avant toute lecture.

Puppeteer peut-il extraire une API JSON sans parser le HTML ?
Oui, lorsque le point de terminaison et le contrat de requête le permettent. page.evaluate peut lancer une requête depuis l’origine de la page et réutiliser les cookies éligibles, mais il ne reproduit pas automatiquement les en-têtes, jetons, options ou comportements de service worker de l’application. Sur la fixture same-origin, il a renvoyé les huit enregistrements sans parsing DOM.

Puppeteer est-il un crawler web ?
Non — c’est une bibliothèque d’automatisation de navigateur, pas un framework de crawl. Il n’y a ni file de requêtes intégrée, ni writer de dataset, ni throttle, donc mon crawl de 12 pages (profondeurs {0:1, 1:4, 2:7}) a nécessité un breadth-first search écrit à la main. C’est une limite de périmètre, pas un défaut. Pour du crawl à grande échelle, associe-le à un wrapper comme Crawlee PuppeteerCrawler, qui ajoute la file et la logique de dataset que Puppeteer n’inclut pas.

Puppeteer est-il réservé à Chrome ?
Plus maintenant. Il est Chrome-first via CDP, mais depuis la v23 il prend officiellement en charge Firefox via WebDriver BiDi, et la version que j’ai testée (24.16.0) va bien au-delà. Ce qu’il ne pilote pas, c’est WebKit, et son histoire multi-moteurs est plus récente que celle de Playwright — c’est cela, et non « Chrome-only », qui constitue la vraie limite. Ici, je n’ai exercé que Chrome, donc je rapporte la prise en charge Firefox via BiDi comme documentée, pas comme mesurée.

Que télécharge réellement l’installation de Puppeteer ?
Par défaut, npm install puppeteer télécharge une version compatible de Chrome for Testing. Le téléchargement peut être ignoré ou redirigé, et un autre exécutable peut être configuré, donc l’alignement des versions dépend des choix de déploiement. Prévois du disque et de la bande passante pour le navigateur, surtout sur les runners CI sans cache. Cette revue a testé la version 24.16.0 ; relance les fixtures principales sur la version en vigueur au moment de la publication.