Affordance et ergonomie des interfaces : des actions faciles à repérer

Vous créez une commande dans un logiciel, un menu pour une application ou une interaction de jeu. Vous savez ce qu’elle permet, mais la personne qui la découvre doit-elle deviner où cliquer, quoi faire au clavier ou si son action a réussi ? La notion d’affordance aide à poser ces questions, à condition de ne pas la confondre avec l’indice visuel qui rend une action repérable.

En interface, cette distinction conduit à des décisions concrètes : choisir une forme de bouton, expliciter une commande, signaler un état et observer les essais. Les critères d’accessibilité complètent cette démarche en apportant des vérifications pour le contraste, le clavier et la cohérence des commandes.

Pourquoi une commande évidente pour vous ne l’est-elle pas pour l’utilisateur ?

Vous connaissez déjà le fonctionnement de votre produit : un développeur sait qu’un texte souligné ouvre une page, une personne habituée à un logiciel reconnaît son icône de sauvegarde, et un joueur expérimenté anticipe les commandes d’un genre. Cette connaissance ne se transfère pas automatiquement à un nouvel utilisateur. Si une action n’est visible qu’au survol, si une icône n’a pas de libellé ou si un geste n’est jamais indiqué, la personne doit deviner ou essayer au hasard.

L’affordance, notion issue de la psychologie de la perception, décrit une possibilité d’action offerte par la relation entre un environnement et les capacités de la personne. Dans une interface, un champ permet de saisir du texte, un bouton peut être activé, une carte peut se déplacer si le système autorise le glisser-déposer. L’affordance n’est donc pas simplement une apparence : un élément visuellement plat peut être activable, et un dessin de bouton peut être purement décoratif.

Pour Don Norman, qui a introduit le terme dans le vocabulaire du design, les signifiants sont les indices perceptibles qui communiquent où agir ou ce qui est possible. Dans son texte sur les signifiants et les affordances, il souligne leur rôle pratique pour guider l’action. Une bordure, un libellé, un curseur qui change ou une animation peut signaler qu’un élément est interactif. Pour clarifier ce qui rend un produit facile à utiliser, replacez cette distinction dans l’ergonomie des logiciels et interfaces : l’indice doit correspondre à une action réellement disponible.

Quels indices rendent une interaction compréhensible ?

Un signifiant peut être visuel, textuel, sonore ou lié au contexte. Dans une application de bureau, un bouton portant « Enregistrer » nomme directement l’action. Une icône de disquette seule est moins explicite pour une personne qui ne l’associe pas à la sauvegarde. Dans un jeu, une invite « Maintenir E pour interagir » relie une touche à une action ; l’invite doit toutefois rester lisible et ne pas dépendre exclusivement de la couleur ou du son.

L’indice n’est qu’une partie de l’expérience. Une interaction claire réunit généralement trois éléments :

• un indice qui annonce la possibilité d’agir, comme un libellé ou une apparence de bouton ;
• une action réalisable avec le mode d’entrée disponible, par exemple souris, clavier ou commande adaptée ;
• un retour perceptible qui confirme l’état obtenu, comme un changement de libellé, un indicateur de chargement ou un message de réussite.

Sans retour, un clic sur « Envoyer » peut sembler ignoré ; avec un retour ambigu, la personne peut cliquer plusieurs fois. Un bouton désactivé peut également être mal interprété si rien n’explique son état. Signaler clairement la condition manquante, telle qu’un champ obligatoire à compléter, aide à comprendre comment poursuivre. Ces choix relèvent de l’ergonomie des interfaces autant que de la cohérence entre apparence et comportement, un lien également présent dans les repères sur l’ergonomie du corps et des interfaces.

Vaut-il mieux une icône, un libellé ou les deux ?

Il n’existe pas de forme universelle à appliquer à chaque commande. Une icône connue prend peu de place, mais peut être interprétée de plusieurs façons. Un libellé explicite demande davantage d’espace, mais peut lever le doute. Une icône accompagnée d’un mot peut être utile pour les actions importantes, surtout si les utilisateurs connaissent peu le produit. Le bon choix dépend du contexte, de la fréquence de l’action, de ses conséquences et des conventions déjà utilisées dans l’interface.

La cohérence est aussi un signifiant : si la même fonction change d’icône, de libellé ou de comportement d’un écran à l’autre, l’utilisateur doit réapprendre ses repères. Le critère 3.2.4 des WCAG porte précisément sur l’identification cohérente des composants ayant la même fonction dans un ensemble de pages. Les exemples du W3C sur l’identification cohérente montrent qu’un même bouton de recherche ou de sauvegarde doit rester reconnaissable, y compris lorsque sa présentation s’adapte à l’écran.

Pour choisir entre les options, demandez-vous : la commande est-elle assez fréquente ou importante pour mériter un libellé visible ? L’icône est-elle connue du public concerné ? La fonction reste-t-elle identique partout ? Une présentation compacte sur mobile peut utiliser une icône, mais son nom accessible doit continuer à décrire l’action pour les technologies d’assistance. Vérifiez aussi qu’une même icône ne déclenche pas des actions différentes sans indication supplémentaire.

Comment mettre ces principes en pratique ?

Commencez par décrire l’action du point de vue de l’utilisateur : « ouvrir les paramètres », « confirmer la sélection », « changer d’arme ». Identifiez ensuite les indices présents avant l’action, le moyen d’activation et le retour qui suit. Cette petite analyse fonctionne pour un formulaire, une interface de développement ou une commande de jeu. Elle évite de commencer par la décoration avant d’avoir clarifié ce que l’utilisateur doit pouvoir faire.

Ensuite, testez plusieurs modes d’interaction. Au clavier, la personne peut-elle atteindre chaque commande et voir le focus ? Sur écran tactile, l’action repose-t-elle sur un geste qui n’a pas d’alternative ? Pour un lecteur d’écran, le nom annoncé décrit-il la fonction plutôt que l’apparence de l’icône ? L’accessibilité web complète ainsi la réflexion sur les signifiants : les indices ne sont pas uniquement visuels. Des critères comme le contraste, l’identification et les alternatives au glisser-déposer sont également utiles pour des interfaces plus accessibles.

Les WCAG 2.2 ajoutent neuf critères de succès à la version 2.1, notamment des critères sur la visibilité du focus, les mouvements de glissement et la taille minimale des cibles. Ces exigences ne définissent pas à elles seules une bonne affordance, mais fournissent des points de contrôle concrets. Le standard du W3C pour les WCAG 2.2 précise que le contenu Web doit être vérifié selon des critères testables, sans dépendre d’une technologie particulière.

Pour le texte, le critère WCAG 1.4.3 donne des seuils de contraste : au moins 4,5:1 pour le texte courant et 3:1 pour le texte de grande taille, selon les exceptions définies dans le critère. Le texte est considéré comme grand à partir de 18 points, ou 14 points en gras. Ces seuils constituent des critères de conformité, pas une garantie que chaque utilisateur trouvera la lecture confortable. Le détail du critère de contraste minimum du W3C explique aussi les cas particuliers et la façon d’interpréter ces rapports.

Comment vérifier que vos indices fonctionnent ?

Faites un test exploratoire avec une tâche précise : demandez à une personne qui découvre l’interface de trouver une fonction ou de terminer une action, sans lui indiquer le chemin. Observez les éléments qu’elle considère interactifs, les mots qu’elle emploie pour décrire une commande et le moment où elle hésite. Évitez de lui demander seulement si l’écran est « clair » : un essai observé apporte des informations plus concrètes sur les indices utilisés.

Répétez l’observation avec le clavier et, si c’est pertinent pour le produit, avec un lecteur d’écran ou des réglages d’affichage différents. Vérifiez qu’un retour confirme chaque action importante, que le focus reste visible et que les libellés cohérents ne changent pas sans raison. Dans un jeu, demandez aussi si les commandes sont repérables pendant l’action et si les messages restent compréhensibles sans le son. Pour les interfaces Web, les ressources sur les contrastes et l’usage au clavier complètent ces essais.

Consignez les tâches réussies, les erreurs et les hésitations, puis modifiez un indice à la fois avant de retester. Un test auprès de quelques personnes peut mettre au jour un problème, mais ne permet pas d’affirmer que l’interface conviendra à tous. Si les observations divergent, vérifiez les profils, les modes d’entrée et les contextes d’usage concernés. Le résultat utile n’est pas une interface où tout semble cliquable : c’est une interface où les actions disponibles sont repérables, cohérentes et confirmées par un retour compréhensible.