Browserbase

Browserbase est une plateforme d'infrastructure cloud de navigateurs headless conçue spécifiquement pour les agents IA. Fondée en 2023 par Paul Klein IV, ancien ingénieur chez Twilio et CTO de StreamClub, l'entreprise exécute des instances Chromium en bac à sable (sandbox) dans le cloud, auxquelles les agents propulsés par des LLM accèdent via des connexions standard Playwright, Puppeteer ou Selenium. Le problème central qu'elle résout est ce que Paul Klein appelle « les 85 % inaccessibles par les API » : les pages web, les portails et les applications authentifiées qui ne disposent d'aucun point d'accès API lisible par une machine et qui ont été conçus uniquement pour des navigateurs humains. Browserbase les rend accessibles aux agents à l'échelle de la production.

La plateforme se déploie en trois couches. La couche d'infrastructure fournit des sessions de navigateur cloud facturées à l'heure de navigation, avec résolution intégrée des CAPTCHA, empreinte numérique furtive (stealth fingerprinting), gestion des proxys et relecture des sessions avec lecture vidéo. Stagehand est la couche SDK open source (licence MIT, TypeScript et Python, plus de 22 400 étoiles GitHub) qui enveloppe le contrôle du navigateur avec quatre primitives IA : act() pour l'exécution d'actions en langage naturel, extract() pour l'extraction de données structurées, observe() pour prévisualiser l'effet d'une action, et agent() pour la délégation autonome de tâches en plusieurs étapes. Director est la couche d'interface utilisateur en langage naturel, lancée en juin 2025, qui permet aux utilisateurs non techniques de décrire des automatisations en anglais courant et de générer des scripts exécutables sans écrire de code. En mars 2026, Browserbase traite environ 37 millions de sessions de navigateur uniques par mois pour plus de 10 000 entreprises, tandis que Stagehand enregistre 800 000 téléchargements hebdomadaires de son SDK.

Ce que fait réellement Browserbase en avril 2026

L'infrastructure de Browserbase offre aux agents une instance complète du navigateur Chromium accessible via WebSocket en utilisant le Chrome DevTools Protocol. Vous connectez votre code Playwright ou Puppeteer existant en modifiant un seul point d'accès (endpoint) ; la session s'exécute dans le cloud de Browserbase au lieu de votre serveur. À partir de là, l'agent peut naviguer, cliquer, remplir des formulaires, gérer des pages chargées en JavaScript, résoudre automatiquement les CAPTCHA et conserver les cookies d'une requête à l'autre. Les sessions incluent une vue en direct intégrée (pour observer le navigateur en temps réel), une relecture vidéo post-session, des instantanés du DOM et des journaux de prompts pour déboguer les exécutions échouées.

Stagehand v3, lancé le 29 octobre 2025, marque une étape architecturale majeure. Les versions antérieures de Stagehand étaient construites sur Playwright ; la v3 est passée au CDP natif, la rendant compatible avec Puppeteer, Bun et d'autres pilotes basés sur le CDP. Le framework s'exécute désormais 44 % plus vite en moyenne que la v2, avec des gains particuliers dans les iframes imbriquées et les interactions avec le shadow DOM, qui étaient les principaux modes d'échec des scripts d'agents précédents sur les applications web modernes. Stagehand v3 a également ajouté la mise en cache automatique des éléments : une fois qu'une exécution act() ou extract() découvre des éléments de page, les exécutions suivantes les réutilisent sans inférence LLM supplémentaire, réduisant ainsi la latence et les coûts d'API pour les flux de travail répétés.

La couche d'observabilité de la plateforme mérite une mention spéciale car il s'agit d'un véritable élément différenciateur. La relecture de session inclut la vidéo complète, l'inspection du DOM à n'importe quelle image, et un journal des prompts LLM déclenchés ainsi que de leurs réponses. Lorsqu'un agent échoue à l'étape 7 d'un flux de travail de 12 étapes, vous pouvez avancer jusqu'à ce moment précis et voir exactement ce que le navigateur affichait et ce que le modèle a déduit. Les concurrents manquent totalement de relecture post-session ou la réservent à leurs forfaits d'entreprise.

« Cela a rendu incroyablement facile l'exécution de véritables sessions de navigateur pour nos agents IA. Sans cela, l'ensemble du système serait 10 fois plus difficile à construire et à faire évoluer. » Elijah Muraoka, fondateur de Soshi, Product Hunt, juin 2025

« L'API a été facile à intégrer et fournit un ensemble de fonctionnalités essentiel pour de nombreux cas d'usage professionnels. » Zach Tratar, fondateur d'Embra, Product Hunt, mai 2025

Où se situe Browserbase par rapport à Apify et Anchor Browser

L'espace des navigateurs headless et de l'automatisation par agents compte au moins trois architectures distinctes, et Browserbase, Apify et Anchor Browser en représentent chacun une différente.

Browserbase vs. Apify : Apify est une place de marché d'automatisation construite autour des « Actors », des fonctions Node.js ou Python serverless que vous écrivez une fois et déployez sur leur cloud. La principale différence structurelle est que le modèle d'Apify repose sur l'exécution de tâches pré-codées issues d'une bibliothèque (plus de 4 000 Actors prêts à l'emploi pour des sites spécifiques comme LinkedIn, Amazon et Google Maps), tandis que Browserbase fournit des sessions de navigateur brutes et non codées sur lesquelles s'exécute la logique de votre agent. Si vous devez scraper un site qui possède déjà un Actor Apify, Apify est plus rapide pour démarrer. Si vous construisez un agent qui rencontre des pages nouvelles et imprévisibles, un outil de vente de logiciels naviguant sur des portails de fournisseurs, un agent de recherche interrogeant des bases de données gouvernementales obscures, le modèle d'Actor d'Apify ne vous couvrira pas. Vous appelleriez Apify depuis un orchestrateur comme un outil connu ; Browserbase est la surface sur laquelle vit toute la boucle de navigation de votre agent. Le modèle de coûts diffère également : Apify facture par unité de calcul d'Actor et par bande passante de proxy, sans couche de débogage par relecture de session conçue pour les cas d'usage des agents.

Browserbase vs. Anchor Browser : Anchor est philosophiquement plus proche de Browserbase : tous deux fournissent des sessions de navigateur cloud accessibles via CDP. L'élément différenciateur d'Anchor est son abstraction de points d'accès « outils agentiques » ; au lieu d'un accès CDP brut, vous appelez des points d'accès de plus haut niveau comme « perform web task » ou « navigate to ». Anchor privilégie l'exécution déterministe via des scripts explicites. Dans un benchmark de 2025 comparant la vitesse de création de session, Anchor affichait une moyenne de 13,1 secondes contre 11,9 secondes pour Browserbase, bien qu'Anchor ait géré 3/3 sessions parallèles sur le niveau gratuit là où Browserbase les exécutait séquentiellement. Là où Anchor est clairement à la traîne, c'est sur l'écosystème : il n'y a pas d'équivalent Anchor à Stagehand, le SDK open source aux plus de 22 000 étoiles sur lequel des centaines d'équipes de développeurs se sont standardisées. Les outils d'observabilité de Browserbase (relecture vidéo post-session, instantanés du DOM) sont également plus complets ; Anchor propose une vue en direct pendant l'exécution, mais pas de relecture post-session. Pour les équipes qui souhaitent un accès brut au navigateur ainsi qu'un framework structuré et bien pris en charge autour de celui-ci, Browserbase est la réponse complète. Pour les équipes qui souhaitent des API de tâches de haut niveau déterministes sans écrire leur propre logique d'agent, Anchor mérite d'être évalué.

À quoi ressemble la réalité de la boucle d'agent Stagehand

Un flux de travail Stagehand se situe entre deux modes d'échec : le Playwright pur (rapide et peu coûteux, mais qui se casse à chaque changement de nom de classe) et les boucles d'agents LLM pures (flexibles mais coûteuses, lentes et non déterministes). La conception de Stagehand vous oblige à choisir, étape par étape, le niveau d'implication de l'IA que vous souhaitez.

Pour un agent SDR typique, un développeur écrirait un code déterministe pour les parties stables (naviguer vers une URL connue, se connecter avec des identifiants stockés) et utiliserait act() pour les parties qui changent (cliquer sur le bouton du formulaire de contact, qui pourrait être étiqueté différemment selon les sites). extract() extrait des données structurées de la page sans vous obliger à écrire des sélecteurs CSS qui se cassent lors des refontes. observe() vous permet de prévisualiser ce que Stagehand ferait avant de vous engager, ce qui est utile pour créer une couverture de test ou consigner une intention. La primitive agent() confie entièrement les objectifs à plusieurs étapes à un LLM sous-jacent, ce qui est utile pour les tâches exploratoires où le chemin est inconnu.

La tension pratique que rencontrent les développeurs est le coût. Chaque invocation de act() ou extract() déclenche un appel LLM, à moins que l'élément n'ait été mis en cache lors d'une exécution précédente. Au début du développement, avant que le cache ne soit rempli, les coûts s'accumulent. Les développeurs sur Hacker News ont noté que Playwright seul pourrait être moins cher pour les flux de travail avec des structures de page stables et bien connues. La mise en cache automatique des éléments de Stagehand v3 résout directement ce problème pour les flux de travail répétés, mais les nouvelles pages entraînent toujours des coûts d'inférence LLM à chaque fois.

Le débogage est le domaine où la plateforme de Browserbase justifie son prix par rapport à un Playwright local. Lorsqu'un agent échoue face à un état de page inattendu, une publicité interstitielle, une erreur de blocage régional, une variante de test A/B que l'agent n'a pas vue, la relecture de session vous permet d'avancer jusqu'à l'image exacte et de comprendre l'état du DOM sur lequel le modèle raisonnait. Sans cela, déboguer les exécutions d'agents échouées revient à reconstituer un plantage à partir d'une trace d'appels (stack trace). Avec cela, vous avez la vidéo.

À qui s'adresse Browserbase

Browserbase est le choix par défaut pour les équipes qui construisent des agents IA de production devant interagir avec le web en direct à grande échelle. Cela couvre un large éventail de catégories de produits : les représentants de développement des ventes IA (11x est un client cité), les agents de recherche qui agrègent des données à partir de sites sans API, les remplaçants de RPA qui gèrent les portails gouvernementaux et les formulaires obsolètes, les outils de veille concurrentielle qui surveillent les prix et les offres d'emploi, et les outils de développement qui exécutent des tests d'acceptation basés sur le navigateur sur des interfaces utilisateur changeantes.

Le SDK Stagehand convient particulièrement aux développeurs TypeScript et Python qui sont déjà à l'aise avec Playwright et souhaitent y superposer des primitives IA plutôt que de changer complètement de framework. La courbe d'apprentissage est douce : les scripts Playwright existants continuent de fonctionner ; vous ajoutez des appels act() là où se trouvaient des sélecteurs fragiles.

Les équipes d'entreprise tirent une valeur ajoutée de la couche d'observabilité. Pouvoir rejouer exactement ce qu'un agent a vu et décidé à chaque étape est important pour la conformité dans les secteurs réglementés, le débogage des défaillances signalées par les clients et l'amélioration des prompts des agents au fil du temps. Les entreprises soumises aux exigences HIPAA peuvent obtenir une couverture BAA avec le forfait Scale.

La plateforme est également très adaptée aux startups qui souhaitent faire l'impasse sur la construction de l'infrastructure. L'exécution de navigateurs headless fiables à grande échelle implique la rotation des proxys, les services CAPTCHA, l'empreinte numérique du navigateur, la gestion de l'état des sessions et la surveillance. Browserbase abstrait tout cela en une seule API et une facture mensuelle.

Ce que Browserbase n'est pas

Browserbase n'est pas le bon choix lorsque vous avez besoin de nombreuses sessions de navigateur très courtes. Le minimum de facturation d'une minute signifie qu'une vérification de formulaire de 10 secondes est facturée comme une minute entière. Si votre flux de travail implique des centaines d'interactions rapides et déterministes, des vérifications de prix, des pings d'état, des vérifications de webhooks, le modèle de coûts joue contre vous. Une configuration Playwright auto-hébergée ou une API de scraping plus légère sera moins chère.

Ce n'est pas non plus un substitut à l'infrastructure de scraping web traditionnelle lorsque les sites cibles ont une structure connue et stable et que des Actors pré-construits existent déjà sur la place de marché d'Apify. Si vous avez besoin de données de produits Amazon, de profils LinkedIn à partir d'un export structuré ou de résultats SERP Google à grande échelle, les outils de scraping spécialisés proposent une tarification plus efficace pour ces cibles connues.

Les équipes à la recherche de scripts entièrement déterministes sans implication de LLM à l'exécution devraient chercher ailleurs, ou utiliser l'infrastructure de Browserbase avec du code Playwright pur et ignorer complètement Stagehand. La plateforme fonctionne sans Stagehand ; l'accès au navigateur en est la fondation. Mais l'architecture LLM à l'exécution de Stagehand est un véritable compromis : elle ajoute des coûts et du non-déterminisme à chaque étape où vous invoquez l'IA. Pour les équipes qui trouvent cela acceptable, la résilience de Stagehand aux changements d'interface utilisateur en vaut la peine. Pour les équipes qui construisent des flux de travail étroitement contrôlés et à haute fréquence où chaque centime par exécution compte, le calcul est différent.

Enfin, les flux d'authentification restent un véritable problème de fiabilité. Les tests sur des flux de travail fortement axés sur la connexion impliquant des codes OTP et une vérification par e-mail ont montré des taux d'échec d'environ 60 %. La résolution de CAPTCHA de Browserbase gère bien les CAPTCHA visuels ; les flux OTP basés sur des e-mails et sensibles au temps nécessitent une orchestration supplémentaire que la plateforme ne fournit pas nativement pour le moment.