Le WebMCP et Browser Run sont peut-être les deux pièces d’un changement beaucoup plus important qu’une nouvelle fonction Cloudflare. Jusqu’ici, un agent IA devait regarder une page comme un humain pressé : prendre une capture, interpréter les boutons, cliquer, attendre, recommencer. Désormais, les sites commencent à pouvoir déclarer directement les actions qu’ils savent exécuter.
Le mot-clé est WebMCP. Cette API de navigateur permet à une page Web d’exposer des outils structurés qu’un agent peut découvrir et appeler avec des paramètres définis. Cloudflare vient d’intégrer ce modèle à Browser Run, son service de navigateurs pilotables à distance, en plus d’un accès direct au protocole CDP, des enregistrements de sessions et de l’intervention humaine. Ce n’est pas encore le Web de demain, mais c’est déjà son premier brouillon technique.
Le Web actuel oblige encore les agents à deviner
Un site Web est conçu pour qu’un humain reconnaisse une barre de recherche, comprenne un bouton « Réserver » et sache quelle date choisir. Un agent IA, lui, doit reconstruire cette intention à partir du HTML, du texte visible, de la position des éléments et parfois d’une capture d’écran. Une petite modification de mise en page suffit à casser une automatisation qui semblait pourtant fonctionnelle.
C’est le fameux cycle capture d’écran → analyse → clic. L’agent observe l’interface, formule une hypothèse, agit, puis vérifie si son action a produit le résultat attendu. Cette méthode reste utile pour les sites qui n’exposent aucune interface exploitable, mais elle est lente, coûteuse en tokens et fragile. Elle confond souvent le fonctionnement d’une application avec son apparence.
Une API classique règle déjà une partie du problème. Si un service expose une API REST documentée, un logiciel peut appeler GET /products ou POST /orders sans simuler un utilisateur. Mais chaque site doit alors publier son propre backend, gérer l’authentification, la documentation et les intégrations. WebMCP propose une couche complémentaire : les fonctions sont déclarées dans la page elle-même, au plus près de l’interface et de son état réel.
WebMCP transforme une page en fournisseur d’outils
WebMCP, pour Web Model Context Protocol, est une proposition d’API de navigateur portée par l’écosystème Chrome. Son principe est simple : une page enregistre des outils avec un nom, une description et un schéma de paramètres. Un agent peut ensuite découvrir ces outils dans le contexte de la page et appeler celui qui correspond à la demande de l’utilisateur.
Visuel source : Cloudflare, « Browser Run: give your agents a browser » — https://blog.cloudflare.com/browser-run-for-ai-agents/
Un site de réservation pourrait ainsi déclarer un outil search_flights avec une origine, une destination et une date de départ. L’agent ne cherche plus le champ qui ressemble à une destination : il reçoit une fonction décrite explicitement. Le site conserve sa logique métier et peut renvoyer un résultat structuré, tandis que l’agent évite une longue série d’interprétations visuelles.
Ce modèle ne transforme pas WebMCP en serveur MCP classique installé quelque part sur Internet. Les outils vivent dans le contexte de la page et sont exécutés dans le navigateur. Le navigateur garde donc un rôle d’intermédiaire : il peut contrôler quelles pages et quels cadres sont autorisés à exposer des outils, notamment avec la Permissions Policy tools.
Cette précision compte. WebMCP ne remplace pas les API backend, ne fournit pas automatiquement une exécution sans navigateur et ne rend pas une application sûre par magie. C’est une interface d’action côté client, conçue pour réduire l’ambiguïté entre une page et un agent.
Browser Run assemble enfin la pile complète
Cloudflare a renommé Browser Rendering en Browser Run et l’oriente clairement vers les agents IA. Le service fournit des sessions Chrome exécutées sur son réseau, pilotables avec du code ou par un agent. L’annonce récente ne se limite pas à WebMCP : elle assemble plusieurs briques qui manquaient encore pour construire une automatisation exploitable en production.
Le premier changement est l’accès direct au Chrome DevTools Protocol, ou CDP. Ce protocole de débogage distant permet d’instrumenter, d’inspecter et de contrôler Chromium. Puppeteer et Playwright s’appuient déjà dessus, mais Browser Run expose désormais un endpoint CDP utilisable directement depuis un environnement compatible WebSocket. Les scripts et les agents qui parlent déjà CDP peuvent donc se connecter à un navigateur Cloudflare sans gérer eux-mêmes la machine, la version de Chrome ou le port de débogage.
Cloudflare ajoute aussi une intégration avec les clients MCP. Un agent de développement peut utiliser Browser Run comme navigateur distant, tandis que CDP fournit les commandes bas niveau pour naviguer, inspecter le DOM, observer le réseau ou déboguer du JavaScript. Ce découpage est plus propre qu’un agent qui reçoit uniquement une suite de captures et doit deviner ce qui s’est passé entre deux images.
La visibilité progresse dans le même mouvement. Live View permet de voir la session en temps réel. Les Session Recordings conservent les changements du DOM, les interactions souris et clavier et les navigations, afin de rejouer un parcours lorsqu’une automatisation échoue. Cloudflare annonce aussi une limite par défaut portée de 30 à 120 navigateurs concurrents. L’agent ne gagne pas seulement des yeux et des mains : son opérateur récupère enfin une trace exploitable.
L’humain ne disparaît pas de la boucle
Le point le plus intéressant est peut-être le Human-in-the-Loop. Une automatisation sérieuse finit toujours par rencontrer une page de connexion, une validation multifactorielle, un paiement ou un cas imprévu. Prétendre que l’agent doit tout faire seul conduit généralement à deux résultats : un échec silencieux ou une prise de risque inutile.
Avec Browser Run, la session peut être ouverte dans Live View afin qu’une personne intervienne directement. Les commandes CDP spécifiques de Cloudflare permettent aussi de demander une prise en main et d’attendre la fin de l’intervention. L’humain se connecte, confirme ou débloque l’étape sensible, puis l’automatisation reprend dans la même session.
WebMCP suit la même logique. La documentation Cloudflare montre par exemple un outil de réservation qui attend une confirmation humaine avant de finaliser une action sensible. Le navigateur agentique n’est donc pas forcément un robot qui remplace l’utilisateur : il peut devenir une interface où l’agent prépare, l’humain décide et le site exécute.
C’est une différence importante pour les entreprises. Un agent qui sait demander de l’aide, conserver un historique de session et reprendre après une intervention est beaucoup plus utile qu’un agent présenté comme autonome mais incapable de dépasser une page de connexion.
Le passage à un Web agent-native ne sera pas automatique
Le terme agent-native ne doit pas devenir un nouveau mot marketing pour désigner n’importe quel chatbot capable de cliquer. Un site conçu pour des agents doit d’abord décrire clairement ses actions, ses paramètres, ses résultats et ses conditions d’échec. Il doit ensuite gérer les permissions, l’authentification, les confirmations et les effets de bord.
Il faudra aussi décider quelles actions peuvent être automatisées sans confirmation. Lire un catalogue et filtrer des résultats n’ont pas le même niveau de risque que supprimer un compte, envoyer un virement ou publier un message. WebMCP facilite l’appel d’une fonction, mais la responsabilité du site reste entière : validation côté serveur, contrôle des droits, protection contre les répétitions et journalisation ne disparaissent pas parce qu’un agent utilise un schéma JSON.
Le modèle reste en expérimentation. La documentation Chrome présente WebMCP comme une proposition et décrit encore des limitations : un contexte de navigation visible est requis, la découverte se fait lorsqu’un client visite la page et les interfaces complexes peuvent demander un vrai travail de refactorisation. Côté Cloudflare, l’utilisation de WebMCP passe encore par des sessions de laboratoire et une version bêta de Chrome. Il ne faut donc pas confondre une direction stratégique claire avec un standard définitivement figé.
Mais la direction est difficile à ignorer. REST a appris aux logiciels à demander des données. WebMCP commence à apprendre aux pages à déclarer des actions. Entre les deux, CDP donne aux agents un canal de contrôle, Browser Run fournit l’infrastructure et le Human-in-the-Loop rappelle que l’autonomie utile n’est pas l’absence d’humain : c’est la capacité à savoir quand lui rendre la main.
Le navigateur devient une plateforme d’exécution
La vraie évolution ne se trouve donc pas dans une seule API. Elle vient de l’empilement : des sites qui exposent des outils, des navigateurs pilotables à distance, des protocoles bas niveau, des traces de session et des points d’intervention humaine. Le navigateur cesse progressivement d’être une simple fenêtre vers le Web. Il devient un environnement d’exécution pour des agents qui lisent, planifient, agissent et rendent compte.
Cela pourrait modifier la conception des sites aussi profondément que l’arrivée des API REST. Une application ne sera plus seulement évaluée sur son interface humaine, sa version mobile ou sa documentation développeur. On lui demandera aussi : quelles actions un agent peut-il découvrir ? Quel état reçoit-il ? Que peut-il faire sans confirmation ? Comment l’utilisateur reprend-il le contrôle ?
Le Web ne devient pas encore un réseau de sites qui parlent tous aux agents. Mais les premières briques sont désormais publiques, testables et intégrées à l’infrastructure de navigateurs. Les équipes qui les expérimentent aujourd’hui ne construisent pas seulement de meilleurs robots de clics. Elles commencent à définir la grammaire d’un Web où l’agent ne cherche plus quoi faire : le site le lui explique.
Sources
Cloudflare, « Browser Run: give your agents a browser » — https://blog.cloudflare.com/browser-run-for-ai-agents/ — annonce de Browser Run, WebMCP, CDP, Live View, enregistrements de sessions, Human-in-the-Loop et limites de concurrence.
Cloudflare Developers, « WebMCP » — https://developers.cloudflare.com/browser-run/features/webmcp/ — fonctionnement, outils structurés, sessions de laboratoire, confirmation humaine et limites actuelles.
Cloudflare Developers, « Chrome DevTools Protocol (CDP) » — https://developers.cloudflare.com/browser-run/cdp/ — endpoints de sessions, WebSocket, HTTP et usages du protocole.
Chrome for Developers, « WebMCP » — https://developer.chrome.com/docs/ai/webmcp — proposition d’API, découverte, schémas JSON, état, sécurité et limites du modèle.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet