Donner un navigateur à Claude Code : Playwright MCP, Chrome DevTools MCP et 6 autres solutions mesurées

Sommaire (11 parties)

Claude Code est l'assistant de programmation d'Anthropic qui travaille dans un terminal. Il lit tes fichiers, lance des commandes et modifie ton code. Sur un site web, il lui manque pourtant un sens : la vue. Il écrit le CSS d'un bouton sans jamais voir le bouton.

Pour qu'il voie, on lui donne un navigateur piloté : un navigateur qu'un programme ouvre, fait cliquer, puis interroge. Le programme renvoie ensuite à Claude ce que la page affiche. Plusieurs solutions existent pour brancher ce navigateur, et elles ne coûtent pas pareil. Elles diffèrent par ce que Claude doit lire, par la vitesse, par les navigateurs disponibles et par leurs pièges.

Le 28 octobre 2026, j'ai mesuré huit solutions sur la même page de test, qui contient huit défauts connus. Le langage Go en fournit trois à lui seul. L'extension Chrome d'Anthropic, neuvième solution, ne tourne pas sous Linux : je l'ai essayée côté Windows de la même machine. En mars, j'avais décrit une boucle de test responsive avec Claude Code et Playwright. Cet article-ci compare toutes les solutions.

Le choix en bref, selon ton besoin :

• Tester un site sur mobile, tablette et bureau : Playwright en script ou en ligne de commande, les moins chers à lire.
• Explorer une page avec Claude, sans écrire de code : Playwright MCP.
• Déboguer le réseau, la console ou les performances : Chrome DevTools MCP, le plus riche et le plus lourd.
• Travailler sur un site où tu es connecté : un Chrome de débogage dédié, ou l'extension Claude in Chrome.
• Écrire un test dans un projet Go : chromedp.
• Vérifier Safari : le WebKit de Playwright pour le moteur, un vrai iPhone pour le reste.

Pour essayer tout de suite, installe Playwright MCP avec la commande donnée plus bas. Vérifie ensuite que claude mcp list affiche playwright avec la mention « Connected ». Demande enfin à Claude d'ouvrir ta page locale à 390 px de large et de te dire ce qui déborde.

Trois façons de montrer une page à Claude

Claude ne regarde pas un écran. Il reçoit du texte, et parfois une image, en réponse à chaque action qu'il demande. Une page web peut donc lui arriver sous trois formes :

• un rapport : un programme mesure la page et écrit le résultat en quelques lignes. Par exemple : « la page fait 616 px de large pour un écran de 390 » ;
• l'arbre d'accessibilité : la liste des éléments qu'annoncerait un lecteur d'écran pour personnes aveugles. Chaque élément a son rôle et son texte, comme « bouton Envoyer » ;
• une capture d'écran, envoyée comme image.

Chaque forme a un prix. Tout ce que Claude lit s'empile dans son contexte, la mémoire de travail de la conversation, dont la taille est limitée. Cette taille se compte en tokens, des morceaux de mots. « 8,3 k tokens » veut dire 8 300 tokens. Pour du texte, je compte un token pour quatre octets : c'est l'estimation utilisée dans tout l'article. Plus le contexte est plein, plus chaque échange coûte, comme je l'ai raconté dans mon article sur la consommation de tokens.

Un rapport coûte quelques centaines de tokens. Un arbre d'accessibilité en coûte des milliers, et il grossit avec la page. Le prix d'une image dépend de la façon dont le modèle la réduit. Je ne l'ai pas mesuré à part : je n'ai que son poids en octets.

Le banc d'essai : une page piégée de huit défauts

Pour comparer des solutions, il faut la même épreuve pour toutes. J'ai donc écrit une petite page de contrôle avec huit défauts connus, notés D1 à D8 :

• D1 : un bloc de 600 px de large, qui déborde sur un écran de 390 px ;
• D2 : le texte de deux cartes, coupé quand la page fait entre 700 et 900 px de large ;
• D3 : deux boutons de 26 px de haut, collés l'un à l'autre, trop petits pour un doigt ;
• D4 : un bandeau haut de 100vh, c'est-à-dire de toute la hauteur de l'écran, avec un bouton collé en bas. Sur un vrai iPhone, la barre d'adresse de Safari recouvre ce bouton ;
• D5 : un panneau dont la hauteur utilise calc-size(), une fonction CSS récente que tous les navigateurs ne comprennent pas ;
• D6 : une erreur JavaScript au clic sur un bouton ;
• D7 : une requête vers un fichier absent, qui répond 404, le code « introuvable » du web ;
• D8 : une image sans texte de remplacement, et une légende gris clair sur blanc, trop peu contrastée.

Chaque solution a ouvert la page en trois tailles de fenêtre, appelées viewports. Ce sont 390 × 844 px pour un téléphone, 820 × 1180 pour une tablette et 1440 × 900 pour un écran de bureau. Pour le téléphone et la tablette, la solution fait de l'émulation : un navigateur de bureau imite un appareil mobile. Il reprend sa taille d'écran, sa densité de pixels, l'écran tactile et l'identité que le navigateur annonce aux sites.

À chaque taille, la solution ouvre la page, fait une capture pleine page, lance un audit et clique sur chaque bouton. Elle relève enfin la console, le journal où le navigateur écrit les erreurs JavaScript, et les requêtes réseau. J'appelle tâche complète cette suite faite aux trois tailles. Chaque solution l'a faite trois fois, et je garde la durée médiane.

Tout tournait sous WSL2, le Linux intégré à Windows, dans des conteneurs Docker : des boîtes isolées qui embarquent un programme et ses dépendances. Ainsi, chaque solution avait la bonne version de Node, le programme qui exécute JavaScript hors du navigateur.

Une limite compte pour lire la suite : l'audit n'est pas fait par Claude. C'est un petit programme JavaScript que j'injecte dans la page, le même partout. Il cherche les débordements, les boutons de moins de 44 px, les images sans texte, les contrastes faibles et les blocs coupés. Il lit aussi les hauteurs en vh du CSS. D4 n'est donc repéré qu'en lisant le CSS, jamais à l'écran. Les défauts trouvés sont les mêmes partout, sauf quand le navigateur diffère : ce chiffre ne départage pas les solutions.

Autre biais : la page décrit elle-même certains défauts. Son texte annonce « huit défauts semés », et le bloc des tarifs écrit qu'il déborde sur 390 px. Mon audit ne lit pas ce texte. Un Claude qui lirait l'arbre d'accessibilité recevrait, lui, ces indices.

Un second banc a servi côté Windows de la même machine, pour l'extension Chrome et pour un contrôle de Playwright MCP en vraie session. Ses chiffres sont toujours signalés « côté Windows ». Durées et tokens ne s'y comparent pas à ceux du banc WSL.

L'encadré ci-dessous dit ce qui a été mesuré, et ce qui ne l'a pas été. C'est le même principe que le registre de preuves de mon article sur l'observabilité d'une API Go.

Trois choses sont publiées : la page, son jumeau sans défaut, et un banc Playwright qui les passe sur trois moteurs et trois tailles d'écran. Le code est dans le dépôt claude-browser-eyes-bench (commit 0aa489b). Une commande suffit, sans installer Node ni navigateur : docker compose run --rm --build bench. Le même dépôt sert la page sur 127.0.0.1:8099 (docker compose up site) pour que tu essaies ton propre outil dessus.

Playwright MCP : Claude explore la page lui-même

Playwright est une bibliothèque de Microsoft : du code prêt à l'emploi qui pilote trois navigateurs. Ce sont Chromium (la base de Chrome), Firefox et WebKit (la base de Safari). Dans cet article, j'appelle ces trois navigateurs de base les moteurs. La version 1.64.1 de Playwright, sortie le 14 octobre 2026, installe Chromium 156, Firefox 157 et WebKit 27.2.

La première façon de s'en servir passe par un serveur MCP. C'est un petit programme qui donne à Claude des outils, c'est-à-dire des actions prêtes à appeler. MCP, pour Model Context Protocol, est le format standard qui relie ces outils à l'assistant. J'ai raconté comment construire un serveur MCP en Go dans un autre article.

Le serveur de Playwright propose par exemple browser_navigate pour ouvrir une page, browser_snapshot pour lire l'arbre d'accessibilité et browser_take_screenshot pour la capture. Claude les appelle quand il veut, sans écrire de code. La commande d'installation vient du README officiel :

claude mcp add playwright npx @playwright/mcp@latest

La commande se lit en trois morceaux :

• claude mcp add ajoute un serveur MCP à la configuration de Claude Code ;
• playwright est le nom que tu donnes à ce serveur ;
• npx @playwright/mcp@latest est la commande qui le lance : npx télécharge le paquet au premier lancement, et @latest prend la dernière version.

Ce serveur a sa propre numérotation, distincte de celle de la bibliothèque : j'ai mesuré sa version 0.0.83. Pour qu'une mise à jour ne change pas ses réponses du jour au lendemain, remplace @latest par @0.0.83. Depuis sa version 1.62, la bibliothèque Playwright contient aussi ce serveur, lancé par npx playwright mcp. Les deux exposent les mêmes 25 outils.

Dans mon conteneur, le serveur a d'abord refusé de démarrer. Par défaut, il cherche Google Chrome dans /opt/google/chrome, que mon conteneur n'a pas. Sur une machine où Chrome est installé, tu ne verras sans doute pas cette erreur. Sinon, deux remèdes ont marché. Le premier : indiquer un Chromium existant avec --executable-path. Le second : télécharger Chrome for Testing, la version de Chrome faite pour les tests (674 Mo).

Sur le banc WSL, le serveur fait la tâche complète en 6,7 s, et ses réponses texte pèsent 33 237 octets. Plus de la moitié, 19 261 octets, vient d'un seul outil : browser_evaluate renvoie le code de mon audit avec son résultat. Ce chiffre gonfle donc le coût du serveur MCP face aux scripts, qui ne renvoient que le résultat. Les trois captures reviennent en image dans les réponses : 443 692 octets en tout.

Les arbres d'accessibilité, eux, ne sont plus dans les réponses de la version 0.0.83. Le serveur les écrit dans des fichiers du dossier .playwright-mcp/, et la réponse ne contient qu'un lien. Ces fichiers pèsent 18 303 octets si Claude les lit. Exclus aussi ce dossier de ce que Claude explore seul, pour qu'il ne le lise pas par hasard, comme dans mon article sur les tokens.

Reste la liste de ses 25 outils, avec leurs descriptions : 20 296 octets, soit 5,1 k tokens d'après mon estimation. Claude Code a une recherche d'outils, active par défaut, qui peut ne donner à Claude que leurs noms et chercher le détail à la demande. Je n'ai pas mesuré ce qu'il en charge vraiment sur le banc WSL. Côté Windows, en vraie session, le journal montre environ 8 200 tokens de contexte au chargement des 25 outils.

Côté Windows toujours, Claude a appelé ce serveur lui-même sur toute la tâche. Le contexte a grossi d'environ 14 000 tokens, dont 5 700 écrits par Claude, sans lire les captures. Chaque réponse y faisait 150 à 700 caractères. Le serveur écrivait arbres, console et captures dans des fichiers. Les captures, demandées avec un nom de fichier, ne revenaient pas en image. C'est très économe, mais pour voir une capture, Claude doit ensuite ouvrir le fichier PNG : une étape de plus. La requête 404 du chargement apparaissait dès l'ouverture de la page.

Pour le mobile, lance le serveur avec --device "iPhone 15". L'outil browser_resize change bien la taille de la fenêtre aux trois tailles, mais ni l'écran tactile ni l'identité de téléphone.

• Point fort : Claude explore seul, page après page. Il clique et lit sans que tu écrives une ligne.
• Point faible : le serveur est en version 0.0.x, une numérotation d'avant la version stable. Cinq versions sont sorties entre le 6 août et le 28 septembre 2026, et ses sorties peuvent changer.
• Quand le prendre : pour explorer une page avec Claude, à la main, sans écrire de code.

Playwright en ligne de commande ou en script : Claude lit moins

Playwright CLI : les mêmes gestes, en commandes

La CLI, pour command line interface, fait la même chose avec des commandes tapées dans le terminal. Elles s'appellent open, goto, resize, snapshot, screenshot ou console. Claude Code sait déjà lancer des commandes, donc aucun serveur n'est à brancher. L'installation, d'après la documentation officielle :

npm install -g @playwright/cli@latest
playwright-cli install --skills

La première ligne installe la commande playwright-cli pour toute la machine : c'est le sens de -g, pour « global ». La seconde installe des skills : des fiches d'instructions que Claude Code ne lit en entier qu'au moment où il en a besoin. Dans mes essais, la commande équivalente de Playwright 1.64.1 a écrit trois skills, 108 851 octets en tout. Seule leur courte description reste chargée en permanence.

Sur la même tâche complète, les réponses de la CLI pèsent 16 818 octets, deux fois moins que celles du serveur MCP. Elle n'a aucune liste d'outils. Comme le serveur, elle écrit les arbres dans des fichiers, 18 303 octets de plus si Claude les lit, et les captures aussi. L'écart vient surtout de l'audit : la CLI rend 1 145 octets pour lui, le serveur MCP 6 416, car il renvoie aussi le code.

La documentation de Playwright le dit en anglais : « CLI commands avoid loading large tool schemas and verbose accessibility trees ». Autrement dit, la CLI évite de remplir le contexte avec de longues descriptions d'outils et des arbres d'accessibilité bavards.

• Point fort : moins de texte que le serveur MCP, pour les mêmes gestes et les trois moteurs.
• Point faible : chaque commande relance Node, soit environ 0,5 s. La tâche complète prend 22 s.
• Quand la prendre : pour tester un site sur plusieurs tailles et plusieurs moteurs, quand chaque token compte.

Playwright en script : Claude écrit le test, puis lit un rapport

Troisième voie : Claude écrit un script Playwright, le lance, et ne lit que le rapport final. L'installation, d'après la documentation :

npm install -D @playwright/test@latest
npx playwright install --with-deps

La première ligne ajoute Playwright à ton projet comme dépendance de développement : c'est le sens de -D. La seconde télécharge les navigateurs, et --with-deps ajoute les bibliothèques système dont ils ont besoin. Ces bibliothèques demandent les droits d'administration de la machine : c'est pour cela que j'ai utilisé l'image Docker officielle de Playwright.

Voici le cœur de la tâche complète de mes essais. Le script pose quatre écouteurs sur la page, du code qui se déclenche à chaque événement. Ils guettent les erreurs de console, les erreurs JavaScript, les réponses en erreur et les requêtes échouées. Il ouvre ensuite la page, prend une capture pleine page, puis injecte l'audit (la variable AUDIT) :

  const ev = { console: [], pageerrors: [], responses404: [], requestfailed: [] };
  page.on('console', m => { if (['error', 'warning'].includes(m.type())) ev.console.push(m.type() + ': ' + m.text()); });
  page.on('pageerror', e => ev.pageerrors.push(String(e.message || e)));
  page.on('response', r => { if (r.status() >= 400) ev.responses404.push(r.status() + ' ' + r.url()); });
  page.on('requestfailed', r => ev.requestfailed.push(r.url()));
  await page.goto(url, { waitUntil: 'load' });
  await page.screenshot({ path: shotPath, fullPage: true });
  const audit = await page.evaluate(`(${AUDIT})()`);

À remarquer : les écouteurs sont posés avant page.goto, qui ouvre la page. La requête 404 de D7 part pendant le chargement, et un écouteur posé après risquerait de la rater. Rien de tout cela ne passe par le contexte de Claude. Le script range tout dans l'objet ev, et Claude lit seulement le rapport JSON : 2 753 octets.

Avec WebKit, le script fait la tâche complète en 3,7 s, avec Firefox en 4,4 s, avec Chromium en 7,2 s. Chromium y perd 3 s sur un seul clic, que je décris maintenant.

En émulation iPhone, sur cette page qui déborde, le clic sur le bouton « Envoyer » n'aboutit pas. Playwright attend que le bouton soit prêt, et son journal reste bloqué à l'étape « faire défiler jusqu'à l'élément ». Au bout de 3 s, il abandonne. La cause exacte n'est pas établie. Trois des solutions Chrome présentées plus bas ont le même souci. WebKit et Firefox, eux, cliquent normalement.

Un autre piège de l'émulation iPhone dans Chromium touche la mesure du débordement. innerWidth est la largeur que la page croit avoir. Sur une page qui déborde, Chromium la porte à 616 px au lieu de 390. Un test qui compare la largeur du contenu à innerWidth ne voit donc plus rien. Il faut comparer à screen.width, la largeur de l'écran imité. WebKit, lui, garde 390.

• Point fort : le moins de texte à lire, les trois moteurs, et une vérification qu'on relance à chaque modification.
• Point faible : Claude doit écrire du code et le relancer. Il n'explore pas la page à sa guise.
• Quand le prendre : pour vérifier un site sur mobile, tablette et bureau, dans plusieurs moteurs, à chaque changement.

Chrome seul : DevTools MCP et connexion CDP

Les solutions suivantes ne pilotent que Chrome ou Chromium. Toutes passent par le CDP, le Chrome DevTools Protocol. Les DevTools sont le panneau de développement de Chrome, celui qu'ouvre la touche F12. Le CDP est le canal par lequel ils parlent au navigateur.

Un Chrome lancé avec l'option --remote-debugging-port=9222 ouvre ce canal sur le port 9222, une porte d'entrée numérotée sur la machine. On l'appelle alors un Chrome de débogage. La documentation de Chrome DevTools MCP rappelle que tout programme de la machine peut alors piloter ce navigateur. Chrome exige d'ailleurs un profil séparé pour ouvrir ce port, c'est-à-dire un dossier à part pour l'historique, les cookies et les sessions.

Chrome DevTools MCP : le plus riche, le plus lourd

Google publie son propre serveur MCP, Chrome DevTools MCP, en version 1.12.0 au 22 octobre 2026. La commande pour Claude Code vient de sa page de dépannage :

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

L'option --scope user inscrit le serveur pour tous tes projets, et pas seulement pour le dossier courant. Le README propose aussi une installation en plugin, par /plugin marketplace add ChromeDevTools/chrome-devtools-mcp.

Dans mon conteneur, le serveur a d'abord échoué comme celui de Playwright : il cherche Google Chrome. Voici la commande qui a marché, avec le Chromium de l'image Playwright. Cette configuration n'est pas officielle : le serveur ne prend en charge que Chrome et Chrome for Testing.

node …/chrome-devtools-mcp.js --headless --isolated --no-usage-statistics --no-performance-crux --executablePath /ms-playwright/chromium-1248/chrome-linux64/chrome --chromeArg=--no-sandbox

Deux options comptent pour toi. --no-usage-statistics coupe les statistiques d'usage, que le serveur envoie à Google par défaut. --no-performance-crux évite d'envoyer les adresses des pages mesurées à une base de mesures de Google. Le reste est propre à mon conteneur : pas de fenêtre, un profil jetable, et le chemin du Chromium.

À mon lancement, ce serveur a chargé 32 outils. Parmi eux : un audit de qualité de page, des mesures de performance et le détail des requêtes réseau. Leur liste pèse 28 928 octets (7,2 k tokens estimés). Sur la tâche complète, ses réponses texte font 17 097 octets, moins que Playwright MCP, mais ses trois captures pèsent 1,7 Mo.

La tâche complète prend 25 s, dont 20 s dans quatre clics bloqués en émulation mobile, 5 s chacun. Pour des tâches simples, l'option --slim réduit le catalogue à trois outils : naviguer, exécuter du JavaScript, capturer. Je ne l'ai pas testée.

• Point fort : la profondeur de débogage. Réseau, console, performance, audit : tout y est.
• Point faible : Chrome seul, la plus longue liste d'outils, les captures les plus lourdes, et des statistiques envoyées par défaut.
• Quand le prendre : pour déboguer une page précise, son réseau, sa console ou ses performances.

connectOverCDP : se brancher sur un Chrome déjà ouvert

Playwright sait aussi se connecter à un Chrome de débogage déjà lancé, au lieu d'ouvrir le sien. L'intérêt : ce Chrome peut garder des sessions connectées, par exemple sur un site qui demande un mot de passe. L'exemple de la documentation officielle tient en trois lignes :

const browser = await playwright.chromium.connectOverCDP('http://localhost:9222');
const defaultContext = browser.contexts()[0];
const page = defaultContext.pages()[0];

La première ligne se branche sur le port 9222. Les deux suivantes reprennent l'onglet déjà ouvert, au lieu d'en créer un. La documentation prévient que cette connexion est de fidélité « significantly lower », nettement plus faible que le protocole propre à Playwright. Elle ne marche aussi qu'avec Chromium.

Dans mes essais, Chrome tournait dans son propre conteneur. La connexion prend 73 ms. La tâche complète prend 11,7 s, dont 3 s sur le même clic bloqué qu'avec le script. Un piège de réseau : se connecter par le nom du conteneur renvoie une erreur 500. Le message est Host header is specified and is not an IP address or localhost. Chrome n'accepte qu'une adresse IP ou localhost.

Le piège du Chrome de débogage : trois onglets saturés, 60 secondes d'attente

J'ai ouvert trois onglets très lourds dans le Chrome de débogage avant de m'y connecter. Chaque onglet contient 30 000 éléments, une animation permanente sur un dessin flouté et une requête réseau toutes les 200 ms. La page est si occupée qu'elle ne répond plus à rien d'autre : je l'appelle un onglet saturé.

Résultat : connectOverCDP abandonne au bout de 60 s, trois fois sur trois. Avec dix onglets saturés, même chose. Le navigateur, lui, répond toujours. Interrogé directement par le CDP, il donne sa version en 1 ms et la liste des onglets en 1 à 2 ms.

Le navigateur et la page ne répondent pas au même rythme. Les questions posées au navigateur passent. Une question posée à une page saturée, même « calcule 1+1 », reste sans réponse pendant 30 s. Or Playwright attend des réponses des pages pour se connecter. Chrome DevTools MCP, branché sur le même navigateur, bloque aussi : sa liste des pages expire.

Avec trois onglets moyens (30 000 éléments, animation légère), la connexion passe en 294 ms, et en 334 ms avec dix. Le nombre d'onglets compte donc peu. Ce qui bloque, c'est une page qui sature le navigateur.

Je n'ai pas testé de remède. Le plus simple serait de fermer les onglets lourds avant de se connecter. On peut aussi garder un profil Chrome dédié aux tests, avec peu d'onglets.

Go : chromedp oui, rod et playwright-go non

Go est un langage de programmation de Google. Pour un projet en Go, trois bibliothèques pilotent un navigateur. chromedp et rod passent par le CDP, playwright-go par Playwright. Aucune ne fournit de serveur MCP ni d'arbre d'accessibilité prêt à lire : Claude écrit le programme Go, le compile, puis lit ce qu'il imprime.

chromedp, en version 0.21.0 du 11 octobre 2026, est la plus rapide des solutions Chrome. Il fait la tâche complète en 3,9 s, sans aucun clic bloqué. Sa nouvelle version a pourtant changé son API, la liste des fonctions qu'elle offre et leur façon de s'écrire. Voici l'ouverture de la page et la capture dans mon programme d'essai, où vp désigne la taille de fenêtre en cours :

		if err := chromedp.Do(ctx, chromedp.Navigate(url)); err != nil {
			fmt.Println("ECHEC navigate", vp.name, err)
			os.Exit(1)
		}
		png, err := chromedp.Run(ctx, chromedp.FullScreenshot(100))
		if err != nil {
			fmt.Println("ECHEC screenshot", err)
			os.Exit(1)
		}

À remarquer : chromedp.Run rend maintenant la capture comme résultat, dans la variable png. L'ancienne écriture passait une zone à remplir, FullScreenshot(&buf, 100), et ne compile plus. Le premier code de mes essais, écrit avec l'ancienne API, a échoué. Il a fallu deux essais avec le guide de migration fourni avec chromedp. Un modèle qui a appris l'ancienne API écrira du code cassé : donne-lui ce guide.

Les deux autres sont à éviter aujourd'hui :

• rod a marché du premier coup, mais sa dernière version date du 12 juillet 2024. Ses clics bloquent en émulation mobile, d'où 19,5 s pour la tâche complète ;
• playwright-go ne s'installe plus tel quel. Ses trois dernières versions sont refusées par la commande d'installation de Go, et la précédente cherche un pilote introuvable.

Le pilote est le programme Playwright que playwright-go fait tourner en coulisse : la bibliothèque Go ne fait que lui transmettre les ordres. Une fois ce pilote reconstruit à la main, playwright-go a trouvé les huit défauts en 4,7 s avec WebKit 26.4. Le bricolage marche, mais personne ne veut le maintenir dans un projet.

L'extension Claude in Chrome, essayée côté Windows

Le verdict d'abord : l'extension sert à travailler dans tes vraies sessions, pas à tester une mise en page mobile. Claude in Chrome est une extension de navigateur d'Anthropic qui pilote ton vrai Chrome. Elle partage ton profil, donc tes sessions. D'après la documentation, Claude peut accéder à « any site you're already signed into » : tout site où tu es déjà connecté.

L'extension demande la version 1.0.36 ou plus, un abonnement Anthropic direct (Pro, Max, Team ou Enterprise), puis claude --chrome. La documentation est nette : « Chrome integration isn't supported in Windows Subsystem for Linux (WSL) ». Je l'ai donc essayée côté Windows, avec l'extension 1.0.102 et Chrome 155.0.8059.86.

Ce qu'elle fait bien :

• elle agit dans ton vrai profil, avec tes sessions ouvertes ;
• elle a relevé le débordement à 390 px, les cartes coupées, l'erreur au clic, la requête 404, l'image sans texte et les petits boutons.

Ce qu'elle fait mal :

• la taille de fenêtre : l'outil de redimensionnement répond « Successfully resized », mais la page garde sa largeur de 2 319 px ;
• le mobile : ni écran tactile ni identité de téléphone. Le seul contournement est une iframe, une page affichée dans la page, large de 390, 820 puis 1440 px ;
• la console : l'erreur 404 du chargement n'y apparaît pas. Elle n'est que dans le journal réseau, qui mélange les requêtes des autres extensions (18 sur 22) ;
• les captures : la partie visible seulement, jamais la page entière ;
• une page piégée exprès : un bouton dans un shadow DOM, une sous-page qu'un composant isole du reste, reste invisible. Une iframe d'un autre domaine reste illisible.

Le coût d'une page longue est le point le plus net. Sur une page de 199 902 caractères de texte, la lecture est tronquée à 50 000 caractères par défaut. J'ai demandé 200 000 caractères sur les 258 819 de l'arbre complet, plus le texte de la page. D'après le journal de la session, cette seule lecture a ajouté environ 110 000 tokens au contexte.

L'enregistrement en GIF a capturé une seule image pour trois actions faites une par une, et aucune quand elles étaient envoyées en un seul lot. Surtout, Claude ne reçoit qu'un message du type « Captured 1 frame », jamais le GIF. Le GIF est un document pour un humain, pas des yeux pour Claude. Je n'ai pas testé son export.

Sur ce banc, l'extension et Playwright ont trouvé les mêmes défauts : 6 sur 8. D5 est absent à juste titre, car ce Chrome comprend calc-size(), et D4 n'y est pas testable. Tous deux ont raté le léger chevauchement du titre de carte (D2) et l'absence d'espace entre les boutons (D3). Surtout, tailles et contraste (2,32:1 pour la légende) n'ont été trouvés que par des scripts JavaScript écrits pour l'occasion. Les fonctions de base des deux solutions, arbre, console et réseau, ne mesurent ni l'un ni l'autre.

Le temps de réaction de l'extension, lu dans le journal, est de 4,7 s en médiane sur 13 appels simples. Le plus lent des 27 appels mesurés a pris 33,7 s. Ce délai est vu de bout en bout par Claude : extension, Chrome, relais de l'outil et attente éventuelle d'une autorisation. Il ne se compare pas aux temps de réaction des serveurs MCP, mesurés plus bas sans le modèle ni Claude Code.

Toute l'étude côté Windows, extension, serveur MCP et échanges compris, a coûté 4,42 $. Elle a produit 79,8 k tokens en sortie, avec 24,1 millions lus en cache et 300,9 k écrits en cache. Ce coût n'est attribuable à aucune solution en particulier. Il est dominé par la relecture du contexte en cache. La lecture de la page longue a gonflé ce contexte d'un coup, et il a été relu à chaque requête suivante.

Je ne note pas l'extension dans le tableau de notes plus bas, puisqu'elle n'a pas tourné sur le même banc. Elle agit avec tes vrais comptes, ce qui demande de la prudence.

Safari : ce que WebKit attrape, et ce qu'il rate

Safari repose sur le moteur WebKit. Parmi les solutions mesurées, seule la famille Playwright le lance, playwright-go compris. La documentation de Playwright précise que son WebKit est construit depuis les sources de WebKit, avec des correctifs : ce n'est pas Safari. Playwright 1.64.1 l'installe dans un dossier webkit-2370. Ce numéro désigne une version de construction, étiquetée WebKit 27.2, pas une version de Safari.

Ce qu'il attrape : un écart de moteur

Le défaut D5 est fait pour cela. Le panneau déclare deux hauteurs à la suite, extraites telles quelles de la feuille de style :

.panneau{height:40px;height:calc-size(auto, size + 24px);padding:12px;background:#d7f0d7;border:1px solid #4a4}

Un navigateur qui comprend calc-size() garde la seconde hauteur, qui suit le texte. Un navigateur qui ne la comprend pas l'ignore et garde la première, 40 px : c'est le repli. La fonction JavaScript CSS.supports dit si un navigateur comprend une règle : Chromium comprend calc-size(), ni WebKit 27.2 ni Firefox 157. Sur l'écran de 390 px, le panneau mesure 146 px dans Chromium et 40 px dans WebKit, où le texte déborde sur la section suivante.

Sur la capture entière, 7,86 % des pixels diffèrent entre Chromium et WebKit à 390 px. Les seules différences de polices et de lissage en expliquent 3 à 5 %. Le reste vient de D5, qui décale tout le bas de la page.

Ce qu'il rate : tout ce qui vient de l'iPhone lui-même

Sur un vrai iPhone, la barre d'adresse de Safari se replie quand on fait défiler la page, et la hauteur visible change. CSS a trois unités pour cela : 100svh vaut la hauteur avec la barre dépliée, 100lvh avec la barre repliée, et 100dvh suit la barre. 100vh vaut la hauteur avec la barre repliée : quand la barre est dépliée, le bas du bandeau de D4 passe dessous.

Le WebKit de Playwright tourne sur Linux, dans une fenêtre de bureau. Tout ce qui vient du téléphone, et non du moteur, lui échappe :

• la barre d'adresse dynamique : avec le profil iPhone 15, les quatre unités valent 659 px, la hauteur de la fenêtre. Aucune barre n'est simulée, et D4 reste invisible ;
• la zone de sécurité, la marge que l'iPhone réserve autour de l'encoche et de la barre d'accueil : env(safe-area-inset-bottom) vaut 0 ;
• le zoom automatique de Safari sur un champ de formulaire écrit en petit. Avec un champ en 12 px, le zoom reste à 1 ;
• l'identité du téléphone : navigator.platform annonce Linux x86_64, maxTouchPoints vaut 0, et les polices ne sont pas celles d'Apple.

Les événements tactiles, eux, marchent : un toucher simulé déclenche bien touchstart, touchend puis click. Pour D4, il reste deux moyens : chercher 100vh dans le CSS, ou ouvrir la page sur un vrai iPhone.

Pour iOS réel, deux voies existent, et je n'en ai testé aucune. La première est un vrai iPhone branché à un Mac, ou le simulateur de Xcode, qui demande aussi un Mac. La seconde est un service en ligne qui loue de vrais iPhone pilotables à distance, certains avec Playwright.

Le tableau de notes : quelle solution pour quel travail

Commençons par ce que chaque solution fait lire à Claude pendant la tâche complète, sur le banc WSL, hors images. Pour les deux serveurs MCP, j'ajoute la taille de leur liste d'outils, une estimation haute puisque Claude Code peut n'en charger qu'une partie.

Le second coût est le temps. Quand Claude appelle un outil, il attend sa réponse avant de décider de la suite. J'appelle temps de réaction la durée médiane d'un appel d'outil, sur trois passes de 30 à 41 appels, sur le banc WSL.

Le tableau le met à côté du texte lu. Chrome DevTools MCP y apparaît deux fois. « Lancé seul » veut dire qu'il démarre son propre Chromium. « Branché » veut dire qu'il se connecte à un Chrome de débogage. Je n'ai pas totalisé le texte de ce second cas. Le script n'a pas de temps de réaction, car Claude le lance une seule fois.

Le temps de réaction est celui de l'outil, pas celui de Claude. Claude doit en plus lire chaque réponse et choisir l'appel suivant, ce que je n'ai pas mesuré sur ce banc. Les clics bloqués en émulation mobile comptent dans la tâche complète, pas dans le temps de réaction. Claude explore lui-même avec trois solutions : Playwright MCP, Chrome DevTools MCP et la CLI. De ces trois, la CLI donne le moins de texte, mais réagit le plus lentement.

Le texte et le temps ne sont que deux critères. J'ai noté les huit solutions de 0 à 10, 10 étant le mieux, sur neuf critères :

• installation (facile ou non), frugalité en tokens, interactivité (explorer sans écrire de code) ;
• moteurs (WebKit et Firefox en plus de Chromium), fiabilité de l'émulation mobile, vitesse de la tâche complète ;
• stabilité (aucun échec, aucun blocage), profondeur de débogage, maintenance du projet (versions récentes, installation qui marche).

Ces notes sont mon jugement, appuyé sur les chiffres de cet article : ce ne sont pas des mesures. Les défauts trouvés n'y entrent pas, puisque mon audit les trouve tous, pour toutes les solutions.

Une note se lit avec son chiffre. Les 9 en tokens viennent du rapport de 2,8 Ko. Le 3 de DevTools MCP en vitesse vient des 25 s. Le 4 de playwright-go en maintenance vient de son pilote introuvable, et le 3 de rod de sa dernière version en 2024.

Le classement ne suffit pas pour choisir. Voici quelle solution prendre, selon le travail, avec la raison :

• Tester un site sur mobile, tablette et bureau, avec WebKit : Playwright en script, ou la CLI avec ses skills. Ce sont les moins chers à lire, et ils lancent les trois moteurs.
• Explorer une page avec Claude, sans écrire de code : Playwright MCP. Sur le banc WSL, sa tâche complète a renvoyé 8,3 k tokens de texte, dont plus de la moitié d'écho de mon audit.
• Déboguer le réseau, la console ou les performances d'une page : Chrome DevTools MCP, le plus riche et aussi le plus lourd. À réserver à ce cas.
• Travailler sur des pages où tu es connecté : connectOverCDP vers un Chrome de débogage dédié, avec un profil propre et peu d'onglets. Ou l'extension Claude in Chrome, hors WSL.
• Écrire un test dans un projet Go : chromedp, avec son guide de migration sous la main. Pas rod ni playwright-go.
• Vérifier Safari sérieusement : Playwright WebKit pour les écarts de moteur, puis un vrai iPhone pour tout le reste.

Conclusion

Les huit solutions ont trouvé les mêmes défauts : 7 sur 7 dans Chromium, où D5 n'existe pas, 8 sur 8 dans WebKit et Firefox. Ce n'est pas leur mérite. Mon audit cherchait à leur place, et il ne repérait D4 qu'en lisant le CSS. Leur vraie différence se situe avant : qui regarde la page, et combien coûte le fait de la montrer. Un script regarde à la place de Claude et lui rend 2,8 Ko. Un serveur MCP lui montre tout, avec des dizaines de Ko de texte et des captures.

Le défaut le plus connu de l'iPhone, le bouton caché par la barre de Safari, aucune des huit ne l'a vu à l'écran. Aucune solution ne peut montrer à Claude ce que son moteur ne simule pas. Avant de choisir, mieux vaut donc savoir ce qu'on cherche, et sur quel appareil le défaut existe vraiment.

Sources

Documentation officielle consultée le 28 octobre 2026 :

• Playwright MCP, README : github.com/microsoft/playwright-mcp
• Playwright CLI : playwright.dev/docs/getting-started-cli
• Playwright, installation : playwright.dev/docs/intro
• Playwright, navigateurs et WebKit : playwright.dev/docs/browsers
• Playwright, connectOverCDP : playwright.dev/docs/api/class-browsertype
• Chrome DevTools MCP : github.com/ChromeDevTools/chrome-devtools-mcp
• Claude Code avec Chrome : code.claude.com/docs/en/chrome
• Claude Code et MCP, recherche d'outils : code.claude.com/docs/en/mcp
• Unités vh, svh, lvh, dvh : developer.mozilla.org/en-US/docs/Web/CSS/length
• chromedp : pkg.go.dev/github.com/chromedp/chromedp