Qu’est-ce qu’un ChatGPT App et ce qu’il N’EST PAS

1. Introduction

Du point de vue d’un développeur ordinaire, tout cela semble déjà un peu familier : il y a un nouveau mot à la mode — ChatGPT App, il y a une API, un SDK, encore deux ou trois acronymes, et on a l’impression que c’est « une autre manière d’appeler un modèle d’IA ».

Le problème, c’est que sans une vision claire, on commence à confondre entre elles des entités très différentes : les anciens plugins ChatGPT, l’Assistants API, les Custom GPTs et les nouveaux ChatGPT Apps. Résultat : certains espèrent « tout cliquer » en une soirée dans l’UI comme pour un Custom GPT, et finissent à devoir monter un serveur MCP, écrire un widget Next.js et réfléchir au Store. Et inversement : d’autres écrivent un backend complexe alors qu’un simple Custom GPT ou un simple wrapper d’API aurait suffi.

Commençons donc par définir ce que est le nouveau ChatGPT App (et remettons tout proprement en place), puis ce qu’il n’est pas.

Brève évolution « historique » des intégrations avec les LLM

Avant de donner des définitions, il est utile de voir l’évolution des approches. Cela vous aidera non seulement à mémoriser de nouveaux termes, mais à comprendre d’où vient l’idée des Apps au sein de ChatGPT.

Au départ, il y avait la variante classique « API wrapper ». Vous déployiez votre application web ou votre bot, et quelque part dans le backend vous appeliez l’OpenAI API : vous transmettiez un prompt, receviez une réponse textuelle, et l’affichiez à l’utilisateur. Toute la logique, l’UI, l’authentification et la facturation étaient de votre côté. En tant que produit, ChatGPT n’était pas impliqué.

Ensuite sont apparus les ChatGPT Plugins.

C’était une première tentative d’intégrer des services externes dans l’interface même de ChatGPT. Le plugin était décrit via OpenAPI, ChatGPT pouvait appeler ses endpoints, et vous répondiez en JSON que le modèle paraphrasait en texte pour l’utilisateur. Le plugin n’avait aucun UI propre — au mieux du Markdown que le modèle pouvait afficher dans le chat. Ce système est désormais considéré comme obsolète.

Sont ensuite arrivés les Custom GPTs (MyGPTs).

C’est un constructeur de « votre version de ChatGPT » sans code : vous configurez des prompts, connectez des fichiers, parfois des Custom Actions vers des HTTP-API. Tout vit dans l’interface ChatGPT, mais l’UI est strictement standard, et les intégrations sont limitées aux possibilités des Actions.

Enfin, un saut qualitatif — les toutes dernières ChatGPT Apps. Ici, on dispose d’un UI riche (un widget dans le chat), d’un protocole standard pour communiquer avec vos données et votre logique backend (MCP), et d’une place dédiée dans l’écosystème : Dev Mode, Store, permissions, paiements intégrés, etc.

Au moment d’écrire ce cours, il y avait 4 millions d’applications sur Google Play, 2 millions sur l’Apple App Store, et seulement 5 sur ChatGPT. Pas 5 millions, mais seulement 5(!) applications. Et pourtant, ChatGPT compte 800 millions d’utilisateurs actifs par semaine. Il n’a jamais été aussi facile d’entrer dans le top 100 des applications et de gagner quelques millions.

Si je vous ai intrigué, allons plus loin vers la question principale : qu’est donc ce nouveau ChatGPT App ?

2. Définition concise de ChatGPT App

On trouve sur Internet plusieurs explications marketing, mais comme nous sommes tous des informaticiens ici, je vais traduire cela en langage simple.

Un ChatGPT App est une application web qui s’exécute à l’intérieur de ChatGPT et possède son propre widget UI. L’application fournit à ChatGPT un ensemble d’outils (fonctions) et de données, et est enregistrée dans le catalogue d’applications (App Store). Elle combine une interface conversationnelle (chat) avec un UI graphique et une logique backend, en communiquant avec la plateforme ChatGPT via des protocoles standardisés comme MCP.

Et voici ce que cela implique :

Premièrement, « s’exécute dans l’interface de ChatGPT ». L’utilisateur ne quitte pas https://chatgpt.com/ ni l’application mobile ; l’UI de votre application est intégré dans cette interface sous forme de widget. Votre widget s’affiche directement dans le flux du chat.

Deuxièmement, « dispose de son propre widget UI ». Ce n’est pas juste du texte que le modèle affiche dans le chat. Vous pouvez rendre des composants React : cartes, listes, formulaires, cartes géographiques, lecteurs et autres joies du frontend. Techniquement, c’est une application Next.js classique, fonctionnant dans une sandbox et communiquant avec ChatGPT via window.openai et le Apps SDK.

Troisièmement, « fournit à ChatGPT un ensemble d’outils (fonctions) et de données ». Vous déployez un serveur MCP côté backend et y enregistrez les outils MCP de votre App — vous décrivez les actions que votre service sait accomplir : recherche dans un catalogue, réservation, analyse de données, génération de rapports. ChatGPT voit ces outils comme des fonctions avec des JSON Schema et peut les appeler à sa discrétion.

Quatrièmement, « est enregistrée dans le catalogue d’applications ». Votre App a un nom, une icône, des descriptions, des catégories, des permissions, des versions et une monétisation. Ce n’est pas un « petit script vite fait », mais une véritable App dans l’écosystème ChatGPT.

Un changement de perspective très important : vous n’écrivez pas un « bot » qui décide de tout. Vous décrivez l’interface et les capacités (UI + outils), et ChatGPT décide lui‑même quand les utiliser et comment les intégrer dans le dialogue. Vous ne contrôlez le scénario que partiellement.

Ce positionnement a un énorme avantage pour vous : ChatGPT propose lui‑même aux utilisateurs d’installer votre application et décide lui‑même quand la lancer. Autrement dit, le coût publicitaire de l’application est de 0 $. Un million d’installations de votre application vous coûteront 0 $. Du moins, si vous faites partie des premiers.

Lancer votre application ChatGPT en 2025, c’est comme acheter des bitcoins à 1 $. À vous de choisir.

3. Anatomie d’un ChatGPT App : UI, outils et contexte

Pour éviter de nous perdre ensuite, décomposons l’App en trois grands composants qui reviendront tout au long du cours.

Premier composant : la couche UI. C’est votre widget, généralement écrit en React/Next.js à l’aide du Apps SDK. Il est rendu à l’intérieur de ChatGPT, affiche des listes de cadeaux, des formulaires de réservation, des graphiques, et d’autres éléments visuels. Il vit dans une sandbox : il ne peut pas casser le DOM global, ne peut pas aller sur Internet comme bon lui semble, et fonctionne dans une fenêtre aux ressources limitées.

Deuxième composant : outils, ressources et prompts. Au niveau du protocole, il s’agit d’un serveur MCP avec des capabilities décrites : tools (actions), resources (données) et prompts (modèles). Les outils sont décrits par des schémas JSON, et le modèle les voit comme des fonctions qu’il peut appeler lorsque c’est pertinent. Dans les modules suivants, nous verrons en détail comment se déroule cet callTool, mais pour l’instant retenez : les outils sont les mains et les yeux de votre App dans le monde réel.

Troisième composant : le contexte d’utilisation. C’est tout ce avec quoi vous décrivez votre App pour le modèle et pour les utilisateurs : system prompt, descriptions des outils, permissions, audience cible, catégories dans le Store. De ces métadonnées dépendent les moments où GPT proposera l’App, quels requêtes seront jugées pertinentes et quelles actions sont autorisées.

Un peu plus tard, lorsque nous analyserons l’application d’exemple GiftGenius, vous verrez ces trois couches en action : un widget UI avec des cartes cadeaux et un assistant de questions de clarification, des outils de sélection et de commande côté MCP/backend, et le contexte — instructions système, descriptions, permissions et catégories dans le Store.

4. Comparons les « applications » ChatGPT

Maintenant que nous avons une vision d’ensemble et l’anatomie de l’App, faisons un pas en arrière et comparons-la à ses « proches ». Cela aidera à bien distinguer dans votre esprit les Apps, les plugins, l’Assistants API et la simple OpenAI API. Ci‑dessous — un tableau pour garder ces entités séparées.

Une bonne analogie, explicitement soulignée dans la documentation officielle : l’Assistants API, c’est quand vous prenez le « cerveau de GPT » et l’intégrez dans votre produit, tandis que le ChatGPT App, c’est l’inverse : vous amenez votre produit à l’intérieur de l’interface de ChatGPT.

5. Ce que ChatGPT App N’EST PAS

Passons maintenant en revue les idées reçues courantes. C’est important pour ne pas concevoir un App comme autre chose.

ChatGPT App ≠ juste un site Next.js

Le réflexe d’un frontend dev est de percevoir un App comme « un SPA de plus », sauf qu’au lieu de / vous avez « une fenêtre étrange dans ChatGPT ». C’est en partie vrai, mais il y a une différence cruciale : vous n’êtes pas sur votre propre domaine et vous ne contrôlez pas l’ensemble de l’UI ; vous louez un petit morceau d’interface à ChatGPT. Vous ne pouvez pas réécrire la navigation, mettre votre bannière au‑dessus de tout ou « hacker » l’environnement.

Dans notre cours, nous considérerons le widget comme un composant isolé, et non comme un site complet : il a des contraintes strictes sur le réseau, le DOM et les ressources, et tout le lourd part sur le backend/MCP. Nous parlerons en détail de la sandbox dans la dernière leçon de ce niveau ; ici, retenez simplement que ce n’est pas « un hébergement Next.js de plus ».

Pour illustrer — un exemple de code. Voici à quoi ressemble un « wrapper API » classique autour d’OpenAI dans votre application Next.js — ce n’est pas un ChatGPT App :

// app/api/chat/route.ts — backend classique de votre site, pas un App
import OpenAI from "openai";
import { NextRequest, NextResponse } from "next/server";

const client = new OpenAI();

export async function POST(req: NextRequest) {
  const { message } = await req.json();
  const response = await client.responses.create({
    model: "gpt-5.2",
    input: [{ role: "user", content: [{ type: "text", text: message }] }],
  });
  return NextResponse.json({ reply: response.output[0].content[0].text });
}

L’utilisateur de cette application communique avec votre backend, pas avec ChatGPT. Toute la logique d’UI et de session est de votre côté. C’est une excellente option pour des fonctionnalités IA dans votre propre produit, mais ce n’est pas un ChatGPT App.

ChatGPT App ≠ ancien ChatGPT Plugin

Il faut envoyer le mot « plugin » au musée de 2023 et l’utiliser uniquement pour désigner l’ancien système. Les plugins donnaient à ChatGPT la possibilité d’appeler vos endpoints HTTP selon une spec OpenAPI, mais ne permettaient pas de construire un UI riche : au mieux, vous pouviez renvoyer du Markdown que le modèle affichait dans le chat.

Les nouveaux Apps, contrairement aux plugins, peuvent rendre des widgets React, travailler via MCP, avoir des permissions et participer à des scénarios financiers. Les considérer comme des « plugins 2.0 » est un raccourci qui se retournera vite contre vous au moment de concevoir l’UI et les outils.

ChatGPT App ≠ Assistants API

L’Assistants API répond à une autre problématique : donner à votre produit (site, application mobile, outil interne) un assistant intelligent basé sur GPT. Tout vit « chez vous », vous contrôlez l’UI, et GPT est un service backend avec lequel vous communiquez via une API.

Dans le cas d’un ChatGPT App, c’est l’inverse. L’UI et l’expérience principale appartiennent à ChatGPT, et vous y « sous‑louez » votre application. L’utilisateur ne voit pas votre domaine : il voit le nom et l’icône de l’App à l’intérieur de ChatGPT, et ce sont généralement ses propres tokens qu’il paie via son abonnement ChatGPT.

En bref : l’Assistants API — c’est GPT dans votre produit ; le ChatGPT App — c’est votre produit dans ChatGPT.

ChatGPT App ≠ simplement un Custom GPT

Les Custom GPTs sont parfaits pour un démarrage rapide : vous assemblez un prompt, ajoutez quelques fichiers — et vous avez déjà un « assistant personnel ». Mais son UI est standard, sans widgets, et les intégrations via les Custom Actions sont assez limitées ; il n’y a pas l’intégralité du Apps SDK ni le niveau MCP.

Un ChatGPT App est déjà une histoire pro‑code. Vous écrivez un widget (souvent en Next.js), déployez un serveur MCP, configurez l’authentification, les permissions, les paiements. Le niveau de flexibilité est bien plus élevé, mais la responsabilité aussi : sécurité, UX et passage en revue lors de l’enregistrement de l’application.

Stratégie pratique que je peux recommander aux entreprises : utiliser un Custom GPT comme porte d’entrée marketing rapide (un assistant simple dans le GPT Store), tout en développant en parallèle une App complète sur le Apps SDK pour des scénarios sérieux et une future monétisation.

ChatGPT App ≠ « juste un bot de plus »

Enfin, un point psychologique important. Un ChatGPT App, ce n’est pas « encore un chatbot ». C’est un produit avec un cycle de vie : il y a un Dev Mode, une revue, des versions, des contraintes, de l’analytics et des scénarios de paiement. Le considérer comme un « petit bot pour démo » est le meilleur moyen de sous‑estimer l’effort, rater un vrai lancement et passer à côté de vos millions.

6. Types d’applications ChatGPT

Pour mieux comprendre ce que vous construisez, il est utile d’avoir une typologie grossière des ChatGPT Apps. Dans notre cours, nous parlerons de quatre axes principaux et utiliserons pour eux de courts labels anglais : UI-heavy, tool-first, commerce-oriented et data/analytics.

• Premier type — applications UI‑heavy ou UI‑first. La valeur principale réside dans l’interface visuelle : assistants, configurateurs, formulaires complexes, canvas. Exemples : sélection d’assurance avec une dizaine de paramètres, configurateur de design, visualisation de données.
• Deuxième type — applications Tool‑first. L’essentiel, ici, ce ne sont pas les écrans, mais les outils. L’App fournit au modèle un ensemble puissant de fonctions, et une grande partie de l’expérience utilisateur est orchestrée par ChatGPT lui‑même, avec des explications textuelles et parfois un UI minimal. Exemple : une App donnant à GPT l’accès à la base de connaissances interne de l’entreprise ; le modèle décide quand et comment lancer une recherche et comment expliquer les résultats.
• Troisième type — applications Commerce‑oriented. Le centre de gravité, ce sont les ventes, abonnements, réservations. L’App est intégrée à l’Agentic Commerce Protocol (ACP), sait traiter des achats, gérer le panier et l’Instant Checkout, relier des commandes aux utilisateurs.
• Quatrième type — applications Data/analytics. Elles se concentrent sur la connexion de sources de données et l’analytique : rapports, tableaux de bord BI, analyse de logs et de métriques, travail avec des fichiers importés.

La même idée peut être réalisée dans des styles différents. Par exemple, la sélection de cadeaux peut être purement Tool‑first (le modèle génère lui‑même les explications, l’App ne renvoie qu’un JSON avec une liste d’idées) ou UI‑heavy (widget riche avec filtres, cartes produits, comparaison d’options).

7. Notre projet pédagogique : GiftGenius

Tout ce que nous ferons dans le cours gagnera à être rattaché à une application « fil rouge ». Ainsi, au fur et à mesure, nous écrirons notre propre application : GiftGenius — une application pour sélectionner des cadeaux et passer commande via ChatGPT. Nous y reviendrons constamment.

Du point de vue de la typologie, GiftGenius est d’abord une App commerce‑oriented avec des éléments UI‑heavy. L’utilisateur écrit dans ChatGPT quelque chose comme : « Il me faut un cadeau pour un ami développeur, budget 50–70 dollars », le modèle d’IA décide d’activer GiftGenius, l’App affiche un widget avec des questions de précision, une sélection de cadeaux et, au final, la commande via ACP.

Pour commencer dès maintenant à le penser en termes de TypeScript, on peut ébaucher un modèle de domaine minimal qui nous accompagnera par la suite :

// gift-types.ts — modèle de domaine simplifié de GiftGenius
export type GiftIdea = {
  id: string;
  title: string;
  priceUsd: number;
  tags: string[];      // intérêts du destinataire
  occasion: string;    // occasion : birthday, wedding, etc.
};

Pour l’instant, ce n’est qu’un type, non lié à un SDK. Mais au fil du cours, vous verrez comment ces modèles de domaine se retrouvent dans les outils MCP, dans le widget UI et même dans la couche commerce.

8. Comment l’utilisateur voit un ChatGPT App dans le dialogue

Bien que le « parcours utilisateur » soit le thème principal de la troisième leçon, il est important d’en esquisser la vue d’ensemble dès maintenant pour comprendre à quoi sert l’UI et comment l’App arrive dans le dialogue.

L’utilisateur discute avec ChatGPT comme d’habitude : il écrit des messages, pose des questions, demande de l’aide. À chaque réplique, ChatGPT décide quoi faire : répondre lui‑même, appeler un outil, afficher ou mettre à jour le widget de votre App, proposer d’utiliser l’App si elle est pertinente dans le contexte.

Par exemple, l’utilisateur écrit : « J’ai besoin d’un cadeau pour un anniversaire de mariage, budget jusqu’à 100 dollars, mon mari adore les jeux de société ». Le modèle voit qu’il dispose de l’App GiftGenius, capable de sélectionner des cadeaux selon ces critères. Il peut suivre deux voies :

1. D’abord proposer à l’utilisateur d’utiliser GiftGenius, en écrivant quelque chose comme : « Je peux lancer l’App GiftGenius pour proposer quelques options. Voulez‑vous que je la démarre ? ».
2. Appeler directement les outils de l’App et afficher le widget avec des champs déjà remplis, en montrant une sélection.

Tout cela se fait sans votre if user_said_gift then call_app() impératif. Vous décrivez les capacités de l’App, et le modèle apprend à les utiliser. D’où l’importance des descriptions claires, des limites et d’un UX bien conçu — sinon GPT abusera de votre App, ou au contraire ne l’utilisera jamais.

Pour visualiser, on peut le représenter par un diagramme :

flowchart TD
  U[Utilisateur dans ChatGPT] -->|message| G[Modèle GPT]
  G -->|décision : utiliser l’App ?| A[Votre ChatGPT App]
  A -->|widget| W[UI dans le chat]
  A -->|tools/MCP| B[Votre backend / MCP]
  B --> A --> G --> U

Nous détaillerons la façon dont GPT décide d’appeler l’App dans les thèmes consacrés aux outils et au system prompt, mais il est déjà utile de comprendre : c’est une coopération, pas une commande impérative.

9. Mini‑exercice : votre idée d’App

Pour éviter que la matière ne reste trop théorique, cela vaut la peine d’imaginer dès maintenant une idée pour votre propre App que vous ferez évoluer mentalement aux côtés de GiftGenius.

Essayez de formuler en une phrase ce que fait votre application dans ChatGPT. Par exemple : « L’App aide les développeurs à estimer la complexité des tâches et à les découper en sous‑tâches » ou « L’App propose des itinéraires de voyage en tenant compte de la météo et du budget ».

Ensuite, il est utile de répondre honnêtement à deux questions. Premièrement, à quel type de notre typologie se rapproche‑t‑elle le plus : UI‑heavy, tool‑first, commerce‑oriented ou data/analytics ? Deuxièmement, s’agit‑il vraiment d’un ChatGPT App ou, en réalité, simplement d’un bot dans votre site ou d’un autre Custom GPT ? Si tout ce dont vous avez besoin est d’appeler OpenAI API un peu plus confortablement côté backend, un App complet n’est peut‑être pas nécessaire.

Ces mini‑analyses sont un bon moyen de vous économiser quelques mois de développement du mauvais produit.

10. Erreurs typiques de compréhension d’un ChatGPT App

Erreur n° 1 : Appeler tout « plugin ».
Le système de plugins est une étape historique de 2023. La nouvelle génération d’intégrations, ce sont des Apps basées sur le Apps SDK + MCP. Si vous restez mentalement accroché au terme « plugin », vous sous‑estimerez facilement le rôle de l’UI, de la sandbox, du Store et de tout le cycle produit. Dans ce cours, nous utilisons « plugin » uniquement pour l’ancien système, et « App » désigne toujours la nouvelle génération d’applications.

Erreur n° 2 : Attendre un contrôle total sur GPT.
Parfois, des développeurs arrivent en pensant « je vais écrire un App et le modèle fera exactement ce que je dis ». Dans l’écosystème ChatGPT, les choses sont différentes : vous décrivez vos capacités et intentions, mais le modèle décide lui‑même quand appeler des outils, quand afficher le widget, et quand répondre en texte. Si vous concevez l’App comme un SPA classique avec un scénario figé, la déception sera douloureuse.

Erreur n° 3 : Confondre ChatGPT App et Assistants API.
Situation très courante : quelqu’un veut « un bot dans son produit » mais regarde par habitude du côté du Apps SDK, alors qu’il serait plus simple et logique d’utiliser l’Assistants API. Il gaspille alors des efforts sur un widget dans ChatGPT dont ses utilisateurs n’ont pas besoin. La distinction correcte est simple : si les utilisateurs viennent sur votre site ou votre application, pensez Assistants API ; si vous voulez aller à la rencontre des utilisateurs dans ChatGPT, pensez ChatGPT App.

Erreur n° 4 : Considérer l’App comme « juste un frontend de plus » sans tenir compte de la sandbox.
Quand un développeur essaie d’utiliser le Apps SDK comme un frontend Next.js ordinaire et ignore les contraintes de la sandbox (accès réseau, DOM et ressources limités), il se heurte vite au fait que « rien ne marche comme sur mon site ». Il faut accepter d’emblée que le widget est un composant isolé, et que toute l’intégration lourde et la gestion des secrets doivent être déportées vers le backend/MCP.

Erreur n° 5 : Surestimer les Custom GPT et sous‑estimer l’Apps SDK (ou l’inverse).
Les Custom GPTs et les Apps ne s’opposent pas : ce sont des niveaux de maturité différents. Souvent, la bonne stratégie est d’utiliser les deux : un Custom GPT comme entrée rapide et marketing, un App comme produit sérieux avec UI riche et commerce. Quand un développeur attend d’un Custom GPT des capacités de niveau Apps SDK ou, à l’inverse, tire le Apps SDK là où un Custom GPT suffirait, il ne fait que se compliquer la vie.