Par Chahid Naoufel

Publié le · Modifié le · Vérifié le

Les points essentiels

  • La spécification MCP finale datée du 28 juillet 2026 standardise les échanges entre un hôte, des clients et des serveurs exposant ressources, prompts ou outils.[3][1]
  • Elle complète les API ; elle ne remplace ni leur logique métier ni leurs contrôles.[1][2]
  • Un serveur MCP étend la surface d’action de l’agent et doit être traité comme une intégration sensible.[1][2]
  • Le transfert de jetons sans validation appropriée est explicitement interdit par cette version de la spécification.[3]
  • Nous recommandons de commencer en lecture seule, avec un petit périmètre et des journaux exploitables.

Un protocole commun ne rend pas une intégration sûre par défaut

MCP facilite la découverte et l’appel d’outils par plusieurs assistants. Cette portabilité est utile, mais elle peut aussi rendre une capacité dangereuse plus facile à brancher.[1][2]

L’adoption doit qualifier chaque serveur, chaque outil et chaque identité : qui l’exécute, à quelles données il accède, ce qu’il peut modifier et comment arrêter ou révoquer l’accès.[1][2]

Rôles et risques à comprendre

  • L’hôte coordonne l’expérience et les connexions.[1][2]
  • Le client MCP maintient la relation avec un serveur.[1][2]
  • Le serveur expose des capacités et peut accéder à des systèmes tiers.[1][2]
  • Les outils décrits en langage naturel restent des entrées non fiables.[1][2]
  • Les jetons doivent être émis pour la bonne ressource et validés.[1][2]
  • Les redirections, consentements et sessions d’autorisation exigent des protections explicites.[1][2]
  • Un serveur communautaire est une dépendance logicielle à auditer et mettre à jour.[1][2]

Décider capacité par capacité

Lecture documentaire

C’est un bon pilote si le corpus est borné, les secrets exclus et les réponses traçables.[1][2]

Écriture dans un outil

Ajoutez scopes fins, prévisualisation et approbation avant toute mutation.

Serveur distant

Vérifiez opérateur, transport, autorisation, résidence, journaux, disponibilité et procédure d’incident.

Serveur local

Local ne signifie pas sûr : inspectez exécutable, permissions, mises à jour et accès au poste.[3][1]

Grille de décision MCP

Grille de décision MCP
DimensionQuestionSeuil minimal
IdentitéQui appelle ?Identité attribuable
AutorisationQuel droit ?Scope minimal
DonnéesQue quitte le système ?Inventaire et filtrage
ActionQuel impact ?Confirmation proportionnée
FournitureQui maintient ?Version et provenance
SortieComment revenir ?Révocation et alternative

Comprendre l’architecture MCP

L’hôte coordonne l’expérience

L’hôte gère l’application qui utilise les capacités MCP, les connexions autorisées et les interactions de l’utilisateur. Il doit rendre visibles les serveurs, les outils et les confirmations plutôt que masquer leur origine.[1][2]

Le client maintient une relation avec un serveur

Chaque client échange avec un serveur selon le protocole et transporte les messages nécessaires. Cette séparation aide à raisonner sur les frontières, mais n’accorde aucun droit par elle-même.[1][2]

Le serveur expose ressources, prompts ou outils

Le serveur décrit des capacités et peut appeler des systèmes en aval. Sa description est une entrée à vérifier ; le code, les identités et les API sous-jacentes déterminent l’effet réel.[1][2]

MCP complète les API existantes

Le protocole normalise découverte et invocation pour les assistants. La logique métier, les transactions, les règles d’autorisation et les garanties de service restent dans les applications et leurs API.[1][2]

Vérifier la maturité avant de suivre les annonces d’adoption

Le support annoncé par un éditeur ne signifie pas que toutes les fonctions, transports ou contrôles sont disponibles dans votre version. Vérifiez documentation, date, offre, environnement, limitations et support opérationnel pour le couple hôte–serveur réellement utilisé.[1][2]

Open source ne signifie pas maintenance garantie

Licence, dépôt et code accessible facilitent l’audit, mais il faut encore examiner provenance, activité, versions, dépendances, processus de signalement et capacité interne à reprendre.

Compatibilité ne signifie pas portabilité complète

Deux hôtes peuvent interpréter différemment les fonctions optionnelles ou confirmations. Testez votre serveur et vos scénarios critiques dans chaque environnement prévu.[1][2]

Évaluer la surface d’attaque des serveurs MCP

Authentification et audience des jetons

Le serveur vérifie émetteur, audience, expiration et scopes. Un jeton destiné à une autre ressource ne doit pas être accepté ou retransmis comme raccourci d’intégration.[1][2]

Injection d’instructions et tool poisoning

Descriptions, résultats d’outils et documents peuvent contenir des instructions hostiles destinées au modèle. Ne traitez jamais le texte du serveur comme une politique supérieure ; contraignez les outils par code, droits et confirmations.[1][2]

Chaîne d’approvisionnement

Serveur, image, paquet, dépendances et mécanisme de mise à jour peuvent être compromis. Épinglez les versions, vérifiez les publications, analysez les changements et définissez une procédure de retrait.[1][2]

Confused deputy et autorisation transitive

Un hôte ou serveur peut agir avec plus de droits que l’utilisateur qui formule la demande. Chaque action doit être autorisée pour l’identité, la ressource et la finalité concernées.[1][2]

Données et obligations de protection

Inventoriez les données qui traversent l’hôte, le serveur, les systèmes en aval et les journaux. Finalité, minimisation, information, conservation et droits dépendent du traitement réel, pas du protocole.[1][2]

Quand utiliser une passerelle MCP

Une gateway peut centraliser inventaire, politiques, identité, filtrage, journalisation et révocation entre plusieurs hôtes et serveurs. Elle crée toutefois une dépendance et un point de concentration : disponibilité, administration et contournement doivent être testés.[1][2]

  • Catalogue de serveurs approuvés.[1][2]
  • Politiques de scopes par groupe.[1][2]
  • Filtrage des paramètres sensibles.[1][2]
  • Journal central et alertes.[1][2]
  • Blocage de versions retirées.[1][2]
  • Procédure de fonctionnement dégradé.[1][2]

Déployer MCP sans exposer l’entreprise

Commencer par un serveur en lecture seule

Choisissez un corpus borné, excluez les secrets inutiles et testez exactitude, permissions, refus et indisponibilité. Une lecture seule réduit l’effet mais ne supprime pas le risque de fuite.[1][2]

Ajouter l’écriture outil par outil

Pour chaque mutation, affichez les paramètres, imposez les scopes, gérez les doublons et testez l’annulation. Une confirmation générique couvrant plusieurs actions n’est pas suffisamment informative.[1][2]

Comparer serveur local et distant

Le local expose le poste, ses fichiers et son processus de mise à jour ; le distant ajoute transport, opérateur, résidence, disponibilité et support. Aucun des deux n’est sûr par nature.[1][2]

Préparer la sortie

Conservez la logique métier derrière des interfaces documentées, les tests hors de l’hôte et une méthode de révocation. Vérifiez qu’une intégration classique ou un autre hôte peut reprendre une capacité critique.

Garde-fous et points de contrôle

  • Refus du token passthrough.[1][2]
  • Validation audience et émetteur.[1][2]
  • Consentement non contournable.[1][2]
  • Liste blanche d’outils.[1][2]
  • Descriptions signées ou revues.[1][2]
  • Isolation des secrets.[1][2]
  • Journaux d’appels et résultats.[1][2]
  • Arrêt d’urgence et révocation.[1][2]

Déployer par étapes

  • Choisir un cas en lecture seule.[1][2]
  • Modéliser menaces et données.[1][2]
  • Auditer serveur et dépendances.[1][2]
  • Configurer identité et scopes.[1][2]
  • Tester injections et pannes.[1][2]
  • Ajouter écriture seulement après preuves.[1][2]
  • Réviser chaque mise à jour.[1][2]

Mesurer le résultat complet

  • Outils et scopes actifs.[1][2]
  • Appels refusés.[1][2]
  • Actions nécessitant confirmation.[1][2]
  • Incidents et temps de révocation.[1][2]
  • Versions non conformes.[1][2]
  • Taux de réussite sans élargissement de droits.[1][2]

Vérifier les textes et la version du produit

Les règles, modèles, tarifs et interfaces évoluent. Les sources officielles ci-dessous doivent être relues au moment de la décision, avec les contrats et paramètres du compte réellement utilisé.[1][2]

Questions fréquentes

MCP remplace-t-il les API ?

Non. Il fournit une couche commune pour exposer et découvrir des capacités qui s’appuient souvent sur des API.[1][2]

Un serveur MCP est-il sûr par défaut ?

Non. Sa provenance, ses permissions, son code et ses dépendances doivent être évalués.[1][2]

Qu’est-ce que le token passthrough ?

C’est l’acceptation ou le transfert d’un jeton non destiné au serveur concerné ; la spécification l’interdit.[3]

Faut-il commencer en lecture seule ?

Oui lorsque c’est possible : cela réduit l’impact pendant que qualité, sécurité et exploitation sont testées.[1][2]

MCP est-il compatible RGPD ?

Le protocole ne crée pas la conformité ; elle dépend du traitement, des acteurs, des données et des mesures.[1][2]

Comment limiter le verrouillage ?

Gardez la logique métier derrière des interfaces testées et vérifiez qu’une autre intégration peut reprendre les capacités critiques.

Sources

  1. Security best practices — Model Context Protocol. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19↩20↩21↩22↩23↩24↩25↩26↩27↩28↩29↩30↩31↩32↩33↩34↩35↩36↩37↩38↩39↩40↩41↩42↩43↩44↩45↩46↩47↩48↩49↩50↩51↩52↩53↩54↩55↩56↩57↩58↩59↩60↩61
  2. Authorization — Model Context Protocol. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19↩20↩21↩22↩23↩24↩25↩26↩27↩28↩29↩30↩31↩32↩33↩34↩35↩36↩37↩38↩39↩40↩41↩42↩43↩44↩45↩46↩47↩48↩49↩50↩51↩52↩53↩54↩55↩56↩57↩58↩59
  3. The 2026-07-28 MCP specification release — Model Context Protocol. Publié le . Consulté le . ↩1↩2↩3↩4

Poursuivre votre lecture