Quand une automatisation par Agents se met à échouer à grande échelle, la cause se trouve souvent moins dans le modèle ou le script que dans la couche d’environnement du navigateur. Cet article présente quatre schémas de panne fréquents, leurs signes observables et les pratiques d’ingénierie adaptées.
Mettre en place un Agent avec LangChain, AutoGen ou CrewAI et lui faire piloter des sites web via Playwright ou Puppeteer n’est pas particulièrement difficile. Le vrai défi consiste à le faire fonctionner de manière continue.
Au début, les problèmes sont souvent peu visibles. Dès que le volume de tâches augmente, les anomalies se multiplient : des sites bloquent des tâches, les sessions de comptes expirent soudainement ou plusieurs Agents se gênent lorsqu’ils s’exécutent en parallèle. Le premier réflexe est souvent de relire le code, pour finir par constater que le code n’a rien d’anormal.
La cause se situe fréquemment dans la couche d’environnement du navigateur. Dans les projets fortement sollicités, les pannes prennent en réalité quelques formes récurrentes. Une fois ces formes reconnues, leur traitement n’est pas particulièrement complexe.
Démarrer avant que l’environnement soit prêt
Lorsqu’un environnement de navigateur tout juste créé est utilisé immédiatement pour une tâche, on observe souvent un échec de connexion, des éléments de page qui ne se chargent pas complètement ou une vérification dès la première étape. La raison est simple : cet environnement n’a aucun historique de visite, aucun cookie et aucune trace de navigation. Pour la plateforme, il ressemble à un appareil totalement inconnu, donc peu digne de confiance.
Le signe observable est une concentration des échecs sur les premières tâches après la création de l’environnement. Déplacer la même tâche vers un environnement utilisé depuis un certain temps suffit souvent à la faire aboutir normalement.
La bonne approche consiste à faire de la disponibilité de l’environnement un état explicite, au lieu de supposer qu’il est utilisable par défaut. Après sa création, on peut lui faire effectuer une période de navigation de faible intensité et ne lui confier des tâches réelles qu’une fois son état stabilisé. L’ordonnanceur doit vérifier cette étape avant d’affecter une tâche, plutôt que d’utiliser immédiatement l’environnement.
Plusieurs tâches se disputent le même environnement
Quand la concurrence augmente, le symptôme le plus visible est l’accumulation des processus, la saturation de la mémoire et le ralentissement du système. Plus difficiles à repérer sont les erreurs cachées : deux tâches utilisent successivement les mêmes cookies et le même stockage local, l’état de connexion de A remplace celui de B, et les journaux donnent l’impression qu’une tâche quelconque échoue de temps en temps. Le diagnostic devient alors délicat.
Il faut ici traiter les environnements de navigateur comme des ressources que l’on peut réserver puis libérer. Une tâche réserve un environnement au démarrage et le restitue à la fin, avec une relation un-à-un entre tâche et environnement. Le stockage d’un environnement reste invisible aux autres, de sorte que l’état de connexion d’une tâche ne se propage pas à une autre. Avec plusieurs dizaines d’Agents exécutés en parallèle, la différence avec le fait de « lancer simplement de nombreux processus de navigateur dans le script » devient très nette.
Si le scénario implique plusieurs comptes, l’isolation doit être encore plus stricte : chaque compte doit conserver un environnement fixe, sans chevauchement des paramètres d’empreinte ni du stockage avec les autres comptes. PurpleMark fournit précisément cette couche d’isolation des environnements et d’ordonnancement centralisé afin de maintenir une correspondance stable un-à-un entre comptes et environnements.
L’expiration de session passe inaperçue
Ce type de panne est facile à manquer, car aucune erreur n’est forcément déclenchée. La tâche continue, les journaux défilent, mais la réponse réelle est une page de connexion ou des données vides. Le problème n’est découvert qu’une fois le résultat entré dans le pipeline de données, ce qui oblige à remonter depuis l’aval et rend l’investigation coûteuse.
La solution consiste à traiter l’état de connexion comme une condition préalable explicite. Avant chaque tâche, il faut vérifier que la session courante est toujours valide. Si elle a expiré, on exécute un processus de connexion complet au lieu de laisser la tâche continuer avec un état invalide. L’état lui-même doit résider dans la couche d’environnement : cookies, stockage local et historique de navigation y sont conservés et peuvent être restaurés intégralement au redémarrage, ce qui évite de réinitialiser chaque tâche de compte.
Un retour d’expérience utile : pour les comptes utilisés sur la durée, des changements fréquents d’état de connexion peuvent eux-mêmes être considérés comme un signal anormal par la plateforme et déclencher des vérifications supplémentaires. Il vaut mieux éviter les reconnexions inutiles.
Un blocage immobilise tout le lot
Un autre type de panne apparaît soudainement par lots : de nombreuses tâches cessent de fournir un résultat au même moment. Le site ne renvoie pas nécessairement un refus explicite ; il est plus fréquent d’obtenir un contenu dégradé ou une page vide, puis de voir l’Agent poursuivre avec des données sans valeur jusqu’à ce que le problème se révèle au niveau du traitement des données.
Dans ce cas, la première étape est de distinguer le blocage d’une panne ordinaire. Si le même groupe d’environnements devient anormal à peu près au même moment, il est très probable que le problème se trouve dans la couche d’environnement. Continuer à relancer les tâches ne ferait qu’étendre l’impact ; il faut d’abord arrêter et isoler les environnements concernés, puis rechercher le déclencheur.
Les déclencheurs courants se répartissent en trois catégories : plusieurs environnements utilisent des configurations d’empreinte très proches, par exemple des paramètres WebGL, Canvas, listes de polices ou versions de moteur presque identiques ; l’IP de sortie, le fuseau horaire et la langue ne correspondent pas, par exemple une IP américaine avec un fuseau asiatique ; ou les intervalles entre actions sont si réguliers que le rythme lui-même devient un signal. Il faut harmoniser la configuration, maîtriser le rythme et journaliser à la fois l’état de l’environnement et les résultats des tâches afin de repérer les signes avant-coureurs avant une panne généralisée.
Isoler cette couche
Les projets matures séparent généralement l’environnement du navigateur de l’Agent et en font une couche indépendante : l’Agent gère la planification et la décision, la couche d’environnement gère l’identité et l’état, et la couche d’exécution reste Playwright ou Puppeteer. Une fois cette séparation faite, il existe un endroit clair pour gérer la crédibilité de l’identité, la restauration de l’état et l’isolation entre tâches.
En prenant du recul, les quatre types de panne précédents ont un point commun : ils ne se trouvent ni dans le modèle ni dans la logique du script. Le modèle et le code doivent bien sûr continuer à s’améliorer, mais la capacité de l’automatisation à fonctionner durablement se joue souvent dans cette couche plus basse.
Ce contenu est partagé à des fins de recherche technique et de retour d’expérience en développement. L’automatisation doit être utilisée dans un cadre légal et conforme, en respectant les conditions d’utilisation de la plateforme cible ainsi que les lois et réglementations locales applicables.
