Prompt teardown : GPS, mémoire et Maps à partir d'une seule phrase

Plus personne ne doute qu'une IA génère du code capable — même « vibe codé », ça marche, et parfois très bien. La question intéressante n'est plus là. Elle est : une fois générée, qu'est-ce que cette section fait vraiment à l'intérieur de votre app ? Reste-t-elle un bloc isolé dans son coin, ou exploite-t-elle ce que le device et l'app savent déjà faire ? La façon la plus honnête d'y répondre, c'est de prendre un prompt et de le décortiquer, ligne par ligne.

C'est à ça que sert cette nouvelle rubrique. À chaque épisode, on prendra un prompt de la bibliothèque de l'AI Extension Builder et on le décortiquera : où il fait confiance à la plateforme, où il la force, et ce que la section obtenue sait vraiment faire. Pour commencer, l'un des prompts d'exemple de la bibliothèque : « où j'ai garé ma voiture ».

Voici le prompt le plus court qu'on puisse écrire pour ça :

C'est tout. Une phrase, pas un cahier des charges. Et voilà ce qui en sort :

Un bouton pour enregistrer sa position. Une section qui retrouve ce point à la réouverture de l'app. Un bouton pour repartir vers la voiture. Un lien discret pour effacer. Et, si on refuse la localisation, un écran qui l'explique au lieu de planter.

La surprise n'est pas que sept mots suffisent à dessiner un écran. C'est que cette section, née d'une phrase, exploite déjà les capacités du terminal : elle lit le GPS, elle garde une mémoire, elle ouvre Maps. On n'a demandé aucune de ces trois choses explicitement.

Voici le point qui compte, et il est facile à manquer. Pour obtenir la position GPS, la section ne s'adresse pas directement au téléphone. Elle passe par l'app qui l'héberge.

C'est l'app qui détient l'accès au GPS, et la section l'emprunte. La conséquence est simple et rassurante : la section n'a pas de permission à elle. Ce que l'app a le droit de faire, elle en hérite ; ce que l'app n'a pas le droit de faire, la section ne peut pas le forcer. Et quelles permissions l'app demande, au départ, c'est vous qui le décidez en tant que créateur de l'app : vous les déclarez dans le Privacy Center de l'app. Une section générée reste strictement dans ce cadre ; elle n'ouvre aucune porte dérobée à côté.

C'est exactement notre philosophie de guardrails : une section générée ne peut rien faire que l'app elle-même ne s'autorise pas. On ne vous laisse pas, par prompt, franchir une limite que vous n'avez pas décidé d'ouvrir. La même logique gouverne les deux autres capacités.

La mémoire. La section retrouve la position enregistrée après qu'on a fermé et rouvert l'app. Et cette persistance, on ne l'a pas réclamée : la plateforme la met en place d'elle-même dès qu'une section manipule des données de l'utilisateur. Mieux, elle fait la part des choses — une position de parking est une donnée simple, personnelle, attachée à l'appareil : pas besoin d'une base de données comme Supabase pour ça, un stockage sur le terminal suffit, et c'est ce qu'elle choisit. C'est toute la finesse : détecter quand un vrai backend est nécessaire, et quand l'appareil suffit. Garder ce qui doit être gardé, au bon endroit, est le comportement par défaut — pas une case à cocher.

Maps. Le bouton « repartir vers la voiture » n'affiche pas de map dans la section : il ouvre l'appli Maps du téléphone, directement sur les bonnes coordonnées. Une section générée n'est pas prisonnière de son écran ; elle sait déléguer à ce que le téléphone fait déjà bien.

Trois capacités — le GPS, la mémoire, Maps — et à chaque fois le même principe : la section ne fait pas cavalier seul, elle s'appuie sur l'app qui l'entoure. De l'extérieur, pour l'utilisateur comme pour vous, c'est un seul objet cohérent. C'est ça, le vrai sujet de cet épisode — pas le parking.

Ce qui rend ce premier exemple intéressant, c'est qu'on n'a rien demandé de tout ça. On n'a pas écrit « utilise le GPS natif », ni « garde les données », ni « ouvre Maps ». La section a pris ces chemins-là toute seule, parce que ce sont ceux de la plateforme.

Autrement dit : on ne mérite pas le bon comportement à coups de précision dans le prompt. Il est le point de départ. La question intéressante devient donc l'inverse : est-ce qu'on peut, par une formulation, quitter ce bon chemin ?

La réponse est oui. Et c'est là que le prompt long de la bibliothèque devient instructif.

Le vrai prompt de « où j'ai garé ma voiture », dans la bibliothèque, est plus détaillé. La plupart de ses phrases ne font qu'enrichir ce qu'on a déjà vu : un libellé précis, un horodatage « garé il y a 23 min », une confirmation avant d'effacer. Rien qui change la nature de la section.

Sauf une ligne. Le prompt réclame un itinéraire Google Maps, calculé depuis la position actuelle jusqu'à la voiture. Et là, la section quitte le chemin intégré.

La raison n'a rien de technique : on a nommé un service précis. Demander « Google Maps », c'est demander Google Maps — le service en ligne, avec son adresse web — et non « la map », qui aurait laissé la plateforme ouvrir celle du téléphone. La section est donc allée chercher ce service à l'extérieur de l'app. Et comme toute section qui s'adresse à un service extérieur, elle a dû en demander l'autorisation : la plateforme a affiché le domaine google.com et attendu votre feu vert avant de la laisser sortir. (Là encore, les guardrails : rien ne quitte le cadre de l'app sans votre accord explicite.)

On a obtenu exactement ce qu'on avait demandé. On a aussi quitté l'app pour le web et ajouté un domaine à valider. Ce n'est ni un bug ni une bonne ou une mauvaise nouvelle : c'est un échange, et autant le faire en connaissance de cause.

D'où la seule règle à retenir de cet épisode : décrivez le résultat que vous voulez, pas la façon de l'obtenir. La version courte, qui disait simplement « repartir vers la voiture », a laissé la plateforme choisir — et elle a ouvert la Maps du téléphone, sans rien aller chercher dehors. On ne nomme un service ou une techno précise que lorsqu'on a une raison que la plateforme, elle, ne peut pas connaître.

Si vous voulez partir de la version complète et la modifier, la voici — c'est celle de la bibliothèque, à un clic dans l'AI Extension Builder :

Build a "remember where I parked" helper. Show a big primary button labeled "Save my parking spot" that captures the device's current GPS coordinates and stores them persistently on the device. Once a location is saved, swap the UI to show the saved coordinates, a timestamp ("Parked 23 min ago"), and a second button "Find my car" that opens Google Maps directions from the user's current location to the saved spot. Include a discreet "Clear" link to forget the saved location. Handle the no-permission case gracefully with an explanation.

Le plus instructif n'est pas de copier ce prompt, c'est de le tordre. Remplacez la voiture par un vélo, un emplacement de camping, une place de marché. Enlevez la ligne Google Maps et regardez la section revenir d'elle-même à la Maps du téléphone. Changez « garé il y a 23 min » par autre chose et voyez le format suivre.

La bibliothèque en réserve d’autres à décortiquer de la même façon : un quiz ciné à partager, un clone de Flappy Bird jouable avec classement, ou une section qui exploite vos propres fichiers.

L'AI Extension Builder est en bêta, ouvert à tout le monde.

Une section générée par IA peut-elle utiliser le GPS du téléphone ?

Oui. Elle n'y accède pas directement : elle passe par l'app qui l'héberge, et hérite de la permission de localisation de cette app.

Est-ce que la section demande sa propre autorisation de localisation ?

Non. Elle s'appuie sur celle de l'app. Si l'app a l'accès, la section l'emprunte ; si l'app ne l'a pas, la section ne peut pas le forcer.

Une section générée peut-elle conserver des données après la fermeture de l'app ?

Oui. La plateforme met cette persistance en place dès qu'une section manipule des données de l'utilisateur, et choisit le bon niveau : un stockage sur l'appareil pour une donnée simple, un vrai backend quand c'est nécessaire.

Une section générée peut-elle ouvrir Maps ?

Oui. Elle ouvre l'appli Maps du téléphone, directement sur les coordonnées voulues.

Comment écrire un bon prompt pour une section d'app ?

Décrivez le résultat que vous voulez, pas la façon de l'obtenir. La plateforme choisit alors le chemin le plus intégré. Ne nommez un service ou une techno précise que si vous avez une raison particulière de le faire.