Playwright MCP : faire tester son site par un agent IA

Le serveur Playwright MCP de Microsoft relie des agents comme Claude Code, Codex, Cursor et l'agent Copilot de VS Code à Playwright, le framework d'automatisation de navigateur. Mon conseil : servez-vous-en pour explorer les parcours et comprendre les échecs, puis transformez les découvertes importantes en tests relus et reproductibles.

À quoi sert Playwright MCP concrètement ?

L'agent dispose de commandes pour piloter le navigateur et d'une description structurée de la page. MCP, pour Model Context Protocol, assure la liaison qui lui permet d'appeler ces outils. Le serveur exécute les actions dans le navigateur ; l'agent choisit celle qu'il demandera ensuite.

Imaginez le plan d'un bâtiment qui indique le nom et la fonction de chaque pièce et de chaque porte. Un instantané d'accessibilité, ou snapshot, joue un rôle similaire : il décrit les boutons, les liens, les champs de texte et leurs noms accessibles. L'agent peut s'appuyer sur cette structure pour choisir sa cible, au lieu de deviner où cliquer dans une image. Le workflow par défaut ne nécessite pas de modèle de vision. Présentation de Microsoft

Avant d'installer le serveur, il faut choisir son approche. Microsoft propose désormais aussi Playwright CLI avec des skills aux utilisateurs d'agents de développement. MCP reste présenté comme utile pour conserver l'état du navigateur et réexaminer régulièrement la structure des pages. Choisissez MCP si cette interaction continue correspond à votre workflow ; étudiez l'option CLI si votre agent utilise déjà facilement des commandes shell. Dans les deux cas, le choix de l'outil ne suffit pas à prouver qu'un parcours client fonctionne. Comparaison entre MCP et CLI par Microsoft

Pour compléter votre environnement, consultez notre sélection des meilleurs serveurs MCP pour 2026.

Installer le serveur dans Claude Code, Codex, Cursor ou VS Code

Il vous faut Node.js 18 ou une version ultérieure et un client compatible avec MCP. Les commandes et configurations ci-dessous reprennent les exemples du README de Microsoft. Choisissez la procédure de votre client : ce sont des options d'installation distinctes, pas des étapes à enchaîner dans tous les éditeurs. Prérequis et installation

Claude Code

Exécutez cette commande telle quelle :

claude mcp add playwright npx @playwright/mcp@latest

Codex

Exécutez cette commande telle quelle :

codex mcp add playwright npx "@playwright/mcp@latest"

Vous pouvez aussi ajouter ceci à ~/.codex/config.toml :

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

Suivez la procédure manuelle du README : Cursor Settings -> MCP -> Add new MCP Server. Choisissez un nom, sélectionnez le type command, puis saisissez :

npx @playwright/mcp@latest

Utilisez Edit pour consulter la configuration ou ajouter des arguments. Le README propose également un bouton d'installation dans Cursor.

VS Code

Utilisez la commande CLI de VS Code exactement sous cette forme :

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

Votre agent GitHub Copilot dans VS Code peut alors accéder au serveur. Le README de Microsoft contient aussi des liens vers les boutons d'installation et le guide de configuration MCP de VS Code.

La configuration JSON commune

Pour les clients qui utilisent la configuration JSON standard du README, voici l'exemple exact :

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

Reportez-vous à la procédure de votre client ci-dessus pour placer cette configuration au bon endroit. L'autre méthode de configuration de Codex utilise du TOML, pas ce JSON. Pour choisir l'agent qui pilotera l'ensemble, consultez notre sélection d'agents IA de développement avec tests dans le navigateur.

Choisir le navigateur et la façon dont l'agent lit la page

Commencez avec une fenêtre de navigateur visible, un profil isolé et des snapshots. Ajoutez les options à la liste des arguments du serveur, après @playwright/mcp@latest. Elles proviennent de la référence de configuration de Microsoft.

Le choix entre snapshot et vision porte sur la méthode d'interaction. Dans le workflow par défaut, utilisez browser_snapshot pour repérer les cibles. browser_take_screenshot fournit une preuve visuelle, mais une capture d'écran n'active pas à elle seule les clics par coordonnées. Avec --caps=vision, le README recense browser_mouse_click_xy, browser_mouse_down, browser_mouse_drag_xy, browser_mouse_move_xy, browser_mouse_up et browser_mouse_wheel. Votre client et votre modèle doivent pouvoir exploiter les images reçues pour raisonner visuellement. Référence des outils

Je commence par les snapshots pour les formulaires courants et la navigation. L'inspection visuelle devient utile quand l'apparence compte ou que la structure de la page ne décrit pas suffisamment le contrôle à utiliser. Un snapshot d'accessibilité renseigne sur la structure ; il ne permet pas de conclure que l'affichage est correct.

Quels outils utiliser pour tester dans le navigateur ?

Les outils de base couvrent la navigation, les interactions et la collecte de preuves. Ce tableau regroupe les outils d'automatisation et de gestion des onglets du README selon la tâche confiée à l'agent. Liste des outils de Microsoft

Les actions fondées sur les snapshots utilisent une référence de cible issue du snapshot de la page, ou un sélecteur unique. Un sélecteur permet d'identifier un élément de la page. Actualisez le snapshot après tout changement significatif, au lieu de supposer qu'une cible repérée auparavant reste valable.

Les capacités supplémentaires doivent être activées explicitement. Le tableau des options mentionne vision, pdf et devtools ; les sections consacrées aux outils documentent aussi expressément config, network, storage et testing :

• PDF : --caps=pdf ajoute browser_pdf_save.
• Preuves de débogage : --caps=devtools comprend les traces, la vidéo, l'enregistrement des actions, les annotations, la mise en évidence et la reprise d'une exécution en pause. Par exemple, browser_start_tracing et browser_stop_tracing délimitent l'enregistrement d'une trace.
• Assertions : --caps=testing ajoute browser_generate_locator, browser_verify_element_visible, browser_verify_list_visible, browser_verify_text_visible et browser_verify_value. Une assertion exprime ce qui doit être vrai.
• Simulation réseau : --caps=network ajoute browser_network_state_set, browser_route, browser_route_list et browser_unroute pour simuler le fonctionnement hors ligne et les requêtes.
• Stockage : --caps=storage permet d'inspecter et de modifier les cookies, le stockage local et le stockage de session, et ajoute browser_storage_state ainsi que browser_set_storage_state.
• Configuration effective : --caps=config ajoute browser_get_config.

Il s'agit des groupes documentés dans le README, sans garantie que chaque client donne immédiatement accès à tous les outils. Si un outil manque, comparez la liste des outils du paquet installé et les capacités activées avec le README. Description complète des outils

Trois usages à privilégier pour votre activité

Concentrez-vous sur les parcours dont l'échec bloque une vente ou empêche un client de vous contacter. Les workflows suivants sont des pistes d'utilisation, pas des promesses d'économies mesurées.

Vérifier que le client peut aller jusqu'au paiement

Le développeur d'une boutique pourrait demander à l'agent de suivre le parcours de commande sans compte en préproduction, de vérifier que l'article choisi se retrouve bien dans le panier, de saisir des coordonnées de livraison fictives et de s'arrêter avant tout paiement réel. L'intérêt est de découvrir une erreur qui empêche l'achat avant qu'un client ne la rencontre.

La même équipe peut aussi lui confier un test de reprise après erreur : envoyer des informations de livraison incomplètes, vérifier que le message d'erreur est compréhensible, corriger les données et s'assurer que le client peut continuer. Un test du seul parcours sans erreur ne couvre pas le cas d'un client qui se trompe dans un champ.

Contrôler le site après un déploiement

Un fondateur qui modifie une landing page pourrait faire ouvrir la version déployée par l'agent, lui demander de suivre l'appel à l'action principal et de vérifier qu'il arrive sur la bonne page d'inscription ou de contact. Demandez des preuves issues de la page, ainsi que les messages de console ou les informations sur les requêtes en échec qui éclairent le résultat.

Un développeur en agence pourrait ensuite réduire la largeur de la zone d'affichage et refaire le parcours. Cela peut révéler un menu masqué ou un bouton inaccessible. La capture d'écran reste un élément à examiner, pas un certificat automatique de qualité visuelle.

Mettre les formulaires à l'épreuve avec des données fictives

Un développeur SaaS pourrait tester les champs obligatoires d'un formulaire d'inscription accessible sans connexion, ses messages de validation et la possibilité de corriger une erreur, en local ou en préproduction. Arrêtez-vous avant de créer un vrai compte, ou utilisez une destination réservée aux envois de test.

Un développeur chargé des opérations pourrait remplir un long formulaire de préproduction avec des données fictives, vérifier les listes déroulantes, les champs conditionnels et le téléversement d'un fichier de test, puis envoyer le tout vers un endpoint simulé. Cette méthode aide à repérer les erreurs de correspondance entre champs, sans transmettre de données clients ni déclencher un vrai workflow.

Exemple de bout en bout : une commande bloquée avant le paiement

Confiez à l'agent une tâche bien délimitée et exigez des preuves à l'appui de sa conclusion. Il s'agit ici d'un exemple illustratif de bout en bout, avec un défaut posé comme hypothèse. Ce n'est pas le compte rendu d'un test effectué sur une boutique en ligne réelle.

L'application de l'exemple comporte un panier accessible sans compte, un formulaire de livraison et une page de paiement. Par erreur, le formulaire envoie le code postal dans le champ postal, alors que le backend attend postalCode. Utilisez un environnement de test local ou de préproduction, accessible sans connexion, avec des données fictives et aucun raccordement à un paiement réel.

Donnez cette consigne à votre agent en remplaçant l'URL entre crochets par celle de votre environnement de test :

L'isolation se règle dans la configuration du serveur avec --isolated ; la demander uniquement dans le prompt ne configure pas le serveur.

Dans cet exemple, le corps de la requête contient postal et la réponse signale l'absence de postalCode. Cela étaye l'hypothèse d'une erreur de correspondance entre champs. Le développeur doit néanmoins examiner la sérialisation du formulaire et le contrat attendu par le backend avant de considérer la cause du problème comme corrigée.

Exemple de rapport de l'agent :

L'étape suivante consiste à corriger la correspondance des champs, puis à rejouer les parcours avec des données invalides et valides. Une fois le comportement confirmé, faites rédiger un test de non-régression Playwright par l'agent, relisez ses assertions et intégrez-le à votre outil d'exécution de tests habituel. Cette dernière étape relève de votre workflow de développement ; la conversation MCP ne constitue pas à elle seule une suite de tests de non-régression.

Quelles sont les limites, et à quoi l'agent peut-il accéder ?

Les vérifications les moins fiables partent d'un objectif flou ou d'un environnement risqué. « Vérifie le tunnel de commande » laisse l'agent inventer les critères de réussite. « Confirme que des coordonnées de livraison valides permettent d'atteindre la page de paiement, sans envoyer de paiement » définit un résultat que l'on peut contrôler.

Voici les limites pratiques à anticiper :

• Structure de page ambiguë : Les contrôles sans nom et les interfaces qui reposent largement sur des canvas rendent le plan structurel moins utile. Je recommande de corriger les libellés accessibles lorsque vous maîtrisez l'application, et de recourir aux preuves visuelles lorsque la structure ne suffit pas.
• État changeant : Un nouveau rendu, une fenêtre surgissante ou une transition retardée peuvent invalider l'hypothèse sur laquelle l'agent fonde son action suivante. Examinez l'état obtenu et attendez le texte ou la transition prévus avant de continuer.
• Conflits de profils : Un profil persistant ne peut servir qu'à une seule instance de navigateur à la fois. Microsoft recommande des sessions isolées ou des valeurs --user-data-dir distinctes pour les clients qui partagent un espace de travail et s'exécutent en parallèle.
• Différences entre environnements : L'implémentation Docker du README ne prend en charge que Chromium en mode headless. Ne supposez pas que tous les navigateurs du tableau général de la CLI fonctionnent dans ce conteneur.
• Couverture incomplète : Atteindre une page ne prouve pas que toutes les validations fonctionnent, ni que tous les navigateurs, appareils ou résultats côté backend sont couverts. Une capture d'écran ne prouve pas non plus qu'une commande a été correctement enregistrée. Ce sont les limites du workflow de vérification proposé.

Les restrictions relatives aux profils et à Docker sont documentées dans le README de Microsoft.

Donner accès au navigateur, c'est donner un accès réel. Microsoft précise expressément que Playwright MCP n'est pas une frontière de sécurité. Le profil par défaut conserve l'état du navigateur ; l'extension facultative Chrome/Edge peut se connecter à des onglets existants et à des sessions déjà authentifiées. Pour les usages décrits ici, utilisez une session isolée, sans importer de cookies ni la relier à votre navigateur quotidien. Fonctionnement des profils et de l'extension

L'agent peut demander des pages accessibles depuis l'environnement du navigateur. Selon votre réseau, cela peut inclure des serveurs de développement ou des services internes, en plus des sites publics. Les règles sur les origines ne remplacent pas l'isolation réseau : --allowed-origins et --blocked-origins ne limitent pas les redirections et ne constituent explicitement pas une frontière de sécurité. --allowed-hosts concerne la vérification des hôtes pour les requêtes entrantes du serveur MCP ; ce n'est pas une liste des sites que le navigateur est autorisé à visiter. Configuration et sécurité

L'accès aux fichiers demande la même vigilance. Selon la documentation, le comportement par défaut limite l'accès aux fichiers aux racines des espaces de travail et bloque la navigation file://, tandis que --allow-unrestricted-file-access assouplit ces règles. Microsoft présente ces contrôles comme des garde-fous, pas comme un confinement sécurisé. Plus sensible encore, browser_run_code_unsafe exécute du JavaScript dans le processus du serveur, avec les possibilités d'accès de ce processus. Encadrez cet outil par les autorisations du client et limitez les accès de l'environnement du serveur. Schéma de configuration et outils

Les captures d'écran, le texte des pages, les sorties de console et les corps de requêtes peuvent exposer des données à l'agent. Utilisez des données fictives et des endpoints réservés aux tests. Arrêtez le parcours avant tout débit réel, envoi de message, création de compte ou autre soumission ayant des conséquences, sauf si cette action précise a été expressément autorisée.

Playwright MCP, Chrome DevTools MCP ou Browserbase : lequel choisir ?

Le choix dépend de la tâche et de l'endroit où le navigateur doit s'exécuter. Ces produits ont des fonctions qui se recoupent, mais n'occupent pas des places interchangeables dans votre environnement.

Microsoft propose aussi --cdp-endpoint pour se connecter à un endpoint de navigateur. Le choix de l'interface utilisée par l'agent et celui du lieu d'exécution du navigateur sont donc deux décisions distinctes. Browserbase n'est pas un autre nom pour le serveur de Microsoft. Notre sélection des meilleurs navigateurs pour les agents IA traite de ce choix plus large.

Quel budget prévoir, et quels services en tirer ?

La comparaison utile porte sur votre méthode de vérification actuelle et sur l'ensemble du workflow automatisé. Le dépôt de Playwright MCP est sous licence Apache ; l'installation ne fournit ni le modèle de l'agent, ni les ressources de calcul, ni les environnements de test, ni la relecture humaine.

Faites le calcul avec vos propres chiffres :

• Avant : heures de vérification manuelle × coût horaire chargé, plus les éventuels abonnements de test déjà en place.
• Après : utilisation de l'agent + infrastructure du navigateur + relecture humaine + maintenance des environnements et des tests.

Pour donner un repère concret sur l'hébergement, Browserbase affiche son offre Developer à $20/mois avec 100 heures de navigateur, puis $0.12 par heure de navigateur. Ces frais couvrent l'infrastructure du navigateur, pas le coût complet d'un test du tunnel de commande par un agent. Tarifs de Browserbase

La piste la plus solide : un service de recette après déploiement

Une petite agence pourrait proposer de vérifier les parcours clients convenus après chaque déploiement. La version minimale utile prend une URL de préproduction et une liste de critères de recette, exécute les parcours sans connexion autorisés et produit un rapport relu, avec des preuves et les limites explicites de sa couverture. Le client paie pour que quelqu'un prenne en charge cette vérification.

Le signal de demande reste modeste : les estimations de mots-clés DataForSEO en anglais pour les États-Unis, récupérées en octobre 2026, indiquent 110 recherches mensuelles pour « automated browser testing » et 10 pour « checkout testing ». Ces chiffres comptent des recherches, pas des acheteurs. Ils justifient de tester un service ciblé auprès de clients existants avant d'investir dans un produit logiciel plus large.

La difficulté tient à la maintenance : parcours qui évoluent, assertions ambiguës et fausses alertes peuvent absorber le temps de travail que l'on espérait économiser. Ce qui rend l'offre défendable, c'est une liste de critères de recette utile et un triage fiable des problèmes, pas l'installation d'un serveur MCP public accessible à tous.

Autre piste : un vérificateur de formulaires en préproduction

Une agence web pourrait créer un outil qui remplit les formulaires avec des valeurs fictives, provoque les erreurs de champs obligatoires et vérifie qu'un envoi corrigé atteint une destination simulée. Commencez par les formulaires des sites que l'agence maintient déjà, avec un rapport permettant à un développeur de reproduire le résultat.

Le même jeu de données DataForSEO en anglais pour les États-Unis estime à 10 le nombre de recherches mensuelles pour « website form testing ». Pris isolément, c'est un faible signal d'acquisition. Je recommande de vendre ce service en complément de la maintenance du site, puis de valider la récurrence de la demande avant d'en faire un produit distinct.

Le point délicat est le système destinataire. Une page qui semble confirmer le succès ne prouve pas que les coordonnées du prospect sont arrivées à destination. Le MVP doit prévoir un endpoint de test, ou un autre moyen autorisé de vérifier la réception, en plus des preuves recueillies dans le navigateur.

Les questions qui se posent à l'installation

À faire dès lundi : choisissez le parcours sans compte le plus directement lié aux ventes, précisez le résultat attendu et le point d'arrêt, puis demandez à votre agent de développement habituel de le vérifier en préproduction. Examinez les preuves avec le développeur responsable du parcours avant d'élargir le périmètre.

Pour un workflow de vérification dans le navigateur adapté à vos mises en production, nous développons des agents IA pour les workflows métier.