Playwright : le guide en français pour débuter l'automatisation des tests web

C'est quoi Playwright ?

Playwright est un framework de test open source, développé par Microsoft et publié sous licence Apache 2.0, qui pilote les navigateurs Chromium, Firefox et WebKit pour automatiser des tests de bout en bout sur Windows, Linux et macOS (source : dépôt GitHub microsoft/playwright, consulté le 29 septembre 2026). Il s'utilise en TypeScript/JavaScript, Python, Java et .NET. Son lanceur de tests, Playwright Test, fournit tout ce qu'il faut pour écrire, exécuter et déboguer une suite : assertions, parallélisation, rapports et traces.

Ce que Playwright sait faire

• Tester sur trois moteurs de navigateur avec une seule base de code : Chromium (Chrome, Edge), Firefox et WebKit (le moteur de Safari), en mode visible ou sans interface, en local ou en CI, avec une émulation mobile pour Chrome Android et Mobile Safari (source : playwright.dev, consulté le 29 septembre 2026).
• Attendre automatiquement que les éléments soient prêts avant d'agir, et réessayer les assertions jusqu'à ce qu'elles passent.
• Isoler chaque test dans un contexte de navigateur neuf, ce qui évite les effets de bord entre tests.
• Paralléliser l'exécution par défaut sur tous les navigateurs configurés (source : playwright.dev, consulté le 29 septembre 2026).
• Générer du code en enregistrant vos actions (codegen) et rejouer une exécution pas à pas (Trace Viewer).
• Tester des API HTTP avec le même lanceur que les tests d'interface.
• Donner la main à des agents IA via un serveur MCP qui expose le navigateur sous forme d'instantanés d'accessibilité (source : playwright.dev, consulté le 29 septembre 2026).

Si vous découvrez le sujet, commencez par notre guide Automatisation des tests : définition, outils, étapes, qui explique où se situent les tests Playwright dans une stratégie de test complète.

Comment installer Playwright ?

Pour installer Playwright, il suffit d'avoir Node.js et de lancer npm init playwright@latest dans un dossier de projet : l'assistant installe Playwright Test et les navigateurs, crée un fichier de configuration et un premier test d'exemple, et propose d'ajouter un workflow GitHub Actions.

npm init playwright@latest

L'assistant vous demande de choisir entre TypeScript et JavaScript (prenez TypeScript), le nom du dossier de tests et l'ajout d'un workflow GitHub Actions. Il génère notamment (source : playwright.dev, consulté le 29 septembre 2026) :

• playwright.config.ts : la configuration (navigateurs, URL de base, rapports, traces) ;
• package.json et package-lock.json ;
• tests/example.spec.ts : un premier test prêt à lancer.

Vérifiez les prérequis système avant d'installer : la documentation demande une version récente de Node.js (22.x, 24.x ou 26.x au moment de notre consultation) et un système Windows 11+, macOS 14+ ou une distribution Linux récente (Debian 12/13, Ubuntu 22.04 ou plus récent) (source : playwright.dev, consulté le 29 septembre 2026).

Lancer les tests

npx playwright test            # exécute toute la suite, sans interface
npx playwright test --headed   # affiche les navigateurs pendant l'exécution
npx playwright test --ui       # ouvre le mode UI, idéal pour apprendre et déboguer
npx playwright show-report     # ouvre le rapport HTML de la dernière exécution

Le fichier de configuration

Voici une configuration courte et commentée. baseURL permet d'écrire page.goto('/login') au lieu de l'URL complète, et trace: 'on-first-retry' enregistre une trace quand un test échoue puis est relancé :

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  reporter: 'html',
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  ],
});

Comment écrire son premier test Playwright ?

Un test Playwright est une fonction asynchrone déclarée avec test(), qui reçoit un objet page, effectue des actions avec await puis vérifie le résultat avec expect(). Le fichier doit se terminer par .spec.ts pour être détecté par le lanceur.

Le test d'exemple généré à l'installation ressemble à ceci :

import { test, expect } from '@playwright/test';

test('a un titre', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);
});

test('lien Get started', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await page.getByRole('link', { name: 'Get started' }).click();
  await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
});

Lire ce test ligne par ligne

• test('…', async ({ page }) => { … }) déclare un test et reçoit une page de navigateur neuve, isolée des autres tests.
• await page.goto(…) ouvre l'URL. Chaque action est une promesse : sans await, le test continuerait sans attendre.
• page.getByRole('link', { name: 'Get started' }) cible le lien comme le ferait un utilisateur ou un lecteur d'écran.
• await expect(…).toBeVisible() est une assertion « web-first » : elle réessaie jusqu'à ce que la condition soit vraie ou que le délai expire.

Un scénario plus réaliste : la connexion

import { test, expect } from '@playwright/test';

test('connexion réussie', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('E-mail').fill('qa@exemple.fr');
  await page.getByLabel('Mot de passe').fill('motdepasse-de-test');
  await page.getByRole('button', { name: 'Se connecter' }).click();

  await expect(page).toHaveURL(/\/tableau-de-bord/);
  await expect(page.getByRole('heading', { name: 'Tableau de bord' })).toBeVisible();
});

Remarquez qu'aucune pause n'est écrite : Playwright attend lui-même que le champ soit prêt, que le bouton soit cliquable et que le titre apparaisse.

Comment cibler les éléments avec les locators Playwright ?

Les locators Playwright ciblent les éléments comme un utilisateur les perçoit : par rôle et nom accessible (getByRole), par libellé de formulaire (getByLabel), par texte (getByText) ou par attribut de test (getByTestId). Ils sont préférables aux sélecteurs CSS ou XPath, qui cassent au moindre changement de structure de la page.

Enchaîner et filtrer

Les locators se combinent. Pour cliquer sur le bouton d'une ligne précise dans une liste :

const ligne = page.getByRole('listitem').filter({ hasText: 'Formation Playwright' });
await ligne.getByRole('button', { name: 'Ajouter au panier' }).click();
await expect(page.getByTestId('panier-total')).toHaveText('1 article');

Un locator n'est pas l'élément lui-même : c'est une description, réévaluée à chaque utilisation. Vous pouvez donc le déclarer une fois et le réutiliser après un rechargement de page sans erreur d'élément « périmé ». Pour les suites importantes, on range ces locators dans des classes de Page Object Model, un modèle enseigné dans la formation Playwright certifiante.

Comment fonctionne l'attente automatique de Playwright ?

Avant chaque action, Playwright vérifie automatiquement que l'élément est prêt (« actionability checks ») et attend si ce n'est pas le cas ; les assertions web-first, elles, réessaient jusqu'à ce que la condition soit vraie. Résultat : pas de sleep() ni d'attente fixe à écrire, et beaucoup moins de tests instables.

Les vérifications avant un clic

Avant un click(), Playwright s'assure que le locator correspond à exactement un élément, que cet élément est visible, stable (pas en cours d'animation), qu'il reçoit les événements (rien ne le recouvre) et qu'il est activé ; il attend que toutes ces conditions soient réunies ou échoue à l'expiration du délai (source : playwright.dev, consulté le 29 septembre 2026).

Assertions web-first contre vérifications ponctuelles

// Recommandé : réessaie jusqu'à ce que le texte apparaisse
await expect(page.getByText('Paiement accepté')).toBeVisible();

// À éviter : lit l'état une seule fois, échoue si la page n'est pas encore à jour
expect(await page.getByText('Paiement accepté').isVisible()).toBe(true);

La première forme attend ; la seconde photographie l'état à un instant donné. C'est l'erreur la plus fréquente des débutants, et la cause de nombreux tests qui « passent parfois ».

À quoi servent codegen et le Trace Viewer ?

Codegen est le générateur de tests de Playwright : il ouvre un navigateur, enregistre vos actions et écrit le code correspondant en choisissant les meilleurs locators. Le Trace Viewer est l'outil de débogage : il rejoue une exécution enregistrée action par action, avec l'état de la page, les requêtes réseau, la console et les captures.

Générer un test avec codegen

npx playwright codegen demo.playwright.dev/todomvc

Deux fenêtres s'ouvrent : le navigateur, où vous cliquez et saisissez, et l'inspecteur, où le code s'écrit en direct (source : playwright.dev, consulté le 29 septembre 2026). Codegen est excellent pour trouver un locator ou démarrer un scénario, mais relisez toujours le résultat : il enregistre ce que vous faites, pas ce qu'il faut vérifier. Les assertions restent votre travail.

Déboguer avec le Trace Viewer

npx playwright test --trace on               # enregistre une trace pour chaque test
npx playwright show-report                   # ouvre le rapport, puis l'icône de trace d'un test
npx playwright show-trace chemin/vers/trace.zip

Le Trace Viewer permet d'avancer et de reculer dans chaque action du test et de voir ce qui se passait à ce moment-là (source : playwright.dev, consulté le 29 septembre 2026). Avec trace: 'on-first-retry' dans la configuration, une trace est produite automatiquement quand un test échoue en CI : vous diagnostiquez l'échec sans le reproduire sur votre poste.

Peut-on tester une API avec Playwright ?

Oui : Playwright fournit une fixture request qui envoie des requêtes HTTP (GET, POST, PUT, DELETE…) sans ouvrir de navigateur, avec le même lanceur, les mêmes assertions et les mêmes rapports que les tests d'interface. On l'utilise pour tester une API directement ou pour préparer des données avant un scénario d'interface.

import { test, expect } from '@playwright/test';

test('crée un utilisateur via l\'API', async ({ request }) => {
  const reponse = await request.post('/api/utilisateurs', {
    data: { nom: 'Ada', email: 'ada@exemple.fr' },
  });
  await expect(reponse).toBeOK();

  const corps = await reponse.json();
  expect(corps.email).toBe('ada@exemple.fr');
});

L'URL de base et les en-têtes communs (jeton d'authentification, par exemple) se déclarent une fois dans la configuration avec baseURL et extraHTTPHeaders, puis s'appliquent à toutes les requêtes de la fixture (source : playwright.dev, consulté le 29 septembre 2026). Pour comparer avec Postman et REST Assured, lisez Tests API : définition, outils et exemples.

Comment lancer Playwright dans GitHub Actions ?

Pour lancer Playwright dans GitHub Actions, ajoutez au dépôt un fichier .github/workflows/playwright.yml qui installe les dépendances, installe les navigateurs avec npx playwright install --with-deps, exécute npx playwright test et publie le rapport comme artefact. L'installateur npm init playwright@latest peut créer ce fichier pour vous.

Le workflow proposé par la documentation officielle (source : playwright.dev, consulté le 29 septembre 2026) :

name: Playwright Tests
on:
  push:
    branches: [ main, master ]
  pull_request:
    branches: [ main, master ]
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v6
    - uses: actions/setup-node@v6
      with:
        node-version: lts/*
    - name: Install dependencies
      run: npm ci
    - name: Install Playwright Browsers
      run: npx playwright install --with-deps
    - name: Run Playwright tests
      run: npx playwright test
    - uses: actions/upload-artifact@v4
      if: ${{ !cancelled() }}
      with:
        name: playwright-report
        path: playwright-report/
        retention-days: 30

À chaque push ou pull request, la suite tourne sur une machine Linux fraîche et le rapport HTML (avec les traces des tests relancés) reste téléchargeable 30 jours. Pour GitLab CI, Jenkins et les bonnes pratiques de pipeline, voir Tests automatisés dans un pipeline CI/CD.

Playwright, Cypress ou Selenium : lequel choisir ?

Pour un nouveau projet ou pour apprendre en 2026, Playwright est le choix le plus complet : trois moteurs de navigateur, quatre langages, attente automatique et parallélisation incluses. Cypress reste pertinent dans les équipes front-end JavaScript, notamment pour les tests de composants ; Selenium domine les suites existantes et les environnements multi-langages historiques.

Les détails, sources à l'appui, sont dans nos deux comparatifs : Playwright vs Cypress : lequel choisir en 2026 ? et Playwright vs Selenium : faut-il encore apprendre Selenium ?

Comment apprendre Playwright ?

Pour apprendre Playwright, commencez par un contenu guidé et gratuit, pratiquez sur une application de démonstration, puis structurez vos acquis (Page Object Model, tests d'API, CI) dans un projet que vous pourrez montrer. Comptez quelques semaines de pratique régulière pour être à l'aise sur les bases.

1. Découvrir gratuitement. Le mini-cours Playwright gratuit d'ADC propose 7 leçons de 7 minutes, sans engagement : c'est le premier module de notre formation certifiante.
2. Pratiquer sur une application de démonstration. Automatisez un parcours complet (connexion, ajout au panier, validation) avec des locators par rôle et des assertions web-first.
3. Structurer. Passez au Page Object Model, factorisez la connexion, ajoutez des tests d'API pour préparer vos données.
4. Industrialiser. Branchez la suite dans GitHub Actions, activez les traces, rendez vos rapports lisibles.
5. Valider. La formation Playwright certifiante d'ADC couvre ce parcours en 40 heures et 6 modules : fondamentaux, Page Object Model, tests d'API et parallélisation, CI/CD avec GitHub Actions, rapports et débogage, puis un projet de certification.

Si votre objectif est un changement de métier, la formation Testeur QA Automatisation & IA (399 heures sur 12 semaines) intègre Playwright avec TypeScript dans un parcours complet : conception de tests, tests d'API, CI, IA appliquée au test et examens ISTQB CTFL v4.0 et CT-GenAI v1.1 inclus.

Questions fréquentes sur Playwright

Playwright est-il gratuit ?

Oui. Playwright est un projet open source de Microsoft publié sous licence Apache 2.0 : la bibliothèque, le lanceur Playwright Test, codegen et le Trace Viewer sont gratuits, y compris pour un usage commercial.

Quel langage choisir pour apprendre Playwright ?

TypeScript est le choix le plus courant : c'est le langage de référence de la documentation et celui du lanceur Playwright Test. Playwright existe aussi en Python, Java et .NET si votre équipe utilise déjà l'un de ces langages. ADC enseigne Playwright avec TypeScript.

Playwright fonctionne-t-il avec Safari ?

Playwright pilote WebKit, le moteur de rendu de Safari, sur Windows, Linux et macOS, ainsi qu'une émulation de Mobile Safari. Il ne pilote pas l'application Safari elle-même, mais WebKit permet de détecter les problèmes propres à ce moteur.

Faut-il savoir coder pour utiliser Playwright ?

Oui, les bases suffisent pour commencer : variables, fonctions, async/await. Codegen aide à écrire les premières lignes en enregistrant vos actions, mais il faut savoir relire et corriger le code et écrire les assertions. Le mini-cours gratuit d'ADC est conçu pour des débutants.

Playwright peut-il remplacer Postman pour les tests d'API ?

Pour les tests d'API automatisés dans la CI, souvent oui : la fixture request envoie des requêtes HTTP avec les mêmes assertions et rapports que les tests d'interface. Postman reste pratique pour explorer et documenter une API à la main.

Combien de temps faut-il pour apprendre Playwright ?

Quelques semaines de pratique régulière pour être à l'aise avec les bases : locators, assertions, configuration et CI. La formation Playwright certifiante d'ADC couvre le parcours complet en 40 heures, projet de certification compris.

Toutes les questions fréquentes : prix, ISTQB, cours du soir, reconversion