Garance
Comment rendre le parcours de souscription au PERO plus clair, côté conseiller comme côté client ?
La missionRefonte d’un parcours de souscription
Contexte
Garance est une mutuelle d’épargne et de retraite, née en 1986 auprès des artisans. Elle compte aujourd’hui plus de 250 000 adhérents.
Parmi ses offres, le PERO (plan d’épargne retraite obligatoire) : la retraite collective d’entreprise. Une TPE ou une PME le met en place pour ses salariés, dès le premier, et le finance en tout ou partie.
Souscrire un PERO, c’est donc enregistrer une entreprise : ses informations, ses représentants, ses justificatifs. Les conseillers Garance le font dans un parcours dédié de leur outil, accessible avec leur identifiant. Ils le remplissent seuls, ou en rendez-vous, avec le client à leurs côtés.
L’enjeuSujet 1
Ce parcours de souscription au PERO existait déjà, et ses étapes comme sa logique étaient validées. Ma mission n’était pas de repenser la stratégie, mais de refondre l’interface.
Comment rendre un parcours long et dense cohérent, moderne et fidèle au design system ?
Audit de la V1
J’ai commencé par un audit du parcours existant, croisé avec les retours des tests menés auprès des conseillers.
- Constat 1
- On se perdTout le parcours est déplié, sans indiquer la sous-étape en cours.
- Constat 2
- Un seul blocDes formulaires sans titres, où les sujets se mélangent.
- Constat 3
- Des doublonsDes champs d’adresse répétés, tous affichés en même temps.
- Constat 4
- Hors design systemDes composants qui ne sont pas ceux du design system de Garance.
La refonte
Trois écrans du parcours, avant et après.
Informations de l’entreprise
- Dans le sommaire (le menu des étapes, à gauche), seule l’étape en cours est dépliée et la sous-étape active est surlignée ; un fil d’Ariane indique où l’on est.
- Le formulaire est découpé en cards titrées : ID Mercure, Entreprise, Adresse du siège social, Adresse secondaire.
- Une seule recherche d’adresse ; la saisie manuelle n’apparaît que si on la demande.
- Le bouton à bascule (toggle), mal compris par les conseillers lors des tests, devient une question claire : Oui / Non.
Avant
AprèsDocuments à préparer
- « Documents » devient une vraie sous-étape, et les étapes terminées portent une coche verte.
- Un document par card, avec son icône, sa description et un badge Obligatoire ou Facultatif.
- Les détails (documents acceptés, cas particuliers) sont repliés dans des accordéons : le conseiller ne les ouvre qu’en cas de besoin.
Avant
AprèsPièces justificatives
- Les pièces sont rangées par personne : une card pour l’entreprise (RIB, Kbis, statuts, accord collectif), puis une card par représentant ou bénéficiaire, à son nom et avec son rôle.
- Un seul champ pour la pièce d’identité : la case « Recto et verso séparés » ne le dédouble qu’en cas de besoin.
- L’encart reprend le style « information » du design system, au lieu de l’orange réservé aux alertes.
Avant
AprèsMa façon de travailler
Une planche Figma par section, qui réunit tout.
À gauche, mes états de l’écran : Default & Filled.
En regard, l’existant : la V1, et l’écran tel qu’il est développé aujourd’hui.
J’y annote les écarts à corriger, comme par exemple un libellé différent des nouvelles maquettes ou une information manquante.
Résultat
La refonte couvre tout le parcours. Elle est prête et attend sa mise en production.
Signaler une erreurSujet 2
Un deuxième sujet, côté client cette fois. Après sa souscription, le client reçoit un e-mail l’invitant à vérifier le récapitulatif de son étude, puis à déposer ses pièces justificatives.
Jusque-là, si une information de ce récapitulatif était fausse, le client n’avait aucun moyen de le dire dans l’interface : il devait contacter son conseiller par un autre canal. Des remontées ont conduit à créer un signalement directement en ligne.
Comment permettre au client de signaler une ou plusieurs erreurs, en un seul envoi, quand seul son conseiller peut les corriger ?
Les contraintes
- Contrainte 1
- Signaler, pas modifierLe client ne corrige rien lui-même : c’est son conseiller qui s’en charge.
- Contrainte 2
- Un récapitulatif longLe client doit pouvoir dire précisément ce qui est faux.
- Contrainte 3
- Un seul envoiS’il y a plusieurs erreurs, toutes doivent partir en même temps afin de ne pas spammer le conseiller.
Wireframes écartés
Deux premières pistes, explorées sur FigJam puis mises de côté, car chacune règle une partie du problème, mais aucune n’y répond entièrement.
Piste A
Signaler section par section
Chaque section du récapitulatif a son bouton « Signaler une erreur » ; le client décrit l’erreur dans la section, puis envoie l’ensemble grâce au bouton « Envoyer mes signalements » du footer.
Pourquoi je l’ai tentée
- On signale l’erreur au moment où on la voit.
- C’est simple et rapide : le bouton est sur la section concernée, à portée de main.
Pourquoi je l’ai écartée
- Le client doit valider deux fois : d’abord dans la section, avec « Valider et enregistrer », puis avec le bouton final « Envoyer mes signalements ». Peu pratique, et contraire à une règle de base : une action, une seule validation.
- La page s’allonge à chaque signalement.
Piste B
Un espace spécialement dédié aux signalements en fin de page
Pour répondre aux défauts de la piste A, la double validation et la page qui s’allonge, je rassemble tout en un seul endroit. Une seule card « Mes signalements », en fin de relecture : le client y liste ses erreurs (une catégorie et une description chacune), confirme, et tout part en un seul envoi.
1Le client liste ses erreurs : il choisit la catégorie grâce au dropdown et décrit la bonne valeur pour chacune.
2La pop-up apparaît et indique qu’un seul envoi est possible.
3Ses signalements sont transmis, et il en retrouve le récapitulatif.
4Il peut ensuite déposer ses pièces justificatives ; ses signalements restent consultables.
Pourquoi je l’ai tentée
- Un seul envoi, une confirmation avant, et un récapitulatif des signalements à la fin.
Pourquoi je l’ai écartée
- Le client doit retenir ses erreurs pour les signaler à la fin.
- Il doit aussi tout redécrire : pour chaque erreur, choisir la catégorie dans une liste et retaper l’information, alors qu’il l’avait sous les yeux en lisant le récapitulatif. Double effort, loin de l’endroit où il a vu l’erreur.
Une première version validée
Le meilleur des deux pistes.
- Un seul point d’entrée en fin de page et un seul envoi, comme la piste B.
- Les catégories sont listées d’emblée : le client coche celle qui le concerne, décrit l’erreur, en ajoute d’autres ou les supprime.
- Le tout tient dans une modale : la page ne s’allonge plus.
Un atelier pour aller plus loin
Pour pousser le contenu de la modale et challenger la première version validée, j’ai animé un atelier avec deux autres designers. Le matin, chacun explore seul ; l’après-midi, chacun présente ses propositions et leur intention, on met en commun, et on décide ensemble de ce qu’on garde.
- Le contenu : 2 ou 3 structures vraiment différentes pour signaler une erreur dans le profil du contrat, les bénéficiaires et l’allocation.
- La navigation : 2 ou 3 alternatives aux onglets, sans retirer d’information.
- Le critère : chaque proposition se comprend en moins d’une minute, sans explication orale, avec une intention claire.
La version retenue
Après l’atelier, la version retenue va au plus direct : une card « Mes signalements » en bas du récapitulatif, sans modale.
Elle répond aux trois contraintes avec le moins d’effort pour le client : il signale sans rien modifier, il n’a pas à pointer chaque ligne, et tout part en un seul envoi.
- Le client coche les catégories incorrectes, toutes visibles d’un coup.
- Il ajoute un commentaire s’il le souhaite, replié par défaut.
- Il envoie tout en une fois, et un message lui confirme que son conseiller va le recontacter.
- S’il envoie sans rien cocher, un message lui demande de sélectionner au moins une catégorie.
Le parcours a été développé.
