Partage, gouvernance et GPTs personnalisés en entreprise

Un GPT personnalisé ne peut exister que dans trois états : privé, partagé par lien à quiconque possède l'URL, ou publié sur le GPT Store. C'est en se trompant d'état qu'un GPT de sales enablement finit par indexer vos tarifs non encore publiés, ou qu'un « petit assistant interne » devient une charge de support que personne ne prend en main. Cette leçon porte sur la façon de faire les bons choix avant qu'une équipe ne dépende de l'outil.

Les trois états de visibilité, précisément

Quand vous construisez un GPT dans l'éditeur, la fenêtre Partager vous propose :

• Moi uniquement (privé) : le réglage par défaut. Le GPT n'existe que dans votre compte.
• Toute personne disposant du lien : utilisable par quiconque possède l'URL. Sur un plan personnel, cela peut être public. Au sein d'un workspace Team ou Enterprise, « lien » signifie lien *à l'intérieur du workspace*, sauf si votre admin autorise le partage externe.
• GPT Store : publié et découvrable. Sur Team/Enterprise, vous pouvez publier dans le store interne de votre workspace plutôt que dans le store public.

La distinction qui fait trébucher : à l'intérieur d'un workspace, le partage est borné par le workspace. Un GPT partagé par lien est accessible à vos collègues, pas à l'internet ouvert, dès lors que votre admin a verrouillé le partage externe. Vérifiez cette hypothèse avant de considérer que « lien uniquement » veut dire « interne uniquement ». Voir la présentation d'OpenAI sur les GPTs personnalisés dans Team et Enterprise.

Ce qui circule réellement quand vous partagez

C'est le point que la plupart des crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éateurs comprennent de travers. Quand vous partagez un GPT, vous partagez sa configuration : les instructions, les amorces de conversation, les capacités activées (recherche web, Code Interpreter, génération d'images), les éventuelles Actions (appels d'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → qu'il peut effectuer) et tous les fichiers chargés dans sa Knowledge.

Ces fichiers de Knowledge comptent. Si vous avez chargé un tableur de marges internes pour que le GPT puisse raisonner dessus, chaque utilisateur de ce GPT peut extraire ce contenu. Un utilisateur déterminé peut demander au GPT d'afficher ses instructions ou de restituer mot pour mot ses fichiers de knowledge, et il le fera souvent. Considérez tout ce qui se trouve dans la configuration d'un GPT comme lisible par quiconque peut l'utiliser.

Un scénario de déploiement concret

Rendons cela tangible. Votre équipe RevOps veut un GPT « Deal Desk Assistant » qui aide les account executives à rédiger des demandes de validation de devis. Il doit :

1. Répondre aux questions portant sur une politique interne de remises (un PDF).
2. Récupérer des données de deals en direct depuis votre CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète →.
3. Rédiger une demande de validation structurée.

Voici comment les trois enjeux (partage, gouvernance, données/sécurité) se déclinent tout au long de cette construction.

Étape 1 : décider de l'audience d'abord, pas en dernier

L'audience est « les AE de notre workspace », pas le public. Il s'agit donc d'un GPT publié dans le workspace, détenu par le compte admin RevOps, et non par une personne qui pourrait quitter l'entreprise. La propriété relève de la gouvernance : un GPT détenu par un collaborateur parti est un GPT que plus personne ne peut mettre à jour.

En Enterprise, un admin peut définir qui a le droit de *créererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète →* et de *publier* des GPTs, et peut passer en revue ce qui est publié dans le store interne. Si vous êtes le créateur, renseignez-vous sur la politique de votre workspace avant d'investir une semaine dans quelque chose que la DSI bloquera.

Étape 2 : la politique de remises (Knowledge, pas copier-coller)

Vous joignez le PDF de la politique en Knowledge. Deux questions de sécurité se posent immédiatement :

• Ce PDF peut-il être lu intégralement par chaque AE ? S'il contient des seuils réservés à la direction, scindez le document. Ne mettez dans le GPT que les règles destinées aux AE.
• Le GPT va-t-il divulguer le fichier ? Ajoutez une instruction déconseillant les restitutions mot pour mot, mais ne comptez pas là-dessus comme mesure de contrôle. Le vrai contrôle consiste à *ne pas charger ce que l'audience ne devrait pas avoir.*

Étape 3 : données CRM en direct (c'est une Action)

Un PDF statique, c'est simple. C'est avec les données en direct que la gouvernance devient sérieuse. Pour récupérer des enregistrements de deals, le GPT a besoin d'une GPT Action : un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → OpenAPI décrivant un endpoint que le GPT peut appeler, plus une méthode d'authentification.

Voici un schéma d'Action minimal pour une consultation de deal en lecture seule :

openapi: 3.1.0
info:
  title: Deal Lookup
  version: "1.0.0"
servers:
  - url: https://api.internal.example.com
paths:
  /deals/{dealId}:
    get:
      operationId: getDeal
      summary: Fetch a single deal by ID
      parameters:
        - name: dealId
          in: path
          required: true
          schema: { type: string }
      responses:
        "200":
          description: Deal record
          content:
            application/json:
              schema:
                type: object
                properties:
                  id: { type: string }
                  amount: { type: number }
                  stage: { type: string }
                  discountPct: { type: number }

Trois règles de gouvernance pour les Actions, plus importantes que le schéma :

• Authentifiez correctement. Les GPT Actions prennent en charge les clés d'API et OAuth. Pour un accès par utilisateur (afin que le GPT ne voie que les deals accessibles à un AE donné), utilisez OAuth pour que la requête s'exécute au nom de l'utilisateur connecté, et non avec une clé de service partagée. Une clé partagée signifie que tous les AE interrogent avec les mêmes permissions, ce qui accorde généralement trop de droits.
• Limitez l'endpoint à la lecture seule. Ce GPT ne doit jamais appeler un endpoint qui *modifie* un deal. Exposez GET, pas POST/DELETE. Plus la surface d'API est réduite, plus le rayon d'impact est faible.
• Attention à la sortie des données. Quand le GPT appelle votre Action, il envoie les données de la requête aux serveurs d'OpenAI pour générer la réponse. Vérifiez que ce flux est acceptable au regard de votre politique de données. Les données métier du workspace ne servent pas par défaut à entraîner les modèles d'OpenAI sur Team/Enterprise, mais « non utilisé pour l'entraînement » est différent de « ne quitte jamais votre réseau ». Elles quittent bien votre réseau. Consultez les engagements de confidentialité Enterprise.

Étape 4 : le brouillon structuré (capacités)

La tâche « rédiger une demande de validation » gagne à avoir une forme constante. Dans les instructions du GPT, précisez le modèle de sortie exact. Vous n'obtenez pas dans un GPT personnalisé les structured outputs contraints par schéma JSON de l'API, c'est une fonctionnalité de l'API, mais une instruction bien spécifiée plus une amorce de conversation vous donnent un formatage fiable pour des brouillons destinés à des humains.

Si l'équipe a plus tard besoin d'une sortie lisible par machine *garantie* (par exemple pour classer automatiquement les validations), c'est le signal pour passer d'un GPT personnalisé à une intégration API utilisant la Responses API avec structured outputs. Voir plus bas sur cette frontière.

Questions de gouvernance à trancher avant le lancement

Déroulez cette checklist avec la personne qui porte le risque. Aucun de ces points n'est optionnel pour un GPT sur lequel une équipe s'appuie.

Classification des données. Quelle est la donnée la plus sensible que ce GPT peut toucher, via les fichiers de Knowledge *et* via les Actions ? Classifiez à ce niveau et appliquez vos règles de traitement existantes. Le GPT ne bénéficie pas d'une exemption particulière.

Identité et accès. Qui peut l'utiliser ? En Enterprise, l'accès aux GPTs peut être cadré, et le SSO gouverne qui figure dans le workspace tout court. Vérifiez que l'offboarding (un départ) retire effectivement l'accès. C'est le cas si l'accès passe par le workspace, mais vérifiez pour les GPTs partagés par lien.

Auditabilité. Les workspaces Enterprise offrent des contrôles admin, une visibilité sur l'usage et la Compliance API pour récupérer les conversations et les données d'audit. Si vous devez pouvoir répondre à « qui a interrogé le Deal Desk Assistant au sujet du deal X », il vous faut cela en place *avant* le lancement, pas après un incident. Voir les fonctionnalités de conformité et d'administration Enterprise.

Memory et Projects. Sachez où réside l'état. La Memory et les instructions personnalisées relèvent du contexte personnel de chaque utilisateur, pas de la configuration partagée du GPT : elles ne fuiteront donc pas entre utilisateurs. Mais si votre équipe travaille dans un Project partagé, les fichiers et instructions ajoutés à ce Project sont partagés avec ses membres. Ne confondez pas un Project (un espace partagé pour des chats et des fichiers) avec un GPT personnalisé (un assistant configuré). Leurs modèles de partage diffèrent.

La frontière des hallucinations. Un Deal Desk Assistant qui *sonne* autoritaire sur la politique de remises peut inventer un seuil avec assurance. Décidez de ce dont il est autorisé à être la source de vérité. Bonne pratique : demandez-lui de citer la section de la politique et de refuser plutôt que de deviner quand la politique est muette.

Quand un GPT personnalisé est le mauvais outil

Les GPTs personnalisés excellent pour les workflows conversationnels avec un humain dans la boucle à l'intérieur de ChatGPT. Ils sont le mauvais outil quand :

• Vous avez besoin de l'embarquer dans un autre produit. Les GPTs vivent dans ChatGPT. Pour mettre un comportement d'assistant dans votre propre application, construisez sur l'API.
• Vous avez besoin d'une sortie structurée garantie ou d'un contrôle programmatique. Utilisez la Responses API avec structured outputs et function calling.
• Vous avez besoin d'autonomie multi-étapes à travers plusieurs outils et de votre propre orchestration. C'est le territoire de l'Agents SDK, ou de l'agent ChatGPT pour des tâches autonomes dans le produit.

Le chemin de migration pour notre scénario : si RevOps veut plus tard que les validations soient classées automatiquement, le même outil OpenAPI devient une function/tool que le modèle appelle par programme. Voici la forme dans la Responses API :

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-4.1",
    input="Draft an approval for deal D-8842 and flag if discount exceeds policy.",
    tools=[{
        "type": "function",
        "name": "getDeal",
        "description": "Fetch a single deal by ID",
        "parameters": {
            "type": "object",
            "properties": {"dealId": {"type": "string"}},
            "required": ["dealId"],
        },
    }],
)

print(response.output_text)

Même logique métier, mais désormais c'est *votre* code qui contrôle l'authentification, exécute l'appel réel à getDeal et peut faire appliquer la politique dans le code plutôt que d'espérer que le prompt tienne. La documentation de la Responses API couvre la boucle complète d'appel d'outils.

La règle empirique : un GPT personnalisé est une configuration partagée, pas une application contrôlée. Dès l'instant où vous avez besoin d'un véritable contrôle d'accès, de garanties d'audit ou d'un comportement déterministe, vous êtes passé dans le domaine de l'API.

Points clés

• Choisissez l'état de visibilité délibérément, et rappelez-vous que tout ce qui est dans la configuration est lisible par chaque utilisateur. Ne chargez jamais de fichiers de Knowledge, et n'inscrivez jamais de secrets en dur, que l'audience ne devrait pas voir intégralement.
• Faites détenir les GPTs au niveau du workspace/admin, pas par un compte personnel. Une dépendance d'équipe détenue par un seul collaborateur meurt avec son départ.
• Utilisez OAuth pour les Actions qui touchent des données cadrées par utilisateur, et gardez les endpoints en lecture seule, sauf si la modification est réellement nécessaire. Réduisez la surface d'API pour réduire le rayon d'impact.
• Déroulez une checklist avant lancement : classification des données, identité/offboarding, audit/Compliance API, et une frontière claire de « source de vérité » pour limiter les hallucinations assurées.
• Sachez quand passer à l'API. Quand vous avez besoin d'une structure garantie, d'une intégration dans votre propre produit ou d'un contrôle d'accès appliqué, passez du GPT personnalisé à la Responses API ou à l'Agents SDK.