Authentification et Sécurité des Actions

État au 5 novembre 2026 : les GPTs vivent leurs dernières semaines. OpenAI retire les GPTs personnalisés le 11 décembre 2026 (le 11 février 2027 pour certains espaces Enterprise bénéficiant d’une dérogation). Les comptes personnels, Free, Go, Plus et Pro, ne peuvent plus créer ni publier de nouveaux GPTs ; dans les espaces Business, Enterprise et Edu, la création dépend des réglages, et elle a cessé le 26 octobre 2026 dans les espaces Enterprise concernés. Les GPTs existants restent utilisables, et modifiables si votre offre le permet, jusqu’à leur retraite ; vos conversations avec eux resteront accessibles ensuite. La migration (Migrate to plugin, dans My GPTs) transforme les instructions en skill, la base de connaissances en fichiers de référence et les applications connectées en apps ; les actions personnalisées ne sont pas transférées. Cette leçon décrit le fonctionnement des GPTs pour vous aider à les maintenir, à les migrer et à transposer leurs principes dans un plugin (leçons 15 à 17).

Pourquoi l’authentification est indispensable

Dans la leçon précédente, vous avez connecté votre GPT à une API publique — un cas confortable, car l’API répondait à n’importe qui. La réalité professionnelle est différente : votre CRM, votre calendrier, votre base de données exigent une preuve d’identité avant de livrer la moindre donnée. C’est une évidence quand on y pense — vous ne voudriez pas que n’importe quel GPT puisse lire vos fiches clients. Sans authentification correctement configurée, votre GPT recevra des refus d’accès au lieu de données. Cette leçon couvre les trois modes d’authentification des actions, puis les règles de sécurité qui doivent accompagner toute Action.

Les trois modes d’authentification

Le premier mode, aucune authentification, correspond au cas de la leçon précédente : des API publiques qui n’exigent pas d’identification, comme certaines API météo, des données ouvertes ou des services gratuits. Réservez-le au prototypage et aux API réellement publiques — aucun outil professionnel sérieux ne fonctionne ainsi.

Le deuxième mode, la clé API (API Key), est le plus courant en pratique. Le principe : le service externe vous délivre une clé secrète, que le GPT joint à chaque requête pour prouver son identité. Dans l’éditeur, la configuration d’une clé d’API se règle en quelques champs, et la clé peut être transmise en Basic, en Bearer ou dans un en-tête personnalisé :

• Auth Type : API Key
• API Key : votre clé (elle sera stockée de manière sécurisée par OpenAI)
• Header name : le nom de l’en-tête, généralement Authorization, X-API-Key ou api-key
• Prefix : le préfixe éventuel, souvent Bearer avec un espace

Une fois ces champs remplis, le GPT ajoute automatiquement la clé à chaque appel. Point important pour la confidentialité : l’utilisateur final ne voit jamais la clé — c’est votre identité qui est utilisée, quelle que soit la personne qui converse avec le GPT.

Le troisième mode, OAuth 2.0, répond à un besoin différent : faire agir le GPT au nom de chaque utilisateur, et non au vôtre. C’est le mécanisme des services comme Google, Microsoft ou Salesforce. Concrètement, quand un utilisateur lance le GPT pour la première fois, il est redirigé vers la page de connexion du service externe, où il autorise lui-même l’accès à ses propres données. La configuration demande les éléments fournis par le service : un Client ID et un Client Secret, l’Authorization URL (la page de connexion), la Token URL (l’échange du jeton) et le Scope, c’est-à-dire les permissions demandées — lecture seule, lecture/écriture, etc. C’est plus lourd à mettre en place qu’une clé API, mais c’est le seul mode correct dès que chaque utilisateur doit accéder à ses propres données.

Sécuriser vos Actions

Connecter un GPT à vos outils, c’est lui confier un accès — et tout accès mérite des garde-fous. Le premier est le principe du moindre privilège : ne demandez que les permissions strictement nécessaires. Si votre GPT doit uniquement lire des contacts CRM, une permission d’écriture est un risque gratuit ; s’il consulte un calendrier, il n’a rien à faire dans les emails. Côté OAuth, cela se traduit par des scopes réduits au minimum — un détail qui compte doublement, car un GPT qui réclame des permissions démesurées effraie aussi les utilisateurs au moment de l’autorisation.

Le deuxième garde-fou concerne vos clés API elles-mêmes. La règle absolue : ne collez jamais une clé dans les instructions du GPT. Les instructions sont extractibles par n’importe quel utilisateur un peu curieux — il suffit souvent de demander au GPT de les réciter — et votre clé se retrouverait publique. Utilisez exclusivement le champ d’authentification sécurisé de l’éditeur. Dans le même esprit, créez une clé dédiée à votre GPT, distincte de vos clés personnelles : le jour où vous devrez la révoquer, vos autres outils continueront de fonctionner. Et si le service le permet, posez des limites de taux (rate limits) sur cette clé, pour qu’un usage anormal ne puisse pas dégénérer.

Troisième garde-fou : encadrer les opérations d’écriture. Si votre API permet de créer, modifier ou supprimer des données, le GPT peut le faire — y compris par erreur d’interprétation. Inscrivez des verrous directement dans les instructions : « Demande toujours confirmation avant de créer un contact dans le CRM », « Ne supprime jamais de données sans validation explicite de l’utilisateur », ou encore « Limite les modifications à 5 par conversation ». Ces phrases anodines sont ce qui sépare un incident bénin d’une base de données saccagée.

Un dernier point, réglementaire celui-là : si vous publiez en public un GPT qui utilise des Actions, OpenAI exige une URL vers une politique de confidentialité. Elle doit expliquer quelles données sont collectées via les Actions, comment elles sont traitées et qui y a accès. Sans elle, votre GPT sera refusé du GPT Store.

À vous de jouer : une chaîne complète en lecture seule

Une clé dédiée, un accès minimal. Le meilleur exercice consiste à monter une chaîne complète en conditions réelles mais sans risque. Créez un compte développeur sur un service disposant d’une API — Airtable, Notion ou HubSpot conviennent bien — et générez un jeton ou une clé d’accès dédiés, avec des permissions minimales, en lecture seule. Configurez ensuite l’authentification par clé API dans votre GPT, puis testez un appel simple, comme lire une liste de données. Terminez par une vérification que trop de créateurs négligent : ouvrez les logs du service et confirmez que les appels proviennent bien de votre GPT. Cette habitude de surveiller l’usage vous servira ensuite en continu, pour détecter un comportement anormal ou une sur-consommation avant qu’ils ne deviennent un problème.

Sources officielles : Configuring actions in GPTs (centre d’aide OpenAI : authentification, schéma OpenAPI, test, limites) · Sharing and publishing GPTs (politique de confidentialité exigée pour les actions publiques)

Points clés à retenir

• Trois modes d’authentification : aucun, clé API, OAuth 2.0
• Appliquez le principe du moindre privilège — ne demandez que les permissions nécessaires
• Ne mettez jamais de clés API dans les instructions du GPT
• Ajoutez des garde-fous pour les opérations d’écriture et de suppression
• Toute action d’un GPT partagé publiquement doit avoir une URL de politique de confidentialité valide