# Tests E2E multi-navigateurs avec un petit budget : notre organisation

> Retour d'expérience sur la couverture Chromium, Firefox et WebKit en CI pour une petite agence : sélection des scénarios, parallélisation et coûts réels observés.

- Auteur : Clément Hadrot
- Publié le : 2026-02-05
- Mis à jour le : 2026-02-05
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tests-e2e-multinavigateurs-petit-budget/

## L’essentiel

- Tous les scénarios ne méritent pas d'être rejoués sur les trois moteurs
- La parallélisation par navigateur coûte des minutes de CI, pas du temps humain
- Un budget mensuel de minutes de CI se pilote comme n'importe quel autre budget

« On teste sur Firefox et Safari aussi ? » La question s'est posée sur un projet client dont l'analytics montrait qu'environ 15 % du trafic venait de Safari sur mobile, une part trop significative pour l'ignorer, mais avec un budget de CI compté à l'agence, impossible de simplement tripler le temps d'exécution de la suite E2E existante sans réfléchir à ce qui devait réellement être couvert sur chaque moteur.

Voici comment on a organisé cette couverture multi-navigateurs sur ce projet précis, avec les compromis assumés et les coûts observés sur trois mois d'exploitation réelle, plutôt qu'une estimation théorique.

## Premier principe : tout ne mérite pas d'être rejoué trois fois

La tentation naturelle consiste à faire tourner l'intégralité de la suite E2E sur Chromium, Firefox et WebKit systématiquement. C'est ce qu'on a fait au départ, avant de constater que le temps de CI avait triplé pour un bénéfice réel très concentré sur une poignée de scénarios seulement. La majorité des régressions détectées sur plusieurs mois ne dépendait d'aucune spécificité de moteur de rendu : un bouton mal câblé, une requête AJAX qui échoue, un calcul de panier faux, se reproduit identiquement sur les trois navigateurs.

On a donc classé les scénarios en deux catégories distinctes, avec un tag Playwright dédié pour les distinguer explicitement dans la configuration :

- **Scénarios « logique métier »**, qui vérifient un comportement fonctionnel indépendant du rendu : ces scénarios tournent uniquement sur Chromium en routine, le moteur le plus rapide à démarrer
- **Scénarios « rendu et interaction fine »**, qui touchent au CSS complexe, aux formulaires natifs, aux dates ou aux inputs spécifiques : ces scénarios seuls tournent sur les trois moteurs

## Configurer Playwright pour ce découpage

```
export default defineConfig({
  projects: [
    {
      name: 'chromium-complet',
      use: { ...devices['Desktop Chrome'] },
      testMatch: /.*\.spec\.ts/,
    },
    {
      name: 'firefox-rendu',
      use: { ...devices['Desktop Firefox'] },
      testMatch: /.*\.rendu\.spec\.ts/,
    },
    {
      name: 'webkit-rendu',
      use: { ...devices['Desktop Safari'] },
      testMatch: /.*\.rendu\.spec\.ts/,
    },
  ],
});
```

La convention de nommage `.rendu.spec.ts` pour les fichiers concernés rend le découpage visible directement dans l'arborescence du projet, sans avoir à consulter la configuration pour savoir quels scénarios tournent sur quels moteurs.

> L'essentiel à retenir : Tous les scénarios ne méritent pas d'être rejoués sur les trois moteurs ; La parallélisation par navigateur coûte des minutes de CI, pas du temps humain ; Un budget mensuel de minutes de CI se pilote comme n'importe quel autre budget

## Paralléliser sans multiplier le temps d'attente

Une fois les scénarios classés, la parallélisation en CI consiste à lancer les trois projets Playwright dans des jobs séparés et simultanés, plutôt que séquentiellement dans un seul job. Le temps d'attente total pour l'équipe reste proche de celui du scénario le plus long des trois, pas la somme des trois :

```
e2e-chromium:
  stage: e2e
  script: npx playwright test --project=chromium-complet

e2e-firefox:
  stage: e2e
  script: npx playwright test --project=firefox-rendu

e2e-webkit:
  stage: e2e
  script: npx playwright test --project=webkit-rendu
```

## Le coût réel observé sur trois mois

| Configuration | Minutes de CI / mois | Scénarios couverts |
| --- | --- | --- |
| Tout sur Chromium seul (avant) | ≈ 340 | 60 scénarios |
| Tout sur 3 navigateurs (essai initial) | ≈ 970 | 60 scénarios × 3 |
| Découpage logique / rendu (retenu) | ≈ 520 | 60 + 18 scénarios rendu × 3 |

Le découpage retenu représente une hausse de 53 % du temps de CI par rapport à la configuration Chromium seul, contre près de 185 % pour une couverture totale sur les trois moteurs, pour une couverture des risques réels jugée équivalente par l'équipe après plusieurs mois de recul.

## Réduire encore : exécuter le multi-navigateurs uniquement sur certaines branches

Pour resserrer davantage le budget, une option complémentaire consiste à ne déclencher les jobs Firefox et WebKit que sur les pull requests qui touchent effectivement à des fichiers CSS ou à des composants de formulaire, via une règle de déclenchement conditionnelle basée sur les chemins modifiés, et à les faire tourner systématiquement sur la branche principale avant chaque déploiement, quel que soit le contenu modifié.

> Un budget de CI, comme n'importe quel autre budget, se pilote mieux en décidant explicitement ce qu'on ne teste pas plutôt qu'en réduisant vaguement « un peu partout » sans base de décision claire.

## Ce qu'on referait différemment

Avec le recul, la première erreur a été de partir directement sur une couverture totale des trois moteurs sans mesurer d'abord combien de régressions réelles étaient spécifiques au rendu, plutôt qu'à la logique métier. Cette mesure préalable, qui aurait pu se faire en analysant l'historique des bugs remontés en production sur les mois précédents, aurait évité l'aller-retour coûteux en temps d'ingénierie observé sur ce projet.

## Notre verdict

Pour une petite structure avec un budget de CI limité, la couverture multi-navigateurs gagne à être ciblée plutôt qu'exhaustive : classer les scénarios selon qu'ils dépendent réellement du moteur de rendu, paralléliser les jobs plutôt que les enchaîner, et restreindre le déclenchement des navigateurs secondaires aux modifications qui les concernent vraiment. Ce n'est pas la solution la plus rassurante en apparence, mais c'est celle qui a tenu dans la durée sans faire exploser le budget mensuel de la CI.