UBAQ édite des solutions SaaS de conformité réglementaire pour les industriels de la santé. NTU (NAYACT Transparency by UBAQ) gère la transparence des liens d'intérêt entre laboratoires et professionnels de santé, dans le cadre de la loi d'encadrement des avantages. L'équipe sentait que quelque chose coinçait dans l'interface mais ne parvenait pas à localiser précisément quoi, ni pourquoi les corrections successives n'amélioraient rien. Ils ont commandé un audit UX via Grandwork. Le cadrage tenait en une phrase : comprendre ce qui ne va pas et dire quoi faire.
Le dispositif
Cinq entretiens avec des profils différents au sein de l'équipe, complétés par une analyse directe de l'application en recette. Pas de tests utilisateurs finaux, pas de données analytics, pas de heatmaps. C'est un choix délibéré : sur un produit B2B de niche avec peu d'utilisateurs actifs, les signaux quantitatifs sont trop bruités pour être exploitables. Les entretiens internes, en revanche, permettent de croiser la perception de l'outil avec les contraintes de ceux qui le construisent, ce qui est précisément le point aveugle habituel.
Le diagnostic ne porte ni sur les décisions business ni sur la couverture fonctionnelle. Il porte sur ce qui empêche l'outil de fonctionner comme ses utilisateurs s'y attendent, et sur les raisons pour lesquelles ça continue.
Premier niveau : les problèmes d'interface
L'analyse de l'application fait apparaître cinq catégories de dysfonctionnements qui, pris isolément, ressemblent à des erreurs de conception classiques, mais qui ensemble dessinent un pattern plus profond.
Le modèle de données central est confus. L'objet « manifestation » regroupe sous la même étiquette des événements, des dons et des contrats, trois concepts que les utilisateurs distinguent nettement. Les commerciaux pensent en termes de dépenses et de clients, pas de manifestations. La volonté de simplifier le modèle technique s'est faite au détriment du modèle mental de ceux qui utilisent l'outil au quotidien. C'est un cas d'école de ce que Don Norman appelle le gulf of evaluation : l'écart entre la représentation du système et la représentation de l'utilisateur.
Le kanban, censé apporter de la visibilité sur l'avancement, n'offre aucun des bénéfices attendus du pattern. Pas de drag and drop, des étapes non linéaires, un rendering lent, et des cards qui accumulent des informations pertinentes à certains stades mais parasitaires à d'autres. Le pattern promet un modèle de flux ; ce qui est livré est une vue tabulaire déguisée.
La navigation change selon le contexte. Le menu d'une manifestation apparaît dans le menu général et se modifie en fonction de l'état de cette manifestation. Un menu de navigation dynamique dont les options varient selon l'état d'un objet métier est un red flag majeur en ergonomie : la navigation doit rester le repère stable de l'utilisateur, pas une surface réactive de plus.
Les formulaires mélangent quatre types d'informations dans un même écran, les relations entre objets ne sont pas visibles, et deux flux métier distincts, gérer les contrats et gérer les dépenses, cohabitent dans la même interface sans que l'utilisateur puisse les traiter séparément. L'interface est dense sans être efficace : la densité vient d'un refus de choisir, pas d'une hiérarchie maîtrisée.
Second niveau : les causes organisationnelles
Chacun de ces problèmes pourrait être corrigé isolément. Mais la question intéressante n'est pas « comment réparer le kanban », c'est « pourquoi le kanban est-il dans cet état alors que l'équipe le sait dysfonctionnel ». Les entretiens permettent de remonter aux mécanismes qui produisent ces symptômes.
L'urgence domine la planification. Quand chaque demande client génère une solution ponctuelle qui s'empile sur l'existant, les cards du kanban finissent par accumuler des champs disparates, la navigation s'adapte au cas par cas, les formulaires absorbent de nouvelles sections sans refactorisation. Ce n'est pas un problème de compétence technique, c'est un problème d'allocation du temps.
L'équipe fonctionne en feature factory : chaque demande client devient une feature à développer sans questionnement sur la valeur réelle ni l'impact sur la cohérence globale. Les choix de roadmap sont pilotés par la migration des clients de l'ancienne solution, une forme de gestion de churn au coup par coup qui sacrifie les clients de demain au profit de la rétention immédiate. Il n'existe pas de framework de priorisation fondé sur la valeur business, la faisabilité et la viabilité utilisateur.
L'absence de compétences UX et PM structurées dans l'équipe explique pourquoi chaque nouvelle fonctionnalité atterrit là où c'est le plus simple à implémenter plutôt que là où ce serait le plus logique pour l'utilisateur. Ce déficit produit un cercle vicieux : les solutions rapides d'aujourd'hui deviennent la dette conceptuelle de demain, la dette augmente la pression, la pression pousse vers des solutions encore plus expéditives. Le mécanisme n'est pas linéaire mais exponentiel, parce que chaque feature incohérente crée sa propre branche de complexité.
Ce que le diagnostic change dans les préconisations
Un audit qui s'arrête aux problèmes d'interface produit une liste de corrections. Utile, mais fragile : si les conditions qui ont généré les problèmes persistent, les mêmes dysfonctionnements réapparaissent sous d'autres formes en quelques mois. Le vrai livrable d'un audit à deux niveaux, c'est un diagnostic qui permet au commanditaire de choisir à quelle profondeur il veut intervenir.
Les préconisations couvrent donc trois registres. Le registre interface, d'abord : séparer le modèle de données en objets qui correspondent aux concepts métier, remplacer le kanban par une vue adaptée aux flux réels, stabiliser la navigation, dégrouper les formulaires. Le registre compétences, ensuite : faire entrer de l'expertise UX et PM dans l'équipe, que ce soit par recrutement, accompagnement externe ou montée en compétence interne. Le registre processus, enfin : mettre en place un framework de priorisation, sortir du mode réactif, sanctuariser du temps pour la cohérence.
Le point délicat est que ces trois registres ne sont pas indépendants. Corriger l'interface sans changer le mode de travail revient à repeindre un mur dont les fondations bougent. Monter en compétence sans framework de priorisation revient à mieux diagnostiquer des problèmes qu'on n'a pas le temps de traiter. L'audit rend ces dépendances explicites pour que la décision soit prise en connaissance de cause.
Ce que cet exercice montre de la méthode
Le réflexe classique face à une interface défaillante, c'est de proposer un redesign. Le réflexe que je défends, c'est de chercher d'abord pourquoi l'interface est dans cet état avant de décider quoi en faire. Cinq entretiens et une analyse de l'application suffisent à établir ce double diagnostic, à condition de ne pas traiter les entretiens comme une collecte de desiderata mais comme un matériau d'investigation sur les mécanismes en jeu.
Dans le cas d'UBAQ, les recommandations ont amorcé la refonte de la navigation, et l'accompagnement s'est prolongé sur l'exécution avec l'équipe produit, qui n'avait pas de profil UX en interne. La suite a montré que le diagnostic organisationnel était le levier le plus utile : l'équipe a pu arbitrer autrement parce qu'elle disposait d'un cadre pour nommer ce qui coinçait au-delà de l'interface.