Playwright vs Cypress 2026 : quel outil pour tester Next.js en production ?

#Pourquoi les tests E2E sont devenus non-négociables sur les projets Next.js B2B

Les projets Next.js B2B modernes combinent rendu serveur, rendu client, API Routes, Server Actions et parfois du streaming RSC — une complexité architecturale qui rend les tests manuels structurellement insuffisants. Un changement dans un Server Component peut casser un flux de navigation sans déclencher la moindre alerte TypeScript ou ESLint.

Selon le State of JS 2025, 68 % des équipes travaillant avec Next.js déclarent avoir au moins un test E2E en production — contre 41 % en 2022. La progression est nette : la démocratisation des outils (Playwright, Cypress) et la pression des process CI/CD y ont largement contribué.

Pour les équipes B2B, les enjeux sont concrets :

• Régressions silencieuses : une mise à jour de dépendance casse un formulaire de contact ou un tunnel de conversion sans que les tests unitaires ne le détectent.
• Fragmentation multi-navigateur : une feature fonctionne parfaitement sous Chrome et échoue sous Safari (WebKit) sur les composants de datepicker ou de modal — sans test E2E multi-navigateur, le bug n'est découvert qu'en production.
• Intégration continue sans filet : les déploiements sur Vercel preview peuvent passer sans validation fonctionnelle si aucun pipeline de tests ne bloque le merge.
• Complexité App Router : les nouveautés Next.js 16 et le paradigme App Router introduisent des comportements de rendu hybrides difficiles à couvrir sans tests E2E dédiés.

Le choix de l'outil de tests E2E n'est pas cosmétique. Il conditionne la vitesse d'écriture des tests, leur stabilité en CI, et la capacité de l'équipe à maintenir la suite à long terme.

#Cypress : architecture, forces et limites

Lancé en 2015, Cypress a largement démocratisé les tests E2E dans l'écosystème JavaScript. Sa proposition de valeur initiale était radicale : un outil qui tourne dans le navigateur, avec accès direct au DOM, aux événements et aux états applicatifs — sans pont WebDriver externe.

#Architecture Cypress

Cypress s'exécute directement dans le navigateur via une iframe. Le runner Cypress et votre application partagent la même boucle d'événements (event loop), ce qui donne accès direct aux objets JavaScript de la page, aux requêtes XHR, et au store Redux ou Zustand sans configuration supplémentaire. Cette architecture explique pourquoi les assertions Cypress sont si précises et pourquoi les erreurs sont facilement diagnosticables.

Depuis la version 12, Cypress supporte trois modes d'exécution :

• cypress open : interface GUI interactive pour le développement
• cypress run : mode headless pour CI/CD
• cypress run --component : tests de composants isolés

#Forces de Cypress

DX (Developer Experience) inégalée : l'interface de test Cypress est la meilleure du marché pour les développeurs qui débutent en testing. Le time-travel debugging permet de revenir à n'importe quelle étape du test et d'inspecter l'état exact du DOM. Les sélecteurs cy.get(), cy.contains(), cy.intercept() ont une syntaxe intentionnellement proche du langage naturel.

Cypress Component Testing (CT) : depuis la version 10, Cypress permet de tester des composants React en isolation, directement dans un vrai navigateur — sans JSDOM. Pour les équipes qui veulent une cohérence d'outil entre leurs tests de composants et leurs tests E2E, c'est un avantage réel. La configuration est simple sur Next.js avec le preset @cypress/react.

Écosystème mature : 8 ans de plugins communautaires, intégrations Storybook, Axe pour l'accessibilité, Percy pour les tests visuels. La documentation est complète et la base d'utilisateurs est large.

Stubbing de réseau facile : cy.intercept() permet d'intercepter et de mocker n'importe quelle requête HTTP sans quitter le test, ce qui simplifie les tests de scénarios d'erreur API.

#Limites de Cypress

Mono-navigateur par défaut : Cypress supporte Chrome, Firefox et Edge, mais pas WebKit/Safari nativement. Le plugin cypress-webkit existe mais reste expérimental en 2026. Pour les applications dont une part significative du trafic vient d'iOS/macOS, c'est une lacune importante.

Parallélisation coûteuse : la parallélisation des tests nécessite Cypress Cloud (anciennement Cypress Dashboard), payant au-delà de 500 runs/mois. Pour les équipes avec des pipelines CI intensifs, le coût peut devenir significatif.

Pas de contexte multi-onglets : Cypress ne peut pas gérer plusieurs onglets ou fenêtres dans le même test. Pour les flux OAuth, les pop-ups de paiement ou les workflows multi-fenêtres, cela impose des contournements complexes.

Performance CI sur les grandes suites : au-delà de 200 tests E2E, les durées de pipeline Cypress en mode séquentiel peuvent dépasser 15-20 minutes sans parallélisation Cloud.

#Playwright : architecture multi-navigateur, mode trace, API moderne

Playwright est développé par Microsoft depuis 2020. Son architecture est fondamentalement différente de Cypress : il contrôle le navigateur via le protocole CDP (Chrome DevTools Protocol) pour Chromium/Chrome et via des protocoles équivalents pour Firefox et WebKit.

#Architecture Playwright

Playwright communique avec le navigateur depuis Node.js via un processus séparé — contrairement à Cypress qui s'exécute dans le navigateur lui-même. Cette architecture externe offre plusieurs avantages structurels : isolation totale des tests, support natif multi-contexte, et capacité à interagir avec plusieurs onglets ou fenêtres dans le même test.

Le modèle d'exécution de Playwright est entièrement async/await — plus verbeux que la syntaxe chainée de Cypress mais plus prévisible et plus aligné avec les patterns JavaScript modernes.

#Multi-navigateur natif

C'est l'avantage différenciant de Playwright : Chromium, Firefox et WebKit sont supportés nativement, sans plugins expérimentaux. Un seul test peut être exécuté sur les trois navigateurs avec un simple paramètre de configuration. Pour les projets Next.js B2B dont le trafic Safari/iOS représente 20-30 % (fréquent sur les audiences cadres et dirigeants), cette couverture multi-navigateur est décisive.

// playwright.config.ts
projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  { name: 'mobile-safari', use: { ...devices['iPhone 14'] } },
]

#Mode Trace et débogage

Le mode Trace de Playwright est l'outil de diagnostic le plus puissant disponible en tests E2E en 2026. Activé via trace: 'on-first-retry', il enregistre une capture complète de chaque test échoué : screenshots à chaque action, captures réseau, log de la console, arbre du DOM à chaque étape. Le rapport est consultable via playwright show-report ou dans l'interface web trace.playwright.dev.

Cette capacité de diagnostic est particulièrement utile en CI : quand un test échoue sur la pipeline Vercel preview, le trace permet de comprendre exactement ce qui s'est passé sans avoir à reproduire localement.

#API moderne et Locators

Les Locators Playwright (introduits en v1.14) sont l'abstraction de sélection DOM la plus robuste disponible. Contrairement aux sélecteurs CSS classiques, les Locators sont auto-waiting (attente automatique que l'élément soit visible et interactif) et auto-retrying (nouvelles tentatives automatiques en cas d'état transitoire).

// Locator recommandé : accessible name (ARIA)
await page.getByRole('button', { name: 'Envoyer la demande' }).click();
await page.getByLabel('Email professionnel').fill('contact@entreprise.fr');
await page.getByText('Votre message a été envoyé').waitFor();

Ces patterns sont alignés avec les recommandations de Testing Library, ce qui facilite la migration des équipes déjà familières avec RTL.

#Playwright Component Testing

Depuis la version 1.22, Playwright propose également des tests de composants. Le setup est plus complexe que Cypress CT mais offre le même avantage de multi-navigateur sur les composants isolés — point développé en section 6.

#Tableau comparatif 2026 : Cypress vs Playwright (10 critères)

Tableau basé sur les benchmarks de l'équipe engineering Nehos, juin 2026, sur des projets Next.js App Router en production.

Le constat de ce tableau est nuancé : Playwright gagne sur les critères techniques (multi-navigateur, parallélisation, debugging CI, multi-onglets) tandis que Cypress conserve l'avantage DX pour les équipes moins expérimentées en testing.

#Intégration CI/CD : GitHub Actions, Vercel preview, rapport HTML

L'intégration CI/CD est souvent l'argument décisif dans le choix entre Playwright et Cypress. Un test E2E qui ne s'exécute pas dans la pipeline de déploiement n'a aucune valeur de garde-fou.

#Playwright sur GitHub Actions

# .github/workflows/e2e.yml
name: Tests E2E Playwright
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Build Next.js
        run: npm run build
      - name: Run Playwright tests
        run: npx playwright test
        env:
          BASE_URL: ${{ secrets.VERCEL_PREVIEW_URL }}
      - name: Upload Playwright report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Le sharding natif de Playwright permet de distribuer la suite de tests sur plusieurs workers GitHub Actions sans coût supplémentaire :

strategy:
  matrix:
    shard: [1/4, 2/4, 3/4, 4/4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }}

Une suite de 200 tests passe ainsi de 15 minutes en séquentiel à moins de 5 minutes avec 4 workers parallèles — sur les runners GitHub Actions standard (gratuits pour les repos publics, 2 000 min/mois pour les repos privés).

#Tests sur les Vercel preview deployments

Vercel génère une URL de preview unique à chaque PR. L'intégration Playwright + Vercel se configure en deux étapes :

1. Récupérer l'URL de preview via l'action amondnet/vercel-action ou le Vercel CLI dans la pipeline.
2. Passer l'URL comme variable d'environnement BASE_URL à Playwright.

// playwright.config.ts
use: {
  baseURL: process.env.BASE_URL || 'http://localhost:3000',
}

Cette configuration permet de valider chaque déploiement preview avant le merge — exactement le même URL que verra l'utilisateur final, sans mock ni environnement synthétique.

#Rapport HTML Playwright

Le rapport HTML généré par playwright test --reporter=html est l'un des meilleurs de l'industrie : chaque test échoué inclut screenshots, vidéo, trace réseau et stack trace. Il peut être publié automatiquement sur GitHub Pages ou comme artefact téléchargeable.

#Cypress sur GitHub Actions

Cypress s'intègre proprement via l'action officielle cypress-io/github-action :

- name: Run Cypress tests
  uses: cypress-io/github-action@v6
  with:
    build: npm run build
    start: npm start
    wait-on: 'http://localhost:3000'
    record: true
  env:
    CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

La parallélisation Cypress nécessite record: true et un compte Cypress Cloud — ce qui entraîne un coût au-delà du tier gratuit (500 tests/mois). Pour les équipes avec des pipelines intensifs, ce coût peut atteindre 150-400 $/mois selon le volume.

#Tests de composants : Playwright Component Testing vs Cypress CT

Les tests de composants (CT) permettent de tester des composants React en isolation — dans un vrai navigateur, sans JSDOM — avec des scénarios d'interaction proches du comportement utilisateur. Ils comblent le gap entre les tests unitaires (trop bas niveau) et les tests E2E (trop coûteux pour tester chaque variante de composant).

#Cypress Component Testing

Cypress CT est le plus mature des deux. Disponible depuis Cypress 10, il propose un preset officiel @cypress/react qui configure automatiquement Vite ou Webpack selon votre setup. La syntaxe est identique aux tests E2E Cypress — zéro courbe d'apprentissage supplémentaire pour une équipe déjà sur Cypress E2E.

// components/SearchForm.cy.jsx
import { SearchForm } from './SearchForm'

describe('SearchForm', () => {
  it('soumet la recherche avec le bon terme', () => {
    cy.mount(<SearchForm onSubmit={cy.stub().as('onSubmit')} />)
    cy.get('[data-testid="search-input"]').type('Next.js App Router')
    cy.get('[type="submit"]').click()
    cy.get('@onSubmit').should('have.been.calledWith', 'Next.js App Router')
  })
})

Point d'attention Next.js : Cypress CT utilise Vite en bundler interne pour les composants, ce qui peut créer des divergences avec le comportement réel du composant dans Next.js App Router (traitement des Server Components, directives 'use client'). Les composants testés via CT sont systématiquement traités comme des Client Components.

#Playwright Component Testing

Playwright CT (disponible depuis v1.22) utilise Vite comme bundler et prend en charge React, Vue, Svelte et Solid. La configuration est plus complexe que Cypress CT mais offre les mêmes avantages multi-navigateur que le reste de l'écosystème Playwright.

// tests/components/Button.spec.tsx
import { test, expect } from '@playwright/experimental-ct-react';
import { Button } from './Button';

test('affiche le label et déclenche le click', async ({ mount }) => {
  let clicked = false;
  const component = await mount(
    <Button onClick={() => { clicked = true; }}>Demander un devis</Button>
  );
  await component.click();
  expect(clicked).toBe(true);
});

Avantage Playwright CT : les tests de composants s'exécutent sur Chromium, Firefox ET WebKit — garantissant que votre DatePicker ou votre Modal fonctionnent de manière identique sur Safari.

#Recommandation

Pour les équipes déjà sur Cypress E2E : adoptez Cypress CT pour la cohérence de l'outillage. Pour les équipes démarrant de zéro ou déjà sur Playwright E2E : choisissez Playwright CT pour le multi-navigateur. Évitez de mélanger les deux outils — la dette de maintenance d'une double stack de testing est rarement justifiée.

#Accessibilité et performance dans les tests E2E

Les tests E2E ne servent pas uniquement à valider les flux fonctionnels. Ils constituent un point d'intégration naturel pour les audits d'accessibilité automatisés et les mesures de performance — deux dimensions directement liées aux Core Web Vitals Next.js et aux exigences réglementaires RGAA.

#Accessibilité automatisée avec axe-core

Playwright + axe-core :

import { checkA11y } from 'axe-playwright';

test('la page d'accueil est accessible RGAA', async ({ page }) => {
  await page.goto('/');
  await checkA11y(page, undefined, {
    runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa', 'best-practice'] },
  });
});

Cypress + cypress-axe :

it('la page de contact est accessible', () => {
  cy.visit('/contact')
  cy.injectAxe()
  cy.checkA11y(null, {
    runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa'] }
  })
})

Les deux intégrations axe-core sont fonctionnellement équivalentes. La différence réside dans la granularité des rapports : Playwright génère des logs structurés dans le rapport HTML avec capture du DOM incriminé, Cypress affiche les violations dans son interface GUI — plus lisible pour un débutant.

#Performance avec Playwright

Playwright permet de récupérer les métriques Web Vitals via l'API JavaScript du navigateur :

test('LCP < 2.5s sur la page d'accueil', async ({ page }) => {
  await page.goto('/', { waitUntil: 'networkidle' });
  const lcp = await page.evaluate(() => {
    return new Promise((resolve) => {
      new PerformanceObserver((list) => {
        const entries = list.getEntries();
        resolve(entries[entries.length - 1].startTime);
      }).observe({ type: 'largest-contentful-paint', buffered: true });
    });
  });
  expect(lcp).toBeLessThan(2500);
});

Ce type de test donne une mesure indicative du LCP en environnement CI — complémentaire aux audits Lighthouse mais non substituable aux mesures CrUX (Chrome User Experience Report) en production réelle.

#Intégration dans la stratégie qualité globale

Les tests d'accessibilité et de performance E2E s'inscrivent dans une démarche de qualité code garantie par IA et de productivité développeur mesurable. Les bloquer dans la pipeline CI — au même titre que les tests fonctionnels — transforme ces audits de tâche ponctuelle en garde-fou permanent.

#Configuration Next.js App Router : pièges courants à éviter

La migration vers l'App Router Next.js introduit des comportements de rendu hybrides qui piègent les configurations de tests E2E mal adaptées. Voici les erreurs les plus fréquentes observées en mission chez Nehos.

#Piège 1 : tester les Server Components comme des Client Components

Les React Server Components (RSC) ne sont pas accessibles via window ou les APIs JavaScript côté client. Un test qui tente de cy.window().its('__NEXT_DATA__') pour vérifier des données RSC va systématiquement échouer ou produire des faux positifs.

Solution : cibler les sorties HTML rendues côté serveur plutôt que les états JavaScript côté client.

// Correct : vérifier le contenu rendu par le RSC dans le DOM
await expect(page.getByTestId('product-list')).toContainText('12 résultats');

// Incorrect : tenter d'accéder aux données RSC via window.__NEXT_DATA__
const data = await page.evaluate(() => window.__NEXT_DATA__);

#Piège 2 : waitForNetworkIdle cassé avec le streaming RSC

Next.js App Router utilise le streaming HTTP (React Suspense + server-side streaming). L'instruction waitForNetworkIdle attend que toutes les requêtes réseau soient terminées — mais avec le streaming RSC, les chunks HTML arrivent progressivement, ce qui fait que waitForNetworkIdle peut se déclencher avant que le contenu complet soit rendu.

Solution : attendre explicitement les éléments cibles plutôt que l'état du réseau.

// Incorrect avec streaming RSC
await page.goto('/tableau-de-bord', { waitUntil: 'networkidle' });

// Correct : attendre l'élément final du rendu
await page.goto('/tableau-de-bord');
await page.getByTestId('dashboard-stats').waitFor({ state: 'visible' });

#Piège 3 : interception des Server Actions avec cy.intercept

Les Server Actions Next.js utilisent des endpoints POST générés dynamiquement. Intercepter ces requêtes avec cy.intercept('POST', '/*') peut capturer les Server Actions et les mocker involontairement, produisant des tests qui passent en local mais échouent sur l'environnement Vercel preview.

Solution : cibler les Server Actions par leur identifiant ou passer par des tests d'intégration plutôt que de mocker les Server Actions dans les tests E2E.

#Piège 4 : cookies de session non persistés entre les pages

Dans l'App Router, la navigation client-side via <Link> ne recharge pas la page mais peut changer le contexte de rendu. Les tests qui supposent que les cookies de session sont automatiquement transmis à tous les Server Components doivent configurer explicitement le contexte d'authentification.

// playwright.config.ts — authFile pour la persistance de session
use: {
  storageState: 'playwright/.auth/user.json',
}

// test de setup auth (à exécuter une seule fois)
setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('test@nehos-groupe.com');
  await page.getByLabel('Mot de passe').fill(process.env.TEST_PASSWORD!);
  await page.getByRole('button', { name: 'Se connecter' }).click();
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

#Piège 5 : baseURL non configurée en CI

L'erreur la plus fréquente sur les premières configurations CI : les tests s'exécutent avant que le serveur Next.js soit prêt, ou avec localhost:3000 comme URL alors que l'environnement CI utilise une URL preview Vercel.

Solution : systématiser l'utilisation de baseURL avec variable d'environnement et valeur de fallback.

Ces pièges de configuration touchent directement la qualité des Server Components Next.js et la stratégie de Partial Prerendering. Les tester correctement requiert une compréhension fine du cycle de rendu.

#Recommandation Nehos : setup recommandé selon la taille de l'équipe

Après avoir livré plus de 30 projets Next.js B2B avec des niveaux de maturité testing variés, voici la recommandation que nous appliquons selon le contexte client.

#Équipe 1-3 développeurs, projet greenfield

Recommandation : Playwright dès le départ.

Pour un projet Next.js App Router qui démarre, Playwright offre le meilleur ratio effort/valeur sur le long terme. Le setup initial est légèrement plus complexe que Cypress (15-30 minutes de plus), mais les économies en CI (parallélisation gratuite, pas d'abonnement Cloud) et la couverture WebKit le justifient pleinement.

Setup recommandé :

• @playwright/test avec sharding natif
• GitHub Actions avec ubuntu-latest (3 navigateurs compris)
• storageState pour l'authentification
• Rapport HTML publié comme artefact
• 20-30 tests E2E couvrant les flux critiques (auth, formulaires, tunnel de conversion)

#Équipe 4-10 développeurs, stack mixte junior/senior

Recommandation : Cypress comme outil principal, Playwright pour les tests multi-navigateur critiques.

Si l'équipe manque d'expérience en testing, la DX Cypress réduit la friction d'adoption. Les développeurs junior adoptent Cypress plus rapidement grâce à l'interface GUI et à la syntaxe lisible. Réserver Playwright pour les parcours utilisateur critiques nécessitant une validation WebKit (paiement, signature de contrat, tunnel B2B).

Setup recommandé :

• Cypress pour les tests de composants et les flux UX généraux
• Playwright pour 5-10 tests E2E cross-browser sur les chemins critiques
• Cypress Cloud jusqu'à 500 runs/mois (tier gratuit)

#Équipe 10+ développeurs, monorepo, CI/CD avancé

Recommandation : Playwright exclusivement.

À cette échelle, la parallélisation native et le coût nul du sharding Playwright sont déterminants. Le budget qui serait alloué à Cypress Cloud (150-400 $/mois) est réinvesti en runners GitHub Actions supplémentaires pour accélérer la pipeline.

Setup recommandé :

• Playwright avec sharding 4-8 workers selon la taille de la suite
• Tests organisés par domaine fonctionnel (auth, catalog, checkout, admin)
• Intégration Vercel preview pour valider chaque PR
• @axe-core/playwright pour les audits accessibilité automatisés
• Rapport HTML archivé 30 jours
• Couverture cible : 80 % des flux critiques, 100 % des flux de conversion

#Migration de Cypress vers Playwright

Pour les projets existants sous Cypress, la migration vers Playwright ne nécessite pas un remplacement brutal. La stratégie que nous appliquons chez Nehos :

1. Garder les tests Cypress existants sans les modifier
2. Écrire les nouveaux tests directement en Playwright
3. Migrer les anciens tests au fil du temps, prioritairement ceux qui échouent le plus souvent en CI
4. Supprimer Cypress quand la suite Playwright couvre 90 % des scénarios

Cette approche évite les migrations risquées et le double coût de maintenance transitoire ne dure généralement que 2-3 mois.

Ces recommandations s'inscrivent dans notre approche globale de refonte de sites B2B et de gestion de la dette technique. La mise en place d'une stratégie de tests E2E robuste est systématiquement incluse dans nos projets Next.js B2B et dans les setups proposés à la suite d'un audit avec les outils IA comme Cursor ou Claude Code.