Lignes directrices UX d’OpenAI : quand afficher App et comment ne pas « prendre le contrôle » du dialogue

1. Chat‑first : ChatGPT est d’abord un chat, ensuite des applications

Au cours des 6 premiers modules, nous avons couvert tous les aspects de l’application : de l’UI et MCP au débogage et au déploiement. Maintenant, nous allons refaire le tour, mais plus en profondeur. Vous ne pensiez tout de même pas que ce serait si simple, n’est‑ce pas ?

Commençons par l’UX, plus précisément par les exigences UI officielles et les lignes directrices UX. Vous voulez que votre application passe la revue, n’est‑ce pas ? Parfait, commençons par l’essentiel : le principal changement de mentalité nécessaire à un front‑end habitué à SPA/Next.js : ChatGPT est avant tout une interface de dialogue, et la App est l’invitée dans ce dialogue. Pas l’inverse.

OpenAI formule cela ainsi dans ses guidelines : les applications étendent ce que l’utilisateur peut faire sans casser le flux de la conversation. Un widget n’est pas un nouvel onglet du navigateur, mais une insertion soignée dans le chat qui apporte de la structure là où le texte seul devient pénible.

Le plus simple est de s’en souvenir via une répartition des rôles.

Les rôles de GPT et de App

Dans ChatGPT, il y a deux « personnages » :

GPT reste le narrateur principal. Il explique avec des mots ce qui va se passer, pourquoi il propose la App, ce que signifient les boutons, et il résume le résultat du widget. De son côté, la App se concentre sur la partie visuelle et les actions : sélection d’options, réglage des filtres, progression d’un assistant pas à pas.

Règle très importante à répéter comme un mantra : toutes les décisions importantes doivent être explicitement formulées dans la réponse textuelle de GPT, même si l’utilisateur clique dans l’UI. L’utilisateur n’est pas obligé de lire chaque ligne de l’interface du widget — les conséquences clés (par exemple « nous avons passé la commande » ou « vous avez choisi ces paramètres ») doivent être énoncées dans le chat.

2. Quand une App est vraiment utile : critères d’affichage

D’un point de vue technique, vous pouvez invoquer un widget à chaque message. Mais d’un point de vue UX — c’est comme ouvrir une boîte de dialogue plein écran à chaque caractère saisi dans un input. Ça marche — oui. Vivre avec — non.

OpenAI et l’Apps SDK proposent un principe simple : une App est pertinente quand elle simplifie la réflexion par rapport au seul texte.

Requêtes structurées et scénarios répétables

Une App est très adaptée lorsque la requête suggère déjà une structure :

• « Propose 5 idées de cadeaux pour un collègue jusqu’à 50 $ ».
• « Compare ces trois forfaits. »
• « Établis un itinéraire de 3 jours à Tokyo. »
• « Affiche ma liste de tâches pour la semaine et aide à définir les priorités. »

Dans tous ces cas, il y a des entités évidentes (cadeaux, forfaits, jours d’itinéraire, tâches) à manipuler, et des étapes : choisir, filtrer, comparer, confirmer. Ici, une UI avec cartes, cases à cocher et filtres est justifiée, voire salvatrice.

Exemples pour GiftGenius

Prenons notre héros favori, GiftGenius. Voici une requête typique :

Il faut choisir des cadeaux pour 10 invités à un mariage, avec des budgets et des centres d’intérêt différents.

En texte brut, GPT peut énumérer 10 listes séparées, mais ce sera pénible à lire. Bien plus agréable :

• afficher un tableau des invités, budgets et centres d’intérêt,
• permettre de filtrer « moins cher/plus cher »,
• afficher un ensemble de cartes pour chaque invité.

Ici, l’App est pratiquement indispensable : trop d’entités et de paramètres pour rester uniquement en texte.

À l’inverse :

Quel cadeau offrir à mon frère pour 5000 ₽ ?

C’est une question simple en une étape. GPT peut répondre en texte avec 3–5 idées, et seulement si l’utilisateur demande « montre des options où je peux filtrer par loisir et âge », on peut passer en douceur à l’App.

Mini heuristique

Utile à garder en tête sous forme de tableau simple :

Nous détaillerons les modes inline et plein écran dans les prochaines leçons, mais on voit déjà : la App est un outil pour des tâches structurées et multi‑étapes, pas pour chaque « je suis triste, que faire ? ».

3. Quand une App gêne : mode « discuter » et réflexion

Nous avons vu dans quels cas une App simplifie la vie et aide à structurer le dialogue. Mais il y a l’envers de la médaille : il existe des situations où toute UI ne fait que gêner.

Parler autant de « dessinons une UI » entraîne souvent un réflexe : « oh, l’utilisateur a demandé quelque chose — déclenchons un widget ». C’est précisément là que, lors de la revue Store, vous pouvez perdre des points UX.

Il existe toute une classe de requêtes où une App est généralement nuisible :

1. L’utilisateur est en mode « discuter ». Il s’agit de réflexions philosophiques, de questions personnelles, de dilemmes de carrière, de conversations thérapeutiques. Dans ces scénarios, l’utilisateur attend un échange textuel, des questions de clarification, parfois de l’empathie. Insérer des cartes et des filtres s’apparente ici à une bannière publicitaire.
2. Questions introductives sur le service. Si quelqu’un écrit « Parle‑moi de ce que GiftGenius peut faire ? » — il veut un aperçu, pas une UI immédiate. Ici, GPT explique d’abord brièvement l’objectif de la App, peut‑être donne des exemples de requêtes, puis propose délicatement d’essayer le widget.
3. Questions théoriques générales. « Comment choisir des cadeaux pour des introvertis ? » ou « Comment fonctionne un programme de fidélité en magasin ? » — c’est un scénario d’apprentissage, pas transactionnel. GPT peut fournir une bonne réponse textuelle et, à la fin, ajouter discrètement : « Si vous le souhaitez, je peux ouvrir GiftGenius et proposer quelques options concrètes ».

Partout où l’UI n’apporte pas de nouvelle valeur et ne fait que dupliquer le texte, mieux vaut rester dans le chat. C’est cela, respecter l’intention de l’utilisateur, dont les gourous UX raffolent.

4. Comment proposer une App : auto‑launch contre « humble handoff »

Même si vous êtes convaincu que l’App est pertinente, la question « comment la lancer » demeure. Variante brutale : le widget s’ouvre en plein écran sans prévenir. Variante normale : GPT explique d’abord avec des mots ce qui va se passer et demande un accord, ou au moins prévient.

Dans la documentation UX des ChatGPT Apps, on distingue deux patrons : auto‑launch et suggestion (humble handoff).

Auto‑launch : quand l’utilisateur le demande explicitement

Auto‑launch est approprié quand l’utilisateur exprime explicitement son intention :

Lance GiftGenius.
Ouvre les paramètres de GiftGenius.
Affiche mon panier de cadeaux dans GiftGenius.

Les règles sont simples :

1. GPT écrit brièvement quelque chose comme « J’ouvre GiftGenius… ».
2. Le modèle invoque immédiatement l’outil / widget.

Le dialogue peut ressembler à ceci :

Utilisateur : Lance GiftGenius, je veux choisir un cadeau pour un ami.
GPT : J’ouvre l’assistant GiftGenius pour la sélection de cadeaux.
[Le widget GiftGenius apparaît en inline ou en plein écran]

L’auto‑lancement sans questions supplémentaires est justifié, car l’utilisateur a lui‑même demandé « d’ouvrir ».

Suggestion (humble handoff) : quand l’intention est implicite

Dans de nombreux cas, l’utilisateur ne connaît pas du tout votre application. Il écrit :

Je dois trouver quelque chose pour un collègue pour son anniversaire, le budget est serré.

Le bon patron ici :

1. GPT analyse la requête et comprend que la App peut aider.
2. GPT pose 1–2 questions de clarification ou propose directement l’App en texte.
3. Ce n’est qu’après un accord ou un signal explicite que le widget est lancé.

Exemple :

Utilisateur : Je dois trouver quelque chose pour un collègue pour son anniversaire, le budget est serré.
GPT : Je peux proposer des idées moi‑même ou ouvrir l’application GiftGenius pour filtrer par budget et centres d’intérêt. Préférez‑vous de simples conseils ou essayer l’application ?
Utilisateur : Allons‑y avec l’application.
GPT : J’ouvre GiftGenius pour sélectionner des options de cadeaux.
[Le widget apparaît]

Cette approche met en avant : l’initiative reste du côté de l’utilisateur, et la App est une option, pas une bannière imposée. Cela s’accorde bien avec le principe « Respect user’s intent » des guidelines UX.

Mini‑exemple de « classificateur d’intention » en TypeScript

Imaginons que, côté back‑end, vous classiez déjà approximativement la requête utilisateur (à ne pas confondre avec GPT lui‑même, c’est une logique auxiliaire) :

// Type simplifié d’intentions utilisateur
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Quel déclencheur pour l’App voulons‑nous utiliser
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "lance GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // requête implicite
  return 'avoid';                                // chat normal, sans App
}

Cette logique ne déclenche pas le widget en elle‑même — c’est plutôt une façon de formaliser votre approche UX. Ensuite, vous traduisez ces règles dans le system‑prompt et les descriptions de l’App, afin que le modèle se comporte dans le même esprit.

5. Comment ne pas « prendre le contrôle » du dialogue : bons et mauvais patrons

Dans la documentation d’OpenAI et les articles sur le design UX pour les ChatGPT Apps, il est clairement formulé ce qu’il ne faut pas faire : ne pas « voler » la conversation. Autrement dit, ne transformez pas le chat en canal de promotion de votre interface.

Antipatrons

Le plus douloureux — le « widget‑surprise ». L’utilisateur est en pleine conversation, et soudain, une application plein écran qu’il n’a pas demandée occupe tout l’écran. Le contexte est perdu, la sensation de contrôle aussi.

Autre travers fréquent — utiliser l’App comme publicité. Par exemple, l’utilisateur pose une question théorique, et le modèle répond : « Je vais d’abord ouvrir notre super widget, tout est expliqué dedans » et affiche une UI où la moitié n’est que marketing. Les guidelines officielles qualifient explicitement ces scénarios de « poor use cases ».

Troisième antipatron — des bascules fréquentes et inutiles entre UI et texte. Si, à chaque petite clarification, on lance et ferme l’App, le dialogue ressemble à une guirlande clignotante. L’utilisateur, surtout sur mobile, se fatiguera vite.

Bonnes pratiques

Dans tous les scénarios où vous ouvrez malgré tout l’App, essayez de suivre trois règles simples.

Premièrement, prévenez. Que GPT dise clairement qu’il va ouvrir l’application, et pourquoi. Par exemple : « Je vais ouvrir l’assistant GiftGenius pour afficher les options sous forme de cartes. » Ce sont 1–2 lignes qui changent totalement la perception de la transition.

Deuxièmement, expliquez quoi faire dans l’UI. Tous les utilisateurs ne sont pas habitués à une nouvelle interface. GPT peut ajouter : « En bas, vous verrez des cartes de cadeaux, vous pouvez changer de page et appuyer sur “En savoir plus” pour n’importe quelle option. » S’il y a quelque chose d’inhabituel dans le widget (par exemple, « Afficher encore N » ou des filtres non standard), mieux vaut l’annoncer avec des mots.

Troisièmement, résumez le résultat en texte. Après que l’App a effectué une action (sélectionné, calculé, envoyé), GPT doit expliquer brièvement : « J’ai trouvé 3 options de cadeaux. Les deux premières dans un budget jusqu’à 50 $, la troisième un peu plus chère mais avec une livraison rapide. Souhaitez‑vous affiner ? » C’est particulièrement important sur mobile et dans les scénarios vocaux : la personne peut ne pas regarder l’UI, mais elle entendra le résumé textuel.

6. Rôle du system‑prompt et des descriptions de l’App dans la gestion de l’UX

Vous avez déjà vu comment le system‑prompt définit la « personnalité » de l’App et comment le modèle utilise les outils. Ajoutons‑y maintenant des règles UX : quand proposer l’App, comment l’annoncer, quand s’en abstenir.

Que préciser dans le system‑prompt

Pour GiftGenius, le system‑prompt peut inclure une section « Dialogue et UX ». La documentation et les articles recommandent de décrire cela de manière structurée, par règles distinctes.

Exemple de fragment (pseudo‑code, mais très proche de la réalité) :

### Dialogue et UX

1. Si l’utilisateur donne des conditions de sélection du cadeau (pour qui, budget, occasion),
   pose d’abord 1–2 questions de clarification en texte.
2. Après les précisions, propose d’ouvrir l’App GiftGenius :
   "Je peux ouvrir l’assistant GiftGenius pour afficher des options de cadeaux. Ouvrir ?"
3. Si l’utilisateur demande explicitement "lance GiftGenius" ou "affiche la liste des cadeaux",
   réponds "J’ouvre GiftGenius..." et déclenche immédiatement l’App sans questions supplémentaires.
4. Si l’utilisateur demande de la théorie ou des conseils généraux (par exemple, "comment choisir des cadeaux"),
   réponds en texte et n’ouvre pas l’App tant qu’il ne le demande pas lui‑même.
5. Si l’utilisateur dit "n’ouvre pas l’application" ou "réponds simplement en texte",
   ne propose plus l’App par la suite dans ce dialogue.
6. Après le travail de l’App, résume toujours le résultat en texte (brièvement).

Ici, tous nos principes UX sont encapsulés : chat‑first, respect du refus de l’utilisateur, différence entre auto‑launch et suggest, résumé textuel obligatoire.

Comment s’aider avec des configs TypeScript

Dans les projets réels, il est pratique de stocker une partie de ces règles de manière structurée (pour éviter de chercher le texte dans les prompts à la main). Par exemple, on peut prévoir une simple config :

// Type fictif de config des déclencheurs UX de l’App
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

La config n’est pas lue par le modèle — elle vous sert, en tant que développeurs, à rassembler en un seul endroit les accords produit/design, puis à les transférer proprement dans le system‑prompt, les descriptions de l’App et la documentation.

7. Exemple : comment GPT annonce GiftGenius sans prendre la main sur l’échange

Relions tout cela à notre application. Imaginons que l’utilisateur écrive pour la première fois dans le chat :

Je cherche un cadeau pour un collègue, environ 3000 ₽, il aime les jeux de société.

Une bonne réponse du modèle (compte tenu de notre system‑prompt) pourrait ressembler à ceci :

Compris ! Précisons deux détails et je propose des idées.

Dites‑moi environ quel âge il a, et s’agit‑il plutôt d’un cadeau formel ou d’un proche ami ?

(Après votre réponse, je peux ouvrir l’assistant GiftGenius pour afficher des options sous forme de cartes.)

Après la clarification, GPT écrit :

Parfait, j’ai suffisamment d’informations.

Je vais ouvrir l’application GiftGenius — j’y afficherai plusieurs options de cadeaux sous forme de cartes, vous pourrez voir les détails et affiner par budget et type de jeu.

Et seulement ensuite — lancement de l’App. Pas de « surprise », tout est expliqué clairement.

Petit composant React « annonce de l’App » dans le widget

Côté code, le widget est généralement simplement rendu lorsqu’il est appelé. Mais vous pouvez inscrire dans son UI la philosophie de « ne pas prendre le dessus » sur le contexte, même s’il est déjà ouvert.

Par exemple, l’écran d’introduction de GiftGenius peut être très simple :

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Sélection de cadeaux avec GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Je vais afficher quelques options sous forme de cartes. Vous pourrez
        choisir celles qui vous plaisent, et ChatGPT expliquera les avantages et inconvénients.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        À tout moment, vous pouvez revenir au chat classique et poursuivre la discussion.
      </p>
    </section>
  );
}

Ce composant ne fait rien de « puissant » techniquement, mais d’un point de vue UX il est important : il rappelle que le chat est toujours là et que le rôle de GPT reste central.

Par la suite, c’est à partir de cet écran d’introduction que vous passerez aux cartes de cadeaux, aux assistants, etc., mais ce sera l’objet des prochaines leçons.

8. Pratique et exercices

Nous avons rassemblé ci‑dessus un ensemble de principes — chat‑first, respect des intentions de l’utilisateur, distinction entre auto‑launch et proposition de App. Pour ancrer l’approche « quand et comment afficher la App », il est utile d’imaginer des requêtes réelles et de distinguer explicitement où la App est nécessaire et où elle ne l’est pas. Pour la pratique à la maison, vous pouvez faire deux petits exercices.

Commencez par GiftGenius et imaginez 5–7 requêtes utilisateur. Pour chacune, répondez honnêtement :

• faut‑il proposer d’ouvrir immédiatement l’App ;
• faut‑il simplement mentionner l’App comme une option ;
• ou vaut‑il mieux ne pas lier la réponse à l’App du tout.

Par exemple :

1. « Offre quelque chose à ma femme pour notre anniversaire, budget jusqu’à 1000 $ » — très probablement, d’abord quelques questions de clarification en texte, puis proposer d’ouvrir l’App.
2. « Comment emballer un cadeau de manière originale ? » — question purement théorique, on peut se passer de l’App.
3. « Lance GiftGenius, je veux choisir des cadeaux pour toute l’équipe » — auto‑launch direct.

Deuxième exercice — le texte d’annonce du lancement de l’App. Essayez d’écrire 1–2 phrases courtes avec lesquelles GPT expliquera à l’utilisateur la transition vers l’App. Comparez différents tons : plus formel (« J’ouvre l’application GiftGenius… ») et plus convivial (« Essayons l’assistant GiftGenius — ce sera plus simple pour comparer les options »).

Vous apprendrez ainsi à penser non seulement comme développeur, mais aussi comme auteur du dialogue.

9. Erreurs fréquentes pour l’UX « quand afficher la App »

Erreur n°1 : Afficher l’App à toute évocation du sujet.
Extrême courante : si l’App concerne les cadeaux, tout mot « cadeau » dans le dialogue déclenche le widget. L’utilisateur demande « comment ne pas se tromper avec un cadeau pour son manager », et au lieu d’un conseil vivant, il reçoit une UI avec des cartes. C’est perçu comme de la pub et ignore l’intention réelle de l’utilisateur, ce qui contredit directement les guidelines UX officielles et le principe « Respect user’s intent ».

Erreur n°2 : Plein écran sans prévenir.
Le « widget‑surprise » qui occupe soudain tout l’écran — moyen sûr de gâcher l’expérience. C’est particulièrement gênant au milieu d’une longue conversation, quand l’utilisateur ne s’attend pas à une transition brutale du texte vers l’UI. Selon les guidelines d’OpenAI, ces scénarios sont une mauvaise pratique ; il faut toujours annoncer la transition et, si possible, demander un accord.

Erreur n°3 : L’UI à la place de la réponse.
Parfois, les auteurs de l’App se disent : « Pourquoi répondre en texte, nous avons une belle interface ! » Au final, GPT dit presque rien et toutes les « réponses » sont cachées dans le widget. L’utilisateur, surtout en mode vocal ou sur mobile, peut rater des détails importants. La bonne approche : l’UI complète la réponse, elle ne la remplace pas ; l’App montre les détails et options, GPT explique ce que cela signifie.

Erreur n°4 : Ignorer le refus explicite de l’App par l’utilisateur.
Si la personne dit explicitement « n’ouvre pas l’application » ou « réponds simplement en texte », l’App doit respecter cette règle stricte jusqu’à la fin du dialogue. Continuer à proposer l’App toutes les deux interactions — c’est comme une fenêtre intrusive « évaluez notre service ». Ces comportements dégradent l’UX et peuvent influencer la revue du Store. Le system‑prompt doit intégrer explicitement le respect du refus.

Erreur n°5 : Pas de distinction entre auto‑launch et « proposition ».
Quand un développeur ne distingue pas intentions explicites et implicites, soit il ne lance jamais l’App, même quand l’utilisateur le demande clairement, soit il la lance tout le temps, même quand l’utilisateur dit seulement « peut‑être que j’essaierai votre App un jour ». D’où l’auto‑ouverture « juste parce qu’un mot ressemble ». La formalisation des déclencheurs (auto / suggest / avoid) et une logique réfléchie dans le system‑prompt aident à éviter cette confusion.

Erreur n°6 : Absence totale de règles UX dans le system‑prompt.
Parfois, toutes les décisions UX ne vivent que « dans la tête de l’équipe », et le system‑prompt se limite à « Tu es l’assistant GiftGenius, aide pour les cadeaux ». Le modèle propose alors parfois l’App, parfois l’oublie, parfois l’ouvre au mauvais moment. Des règles UX écrites et structurées dans le system‑prompt et la documentation sont un artefact aussi important que le schéma JSON des outils.

Erreur n°7 : Vouloir « ajouter l’UX plus tard ».
Approche répandue — d’abord « faire fonctionner », puis penser à l’UX un jour. Avec les ChatGPT Apps, cela conduit à des patrons d’appel d’outils déjà figés, et il devient plus difficile de modifier le system‑prompt et le comportement de GPT. Mieux vaut intégrer au moins des guidelines UX de base dès le départ : chat‑first, respect du refus, critères clairs d’affichage de l’App et absence de « widgets‑surprise ». Tout le développement ultérieur (patrons inline, plein écran, voix) s’appuiera alors sur des bases saines.