Imaginez le visiteur pour qui votre formulaire de contact a été conçu. Une personne, une souris, deux minutes de patience. Des libellés qu’elle peut lire, un astérisque rouge qu’elle comprend, une case qu’elle sait cocher.
Imaginez maintenant un autre visiteur. Quelqu’un demande à son assistant IA de « réserver une démo avec ce fournisseur », et l’assistant ouvre votre page et tente de déchiffrer votre formulaire. Il ne voit pas votre design. Il lit le balisage et devine. Est-ce que « Entreprise » désigne le nom de l’entreprise ou sa taille? Ce champ vide en bas est-il une vraie question ou un piège à pourriels? Appuyer sur Entrée envoie-t-il le formulaire?
C’est en devinant qu’on perd des prospects. WebMCP met fin aux devinettes.
Points clés
- WebMCP est une norme web proposée qui permet à une page d’indiquer à un agent IA les actions qu’elle offre et comment les utiliser, plutôt que de laisser l’agent extraire le contenu de la page. arvindkumar.ca
- Les formulaires sont le plus simple point de départ : quelques attributs transforment un formulaire existant en outil qu’un agent peut appeler. arvindkumar.ca
- Réglez d’abord la tuyauterie : une file de livraison vers le CRM garantit qu’aucun prospect ne se perd, que le formulaire soit rempli par une personne ou par un agent. arvindkumar.ca
- Ce sont les détails qui font que ça fonctionne : décrivez chaque champ, dites aux agents de ne pas toucher au piège à pourriels, et laissez la personne appuyer sur Envoyer. arvindkumar.ca
- La norme n’est encore qu’une ébauche; construisez donc votre solution de façon à ne rien changer pour les gens quand aucun agent n’est présent. arvindkumar.ca
Written by a person, formatted for answer engines.
Ce qu’est vraiment WebMCP
MCP, le Model Context Protocol, est la façon dont les applications d’IA se connectent à des outils : un serveur dit « voici ce que je peux faire, et voici ce dont chaque action a besoin », et le modèle l’appelle. WebMCP applique la même idée à une page web ordinaire. La page déclare ses propres outils, et un agent qui travaille dans le navigateur au nom de quelqu’un peut les appeler directement plutôt que de cliquer un peu partout.
Il y a deux façons de s’y prendre. La façon impérative passe par JavaScript : la page enregistre des outils, chacun avec un nom, une description, un schéma d’entrée et une fonction à exécuter. La façon déclarative passe par du HTML ordinaire : vous ajoutez quelques attributs à un formulaire que vous avez déjà.
C’est tout récent. WebMCP est en cours de développement au sein du W3C Web Machine Learning Community Group, avec des éditeurs de Google et de Microsoft, et c’est une ébauche, pas une norme finalisée. Chrome le met à l’essai, et l’ébauche a déjà changé de forme une fois : le point d’entrée JavaScript est passé de navigator.modelContext à document.modelContext. Si vous bâtissez dessus, prévoyez de suivre les changements.
Pourquoi commencer par les formulaires
Sur un site B2B, les formulaires sont l’endroit où le site se transforme en revenus. Avant d’ajouter quoi que ce soit pour les agents, assurez-vous que la tuyauterie est solide : affichez les formulaires du CRM avec le design du site et conservez chaque soumission dans une file de livraison jusqu’à ce que le CRM la confirme, en réessayant au besoin. Ainsi, aucun prospect ne se perd entre le formulaire et le CRM.
L’étape suivante devient évidente. Si des agents vont remplir des formulaires pour des gens, les formulaires qui ne perdent jamais un prospect devraient aussi être ceux qu’un agent ne peut pas mal comprendre. C’est à ça que sert WebMCP.
À quoi ça ressemble
La version déclarative est assez courte pour être montrée. Voici le formulaire de contact de ce site, réduit à l’essentiel :
<form toolname="contact_arvind"
tooldescription="Write a message to Arvind Kumar from the contact form
on this page. You fill in the fields; the person using the page
reviews them, ticks the consent box and presses Send. Nothing is
sent without them. Messages are answered by email.">
<input name="ak_email" type="email" required
toolparamdescription="The sender's email address. The reply goes here.">
<textarea name="ak_message" required
toolparamdescription="What the sender would like Arvind Kumar to know
or help with, in their own words."></textarea>
<input name="ak_consent" type="checkbox" required
toolparamdescription="Consent to be contacted back. Leave this for the
person to tick themselves.">
<input name="ak_trap" type="text" tabindex="-1"
toolparamdescription="Spam trap. Always leave empty.">
<button type="submit">Send</button>
</form>Trois attributs font le travail. toolname donne au formulaire un nom qu’un agent peut appeler. tooldescription explique ce que fait le formulaire et ce qui se passe ensuite. toolparamdescription explique chaque champ en une phrase, ce que la plupart des gens sautent, alors que c’est ce qui compte le plus.
Le AI Scanner de ce site illustre l’autre approche : quand le navigateur le permet, le scanner enregistre ses outils depuis JavaScript, de sorte qu’un agent peut lui demander de vérifier une page comme le ferait une personne.
Les détails qui déterminent si ça fonctionne
En le construisant, j’ai appris trois choses que vous ne trouverez dans aucun guide de démarrage rapide.
Dites à l’agent ce qu’il doit laisser tranquille
La plupart des formulaires contiennent un honeypot : un champ caché que les gens ne voient jamais et que les robots remplissent, ce qui permet au serveur de jeter le pourriel. Si vous donnez à ce champ un nom innocent comme « website », vous tendez un piège au mauvais visiteur. Un agent serviable lit le balisage, voit un champ qui demande un site web, le remplit, et le formulaire rejette une vraie demande en la prenant pour du pourriel. Sur ce site, le piège s’appelle ak_trap, porte l’étiquette « Leave this empty » et est décrit aux agents pour ce qu’il est vraiment.
Laissez la personne appuyer sur Envoyer
Il existe un attribut, toolautosubmit, qui permet à un agent de soumettre un formulaire de lui-même. Je ne l’active pas. L’agent remplit les champs; la personne les relit, coche la case de consentement et appuie sur Envoyer. Le consentement est le seul champ que je décris aux agents comme étant à laisser tranquille.
Ne faites jamais payer les gens pour ça
Rien de tout ça ne change le formulaire pour une personne qui utilise une souris. Les navigateurs qui ne connaissent pas WebMCP ignorent les attributs. Le formulaire a la même apparence, fonctionne de la même façon et aboutit au même endroit. C’est la règle que je donnerais à quiconque adopte une norme encore à l’état d’ébauche : l’ajouter de manière invisible quand personne ne s’en sert.
WebMCP et MCP, ce sont deux rôles différents
Les gens confondent les deux, alors ça mérite un paragraphe. WebMCP, c’est la porte d’entrée : il s’adresse aux agents qui visitent le site web au nom d’un visiteur. Un serveur MCP de site web, c’est l’autre porte : il permet aux agents internes d’un site de travailler sur celui-ci au moyen d’opérations vérifiées plutôt que de modifications brutes. L’un s’adresse aux gens qu’on veut joindre. L’autre, à l’équipe qui gère le site.
Pourquoi s’en soucier avant l’arrivée des agents
Bonne question. Les agents qui utilisent WebMCP commencent à peine à se manifester, et la norme va continuer d’évoluer.
Mais le coût est minime, et le moment est justement ce qui compte. Chaque virage dans la recherche a récompensé les sites qui étaient prêts tôt : un balisage propre avant que les robots d’exploration deviennent exigeants, des données structurées avant les résultats enrichis. Des agents qui remplissent des formulaires pour les gens, c’est la prochaine version de la même histoire. Quand ils arriveront en grand nombre, vous voudrez que vos formulaires soient les plus faciles du web à remplir correctement.
Ce site l’a aussi. Demandez à un agent de me contacter à partir de la page Contact : il trouvera un outil appelé contact_arvind, le remplira et vous laissera la dernière étape.