À propos de ce cours
Ce TP de 5 heures fait mener l’audit UX complet d’une application existante. Les élèves remplissent sa fiche d’identité et dessinent son plan de navigation, construisent deux personas et une carte du parcours utilisateur. Ils mènent une évaluation heuristique avec les 10 heuristiques de Nielsen et une échelle de gravité, puis un test utilisateur. Ils calculent le score SUS, priorisent les recommandations avec une matrice impact / effort et produisent des maquettes avant / après et un rapport d’audit. Une vidéo, un rapport d’audit et un classeur corrigés accompagnent le TP.
| Durée | Niveau | Outils | Livrable |
|---|---|---|---|
| 5 heures (10 parties), en binôme | Débutant, après le chapitre « Introduction à l'expérience utilisateur (UX) » | Un navigateur (ordinateur et téléphone), un tableur, un outil de dessin (Figma, Excalidraw ou papier), un chronomètre | Un dossier d'analyse (rapport d'audit de 8 à 12 pages) et une présentation de 5 minutes |
-
Objectifs
- Décrire une application avec le regard d'un designer UX : son but, ses utilisateurs, son contexte et ses parcours
- Construire des personas et une carte du parcours utilisateur pour se mettre à la place des utilisateurs
- Mener une évaluation heuristique avec les 10 heuristiques de Nielsen et noter la gravité des problèmes
- Organiser un test utilisateur court, mesurer la réussite, le temps et les erreurs, et calculer un score SUS
- Distinguer ce qui relève de l'UI (l'interface) et de l'UX (l'expérience vécue)
- Prioriser les problèmes et rédiger des recommandations argumentées, illustrées par des maquettes avant / après
-
Prérequis
- Avoir suivi les leçons du chapitre « Introduction à l'expérience utilisateur (UX) » : Définition de l'UX, UX et UI : quelles différences ?, Les enjeux du design d'expérience utilisateur, Les domaines d'utilisation de l'UX.
- Aucune compétence en programmation n'est nécessaire : on observe et on analyse, on ne code pas.
-
Présentation du projet
- Le restaurant universitaire du campus a mis en ligne Resto'Campus, une application web pour téléphone qui permet aux étudiants de :
- consulter la carte du jour;
- composer leur repas dans un panier (appelé « sac ») ;
- choisir un créneau de retrait entre 11h00 et 14h45 ;
- payer avec le solde de leur carte étudiant ;
- retrouver leurs commandes dans un historique.
- Depuis sa mise en service, les réclamations se multiplient : commandes en double, plateaux non retirés, files d'attente au comptoir. Avant de financer une refonte, la direction vous confie, en tant que consultants UX, un audit de l'expérience utilisateur: que se passe-t-il vraiment pour les étudiants, et que faut-il corriger en premier ?
- L'application est fournie dans l'archive du TP (
application/resto-campus.html) : ouvrez-la dans un navigateur, de préférence sur un téléphone ou avec l'affichage mobile des outils de développement (F12, puis l'icône téléphone). Compte de test : numéro étudiant20261234, mot de passeCampus2026.
- Le restaurant universitaire du campus a mis en ligne Resto'Campus, une application web pour téléphone qui permet aux étudiants de :
- Resto'Campus est une application fictive, créée pour ce TP : ses défauts sont volontaires et réalistes. Vous ne modifierez pas son code : votre travail est de les trouver, de les expliquer et de proposer des solutions.
-
Organisation du TP
- Le TP est découpé en dix parties. Chacune indique sa durée, les notions mobilisées, les consignes, une aide, un point de contrôle et des questions.
- Chaque partie ajoute une pièce à votre dossier d'analyse (un document texte ou une présentation partagée). Le classeur
modeles/grille-analyse-ux.xlsxfourni dans l'archive contient les tableaux à remplir : problèmes, résultats du test et calcul du score SUS. - Trois règles s'appliquent à tout le TP : un constat est un fait observable, pas une opinion ; chaque problème a une preuve (capture, observation, mesure) ; chaque recommandation est précise et vérifiable.
-
Partie 0 : préparer l'analyse
⏱ 15 min
Notions mobilisées : Définition de l'UX · Les domaines d'utilisation de l'UX
- Avant de juger une application, il faut comprendre à quoi elle sert et pour qui. Ouvrez Resto'Campus sans rien chercher à accomplir, deux minutes, puis remplissez la fiche d'identité:
💡 Aide
- Les tâches principales se formulent avec un verbe, du point de vue de l'utilisateur : « commander un repas », pas « le module de commande ».
- Le contexte d'utilisation compte autant que l'écran : un étudiant pressé, debout, d'une main, avec un réseau parfois lent, n'a pas les mêmes besoins qu'un utilisateur assis devant un ordinateur.
✅ Point de contrôle
- La fiche est remplie, avec au moins trois tâches principales.
- Vous savez dans quel domaine d'utilisation de l'UX se place cette application (service public, restauration, paiement…).
❓ Questions (à traiter dans le dossier d'analyse)
- Notez vos trois premières impressions. Lesquelles concernent l'UI (ce qu'on voit) et lesquelles l'UX (ce qu'on vit) ?
- Qui sont les parties prenantes de cette application, en plus des étudiants ? Quel est l'enjeu pour chacune ?
📁 Dans le dossier : la fiche d'identité et les réponses aux questions.
-
Partie 1 : explorer l'application
⏱ 25 min
Notions mobilisées : UX et UI : quelles différences ?
- Parcourez tous les écrans de l'application : tuiles de l'accueil, icônes de l'en-tête, menu ☰, et le parcours complet d'une commande jusqu'à la confirmation.
- Faites l'inventaire des écrans (une capture et le titre de chacun), puis dessinez le plan de navigation: comment passe-t-on d'un écran à l'autre ?
💡 Aide
- Capture d'écran sur ordinateur : Win + Maj + S (Windows) ou Cmd + Maj + 4 (macOS). Nommez chaque fichier avec le titre de l'écran.
- Notez le nombre de clics nécessaires pour aller de l'accueil à la confirmation d'une commande : c'est une première mesure de la complexité d'un parcours.
⚠ Piège : ne passez pas une commande « pour voir » sans noter ce qui se passe : la première fois est la seule où vous découvrez l'application avec un regard neuf, comme un vrai utilisateur. Notez vos hésitations au moment où elles arrivent.
✅ Point de contrôle
- L'inventaire contient au moins 9 écrans, dont l'écran d'erreur de connexion.
- Le plan de navigation montre la tâche principale en couleur et les accès permanents de l'en-tête.
❓ Questions (à traiter dans le dossier d'analyse)
- Combien de clics faut-il, au minimum, pour commander un repas en partant de l'accueil sans être connecté ?
- Comment s'appelle le panier sur chaque écran où il apparaît ? Qu'en concluez-vous ?
- Que se passe-t-il si vous touchez « Payer » deux fois de suite ? Vérifiez dans l'historique.
📁 Dans le dossier : l'inventaire des écrans, le plan de navigation et les réponses.
-
Partie 2 : personas et scénarios
⏱ 30 min
Notions mobilisées : Définition de l'UX · Les domaines d'utilisation de l'UX
- Un persona est un utilisateur fictif mais réaliste, qui représente un groupe d'utilisateurs réels. Il permet de juger l'application avec ses yeux, et non avec les vôtres.
- Interrogez 2 ou 3 camarades sur leurs habitudes au restaurant universitaire (5 minutes chacun : quand, comment, ce qui les agace), puis créez deux personas différents.
- Pour chacun, écrivez un scénario: une petite histoire de quelques lignes qui raconte une situation où il utilise Resto'Campus.
💡 Aide
- Choisissez deux personas dont les besoins diffèrent: par exemple un étudiant très pressé et un étudiant qui doit éviter un aliment (allergie, régime).
- Exemple de début de scénario : « Lundi, 12h05. Yasmine sort de son TD et n'a que 45 minutes avant son prochain cours. Debout dans le couloir, elle ouvre Resto'Campus… »
✅ Point de contrôle
- Deux personas complets, chacun avec un contexte, trois objectifs, trois frustrations et une citation.
- Deux scénarios réalistes, qui utilisent la tâche principale.
❓ Questions (à traiter dans le dossier d'analyse)
- Pour chaque persona, quel est l'écran de Resto'Campus le plus risqué? Pourquoi ?
- Pourquoi ne faut-il pas créer un persona qui vous ressemble trait pour trait ?
📁 Dans le dossier : les deux personas et leurs scénarios.
-
Partie 3 : la carte du parcours utilisateur
⏱ 40 min
Notions mobilisées : Définition de l'UX · Les enjeux du design d'expérience utilisateur
- Choisissez un persona et sa tâche principale : commander un repas. Réalisez la tâche en vous mettant à sa place, puis construisez la carte du parcours (customer journey map) :
- en colonnes, les étapes de la tâche (6 à 8) ;
- en lignes, ce que le persona fait, ce qu'il pense, ce qu'il ressent (de 😟 à 😀), les irritants et les opportunités d'amélioration.
💡 Aide
- Les pensées s'écrivent entre guillemets, à la première personne : « Est-ce que c'est ajouté ? ».
- Tracez la courbe des émotions d'une étape à l'autre : les points les plus bas désignent les moments à corriger en priorité.
✅ Point de contrôle
- La carte couvre tout le parcours, de l'ouverture de l'application jusqu'au retrait du repas.
- Au moins cinq irritants sont relevés, chacun relié à un écran précis.
❓ Questions (à traiter dans le dossier d'analyse)
- À quelle étape l'émotion est-elle la plus basse ? Est-ce un problème d'UI, d'UX, ou les deux ?
- Quel irritant pourrait avoir des conséquences financières pour l'étudiant ? Et lequel des conséquences pour sa santé?
📁 Dans le dossier : la carte du parcours, avec sa courbe des émotions.
-
Partie 4 : l'évaluation heuristique
⏱ 55 min
Notions mobilisées : UX et UI : quelles différences ? · Les enjeux du design d'expérience utilisateur
- Une évaluation heuristique est une inspection de l'interface par un expert, à l'aide d'une liste de principes reconnus. Vous utiliserez les 10 heuristiques de Jakob Nielsen:
- Chaque membre du binôme inspecte d'abord l'application seul (25 minutes), écran par écran, en relevant tous les problèmes. Mettez ensuite vos listes en commun : supprimez les doublons et discutez des désaccords.
- Pour chaque problème, remplissez une ligne de l'onglet « Problèmes » du classeur : identifiant, écran, heuristique(s), constat, conséquence, gravité et recommandation, et ajoutez une capture.
💡 Aide
- Inspectez chaque écran deux fois: une première fois pour la vue d'ensemble, une seconde avec la liste des heuristiques sous les yeux.
- Pensez aux états qu'on ne voit pas tout de suite : erreurs de saisie, attente, liste vide, double clic, retour en arrière.
- Pour vérifier la lisibilité d'un texte, mesurez son contraste avec un outil en ligne (WebAIM Contrast Checker) : le minimum recommandé est de 4,5:1 pour un texte courant.
⚠ Piège : un même problème peut toucher plusieurs heuristiques : notez-les toutes, mais ne comptez le problème qu'une fois. Et ne confondez pas gravité et agacement : un défaut qui fait perdre de l'argent est plus grave qu'une couleur qui déplaît.
✅ Point de contrôle
- Au moins 12 problèmes relevés, répartis sur au moins 7 heuristiques différentes.
- Chaque problème a une capture, une gravité justifiée et une recommandation.
- Au moins un problème de gravité 4 est identifié.
❓ Questions (à traiter dans le dossier d'analyse)
- Quelle heuristique est la plus souvent violée dans Resto'Campus ? Que révèle-t-elle sur la façon dont l'application a été conçue ?
- Citez un problème que l'évaluation heuristique risque de ne pas faire apparaître, et que seul un test avec des utilisateurs peut révéler.
- Parmi vos problèmes, lesquels concernent l'accessibilité (personnes malvoyantes, usage d'une main, en plein soleil) ?
📁 Dans le dossier : le tableau des problèmes trié par gravité, avec les captures annotées.
-
Partie 5 : le test utilisateur
⏱ 40 min
Notions mobilisées : Définition de l'UX
- Faites réaliser cinq tâches à au moins trois participants qui ne connaissent pas l'application (des étudiants d'un autre groupe). L'un de vous anime, l'autre observe et note.
| Tâche | Consigne lue au participant |
|---|---|
| T1 | Commander un couscous et un yaourt à retirer à 13h15, en partant de l'accueil (non connecté). |
| T2 | Vérifier si les lasagnes contiennent du lait. |
| T3 | Dans le panier, passer de 1 à 2 couscous. |
| T4 | Retrouver le numéro de la commande que vous venez de passer. |
| T5 | Annuler cette commande. |
💡 Aide
- Demandez au participant de penser à voix haute. Quand il se tait, relancez par « Qu'est-ce que vous cherchez ? », jamais par « Cliquez sur… ».
- Si une tâche dépasse le temps limite, notez « échec » et passez à la suivante, sans montrer la solution.
- Réinitialisez l'application entre deux participants : rechargez la page (F5).
⚠ Piège : ne testez pas avec vos coéquipiers ni avec quelqu'un qui a déjà vu l'application : il connaît les pièges et contourne les problèmes sans s'en rendre compte.
✅ Point de contrôle
- L'onglet « Test » du classeur contient, pour chaque participant et chaque tâche, le résultat (réussie, partielle, échec), le temps et le nombre d'erreurs.
- Le classeur calcule le taux de réussite, le temps moyen et le nombre moyen d'erreurs par tâche.
- Vous avez relevé au moins 5 verbatims (phrases prononcées par les participants).
❓ Questions (à traiter dans le dossier d'analyse)
- Quelle tâche a le plus faible taux de réussite ? Quel(s) problème(s) de la partie 4 l'expliquent ?
- Le test a-t-il fait apparaître un problème que vous n'aviez pas relevé en partie 4 ?
📁 Dans le dossier : le protocole, le tableau des résultats et les verbatims.
-
Partie 6 : le questionnaire SUS
⏱ 20 min
Notions mobilisées : Les enjeux du design d'expérience utilisateur
- Après les tâches, chaque participant remplit le questionnaire SUS (System Usability Scale) : dix affirmations notées de 1 (pas du tout d'accord) à 5 (tout à fait d'accord). Les affirmations sont dans l'onglet « SUS » du classeur.
- Calculez le score SUS de chaque participant, puis la moyenne :
⚠ Piège : le score SUS n'est pas un pourcentage, et ce n'est pas la moyenne des notes. Une affirmation sur deux est négative : il faut d'abord convertir chaque réponse en contribution.
✅ Point de contrôle
- Le classeur calcule le score SUS de chaque participant avec une formule, et la moyenne.
- Le score est vérifié à la main pour un participant.
❓ Questions (à traiter dans le dossier d'analyse)
- Le score moyen se situe-t-il au-dessus ou en dessous de 68 ? Comment l'expliquer à un directeur qui ne connaît pas le SUS ?
- Le score SUS et les résultats des tâches racontent-ils la même histoire ?
📁 Dans le dossier : les scores SUS et leur interprétation.
-
Partie 7 : prioriser
⏱ 25 min
Notions mobilisées : Les enjeux du design d'expérience utilisateur
- Vous ne pouvez pas tout corriger d'un coup. Regroupez les problèmes en recommandations (une recommandation peut corriger plusieurs problèmes), estimez pour chacune un effort de 1 (faible) à 3 (élevé), puis placez-les dans la matrice :
💡 Aide
- L'impact d'une recommandation est la gravité la plus élevée des problèmes qu'elle corrige. Ajustez-le avec les résultats du test : un problème que tous les participants ont rencontré pèse plus lourd.
- Un texte à changer ou un bouton à désactiver est un effort faible ; une nouvelle fonctionnalité (annulation, recommandation du dernier repas) un effort élevé.
✅ Point de contrôle
- Chaque recommandation est placée dans la matrice, et au moins trois « gains rapides » sont identifiés.
❓ Questions (à traiter dans le dossier d'analyse)
- Quelles sont les trois recommandations que vous mettriez en œuvre la première semaine ? Justifiez par la gravité, les résultats du test et l'effort.
📁 Dans le dossier : la matrice et la liste ordonnée des recommandations.
-
Partie 8 : recommandations et maquettes avant / après
⏱ 30 min
Notions mobilisées : UX et UI : quelles différences ?
- Rédigez les recommandations en suivant le format problème → preuve → recommandation, puis illustrez les deux plus importantes par une maquette avant / après de l'écran concerné.
💡 Aide
- Une maquette en basse fidélité suffit : papier photographié, Excalidraw ou Figma. Placez la capture actuelle à gauche, votre proposition à droite, et numérotez les changements.
- Pour chaque changement, indiquez l'heuristique respectée et ce que l'utilisateur y gagne.
✅ Point de contrôle
- Deux maquettes avant / après, annotées, qui corrigent au moins quatre problèmes.
- Chaque recommandation est précise : on sait exactement quoi changer.
❓ Questions (à traiter dans le dossier d'analyse)
- Dans vos maquettes, quels changements relèvent de l'UI et lesquels de l'UX ? Un changement d'UI peut-il améliorer l'UX ?
📁 Dans le dossier : les recommandations rédigées et les deux maquettes.
-
Partie 9 : le rapport et la présentation
⏱ 20 min
Notions mobilisées : Les enjeux du design d'expérience utilisateur
- Assemblez le rapport d'audit selon le plan ci-dessous, puis préparez une présentation de 5 minutes pour la direction du restaurant : le constat, les trois priorités, une maquette.
- Variantes (au choix, pour les binômes en avance) : appliquer la même démarche à une vraie application que vous utilisez (transport, banque, réseau social) ; vérifier l'accessibilité de Resto'Campus avec un lecteur d'écran ; comparer deux applications concurrentes avec le SUS.
- Relisez votre rapport : chaque problème a une preuve, chaque recommandation est précise, aucun jugement personnel (« c'est moche ») ne remplace un constat.
-
Grille d'évaluation (sur 20)
| Critère | Points |
|---|---|
| Parties 0–1 : fiche d'identité, inventaire des écrans, plan de navigation | 2 |
| Partie 2 : deux personas crédibles et différents, scénarios réalistes | 2 |
| Partie 3 : carte du parcours complète, courbe des émotions, irritants reliés aux écrans | 2 |
| Partie 4 : au moins 12 problèmes, heuristiques justes, gravités argumentées, captures | 4 |
| Parties 5–6 : protocole respecté, mesures, verbatims, score SUS calculé et interprété | 3 |
| Partie 7 : matrice impact / effort cohérente | 2 |
| Partie 8 : recommandations précises, deux maquettes avant / après annotées | 3 |
| Partie 9 : rapport structuré et présentation de 5 minutes | 2 |
| Total | 20 |
-
Livrables
- Le rapport d'audit (PDF), avec vos noms, 8 à 12 pages, selon le plan de la partie 9.
- Le classeur
grille-analyse-ux.xlsxcomplété : problèmes, résultats du test, scores SUS. - Les deux maquettes avant / après (images ou lien Figma) et le support de présentation.
-
Erreurs fréquentes
| Symptôme | Cause | Solution |
|---|---|---|
| « La page d'accueil est moche » | Opinion au lieu d'un constat | Décrire ce qu'on voit et sa conséquence : « 9 tuiles de même taille ; la commande est noyée » |
| Un problème sans capture ni mesure | Absence de preuve | Joindre une capture annotée, une observation ou un chiffre |
| Toutes les gravités à 4 | Gravité confondue avec l'agacement | Juger la fréquence, l'impact et la persistance |
| Le même problème compté trois fois | Un problème par heuristique concernée | Une ligne par problème, plusieurs heuristiques dans la colonne |
| Le participant réussit toutes les tâches | Il a été aidé, ou connaissait l'application | Ne jamais montrer ; recruter des personnes extérieures |
| Score SUS de 3,2 ou de 64 % | Moyenne des notes, ou score lu comme un pourcentage | Convertir chaque réponse, sommer, multiplier par 2,5 |
| Persona « étudiant, 18-25 ans, aime son téléphone » | Persona trop vague | Un prénom, un contexte précis, des objectifs et des frustrations utiles à l'analyse |
| « Améliorer l'ergonomie du panier » | Recommandation vague | Une action vérifiable : « remplacer les lignes en double par un sélecteur − 1 + » |
| Uniquement des remarques de couleurs et de polices | UX réduite à l'UI | Analyser aussi les parcours, les erreurs, les délais, la confiance |
| Recommandations sans ordre | Pas de priorisation | Matrice impact / effort, trois priorités pour commencer |
-
Pour aller plus loin
- Mesurer la lisibilité et l'accessibilité avec les critères du WCAG (contraste, taille des cibles, textes alternatifs).
- Compléter le test avec des indicateurs de suivi : taux d'abandon du panier, temps moyen de commande, nombre de commandes en double.
- Transformer les recommandations en maquettes haute fidélité dans Figma : ce sera l'objet des prochains chapitres.
-
Bilan
- L'UX se mesure : taux de réussite, temps, erreurs, score SUS. Elle ne se résume pas à l'apparence de l'interface.
- L'évaluation heuristique (le regard de l'expert) et le test utilisateur (le regard de l'utilisateur) se complètent.
- Un problème bien décrit est un constat, avec une preuve, une gravité et une recommandation.
- On ne corrige pas tout : on priorise selon l'impact pour l'utilisateur et l'effort de correction.
Une bonne expérience utilisateur ne se remarque pas : l'étudiant commande, paie, récupère son plateau, et n'y pense plus. C'est quand elle est mauvaise qu'on la voit… et c'est à vous de la rendre invisible.