BrowserOS : deux navigateurs Chromium, un pour vos agents, un pour vous
🌐 The open-source Agentic browser; alternative to ChatGPT Atlas, Perplexity Comet, Dia.
En bref
- De quoi s’agit-il ?
- BrowserOS empile deux produits dans un même dépôt : neo, un navigateur secondaire qui exécute vos agents sur vos sessions connectées, et un fork Chromium doté d'un agent intégré. Voici ce que la documentation permet réellement de vérifier, et où les choix de conception se paient.
- À qui s’adresse-t-il ?
- Adoptez BrowserOS neo si vos tâches exigent un navigateur déjà connecté à vos comptes et que vous acceptez de faire tourner un second navigateur à côté de Chrome, avec les sessions stockées dans ~/.browserclaw/. Ne l'adoptez pas pour du CI ou du scraping anonyme : Playwright reste plus simple et plus reproductible.
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions strictes. AGPL-3.0 est une licence à copyleft réseau : si des personnes utilisent une version modifiée via un réseau, par exemple comme service hébergé, vous devez leur proposer son code source sous la même licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : automatiser ce qui exige une session déjà ouverte
La plupart des tâches web intéressantes ne sont pas anonymes. Lire une boîte mail, publier sur LinkedIn, mettre à jour un CRM ou sortir un rapport d'un outil interne suppose un cookie de session valide. Les pilotes sans interface comme Playwright démarrent un Chrome neuf, sans identifiants : le README le dit sans détour, ils sont utiles en intégration continue et inutiles pour ce genre de travail. Les navigateurs hébergés en centre de données posent l'autre moitié du problème : se connecter à un compte depuis une adresse IP de datacenter déclenche les blocages de sites comme Twitter ou LinkedIn. BrowserOS neo répond à ce cas précis en s'installant sur votre machine, en important vos identifiants depuis Chrome en un clic, et en exposant le tout aux agents que vous payez déjà. Le public visé est donc l'utilisateur individuel ou le petit collectif qui veut déléguer des actions web sur ses propres comptes, pas l'équipe qui cherche une ferme de navigateurs.
Deux produits dans un seul dépôt, et une confusion qui coûte
Le dépôt héberge deux navigateurs distincts. BrowserOS neo est décrit comme un navigateur secondaire, qui se place à côté de Chrome et non à sa place ; le README insiste sur ce point. Le second, BrowserOS, est un fork Chromium complet avec un agent dans chaque nouvel onglet, qui annonce plus de 20 outils intégrés et plus de 40 intégrations applicatives, avec la possibilité d'apporter ses propres clés ou de tout exécuter en local via Ollama. Ces deux ensembles ne partagent ni la même finalité ni le même mode d'installation. La page d'accueil renvoyée dans les métadonnées pointe vers BrowserOS.com/neo, ce qui laisse penser que neo est la vitrine actuelle. Pour un lecteur qui évalue le projet, la première question n'est pas « est-ce que ça marche » mais « lequel des deux est-ce que j'installe ». Le README ne répond pas entièrement : la section consacrée au fork Chromium est tronquée dans le matériel disponible, et je ne peux donc pas décrire son installation ni ses prérequis. C'est une lacune documentaire réelle, pas un détail de présentation.
Le mécanisme : un serveur local, une extension, des onglets parallèles
Les versions publiées éclairent l'architecture mieux que le README. Deux composants sont versionnés séparément : ext-agent, l'extension d'agent, et agent-server, le serveur. Le serveur est publié bien plus fréquemment que l'extension, ce qui suggère que la logique d'orchestration vit côté serveur et que l'extension sert de pont avec le navigateur. Le flux décrit par la documentation est le suivant : votre harnais (Claude Code, Codex, Cursor, VS Code, OpenClaw, Hermes) se connecte au navigateur via MCP, vous lui donnez une tâche en langage naturel, et l'agent travaille dans son propre onglet pendant que vous continuez à naviguer. Plusieurs agents peuvent tourner en parallèle, chacun dans son onglet. Le nouveau tab sert de tableau de bord : site courant, action en cours, avancement. Chaque session est enregistrée sur disque sous forme de vidéo que l'on peut faire défiler, accompagnée d'une chronologie d'actions. Le README situe ces données dans ~/.browserclaw/. Rien dans le matériel ne décrit le protocole exact entre le serveur et l'extension, ni la manière dont les onglets sont isolés les uns des autres. Si vous avez besoin de cette garantie d'isolation, il faudra la chercher dans le code.
Mise en route : téléchargement, import, connexion MCP
L'installation passe par des binaires préconstruits, pas par un gestionnaire de paquets. Le README fournit deux liens de téléchargement : un fichier .dmg pour macOS et un installateur .exe pour Windows, tous deux servis depuis cdn.browseros.com. Les sujets du dépôt mentionnent Linux, mais aucune commande ni aucun artefact Linux n'apparaît dans le matériel fourni ; je ne peux donc pas confirmer la procédure sur cette plateforme. Une fois installé, le parcours tient en trois étapes selon le README : importer depuis Chrome en un clic (identifiants, favoris, extensions), laisser le navigateur détecter les harnais présents et se connecter en un clic, puis confier une tâche depuis l'agent. La connexion aux harnais s'appuie sur MCP, et la documentation associée se trouve à docs.browseros.com/neo/mcp. Le README ne donne pas d'exemple de fichier de configuration MCP ni de clé à renseigner : la connexion est présentée comme automatique depuis une interface graphique. C'est confortable pour un utilisateur, moins pour quelqu'un qui voudrait provisionner la chose par script.
Ce que le dépôt ne dit pas sur le coût de possession
La licence est AGPL-3.0, ce qui a une conséquence pratique : si vous modifiez le code et l'exposez en tant que service réseau, l'obligation de publication du source s'applique. Pour un usage personnel sur son poste, cela ne change rien. Pour une entreprise qui voudrait intégrer neo dans un produit accessible à ses clients, la question mérite un avis juridique, que je ne fournis pas ici. Sur la maintenance, les publications récentes montrent un rythme soutenu : trois versions en une journée pour agent-server et ext-agent, le 9 septembre 2026. Ce rythme indique un projet actif, mais aussi une surface mouvante : un agent qui automatise des parcours web dépend de sélecteurs et de flux qui changent sans préavis, et la version de l'extension doit rester alignée sur celle du serveur. Le README ne documente ni politique de compatibilité entre ext-agent et agent-server, ni procédure de retour arrière. Sur un poste de travail où vos sessions sont réelles, c'est le point à vérifier avant de généraliser l'outil à une équipe.
La comparaison qui compte : état de session contre reproductibilité
Face à Playwright, la différence n'est pas une question de qualité mais de nature de l'état. Playwright démarre un processus Chrome neuf, sans identifiants, et vous décrivez le parcours dans un script versionné : le résultat est reproductible, exécutable en CI, et ne dépend d'aucune session personnelle. BrowserOS neo fait l'inverse : il réutilise vos sessions importées depuis Chrome et laisse un agent décider des actions. Vous gagnez l'accès aux tâches qui exigent une connexion, vous perdez la reproductibilité et la possibilité de faire tourner la même chose sur un runner. Face aux navigateurs hébergés en centre de données, le renversement porte sur l'adresse IP et la localisation des données : neo tourne sur 127.0.0.1 selon le README, et les sessions restent sous ~/.browserclaw/. Cela réduit le risque de blocage par les sites et évite d'envoyer captures et historique à un tiers. En contrepartie, il n'y a pas de mise à l'échelle horizontale : vos agents tournent sur votre machine, avec ses ressources et sa bande passante.
Les cas où neo est le mauvais outil
Trois situations écartent BrowserOS neo. D'abord le test automatisé et l'intégration continue : un navigateur qui dépend de vos identifiants personnels et d'un tableau de bord graphique ne s'insère pas dans un pipeline, et Playwright reste l'outil adapté. Ensuite le scraping à grande échelle ou anonyme : si la tâche n'a pas besoin de votre session, l'import des identifiants devient un risque inutile. Enfin le poste partagé ou la machine de build : le README indique que les sessions, captures d'écran et historique vivent sous ~/.browserclaw/ et ne quittent pas la machine, ce qui est un argument de confidentialité mais aussi une contrainte de sécurité. Sur un poste utilisé par plusieurs personnes, ces fichiers sont accessibles à quiconque ouvre le répertoire. Le README ne décrit ni chiffrement de ce répertoire ni mécanisme de verrouillage, et je ne peux pas affirmer qu'il en existe. À l'inverse, la revendication de consommation de jetons réduite par rapport à l'extension Chrome de Claude ou au navigateur de Codex est présentée sans chiffre ni protocole de mesure dans le matériel disponible : à traiter comme une affirmation de l'éditeur, pas comme un résultat vérifié.
Conclusion éditoriale
Adoptez BrowserOS neo si vos tâches exigent un navigateur déjà connecté à vos comptes et que vous acceptez de faire tourner un second navigateur à côté de Chrome, avec les sessions stockées dans ~/.browserclaw/. Ne l'adoptez pas pour du CI ou du scraping anonyme : Playwright reste plus simple et plus reproductible. Avant de vous engager, vérifiez la liste des harnais réellement supportés dans docs.browseros.com/neo/mcp et le contenu du répertoire ~/.browserclaw/ après une première session enregistrée, car c'est là que vivent captures d'écran et historique.
Notes de la communauté