MCP Playwright : le serveur Model Context Protocol publié par Microsoft pour Playwright (dépôt officiel). Il permet à un agent IA de piloter un navigateur en lisant l'arbre d'accessibilité des pages, sans capture d'écran ni modèle de vision : ouvrir une URL, cliquer, remplir un formulaire, lire ce qui s'affiche.
De plus en plus d'équipes QA confient leurs tests de non-régression à un agent comme Claude, branché sur le MCP Playwright. Pour explorer une application ou reproduire un bug, l'outil est remarquable. Pour un test rejoué à chaque release, il lui manque une propriété : refaire exactement le même parcours, car l'agent redécide chaque action à chaque passage. Delta-QA MCP répartit les rôles autrement. Votre agent crée le scénario en langage courant, puis Delta-QA le rejoue à l'identique, sans LLM, et compare chaque release à la référence.
L'essentiel en une page (définition, automatisation sans code, grille de choix d'un outil) : Test de non-régression automatisé, sans code.
Votre agent IA sait déjà naviguer sur votre site. Branchez-le sur Delta-QA : il écrit le scénario, Delta-QA le rejoue à chaque release et photographie chaque étape. Essayer Delta-QA gratuitement →
Pourquoi le MCP Playwright séduit autant les équipes QA
Le MCP Playwright transforme une demande en langage courant en actions réelles dans un navigateur. Un testeur écrit « vérifie que le formulaire de contact refuse un e-mail invalide », et l'agent ouvre la page, saisit, valide, puis rend compte. Aucun script à écrire, aucun sélecteur à chercher : c'est ce qui explique son adoption rapide.
Les chiffres le confirment. Le paquet @playwright/mcp est passé de 2,2 millions de téléchargements npm en septembre 2025 (npm) à 29,3 millions en septembre 2026 (npm), et son dépôt GitHub approche les 38 000 étoiles. Les téléchargements comptent aussi les installations automatiques, l'indicateur est donc imparfait. La tendance, elle, est nette : treize fois plus de téléchargements en un an.
Ses atouts sont réels. Ses outils agissent sur l'arbre d'accessibilité de la page, ce que Microsoft présente comme une application déterministe des outils, sans les ambiguïtés des approches par capture d'écran. Microsoft le recommande pour l'automatisation exploratoire et les tâches où l'agent doit garder le contexte du navigateur. Reproduire un bug signalé, vérifier une page après un correctif, découvrir une fonctionnalité : sur ces tâches ponctuelles, il fait gagner un temps considérable.
Le MCP Playwright est donc un excellent outil d'exploration. Reste à savoir s'il peut devenir votre filet de sécurité à chaque release. Pour le fonctionnement du protocole lui-même, voir Playwright et le MCP (Model Context Protocol).
Un test rejoué par un agent n'est pas un test de non-régression
Un test de non-régression n'a de valeur que s'il rejoue le même parcours, avec les mêmes vérifications, à chaque release. C'est ce qui permet d'attribuer une différence à la release, et non au test. Un agent piloté par un LLM redécide chaque action à chaque passage : le même prompt peut produire un autre chemin, et donc un autre verdict.
Ce n'est pas un défaut de Playwright, c'est la nature des LLM. En septembre 2025, le laboratoire Thinking Machines a soumis 1 000 fois la même demande au modèle Qwen3-235B, avec une température à zéro, le réglage censé être le plus stable. Il a obtenu 80 réponses différentes (Thinking Machines Lab). Les outils du MCP Playwright s'appliquent de façon déterministe ; la décision de les appeler, dans quel ordre et sur quel élément, ne l'est pas.
Pour une équipe QA, cela a trois conséquences concrètes :
- Un échec ne dit pas qui a changé. Quand le rejeu échoue, rien n'indique si le site a régressé ou si l'agent a pris un autre chemin.
- Un succès ne prouve pas le même parcours. L'agent peut atteindre la page finale par un détour et conclure que tout fonctionne.
- Chaque passage coûte du temps et des tokens. L'agent raisonne de nouveau à chaque étape, et Microsoft rappelle que le MCP charge des schémas d'outils et des arbres d'accessibilité volumineux dans le contexte du modèle (README du MCP Playwright).
Playwright a sa propre réponse : figer le parcours en code. Ses agents de test explorent l'application, rédigent un plan, puis le transforment en fichiers Playwright Test qu'un troisième agent répare quand ils cassent. C'est la bonne voie pour une équipe de développement qui versionne et maintient son code de test. Pour une équipe QA qui ne code pas, cela revient à hériter de fichiers TypeScript, de sélecteurs et d'assertions à maintenir.
Delta-QA MCP : l'agent crée le scénario, Delta-QA le rejoue
Le serveur MCP de Delta-QA garde ce que l'agent fait de mieux, comprendre une demande en langage courant, et lui retire ce qu'il fait mal, rejouer à l'identique. Votre agent crée le scénario et en écrit les étapes. Delta-QA les rejoue dans son propre navigateur, sur votre vrai site, photographie chaque étape et ne valide que ce qui a réellement fonctionné.
Le serveur expose huit outils, que l'agent découvre seul. Six d'entre eux suffisent à créer un test, dans cet ordre :
list_workspaces: l'agent choisit l'espace de travail où créer le test.create_scenario: il crée le scénario à partir d'un nom et d'une URL de départ ; l'étape 1, ouvrir la page, est posée par Delta-QA.set_scenario_steps: il écrit les étapes du parcours, parmi quatorze gestes (clic, saisie, choix, touche, défilement, navigation…), chacune visant un élément de la page.capture_scenario: Delta-QA rejoue le scénario dans son navigateur, sur le vrai site, et prend une photo par étape.get_capture_result: l'agent lit le verdict. Un échec nomme l'étape à corriger ; l'agent la corrige et relance.activate_scenario: sur un rejeu réussi, l'agent valide le scénario et la capture devient la référence.
Rien n'est validé sur parole. Un agent peut se tromper de sélecteur ou affirmer qu'un parcours fonctionne : tant que Delta-QA n'a pas rejoué toutes les étapes avec succès, le scénario reste un brouillon. Le détail des outils, des rôles et des clés figure sur la page Serveur MCP de Delta-QA.
| MCP Playwright | Delta-QA MCP | |
|---|---|---|
| Qui exécute le parcours | L'agent, action par action, à chaque passage | Delta-QA, à partir des étapes écrites une fois par l'agent |
| Rôle du LLM au rejeu | Il décide de chaque action | Aucun : le LLM n'intervient qu'à la création |
| Ce qui reste après la session | L'historique de la conversation, ou des fichiers de test à maintenir | Un scénario dans Delta-QA, lisible et modifiable sans code |
| Preuve du résultat | Le compte rendu de l'agent et ses captures | Une photo par étape et un verdict qui nomme l'étape en échec |
| Release suivante | Nouveau passage de l'agent, ou code à faire évoluer | Rejeu identique, comparé à la référence |
| Point fort | Exploration, reproduction de bugs, vérifications ponctuelles | Tests de non-régression rejoués à chaque release, sans code |
Faites écrire vos scénarios par votre agent, gardez un rejeu à l'identique. Delta-QA rejoue chaque étape sur votre vrai site et ne valide que ce qui a réellement fonctionné. Essayer Delta-QA gratuitement →
Exemple : créer le test du parcours de connexion avec Claude Code
Brancher Claude Code sur Delta-QA demande une clé d'API et une seule commande. Ensuite, vous décrivez le parcours comme vous le feriez à un collègue. L'agent écrit le scénario, Delta-QA le rejoue et en garde la preuve, étape par étape.
- Créez votre compte gratuit et votre espace de travail dans Delta-QA.
- Créez une clé d'API dans Réglages, onglet Espace, section Clés d'API. Donnez-lui un nom, le rôle « Peut modifier » pour un agent qui écrit des scénarios et une expiration de 30 jours, 90 jours ou un an. La clé n'est affichée qu'une fois, avec la commande toute prête.
- Collez la commande dans un terminal, en remplaçant
dqa_…par votre clé :
claude mcp add --transport http delta-qa https://api.delta-qa.com/api/mcp --header "Authorization: Bearer dqa_…"
- Décrivez le parcours dans Claude Code, en langage courant. Par exemple : « Crée un test de non-régression du parcours de connexion sur
https://recette.example.com: saisis l'e-mail du compte de test, le mot de passe, valide, puis vérifie que le tableau de bord s'affiche. » - Laissez l'agent travailler. Il crée le scénario, écrit les étapes et demande à Delta-QA de les rejouer. Si une étape échoue, par exemple un bouton introuvable à l'étape 4, le verdict la nomme : l'agent corrige et relance.
- Validez. Quand le rejeu réussit, l'agent active le scénario : sa capture devient la référence.
Le mot de passe, marqué comme valeur sensible, est chiffré dès son arrivée, saisi au rejeu et voilé sur les photos : l'agent lui-même ne peut plus le relire. La clé d'API n'agit que dans son espace, avec les droits de son rôle, et se révoque immédiatement depuis le même écran.
Ensuite, le QA reprend la main dans Delta-QA
Une fois validé, le scénario créé par l'agent devient un scénario Delta-QA comme les autres. Il apparaît dans votre espace, lisible et modifiable sans code, comme s'il avait été enregistré en naviguant. Le rôle de l'agent s'arrête là : rejouer, comparer et décider reviennent au QA, avec tous les outils de Delta-QA.
À chaque release :
- Rejouer en un clic : le scénario s'exécute seul, sur Chrome, Firefox et WebKit, aux largeurs d'écran que vous choisissez.
- Comparer : le rapport affiche la référence et la version courante côte à côte, avec les différences surlignées et classées (critique, avertissement, mineur). L'IA déterministe de Delta-QA, pas un LLM, rend toujours le même verdict pour le même écart.
- Décider : vous validez le changement comme nouvelle référence, ou vous ouvrez le bug depuis le rapport.
Le rapport contient ce dont un développeur a besoin pour corriger : l'étape en cause, la capture de référence, la capture actuelle et les zones qui diffèrent. Ces éléments se transmettent tels quels au développeur, ou à son agent de code, qui part d'un écart précis plutôt que d'une description approximative. Après la correction, un nouveau rejeu du même scénario confirme que la régression a disparu.
Votre agent écrit le scénario, Delta-QA en garde la preuve. Créez votre clé d'API et faites écrire votre premier test de non-régression par Claude Code. Essayer Delta-QA gratuitement →
FAQ
Qu'est-ce que le MCP Playwright ?
Le MCP Playwright est le serveur Model Context Protocol publié par Microsoft pour Playwright. Il permet à un agent IA comme Claude de piloter un vrai navigateur en lisant l'arbre d'accessibilité des pages : ouvrir une URL, cliquer, saisir, lire un contenu. L'agent agit à partir d'instructions en langage courant, sans script.
Peut-on faire des tests de non-régression avec le MCP Playwright ?
Pour une vérification ponctuelle, oui. Pour un test rejoué à chaque release, l'agent redécide chaque action à chaque passage, donc deux passages peuvent suivre deux chemins. Il faut alors figer le parcours : en code Playwright Test que l'équipe maintient, ou dans un outil qui le rejoue à l'identique, comme Delta-QA.
Faut-il savoir coder pour utiliser le serveur MCP de Delta-QA ?
Non. Vous décrivez le parcours en langage courant, l'agent écrit les étapes et Delta-QA les rejoue. Le scénario apparaît ensuite dans Delta-QA, lisible et modifiable sans code, comme un scénario enregistré en naviguant.
Le LLM intervient-il quand Delta-QA rejoue le test ?
Non. L'agent n'intervient qu'à la création du scénario. Les rejeux sont exécutés par le navigateur de Delta-QA et comparés à la référence par son IA déterministe, pas un LLM : la même entrée donne toujours le même verdict.
Quels agents peuvent se brancher sur Delta-QA ?
Claude Code s'y connecte en une commande. Tout client MCP qui accepte un serveur distant en « Streamable HTTP », avec un en-tête d'authentification, peut aussi s'y brancher.
Le serveur MCP est-il inclus dans le compte gratuit ?
Oui. Les clés d'API et le serveur MCP existent sur tous les plans, compte gratuit compris. Ce que l'agent déclenche compte dans le quota de votre plan, comme si vous l'aviez lancé vous-même.