Cet article a été rédigé le 6 novembre 2026.
Les outils d’IA évoluent à toute vitesse. L’obligation d’informer l’utilisateur sur le résultat d’une action, elle, ne change pas. Bouton (button), lien (link), formulaire (form), champ (input), étiquette (label), erreur (error), notification éphémère (toast), squelette (skeleton), état vide (empty state), infobulle (tooltip) : autant de moyens par lesquels une page répond à une personne. L’esthétique des icônes évoluera sans cesse ; lisez ceci comme un principe de clarté et d’honnêteté ergonomique, et non comme un simple défilé de composants.
Une page qui ne donne aucun retour d’information pousse les utilisateurs à cliquer deux fois. Ils renouvellent leur action simplement parce que rien ne leur a confirmé que leur premier clic avait été pris en compte. Les modèles d’IA savent très bien concevoir l’élément sur lequel on clique, mais négligent souvent la réponse du système, à moins de la réclamer explicitement comme un composant à part entière. Cette réponse n’est pas un détail visuel : c’est ce qui sépare un formulaire fonctionnel de réservation d’une simple maquette inerte.
Un bouton exécute une action. Un lien mène quelque part.
Un bouton (button) modifie un état à cet endroit précis : envoyer, enregistrer, réserver, supprimer. Un lien (link) redirige vers un autre emplacement : la page du lendemain, un plan d’accès ou les mentions légales. Lorsque l’IA présente chaque texte sous forme de bouton, l’utilisateur ne parvient plus à distinguer la navigation d’une action concrète. Lorsqu’elle habille chaque action sous forme de lien, « supprimer » ressemble à une simple page de destination — et le devient parfois, ce qui est pire. Dans vos consignes, qualifiez le verbe d’action de bouton (button) et la destination de lien (link). Un seul bouton principal par écran suffit largement ; les actions secondaires doivent rester plus discrètes. Présenter deux boutons principaux de même niveau traduit un choix ergonomique que la page n’a pas su trancher.
Rédigez l’intitulé du bouton sous la forme d’un verbe explicite dont l’utilisateur pourra vérifier l’effet. « Réserver un créneau » permet un contrôle clair. « Continuer » ou « OK » n’apportent aucune confirmation. Si vos usagers ne lisent pas l’anglais, le verbe visible doit être rédigé dans leur langue. Le nom technique du composant à insérer dans le prompt — button, link — reste en anglais.
Un formulaire est une suite de questions identifiées
Un formulaire (form) n’est pas une juxtaposition de rectangles gris. Chaque zone de saisie est un champ (input). Chaque champ exige une étiquette (label) constamment visible, et non un simple texte d’exemple (placeholder) qui s’efface dès les premiers mots tapés. Le texte d’exemple placé à l’intérieur de la zone de saisie est une indication temporaire, pas une identification permanente. En tapant, l’utilisateur oublie ce qui lui était demandé. Les outils de traduction automatique ne peuvent pas lire un libellé qui a disparu. Exigez la règle suivante : chaque champ dispose d’une étiquette visible au-dessus d’elle, rédigée dans la langue des usagers.
Le message d’erreur (error) s’affiche en toutes lettres à côté du champ concerné, et fait également l’objet d’un récapitulatif en haut de page si plusieurs erreurs surviennent. Utiliser la seule couleur ne suffit pas à signaler une erreur. Le rouge et le vert sont indiscernables pour de nombreux usagers, bien qu’ils constituent le premier réflexe des modèles d’IA. Spécifiez clairement : « des explications textuelles, placées à côté du champ, et non de la couleur seule ».
Le caractère obligatoire d’un champ est une contrainte que vous devez définir explicitement, et non un simple astérisque dont on espère l’universalité. Précisez quels champs peuvent rester vides. Un numéro de téléphone obligatoire dans un pays peut s’avérer facultatif dans un autre. Cette logique doit être exprimée dans votre langue sous l’instruction en anglais.
Informations éphémères, permanentes ou manquantes
Une notification éphémère (toast) — parfois appelée snackbar — est un message court, le plus souvent placé en bas d’écran, qui apparaît suite à une action puis s’efface automatiquement. « Enregistré », « Copié ». Une durée de trois secondes est amplement suffisante. Elle ne doit en aucun cas constituer le seul endroit où est signalé un échec. Les messages d’échec doivent rester affichés, à côté du champ ou en haut du formulaire, jusqu’à ce que l’utilisateur ait corrigé sa saisie. Une notification éphémère qui affiche « Échec de la réservation » avant de disparaître laisse l’utilisateur sans aucun recours.
Un squelette (skeleton) représente la forme grise simplifiée de la page pendant le chargement des données réelles. C’est une solution bien supérieure à un écran blanc immobile ou à une icône de chargement indéfinie. Utilisez-le lorsqu’une liste se charge. Ne le conservez pas comme un état permanent. Si les données n’arrivent jamais, le squelette doit céder sa place à un état vide (empty state).
Un état vide (empty state) est l’écran qui s’affiche lorsqu’il n’y a encore aucun contenu à présenter : aucune réservation enregistrée, aucun cours prévu cette semaine, aucun résultat de recherche. Il nomme cette absence d’information et propose une action immédiate pour y remédier. Un tableau vide sans explications n’est pas un état vide ; c’est une interface incomplète. C’est l’écran que les petites structures oublient fréquemment de définir, et c’est pourtant celui que leurs premiers visiteurs rencontrent le premier jour, lorsque la liste est naturellement vide.
Une infobulle (tooltip) affiche quelques mots explicatifs au survol ou lors de la focalisation au clavier sur une icône qui resterait autrement énigmatique. Ce n’est pas l’endroit où détailler des conditions d’utilisation, et ce composant n’existe pas de manière fiable sur la plupart des téléphones mobiles. Si l’information est essentielle, elle doit être rédigée sous forme de texte visible. Une infobulle reste un complément d’étiquette, pas un document.
Le second clic évité
Un parent d’élève tentait de réserver un cours depuis son téléphone sur le chemin du retour. Le bouton indiquait simplement « Continuer ». Aucun retour visuel n’étant apparu à l’écran, il a réappuyé. Deux inscriptions se sont retrouvées enregistrées. Le secrétariat a attribué cela à une erreur de manipulation ; il s’agissait en réalité d’un manque de retour de l’interface. « Continuer » n’est pas un verbe dont on peut vérifier l’effet, et un écran muet ne constitue pas une confirmation.
Une page ergonomique s’appuie sur des composants très simples. Le bouton indique « Demander ce cours », dans la langue du parent. Chaque champ comporte une étiquette qui ne disparaît pas lors de la saisie. Si le numéro de téléphone est manquant, le texte d’explication s’affiche à côté du champ et y reste. Lorsque la demande est transmise, une notification éphémère (toast) confirme la réception avant de s’effacer, tandis que le formulaire se transforme en un reçu synthétique que le parent peut relire. Si la liste des cours est vide parce que le programme n’est pas encore publié, l’état vide (empty state) l’explique clairement et propose un bouton d’action, au lieu d’afficher un tableau vide d’apparence défectueuse. Rien de tout cela ne relève du style visuel : c’est une conception qui refuse de laisser l’utilisateur dans l’incertitude.
Lorsque vous formulez cette demande, conservez les nom des composants en anglais — button, label, error, toast, empty state — tout en rédigeant l’ensemble des phrases destinées aux humains dans votre propre langue. Un modèle d’IA qui ne reçoit que des termes anglais dans ses consignes de contenu publiera des libellés en anglais. C’est un dysfonctionnement distinct de l’absence de notification éphémère, mais tout aussi fréquent. Le composant technique est partagé pour garantir un comportement correct ; le texte est local pour que l’utilisateur sache exactement ce qu’il vient d’accomplir.
Une consigne de cadrage type
Build a booking form. Each input has a visible label. Errors are written beside the field in words, not by color alone. After a successful send, show a toast that says the visit is requested and leaves after a few seconds. If sending fails, keep the error on the form. If there are no visits yet, show an empty state with one button to add the first.
Rédigez ensuite les étiquettes et les messages d’erreur dans la langue de vos usagers. L’instruction en anglais ci-dessus définit la structure technique. Les phrases rédigées en-dessous traduisent le soin apporté aux utilisateurs. Un modèle d’IA ne sait pas comment un établissement de votre ville s’adresse à son public ; vous le savez. Le prochain article traitera des animations et des éléments visuels secondaires qui peuvent attendre que ces retours d’information fondamentaux soient en place.