Contexte technique

Le blog de l’auteur utilise un Cloudflare Worker pour filtrer les requêtes HTTP avant qu’elles n’atteignent le compteur côté serveur. L’objectif est de distinguer les navigateurs humains des bots sans recourir à du JavaScript exécuté côté client. Sur une période de deux jours complets (UTC), 372 requêtes contenant un User‑Agent de type navigateur ont été soumises aux règles du Worker ; 277 d’entre elles, soit 74,5 %, ont été reclassées hors de la catégorie « Browsers ».

Parallèlement, le compteur natif de Cloudflare Web Analytics a enregistré seulement 14 chargements de pages, alors que le Worker a conservé 95 observations HTML de navigateurs. Cette divergence initiale a déclenché une série de vérifications afin de comprendre quelles caractéristiques des requêtes étaient réellement discriminantes.

Fonctionnement du classificateur

Le Worker se base sur quatre sources d’évidence : le réseau (ASN), les en‑têtes Fetch Metadata (Sec‑Fetch‑Mode, Sec‑Fetch‑Dest, Sec‑Fetch‑Site), les en‑têtes Accept/Accept‑Language, et le User‑Agent. Aucun de ces éléments ne prouve l’intention du client, mais combinés ils permettent de repérer des patterns typiques de bots ou de services d’hébergement.

Première règle : les requêtes provenant d’ASNs de grands fournisseurs de cloud (Google Cloud, AWS, Azure) sont classées comme cloud‑browser avant d’appliquer les critères de forme de navigateur. Dans l’échantillon de 72 h jusqu’au 3 septembre, 430 sur 844 GET réussis (≈ 51 %) étaient « navigation‑shaped » provenant de ces réseaux, dont un pic de 374 requêtes attribuées à un client Google Cloud déclarant Chrome Mobile 114. Les en‑têtes de navigation n’ont pas permis de séparer ce cluster.

Deuxième règle : l’absence de métadonnées Fetch ou un Accept incompatible avec le rendu HTML conduit à un rejet de la classification « browser ». Cette règle a détecté 60 requêtes classées « cloud‑classified » qui possédaient pourtant les en‑têtes de navigation attendus, révélant une sous‑détection initiale.

Analyse des résultats mesurés

La comparaison entre le compteur Edge (Worker) et le compteur script (Web Analytics) montre des écarts majeurs : le premier indique 578 visites contre 52 au second à une date donnée, puis 1 209 contre 113 sur une période plus large. Ces chiffres sont partiellement expliqués par des différences de fenêtre temporelle, l’inclusion de routes /stats dans le compteur script, et le fait que le compteur Edge exclut les pré‑fetches et les réponses non‑HTML.

Des indicateurs internes renforcent l’hypothèse de trafic automatisé : le 2 septembre, 156 sur 164 observations UA n’ont aucun referrer, et un client unique a récupéré 31 pages distinctes au même milliseconde, un comportement improbable pour un lecteur humain.

Neuf signatures stockées (crawlers, assistants) ont été reconnues, mais elles ne comptent pas les utilisateurs qui demandent à un assistant vocal de lire le contenu, ce qui souligne la séparation entre identité client et lectorat réel.

Limites et perspectives

Le système ne peut pas garantir une mesure exacte de l’audience : il ne distingue pas les humains qui utilisent des extensions de blocage JavaScript ni les bots qui imitent parfaitement les en‑têtes de navigation. De plus, la liste curée des ASNs de cloud exclut certains réseaux partagés, ce qui peut laisser passer des bots légitimes ou, au contraire, éliminer des navigateurs humains légitimes.

Pour affiner la précision, il serait nécessaire d’ajouter des marqueurs de session persistants (cookies sécurisés) ou de croiser les logs d’accès avec des bases de données de signatures de crawlers régulièrement mises à jour. En l’état, le classificateur fournit une vue plus fiable que le simple comptage d’User‑Agent, mais il reste dépendant de la qualité des en‑têtes HTTP et de la granularité du mapping ASN.