Leak Google : du lard ou du cochon ?

Ça fait maintenant une semaine que la nouvelle a fait l'effet d'un tremblement de terre dans le monde du SEO : Mic King et Rand Fishkin ont publié plus de 2500 pages tirées de la documentation de l'API interne que Google utilise, notamment pour classer les résultats sur son moteur de recherche.

C'est le "wet dream" de tous les consultants en référencement : avoir les clés pour décrypter le sacro-saint algorithme de Google. Évidemment, la nouvelle a fait grand bruit... J'ai immédiatement décidé de faire une édition spéciale de la newsletter de Soumettre.fr et en écrivant l'édito, je me suis rendu compte que j'avais beaucoup de choses à dire sur le sujet. Les voici :)

Le rêve éveillé

On apprend enfin toute la vérité sur l'algo : il y a bien une métrique d'autorité du domaine, le comportement des utilisateurs est remonté via Chrome, qui sert de mouchard (on en avait déjà eu confirmation quand Google a dû témoigner devant le Department of Justice américain), les liens sont toujours très importants, etc.

Retour à la réalité

Plusieurs points viennent quand même calmer nos ardeurs :

• obsolète : la dernière modification des documents date d'août 2023. Presque un an, sur internet, c'est une éternité, et c'est encore plus vrai depuis que l'IA est venue chambouler notre quotidien.
• sans contexte : la documentation ne présente qu'une liste de critères, on ne connaît pas leur poids dans l'algo final. Certains sont peut-être même ignorés. Pour faire simple, c'est comme si un grand chef vous donnait une liste d'ingrédients : il n'est pas directement possible de réaliser les mêmes plats que lui. Mais ça aide quand même !

C'est sur ces deux points qu'à insisté le géant de Mountain View lors d'une annonce de réaction qui a tardé à paraître ; on sent que la cellule de crise s'est creusé les méninges pour nous sortir les arguments les plus plausibles.

Le code chez Google

Historiquement, Google n'utilise qu'un seul repository pour l'ensemble de ses produits, sauf Chrome et Android qui sont traités à part.

Un repository, c'est un endroit où on stocke du code, qui sera ensuite déployé et exécuté sur des serveurs. On peut, au choix, utiliser des micro-services, où chaque serveur réalise une petite tâche, ou coder en monolithe, où une appli est capable de tout gérer en local, sans l'aide de services externes. C'est ce dernier paradigme que Google a mis en place, en évoluant pour devenir une des plus grosses bases de code de la planète (et de l'univers connu, pour le coup).

Avec des micro-services, il est plus facile de scinder les tâches, puisque chaque équipe est responsable d'un repository, qui doit réaliser une seule tâche. Avec un monolithe, tout le monde peut (théoriquement du moins) tripoter la totalité du code.

Ces quelques chiffres pourront vous donner le tournis. Google, c'est :

• un milliard de fichiers
• 2 milliards de lignes de code
• 35 millions de commits historisés
• 86 téraoctets de code
• 40.000 commits par jour

... Vous voulez pire ? Ces chiffres ont 10 ans. Je n'en ai pas trouvé de plus récents, mais ça donne une idée de l'envergure du repo : c'est colossal. De 2005 à 2015, leur croissance était quasiment exponentielle : ça ne m'étonnerait pas que tout ait fait x10 depuis.

C'est tellement énorme qu'ils ont dû développer tout un process en interne pour gérer ça, appelé Blaze, qui existe aussi en version open-source sous le nom de Bazel - édité par Google.

Les limites du leak

La documentation qui nous concerne aujourd'hui est celle d'une partie de ce repo, d'où la présence de marqueurs qui concernent Youtube ou Google Maps et qui n'ont pas de rapport évident avec le Search.

J'avais vu une interview d'un lead dev de chez Google (que je ne retrouve pas), où il expliquait qu'ils ne se servent même pas de branches, qu'ils commit tous au même endroit : admettons qu'un dev bosse sur une fonction pour retailler des images. Dès que possible, il la documente et la pousse en prod, pour que tous les autres devs de la boîte puissent s'en servir aussi. Il est possible que finalement, personne ne s'en serve. Ce "code dormant" donnera des boutons aux puristes mais chez Google, on estime qu'il ne gêne pas tant que ça, et qu'on pourra l'effacer au bout de X temps s'il est vraiment inutile.

C'est le problème principal qu'on a avec cette documentation : il est fort possible qu'elle concerne des bouts de code qui ne sont plus utilisés mais qui "traînent dans le repo", et/ou que le poids de certains des critères soit passé à zéro, ou même qu'ils aient été codés mais jamais utilisés.