Les agents IA utiliseront votre site ou le contourneront. WebMCP mise sur la première option.

Un agent IA qui réserve, commande ou remplit un formulaire pour quelqu'un a aujourd'hui deux façons de joindre une entreprise. Il peut piloter le site comme le ferait une personne, en lisant la page et en simulant des clics, ou sauter le site et parler directement à une intégration côté serveur. Le chemin qu'il emprunte détermine si votre site web fait même partie de la transaction. WebMCP est une proposition de norme web pour une troisième voie : le site déclare ce qu'il sait faire, dans un format que l'agent lit directement, et le travail se fait dans la page que l'utilisateur a déjà ouverte. Cette note couvre le patron, la partie sur laquelle vous pouvez agir dès maintenant, le coût dont presque personne ne parle, et pourquoi un petit pilote jetable vaut mieux qu'un pari de plateforme.

Vous utiliser, ou vous contourner.

La phrase stratégique se trouve dans la liste d'objectifs de l'explainer, pas dans un texte de lancement. Un objectif se lit, mot pour mot : « Prevent disintermediation of web apps by backend integrations by adapting front-ends for use by agents, rather than replacing them. » (en anglais dans l'original), c'est-à-dire : empêcher que des intégrations côté serveur court-circuitent les applications web, en adaptant les interfaces frontales à l'usage des agents plutôt qu'en les remplaçant.[1] La désintermédiation, c'est l'enjeu d'affaires. Les agents qui appellent les serveurs d'un service par une intégration côté serveur, comme le Model Context Protocol ou un connecteur OpenAPI, passent tout droit à côté du site web. L'explainer énumère ce que ça coûte : l'interface web est contournée et son contexte perdu, la session et la connexion de l'utilisateur doivent être reconstruites sur un serveur distinct, et l'entreprise doit écrire et exploiter ce serveur au lieu de réutiliser le code que ses pages exécutent déjà.

Traduisez ça pour une entreprise qui a une page de réservation. Quand l'agent passe à côté du site, votre page d'offre, votre écran de confirmation, votre option additionnelle et votre marque ne font plus partie de la transaction. L'agent et le serveur règlent ça entre eux. Le pari de WebMCP, c'est que l'interface web peut rester dans la boucle si elle devient quelque chose qu'un agent sait bien utiliser. Les outils s'exécutent dans l'onglet du navigateur de l'utilisateur, avec sa session et sa connexion déjà en place, et la page se met à jour là où l'utilisateur peut la voir.

Ce qu'est réellement WebMCP.

WebMCP est une API de navigateur proposée, rédigée dans un groupe communautaire du W3C et en essai d'origine dans Chrome, qui permet à une page web d'enregistrer des outils qu'un agent IA peut appeler, plutôt que de piloter la page par des clics simulés. Une page appelle document.modelContext.registerTool() avec un nom, une description en langage courant, un schéma JSON pour les entrées et une fonction de rappel (callback) execute. Un agent qui travaille dans le navigateur demande au navigateur quels outils la page a enregistrés, en choisit un et l'appelle avec des arguments structurés. La fonction de rappel exécute le code de la page elle-même. Il existe aussi une voie déclarative qui annote les formulaires HTML existants, sans JavaScript, pour les cas simples.[1][2]

Trois choses que ce n'est pas, selon les non-objectifs de la proposition elle-même. Ce n'est pas un remplaçant de MCP. Il emprunte le vocabulaire de MCP (outils, schémas, paramètres), mais n'a délibérément pas adopté la spécification, parce que MCP a été conçu pour la communication entre serveur et client et entre processus, et qu'il ne connaît ni les origines, ni les permissions du navigateur, ni le DOM, ni le cycle de vie des onglets. Ce n'est pas un remplaçant de l'interface humaine, qui demeure prioritaire. Et ce n'est pas destiné à des agents pleinement autonomes qui roulent sans aucun navigateur. C'est aussi encadré : ça ne s'exécute que dans des documents à isolation d'origine, et derrière une politique de permissions tools dont la valeur par défaut est l'origine de la page, de sorte qu'un iframe tiers a besoin d'une permission explicite.[2]

Un outil, c'est quatre choses.

C'est la partie sur laquelle un gestionnaire peut agir dès aujourd'hui. Un outil, c'est un nom, une description, un schéma JSON et une fonction de rappel qui exécute du code que votre propre interface appelle déjà. Cette dernière partie est ce qui garde le coût bas. Si votre formulaire de soumission valide déjà ses champs et envoie du JSON par POST à un point de terminaison, un outil enveloppe cet appel. Vous n'écrivez pas un deuxième chemin de code : vous donnez à celui que vous avez une étiquette qu'un agent peut lire.

// Les navigateurs sans WebMCP sautent ce bloc en entier.
if ("modelContext" in document) {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: "demarrer-demande-de-soumission",
    description:
      "Remplit le formulaire de demande de soumission pour un service que l'utilisateur nomme. " +
      "L'utilisateur le révise et appuie sur Envoyer.",
    inputSchema: {
      type: "object",
      properties: {
        service: {
          type: "string",
          enum: ["audit de flux de travail", "mise en place d'un agent", "entente de soutien"],
          description: "Le service dont l'utilisateur veut connaître le prix."
        },
        details: { type: "string", description: "Le mandat, dans les mots de l'utilisateur." },
        email: { type: "string", description: "L'adresse courriel où envoyer la réponse." }
      },
      required: ["service", "email"]
    },
    async execute(input) {
      // Les validations strictes vivent ici, pas dans le schéma : retournez une erreur que l'agent peut corriger.
      const problem = validateQuote(input);   // le validateur du formulaire
      if (problem) return { content: [{ type: "text", text: problem }] };

      fillQuoteForm(input);                   // la logique de remplissage du formulaire
      return { content: [{ type: "text", text: "Formulaire rempli. L'utilisateur le révisera et l'enverra." }] };
    }
  }, { signal: tools.signal });
}

La plupart des décisions de conception de cet extrait viennent directement de la section des bonnes pratiques de l'explainer.[1] Le nom emploie un verbe précis : demarrer-demande-de-soumission remplit le formulaire et s'arrête, là où un envoyer-demande-de-soumission l'enverrait. La spécification fait exactement cette distinction entre faire une chose maintenant et démarrer le flux de travail. L'énumération (enum) emploie des mots qu'une personne dirait plutôt que des identifiants internes. Le schéma est souple et la fonction de rappel est stricte, parce que des échecs de schéma stricts peuvent faire caler un agent, alors qu'un message d'erreur clair lui permet de se corriger et de réessayer. Et le formulaire visible se remplit à l'écran, parce que l'agent et la personne partagent une seule session.

Nous avons choisi la version « remplir et s'arrêter » exprès. Une version avec envoi appellerait la même fonction d'envoi que votre formulaire appelle déjà, enverrait le même JSON au même point de terminaison, et serait tout aussi courte. Mais la façon dont un outil devrait demander une confirmation à l'utilisateur avant de l'engager fait partie des questions que la spécification liste comme ouvertes. Pour tout ce qui envoie, réserve ou facture, laissez donc le dernier bouton à l'humain jusqu'à ce que ce soit réglé. La vérification de fonctionnalité à la première ligne est ce qui fait de l'ensemble une amélioration progressive, le terme même de Chrome : un navigateur sans WebMCP voit un formulaire ordinaire.

Chaque outil dépense du contexte.

L'idée de cette proposition qui porte le plus loin n'est pas propre à WebMCP. Les bonnes pratiques de l'explainer le disent sans détour : le nom, la description et le schéma d'entrée de chaque outil enregistré « consumes tokens in the model prompt, adds to inference latency, and increases the potential for tool confusion or hallucination » (en anglais dans l'original), soit : consomment des jetons dans le prompt du modèle, ajoutent à la latence d'inférence et augmentent le risque de confusion entre outils ou d'hallucination. Puis l'avertissement : « Exposing too many tools (e.g., dozens or hundreds) can severely degrade agent performance or lead agent browsers to drop tools or fail to process them. » (en anglais dans l'original), soit : exposer trop d'outils (par exemple des dizaines ou des centaines) peut dégrader sévèrement la performance de l'agent ou amener les navigateurs d'agents à abandonner des outils ou à ne pas réussir à les traiter.[1] C'est une orientation donnée par les auteurs de la spécification, pas un seuil mesuré, et la spécification ne fixe aucune limite stricte. La direction ne fait toutefois pas de doute. Une liste d'outils est un budget de contexte, et il est dépensé avant que l'agent ait fait quoi que ce soit.

Le même calcul s'applique à chaque serveur MCP qu'on tente de vendre à une PME. À moins que l'assistant charge les outils à la demande, chaque serveur que vous branchez met toute sa liste d'outils dans le prompt, que la tâche en ait besoin ou non. Quand l'argument d'un fournisseur est que son serveur expose quatre-vingts outils, la réponse utile est de demander combien l'agent en a besoin pour la tâche qui est devant lui. Nous avons fait valoir le même point du côté du harnais dans la note sur l'ordre de construction : gardez des jeux d'outils minimaux qui ne se chevauchent pas, parce que si une personne ne sait pas lequel de deux outils utiliser, le modèle ne le saura pas non plus. La version de l'explainer est « single responsibility » (en anglais dans l'original), soit « responsabilité unique », avec un avertissement explicite contre les outils qui se chevauchent ou font double emploi. Et comme les jetons, c'est de l'argent, une liste d'outils gonflée apparaît dans la trace de coût par étape que nous avons décrite dans la note sur la métrique de coût bien avant que quiconque la remarque dans la qualité.

Ce que personne n'a mesuré.

Aucune des deux sources n'offre de preuve que ça fonctionne. La page de Chrome dit que WebMCP « can significantly improve the performance and reliability of agent actuation. » (en anglais dans l'original), soit : peut améliorer sensiblement la performance et la fiabilité de l'exécution d'actions par les agents.[2] C'est une affirmation non mesurée d'une organisation co-autrice, à propos de sa propre proposition. Aucun banc d'essai, jeu de données ou chiffre comparatif n'apparaît dans l'une ou l'autre source, et la seule chose offerte à l'appui est une démo côte à côte d'une prise de rendez-vous. L'amélioration est une hypothèse plausible. Elle pourrait fort bien s'avérer juste, et ça reste une hypothèse.

Ça ne peut pas faire en sorte qu'un agent vous trouve. La section Limitations de Chrome : « Clients and browsers must visit a site directly to know if it has callable tools. » (en anglais dans l'original), soit : les clients et les navigateurs doivent visiter un site directement pour savoir s'il offre des outils appelables.[2] Quoi que fasse WebMCP, ça agit sur un site où l'agent se trouve déjà. Ça ne fait rien pour que l'agent y arrive. L'explainer liste la découverte en arrière-plan par des service workers comme une question ouverte, et tant que quelque chose de semblable n'est pas livré, la découvrabilité ne change pas. Si quelqu'un vous vend WebMCP comme une façon de vous faire recommander par l'IA, il avance une affirmation que la documentation même de l'implémenteur contredit.

L'API n'est pas stabilisée. C'est un essai d'origine dans Chrome à partir de la version 149 et dans Edge à partir de la version 150, avec un indicateur Chrome pour les tests locaux, alors que les positions de Mozilla et de WebKit sur la norme étaient encore en suspens au moment de la rédaction.[1] L'explainer liste dix questions ouvertes, la plupart avec des liens vers les tickets, parmi lesquelles un schéma de sortie structurée, la façon dont un outil demande une confirmation à l'utilisateur, ce qui se passe quand l'envoi d'un formulaire par un outil mène à une nouvelle page, et les entrées et sorties multimodales. Tout ce qui est construit pendant l'essai doit présumer que ces éléments bougeront. Les deux sources divergent aussi sur l'usage sans interface (headless) : Chrome décrit l'API comme « primarily designed for local browser workflows with a human in the loop » (en anglais dans l'original), soit : conçue principalement pour des flux de travail locaux dans le navigateur avec un humain dans la boucle[2], alors que l'explainer liste la navigation sans interface comme un objectif. Si on lit les deux sources ensemble, la navigation sans interface avec un navigateur entre dans le périmètre, mais au second plan, et l'absence totale de navigateur en est exclue.

L'outillage est une extension, pas les DevTools. L'outil de test de Google est le Model Context Tool Inspector, une extension du Chrome Web Store. Il liste les outils enregistrés d'une page, vous permet de les appeler à la main, valide votre schéma et montre ce que votre outil retourne.[2] Certaines couvertures secondaires décrivent ça comme une prise en charge intégrée aux DevTools, et c'est faux. Un détail compte pour les entreprises québécoises : par défaut, le clavardage de l'inspecteur envoie vos prompts à un modèle Gemini hébergé. Testez donc avec des données inventées, jamais avec de vrais dossiers de clients.

Pour ce que ça vaut, quand nous avons évalué WebMCP pour nos propres sites, l'hypothèse de départ que nous avons notée était « probablement aucun gain mesurable sur un site vitrine ». Ce pilote n'a pas été mené. Un site où les gens accomplissent des tâches en plusieurs étapes, un parcours de réservation, un configurateur, un formulaire de demande de soutien avec embranchements, c'est là que l'hypothèse a de la place pour se manifester.

Si vous lancez un pilote, gardez-le jetable.

La bonne posture pour une API en essai d'origine dont les bénéfices ne sont pas mesurés, c'est un pilote qu'on peut supprimer en un seul commit. Cinq règles :

1. Choisissez une tâche que le site fait déjà bien.

   Une demande de soumission, une réservation, un filtre de produits : quelque chose qui a du code fonctionnel et un point de terminaison derrière. Pas un catalogue de tout ce que le site sait faire. Trois outils qui enveloppent du code existant valent mieux que trente qui exigent du nouveau code.

   à faire · un à trois outils, chacun enveloppant du code qui existe déjà
2. Détectez la fonctionnalité et gardez le tout dans un seul fichier.

   Les navigateurs sans WebMCP devraient voir exactement le site qu'ils voyaient hier. Si l'API change de forme pendant l'essai, et la spécification dit que certaines parties changeront, retirer le pilote devrait être un retour en arrière d'une seule ligne, pas un remaniement.

   à faire · isoler le code d'enregistrement pour que sa suppression soit triviale
3. Remplissez, n'envoyez pas, pour tout ce qui engage l'utilisateur.

   Tant que la spécification n'a pas réglé la façon dont un outil demande une confirmation, laissez l'agent préparer le formulaire et laissez la personne appuyer sur le bouton. Ça coûte un clic et ça élimine le pire mode d'échec.

   à faire · garder l'humain à la dernière étape de tout achat, réservation ou envoi
4. Écrivez la mesure de succès avant de livrer.

   Décidez ce qu'est une tâche réussie, comment vous la compterez et dans quel agent, puis mesurez d'abord la même tâche sans les outils. Sans point de référence, le seul résultat que vous obtiendrez, c'est que ça semble mieux.

   à faire · noter la mesure, le point de référence et la date où vous y mettrez fin
5. Testez seulement avec des données fictives.

   Le clavardage de l'inspecteur passe par un modèle hébergé par défaut. Sous la Loi 25 du Québec, ce n'est pas là qu'ont leur place le nom et le courriel d'un client, test ou pas.

   à faire · garder les renseignements personnels hors de toute session de test hébergée

Si vous vous demandez si votre site est un candidat WebMCP, le formulaire de contact est la voie la plus rapide. Dites-nous quelle tâche vos clients accomplissent sur le site et ce qui se trouve derrière le formulaire, et nous vous enverrons gratuitement un avis écrit sur la pertinence de mener un pilote.