Application native ou application web : quelle différence pour votre business ?

C’est la question qu’on pose au développeur en attendant une réponse technique. Elle n’a pourtant que des conséquences commerciales : le prix, le temps qu’il faut pour mettre une correction entre les mains des utilisateurs, et la possibilité qu’Apple refuse votre mise à jour un lundi matin.

Voici les trois options, ce qu’elles impliquent réellement, et le cas où chacune s’impose.

L’application web installable

C’est un site, mais qui s’ajoute à l’écran d’accueil, s’ouvre en plein écran sans barre de navigateur, fonctionne partiellement sans réseau et peut envoyer des notifications. L’utilisateur ne voit pas de différence avec une application — sauf qu’il ne l’a pas installée depuis un store.

Son intérêt décisif : elle ne demande la permission de personne. Vous corrigez un bug, il est en ligne cinq minutes plus tard, pour tout le monde. Sa limite : elle n’accède pas à tout le matériel du téléphone, et sur iPhone certaines fonctions restent bridées.

L’application multiplateforme

Une seule base de code produit les deux applications, iOS et Android, publiées sur les deux stores. C’est le choix de la très grande majorité des projets d’entreprise, et celui de la plupart des applications que vous avez sur votre téléphone sans le savoir.

Le natif

Deux applications distinctes, écrites séparément avec les outils d’Apple d’un côté et de Google de l’autre. Tout est fait deux fois : le développement, les corrections, les évolutions. En échange, l’accès au matériel est total et les performances graphiques maximales.

L’écart de prix au départ n’est que la moitié de l’histoire. Le vrai coût du natif se paie après, à chaque évolution : une fonctionnalité ajoutée est une fonctionnalité écrite deux fois, testée deux fois, corrigée deux fois — pendant toute la vie du produit.

Trois usages le justifient malgré tout : l’exploitation intensive des capteurs, le graphisme temps réel — jeux, rendu 3D — et la réalité augmentée. En dehors de ces trois cas, vos utilisateurs ne verront aucune différence.

C’est le point qu’on découvre trop tard, et il ne dépend pas de la technologie choisie mais du fait de passer ou non par un store.

• Chaque mise à jour est soumise à validation. Comptez de quelques heures à quelques jours, et parfois un refus qu’il faut argumenter. Un bug critique corrigé le vendredi n’est pas forcément en ligne le lundi.
• Apple prélève une commission sur tout achat de contenu numérique consommé dans l’application, et refuse la publication si vous contournez son système.
• Les règles changent sans vous demander votre avis. Une exigence nouvelle sur la confidentialité ou la suppression de compte peut obliger à modifier une application qui fonctionnait très bien.

Publier sur un store, c’est louer une vitrine dont le propriétaire peut changer le règlement — et fermer.

L’application web échappe entièrement à cela. En contrepartie, elle n’apparaît pas dans les stores, ce qui compte quand la visibilité de l’App Store fait partie de votre stratégie d’acquisition.

• Application web si : l’usage est interne ou destiné à des utilisateurs identifiés, vous n’avez pas besoin des capteurs, et vous voulez pouvoir corriger sans délai. C’est aussi la seule option qui laisse la porte ouverte : on peut en faire une vraie application plus tard.
• Multiplateforme si : vous visez le grand public, la présence dans les stores compte, et vous avez besoin des notifications et du fonctionnement hors ligne. C’est le cas majoritaire.
• Natif si : capteurs intensifs, graphisme temps réel ou réalité augmentée. Sinon, l’écart de coût ne se justifie pas.

Avant même ce choix, une question le précède : votre entreprise a-t-elle besoin d’une application ? Et si oui, ce qui fait varier son prix vous dira où part le budget.

Quel que soit le côté où tombe le choix, je développe les deux familles : application mobile et application web. Décrivez-moi l’usage que vous visez et je vous dis laquelle des trois convient, avec la fourchette correspondante. Réponse sous 48 heures.