Pourquoi les analyses ne fonctionnent pas dans Brave (et que faire)

Brave Shields bloque Google Analytics, Tag Manager et la plupart des traceurs tiers par défaut — mais la façon dont il le fait rend la perte invisible dans votre tableau de bord. Ce qui se passe vraiment au niveau réseau, pourquoi vous ne voyez jamais d'erreur, et quelles sont vos options.

Brave n'est plus un navigateur de niche

Brave a dépassé les 80 millions d'utilisateurs actifs mensuels dans le monde. Pour des audiences techniques, soucieuses de la vie privée ou proches du monde crypto, sa part de marché atteint régulièrement 5 à 15 % — parfois plus. Si vous publiez du contenu technique, vendez un SaaS pour développeurs, ou ciblez une audience attentive à la vie privée, une part significative de vos visiteurs utilise Brave en ce moment.

Et par défaut — à l'installation, sans toucher à aucun paramètre — Brave bloque la grande majorité des scripts d'analyse.

Ce que Brave Shields fait vraiment

Brave Shields n'est pas un mécanisme unique. Ce sont trois couches de protection appliquées dans cet ordre :

1. Blocage au niveau réseau — pour les traceurs présents dans EasyList, EasyPrivacy et les listes propres de Brave, la requête ne sort jamais du navigateur. Dans DevTools, vous verriez (blocked:other) ou (cancelled) sans code de statut.
2. Redirection vers un stub vide — pour certains scripts populaires (y compris des parties de l'écosystème Google), Brave renvoie une réponse locale vide avec HTTP 200 pour ne pas casser la page. La page ne plante pas ; le script ne fait simplement rien. La visite n'est jamais enregistrée par votre analyse, mais la requête a l'air « réussie » dans DevTools.
3. Randomisation d'empreinte — pour tout ce qui se charge effectivement, Brave perturbe les signaux de canvas, WebGL, audio context et énumération de fontes pour empêcher votre traceur de construire une empreinte stable du visiteur.

La couche 2 est celle qui surprend la plupart des propriétaires de sites. Vous ouvrez DevTools, voyez la requête GA4 renvoyer 200 OK, et vous supposez que le suivi fonctionne. Il ne fonctionne pas — le script téléchargé par le navigateur est le stub vide renvoyé par Brave, pas le vrai gtag.js. Aucune donnée ne quitte la page.

Pourquoi votre tableau de bord ne vous le dit jamais

Les produits d'analyse ne mesurent pas leur propre absence. Google Analytics vous montre les visites qu'il a reçues. Il ne peut pas vous montrer les visites où le script ne s'est jamais chargé — ces visiteurs sont, du point de vue de GA4, identiques à des gens qui ne sont pas venus.

Pas de journal d'erreur, pas d'astérisque, pas d'avertissement « votre portée est réduite ». Le chiffre dans votre tableau de bord est simplement plus petit que la réalité d'une quantité qui dépend de la composition de votre audience. Pour un public type Hacker News, cet écart peut facilement dépasser 40 %. Pour un site grand public, il reste de 5 à 15 %.

C'est pourquoi migrer de GA4 vers un outil d'analyse privacy-first fait souvent monter vos chiffres. Pas parce que le nouvel outil surcompte — parce que l'ancien sous-comptait silencieusement depuis des années.

Que pouvez-vous faire

Option 1 : accepter l'écart, ajuster vos décisions

Si votre audience est principalement non technique et que votre taux d'utilisateurs avec bloqueur est faible (disons sous 10 %), la réponse la plus simple est de reconnaître le sous-comptage et de ne pas surinterpréter les petites différences dans votre tableau GA4. Ne prenez pas de décisions de classement sur des chiffres dont vous savez qu'il manque des morceaux.

Option 2 : tracking côté serveur

Déplacez le measurement protocol de GA4 vers votre serveur. Votre code côté client envoie les événements à votre propre endpoint, qui les transfère à Google. Brave ne bloque pas votre domaine.

Le piège : le GA4 côté serveur est véritablement complexe à configurer correctement, le consentement RGPD s'applique toujours (vous collectez les mêmes données personnelles, juste via un autre transport), et vous avez toujours besoin d'une bannière de cookies. Vous avez résolu le problème du bloqueur mais conservé tous les autres.

Option 3 : un traceur privacy-first et résistant aux bloqueurs

Il existe une catégorie de produits d'analyse construits autour de l'idée de ne pas figurer dans les listes de blocage en premier lieu. Plausible, Fathom, GoatCounter et Logly adoptent cette approche avec des compromis légèrement différents.

Le motif commun : un endpoint first-party sur un domaine absent d'EasyPrivacy, pas de cookies (donc pas de bannière de consentement), et un traceur suffisamment petit pour que le maintenir sur une liste de blocage n'en vaille pas la peine. Les pings sortent, la requête renvoie 204 (no content), et la couche de redirection de Brave n'a rien à substituer.

Nous testons Logly contre Brave Shields en Standard et Aggressive, plus uBlock Origin avec EasyPrivacy, comme gate de release. Si une future version de Brave commence à nous bloquer, le gate échoue et nous corrigeons avant le déploiement. D'autres outils de cette catégorie font des validations similaires.

De combien cela change-t-il vraiment vos chiffres ?

Calcul approximatif pour un site à audience technique recevant 10 000 visites réelles par mois :

• ~12 % des visiteurs utilisent Brave ou ont un blocage agressif activé → 1 200 visites perdues en silence.
• Sur les 8 800 restantes, ~25 % utilisent uBlock ou un autre bloqueur → encore 2 200 perdues.
• Ce que GA4 enregistre : ~6 600 visites. Il vous manque environ un tiers de votre audience.

Pour un site grand public les chiffres se compressent (moins de Brave, moins de uBlock) mais vous voyez rarement plus de 90 % du trafic réel, et souvent moins.

Si vous prenez des décisions produit, marketing ou recrutement sur du trafic silencieusement 25 à 35 % en dessous de la réalité, l'écart vaut la peine d'être connu — même si vous ne changez pas d'outil demain.