Automatisation web : exploiter WebMCP avec Kitesurf

Automatisation web avec Kitesurf WebMCP : l’essentiel

Pour utiliser Kitesurf WebMCP, connectez un agent compatible MCP à Cloudflare Browser Run via Chrome DevTools MCP, configurez l’endpoint WebSocket avec browser=kitesurf, puis activez la catégorie expérimentale des outils WebMCP. L’agent obtient alors deux commandes essentielles : list_webmcp_tools pour découvrir les actions d’une page et execute_webmcp_tool pour en exécuter une.

Commencez par une action en lecture seule ou réversible. Cloudflare Radar est une cible bien documentée : le service expose notamment des actions comme navigate-to et set-location. Inspectez le schéma renvoyé par Kitesurf, ne fournissez que les arguments qu’il accepte, puis confrontez le résultat structuré à l’état visible de la page. Un appel d’outil n’est validé que si les deux concordent.

Ce guide présente un protocole de test documenté, pas le compte rendu d’un test réellement exécuté. Aucun compte Cloudflare ni jeton Browser Run de test n’était disponible lors de cette publication : les résultats ci-dessous ne sont donc pas des réussites inventées.

Ce que Kitesurf WebMCP change réellement

MCP et WebMCP ne remplissent pas le même rôle. MCP relie votre agent au navigateur distant. WebMCP permet au site de publier ses propres actions nommées dans ce navigateur. MCP est en quelque sorte la ligne téléphonique, et WebMCP le menu disponible à l’autre bout : la ligne établit la connexion, tandis que le menu précise ce qu’il est possible de commander et les informations nécessaires pour chaque demande.

Sans ce menu, un agent doit souvent lire la page, repérer un contrôle, cliquer, attendre, puis relire. Avec WebMCP, une page peut exposer une fonction comme set-location, accompagnée d’entrées typées. L’agent doit toujours choisir la bonne action et valider sa sortie, mais il n’a plus à déduire chaque interaction à partir des pixels ou de la structure de la page.

Selon la documentation WebMCP de Cloudflare, Kitesurf dispose de sa propre implémentation et n’a donc pas besoin d’une session Chrome Lab. Les pages peuvent enregistrer des outils programmatiques via document.modelContext. Kitesurf reconnaît également les outils de formulaire déclaratifs signalés par les attributs toolname et tooldescription.

Connecter un client MCP à Kitesurf

Il vous faut Node.js 20.19 ou une version plus récente, un client compatible MCP, un identifiant de compte Cloudflare et un jeton API doté de l’autorisation Browser Rendering - Edit. Le guide de configuration des clients MCP de Cloudflare couvre Claude Desktop, Claude Code, Cursor et OpenCode. S’il s’agit de votre première connexion MCP, ce comparatif des serveurs MCP vous aidera à comprendre le rôle du serveur local.

L’annonce de Kitesurf par Cloudflare fournit cette configuration pour le client local :

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

Adaptez la forme de la configuration aux attentes de votre client, mais conservez les arguments de la commande. Stockez le véritable identifiant de compte et le jeton dans des secrets fournis par l’environnement, plutôt que dans un fichier de réglages versionné. Ne recopiez pas les paramètres de Chrome Lab dans cette URL. Kitesurf utilise browser=kitesurf, n’exige pas lab=true et n’accepte pas keep_alive.

Le dernier flag est indispensable. C’est --category-experimental-webmcp qui ajoute list_webmcp_tools et execute_webmcp_tool à Chrome DevTools MCP. Sans lui, la connexion peut parfaitement fonctionner alors que les deux commandes WebMCP restent introuvables.

Exécuter une tâche vérifiée sur Cloudflare Radar

Le plus petit test pertinent doit confirmer quatre points : la découverte fonctionne, le schéma est lisible, l’exécution renvoie des données et la page reflète bien le résultat.

1. Demandez à l’agent connecté d’ouvrir https://radar.cloudflare.com/. Limitez le test à un compte prévu à cet effet et évitez toute action ayant des conséquences financières, destructrices ou à l’échelle du compte.
2. Appelez list_webmcp_tools. Enregistrez le nom, la description et le schéma d’entrée de chaque outil renvoyé. La liste disponible peut changer après une navigation ou une autre action : cet inventaire ne vaut donc que pour l’état actuel de la page.
3. Si une action sans risque comme set-location est présente, sélectionnez-la et lisez le schéma renvoyé. Ne déduisez pas les noms d’arguments à partir de cet article. Le schéma en direct fait foi.
4. Appelez execute_webmcp_tool avec une valeur de localisation conforme au schéma. Consignez le nom exact de l’outil, les arguments, le résultat structuré, le temps écoulé et l’état visible de la page.
5. Comparez la réponse avec ce qu’affiche Radar. Relancez list_webmcp_tools après le changement d’état, puis notez les actions ajoutées ou supprimées.

Un bon prompt d’agent va droit au but :

Traitez ces éléments comme une fiche de test concise, pas comme une transcription de conversation. Conservez au minimum les champs suivants :

Ce relevé transforme une démo en test reproductible par une équipe d’ingénierie. Il distingue aussi une défaillance de WebMCP d’une erreur de raisonnement de l’agent. Si l’outil nommé est absent, l’interface a échoué avant l’exécution. Si l’appel aboutit mais que la page contredit le résultat, l’implémentation ou la vérification a échoué après l’exécution.

Quand Kitesurf doit prévoir un fallback

Kitesurf WebMCP n’est pas une couche universelle de contrôle du navigateur. Ses limites actuelles déterminent les tâches de production qu’il est prudent de lui confier.

• Les outils enregistrés dans une iframe ou une popup ne sont pas exposés via CDP. Considérez-les comme inaccessibles à l’agent et passez par un navigateur classique, une intervention humaine ou un outil de premier niveau si le site vous appartient.
• Les sessions Kitesurf n’apparaissent pas dans wrangler browser list et ne disposent d’aucune vue en direct. Un agent ne peut donc pas mener à terme un outil qui attend la confirmation d’une personne.
• Pour une action soumise à confirmation, le parcours manuel documenté par Cloudflare passe par le panneau WebMCP, sous Application, dans le playground Kitesurf. Il s’agit d’un relais humain, pas d’une automatisation autonome.
• Kitesurf n’implémente ni la politique d’autorisation WebMCP tools, ni le filtrage des outils selon l’origine. La découverte d’un outil ne vaut pas autorisation. Maintenez une liste d’autorisation distincte pour les domaines, les actions et les identités de test.
• La liste des outils dépend de l’état de la page. Après une navigation ou toute action qui la modifie, relancez l’inventaire avant de supposer que l’outil suivant existe toujours.

En production, la solution réaliste prend la forme d’un routeur : WebMCP en priorité lorsqu’une action nommée adaptée est disponible, l’automatisation classique du navigateur dans le cas contraire, et un relais humain dès qu’un consentement est requis. Ne masquez pas ces embranchements derrière un prompt trop optimiste.

Le vrai calcul économique porte sur la maintenance

Kitesurf est gratuit pendant sa bêta, dans la limite des quotas du compte. Cloudflare n’a toutefois pas établi que ses tarifs généraux de dépassement pour Browser Run s’appliqueraient à cette bêta gratuite. L’état actuel des tarifs et quotas de Kitesurf est détaillé séparément, tout comme les raisons de ne pas bâtir un modèle de coûts durable sur une offre bêta.

Le marché consacre déjà un budget réel à l’infrastructure de navigateur. Browserbase propose des formules payantes à $20 et $99 par mois. Browserless affiche des offres à $25 et $140 par mois avec une facturation annuelle. Ces produits couvrent des besoins d’infrastructure plus larges : il ne s’agit donc pas de prétendre qu’ils peuvent être remplacés à l’identique. Ils montrent simplement que les équipes paient déjà pour faire fonctionner des agents de navigation.

WebMCP agit sur un autre poste budgétaire : la maintenance des sélecteurs, les nouvelles tentatives et le contrôle opérateur. Il ne supprime ni le navigateur, ni le modèle, ni les contrôles de sécurité, ni la validation du résultat, ni le parcours de secours. Mesurez la même tâche avec les deux approches, puis comparez le temps écoulé, les tentatives échouées, les interventions humaines et les correctifs techniques. Ne conservez Kitesurf que lorsque la baisse mesurée de la charge de maintenance dépasse le travail d’intégration.

Sept cas d’usage, classés selon les équipes qui y gagnent le plus

Tous les cas ci-dessous supposent que la page cible expose réellement un outil WebMCP adapté. Kitesurf ne peut pas créer une action que le site ne propose pas.

Le premier cas d’usage offre la valeur la plus large, car la plupart des équipes devront composer avec un web hybride pendant des années. Un routeur qui sait quand ne pas utiliser WebMCP est plus utile qu’une démo réussie sur une seule page préparée.

Trois produits à construire

1. Un routeur WebMCP avec fallback intégré

Construisez une couche de règles destinée aux équipes qui déploient des agents : elle inventorie les outils d’une page, rapproche l’action demandée par l’utilisateur d’un schéma autorisé, puis oriente la tâche vers execute_webmcp_tool, une automatisation classique du navigateur ou une file d’attente humaine. C’est l’opportunité la plus solide, car elle comble le fossé d’adoption sans attendre que tous les sites implémentent WebMCP.

La demande existe déjà autour de ce besoin : browser automation génère environ 720 recherches mensuelles, tandis que la requête commerciale browser automation tools en totalise environ 260, avec un CPC de $34.28 dans les données de mots-clés de cette étude. La plus petite version commercialisable doit inclure un connecteur de client MCP, une liste d’autorisation des domaines et des actions, un moteur de correspondance des schémas, un journal d’exécution et un adaptateur de fallback.

La portée reste le principal obstacle. La couverture de WebMCP est encore limitée, l’ensemble des outils peut évoluer avec l’état de la page et Kitesurf ne peut pas exposer via CDP ceux qui se trouvent dans une iframe ou une popup. Le moteur de fallback fait partie du produit dès le départ : ce n’est pas une option à ajouter plus tard.

2. Un moniteur de régression WebMCP

Proposez aux propriétaires de sites un contrôle planifié qui enregistre les noms et schémas des outils exposés, exécute une action de test réversible, confronte le résultat à la page visible et déclenche une alerte en cas d’écart. Environ 590 recherches mensuelles ciblent website automation, avec un CPC de $33.88. La requête apparentée au singulier browser automation tool progresse de 24% sur un an dans les données de suggestions.

Un MVP peut surveiller une courte liste de routes d’un site contrôlé par le client avec des identifiants de test, stocker les inventaires d’outils avant et après l’action, puis produire une fiche d’échec concise réunissant les arguments, le résultat, la durée et l’état de la page. La difficulté tient à l’état : un outil manquant peut signaler une mauvaise route ou une session mal positionnée plutôt qu’une version défaillante. Le produit doit donc garantir une navigation reproductible et des jeux d’essai soigneusement conçus.

3. Un audit de préparation à WebMCP

Créez un service de préflight pour les équipes web. Il cartographie les parcours clients qui exposent des outils de premier niveau, les actions enfermées dans des iframes ou des popups et celles qui exigent la validation d’une personne. Le signal de demande est concret : playwright browser automation génère environ 320 recherches mensuelles et progresse de 129% sur un an, tandis que website automation en totalise environ 590.

La plus petite version accepte les routes d’un site détenu par le client et une identité de test, inventorie et classe les outils disponibles, puis produit un rapport d’implémentation priorisé. Sa limite réelle concerne l’observabilité. Comme Kitesurf ne peut pas exposer via CDP les outils imbriqués dans une iframe ou une popup, un auditeur ne peut pas déduire leur contrat attendu à partir du seul Kitesurf. Il lui faut les informations du propriétaire du site ou une seconde méthode d’inspection pour distinguer ce qui est masqué de ce qui est absent.

Limites et verdict sans détour

Utilisez Kitesurf WebMCP dès maintenant pour des tâches délimitées et réversibles, lorsqu’une action structurée surpasse clairement une suite de clics. N’en faites pas l’unique voie pour un workflow critique, un paiement imbriqué ou une tâche qui doit attendre une validation humaine en direct.

La fonctionnalité apporte une vraie valeur, mais son lancement devance l’écosystème. Le modèle d’actions nommées peut réduire l’ambiguïté et faciliter le diagnostic des échecs. Il ne rend pas tous les sites immédiatement exploitables par des agents et un résultat renvoyé ne prouve pas que la page a effectué la bonne action. La vérification constitue la véritable frontière du produit.

Si vous souhaitez déployer cette connexion, ce protocole de vérification et cette politique de fallback pour un agent en production, je peux vous aider à construire le système.