WebMCP, MCP au niveau du service ou utilisation classique du navigateur : où se situent les outils d’agent.

À première vue, WebMCP semble logique : l’utilisateur est déjà connecté, un agent fonctionne à l’intérieur du navigateur, et le site peut indiquer quelles actions sont disponibles, ce qui évite à l’agent de deviner l’emplacement des champs et des boutons. Le problème réside plutôt dans l’emplacement de cette interface. Lorsque des efforts sont déployés pour rendre une application utilisable par des agents, ces fonctionnalités doivent-elles être exposées par la page elle-même ou par les services qui la sous-tendent ? De plus, qu’ajoute une interface d’outil au niveau de la page par rapport aux outils généraux du navigateur ?

Ces deux questions encadrent l’évaluation qui suit.

Qu’est-ce que WebMCP ?

Avec WebMCP, un site enregistre des outils structurés que tout agent compatible peut appeler depuis le navigateur. Chaque outil indique ce qu’il fait, quels entrées il accepte et quel code le met en œuvre. L’enregistrement s’effectue en JavaScript ou via des formulaires HTML annotés. Chrome présente cette idée comme une norme proposée, dont les essais de déploiement commencent avec Chrome 149, et l’API est susceptible de changer.

Imaginez une page de recherche de vols. Sans WebMCP, un agent lit la page, localise le champ de destination, définit les dates et clique sur Rechercher. Avec WebMCP, le site pourrait publier un outil search_flights qui prend en charge la destination et les dates. L’agent n’a qu’à saisir les arguments, et l’application effectue la recherche.

Il convient de maintenir trois approches distinctes : MCP au niveau du service, WebMCP et utilisation générale dans le navigateur. Rien ne force à choisir l’une d’elles, et un même agent peut appeler un outil de service pour un produit, un outil de page pour un autre, et faire fonctionner directement le navigateur pour un troisième.

La préoccupation architecturale

La première réaction est que WebMCP entraîne les problématiques liées aux services dans la couche de présentation. La recherche de stocks, la modification d’une réservation ou la passation d’une commande dans une application commerciale typique se fait via un service backend, et le navigateur appelle déjà une extrémité qui effectue cette tâche. Alors pourquoi définir un contrat destiné aux agents à l’intérieur de la page plutôt qu’à côté de ce service ?

Une alternative naturelle part du contrat de service existant, tel qu’une spécification OpenAPI ou une définition gRPC, et construit l’interface MCP à partir de celui-ci. L’avantage réside dans le fait que l’équipe responsable de l’opération métier peut gérer les versions, tester et contrôler le contrat destiné aux agents, et les agents interactifs, les tâches par lots ainsi que les workflows planifiés peuvent tous l’utiliser.

Envelopper un point de terminaison interne dans un outil de page ne rend pas pour autant l’engagement lié au contrat moins lourd. Les agents reçoivent une opération avec des entrées et un comportement attendus, et les workflows échouent si ce comportement change. Où que l’outil soit exposé, l’équipe doit déterminer quelle compatibilité et quel soutien il offre, et placer l’interface au niveau web ne diminue pas pour autant ces responsabilités.

Un examen plus approfondi remet en question certaines de ces premières hypothèses.

• Le navigateur conserve un état réel. Un éditeur peut contenir un brouillon non enregistré, une sélection en temps réel ou des opérations locales sans équivalent significatif sur le serveur, et qualifier le client de simple coquille vide revient à ignorer tout cela.
• La logique n’a pas besoin d’être dupliquée. Un outil peut appeler la même fonction client qu’un bouton et, par son intermédiaire, le même point de terminaison backend. La véritable préoccupation réside dans le contrat supplémentaire imposé par l’outil avec son propre cycle de vie, ainsi que dans la manière dont les règles métier pourraient s’accumuler autour de lui avec le temps.

Les flux multi-écrans représentent le cas le plus complexe. Sélectionner plusieurs vols, attribuer des passagers et valider une réservation avant soumission peut être beaucoup moins coûteux si l’orchestration existante pour les clients est réutilisée. Une séquence écrite exclusivement pour l’agent soulève la question de savoir quels éléments relèvent de la présentation et quels éléments sont des règles métier. Les critères d’éligibilité et les autorisations doivent faire partie du service, et lorsque l’outil de page et l’outil de service sont en désaccord, quelqu’un doit assumer la responsabilité de cette incohérence ainsi que d’un ensemble commun de vérifications contractuelles.

Le parcours de service est plus difficile qu’il n’y paraît. La génération automatique d’outils à partir de centaines de points d’entrée API ne produit pas une interface utile pour l’agent. Les descriptions doivent être rédigées dans un langage orienté agent, les réponses doivent respecter des limites de taille, certaines opérations doivent être fusionnées, et une personne doit décider de ce qui doit être exposé.

Le degré de maturité est également important. Une certaine experimentation est attendue, mais une interface basée sur une API de navigateur en évolution ajoute une source supplémentaire de travail de maintenance.

La position affinée est donc que pour une opération commerciale durable, il est préférable qu’elle soit gérée directement près du service qui la met en œuvre, et qu’il faille une raison spécifique pour placer son contrat dans la page.

Réutilisation des sessions versus accès délégué

Les avantages en matière d’authentification proviennent du fait de fonctionner à l’intérieur d’un navigateur connecté, et WebMCP partage ce point avec l’utilisation normale d’un navigateur. La comparaison ici oppose cette commodité à l’accès délégué aux services. Ce que les outils WebMCP explicites ajoutent par rapport à l’interaction normale avec un navigateur est une question distincte, abordée plus loin.

Lorsqu’un agent clique sur un contrôle sur un site pour lequel il est connecté, l’application envoie sa demande au sein de la session existante, et un outil WebMCP invoqué directement peut utiliser cette même session. Aucun des deux n’a besoin d’une autorisation déléguée distincte entre l’hôte de l’agent et le service.

Cette approche gagne en attractivité d’un application à l’autre. Un flux de travail impliquant cinq services pourrait nécessiter cinq autorisations, cinq cycles de vie de jetons et cinq ensembles de exigences d’intégration, en plus des démarches de registration du client qui dépendent de chaque service. Si l’utilisateur est déjà connecté aux cinq sites, la réutilisation de ces sessions permet d’éviter une grande partie de cette configuration.

Appeler cela une authentification gratuite serait exagéré. Une session en temps réel possède son propre cycle de vie en matière de sécurité, et être connecté ne constitue pas un consentement pour tout ce qu’un agent pourrait tenter. Néanmoins, les économies réalisées grâce à l’intégration sont réelles. L’injection de commandes et les actions indésirables ne sont pas résolues simplement en choisissant un niveau de sécurité, car ces deux scénarios nécessitent des mesures de protection telles que des confirmations pour les opérations importantes, avec des niveaux d’exposition et de contrôle différents ; par conséquent, chaque conception doit évaluer ces risques indépendamment.

Comment CIMD réduit l’écart

L’accès au niveau de service s’améliore également. Les Documents de métadonnées d’ID de client (CIMD) résolvent un problème lié à OAuth : comment un client entièrement nouveau peut s’identifier à un serveur d’autorisation qui ne l’a jamais rencontré. Le client utilise une URL HTTPS comme identifiant, et cette URL fournit un document de métadonnées listant des éléments tels que les URI de redirection autorisés. Un serveur d’assistance le récupère et le vérifie, ce qui élimine la nécessité d’enregistrer à l’avance chaque paire client-serveur. La spécification d’autorisation MCP de novembre 2025 recommande de prendre en charge les CIMD et de les privilégier par rapport à l’enregistrement dynamique des clients lorsque aucune information préenregistrée sur le client n’existe.

Dans le cas des cinq services, le support CIMD sur les cinq serveurs d’autorisation élimine les inscriptions préalables. Les exigences d’autorisation et les cycles de vie des jetons par service restent inchangés, bien que les autorisations ou sessions existantes puissent réduire les demandes, de sorte qu’il n’est pas nécessaire d’effectuer cinq nouveaux connexions. Les décisions d’autorisation elles-mêmes ne sont pas affectées par CIMD.

Contexte, cycle de vie et découverte

Un document non enregistré montre l’importance de l’état local du navigateur. Un outil qui modifie le paragraphe sélectionné dans un brouillon inachevé fonctionne avec un état que le service n’a pas vu, ce qui constitue une raison plus spécifique d’exposer un outil de page plutôt que de transférer une opération backend.

Le problème, c’est que l’état local lie les outils à la page. Lorsqu’un utilisateur quitte la page ou la ferme, un agent peut devoir rouvrir l’application et reconstruire d’abord le contexte. La session de connexion peut très bien persister malgré la fermeture de la page, tandis que ce qui disparaît, c’est l’état non enregistré ou les outils qui s’y trouvaient.

La découverte est une question distincte : comment un agent peut-il savoir ce qu’un site propose ? Les limitations documentées de Chrome indiquent que le site doit être visité avant que ses outils WebMCP ne soient connus. Un point de terminaison MCP connu peut être consulté directement sans intervention humaine, mais en trouver un à partir d’une simple adresse web constitue un défi supplémentaire. De plus, les métadonnées OAuth ne permettent de localiser le serveur d’autorisation que pour des ressources protégées déjà connues, sans liste universelle des capacités MCP.

SEP-2127, intitulé MCP Server Cards, propose une méthode standard pour publier des métadonnées structurées de serveur via HTTP, permettant ainsi aux clients de découvrir les interfaces de service avant d’établir une connexion MCP, sans avoir à gérer de page destinée aux utilisateurs. C’est une direction prometteuse. Au moment de la rédaction de ce texte, la demande de modification est encore ouverte ; il s’agit donc d’une proposition pour combler un manque, et non d’une solution adoptée qui puisse être appliquée partout.

Aucune des deux approches ne présente actuellement d’avantage décisif en matière de découverte : les outils basés sur des pages exigent une visite sur le site, tandis que la découverte de services depuis une adresse arbitraire ne dispose pas encore de conventions universelles. Aucun de ces deux niveaux ne garantit non plus une bonne gouvernance, car les outils WebMCP peuvent être soigneusement testés et maintenus, tandis que les outils de services peuvent être mal conçus. La vraie question concerne la responsabilité de gestion et les workflows que l’interface doit prendre en charge.

Les agents navigateur fonctionnent déjà sans cela

Il est utile de vérifier ce qu’un agent navigateur peut découvrir sans WebMCP. Les définitions des outils de navigateur, au cours d’une même session desktop d’un agent de codage, privilégient les actions sur les éléments basées sur l’accessibilité lorsque c’est possible, en utilisant des captures d’écran pour fournir un contexte visuel ou en tant que solution de repli ; les informations d’accessibilité retournées pour une page de documentation étaient utiles. Il s’agit d’une observation spécifique à cette session et non d’une affirmation valable pour toutes les versions ou les paramètres par défaut.

L’intégration a fourni à l’agent une description structurée de l’interface affichée, incluant des champs de texte, des boutons, des étiquettes, des valeurs et des états, et des outils orientés DOM étaient disponibles pour les tâches appropriées. Une plus grande partie de la page était présentée sous forme de texte structuré, contrairement à ce que l’on pourrait attendre avec un fort recours aux captures d’écran. Pour un formulaire de recherche simple, l’agent pourrait recevoir quelque chose comme ceci.

1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled

À partir de là, un agent peut identifier le champ de destination, cliquer sur le bouton « Rechercher des vols » et vérifier l’état mis à jour. Les sémantiques HTML et les étiquettes d’accessibilité contiennent déjà une grande partie du sens d’une interface. La vue d’une page que reçoit un modèle dépend de l’intégration et non du nom du modèle, et la documentation d’OpenAI sur l’utilisation informatique montre des intégrations où les captures d’écran sont envoyées au modèle et les actions sont renvoyées via des outils fournis par l’application.

En résumé, les agents peuvent gérer un site sans WebMCP, ce qui réduit ce que les développeurs de sites doivent créer. Cela ne permet cependant pas de déterminer si WebMCP vaut la peine d’être utilisé. Un arbre d’accessibilité liste les contrôles, tandis qu’un outil bien conçu peut décrire toute une opération avec ses entrées, réduisant ainsi les interactions et les suppositions. Lorsqu’un agent navigateur fonctionne à travers une série de dix contrôles, l’application pourrait proposer un seul outil pour cette tâche. Chrome présente WebMCP comme une amélioration progressive et inclut un inspecteur pour tester les outils.

Aucune comparaison contrôlée entre l’utilisation d’outils WebMCP et sans eux n’a été effectuée pour cette évaluation ; il s’agit donc d’un jugement architectural et non d’un résultat de performance. Un verdict équitable nécessiterait de mesurer l’achèvement des tâches, le nombre d’interactions et le temps écoulé dans plusieurs flux de travail. Une démonstration réussie constitue un bon point de départ, mais elle ne répond pas à cette question plus large.

Ce qui peut être déployé dépend également des interfaces que contrôle une équipe. WebMCP nécessite la coopération du site, et une intégration de services exige une interface de service accessible et autorisée. Lorsqu’une application tierce ne propose ni l’un ni l’autre, l’utilisation ordinaire du navigateur peut être le seul moyen viable.

Où cela nous mène

Les points de départ qui en découlent sont les suivants :

• Les outils au niveau du service conviennent aux opérations commerciales durables, en particulier aux flux non surveillés ou à long terme.
• WebMCP est adapté lorsque l’état de l’application locale est important ou lorsque la réutilisation d’un flux de travail de client authentifié permet d’économiser beaucoup de travail d’intégration.
• L’utilisation générale du navigateur couvre les cas où il n’existe pas d’outils dédiés, surtout les applications hors du contrôle de l’équipe.

Un malaise persiste lorsque WebMCP devient le standard pour des fonctionnalités qui disposent déjà de frontières de service bien définies. La commodité liée aux sessions constitue un argument puissant en faveur de son utilisation, mais elle ne devrait pas déterminer à elle seule l’architecture à long terme.

Des preuves susceptibles de changer ce point de vue montreraient, pour une application donnée, que les outils définis par la page surpassent clairement l’utilisation classique du navigateur, à un coût total inférieur à celui de la création et de la maintenance d’une interface de service, coût qui inclut l’autorisation, la maintenance, la gouvernance ainsi que les workflows que cette interface ne peut pas couvrir.

WebMCP est au plus fort lorsqu trois éléments coïncident : une session authentifiée en temps réel, un état local précieux et des flux de travail clients exploitables. L’utilisation ordinaire du navigateur permet également la réutilisation des sessions, ce qui pose la question de savoir quels outils explicites contribuent réellement. Un outil de page qui se contente de rediriger une opération vers un service a encore besoin d’une justification pour conserver le contrat destiné à l’agent sur cette page.