Les agents IA ont besoin de leur propre navigateur
Confier à un agent autonome votre navigateur de tous les jours, c'est lui donner vos cookies, vos connexions et votre appareil. Pourquoi les agents ont leur place dans un profil isolé, et comment leur en donner un.
Le moyen le plus rapide de donner à un agent IA de vraies capacités sur le web est de le laisser piloter un navigateur. Le moyen le plus rapide de le regretter est de lui laisser piloter le vôtre. Un navigateur de tous les jours porte chaque session où vous vous êtes déjà connecté, et un agent capable de cliquer peut cliquer sur tout ce que ces sessions atteignent.
Le problème du rayon d'impact
Un agent chargé de rechercher des fournisseurs n'a pas l'intention d'ouvrir l'onglet de votre banque. Mais le navigateur dans lequel il s'exécute ne fait aucune distinction : un seul jeu de cookies, un seul ensemble d'identifiants enregistrés, une seule identité de machine. Tout ce que l'agent peut atteindre, il y est déjà authentifié. Les mesures auxquelles on pense en premier — un autre profil Chrome, une fenêtre de navigation privée — déplacent les cookies sans rien déplacer d'autre.
Ce que l'isolation doit réellement couvrir
- Le stockage : son propre jeu de cookies, Local Storage et IndexedDB, dans un répertoire où rien d'autre n'écrit
- Les identifiants : seulement les connexions que vous avez délibérément ouvertes dans ce profil, et aucune autre
- Le réseau : sa propre route, pour que le trafic de l'agent et le vôtre ne partagent pas la même adresse
- L'identité de l'appareil : stable pour ce profil, et pas une copie de la machine sur laquelle vous travaillez
- Les extensions : seulement ce dont l'agent a besoin, pas votre gestionnaire de mots de passe
Cette liste est celle qu'un profil de navigateur isolé satisfait déjà. Du point de vue du navigateur, un agent n'est qu'un autre utilisateur de votre machine qui ne devrait pas pouvoir voir le reste de votre travail.
Donner un profil à un agent
Dans PowerOps, le schéma est court. Créez un profil pour l'agent, donnez-lui la route sur laquelle vous voulez son trafic, et connectez-le uniquement aux comptes dont cette tâche a besoin. Puis démarrez-le depuis l'API locale, qui renvoie le point d'accès de débogage du navigateur, et pointez votre framework d'agent vers ce point d'accès plutôt que vers un navigateur qu'il aurait lancé lui-même.
# Start the agent's profile and take the endpoint it returns.
curl -s -X POST http://127.0.0.1:50326/v1/browsers/start \
-H "Authorization: Bearer $POWEROPS_KEY" \
-H "Content-Type: application/json" \
-d '{"profileId": "agent-research-01"}'Tout ce qui parle le protocole Chrome DevTools se connecte à ce que cet appel renvoie — Puppeteer, Playwright, ou un framework d'agent qui encapsule l'un des deux. Rien ne change dans le code de l'agent ; ce qui change, c'est le navigateur dans lequel il atterrit.
Un profil par tâche, pas par agent
L'instinct est de donner un profil à l'agent. La meilleure unité, c'est la tâche. Un profil pour la recherche de fournisseurs, un profil pour le compte depuis lequel il a le droit de publier, un profil pour le tableau de bord qu'il consulte. Si une exécution tourne mal, les dégâts sont bornés par ce que ce profil pouvait atteindre, et vous pouvez jeter le répertoire et repartir de zéro.
Garder les exécutions comparables
Les agents sont difficiles à déboguer parce que deux exécutions sont rarement la même exécution. Un profil qui déclare le même appareil à chaque lancement, depuis la même route, avec l'état dans lequel vous l'avez laissé, supprime toute une catégorie de différences entre les tentatives. Quand une exécution se comporte autrement, l'environnement n'est plus parmi les suspects.
La limite
Rien de tout cela n'est un moyen de contourner les conditions d'un site, ses limites de débit ou sa politique robots, et ce n'est pas vendu comme tel. Ce que cela donne à un agent, c'est un navigateur qui appartient à la tâche plutôt qu'à vous.
