Faut-il vraiment une application ? Quatre questions, et le débat est clos.

Le débat tourne vite au camp retranché. Il devient beaucoup plus court quand il est ramené à quatre questions dont les réponses sont factuelles.

1. De quel matériel l’application a-t-elle besoin ?

Le navigateur accède aujourd’hui à la caméra, au micro, à la position, aux notifications, au stockage hors ligne, au Bluetooth à basse consommation, et au partage de fichiers.

Restent hors de portée, ou trop partiellement supportés pour être fiables : la lecture NFC sur certaines plateformes, l’accès aux contacts, les traitements en arrière-plan de longue durée, et l’intégration profonde au système.

Si la fonction centrale figure dans cette seconde liste, le débat est clos : ce sera natif. Si elle figure dans la première, les trois questions suivantes décident.

2. Comment l’application est-elle distribuée ?

Une application de magasin se cherche, s’installe, et impose une revue à chaque publication. Pour un usage grand public récurrent — un client qui commande chaque semaine — c’est un avantage : l’icône reste sur l’écran d’accueil.

Pour un usage occasionnel, c’est un péage. Un utilisateur qui doit consulter un document une fois par trimestre n’installera rien : il ouvrira un lien, ou n’ouvrira rien du tout.

En interne, la distribution par magasin est souvent le poste le plus pénible du projet : comptes d’entreprise, gestion de parc, terminaux personnels des salariés.

3. À quelle fréquence faut-il publier ?

Une application web se met à jour au rechargement. Une application de magasin passe par une revue, puis attend que chaque utilisateur accepte la mise à jour — et une partie ne le fera jamais. Le serveur doit donc rester compatible avec des versions anciennes, parfois longtemps.

Ce coût est invisible au lancement et structurel ensuite.

4. Quel est le coût de maintien sur cinq ans ?

C’est le critère le plus souvent oublié. Une application native, ce sont deux plateformes, deux chaînes de compilation, deux jeux de certificats à renouveler, et des versions de système qui imposent des adaptations sans apporter aucune fonctionnalité nouvelle.

Le coût ne se compare pas au développement initial mais à ce qu’il faut dépenser chaque année pour que l’application continue simplement d’exister.

La combinaison qui revient le plus souvent

Une application web installable pour tout le monde, et une application native réservée à la minorité qui a réellement besoin du matériel inaccessible autrement. La base de code principale reste unique ; le natif se limite à ce qui le justifie.

C’est moins net qu’un choix de camp, mais cela reflète la répartition réelle des usages.