Comment connecter votre application à ChatGPT et Claude avec MCP

Vous pouvez connecter votre application à ChatGPT et à Claude sans avoir à refondre votre backend. Le Model Context Protocol (MCP) ajoute un serveur léger devant l’API dont vous disposez déjà. Les deux assistants peuvent alors vérifier en temps réel une commande, une réclamation ou une réservation pour vos clients.

Sans ce canal, un assistant à qui l’on demande « Où en est ma commande ? » ne peut que s’excuser ou émettre des hypothèses. Il ne peut pas visualiser l’état en temps réel de votre système. Le MCP lui offre un moyen d’accès standardisé et contrôlé.

Ce guide s’adresse aux responsables techniques qui gèrent une application, écrivent du code et souhaitent connecter leur application à ChatGPT. Il explique ce qu’il faut exposer en premier lieu, comment fonctionne OAuth, comment votre application est référencée dans ChatGPT et Claude, et dans quels cas une intégration directe via l’API est suffisante.

En résumé : choisissez trois à cinq tâches en lecture seule dont votre équipe d’assistance s’occupe déjà. Intégrez-les à un petit serveur MCP distant via OAuth. Testez-les en mode développeur de ChatGPT et en tant que connecteur personnalisé Claude, puis soumettez-les pour examen à OpenAI et Anthropic.

Qu’est-ce que le MCP, et pourquoi ChatGPT et Claude l’utilisent-ils tous les deux ?

Le MCP est un protocole ouvert qui normalise la manière dont les assistants IA se connectent aux systèmes externes. Anthropic l’a lancé en novembre 2024. OpenAI, Google et Microsoft l’ont depuis adopté, ce qui permet à un seul serveur MCP de prendre en charge plusieurs assistants, au lieu de nécessiter une intégration personnalisée par fournisseur.

Considérez cela comme un menu destiné à une IA. Il répertorie ce que votre système est capable de faire, les données d’entrée requises pour chaque action et ce qu’il renvoie. L’assistant lit le menu et décide quand passer commande.

Un serveur MCP est généralement déployé en amont d’une API dont vous disposez déjà. Vous ne reconstruisez pas votre backend ; vous en décrivez une petite partie afin qu’un modèle puisse l’utiliser en toute sécurité. Pour en savoir plus, consultez notre guide complet sur le Model Context Protocol.

Où se situe un serveur MCP dans l’architecture de votre application ?

Trois rôles sont essentiels. L’hôte est l’application d’IA, telle que ChatGPT ou Claude. Au sein de celle-ci, un client MCP communique avec votre serveur MCP, que vous gérez et qui appelle vos propres API ou bases de données.

Le modèle ne se connecte jamais directement à vos systèmes. Il propose un appel d’outil ; la requête parvient à votre serveur, qui décide de l’exécuter ou non. C’est à ce niveau que s’exercent vos contrôles : validation des données saisies, vérification des autorisations, limitation du débit et journaux d’audit. Les identifiants du backend restent dans l’environnement de votre serveur et n’entrent jamais dans le contexte du modèle.

Pour un architecte, le modèle mental utile est celui d’un nouveau service public en périphérie doté d’un client atypique. Traitez-le avec la même rigueur que n’importe quelle API que vous exposez sur Internet.

Que se passe-t-il lorsqu’un client interroge ChatGPT au sujet de votre application ?

Prenons l’exemple d’un assureur qui permet à ses clients de vérifier leurs déclarations de sinistre via ChatGPT. Voici ce qui se passe en coulisses lorsqu’une question est posée.

1. L’assistant détecte vos outils. Lorsqu’il se connecte, le client MCP interroge votre serveur pour connaître les outils disponibles (tools/list). Il obtient alors le nom, la description et le schéma d’entrée de chaque outil.
2. Un client demande : « Où en est ma demande de remboursement n° 4471 ? » Le modèle sélectionne get_claim_status et saisit le numéro de la demande. Vos systèmes n’ont encore été sollicités d’aucune manière. Il ne s’agit que d’une proposition.
3. C’est votre serveur qui en décide. La requête parvient à votre serveur (tools/call), qui vérifie que le jeton de l’utilisateur couvre la revendication 4471. Ce n’est qu’alors qu’il appelle votre API de revendications.
4. La réponse reste modeste. Votre serveur renvoie les trois informations dont le modèle a besoin : le statut, la dernière mise à jour et l’étape suivante. Il ne transmet pas l’enregistrement à 200 champs que contient votre backend.
5. Le client ajoute : « Versez-le sur mon nouveau compte. » L’assistant sait de quelle demande il s’agit, car l’hôte conserve l’historique de la conversation. Cependant, connaître la demande ne signifie pas pour autant être autorisé à modifier le montant du versement. Votre serveur vérifie tout de même les droits et demande à l’utilisateur de confirmer.

Deux choses en découlent. Premièrement, le contexte de la conversation réside dans l’assistant, et non dans le protocole. Votre serveur ne doit en aucun cas considérer l’expression « nous en avons déjà parlé » comme une autorisation.

Deuxièmement, MCP ne peut rien faire que votre backend n’autorise pas. Un identifiant de base de données en lecture seule reste en lecture seule, quelle que soit la requête du modèle.

À quoi ressemble une bonne définition d’outil ?

Voici l’outil de réclamation de l’exemple ci-dessus, tel que votre serveur le décrirait :

{
  "name": "get_claim_status",
  "title": "Get claim status",
  "description": "Returns the status of one insurance claim for the signed-in customer: current status, date of the last update and the next step. Use it when the customer asks where a claim stands. It changes nothing.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "claim_id": { "type": "string", "description": "Claim number, for example 4471" }
    },
    "required": ["claim_id"]
  },
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "openWorldHint": false
  }
}

C’est la description qui fait l’essentiel du travail. Elle précise ce que l’outil renvoie, quand l’utiliser et qu’il est fiable, car c’est ce que le modèle analyse avant de prendre une décision.

La description de l’application ( title ) et la page de présentation ( annotations ) ont également leur importance. OpenAI et Anthropic les vérifient toutes les deux lorsque vous soumettez votre application, et une description de l’application ( readOnlyHint ) qui ne correspond pas à ce que l’outil fait réellement est un motif fréquent de rejet.

Le résultat structuré renvoyé par votre serveur reste tout aussi concis :

{ "status": "In review", "last_update": "2026-10-12", "next_step": "Expert visit scheduled" }

Trois champs, pas d’identifiants internes, pas de piste d’audit. Le modèle a moins de risques d’interpréter mal les données, et celles-ci se retrouvent moins souvent dans la fenêtre de contexte d’un autre utilisateur.

Ce que votre application doit proposer : des outils, des ressources et des invites

Un serveur MCP propose trois types de services :

• Les outils sont des actions que l’assistant peut lancer, telles que check_order_status ou find_branch_opening_hours.
• Les ressources sont des données que l’assistant peut lire, telles qu’un catalogue de produits ou un document de politique.
• Les « prompts » sont des modèles réutilisables qui guident l’assistant dans l’exécution d’une tâche que vos utilisateurs effectuent régulièrement.

La plupart des premiers projets ne nécessitent que des outils. Prenons l’exemple d’un commerçant : la liste des outils indispensables pour débuter est courte. Vérifier les stocks en magasin, suivre une commande, consulter la politique de retour. Aucune de ces opérations n’implique de modification de vos systèmes, ce qui est plus important qu’il n’y paraît (voir « Commencez par les utilisateurs internes et les outils en lecture seule » ci-dessous).

Six étapes pour connecter votre application à ChatGPT et Claude

Pour connecter votre application à ChatGPT et à Claude, veuillez suivre ces six étapes :

1. Choisissez les tâches, et non les terminaux. Dressez la liste des questions que les utilisateurs posent déjà à votre équipe d’assistance. Choisissez-en trois à cinq auxquelles votre API est déjà en mesure de répondre. Rendre accessible l’intégralité de votre API est l’erreur la plus courante que nous observons : face à 80 outils, l’assistant ne sait plus lequel choisir et se trompe.
2. Déterminez qui est à l’origine de l’appel. Les informations publiques, telles que les horaires d’ouverture ou un catalogue, ne nécessitent aucune connexion. Pour accéder à toute information personnelle, l’utilisateur doit se connecter. Les serveurs MCP distants utilisent OAuth à cette fin, via votre fournisseur d’identité. L’assistant agit alors avec les autorisations de cet utilisateur, sans jamais aller au-delà.
3. Rédigez des descriptions destinées au modèle, et non aux développeurs. Le modèle sélectionne un outil à partir de son nom et de sa description. « Renvoie le statut d’une commande pour un identifiant de commande donné, y compris le transporteur et la date de livraison prévue » fonctionne. « GET /v2/ord/status » ne fonctionne pas. Ne renvoyez que les informations dont le modèle a besoin, et non l’objet brut du backend.
4. Créez un serveur léger et hébergez-le. Le serveur assure la traduction entre MCP et votre API. Pour être accessible depuis ChatGPT ou Claude, il doit fonctionner à distance via HTTPS (HTTP « streamable » selon la spécification actuelle) sur un domaine public. Prévoyez en amont les mesures habituelles : pare-feu applicatif web (WAF), surveillance et limitation de débit.
5. Testez chaque assistant à l’aide de vraies questions. Posez les questions de l’étape 1 comme le ferait un client, fautes de frappe comprises. Observez quel outil l’assistant choisit. S’il choisit le mauvais, corrigez les descriptions, et non le modèle.
6. Enregistrer, limiter et surveiller. Enregistrez chaque demande d’outil, définissez des limites de fréquence et analysez les demandes réelles des utilisateurs. Les données enregistrées au cours du premier mois constituent la meilleure étude de marché dont vous disposerez sur ce canal.

Les étapes 1 à 6 vous permettent de disposer d’un serveur opérationnel. La section suivante explique comment les clients peuvent effectivement le trouver.

Comment faire figurer votre application dans ChatGPT et Claude

Une fois que vous avez connecté votre application à ChatGPT en mode développeur, celle-ci n’apparaît toujours pas dans la liste des applications. Les deux fournisseurs vous permettent de procéder d’abord à des tests en privé, puis d’examiner votre serveur avant que celui-ci n’apparaisse dans leur répertoire. Aucun des deux fournisseurs ne s’engage sur un délai d’examen ; veillez donc à préparer les documents nécessaires à la mise en ligne pendant que vous développez votre application.

Deux points posent problème aux équipes européennes. Premièrement, les projets OpenAI soumis à une résidence des données au sein de l’UE ne peuvent actuellement pas présenter de candidatures; vous devez disposer d’un projet avec une résidence des données mondiale. Vérifiez ce point dès que possible auprès de votre délégué à la protection des données.

Deuxièmement, les métadonnées de votre outil constituent un contrat versionné sur ChatGPT. Une application publiée conserve un instantané validé des noms, descriptions et annotations. Toute modification de ces éléments entraîne la création d’une nouvelle version et un nouveau processus de validation, tandis que les corrections apportées aux résultats exclusivement au niveau du serveur sont mises en ligne immédiatement.

Ces deux fournisseurs prennent également en charge les applications MCP, qui permettent d’afficher une interface utilisateur interactive au sein même de la messagerie instantanée. Commencez sans interface utilisateur : les outils « nus » sont plus rapides à développer, à valider et à tester.

Ce qu’il faut tester avant la mise en production

Les démonstrations dans des conditions idéales masquent la plupart des problèmes. Avant de connecter votre application à ChatGPT pour de vrais utilisateurs, testez délibérément les cas suivants :

• Une véritable expression. Les fautes de frappe, les phrases incomplètes et toutes les langues utilisées par vos clients. En Belgique, cela signifie au moins le français, le néerlandais et l’anglais.
• Échecs. Un enregistrement qui n’existe pas, des arguments non valides, un refus d’autorisation, un backend hors service. L’assistant devrait faire la distinction entre « introuvable » et « impossible de vérifier ».
• Des suivis autonomes. L’instruction « Rembourser celui-ci » doit désigner le bon enregistrement et doit tout de même faire l’objet d’une autorisation.
• Chaque assistant, là encore après les mises à jour. ChatGPT et Claude choisissent leurs outils différemment, et tous deux s’adaptent lorsque le fournisseur propose un nouveau modèle.

Cet ensemble de tests fait également office de dossier de soumission. OpenAI demande des consignes de test accompagnées des réponses attendues ; vous pouvez donc les rédiger une seule fois et les réutiliser.

Construire, réutiliser ou acheter un serveur MCP

Vous n’êtes pas obligé de développer vous-même chaque serveur. De nombreux fournisseurs de SaaS publient désormais leurs propres serveurs MCP, la communauté open source en gère beaucoup d’autres, et vos propres systèmes auront besoin de serveurs personnalisés. D’après notre expérience, l’étiquette importe moins que le code. Un serveur « officiel » peut tout de même ne pas disposer de la fonction dont vous avez besoin, tandis qu’un projet communautaire peut être excellent ou avoir été abandonné.

Avant d’en adopter un, vérifiez cinq points :

• Il présente les opérations dont votre cas d’utilisation a besoin, et pas seulement les plus courantes.
• Elle est mise à jour en fonction de la version du backend que vous utilisez effectivement.
• Vous pouvez limiter les informations d’identification et les opérations auxquelles il a accès.
• Ses réponses sont suffisamment claires pour qu’un modèle puisse les interpréter.
• Une personne de votre équipe en est responsable en environnement de production : déploiement, journaux, pannes et mises à jour.

Déterminez ensuite le nombre de serveurs dont vous avez besoin. Un seul serveur peut regrouper plusieurs systèmes, ce qui permet de centraliser les politiques. Il est plus judicieux d’utiliser des serveurs distincts lorsque les systèmes ont des responsables différents ou relèvent de périmètres de sécurité distincts. Basez-vous sur votre organigramme et votre modèle de risque, et non sur l’idée reçue selon laquelle « moins il y en a, mieux c’est ».

Commencez par les utilisateurs internes et les outils en lecture seule

Ce même serveur peut d’abord répondre aux besoins de vos propres équipes. Les agents du service client peuvent consulter les commandes et les réclamations directement depuis Claude, sans avoir à basculer entre trois systèmes de gestion. Les développeurs peuvent demander à un assistant pourquoi un déploiement échoue, à condition que votre serveur expose l’état des pods et les journaux récents. Nous abordons ces cas d’utilisation internes dans la section « Agents IA pour vos équipes ».

Les utilisateurs internes constituent un premier public plus sûr. Ils font preuve d’indulgence face aux imperfections, vous signalent ce qui manque et leurs données se trouvent déjà au sein de votre périmètre de sécurité. Les administrateurs des versions « Business » et « Enterprise » de ChatGPT peuvent également activer le mode développeur pour les applications internes, ce qui évite de devoir les publier.

Notre recommandation la plus forte : commencez par déployer des outils en lecture seule. Vérifier un statut ou effectuer une recherche ne peut causer aucun dommage ; vous apprenez ainsi comment les utilisateurs réels formulent leurs demandes, pratiquement sans aucun risque. Les actions qui modifient les données (réserver, annuler, payer) interviennent plus tard, avec une étape de confirmation que l’utilisateur doit approuver.

Cela facilite également les échanges en interne. Une équipe de sécurité approuvera la fonctionnalité « l’assistant peut consulter les horaires d’ouverture » en une semaine. La fonctionnalité « l’assistant peut annuler des commandes » donne lieu à un quart des réunions.

Questions de sécurité auxquelles vous devez répondre avant de connecter votre application à ChatGPT

Envoyez cette liste à votre RSSI avant la première réunion. Cela évite un aller-retour, car chaque réponse influe sur la conception.

• Quelles données quittent nos systèmes, et le fournisseur de l’assistant les stocke-t-il ?
• Comment l’utilisateur est-il authentifié, et l’assistant peut-il jamais agir au-delà des droits de cet utilisateur ?
• Une instruction malveillante, telle qu’un texte dissimulé dans un document, peut-elle amener l’assistant à faire appel à un outil qu’il ne devrait pas utiliser ? Quelles sont les limites à cet égard ?
• Où le serveur est-il hébergé, et dans quelle région ?
• Comment faire pour l’arrêter en quelques minutes si un problème survient ?

Il existe de bonnes réponses à chacune de ces questions, mais il s’agit de choix de conception, et non de paramètres. Elles doivent être abordées lors du premier sprint, et non du dernier.

Il est recommandé de ne pas inclure les identifiants d’accès au backend dans le modèle, mais ce n’est pas ce qui garantit la sécurité d’un appel d’outil. Un modèle peut proposer une action dangereuse sans jamais avoir accès à une clé. Les informations confidentielles peuvent également faire l’objet de fuites via les descriptions d’outils, les messages d’erreur ou les données renvoyées ; veillez donc à les examiner avec autant de soin que le code.

Une règle permet de répondre à plusieurs questions à la fois : appliquez les règles métier dans le code du serveur, jamais dans une invite. La mention « Ne jamais rembourser plus de 200 € sans autorisation », figurant dans la description d’un outil, n’est qu’une suggestion. La même règle, intégrée au code, constitue un contrôle.

Quand vous n’avez pas besoin de MCP pour connecter votre application à ChatGPT

Le MCP s’avère avantageux lorsque les mêmes fonctionnalités peuvent être utilisées pour plusieurs applications d’IA, ou lorsque vous prévoyez de changer de modèle tout en conservant l’intégration. Si vous développez un seul assistant interne sur un backend stable avec un flux prévisible, une intégration API directe est plus simple. Vous aurez ainsi un composant de moins à déployer, à sécuriser et à surveiller.

La fonctionnalité « Discovery » est également utile. Ajoutez un outil à votre serveur : un connecteur personnalisé le détectera lors de la prochaine connexion, sans qu’il soit nécessaire de procéder à une mise à jour dans chaque application. Les listes publiées sont soumises à des règles plus strictes : sur ChatGPT, les outils nouveaux ou modifiés font l’objet d’un nouveau contrôle. Dans tous les cas, considérez chaque nouvel outil comme un nouveau point de terminaison API, et veillez à ce qu’il fasse l’objet d’un contrôle et de tests avant sa mise en service.

La portabilité est bien réelle, mais partielle. Lorsque vous changez de modèle, le serveur reste le même, mais attendez-vous à devoir refaire des tests, car deux modèles peuvent interpréter différemment les mêmes descriptions d’outils.

Le MCP ne supprime pas non plus le travail d’intégration. Quelqu’un doit toujours créer et maintenir la connexion à chaque backend, et la mettre à jour lorsque ce dernier évolue. Ce que le MCP vous apporte, c’est une interface unique pour ce travail, que chaque assistant peut réutiliser.

Si vous avez un doute, quatre questions permettent généralement de trancher :

• Ces fonctionnalités seront-elles utilisées par plusieurs assistants ou applications d’IA ?
• Envisagez-vous de changer de modèle ou de fournisseur au cours des deux prochaines années ?
• Existe-t-il un serveur déjà en place que vous pourriez réutiliser, ou comptez-vous en créer et en exploiter un vous-même ?
• Une couche distincte permettrait-elle de clarifier les droits d’accès et la propriété ?

Si vous répondez « oui » à au moins deux de ces questions, MCP en vaut probablement la peine. Nous préférons vous le dire dès maintenant plutôt que de vous vendre un serveur que vous devrez entretenir pour rien.

Est-il intéressant de connecter votre application à ChatGPT et à Claude ?

Nous pensons que oui, pour une raison très simple. Lorsqu’un utilisateur pose à un assistant une question à laquelle votre entreprise peut répondre, l’assistant utilisera soit vos données, soit celles d’un tiers. Être présent dans cette réponse, c’est la nouvelle façon d’apparaître en première page de Google. MCP vous permet de connecter votre application à ChatGPT et à Claude en utilisant vos propres données, plutôt que le résumé qu’en ferait un inconnu.

FAQ : comment connecter votre application à ChatGPT et Claude

MCP fonctionne-t-il avec ChatGPT ? Oui. OpenAI prend en charge MCP pour connecter ChatGPT à des outils externes, et son SDK Apps repose sur MCP. Claude, Gemini et Microsoft Copilot le prennent également en charge. La disponibilité varie souvent selon les formules ; veuillez donc consulter la documentation actuelle de chaque fournisseur.

Comment puis-je faire en sorte que mon application figure dans ChatGPT et Claude ? Pour connecter votre application à ChatGPT et à Claude pour tous les utilisateurs, testez-la d’abord en privé : en mode développeur de ChatGPT et en tant que connecteur personnalisé Claude. Soumettez-la ensuite via le portail de soumission de plugins d’OpenAI et le portail des développeurs de connecteurs d’Anthropic. Ces deux entités examineront vos outils, votre politique de confidentialité et un compte de test.

Dois-je refaire mon backend pour MCP ? Non. Un serveur MCP constitue une couche placée en amont de votre API existante. Si vous ne disposez pas d’une API opérationnelle, c’est par là qu’il faut commencer.

Le protocole MCP est-il suffisamment sécurisé pour les opérations bancaires ou d’assurance ? C’est possible, mais la sécurité repose sur votre conception : OAuth, des outils basés sur le principe du « privilège minimal », le mode « lecture seule » par défaut, la journalisation et un « kill switch ». Le protocole ne fait pas ces choix à votre place.

En quoi le MCP diffère-t-il d’une API classique ? Une API est conçue pour les développeurs qui consultent la documentation. Un serveur MCP est conçu pour un modèle qui lit les descriptions des outils et décide de lui-même quand les appeler.

Pouvons-nous utiliser un serveur MCP existant plutôt que d’en créer un ? Souvent, oui, notamment pour les outils tiers tels que les solutions de paiement ou de messagerie. Vérifiez quelles informations il expose, qui en assure la maintenance et comment vous pouvez en limiter l’accès avant de le connecter aux données de production.

Que se passe-t-il avec notre serveur MCP si nous changeons de modèle d’IA ? Le serveur continue de fonctionner avec n’importe quel assistant prenant en charge MCP. Vous devrez toutefois refaire des tests, car les modèles choisissent des outils différents à partir de descriptions identiques.

Êtes-vous prêt à connecter votre application à ChatGPT ?

Vous souhaitez savoir quels sont les trois services que votre application devrait mettre à disposition en priorité ? Prenez rendez-vous pour un entretien de 30 minutes sur la préparation à l’IA. L’un de nos architectes de solutions examinera votre API et votre configuration d’authentification, puis vous indiquera par où nous commencerions.