Cloudflare a ouvert le code de Kitesurf, un navigateur conçu pour les agents IA, sous licence Apache 2.0. Le code est hébergé sur GitHub et la page du projet est kitesurf.dev. Ce navigateur s’exécute sur Cloudflare Workers, sans conteneur de navigateur, tout en analysant le HTML, en traitant le CSS et en exécutant du JavaScript.
L’objectif affiché par Cloudflare est limpide :
"Our main goal is to give AI agents a lightweight, efficient browser — one that can load websites, execute JavaScript, and interact with pages while using less CPU and memory than a full browser like Chromium."
Autrement dit : offrir aux agents un navigateur léger, capable d’ouvrir des pages web, d’exécuter des scripts et d’interagir avec les pages, pour une consommation de CPU et de mémoire inférieure à celle de navigateurs complets comme Chromium.
De l’expérience de portage à l’open source : trois étapes
Le point de départ de Kitesurf est obscura, un moteur headless open source écrit en Rust, qui se présente comme « sans Chrome, sans Node.js, sans dépendances ». L’équipe de Cloudflare a d’abord demandé à un agent IA de le porter sur Workers, avec de mauvais résultats au début ; ce n’est qu’après avoir rédigé pour l’agent un plan détaillé et des critères de réussite que le prototype a fini par fonctionner, tant bien que mal.
D’après le blog de Cloudflare, il s’est écoulé 12 semaines entre la décision de se lancer et la sortie officielle. Lors de sa première apparition, Kitesurf a été intégré à Browser Run, le service d’automatisation de navigateurs headless de Cloudflare, sous forme de bêta gratuite ; les développeurs pouvaient basculer en ajoutant le paramètre browser=kitesurf à l’API. Cloudflare avait alors promis d’« ouvrir le code quand il sera prêt » et, selon certains articles, le billet ne donnait aucun calendrier. L’ouverture que rapporte aujourd’hui Phoronix tient cette promesse.
Côté méthode, l’équipe a utilisé les Web Platform Tests (la suite de tests de conformité du W3C) comme critère de validation pour l’agent IA, tandis que les humains se chargeaient de l’architecture et de la relecture. À la publication du blog, Kitesurf passait environ 215 000 tests, avec quelques centaines de plus chaque semaine. Pour combler l’écart entre les tests standardisés et les sites réels, l’équipe a aussi fait tourner Chromium et Kitesurf côte à côte avec Puppeteer sur de vrais sites, en comparant pas à pas les assertions et les captures rendues.

Comment il est découpé en interne
Kitesurf se divise en trois blocs :
- Engine : le seul composant exposé vers l’extérieur ; il gère le protocole Chrome DevTools (CDP) et conserve l’état de session. Des clients comme Puppeteer ou Playwright fonctionnent en le pointant simplement.
- PageScript : chaque page s’exécute dans un isolat Workers dédié ; l’analyse du HTML et du CSS s’appuie sur un module du moteur de rendu Blitz, écrit en Rust, et sur Stylo de Firefox ; en présence d’un
eval, que Workers ne prend pas en charge nativement, l’exécution est confiée au moteur JS Boa, lui aussi écrit en Rust. - PageRenderer : dessine l’objet de la page en pixels et produit du JPEG, du PNG ou du PDF, sans conserver d’état de page ; s’il se bloque, il est simplement tué puis relancé.
Toutes les requêtes vers le réseau externe passent par un unique composant, SandboxOutbound, et les cookies de chaque page sont rangés dans un « bocal » à part. L’hypothèse de conception de Cloudflare est de considérer chaque chargement comme une entrée non fiable et de faire démarrer chaque session à vide, afin de répondre aux risques propres aux agents, comme l’injection de prompt et la sécurité des appels d’outils.
Le calcul par la mémoire : combien de sessions par machine
Cloudflare a lancé 5 passes sur chacune de 14 adresses web et retenu la médiane. Pour l’extraction de HTML, Kitesurf occupe 39,4 MiB de mémoire contre 273,7 MiB pour le pool Chromium préchauffé, soit un écart de 7 fois ; pour la capture d’écran, l’écart est de 4,7 fois.
D’après les chiffres de la capture d’écran, un calcul grossier donne environ 17 sessions Kitesurf pour 1 GiB de mémoire, contre seulement 3 à 4 avec Chromium. Un déploiement réel doit encore tenir compte de la charge d’ordonnancement et des pics ; ce ratio est donc à lire comme un plafond. Cloudflare souligne elle-même que la mémoire et le CPU déterminent la facture ; en temps réel, Chromium est 1,7 à 1,8 fois plus rapide, l’écart venant surtout de la rastérisation et de l’encodage des images, et des optimisations sont prévues.
Les limites sont elles aussi énoncées clairement : pour l’instant, Kitesurf ne sait pas lire de vidéo, ne rend pas le WebGL et n’utilise pas d’empreinte TLS réelle pour passer les contrôles anti-bots. Parmi les pages que Cloudflare indique comme correctement rendues figurent Wikipédia, Hacker News et TodoMVC dans plusieurs versions de frameworks. Pour les développeurs en Chine, l’ouverture du code permet de le déployer dans son propre compte Workers, sans passer par les quotas de Browser Run, mais la compatibilité avec les sites complexes reste à tester soi-même.
Sources : blog officiel de Cloudflare, Phoronix, CocoLoop, H2S Media ; les médianes de CPU, de mémoire et de durée sur le jeu de test de 14 adresses ainsi que le nombre de tests WPT réussis ont été vérifiés auprès du blog de Cloudflare.