Dans les tâches web d’un Agent, les échecs proviennent souvent de quatre zones : localisation des éléments, attentes et délais d’expiration, persistance de l’état et blocages liés à l’environnement. Des étapes idempotentes, des reprises ciblées, un état persistant et des environnements isolés par tâche stabilisent nettement le taux de réussite.
Quand on débute dans l’automatisation web, l’approche paraît souvent simple : définir le flux puis lancer le script. La logique semble correcte, pourtant les tâches échouent de façon sporadique et l’état des comptes devient parfois anormal. Le premier réflexe est d’examiner le code, mais une analyse plus poussée ramène généralement les problèmes à quatre zones.
Une modification de la page casse la localisation
La plupart des scripts repèrent les éléments à l’aide de sélecteurs. Dès qu’un sélecteur est codé en dur, presque toute modification de la page peut le rendre invalide : un bouton change de classe, un mot du texte est modifié, une section passe du rendu côté serveur au chargement asynchrone ou un élément est enveloppé dans un nouveau conteneur. Lors d’un test A/B, une même page peut même présenter des structures différentes selon les comptes.
Les symptômes habituels sont un élément introuvable, un clic au mauvais endroit ou l’activation d’un contrôle portant le même nom mais placé ailleurs. Ce type d’échec n’est pas dû à une fluctuation du réseau et plusieurs tentatives ne le corrigeront pas.
Une approche pratique consiste à moins dépendre des chemins absolus. Il vaut mieux privilégier les attributs d’accessibilité, des ID métier stables ou les relations relatives entre éléments, et prévoir des sélecteurs de repli pour un même type de page afin de basculer automatiquement si le sélecteur principal échoue. Si la page contient un iframe ou un Shadow DOM, il faut d’abord passer dans le bon contexte, sinon la localisation échouera.
Les attentes et les timeouts sont mal dimensionnés
Si l’attente est trop courte, un élément peut être déclaré en échec avant la fin de son rendu, ce qui ressemble à un bug du script. Si elle est trop longue, la durée d’une seule tâche s’allonge inutilement, le débit baisse et les timeouts peuvent masquer l’erreur réelle.
Les attentes explicites sont plus fiables qu’un sleep fixe : on attend une condition précise, par exemple l’apparition de l’élément cible, le retour d’une requête ou la disparition d’une animation de chargement. Les budgets de timeout doivent être définis par niveaux, avec des limites propres à une étape, à une page et à l’ensemble de la tâche, puis resserrés progressivement au lieu d’utiliser la même valeur partout.
Il faut aussi distinguer l’attente jusqu’à ce que la page soit utilisable de l’attente jusqu’à la production du résultat métier. Pour la première, attendre que le DOM soit prêt suffit souvent ; pour la seconde, il faut parfois attendre un callback d’API ou un changement du texte d’état dans la page. Attendre le mauvais signal peut donner l’impression que l’opération a réussi alors que les données n’ont pas été écrites.
La progression se perd au milieu d’une tâche en plusieurs étapes
Des tâches comme l’inscription, la commande ou la publication dépassent facilement une dizaine d’étapes. Si le processus s’arrête en cours de route à cause d’un timeout, d’un plantage du navigateur ou d’un redémarrage de l’hôte, et que l’état n’existe qu’en mémoire, l’exécution suivante doit soit repartir de zéro, soit renvoyer l’étape précédente.
Une exécution en double peut être plus difficile à diagnostiquer qu’un simple échec : la même opération est lancée deux fois, le système en amont reçoit un enregistrement supplémentaire et son origine devient difficile à retrouver.
La solution consiste à donner à chaque étape un point de persistance. Après chaque étape terminée, on écrit la progression dans un stockage durable avec l’identifiant unique de la tâche ; après un redémarrage, on reprend au dernier point réussi. Aucun framework complexe n’est nécessaire : un fichier ou un enregistrement d’état suffit.
Un blocage côté environnement ressemble à une erreur de code
Les trois premières catégories se situent dans la tâche, mais une autre vient de l’environnement. Un site peut combiner les caractéristiques du navigateur, le comportement d’accès et l’origine réseau pour évaluer la provenance du trafic. S’il le juge suspect, il peut renvoyer une page de vérification, du contenu vide ou simplement expirer. Dans les journaux de tâche, cela ressemble presque à une erreur d’exécution.
Parmi les déclencheurs courants :
- La localisation de l’IP de sortie, le fuseau horaire et la langue ne correspondent pas
- Toutes les tâches émettent leurs requêtes depuis le même environnement de navigateur, avec une densité de requêtes par unité de temps nettement supérieure à celle de vrais utilisateurs
- L’environnement change fréquemment ou le compte se reconnecte de manière répétée
Quatre mesures pour augmenter le taux de réussite
- Rendre chaque étape idempotente. Avant l’exécution, vérifier si la condition préalable est déjà satisfaite afin qu’une répétition n’entraîne pas d’effet secondaire supplémentaire. Les lectures sont naturellement idempotentes ; les écritures doivent être protégées par un identifiant unique ou une clé de déduplication.
- Classer les échecs. Les échecs temporaires, comme un élément pas encore rendu, une fluctuation réseau ou une API qui renvoie 5xx, peuvent être retentés avec backoff. Les échecs déterministes, comme un compte restreint, des paramètres invalides ou une ressource cible inexistante, ne s’amélioreront pas avec davantage de tentatives : il faut les arrêter au lieu de leur laisser occuper la capacité de concurrence.
- Persister régulièrement l’état. Enregistrer la progression, les artefacts intermédiaires et l’étape en cours permet à la tâche de reprendre après un redémarrage au lieu de repartir de la première étape.
- Isoler l’environnement d’exécution par tâche. Chaque compte ou tâche dispose de son propre environnement de navigateur ; les Cookies et le stockage local ne sont pas partagés, les caractéristiques de fingerprint varient de manière raisonnable, et le fuseau horaire ainsi que la langue restent cohérents avec la région de l’IP de sortie.
La quatrième mesure devient particulièrement importante à mesure que le volume de tâches augmente. Lorsque des dizaines ou des centaines de tâches s’exécutent en parallèle, la couche d’environnement fixe la limite supérieure de stabilité et détermine aussi l’étendue des impacts en cas de problème. Dans ce type de scénario, PurpleMark permet de créer à la demande des environnements isolés et de les récupérer par lots, avec un environnement propre à chaque compte afin que les états des tâches ne se contaminent pas entre eux.
Ce contenu est fourni uniquement à des fins de recherche technique et de partage de pratiques de développement. Utilisez les technologies concernées dans un cadre légal et conforme, et respectez les conditions d’utilisation de la plateforme cible.
