Le test de compatibilité entre navigateurs vérifie que les fonctionnalités et la mise en page d'un site web fonctionnent de façon homogène dans chaque navigateur, chaque version de navigateur, chaque système d'exploitation et chaque appareil que vous prenez en charge, et inclut la correction de ce qui ne fonctionne pas. Le test cross-browser au sens large porte sur le processus et les outils de test ; le test de compatibilité, lui, porte sur les différences elles-mêmes : une fonctionnalité CSS qu'un navigateur n'a pas encore déployée, un sélecteur de date qui se comporte différemment sur Android, ou une connexion qui échoue lorsque les cookies tiers sont bloqués.
Qu'est-ce que le test de compatibilité entre navigateurs ?
Un navigateur est compatible avec votre site lorsque chaque fonctionnalité sur laquelle vous vous appuyez est prise en charge et s'affiche comme prévu. Le test de compatibilité, souvent abrégé en CBT, répond à trois questions :
- Quels navigateurs et quelles versions prenons-nous en charge ?
- Chaque fonctionnalité que nous utilisons fonctionne-t-elle dans tous ces navigateurs, ou bascule-t-elle proprement sur une solution de repli lorsque ce n'est pas le cas ?
- La dernière version d'un navigateur ou notre dernier déploiement a-t-il cassé quelque chose ?
Les tests de compatibilité au sens large peuvent aussi couvrir les systèmes d'exploitation, le matériel, les lecteurs d'écran et les réseaux lents, mais pour les sites web, c'est du côté des navigateurs que surviennent la plupart des problèmes.
Pourquoi la compatibilité reste essentielle en 2026
- Votre audience est répartie entre plusieurs moteurs. Les chiffres de StatCounter de septembre 2026 attribuent à Chrome 66,4 % de l'usage mondial des navigateurs, à Safari 18,3 %, à Edge 6,0 %, à Firefox 2,8 % et à Samsung Internet 2,3 %. Sur mobile, Safari atteint 24,7 %, et aux États-Unis 30,4 % tous appareils confondus.
- Tous les navigateurs sur iPhone utilisent WebKit. Chrome, Firefox et Edge sur iOS reposent sur le moteur d'Apple (avec une exception limitée dans l'UE) : un bug de Safari touche donc tous les utilisateurs d'iPhone, quel que soit leur navigateur.
- Les fonctionnalités n'arrivent pas en même temps. Les nouveautés CSS et JavaScript sont déployées dans chaque navigateur selon son propre calendrier, et les anciennes versions persistent sur des appareils qui ne sont plus mis à jour.
- Référencement et conversions. Google indexe la version mobile de vos pages : une mise en page qui se casse sur smartphone nuit donc aussi bien aux visiteurs qu'à votre visibilité.
Étape 1 : définir votre matrice de navigateurs pris en charge
Vous ne pouvez pas tout prendre en charge ; notez donc ce que vous prenez réellement en charge. Partez de vos statistiques d'audience et regroupez les navigateurs par niveaux :
| Niveau | Navigateurs typiques | Engagement |
|---|---|---|
| A : prise en charge complète | Versions actuelles de Chrome, Safari (Mac et iPhone), Edge et Firefox ; Samsung Internet si vous avez du trafic Android | Tout fonctionne et s'affiche comme prévu ; les tests automatisés s'exécutent à chaque modification |
| B : fonctionnel | Anciennes versions qui apparaissent encore dans vos statistiques | Les parcours essentiels fonctionnent ; de légères différences visuelles sont acceptables |
| C : basique | Tout le reste | Le contenu est lisible et les formulaires s'envoient |
Conservez la matrice sous forme de configuration Browserslist afin que les outils de build comme Autoprefixer et Babel ciblent les mêmes navigateurs. Baseline offre un raccourci utile : une fonctionnalité marquée « Baseline widely available » fonctionne dans tous les navigateurs principaux (Chrome, Edge, Firefox et Safari, sur ordinateur et mobile) depuis au moins 30 mois, et la plupart des sites peuvent donc l'utiliser sans solution de repli.
Comment repérer et corriger les problèmes de compatibilité
- Vérifiez la prise en charge avant de développer. Consultez les nouvelles fonctionnalités sur MDN, dont les pages affichent des tableaux de compatibilité des navigateurs et le statut Baseline, ou sur Can I use. Le projet Baseline explique comment ce statut est défini.
- Détectez les fonctionnalités, pas les navigateurs. Encadrez le CSS récent avec
@supportset vérifiez en JavaScript qu'une API existe avant de l'appeler, au lieu de deviner à partir de la chaîne de l'agent utilisateur. - Construisez avec l'amélioration progressive. Faites d'abord fonctionner le contenu et les formulaires avec du HTML et du CSS de base, puis ajoutez les fonctionnalités récentes par-dessus.
- Automatisez les correctifs de routine. Autoprefixer ajoute les préfixes propriétaires, Babel et les polyfills couvrent les anciens moteurs JavaScript, et des linters comme eslint-plugin-compat vous avertissent lorsque le code utilise un élément non pris en charge par les cibles de votre Browserslist.
- Testez dans les trois moteurs. Playwright exécute les mêmes tests dans Chromium, Firefox et WebKit, et ses comparaisons de captures d'écran détectent les dérives de mise en page.
- Confirmez sur de vrais appareils. Les émulateurs et les modes d'affichage adaptatif conviennent pour un premier passage, mais les claviers à l'écran, le tactile, le défilement et la vidéo se comportent différemment sur de vrais smartphones. Utilisez vos propres appareils ou une grille cloud comme BrowserStack, TestMu AI (anciennement LambdaTest), Sauce Labs ou BitBar.
- Testez avec les protections de confidentialité activées. La prévention du suivi de Safari, le mode strict de Firefox et les Shields de Brave peuvent bloquer des scripts, des cookies et des contenus intégrés dont dépend votre site.
Problèmes de compatibilité courants en 2026
| Problème | Où il apparaît | Correctif habituel |
|---|---|---|
| Les sections pleine hauteur sautent ou se cachent derrière la barre d'outils | Navigateurs mobiles, en particulier Safari sur iPhone | Utiliser des unités de viewport dynamiques comme dvh plutôt que vh |
| Fonctionnalités CSS récentes ignorées | Navigateurs qui n'ont pas encore déployé la fonctionnalité, appareils anciens | Vérifier le statut Baseline et ajouter des solutions de repli avec @supports |
| Les champs de date, d'heure et de sélection ont un aspect et un comportement différents | Tous les navigateurs, qui utilisent leurs propres sélecteurs natifs | Accepter les contrôles natifs ou recourir à une bibliothèque de composants bien testée |
| La vidéo ne se lance pas automatiquement ou ne se lit pas directement dans la page | Navigateurs mobiles et Safari | Ne lancer automatiquement que des vidéos sans son et ajouter playsinline pour iPhone |
| Les connexions, paiements ou widgets de chat intégrés échouent | Safari, Firefox et Brave, qui restreignent les cookies tiers | Privilégier les parcours sur votre propre site ou l'API Storage Access, et tester avec les paramètres de confidentialité par défaut |
| Le texte passe à la ligne différemment et les boutons débordent | Polices et rendu des polices différents sous Windows, macOS et Android | Définir des polices de repli et laisser de la marge dans les boutons et les menus |
Checklist de compatibilité entre navigateurs
- Matrice de compatibilité rédigée et conservée sous forme de configuration Browserslist.
- Nouvelles fonctionnalités vérifiées sur MDN, Can I use ou Baseline avant utilisation.
- Solutions de repli en place pour tout ce qui n'est pas Baseline widely available.
- Tests automatisés réussis dans Chromium, Firefox et WebKit.
- Formulaires, vidéo et défilement vérifiés sur un vrai iPhone et un vrai téléphone Android.
- Connexions, paiements et contenus intégrés testés avec les protections de confidentialité par défaut activées.
- Pages propres à une région et contrôles anti-bots testés depuis d'autres emplacements et avec d'autres empreintes de navigateur (voir comment les tester).
- Tests relancés après chaque sortie majeure de navigateur.
Questions fréquentes
Ai-je besoin de tests de compatibilité si mon site s'affiche bien dans Chrome ?
Oui. Chrome représente environ deux tiers de l'usage mondial des navigateurs, mais Safari à lui seul compte pour près d'un tiers des visites aux États-Unis, et tous les navigateurs sur iPhone reposent sur le moteur de Safari. Ne tester que dans Chrome laisse une grande partie des visiteurs sans vérification.
À quelle fréquence faut-il tester la compatibilité ?
Lancez des vérifications automatisées à chaque modification du code et après chaque sortie majeure de navigateur, puis effectuez un passage manuel sur de vrais appareils avant les lancements importants ou les refontes.
Les tests de compatibilité coûtent-ils cher ?
Pas nécessairement. Playwright, Selenium et Cypress sont gratuits, tout comme les données de MDN, Can I use et Baseline. Les grilles cloud payantes vous évitent surtout d'acheter et d'entretenir votre propre parc d'appareils.
Quelle est la différence entre le test cross-browser et le test de compatibilité ?
Le test cross-browser désigne le processus global de test sur plusieurs navigateurs, présenté dans notre guide du test cross-browser. Le test de compatibilité se concentre sur la prise en charge des fonctionnalités et du code que vous utilisez, ainsi que sur la façon de corriger ou de contourner les lacunes.
