Un Agent dans une seule fenêtre suffit pour une démonstration. En production, des dizaines de tâches simultanées ont besoin d’environnements séparés, sinon les sessions se contaminent, les onglets se disputent les ressources et les pannes deviennent difficiles à diagnostiquer.
Une seule fenêtre de navigateur suffit pour montrer ce qu’un AI Agent peut faire. Dès qu’on l’intègre à un usage métier réel, le besoin passe rapidement à des dizaines de fenêtres qui ne doivent pas se perturber. Le problème ne vient pas de l’Agent lui-même, mais du navigateur qui lui sert d’environnement d’exécution.
Quels problèmes pose le partage d’un même environnement ?
Le plus évident est la contamination entre cookies et états de connexion. Dans un même répertoire de données du navigateur, deux tâches qui se connectent successivement avec des comptes différents peuvent écraser leurs sessions respectives. Si une tâche vide le cache, l’état de page d’une autre peut également disparaître.
Vient ensuite la concurrence pour les ressources. Dans une même instance de navigateur, les onglets, le focus, le dossier de téléchargement et les fenêtres contextuelles sont partagés. Si deux tâches ouvrent de nouveaux onglets au même moment, il devient difficile de savoir quelle tâche contrôle quelle page. Une boîte de dialogue ouverte par l’une peut bloquer le script de l’autre. Les conflits de connexion, les écrasements de données et les interférences sont presque inévitables en cas de concurrence.
Le troisième problème apparaît après un échec. Il devient difficile de déterminer si la logique du script est en cause ou si l’environnement a été perturbé par une autre tâche à une étape donnée. Quand plusieurs tâches partagent le même processus et le même journal, les symptômes peuvent en plus varier, ce qui multiplie le coût du diagnostic.
Il existe aussi un risque moins visible : plusieurs identités utilisées longtemps dans le même environnement laissent des signaux de corrélation. Les paramètres de l’appareil, l’état du stockage et la sortie réseau sont identiques. Une plateforme peut donc facilement les interpréter comme des opérations en série depuis le même appareil. Si un compte est considéré comme anormal, d’autres peuvent être affectés à leur tour.
Ouvrir plusieurs fenêtres ne signifie pas isoler
La première réaction consiste souvent à ouvrir plusieurs fenêtres manuellement. Elles semblent séparées, mais elles partagent en réalité le même profil de navigateur : les mêmes cookies, le même stockage local et les mêmes informations sur l’appareil. Une fenêtre peut voir l’état de connexion d’une autre, et une action effectuée dans l’une peut perturber les autres.
Une véritable isolation doit porter sur le répertoire de données et les paramètres de l’environnement. Chaque environnement doit disposer de son propre répertoire de stockage, de ses propres paramètres d’appareil — résolution, langue, fuseau horaire, polices, Canvas, WebGL, etc. — ainsi que de sa propre sortie réseau. Si l’un de ces trois éléments manque, l’isolation reste incomplète. Même avec des environnements séparés, une sortie réseau partagée peut toujours déclencher des corrélations.
Le coût de l’isolation et ce qu’elle apporte
L’isolation n’est pas gratuite. Chaque environnement repose sur un processus de navigateur indépendant et un répertoire de données distinct. À mesure que leur nombre augmente, la mémoire et le CPU sont les premiers à subir la pression. Pour faire tourner des dizaines d’environnements sur une seule machine, mieux vaut calculer la marge disponible à l’avance plutôt que d’attendre un plantage.
Plusieurs compromis sont possibles : recycler les environnements rarement utilisés et les relancer à la demande ; répartir les tâches selon leur charge sur plusieurs machines au lieu de tout concentrer sur une seule ; et définir un cycle de vie clair pour les environnements afin d’éviter d’en laisser des centaines actifs en permanence. La structure des tâches compte aussi. Des tâches séquentielles liées au même compte n’ont pas besoin d’environnements séparés ; les scinder ne ferait que gaspiller des ressources.
En contrepartie, les bénéfices sont importants. Lorsque l’isolation est correctement mise en place, les échecs deviennent stables et attribuables : le problème vient de cet environnement précis, et non d’un phénomène inexplicable. À grande échelle, cette prévisibilité vaut bien plus que les quelques ressources économisées en partageant les environnements.
Trois fonctions qui doivent passer au niveau de l’environnement à grande échelle
La première est l’ordonnancement par lots. Les environnements doivent pouvoir être demandés et libérés comme des ressources de calcul, avec création à la demande, démarrage en lot, contrôle de la concurrence, reprise après échec et recyclage automatique, plutôt que d’être créés et fermés un par un dans les scripts.
La deuxième est une sortie réseau indépendante. Chaque environnement doit être lié à sa propre sortie, dont la région doit rester cohérente avec ses paramètres géographiques. Ce point est facile à négliger, mais il constitue une condition préalable à une isolation complète.
La troisième est un état interrogeable. Il faut pouvoir savoir à tout moment quels environnements sont en cours d’exécution, lesquels sont disponibles et lesquels présentent une anomalie. Les Agents fonctionnent sans surveillance ; si l’état n’est pas consultable, le dépannage se réduit à des suppositions.
Ces trois fonctions sont difficiles à gérer proprement dans des scripts. Elles nécessitent du stockage, de la configuration et de l’ordonnancement au niveau de l’environnement. Certains outils de gestion multienvironnement se placent précisément à ce niveau. PurpleMark en fait partie et transforme les environnements de navigateur en ressources isolables, planifiables par lots et appelables via des interfaces.
Quand plusieurs environnements ne sont pas nécessaires
Si un Agent n’utilise qu’un seul compte et s’exécute rarement, un navigateur classique suffit réellement, et l’isolation supplémentaire ne fait qu’ajouter de la maintenance. Mais dès qu’une des situations suivantes apparaît, il devient pertinent de séparer la couche d’environnement : exécution parallèle des tâches, accès à la même plateforme avec plusieurs identités, maintien prolongé des sessions ou croissance continue de la concurrence.
Toutes ces situations ont un point commun : la question n’est pas de savoir si l’Agent est assez intelligent, mais si l’environnement sous-jacent est suffisamment propre et isolé.
Limites
Quel que soit le choix d’architecture, les règles de fond restent les mêmes : respecter les conditions d’utilisation et les règles robots de chaque plateforme, ne pas utiliser de fausses informations d’identité, ne pas contourner les mesures techniques de protection, contrôler la fréquence des requêtes et ne pas perturber le fonctionnement normal des services tiers.
