Michael JohnsonChaque agent d’IA doit-il vraiment lancer un Chromium complet pour lire une page ou prendre une capture d’écran ? Le 12 novembre 2026, Cloudflare a publié le code source de Kitesurf, un moteur de navigateur expérimental destiné à ce type de tâches automatisées. Il peut être exécuté localement ou déployé dans son propre compte Cloudflare ; le compromis principal est une consommation plus faible de CPU et de mémoire, au prix d’une exécution plus lente et d’une compatibilité limitée avec les sites.
Pour les développeurs d’outils d’automatisation du navigateur, c’est une option intéressante : ils peuvent étudier et adapter le moteur tout en conservant l’interface familière Chrome DevTools Protocol (CDP). Mais avant de transférer tous leurs scénarios vers Kitesurf, ils devraient tester les pages visées. Dans la comparaison publiée par Cloudflare, Chromium terminait plus vite les tâches de test, et Kitesurf ne prend pas encore en charge certaines fonctionnalités importantes du Web.
Ce qui a changé le 12 novembre
Kitesurf a été présenté pour la première fois le 6 octobre 2026 comme composant de Browser Run, disponible en version bêta. À l’époque, Cloudflare avait décrit son architecture et les résultats de ses propres tests ; le 12 novembre, l’entreprise a publié le code sous licence Apache 2.0. Il est désormais possible d’étudier le moteur, de le compiler localement et de le déployer sur l’infrastructure de son compte. Cela élargit l’accès à son implémentation, mais ne fait pas pour autant de ce navigateur expérimental un remplaçant de Chromium.
Le projet peut être lancé de deux façons. Pour le développement local, il faut Node.js 22 ou une version ultérieure, pnpm 9.15.4 et Bazelisk ; les instructions du projet proposent de cloner le dépôt, d’installer les dépendances et de lancer la compilation avec pnpm run dev. Le déploiement sur Cloudflare nécessite un forfait Workers payant : le moteur utilise des Dynamic Workers pour isoler les pages. Pour l’hébergement autonome, il faut mettre en place une authentification séparée : Kitesurf n’en intègre pas, et l’adresse publique d’un Worker pourrait permettre à des tiers d’utiliser la puissance de calcul et les requêtes sortantes de votre compte.
Comment le navigateur se passe de Chromium
Un navigateur headless classique lance un moteur volumineux conçu pour les sites Web et les interfaces utilisateur. Kitesurf assemble les fonctionnalités nécessaires à l’automatisation à partir de plusieurs composants Workers : l’un accepte les connexions CDP et conserve l’état de la session, des processus isolés distincts traitent la page, et un autre se charge du rendu. Pour interagir avec les outils de développement, Kitesurf prend en charge CDP ; des clients compatibles comme Puppeteer peuvent donc s’y connecter.
Les composants en Rust traitent le HTML et le CSS, le JavaScript de la page s’exécute dans un environnement Workers isolé et un moteur de rendu distinct produit l’image. Cloudflare décrit le routage des requêtes réseau par un composant dédié : il charge les ressources du site, applique les règles réseau et conserve les cookies des pages séparément. L’isolation fait ici partie intégrante de l’architecture du navigateur : les agents doivent ouvrir des sites arbitraires contenant du code auquel il ne faut pas accorder sa confiance par défaut.
Cette architecture correspond à une charge de travail du type « lancer une tâche — traiter une page — terminer ». Si le moteur de rendu se bloque, il est possible de l’arrêter puis d’en créer un nouveau : l’état de la page n’y est pas conservé. Cette approche pourrait être plus pratique pour les pics d’automatisation que des processus lourds fonctionnant en permanence. Il s’agit d’une motivation architecturale du projet, et non d’une garantie d’économies précises dans tous les systèmes.
Pourquoi la consommation diminue
Dans une comparaison publiée précédemment, Cloudflare a utilisé les médianes de cinq exécutions de Browser Run sur un ensemble de 14 URL. Pour la capture d’écran, Kitesurf consommait 57,8 Mio de mémoire, contre 271 Mio pour un pool Chromium préchauffé ; pour l’extraction du HTML, les chiffres étaient de 39,4 Mio contre 273,7 Mio. Ces résultats décrivent une configuration et un ensemble de pages spécifiques à l’entreprise. Il faut donc les considérer comme une mesure d’un type de charge de travail, et non comme un coefficient universel applicable à tous les sites.
Pour ces mêmes tâches, Chromium était plus rapide : la capture d’écran prenait 637 ms contre 1 148 ms avec Kitesurf, et l’extraction du HTML 472 ms contre 820 ms. Autrement dit, l’avantage de Kitesurf porte avant tout sur la consommation de ressources, et non sur la rapidité de réponse. Pour une collecte de pages à grande échelle et de courte durée, la mémoire peut compter davantage qu’un délai de quelques secondes ; pour un agent interactif qui doit réagir rapidement, la différence de temps peut l’emporter. Cloudflare a publié la méthodologie et les résultats de ces mesures.
Quand choisir Kitesurf plutôt que Chromium
Kitesurf convient aux tâches ponctuelles : récupérer du HTML, construire le DOM, prendre une capture ou générer un PDF sur un site compatible. Sa compatibilité CDP permet de tester cette solution de remplacement dans une pile d’automatisation existante, et son code source donne la possibilité d’étudier son fonctionnement et ses conditions de déploiement. Pour une petite expérimentation, on peut commencer par une compilation locale ; pour l’exécuter sur Cloudflare, il faut prévoir un forfait payant et protéger l’instance par une authentification.
Pour un site utilisant la vidéo ou WebGL, une session authentifiée de longue durée, une interaction fiable avec des protections anti-bots ou un rendu précis des pages, la documentation de Cloudflare recommande le navigateur standard de Browser Run, basé sur Chromium. Kitesurf ne prend pas encore en charge la lecture vidéo, WebGL ni les longues sessions avec conservation de l’état ; la prise en charge des standards et la qualité du rendu continuent d’être améliorées.
Il existe aussi une différence importante entre le respect des standards et la compatibilité réelle. Les tests Web Platform Tests vérifient des exigences spécifiques des standards du Web, mais ne permettent pas de savoir si un site complexe donné se chargera ou si l’agent pourra y exécuter correctement une séquence d’actions. En pratique, il faut tester les pages et les scénarios visés en comparant les résultats à ceux de Chromium, plutôt que de déduire la compatibilité du nombre global de tests réussis.
Conclusion pratique pour les équipes
Considérez Kitesurf comme une option spécialisée pour exécuter des tâches dans un navigateur. Commencez par sélectionner quelques pages réelles et mesurez trois éléments : l’exactitude des données extraites ou des captures, le temps d’exécution et la consommation de ressources. Vérifiez ensuite séparément l’authentification, les restrictions réseau et le comportement des sessions. Si la tâche est courte, le site compatible et la mémoire ainsi que le CPU plus importants que la latence, Kitesurf mérite un essai. Si le rendu précis, les fonctionnalités avancées du Web ou la persistance de l’état sont essentiels, Chromium reste un meilleur point de départ.
La publication du code source ne change pas le choix entre un moteur léger et spécialisé et un navigateur complet ; elle permet plutôt d’examiner et de déployer soi-même la première option. Les équipes peuvent désormais l’évaluer plus facilement sur leurs propres pages et leur infrastructure, au lieu de s’appuyer uniquement sur les tableaux du fournisseur.
