Relier N outils à M modèles imposait autrefois N×M couches d’adaptation. MCP découple le côté outils du côté modèles afin que chacun n’implémente le protocole qu’une seule fois. Cet article présente ce choix d’architecture, l’abstraction des environnements et actions de navigateur, ainsi que les problèmes encore ouverts.
Pour qu’un Agent accomplisse réellement une tâche, il finit généralement dans un navigateur : se connecter, publier, collecter des données ou remplir des formulaires. La difficulté technique n’est pas de savoir s’il peut cliquer, mais de maîtriser le coût d’intégration lorsqu’on confie un navigateur à un Agent.
Le piège des adaptations N×M
Supposons qu’il existe N outils et M modèles sur le marché. Le fournisseur d’un outil doit écrire une intégration pour chaque modèle, tandis que le côté modèle doit prévoir une couche d’adaptation pour chaque outil. Les deux parties maintiennent leurs propres implémentations, soit N×M au total.
Le problème vient de cette multiplication. Ajouter un outil ne représente pas une seule tâche supplémentaire : il faut connecter cet outil à chacun des modèles. Inversement, lorsqu’un modèle change de version, des outils déjà intégrés peuvent devoir être validés à nouveau. Une capacité peut être excellente ; sans adaptation pour un modèle donné, elle reste inutilisable avec lui. L’outil se retrouve ainsi bloqué dans la couche de distribution.
Au début, chacun devait construire sa propre solution. Pour la même opération — lister les environnements, démarrer un navigateur, lire une page — il fallait tout réécrire dès que l’appelant changeait, avec des logiques souvent incohérentes : certains plaçaient les attentes dans le client, d’autres dans le serveur.
Le protocole découple les deux côtés
MCP (Model Context Protocol) a été rendu public fin 2024. Son principe est de normaliser la découverte et l’appel des outils : ce qui est exposé, la façon dont les paramètres sont décrits et la structure des résultats sont définis dans le protocole.
L’architecture devient alors un Agent relié à un MCP Client, lequel se connecte selon le protocole à plusieurs MCP Server ; les capacités concrètes se trouvent derrière ces serveurs. Le volume d’implémentation passe de N×M à N+M : le côté modèle implémente le client une fois, et le côté outil implémente le serveur une fois.
Il n’existe que trois rôles. Le Host est l’application qui exécute le modèle et démarre le client. Le Client est l’implémentation cliente du protocole, généralement une par Server. Le Server est développé par le fournisseur de l’outil et expose ses capacités sous forme d’outils standardisés.
Deux modes de communication sont actuellement utilisés. Le mode local passe par l’entrée et la sortie standard, le client et le serveur se trouvant sur la même machine ; le chemin est court et la configuration légère, ce qui en fait un choix fréquent pour l’automatisation. Le mode distant utilise HTTP ou WebSocket et convient aux déploiements distribués, au prix d’une réflexion supplémentaire sur l’authentification et les frontières réseau.
Dans le navigateur, trois couches sont exposées
Lorsqu’un environnement de navigateur est raccordé au protocole, les capacités exposées se répartissent globalement en trois couches.
La couche supérieure concerne l’environnement : lister les environnements d’un compte, en créer un à partir d’une configuration, démarrer un environnement donné, lui associer une sortie réseau et l’arrêter après utilisation. Ces opérations étaient autrefois dispersées entre les API des fournisseurs ; elles deviennent maintenant des outils que le modèle peut découvrir et appeler. Le démarrage renvoie généralement un point de terminaison de débogage, par exemple un port ou une adresse WebSocket, qui peut ensuite être transmis à des pilotes comme Selenium ou Puppeteer.
La couche intermédiaire concerne la page : ouvrir une adresse, lire le DOM ou l’arbre d’accessibilité, changer d’onglet et prendre une capture d’écran.
La couche inférieure regroupe les actions : cliquer, saisir du texte, faire défiler, attendre qu’une condition soit remplie et gérer les fenêtres contextuelles.
Le changement essentiel ne tient pas au nombre d’actions disponibles. L’environnement passe d’un morceau de code qu’il faut écrire soi-même à une ressource que l’Agent peut choisir et utiliser. Il suffit d’indiquer l’objectif ; l’Agent peut décider de créer un nouvel environnement ou d’en réutiliser un, ainsi que de l’ordre des appels. Ce point devient particulièrement visible lorsque plusieurs environnements fonctionnent en parallèle : l’ordonnancement est décrit dans le prompt au lieu d’être codé en dur dans un script.
Ce qui n’est pas encore résolu
Le protocole résout la connexion, pas la justesse. Plusieurs points faciles à négliger restent ouverts.
La qualité de la description des outils détermine le résultat des appels. Si les paramètres sont erronés ou si le mauvais outil est choisi, le protocole ne peut pas corriger le problème. Lorsque le nombre d’outils augmente, leurs descriptions consomment aussi du contexte : il faut donc arbitrer entre quantité et granularité. Une granularité trop grossière empêche le modèle de comprendre tout ce qu’un outil sait faire ; une granularité trop fine remplit le contexte trop vite.
Les permissions et l’audit sont encore à un stade précoce. De nombreux serveurs fonctionnent localement sur une seule machine, démarrent avec des privilèges importants et ne disposent ni d’autorisations fines ni de journaux d’appels détaillés. En mode distant, il faut d’abord déterminer qui peut se connecter et ce qui lui est visible.
L’instabilité des pages n’a pas disparu. Éléments introuvables, ordre de chargement incertain, sessions expirées et CAPTCHA exigent toujours des attentes, des nouvelles tentatives et des solutions de repli. Le protocole ne fait qu’unifier le point d’entrée.
La maturité de l’écosystème reste également inégale. Les différents serveurs ne prennent pas exactement en charge les mêmes types de ressources, structures de retour ou codes d’erreur. Lorsqu’une tâche combine plusieurs serveurs, la logique d’orchestration doit souvent encore être écrite manuellement. Le protocole lui-même continue d’évoluer, et les différences de comportement entre versions doivent être surveillées.
Une autre frontière doit rester claire : le protocole définit la manière dont un modèle appelle des outils, mais pas la conformité de la tâche elle-même. Savoir si la collecte est autorisée, si l’usage d’un compte est légitime ou si les règles d’une plateforme sont respectées relève d’évaluations indépendantes, sans rapport avec la fluidité de la connexion.
Dans les scénarios multi-environnements, l’isolation entre environnements et la cohérence entre sortie réseau, fuseau horaire et langue influencent souvent davantage le résultat que la méthode d’intégration. Au niveau de l’isolation, PurpleMark fournit des interfaces de création, de démarrage et de configuration réseau d’environnements qui peuvent être appelées par des outils d’AI et orchestrées depuis un même client.
Ce texte présente uniquement des principes techniques. Utilisez les protocoles et outils concernés dans le respect des lois et règles applicables.
