- MCP-B : protocole d’automatisation IA natif au navigateur
- Au lieu de la méthode classique par capture d’écran et clics, il permet à l’IA d’automatiser 1 000 fois plus vite et plus précisément en accédant directement aux API d’un site web, grâce à un protocole de contexte pour navigateur
- En ajoutant environ 50 lignes de code, il devient possible d’intégrer immédiatement l’IA avec les informations d’authentification du site, sans OAuth séparé, clé API ni configuration complexe
- En s’appuyant sur la session du navigateur et le système d’authentification existant, il fonctionne immédiatement sans nouvelle authentification ni réglage de permissions, tout en respectant les politiques de sécurité API propres à chaque application web
- Via une extension, un assistant IA peut naviguer entre plusieurs onglets et applications, consulter directement des données et exécuter des tâches ; par rapport à l’automatisation classique, les performances (exécution en quelques ms) et la fiabilité sont nettement supérieures
- Grâce à un accès structuré aux API, il s’affranchit des problèmes liés aux changements d’interface, aux erreurs de capture d’écran et à la gestion complexe des sélecteurs. L’installation comme l’utilisation sont très simples
Présentation de MCP-B
- MCP-B (Machine Context Protocol for Browsers) est un protocole de contexte de modèle pour les navigateurs, qui fournit un standard pour contrôler et faire interagir l’environnement du navigateur d’une manière comparable à l’automatisation de terminal basée sur l’IA
- Ce protocole définit clairement la communication entre le navigateur et le moteur d’IA, afin de structurer différents types d’automatisation et d’interactions avec les modèles
Ce qui le différencie des approches existantes
- Automatisation traditionnelle du navigateur : analyse de captures d’écran, clic sur des éléments, vulnérable aux changements d’UI, lente et instable (10 à 20 secondes par tâche, coût de 4 à 5 $)
- Approche MCP existante : nécessite une clé API et une authentification complexe, avec une forte barrière à l’entrée lors du setup initial
- MCP-B : exploite la session du navigateur, accès direct aux API, fonctionnement immédiat sans authentification ni configuration complexes
Principes clés et architecture
- Serveur MCP par onglet : chaque web app exécute son propre serveur MCP en TypeScript (transport en mémoire, réutilisation des cookies/JWT existants pour l’authentification)
- Extension MCP-B : extension Chrome/Edge/Firefox (le script de contenu communique avec le serveur d’onglet via
postMessage), qui centralise en un seul endroit les outils et API de tous les onglets - Intégration avec un assistant IA : automatisation du navigateur via MCP-B depuis le Native Bridge et différents clients (Claude Desktop, Cursor IDE, etc.)
Utilisation et déploiement
- Développeurs : 1) installer le package 2) ajouter le code du serveur MCP 3) déployer → aucune clé API, aucun OAuth, aucune configuration complexe supplémentaire nécessaires
- Utilisateurs : installation de l’extension puis utilisation immédiate ; l’automatisation est disponible dès la configuration de l’IA
Avantages concrets
- Authentification : réutilise telles quelles les informations de connexion et de session du site web, sans OAuth 2.1 ni authentification séparée
- Performances : appels API directs permettant d’achever les tâches en millisecondes (amélioration de 10 000 fois par rapport à l’existant)
- Sécurité : fonctionne à l’intérieur de l’application, en respectant les contrôles d’accès et politiques d’autorisation déjà en place
- Extensibilité : plusieurs web apps, onglets et outils IA peuvent être gérés de manière unifiée via MCP-B
- Configuration : l’automatisation est prête avec environ 50 lignes de code
Résumé comparatif
| Méthode | Authentification et configuration | Mode de fonctionnement | Performances et fiabilité |
|---|---|---|---|
| Automatisation classique | Authentification complexe, clé API | Screen scraping, clics | Lente et instable (10 à 20 s) |
| MCP existant | Clé API, OAuth requis | Accès API | Barrière à l’entrée élevée |
| MCP-B | Aucune configuration, utilisation de la session du navigateur | Appels API directs | En millisecondes, très rapide et stable |
Conclusion : l’automatisation IA de nouvelle génération dans le navigateur
- MCP-B est un protocole d’automatisation IA optimisé pour l’environnement du navigateur, innovant en matière d’authentification, de sécurité, d’extensibilité et de performances
- Sans authentification supplémentaire ni configuration complexe, il permet de mettre en œuvre une automatisation IA à grande échelle grâce à de simples appels directs aux API depuis le navigateur
- Licence MIT, centré sur la communauté, compatible avec tous les principaux navigateurs
2 commentaires
On peut considérer que la vision centrale de la technologie MCP-B est la suivante.
« Par l’intermédiaire fiable qu’est une extension Chrome, exploiter les informations utilisateur que le navigateur gère déjà de façon sécurisée (cookies, session, authentification, etc.) afin d’appeler et de piloter, depuis une fenêtre de chat IA, des “outils (Tools)” prédéfinis par les développeurs sur une page web au moyen de commandes en langage naturel. »
Mais, pour ma part, j’ai le sentiment que « les possibilités d’extension semblent limitées », et j’estime que les raisons sont les suivantes.
En conclusion,
l’idée même de MCP-B est techniquement très intéressante et innovante, mais elle ne semble pas pouvoir apporter une réponse claire à la question fondamentale, pour les utilisateurs comme pour les développeurs, de « pourquoi faudrait-il absolument utiliser cette approche ? ». Par rapport à l’approche API existante, les avantages obtenus restent flous, tandis que les inconvénients — préoccupations de sécurité et complexité de développement — sont, eux, bien réels.
Par conséquent, à ce stade, cette technologie pourra certes être utilisée à titre expérimental par quelques passionnés ou par des développeurs ayant des objectifs spécifiques, mais elle semble rencontrer de nombreuses difficultés pour s’étendre à l’ensemble de l’écosystème web.
Avis sur Hacker News
Prévision : cela suivra probablement la même trajectoire que le RSS. Les entreprises ont tendance à ne pas aimer que les utilisateurs contrôlent eux-mêmes la manière dont leurs données sont exploitées
Même chose pour les API REST : à une époque, on pensait qu’avec la vague du design « API-first », elles deviendraient l’avenir de l’automatisation et de l’intégration des services. Mais les entreprises ont vite compris qu’offrir ce type de capacité menaçait leur modèle de revenus, et elles ont rapidement changé de cap. Elles ont fini par redécouvrir que tout leur gagne-pain repose sur le fait d’empêcher les utilisateurs d’avoir ce genre de pouvoir
Je ne pense pas que le RSS ait échoué, au contraire, je pense qu’il a eu un immense succès. Après la disparition de Google Reader, on a pu migrer vers d’autres lecteurs, et les flux RSS continuent de fonctionner sans problème depuis plus de 20 ans. Je rencontre très rarement des sites qui ne prennent pas en charge le RSS
La plupart des sites web prennent toujours en charge le RSS, et certains ont des flux existants par défaut même s’ils ne les affichent pas sur la page. Même si certains ne publient pas le texte intégral, cela reste très utile comme notification de mise à jour ou comme déclencheur d’automatisation. Le RSS est encore très vivant et utile, un peu comme un micro-ondes : c’est juste là, naturellement
La structure du marché a changé : les grandes entreprises se concentrent désormais sur la « couche d’intelligence » plus que sur le contenu lui-même. Le contenu devient de plus en plus une commodité. Google doit capter les yeux et l’attention des utilisateurs, ainsi que la technologie intelligente qui les retient, afin de continuer à vendre de la publicité. Si Google ne voulait pas du RSS, c’est parce qu’il pouvait contourner Google Search
Dès que l’IA saura cliquer et faire défiler les pages comme un humain, on assistera à une nouvelle compétition sans fin
L’historique des contributions du projet Github est très intéressant (citation directe du lien). MiguelsPizza a fait 3 commits, Claude en a fait 2, mais le volume de modifications de code attribué à Claude est presque écrasant
L’extension a été rendue privée temporairement et l’historique git a été ajusté, donc il y a un léger écart avec l’historique réel. Cela dit, il est vrai que Claude a écrit environ 85 % de l’ensemble du code
On verra probablement ce genre de schéma (des contributions massives au code par l’IA) de plus en plus souvent à l’avenir
Le graphe des commits de Claude est très particulier. On dirait que Claude Code commit directement, mais en réalité c’est presque jamais le cas. Voir aussi le profil claude
Quand on regarde la liste réelle des commits, ils sont tous au nom de MiguelsPizza / Alex Nahas (lien). Ça semble bizarre
En citant un extrait du blog, discussion sur le problème d’authentification de MCP. OAuth2.1 semble acceptable à long terme, mais il faut réinventer l’authentification pour l’adapter à des agents qui agissent au nom des utilisateurs. Le risque de fuite de données dans les applications multi-tenant n’est toujours pas résolu
Limiter le périmètre des dommages potentiels du modèle et les données auxquelles il a accès pourrait être un gros avantage de MCP. On peut s’attendre à ce que les API côté client d’une application multi-tenant soient déjà limitées au périmètre utilisateur ; si l’on ne fournit que cela au modèle, l’impact ne devrait pas être trop grave. La question de la compatibilité entre le système d’authentification interne d’Amazon et OAuth2.1 est aussi mentionnée (chez Amazon, l’authentification fonctionne différemment)
Quelqu’un se demande si une partie des fonctionnalités d’OAuth2.1 est déjà couverte par la délégation et l’usurpation de la RFC 8693
Le périmètre auquel le modèle peut accéder est de toute façon identique à celui de l’utilisateur, donc la mise en œuvre correcte de la sécurité reste la responsabilité de l’administrateur du site web
Je ne pense pas que l’exemple d’Amazon, où OAuth n’est pas correctement appliqué, soit le cœur du problème. Un accès de type porte dérobée au-delà du périmètre des autorisations utilisateur est extrêmement dangereux. Si toutes les actions d’une application MCP sont journalisées dans la même catégorie que les accès utilisateur, cela pourrait créer beaucoup de problèmes de conformité. C’est très intéressant sous cet angle, mais du point de vue sécurité, cela ressemble beaucoup à un contournement potentiellement problématique
Quelqu’un avance l’idée qu’en publiant une spécification Swagger(OpenAPI) et en ayant simplement un client MCP Swagger générique, on pourrait presque remplacer toutes ces implémentations. Il suffirait peut-être que l’utilisateur ouvre lui-même une session d’authentification manuellement. La suggestion est que Claude identifie correctement les clés API depuis le prompt/la configuration et utilise un client API basé sur Swagger, ce qui reviendrait au même
C’est la première idée à laquelle tout le monde a pensé quand MCP est apparu. Mais en pratique, on a constaté que cela fonctionne mal à cause du trop grand nombre d’outils. Cela dit, il continue d’y avoir des tentatives intéressantes dans ce domaine
Il y a aussi un rappel de prudence : ne mettez pas vos clés API dans le prompt
Claude Code devient vraiment pratique pour tester des API si on lui donne simplement le lien vers
swagger.jsondansCLAUDE.mdQuelqu’un encourage à essayer soi-même
On ne voit pas très bien qui est l’utilisateur cible. Pour les tests frontend, le fait que les tests cassent quand l’UI change fortement est plutôt utile. Pour les autres besoins d’automatisation, il semble préférable d’exposer une vraie API
À la métaphore disant que « ce serait encore plus difficile de fabriquer une table chez Home Depot », quelqu’un objecte qu’il y a justement plein de bois chez Home Depot
Home Depot vend aussi des tables déjà finies
Home Depot dispose même de meilleurs outils de précision ainsi que de professionnels, donc cela pourrait au contraire rendre le travail plus facile
Quelqu’un plaisante avec la nuance : « le bois, c’est à toi de l’imaginer et de le créer »
Il précise avoir modifié la formule pour tenir compte de cette remarque
Quelqu’un n’a pas encore utilisé MCP directement, mais du point de vue d’une personne en situation de handicap, il voit un fort potentiel pour l’accessibilité dans l’automatisation des navigateurs et des smartphones. En revanche, comme cette technologie pourrait être détournée par des utilisateurs malveillants, il doute qu’elle soit réellement adoptée par les grands sites/apps. Il se demande s’il existe déjà des cas d’usage réels pour améliorer l’accessibilité
Quelqu’un se dit reconnaissant que MCP-B soit open source. Beaucoup de choses se passent déjà dans le navigateur, mais avec MCP, il y a une hypothèse légèrement différente : c’est le client IA qui exécute la tâche. Fondamentalement, il se demande en quoi MCP-B diffère du fait de relier directement l’API JS d’une web app à un serveur LLM pour l’utiliser. Est-ce finalement la même chose, ou y a-t-il une vision plus large derrière ?
Rien qu’en lisant la page d’accueil, ce n’est pas très clair, et quelqu’un pose la question en disant qu’il a l’impression que c’est une sorte de version navigateur de Selenium
Quelqu’un prédit que si l’automatisation de navigateur via MCP commence à viser les utilisateurs de LLM gratuits, même les modèles gratuits finiront par se heurter à des Captcha. Le problème, c’est que les Captcha ne sont pas si efficaces contre les LLM, et on pourrait donc entrer dans une étrange ère de guerre des robots où des LLM se battront entre eux pour empêcher l’accès d’autres LLM d’automatisation