Consignes UX : annonce de App, renoncement à App et conduite dans le dialogue

1. Pourquoi piloter l’UX avec des consignes

Du point de vue de ChatGPT, votre App n’est qu’un ensemble d’outils et de widgets. Mais pour l’utilisateur, c’est une véritable interface à part entière qui surgit au milieu de la conversation. Sans piloter le comportement du modèle, on peut tomber dans deux scénarios extrêmes.

Dans un cas, GPT ignore App et tente de « tout résoudre avec des mots ». L’utilisateur demande de choisir un cadeau, et au lieu de lancer GiftGenius, le modèle produit un long essai textuel avec des recommandations « à sa façon ». Parfois ce n’est pas si mal, mais vous n’avez pas écrit App pour qu’il prenne la poussière sur l’étagère.

Dans l’autre cas, GPT, au contraire, abuse de App. Au moindre « Que sait faire votre service ? », il lance un widget, affiche un formulaire flou, l’utilisateur est intimidé et ferme tout ce bel attirail. Du point de vue UX, c’est très intrusif.

La logique est donc simple : il faut fixer explicitement le comportement, comme vous figez un schéma JSON d’un outil ou les props d’un composant React. Le system‑prompt (et les consignes associées) est ici votre « protocole UX ». Vous y décrivez quand et comment l’assistant :

• annonce le lancement de App ;
• s’abstient délibérément de lancer App et répond en texte ;
• se comporte une fois que le widget a déjà affiché un résultat ;
• respecte les demandes de l’utilisateur « sans applications ».

Tout cela ne concerne ni le marketing ni le ton de la conversation. Cela influence réellement la fréquence d’appel de votre App et le confort de l’utilisateur.

Nous allons détailler pas à pas : comment l’assistant doit annoncer le lancement de App, dans quels cas il vaut mieux ne pas proposer le widget, comment se comporter après que l’application a travaillé, comment respecter les demandes explicites de format de dialogue et comment formaliser proprement toutes ces règles dans le system‑prompt.

2. Annonce de App : comment le modèle doit « prévenir » l’arrivée du widget

Quand ChatGPT décide d’utiliser App, l’interface change : une carte de widget apparaît dans le chat, parfois en plein écran, des boutons et autres éléments d’UI s’affichent. Si l’assistant montre simplement le widget sans explication, l’utilisateur peut ne pas comprendre ce qui s’est passé ni d’où vient ce bloc.

La bonne pratique consiste donc à expliquer d’abord par du texte ce qui va se passer, puis seulement lancer App. C’est similaire à un navigateur qui demande : « Ouvrir une nouvelle fenêtre ? » ou à une application mobile qui avertit : « Nous allons maintenant vous demander l’autorisation d’accéder à la caméra ».

Types d’annonces

On peut distinguer schématiquement trois styles d’annonce.

Le premier — la proposition douce. L’assistant dit quelque chose comme : « Je peux ouvrir pour vous l’application GiftGenius, qui sélectionnera des cadeaux selon vos paramètres. L’ouvrir ? » puis attend « oui/non ». Cela fonctionne bien lorsque l’utilisateur découvre le service ou peut être sensible au changement d’interface.

Le deuxième — la recommandation sûre d’elle. Si votre App est l’interface principale du produit, vous pouvez écrire : « Je vais lancer maintenant l’application GiftGenius et afficher quelques options de cadeaux sous forme de cartes. » L’assistant peut toujours tenir compte d’un refus, mais par défaut il agit plus résolument.

Le troisième — la notification neutre. Dans ce cas, l’assistant se contente d’indiquer : « Je lance l’application GiftGenius pour sélectionner des cadeaux… », sans longues explications. Ce style est pertinent quand l’utilisateur a déjà vu votre App plusieurs fois et s’attend à son apparition.

Il est important d’ancrer ces variantes dans le system‑prompt. Le modèle ne fabrique pas des phrases UX à partir de rien si vous lui fournissez à l’avance l’ossature.

Mini‑exemple de code : section sur l’annonce dans le system‑prompt

Imaginez que votre template Next.js contient le fichier appDefinition.ts, où vous définissez le system‑prompt pour App :

// app/appDefinition.ts
export const systemPrompt = `
# Rôle
Tu es ChatGPT App GiftGenius, tu aides à choisir des cadeaux.

# Dialogue et UX — Annonce de l’application
Si tu décides de lancer le widget GiftGenius,
commence par expliquer en une ou deux phrases
qu’une application de sélection de cadeaux va s’ouvrir
et en quoi elle aidera l’utilisateur.
`;

Ce n’est pas encore un contrat complet, mais même un petit ajout de ce genre augmente fortement la prédictibilité du comportement.

Quand l’annonce est particulièrement importante

Plus votre UI est complexe, plus il est important d’annoncer son lancement. Si le widget montre simplement trois cartes de cadeaux, c’est un changement de contexte relativement doux. En revanche, si vous ouvrez un assistant multi‑étapes avec filtres, budget, catégories, etc., l’utilisateur doit comprendre pourquoi la conversation s’est soudain transformée en « mini application web dans le chat ».

Les directives UX officielles soulignent elles aussi que l’assistant doit relier explicitement le texte et l’UI, et non glisser silencieusement un widget dans la réponse.

3. Quand s’abstenir délibérément de proposer App

L’erreur la plus courante aux premiers stades de développement d’une App — l’effet classique « quand on a un marteau, tout ressemble à un clou ». Puisqu’on dispose d’un joli GiftGenius, le modèle tente de l’amener dans chaque dialogue. L’utilisateur demande : « Que sait faire votre application ? », et ChatGPT : « Je lance GiftGenius… », alors que la personne voulait simplement deux lignes d’explication.

Pour éviter cela, le system‑prompt doit décrire les situations où il vaut mieux ne pas proposer App. Ci‑dessous, quelques scénarios typiques.

• Premièrement, les questions de découverte. Si quelqu’un écrit « Que fait GiftGenius ? » ou « Comment travaillez‑vous ? », les consignes doivent exiger d’abord une brève explication textuelle, sans lancer l’UI. Ici, le widget ne ferait que distraire.
• Deuxièmement, une demande trop générale ou floue. L’utilisateur écrit « Parle‑moi des cadeaux populaires pour le Nouvel An » — c’est plutôt une question éducative qu’une sélection concrète. L’assistant peut expliquer brièvement des principes généraux, poser des questions de clarification, et seulement lorsque des paramètres concrets apparaissent (budget, destinataire, catégorie), proposer App.
• Troisièmement, les demandes hors du domaine de App. Si quelqu’un dit : « Aide‑moi à rédiger un CV », alors que votre App est conçue pour les cadeaux, le bon comportement est de répondre honnêtement comme un ChatGPT classique et de ne rien lancer. On peut mentionner prudemment à quoi sert App, mais il ne faut pas l’imposer lorsqu’il est manifestement non pertinent.
• Quatrièmement, refus explicite d’UI. Si l’utilisateur écrit : « N’ouvre aucune application, réponds simplement en texte », le modèle doit obéir, même s’il voit un scénario idéal pour App.

Tableau : type de demande et comportement de l’assistant

Compléter le system‑prompt avec les règles de refus de App

Poursuivons le même systemPrompt, en ajoutant un bloc sur les cas où App ne doit pas être lancé :

export const systemPrompt = `
# Rôle
Tu es ChatGPT App GiftGenius, tu aides à choisir des cadeaux.

# Quand NE PAS lancer le widget
Si l’utilisateur demande seulement ce que sait faire le service
ou pose une question théorique générale sur les cadeaux,
réponds d’abord en texte et ne lance pas l’application.

Si la demande n’est pas liée au choix de cadeaux,
réponds comme un ChatGPT classique et ne propose pas GiftGenius.

Si l’utilisateur te demande explicitement de ne pas utiliser d’applications,
respecte-le et reste dans le chat.
`;

Ce texte se transforme en décisions concrètes du modèle dans les situations limites, où sinon il « tirerait la couverture » vers l’UI. Nous avons fixé quand App n’est pas nécessaire. Il est maintenant important de décrire l’envers : que doit faire l’assistant lorsque le widget a déjà fonctionné et que l’utilisateur voit le résultat.

4. Comportement après l’utilisation de App : follow‑up et clôture du scénario

Dans le module sur le widget, vous avez déjà vu comment les messages de follow‑up aident à poursuivre le dialogue après l’exécution de l’UI. Le widget affiche des cartes, et en dessous l’assistant écrit quelque chose comme : « J’ai trouvé telles options de cadeaux pour un collègue avec un budget jusqu’à $50. Voulez‑vous que je montre des options moins chères ou que je change de catégorie ? » et propose des boutons d’actions populaires.

Notre tâche maintenant est de figer ce comportement dans les consignes, au lieu de compter sur « l’intuition » du modèle.

Ce que l’assistant doit faire après le widget

Dans le scénario idéal, plusieurs choses se produisent.

• D’abord, l’assistant résume brièvement en mots le résultat du travail de App. Même si le widget a montré dix cartes, il est utile d’écrire : « J’ai sélectionné 4 options de cadeaux pour un collègue avec un budget jusqu’à $50. Parmi elles : une tasse personnalisée, une plante de bureau, un coffret de bon café et un carnet élégant. »
• Ensuite, il propose les prochaines étapes. Des phrases de follow‑up préparées à l’avance aident ici : « Voulez‑vous voir des options moins chères ? », « Faut‑il affiner selon les centres d’intérêt ? », « Afficher uniquement ce qui est disponible dans votre région ? ». Ce sont précisément ces phrases que vous pouvez utiliser dans sendFollowUpMessage dans le widget, ainsi que recommander au modèle dans le system‑prompt.
• Enfin, si l’utilisateur clôt explicitement le scénario (« Merci, ça suffit »), l’assistant « ferme » délicatement le sujet : il reconnaît que la tâche est accomplie et propose son aide pour autre chose.

Diagramme de flux : question → widget → follow‑up

Pour plus de clarté, on peut représenter le comportement de l’assistant comme un simple automate à états.

flowchart TD
    U[L’utilisateur formule une demande] --> G[GPT décide : lancer l’App ?]
    G -->|Oui| A[Annonce le lancement de l’App]
    A --> W[Le widget GiftGenius propose des options]
    W --> S[L’assistant résume le résultat]
    S --> F[L’assistant propose des options de follow-up]
    F -->|L’utilisateur choisit une action| G
    G -->|Non, ne pas lancer l’App| T[Réponse textuelle sans UI]
    F -->|"L’utilisateur dit \"Merci\""| E[L’assistant clôt le scénario et propose une autre aide]

C’est ce flux que nous décrivons en fait par des mots dans le system‑prompt.

Exemple de code : follow‑up depuis le widget

Côté UI, vous savez déjà envoyer des messages de follow‑up. Pour être complet, voici un exemple simple de composant qui, après clic, demande au modèle « d’élargir le budget » :

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Montre des options avec un budget un peu plus élevé"
        );
    };

    return <button onClick={onClick}>Je veux des options plus chères</button>;
}

Nous allons maintenant ajouter dans le system‑prompt un texte qui suggère au modèle comment traiter ces messages de follow‑up.

// suite du systemPrompt
const followUps = `
# Comportement après le lancement de l’application
Après que le widget a affiché la liste des cadeaux,
décris brièvement le résultat en texte.

Propose ensuite 1 à 3 prochaines étapes claires
(par exemple : montrer des options moins chères, modifier le budget, changer de catégorie).
Si le widget envoie un message de follow-up,
utilise-le comme indication pour l’étape suivante.
`;

Techniquement, ce n’est qu’une chaîne de caractères. Côté UX, c’est la base d’un scénario prédictible.

5. Respecter les intentions de l’utilisateur

Tout ce que nous avons évoqué ci‑dessus correspond à vos attentes produit vis‑à‑vis du comportement de App. Les consignes UX fonctionneront mal si le modèle ne sait pas « écouter » l’utilisateur. Même une App parfaitement conçue doit s’effacer si la personne demande explicitement de ne pas changer le format d’interaction.

Quelques situations caractéristiques.

• Si l’utilisateur dit clairement qu’il ne veut pas lancer d’applications (« Aucune UI, explique simplement quoi acheter »), l’assistant doit considérer cela comme une contrainte stricte et ne pas essayer de la contourner. On peut répondre poliment : « D’accord, je répondrai uniquement en texte », et s’y tenir ensuite.
• Si l’utilisateur craint qu’un lancement automatique se produise, il est utile de lui donner un sentiment de contrôle. Par exemple : « Je peux ouvrir une application pour sélectionner des cadeaux, mais si vous préférez, nous pouvons en discuter simplement dans le chat. Qu’est‑ce qui vous convient le mieux ? » Vous offrez ainsi un choix explicite.
• Si l’utilisateur écrit « Je suis sur téléphone, n’ouvre pas de formulaires compliqués », cela fait aussi partie du contexte. L’assistant doit l’accepter et, par exemple, se limiter à une courte liste d’idées et à des questions de précision.

Intégrer le respect dans le contrat

Tout cela peut être reflété de manière concise dans le system‑prompt :

export const respectBlock = `
# Priorité aux intentions de l’utilisateur
Tiens toujours compte des demandes explicites de l’utilisateur
concernant le format d’échange.

S’il demande de ne pas lancer d’applications ou de widgets,
ne propose ni ne lance GiftGenius,
même si cela aiderait à résoudre la tâche.
Aide plutôt en texte.
`;

Vous définissez ainsi clairement « qui est le patron » dans le dialogue. Spoiler : ce n’est pas votre fierté pour une belle UI, mais la personne de l’autre côté de l’écran.

6. Comment rédiger les consignes UX dans le system‑prompt et dans la documentation

Nous avons déjà accumulé pas mal de règles de comportement — de l’annonce de App aux messages de follow‑up et au respect du format de dialogue. Il est maintenant important non seulement de ce que nous disons au modèle, mais aussi de la manière dont c’est rédigé dans le system‑prompt et la documentation.

Un system‑prompt dans une App réelle grossit vite. Si vous l’écrivez comme un texte littéraire continu, au bout d’une semaine plus personne ne s’y retrouvera. Traitez‑le comme une spécification technique ou un README : structurez‑le.

Une bonne pratique consiste à diviser le prompt en plusieurs sections logiques avec des titres. Par exemple : « Rôle et périmètre de responsabilité », « Quand utiliser App », « Quand ne pas utiliser App », « Dialogue et UX », « Sécurité et limitations ». À l’intérieur de chaque section, écrivez avec des formulations simples et univoques.

Encore mieux : extraire le system‑prompt dans un fichier séparé à côté du code, plutôt que de le coincer dans une chaîne littérale au milieu d’un composant. Ce sera plus facile à relire, comparer et discuter avec les chefs de produit ou les juristes.

Exemple d’organisation du system‑prompt dans le code

Une option consiste à conserver les parties du prompt dans des chaînes séparées et à les assembler en un tout :

// app/prompt/role.ts
export const roleSection = `
# Rôle
Tu es ChatGPT App GiftGenius.
Tu aides l’utilisateur à choisir des cadeaux en fonction de sa tâche et de son budget.
`;

// app/prompt/ux.ts
export const uxSection = `
# Dialogue et UX
Avant de lancer le widget GiftGenius,
explique brièvement qu’une application avec des cartes cadeaux va s’ouvrir.
Ne lance pas l’application pour des questions générales ou théoriques,
sauf si l’utilisateur demande explicitement une sélection.
Après le widget, résume le résultat en texte
et propose 1 à 3 prochaines étapes.
`;

// app/appDefinition.ts
import { roleSection } from "./prompt/role";
import { uxSection } from "./prompt/ux";

export const systemPrompt = `
${roleSection}
${uxSection}
`;

Ce découpage aide à considérer les consignes comme des modules distincts : partie UX, sécurité, travail avec les outils, etc. Cela sera particulièrement utile lorsque vous ajouterez de nouvelles fonctionnalités et devrez aligner le comportement avec plusieurs équipes.

En outre, il est pertinent d’aligner la documentation de App (README interne, Confluence, Notion) avec ces sections. Vous pouvez y expliquer en langage naturel pourquoi vous annoncez App de telle manière et pourquoi vous ne la lancez pas pour les requêtes d’essai. Fixez séparément quelles doivent être les répliques de follow‑up. Ainsi, les nouveaux venus dans l’équipe n’essaieront pas de « réparer » le prompt sans comprendre ce que vous faites.

7. Pratique : réécrire la partie UX pour notre GiftGenius

Assemblons tout dans un exemple de system‑prompt plus ou moins cohérent. Supposons que nous avions un system‑prompt très minimaliste :

export const systemPrompt = `
Tu es l’application GiftGenius.
Sélectionne des cadeaux pour l’utilisateur.
`;

Ce texte ne dit rien sur quand lancer App, comment l’annoncer ni quoi faire après le widget. Ajoutons les consignes UX pas à pas.

Indiquons d’abord clairement le périmètre et le format de travail :

const role = `
# Rôle
Tu es ChatGPT App GiftGenius.
Ta mission est d’aider l’utilisateur à proposer 3–7 cadeaux pertinents
pour un budget, un destinataire et une occasion donnés.
Tu peux utiliser le widget GiftGenius pour une sélection visuelle.
`;

Décrivons ensuite comment annoncer le lancement :

const announce = `
# Annonce de l’application
Si tu estimes que le widget GiftGenius aidera davantage,
explique d’abord en une à deux phrases
qu’une application avec des cartes cadeaux va s’ouvrir
et que l’utilisateur pourra les parcourir et les filtrer.
Lance l’application seulement après.
`;

Ajoutons les règles pour ne pas lancer App :

const noApp = `
# Quand ne pas utiliser l’application
Si l’utilisateur demande seulement ce que sait faire le service
ou souhaite des informations théoriques générales sur les cadeaux,
réponds en texte et ne lance pas GiftGenius.

Si la demande ne concerne pas les cadeaux (par exemple, un CV ou du code),
réponds comme un ChatGPT classique et ne propose pas l’application.

Si l’utilisateur demande de ne pas utiliser d’applications,
considère cela comme une contrainte obligatoire.
`;

Et terminons avec le comportement après l’utilisation du widget :

const afterWidget = `
# Comportement après le widget
Après que le widget a affiché des options de cadeaux,
décris brièvement le résultat avec tes mots.
Propose à l’utilisateur 1 à 3 prochaines étapes
(par exemple : modifier le budget, filtrer par centres d’intérêt,
afficher uniquement des options moins chères).

Si le widget a envoyé un message de follow-up,
utilise-le comme signal principal pour l’étape suivante.
`;

Le system‑prompt final peut ressembler à ceci :

export const systemPrompt = `
${role}
${announce}
${noApp}
${afterWidget}
`;

Cela ressemble déjà à une spécification de comportement, et non à un « voeu pieux ». Dans les prochains modules, vous compléterez ce contrat avec des consignes sur la sécurité, les hallucinations, la monétisation et autres joies de la vie d’une App mature, mais la partie UX sert déjà de fondation.

8. Erreurs typiques lors du paramétrage des consignes UX

Erreur n° 1 : « App est toujours meilleure que le texte ».
Parfois, les développeurs sont si fiers de leur widget qu’ils exigent du modèle qu’il l’appelle à la moindre occasion. Résultat : l’utilisateur reçoit App même là où il voulait juste demander « ce que c’est ». Le modèle devient intrusif, et les gens commencent à ignorer l’application. La bonne approche consiste à préciser explicitement les scénarios où App n’est pas nécessaire, et à respecter ces cas.

Erreur n° 2 : absence d’annonce explicite avant de lancer App.
Si l’assistant lance le widget en silence, l’utilisateur ne comprend ni d’où vient le bloc UI ni quoi en faire. Les guidelines d’OpenAI et l’expérience pratique montrent : une à deux phrases « j’ouvre maintenant une application qui fera X » améliorent nettement l’UX et réduisent la confusion.

Erreur n° 3 : proposition trop agressive et répétée de App.
Il arrive que App propose de relancer le widget après chaque réponse : « Voulez‑vous rouvrir l’application ? Et maintenant ? Et là ? ». Cela se transforme vite en spam. Il vaut mieux préciser dans les consignes qu’après la première utilisation de App, il faut regarder le contexte : ne la reproposer que si l’utilisateur change clairement les paramètres de la tâche ou demande lui‑même à « en voir plus ».

Erreur n° 4 : ignorer un refus explicite des applications.
Des phrases comme « seulement sans applications, s’il vous plaît » ou « je suis sur mobile, les formulaires c’est compliqué » doivent être perçues comme des contraintes strictes. Si le modèle continue à imposer App, l’utilisateur perd confiance à la fois dans l’assistant et dans votre produit. Dans le system‑prompt, cela se fixe facilement en deux ou trois phrases, mais beaucoup oublient de le faire.

Erreur n° 5 : absence de résumé et de messages de follow‑up après le widget.
Parfois, le widget affiche honnêtement des options, puis l’assistant se tait. L’utilisateur voit l’UI, mais ne sait pas quoi faire ensuite. Aucun texte, aucune question, aucun bouton d’action populaire. Ce scénario paraît inachevé et casse la continuité du dialogue. Précisez toujours dans les consignes qu’après le widget, il doit y avoir un bref résumé textuel et 1 à 3 prochaines étapes claires.

Erreur n° 6 : mélanger l’UX produit et le « style général de ChatGPT » dans le même paragraphe.
Il arrive que le system‑prompt se transforme en un long texte romanesque : « Sois amical, utilise des émojis, plaisante parfois si c’est pertinent. Et, au fait, lance peut‑être App de temps en temps. » Dans un tel texte, il est très difficile de remarquer les vraies règles UX. Il vaut mieux isoler des sections claires avec des titres nets : « Rôle », « Dialogue et UX », « Quand utiliser App », « Quand ne pas utiliser App ». Cela aide autant le modèle que les personnes qui travailleront sur ce prompt après vous.