Aujourd'hui, un agent qui veut ajouter un article au panier clique sur ce qui ressemble à un bouton et constate le résultat après coup. La page ne lui indique ni ce que fait ce bouton, ni ce qu'il déclenche, ni s'il peut être annulé. WebMCP (Web Model Context Protocol) prévoit que le site déclare lui-même ses fonctions comme des outils que l'agent peut lire.
Deux façons de déclarer un outil dans la page
Tout passe par navigator.modelContext. L'API déclarative annote des formulaires HTML existants. L'API impérative enregistre des fonctions en JavaScript, chacune avec un nom, une description et un schéma d'entrée. Pour une boutique, cela donnerait par exemple registerTool({ name: 'add_to_cart', description: 'Ajoute un produit au panier, annulable depuis la page Panier', inputSchema: { type: 'object', properties: { sku: { type: 'string' }, quantity: { type: 'integer', minimum: 1 } }, required: ['sku'] }, execute }). L'exemple a été écrit pour cet article et ne vient d'aucun site en production.
L'agent reçoit donc un contrat typé, sans avoir à interpréter la mise en page.
Chrome 149 ouvre un origin trial, le W3C ne parle que de brouillon
Chrome a lancé une preview en février 2026, puis un origin trial avec Chrome 149 le 9 juin 2026. Un origin trial est une phase d'essai : les sites inscrits activent la fonction pour leurs visiteurs, les autres ne la voient pas. La proposition est portée par des ingénieurs de Google et de Microsoft. Le W3C (World Wide Consortium) l'héberge dans son groupe Web Machine Learning, sous forme de Draft Community Group Report : un document de discussion, pas un standard. Les notes techniques communautaires signalent que la période où l'on peut encore infléchir la conception se termine quand les implémentations figent le dessin.
Safari s'oppose à WebMCP : un agent doit utiliser le site comme un humain
L'équipe WebKit a déposé son opposition dans le suivi public des positions de standards. Voici l'extrait qui résume sa position :
Un agent qui agit pour le compte d'un utilisateur est, en fait, une technologie d'assistance : il devrait opérer le site comme l'utilisateur, et le site ne devrait pas le traiter différemment.
Pour WebKit, un site difficile à manipuler par un agent a souvent une sémantique déjà faible, et la correction passe par HTML et ARIA (Accessible Rich Internet Applications). Les lecteurs d'écran, la navigation au clavier et les agents en profitent ensemble. La proposition WebMCP indique elle-même ne pas viser les technologies d'assistance, ce qui donne du poids à l'objection : l'effort d'ingénierie irait aux outils pour machines, sans bénéfice direct pour les personnes qui naviguent au clavier.
Mozilla se dit réservé sur la sécurité et la vie privée. On n'a pas trouvé de texte détaillé à citer, et cette position reste à confirmer.
Chaque outil exposé augmente la surface d'attaque et le nombre de tests
Une description d'outil est du texte lu par un modèle. Un contenu tiers affiché sur la page, un avis client par exemple, peut y glisser des consignes détournées : c'est l'injection de prompt, déjà documentée pour les protocoles d'outils d'agents en général. Une boutique qui publierait cinquante outils (recherche, panier, compte, retours, modification de commande) multiplierait les cas à tester, les droits à vérifier et les effets de bord à décrire.
Une dizaine d'actions à fort usage suffit pour commencer. Pour chacune, la description de l'outil peut indiquer si l'action est réversible et si elle requiert une confirmation de la personne.
Le travail ressemble à celui de l'accessibilité : on recense les parcours, on rédige des libellés explicites, on arbitre entre couverture et utilité. L'accessibilité dispose en plus d'obligations légales et d'audits. WebMCP n'a qu'un origin trial et un groupe de travail, et aucun navigateur ne le livre à tous ses utilisateurs.
Les demandes « prêt pour l'IA » se règlent avant le protocole
Ces demandes arrivent déjà dans les briefs. Avant d'écrire une ligne de WebMCP, il reste à décider quelles actions du site méritent d'être déclarées, lesquelles ne doivent jamais s'exécuter sans validation humaine, et ce qui se passe quand l'agent se trompe, par exemple en passant la même commande deux fois.
Le commerce agentique avance en parallèle. Le Universal Commerce Protocol (UCP) décrit, côté marchand, les fonctionnalités disponibles et la configuration du paiement, sans passer par le navigateur. Si ce type de protocole s'impose, la couche navigateur perdra de son intérêt pour les achats. On ne sait pas encore si WebMCP deviendra une couche commune ou s'effacera devant des API propriétaires, ni quelle sera la position finale de Mozilla.