Développement d'une application mobile, quels éléments analyser avant de se lancer ?

Même s’il est évident aujourd'hui qu’une application web doit être responsive, le point de départ de la réflexion autour d’un produit dédié mobile est souvent l’identification d’une cible intéressante, que ce soit par la présence d’un parc mobile important ou par des segments de cible spécifiques dont les usages sont majoritairement mobiles. Mais pour choisir d'investir ou non dans une solution dédiée mobile, il faut aller plus loin dans la réflexion.

Voici donc quelques éléments à prendre en compte avant de se lancer :

Comprendre les enjeux et les opportunités liés au marché

Définir la cible idéale

Pour déterminer si une cible a du potentiel sur mobile, il faut identifier :

• Un fort usage mobile et/ou tablette
• Un certain potentiel de chiffre d'affaires sur iOS malgré la commission d'Apple (les usagers d'Apple représentent un meilleur potentiel d'achat)
• Une grande importance du parcours utilisateur pour cette cible

Identifier le potentiel d'une solution purement mobile

Pour déterminer si un produit mobile dédié est réellement pertinent, on peut observer la solution web, si elle existe. En effet, si certains écrans comportent beaucoup d'informations, des cartes dans des cartes, des menus complexes, des tableaux, alors il est plus que probable que le produit responsive touche ses limites et soit générateur de bugs et de conflits de gestuelles. Si aucun équivalent web n'existe, les mêmes questions se posent vis-à-vis de la promesse utilisateur. Quel est l'obectif du produit ? Son contenu peut-il être proposé de manière adaptée et fluide aux petits écrans ?

Définir son budget

Une fois la cible identifiée et le produit estimé pertinent, vient alors la question cruciale du budget disponible pour ce produit. Cette donnée est primoridale pour déterminer quelle solution technique mettre en place, notamment entre application natives ou hybrides. Dans les applications natives, toutes les fonctionnalités sont développées dans le langage natif de la plateforme supportée. Les applications hybrides sont développées à partir d'une seule base de code et s'exécutent sur plusieurs plateformes. En effet, nous le verrons ensuite, en fonction de la solution choisie, le budget en terme de ressource varie grandement.

Les commissions de vente

Le point de friction n°1 pour proposer des applications natives iOS est le taux de commission d’Apple (30%) et l'usage obligatoire des tiers en prix de produit. On ne peut donc pas appliquer n'importe quel prix à nos produits alors que sur Android, on le peut. On a même la main pour changer le prix en fonction de la TVA de chaque pays où l'application est distribuée.

Leviers marketing

Être présent sur les stores d’Apple et Google est un puissant gage de qualité et représente un levier marketing intéressant pour les marques. Apple et Google proposent plusieurs offres d’approches (incentive, etc.), incluant des périodes gratuites utilisables une fois, en échange de l'adresse email du compte par exemple. Le Store d'Apple permet de mettre en avant des produits mais également des offres, ce qui offre un levier supplémentaire en termes de campagnes de communication.

L'acquisition d'un parc abonné dédié mobile

La principale raison d’investir sur du natif est l'acquisition d’un parc abonné Apple et Google. En effet, l’acquisition d’un parc dédié mobile avec un enrôlement facilité par Apple et Google et le bon taux de rétention (entre les personnes qui oublient qu’elles sont abonnés et celles qui ne savent pas interrompre leurs abonnements sur les stores) représente deux leviers de chiffre d'affaires intéressants. Les deux plateformes proposent par ailleurs des interfaces de statistiques intéressantes pour suivre les usages (Attention, celles-ci ne permettent pas de s'affranchir totalement d'un plan de taggage !).

Cependant, il faut savoir que l'acquisition d'un nouveau parc a aussi un coût pour les équipes CRM car il est difficile de communiquer avec ces parcs. En effet, les plateformes renvoient très peu d'informations à leur propos (le device ID en question, des receipts, etc.). Par ailleurs, comme ce sont elles qui gèrent l'achat, la notion de remboursement sans faire appel aux plateformes peut vite devenir un casse-tête car les clients se retournent plus volontier contre la marque du produit que vers les stores de paiement. Google propose la possibilité de rembourser un achat dans son interface, mais encore faut-il pour cela connaitre la date exacte de l'achat et le device ID qui l'a effectué.

En effet, les parcs iOS et Android sont scindés et isolés l'un de l'autre mais aussi du parc web ce qui signifie qu'un abonnement iOS ne peut pas être restauré sur Google ou le web de base. Par ailleurs, le propriétaire du compte Google et Apple peut choisir à la création d'un product ID s'il s'agit d'un achat consommable (qui ne peut être restauré) ou non consommable (qui peut l'être). Pour rendre une restauration d'achat possible cross device, il faut mettre en place un parcours de réconciliation qui requiert d'envoyer au back l'identifiant du compte (s'il est identifié) afin d'attacher au compte un abonnement ou un droit équivalent à celui qui a été pris sur la plateforme.

Dans le cas contraire, si la personne change de device, il lui est nécéssaire de faire une restauration des achats pour accéder à ceux-ci. Il faut donc penser le parcours d'achat de manière précise en forçant les utilisateurs à se connecter (pour obtenir leur email par exemple) afin d'assurer, si on le souhaite, la restauration des achats mobile natifs ou même de communiquer avec les acheteurs. Vous l'aurez bien compris, même si accroitre son parc d'utilisateurs représente un certain potentiel financier, l'usage d'une base de données utilisateurs unique est indéniablement préférable car elle simplifie grandement la gestion des équipes CRM.

Le choix des plateformes

Une question que l'on se pose parfois : Peut-on proposer une application sur une seule des deux plateformes ? La réponse est bien évidemment oui puisqu’il n’y a aucune dépendance entre les deux environnements mais le choix de l’un ou l’autre (ou des deux) dépend de votre produit et de votre parc utilisateur.

En effet, le parc iOS représente souvent le chiffre d'affaires le plus important car outre le fait que les devices coûtent chers et qu’on imagine une CSP plus élevée derrière, la communauté est historiquement habituée à payer pour du contenu. Par ailleurs, le potentiel marketing de mise en avant d’offres et d'applications dans le store d’Apple est intéressant. En revanche attention, il faut noter que la communauté est généralement exigeante avec de fortes attentes fonctionnelles.

Sur Android, la communauté est plus habituée à consommer du contenu gratuit donc il sera plus difficile de les convertir vers des offres payantes et les leviers de Google en termes de visibilité sont un peu plus limités, mais la gestion des stores et des achats est un peu plus simple.

Prendre en compte les enjeux liés au format de l'application mobile

Le support des différents formats

En responsive web, nous utilisons des break points permettant d’adapter le produit à plusieurs formats, généralement 3 ou 4 : écran large (de bureau), petit (portable), tablette et mobile. En natif, on va généralement travailler sous 2 formats : mobile et tablette, sachant que les mobiles aux écrans larges bénéficieront du format tablette.

Un focus sur le format tablette

Faisons une aparté sur le format tablette qui, bien que représentant bien moins de ventes face aux mobiles, n’est pas toujours négligeable dans certains milieux, dont celui du média et de la presse par exemple où la lecture d’articles est plus confortable. Il représente d'ailleurs à peu près autour de 10 à 20% des usages dans la presse en France. Et lorsque l'on compare les usages entre mobile et tablette, notamment sur iOS, on observe parfois un usage quasi égal. Par exemple, je prends le cas de deux applications presse de PQR sur le mois de septembre 2024, on observe 51,7% d'usage tablette contre 48,3% en mobile et 54,3% tablette contre 45,7% sur mobile.

S'intéresser aux enjeux techniques avant de lancer un produit mobile

L'expérience utilisateur

En responsive mobile, sur format mobile et tablette, on observe souvent des conflits de gestuelles pour trouver les équivalents aux clics droits, double clics, etc. On observe aussi des conflits dans les scroll bars lorsque des éléments sont embarqués dans d'autres, là où le développement en natif utilise un design déjà pensé pour ces usages dès leur conception. En natif, nous concevons dès le départ un design qui utilise les composants natifs Android et iOS. L'utilisateur se voit proposé un parcours instinctif voire familier et trouve alors des points communs entre les autres applications qu'il utilise et notre produit, ce qui permet une meilleure adhésion à celui-ci. Il s'agit du plus grand avantage à partir des applications natives et de la limitation la plus importante sur de l'application hybride.

L'aspect technique et les fonctionnalités

D'un point de vue technique, développer en hybride offre le grand avantage de ne pas multiplier les différents langages de développement, et de simplifier la maintenance du produit. A contrario, le développement natif doit être réalisé dans le language natif de la plateforme.

Cependant, l'usage des composants natifs déjà disponibles en librairies permet de s'affranchir de certains développements, et d'éviter la maintenance de ceux-ci. Par ailleurs, à chaque évolution d'Apple et Google, le produit peut profiter des nouvelles fonctionnalités conçues par les OS, ce qui donne parfois naissance à des features particulières auxquelles on auraient pas pensé ou qu'on aurait pas priorisé en hybride à cause d'un ratio effort / business value jugé insuffisant. En outre, utiliser les nouvelles features des OS permet d’être présent sur différentes verticales hors produit comme les montres connectées, les écrans de veille, la dynamic island iOS..., et de proposer parfois des plus values par rapport à la concurrence.

Le SEO n'est plus une priorité sur les stores

Sur les applications mobiles soumises sur les Stores, on s'affranchit de la notion de SEO puisqu'il s'agit d'être référencé principalement sur les Stores. On va alors jouer principalement sur le contenu des interfaces Apple et Google directement. L'équipe marketing peut par ailleurs utiliser des leviers pour accroitre la visibilité des applications sur les stores.

Prendre en compte les différents défis liés au développement de l'application mobile

Les coûts de développements

Les deux environnements natifs étant différents techniquement et complexes à prendre en main (du moins au niveau des APis de paiement et de restauration), ils requièrent des expertises spécifiques. Il faut être familiarisé avec les méthodes de receipts et de restauration d’Apple et Google, connaitre les enjeuxs liés au fait de proposer des achats consommables ou non consommables, définir le type d'abonnement à proposer en fonction des répercussions techniques, etc.

Par ailleurs, tous les ans, de nouveaux OS sont développés par Apple et Google et à chaque nouvelle version, d’anciennes versions ne sont plus supportées par les plateformes, ce qui implique qu’un parc utilisant de vieux devices n'est plus concerné par l’évolution des applications. Aussi, à chaque update d’OS, nous perdons la possibilité d’intervenir auprès des clients ayant de vieux devices qui ne peuvent être mis à jour, ce qui est souvent un casse-tête pour les équipes du service client qui peuvent difficilement dire aux utilisateurs que leur device est trop ancien et qu'ils doivent en changer pour profiter des évolutions. En interne, à chaque mise à jour, la même question se pose pour savoir quelles versions d'OS le produit continue de supporter, parmi celles qui le sont encore côté plateforme (souvent on en abandonne deux de plus à chaque nouvel OS).

Plus rarement, ce sont des versions d’APIs qui ne sont plus maintenues par les OS, demandant ainsi aux développeurs de faire des modifications produit plus à risque. En mobile, il faut être Agile et anticiper au maximum les changements car l’on dépend de systèmes d’exploitation sur lesquels nous n’avons pas la main. C'est pourquoi les développeurs installent dès leur disponibilité les versions beta des nouveaux OS afin de vérifier leur impact sur le produit et de prévoir les développements.

Les deux plateformes sont soumises à la RGPD qui impose régulièrement de nouvelles règles ayant un impact sur la validation des applications en soumission (on note au fil du temps l'obligation d'ajouter des CGV, mentions légales, la possibilité pour l'utilisateur de supprimer son compte, l'ajout des consentements, etc.). Comme si cela ne suffisait pas, chaque plateforme ajoute ses propres règles, comme l'impossibilité sur iOS de proposer des achats via webview s'il n'y a pas d'achat in app. Il faut donc être très agile pour palier aux différentes règles et changements (parfois soudains) des plateformes.

En plus de l'expertise technique indéniable, proposer des applications natives requiert d'avoir des Product Owners alertes, constamment en veille sur les plateformes et qui maîtrisent divers sujets liés au mobile. Ces ressources expertes mobiles sont souvent plus rares sur le marché et coûtent parfois plus cher que sur les ressources web.

Le sujet qui fâche, les tests

Là où en desktop, nous testons plutôt des versions de navigateurs, en mobile nous avons besoin de beaucoup, beaucoup de devices. En effet, les simulateurs ne sont pas suffisants (on ne peut pas y tester les achats) donc nous devons tester en réel afin d'éviter de mauvaises surprises aux utilisateurs. Tester en mobile requiert donc d'avoir en stock différents modèles d'iPhone et d'iPad (pro, plus, edge...) sur iOS mais aussi différents modèles Android, dont les formats sont parfois plus exotiques (une petite pensée pour le format carré) afin de s’assurer du rendu correct des applications.

Même si l’on a besoin sur iOS d’iPhones et d’iPads de différentes générations sur différents OS, sur Android il faut surtout avoir en stock des devices récents et anciens de performances plus ou moins bonnes, et porter une attention particulière aux Samsung. Heureusement pour nous testeurs et malheureusement pour les utilisateurs, Apple abandonnant des versions d’OS chaque année, le parc reste plus ou moins le même alors que sur android, il s'agrandit toujours.

Techniquement, la complexité résulte en le fait de tester avant envoi en soumission tout ce qui appelle les APIs d'achats. En effet, là où sur desktop on peut avoir une certaine visibilité sur les appels faits entre le front et le back, en mobile, nous, Product Owners, sommes plutôt aveugles sur cette partie.

Sur iOS, certains utilisent testflight, d’autres des comptes bêtas, dans tous les cas, des manipulations précises et souvent lourdes sont indispensables sur les deux stores.

À nouveau, les produits mobiles demandent des compétences particulières aux ressources : la personne chargée des tests doit connaître les procédures mobile sur les deux environnements afin d’assurer un schéma de tests fiable. Il faut tout de même préciser que les OS étant stables, on peut parfois se fier à leur fonctionnement, à nos risques et périls.

Des mises en production bien anticipées

Là où nous maitrisons notre schéma de mise en production sur le web, en mobile, les mises en production passent par des soumissions sur les stores qui doivent être obligatoirement anticipés car elles nécessitent une vérification (review) de la part des plateformes. Sur iOS, il faut compter 48h (attention aux vacances de Noël pendant lesquelles Apple ferme) et sur Android, cela peut aller de quelques heures à plusieurs jours. Pour soumettre une application, plusieurs contraintes s'imposent : il faut uploader un IPA ou APK qui soit vérifié à l'upload (cela prend quelques minutes), puis il faut ajouter un texte de mise à jour et des screenshots puis soumettre les binaires. En cas de refus par les plateformes, l'échange est chronophage car les retours sont souvent peu précis (surtout chez Google) lorsque ce ne sont pas des textes automatiques. Il faut donc que le Product Owner en charge de la soumission connaisse bien les environnements et leurs contraintes et sache communiquer avec Apple et Google en Anglais. Et oui, les équipes de review d’Apple et Google auront toujours le dernier mot, même à une phrase près dans la description de mise à jour.

Conclusion : vous avez toutes les cartes en mains pour choisir de développer un produit mobile

En conclusion, le choix de se tourner vers un produit dédié et de partir sur un produit natif ou hybride dépend de plusieurs facteurs donc les ressources disponibles dans l’entreprise, du potentiel que représente la cible identifiée en termes de ventes, du chiffre d’affaires estimé, et de l’importance qu’a le parcours client dans le produit en lui-même. Sur une approche user-centric à l'usage majoritairement mobile, le natif semble plus pertinent, à condition d'avoir des ressources qui maîtrisent l'environnement car commme nous l'avons vu, cela ne va pas sans plusieurs contraintes. Le fait de passer par une application hybride peut en revanche être une solution pour entrer sur le marché lorsque l'on est pas certain du potentiel de sa cible, en utilisant les ressources techniques de développpement déjà à notre disposition tout en limitant l'investissement financier. On voit d'ailleurs apparaitre plusieurs solutions permettant cela à l'instar de Flutter. Pour plus d'informations sur les applications hybrides, vous pouvez consulter cet article.