Pourquoi une capture d'écran ne suffit pas
Une image est plate, et elle ne dit rien de ce qu’elle tait. Quatre choses qu’une page contient et qu’aucune capture ne vous montrera jamais — et ce qui arrive quand un agent suppose le contraire.
Donner une capture d’écran à un modèle donne l’impression de lui donner des yeux. C’est plutôt tendre à quelqu’un la photo d’une pièce et lui demander d’ouvrir le troisième tiroir.
L’image est exacte. Elle est aussi plate, muette sur ses propres limites, et elle omet quatre choses qui décident si une action va marcher.
Un — ce qui est sous la ligne de flottaison
Une capture cadre une fenêtre, pas un document. Sur l’index des recettes de ce site, dans la fenêtre par défaut de 1280 × 720, Set-of-Mark numérote les 16 éléments interactifs visibles et en signale 27 autres hors de la fenêtre (mesuré le 26 septembre 2026) :
"boussole": {"som_hors_viewport": 27}
Diwall le dit au lieu de vous le laisser découvrir. Sans ce compte, un agent qui regarde l’image conclut que la page contient seize éléments — elle en contient quarante-trois, et l’agent se trompe sur la page, avec assurance.
Le remède est de faire défiler avant d’agir, mais l’essentiel est en amont : l’image ne sait pas ce qui lui manque. Le JSON, si.
Deux — ce qui est dans la page mais pas à l’écran
Un <dialog> qui n’a pas été ouvert existe dans le document. Ses boutons sont
réels, désignables, et invisibles. Un menu replié contient ses liens. Un
panneau d’onglet contient son contenu.
Rien de tout cela n’apparaît sur la capture, et tout est à un clic d’apparaître. Un agent qui raisonne à partir de l’image seule croit que ces éléments n’existent pas ; un agent qui raisonne à partir du document brut croit qu’ils sont disponibles tout de suite. Les deux se trompent, en sens inverse.
Ce qui décide, c’est que l’élément soit rendu, pas qu’il soit présent. Cette distinction n’a aucune forme visuelle.
Trois — ce qu’est un élément, et où il mène
Sur une capture, un lien et un bouton stylés à l’identique sont identiques. De même un contrôle désactivé et un contrôle actif, quand le concepteur a choisi un gris discret.
La page, elle, fait la différence. link "Dashboard" /url: "#a" dit le rôle
et la destination — avant tout clic. option "production" [selected] dit
quel choix est actif. Aucun examen des pixels ne permet de retrouver cela.
Quatre — si la page est toujours la même
Une capture est un instant. Entre le moment où elle est prise et celui où une action s’exécute, un bandeau peut se fermer, une fenêtre modale s’ouvrir, une liste gagner quatre lignes. Tout ce qui était repéré par sa position dans l’image a bougé, sans bruit.
Ce n’est pas une hypothèse : c’est la façon la plus courante dont un clic automatisé tombe sur le mauvais élément tout en annonçant un succès. Une capture n’a aucun moyen de vous prévenir, parce qu’une capture n’a aucune notion de l’après.
Alors, à quoi sert la capture ?
À vous.
L’image est ce qu’une personne peut vérifier d’un coup d’œil — la mise en page, le bandeau d’erreur, le bouton gris qui devrait être bleu. C’est elle qui rend un compte rendu vérifiable, et pas seulement crédible.
Le modèle a besoin des numéros et de l’arbre ; vous avez besoin de l’image. Diwall renvoie les deux dans le même appel parce qu’ils répondent à des questions différentes, et qu’aucun ne remplace l’autre.
En bref
- Une capture cadre une fenêtre ;
som_hors_viewportvous dit ce qu’elle a coupé. - Présent dans le document ne veut pas dire rendu à l’écran.
- Les rôles, les destinations et les états n’ont aucune forme visuelle.
- Une image n’a aucune notion de l’après — les positions glissent, sans bruit.
- L’image est pour l’humain. La structure est pour le modèle.