Photo de Fabian Blank sur Unsplash
Dans le secteur des technologies financières, il arrive souvent que le parcours de l'utilisateur implique de traiter des paiements bancaires. Il peut s'agir de recharger un portefeuille électronique, de réaliser un investissement ou de payer une facture.
Lorsque le montant est supérieur à 2 500 €, le moyen de paiement privilégié est le virement bancaire.
Cet article étudie un cas de base de parcours utilisateur impliquant un paiement par virement bancaire (SEPA) et explore les moyens de l'améliorer.
Note : Cet article est le premier d'une nouvelle série intitulée Fintechs' crumbs qui explore le parcours web des fintechs.
1. Le cas d'utilisation
Prenons une fintech aléatoire et imaginaire appelée SmartFintek. Sur SmartFintek, les utilisateurs peuvent recharger leur porte-monnaie électronique. Le porte-monnaie électronique n'est utilisé que pour les transactions importantes et le seul moyen de paiement autorisé est le câble bancaire SEPA.
Une page de base pour "recharger votre porte-monnaie électronique" (web)
Le processus de rechargement est essentiellement le suivant :
1. L'utilisateur se connecte à SmartFintek
2. L'utilisateur va dans son portefeuille et choisit "Recharge".
3. L'utilisateur reçoit un IBAN et un BIC liés à son porte-monnaie électronique.
4. L'utilisateur effectue le paiement auprès de sa banque
5. L'utilisateur reçoit l'argent sur son porte-monnaie électronique SmartFinteck.
Comme nous pouvons le voir, il s'agit d'un parcours utilisateur très basique que vous avez peut-être expérimenté ou mis en place pour vos utilisateurs si vous possédez une fintech. Maintenant, nous allons chercher des données précises sur la façon dont les utilisateurs finaux vivent réellement ce parcours.
Il y a deux questions principales que nous devons nous poser :
Quel est le type d'appareil le plus utilisé pour ce parcours utilisateur ?
Comment l'utilisateur effectue-t-il le paiement ?
Photo de Jessica Lewis sur Unsplash
Quel est le type d'appareil le plus utilisé pour ce parcours utilisateur ?
un graphique de répartition de l'utilisation d'un dispositif web typique pour les Fintechs (réalisé avec AM charts)
Si nous nous rendons sur Google Analytics, voici ce que nous pouvons voir sur la répartition des appareils de nos utilisateurs. Chez CapSens, nous travaillons avec de nombreuses fintechs et ces statistiques sont représentatives du secteur : près de 2 tiers sur ordinateur, 1 tiers sur mobile et 5 à 7% sur tablette.
Sur la base de ce graphique, on pourrait se dire : "Ok, nous avons notre réponse. Les deux tiers des utilisateurs effectueront la recharge sur leur ordinateur de bureau et l'autre tiers sur leur mobile". Pas tout à fait.
La répartition ci-dessus est une moyenne pour tous les visiteurs du site web et pour toutes les pages, y compris la page d'accueil et les autres pages de contenu. Si nous voulons des données précises sur la répartition des appareils pour le processus de rechargement, nous devons creuser un peu plus.
un graphique de répartition de l'utilisation d'un dispositif web typique des pages connectées pour les Fintechs (réalisé avec AM charts)
Ce graphique montre maintenant la répartition de l'utilisation des appareils pour les pages accessibles lors de la connexion (toutes les pages imbriquées dans /compte par exemple). Nous voyons clairement que l'ordinateur de bureau est maintenant très dominant avec près de 80% de l'utilisation totale et que les appareils mobiles ne représentent que moins de 20% de l'utilisation totale, les tablettes d'autre part sont presque insignifiantes avec moins de 4%.
Nous avons donc un parcours utilisateur qui se déroule principalement sur des appareils de bureau. Concentrons-nous maintenant sur le paiement lui-même.
Comment l'utilisateur effectue-t-il le paiement ?
Pour effectuer le virement bancaire, nos utilisateurs ont trois possibilités :
Utiliser leur site web bancaire => desktop
Utiliser leur application bancaire mobile => mobile
Utiliser un distributeur automatique
(oui, cela existe) => ? ??
Tout d'abord, la réponse à cette question peut dépendre de l'âge de notre public. Analytics fournit-il ces données ? Oui, il le fait :
Graphique des sessions par âge (réalisé avec AM charts)
Le graphique ci-dessus nous montre la proportion de sessions par tranche d'âge. Nous pouvons voir que les visiteurs de 25 à 34 ans représentent plus de 30% du total des sessions.
Hum ... c'est bien mais pas assez. Voyons si nous pouvons creuser un peu plus avec ces données.
Graphique cumulatif des sessions par âge (réalisé avec AM charts)
Le graphique ci-dessus est cumulatif, c'est-à-dire qu'il nous donne la proportion de sessions provenant de visiteurs nés avant une certaine date.
Le guide rouge est là pour souligner le fait que 80% des visiteurs sont nés avant 1966.
Sur la base de cette statistique, nous pouvons maintenant rechercher des données sur le comportement des personnes âgées de moins de 54 ans : se rendent-elles à un distributeur automatique, utilisent-elles leur ordinateur ou leur application bancaire mobile?
Selon la cinquième édition de la célèbre étude de Deloitte (l'un des "Big Four") "Les Français et les nouveaux services financiers" :
Comment les Français effectuent les paiements par virement bancaire selon la 5ème édition de l'ouvrage “Les Français et les nouveaux services financiers” de Deloitte (graphique réalisé avec AM charts)
Comme prévu, il n'y a que trois façons d'effectuer un virement bancaire, mais la plus utilisée est l'application bancaire mobile, qui représente 43 % du total. Vient ensuite le site web de la banque (35 %) et enfin, mais ce n'est pas le moins surprenant, le guichet automatique ou l'agence (17 %).
Voyons maintenant ce que ce cas le plus courant induit pour le parcours de l'utilisateur.
Parcours de l'utilisateur avec une application bancaire mobile réalisée par transfert bancaire
Comme nous l'avons vu précédemment dans cet article, ce parcours utilisateur est le scénario le plus courant :
L'utilisateur obtient les coordonnées bancaires (IBAN et BIC) sur son ordinateur.
L'utilisateur utilise son smartphone pour ajouter le nouveau bénéficiaire (si c'est la première fois) et lancer le virement bancaire.
Le parcours de l'utilisateur n'est pas homogène ; l'utilisateur passe du bureau au mobile pour effectuer le virement bancaire. Nous avons donc une rupture dans le flux.
Parcours de l'utilisateur avec une application de banque mobile effectuant un virement bancaire
Partant de ce constat, nous pouvons maintenant nous demander : comment rendre ce parcours utilisateur le plus facile possible pour l'utilisateur final ? Explorons quelques pistes.
Taper manuellement l'IBAN et le BIC
Si vous n'avez pas pris de mesure particulière pour le flux de rechargement, c'est ce que font 43% de vos utilisateurs. Je l'ai fait plusieurs fois : vous lisez l'IBAN et le BIC sur l'écran de votre ordinateur et vous tapez chaque caractère un par un sur votre smartphone. Un IBAN peut comporter jusqu'à 34 caractères. Hew !
D'accord, nous avons tous survécu à cette expérience, mais ce n'est pas ce que nous pouvons appeler une bonne UX. Voyons si nous pouvons trouver une meilleure solution.
Envoyer les coordonnées par courrier électronique
Pour éviter que l'utilisateur n'ait à saisir manuellement l'IBAN et le BIC, une solution pourrait être d'envoyer les coordonnées par courrier électronique à l'utilisateur afin qu'il puisse les copier et les coller dans son application bancaire mobile.
Cela semble correct, mais pas vraiment terrible. La réception de l'e-mail pourrait poser problème. Les courriels transactionnels sont souvent retardés, finissent dans le dossier spam ou n'arrivent pas du tout à destination.
Codes QR EPC
Ces QR Codes peuvent être utilisés pour initier un virement SEPA. Ils sont définis par le Conseil européen des paiements. En gros, vous recevez un QR code et lorsque vous le scanner avec votre application de banque mobile, le virement bancaire est créé, il vous suffit de vérifier son bénéficiaire et son montant et en un clic vous avez initié le virement bancaire. Génial, non ?
Malheureusement, il y a un gros problème : seuls quelques pays européens le supportent : Autriche, Belgique, Finlande, Allemagne, Pays-Bas. Donc, à moins que vos utilisateurs soient situés dans l'un de ces pays, pas de QR Codes EPC pour vous !
Permettre à l'utilisateur d'accéder à la page avec son smartphone
Une autre solution pourrait être de permettre à l'utilisateur d'accéder à la page depuis son smartphone. L'inconvénient majeur de cette solution est l'authentification : l'utilisateur pourrait être réticent à reproduire son parcours sur un autre terminal :
Aller sur le site
S'identifier
Accéder à son compte puis à la page "recharger son portefeuille".
Cela fait beaucoup d'étapes juste pour éviter de devoir taper manuellement 45 caractères (34 + 11). Mais ne pouvons-nous pas trouver une solution pour rendre cela plus rapide ?
Nous avons un utilisateur déjà connecté sur son ordinateur et nous avons un smartphone.
Que pouvons-nous faire ?
Une solution pourrait être de mettre en place un code QR contenant une URL directe vers cette page. L'utilisateur n'aurait qu'à le scanner avec l'appareil photo de son smartphone et serait automatiquement redirigé vers la même page sur son mobile.
Attendez. Quoi ? Sans authentification ?
La page à laquelle on accède avec le code QR ne contiendrait que l'IBAN et le BIC. Ce ne sont pas des données sensibles. Ne les voyez-vous pas sur chaque facture ? De plus, le lien pourrait être sécurisé par un jeton afin de garantir que ces données ne puissent être consultées sans connaître le jeton. Enfin, le jeton pourrait être suffisamment fort pour qu'il soit difficile de le forcer.
Essayons de mettre en place cette fonctionnalité.
1. L'utilisateur peut afficher un code QR en cliquant sur un lien "voir ces informations sur votre téléphone portable".
Le lien ne doit pas être affiché sur les tablettes et les mobiles sinon ce serait bizarre. Dans ma solution, un clic sur le lien affiche une modale avec QR Code mais il y a plein d'autres solutions (onglets, collapsing content...).
La page "Créditer mon porte-monnaie SmartFintek" avec le lien ajouté
2. L'utilisateur reçoit le code QR
Ici, le code QR est généré côté serveur. Pour ce faire, il existe de nombreuses API disponibles, comme l'API Google Chart (récemment dépréciée). Pour cet article, j'ai codé le site web en Ruby on Rails, donc j'ai utilisé une gemme rQRCode qui est très simple.
La gemme permet de choisir si la sortie doit être un .png ou un .svg. A mon avis, le .svg permet un rendu plus précis (pas de pixellisation) et est plus léger qu'un fichier png. En plus des options, elle nécessite un contenu qui est ici un lien.
Le lien vers la page du portefeuille (version jeton)
En ce qui concerne ce lien, le processus est assez simple. Chaque utilisateur reçoit un jeton unique dans la base de données. Ce jeton est ajouté à l'URL comme paramètre (couleur verte). Lorsque quelqu'un essaie d'accéder à la page, nous vérifions si le jeton existe dans notre base de données, si c'est le cas, nous récupérons les informations sur le portefeuille et les affichons, sinon nous renvoyons une erreur 404 Not found.
Comme vous pouvez le constater, le jeton est insupportable, c'est pourquoi nous ne l'affichons jamais directement à l'utilisateur. L'URL contenant le jeton peut être trouvée uniquement en scannant le code QR.
Le code QR généré
3. L'utilisateur scanne le code QR et est redirigé vers la même page sur son téléphone portable.
Voilà, c'est fait ! Si vous êtes intéressé par l'implémentation technique, vous pouvez consulter le code complet ici (Rails 6 / Ruby 2.6.2).
Cette fonctionnalité améliore le parcours utilisateur de ceux qui utilisent une application bancaire mobile pour effectuer le virement bancaire (43% de nos utilisateurs). En revanche, cela n'aide pas les 17 % qui se rendent physiquement à un guichet automatique ou à la réception de leur banque. Une solution facile pourrait être d'implémenter un bouton "envoyer l'instruction de paiement par courrier" afin qu'ils puissent avoir les coordonnées bancaires dans leur boîte aux lettres, prêtes à être utilisées chaque fois qu'ils en auront besoin. En ce qui concerne les 35 % qui effectuent toutes les opérations sur leur ordinateur, le processus est déjà simple pour eux car il existe un bouton de copie rapide pour l'IBAN et le BIC.
Et voilà. N'hésitez pas à me faire part de vos commentaires sur la façon dont vous avez géré ce parcours utilisateur (peut-être souhaitez-vous partager une meilleure solution que vous avez trouvée).