Application mobile ou application web ? Un guide de décision honnête pour les petites entreprises

Presque chaque semaine, quelqu'un nous dit avoir besoin d'une appli. En général, il se l'est déjà imaginée : une icône sur un téléphone, une chose que les clients téléchargent, peut-être une petite pastille avec un nombre de notifications. Et presque aussi souvent, au bout de quinze minutes de conversation, il s'avère qu'il n'a pas du tout besoin d'une appli. Il a besoin de quelque chose qui fonctionne à merveille sur mobile, ce qui est tout autre chose : moins cher, plus rapide et bien moins susceptible de prendre la poussière dans un magasin d'applications que personne ne visite.

Le mot « appli » a discrètement englouti trois ou quatre produits très différents. Quand quelqu'un le prononce, il peut désigner une application native que l'on télécharge, un site qui se comporte comme une appli, un outil interne pour son propre personnel, ou simplement « une version moderne de mon entreprise sur un écran ». Se tromper ici coûte cher, non pas parce que le mauvais choix est difficile à construire, mais parce qu'il vous enchaîne à des mois de coûts et de maintenance dont vous n'aviez pas besoin.

Voici donc le guide que nous aurions aimé que chaque dirigeant ait avant ce premier appel. Pas de battage sur la plateforme qui l'emporte, pas de prétention selon laquelle les applications natives seraient toujours le choix prestigieux. Juste un regard lucide sur ce que sont réellement les deux options, ce qu'elles coûtent, et une manière simple de décider laquelle votre entreprise nécessite, si tant est qu'elle en nécessite une.

D'abord, clarifiez ce que vous entendez vraiment par « appli »

Avant de pouvoir choisir, il faut savoir ce qui figure au menu. Une application mobile — la version native — est un logiciel que l'utilisateur installe depuis l'App Store ou Google Play. Elle réside sur le téléphone, obtient une icône et peut accéder en profondeur à l'appareil : appareil photo, GPS, notifications push, stockage hors ligne, connexion par empreinte. Une application web est un site qui fait plus qu'afficher des informations : il permet aux gens de faire des choses : se connecter, réserver, payer, gérer un compte. Vous l'ouvrez dans un navigateur et il n'y a rien à télécharger.

Entre les deux se trouve une troisième option dont la plupart n'ont jamais entendu le nom : la progressive web app, ou PWA. C'est une application web conçue pour être « ajoutée à l'écran d'accueil », s'exécuter en plein écran avec sa propre icône, fonctionner hors ligne et envoyer des notifications sur la plupart des appareils. Pour une très grande part des petites entreprises, c'est le juste milieu dont personne n'a parlé : pour le client, cela ressemble à une appli, mais cela se construit et s'entretient comme un site.

Gardez ces trois notions distinctes en tête et la moitié de la confusion disparaît. La plupart du temps, la vraie question n'est pas « native ou web ? » — c'est « à quel point cela doit-il réellement ressembler à une appli, et cela vaut-il son prix ? »

Les différences qui comptent vraiment pour une entreprise

Vous trouverez cent articles comparant ces deux options sur le plan technique. La plupart sont écrits pour des développeurs et passent à côté de ce qui importe vraiment à un dirigeant. Laissons donc de côté les guerres de frameworks et parlons des quatre choses qui changent le fonctionnement de votre entreprise.

Comment les gens y accèdent

Une application web vit derrière un lien. Vous pouvez le placer dans un e-mail, un SMS, un QR code sur une table, un résultat de recherche Google. Un client l'utilise deux secondes après avoir cliqué. Une application native vit derrière un téléchargement : votre client doit la vouloir suffisamment pour aller sur un magasin, chercher votre nom, l'installer et l'ouvrir. Cet écart est brutal. Pour une entreprise avec laquelle la plupart des gens interagissent de façon occasionnelle, le téléchargement est souvent la raison entière de l'échec d'une appli.

Ce qu'elle peut réellement faire

Le natif l'emporte encore sur la puissance brute. Si vous avez besoin d'un usage hors ligne à toute épreuve, d'un travail intensif de l'appareil photo ou des capteurs, de graphismes fluides et performants, ou de notifications qui doivent absolument arriver, le natif est le pari le plus sûr. Mais l'écart s'est considérablement réduit. Une application web moderne peut encaisser des paiements, utiliser l'appareil photo, trouver votre position, fonctionner hors ligne et envoyer des notifications push sur la plupart des téléphones. La vraie question est de savoir si votre entreprise s'appuie réellement sur les rares choses que seul le natif réussit bien.

Ce qu'elle coûte à construire et à maintenir en vie

C'est ici que l'écart est le plus grand, et là que les dirigeants se font surprendre. Une application web est une seule base de code qui tourne partout avec un navigateur. Une application native, bien faite, signifie souvent construire et maintenir pour deux plateformes, plus le processus de validation du magasin, plus des mises à jour permanentes chaque fois qu'Apple ou Google change les règles. La construction coûte plus cher ; la maintenance est la partie dont personne ne vous prévient. Une appli n'est pas une chose que l'on termine, c'est une chose que l'on nourrit.

Le contrôle que vous conservez

Avec une application web, vous publiez une modification et elle est en ligne en quelques minutes. Avec une application native, chaque mise à jour attend dans une file de validation, et le magasin peut la rejeter, exiger une commission sur chaque vente ou changer ses règles sous vos pieds. Vous louez de l'espace sur la plateforme de quelqu'un d'autre. Pour certaines entreprises, ce compromis en vaut la peine. Pour beaucoup, la liberté de « ce n'est qu'un site, on le met à jour quand on veut » vaut plus que la finition.

Quand une application mobile native est réellement le bon choix

Les applications natives ne sont pas un piège : ce sont un outil puissant, inadapté à la plupart des petites entreprises et parfaitement adapté à quelques-unes. Voici quand le surcoût et la dépendance se rentabilisent, honnêtement et sans vernis commercial.

• Les gens l'utilisent en permanence, chaque jour ou presque. Le coût du téléchargement est largement remboursé par un usage fréquent et fidèle.
• Vous vous appuyez fortement sur les fonctions de l'appareil : GPS continu, travail intensif de l'appareil photo, matériel Bluetooth, fonctionnement hors ligne fiable dans des lieux sans réseau.
• Les notifications sont au cœur du produit, pas un simple plus, et elles doivent arriver de façon fiable sur chaque appareil.
• La performance doit être irréprochable : graphismes rapides, jeux, interaction en temps réel où une demi-seconde de latence est rédhibitoire.
• Être dans l'App Store fait partie en soi de la confiance ou du discours marketing que vos clients attendent.

Remarquez le fil conducteur : le natif mérite son coût quand l'appli est utilisée beaucoup, par des gens déjà engagés auprès de vous, et quand elle dépend du matériel du téléphone d'une manière que le navigateur ne peut encore égaler. Une application d'intervention sur le terrain que votre propre équipe ouvre quarante fois par jour est un candidat parfait pour le natif. Une page de réservation qu'un client touche deux fois par an ne l'est pas.

Quand une application web est le choix plus malin et moins cher

Pour la plupart des petites et moyennes entreprises, c'est la réponse — et ce n'est pas un compromis, c'est le bon ajustement. Une application web brille précisément là où le natif peine : partout où la portée compte plus que la puissance brute, et partout où vous devez aller vite et modifier les choses souvent.

Optez pour le web d'abord quand les gens utiliseront la chose occasionnellement plutôt que chaque jour, quand vous voulez accueillir des clients sans la friction d'un téléchargement, quand le budget et la vitesse comptent, ou quand vous n'êtes pas encore sûr que l'idée prendra. Ce dernier point est sous-estimé. Une application web est le moyen parfait de tester si quelqu'un veut votre idée avant de vous engager dans le coût du natif. Vous pourrez toujours construire l'application native plus tard, une fois la demande réelle et lorsque vous verrez exactement quelles fonctionnalités la méritent.

Une courte histoire : le cabinet qui a demandé une appli

Un cabinet de kinésithérapie est venu nous voir, convaincu d'avoir besoin d'une application mobile. Un concurrent un peu plus loin en avait une, et ne pas en avoir donnait l'impression de prendre du retard. Leur idée était claire : les patients téléchargeraient l'appli, prendraient rendez-vous, consulteraient leurs plans d'exercices et recevraient des rappels. Ils avaient déjà à moitié budgété et s'étaient préparés au coût.

Nous avons donc posé la question que nous posons toujours : à quelle fréquence un patient ouvrira-t-il vraiment ceci ? La réponse honnête : une poignée de fois autour d'une cure de soins — réserver, jeter un œil aux exercices, recevoir un rappel, peut-être reprendre rendez-vous des mois plus tard. Ce n'est pas un usage quotidien. C'est un usage occasionnel. Et l'usage occasionnel est précisément là où la barrière du téléchargement tue discrètement une appli. Nous avons esquissé l'issue probable : quelques centaines d'euros de construction, puis des patients qui ne prennent jamais la peine de l'installer, et un comptoir d'accueil qui continue de prendre les rendez-vous par téléphone parce que l'appli est restée inutilisée.

Ce que nous avons construit à la place

Nous avons construit une application web — une progressive. Les patients l'ouvrent depuis un lien dans leur message de confirmation : pas de téléchargement, pas de magasin, pas de barrière de compte pour commencer. Ils peuvent réserver et reprogrammer, consulter leur plan d'exercices avec des vidéos et recevoir des rappels automatiques qui réduisent les absences. Quiconque veut le ressenti d'une appli peut l'ajouter à son écran d'accueil d'un seul geste, et dès lors elle s'ouvre en plein écran avec l'icône du cabinet, exactement comme une application native. Pour le patient, c'est tout simplement l'appli.

Comment cela s'est terminé

Les chiffres ici sont donnés à titre indicatif, mais le schéma est celui que nous voyons sans cesse. Cela a coûté une fraction de la construction native à laquelle ils s'étaient préparés, et bien moins cher à faire tourner : pas de deux plateformes, pas de validations de magasin, pas de course trimestrielle quand un système d'exploitation se met à jour. Comme il n'y avait rien à installer, les patients l'ont utilisée dès le premier jour ; l'adoption n'était pas bloquée derrière un téléchargement que personne n'achève. Les rappels ont sensiblement réduit les absences en deux mois. Et le cabinet a gardé le contrôle : lorsqu'il a voulu ajouter une étape de paiement, elle était en ligne la même semaine, et non coincée dans une file de validation.

La note honnête en bas de page : si, dans un an, les patients l'ouvrent en permanence et réclament des fonctions hors ligne plus poussées, une application native pourrait réellement mériter sa place. Mais cette décision se prendra alors sur des preuves, non sur l'icône d'un concurrent. Ils sauront qu'elle en vaut la peine avant de payer pour elle.

Une méthode simple pour décider vous-même

Vous n'avez pas besoin d'un consultant pour à peu près viser juste. Passez votre idée au crible de quatre questions, dans l'ordre. Le premier « oui » qui colle vraiment vous dit l'essentiel de ce que vous avez besoin de savoir.

1. 1
   À quelle fréquence une personne l'utilisera-t-elle ?

   Chaque jour ou presque oriente vers le natif. Occasionnellement — chaque semaine, chaque mois, quelques fois par an — oriente fermement vers le web.
2. 2
   A-t-elle vraiment besoin du matériel du téléphone ?

   Usage hors ligne intensif, GPS continu, appareils Bluetooth, travail intensif de l'appareil photo ? C'est un signal en faveur du natif. « Ce serait bien d'utiliser l'appareil photo une fois » ne l'est pas : le web gère cela sans problème.
3. 3
   À quelle vitesse et à quelle fréquence la modifierez-vous ?

   Si vous l'ajustez et la mettez à jour en permanence, ou si vous testez encore l'idée, les mises à jour instantanées du web et l'absence de tout gardien sont un avantage majeur.
4. 4
   Quel est votre budget réel — pour construire et pour maintenir ?

   Soyez honnête sur le second chiffre. Si l'entretien continu de deux plateformes vous pesait, commencez par le web. Vous pourrez passer au natif plus tard, en connaissance de cause, une fois le bien-fondé prouvé.

Une note sur les outils internes — une tout autre question

Tout ce qui précède suppose que vous construisez pour des clients. Si vous construisez pour votre propre équipe, le calcul change. Votre personnel installera volontiers quelque chose qu'il utilise toute la journée pour travailler : la barrière du téléchargement qui tue une appli grand public n'a guère d'importance quand utiliser l'outil est le travail. Ainsi, une application interne d'intervention sur le terrain ou d'entrepôt peut justifier solidement le natif là où une application orientée client ne le ferait pas.

Même là, le web l'emporte plus souvent qu'on ne le pense. Un outil interne basé sur le web fonctionne sur l'appareil que votre personnel transporte déjà, ne nécessite aucune installation sur toute une flotte de téléphones et se met à jour pour tous à l'instant où vous publiez. À moins de dépendre véritablement du fonctionnement hors ligne ou d'un accès matériel poussé, une application web interne est généralement la voie la plus rapide, la moins chère et la moins pénible — la même logique qu'avant, simplement avec les hypothèses d'usage inversées.

Questions fréquentes