Qu'est-ce que le Web agentique ? WebMCP, MCP Fetch et l'accès natif aux agents
Tous les articles

Qu'est-ce que le Web agentique ? WebMCP, MCP Fetch et l'accès natif aux agents

Ryan Turner
Ryan Turner · Head of Growth

Le réseau agentique Il s'agit d'une évolution vers le traitement des agents IA comme des clients web à part entière. Au lieu qu'un agent devine comment agir à partir de code HTML brut, un site met à sa disposition des outils structurés auxquels il peut accéder directement. C'est le site qui indique à l'agent comment interagir, plutôt que de laisser ce dernier procéder à une ingénierie inverse du DOM en espérant que la mise en page n'ait pas changé du jour au lendemain.

Voilà l'idée en une phrase. Le Web que vous et moi parcourons a été conçu pour les yeux humains et les clics de souris. Le Web agentique ajoute une deuxième interface, conçue pour des machines qui lisent, prennent des décisions et agissent en votre nom. Deux normes constituent aujourd'hui le fondement de cette interface : WebMCP et le Model Context Protocol, avec son serveur de référence Fetch.

Points à retenir
  • Le Web agentique considère les agents comme des clients natifs : ce sont les sites qui mettent à disposition des outils pouvant être appelés, et non les agents qui parcourent le DOM.
  • WebMCP, présenté lors de la Google I/O 2026, permet à un site de publier des fonctions JavaScript et des formulaires HTML sous forme d'outils qu'un agent peut invoquer.
  • MCP Fetch est un serveur standard qui récupère une URL et convertit le code HTML en Markdown, ce qui réduit considérablement le coût des jetons d'agent.
  • L'adoption est précoce mais inégale. La plupart des sites ne proposeront pas de sitôt des outils natifs pour les agents.
  • En attendant, les agents ont toujours besoin de navigateurs, d'API de rendu et de recherche, ainsi que d'un réseau d'appareils réels pour couvrir la longue traîne.

Que signifie exactement « accès natif à l'agent » ?

Accès natif à l'agent Il s'agit d'un modèle dans lequel un site présente ses propres capacités aux agents, de sorte que l'agent appelle une fonction nommée au lieu d'analyser une page. Cela redéfinit l'accès au Web. L'ancien modèle repose sur la détection et la contournement : un agent charge une page, le site tente de repérer le bot, et l'agent s'efforce de ne pas en avoir l'air. L'accès natif pour les agents, en revanche, transforme cela en un problème d'adressage et de protocole, plus proche de l'appel d'une API que du scraping d'un écran.

Cette distinction est importante, car le trafic généré par les bots n'est plus un phénomène marginal. En 2024, les bots automatisés représentaient 51 % de l'ensemble du trafic web, marquant la première fois en dix ans que les machines dépassaient les humains, selon Imperva, Rapport 2025 sur les robots malveillants. Lorsque la plupart de vos visiteurs sont des logiciels, la conception d'une interface destinée à ces derniers n'est plus une simple option, mais devient une véritable question de conception.

Il y a aussi une raison plus discrète. Lorsqu’un site peut fournir à un robot d’indexation un parcours clair et autorisé, il contrôle ce que le robot voit et fait. Par conséquent, cela s’avère plus prévisible pour le propriétaire du site que de laisser des milliers de robots d’indexation improviser sur une structure qui n’a jamais été conçue pour eux. Le site définit les règles, l'agent s'y conforme, et les deux parties ont moins de surprises.

Cela modifie également le mode de défaillance. Le scraping DOM se bloque silencieusement lorsqu’un nom de classe change ou qu’un bouton se déplace ; un outil natif de l’agent existe ou n’existe pas, et un contrat versionné peut le signaler explicitement. D'après ce que nous observons dans les charges de travail des agents, les ingénieurs responsables de la couche d'accès ont tendance à préférer le second type de défaillance, car il est visible et testable plutôt que silencieux et intermittent. Pour comprendre pourquoi cela est important à tous les niveaux de la pile, consultez donner aux agents IA un accès en temps réel au Web.

Comment fonctionne WebMCP ?

WebMCP Il s'agit d'un projet de norme, présenté lors de la Google I/O 2026, qui permet à un site web de mettre à disposition ses propres fonctions JavaScript et formulaires HTML en tant qu'outils pouvant être appelés par un agent basé sur un navigateur. Selon Chrome, Chrome à l'I/O 2026Le site définit ce qu'un agent peut faire ; l'agent lit ces définitions et les invoque comme s'il s'agissait d'appels d'API. En résumé, la page décrit ses propres actions au lieu d'obliger l'agent à les déduire.

Imaginez un processus de paiement. Sans WebMCP, un agent doit repérer les champs de saisie appropriés, les remplir, trouver le bouton de validation et confirmer le résultat, le tout en analysant les pixels et les nœuds DOM qui peuvent changer d'emplacement d'une version à l'autre. Avec WebMCP, en revanche, le site publie un submitOrder outil avec des paramètres typés. L'agent l'appelle. Pas besoin de deviner le sélecteur, pas d'attente instable sur des éléments qui s'affichent tardivement.

Deux caractéristiques rendent cette approche utile. Premièrement, le contrat est explicite : le site indique clairement les outils dont il dispose, ce qui évite à l'agent d'avoir à déduire les intentions par rétro-ingénierie. Deuxièmement, l'agent s'exécute dans la session de navigation de l'utilisateur, ce qui signifie qu'il agit avec les autorisations et l'identité dont dispose déjà l'utilisateur. Cela permet d'éviter toute une série de problèmes d'accès, bien que cela ne soit possible que sur les sites prenant en charge WebMCP, ce qui représente aujourd'hui un petit nombre d'entre eux.

Qu'est-ce que MCP Fetch et pourquoi est-ce important ?

MCP Fetch est le serveur Fetch de référence au sein de l'écosystème du Model Context Protocol. Il remplit parfaitement une seule fonction : prendre une URL, récupérer la page et convertir le code HTML en Markdown lisible par un agent. Conformément à la Répertoire des serveurs du protocole Model ContextIl s'agit d'un outil standard et réutilisable auquel tout agent compatible MCP peut se connecter pour effectuer des requêtes de pages de base.

C'est justement la conversion en Markdown qui fait toute la différence. Le code HTML brut est surchargé d'éléments de navigation, de scripts, de styles et de balises de suivi dont un agent n'a pas besoin et qui lui coûtent des jetons. Réduire une page à un Markdown épuré permet de réduire considérablement le nombre de jetons, souvent de plus de moitié, ce qui diminue les coûts et laisse davantage de place dans la fenêtre de contexte du modèle pour le raisonnement proprement dit. Par exemple, un agent qui charge une page produit au format HTML brut peut dépenser la majeure partie de son budget en menus et balises de script avant d'atteindre le seul paragraphe dont il a besoin. Le compte rendu du praticien à l'adresse dev.to, Outils de navigation pour les agents IA – 4e partie explique en détail ce compromis.

MCP Fetch et WebMCP interviennent à des niveaux différents. Fetch gère la lecture : il récupère une page et renvoie du texte brut. WebMCP, en revanche, gère l'exécution : il appelle les fonctions déclarées d'un site pour effectuer une action. La plupart des workflows d'agents réels ont besoin des deux, et nous constatons que les équipes construisent leur propre couche de récupération par-dessus ces primitives plutôt que de considérer l'une ou l'autre de ces normes comme l'ensemble du pipeline.

Soyez clair sur les limites de Fetch. Il récupère et convertit les données, mais il n’exécute pas de code JavaScript, ne résout pas les pages de vérification d’identité et ne redirige pas vers une autre source lorsque le site bloque la requête. Sur un article statique, cela fonctionne très bien. Sur une application monopage ou une cible protégée, en revanche, il renvoie une page vide ou une page d'erreur, c'est pourquoi les équipes l'associent à un rendu plus lourd pour tout ce qui oppose une résistance. Si vous construisez ce pipeline vous-même, mettre en place un serveur MCP pour l'extraction de données Web couvre le motif dans son intégralité.

Qu'en est-il donc des agents d'aujourd'hui ?

Les agents actuels ont encore besoin de navigateurs, d'API de rendu et de recherche, ainsi que d'un réseau d'appareils réels, car les normes natives aux agents en sont encore à leurs débuts et leur adoption est inégale. WebMCP est une proposition. MCP Fetch, quant à lui, ne prend en charge que les pages simples pouvant être récupérées. La grande majorité du Web ne propose aucun outil natif aux agents, et une grande partie bloque activement l'accès automatisé. Les normes viennent ici en complément, et non en remplacement.

Le blocage est bien réel et prend de l'ampleur. En 2025, Cloudflare a commencé, le 1er juillet, à bloquer par défaut les robots d'indexation basés sur l'IA sur environ 20 % du Web, selon Cloudflare, Cloudflare vient de révolutionner la manière dont les robots d'indexation basés sur l'IA explorent l'Internet dans son ensemble. Les éditeurs de presse sont allés plus loin : en 2025, environ 79 % des principaux sites d'information bloquaient les robots d'entraînement à l'IA, selon Press Gazette, Huit des dix plus grands sites d'information au monde bloquent désormais les robots d'entraînement à l'IA. Un outil WebMCP « propre » ne sert donc à rien pour les millions de sites qui n'en proposeront jamais.

Ces deux mondes coexistent donc. Lorsqu’un site adopte WebMCP ou fournit du contenu « propre » à MCP Fetch, l’accès s’en trouve simplifié et le modèle d’adressage s’impose. En revanche, pour la « longue traîne », les agents ont besoin d’un rendu réel et d’origines provenant d’appareils d’utilisateurs réels pour accéder au contenu de la même manière qu’un visiteur ordinaire. La sortie est plus importante que ce que l'on pourrait croire sur les cibles protégées. Dans nos tests comparatifs de fournisseurs, les requêtes provenant d’adresses IP résidentielles aboutissent généralement sur les sites protégés à des taux bien plus élevés que celles provenant d’adresses IP de centres de données, souvent entre 85 et 99 % contre environ 20 à 40 % pour les centres de données, ce qui explique pourquoi les équipes acheminent les cas difficiles via des origines provenant d’appareils réels. C'est ce que couvrent le réseau d'accès aux appareils et l'API Web Render de la couche Massive : du HTML ou du Markdown propre provenant de n'importe quelle source publique, quel que soit l'emplacement, y compris les sites qui n'exposeront jamais d'outil. Les normes facilitent les cas simples ; elles n'effacent pas les cas difficiles. En ce qui concerne le volet « raisonnement » de ce pipeline, Entraînement des modèles de langage de grande envergure (LLM) à partir de données Web en temps réel relie la recherche aux résultats du modèle.

Sources

Foire aux questions

Le Web agentique est-il une véritable norme ou simplement un effet de mode ?+

Il s'agit d'une orientation étayée par des propositions concrètes. WebMCP a été présenté lors de la Google I/O 2026 et MCP Fetch est déjà disponible dans le dépôt des serveurs du Model Context Protocol. Les éléments sont en place. Cependant, cette technologie n'est pas encore largement adoptée ; il convient donc de la considérer comme une infrastructure émergente, et non comme une plateforme aboutie sur laquelle vous pouvez compter sur l'ensemble du Web ouvert.

WebMCP remplace-t-il le web scraping ?+

Non, pas pour l'instant. WebMCP ne fonctionne que sur les sites qui l'ont implémenté, ce qui représente encore une minorité aujourd'hui. Pour tout le reste, les agents continuent d'analyser les pages, d'exécuter le JavaScript et de passer par des réseaux de périphériques réels pour accéder au contenu. Prévoyez les deux scénarios en production plutôt que de miser sur une prise en charge native universelle par les agents.

Quelle est la différence entre WebMCP et MCP Fetch ?+

MCP Fetch lit : il récupère une URL et convertit le code HTML en Markdown afin que l'agent puisse l'exploiter. WebMCP agit : il permet à un site d'exposer des fonctions et des formulaires appelables afin qu'un agent puisse effectuer des tâches. Lire ou agir. La plupart des flux de travail combinent les deux.

Pourquoi convertir le code HTML en Markdown pour les agents ?+

Le code HTML brut contient des éléments de navigation, des scripts et des styles qui gaspillent des tokens et encombrent la fenêtre de contexte. Le Markdown réduit tout cela à un contenu lisible, ce qui diminue considérablement le nombre de tokens, souvent de plus de moitié. Un coût moindre, une entrée plus épurée, et davantage d'espace laissé au modèle pour se concentrer sur ce qui compte vraiment.