Playwright Agent CLI

Ce que c'est

Playwright Agent CLI (`@playwright/agent-cli`) est un binaire officiel publié par l'équipe Playwright (Microsoft) qui expose le contrôle d'un navigateur — Chromium, Firefox, WebKit — à un agent IA via un protocole inspiré de MCP. La CLI tourne en parallèle de l'agent ; l'agent s'y connecte pour cliquer, attendre des sélecteurs, faire des captures, vérifier du texte.

Le second pilier officiel : Playwright Skills (`@playwright/skills`), un set de skills installables côté agent qui lui apprennent comment piloter la CLI efficacement — patterns d'attente, stratégies de sélection, gestion des timeouts, manipulation des screenshots. Sans ces skills, l'agent doit tout réinventer ; avec, le pattern d'usage est cadré.

Pourquoi je m'y suis mis

Sur mes projets, la QA visuelle est un point de friction. Tester localement un composant qui dépend de scroll, hover, layout responsive, c'est long en manuel et chiant à automatiser sans tooling. Playwright Agent CLI déplace le test dans la conversation : pas de switch d'outil, pas de fichier de test séparé à écrire, l'agent click et observe.

Trois raisons concrètes. D'abord, c'est officiel Microsoft, donc maintenu — pas un wrapper communautaire qui peut disparaître. Ensuite, ça s'intègre nativement avec Claude Code via la skill associée, pas de tuyauterie manuelle à monter. Enfin, ça remplace 80% des tests e2e que j'écrivais manuellement pendant le dev — les tests Playwright finaux deviennent un export du flow validé en conversation.

Comment ça marche

Installation en deux temps. La CLI globale via npm, démarrée en daemon dans un terminal dédié. Puis la skill côté Claude Code, qui charge automatiquement le contexte d'usage.

# CLI (terminal dédié)
npm install -g @playwright/agent-cli
playwright-agent serve

# Skill (Claude Code)
claude skill install @playwright/skills

Une fois la CLI lancée, l'agent y accède via un protocole de communication. Concrètement, dans Claude Code, tu dis « ouvre https://localhost:3000, clique sur le bouton Contact et dis-moi ce que tu vois ». L'agent pilote la CLI, screenshot la page, et te répond en analysant l'image. Tout depuis la même conversation.

Cas d'usage concrets

Cinq cas où ça change la vie au quotidien sur un projet React/Next.js.

• Validation visuelle pendant une refonte UI. Je modifie un composant, je demande à l'agent : « navigue sur /pricing, screenshot les 3 cards de prix, dis-moi si l'espacement vertical est cohérent ». L'agent répond en regardant l'image, je corrige, on itère.
• Regression catcher entre 2 commits. Avant de merger une PR de refonte CSS, l'agent screenshot les 5 routes clé avant et après — si quelque chose a bougé sans intention, on le voit.
• Smoke prod post-deploy. Après chaque release, l'agent visite les 3 routes critiques (home, contact, page de checkout) et vérifie qu'elles affichent le bon contenu. Pas besoin de monter un environnement de test parallèle.
• Tests e2e cross-browser pilotés en langage naturel. « Refais le même flow contact sur Firefox, puis WebKit, dis-moi si quelque chose diverge ». L'agent itère sur les 3 navigateurs sans que j'aie à écrire 3 fichiers de test.
• Debugging visuel guidé. « Le formulaire /contact est cassé en prod, regarde et dis-moi pourquoi ». L'agent screenshot, analyse l'erreur React dans la console, propose un fix. Beaucoup plus rapide qu'un aller-retour avec le support.

Le pattern commun : la QA n'est plus un step séparé après le dev, c'est le dialogue lui-même.

Limites observées à ce stade

Trois limites visibles à ce stade du projet perso. D'abord, les sélecteurs complexes — shadow DOM, iframes imbriqués, composants custom non standards — nécessitent parfois une intervention manuelle. La skill aide mais ne fait pas de miracle sur un widget tiers mal foutu.

Ensuite, l'agent peut sur-screenshooter et exploser le contexte conversationnel. Chaque image consomme des tokens lourds. Je n'ai pas encore trouvé un pattern stable pour limiter ça automatiquement — pour l'instant je précise systématiquement « screenshot seulement la zone du formulaire ». Enfin, les flows authentifiés sensibles (login client réel, paiement) demandent une stratégie de sandbox dédiée que je n'ai pas encore mise en place.