Kitesurf et Obscura : à qui appartient le navigateur IA ?

Lorsqu’on parle aujourd’hui de navigateur IA, beaucoup pensent d’abord à un navigateur ordinaire doté d’une fenêtre de chat. Une IA résume les onglets, répond aux questions ou remplit un formulaire. Une seconde catégorie est pourtant plus intéressante techniquement : des moteurs de navigateur qui ne sont plus conçus pour des humains. Ils fonctionnent sans fenêtre visible, sont pilotés par API et peuvent n’exister que le temps d’une seule tâche.

Dans mon article sur WebMCP et le Web agentique, je traitais des sites qui proposent des fonctions structurées aux agents. Kitesurf et Obscura abordent l’autre face du problème. Tant que la majeure partie du Web ne dispose pas d’interface pour agents, les systèmes IA ont toujours besoin d’un moteur capable de lire et manipuler des pages ordinaires.

C’est précisément là que Cloudflare positionne Kitesurf. Ce nouveau navigateur s’exécute sur Cloudflare Workers, parle le Chrome DevTools Protocol et doit fournir des pages Web aux agents à un coût nettement inférieur à celui d’un processus Chromium complet. Son architecture n’est pas son seul intérêt. Cloudflare indique elle-même que le premier prototype s’inspirait d’Obscura, un navigateur indépendant et open source écrit en Rust.

Obscura poursuit toutefois un autre objectif. Son mode stealth facultatif tente de masquer les caractéristiques typiques des navigateurs automatisés. Kitesurf ne le fait pas. Au contraire, Browser Run marque volontairement les requêtes sortantes afin que les exploitants puissent les reconnaître comme une automatisation Cloudflare et les vérifier cryptographiquement.

Une question dérangeante se pose donc. Cloudflare a-t-elle repris une bonne idée open source, supprimé la partie gênante pour la détection des bots et préféré en faire son propre produit contrôlable ?

Réponse courte : la critique vise en partie un véritable conflit d’intérêts. Mais rien ne prouve encore qu’il explique la naissance de Kitesurf. Sur les plans technique et stratégique, il se passe davantage qu’une copie assainie d’Obscura.

Base de l’analyse et limites

Cette analyse repose sur l’article de Cloudflare du 6 août 2026, la documentation actuelle de Browser Run et l’examen du code et de la documentation du dépôt public d’Obscura le 25 août 2026. La version alors actuelle, Obscura 0.2.1, était parue deux jours auparavant. J’ai notamment étudié l’architecture, les chemins réseau, l’implémentation stealth, les avertissements de sécurité, les notes de version et le dépôt de benchmarks distinct.

Je n’ai effectué ni mesures de performance face à Kitesurf, ni tests contre des challenges antibot en production. Les affirmations sur la qualité de détection proviennent donc de l’implémentation, des limites documentées et des benchmarks publiés par les fabricants. Toute intention stratégique prêtée à Cloudflare à partir de ces éléments est explicitement une interprétation, pas une déclaration confirmée de l’entreprise.

Ce qu’un navigateur IA doit accomplir techniquement

Un navigateur classique est une immense machine universelle. Il rend du CSS complexe, lit des médias, accélère les graphiques par GPU, gère les extensions, synchronise les profils et maintient de nombreux onglets stables pendant des heures. Pour un agent qui doit lire une fiche produit, trouver un bouton ou produire une capture, une grande partie de cela est superflue.

L’agent a néanmoins besoin de plus qu’un client HTTP. Les pages modernes ne livrent souvent d’abord qu’un squelette HTML presque vide. JavaScript construit le contenu réel, lance d’autres requêtes, modifie le DOM et réagit aux actions utilisateur. Un navigateur IA utilisable nécessite donc au minimum :

• un runtime JavaScript
• un DOM suffisamment compatible
• une logique réseau, cookies et origine
• des événements pour la souris, le clavier, les formulaires et la navigation
• une interface pour agents et outils d’automatisation
• selon la tâche, mise en page, captures et sortie PDF
• des limites strictes pour le code tiers, le temps d’exécution, la mémoire et l’accès réseau

Kitesurf et Obscura réduisent Chromium à ces éléments utiles aux agents. Tous deux exposent CDP afin que Playwright et Puppeteer n’aient pas à adopter une interface entièrement nouvelle. Tous deux exécutent réellement JavaScript, construisent un DOM vivant et développent leurs propres chemins de rendu au lieu de lancer simplement Chromium avec d’autres paramètres.

Ce sont donc des moteurs pour l’automatisation. Le modèle de langage, la planification, les autorisations et la décision d’exécuter ou non une action restent au-dessus. Cette séparation est essentielle : un navigateur rapide ne transforme pas un agent peu fiable en agent sûr.

Kitesurf : un navigateur fait de Workers

Cloudflare n’a pas conçu Kitesurf comme un exécutable unique. Le moteur se répartit entre plusieurs composants Worker dotés de frontières de confiance distinctes.

Engine, PageScript et PageRenderer

L’Engine Worker est le point d’entrée public. Il accepte les connexions CDP et appels REST, et conserve l’état d’une session. Un client CDP existant peut ainsi communiquer avec Kitesurf d’une manière proche de Chrome.

Pour chaque page et iframe externalisée, Kitesurf démarre un PageScript Worker. Celui-ci reçoit un nouveau contexte JavaScript global et le DOM de la page. HTML et CSS sont traités avec des composants de Blitz et Stylo. JavaScript ordinaire et WebAssembly s’exécutent dans l’isolate V8 du Worker.

eval() constitue une exception notable. Pour des raisons de sécurité, Cloudflare Workers n’autorise pas nativement l’évaluation dynamique de code. Kitesurf emploie donc Boa, un moteur ECMAScript écrit en Rust, pour exécuter ces appels dans l’environnement Worker. Cette solution pragmatique crée une délicate frontière de compatibilité : une partie du code s’exécute directement dans V8, tandis que le code généré dynamiquement passe par un second moteur JavaScript au comportement potentiellement différent.

Le PageRenderer Worker produit les pixels des captures et PDF. Il reçoit une description de scène, la rastérise et renvoie le résultat. Il ne conserve pas d’état important de la page. S’il se bloque ou plante, l’Engine peut le supprimer et relancer le rendu.

Un seul composant peut accéder au réseau

Du point de vue de la sécurité, le SandboxOutbound Worker est particulièrement intéressant. Lui seul peut récupérer des ressources sur Internet. Il applique CORS, gère les cookies séparément par page, filtre les réponses et ajoute des en-têtes ressemblant à ceux d’un navigateur. PageScript et Engine ne disposent donc pas librement du réseau.

C’est une différence pertinente face à de nombreux montages d’agents artisanaux. Un agent navigateur n’ouvre pas uniquement des pages déjà approuvées par un humain. Il suit des liens provenant de résultats de recherche, de documents tiers ou même de prompts manipulés. Chaque chargement est une entrée non fiable. La frontière réseau n’est donc pas une optimisation, mais un élément du modèle de sécurité.

Kitesurf privilégie aussi les composants sans état. Ce qui ne conserve aucun état peut être arrêté et redémarré après une erreur. Pour des charges agentiques courtes et très fluctuantes, ce modèle s’accorde bien à Workers.

Cloudflare annonce plus de 215 000 Web Platform Tests réussis et une bonne couverture de DOM, HTML, CSS, SVG, Selection et XHR. Le chiffre est impressionnant, mais ne suffit pas à déterminer la maturité. WPT se compose de fichiers contenant de nombreux sous-tests, et Cloudflare ne publie ni taux de réussite complet, ni code et configuration de test exacts de Kitesurf. Impossible donc de comparer proprement ce nombre au runner WPT public d’Obscura ou à la compatibilité Chromium. Lors de sa présentation, Kitesurf n’avait que douze semaines et reste en bêta.

Plus efficace, mais pas plus rapide

Les propres mesures de Cloudflare révèlent l’intérêt économique. Sur un corpus de 14 URL et cinq exécutions, Kitesurf aurait consommé pour les captures 3,1 fois moins de CPU et 4,7 fois moins de mémoire qu’un pool Chromium chaud. Pour l’extraction HTML, 3,8 fois moins de CPU et 7 fois moins de mémoire.

La latence était cependant moins bonne. Les captures prenaient une médiane 1,8 fois supérieure et l’extraction HTML 1,7 fois. Kitesurf économise donc surtout de l’infrastructure par tâche, sans être automatiquement le plus rapide sur une page donnée.

Ces chiffres sont utiles, mais ne constituent pas des benchmarks indépendants. Cloudflare a choisi le corpus, l’environnement et la comparaison. Un pool Chromium chaud n’est en outre qu’un mode d’exploitation possible. La mesure montre le potentiel de l’architecture, pas que Kitesurf soit moins cher ou plus fiable pour toutes les charges agentiques réelles.

Obscura : le navigateur Rust indépendant

Obscura applique la même idée de base dans un projet open source local ou autohébergé. Le code est sous licence Apache 2.0. La version 0.2.1, publiée le 23 août 2026, comprend plusieurs crates Rust pour la CLI, CDP, la logique navigateur, JavaScript, le DOM, le réseau, MCP et le rendu.

V8, DOM propre et rendu CPU

Obscura intègre V8 via deno_core. Les API navigateur sont fournies par une importante couche bootstrap JavaScript et des opérations Rust. Le DOM est une implémentation maison. Pour la mise en page et le rendu, le projet utilise notamment Taffy, sa propre logique navigateur et un chemin de peinture sur CPU.

Obscura parle aussi CDP et possède un serveur MCP. Un agent peut ouvrir des pages, récupérer des instantanés DOM, cliquer, remplir des formulaires, exécuter JavaScript, produire des captures ou des PDF. Son avantage pratique est le contrôle : le moteur peut tourner localement, dans un conteneur ou sur une infrastructure propre, sans compte Cloudflare requis.

Le prix est l’exploitation. Selon la documentation d’architecture, les pages d’un processus partagent un isolate V8, et le travail JavaScript est sérialisé par un verrou global. Des watchdogs et deadlines strictes doivent empêcher une page de bloquer durablement le processus. Le document de sécurité précise néanmoins correctement la limite : ces mécanismes ne remplacent pas l’isolation du système d’exploitation. Pour traiter des pages hostiles à grande échelle, Obscura doit fonctionner dans des conteneurs ou machines virtuelles au réseau restreint.

Ce n’est pas un détail. Rust ne protège pas contre toute vulnérabilité de V8, des dépendances natives ou des frontières FFI. Un processus exécutant du JavaScript arbitraire d’Internet reste un service à haut risque.

Le mode stealth va au-delà du User-Agent

La différence la plus intéressante d’Obscura est son build stealth facultatif. Il remplace le transport reqwest normal par wreq avec BoringSSL et imite un handshake TLS de Chrome, dont ClientHello, ALPN et l’ordre des cipher suites. C’est important, car les systèmes antibot ne contrôlent pas uniquement le User-Agent visible. Ils vérifient si les en-têtes HTTP, l’empreinte TLS et les propriétés JavaScript racontent la même histoire de navigateur.

Côté JavaScript, Obscura tente de prolonger cette cohérence. Le code reproduit notamment navigator.userAgentData, les valeurs de plateforme, l’écran, le GPU, Canvas, l’audio, la batterie et d’autres surfaces d’empreinte. navigator.webdriver reste invisible. Les propriétés internes d’Obscura sont masquées lors de l’énumération, et les fonctions natives doivent ressembler à de vraies fonctions du navigateur dans Function.prototype.toString().

event.isTrusted est aussi traité de façon nuancée. Un événement créé par le code de la page avec new Event() reste untrusted. Les entrées du chemin CDP peuvent être marquées comme générées par le navigateur. Renvoyer systématiquement true serait facile à détecter et reproduirait mal le comportement normal du Web.

Le chemin stealth couvre navigations, sous-ressources, fetch() et XHR. C’est crucial : si seul le document principal présente une empreinte TLS de Chrome, mais qu’une requête API ultérieure ressemble soudain à une bibliothèque Rust, elle produit précisément l’incohérence recherchée par les systèmes antibot.

Obscura bloque aussi des endpoints connus de suivi et de fingerprinting. Les propriétés du navigateur peuvent varier par session. La documentation met toutefois en garde contre les combinaisons incompatibles. Région IP, fuseau horaire, géolocalisation, profil JavaScript et empreinte TLS doivent concorder. La rotation n’est pas une cape d’invisibilité. Une même IP de sortie changeant sans cesse d’identité d’appareil peut devenir encore plus suspecte.

Obscura contourne-t-il vraiment mieux la détection des bots ?

Face à Kitesurf, Obscura vise clairement davantage l’antidétection. Le code et la documentation le montrent. Cela ne signifie pas qu’il contourne de manière fiable les défenses antibot modernes.

Le projet limite heureusement clairement sa promesse. Le mode stealth doit réussir des contrôles simples de l’empreinte TLS ou du User-Agent. Selon la documentation, ne sont pas pris en charge :

• les challenges Cloudflare interactifs
• les challenges actifs de DataDome et Akamai Bot Manager
• les CAPTCHA
• les limites de débit fondées sur l’IP

L’affirmation fréquente selon laquelle Obscura passe la détection des bots n’est donc vraie que dans un sens étroit. Il cherche à moins ressembler à un client headless ordinaire, sans être un contournement universel des challenges.

Les systèmes antibot modernes évaluent bien davantage que l’empreinte du navigateur : réputation IP, ASN, fréquence des requêtes, navigation, mouvements de souris et frappes clavier, historique des cookies, comportement des comptes et relations entre sessions. Une propriété navigator parfaitement imitée sert peu si mille requêtes arrivent d’un centre de données au même rythme.

Les benchmarks publics d’Obscura doivent aussi être lus avec prudence. Le dépôt séparé contient des scripts reproductibles pour WPT, un parcours d’obstacles, des pages réelles, la fiabilité et la cohérence stealth. C’est mieux qu’un tableau marketing. Mais la suite stealth tourne localement et vérifie surtout la cohérence interne de l’empreinte définie par le projet. Elle ne prouve pas que de grands systèmes antibot commerciaux considèrent le trafic comme humain.

La vitesse d’évolution compte également. Entre Obscura 0.2.0 et 0.2.1, les notes de version recensent 122 commits en un peu plus de deux semaines. C’est le signe d’un développement actif, mais aussi d’une surface encore très mouvante. Pour un jeune moteur, une démonstration réussie ne suffit pas à conclure à la maturité en production.

Cloudflare ne veut pas d’un bot invisible

Kitesurf suit une logique fondamentalement différente. Cloudflare Browser Run ajoute aux requêtes sortantes des en-têtes non configurables, ainsi que des signatures Web Bot Auth permettant au serveur cible de vérifier cryptographiquement qu’une requête vient de l’infrastructure de navigateur Cloudflare.

La FAQ de Cloudflare est sans ambiguïté : les requêtes Browser Run sont toujours reconnues par Cloudflare comme du trafic bot. L’exploitant du site décide de les autoriser ou de les bloquer. Pour tester automatiquement sa propre zone, il peut les permettre spécifiquement par une règle WAF.

Kitesurf est une option de Browser Run. Décrire l’absence de camouflage comme un simple retard technique serait donc faux. L’identité bot transparente appartient au modèle produit. Cloudflare exploite à la fois la plateforme d’automatisation et les produits de sécurité qui détectent et contrôlent les bots. Un navigateur maison contournant volontairement ces contrôles nuirait directement à ce modèle.

Cloudflare dit aussi ouvertement que Kitesurf ne peut pas encore négocier le handshake d’un challenge antibot avec de vraies empreintes TLS. Pour ces pages, elle recommande toujours le Chromium standard de Browser Run. Même ce trafic Chromium reste toutefois identifiable comme automatisation grâce aux en-têtes et signatures Cloudflare.

On peut approuver cette décision. Les exploitants reçoivent une identité vérifiable plutôt qu’un User-Agent arbitrairement falsifiable. Les bots légitimes peuvent être autorisés, mesurés ou limités distinctement. Un abus peut être rattaché à un fournisseur et une infrastructure.

On peut aussi la critiquer. Un agent personnel lisant une page publique pour un utilisateur est techniquement rapproché d’un crawler commercial plutôt que du navigateur de cet utilisateur. L’exploitant dispose d’un interrupteur simple pour exclure les agents Cloudflare. L’utilisateur ne peut alors pas revenir à une session normale d’apparence humaine, même s’il automatisait seulement ses propres recherches.

Pourquoi Cloudflare a tout de même créé sa propre solution

Cloudflare écrit qu’Obscura a fourni l’inspiration initiale, puis qu’un agent IA a aidé à le porter sur Workers. De ce proof of concept à peine fonctionnel est né Kitesurf. C’est une attribution claire, pas une prétention cachée que l’idée serait née dans ses laboratoires.

La thèse selon laquelle Cloudflare aurait rejeté Obscura à cause du stealth n’apparaît toutefois ni dans l’article Kitesurf, ni dans la documentation Browser Run. Plusieurs raisons sont plus visibles.

Obscura est conçu comme un processus autohébergé. Kitesurf est une application Worker distribuée. Cloudflare veut exploiter isolates, Service Bindings, Worker-RPC, sa propre sandbox sortante et les API Browser Run existantes. Lancer quelque part un binaire Rust ne suffit pas.

Cloudflare a aussi besoin d’un moteur dont cycle de vie, ressources, télémétrie et comportement d’erreur correspondent à sa plateforme. Un renderer sans état, supprimé après un RPC défaillant, relève d’une autre architecture opérationnelle qu’un processus à isolate V8 partagé et verrou global.

Enfin, Kitesurf est un composant produit. CDP rend le client assez portable, mais le service demeure lié à Browser Run et Cloudflare Workers. Cloudflare promet de publier Kitesurf en open source et de permettre son déploiement dans le propre compte Cloudflare des clients. Aujourd’hui, le code n’est pas encore public. On peut dès maintenant examiner l’architecture, les limites de sécurité et l’implémentation d’Obscura. Pour Kitesurf, seuls le design publié, la documentation et le comportement observable peuvent être évalués.

La critique est ici légitime. Cloudflare profite d’une idée ouverte et d’un projet existant tandis que son développement reste d’abord fermé. Apache 2.0 le permet, et Cloudflare cite explicitement Obscura. C’est juridiquement propre. Mais pour une entreprise annonçant une ouverture prochaine, le code publié finira par compter davantage que le mot « soon ».

Deux navigateurs, deux modèles de contrôle

Les différences majeures ne se résument pas à la vitesse.

Kitesurf n’est donc pas simplement un meilleur Obscura. Il résout un autre problème opérationnel. Cloudflare veut exécuter de façon sûre et économique de très nombreuses tâches brèves sur sa plateforme. Obscura veut fournir un moteur indépendant que les exploitants contrôlent et peuvent au besoin rendre moins détectable.

La question de sécurité non résolue se trouve au-dessus du navigateur

Les deux projets investissent beaucoup dans l’isolation des sites. C’est nécessaire, sans résoudre le principal risque d’un navigateur IA : un site peut manipuler l’agent lui-même.

Un texte de prompt injection dans le DOM n’a pas besoin de provoquer une évasion de la sandbox V8. Il suffit que le modèle l’interprète comme instruction, révèle des données internes, ouvre un mauvais lien ou utilise un outil puissant. L’isolation réseau protège l’infrastructure du navigateur, pas automatiquement l’intention de l’utilisateur.

Un navigateur agentique prêt pour la production exige donc des contrôles supplémentaires :

• des contextes séparés pour les tâches sans rapport
• un minimum de secrets et des tokens éphémères par session
• des validations claires avant connexion, achat, upload ou modification de données
• des règles de domaine et d’egress extérieures au JavaScript de la page
• des journaux reliant décision du modèle, action du navigateur et résultat
• un arrêt sûr face aux navigations et téléchargements inattendus
• une protection empêchant le contenu d’une page de devenir une instruction système

Cloudflare cite Prompt Injection et Tool Safety comme priorités, mais l’article Kitesurf décrit surtout l’isolation du navigateur. Obscura fournit des outils, sans gérer l’autorisation de l’agent supérieur. Quiconque emploie l’un de ces projets doit combler lui-même cette lacune.

Quel modèle pour quel usage ?

Kitesurf est intéressant pour les captures, l’extraction HTML ou les documents issus de pages propres et autorisées. L’architecture Worker réduit l’exploitation et l’identité bot transparente ne gêne pas dans son propre environnement. Les exploitants peuvent autoriser précisément Browser Run et bénéficient d’une origine traçable.

Obscura est plus attrayant pour la recherche locale, les automatisations internes ou les environnements aux exigences strictes de contrôle des données. Mais il faut placer le moteur dans un runtime correctement limité. Conteneur ou VM, egress restrictif, identifiants séparés et --obey-robots activé ne devraient pas être ajoutés après coup.

Pour les longues sessions authentifiées, les médias, WebGL ou les pages dotées de défenses antibot complexes, un véritable Chromium reste souvent plus réaliste. Cloudflare le reconnaît pour Kitesurf. Un navigateur plus petit n’est pas automatiquement plus compatible.

Les fonctions stealth ne devraient servir qu’à des tests légitimes et autorisés ou à des automatisations respectueuses de la vie privée. L’accessibilité technique d’une page ne tranche ni la question juridique, ni l’obligation de respecter ses règles, limites de débit et ressources.

Ma conclusion

Obscura a manifestement montré à Cloudflare qu’un navigateur agentique n’était pas forcément Chromium. Kitesurf reprend cette idée et en tire une architecture native de Workers, avec une isolation convaincante, moins de ressources et une intégration directe à Browser Run.

Obscura est effectivement plus offensif sur la détection des bots. Son mode stealth modèle les surfaces TLS, HTTP et JavaScript bien plus précisément que Kitesurf. Dire qu’il « contourne mieux » reste excessif. Seul un meilleur camouflage face à des contrôles d’empreinte simples est établi ; le projet exclut lui-même le contournement des challenges interactifs modernes.

Chez Cloudflare, cette retenue n’est pas qu’une immaturité technique. Browser Run doit être identifiable comme bot. Les en-têtes non supprimables et Web Bot Auth font de cette transparence une fonction produit. C’est cohérent pour une entreprise qui vend aussi Bot Management, mais empêche Kitesurf de devenir un navigateur indépendant agissant pour l’utilisateur.

La critique la plus solide n’est donc pas que Cloudflare ait simplement copié Obscura. Les architectures et modèles d’exploitation diffèrent trop, et Cloudflare reconnaît l’inspiration.

La critique plus forte est la suivante : Cloudflare construit un navigateur IA dont l’identité, le runtime, la distribution et l’accès s’intègrent entièrement à son modèle de contrôle. Cela peut être très raisonnable pour les exploitants. Pour un Web agentique ouvert et centré sur l’utilisateur, ce n’est qu’une réponse possible.

Reste à voir si Kitesurf deviendra réellement ouvert, jusqu’où ira le code publié et si le navigateur pourra fonctionner utilement hors de la plateforme Cloudflare. D’ici là, Obscura est l’expérience la plus ouverte et Kitesurf le produit le mieux intégré.

À la prochaine,
Joe