Playwright MCP : l'IA pour écrire et déboguer tes tests

Demander à une IA d'ouvrir ton application, de cliquer sur un bouton et de te dire ce qu'elle voit : c'est exactement ce que permet Playwright MCP. Ce serveur, publié par Microsoft, donne à un assistant de code comme Claude Code, GitHub Copilot ou Cursor la possibilité de piloter un vrai navigateur. Pour un QA, c'est un outil précieux pour explorer une page, trouver des locators fiables, écrire un premier test ou comprendre un échec.

Ce guide explique ce qu'est Playwright MCP, comment l'installer, trois usages concrets pour un testeur, et surtout ses limites : l'IA accélère le travail, elle ne remplace pas une suite de tests bien écrite.

Playwright MCP en deux mots

MCP (Model Context Protocol) est un standard qui permet à un assistant IA d'utiliser des outils externes. Playwright MCP est un serveur MCP qui expose les actions d'un navigateur sous forme d'outils : ouvrir une page, cliquer, saisir du texte, prendre une capture d'écran, lire la console ou les requêtes réseau.

Sa particularité : l'assistant ne « regarde » pas la page à partir d'images. Il lit un instantané d'accessibilité, c'est-à-dire la liste des éléments avec leur rôle et leur libellé, tels que les perçoit un lecteur d'écran. C'est rapide, précis, et cela pousse naturellement vers les bons locators Playwright, comme getByRole et getByLabel.

Ce qu'il te faut

• Node.js 20 ou plus récent sur ton poste ;
• un client MCP : Claude Code, VS Code avec GitHub Copilot en mode agent, Cursor, Windsurf, Claude Desktop…
• une application à tester, idéalement un environnement de recette avec des comptes de test.

Le serveur Playwright MCP est open source et gratuit. En revanche, l'assistant IA que tu utilises peut être payant selon ton abonnement.

Installer Playwright MCP

Dans Claude Code

Une seule commande, à lancer dans ton terminal :

claude mcp add playwright npx @playwright/mcp@latest

Dans VS Code

Le plus simple est le bouton d'installation de la documentation officielle. En ligne de commande :

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

Les outils du navigateur sont ensuite disponibles dans Copilot, en mode agent.

Dans Cursor ou un autre client

Ajoute cette configuration dans les réglages MCP de ton client (Cursor : Settings, puis MCP) :

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

Les options utiles

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

Point à connaître : par défaut, le serveur garde un profil persistant par projet, avec tes cookies et tes connexions d'une session à l'autre. Pratique pour ne pas se reconnecter, mais à éviter sur un compte sensible : préfère alors --isolated.

Comment l'assistant « voit » ta page

Quand l'assistant appelle l'outil browser_snapshot, il reçoit une description de la page de ce type (extrait simplifié) :

- heading "Connexion" [level=1] [ref=e2]
- textbox "Adresse e-mail" [ref=e5]
- textbox "Mot de passe" [ref=e6]
- button "Se connecter" [ref=e7]
- link "Mot de passe oublié ?" [ref=e8]

Chaque élément a une référence (e5, e7…) que l'assistant utilise pour agir : browser_type sur e5 pour saisir l'e-mail, browser_click sur e7 pour valider. Ce sont les mêmes rôles et libellés que ceux de getByRole('button', { name: 'Se connecter' }) dans un test Playwright : le passage de l'exploration au test est direct.

Si un champ apparaît sans libellé dans l'instantané, c'est aussi une information utile : la page a un défaut d'accessibilité, et le locator devra s'appuyer sur un data-testid.

Trois usages concrets pour un QA

1. Explorer une page et trouver de bons locators

Au lieu d'inspecter le HTML à la main, demande à l'assistant :

Ouvre https://recette.mon-appli.fr/login, fais un instantané de la page
et propose les locators Playwright les plus robustes pour chaque champ et bouton
du formulaire de connexion. Signale les éléments sans libellé accessible.

L'assistant navigue, lit l'instantané et te propose des getByRole et getByLabel, en pointant les éléments mal balisés. C'est un gain de temps réel sur une page riche en formulaires.

2. Transformer un scénario manuel en premier test

Donne-lui ton cas de test tel que tu l'écrirais pour une campagne manuelle :

Déroule ce scénario dans le navigateur, puis écris le test Playwright TypeScript correspondant :
1. Se connecter avec qa@example.com / motdepasse-test
2. Ajouter le produit « Casque audio » au panier
3. Vérifier que le panier affiche 1 article
N'utilise que des locators getByRole, getByLabel ou getByText, et aucune pause fixe.

L'assistant exécute réellement les étapes, ce qui vérifie que les locators existent, puis produit un test du type :

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

test('un produit ajouté apparaît dans le panier', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Adresse e-mail').fill('qa@example.com');
  await page.getByLabel('Mot de passe').fill(process.env.TEST_USER_PASSWORD!);
  await page.getByRole('button', { name: 'Se connecter' }).click();

  await page.getByRole('link', { name: 'Casque audio' }).click();
  await page.getByRole('button', { name: 'Ajouter au panier' }).click();

  await expect(page.getByRole('link', { name: /Panier/ })).toContainText('1');
});

Ce test est un brouillon, pas un livrable. Relis-le comme le code d'un collègue : l'assertion vérifie-t-elle vraiment le résultat attendu ? Le mot de passe sort-il bien d'une variable d'environnement ? Le test ne dépend-il pas de données créées à la main ? Pour l'organiser ensuite proprement, range ses locators dans des classes avec le Page Object Model.

3. Comprendre un test qui échoue

Quand un test casse et que le message d'erreur ne suffit pas, demande à l'assistant de reproduire le parcours :

Rejoue ce parcours sur la recette : connexion, puis page Mes commandes.
Le test échoue sur l'attente du titre « Mes commandes ».
Regarde la console, les requêtes réseau en erreur et fais une capture de la page.

Grâce aux outils browser_console_messages, browser_network_requests et browser_take_screenshot, il peut repérer une API qui répond en erreur, un message JavaScript ou un titre qui a changé. Tu gagnes du temps sur le diagnostic, mais c'est toi qui décides s'il s'agit d'un bug de l'application ou d'un test à corriger.

MCP, CLI, agents de test ou codegen : lequel choisir ?

Playwright propose désormais plusieurs façons d'automatiser avec ou sans IA. Elles ne servent pas à la même chose :

La documentation de Playwright recommande d'ailleurs playwright-cli pour les assistants de code, car ses commandes évitent de charger dans le contexte du modèle les longues listes d'outils et les instantanés complets. Playwright MCP reste plus adapté aux boucles où l'assistant doit raisonner longtemps sur la page.

Quel que soit l'outil, une chose ne change pas : ce sont les tests Playwright qui tournent en intégration continue, pas l'IA. L'assistant t'aide à écrire et à déboguer ; la suite de tests, elle, doit rester déterministe et rejouable. Pour l'exécuter automatiquement, vois Playwright et GitHub Actions.

Les limites et les précautions

• Relis tout le code généré. Les erreurs fréquentes : une assertion trop faible (qui passerait même si la fonctionnalité était cassée), un sélecteur CSS fragile, une pause fixe waitForTimeout, ou des données de test écrites en dur.
• Fais attention aux données. Le contenu des pages visitées est envoyé au modèle d'IA. Travaille sur un environnement de recette avec des comptes de test, jamais sur la production avec des données clients.
• Playwright MCP n'est pas une barrière de sécurité, comme le précise sa documentation. N'expose pas le serveur sur le réseau, et n'active pas l'outil browser_run_code_unsafe, qui exécute du code arbitraire, sauf dans un contexte de confiance.
• Méfie-toi du profil persistant. Une session restée connectée peut servir à l'assistant sur une autre tâche. Utilise --isolated pour les comptes sensibles.
• L'IA ne remplace pas la compréhension. Si tu ne sais pas lire un test Playwright, tu ne sauras pas juger celui que l'IA écrit. Les bases restent indispensables : commence par écrire et lancer ton premier test.

FAQ sur Playwright MCP

Playwright MCP est-il gratuit ?

Oui, le serveur est open source et gratuit. Le coût éventuel vient de l'assistant IA que tu utilises (Claude, Copilot, Cursor…), selon ton abonnement ou ta consommation.

Faut-il savoir coder pour utiliser Playwright MCP ?

Pour explorer une page ou diagnostiquer un problème, non : tu dialogues en français avec l'assistant. Pour exploiter les tests qu'il génère, oui : il faut savoir lire du Playwright en TypeScript pour vérifier ce que le test contrôle vraiment et le maintenir dans le temps.

Playwright MCP remplace-t-il les tests automatisés ?

Non. C'est un outil d'aide à l'écriture, à l'exploration et au diagnostic. Les tests qui protègent ton application en continu restent des tests Playwright classiques, exécutés en intégration continue, de façon déterministe.

Fonctionne-t-il avec GitHub Copilot ?

Oui. Dans VS Code, une fois le serveur ajouté, ses outils sont disponibles dans Copilot en mode agent. Il fonctionne aussi avec Claude Code, Cursor, Windsurf, Claude Desktop et la plupart des clients compatibles MCP.

Pour aller plus loin

L'IA est un accélérateur, pas un raccourci : elle rend plus efficace un QA qui maîtrise déjà les bases de Playwright. Pour les acquérir, commence par ton premier test Playwright, puis structure ta suite avec le Page Object Model. Et si tu hésites encore entre les outils, le comparatif Playwright vs Cypress fait le point, y compris sur leurs fonctions d'IA.

L'utilisation de l'IA dans les tests Playwright fait partie du module IA de la formation Mission Playwright : outils, cas réels et bonnes pratiques, sur ton propre projet.