Table des matières

La fuite de documents lors de la Google Leak de 2024 donne accès à une documentation très structurée, remplie de vocabulaire technique.

D’entrée, il faut être clair : ces documents ne concernent pas directement le cœur des « systèmes de Google search », mais une API qui permet aux développeurs de communiquer depuis l’extérieur avec ces systèmes. Plus précisément, il s’agit de donner un accès à la Google Search aux développeurs qui créent des applications en lien avec l’IA de Google sur Google Cloud Platform, notamment Gemini. L’enjeu pour ces applications est d’empêcher l’IA d’avoir ses défauts habituels : halluciner, inventer de faux faits – et pour cela, il faut baser les faits sur les résultats de la recherche, eux mêmes basés sur le Knowledge Graph et son ontologie.

N’empêche : ces documents, même de manière indirecte, reflètent bel et bien le fonctionnement interne des algorithmes de Google, ses concepts, sa logique.

Par contre, forte nuance : ces documents ne contiennent aucune info sur le poids de chaque concept, chaque paramètre. On ne peut donc que spéculer sur leur usage et leur impact réels.

Les modules

Chaque document porte un titre de ce type :

GoogleApi.ContentWarehouse.V1.Model.ImageExactBoostNavQuery
GoogleApi.ContentWarehouse.V1.Model.ResearchScienceSearchNavboostQueryInfo
GoogleApi.ContentWarehouse.V1.Model.VideoContentSearchNavboostAnchorFeatures
etc

Il y a donc là une structure hiérarchique évidente :

un dossier GoogleApi
qui contient un dossier ContentWarehouse
qui contient un dossier V1
qui contient un dossier Model
qui contient une très longue liste de centaines de « modules »
et chacun de ces modules est nommé selon une convention très anglo-saxonne, qui ressemble elle aussi à une forme de classification interne hiérarchique, qui concatène les termes du plus général au plus hiérarchique :
- Image… ExactBoost… NavQuery
  - une traduction serait : exact boost of navigation query [relative to] image, c’est à dire « renforcement exact de la requête de navigation concernant une image »
- Research… ScienceSearch… NavBoost… QueryInfo
  - qui se lirait à peu près : « renforcement de requete informationnelle dans le domaine de la recherche scientifique »
- etc

Rien qu’en lisant les intitulés de chaque document, on peut donc avoir une vague idée de ce dont il est question, même si beaucoup de formulations sonnent de manière obscure.

En effet, de nombreux titres de modules utilisent des abréviations. Une des plus fréquentes est « NSR ». Mike King, cité par l’article de Rand Fishkin qui a révélé la fuite, et un des premiers à en avoir livré une analyse, a supposé que NSR signifie « Neural Semantic Retrieval », c’est à dire « récupération sémantique neurale », jargon qui signifierait en gros « récupération d’information sémantique au moyen d’un réseau neuronal » (comme dans les LLMs, les large language models comme chatGPT).

On a par exemple un module nommé : GoogleApi.ContentWarehouse.V1.Model.QualityNsrPQData. Aucune idée de ce que signifient les lettres PQ, mais il serait question de données, par récupération sémantique neurale, et concernant la qualité (de quoi ?)

Bref, je vous explique tout ceci pour vous montrer de quoi il retourne, et la difficulté à interpréter cette masse d’infos obscures : c’est un gros mélange d’éléments évidents et d’éléments incompréhensibles.

Grâce à ces documents, on n’a jamais été aussi proches de la vérité concernant le SEO. Et pourtant, nous sommes condamnés d’office à ne pas tout comprendre, et à faire un travail interprétatif hasardeux.

La simple structure des documents nous laisse imaginer tout ce que nous ne savons pas : dans le dossier GoogleApi, quels sont les autres dossiers ? Dans le dossier V1, quels sont les autres dossiers à part Model ? Si V1 signifie Version 1, combien y a-t-il d’autres versions et quelle est celle utilisée en production ? Mystères.

Les attributs

Chaque module a une liste d’attributs, plus ou moins longue.

En voici un aperçu :

On constate que cette information est structurée comme ceci :

le nom de l’attribut
entre parenthèses, son type (par exemple un nombre entier, une valeur booléenne Vrai ou Faux, une chaîne de caractères, un module, etc) puis sa valeur par défaut, souvent nulle (« nil », abréviation du latin nihil = rien)
puis un tiret, et soit rien, soit un bref commentaire qui décrit le sens ou l’usage de cet attribut

Là encore, beaucoup de termes sont incompréhensibles : par exemple ici, que signifie l’attribut deltaAutopilotScore, qui est un nombre entier, et à quoi sert-il ? Mystère.

D’autres attributs au contraire ont un nom transparent : par exemple author (l’auteur) dans le contexte d’un module à propos d’article de blog, ou price (le prix) dans le contexte d’un module produit.

Il est possible de faire une recherche dans le corpus des documents fuités. On peut donc chercher n’importe quel attribut obscur et voir s’il est utilisé dans d’autres contextes, qui permettraient d’éclairer son sens. On peut donc en partie lever une partie du voile de mystère qui enrobe l’API de Google, éliminer ou confirmer des hypothèses.

Par exemple, une recherche sur le mystérieux attribut chardScoreEncoded montre qu’il est mentionné deux fois dans toute la documentation.

Ce qu’on peut tirer de ces documents

Bref, par cette méthode, en cherchant des thèmes précis, il est possible d’avoir une idée de ce que fait vraiment Google sur un certain nombre de thèmes précis, comme, en vrac : service, produit, auteur, prix, porno, video, image, blog, date, pays, etc etc.

Au minimum, cela permet de vérifier que tel ou tel concept existe bel et bien dans l’algorithme.

Par exemple, Google avait dénié encore et encore utiliser les données de navigation de Google Chrome en tant que facteur de classement, or le module nommé GoogleApi.ContentWarehouse.V1.Model.QualityNavboostCrapsCrapsData, avec ses attributs goodClicks et badClicks, prouve le contraire : Google mesure la durée des visites après un clic sur un de ses résultats.

Ou encore, il y a eu une longue controverse sur le fait que mettre des mots en gras sur une page web puisse être un facteur de référencement : mais c’est confirmé, Google a bien un attribut qui mesure la quantité de texte mis en gras dans une page : si cette mesure existe, elle sert probablement à quelque chose.

Pour conclure : il est donc possible de surfer dans la documentation fuitée pour mieux comprendre comment fonctionne les algorithmes de Google, valider ou invalider des théories SEO, et en tirer des conclusions sur les techniques d’optimisation qui marchent ou qui ne marchent pas.

Avec ce fort bémol : maintenant, Google sait qu’on sait ce qu’il sait. Il y a donc fort à parier qu’il comble le gouffre créé par la fuite, en modifiant ses concepts et ses réglages, et probablement en se dirigeant vers sa profonde mutation, qui le fera passer de moteur de recherche à générateur de réponse par intelligence artificielle…