Web app vs mobile app : la décision avant le build

Une fondatrice avec qui nous avons travaillé l’an dernier est arrivée au kickoff certaine d’une chose : il lui fallait une app iOS. Son produit était un outil de prise de rendez-vous et de facturation pour kinésithérapeutes indépendants, le genre de travail qui se fait à un bureau entre deux patients, sur un ordinateur portable, avec un second écran affichant l’agenda du jour. Elle voulait être sur l’App Store quand même, parce que c’était à ça que ressemblait un vrai produit dans sa tête. Nous lui avons construit un web app à la place. Dix-huit mois plus tard, elle a des cliniques clientes dans trois États et n’a pas une seule fois regretté l’app native qu’elle avait demandée le premier jour.

Voilà toute la question web app vs mobile app en une histoire. Un web app tourne dans le navigateur et fonctionne sur tout appareil capable d’ouvrir une URL. Un mobile app s’installe depuis une app store et tourne nativement sur le téléphone. Choisir entre les deux n’est pas un choix sur la technologie la plus moderne. C’est une question sur l’endroit où vos clients font réellement le travail, et sur ce dont ce travail a besoin de l’appareil qu’ils ont en main. Répondez-y honnêtement et la plateforme découle d’elle-même de la réponse.

La plupart des fondateurs en phase de démarrage sont poussés dans l’autre sens. L’instinct app store dit « une entreprise sérieuse a une app », alors ils paient pour construire et maintenir deux plateformes afin d’atteindre des clients qu’un seul bon web app aurait servis tout aussi bien. Ceci est un guide pour prendre cette décision depuis le siège du fondateur, pas celui du développeur, avec un framework que vous déroulez en un après-midi.

Trois choses que les fondateurs continuent de confondre

Avant que la décision ait du sens, trois mots doivent se séparer, parce que les fondateurs les emploient comme des synonymes et finissent par acheter la mauvaise chose.

Un site web est du contenu que l’on lit. Un site vitrine, un blog, une landing page. Personne ne se connecte pour travailler.

Un web app est un logiciel qui tourne dans le navigateur et auquel les gens se connectent pour l’utiliser. Gmail est un web app. Figma est un web app. Le dashboard de votre banque est un web app. Il vit à une URL, se met à jour à l’instant où vous déployez, et fonctionne sur ordinateur portable, tablette et navigateur de téléphone sans que vous construisiez trois versions. Un progressive web app, ou PWA, est un web app que l’on peut enregistrer sur l’écran d’accueil du téléphone, qui fonctionne en partie hors ligne et qui peut envoyer des push notifications. Il ressemble et se comporte presque comme une app installée sans passer par un magasin.

Un mobile app est ce que vous téléchargez depuis l’App Store ou Google Play. Il tourne nativement sur le téléphone, peut utiliser l’appareil photo, le GPS, le Bluetooth et tout le système de notifications, et fonctionne hors ligne par défaut. En construire un signifie en général le construire deux fois, une pour iOS et une pour Android, ou utiliser un framework cross-platform pour partager le code. Cette deuxième décision, natif versus cross-platform, ne compte qu’une fois que vous avez décidé qu’il vous faut un mobile app tout court.

Gardez ces trois choses distinctes et l’essentiel de la confusion du débat « web app vs mobile app » disparaît. Beaucoup de fondateurs croient avoir besoin d’un mobile app alors qu’il leur faut un web app qui se trouve bien fonctionner sur le téléphone.

La vraie question n’est pas web vs mobile

Voici le geste qui fait économiser le plus d’argent au fondateur : arrêtez de comparer les plateformes et commencez à décrire le travail.

Les plateformes ne sont que des mécanismes de livraison. Ce qui compte, c’est le travail que fait votre client quand il se tourne vers votre produit, et où il se trouve quand il le fait. Un technicien de terrain photographiant un compteur abîmé sur un toit sans réseau fait un travail différent de celui d’un responsable des opérations rapprochant des factures un mardi après-midi. Le premier a besoin de l’appareil photo, du GPS et d’un stockage hors ligne, donc il veut être natif. Le second a besoin d’un vrai clavier et d’un grand écran, donc il veut être un web app. Aucun des deux fondateurs ne devrait partir de « iOS ou navigateur ». Ils devraient partir du toit et du mardi après-midi.

C’est pourquoi la SERP pleine de listes « 20 avantages et inconvénients » vous est inutile. Les avantages et inconvénients dans l’abstrait sont du bruit. La même fonctionnalité qui est un plus pour une app grand public de fitness, des push notifications qui vous poussent à fermer vos anneaux, est sans intérêt pour un outil B2B que les gens ouvrent quand un e-mail le leur dit. Vous n’avez pas besoin d’une matrice de fonctionnalités. Vous avez besoin de connaître la journée de votre client.

Les quatre questions qui tranchent vraiment

Faites passer votre produit par ces quatre questions. Les réponses pointent vers web app, PWA ou natif bien plus sûrement que n’importe quel tableau comparatif générique.

1. Où le travail se passe-t-il physiquement ? À un bureau, sur un ordinateur portable, avec d’autres onglets ouverts ? C’est le territoire du web app, point. En déplacement, sur le terrain, dans le rayon d’un magasin, en voiture, loin d’un clavier ? Cela tire vers le mobile. Soyez honnête sur l’endroit où le travail se déroule vraiment, pas sur l’endroit où vous imaginez vos utilisateurs rêvant de votre marque.

2. De quoi le travail a-t-il besoin de l’appareil ? Listez les fonctions matérielles et système que la tâche centrale exige réellement. Appareil photo pour capturer un document ou un code-barres. GPS pour la localisation. Bluetooth pour un appareil. Usage hors ligne fiable sans réseau. Push notifications riches qui doivent arriver même quand l’app est fermée. Si votre tâche centrale a besoin de deux de ces éléments ou plus, en profondeur, un app natif justifie son coût. Si elle n’en a besoin d’aucun, vous payez un app natif pour livrer une expérience de web.

3. À quelle fréquence les clients reviennent-ils, et par quelle porte ? Un outil que les gens utilisent chaque jour, qu’ils veulent à un appui sur l’écran d’accueil, gagne à être installé. Un outil utilisé chaque semaine ou chaque mois, que l’on atteint en cliquant sur un lien dans un e-mail ou un message Slack, vaut mieux en web app. La découverte compte ici. Si vos clients vous trouvent et reviennent par e-mail, recherche et liens partagés, une URL est votre porte d’entrée. Une fiche dans l’app store ne l’est pas.

4. Combien pouvez-vous payer pour construire et maintenir sur 18 mois, pas seulement pour lancer ? Voilà la question que les fondateurs sautent et regrettent. Un app natif est rarement une seule construction. C’est iOS plus Android, deux processus de revue de magasin, des mises à jour système qui cassent des choses deux fois par an, et un cycle de release où corriger un bug signifie attendre les relecteurs d’Apple au lieu de déployer en une heure. Construire pour deux plateformes natives coûte en général nettement plus qu’un seul build web, et l’écart de maintenance s’accumule chaque trimestre après le lancement. Si votre runway est serré, chaque plateforme que vous ajoutez est un impôt que vous payez pour toujours.

Si trois des quatre réponses pointent vers le navigateur, construisez le web app et arrêtez de vous convaincre d’en faire plus. Si trois pointent vers le téléphone, le coût natif est justifié. Quand elles se divisent, les deux sections suivantes sont pour vous.

Quand un web app ou un PWA est le bon choix

Pour la plupart des produits B2B, outils internes, dashboards, marketplaces et tout ce que les gens utilisent à un bureau, un web app n’est pas le compromis. C’est la bonne réponse.

Vous livrez à l’instant où vous déployez, sans aucune revue de magasin assise entre vous et vos clients. Une seule base de code sert l’ordinateur portable, la tablette et le navigateur du téléphone. L’onboarding est un lien, la distribution la moins coûteuse en friction qui soit. Et quand un client tombe sur un bug un vendredi, vous le corrigez le vendredi, pas le mardi suivant après le réveil d’un relecteur.

Si votre produit veut un pied sur le téléphone sans le coût natif complet, un PWA est le moyen sous-estimé. Les clients peuvent l’ajouter à l’écran d’accueil, il peut fonctionner hors ligne pour les données en cache, et il peut envoyer des push notifications sur Android et, de plus en plus, sur iOS. Il n’égalera pas un app natif sur les graphismes lourds, l’accès profond au matériel ou le soin des gestes natifs de la plateforme. Pour une grande part des produits de fondateur, ce n’est pas nécessaire. L’arbitrage honnête est que les PWA perdent face au natif en capacité brute et gagnent en coût et en vitesse d’itération. Pour un outil auquel les gens se connectent pour travailler, cet échange penche en général du côté du web. Le guide de Google lui-même sur les progressive web apps est une bonne introduction à ce qu’ils peuvent et ne peuvent pas faire aujourd’hui.

Quand vous avez vraiment besoin d’un app natif

Parfois le téléphone n’est pas un agrément. C’est le produit.

Construisez natif quand la tâche centrale vit sur le téléphone et s’appuie fortement sur l’appareil : une app de navigation, un produit appareil-photo d’abord, un outil de livraison ou de logistique utilisé sur le terrain, tout ce qui exige un fonctionnement hors ligne fiable, une localisation en temps réel, du matériel Bluetooth ou une fiabilité de notification que vous ne pouvez pas compromettre. Construisez natif quand l’usage quotidien et habituel est tout le modèle de rétention et que l’icône sur l’écran d’accueil fait un vrai travail pour ramener les gens. Construisez natif quand la performance est l’expérience, là où une demi-seconde de à-coup se lit comme cassé.

Si c’est vous, le coût natif n’est pas du gaspillage. C’est le prix pour que le produit fonctionne tout court. Le but du framework n’est pas de vous dissuader du natif. C’est de garantir que vous payez le natif parce que le travail l’exige, pas parce que l’App Store ressemblait à un jalon à cocher.

« Lequel construire en premier ? »

Voilà la question que la moitié de la SERP promet de trancher avant de l’esquiver. En voici la version honnête.

Pour la plupart des fondateurs, construisez le web app en premier, même si vous êtes sûr qu’un app natif est dans votre futur. Le web app est moins cher, se livre plus vite, tourne sur tout appareil que possèdent vos premiers clients, et vous apprend ce que le produit devrait être avant que vous vous engagiez sur la plateforme la plus coûteuse. Vous découvrez quelles fonctionnalités comptent, sur quels écrans les gens vivent, et quelles parties de votre plan du premier jour étaient fausses. Ensuite, si les quatre questions pointent encore vers le natif, vous le construisez en sachant exactement quoi construire, par-dessus un backend que le web app a déjà éprouvé.

L’exception est le petit ensemble de produits où le téléphone est toute l’expérience dès le premier jour, où un web app ne serait pas une version plus petite du produit mais une version différente et moins bonne. Une app grand public dont tout le pitch est appareil-photo-plus-localisation n’a pas de version web utile. Pour tous les autres, le web d’abord n’est pas se contenter de moins. C’est du séquençage, et c’est la même discipline derrière un vrai produit minimum viable : construisez la plus petite chose qui fait bien le travail, apprenez, puis élargissez la surface volontairement. La décision web app vs mobile app est une instance du jugement plus large build versus buy versus séquencer que tout fondateur prend une douzaine de fois.

L’app store est de la distribution, et la distribution a un prix

Une dernière chose que l’instinct « une entreprise sérieuse a une app » ne voit pas. L’App Store et Google Play ne sont pas seulement un endroit où poser votre app. Ce sont un canal de distribution, et les canaux font payer un loyer.

Ce loyer prend trois formes. Il y a la commission, historiquement de 15 à 30 pour cent de tout ce que vous vendez dans l’app, même si le programme pour petites entreprises d’Apple la ramène à 15 pour cent en dessous d’un million de dollars par an. Il y a la latence de revue : chaque release, y compris le correctif urgent, attend dans une file que vous ne contrôlez pas. Et il y a la découverte, que les fondateurs surestiment le plus. Personne ne parcourt le magasin et ne tombe par hasard sur votre outil B2B de prise de rendez-vous. Vous le ferez connaître par les mêmes canaux que pour un web app, puis vous demanderez aux gens d’aller l’installer, ajoutant une étape. Le magasin est un péage que vous choisissez de franchir quand l’expérience native vaut le péage. Ce n’est pas de la portée gratuite, et ce n’est pas un trophée.

Rien de tout cela ne veut dire éviter l’App Store. Cela veut dire la compter comme un coût, comme vous comptez tout autre coût, au lieu de traiter « nous sommes sur l’App Store » comme un objectif qui se rembourse de lui-même. Il le fait rarement tout seul.

La fondatrice de l’outil de kinésithérapie l’a compris dès que nous le lui avons exposé. Ses clients étaient à des bureaux, le travail avait besoin d’un clavier et d’un écran et de rien du matériel du téléphone, ils revenaient par des rappels e-mail, et son runway ne pouvait pas porter deux builds natifs. Chacune des quatre questions pointait dans la même direction. L’app natif n’a jamais été le produit dont elle avait besoin. C’était l’image dans sa tête de ce qu’un produit est censé être. Le travail, une fois décrit sans détour, avait déjà choisi le navigateur.

FAQ

Qu’est-ce qui est mieux, un mobile app ou un site web ?
Aucun n’est meilleur dans l’abstrait. Un site web est pour du contenu que les gens lisent ; un web app est un logiciel auquel les gens se connectent ; un mobile app s’installe depuis un magasin et utilise le matériel du téléphone. Le bon dépend de l’endroit où le travail se passe et de ce dont il a besoin de l’appareil. Pour la plupart des produits de bureau et B2B, un web app gagne sur le coût, la vitesse et la portée. Pour les produits de terrain, d’appareil photo ou d’habitude quotidienne, le natif se justifie.

Un web app peut-il être un mobile app ?
En pratique, oui, et c’est ce qu’est un progressive web app. Un PWA tourne dans le navigateur mais peut s’enregistrer sur l’écran d’accueil, fonctionner hors ligne pour les données en cache et envoyer des push notifications, donc il se comporte beaucoup comme une app installée sans passer par une app store. Il n’égalera pas un app natif sur un usage matériel lourd ou les graphismes, mais pour beaucoup de produits il comble l’essentiel de l’écart à une fraction du coût.

Pourquoi les PWA ne sont-ils pas populaires ?
Les PWA sont largement utilisés, mais discrètement. Plusieurs produits que vous utilisez sont des PWA sans le crier. La perception qu’ils ne sont pas populaires vient de deux choses : iOS les a pris en charge plus tard et plus partiellement qu’Android, et il n’y a pas de fiche de magasin pour les rendre visibles, donc l’adoption est invisible par conception. Pour les fondateurs, cette invisibilité est un atout, puisque la distribution passe par vos propres liens plutôt que par un magasin saturé.

Facebook est-il un web app ou un mobile app ?
Les deux, et c’est tout le propos. Les grandes entreprises font tourner un web app et des apps natives iOS et Android en parallèle parce qu’elles ont le budget et la base d’utilisateurs pour justifier chaque plateforme. C’est le mauvais modèle à copier au stade précoce. Les grandes apps sont partout parce qu’elles peuvent se le permettre, pas parce que chaque produit doit commencer ainsi. Choisissez la seule plateforme que le travail de vos clients exige vraiment, prouvez-la, puis ajoutez des surfaces quand les chiffres, et non l’instinct, le disent.