Ce que nous avons appris en lançant un produit avec le SDK Apps de ChatGPT

• Le SDK Apps est une option pratique si vous avez rapidement besoin d’un workflow dans ChatGPT, ou si vous voulez y tester vos outils avant d’investir dans une stack d’agents personnalisée. Si vous devez maîtriser chaque étape du comportement de l’agent, ce n’est généralement pas le bon choix.

• Choisissez le SDK Apps si ChatGPT doit être l’interface principale et si vous voulez des outils et quelques éléments d’UI sans créer un produit de chat complet. Choisissez votre propre stack d’agents si vous devez contrôler étroitement le flux, la mémoire, les prompts et les écritures.

• Le SDK Apps convient aux produits qui associent le chat à quelques brèves étapes d’UI. Vous livrez plus vite, mais renoncez à une partie du contrôle.

• Ce qui a fonctionné pour nous : des outils, un comportement des widgets et des étapes suivantes clairement définis. Nous nous sommes appuyés sur ces éléments, et non sur le LLM, pour définir le flux. Le modèle était surtout utile lorsqu’il expliquait des résultats déjà choisis par le système.

• Ci-dessous : comment choisir, puis ce qui a fonctionné ou non.

La plupart des équipes mènent encore des projets pilotes d’IA ou déploient l’IA pour des usages périphériques présentant peu de risques et de bénéfices. Peu livrent un produit critique pour l’entreprise que les utilisateurs emploient chaque semaine. Le SDK Apps de ChatGPT permet de combler cet écart si votre objectif est d’intégrer ChatGPT plutôt que de créer vous-même l’assistant complet.

Nos enseignements viennent d’une mission client dont les exigences désignaient ChatGPT comme interface principale et imposaient une mise en œuvre rapide, sans financer un produit de chat entièrement sur mesure.

Le SDK Apps répondait à ce cahier des charges, car le client avait besoin des éléments suivants :

• Aucun produit de chat dédié à créer et héberger — le client voulait toucher les utilisateurs dans ChatGPT, pas proposer une nouvelle enveloppe d’assistant autonome.

• Du chat et une petite UI propre à la tâche — quelques étapes ciblées dans des widgets, pas un second produit complet au sein du workflow.

• Un comportement backend exposé par des outils MCP — des appels d’outils standard, pas un environnement d’exécution d’agent personnalisé et entièrement maîtrisé.

• Une découverte dans ChatGPT — les utilisateurs doivent trouver le workflow là où ils travaillent déjà.

Nous avons validé ces choix avec le client au fil du développement. Le compromis reste le même : lorsque ChatGPT héberge la session, vous ne maîtrisez pas l’environnement d’exécution externe. Vous le guidez sans le contrôler entièrement.

Une application du SDK Apps relie trois éléments :

1. L’environnement d’exécution d’agent de ChatGPT

2. Vos outils MCP

3. L’UI de votre widget

Le flux en pratique :

1. L’utilisateur demande quelque chose à ChatGPT.

2. ChatGPT peut appeler l’un de vos outils MCP.

3. Votre serveur renvoie un résultat d’outil structuré.

4. ChatGPT lit ce résultat et décide de l’étape suivante : d’autres appels d’outils, une réponse à l’utilisateur, ou les deux. Si vous avez associé un widget à cet outil, il peut s’afficher durant cet échange.

5. L’utilisateur poursuit dans le chat ou le widget : texte de suivi, choix ou appel d’outil déclenché par le widget. Cela met à jour le fil ; ChatGPT lance un nouvel échange et répète les étapes 2 à 4 jusqu’à l’accomplissement de la tâche.

Cette combinaison de chat, d’actions backend et de brèves étapes d’UI est précisément l’objectif. Cela signifie aussi que les points fragiles sont les transitions entre le chat, les outils et l’UI.

Vous n’avez pas à recréer de zéro l’UI de chat, la connexion des outils, les mécanismes d’authentification ou l’enveloppe du widget. Pour de nombreux produits, cela réduit fortement le temps de développement et permet de se concentrer sur la logique métier et les garde-fous.

Créer dans ChatGPT ne revient pas à exploiter son propre agent. La difficulté du projet ne résidait pas dans des astuces de prompt. Il fallait rendre les outils, les widgets et les étapes suivantes suffisamment explicites pour que le modèle et l’UI restent alignés.

Le SDK Apps offre une structure de produit différente de votre frontend habituel, mais il est important de connaître les scénarios auxquels il convient le mieux.

Utilisez le SDK Apps si vous voulez

• Lancer rapidement un workflow ChatGPT.

• Laisser ChatGPT héberger la conversation.

• Associer le langage naturel à quelques étapes d’UI ciblées.

• Éviter de créer votre propre interface de chat, conteneur d’agent et système de découverte.

Ce dernier point compte lorsque vos utilisateurs travaillent déjà dans ChatGPT.

Créez votre propre agent si vous avez besoin

• D’un flux fixe, étape par étape, que vous pouvez imposer dans le code.

• D’une UI et d’un parcours de confirmation personnalisés, que vous maîtrisez de bout en bout.

• De votre propre modèle de mémoire et d’état.

• D’un comportement prévisible à chaque exécution.

• De traces, journaux et métriques pour l’agent.

Si le planificateur, les prompts système et l’ensemble du workflow constituent votre produit, une stack personnalisée est généralement plus adaptée.

Durant notre mission, le mot qui revenait sans cesse était « contrôle » : d’un côté, la rapidité et un environnement familier ; de l’autre, une maîtrise partielle de l’environnement d’exécution. C’est le compromis accepté par le client lorsqu’il a privilégié la rencontre avec les utilisateurs dans ChatGPT plutôt que la maîtrise de toute la stack.

Le scénario idéal paraît simple : l’utilisateur demande, l’outil s’exécute, les données reviennent et le widget s’affiche lorsqu’un choix est nécessaire.

En pratique, les transitions étaient la principale difficulté. Un widget n’est pas décoratif. Une fois affiché, il modifie ce que voit le modèle et ce qu’il fait ensuite. Traitez les actions des widgets comme des événements nommés, et non comme une conversation informelle.

La stack de la mission était simple : FastMCP, Pydantic, React et TypeScript. Leur intégration n’a posé aucun problème. Le travail consistait à faire concorder le modèle, les outils et l’UI sur l’étape suivante.

Rendez chaque transition évidente

Nous avons cessé de traiter les résultats des outils comme des données backend brutes. Chaque retour est devenu une transition.

Un bon résultat d’outil :

• Fournit au widget ce dont il a besoin pour s’afficher.

• Fournit à ChatGPT des faits structurés sur lesquels fonder sa réponse.

• Lorsque le flux l’exige, indique l’étape suivante afin que le modèle n’ait pas à la deviner.

Les actions des widgets ne doivent pas renvoyer de texte vague dans le fil. Elles doivent indiquer ce que l’utilisateur a fait et ce qui doit suivre.

La fiabilité s’est améliorée dès que les transitions sont devenues claires.

Le modèle suit des instructions courtes et claires lorsqu’elles figurent dans le résultat de l’outil et les actions du widget.

Voici une petite structure Pydantic que nous avons utilisée. Le champ output contient les données structurées nécessaires au widget lorsqu’il est affiché, ainsi que les faits que ChatGPT doit utiliser dans la session. Le champ agent_directions contient une courte ligne indiquant ce que l’assistant doit faire ensuite. Reason est facultatif.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

Gardez les widgets simples

Les widgets efficaces permettaient de prendre une décision, puis rendaient le contrôle. Les listes courtes, les confirmations ou un écran de vérification ciblé fonctionnaient mieux que la transformation du widget en mini-application. Un peu de logique dans le widget, comme une validation simple ou une étape suivante fixe, restait utile pour rendre le flux plus déterministe.

La troisième personne dans les messages des widgets

Nous avons cessé de rédiger les suivis des widgets comme des messages de l’utilisateur (« J’ai sélectionné… », « J’ai confirmé… »). Nous les avons rédigés comme de brefs comptes rendus des actions de l’utilisateur (« L’utilisateur a sélectionné… », « L’utilisateur a confirmé… »). Nous avons essayé cette approche parce que ChatGPT ajoutait les messages des widgets comme des messages d’outil plutôt que comme des messages utilisateur.

Des actions directes lorsque l’étape suivante est évidente

Lorsqu’un bouton implique clairement le prochain appel d’outil, laisser le widget le déclencher directement fonctionnait mieux qu’imposer un nouvel échange de chat. Cela ne s’applique que si le prochain appel d’outil ne nécessite aucune donnée de ChatGPT.

Cela a aidé à imposer des flux déterministes et réduit la latence en évitant un nouvel échange de chat.

Gestion des erreurs

Lorsqu’un appel d’outil échouait, l’outil renvoyait les codes d’erreur MCP appropriés et des messages courts et simples. ChatGPT disposait alors d’informations réelles sur les appels échoués pour expliquer le problème à l’utilisateur et/ou choisir une étape suivante pertinente.

Gestion du contexte des outils

Nous conservions l’état de la session sur notre serveur. ChatGPT envoie un contexte propre à la session avec les appels d’outils ; dans FastMCP, nous avons donné à chaque outil un paramètre Context afin que le gestionnaire puisse lire et mettre à jour cet état.

• Les identifiants stables et les résultats précédents restaient dans la session, au lieu de demander à ChatGPT de les retransmettre comme arguments à chaque appel d’outil.

• Lorsque des boucles d’appels d’outils apparaissaient, nous pouvions détecter les doublons et renvoyer une erreur claire dans le résultat de l’outil.

• Les journaux de session restaient de notre côté pour le débogage et l’assistance.

Au début, nous affichions un widget, supposions que le modèle « avait compris » et attendions le bon appel d’outil de suivi. Cela fonctionnait parfois. Souvent, ce n’était pas le cas.

Sans transition claire, ChatGPT pouvait résumer alors que nous attendions une action, demander à l’utilisateur de répéter un choix ou continuer à planifier alors qu’il aurait dû s’arrêter.

La solution consistait à préciser l’étape suivante dans les sorties structurées et les données des widgets, plutôt que d’espérer que le modèle la déduise.

Nous avons tenté de répartir astucieusement les réponses entre le résultat de l’outil, les métadonnées masquées et le texte du chat, conformément à la documentation du SDK Apps. Mais nous ne pouvions pas lire les métadonnées masquées dans les widgets. Nous ne pouvions donc pas utiliser cette approche.

La documentation du SDK Apps décrit des outils que vous pouvez exclure de la liste de l’agent pour qu’il ne les choisisse pas, tout en les appelant depuis le widget. Lorsque nous avons limité la visibilité à l’application, ces outils ont également cessé d’être accessibles depuis le widget, et pas seulement depuis l’agent. Nous n’avons jamais réussi à configurer un outil invisible pour l’agent mais toujours accessible au widget.

Le silence ou un message générique « réussi » quand rien d’utile ne s’était produit était pire qu’une erreur franche. Nous avons donc traité les échecs d’outils et de widgets comme des sorties à part entière : lorsqu’une étape ne pouvait pas continuer, nous l’indiquions clairement et renvoyions une erreur explicite, au lieu de laisser l’utilisateur devant un widget affiché qui ne lui permettait pas d’avancer. Cela a amélioré l’ergonomie et rendu le comportement du modèle plus fiable.

Si votre objectif est de proposer un workflow dans ChatGPT avec moins de travail de plateforme personnalisé, le SDK Apps est une solution pratique. Vous échangez une partie du contrôle contre de la rapidité et la possibilité de toucher les utilisateurs là où ils travaillent déjà.

Si vous devez maîtriser chaque branche du flux, l’UI et la décision à chaque étape, prévoyez votre propre stack d’agents dès le départ. Vous finirez probablement par dépasser les limites d’une création exclusivement dans ChatGPT.

Vous pouvez aussi utiliser le SDK Apps pour exécuter votre serveur MCP dans ChatGPT avant de créer vous-même le chat, l’authentification et l’infrastructure de l’agent, puis migrer vers votre propre stack lorsque le produit l’exige.

Prochaine étape pour les équipes dans la même situation : choisissez un workflow au résultat clair, consignez les transitions entre le chat, les outils et les widgets, puis testez intensivement les nouvelles tentatives et les erreurs avant de consacrer trop de temps au réglage des prompts.