browser-use est l'une des bibliothèques d'agents navigateurs les plus commentées de ces deux années : vous énoncez une tâche en une phrase, et l'outil ouvre lui-même un navigateur, lit les pages, clique sur les boutons et remplit les formulaires jusqu'à livrer le résultat. On dirait le point final de l'automatisation. En pratique, cela ressemble plutôt à un stagiaire brillant facturé au pas : capable, et tout à fait apte à tomber dans chaque piège du parcours.
Informations sur le dépôt officiel
Le projet est hébergé sur GitHub, organisation browser-use, dépôt également nommé browser-use, licence MIT, écrit en Python, avec largement plus de cent mille étoiles. En dessous, Playwright pilote un vrai navigateur, tandis qu'une boucle d'agent comprend la page et décide de l'action suivante. On peut y brancher les modèles d'OpenAI, d'Anthropic, de Google et d'autres, ainsi que des modèles locaux. L'équipe vend aussi un service de navigateur cloud hébergé, qui est une offre distincte ; auto-héberger la bibliothèque elle-même ne coûte rien.
Le fonctionnement, c'est la facturation
Chaque pas se déroule ainsi : la structure de la page courante est transformée en texte pour le modèle, le modèle décide où cliquer ou quoi saisir, l'action s'exécute, et la boucle regarde la nouvelle page. Une tâche en apparence simple, comparer des prix sur quelques sites et remplir un tableau, consomme facilement vingt à trente pas, donc vingt à trente appels au modèle. Avec un modèle haut de gamme, une tâche peut coûter un ordre de grandeur de plus que prévu ; avec un modèle bon marché, les erreurs de jugement multiplient les pas et la facture remonte quand même. La façon honnête d'économiser est de mesurer le coût par tâche sur un travail réel avant de passer à l'échelle.
Coût de déploiement : facile à installer, plus dur à garder en vie
L'installation locale n'est pas exigeante : un environnement Python, Playwright et un navigateur suffisent, la première fois relève surtout des téléchargements et des dépendances. Le travail permanent est ailleurs : un navigateur sans affichage sur serveur demande de gérer polices, fenêtres surgissantes, délais et mémoire, et une seule refonte de site peut casser une tâche qui marchait la veille. Quelqu'un doit donc surveiller et réparer. En script ponctuel, tout cela est indifférent ; en système de production, il faut le personnel d'un service.
Quatre pièges bien réels
D'abord, les murs de connexion et les captchas. Les sites exigeant identification, code SMS ou vérification humaine bloquent régulièrement l'agent ; réutiliser l'état connecté de votre vrai navigateur en contourne une partie, mais expose votre compte à un programme automatisé, à vos risques. Ensuite, l'injection de prompt par les pages web. Le texte d'une page devient le contexte du modèle, et une page hostile peut l'inciter à cliquer au mauvais endroit ou à divulguer ce que vous lui avez confié ; les tâches de paiement et de compte doivent être isolées. Troisièmement, des taux de réussite instables. La même tâche réussit aujourd'hui et échoue demain, ce qui exclut les exécutions sans surveillance pour des commandes ou des inscriptions impossibles à refaire. Quatrièmement, la lenteur. Chaque pas attend le modèle, quelques minutes par tâche sont banales, et en lot, le temps et la facture d'API grandissent ensemble.
L'outil convient aux travaux dont le déroulement change sans cesse et ne peut pas être figé en script : veille concurrentielle, recopie de formulaires, transformation de pages en données structurées, avec un humain qui vérifie les résultats. Pour les flux fixes, un script Playwright écrit à la main ou un RPA classique coûte moins cher et dort mieux.
