Puppeteer contre Playwright contre Browserbase pour le MCP

Choisir un serveur MCP d'automatisation de navigateur

L'automatisation de navigateur est l'un des cas d'usage les plus convaincants pour les serveurs MCP aujourd'hui. Donnez à un agent IA la capacité de naviguer entre les pages, d'extraire des données et d'interagir avec des interfaces web, et vous débloquez une catégorie réellement utile de flux de travail autonomes. Les trois serveurs qui reviennent le plus souvent dans ce domaine sont le serveur MCP Puppeteer, le serveur MCP Playwright et l'offre managée de Browserbase. Ils ne sont pas interchangeables, et choisir le mauvais vous coûtera du temps de débogage.

Cet article passe en revue ce que fait réellement chaque serveur, les domaines où chacun peine, et la manière de penser le rate limiting et la détection anti-bot avant d'expédier quoi que ce soit en production.

Le serveur MCP Puppeteer

Le serveur MCP Puppeteer enveloppe la bibliothèque Puppeteer de Google, qui pilote Chromium via le Chrome DevTools Protocol. Il expose des outils comme puppeteer_navigate, puppeteer_screenshot, puppeteer_click et puppeteer_evaluate, donnant à un agent la possibilité de manipuler un navigateur headless avec une granularité raisonnable.

L'installation est directe. Vous le lancez localement via npx @modelcontextprotocol/server-puppeteer, et il démarre une instance de Chromium à la demande. Pour le prototypage rapide et les outils internes, c'est efficace. La surface d'outils est suffisamment réduite pour qu'un LLM ne se perde pas en se demandant lequel appeler.

La limite, c'est que Puppeteer est exclusivement Chromium. Si vous scrapez un site qui se comporte différemment selon les navigateurs, ou si vous avez besoin de Firefox pour une raison quelconque, Puppeteer ne vous aidera pas. Il tourne aussi par défaut dans un seul contexte de navigateur, ce qui pose problème quand vous avez besoin de sessions parallèles ou de pots de cookies isolés pour différentes tâches de scraping.

Le serveur MCP Playwright

Playwright couvre plus de terrain. Le serveur MCP Playwright prend en charge Chromium, Firefox et WebKit, et il expose un ensemble plus riche de contextes de navigateur et d'outils de gestion de pages. La bibliothèque Playwright de Microsoft a été conçue avec l'automatisation de tests en tête, ce qui lui donne une meilleure prise en charge intégrée pour des choses comme l'attente d'états réseau au repos, l'interception de requêtes et la gestion simultanée de plusieurs contextes de navigateur.

L'implémentation MCP côté Microsoft (disponible sous @playwright/mcp) expose des outils dont browser_navigate, browser_snapshot, browser_click et browser_network_requests. L'outil snapshot est particulièrement utile pour les agents car il retourne un arbre d'accessibilité plutôt que du HTML brut, ce qui réduit la consommation de tokens et donne au LLM une représentation plus propre des éléments interactifs.

La prise en charge multi-contexte de Playwright est un véritable avantage pour les flux de scraping qui doivent maintenir des sessions séparées. Vous pouvez faire tourner en parallèle des contextes authentifié et non authentifié, ce qui demande davantage de câblage manuel avec Puppeteer.

Le compromis, c'est la complexité. La surface d'API de Playwright est plus large, et le serveur MCP en porte la trace. Un agent qui dispose de plus de 30 outils peut parfois faire des choix sous-optimaux quant à celui à appeler. L'ingénierie de prompt y compte davantage.

Le serveur MCP Browserbase

Browserbase adopte une approche entièrement différente. Au lieu de faire tourner un navigateur localement, il provisionne des navigateurs cloud à la demande via l'infrastructure Browserbase. Le serveur MCP connecte votre agent à ces sessions distantes, ce qui veut dire que vous n'avez plus à gérer les processus de navigateur, la mémoire ni les mises à jour de Chromium sur vos propres machines.

Les bénéfices pratiques sont significatifs pour le scraping en production. Browserbase prend en charge la rotation de proxys résidentiels, le fingerprinting de navigateur et la persistance de session entre requêtes. Leur infrastructure est spécifiquement conçue pour ressembler au trafic d'utilisateurs réels, ce qui répond à une classe de problèmes anti-bot avec laquelle les setups Puppeteer et Playwright locaux peinent.

Le serveur expose des outils pour créer des sessions, naviguer et extraire du contenu, mais aussi des capacités plus haut niveau comme browserbase_stagehand_act et browserbase_stagehand_extract, qui utilisent leur bibliothèque Stagehand pour permettre à l'agent de décrire ce qu'il veut en langage naturel plutôt que de spécifier des sélecteurs précis. C'est réellement utile lorsque vous scrapez des sites aux structures DOM dynamiques ou inconsistantes.

Le coût évident, c'est que Browserbase est un service payant. Les sessions sont facturées à la minute de temps de navigateur. Pour du scraping à fort volume, cela s'accumule, et vous devez évaluer si les économies d'infrastructure managée compensent le coût par session par rapport à l'exploitation de votre propre flotte de navigateurs.

Limitation de débit et détection anti-bot

Les trois serveurs vous feront bloquer si vous les lancez naïvement contre des sites équipés d'une infrastructure anti-bot sérieuse. Bot Management de Cloudflare, Akamai Bot Manager et DataDome sont les systèmes les plus courants que vous croiserez. Ils observent le timing des requêtes, les empreintes TLS, le comportement des API du navigateur et des signaux comportementaux comme les motifs de mouvement de souris.

Avec Puppeteer ou Playwright en local, c'est à vous d'implémenter les délais entre requêtes, la rotation des user agents et la gestion des CAPTCHA. L'écosystème de plug-ins puppeteer-extra inclut puppeteer-extra-plugin-stealth, qui patche les vecteurs courants de fingerprinting de navigateur. Playwright dispose de plug-ins communautaires similaires. Ils aident, mais ne sont pas infaillibles face à des systèmes de détection sophistiqués.

La limitation de débit au niveau de la couche MCP est quelque chose que vous devez implémenter vous-même quand vous utilisez les serveurs Puppeteer ou Playwright. Aucun des deux serveurs n'a de throttling de requêtes intégré. Si votre agent décide de scraper 500 pages en succession rapide, le serveur s'exécutera. Vous devez soit contraindre le comportement de l'agent via les prompts système et les descriptions d'outils, soit ajouter un middleware de rate limiting entre le serveur MCP et les appels au navigateur.

Browserbase gère beaucoup de cette infrastructure automatiquement. Leurs sessions de navigateur utilisent des empreintes qui correspondent à de véritables builds de Chrome, et ils alternent les IP via des proxys résidentiels. Cela dit, les motifs comportementaux comptent toujours. Un agent qui clique sur 200 pages produit en 90 secondes paraîtra suspect, indépendamment de l'IP d'où il vient.

Considérations éthiques de scraping

Avant que tout choix technique ne compte, il vaut la peine d'être au clair sur ce que vous avez réellement le droit de scraper. Le standard robots.txt est la base, et bien qu'il ne soit pas juridiquement contraignant dans la plupart des juridictions, l'ignorer est à la fois une mauvaise pratique et de plus en plus pertinent en matière de litige. L'affaire hiQ contre LinkedIn a établi un certain précédent sur les données publiques, mais le paysage juridique reste mouvant.

Vérifiez les conditions générales d'utilisation du site. Beaucoup interdisent explicitement l'accès automatisé. Si vous construisez un produit commercial sur des données scrapées, le profil de risque est différent que pour un script de recherche ponctuel.

D'un point de vue pratique, le scraping éthique implique aussi de ne pas marteler les serveurs avec un trafic qui dégrade les performances pour les utilisateurs réels. Implémentez des délais qui approximent la vitesse de navigation humaine, scrapez en heures creuses quand c'est possible, et mettez agressivement en cache pour ne pas re-télécharger des données que vous avez déjà.

Lorsque vous utilisez un serveur MCP dans une boucle agentique, il est facile de perdre la visibilité sur le nombre de requêtes effectivement émises. Intégrez la journalisation au niveau de l'appel d'outil MCP afin de pouvoir auditer ce que fait votre agent. La notation de sécurité de Skillful.sh signale les serveurs MCP qui manquent de contrôles de portée ou qui pourraient servir à de l'exfiltration de données à grande échelle, ce qui est un signal utile pour évaluer des implémentations de serveur tierces.

Quel serveur utiliser

Pour le développement local et l'outillage interne où vous contrôlez les sites cibles, le serveur MCP Playwright est le meilleur choix par défaut. Le support multi-navigateur, la meilleure gestion des contextes et les snapshots d'arbre d'accessibilité le rendent plus capable que le serveur Puppeteer pour la plupart des flux d'agent.

Pour le scraping en production face à des sites équipés de systèmes anti-bot actifs, Browserbase mérite une évaluation sérieuse. Le fingerprinting managé et l'infrastructure de proxys résolvent des problèmes réellement pénibles à gérer soi-même, et les outils d'extraction Stagehand réduisent la fragilité du scraping à base de sélecteurs.

Le serveur MCP Puppeteer a du sens si vous êtes déjà investi dans l'écosystème Puppeteer, si vous avez besoin d'une surface d'outils minimale pour un agent contraint, ou si vous tournez dans un environnement où la taille du binaire Playwright est un souci.

Le bon choix dépend de vos sites cibles, de vos contraintes d'infrastructure et de la part de complexité anti-bot que vous voulez assumer. Commencez avec Playwright en local, et passez à Browserbase quand vous heurtez des murs de détection que les plug-ins de stealth ne savent pas résoudre.

Lectures complémentaires

Parcourez les serveurs MCP sur Skillful.sh. Cherchez plus de 137 000 outils IA sur Skillful.sh.