Lightspeed
2025
Simplifier la gestion des utilisateurs dans un logiciel de caisse
Ou comment repenser les rôles et permissions du back-office pour réduire les erreurs d’accès et soulager l’équipe support.
Enjeu business
Beaucoup d’employés en restauration, peu de visibilité sur leur accès
Lightspeed vend son logiciel de caisse à des groupes de restaurants, des organisations avec des dizaines d’employés, plusieurs adresses, et un turn-over élevé.
Gérer les accès au back-office et aux points de vente fait partie du quotidien des managers.
Problèmes utilisateurs
Ce que j’ai trouvé en arrivant
-
Les rôles manquaient de transparence
Difficile de savoir exactement ce qu’un rôle autorisait. Les managers avaient besoin de plus de visibilité pour configurer les accès.
Cédric, Manager de restaurant -
La granularité des accès était limitée
Les permissions ne permettaient pas encore d’adapter finement les droits selon les rôles métier réels.
Amandine, Cheffe opération multi-restaurant -
Les permissions manquaient de structure
Une liste longue sans explication ni regroupement. Avec un peu de guidage, l’expérience pouvait être bien plus fluide.
Jean-Patrick, Manager de restaurant -
Certaines actions manquaient de clarté sur leur portée
Désactiver un utilisateur depuis une location le supprimait sur tous les restaurant du groupe
Akim, Responsable de 3 restaurants
Contraintes terrain
Je suis partie avec ces cartes en main
-
Une squad en construction
Mon PM arrivait du sales, une connaissance métier pointue, mais pas de méthodo produit. C’était à moi de structurer l’approche et de capitaliser sur sa connaissance terrain.
-
3 350 tickets support en 2025
Un volume qui confirmait l’urgence du sujet et une mine d’informations brutes à exploiter (69 nouveaux tickets par semaine)
-
Un design system pas encore migré
Le design system existait, mais cette section du produit n’avait pas encore été migrée. Il fallait tout repenser avec les nouveaux légos en collaboration avec les autres designers.
Méthodes
J’ai trié ce qu’on savait déjà
Choix design
Jusqu’où aller sans tout casser ?
Standardiser avec les rôles sans brutaliser la transition
À terme, tout devrait passer par des rôles. Plus besoin d’attribuer des permissions une par une, plus de configurations hasardeuses.
Sauf que 12,5% des utilisateurs existants n’appartenaient à aucun groupe et une migration forcée était trop risquée.
J’ai donc gardé les deux options, en orientant doucement vers les rôles : en les mettant en avant en premier, en montrant leur flexibilité à la création.
-
Attribuer simplement un rôle à un user
-
Switcher pour sélectionner les permissions une à une
-
Side panel pour lister les permissions activées pour ce rôle
Rendre les permissions lisibles aujourd'hui pour les enrichir demain
Les permissions allaient devenir plus granulaires à terme. Mais avant d’en ajouter, il fallait déjà rendre celles qui existaient compréhensibles.
J’ai catégorisé les permissions par grande famille, ajouté un titre et une description à chacune, et intégré une recherche par mots-clés.
Une base propre qui prépare le terrain sans attendre que le back-end soit prêt.
-
Personnaliser les rôles avec des permissions catégorisées
-
Trouver facilement des permisions avec des mots-clés
Détourner une feature existante pour créer la business view
L’idée d’une vue globale sur tous les restaurants d’un groupe était évidente. La mettre en place l’était beaucoup moins.
Créer une vraie business view impliquait des développements back-end lourds et une dépendance à une autre squad dont la roadmap était incertaine.
On a trouvé une autre voie : les templates. Jusqu’ici utilisés en workaround par les grands groupes pour dupliquer rapidement une configuration, ils pouvaient devenir officiellement la business view. Même logique technique, nouveau rôle dans le produit.
-
Business view avec tous les utilisateurs auxquels le manager a lui-même accès
Résultats
Ce que je laisse derrière moi
-
Un langage commun
Décisions documentées, termes définis avec la squad et les squads adjacentes. Plus de flou sur qui fait quoi ni sur ce que les mots veulent dire.
-
Des maquettes prêtes à développer
Flows livrés et documentés dans le détail, migrés sur le nouveau design system. Chaque écran accompagné de ses règles et de ses cas limites.
-
Un Figma autoportant
Des fichiers organisés pour être compris sans explication orale par la nouvelle designer, par les développeurs, par les parties prenantes.