BrowserGym : un environnement Gymnasium pour agents web, entre cadre de recherche et usine à benchmarks

Le problème : chaque benchmark web a sa propre plomberie

Un agent web doit lire une page, choisir une action, l'exécuter dans un navigateur, puis recevoir une récompense. Cette boucle est identique d'un benchmark à l'autre, mais son implémentation ne l'est pas. BrowserGym part de ce constat et expose la navigation comme un environnement Gymnasium : gym.make renvoie un objet qui possède reset et step, comme n'importe quel environnement de reinforcement learning. Le public visé est celui qui écrit des agents web et veut les mesurer, pas celui qui cherche un outil d'automatisation de navigateur pour un usage quotidien. Le dépôt le dit sans détour : le projet vise à accélérer la recherche sur les agents web et n'est pas conçu comme un produit grand public.

Neuf benchmarks derrière un préfixe d'identifiant

Le paquet regroupe MiniWoB, WebArena, WebArenaVerified, VisualWebArena, WorkArena, AssistantBench, WebLINX, OpenApps et TimeWarp. Chaque benchmark s'enregistre via son propre import et ses tâches apparaissent dans le registre Gymnasium sous un préfixe, par exemple browsergym/miniwob.choose-list ou browsergym/webarena.310. Le README montre comment énumérer les identifiants disponibles en filtrant gym.envs.registry.keys() sur ce préfixe. C'est le principal argument du projet : un même code d'agent peut être pointé vers des suites différentes en changeant l'identifiant et l'import. La contrepartie est réelle. Chaque benchmark conserve son installation propre, et le README renvoie vers un fichier de configuration distinct pour MiniWoB, WebArena, WebArenaVerified, VisualWebArena, AssistantBench et TimeWarp. L'uniformité s'arrête à l'API.

La boucle agent-environnement, telle que documentée

Le code d'amorçage du README tient en quelques lignes. On importe gymnasium et browsergym.core pour enregistrer la tâche ouverte, puis on appelle gym.make("browsergym/openended", task_kwargs={"start_url": "https://www.google.com/"}, wait_for_user_message=True). L'option wait_for_user_message indique que l'environnement attend un message utilisateur après chaque message de l'agent envoyé au chat. La boucle enchaîne ensuite env.reset() puis env.step(action) jusqu'à ce que terminated ou truncated passe à vrai, et se termine par env.close(). L'action est laissée à l'implémentation : le README écrit action = ... et rien de plus. C'est cohérent avec un cadre de recherche, mais cela signifie aussi qu'aucun agent de référence n'est fourni dans cet exemple. Pour les tâches fermées, on remplace l'import et l'identifiant, par exemple browsergym/workarena.servicenow.order-ipad-pro.

Installation : choisir la granularité du paquet

L'installation se fait par pip, avec un découpage en paquets qui correspond aux benchmarks. pip install browsergym installe l'ensemble, browsergym-experiments ajoute les utilitaires d'expérience (agent, boucle, benchmarks) et tout ce qui se trouve en dessous, tandis que browsergym-core ne contient que le cœur, sans benchmark, avec pour seule tâche la tâche ouverte. Les variantes browsergym-miniwob, browsergym-webarena, browsergym-webarena-verified, browsergym-visualwebarena, browsergym-workarena, browsergym-assistantbench et browsergym-timewarp ajoutent chacune un benchmark au cœur. WebLINX passe par un paquet au nom différent, weblinx-browsergym. Ensuite vient une étape non négociable : playwright install chromium. Le README précise enfin que chaque benchmark exige des étapes supplémentaires, décrites dans son propre README. Pour le développement local, la séquence documentée est git clone, cd BrowserGym, make install.

Étendre le cadre : une classe à hériter

Le README affirme que concevoir un nouveau benchmark est simple et passe par l'héritage de la classe AbstractBrowserTask, située dans browsergym/core/src/browsergym/core/task.py. C'est le point d'extension central du projet, et il explique pourquoi l'API reste volontairement minimale : l'environnement ne sait rien du domaine, il sait piloter un navigateur et rendre une observation. Toute la sémantique d'une tâche, y compris la manière de calculer la récompense, vit dans la sous-classe. Cette séparation est saine pour la recherche, car elle permet de greffer un nouveau site ou un nouveau scénario sans toucher au cœur. Elle implique en revanche que la qualité d'un benchmark BrowserGym dépend entièrement du code de la sous-classe, et non du cadre lui-même.

Ce que le dépôt ne promet pas

L'avertissement placé en tête du README est le passage le plus utile du document : BrowserGym n'est pas destiné à être un produit grand public et doit être utilisé avec prudence. Il faut le prendre au sérieux. Le projet ne fournit pas de garantie de stabilité d'API entre versions, et la numérotation observée dans les releases, avec une v0.14.3.dev4 publiée avant la v0.14.3, montre un rythme de développement actif plutôt qu'un cycle lent. Autre limite documentaire : la licence. Le badge PyPI du README pointe vers Apache-2.0, mais les métadonnées du dépôt indiquent NOASSERTION. Un lecteur ne peut pas trancher à partir de ces seules informations, et une équipe qui doit intégrer ce code dans un contexte commercial doit lire le fichier LICENSE à la racine du dépôt plutôt que se fier au badge. Enfin, l'écosystème autour du projet, notamment AgentLab présenté comme un cadre pour implémenter, tester et évaluer des agents sur tous les benchmarks BrowserGym, suggère que BrowserGym n'est qu'une brique d'une chaîne plus large.

Face à Playwright seul

L'alternative la plus directe n'est pas un autre cadre d'agents, c'est Playwright employé directement. BrowserGym s'appuie d'ailleurs dessus, puisque l'installation demande playwright install chromium. La différence tient à la surface d'API. Avec Playwright seul, vous écrivez vos propres sélecteurs, votre propre boucle, votre propre calcul de réussite, et vous obtenez un contrôle total sur le navigateur et sur le format des observations. Avec BrowserGym, vous héritez d'une interface reset et step, d'un registre de tâches normalisé et de benchmarks déjà câblés, mais vous acceptez en échange la structure d'observation du cadre et la configuration propre à chaque benchmark. Pour un script d'automatisation ponctuel, Playwright seul est plus court. Pour comparer un agent sur WebArena et WorkArena sans réécrire deux harnais, BrowserGym fait gagner le travail d'intégration.

Coût de maintenance et de mise à jour

Le coût se répartit sur trois postes visibles dans le matériel fourni. Le premier est la dépendance à Chromium via Playwright : la commande playwright install chromium doit être rejouée dans chaque environnement, et la version du navigateur conditionne le comportement des pages. Le deuxième est la configuration par benchmark, puisque six des suites listées renvoient à un README dédié et que WorkArena et OpenApps renvoient à des documentations externes. Le troisième est le rythme de publication : trois versions listées entre août 2025 et janvier 2026, dont une pré-version, ce qui implique de suivre les notes de version avant de mettre à jour un harnais d'évaluation. Sur le plan juridique, l'écart entre le badge Apache-2.0 et le NOASSERTION des métadonnées doit être levé en lisant le fichier LICENSE du dépôt avant toute redistribution.

Conclusion éditoriale

BrowserGym s'adresse aux équipes de recherche qui doivent comparer des agents web sur plusieurs benchmarks avec une seule interface Gymnasium, et qui acceptent d'installer Playwright et de suivre un README de configuration par benchmark. Il ne convient pas à un produit grand public : l'avertissement du dépôt est explicite sur ce point. Avant d'investir, vérifiez deux choses concrètes : le fichier LICENSE à la racine, puisque le badge PyPI renvoie vers Apache-2.0 alors que l'API GitHub indique NOASSERTION, et le README propre à chaque benchmark que vous comptez exécuter.

Sources officielles

1. Issues
2. README
3. Releases
4. ServiceNow/BrowserGym on GitHub