WebMCP : rendre ton site « agent‑ready » dans Chrome

WebMCP : rendre ton site « agent‑ready » dans Chrome

Sommaire

Pourquoi les agents « qui cliquent » cassent (et coûtent)

Aujourd’hui, beaucoup d’agents web font semblant d’être des humains. Ils lisent des screenshots, devinent où est le bon bouton, cliquent, attendent, recommencent.

Ça marche… jusqu’au jour où tu changes un libellé, un layout, ou un flow. Et là : flaky, latence, token‑burn, et bugs difficiles à diagnostiquer.

WebMCP tente de remettre une idée simple au centre : si ton site sait déjà faire une action, autant la décrire proprement.

Qu'est-ce que le WebMCP ?

WebMCP ajoute une couche "lisible pour une machine" au-dessus de ton interface web. Tu exposes des tools que le navigateur peut présenter à un agent.

Chrome parle de deux APIs complémentaires :

  • API déclarative : transformer des HTML forms en tools (low effort, gros gain).
  • API impérative : déclarer des tools en JavaScript (plus puissant, plus flexible).

WebMCP vs MCP (backend)

Le Model Context Protocol (MCP) « classique » est pensé client <---> serveur.

Tu exposes tes tools via un service (Node/Python), puis un agent consomme à distance (comme une API REST par exemple).

WebMCP, lui, s’exécute dans un onglet. Tu peux le voir comme « un MCP server… côté client », au plus proche de l’UI et de la session utilisateur.

Conséquence directe :

  • tu réutilises ton code front existant (state, auth, logique UI),
  • tu peux faire du human‑in‑the‑loop proprement,
  • mais tu as besoin d’un browsing context (pas de “headless” pur à ce stade).

L’API impérative : navigator.modelContext

L’API impérative sert quand ton UI est dynamique, ou quand tu veux retourner des résultats structurés sans passer par un formulaire.

Les 4 méthodes à connaître

  • provideContext({ tools }) : remplace tout le set de tools (pratique en SPA).
  • registerTool(tool) : ajoute un tool sans toucher aux autres.
  • unregisterTool(name) : retire un tool.
  • clearContext() : nettoie tout.

Un tool, c’est quoi exactement ?

Un tool est une définition JSON + une fonction execute. Le point qui change tout : l’inputSchema (JSON Schema) qui contractualise l’entrée.

Tu peux aussi annoter le tool avec un hint readOnlyHint quand il ne modifie rien.

Exemple : exposer une recherche de produits (retour JSON)

// Exemple minimal : un tool côté client.
// Objectif : éviter que l’agent scrolle, clique 12 filtres et parse du HTML.

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Recherche des produits dans le catalogue",
    annotations: { readOnlyHint: true },
    inputSchema: {
      type: "object",
      additionalProperties: false,
      properties: {
        query: { type: "string", description: "Texte libre" },
        category: { type: "string", description: "Catégorie (slug)" },
        minPrice: { type: "number", description: "Prix minimum" },
        maxPrice: { type: "number", description: "Prix maximum" }
      },
      required: ["query"]
    },

    // execute peut être async.
    // Le 2e param (client) sert notamment à demander une interaction utilisateur.
    execute: async ({ query, category, minPrice, maxPrice }, client) => {
      const params = new URLSearchParams({ query });
      if (category) params.set("category", category);
      if (minPrice != null) params.set("minPrice", String(minPrice));
      if (maxPrice != null) params.set("maxPrice", String(maxPrice));

      const res = await fetch(`/api/products/search?${params.toString()}`);
      if (!res.ok) {
        // Astuce : renvoyer une erreur explicite aide l’agent à se corriger.
        return { ok: false, error: `Search failed (${res.status})` };
      }

      const data = await res.json();
      return { ok: true, results: data.results };
    }
  });
}

Règles de design qui évitent les tools « inutilisables »

  • Nommer en verbe + complément : search_products, create_ticket, book_flight.
  • Faire petit : un tool = une intention claire.
  • Retourner du structuré : JSON stable, pas un blob de texte.
  • Gérer les erreurs : codes, messages et champs manquants.

L’API déclarative : transformer un <form> en tool

C’est la transition la plus progressive. Ton formulaire reste 100% utilisable par un humain, et si WebMCP est dispo, il devient aussi invocable par un agent.

Attributs clés

  • toolname : identifiant du tool.
  • tooldescription : description en langage naturel.
  • toolparamdescription : description d’un champ (paramètre).
  • toolautosubmit : autorise la soumission sans clic manuel.

Sans toolautosubmit, Chrome peut mettre en pause l’exécution côté agent et attendre une action utilisateur. C’est une approche “permission‑first” qui évite les surprises.

Exemple : formulaire de réservation

<form
  toolname="book_table"
  tooldescription="Réserver une table au restaurant"
  action="/reserve"
  method="post"
>
  <label for="date">Date</label>
  <input
    id="date"
    name="date"
    type="date"
    required
    toolparamdescription="Date de réservation"
  />

  <label for="time">Heure</label>
  <input
    id="time"
    name="time"
    type="time"
    required
    toolparamdescription="Heure (format local)"
  />

  <label for="guests">Convives</label>
  <input
    id="guests"
    name="guests"
    type="number"
    min="1"
    max="12"
    required
    aria-description="Entre 1 et 12"
  />

  <button type="submit">Réserver</button>
</form>

Accessibilité : ici, WebMCP récompense les bonnes pratiques

Chrome construit la description des paramètres en priorisant :

  1. toolparamdescription si présent,
  2. sinon le texte du label,
  3. sinon aria-description.

Traduction : si tes formulaires sont propres (label associés, ARIA utile), tu as déjà fait 80% du taf. Et tu améliores au passage l’expérience pour les lecteurs d’écran (WCAG 2.2, tout ça).

Signaux UI pour inspirer confiance

WebMCP introduit aussi des signaux “visuels” utiles :

  • des événements toolactivation et toolcancel (dispatch sur window),
  • des pseudo‑classes CSS :tool-form-active et :tool-submit-active.

Ça te permet d’afficher un état clair quand un agent “pilote” la page. Ton utilisateur voit ce qui se passe, au lieu de subir une magie opaque.

window.addEventListener("toolactivation", (e) => {
  console.log("Tool started:", e.toolName);
});

window.addEventListener("toolcancel", (e) => {
  console.log("Tool cancelled:", e.toolName);
});

/* Petit feedback visuel pendant l’interaction agent */
form:tool-form-active { outline: 2px solid currentColor; }
button:tool-submit-active { opacity: 0.7; }

Sécurité, consentement, et “human‑in‑the‑loop” (le vrai sujet)

Le risque, quand on parle d’agents, c’est de basculer dans un web qui fait des actions “dans ton dos”. WebMCP pousse plutôt une logique inverse : le navigateur arbitre.

Côté impératif, tu peux demander une interaction utilisateur pendant execute. Côté déclaratif, l’absence de toolautosubmit force un geste humain.

Mon conseil : commence avec un cadre simple.

  • Tools read‑only : recherche, filtres, lecture de données.
  • Tools write : derrière confirmation explicite.

Limitations actuelles (à assumer dans l’article)

WebMCP est encore tôt. Et ça se voit dans les contraintes.

  • Onglet requis : les tools vivent dans un top‑level browsing context.
  • Discoverability : pas de “catalogue” natif de tools par site.
  • Évolution rapide : c’est un draft de Community Group, donc ça bouge.

Prends-le comme un signal : la direction est claire, l’API va se stabiliser. Mais on est encore dans la phase où il faut prototyper, pas refondre ton SI.

Comment tester aujourd’hui (février 2026)

1) Accéder à l’early preview

WebMCP est proposé dans le cadre du Chrome Early Preview Program (EPP). L’objectif est de prototyper, donner du feedback, et itérer vite.

2) Utiliser Chrome Canary + flag

L’outillage autour de WebMCP mentionne Chrome 146+ avec le flag :

  • chrome://flags → WebMCP for testing

3) Inspecter les tools avec “Model Context Tool Inspector”

Une extension permet de lister les tools exposés par la page, et d’en exécuter. C’est parfait pour valider ton schéma, ton naming, et ton payload.

Stratégie d’adoption (simple, réaliste)

Si tu veux en parler “comme un dev du terrain”, voici une approche en 3 étapes.

Étape 1 — Commence par les formulaires

Cherche tes 3 forms les plus fréquents :

  • search,
  • contact/support,
  • checkout / réservation,
  • filtres avancés.

Ajoute toolname + tooldescription. Puis améliore la qualité des labels et des descriptions.

Étape 2 — Ajoute 1 ou 2 tools impératifs à fort ROI

Exemples typiques :

  • search_products qui renvoie du JSON propre,
  • create_support_ticket qui pré-remplit les infos techniques.

Ton objectif : remplacer 20 actions UI par 1 call.

Étape 3 — Ajoute des garde‑fous

  • readOnlyHint quand c’est lecture.
  • Confirmation (human‑in‑the‑loop) quand c’est écriture.
  • Logs et observabilité : tu veux pouvoir reproduire “ce que l’agent a fait”.

FAQ

« Est-ce que ça remplace l’accessibilité ? »

Non. Mais ça peut aider certains parcours (conversational UI), surtout quand l’accessibility tree d’un site est pauvre. Le combo gagnant reste : accessibilité solide + tools clairs.

« Est-ce que je dois ajouter WebMCP partout ? »

Non. Commence par les flows critiques et répétitifs. Le reste viendra si le trafic “agent” devient un vrai sujet.

« Est-ce que ça marche sur tous les navigateurs ? »

Pas aujourd’hui. Mais Google et Microsoft co‑portent le sujet côté standardisation. Ça vaut le coup d’être early adopter sur un petit périmètre.

Conclusion

WebMCP n’est pas “juste un truc d’IA de plus”. C’est une tentative de rendre le web plus accessible aux agents sans casser le web humain.

Si tu as déjà de bons formulaires et une UI bien structurée, tu pars avec un avantage. Et si tu veux aller plus loin, l’API impérative te permet d’exposer des actions robustes, versionnées, testables.

Liens utiles

Tags

  • MCP

  • agentic web

  • tools

  • Model Context Protocol

  • chrome

  • WebMCP

Cet article à été posté le

Commentaires

Chargement...