Examiner Baidu depuis différents points de sortie : index, opérateurs et limites

En examinant à distance un moteur de recherche régional, l'erreur la plus coûteuse consiste à imputer à l'IP de sortie chaque écart observé. Une page de résultats naît d'au moins quatre entrées indépendantes : ce que contient l'index du moteur à cet instant, l'inférence géographique du réseau d'origine de la requête, la préférence de langue déclarée par le client et le réglage de région ou de filtre sélectionné dans l'interface. Le proxy ne modifie que la deuxième.

Dans le cas de Baidu, cette distinction est encore plus nette, car ce qui définit l'identité du moteur se situe non pas du côté réseau mais du côté index : quelles langues sont majoritairement représentées dans les documents, quelles sources trouvent leur place dans la page de résultats, et si une requête trouve ou non une couverture dans cet index. Passer d'un point de sortie en Allemagne à Singapour ne modifie pas ce poids.

Les sections ci-dessous construisent successivement : le chemin de la requête sur le réseau, la répercussion de la différence d'index sur la mesure, le test du comportement des opérateurs, les limites de conformité et la configuration.

D'où l'ensemble des résultats de Baidu est-il alimenté ?

Baidu n'est pas une couche de métarecherche. Il parcourt le web avec son propre crawler, tient son propre index et produit son classement avec ses propres signaux. Concrètement, du point de vue de la mesure : vous ne pouvez pas utiliser comme référence ici le classement observé sur un autre moteur, et l'écart entre deux moteurs n'est pas une erreur mais une situation attendue. Qu'une requête reste sans réponse ici tient aussi le plus souvent à l'index, non au réseau.

Le deuxième facteur déterminant est le poids linguistique et documentaire. L'index est majoritairement alimenté par du contenu en chinois ; entre une requête rédigée en chinois et son équivalent en turc ou en anglais, vous constaterez de grands écarts en nombre de résultats, en diversité de blocs et en profondeur. Sur les requêtes en caractères latins, l'ensemble des résultats s'éclaircit et s'épuise rapidement dès la deuxième ou la troisième page. Cela ne signifie pas que votre point de sortie « ne fonctionne pas » : cela signifie que la couverture de votre langue de requête dans l'index est étroite.

Le troisième point est l'écosystème propre au moteur. Les blocs issus de ses propres services — encyclopédie, questions-réponses, contenu communautaire — occupent une place notable dans la page de résultats. La présence et l'ordre de ces blocs varient selon le type de requête (recherche d'information, navigation, intention commerciale). En concevant une comparaison, répondez à la question « de quels blocs la page est-elle composée » avant celle du « à quel rang suis-je » ; lorsque la composition des blocs change, un glissement dans le classement organique ne dit rien à lui seul.

La chaîne de requête et le point où intervient le proxy

Lorsque vous envoyez une requête, le nom de domaine est d'abord résolu, puis la connexion TCP est établie et la négociation TLS a lieu. Si vous utilisez un proxy HTTP, le client déclare la cible sous la forme CONNECT ornek.example:443 et le proxy prend en charge la résolution ; en SOCKS5, le lieu de la résolution dépend du client. Cette distinction compte plus qu'il n'y paraît : si la résolution est effectuée sur votre réseau, le nom de la cible apparaît sur votre serveur DNS local et un nœud de périphérie proche de vous est retourné alors que la connexion est établie depuis le pays du proxy. Pour le détail, où le DNS est-il résolu en SOCKS5 et la méthode HTTP CONNECT.

La page de résultats elle-même ne provient pas d'un seul nom de domaine : les scripts de l'interface, les icônes et les aperçus visuels sont servis depuis des noms de domaine de ressources statiques distincts. Si vous avez écrit une règle ne couvrant que le domaine principal, la page s'ouvre mais s'affiche à moitié — le signe non pas que le proxy ne fonctionne pas, mais que votre périmètre est trop étroit.

Comment prendre en compte la différence d'index dans votre mesure ?

La différence d'index ne fausse pas une mesure : elle change ce que la mesure mesure. Une configuration qui l'ignore lit comme « mon point de sortie a un problème » un résultat qui dit en réalité « la couverture de cette requête dans l'index est étroite ». C'est pourquoi chaque série doit comporter au moins une requête de contrôle : un terme dont vous savez que la couverture est abondante et qui occupe assurément une large place dans l'index. Si la requête de contrôle répond normalement et que votre requête de mesure revient vide, le problème n'est pas sur le réseau.

La deuxième pratique consiste à exécuter la requête dans deux langues. En suivant comme deux séries distinctes l'écriture chinoise et l'écriture latine d'un même concept, vous pourrez déterminer si l'écart observé provient de la langue ou du point de sortie. Gardez le point de sortie fixe dans les deux séries ; si vous changez à la fois la langue et le point de sortie, il vous restera un tableau ininterprétable.

La troisième est la conservation des preuves. Dire « j'ai vu » une page de résultats n'est pas une mesure. Pour chaque tour, conservez le texte de la requête, l'horodatage, l'étiquette du point de sortie, son pays, l'en-tête de langue du client et la version enregistrée de la page. Il est courant que la même requête donne un résultat différent à deux semaines d'intervalle ; si vous n'avez que votre mémoire, vous ne pourrez expliquer cet écart à personne. N'utilisez pas non plus comme métrique les estimations affichant un nombre de résultats ; ces valeurs sont approximatives et varient d'un tour à l'autre.

Séparer les entrées : réseau, client, interface, index

Pour imputer un écart à la bonne cause, vous devez activer et désactiver les entrées une par une. Le tableau ci-dessous résume les quatre entrées qui façonnent une requête de recherche et indique si le proxy agit ou non sur chacune. En construisant votre protocole de mesure, considérez ces lignes comme autant de variables : n'en faites varier qu'une à la fois.

La ligne la plus souvent confondue dans ce tableau est la préférence de langue. Quand vous activez un proxy, votre point de sortie est déplacé dans un autre pays mais votre navigateur envoie toujours la même liste de langues ; et dans la plupart des configurations, le moteur accorde du poids à cette liste. C'est presque toujours la source de la plainte « j'ai changé de point de sortie, l'interface est toujours dans la même langue ». Un test de pays mené sans changer la langue du client ne mesure que le côté réseau.

Le réglage de l'interface, lui, est transporté par cookie : un second tour effectué sans ouvrir un profil vierge hérite des préférences du premier. Exécutez chaque tour de mesure dans un profil de navigateur distinct et vierge.

De quelles entrées l'écart dans les résultats s'accumule-t-il ?

Le schéma ci-dessous présente, avec des poids indicatifs, l'origine de l'écart que vous observez entre deux points de sortie. Il ne s'agit pas d'un résultat de mesure, mais de parts relatives illustrant l'ordre de décision : la part la plus importante se situe généralement du côté de l'index et de la langue, tandis que l'inférence réseau est une entrée qui façonne le résultat sans le déterminer à elle seule.

En pratique, cela signifie : si, dans un test où vous ne changez que le pays de sortie, l'écart est plus faible que prévu, votre configuration n'est pas défectueuse. L'écart est faible parce que vous avez fait varier une variable de faible poids. Si vous voulez observer un écart marqué, il vous faut aussi modifier la langue et le réglage de l'interface conformément à votre scénario, mais en menant cela comme une série distincte.

L'inverse est également vrai : le côté réseau n'est pas négligeable sous prétexte que son poids est faible. Les blocs locaux, les liens vers des services régionaux et certains avertissements de contenu sont sensibles au réseau d'origine de la requête. Vérifier la présence de ces blocs est souvent une sortie plus précieuse que la question « à quel rang suis-je » — car elle est reproductible et démontrable par capture d'écran. Le réseau auquel le point de sortie semble appartenir entre aussi dans ce tableau : le fait qu'une adresse relève d'un datacenter ou d'un réseau d'abonnés se lit dans le système autonome dont elle dépend (ASN et réputation d'IP).