Qu’est-ce que MCP en IA ? Model Context Protocol Expliqué

Pourquoi l’IA a besoin de connexions externes

Un assistant IA peut bien expliquer du code ou rédiger un ordre du jour de réunion. Demandez-lui d’inspecter un problème de dépôt en direct ou les fichiers privés derrière ce problème, et une lacune apparaît. Il en va de même pour votre calendrier ou une base de connaissances interne. Le modèle peut être capable d’interpréter les informations, mais l’application a toujours besoin d’un moyen contrôlé de les récupérer.

Les développeurs construisent traditionnellement ces connexions une à la fois. Un assistant obtient une intégration de dépôt. Un autre a besoin d’un connecteur de calendrier, tandis qu’un troisième accède au même suivi de problèmes via une interface différente. À mesure que les applications IA et les systèmes externes se multiplient, leurs intégrations aussi. Chaque connexion apporte des décisions d’authentification et de permissions, suivies de responsabilités continues en matière de maintenance et de traitement des données. À grande échelle, les connexions ponctuelles deviennent du travail d’ingénierie répété.

La pièce manquante n’est pas un modèle plus intelligent. C’est une limite de connexion réutilisable entre les applications IA et le contexte ou les actions externes. Ce guide localise cette limite et trace une demande à travers elle. Il sépare ensuite les concepts voisins et vous aide à juger de son adéquation.

Ce qu’est le MCP et pourquoi il existe

Model Context Protocol (MCP) est une norme ouverte qui permet aux applications IA compatibles de se connecter de manière cohérente à des systèmes externes fournissant des données, des outils et des flux de travail réutilisables. Ceci reprend l’introduction officielle. « Norme ouverte » signifie que les fournisseurs peuvent implémenter des règles publiques partagées au lieu du format de connecteur privé d’un seul produit. En pratique, une capacité publiée via MCP peut servir plusieurs hôtes compatibles, selon ce que chaque hôte supporte et autorise.

L’analogie courante est « USB-C pour les applications IA ». Au lieu d’inventer une prise différente pour chaque appairage, les produits peuvent implémenter une norme de connexion partagée. La limite compte autant que l’analogie. La compatibilité ne prouve pas qu’un système est sûr, autorisé ou de haute qualité. Cela ne signifie pas non plus que chaque hôte supporte les mêmes fonctionnalités.

Anthropic a introduit MCP le 25 novembre 2024, puis l’a contribué à la Agentic AI Foundation de la Linux Foundation en décembre 2025. C’est maintenant un projet ouvert et multi-fournisseurs plutôt qu’une fonctionnalité propriétaire réservée à Anthropic. Le support est généralisé dans les principales applications IA et outils de développement, bien que l’implémentation et le comportement d’approbation varient.

Architecture MCP : Hôtes, Clients et Serveurs

L’hôte MCP est l’application IA orientée utilisateur. Il coordonne l’interface, le modèle et les connexions aux systèmes externes. La politique de l’hôte détermine quelles capacités apparaissent et quand une approbation est requise. L’hôte retourne également les résultats à l’utilisateur. Le modèle fonctionne à l’intérieur ; il ne se connecte normalement pas directement aux systèmes externes.

Un client MCP est le composant parlant le protocole que l’hôte crée ou gère pour une connexion serveur. Il y a un client par serveur connecté. L’interface du produit peut le masquer, mais le client et l’hôte restent distincts. Des clients séparés maintiennent les connexions et les capacités exposées sous le contrôle de l’hôte.

Un serveur MCP est un programme qui expose des capacités via MCP—pas une classe matérielle. Le même serveur pourrait s’exécuter sur un ordinateur portable et fonctionner avec des fichiers locaux sélectionnés sous le compte de l’utilisateur. Exécutez-le en tant que service distant, et l’identité réseau et la disponibilité deviennent des préoccupations opérationnelles. Son rôle MCP reste le même dans les deux emplacements.

Les serveurs exposent trois types de capacités principales. Un outil est une opération, comme récupérer un problème ou créer un événement calendrier. Une ressource est un contexte lisible, comme un fichier, un enregistrement ou un schéma. Une invite est un modèle d’interaction réutilisable, comme une invite d’examen d’incident.

User request
     ↓
┌─ MCP host: AI application ───────────────────────────┐
│ Interface + model + policy/approval + result handling│
│                                                     │
│ ├─ MCP client A ────────────────────────────────────┼─⇄ Local MCP server
│ └─ MCP client B ────────────────────────────────────┼─⇄ Remote MCP server
└─────────────────────────────────────────────────────┘          │
                                                                 ├─ each exposes tools / resources / prompts
                                                                 ├─ local server ⇄ local files or application
                                                                 └─ remote server ⇄ external API, database, or service

Request/action travels →        Result/context returns ←

L’aperçu architectural officiel approfondit davantage. Un serveur peut se situer devant une API ou une base de données existante. Il peut également exposer l’accès à une interface de ligne de commande, un système de fichiers ou un service métier. MCP standardise l’exposition et l’échange ; le système sous-jacent stocke les données ou effectue l’action.

En termes de service d’assistance, l’hôte coordonne la visite. Chaque client est un commis parlant le protocole assigné à un guichet, tandis que chaque serveur publie un menu de capacités. Ce menu montre la disponibilité, pas la sécurité.

Comment fonctionne une demande MCP

Considérez cette architecture en action. Un développeur demande à un assistant de codage d’inspecter un problème et les fichiers de référentiel pertinents, puis d’expliquer la cause probable. La tâche est en lecture seule : enquêter, mais ne pas modifier, valider, fusionner ou déployer.

Un flux conceptuel typique comporte six étapes :

1. L’hôte se connecte. L’assistant est configuré pour accéder aux serveurs de problèmes et de référentiel via ses clients MCP.
2. L’hôte découvre et filtre les capacités. Les clients découvrent ce que leurs serveurs offrent ; l’hôte réduit l’ensemble par configuration, pertinence et permission.
3. L’utilisateur pose la question. L’hôte donne au modèle la demande, le contexte disponible et uniquement les descriptions de capacités pertinentes.
4. Le modèle propose une opération. Il sélectionne un outil de lecture approprié. L’hôte applique la politique et demande l’approbation si nécessaire ; le comportement varie selon l’hôte et la configuration.
5. Le serveur effectue le travail. Il appelle le suivi des problèmes, l’interface du référentiel ou l’API et retourne les résultats structurés via le client.
6. Le modèle interprète les preuves. L’hôte ajoute les informations retournées au contexte du modèle, et le modèle l’explique à l’utilisateur.

Ici, la découverte de capacités

Comme le montre le diagramme, la demande se déplace de l’hôte au client, au serveur et au système sous-jacent. Les résultats retournent par le même chemin avant que le modèle les utilise.

Un ensemble de capacités petit et spécifique à une tâche est souvent meilleur que le catalogue complet. Une exposition étroite limite les privilèges inutiles. Moins de descriptions réduisent également l’utilisation de jetons, les coûts et la latence tout en rendant la sélection d’outils moins confuse. La découverte fournit des options ; l’hôte décide lesquelles entrent dans l’interaction.

MCP, APIs, Function Calling, Agents, and RAG

MCP, APIs, function calling, agents, and retrieval-augmented generation (RAG) sont souvent présentés comme des rivaux. Ils résolvent des problèmes différents et travaillent régulièrement ensemble.

La chaîne en couches peut ressembler à ceci : service/API sous-jacent → serveur MCP → client/hôte MCP → sélection d’outils du modèle → boucle d’agent optionnelle.

Dans l’exemple du référentiel, une API fournit les données, et un serveur MCP expose une opération de lecture délimitée. Function calling permet au modèle de proposer cette opération. Une boucle d’agent optionnelle peut répéter les lectures approuvées. Le service conserve son interface existante tandis que les hôtes compatibles gagnent un moyen standard de découvrir l’opération.

« Connecteur » et « plugin » sont des étiquettes de produit, pas des synonymes MCP. L’un ou l’autre peut utiliser MCP ou une intégration propriétaire ; le nom seul ne révèle pas le protocole.

Cas d’usage pratiques de MCP

Les cas d’usage de MCP ont deux formes pratiques. Les opérations de contexte et de lecture rassemblent des preuves sans modifier la source. Les actions conséquentes créent un effet externe, comme la mise à jour de données ou l’envoi d’un message. MCP peut exposer les deux ; la section sécurité explique les contrôles plus stricts nécessaires pour le deuxième groupe.

Les projets initiaux les plus sûrs sont donc étroits et axés sur la lecture :

Les équipes de développement peuvent utiliser un éditeur, une interface de chat et un outil d’examen contre les mêmes dépôts et problèmes. Une capacité partagée donne à chaque hôte le même contexte limité, réduisant le travail de configuration avant qu’une investigation puisse commencer.

Pour les équipes métier, la valeur immédiate est une préparation plus rapide. Le contexte approuvé de la base de connaissances ou du CRM peut soutenir un brouillon de réponse ou un résumé de réunion, de sorte que le personnel passe moins de temps à rassembler les antécédents avant examen.

Les auto-hébergeurs peuvent utiliser le même modèle pour vérifier les fichiers privés et les services de laboratoire personnel sans basculer entre plusieurs interfaces. Les équipes cloud et IT peuvent intégrer les journaux, les métriques et les runbooks dans une investigation, ce qui facilite la corrélation des preuves d’incident.

Dans les quatre lignes, un projet initial utile a une source nommée, une tâche claire et un résultat observable. Cela rend sa valeur plus facile à juger avant que la portée ne s’élargisse.

MCP local vs distant

Un serveur MCP est un rôle logiciel qui peut résider dans deux emplacements courants. Un serveur local est un processus que l’hôte lance ou atteint via stdio, ce qui signifie une entrée/sortie standard directe entre les processus locaux. Il se situe près des fichiers et applications locaux, sert souvent un seul client et peut s’exécuter avec les privilèges de l’utilisateur.

Un serveur distant est un service continuellement accessible via HTTPS utilisant le transport distant de MCP (actuellement HTTP Streamable). Il peut servir un ou plusieurs hôtes compatibles. « Distant » signifie accessible par ses clients réseau prévus, pas nécessairement exposé à l’internet public.

Local:  AI host → stdio → local MCP process → scoped local files/app
                        [same-machine trust boundary]

Remote: AI host → HTTPS → remote MCP service → API/database/business system
                        [network + identity trust boundary]

L’exécution de MCP à distance crée des responsabilités de service ordinaires. L’accès et les secrets ont besoin de protection, tandis que les journaux et la surveillance rendent le comportement visible. La correction, la disponibilité et les limites réseau deviennent également des préoccupations opérationnelles. La section suivante couvre ces contrôles en détail.

Un VPS AlexHost standard peut convenir à un petit service MCP distant toujours actif ou à une passerelle. L’hébergement IA AlexHost n’importe que lorsque l’inférence de modèle auto-hébergée est une charge de travail distincte et gourmande en calcul. MCP lui-même ne nécessite pas de GPU.

Sécurité et confiance MCP

La compatibilité devient une question de sécurité lorsque les données et les actions franchissent la limite. Un serveur peut recevoir des données sélectionnées ou exposer des outils qui déclenchent des actions externes. Le nom et la description d’un outil sont des affirmations logicielles, pas une preuve de comportement sûr. La même prudence s’applique à ses annotations.

Le placement change le risque. Un serveur local est du code exécutable qui peut hériter de l’accès aux fichiers et au réseau de l’utilisateur. Un serveur distant reçoit des données sur un réseau, donc son identité et ses contrôles d’autorisation sont importants. La connexion dépend également de la protection du transport et de la confiance envers l’opérateur.

⚠️ Avertissement : la compatibilité de la connexion n’est pas un certificat de confiance. Comme avec USB-C, l’interopérabilité ne décide pas si un composant doit recevoir vos données ou permissions.

Utilisez cette base de six points :

1. Choisissez délibérément. Préférez les serveurs officiels, examinés ou contrôlés en interne. Inspectez la commande exacte et le paquet avant d’exécuter du code local.
2. Gardez l’exposition étroite. Autorisez uniquement les serveurs, capacités, répertoires, enregistrements et outils nécessaires. Commencez en lecture seule et appliquez le principe du moindre privilège—l’accès minimum requis.
3. Contrôlez les actions conséquentes. Exigez une approbation explicite ou une politique stricte pour l’envoi, la suppression, le paiement, le déploiement, le changement de permission et les opérations similaires.
4. Protégez l’accès distant. Utilisez l’authentification et l’autorisation appropriées, HTTPS, des identifiants limités en portée et une gestion prudente des secrets.
5. Isolez les processus locaux. Mettez-les en sandbox si possible, surtout quand ils n’ont pas besoin d’un accès large au système de fichiers ou au réseau.
6. Conservez les journaux utiles. Enregistrez les connexions, le partage de données, les appels d’outils, les approbations, les défaillances et les résultats pour l’audit.

Un registre facilite la découverte, une licence open-source permet l’inspection, et une implémentation valide établit la compatibilité. Aucun seul ne garantit la sécurité. Les conseils officiels de sécurité MCP vont plus loin pour les implémenteurs.

La sécurité reste partagée. L’hôte contrôle l’exposition, et le serveur applique ses limites. L’opérateur protège le déploiement et les identifiants, tandis que le système sous-jacent autorise chaque demande.

Quand utiliser MCP

MCP justifie sa limite supplémentaire quand des capacités fournies indépendamment doivent être réutilisées sur des hôtes compatibles. La découverte au runtime peut également être importante quand ces capacités évoluent au fil du temps. Une limite partagée peut alors maintenir une gouvernance cohérente tout en permettant à la capacité et à l’hôte d’évoluer séparément.

Si une application n’a besoin que d’une petite intégration stable, un appel API direct ou une fonction détenue par l’application peut être plus simple. Si le code connaît déjà l’ordre des opérations, utilisez un workflow déterministe : une séquence prédéfinie favorisant la prévisibilité et l’auditabilité plutôt que les étapes sélectionnées par le modèle.

Utilisez ces six questions comme filtre pratique :

1. Plus d’un hôte AI compatible réutilisera-t-il la capacité ? Si non, une intégration directe peut suffire.
2. La capacité doit-elle évoluer indépendamment de l’hôte ou être découverte dynamiquement ? Si non, les fonctions détenues par l’application peuvent être plus simples.
3. Un modèle doit-il choisir parmi les opérations, ou la séquence est-elle déjà connue ? Les séquences connues favorisent le code déterministe.
4. L’équipe peut-elle gouverner cette limite ? Si non, n’ajoutez pas encore d’outils MCP conséquents ; appliquez d’abord les contrôles de la section sécurité.
5. La latence ajoutée, les erreurs de sélection de capacité et les opérations de service sont-elles justifiées par la réutilisation ? Si non, gardez la limite plus petite.
6. Les hôtes cibles supportent-ils les primitives et le comportement d’approbation dont le projet a besoin ? Si incertain, vérifiez la compatibilité avant de standardiser sur MCP.

Un « oui » à la découverte dynamique n’est pas une raison d’exposer le catalogue complet. Trop de descriptions consomment des tokens, ajoutent du coût et de la latence, et rendent la sélection moins fiable. Plus d’outils ne garantissent pas une meilleure application.

Commencez par l’intégration la plus simple qui fonctionne. Choisissez MCP uniquement quand la checklist pointe vers un avantage clair par rapport à une intégration directe.

Conclusion

Retournez à l’assistant du début. MCP n’a pas changé la capacité de raisonnement du modèle. Il a donné à l’hôte un moyen défini de récupérer le contexte externe sélectionné.

Le modèle mental est simple : le serveur expose ; le client se connecte ; l’hôte contrôle ; le système sous-jacent fait le travail. MCP est une couche de connexion au sein d’une pile IA plus large.

Avant d’adopter MCP, identifiez une capacité étroite et en lecture seule dont plus d’un hôte IA bénéficierait. Si vous ne pouvez pas en nommer une, commencez plutôt par une intégration directe.