On a lu les chemins, pas les contenus. L'existence d'une URL est déjà du renseignement : ce qu'elle nomme révèle une équipe, un système, une machine.
Aucun mur n'a été franchi. La quasi-totalité de ces adresses répond par une redirection vers un portail d'authentification interne : le contenu reste fermé. Mais le chemin, lui, est public. Et un chemin qui dit superroot/youtube/youtube_controversial_query_blacklist en dit déjà long, même fermé à clé.
On ne lit pas ce que dit la page. On lit son adresse.
Une URL nomme. Avant tout contenu, elle annonce un host, un dossier, un fichier. ranklab.teams.x20web.corp.google.com révèle un banc d'essai de ranking ; badurls_demoteindex révèle qu'on distingue « démoter » de « supprimer ». Le corps de la page peut rester fermé : le nommage a déjà fui.
C'est la limite assumée de la méthode, et sa force. On travaille sur des données publiques avec des techniques OSINT classiques. On ne sait pas ce que contiennent ces pages. On sait qu'elles existent, et comment leurs auteurs les ont nommées.
Ce qu'on n'a PAS fait
Pas d'accès interne, pas de login, pas de contournement, aucun contenu ouvert. La quasi-totalité des adresses répond en redirection 302 vers login.corp. On s'arrête à la porte ; on lit seulement ce qui est écrit dessus.
Le point de départ : la reconstitution du fonctionnement de la recherche après les Google Leaks.
En 2024, à la suite des Google Leaks, nous avions reconstitué le fonctionnement de la recherche Google : les composants, leurs noms de code, l'enchaînement crawl → indexation → scoring → serving. Voici l'infographie que nous avions publiée. Elle sert de grille de lecture pour la section suivante : le lexique.
Lire l'analyse complète : Google Leak, partie 6 : How does Google Search work.
134 termes des Google Leaks, confrontés aux 3,7 M d'URLs et aux chemins de code. Chaque pastille s'ouvre sur sa définition.
Les composants de ranking que nos chemins de 2026 confirment, un par un.
Ascorer, le scoreur IR principal, apparaît en clair dans un flag de debug LIVE : eng-hip-ascorer. Au-dessus, les Twiddlers (189 occurrences dans les URLs) re-classent les résultats sous SuperRoot (474 occurrences). Le pipeline GWS se lit étage par étage via asdebugger : qrewrite → optq → sr_bns → gws_bns.
Deux listes Googlebot cohabitent : badurls_spamindex (tuer) et badurls_demoteindex (démoter). Une youtube_controversial_query_blacklist branchée sur SuperRoot atteste d'une intervention éditoriale par-vertical. Et des hosts comme signalslookup, ranklab.teams.x20web, raterhub (EWOK) ou hc-ai-mode-staging nomment les bancs d'essai du classement.
Expériences, kill-switches, launches : le levier au-dessus du moteur.
Avertissement de méthode
Sur des tokens courts (sge, magi, ewok, sxs…), un simple grep est pollué par du base64 caché dans les jetons upxsrf=. Tous les compteurs ci-dessous sont ancrés sur des noms de hosts, pas sur des sous-chaînes. C'est ce qui les rend défendables. Que Google ait planqué sa plateforme de raters derrière des jetons ressemblant à du bruit fait partie de l'histoire.
Au-dessus du moteur, un étage pilote tout : les expériences A/B et les kill-switches. Mendel est la plateforme maîtresse (produit interne Mendel Insights) ; Finch est son équivalent côté Chrome, où chaque étude est un fichier .gcl rangé par état de cycle de vie (launched/). On y trouve littéralement un KillSwitchExample.gcl. Tout passe par launch.corp.google.com/launch/$1, le tracker central, dont on a récupéré des IDs réels.
En prod, rollouts.corp fait monter les changements par vagues (Progressive Borg Rollout, pbr_view=stages). Et une seule URL de querydebugger.corp.google.com/eval/unified contient une config d'expérience Search entière figée dans un string : binaire GWS gelé, flags nommés, et le marqueur __data_rollout__…__launched__:true, le drapeau exact qui dit « cette expé est lancée en prod ».
Et ce ne sont pas des abstractions : voici des expériences AI Mode bien réelles, nommées et datées, récoltées par un autre canal OSINT, pas dans la liste des 3,7 M d'URLs. Chaque nom trahit une feature en cours : entités actionnables, agent de recherche, transports terrestres.
Des expériences AI Mode bien réelles, captées par ailleurs. On lit leur nom et leur état : ::Launch (lancée), ::Experiment (en test), ::Control (groupe témoin), sans jamais ouvrir la feature.
Un leak censé ne livrer qu'un nom de fichier livre son historique d'édition.
Certaines décisions ne sont pas des algorithmes : ce sont des fichiers édités à la main, posés dans google3/googledata/. Certaines URLs embarquent l'historique d'édition de youtube_controversial_query_blacklist : 42 révisions distinctes, dont les jetons encodent les termes ajoutés (…?cl=…/40mandalay, /40shooter, /40paddock, /40crisis, /40bomber). La liste se peuple pendant la fusillade de Las Vegas (oct. 2017). Le nom de fichier devait tout cacher ; il révèle le contenu.
Dans le même dossier cohabitent deux listes Googlebot, badurls_spamindex (tuer) et badurls_demoteindex (démoter), et un workflow de manual action en clair : spam-policy.prom.corp.google.com/{submit,approve,reject}. L'org-chart anti-spam affleure : webspam.corp, adspam.corp, spamops.corp/QueryAide, fraudbin.corp/fraud/takeNextTicket.
L'angle OSINT
La censure laisse une trace de versions. Chaque révision cl=… est un mot ajouté à la main.
16 000 évaluateurs, leur plateforme et leurs verdicts, par les hosts.
Le lexique nomme EWOK et Needs-Met comme concepts ; voici les hosts qui les servent. raterhub.corp.google.com est la plateforme des Quality Raters (la même qui applique les « Quality Rater Guidelines » publiques). Et eval-analytics.corp.google.com/querygroup?experimentId=…&queryGroupIndex=0 expose la mécanique : un ID d'expérience nommé, découpé en query-groups, l'unité exacte que les raters notent. La flèche est complète : rater → query-group → verdict d'expérience.
Autour gravitent le « golden set » humain (goldendata-geq.googleplex.com, gwstest-gold, un GWS de test côte-à-côte), l'usine d'annotation (merlot-ops-labelstream-ui, crowdcompute.googleplex.com) et les enquêtes de satisfaction (gutssurveys.corp, GUTS = Google User Satisfaction).
Le sujet SEO le plus chaud, leaké par ses hosts de staging.
Un nom de host de pré-production est du renseignement pur : il atteste l'existence du produit, son codename interne et son dogfooding, alors même que le contenu reste fermé. hc-ai-mode-staging.corp.google.com/?entry_point_id=1 nomme « AI Mode », la surface de recherche conversationnelle qui rebat les cartes du SEO. À côté, aistudio-preprod expose un slug de modèle (gemini-2-5-flash-image) et des apps de démo embarquées.
On peut même reconstruire le pipeline de release à partir des seuls suffixes : geminidataanalytics existe en cinq barreaux propres, dev → autopush → staging → preprod → prod. Et bard.corp.google.com/sitemap.xml reste indexé après le rebrand en Gemini : un fossile OSINT. Dans le code, abuse/llm/agents/adi_agent nomme un agent LLM chargé de policer l'abus… des LLM.
Pour les SEA : les leviers du prix plancher, vus de l'intérieur.
Un seul host, adxdashboard.corp.google.com, expose l'arbre de pages de la console opérateur d'Ad Exchange : le prix plancher (/pub/reserve_price_opt_summary.html), l'enchère temps réel (/rtb/rtb_dashboard.html) et le paiement éditeur (/pub-mon-payout.html). Les SEA ne voient que la sortie de cette boucle ; ici, c'est la machine.
La couture entre organique et payant est nommée : SearchAdsViewerRenderingUi est le composant qui peint les annonces sur la SERP ; displayadssearch et unity-adsense-search sont là où l'ad-serving interroge le stack de recherche. Et l'anti-spam a un jumeau publicitaire : adspam.corp, avec un signal verbatim, MobileAppQueryIpClickStats28Days (stats de clics par IP sur 28 jours, détection de fraude).
Toutes en *.printer.in.goog, nommées à la main par les employés.
Chaque imprimante porte un nom choisi par une équipe. Mises bout à bout, 2 377 d'entre elles dessinent une culture interne, et parfois une géographie. On y croise les IA qui veulent détruire l'humanité (hal9000, skynet, glados, ultron, jarvis), les jeux vidéo (mario, zelda, sonic, tetris), James Bond (goldfinger, jaws), la nourriture (sushi, taco, croissant), et une référence à la série The IT Crowd : 01189998819991197253.
L'angle OSINT : les noms géolocalisent
Beaucoup d'imprimantes encodent un emplacement : 24th-floor, 25th-floor, access-sf1, 3cc-reception. En les recoupant, on cartographie étages et bâtiments par les seules imprimantes. On trouve même des caméras nommées sur le même domaine (3ccsecurity-cam).
Au-delà des imprimantes : campus, datacenters, badges, GPS.
Les imprimantes nommaient des étages ; campusmaps va plus loin. 166 URLs campusmaps embarquent une grammaire d'adresse canonique PAYS-VILLE-BÂTIMENT-ÉTAGE-SALLE sur 7 villes (Mountain View, NYC, Tokyo, Zürich, Sydney…), parfois avec latitude/longitude. Le ctype= trahit le type de lieu : CONFERENCE, UX_LAB, MICRO_KITCHEN. Pire : une requête q=type:person+near:email@google.com résout une personne nommée à un siège, étage et coordonnées.
Les hostnames d'imprimantes structurés cartographient la sécurité d'un datacenter : au-syd-erk1a-1-security-truck-entry (l'entrée des camions), …-soc (security operations center), …-security-kiosk. On croise badges (nacho-badgelobby), caméras (3ccsecurity-cam) et le YouTube HQ en bâtiment connecté (building/datacenter/kiosk/nest.corp.youtube.com).
L'angle OSINT
Email d'entreprise → bâtiment, étage et GPS. La carte interne devient un annuaire géolocalisé.
www.corp.google.com/~login : l'annuaire involontaire.
Chaque ingénieur dispose d'un espace personnel sous www.corp.google.com/~login. On y dépose des prototypes, des slides, des notes. Nous avons reconstitué la liste de 917 de ces espaces. Rien n'a été forcé : tout est resté visible, encore fallait-il savoir où regarder. On cite ici la mécanique (917 logins distincts), pas les identités.
Détail parlant : on y trouve ~daepark/public/mustang-suggest/. Une page perso qui nomme Mustang, le système central de ranking. Le contenu reste fermé ; le chemin, lui, situe la personne dans la machine.
Le raccourcisseur d'URL interne, la toolchain et le zoo de codenames.
Les fameux go/ de Google sont des marque-pages internes. Leurs slugs nomment des projets, et certains recoupent directement le lexique de la section 3. Côté ranking/qualité :
Autour, la toolchain légendaire affleure host par host : critique (revue de code), cs / codesearch, cider (l'IDE), buganizer, moma (le Google interne). Et la culture codename : 757 hosts mono-mot (bahamut, valkyrie, aristocat…), plus la cerise : memegen.corp.google.com, un générateur de memes en infra corp officielle.
Recoupement avec le lexique
Plusieurs slugs go/ confirment des termes du lexique : udr, iql, superroot, ymyl. Le marque-page d'un ingénieur vaut preuve d'existence du projet.
L'arborescence du monorepo, devinée dossier par dossier.
Les chemins de code archivés dessinent l'arborescence de google3. Les dossiers de tête observés : third_party (213), googledata (149), file/colossus (89), quality (26). Sous ces racines, les noms trahissent les équipes.
learning/multipod/pax pointe vers Pax, le framework JAX derrière Gemini ; abuse/llm/agents/adi_agent nomme un agent LLM d'anti-abus. Le levier qui pilote tout le reste affleure aussi : Mendel et Finch (A/B tests et kill-switches), via experiments.corp.google.com.
Les 3 736 742 URLs internes, en clair, dans un seul fichier. Seuls les chemins sont exposés, les contenus restent derrière login.corp. On les met à disposition de la communauté SEO/OSINT.
Télécharger le .zip (79 Mo)3 736 742 lignes · ~622 Mo une fois décompressé
