Cloudflare publie en open source le moteur de navigateur Kitesurf pour les agents d’IA

Cloudflare a annoncé le 13 novembre 2026 que Kitesurf, son moteur de navigateur expérimental pour les agents d’IA, était désormais disponible en open source sous licence Apache 2.0. Les développeurs peuvent consulter et modifier le code, l’exécuter localement ou déployer leur propre instance sur Cloudflare Workers.

Le dépôt public permet aux développeurs d’exploiter et de modifier le moteur dans leurs propres comptes Cloudflare, plutôt que de dépendre uniquement des API gérées de Browser Run. Cloudflare avait annoncé cette étape lors de la présentation de Kitesurf, le 6 août 2026, puis de nouveau dans une mise à jour du 28 septembre 2026, qui ajoutait la prise en charge de WebMCP, élargissait la couverture des API de navigateur et de Browser Run, et introduisait le rendu de terminal.

Dans les coulisses de la conception de Kitesurf pour les agents

Kitesurf transforme le HTML et le CSS en pages affichées, exécute le JavaScript des pages et produit des captures d’écran, sans Chrome ni conteneur de navigateur. Il expose un point de terminaison Chrome DevTools Protocol (CDP), l’interface de contrôle utilisée par Chrome DevTools et les logiciels d’automatisation compatibles, auquel peuvent se connecter les clients Puppeteer et les environnements d’exécution pour agents d’IA.

En interne, le moteur coordonne les sessions de navigateur et les connexions clientes, PageScript exécute la page et son JavaScript, et PageRenderer produit le rendu visuel. La plateforme de développement de Cloudflare s’associe à des composants Rust compilés en WebAssembly : Blitz assure l’analyse du HTML, la gestion du DOM, la mise en page et le dessin ; Stylo gère le CSS ; les bibliothèques Linebender prennent en charge le texte et les graphiques 2D ; et Krilla produit les fichiers PDF. Boa fournit un moteur d’exécution JavaScript de secours dans WebAssembly lorsque le code de la page ne peut pas s’exécuter dans Dynamic Workers.

Cloudflare indique que son objectif est de donner aux agents l’accès au Web dont ils ont besoin, en consommant moins de ressources processeur et mémoire qu’un navigateur Chromium complet, tout en adaptant les capacités à la demande sur son réseau Workers. L’architecture initiale considère chaque chargement de page comme une entrée non fiable et isole les composants en fonction des ressources dont ils ont besoin. Un worker SandboxOutbound dédié gère toutes les requêtes vers des ressources externes, applique la politique réseau et maintient séparés les cookies de chaque page ; les autres composants ne peuvent pas accéder directement au réseau.

L’absence d’état est un autre élément de cette conception. Le moteur conserve l’état des sessions, tandis que les autres composants sont supprimables dans la mesure du possible, ce qui permet d’adapter les capacités aux pics d’activité des agents. PageRenderer ne conserve aucun état persistant des pages ; le moteur peut donc le remplacer après l’échec ou le blocage d’une requête de rendu.

Exigences et sécurité de l’hébergement sur sa propre infrastructure

Le développement local nécessite Bazelisk, Node.js 22 ou une version ultérieure, ainsi que pnpm 9.15.4. La commande de développement compile les modules WebAssembly et les bundles de la page et du moteur de rendu, puis lance un moteur local à l’adresse 127.0.0.1:8787. La compilation initiale compile le cœur Rust et les dépendances intégrées au dépôt, tandis que les compilations suivantes réutilisent le cache de Bazel. Les développeurs peuvent ensuite examiner les pages avec Chrome DevTools ou connecter Puppeteer et d’autres clients CDP.

Le déploiement sur Cloudflare nécessite une offre Workers payante, car Dynamic Workers créent les workers isolés utilisés pour les pages et les moteurs de rendu. Après avoir effectué des tests localement, les opérateurs peuvent déployer le moteur dans leur propre compte, plutôt que d’utiliser les API gérées de Browser Run.

L’hébergement sur sa propre infrastructure implique également une importante responsabilité en matière de sécurité. Le moteur n’intègre pas de système d’authentification, et son adresse workers.dev est publique par défaut. Sans Cloudflare Access ni autre couche d’authentification, toute personne disposant de l’URL pourrait naviguer sur le Web via le moteur, connecter des clients CDP, envoyer des requêtes depuis le compte Cloudflare de l’opérateur et consommer du temps processeur payant ainsi que des ressources Dynamic Workers. Le dépôt demande aux opérateurs de protéger immédiatement l’URL et explique comment activer Access sur l’ensemble du compte avant le déploiement afin d’éviter toute période d’exposition publique.

Statut expérimental et processus de contribution

Kitesurf reste expérimental et fait l’objet d’un développement intensif. Le dépôt le présente comme un point de terminaison CDP plutôt que comme une implémentation complète de Chrome ; certaines fonctionnalités de Chrome DevTools ne sont toujours pas prises en charge. Cloudflare donne la priorité à la compatibilité, à la fiabilité et à l’efficacité.

Lors du lancement en août, Cloudflare a indiqué que Kitesurf n’était pas encore adapté à la vidéo, à WebGL, aux échanges de validation anti-bot nécessitant de véritables empreintes TLS, ni aux longues sessions authentifiées reposant sur un état persistant. Ces limites montrent quelles vérifications de compatibilité restent importantes pour les charges de travail des agents, même lorsqu’un navigateur plus léger est intéressant par sa consommation de ressources.

Le processus de contribution est organisé autour de ces travaux en cours. Cloudflare demande aux personnes souhaitant contribuer de créer un ticket présentant un cas de reproduction minimal ou une approche proposée, puis d’obtenir l’appui d’un responsable de maintenance avant de soumettre une demande de fusion. Les modifications ciblées, accompagnées de tests et dont la portée est clairement définie, sont privilégiées ; les bogues de rendu reproductibles, les flux d’automatisation qui échouent et les corrections de documentation sont également les bienvenus.

Pour les développeurs, le compromis consiste à prendre directement le contrôle de la pile de navigation, en contrepartie de la sécurisation du déploiement par leurs propres moyens et de la nécessité de composer avec un moteur dont la compatibilité avec Chrome et les standards du Web reste incomplète.