Prix Kitesurf chez Cloudflare : ce que couvre la bêta gratuite

Prix Kitesurf : le navigateur est gratuit tant qu’il reste en bêta. Mais, avec Workers Free, le quota réellement exploitable est plafonné à 10 minutes de navigation par compte et par jour, trois Browser Sessions simultanées et une nouvelle session toutes les 20 secondes. De quoi mener un pilote bien cadré, pas de quoi conclure que l’ensemble de votre stack d’agents ne coûte rien.

Prix Kitesurf : est-il vraiment gratuit ?

Kitesurf est gratuit pendant la bêta du navigateur. Cloudflare l’indique sans ambiguïté dans sa mise à jour du 28 septembre 2026, avec une précision tout aussi importante : l’accès reste soumis aux limites de Browser Run appliquées à chaque compte.

Kitesurf est le moteur de navigation sans état de Cloudflare destiné aux agents IA. Il fonctionne sur Workers et délaisse certaines fonctions conçues pour les utilisateurs humains au profit d’un runtime plus léger, pensé pour les agents. Le moteur Kitesurf ne fait aujourd’hui l’objet d’aucune facturation distincte, mais son usage reste comptabilisé par Browser Run.

Les limites actuelles de Browser Run et sa tarification font apparaître quatre seuils à comparer :

La gratuité répond donc à une question produit, mais pas à toute la question budgétaire. Elle précise ce que Cloudflare facture pour Kitesurf pendant la bêta. Elle ne dit pas si votre workflow respecte les plafonds du compte, s’il vous faut Workers Paid ni combien coûtera le modèle de votre agent.

Les tarifs et limites de ce guide ont été vérifiés sur les pages publiques de Cloudflare le 29 septembre 2026. Faute de tâche Browser Run authentifiée disponible pour ce test, vous ne trouverez ici ni facture de dashboard inventée, ni durée d’exécution fictive, ni taux de réussite fabriqué pour les appels d’outils.

Ce qui a réellement changé le 28 septembre 2026

La mise à jour de septembre rend Kitesurf crédible pour un pilote plus large, car elle relie désormais le moteur aux interfaces déjà utilisées par les équipes qui conçoivent des agents. Le lancement initial d’août avait introduit le navigateur ; cette version ajoute les couches pratiques qui l’entourent.

Première nouveauté : Kitesurf prend maintenant en charge WebMCP, une API de navigateur qui permet à un site d’exposer des outils nommés et des entrées structurées. Un agent peut appeler une fonction du type searchFlights() plutôt que de deviner des boutons à partir de pixels. D’après la documentation WebMCP de Cloudflare, Kitesurf peut répertorier et exécuter ces outils via Chrome DevTools Protocol, généralement abrégé en CDP.

Deuxième évolution : Kitesurf couvre désormais l’intégralité de l’API Browser Run. On peut le sélectionner via CDP, Playwright, Puppeteer ou MCP. Les Quick Actions, interfaces à requête unique de Cloudflare pour produire des captures d’écran, du HTML, des PDF et d’autres sorties courantes, peuvent également sélectionner Kitesurf depuis un Worker grâce à env.BROWSER.quickAction().

Troisième apport : le moteur de rendu fonctionne dans les terminaux compatibles grâce au protocole graphique Kitty, avec un mode texte ANSI pur lorsque Kitty n’est pas disponible. C’est un moyen pratique de voir la page du point de vue du navigateur de l’agent, sans ouvrir un navigateur de bureau séparé. Il s’agit d’un outil d’inspection, pas d’un nouveau niveau de facturation en production.

Cloudflare indique aussi dans la mise à jour de septembre que Kitesurf réussit désormais plus de 730,000 sous-tests de Web Platform Test, soit plus de 500,000 de plus qu’au lancement. Le gain de compatibilité est substantiel. Il ne garantit toutefois pas qu’un portail client choisi au hasard s’affichera correctement : une liste de sites bien délimitée reste donc indispensable au pilote.

Limites de la bêta Kitesurf : peut-on traiter dix tâches par jour ?

Dix tâches quotidiennes ne tiennent dans le quota que si chaque tâche complète consomme en moyenne 60 secondes de navigateur ou moins. L’allocation Workers Free est de 10 minutes, soit 600 secondes de navigateur. En divisant ce budget par 10 tâches, on obtient un seuil de 60 secondes par tâche.

La formule utile est daily task ceiling = floor(600 / measured browser seconds per task). Ne la remplacez pas par le temps écoulé indiqué dans les logs d’une application. Pour Quick Actions, Cloudflare renvoie le temps de navigateur dans l’en-tête de réponse X-Browser-Ms-Used, selon sa documentation tarifaire. Relevez cette valeur pour la même tâche et les mêmes sites cibles que ceux prévus en production.

Le temps n’est pas la seule contrainte. La page des limites précise qu’un compte Free peut exécuter trois Browser Sessions simultanément, démarrer une nouvelle session toutes les 20 secondes et lancer une requête Quick Actions toutes les 10 secondes. Le délai d’inactivité par défaut est de 60 secondes. Cloudflare autorise une fenêtre keep_alive plus longue dans les intégrations de session compatibles, mais sa page WebMCP précise que Kitesurf n’accepte pas keep_alive dans la configuration Chrome DevTools MCP.

La même page des limites fixe une autre borne Free pour /crawl : cinq tâches de crawl par jour, avec un maximum de 100 pages par crawl. Un agent de recherche qui transforme une seule question en plusieurs crawls peut épuiser ce quota bien avant d’avoir consommé les 10 minutes de navigateur.

La façon de fermer les sessions influe elle aussi sur la capacité. Cloudflare avertit qu’une session laissée ouverte continue de consommer du temps de navigateur jusqu’à son expiration. Une fermeture explicite enregistre NormalClosure ; une expiration pour inactivité enregistre BrowserIdle. Placez browser.close() dans un bloc finally, puis contrôlez la raison de la fermeture au lieu de supposer que le code a correctement fait le ménage.

La règle de décision est simple : si la médiane mesurée reste inférieure ou égale à 60 secondes et que les limites de débit ne mettent pas le travail en file d’attente, un pilote de 10 tâches tient dans le quota. Sinon, réduisez le nombre de pages ou le périmètre de la tâche avant de payer pour déployer à plus grande échelle une boucle inefficace.

Prix Kitesurf : trois frontières de coût chez Cloudflare

Il n’existe pas un tarif Kitesurf unique, car Kitesurf, le compte Workers, l’usage de Browser Run et le modèle de raisonnement sont des services distincts. Les regrouper sous une seule ligne « agent gratuit » masque le premier poste qui fera réellement bouger la facture.

Le dépassement brut de temps de navigateur reste faible pour une tâche courte. Au tarif Browser Run publié, une fois les 10 heures Workers Paid incluses consommées, une tâche de 60 secondes coûte $0.0015 à raison de $0.09 par heure, avant la simultanéité, le temps de calcul Workers, l’usage du modèle ou les frais d’un SaaS tiers. Ces mêmes 10 heures incluses permettent d’exécuter 600 tâches de navigateur d’une minute si leur durée est uniforme.

Ce calcul ne doit pas devenir une promesse sur Kitesurf après la bêta. Cloudflare n’a publié aucun tarif propre à Kitesurf pour l’après-bêta, que ce soit dans la mise à jour, la documentation Kitesurf, la page tarifaire de Browser Run ou la page tarifaire de Workers. Le minimum Workers Paid de $5 achète l’accès à ce niveau de compte ; il ne garantit aucun futur prix Kitesurf.

Pour un acheteur, un budget lisible sépare le temps de navigateur, la simultanéité des sessions, Workers, le modèle et tout système payant utilisé par l’agent. Un moteur de navigateur gratuit peut parfaitement s’inscrire dans un workflow payant.

Kitesurf Browser Run : conséquences pour les équipes techniques, les Ops et les acheteurs

La plateforme est prête pour des tâches sans état et bien délimitées, pas pour remplacer Chromium dans tous les cas. Les conséquences varient selon le rôle.

Équipes techniques : choisir l’interface la plus légère qui termine la tâche

Commencez par une Quick Action lorsque le résultat attendu est une capture d’écran, le contenu d’une page, un PDF ou une extraction structurée. Ajoutez browser=kitesurf à l’endpoint, mesurez le temps de navigateur renvoyé et ne passez à une session complète que si la tâche exige de naviguer ou de conserver un état sur plusieurs actions.

WebMCP est séduisant lorsqu’un site compatible expose précisément l’action requise par votre agent. Une boucle visuelle fragile cède alors la place à un outil nommé. Il reste néanmoins indispensable de valider l’implémentation du site, ses règles d’autorisation et le résultat obtenu.

Lorsqu’une session destinée à un client approche de la production, associez le choix du moteur aux contrôles de Browser Run. Le guide consacré aux hôtes approuvés et à la revue client en lecture seule couvre la restriction des destinations qu’un simple choix de navigateur ne suffit pas à imposer.

Ops : mesurer séparément le travail normal et les échecs

Pour chaque catégorie de tâche, les équipes Ops doivent relever les millisecondes de navigateur, la raison de fermeture, le résultat de la requête et l’usage du modèle. Une extraction réussie et une page arrivée à expiration ne représentent pas la même charge. Les fondre dans une moyenne empêche de savoir si la correction doit porter sur le navigateur, le site ou la boucle de l’agent.

En cas d’échec, conservez les preuves avant de relancer une exécution. Le workflow d’inspection de Browser Run peut révéler la console, le réseau et l’état final de la page après une session enregistrée. Le guide de débogage d’une tâche en échec avant relance explique dans quels cas ces éléments valent davantage qu’un redémarrage immédiat.

Acheteurs : valider la compatibilité avant d’acheter de la capacité

Atteindre le compteur Free ne justifie pas, à lui seul, un changement d’offre. Vérifiez d’abord que Kitesurf affiche les sites cibles et termine correctement la tâche. Déterminez ensuite si le point de blocage vient du temps de navigateur quotidien, du débit de requêtes, de la simultanéité ou du modèle.

La documentation produit actuelle de Cloudflare permet de trancher entre les moteurs. Choisissez Kitesurf pour le rendu ponctuel, l’extraction et les charges d’agents sans état, exécutées en rafales sur des sites compatibles. Préférez Chromium si le workflow exige de la vidéo, WebGL, le franchissement d’un challenge anti-bot avec de véritables empreintes TLS ou une longue session authentifiée avec état persistant.

La décision peut être prise avant un déploiement généralisé : une tâche représentative, un ensemble de sites cibles, une distribution mesurée du temps de navigateur et un fallback explicite. Si ce fallback se déclenche souvent, le moteur plus léger ne réduit pas les coûts d’exploitation.

Qui doit agir maintenant, qui devrait attendre et qui n’est pas concerné ?

Agissez maintenant si vous gérez un workflow de support, de recherche ou de QA portant sur des pages publiques ou peu sensibles. Parmi les bons pilotes : capturer une page de centre d’aide, extraire une note de version, vérifier un composant rendu ou appeler un outil de recherche WebMCP sur un site compatible. Ces tâches sont courtes, auditables et faciles à comparer à un résultat connu.

Attendez si le workflow dépend d’un état de connexion persistant, de la vidéo, de WebGL, de la compatibilité avec un challenge anti-bot ou de la confirmation sans supervision d’actions WebMCP sensibles. Les sessions Kitesurf n’apparaissent pas dans wrangler browser list et ne proposent pas de vue en direct. Cloudflare précise qu’une session d’agent Kitesurf ne peut donc pas terminer un outil mis en pause dans l’attente d’une validation humaine ; cette interaction exige le playground manuel.

Attendez également avant de prendre un engagement budgétaire qui se prolonge au-delà de la bêta. Le navigateur est actuellement gratuit, mais aucun prix Kitesurf post-bêta n’a été publié pour établir un contrat long ou un devis client à marge fixe.

Vous êtes peu concerné si un workflow Chromium Browser Run stable atteint déjà ses objectifs de coût et de fiabilité. La version de septembre fournit un backend supplémentaire à évaluer ; elle n’impose pas de migrer un navigateur de production qui fonctionne.

Ce que la bêta gratuite fait croire à tort

Le mot « gratuit » porte trop de promesses lorsqu’il sert à décrire l’agent tout entier. Il concerne la disponibilité de Kitesurf en bêta, pas le modèle, le temps des opérateurs, le SaaS cible ni un futur tarif commercial.

WebMCP ne supprime pas non plus les pannes de navigateur. Cloudflare documente quatre lacunes importantes dans l’implémentation actuelle de Kitesurf : aucune politique d’autorisation ni aucun filtrage par origine pour les outils WebMCP, aucun outil provenant d’iframes ou de popups exposé via CDP, aucune live view des sessions Kitesurf et aucune confirmation côté agent pour les outils qui exigent l’intervention d’une personne. Une fonction nommée est plus fiable qu’un clic sur des pixels uniquement si la page expose et sécurise la bonne fonction.

Le moteur de rendu dans le terminal apporte de la visibilité, pas une stratégie de déploiement. Il aide les équipes techniques à voir ce que Kitesurf voit. Il ne modifie ni les minutes de navigateur, ni la simultanéité, ni le coût du modèle, ni la compatibilité des sites.

Les performances réclament la même retenue. Dans le benchmark médian de Cloudflare, mené sur cinq exécutions Quick Action et un corpus de 14 URL, Kitesurf a consommé 380 ms de CPU pour une capture d’écran, contre 1,173 ms pour Chromium en warm pool, et 57.8 MiB de mémoire, contre 271.0 MiB. Son temps réel était aussi plus lent : 1,148 ms contre 637 ms. Une consommation de ressources plus faible compte à grande échelle, mais ne signifie pas que chaque requête se termine plus vite.

Enfin, réussir plus de 730,000 sous-tests prouve la rapidité des progrès, pas une parité avec l’ensemble du web. Une matrice de compatibilité fondée sur vos sites cibles garde plus de valeur qu’un compteur de tests global.

À faire dès lundi : lancer un pilote bien délimité

La prochaine étape pertinente est un test de compte contrôlé, pas une migration d’architecture. Cette page n’a exécuté aucune requête Browser Run authentifiée : la séquence ci-dessous est donc un pilote reproductible, et non un benchmark présenté comme réalisé de première main.

1. 1

   Examiner l’interface publique

   Ouvrez le playground Kitesurf sur Cloudflare Radar. Dans DevTools, ouvrez Application > WebMCP et notez les outils que Cloudflare indique exposer sur Radar, notamment navigate-to et set-location. Leur présence ne prouve pas que votre site cible expose des outils équivalents.

2. 2

   Exécuter une tâche représentative

   Utilisez un compte de test existant pour une requête de contenu ou de capture d’écran. Le format de requête documenté par Cloudflare est le suivant :

   curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
     -H 'Authorization: Bearer <API_TOKEN>' \
     -H 'Content-Type: application/json' \
     -d '{"url":"https://example.com"}' \
     --output screenshot.png

   Commencez par une cible non sensible. Vérifiez que le résultat est correct avant de chercher à optimiser la vitesse.

3. 3

   Relever chaque poste de coût

   Consignez l’offre Workers, X-Browser-Ms-Used pour une Quick Action, l’usage de Browser Run, la raison de fermeture de la session et l’usage du modèle. Pour une Browser Session, fermez-la explicitement et confirmez NormalClosure plutôt que BrowserIdle.

4. 4

   Calculer le quota disponible

   Divisez 600 par le nombre mesuré de secondes de navigateur par tâche réussie, puis arrondissez à l’entier inférieur. Une journée de 10 tâches exige une moyenne mesurée inférieure ou égale à 60 secondes. Conservez la facture du modèle dans une colonne séparée, puis déterminez si le pilote tient dans Free, requiert une tâche plus ciblée ou justifie Workers Paid.

Cette exécution unique fournit les preuves qui manquent : la compatibilité, le temps de navigateur, le comportement à la fermeture et le coût du modèle pour une tâche que votre entreprise répétera réellement.

Pour recevoir la prochaine évolution de prix ou de limite touchant l’infrastructure des agents, accompagnée d’une décision opérationnelle concrète, inscrivez-vous à la newsletter.