Le 6 août 2026, Cloudflare a publié Kitesurf — un navigateur conçu non pas pour les humains, mais pour les agents. À l'intérieur, il n'y a pas de Chromium : le moteur est construit sur Rust, compilé en WebAssembly et fonctionne entièrement dans des isolats V8 sur Workers. La société affirme qu'il consomme de 3 à 7 fois moins de CPU et de mémoire sur des tâches typiques d'agents que Chromium. Quatre mois auparavant, l'open source Obscura — également en Rust, également « pour les agents » — avait recueilli plus de 22 000 étoiles sur GitHub, et Cloudflare a reconnu que le premier prototype de Kitesurf était un port d'Obscura sur Workers.
Le marché des moteurs d'automatisation est divisé : d'un côté, des runtimes légers pour agents qui économisent des ressources ; de l'autre, des versions lourdes de Chromium qui peuvent tout faire, y compris passer des vérifications anti-bot. Analysons les faits pour voir ce que chaque classe offre réellement et où s'arrête l'économie.
Quels critères utiliser pour comparer
Les benchmarks des moteurs aiment se mesurer en vitesse et en mémoire, mais pour le scraping en conditions réelles et les agents, quatre axes indépendants sont importants, et un gain sur le premier ne dit rien des autres :
- Coût de lancement — CPU et mémoire par page. C'est ce qui se traduit directement par la facture d'infrastructure lors de milliers de sessions parallèles.
- Complétude de la plateforme web — combien de sites modernes s'affichent correctement. Ici, on mesure la couverture des Web Platform Tests (WPT).
- Passage des vérifications anti-bot — la session survivra-t-elle à la poignée de main TLS, au défi JS et à la vérification comportementale.
- Contrôle de la sortie réseau — pouvez-vous gérer depuis quelle IP et quel ASN le site voit la requête.
Kitesurf : économie contre complétude
Kitesurf est construit à partir de modules : rendu et analyse HTML/CSS sur Blitz, moteur CSS Stylo de Firefox, runtime JS Boa en Rust, mise en forme du texte via Parley. Selon la société, le développement a pris 12 semaines.
Les chiffres du benchmark interne de Cloudflare contre Chromium :
- CPU pour la capture d'écran — 380 ms contre 1173 ms (3,1 fois moins) ;
- CPU pour l'extraction HTML — 229 ms contre 877 ms (3,8 fois moins) ;
- mémoire pour la capture d'écran — 57,8 MiB contre 271 MiB (4,7 fois moins) ;
- mémoire pour l'extraction HTML — 39,4 MiB contre 273,7 MiB (7 fois moins) ;
- mais en termes de temps d'exécution, Kitesurf est plus lent : 1148 ms contre 637 ms pour la capture d'écran et 820 ms contre 472 ms pour l'HTML — de 1,7 à 1,8 fois.
C'est un échange honnête : vous payez en latence, mais vous obtenez la possibilité de maintenir beaucoup plus de sessions parallèles sur une seule machine. Selon les normes web, le moteur se défend bien pour son âge — au moment de l'annonce, environ 215 000 sous-tests WPT réussis, et la documentation indique maintenant plus de 235 000. Couverture par sections : DOM 97 %, HTML 96 %, Selection 99 %, SVG 97 %, Encoding 99 %, CORS 95 %, XHR 95 %, URL 83 %. Wikipédia, Hacker News et des SPA typiques s'affichent correctement.
Kitesurf se connecte de manière habituelle : point de terminaison CDP (ce qui signifie Puppeteer et Playwright), MCP pour les agents, points de terminaison REST Quick Actions pour la capture d'écran et l'extraction HTML. Il suffit d'ajouter le paramètre browser=kitesurf. La version bêta est gratuite, mais avec des limites par compte ; les sources sont promises à l'ouverture.
Ce que Kitesurf ne peut pas faire — et c'est écrit dans sa propre documentation
La liste des limitations est courte, mais elle couvre toute la ligne de défense des sites modernes. Kitesurf ne prend pas en charge :
- la lecture de vidéos ;
- le rendu WebGL ;
- la poignée de main du défi bot avec de véritables empreintes TLS ;
- les longues sessions authentifiées nécessitant un état constant.
Le troisième point est clé. Cloudflare écrit elle-même : si la tâche se heurte à un défi bot, utilisez le Chromium classique dans Browser Run. Cela signifie que la société qui impose ces défis sur des millions de sites avertit honnêtement que son propre navigateur léger ne les passe pas. Ce n'est pas un défaut de la bêta, mais une conséquence de l'architecture : l'empreinte TLS (JA3/JA4) naît dans la pile réseau, et non dans le moteur de rendu, et le moteur Rust dans l'isolat Workers se comporte physiquement différemment de Chrome.
L'effet secondaire d'un moteur non standard est l'unicité. Les scripts anti-bot ont été calibrés pendant des années sur les artefacts de Chromium : l'ordre des propriétés, la spécificité des erreurs, les timings API. Un moteur qui n'a pas ces artefacts n'a pas l'air « plus propre » — il a l'air différent, et « différent » dans le scoring anti-bot coûte plus cher que « comme tout le monde ». Nous avons déjà examiné cet effet dans notre revue des navigateurs furtifs de 2026 : les benchmarks sur la propreté de l'empreinte JS et les résultats sur des cibles réelles divergent, car les cibles réelles prennent en compte un ensemble de signaux.
Obscura : la même classe, mais sur votre serveur
Obscura est le représentant open source principal de la classe. Le dépôt a été créé le 13 avril 2026, sous licence Apache-2.0, et à la fin août, il avait plus de 22 000 étoiles. À l'intérieur, un véritable V8, à l'extérieur — CDP, donc aussi un remplacement drop-in pour headless Chrome pour Puppeteer et Playwright.
La décision architecturale clé : Obscura n'a pas de pipeline de mise en page et de rendu, il ne dessine pas d'image du tout. D'où les chiffres du benchmark de l'auteur — la médiane sur 33 scénarios donne environ 21 fois la vitesse et environ un septième de la mémoire par rapport à headless Chrome. Sur un chargement continu de pages React dans quatre workers, cela donne 40 pages par seconde avec 112 Mo de mémoire contre 3 pages par seconde avec 4,2 Go pour Chrome. Couverture WPT sur le « noyau » (DOM, HTML, URL, fetch) — 83,3 %, soit 318 916 sous-tests sur 382 891.
La différence pratique avec Kitesurf ne réside pas dans la vitesse, mais dans l'endroit où tout cela tourne. Vous déployez Obscura vous-même — et vous décidez vous-même par quelle sortie réseau il passe. Kitesurf vit dans le réseau d'autrui, et cela nous amène au point principal.
Qui possède votre IP sortante
Tout le monde a parlé de l'économie de CPU, mais presque personne n'a abordé la sortie réseau. Pourtant, Kitesurf s'exécute sur Workers, ce qui signifie que les requêtes sortent du réseau Cloudflare, avec son ASN. Il n'y a pas de gestion de l'IP sortante ou de connexion à un proxy personnel dans la documentation de Kitesurf. Les développeurs de Browser Rendering voisin rencontrent le même problème : tenter de définir un proxy en amont via proxyServer dans BrowserContext échoue avec net::ERR_PROXY_CONNECTION_FAILED, et les adresses egress fixes pour Workers ne sont pas prévues par défaut.
Pour le scénario cible de Cloudflare, cela est normal : l'agent navigue sur des pages ouvertes, prend des captures d'écran, extrait du HTML. Mais dès que la cible est un peu protégée, vous obtenez la pire des combinaisons possibles de signaux :
- L'IP appartient à un grand ASN cloud, donc elle est déjà marquée comme serveur ;
- L'empreinte TLS ne correspond à aucun vrai navigateur ;
- vous ne pouvez pas remplacer l'un ou l'autre, car vous ne contrôlez ni la pile réseau ni la sortie.
Cette situation explique pourquoi la discussion sur les agents en 2026 se concentre de plus en plus non pas sur l'optimisation du runtime, mais sur la question de l'accès légal et payé — des agents signés aux requêtes payantes, comme nous l'avons écrit dans notre analyse des portefeuilles pour bots et HTTP 402. Si un site ne vous laisse pas entrer, le moteur le plus économique du monde ne vous aidera pas : vous ne pouvez tout simplement pas obtenir une page que l'on ne vous a pas donnée.
Que choisir selon la tâche
Kitesurf — lorsque les cibles sont ouvertes et nombreuses : surveillance de pages publiques, extraction de HTML pour l'index RAG, captures d'écran massives, contournements de documentation par agents à bas coût. De plus, une bêta gratuite et aucune gestion d'infrastructure. Ne l'utilisez pas là où il y a un login, un anti-bot ou une exigence géographique spécifique.
Obscura — le même profil de charge, mais lorsque le contrôle est nécessaire : votre hébergement, votre sortie réseau, vos correctifs. Convient comme cheval de bataille pour un parc de parsing où le coût de la page est important, mais l'apparence de la page ne l'est pas du tout. Fonctionne bien avec des proxies, car vous gérez le processus dans son ensemble.
Chromium classique sous Playwright ou Puppeteer — lorsque des vidéos, WebGL, des sessions authentifiées complexes et un véritable rendu sont nécessaires. Coûteux en ressources, mais prévisible.
Versions furtives de Chromium (Camoufox, nodriver, patchright, et parmi les plus récents — CloakBrowser, qui a obtenu plus de 30 000 étoiles depuis février 2026) — lorsque la cible est protégée et qu'il n'y a pas d'autres options. Les ressources sont légèrement supérieures à celles de Chromium classique, mais l'essentiel est préservé : une véritable pile réseau, dans laquelle vous pouvez insérer la sortie souhaitée.
Et le dénominateur commun pour les trois dernières options : le moteur détermine comment vous apparaissez au niveau du navigateur, et les proxies résidentiels déterminent comment vous apparaissez au niveau du réseau. Pour des cibles ouvertes et des tâches internes, des adresses serveur suffisent — elles sont moins chères et plus rapides. Pour des sites avec une véritable protection, le coût de la page est calculé non pas en mégaoctets de mémoire, mais en pourcentage de réponses réussies.
Conclusion
Kitesurf et Obscura sont une réponse honnête et, à en juger par les chiffres, réussie à une véritable douleur : faire tourner Chromium pour extraire du HTML est vraiment gaspilleur, et le rapport d'Apify et du Web Scraping Club le confirme — 65,8 % des spécialistes en 2025 ont utilisé plus de proxies que l'année précédente, et 58,3 % ont augmenté leur budget pour cela. Les dépenses en automatisation augmentent, et une économie de 3 à 7 fois en mémoire est un argument de poids.
Mais l'économie fonctionne jusqu'à la première cible protégée. Un moteur léger ne passe pas le défi bot — c'est écrit dans la documentation de Cloudflare elle-même. Le runtime cloud ne permet pas de gérer l'IP sortante. Ainsi, la pile d'agents de 2026 se compose de deux couches indépendantes : un moteur économique pour des pages ouvertes en masse et un véritable navigateur avec une sortie réseau contrôlée pour tout le reste. Tenter de couvrir les deux couches avec un seul outil se termine soit par un surcoût pour Chromium là où Rust suffirait, soit par une conversion nulle du parser là où l'IP manquait.
```