Ce que mesure le test d’empreinte de navigateur
L’audit mesure la cohérence : il vérifie si des sous-systèmes indépendants du navigateur donnent des réponses compatibles sur une même machine. Il peut comparer JavaScript et CSS, la page principale et un worker ou une iframe, la famille de navigateur annoncée et des API propres au moteur, ou encore le GPU déclaré et le pipeline de rendu qui a réellement produit une image.
Ce n’est pas la même chose que mesurer la rareté. Un appareil inhabituel mais cohérent en interne peut réussir le test. Une identité d’apparence banale peut échouer dès que deux surfaces se contredisent. La plupart des vérifications n’ont donc besoin d’aucune population de référence : le navigateur fournit lui-même les deux termes de la comparaison.
Comment le score de cohérence est calculé
Le score est la part des vérifications applicables et notées qui concordent. Ce n’est ni la probabilité que le visiteur soit humain, ni un taux de détection, ni une garantie qu’une session d’automatisation passe inaperçue. Un score de 92 signifie que 92 % des comparaisons notées qui s’appliquaient étaient cohérentes.
Les constats contextuels sont exclus, car des environnements ordinaires peuvent les produire : outils d’accessibilité, extensions, bureaux à distance, navigateurs gérés par des stratégies, protections de la vie privée ou matériel absent modifient tous les surfaces observables. Les vérifications qui ne peuvent pas s’exécuter sont signalées comme non mesurées et ne comptent jamais comme réussies.
Pourquoi certaines mesures nécessitent une sonde réseau
JavaScript ne peut lire ni le ClientHello TLS, ni l’ordre des frames HTTP/2, ni les paramètres de transport QUIC, ni l’adresse publique utilisée par WebRTC. Ces informations se situent sous le runtime de la page. Pour les mesurer, il faut qu’un serveur rapporte ce qui est réellement arrivé sur le fil.
L’audit ouvre deux connexions vers tls.clearcotelabs.com pour comparer des handshakes TLS indépendants. Son test de fuite WebRTC contacte stun.l.google.com — Google voit donc l’IP qui se connecte — puis compare cette adresse à celle utilisée pour l’audit. Si l’un de ces services est injoignable, le résultat correspondant est « non mesuré », et non « propre ».
Collecte des données et corpus de recherche
Lancer l’audit envoie un profil de navigateur à Clearcote pour analyse interne. L’avis de consentement affiché par l’outil liste les champs concernés avant le début de l’exécution. Le corpus de recherche, distinct, conserve un enregistrement de configuration moins détaillé, qui sert à étudier la couverture et les faux positifs ; ce n’est ni une base de données antifraude, ni une base de réputation de comptes.
Les règles complètes de conservation et de suppression, ainsi que le détail champ par champ, figurent dans la politique de confidentialité de l’audit. Garder cette politique à part permet au test de rester concis sans rien cacher de ce qui quitte le navigateur.
Ce qu’un test de navigateur public ne peut pas établir
Une page publique ne voit ni l’ancienneté globale du profil, ni l’historique de navigation intersites, ni la réputation du compte, ni les cookies privés d’autres origines, ni les modèles de risque côté serveur des systèmes anti-bot commerciaux. Les entrées comportementales peuvent révéler un timing mécanique ou une interpolation parfaite, mais une courte interaction ne vaut pas un classifieur comportemental entraîné.
Un score élevé doit donc être lu de façon restrictive : les mesures effectuées n’ont pas révélé beaucoup de contradictions internes. Il ne dit rien de définitif sur la réputation, l’intention, l’historique du compte, ni sur l’ensemble des signaux qu’un détecteur en production peut combiner.
Un cas mérite d’être énoncé clairement, car c’est celui qu’on interprète le plus souvent de travers. Toutes les vérifications du groupe automatisation peuvent réussir, et une session peut malgré tout être classée comme automatisée. Dans l’analyse publiée (teardown) d’un agent commercial en production, un payload capturé sur un navigateur piloté via le protocole DevTools est revenu étiqueté comme bot webdriver, avec outils de développement détectés — alors que ce même payload déclarait tous les flags d’automatisation à false, et ne différait d’une fenêtre ordinaire que par les identifiants de session, les relevés d’horloge et un champ de timing réseau. Ce sur quoi le serveur s’est appuyé n’est pas récupérable côté client, et cette page s’abstient délibérément d’ajouter une ligne pour ce qu’elle ne peut pas mesurer. La conclusion honnête, c’est que la présence d’un protocole de débogage se décide en dehors des valeurs qu’une page peut lire : une section automatisation propre signifie que ces surfaces précises sont propres, pas que la connexion n’est pas observée.
C’est aussi à cause de cette analyse que cette page affiche plusieurs relevés au lieu de leur attribuer un score. Des payloads capturés identiques, soumis de nouveau au même fournisseur à une semaine d’intervalle, ont reçu des verdicts de manipulation (tampering) et d’anti-détection sensiblement différents — dérive du modèle, historique de rejeu, ou les deux, sans que la part de chacun ait été établie. Les scores absolus d’un détecteur en production dérivent ; seules les différences mesurées par rapport à un témoin dans la même session ont un sens. Cela vaut aussi pour le chiffre de cette page, et c’est pourquoi l’exécution indique à quel point les réponses de votre navigateur ont été stables, plutôt que de tenir un seul passage pour la vérité terrain.