navigator.cpuPerformance dans Chrome 152 : nouveau signal de détection pour l'anti-détection et le scraping

Le 25 août 2026, Chrome 152 a été lancé dans le canal stable sur Windows, Mac, Linux, ChromeOS et Android — et a introduit la propriété navigator.cpuPerformance. Un chiffre de 0 à 4 que le site lit de manière synchrone, sans autorisations et sans un seul cycle de calcul. Il est conçu comme un indice pour les appels vidéo et les streams : attribuer 240p à un appareil faible sans flou d'arrière-plan, 1080p avec effets à un appareil puissant. Deux semaines après la sortie, l'industrie du scraping discute d'autre chose : les systèmes anti-bot ont désormais un signal bon marché et stable sur le matériel sur lequel votre navigateur fonctionne.

Que renvoie exactement le navigateur

La propriété ne renvoie pas des gigahertz ni le modèle de processeur, mais un « panier » de performance. Selon la note explicative de WICG, il y a quatre niveaux plus un zéro :

• 0 — impossible de classifier l'appareil ;
• 1 — pratiquement inutilisable pour des tâches lourdes ;
• 2 — faible, mais fonctionnel ;
• 3 — confortable pour des scénarios normaux ;
• 4 — performant, avec une marge pour le multitâche.

La spécification interdit explicitement de révéler le fournisseur, le nom du modèle et le nombre de cœurs, exige HTTPS et vise la confidentialité : chaque panier doit couvrir une part significative des appareils sur Internet — environ des centaines de modèles différents de CPU, afin que la valeur ne réduise pas l'audience à quelques unités.

La mise en œuvre réelle dans Chromium s'est avérée plus simple que la spécification. Dans l'analyse de Zyte, il est montré que la classification repose principalement sur le nombre de cœurs logiques et sur une table intégrée d'augmentations et de diminutions : la fréquence n'est pas prise en compte du tout, bien que la spécification le permette. Les augmentations sont attribuées aux AMD Ryzen, aux cœurs Intel Gracemont, à la puce Apple silicon et aux Intel Core Ultra ; les diminutions — aux Intel Atom et aux processeurs de l'époque Core 2. L'association brute se présente ainsi : les machines monocœurs et très faibles tombent dans le premier niveau, deux à quatre cœurs donnent le second, quatre à dix cœurs ou des puces modernes écoénergétiques — le troisième, et huit cœurs ou plus sur Core Ultra, série M d'Apple et tout ce qui a dix cœurs ou plus — le quatrième.

Pourquoi c'est un signal de détection, et pas juste un autre octet d'entropie

La valeur en elle-même est faible : cinq options — c'est environ 2,3 bits d'entropie, moins que ce que donne la langue de l'interface. Le danger réside dans trois autres propriétés.

C'est gratuit. Pour mesurer la véritable vitesse d'exécution de JS avec le timing, le script de détection doit occuper le processeur pendant des dizaines de millisecondes, ce qui est visible dans le profileur. Ici — lecture synchrone de la propriété, zéro coût, zéro trace.

C'est stable. La valeur ne dépend pas de la charge de la machine au moment de la vérification : c'est une classe de matériel, et non une utilisation actuelle. Entre les sessions, les redémarrages et les changements d'IP, elle reste la même — c'est-à-dire qu'elle convient comme partie d'un identifiant de profil à long terme.

C'est vérifiable pour la cohérence. C'est le principal. Les moteurs anti-bot modernes bannissent rarement sur un seul champ — ils recherchent des incohérences internes dans l'ensemble. Un appareil qui déclare le quatrième niveau doit le confirmer par un navigator.hardwareConcurrency plausible, un navigator.deviceMemory raisonnable, une chaîne GPU-renderer moderne et une vitesse d'exécution JS correspondante. Un profil qui renvoie un niveau 4 tout en exécutant un benchmark comme une machine virtuelle à deux cœurs sera détecté par un simple contrôle croisé.

Il en résulte presque un fossé prêt entre « centre de données contre utilisateur réel » : un instance cloud typique sur deux vCPU rapporte honnêtement le premier niveau, tandis que les ordinateurs portables et téléphones grand public vivent dans le troisième ou quatrième. Pour un scraper qui tourne sur un VPS bon marché en mode headless tout en se faisant passer pour un Chrome ordinaire sur Windows, c'est une combinaison peu pratique.

En quoi cela diffère de hardwareConcurrency, qui a toujours existé

Une question raisonnable : le nombre de cœurs que le site lisait déjà via navigator.hardwareConcurrency, et la mémoire via navigator.deviceMemory. Qu'est-ce qui a changé ?

La connectivité a changé. hardwareConcurrency est un chiffre brut, et il est falsifié depuis longtemps et partout : on a mis huit au lieu de trente-deux, et la question est réglée. cpuPerformance est une valeur dérivée, calculée par le navigateur lui-même à partir d'une table intégrée. Dès que deux champs apparaissent dans l'ensemble, l'un d'eux étant calculé à partir de l'autre, toute modification unilatérale rompt le lien entre eux. On a déclaré quatre cœurs, mais le niveau est resté le quatrième — logiquement, cette combinaison exige soit Apple silicon, soit Core Ultra, soit dix cœurs ; donc, soit le nombre de cœurs ment, soit la chaîne GPU ment, et le détecteur suffit de remarquer le simple fait de l'incohérence, sans avoir à déterminer où se trouve le mensonge.

C'est précisément pour cette raison que les anciennes listes de contrôle « quels champs falsifier dans le profil » deviennent obsolètes non pas point par point, mais par blocs entiers : la bonne question est maintenant non pas « quoi falsifier », mais « quelle configuration de matériel cohérente obtenons-nous au total ».

Qui est le plus touché

Chromium uniquement — et ce n'est pas une circonstance atténuante. WebKit a pris position « contre » sur cette API, Mozilla n'a pas déclaré de position publique, donc dans Safari et Firefox, la propriété ne sera probablement pas présente. Mais la grande majorité de l'automatisation de production — Playwright, Puppeteer, nodriver, Patchright, navigateurs agents — est construite précisément sur Chromium. Cela signifie que le signal arrive exactement dans le créneau où il est le moins attendu.

Le plus douloureux est que l'incohérence frappe l'émulation des profils mobiles. Si un profil anti-détection se fait passer pour un smartphone Android, et que cpuPerformance sous lui répond « 4 », parce que le navigateur est physiquement lancé sur un bureau avec Ryzen, ce n'est pas une petite inexactitude, mais une paire de signaux contradictoires. C'est la même chose avec les scénarios de ferme, où des dizaines de profils avec différents « appareils » vivent sur une seule machine hôte et donnent donc un niveau identique.

Qu'est-ce que cela change pour la pile de parsing

Quelques conséquences pratiques pour ceux qui exécutent des navigateurs headless en masse.

• Les conteneurs héritent de l'hôte. Le navigateur dans Docker voit les cœurs de la machine hôte, et non les limites de cgroup, — donc, dix conteneurs sur un serveur puissant donneront dix niveaux maximaux identiques. La diversité des profils que vous avez soigneusement dessinés dans l'agent utilisateur est absente au niveau matériel.
• Le VPS bon marché est maintenant plus visible. Deux vCPU — c'est le premier niveau, et le premier niveau sur Chrome de bureau sous Windows n'est pas fréquent chez les utilisateurs réels. Auparavant, un serveur faible était simplement lent ; maintenant, il est également marqué.
• Le signal est gratuit pour le site. Des vérifications lourdes comme des benchmarks de timing sont incluses de manière sélective par les sites, car elles coûtent du temps à l'utilisateur. La lecture de la propriété ne coûte rien, donc elle sera ajoutée au jeu de base même par les sites qui se limitaient auparavant à la réputation IP et aux en-têtes.
• Il s'alignera avec Compute Pressure. Dans les notes de version de Chrome, il est directement suggéré de combiner la nouvelle API avec l'API Compute Pressure — donc la combinaison « classe de matériel plus charge observée » est initialement conçue comme un scénario standard, et les anti-bots n'auront rien à inventer.

Il est également important de revoir l'hypothèse selon laquelle il suffit de rassembler une fois un « bon » profil et de le réutiliser pendant des années. Les navigateurs ajoutent de telles propriétés sans annonces pour les utilisateurs finaux : entre la sortie de Chrome 152 et les premières analyses publiques, des semaines se sont écoulées, durant lesquelles les profils ont tranquillement renvoyé un nouveau champ, sans rien soupçonner. Il est judicieux de vérifier l'ensemble des champs une fois par cycle de versions, et non une fois par an.

Que faire pratiquement

1. Obtenez la valeur actuelle. Dans la console de profil : navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory et la chaîne du renderer WebGL. Enregistrez en groupe de quatre, et non un par un — vous serez vérifiés précisément par la combinaison.
2. Vérifiez le niveau avec la légende du profil. La légende mobile — premier à troisième niveau, un ordinateur portable bon marché — deuxième à troisième, un bureau haut de gamme — quatrième. Un niveau 4 sous l'apparence d'un ancien Android ou un niveau 1 sous l'apparence d'un MacBook sur la série M sont tous deux également suspects.
3. Ne modifiez pas la propriété directement. La substitution via Object.defineProperty est détectée par les traces de redéfinition du getter et par l'incohérence avec la véritable vitesse d'exécution. Si vous devez changer, faites-le au niveau de la construction du navigateur ou via des mécanismes intégrés.
4. Rappelez-vous le contournement légal. Chrome donne à l'utilisateur un moyen dans les paramètres (Performance → Vitesse → Remplacer le niveau de performance du CPU), et aux administrateurs — une politique d'entreprise. C'est utile à savoir des deux côtés : la valeur peut être non seulement « réelle », mais aussi définie manuellement, et un contournement identique sur un ensemble de profils devient lui-même une étiquette.
5. Répartissez les profils sur différents matériels. Si tous vos profils sont sur un même serveur, ils auront le même niveau — peu importe quels appareils ils prétendent être. C'est un cas où un parc de plusieurs machines de configurations différentes résout honnêtement le problème, tandis qu'un patch ne le fait pas.

Pour plus de détails sur le signal voisin de la même famille — dans l'analyse de l'empreinte basée sur la mémoire de l'appareil, et pour les navigateurs stealth qui fonctionnent avec de telles propriétés dès la sortie de la boîte, il y a le benchmark de nodriver, Camoufox et Patchright.

Où sont les proxies ici

Pour être franc : un proxy ne répare pas l'empreinte du navigateur. cpuPerformance est calculé côté client, et aucun IP ne peut le modifier. Mais l'anti-bot prend une décision sur la somme des couches, et c'est précisément à l'intersection des couches que se produit généralement l'échec.

Une chaîne typique par laquelle échouent les configurations bon marché ressemble à ceci : IP d'un réseau d'hébergement connu, premier niveau de processeur, signes headless en JS — trois signaux indépendants, chacun d'eux étant tolérable séparément, mais ensemble, ils se combinent en un verdict sans équivoque. Retirer la couche réseau de cette somme est moins cher et plus fiable que de lutter contre les champs du navigateur : avec un IP résidentiel, la requête ressemble à du trafic d'un fournisseur domestique ordinaire, et l'hypothèse « centre de données » disparaît d'elle-même pour le détecteur. Pour les légendes mobiles, la logique est la même — un proxy mobile doit soutenir le profil mobile, sinon l'incohérence se déplace simplement du processeur au réseau.

En résumé

Chrome 152 n'a pas tant ajouté une nouvelle empreinte qu'une nouvelle ligne dans le tableau des vérifications croisées. Deux bits et quelques en eux-mêmes ne révèlent personne — c'est l'incohérence qui révèle : l'appareil déclaré doit correspondre à la classe de processeur, à la mémoire, à la carte graphique, à la vitesse d'exécution et au réseau d'où la requête est venue. L'audit des profils cette semaine doit commencer par une ligne dans la console et la question « un tel matériel existe-t-il vraiment pour celui que nous prétendons être ? ».