Où regarder lorsque vous vérifiez les résultats Ecosia ?

Lorsque vous analysez un moteur de recherche qui tire une part importante de ses résultats d'un fournisseur partenaire, votre première décision doit être la suivante : construisez votre mesure indépendamment de la source. Autrement dit, ne tirez aucune conclusion reposant sur l'hypothèse « ces résultats proviennent de tel moteur ». Les partenariats de sourcing peuvent évoluer dans le temps et d'un marché à l'autre ; une hypothèse vraie aujourd'hui invalidera votre tour de mesure dans six mois.

En pratique, une mesure indépendante de la source consiste à consigner ce que vous voyez tel quel : quelle requête, dans quelles conditions, depuis quelle sortie, à quelle date, et quels résultats obtenus. Cet enregistrement conserve sa validité même si la chaîne de sourcing change ; la phrase « cela vient de là », non.

Dans ce tableau, le proxy joue un seul rôle : il change le réseau depuis lequel part la requête. La région sélectionnée dans l'interface, la langue déclarée par votre navigateur et les préférences enregistrées dans votre profil restent identiques, indépendamment de votre sortie. Les sections ci-dessous posent cette distinction pas à pas.

Par où passe une requête avant de devenir une page de résultats ?

La chaîne comporte quatre étapes, et à chacune intervient un acteur différent. Votre client prépare d'abord la requête : liste de langues, cookies et préférences de profil sont ajoutés à ce stade. La requête sort ensuite par la sortie du proxy ; c'est l'adresse que voit la cible. À la troisième étape, le frontal du moteur reçoit la requête et applique sa propre couche de classement et d'interface. À la quatrième, la page est composée et vous est renvoyée.

Le proxy n'intervient qu'à la deuxième étape. Ce qui se passe à la troisième — quelles données sont tirées de quelle source, quel bloc est placé en tête, quels marqueurs sont ajoutés — est indépendant de votre réseau. C'est pourquoi l'observation « j'ai changé de sortie et le jeu de résultats est quasiment identique » n'est pas un dysfonctionnement mais une conséquence naturelle de la chaîne : le côté réseau n'est que l'une des entrées qui façonnent le résultat.

La chaîne comporte une autre partie invisible : la page ne provient pas d'un seul nom de domaine. Les scripts d'interface, les icônes et les petites ressources comme la favicon sont servis depuis des adresses distinctes. Si votre règle ne couvre que le domaine principal, la page s'ouvre mais s'affiche de façon fragmentaire ; cela ne signifie pas que l'installation est défectueuse, mais que sa portée est trop étroite.

Enfin, le volet cookies : le choix que vous faites sur les écrans de consentement et de préférences lors de la première visite est conservé dans le profil et influence les tours suivants. Lors de vos tours de mesure, faites ce choix de façon identique à chaque fois, ou travaillez avec un profil entièrement vierge ; faire des choix différents sur deux tours rend l'écart observé ininterprétable.

Quand le réglage régional de l'interface contredit le pays de sortie

La plupart des interfaces de recherche vous laissent choisir manuellement la région selon laquelle les résultats seront compilés. Ce choix est transporté dans un cookie ou dans un paramètre de l'URL et fonctionne indépendamment du réseau d'où provient la requête. Résultat : deux signaux s'expriment en même temps, la région que vous avez choisie et l'inférence géographique du réseau.

En cas de contradiction, la sélection explicite l'emporte généralement, car une préférence exprimée par l'utilisateur pèse plus lourd qu'un signal déduit. Cela ne rend pas le proxy inutile ; cela change seulement ce que vous mesurez. Un test avec sélection explicite répond à la question « que voit un utilisateur qui choisit cette région ». Un test avec pays de sortie répond à « que voit un utilisateur connecté depuis un réseau de ce pays et qui n'a rien sélectionné ». Ce sont deux questions différentes, à mener comme deux séries distinctes.

Le montage pratique est le suivant : dans la première série, le profil s'ouvre vierge, aucune région n'est sélectionnée et seul le pays de sortie change. Dans la seconde, la sortie reste fixe et seule la sélection régionale de l'interface change. En lisant les deux séries ensemble, vous pouvez déterminer quel écart provient de quel signal. Faire varier deux variables au cours d'un même tour produit un tableau ininterprétable.

La langue se comporte de façon comparable. La liste de langues envoyée par votre navigateur ne change pas avec votre sortie ; passer à une sortie allemande ne met pas automatiquement l'interface en allemand. Si vous voulez mesurer l'effet de la langue, modifiez manuellement la liste de langues et consignez cela comme une série distincte.

À quoi les cartes, les établissements et les blocs locaux sont-ils sensibles ?

Les blocs locaux sont le domaine où l'effet du proxy est le plus net, car sur une requête sensible à la localisation le jeu de résultats réagit directement à l'inférence géographique du réseau. Mais pour observer cette réaction, la requête doit réellement porter une intention locale. Sur une requête conceptuelle, aucun bloc cartographique n'apparaît ; l'interpréter comme « le proxy ne fonctionne pas » est une erreur fréquente.

La seconde condition est que les signaux plus forts soient désactivés. Une autorisation de localisation accordée au navigateur, une sélection régionale enregistrée dans le profil ou un nom de ville saisi dans la barre de recherche écrasent l'inférence réseau. Pour un test de bloc local propre, l'autorisation de localisation doit être refusée, le profil doit être vierge et aucun nom de ville ne doit figurer dans le texte de la requête — dès que vous saisissez le nom de la ville, c'est vous qui déclarez la localisation.

Le troisième point est la résolution. L'inférence réseau est généralement juste au niveau du pays et approximative au niveau de la ville. Une même adresse de sortie peut être rattachée à des villes différentes selon les bases de données ; si vous attendez un résultat précis au niveau de la ville, vous devez donc consigner l'inférence elle-même comme une variable (mon adresse IP notez à chaque tour comment la sortie apparaît via l'outil).

Les paliers d'une collecte de données conforme

Le besoin de collecter des données auprès d'un moteur de recherche n'a pas toujours la même ampleur, et la bonne méthode varie selon cette ampleur. Le schéma de paliers ci-contre le résume en trois marches : contrôle limité mené manuellement, accès via les interfaces officielles et accès à grande échelle encadré par un contrat. À mesure que l'on monte d'un palier, ce n'est pas la difficulté technique qui augmente, mais la dimension de l'autorisation et de la responsabilité.

Le premier palier couvre la plupart des besoins et génère le moins de frictions : pages ouvertes manuellement, nombre limité de requêtes, temporisation entre les tours et enregistrement de chaque tour. À ce palier, le rôle du proxy est clair : permettre de regarder depuis différents pays. Tant que vous avancez à un rythme raisonnable, cet usage ne pose de problème ni sur le plan technique ni sur le plan éthique.

Le deuxième palier intervient lorsqu'un besoin régulier et planifié apparaît. La bonne démarche consiste alors non pas à ouvrir la page automatiquement, mais à étudier les interfaces officielles proposées par le moteur ou par le fournisseur de données. La voie officielle est généralement plus stable : le format ne change pas, les quotas sont connus et vous avez un interlocuteur en cas d'incident. Un montage reposant sur le scraping de pages casse, lui, à chaque modification de l'interface.

Le troisième palier correspond à un usage commercial à grande échelle ; à ce stade, la question cesse d'être technique pour devenir une affaire de contrat et de licence. On n'accède pas à ce palier par une manœuvre technique. Pour le volet infrastructure des travaux de lecture à grande échelle, le proxy web scraping et guide de sélection de proxy peut vous aider, mais l'infrastructure ne règle pas le volet des autorisations.