Application web ou mobile : partir de l’usage, pas de l’icône
Par Pixit
« Il nous faut une application. » D’accord. Mais faut-il l’installer ? La réponse dépend de ce que les utilisateurs feront, à quelle fréquence et dans quelles conditions. L’icône sur l’écran d’accueil fait plaisir ; elle ne remplace pas une bonne raison d’ouvrir le produit.
Le lien est parfois le meilleur point d’entrée
Une application web se consulte dans un navigateur. Elle peut convenir à un portail client, un outil interne ou un service que l’on utilise ponctuellement. Le lecteur ouvre un lien depuis un message et retrouve son espace sans passer d’abord par une installation.
Imaginez un client qui consulte une proposition une fois par mois. Lui imposer un téléchargement et une mise en route supplémentaire mérite une justification. Commencez par tester son parcours sur téléphone : le web ne signifie pas une version desktop écrasée dans un petit écran.
Le mobile se justifie par un usage régulier ou spécifique
Une application mobile peut être pertinente pour un outil utilisé chaque jour, des interactions étroitement liées à l’appareil ou une expérience qui doit rester très intégrée à son système. Listez les besoins réels : prise de photo, localisation, notifications, fonctionnement sans réseau.
Ne cochez pas ces fonctions pour faire complet. Pour un technicien sur le terrain, photographier une intervention puis synchroniser plus tard peut être essentiel. Pour une demande de devis occasionnelle, ce n’est probablement pas le cœur du problème. Deux métiers, deux décisions.
Et la PWA dans tout ça ?
Une application web progressive peut offrir certaines possibilités proches d’une application installée. Leur disponibilité varie selon le navigateur, l’appareil et la fonction : il faut vérifier les environnements visés plutôt que promettre une équivalence universelle.
Présentez une petite liste de téléphones et de navigateurs réellement utilisés par votre public. Testez dessus la fonction décisive avant d’engager toute la réalisation. Une démonstration sur le seul téléphone du développeur ne constitue pas une validation de votre marché.
Penser aux coûts de fonctionnement
Le budget comprend les interfaces, mais aussi le serveur, les données, les droits d’accès, les tests et les évolutions. Avec une distribution mobile, prévoyez également la préparation des publications et le suivi des versions sur les plateformes retenues.
Précisez qui maintient les comptes de publication et comment les utilisateurs reçoivent les corrections. Demandez aussi ce qui se passe lorsqu’une connexion disparaît au milieu d’une action. Une réservation envoyée deux fois n’est pas un détail de design.
Peut-on commencer par le web ?
Oui, si cela permet de tester le service dans de bonnes conditions. Concevoir clairement les données et les règles métier peut faciliter une évolution future, sans rendre automatiquement gratuit le développement d’une application mobile.
Chez Pixit, nous proposons de trancher avec trois scénarios d’utilisation, dont un qui se passe mal : réseau coupé, permission refusée ou appareil ancien. Si le produit tient encore debout, le choix commence à être solide. Une application mérite mieux qu’un choix de format fait par habitude.
