Le Model Context Protocol, ou MCP, fournit une interface standardisée entre une application d’intelligence artificielle et des outils externes. Un client compatible peut découvrir les fonctions exposées par un serveur, appeler une fonction autorisée et recevoir un résultat structuré sans qu’un utilisateur doive écrire un script différent pour chaque demande.

Pour les workflows qui nécessitent un véritable navigateur, BitBrowser ajoute une couche utile : des profils isolés possédant leurs propres cookies, stockage local, paramètres de proxy, extensions et empreintes. Depuis BitBrowser 7.1.5, le client inclut un service MCP relié à l’environnement Local API, ce qui permet de piloter des opérations de gestion de profils depuis un client MCP compatible. Notes de version BitBrowser 7.1.5

Des outils comme Cursor, Claude et d’autres clients MCP peuvent ainsi travailler avec BitBrowser au moyen d’instructions en langage naturel. MCP ne remplace pas Selenium, Playwright ou une API déterministe ; il ajoute une interface adaptée aux agents d’IA pour les tâches où l’utilisateur souhaite décrire l’objectif plutôt que coder chaque appel. Guide officiel BitBrowser MCP

Ce guide montre comment préparer la Local API, activer l’authentification, connecter un client MCP, commencer par une vérification en lecture seule, créer un profil de test, associer un proxy autorisé, conserver un environnement cohérent et déployer progressivement l’automatisation dans une équipe.

Qu’est-ce qu’un serveur MCP ?

MCP est un protocole ouvert conçu pour standardiser la manière dont une application d’IA découvre et utilise des outils. Le serveur MCP décrit les opérations disponibles, leurs paramètres et les résultats attendus. Le client choisit ensuite l’outil approprié en fonction de la demande et des autorisations accordées.

Dans un environnement BitBrowser, la chaîne peut être résumée ainsi : client IA → MCP → serveur MCP local BitBrowser → Local API → profil de navigateur → site ou application autorisée. La partie locale est importante car elle permet de garder l’accès au navigateur sur la machine contrôlée par l’utilisateur.

Le bénéfice principal est la séparation des contextes. Un agent peut consulter ou lancer plusieurs profils sans mélanger les cookies, les sessions ou les paramètres réseau. Pour une agence, une équipe QA ou un service marketing, cette séparation facilite l’organisation, l’audit et la reproductibilité des tests.

Le rôle de BitBrowser dans un workflow MCP

BitBrowser n’est pas seulement un endpoint MCP. Sa valeur vient de la combinaison entre l’accès piloté par un agent et une infrastructure de profils de navigateur isolés. Chaque profil peut conserver un proxy, une empreinte, des cookies, des extensions et des données de session indépendants.

Cette architecture permet de séparer les projets de manière lisible. Une équipe peut par exemple réserver un profil à la QA en France, un autre à un test de localisation en Allemagne et un troisième à une recherche de marché aux États-Unis, sans réutiliser le même contexte de navigation.

MCP se place au-dessus de cette couche. Selon les outils exposés et les permissions, un agent peut lister des profils, vérifier une configuration, créer un environnement de test, lancer une fenêtre ou effectuer une modification ciblée. Le principe de moindre privilège reste essentiel.

La Local API continue d’avoir un rôle important. Les scripts internes peuvent appeler directement l’API lorsque le processus doit être totalement déterministe, tandis que MCP convient aux workflows pilotés par l’intention et aux interactions assistées par IA. Les deux approches peuvent coexister.

Architecture MCP avec BitBrowser

Prérequis

Avant de commencer, préparez un environnement de test et vérifiez les éléments suivants :

• BitBrowser 7.1.5 ou une version plus récente

   

• Accès à Settings → Browser Settings → Local API

• Authentication Control activé pour la Local API

   

• Un client IA acceptant des serveurs MCP personnalisés

   

• Un profil ou projet de test sans données sensibles

• Un proxy que vous êtes autorisé à utiliser si votre scénario nécessite un routage régional

• Un plan de permissions clair pour les membres de l’équipe et l’agent IA

Configuration étape par étape

1. Installez ou mettez à jour BitBrowser

Installez une version actuelle de BitBrowser. Si le logiciel est déjà présent, contrôlez le numéro de version et redémarrez l’application après la mise à jour. Pour un déploiement en équipe, validez d’abord la nouvelle version sur un poste de test avant de modifier un environnement de production. Télécharger BitBrowser

2. Ouvrez les réglages Local API

Dans BitBrowser, ouvrez Settings → Browser Settings → Local API. Cette section regroupe les paramètres qui permettent à une application locale de communiquer avec l’environnement de gestion des profils. Notez le port utilisé et évitez de modifier plusieurs paramètres en même temps pendant le diagnostic.

3. Activez Authentication Control

Activez Authentication Control. BitBrowser génère alors un jeton utilisé dans l’en-tête x-api-key. Traitez ce jeton comme un secret : ne le publiez pas, ne l’insérez pas dans un dépôt public et ne le transmettez qu’aux personnes ou services qui en ont réellement besoin.

4. Vérifiez l’endpoint MCP

Vérifiez les adresses affichées dans votre installation. La configuration standard utilise généralement 127.0.0.1:54345 pour la Local API et /mcp pour le service MCP. Si vous avez changé le port, utilisez toujours la valeur affichée localement plutôt qu’un exemple copié depuis un tutoriel.

Local API: http://127.0.0.1:54345
MCP:       http://127.0.0.1:54345/mcp

5. Copiez la configuration MCP générée

Utilisez de préférence la configuration MCP générée par BitBrowser. Elle réduit le risque d’erreur sur l’URL, le port, le format et l’en-tête d’authentification. Si le jeton est régénéré plus tard, pensez à mettre également à jour la configuration enregistrée dans le client IA. Guide officiel BitBrowser MCP

6. Connectez BitBrowser à Cursor

Dans Cursor, ouvrez les réglages MCP ou Tools & Integrations, ajoutez un nouveau serveur, collez la configuration BitBrowser et activez-la. Si le serveur n’apparaît pas immédiatement, rechargez le client. Testez d’abord la découverte des outils avant d’autoriser une action qui modifie un profil.

7. Connectez Claude ou un autre client

Dans Claude ou un autre client acceptant un serveur MCP personnalisé, ajoutez la configuration correspondant à BitBrowser, conservez le jeton d’authentification et vérifiez l’endpoint local. Les écrans peuvent changer selon la version du client ; la configuration générée par BitBrowser reste la référence la plus sûre.

8. Commencez par une opération en lecture seule

Le premier test devrait être en lecture seule. Demandez au client de confirmer la connexion et de lister les profils accessibles sans lancer, créer, modifier ou supprimer quoi que ce soit. Cette méthode permet de distinguer un problème de connexion d’un problème de permission ou d’action spécifique.

List the BitBrowser profiles available to this connection.
Do not create, modify, launch or delete anything.

9. Créez un profil de test

Lorsque la lecture fonctionne, créez un seul profil de test, par exemple MCP_Test_01. Ne lui ajoutez pas encore de cookies de production. Demandez au client de retourner l’identifiant du profil et arrêtez le workflow à ce stade afin de vérifier manuellement que l’objet créé correspond à la demande.

Create a BitBrowser profile named MCP_Test_01.
Return the profile ID and stop.

10. Configurez un proxy autorisé

Si le projet nécessite un emplacement réseau particulier pour une QA ou une localisation autorisée, associez au profil un proxy approuvé. Saisissez le protocole, l’hôte, le port et les identifiants nécessaires, puis testez la connexion. Ne placez pas les mots de passe de proxy dans des prompts partagés ou des journaux publics.

11. Gardez l’environnement cohérent

Conservez une cohérence entre l’objectif du profil, la région réseau, la langue, le fuseau horaire et les paramètres du projet. Un profil France QA ne devrait pas changer de région à chaque tâche. Des environnements stables sont plus simples à comprendre, reproduire et auditer.

12. Lancez le profil via MCP

Demandez ensuite au client MCP de lancer uniquement le profil de test. Vérifiez que la bonne fenêtre s’ouvre et que le réseau attendu est actif. Séparer création, configuration, contrôle et lancement rend les erreurs beaucoup plus faciles à isoler.

13. Passez progressivement à l’échelle

Quand le workflow de test est fiable, créez des modèles, définissez les groupes, documentez les responsabilités et n’accordez que les actions indispensables. Introduisez progressivement les écritures, la création en série ou les tâches récurrentes, avec des journaux et des contrôles humains adaptés au risque.

Cas d’usage légitimes pour BitBrowser MCP

QA assistée par IA: Maintenir des profils de test reproductibles et demander à un agent de vérifier leur état avant une session.

Tests de localisation: Conserver des environnements séparés par langue ou région afin de contrôler l’affichage d’un site de manière autorisée.

Gestion de profils: Créer, nommer, vérifier et lancer des profils dédiés à des projets internes ou à des clients autorisés.

Recherche de marché: Séparer les sessions et paramètres de plusieurs projets de recherche sans mélanger les données de navigation.

Vérification publicitaire: Utiliser des environnements approuvés pour contrôler l’expérience d’une campagne dans une région donnée, sans cliquer sur ses propres annonces.

Développement: Préparer des profils de test cohérents pour reproduire des problèmes d’interface ou de compatibilité.

Opérations d’équipe: Appliquer des groupes, permissions et conventions de nommage pour réduire les erreurs entre collaborateurs.

Automatisation interne: Associer MCP à la Local API pour des tâches administratives répétitives sur des environnements dont l’organisation possède l’autorisation.

Sécurité d’équipe et principe de moindre privilège

L’automatisation par agent augmente l’importance des permissions. Une personne ou un agent qui doit seulement lancer des profils existants n’a pas nécessairement besoin du droit de les supprimer, de modifier tous les proxys ou de changer les paramètres de l’organisation.

Utilisez les contrôles de sous-comptes, les listes d’URL autorisées ou bloquées et les restrictions disponibles dans BitBrowser pour limiter la surface d’action. Créez aussi des profils de test dédiés afin que les expérimentations MCP n’affectent pas des sessions sensibles.

Documentez le propriétaire du profil, son objectif, la région, le proxy approuvé, le groupe et la durée de conservation. Une nomenclature simple comme QA_FR_01 ou CLIENT_A_RESEARCH facilite les audits et évite qu’un agent choisisse le mauvais environnement.

Enfin, surveillez les changements. Les opérations à impact élevé devraient être journalisées et, lorsque le risque le justifie, soumises à une validation humaine avant exécution.

Bonnes pratiques pour la production

Dépannage

Conclusion

BitBrowser MCP ajoute une interface orientée agents à une infrastructure déjà conçue pour gérer des profils isolés. Le bénéfice principal n’est pas de remplacer tous les scripts, mais de permettre à un client IA compatible d’utiliser des outils de gestion du navigateur dans un contexte contrôlé.

Une configuration solide commence par la Local API, l’authentification, un test en lecture seule et un seul profil de démonstration. Ensuite, l’équipe peut ajouter un proxy autorisé, vérifier la cohérence de l’environnement, tester le lancement et seulement après introduire des actions plus larges.

En combinant MCP, Local API, profils séparés, proxys, contrôles d’équipe et procédures de sécurité, BitBrowser peut jouer le rôle de couche d’orchestration de navigateur pour des workflows IA légitimes en 2026.

Guide officiel BitBrowser MCP  •  Notes de version BitBrowser 7.1.5 •  Documentation BitBrowser

Questions fréquentes

BitBrowser prend-il en charge MCP ?

Oui. Les versions récentes de BitBrowser à partir de la branche 7.1.5 incluent le service MCP relié à la Local API.

Quel endpoint MCP dois-je utiliser ?

Utilisez l’adresse affichée par votre installation. La configuration locale standard utilise généralement http://127.0.0.1:54345/mcp.

L’authentification est-elle nécessaire ?

Oui, activez Authentication Control et conservez le jeton x-api-key comme un secret.

Puis-je connecter Cursor ?

Oui. Ajoutez la configuration MCP générée par BitBrowser dans les réglages MCP de Cursor et testez d’abord la découverte des outils.

Puis-je utiliser Claude ?

Un environnement Claude compatible avec des serveurs MCP personnalisés peut utiliser la configuration BitBrowser appropriée.

MCP remplace-t-il la Local API ?

Non. MCP est une interface orientée agent ; la Local API reste utile pour les scripts et processus déterministes.

Puis-je configurer un proxy ?

Les profils BitBrowser prennent en charge la configuration de proxys. Utilisez uniquement des endpoints que vous êtes autorisé à employer et testez-les avant le workflow.

Quelle est la meilleure manière de commencer ?

Commencez en lecture seule, créez un profil de test, vérifiez chaque étape et augmentez progressivement les permissions et le volume.