Tous les projets
Purse · 2026 · en cours de déploiement

Deux designers, un back office, une seule logique

Comment j’ai réorganisé le design du back office Purse : qui s’occupe de quoi, et pour quels utilisateurs.

Avant

Une seule designer sur tout le back office
Product Designer A
Capacité disponible
  • Checkout
  • SDK
  • Design system
Livré et stable
Product Designer B
  • Paiements
  • Réconciliation
  • Analytics
  • Onboarding
  • Config technique
  • Orchestration
  • Monitoring
  • Automatisations
8 fonctionnalités, des patterns qui divergent

Après

Deux designers, quatre parcours
Product Designer A
Paiement & réconciliation
  • Paiements
  • Réconciliation
Orchestration
  • Règles
  • Routage
2 parcours de bout en bout
Product Designer B
Accueil & analytics
  • Analytics
  • Monitoring
Onboarding & config
  • Onboarding
  • Config technique
  • Automatisations
2 parcours de bout en bout
Design system partagé · Revues croisées
La capacité design passe des produits stables au back office, découpé en parcours.
RÔLE
Lead Product Designer (vision, organisation d’équipe, arbitrages produit)
PÉRIMÈTRE
Le back office Purse Payment, utilisé par nos clients et nos équipes internes
ÉQUIPE
2 Product Designers, 1 PM, le Head of Product
STATUT
Validé par le Head of Product et le CPO, en cours de déploiement
En bref

Le back office est la seule partie de notre orchestration de paiement que les clients voient et utilisent. Une seule designer le portait, face à une roadmap ambitieuse et à des parcours devenus incohérents. J’ai proposé de passer à deux designers avec un découpage par parcours métier, et d’ajouter un mode interne dans le même produit plutôt que de créer un outil séparé.

  • 4parcours métier, chacun avec un designer responsable
  • 1seul produit, avec un mode client et un mode interne
  • −30 %Objectifde tickets support remontés aux devs d’ici 6 mois
Contexte

Pour nos clients, le back office est le produit

L’orchestration de paiement ne se voit pas. Ce que nos clients en perçoivent, c’est le back office. Ils y suivent leur activité, consultent le détail d’un paiement, font leur réconciliation bancaire et règlent quelques paramètres d’orchestration.

Nos équipes internes utilisent le même outil pour créer l’environnement et les entités d’un client, configurer les moyens de paiement, mettre en place des automatisations et surveiller l’activité.

Au même moment, ma charge baissait. Le Checkout et le SDK étaient livrés, le design system était stable. Sur Identity, les PM prototypent eux-mêmes avec le design system, et nous faisons des revues de parcours.

TROIS SIGNAUX M’ONT ALERTÉ
  • Une roadmap qui accélère, portée par une seule designer encore junior.
  • Des parcours incohérents, chaque fonctionnalité ayant été conçue au fil de l’eau avec ses propres patterns.
  • Des retours répétés du support, de la tech et de l’intégration, qui travaillaient avec un outil pensé pour d’autres.
Le problème

La capacité design était concentrée sur les produits déjà stables, et absente du produit le plus visible.

Décision 1

Découper le back office par parcours métier

Passer à deux designers ne suffisait pas. Il fallait choisir comment se répartir le back office, et plusieurs découpages étaient possibles.

DécoupageCohérence UXRéutilisation des patternsExpertise métierVue d’ensembleScore
Par personaDeux écrans pour un même objet2/8
Par produitSurdimensionné pour Identity3/8
Par fonctionnalitéChacun enfermé dans ses écrans1/8
Par parcours métierRetenuUn expert par parcours complet8/8

  • Par persona (client ou interne)

    Écarté

    Le support, le client et l’intégrateur regardent les mêmes objets : un paiement, une entité, une règle d’orchestration. Les séparer obligerait à concevoir deux fois le même écran, avec deux langages visuels qui finissent par diverger. Le support perdrait aussi ce qui lui fait gagner du temps : voir exactement ce que voit le client.

  • Par produit (Payment ou Identity)

    Écarté

    Identity est mature et autonome, avec moins d’enjeux et moins de charge. Y affecter un designer serait surdimensionné. La priorité y est d’abord de mesurer l’usage pour comprendre les parcours réels.

  • Par fonctionnalité

    Écarté

    Trop fin. Chaque designer s’enferme dans quelques écrans et perd la vue d’ensemble.

  • Par parcours métier

    Retenu

    Chaque designer devient expert d’un parcours complet, qui traverse plusieurs fonctionnalités clés, pour tous les profils qui l’empruntent.

Ce découpage s’appuie sur la user journey map du back office.

  • Onboarding & configuration techniqueProduct Designer B
    • Support
    • Dev / intégrateur
    1. Créer l’entité
    2. Configurer l’environnement
    3. Activer les moyens de paiement
    4. Mettre en place les automatisations
  • OrchestrationProduct Designer A
    • Client
    • Support
    • Dev / intégrateur
    1. Définir les règles
    2. Router les paiements
    3. Gérer les fallbacks
  • Paiement & réconciliationProduct Designer A
    • Client
    • Support
    1. Suivre un paiement
    2. Consulter le détail
    3. Réconcilier avec la banque
  • Accueil & analyticsProduct Designer B
    • Client
    • Support
    1. Vue d’ensemble
    2. Analyser l’activité
    3. Monitoring
Un moyen de paiement activé à l’onboarding est routé par l’orchestration, puis consulté dans le détail du paiement. Les parcours se croisent, mais chacun garde son responsable.

Les frontières restent volontairement souples, car un parcours en croise toujours un autre. Deux garde-fous évitent que les deux moitiés dérivent :

  • Un design system partagé, auquel chacun contribue et que personne ne garde pour soi.
  • Des revues croisées, où chaque parcours est relu par l’autre designer avant le développement.
Paiement & réconciliation
Product Designer A
Orchestration
Product Designer A
Accueil & analytics
Product Designer B
Onboarding & configuration technique
Product Designer B
Décision 2

Un mode interne dans le même back office

Nos équipes ne raisonnent pas comme nos clients. Un marchand part d’un besoin : suivre ses paiements, faire sa réconciliation, analyser son activité. Nous partons d’une entité et de sa configuration. Mêmes données, autre modèle mental, donc autre navigation.

Pour trancher, j’ai mené des entretiens avec les équipes internes et étudié d’autres outils du marché. Résultat :

  • Mode marchand : navigation par fonctionnalité

    C’est le standard des back offices de paiement, que nos clients connaissent déjà.

  • Mode interne : navigation par entité

    On choisit d’abord le client et l’entité. Tout le reste en découle : configuration, moyens de paiement, monitoring, paiements.

Choix assumé : ne pas innover côté marchand

J’ai écarté l’idée de réinventer la navigation pour se démarquer. Nos clients utilisent déjà d’autres outils de paiement, et chaque écart au standard leur demande un effort d’apprentissage sans bénéfice en retour. J’ai gardé l’innovation pour le mode interne, où aucun standard ne correspondait à notre façon de travailler.

Écarté : une navigation sur mesure côté marchand, plus originale en démo mais plus coûteuse à apprendre au quotidien.

Entretiens internes et benchmark des outils du marché
MODE MARCHAND

Par fonctionnalité

Le standard du marché« Où en sont mes paiements ? »
  • Accueil
  • Paiements
  • Réconciliation
  • Analytics
  • Orchestration
  • Paramètres
  • 1 niveau
  • 1 entrée par besoin
MODE INTERNE

Par entité

Issu des entretiens internes« Que se passe-t-il chez ce client ? »
CLIENT
Client A
ENTITÉ
Entité FR
  • Environnement
  • Moyens de paiement · config technique
  • Règles d’orchestration
  • Automatisations
  • Monitoring & logs
  • Paiements de l’entité
  • 2 niveaux
  • Tout part de l’entité
Même API · Même environnement · Même version

Deux options étaient sur la table :

  • Un back office interne séparé

    Écarté

    Deux produits, donc deux codebases à maintenir, deux versions qui divergent, et un support qui ne voit plus ce que voit le client.

  • Un mode interne dans le même produit

    Retenu

    Même environnement, même API, même version. Seule l’expérience change : la navigation part de l’entité, l’interface est plus dense, et des données et actions supplémentaires apparaissent pour les admins, le support, les devs et les intégrateurs.

VUE CLIENTConsulter
1 240,00 €Capturé
Moyen de paiement
Carte •••• 4242
Client final
j.martin@exemple.fr
Chronologie
  1. Créé
  2. Autorisé
  3. Capturé
Rembourser
VUE INTERNEConfigurer et diagnostiquer
1 240,00 €Capturé
Moyen de paiement, client final, chronologieidentiques à la vue client
RoutageVisible selon le rôle
PSP utilisé
PSP A
Règle appliquée
Règle 12 · fallback carte
Réponse brute du PSPVisible selon le rôle
{ "status": "captured", "psp_code": "00", … }
Identifiants techniquesVisible selon le rôle
Entité
ent_8F2K
Transaction
txn_51QX
Historique des webhooksVisible selon le rôle
payment.authorized
500 · rejoué
payment.captured
200
Rejouer le webhookVoir la configuration de l’entité
Même paiement, même écran. Le mode interne reprend la vue client et y ajoute des blocs techniques, affichés selon le rôle.

Ce mode m’a obligé à trancher quatre questions :

  • Rôles et permissions

    Qui voit le mode interne, et qui peut agir.

  • Niveau de détail

    Ce qui aide le client dans un paiement, et ce qui ne sert qu’en interne.

  • Navigation

    Par entité en interne, par fonctionnalité côté marchand.

  • Actions principales

    Consulter côté client, configurer et diagnostiquer côté interne.

Convaincre

Présenter le projet comme un enjeu business

J’ai défendu ce projet sur le terrain du business. Le back office est la vitrine de notre produit, ce que nos clients achètent sans le savoir, et c’est là que la capacité design manquait. Le Head of Product puis le CPO l’ont validé.

Impact

Ce que nous allons mesurer

Premier effet constaté par l’équipe : nous livrons mieux et plus vite. Le déploiement continue, et ces chiffres restent des objectifs, pas encore des résultats.

  • Écrans conformes au design system
    Objectif à 6 mois
  • Tickets support remontés aux devs
    Objectif à 6 mois
  • Temps pour configurer un nouveau client (entité et moyens de paiement)
    Objectif à 6 mois
  • Satisfaction sur le back office (score SUS)
    Objectif à 6 mois
  • Composants partagés entre les modes client et interne
    Objectif à 6 mois
Ce que j’en retiens

L’idée me trottait dans la tête depuis mon arrivée chez Purse. Ce sont mes échanges réguliers avec les équipes qui m’ont donné les arguments pour la défendre.

Ce que je ferais différemment : lancer le sujet plus tôt. Mon intuition était bonne, mais j’aurais dû documenter les premiers signaux dès le départ pour convaincre plus vite.