Explication de WebMCP : Fournir aux agents IA des navigateurs des outils plutôt que de se fier aux suppositions.

Demandez à un agent IA de réserver un vol sur un site web et observez ce qui se passe. Il ouvre la page et commence à explorer. Quel élément sert à choisir la date ? Quel menu déroulant affiche la destination ? Quel bouton nécessite deux clics parce qu’un volet modale le recouvre ? Parfois, l’agent parvient à ses fins. Parfois, il clique sur le mauvais élément, remplit un champ de données inutiles ou bloque lors du paiement en raison d’un changement de mise en page après l’entraînement du modèle.

C’est ainsi que fonctionnent aujourd’hui la plupart des agents basés sur le navigateur. Ils analysent le DOM, déterminent la fonction de chaque élément à partir de son étiquette et de sa position, puis simulent les clics et les frappes que ferait une personne. Cette technique s’appelle l’actuation ; elle fonctionne bien lors d’une démonstration mais échoue en pratique. Un simple changement de classe CSS ou un déplacement d’un bouton suffit à faire échouer un agent qui fonctionnait hier encore.

WebMCP est une réponse à ce problème. Si vous connaissez le Model Context Protocol (MCP) côté backend, l’idée est simple : on prend le concept d’outils et on le transfère dans le navigateur, afin qu’il existe sur les pages que vous créez.

Pourquoi se fier uniquement au DOM ne suffit pas

Actuellement, les agents accèdent à un service par l’une de deux voies :

• Intégration côté backend. Le service enregistre des outils auprès d’une plateforme d’IA, via un serveur MCP, OpenAPI ou une API propriétaire, et l’IA communique directement avec le serveur sans toucher au navigateur.
• Activation via le navigateur. L’agent ouvre la page comme un humain et devine quels éléments cliquer ou remplir.

Cette méthode d’activation est coûteuse et sujette aux erreurs. Chaque étape peut être interprétée de manière incorrecte, surtout dans des interfaces complexes et en couches comme les applications modernes à page unique.

WebMCP ajoute une troisième approche, qui n’est ni une intégration avec un backend ni un clic aveugle. Le site lui-même indique ce qu’il peut faire. Au lieu qu’un agent devine la fonction du bouton de paiement, le développeur précise ce que fait le processus de paiement, quels éléments d’entrée il nécessite et ce qu’il renvoie.

Qu’est-ce que WebMCP ?

WebMCP est une norme web proposée par le Web Machine Learning Community Group au sein du W3C. La spécification définit une API JavaScript ainsi que des annotations pour les éléments de formulaire HTML, afin qu’un agent sache comment utiliser les fonctionnalités de la page sans deviner.

Comparez-le avec MCP backend. Une page qui implémente WebMCP se comporte comme un serveur MCP dont les outils s’exécutent en tant que scripts côté client. Là où l’on aurait normalement besoin d’un serveur distinct pour exposer une fonction, il est possible de la déclarer depuis le JavaScript déjà en cours d’exécution sur la page.

Le design se compose de trois éléments :

• Découverte : une méthode standard permettant aux pages d’enregistrer des outils tels que checkout ou search_products auprès d’un agent.
• JSON Schema : des définitions explicites des entrées et des sorties attendues, ce qui réduit les hallucinations et les malentendus.
• État : une représentation partagée du contexte actuel de la page, afin que l’agent sache sur quoi il peut agir en ce moment.

Un dernier détail : les outils s’exécutent toujours de manière visible sur la page. Lorsqu’un agent appelle un outil add_to_cart, le résultat apparaît dans l’interface utilisateur plutôt que d’opérer en silence. Cela est important pour la confiance, car les utilisateurs peuvent voir ce qui est fait pour eux et l’expérience que vous avez conçue n’est pas contournée.

Enregistrement de WebMCP sur un site

Intégrer cette fonctionnalité à un site existant ne signifie pas le reconstruire. Il s’agit simplement d’une couche de communication supplémentaire ajoutée à un backend déjà fonctionnel. Les étapes sont les suivantes :

1. Activer l’environnement. Comme la norme n’est qu’une proposition, activez-la manuellement pour des essais. Dans Chrome, ouvrez chrome://flags/#enable-webmcp-testing, mettez-le sur « Enabled » et redémarrez le navigateur. Pour une version plus proche de la production, inscrivez-vous à l’essai WebMCP origin qui sera disponible à partir de Chrome 149, afin que de vrais visiteurs puissent utiliser cette fonctionnalité sans avoir à modifier les paramètres du navigateur.

2. Choisissez des outils dignes d’être présentés. Il est facile de sous-estimer cette étape. Ne présentez pas toutes les fonctionnalités simplement parce que vous en avez la possibilité. Réfléchissez aux actions pour lesquelles les utilisateurs souhaiteraient réellement l’aide d’un agent, généralement celles ayant un but clair : rechercher, filtrer, soumettre un formulaire, finaliser une commande. Évitez de mettre des dizaines d’outils sur une seule page, car chaque outil enregistré occupe de l’espace dans la fenêtre de contexte et un menu trop long complique le choix de l’agent.

3. Choisissez l’API impérative ou déclarative. L’API impérative enregistre des outils à l’aide de JavaScript pur via registerTool et convient à des logiques plus complexes telles que la gestion de l’état, la navigation ou la chaînage d’actions. L’API déclarative place des annotations directement sur un <form> HTML standard, ce qui permet de créer automatiquement l’outil adapté aux cas simples basés sur des formulaires. Les projets React et Angular disposent d’options natives aux frameworks respectifs. React propose le paquet usewebmcp, dont le hook useWebMCP lie le cycle de vie d’un outil au montage et au démontage d’un composant. Angular offre un support expérimental permettant de transformer des Signal Forms en outils.

4. Rendre le inputSchema détaillé. Cela détermine dans quelle mesure un agent comprend l’outil. Écrivez la description en langue naturelle simple, sans abréviations internes, et définissez chaque propriété avec son type. Pour un ensemble fermé de valeurs, utilisez enum afin que l’agent ait moins de chances d’envoyer des données invalides.

5. Définir les annotations en fonction du risque réel. Chaque outil nécessite une étiquette honnête :

• readOnlyHint: true pour un outil qui se contente de lire et de laisser tout inchangé.
• consequentialHint: true pour une action ayant des effets réels, qui doit d’abord demander la confirmation de l’utilisateur.
• untrustedContentHint: true lorsque la sortie contient du contenu provenant d’autres utilisateurs, comme des avis ou des commentaires, qui pourraient cacher une instruction.

6. Reliez execute à une endpoint existante. La fonction execute peut simplement appeler la route API que vous possédez déjà, en utilisant fetch(). Une route Laravel fonctionne parfaitement. Il n’y a pas de backend WebMCP distinct. Vous créez un pont frontend vers une logique métier déjà éprouvée en production.

7. Testez-le. Ajoutez l’extension Chrome intitulée Model Context Tool Inspector (Chrome Web Store), chargez votre page et voyez quels outils se connectent. Vous pouvez également contacter un agent depuis là pour confirmer que votre outil est bien appelé et que son schéma se lit correctement.

8. Traitez-le comme une amélioration progressive. La compatibilité avec les navigateurs est limitée, donc les clics sur des boutons ordinaires doivent continuer de fonctionner pour les visiteurs dont les navigateurs ne prennent pas en charge WebMCP. Cela ajoute une nouvelle voie sans remplacer l’ancienne.

Exemple : un outil de suivi de statut de commande

Prenez un magasin en ligne construit avec Laravel disposant d’une page d’état des commandes. Le flux normal consiste pour l’utilisateur à se connecter, ouvrir « Mes commandes », choisir une période et consulter une liste de commandes avec leur statut d’expédition. Un agent utilisant des outils d’automatisation devrait trouver le bon menu déroulant et le bouton de soumission, puis parser un tableau de résultats à partir d’HTML brut, ce qui ne fonctionne plus dès que le formatage change.

Avec WebMCP, une seule outil encapsule l’endpoint déjà existant :

await document.modelContext.registerTool({
  name: 'get_order_status',
  description: 'Look up orders within a given timeframe. Returns order number, shipping status, and current location.',
  inputSchema: {
    type: 'object',
    properties: {
      timeframe: {
        type: 'string',
        enum: ['today', 'yesterday', 'last_7_days', 'last_30_days', 'last_6_months'],
        description: 'Timeframe for the order lookup.'
      }
    },
    required: ['timeframe']
  },
  annotations: {
    readOnlyHint: true,
    consequentialHint: false,
    untrustedContentHint: false
  },
  execute: async ({ timeframe }) => {
    const response = await fetch(`/api/orders/status?range=${timeframe}`, {
      headers: { 'Accept': 'application/json' }
    });
    const data = await response.json();
    return JSON.stringify(data);
  }
});

Trois détails se détachent. Le inputSchema épargne à l’agent la nécessité de deviner le format, car il connaît les valeurs que timeframe accepte. L’annotation readOnlyHint: true indique que l’outil n’a pas d’effets secondaires, ce qui élimine la nécessité d’une confirmation. De plus, execute ne fait que faire appel à une route Laravel existante, de sorte que rien n’a à être reconstruit.

Le processus de paiement est plus sensible, car de l’argent est transféré et une commande est passée. Cela nécessite un signal différent :

await document.modelContext.registerTool({
  name: 'checkout_cart',
  description: 'Completes checkout for the currently logged-in user\'s cart.',
  inputSchema: {
    type: 'object',
    properties: {
      paymentMethod: { type: 'string', description: 'Payment method selected by the user' }
    },
    required: ['paymentMethod']
  },
  annotations: {
    readOnlyHint: false,
    consequentialHint: true,
    untrustedContentHint: false
  },
  execute: async ({ paymentMethod }) => {
    const response = await fetch('/api/checkout', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ payment_method: paymentMethod })
    });
    return await response.text();
  }
});

Avec consequentialHint: true, le navigateur ou l’agent sait qu’il doit afficher une boîte de dialogue de confirmation avant d’exécuter. Même si l’agent appuie sur le bouton, la décision finale reste entre les mains de l’utilisateur.

Pour lister les outils enregistrés sur une page :

const tools = await document.modelContext.getTools();
console.log(tools);

Et pour le déclencher manuellement à des fins de test :

const [tool] = await document.modelContext.getTools();
const result = await document.modelContext.executeTool(tool, '{"timeframe": "last_7_days"}');

Un aller-retour complet

Voici la séquence lorsque vous discutez avec un agent qui utilise l’outil get_order_status.

1. Vous tapez quelque chose comme « trouver mes commandes de la semaine dernière » à un agent dont la page du magasin est ouverte, en langage simple.
2. L’agent lance la recherche en appelant getTools() sur la page.
3. La page renvoie sa liste d’outils avec leurs schémas, y compris get_order_status avec sa description et son format d’entrée.
4. L’agent compare votre demande aux descriptions. Une description claire l’aide à choisir l’outil approprié immédiatement.
5. L’agent appelle executeTool() avec des arguments générés à partir de la conversation, tels que {timeframe: 'last_7_days'}.
6. La fonction execute de la page appelle le même point d’entrée Laravel via fetch(), exactement comme si vous cliquiez sur un bouton.
7. Le backend répond en JSON, et l’outil le renvoie à l’agent.
8. L’agent reformule le résultat en langage naturel et le présente, tout en maintenant l’ensemble visible dans l’interface de la page.

Pourquoi est-ce mieux que l’activation ?

• Cela nécessite moins de contexte. L’agent lit un schéma compact, et non des milliers de lignes de balisage, ce qui rend les réponses plus rapides et moins coûteuses.
• Les résultats restent cohérents. L’outil appelle réellement votre fonction, de sorte que la récoloration d’un bouton ou le déplacement d’un élément ne perturbe rien.
• Les utilisateurs gardent le contrôle. Les actions à haut risque marquées avec consequentialHint: true nécessitent toujours une confirmation, donc un agent ne peut pas les exécuter sans sollicitation.

C’est plus facile à auditer. Chaque interaction passe par un outil explicite, ce qui vous permet de consigner précisément ce qu’un agent a fait pour un utilisateur, ce qui est bien plus difficile lorsque les actions se limitent à des clics aléatoires.

Sécurité

Puisque les outils se trouvent sur vos pages, la sécurité est plus proche de la surface que dans le cas de MCP backend, qui fonctionne généralement de manière isolée sur son propre serveur. La spécification prévoit plusieurs mesures de protection :

• Isolation de l’origine. WebMCP ne fonctionne que dans des documents isolés par origine. Si une page active document.domain, par exemple via l’en-tête Origin-Agent-Cluster: ?0, WebMCP s’éteint.
• Politique de permissions. L’enregistrement des outils est contrôlé par la politique tools, dont la valeur par défaut est self ; ainsi, les iframes跨-origin ne peuvent pas enregistrer de outils à moins que vous ne l’autorisiez avec allow="tools".
• Exposition à une origine. Pour rendre un outil accessible depuis une autre origine, indiquez cette origine dans l’option exposedTo. Rien n’est exposé automatiquement.
• Trois indications d’annotation. readOnlyHint, consequentialHint et untrustedContentHint ne sont pas de simples étiquettes. Elles indiquent si un agent peut exécuter un outil sans confirmation, ou s’il doit traiter ses résultats avec prudence en raison de la présence de contenus non fiables tels que des avis d’utilisateurs, susceptibles de comporter une injection de commandes.

Une mise en garde honnête : l’isolation entre onglets est encore en développement. Lorsqu’un agent fonctionne sur deux onglets, rien ne garantit qu’aucun contexte sensible ne s’échappe d’un onglet à l’autre. Pour les flux nécessitant un haut niveau de confiance comme la banque, surveillez bien ce aspect avant de compter sur cette fonctionnalité.

État du support par navigateur

À mi-2026, c’est encore précoce :

• Le groupe communautaire W3C Web Machine Learning a officiellement accepté la spécification en septembre 2025.
• Chrome propose une version bêta depuis la version 149, et un support natif dans Chrome et Edge est prévu pour la seconde moitié de 2026.
• Pour des expériences locales, le paramètre chrome://flags/#enable-webmcp-testing fonctionne sans devoir rejoindre la version bêta.
• L’extension Model Context Tool Inspector affiche quels outils une page enregistre et peut simuler une conversation avec un agent.

La proposition peut encore changer, donc ne comptez pas sur une fonctionnalité finale à ce stade. Utilisez une approche d’amélioration progressive. Lorsque le navigateur prend en charge WebMCP, les agents bénéficient d’une expérience plus précise, tandis que dans le cas contraire, le flux manuel fonctionne comme avant.

Limites actuelles

• Aucun navigation sans interface utilisateur. L’API vise les workflows de navigateur locaux impliquant une personne, et non une automatisation non supervisée.
• Surcoût pour les interfaces complexes. Une application avec une gestion d’état sophistiquée nécessitera probablement un refactoring afin que les outils reflètent réellement l’état de l’application.
• La découverte nécessite une visite. Les clients ne connaissent l’existence d’outils sur un site que s’ils visitent la page correspondante. Il n’existe pas encore d’index global comme un sitemap pour ces outils.
• Aucuns ressources ni prompts disponibles pour l’instant. Deux autres primitives du MCP complet n’ont pas encore été intégrées au WebMCP. Si un agent doit lire des documents ou récupérer des données structurées ailleurs, un serveur MCP distinct reste nécessaire.

Où commencer

WebMCP complète MCP backend sans pour autant le remplacer. MCP backend reste adapté aux données et à la logique qui doivent résider sur un serveur, tandis que WebMCP convient à la couche d’interaction frontend : formulaires complexes, navigation en plusieurs étapes et actions liées à l’état de l’interface affichée.

Une manière sûre de commencer :

• Activer le paramètre local et enregistrer un outil simple, de préférence en lecture seule comme une recherche de produits.
• Utiliser correctement annotations dès le début. Ne reporter pas l’ajout de readOnlyHint et consequentialHint, car ce sont les fondements de la sécurité qui déterminent dans quelle mesure un agent peut être confié l’utilisation de votre outil.
• Suivre le répertoire du Web Machine Learning Community Group sur GitHub, car les discussions communautaires continuent d’ajuster les spécifications.

WebMCP est loin d’être mature, mais la direction est claire. Le web se voit doter d’un langage explicite pour communiquer avec les agents, un contrat clair entre le développeur et l’agent remplaçant les suppositions basées sur le DOM. Pour ceux qui sont habitués aux outils et schémas du MCP backend, ce changement leur semblera familier. Le contrat se trouve désormais uniquement dans le navigateur.