Kitesurf : Cloudflare lance un navigateur conçu pour les agents IA, sans Chromium

Le vrai problème : Chromium est trop cher pour les agents

Les navigateurs modernes ont été conçus pour des humains. Onglets, extensions, synchronisation, rendu pixel-perfect à 60 fps — autant de fonctionnalités dont un agent IA n'a aucun usage, mais qui consomment de la mémoire et du CPU en permanence.

Cloudflare l'énonce clairement dans son annonce : fournir à chaque agent une instance Chromium complète est « prohibitivement coûteux », ce qui réserve l'accès au web aux seuls modèles les plus puissants et les plus chers. Les applications agentiques plus modestes sont de facto exclues de larges pans du web.

C'est la tension que Kitesurf cherche à résoudre : un navigateur qui abandonne ce qui ne sert qu'aux humains (fidélité visuelle, gestion d'onglets, CSS parfait) pour prioriser ce qui compte pour un modèle — nombre de tokens, fenêtres de contexte, scalabilité, performance et coût. La question du modèle de menace change aussi : les priorités deviennent la résistance à l'injection de prompts et la sécurité des outils, pas la protection de la vie privée de l'utilisateur.

Architecture : trois composants, deux principes

L'architecture de Kitesurf repose sur deux partis pris structurants : isolation maximale et statelessness par défaut.

Chaque chargement de page est traité comme une entrée non fiable, chaque session repart de zéro. Un composant stateless est, par nature, jetable et parallélisable : on peut en lancer mille simultanément, le tuer s'il cale, et ne payer que ce qu'il consomme effectivement.

Les trois composants principaux :

Engine

Le seul composant exposé publiquement. Il gère la WebSocket CDP et les API HTTP REST, et stocke l'état de session — c'est le seul composant qui ne soit pas stateless. Son atout principal : la compatibilité CDP. Pointer Puppeteer, Playwright ou chrome-remote-interface sur Kitesurf fonctionne sans adaptation, ce qui est aussi la base de Browser Run.

PageScript

C'est là que réside la complexité. Chaque page ou iframe hors-process (OOPIF) fait tourner un isolate PageScript dédié via Dynamic Workers — une primitive Workers relativement récente sans laquelle Kitesurf n'aurait pas été possible selon l'équipe. L'isolate reçoit un globalThis propre et un objet DOM, peuplé par le parsing HTML/CSS et l'exécution des scripts trouvés dans la page.

Pour le parsing HTML et CSS, Kitesurf utilise des composants de Blitz (moteur de rendu modulaire) et Stylo, le parser CSS haute performance de Firefox — tous deux écrits en Rust et compilés en Wasm via wasm-bindgen, sans passer par Emscripten.

Le cas des eval() mérite un aparté : Workers ne supporte pas nativement eval pour des raisons de sécurité, et ouvrir un second isolate ne fonctionnerait pas (pas d'accès au globalThis partagé). La solution retenue est d'embarquer Boa JS, un moteur ECMAScript écrit en Rust, qui tourne donc à l'intérieur de l'isolate V8 — un runtime dans un runtime. L'équipe reconnaît que ce n'est pas optimal, mais que ça couvre les eval occasionnels rencontrés en production. Une migration vers le support natif est prévue quand Workers le permettra.

PageRenderer

Ce composant génère les pixels à partir des objets de page calculés. Il tourne en boucle avec l'Engine : à chaque demande de frame, il récupère la scène depuis PageScript, charge les polices et images depuis Static Assets, rastérise le tout dans un buffer, et retourne le résultat au format JPEG, PNG ou PDF.

SandboxOutbound : le seul chemin réseau

Aucun composant ne peut toucher le réseau directement — tout passe par un worker dédié, SandboxOutbound, rendu exclusif grâce aux Dynamic Workers. C'est lui qui applique le CORS, injecte les headers navigateur, filtre les réponses et gère les jars de cookies par page. Tout ce qui ne passe pas la politique reçoit un 403.

Comment Cloudflare a construit ça en 12 semaines

L'équipe revendique 12 semaines de développement, avec un usage intensif d'agents IA pour accélérer. La clé méthodologique : fournir aux agents une masse de tests comme critères de succès objectifs.

Deux niveaux de tests ont été mis en place. D'abord les Web Platform Tests (WPT) du W3C, qui mesurent la conformité aux standards et fournissent aux agents des jalons clairs. Ensuite, une couche de tests d'intégration et de régression visuelle : des scénarios Puppeteer multi-étapes tournant en parallèle sur Chromium et Kitesurf, comparant les assertions et les rendus visuels à chaque étape.

Le point de départ a été obscura, un moteur headless open source écrit en Rust, sans Chrome ni Node.js, que l'équipe a tenté de porter sur Workers avec l'aide d'un agent IA. Le résultat initial était imparfait, mais suffisant pour valider la direction.

À vérifier avant d'adopter

Kitesurf est en bêta, disponible gratuitement dans Browser Run. Quelques questions restent ouvertes à ce stade que l'annonce n'aborde pas :

• Couverture de rendu réelle : les tests WPT mesurent la conformité aux standards, pas le comportement sur des sites de production complexes (SPAs lourdes, rendu côté client avancé). L'équipe mentionne des tests visuels sur des sites réels, mais sans préciser le périmètre ni les taux d'échec observés.
• Support JavaScript complet : le recours à Boa JS pour les eval est explicitement présenté comme une solution temporaire non optimale. L'impact sur des applications qui en font un usage intensif n'est pas documenté dans l'annonce.
• Modèle de tarification post-bêta : aucune indication sur ce que deviendra la tarification une fois la bêta terminée.
• Nouveaux vecteurs d'attaque : l'annonce mentionne l'injection de prompts et la sécurité des outils comme priorités, sans détailler les mécanismes de protection en place.

La documentation et les détails d'accès sont disponibles via Browser Run sur le Developer Platform de Cloudflare.