Installer la skill Claude Code webapp-testing proprement

Une skill qui pilote Chromium

Samedi soir, je tombe sur une discussion à propos d'une skill récente d'Anthropic qui donne à Claude Code le contrôle d'un vrai navigateur. Pas une simulation, pas un parser HTML : une instance Chromium qu'il pilote via Playwright pour tester ton app en local pendant que tu codes.

Ça s'appelle webapp-testing. C'est officiel, c'est dans le repo anthropics/skills, et selon les blogs récents elle se chope ~117k installs par semaine. C'est l'une des skills officielles les plus utilisées du moment.

Le concept c'est simple : au lieu d'écrire des scripts Playwright à la main, tu décris ce que tu veux tester en langage naturel, et Claude écrit + exécute le script dans un vrai browser. Tu peux te logger à la main, puis lui passer la main. Il prend des screenshots, lit le DOM, capture les logs console, debug les flows authentifiés. Le genre de truc qu'aucune analyse de code statique ne peut faire.

J'ai voulu l'installer. Et là, première surprise : aucun blog que j'ai lu ne donne la bonne méthode d'install. Tous proposent un truc qui pollue le système ou qui marchera deux semaines avant de péter.

Voici comment je l'ai installée proprement, avec un venv dédié, sans sudo pip install, sans pipx mal utilisé.

Le problème avec les méthodes habituelles

Playwright pour Python en 2026, le consensus officiel est clair :

1. Jamais pip install system-wide. PEP 668 bloque ça par défaut sur Ubuntu, Debian, Fedora et la plupart des distros modernes. Tu te prends un error: externally-managed-environment et c'est tant mieux - ça pollue rien.
2. Pas pipx. pipx est conçu pour les CLI standalone. Or Playwright s'utilise comme librairie importée (from playwright.sync_api import ...). pipx isole tellement bien le truc que tu peux pas l'importer depuis un script externe. Erreur classique, beaucoup la font.
3. Toujours --with-deps sur Linux quand tu installes les browsers. Sinon t'as Chromium qui crashe avec des erreurs cryptiques sur des .so manquants - libs audio, fonts, rendering. Le --with-deps lance apt install derrière (donc sudo demandé), mais c'est ça la bonne route.

La best practice pour un projet Playwright classique c'est : venv par projet. Mais pour une skill Claude Code globale, le venv-par-projet ça marche pas - Claude appelle la skill depuis n'importe quel répertoire, il a aucun moyen de savoir quel venv activer.

La solution : venv dédié dans le dossier de la skill

Le pattern qui tient la route : un venv embarqué directement à l'intérieur du dossier de la skill, et un patch dans le SKILL.md pour dire à Claude "utilise CE python, pas le système".

Comme ça :

• La skill est autonome, elle embarque sa propre stack.
• Aucune pollution du Python système.
• Si je désinstalle la skill (rm -rf ~/.claude/skills/webapp-testing), tout part proprement, y compris les 600 MB de Chromium.
• Ça survit aux upgrades de python système, aux changements de distro, aux migrations.

Voilà comment on la pose.

Workflow d'installation

Étape 1 : récupérer la skill

Le repo officiel anthropics/skills contient plein d'autres trucs (skills documents PDF/DOCX/PPTX, MCP server generator, etc.). On veut juste webapp-testing. Sparse checkout pour pas tout cloner :

cd /tmp
git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/anthropics/skills.git anthropics-skills-tmp
cd anthropics-skills-tmp
git sparse-checkout set skills/webapp-testing
cp -r skills/webapp-testing ~/.claude/skills/
cd .. && rm -rf anthropics-skills-tmp

Le dossier ~/.claude/skills/webapp-testing/ contient maintenant :

webapp-testing/
├── SKILL.md         # Instructions principales
├── LICENSE.txt
├── examples/        # console_logging.py, element_discovery.py, static_html_automation.py
└── scripts/         # with_server.py (lifecycle multi-serveurs)

À ce stade, Claude Code détecte la skill au prochain démarrage. Mais elle ne marche pas encore - Playwright n'est pas installé.

Étape 2 : venv dédié dans la skill

python3 -m venv ~/.claude/skills/webapp-testing/.venv
~/.claude/skills/webapp-testing/.venv/bin/pip install --upgrade pip
~/.claude/skills/webapp-testing/.venv/bin/pip install playwright

Tout reste contenu dans ~/.claude/skills/webapp-testing/.venv/. Aucun impact sur le Python système. Si je tape python3 dans un terminal, c'est toujours mon Python d'OS, vierge.

Chez moi ça donne Python 3.12.3, pip 26.1, Playwright 1.59.0 (sortie fin avril 2026).

Étape 3 : Chromium + dépendances système

~/.claude/skills/webapp-testing/.venv/bin/playwright install --with-deps chromium

Le --with-deps est critique sur Linux. Il lance derrière un sudo apt install (ou équivalent) pour poser les libs partagées dont Chromium a besoin : libnss3, libatk1.0, libxkbcommon, libgbm, et une vingtaine d'autres. Sans ça, le browser téléchargé crashe au lancement avec une erreur du genre error while loading shared libraries: libnss3.so.

Le download c'est ~280 MB :

• Chrome for Testing 147.0.7727.15 (170 MB) → ~/.cache/ms-playwright/chromium-1217/
• Chrome Headless Shell (112 MB) → ~/.cache/ms-playwright/chromium_headless_shell-1217/

Note : le binaire Chromium est stocké dans ~/.cache/ms-playwright/, pas dans le venv. C'est le défaut Playwright et c'est très bien comme ça - si demain tu veux utiliser Playwright dans un autre projet, tu peux réutiliser le même cache de browsers.

Étape 4 : patcher SKILL.md

C'est l'étape que personne ne mentionne dans les guides en ligne, et c'est pourtant celle qui rend l'install vraiment fonctionnelle.

Par défaut, le SKILL.md dit à Claude "lance les scripts avec python3". Mais python3 c'est le Python système, qui n'a pas Playwright. Donc Claude appelle python3 scripts/with_server.py, ça crash avec ModuleNotFoundError: No module named 'playwright', et il passe la moitié de la session à comprendre pourquoi.

J'ajoute en tête du SKILL.md une section IMPORTANT qui pointe vers le bon interpréteur :

**IMPORTANT — Python interpreter to use**:
This skill ships with its own dedicated venv at
`~/.claude/skills/webapp-testing/.venv` with Playwright + Chromium
pre-installed. **Always invoke scripts with this interpreter**, never
the system `python3` (which won't have Playwright):

\`\`\`bash
~/.claude/skills/webapp-testing/.venv/bin/python scripts/with_server.py --help
~/.claude/skills/webapp-testing/.venv/bin/python /tmp/your_automation.py
\`\`\`

When the helper `with_server.py` invokes child commands, also pass this
interpreter explicitly (e.g. `... -- ~/.claude/skills/webapp-testing/.venv/bin/python your_automation.py`).

Claude lit le SKILL.md à chaque déclenchement de la skill. Cette note tape direct dans son contexte, et il utilise systématiquement le bon python. Plus de ModuleNotFoundError.

Étape 5 : smoke test

Avant de crier victoire, vérifier que Chromium se lance vraiment :

~/.claude/skills/webapp-testing/.venv/bin/python -c "
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    b = p.chromium.launch(headless=True)
    page = b.new_page()
    page.set_content('<h1>hello</h1>')
    print('h1:', page.locator('h1').inner_text())
    b.close()
print('OK')
"

Sortie attendue :

h1: hello
OK

Si tu vois ça, l'install est complète. Si tu te prends un crash sur des libs partagées, c'est que --with-deps n'a pas tourné correctement (souvent : sudo refusé ou apt indisponible). Relance la commande avec sudo explicite.

Pourquoi pas la méthode npx skills add

Plusieurs blogs proposent :

npx skills add https://github.com/anthropics/skills --skill webapp-testing

Ou avec le marketplace plugin :

/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

Ça pose la skill (en gros ce que mon git clone sparse fait), mais ça ne gère pas l'install Playwright. Tu te retrouves avec une skill détectée par Claude Code, qui plante à la première utilisation parce que Python ne trouve pas Playwright. Et là tu lis Stack Overflow pendant 30 minutes.

La méthode "git sparse + venv dédié + patch SKILL.md" prend 5 minutes et marche du premier coup.

Bonus : alternative avec uv

uv (par Astral) est devenu en 2026 la référence pour gérer du Python. Plus rapide que pip (10x sur les installs), gestion native des venvs, scripts auto-dépendances via PEP 723. Si tu l'as déjà installé :

curl -LsSf https://astral.sh/uv/install.sh | sh   # si pas déjà installé

uv venv ~/.claude/skills/webapp-testing/.venv
uv pip install --python ~/.claude/skills/webapp-testing/.venv/bin/python playwright
~/.claude/skills/webapp-testing/.venv/bin/playwright install --with-deps chromium

Le résultat est rigoureusement identique, juste l'install pip va deux fois plus vite. Le patch SKILL.md reste à faire dans tous les cas.

Comment l'utiliser maintenant

Une fois posée, tu interpelles la skill en langage naturel. Quelques exemples qui marchent chez moi :

"Démarre mon dev server Next.js sur le port 3000 et utilise webapp-testing
pour vérifier que la page d'accueil charge sans erreur console."

"Lance webapp-testing sur localhost:5173, prends un screenshot de la page
de login, puis tente de te connecter avec test@example.com/password et
vérifie qu'on arrive bien sur le dashboard."

"Avec webapp-testing, navigue sur le formulaire de checkout et liste tous
les sélecteurs des champs input - je veux écrire un test E2E."

Claude détecte automatiquement la skill (elle apparaît dans la liste interne au démarrage), il appelle ~/.claude/skills/webapp-testing/.venv/bin/python grâce au patch SKILL.md, et il écrit + exécute le script Playwright à la volée.

Le pattern recommandé par la skill

Le SKILL.md officiel donne un decision tree clair :

• App statique (HTML pur) → lecture directe du fichier HTML pour identifier les sélecteurs, puis script Playwright simple.
• App dynamique, serveur déjà lancé → pattern "recon → action" : page.goto(url), page.wait_for_load_state('networkidle'), screenshot/inspection, identification des sélecteurs, exécution.
• App dynamique, serveur à lancer → utiliser le helper scripts/with_server.py qui gère le lifecycle multi-serveurs (frontend + backend en parallèle, par exemple).

La règle la plus importante : toujours wait_for_load_state('networkidle') avant d'inspecter le DOM sur une app dynamique. Sinon Claude lit un DOM mort à mi-rendering et écrit un test qui échoue 1 fois sur 3.

Ce que j'ai appris

La doc officielle Playwright recommande venv mais ne couvre pas le cas "skill globale". C'est moi qui ai dû adapter le pattern. La doc parle de venv-par-projet, ce qui est le bon réflexe en dev classique. Mais pour une skill qui s'invoque depuis n'importe où, le venv embarqué dans la skill elle-même est le seul moyen propre.

Le patch SKILL.md, c'est 90% de la stabilité de l'install. Sans cette note, Claude tombe sur python3 système et crashe. Avec, il utilise systématiquement le bon interpréteur. Une note de 8 lignes change tout.

Les binaires Chromium dans ~/.cache/ms-playwright/, c'est partagé. Si demain tu fais un autre projet avec Playwright (peu importe la méthode d'install), il réutilisera le même cache. Tu télécharges Chromium une seule fois sur ta machine.

--with-deps est non négociable. J'ai voulu sauter le sudo une fois pour aller plus vite, j'ai passé 20 minutes à debug une erreur sur libnspr4.so. Ne le fais pas. Le --with-deps lance un seul apt install, c'est rapide.

Cette skill remplace 80% de mes besoins en MCP Playwright. J'avais avant un setup avec @playwright/mcp configuré comme serveur MCP. C'est plus puissant pour l'exploration interactive (état browser persistant, accessibility tree dans la réponse), mais plus lourd à mettre en place et plus cher en tokens. Pour les tests "vérifie que ce flow marche", la skill webapp-testing est plus directe.

Les limites

C'est un outil d'aide au développement, pas un framework de test E2E pour la prod. Si tu construis une vraie suite de tests E2E avec CI/CD, sharding, retries, allure reports - utilise pytest-playwright dans un projet dédié. La skill Claude Code, c'est pour le quotidien : "j'ai changé ce composant, vérifie vite que rien n'est cassé sur le flow X".

Et bien sûr, tout ce que Claude voit dans le browser (DOM, console output, données de formulaires) part dans l'API Anthropic. À utiliser sur des environnements de dev avec des données de test, pas sur la prod avec des données client réelles.

Pour le reste, c'est devenu mon réflexe quand je touche du frontend. Je code, je dis "vérifie le flow de login", il vérifie en 30 secondes en pilotant Chromium. C'est ce que les tests E2E auraient dû être depuis le début.