16. Application web ou mobile : choisir selon les usages réels

En bref

Choisissez une application web lorsque le service doit être accessible rapidement depuis plusieurs appareils, se partager par un lien et évoluer souvent. Choisissez une application mobile native lorsque l’usage dépend réellement du téléphone : appareil photo, Bluetooth, localisation continue, travail hors ligne exigeant, notifications critiques ou traitement en arrière-plan.

Dans beaucoup de projets, le meilleur premier choix est une application web responsive. Elle permet de valider le processus avec moins de versions à maintenir. Une application mobile devient pertinente lorsque des usages mesurés montrent que le navigateur crée une vraie limite. La grille ci-dessous aide à décider sur des situations concrètes plutôt que sur une préférence technique.

Quelle différence faut-il regarder en premier ?

La différence utile n’est pas l’apparence. Une application web peut offrir une interface très proche d’une application mobile. La vraie question est où, quand et avec quelles contraintes la personne accomplit sa tâche.

Une application web s’ouvre dans un navigateur. Une Progressive Web App peut aussi être installable et utiliser un service worker pour fonctionner partiellement hors ligne. MDN précise cependant que l’installation et les capacités disponibles varient selon le navigateur et la plateforme (MDN, applications web progressives). Il faut donc tester les appareils réellement utilisés par l’équipe.

Une application mobile distribuée sur iOS ou Android peut intégrer plus profondément les fonctions du téléphone. Cette proximité ne signifie pas qu’elle peut tout exécuter librement. Sur iOS, les traitements en arrière-plan passent par des mécanismes encadrés par le système, qui choisit quand accorder du temps à l’application (Apple, Background Tasks).

Dans quels cas une application web est-elle le meilleur choix ?

Une application web est souvent adaptée lorsque le travail se fait principalement au bureau, avec une connexion disponible et des données partagées entre plusieurs rôles.

Elle convient particulièrement pour :

• un portail client ou partenaire accessible par un lien ;
• un CRM, un outil de suivi ou un tableau de bord ;
• une administration utilisée sur ordinateur et tablette ;
• un formulaire métier qui doit être mis à jour fréquemment ;
• un outil destiné à des utilisateurs externes qui ne veulent pas installer une application ;
• un premier produit dont le processus doit encore être validé.

Le déploiement est centralisé : une mise à jour du serveur peut être disponible immédiatement pour tous les utilisateurs. Il reste néanmoins nécessaire de tester les navigateurs pris en charge, la sécurité, l’accessibilité et le comportement en cas de réseau instable.

Le web devient moins confortable si l’utilisateur doit accomplir une longue série d’actions dehors, sans réseau, avec des photos, des capteurs ou des transferts importants. Il ne faut pas conclure trop vite que « le mobile est obligatoire » : un prototype web sur le téléphone permet souvent de mesurer où se trouve la limite exacte.

Quand une application mobile devient-elle justifiée ?

Une application mobile est pertinente lorsque sa présence sur le téléphone améliore directement une tâche répétée. L’argument « nos clients sont sur mobile » ne suffit pas : un site responsive répond déjà à de nombreux parcours de consultation et de saisie.

Les signaux les plus solides sont les suivants :

• l’utilisateur travaille régulièrement sans connexion et doit synchroniser plus tard ;
• il prend beaucoup de photos, scanne des documents ou lit des codes sur le terrain ;
• le service dépend du Bluetooth, de capteurs, d’accessoires ou de fonctions propres à l’appareil ;
• des téléchargements ou traitements doivent se poursuivre selon les mécanismes d’arrière-plan du système ;
• l’usage quotidien bénéficie d’une ouverture immédiate, d’un stockage local et d’une navigation conçue pour une main ;
• les notifications font partie du processus opérationnel, avec une règle claire sur leur utilité.

Apple recommande d’utiliser les modes d’exécution en arrière-plan avec parcimonie, car ils peuvent affecter les performances et la batterie (Apple, modes d’exécution en arrière-plan). Une promesse comme « synchronisation permanente » doit donc être traduite en scénarios précis et testée sur de vrais appareils.

Il faut aussi prévoir la distribution. Apple demande qu’une application publiée apporte une utilité et une expérience qui dépassent un simple site emballé dans une coque mobile (App Review Guidelines, section 4.2). Une application interne ou distribuée autrement possède ses propres contraintes de comptes, de signature et de mise à jour.

Comment comparer les deux options sur un projet réel ?

Ce tableau n’attribue pas automatiquement un vainqueur. Il permet de repérer le critère qui influence réellement le projet. Un portail consulté deux fois par an privilégiera probablement l’accès par lien. Un outil utilisé chaque jour par des techniciens dans des zones sans réseau demandera une étude mobile sérieuse.

Faut-il construire les deux dès le début ?

Rarement. Construire simultanément une application web et deux applications mobiles multiplie les interfaces à concevoir, tester, sécuriser et maintenir. Cela peut être justifié si les publics et les usages sont déjà établis, mais c’est un mauvais moyen de compenser un besoin encore flou.

Une progression plus sûre consiste à séparer trois couches :

1. les données et les règles métier, accessibles par une API sécurisée ;
2. l’interface principale, souvent web pour valider le processus ;
3. les expériences spécialisées, ajoutées sur mobile lorsque l’usage le prouve.

Cette architecture ne garantit pas qu’un futur passage au mobile sera gratuit. Elle évite en revanche d’enfermer toutes les règles dans une seule interface. Elle permet aussi de conserver un back-office web même si une application mobile est créée pour les utilisateurs de terrain.

Une autre option est une base multiplateforme. Elle peut partager une partie du code entre iOS et Android, mais elle ne supprime ni les tests sur appareils, ni la gestion des permissions, ni les règles des stores. Le choix doit dépendre des compétences de l’équipe, des fonctions natives et du niveau de finition attendu.

Quelle méthode utiliser pour décider sans surinvestir ?

1. Décrire trois scénarios fréquents

Écrivez des situations observables : « le technicien ouvre le dossier chez le client, prend quatre photos et fait signer le rapport » ou « la responsable compare les dossiers sur deux écrans au bureau ». Évitez les listes abstraites de fonctionnalités.

2. Noter les contraintes de chaque scénario

Pour chaque étape, relevez l’appareil, la qualité du réseau, les données nécessaires, les permissions, la durée, la fréquence et les erreurs actuelles. Une fonction utilisée une fois par trimestre ne doit pas peser autant qu’une action répétée cinquante fois par jour.

3. Tester le parcours mobile avec un prototype web

Un prototype responsive permet de vérifier la taille des champs, la navigation, la saisie et la compréhension du processus. Faites-le essayer dans le lieu réel d’utilisation, avec le réseau et la luminosité habituels.

4. Mesurer les limites rencontrées

Notez les blocages concrets : attente du réseau, reprise après interruption, difficulté à joindre une photo, authentification répétée ou absence d’une fonction matérielle. Une préférence comme « je voudrais une app » devient alors une exigence vérifiable.

5. Chiffrer le cycle complet

Comparez conception, développement, tests, comptes développeur, publication, support, suivi des versions du système et maintenance. Pour le web, incluez aussi l’hébergement, les navigateurs ciblés, la sécurité et les sauvegardes. Mon guide sur le budget réel d’un projet numérique aide à séparer le socle, les coûts récurrents et les évolutions.

6. Décider avec un seuil de passage

Formulez une règle avant de développer. Par exemple : « nous créons l’application mobile si le pilote confirme que le hors-ligne bloque plus de deux interventions par semaine » ou « si l’appareil photo réduit suffisamment les ressaisies ». Le seuil doit venir du processus, pas d’une mode technologique.

Quelles erreurs éviter pendant le choix ?

La première erreur consiste à choisir une plateforme avant d’avoir observé les utilisateurs. La deuxième est de réduire le coût à la première version. Une application utile devra évoluer avec les appareils, les systèmes, les règles de sécurité et le métier.

Évitez aussi ces raccourcis :

• croire qu’une application mobile fonctionne automatiquement hors ligne ;
• promettre des traitements continus en arrière-plan sans vérifier les règles du système ;
• transformer un site vitrine en application simplement pour être présent dans un store ;
• négliger le back-office nécessaire pour gérer les utilisateurs et les contenus ;
• demander toutes les permissions dès l’ouverture, sans lien avec l’action en cours ;
• vouloir reproduire exactement la même interface sur ordinateur et téléphone.

Si votre besoin concerne surtout un processus interne qui dépasse Excel, commencez par le guide remplacer Excel par un outil métier. Pour décider entre un produit existant et un développement spécifique, consultez aussi application sur mesure ou logiciel standard.

Quelle première étape faire cette semaine ?

Choisissez un seul utilisateur et observez une tâche complète. Notez chaque changement d’appareil, chaque perte de réseau, chaque photo, chaque double saisie et chaque interruption. Vous saurez rapidement si le problème vient de l’interface, du processus ou d’une capacité propre au téléphone.

Je conçois des applications web et mobiles sur mesure pour des indépendants, PME et organisations. Décrivez-moi le parcours et le lieu d’utilisation : je pourrai vous aider à comparer un prototype web, une application mobile ou une progression en deux étapes.

FAQ

Une application web peut-elle fonctionner hors ligne ?

Oui, certaines données et certains écrans peuvent être mis en cache avec un service worker. Il faut toutefois définir les informations disponibles hors ligne, les conflits de synchronisation et les navigateurs pris en charge. Le hors-ligne n’apparaît pas automatiquement parce que le site est installable.

Une Progressive Web App remplace-t-elle toujours une application mobile ?

Non. Elle peut suffire pour de nombreux formulaires, portails et outils de suivi. Une intégration matérielle avancée, des traitements d’arrière-plan particuliers ou une expérience terrain très exigeante peuvent justifier une application native ou multiplateforme.

Peut-on commencer par le web puis créer l’application mobile ?

Oui, si les données et règles métier sont séparées de l’interface. Le prototype web permet de valider le processus. L’application mobile peut ensuite se concentrer sur les usages que le navigateur couvre mal.

Une application mobile coûte-t-elle forcément plus cher ?

Pas dans tous les cas, mais elle ajoute généralement la distribution, les tests sur appareils, les permissions et le suivi des versions du système. Le coût dépend surtout du périmètre, des intégrations et du niveau de fiabilité attendu.

Faut-il publier une application interne sur l’App Store public ?

Pas nécessairement. Apple propose plusieurs modes de distribution selon le public et l’organisation. Le choix doit être défini avant le développement, car il influence les comptes, la signature et le déploiement.

Comment choisir entre une application native et multiplateforme ?

Listez d’abord les fonctions propres au téléphone, les performances attendues et les compétences disponibles pour la maintenance. Une base partagée peut réduire certaines duplications, mais chaque plateforme doit tout de même être testée et intégrée correctement.