Que devient le flux de travail lorsque les opérations du navigateur sont confiées à MCP, et quelles parties disparaissent du code ? Ce retour pratique présente la répartition des responsabilités, quatre problèmes de configuration fréquents et un ordre de diagnostic efficace.
Avec Claude Code pour automatiser le navigateur, ce qui devient vite pénible, c’est le code de liaison : démarrer le navigateur, associer un proxy, créer des environnements et attendre des handles. Rien de tout cela ne relève de la logique métier, mais il faut pourtant le réécrire sans cesse. En déléguant les opérations du navigateur à MCP, cette partie disparaît presque du code. Vous décrivez ce qu’il faut faire, et le modèle choisit lui-même l’outil à appeler.
Comment répartir les responsabilités
Claude Code est un assistant de programmation en ligne de commande. Il peut lire et écrire des fichiers, exécuter des commandes et travailler avec Git. Son point fort se situe du côté du code et du terminal. Il n’est pas conçu pour manipuler directement le navigateur, et ce n’est pas son rôle.
MCP comble précisément ce manque. Il encapsule les capacités d’un environnement d’automatisation du navigateur sous forme d’outils que le modèle peut appeler après leur enregistrement : lister et créer des environnements, démarrer et arrêter le navigateur, prendre des captures d’écran et lire le contenu des pages. Un côté gère le code et les journaux, l’autre le navigateur et les pages. Avec cette séparation claire, les problèmes sont aussi plus faciles à localiser.
Comment le flux de travail évolue
Le changement le plus visible est la rapidité avec laquelle la chaîne complète peut être montée. Avant, toute modification du processus obligeait à retoucher un script. Désormais, on peut d’abord tester en langage naturel : lister les environnements disponibles, se connecter dans deux d’entre eux et faire des captures, puis regrouper les résultats. Une fois le flux validé, on le fige dans un script.
Dans un projet réel, trois couches travaillent généralement ensemble. MCP reçoit les instructions en langage naturel et convient bien à l’exploration et aux tâches ponctuelles. Une API HTTP locale gère les actions en masse, par exemple créer des dizaines d’environnements en une seule fois, avec un comportement stable et facile à relancer. Pour les interactions fines, comme attendre l’apparition d’un état précis ou extraire des données structurées d’une page, CDP se connecte directement au navigateur. Ces trois approches ne s’opposent pas : chacune prend en charge une partie du flux.
La gestion séparée de la couche d’environnements est une autre leçon tirée de cette étape. Lorsque les environnements sont dispersés entre plusieurs scripts, le diagnostic devient vite difficile à mesure que les tâches se multiplient. Désormais, ils sont créés, consultés et récupérés en lot de manière centralisée avec des outils dédiés, tandis que le script reçoit simplement un ID d’environnement à utiliser. Dans les scénarios multi-comptes, une solution d’isolation comme PurpleMark remplit précisément ce rôle : elle sépare l’environnement, la session et le cache de chaque compte afin que la couche d’exécution puisse les planifier correctement.
Quatre points où l’on se bloque souvent
Premier point : l’outil n’est pas reconnu. De nombreux clients ne lisent la configuration qu’au démarrage ; enregistrer un outil sans redémarrer ne produit donc aucun effet. Une mauvaise adresse du fichier de configuration est également fréquente, car son emplacement varie selon les outils. Un test très simple reste efficace : démarrer le service manuellement. S’il démarre, le problème vient probablement de la configuration ; sinon, il vient de l’environnement.
Deuxième point : l’authentification échoue. La cause la plus fréquente est un identifiant copié avec un espace ou un saut de ligne en trop. Il faut vérifier cela en premier, puis examiner la façon dont les variables d’environnement sont lues. Le résultat peut effectivement varier selon le système d’exploitation et le mode de lancement.
Troisième point : l’API locale ne tourne pas. Beaucoup de services MCP dépendent du fait que l’application cliente elle-même soit ouverte. Si le client est fermé, le service peut ne pas démarrer ou les connexions peuvent expirer. Vérifiez aussi si le port est déjà occupé ; un ancien processus mal arrêté peut encore le conserver. Le numéro du port est consultable dans les paramètres du client.
Quatrième point : les tâches concurrentes se perturbent. Une tâche seule fonctionne correctement, mais plusieurs en parallèle provoquent des données mélangées ou des sessions de connexion qui s’écrasent. La cause est généralement le partage du même environnement par plusieurs tâches. Ce problème ne se corrige pas par le débogage ; il faut imposer une règle : un environnement par tâche, avec création et récupération via l’API par lots, jamais à la volée dans les scripts.
Quelques habitudes de débogage
Précisez clairement les conditions d’attente dans les instructions. « Cliquer sur le bouton Envoyer » ne donne pas assez d’informations. « Attendre que le bouton Envoyer soit cliquable, puis cliquer » améliore nettement le taux de réussite. Le modèle décide quoi faire, mais le moment où il doit attendre doit être indiqué.
Commencez par valider la chaîne avec des tâches en lecture seule. Lister les environnements, prendre des captures d’écran et lire le texte d’une page n’ont pas d’effet secondaire, mais permettent de tester d’un coup l’authentification, le réseau et le service. Tant que la chaîne ne fonctionne pas, évitez les opérations qui produisent des effets secondaires.
Ne mettez pas les identifiants dans le code. Utilisez des variables d’environnement ou des fichiers de configuration locaux, ajoutez ces fichiers à la liste d’exclusion et faites tourner les identifiants lorsque l’équipe change. Si une API locale a désactivé sa propre validation, assurez-vous au minimum qu’elle n’écoute que sur la machine locale et qu’elle n’est pas accessible de l’extérieur.
Dernière limite : MCP relie la chaîne technique, mais ne change pas les règles de la plateforme. Même avec une intégration parfaitement fluide, la tâche reste soumise à toutes les conditions de service applicables.
