GPT Actions : laisser ChatGPT appeler vos API

Les GPT Actions permettent à un GPT personnalisé d'appeler des 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 → externes que vous décrivez : au lieu de deviner, ChatGPT récupère des données en direct ou déclenche un vrai système pour vous. Vous écrivez une petite spécification OpenAPI, vous la pointez vers votre endpoint, vous configurez l'authentification, et le modèle décide quand l'appeler au cours d'une conversation.

C'est la même mécanique que le function calling dans l'API, mais packagée pour le builder no-code de Custom GPT. **Vous définissez les *tools*, ChatGPT gère le *quand* et le *comment***.

Ce qu'est réellement une Action

Une Action est un ou plusieurs endpoints HTTP exposés à un GPT via une [spécification OpenAPI](https://platform.openai.com/docs/actions/introduction). OpenAPI (anciennement Swagger) est une description standard, lisible par machine, d'une API REST : ses paths, paramètres, corps de requête et réponses.

Quand vous ajoutez une Action à un GPT, trois choses se produisent au runtime :

1. Le modèle lit vos descriptions d'opérations et décide qu'un appel est nécessaire.
2. ChatGPT construit la requête HTTP (en remplissant les paramètres à partir de la conversation), y attache l'authentification et l'envoie.
3. Votre API répond en JSON, et le modèle lit ce JSON pour rédiger sa réponse.

Le modèle ne voit jamais votre serveur. Il ne voit que le 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 → que vous lui avez donné et la réponse qui revient. Autrement dit, **vos champs description ne sont pas de la documentation, ce sont des *prompts*. Des descriptions vagues produisent des appels erronés**.

Où se configurent les Actions

Les Actions se configurent dans l'éditeur de GPT sur chatgpt.com (Explore GPTs, Create, puis l'onglet Configure). Descendez jusqu'à Actions et cliquez sur Create new action. Vous collez un schéma, choisissez un type d'authentification, et ChatGPT le valide sur le champ.

Ne confondez pas les Actions avec les Connectors. Les Connectors sont des intégrations préconstruites et gérées par OpenAI (Google Drive, SharePoint, GitHub, etc.) qui font entrer des données *dans* ChatGPT pour la recherche et la récupération. Les Actions sont *vos* appels d'API personnalisés, définis par vous. Utilisez un Connector quand il en existe un pour la source ; construisez une Action quand vous devez taper sur votre propre backend ou déclencher quelque chose.

Un exemple concret : consultation du statut d'une commande

Admettons que votre équipe support veuille un GPT qui répond à « Où est la commande 10428 ? » en appelant votre API interne de commandes. Votre endpoint existe déjà :

GET https://api.acme-shop.com/v1/orders/{orderId}

Il renvoie quelque chose comme :

{
  "orderId": "10428",
  "status": "shipped",
  "carrier": "DHL",
  "trackingNumber": "JD0149...",
  "estimatedDelivery": "2026-02-14"
}

Vous décrivez maintenant cet endpoint au GPT. Voici un schéma OpenAPI 3.1 propre et minimal, que vous pouvez coller directement dans l'éditeur d'Actions :

openapi: 3.1.0
info:
  title: Acme Orders API
  version: 1.0.0
servers:
  - url: https://api.acme-shop.com/v1
paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      summary: Get the current status and tracking info for one order.
      description: >
        Look up a single order by its numeric ID. Use this whenever a
        user asks where their order is, its delivery date, or its
        shipping status. Returns status, carrier, and tracking number.
      parameters:
        - name: orderId
          in: path
          required: true
          description: The order's numeric ID, e.g. 10428.
          schema:
            type: string
      responses:
        "200":
          description: Order found.
          content:
            application/json:
              schema:
                type: object
                properties:
                  orderId: { type: string }
                  status: { type: string }
                  carrier: { type: string }
                  trackingNumber: { type: string }
                  estimatedDelivery: { type: string, format: date }
        "404":
          description: No order with that ID exists.

Quelques éléments font de ce schéma un bon schéma, et pas seulement un schéma valide :

• `operationId` est descriptif. getOrderStatus parle mieux au modèle que get1. C'est ce qui devient le nom de la fonction.
• La `description` dit au modèle quand l'utiliser. Notez la phrase « Use this whenever a user asks... ». C'est du routage d'intention.
• Le `404` est documenté. Quand le modèle reçoit un 404, il peut dire à l'utilisateur « Je n'ai pas trouvé cette commande » au lieu d'halluciner un statut.

Une fois enregistré, ChatGPT affiche l'opération disponible. Testez-la en posant une question naturelle au GPT. La première fois qu'il appelle un nouveau domaine, ChatGPT demande à l'utilisateur de confirmer, puis envoie la requête.

Authentification

Les Actions prennent en charge trois modes d'authentification dans le builder : None, API Key et OAuth. Le schéma ci-dessus déclare *quoi* appeler ; l'authentification contrôle *comment vous prouvez qui vous êtes*.

API Key

L'option sécurisée la plus simple. Vous collez une clé dans l'éditeur de GPT, choisissez comment elle est envoyée (header Bearer, Basic, ou un header personnalisé), et OpenAI la stocke chiffrée. ChatGPT l'attache à chaque appel. Ajoutez un bloc securitySchemes correspondant à votre schéma :

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
security:
  - bearerAuth: []

La clé est partagée par tous ceux qui utilisent le GPT. C'est acceptable pour un endpoint interne en lecture seule protégé par vos propres contrôles réseau. Ce n'est *pas* acceptable quand chaque utilisateur ne doit voir que ses propres données, car le modèle agirait avec une identité unique partagée.

OAuth

Quand vous avez besoin d'une identité par utilisateur (chaque agent de support, ou chaque client, s'authentifiant en son nom), utilisez OAuth. Vous fournissez l'URL d'autorisation, l'URL de tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →, le client ID, le client secret et les scopes. ChatGPT déroule le flow OAuth standard : l'utilisateur clique sur Sign in, approuve l'accès sur votre serveur d'authentification, et ChatGPT stocke le token de cet utilisateur. Les appels portent alors les permissions *de cet utilisateur*.

C'est le bon choix pour tout ce qui écrit des données ou expose des enregistrements privés. La configuration complète est dans la documentation d'authentification des Actions.

Une note sur les secrets et les rate limits

Ne mettez jamais d'identifiants dans le schéma lui-même ni dans les instructions du GPT. Quiconque peut utiliser un GPT peut parfois l'amener à révéler sa configuration. Gardez les secrets dans les champs d'authentification dédiés, et protégez votre endpoint avec son propre rate limiting. Un GPT populaire peut générer un trafic réel, et le modèle peut réessayer en cas d'erreur.

Concevoir l'API pour un modèle, pas pour un humain

Une API REST conçue pour des ingénieurs et une API conçue pour un LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → diffèrent de façon subtile. Resserrez ces points :

• Renvoyez du JSON petit et plat. La réponse entre dans la fenêtre de contexte et coûte des tokens. Supprimez les champs dont le modèle n'a pas besoin. Une consultation de commande n'a pas besoin de tout l'audit log.
• Utilisez des noms de champs clairs. estimatedDelivery vaut mieux que est_dlv_dt. Le modèle raisonne sur les noms.
• Rendez les erreurs lisibles. Renvoyez un message lisible par un humain en cas d'échec, pour que le modèle puisse le relayer.
• Gardez des opérations étroites. Un endpoint qui fait cinq choses brouille le routage. Préférez getOrderStatus, cancelOrder et getInvoice comme opérations séparées avec des descriptions séparées.

Une conséquence à intérioriser : **le modèle ne peut faire que ce que votre schéma *décrit***. Si vous voulez qu'il annule des commandes, il vous faut une opération cancelOrder (un POST ou un DELETE) avec sa propre description et, idéalement, OAuth pour que l'action s'exécute en tant qu'utilisateur réel ayant la permission d'annuler.

Actions à conséquence et confirmation

Certains appels sont en lecture seule. D'autres changent le monde : rembourser un paiement, envoyer un e-mail, supprimer un enregistrement. ChatGPT les traite différemment.

Par défaut, ChatGPT demande à l'utilisateur de confirmer avant d'appeler une Action sur un nouveau domaine. Pour les écritures, vous voulez ce frottement. Vous pouvez marquer des opérations pour que l'utilisateur doive confirmer chaque fois, ce qui est une bonne pratique pour tout ce qui est destructif. Traitez chaque `POST`, `PUT`, `PATCH` et `DELETE` comme à conséquence jusqu'à preuve du contraire, et concevez votre endpoint de sorte qu'une étape de confirmation soit peu coûteuse (par exemple un flow en deux appels : un pour prévisualiser, un pour valider).

Gardez une frontière claire en tête. Le GPT raisonne sur vos descriptions et peut appeler la mauvaise opération ou passer le mauvais argument. **Votre *serveur* est la véritable autorité**. Validez chaque requête côté serveur : vérifiez que la commande appartient à l'utilisateur authentifié, que le montant est dans les limites, que l'ID est bien formé. Ne supposez jamais que le modèle a vu juste.

Lien avec l'API et l'Agents SDK

Les Actions sont la surface Custom GPT pour l'usage d'outils. Sous le capot, la même idée alimente l'API OpenAI, où vous définissez des tools sous forme de schémas JSON et où le modèle renvoie un appel d'outil structuré que votre code exécute. Si vous dépassez les limites du builder de GPT (vous avez besoin de logique personnalisée entre les appels, de votre propre UI, ou d'orchestration sur de nombreux tools), vous passez à l'[API Responses](https://platform.openai.com/docs/api-reference/responses) ou à l'[Agents SDK](https://platform.openai.com/docs/guides/agents-sdk), où vous contrôlez la boucle directement.

Le chemin de migration est propre : les descriptions et les schémas de paramètres que vous avez écrits pour une Action se traduisent presque directement en définitions de tools dans le code. Voyez les GPT Actions comme la version hébergée, sans orchestration serveur, du même pattern. Prototypez une intégration en Action, puis faites-la passer à l'Agents SDK quand vous avez besoin d'un contrôle total.

Déboguer les Actions

Quand un appel se comporte mal, parcourez ces points dans l'ordre :

1. Le modèle l'a-t-il appelé du tout ? S'il a répondu au jugé, votre description est trop faible ou trop générique. Ajoutez la phrase déclencheuse explicite « Use this when... ».
2. Mauvais paramètres ? Vérifiez les champs description des paramètres et leurs types. L'ambiguïté ici produit des requêtes malformées.
3. Échecs d'authentification ? Testez l'endpoint avec exactement la même clé ou le même token en dehors de ChatGPT (un appel curl) pour isoler si le problème vient de votre authentification ou de la configuration du GPT.
4. Schéma rejeté à l'enregistrement ? L'éditeur valide contre OpenAPI 3.1. Collez votre YAML dans un validateur externe pour trouver la ligne fautive.

Une vérification curl rapide avant même de toucher au builder :

curl -s https://api.acme-shop.com/v1/orders/10428 \
  -H "Authorization: Bearer $ACME_TOKEN"

Si ça renvoie du JSON propre, le côté GPT n'est plus qu'une affaire de schéma et de configuration d'authentification.

Points clés

• Écrivez les descriptions comme des prompts, pas comme de la doc. Les champs operationId, summary et description sont ce qui permet au modèle de décider quand et comment appeler votre API. Incluez une phrase explicite « Use this when... » dans chaque opération.
• Adaptez l'authentification aux besoins d'identité. Utilisez API Key pour des endpoints internes partagés en lecture seule ; utilisez OAuth dès que chaque utilisateur doit agir en son nom ou que l'action écrit des données.
• Traitez le modèle comme une entrée non fiable. Validez chaque requête côté serveur et marquez les opérations d'écriture comme à conséquence, pour que les utilisateurs confirment avant tout changement.
• Gardez des réponses petites et plates. Ne renvoyez que les champs dont le modèle a besoin ; la réponse consomme des tokens de contexte et le modèle raisonne sur vos noms de champs.
• Prototypez en Action, passez à l'Agents SDK. Les mêmes schémas se reportent : commencez dans le builder de GPT et passez au code quand vous avez besoin d'orchestration ou de logique personnalisée entre les appels.