Du leak de 2024 à Geostore, nous avons reconstruit la manière dont Google consolide un lieu, mesure son importance, comprend une requête, sélectionne les résultats, les affiche sur la carte et commence désormais à les personnaliser avec l'IA.
En 2024, une fuite de documentation interne avait ouvert une fenêtre sur les systèmes de Google. Pendant deux ans, c'était la meilleure source disponible pour comprendre ce qui se cachait derrière Google Maps.
Depuis, nous avons mis la main sur un binaire récent embarquant un scope Geostore non public, puis recoupé ce matériau avec les protocoles de Google Maps, ses échanges réseau, ses index Web, ses services annexes, ses tables de styles et plusieurs composants exécutés localement.
Le résultat change sensiblement l'image que l'on pouvait avoir de Maps. Nous disposons maintenant de noms de messages, de numéros de champs, d'énumérations complètes, de centaines de méthodes d'API, de signaux de ranking, de structures d'indexation et de mesures réalisées directement sur le moteur.
Et le calendrier est intéressant. Le 6 août 2026, Google annonçait une vague de fonctions IA dans Maps. Nous avions le code de la veille et celui du lendemain.
Google Maps n'est plus seulement une carte et un moteur local. Il devient aussi un moteur de réponses. Pour comprendre ce que cette évolution signifie, il faut d'abord comprendre la machine qui se trouve dessous.
1. Google Maps ne repose pas sur une base de fiches.
Au centre se trouve Geostore, un référentiel bien plus général qui modélise des entités géographiques canoniques appelées Feature.
2. Une Feature mélange des informations de sources différentes. La provenance peut être conservée au niveau du champ. Le nom, le téléphone, une catégorie ou une géométrie peuvent avoir des origines différentes.
3. Lorsqu'elles se contredisent, les sources sont arbitrées. Geostore expose un système de conflation, de priorité, de confiance, de droits, et même de critères qu'une future modification devra satisfaire pour remplacer une valeur existante.
4. Geostore possède son propre système de ranking, et il porte un nom. Oyster Rank. Nous avons retrouvé l'énumération complète visible de 72 signaux, dont 25 explicitement dépréciés. Les signaux présents incluent les avis, le volume de requêtes Web, les impressions de fiche, les ouvertures de fiche, les demandes d'itinéraire, les clics vers le site, l'appartenance à une chaîne, la popularité, la proéminence et l'usage de la voirie.
5. Nous avons les noms des signaux, pas leurs coefficients.
Le schéma indique qu'ils sont combinés avec des poids, mais les quinze champs les plus intéressants de RankDetailsProto sont retirés du scope que nous avons pu récupérer.
6. Ce rang n'est pas le classement final d'une requête Maps. Search/Places ajoute ensuite compréhension sémantique, contexte géographique, génération de candidats, pertinence et serving.
7. Le Web et Maps sont bien plus liés qu'il n'y paraît. Les documents Web sont attachés aux entités via leur MID, avec topicalité, confiance et métadonnées géographiques stockées dans l'index. Une couche, Webref, décide document par document de quelle entité parle une page.
8. Le moteur n'est pas un tri par distance.
Dans les zones denses, nous observons un objectif de 20 résultats et un rayon qui s'adapte à la requête. À Paris, 0,98 km suffisent pour pharmacie, contre 12,44 km pour Carrefour. La même requête pharmacie vaut 32,96 km en Lozère.
9. Une partie de l'intelligence géographique est calculée sur le téléphone.
Une couche embarquée infère les lieux fréquents, le domicile, le travail, les trajets et une ChainAffinity, c'est-à-dire une affinité envers une enseigne. Attention au niveau de preuve : l'étage segmenteur est nommé, l'étage persona ne l'est pas.
10. L'annonce IA du 6 août 2026 est surtout un allumage serveur. Sur les six volets annoncés, cinq n'ont aucune contrepartie de code nouvelle. Le seul code réellement neuf est le service de consentement, parce que c'est la seule brique qu'on ne peut pas allumer à distance.
Trois niveaux de preuve, tenus du début à la fin. C'est la grille de lecture de toute l'étude.
Un nom de champ, un numéro, une énumération ou un commentaire établit que le système prévoit cette information.
Si SIGNAL_GOOGLE_REVIEWS existe dans l'énumération de ranking, nous pouvons affirmer que les avis appartiennent au vocabulaire de ranking de Geostore. Nous ne pouvons pas en déduire leur poids actuel dans une recherche.
Nous avons interrogé les services, capturé des réponses, comparé des classements, fait varier la localisation et le zoom, décodé des tuiles et mesuré les résultats.
C'est à ce niveau que nous pouvons affirmer que le moteur renvoie 20 résultats dans certaines conditions, ou que la priorité transmise dans la tuile reprend exactement l'ordre des résultats.
Lorsqu'une donnée manque, nous le signalons. C'est particulièrement important pour les poids du ranking.
Le but de cette étude n'est pas de transformer des noms internes en mythologie SEO. C'est de séparer ce que les données démontrent de ce qu'elles ne permettent pas de savoir.
Messages, champs, énumérations complètes, tags retirés du scope client et prose de mars 2024 en regard. Un moteur de recherche pour creuser les types, les attributs et les signaux, et un dump complet pour ceux qui préfèrent leurs propres outils.
La documentation récupérée en 2024 avait une qualité rare : elle expliquait le rôle de milliers de modèles et d'attributs, en prose.
Mais elle avait une faiblesse.
Les énumérations y étaient largement abstraites. Nous pouvions comprendre les concepts, beaucoup moins facilement reconstruire leurs valeurs réelles.
Le binaire récent change cela.
1 623 descripteurs protobuf 4 013 messages 1 359 énumérations 17 757 valeurs d'énumération 433 types Geostore (300 messages + 133 enums)
Parmi les grandes énumérations retrouvées :
RankSignalProto.Signal 72 RankDetailsProto.SignalMixerType 35 FeatureProto.TypeCategory 371 EstablishmentProto.TypeCategory 374 DataSourceProvider.Provider 793 SuggestSubtype 852 dans la version mesurée localsearch.lite.IntentType 446
La comparaison avec 2024 est plus instructive encore.
Sur 3 585 valeurs d'énumération comparées, 3 471 n'étaient pas retrouvables dans l'archive 2024, dont 70 des 72 signaux de ranking. Aucun modèle Geostore documenté en 2024 n'a en revanche disparu du corpus récent.
Ce n'est donc pas une nouvelle architecture remplaçant celle de 2024.
C'est plutôt comme si nous avions obtenu les plans électriques d'un bâtiment dont nous connaissions déjà les pièces.
Un modèle mental utile de Google Maps commence par une distinction.
Geostore n'est pas Google Maps.
Geostore est la couche qui maintient l'identité et l'état canonique d'une entité géographique. Search et Places viennent ensuite.
Une Feature Geostore peut être :
un établissement une ville un pays une route une intersection un bâtiment une zone une station un élément de transport un objet 3D … et beaucoup d'autres types d'entités spatiales
Le POI que nous voyons dans Google Maps n'est donc qu'une projection de cet objet beaucoup plus riche.
message geostore.FeatureProto {
id = 1;
bound = 2;
rank = 3;
name[] = 4;
address[] = 5;
point[] = 6;
polyline[] = 7;
polygon[] = 8;
child[] = 9;
center = 10;
source_info[] = 12;
related_feature[] = 13;
parent[] = 14;
type = 15;
synthetic_geometry = 16;
access_point[] = 17;
geometry_precision_meters = 20;
rank_details = 24;
covering = 26;
data_source = 33;
establishment = 51;
status = 67;
website[] = 69;
raw_gconcept_instance_container = 70;
internal = 71;
social_reference = 74;
knowledge_graph_reference = 75;
kg_property[] = 79;
business_chain = 91;
operations = 103;
experimental_data[] = 118;
feature_originators[] = 123;
existence_confirmations[] = 126;
metadata = 300;
}
Le champ 70 mérite son nom complet : raw_gconcept_instance_container. Ce n'est pas une liste de catégories, c'est un conteneur d'instances de concepts. La nuance porte tout ce qui suit sur les catégories.
L'identifiant fondamental de Geostore est composé de deux valeurs de 64 bits :
FeatureId ├── cell_id 64 bits └── fprint 64 bits
Le cell_id correspond approximativement à la position de la Feature lors de sa création.
Ce détail est important.
Il ne doit pas être interprété comme la position actuelle du commerce. La géométrie réelle se trouve ailleurs dans la Feature.
Et il ne s'agit pas d'une alternative à deux branches. Le schéma en décrit trois états :
1. cellule exacte position de création
2. cellule randomisée entités sans lieu propre
3. champ absent "As of Mar 2017, the cell ID
field of the feature ID
might not be set"
Cette séparation permet à une entité de déménager, d'être corrigée ou de changer de géométrie sans perdre son identité.
Elle permet aussi de comprendre les différents identifiants que l'on rencontre autour de Maps.
| Identifiant | Ce qu'il représente |
|---|---|
Feature ID / ftid | l'identité Geostore |
Place ID | sérialisation de cette identité |
CID | le fprint de la Feature |
MID | l'identité d'entité dans le Knowledge Graph |
gcid | une classification sémantique |
| identifiant de listing marchand | la fiche administrée par le commerçant |
Ce couple de 64 bits est exactement ce que l'on manipule sans le savoir dans les outils publics. Un ftid de la forme 0x47e66e2964e34e2d:0x8ddca9ee380ef7e0 affiche le cell_id puis le fprint en hexadécimal ; le CID est ce même fprint en décimal ; et un Place ID commençant par ChIJ en est la forme sérialisée puis encodée. Trois écritures, une seule identité Geostore.
La distinction est fondamentale pour le SEO local. Le commerce, la fiche administrée par le commerçant, son type sémantique et l'entité Knowledge Graph ne sont pas le même objet.
Geostore est le nom que lui donne Google : c'est celui qui préfixe chaque type du schéma, geostore.FeatureProto. Ce référentiel porte, dans la documentation, un second nom : Oyster.
On le retrouve sur l'identifiant, sur le type d'entité côté index, et surtout sur le système de ranking lui-même.
// sur l'identifiant the oyster feature id // sur le type d'entité, côté index Web RepositoryWebrefOysterType.featureType "a value of the enum geostore.FeatureProto.TypeCategory" // sur le système de ranking RankSignalProto.rank "A value in the range [0, 1] estimating Oyster Rank according to this signal."
Le système dont nous détaillons plus loin les 72 signaux, Oyster Rank, a donc un nom, et ce n'est pas PlaceRank.
Une intuition fréquente consiste à penser qu'une fiche appartient à une source.
source = Google Business Profile
Ce n'est pas le modèle que décrit Geostore.
La provenance peut être attachée au niveau du champ.
Nom ---------------------- Source A Téléphone ---------------- Source B Horaires ----------------- Source C Catégorie ---------------- Source D Géométrie ---------------- Source E
Geostore peut conserver, pour un chemin de champ :
field_path provider dataset
Le catalogue découvert contient 793 fournisseurs. Il inclut des sources cartographiques, des pipelines automatiques Google et l'édition humaine interne.
Une correction humaine apparaît donc dans la même philosophie générale : une observation issue d'une source possédant une priorité et un niveau de confiance, plutôt qu'une vérité magique située en dehors du système.
C'est l'une des découvertes les plus utiles pour comprendre Maps.
Le schéma expose trois méthodes génériques :
CONFLATION_PICK_FIRST_VALUE CONFLATION_UNION_CSV CONFLATION_SUM
Et la valeur par défaut est :
CONFLATION_PICK_FIRST_VALUEAutrement dit, dans ce mécanisme générique, lorsque plusieurs valeurs concurrentes existent, le système ne fait pas nécessairement voter les sources.
Il peut simplement prendre la première valeur admissible selon l'ordre de priorité.
Cela fait de la priorité des sources une donnée essentielle.
Ce mécanisme ne prouve pas que tous les attributs de Google Maps sont consolidés de cette manière. Il prouve que Geostore dispose explicitement de cette mécanique de fusion.
Modifier une donnée dans Google Business Profile ne signifie pas nécessairement :
ancienne valeur
↓
nouvelle valeur définitiveLe modèle ressemble davantage à :
nouvelle observation
+
observations déjà connues
+
provenance
+
priorité
+
confiance
↓
valeur canoniqueC'est une différence de nature, pas de degré.
Le niveau de confiance visible dans le schéma possède six paliers :
UNKNOWN 0 BLOCKED 16 NOT_TRUSTED 32 YP_FEEDS 40 TRUSTED 48 SUPER_TRUSTED 64
YP_FEEDS désigne les flux d'annuaires professionnels, les yellow pages : les données achetées ou reprises aux pages jaunes et à leurs équivalents. Elles valent mieux qu'une source inconnue, moins qu'une source jugée fiable.Mais le plus intéressant n'est pas cette liste.
Pour une Feature en sortie, la structure de confiance peut aussi définir les critères qu'une nouvelle édition devra satisfaire pour être acceptée.
Un attribut peut donc conceptuellement avoir trois caractéristiques différentes :
D'où vient-il ? PROVENANCE À quel point cette source est-elle fiable ? TRUST À quel niveau doit se situer une future modification pour la remplacer ? EDIT BARRIER
Cette troisième dimension explique pourquoi certaines erreurs cartographiques sont difficiles à corriger, même en s'y prenant correctement.
Nous n'avons pas récupéré la formule. TrustSignalsProto contient quatre emplacements retirés du scope.
Google sépare plusieurs niveaux.
La Feature appartient à l'une des 371 catégories structurelles.
Une seconde taxonomie possède 374 valeurs. Mais sa propre documentation indique qu'elle est dépréciée au profit des GConcepts.
C'est la couche ontologique.
Le gconcept_id du schéma est le gcid: que transportent les réponses du moteur. Et ce n'est pas une donnée cachée : c'est la catégorie que vous lisez sous le nom de l'établissement dans Google Maps. Quand la fiche du Louvre affiche « Musée d'art », c'est gcid:art_museum. Quand un restaurant affiche « Restaurant de ramen », c'est gcid:ramen_restaurant.
Les attributs suivent la même convention : AttributeIdProto.id est décrit comme « a stripped format of the gcid », tandis qu'une valeur d'attribut énumérée est elle-même un gcid, du type gcid:attval_yes.
Les catégories, les attributs et leurs valeurs vivent dans le même espace de noms.
Un concept peut porter une prominence :
NON_PRIMARY = 0 PRIMARY = 1000
La documentation donne l'exemple :
« une station-service avec supérette et distributeur. Les trois GConcepts sont très pertinents, mais gas_station est le plus proéminent. »
Le trafic confirme la lecture. La liste de gcid servie place la catégorie principale en tête, puis les 8 à 16 secondaires strictement triées par ordre alphabétique, sur 6 entités sur 6.
Le tri alphabétique est la preuve qu'aucun ordre sémantique n'est transporté. La fiche du Louvre porte 16 valeurs : la première est celle qui s'affiche, les quinze suivantes sont rangées de art à vacances.
gcid:art_museum ← affiché gcid:art gcid:attraction gcid:culture gcid:education_and_culture gcid:entertainment_and_recreation gcid:establishment gcid:establishment_poi gcid:feature gcid:museum gcid:places_of_interest gcid:public_api_establishment gcid:tourism gcid:tourist_attraction gcid:travel gcid:vacances
museum n'est pas derrière feature parce qu'il décrirait moins bien le lieu : il est derrière parce que m vient après f.Il faut en tirer la limite tout de suite : il n'existe aucune gradation entre catégories secondaires. Seul le basculement PRIMARY est un fait porté par le schéma.
Dernier point, souvent contre-intuitif : le gcid est une donnée de la réponse de recherche, pas de la fiche. Il est absent de cinq réponses GetPlace sur sept, qui transportent l'ontologie /geo/type/… à la place.
C'est le fait le plus actionnable de cette section. Le basculement PRIMARY n'est pas homogène à l'intérieur d'une chaîne.
Sur 21 magasins d'une même enseigne dans une même métropole, appariés un à un :
11 gcid:pharmacy 10 gcid:drugstore
À rapprocher de BusinessChainProto.canonical_gconcepts, qui déclare « l'état idéal des GConcepts des membres de cette chaîne », avec la règle isRequired : « must be true for a primary gconcept ».
L'état idéal est déclaré. L'état réel diverge à l'intérieur de la même enseigne, dans la même ville.
Nous suivrons le même exemple, la chaîne ramen, d'un bout à l'autre de cette étude. Première étape, la classification.
La requête rend 20 résultats, et chacun porte un seul gcid :
ramen_restaurant 6 asian_restaurant 5 restaurant 4 japanese_restaurant 4 japanese_authentic_restaurant 1
Vingt établissements que le même mot fait remonter, répartis sur cinq concepts différents.
C'est l'un des résultats les plus structurants pour le SEO.
Le pont entre Geostore et l'écosystème d'entités de Google Search n'est pas le Place ID.
C'est le MID du Knowledge Graph.
Une Feature contient :
knowledge_graph_reference
↓
MIDCôté index Web, les documents transportent eux-mêmes des encodedMid[].
L'Oyster ID géographique circule autour de cette entité, mais le pivot conceptuel est le MID. Son statut demande de la précision, et le corpus pose lui-même la nuance : sur CountryLocationInfo, l'oyster_id est un payload « cleared during index creation » ; sur WebrefMustangAttachment, il est bien stocké. Selon le message, le même identifiant est transporté ou conservé. Une phrase unique sur son sort serait fausse dans un cas sur deux.
MID
│
┌─────────┴─────────┐
│ │
KNOWLEDGE GRAPH INDEX WEB
│ │
│ documents liés à l'entité
│ topicalité
│ confiance
│ scores documentaires
│
└──────── GEOSTORE
│
FeatureEn sens inverse, Geostore ne stocke pas les identifiants de chaque page Web. Il récupère des signaux agrégés :
SIGNAL_WEBSCORE SIGNAL_GOOGLE_WEB_QUERYVOL
C'est une architecture asymétrique.
Le Web sait parler des entités. Geostore sait combien le Web semble parler d'elles, sans devenir lui-même un index de pages.
Une fiche d'établissement ne porte pas un MID, elle en porte une famille : un par plat de menu, un par sujet d'avis, un par attribut, plus la marque, la classe et les types de repas.
Sur un corpus de captures couvrant cinq requêtes et une fiche complète, nous relevons 221 MID distincts.
Le même type d'identifiant revient à plusieurs endroits de la fiche, dans des rôles différents.
Ce sont ces rôles qui rendent la fiche lisible par une machine : un plat de menu n'est pas une ligne de texte, c'est une entité ; un sujet d'avis non plus.
Sur une fiche de restaurant, ramen n'existe pas comme chaîne de caractères. Il existe comme entité, et il apparaît à trois endroits dans trois rôles différents.
Un avis qui dit « le ramen était trop salé » n'est pas stocké comme une phrase. Il est stocké avec le sujet identifié et les positions de caractères où il en est question.
C'est ce qui permet à un système de compter les mentions, de leur attacher un sentiment, et de citer l'extrait exact. Sans identification, il faudrait relire le texte à chaque question.
La frontière entre le monde documentaire et le monde géographique n'est pas une métaphore. Elle a un nom, et on peut la compter.
Dans le leak de 2024, sur 14 025 attributs de documentation, 25 commentaires citent un type ou un chemin geostore, dont 8 ponts venus de l'extérieur. Cinq des huit sont dans RepositoryWebref*.
Et ce qui traverse le plus n'est pas l'identifiant, c'est le type d'entité : FeatureProto.TypeCategory franchit la frontière trois fois, par trois modèles indépendants.
RepositoryWebrefDomainSpecificRepresentation.entityData déclare pouvoir contenir :
freebase.Topic repository_wikipedia.WikiJoin ocean.WorkMetadata* geostore.Feature
ocean est le corpus Google des publications : livres numérisés, articles académiques et scientifiques. Une même entité peut donc être décrite par un topic Freebase, une page Wikipédia, une publication et un lieu.Webref est la couche où les représentations d'une même entité, venues de sources différentes, se rejoignent.
encodedMid[] "sorted by topicality score" topicalityE2 virgule fixe /100 confidenceE2 virgule fixe /100 oysterId featureType latE7 / lngE7 "same format as geostore.PointProto"
C'est le point que le SEO doit retenir. Webref ne se contente pas de dire de quelle entité parle un document. Il range aussi les documents entre eux, pour une entité donnée.
RepositoryWebrefDetailedEntityScores.docScore "relative ranking signal between different documents for an entity" normalizedTopicality part du document qui parle de l'entité, somme 1 sur toutes les entités connectedness relevanceScore isAuthor isPublisher isReferencePage
RepositoryWebrefMention.confidenceScore publie sa propre calibration. Elle vaut d'être lue attentivement, parce qu'elle éclaire toutes les confiances du corpus.
0,3 → 75 % 0,5 → 87 % 0,7 → 89 % 0,9 → 94 % 1,0 → 98 %
Le Knowledge Graph n'est pas alimenté par les fiches.
Webref est la couche qui décide, document par document, de quelle entité parle une page, à quel point, et avec quelle confiance, puis range ces documents entre eux pour cette entité.
Une page magasin ne se bat pas seulement pour un mot clé. Elle se bat pour être un document de référence de l'entité.
Le système a un nom, une énumération complète, et une frontière nette là où s'arrête ce que nous savons.
Une Feature peut transporter des détails de ranking.
Le pipeline documenté ressemble à ceci :
OBSERVATION BRUTE
│
▼
SignalExtractor
│
├── raw_scalar
└── raw_string
│
▼
NORMALISATION [0,1]
│
▼
RankSignalProto.rank
│
▼
SignalMixer
│
▼
FeatureProto.rankChaque signal peut donc porter :
type rank "A value in the range [0, 1] estimating Oyster Rank according to this signal." raw_scalar raw_string metadata
La documentation indique ensuite que le ranking est produit par une somme pondérée de plusieurs signaux.
Nous avons retrouvé 72 valeurs dans RankSignalProto.Signal. L'énumération n'a aucun reserved_range : elle est complète pour le scope que nous possédons.
Vingt-cinq de ces 72 valeurs sont explicitement dépréciées. Une valeur dépréciée n'est pas un facteur de ranking actuel : c'est la trace d'un facteur qui a existé.
Le bloc le plus parlant se situe dans la famille 3100 à 3504.
SIGNAL_WIKIPEDIA_ARTICLES SIGNAL_KML_PLACEMARKS SIGNAL_KML_SOURCES SIGNAL_GOOGLE_MAPSHOP_USERS SIGNAL_GOOGLE_RBL_CLICKS SIGNAL_GOOGLE_RBL_CLICK_FRACTION SIGNAL_GOOGLE_AUTHORITYPAGE_PAGERANK_CONFIDENCE SIGNAL_GOOGLE_REVIEWS SIGNAL_GOOGLE_WEB_QUERYVOL SIGNAL_GOOGLE_LISTING_IMPRESSIONS SIGNAL_GOOGLE_INFOWINDOW_VIEWS SIGNAL_GOOGLE_DIRECTION_REQUESTS SIGNAL_GOOGLE_HOMEPAGE_CLICKS SIGNAL_GOOGLE_CHAIN_STORES SIGNAL_GOOGLE_LEANBACK_TOURS SIGNAL_GOOGLE_LOCALSEARCH_PLACERANK SIGNAL_WIKIPEDIA_WIKI_SCORE SIGNAL_PLACE_INSIGHTS_LANDMARK SIGNAL_PLACE_INSIGHTS_POPULARITY SIGNAL_PLACE_INSIGHTS_PROMINENCE SIGNAL_PLACE_INSIGHTS_APPROACHABILITY SIGNAL_PLACE_INSIGHTS_TOTAL_ROAD_SEGMENT_USAGE
Et quelques survivants historiques sont explicitement dépréciés :
SIGNAL_GOOGLE_MAPS_NAVBOOST_CLICKS [DEPRECATED] SIGNAL_GOOGLE_MAPS_NAVBOOST_CLICKTHROUGH_RATE [DEPRECATED] SIGNAL_GOOGLE_AUTHORITYPAGE_PAGERANK [DEPRECATED] SIGNAL_GOOGLE_WEBPAGE_REFERENCE_DOMAINS [DEPRECATED]
Elle fait apparaître plusieurs familles d'importance :
PRÉSENCE ET AUTORITÉ SUR LE WEB
WebScore, Wikipedia, références externes,
confiance de page d'autorité
+
DEMANDE
volume de requêtes Web sur l'entité
+
ENGAGEMENT AVEC LA FICHE
impressions, ouvertures de fiche, avis
+
ACTIONS
demandes d'itinéraire, clics vers le site
+
STRUCTURE COMMERCIALE
appartenance à une chaîne
+
ENVIRONNEMENT PHYSIQUE
voirie, accessibilité, usage des segments routiers
+
IMPORTANCE DU LIEU
popularité, proéminence, caractère de landmarkL'importance d'un lieu chez Google est un objet hybride, à la fois Web, cartographique, comportemental et physique.
Mais il faut immédiatement ajouter une précaution. Nous savons que ces éléments appartiennent au vocabulaire du rang Geostore. Nous ne connaissons pas leur poids actuel dans le ranking final d'une requête Maps.
Google les représente par deux signaux différents :
3501 PLACE_INSIGHTS_POPULARITY 3502 PLACE_INSIGHTS_PROMINENCE
Un lieu peut être très fréquenté sans être un repère important. Inversement, un monument peut posséder une forte proéminence sans que cette notion soit identique à son volume de fréquentation.
Trois autres signaux complètent cette famille :
LANDMARK APPROACHABILITY TOTAL_ROAD_SEGMENT_USAGE
APPROACHABILITY, littéralement la facilité d'accès d'un lieu — la manière dont on l'atteint, dont on s'en approche — pose une question ouverte. Le nom est explicite, nous n'avons pas sa formule.
TOTAL_ROAD_SEGMENT_USAGE montre quelque chose de très concret : l'environnement routier associé à un lieu peut entrer dans son vocabulaire de ranking.
Le ranking d'une entité ne regarde donc pas seulement ce qui se passe sur sa fiche ou sur le Web. Il peut aussi regarder le monde physique autour d'elle.
Nous avons trouvé une autre pièce du puzzle, cette fois dans une couche embarquée du système.
Plusieurs pipelines portent des noms explicites :
deidentified-store-visits deidentified-historical-busyness deidentified-wifi-place-visits deidentified-cycling-activity
Ils correspondent à des agrégations de visites en magasin, d'affluence historique, de visites détectées via Wi-Fi et d'activité cycliste. La cadence de remontée par défaut visible dans la configuration est de 6 heures.
Un dossier pulptraining montre également que cette couche participe au réentraînement de modèles.
Il faut être précis sur ce que cela prouve. Nous observons :
détection sur l'appareil
↓
agrégation
↓
remontée dés-identifiéeEt, ailleurs :
SIGNAL_PLACE_INSIGHTS_POPULARITY
Nous n'avons pas la formule qui relie les deux. La filière de mesure existe. La causalité exacte vers le signal de ranking n'est pas démontrée.
Autre piège de vocabulaire.
MIXER_PLACERANK apparaît dans une énumération de 35 mixers. Un mixer est le régime utilisé pour combiner les signaux selon la nature de l'entité.
Pour les lieux :
MIXER_PLACERANK = 18Deux détails de cette liste méritent d'être notés, parce qu'ils disent quelque chose de la manière dont l'énumération a vécu. Elle contient un MIXER_MANAGER à 10000 et cinq MIXER_TEST_1..5 juste après. Et les valeurs 25 et 26 sont absentes sans être réservées : deux mixers ont existé, ont disparu, et n'ont pas laissé de trou déclaré.
Conceptuellement :
Avis ──────────────────────┐
Volume de requêtes Web ────┤
Itinéraires ───────────────┤
Clics vers le site ────────┤
Popularité ────────────────┤
Proéminence ───────────────┤
Approachability ───────────┤
Usage de la voirie ────────┤
WebScore ──────────────────┤
… │
▼
MIXER_PLACERANK
│
▼
importance du lieuPlaceRank n'est donc pas « le facteur PlaceRank ». C'est un mode de combinaison de facteurs.
C'est la frontière la plus importante de cette étude.
RankDetailsProto expose :
signal[] signal_mixer_type
Mais 15 autres tags ont été retirés du scope. La documentation du champ parent indique précisément que cette structure contient les signaux et leurs poids.
RankDetailsProto 15 champs retirés FeatureProto 25 champs retirés TrustSignalsProto 4 champs retirés
Nous ne connaissons pas :
les coefficients les fonctions de normalisation les seuils les transformations les calibrations par marché les interactions entre signaux les versions de modèle
Google développe dans un dépôt unique, google3, qui contient le code de presque tous ses produits à l'exception de Chrome et Android. Search, YouTube, Maps, Assistant et Lens y cohabitent, et la quasi-totalité des ingénieurs y ont accès. C'est un choix inhabituel à cette échelle, et il a ses raisons : collaboration entre équipes, uniformité des outils, refactorisations massives possibles.
Une petite fraction du code, de l'ordre de 0,1 %, échappe à cet accès général. Elle est isolée pour des raisons de confidentialité, principalement autour de l'anti-spam, et porte le nom de HIP, pour High-value Intellectual Property. C'est là qu'on s'attendait, en 2024, à trouver des composants comme NSR ou PageRankNS.
Ce que nous observons ici est de la même famille, un cran plus bas : les descripteurs compilés pour un client ne contiennent que les champs de son périmètre, et ceux qui en sortent laissent une trace, un numéro de tag réservé.
L'hypothèse, que nous ne pouvons pas démontrer : les signaux comportementaux les plus sensibles, ceux dont l'existence même a fait débat après 2024, sont probablement du côté fermé de cette frontière. Le schéma laisse d'ailleurs un indice indirect, puisque les deux signaux Navboost du vocabulaire géographique sont présents mais dépréciés : ce qui est encore actif dans ce domaine ne s'appelle plus comme ça, et a été protégé.
Nous formulons cela comme une hypothèse, pas comme un résultat. Ce qui est mesuré, c'est l'emplacement du trou et sa taille.
Notre analyse du leak de 2024 est ici.
Geostore calcule ou transporte une notion d'importance d'entité. Mais une recherche Google Maps pose une autre question :
« Parmi toutes ces entités, lesquelles répondent le mieux à cette requête, depuis cet endroit, maintenant ? »
Un modèle plus réaliste est :
GEOSTORE
│
entité + attributs + importance
│
▼
COMPRÉHENSION REQUÊTE
│
▼
MATCHING SÉMANTIQUE
│
▼
GÉNÉRATION CANDIDATS
│
┌───────┴────────┐
│ │
importance proximité
qualité géographie
│ │
└───────┬────────┘
▼
RERANKING
│
▼
TOP 20C'est l'une des séparations essentielles de toute l'étude.
Geostore explique très bien ce qu'est un lieu et quels signaux peuvent caractériser son importance. Il n'explique pas à lui seul pourquoi ce lieu est numéro 3 pour une requête donnée.
Les réponses du moteur exposent une classification sémantique de la requête.
Exemple observé pour une marque de restauration :
fast_food_restaurant 0.913505 restaurant 0.676 hamburger 0.568 breakfast 0.509 coffee_shop 0.367 sandwich 0.348 american 0.287 + entité Knowledge Graph scorée
Une hiérarchie géographique scorée accompagne aussi la requête :
quartier ville comté état pays
Nos tests multilingues montrent que des termes synonymes dans différentes langues récupèrent des ensembles d'entités communs. Ce qui se passe en face est plus net encore.
Des termes de sens différent ne récupèrent pas « pratiquement aucune » entité commune. Ils en récupèrent exactement zéro :
Jaccard moyen 0,0000 paires comparées 5 193 paires à recouvrement non nul 0 %
La récupération n'est donc pas purement lexicale. Le terme est d'abord résolu vers une représentation conceptuelle, puis cette représentation oriente l'accès aux candidats.
Pour le SEO local, la conséquence est directe. Il ne suffit pas d'avoir le mot recherché quelque part. Il faut que Google puisse relier l'établissement aux concepts correspondant à l'intention.
Reprenons la distribution de concepts vue plus haut. Vingt résultats pour ramen, et un seul gcid par établissement.
| Concept porté par le résultat | Résultats | |
|---|---|---|
ramen_restaurant |
6 | |
asian_restaurant |
5 | |
restaurant |
4 | |
japanese_restaurant |
4 | |
japanese_authentic_restaurant |
1 | |
| Total | 20 |
Aucun de ces établissements ne porte les cinq concepts. Le moteur n'a pas élargi la catégorie de chacun : il a rassemblé cinq catégories différentes autour d'une intention.
Et la plus fréquente ne représente que six résultats sur vingt. Le concept qui porte exactement le mot tapé est minoritaire dans sa propre réponse.
C'est la raison pour laquelle « ajouter le mot ramen sur la fiche » et « être compris comme un ramen_restaurant » sont deux problèmes distincts.
Dans les zones suffisamment peuplées, nous observons 20 résultats. Le moteur adapte ensuite l'emprise nécessaire pour les obtenir.
À Paris :
pharmacie0,98 kmboulangerie1,15 kmsupermarché5,66 kmTotal7,24 kmCarrefour12,44 kmMême point d'interrogation, même ville. Facteur 12,7 entre deux requêtes.
Pour pharmacie, la distance joue très fortement. Pour une marque ou une catégorie plus ambiguë, la pertinence peut pousser le moteur beaucoup plus loin alors que des centaines d'établissements existent plus près.
Le chiffre le plus parlant n'est pas dans le tableau. Il apparaît quand on sort de Paris avec la même requête.
pharmacie Paris 0,98 km pharmacie Lozère 32,96 km
Le rapport des rayons est proche de la racine du rapport des densités. C'est la signature d'une recherche à nombre de voisins constant : le moteur ne cherche pas dans un cercle, il cherche jusqu'à avoir rempli ses vingt places.
C'est pourquoi la question :
« Quel est le rayon de Google Maps ? »
n'a pas une bonne réponse unique. Le rayon est en partie le résultat du processus, pas un paramètre fixe posé avant la recherche.
Une surface de recherche ouverte que nous avons instrumentée possède une propriété intéressante. En omettant la pondération géographique, elle expose un état impossible à obtenir avec l'API Places classique.
Nous avons réalisé :
5 083 appels 86 584 résultats
Lorsque deux listes partagent les mêmes entités, leur ordre ne bouge pratiquement pas :
Spearman médian +1,000 Spearman moyen +0,984
Changer le point d'origine de plusieurs milliers de kilomètres ne modifie quasiment plus cet ordre.
Il ne correspond ni :
au cell_id au CID à l'ordre lexical de l'identifiant à une distance vers un point géographique caché
Cela révèle l'existence d'un ordre non géographique très stable derrière la récupération.
ordre observé = FeatureProto.rank ordre observé = MIXER_PLACERANK
Nous n'avons pas ce lien. Il pourrait s'agir d'un prior de qualité, d'un ordre documentaire interne ou d'un mécanisme voisin.
Le phénomène est mesuré. Sa nature exacte reste opaque.
Le même appel que celui de la section précédente, avec et sans pondération géographique.
La surface utilisée ici est expérimentale et non documentée. Elle ne doit pas être confondue avec l'API commerciale Google Places.
Le paramètre géographique que nous utilisons ne définit pas simplement un rayon maximal. Lorsqu'une pondération est activée, la géographie influence le ranking. Sans elle, on observe l'ordre non géographique obtenu plus haut, une fois la géographie retirée. Le plafond de 20 résultats demeure dans les deux cas.
Le rayon que ce formulaire affiche sera souvent différent de celui des rayons médians mesurés plus haut, et ce n'est pas une contradiction : le tableau donne une médiane sur des dizaines de points d'origine, alors qu'ici vous interrogez un point unique. Sur pharmacie au centre de Paris, la médiane est à 0,98 km et ce point-là monte à 5,68 km, parce que trois pharmacies éloignées entrent dans le top 20 devant des dizaines de plus proches. C'est précisément le phénomène d'une recherche locale sans rayon fixe, et c'est plus convaincant de le voir que de le lire.
Avant même que l'utilisateur valide sa recherche, Maps appelle son service Suggest à chaque caractère.
Cette section ne présente pas un catalogue. Elle démontre une seule chose.
À chaque caractère frappé, le système qualifie ce que vous êtes en train d'écrire, et il sait déjà si la réponse sera locale ou non.
Sur 199 suggestions mesurées côté cartographique :
établissement 125 catégorie 29 enseigne 21 localité 11 requête locale, réponse web 9
Le catalogue distingue des cas très fins. Parmi les valeurs :
SUBTYPE_MAPS_ESTABLISHMENT_POI SUBTYPE_MAPS_CATEGORY SUBTYPE_MAPS_CHAIN SUBTYPE_MAPS_LOCALITY SUBTYPE_MAPS_LOCAL_WEB SUBTYPE_MAPS_POLITICAL SUBTYPE_MAPS_ROUTE SUBTYPE_MAPS_STREET_NUMBER SUBTYPE_MAPS_TRANSIT_STATION SUBTYPE_MAPS_TRANSIT_LINE SUBTYPE_MAPS_DISH SUBTYPE_MAPS_AD SUBTYPE_MAPS_PLUS_CODE SUBTYPE_MAPS_LAT_LNG SUBTYPE_MAPS_SYNTHETIC_PLACEID SUBTYPE_MAPS_CRISIS
Pour les numéros de rue, le catalogue va jusqu'à :
STREET_NUMBER
OUTSIDE_SEARCH_RANGE
OUTSIDE_MINMAX
IN_RANGE
IN_GAPGoogle sait donc représenter un numéro qui tombe dans un trou de la plage d'adresses connue. Ce n'est ni une adresse valide, ni une adresse hors zone : c'est un troisième état.
SUBTYPE_MAPS_ASK_MAPS SUBTYPE_MAPS_ASK_MAPS_PROMPT SUBTYPE_MAPS_ASK_MAPS_PROMPT_FALLBACK SUBTYPE_MAPS_ASK_MAPS_QUERY_MIRROR SUBTYPE_MAPS_ASK_MAPS_QUERY_MIRROR_FALLBACK
Une seule réponse d'autocomplétion sur ramen. Toutes ses suggestions commencent par les mêmes cinq lettres, et pas une seule ne reçoit la même qualification.
Le libellé « See locations » n'est donc pas une décision d'interface. C'est la conséquence d'une qualification faite en amont, à la frappe.
Le client mobile parle à une architecture de services gRPC sur HTTP/3. Le catalogue que nous avons reconstruit contient 115 services et 395 méthodes.
Ce catalogue montre à quel point parler du « moteur Google Maps » au singulier devient trompeur.
La recherche, les fiches, la carte, l'UGC, la publicité, les données personnelles et l'IA sont des couches distinctes qui communiquent autour d'identités communes.
Quand Google renvoie un résultat, il ne transmet pas le FeatureProto de Geostore. Il construit une vue de serving beaucoup plus riche.
Nous avons retrouvé dans PlaceProto :
identité Geostore note nom nombre d'avis adresse site Web coordonnées horaires téléphone photo principale gcid MID attributs ontologiques recherches associées
La fiche complète ajoute ensuite :
avis individuels menus
photos contribuées prix
topics KG dans les avis questions / réponses
affluence par heure réponses du propriétaire
et par jour taxonomies guidées
contenu éditorialSearch et GetPlace utilisent la même structure de lieu, mais avec des niveaux de remplissage différents. Le client demande explicitement les sous-champs dont il a besoin via un FieldMask.
GEOSTORE FEATURE
identité, géométrie, provenance,
catégories, existence, ranking
│
┌────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Knowledge Graph UGC données produit
marques avis menus
concepts photos prix
plats Q&R horaires
attributs
│ │ │
└────────────┼─────────────┘
│
personnalisation
│
▼
PlaceProto
│
▼
FICHEUne fiche Google Maps est un document composé à la volée autour d'une entité, pas une copie de la base géographique.
Le contenu servi par Maps va beaucoup plus loin que les anciennes informations de POI. Nous retrouvons :
des résumés génératifs des thèmes extraits des avis du sentiment par thème un score de pertinence par avis des justifications des offsets reliant les phrases aux concepts des attributs confirmés ou non confirmés
C'est exactement le type de matériau nécessaire à une interface conversationnelle.
Ask Maps n'arrive donc pas au-dessus d'une table contenant uniquement :
Nom Adresse Étoiles Horaires
Il arrive au-dessus d'une représentation déjà fortement enrichie et sémantisée des lieux.
Voici ce que la réponse porte réellement autour d'une seule requête et d'un seul établissement, remis à plat.
serves, cuisine, is-a.Ce n'est pas une fiche avec des champs. C'est un voisinage d'entités reliées par des relations nommées, et c'est là-dessus qu'une question en langage naturel peut se poser.
La fiche de restaurant que nous suivons depuis le début de ce fil ramen porte, sans qu'aucun modèle génératif n'intervienne au moment de la lecture : les plats du menu identifiés par leur MID, les avis ancrés sur des sujets identifiés avec leurs offsets de caractères, les photos taguées par plat, et les attributs séparés en confirmés et non confirmés.
Sur une autre fiche de notre corpus, une chaîne de restauration cette fois, la couche thématique est présente et se lit directement :
thème "wait time" mentions 87 positives 2 négatives 85
Quatre-vingt-cinq mentions négatives sur quatre-vingt-sept, et le compte est déjà fait avant qu'une question soit posée. S'y ajoute un score de pertinence par avis et des justifications avec leurs offsets.
Ask Maps n'invente pas cette matière. Il la lit.
L'exemple se referme ici. La chaîne ramen ne désignait pas un mot clé. Elle désignait un point d'entrée dans une ontologie, et un établissement gagne ou perd selon les concepts auxquels le système sait le relier.
Nous avions le code de la veille et celui du lendemain d'une annonce. Ce que le diff montre pèse plus lourd que la date.
Google présente Ask Maps le 12 mars 2026, dans un billet officiel : questions complexes sur le monde réel, recommandations personnalisées, interaction conversationnelle avec la carte, déploiement initial aux États-Unis et en Inde sur Android et iOS, desktop annoncé pour plus tard (source).
Cinq mois plus tard, le 6 août 2026, une seconde annonce élargit l'ensemble (source). Six volets :
1 ouverture à 160 nouveaux pays 2 connexion sécurisée à Gmail, Agenda « bientôt » 3 partenaires de commande de repas 4 comparaison de prix d'hôtels 5 détection d'horaires sur photo d'enseigne 6 fréquentation et alertes transport
La commande de repas, elle, était déjà là mi-juillet :
ASK_MAPS_FOOD_ORDERING_AGENT END_TO_END_ACTION_FOOD_ORDERING
L'annonce est presque entièrement un allumage serveur d'une infrastructure livrée avant.
FetchLlmResult GetKnowBeforeYouGoSummaries CallKnowBeforeYouGoAgent PrototypeCallAskMapsAgent PrototypeCallAskMapsAgentStreamed CreateSharedAskMapsHistoryThread GetSharedAskMapsHistoryThread
Cela permet de distinguer plusieurs fonctions :
GÉNÉRATION → résultats LLM AGENT → Ask Maps MÉMOIRE → historique des conversations CONTEXTE LIEU → Know Before You Go
Ask Maps est donc moins un chatbot posé devant Maps qu'une nouvelle interface vers les couches sémantiques, géographiques et transactionnelles déjà présentes.
Une valeur parlante apparaît dans le code :
PERSONAL_INTELLIGENCE = 45 sur 138 types de contenus de fiche
Nous retrouvons également un service :
personalitem ListPersonalPlaces UpdatePersonalIntelligence UpdatePersonalNotes
Et plusieurs sources portent des noms sans ambiguïté :
KBYG_GMAIL_FLIGHT_RESERVATION KBYG_GMAIL_HOTEL_RESERVATION KBYG_GMAIL_RESTAURANT_RESERVATION TIME_TO_LEAVE_FOR_GMAIL_*
Une autre configuration, PLACESHEET_PERSONAL_INTELLIGENCE_MODULES, montre que cette couche peut alimenter des modules de la fiche elle-même, pas uniquement une réponse conversationnelle.
Le cadre public de Google va dans la même direction : les Search services, dont Maps, peuvent, avec le consentement de l'utilisateur, accéder à des applications comme Gmail, Agenda et Google Photos afin de produire des expériences plus personnalisées.
Deux personnes peuvent désormais consulter la même entité géographique sans recevoir exactement la même composition informationnelle autour d'elle.
L'idée reçue veut que tout se joue entre le téléphone et le serveur, le premier envoyant une requête et le second renvoyant une réponse :
téléphone │ ▼ serveur Google │ ▼ réponse
Une couche système embarquée révèle un autre étage. Une partie de l'intelligence géographique est calculée localement sur l'appareil.
Nous avons retrouvé deux grandes couches.
Cet étage est tagué : 102 messages nommés, champs numérotés. Nous lisons les noms directement.
SemanticSegment Visit PlaceCandidate PlaceInfo MobilePlacePopularity CslStateSnapshot DeviceGenericPersona
Cet étage est compilé en WebAssembly. Ses 85 tables de parsing sont localisées et leurs tags exacts sont connus, mais aucune n'est nommable : nous connaissons les noms de types par RTTI, pas la correspondance type ↔ table.
PulpCalculationInputs FeatureWeights Persona ChainAffinity UserLocationProfile FrequentPlace FrequentTrip PlaceAggregates AliasedLocationLite
La distinction compte. Sur CSL, nous pouvons citer un nom de message et dire qu'il existe. Sur Pulp, nous pouvons dire qu'une table de 85 entrées existe et donner ses tags, sans pouvoir affirmer que telle table correspond à tel type.
Le pipeline visible ressemble à ceci :
SIGNAL DE LOCALISATION
│
▼
INFÉRENCES POINT PAR POINT
│
▼
SEGMENTATION
│
▼
BEAM SEARCH
│
▼
SEGMENTS SÉMANTIQUES
│
▼
VISITES / LIEUX CANDIDATS
│
▼
PULP / HULK
│
├── domicile
├── travail
├── lieux fréquents
├── trajets fréquents
├── modes de déplacement
└── personaLe profil contient :
Persona ├── ChainAffinity ├── LocationAffinity └── TravelModeAffinity FrequentPlace FrequentTrip Visit Activity PlaceCandidate SemanticSegment
Le champ le plus frappant pour les marques est celui-ci.
Persona.ChainAffinityL'affinité d'un utilisateur pour une enseigne peut être calculée et conservée comme une donnée de son profil géographique local.
Il faut distinguer cette information d'un facteur de ranking universel. Il s'agit d'une donnée de personnalisation sur l'appareil.
Mais pour comprendre où Google Maps se dirige, c'est un signal architectural.
Le composant de labellisation domicile / travail embarque en dur une série d'identifiants de catégories.
housing indoor_lodging
residential_area guest_house
apartment motel
apartments luxury_hotel
apartment_complex budget_hotel
condominium resort_hotel
student_housing_... boarding_school
building_society college
cottage_village university
kindergarten
library
station
transitEt juste à côté apparaissent des états comme :
tp-poi-suitable-for-home tp-poi-not-suitable-for-home tp-poi-suitable-for-work tp-poi-not-suitable-for-work tp-no-prominent-category
La nature sémantique du lieu participe donc à la décision de savoir s'il est plausible comme domicile ou comme lieu de travail.
La dernière valeur mérite d'être lue deux fois : tp-no-prominent-category. Un lieu sans catégorie proéminente est un cas traité explicitement, pas un cas oublié.
Ce scorer est à ne pas confondre avec les 72 signaux Geostore. Il appartient au moteur de recherche embarqué et n'est pas utilisé lorsque le ranking vient du serveur.
Sa structure :
8 signaux
× 13 paliers
+ 8 bases
─────────────
112 fonctionsQuatre dimensions de sa famille principale ont pu être caractérisées expérimentalement :
| Code | Comportement observé |
|---|---|
c-L | proéminence locale de base |
c-R | correspondance textuelle requête / nom |
c-C | correspondance de catégorie |
c-A | composante adresse / position |
Le palier dépend de l'échelle du viewport. Lorsque nous faisons varier uniquement le zoom, tous les signaux changent de palier ensemble.
Cela donne une séparation supplémentaire :
RANKING GEOSTORE
72 signaux, importance d'entité
≠
RANKING SERVEUR PLACES
requête + géographie + pertinence
≠
SCORER OFFLINE DU CLIENT
8 signaux × 13 paliersParler du « ranking Google Maps » comme d'une seule formule masque donc plusieurs mécanismes différents.
Il reste une dernière étape. Même si une entité existe et même si elle est candidate, Google doit décider ce qui sera réellement écrit sur la carte.
Le moteur de rendu mapcore est partagé entre plusieurs environnements. Nous avons retrouvé une table de :
50 998 styles 12 936 styles de labels
Un style peut changer selon le zoom. Le mécanisme d'apparition du texte est simple :
font.size = 0
↓
label invisible
font.size > 0
↓
label affichableSur 1 386 styles commençant avec une taille nulle, les niveaux d'apparition varient fortement. Et 593 styles ne deviennent jamais du texte, quel que soit le zoom étudié. Ils restent des représentations sans nom écrit.
Sur le style global 7557, « Restaurant & Bar », les deux entrées de zoom sont identiques champ pour champ, à une exception près :
style 7557 « Restaurant & Bar » zoom 0 font.size = 0 px zoom 11 font.size = 11 px tous les autres champs : identiques
La visibilité du nom d'un commerce n'est donc pas simplement :
score du commerce > seuil
Le serveur attribue d'abord un style. Ce style détermine à partir de quel zoom son texte est éligible.
Chaque LabelRenderOp contient :
texte géométrie style rang de priorité CID / Feature ID représentations alternatives
Sur la couche où les 20 résultats de recherche sont injectés dans la carte, nous retrouvons exactement :
résultat #1 → 16383 résultat #2 → 16382 résultat #3 → 16381 … résultat #20 → 16364
L'ordre du classement serveur devient donc directement un ordre de priorité pour l'affichage des résultats injectés.
Le client reçoit beaucoup plus de labels qu'il ne peut en afficher. Son travail consiste ensuite à :
résoudre les collisions
↓
essayer une représentation alternative
↓
texte
↓
icône seule
↓
suppression si nécessaireIl ne recalcule pas la pertinence du commerce. L'essentiel de la décision a été pris en amont.
La bonne manière de penser Maps n'est donc plus :
BASE DE LIEUX
↓
ALGORITHME
↓
RÉSULTATSmais :
SYSTÈME DE VÉRITÉ
+
GRAPHE D'ENTITÉS
+
INDEX DOCUMENTAIRE
+
MOTEUR DE RECHERCHE
+
MOTEUR CARTOGRAPHIQUE
+
MODÈLES EMBARQUÉS
+
PERSONNALISATION
+
IA GÉNÉRATIVEIl serait tentant de transformer les 72 signaux en une nouvelle checklist de facteurs de ranking. Ce serait une mauvaise lecture de l'étude.
L'enseignement le plus important est architectural.
Google essaie de construire une identité cohérente du lieu à travers :
Maps · Knowledge Graph · Web · Merchant data UGC · géographie · chaîne · historique
Le premier travail consiste à réduire l'ambiguïté autour de l'entité. Nom, adresse, téléphone, catégorie, URL, marque, établissement et relations doivent raconter la même histoire.
Le lien document ↔ MID est présent dans l'index. La topicalité de la page envers l'entité est elle-même représentée, et Webref range les documents entre eux pour cette entité. Des scores Web agrégés reviennent ensuite dans le vocabulaire Geostore.
Une bonne page locale doit répondre sans ambiguïté à :
Quel lieu ? Quelle enseigne ? Quelle adresse ? Quelle catégorie ? Quels services ? Quels produits ? Quelle zone desservie ? Quelle relation avec les autres établissements ?
Google raisonne avec des concepts, une catégorie principale et des relations ontologiques. Une enseigne doit couvrir correctement son territoire sémantique réel, en fournissant assez d'informations cohérentes pour que Google puisse relier le lieu aux bons concepts.
Une précision qui coupe court à une mauvaise déduction : le schéma ne connaît aucune gradation entre catégories secondaires. Seul le basculement en catégorie principale est un fait porté par les données, et nous l'avons vu diverger d'un magasin à l'autre au sein d'une même enseigne. Empiler des catégories secondaires pour « renforcer la pertinence » n'a aucun appui ici.
SIGNAL_GOOGLE_WEB_QUERYVOL appartient explicitement au vocabulaire de ranking Geostore. Parallèlement, le moteur de requête sait reconnaître une marque comme entité et lui associer des catégories.
Cela renforce une idée difficile à mesurer en SEO local : la notoriété et la demande autour de l'entité peuvent compter autant que l'optimisation textuelle de sa fiche.
Ce n'est pas une invitation à générer artificiellement des recherches de marque. Cela signifie que le local ne vit pas dans un silo séparé de la demande globale.
SIGNAL_GOOGLE_REVIEWS existe dans le vocabulaire de ranking. Mais les avis servent aussi à produire des thèmes, extraire du sentiment, identifier des concepts, fournir des justifications, alimenter des résumés génératifs et répondre à des questions conversationnelles.
Avec Ask Maps, un avis devient un corpus de preuves sur :
le service · le produit · l'attente · le bruit l'ambiance · l'accessibilité · la qualité le prix · les plats · les situations d'usage
Pour les marques, la stratégie d'avis devient aussi une stratégie de couverture informationnelle.
LISTING_IMPRESSIONS INFOWINDOW_VIEWS DIRECTION_REQUESTS HOMEPAGE_CLICKS
Cela montre au minimum que Google sait conserver et normaliser ces familles d'interactions dans le cadre du ranking d'entité. Le bon objectif n'est pas de les manipuler : c'est de créer un lieu qui génère naturellement de la demande et des actions réelles.
BusinessChainProto existe. SIGNAL_GOOGLE_CHAIN_STORES existe. Persona.ChainAffinity existe côté utilisateur. Maps distingue une chaîne d'un établissement précis dès Suggest.
Et la mesure rend le point concret : sur 21 magasins d'une même enseigne dans une même métropole, 11 portent gcid:pharmacy et 10 portent gcid:drugstore en catégorie principale, alors que canonical_gconcepts déclare un état idéal pour les membres de la chaîne.
ENTITÉ ENSEIGNE
│
├── magasin A
├── magasin B
├── magasin C
└── magasin DPour une enseigne multi-sites, il faut donc travailler les deux niveaux, et non considérer chaque fiche comme une île.
Nos mesures montrent qu'une requête de marque peut faire chercher beaucoup plus loin qu'une catégorie locale dense. Et que la même requête, hors métropole, s'étend d'un facteur 34.
Il faut arrêter de raisonner uniquement en :
« je suis à 800 mètres, donc je dois être devant »
Google cherche à équilibrer ce que l'utilisateur veut, ce qui existe autour de lui, et l'importance et la qualité des candidats. La distance est centrale. Elle n'est pas souveraine.
Cela ne veut pas dire que la demande de proximité est ignorée : elle est mesurée. Le leak de 2024 documentait un attribut clickRadius50Percent, le rayon dans lequel se produisent la moitié des clics sur une requête. Autrement dit, Google sait pour chaque requête à quelle distance ses utilisateurs acceptent d'aller, et ce rayon est appris, pas fixé.
APPROACHABILITY TOTAL_ROAD_SEGMENT_USAGE ROAD_PRIORITY
Une adresse physique possède des caractéristiques réelles : accès, voirie, flux, position, environnement, transport. Tout n'est pas optimisable depuis un CMS.
Le meilleur emplacement commercial et le meilleur emplacement pour le SEO local ne sont probablement pas deux problèmes totalement indépendants.
Geostore possède des états pour :
closed · removed · moved · rebranded duplicate · replaced · spam
Il conserve aussi des confirmations d'existence avec leur origine et leur horodatage. Une entreprise doit donc surveiller les doublons, les déménagements, les anciens établissements, les changements de marque, les fermetures temporaires et les incohérences d'adresse.
Une erreur d'identité est plus grave qu'un champ mal optimisé.
Ask Maps modifie la sortie du système. Avant :
requête ↓ liste de lieux
Maintenant :
question complexe
↓
compréhension du besoin
↓
sélection de lieux
↓
lecture des attributs
↓
lecture des avis
↓
Knowledge Graph
↓
contexte personnel éventuel
↓
synthèse
↓
recommandation argumentéeUn commerce doit donc fournir de quoi répondre à des questions comme :
Quel restaurant conviendrait à six personnes avec des enfants et une personne végétarienne ?
Quel magasin est pratique sur mon trajet et encore ouvert après mon rendez-vous ?
Où déjeuner rapidement près de mon hôtel avec de bons avis récents sur le service ?
Quelle boutique correspond le mieux aux marques que j'aime déjà ?
Ce ne sont plus des requêtes de catégorie. Ce sont des problèmes à résoudre à partir d'attributs, de relations et de preuves.
Pendant longtemps, le SEO local s'est structuré autour de trois grandes idées :
proximité pertinence proéminence
Ces notions restent utiles. Mais les mécanismes observés suggèrent une lecture plus riche.
Pour recommander un établissement, l'IA doit pouvoir déterminer :
ce qu'il est ce qu'il propose où il est comment on y accède qui l'apprécie pour quelles raisons dans quelles situations avec quelles contraintes à quel moment et avec quel niveau de confiance
La compétition ne porte donc plus uniquement sur la meilleure fiche. Elle porte progressivement sur la meilleure représentation de l'entité.
La découverte la plus importante de cette étude n'est pas un signal particulier.
Ce n'est pas GOOGLE_REVIEWS. Ce n'est pas POPULARITY. Ce n'est pas PROMINENCE. Ce n'est même pas MIXER_PLACERANK.
C'est l'architecture entière.
Le leak de 2024 nous avait montré une partie des plans. Le binaire récent et les mesures réalisées autour de Maps permettent désormais de suivre une grande partie des câbles.
Et c'est probablement au moment où Google ajoute Gemini au-dessus de cette infrastructure que cette compréhension devient la plus utile.
Google Maps n'est pas un moteur de recherche local auquel on ajoute de l'IA.
Il devient un système capable de construire une représentation du monde physique, de la relier au Web et aux entités, de l'observer à travers les comportements, de la contextualiser pour un utilisateur, puis de répondre en langage naturel.
Pour les SEO et les enseignes, cela change la question. Il ne s'agit plus seulement de savoir :
« Comment mieux classer ma fiche ? »
La question devient :
« Quelle représentation Google possède-t-il réellement de mon établissement, de ma marque et de ce qu'ils peuvent apporter à cet utilisateur précis ? »
C'est probablement là que commence la prochaine génération du local SEO.
Tout ce que cette étude cite se vérifie ligne à ligne dans l'archive : 10 936 déclarations, la documentation de mars 2024 en regard, et le dump complet à emporter.
Explorer l'archive