Règles applicables aux plugins

Vue d’ensemble

L’écosystème des plugins repose sur la confiance. Les utilisateurs de ChatGPT et de Codex s’attendent à trouver des plugins sûrs, utiles et respectueux de leur vie privée. Les développeurs attendent une procédure équitable et transparente. Les présentes règles énoncent les politiques que tout développeur de plugins est tenu de lire et de respecter.

Vous pouvez également consulter les principes présentés dans notre article sur les qualités d’une bonne expérience dans ChatGPT.

Les règles ci-dessous précisent les exigences minimales qu’un plugin publié doit respecter pour rester disponible dans le répertoire commun à ChatGPT et à Codex. Les plugins qui démontrent leur utilité en situation réelle et donnent pleinement satisfaction aux utilisateurs peuvent bénéficier d’une visibilité accrue, par exemple grâce à une mise en avant dans le répertoire ou à des suggestions proactives.

Comment utiliser ces règles

Commencez par les règles de base, qui s’appliquent à tous les plugins. Lisez ensuite les exigences relatives à MCP pour les plugins dotés de serveurs MCP, d’outils ou d’une interface utilisateur facultative, et la section Skills pour les plugins qui contiennent des skills. Si votre plugin contient à la fois des outils MCP et des skills, lisez les deux sections.

Règles de base pour les plugins

Utilité et originalité

Un plugin doit avoir une finalité claire et remplir sa fonction de manière fiable. Il doit notamment proposer des fonctionnalités ou des workflows que les produits ne prennent pas en charge nativement et qui répondent concrètement aux besoins que les utilisateurs expriment couramment en conversation.

Utilisez uniquement des éléments de propriété intellectuelle dont vous détenez les droits ou que vous avez l’autorisation d’utiliser. Évitez les présentations trompeuses ou copiées, l’usurpation d’identité, le spam et les cadres statiques qui ne permettent aucune interaction utile. Les plugins ne doivent pas laisser entendre qu’OpenAI les a créés ou les recommande.

Qualité et fiabilité

Les plugins doivent fonctionner de manière prévisible et fiable. Les résultats doivent être exacts et pertinents au regard de la demande de l’utilisateur. En cas d’erreur, même imprévue, le plugin doit afficher un message clair ou prévoir un comportement de repli.

Les plugins doivent être stables, réactifs et complets. Les plugins proposés en version d’essai ou de démonstration seront refusés.

Nom, description et prompts du plugin

Le nom et la description du plugin doivent être clairs, exacts et faciles à comprendre. Fournissez des exemples de prompts pour aider les utilisateurs à prendre en main votre plugin.

• Noms : évitez les noms trop génériques, en particulier les noms constitués d’un seul mot du dictionnaire sans lien explicite avec votre marque. N’ajoutez pas « MCP », « Serveur MCP » ou « Plugin » à la fin d’un nom d’entreprise ou de produit.
• Sous-titres et descriptions : décrivez les fonctionnalités du plugin sans les comparer à celles d’autres produits, dénigrer les solutions concurrentes ou avancer d’affirmations invérifiables. Ne faites pas la promotion de tarifs, d’abonnements, d’essais gratuits, de remises ou d’offres spéciales.

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 tout comportement à haut risque susceptible de causer un préjudice aux utilisateurs ou de les exposer à une fraude ou à un usage abusif.

Tenez-vous au courant de l’évolution des exigences et veillez à les respecter en permanence. Un plugin déjà approuvé peut être retiré si un manquement est constaté par la suite.

Public visé

Les plugins doivent convenir au grand public, y compris aux utilisateurs 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.

Respect de l’intention de l’utilisateur

Répondez directement à la demande de l’utilisateur. N’insérez aucun contenu sans rapport avec sa demande et ne tentez pas de réorienter l’échange. Limitez la collecte aux données raisonnablement nécessaires pour répondre à la demande, dans le respect de votre politique de confidentialité.

Agissez uniquement dans le cadre de la tâche autorisée par l’utilisateur. Les métadonnées des plugins et des outils ne doivent pas chercher à obtenir des secrets ou des éléments de contexte protégés, ordonner des transferts de données ou des actions non autorisés, passer outre les instructions ou les protections de la plateforme, dissimuler le comportement du plugin ou de l’outil, ni usurper l’identité d’un tiers. Ces exigences s’appliquent également aux plugins dont les instructions sont encodées ou obscurcies.

Concurrence loyale

Aucun champ lisible par le modèle, qu’il s’agisse d’une description, d’un titre, d’une annotation d’outil ou de tout autre champ défini au niveau de l’outil ou du plugin, ne doit manipuler la façon dont le modèle sélectionne ou utilise d’autres plugins ou leurs outils. Par exemple, il est interdit de demander au modèle de privilégier un plugin. Ces champs ne doivent pas non plus compromettre l’équité du processus de découverte des plugins. Toutes les descriptions doivent présenter fidèlement l’utilité 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 d’utilisation du tiers concerné.
• Connecteurs non officiels : nous ne pouvons pas approuver les plugins dont la fonction principale est de servir de connecteur non officiel à 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.

Confidentialité

Politique de confidentialité

Lorsque vous soumettez un plugin, fournissez une politique de confidentialité claire et publique. Elle doit préciser 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 et les moyens de contrôle dont disposent vos utilisateurs. Respectez cette politique en toutes circonstances. Les utilisateurs peuvent la consulter avant d’installer le plugin.

Collecte de données

• Limitation de la collecte : collectez uniquement les données indispensables au fonctionnement du plugin. Chaque champ de saisie doit avoir un objet précis, une portée limitée et un lien explicite avec la tâche. Évitez les champs prévus « au cas où » et la collecte de données générales sur le profil de l’utilisateur.
• Données soumises à restrictions : ne collectez, ne sollicitez et ne traitez aucune donnée relevant des catégories suivantes :
  • Informations soumises à la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS)
  • Informations de santé protégées (PHI)
  • Identifiants délivrés par les autorités publiques (par exemple, les numéros de sécurité sociale)
  • Identifiants d’accès et secrets d’authentification (par exemple, les clés API, les codes d’authentification multifacteur (MFA), les codes à usage unique (OTP) ou les mots de passe).
• Données sensibles réglementées : ne collectez de données personnelles considérées comme « sensibles » ou relevant d’une « catégorie particulière » dans le territoire où elles sont recueillies que si toutes les conditions suivantes sont remplies. La collecte est strictement nécessaire à la fonction déclarée du plugin. L’utilisateur a donné un consentement conforme aux exigences légales. La collecte et l’utilisation des données sont signalées explicitement et de manière bien visible avant ou au moment de la collecte.

Transparence et contrôle par l’utilisateur

• Pratiques relatives aux données : n’effectuez aucune surveillance, aucun suivi ni aucun profilage comportemental, y compris par la collecte de métadonnées telles que les horodatages, les adresses IP ou les habitudes de recherche, sauf si ces pratiques sont explicitement signalées, strictement délimitées, soumises au contrôle effectif de l’utilisateur et conformes aux politiques d’utilisation d’OpenAI.

Commerce et monétisation

Pour le moment, seules les transactions portant sur des biens physiques sont autorisées dans les plugins. La vente de produits ou de services numériques, notamment d’abonnements, de contenus numériques, de jetons ou de crédits, est interdite. Cette interdiction s’applique aux ventes directes et indirectes, par exemple lorsqu’une offre gratuite incite à acheter une version 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 une nouvelle souscription ou promouvoir le passage à une formule supérieure.

Si une fonctionnalité nécessite une formule ou des droits différents de ceux dont dispose l’utilisateur (par exemple, un autre niveau d’abonnement ou des crédits supplémentaires), le plugin peut le préciser. Cette information doit aider l’utilisateur à comprendre pourquoi la fonctionnalité est indisponible sans déclencher de procédure de paiement ou de transaction.

Les plugins peuvent notamment :

• Expliquer qu’une fonctionnalité est indisponible avec la formule ou les droits actuels de l’utilisateur.
• Fournir un lien vers une page d’information qui présente les formules ou les droits d’accès disponibles.

Les plugins ne doivent pas :

• Fournir un lien direct vers une page de paiement ou toute autre page permettant d’effectuer une transaction.
• Fournir un lien vers une page qui lance explicitement la procédure de passage à une formule supérieure, de souscription ou de finalisation d’un achat.

Les plugins doivent offrir une expérience de qualité dans ChatGPT. Si votre site web ou votre application externe propose aussi une fonctionnalité de votre plugin, vous ne devez pas en proposer une version de moindre qualité dans le plugin. Les plugins ne doivent appliquer ni frais, ni majorations, ni autres conditions tarifaires propres à ChatGPT qui pénaliseraient les utilisateurs accédant à un service depuis ChatGPT. Les remises temporaires et les offres promotionnelles sur d’autres plateformes sont autorisées.

Il est également interdit d’utiliser un plugin pour vendre les biens ou services suivants, en faire la promotion, en faciliter la vente 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 avec mises réelles, crédits de casino, paris sportifs, jetons de casinos en cryptomonnaies
• Drogues illégales ou réglementées
  • Produits à base de cannabis ou de THC, psilocybine, substances illégales
  • Produits au CBD dont la teneur en THC dépasse la limite légale
• Matériel destiné à la consommation ou à la production de drogues
  • Pipes à eau, dispositifs pour inhaler des concentrés de cannabis, balances destinées à peser des drogues, matériel de culture du cannabis commercialisé pour la production de drogues
• Médicaments soumis à prescription ou à des restrictions d’âge
  • Médicaments disponibles 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, hormones utilisées dans les traitements de la fertilité)
• Biens illicites
  • Contrefaçons ou répliques de produits
  • Biens volés ou objets de provenance incertaine
  • Dispositifs de fraude financière (lecteurs clandestins de cartes bancaires, faux terminaux de paiement)
  • Outils de piratage ou logiciels dont les protections ont été contournées
  • Produits de contrebande liés à la faune ou à l’environnement (ivoire, produits issus d’espèces menacées)
• Logiciels malveillants, logiciels espions et dispositifs de surveillance
  • Logiciels malveillants, rançongiciels, enregistreurs de frappes, logiciels de traque
  • 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ériels dangereux
  • Armes à feu, munitions, pièces d’armes à feu
  • Explosifs, feux d’artifice, matériel de fabrication de bombes
  • Armes illégales ou soumises à des restrictions d’âge (couteaux à ouverture automatique, coups-de-poing américains, arbalètes là où elles sont interdites)
  • Armes de défense personnelle (bombes au poivre, pistolets à impulsion électrique, tasers)
  • Articles ou propagande à caractère extrémiste

Services frauduleux, trompeurs ou à haut risque interdits

• Fausses pièces d’identité, faux documents ou services de falsification de documents
• Stratagèmes de réduction de dettes, de rétablissement de la cote de crédit ou de manipulation du score de crédit
• Services financiers non réglementés, trompeurs ou abusifs
• Stratagèmes de prêt, de perception de frais à l’avance ou de constitution d’un historique de crédit visant à 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 de fonds, de transferts de cryptomonnaies ou de transactions sur des placements
• Utilisation abusive de services publics, usurpation d’identité ou manipulation des prestations publiques
• Vol d’identité, usurpation d’identité ou services de surveillance de l’identité facilitant des abus
• Certains services juridiques ou assimilés qui facilitent la fraude, le contournement d’obligations ou les fausses déclarations
• Facturation en l’absence de refus explicite, télémarketing ou procédés visant à contourner le consentement
• Services de voyage abusifs, particulièrement exposés à la fraude ou donnant lieu à de nombreuses rétrofacturations

Paiement

Les plugins doivent utiliser un système 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 à l’avenir.

D’ici là, le paiement externe standard est 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 servir principalement de support publicitaire. Chaque plugin doit proposer des fonctionnalités clairement définies et légitimes qui présentent un intérêt en elles-mêmes pour les utilisateurs.

Vérification des développeurs

Vérification

Seules les personnes ou organisations dont l’identité a été vérifiée peuvent soumettre un plugin. Les paramètres généraux du tableau de bord de la plateforme OpenAI vous permettent de confirmer votre identité et votre affiliation à toute entreprise au nom de laquelle vous souhaitez publier. Toute fausse déclaration, dissimulation de comportement ou tentative de détourner le système peut entraîner votre exclusion du programme.

Coordonnées du service d’assistance

Fournissez des coordonnées permettant aux utilisateurs finaux de contacter votre service d’assistance. Vérifiez leur exactitude et tenez-les à jour.

Exigences relatives à MCP

Ces exigences s’appliquent aux plugins qui comprennent des serveurs MCP, des outils ou une interface utilisateur facultative.

Outils

Les outils MCP indiquent à ChatGPT et à Codex comment utiliser les fonctionnalités de votre serveur. Des définitions d’outils claires et exactes rendent le plugin plus sûr, aident le modèle à comprendre son fonctionnement et permettent aux utilisateurs de lui faire confiance.

Noms d’outils clairs et précis

Le nom d’un outil doit être compréhensible, précis et décrire ce que fait réellement l’outil.

• Chaque outil de votre serveur MCP doit porter un nom unique.
• Employez des termes simples qui décrivent directement l’action, de préférence avec un verbe (par exemple, get_order_status).
• Évitez les termes trompeurs, excessivement promotionnels ou comparatifs (par exemple, pick_me, best, official).
• Évitez le jargon interne, les acronymes inexpliqués et les identifiants opaques.

Descriptions fidèles au comportement des outils

Chaque outil doit avoir une description non vide qui précise explicitement et fidèlement sa finalité, son comportement, les situations dans lesquelles l’utiliser et ses éventuelles limites ou effets de bord. La description doit correspondre au schéma de l’outil et à son comportement réel. Si elle ne permet pas de comprendre clairement et entièrement ce comportement, le plugin peut être refusé.

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 de préférence à ceux d’un autre plugin. Elles ne doivent pas recommander d’appeler les outils dans des situations qui dépassent l’intention explicite de l’utilisateur et la finalité du plugin.

Autonomie et exposition des outils

Chaque outil public doit fonctionner de manière autonome. Ne demandez pas au modèle d’appeler un autre plugin ou connecteur pour mener l’opération à bien. Intégrez les dépendances nécessaires à votre plugin.

Exposez chaque opération que le modèle peut appeler sous la forme d’un outil distinct doté d’une description claire, d’un schéma d’entrée et d’annotations. N’associez pas un exécuteur générique à un mécanisme de découverte, de sélection d’opérations ou de récupération de schémas pour permettre l’exécution d’opérations qui ne sont pas présentées individuellement lors de l’examen.

Annotation correcte des outils

Attribuez à readOnlyHint, destructiveHint et openWorldHint des valeurs booléennes explicites (true ou false) dans l’objet annotations de chaque outil. Il n’est plus nécessaire de justifier les annotations. Si notre examen automatisé signale un problème d’annotation, vous pouvez déposer un recours en apportant des précisions ou des informations complémentaires.

• readOnlyHint : utilisez true pour les opérations de récupération de données, les calculs ou les aperçus qui ne modifient pas l’environnement. Utilisez false pour les opérations qui modifient un état externe, enregistrent durablement des artefacts, lancent des tâches ou des workflows avec état, mettent des tâches en file d’attente ou effectuent une écriture vers l’extérieur, comme publier des messages, envoyer des e-mails ou téléverser des fichiers.
• destructiveHint : utilisez false pour les outils en lecture seule. Pour les écritures, utilisez true si les effets peuvent être destructifs ou irréversibles, par exemple en cas de suppression, d’écrasement, d’annulation, de révocation d’accès ou d’envois ou de transactions irréversibles. Utilisez false uniquement pour les écritures qui ajoutent des éléments sans effet destructif ou irréversible. La possibilité d’annuler une action ne suffit pas à justifier de définir destructiveHint sur false.
• openWorldHint : utilisez true pour les outils qui accèdent à des entités publiques ou dont le périmètre n’est pas prédéfini, notamment pour la recherche web en lecture seule ou l’accès à des destinations arbitraires. Un outil dont le périmètre se limite à un compte privé, un espace de travail ou un catalogue bien délimité peut utiliser false, même s’il est hébergé à l’extérieur. La connectivité ne détermine pas à elle seule cette valeur.

Les annotations guident les mécanismes de protection du client. Elles n’accordent aucune permission et ne remplacent ni l’authentification, ni les vérifications d’autorisation et de portée, ni la validation des entrées, ni la confirmation humaine des opérations irréversibles.

Données d’entrée limitées à la tâche

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

• Les champs d’entrée doivent avoir un lien direct avec la finalité déclarée de l’outil.
• Ne demandez pas l’historique complet de la conversation, des transcriptions brutes de discussions ou des champs de contexte généraux « au cas où ». Un outil peut demander un champ décrivant brièvement l’intention de l’utilisateur pour la tâche en cours, uniquement si cette information améliore concrètement l’exécution et si la collecte reste limitée aux données raisonnablement nécessaires pour répondre à la demande et aux finalités décrites dans votre politique de confidentialité.
• Ne demandez pas le contexte cumulé de la conversation ni de tableaux contenant les échanges précédents.
• Si nécessaire, utilisez la localisation géographique approximative fournie par le système. Ne demandez pas de données de localisation précises sur l’utilisateur (par exemple, des coordonnées GPS ou une adresse).

Comportement prévisible et vérifiable

Les outils doivent se comporter exactement comme l’indiquent leur nom, leur description et leurs entrées.

• Les effets de bord ne doivent jamais être cachés ou implicites.
• Dans la mesure du possible, un nouvel appel après un échec doit être sans risque. Si une nouvelle tentative peut reproduire les effets de la première, l’outil doit le signaler explicitement.

Des outils bien conçus réduisent les imprévus, protègent les utilisateurs et accélèrent l’examen du plugin.

Traitement des données par les outils

Concevez le schéma d’entrée de façon à limiter par défaut la collecte de données. Évitez d’y multiplier les champs de contexte facultatifs.

• Limitation des réponses : les outils doivent renvoyer uniquement les données directement pertinentes pour la demande de l’utilisateur et la finalité déclarée de l’outil. N’incluez pas d’identifiants internes, de données de diagnostic ou de télémétrie (par exemple, identifiants de session, de trace ou de requête, horodatages ou métadonnées de journalisation), sauf s’ils sont strictement nécessaires pour répondre à la demande de l’utilisateur.
• Limites d’accès aux données :
  • Évitez de demander des données de localisation brutes (par exemple, une ville ou des coordonnées) dans votre schéma d’entrée. Si la localisation est nécessaire, obtenez-la par un canal distinct contrôlé par le client (par exemple, via les métadonnées de l’environnement ou une ressource référencée) afin de pouvoir appliquer les politiques et les contrôles de consentement appropriés. Cette approche réduit le risque de recueillir accidentellement des informations permettant d’identifier une personne, impose le principe du moindre privilège et permet d’auditer le traitement des données de localisation et d’en révoquer l’accès.
  • Votre serveur MCP ne doit pas récupérer, reconstituer ou déduire l’intégralité de l’historique de discussion à partir du client ou d’une autre source. Traitez uniquement les extraits et les ressources que le client ou le modèle choisit explicitement de transmettre. Cette séparation aide à prévenir tout élargissement dissimulé de la collecte et à limiter l’analyse aux contenus partagés intentionnellement.
• Protections liées aux actions : suivez les règles d’annotation correcte des outils pour signaler les écritures et les actions destructives, demander les confirmations nécessaires et protéger les données sortantes.

Authentification et permissions

Si votre serveur MCP exige une authentification, la procédure doit être transparente et explicite. Informez les utilisateurs de toutes les permissions demandées et limitez-les à celles qui sont nécessaires au fonctionnement du plugin.

Interface utilisateur

Avant d’aborder les détails, consultez les règles relatives aux interfaces utilisateur facultatives. Elles présentent des modèles d’interaction, de mise en page et de conception qui rendent l’interface d’un plugin intuitive, digne de confiance et cohérente avec le reste de ChatGPT.

Iframes et pages intégrées

Les plugins dotés d’une interface utilisateur peuvent intégrer des pages provenant du domaine enregistrable de leur serveur MCP, y compris des éditeurs et des interfaces d’administration existants dans leur intégralité. Par exemple, un serveur situé à l’adresse https://api.example.com/mcp peut intégrer https://app.example.com, car tous deux utilisent le domaine enregistrable example.com. Sur un service d’hébergement mutualisé, les environnements de clients distincts 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 nécessaire dans la CSP de la ressource à l’aide de _meta.ui.csp.frameDomains (ou de l’ancienne propriété _meta["openai/widgetCSP"].frame_domains). Pour les domaines tiers, limitez l’utilisation d’iframes aux cas où la fonctionnalité intégrée est indispensable.

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

Toutes les autres exigences applicables aux plugins s’appliquent également aux pages intégrées, notamment celles relatives au paiement et à la confidentialité.

Tests

Avant de soumettre un plugin, testez soigneusement son serveur MCP, ses outils et, le cas échéant, son interface utilisateur dans des situations variées.

Les plugins, y compris tous leurs composants d’interface, doivent fonctionner de manière fiable dans ChatGPT, sur ordinateur comme sur mobile.

Identifiants de test

Si vous soumettez un plugin dont le serveur MCP exige une authentification, fournissez l’identifiant et le mot de passe d’un compte de démonstration donnant accès à toutes les fonctionnalités et contenant des données d’exemple. Les plugins qui exigent 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.

Skills

Les skills font l’objet d’une analyse automatique et doivent respecter nos politiques de sécurité, de confidentialité et d’utilisation. Les plugins qui contiennent uniquement des skills doivent satisfaire à toutes les exigences ci-dessus relatives aux métadonnées et au référencement. Leur inscription au répertoire peut être soumise à des conditions d’admissibilité supplémentaires.