Proxy pour Brave Search : index indépendant, contrôle des requêtes et mesure

Ce qui distingue Brave Search des autres front-ends axés sur la confidentialité, c'est qu'il produit la majeure partie de ses résultats depuis sa propre infrastructure de crawl et d'indexation, au lieu de les reprendre d'un autre moteur. Alimenté par des contributions anonymes issues des navigateurs participants, cet index fonctionne sans compte utilisateur.

Du point de vue du proxy, cela se résume à un tableau simple : en l'absence de profil persistant vous identifiant côté serveur, les signaux qui classent la requête se limitent à votre adresse de sortie, aux en-têtes portés par la connexion et aux paramètres de la barre d'adresse. Vous pouvez contrôler les trois.

Les sections suivantes traitent ces trois signaux un à un ; viennent ensuite la configuration, la vérification et la gestion de la cadence. Si vous menez des comparaisons, il faut apprendre séparément d'où chaque moteur produit ses résultats ; le poids de la décision proxy change avec la source des résultats.

Par où passe une requête avant d'atteindre le front-end ?

Lorsqu'une requête quitte le navigateur, elle porte trois types d'informations : l'adresse cible, l'identité réseau qui établit la connexion et les en-têtes de la requête. Le proxy ne modifie que la deuxième. La liste de langues, les en-têtes d'identification du client (user-agent et client hints à faible entropie) et, le cas échéant, les préférences locales restent inchangés ; la taille d'écran, elle, n'apparaît pas dans un en-tête mais se déduit de la valeur de viewport lue par les scripts de la page. Le navigateur ne transporte des indices comme le viewport ou la densité de pixels dans l'en-tête de requête que si le site les demande explicitement via Accept-CH ; par défaut, il ne les transporte pas. C'est pourquoi changer de sortie ne produit pas à soi seul l'apparence d'« un autre utilisateur ».

La deuxième étape est le serveur proxy. Sur du trafic HTTPS, la seule chose qui s'y fait est d'ouvrir un tunnel avec CONNECT et de transporter les octets chiffrés ; le contenu n'est pas lu. Le front-end voit que la requête provient de ce serveur et peut classer le réseau auquel appartient l'adresse. Ce classement repose sur l'information de système autonome (ASN et réputation d'IP).

À la troisième étape, la requête trouve sa correspondance dans l'index. Les résultats issus de son propre index et ceux complétés par des sources externes pouvant se combiner sur la même page, n'interprétez pas directement comme une « différence régionale » les petits écarts entre deux listes obtenues depuis deux sorties. Prenez d'abord deux tours avec la même sortie pour mesurer le bruit de fond, puis changez de sortie.

Le gabarit à écran étroit change la mise en page, pas l'ensemble de résultats

Dans un index indépendant, la correspondance d'une requête est produite en un seul endroit ; lorsque vous passez en écran étroit, ce qui change n'est pas cette correspondance, mais sa présentation. Les noms de domaine renvoyés restent en grande partie les mêmes, en revanche la mise en page se resserre, les blocs latéraux se déplacent dans la liste et le nombre de lignes visibles au premier écran diminue. En pratique, la distinction se pose ainsi : si la grandeur mesurée est « à quelle position », les deux gabarits donnent la même réponse dans la plupart des tours ; s'il s'agit de « était-ce au premier écran », la réponse dépend directement du gabarit. Vous pouvez mener le suivi de position sur une seule série, pas le suivi de visibilité.

Le deuxième sujet, moins connu, est la façon dont l'état des filtres est transporté en écran étroit. Un choix de Goggle ou de recherche sécurisée est attaché au lien de la requête ; même si le gabarit change, la règle continue de s'appliquer tant que le lien reste identique. Le problème survient lorsque, en écran étroit, le lien est raccourci manuellement ou que la requête est relancée depuis le raccourci de l'interface : la règle saute silencieusement, le classement revient à sa forme simple et vous prenez ce retour en arrière pour une différence de gabarit. Avant de clore le tour, vérifiez que le nom du jeu de règles actif est toujours affiché à l'écran et consignez-le dans le relevé du tour.

Le côté gabarit et le côté réseau sont deux décisions distinctes : si vous voulez mesurer comment est traitée une requête venant d'un réseau d'opérateur, il ne s'agit plus de mise en page mais de la classe de la sortie, et proxy mobile se met en place comme une série distincte pour cela.

Avant de décider de mener deux séries, clarifiez ceci : dans votre rapport, la sortie en écran étroit constitue-t-elle une ligne à part entière, ou une confirmation du résultat en écran large ? S'il s'agit d'une confirmation, un tour d'échantillon hebdomadaire suffit et vous n'avez pas besoin d'exécuter les deux gabarits à chaque tour. S'il s'agit d'une ligne à part entière, nommez les deux séries distinctement dès le départ ; deux séries fusionnées après coup ne peuvent pas être séparées rétroactivement, puisque le gabarit a changé entre-temps.

Enfin, tenez compte du volume de données. Le gabarit à écran étroit porte généralement moins d'images, mais mener deux séries en parallèle double le transfert total. Dans un pool facturé au quota, cet écart se voit sur la facture mensuelle ; limitez le nombre de séries à vos besoins et fermez les profils inutilisés.

Restreindre le résultat avec les opérateurs et les Goggles

Le moyen le moins coûteux de réduire le bruit dans une mesure est de travailler côté requête, pas côté réseau. Rechercher une expression exacte entre guillemets, utiliser limitation à un domaine pour se limiter à un seul nom de domaine ou exclure un terme indésirable restreint l'origine de l'écart entre deux tours. Plus la requête est précise, plus l'écart que vous constatez en changeant de sortie est interprétable.

Brave Search ajoute par-dessus une couche appelée Goggles : des jeux de règles publics qui réordonnent l'ensemble de résultats. Un Goggle met en avant ou repousse certains noms de domaine ; la requête reste la même tandis que le critère de classement change. Si vous ne consignez pas quel Goggle est actif pendant la mesure, vous risquez d'attribuer au pays de sortie l'écart entre deux tours.

La troisième variable, ce sont les sélecteurs de région et de langue de l'interface. Ces sélecteurs peuvent orienter la liste vers un autre marché, indépendamment de l'adresse de sortie. Si le sélecteur contredit le pays de sortie, le tableau obtenu ne correspond à la vue d'aucun utilisateur réel ; réglez les deux ensemble et consignez-les tous les deux.

L'usage des opérateurs présente un autre avantage, hors mesure : restreindre le résultat réduit aussi le nombre de requêtes envoyées. Écrire deux requêtes précises plutôt que cinq requêtes larges donne à la fois une sortie facile à interpréter et moins de trafic passant par votre sortie. Dans les pools facturés au quota, c'est directement un poste de coût (calcul de bande passante).

• Figez le jeu de requêtes avec ses opérateurs ; n'ajoutez pas d'opérateur après coup.
• Consignez à chaque tour le nom du Goggle ou du filtre actif.
• Alignez le sélecteur de région sur le pays de sortie.
• Fixez le niveau de recherche sécurisée ; passer d'un niveau à l'autre change l'ensemble.

Quel type de sortie convient à quel usage ?

Le choix du type de sortie se pense sur deux axes : l'étendue du pool et la durée pendant laquelle vous pouvez rester sur une même adresse. Ces deux propriétés fonctionnent en sens inverse. Un pool large vous évite de dépendre d'une seule adresse, mais sortir d'une adresse différente à chaque requête rompt la cohérence de session.

Dans une série de suivi de longue durée, le maintien sur l'adresse prime généralement. Regarder par la même fenêtre pendant des mois avec une seule sortie ISP produit une série plus lisible que sortir d'une adresse différente à chaque tour. En revanche, si vous voulez comparer côte à côte les sorties de différentes villes, la granularité par ville d'un pool residential est nécessaire.

Une configuration rotating convient quant à elle pour répartir la charge sur des travaux de lecture de données publiques sans session. Utiliser pour le suivi de position une configuration qui change d'adresse à chaque requête transforme la mesure elle-même en source de bruit : vous ne pourrez pas déterminer si l'écart entre deux tours vient du mouvement du moteur ou de la nouvelle sortie.