La question qu'on me pose en premier
« Cypress ou Playwright ? » C'est toujours la première question. C'est rarement la bonne.
J'ai livré les deux en production. Une fondation Cypress qui tourne aujourd'hui dans la CI d'une plateforme de réservation, et de la gouvernance de tests sur un logiciel de machines industrielles où les suites s'exécutent tous les jours. Sur ces deux projets, l'outil n'a jamais été ce qui a séparé une suite qui protège la production d'une suite que l'équipe finit par désactiver.
La question mérite quand même une vraie réponse.
La différence qui explique tout le reste
Cypress s'exécute dans le navigateur, dans la même boucle d'événements que votre application. Playwright pilote le navigateur depuis l'extérieur, par un protocole de debug.
Tout le reste découle de là.
Parce qu'il vit dans la page, Cypress voit l'application comme elle se voit elle-même. Vous accédez au DOM, au store, aux requêtes réseau, sans passer par un pont. Le runner rejoue chaque étape avec l'état exact du DOM à ce moment. Pour comprendre pourquoi un test casse, c'est encore ce qu'on fait de mieux.
Le prix de cette proximité, c'est l'enfermement. Un test Cypress vit dans un onglet. Le multi-onglets, le multi-contexte, plusieurs sessions utilisateur en parallèle dans le même scénario : c'est là que ça coince, et les contournements sont laids.
Playwright n'a pas ce problème parce qu'il n'est pas dans la page. Il ouvre autant de contextes navigateur qu'il veut, chacun avec ses cookies et son stockage. Tester un chat entre deux utilisateurs, ou un flux d'approbation où l'un soumet et l'autre valide, s'écrit naturellement.
Où Playwright gagne vraiment
Le parallélisme. Il est natif et gratuit. Vous découpez la suite en workers, vous shardez sur plusieurs machines en CI, et c'est une option de ligne de commande. Chez Cypress, la parallélisation passe historiquement par Cypress Cloud, donc par une facture, ou par un service tiers à héberger.
Les navigateurs. Chromium, Firefox et WebKit avec la même API. Si vos utilisateurs sont sur Safari, ce n'est pas un détail.
Le trace viewer. Un fichier de trace contient les captures, le DOM, le réseau et la console de toute l'exécution. Vous ouvrez l'échec de la CI sur votre machine et vous rembobinez. C'est la meilleure réponse au « ça marche chez moi » que j'aie vue.
Les langages. JavaScript et TypeScript, mais aussi Python, Java et C#. Sur un produit .NET dont l'équipe ne fait pas de JS, ça change la conversation.
Où Cypress tient encore
L'expérience de développement reste au-dessus. Le runner interactif, la sélection d'élément, le rejeu instantané : un développeur qui n'a jamais écrit de test produit quelque chose d'utile en une après-midi. Ça compte plus qu'on ne l'admet, parce qu'une suite que personne n'aime écrire est une suite qui meurt.
Et si votre équipe a déjà deux ans de Cypress dans un monorepo, avec l'exécution ciblée sur les projets affectés et une CI réglée, migrer coûte des semaines pour un gain marginal. Ne le faites pas par mode.
Ce que je recommande
Nouveau projet en 2026 : Playwright. Le parallélisme natif, le multi-contexte et le trace viewer valent plus que le confort du runner Cypress, et l'écart d'ergonomie s'est beaucoup réduit.
Projet existant sous Cypress qui fonctionne : restez. Investissez plutôt l'argent de la migration dans la stabilité des tests que vous avez déjà.
Et maintenant la vraie réponse
Sur les projets où la suite E2E a fini au placard, ce n'est jamais l'outil qui a échoué. C'est toujours les mêmes quatre choses.
Des sélecteurs accrochés au CSS, qui cassent au premier changement de design. Des tests qui dépendent les uns des autres, donc un échec en cascade dès que le premier tombe. Des données non maîtrisées, donc une suite verte le lundi et rouge le mardi sans qu'une ligne de code ait bougé. Et un temps d'exécution qui dépasse le quart d'heure, après quoi les développeurs apprennent à contourner la barrière.
Réglez ces quatre points et Cypress comme Playwright vous protégeront. Ignorez-les et aucun des deux ne vous sauvera.
Le choix de l'outil, c'est la plus petite décision du projet.