Blog / · 7 min de lecture
MCP perd son statut de bricolage perso : la DSI vient de récupérer les clés
Chaque dev avec son token perso planqué dans un fichier de config, c'était pratique et complètement hors de contrôle. L'extension EMA fait rentrer MCP dans les clous de l'IT. Ce que ça résout, ce que ça complique, et pourquoi le dev solo n'y gagne pas grand-chose.
Bon. Tu te souviens de la dernière fois où t’as connecté un serveur MCP à Claude Desktop ou à VS Code ? Tu as cliqué “autoriser”, t’as collé un token, et t’es passé à autre chose. Personne dans ton IT n’a rien vu passer.
Multiplie ça par 200 employés, chacun avec ses propres serveurs MCP branchés à sa sauce, ses propres tokens qui traînent dans des fichiers de config locaux, et tu comprends pourquoi une équipe sécurité un peu sérieuse a fait une syncope en découvrant ça en revue d’accès.
C’est exactement ce trou que l’extension “Enterprise-Managed Authorisation” vient combler. Et elle vient de passer stable, en juillet 2026.
Le bricolage qui a bien marché, jusqu’à ce qu’il ne marche plus
MCP, à la base, c’est né pour du usage individuel. Tu ouvres ton client, tu branches un serveur, OAuth te fait cliquer “autoriser” une fois, et c’est plié. Chaque dev gère ses propres connexions, ses propres tokens, ses propres autorisations serveur par serveur.
Pour un solo dev ou une petite équipe, ça tourne très bien. Le souci arrive à l’échelle entreprise. Personne ne sait combien de serveurs MCP sont réellement branchés dans la boîte. Personne ne peut révoquer d’un coup l’accès d’un employé qui part, parce que les autorisations sont éparpillées, une par serveur, une par machine. Et la frontière entre compte perso et compte pro devient franchement floue quand le token qui autorise l’accès à un outil interne critique dort dans le fichier de config personnel d’un dev.
C’est ce que l’article d’InfoQ décrit bien : le modèle OAuth par utilisateur et par serveur générait un travail d’onboarding manuel sans fin, et rendait quasi impossible pour une équipe sécurité de faire appliquer une politique cohérente. Chaque connexion était une décision individuelle, jamais une décision d’entreprise.
Ce que EMA change vraiment
L’idée de fond : sortir la décision d’autorisation des mains de chaque employé pour la remettre entre celles du fournisseur d’identité (IdP) de l’entreprise. Okta, Entra ID, peu importe le nom, tant qu’il implémente l’extension.
Concrètement, l’utilisateur fait une seule connexion, celle qu’il fait déjà tous les matins pour accéder au reste des outils de la boîte, et cette connexion lui donne accès aux serveurs MCP pré-approuvés par l’IT. Plus de pop-up de consentement serveur par serveur. Plus de token perso à générer et à planquer quelque part.
Techniquement, ça repose sur un mécanisme d’échange de jeton, l’ID-JAG (Identity Assertion JWT Authorization Grant), qui permet de convertir l’identité déjà vérifiée par l’IdP en accès à un serveur MCP donné, sans repasser par un flux OAuth complet à chaque fois.
Okta est le premier fournisseur d’identité à supporter ça de bout en bout, via son mécanisme Cross App Access. Anthropic a implémenté le support côté Claude, Visual Studio Code a ajouté le support IDE. Et une bonne poignée d’entreprises qui exposent déjà des serveurs MCP suivent le mouvement : Asana, Atlassian, Canva, Figma, Linear, Supabase.
Ce n’est donc pas un gadget publié dans un coin. C’est porté par les trois acteurs qui comptent pour que ça devienne un standard de fait : celui qui fait le modèle, celui qui fait l’IDE, celui qui fait l’identité.
Ce qui coince, et il y a un vrai truc qui coince
Là où je tempère un peu l’enthousiasme : EMA règle la question de la connexion, pas celle de l’exécution.
L’article le dit clairement, et c’est le point le plus important à retenir. L’architecture sépare volontairement la politique d’identité, qui décide qui a le droit de se connecter à quel serveur, de l’autorisation d’exécution des actions, qui décide ce que l’agent a le droit de faire une fois connecté. EMA gère la première couche. La seconde reste, pour l’instant, largement entre les mains du serveur MCP lui-même et de sa propre logique d’autorisation par outil.
Autrement dit : ta DSI peut maintenant dire “seuls les devs de l’équipe paiement ont le droit de se connecter au serveur MCP qui touche à la prod de facturation”. Elle ne peut pas encore dire, avec le même mécanisme, “cet agent a le droit de lire les logs de facturation mais pas de déclencher un remboursement”. Cette granularité-là reste à construire, serveur par serveur.
Et il y a un deuxième angle mort, plus large que EMA lui-même, que SecurityWeek pointe bien : faire passer MCP à l’échelle entreprise déplace la charge de sécurité du protocole vers les développeurs et les opérateurs de plateforme. Un expert d’Akamai cité dans l’article résume ça sans détour : les frontières de sécurité critiques dépendent désormais entièrement de l’implémentation côté développeur. Nouveaux en-têtes HTTP spécifiques à MCP qui peuvent exposer des clés d’API dans des logs ou des proxys, tâches asynchrones longues qui ouvrent une surface de déni de service, XSS stocké via les extensions MCP Apps. EMA ne touche à aucun de ces sujets. Elle règle qui rentre, pas ce qui se passe une fois dedans.
Autant dire qu’une entreprise qui déploie EMA et se dit “bon, MCP est sécurisé maintenant” se fait des illusions. C’est une brique de gouvernance de plus, une bonne, mais une brique parmi d’autres.
J’en avais déjà parlé côté architecture pure dans l’article sur la refonte 2026 du protocole MCP : le protocole devient stateless, les sessions implicites disparaissent au profit de handles explicites. EMA s’inscrit dans la même révision, mais sur un axe complètement différent. Là où la refonte protocole règle “comment un serveur MCP tient son état”, EMA règle “qui a le droit de parler à ce serveur en premier lieu”. Les deux sujets avancent en parallèle, mais ne se recouvrent pas.
Ce que ça change dans un vrai workflow
Si tu bosses dans une boîte avec un IdP déjà en place, Okta en tête pour l’instant, le changement est net. Le service sécurité peut enfin faire une revue d’accès MCP qui ressemble à une vraie revue d’accès, pas à une chasse au trésor dans des fichiers de config éparpillés sur les postes. Quand quelqu’un quitte l’entreprise, couper son compte IdP suffit à couper son accès à tous les serveurs MCP pré-approuvés, d’un coup. Ça, c’est un vrai progrès, et n’importe quelle équipe sécurité qui a déjà géré un départ d’employé avec des tokens perso éparpillés partout te dira que c’était un vrai trou noir avant.
Si tu es dev solo ou dans une petite structure sans IdP d’entreprise digne de ce nom, cette extension ne te concerne à peu près pas. Tu continues comme avant : un clic, un token, un serveur. Ce n’est ni une régression ni un progrès pour toi, c’est juste que le protocole que tu utilises a maintenant deux modes de fonctionnement bien distincts, et le mode “gouverné” n’est pas taillé pour toi.
Si tu développes des serveurs MCP destinés à être utilisés en entreprise, en revanche, tu ne peux plus l’ignorer. Un serveur qui ne supporte pas EMA aujourd’hui devient un candidat naturel à l’exclusion des politiques d’accès centralisées de tes clients, même si son OAuth classique fonctionne très bien. Les organisations qui adoptent déjà l’extension, Atlassian, Figma, Linear, ne l’ont pas fait par coquetterie technique. Elles l’ont fait parce que leurs clients entreprise vont commencer à l’exiger dans leurs critères de sécurité fournisseur.
Le fond du truc, c’est que MCP grandit. Il est né comme un outil de bricoleur, un truc qu’on branche vite pour tester une idée. Il devient, sous la pression des mêmes acteurs qui l’ont poussé au départ, un protocole qu’une DSI peut auditer, gouverner, et couper d’un coup de bouton si besoin. C’est une bonne nouvelle pour qui doit dormir la nuit en sachant qui a accès à quoi. C’est une couche de friction en plus pour qui voulait juste brancher un serveur MCP un samedi après-midi sans avoir à demander la permission à personne.
Sources
Continuer la lecture