L’outil Gemini Map arrive alors que Google remplace les commandes slash par @

Google a ajouté un outil Gemini Map sur Android et iOS, tandis qu’un second changement d’interface remplace la commande slash par un menu @.

La carte permet aux utilisateurs d’insérer directement une zone géographique dans un prompt au lieu de la décrire avec des mots. Le changement autour de @ regroupe Skills, services connectés et autres outils dans une même couche de sélection.

Ensemble, ces mises à jour annoncent un autre type d’application Gemini. Google transforme la zone de prompt, d’un champ de texte vierge, en surface de contrôle permettant de choisir du contexte et des capacités.

Le changement immédiat reste modeste. Les utilisateurs disposent d’un sélecteur visuel de localisation et d’un menu consolidé. L’enjeu plus large est qu’un assistant devient plus utile lorsque les personnes peuvent lui montrer précisément où intervenir.

Cela met sous pression l’interface traditionnelle du chatbot, centrée sur le texte. OpenAI, Anthropic et d’autres développeurs d’assistants ont étendu l’usage des outils, mais Google possède une combinaison distinctive de distribution mobile et d’infrastructure cartographique.

L’outil Gemini Map teste la capacité de cet avantage à se traduire par une meilleure expérience de formulation des prompts. Il soulève aussi des questions familières sur la disponibilité, la précision de la localisation, le traitement des données et la capacité de Gemini à agir de manière fiable sur le contexte sélectionné.

L’outil Gemini Map transforme une zone en contexte de prompt

La nouvelle carte fait passer la localisation de quelque chose que les utilisateurs décrivent à quelque chose qu’ils peuvent sélectionner.

L’outil Map mobile apparaît dans le carrousel de pièces jointes de l’application Gemini sur Android et iOS. Il côtoie des options telles que Photos, Camera, Files, Drive, Avatar et Notebooks.

La sélection de Map ouvre une vue en direct centrée sur la zone actuelle de l’utilisateur. L’interface comprend une zone de focalisation circulaire qui identifie l’emplacement que Gemini doit prendre en compte.

Les utilisateurs peuvent déplacer la carte, zoomer ou dézoomer, ou rechercher une autre destination. En touchant « Explorer cette zone », ils ajoutent ensuite une pièce jointe « Zone de carte » à la zone de prompt.

Cette pièce jointe peut être combinée à une demande écrite. Un voyageur pourrait sélectionner plusieurs pâtés de maisons autour d’un hôtel et demander des restaurants calmes adaptés à une réunion.

Un utilisateur pourrait également choisir un quartier inconnu et demander des cafés près d’un arrêt de transport. Une personne planifiant des courses pourrait demander à Gemini d’identifier des arrêts utiles dans la zone sélectionnée.

La distinction importante est celle de la précision. Une expression telle que « près du centre-ville » peut recouvrir une limite géographique imprécise. Une sélection sur la carte donne au système une référence visuelle définie.

Cela ne garantit pas une réponse correcte. Cela réduit toutefois une source d’ambiguïté avant que Gemini ne commence à raisonner sur la demande.

Le flux de travail sépare également la sélection d’une zone de la recherche d’une destination. Les utilisateurs n’ont pas besoin de commencer par le nom exact ou l’adresse d’un établissement.

Ils peuvent partir de la géographie, puis laisser le prompt décrire leur intention. Cette structure convient mieux aux questions exploratoires qu’un champ de destination classique.

Le déploiement rapporté est réservé au mobile. L’option Map n’est actuellement pas disponible via l’interface web de Gemini, même si l’application web peut utiliser la localisation pour proposer des réponses pertinentes.

Cette différence compte, car l’interaction dépend du toucher. Parcourir une carte et ajuster une zone cible paraît naturel sur un téléphone utilisé pendant un déplacement.

La fonctionnalité devient aussi plus immédiate que la copie de coordonnées, de noms de rues ou de liens entre applications. La carte devient un objet d’entrée, au même titre qu’une image ou un document.

Google a déjà relié Gemini à des informations géographiques dans d’autres contextes. Son précédent lancement de Maps grounding a donné aux développeurs accès à des informations couvrant plus de 250 millions de lieux.

L’outil Map destiné aux consommateurs applique la même idée générale au niveau de l’interface. Il permet aux utilisateurs de définir un contexte géographique avant de demander à Gemini de l’interpréter.

Cependant, le nouveau sélecteur ne doit pas être confondu avec une navigation complète. L’interface rapportée prépare un prompt fondé sur la localisation plutôt qu’elle ne remplace les itinéraires détaillés.

Elle n’établit pas non plus que chaque demande utilisera des conditions en temps réel, des lieux privés enregistrés ou des informations exhaustives sur les établissements. Ces capacités dépendent des services auxquels Gemini peut accéder.

L’interprétation la plus défendable est plus restreinte. Google a créé un moyen direct de joindre une zone choisie à une conversation Gemini.

Cet ajout importe, car les prompts géographiques sont souvent difficiles à formuler avec précision. Une région sélectionnée donne à Gemini une limite plus claire pour y répondre.

Il crée également la tension centrale de l’article. Google peut offrir un contexte géographique exceptionnellement riche, mais les utilisateurs doivent toujours comprendre quelles données entrent dans la conversation.

Google reconstruit la zone de prompt autour des outils

La zone de prompt devient un lanceur d’entrées spécialisées, d’instructions réutilisables et de services connectés.

L’option Map constitue une partie de cette transition. La seconde apparaît dans la version bêta 17.63 de l’application Google, selon le rapport initial.

Dans cette bêta, taper une barre oblique affiche un message indiquant que la barre oblique est désormais @. L’interface précise que les utilisateurs peuvent accéder aux Skills, aux Connectors et à d’autres éléments depuis un seul endroit.

Google n’avait introduit que récemment la barre oblique comme moyen d’invoquer les Skills. Ce changement rapide suggère que Google considère un menu d’outils unifié comme plus important que la préservation de cette convention de commande.

Le symbole @ a déjà une signification claire dans de nombreux produits numériques. Il identifie généralement une personne, un service, un agent ou une ressource devant participer à la tâche en cours.

Ce modèle mental est utile pour Gemini. Un utilisateur peut considérer un Skill ou une application connectée comme une source explicite de capacité plutôt que comme un paramètre système invisible.

L’interface élargie change également de vocabulaire. Les « Connected Apps » devraient devenir des « Connectors », tandis que les Gems sont remplacés par les Skills.

Google définit les Gemini Skills comme des instructions personnalisées réutilisables pour des tâches et des flux de travail récurrents. Gemini peut appliquer automatiquement un Skill pertinent, ou l’utilisateur peut en spécifier un.

Ce modèle diffère d’un prompt ponctuel. Un Skill conserve une méthode répétable, qui peut être sollicitée de nouveau lorsqu’une tâche similaire se présente.

Google indique également que plusieurs Skills peuvent fonctionner ensemble. L’un pourrait établir les règles rédactionnelles d’une organisation, tandis qu’un autre définirait les étapes de production d’un rapport hebdomadaire.

Le menu @ donne à ces instructions réutilisables un espace commun avec les services externes. Il transforme la zone de prompt en couche de routage entre le modèle, les flux de travail enregistrés et les données connectées.

L’extension des applications connectées de Google en septembre illustre l’ampleur de cette ambition. L’entreprise a annoncé des intégrations dans les catégories de productivité, de création et de style de vie.

Ses exemples incluaient la gestion de projets, l’organisation de bases de données, le design, la création de sites web, la planification d’exercices, la recherche d’appartements, le suivi du crédit et la découverte d’événements.

Les utilisateurs peuvent connecter des services pris en charge dans les paramètres. Ils peuvent ensuite en intégrer un à une conversation au moyen d’une mention @ ou d’une demande directe.

La nouvelle interface réduit la distinction entre ces services et les propres Skills réutilisables de Google. Tous deviennent des ressources appelables au sein de la même conversation.

Map étend ce modèle de ressource à l’espace physique. Une zone sélectionnée devient un autre objet que Gemini peut utiliser avec des fichiers, des photos, des notebooks et des applications connectées.

Cette consolidation peut réduire les frictions de l’interface. Les utilisateurs n’ont plus besoin de se souvenir qu’une ressource utilise @ tandis qu’une autre utilise une barre oblique.

Elle peut aussi rendre le menu encombré. Un sélecteur unique pourrait à terme contenir des Skills personnels, des processus de travail, des services Google, des outils tiers et des entrées multimédias.

La découverte importera donc autant que la disponibilité. Si les utilisateurs ne peuvent pas anticiper la ressource sélectionnée par Gemini, la consolidation risque de masquer la complexité au lieu de la supprimer.

Le routage automatique soulève une préoccupation connexe. La capacité de Gemini à choisir un Skill approprié peut faire gagner du temps, mais un choix incorrect peut modifier discrètement le résultat.

Les mentions @ explicites offrent un contrepoids utile. Elles permettent à l’utilisateur d’identifier l’outil visé avant que le modèle n’interprète la tâche.

L’interface est encore en transition. L’outil Map est décrit comme largement disponible, tandis que le remplacement de la commande slash n’est pas encore déployé à grande échelle.

Les utilisateurs peuvent donc voir des contrôles différents selon les comptes, les plateformes et les versions de l’application. Une interface bêta ne doit pas être considérée comme une migration mondiale achevée.

L’orientation de Google est plus claire que son calendrier. L’entreprise veut que la zone de prompt de Gemini coordonne une collection d’outils, et pas seulement qu’elle accepte du texte.

L’outil Gemini Map met en évidence l’avantage géographique de Google

L’avantage de Google ne réside pas seulement dans le sélecteur de carte, mais dans le système cartographique qui l’alimente.

Les assistants concurrents peuvent accepter des adresses, des coordonnées, des captures d’écran et des questions liées à la localisation. Certains peuvent aussi appeler la recherche web ou des services externes pour obtenir des informations actuelles sur des lieux.

Google aborde le problème depuis une position différente. L’entreprise exploite Google Maps, distribue Gemini sur Android et gère des services contenant un contexte personnel utile.

Cette combinaison fait de la localisation un domaine naturel pour l’intégration produit. Elle donne également à Google l’occasion de raccourcir des flux de travail qui passent aujourd’hui entre un chatbot et une application de cartographie.

Google a commencé à exposer cette stratégie aux développeurs avant l’apparition du nouveau sélecteur destiné aux consommateurs. Son outil Maps pour l’API Gemini relie les réponses du modèle à des informations géospatiales actuelles.

L’entreprise a déclaré que ce produit destiné aux développeurs s’appuie sur plus de 250 millions de lieux. Cette échelle donne à Gemini une base substantielle pour les questions sur les restaurants, les attractions, les services et les itinéraires.

Google a également étendu Gemini au sein de Maps lui-même. Une voie commence par la navigation et introduit une assistance conversationnelle pendant un trajet.

L’outil Gemini Map suit la direction inverse. Il démarre dans l’assistant et importe une zone géographique choisie dans la conversation.

Ces deux voies commencent à se rejoindre. Maps gagne en comportement conversationnel, tandis que Gemini gagne en entrées géographiques plus explicites.

Cette convergence met sous pression l’idée qu’un assistant IA devrait rester une destination distincte. Google peut placer Gemini avant, pendant et après une décision fondée sur la localisation.

Prenons une tâche de planification de week-end. Un utilisateur pourrait sélectionner une zone, demander plusieurs options, les comparer à des contraintes de calendrier, puis poursuivre avec la navigation.

La pièce jointe Map gère la première étape en définissant la zone de recherche. Les Connectors pourraient à terme fournir les disponibilités, les réservations, les billets ou d’autres informations spécifiques à une tâche.

Les Skills pourraient conserver les préférences récurrentes de l’utilisateur. Une instruction enregistrée pourrait privilégier la distance à pied, des établissements plus calmes, l’accessibilité ou un format d’emploi du temps particulier.

Cette combinaison ferait de l’assistant plus qu’un moteur de recherche de lieux. Il coordonnerait le contexte géographique avec les règles personnelles et les services connectés.

La version actuelle n’établit pas que ce flux de travail complet fonctionne de manière fiable. Elle ne fournit que plusieurs éléments d’interface nécessaires à sa construction.

Cette distinction est importante. Une zone sélectionnée visuellement n’élimine pas les hallucinations, les fiches obsolètes, les horaires manquants ou les recommandations discutables.

Les recommandations fondées sur la localisation comportent de nombreuses exigences cachées. Le système doit interpréter la limite, récupérer les lieux pertinents, les classer et expliquer pourquoi ils conviennent.

Une erreur à n’importe quelle étape peut affaiblir la réponse. Une zone cartographique magnifiquement sélectionnée offre peu de valeur si Gemini néglige une contrainte importante dans le prompt.

La profondeur cartographique propre à Google modifie toujours le calcul concurrentiel. Les rivaux peuvent intégrer des fournisseurs de cartographie, mais Google contrôle à la fois l’assistant et une plateforme géographique majeure.

L’entreprise atteint également les utilisateurs sur iOS par le biais de son application, malgré l’absence du contrôle du système d’exploitation dont elle dispose sur Android. L’arrivée de l’outil Map sur les deux plateformes mobiles élargit le test.

La disponibilité sur le web reste une lacune notable. Les utilisateurs d’ordinateur qui recherchent des destinations de voyage ou des sites professionnels peuvent préférer un écran plus grand et un clavier.

Google pourrait éventuellement étendre le sélecteur au web, mais le lancement rapporté ne le promet pas. Son absence maintient la fonctionnalité actuelle centrée sur l’usage mobile.

La pression sur les concurrents est donc spécifique. Ils doivent rendre le contexte géographique tout aussi facile à fournir, même sans posséder la carte sous-jacente.

La pression sur Google est tout aussi réelle. L’entreprise doit démontrer que l’intégration produit de meilleurs résultats, et pas seulement davantage de passerelles vers les services existants.

Un meilleur prompt de localisation s’accompagne d’une responsabilité accrue en matière de confidentialité

L’outil Map supprime l’ambiguïté de la demande, mais il rend les frontières des données plus importantes.

Gemini utilise déjà la localisation de plusieurs façons. Google indique que ses applications peuvent utiliser une localisation générale ou la localisation précise d’un appareil lorsqu’une autorisation est disponible.

Sur mobile, ces autorisations dépendent en partie de l’application Google qui héberge les fonctions d’assistant de Gemini. Les réglages de la plateforme peuvent donc affecter le contexte reçu par Gemini.

La nouvelle interface Map introduit un signal plus délibéré. Les utilisateurs choisissent activement une zone et l’attachent à leur prompt.

Cette action est plus facile à comprendre qu’une inférence invisible en arrière-plan. La carte sélectionnée offre une représentation visible du lieu partagé.

Toutefois, la visibilité au stade de l’ajout ne répond pas à toutes les questions. Les utilisateurs peuvent encore vouloir savoir comment le prompt est stocké, traité et combiné à d’autres informations.

Les contrôles de confidentialité de Gemini de Google expliquent que les informations Gemini peuvent inclure les prompts, le contenu importé, les données d’applications connectées, les informations sur l’appareil et les informations de localisation.

La documentation distingue également la localisation générale de la localisation précise. Les utilisateurs devraient examiner les autorisations des applications et les paramètres d’activité Gemini avant de partager un contexte géographique sensible.

Une sélection sur la carte peut révéler davantage qu’une destination. Elle peut identifier une zone de domicile, un lieu de travail, un établissement médical, une école ou une habitude de déplacement récurrente.

Ce risque augmente lorsque la localisation s’ajoute à des informations issues d’e-mails, de calendriers, de fichiers, de photos, de contacts ou de services tiers. Chaque connexion peut rendre une réponse plus utile et plus personnelle.

Google indique que la connexion d’applications prises en charge reste soumise aux contrôles des utilisateurs. Pourtant, le contrôle devient plus difficile à évaluer lorsque l’assistant combine automatiquement plusieurs sources.

Le menu @ unifié peut aider en rendant les ressources sélectionnées visibles. Un utilisateur qui invoque explicitement un connecteur sait plus clairement qu’il entre dans la tâche.

La sélection automatique de Skill est moins évidente. Un flux de travail enregistré peut influencer une réponse même lorsque l’utilisateur ne l’appelle pas directement.

Les Skills sont des instructions plutôt que des sources de données, mais ils peuvent façonner ce que Gemini demande ou la manière dont il utilise les informations connectées. Cela rend la transparence importante.

Une interface digne de confiance devrait indiquer quel Skill, connecteur ou élément joint a influencé la réponse. Elle devrait également permettre de supprimer facilement ces éléments avant l’envoi.

L’ajout Map semble fournir ce type d’objet explicite dans la zone de prompt. La question de savoir si l’interface finale explique l’utilisation des données en aval reste distincte.

L’exactitude fait aussi partie de cette discussion sur les risques. Une zone sélectionnée peut être précise à l’écran alors que son interprétation sous-jacente reste imparfaite.

Les limites peuvent traverser des quartiers, des districts, des campus ou des zones commerciales. Gemini pourrait traiter un cercle approximatif comme un rayon de recherche strict ou seulement comme une indication générale.

Le nom de la fonctionnalité pourrait créer l’attente qu’elle effectue une recherche cartographique complète. Les utilisateurs devraient vérifier les détails critiques dans Google Maps ou directement auprès d’un établissement.

C’est particulièrement important pour les horaires d’ouverture, l’accessibilité, les réservations, les conditions routières et le temps de trajet. Ces détails peuvent changer après que Gemini a généré une réponse.

L’assistant devrait également distinguer les recommandations fondées sur des informations Google Maps actuelles des suggestions basées sur des contenus web plus larges. L’interface ne rend pas toujours cette provenance évidente.

Une deuxième incertitude concerne la cohérence du déploiement. L’outil Map serait largement disponible sur Android et iOS, mais la disponibilité des fonctionnalités peut encore varier selon les comptes.

Le remplacement par @ en est à un stade plus précoce de déploiement. Les utilisateurs des versions stables peuvent continuer à voir le menu avec barre oblique tandis que les utilisateurs bêta reçoivent le sélecteur consolidé.

Cet état progressif peut compliquer les instructions partagées en ligne ou au sein des organisations. Un flux de travail documenté pour une version peut ne pas correspondre à l’écran d’une autre personne.

La migration de Gems vers Skills ajoute une autre transition. Les assistants personnalisés existants deviennent des Skills réutilisables, ce qui soulève des questions de compatibilité et de préservation du comportement.

Google doit gérer ces changements sans donner l’impression que les flux de travail familiers deviennent instables. Renommer des fonctionnalités et modifier les symboles d’invocation peut imposer un coût d’apprentissage modeste mais récurrent.

Le pari de l’entreprise est qu’un point d’entrée @ cohérent compensera ce coût. La réussite de ce pari dépend d’un routage prévisible et de retours clairs.

Le défi central n’est pas de savoir si Google peut placer davantage d’outils dans Gemini. Il s’agit de déterminer si les utilisateurs peuvent comprendre quel outil a agi, quelles données il a utilisées et comment le corriger.

Trois signaux montreront si le pari de Google sur l’interface fonctionne

Le prochain test sera de savoir si un menu d’outils plus clair produit des actions plus fiables et plus compréhensibles.

Le premier signal est le déploiement complet du sélecteur @. Google doit l’étendre au-delà d’une disponibilité bêta limitée sans fragmenter le comportement entre Android, iOS et le web.

Un déploiement achevé renforcerait l’idée que @ est le langage permanent d’invocation des outils de Gemini. Une incohérence persistante affaiblirait l’argument de l’interface unifiée.

Le détail pertinent n’est pas seulement le symbole. Les utilisateurs devraient voir la même organisation de base pour les Skills, les Connectors et les autres ressources sur les appareils pris en charge.

Google doit aussi expliquer comment la sélection explicite interagit avec le routage automatique. Les utilisateurs doivent savoir quand Gemini a choisi un Skill et quand leur mention @ a remplacé ce choix.

Le deuxième signal est une disponibilité plus large de l’outil Gemini Map. La prise en charge du web montrerait que Google considère la sélection géographique comme une entrée fondamentale, et non comme une expérimentation mobile.

L’utilisation sur ordinateur pourrait servir à la recherche de voyages, aux comparaisons immobilières, à la logistique, à la planification d’événements et à l’analyse d’entreprises fondée sur la localisation. Ces tâches bénéficient souvent d’une carte plus grande.

Plus important encore, Google devrait révéler ce que la limite sélectionnée contrôle réellement. Les utilisateurs doivent avoir confiance que Gemini respecte la zone plutôt que de la traiter comme une suggestion vague.

Les résultats devraient également indiquer lorsqu’une recommandation s’appuie sur des informations Google Maps actuelles. Un ancrage clair rendrait l’outil plus facile à faire confiance et à vérifier.

Le troisième signal est une coordination plus poussée entre les Skills et les Connectors. L’interface de Google gagne en valeur lorsque ces ressources coopèrent sans créer de comportement caché.

Un utilisateur pourrait invoquer un Skill de planification, joindre une Map Area et appeler un connecteur de réservation. Gemini devrait alors préserver chaque contrainte tout au long du flux de travail.

C’est un test exigeant. Le système doit conserver le contexte, appeler les bons services, présenter des erreurs récupérables et éviter les actions non intentionnelles.

L’expansion précédente par Google des services connectés suggère que l’entreprise souhaite que Gemini couvre davantage de ces flux de travail. Le menu @ offre à ce catalogue en croissance une entrée commune.

Ce changement reflète aussi une évolution plus large des chatbots vers des assistants qui utilisent des outils. Le modèle reste central, mais le travail utile s’effectue de plus en plus par le biais de contextes sélectionnés et de systèmes externes.

Cette évolution peut bénéficier aux travailleurs du savoir au-delà du voyage. Un bon assistant devrait permettre aux personnes d’identifier la source, le flux de travail et la limite pertinents pour chaque demande.

Le même principe s’applique au travail avec des documents et des informations personnelles. Une base de connaissances personnelle devient plus utile lorsque les utilisateurs peuvent contrôler le contexte qui entre dans une tâche.

Le sélecteur de carte de Google offre une version concrète de cette idée. Au lieu d’espérer que l’assistant déduise le bon lieu, l’utilisateur fournit la zone visée.

Le menu @ étend ce principe aux capacités. Au lieu de s’appuyer entièrement sur la sélection automatique, l’utilisateur peut appeler un Skill ou un connecteur particulier.

Aucun de ces changements ne supprime le besoin de jugement. Les utilisateurs doivent toujours vérifier les recommandations importantes, surveiller les autorisations et contrôler les services qui ont participé.

L’outil Gemini Map est donc moins important comme widget cartographique autonome que comme preuve d’un modèle d’interface en évolution.

Google remplace le prompt vide par des choix structurés. Les fichiers, les photos, les lieux, les instructions enregistrées et les services externes peuvent tous devenir des éléments visibles.

Si ces éléments restent compréhensibles, Gemini peut paraître plus précis sans nécessiter des prompts plus longs. S’ils deviennent opaques, l’interface ne fera que masquer une complexité supplémentaire.

Surveillez le déploiement de @, la prise en charge des cartes sur le web et la transparence des outils multiples au cours des prochains mois. Ensemble, ils montreront si Google a construit une interface d’assistant cohérente.

Pour l’instant, les utilisateurs mobiles peuvent tester directement l’hypothèse centrale. Sélectionnez une zone clairement délimitée, posez une question contrainte et comparez la réponse avec Google Maps.

Cette comparaison révélera davantage que la présence d’un nouveau bouton. Elle montrera si Gemini peut transformer un contexte géographique choisi en un résultat utile et vérifiable.