Ce que fait cet outil
À l'ouverture de la page, un script lance une soixantaine de petits tests sur votre navigateur actuel et indique pour chaque fonctionnalité si elle est prise en charge ou non. Les résultats sont regroupés en langage JavaScript, CSS, graphisme, médias et codecs, stockage, réseau, API matérielles, sécurité et interface, et le résumé en haut donne le nombre de fonctionnalités prises en charge.
Chaque test est une question à laquelle le navigateur peut répondre sans rien faire de visible. En JavaScript, il s'agit le plus souvent de vérifier qu'un élément existe, comme structuredClone ou Promise.withResolvers, ou qu'une syntaxe plus récente est acceptée, comme une expression régulière avec le drapeau v. Les lignes CSS passent par CSS.supports(), qui indique si le moteur de style comprend une propriété, une valeur ou un sélecteur comme :has(). Les lignes de codecs reprennent les réponses du navigateur lui-même à canPlayType() et aux tests Media Source.
Aucun test n'ouvre de demande d'autorisation, ne lance de sélecteur d'appareil ni n'envoie quoi que ce soit sur le réseau. Pour les API matérielles comme Web Bluetooth, WebUSB ou Web NFC, « prise en charge » signifie que le navigateur expose l'interface, pas qu'un appareil est branché ou autorisé.
Mode d'emploi
- Ouvrez la page dans le navigateur, le profil et l'appareil exacts qui vous intéressent. Les tests démarrent tout seuls.
- Lisez le total du résumé, puis parcourez chaque groupe à la recherche des lignes marquées « Non ».
- Dans le groupe Médias, repérez les codecs affichés comme « Partiel » : le navigateur a répondu maybe au lieu de probably.
- Appuyez sur le bouton « Copier en texte » pour placer toute la liste dans le presse-papiers.
- Collez-la dans le rapport de bug, le ticket ou la conversation, en ajoutant la version du navigateur et le système d'exploitation s'ils n'y sont pas déjà.
Faites le test dans la fenêtre même où le problème se produit. Les extensions, les règles d'entreprise et les options expérimentales (flags) peuvent activer ou désactiver certaines fonctionnalités.
Deux lignes décrivent la page autant que le navigateur : le contexte sécurisé dépend de la façon dont la page a été chargée, et l'isolation cross-origin des en-têtes envoyés par le serveur. Un autre site peut donc obtenir des réponses différentes pour ces deux-là.
Cas d'usage
- Tickets de support. Un client signale que l'enregistrement d'un gros fichier ne fait rien. Demandez-lui d'ouvrir cette page et de coller la liste copiée ; une ligne « Système de fichiers privé de l'origine » ou « Fetch avec flux » absente peut régler la question en une seule réponse.
- Vidéo qui ne se lit pas. Un extrait se lit sur un ordinateur portable et affiche une image noire sur un autre. Comparez les lignes HEVC et AV1 sur les deux ; un « Non » ou un « Partiel » indique qu'il vaut mieux proposer aussi une version H.264 ou VP9.
- Choisir ce qu'on peut mettre en production. Avant de compter sur
:has(), les requêtes de conteneur ou l'imbrication CSS, ouvrez la page sur les navigateurs les plus anciens qu'utilisent encore vos visiteurs, bornes et téléviseurs connectés compris. - Navigateurs intégrés aux applis. Les liens touchés dans les applis de messagerie et les réseaux sociaux s'ouvrent souvent dans une vue web intégrée. Ouvrir cette page de cette façon montre ce que cette vue prend en charge, ce qui peut différer de Safari ou de Chrome sur le même téléphone.
- Projets matériels. Avant d'annoncer à vos utilisateurs qu'ils peuvent flasher un microcontrôleur ou configurer un clavier depuis une page web, faites-leur vérifier les lignes Web Serial, WebUSB et WebHID ; certains grands navigateurs n'ont pas du tout ces interfaces.
Détection de fonctionnalités ou lecture du user agent
L'ancienne habitude consistait à lire la chaîne du user agent et à en déduire les capacités d'après le nom du navigateur. Cela échoue de façon prévisible. Les navigateurs basés sur Chromium partagent l'essentiel du texte de leur user agent. Chrome sur iPhone porte un jeton CriOS mais affiche normalement les pages avec WebKit : pour la plupart des lignes ici, il se comporte donc comme Safari. Chrome a aussi figé une partie des détails de version et de plateforme de sa chaîne, et n'importe qui peut la modifier en quelques clics.
La détection de fonctionnalités interroge plutôt le navigateur en cours d'exécution, ce qui simplifie aussi l'amélioration progressive : on construit une base qui fonctionne partout, puis on ajoute la meilleure option seulement là où le test réussit.
if ('share' in navigator) {
shareButton.hidden = false; // feuille de partage native
} else {
copyLinkButton.hidden = false; // solution de repli simple
}@supports (container-type: inline-size) {
.card-list { container-type: inline-size; }
}Les codecs fonctionnent de la même façon. Un lecteur peut appeler video.canPlayType('video/mp4; codecs="av01.0.05M.08"') et se rabattre sur une source H.264 quand la réponse est une chaîne vide, la façon dont le navigateur dit non. Les deux seules autres réponses possibles sont maybe et probably.
Pourquoi le même navigateur peut répondre différemment
Matériel et système d'exploitation
Beaucoup de lignes dépendent d'autre chose que de la compilation du navigateur. La lecture HEVC exige souvent un décodeur matériel ou la prise en charge du codec par le système d'exploitation : la même version du navigateur peut donc donner deux réponses différentes sur deux ordinateurs portables. Safari n'annonce AV1 que sur les appareils Apple équipés d'un décodeur AV1 matériel. WebGPU est arrivé sur certains systèmes d'exploitation avant d'autres, et un navigateur peut désactiver WebGL quand le pilote graphique figure sur sa liste de blocage. Certaines compilations open source de navigateurs omettent les codecs sous licence comme H.264 et AAC.
Contextes sécurisés
Beaucoup d'API n'existent que dans un contexte sécurisé : les pages servies en https, ainsi que les adresses locales comme http://localhost et http://127.0.0.1. Les Service Workers, l'API asynchrone du presse-papiers, Web Authentication, Web Share, Screen Wake Lock, WebGPU et les API matérielles en font partie. Chargez le même site en http simple sur une adresse du réseau local, et ces objets sont absents plutôt que bloqués : une fonctionnalité qui marche sur localhost peut ainsi disparaître sur un serveur de test. window.isSecureContext indique l'état. L'isolation cross-origin, qui débloque SharedArrayBuffer, exige en plus les en-têtes de réponse Cross-Origin-Opener-Policy et Cross-Origin-Embedder-Policy.
La liste est aussi une empreinte
Comme les résultats varient selon le navigateur, la version, le système d'exploitation et le matériel, l'ensemble des réponses permet de cerner la configuration d'un visiteur. C'est pour cela que les scripts d'empreinte font le même genre de tests, à côté du rendu canvas et des polices installées. Cette page fait ses tests en local et n'envoie rien, et iseeu.cc ne conserve aucun journal des adresses IP ni des recherches, mais n'importe quel site peut exécuter un code équivalent sans vous montrer le résultat. Avant de coller la liste dans un outil de suivi de bugs public, traitez-la comme tout autre détail de votre système que vous partagez.
Questions fréquentes
Cette page demande-t-elle l'accès à la caméra, au Bluetooth ou aux notifications ?
Non. Chaque test se contente de vérifier si une API existe ou si le navigateur déclare prendre en charge quelque chose. Aucune méthode susceptible d'ouvrir une demande d'autorisation ou un sélecteur d'appareil n'est appelée, et aucune donnée ne quitte votre navigateur. La ligne « API Notifications », par exemple, vérifie que l'API est présente ; elle ne vous demande pas l'autorisation d'afficher des notifications. Par ailleurs, iseeu.cc ne dépose aucun cookie et ne conserve aucun journal des adresses IP ni des recherches.
Une fonctionnalité est indiquée comme prise en charge : pourquoi ne marche-t-elle pas sur mon site ?
« Prise en charge » signifie ici que le navigateur expose l'API ou déclare comprendre la syntaxe. L'usage réel peut quand même échouer : votre site est peut-être chargé en http simple et perd les API réservées aux contextes sécurisés, une autorisation a pu être refusée, une règle peut bloquer un appareil, ou WebGPU peut ne trouver aucun adaptateur graphique utilisable. Les lignes de codecs reflètent ce que le navigateur affirme, et un profil ou une résolution inhabituels peuvent encore échouer au décodage.
Que veut dire « Partiel » dans les lignes de codecs ?
La méthode canPlayType ne répond jamais oui. Elle renvoie probably quand le navigateur est à peu près sûr de pouvoir lire le format, maybe quand il reconnaît le format sans pouvoir en être certain sans essayer, et une chaîne vide pour dire non. Cette page affiche maybe comme « Partiel ». Un résultat partiel doit vous inciter à faire un vrai test de lecture avec votre propre fichier avant de compter sur ce codec.
Pourquoi un collègue obtient-il d'autres résultats avec la même version du navigateur ?
Plusieurs lignes dépendent du système d'exploitation et du matériel plus que de la version du navigateur. HEVC et AV1 s'appuient souvent sur des décodeurs matériels, la disponibilité de WebGPU varie selon la plateforme et le pilote graphique, et certaines compilations du navigateur sont livrées sans les codecs sous licence. Les extensions, les règles d'entreprise, les options expérimentales et les fenêtres de navigation privée peuvent aussi changer certaines réponses. Le plus rapide pour trouver la différence est de comparer côte à côte les deux listes copiées.
Pourquoi certaines fonctionnalités disparaissent-elles quand le site est ouvert en http ?
Les navigateurs n'exposent beaucoup d'API récentes que dans des contextes sécurisés, c'est-à-dire sur des pages chargées en https ou depuis des adresses locales comme localhost. Sur une page en http simple, des objets comme navigator.serviceWorker et navigator.clipboard sont tout simplement indéfinis. C'est voulu : ces API touchent à des appareils, à des identifiants ou à du code qui tourne longtemps en arrière-plan, et une page non chiffrée pourrait être modifiée en chemin. Servez vos environnements de test en https pour retrouver le comportement de la production.
Cette liste peut-elle servir à m'identifier ?
À elle seule, une liste de fonctionnalités prises en charge décrit votre navigateur, votre système d'exploitation et votre matériel, pas vous. Combinée à d'autres signaux, comme la taille de l'écran, les polices installées et le rendu canvas, elle s'ajoute à une empreinte du navigateur qui peut aider à reconnaître un visiteur qui revient. Cette page fait les tests en local et n'envoie rien, mais d'autres sites peuvent faire les mêmes tests sans rien dire : l'exposition tient donc à la combinaison, pas à cette liste seule.
Ne vaut-il pas mieux regarder le user agent ?
Pour décider d'utiliser ou non une fonctionnalité, non. Les chaînes User-Agent se ressemblent d'un navigateur basé sur Chromium à l'autre, Chrome en a réduit le détail, elles se modifient facilement et elles induisent en erreur sur iPhone, où Chrome et Firefox affichent normalement les pages avec WebKit. Tester directement la fonctionnalité donne la réponse du navigateur réellement en cours d'exécution. La chaîne User-Agent reste utile dans un rapport de bug pour noter la version exacte du navigateur.
Comment transmettre ces résultats au support technique ?
Ouvrez la page dans le navigateur, le profil et l'appareil où le problème se produit, appuyez sur le bouton « Copier en texte », puis collez la liste dans le ticket, le rapport de bug ou la conversation. Ajoutez la version du navigateur et le système d'exploitation s'ils n'y figurent pas déjà. Avant de la publier dans un outil de suivi public, traitez-la comme n'importe quel autre détail de votre système que vous partagez.
La détection rapporte ce que le navigateur expose ou annonce. Une fonctionnalité peut encore se révéler désactivée par une règle, faute de matériel ou à cause d'une autorisation refusée quand un site essaie réellement de s'en servir.