Comment offrir une expérience utilisateur fluide pour un système supposé complexe

Dans les logiciels métier B2B, l’expérience utilisateur reste souvent le parent pauvre : des interfaces surchargées freinent l’adoption du produit, voire poussent les équipes à contourner l’outil. La gestion des habilitations en est un cas typique. Nous partageons ici un retour d’expérience concret : la conception d’un module d’habilitations pour une plateforme d’achats centralisée, avec sa hiérarchie organisationnelle multiniveaux, ses dizaines de permissions et ses rôles sur mesure. De la maquette à l’implémentation front-end, voici comment nous avons rendu la navigation intuitive, réduit la charge cognitive et favorisé l’adoption de l’outil.

1. La problématique : quand la complexité métier menace l’expérience utilisateur

Notre client opère une plateforme d’achats qui orchestre l’ensemble de la chaîne d’approvisionnement — des factures proforma au suivi douanier, en passant par le booking, le transport et la facturation. Pour sécuriser les accès, il fallait construire un système d’habilitations capable de :

• Modéliser une hiérarchie organisationnelle variable : chaque enseigne (marque) possède sa propre arborescence — départements, rayons, sous-équipes — avec des profondeurs différentes selon l’enseigne.
• Gérer des rôles sur mesure : chaque nœud de l’organigramme peut porter des rôles distincts, avec des combinaisons de permissions fines (créer une facture, valider un booking, importer des données douanières…).
• Couvrir plus de 80 permissions réparties sur 10 domaines fonctionnels différents (Proforma Invoice, Dossier de chargement, Booking, Tracking, Dossier Transitaire, Douane, Facturation, Frais & Barème, Tarification, Paramètres).

Le défi était clair : comment permettre à un responsable métier — qui n’est ni développeur ni administrateur système — de configurer tout cela sans se perdre ?

Une hiérarchie organisationnelle multiniveaux, combinée à des dizaines de permissions, crée une complexité difficile à appréhender pour l’utilisateur final. (Schéma de conception — il ne s’agit pas d’une capture d’écran du produit final.)

2. Notre démarche : une approche en quatre étapes

Plutôt que de foncer tête baissée dans le développement, nous avons suivi une démarche progressive, itérative, centrée sur l’utilisateur.

Étape 1 — Identifier l’identité visuelle adaptée

Avant de dessiner la moindre maquette, nous avons travaillé sur le langage visuel du module. L’objectif : que l’utilisateur comprenne instinctivement ce qu’il voit, sans lire de documentation. Quelques exemples concrets :

• Un code couleur par niveau hiérarchique : bleu pour le premier niveau, violet pour le deuxième, vert pour le troisième… Chaque nœud porte un accent coloré qui permet de situer sa profondeur d’un coup d’œil.
• Des badges d’état explicites : un nœud actif se distingue immédiatement d’un nœud archivé (grisé, bandeau visible).
• Des icônes contextuelles : un cadenas signale un élément verrouillé, un bouclier identifie les rôles, un engrenage ouvre les paramètres — sans avoir besoin de lire un label.

Ce travail en amont sur l’identité visuelle garantit que l’interface communique avant même que l’utilisateur n’interagisse.

Étape 2 — Concevoir des maquettes, itérer avec le client

Nous avons produit plusieurs itérations de maquettes avant d’écrire une seule ligne de code. Chaque version a été discutée avec le client, en posant une question simple à chaque écran : « Est-ce qu’un nouvel utilisateur comprendrait cet écran en moins de 10 secondes ? »

Les retours du client ont conduit à des décisions structurantes :

• Pas plus d’une action principale par écran. Si l’utilisateur doit créer un rôle, on ne lui montre que ce qui est nécessaire pour cette tâche — pas la liste complète des permissions en même temps que le formulaire de description.
• Éviter le « mur de checkboxes ». Avec plus de 80 permissions, afficher toutes les options d’un coup serait accablant. Nous avons opté pour un regroupement par domaine fonctionnel, avec des sections rétractables (accordéons).
• Utiliser un vocabulaire métier, pas technique. Au lieu de codes techniques, l’interface affiche des libellés clairs et compréhensibles. L’utilisateur parle le langage de son quotidien.
• Verrouiller les permissions dépendantes. Certaines permissions en supposent d’autres : impossible, par exemple, d’accorder la validation d’un booking sans sa création. Plutôt que d’afficher une erreur après coup, l’interface verrouille la case (icône de cadenas) et une info-bulle indique quel droit activer d’abord.

Regrouper les permissions par domaine fonctionnel avec des sections rétractables et des compteurs — l’utilisateur ne voit que ce dont il a besoin. (Schéma de conception — il ne s’agit pas d’une capture d’écran du produit final.)

Étape 3 — Découper les parcours complexes en étapes (Stepper)

L’un des tournants du projet a été l’introduction des assistants par étapes (steppers). Au lieu de présenter des formulaires monolithiques avec trop d’informations d’un coup, nous avons décomposé chaque parcours complexe en une série d’étapes claires et guidées.

Ce pattern a été appliqué dans plusieurs modules de la plateforme :

• Création d’un rôle : une première étape pour les informations générales (nom, description), une seconde pour la sélection des permissions organisées par domaine.
• Gestion d’un chargement : un parcours en plusieurs étapes — informations, offres, booking, tracking, dossier transitaire, dédouanement, facturation — où chaque étape se débloque progressivement en fonction de l’avancement du dossier.
• Configuration d’une enseigne : l’utilisateur crée d’abord l’entité, puis construit son organigramme visuellement, puis y rattache les rôles.

Étape 4 — Choisir les bons composants pour fluidifier l’interaction

Pour représenter la hiérarchie organisationnelle, un simple tableau ou une liste imbriquée n’auraient pas suffi. Nous avons opté pour un organigramme interactif — un canevas visuel où les nœuds sont connectés par des liens, et où l’utilisateur peut :

• Naviguer visuellement dans l’arbre en zoomant, dézoomant et en se déplaçant librement.
• Ajouter un sous-niveau directement depuis un nœud parent, via un bouton contextuel.
• Modifier un nœud en place — le nom et le type de niveau sont éditables directement dans la carte, sans ouvrir de formulaire séparé.
• Réorganiser automatiquement l’organigramme d’un clic, grâce à un algorithme de disposition automatique.

Cette approche transforme une tâche administrative (« configurer la hiérarchie ») en une expérience visuelle et manipulable, bien plus naturelle qu’un formulaire classique.

L’utilisateur interagit directement avec un canevas visuel — il glisse, clique, zoome, modifie sur place et ajoute des sous-niveaux contextuellement. (Schéma de conception — il ne s’agit pas d’une capture d’écran du produit final.)

3. Résultats et enseignements

La mise en production du module a confirmé la pertinence de l’approche :

• Temps de configuration d’un rôle divisé par plus de 10 : le temps moyen de création d’un rôle est passé de 45 minutes (échanges par e-mail et intervention technique) à 4 minutes en autonomie. Mesure : chronométrage d’une création de rôle par responsable (5 au total), avant et après la mise en production.
• 100 % d’autonomie dès la première semaine : les 5 responsables métier du périmètre ont tous configuré leurs rôles sans solliciter le support, sans document de formation. Mesure : les tickets « demande de configuration de rôle » sont passés d’environ 12 par mois sur les 3 mois précédant la mise en production à 0 sur les 3 mois suivants.
• Zéro configuration incohérente en production : aucune configuration de permissions invalide n’a été remontée sur les 3 mois suivant la mise en production, contre environ 3 tickets par mois sur les 3 mois précédents. Mesure : comptage des tickets « permission incohérente » dans l’outil de support.

4. Ce que nous retenons — 3 recommandations pour simplifier un système complexe

Investir dans les maquettes avant le code. Chaque heure passée à itérer sur une maquette avec le client économise des jours de refactoring. Le dialogue autour d’un visuel concret fait émerger des besoins que les spécifications écrites ne capturent jamais.

Découper systématiquement les parcours longs. Dès qu’un formulaire dépasse 5 champs ou implique des choix interdépendants, le stepper s’impose. Il transforme une tâche intimidante en une série de micro-actions maîtrisables.

Laisser l’interface faire le travail de documentation. Les tooltips, les états visuels, les verrouillages intelligents et les messages contextuels remplacent avantageusement un guide utilisateur que personne ne lira. L’objectif : qu’un nouvel utilisateur puisse utiliser le module dès sa première connexion, sans assistance.

Pour aller plus loin sur le modèle d’habilitations sous-jacent, lire l’article de Mouhcine El Hasnaoui : « Quand le rôle ne suffit plus : modéliser le périmètre d’accès à partir de l’organigramme ».

---

Vous avez un module que vos utilisateurs contournent ou qui génère des tickets de configuration ? We Are Beebay audite le parcours en une semaine, maquettes à l’appui, avant d’écrire une ligne de code. Contactez-nous ou écrivez à [email protected].