Ce qu'un agent ne peut pas deviner

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

Cette affirmation est vraie. Elle est aussi compatible avec un serveur qui n’a rien reçu, un formulaire rejeté, une session expirée, et une page qui n’était pas la bonne depuis le début.

Percevoir, ce n’est pas seulement voir la page. C’est savoir où la vue s’arrête.

L’écart entre « ça s’est exécuté » et « ça a marché »

Trois cas réels, tous terminés par un succès :

Le navigateur a refusé l’envoi. Un champ required était vide. La validation HTML5 l’a bloqué et a affiché une petite bulle native. Le clic a eu lieu — Diwall a raison — et rien n’est parti.

Le clic était synthétique. Un .click() JavaScript sur un bouton d’envoi déclenche l’événement DOM sans garantir l’envoi HTTP. Une mise à jour de thème dans un système de gestion de contenu s’est terminée au vert, sans qu’aucun thème soit mis à jour.

L’élément n’était pas celui de l’image. Les numéros bougent avec le document ; quelque chose s’est ouvert ou fermé entre la capture et l’action. Le clic a porté, sur un autre élément.

Dans les trois cas, l’agent n’avait aucun moyen de le savoir d’après sa propre sortie. C’est tout le propos de cette page.

Le temps est invisible

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 tait et la navigation se termine. L’agent en conclut que la session est établie et ouvre une page protégée — pour retomber sur l’écran de connexion.

Le serveur n’avait pas fini. 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 ne distingue, ni visuellement ni dans la structure, « silencieux parce que fini » de « silencieux parce qu’entre deux états ».

{"type": "cliquer_som", "id": 2},
{"type": "pause", "ms": 2000},
{"type": "naviguer", "url": "https://target.local/protected"}

Deux secondes d’attente voulue, parce que le silence du réseau n’est pas la disponibilité. Rien dans la page ne le dit.

Ce que Diwall y fait

Il ne peut pas combler l’écart — aucun outil ne le peut, depuis l’intérieur du navigateur. Ce qu’il peut faire, c’est empêcher l’agent de raisonner comme si l’écart n’existait pas.

Donner le compte, pas seulement la liste. som_hors_viewport dit combien d’éléments interactifs la capture a manqués.

Dire où l’on est vraiment. La boussole porte l’URL courante après redirections, le titre de la page, le dernier code HTTP. Un agent qui se croyait ailleurs s’en aperçoit.

Signaler la dérive. session_derive dit que la session ne tient plus. Et dernier_code_http départage les deux échecs qui se ressemblent : une vraie expiration redirige avec un 302, une erreur applicative masquée derrière display_errors=0 renvoie un 500 et la même page de connexion.

Signaler le recours à la force. repli_js_utilise n’apparaît que lorsqu’un repli a réellement eu lieu, jamais parce que l’option était posée.

Rien de tout cela n’est une garantie. Ce sont des signaux qui transforment une supposition fausse et silencieuse en une supposition lisible.

L’habitude à en tirer

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.

Ce qui vous dit si le travail a été fait, c’est tout ce qui l’entoure : où vous êtes, ce qu’a répondu le serveur, ce que la capture n’a pas pu voir, si quelque chose a dû être forcé. Un agent qui ne regarde que le verdict se trompera avec assurance, précisément dans les cas qui comptent.

En bref

• Le succès mécanique et l’effet réel sont deux affirmations différentes.
• Un réseau silencieux ne veut pas dire un serveur prêt.
• Les signaux existent — boussole, code HTTP, dérive, compte hors écran — et ils valent plus que le verdict.
• Savoir où s’arrête la perception fait partie de percevoir.