Agent IA : automatiser le navigateur avec Browser Use

Avec Browser Use, votre application peut confier une tâche sur un site web à un agent IA tout en gardant la main sur l’automatisation web. Sa bibliothèque open source nécessite Python 3.11 ou une version ultérieure ; Browser Use Cloud peut héberger le navigateur ou l’agent complet. Commencez par une tâche dont vous pouvez vérifier le résultat, comme consulter un enregistrement sur un portail, avant de l’autoriser à valider des modifications.

Informations vérifiées dans le README GitHub de Browser Use et la documentation officielle citée, le 2 novembre 2026. Le tutoriel ci-dessous est adapté de cette documentation ; il ne s’agit pas d’un test de performances réalisé par nos soins.

Comment Browser Use fait-il agir un agent IA ?

Browser Use relie un modèle de langage à un navigateur : votre application décrit un objectif au lieu de dicter chaque clic. Il se prête notamment à la recherche d’un enregistrement sur un portail fournisseur, à la consultation d’un tableau de bord ou au parcours d’un formulaire dont l’écran suivant dépend de la réponse précédente. La bibliothèque open source fournit l’agent, c’est-à-dire le logiciel qui choisit et exécute successivement les actions nécessaires pour atteindre cet objectif. README de la bibliothèque

Imaginez le modèle de langage au volant, Browser Use comme les commandes et les informations à sa disposition, et le navigateur comme le véhicule. La route reste le site web de quelqu’un d’autre. Même un bon conducteur ne peut pas rendre une route fermée accessible, ni décider qu’une livraison l’autorise à effectuer un achat sans rapport.

La boucle se déroule ainsi :

1. Observer : recueillir l’état actuel de la page, notamment ses éléments interactifs. Browser Use peut aussi transmettre des captures d’écran au modèle.
2. Décider : le grand modèle de langage, ou LLM, choisit l’action suivante à partir de la tâche et de l’état actuel.
3. Agir : le navigateur change de page, clique, saisit du texte ou effectue une autre opération disponible.
4. Observer à nouveau : la décision suivante s’appuie sur la page modifiée. La boucle continue jusqu’à l’arrêt de l’agent ou jusqu’à ce qu’une limite configurée l’interrompe.

Le DOM, l’arborescence structurée des éléments d’une page, permet de repérer les commandes sur lesquelles l’agent peut agir ; les captures d’écran apportent le contexte visuel. La documentation de Browser Use décrit à la fois le traitement du DOM et des fonctions de vision configurables. Le réduire à un modèle qui regarde des images serait donc trompeur. Paramètres du navigateur, paramètres de l’agent

Pour un fondateur qui développe un assistant d’approvisionnement, une tâche utile pourrait être : « trouver le statut d’expédition de cette commande ». Le critère de validation est la bonne commande, accompagnée de son statut et d’un enregistrement source. Un paragraphe convaincant rédigé par l’agent ne suffit pas.

Browser Use open source : que faut-il installer ?

L’installation de base comprend le package Python browser-use, un navigateur à piloter et l’accès à un modèle compatible. La bibliothèque est sous licence MIT. Son README demande Python 3.11 ou une version ultérieure, tandis que le guide de démarrage utilise Python 3.12. Vous pouvez exécuter l’agent dans votre propre processus et choisir un navigateur local ou distant. README et installation

« Local » désigne l’endroit où s’exécute ce processus ou ce navigateur. Si vous choisissez l’API d’un modèle distant, les observations sont tout de même envoyées à ce service : un navigateur local ne rend pas tout le système local.

Quels modèles peuvent piloter le navigateur ?

Browser Use propose des adaptateurs pour plusieurs fournisseurs ; son propre modèle n’est donc pas imposé :

• Browser Use BU2 : ChatBrowserUse(model="bu-2-0"), avec BROWSER_USE_API_KEY.
• Modèles OpenAI : ChatOpenAI, avec OPENAI_API_KEY.
• Modèles Anthropic Claude : ChatAnthropic, avec ANTHROPIC_API_KEY.
• Modèles Google Gemini : ChatGoogle, avec GOOGLE_API_KEY.
• Modèles locaux via Ollama : ChatOllama, connecté à votre service de modèle local.

La documentation des modèles compatibles répertorie aussi des intégrations pour DeepSeek, Mistral, Microsoft Azure OpenAI, Amazon Web Services Bedrock et OpenRouter. Vérifiez les modèles actuellement disponibles chez le fournisseur : un ancien identifiant donné en exemple ne vaut pas recommandation.

La présence d’un adaptateur ne garantit pas la qualité. Cette même documentation signale que certains modèles Qwen produisent un schéma d’action incorrect, autrement dit des instructions dans un format que l’agent ne peut pas exécuter. Elle recommande actuellement qwen-vl-max pour cette intégration. Évaluez un modèle sur vos pages réelles et les résultats attendus avant d’élargir ses responsabilités.

L’interface Browser Use Web UI

Browser Use Web UI est un projet distinct doté d’une interface Gradio, qui permet d’interagir avec l’agent depuis une interface web. Il possède sa propre procédure d’installation et ses propres dépendances. Pour intégrer Browser Use à une application, partez de la documentation actuelle de la bibliothèque Python ; ne mélangez pas l’installation du dépôt Web UI avec le SDK du service hébergé.

Qu’apporte Browser Use Cloud ?

Browser Use Cloud permet de déléguer l’infrastructure du navigateur, l’agent complet, ou les deux. Ces choix déterminent la quantité de code que vous devez exploiter. Le guide de démarrage Cloud actuel les distingue explicitement :

Avec votre propre agent, Browser(use_cloud=True) sélectionne le navigateur hébergé de Browser Use et nécessite BROWSER_USE_API_KEY. Ce navigateur géré apporte des fonctions de navigation furtive, des proxys et un aperçu en direct ; le README décrit aussi la prise en charge des CAPTCHA, en précisant que les résultats dépendent du site et du défi rencontré. Guide du navigateur Cloud, README

CDP, le Chrome DevTools Protocol, assure la connexion de pilotage à distance dans l’option d’infrastructure décrite par la documentation. Un navigateur hébergé peut donc servir à du code que vous continuez à exécuter vous-même.

Pour l’option entièrement hébergée, le package à utiliser est browser-use-sdk, et non browser-use. Les exemples Cloud actuels reposent sur l’API V4 et l’import Python from browser_use_sdk.v4 import BrowserUse. Votre programme envoie une tâche et récupère son résultat au lieu d’exécuter localement la boucle Agent. Guide de démarrage des agents hébergés

Pour le développeur, c’est un choix de déploiement. Pour la personne qui exploite le système, la responsabilité reste la même : définir les accès de l’agent et les preuves qui permettent de considérer une tâche comme terminée.

Quand choisir une alternative à Browser Use ?

Choisissez la couche que vous souhaitez maîtriser. Browser Use constitue un bon point de départ lorsque la tâche reste dans des sites web et que vous voulez une boucle d’agent navigateur prête à l’emploi, avec le choix du modèle. Une API de pilotage d’ordinateur convient si vous souhaitez construire votre intégration autour de son interface d’actions ou intervenir au-delà des pages web.

OpenAI propose aussi une Agents API distincte, avec un navigateur hébergé par OpenAI. La règle « le pilotage d’ordinateur impose toujours d’héberger soi-même son navigateur » n’est donc plus pertinente. Browserbase propose également des produits d’agents au-delà de son infrastructure de navigateur.

Browser Use et Browserbase ne s’excluent pas nécessairement : Browser Use accepte un cdp_url, et Browserbase fournit une URL de connexion CDP. Ces interfaces documentées offrent une voie pour associer la bibliothèque d’agent à cet environnement d’exécution, sans que cet article prétende avoir testé l’intégration. Paramètres de connexion de Browser Use

Conservez une API fiable ou un script de navigateur prédéfini s’ils font déjà le travail. Un formulaire stable ne gagne rien à ce qu’un modèle redécouvre la même séquence à chaque fois. Le guide des agents de pilotage d’ordinateur aide à choisir le mode de contrôle ; le comparatif des navigateurs pour agents IA examine les infrastructures.

Les risques qui restent à la charge de votre application

En production, la frontière la plus délicate est celle des actions autorisées dans un navigateur connecté à un compte. L’héberger ailleurs ne rend pas les instructions des pages fiables et n’efface pas les conséquences d’une validation erronée.

L’injection de prompt depuis le contenu d’une page

Il y a injection de prompt lorsqu’un contenu lu par l’agent tente de détourner ses instructions. Sur un portail, il peut s’agir d’une note saisie par un client qui demande à l’agent d’envoyer un rapport vers une autre destination. Traitez cette note comme une donnée, même si elle se présente comme une consigne d’administrateur.

Utilisez des comptes dédiés dotés uniquement des permissions nécessaires à la tâche. Limitez la navigation avec le paramètre allowed_domains de Browser Use et imposez une approbation pour les actions à conséquences dans votre application ou votre environnement d’exécution. Un site autorisé peut tout de même afficher du contenu malveillant publié par des utilisateurs : une liste de domaines ne suffit donc pas à établir la confiance. Restrictions du navigateur, consignes de sécurité pour le pilotage d’ordinateur

Un prompt qui dit « demander avant d’envoyer » n’impose pas une véritable limite de permissions. Si votre intégration ne peut pas intercepter l’action concernée de manière fiable, retirez cette action des permissions de l’agent et confiez-la à une personne. Le guide de l’injection de prompt explique comment lier l’approbation à l’action précise qu’elle autorise.

Connexions, stockage de session et journaux

Une connexion enregistrée donne accès au compte. Browser Use peut réutiliser Chrome avec Browser.from_system_chrome() ou charger des cookies et le stockage local sauvegardés avec Browser(storage_state="auth.json"). Protégez ce fichier d’état comme un identifiant de connexion, excluez-le du contrôle de version et évitez d’utiliser un profil de navigateur personnel pour une tâche professionnelle sans supervision. Documentation de l’authentification

La migration présente une limite précise : le README indique que la synchronisation d’un profil local transfère les cookies, mais pas le stockage local, IndexedDB ni les extensions. IndexedDB est un autre système de stockage de données côté navigateur. Par ailleurs, les profils Cloud peuvent conserver les cookies, le stockage local et l’état de connexion d’un navigateur cloud à l’autre. Cette persistance ne signifie pas que la synchronisation locale a copié tous les mécanismes de stockage. Certains sites demanderont une nouvelle connexion. Limite de la synchronisation

Prévoyez un profil distinct pour chaque utilisateur final. Avant de traiter des données privées issues d’un portail, examinez aussi ce qui entre dans les données transmises au modèle, les captures d’écran et les historiques de conversation enregistrés. Browser Use fournit des paramètres pour les captures d’écran et la sauvegarde des conversations ; configurez-les en connaissance de cause. Paramètres de l’agent

Limites de débit et relances au résultat incertain

Disposer d’un navigateur cloud ne donne pas un accès illimité au site cible. Prévoyez séparément les limites du service de modèle, la capacité et les limites de requêtes de Browser Use Cloud, ainsi que les limitations de débit ou les vérifications imposées par le site lui-même.

Limitez les tâches simultanées sur chaque site cible, espacez les tentatives lorsqu’il demande un délai et cessez de répéter les tentatives bloquées. En cas d’erreur de l’API Cloud, déterminez si le problème vient de la capacité ou de la fréquence des requêtes et respectez les consignes de nouvelle tentative renvoyées. Limites du Cloud

Surtout, ne renvoyez pas une opération simplement parce que votre client a dépassé son délai d’attente. Vérifiez d’abord l’exécution en cours et l’enregistrement dans le système destinataire. Un délai dépassé peut laisser planer le doute sur une action qui a déjà eu lieu.

Premier lancement avec la documentation Browser Use

Commencez par une page publique et une tâche en lecture seule. Cela permet de vérifier que le package, le navigateur et le modèle communiquent, sans connexion à un compte ni transaction métier. Les commandes suivent le guide de démarrage open source ; cet exemple reprend son environnement Python 3.12 et la sélection explicite du modèle BU2 indiquée dans le README.

Configurer Browser Use en Python

1. 1

   Installer le package et le navigateur

   Sur macOS ou Linux, avec Python et pip disponibles, ouvrez un terminal Bash dans un nouveau répertoire de projet :

   pip install uv
   uv venv --python 3.12
   source .venv/bin/activate
   uv pip install browser-use
   uvx browser-use install

   La dernière commande installe le navigateur. Sous Windows, utilisez la commande d’activation de l’environnement indiquée dans le guide de démarrage à la place de source.

2. 2

   Configurer la clé d’accès au modèle

   Créez une clé API Browser Use dans le tableau de bord accessible depuis le guide de démarrage. Dans le même terminal Bash, saisissez-la sans l’afficher :

   read -rsp "Browser Use API key: " BROWSER_USE_API_KEY
   printf '\n'
   export BROWSER_USE_API_KEY

   Cette clé donne accès au service du modèle choisi. Elle ne déplace pas automatiquement le navigateur vers le Cloud.

3. 3

   Exécuter une petite tâche en lecture seule

   Enregistrez ce code dans agent.py :

   import asyncio
   from browser_use import Agent, ChatBrowserUse
   
   async def main():
       agent = Agent(
           task=(
               "Open https://example.com and report the page heading. "
               "Do not follow links or submit anything."
           ),
           llm=ChatBrowserUse(model="bu-2-0"),
       )
       history = await agent.run()
       print(history.final_result())
   
   if __name__ == "__main__":
       asyncio.run(main())

   Puis lancez :

   python agent.py

   Vérifiez vous-même que le titre renvoyé correspond à celui de la page. La consigne de la tâche constitue une contrainte de départ adaptée à cet exemple sans enjeu ; en production, les restrictions doivent être imposées en dehors du prompt.

En cas d’échec, lisez l’erreur avant de changer de modèle : l’installation du navigateur, l’authentification auprès du modèle et l’accès au site sont des sources de panne distinctes. Une fois l’exemple fonctionnel, conservez les versions des dépendances utilisées et passez à un compte de test sur le site visé.

Quelles promesses faut-il relativiser ?

Une exécution terminée ne prouve pas qu’une transaction métier a abouti. La documentation des résultats de Browser Use distingue clairement les deux : is_done() signifie que l’agent a émis une action de fin ; is_successful() reflète sa propre évaluation. Les résultats externes importants doivent toujours être vérifiés dans le système destinataire. Signification des résultats

Pour un changement d’adresse, contrôlez l’adresse enregistrée. Pour un rapport téléchargé, examinez le fichier et la période couverte. Pour un envoi, recueillez la confirmation du système destinataire et levez les incertitudes sur le résultat avant de réessayer.

La même prudence s’impose face à la promesse « fonctionne sur tous les sites ». Les fonctions du navigateur géré peuvent faciliter l’accès, mais le README du projet ne promet pas de contourner ou de résoudre tous les CAPTCHA. Un meilleur modèle ne peut pas non plus accorder des permissions que l’utilisateur ne possède pas. Concevez votre intégration à partir du comportement réel du site, y compris le moment où une personne doit reprendre la main.

Par quoi commencer dès lundi ?

Pour un fondateur technique, le premier pilote utile est une tâche de lecture bien délimitée sur un portail, avec une réponse claire à obtenir. Utilisez un compte de test distinct, identifiez les pages autorisées et décrivez comment vous vérifierez l’enregistrement renvoyé. Consignez les échecs aussi bien que les exécutions terminées.

Ne passez à la préparation de formulaires qu’après avoir compris ces échecs. Confiez la validation à une personne tant que votre application ne peut pas imposer une approbation, contrôler le résultat enregistré et reprendre après un incident sans répéter l’action. Si une API prise en charge ou un script stable couvre le workflow, conservez cette intégration plus simple.

Pour des conseils pratiques sur la création de workflows IA fiables, abonnez-vous à la newsletter.