WebMCP : mise à disposition d’outils de site web afin que les agents cessent de scraper le DOM

Les sites web ont été conçus pour les clics des utilisateurs, les formulaires et les API. De plus en plus, l’« utilisateur » peut être un agent IA qui ne touche jamais à l’interface visuelle. Les agents qui extraient des données depuis les arbres DOM ou qui pilotent des navigateurs échouent lorsque le formatage change. WebMCP (Web Model Context Protocol), proposé dans l’écosystème Chrome, vise à permettre aux sites d’exposer directement des outils structurés aux agents — noms, entrées, sorties et moments de leur utilisation — afin que l’automatisation devienne explicite plutôt que déduite.

Qu’est-ce que WebMCP ?

En bref, WebMCP permet à une page de publier des outils destinés aux agents au lieu d’espérer que les outils d’extraction devinent correctement.

Sans WebMCP, un agent doit improviser face à une interface opaque :

AI Agent → Reads HTML → Guesses → Clicks → Hopes it works

Avec WebMCP, la même intention devient une demande d’outil déclarée :

AI Agent → Reads structured tools → Executes correctly

La documentation de Chrome présente les avantages de WebMCP comme la vitesse, la fiabilité et la précision dans les interactions avec des agents.

Pourquoi WebMCP existe-t-il

Envisagez de réserver un hôtel. Le chemin fragile ouvre une page, trouve les champs à remplir, interprète les dates, clique sur « Rechercher » et analyse les résultats — vulnérable face aux modifications du DOM. Avec WebMCP, l’agent lance une opération structurée :

searchHotels({
 location: "Tokyo",
 checkIn: "2026-08-10",
 checkOut: "2026-08-15",
 guests: 2
})

Aucune archéologie XPath, aucune roulette de sélecteurs CSS, aucun détour visuel pour les flux courants — simplement une exécution par saisie.

Fonctionnement de WebMCP

Deux API complémentaires :

1. API impérative

JavaScript enregistre explicitement les outils :

navigator.webMCP.registerTool({
  name: "create-event",
  description: "Creates a calendar event",
  inputSchema: {
    type: "object",
    properties: {
      title: { type: "string" },
      date: { type: "string" }
    }
  },
  execute: async ({ title, date }) => {
    return await createCalendarEvent(title, date);
  }
});

Les agents reçoivent le nom de l’outil, son utilisation, les champs requis ainsi que le chemin d’exécution — la logique frontale exportée sous forme de capacités appelables.

2. API déclarative

Approche centrée sur l’HTML, en particulier pour les formulaires :

<form webmcp-tool="book-flight">
  <input name="from" />
  <input name="to" />
  <input name="date" />
</form>

L’environnement de exécution transforme le formulaire en un outil structuré, permettant ainsi aux applications existantes de devenir compatibles avec les agents grâce à de légères modifications du markup.

WebMCP versus MCP

La confusion est fréquente. Une distinction pratique : WebMCP vise l’interface utilisateur ; MCP vise les systèmes et services backend. On peut envisager MCP comme le cerveau du côté serveur et WebMCP comme le corps de l’interface. Ensemble, ils couvrent les outils d’agent full-stack sans obliger chaque action à passer par une automatisation du navigateur fragile.

Cas d’usage concrets

1. E-commerce

Un client demande des chaussures de sport dans le cadre d’un budget donné ainsi que la possibilité de passer commande. Les outils possibles incluent :

searchProducts()
filterProducts()
addToCart()
applyCoupon()
checkout()

L’agent termine le processus sans avoir à cliquer à travers des grilles.

2. Réservation de voyages

Recherche de vols, comparaison d’hôtels, réservation de transport terrestre, ajout d’assurance — via des outils et non des macros fragiles.

3. Tableaux de bord SaaS

Les interfaces d’analyse peuvent publier des opérations telles que :

generateReport()
downloadCSV()
inviteMember()
changeBillingPlan()

Des copilotes intégrés à l’application appellent alors les mêmes fonctionnalités que celles visibles par les utilisateurs sous forme de boutons.

4. Systèmes CRM

Au lieu de dix écrans à parcourir un par un :

createLead()
assignSalesRep()
scheduleFollowUp()

5. Support client

Annuler les abonnements, demander des remboursements, suivre les livraisons à l’aide d’outils vérifiés plutôt que grâce à des méthodes archaïques basées sur HTML.

Pourquoi les développeurs devraient s’en soucier

Le travail frontend évolue de « peindre des pixels » à « publier des outils pour les agents ». Les responsabilités se tournent vers une nomenclature claire, des schémas solides et une exécution fiable. La comparaison avant/après de la conception des fonctionnalités ressemble moins à :

Build components for humans

et plus à :

Build components for humans + machines

Bonnes pratiques

Garantir que les outils aient une seule fonction

Éviter les opérations trop complexes :

manageEverything()

Préférer des outils ciblés :

createInvoice()
sendInvoice()
downloadInvoice()

La spécificité améliore la précision des agents.

Utiliser des noms clairs

Des étiquettes opaques :

doTask()

Des noms révélant l’intention :

submitExpenseClaim()

Réduire la charge cognitive

Ne forcez pas le modèle à calculer à l’avance ce que l’application connaît déjà. Évitez :

durationInMinutes

Préférez accepter des entrées brutes que le backend peut normaliser :

startTime: "10:00"
endTime: "12:00"

Gérer les échecs avec élégance

Les agents tentent à nouveau. Les outils doivent être sûrs lors des tentatives répétées — l’idempotence est importante.

Problématiques de sécurité

Si les agents peuvent exécuter des outils, l’injection de scripts malveillants représentant des outils fictifs constitue un enjeu de recherche. Parmi les mesures d’atténuation à prévoir figurent la validation de l’origine, l’audit des inscriptions, les limites de permissions et les confirmations utilisateur concernant les effets secondaires. Ne faites pas confiance aveuglément aux inscriptions.

Le contexte global

WebMCP s’inscrit au sein d’un web agentiel plus large : les sites exposent leurs capacités, les agents les comprennent, les utilisateurs délèguent des tâches, ce qui permet d’achever le travail plus rapidement. Les équipes développent déjà des API pour les développeurs ; la prochaine étape consiste à créer des outils destinés aux agents. Les premiers adoptants qui se demandent « quels aspects de cette application devraient devenir des outils d’IA ? » influenceront la prochaine vague d’architecture web — de manière similaire à ce que REST, GraphQL, WebSockets et les composants serveur ont fait en passant de solutions spécialisées à des standards courants. La technologie est encore naissante, mais sa direction est difficile à ignorer.

Voie d’adoption pour les applications existantes

Commencez par marquer une formulaire ou une étape de paiement à haute valeur avec l’API déclarative, mesurez le succès des agents par rapport à l’ancien outil de scraping, puis étendez les outils impératifs aux flux nécessitant une validation personnalisée. Maintenez un contrôle de confirmation humaine pour les paiements et les modifications destructrices des comptes tant que les données en temps réel ne prouvent pas une idempotence sûre. Traitez les schémas des outils comme des API publiques : examinez leurs noms, mettez-les à jour en version et refusez les inscriptions provenant de scripts non fiables.