Utiliser un proxy avec Mojeek : signal régional, état de session et cadence des requêtes

Sur les pages de moteurs de recherche, la plupart des discussions sur les proxys se compliquent parce qu'on ignore qui produit réellement le résultat. De nombreux services récupèrent leur jeu de résultats auprès d'un partenaire ; vous croyez mesurer une partie alors que vous enregistrez en réalité le comportement d'un second fournisseur. Mojeek offre à cet égard un terrain plus simple : crawl, indexation et classement se font sous le même toit.

Cette simplicité n'élargit pas le rôle du proxy, mais elle le clarifie. Lorsque votre adresse de sortie change, ce qui est affecté n'est pas l'ensemble du classement, mais l'une des quelques entrées que le moteur lit comme un indice régional. Les autres entrées — langue de l'interface, filtre pays de la page de paramètres, requête elle-même — restent côté navigateur et le proxy n'y touche pas.

Les sections ci-dessous détaillent cette distinction dans l'ordre : quelle couche regarde le réseau, quelle couche vous regarde ; laquelle il faut figer lors d'une mesure ; et comment planifier la cadence lorsque l'échelle augmente.

Que change un proxy sur un moteur qui parcourt son propre index ?

Une requête Mojeek traverse trois couches distinctes. Tout en haut se trouve la couche requête et interface : l'expression que vous saisissez, la langue que vous choisissez, le filtre pays que vous cochez dans la page de paramètres. L'ensemble est conservé côté client et échappe au champ de vision du proxy — changer de sortie ne réinitialise pas une préférence, car celle-ci réside dans le stockage de votre navigateur.

La couche intermédiaire est celle de l'index et du classement. Le crawler du moteur a collecté, analysé et ordonné les documents. Cette couche n'est pas reconstruite pour chaque utilisateur d'une requête à l'autre ; la même requête dans les mêmes conditions renvoie très largement le même ensemble de documents. Lorsque vous vous demandez pourquoi un résultat figure en haut, c'est le comportement d'indexation de cette couche qu'il faut examiner, et non votre réglage de proxy.

La couche la plus basse est celle du transport et de la sortie. La requête est établie sur TCP, chiffrée par TLS, et la seule identité réseau visible côté serveur est votre adresse IP de sortie. Ce que le moteur peut lire de cette adresse est limité : le système autonome (ASN) auquel elle appartient et, approximativement, le pays où elle semble enregistrée. Pour comprendre le fonctionnement de cette classification, l'article sur l'ASN et la réputation IP est un bon point de départ.

L'intérêt pratique de séparer ces trois couches est le suivant : lorsque vous constatez un changement de résultat, vous demandez d'abord quelle couche a bougé. Votre préférence a-t-elle changé, l'index a-t-il été rafraîchi, ou votre sortie s'est-elle simplement déplacée vers un autre pays ? Les équipes qui ne se posent pas cette question imputent au proxy un écart provoqué par une préférence du navigateur et cherchent la solution au mauvais endroit.

Comment le pays de sortie et la langue de l'interface se distinguent-ils dans le classement ?

L'effet régional ne dépend pas d'un unique bouton ; il résulte de la combinaison de deux entrées indépendantes. La première est l'indice côté réseau : le pays d'enregistrement de votre adresse de sortie. La seconde est la préférence explicite côté application : la langue de l'interface et le filtre pays de la page de paramètres. Lorsque les deux ne pointent pas dans la même direction, il en résulte un profil hybride qu'un utilisateur réel produit rarement.

Exemple concret : si vous utilisez une sortie en Allemagne tout en laissant l'interface en anglais, la couche réseau indique l'Allemagne tandis que la couche applicative déclare une préférence de langue donnée. La page renvoyée se situe quelque part entre les deux et ne correspond exactement ni à ce que voit un utilisateur consultant depuis l'Allemagne, ni à ce que voit un utilisateur dont la langue est l'anglais. Si vous effectuez une comparaison, vous devez consigner cet état intermédiaire, faute de quoi vous inscrirez deux mesures dans la même colonne.

La bonne configuration consiste à figer délibérément les deux entrées. Si vous souhaitez étudier la surface de résultats d'un pays, prenez une sortie dans ce pays, réglez la langue de l'interface sur la langue courante de ce pays et orientez le filtre pays dans le même sens. Pour la liste des pays, localisations proxy et pour un affichage TR, une sortie en Turquie vous pouvez le consulter.

Une seule règle résout l'essentiel : dans une série, ne faites varier qu'une seule variable. Si vous changez de pays, laissez la langue fixe ; si vous changez de langue, laissez la sortie en place. Un écart issu d'une mesure où deux variables bougent ensemble ne dit pas de quelle entrée il provient.

Sortir l'état du navigateur du périmètre de mesure

Un moteur axé sur la confidentialité ne vous profile peut-être pas via un compte ; cela ne signifie pas que votre mesure est propre. L'essentiel de l'état qui influence l'affichage de la page réside déjà dans votre navigateur : cookies de préférence enregistrés auparavant, règles injectées par des extensions, blocs masqués par un bloqueur de contenu, largeur de fenêtre et échelle de police.

Le côté le plus sournois de ces résidus d'état est qu'ils se transmettent à votre insu. La semaine dernière, vous avez coché un filtre pays ; cette semaine, en démarrant une nouvelle série avec le même profil, le filtre est toujours actif et vous prenez cela pour un effet du proxy. De même, si une extension masque certains liens de la page, vous comptez moins de résultats qu'il n'y en a réellement.

La solution n'est pas compliquée, mais elle demande de la discipline. Ouvrez un profil de navigateur distinct pour la mesure ; ce profil ne doit contenir que la configuration du proxy et le strict minimum d'extensions. Commencez chaque série avec un stockage vide et ne changez aucune préférence avant la fin de la série. Ne gardez dans ce profil aucun onglet connecté à un compte — un onglet avec une session ouverte continue de générer des requêtes en arrière-plan tant qu'il reste ouvert.

• Séparez complètement le profil de mesure du profil que vous utilisez au quotidien.
• Notez la largeur de la fenêtre ; la mise en page varie selon la largeur.
• Gardez le bloqueur de contenu désactivé dans le profil de mesure, ou utilisez le même réglage à chaque série.
• Videz le stockage avant de commencer la série, et non en cours de série.
• Inscrivez dans la ligne de journal le profil utilisé ; le résultat est propre au profil.

Une fois ce dispositif en place, l'écart que vous observez en changeant de sortie provient réellement de la sortie. Auparavant, les écarts constatés venaient le plus souvent de la mémoire du navigateur, et aucun réglage de proxy n'y remédie.

Aligner la cadence des requêtes sur la taille du pool

Pour des recherches effectuées manuellement une à une, la cadence n'est pas un problème. En revanche, dès que vous mettez en place un dispositif de contrôle exécutant des dizaines de requêtes à la suite, la cadence devient la première limite. Une série dense de requêtes issues de la même sortie à intervalles rapprochés produit un motif qui ne ressemble pas à un usage humain, et vous risquez de rencontrer un écran de vérification.

L'écran de vérification n'est pas une sanction, c'est un signal de ralentissement. La bonne réaction n'est pas de réessayer à la même vitesse, mais de battre en retraite progressivement : augmentez le délai d'attente de façon exponentielle, puis revenez à la cadence normale après quelques tours. Cette page n'explique pas comment contourner les écrans de vérification, mais comment régler la cadence pour ne jamais les déclencher.

La cadence et la taille du pool sont les deux côtés d'une même équation. Une fois que vous avez décidé du nombre de requêtes par heure, il vous faut assez d'adresses pour maintenir la charge par sortie à un niveau acceptable. Dans la plupart des tâches de contrôle, réduire le nombre de requêtes est une décision moins coûteuse qu'augmenter le nombre d'adresses ; l'objectif de la mesure n'est pas le volume mais la comparabilité. Si vous ouvrez des requêtes en parallèle, limite de connexions simultanées doit également être pris en compte.

Si vous avez réellement besoin d'un accès à grande échelle, consultez d'abord l'interface de recherche documentée du moteur. Travailler via une interface officielle donne des résultats plus prévisibles et reste conforme aux attentes des parties. Avant toute démarche de scraping de pages, il convient de lire robots.txt ainsi que les conditions de service.