Demandez à Google Maps un café calme, avec des prises, où travailler pendant deux heures.
Lancé cet été par Google, Ask Maps peut répondre avec quelques lieux qui semblent correspondre.
Le plus intéressant n’est pas forcément la réponse. C’est ce qu’elle suppose en amont.
Les fiches de ces cafés ne contiennent pas toujours un champ « calme », « adapté au travail » ou « beaucoup de prises ». Pourtant, Google peut parfois faire remonter ce type d’information.
D’où vient-elle ?
Google possède déjà plusieurs couches d’information sur un lieu
Google indique qu’Ask Maps analyse des informations sur plus de 300 millions de lieux, notamment les avis publiés par une communauté de plus de 500 millions de contributeurs.
Mais une fiche Maps est déjà construite à partir de sources plus nombreuses.
Google explique que les informations affichées dans les profils locaux peuvent provenir du site officiel de l’établissement et d’autres contenus Web publics explorés par Google, de données fournies sous licence par des tiers, des contributions des utilisateurs et des propriétaires, ainsi que d’informations issues des interactions de Google avec le lieu.
Un café peut donc être décrit par ses horaires et sa catégorie, mais aussi par des photos, des avis ou des informations provenant du Web.
Certaines de ces données sont structurées. D’autres sont écrites en langage naturel.
C’est là que Gemini devient utile.
Les avis peuvent déjà être transformés en attributs
Google Maps Platform propose des résumés d’avis générés par Gemini.
La documentation précise qu’ils sont construits uniquement à partir des avis utilisateurs et qu’ils synthétisent notamment les attributs du lieu et les sentiments exprimés.
Un ensemble d’avis peut par exemple contenir des remarques sur l’ambiance, le bruit, le service ou la vue.
Gemini peut transformer ce texte dispersé en une représentation plus facile à exploiter.
Google fait aussi ce travail à l’échelle d’un quartier. Ses résumés de zone peuvent intégrer les points d’intérêt situés autour d’un lieu afin de fournir des informations sur son environnement.
Cela montre au moins une chose : Google sait enrichir un lieu à partir d’informations qui ne figurent pas dans quelques champs classiques de sa fiche.
Faut-il refaire ce travail à chaque question ?
On pourrait imaginer Ask Maps recevant notre demande, parcourant les avis, consultant le site de l’établissement, interrogeant d’autres sources puis envoyant l’ensemble à Gemini.
C’est possible pour certains besoins. Mais à l’échelle de Google Maps, cette architecture aurait un coût.
Chaque recherche supplémentaire ajoute des données à récupérer et à traiter. Chaque contenu envoyé au modèle augmente le travail d’inférence. La réponse prend aussi davantage de temps.
Google a donc intérêt à mutualiser une partie de ce travail lorsque c’est possible.
Et ses produits donnent un indice sur la manière de le faire.
Dans Places API, Google propose déjà des résumés de lieux, d’avis et de zones générés par IA. Sa documentation indique que ces résumés sont régénérés régulièrement à partir des dernières informations disponibles. Lorsqu’une application les demande, elle récupère ensuite la version la plus récente.
Le calcul n’est donc pas nécessairement recommencé depuis zéro pour chaque utilisateur.
On peut en tirer une hypothèse pour Ask Maps, sans prétendre connaître son architecture interne.
Google pourrait préparer en amont une représentation enrichie de chaque lieu, puis utiliser cet index pour trouver rapidement les candidats correspondant à une demande.
Un index plus riche que la carte visible
Dans ce modèle, un café ne serait pas seulement associé à une adresse, des horaires, une catégorie et une note.
Il pourrait aussi être relié à des informations déduites des avis, du Web, de son environnement ou d’autres sources déjà intégrées à Google.
« Calme » pourrait venir d’un ensemble d’avis.
« Prises disponibles » pourrait apparaître dans des contributions ou sur le Web.
« Pratique pour travailler » pourrait résulter du rapprochement de plusieurs éléments.
Ces éléments sont des hypothèses (comme souvent en SEO), nous ne savons pas lesquels de ces signaux Ask Maps utilise réellement ni comment ils sont pondérés.
Nous savons en revanche que Google dispose déjà de mécanismes capables de produire ce type d’enrichissement avant qu’un utilisateur ne pose sa question.
« La transformation de Maps pourrait se jouer avant la requête, dans la manière dont Google prépare et enrichit chaque lieu. »
Renaud Joly
L’architecture la plus vraisemblable est probablement hybride. Les caractéristiques relativement stables d’un lieu peuvent être préparées à l’avance. Les informations qui changent rapidement, comme certains horaires, le trafic ou une disponibilité, peuvent être récupérées au moment de la demande (cf. query deserve freshness en SEO).
Cela permettrait de conserver des réponses fraîches sans reconstruire toute la connaissance du lieu à chaque requête.
Une partie de la réponse peut donc exister avant la question
Ask Maps donne l’impression d’un assistant qui comprend une demande puis part chercher les lieux correspondants. Il est possible qu’une partie importante du travail ait déjà été réalisée.
Google collecte depuis longtemps des informations sur les lieux. Gemini lui permet maintenant d’en extraire davantage de caractéristiques et de les rendre accessibles à des requêtes formulées beaucoup plus librement.
Si cette hypothèse est correcte, l’évolution importante de Maps ne concerne pas seulement son interface conversationnelle.
Elle concerne aussi la manière dont Google prépare son index : chaque lieu peut devenir un objet beaucoup plus riche, décrit par davantage d’attributs susceptibles d’être mobilisés lorsqu’une question arrive.