---
title: "WebMCP ne remplace pas le scraping. Il remplace le clic au hasard"
locale: "fr"
url: "https://irz.fr/fr/articles/webmcp-declared-tools-not-scraping-fr"
markdown_url: "https://irz.fr/fr/articles/webmcp-declared-tools-not-scraping-fr.md"
category: "ai"
tags: ["WebMCP", "MCP", "agents", "navigateur", "Cloudflare", "Chrome", "web"]
published_at: "2026-08-21T15:47:00.000Z"
author: "Arthur Lacoste"
translation: "https://irz.fr/en/articles/webmcp-declared-tools-not-scraping-en.md"
---

# WebMCP ne remplace pas le scraping. Il remplace le clic au hasard

WebMCP permet à un site de déclarer des actions directement aux agents. C’est une alternative au pilotage fragile du DOM, pas la fin du scraping ni des API.

Le scraping n’est pas en train de mourir. Le bouton que l’agent cherche pendant vingt secondes dans une capture d’écran, lui, a peut-être un problème.

Le 6 août 2026, Cloudflare a annoncé une preview permettant d’ajouter une interface WebMCP à un domaine depuis son dashboard, sans toucher au code servi par l’origine.[1](https://blog.cloudflare.com/webmcp/) La promesse est suffisamment jolie pour être résumée brutalement : au lieu de laisser un agent lire une page comme un humain myope, retrouver le bon champ, cliquer sur un bouton et espérer que le DOM n’ait pas changé depuis hier, le site lui déclare directement des outils.

`search_products`. `create_ticket`. `book_flight`. Une description, un schéma d’entrée, une fonction à exécuter.

C’est une vraie rupture dans la façon de piloter une interface web. Ce n’est pourtant pas la fin du scraping, et c’est précisément cette nuance qui rend WebMCP plus intéressant que le slogan.

## Le faux remplacement

Aujourd’hui, lorsqu’un agent doit agir sur un site qui n’a pas d’API pensée pour lui, il dispose de plusieurs techniques plus ou moins glorieuses. Il peut lire le DOM, utiliser l’arbre d’accessibilité, analyser une capture d’écran, chercher du texte visible, calculer où cliquer, remplir un formulaire et regarder ce qui change ensuite.

Cette automatisation marche étonnamment souvent. Elle a aussi les qualités d’un robot qui ouvrirait votre porte en reconnaissant la poignée à la forme des pixels.

Une classe CSS change, un bouton déménage, une modale apparaît, le site charge une étape asynchrone et toute la procédure doit être réinterprétée. Les modèles visuels limitent une partie de la casse, mais ils paient cette souplesse en tokens, en latence et en ambiguïté. Chrome présente WebMCP exactement comme une réponse à cette situation : plutôt que laisser l’agent deviner le rôle d’un bouton ou d’un input, l’application peut déclarer ce qu’ils permettent réellement de faire.[3](https://developer.chrome.com/blog/ai-webmcp-origin-trial)

Le mot important est **agir**.

WebMCP ne dit pas qu’un agent cessera de lire le web. La spec elle-même décrit les « observations » que le navigateur peut fournir à son agent et cite, en plus de la liste des tools, des captures annotées, des morceaux d’arbre d’accessibilité ou tout autre contexte que le navigateur juge utile.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs) Autrement dit, même dans le monde WebMCP, le navigateur continue à regarder la page.

Le standard ajoute une voie structurée pour les **capacités**. Il ne remplace pas les mécanismes permettant de comprendre tout ce qui n’a pas été déclaré.

> **Trois chemins**
> - L’agent observe une interface humaine et devine comment l’actionner.: DOM / vision
> - Le site expose une action structurée dans la page et conserve son état client.: WebMCP
> - L’agent parle directement à un service hors de l’interface web.: API / MCP distant
> WebMCP ajoute un chemin ; il ne supprime pas les deux autres

Un article de presse n’a pas nécessairement besoin d’un tool pour être lu. Une page historique peut continuer à être indexée. Une boutique qui n’implémente rien restera actionnée par le DOM ou par son API privée si un agent parvient à l’utiliser. Et un acteur qui veut extraire des milliers de pages depuis un serveur n’a aucun intérêt particulier à lancer une session de navigateur pour chaque document.

Le scraping de contenu et l’automatisation d’interface ont été mélangés dans le même mot parce que nous avons pris l’habitude de tout faire avec les pages. WebMCP cible surtout le second problème.

## Un outil local

La version impérative de WebMCP est étonnamment simple à expliquer. Un script exécuté dans la page appelle `document.modelContext.registerTool()` avec un nom, une description, un schéma JSON des arguments et une fonction `execute`.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)

L’agent du navigateur peut ensuite découvrir ces définitions et appeler la fonction avec des paramètres structurés. Le code qui réalise réellement l’action reste celui du site : il peut modifier l’interface, utiliser son store JavaScript, déclencher une requête `fetch`, passer par un service déjà authentifié ou composer plusieurs opérations internes.

C’est là que WebMCP diffère d’une API publique classique.

Une API demande généralement à un développeur de créer un endpoint, choisir une méthode d’authentification, documenter le contrat et maintenir un deuxième canal à côté de l’application. Avec WebMCP, une application peut exposer une fonction qui vit dans son propre contexte navigateur et réutilise les mécanismes déjà présents côté client.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)

La frontière n’est pas purement technique. Elle change aussi qui possède l’état.

L’agent n’arrive pas forcément avec sa propre clé API. Il peut agir dans le navigateur où l’utilisateur est déjà connecté, au milieu de la session, des cookies, des données affichées et du workflow que le site a construit. La section sécurité de la spec prend même comme hypothèse de base qu’un agent de navigateur peut hériter du contexte d’identité et de session de l’utilisateur.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)

Cette continuité est extrêmement pratique. Elle est aussi l’une des raisons pour lesquelles WebMCP ne peut pas être réduit à « MCP dans une page ».

## Pas vraiment MCP

Le nom est un petit piège délicieux.

Model Context Protocol définit un protocole de communication complet entre un client et un serveur : initialisation, appels, réponses, transport, primitives comme les tools, resources ou prompts. WebMCP reprend l’idée et la forme générale des **tools**, mais la proposition n’impose pas le data layer MCP pour relier la page à l’agent.[5](https://github.com/webmachinelearning/webmcp/issues/25)

La spec actuelle va même jusqu’à préciser qu’un navigateur est libre de présenter les tools de la page à son agent via MCP, via un mécanisme propriétaire de function calling, ou par n’importe quelle autre représentation appropriée.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)

Donc : WebMCP peut fonctionner sans qu’aucun message MCP ne traverse réellement la frontière entre page et agent.

Ce choix est volontaire. Une discussion de conception du groupe explique qu’en laissant le navigateur comprendre les tools plutôt qu’en transportant des messages MCP opaques, le web évite de se coupler à une version précise du protocole et permet au navigateur d’appliquer ses propres règles de sécurité, notamment autour des iframes et des origines.[5](https://github.com/webmachinelearning/webmcp/issues/25)

Le nom reste logique parce que les tools suivent l’écosystème MCP et parce que les mêmes modèles d’outils peuvent être traduits. Mais l’architecture est plus proche de **function calling standardisé pour les pages web** que d’un serveur MCP complet miniature.

> **Le nom ment un peu**
> - Protocole client/serveur, data layer, transport, tools/resources/prompts.: MCP serveur
> - API Web pour déclarer des tools. Le navigateur choisit comment les transmettre à son agent.: WebMCP
> La compatibilité conceptuelle est forte ; le transport n’est pas le même contrat

Cette distinction devient importante dès qu’on parle d’interopérabilité. Un agent compatible MCP n’obtient pas automatiquement toutes les pages WebMCP sans navigateur adapté. Et une page WebMCP n’est pas un endpoint auquel un client MCP distant peut simplement envoyer `tools/list` depuis un serveur.

Il faut un pont.

## Le pont Cloudflare

C’est exactement ce que Cloudflare construit.

Son système n’édite pas votre dépôt et ne génère pas magiquement une API à partir de tous les boutons de la page. Lorsqu’un domaine active la preview, Cloudflare utilise `HTMLRewriter` à l’edge pour injecter une petite référence vers `/.webmcp/bridge.js` dans les réponses HTML.[1](https://blog.cloudflare.com/webmcp/)

Ce bridge regarde si le navigateur possède `document.modelContext`. Si la surface WebMCP n’existe pas, il ne fait rien. Sinon, il enregistre des groupes de tools appelés **packs**.[1](https://blog.cloudflare.com/webmcp/)

La nuance avec le titre « Give any website a WebMCP interface » est importante : dans la preview d’août, Cloudflare ne transforme pas automatiquement toutes les fonctionnalités arbitraires de n’importe quel site en tools. Il fournit deux packs précis.[1](https://blog.cloudflare.com/webmcp/)

Le premier lit les Content Credentials C2PA des images. Le second agit comme client d’un **serveur MCP que le site possède déjà**, par défaut sur `/mcp`. Le bridge récupère alors la liste des tools de ce serveur et enregistre dans la page des proxys WebMCP qui rappellent le même endpoint lorsque l’agent les invoque.[1](https://blog.cloudflare.com/webmcp/)

> Illustration: Capture du dashboard Cloudflare permettant d’activer WebMCP et ses packs sur un domaine. Cloudflare injecte le bridge à l’edge. Dans la preview, les deux packs disponibles sont Content Credentials et Site MCP Server. Credit: [Cloudflare](https://blog.cloudflare.com/webmcp/).

Cette architecture est plus honnête et plus utile qu’un générateur automatique de tools. Cloudflare ne prétend pas comprendre ce qu’un bouton métier signifie mieux que son développeur. Il réduit le coût de raccordement entre trois éléments qui existent déjà : le navigateur agentique, la page et un serveur MCP du site.

Le résultat peut être activé sans redeployer l’origine, mais la fonctionnalité métier n’apparaît pas du néant. Si vous voulez un tool `refund_order`, quelqu’un doit toujours écrire la logique permettant réellement de rembourser une commande.

L’humanité est rassurante : même à l’ère agentique, le bouton magique a encore un backend.

## Votre session

Le choix de faire passer le tool par la page a un autre effet : Cloudflare montre un proxy qui appelle le serveur MCP en same-origin avec `credentials: "same-origin"`.[1](https://blog.cloudflare.com/webmcp/)

Cela signifie qu’un site peut réutiliser la session existante de l’utilisateur. Pas besoin de demander à l’agent de stocker une deuxième authentification simplement pour retrouver la commande visible dans le compte déjà ouvert.

En termes d’expérience, c’est puissant. « Annule ma dernière commande » peut devenir une action du site courant plutôt qu’une conversation abstraite avec une API séparée.

En termes de sécurité, cela déplace immédiatement le niveau d’exigence.

Un mauvais clic automatisé sur une page publique produit un résultat ridicule. Un tool appelé dans une session authentifiée peut envoyer un message, acheter un produit, modifier un profil ou supprimer une donnée. La stabilité du contrat devient meilleure, donc les conséquences d’une erreur deviennent elles aussi plus stables. Formidable progrès civilisationnel.

Le draft WebMCP prévoit un mécanisme de Permissions Policy nommé `tools`, autorisé par défaut uniquement à `self`, et des règles d’origine pour contrôler quels documents peuvent exposer leurs tools à d’autres contextes.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs) C’est utile pour les iframes et le contrôle de provenance.

Mais cette permission ne répond pas à elle seule à la question « l’utilisateur voulait-il vraiment envoyer ce formulaire maintenant ? ».

Le travail sur l’API déclarative montre une piste plus explicite. Le projet propose de transformer des formulaires HTML en tools à l’aide d’attributs comme `toolname` et `tooldescription`. Sans `toolautosubmit`, l’agent remplirait le formulaire puis le navigateur remettrait le focus sur le bouton de validation afin que l’utilisateur vérifie et soumette lui-même. Avec `toolautosubmit`, cette étape humaine peut être supprimée.[4](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md)

> **Qui dit oui ?**
> - Choisit les tools, leurs descriptions, leur code et leurs origines.: Site
> - Applique la policy, expose le contexte et décide comment son agent reçoit les tools.: Navigateur
> - Peut rester dans la boucle, mais certaines actions peuvent aussi être conçues pour s’exécuter automatiquement.: Utilisateur
> WebMCP structure l’action ; il ne supprime pas le problème du consentement

Cette partie reste très mouvante. Le document déclaratif note encore plusieurs détails « TBD », notamment la synthèse exacte du JSON Schema pour certains contrôles de formulaire et la manière de retourner une réponse après navigation.[4](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md) Chrome parle d’un origin trial, pas d’une API web figée pour les quinze prochaines années.[3](https://developer.chrome.com/blog/ai-webmcp-origin-trial)

## Le formulaire compile

L’API déclarative mérite qu’on s’y attarde parce qu’elle montre une autre ambition que `registerTool()`. Le développeur n’est pas obligé de recopier en JavaScript toute une interface déjà décrite en HTML. Le navigateur peut partir d’un vrai `<form>`, de ses noms de champs, de ses types, de ses valeurs autorisées et de ses contraintes pour construire le schéma de l’outil.[4](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md)

C’est presque une compilation de l’interface humaine vers l’interface agentique.

Un champ `email` reste un champ email. Un `select` fournit déjà une liste d’options. Un contrôle `required` exprime une contrainte que le formulaire possède depuis longtemps. La proposition essaie de récupérer ces informations plutôt que demander au site de maintenir une seconde description du même workflow.[4](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md)

Ce point peut sembler banal, mais il décide d’une bonne partie du coût réel d’un standard. Si WebMCP exigeait que chaque équipe redécrive manuellement toutes ses actions, schémas et validations dans une nouvelle couche JavaScript, la jolie interface agentique deviendrait rapidement un deuxième produit à synchroniser. À l’inverse, dériver les tools depuis du HTML sémantique crée une raison supplémentaire de garder les formulaires compréhensibles par la plateforme.

La proposition n’est pas terminée : les règles exactes pour construire certains JSON Schemas restent ouvertes, tout comme les réponses lorsqu’une soumission navigue vers un autre document.[4](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md) Mais la direction est intéressante. Le web possède déjà beaucoup de métadonnées décrivant ce qu’un utilisateur peut faire. WebMCP essaie d’en faire une surface directement utilisable par un agent au lieu d’ajouter systématiquement une API parallèle.

> **Six mois de WebMCP**
> - Chrome ouvre l’early preview aux développeurs.: 10 fév.
> - Origin trial annoncé pour Chrome 149.: 9 juin
> - Cloudflare lance son bridge et ses deux premiers packs.: 6 août
> - Draft Community Group actif, API déclarative encore en discussion.: Aujourd’hui
> 2026 : expérimentation rapide, pas standard figé

## Le vrai pouvoir

Si WebMCP se généralise, le changement le plus important ne sera peut-être pas la robustesse des agents. Ce sera le retour du **site** dans la définition de l’interface agentique.

Avec le scraping ou l’automatisation visuelle, le site publie une interface humaine et l’agent décide comment l’interpréter. Le développeur peut rendre le DOM plus ou moins accessible, mais il ne décrit pas nécessairement ce qu’un agent devrait considérer comme une capacité stable.

Avec WebMCP, il choisit le vocabulaire.

Un marchand peut exposer `search_products` mais pas `export_all_prices`. Une banque peut déclarer un tool de recherche de transactions sans exposer un tool de virement. Un logiciel peut donner à l’agent un diagnostic structuré tout en gardant certaines actions derrière une validation humaine.

Le site reprend donc une partie du contrôle perdu lorsque les agents ont commencé à traiter toutes les interfaces comme des surfaces à reverse-engineerer.

Cloudflare insiste aussi sur le trafic et l’attribution : un agent qui visite le site et utilise les tools de la page reste dans le contexte du domaine, plutôt que de faire aspirer son contenu par un crawler distant.[1](https://blog.cloudflare.com/webmcp/) Techniquement, c’est vrai pour ce parcours. Le navigateur charge la page, exécute le bridge et les appels same-origin reviennent vers le site.

Mais **conserver le trafic ne signifie pas conserver l’attention**.

Un agent peut ouvrir votre page, appeler `search_products`, récupérer trois résultats puis répondre à l’utilisateur dans sa propre interface sans que celui-ci regarde une seule publicité, découvre la navigation du site ou lise le texte éditorial autour du catalogue. Le serveur reçoit une visite ; le produit médiatique peut ne recevoir aucune attention humaine.

WebMCP améliore la position technique du site sans résoudre automatiquement son modèle économique.

## Le nouveau risque

Déclarer un tool évite à l’agent de deviner où cliquer, mais cela transforme la description du tool en une nouvelle surface de confiance.

La section sécurité du draft est étonnamment explicite : elle identifie la **prompt injection dans les métadonnées, les entrées ou les sorties des tools** comme un risque central.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs) Une description n’est pas seulement une documentation lue par un développeur. Elle peut entrer directement dans le contexte du modèle chargé de choisir quoi appeler.

Un site malveillant peut donc enregistrer un tool au nom rassurant avec une description conçue pour influencer le modèle. Une page compromise peut tenter d’empoisonner le contexte. Et un tool parfaitement légitime peut retourner du contenu utilisateur contenant lui-même des instructions adverses.

La structure JSON ne fait pas disparaître le langage naturel.

Le draft suppose en outre des agents capables de corréler des informations entre plusieurs sites et d’utiliser l’identité, l’historique ou même des données de paiement disponibles dans le contexte navigateur.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs) Les auteurs reconnaissent que les mitigations précises dépendent du navigateur, du fournisseur d’agent et du site ; la section sécurité reste non normative sur plusieurs points.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)

C’est une différence majeure avec une API serveur classique. Une API peut appliquer OAuth, des scopes et des ACL sur un client identifié. WebMCP s’insère dans une interaction où le navigateur doit également comprendre l’origine d’un tool, la confiance à accorder à sa description, l’intention de l’utilisateur et les conséquences potentielles d’un appel.

La stabilité de l’action ne garantit pas la sûreté de la décision.

> **Moins fragile ≠ plus sûr**
> - Peut cliquer au mauvais endroit parce que l’interface a changé.: Automatisation DOM
> - Appelle exactement la bonne fonction, mais peut le faire pour une mauvaise raison si le contexte ou la description a été empoisonné.: Tool déclaré
> WebMCP déplace une partie du risque du repérage vers la décision

## Ce qui reste

La preview Chrome est encore jeune. WebMCP était accessible en early preview en février 2026 ; Chrome a ouvert un origin trial à partir de Chrome 149 en juin, tandis que Cloudflare indique que la surface existait expérimentalement depuis Chrome 146.[3](https://developer.chrome.com/blog/ai-webmcp-origin-trial)[6](https://developer.chrome.com/blog/webmcp-epp)[1](https://blog.cloudflare.com/webmcp/)

Le draft Community Group continue d’évoluer. L’API déclarative possède encore des questions ouvertes. L’intégration des iframes, la sécurité et la manière exacte dont différents navigateurs présenteront les tools à leurs agents ne sont pas terminées.[2](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)[4](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md)

Et surtout, WebMCP ne bénéficie que des capacités qu’un site accepte ou sait exposer.

Le vieux web ne disparaît pas le jour où Chrome ajoute une nouvelle interface. Les milliards de pages existantes resteront lisibles par DOM, accessibilité, rendu, extraction ou crawler. Les sites hostiles aux agents ne fourniront probablement pas un tool sympathique `download_everything`. Les sites abandonnés ne seront pas modernisés par télépathie. Les applications qui vivent derrière des APIs riches continueront d’avoir de bonnes raisons d’exposer directement ces APIs ou un serveur MCP distant.

Le web agentique sera donc hybride, ce qui est une façon polie de dire qu’il accumulera encore une couche.

Mais celle-ci répond à un vrai problème.

## Une autre interface

Nous avons longtemps conçu deux interfaces pour un service web : l’interface graphique pour les humains et l’API pour les programmes. Les agents ont créé un troisième utilisateur qui n’entre proprement dans aucune des deux catégories.

Ils comprennent le langage naturel et peuvent regarder un écran, donc on leur donne l’interface humaine. Mais ils exécutent des tâches structurées et répétables, donc on attend d’eux la fiabilité d’un programme. Puis nous sommes surpris lorsqu’un modèle intelligent passe six étapes à retrouver un bouton « Confirmer » que le backend connaissait depuis le début.

WebMCP propose une réponse assez raisonnable : laisser l’application déclarer une **interface de capacités** directement dans la page où la session et l’état existent déjà.

Cette interface n’a pas besoin de remplacer le DOM. Elle n’a pas besoin de remplacer les APIs. Elle n’a même pas besoin de transporter MCP de bout en bout pour être utile.

Elle sert à éviter qu’un agent reconstruise à chaque visite le sens d’une interface que le développeur connaît parfaitement.

Le scraping restera là où personne ne coopère. Les APIs resteront là où une intégration serveur est plus propre. Et WebMCP peut occuper un espace intermédiaire très spécifique : l’utilisateur est déjà sur le site, l’agent agit avec lui, et le site préfère déclarer **ce qu’il sait faire** plutôt que laisser un modèle deviner **où cliquer**.

Ce n’est pas la fin du web pour humains.

C’est peut-être la fin de l’idée absurde selon laquelle un agent doit faire semblant d’en être un pour utiliser chaque bouton.

## References

1. [Cloudflare, Give any website a WebMCP interface, 6 août 2026](https://blog.cloudflare.com/webmcp/)
2. [WebMCP Community Group Draft, webmachinelearning/webmcp](https://github.com/webmachinelearning/webmcp/blob/main/index.bs)
3. [Chrome for Developers, Join the WebMCP origin trial, 9 juin 2026](https://developer.chrome.com/blog/ai-webmcp-origin-trial)
4. [WebMCP, Declarative API explainer](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md)
5. [WebMCP issue #25, Core design principles for WebMCP](https://github.com/webmachinelearning/webmcp/issues/25)
6. [Chrome for Developers, WebMCP is available for early preview, 10 février 2026](https://developer.chrome.com/blog/webmcp-epp)