Audit UX et ergonomique : ce qui bloque vos utilisateurs, et pourquoi

Ce qu'un audit UX révèle, et ce qu'il ne révèle pas

Un audit répond à trois questions, et à trois seulement : où sont les points de friction, pourquoi ils existent, et lesquels corriger en premier. Tout ce qu'on lui fait dire au-delà est une extrapolation.

Il est utile quand vous reconnaissez au moins un de ces trois signaux :

• Les visiteurs arrivent et repartent en moins de trente secondes, alors que vos campagnes fonctionnent.
• Votre support répond toujours aux trois mêmes questions, et ce sont des questions sur le fonctionnement du produit.
• Une fonctionnalité que vous avez développée n'est utilisée par presque personne.

Ces trois signaux ont un point commun : ce sont des problèmes d'interface, pas des problèmes de trafic. Acheter plus de visiteurs pour compenser un parcours qui perd les gens revient à remplir plus vite un seau percé.

Un audit n'est pas une refonte

L'audit répond à « où sont les problèmes et lesquels coûtent le plus cher ». La refonte est le chantier qui suit. Beaucoup d'entreprises lancent une refonte complète sans avoir fait le diagnostic : elles refont l'interface, gardent les mêmes problèmes de parcours, et se retrouvent au même endroit six mois plus tard avec un budget en moins. Savoir ce qui ne va pas coûte une fraction de ce que coûte le fait de le redécouvrir après.

Ce qu'il ne dit pas

Un audit expert repose sur mon regard, appuyé sur des schémas d'usage éprouvés et sur la vérification technique de chaque point. Il ne remplace pas l'observation de vos utilisateurs réels. C'est écrit dans chacun de mes rapports, à la fin de chaque recommandation : elle reste à confirmer par un test avant implémentation. Je préfère l'écrire que le laisser croire, parce qu'un rapport qui prétend tout savoir est un rapport qu'on finit par ne plus croire du tout.

Les frictions que je retrouve le plus souvent

Les produits que j'audite n'ont presque jamais le même métier. Les frictions, elles, se répètent. Voici celles qui reviennent d'un audit UX design à l'autre, quel que soit le secteur.

• Un parcours long, sans annonce ni porte de sortie

  Un bouton promet un contenu et ouvre en réalité un questionnaire de cinq minutes. L'utilisateur n'a pas consenti, et rien ne lui propose de le faire plus tard. C'est la friction la plus coûteuse que je rencontre, et la moins chère à corriger.

• Deux indicateurs de progression qui disent la même chose

  Une barre d'étapes et un compteur cohabitent. Sur mobile, ils occupent une part significative de l'écran avant même la première question, et rallongent visuellement un parcours qu'on cherchait à raccourcir.

• Du jargon métier sans aide contextuelle

  Un terme technique évident pour l'équipe qui l'a écrit, opaque pour la personne qui doit répondre. Elle répond quand même, au hasard, et la donnée récoltée ne vaut rien.

• Des champs pré-remplis qui faussent les réponses

  Une valeur par défaut ressemble à une suggestion. Beaucoup la valident sans y penser. Vous croyez collecter une réponse, vous collectez votre propre proposition.

• Un bouton retour qui ne ramène pas où on croit

  Revenir en arrière renvoie à la mauvaise étape, ou fait perdre ce qui venait d'être saisi. L'utilisateur cesse alors d'explorer, par peur de casser quelque chose.

• Une action structurante confirmée par une notification discrète

  Un versement, une suppression, un envoi définitif validés par un message qui disparaît en trois secondes. Le doute qui suit se transforme en ticket de support, ou en abandon.

• Une barre de navigation qui disparaît sur certains écrans

  Sur mobile, la barre du bas est le repère principal. Un seul écran où elle manque et l'utilisateur se retrouve sans issue visible, sur l'écran précis où il venait d'arriver.

• Une contrainte que rien n'annonce

  Un filtre qui n'accepte qu'une sélection à la fois, une limite quotidienne, un plafond lié à l'offre gratuite. La règle existe, elle est peut-être justifiée, mais elle n'est écrite nulle part et l'utilisateur la découvre en échouant.

Une dernière catégorie mérite d'être mise à part, et je la sépare toujours dans mes rapports : les bugs ne sont pas des sujets d'UX. Un champ qui refuse une saisie valide, une langue qui bascule toute seule : ce sont des corrections de développement. Mais ils abîment la confiance aussi sûrement qu'un parcours mal conçu, et ils doivent être réglés avant toute campagne d'acquisition. Ils figurent donc dans le rapport, dans leur propre liste.

Ma méthode d'audit ergonomique, en 6 étapes

La même séquence sur chaque mission, quel que soit le produit. C'est ce qui rend deux rapports comparables, et c'est ce qui fait que rien n'entre dans un rapport sans avoir été vérifié.

1. 1. Cadrage du périmètre

   Quel parcours, quels écrans, et surtout quel objectif business derrière. Auditer un produit entier sans priorité produit un catalogue que personne ne traite, et auditer l'inscription quand le problème est la rétention ne sert à rien non plus.

2. 2. Parcours joué de bout en bout, commenté à voix haute

   Je fais le parcours comme un utilisateur qui découvre, en enregistrant ce que je dis au moment où je le dis. C'est la seule façon de capter l'hésitation avant de l'avoir rationalisée. Desktop en 1440 px et mobile en 390 px, systématiquement : la moitié des frictions n'existent que sur l'un des deux.

3. 3. Chaque point rejoué et capturé

   Rien de ce que j'ai dit à voix haute n'entre dans le rapport sans avoir été refait manuellement et capturé en image. Cette étape élimine les faux positifs, et il y en a toujours : ce que j'avais signalé et qui fonctionne en réalité est documenté, pas retiré en silence.

4. 4. Vérification de la cause dans le code source

   C'est l'étape qui change la nature du rapport. Constater qu'un bouton ne réagit pas est une observation. Savoir que c'est un état désactivé conditionné par un champ que rien n'indique comme obligatoire est une consigne de correction. Vos développeurs reçoivent la seconde, pas la première.

5. 5. Corroboration, quand le matériau existe

   Une session de test utilisateur si le périmètre le justifie, la lecture de vos avis publics et de vos tickets de support s'il y en a, vos données d'usage si vous en avez. Sur un audit de mai 2026, une seule séance de test a confirmé deux points et en a fait apparaître quatre que je n'avais pas vus.

6. 6. Priorisation et restitution

   Les points sont classés par impact, regroupés en lots indépendants et chiffrés, puis présentés en visio. La restitution n'est pas une formalité : c'est le moment où vos contraintes réelles, techniques et budgétaires, redécoupent la feuille de route.

Les heuristiques d'utilisabilité de Jakob Nielsen servent de grille de relecture en fin de parcours, pour vérifier qu'aucune famille de problème n'a été oubliée. Elles ne sont pas la colonne vertébrale du travail : un audit conduit en déroulant une liste de dix principes produit un rapport qui ressemble à la liste, pas à votre produit.

Ce que vous recevez, et ce qui dépend du contexte

Le rapport est livré au format .md, celui que vos développeurs ouvrent dans leur éditeur et dans lequel ils peuvent cocher au fur et à mesure. Pas un PDF de trente pages qu'il faut recopier ailleurs pour s'en servir.

Les trois derniers ne sont pas des options payantes cachées : ce sont des livrables qui dépendent de ce qui existe déjà chez vous. Je vous dis au cadrage lesquels s'appliquent, avant que vous décidiez quoi que ce soit.

À quoi ressemble un point de rapport

Décrire une méthode ne prouve pas grand-chose. Voici donc un point réel, tiré d'un audit livré en 2026 et anonymisé : ni le client, ni le produit, ni la fonctionnalité d'origine ne sont identifiables. Ce qui compte ici n'est pas le constat, qui change à chaque mission, mais la forme, qui ne change jamais.

Six éléments, toujours les mêmes : le constat, les formats sur lesquels il est confirmé, la cause technique, l'impact sur l'utilisateur, une recommandation principale, et une alternative moins chère à développer. Cette dernière fait la différence entre un rapport qu'on applique et un rapport qu'on classe.

Comment je priorise, et pourquoi il y a toujours deux options

Un rapport de vingt points sans hiérarchie est un rapport que personne ne traite. Chaque friction reçoit donc une priorité, Haute, Moyenne ou Basse, établie sur ce qu'elle coûte réellement : combien d'utilisateurs la rencontrent, à quel moment du parcours, et si elle les fait hésiter ou abandonner.

Mais la priorité seule ne suffit pas à décider. Une friction Haute qui demande trois semaines de développement ne passe pas forcément avant une friction Moyenne corrigée en une journée. C'est pourquoi le coût de correction est estimé en face de chaque point, et c'est pourquoi chaque recommandation en contient deux : celle que je conseille, et une version dégradée mais nettement moins chère à développer.

Le rapport se termine sur une feuille de route découpée en lots indépendants et chiffrés. Indépendants, c'est le mot important : chaque lot peut être embarqué seul, dans l'ordre qui correspond à votre agenda de développement. Vous n'avez pas à tout faire, ni à tout faire dans mon ordre.

Les bugs constituent leur propre lot, et sur mes audits ce lot n'est pas facturé : ce n'est pas du travail de conception, c'est une liste de correctifs à passer à vos développeurs. Elle fait partie de l'audit.

Ce que ça change, et ce qu'on mesure pour le savoir

Vous ne trouverez pas de pourcentage de résultat sur cette page, et c'est volontaire. Je ne m'engage pas sur des résultats : un audit identifie ce qui bloque, ce sont les corrections qui produisent l'effet, et elles dépendent de ce que vous décidez d'embarquer. Promettre un chiffre serait vous vendre le travail de quelqu'un d'autre.

Ce que je fais en revanche, c'est fixer avec vous les indicateurs à relever avant les corrections, pour que la mesure d'après veuille dire quelque chose. Six suffisent, et il n'en faut jamais six à la fois : deux ou trois choisis en fonction de ce que l'audit a trouvé.

La condition tient en une phrase : l'indicateur se choisit avant de corriger. Un retour sur investissement calculé après coup, sur le chiffre qui arrangeait, est un argument commercial, pas une mesure.

Diagnostic UX à 500 € ou accompagnement : lequel pour vous

Le Diagnostic UX est l'audit, en format court et à prix fixe. 500 €, livré sous 72 heures. Il existe pour deux situations précises : vous n'avez pas le budget d'un accompagnement complet, ou vous ne voulez pas vous engager avant d'avoir vu comment je travaille. Les deux sont légitimes, et la seconde est plutôt saine.

Il s'arrête là où commence la conception : vous recevez les frictions, leurs causes et les corrections priorisées, mais ni wireframes, ni maquettes, ni mise en œuvre. Si votre équipe peut appliquer les recommandations, c'est exactement ce qu'il vous faut.

L'accompagnement complet part du même audit et enchaîne sur la conception : recherche, structure, wireframes, maquettes haute fidélité, tests utilisateurs, réunion de passation aux développeurs. Il est sur devis, parce que concevoir un tunnel d'achat et refondre une application métier de quarante écrans n'ont ni le même périmètre ni la même durée.

Rien ne vous oblige à choisir maintenant. Beaucoup commencent par le diagnostic et décident ensuite, avec le rapport sous les yeux. Le comparatif détaillé des deux formules dit ce que chacune contient et ce qu'elle ne contient pas.