Developer Mode vs Store

1. Introduction

Dans les cours précédents, nous avons déjà parlé de ce qu’est une ChatGPT App, des couches qui la composent et en quoi elle diffère des anciens plugins et des simples bots sur l’API OpenAI. Passons maintenant au deuxième sujet important — le cycle de vie d’une telle application.

Si vous développez des services web depuis quelques années, le mot « lifecycle » ne vous effraie pas. Tout produit suit un chemin simple : « on code en local → on déploie sur le staging → on déploie en production → parfois on casse tout → on répare ». Dans l’écosystème ChatGPT avec une App, c’est la même chose, avec quelques nuances : il existe un Dev Mode au sein de ChatGPT et une entité séparée — le Store.

Il est important de distinguer clairement deux plans :

1. Où vit physiquement votre code : serveur Next.js local, Vercel, un cluster Kubernetes, etc. C’est votre monde, vous y êtes roi.
2. Comment ChatGPT voit votre App : comme un ensemble de métadonnées, d’URL et d’autorisations, que l’on peut soit connecter en Developer Mode, soit formaliser comme un produit prêt dans le Store. C’est le monde d’OpenAI, avec ses règles, sa review et ses utilisateurs.

Ce cours porte précisément sur ce second plan. Nous nous appuierons sur votre modèle d’environnements habituel (dev / staging / prod), mais en l’observant avec les yeux de ChatGPT. Notre objectif : que vous puissiez, à tout moment, répondre à quelques questions. Quel code exact exécute actuellement mon App ? Qui la voit ? Comment expérimenter en sécurité ? Et que signifie au juste « mettre à jour l’App » dans le Store ?

2. Developer Mode : bac à sable personnel dans ChatGPT

Commençons par ce que les développeurs préfèrent : un bac à sable où l’on peut tout casser sans (presque) blesser personne.

Le Developer Mode est un mode spécial dans ChatGPT où vous pouvez connecter vos ChatGPT Apps directement par URL, sans review, sans publier l’App dans le Store et sans l’exposer au monde entier. L’esprit est proche du localhost:3000 dans un navigateur, mais dans l’univers ChatGPT.

À quoi cela ressemble conceptuellement

Le plus simple est d’imaginer le schéma ainsi :

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Config App (dev) (URL + métadonnées)"]
    AppServer["Votre serveur d’app (Next.js + Apps SDK)"]

    User -->|requête dans le chat| ChatGPTCore[GPT]
    ChatGPTCore -->|requiert l’App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/outils| ChatGPTCore
    ChatGPTCore --> User

En tant que développeur, dans les paramètres du Developer Mode, vous dites à ChatGPT : « Voici mon App, voici son URL, voici son nom et ce qu’elle sait faire. » ChatGPT considère alors cette URL comme la source de votre application. Tant que vous n’avez pas soumis l’App au Store, vous seul la verrez (et, éventuellement, les autres membres de votre équipe si vous les ajoutez comme développeurs).

Nous verrons plus loin les détails techniques de la connexion (tunnel HTTPS, Vercel et autres réjouissances). L’idée clé ici : le Dev Mode est une sorte de « raccourci dynamique » vers votre serveur de développement, que ChatGPT sait appeler.

Comment activer le Developer Mode

Pour avoir la possibilité de "connecter" votre serveur local à l'interface ChatGPT, vous devez activer le commutateur correspondant dans les paramètres.

• Suivez le lien https://chatgpt.com/#settings/Connectors/Advanced ou allez dans Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Une fois cela fait, le bouton Create App apparaîtra.

En quoi le Dev Mode diffère-t-il de la production

La différence ressemble beaucoup à celle entre un environnement de dev et la production sur le web classique, mais avec quelques spécificités.

Premièrement, la visibilité. Votre App en Dev Mode n’est en général pas accessible aux utilisateurs ordinaires de ChatGPT. Elle est visible par vous et, éventuellement, par les membres de votre organisation ayant les droits adéquats. Vous pouvez expérimenter sans crainte qu’un utilisateur au hasard tombe sur un UX à moitié cassé.

Deuxièmement, la stabilité et l’expérimentation. En Dev Mode, vous pouvez changer le code toutes les deux minutes, démarrer un serveur local, le tuer, relancer un tunnel. ChatGPT essaiera d’appeler l’URL indiquée, mais ne « se vexera » pas si vous renvoyez parfois un 500 ou si vous ne répondez pas — c’est précisément le but du dev.

Troisièmement, les permissions et la politique. En Dev Mode, il est plus simple d’essayer différentes configurations. Mais n’oubliez pas que les politiques de contenu et de sécurité de base ne sont pas désactivées, même en dev : ChatGPT ne vous laissera pas soudainement devenir « une App de hacking pour tout ». En revanche, le cadre de la review du Store n’est pas encore activé : pas besoin d’une fiche parfaite, d’un joli logo, etc.

Enfin, en Dev Mode, il est en général plus facile de diagnostiquer les points problématiques. Vous pouvez modifier rapidement la logique, voir quelles requêtes ChatGPT envoie à votre serveur et corriger le comportement, sans penser à des « migrations d’utilisateurs ».

Nous avons déjà vu le Dev Mode comme un bac à sable personnel et nous avons jeté un œil au Store. Mettons maintenant tout cela en forme dans une « machine à états » claire du cycle de vie d’une App.

3. États d’une ChatGPT App : du brouillon à la dépublication

Formalisons cela en une « machine à états » pour votre App. Nous parlerons de quatre états principaux : Draft / Dev-only, Under review, Published et Paused/Removed.

Automate d’états du cycle de vie

Essayons de le dessiner en diagramme :

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / brouillon
    Review: Under review (Store)
    Published: Dans le Store, accessible aux utilisateurs
    Paused: Paused / Removed

    Draft --> Review: Envoyer en review
    Review --> Draft: Refusé / retour pour corrections
    Review --> Published: Approuvé
    Published --> Paused: Mettre en pause / retirer
    Paused --> Draft: Reprendre en mode dev
    Draft --> Published: Déploiement interne sans Store (pour l’organisation)

À l’état Draft, votre App n’existe que comme ressource de dev. Vous pouvez la connecter en Developer Mode, tester des fonctionnalités, sans l’exposer dans le Store.

Quand vous décidez que l’App est prête à être montrée, vous l’envoyez en « review » — c’est l’état Under review. OpenAI (ou le système interne de review de votre organisation) vérifie alors la conformité aux politiques, la stabilité, la sécurité de base et l’adéquation de l’UX.

Si tout va bien, l’App passe en Published : elle apparaît dans le Store ou devient accessible aux utilisateurs de votre entreprise (dans un scénario corporate). À partir de ce moment, de vrais utilisateurs arrivent, et tout changement de code et de configuration nécessite davantage de planification.

Si vous ne souhaitez temporairement plus rendre l’App accessible, vous pouvez la passer en Paused/Removed. À l’état Paused, elle est cachée aux nouveaux utilisateurs, mais peut rester active pour les sessions déjà commencées ou être totalement désactivée — les détails dépendent de la plateforme et des réglages.

4. Store : quand votre App devient un produit

Le Developer Mode est votre garage privé. Le Store, c’est la concession officielle. Ici entrent en jeu les utilisateurs, les notes, les règles de listing et la review.

Ce qui change quand vous allez dans le Store

D’abord et avant tout : votre App devient un « produit ». Elle a une fiche : nom, description, icône, catégories, parfois des amorces de conversation. À partir de ces métadonnées, le ChatGPT Store recherchera et recommandera votre application aux utilisateurs, et le modèle lui‑même comprendra dans quels scénarios l’App est pertinente.

Deuxième point important — review et politique. Avant qu’une App n’apparaisse dans le Store, elle est vérifiée pour sa conformité aux exigences de sécurité, de contenu et d’UX. Cela signifie que :

• il est interdit de collecter subrepticement des données personnelles inutiles ;
• il est interdit de promettre ce que votre App ne fait pas ;
• il est interdit de sortir des catégories de contenu autorisées.

Nous parlerons plus en détail des politiques et du bac à sable dans les cours suivants, mais voyez dès maintenant le Store comme l’endroit où vous apportez des versions relativement « bien élevées » de votre App.

Troisième point — responsabilité de la stabilité. En Dev Mode, vos plantages sont vos soucis. Dans le Store, on attend de votre App une disponibilité correcte, une latence raisonnable et l’absence « d’écrans rouges de la mort » dans le widget. Nous parlerons plus tard de SLO, de métriques et de review du Store dans ce contexte.

Versions : dev vs production

Question typique : « Si je mets à jour le code, que verra l’utilisateur ? ». Dans le monde des ChatGPT Apps, il est utile de penser à deux « brindilles » en parallèle :

• la branche dev, connectée au Developer Mode et qui peut pointer vers un serveur de dev, à côté de votre IDE ;
• la branche production, associée à la configuration publiée dans le Store et pointant vers une URL stable.

Architecturalement, on peut même l’exprimer via un petit type TypeScript dans votre projet :

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

Dans la vraie vie, la configuration est stockée par la plateforme ChatGPT, pas par votre code, mais de telles structures aident à garder en tête qu’il s’agit de deux « images » différentes d’une même App.

La mise en production d’une ChatGPT App ressemble davantage à la publication d’une application dans l’Apple App Store qu’à une mise à jour de site. Vos widgets et vos mcp-tools sont mis en cache à chaque release de l’application. Et la review peut prendre 2 semaines. Donc pas de « on déploie en production et on finira de tester là‑bas ». Vous devez soumettre en review une application déjà entièrement testée et stable.

5. Contexte organisationnel : compte personnel vs entreprise

Nous avons déjà séparé l’App en branches dev et production et vu comment cela se reflète dans le Store. Un autre axe important du cycle de vie est l’« endroit » où il vit organisationnellement.

Dans le cas le plus simple, vous créez une App en tant que particulier dans votre ChatGPT Plus personnel. Le Dev Mode est alors à vous, et le Store aussi, sous votre compte. Tout est relativement simple : vous l’avez fait pour vous, vous l’avez publié, vous avez fait plaisir au monde.

Mais très souvent, les ChatGPT Apps vivent dans un contexte d’entreprise. Plusieurs rôles s’ajoutent alors. Il y a les administrateurs de l’organisation, qui décident quelles Apps sont accessibles aux employés, lesquelles doivent être bloquées, lesquelles ne peuvent être utilisées que par un groupe pilote. Votre App peut être publiée non pas pour le monde entier, mais pour une entreprise spécifique, voire pour certains services en son sein.

Dans ce scénario, le cycle de vie peut ressembler à ceci : d’abord, l’App n’existe que comme projet de dev au sein de l’équipe, puis apparaît une « production interne » — accessible, par exemple, au seul service commercial pour un pilote. Ce n’est que plus tard, si tout se passe bien, que vous décidez d’envoyer l’App dans le Store global pour en faire un produit externe.

Architecturalement, cela compte, car vous devez concevoir l’App pour qu’elle fonctionne correctement à la fois comme outil interne et comme produit public. Cela implique parfois des feature flags, des modes « réservés aux nôtres » et des réglages d’authentification distincts.

6. Scénario pratique : cycle de vie de GiftGenius

Pour ne pas rester dans l’abstraction, regardons l’App fictive GiftGenius — un assistant de choix de cadeaux qui nous accompagnera tout au long du cours.

Étape 1. Idée et prototype brut en Dev Mode

Vous décidez de créer GiftGenius : une App qui demande à l’utilisateur pour qui il faut un cadeau, quel budget est envisagé et quels sont les centres d’intérêt du destinataire, puis propose des options en utilisant votre catalogue de produits.

À la première étape, vous :

1. montez un simple projet Next.js avec un widget minimal ;
2. activez le Developer Mode dans ChatGPT et y ajoutez l’URL de votre serveur de dev ;
3. menez quelques dialogues de test : vous demandez au GPT « Aide‑moi à choisir un cadeau pour un ami gamer jusqu’à 50 $ » et observez comment il appelle votre App, rend le widget et quel est l’UX.

À ce stade, vous ne pensez pas encore au Store, à la review ou aux belles icônes. Votre tâche est de vous prouver, à vous et à votre équipe, que l’idée fonctionne, et que la plateforme ChatGPT permet de réaliser le scénario voulu.

Étape 2. Consolidation du prototype et « alpha » interne

Quand vous avez confirmé que le scénario de base fonctionne, commence l’étape de « consolidation ». Vous :

• ramenez la logique à une structure plus claire ;
• réfléchissez aux permissions et aux données réellement nécessaires à l’App ;
• vérifiez le comportement de l’App en cas d’erreurs (par exemple, si le catalogue ne répond pas).

Toujours en Dev Mode, mais plus seul : vous ajoutez des collègues comme développeurs ou testeurs, afin qu’ils puissent eux aussi connecter l’App à leur ChatGPT. Le cycle de vie tourne encore autour de l’état Draft : vous mettez rapidement le code à jour, essayez divers patterns UX, discutez les retours en interne.

Étape 3. Préparation au Store et review

À cette étape, vous vous dites : « Oui, GiftGenius est suffisamment correct pour être montré à des utilisateurs externes. » Le focus se déplace alors du code vers l’emballage produit :

• vous rédigez une description honnête et claire de l’App ;
• vous configurez les permissions : vous expliquez quelles données l’App consulte, et pourquoi ;
• vous vous assurez que l’UX n’induit pas en erreur et que l’App ne promet pas l’impossible.

C’est le moment du passage de Draft à Under review. Vous envoyez l’App en review, et, pendant un certain temps, elle vit dans cet état intermédiaire. Il se peut que vous receviez des remarques : préciser la politique de confidentialité, corriger des formulations, réduire les permissions. Vous revenez en Draft, corrigez et renvoyez.

Étape 4. Publication et « vraie vie »

Après approbation, votre GiftGenius passe en Published. Les utilisateurs peuvent désormais le trouver dans le Store, ChatGPT peut le proposer selon les requêtes pertinentes, et vous commencez à collecter de vrais retours, à observer l’usage et à réfléchir à l’échelle.

Désormais, chaque changement de code n’est pas juste « j’ajoute vite une fonction ». C’est un mini‑release. Il faut penser à la rétro‑compatibilité, aux migrations, si possible d’abord modifier la version dev, la vérifier, puis seulement mettre à jour la configuration de production.

Si nécessaire, vous pouvez temporairement passer l’App en Paused, si vous trouvez une vulnérabilité critique ou si votre backend ne tient pas la charge. L’idéal reste de faire évoluer progressivement la branche Published, sans oublier l’environnement dev pour les expérimentations.

7. Comment un développeur doit penser les environnements : dev, staging, production + Dev Mode

Avec l’exemple GiftGenius, nous avons parcouru le chemin de l’idée en Dev Mode jusqu’à l’App publiée. Mettons cela dans le schéma d’environnements habituel — dev/staging/production — et voyons comment cela se relie au Dev Mode et au Store.

On peut garder en tête la matrice suivante :

Le Developer Mode se « colle » à votre infrastructure de dev ou de staging : vous publiez une URL temporaire que ChatGPT utilise pour les tests. La configuration du Store, elle, pointe vers une URL de production déjà mûre.

Plus tard, quand nous parlerons du déploiement sur Vercel et des tunnels, cette matrice deviendra une série d’étapes très concrètes. Mais, dès maintenant, gardez une idée simple : sachez toujours où se trouve la requête en cours de ChatGPT — dans votre bac à sable de dev ou dans l’environnement de prod utilisé par les utilisateurs.

8. Un petit « morceau de code » sur le cycle de vie

Pour rapprocher cela de votre approche TypeScript habituelle, écrivons un type simple qui reflète le cycle de vie de l’App non pas au niveau de la plateforme, mais au niveau de votre propre tooling. Vous pouvez le mettre dans le dépôt pour ne pas oublier les différents états.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – sélection de cadeaux',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Vous n’enverrez jamais un tel objet à ChatGPT, mais il aide l’équipe à partager le même contexte. Vous pouvez même créer un petit CLI qui affiche l’état de toutes vos Apps, pour éviter de confondre ce qui est encore un brouillon avec ce qui se trouve déjà dans le Store.

Dans les modules suivants, nous reviendrons constamment à ce modèle de cycle de vie : lors de la configuration des tunnels et du déploiement sur Vercel, de la conception d’un serveur MCP et de scénarios agents, de la réflexion sur le commerce‑flow et de la préparation à la review dans le Store. Considérez le Dev Mode et le Store comme les deux pôles d’un même système : un bac à sable pour expérimenter et une vitrine pour un produit déjà mature.

9. Erreurs courantes avec le Dev Mode et le Store

Erreur n° 1 : « Directement dans le Store, on verra bien après ».
La tentation est parfois grande de « conquérir le marché » au plus vite et de publier une App dans le Store au stade de prototype semi‑fonctionnel. Cela mène presque immanquablement à des avis négatifs, de mauvaises statistiques d’usage et des questions supplémentaires lors de la review. Mieux vaut vivre quelques itérations en Developer Mode, recueillir des retours de collègues et d’amis, stabiliser l’UX de base, puis seulement aller dans le Store.

Erreur n° 2 : mélanger les environnements dev et production.
Scénario typique : vous pointez le Dev Mode vers la même URL que la production, puis vous vous étonnez que « quelques petits changements de debug » soient soudain visibles des vrais utilisateurs. Séparez soigneusement les URLs de dev et de prod, comme vous le faites pour les services web classiques. Si la configuration de votre ChatGPT App indique une URL de production, ne l’utilisez pas pour des « expériences rapides du soir ».

Erreur n° 3 : absence de compréhension claire des états.
Quand les développeurs ne savent pas dans quel état vit une App (Draft, Under review, Published, Paused), des situations étranges surviennent : l’un pense que l’App est déjà dans le Store, l’autre la considère toujours comme un prototype local. Indiquez au moins dans le README du projet où en est l’App et ce qu’il faut faire pour passer à l’étape suivante.

Erreur n° 4 : ignorer la politique et la review jusqu’au dernier moment.
Certaines équipes développent une App « comme si c’était juste un site », et ne pensent à la politique, aux permissions et aux exigences du Store que la veille de l’envoi en review. Résultat : il faut revoir sérieusement la collecte et le stockage des données, réécrire les descriptions et réduire les droits. Mieux vaut garder le cadre en tête dès le départ et, en Dev Mode, expérimenter d’emblée avec des permissions honnêtes et minimales.

Erreur n° 5 : absence de stratégie distincte pour l’usage interne et externe.
Si une App est d’abord conçue comme outil interne d’entreprise, puis que vous souhaitez en faire un produit public, il est facile de confondre les cibles. En interne, on peut tolérer un UX moins « léché » et des scénarios plus complexes ; dans le Store public, les utilisateurs attendent un autre niveau de confort. Ne pas savoir dans quel mode vous êtes conduit à une App publique qui ressemble à un outil d’admin interne, et un pilote interne qui s’enlise parce que vous pensez trop tôt au Store global.

Erreur n° 6 : absence de lien entre Dev Mode et observabilité.
Le Developer Mode est parfait pour le debug, mais il faut en profiter. Si vous ne regardez pas les logs et n’enregistrez pas quelles requêtes ChatGPT envoie à votre App en environnement de dev, des surprises désagréables peuvent vous attendre plus tard en production. Utilisez le Dev Mode comme un terrain d’étude du comportement réel du modèle et des utilisateurs, pas seulement pour vérifier « que le widget compile ».