« 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.
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-renduLe 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.
