GUI est l’acronyme de Graphical User Interface, soit interface graphique utilisateur en français. Le terme désigne toute interface logicielle où l’utilisateur interagit avec des éléments visuels (boutons, menus, icônes, fenêtres) plutôt qu’en saisissant des lignes de commande. Pour un product owner qui pilote le backlog d’un produit digital, maîtriser ce vocabulaire conditionne la qualité des échanges avec l’équipe design et l’équipe de développement.
GUI, UI, UX : les frontières que le product owner doit tracer
La confusion entre ces trois termes revient à chaque sprint planning. La GUI couvre strictement la couche graphique d’une application : disposition des composants visuels, états d’un bouton, retour visuel après une action utilisateur. L’UI (User Interface) englobe la GUI mais inclut aussi les interfaces vocales, haptiques ou conversationnelles.
A découvrir également : Pourquoi les téléphones milieu de gamme suffisent largement au quotidien en 2026
L’UX (User Experience) se situe un cran au-dessus. Elle intègre le parcours complet de l’utilisateur, y compris les étapes qui ne passent pas par un écran (attente d’un e-mail de confirmation, appel au support). La GUI est un sous-ensemble de l’UI, elle-même un sous-ensemble de l’UX.
Un product owner qui rédige une user story gagne en précision quand la terminologie est posée. Dire « améliorer l’UX du formulaire » reste flou. Dire « modifier la GUI du formulaire pour afficher un message d’erreur inline sous chaque champ » donne à l’équipe un critère d’acceptation testable.
A lire aussi : Quels sont les points forts du Redmi 15C à prendre en compte avant l'achat ?
Composants GUI à connaître pour rédiger des user stories
Une interface graphique repose sur un jeu limité de composants réutilisables. Les nommer correctement dans le backlog évite les allers-retours entre le product owner, le designer et le développeur.
- Widget : terme générique pour tout élément interactif d’une GUI (champ de saisie, slider, toggle, sélecteur de date). Chaque widget possède des états (actif, désactivé, en erreur, en focus) qui doivent figurer dans les critères d’acceptation de la story.
- Modal (ou fenêtre modale) : panneau superposé à l’interface principale qui bloque l’interaction avec le reste de l’écran tant que l’utilisateur n’a pas répondu. Préciser dans la story si le comportement attendu est modal ou non modal change le travail de développement.
- Tooltip et popover : bulles d’information qui apparaissent au survol ou au clic. Un tooltip affiche un texte court, un popover peut contenir des actions. La distinction impacte l’accessibilité de l’application.
- Breadcrumb (fil d’Ariane) : barre de navigation secondaire qui indique la position de l’utilisateur dans l’arborescence du produit. Utile dans les stories qui touchent à la navigation profonde.
Cette liste n’est pas exhaustive, mais elle couvre les composants les plus souvent mal nommés dans les tickets de backlog.
Intégrer le vocabulaire GUI dans le processus agile
Un vocabulaire partagé ne sert à rien s’il reste dans un glossaire que personne ne lit. L’enjeu est de l’ancrer dans les rituels du projet Scrum ou Kanban.
La user story comme point d’ancrage
Le format classique « En tant que [utilisateur], je veux [action] afin de [bénéfice] » ne suffit pas quand la story touche à l’interface graphique. Le product owner gagne à ajouter une section « Comportement GUI attendu » dans la description. Cette section liste les composants concernés, leurs états et le retour visuel après interaction.
Exemple concret : plutôt que « l’utilisateur peut filtrer les résultats », écrire « l’utilisateur interagit avec un groupe de toggles (catégorie, prix, note). Chaque toggle activé met à jour la liste sans rechargement de page. Un badge numérique sur le bouton Filtres indique le nombre de filtres actifs. »
Le design review en sprint
Lors du design review, l’équipe passe en revue les maquettes avant le développement. Utiliser les noms exacts des composants GUI pendant cette revue réduit les écarts entre la maquette et le produit livré. Un designer qui dit « le petit truc qui s’ouvre » et un développeur qui comprend « dropdown » alors qu’il s’agissait d’un popover, cela génère un bug signalé en test.
GUI et accessibilité : un angle souvent absent du backlog
Chaque composant d’une interface graphique porte des attributs d’accessibilité (rôles ARIA, ordre de tabulation, contraste des couleurs). Le product owner n’a pas besoin de maîtriser le code, mais il doit savoir que chaque widget GUI possède des exigences d’accessibilité spécifiques.
Un toggle sans label accessible reste invisible pour un lecteur d’écran. Une modal qui ne piège pas le focus clavier laisse l’utilisateur naviguer sous la couche modale sans le voir. Ces détails se traduisent en critères d’acceptation dans la story, pas en tickets séparés découverts après coup.
Intégrer la mention « Accessibilité : vérifier [composant] selon les guidelines WCAG » dans le template de story pousse l’équipe à traiter le sujet dès le développement, et non comme un correctif post-livraison.
Glossaire GUI rapide pour les échanges en sprint
| Terme | Définition opérationnelle |
|---|---|
| GUI | Interface graphique permettant l’interaction via des éléments visuels |
| Widget | Composant interactif unitaire (bouton, champ, slider) |
| Modal | Fenêtre superposée bloquant l’interaction avec l’écran principal |
| State (état) | Apparence d’un composant selon le contexte (hover, focus, disabled, error) |
| Tooltip | Bulle informative au survol, texte court, non interactive |
| Popover | Bulle riche pouvant contenir des actions, déclenchée au clic |
| Breadcrumb | Fil d’Ariane indiquant la position dans l’arborescence |
| Dropdown | Menu déroulant proposant une liste d’options |
Imprimer ce tableau ou l’épingler dans l’outil de gestion de projet de l’équipe (Jira, Linear, Notion) donne un référentiel commun consultable en quelques secondes pendant un refinement ou un sprint planning.
La précision du vocabulaire GUI dans les stories et les échanges quotidiens n’accélère pas seulement le développement. Elle réduit les bugs d’interface détectés tardivement en phase de test, là où leur correction coûte le plus de temps à l’ensemble du projet.
