La démonstration est généralement la partie facile. Un client pose une question en langage naturel, l’application appelle un outil et un résultat soigné s’affiche dans ChatGPT.
Le vrai produit commence quand le stock a changé, que le client répète une instruction, que le jeton de son compte expire ou qu’un système en amont n’accepte que la moitié d’une demande. Si l’application peut réserver, modifier, commander, chiffrer ou soumettre, ce sont des états du produit, pas des notes de bas de page techniques.
Une application ChatGPT orientée client doit donc être construite à partir de preuves de mise en production, pas d’une liste de fonctionnalités. La question décisive est de savoir si l’entreprise peut prouver qu’une action client utile est exacte, autorisée, rattrapable et prise en charge par le support.
Réponse en 60 secondes
Partez d’une tâche du client et du système qui a autorité pour l’accomplir. Définissez l’action comme un changement d’état contrôlé : comprendre la demande, récupérer l’état à jour, préparer l’action, revalider les conditions exactes, montrer la conséquence, obtenir l’accord, engager une seule fois, émettre un reçu et offrir, lorsque c’est possible, un chemin d’annulation ou d’escalade.
N’exposez que les outils étroits dont cette tâche a besoin. Séparez les outils de lecture des outils d’écriture. N’ajoutez une interface visuelle que si elle améliore la comparaison, la saisie ou la confirmation. Gardez des permissions minimales et appliquez-les dans le back-end.
Avant l’ouverture au public, rassemblez des preuves pour le parcours ordinaire, les prompts négatifs et les cas difficiles : soumission en double, prix périmé, identité expirée, écriture partielle, délai dépassé et panne d’un système en amont. Attribuez un responsable à la supervision, au support, aux changements de règles et au retour arrière.
La soumission et la publication sont des étapes de livraison. Elles ne garantissent ni une découverte en bonne place ni l’adoption par les clients.
Dans cet article
- Le produit, c’est la capacité derrière la conversation
- Définir une machine à états avant de dessiner des écrans
- Construire la plus petite surface d’outils utile
- N’ajouter de l’interface que là où elle pèse dans la décision
- Traiter l’identité et les permissions comme un comportement du produit
- Le dossier de preuves de mise en production
- La matrice de contrôle des cas difficiles
- La revue publique fait partie du plan de mise en production
- Une séquence de mise en production adossée aux preuves
- Ce qu’il faut mettre dans le brief prestataire
1. Le produit, c’est la capacité derrière la conversation
La documentation actuelle d’OpenAI décrit un plugin comme un paquet qui peut inclure des instructions ou des skills, un serveur MCP distant, une interface et des hooks de cycle de vie. Une intégration orientée client utilise généralement un serveur MCP pour exposer des outils contrôlés. Une interface optionnelle s’exécute dans l’hôte quand des cartes, des comparaisons, des formulaires ou des confirmations sont plus utiles que du texte. Architecture des plugins, guide du serveur MCP, guide de l’interface.
Les termes évoluent : les acheteurs cherchent encore « application ChatGPT » et « Apps SDK », tandis que la documentation développeur actuelle parle de plus en plus de « plugins ». L’architecture métier compte davantage que l’étiquette du moment :
conversation ChatGPT → outil sélectionné → service d'intégration → système métier de référence → résultat validé
Pour une action client, le même chemin revient en sens inverse avec un résultat, une référence, un statut et une voie de support. Le modèle peut interpréter la demande et choisir un outil. Il ne doit pas devenir la source de vérité d’un prix, d’une permission de compte ou d’une transaction terminée.
Cela a une conséquence immédiate sur le cadrage. Le travail n’est pas de « connecter notre site à ChatGPT ». Il consiste à concevoir et exploiter un produit borné, à cheval sur une surface conversationnelle externe et les propres systèmes de l’entreprise.
2. Définir une machine à états avant de dessiner des écrans
Une action à conséquences exige une séquence visible :
comprendre l'intention → récupérer l'état de référence → préparer l'action → revalider les conditions → montrer le périmètre et les conséquences → obtenir un accord explicite → engager une seule fois → émettre un reçu → permettre l'annulation ou l'escalade
Chaque transition a besoin d’un responsable et de preuves.
Imaginons qu’un client demande à déplacer un rendez-vous. L’assistant peut repérer les créneaux possibles sans rien modifier. Une fois que le client a choisi, l’application doit récupérer l’état le plus récent du créneau, afficher la date, le lieu, l’écart de prix et la conséquence sur les conditions d’annulation, puis demander une confirmation. Le back-end vérifie l’identité et la permission, soumet une modification idempotente, renvoie la référence de réservation et enregistre le résultat.
Si la confirmation est répétée parce que la réponse a tardé, l’application ne doit pas créer un second rendez-vous. Si le créneau choisi a disparu, elle ne doit pas annoncer un succès sur la foi d’une lecture antérieure. Si une seule des étapes en aval a abouti, le support doit savoir ce qui s’est passé.
La même logique s’applique à une commande, un devis de service, un retour, une réservation ou une demande B2B. Les conséquences financières et opérationnelles déterminent le niveau de contrôle requis.
3. Construire la plus petite surface d’outils utile
Un outil MCP doit représenter une capacité métier claire, pas une instruction vague du type « gérer le client ». Des frontières utiles pourraient être :
- rechercher les points de vente disponibles ;
- récupérer les options éligibles ;
- calculer un devis provisoire ;
- préparer une demande de report ;
- confirmer une modification choisie ;
- récupérer le reçu ou le statut qui en résulte.
Séparez les lectures des écritures. Un outil de recherche peut être appelé pendant que le client explore. Un outil qui engage une commande exige des contrôles plus forts d’identité, de confirmation, de relance et d’audit.
Les entrées et sorties des outils doivent utiliser des identifiants stables et des schémas explicites. Les libellés affichés au client peuvent changer ; un identifiant de réservation ou de produit, non. Renvoyez des états d’erreur structurés que l’application sait expliquer, plutôt que de masquer chaque échec derrière une réponse conversationnelle inventée.
Les recommandations d’OpenAI sur les métadonnées préconisent un jeu versionné de « golden prompts » avec des exemples directs, indirects et négatifs. L’objectif est de mesurer quand le bon outil est appelé, quand un autre outil serait préférable et quand aucun outil ne doit l’être. Changez une seule variable de métadonnées à la fois et rejouez le jeu après chaque modification. Évaluation des métadonnées.
Ce sont des preuves d’invocation. Elles ne prouvent pas que les clients découvriront l’application dans l’annuaire ni qu’ils l’utiliseront à une échelle commerciale.
4. N’ajouter de l’interface que là où elle pèse dans la décision
La conversation sait recueillir une demande incomplète et clarifier des arbitrages. Elle est moins fiable comme seule représentation d’une comparaison dense ou d’une confirmation à conséquences.
Une interface dans la conversation justifie son périmètre quand elle aide le client à :
- comparer plusieurs options sans perdre d’attributs importants ;
- modifier précisément des dates, des quantités ou des sélections ;
- comprendre un total, une restriction ou une condition d’annulation ;
- confirmer l’action exacte qui sera soumise ;
- consulter un reçu ou un statut stable.
Gardez une solution de repli non visuelle pour l’accessibilité et les différences entre hôtes. Testez l’usage au clavier, l’ordre de focus, les libellés, les messages d’erreur, le zoom, le contraste et le sens restitué par un lecteur d’écran. Les contrôles automatisés sont utiles, mais ils ne remplacent pas une évaluation humaine de la question essentielle : la décision reste-t-elle compréhensible ? Les WCAG 2.2 sont la recommandation actuelle du W3C à retenir comme référence d’accessibilité. WCAG 2.2.
L’interface doit rendre l’incertitude et les conséquences plus claires. La décoration seule ne justifie pas un composant de plus à construire, à faire passer en revue et à maintenir.
5. Traiter l’identité et les permissions comme un comportement du produit
Une information publique peut ne demander aucune identité client. Des données privées ou des actions sur un compte, si.
Pour les outils authentifiés, définissez :
- quel fournisseur d’identité fait autorité ;
- quel utilisateur et quelle organisation cliente le jeton représente ;
- le périmètre de permission minimal de chaque outil ;
- comment l’émetteur, l’audience, la signature et l’expiration sont validés ;
- ce que voit le client quand l’accès manque ou expire ;
- quelle règle d’autorisation est appliquée côté serveur avant chaque action ;
- quelles données personnelles sont journalisées, conservées et supprimées.
Les recommandations actuelles d’OpenAI sur l’authentification utilisent OAuth pour l’accès propre à un utilisateur. Ses recommandations de sécurité insistent sur le moindre privilège, le consentement explicite, la validation côté serveur, des politiques de sécurité du contenu restrictives et une gestion prudente des contenus externes. Guide d’authentification, recommandations de sécurité et de confidentialité.
Le modèle peut aider à interpréter l’intention. Il ne doit pas décider qu’un utilisateur a le droit de consulter un autre compte, d’approuver un remboursement ou de contourner une règle commerciale. Nous détaillons le modèle de permissions plus large dans gérer les accès et autorisations des agents IA et les contrôles au niveau du produit dans ce qui change quand l’IA peut agir.
6. Le dossier de preuves de mise en production
Demandez à l’équipe de livraison de produire ce dossier en même temps que l’intégration fonctionnelle. Il transforme « la démo fonctionne » en preuves de recette vérifiables.
| Élément de preuve | Ce qu’il contient | La question qu’il tranche |
|---|---|---|
| Contrat de résultat | Une tâche du client, les utilisateurs éligibles, l’état de départ et d’arrivée, les actions exclues et des critères de recette mesurables | Que mettons-nous exactement en production ? |
| Carte de l’architecture et des sources de vérité | Systèmes, flux de données, source de vérité de chaque champ, ancienneté acceptable et point de validation | Quel système a le droit d’affirmer chaque fait ? |
| Registre des contrats d’outils | Nom de l’outil, finalité, entrées, sorties, effets de bord, états d’erreur, responsable et version | Que peut demander le modèle, et que peut réellement faire l’outil ? |
| Inventaire des permissions et des données | Identité, périmètre, règles par organisation cliente, données personnelles, conservation, suppression et accès aux journaux | Qui peut faire quoi, et quelles données franchissent la frontière ? |
| Corpus de golden prompts | Prompts directs, indirects, négatifs, ambigus et adversariaux, avec le comportement attendu | L’invocation correspond-elle à la façon dont les clients s’expriment ? |
| Preuves de test des actions | Contrôles de revalidation, de confirmation, d’idempotence, d’autorisation, de reçu et d’audit | Une action à conséquences peut-elle être engagée une seule fois et tracée ? |
| Matrice de contrôle des cas difficiles | Délais dépassés, doublons, état périmé, écritures partielles, pannes et comportement de reprise | Que se passe-t-il hors du parcours idéal ? |
| Preuves d’interface et d’accessibilité | Modes d’affichage, comportement de repli, contrôles au clavier et au lecteur d’écran, revue humaine | Les clients peuvent-ils comprendre et utiliser la surface de décision ? |
| Carte de mise en production et de revue | Propriété du domaine et de l’identité, éléments de règles et de fiche, accès des évaluateurs, déploiement et déclencheurs d’une nouvelle revue | L’équipe peut-elle soumettre, publier et faire évoluer le produit de façon responsable ? |
| Plan d’exploitation et de retour arrière | Supervision, alertes, support, responsable des incidents, coupe-circuit, retour arrière et correction auprès du client | Qui maintient la capacité en sécurité après le lancement ? |
Le dossier doit être versionné avec chaque mise en production. Un schéma ou un résultat de test issu d’une architecture antérieure ne prouve rien pour le système actuellement en production.
7. La matrice de contrôle des cas difficiles
N’acceptez pas « géré proprement » comme exigence. Définissez le résultat attendu.
| Cas difficile | Comportement attendu côté client | Preuve système requise |
|---|---|---|
| Identifiant manquant ou ambigu | Demander la clarification minimale ; ne pas deviner l’enregistrement | Aucune lecture ni écriture sur un objet de compte incertain |
| Authentification expirée | Expliquer qu’une reconnexion est nécessaire et conserver le contexte sûr lorsque c’est permis | Action refusée, aucune fuite de données, échec d’authentification traçable |
| Prix, stock ou créneau modifié | Rechiffrer selon les conditions de référence actuelles avant la confirmation | Ancienne et nouvelle version enregistrées ; aucun engagement sur un état périmé |
| Le client soumet deux fois | Renvoyer le résultat existant ou un statut sûr | Clé d’idempotence et un seul engagement en aval |
| Délai dépassé en amont | Indiquer avec exactitude un statut en attente ou inconnu ; n’annoncer ni échec ni succès sans preuve | Identifiant de corrélation, règle de relance et chemin de rapprochement |
| Écriture partielle | Bloquer toute nouvelle action, afficher un statut exact et orienter vers la correction | Étapes terminées, tentative de compensation ou de retour arrière, et responsable |
| Permission refusée | Expliquer l’étape suivante autorisée sans exposer de détail protégé | Refus côté serveur et événement d’audit |
| Panne d’un service externe | Proposer une solution de repli honnête ou une voie ultérieure | Signal de santé, disjoncteur ou limite, et message de support |
| Le client refuse la confirmation | Ne rien modifier | Aucune écriture, et un brouillon annulé enregistré seulement si c’est pertinent |
Ajoutez les cas propres à votre secteur. Un commerçant a besoin des erreurs de variante et d’exécution des commandes. Un service de rendez-vous a besoin des cas de double réservation et de fuseau horaire. Un fournisseur B2B a besoin des conflits de prix par compte, de quantités et de règles de validation. Les services réglementés exigent un périmètre d’action plus étroit et une escalade humaine plus forte.
8. La revue publique fait partie du plan de mise en production
Pour une intégration MCP distante publique, les recommandations actuelles d’OpenAI exigent un point d’accès HTTPS public et stable, une identité vérifiée, des annotations d’outils exactes, les éléments de règles et de fiche, les domaines réseau déclarés et un accès pour les évaluateurs quand une authentification est en jeu. Les recommandations actuelles de soumission demandent aussi au moins cinq cas de test positifs et trois négatifs. L’approbation est suivie d’une action de publication distincte, et un changement important des métadonnées peut déclencher un nouveau cycle de revue. Recommandations de soumission, exigences de revue.
Traitez-les comme des exigences actuelles de la plateforme, pas comme des constantes. Attribuez la responsabilité de la vérification développeur, du contrôle du domaine, des pages de règles, des identifiants, des réponses lors de la soumission et du retrait de publication d’urgence.
Disponibilité publique et découverte sont deux choses distinctes. Les recommandations de revue actuelles indiquent que la distribution renforcée est limitée et ne peut pas être demandée. Un contrat de livraison peut inclure l’accompagnement jusqu’à une soumission réussie ainsi que la vérification de la recherche par nom exact et du lien direct. Il ne doit promettre ni recommandation, ni mise en avant, ni trafic, ni ventes.
9. Une séquence de mise en production adossée aux preuves
1. Prouver la tâche du client sans action d’écriture
Utilisez des demandes réalistes et des données de référence. Vérifiez que le résultat améliore suffisamment la décision du client pour justifier l’intégration.
2. Stabiliser le parcours de lecture
Mesurez l’exactitude des données, la latence, la gestion des permissions, les résultats vides et les pannes en amont. Réparez le système source ou l’adaptateur là où la vérité n’est pas fiable.
3. Ajouter une action en brouillon
Laissez l’application préparer la modification sans l’engager. Rendez visibles le périmètre et les conséquences prévus.
4. Ajouter un engagement contrôlé
Mettez en place la revalidation, l’accord explicite, l’autorisation côté back-end, l’idempotence, le reçu et les preuves d’audit. Commencez par l’action éligible la plus étroite.
5. Dérouler les cas difficiles et une répétition opérationnelle
Testez les relances, les pannes, les accès révoqués, les objets périmés, les exécutions partielles, la supervision, le support et le retour arrière. Impliquez les personnes qui traiteront un vrai incident.
6. Mener la revue de la plateforme et une mise en production bornée
Soumettez les preuves exigées par l’hôte, publiez après approbation et ouvrez la capacité à un groupe ou à un parcours défini lorsque c’est possible. Suivez séparément la qualité d’invocation et les résultats métier.
10. Ce qu’il faut mettre dans le brief prestataire
Donnez aux équipes pressenties la tâche du client, les systèmes de référence, la frontière entre lecture et écriture, le modèle d’identité, les marchés visés, l’interface attendue et le niveau de conséquence. Demandez à chaque prestataire de renvoyer la même structure de preuves :
- outils, systèmes et états d’interface inclus ;
- hypothèses sur les API existantes et la qualité des données ;
- frontières d’authentification, de sécurité et de confidentialité ;
- couverture des tests ordinaires, négatifs, limites et adversariaux ;
- travail de mise en production et de revue, et exclusions ;
- responsabilité de la supervision, du support et des incidents ;
- propriété du code source, du compte cloud, du domaine, des secrets, de la télémétrie et de la documentation ;
- conditions de changement, de nouvelle revue, de retour arrière et de sortie.
Les propositions deviennent comparables, et un risque courant apparaît : une estimation séduisante du front-end qui suppose que le travail difficile d’intégration et d’exploitation existe déjà.
Construire pour une vraie promesse
Le client ne perçoit ni serveur MCP ni iframe. Ce qu’il vit, c’est la réponse à une question simple : l’entreprise lui propose-t-elle la bonne option, respecte-t-elle ses permissions, engage-t-elle l’action voulue une seule fois et l’aide-t-elle quand quelque chose tourne mal ?
C’est le niveau d’exigence d’une mise en production. Construisez la plus petite capacité utile, puis exigez la preuve que le parcours ordinaire comme les cas difficiles peuvent être exploités.
Apportez une action client et son système source. Nous pouvons la transformer en contrat de résultat, définir le dossier de preuves de mise en production et identifier ce qui doit être réparé avant qu’une construction publique mérite d’être financée. Concevoir et exploiter cette capacité bornée relève de notre service Agents IA & Produits LLM.
Sources et périmètre
La documentation des plateformes a été vérifiée le 9 septembre 2026. La dénomination des produits, les exigences de revue, la distribution, l’éligibilité au commerce et les capacités des hôtes peuvent changer et doivent être revérifiées avant toute soumission. La machine à états, le dossier de preuves de mise en production et la matrice de contrôle des cas difficiles constituent le cadre de livraison d’IZZY. Ils réduisent l’ambiguïté et exposent les risques ; ils ne garantissent ni l’approbation de la plateforme, ni la découverte, ni un fonctionnement sans erreur, ni un retour commercial.