Parcours utilisateur : comment GPT propose une App et appelle ses fonctions

1. Introduction

Imaginez que vous écriviez un service web classique. C’est simple : vous avez une URL /search, l’utilisateur clique sur un bouton, vous appelez le contrôleur searchController. Dans l’univers des ChatGPT Apps, l’utilisateur ne voit aucun /search. Il écrit un texte en langage naturel :

« Trouve un cadeau pour mon frère gamer jusqu’à 50 $ »

Et ensuite :

• le modèle décide : « Oh, c’est à propos de cadeaux, j’ai GiftGenius, qui sait le faire » ;
• GPT « appuie sur les boutons » tout seul — il appelle les outils de votre App ;
• il propose parfois à l’utilisateur : « Tu veux que j’ouvre GiftGenius et que je montre des options ? ».

Le changement clé : l’utilisateur exprime une intention, et c’est le modèle qui appuie sur les boutons. Sans comprendre ce flow, il est très facile de :

• écrire des outils avec des noms dénués de sens (run_func, doStuff),
• obtenir une App que le modèle ne propose jamais ou appelle à mauvais escient,
• créer un widget qui « surgit de nulle part » et casse le dialogue.

C’est pourquoi, dans cette leçon, nous construisons un modèle mental : comment GPT apprend‑il l’existence de votre App et à quels moments du dialogue il l’« insère ».

Insight : l’application est un plugin de ChatGPT

Contrairement aux applications sur téléphone ou aux mini‑apps de WeChat, les applications dans ChatGPT fonctionnent différemment.

ChatGPT décide lui‑même quand lancer votre application et quelle fonction appeler. Les applications dans ChatGPT peuvent intervenir activement (avec des limites) dans la logique du chat. Leur objectif principal et leur point fort — c’est d’étendre les capacités de ChatGPT lui‑même.

Si ChatGPT peut résoudre parfaitement le problème de l’utilisateur — il n’a pas besoin d’appeler votre application. Si ChatGPT ne peut absolument pas résoudre le problème — l’utilisateur n’en parlera probablement pas. Le cas idéal, c’est lorsque ChatGPT ne peut résoudre la requête de l’utilisateur que partiellement. Cela signifie qu’il y a des requêtes, nombreuses, mais un résultat insuffisant.

C’est précisément alors que ChatGPT appelle votre application et, ensemble, vous rendez l’utilisateur heureux. L’utilisateur devient plus heureux, et vous — plus riche.

2. Façons de lancer une App ChatGPT du point de vue de l’utilisateur

L’utilisateur n’a pas de bouton « appelle le serveur MCP et call_tool », mais il a un champ de texte et (parfois) un menu d’applications. De son point de vue, il existe deux schémas de lancement de base : explicite et implicite.

Lancement explicite (explicit)

Scénario où l’utilisateur choisit consciemment votre App.

Cas typiques :

• il trouve l’App dans le Store de ChatGPT et clique sur « Ouvrir » ;
• il choisit l’App dans le launcher (par exemple via le bouton + dans le champ de saisie (Composer)) ;
• il commence le message par le nom de l’application : « GiftGenius, trouve un cadeau… » — c’est ce qu’on appelle une named mention. Si le nom de l’App est au début du prompt, ChatGPT inclut automatiquement votre App dans le contexte de la réponse.

En mode explicite, le modèle sait dès le départ : l’utilisateur est venu pour travailler avec cette App en particulier. Donc :

• GPT appelle plus souvent et plus activement vos tools ;
• le widget UI de votre App peut tout à fait apparaître dès la première réponse ;
• GPT ignore plus rarement l’App pour répondre « par lui‑même ».

Exemple favori : l’utilisateur ouvre directement GiftGenius parce qu’il veut « jouer » avec la sélection de cadeaux. Il clique sur l’App dans la liste, et GPT affiche un message d’accueil du style :

« Bonjour ! Je suis GiftGenius, je peux vous aider à choisir un cadeau. Dites-moi pour qui et quel budget nous visons ? »

Puis il utilise activement vos outils de recherche.

Lancement implicite (implicit / suggested)

Scénario tout autre : l’utilisateur ne pense pas du tout à une App. Il écrit simplement dans un chat ordinaire :

« Trouve un cadeau d’anniversaire pour ma mère, elle aime le jardinage, budget jusqu’à 100 $ »

GPT analyse la requête et constate que :

• dans l’écosystème, il existe l’App GiftGenius, dont les outils sont décrits ainsi : « Use this when the user wants to get gift recommendations » ;
• les tâches et contraintes (cadeau, budget, centres d’intérêt) correspondent bien à cette App.

Dans ce cas, le modèle peut « s’insérer discrètement » avec une proposition :

« Je peux utiliser l’application GiftGenius pour sélectionner des idées de cadeaux concrètes et les afficher sous forme de cartes. L’ouvrir ? »

Si l’utilisateur accepte — GPT appelle l’outil nécessaire de l’App et, éventuellement, rend votre widget.

Important : vous n’écrivez jamais if (prompt.includes("cadeau")) openApp(). Le modèle prend la décision tout seul, en s’appuyant sur :

• le texte de la requête et l’historique du dialogue ;
• les métadonnées de vos outils (noms, descriptions, schémas de paramètres) ;
• l’état de connexion de l’utilisateur à l’App (authentifié ou non), utilisateur en entreprise ou non.

Vous n’influencez pas l’algorithme, mais la façon dont votre App et vos tools sont « décrits » au modèle.

Hybride : quand GPT clarifie puis propose l’App

Parfois, l’utilisateur écrit quelque chose de très général :

« Il me faut une idée pour un collègue, je n’ai aucune inspiration »

Le modèle comprend que GiftGenius peut aider, mais l’information est trop vague. Schéma fréquent :

1. GPT pose 1 à 2 questions de clarification en texte.
2. Ensuite, il propose de lancer l’App : « J’ai un outil de sélection de cadeaux. Voulez-vous que je l’ouvre et que je montre des options ? ».

C’est un bon UX : l’utilisateur n’a pas l’impression qu’on l’a « forcé à basculer dans une autre application ».

3. Discovery : comment GPT trouve votre App

Voyons maintenant tout cela du point de vue du modèle lui‑même.

Dans la documentation de l’Apps SDK, cela s’appelle Discovery — tous les moyens par lesquels l’utilisateur et le modèle découvrent votre App. Ce sont les requêtes naturelles dans le chat, le catalogue d’applications et des « points d’entrée » spécifiques comme le launcher.

D’où le modèle sait‑il que votre App existe

Lors de l’enregistrement, ChatGPT lance votre App, laquelle (via MCP) se décrit : elle énumère les outils disponibles avec leurs schémas — nom, description, schéma JSON des paramètres d’entrée. Les informations sur l’application devront être renseignées lors de l’enregistrement, et les informations sur les outils seront extraites par ChatGPT via la méthode MCP list_tools.

Le modèle ne voit pas votre code source, il n’a accès qu’à :

• le nom de l’outil (name) ;
• la description (description) ;
• la signature d’entrée (inputSchema).

C’est cela qui devient « l’API pour le modèle ». Si vous nommez l’outil run_func avec la description « Executes the function », le modèle ne comprendra pas quand l’appeler. Si vous le nommez suggest_gifts avec la description « Use this when the user wants gift ideas based on recipient, occasion and budget » — tout devient limpide.

Named mention et in‑conversation discovery

La spécification officielle de l’Apps SDK distingue deux mécanismes clés :

• Named mention — lorsque l’utilisateur commence un message par le nom de votre App. Dans ce cas, l’App sera presque à coup sûr chargée et utilisée dans la réponse.
• In‑conversation discovery — lorsque l’utilisateur écrit simplement une requête, et que le modèle décide s’il faut connecter l’App. Sont pris en compte :
  • le contexte de la conversation (historique des messages, résultats des tools précédents, préférences de l’utilisateur) ;
  • les mentions explicites de marque dans le texte ;
  • les métadonnées de vos tools — noms, descriptions, documentation des paramètres ;
  • l’état du « lien » — l’utilisateur est‑il connecté à l’App (authentifié, permissions requises accordées).

Le développeur influence ce processus de manière indirecte : via des métadonnées de qualité et des patterns UX, pas via des if/else dans le code.

Catalogue et launcher

Outre la voie conversationnelle, il existe aussi le Store à l’intérieur de ChatGPT et le launcher, accessible depuis le composer. Grâce à eux, les utilisateurs peuvent choisir explicitement une App, comme une application classique dans un magasin.

Pour nous, c’est important conceptuellement : quand nous concevons le flow de GiftGenius, nous devons garder à l’esprit que :

• certains passeront par le catalogue et se retrouveront immédiatement « dans » l’App ;
• d’autres ne navigueront jamais dans le catalogue et ne verront l’App que comme une proposition dans le dialogue.

Tout cela relève de la discovery de l’App elle‑même : les moments où le modèle décide s’il faut « monter » votre application et la proposer à l’utilisateur dans la conversation en cours.

4. Anatomie du cycle d’interaction : de la phrase au widget

Il est temps d’assembler tous les niveaux de la leçon précédente — de l’UI de ChatGPT et du widget jusqu’à l’Apps SDK et au serveur MCP — en un cycle logique compréhensible.

Schéma de haut niveau

Du point de vue du processus, le cycle ressemble à ceci :

sequenceDiagram
    participant U as Utilisateur
    participant G as ChatGPT (modèle)
    participant A as App / serveur MCP

    U->>G: Requête textuelle
    G->>G: Analyse de la requête + sélection des tools
    G->>A: Appel d’outil (call_tool)
    A-->>G: Réponse (données / structuredContent)
    G->>U: Réponse textuelle + (optionnel) widget de l’App

En langage humain :

1. L’utilisateur écrit un message dans ChatGPT.
2. Le modèle analyse la requête et le contexte actuel, puis décide :
   • de répondre lui‑même,
   • ou d’appeler un ou plusieurs outils.
3. Si un outil de votre App est choisi, ChatGPT forme une requête structurée (call_tool) et l’envoie au serveur MCP.
4. Votre backend (ou serveur MCP) exécute l’action : interroge une base de données, des API externes, ACP, etc., et formate le résultat.
5. Le résultat revient sous forme de données structurées (et, éventuellement, du JSON pour le widget).
6. Le modèle utilise ces données pour :
   • générer un texte compréhensible par l’utilisateur,
   • si nécessaire — afficher le widget de l’App directement dans la réponse.

Toute la planification multi‑étapes — « quand appeler quoi », « faut‑il poser une clarification », « faire un autre appel » — se situe côté modèle d’IA. L’Apps SDK et MCP ne font que fournir un contrat unifié pour les outils.

Où écrivons‑nous du code

Dans ce cycle, il y a trois points où vous écrivez réellement du TypeScript/du code :

1. Configuration de l’App et des outils — descriptions des tools (nom, description, schéma) et métadonnées de l’App (nom, icône, catégories). Dans votre projet, c’est probablement un fichier du type openai/app-config.ts.
2. Serveur MCP / backend — traitement de call_tool : accès à la BD, filtrage de produits, appels d’autres API, etc.
3. Widget (UI) — composant React dans une application Next.js, qui est rendu dans le chat et lit les résultats des outils via window.openai ou les hooks de l’Apps SDK.

Tout le reste — relève du modèle et de la plateforme.

5. GiftGenius en action : deux scénarios de parcours utilisateur

Passons à des scénarios plus concrets pour « voir » ce flow.

Scénario 1 : l’utilisateur ouvre GiftGenius explicitement

Scénario :

1. L’utilisateur ouvre le catalogue des Apps dans ChatGPT et trouve GiftGenius.
2. Il clique sur « Ouvrir ».
3. ChatGPT démarre la conversation déjà dans le contexte de GiftGenius.

Le dialogue ressemble à ceci :

Utilisateur :

Ouvre GiftGenius depuis le catalogue.
Et écrit : « Bonjour ! Je veux choisir un cadeau pour un ami »

GPT :

« Parfait, je vais vous aider à choisir un cadeau. Dites-moi pour qui, avec quel budget et pour quelle occasion vous cherchez ? »

À cette étape, GPT peut immédiatement appeler un premier outil, par exemple start_gift_session, pour initialiser une session dans votre backend (créer un panier temporaire, générer un sessionId, etc.).

Votre code côté serveur MCP peut ressembler à ceci (très schématique) :

// Pseudo-exemple TS futur : description de l’outil GiftGenius
const suggestGiftsTool = {
  name: "suggest_gifts",
  description: "Use this when the user wants gift ideas by recipient, occasion and budget",
  inputSchema: {
    type: "object",
    properties: {
      recipient: { type: "string" },
      occasion: { type: "string" },
      budgetUsd: { type: "number" },
    },
    required: ["recipient", "occasion", "budgetUsd"],
  },
};
    

Nous verrons en détail comment cela se déclare dans MCP/Apps SDK dans un module séparé ; l’idée importante ici : grâce à cette description, le modèle comprend que l’outil convient aux requêtes de « sélection de cadeaux ».

Après la réponse de l’utilisateur, GPT appelle suggest_gifts, reçoit de vous un tableau d’options, puis :

• rédige un résumé en texte ;
• intègre le widget GiftGenius, où l’on peut faire défiler et filtrer les cartes cadeaux.

Scénario 2 : l’utilisateur demande « trouve un cadeau » dans un chat ordinaire

Autre variante : l’utilisateur ne connaît pas du tout GiftGenius.

Il écrit dans un chat ordinaire :

« Il me faut un cadeau pour mon frère, il adore les jeux de société, 50 $ max »

À l’intérieur de ChatGPT, il se passe à peu près ceci :

1. Le modèle analyse la requête et la liste des outils disponibles.
2. Il voit l’outil suggest_gifts avec une description appropriée.
3. Il comprend que l’App GiftGenius est faite pour ce type de tâches.
4. Il vérifie si l’utilisateur a déjà installé cette application, s’il était authentifié et quelles permissions ont été accordées.

La suite peut varier :

• si la requête est suffisamment précise, GPT peut appeler silencieusement suggest_gifts et renvoyer une réponse avec le widget ;
• s’il manque quelque chose (p. ex., l’occasion ou l’âge), GPT peut d’abord demander une précision en texte, puis proposer l’App.

Cette flexibilité distingue les Apps d’une UI « rigide » à formulaires : le modèle choisit lui‑même quand utiliser des outils, et quand discuter.

6. Routage sémantique : « un LLM comme répartiteur »

Au niveau de la discovery, le modèle décide s’il faut connecter votre App à la requête courante. Mais ensuite, quand l’App est déjà « montée » et que ses outils sont connus du modèle dans la session, un second niveau intervient — le routage sémantique au sein de ces tools : par quel outil traiter la réplique suivante.

Dans un backend web classique, la route est choisie par URL : /checkout — on appelle alors le contrôleur de checkout. Dans les ChatGPT Apps, il n’y a pas de routage par URL, mais il existe un routage sémantique : le modèle compare le sens de la requête aux descriptions de vos outils.

En simplifiant, le processus est le suivant :

1. Au démarrage de la session, ChatGPT reçoit la liste des tools : leurs noms, descriptions, schémas.
2. Ces données sont intégrées aux instructions système du modèle.
3. Quand l’utilisateur écrit une requête, le modèle compare son sens aux descriptions d’outils : où est « la sélection de cadeaux », où est « la recherche d’hôtels », où est « construire un graphique ».
4. S’il trouve une bonne correspondance — il forme l’appel structuré de l’outil nécessaire.

Conclusion pratique majeure :

• la description de l’outil — c’est votre API pour le modèle ; relisez‑le encore une fois. Et encore.
• si vous écrivez « does stuff », le modèle ne comprendra vraiment pas quand l’appeler.

La documentation et les bonnes pratiques sur la discovery soulignent : traitez les métadonnées comme un travail de copywriting produit. Ce sont elles qui déterminent dans quelles conversations le modèle se souviendra de votre App.

7. Patterns de dialogue autour d’une App

Voyons maintenant des patterns UX typiques qui apparaissent quand GPT interagit avec une App au sein d’une même conversation. C’est important pour éviter de concevoir une App « en vase clos », sans comprendre le rôle de la partie GPT.

Tous les guides pratiques de l’Apps SDK distinguent plusieurs patterns caractéristiques :

« Assistant pas à pas » (The Wizard)

GPT guide l’utilisateur étape par étape, en s’appuyant souvent sur l’App.

Exemple avec GiftGenius :

1. GPT : « Dites‑moi, pour qui est le cadeau ? »
2. Utilisateur : « Mon frère, 25 ans, fan de jeux de société ».
3. GPT : « Quel budget ? »
4. Utilisateur : « Jusqu’à 50 $ ».
5. GPT appelle suggest_gifts, affiche les résultats dans le widget et écrit : « J’ai sélectionné plusieurs options, regardez la liste ci‑dessous ».

Dans ce pattern, l’App et son widget sont comme une couche visuelle au‑dessus d’un dialogue multi‑étapes. L’utilisateur écrit surtout du texte, et le widget aide à visualiser le choix.

« Widget adaptatif » (The Adaptive Widget)

Le texte reste le canal principal, et l’App se connecte ponctuellement pour des tâches spéciales : tracer un graphique, montrer un tableau, afficher des cartes produits.

Exemple :

• Utilisateur : « Compare trois options de cadeau : un jeu de société, un livre, une expérience ».
• GPT explique d’abord en texte les avantages et inconvénients.
• Puis il appelle un outil qui renvoie une liste de produits structurée, et rend un petit tableau ou des cartes.

Ici, l’App est un complément visuel, pas le « mode par défaut ».

« Agent invisible » (Invisible Agent)

L’App peut ne pas afficher d’UI du tout. Elle fonctionne « sous le capot » comme source de données :

• vous implémentez un MCP‑tool qui cherche des cadeaux dans votre BD ;
• GPT l’appelle, obtient la liste et en reformule les résultats en texte, sans aucun widget.

Cela ressemble à un « plugin sans UI » classique : l’utilisateur constate simplement que GPT connaît les prix et l’assortiment à jour.

Un tel pattern est utile pour une tool‑first App, où l’UI n’est pas critique.

8. Comment le flow influence le design de l’App

Comprendre le flow est important non seulement philosophiquement, mais aussi pour des décisions très pratiques : quels outils créer, comment les décrire, quand afficher un widget et quand il vaut mieux répondre en texte.

Principe « chat‑first »

Idée clé de l’écosystème : le chat est le principal canal d’interaction, et les composants UI — des auxiliaires.

Cela signifie :

• inutile d’essayer d’« entasser tout un site » dans un seul widget ;
• les widgets doivent aider là où le chat est peu pratique : sélection dans une liste, filtrage, comparaison, formulaires complexes.

Pour GiftGenius, cela veut dire :

• sélectionner une liste de cadeaux et laisser l’utilisateur « cliquer » sur les cartes ;
• visualiser des filtres (prix, catégorie, disponibilité) ;
• aider à passer commande (checkout) en quelques étapes claires.

En revanche, écrire de longues explications dans le widget — « comment choisir un cadeau pour une femme introvertie » — n’est pas une bonne idée ; c’est la tâche du chat.

Quand lancer l’App, et quand non

Autre conséquence : n’en faites pas une App « qui prend le contrôle du dialogue ».

Mauvais pattern :

• l’utilisateur conduit une discussion sérieuse ;
• l’App se lance et ouvre un énorme widget plein écran sans prévenir ;
• l’utilisateur est perdu : « où est passé mon chat ? ».

Mieux :

• commencer par tout discuter en texte, poser quelques précisions ;
• proposer ensuite d’ouvrir l’App si cela améliore réellement l’UX (comparaison, configuration, checkout).

Impact sur l’ensemble d’outils

Puisque le modèle choisit l’outil par la description, chaque outil doit :

• résoudre une tâche claire et unique ;
• être bien décrit dans le style « Use this when… » ;
• avoir des paramètres qui découlent naturellement des questions que GPT posera à l’utilisateur.

Pour GiftGenius, au lieu d’un gigantesque do_everything, il est plus logique d’avoir :

• suggest_gifts — sélection d’une liste d’options ;
• get_gift_details — détails pour un ID donné ;
• create_order — passage de commande.

Nous détaillerons la conception des outils dans le module 4, mais l’idée générale importe déjà : le flow du dialogue détermine les outils dont on a besoin.

9. Mini‑exemple : comment les descriptions des tools influencent le flow (ébauche TypeScript)

Petit extrait imaginaire de openai/app-config.ts, pour relier la théorie au code. Ne le prenez pas pour la syntaxe exacte du SDK (nous la verrons au module suivant) — l’idée des noms et descriptions nous intéresse ici.

// Fragment de configuration hypothétique de GiftGenius (code futur)
const tools = [
  {
    name: "suggest_gifts",
    description: "Use this when the user wants gift ideas based on recipient, occasion, and budget.",
    inputSchema: {/* ... */},
  },
  {
    name: "get_gift_details",
    description: "Use this when the user asks for more information about a specific gift from a previous list.",
    inputSchema: {/* ... */},
  },
];

Si vous remplacez suggest_gifts par run_func et la description par « Main function », GPT :

• comprendra moins bien pour quelles requêtes appeler cet outil ;
• proposera peut‑être moins souvent votre App en in‑conversation discovery ;
• aura plus de mal à relier les follow‑ups de l’utilisateur à une liste de cadeaux déjà affichée.

Inversement, de bons noms et descriptions augmentent la probabilité que votre App apparaisse au bon moment.

10. Erreurs courantes lors de la conception du parcours utilisateur

Erreur n° 1 : Attendre un contrôle total — « je déciderai moi‑même quand lancer l’App ».
Parfois, les développeurs pensent en termes « j’attraperai toutes les requêtes sur les cadeaux et je brancherai mon App ». Dans le monde des ChatGPT Apps, ce n’est pas ainsi : les décisions sont prises par le modèle. Il tient compte des descriptions des outils, du contexte du dialogue, de l’état des permissions et du degré de satisfaction de l’utilisateur vis‑à‑vis de l’appel de votre App en particulier.

Erreur n° 2 : Noms et descriptions d’outils dénués de sens.
Des outils nommés run, main, tool1 et décrits par « Calls the main function » créent la tempête parfaite : le modèle ne comprend pas quand les appeler, l’in‑conversation discovery fonctionne à peine, et votre App devient « invisible ». Une bonne description du type « Use this when the user wants… » avec un nom clair — est bien plus importante qu’on ne le croit.

Erreur n° 3 : Tenter de faire « tout et n’importe quoi » dans une seule App.
Si votre App « sélectionne des cadeaux, réserve des hôtels, calcule des impôts et affiche des chats » à la fois, le modèle ne pourra pas router les requêtes de manière fiable. Les recommandations officielles et les guides pratiques soulignent le principe « one clear job per tool/App » : mieux vaut plusieurs applications spécialisées qu’un méga‑monolithe.

Erreur n° 4 : Lancement agressif d’une UI lourde en auto‑start.
Le développeur adore son beau widget plein écran et veut l’afficher « à tout bout de champ ». Résultat : l’utilisateur a l’impression que le chat « se casse » et devient une application web étrange. Il est bien préférable que GPT commence par discuter en texte, pose des questions de précision et propose ensuite d’ouvrir l’App, en expliquant pourquoi cela améliore l’UX.

Erreur n° 5 : Ignorer le rôle de GPT comme couche UX.
On peut concevoir une App comme un SPA classique : tout faire dans le widget, et ChatGPT doit « se taire et ne pas gêner ». Mais cela ne fonctionnera pas. ChatGPT peut ne pas afficher votre widget, ou afficher un nouveau widget à chaque nouvel appel de tool. Vous voulez un produit performant — adaptez‑vous à la plateforme, n’attendez pas qu’elle s’adapte à vous.