Sur une même page de Cadulis, deux boutons lançaient la même action. Ils ne portaient pas le même nom. Nous ne l’avions pas vu, parce qu’on connaît notre outil par cœur, et c’est justement le problème. L’ergonomie d’un logiciel, ça se juge chez ceux qui s’en servent.
Depuis octobre 2024, l’agence messine UX-KEY observe l’usage réel de notre application et nous envoie chaque mois un rapport. On vous montre comment leur dispositif fonctionne et ce qu’il nous a fait corriger, avant de finir par les questions d’ergonomie à poser à n’importe quel éditeur avant de choisir votre logiciel.
Pourquoi l’ergonomie d’un logiciel de terrain compte double
Un écran mal pensé, au bureau, on s’en accommode. Sur le terrain, le technicien tient son téléphone d’une main, parfois avec des gants, souvent entre deux interventions et avec le client qui attend. Chercher un bouton, il n’a pas le temps. Recommencer une saisie ratée non plus.
Et puis il y a tout ce que le bureau ne voit pas : l’écran en plein soleil sur un toit, le réseau qui faiblit au sous-sol, un téléphone perso pas tout jeune avec la police agrandie.
Reste la répétition. Trois secondes perdues à chaque clôture d’intervention, vingt fois par jour, multipliées par une équipe et par une année, ça finit par peser.
Quand l’outil agace, il finit contourné. Le technicien note sur un carnet, rappelle le bureau, envoie une photo par SMS. Le logiciel est installé, mais il ne sert plus. Nous en parlions dans notre article sur la digitalisation des équipes terrain et la résistance au changement ; une bonne partie de cette résistance tient à des détails d’ergonomie logicielle que personne n’a pris le temps de regarder.
Le hic, c’est qu’un éditeur est mal placé pour les voir. Il sait où se trouve chaque fonction, il ne se trompe jamais de bouton. D’où l’intérêt d’un regard extérieur, qui part des données d’usage.
Comment fonctionne l’audit UX de UX-KEY
UX-KEY est une agence de Metz, créée en 2019, spécialisée dans l’expérience utilisateur des logiciels en ligne pour les entreprises (CRM, ERP, outils RH).
Un script qui observe l’usage réel
Un script de collecte est posé sur l’application. Il enregistre les données d’interaction pour retracer la navigation des utilisateurs. Selon UX-KEY, il ne capte que des données à caractère non personnel, et l’agence publie ses chartes de conformité au RGPD et au règlement européen sur l’IA.
Le brevet de leur technologie d’analyse des parcours, déposé en 2020, porte sur le suivi en temps réel des changements de structure des pages. Ce point compte pour un outil comme le nôtre, où les écrans se recomposent sans cesse (un planning qui se recharge, une fiche d’intervention qui s’ouvre par-dessus). Le résultat prend notamment la forme de cartes de chaleur, qui montrent où les utilisateurs cliquent.
Une analyse assistée, des conclusions humaines
Une IA aide à trier ces données. Mais l’audit lui-même reste fait par les UX designers de l’agence, qui interprètent les comportements et rédigent les recommandations.
Un rapport par mois, un thème par rapport
Chaque mois, nous recevons un rapport consacré à un seul sujet, par exemple l’ergonomie d’un parcours, l’accessibilité, l’affichage sur mobile ou la rédaction des libellés. Les points de friction y sont listés et les recommandations priorisées.
Un audit unique finit souvent dans un tiroir. Celui-là revient sur la table tous les mois, et il faut bien trancher (corriger, planifier, ou assumer de laisser).
Nous ne sommes pas les seuls logiciels de terrain dans ce cas. UX-KEY raconte par exemple comment elle a rendu plus intuitif le suivi de chantier et de tickets de maintenance de DriveIM, une plateforme de gestion technique pour l’immobilier.
Ce que l’audit a corrigé dans l’ergonomie de notre logiciel
Rien de spectaculaire, juste des défauts que plus personne chez nous ne voyait.
Deux boutons, deux noms, une seule action
Sur certaines pages, deux boutons lançaient la même action sous deux libellés différents. Nous, on savait. Un utilisateur, lui, voit deux noms et cherche deux fonctions : il se demande lequel choisir, hésite, ou pire, croit qu’il lui manque une étape.
Les règles d’accessibilité du web posent le même principe à l’échelle d’un site. Le critère 3.2.4 des WCAG 2.2 demande que les composants qui ont la même fonction soient identifiés de façon cohérente. Nous avons harmonisé les libellés.
Des boutons trop proches
Ailleurs, des boutons étaient placés si près les uns des autres qu’un clic pouvait tomber sur le voisin. À la souris, passe encore. Au pouce, dans une cage d’escalier mal éclairée, on déclenche parfois une action qu’on ne voulait pas.
La norme donne là aussi un repère. Le critère 2.5.8 des WCAG 2.2, de niveau AA, fixe une cible d’au moins 24 pixels CSS de côté, ou un espacement suffisant entre deux cibles plus petites. Nous avons revu l’espacement des boutons concernés.
Pourquoi personne ne nous l’avait signalé
On ne téléphone pas à son éditeur pour dire qu’on a hésité deux secondes devant un bouton, ou qu’on a cliqué à côté une fois dans la semaine. On râle, on recommence, et on s’habitue. Ce genre de friction se lit surtout dans les données d’usage, quand quelqu’un prend le temps de les regarder.
Ce qu’un audit UX ne remplace pas
Un audit d’ergonomie logicielle a ses limites. Il montre où les utilisateurs bloquent ; il ne dit pas toujours pourquoi, ni ce dont ils auraient besoin et qui n’existe pas encore.
Les retours directs restent donc irremplaçables. Un technicien qui explique qu’il saisit ses heures le soir parce qu’il n’a pas le temps sur place apprend autre chose à l’éditeur que n’importe quelle carte de chaleur. La formation garde aussi sa place, même avec un outil bien conçu.
Reste à arbitrer. Corriger un défaut d’ergonomie coûte du temps de développement, qui n’ira pas ailleurs. Le rapport priorise, c’est l’équipe qui décide.
Cinq questions d’ergonomie à poser avant de choisir votre logiciel
Pas besoin d’être designer pour juger l’ergonomie d’un logiciel d’intervention. Pendant une démonstration ou un essai, ces cinq questions suffisent à faire le tri.
- Une même action porte-t-elle partout le même nom ? Parcourez trois ou quatre écrans. Si « Valider », « Enregistrer » et « Terminer » semblent faire la même chose, vos techniciens vont hésiter.
- Les boutons se touchent-ils facilement au doigt ? Faites la démo sur un téléphone, pas sur l’ordinateur de l’éditeur. Essayez avec le pouce, d’une seule main.
- Combien d’écrans faut-il pour clôturer une intervention ? Comptez-les. Chaque écran de trop sera vécu cent fois par semaine.
- Que se passe-t-il quand on se trompe ? Une action destructrice doit demander confirmation, et une erreur de saisie doit pouvoir se corriger sans tout recommencer.
- Comment l’éditeur sait-il ce qui gêne ses utilisateurs ? C’est la question la plus révélatrice. Une réponse vague (« nos clients sont contents ») vaut moins qu’une méthode : retours des utilisateurs, données d’usage, audit extérieur.
Un conseil de plus. Faites tester l’outil par un de vos techniciens, pas seulement par la personne qui signera le contrat. En dix minutes d’essai, il repérera ce que la démonstration la mieux préparée ne montre pas, et vous saurez s’il l’utilisera vraiment une fois sur le terrain.
Vous êtes vous-même éditeur d’un logiciel ? Le guide de l’UX design des interfaces SaaS publié par UX-KEY détaille la démarche, de la recherche utilisateur aux tests.
Pour le reste du choix (fonctions, prix, engagement), notre guide pour choisir le meilleur logiciel de gestion des interventions passe en revue les autres critères.
Ergonomie logiciel : un chantier permanent
Chaque nouvelle fonction ajoute un bouton, un écran, un libellé, et donc une occasion de brouiller ce qui était clair. Le remède tient en peu de mots : regarder régulièrement comment l’outil est vraiment utilisé, et corriger les petites choses avant qu’elles ne deviennent des habitudes de contournement.
Nous le faisons avec UX-KEY, un rapport par mois. Et si vous voulez juger par vous-même, demandez-nous une démonstration sur téléphone, avec vos propres interventions.
