Comment connecter un réseau neuronal à un navigateur réel avec Browser Harness

Tous ceux qui ont essayé d'automatiser le web avec des modèles de langage connaissent cette frustration. L'agent commence joyeusement à cliquer sur les boutons, mais se bloque dès le premier champ de saisie non standard ou un captcha difficile. Les frameworks traditionnels offrent un ensemble rigide d'outils : cliquer, taper, défiler. Si l'action requise n'est pas dans le code de l'agent, la tâche échoue.

L'équipe browser-use a proposé une approche différente dans le projet browser-harness. Au lieu d'essayer d'anticiper à l'avance tous les scénarios possibles de pages web, ils ont créé un wrapper qui connecte un LLM à votre vrai navigateur via le Chrome DevTools Protocol (CDP) et donne au modèle la capacité d'écrire des fonctions manquantes à la volée.

Quelle est l'idée derrière le wrapper auto-apprenant

Un agent navigateur classique fonctionne de manière isolée. Il obtient un navigateur headless isolé sans sessions sauvegardées, cookies ou autorisations. Résultat : la moitié du temps est perdue à essayer de se connecter.

Browser Harness se connecte directement à votre Chrome en cours d'exécution via le port de débogage. Le modèle voit immédiatement les onglets ouverts, vos profils et l'environnement de travail.

La partie la plus intéressante réside dans la mécanique de gestion du code :

1. L'agent reçoit une tâche, par exemple télécharger les vingt dernières vidéos d'un profil de réseau social ou remplir un formulaire complexe avec une zone de dépôt de fichiers.
2. Le modèle vérifie le fichier local agent-workspace/agent_helpers.py. S'il n'y a pas de fonction adaptée pour travailler avec l'élément, l'agent écrit lui-même un script d'assistance.
3. Le script est immédiatement exécuté dans le contexte de la page. S'il fonctionne avec succès, la fonction est sauvegardée dans l'espace de travail.
4. Lors de l'exécution de la prochaine tâche similaire, l'agent ne réinvente pas la roue mais utilise le helper précédemment écrit.

Dans le même temps, le cœur de la bibliothèque elle-même dans le dossier src/browser_harness/ reste protégé des modifications. Le modèle étend uniquement son propre espace de travail local, donc le risque de casser la logique principale est minime.

Comment fonctionne le lancement

Le projet est tightly intégré avec les environnements de développement agentiques comme Claude Code ou Codex. Pour commencer, il suffit de fournir à votre assistant une invite d'installation prête à l'emploi :

Install or upgrade browser-harness to the latest stable version with uv using Python 3.12, register the skill from `browser-harness skill`, and connect it to my browser. Ask whether I want local browser recordings enabled; default to no and preserve my existing preference on upgrades. Follow https://github.com/browser-use/browser-harness/blob/main/install.md if setup or connection fails.

Après avoir exécuté la commande, l'onglet chrome://inspect/#remote-debugging s'ouvrira. Vous devez y cocher la case de débogage à distance afin que l'agent ait accès au WebSocket CDP :

Toute la pile est maintenue ensemble par trois fichiers clairs :

• Les instructions install.md gèrent la connexion initiale au navigateur via le port de débogage.
• Le fichier SKILL.md décrit les modèles d'interaction avec les pages pour le LLM.
• Les modules du répertoire src/browser_harness/ maintiennent un socket persistant et transmettent les commandes.

Ce qu'il y a à l'intérieur et quelles technologies sont utilisées

Sous le capot, le projet utilise Python 3.12 et le gestionnaire de paquets uv. La gestion des sessions utilise un WebSocket direct vers CDP, sans wrappers lourds comme Selenium.

Cette approche offre deux avantages pratiques :

• Latence minimale lors de la transmission des événements d'entrée, du défilement et des clics.
• Accès complet au DOM, aux requêtes réseau et au stockage du navigateur sans avoir besoin de configurer des ponts supplémentaires.

Si vous avez besoin d'exécuter des dizaines de tâches en parallèle, les créateurs proposent l'infrastructure Browser Use Cloud avec des proxies prêts à l'emploi, une protection anti-bot-detector et une résolution de captcha. Mais pour les exécutions locales quotidiennes sur votre propre navigateur, c'est plus que suffisant.

Cas d'utilisation pratiques

Là où un tel outil fait vraiment gagner du temps :

• Collecter des données à partir de tableaux de bord privés où il n'y a pas d'API publique et où l'authentification à deux facteurs est configurée. Vous vous authorizez manuellement une fois, puis confiez l'exportation routine du rapport à l'agent.
• Téléchargements massifs de fichiers médias. L'agent ouvre la page, fait défiler le fil, trouve les sélecteurs du lecteur vidéo nécessaire et enregistre les fichiers dans un dossier local.
• Tester les mises en page et les scénarios utilisateur. L'agent parcourt le parcours utilisateur, écrit lui-même les vérifications manquantes et les stocke dans les helpers.
• Remplir des formulaires répétitifs dans les systèmes CRM d'entreprise lorsque vous devez transférer un lot de données depuis un tableur.

Cela vaut-il la peine d'essayer

Si vous utilisez activement des outils CLI agentiques comme Claude Code et que vous êtes fatigué de copier manuellement des données des pages vers le terminal, le projet mérite définitivement d'être essayé. Le concept où l'agent étend lui-même sa boîte à outils grâce à des helpers persistants semble beaucoup plus viable que de gonfler indéfiniment le system prompt.

Parmi les inconvénients, je noterai que le projet nécessite une attention particulière à la sécurité : en donnant à un LLM l'accès à votre navigateur principal, vous partagez toutes les sessions ouvertes. Donc pour les expériences, il est plus judicieux de créer un profil Chrome séparé sans cartes bancaires liées et services critiques. Commencez par des scénarios de parsing simples, regardez comment l'agent génère ses premières fonctions dans agent_helpers.py, et évaluez à quel point ce format s'intègre dans votre pile habituelle.