Test cross-browser : une checklist pratique et des outils gratuits

Le test cross-browser consiste à vérifier qu’un site s’affiche et fonctionne correctement dans les navigateurs de vos visiteurs, sur les appareils qu’ils utilisent. En pratique, cela représente trois moteurs de rendu (Blink pour Chromium, WebKit pour Safari et Gecko pour Firefox), sur ordinateur et sur mobile. Vous pouvez en couvrir l’essentiel gratuitement avec les navigateurs installés, Playwright et un affichage mobile, et ne payer des appareils dans le cloud que lorsque vous avez besoin d’un vrai matériel que vous ne possédez pas.

Quels navigateurs tester

Partez de vos propres statistiques, pas d’un classement mondial. Un tableau de bord B2B peut être utilisé surtout dans Chrome et Edge sur ordinateur, alors qu’une boutique grand public verra surtout Safari sur iPhone. Regardez les rapports navigateurs et appareils des trois derniers mois et couvrez tout ce qui dépasse quelques pour cent des sessions.

Si vous n’avez pas encore de données, cet ensemble couvre les moteurs et la majeure partie du trafic réel :

Deux moteurs méritent le plus d’attention : WebKit, à cause de l’iPhone, et Gecko, seul grand moteur qui n’appartient ni à Apple ni à Google.

Quoi vérifier dans chaque navigateur

Les bugs cross-browser se concentrent à des endroits prévisibles. Passez cette liste sur chaque page clé :

1. Mise en page. Les gap en flexbox et en grid, position: sticky, aspect-ratio et les container queries dans les anciennes versions des navigateurs.
2. Polices. Les polices web se chargent, les polices de secours ont des métriques proches, pas de texte invisible pendant le chargement.
3. Formulaires. Sélecteurs de date et d’heure, style des select, couleurs de saisie automatique, messages de validation, type de clavier mobile pour chaque champ.
4. Médias. Règles de lecture automatique des vidéos (la plupart des navigateurs mobiles ne l’autorisent qu’en muet), formats d’image comme AVIF, choix effectués par srcset.
5. Défilement et unités de viewport. 100vh face au 100dvh dynamique sur mobile, scroll snapping, défilement fluide, overscroll.
6. API JavaScript. Tout ce qui a moins de deux ou trois ans : vérifiez la prise en charge avant de vous y fier.
7. Interaction. Menus au survol uniquement sur écran tactile, contour de focus pour les utilisateurs au clavier, taille des zones tactiles.
8. Mode sombre et zoom. Les pages zoomées à 200 % et avec le mode sombre du système.

Les outils gratuits qui font l’essentiel du travail

Installez les navigateurs. Chrome, Edge et Firefox fonctionnent sur tous les systèmes de bureau. Safari ne tourne que sur macOS, ce qui explique pourquoi les testeurs sans Mac ont besoin d’outils supplémentaires.

Vérifiez la compatibilité avant d’écrire du code. Baseline indique si une fonctionnalité web est « newly available » ou « widely available » dans les principaux navigateurs, et Can I use fournit des tableaux de compatibilité version par version. Les consulter en amont évite la plupart des bugs cross-browser.

Automatisez avec Playwright. Playwright exécute le même script de test dans Chromium, Firefox et WebKit sous Windows, macOS et Linux, et peut émuler des appareils mobiles. Un court script qui ouvre vos dix pages les plus importantes dans les trois moteurs et enregistre des captures détecte la plupart des régressions à chaque pull request.

Passez par un affichage mobile pour le responsive. Les problèmes de mise en page mobile sont souvent pris pour des problèmes de navigateur. Écartez-les rapidement avec le mode appareil de DevTools ou une extension comme Mobile View Extension, puis cherchez des causes propres au moteur. La différence entre ces deux outils est expliquée dans simulateur mobile en extension ou DevTools.

Utilisez des émulateurs pour les moteurs mobiles. Le simulateur Xcode fournit un vrai Safari iOS sur Mac (guide) ; l’émulateur d’Android Studio fournit un vrai Chrome Android (guide).

Quand les outils de test cross-browser payants valent le coup

Les services de test dans le cloud louent de vrais appareils et de nombreuses versions de navigateurs. Ils valent leur prix quand :

• vous n’avez pas de Mac et devez tester régulièrement Safari sur iPhone ;
• vos clients utilisent d’anciennes versions de navigateurs impossibles à installer côte à côte ;
• un contrat client impose de tester sur des modèles de téléphones précis ;
• vos tests automatisés doivent tourner sur du vrai matériel mobile.

Pour un petit site, un abonnement mensuel utilisé pendant la semaine de mise en production suffit souvent ; pour des vérifications ponctuelles, les essais gratuits vont déjà loin.

Une routine cross-browser légère

• Pendant le développement : consultez Baseline avant d’utiliser une nouvelle fonctionnalité et vérifiez l’affichage mobile au fil du code.
• À chaque pull request : lancez des captures Playwright dans Chromium, Firefox et WebKit.
• Avant la mise en ligne : parcourez les parcours clés dans Safari (sur Mac ou en simulateur), Firefox et Chrome sur Android.
• Après la mise en ligne : surveillez les outils de suivi d’erreurs et l’analytics, avec les erreurs regroupées par navigateur.

La partie mobile de cette vérification est détaillée dans la checklist de test d’un site mobile.

Questions fréquentes

Comment tester gratuitement mon site sur différents navigateurs ?

Installez Chrome, Edge et Firefox, utilisez Playwright pour lancer WebKit sur n’importe quel système, et DevTools ou une extension d’affichage mobile pour les tailles de téléphone. Sur Mac, le simulateur Xcode ajoute un vrai Safari iOS.

Faut-il encore tester dans Edge si l’on teste dans Chrome ?

Edge utilise le même moteur que Chrome, donc les différences sont rares. Un passage rapide suffit, sauf si votre public utilise des fonctions propres à Edge ou des stratégies d’entreprise.

Quelle est aujourd’hui la cause la plus fréquente des bugs cross-browser ?

Utiliser une fonctionnalité CSS ou JavaScript avant qu’elle soit prise en charge partout où se trouvent vos utilisateurs. Vérifier son statut Baseline avant de l’adopter évite la plupart de ces bugs.