"On pourrait faire une app mobile ?" C'est l'une des questions les plus fréquentes
en réunion produit. La réponse est rarement simple, car il existe plusieurs façons
de créer une application mobile, chacune avec ses avantages et ses compromis.
Pire, la vraie question est souvent ailleurs. Avant de choisir une technologie,
il faut savoir si une application est réellement nécessaire, car son coût le plus
lourd n'est ni le développement ni le design, mais le fait de convaincre quelqu'un
de l'installer. Nous y reviendrons.
Application native
Une application native est développée spécifiquement pour une plateforme.
Swift, ou l'ancien Objective-C, pour iOS chez Apple. Kotlin, ou l'ancien Java,
pour Android chez Google.
C'est l'approche qui donne les meilleures performances et le meilleur accès
aux fonctionnalités du téléphone, caméra, GPS, notifications, capteurs, paiement
sans contact. L'application s'intègre parfaitement dans son écosystème, elle suit
les conventions de design de la plateforme, les animations sont fluides,
et les nouveautés du système sont disponibles dès leur sortie.
Le problème saute aux yeux. Il faut développer et maintenir deux applications
distinctes, une par plateforme, avec des langages et des outils différents.
Cela double le coût, le temps de développement et la charge de maintenance,
et cela demande deux compétences que la même personne possède rarement.
Chaque évolution doit être spécifiée une fois et implémentée deux fois,
ce qui multiplie aussi les occasions de divergence entre les deux versions.
Applications hybrides et cross-platform
Pour éviter d'écrire deux fois la même chose, plusieurs familles de solutions
permettent de partager le code entre iOS et Android. On les confond souvent
sous le terme "hybride", alors qu'elles fonctionnent très différemment.
La première famille, historiquement appelée hybride, embarque en réalité un site web
dans une coquille d'application. Ionic et Capacitor en sont les représentants
les plus connus. C'est peu coûteux et très rapide à produire quand on a déjà
un site, mais le résultat trahit souvent ses origines, les animations manquent
de fluidité et l'application ne se comporte pas tout à fait comme les autres.
La seconde famille, dite cross-platform, produit une véritable application
et non une page web déguisée.
- React Native (créé par Meta, l'entreprise derrière Facebook) : le code s'écrit en JavaScript et pilote de vrais composants d'interface natifs. Il est utilisé par une partie des écrans d'Instagram, par Shopify ou Discord. Airbnb l'a longtemps utilisé avant d'y renoncer et de revenir au natif, un retour d'expérience très commenté dans le métier.
- Flutter (créé par Google) : le code s'écrit en Dart et le framework dessine lui-même chaque pixel de l'interface, ce qui garantit un rendu rigoureusement identique partout. Google Pay, BMW ou Alibaba s'en servent.
- Kotlin Multiplatform (créé par JetBrains) : une approche plus récente et plus prudente, où l'on partage la logique métier mais où chaque plateforme garde sa propre interface native.
Le compromis est intéressant, un seul code pour deux plateformes, des performances
proches du natif dans la grande majorité des cas, et un accès à l'essentiel
des fonctionnalités du téléphone.
Les limites existent quand même. Les fonctionnalités très spécifiques
à une plateforme demandent du code natif en complément, ce qui suppose
d'avoir malgré tout la compétence sous la main. Les nouveautés d'une version
majeure du système arrivent avec un décalage, le temps que le framework
les prenne en charge. Et tu ajoutes une dépendance de plus, celle du framework
lui-même, dont les mises à jour peuvent être douloureuses.
La PWA, le web qui se fait passer pour une app
Une PWA, pour Progressive Web App, est un site web enrichi qui peut s'installer
sur le téléphone et se comporter comme une application, avec une icône
sur l'écran d'accueil, un fonctionnement partiel hors ligne et des notifications.
L'avantage principal, c'est qu'il s'agit de web standard, HTML, CSS et JavaScript.
Pas d'application séparée à développer, pas de passage obligé par les magasins
d'applications, pas de commission à verser, et une seule base de code
pour le site et l'application. Une mise à jour est en ligne immédiatement,
sans validation ni attente que les utilisateurs mettent à jour.
Les limites tiennent surtout à l'accès aux fonctionnalités du téléphone,
plus restreint qu'en natif, et à un écart historique entre les plateformes.
Android a longtemps eu une longueur d'avance, Apple ayant tardé à soutenir
les PWA, notamment sur les notifications qui ne sont arrivées sur iPhone
qu'en 2023. La situation s'améliore, mais si ton produit dépend d'une capacité
matérielle pointue, il faut vérifier son support au cas par cas avant de s'engager.
Responsive design, adapter le web au mobile
Avant même de penser "application", beaucoup de besoins sont couverts
par un site web responsive, c'est-à-dire un site qui s'adapte automatiquement
à la taille de l'écran.
Sur un ordinateur, le contenu s'affiche sur trois colonnes. Sur une tablette,
sur deux. Sur un téléphone, sur une seule, les menus se replient et les images
se redimensionnent. Le contenu reste le même, seule la mise en page change.
Nous détaillerons le sujet dans le chapitre sur le
responsive design.
Ce n'est plus une option. Un site inutilisable sur mobile perd des positions
dans les résultats de recherche, puisque Google indexe désormais les sites
à partir de leur version mobile, et fait fuir des utilisateurs qui,
pour la plupart des sites grand public, sont majoritairement sur téléphone.
Le coût réel d'une application
Le choix technique est souvent celui qui occupe les réunions, alors que ce n'est pas là que se joue la réussite. Voici ce qui est systématiquement sous-estimé.
- La distribution : publier sur l'App Store ou le Play Store suppose un compte développeur payant, un processus de validation, et le respect de règles éditoriales parfois tatillonnes. Un refus de dernière minute avant un lancement commercial est une expérience que beaucoup d'équipes ont vécue. Être présent ne suffit d'ailleurs pas, encore faut-il être trouvé, ce qui est le sujet du chapitre sur l'ASO.
- La commission : Apple et Google prélèvent une commission sur les achats effectués dans l'application, historiquement 30 pour cent, ramenée à 15 pour cent pour les petits éditeurs et pour une partie des abonnements. Sur un modèle par abonnement, cette ponction change complètement l'équation économique. Les règles évoluent d'ailleurs sous la pression réglementaire, en Europe notamment. Et la commission n'est qu'une partie de l'intermédiation, les abonnements sont gérés côté magasin, les remboursements aussi, et les avis sont publics. Une partie de ta relation client passe par un tiers qui fixe ses règles.
- L'installation : c'est le point le plus dur. Demander à quelqu'un d'installer une application, c'est lui demander de la chercher, d'attendre un téléchargement et de libérer de la place. La plupart des applications installées sont ouvertes une fois puis oubliées. Une application n'a de sens que si l'usage est répété et fréquent.
- Les mises à jour : contrairement au web, tu ne contrôles pas la version qu'utilisent tes clients. Il faut donc maintenir la compatibilité avec des versions anciennes de ton application pendant des mois, et prévoir un mécanisme pour forcer la mise à jour quand c'est indispensable.
- Le cycle de vie : Apple et Google publient une version majeure de leur système chaque année et imposent régulièrement de mettre à jour les applications pour qu'elles restent publiées. Une application mobile n'est jamais "terminée", elle demande un budget de maintenance récurrent même quand plus aucune fonctionnalité n'est ajoutée.
- Le hors ligne : présenté comme un avantage, c'est surtout du travail. Une application qui fonctionne dans le train doit ensuite réconcilier ce que l'utilisateur a modifié avec ce qui a changé côté serveur pendant ce temps, et décider qui a raison quand les deux ont touché à la même chose. C'est régulièrement la partie la plus coûteuse d'un projet mobile.
- La mesure : les outils d'analytics du web ne fonctionnent pas tels quels dans une application, il faut y intégrer des composants dédiés. Et depuis qu'Apple oblige chaque application à demander l'autorisation avant de suivre l'utilisateur à des fins publicitaires, la majorité des gens refusent, ce qui a bouleversé la publicité mobile et la mesure de son efficacité.
Les notifications
C'est l'argument numéro un pour justifier une application, et le plus vite gâché. Une notification arrive
sur l'écran verrouillé de quelqu'un, au milieu de sa journée, et elle coûte à chaque fois un peu de la
tolérance qu'il t'accorde.
Trois règles tiennent lieu de doctrine. Demander l'autorisation au bon moment, jamais au premier lancement,
mais après que l'utilisateur a vu ce que l'application lui apporte, sans quoi le refus est massif et
définitif. Envoyer peu, et utile, une commande expédiée, une réponse à un message, pas une promotion par jour.
Et mesurer les désinstallations dans les heures qui suivent chaque envoi, parce que c'est là qu'elles se
produisent. Une application désinstallée pour cause de notifications abusives ne revient jamais.
La bonne question n'est donc pas "quelle technologie choisir" mais "qu'est-ce que l'application apporte qu'un bon site mobile ne peut pas apporter". Les réponses valables existent, notification poussée sur un usage quotidien, fonctionnement hors ligne, accès aux capteurs, paiement rapide, présence permanente sur l'écran d'accueil. Si aucune ne s'applique à ton produit, l'application coûtera cher pour pas grand-chose.
Comment choisir ?
- Site responsive : suffisant pour la majorité des cas, contenu, e-commerce, services en ligne, et de loin l'option la moins coûteuse à faire vivre.
- PWA : quand tu veux une présence sur l'écran d'accueil et un usage hors ligne léger, sans le coût ni les contraintes d'une application native.
- Cross-platform : quand tu as besoin d'une vraie application avec des fonctionnalités avancées, mais que tu veux un seul code et une seule équipe. C'est le choix par défaut raisonnable pour la plupart des projets aujourd'hui.
- Natif : quand les performances, la finesse de l'expérience ou l'accès aux capteurs sont critiques, typiquement les jeux, la réalité augmentée, les applications de santé ou celles qui exploitent intensivement l'appareil photo.
Un dernier conseil. Rien n'oblige à trancher définitivement dès le premier jour. Beaucoup d'équipes lancent un site responsive, mesurent l'usage réel sur mobile, puis investissent dans une application quand les données montrent qu'un noyau d'utilisateurs revient plusieurs fois par semaine. C'est nettement plus prudent que de dépenser un an de budget sur une intuition de réunion.