← Actualités

Actualités · 49

Le site web devient une prise : WebMCP demande ce qu'elle sait faire

Hier, un robot lisait vos pages pour les indexer. Demain, il appellera directement vos fonctions, et si elles ne sont pas déclarées, il ne devinera pas.

Pendant vingt ans, un site web a été un document : des pages à lire, à indexer, à cliquer. WebMCP propose autre chose. La page y déclare des outils qu'un agent peut appeler : calculer un devis, vérifier une disponibilité, ajouter un article au panier. Le site n'est plus une brochure. Il ressemble à une prise, et l'agent veut savoir ce qu'on peut y brancher.

Ce n'est plus de la science-fiction de laboratoire, sans être un standard pour autant. Le W3C a publié fin septembre 2026 un Draft Community Group Report, le stade le plus précoce d'une spécification, et Chrome documente déjà l'API, un panneau DevTools de débogage et un audit Lighthouse dédié. Les outils arrivent avant la norme, et c'est souvent là que les habitudes se prennent.

Le site web devient une prise : WebMCP demande ce qu'elle sait faire — illustration 2

Chrome a ouvert la boîte à outils en juin, le W3C a suivi en septembre

Le principe tient en une phrase : une page devient un serveur MCP (Model Context Protocol) qui tourne dans le navigateur de l'internaute. Au lieu de fouiller le DOM en espérant comprendre à quoi sert un bouton, l'agent reçoit une liste d'outils. Chacun a un nom, une description en langage naturel et un schéma JSON des paramètres attendus. Il appelle ensuite l'outil qui l'intéresse. Le navigateur sert d'intermédiaire, et l'utilisateur garde la main sur ce que l'agent fait en son nom.

Un bouton sans nom n'existe pas pour un agent

C'est le premier effet, et il ne coûte pas un euro de licence : l'agent s'appuie sur l'arbre d'accessibilité. Un bouton sans nom programmatique est invisible pour lui, exactement comme pour une personne qui utilise un lecteur d'écran. Les équipes qui traitaient l'accessibilité comme une case à cocher en fin de projet découvrent qu'elle devient un critère de fonctionnement. La stabilité visuelle suit la même pente : une interface qui bouge pendant le chargement fait échouer un agent comme elle agace un humain.

Un agent qui ne trouve aucune fonction à appeler n'insiste pas : il passe au site suivant.

Ces outils ne remplacent pas l'interface, ils s'ajoutent à elle. Le même parcours doit tenir pour quelqu'un qui clique et pour un agent qui appelle. C'est un chantier d'une tout autre ampleur que d'ajouter un chatbot dans un coin de page.

Une démo de pizza ne prouve rien

Premier malentendu : ranger WebMCP au rayon référencement. Le SEO répond à « comment être trouvé ». Ici, la question est « comment être utilisé sans qu'on lise mes pages ». Les métiers diffèrent, et les preuves aussi.

Second piège : se fier aux démonstrations. Un configurateur de pizza qui commande tout seul, c'est joli. Ça ne dit rien d'un parcours de réservation un lundi matin, avec un stock épuisé, un code promo refusé et un agent qui doit décider s'il a le droit de payer. C'est là que se jouera la qualité : des fonctions bien décrites, des erreurs gérées, des permissions cadrées.

Les sites qui vendent quelque chose passent devant les vitrines

Prenons position. Réservation, e-commerce et devis ont de l'avance : leur activité est déjà faite d'actions que l'on peut nommer. Les vitrines qui se contentent d'un formulaire de contact n'ont rien à déclarer, donc rien à offrir à un agent, et c'est à elles que la prise sert le moins. Le risque inverse existe aussi : un site qui laisse l'agent trancher à sa place peut voir sa marque se dissoudre dans un comparateur automatique.

Le site web devient une prise : WebMCP demande ce qu'elle sait faire — illustration 3

Reste l'objection sérieuse : un équivalent propriétaire, poussé par une grande plateforme, pourrait doubler le standard ouvert. Le web a déjà vu ce film. Attendre le vainqueur serait pourtant la mauvaise réponse, car des fonctions bien décrites se transposent d'un format à l'autre.

Reste une question : qui fixera la forme de la prise ?

Pour un studio ou une PME, le premier geste est modeste : lister ce que le site sait faire, nommer correctement ses boutons, décrire ses formulaires. Cela se facture comme une passe d'audit, pas comme un virage stratégique.

Le dossier est mince, il faut le dire. Les sources disponibles ne citent ni site en production ni chiffre d'adoption, et on ne sait pas si les agents tiendront leurs promesses. On ne sait pas davantage si WebMCP sera la norme ou un épisode. Mais la question « que peut faire mon site pour un agent ? » se pose déjà, et elle arrive avant celle du design.

Partager