Un audit UX examine les obstacles qui gênent une tâche sur un site : comprendre une prestation, trouver une information, utiliser un menu ou préparer une demande. Son intérêt vient de constats que l’on peut reproduire, pas d’une note générale ou d’une promesse de contacts supplémentaires.
Le diagnostic doit annoncer ce qui a été examiné, dans quelles conditions et avec quelles limites. Une revue de pages, un outil automatique et une session avec des participants apportent des preuves différentes. Les réunir dans un rapport ne les rend pas interchangeables.
Définir le périmètre avant de chercher des problèmes
Choisissez les pages et les tâches à examiner. Précisez le point de départ, la prochaine action et ce qui permet de dire que la tâche est terminée. Pour un contact, distinguez l’ouverture du formulaire, la saisie et la réception prévue ; pour un achat, le paiement et la commande doivent aussi être identifiés.
Listez les conditions retenues : appareil, navigateur, taille d’affichage, mode de saisie, état connecté ou non et données de test. Ajoutez les accès autorisés et les systèmes dont dépend le parcours. Le diagnostic ne donne pas automatiquement le droit d’installer un suivi, de modifier un compte ou d’envoyer une vraie demande.
Indiquez aussi ce qui reste non testé : paiement réel, traitement d’un e-mail, appareil absent ou service tiers inaccessible. Un rapport portant sur des pages sélectionnées ne doit pas annoncer une couverture de tout le site.
Séparer constat, hypothèse et observation d’un participant
Un constat reproductible décrit un comportement observé : le menu reste ouvert après un choix et masque le contenu, un lien mène à une page absente ou une erreur n’indique pas quel champ corriger. Notez les étapes permettant de retrouver ce comportement.
Une hypothèse propose une explication encore à vérifier : un intitulé pourrait être mal compris, une information importante pourrait être difficile à trouver. Ne la présentez pas comme une observation de toute l’audience. Les données disponibles peuvent orienter la recherche, mais l’absence d’un événement ne prouve pas à elle seule l’abandon d’une personne.
Les tests d’utilisabilité décrits par GOV.UK observent des participants accomplissant des tâches réalistes, avec des consignes neutres. Cette démarche demande des participants pertinents et une préparation spécifique. Cliquer soi-même ou exécuter un script n’est pas un test utilisateur avec des participants.
Examiner un parcours dans des conditions explicites
Suivez la tâche depuis son entrée jusqu’au résultat attendu. Vérifiez les noms des liens, les informations nécessaires, les retours disponibles et les états de l’interface. Un problème sur la page de contact peut venir d’une étape précédente qui annonce autre chose que ce qui est demandé.
Pour le clavier, notez si les contrôles sont atteignables, activables et repérables. Pour les formulaires, examinez les aides, les erreurs et la confirmation, sans envoyer une donnée réelle sans autorisation. Les premiers contrôles d’accessibilité W3C donnent des pistes de vérification ; ils ne constituent pas une évaluation complète de conformité.
Une vue de téléphone simulée sert à repérer un débordement ou une disposition inattendue. Elle ne prouve pas le fonctionnement du clavier virtuel, du tactile ou d’un navigateur réel. Le guide sur le diagnostic d’un parcours sur smartphone détaille cette distinction. Les conditions non disponibles restent une limite du rapport.
Rédiger une fiche que quelqu’un peut rejouer
Pour chaque difficulté retenue, renseignez une adresse, les conditions, les étapes, le résultat attendu et le résultat obtenu. Ajoutez une capture utile si sa diffusion est autorisée, puis une correction proposée. Une capture montre un état ; elle ne remplace pas les étapes de reproduction.
- Situation : quel besoin et quelle page sont concernés ?
- Reproduction : quelle action mène à la difficulté ?
- Preuve : qu’est-ce qui a été effectivement observé ?
- Impact : quelle tâche est bloquée ou rendue plus difficile ?
- Suite : quelle correction est proposée, et comment la vérifier ?
Exemple illustratif : après l’ouverture d’un menu au clavier, la sélection d’une rubrique laisse le panneau devant la page. La fiche précise le navigateur, la rubrique, la séquence et l’état attendu. L’exemple explique la forme du livrable ; il ne décrit pas un défaut reçu sur un site client.
Si la difficulté ne se reproduit pas, gardez la trace de l’essai et de ses conditions. Ne transformez pas un signalement non confirmé en certitude. Une différence d’appareil, de données ou de session peut être la prochaine piste à examiner.
Prioriser selon la tâche plutôt qu’un gain inventé
Commencez par les obstacles qui empêchent de terminer une tâche ou donnent une fausse confirmation. Distinguez ensuite les difficultés qui imposent un détour, les incohérences récurrentes et les ajustements esthétiques. Expliquez le classement : plusieurs catégories sans justification n’aident pas à décider.
Le choix d’une correction tient compte des dépendances, des accès, de l’effort et du risque de régression. Une même anomalie peut apparaître sur plusieurs pages parce qu’elles partagent un composant. Cela justifie d’examiner la portée de la correction, pas de supposer que toutes les autres pages sont déjà validées.
Un formulaire réparé ne vaut pas automatiquement une vente. Un devis, une demande commerciale, une commande et un encaissement doivent rester distincts. Sans données et hypothèses explicitement reçues, ne calculez pas un retour sur investissement à partir d’un nombre de clics.
Recevoir les corrections et conserver les réserves
Après modification, effectuez une nouvelle vérification avec les conditions de départ. Comparez le comportement, contrôlez les autres états concernés et consignez le résultat. Si une correction change un composant partagé, prévoyez les parcours voisins à rejouer avant généralisation.
Un résultat peut être corrigé et vérifié, non corrigé, ou toujours non testé faute d’un appareil ou d’un accès. Ces états doivent rester lisibles dans le rapport. Le passage d’un test automatisé ne ferme pas une réserve sur la compréhension humaine, la livraison d’une notification ou les conditions de production.
L’optimisation de conversion dans la durée relève d’un suivi distinct du diagnostic initial. Le périmètre d’un audit, des corrections et de leur réception se définit avant la mission. Pour commencer, partagez votre site et un parcours à examiner, ainsi que les difficultés et les traces dont vous disposez déjà.
