Les heuristiques web

Le chapitre précédent reprend les heuristiques qui valent pour tout système. Celui-ci traite ce que le navigateur et le protocole ajoutent, que la Test Heuristics Cheat Sheet range en quatre familles sur sa première page¹.

Ce que le navigateur ajoute

Cette famille de défauts vient de l’architecture et non du code métier.

HTTP n’a pas de mémoire. Chaque requête arrive seule. Le serveur reconstruit la continuité que l’utilisateur perçoit à partir d’un identifiant de session, et rien n’oblige deux requêtes successives à se suivre dans l’ordre où l’application les attend². La norme distingue les méthodes sûres, qui ne modifient rien, et les méthodes idempotentes, dont la répétition produit le même effet qu’une seule exécution. Une application qui écrit sur une requête GET viole cette distinction, et le navigateur, qui la respecte, rejoue cette requête sans le demander.

Le client n’est pas maîtrisé. Le code envoyé à la page s’exécute dans un logiciel que l’utilisateur choisit, configure et modifie. Toute validation faite là est une commodité d’affichage. Elle se désactive, se contourne par un appel direct ou n’a jamais été chargée.

L’utilisateur dispose de commandes que le développeur n’a pas écrites. Retour, rechargement, signet, ouverture d’un second onglet, modification de l’URL. Aucune ne passe par la logique de navigation de l’application, et chacune peut réintroduire un état que l’application croyait dépassé.

Navigation

Le bouton Précédent reconstruit depuis le cache l’écran d’avant l’action, sans prévenir le serveur, dont l’état a changé. Si cet écran porte un formulaire déjà soumis, le rechargement le soumet une seconde fois. Le second onglet ajoute une variante: deux séquences de l’application partagent le même cookie de session, donc le même état serveur, et chacune écrase ce que l’autre y a posé.

L’URL est le second point d’entrée. Une page qui lit un identifiant dans l’URL et l’utilise sans vérifier que la session en cours a le droit de le lire donne accès au dossier d’un autre. Ce défaut ne se voit sur aucun écran, puisque l’écran affiche exactement ce qu’on lui a demandé.

On se déplace par les commandes du navigateur, jamais par celles de la page: historique, rechargement, signet posé puis rouvert après déconnexion, URL modifiée à la main, second onglet ouvert sur la même session. L’oracle est l’état du serveur après le déplacement, lu par un autre point de contact que l’écran: la base, le journal, l’API. Un écran d’apparence correcte après un retour n’est pas un verdict.

p.ex. sur un guichet fiscal cantonal, après la soumission définitive, le bouton Précédent réaffiche l’écran de confirmation. Reste à savoir si cet écran autorise un second envoi. Une déclaration déposée deux fois se répare à la main, dossier par dossier.

Preferences

Le lecteur configure son navigateur, et ces réglages précèdent l’application. Une taille de police agrandie change la hauteur de chaque bloc et fait déborder les mises en page calculées en pixels. Une fenêtre réduite déclenche des règles de style que personne n’a regardées. Le script désactivé retire toute validation faite chez le client, et avec elle les champs qui n’existaient que par le script. Les cookies refusés retirent la session. Un niveau de sécurité élevé bloque les ressources tierces dont la page dépend sans le déclarer.

L’agrandissement du texte est le premier moyen d’adaptation des lecteurs malvoyants, et les WCAG en font un critère mesurable: le contenu reste utilisable jusqu’à 200% d’agrandissement³.

On règle une préférence à la fois, puis on parcourt le chemin nominal complet: police au double, fenêtre réduite, script désactivé, cookies refusés, sécurité élevée. L’oracle est l’achèvement de la tâche, pas l’apparence de l’écran. Un formulaire dont le bouton est sorti du cadre visible reste affiché correctement et n’est plus utilisable.

p.ex. une prestation publique en ligne se consulte avec la police agrandie au double. Le formulaire reste utilisable ou non, et l’exigence d’accessibilité chiffre la réponse.

Input

Un champ de page web reçoit deux choses: ce que l’utilisateur tape et ce qu’un appel direct y met. La validation écrite dans la page ne protège que la première. L’attribut qui limite la longueur d’un champ est un confort de saisie, et la requête construite hors de la page l’ignore.

Le second mécanisme est l’interprétation. Une chaîne stockée puis réaffichée est réinterprétée par le navigateur à l’affichage. Si elle contient du balisage et que la sortie ne l’échappe pas, le navigateur exécute ce que l’utilisateur a écrit, avec les droits de la session qui lit la page. Le défaut se déclare chez un autre utilisateur, plus tard, ce qui le rend invisible au test de saisie.

On applique aux champs de la page les attaques par type de donnée du chapitre précédent, puis on y ajoute ce qui est propre au formulaire web: une balise et un script saisis dans un champ, une zone de texte remplie de plus de cinq mille caractères et la longueur maximale annoncée, vérifiée par un appel direct plutôt que crue. L’oracle du balisage est ce que reçoit l’écran de relecture, lu dans la source de la page: du texte échappé ou du balisage actif.

p.ex. le champ «remarques» d’un formulaire administratif reçoit ce que l’usager y colle, y compris un extrait de courriel avec sa mise en forme. L’écran qui le relit plus tard l’affiche comme du texte ou comme du balisage.

Syntax

Un navigateur corrige en silence un balisage invalide: il ferme les balises ouvertes, ignore les attributs qu’il ne comprend pas et reconstruit un arbre affichable. La technologie d’assistance, elle, reçoit l’arbre tel qu’il est produit, et un identifiant répété ou une étiquette non rattachée lui retire l’information qu’elle transmet. L’écran reste correct pour qui le regarde, et il devient inutilisable pour qui l’écoute.

On passe la page dans un validateur HTML puis dans un validateur CSS. Le rapport nomme ce que le navigateur corrigeait sans le dire. On complète par un parcours au clavier seul et par une lecture au lecteur d’écran, qui montrent les rattachements réels plutôt que les rattachements prévus. L’oracle est le rapport du validateur et la restitution du lecteur d’écran, jamais le rendu visuel.

p.ex. un formulaire qui répète un fragment par membre du ménage produit souvent le même id plusieurs fois dans la page. Le navigateur affiche l’écran sans broncher; le lecteur d’écran rattache chaque étiquette au premier champ qui porte cet id.

Ce que ce chapitre ajoute à la liste de contrôle d’un agent

Le chapitre précédent donne six contrôles à déposer dans un fichier SKILL.md. La surface web en ajoute un septième, qui se colle à la suite.

Contrôle de la surface web · surface-web-test.md

Contrôle ce que le navigateur et le protocole ajoutent: idempotence des écritures, droits sur un identifiant lu dans une URL, validation refaite chez le serveur, échappement propre au contexte de sortie.

Notes et références