SaaS B2B · recherche, santé, innovation
2020-2025 · 7 min de lecture
De l'outil d'experts à la plateforme multi-profils
Refonte UX/UI d'une plateforme SaaS B2B pensée par des ingénieurs pour des scientifiques : parcours clé réduit de 15 à 7 étapes et conversion en hausse de 17 à 20 %, validée par A/B test.
- UX Research
- Refonte
- Design multi-profils
- A/B testing
- Client
- SKALES, plateforme de gestion de projets
- Rôle
- Responsable du design produit de l'entreprise, de l'audit (stage) au pilotage du design produit (CDI)
- Durée
- Septembre 2020 à mai 2025
- Ce qui a changé
- Une interface réservée à des experts devenue vendable à des clients sans bagage technique
Le problème
SKALES édite une plateforme SaaS qui centralise la gestion des utilisateurs, des organisations, des licences et l'accès aux applications de ses clients. Elle n'avait jamais été conçue avec ses utilisateurs : parcours lents, étapes superflues, bugs générateurs de plaintes, et aucune cohérence visuelle faute de design system.
Ce qui rendait la refonte urgente, c'était l'évolution de la clientèle. SKALES signait de plus en plus de clients hors du monde scientifique : secteur médical, équipes sans aucune formation technique. Une interface pensée pour des experts devenait un frein commercial. En parallèle, le périmètre explosait : gestion des droits, thèmes personnalisés, paiement et messagerie à intégrer.
La question de départ : comment rendre une plateforme plus riche tout en la rendant plus simple, pour des utilisateurs de plus en plus différents les uns des autres ?
La solution
Une refonte menée de bout en bout (audit, recherche, conception, tests) plutôt qu'un empilement de correctifs. Le parcours le plus critique a été reconstruit, l'affichage adapté au rôle de chaque utilisateur, les droits rendus lisibles, et chaque organisation a pu adopter son propre vocabulaire et sa propre identité visuelle.
Au-delà des écrans, l'enjeu était d'installer une méthode UX dans une équipe qui n'en avait pas : des revues produit et des temps de réflexion UX greffés sur les rituels Scrum existants, pas un processus design parallèle.
Démarche
Croiser ce que les gens disent et ce qu'ils font, parce que les deux divergent souvent.
- Entretiens clients et utilisateurs
- Questionnaires
- Google Analytics, funnels, heatmaps
- Analyse experte (Gestalt, biais cognitifs)
- Tests d'utilisabilité
- A/B testing
- Ateliers
Planches reconstituées en 2026 à partir des livrables originaux, qui appartiennent aux clients. Les contenus sensibles sont anonymisés.
Trop d'information tuait l'usage
J'ai commencé par les clients, qui centralisaient déjà beaucoup de retours de leurs équipes, avant d'aller voir les utilisateurs finaux en entretien et par questionnaire. Pour objectiver le ressenti, j'ai analysé les parcours avec Google Analytics, des funnels et des heatmaps.
Mon profil de développeur a servi dès cette étape : j'ai intégré moi-même les trackers manquants (clics, abandons, temps passé par écran) sans attendre qu'ils soient priorisés dans le backlog.
Les utilisateurs se disaient souvent perdus face à la quantité de données affichée. En croisant le temps passé sur chaque écran avec le rôle de chaque utilisateur sur un projet, nous avons vérifié qu'une grande partie de l'interface ne servait qu'à certains profils. Cette corrélation a guidé toute la suite.
Ce que le croisement a montré
- Le ressenti « je suis perdu » correspondait à une surcharge réelle, mesurable écran par écran
- Une large part de chaque écran ne concernait que certains rôles du projet
- Les plaintes remontées par les clients et les décrochages mesurés pointaient les mêmes moments du parcours
Diviser par deux le parcours le plus pénible
Créer un projet opérationnel, jusqu'à une application intégrée et utilisable, était le parcours le plus critique de la plateforme. Son étape la plus pénible était l'attribution des licences : un enchaînement incompris, et aucune façon de désactiver proprement une licence une fois intégrée. Les funnels montraient précisément où les utilisateurs décrochaient.
J'ai repensé le parcours de bout en bout : regrouper les étapes liées, supprimer celles que la plateforme pouvait déduire seule, rendre chaque action réversible, licences comprises. Les nouvelles versions ont été prototypées puis validées par A/B test avant déploiement.
De 15 à 7 étapes
- Regroupement des étapes qui relevaient d’une même décision
- Suppression de tout ce que la plateforme pouvait déduire seule
- Chaque action rendue réversible, y compris la désactivation d’une licence
- Validation par A/B test avant déploiement, puis comparaison avant/après
Parcours avant / aprèsVoir en grand ↗
Le parcours de création d'un projet, avant et après refonte. Les étapes supprimées sont celles que la plateforme pouvait déduire ou regrouper. Montrer à chacun ce dont il a besoin
Face à la surcharge d'information, trois options existaient : garder l'interface complète avec des filtres, laisser chaque utilisateur personnaliser son affichage, ou adapter l'affichage au rôle.
Nous avons retenu un double niveau. Par défaut, l'affichage s'adapte au rôle de l'utilisateur sur le projet. Un administrateur peut ensuite accorder facilement une visibilité supplémentaire à une personne précise, pour couvrir les cas que les rôles ne prévoient pas.
Option Ce qu’elle réglait Pourquoi elle ne suffisait pas Interface complète + filtres Aucun développement structurant, réversible Déplace le problème : il faut déjà savoir quoi filtrer pour s'y retrouver Personnalisation libre par utilisateur Chacun obtient exactement son écran Demande un effort de configuration que nos utilisateurs ne feraient pas Affichage adapté au rôle, ajustable par l'adminOption retenue Le bon écran par défaut, sans effort, avec une soupape pour les cas particuliers Sans objet Rendre les droits compréhensibles
La gestion des droits ralentissait la mise en place d'un projet de bout en bout. J'ai proposé des profils de droits prêts à l'emploi (utilisateur, manager, administrateur…) couvrant la majorité des besoins, puis une interface dédiée pour modifier un profil ou ajuster les droits d'un utilisateur précis. Un manager peut régler une sous-sélection de droits pour les membres de son projet, sur ce projet uniquement, sans toucher au reste de l'organisation.
L'interface regroupe les droits par familles repliables (principe de proximité de la Gestalt) pour cocher ou décocher un ensemble rapidement. J'ai surtout tenu à ce que chaque droit soit formulé simplement et que ses conséquences pour l'utilisateur concerné soient explicites avant validation.
Rôles et droitsVoir en grand ↗
Les profils prêts à l'emploi, l'ajustement fin par utilisateur, et la formulation de chaque droit avec sa conséquence explicite avant validation. Laisser chaque client parler sa propre langue
En échangeant avec les clients, un collègue et moi avons repéré une série de tickets similaires : le vocabulaire de la plateforme ne correspondait pas à celui de leur métier. Imposer un lexique neutre unique n'aurait satisfait personne.
Nous avons comparé le temps passé à traiter ces tickets avec le coût d'une fonctionnalité de labels personnalisables. Le moment était idéal : la refonte et la personnalisation des thèmes touchaient déjà la base de données. Chaque organisation a ainsi pu adapter ses libellés, importer ses propres langues, et appliquer son identité visuelle.
Les thèmes servaient aussi l'accessibilité, en proposant des variantes adaptées au daltonisme et à d'autres troubles visuels.
Argumenter le design en coût, pas en confort
- Le design n'était pas le poste prioritaire d'une startup : chaque chantier devait se justifier
- J'ai appris à chiffrer le temps perdu en support et les opportunités commerciales freinées
- Cet argumentaire a débloqué plusieurs décisions, dont celle-ci
Ce que j'en retiens
“Une méthode doit survivre à celui qui la porte. J'ai installé des revues produit et des réflexes UX dans l'équipe, mais ils reposaient beaucoup sur ma présence. C'est la leçon que j'ai le plus appliquée depuis : en freelance comme sur mes projets, je documente systématiquement recherches, décisions et rituels pour qu'ils restent transmissibles.”
Résultats
- 15 → 7
- Étapes du parcours critique
- ≈ −25 % (relatif)
- Taux d'abandon
- +17 à 20 %
- Projets menés jusqu’à une app utilisable
- A/B test + avant/après
- Méthode de validation
La plateforme est devenue utilisable, et donc vendable, à des clients sans bagage scientifique. Les plaintes et les sollicitations du support ont diminué, et l'équipe produisait de nouveaux écrans plus vite, avec moins d'allers-retours entre design et développement.