Avec WebMCP, la question la plus immédiate est souvent : quels tools un site devrait-il exposer aux agents ?
C’est probablement la mauvaise question pour commencer.
WebMCP permet à une application web d’exposer des fonctions structurées à des agents IA. Un site peut ainsi déclarer explicitement des actions comme rechercher un produit, remplir un formulaire ou gérer un état, au lieu de laisser l’agent reproduire des clics et des saisies à partir de l’interface.
Le risque est alors de partir de ce que le site possède déjà : ses pages, ses formulaires, ses composants ou ses APIs, puis de chercher à les transformer en tools.
On obtient facilement quelque chose comme :
openSearchPage()
submitSearchForm()
openProductPage()
clickAddToCart()
Le site devient plus facile à piloter par un agent, mais son modèle d’interaction reste celui qui avait été conçu pour un humain.
Or un agent n’a pas nécessairement besoin de suivre ce parcours.
Partir du résultat attendu
La documentation de Chrome sur la conception de tools WebMCP propose de commencer par le but de l’utilisateur : quel résultat cherche-t-il à obtenir, quelles informations sont nécessaires et quelles actions doivent être réalisées pour y parvenir ?
Ce déplacement paraît simple, mais il change l’unité de conception.
Prenons un site e-commerce.
Le parcours observable peut être :
catalogue → filtres → fiche produit → choix d'une variante → stock
Mais ce parcours ne décrit pas nécessairement l’intention de l’utilisateur.
L’intention peut être simplement : « savoir si ce produit est disponible dans ma taille. »
Dans ce cas, les pages traversées sont une propriété de l’interface actuelle. Elles ne sont pas le besoin.
C’est ici que la notion de critical user journey devient utile. Dans les travaux de Google SRE (Site Reliability Engineering), un CUJ Critical User Journey) désigne un ensemble de tâches importantes permettant à un utilisateur d’atteindre un objectif central du service. Le point important est l’objectif, pas la séquence exacte d’écrans utilisée pour l’atteindre.
Pour WebMCP, la bonne unité de départ pourrait donc être l’intention critique plutôt que la page ou l’API.
Mais les intentions ne sont pas directement observables
Le problème devient alors plus difficile.
Un site dispose de nombreux signaux sur ses utilisateurs, mais aucun ne révèle directement ses intentions critiques :
- Les analytics indiquent ce que les utilisateurs ont fait.
- Les funnels montrent les séquences fréquentes et les abandons.
- Les requêtes saisies dans un moteur de recherche interne donnent une formulation de certains besoins.
- Les tickets support révèlent des problèmes que le site n’a pas correctement résolus.
- L’interface et les APIs indiquent enfin ce que le produit est techniquement capable de faire.
Ces sources décrivent des objets différents.
Une visite sur /orders/123, une recherche « où est mon colis ? », un clic sur « suivre la livraison » et un ticket concernant une commande en retard peuvent pourtant être plusieurs manifestations d’une même intention : connaître l’état d’une commande et sa date probable d’arrivée.
Identifier les CUJ revient donc moins à lire un funnel qu’à reconstruire des intentions à partir de signaux incomplets.
Du parcours critique à la capability
Même une fois l’intention trouvée, il reste une seconde question.
Tout ce qui compose un parcours n’a pas besoin de devenir un tool.
Un agent peut comparer lui-même deux produits si le site lui fournit leurs caractéristiques. En revanche, il ne peut pas deviner un stock en temps réel ou modifier un panier sans accéder à une capacité détenue par le site.
La chaîne de raisonnement devient alors :
intention utilisateur
→ critical user journey
→ informations et actions nécessaires
→ capabilities détenues par le site
→ tools WebMCP
Cette séquence évite de considérer chaque interaction actuelle comme une capability à exposer.
Le problème à résoudre avant de construire les tools
Le premier enjeu de WebMCP n’est donc peut-être pas technique.
Il consiste à déterminer quelles intentions méritent d’être rendues accessibles aux agents, puis à comprendre quelles capacités du site sont réellement nécessaires pour les accomplir.
Cela suppose de combiner plusieurs types de signaux : ce que les utilisateurs déclarent vouloir, ce qu’ils font réellement et ce que le site permet techniquement.
La méthode précise reste à construire.
Mais elle devrait répondre à une question plus étroite que « quels tools créer ? » :
Comment reconstruire les intentions critiques d’un site, puis trouver le plus petit ensemble de capacités permettant à un agent de les satisfaire ?
C’est seulement après cette étape que le design des tools WebMCP commence vraiment.