Playwright MCP : tester avec l'IA (Claude Code, Copilot, Cursor)

Playwright MCP est le serveur MCP officiel de Microsoft : il donne à un assistant IA comme Claude Code, GitHub Copilot ou Cursor les outils pour piloter un vrai navigateur. L'assistant navigue, clique, remplit des formulaires et lit la page à partir d'instantanés d'accessibilité, sans capture d'écran ni modèle de vision. Pour un testeur, cela permet d'explorer une application en langage naturel puis de transformer cette exploration en test Playwright. Ce guide explique l'installation, un premier scénario complet, la différence avec Playwright CLI et les Test Agents, et les règles à respecter pour garder des tests fiables.

Qu'est-ce que le MCP (Model Context Protocol) ?

Le Model Context Protocol est un protocole ouvert qui standardise la façon dont un assistant IA se connecte à des outils externes. Un « serveur MCP » expose une liste d'outils décrits par un nom, une description et des paramètres ; le « client » (Claude Code, l'agent de GitHub Copilot dans VS Code, Cursor…) les présente au modèle, qui décide lequel appeler et avec quels arguments. Le résultat de chaque appel revient dans la conversation, et le modèle enchaîne l'étape suivante.

Sans MCP, un assistant de code peut écrire un test Playwright, mais il l'écrit « à l'aveugle » : il devine les libellés des boutons, la structure des formulaires et l'enchaînement des pages. Avec un serveur MCP de navigateur, il peut ouvrir l'application, constater ce qui s'affiche réellement, puis écrire le test à partir de ce qu'il a observé.

Qu'est-ce que Playwright MCP ?

Playwright MCP est le serveur MCP maintenu par l'équipe Playwright de Microsoft. Il lance un navigateur avec Playwright et expose des outils comme browser_navigate (ouvrir une URL), browser_snapshot (lire la page), browser_click, browser_type, browser_fill_form, browser_wait_for, browser_take_screenshot, browser_tabs, browser_evaluate, ou encore browser_console_messages et browser_network_requests pour inspecter la console et les appels réseau.

Sa particularité est l'outil browser_snapshot : au lieu d'envoyer une image de l'écran, il renvoie un instantané d'accessibilité structuré, c'est-à-dire l'arbre des éléments avec leur rôle (bouton, lien, champ de saisie, titre), leur nom accessible et leur état. Le modèle n'a donc pas besoin de capacités de vision, et il « voit » la page comme la voient les technologies d'assistance — exactement le point de vue que les bonnes pratiques Playwright recommandent pour écrire des locators robustes.

Comment installer Playwright MCP ?

Le seul prérequis est Node.js, puisque le serveur se lance avec npx. Le navigateur s'ouvre en mode visible par défaut, ce qui est pratique pour suivre ce que fait l'assistant.

Dans Claude Code

claude mcp add playwright npx @playwright/mcp@latest

Le serveur est ensuite disponible dans les sessions Claude Code : il suffit de demander, en français, d'ouvrir une page ou de tester un parcours.

Dans VS Code (mode agent de GitHub Copilot)

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

Les outils browser_* apparaissent alors dans la liste des outils de l'agent Copilot.

Dans Cursor et les autres clients MCP

La plupart des clients acceptent la même configuration JSON standard, à ajouter dans leurs paramètres MCP :

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Les options utiles pour un testeur

Les options s'ajoutent après @playwright/mcp@latest dans la commande ou dans le tableau args :

Premier scénario : explorer une page de connexion puis générer un test

Prenons une application de démonstration qui tourne en local. L'objectif est double : laisser l'assistant explorer le parcours de connexion, puis lui faire écrire un test Playwright en TypeScript à partir de ce qu'il a réellement observé.

Étape 1 : l'exploration

Un prompt précis donne de bien meilleurs résultats qu'une consigne vague. Exemple :

Avec Playwright MCP, ouvre http://localhost:3000/login.
Décris les champs, les boutons et les messages présents sur la page.
Essaie ensuite une connexion avec un mot de passe incorrect
et rapporte le message d'erreur exact affiché.
Ne soumets aucun autre formulaire.

L'assistant appelle browser_navigate, puis browser_snapshot pour lire la page, remplit les champs avec browser_type ou browser_fill_form, clique avec browser_click et relit la page. Vous obtenez un compte rendu des éléments (avec leurs rôles et leurs libellés accessibles) et du comportement constaté — c'est déjà une petite session de test exploratoire documentée.

Étape 2 : la génération du test

À partir de ce que tu as observé, écris tests/connexion.spec.ts
avec Playwright Test en TypeScript : un cas de connexion réussie
et un cas de mot de passe incorrect. Utilise getByRole et getByLabel,
aucun sélecteur CSS, et lis les identifiants dans des variables
d'environnement. Lance ensuite les tests et corrige-les s'ils échouent.

Le résultat attendu ressemble à ceci (l'URL de base est définie dans playwright.config.ts) :

import { test, expect } from '@playwright/test';

test.describe('Connexion', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/login');
  });

  test('un utilisateur valide accède à son tableau de bord', async ({ page }) => {
    await page.getByLabel('E-mail').fill(process.env.TEST_USER_EMAIL!);
    await page.getByLabel('Mot de passe').fill(process.env.TEST_USER_PASSWORD!);
    await page.getByRole('button', { name: 'Se connecter' }).click();

    await expect(page).toHaveURL(/\/dashboard/);
    await expect(page.getByRole('heading', { name: 'Tableau de bord' })).toBeVisible();
  });

  test('un mot de passe incorrect affiche une erreur', async ({ page }) => {
    await page.getByLabel('E-mail').fill(process.env.TEST_USER_EMAIL!);
    await page.getByLabel('Mot de passe').fill('mauvais-mot-de-passe');
    await page.getByRole('button', { name: 'Se connecter' }).click();

    await expect(page.getByRole('alert')).toContainText('Identifiants incorrects');
    await expect(page).toHaveURL(/\/login/);
  });
});

Les libellés (« E-mail », « Se connecter », « Identifiants incorrects ») sont ceux de l'application d'exemple : chez vous, ils viendront de l'exploration réelle. C'est tout l'intérêt de la démarche — le test est écrit à partir de la page observée, pas d'une supposition.

Étape 3 : la relecture humaine

Avant de committer, relisez le test comme celui d'un collègue : les assertions vérifient-elles un résultat métier, ou seulement qu'un clic a eu lieu ? Le cas d'erreur contrôle-t-il aussi que l'utilisateur n'est pas connecté ? Manque-t-il un cas limite (champ vide, compte bloqué) ? Exécutez le test vous-même, puis faites-le échouer volontairement une fois pour vérifier qu'il détecte bien une régression.

Playwright MCP, Playwright CLI ou Test Agents : que choisir ?

Microsoft propose aujourd'hui trois manières de faire travailler une IA avec Playwright. Elles ne s'excluent pas, mais elles ne visent pas le même usage.

Le README de Playwright MCP le dit clairement : pour un agent de code, la CLI avec des Skills est souvent préférable, car chaque appel reste court ; MCP reste pertinent quand l'agent doit raisonner longtemps sur la structure d'une page avec un état persistant.

Les Playwright Test Agents s'installent dans un projet existant :

npx playwright init-agents --loop=claude
# ou : --loop=vscode, --loop=opencode

Pour Claude Code, la commande crée les définitions d'agents dans .claude/agents/ et un fichier .mcp.json qui lance npx playwright run-test-mcp-server. Le planner explore l'application et produit un plan de test en Markdown, le generator transforme ce plan en fichiers de test, et le healer exécute la suite et répare les tests en échec — en dernier recours, il marque un test test.fixme() avec un commentaire expliquant pourquoi. Pensez à relancer la commande après chaque mise à jour de Playwright pour récupérer les nouvelles instructions.

Limites et bonnes pratiques

Ce que ça change pour le métier de testeur

Playwright MCP ne remplace pas le testeur : il déplace son travail. Le temps passé à écrire des sélecteurs et du code répétitif diminue ; celui consacré à concevoir les cas de test, choisir les assertions, préparer les données et relire le code augmente. Les compétences qui comptent le plus deviennent donc celles qui ne s'automatisent pas : les techniques de conception de tests (partitions d'équivalence, valeurs limites, tables de décision), la compréhension du métier, et la capacité à juger si un test protège vraiment contre une régression.

Il faut aussi savoir lire et corriger du TypeScript : un testeur qui ne comprend pas le code généré ne peut ni le relire, ni le maintenir. C'est pourquoi nous enseignons d'abord la conception de tests et les bases de Playwright, puis l'IA appliquée au test — voir notre page IA et test logiciel et notre article sur l'IA et le machine learning pour les tests automatisés. Si vous hésitez encore sur l'outil, notre comparatif Playwright vs Selenium détaille pourquoi Playwright est aujourd'hui le choix le plus simple pour démarrer.

Questions fréquentes