Localiser l’élément, attendre qu’il soit interactif, déclencher l’action et vérifier le résultat : toute action automatisée suit ces quatre étapes. Comprendre les sélecteurs, le chargement dynamique, les iframes et le shadow DOM permet de créer des scripts plus durables.
L’automatisation web est souvent résumée à un programme qui clique sur des boutons à votre place. En pratique, on découvre qu’une action comporte quatre étapes et que, si l’une d’elles est mal exécutée, tout peut donner l’impression que rien ne s’est passé.
Commençons par distinguer deux notions faciles à confondre. L’automatisation web est la catégorie la plus large : elle couvre l’usage d’un programme pour accomplir ce qu’une personne ferait normalement sur une page web, y compris récupérer directement des données par requête. L’automatisation du navigateur est une branche plus précise : le programme contrôle un vrai navigateur, ouvre des pages, exécute du JavaScript et simule des clics et des saisies. Lorsque le contenu est très dynamique ou les interactions complexes, cette seconde approche est généralement nécessaire.
Les quatre étapes d’une action
- Localiser l’élément : Identifiez la cible avec id, name, class, un sélecteur CSS ou XPath. Privilégiez les attributs sémantiques et ne revenez à la structure ou à l’index qu’en dernier recours.
- Attendre qu’il soit interactif : La présence d’un élément dans le DOM ne signifie pas qu’il est déjà cliquable. Attendez qu’il soit visible, cliquable ou qu’une requête précise ait répondu. On attend une condition, pas un nombre de secondes.
- Déclencher l’action : Cliquer, saisir ou faire défiler. Les composants personnalisés exigent souvent de reproduire l’ordre suivi par une personne : ouvrir d’abord le composant, attendre le rendu de la liste, puis sélectionner par texte.
- Vérifier le résultat : Après l’action, confirmez que le résultat est correct. Vérifiez si le lien a changé, si le texte de la page a changé ou ce que l’API a renvoyé. Sans cette étape, un échec peut être pris pour un succès, ce qui rend les nouvelles tentatives et les alertes peu fiables.
Parmi ces quatre étapes, la deuxième et la quatrième demandent généralement le plus de temps de débogage. Non pas parce qu’elles sont difficiles, mais parce qu’elles échouent souvent sans erreur visible et produisent silencieusement un résultat incorrect.
La stabilité du sélecteur détermine la durée de vie du script
Dès que la page change, un repérage codé en dur peut cesser de fonctionner. Se baser sur le texte, la position ou l’index résiste mal aux changements : un bouton ajouté ou un message modifié peut suffire à tout décaler.
Utilisez en priorité les attributs id, name ou data lorsqu’ils sont disponibles. Si vous devez recourir à des repérages structurels, centralisez-les afin qu’une modification ne soit nécessaire qu’à un seul endroit, et non dans des dizaines de lignes. N’imaginez pas non plus qu’un script terminé ne demandera plus d’entretien : les sites évoluent régulièrement, et une grande partie du coût de maintenance se concentre ici.
Chargement dynamique : ce que vous attendez compte plus que la durée
Peu de pages sont aujourd’hui entièrement prêtes dès la fin du chargement initial. Les données sont rendues via des requêtes asynchrones, et les éléments apparaissent souvent plus tard que prévu.
Les attentes fixes sont courantes, mais aussi fragiles : attendre 3 secondes peut être insuffisant sur une machine lente et inutilement long sur une machine rapide. Il vaut mieux attendre qu’une condition soit remplie et n’agir que lorsque l’élément est réellement cliquable.
Si un élément reste introuvable, vérifiez d’abord iframe et shadow DOM
Lorsqu’un élément est clairement visible sur la page mais que le script ne le trouve pas, le problème vient souvent moins du sélecteur que de la portée.
Un iframe est un document indépendant. Il faut d’abord basculer dans le frame concerné pour rechercher l’élément, puis en ressortir après l’opération, sinon les recherches suivantes auront lieu dans le mauvais contexte. Les nœuds d’un shadow DOM ne sont pas directement accessibles par des sélecteurs CSS depuis l’extérieur ; il faut d’abord obtenir le shadow root, puis chercher à l’intérieur. Ces deux situations sont souvent prises à tort pour une refonte de la page et font perdre beaucoup de temps.
Deux autres points faciles à oublier
Le premier est la session. Pour les tâches nécessitant une connexion, il faut prévoir comment conserver et réutiliser l’état authentifié. Sinon, chaque exécution impose une nouvelle connexion et peut se bloquer sur une étape de vérification.
Le second est l’environnement. Si toutes les tâches partagent le même environnement de navigateur, les sessions et les caches peuvent se polluer mutuellement. Des tâches qui fonctionnent bien séparément peuvent commencer à se gêner lorsqu’elles tournent ensemble. Quand on passe d’une tâche à plusieurs, isoler les environnements dans une couche dédiée évite beaucoup de problèmes. Des outils comme PurpleMark fournissent un fingerprint indépendant et un proxy indépendant pour chaque environnement, tandis que le framework d’automatisation se concentre sur l’exécution des actions.
Une limite doit être confirmée avant de commencer
L’automatisation peut remplacer des opérations répétitives, mais pas les étapes qui exigent une personne réelle. Si le processus cible comprend une vérification faciale en temps réel ou une validation manuelle, il ne pourra pas être automatisé à 100 %.
Commencez donc par la méthode de validation la plus simple : parcourez manuellement l’ensemble du processus, notez chaque étape et vérifiez s’il existe un point impossible à franchir. Décidez seulement ensuite de l’effort de développement à investir. La faisabilité technique et ce que les règles autorisent sont aussi deux sujets différents ; consultez donc à l’avance les conditions d’utilisation de la plateforme cible.
