Connecter Votre GPT à des API Externes

É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).

Dépasser les limites du GPT autonome

Jusqu’ici, votre GPT fonctionne en vase clos : ses instructions définissent son comportement, sa Knowledge lui fournit vos documents. C’est déjà puissant, mais il reste coupé du monde. Il ne peut pas consulter votre CRM en temps réel, créer un événement dans votre calendrier ou interroger votre base de données — il ne connaît que ce que vous avez uploadé, figé au moment de l’upload. Les Actions lèvent cette limite : elles permettent à votre GPT d’appeler des API externes pour lire et écrire des données dans vos outils, pendant la conversation.

Qu’est-ce qu’une Action ?

Une Action est une connexion entre votre GPT et un service externe via son API. Le déroulement est toujours le même : l’utilisateur pose une question ou donne une instruction, le GPT identifie qu’il a besoin de données externes pour y répondre, il appelle l’API du service concerné, puis il reçoit la réponse et l’intègre dans sa formulation finale. Prenons un GPT commercial connecté au CRM : quand un utilisateur demande « Où en est le dossier Dupont ? », le GPT interroge l’API du CRM, récupère la fiche du client, et répond avec les données du jour — pas avec un souvenir de fichier uploadé il y a trois mois. Tout cela se passe de manière transparente pour l’utilisateur, qui a simplement l’impression de parler à un assistant bien informé.

Le schéma OpenAPI

Pour que le GPT sache appeler une API, il faut la lui décrire. C’est le rôle du schéma OpenAPI (anciennement Swagger), un fichier JSON ou YAML qui joue le rôle de mode d’emploi de l’API. Il décrit les endpoints — les URLs que votre GPT peut appeler —, les méthodes associées (GET pour lire, POST pour créer, PUT pour modifier, DELETE pour supprimer), les paramètres attendus par chaque endpoint, et le format des réponses renvoyées. À partir de ce document, le GPT décide seul, en cours de conversation, quel endpoint appeler et avec quels paramètres.

Voici à quoi ressemble un schéma minimal, pour une API météo fictive :

openapi: 3.1.0
info:
  title: API Météo
  version: 1.0.0
servers:
  - url: https://example.com
paths:
  /previsions:
    get:
      operationId: obtenirPrevisions
      summary: Obtenir les prévisions météo pour une ville
      parameters:
        - name: ville
          in: query
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Prévisions météo

Bonne nouvelle : vous n’aurez presque jamais à écrire ce fichier de zéro. Beaucoup de services publient leur schéma OpenAPI directement dans leur documentation d’API. Sinon, des outils comme Swagger Editor — ou ChatGPT lui-même, à qui vous décrivez l’API — peuvent le générer. Et si votre équipe technique travaille avec Postman, ses collections s’exportent au format OpenAPI.

Configurer une Action dans l’éditeur de GPT

La mise en place se fait dans l’éditeur de votre GPT, sur le web : section Actions, puis Create new action, cliquez sur Créer une action, collez votre schéma OpenAPI dans le champ prévu, configurez l’authentification (c’est l’objet de la leçon suivante), puis testez l’action depuis le panneau de prévisualisation.

La qualité de votre schéma détermine la qualité des appels. Retenez trois habitudes. D’abord, donnez des noms explicites aux operationId : c’est sur eux que le GPT s’appuie pour décider quelle action appeler, et obtenirPrevisions le guide infiniment mieux que op_42. Ensuite, écrivez des descriptions claires pour chaque endpoint et chaque paramètre — en langage naturel, comme si vous expliquiez l’API à un collègue. Enfin, limitez-vous aux endpoints réellement nécessaires : si votre GPT n’a besoin que de deux ou trois routes, n’exposez pas les quarante routes de l’API complète. Chaque endpoint exposé occupe de la place dans le contexte du GPT et augmente le risque qu’il choisisse le mauvais.

À vous de jouer : une API publique

Votre première action, ou son plan. Le meilleur terrain d’entraînement est une API publique et gratuite — météo, taux de change, actualités — qui ne demande pas d’authentification complexe. Choisissez-en une, récupérez ou créez son schéma OpenAPI, et ajoutez-le comme Action dans votre GPT. N’oubliez pas de relier l’Action aux instructions en précisant quand l’utiliser : « Quand l’utilisateur demande la météo, utilise l’action obtenirPrevisions ». Testez ensuite avec plusieurs formulations différentes pour vérifier que le GPT déclenche l’appel au bon moment.

Quelques écueils guettent les premières tentatives. Un schéma mal formaté — une simple virgule manquante dans le JSON — bloque tout : validez systématiquement votre schéma dans Swagger Editor avant de le coller. Des descriptions absentes rendent le GPT aveugle : sans elles, il ne sait pas quand une action est pertinente. Pensez aussi aux erreurs de l’API, qui arriveront tôt ou tard : prévoyez dans vos instructions le comportement à adopter, par exemple « Si l’API ne répond pas, dis à l’utilisateur de réessayer plus tard » — sinon le GPT improvisera, parfois en inventant des données. Et ne vous fiez pas au seul panneau de prévisualisation : testez en conditions réelles, avec de vraies données et de vraies formulations d’utilisateurs.

Deux limites à connaître avant de vous lancer : un GPT utilise des applications connectées ou des actions, pas les deux, et les actions ne fonctionnent pas en mode Pro. Surtout, les actions personnalisées ne passent pas dans un plugin lors de la migration : vérifiez d’abord si l’annuaire des plugins propose déjà une application pour le service visé ; sinon, il faudra reconstruire l’intégration, par exemple avec un serveur MCP.

Sources officielles : Configuring actions in GPTs (centre d’aide OpenAI : authentification, schéma OpenAPI, test, limites) · Custom GPT retirement and migration FAQ (actions non transférées) · OpenAPI Specification (format du schéma)

Points clés à retenir

• Les Actions connectent votre GPT à des services externes via leurs API
• Vous devez fournir un schéma OpenAPI décrivant les endpoints disponibles
• Les descriptions dans le schéma sont essentielles — le GPT s’en sert pour décider quelle action appeler
• Commencez par une API publique gratuite pour vous familiariser avec le processus
• Limitez les endpoints exposés au strict nécessaire pour votre cas d’usage