En novembre 2025, j'étais au WebWorker Saar, dans les locaux de Meta-Level Software AG à Sarrebruck, pour parler de Playwright : tests E2E, Testcontainers, IA générative et MCP, et pourquoi tout cela s'emboîte soudain. Presque un an plus tard, Playwright était de nouveau au programme, cette fois au .NET User Group Karlsruhe. Deux soirées, deux publics, et un même constat les deux fois.
Tout le monde connaît, peu l'utilisent
Playwright et les tests de bout en bout n'étaient pas des inconnus dans la salle. La plupart en avaient entendu parler, rares étaient ceux qui les utilisaient vraiment. Ce qui était nouveau pour beaucoup, c'étaient les différentes approches : tests contre des API simulées, tests contre un vrai backend avec Testcontainers ou Docker Compose, traces pour analyser les échecs dans le pipeline.
C'est exactement ce que j'entends quand je discute avec d'autres entreprises. Tout le monde s'accorde à dire que la qualité est essentielle et qu'un outil comme Playwright aide. Puis l'investissement ne vient pas, ou reste superficiel.
Les participants de la soirée à Sarrebruck ont appris quelque chose de nouveau, posé des questions pertinentes et sont repartis en mesure d'approfondir le sujet de façon plus ciblée.
La culture du test vient de l'équipe
Ce que je retiens de nos projets : les initiatives qui ont réellement mené à une adoption large sont toujours venues de la base, de l'équipe elle-même.
C'est ce qui s'est passé chez un grand client. Nous avons testé Playwright dans notre propre équipe, l'avons mis en place pour les scénarios critiques, puis avons transmis notre expérience aux autres équipes avec une recommandation. À partir de là, il s'est diffusé. Aujourd'hui, Playwright y est la solution de référence.
Mon pire talk depuis longtemps
En septembre 2026, j'ai été invité au .NET User Group Karlsruhe pour parler de « Playwright au-delà du happy path ». Je dois être honnête : c'était mon pire talk depuis longtemps. Désolé pour tous ceux qui étaient là.
La démo n'a pas fonctionné. Je n'avais pas d'internet sur place, et il manquait sur ma machine les binaires de navigateur dont Playwright a besoin pour les tests. Je n'y avais tout simplement pas pensé.
La soirée en a tout de même valu la peine, grâce à la discussion. À Karlsruhe aussi, Playwright était bien connu, et déjà utilisé par endroits. Nous avons eu un échange constructif sur les cas où Playwright vaut le coup et ceux où il ne le vaut pas.
Quand les tests E2E sont rentables
Mon conseil est toujours le même : respectez la pyramide des tests et utilisez les tests E2E avec parcimonie. Même à l'heure de l'IA, ils demandent plus d'efforts à écrire et à maintenir que des tests unitaires ou d'intégration, et les garder stables représente un vrai travail.
Un test de bout en bout qui échoue en permanence a à peu près autant de sens que Stack Overflow en 2026.
Les tests E2E ont donc leur place là où un bug fait vraiment mal : les parcours critiques qui traversent toutes les couches. Pour le reste, il existe des tests plus rapides et moins chers. Pour démarrer avec Playwright, j'ai écrit Tests UI avec Playwright.
Une seconde jeunesse pour Playwright
Ce qui a vraiment changé entre les deux talks, c'est le rôle de Playwright. En 2025, je classais encore le serveur MCP de Playwright dans la catégorie « expérimental, mais prometteur ». En 2026, l'IA lui a offert une seconde jeunesse.
Grâce au serveur MCP et à la CLI de Playwright, les agents de code ne se contentent plus de piloter un navigateur à distance. Ils se branchent directement sur les tests E2E, exécutent du code dans la session de navigation en cours, font des tests exploratoires et peuvent même enregistrer des vidéos via la CLI. Playwright est donc devenu la télécommande universelle et automatique du navigateur, enregistreur vidéo intégré.
Je m'en sers aujourd'hui pour le développement d'interfaces dans des projets clients et pour des vidéos de démo, que je réalise avec la CLI de Playwright et ffmpeg.
Mais le point le plus important est ailleurs. Une IA a toujours besoin d'un moyen de vérifier son propre travail. Dans le modèle d'Andrej Karpathy, c'est le vérificateur, l'un des trois niveaux : spec, vérificateur et environnement. En développement d'interface, ce vérificateur est forcément visuel. Sans regarder ce que le navigateur affiche réellement, un agent ne peut pas savoir s'il a terminé et si tout fonctionne comme prévu. Playwright lui donne ce regard.
Ce que je retiens
L'intérêt pour les tests E2E est là, c'est la mise en œuvre qui coince. Ce qui a fonctionné chez nous, c'est une équipe qui se lance, sécurise les scénarios critiques et partage ce qu'elle a appris.
En décembre, je parlerai de nouveau de Playwright aux IT-Tage à Francfort, avec internet cette fois.