Stratégies de Tests Cross-Browser: Quand et Comment Tester sur Plusieurs Navigateurs

La stratégie de test cross-browser se résume à savoir où se trouvent vos utilisateurs et quelles différences de rendu comptent pour votre application. La vraie question : quelles fonctionnalités nécessitent WebKit plutôt qu'un run Chromium uniquement ?

Pourquoi les navigateurs diffèrent encore

Les navigateurs modernes (Chrome, Firefox, Safari, Edge) supportent tous les mêmes standards HTML, CSS et JavaScript. Mais des différences subsistent.

Parts de marché des navigateurs (2025)

| Navigateur | Desktop | Mobile |

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

| Chrome | ~65% | ~66% |

| Safari | ~12% | ~27% |

| Firefox | ~3% | ~1% |

| Edge | ~13% | ~3% |

La stratégie pragmatique

Impossible de tout tester dans chaque navigateur. Voici une hiérarchie pratique.

Niveau 1 : toujours tester (chaque sprint)

Chrome représente la plus grande part de marché et sert de navigateur principal de développement. Safari est critique pour les utilisateurs iOS et macOS.

Niveau 2 : tester avant les releases majeures

Firefox a une part de marché plus petite mais un rendu distinct. Edge, basé sur Chromium, présente un risque additionnel faible.

Niveau 3 : tester pour des fonctionnalités spécifiques

Safari iOS et Chrome Android pour les flux spécifiques au mobile. Les versions spécifiques de navigateurs uniquement quand des clients enterprise les exigent.

Configuration cross-browser dans Playwright

Playwright supporte Chrome, Firefox et WebKit (le moteur de Safari) nativement :

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

export default defineConfig({
  projects: [
    // Navigateurs desktop
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
    
    // Navigateurs mobiles
    {
      name: 'mobile-chrome',
      use: { ...devices['Pixel 7'] },
    },
    {
      name: 'mobile-safari',
      use: { ...devices['iPhone 14'] },
    },
  ],
});

Lancer un navigateur spécifique :

npx playwright test --project=webkit

Lancer tous les navigateurs :

npx playwright test

Ce qu'il faut tester cross-browser (et ce qui n'en a pas besoin)

• Flux utilisateurs principaux (connexion, paiement, parcours clés)
• Formulaires, surtout les sélecteurs de date, les uploads de fichier, les selects
• Mises en page CSS, notamment les designs à base de flex/grid
• Fonctionnalités à forte charge JavaScript (interactions complexes)
• Flux spécifiques au mobile (touch, viewport, orientation)

• Tests unitaires : indépendants du navigateur
• Tests API : aucun navigateur impliqué
• Tests de logique backend
• Outils d'administration internes que seule votre équipe utilise

Gérer les échecs spécifiques à un navigateur

Quand un test échoue dans un seul navigateur :

test('upload de fichier', async ({ page, browserName }) => {
  // Ignorer dans WebKit : le comportement des inputs fichier diffère significativement
  test.skip(browserName === 'webkit', 'WebKit gère les inputs fichier différemment');
  
  await page.goto('/upload');
  await page.setInputFiles('[data-testid="file-input"]', 'test-file.pdf');
  await expect(page.getByTestId('upload-success')).toBeVisible();
});

Quand vous avez besoin d'un comportement spécifique à un navigateur :

test('le sélecteur de date fonctionne', async ({ page, browserName }) => {
  await page.goto('/book-appointment');
  
  if (browserName === 'webkit') {
    // Le sélecteur de date de Safari nécessite une interaction différente
    await page.fill('[data-testid="date-input"]', '2026-06-15');
  } else {
    await page.click('[data-testid="date-input"]');
    await page.click('[data-date="2026-06-15"]');
  }
  
  await expect(page.getByTestId('selected-date')).toContainText('15 juin');
});

BrowserStack et Sauce Labs

Les navigateurs intégrés de Playwright utilisent des versions open source. Pour tester sur le vrai Chrome (pas Chromium), le vrai Safari, et des versions spécifiques de navigateurs, utilisez des services de test cloud.

BrowserStack

// playwright.config.ts pour BrowserStack
const capabilities = {
  'browserstack.user': process.env.BROWSERSTACK_USERNAME,
  'browserstack.key': process.env.BROWSERSTACK_ACCESS_KEY,
};

export default defineConfig({
  projects: [
    {
      name: 'chrome@latest-mac',
      use: {
        connectOptions: {
          wsEndpoint: `wss://cdp.browserstack.com/playwright?caps=${encodeURIComponent(JSON.stringify({
            ...capabilities,
            browserName: 'chrome',
            browserVersion: 'latest',
            'bstack:options': {
              os: 'OS X',
              osVersion: 'Sonoma',
            }
          }))}`,
        },
      },
    },
  ],
});

Quand les services cloud valent l'investissement

• Vous avez besoin du vrai Safari (pas WebKit) sur le vrai macOS
• Une version Chrome spécifique (clients enterprise bloqués sur Chrome 110)
• Tests sur vrai appareil iOS (pas simulateur)
• Support IE11 (rare, mais existe encore en finance et administration publique)

Tests responsives

Testez à plusieurs tailles de viewport, pas seulement mobile vs desktop :

// playwright.config.ts
projects: [
  {
    name: 'desktop',
    use: { viewport: { width: 1920, height: 1080 } },
  },
  {
    name: 'laptop',
    use: { viewport: { width: 1280, height: 720 } },
  },
  {
    name: 'tablet',
    use: { viewport: { width: 768, height: 1024 } },
  },
  {
    name: 'mobile',
    use: { viewport: { width: 375, height: 667 } },  // iPhone SE
  },
],

Dans un test :

test('la navigation fonctionne sur mobile', async ({ page }) => {
  await page.setViewportSize({ width: 375, height: 667 });
  await page.goto('/');
  
  // Mobile : menu hamburger au lieu de la barre de navigation
  await expect(page.getByTestId('hamburger-menu')).toBeVisible();
  await expect(page.getByTestId('desktop-nav')).not.toBeVisible();
  
  await page.getByTestId('hamburger-menu').click();
  await expect(page.getByTestId('mobile-nav')).toBeVisible();
});

Gérer les échecs cross-browser en CI

Lancez les navigateurs en parallèle pour garder la CI rapide :

# Stratégie de matrix GitHub Actions
strategy:
  matrix:
    browser: [chromium, firefox, webkit]

steps:
  - run: npx playwright test --project=${{ matrix.browser }}

Ou shardez les tests cross-browser :

strategy:
  matrix:
    include:
      - browser: chromium
        shard: 1/2
      - browser: chromium  
        shard: 2/2
      - browser: firefox
        shard: 1/1  # Moins de tests Firefox
      - browser: webkit
        shard: 1/1

Tests visuels cross-browser

Les différences de rendu CSS sont souvent subtiles. La comparaison manuelle est fastidieuse. Utilisez Percy ou la comparaison de captures d'écran de Playwright :

test('la page d\'accueil s\'affiche correctement', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveScreenshot('homepage.png', {
    maxDiffPixelRatio: 0.02,  // 2% de différence de pixels autorisée
  });
});

Les captures d'écran sont stockées par projet : chaque navigateur obtient sa propre baseline.

Récapitulatif

1. Lancer la suite complète dans Chrome à chaque commit

2. Lancer Chrome + Safari avant chaque release

3. Lancer tous les navigateurs (Firefox, Edge inclus) avant les releases majeures

4. Tester les viewports mobiles pour les fonctionnalités responsives

• Définissez des projets pour chaque navigateur
• La fixture browserName pour le code spécifique à un navigateur
• test.skip() pour les incompatibilités connues
• WebKit intégré = Safari sans macOS requis

L'objectif n'est pas de tout tester dans chaque navigateur. C'est de détecter les bugs spécifiques aux navigateurs qui affectent réellement vos utilisateurs, avec le temps dont vous disposez.