MCP en IA signifie Model Context Protocol. Découvrez comment hôtes, clients et serveurs connectent l'IA aux outils et aux données, ainsi que MCP vs API et les principaux risques de sécurité.
MCP en IA signifie Model Context Protocol. Il s'agit d'une norme ouverte qui aide les applications d'IA à se connecter à des outils externes, des sources de données et des flux de travail via une interface commune. MCP ne remplace pas les API, l'appel de fonction ni le RAG. Il offre plutôt aux applications d'IA un moyen plus cohérent de découvrir et d'utiliser ces capacités.
MCP signifie Model Context Protocol.
Il s'agit d'une norme open source permettant de connecter des applications d'IA à des systèmes externes tels que des fichiers, des bases de données, des outils de recherche, des calendriers, des référentiels de code et des logiciels métier. La documentation officielle de MCP la compare à un port USB-C : différents appareils peuvent utiliser la même norme de connexion au lieu d'exiger un nouveau câble pour chaque combinaison.
Cette comparaison est utile, mais elle peut aussi donner l'impression que MCP est plus simple qu'il ne l'est.
MCP n'est ni un modèle d'IA, ni une application, ni un remplacement d'API. C'est une norme de communication utilisée par des applications et des serveurs d'IA compatibles. L'application a toujours besoin d'un modèle de langage pour comprendre la requête de l'utilisateur, tandis que les services connectés s'appuient souvent encore sur leurs API existantes en arrière-plan.
Une définition plus précise est :
MCP normalise la manière dont une application d'IA découvre, se connecte et échange des informations avec des outils et des sources de données externes.
Le mot contexte est important. Un modèle de langage ne connaît que ce qui est inclus dans ses données d'entraînement ou fourni lors de l'interaction en cours. MCP peut donner à une application d'IA accès à un contexte supplémentaire—comme un enregistrement de base de données actuel, un fichier local ou le résultat d'une requête API en direct—lorsque ces informations sont nécessaires.
Avant MCP, les développeurs créaient généralement des intégrations distinctes pour chaque combinaison d'application d'IA et de service externe.
Imaginez un assistant IA qui doit fonctionner avec Google Calendar, GitHub, une base de données clients et un système de facturation interne. Chaque intégration peut avoir son propre format d'API, son processus d'authentification, ses définitions de fonctions et ses règles de gestion des erreurs.
Imaginez maintenant devoir créer les mêmes connexions pour un autre assistant IA.
MCP tente de réduire ce travail d'intégration répétitif. Un service peut exposer ses capacités via un serveur MCP, tandis que les applications d'IA compatibles peuvent se connecter via un protocole partagé.
Cela ne signifie pas que les développeurs peuvent cesser de créer des intégrations. Quelqu'un doit toujours implémenter le serveur MCP, le connecter au service sous-jacent, gérer les identifiants, valider les requêtes et maintenir le système. L'avantage est la réutilisation : une fois qu'une capacité suit le protocole, il peut être plus facile de la connecter à plusieurs hôtes d'IA compatibles.
MCP est particulièrement utile lorsque le nombre d'outils, de sources de données et de clients IA commence à augmenter. Pour une application connectée à un service stable unique, une intégration API directe peut rester le choix le plus simple.
MCP utilise une architecture client-serveur, mais la terminologie peut prêter à confusion car trois éléments sont impliqués.
L'hôte est l'application d'IA avec laquelle l'utilisateur interagit. Il peut s'agir d'un assistant de chat, d'un environnement de codage, d'une application de bureau ou d'un agent IA personnalisé.
L'hôte coordonne la conversation, communique avec le modèle de langage, gère les permissions et décide quelles connexions MCP sont disponibles.
Un client MCP est un composant à l'intérieur de l'hôte qui maintient la connexion à un serveur MCP.
Selon l'architecture MCP officielle, un hôte crée normalement une connexion client distincte pour chaque serveur. Si une application se connecte à un serveur de système de fichiers et à un serveur de calendrier, elle gère deux clients MCP.
Un serveur MCP est un programme qui met des capacités spécifiques à la disposition des clients MCP. Il peut s'exécuter localement sur l'appareil de l'utilisateur ou à distance sur un autre serveur.
Un serveur MCP peut exposer trois types principaux de capacités :
L'hôte et le serveur négocient d'abord les fonctionnalités du protocole qu'ils prennent en charge tous les deux. Le client peut ensuite demander la liste des capacités disponibles. Lorsque le modèle décide qu'un outil est pertinent, l'hôte achemine la requête structurée via le client MCP vers le serveur approprié.
Le résultat revient à l'application d'IA et devient un contexte supplémentaire pour la prochaine réponse du modèle.
Supposons qu'un développeur demande à un assistant IA interne :
“Vérifiez nos dépenses API pour ce mois-ci. Si elles dépassent le budget de plus de 20 %, créez une alerte pour l'équipe d'ingénierie.”
Un flux de travail MCP simplifié pourrait ressembler à ceci :
get_api_usage et get_budget_limit.create_alert.MCP normalise le milieu de ce processus : découvrir les outils, décrire leurs exigences d'entrée, les appeler et renvoyer des résultats structurés.
Il n'effectue pas le calcul lui-même, ne fournit pas le modèle de langage et ne remplace pas les API de facturation et de messagerie.
Ces termes sont souvent présentés comme des technologies concurrentes. En pratique, ils opèrent à différents niveaux et apparaissent fréquemment dans la même application.
| Concept | Ce qu'il résout | Son lien avec MCP |
|---|---|---|
| API | Permet à un système logiciel de demander des données ou des actions à un autre | Un serveur MCP appelle souvent des API existantes en arrière-plan |
| Appel de fonction | Permet à un modèle de produire une requête structurée pour un outil prédéfini | Un hôte peut convertir les définitions d'outils MCP en fonctions que le modèle peut sélectionner |
| RAG | Récupère des informations externes pertinentes avant qu'un modèle ne réponde | Un serveur MCP peut exposer des outils ou des ressources de récupération, mais MCP lui-même n'est pas du RAG |
| MCP | Normalise la manière dont les applications d'IA compatibles se connectent aux outils et aux données et interagissent avec eux | Fonctionne comme la couche de connexion et d'interopérabilité |
Non. MCP et les API résolvent des problèmes connexes mais différents.
Une API définit comment un service particulier peut être appelé. Par exemple, une API de facturation peut définir un endpoint qui renvoie l'utilisation du compte.
MCP définit comment une application d'IA peut découvrir et utiliser une capacité exposée par un serveur compatible. Ce serveur peut appeler l'API de facturation pour obtenir les données réelles.
En d'autres termes :
Une API connecte un logiciel à un service. MCP aide une application d'IA à travailler avec de nombreux services via un protocole commun.
Une intégration API directe peut encore être plus rapide et plus facile lorsqu'une application n'a besoin que d'une seule fonction fixe. MCP devient plus attractif lorsque les développeurs souhaitent réutiliser des outils sur plusieurs clients IA ou permettre aux capacités disponibles d'évoluer dynamiquement.
Non. L'appel de fonction est généralement une capacité du modèle. Les développeurs décrivent une ou plusieurs fonctions, et le modèle produit des arguments structurés lorsqu'il décide qu'une fonction doit être utilisée.
MCP fonctionne autour de ce processus. Il peut aider l'application à découvrir les définitions d'outils depuis les serveurs connectés, au lieu d'exiger que chaque outil soit codé en dur dans l'application.
Le modèle peut toujours s'appuyer sur l'appel de fonction ou d'outil pour sélectionner un outil fourni par MCP.
Non. La génération augmentée par récupération, ou RAG, est une méthode qui consiste à récupérer des informations pertinentes et à les ajouter au contexte d'un modèle avant qu'il ne réponde.
Un serveur MCP pourrait exposer un outil de recherche de documents qui fait partie d'un système RAG. Cependant, MCP ne décide pas comment les documents sont indexés, comment les résultats sont classés, ni comment le texte récupéré est ajouté à un prompt.
MCP peut transporter la requête et le résultat. C'est le système de récupération qui effectue la recherche.
MCP peut rendre les outils plus réutilisables dans les applications compatibles. Il peut également permettre à une application de découvrir les outils disponibles et leurs entrées requises, au lieu de s'appuyer entièrement sur des connexions codées en dur.
Mais plusieurs affirmations courantes vont trop loin.
MCP ne permet pas de :
Il ne donne pas non plus au modèle un accès illimité à chaque service connecté. L'hôte contrôle quels serveurs sont connectés, tandis que les capacités du serveur et les permissions utilisateur déterminent ce qui peut être lu ou modifié.
MCP mérite d'être envisagé lorsqu'une application doit se connecter à plusieurs outils ou sources de données, surtout si ces capacités peuvent être réutilisées sur différents hôtes d'IA.
Les situations typiques incluent :
Une intégration API directe peut être la meilleure option lorsque l'application a un flux de travail étroit, n'utilise qu'un seul service, ou nécessite un contrôle précis de bas niveau sur chaque requête. Ajouter un serveur MCP introduit un composant supplémentaire à déployer, sécuriser, tester et observer.
MCP réduit une partie de la répétition des intégrations. Il n'élimine pas les compromis architecturaux.
MCP n'est pas automatiquement sûr ou dangereux. La sécurité dépend de l'hôte, du serveur, de ses services sous-jacents, du flux d'authentification et des permissions accordées à chaque action.
Un serveur connecté peut recevoir des informations sensibles de l'application d'IA. Un outil disposant d'un accès en écriture pourrait également modifier des fichiers, envoyer des messages, créer des enregistrements ou déclencher d'autres actions externes.
Les recommandations de sécurité MCP couvrent les risques suivants : le passage de jetons (token passthrough), la falsification de requête côté serveur, le détournement de session, les serveurs locaux compromis et les attaques par député confus. Ce sont des risques d'implémentation, pas des avantages théoriques qui disparaissent parce qu'un système utilise un protocole standard.
Les développeurs devraient appliquer plusieurs contrôles de base :
OpenAI avertit de même que les serveurs MCP personnalisés peuvent recevoir des données et effectuer des actions externes, et recommande de se connecter uniquement à des serveurs de confiance. Son implémentation actuelle exige une confirmation avant les actions d'écriture dans les conversations ChatGPT, mais les développeurs ne devraient pas supposer que chaque client MCP applique la même politique. la documentation MCP d’OpenAI
En date de juillet 2026, la dernière spécification MCP stable reste la version publiée le 25 novembre 2025. Le projet officiel a déclaré qu'il n'avait pas publié d'autre version de spécification depuis lors. La feuille de route MCP 2026 décrit le travail planifié, et non des fonctionnalités déjà garanties dans le protocole stable.
La spécification actuelle définit deux transports standards :
stdio pour la communication avec les processus locaux.Streamable HTTP a remplacé l'ancien transport HTTP+SSE, bien que les clients et les serveurs puissent conserver une rétrocompatibilité. La spécification de transport actuelle inclut également des exigences et des recommandations couvrant l'authentification, la validation de l'origine, la liaison au réseau local et la gestion des sessions.
La gouvernance de MCP a également changé. En décembre 2025, le protocole est devenu un projet fondateur de l'Agentic AI Foundation de la Linux Foundation. La fondation a signalé plus de 10 000 serveurs MCP publiés et une adoption dans des produits tels que ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor et Visual Studio Code. annonce de la Linux Foundation
La feuille de route 2026 se concentre sur quatre domaines : l'évolutivité des transports, la communication entre agents, la gouvernance et la préparation à l'entreprise. Les pistes d'audit, l'authentification intégrée SSO, la portabilité de la configuration et le comportement des passerelles font partie des problèmes d'entreprise encore en cours de traitement.
Ce dernier point est important. MCP a dépassé le stade de l'expérimentation pour les outils de développement locaux, mais certaines parties de sa sécurité d'entreprise et de son modèle opérationnel arrivent encore à maturité.
GPT Proto et MCP appartiennent à différentes couches d'une application d'IA.
MCP connecte l'application à des outils et à un contexte externes. L'application a toujours besoin d'un modèle pour comprendre la requête, choisir une action et générer la réponse finale.
Ce modèle peut être accessible via un fournisseur d'API de modèles. Les développeurs qui utilisent le catalogue de modèles GPT Proto peuvent choisir parmi des modèles de texte et de raisonnement pour cette couche d'inférence, tandis que les serveurs MCP gèrent les connexions aux systèmes externes.
Une configuration simplifiée pourrait contenir :
Les deux couches sont complémentaires. Une API de modèle commune peut faciliter les tests ou le changement du modèle derrière une application ; MCP peut réduire le travail répétitif lors de la connexion de cette application à plusieurs outils.
TL;DR Best direct APIs: OpenAI is the safest general-purpose default; Anthropic Claude is strongest for coding and long-running agents; Gemini suits low-cost multimodal prototyping; and DeepSeek leads on text-token price. Best multi-model options: OpenRouter is the clearest choice for testing many LLMs. GPTProto is the stronger fit when one product needs text, image, and video models under one API key and shared balance. Best infrastructure choices: Amazon Bedrock fits AWS-governed enterprise deployments, while Replicate, fal.ai, and Together AI are better suited to open-model or generative-media inference. There is no universal winner. Compare workload fit, model coverage, real billing units, production controls, and switching cost. Prices and availability were checked on July 14, 2026; verify live provider pages before deployment.
Tiffany Layne | 2026-07-15
En bref : Kimi K3 est le modèle de codage le plus performant lorsque la tâche est difficile, longue ou visuelle. Il devance GLM-5.2 dans la comparaison de codage publiée par Moonshot et accepte les images et les vidéos via son service hébergé. GLM-5.2 reste le meilleur choix par défaut pour le travail courant sur les dépôts : il coûte beaucoup moins cher, est plus compact à exploiter et utilise la licence MIT permissive. Kimi K3 propose désormais aussi des poids téléchargeables, mais son dépôt de 1,56 To, son déploiement recommandé avec au moins 64 accélérateurs et sa licence personnalisée en font un engagement nettement plus important pour l'auto-hébergement. Choisissez Kimi lorsque les capacités constituent le facteur limitant ; choisissez GLM lorsque le coût et la simplicité opérationnelle comptent au quotidien. L'aspect intéressant de la comparaison de code GLM-5.2 vs Kimi K3 n'est pas que les deux modèles puissent écrire un composant React ou résoudre un algorithme court. Les modèles de ce niveau franchissent déjà cette étape. La vraie question est de savoir ce qui se passe lorsque la mission devient complexe : audit d'un dépôt, migration portant sur plusieurs fichiers, bogue qui n'apparaît que dans une capture d'écran ou prototype Three.js jouable devant maintenir la cohérence de plusieurs systèmes. C'est également à ce moment que l'écart de prix commence à compter. Kimi K3 semble meilleur sur les tests publics les plus difficiles, mais son tarif officiel de sortie est plus de trois fois supérieur à celui de GLM-5.2. Une équipe qui effectue des milliers de revues ordinaires pourra peut-être accomplir davantage de travail par dollar avec GLM. Un développeur qui tente de sauver un projet visuel particulièrement difficile acceptera volontiers de payer pour K3.
Tiffany Layne | 2026-07-28
J’ai vu beaucoup de gens générer une magnifique illustration avec l’IA, s’enthousiasmer, puis abandonner discrètement vers la quatrième page. La première image n’est jamais le problème. Le problème, c’est que la page quatre ressemble toujours au même renard que celui de la page une — et que chaque page est suffisamment nette pour être réellement imprimée. La plupart des sites de type « créateur de livres pour enfants avec l’IA » dissimulent ces deux problèmes derrière un bouton accueillant, puis vous livrent une image de 1024 pixels qui devient floue dès qu’une imprimante la touche. Ce guide emprunte une autre voie : un petit pipeline API reproductible que vous exécutez vous-même. Il s’adresse aux personnes qui souhaitent un contrôle programmatique — génération par lots, même personnage sur 24–32 pages et fichiers conformes aux spécifications d’impression — plutôt qu’un gadget en un clic. Si vous voulez simplement une image pour le coucher sur votre téléphone, un outil sans code est réellement plus rapide et vous devriez en utiliser un. Si vous souhaitez produire un livre entier tout en maîtrisant vos coûts et votre qualité, poursuivez votre lecture. À la fin, vous disposerez d’un workflow qui produit un ensemble de pages intérieures en résolution d’impression (300 DPI), avec des personnages cohérents, ainsi qu’une couverture, en utilisant deux modèles via une seule GPTProto clé API, pour environ un dollar de coût de génération.
Katherine Lawrence | 2026-06-12
Connecter GLM-5.2 à un agent de programmation ne prend que quelques minutes. Lui fournir suffisamment de contexte pour corriger un dépôt sans le laisser s’égarer est la partie la plus difficile. Cette distinction est importante. Un modèle peut écrire une fonction propre dans une fenêtre de discussion et tout de même échouer sur une véritable tâche d’ingénierie parce qu’il modifie la mauvaise couche, rompt un contrat d’API, ignore la suite de tests ou consacre la moitié de son contexte à lire des fichiers générés. GLM-5.2 est conçu pour les tâches de programmation longues pilotées par des outils, mais le modèle a toujours besoin d’un flux de travail d’agent rigoureux. Ce guide présente trois méthodes pratiques : utiliser GLM-5.2 avec Claude Code, appeler l’ API GLM-5.2 sur GPTProto depuis un agent compatible avec OpenAI, et exécuter les poids ouverts localement. Il explique ensuite comment définir une tâche au niveau du dépôt, gérer le contexte de 1 million de tokens, vérifier les modifications et estimer le coût réel en tokens. En bref Utilisez Claude Code avec le point de terminaison compatible Anthropic de Z.ai si vous travaillez déjà avec cet agent dans le terminal. Utilisez le point de terminaison compatible OpenAI de GPTProto pour Cline, OpenCode, un agent personnalisé ou une application qui utilise déjà le SDK OpenAI. N’envoyez pas par défaut un monorepo entier simplement parce que GLM-5.2 accepte jusqu’à 1 million de tokens. Commencez par une cartographie du dépôt, les fichiers pertinents, les contraintes et les commandes de test. Utilisez le niveau de raisonnement High pour les investigations courantes et Max pour les tâches ambiguës impliquant plusieurs fichiers, lorsqu’un mauvais plan serait coûteux. Considérez les modifications de l’agent comme non fiables tant qu’elles n’ont pas passé le build, le linting, les vérifications de types et les tests du dépôt. N’exécutez le modèle localement que lorsque la confidentialité, le contrôle ou un usage soutenu justifient une infrastructure importante. « Poids ouverts » ne signifie pas « adapté à un ordinateur portable ».
Schuyler Stacy | 2026-07-17
