Authentification et Sécurité des Actions

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 du GPT Builder, 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 le GPT Builder, la configuration tient en quatre champs :

• 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é du Builder. 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.

Exercice : une chaîne complète en lecture seule

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 une clé API dédiée, 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.

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
• Les GPTs publics avec Actions nécessitent une politique de confidentialité