Steel Browser : une API de navigateur pour agents, entre sandbox Docker et Chrome local

Ce que Steel Browser prend en charge à la place de votre code

Le README présente le projet comme une API de navigateur qui gère les sessions, les pages et les processus Chrome, pour que l'application se concentre sur l'agent. Le problème visé est concret : piloter Chrome en production implique de démarrer des processus, de les rattacher à une session, de conserver cookies et local storage entre deux requêtes, puis de nettoyer derrière soi. Steel expose ces opérations en HTTP plutôt que de les laisser à chaque application. Le public visé est celui qui construit des agents ou des outils d'automatisation et qui ne veut pas réécrire cette plomberie. Le README mentionne aussi des outils annexes : conversion d'une page en markdown, extraction en mode lisibilité, captures d'écran et PDF. Ces conversions sont utiles quand le résultat doit alimenter un modèle de langage, mais elles restent des appels séparés, pas un pipeline intégré.

Une API au-dessus de Chrome, pas un navigateur réimplémenté

Steel ne remplace pas Chrome. Le README indique que le contrôle passe par Puppeteer et le Chrome DevTools Protocol, ce qui permet de se connecter ensuite avec Puppeteer, Playwright ou Selenium. C'est un choix d'architecture qui a une conséquence directe : la compatibilité dépend de Chrome et de CDP, pas d'un moteur maison. Les sessions conservent état, cookies et local storage entre les requêtes, ce qui suppose un stockage côté serveur et une durée de vie à définir. Le projet ajoute une gestion de chaînes de proxy pour la rotation d'IP, le chargement d'extensions Chrome personnalisées, des plugins de stealth et de gestion d'empreinte, ainsi qu'un nettoyage automatique des navigateurs. Le port 9223 est décrit comme celui du console debugger, distinct du port 3000 qui sert l'API et l'interface. Cette séparation entre API et canal de débogage est un détail d'exploitation important : exposer 9223 publiquement donne un accès direct au navigateur.

Démarrage par image Docker ou par Node.js

La voie la plus courte tient en une commande, citée telle quelle dans le README : docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser. L'API répond alors sur http://localhost:3000 et l'interface sur http://localhost:3000/ui. La documentation Swagger est annoncée à l'adresse http://0.0.0.0:3000/documentation, ce qui permet d'inspecter les routes sans lire le code. Pour séparer API et interface, le dépôt fournit docker compose up, avec une précision pour les machines Mac Silicon : DOCKER_DEFAULT_PLATFORM=linux/arm64 docker compose up. Les contributeurs utilisent un autre fichier, docker-compose.dev.yml, qui construit les images depuis les répertoires api et ui et place l'interface sur le port 5173. Le README précise qu'il faut relancer avec --build à chaque modification. Enfin, npm install suivi de npm run dev démarre serveur et interface sans Docker, à condition que Chrome soit installé à un emplacement reconnu : /usr/bin/google-chrome sous Linux, /Applications/Google Chrome.app/Contents/MacOS/Google Chrome sous macOS, ou l'un des deux chemins Program Files sous Windows. Si Chrome est ailleurs, la variable CHROME_EXECUTABLE_PATH prend le relais : export CHROME_EXECUTABLE_PATH=/path/to/your/chrome, puis npm run dev. Le README renvoie à api/src/utils/browser.ts pour le détail de cette recherche.

Le point faible : une beta qui dépend de votre infrastructure

Le README écrit noir sur blanc que Steel est en beta publique et évolue chaque jour. Les releases publiées confirment le rythme : v0.5.4-beta, v0.5.3-beta, v0.5.2-beta, toutes suffixées -beta, avec des écarts de plusieurs mois entre certaines d'entre elles. Cela signifie que les routes et les formats de réponse peuvent bouger, et qu'un déploiement doit prévoir de suivre ces changements. La seconde limite est structurelle : Steel ne fournit pas le navigateur. Sans Chrome installé à un chemin reconnu, ou sans CHROME_EXECUTABLE_PATH correct, le serveur ne peut pas démarrer de session. Sur une image de conteneur minimale, c'est à vous d'ajouter Chrome. Troisième point, la gestion de sessions implique de la mémoire et des processus persistants : le README parle de nettoyage automatique, mais ne détaille pas de politique de durée de vie ni de quota. Si votre besoin se limite à charger une page et à lire son HTML, sans état à conserver, une simple bibliothèque d'automatisation dans votre processus suffit et évite d'exploiter un service HTTP supplémentaire.

Face à Playwright ou Puppeteer utilisés directement

La différence n'est pas la capacité de piloter un navigateur, puisque Steel s'appuie justement sur Puppeteer et CDP. Elle porte sur ce qui entoure le navigateur. Avec Playwright ou Puppeteer seuls, le cycle de vie des instances, la persistance des cookies entre appels, la rotation de proxy et le nettoyage sont à écrire dans l'application, et chaque service qui automatise le web doit les réimplémenter. Steel en fait un service partagé, joignable en HTTP, auquel plusieurs applications peuvent se connecter, y compris via Playwright ou Selenium d'après le README. Le coût de ce déplacement est réel : un processus de plus à superviser, un port d'API à sécuriser, et une dépendance à un projet encore en beta. À l'inverse, une bibliothèque embarquée ne nécessite aucun service tiers et se teste dans le même processus que l'application. Le choix se joue donc sur le nombre de consommateurs et sur la volonté de centraliser l'état des navigateurs.

Licence, maintenance et surface d'exploitation

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence. Elle comporte aussi une clause de brevets. Rien dans le matériel fourni n'indique de conditions supplémentaires liées à Steel Cloud, mais je ne peux pas confirmer ce point : le README présente le cloud comme la voie la plus simple pour démarrer, sans détailler la relation entre l'offre hébergée et cette instance auto-hébergée. Côté maintenance, le projet est actif, la dernière poussée sur main datant du 3 septembre 2026, et il existe un canal Discord ainsi qu'un dépôt de cookbook séparé. La surface à maintenir de votre côté reste néanmoins double : l'image Steel et le Chrome sous-jacent. Une montée de version de Chrome peut changer le comportement de CDP, et les plugins de stealth ou de gestion d'empreinte doivent suivre. Ce coût ne disparaît pas parce que le code est open source.

Conclusion éditoriale

Steel Browser convient aux équipes qui veulent une API HTTP de sessions Chrome sans écrire la couche de cycle de vie, et qui acceptent de gérer Chrome, Docker et les ports 3000 et 9223. Il ne convient pas si vous avez besoin d'une API stable : les releases publiées portent le suffixe -beta. Avant d'adopter, vérifiez la variable CHROME_EXECUTABLE_PATH sur votre machine et le fichier api/src/utils/browser.ts, qui indique où l'exécutable est recherché.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. steel-dev/steel-browser on GitHub