Tout ingénieur QA finit par se poser la question : quel framework utiliser ? Selenium, Cypress et Playwright ont chacun de vrais utilisateurs, de vraies suites de tests en production, et de vraies forces. Voici une comparaison honnête basée sur ce qu'ils font réellement, pas sur du marketing.

La version courte

Si vous démarrez un nouveau projet en 2026 : Playwright. Vous êtes déjà sur Cypress avec une suite qui fonctionne ? Restez-y sauf si vous avez une raison précise de migrer. Sur Selenium, évaluez si le coût de maintenance justifie de rester.

La suite de cet article explique pourquoi.

Selenium : le vétéran

Selenium est le plus ancien des trois, et en base installée c'est encore le plus utilisé. Des millions de lignes de tests Selenium tournent aujourd'hui dans des pipelines CI, et ça ne va pas changer rapidement.

Ce que Selenium fait bien :

Le choix du langage est réel. Java, Python, C#, Ruby, JavaScript : Selenium les prend tous en charge avec des bindings matures. Si votre équipe écrit en Java, Selenium avec TestNG ou JUnit est un choix légitime et bien documenté.

La couverture cross-browser est complète. Selenium prend en charge tout navigateur avec une implémentation WebDriver, y compris Internet Explorer et Edge Legacy. Si vous testez dans des navigateurs que Playwright ne prend pas en charge, Selenium peut être votre seule option.

L'écosystème est gigantesque. Stack Overflow, tutoriels, bibliothèques, intégrations : Selenium bénéficie de plus de 15 ans d'investissement communautaire.

Ce que Selenium fait mal :

La gestion des drivers est une contrainte de maintenance permanente. ChromeDriver doit correspondre à la version de Chrome. Quand Chrome se met à jour automatiquement, les tests se cassent jusqu'à la mise à jour du driver. Selenium Manager (introduit dans Selenium 4) améliore ça, mais n'élimine pas complètement le problème.

Pas d'attente intégrée. On écrit le code d'attente manuellement : WebDriverWait, ExpectedConditions, utilitaires de polling maison. Chaque équipe réinvente cette roue.

Overhead de configuration. Selenium est une bibliothèque, pas un framework. On assemble un framework de test depuis Selenium + un test runner (JUnit, pytest, Jest) + une bibliothèque d'assertions + un reporter. Playwright s'installe en package complet.

Vitesse. Les tests Selenium sont généralement plus lents que les tests Playwright sur des scénarios équivalents.

// Selenium (Java) — attendre un bouton
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement btn = wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("button[data-testid='submit']")
));
btn.click();

// Playwright (TypeScript) — même opération
await page.getByRole('button', { name: 'Submit' }).click();

Qui devrait utiliser Selenium : les équipes avec des suites Selenium existantes, les équipes qui écrivent en Java/Python/C# où l'écosystème compte, les équipes qui testent dans des navigateurs non pris en charge par Playwright.

Cypress : le bon compromis orienté développeur

Cypress a été lancé vers 2017 et a comblé un vrai manque : un framework de test facile à configurer avec une excellente expérience développeur. C'était l'alternative moderne à Selenium avant l'arrivée de Playwright.

Ce que Cypress fait bien :

L'expérience développeur. L'interface du test runner Cypress est excellente : exécution des tests en temps réel, débogage avec voyage dans le temps via les snapshots DOM, replay intégré des tests. Pour les développeurs qui ne vivent pas dans les frameworks de test, Cypress est facile à adopter.

Les tests de composants. Cypress prend en charge en priorité les tests de composants React, Vue, Angular et Svelte en isolation. Si votre équipe écrit beaucoup de tests de composants, Cypress est compétitif.

Les messages d'erreur. Les erreurs Cypress sont claires et détaillées. Elles indiquent exactement quel élément a été trouvé, quel était le timeout, et à quoi ressemble le DOM actuel.

Ce que Cypress fait mal :

Support des navigateurs. Chromium est pleinement pris en charge. Firefox a un support limité. WebKit (Safari) n'est pas pris en charge. Si la couverture cross-browser est importante, Cypress ne peut pas la fournir.

La parallélisation est payante. Exécuter les tests sur plusieurs machines en CI nécessite Cypress Cloud. L'offre gratuite a des limites. Le sharding de Playwright est gratuit et intégré.

Les scénarios multi-domaines et multi-onglets. Cypress a été architecturalement conçu pour les tests same-origin. Les redirections cross-domain (flux OAuth, paiements tiers) nécessitent des contournements. Playwright gère ça nativement.

Pas d'émulation mobile. Playwright peut émuler des appareils, viewports, user agents, géolocalisation et événements tactiles. Cypress ne peut pas.

La gestion des iframes est limitée. Playwright traite les iframes comme des contextes navigateur de première classe. Cypress a des contournements qui ne couvrent pas tous les cas.

// Cypress — pas d'await, file de commandes
cy.visit('https://lab.becomeqa.com')
cy.get('[data-cy="login-btn"]').click()
cy.get('input[name="username"]').type('admin@becomeqa.com')

// Playwright — async/await explicite
await page.goto('https://lab.becomeqa.com')
await page.getByRole('button', { name: 'Login' }).click()
await page.getByLabel('Username').fill('admin@becomeqa.com')

La différence architecturale est notable : Cypress utilise une file de commandes (les commandes sont mises en file et exécutées plus tard, sans await). Playwright utilise le standard JavaScript async/await. Si vous connaissez JavaScript moderne, le modèle de Playwright est plus intuitif. Si vous débutez en programmation asynchrone, l'approche de Cypress supprime cette complexité.

Qui devrait utiliser Cypress : les équipes avec des suites Cypress existantes, les équipes qui font beaucoup de tests de composants. Aussi celles où l'adoption par les développeurs est la priorité et la couverture cross-browser ne l'est pas.

Playwright : le choix par défaut actuel

Playwright est développé et maintenu par Microsoft, sorti en 2020, et a connu une croissance rapide depuis.

Ce que Playwright fait bien :

Auto-attente partout. Chaque interaction avec un locator attend automatiquement que l'élément soit actionnable. Pas d'attentes explicites nécessaires pour les scénarios standard.

Vraie couverture cross-browser. Chromium, Firefox et WebKit exécutent le même code de test sans configuration spécifique par navigateur. C'est une vraie couverture Safari sur Windows, que rien d'autre ne fournit.

Support TypeScript natif. Les types sont de première classe, pas une réflexion après coup.

Interception réseau. page.route() intercepte, modifie ou simule n'importe quelle requête réseau. Utile pour tester les états d'erreur sans modifier le backend.

// Simuler une réponse API en échec
await page.route('**/api/items', route => {
  route.fulfill({ status: 500, body: '{"error": "Erreur interne du serveur"}' });
});

Multi-onglets et multi-contextes. Créer un nouveau contexte navigateur ou un nouvel onglet est trivial :

const newPage = await context.newPage();
await newPage.goto('https://lab.becomeqa.com/other-page');

Sharding gratuit. Divisez votre suite sur N machines sans service externe :

npx playwright test --shard=1/4  # exécuter 25% des tests sur cette machine

Tests API intégrés. La fixture request fournit un client HTTP complet qui partage le contexte navigateur :

test('api + ui combinés', async ({ page, request }) => {
  const resp = await request.get('/api/items');
  expect(resp.status()).toBe(200);
});

Ce que Playwright fait moins bien :

Les tests de composants sont expérimentaux. Playwright prend en charge les tests de composants, mais c'est moins mature que chez Cypress.

L'interface Cypress est meilleure pour le débogage interactif. Le mode UI de Playwright est bon. Mais l'aperçu en direct et le replay de snapshots DOM de Cypress offrent une meilleure expérience aux développeurs qui ne sont pas principalement des testeurs.

La communauté est plus jeune. Moins d'historique sur Stack Overflow, moins de tutoriels pour les cas limites.

Qui devrait utiliser Playwright : les nouveaux projets, les équipes qui ont besoin de couverture cross-browser, les équipes qui veulent les tests API + UI dans un seul framework, les équipes qui veulent la parallélisation gratuite.

Comparaison côte à côte

| Fonctionnalité | Selenium | Cypress | Playwright |

|---|---|---|---|

| Langages | Java, Python, C#, JS, Ruby | JavaScript/TypeScript | JS/TS, Python, Java, .NET |

| Auto-attente | Manuelle | Intégrée | Intégrée |

| Navigateurs | Tous + IE | Chromium, Firefox partiel | Chromium, Firefox, WebKit |

| Émulation mobile | Non | Non | Oui |

| Multi-onglets | Difficile | Contournements | Natif |

| Mock réseau | Partiel | Intégré | Intégré |

| Parallélisation | Gratuite | Payante (Cloud) | Gratuite |

| Complexité de config | Élevée | Faible | Faible |

| Tests de composants | Non | Excellent | Expérimental |

| Tests API | Non | Non | Intégré |

| Temps de setup | 30-60 min | 10 min | 10 min |

Migration : quand et si

Selenium vers Playwright : vaut la peine d'être évalué si votre suite Selenium a un coût de maintenance élevé lié à la gestion des drivers et aux utilitaires d'attente. La migration n'est pas triviale. Les page objects et la logique de test peuvent être portés, mais les locators doivent être réécrits. Faites-le fonctionnalité par fonctionnalité, pas tout d'un coup. Cypress vers Playwright : à envisager si vous atteignez la limite de support des navigateurs, si vous avez besoin de parallélisation gratuite, ou si vous avez régulièrement besoin de scénarios multi-onglets/multi-domaines. Si votre suite Cypress fonctionne bien et que vous ne rencontrez pas ces obstacles, le coût de migration dépasse l'avantage. Playwright vers autre chose : difficile à justifier en 2026. Playwright est activement développé, bien maintenu, et n'a pas de limites architecturales qui forceraient une migration.
Les migrations de framework ont un coût caché : réentraînement de l'équipe, réécriture des outils, changements du pipeline CI, et des semaines de "pourquoi ça échoue dans le nouveau framework". La comparaison technique n'est qu'une partie du calcul.

FAQ

Selenium va-t-il disparaître ?

Pas prochainement. Les suites de tests existantes sont trop nombreuses, et trop d'équipes ont investi dans les outils Selenium. Mais pour les nouveaux projets, ce n'est plus le premier choix.

Peut-on utiliser Playwright et Cypress dans le même projet ?

C'est possible mais déconseillé. Ça double la surface de dépendances et divise les connaissances de l'équipe. Choisissez l'un ou l'autre.

Lequel est le plus rapide ?

Playwright est généralement le plus rapide, surtout avec le sharding parallèle sur plusieurs machines. Cypress est comparable sur une seule machine. Selenium est le plus lent en raison de l'overhead du protocole WebDriver.

Lequel a le plus d'offres d'emploi ?

Selenium domine encore en nombre brut, porté par les bases de code enterprise héritées. Les offres pour Playwright croissent vite et se concentrent dans les entreprises qui construisent de nouveaux projets. Si vous ciblez les entreprises tech modernes, Playwright est de plus en plus la compétence attendue.

→ See also: Débuter avec Playwright: Vos Premiers Tests en 30 Minutes | Locators Playwright: getByRole, getByLabel, getByText, getByTestId Comparés | Playwright en 2026: Pourquoi Il Est Devenu le Framework de Tests #1 | Migrer de Selenium (ou Cypress) vers Playwright: Un Plan Pratique