WebMCP expliqué : permettre aux sites web de publier des outils au lieu que des agents cliquent sur des interfaces utilisateur.

Imaginez un petit projet secondaire dans lequel un agent IA doit gérer une application web seul. La première version fonctionne comme la plupart des agents navigateur : l’agent obtient un accès à l’application et agit en fonction de ce que montre la page. Pour une application de tâches basique, la demande pourrait être « Ajouter ‘Acheter des œufs’ à ma liste ». Pour la mettre en œuvre, l’agent doit examiner la page, trouver la case de saisie, déterminer quel bouton soumet le formulaire, effectuer le clic, puis vérifier le résultat.

Cela fonctionne, mais cela semble nécessiter beaucoup trop d’efforts. L’application sait déjà précisément ce qui doit se passer. Une fonction se trouve derrière ce bouton, une API se trouve derrière cette fonction, et l’opération elle-même consiste en une seule appelation claire :

add_todo(title)

Alors pourquoi l’agent devrait-il fixer l’interface et essayer de deviner comment faire quelque chose que l’application peut déjà décrire ? C’est là que WebMCP commence à prendre du sens. Le flux devient alors quelque chose comme ceci :

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

L’interface reste présente pour les visiteurs humains. L’agent n’a simplement pas besoin de la déchiffrer pour effectuer une action. Cela change la manière de concevoir le problème dans son ensemble. La question n’est peut-être pas de savoir comment améliorer la capacité de l’IA à utiliser les sites web, mais plutôt comment améliorer les sites web pour leur permettre d’indiquer à l’IA ce qu’ils peuvent faire.

Deux manières dont les agents utilisent le web aujourd’hui, et leurs limites respectives

Un agent qui doit agir sur un site dispose actuellement de deux approches courantes.

La première est l’automatisation du navigateur. L’agent prend des captures d’écran, détermine ce qui est cliquable, déplace le curseur, remplit un champ, clique, vérifie ce qui s’est passé, et itère. Cela ressemble à observer quelqu’un utiliser un navigateur, et présente les mêmes faiblesses : c’est lent, cela consomme beaucoup de tokens, et cela tombe facilement en panne. Un petit changement de mise en page, un menu caché, une interaction réservée au survol, ou un flux avec une étape supplémentaire peuvent faire dérailler l’agent.

La deuxième approche consiste en un serveur MCP personnalisé conçu pour votre application. Pour les outils, c’est une expérience bien meilleure. Le coût se fait sentir ailleurs, car l’agent doit d’abord savoir que le serveur existe et se connecter à lui. Lorsque chaque site web intègre sa propre solution sur mesure, cela ne permet pas une expansion efficace. C’est là la limite pratique de l’approche MCP personnalisé.

Cela crée un vide : l’automatisation des navigateurs est trop indirecte, tandis que les intégrations personnalisées sont trop manuelles. WebMCP vise justement cet espace intermédiaire.

Qu’est-ce que WebMCP, en réalité ?

En termes simples, WebMCP permet à un site web d’annoncer à un agent IA : « Voici les actions que vous pouvez effectuer sur cette page. » Au lieu que l’agent se demande quel bouton appuyer, le site lui fournit une liste d’actions possibles.

Un magasin en ligne, par exemple, pourrait publier des outils de ce type :

search_products()
get_product_details()
add_to_cart()

Un agent qui parcourt le site découvre les outils par lui-même et les invoque en utilisant les données structurées indiquées par chacun d’eux. Aucune inscription préalable n’est nécessaire au sein de l’agent. Les outils sont découverts dynamiquement depuis le site web, et c’est là l’aspect à retenir. Un site cesse alors d’être simplement un ensemble de pages pour commencer à offrir des fonctionnalités.

Un exemple concret : l’application Todo

Prenons une application Todo simple. Sans WebMCP, un agent devrait examiner la page, trouver le champ de saisie, y entrer du texte, localiser le bouton Ajouter, le cliquer, puis relire l’interface mise à jour.

Avec WebMCP, l’application peut publier quatre outils :

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

L’agent n’a plus besoin de connaître la mise en page visuelle. Il sait ce que l’application peut faire. Une démonstration réalisée exactement de cette manière a montré une application Todo qui exposait quatre outils, avec un agent connecté qui lisait leurs schémas et appelait immédiatement add_todo. En demandant à l’agent d’ajouter « Je dois acheter des œufs » à la liste, l’appel à l’outil était déclenché, et le nouvel élément apparaissait dans l’application.

Le modèle mental est beaucoup plus clair : l’interface utilisateur est destinée aux humains, les outils aux agents, et tous deux fonctionnent sur la même application.

À quoi ressemble une définition d’outil

Les ingénieurs frontend y trouveront matière à intérêt. L’implémentation dans cette démonstration enregistre les outils via navigator.modelContext. Chaque outil comprend quelques composants :

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

La structure reste constante : un nom, une description, un schéma d’entrée, ainsi qu’une fonction d’exécution qui effectue le travail, généralement en appelant des API backend déjà disponibles dans l’application. Ce dernier point est important. WebMCP ne vous demande pas de réécrire la logique métier pour l’IA. L’application existante reste le système qui exécute l’opération, et l’agent se contente d’obtenir un moyen structuré pour la déclencher.

Le problème de l’authentification

Les choses deviennent sérieuses dès que l’application n’est plus un simple outil de démonstration. Imaginez des outils de ce type :

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

Un agent inconnu ne devrait pas pouvoir invoquer ces fonctionnalités librement. Une deuxième démonstration utilisant le même matériel aborde précisément ce problème grâce à OAuth. Les outils WebMCP fonctionnent au-dessus d’une application authentifiée, et les utilisateurs qui ne se sont pas connectés ne peuvent pas exécuter les actions protégées.

Cela est important car les agents proviennent de nombreux types de clients : un navigateur doté d’IA, un agent de bureau ou une autre application agente. Un mécanisme standard comme OAuth rend la couche de fonctionnalités bien plus facile à protéger pour tous ces clients, par rapport à la création d’un flux de connexion pour chaque intégration. Une fois que les sites exposent leurs fonctionnalités aux agents, l’authentification fait partie de l’expérience de l’agent dès le premier jour, et non d’un correctif ajouté ultérieurement.

Une nouvelle question pour la conception frontend

Pendant des années, l’architecture frontend a tourné autour d’une seule chaîne : interface, état, API, backend. WebMCP ajoute une nouvelle question à se poser : quelles fonctionnalités cette application doit-elle exposer à un agent ?

Cela semble anodin, mais cela pourrait changer la manière dont les fonctionnalités sont conçues. Un bouton « Ajouter au panier » est une interaction humaine. Cette requête, en revanche, représente une capacité de l’application :

add_to_cart(productId, quantity)

Les deux pourraient finalement être conçus ensemble. Les utilisateurs bénéficient d’une interface soignée, les agents disposent d’une interface de capacités structurée, et tous deux relèvent de la même logique métier.

Il ne s’agit pas seulement de vitesse

Il existe une raison plus profonde pour laquelle cela est important que la simple rapidité des agents. Lorsqu’un agent fonctionne à l’aide d’captures d’écran et de clics, l’interface elle-même constitue le contrat, et toute modification de cette interface peut le rendre inopérant. Avec WebMCP, la définition des outils fait partie intégrante de ce contrat.

Cela amène un nouveau ensemble de considérations dans le champ d’action du développeur frontend : noms des outils, descriptions, schémas d’entrée, comportement d’exécution et limites d’authentification. Le travail cesse d’être uniquement axé sur la conception des écrans. Il inclut désormais la conception de la manière dont le logiciel se présente aux systèmes intelligents.

C’est encore très précoce

Une mise en garde mérite d’être soulignée. WebMCP reste une proposition en phase de bêta et non un standard web définitif. La démonstration a été effectuée dans Chrome Beta avec WebMCP activé via des paramètres du navigateur, et le présentateur a clairement indiqué que l’API pouvait encore changer. Il serait prématuré de reconstruire une architecture de production autour de celle-ci pour l’instant. En revanche, l’expérimenter est une autre affaire, car l’idée sous-jacente est plus vaste que l’API actuelle.

Pendant des décennies, les sites web ont été conçus sur une seule hypothèse : il y a une personne de l’autre côté. WebMCP fait partie des premiers essais à remettre cela en question. Les applications web devront bientôt répondre à deux questions : comment une personne doit-elle l’utiliser ? Et comment un agent IA doit-il l’utiliser ? La première question a donné naissance à l’ingénierie frontend moderne. La seconde pourrait bien déterminer ce qui viendra ensuite.