Le SDK Apps est une option pratique si vous avez bientôt besoin d’un flux de travail dans ChatGPT ou si vous voulez y tester vos outils avant d’investir dans une pile d’agents personnalisée. Si vous devez maîtriser chaque étape du comportement de l’agent, ce n’est généralement pas le cas.
Choisissez le SDK Apps si ChatGPT doit être l’interface principale et que vous voulez des outils ainsi que quelques éléments d’interface sans créer un produit de clavardage complet. Choisissez votre propre pile d’agents si vous avez besoin d’un contrôle étroit sur le flux, la mémoire, les invites et les écritures.
Le SDK Apps convient aux produits qui combinent le clavardage et quelques courtes étapes d’interface. Vous livrez plus vite, mais cédez une part de contrôle.
Ce qui a fonctionné pour nous, ce sont des outils bien définis, des composants au fonctionnement clair et des prochaines étapes clairement établies. 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 pour expliquer les résultats déjà déterminés par le système.
Voici comment faire votre choix, puis ce qui a fonctionné et ce qui n’a pas fonctionné.
La plupart des équipes mènent encore des projets pilotes d’IA ou déploient l’IA dans des usages périphériques au rapport risque-rendement faible. Peu d’entre elles livrent un produit essentiel aux activités que les utilisateurs emploient chaque semaine. Le SDK Apps de ChatGPT permet de combler cet écart si votre objectif est d’être présent dans ChatGPT plutôt que de créer vous-même l’assistant au complet.
Nos apprentissages viennent d’un mandat client dont les exigences désignaient ChatGPT comme interface principale et privilégiaient une voie rapide, sans financer un produit de clavardage entièrement sur mesure.
Compte tenu de ce mandat, le SDK Apps convenait, car le client avait besoin des éléments suivants :
Aucun produit de clavardage dédié à créer et à héberger : il voulait rejoindre les utilisateurs dans ChatGPT, pas créer une autre interface d’assistant autonome.
Clavardage et petite interface propre aux tâches : quelques étapes ciblées dans des composants, pas un deuxième produit complet dans le flux de travail.
Comportement du serveur exposé par des outils MCP : des appels d’outils standards, pas un environnement d’exécution d’agent personnalisé géré de bout en bout.
Découverte dans ChatGPT : les utilisateurs doivent trouver le flux de travail là où ils travaillent déjà.
Nous avons validé ces choix avec le client tout au long du développement. Le compromis demeure : lorsque ChatGPT héberge la session, vous ne contrôlez 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 :
L’environnement d’exécution d’agent de ChatGPT
Vos outils MCP
L’interface de vos composants
Déroulement en pratique :
L’utilisateur demande quelque chose à ChatGPT.
ChatGPT peut appeler l’un de vos outils MCP.
Votre serveur renvoie un résultat d’outil structuré.
ChatGPT lit ce résultat et décide de la prochaine étape : effectuer d’autres appels d’outils, répondre à l’utilisateur ou faire les deux. Si vous avez associé un composant à cet outil, ce composant peut s’afficher au cours de ce même tour.
L’utilisateur poursuit dans le clavardage ou le composant (texte de suivi, choix ou appel d’outil déclenché par le composant). Cela met le fil à jour; ChatGPT exécute un autre tour et répète les étapes 2 à 4 jusqu’à la fin de la tâche.
C’est précisément cette combinaison de clavardage, d’actions du serveur et de courtes étapes d’interface qui importe. Cela signifie aussi que les éléments fragiles sont les transitions entre le clavardage, les outils et l’interface.
Vous n’avez pas à recréer de zéro l’interface de clavardage, la connexion des outils, les modèles d’authentification ou le conteneur de composants. Pour de nombreux produits, cela réduit fortement le temps de développement afin que vous puissiez vous concentrer sur la logique métier et les garde-fous.
Développer dans ChatGPT n’équivaut pas à exploiter votre propre agent. La difficulté du projet ne résidait pas dans des astuces d’invite. Il fallait rendre les outils, les composants et les prochaines étapes assez explicites pour que le modèle et l’interface restent harmonisés.
Le SDK Apps offre une forme de produit différente de votre interface habituelle, mais il est important de savoir à quels scénarios il convient le mieux.
Utilisez le SDK Apps lorsque vous voulez
Lancer rapidement un flux de travail dans ChatGPT.
Laisser ChatGPT héberger la conversation.
Combiner le langage naturel à quelques étapes d’interface ciblées.
Éviter de créer votre propre interface de clavardage, conteneur d’agent et mécanisme de découverte.
Ce dernier point importe lorsque vos utilisateurs sont déjà dans ChatGPT.
Créez votre propre agent lorsque vous avez besoin
D’un flux fixe, étape par étape, que vous pouvez imposer dans le code.
D’une interface et d’un parcours de confirmation personnalisés que vous contrôlez 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, de journaux et de mesures pour l’agent.
Si le planificateur, les invites système et le flux de travail complet constituent votre produit, une pile personnalisée convient généralement mieux.
Question | SDK Apps de ChatGPT | Vos propres agents |
|---|---|---|
Où l’expérience se déroule-t-elle? | Dans ChatGPT | Dans votre produit |
Qui exécute les étapes de la conversation? | ChatGPT, guidé par vos outils et votre interface | Votre système agentique |
Combien d’éléments d’interface créez-vous? | Des composants ciblés dans le clavardage | Tout ce dont vous avez besoin |
Quel contrôle exercez-vous sur les invites? | Indirect | Total |
Est-il facile de créer des flux fixes et reproductibles? | Exige une conception soignée | Plus facile à imposer dans le code |
Délai avant la première livraison | Souvent plus rapide | Souvent plus lent au départ |
Travail de plateforme à votre charge | Moins | Plus |
Marge pour changer de direction plus tard | Moins | Plus |
Pendant notre mandat, un mot revenait sans cesse : 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’était le compromis accepté par le client lorsqu’il a privilégié le fait de rejoindre les utilisateurs dans ChatGPT plutôt que la maîtrise de toute la pile.
Le parcours idéal semble simple : l’utilisateur demande, l’outil s’exécute, les données reviennent et le composant apparaît lorsqu’un choix est requis.
En pratique, les transitions étaient problématiques. Un composant n’est pas décoratif. Une fois à l’écran, il modifie ce que le modèle voit et fait ensuite. Traitez les actions des composants comme des événements nommés, et non comme du clavardage informel.
La pile du mandat était simple : FastMCP, Pydantic, React et TypeScript. Leur intégration s’est bien passée. Le travail consistait à faire en sorte que le modèle, les outils et l’interface s’accordent sur la prochaine étape.
Rendre chaque transition évidente
Nous avons cessé de traiter les résultats d’outils comme des charges utiles brutes du serveur. Chaque résultat est devenu une transition.
Un bon résultat d’outil :
Fournit au composant 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 la prochaine étape afin que le modèle n’ait pas à la deviner.
Les actions des composants 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 une fois les transitions clarifiées.
Le modèle suit de courtes instructions claires lorsqu’elles figurent dans la sortie de l’outil et les actions des composants.
Voici une petite structure Pydantic que nous avons utilisée. Le champ output contient les données structurées dont le composant a besoin lorsqu’il est affiché, ainsi que les faits que ChatGPT doit utiliser pendant la session. Le champ agent_directions contient une courte ligne indiquant ce que l’assistant doit faire ensuite. Le champ Reason est facultatif.
Python
Limiter la portée des composants
Les composants efficaces servaient à prendre une seule décision, puis rendaient le contrôle. Les courtes listes, les confirmations ou un écran de révision ciblé fonctionnaient mieux que la transformation du composant en miniapplication. Un peu de logique dans le composant, comme une validation simple ou une prochaine étape fixe, aidait tout de même lorsque nous voulions rendre le flux plus déterministe.
Troisième personne dans les messages des composants
Nous avons cessé de rédiger les suivis des composants comme des messages de l’utilisateur (« J’ai sélectionné… », « J’ai confirmé… »). Nous les avons rédigés comme de courts 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 composants comme messages d’outil plutôt que comme messages d’utilisateur.
Actions directes lorsque la prochaine étape est évidente
Si un bouton implique clairement le prochain appel d’outil, laisser le composant le déclencher directement fonctionnait mieux que d’imposer un autre tour de clavardage. 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 autre tour de clavardage.
Gestion des erreurs
Lorsqu’un appel d’outil échouait, nous renvoyions les bons codes d’erreur MCP et de courts messages clairs depuis l’outil. ChatGPT avait alors de l’information concrète à lire lors des appels échoués afin d’expliquer le problème à l’utilisateur ou de choisir une prochaine étape raisonnable, ou les deux.
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 antérieurs restaient dans la session au lieu de demander à ChatGPT de les transmettre de nouveau comme arguments d’outil à chaque appel.
Lorsque des boucles d’appels d’outils survenaient, nous pouvions intercepter les appels en double 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 le soutien.
Au début, nous affichions un composant, 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 voulions 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 la prochaine étape dans les sorties structurées et les charges utiles des composants, plutôt que d’espérer que le modèle la déduise.
Nous avons tenté de répartir astucieusement les réponses entre la sortie de l’outil, les métadonnées cachées et le texte du clavardage, conformément à la documentation du SDK Apps. Mais nous ne pouvions pas lire les métadonnées cachées dans les composants. Nous ne pouvions donc pas utiliser cette méthode.
La documentation du SDK Apps décrit des outils que vous pouvez exclure de la liste d’outils de l’agent afin qu’il ne les choisisse pas, tout en permettant au composant de les appeler. Lorsque nous avons réglé la visibilité à app-only, ces outils ont aussi cessé d’être accessibles depuis le composant, et non uniquement depuis l’agent. Nous n’avons jamais réussi à configurer le système pour que l’agent ne voie pas un outil auquel le composant avait toujours accès.
Le silence ou un message générique de « réussite » quand rien d’utile ne s’était produit était pire qu’une erreur franche. Nous avons donc traité les échecs des outils et des composants comme des sorties à part entière : si une étape ne pouvait pas continuer, nous l’indiquions clairement et renvoyions une erreur explicite, plutôt que de laisser les utilisateurs devant un composant affiché qui ne les faisait pas avancer. Cela a amélioré la convivialité et rendu le comportement du modèle plus fiable.
Si vous voulez un flux de travail dans ChatGPT avec moins de travail de plateforme personnalisé, le SDK Apps est un moyen pratique d’y parvenir. Vous échangez une part de contrôle contre de la rapidité et la possibilité de rejoindre les utilisateurs là où ils travaillent déjà.
Si vous devez maîtriser chaque branche du flux et l’interface, et déterminer qui décide de chaque étape, prévoyez votre propre pile d’agents dès le départ. Vous dépasserez probablement les limites d’un développement effectué uniquement 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 clavardage, l’authentification et l’infrastructure d’agent, puis migrer vers votre propre pile lorsque le produit l’exige.
Prochaine étape pour les équipes dans la même situation : choisissez un flux de travail au résultat clair, consignez les transitions entre le clavardage, les outils et les composants, puis testez rigoureusement les mécanismes de nouvelle tentative et la gestion des erreurs avant de consacrer beaucoup de temps au réglage des invites.