Articles liés

La newsletter française des développeurs Ruby on Rails. Retrouve du contenu similaire gratuitement tous les mois dans ta boîte mail !
S'inscrire
Partager :
Blog
>

Faut-il une app mobile native pour une plateforme d'investissement ?

Ce que les usages disent quand on les regarde vraiment

Sur les plateformes PSFP et de crowdfunding qu'on suit chez Capsens, deux constats reviennent avec une régularité qui n'admet plus vraiment de doute.

La souscription se fait principalement sur ordinateur. Entre soixante et soixante-quinze pour cent des montants engagés le sont sur desktop, pas sur smartphone. La raison est logique quand on la regarde de près : souscrire à un fonds d'investissement implique de signer électroniquement, de fournir un RIB, de lire un document d'information clé, de remplir un test d'adéquation. Ce sont des tâches qui demandent de la concentration et un vrai écran. Les faire sur un téléphone est possible mais inconfortable, et les investisseurs sérieux préfèrent ouvrir leur ordinateur pour ces moments-là.

Le suivi post-souscription, en revanche, se fait majoritairement sur mobile. Entre soixante et quatre-vingts pour cent des consultations d'un compte investisseur après la souscription se font sur smartphone, sur des sessions courtes, à des moments de pause dans la journée. L'investisseur veut jeter un œil à ses positions dans les transports, vérifier une notification pendant une réunion, lire un rapport d'un projet en attendant un rendez-vous. Ces usages sont naturellement mobiles.

Cette répartition change complètement l'analyse. Ce qui compte vraiment, ce n'est pas "avoir une app" — c'est "avoir une expérience mobile fluide là où les usages mobiles sont dominants". Et cette exigence peut se traiter de plusieurs façons, dont l'app native n'est qu'une parmi d'autres.

Trois options qui ne coûtent pas la même chose

Il y a en réalité trois voies possibles pour couvrir la dimension mobile d'une plateforme d'investissement, et chacune a son économie propre.

Le site responsive est la voie standard. Une seule base de code — le site web — qui s'adapte à toutes les tailles d'écran. Bien conçu, il offre une expérience mobile parfaitement correcte sur cent pour cent des parcours utilisateur. Coût marginal : compris dans le développement web initial. Limites : pas d'icône sur l'écran d'accueil du téléphone, pas de notifications push natives sur iOS pour l'instant, et pas d'accès à certaines APIs hardware comme la caméra pour un KYC mobile ou la biométrie pour la connexion. Ces limites sont réelles mais gérables pour la plupart des plateformes.

La PWA — Progressive Web App — est une voie intermédiaire de plus en plus intéressante. C'est un site web amélioré qui se comporte comme une app : icône installable sur l'écran d'accueil, fonctionnement hors ligne sur les pages déjà visitées, notifications push disponibles sur Android depuis longtemps et sur iOS depuis iOS 16.4 sous condition d'installation, accès à certaines APIs natives. Le coût additionnel pour transformer un site responsive en PWA propre se situe entre cinq et quinze mille euros. Les limites qui subsistent : sur iOS, l'expérience reste légèrement dégradée par rapport à une app native, et la PWA n'est pas distribuée sur les stores officiels, ce qui prive la plateforme d'un canal de découverte pour les utilisateurs qui cherchent une app dans l'App Store.

L'app native iOS et Android est la voie la plus complète mais aussi la plus coûteuse. Deux applications développées soit en natif — Swift pour iOS, Kotlin pour Android —, soit en cross-platform via React Native ou Flutter. Le coût d'une V1 démarre autour de soixante mille euros hors taxes et peut monter à cent cinquante mille selon la complexité fonctionnelle et le degré de duplication des parcours web. La maintenance représente cinq cents à mille cinq cents euros par mois, essentiellement pour absorber les mises à jour des systèmes d'exploitation, les soumissions aux stores et la gestion des SDK tiers. L'avantage : une expérience native fluide, une présence sur les stores qui envoie un signal de maturité, et l'accès complet à tous les APIs du téléphone.

Les critères qui font pencher vers le natif

L'app native n'est pas un mauvais investissement en soi, mais c'est un investissement qui doit être justifié par des critères précis. Plusieurs facteurs, quand ils se cumulent, basculent la balance en sa faveur.

Le volume d'utilisateurs actifs est le premier critère à regarder. En dessous de dix mille investisseurs actifs sur la plateforme, le coût par utilisateur d'une app native reste élevé et l'investissement s'amortit lentement. Au-delà, il commence à faire sens : chaque euro dépensé sur l'app se répartit sur une base plus large, et le confort d'usage se répercute sur davantage de sessions.

La fréquence d'usage compte tout autant. Si les utilisateurs reviennent quotidiennement — plateformes de trading, suivi de cours en temps réel, micro-investissement de type Yomoni, Cashbee ou Mon Petit Placement —, l'app native apporte un confort qui justifie clairement l'investissement. Pour une plateforme de crowdfunding immobilier où l'investisseur revient une fois par mois pour vérifier ses projets, le ratio coût-bénéfice est beaucoup moins évident, et la PWA suffit souvent.

Le profil de la cible pèse aussi. Une clientèle jeune, digital native, s'attend à trouver une app dans les stores. Son absence est parfois perçue comme un signal de retard de la marque. Pour une cible CGP ou patrimoniale plus mature, le site desktop reste le canal de référence et l'app n'apporte que peu de valeur perçue.

La stratégie d'engagement peut faire basculer la décision. Si on construit sa rétention sur les notifications push — alerte nouveau projet, alerte fin de collecte, alerte versement de coupons —, l'app native maximise le taux d'opt-in et la délivrabilité par rapport au web. Sur ces cas d'usage, l'écart de performance est significatif.

Enfin, l'app peut devenir un actif produit si elle porte des fonctionnalités exclusives : caméra pour scanner une pièce d'identité au moment du KYC, biométrie pour la connexion rapide, paiement via Apple Pay ou Google Pay, widgets sur l'écran d'accueil qui affichent le rendement du portefeuille. À ce moment-là, l'app n'est plus un canal de plus mais un vrai différentiateur produit.

Le coût réel qu'on sous-estime souvent

Le ticket d'entrée d'une app native n'est qu'une partie de la facture, et probablement pas la plus lourde sur la durée. Une app native génère plusieurs postes récurrents qu'on sous-estime régulièrement au moment de la décision initiale.

Les mises à jour des systèmes d'exploitation reviennent chaque année. Apple et Google publient des versions majeures d'iOS et d'Android tous les douze à quatorze mois. Chaque mise à jour impose des tests, parfois des refontes partielles — passage à SwiftUI côté Apple, adoption de Material You côté Google, support des nouvelles tailles d'écran, gestion des nouvelles règles de confidentialité. Compter dix à vingt jours de développement par an rien que pour maintenir la compatibilité, soit cinq à douze mille euros annuels.

Les soumissions et conformité aux stores prennent aussi du temps. Apple applique des règles changeantes via ses App Store Review Guidelines, avec des refus possibles à chaque mise à jour publiée. Google est un peu plus souple mais impose ses propres contraintes. Compter un à trois jours de gestion pour chaque mise à jour poussée en production, avec parfois des allers-retours pour justifier une fonctionnalité qui a provoqué un doute chez le reviewer.

Les SDK tiers vieillissent et se remplacent. KYC, paiement, analytics, crash reporting — chaque SDK intégré doit être maintenu, mis à jour, parfois remplacé par une alternative quand l'éditeur d'origine change sa politique commerciale ou disparaît. C'est un travail invisible mais permanent.

Les comptes développeur sont marginaux mais à budgéter — quatre-vingt-dix-neuf euros par an pour Apple, vingt-cinq euros en frais unique pour Google. Rien qui puisse changer une décision, mais des lignes à prévoir.

Au total, le coût de possession sur trois ans d'une app native iOS et Android atteint typiquement cent à deux cents mille euros, soit deux à trois fois le coût de la V1 initiale. C'est ce chiffre qu'il faut avoir en tête au moment de trancher, pas le seul ticket d'entrée.

La voie médiane que beaucoup empruntent

Pour la majorité des plateformes d'investissement en V1 et V2, la PWA constitue le bon compromis. Elle apporte soixante-dix à quatre-vingts pour cent de l'expérience d'une app native pour dix à vingt pour cent du coût, sans créer de dépendance aux stores et sans démultiplier les chantiers de maintenance. Elle permet aussi, chose importante, de mesurer le comportement réel de l'audience mobile avant de décider d'investir dans une vraie app.

Beaucoup de plateformes qu'on accompagne suivent une trajectoire en trois temps. Site responsive en V1, quand la priorité est de valider le marché et de démarrer les collectes. Bascule en PWA en V2 quand la plateforme dépasse mille utilisateurs actifs et que les usages mobiles se dessinent clairement. App native en V3 seulement quand le volume, la fréquence d'usage et le profil de cible justifient vraiment l'investissement.

Cette trajectoire n'est pas la seule possible, mais elle est probablement la plus rationnelle économiquement pour la plupart des projets. Elle aligne l'investissement mobile sur la maturité réelle de la plateforme, plutôt que de partir sur une hypothèse d'usage qui ne s'est pas encore vérifiée.

Pour finir

L'app mobile native n'est presque jamais la bonne réponse en V1. Elle devient pertinente sur des critères précis — volume, fréquence d'usage, profil de cible, stratégie d'engagement — qui s'observent typiquement après dix-huit à trente-six mois d'exploitation. Avant ça, un site responsive bien soigné, éventuellement complété par une PWA quand les usages mobiles se confirment, couvre l'essentiel des besoins pour une fraction du coût.

Le meilleur conseil qu'on puisse donner à un fondateur qui se pose la question, c'est probablement de ne pas la trancher trop tôt. Attendre d'avoir des données réelles sur l'usage de sa plateforme, mesurer les canaux qui apportent vraiment de la valeur, et prendre la décision de l'app quand elle devient évidente plutôt que quand elle paraît obligatoire. La différence entre les deux se compte en dizaines de milliers d'euros économisés et en clarté stratégique gagnée.