L’Agent décide et Playwright agit dans le navigateur, mais la couche d’environnement est souvent négligée. Sur les tâches de collecte de longue durée, les défaillances se concentrent fréquemment à ce niveau.
Lorsqu’un framework d’agents pilote un navigateur pour collecter des données, l’architecture comporte généralement trois couches : l’Agent planifie et prend les décisions, Playwright gère les clics, les saisies et l’extraction, puis le flux interagit avec le site cible. Les tâches courtes fonctionnent souvent sans difficulté et passent les tests locaux. Mais dès que l’exécution se prolonge et que les tâches se multiplient, les défaillances commencent à se concentrer dans une zone rarement traitée avec assez d’attention : l’environnement du navigateur.
En revenant sur les problèmes rencontrés en pratique, les incidents de la couche d’environnement prennent généralement trois formes.
L’environnement est jugé anormal et toute la chaîne s’arrête
Premier cas : la plateforme agit directement sur l’environnement. Cela ne prend pas toujours la forme d’un blocage franc, mais plutôt d’une dégradation : pages simplifiées, résultats vides ou demandes de vérification. Le script ne lève pas d’erreur, pourtant les données renvoyées n’ont plus de valeur. Les étapes en aval continuent normalement et l’erreur se propage jusqu’au tableau final.
La difficulté vient du fait que ces environnements sont souvent partagés par plusieurs tâches. Si un environnement pose problème, toutes les tâches qui lui sont rattachées peuvent s’arrêter. Les nouvelles tentatives n’y changent rien, car la cause n’est pas dans le script.
Plusieurs tâches partagent un environnement et leurs sessions se mélangent
Lorsque plusieurs tâches s’exécutent en parallèle dans une même instance de navigateur, Cookie, localStorage et IndexedDB peuvent s’écraser mutuellement et faire disparaître des états de connexion. Le problème est peu visible à court terme, mais après quelques jours apparaissent des demandes de reconnexion difficiles à expliquer.
Il existe aussi une dérive plus discrète. Dans un navigateur qui fonctionne longtemps, le cache, le stockage et même l’état de rendu WebGL évoluent progressivement. Un même environnement peut présenter aujourd’hui des caractéristiques différentes de celles qu’il aura trois jours plus tard. Beaucoup pensent d’abord à une Cookie expirée, alors que c’est l’environnement lui-même qui a changé. C’est pourquoi il est souvent plus rentable de traiter les environnements comme des objets persistants et réutilisables que de relancer un nouveau navigateur à chaque fois.
Lors d’une reprise, l’environnement d’origine peut ne plus être exploitable
Les tâches de collecte se terminent rarement en une seule exécution. Reprendre depuis un point de contrôle après une interruption est courant, mais c’est aussi un moment où l’on peut facilement perdre du travail : au redémarrage du script, une nouvelle instance de navigateur peut être créée et l’état de connexion disparaît ; ou l’ancien environnement est conservé alors que la plateforme l’a déjà signalé, si bien que poursuivre ne fait que consommer des ressources.
Le point essentiel n’est donc pas le nombre de nouvelles tentatives, mais la granularité de la reprise. Si l’étape atteinte, les données déjà collectées et l’environnement utilisé ne sont pas enregistrés en dehors du script, un redémarrage oblige à repartir de zéro.
Que faire au niveau de l’environnement
Ces trois problèmes conduisent à trois principes.
Regrouper les environnements par tâche. Chaque tâche doit disposer de son propre groupe d’environnements au lieu de partager une instance avec plusieurs autres tâches. Une fois les groupes séparés, chaque tâche peut avoir sa propre sortie réseau, son fuseau horaire et sa langue. Il est plus fiable de conserver ces paramètres comme un ensemble cohérent que de les régler manuellement un par un. Dans cette architecture, PurpleMark se situe au niveau de l’environnement : il crée des environnements de navigateur par lots, associe à chacun une sortie réseau indépendante et les fournit via API à la couche d’orchestration pour la planification.
Isoler les défaillances. Lorsqu’un environnement est jugé anormal, seules les tâches qui y sont rattachées doivent être affectées. En pratique, on conserve généralement un état de santé pour chaque environnement, on le vérifie régulièrement et on retire les environnements défaillants au profit d’environnements de secours, au lieu de laisser les scripts de niveau supérieur réessayer sans cesse le même environnement défectueux. Cela facilite aussi le diagnostic : le problème vient-il de l’environnement ou d’un changement de structure de la page ?
Rendre l’état récupérable. La progression, les empreintes de déduplication et les identifiants d’environnement doivent être stockés de manière persistante en dehors du script. Au redémarrage, on lit d’abord ces informations, puis on décide d’où reprendre et quel environnement utiliser. En séparant la tâche en phases de découverte, chargement et extraction, on peut gérer les erreurs par étape sans perdre tout un cycle à cause d’un incident isolé. Il faut aussi surveiller les ressources : les instances de longue durée peuvent subir des fuites mémoire, des pages bloquées ou des délais de connexion dépassés, d’où la nécessité de recycler régulièrement les sessions invalides.
Des limites à garder claires
La stabilité de l’environnement et l’autorisation de collecter sont deux questions distinctes. Il faut d’abord consulter les règles robots et les conditions d’utilisation du site cible, car de nombreux sites limitent explicitement l’accès automatisé ; la fréquence des requêtes doit rester assez faible pour ne pas perturber le service ; les informations personnelles ne doivent pas être collectées ; et face à des mesures de protection techniques, la bonne démarche consiste à adapter la stratégie ou à obtenir une autorisation, pas à chercher à les contourner. La stabilité technique ne remplace pas l’analyse de conformité.
Ce contenu est fourni uniquement à des fins de recherche technique et d’échange sur les pratiques de développement. Respectez les conditions du site cible et la réglementation applicable dans votre lieu d’activité.
