La migration vers les User-Agent Client Hints : mesurer les appareils sans la chaîne UA complète

La lente agonie de la chaîne User-Agent

Pendant des décennies, l'en-tête de requête User-Agent a été le cheval de bataille de l'analytique pour répondre à des questions simples : quel navigateur, quel système d'exploitation, mobile ou ordinateur de bureau ? C'était aussi un passif en matière de fingerprinting. Une chaîne UA complète comme Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xxx.0.0.0 Safari/537.36 divulgue des numéros de version précis et des détails de plateforme qui, combinés à d'autres signaux, aident à identifier des visiteurs individuels.

L'effort de réduction du User-Agent mené par Google rogne cette chaîne depuis des années. Chrome envoie désormais une UA réduite, où la version de la plateforme est figée et les segments de version mineure mis à zéro. L'intention, selon la documentation de Chrome, est de supprimer l'entropie disponible passivement tout en préservant un remplaçant structuré et explicitement demandé : les User-Agent Client Hints (UA-CH).

Pour qui construit de l'analytique en 2026, la conséquence pratique est nette. Analyser la chaîne UA héritée pour en tirer autre chose que la famille approximative du navigateur devient de moins en moins fiable — et de plus en plus la mauvaise approche.

Comment fonctionnent réellement les Client Hints

UA-CH découpe les informations d'appareil en indices distincts et demandables plutôt qu'en une seule chaîne dense. Les indices à faible entropie sont envoyés par défaut à chaque requête :

• Sec-CH-UA — liste de la marque et de la version significative
• Sec-CH-UA-Mobile — un booléen ?0 / ?1
• Sec-CH-UA-Platform — par exemple "macOS"

Les indices à forte entropie — version complète de la plateforme, architecture, modèle, bitness — ne sont pas envoyés à moins que le serveur ne les demande explicitement. Le serveur les réclame via un en-tête de réponse Accept-CH, et le navigateur peut alors les inclure dans les requêtes suivantes. Le préfixe Sec- signifie que ces en-têtes sont contrôlés par le navigateur et ne peuvent pas être définis par des scripts, ce qui constitue une propriété d'intégrité appréciable.

Cette inversion compte pour la vie privée. La posture par défaut est la divulgation minimale. L'entropie supplémentaire devient un acte délibéré, consigné dans vos propres en-têtes de réponse, plutôt qu'une donnée discrètement moissonnée chez chaque visiteur.

La lecture « privacy-first » de ce basculement

Monoid reste délibérément du côté faible entropie de cette frontière. Nous n'envoyons jamais Accept-CH pour obtenir l'architecture, le modèle ou la version complète de la plateforme, et nous ne combinons jamais les indices que nous voyons en une signature d'appareil stable. Ce serait du fingerprinting — reconstruire un identifiant à partir de caractéristiques matérielles —, précisément ce que la réduction de l'UA vise à empêcher, et ce que l'article 5(3) de la directive ePrivacy et les politiques anti-fingerprinting des navigateurs traitent comme un accès aux informations de l'équipement terminal.

Les indices à faible entropie envoyés par défaut suffisent aux questions que l'analytique devrait se poser :

• Famille et version majeure du navigateur via Sec-CH-UA, pour la compatibilité et la planification du support.
• Mobile ou non mobile via Sec-CH-UA-Mobile, pour segmenter la mise en page et les Core Web Vitals.
• Plateforme via Sec-CH-UA-Platform, pour des répartitions au niveau du système d'exploitation.

Point essentiel : ce sont des dimensions agrégées, pas des clés par visiteur. Un booléen et un nom de plateforme partagés par des millions de visiteurs n'ont, à eux seuls, aucun pouvoir identifiant significatif.

Lire les indices en périphérie

Puisque les Client Hints sont de simples en-têtes de requête, un worker en périphérie peut les lire sans aucun script côté client. Sur Cloudflare, les indices à faible entropie arrivent sur l'objet Request entrant :

export default {
  async fetch(request) {
    const brands = request.headers.get('Sec-CH-UA') || '';
    const isMobile = request.headers.get('Sec-CH-UA-Mobile') === '?1';
    const platform = request.headers.get('Sec-CH-UA-Platform') || '';
    // Ne dériver que des dimensions grossières ; ne jamais persister de clé composite.
    return new Response('ok');
  }
};

Remarquez ce qui est absent : aucun écho de Accept-CH, aucune demande d'indices à forte entropie, aucun hachage des valeurs combinées. La valeur de Sec-CH-UA est une liste structurée : analysez-la avec soin — elle contient des entrées de marque « GREASE » volontaires, conçues pour décourager un parsing fragile par correspondance exacte, une technique que la spécification emprunte à TLS.

Ce qu'il faut changer dans votre pipeline

Si votre analytique applique encore des expressions régulières à la chaîne UA complète, trois choses se cassent avec le temps. Les numéros de version dérivent vers .0.0.0, les versions de plateforme se figent, et la détection du mobile fondée sur la recherche de sous-chaînes devient peu fiable. Le chemin de migration est simple :

1. Préférez les indices structurés à faible entropie à l'analyse de la chaîne UA.
2. Ne traitez la chaîne UA réduite que comme un repli pour les clients anciens.
3. Résistez à la tentation de demander des indices à forte entropie « au cas où » : chaque indice supplémentaire élargit votre surface de fingerprinting et votre exposition réglementaire.

La leçon plus large rejoint tout ce que nous construisons. Les éditeurs de navigateurs retirent méthodiquement l'entropie passive de la plateforme web. La bonne réponse n'est pas de la poursuivre à travers de nouvelles API, mais de concevoir une mesure qui n'en a jamais eu besoin.

Sources

• Chrome for Developers — User-Agent Reduction
• MDN — User-Agent Client Hints headers (Sec-CH-UA)
• W3C — User-Agent Client Hints specification
• MDN — Accept-CH header