Il y a un indicateur fiable pour savoir où en est une technologie, et ce n’est pas le volume de discussion à son sujet.
C’est le type de session que les grandes plateformes lui consacrent.
Une session d’évaluation demande « est-ce que ceci vaut la peine ». Une session d’adoption explique comment le construire, comment l’exploiter et comment le sécuriser. La deuxième signifie que la première a déjà eu lieu, ailleurs, et que la réponse était oui.
La programmation, qui est le message
Microsoft a tenu une demi-journée sur MCP. Les créneaux : état du protocole, MCP chez GitHub, boîtes à outils dans Microsoft Foundry, construire des serveurs MCP avec VS Code, autorisation et sécurité MCP, FastMCP, agents pilotés par événements.
Aucune de ces sessions ne se demande si le protocole a un avenir. Elles supposent qu’on le déploie, et elles répondent aux questions qui viennent après cette décision.
La session sur l’autorisation et la sécurité est celle qui m’intéresse, mais elle n’est pas la plus instructive. Le reste de la programmation l’est davantage, parce qu’il indique le stade : quand une plateforme explique comment construire un serveur dans son éditeur et comment l’exposer dans sa plateforme d’agents, l’adoption est acquise.
Le trajet est connu
MCP entre dans les organisations par le même chemin que Docker, les extensions VS Code, npm et les frameworks JavaScript avant lui.
Personne ne décide de l’adopter. Un développeur l’installe parce que ça résout un problème concret un mardi après-midi. Ça fonctionne. Un collègue le remarque. Six mois plus tard, c’est dans un pipeline, et personne ne se souvient de la première installation.
Ce n’est pas une défaillance de gouvernance. C’est ainsi que l’outillage de développement s’est toujours diffusé, et les tentatives de le contrarier frontalement produisent surtout de l’invisibilité.
La différence qui compte
Ce qui distingue MCP des exemples précédents est ce que le composant détient.
Une extension d’éditeur améliore une expérience de rédaction. Un serveur MCP détient des credentials vers vos systèmes et exécute des commandes pour le compte d’un agent. C’est un composant d’intégration avec des droits, installé selon les habitudes de diffusion d’un utilitaire de confort.
Trois conséquences pratiques :
Il s’authentifie quelque part, donc il porte un secret.
Il s’exécute avec ses propres privilèges plutôt qu’avec ceux de l’utilisateur qui formule la demande. C’est le problème du député confus, et il fait que le contrôle d’accès construit autour de vos utilisateurs ne s’applique pas à ce chemin.
Il est mis à jour comme une dépendance, c’est-à-dire par un mainteneur dont vous ne savez rien, avec les modes de défaillance de n’importe quelle dépendance.
Les trois questions
Elles arrivent après l’adoption, ce qui est l’ordre habituel et non un échec particulier.
Quels serveurs MCP tournent chez nous ?
C’est un problème de découverte. Rien ne les inventorie par défaut. Les points de départ utiles : les fichiers de configuration des éditeurs sur les postes gérés, les définitions de conteneurs dans les dépôts, et le trafic sortant vers des points d’extrémité inhabituels depuis des machines de développement.
Avec quelles credentials ?
C’est la question qui détermine le rayon d’impact. Un serveur MCP avec un jeton en lecture seule sur un dépôt et un serveur MCP avec un principal de service qui peut écrire dans votre tenant occupent la même ligne dans un inventaire et ne représentent pas le même risque.
Qui les a approuvés ?
Elle paraît bureaucratique et elle ne l’est pas. Elle vous dit s’il existe un processus, ou seulement une habitude. Si personne ne peut nommer qui a approuvé un serveur donné, il n’y a pas de mécanisme qui empêchera le suivant d’entrer de la même manière.
Ce qu’il faut en faire
Pas un blocage. Un protocole que Microsoft et GitHub outillent activement ne se bloque pas de façon durable, et l’interdire produit surtout des installations que vous ne voyez plus.
Un inventaire, une position par défaut sur les credentials — portée limitée, courte durée, jamais le principal de service qui peut tout —, et un point d’entrée nommé pour approuver le prochain serveur.
Le protocole est arrivé. La question est seulement de savoir si vous l’apprenez maintenant ou pendant une investigation.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.