Tous les projets
Purse · 2024 — 6 mois

Réconciliation des paiements

Un espace de rapprochement pour des équipes finance qui associaient à la main, fichier par fichier, les virements bancaires aux transactions.

Purse — espace de réconciliation des paiements
Rôle
Seul Product Designer : recherche, parcours, UI, design system, co-conception de l’API
Équipe
1 PM, backend, un data engineer
Utilisateurs
Comptables et équipes finance des marchands
Périmètre
Web app, contrat d’API, tableaux à forte densité
En bref

Chaque semaine, les comptables reconstruisaient dans des tableurs le lien entre les reversements et les transactions. Le PM avait inscrit le sujet à la roadmap avec une solution qu’il avait déjà construite ailleurs. Mes entretiens ont révélé un autre besoin : voir d’abord le taux de rapprochement, et où il bloque. J’ai conçu l’espace de travail, et co-conçu l’API qui le porte, autour de ce besoin.

  • ~6 hgagnées par semaine et par équipe finance
  • 100 %des clients ont adopté l’outil
  • 0rapprochement encore traité hors du produit
Contexte

Le rapprochement vivait en dehors du produit

Purse gérait les paiements mais s’arrêtait au reversement. Tout ce qui venait ensuite, prouver qu’un virement correspondait à un ensemble précis de transactions, se passait dans les tableurs du client. Les équipes finance nous l’ont dit sans détour : c’était la partie la plus fastidieuse de leur mois.

Le problème

Les équipes finance devaient rassembler des fichiers issus de plusieurs sources, puis deviner quel virement correspondait à quelles transactions.

  • Des données éparpillées entre relevés bancaires, exports et dashboard, sans identifiant commun.
  • Un rapprochement manuel, donc des erreurs découvertes des semaines plus tard, à la clôture.
  • Aucune traçabilité : personne ne pouvait expliquer comment un rapprochement passé avait été décidé.
Ma démarche

Partir des fichiers réels, pas de la solution connue

  1. Entretiens

    Avec des comptables et des responsables finance, sur leurs vrais fichiers de fin de mois. Leur première question n’était jamais « ce virement correspond-il ? », mais « combien me reste-t-il à rapprocher ? ».

  2. Cartographie du parcours

    Le rapprochement se cassait chez les partenaires de paiement, chacun envoyant ses reversements à son format. D’où l’idée d’une vue par partenaire.

  3. Prototype et tests

    La solution prévue et la mienne, testées avec les mêmes utilisateurs. Les résultats ont servi d’argument face au PM.

  4. Co-conception de l’API

    Règles de rapprochement et payload définis avec les devs, pour livrer l’UI et l’API ensemble.

Arbitrages

Les choix qui ont façonné le produit

Que doit voir un comptable en premier ?

Le taux de rapprochement, directement dans le tableau

J’ai placé le taux de rapprochement dans le grand livre, avec la répartition par partenaire de paiement mise en avant. Le comptable voit en un coup d’œil où ça bloque, avant d’ouvrir une seule ligne.

Ce qui a tranché : les entretiens. Chaque équipe finance commençait sa journée par la même question : combien reste-t-il à rapprocher, et chez quel partenaire ?

Écarté : La solution que le PM avait construite dans une expérience précédente : une liste de virements à traiter un par un, sans vue d’ensemble.

Jusqu’où automatiser ?

Suggérer le rapprochement, jamais le décider

Le système propose un rapprochement avec un niveau de confiance et ses raisons ; le comptable confirme.

Ce qui a tranché : une erreur découverte à la clôture coûte des heures, une validation coûte un clic. La confiance est venue du raisonnement montré, pas caché.

Écarté : Le rapprochement entièrement automatique, plus rapide sur le papier.

Une ligne à la fois, ou beaucoup ?

Un grand livre dense plutôt qu’une revue carte par carte

Beaucoup de lignes à la fois, avec tris et totaux visibles, plutôt qu’un élément par écran.

Ce qui a tranché : les utilisateurs finance comparent des lignes entre elles. En test, les utilisateurs quotidiens rejetaient la revue carte par carte.

Écarté : Une file de revue sous forme de cartes, bien reçue par les nouveaux utilisateurs seulement.

Convaincre

Faire évoluer une solution déjà décidée

Le PM avait inscrit le rapprochement à la roadmap avec une idée précise : reprendre la fonctionnalité qu’il avait construite dans une expérience précédente. Elle répondait aux besoins d’un autre produit, pas à ceux de nos clients.

Plutôt que d’opposer mon avis au sien, j’ai apporté des preuves : les verbatims des entretiens, puis un prototype testé à côté de sa version. Le sujet est resté sur sa roadmap, et c’est la version issue de la recherche qui a été livrée.

Ce que j’ai entendu en entretien

  • Le matin, je veux savoir combien il me reste à rapprocher. Le détail, je le regarde après.

    Comptable, marchand e-commerce

  • Quand ça bloque, c’est presque toujours chez le même partenaire. Je veux le voir tout de suite.

    Responsable finance

  • Je passe presque une journée par semaine dans mes fichiers à retrouver qui a payé quoi.

    Comptable

Résultat : la fonctionnalité prévue est restée sur la roadmap, repensée autour du taux de rapprochement et de la vue par partenaire.

Impact

Tous les clients ont rapatrié leur rapprochement

L’espace de travail a entièrement remplacé l’étape tableur. Toute la base clients l’a adopté, et les équipes finance ont récupéré environ 6 heures par semaine, du temps qui partait dans le rapprochement ligne à ligne.

Temps mesuré avec les équipes finance pendant les entretiens, avant et après le lancement ; chiffres arrondis et anonymisés.

  • Temps gagné par semaine et par équipe finance~6 h
  • Adoption par les clients100 %
  • Rapprochements traités hors du produit0
Ce que j’en retiens

Les utilisateurs finance ne veulent pas d’automatisation. Ils veulent un outil qui montre son raisonnement et les laisse assumer la dernière étape.

Ce que je ferais différemment : intégrer le data engineer aux entretiens dès la première semaine. La moitié de nos contraintes de design étaient des contraintes de données, découvertes trop tard.