GPT Actions vs MCP : comparaison technique

Les GPT Actions d’OpenAI et le Model Context Protocol (MCP) d’Anthropic résolvent le même problème fondamental : permettre à un modèle d’IA d’appeler des outils et des API externes pendant une conversation. Ils le résolvent de façons très différentes.

Cet article est une comparaison technique des deux approches. Il couvre l’architecture, les mécanismes de protocole, l’authentification, la découverte d’outils et les compromis importants lorsque vous choisissez entre les deux (ou lorsque vous utilisez les deux).

Que sont les GPT Actions ?

Les GPT Actions sont le mécanisme d’OpenAI permettant aux Custom GPTs (et, plus largement, aux assistants construits via l’API OpenAI) d’appeler des API HTTP externes. Le concept a été lancé avec le GPT Store fin 2023 et a évolué à partir du système antérieur ChatGPT Plugins.

L’idée centrale : vous fournissez une spécification OpenAPI (version 3.0 ou 3.1) qui décrit les endpoints, les paramètres et les schémas de réponse de votre API. Le système d’OpenAI analyse cette spécification et présente les endpoints au modèle comme des outils appelables. Lorsque le modèle décide d’en invoquer un, les serveurs d’OpenAI effectuent la requête HTTP pour le compte de l’utilisateur.

Voici un schéma OpenAPI minimal qui définit une action unique pour rechercher un client par e-mail :

openapi: "3.1.0"
info:
  title: "API de recherche client"
  version: "1.0.0"
servers:
  - url: "https://api.example.com"
paths:
  /customers/search:
    get:
      operationId: "searchCustomer"
      summary: "Rechercher un client par e-mail"
      parameters:
        - name: "email"
          in: "query"
          required: true
          schema:
            type: "string"
            format: "email"
          description: "L'adresse e-mail du client"
      responses:
        "200":
          description: "Client trouvé"
          content:
            application/json:
              schema:
                type: "object"
                properties:
                  id:
                    type: "string"
                  name:
                    type: "string"
                  email:
                    type: "string"
                  plan:
                    type: "string"

Vous collez ou importez ce schéma dans le GPT Builder (ou vous le référencez via une URL), vous configurez l’authentification, et le Custom GPT peut désormais appeler GET /customers/search?email=... chaque fois que le modèle le juge pertinent. (La rédaction de la spécification est la partie qui peut être automatisée : Quickchat AI, par exemple, génère l’action équivalente à partir d’une description en une phrase, fondée sur la documentation live de l’API.)

Propriétés architecturales clés des GPT Actions :

Exécution côté serveur : l’infrastructure d’OpenAI effectue l’appel HTTP sortant. Votre API reçoit la requête depuis la plage d’adresses IP d’OpenAI, et non depuis le navigateur de l’utilisateur final.
OpenAPI comme format de schéma : le modèle utilise les champs operationId, summary et description de la spécification OpenAPI pour comprendre quand et comment appeler chaque endpoint.
REST/HTTP uniquement : les Actions sont limitées aux méthodes HTTP standard (GET, POST, PUT, DELETE, PATCH) via HTTPS.
Options d’authentification : OAuth 2.0, clé API (envoyée comme header ou paramètre de requête), ou aucune authentification. OpenAI gère le flux d’échange de jeton OAuth pour le compte de l’utilisateur.
Définitions d’outils statiques : l’ensemble des actions disponibles est fixé au moment de la configuration. Le modèle ne peut pas découvrir de nouveaux endpoints à l’exécution.

Qu’est-ce que MCP ?

Model Context Protocol (MCP) est un protocole ouvert, publié par Anthropic fin 2024, qui standardise la manière dont les applications d’IA communiquent avec des outils et des sources de données externes. Il n’est lié à aucun modèle ni fournisseur spécifique.

Nous avons rédigé un guide complet sur le fonctionnement de MCP, qui couvre le protocole depuis les principes de base. En résumé : MCP définit une architecture client-serveur dans laquelle une application d’IA (le client MCP) se connecte à un ou plusieurs serveurs MCP, découvre les outils disponibles via une requête tools/list, puis les invoque via des messages tools/call. La communication utilise JSON-RPC 2.0.

Voici le même outil de recherche client exprimé sous forme de définition d’outil MCP :

{
  "name": "search_customer",
  "description": "Rechercher un client par adresse e-mail",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "L'adresse e-mail du client"
      }
    },
    "required": ["email"]
  }
}

Cette définition se trouve dans un serveur MCP (un petit programme qui encapsule votre logique métier). Lorsqu’un client MCP envoie une requête tools/call avec name: "search_customer" et arguments: {"email": "user@example.com"}, le serveur exécute le code situé derrière cet outil (un appel API, une requête de base de données, une lecture de fichier) et renvoie le résultat. Si ce que vous voulez exposer est un assistant IA plutôt qu’une logique métier brute, vous pouvez éviter d’écrire le serveur entièrement : votre AI Agent Quickchat AI peut être exposé comme outil MCP avec une URL hébergée.

Comparaison d’architecture

Les deux approches diffèrent par l’endroit où le code s’exécute, la manière dont la communication circule et les abstractions qu’elles exposent.

GPT Actions : centralisées, natives HTTP

Utilisateur <-> ChatGPT (serveurs OpenAI) --HTTPS--> Votre serveur API

Le modèle et l’exécuteur d’actions se trouvent tous deux côté OpenAI. Lorsque le modèle décide d’appeler une action, le backend d’OpenAI construit une requête HTTP à partir de la spécification OpenAPI, l’envoie à votre API, reçoit la réponse et réinjecte le résultat dans le modèle. Le client de l’utilisateur (navigateur, application mobile) ne communique jamais directement avec votre API.

Cela signifie que :

Votre API doit être accessible publiquement via HTTPS (ou au moins joignable depuis l’infrastructure d’OpenAI).
La latence inclut un aller-retour entre OpenAI et votre serveur.
Toutes les données de requête et de réponse transitent par les serveurs d’OpenAI.

MCP : décentralisé, natif protocole

Utilisateur <-> Application IA (client MCP) <--JSON-RPC--> Serveur MCP <-> Votre API / BDD / service

Le client MCP s’exécute là où l’application d’IA s’exécute. Pour Claude Desktop, c’est sur la machine de l’utilisateur. Pour un agent IA hébergé dans le cloud (comme Quickchat AI), le client MCP s’exécute sur le backend de l’agent. Le serveur MCP peut s’exécuter localement (en communiquant via stdio), sur le même réseau, ou à distance via HTTP avec Server-Sent Events (SSE) ou le transport plus récent Streamable HTTP.

Cela signifie que :

Les serveurs MCP peuvent accéder à des ressources locales (fichiers, bases de données, services localhost) qui ne sont pas exposées à l’internet public.
La communication est bidirectionnelle. Les serveurs peuvent envoyer des notifications aux clients (par exemple lorsqu’une ressource change).
Le protocole est indépendant du transport. Il fonctionne via des pipes stdio, SSE ou HTTP simple.

Tableau comparatif

Dimension	GPT Actions	MCP
Verrouillage fournisseur	OpenAI uniquement. Fonctionne exclusivement dans ChatGPT et l’API OpenAI.	Indépendant des fournisseurs. Pris en charge par Claude, Cursor, VS Code, Windsurf, Quickchat AI et d’autres.
Protocole	OpenAPI 3.x sur REST/HTTP.	JSON-RPC 2.0 sur des transports configurables.
Transport	HTTPS uniquement. Votre API doit être accessible publiquement.	stdio (local), SSE (distant), Streamable HTTP (distant). Les serveurs locaux n’ont pas besoin d’endpoint public.
Authentification	OAuth 2.0, clé API (header ou paramètre de requête), ou aucune. Gérée par OpenAI.	Basée sur des jetons (Bearer tokens dans les headers), headers personnalisés, ou aucune. Gérée par l’application cliente.
Découverte d’outils	Statique. Vous importez ou liez un schéma OpenAPI au moment de la configuration. Le modèle voit ce qui se trouve dans la spécification.	Dynamique. Le client envoie `tools/list` à l’exécution et le serveur répond avec les outils actuellement disponibles. Les outils peuvent changer entre les sessions.
Format de schéma d’outil	Définitions d’opérations OpenAPI (paths, méthodes, paramètres, corps de requête, schémas de réponse).	JSON Schema pour les paramètres d’entrée. Les définitions d’outils incluent le nom, la description et `inputSchema`.
Lieu d’exécution	Les serveurs d’OpenAI effectuent l’appel HTTP.	Le client MCP (ou le serveur) exécute l’appel. Le lieu dépend de l’endroit où le client et le serveur s’exécutent.
Bidirectionnalité	Unidirectionnelle. Le modèle appelle votre API, votre API ne peut pas pousser de données en dehors de la réponse HTTP.	Bidirectionnelle. Les serveurs peuvent envoyer des notifications et des événements de changement de ressource aux clients.
Gestion d’état	Requêtes HTTP sans état. Aucune connexion persistante entre les appels.	Sessions avec état. La connexion client-serveur persiste sur plusieurs appels d’outils au sein d’une session.
Écosystème	Fermé. Le format de spécification (OpenAPI) est ouvert, mais l’environnement d’exécution est propriétaire.	Ouvert. La spécification du protocole est publique. Tout le monde peut construire des clients et des serveurs.
Format de réponse	Réponses HTTP standard (JSON, texte, etc.) analysées par OpenAI.	Blocs de contenu MCP structurés (texte, images, ressources intégrées).

Analyse technique : exemple d’intégration

Pour rendre les différences concrètes, prenons une tâche courante : interroger une base de données PostgreSQL pour obtenir les commandes de clients et renvoyer les résultats à l’utilisateur.

Approche GPT Actions

Vous devez construire et héberger une API HTTP devant votre base de données :

# Serveur API Flask (simplifié)
from flask import Flask, request, jsonify
import psycopg2

app = Flask(__name__)

@app.route("/orders", methods=["GET"])
def get_orders():
    customer_email = request.args.get("email")
    conn = psycopg2.connect("dbname=mydb user=myuser")
    cur = conn.cursor()
    cur.execute(
        "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
        (customer_email,)
    )
    rows = cur.fetchall()
    cur.close()
    conn.close()
    return jsonify([
        {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
        for r in rows
    ])

Vous écrivez ensuite une spécification OpenAPI pour cet endpoint, déployez l’API avec TLS, configurez l’authentification et collez la spécification dans le GPT Builder. OpenAI gère le reste : il lit la spécification, montre au modèle l’opération disponible et effectue l’appel HTTP lorsque nécessaire.

La configuration totale comprend : un serveur API en cours d’exécution, un endpoint HTTPS public, une spécification OpenAPI et la configuration de la GPT Action dans l’interface d’OpenAI.

Approche MCP

Vous écrivez un serveur MCP qui encapsule la même requête de base de données :

# Serveur MCP utilisant le SDK Python mcp
from mcp.server import Server
from mcp.types import Tool, TextContent
import psycopg2
import json

server = Server("orders-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_orders",
            description="Rechercher les commandes d'un client par e-mail",
            inputSchema={
                "type": "object",
                "properties": {
                    "email": {
                        "type": "string",
                        "description": "Adresse e-mail du client"
                    }
                },
                "required": ["email"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_orders":
        conn = psycopg2.connect("dbname=mydb user=myuser")
        cur = conn.cursor()
        cur.execute(
            "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
            (arguments["email"],)
        )
        rows = cur.fetchall()
        cur.close()
        conn.close()
        results = [
            {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
            for r in rows
        ]
        return [TextContent(type="text", text=json.dumps(results, indent=2))]

Si le serveur MCP s’exécute localement (via stdio), il peut se connecter directement à une base de données sur localhost ou sur le réseau local. Aucun endpoint public n’est nécessaire. Si le serveur s’exécute à distance, il lui faut un endpoint HTTP, mais il communique via JSON-RPC sur SSE ou Streamable HTTP plutôt qu’en REST brut.

La configuration totale pour un usage local comprend : le script du serveur MCP, la configuration du client MCP (pointant vers la commande du serveur) et une connexion à la base de données. Pas de spécification OpenAPI, pas de certificat TLS, pas d’API exposée publiquement.

Différences clés en pratique

Le chemin GPT Actions exige plus d’infrastructure (un service HTTP déployé), mais s’appuie sur des modèles d’API REST existants que la plupart des équipes connaissent déjà. Si vous avez déjà une API REST, ajouter une GPT Action consiste surtout à rédiger la spécification OpenAPI.

Le chemin MCP exige moins d’infrastructure pour les cas d’usage locaux, mais introduit un nouveau protocole que votre équipe doit apprendre. Pour les déploiements distants, les exigences d’infrastructure sont similaires à celles des GPT Actions, mais le modèle de communication est différent (connexions persistantes, encadrement JSON-RPC, notifications bidirectionnelles).

Comment Quickchat AI gère les deux approches

Le système AI Actions de Quickchat AI prend en charge deux types d’actions distincts qui correspondent à ces deux paradigmes : HTTP Request Actions et Remote MCP Actions.

HTTP Request Actions

Les HTTP Request Actions sont conceptuellement similaires aux GPT Actions. Vous configurez un endpoint HTTP, une méthode, des headers, des paramètres de requête et un modèle de corps JSON. L’AI Agent collecte les valeurs des paramètres dans la conversation, puis le backend de Quickchat effectue la requête HTTP côté serveur.

Une HTTP Request Action comprend :

Une URL d’endpoint avec des placeholders {{parameter}} (par exemple https://api.hubapi.com/crm/v3/objects/contacts)
Une méthode HTTP (GET, POST, PATCH, PUT, DELETE)
Des headers (y compris des jetons d’autorisation substitués côté serveur)
Un modèle de corps JSON avec des placeholders de paramètres
Des paramètres de requête avec des placeholders
Un ensemble de paramètres typés (string, number, boolean, float) avec descriptions, indicateurs obligatoires et valeurs par défaut

Au moment de l’exécution, l’IA détermine quels paramètres remplir en fonction du contexte de conversation. Le backend injecte les valeurs de paramètres dans l’URL, les headers, le corps et la chaîne de requête, en remplaçant les placeholders {{param_name}}. Il effectue ensuite la requête HTTP et renvoie la réponse à l’IA pour interprétation.

Pour un exemple détaillé, consultez notre guide HubSpot AI Actions.

Remote MCP Actions

Les Remote MCP Actions connectent l’AI Agent à un serveur MCP externe. Au lieu de définir des endpoints HTTP individuels, vous fournissez l’URL du serveur MCP et, facultativement, des identifiants d’authentification (un bearer token et/ou des headers personnalisés). Le backend Quickchat agit comme client MCP : il se connecte au serveur distant, découvre les outils disponibles via l’appel de protocole standard tools/list, puis les présente au modèle d’IA.

La configuration exige :

L’URL du serveur MCP (un endpoint HTTPS servant le transport MCP Streamable HTTP ou SSE)
Un jeton d’authentification facultatif
Des headers personnalisés facultatifs
Une liste d’outils découverts avec des bascules active/inactive individuelles
Un réglage d’activation des outils par défaut (si les outils nouvellement découverts sont actifs par défaut)

Une fois connecté, chaque outil exposé par le serveur MCP devient disponible pour l’AI Agent pendant les conversations. L’IA voit les noms et descriptions des outils provenant de la réponse tools/list du serveur MCP et peut les invoquer selon les besoins. La sélection d’outils peut être restreinte avec la configuration allowed_tools, qui permet d’activer ou de désactiver des outils spécifiques du serveur.

Cette approche est particulièrement utile lorsque vous intégrez des services qui publient déjà des serveurs MCP (comme Shopify’s MCP), car vous pouvez vous connecter au serveur existant plutôt que de construire des actions HTTP individuelles pour chaque endpoint.

Quand utiliser chaque option dans Quickchat

Utilisez HTTP Request Actions lorsque :

Vous vous intégrez à un endpoint d’API REST spécifique
Vous voulez un contrôle fin du format de requête (headers, structure du corps, paramètres de requête)
L’API ne dispose pas d’un serveur MCP publié
Vous avez besoin d’une injection d’identifiants côté serveur (comme des jetons OAuth pour HubSpot, Zendesk, etc.)

Utilisez Remote MCP Actions lorsque :

Le service publie un serveur MCP
Vous voulez vous connecter à plusieurs outils d’un même service dans une seule action
Vous voulez une découverte dynamique des outils (les outils disponibles pour l’IA peuvent changer lorsque le serveur MCP est mis à jour)
Vous construisez un système multi-agent dans lequel une IA délègue à une autre via MCP

Avantages et inconvénients

GPT Actions

Avantages :

Technologie familière. Si vous avez une API REST existante, vous disposez déjà de la majeure partie de ce qu’il vous faut. La rédaction d’une spécification OpenAPI est bien documentée et l’outillage est mature.
Le format OpenAPI est largement adopté. Les spécifications peuvent être générées automatiquement à partir de nombreux frameworks web (FastAPI, Express avec swagger-jsdoc, Spring Boot avec springdoc).
OpenAI gère l’exécution des requêtes HTTP, la terminaison TLS et la gestion des erreurs sur son infrastructure.
La prise en charge d’OAuth 2.0 est intégrée, avec actualisation automatique des jetons.

Inconvénients :

Verrouillé dans l’écosystème d’OpenAI. Une action que vous construisez pour un Custom GPT ne peut pas être réutilisée avec Claude, Gemini ou un autre fournisseur de modèles sans réimplémentation.
Votre API doit être accessible publiquement. Pas de prise en charge des ressources locales ou de réseau privé.
Pas de découverte dynamique des outils. Ajouter un nouvel endpoint nécessite de mettre à jour la spécification OpenAPI et de reconfigurer le GPT.
Unidirectionnel uniquement. Votre API ne peut pas pousser de mises à jour ou de notifications vers le modèle en dehors des réponses HTTP.
Toutes les données transitent par les serveurs d’OpenAI, ce qui peut poser problème pour les charges de travail sensibles.
Les limites de débit et les timeouts d’exécution sont contrôlés par OpenAI, pas par vous.

MCP

Avantages :

Indépendant des fournisseurs. Le même serveur MCP fonctionne avec Claude, Cursor, Quickchat AI et tout autre client qui implémente le protocole.
Prend en charge les ressources locales. Un serveur MCP exécuté via stdio peut accéder aux fichiers, bases de données et services sur la machine locale sans rien exposer à internet.
Découverte dynamique des outils. L’IA peut interroger le serveur pour obtenir les outils disponibles à l’exécution. Des outils peuvent être ajoutés, supprimés ou mis à jour sans reconfigurer le client.
Communication bidirectionnelle. Les serveurs peuvent notifier les clients de changements (par exemple, un fichier a été modifié, un nouvel enregistrement a été créé).
Sessions avec état. La connexion persiste sur plusieurs invocations d’outils au sein d’une conversation, ce qui permet des workflows nécessitant le contexte d’appels précédents.
Spécification ouverte. Tout le monde peut inspecter, implémenter ou étendre le protocole.

Inconvénients :

Écosystème plus jeune. Le protocole a été publié fin 2024, donc l’outillage, la documentation et les connaissances de la communauté sont encore en développement par rapport à OpenAPI.
Nécessite d’exécuter un serveur MCP. Pour les déploiements distants, cela signifie héberger un service supplémentaire (même s’il peut être léger).
Pas de spécification d’authentification standardisée (début 2026). Les implémentations varient entre authentification par jeton, headers personnalisés et extensions OAuth. La spécification MCP Authorization continue d’évoluer.
L’encadrement JSON-RPC ajoute une couche d’abstraction qui peut sembler peu familière aux équipes habituées à REST.
La prise en charge côté client varie. Toutes les applications d’IA ne prennent pas en charge tous les transports ou toutes les fonctionnalités MCP.

Quand utiliser chaque option

Le choix dépend de vos contraintes :

Choisissez GPT Actions si :

Vous construisez exclusivement pour ChatGPT ou l’API OpenAI.
Vous avez déjà une API REST publique avec une spécification OpenAPI.
Vous avez besoin que la plateforme gère OAuth 2.0 pour vous.
Vous voulez le chemin le plus simple entre « API existante » et « outil appelable par l’IA ».

Choisissez MCP si :

Vous avez besoin que vos outils fonctionnent avec plusieurs fournisseurs d’IA.
Vous voulez exposer des ressources locales ou de réseau privé à une IA sans les rendre publiques.
Vous avez besoin de découverte dynamique des outils, de communication bidirectionnelle ou de sessions avec état.
Vous construisez une architecture multi-agent où différents systèmes d’IA doivent se coordonner.

Utilisez les deux si :

Vous avez une API REST existante que vous voulez exposer comme GPT Action pour les utilisateurs de ChatGPT, mais vous voulez aussi publier un serveur MCP pour Claude, Cursor et d’autres clients. La logique métier sous-jacente peut être partagée, l’adaptateur de protocole est une fine couche au-dessus.

La tendance à la convergence

Les GPT Actions et MCP sont partis de philosophies de conception différentes (native HTTP vs native protocole), mais l’écart se réduit.

OpenAI a ajouté la prise en charge de MCP à l’Agents SDK en mars 2025, permettant aux agents propulsés par OpenAI de se connecter à des serveurs MCP en plus du function calling traditionnel. Cela ne remplace pas les GPT Actions (qui restent le moyen d’ajouter l’appel d’outils aux Custom GPTs dans ChatGPT), mais indique qu’OpenAI reconnaît MCP comme un standard viable pour la communication entre agents et outils.

Côté MCP, le protocole prend maintenant en charge le transport Streamable HTTP, ce qui rapproche les serveurs MCP distants des services HTTP traditionnels. Un serveur MCP derrière un endpoint Streamable HTTP n’est pas très éloigné d’une API REST sur le plan architectural, même s’il utilise toujours JSON-RPC en interne plutôt que les conventions REST.

Le résultat probable est la coexistence des deux modèles. Les schémas OpenAPI resteront le moyen standard de décrire les API REST, et les GPT Actions (ou des mécanismes similaires) continueront d’être le pont le plus simple entre ces API et les modèles d’IA dans l’écosystème d’OpenAI. MCP se développera comme standard inter-fournisseurs pour l’intégration d’outils, en particulier dans les architectures agentiques et multi-modèles. Les plateformes comme Quickchat AI qui prennent en charge à la fois HTTP Request Actions et Remote MCP Actions vous donnent la flexibilité d’utiliser l’approche adaptée à votre intégration spécifique.