OpenChrome - Serveur MCP d’automatisation parallèle pour le navigateur Chrome
(github.com/shaun0927)Playwright est un outil d’automatisation web pratique pour piloter des actions comme les clics dans le navigateur quand on veut faire du crawling d’une manière ou d’une autre,
ou exécuter des tests E2E en environnement de production.
Lancé en 2020,
c’est encore l’outil utilisé par la majorité des développeurs.
Mais même avec une seule session ouverte, la consommation de RAM dépasse 2 Go, et l’outil est lourd, lent et se casse facilement.
À l’ère de l’IA, cet outil a besoin d’une vraie innovation,
et il faut en particulier un outil d’automatisation de navigateur capable de fonctionner de manière stable même en parallèle.
Nous ne voulons plus faire la QA nous-mêmes ni errer sur les sites.
OpenChrome est un projet né de la volonté de résoudre ce problème.
C’est un serveur MCP qui permet une automatisation parallèle du navigateur, rapide et intelligente.
C’est aussi l’outil que j’utilise le plus ces derniers temps dans mon travail personnel.
Il utilise la connexion du navigateur Chrome,
et si vous utilisez plusieurs comptes, il suffit d’indiquer pendant la tâche quel nom de compte employer.
Par défaut, il fonctionne à partir du navigateur Chrome déjà connecté.
Il permet le travail en parallèle sur plus de 20 navigateurs et réduit l’usage mémoire à environ 300 Mo. Il travaille avec une session Chrome connectée et neutralise pratiquement totalement la détection des bots. L’intégration avec Openclaw est également possible.
Voici un exemple d’utilisation.
"Récupère avec oc les derniers posts de 20 personnalités célèbres sur Twitter."
(référence Claude Code : benchmark de 3 min 30 s — la majeure partie du temps correspond à l’inférence du LLM)
En réalité, le problème chronique de Playwright, c’est l’« errance du LLM » qui part dans tous les sens.
Même si on lui demande une tâche comme se connecter, il passe longtemps à fouiller le site et à essayer tout et n’importe quoi,
pour finir par envoyer une notification d’échec après plus de 30 minutes.
Openchrome résout cela non pas par approximation, mais avec une approche guidée.
Il se connecte directement à Chrome et, si on lui donne un lien, y accède immédiatement.
Il prend le minimum de captures d’écran et repère rapidement l’emplacement des boutons, etc.
Si un problème survient pendant la tâche, il se remémore ce qui s’est passé et ne répète pas la même erreur.
Comme il s’agit d’un serveur MCP, il peut être utilisé immédiatement dans n’importe quel environnement à la place de Playwright.
Il fonctionne non seulement pour le développement MAC-claude code ou sur d’autres systèmes d’exploitation comme Windows et Linux,
mais aussi avec codex cli, cursor, etc.
Installation :
npx openchrome-mcp setup
La stabilité en production à grande échelle, très complexe et très gourmande en capacité, nécessite encore des vérifications supplémentaires.
Si vous avez des retours ou des suggestions, postez-les dans les GitHub Issues et je les prendrai en compte rapidement.
Merci.
13 commentaires
Sans utiliser une solution E2E existante, est-ce que cela signifie que l’IA va gérer et exécuter elle-même directement le code de test ?
Si Playwright accédait jusqu’ici aux sites web avec une méthodologie rigide, ce qui entraînait une forte consommation de tokens,
openchrome adopte une approche plus compatible avec les LLM, où le LLM peut intervenir rapidement et directement pour contrôler le comportement du site web. Il est possible d’exécuter directement des solutions e2e.
Par exemple, dans un environnement de production nécessitant une connexion Google, on peut lui faire effectuer des tâches de QA alors qu’il est connecté avec un compte administrateur. Faire défiler la page, cliquer automatiquement sur des cas limites, etc. : la plupart des tâches que vous imaginez sont possibles. En effet, au lieu de laisser Playwright exécuter de manière autonome des actions inefficaces, le LLM intervient immédiatement pour piloter le comportement.
Si l’on ne regarde que la consommation de tokens, une méthode standardisée ne consomme-t-elle pas moins, puisqu’elle consiste à exécuter les cas de test E2E sans intervention du LLM ?
Dans les méthodologies de test, en plus des TC, il y a aussi les tests que la QA effectue de manière autonome.
Si l’on juge que cette partie est efficace, peut-on considérer que c’est une bonne approche ?
Pour répondre de façon plus technique à votre question,
le MCP Playwright existant fonctionne avec les 3 niveaux d’abstraction suivants :
LLM → serveur MCP → serveur Playwright Node.js → CDP/Juggler → navigateur
À l’inverse, OpenChrome fonctionne avec le niveau d’abstraction unique suivant :
LLM → serveur MCP → CDP → navigateur
Moins il y a de couches d’abstraction, plus c’est rapide et plus le contrôle est précis ;
Playwright est un outil généraliste, tandis qu’OpenChrome utilise des outils spécialisés.
Pour prendre une analogie mathématique, c’est un peu comme compresser une solution de 20 lignes en 4 lignes.
Playwright reçoit aussi les retours via une approche textuelle fondée sur l’arbre d’accessibilité
(en théorie c’est excellent, mais c’est aussi la raison pour laquelle cela casse sur la plupart des sites),
ce qui limite fortement la compréhension du contexte.
Par conséquent, sur les sites où l’accessibilité est bien implémentée (Google et d’autres domaines connus, par exemple), Playwright reste utile,
mais sur la plupart des sites ou en production, OpenChrome est largement supérieur.
De plus, comme la « densité de conception des outils » et la « réduction des occasions pour le LLM de se tromper » déterminent en fin de compte les performances réelles en situation,
je pense qu’il est pertinent de mesurer cela sur des tâches réelles plutôt que sur des performances théoriques.
Merci. Je n’avais pas lu l’article principal assez attentivement.
J’ai négligé le fait qu’il visait un environnement de production.
Je vais moi aussi l’essayer sans faute.
Merci d’avoir répondu avec autant de sérieux à une question erronée~
Non, merci pour cette bonne question. Cela m’a aussi permis de clarifier les choses en l’expliquant.
C'est clairement rapide et bien.
Mais dès qu'une alerte s'affiche, ça se bloque.
Je vais m’efforcer d’améliorer cela rapidement.
Je suis aussi curieux de voir la comparaison avec Chrome DevTools MCP !
Pour l’avoir essayé, je me souviens avoir trouvé Playwright plutôt préférable à chrome devtools mcp, mais j’ajouterai un benchmark plus tard.
Avec chrome devtools mcp, l’avertissement de grand contexte ne s’affiche pas, et j’avais l’impression que les performances étaient assez similaires, donc c’est ce que j’utilisais ! J’ai hâte de voir les résultats du benchmark :D
Oh, la consommation de tokens diminue aussi ? Merci !!
On peut considérer que, dans la mesure où il multiplie moins les faux pas, la consommation de tokens diminue aussi.