WebMCP arrive dans Chrome 149 : préparer un site aux agents sans sacrifier sa sécurité

Chrome 149 ouvre un essai d'origine pour WebMCP, une proposition d'API qui permet à une page web de déclarer des actions structurées à destination des agents IA. Au lieu de regarder une capture, interpréter le DOM puis simuler une suite de clics, l'agent peut découvrir un outil tel que filter_results, run_diagnostics ou start_application avec une description et un schéma d'entrée.

L'objectif n'est pas de remplacer l'interface humaine ni les serveurs MCP. WebMCP rapproche l'agent de la logique déjà présente dans l'onglet, avec l'état courant, l'authentification de l'utilisateur et une interface visible. Cette promesse de fiabilité crée aussi une nouvelle surface d'action. Une fonction mal conçue peut exposer des données, provoquer une modification irréversible ou relayer une injection de prompt. L'expérimentation doit donc commencer par des tâches étroites et réversibles.

La réponse rapide

Question	Réponse
WebMCP est-il un standard stable ?	Non. Il s'agit d'une proposition en discussion et d'un essai temporaire dans Chrome 149. L'API peut changer.
Que déclare un site ?	Des outils avec un nom, une description, un schéma d'entrée et une fonction exécutée dans la page.
Faut-il un serveur MCP ?	Non pour les outils WebMCP de la page. Ils complètent les intégrations MCP côté serveur au lieu de les remplacer.
Le site doit-il rester ouvert ?	Oui. Le contexte de navigation et l'interface visible sont requis ; le scénario principal n'est pas l'automatisation headless.
Un agent peut-il appeler tous les outils du web ?	Non. La découverte suit les origines, la Permissions Policy et les règles d'exposition explicites.
Est-ce protégé contre toute injection de prompt ?	Non. Chrome rappelle qu'aucun modèle probabiliste ne peut garantir cette sécurité. La validation et la confirmation restent indispensables.

Pourquoi les agents ont besoin d'une interface structurée

Un agent généraliste agit aujourd'hui souvent comme un utilisateur approximatif. Il observe une page, recherche le bouton qui semble correspondre à l'intention, remplit un champ, attend une mise à jour puis recommence. Chaque étape peut échouer après un changement de libellé, un déplacement visuel, une fenêtre modale ou une ambiguïté entre deux commandes.

WebMCP laisse le site déclarer ce qu'une action signifie. Le schéma distingue un prénom d'un nom complet, une date ISO d'un libellé libre ou une opération de lecture d'une modification. La fonction réutilise ensuite la logique cliente et met à jour l'interface sous les yeux de l'utilisateur. L'agent ne contourne donc pas nécessairement l'expérience conçue par le produit.

Cette approche peut réduire le nombre d'étapes et les hallucinations sur les paramètres. Elle ne rend pas l'agent déterministe. Il doit encore choisir le bon outil, collecter les bonnes valeurs et interpréter le résultat. Plus la page expose d'outils proches, plus ce choix devient difficile et consomme du contexte.

Les cas d'usage avancés par Chrome incluent les formulaires structurés, les réservations complexes, l'orientation vers le bon parcours de support et le déclenchement d'un diagnostic caché dans des menus. Le meilleur candidat n'est pas forcément l'action la plus spectaculaire, mais celle où l'automatisation par clic est fragile et où le résultat peut être vérifié visuellement.

WebMCP n'est pas le protocole MCP côté serveur

MCP connecte habituellement un client IA à un serveur distant ou à un processus local par un protocole dédié. Cette intégration peut fonctionner sans page ouverte et donne accès à une API, une base ou un outil système. Elle exige souvent une authentification et une logique distinctes de celles du site.

WebMCP est une API de plateforme web inspirée du même vocabulaire d'outils et de schémas. Le code s'exécute dans la page, suit son cycle de vie et partage son état. L'utilisateur conserve l'interface, sa session et la possibilité de voir l'effet produit. La proposition vise les parcours collaboratifs avec une personne dans la boucle, pas un agent autonome travaillant des heures en arrière-plan.

Une entreprise peut conserver un serveur MCP pour les opérations automatisées et ajouter WebMCP aux tâches qui dépendent du contexte visuel ou d'une confirmation dans le navigateur. Choisir l'un n'oblige pas à abandonner l'autre. Il faut en revanche documenter où se trouve l'autorité : côté serveur, dans le client web ou dans les deux.

Une inscription impérative minimale

L'API JavaScript actuelle utilise document.modelContext. La documentation précise que l'ancien navigator.modelContext est déprécié à partir de Chrome 150 ; un prototype neuf doit donc employer directement l'interface documentée la plus récente.

const controller = new AbortController()

await document.modelContext.registerTool({
  name: 'prepare_support_request',
  description: 'Prepare a support request for the issue visible on this page.',
  inputSchema: {
    type: 'object',
    properties: {
      category: {
        type: 'string',
        enum: ['billing', 'access', 'technical']
      },
      summary: { type: 'string', maxLength: 500 }
    },
    required: ['category', 'summary']
  },
  annotations: {
    readOnlyHint: false,
    untrustedContentHint: true
  },
  async execute(input) {
    const values = validateSupportRequest(input)
    showSupportDraft(values)
    return { status: 'draft_ready' }
  }
}, { signal: controller.signal })

// Retirer l'outil lorsque l'état de la page ne le permet plus.
controller.abort()

Cet exemple prépare un brouillon visible au lieu d'envoyer immédiatement la demande. La validation reste dans le code de l'application, même si le schéma annonce déjà les types et valeurs attendus. AbortSignal retire l'outil lorsque l'utilisateur change de page, se déconnecte ou quitte le contexte où l'action est valide.

Le schéma n'est pas une frontière de sécurité. Chrome recommande de valider strictement dans le code et de renvoyer des erreurs compréhensibles. Un client ou une future implémentation peut produire une entrée inattendue, et les règles métier changent plus vite que la déclaration descriptive.

L'API déclarative pour les formulaires

WebMCP prévoit aussi une forme déclarative qui annote un formulaire HTML. Elle convient lorsque l'action correspond déjà clairement à des champs et à une soumission. Le navigateur peut en dériver un outil sans dupliquer toute la structure dans un objet JavaScript.

L'approche impérative reste nécessaire pour la navigation, les états dynamiques, un assemblage de plusieurs composants ou une opération qui ne se résume pas à envoyer un formulaire. Les deux formes doivent conserver un HTML sémantique : WebMCP est un enrichissement progressif, pas une excuse pour rendre l'interface inaccessible aux personnes ou inutilisable dans les autres navigateurs.

Un site doit continuer à fonctionner lorsque l'API est absente. La détection de capacité, les boutons ordinaires et les messages d'erreur restent la base. Une fonctionnalité commerciale essentielle ne devrait pas dépendre d'un essai d'origine expérimental.

Essayer WebMCP dans Chrome 149

Pour un test local, Chrome documente le drapeau chrome://flags/#enable-webmcp-testing, suivi d'un redémarrage. Pour un site accessible à des utilisateurs pilotes, l'équipe peut s'inscrire à l'origin trial de Chrome 149 et déployer le jeton selon les règles habituelles des essais d'origine.

Un origin trial est limité dans le temps et peut comporter des restrictions d'usage. Il sert à obtenir des retours sur l'API avant une éventuelle stabilisation, pas à promettre une disponibilité permanente. Le plan de test doit inclure le retrait du jeton et le comportement du site lorsque document.modelContext n'existe plus.

Chrome propose aussi une extension d'inspection des outils. Elle permet de voir les inscriptions actives, appeler manuellement une fonction, contrôler le JSON Schema et examiner sorties ou erreurs. Les conversations de test de cette extension utilisent par défaut un modèle Gemini de préversion ; ce composant est séparé des fonctions Gemini intégrées à Chrome.

L'équipe devrait tester plusieurs formulations d'une même intention, des valeurs manquantes, des données trop longues, les changements de route et les appels répétés. Un test unitaire vérifie le code de la fonction ; une évaluation agentique vérifie que l'agent choisit cette fonction au bon moment.

Origines, iframes et politique de permissions

WebMCP exige un document isolé par origine. Si le site désactive cette isolation, notamment avec Origin-Agent-Cluster: ?0 et l'usage de document.domain, les API sont désactivées. Cette contrainte stabilise l'origine associée à l'outil pendant son existence.

La Permissions Policy tools vaut self par défaut. Une page de premier niveau et ses cadres de même origine peuvent inscrire des outils, tandis qu'un iframe tiers ne le peut pas automatiquement. Pour autoriser un cadre externe, la page doit déléguer explicitement la capacité, par exemple avec allow="tools".

Cette délégation ne suffit pas à elle seule. L'outil impératif doit également définir les origines sécurisées dans exposedTo, et le consommateur doit demander les outils de cette origine. Cette double décision réduit l'exposition accidentelle entre cadres.

Une liste large affaiblit le modèle. Il faut nommer les origines HTTPS exactes, comprendre qui les administre et éviter de partager une action contenant des données personnelles avec un fournisseur qui n'en a pas besoin. Un outil en lecture seule peut déjà révéler un historique, des favoris ou un identifiant client.

Le risque central reste l'injection de prompt

Une page peut afficher un avis, un commentaire utilisateur, un ticket importé ou une description provenant d'un tiers. Si ce texte contient une instruction malveillante destinée à l'agent, celui-ci peut tenter de l'exécuter comme si elle faisait partie de sa mission. Le fait que l'appel final passe par un outil structuré ne supprime pas cette injection indirecte.

Chrome recommande untrustedContentHint lorsque la sortie contient des données externes ou produites par des utilisateurs. readOnlyHint signale qu'un outil ne modifie pas l'état. Ces annotations aident l'agent à appliquer ses garde-fous et à décider d'une confirmation, mais elles ne constituent pas une autorisation serveur.

Chaque fonction doit refaire les contrôles classiques : session, rôle, appartenance de la ressource, protection CSRF lorsque pertinente, limites de fréquence, validation métier et journalisation. L'interface ne doit jamais considérer qu'un appel WebMCP est fiable parce qu'il vient du navigateur de l'utilisateur.

Une opération irréversible doit demander une confirmation explicite dans une interface que le contenu de la page ne peut pas imiter. L'utilisateur doit voir l'objet, le montant, le destinataire et l'effet exact. « L'agent a demandé cette action » n'est pas une preuve d'intention suffisante.

Concevoir peu d'outils, mais des outils nets

Chrome conseille une fonction par outil et des rôles sans chevauchement. create_event signifie que l'événement sera créé ; start_event_creation indique seulement l'ouverture ou la préparation du parcours. Cette différence évite qu'un agent choisisse une action définitive en croyant produire un brouillon.

Les noms et descriptions doivent rester courts. La recommandation préliminaire évoque 30 caractères pour les noms d'outil ou de paramètre, 500 pour une description d'outil, 150 pour un paramètre et environ 1 500 caractères pour une sortie. Ces budgets peuvent évoluer, mais ils rappellent qu'une documentation entière ne doit pas entrer dans le contexte à chaque appel.

Il vaut mieux accepter une donnée utilisateur brute puis la normaliser dans le code que demander au modèle d'effectuer un calcul inutile. Une plage « 11:00-15:00 » peut être interprétée par la fonction plutôt que transformée en nombre de minutes par l'agent. Les types, énumérations et erreurs explicites réduisent les tentatives hasardeuses.

L'outil doit mettre l'interface à jour lorsque l'action réussit. L'utilisateur et l'agent partagent ainsi le même état observable. Pour un traitement lent, un statut clair et une possibilité d'annulation valent mieux qu'une réponse prématurée affirmant que tout est terminé.

Une méthode d'expérimentation responsable

choisir une tâche fréquente, étroite, réversible et facile à vérifier ;
mesurer le parcours actuel par clics avant d'ajouter l'outil ;
conserver une interface et un HTML sémantique pleinement fonctionnels ;
donner à chaque outil un verbe et un effet sans ambiguïté ;
limiter les paramètres et valider toutes les entrées dans le code ;
inscrire l'outil uniquement dans les états où il est utilisable ;
séparer lecture, préparation et action irréversible ;
exiger une confirmation humaine pour les effets sensibles ;
tester prompt injection, appels répétés, changements de page et erreurs réseau ;
prévoir le retrait de l'essai et suivre l'évolution de la proposition.

Les métriques utiles ne se limitent pas au taux d'appel. Il faut comparer la réussite de bout en bout, le nombre de corrections, les abandons, les confirmations annulées et les incidents de permission. Une action appelée rapidement mais corrigée manuellement ensuite n'est pas une amélioration.

Une expérimentation qui peut changer le contrat du web

WebMCP propose aux sites de ne plus laisser les agents deviner toutes leurs interfaces. Une action déclarée par son auteur peut être plus robuste qu'une chaîne de clics et conserver l'utilisateur dans une page visible. Pour les formulaires complexes et les outils métier, le potentiel est réel.

Le projet demeure expérimental, discuté publiquement et susceptible de changer. Son adoption ne devrait donc pas commencer par le paiement, la suppression ou l'administration globale. Un petit outil en lecture ou un brouillon contrôlé permet d'évaluer la fiabilité sans transférer trop tôt l'autorité à l'agent. Si WebMCP se stabilise, les équipes qui auront traité sécurité, sémantique et évaluation comme un même sujet disposeront de la base la plus solide.