Contexte : mission menée chez Apave, groupe spécialisé dans la maîtrise des risques. Mon rôle : recherche, cadrage, architecture de l’information, parcours, UX/UI, responsive et prototypes fonctionnels.
D’une visionneuse de documents à un outil de pilotage
L’espace client d’Apave servait d’abord à récupérer des documents : des rapports d’intervention en PDF, mis à disposition après coup. Pour un petit client, c’est souvent suffisant. Pour un grand compte avec un siège, des filiales, des établissements et des dizaines de lieux d’intervention, ça ne l’est plus du tout.
L’objectif de la refonte était de faire passer l’Espace Client B2B d’une logique de restitution documentaire à une logique de pilotage de service : comprendre son organisation, gérer ses accès, suivre la prestation avant, pendant et après l’intervention, et exploiter la donnée des rapports au-delà du PDF.
Les problèmes de départ
Le cadrage a mis en évidence quatre problèmes structurels, bien plus profonds qu’une question d’interface :
- Une vision réductrice du client, ramené à l’entité facturée, sans représentation des groupes, filiales, établissements ou responsabilités locales.
- Des accès mal maîtrisés : des comptes créés automatiquement à partir d’adresses email présentes dans les rapports pouvaient exposer des données à des personnes non légitimes, comme des sous-traitants.
- Une charge interne excessive : la structuration des grands comptes reposait en partie sur des opérations manuelles, longues et fragiles.
- Une valeur métier mal restituée : le client recevait un document final, sans vision exploitable des anomalies, des équipements concernés ou de l’avancement.
L’enjeu n’était donc pas seulement de moderniser un écran, mais de concevoir un socle capable de représenter la complexité réelle des clients B2B, de sécuriser les droits et de rendre le client plus autonome.
Comprendre qui utilise le produit
Avec la business analyst et le product manager, nous avons animé un atelier UX qui a fait émerger trois grandes familles d’utilisateurs : les utilisateurs internes Apave (support, administrateurs, responsables d’agence), les utilisateurs clients (administrateur groupe, administrateur de site, responsable opérationnel, profil achats) et les utilisateurs externes ou ponctuels (prestataires, stagiaires).
Leurs besoins sont très différents. Un petit client veut accéder vite au bon document. Le siège d’un grand compte veut une vue consolidée de plusieurs entités. Un responsable d’exploitation veut lire immédiatement les anomalies. Un sous-traitant a besoin d’un accès ciblé, sans surcharge d’information.
Un même cadre d’interface pour tout le monde
La décision la plus structurante a été de garder un seul cadre d’interface pour tous les profils. La navigation, la structure et les repères restent identiques ; ce qui change, ce sont les droits, le périmètre de données visible et les fonctions activées. Cela simplifie la conception, le développement et surtout le support : un responsable d’agence peut disposer d’une vue miroir de ce que voit son client pour l’aider efficacement.
Les principes que j’ai posés
- Autonomie encadrée : le client gère lui-même ses utilisateurs grâce à un rôle de super administrateur, dans un cadre maîtrisé.
- Sécurité par défaut : tout accès doit être explicite, justifiable et traçable ; plus d’ouverture automatique à partir de données faibles.
- Représentation fidèle de la complexité : société, établissements, lieux d’intervention, mais aussi groupes, franchises, fusions ou cessions.
- Utilité immédiate : chaque profil accède d’abord à ce qui lui sert, sans détour.
- Langage client : un vocabulaire compréhensible par l’utilisateur final, pas les termes internes.
- Robustesse : synchronisation en échec, indisponibilité ou donnée manquante sont traitées explicitement par l’interface.
- Desktop d’abord pour le cœur de l’usage B2B, le mobile restant réservé à des cas précis.
Le MVP : d’abord la gouvernance
Nous avons volontairement placé la priorité du MVP sur la couche la plus critique : qui appartient à quel périmètre, qui voit quoi, qui gère qui, et comment un tiers obtient, limite ou perd un accès. Si cette couche est fragile, tout le reste du produit l’est aussi.
Le MVP couvre donc l’arborescence client, le rôle de super administrateur, une logique de permissions qui croise utilisateur, périmètre, niveau d’accès et fonctionnalités, un annuaire de tiers avec partage explicite et limité dans le temps, ainsi que les parcours d’entrée dans le produit : authentification, qualification du profil, détection du périmètre.
Des prototypes fonctionnels pour décider
Plutôt que des maquettes statiques, j’ai conçu des prototypes HTML fonctionnels, sur desktop et sur mobile, construits avec le design system Apave. Ils ont permis d’arbitrer concrètement avec les métiers et l’équipe de développement, sur des écrans qui se comportent comme le futur produit.
Valider sur le terrain
Nous nous sommes fixé une règle : confronter les hypothèses à l’usage réel avant de figer le design. Le plan de validation porte sur la fréquence d’usage, les formats de données attendus, la hiérarchie de l’information et les irritants de l’existant, avec un panel de testeurs internes et clients représentatifs, et deux temps distincts : la validation de la structure, puis celle de l’interface.
Ce que j’en retiens
Sur un produit B2B, la vraie complexité n’est pas visuelle : elle est organisationnelle. Bien représenter une structure client et bien distribuer les droits rend l’interface plus simple, pas plus lourde. Et garder un cadre d’interface unique pour tous les profils est ce qui permet au produit de grandir sans se fragmenter.
Show Comments