For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale

Consignes relatives aux plugins

Exigences relatives aux serveurs MCP et à l’interface utilisateur facultative des plugins publiés.

Ces consignes concernent le serveur MCP et l’interface utilisateur facultative d’un plugin. Pour connaître l’ensemble du processus de soumission, y compris les skills, les étapes dans le portail, la révision, l’approbation et la publication, consultez Soumettre des plugins.

Vue d’ensemble

L’écosystème des plugins repose sur la confiance. Les utilisateurs de ChatGPT et de Codex s’attendent à des expériences sûres, utiles et respectueuses de leur vie privée. Les développeurs attendent un processus équitable et transparent. Ces consignes destinées aux développeurs énoncent les règles que chaque créateur est tenu de lire et de respecter.

Avant d’entrer dans les détails, consultez les consignes relatives à l’interface utilisateur facultative pour découvrir les modèles d’interaction, de mise en page et de design qui rendent l’interface d’un plugin intuitive, digne de confiance et cohérente au sein de ChatGPT.

Vous pouvez également consulter les principes présentés dans Ce qui fait une excellente expérience dans ChatGPT.

Les consignes ci-dessous définissent les exigences minimales qu’un plugin publié doit respecter pour rester disponible dans l’annuaire universel commun à ChatGPT et Codex. Les plugins qui démontrent une réelle utilité pratique et suscitent une grande satisfaction chez les utilisateurs peuvent bénéficier d’une diffusion élargie, par exemple grâce à une mise en avant dans l’annuaire ou à des suggestions proactives.

Principes fondamentaux des plugins

Finalité et originalité

Les plugins devraient répondre à un objectif clair et tenir leurs promesses de manière fiable. Ils devraient notamment proposer des fonctionnalités ou des workflows que les produits ne prennent pas en charge nativement et qui contribuent réellement à répondre aux intentions courantes exprimées par les utilisateurs dans la conversation.

N’utilisez que des éléments de propriété intellectuelle dont vous détenez les droits ou que vous êtes autorisé à utiliser. N’ayez recours ni à des designs trompeurs ou imitant d’autres produits, ni à l’usurpation d’identité, au spam ou à des cadres statiques sans interaction utile. Les plugins ne devraient pas laisser entendre qu’ils sont créés ou approuvés par OpenAI.

Qualité et fiabilité

Les plugins doivent se comporter de manière prévisible et fiable. Les résultats devraient être exacts et pertinents au regard des informations saisies par l’utilisateur. Les erreurs, y compris imprévues, doivent être gérées au moyen de messages clairs ou de mécanismes de repli.

Avant de soumettre un plugin, testez soigneusement son serveur MCP, ses outils et son éventuelle interface utilisateur dans un large éventail de scénarios. Les plugins devraient être stables, réactifs et complets. Les plugins d’essai ou de démonstration ne seront pas acceptés.

Nom, description et captures d’écran facultatives du plugin

Les noms et descriptions des plugins doivent être clairs, exacts et simples. Évitez les noms trop génériques, en particulier ceux composés d’un seul mot du dictionnaire qui n’est pas explicitement associé à votre marque. Les captures d’écran sont facultatives pour les plugins dotés d’une interface utilisateur. N’en soumettez pas pour les plugins sans interface utilisateur. Si vous incluez des captures d’écran, elles doivent représenter fidèlement les fonctionnalités du plugin et respecter les dimensions requises.

Outils

Les outils MCP indiquent à ChatGPT et Codex comment utiliser les capacités de votre serveur. Des définitions d’outils claires et précises rendent le plugin plus sûr, facilitent sa compréhension par le modèle et inspirent davantage confiance aux utilisateurs.

Des noms d’outils clairs et précis

Les noms des outils devraient être compréhensibles, précis et décrire ce que l’outil fait réellement.

  • Les noms des outils doivent être uniques au sein de votre serveur MCP.
  • Utilisez des termes simples qui reflètent directement l’action, idéalement sous forme de verbe (par exemple, get_order_status).
  • Évitez les formulations trompeuses, trop promotionnelles ou comparatives (par exemple, pick_me, best, official).

Des descriptions conformes au comportement

Chaque outil doit inclure une description qui explique sa finalité de manière explicite et précise.

  • La description devrait indiquer ce que fait l’outil.
  • Les descriptions ne doivent ni favoriser ni dénigrer d’autres plugins ou services, ni tenter d’influencer le modèle pour qu’il choisisse les outils décrits plutôt que ceux d’un autre plugin.
  • Les descriptions ne doivent pas recommander de déclencher les outils dans des situations trop larges, au-delà de l’intention explicite de l’utilisateur et de la finalité du plugin.
  • Si la description d’un outil ne permet pas de comprendre clairement et complètement son comportement, le plugin peut être refusé.

Des annotations correctes

Les annotations des outils doivent être correctement définies pour que le modèle et les utilisateurs sachent si une action est sûre ou nécessite une prudence accrue.

  • Vous devriez attribuer l’annotation readOnlyHint à un outil s’il se contente de récupérer ou de lister des données sans rien modifier en dehors de la conversation.
  • Les outils qui effectuent des opérations d’écriture ou de destruction (par exemple, création, mise à jour, suppression, publication, envoi) doivent être explicitement signalés à l’aide des annotations readOnlyHint et destructiveHint.
  • Définissez openWorldHint sur true pour les outils qui accèdent à l’Internet public ou à des entités externes sans périmètre délimité, y compris pour la recherche web en lecture seule. Un outil limité à un compte ou à un espace de travail privé dont le périmètre est délimité peut définir cette annotation sur false, même si le service est hébergé à l’extérieur.
  • Des annotations d’action incorrectes ou manquantes sont une cause fréquente de refus. Vérifiez soigneusement que les annotations readOnlyHint, openWorldHint et destructiveHint sont correctement définies, et fournissez une justification détaillée pour chacune lors de la soumission du plugin.

Des données d’entrée minimales et adaptées à l’objectif

Les outils devraient demander uniquement les informations nécessaires à l’exécution de leur tâche.

  • Les champs d’entrée doivent être directement liés à la finalité déclarée de l’outil.
  • Ne demandez pas l’historique complet de la conversation, les transcriptions brutes des discussions ou des champs contextuels trop larges « au cas où ». Un outil peut demander un champ décrivant l’intention de l’utilisateur de manière brève et propre à la tâche , uniquement si cela améliore sensiblement l’exécution sans étendre la collecte de données au-delà de ce qui est raisonnablement nécessaire pour répondre à la demande de l’utilisateur et aux finalités décrites dans votre politique de confidentialité.
  • Si nécessaire, utilisez la localisation géographique approximative partagée par le système. Ne demandez pas de données de localisation précises sur l’utilisateur (par exemple, des coordonnées GPS ou des adresses).

Un comportement prévisible et vérifiable

Les outils devraient se comporter exactement comme l’indiquent leurs noms, leurs descriptions et leurs données d’entrée.

  • Les effets de bord ne devraient jamais être cachés ou implicites.
  • Si un outil envoie des données en dehors de l’environnement actuel (par exemple, en publiant du contenu ou en envoyant des messages), sa définition doit l’indiquer clairement.
  • Dans la mesure du possible, les outils devraient pouvoir être réexécutés sans risque. Dans le cas contraire, ils devraient indiquer explicitement si de nouvelles tentatives risquent de répéter leurs effets.

Des outils soigneusement conçus contribuent à limiter les surprises, à protéger les utilisateurs et à accélérer le processus de révision.

Authentification et autorisations

Si votre serveur MCP nécessite une authentification, le parcours doit être transparent et explicite. Les utilisateurs doivent être informés de toutes les autorisations demandées, et ces demandes doivent se limiter à ce qui est nécessaire au fonctionnement du plugin.

Identifiants de test

Lorsque vous soumettez un plugin doté d’un serveur MCP nécessitant une authentification, fournissez un identifiant et un mot de passe pour un compte de démonstration offrant toutes les fonctionnalités et contenant des données d’exemple. Les plugins qui nécessitent des étapes de connexion supplémentaires, comme la création d’un compte ou une authentification à deux facteurs via un compte inaccessible, seront refusés.

Commerce et monétisation

Actuellement, les plugins peuvent effectuer des transactions commerciales uniquement pour des biens physiques. La vente de produits ou de services numériques, y compris des abonnements, du contenu numérique, des tokens ou des crédits, est interdite, que ces offres soient proposées directement ou indirectement (par exemple, en incitant à passer d’une offre freemium à une offre payante).

Les utilisateurs peuvent se connecter à un compte payant existant et accéder aux fonctionnalités déjà incluses dans leur abonnement. Les plugins ne doivent pas afficher de formules d’abonnement, lancer de nouveaux abonnements ni promouvoir le passage à une offre supérieure.

Si une fonctionnalité du plugin nécessite une offre ou des droits d’accès différents de ceux de l’utilisateur (par exemple, un autre niveau d’abonnement ou des crédits supplémentaires), le plugin peut l’expliquer. Ces informations devraient aider les utilisateurs à comprendre pourquoi la fonctionnalité n’est pas disponible, sans lancer de parcours de paiement ou de transaction.

Plus précisément, les plugins peuvent :

  • Expliquer qu’une fonctionnalité n’est pas disponible avec l’offre ou les droits d’accès actuels de l’utilisateur.
  • Proposer un lien vers une page d’information décrivant les offres ou les options de droits d’accès disponibles.

Les plugins ne peuvent pas :

  • Proposer un lien direct vers une page de paiement ou une autre page transactionnelle.
  • Proposer un lien vers une page qui lance explicitement le processus de passage à une offre supérieure, de souscription ou de finalisation d’un achat.

Les plugins devraient offrir une expérience de qualité dans ChatGPT. Si une fonctionnalité de votre plugin est également disponible sur votre site web ou votre application externe, vous ne devez pas en proposer une version de moindre qualité dans le plugin. Les plugins ne doivent pas appliquer de frais, de suppléments ou d’autres tarifs propres à ChatGPT qui pénalisent les utilisateurs accédant à un service via ChatGPT. Les remises temporaires et les offres promotionnelles sur d’autres plateformes sont autorisées.

En outre, les plugins ne peuvent pas servir à vendre ou à promouvoir les biens ou services suivants, ni à en faciliter l’accès ou à contribuer de manière substantielle à leur mise à disposition :

Biens interdits

  • Contenus pour adultes et services sexuels
    • Pornographie, contenus sexuellement explicites, services de webcam en direct, abonnements pour adultes
    • Jouets sexuels, poupées sexuelles, accessoires BDSM, produits fétichistes
  • Jeux d’argent
    • Services de jeux d’argent réel, crédits de casino, paris sportifs, jetons de casinos en cryptomonnaies
  • Drogues illégales ou réglementées
    • Produits à base de marijuana ou de THC, psilocybine, substances illégales
    • Produits au CBD dépassant les limites légales de THC
  • Accessoires liés aux drogues
    • Bangs, dispositifs de vaporisation de concentrés de cannabis, balances destinées à la consommation de drogues, matériel de culture du cannabis commercialisé pour la production de drogues
  • Médicaments sur ordonnance et soumis à des restrictions d’âge
    • Médicaments délivrés uniquement sur ordonnance (par exemple, insuline, antibiotiques, Ozempic, opioïdes)
    • Produits sur ordonnance soumis à des restrictions d’âge (par exemple, testostérone, hormone de croissance humaine (HGH), hormones de fertilité)
  • Biens illicites
    • Produits contrefaits ou répliques
    • Biens volés ou articles dont la provenance n’est pas clairement établie
    • Outils de fraude financière (dispositifs de copie de cartes bancaires, faux terminaux de paiement)
    • Outils de piratage ou logiciels crackés
    • Produits de contrebande issus de la faune sauvage ou de ressources naturelles (ivoire, produits issus d’espèces menacées)
  • Logiciels malveillants, logiciels espions et surveillance
    • Logiciels malveillants, rançongiciels, enregistreurs de frappe, logiciels de harcèlement
    • Dispositifs de surveillance clandestine (caméras espionnes, intercepteurs IMSI, traceurs dissimulés)
  • Tabac et nicotine
    • Produits du tabac
    • Produits contenant de la nicotine (cigarettes électroniques, e-liquides, sachets de nicotine)
  • Armes et matériaux dangereux
    • Armes à feu, munitions, pièces d’armes à feu
    • Explosifs, feux d’artifice, matériaux destinés à la fabrication de bombes
    • Armes illégales ou soumises à des restrictions d’âge (couteaux à cran d’arrêt, coups-de-poing américains, arbalètes là où elles sont interdites)
    • Armes d’autodéfense (aérosols au poivre, shockers électriques, tasers)
    • Articles ou propagande à caractère extrémiste

Services interdits à caractère frauduleux, trompeur ou à haut risque

  • Fausses pièces d’identité, faux documents ou services de falsification de documents
  • Montages visant l’allègement des dettes, le rétablissement du crédit ou la manipulation des scores de crédit
  • Services financiers non réglementés, trompeurs ou abusifs
  • Montages de prêt, de frais payables d’avance ou de constitution d’un historique de crédit conçus pour exploiter les utilisateurs
  • Offres de cryptomonnaies ou de NFT impliquant de la spéculation, des pratiques trompeuses envers les consommateurs ou des abus financiers
  • Exécution de transferts d’argent, de transferts de cryptomonnaies ou d’opérations d’investissement
  • Utilisation abusive des services publics, usurpation d’identité ou manipulation des prestations
  • Vol d’identité, usurpation d’identité ou services de surveillance de l’identité facilitant des usages abusifs
  • Certains services juridiques ou quasi juridiques facilitant la fraude, le contournement d’obligations ou les fausses déclarations
  • Pratiques de facturation sauf refus explicite, de télémarketing ou de contournement du consentement
  • Services de voyage présentant un taux élevé de rétrofacturations, propices à la fraude ou abusifs

Paiement

Les plugins doivent utiliser un processus de paiement externe et diriger les utilisateurs vers votre propre domaine pour finaliser leurs achats.

Le paiement instantané, actuellement en version bêta, est réservé à certaines places de marché partenaires. Il pourrait être étendu à d’autres places de marché et commerçants au fil du temps.

En attendant, le paiement externe standard reste obligatoire. Aucune autre solution de paiement tierce ne peut être intégrée ou hébergée dans l’interface du plugin. Pour en savoir plus, consultez notre documentation sur le commerce agentique.

Publicité

Les plugins ne doivent pas diffuser de publicités ni avoir pour vocation principale de servir de support publicitaire. Chaque plugin doit proposer des fonctionnalités claires et légitimes qui apportent une valeur propre aux utilisateurs.

Sécurité

Politiques d’utilisation

Ne participez pas à des activités interdites par les politiques d’utilisation d’OpenAI et ne les facilitez pas. Les plugins doivent éviter les comportements à haut risque susceptibles d’exposer les utilisateurs à des préjudices, à des fraudes ou à des usages abusifs.

Suivez l’évolution des exigences des politiques et veillez à les respecter en permanence. Les plugins déjà approuvés peuvent être retirés si une infraction est constatée par la suite.

Adaptation au public

Les plugins doivent convenir au grand public, y compris aux utilisateurs âgés de 13 à 17 ans. Ils ne doivent pas cibler explicitement les enfants de moins de 13 ans. Les expériences réservées aux adultes (18 ans et plus) seront prises en charge une fois que des mécanismes appropriés de vérification de l’âge et de contrôle seront en place.

Respectez l’intention de l’utilisateur

Proposez des expériences qui répondent directement à la demande de l’utilisateur. N’insérez pas de contenu sans rapport et ne tentez pas de réorienter l’interaction. Limitez la collecte de données à ce qui est raisonnablement nécessaire pour répondre à la demande de l’utilisateur et conforme à votre politique de confidentialité.

Pratiques loyales

Les plugins ne doivent comporter aucune description, aucun titre, aucune annotation d’outil ni aucun autre champ lisible par le modèle, au niveau des outils comme du plugin, qui manipule la manière dont le modèle sélectionne ou utilise d’autres plugins ou leurs outils (par exemple, en lui demandant de privilégier un plugin par rapport aux autres), ou qui entrave leur découverte équitable. Toutes les descriptions doivent refléter fidèlement la valeur du plugin sans dénigrer les autres solutions.

Contenus et intégrations de tiers

  • Accès autorisé : N’extrayez pas de données de sites web externes, ne relayez pas de requêtes et n’intégrez pas d’API tierces sans disposer des autorisations nécessaires et respecter les conditions de service du tiers concerné.
  • Connecteurs non officiels : Nous ne pouvons pas approuver les plugins dont la fonction principale est de servir de connecteurs non officiels à des services tiers, y compris les couches logicielles intermédiaires qui se contentent de relayer les échanges.
  • Contournement : Ne contournez pas les restrictions d’API, les limites de débit ou les contrôles d’accès imposés par le tiers.

Iframes et pages intégrées

Les plugins dotés d’une interface utilisateur peuvent intégrer des pages du domaine enregistrable de leur propre serveur MCP, y compris des éditeurs et des interfaces d’administration existants dans leur intégralité. Par exemple, un serveur à l’adresse https://api.example.com/mcp peut intégrer https://app.example.com : tous deux utilisent le domaine enregistrable example.com. Des locataires distincts sur un service d’hébergement partagé sont considérés comme des domaines différents ; le recours au même hébergeur ne prouve pas que les domaines appartiennent au même propriétaire.

Déclarez chaque origine d’iframe requise dans la CSP de la ressource à l’aide de _meta.ui.csp.frameDomains (ou de l’ancien champ _meta["openai/widgetCSP"].frame_domains). Pour les domaines tiers, les intégrations par iframe devraient se limiter aux cas où l’expérience intégrée est essentielle.

Vous devez toujours fournir une justification lorsque vous soumettez un plugin qui utilise des iframes. Expliquez le rôle de chaque page intégrée, pourquoi le plugin l’intègre et qui contrôle son domaine. L’utilisation d’iframes peut nécessiter une révision supplémentaire ou une transmission à un niveau supérieur, et peut retarder l’approbation ou entraîner un rejet si le contenu ne peut pas être évalué. Le fait de partager le domaine du serveur MCP ne garantit pas l’approbation.

Toutes les autres exigences applicables aux plugins restent valables pour les pages intégrées, y compris celles relatives au paiement et à la confidentialité.

Confidentialité

Politique de confidentialité

Toute soumission de plugin doit inclure une politique de confidentialité claire et publiée, précisant au minimum les catégories de données personnelles collectées, les finalités de leur utilisation, les catégories de destinataires, les durées de conservation des données et les moyens de contrôle proposés aux utilisateurs. Respectez cette politique en permanence. Les utilisateurs peuvent consulter votre politique de confidentialité avant d’installer le plugin.

Collecte de données

  • Minimisation de la collecte : Ne collectez que les données strictement nécessaires à la fonction de l’outil. Les entrées doivent être précises, limitées et explicitement liées à la tâche. Évitez les champs prévus « au cas où » ou les données de profil trop générales. Concevez le schéma d’entrée pour limiter la collecte de données par défaut, plutôt que pour recueillir du contexte facultatif.
  • Minimisation des réponses : Les réponses des outils doivent contenir uniquement des données directement pertinentes pour la demande de l’utilisateur et la finalité déclarée de l’outil. N’incluez pas d’identifiants de diagnostic, de télémétrie ou internes, tels que les identifiants de session, de trace ou de requête, les horodatages ou les métadonnées de journalisation, sauf s’ils sont strictement nécessaires pour répondre à la demande de l’utilisateur.
  • Données soumises à restriction : Ne collectez, ne sollicitez et ne traitez aucune des catégories suivantes de données soumises à restriction :
    • Informations soumises aux normes de sécurité des données de cartes de paiement (PCI DSS)
    • Informations de santé protégées (PHI)
    • Identifiants délivrés par les autorités publiques (tels que les numéros de sécurité sociale)
    • Identifiants d’accès et secrets d’authentification (tels que les clés API, les codes d’authentification multifacteur (MFA) ou à usage unique (OTP), ou les mots de passe).
  • Données sensibles réglementées : Ne collectez pas de données personnelles considérées comme « sensibles » ou relevant d’une « catégorie particulière » dans la juridiction où elles sont collectées, sauf si leur collecte est strictement nécessaire à la fonction déclarée de l’outil, si l’utilisateur a donné un consentement juridiquement valable et si la collecte et l’utilisation sont signalées de manière explicite et bien visible au moment de la collecte ou avant celle-ci.
  • Limites d’accès aux données :
    • Évitez de demander des champs de localisation bruts (par exemple, une ville ou des coordonnées) dans votre schéma d’entrée. Si la localisation est nécessaire, obtenez-la par le canal auxiliaire contrôlé du client (par exemple, les métadonnées de l’environnement ou une ressource référencée), afin de permettre l’application des règles et des contrôles de consentement appropriés. Cela réduit la collecte accidentelle de données permettant d’identifier une personne, impose le principe du moindre privilège et permet d’auditer le traitement de la localisation et d’en révoquer l’accès.
    • Votre serveur MCP ne doit ni récupérer, ni reconstituer, ni déduire l’intégralité de l’historique de discussion à partir du client ou d’une autre source. Utilisez uniquement les extraits et les ressources que le client ou le modèle choisit explicitement d’envoyer. Cette séparation peut aider à empêcher l’élargissement à l’insu de l’utilisateur du périmètre des données et à limiter l’analyse au contenu partagé intentionnellement.

Transparence et contrôle par l’utilisateur

  • Pratiques relatives aux données : N’effectuez aucune surveillance, aucun suivi ni aucun profilage comportemental, y compris la collecte de métadonnées telles que les horodatages, les adresses IP ou les habitudes de requête, sauf si ces pratiques sont explicitement signalées, strictement délimitées, soumises à un contrôle effectif de l’utilisateur et conformes aux politiques d’utilisation d’OpenAI.
  • Étiquetage exact des actions : Signalez tout outil qui modifie un état externe (création, modification, suppression) comme une action d’écriture. Vous ne devez signaler un outil comme une action en lecture seule que s’il est sans effet de bord et peut être réexécuté sans risque. Les actions destructives nécessitent un étiquetage clair et des étapes de validation (par exemple, une confirmation) afin que les clients puissent appliquer des garde-fous, exiger des approbations ou des confirmations, ou afficher des invites avant l’exécution.
  • Prévention de l’exfiltration de données : Toute action qui envoie des données hors du périmètre actuel (par exemple, publier des messages, envoyer des e-mails ou téléverser des fichiers) doit être signalée au client comme une action d’écriture, afin qu’il puisse exiger une confirmation de l’utilisateur ou l’exécuter en mode aperçu. Cela réduit les fuites de données involontaires et rend le comportement du serveur conforme aux exigences de sécurité côté client.

Vérification des développeurs

Vérification

Toutes les soumissions de plugins doivent provenir de personnes ou d’organisations vérifiées. Dans les paramètres généraux du tableau de bord de la plateforme OpenAI, nous vous permettons de confirmer votre identité et votre affiliation à toute entreprise au nom de laquelle vous souhaitez publier. Toute fausse déclaration, tout comportement dissimulé ou toute tentative de contourner les règles du système peut entraîner une exclusion du programme.

Coordonnées de l’assistance

Vous devez fournir les coordonnées de votre assistance clientèle afin que les utilisateurs finaux puissent vous contacter pour obtenir de l’aide. Veillez à ce que ces informations restent exactes et à jour.