Bing Proxy : choix du marché, résultats locaux et séparation des sessions

Deux profils types utilisent Bing via un proxy. D'une part l'équipe qui veut voir comment son propre contenu est listé sur un autre marché ; d'autre part l'agence qui contrôle comment les blocs d'entreprises locales et de cartes varient d'une ville à l'autre. Leur question est la même : la page que je vois est-elle vraiment celle que voit l'utilisateur cible ?

La réponse dépend de la cohérence de trois réglages entre eux. Le marché des résultats et la langue de l'interface se définissent dans l'adresse de la requête, l'interprétation de la localisation se lit depuis l'adresse de sortie, et la mise en page de la page dépend de la façon dont le navigateur se présente. Si vous ne configurez pas ces trois éléments séparément, votre capture d'écran devient un mélange que personne ne voit réellement.

Les sections suivantes traitent successivement de ces réglages, du comportement des blocs locaux, de l'effet de la classe d'appareil et du protocole qui rend la mesure reproductible. La partie installation vient à la fin ; il est plus efficace de clarifier d'abord ce que vous mesurez.

À partir de quelles entrées une page de résultats Bing est-elle composée ?

Une page de résultats n'est pas un bloc unique. La liste de liens organiques, les encadrés de réponse, les bandeaux d'images et de vidéos, les blocs shopping et locaux se combinent sur la même page mais proviennent de sources différentes. Les blocs affichés varient selon l'intention de la requête ; une requête de marque et une requête « près de moi » ne produisent pas la même mise en page.

Quatre entrées dominent la composition de ces blocs : le texte de la requête, le marché et la langue sélectionnés, le contexte géographique de la requête et la classe d'appareil du client. Le proxy n'agit directement que sur la troisième, c'est-à-dire le contexte géographique. Le marché et la langue sont des champs que vous envoyez ; la classe d'appareil se lit dans la chaîne d'identification déclarée par le navigateur.

Pourquoi cette distinction importe-t-elle ? Parce qu'elle vous indique où regarder lorsqu'un résultat inattendu apparaît. Si le bloc local ne s'affiche pas du tout, le problème vient généralement du contexte de localisation. Si l'interface s'affiche en anglais, on regarde le champ de langue. Si la mise en page diffère de vos attentes, c'est la classe d'appareil qui est en jeu. Quand les trois se mélangent, le diagnostic devient impossible.

Distinguez le marché des résultats de la langue de l'interface

Côté Bing, le marché et la langue sont des champs distincts. Le marché indique dans quel couple pays-langue les résultats sont compilés ; la langue indique dans quelle langue arrivent l'interface et le contenu privilégié. Les deux vont souvent de pair, mais ce n'est pas obligatoire : vous pouvez demander le marché allemand avec une interface en anglais. Ces champs sont documentés dans l'interface de recherche Bing et largement utilisés dans l'interface web.

Il existe aussi un champ de pays ; il sert à restreindre le pays d'origine des résultats et peut se comporter indépendamment du choix de marché. Si vous réglez les trois sur des valeurs différentes en même temps, il devient difficile d'expliquer pourquoi le résultat est tel qu'il est. Gardez une règle simple lors de la mise en place d'une mesure : marché, langue et pays de sortie doivent pointer vers la même cible, et ne différenciez que pour une expérimentation délibérée.

Le proxy n'envoie aucun de ces champs. Le proxy ne change que le point de départ de la requête ; les champs de la barre d'adresse relèvent de votre responsabilité. De même, l'en-tête de langue du navigateur reste côté client. Utiliser une sortie allemande tout en envoyant un en-tête de langue turc revient à donner à Bing deux indices contradictoires, et le résultat se situera quelque part entre les deux.

Lorsque vous choisissez le pays de sortie, regardez non pas la longueur de la liste mais la couverture des marchés que vous allez mesurer. Côté européen, les sorties les plus utilisées passent généralement par l'Allemagne et les Pays-Bas ; ces deux pays offrent une grande diversité de fournisseurs et se connectent aux marchés voisins avec une faible latence. Si vous testez le marché américain, tenez aussi compte des différences entre États : au sein d'un même pays, des sorties côte est et côte ouest peuvent produire des résultats différents sur les blocs sensibles à la localisation.

Session, cookies et profil : une configuration qui ne contamine pas la mesure

Le débat sur la personnalisation tourne généralement autour de l'IP, mais le poids se situe le plus souvent dans la session. Un compte connecté, des cookies accumulés et le contexte laissé par les recherches précédentes peuvent influencer l'aspect du résultat plus directement que l'adresse de sortie. Le proxy ne touche pas à cette couche ; c'est pourquoi une comparaison faite en activant et désactivant le proxy dans le même navigateur n'est pas propre.

La solution est l'isolation : un profil de navigateur dédié à la mesure, sans compte, sans extension, sans accumulation d'historique. Rattachez la sortie au profil ; un réglage défini au niveau du système d'exploitation couvre toutes les applications et redirige aussi votre travail quotidien. Cette distinction est particulièrement importante dans les navigateurs qui héritent du réglage système, comme Edge : un proxy défini côté Windows fait passer par la même sortie le trafic d'applications que vous ne mesurez pas, ce qui contamine à la fois le volume et le schéma.

Le deuxième point, aussi important que le profil, est que la sortie reste identique pendant toute la mesure. Si l'adresse change en cours de route, la première moitié du tableau vient d'un pays et la seconde d'un autre. Pour les travaux exigeant une adresse fixe, on préfère une sortie statique ; la rotation convient aux lectures de données publiques sans session.

Si vous travaillez en équipe, la méthode d'authentification relève aussi de ce chapitre. Pour les bureaux à IP fixe, la liste blanche est pratique : vous n'intégrez aucune information dans le client, l'autorisation se lit à partir de l'adresse. Pour les utilisateurs nomades, un nom d'utilisateur et un mot de passe sont nécessaires, car le réseau change chaque jour. Mélanger les deux méthodes sur le même compte est la cause la plus fréquente d'erreurs d'autorisation inattendues.

Blocs locaux, résultats cartographiques et fiches d'entreprise

Les résultats locaux sont la partie de la page la plus sensible à la localisation. Pour les requêtes de type « près de moi », les entreprises listées varient selon le point auquel la requête est rattachée. Une sortie au niveau du pays ne suffit souvent pas ici : une sortie allemande vous montre le marché allemand, mais ne vous permet pas de distinguer les résultats de Munich de ceux de Hambourg.

Une vue au niveau de la ville exige deux choses. D'abord un pool prenant en charge le ciblage par ville ; ensuite, l'autorisation de localisation du navigateur désactivée. Si cette autorisation est active, les coordonnées déclarées par l'appareil priment sur l'adresse de sortie et ce que vous mesurez n'est pas le proxy mais l'endroit où vous vous trouvez. La logique de ciblage ciblage par ville et par ISP est détaillée dans cet article.

Les cartes et les fiches d'entreprise sont en outre alimentées par une source de données distincte ; le bloc local peut donc changer sans que le classement organique bouge, ou l'inverse. Ne réduisez pas les deux à un seul chiffre de « position », enregistrez-les dans des colonnes séparées. Pour une même requête, le bloc local n'apparaît parfois pas du tout ; ce n'est pas une erreur, c'est une interprétation différente de l'intention de la requête à cet instant.