Choisissez une application web si l’accès doit être immédiat, occasionnel, partageable par lien ou réparti entre ordinateur et téléphone. Choisissez une application mobile si une tâche fréquente, réalisée en mobilité, dépend réellement du hors-ligne, des notifications ou des capacités du téléphone. Prévoyez les deux seulement lorsque des rôles distincts ont des contraintes distinctes, pas pour couvrir toutes les possibilités dès le lancement.
Comparaison et documentations vérifiées le 8 septembre 2026. Les capacités du web, les règles des stores et la compatibilité des appareils évoluent : vérifiez-les sur le parc réellement ciblé avant de figer le périmètre.
Commencez par la scène d’usage, pas par le support
« Nos utilisateurs sont sur mobile » ne suffit pas à justifier une application à installer. Une personne peut consulter un lien sur son téléphone une fois par trimestre, puis traiter le dossier sur ordinateur. À l’inverse, un technicien peut ouvrir le même outil vingt fois par jour, dans un bâtiment sans réseau, avec des gants et l’appareil photo du téléphone.
Décrivez d’abord une scène observable : qui agit, dans quel lieu, sur quel appareil, avec quel réseau et pour obtenir quel résultat. Le bon support est celui qui retire l’obstacle principal de cette scène.
| Observation à recueillir | Ce qu’elle change dans la décision | Preuve à obtenir avant le devis |
|---|---|---|
| Premier accès | Un lien favorise le web ; une installation ajoute une étape. | Faire réaliser le premier parcours sans explication. |
| Fréquence | Un usage quotidien peut justifier une icône, une session persistante et des gestes courts. | Observer la fréquence réelle de la tâche, pas celle espérée. |
| Lieu et réseau | Un réseau instable oblige à définir ce qui reste possible hors ligne. | Tester les sites et appareils représentatifs. |
| Appareil | Un écran de bureau favorise les tableaux denses ; le téléphone favorise une action située et courte. | Lister les appareils réellement disponibles par rôle. |
| Fonction du téléphone | Appareil photo, géolocalisation, Bluetooth ou arrière-plan peuvent devenir structurants. | Prototyper la fonction critique sur les plateformes visées. |
| Distribution | Le web s’ouvre par URL ; une application implique installation, versions et règles de distribution. | Tester le parcours d’accès et identifier qui gère les stores. |
Cette collecte distingue aussi le site responsive, l’application web dans un navigateur, la PWA installable et l’application mobile distribuée pour iOS ou Android.
Quand une application web est-elle le meilleur premier choix ?
Une application web est généralement le meilleur point de départ quand la valeur dépend d’un accès sans installation. C’est le cas d’un portail ouvert depuis un e-mail, d’un formulaire transmis à des clients occasionnels ou d’un outil B2B utilisé sur plusieurs ordinateurs. Elle convient aussi aux comparaisons, tableaux et saisies longues, ainsi qu’aux contenus qui doivent rester partageables par URL.
Le web peut utiliser caméra, géolocalisation et installation, mais pas de façon identique partout. Il devient insuffisant si l’usage central se dégrade fortement lorsque la page se ferme, le réseau disparaît ou une fonction reste partielle. Testez alors une PWA ou une application mobile sur cette scène précise.
Quand une application mobile justifie-t-elle son installation ?
Une application mobile se justifie quand l’installation rend une tâche centrale possible ou plus fiable. La fréquence seule n’est pas décisive : il faut identifier le bénéfice concret du canal installé.
Les signaux les plus solides sont :
- une action répétée en déplacement sur un appareil connu ;
- un mode hors ligne avec consultation, modification et synchronisation ;
- des notifications attendues qui déclenchent une action ;
- l’utilisation soutenue de la caméra, de la géolocalisation, du Bluetooth, de capteurs ou de l’arrière-plan ;
- un parc d’appareils maîtrisé ou une présence en store explicitement attendue.
Une application mobile ajoute un parcours d’installation, des permissions, des versions de systèmes, des publications et de la maintenance. Si elle ne fait qu’afficher les pages du site, ces coûts n’apportent pas de valeur. Apple demande qu’une application dépasse un site web réemballé, et Google Play refuse les applications à fonctionnalité trop limitée (Apple Developer, Google Play Console).
Un store est un canal de distribution avec ses règles, pas un argument automatique de visibilité. Formulez ce que l’application installée permet de mieux faire et comment vous observerez cet effet.
Une PWA peut-elle éviter de développer une application mobile ?
Une Progressive Web App peut être installée depuis un navigateur, disposer d’une icône, mettre en cache une interface et recevoir des messages push (MDN sur l’installation, MDN sur le hors-ligne).
Une PWA n’est pas une application mobile à moindre coût dans tous les cas. Installation, arrière-plan, permissions et API varient selon navigateur et plateforme. Sur iPhone et iPad, Apple documente Web Push à partir d’iOS et iPadOS 16.4 pour les applications web ajoutées à l’écran d’accueil : installation et consentement font partie du parcours (Apple Developer).
Choisissez une PWA si l’URL reste importante, si l’installation aide des utilisateurs réguliers et si les fonctions nécessaires passent les tests sur leurs appareils. Écartez-la si une capacité critique reste incertaine ou si l’installation crée trop d’assistance.
L’arbre de décision en sept questions
Utilisez cet arbre sur chaque rôle, pas une seule fois pour tout le produit.
- Faut-il entrer sans préparation ? Si le premier usage vient d’un lien, d’un QR code ou d’une invitation ponctuelle, conservez le web.
- La tâche est-elle fréquente et située ? Pour un usage quotidien sur le terrain, testez une expérience installée. Pour un usage mensuel au bureau, privilégiez le web.
- Que faut-il faire sans réseau ? Écrivez les actions, données, durées et conflits de synchronisation. « Fonctionner hors ligne » n’est pas une spécification.
- Quelle capacité du téléphone est indispensable ? Nommez le comportement, l’appareil et la fiabilité attendue. Sinon, justifiez l’application autrement.
- La notification déclenche-t-elle une action attendue ? Si elle peut attendre la prochaine ouverture, un e-mail peut suffire. Sinon, testez délivrance et permission.
- Qui installe, met à jour et assiste ? Un parc professionnel administré diffère d’un public occasionnel. Identifiez aussi le propriétaire des comptes de distribution.
- Les rôles ont-ils la même réponse ? Sinon, un portail web et une application mobile ciblée peuvent partager les comptes, les données et les règles métier.
À la fin, la décision doit prendre cette forme : « pour ce rôle et cette tâche, nous choisissons ce support parce qu’il retire cet obstacle ; nous le vérifierons avec ce test ». Une préférence comme « le mobile paraît plus moderne » ne passe pas ce contrôle.
Exemple rempli : une PME de maintenance sur sites industriels
L’exemple suivant est fictif. Une PME emploie 35 techniciens équipés de téléphones Android professionnels. Six gestionnaires organisent les interventions sur ordinateur. Les clients ouvrent quelques demandes par an depuis un e-mail. Certains sites industriels reçoivent mal le réseau.
Trois options sont comparées : tout faire dans une application web responsive, imposer une application mobile à chaque rôle ou séparer les interfaces autour d’un même service.
| Rôle et contrainte | Décision illustrée | Conséquence sur la première version |
|---|---|---|
| Client, usage rare après un lien | Portail web sans installation | Déposer une demande, joindre un document et suivre son statut. |
| Gestionnaire, planning dense sur grand écran | Application web | Vue planning, attribution, correction et export ; pas de déclinaison mobile complète. |
| Technicien, usage quotidien et réseau instable | Application mobile Android ciblée | Ordres de mission stockés, photos, compte rendu hors ligne et synchronisation contrôlée. |
Le portail web retire la friction d’accès des clients et offre l’espace nécessaire aux gestionnaires. L’application mobile justifie son installation par une boucle terrain complète : recevoir une mission, consulter les données, prendre des photos, faire signer, clôturer et synchroniser.
La première version ne couvre pas iOS, puisque le parc observé est Android. L’équipe doit aussi décider ce qui se passe si un gestionnaire modifie une mission pendant qu’un technicien travaille hors ligne : dernière modification gagnante, blocage, fusion ou revue manuelle. Ce choix technique agit directement sur les erreurs et l’assistance.
Le pilote mesure les interventions terminées en zone mal couverte, les synchronisations échouées, les corrections, l’aide demandée et le temps du parcours. La PME fixe ses seuils avant le test. Si le hors-ligne s’avère rare ou si une PWA couvre le parc, elle peut simplifier le canal.
Que conserver, reporter et mesurer dans la première version ?
Le support choisi ne doit pas rouvrir toutes les idées du produit. Reliez-le au périmètre du MVP et traitez chaque capacité comme une hypothèse ou une contrainte.
| Décision | À conserver | À reporter | À mesurer |
|---|---|---|---|
| Accès | Le chemin nécessaire au rôle prioritaire. | Les déclinaisons pour des appareils non observés. | Abandon avant la première action utile. |
| Hors-ligne | Une boucle précise et ses conflits de synchronisation. | Le téléchargement de toutes les données « au cas où ». | Échecs, doublons, corrections et volume stocké. |
| Notifications | Les événements qui réclament une action datée. | Les relances promotionnelles et alertes de confort. | Permission, délivrance, ouverture et action, sans confondre ces étapes. |
| Fonctions du téléphone | La capacité indispensable au résultat. | Les intégrations matérielles décoratives. | Taux d’échec et recours à une procédure alternative. |
| Distribution | Le canal correspondant au parc retenu. | Le second store sans utilisateur ciblé. | Installation, mise à jour, support et usage réel. |
Une estimation doit préciser plateformes, versions, hors-ligne, permissions, publication et compatibilité. Une ligne « application iOS et Android » ne décrit pas ces engagements. Une fois le mobile justifié, la décomposition du budget d’une application aide à vérifier les postes oubliés.
Les questions à poser avant de figer le support
Demandez au prestataire de relier sa recommandation à des scènes d’usage :
- quels rôles et appareils ont été observés ;
- quelle action devient trop fragile sur le web ;
- quelles données restent hors ligne et comment les conflits sont traités ;
- qui possède les comptes de store et répond aux revues ;
- quel test autorisera ou annulera le second canal.
Si ces réponses manquent, un prototype ciblé vaut mieux qu’un choix de framework : il teste la tâche critique avant la distribution.
Préparer la décision avec Klaapp
Un premier échange sur la création de produit peut cartographier les rôles, leurs appareils, les conditions réseau et la boucle d’usage à prototyper. L’objectif est de décider quel canal construire d’abord, quelles incertitudes tester et ce qu’il est raisonnable de ne pas développer.
Questions fréquentes
Une application web fonctionne-t-elle sur un téléphone ?
Oui, si son interface est conçue et testée pour les interactions mobiles. Un navigateur ne rend pas automatiquement confortable un tableau dense ou une saisie longue.
Une PWA remplace-t-elle toujours une application mobile ?
Non. Elle peut couvrir installation, cache, hors-ligne et notifications, mais sa pertinence dépend du navigateur, de l’installation et des fonctions critiques.
Faut-il être dans l’App Store et Google Play pour être crédible ?
Pas systématiquement. Un portail B2B peut gagner davantage par un accès simple et fiable. Les stores comptent si les utilisateurs y attendent le produit ou si l’installation apporte une valeur démontrable.
Peut-on commencer par le web puis créer une application mobile ?
Oui, si comptes, données et règles métier peuvent servir plusieurs interfaces. Cette séquence valide le service, mais la sécurité, la synchronisation et la publication doivent être prévues avant le second canal.
Sources
- MDN — Making PWAs installable
- MDN — Offline and background operation
- Apple Developer — Sending web push notifications in web apps and browsers
- Apple Developer — App Review Guidelines
- Google Play Console — Functionality, Content, and User Experience
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.