Vibium - un outil d’automatisation de navigateur pour l’IA et les humains

 (github.com/VibiumDev)
14 points par GN⁺ 2025-12-25 | 1 commentaires | Partager sur WhatsApp
  • Projet open source d’automatisation de navigateur redéveloppé en pensant aux agents IA par Jason Huggins, qui avait créé Selenium il y a 21 ans
  • Vibium est une infrastructure d’automatisation de navigateur pour les agents IA, qui gère le cycle de vie du navigateur et le protocole WebDriver BiDi dans un binaire unique, tout en exposant un serveur MCP
  • Clicker, un binaire Go unique de 10 Mo, détecte et lance automatiquement Chrome, et permet à des modèles d’IA ou à des clients JS de contrôler le navigateur via un proxy BiDi et un serveur MCP
  • Le client JS/TS prend en charge à la fois des API synchrones et asynchrones, et peut être utilisé immédiatement après installation avec npm install vibium
  • Des agents LLM comme Claude Code peuvent ajouter des capacités de contrôle du navigateur avec une seule commande claude mcp add vibium
  • Adapté à la fois à l’automatisation par IA et à l’automatisation de tests, il fournit un environnement de contrôle du navigateur sans configuration

Présentation de Vibium

  • Vibium est une infrastructure d’automatisation de navigateur pour les agents IA et les utilisateurs humains
    • Un binaire Go unique regroupe la gestion du navigateur, un proxy WebDriver BiDi et les fonctions de serveur MCP
    • Compatible avec divers modèles LLM comme Claude Code, Codex et Gemini
  • Son architecture fonctionne immédiatement sans procédure d’installation, ce qui la rend exploitable pour les agents IA comme pour les environnements d’automatisation de tests

Composants

  • Clicker : binaire Go d’environ 10 Mo, qui assure les fonctions suivantes
    • Détection automatique de Chrome et lancement en mode BiDi
    • Transmission des commandes via un serveur proxy BiDi fondé sur WebSocket
    • Communication avec les agents LLM via un serveur MCP
    • Fonction Auto-Wait pour attendre les éléments avant interaction
    • Fonction de capture de captures d’écran
  • Client JS/TS : fourni sous forme de paquet npm, avec prise en charge des API synchrones (browserSync) et asynchrones (browser)
    • Contrôle du navigateur avec des commandes simples comme vibe.go(), vibe.find(), vibe.click() et vibe.quit()
    • Inclut les fonctions d’automatisation de base comme l’enregistrement de captures d’écran, la recherche d’éléments et le clic

Intégration avec les agents IA

  • Commande pour ajouter le contrôle du navigateur à Claude Code : 
    claude mcp add vibium -- npx -y vibium
    • Chrome est téléchargé automatiquement, sans configuration supplémentaire
  • Liste des commandes fournies
    • browser_launch : lancer le navigateur
    • browser_navigate : aller vers une URL
    • browser_find : rechercher un élément via un sélecteur CSS
    • browser_click : cliquer sur un élément
    • browser_type : saisir du texte
    • browser_screenshot : capturer le viewport
    • browser_quit : fermer le navigateur

Installation pour les utilisateurs humains

  • Installation automatique avec la commande npm install vibium
    • Télécharge dans le cache, selon la plateforme, le binaire Clicker, Chrome for Testing et chromedriver
    • Linux : ~/.cache/vibium/, macOS : ~/Library/Caches/vibium/, Windows : %LOCALAPPDATA%\vibium\
  • La variable d’environnement VIBIUM_SKIP_BROWSER_DOWNLOAD=1 permet d’ignorer le téléchargement du navigateur

Prise en charge des plateformes

  • Prise en charge de Linux x64, macOS (Intel/Apple Silicon) et Windows x64

Démarrage rapide

  • Exemple d’utilisation de la bibliothèque 
    import { browser } from "vibium";  
const vibe = await browser.launch();  
await vibe.go("https://example.com";);  
const el = await vibe.find("a");  
await el.click();  
await vibe.quit();
  • Exemple d’intégration avec Claude Code
    • Après l’installation, il est possible de piloter le navigateur avec une commande comme « Go to example.com and click the first link »

Feuille de route

  • V1 : priorité au contrôle du navigateur via MCP et le client JS
  • Plan V2
    • Clients Python et Java
    • Cortex (couche mémoire et navigation)
    • Retina (fonctionnalités d’extension pour l’enregistrement)
    • Enregistrement vidéo et recherche d’éléments assistée par IA

À lire aussi

1 commentaires

 
GN⁺ 2025-12-25
Commentaires Hacker News

  • Selenium a eu un impact majeur sur ma carrière. Un immense merci, sincèrement
    J’utilise Playwright ces temps-ci, mais la nouvelle approche de Vibium m’intrigue

    • Playwright a beaucoup fait avancer les choses grâce à son contrôle rapide du navigateur basé sur WebSockets+JSON. Vibium utilise de son côté le standard W3C WebDriver BiDi correspondant. L’objectif est d’offrir une superbe expérience développeur, du genre « quelques clics et c’est réglé », comme Playwright
    • Si vous utilisez déjà Playwright, je recommande d’essayer Stagehand. L’API est similaire, mais l’outil est conçu pour l’automatisation et non pour les tests

  • Je me demande si Vibium prend en charge l’injection de JS, la modification du DOM, ainsi que la surveillance et la modification des requêtes réseau. Avec Playwright, j’utilise presque toujours ces fonctionnalités

    • Ce n’est pas encore pris en charge, mais c’est sur la roadmap. L’objectif est d’adopter les points forts de Playwright puis d’aller au-delà
    • Personnellement, rien que la surveillance des requêtes réseau me suffirait. Les applis Flutter + Amazon AppSync sont vraiment trop difficiles à déboguer

  • Intéressant. J’utilisais récemment dev-browser, ce qui m’apportait une meilleure conservation du contexte et plus de vitesse. Je compte clairement tester Vibium aussi

    • Vibium prévoit aussi de prendre en charge ce type d’extensibilité basée sur les skills

  • En tant que personne qui vit de l’automatisation d’interface depuis plus de 10 ans, merci à Selenium. Aujourd’hui, Playwright est de facto le standard, mais Selenium a été le pilote de navigateur originel. Je me demande en quoi Vibium diffère de Playwright

    • Playwright est en avance sur la vitesse, mais Selenium conserve un écosystème profondément enraciné dans le monde entier. Vibium prévoit de construire un pont permettant aux utilisateurs de Selenium de passer naturellement vers le coding agentique du futur

  • Je suis la personne qui avait aidé Atlassian à étendre ses tests avec Selenium à l’époque. Je me souviens de nos échanges d’il y a 13 à 15 ans. Ravi de voir que vous êtes toujours actif dans ce domaine

  • Je me demande si la migration d’anciens scripts Selenium vers Vibium permettra de profiter d’une fonction de self-heal en cas d’échec des tests

    • Pour prendre une image, je suis en train de construire un resort sur une île. Le pont (le chemin de migration) viendra plus tard. Si le resort est attractif, il y aura alors une bonne raison de construire le pont. Pour l’instant, je me concentre sur le resort, mais je veux vraiment construire le pont aussi

  • Je me demande comment l’agent trouve le sélecteur CSS quand il capture l’écran avec browser_screenshot puis doit cliquer. Avec une simple capture d’écran, il est difficile de connaître le type des éléments

    • À l’heure actuelle, le serveur MCP manque de vraies capacités d’exploration autonome. Dans mon fork, j’ai ajouté l’outil browser_evaluate pour récupérer l’arbre d’accessibilité en JS et permettre l’exploration à partir de là. Voir la roadmap V2 pour plus de détails

  • Pour laisser un outil comme Claude utiliser librement l’automatisation du navigateur, il faut une fonction de verrouillage du navigateur n’autorisant que certaines URL. Je me demande si c’est sur la roadmap

    • Si vous utilisez Claude Code, c’est facile à contrôler avec le hook browser_navigate. Un script de whitelist se configure en 5 minutes. Pour des politiques plus complexes, on peut utiliser cupcake et Rego. Référence : documentation Claude Code Hooks
    • Je connais bien le risque de « blast radius » de Claude. Moi aussi, je développe Vibium dans une VM UTM. J’envisage également d’ajouter des règles réseau. J’ai déjà publié la roadmap V2, et il va sans doute falloir préparer un brouillon pour V3 aussi
    • La méthode la plus sûre reste de n’autoriser qu’une courte whitelist à l’intérieur d’un conteneur avec pare-feu

  • J’envisageais de créer quelque chose de similaire à Skyvern, mais je me demande pourquoi vous avez choisi de créer un nouveau Vibium plutôt qu’une extension de Selenium

    • J’en explique une partie dans l’annonce de Vibium v1. Selenium comme Playwright n’avaient pas été conçus autour de l’IA. Vibium, lui, a été pensé dès le départ avec une architecture optimisée pour le « vibe coding » basé sur l’IA

  • Je me demande comment vous gérez le problème de surcharge de contexte (context bloat) entre le navigateur et le LLM. La question porte aussi sur une éventuelle exposition de fichiers de tracing comme dans Playwright, ou sur la possibilité d’autoriser l’exécution de JS

    • L’exposition du navigateur va s’élargir progressivement. Personne n’a encore vraiment résolu parfaitement la surcharge de contexte. À long terme, la réponse pourrait même être de « ne pas utiliser MCP ». Pour l’instant, Vibium propose deux options : un serveur MCP et une API JS/TS. Dans l’API JS/TS, l’exécution de JS arbitraire est possible. Faire en sorte que l’agent écrive puis exécute des scripts Vibium pourrait être une solution de contournement pour réduire la surcharge de contexte