BrowserWing : transformer des scripts de navigation en commandes MCP ou en Skills Claude
BrowserWing turns your browser actions into MCP commands Or Claude Skill, allowing AI agents to control browsers efficiently and reliably. Say goodbye to slow, token-heavy LLM interactions — let agents call commands directly for faster automation. Perfect for AI-driven tasks, browser automation, and boosting productivity.
En bref
- De quoi s’agit-il ?
- BrowserWing est un binaire Go accompagné d'une interface React qui enregistre des actions de navigation, les rejoue et les expose sous forme de commandes MCP ou de fichiers Skills. Le point à trancher avant de l'adopter : ce que vous gagnez en jetons dépensés par le modèle, vous le payez en dépendance à une version précise de Chrome et à des sélecteurs qui vieillissent.
- À qui s’adresse-t-il ?
- Adoptez BrowserWing si vous avez déjà identifié une poignée de parcours web stables que vos agents répètent souvent et que vous voulez arrêter de payer des jetons pour chaque clic. Passez votre chemin si vos cibles changent de structure chaque semaine, si vous ne pouvez pas installer Chrome dans l'environnement d'exécution, ou si vous devez auditer chaque action avant exécution.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 39 jours.
- En quel langage est-il écrit ?
- Principalement Go, 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 visé : le clic coûte plus cher que la décision
Quand un agent pilote un navigateur par le modèle, chaque étape passe par une inférence. Il faut décrire la page, choisir un élément, produire une action, observer le résultat, recommencer. Le README résume l'ambition du projet par une formule directe : permettre aux agents d'appeler des commandes directement, plutôt que de passer par des interactions lentes et gourmandes en jetons. BrowserWing prend cette phrase au sérieux et en fait une architecture : une action de navigation enregistrée une fois devient une commande nommée, que l'agent invoque sans avoir à raisonner sur le DOM.
Le public visé est précis. D'un côté, les développeurs qui construisent des agents et veulent leur donner des capacités web sans écrire un client Playwright complet. De l'autre, les utilisateurs d'outils compatibles MCP ou Skills qui préfèrent installer un binaire plutôt que maintenir du code de scraping. Le README annonce 78 scripts intégrés, avec des exemples comme github-trending, bilibili-hot et hackernews-top. Ce sont des cibles choisies pour être stables et populaires, ce qui est cohérent avec l'idée de commandes figées.
La limite de cette approche apparaît dès la formulation du problème. Une commande figée résout la lenteur, pas la variabilité. Elle suppose que la page ne change pas de structure entre l'enregistrement et l'exécution. C'est un pari raisonnable sur un classement de tendances, beaucoup moins sur une application métier derrière authentification.
Ce qui se passe entre l'enregistrement et l'appel MCP
Le mécanisme tient en trois étages. Un enregistreur visuel capture des actions dans le navigateur. Ces actions sont stockées, puis éditables dans l'interface. Enfin, elles sont exposées de deux façons : comme commandes MCP, ou comme fichier Skills. Le README décrit explicitement cette conversion : convertir les scripts enregistrés en commandes MCP ou en fichiers Skills pour l'intégration aux outils d'IA.
Côté transport, la configuration MCP donnée dans le README est un serveur HTTP pointant vers http://localhost:8080/api/v1/mcp/message, avec le type déclaré comme http. Autrement dit, BrowserWing tourne en local et votre outil d'IA s'y connecte par le réseau local. Il n'y a pas de service distant dans ce que décrit le README.
Le projet annonce aussi plus de 26 points d'entrée HTTP pour le pilotage du navigateur, ainsi qu'un agent conversationnel intégré. La gestion de session (cookies et stockage) est présentée comme un élément à part entière, ce qui est logique : sans persistance de session, toute cible authentifiée devient inaccessible. La partie extraction sémantique s'appuie sur un LLM, avec OpenAI, Claude et DeepSeek cités comme fournisseurs possibles. Cette brique est distincte des commandes enregistrées : elle sert quand la structure de la page n'est pas connue d'avance.
Le point d'architecture à retenir est donc le suivant. BrowserWing ne remplace pas le modèle, il déplace son intervention. Le modèle choisit quelle commande appeler. Le détail des clics est exécuté par le binaire.
Installation et premier appel en ligne de commande
Le chemin le plus court passe par npm. La commande d'installation globale, puis le lancement sur le port 8080 :
npm install -g browserwing && browserwing --port 8080
Le README indique que le paquet npm teste les miroirs GitHub et Gitee pendant l'installation et retient le plus rapide. Un script d'installation en une ligne existe aussi pour Linux et macOS via curl, et une version PowerShell pour Windows. Ce script détecte l'OS et l'architecture, télécharge le binaire, l'extrait et l'ajoute au PATH.
Sur macOS, le README signale une erreur possible de type killed au lancement, avec un remède explicite : xattr -d com.apple.quarantine $(which browserwing). C'est le genre de détail qui fait perdre une heure quand il n'est pas documenté, et il l'est ici.
Pour vérifier que l'outil répond avant de brancher un agent, les exemples du README sont directs :
browserwing run github-trending browserwing run hackernews-top | jq '.[0:5]'
L'usage de jq dans l'exemple indique que la sortie est du JSON exploitable en pipeline. C'est un choix cohérent avec l'objectif : une commande qui produit du texte destiné à un humain serait inutile pour un agent.
Côté compilation depuis les sources, le README donne make install, puis make build-embedded pour un binaire avec le frontend intégré, et mentionne make build-all et make package. Go et pnpm sont requis. La prérequis matériel est unique et non négociable : Chrome ou Chromium doit être installé et accessible dans l'environnement.
Le point de rupture : Chrome, les sélecteurs et l'audit
Trois contraintes méritent d'être posées avant tout déploiement.
La première est l'environnement. Le README liste Chrome ou Chromium comme seule exigence, sans alternative. Un conteneur minimal sans navigateur ne suffira pas. Il faut donc prévoir l'image, la version et les dépendances système, ce qui pèse plus lourd qu'un simple binaire Go.
La deuxième est la fragilité des sélecteurs. Un script enregistré encode une manière d'atteindre un élément. Si le site change ses classes ou sa structure, la commande échoue. Le README ne décrit pas de mécanisme de repli automatique vers l'extraction sémantique quand une commande enregistrée casse. C'est une lacune de conception, pas un détail d'implémentation : elle signifie que la maintenance des scripts retombe sur vous.
La troisième concerne les usages sensibles. Rien dans le matériel fourni ne décrit de journal d'audit, d'approbation avant exécution ou de bac à sable par commande. Un agent qui peut déclencher des commandes de navigation enregistrées agit sans que vous voyiez le détail des étapes. Sur un site interne, cette opacité est un vrai sujet.
Enfin, la maturité. Le dépôt n'est pas archivé et la dernière poussée est datée du 8 août 2026. Les versions récentes listées sont v1.1.1-beta.1, v1.1.0 et v1.0.1-beta.2. La présence de deux versions bêta dans une historique aussi court indique un projet encore en mouvement. Le README mentionne également une installation Homebrew comme à venir, ce qui confirme que la distribution n'est pas terminée.
Face à Playwright ou Puppeteer, la différence n'est pas la vitesse
La comparaison naturelle est Playwright ou Puppeteer. Ces bibliothèques vous font écrire du code : vous décrivez le parcours en TypeScript ou en Python, vous le versionnez, vous le testez, et vous l'exécutez. Le modèle n'intervient pas dans la boucle d'exécution.
BrowserWing prend le chemin inverse. Vous n'écrivez pas le parcours, vous l'enregistrez dans une interface, et vous l'exposez comme une commande que le modèle peut choisir. La différence pratique est double. D'un côté, vous n'avez pas à maintenir un client de navigateur ni à écrire la plomberie de session. De l'autre, vous échangez du code lisible contre un artefact produit par une interface graphique, dont la traçabilité dans Git est moins évidente.
Le second écart tient à l'appelant. Avec Playwright, c'est votre programme qui décide quand lancer le script. Avec BrowserWing en mode MCP, c'est le modèle qui décide quelle commande invoquer, dans une conversation. Cela déplace la question du contrôle : vous ne définissez plus seulement ce que fait le script, mais aussi ce que l'agent a le droit de déclencher. Le matériel fourni ne décrit pas de politique de permissions à ce niveau.
Reste un cas où BrowserWing est clairement le mauvais outil : quand la page cible est un formulaire complexe dont le parcours dépend de données variables à chaque exécution. Une commande figée ne sait pas s'adapter à un nombre d'étapes inconnu. Il faut alors soit revenir à du code, soit passer par l'extraction sémantique pilotée par LLM, ce qui annule le bénéfice de jetons recherché au départ.
Coût de maintenance et implications de la licence MIT
Le coût de maintenance se répartit en trois postes. Le premier est le suivi de Chrome : le binaire dépend d'un navigateur installé, et une montée de version majeure peut affecter le comportement. Le deuxième est la surveillance des scripts : chaque commande enregistrée pointe vers une structure de page qui peut changer sans préavis, et le README ne décrit pas de détection de rupture. Le troisième est le suivi des versions de BrowserWing lui-même, avec des publications bêta régulières qui suggèrent des changements fréquents.
Le projet est publié sous licence MIT. Cela autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Cette description est factuelle : elle ne constitue pas un avis juridique, et une organisation qui distribue BrowserWing à l'intérieur d'un produit devrait faire valider les obligations de mention par ses propres responsables juridiques.
Un point mérite attention du côté des dépendances. Le README mentionne un sponsor, Swiftproxy, qui fournit des proxys résidentiels et propose un code de réduction aux utilisateurs de BrowserWing. Ce parrainage n'affecte pas la licence du logiciel, mais il indique que le projet cherche un modèle de financement. Pour un outil que vous placez au cœur de votre chaîne d'automatisation, la question de la pérennité du financement se pose légitimement.
Enfin, le paquet npm télécharge un binaire depuis GitHub ou Gitee. Cela implique une dépendance réseau à l'installation, et une chaîne d'approvisionnement qu'il faut pouvoir vérifier si votre contexte l'exige.
Conclusion éditoriale
Adoptez BrowserWing si vous avez déjà identifié une poignée de parcours web stables que vos agents répètent souvent et que vous voulez arrêter de payer des jetons pour chaque clic. Passez votre chemin si vos cibles changent de structure chaque semaine, si vous ne pouvez pas installer Chrome dans l'environnement d'exécution, ou si vous devez auditer chaque action avant exécution. Avant de vous engager, lancez browserwing run github-trending et vérifiez que la sortie correspond bien à ce que vous attendez, puis ouvrez http://localhost:8080 pour confirmer que l'interface d'enregistrement s'affiche correctement sur votre système.
Notes de la communauté