Vos agents pilotent un vrai navigateur.
Pas un faux.
AgentsRoom embarque un vrai navigateur Chromium dans chaque projet, et livre un serveur AgentsRoom Browser MCP qui laisse vos agents IA le contrôler. Votre agent QA ouvre votre site localhost, clique sur les boutons, remplit les formulaires, prend des captures, lit la console, et vérifie que la feature marche vraiment avant de dire done. De la vraie automatisation navigateur end-to-end pour Claude, Codex, GitHub Copilot CLI, Cursor et 13 autres CLI d'agent, avec zéro config Playwright.
Combinez-le avec Agent Teams : un agent Dev livre la feature, un agent QA charge le site localhost dans le navigateur intégré, exécute le scénario de vérification, screenshote le résultat, et signe. L'automatisation native du navigateur est aussi sur la roadmap, avec des futurs serveurs MCP prévus pour les apps React Native et Electron pour que les agents puissent tester le mobile et le desktop.
Une vraie session, filmée dans l'app : un agent de code IA autorisé à piloter le navigateur intégré ajoute une inscription à la newsletter sur la page d'une boutique qui tourne en local. Il ouvre la page lui-même, tape une adresse e-mail de test et clique sur Subscribe, voit que le formulaire reste affiché, corrige ses propres styles et réessaie. Puis il raconte ce qu'il a vu dans le navigateur.
Browser Automation dans AgentsRoom, c'est deux choses en une. Premièrement, un vrai navigateur Chromium intégré à chaque room projet, avec barre d'URL, back/forward, reload, historique, capture vers presse-papiers, ouvrir-dans-navigateur-par-défaut, cookies persistants et localStorage par projet. Deuxièmement, un serveur AgentsRoom Browser MCP (agentsroom-browser) qui expose ce navigateur à vos agents IA via le Model Context Protocol. L'agent reçoit une interface propre et scriptable : navigate, click, type, screenshot, evaluate JavaScript, wait for an element, get the page state, get the console logs, go back, go forward, reload.
Pourquoi c'est important ? Parce que toute la promesse des agents IA de code s'effondre quand l'agent dit 'feature livrée' mais n'ouvre jamais la page pour vérifier. La plupart des agents aujourd'hui se contentent de lancer des tests unitaires, et après ils espèrent. Avec un vrai Browser MCP, l'agent charge le serveur localhost, exécute le user flow, voit ce que verrait l'utilisateur humain, et seulement après il signe. Le rôle agent QA Engineer a enfin les outils dont il a besoin pour faire de la vraie QA, pas juste de l'analyse statique.
Le setup technique vous est invisible. Quand vous cochez 'Browser access' sur un agent, AgentsRoom merge l'entrée agentsroom-browser dans le .mcp.json de votre projet et l'agent boote avec les outils browser disponibles. Un bridge WebSocket qui tourne sur un port loopback (127.0.0.1, attribué par l'OS, régénéré à chaque boot, authentifié avec un token hex de 32 octets) connecte le sous-process MCP à la WebContentsView Chromium dans l'app Electron. Chaque clic, chaque saisie, chaque capture est un appel JSON-RPC. L'agent voit un vrai navigateur, pas un stub.
Panel Browser AgentsRoom : barre d'URL, historique, capture, et surface de contrôle MCP complète pour que les agents IA naviguent, cliquent, tapent et vérifient.
Un vrai navigateur, pas un stub Playwright
La plupart des démos d'agents IA qui parlent d'automatisation navigateur utilisent une instance Playwright headless spawnée à chaque appel d'outil. Ça marche pour les benchmarks mais c'est pénible dans la vraie vie : vous ne voyez pas ce que fait l'agent, chaque navigation respawn Chromium, les cookies sont perdus, le localStorage est vide, votre serveur de dev pense que chaque visite est une nouvelle session toute neuve. AgentsRoom prend un angle différent. Le navigateur est déjà ouvert dans votre room projet (vous l'utilisez vous-même, comme un navigateur normal), et l'agent pilote ce navigateur. Sessions, cookies, localStorage, état de connexion, tout est préservé.
Chaque clic et chaque saisie de l'agent déclenchent un vrai dispatch natif via la WebContentsView d'Electron, avec de vrais events clavier, events souris et mutations DOM. Les captures sont de vrais PNG capturés depuis la page rendue réelle (pas un hack DOM-vers-image). Les logs de console sont bufférisés et interrogeables, y compris les warnings et les errors. L'agent voit la même chose que vous verriez avec les DevTools ouvertes : vraie performance, vrai comportement réseau, vrai CORS, vraie auth.
L'isolation cross-room est appliquée. AgentsRoom crée une WebContentsView Chromium par projet, avec sa propre session partition (persist:agentsroom-browser-<projectId>). Les cookies du projet A ne fuient jamais dans le projet B. Quand vous changez de projet, le navigateur précédent est caché et le nouveau arrive en ligne avec son propre état. L'agent atterrit toujours sur le bon projet, avec les bons credentials.
La couche MCP est volontairement petite et sans dépendances. Le sous-process browser-mcp-server.cjs parle le protocole MCP 2024-11-05 sur stdio (initialize, tools/list, tools/call) et le traduit en appels JSON-RPC sur le bridge WebSocket loopback. Comparé à un serveur lourd basé sur SDK, ça reste rapide (premier appel d'outil sous les 100ms) et facile à debugger. Après chaque action qui change la page (click, type, navigate, reload, back, forward), la réponse inclut une capture PNG en base64 plafonnée à 1.6 MB pour que l'agent voie toujours le résultat de ce qu'il vient de faire. C'est le plus gros gain de fiabilité qu'on a constaté : les agents qui voient l'écran font le bon truc bien plus souvent que les agents qui espèrent.
La toolkit Browser MCP que vos agents reçoivent
Chaque agent IA avec accès navigateur boote avec ces outils disponibles. Ils sont exposés via MCP standard, donc tout CLI compatible les voit : Claude, Codex, GitHub Copilot CLI, Cursor et 13 autres CLI d'agent.
browser_navigate
Ouvre une URL dans le navigateur intégré. Gestion intelligente des URL : localhost:3000 devient http://localhost:3000 au lieu de déclencher un dialogue 'cannot open application'. Retourne l'URL finale et une capture de la page après chargement.
browser_click
Clique sur un élément par sélecteur ou par texte visible. Vrai event de clic natif, pas un dispatch JavaScript. Retourne la capture post-clic pour que l'agent voie le résultat de son action.
browser_type
Tape du texte dans un input ou une textarea. Supporte les raccourcis clavier et le submit. Vrais events clavier, les handlers onChange de la page sont déclenchés. Retourne la capture après la saisie.
browser_screenshot
Capture le viewport courant en PNG. Utile pour les checks de régression visuelle, le design QA, les comparaisons before-and-after, ou pour partager l'état d'un bug avec le reste de l'équipe.
browser_evaluate
Exécute une expression JavaScript dans le main world de la page. Récupère le résultat sérialisé. Utilisé par les agents pour lire l'état de la page, interroger le DOM, inspecter un store Redux, ou déclencher une action qui n'a pas de bouton visible.
browser_wait_for
Attend qu'un élément apparaisse, que l'URL change, qu'une requête réseau finisse, ou qu'un JavaScript arbitraire retourne true. Évite la classique race 'l'agent clique trop vite'.
browser_get_state
Lit l'URL courante, le titre, le viewport, la position de scroll, et un snapshot structuré des éléments accessibles de la page. L'input principal de l'agent quand il a besoin de planifier sa prochaine action.
browser_get_logs
Récupère le buffer de console (log, warn, error). L'agent peut voir les mêmes warnings React, erreurs d'hydratation, échecs réseau et exceptions runtime que vous verriez dans les DevTools. Les bug reports deviennent 'voici l'erreur de la console'.
browser_set_viewport
Redimensionne le viewport de la page, pour que l'agent examine une mise en page à une largeur réelle plutôt qu'à la taille que le panel a sur le moment. Un preset d'appareil (de l'iPhone SE à l'iPad Pro) apporte une vraie sémantique mobile : la balise viewport meta est respectée, les événements touch se déclenchent, et devicePixelRatio ainsi que le user agent changent avec lui. Une largeur brute couvre les breakpoints desktop. Le panel intégré se redimensionne en même temps, donc vous voyez exactement la page que l'agent est en train de juger, et vous pouvez revenir en arrière depuis le menu des appareils.
browser_go_back / forward / reload
Navigation standard de navigateur, scriptable. Utilisée par les agents pour revenir en arrière quand un flow part en vrille, ou pour re-tester une page après un hot reload de Vite, Next.js ou Expo Metro. Ce navigateur tourne avec le cache HTTP désactivé : l'agent voit toujours le dernier build, jamais un bundle périmé ; useCache: true réautorise le cache pour un seul chargement.
Ce que les agents font vraiment avec le navigateur
Vrais workflows que vous pouvez construire dès aujourd'hui, avec le rôle QA Engineer et Agent Teams.
Smoke test end-to-end à chaque handoff
Câblez une équipe Dev vers QA. L'agent QA navigue vers votre serveur de dev localhost, clique à travers les chemins critiques (signup, checkout, dashboard), screenshote le résultat, et signe seulement si rien ne crash. Attrapez les régressions avant qu'un humain ouvre la page.
QA de régression visuelle
Captures avant-après sur les changements UI. L'agent charge la page sur le commit précédent, screenshote, change de branche, screenshote, demande à Claude de comparer. Diff visuel pas cher pour la QA, sans Percy ni Chromatic dans la boucle.
Chasse aux erreurs console
L'agent navigue dans l'app, appelle browser_get_logs, trouve les warnings d'hydratation React, les warnings useEffect, les 404 réseau, les erreurs CORS, les notices de deprecation. Les rapporte comme une liste de risques dans le payload de handoff d'équipe, l'agent Dev suivant les corrige.
Tests de validation de formulaire
L'agent remplit le formulaire avec des données valides, des champs vides, des cas limites (chaînes XSS, inputs très longs, non-ASCII). Vérifie les messages de validation, les requêtes réseau, les redirections. Vraie QA de formulaire, pas des tests unitaires.
Audit d'accessibilité
L'agent parcourt la page, interroge l'arbre d'accessibilité via browser_get_state et browser_evaluate, vérifie les alt textes, les attributs ARIA, la gestion du focus, la navigation clavier. Rapporte les problèmes avec captures.
Design QA contre Figma
Combinez avec la feature Figma vers agents IA. L'agent charge la frame Figma, screenshote, charge la page localhost, screenshote, compare les espacements, polices, couleurs, alignements. Liste les écarts.
Vérif de tunnel preview live
Combinez avec le tunnel localhost AgentsRoom. L'agent navigue vers l'URL HTTPS de preview publique (pas localhost), vérifie que le site est joignable depuis l'extérieur, screenshote, et confirme qu'un stakeholder peut vraiment ouvrir le lien.
Reproduire un bug client depuis un ticket de backlog public
Un ticket de backlog public arrive avec une URL et des étapes pour reproduire. L'agent QA ouvre l'URL, suit les étapes, capture l'erreur console, attache la capture, fait le handoff au Dev avec une repro propre. Plus de boucles 'cannot reproduce'.
Pointez un élément, envoyez-le directement à l'agent
Piloter le navigateur, ce n'est que la moitié de l'histoire. Parfois, c'est vous qui repérez le problème : un bouton mal aligné, un libellé erroné, une carte qui casse sur mobile. Plutôt que de le décrire avec des mots, vous le pointez. Le navigateur intégré propose un mode pointage : cliquez sur n'importe quel élément de la page et AgentsRoom capture son sélecteur CSS exact dans le DOM en direct.
Ajoutez une note courte comme « resserrez cet espacement » ou « mauvaise couleur ici », et l'élément pointé accompagné de votre annotation part vers l'agent actif sous forme de demande de modification précise et sans ambiguïté. Fini le « la troisième carte en partant de la gauche » : l'agent reçoit le sélecteur, le contexte autour et votre intention d'un seul coup.
Mode pointage du navigateur AgentsRoom : cliquez un élément, ajoutez une note, et le sélecteur exact accompagné de votre annotation sont envoyés à l'agent sous forme de changement pointé.
Activez le mode pointage
Ouvrez le navigateur intégré sur votre app et cliquez sur le bouton de pointage. Chaque élément se surligne au survol.
Cliquez l'élément
Cliquez sur le bouton, le bloc de texte ou la carte à modifier. AgentsRoom le verrouille et lit son sélecteur CSS exact dans le DOM en direct.
Ajoutez une note et envoyez
Tapez ce qui doit changer et validez. Le sélecteur, le contexte autour et votre note sont transmis à l'agent actif sous forme de changement pointé.
Besoin de votre vrai Chrome ?
Pilotez le Chrome où vous êtes connecté, avec Chrome control
Le navigateur intégré est fait pour votre localhost : session propre, rien de personnel en jeu. Quand le boulot exige vos vrais comptes, un panneau d'admin derrière votre SSO, un service où vous seul êtes connecté, l'extension AgentsRoom transforme chaque profil Chrome en cible nommée que vos agents peuvent piloter, sur cette machine ou sur une autre, avec les mêmes outils navigateur.
Lire la page Chrome controlComment un agent obtient un navigateur
Ouvrez l'onglet Browser dans votre room
Dans votre room projet, le panel de droite expose trois onglets : Files, Changes, Browser. Cliquez sur Browser. Le panel s'élargit, la sidebar se replie, et une vraie vue Chromium apparaît. Tapez une URL ou choisissez dans l'historique du projet.
Cochez 'Browser access' sur l'agent
Ouvrez la modale Edit Agent, dépliez Capabilities, cochez Browser access. AgentsRoom merge l'entrée agentsroom-browser dans le .mcp.json de votre projet et l'agent verra les outils browser au prochain démarrage.
<project>/.mcp.jsonL'agent boote avec le browser MCP
Au spawn de l'agent, Claude (ou Codex, Antigravity, etc.) initialise le serveur MCP agentsroom-browser, liste ses outils (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_set_viewport, browser_go_back, browser_go_forward, browser_reload), et à partir de maintenant peut piloter le navigateur.
L'agent utilise le navigateur
L'agent navigue, clique, tape, screenshote, lit la console. Chaque action passe par un bridge WebSocket loopback (127.0.0.1, port attribué par l'OS, token hex de 32 octets, régénéré à chaque boot de l'app desktop). Après chaque action qui change la page, une capture est retournée inline pour que l'agent vérifie visuellement son coup.
Cible automatique localhost ou votre tunnel
Si un tunnel localhost tourne, la première navigation atterrit sur l'URL du tunnel. Sinon, le premier serveur de dev détecté. Sinon, https://localhost:3000. Combiné aux Dev Terminals, l'agent démarre littéralement le serveur de dev, puis l'ouvre dans le navigateur, puis le teste.
Vérifie, screenshote, fait le handoff
Quand il est câblé dans Agent Teams, le node QA exécute ses scénarios, capture les screenshots, pose flags.qaPassed dans le payload de handoff. L'agent suivant hérite du verdict. Pass va au PM, fail repart au Dev avec les pistes de test.
Sous le capot
Pour les curieux. La stack d'automatisation navigateur est petite par choix.
Chaque projet a une WebContentsView Chromium (l'API Electron moderne, pas la BrowserView dépréciée), superposée sur la fenêtre principale aux bounds streamées depuis le renderer React. La session partition par projet garde les cookies, le localStorage et l'authentification isolés entre projets. Les bounds offscreen par défaut laissent les agents appeler les outils browser même avant que l'humain n'ouvre l'onglet Browser, avec un timeout de 5 secondes sur les screenshots pour éviter les freezes.
Un serveur WebSocket léger (browser-bridge.ts) tourne sur un port loopback choisi par l'OS, bind à 127.0.0.1 uniquement. L'authentification utilise un token hex de 32 octets régénéré à chaque boot desktop. Le fichier de bridge ~/.agentsroom/browser-bridge.json contient le port, le token et le PID courants, réécrit atomiquement à chaque boot, pour que le sous-process MCP récupère toujours des credentials frais avec retry automatique.
Le serveur MCP lui-même est browser-mcp-server.cjs, un script Node sans dépendance qui implémente le protocole MCP 2024-11-05 sur stdio (initialize, tools/list, tools/call). Il parle JSON-RPC au bridge WebSocket via un client WebSocket fait main (pas de ws, pas de @modelcontextprotocol/sdk). Petit, rapide, facile à auditer. Bundlé comme fichier extraResources dans l'app desktop, donc chaque install est livrée avec lui prêt à tourner.
Le support natif du navigateur (une feature browser first-class au-delà du MCP) est sur la roadmap AgentsRoom. Au-delà, le plan long terme inclut des MCP supplémentaires pour que les agents pilotent aussi des cibles non-web : un MCP React Native pour les apps mobiles et un MCP Electron pour les apps desktop. Même idée, même UX : l'agent n'écrit pas juste du code, il exerce vraiment l'app qui tourne.
FAQ
En quoi c'est différent du Playwright MCP ou des outils navigateur basés sur Puppeteer ?
Les MCP basés sur Playwright et Puppeteer spawn un nouveau navigateur headless à chaque session. C'est bien pour les tâches sans état, mais ça perd les cookies, le localStorage et l'auth entre les appels, et l'humain ne peut pas voir ce que fait l'agent. AgentsRoom Browser est le même navigateur que l'humain utilise dans l'app, avec session persistante par projet, visible par l'utilisateur en temps réel. L'agent pilote une fenêtre que vous pouvez voir et reprendre à tout moment. C'est une automatisation navigateur plus honnête, plus debuggable.
Ça marche avec tous les providers IA, ou seulement Claude Code ?
Ça marche avec les 17 CLI d'agent supportés par AgentsRoom : Claude Code, Codex CLI, GitHub Copilot CLI, Cursor et 13 autres. Les outils browser sont exposés via le standard Model Context Protocol, que tous ces CLIs lisent depuis .mcp.json. L'agent ne sait jamais qu'il est dans AgentsRoom, il voit juste un set d'outils MCP et les utilise comme n'importe quel autre outil.
L'agent peut piloter un site distant, ou seulement localhost ?
Les deux. Tapez n'importe quelle URL et go. Les formes localhost (et host:port) sont smart-detectées, préfixées avec http://, et ouvertes directement. Les sites publics marchent comme dans n'importe quel navigateur normal, avec cookies et état de connexion préservés par projet. Combiné au tunnel localhost AgentsRoom, l'agent peut aussi piloter votre serveur de dev local via une URL HTTPS publique, ce qui est utile pour la QA cross-réseau et mobile.
Le browser MCP est-il sécurisé ? Qu'est-ce qui empêche les abus ?
Le bridge bind sur 127.0.0.1 uniquement, jamais sur 0.0.0.0. Le port est attribué par l'OS (pas de port fixe propice au scanning de collision). Un token hex de 32 octets est requis sur chaque connexion, régénéré à chaque boot desktop. Le sous-process MCP reçoit les credentials uniquement via variables d'env, jamais dans un fichier commité. L'accès navigateur est opt-in par agent dans la modale Edit Agent. Si vous le retirez, l'entrée .mcp.json est retirée et l'agent ne peut plus utiliser les outils.
L'agent voit-il la console du navigateur (errors, warnings, network) ?
Oui, via browser_get_logs. Le buffer contient les messages console.log, console.warn et console.error du main world de la page. Beaucoup de vrais bugs (erreurs d'hydratation React, warnings useEffect, échecs CORS) ne remontent que dans la console, jamais dans les tests unitaires, donc ça se révèle être un des outils les plus à fort signal pour l'agent QA.
Qu'est-ce qui se passe avec les screenshots retournés à l'agent ? Ils coûtent beaucoup de tokens ?
Par défaut, chaque action qui change la page ajoute à la réponse de l'outil une capture PNG en base64, plafonnée à 1.6 MB, qui coûte environ 1 400 à 1 800 tokens. Le mode économie de tokens (bêta) change ce défaut : l'agent lit une liste plafonnée des éléments de la page avec browser_read_page (140 à 820 tokens) et ne reçoit une capture que si une action échoue ou s'il en demande une. AgentsRoom affiche le coût estimé en tokens de chaque appel au navigateur, pour voir la différence sur vos propres pages.
L'agent peut remplir un formulaire de connexion ? Persister sa session ?
Oui. Les cookies et le localStorage sont persistés par projet sous la session partition persist:agentsroom-browser-<projectId>. L'agent peut se connecter une fois avec browser_type et browser_click, et rester connecté sur le reste du run. Quand vous changez de projet, la session change, donc les credentials ne fuient jamais entre projets.
L'agent va casser si le serveur de dev ne tourne pas ?
Il navigue vers l'URL et voit une page d'erreur Chromium. Il peut lire cette erreur via browser_get_state et browser_get_logs et réagir en conséquence : vous demander de démarrer le serveur, ou appeler une commande Dev Terminals pour le démarrer. Avec Agent Teams et Dev Terminals, vous pouvez câbler un workflow qui démarre le serveur, attend, puis ouvre le navigateur, le tout sans intervention humaine.
Les apps mobiles et desktop sont aussi supportées ?
Le web est livré aujourd'hui, à travers le Chromium intégré et le AgentsRoom Browser MCP. La roadmap inclut un AgentsRoom Browser natif comme feature browser first-class. Au-delà, des serveurs MCP supplémentaires sont prévus : un MCP React Native pour que les agents pilotent les bundles iOS et Android Expo, et un MCP Electron pour que les agents pilotent les apps desktop qui ne sont pas web. La même logique d'agent, appliquée à des cibles non-web.
L'humain peut mettre l'agent en pause et reprendre le navigateur ?
Oui. Le navigateur est la même vue Chromium que l'humain utilise. À tout moment, cliquez dans le panel Browser et vous prenez le contrôle. Une fois que vous arrêtez d'interagir, l'agent peut reprendre ses appels d'outils. Il n'y a pas de concept de 'navigateur verrouillé par l'agent', c'est une surface partagée, exactement comme une session de pair programming.
Il peut ouvrir un site de dev ou de préprod protégé par un mot de passe .htaccess ?
Oui, depuis la version 1.220.0 (octobre 2026). Quand un site demande une authentification HTTP (Basic ou Digest, celle qu'un fichier .htaccess met en place sur un serveur de préprod ou de staging), le navigateur ouvre une fenêtre « Se connecter à ce site » qui nomme l'hôte et vous demande un identifiant et un mot de passe. « Se connecter » les envoie à ce site uniquement ; « Annuler » affiche la page 401 du site ; si le site les refuse, la fenêtre revient et le dit. Cochez « Mémoriser pour ce projet », ou ajoutez des règles dans l'onglet « Connexion HTTP » du Contexte QA (preprod.exemple.com, ou *.exemple.com pour tous les sous-domaines) : le navigateur répond ensuite tout seul, pour vous comme pour les agents qui le pilotent. Les agents ne voient jamais le mot de passe : il est enregistré chiffré sur votre ordinateur, et vous suit sur vos autres ordinateurs, chiffré de bout en bout, quand la synchronisation des mots de passe est active.
À propos : Délégation d'agent
Laissez un agent QA moins cher driver le browser, pas votre agent dev
Le Browser MCP brille le plus quand l'agent dev ne le drive pas directement. La délégation d'agent route le test browser vers un agent QA séparé et moins cher via un seul appel MCP run_qa_test. Votre Opus ou Codex reste focalisé sur le code, l'agent QA fait les clics sur un modèle plus petit, le verdict revient en une ligne. Même Browser MCP, facture plus légère, contexte plus propre.
Lire la page Délégation d'agentDonnez à vos agents de vrais yeux navigateur
Cochez Browser access sur n'importe quel agent dans AgentsRoom. Le Browser MCP boote automatiquement. Votre agent QA teste enfin ce qu'il livre.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.