Exécution dans un navigateur pour les agents d’IA : Playwright, MCP et un exécuteur sécurisé

Les agents de production maîtrisent déjà parfaitement les machines. Ils interagissent avec des API, se connectent à des serveurs MCP, exécutent du code, consultent le web, ouvrent des fichiers et lancent des commandes en ligne de commande. Pourtant, une proportion surprenante de logiciels réels ne met à disposition que leur interface utilisateur basée sur un navigateur pour certaines de leurs opérations clés, et c’est là que l’exécution dans un navigateur vient combler le manque.

Les derniers produits d’agents disposent d’un navigateur ou d’un ordinateur cloud à disposition pour l’agent. Il est tentant de considérer cela comme une simple démonstration d’une intelligence artificielle cliquant sur des boutons. Une interprétation plus utile est d’ordre architectural : le navigateur n’est pas un nouveau type d’agent, c’est un nouvel environnement d’exécution.

La différence est importante. Si un système offre déjà des serveurs MCP, des compétences, l’exécution de code, des appels d’outils programmatisés, des environnements de test isolés, des fonctionnalités de recherche ainsi que des connexions directes au backend, un navigateur ne devrait pas remplacer aucun de ces éléments. Il étend le système vers des domaines qu’il ne peut pas couvrir de manière fiable : des applications à état, lourdes en JavaScript, nécessitant une authentification et conçues pour les humains.

La recherche sert à trouver des informations. Les API et MCP communiquent avec les systèmes. Le code transforme les données et coordonne les étapes. Un navigateur gère l’interface conçue pour les utilisateurs.

L’interface oubliée

Les architectures d’agents commencent généralement par des capacités structurées. Lorsqu’un service fournit une API REST bien organisée, un SDK ou un serveur MCP, c’est presque toujours l’interface la plus adaptée pour un agent : un contrat explicite, des entrées et sorties de type défini, des erreurs plus faciles à gérer et des limites de sécurité plus claires.

Vient ensuite l’exécution de code. Plutôt que de faire en sorte que le modèle appelle vingt outils un par un, on peut lui faire écrire un petit programme qui les appelle, agrège les résultats localement, filtre les données et renvoie une réponse compacte. Cela convient aux grands catalogues d’outils, aux appels répétés et aux workflows à forte charge de données. Un environnement sandbox ajoute une couche supplémentaire avec Python, le shell, des fichiers, et éventuellement des outils Kubernetes ou GitHub, tout cela dans un environnement contrôlé. À ce stade, l’agent peut accomplir de nombreuses tâches, mais il suppose toujours que tout ce qui est utile est exposé via des interfaces lisible par machine.

Pas vraiment. De nombreux outils ne sont accessibles qu’à travers des écrans : des panneaux d’administration internes, des portails anciens de fournisseurs, des tableaux de bord de reporting, des systèmes de partenaires, des plateformes d’offres d’emploi, des produits d’analyse, des pages de configuration SaaS, ou des applications qui ne récupèrent des données réelles qu’après avoir appliqué plusieurs filtres. Les données peuvent être publiques, tandis que l’état utile est généré par JavaScript. Une personne peut trouver cette tâche simple, mais aucune API n’est documentée. Parfois, une API interne existe, mais elle est privée, instable ou délibérément non prise en charge.

C’est là l’usage réel : ne pas permettre à l’IA de naviguer sur Internet de manière générale, mais d’utiliser le navigateur comme interface de secours lorsque l’application elle-même fait partie de la tâche.

Pourquoi MCP ne couvre pas encore cela

Chaque fois que la question de l’exécution dans un navigateur se pose, elle suscite également cette interrogation, qui mérite une réponse claire. MCP ne requiert jamais que le système cible dispose d’une API ; il précise simplement comment un agent communique avec une capacité. Supposons que l’application cible ne propose que des interfaces utilisateur destinées aux utilisateurs. Le code d’un outil MCP peut alors faire fonctionner un navigateur lui-même. La limite n’est pas MCP, mais plutôt l’absence d’une interface stable et structurée derrière le système cible.

La cible peut ne pas exposer de contenu structuré. Ce qui se trouve derrière MCP peut être un navigateur, un environnement isolé, un moteur de workflow ou quelque chose de complètement différent. Les problèmes surviennent lorsque l’application ne dispose d’aucune API publique, d’aucun SDK, d’aucune intégration de base de données ni de méthode programmative permettant d’accéder à l’opération souhaitée. MCP peut tout de même publier une outil nommé browser_execute, mais quelque chose derrière lui doit gérer le système, ce qui correspond à l’exécution dans un navigateur. Ce ne sont pas des concurrents : MCP peut être le protocole qui expose les capacités du navigateur, tandis que le navigateur est le moyen par lequel l’application destinée aux utilisateurs interagit lorsque rien de mieux n’existe.

L’authentification peut être liée au navigateur. MCP dispose de son propre modèle d’autorisation, y compris des flux OAuth, mais il ne couvre que la communication entre le client MCP et le serveur MCP. Il laisse intactes les règles de connexion du système dans lequel l’outil doit finalement fonctionner. De nombreux portails internes, applications de fournisseurs et produits SaaS plus anciens n’autorisent l’accès qu’au moyen d’un flux interactif via navigateur avec SSO, MFA, cookies de session ou d’autres éléments de statut créés lors d’une connexion manuelle, sans qu’aucune clé de service ou jeton délégué n’existe. Un outil MCP peut néanmoins exposer cette fonctionnalité, en s’appuyant sur un profil de navigateur authentifié. L’utilisateur se connecte via le navigateur, l’état de session est géré avec un accès contrôlé, et il peut ensuite effectuer des actions en utilisant cette identité. La limite réside dans le modèle d’authentification de l’application cible, et non dans celui de MCP.

Certaines tâches relèvent de flux de travail d’interface utilisateur et ne consistent pas en des appels uniques. Prenons l’exemple de « sélectionner Retail, Europe et les 90 derniers jours, puis calculer la conversion moyenne par pays ». Cela peut nécessiter une série de filtres, une étape de rendu et l’extraction de l’état résultant, sans qu’aucun point de terminaison ne renvoie directement la réponse. Le navigateur peut gérer l’interface et lire ce que l’application produit.

Les API structurées, appelées directement ou via MCP, restent la première option dès lors qu’elles existent. Elles sont moins coûteuses, plus déterministes et plus faciles à sécuriser. Le navigateur s’occupe de la partie qui se trouve uniquement derrière l’interface destinée aux utilisateurs.

La recherche n’est pas du navigation

Dans de nombreux ensembles d’agents, la recherche sur le Web, la récupération de données via HTTP, l’automatisation du navigateur et l’utilisation d’ordinateur sont regroupées en une seule compétence floue appelée « Web », alors qu’il s’agit en réalité d’outils différents.

Pour savoir ce qui a changé dans la dernière spécification MCP, une recherche sur Internet suffit probablement. Avec l’URL d’un article public ordinaire, une récupération directe peut être suffisante. Pour travailler avec Salesforce, il faut utiliser son API ou MCP. Pour calculer des statistiques à partir de JSON, il faut utiliser du code.

Imaginons maintenant une autre demande : ouvrir un tableau de bord public, choisir l’Ukraine, définir l’année sur 2026, sélectionner l’option Enterprise, parcourir chaque catégorie et calculer la moyenne de chaque indicateur. Un moteur de recherche ne peut pas effectuer cette interaction, et une simple requête HTTP ne renverra probablement que la structure vide de la page. Les données intéressantes apparaissent après que le navigateur a exécuté du JavaScript, envoyé des requêtes côté client, mis à jour l’état de l’application et affiché le résultat.

Ou un site d’offres d’emploi : choisissez « Ingénierie IA », « Télétravail » et « Allemagne », puis comptez le nombre de postes dont la description mentionne RAG. Ce n’est pas vraiment une requête de recherche. Il s’agit d’un flux de travail utilisateur suivi d’une extraction et d’un calcul. C’est là qu’un véritable navigateur offre à l’agent quelque chose de nouveau, une surface d’exécution web à état.

Le navigateur est un environnement d’exécution

Un navigateur géré comme Amazon Bedrock AgentCore Browser constitue une infrastructure : une session de navigateur à distance isolée qui peut être contrôlée de manière programmée. Le LLM ne communique pas avec lui par magie. C’est vous qui définez le contrat entre l’agent et l’environnement.

AgentCore Browser expose les sessions via un point d’entrée d’automatisation WebSocket, et des bibliothèques comme Playwright peuvent se connecter au Chromium distant au moyen du Chrome DevTools Protocol. AWS propose des actions de navigateur au niveau du système d’exploitation pour les interactions que CDP ne peut pas gérer correctement. Le navigateur est un environnement d’exécution distant et non une couche d’intelligence. Vu sous cet angle, l’intégration devient plus simple : l’agent a besoin d’une capacité programmable, et c’est dans l’environnement d’exécution du navigateur que cette capacité s’exécute.

Permettez à l’agent d’écrire le code du navigateur

Un navigateur peut atteindre un agent de plusieurs manières. Une option consiste à utiliser un outil de haut niveau comme browser_task(task="trouver la dernière facture"), contenant un agent spécifique au navigateur qui lit la tâche, explore le site, choisit ce sur quoi cliquer et rapporte les résultats. Cela peut être utile pour des sites inconnus où le flux de travail doit être découvert, mais c’est un mauvais point de départ.

Si le modèle principal est un codeur compétent, une approche plus propre consisterait à le faire générer le programme navigateur avant de le transmettre à un Exécuteur de navigateur. Une signature aussi simple que browser_execute(code, profile_id, allowed_domains) suffit :

browser_execute(
    code=generated_playwright_code,
    profile_id="vendor-portal-user-42",
    allowed_domains=["portal.example.com"]
)

Lorsque l’appel arrive, l’exécuteur vérifie la demande, puis crée (ou réutilise) une session isolée et relie Playwright au navigateur distant. Il exécute le programme et restitue des données structurées. L’agent principal effectue ses calculs une seule fois. Un deuxième LLM qui interprète à nouveau la même intention n’a de sens que lorsque la tâche nécessite réellement une exploration. Pour un tableau de bord, un catalogue ou un portail prévisibles, cette approche est supérieure à un agent navigateur imbriqué en termes de coût et de facilité d’observation.

Pourquoi le mode code convient

Cela est particulièrement important là où l’utilisation d’outils programmatisés est déjà en place. Le schéma gaspilleur est facile à repérer : le modèle appelle click, obtient un résultat, appelle screenshot, réfléchit à nouveau, appelle type, obtient un autre résultat. Ce qui pourrait être géré par un simple script en quelques millisecondes devient alors des dizaines d’appels au modèle.

La meilleure approche consiste à regrouper les outils de correspondance de motifs : permettez au modèle d’écrire un seul programme qui effectue de nombreuses opérations du navigateur au sein de l’environnement d’exécution et qui renvoie un seul résultat compact.

page = await browser.page()
await page.goto("https://jobs.example.com")
await page.get_by_label("Category").select_option("AI Engineering")
await page.get_by_label("Location").select_option("Germany")
await page.get_by_label("Remote").check()
await page.get_by_role("button", name="Apply").click()
jobs = await page.locator(".job-card").all_inner_texts()

rag_jobs = [job for job in jobs if "RAG" in job.upper()]
return {
    "total_jobs": len(jobs),
    "jobs_mentioning_rag": len(rag_jobs)
}

Le modèle écrit un programme, l’exécuteur effectue des dizaines ou des centaines d’opérations DOM déterministes, et l’agent reçoit un petit objet JSON à la place d’une longue série de clics et d’captures d’écran.

Cela peut aller plus loin. Un environnement d’exécution de code conscient des capacités peut fournir au programme généré un ensemble d’interfaces contrôlées : des clients MCP, du HTTP pur, des fichiers, un contrôle du navigateur et des calculs locaux. Un seul programme peut alors récupérer des comptes depuis Salesforce via MCP, ouvrir un portail obsolète, lire une métrique pour chaque compte, les agréger et retourner une seule réponse.

customers = await mcp.salesforce.search_accounts(segment="enterprise")

results = []
for customer in customers:
    await browser.goto(f"https://legacy.example.com/customer/{customer.id}")
    metric = await browser.locator("#health-score").inner_text()
    results.append({
        "customer": customer.name,
        "health_score": metric,
    })
return summarize(results)

Ce n’est pas une intelligence artificielle qui clique au hasard. Il s’agit d’une orchestration programmée entre des interfaces machines et des interfaces humaines.

Un flux de travail concret

Prenons une demande qui semble simple : se rendre sur un tableau de bord d’analyse public, sélectionner le secteur du commerce de détail, choisir l’Europe, limiter la période aux 90 derniers jours et comparer les différences de taux de conversion et de rétention entre les pays.

L’agent ne devrait pas passer directement par un navigateur. Un routeur de capacités vérifie d’abord s’il existe une méthode moins coûteuse et plus structurée. Si la recherche peut répondre, on utilise la recherche. Si la page propose une API stable, on l’appelle. Si les données sont disponibles via une récupération HTTP directe, inutile de lancer Chromium.

Si les valeurs n’apparaissent qu’après une interaction côté client, le routeur choisit l’exécution dans le navigateur. L’agent principal génère un programme Playwright, l’exécuteur le lance dans la session gérée, attend que la page cesse de changer, lit les nombres affichés et les renvoie sous forme de données structurées. Le mode code effectue ensuite la comparaison, et l’agent enregistre la réponse. L’utilisateur n’a pas besoin de savoir qu’un navigateur a été ouvert. Dans de nombreux produits, il s’agit d’une fonctionnalité backend invisible, similaire à une requête de base de données ou à un environnement de test de code.

Automatisation en premier, utilisation de l’ordinateur en second

L’automatisation des navigateurs et l’utilisation de l’ordinateur sont parfois considérés comme une seule et même chose, mais ils relèvent de niveaux différents de la pile technique. Playwright et CDP s’occupent de la structure du navigateur : pages, sélecteurs, éléments DOM, formulaires, requêtes réseau, téléchargements et état. Grâce à cela, ils fonctionnent plus rapidement, consomment moins de ressources, et il est plus simple de les tester et de les isoler.

L’utilisation de l’ordinateur est visuelle. Le modèle observe l’écran et exécute des actions avec la souris ou le clavier. Il prend son rôle en charge lorsque le DOM ne parvient pas à gérer l’interface de manière fiable : applications canvas, boîtes de dialogue natives, menus contextuels, flux de glisser-déposer complexes. AWS adopte la même approche dans AgentCore Browser, où le chemin d’automatisation WebSocket est basé sur CDP, et l’API InvokeBrowser offre un contrôle au niveau du système d’exploitation pour les tâches que CDP ne peut pas effectuer. Il convient donc d’utiliser d’abord une automatisation structurée et de recourir au contrôle visuel uniquement en cas de besoin. Plus l’agent descend dans la pile, plus il devient flexible, mais chaque action devient également plus coûteuse, plus gourmande en ressources et plus risquée.

Après un recours à l’utilisation de l’ordinateur, l’exécuteur doit mettre en œuvre un cycle de vérification fermé, et non une série d’actions effectuées de manière aveugle. Un clic qui se termine sans erreur ne prouve rien quant à l’opération effectuée. La page pourrait encore être en chargement, un modal pourrait avoir absorbé l’action, ou un autre élément pourrait avoir intercepté le clic. Après chaque étape, le système doit examiner l’état actuel et s’assurer que le changement attendu s’est produit avant de passer à l’étape suivante. Il doit également détecter les actions répétées qui ne produisent aucun résultat. Si la même étape se répète sans aucun changement, tenter à nouveau est inapproprié ; il convient alors de replanifier ou de revenir à une stratégie plus structurée.

Ce cycle repose sur trois principes de contrôle : limiter le nombre d’écrans capturés, identifier les actions répétées qui ne changent rien, et appliquer progressivement les différents niveaux d’autorisation, action par action.

L’authentification rend cela vraiment efficace

Les tableaux de bord publics reposent sur une démonstration de concept, mais la valeur d’entreprise se manifeste à travers des applications authentifiées. Playwright dispose déjà d’une conception solide des contextes de navigateur ainsi que d’un état d’authentification réutilisable, et AgentCore Browser ajoute des profils gérés qui conservent les cookies et le stockage local entre les sessions. Un utilisateur se connecte une fois, le profil est enregistré, et une session ultérieure restaure cet état. Cela convient aux portails internes, aux systèmes clients, aux solutions SaaS anciennes et aux applications de fournisseurs où une intégration API nécessiterait sinon un reverse engineering personnalisé ou serait impossible.

Cela modifie également la manière dont l’identité est modélisée. Un profil de navigateur constitue en réalité une identité d’exécution munie de crédences, et non un objet générique destiné à la commodité. Le profil permettant d’accéder à un portail financier ne devrait pas être automatiquement disponible pour tous les agents ou workflows. En environnement de production, liez les profils au locataire, à l’utilisateur, à la finalité et à la portée de la politique, et accordez à l’agent un accès spécifique à un profil donné, plutôt qu’un accès général à toutes les sessions appartenant à l’utilisateur.

La sécurité est plus importante que la démonstration

L’exécution via un navigateur est puissante car elle s’effectue à travers la même interface que celle utilisée par un humain, ce qui signifie également qu’elle peut commettre des erreurs en utilisant les privilèges d’un humain.

La première limite concerne l’exécutant. Le code du navigateur généré doit fonctionner de manière isolée, avec des restrictions de domaine explicites, des délais d’expiration, des limites de ressources et un accès contrôlé aux profils. Le modèle ne doit pas obtenir de variables d’environnement du hôte, de identifiants arbitraires ou d’adresses réseau générales, simplement parce qu’il peut exécuter Playwright.

La deuxième limite est la politique d’action. Extraire des métriques d’une page est une action différente de publier du contenu, d’envoyer des messages, de modifier les permissions du compte, d’effacer des données ou d’approuver un paiement. Il convient de classer ces effets secondaires en dehors du modèle et de les contrôler au niveau d’exécution.

Le troisième problème est l’injection de commandes. Une fois qu’un agent lit des pages arbitraires, tout ce qui est affiché devient une entrée non fiable. Le texte présent dans un tableau de bord, un e-mail, une bannière ou un document peut ressembler à une commande destinée à l’agent. L’exécutant ne doit jamais considérer le contenu affiché comme une autorisation de la part de l’utilisateur. Les directives d’OpenAI concernant l’utilisation des ordinateurs disent la même chose : traiter le contenu provenant de tiers comme non fiable et demander une confirmation juste avant d’effectuer des actions risquées telles que publier, envoyer, supprimer, modifier des permissions ou transférer de l’argent. Il s’agit d’une question de politique d’exécution, et non seulement d’ingénierie des commandes. Le navigateur peut observer de manière générale, mais il ne doit modifier le monde qu’au travers d’une politique explicite.

L’observabilité suit. Un exécuteur en production doit enregistrer la tâche demandée, le profil utilisé, les domaines consultés, le programme exécuté, les fichiers téléchargés, les effets secondaires externes tentés ainsi que les cas où une approbation humaine était nécessaire. AgentCore Browser peut être surveillé en direct, et les navigateurs personnalisés permettent d’enregistrer et de rejouer une session, ce qui offre une base solide pour les audits.

Comment cela s’intègre avec MCP, les compétences et les sandbox

Rien ici ne remplace quoi que ce soit d’autre. MCP et les API restent préférés pour les opérations commerciales structurées. Le package de compétences comprend des procédures reproductibles, ainsi que des connaissances contextuelles et opérationnelles. Le mode code reste le moyen le plus efficace pour les appels répétés, l’agrégation et la transformation. Les environnements de test restent l’espace contrôlé pour les fichiers, les shells, Python, les tests et les calculs intensifs. L’exécution dans un navigateur comble un besoin distinct : permettre l’utilisation d’une interface destinée aux utilisateurs lorsque pas d’équivalent adapté aux machines n’est suffisamment fiable.

Restez prudent dans la gestion des chemins d’accès. Une API peut-elle accomplir la tâche ? Utilisez-la. Un accès direct suffit-il ? N’ouvrez pas de navigateur. Le site lui-même doit-il être manipulé pour obtenir le résultat ? Alors l’exécution dans un navigateur est la solution appropriée. L’automatisation structurée ne peut-elle pas terminer l’interaction ? L’utilisation d’un ordinateur devient alors le dernier recours.

MCP en tant que contrat

En pratique, les branches restent rarement séparées. L’exécution du code, l’exécution dans le navigateur et même la découverte d’outils se font généralement via un serveur MCP. MCP n’est pas seulement la branche API ; c’est le contrat grâce auquel un agent obtient n’importe quelle capacité, qu’il s’agisse d’une requête REST, d’un script dans un environnement isolé ou d’un Chromium distant en arrière-plan.

Le regroupement fonctionne bien avec un serveur MCP dédié qui expose un petit nombre d’outils, tels que execute_code, browser_execute et find_tool, au lieu d’un outil par action sous-jacente. Le nombre d’outils reste donc à trois ou quatre, et non à trente. Un modèle n’a pas besoin d’outils distincts pour cliquer, prendre une capture d’écran ou sélectionner une option, tout comme il n’a pas besoin d’outils séparés pour redémarrer, échaler ou revenir en arrière, lorsqu’une seule opération avec un plan suffit.

La portabilité en est une autre raison. Un serveur peut être utilisé derrière un agent personnalisé ou connecté directement à Claude, ChatGPT ou tout client compatible MCP, permettant ainsi de tester les mêmes fonctionnalités via une interface familière sans nécessiter une intégration supplémentaire.

Conserver l’exécuteur séparé

Du point de vue de l’agent, le navigateur peut sembler faire partie du mode code, car un script généré peut utiliser browser.goto() et browser.locator() aux côtés des clients MCP, des fichiers et des API de calcul au sein d’un même environnement de exécution logique. Lors du déploiement, l’Executor de navigateur reste préférable en tant que composant distinct. Les navigateurs possèdent leur propre cycle de vie et leurs propres risques : sessions, cookies, stockage local, fichiers téléchargés, règles réseau, profils connectés, état des pages, enregistrements et effets secondaires en dehors de votre système. Une sandbox de code gère quant à elle la CPU, la mémoire, les fichiers, les paquets et les processus. En les séparant, chaque environnement de exécution peut appliquer le modèle de sécurité qui lui convient. Le mode code peut fournir un client navigateur restreint, tandis que l’executor gère la session à distance, ce qui permet de maintenir un modèle de programmation unifié tout en gardant l’infrastructure divisée.

Commencer à être ennuyeux

Omettez l’agent navigateur autonome universel au début. La première version fonctionnelle est délibérément simple : une session Chromium distante isolée, un petit contrat browser_execute, Playwright pour l’automatisation, une liste blanche stricte des domaines autorisés et des résultats structurés. Testez-la sur un tableau de bord public riche en JavaScript ou une application de exemple où vous pouvez démontrer que le navigateur est supérieur aux recherches et aux récupérations via HTTP.

Lorsque cela fonctionne, connectez-le au schéma programmatisé déjà utilisé pour le mode code, afin que l’agent principal génère un programme navigateur sans devoir appeler constamment des outils de clic de bas niveau. Ajoutez ensuite des profils authentifiés pour les applications internes contrôlées, ainsi que des politiques d’action et des contrôles d’approbation avant que tout flux de travail ne puisse provoquer des effets secondaires externes. Utilisez uniquement l’affichage visuel pour les interfaces que Playwright ne peut pas gérer de manière fiable, et envisagez un cycle agent-navigateur spécialisé qui observe, raisonne, réessaie et explore uniquement lorsque une tâche est trop ambiguë pour que l’agent principal puisse générer un programme stable. Cette séquence permet de maintenir une architecture compréhensible et de reporter les comportements les plus coûteux et les moins déterministes à des cas limités, plutôt que de les faire figurer par défaut.

Le changement majeur

Ce qui est intéressant, ce n’est pas le fait qu’un LLM puisse cliquer sur un bouton : l’automatisation des navigateurs existe depuis des années. Ce qui est nouveau, c’est qu’un agent puisse décider quand le navigateur constitue l’interface appropriée, écrire le programme qui le pilote, combiner les résultats avec des appels MCP et l’exécution de code, et continuer ainsi, sans qu’aucun développeur ait à créer une intégration sur mesure pour chaque application destinée aux utilisateurs.

Les interfaces machines restent supérieures : plus fiables, plus sécurisées et plus faciles à gérer. Mais le monde est plein de systèmes qui ne proposent pas les fonctionnalités nécessaires via une interface claire, et les workflows devaient autrefois se terminer par une personne qui devait ouvrir le site pour terminer le travail. L’exécution dans le navigateur déplace cette frontière : elle fait de l’interface utilisateur humaine une autre surface programmable, à utiliser avec prudence, à isoler strictement, et à privilégier uniquement lorsque les interfaces structurées se révèlent insuffisantes.

La prochaine génération de plateformes d’agents doit être comprise non pas comme de simples collections d’outils plus volumineuses ou des armées de bots navigateurs, mais comme des systèmes disposant de plusieurs environnements d’exécution ainsi que d’un routeur qui sait lequel doit gérer chaque partie d’une tâche. L’objectif n’est pas de faire en sorte que les agents cliquent davantage, mais de leur permettre d’accéder aux parties du logiciel que les API ne mettent pas encore à disposition.