Fiche et promotion : contenu, localisation, notes de version

1. La fiche comme partie du produit, pas « un formulaire pour la forme »

Un développeur qui arrive pour la première fois au Store perçoit souvent la fiche comme « encore un long formulaire à remplir avec quelque chose ». C’est un peu comme écrire un README dans un dépôt à trois heures du matin : « je réécrirai ça correctement plus tard ». Spoiler : on ne réécrit généralement pas.

Pour un ChatGPT App, la fiche est la première, et parfois la seule, chose que verra l’utilisateur avant d’appuyer sur « Try » ou de faire défiler. Le nom, le sous‑titre, la courte description, la liste de scénarios, l’icône — tout cela fonctionne comme une mini‑landing page.

En outre, la fiche influence non seulement les humains, mais aussi ChatGPT lui‑même. Les métadonnées (nom, catégories, description) participent aux mécanismes de découverte. Quand le modèle choisit quel App proposer à l’utilisateur pour une requête donnée, il s’appuie notamment sur les textes que vous avez écrits ici.

Les guidelines officielles exigent que le nom et la description de l’App soient clairs, précis et non trompeurs quant aux fonctionnalités. Pas de « nous sommes une IA magique qui fait tout » ni de « client officiel de X » si cela ne correspond pas à la réalité.

Autrement dit, à cette étape vous faites trois choses à la fois :

1. Vous expliquez à la personne pourquoi votre App existe.
2. Vous donnez des indices aux algorithmes du Store et de ChatGPT sur les situations où l’App est pertinent à proposer.
3. Vous établissez la confiance : vous promettez exactement ce que vous faites réellement, sans magie ni dark patterns.

2. Le squelette de la fiche d’un ChatGPT App

L’interface concrète du Store peut changer ses champs et son apparence, mais le squelette logique est presque toujours le même. Voici ce qui est typiquement nécessaire aujourd’hui pour un ChatGPT App avec widget UI :

Rappel du début du cours : les guidelines exigent des noms et descriptions clairs et honnêtes, sans se faire passer pour un « client officiel de quoi que ce soit ». Le tableau ci‑dessus décline cela en champs concrets de la fiche.

Tout cela semble un peu bureaucratique tant qu’on ne se met pas à la place de l’utilisateur. Vous ouvrez le Store, voyez plein de cartes, vous avez cinq secondes d’attention. En regardant GiftGenius, vous voulez comprendre tout de suite :

• cet App correspond‑il à mes besoins ?
• est‑il sûr et ne fera‑t‑il pas des choses bizarres avec mes données ?
• est‑il différent d’un simple dialogue avec ChatGPT ?

Votre fiche doit apporter ces réponses.

3. Nom et sous-titre : comment ne pas se tirer une balle dans le pied

Critères d’un bon nom

Le nom de l’App a plusieurs rôles à la fois : on le prononce dans une conversation (« lance GiftGenius »), on le tape dans la recherche, on le voit dans une liste. L’idéal est donc un nom qui :

• est court et mémorable ;
• transmet l’idée principale (GiftGenius → « quelque chose sur les cadeaux et l’intelligence ») ;
• ne viole pas les marques déposées d’autrui ;
• n’en promet pas trop et ne se fait pas passer pour un client officiel d’une plateforme.

Les mêmes guidelines d’OpenAI évoquées au début interdisent explicitement les noms trompeurs, y compris les insinuations d’officialité que vous n’avez pas.

Voyons des exemples pour notre GiftGenius.

Dans ce cours, nous continuons d’utiliser GiftGenius comme nom principal. Si vous créez votre propre App, n’ayez pas peur d’un léger branding : « TripTailor », « StockScout », « LegalChecklist », etc.

Sous-titre : une phrase qui fait tout le travail

Le sous‑titre est votre « one‑liner ». Il est visible dans les résultats du Store et sur la page de l’App. Les guidelines officielles recommandent que ces textes expliquent clairement et honnêtement la finalité de l’App.

Mauvaise variante :

"L'assistant IA idéal pour toutes les tâches !"

Bonne variante :

"Aide à trouver un cadeau en 30 secondes selon les centres d'intérêt, directement dans le chat."

Un bon sous‑titre :

• indique quel résultat l’utilisateur obtiendra ;
• évoque le contexte (dans notre cas — « directement dans le chat ») ;
• n’entre pas dans les détails techniques (« analyse des vecteurs d’embedding » n’intéresse personne).

Pour pratiquer, il est utile d’écrire 5–7 variantes et de les relire avec les yeux d’un non‑technique. Si vous butez vous‑même en lisant le texte à voix haute — réécrivez‑le.

4. Description : courte et longue, avant/après

Description courte

La description courte se compose généralement de deux phrases et s’affiche à côté du sous‑titre. C’est souvent votre dernière chance d’accrocher un utilisateur qui n’a pas envie d’ouvrir les détails.

Structure :

1. Première phrase — ce que fait l’App.
2. Deuxième — en quoi il diffère d’un simple ChatGPT ou d’autres Apps.

Exemple « avant » pour GiftGenius :

"App pour la sélection de cadeaux. Utilise MCP et un backend complexe pour fournir les meilleurs résultats."

Problèmes :

• détails techniques superflus ;
• on ne voit pas en quoi vous êtes mieux que ChatGPT seul ;
• le scénario utilisateur n’est pas décrit.

Réécrivons :

"GiftGenius aide à choisir un cadeau selon les centres d'intérêt, le budget et l'occasion. Vous répondez à quelques questions dans le chat et l’App affiche des idées concrètes avec des liens."

Ici, nous nous accrochons à l’expérience réelle de l’utilisateur : « je réponds aux questions → je vois des idées ». Ce texte aide aussi ChatGPT à mieux comprendre vos scénarios typiques.

Description longue

La description longue est lue par des personnes déjà motivées, mais même elles ne veulent pas plonger dans un traité technique. Un bon canevas :

1. Qui est la cible (par exemple, « celles et ceux qui détestent choisir un cadeau à la dernière minute »).
2. Quelles tâches l’App résout (2–3 scénarios principaux).
3. En quoi l’App est plus pratique que de poser la question à ChatGPT sans App.
4. Quid des données et de la sécurité — très bref, avec renvoi à la Politique.
5. Langues/régions, s’il y a des restrictions.

Pour GiftGenius, un exemple de canevas :

GiftGenius s'adresse à celles et ceux qui se rappellent du cadeau au dernier moment. 
L’App demande pour qui vous choisissez un cadeau, votre budget et l’occasion, puis affiche une liste d’idées avec descriptions et liens.

Contrairement à un dialogue classique avec ChatGPT, GiftGenius utilise votre catalogue produit et les prix à jour, et il se souvient de l’historique des sélections dans le cadre de la conversation.

L’App ne conserve pas votre conversation plus longtemps que nécessaire pour proposer des recommandations. Plus de détails — dans notre Politique de confidentialité.

L’essentiel — ne transformez pas la description en décharge de termes d’architecture. Sous le capot il y a MCP, Agents, du cache, des feature flags, mais à l’utilisateur importe le scénario : plus vite, plus simple, plus fiable.

5. Captures, vidéo, icône et visuel

Nous avons réglé les textes de la fiche. Passons à ce que l’utilisateur voit plutôt que lit : l’icône, d’éventuelles captures d’écran et une courte vidéo.

Où le visuel est-il visible pour un ChatGPT App

À l’horizon 2025–2026, les interfaces du ChatGPT Store pour les GPTs classiques n’affichent pas la « galerie de captures » habituelle des stores mobiles : on voit surtout l’icône, le nom, l’auteur et les invites de départ.

Pour les ChatGPT Apps avec widgets UI, la situation est similaire : la « vitrine » principale se trouve dans ChatGPT lui‑même (premier lancement de l’App, widget inline, etc.). Les captures externes, vidéos et le large habillage visuel vivent le plus souvent :

• sur une landing page dédiée de l’App ;
• dans des posts et annonces (« comment nous avons créé GiftGenius ») ;
• sur des plateformes comme Product Hunt, un README GitHub, etc.

Ainsi, quand on parle de « captures et vidéos pour la fiche », en pratique il s’agit de ressources externes vers lesquelles vous dirigerez depuis le Store, la documentation ou les réseaux sociaux.

Icône de l’App

L’icône est un détail jusqu’au moment où vous la voyez au milieu de dizaines d’apps. Principes de base :

• forme simple, lisible dans un petit disque (128×128) ;
• minimum de texte, idéalement aucun ;
• bon contraste avec le fond ;
• lien visuel avec le thème de l’App (cadeau, panier, analyse de graphiques, etc.).

Pour GiftGenius, une option logique — une boîte‑cadeau minimaliste sur fond contrasté, sans « GG » écrit en minuscule.

Captures d’écran : que montrer exactement

Quand vous faites une landing ou un article sur l’App, il vous faut des captures qui montrent :

• le scénario principal : l’utilisateur pose une question → le widget de recommandations apparaît ;
• le « moment wahou » : filtrage, choix d’un élément, éventuellement — intégration Instant Checkout (si présente) ;
• un minimum de détails superflus : on retire les PII, comptes de test plutôt que de vrais clients, interface propre.

Une bonne astuce pratique — constituer un « catalogue démo » séparé avec des produits fictifs et des noms soignés, pour ne pas exposer d’identifiants internes ni des marques tierces.

Courte vidéo

Un walkthrough court de 30–60 secondes peut être enregistré avec un simple outil de capture : ouvrir ChatGPT, saisir une requête typique, montrer comment l’App apparaît et comment interagir avec. En substance, vous rejouez un de vos golden prompts du module sur l’UX.

Scénario pour GiftGenius :

1. L’utilisateur écrit : « Il me faut un cadeau pour un collègue développeur, budget 50 $. »
2. ChatGPT propose GiftGenius.
3. Le widget apparaît avec des questions de précision puis — une liste d’options.

Une telle vidéo — excellent matériau à la fois pour la landing et pour un post sur les réseaux sociaux.

6. Localisation de la fiche : stratégies et pièges

Du visuel aux langues. Même si l’UI et les données sont déjà très bien localisées (ce que nous avons fait au module 9), la fiche a sa propre vie et il y a des pièges.

Pourquoi ce n’est pas si simple

Votre App peut très bien localiser l’UI et les données, utiliser openai/locale, _meta["openai/userLocation"] et autres astuces du module 9. Mais la fiche a sa propre vie.

À l’heure de 2025–2026, le ChatGPT Store ne bascule pas automatiquement le nom et la description de l’App selon la langue de l’utilisateur. Il n’y a donc pas de mécanisme « intégré » pour des métadonnées multilingues : le Store affiche un seul jeu de textes.

Il en découle trois stratégies populaires.

Stratégie 1 : Universal English

La variante la plus simple et la plus répandue — tout en anglais (nom et description). Dans le texte, vous pouvez indiquer explicitement les langues prises en charge par l’App :

"Supports English, Spanish, Russian."

Avantages : une seule fiche, maintenance simple, compréhensible pour la plupart du public tech. Inconvénient évident : conversion plus faible chez les utilisateurs peu à l’aise avec l’anglais.

Stratégie 2 : Nom hybride

Une tentative de ménager la chèvre et le chou : « GiftGenius | Cadeaux ». Un tel nom se lit par les anglophones comme par les francophones.

Avantage : plus de personnes comprennent intuitivement de quoi parle l’App. Inconvénient : aspect « bruyant », peut nuire au style global du Store, et ne résout pas la question de la description longue — il faudra quand même choisir une langue.

Stratégie 3 : Apps séparées par langue

Variante pour les projets d’envergure : créer, disons, « GiftGenius (RU) » et « GiftGenius (Global) » comme des Apps distinctes avec un backend MCP commun.

Avantages :

• on peut adapter complètement la description, les invites de départ et même le flow au marché local ;
• meilleur « SEO » dans le Store : un utilisateur écrivant en français verra un nom et une description compréhensibles.

Inconvénients :

• les statistiques d’usage et avis se répartissent sur plusieurs Apps ;
• plus de travail de maintenance : releases, fiches, revues pour chaque variante.

Conseil pratique

Pour un App d’étude/proof‑of‑concept, Universal English suffit généralement, surtout si le public principal est développeur. Dans un produit réel, un compromis raisonnable — commencer avec une ou deux langues et faire de bonnes traductions, au lieu de viser dix langues avec de la « salade de mots » machine.

Lien avec le module de localisation : vous savez déjà localiser l’UI et les données de façon flexible. Il faut maintenant que les textes de la fiche ne contredisent pas ce que l’utilisateur verra en réalité. N’écrivez pas « ne prend en charge que l’anglais » si l’App fonctionne déjà sereinement en espagnol.

7. Notes de version : à quoi elles servent et comment éviter « nous avons tout amélioré »

La fiche, c’est la première rencontre. Ensuite l’App évoluera, et il faut en informer les utilisateurs — les notes de version entrent en jeu.

Que sont les notes de version dans le contexte d’un ChatGPT App

Les notes de version — une brève description des changements d’une nouvelle version : ce qui a été ajouté, corrigé, accéléré. Dans les stores classiques, il existe un onglet « Version history ». Dans le ChatGPT Store actuel, cet onglet peut ne pas exister, donc les notes de version vivent :

• dans la description de la nouvelle version dans la console du Store ;
• sur votre site/blog/dépôt ;
• dans l’App lui‑même, si vous permettez à l’utilisateur de demander « quoi de neuf ».

Le format est généralement simple : nom de version, date et liste des changements clés.

Pourquoi y consacrer du temps

Premièrement, l’utilisateur voit que l’App est vivant : on y revient, on l’améliore, on corrige des erreurs. Cela augmente la confiance envers votre code et votre activité.

Deuxièmement, vous obtenez votre propre chronologie : pratique pour voir quand une fonctionnalité a été ajoutée, y faire référence en support ou « vendre » des mises à jour en interne.

Troisièmement, les notes de version — un matériau prêt pour une mini‑promotion : un e‑mail, un post sur les réseaux, une courte vidéo.

Comment écrire : vendre le bénéfice, pas les termes internes

L’expérience des stores mobiles et les recommandations de product people convergent vers une idée simple : décrivez les changements du point de vue du bénéfice pour l’utilisateur, pas des entités internes que vous avez modifiées.

Mauvais :

"v1.1 — refactor de l’algorithme de sélection, scoring amélioré, bugs corrigés."

Mieux :

"v1.1 — des recommandations plus précises pour des hobbies rares. 
GiftGenius comprend mieux les centres d’intérêt si vous mentionnez les jeux de société, le craft ou la musique. 
Nous avons aussi corrigé un bug rare à cause duquel la liste de recommandations se vidait parfois."

Ici, même la correction de bug est formulée comme une amélioration de fiabilité pour l’utilisateur.

Exemples pour GiftGenius

Première version :

v1.0 — lancement de GiftGenius
- Premières sélections de cadeaux par nom, centres d'intérêt et budget.
- Prise en charge USD/EUR.
- Localisation de l’interface : EN, RU.

Deuxième version :

v1.1 — cadeaux via photo et filtres par type
- Nouvel outil expérimental : vous pouvez téléverser une photo du bureau de la personne et GiftGenius proposera des idées pertinentes.
- Nouveau filtre "cadeaux 100% numériques" — pratique si la personne est dans une autre ville.
- Recherche dans le catalogue accélérée, la liste de recommandations s’ouvre plus vite.

Ce format se transforme facilement en texte pour le Store et en court post « quoi de neuf dans GiftGenius ».

8. Mini‑plan de promotion : faire un peu semblant d’être marketeur

Même une fiche parfaite et des notes de version soignées n’amèneront pas des utilisateurs toutes seules. Il faut un minimum de plan de promotion, réalisable par un développeur.

Le marketing complet — c’est un cours à part, mais sans promotion même le meilleur App va prendre la poussière dans le Store. Il nous faut un ensemble minimal d’actions que vous pourrez vraiment réaliser en tant que développeur.

« Promotion » interne dans l’écosystème ChatGPT

Premier point essentiel : une fiche bien écrite est déjà, en soi, une partie de la promotion. Les métadonnées et descriptions aident ChatGPT à proposer votre App dans des dialogues pertinents, et la recherche du Store à le trouver par mots‑clés.

D’où des actions pratiques :

• mentionner des scénarios typiques dans la description (achat de cadeaux, préparation de rapports, etc.) ;
• ne pas surcharger la fiche de jargon technique — cela rebute l’utilisateur ;
• éviter des promesses trop larges « pour tout et tous » afin de ne pas diluer le « SEO ».

Promotion externe : landing, réseaux sociaux, communauté

Les études sur le sujet recommandent un plan de promotion minimal simple pour les ChatGPT Apps :

1. Faire une courte vidéo de preview (30–60 secondes) montrant le scénario clé.
2. Écrire une note/un article de blog : « Comment nous avons créé GiftGenius » — avec quelques captures et une description d’architecture de haut niveau.
3. Faire 1–2 posts sur les réseaux (Twitter/X, LinkedIn, Telegram) avec un lien vers l’App ou la landing.
4. Demander à 5–10 collègues/amis d’essayer l’App et de donner un feedback honnête.

Important : ne devenez pas spammeur. Pas de « taguer tout le monde dans un tweet » ni « écrire dans tous les chats ». Bonne règle — chaque post apporte une vraie valeur (démo, explication d’architecture, analyse d’un cas intéressant).

Où publier les notes de version

Comme nous l’avons déjà mentionné, le Store peut ne pas proposer d’historique des versions. Il est donc pertinent de dupliquer les notes de version :

• sur la page de l’App dans le Store (si on peut y ajouter un texte pour la nouvelle version) ;
• sur votre site (section Changelog) ;
• dans le README du dépôt (si l’App est open‑source ou partiellement ouvert) ;
• dans une newsletter ou un canal pour les utilisateurs intéressés.

Il est pratique d’utiliser une même structure « source » définie dans le code ou la config, puis de la rendre sur différents canaux.

Exemple tout simple en TypeScript :

// shared/releaseNotes.ts
export const releaseNotes = [
  {
    version: "1.0.0",
    date: "2025-02-01",
    changes: [
      "Première version publique de GiftGenius",
      "Sélection de cadeaux selon centres d'intérêt et budget",
    ],
  },
  {
    version: "1.1.0",
    date: "2025-03-10",
    changes: [
      "Nouveau filtre « cadeaux 100% numériques »",
      "Recherche dans le catalogue accélérée",
    ],
  },
];

Ce tableau peut être utilisé dans le widget (réponse à « quoi de neuf ? ») et pour générer la page Changelog sur votre site.

9. Vue d’ensemble : fiche GiftGenius en exemple

Pour relier le tout, esquissons une fiche « brouillon » pour notre App pédagogique.

Version texte

Nom :
GiftGenius

Sous-titre :
Sélectionne des cadeaux en 30 secondes selon centres d’intérêt et budget, directement dans le chat.

Description courte :
GiftGenius pose quelques questions sur la personne, le budget et l’occasion, et affiche une liste d’idées prête à l’emploi avec descriptions et liens. Idéal quand il reste une soirée avant la fête.

Description longue (version abrégée) :

GiftGenius aide celles et ceux qui en ont assez de se creuser la tête pour des cadeaux à la dernière minute. 
L’App demande pour qui vous choisissez le cadeau, ce qui intéresse la personne et votre budget, 
puis affiche des idées concrètes avec une courte description et un lien pour l’acheter.

GiftGenius tient compte de votre catalogue et des prix à jour, donc les recommandations collent mieux au réel 
qu’un simple conseil générique dans le chat.

L’App prend en charge les interfaces en anglais et en russe. 
Nous n’utilisons pas vos données pour entraîner des modèles tiers et nous conservons l’historique des sélections uniquement pendant une session. 
Plus de détails — dans notre Politique de confidentialité.

Invites de départ :

• « Help me find a birthday gift for a colleague who loves board games, budget $40. »
• « Trouve un cadeau pour ma mère qui aime le jardinage, jusqu’à 3 000 ₽. »
• « Suggest digital-only gifts for a friend who lives abroad, budget €50. »

Icône : une boîte‑cadeau minimaliste dans les couleurs de la marque.

Langues : EN, RU (explicitement indiqué dans la description, et l’UI sait déjà basculer via openai/locale).

Liens :
Privacy Policy, Terms of Use, Support page — nous avons fait tout cela à la leçon précédente.

Schéma : parcours utilisateur, de la fiche à l’usage

Pour la clarté — un petit diagramme :

flowchart TD
    A[Fiche GiftGenius dans le Store] --> B[L’utilisateur lit
le nom et la description]
    B --> C{Comprend-il
la valeur de l’App ?}
    C -- Oui --> D[Clique sur Try / active l’App]
    C -- Non --> E[Passe son chemin]
    D --> F[Premier dialogue avec ChatGPT]
    F --> G[Le modèle propose GiftGenius
selon le contexte de la requête]
    G --> H[Le widget apparaît
et le scénario de sélection de cadeaux]

Une bonne fiche augmente la probabilité que l’utilisateur prenne la branche « Oui » et, à l’étape G, sache déjà à peu près à quoi s’attendre de l’App.

10. Erreurs typiques lors de la fiche et de la promotion

Erreur n° 1 : le nom et le sous‑titre promettent une magie qui n’existe pas.
Écrire « Ultimate AI that does everything » est tentant, mais cela frappe sur deux fronts. L’utilisateur s’attend à un super‑assistant universel et obtient un outil spécialisé. La modération du Store peut poser des questions : ces affirmations correspondent‑elles au comportement réel et à la politique ? Les guides exigent clairement des formulations claires et précises sans exagérations.

Erreur n° 2 : la description est noyée sous les détails techniques.
« Utilise MCP, Agents SDK, cache sur couche edge » — parfait pour une présentation à un meetup, mais totalement inutile dans une fiche. À l’utilisateur importent les scénarios et le résultat : plus vite, plus simple, plus fiable. Gardez les détails techniques pour un billet de blog « comment nous l’avons fait ».

Erreur n° 3 : ignorer la localisation de la fiche.
L’App localise très bien l’UI et les données, mais la fiche est laissée avec une mauvaise traduction automatique ou uniquement en anglais pour un marché où la majorité ne lit pas l’anglais. Résultat : vous perdez de la conversion avant même le premier lancement. Mieux vaut une ou deux langues avec un bon texte que dix langues en charabia.

Erreur n° 4 : l’icône et le visuel faits à la dernière minute « à l’arrache ».
Des détails trop complexes, du texte illisible dans un petit disque, ou une icône grise qui se perd parmi les autres. L’utilisateur n’enregistre tout simplement pas que c’était votre App. Passez quelques heures sur une icône propre et des captures claires : vous les utiliserez longtemps dans des articles, des slides et sur les réseaux sociaux.

Erreur n° 5 : des notes de version façon « bug fixes and improvements ».
Oui, tout le monde écrit ça, mais vous pouvez faire mieux. Si vous‑même, dans un mois, ne comprenez pas ce qui a changé en 1.3, l’utilisateur ne comprendra pas non plus. Décrivez les changements en termes de bénéfice : ce qui est plus rapide, plus fiable, quels nouveaux scénarios sont apparus. Court, mais concret.

Erreur n° 6 : absence d’annonce externe.
L’App est déjà dans le Store, mais vous n’en avez parlé à personne. Pas de post, pas de petite vidéo, pas de note sur le blog. Résultat : votre App n’est vu que par des utilisateurs au hasard dans les résultats du Store. Même une annonce minimale pour les collègues, abonnés ou la communauté apporte des premières installations et du feedback, sur lesquels vous pouvez vous améliorer.

Erreur n° 7 : manque de cohérence entre la fiche et le comportement réel de l’App.
La fiche dit que l’App ne stocke pas les données, mais la politique de rétention est autre. Ou le russe est promis alors qu’en réalité il est encore en bêta et casse. Cela nuit non seulement aux avis, mais peut aussi devenir un sujet de réclamation de la part du Store. Les textes de la fiche doivent suivre l’architecture et les réglages de sécurité abordés dans les modules précédents, pas vivre leur propre vie.