L’automatisation du navigateur a traversé trois générations. Chacune a résolu le principal blocage de la précédente tout en déplaçant le suivant. Comprendre les limites laissées par chaque génération est plus utile que mémoriser des noms d’outils.
L’automatisation du navigateur existe depuis plus de vingt ans et a changé trois fois de trajectoire. Ce qui est intéressant, c’est que chaque génération résout une catégorie de problèmes différente et qu’une fois ceux-ci résolus, le goulot d’étranglement se déplace ailleurs.
Première génération : simuler une personne qui déplace la souris au niveau du système d’exploitation
Les premières formes d’automatisation ne fonctionnaient pas réellement dans le navigateur, mais au niveau du système d’exploitation. Le script déplaçait la souris et appuyait sur les touches, tandis que le navigateur se contentait de recevoir ces entrées.
L’avantage était la polyvalence : tout ce qui apparaissait à l’écran pouvait être manipulé, qu’il s’agisse d’une page web, d’une application cliente ou d’un ancien logiciel de bureau, sans exiger la moindre interface du navigateur. Le coût était tout aussi évident. Le script se repérait par coordonnées d’écran : un changement de résolution, de mise à l’échelle du système ou de position de la fenêtre suffisait à décaler les clics. Il ne savait pas non plus si la page avait fini de charger et devait donc s’appuyer sur des attentes fixes. Le parallélisme était encore plus contraignant : une machine n’a qu’une souris et un clavier, donc dix environnements exigeaient dix machines.
Le problème laissé par cette génération était simple : elle ne voyait pas la page.
Deuxième génération : contourner l’écran et dialoguer directement avec le navigateur
L’arrivée de WebDriver a fait passer l’automatisation du niveau des pixels à celui des éléments : on cherchait un élément précis de la page plutôt que la position correspondant au 800e pixel de l’écran. Le même code pouvait piloter différents navigateurs et être écrit dans plusieurs langages, ce qui explique aussi pourquoi cette approche est devenue une norme dans le domaine des tests.
Ensuite, les solutions basées sur les protocoles de débogage des navigateurs ont poussé cette voie beaucoup plus loin. La famille Puppeteer/Playwright communique directement avec le moteur et accède à l’état interne de la page : attente automatique de la disponibilité d’un élément, interception et réécriture des requêtes, connexion à une instance de navigateur déjà ouverte, exécution sans interface et ouverture parallèle de plusieurs contextes. La plupart des capacités aujourd’hui considérées comme normales ont été consolidées à cette étape.
Cette génération a résolu les problèmes de contrôle et de stabilité, mais en a laissé deux autres. D’abord, les scripts restaient écrits de manière rigide par des humains. Dès que la structure d’une page changeait ou qu’un sélecteur ne fonctionnait plus, il fallait modifier le code, avec un coût de maintenance qui augmentait avec la taille du projet. Ensuite, un problème plus fondamental demeurait : cette approche gère la manière d’agir, pas l’apparence de l’acteur. Une connexion directe par protocole rend le contrôle plus précis, mais changer de mode de communication ne fait pas disparaître les traces de l’automatisation. Même un script très stable peut toujours apparaître comme un script aux yeux d’un tiers.
Troisième génération : les étapes ne sont plus écrites à la main, et le problème se déplace encore
La troisième génération ne change pas le mode de contrôle, mais le mode de décision. Dans les deux premières, il fallait décrire chaque étape : quel bouton cliquer, quel champ remplir et dans quel ordre. Avec l’approche pilotée par modèle, on fournit un objectif, le modèle planifie lui-même le chemin et peut retrouver un point d’entrée si la page est remaniée.
Les difficultés autrefois fastidieuses, comme le choix des sélecteurs ou la durée d’attente, deviennent donc progressivement moins critiques. Mais de nouveaux problèmes apparaissent immédiatement.
Le point essentiel est que le modèle lui-même n’accède pas à la page web. C’est toujours le navigateur qui ouvre la page, charge les ressources et maintient l’état de connexion. Lorsqu’une tâche devient instable, la cause vient donc souvent moins d’une mauvaise décision du modèle que de l’environnement d’exécution sur lequel il repose : plusieurs tâches partagent un même navigateur et contaminent mutuellement cookies et cache ; les caractéristiques d’empreinte sont très similaires et la plateforme perçoit toutes ces tâches comme provenant de la même machine ; les comptes se mélangent entre les tâches et une anomalie peut en affecter plusieurs ; les environnements doivent être créés temporairement puis récupérés sans planification unifiée. Le modèle résout la question du comment et transforme la question du où en nouveau goulot d’étranglement.
La couche supplémentaire dans l’architecture
En regardant les trois générations ensemble, la différence ne consiste pas à déterminer laquelle est la plus avancée. Chacune doit prendre en charge ce que la précédente n’a pas résolu. Dans les deux premières, l’environnement n’était pas un problème majeur puisque l’on utilisait le navigateur de sa propre machine. À l’étape des Agents, les tâches deviennent nombreuses, concurrentes et sans surveillance ; l’environnement doit alors être géré explicitement : chaque tâche s’exécute dans un environnement isolé, sans mélange des empreintes ni des sessions ; l’état de connexion est conservé entre les tâches pour éviter de se reconnecter à chaque fois ; IP, fuseau horaire et langue sont associés de façon cohérente ; les environnements sont créés et récupérés à la demande comme des ressources de calcul.
PurpleMark intervient précisément à cette couche, en transformant les environnements de navigateur en ressources planifiables afin que l’Agent puisse se concentrer sur la logique de la tâche.
Le choix devient alors plus facile à situer. Les piles de tests d’entreprise et les scripts existants peuvent rester sur leur trajectoire actuelle ; les applications web complexes qui nécessitent un contrôle au niveau des requêtes relèvent de la génération pilotée par protocole ; pour les tâches planifiées par un modèle qui doivent aussi fonctionner de manière stable dans la durée, les technologies des deux premières générations restent utilisables, mais la couche d’environnement doit être traitée séparément. Si votre scénario doit donner l’impression qu’un véritable utilisateur agit, aucun framework d’automatisation ne peut fournir cela à lui seul, quelle que soit la génération.
Une autre limite existe au-delà de la technique : les opérations automatisées doivent respecter les règles de la plateforme cible et les lois locales. Ce qui est techniquement réalisable n’est pas nécessairement approprié sur le plan métier.
