Ce qu'un agent ne peut pas deviner

Un agent qui pilote le cœur de navigation sait une chose avec certitude : si sa propre instruction s’est exécutée. Il a cliqué, le clic a eu lieu, succes: true.

Cela reste compatible avec un serveur qui n’a rien reçu, un formulaire refusé, une session expirée, ou une page qui n’était pas la bonne dès le départ.

Trois façons dont un succès n’est pas un résultat

Le navigateur a refusé d’envoyer le formulaire. Un champ required était vide, et la validation HTML5 a bloqué l’envoi. Le clic a eu lieu ; rien n’est parti.

Le clic était synthétique. Un .click() JavaScript sur un bouton d’envoi déclenche l’événement de clic sans garantir que le formulaire soit envoyé.

La page n’était pas celle attendue. Une redirection a mené ailleurs que ce que supposait le scénario, et le clic est tombé sur une page que personne ne voulait toucher.

Dans les trois cas, la sortie de l’agent ne suffit pas à le lui apprendre. Le formulaire qui ne part jamais →

Le temps ne se voit pas

Une page peut être entièrement chargée sans être encore prête.

Après l’envoi d’un formulaire de connexion, le réseau se calme et la navigation s’achève. L’agent en conclut que la session existe, se rend sur une page protégée, et retombe sur la page de connexion.

Beaucoup d’applications régénèrent l’identifiant de session juste après l’authentification : le navigateur a terminé, le serveur non, et rien dans la page ne distingue « calme parce que terminé » de « calme entre deux états ». Il n’y a aucun signal à attendre : c’est le seul cas où une pause fixe est le bon outil.

{"type": "cliquer", "selecteur": "button[type=\"submit\"]"},
{"type": "pause", "ms": 2000},
{"type": "naviguer", "url": "https://target.local/protected"}

Ce que fait Dinoer

Il ne peut pas combler l’écart : aucun outil ne le peut depuis l’intérieur du navigateur. Il renvoie des signaux qui rendent visible une supposition fausse.

Où vous êtes. boussole porte l’URL après redirections, le titre de la page et le dernier statut HTTP.

La dérive de session. Après --reprendre-session, boussole.session_derive apparaît quand la page d’arrivée diffère de celle où la session a été enregistrée. dernier_code_http sépare alors deux échecs qui se ressemblent : une vraie expiration redirige (302), une erreur de l’application renvoie 500 et la même page de connexion.

Le repli utilisé. repli_js_utilise n’apparaît que lorsqu’un clic de repli en JavaScript s’est réellement exécuté.

Aucun de ces signaux n’est une garantie. Chacun transforme une supposition fausse et silencieuse en quelque chose que vous pouvez lire.

L’habitude qui en découle

Lisez la réponse, pas le verdict. succes: true est le champ le moins informatif de la sortie : il dit que l’instruction s’est exécutée. Pour savoir si le travail a été fait, il faut lire tout le reste : où vous êtes, ce qu’a répondu le serveur, s’il a fallu forcer quoi que ce soit.

La chaîne de recherche suit la même règle : campagne.py lit le statut de chaque page qu’il récupère (visitee, refusee, insuffisante_legere et d’autres) et ne garde que les pages qu’il a pu lire.

En bref

• Une exécution qui a marché et un résultat obtenu sont deux affirmations différentes.
• Un réseau calme ne veut pas dire un serveur prêt.
• Les signaux existent (position, statut HTTP, dérive de session, repli utilisé) et ils en disent plus que le verdict.