Application web ou application mobile : choisir selon l'endroit où vos équipes travaillent

Application web ou mobile : le tableau de décision

Une application web s'utilise dans un navigateur, sur ordinateur, tablette ou téléphone, à partir d'une adresse. Une application mobile s'installe sur le téléphone depuis l'App Store, Google Play ou une distribution privée, et accède directement aux fonctions de l'appareil.

Où vos utilisateurs travaillent-ils ?

Le critère qui tranche le plus souvent est le lieu de travail. L'assistante qui organise le planning de vingt techniciens a besoin d'un grand écran, d'un clavier, de filtres et de vues par semaine : une application web lui convient. Le technicien qui reçoit ce planning intervient dans une chaufferie, sur un toit ou chez un client, une main occupée. Il lui faut trois boutons, l'appareil photo et une zone de signature.

Ces deux personnes manipulent la même donnée, mais pas avec le même outil. Imposer une application mobile à l'assistante la ralentit ; imposer au technicien un écran pensé pour l'ordinateur produit des rapports incomplets, remplis le soir de mémoire. La page application mobile pour équipes terrain détaille ce second cas.

Le réseau est-il garanti là où l'outil sert ?

Si le réseau n'est pas garanti, l'application mobile l'emporte. Une application web a besoin d'une connexion pour presque tout : un formulaire validé dans un parking souterrain peut être perdu si rien n'est prévu.

Une application mobile conçue pour le hors ligne enregistre tout sur le téléphone, puis envoie les données au retour du réseau. Pour Cap Vert, qui nettoie des grandes surfaces et des panneaux photovoltaïques, YMHB Web a construit une application iOS et Android qui gère des files d'attente distinctes pour les modifications, les photos, les PDF et les e-mails, avec reprise automatique. Le PDF du rapport se génère sur le téléphone.

Une application web installable couvre une partie de ce besoin pour des consultations et des saisies courtes : le comparatif PWA ou application native en précise les limites, notamment sur iPhone.

Appareil photo, GPS, capteurs : de quoi l'application a-t-elle besoin ?

Une application web peut proposer de joindre une photo ou de partager sa position au moment d'une saisie. Dès que l'usage du matériel devient intensif, continu ou spécifique, l'application mobile reprend l'avantage.

La documentation de Flutter, framework utilisé par YMHB Web notamment pour l'application Cospo Line, montre ce qui s'ouvre côté application installée : elle associe à chaque framework d'Apple un module prêt à l'emploi, par exemple CoreLocation pour le GPS, AVFoundation pour les fonctions avancées de l'appareil photo, CoreMotion pour les capteurs de mouvement ou HealthKit pour les données de santé. Les cas où le mobile s'impose :

• scanner des dizaines de codes-barres ou de QR codes à la suite, à un comptoir ou à l'entrée d'un événement ;
• suivre une tournée à partir de la position du véhicule ;
• dialoguer en Bluetooth avec une imprimante d'étiquettes, une balance ou un capteur ;
• travailler avec le SDK d'un constructeur, comme l'application embarquée du robot de livraison de Sakura France Service, écrite en Kotlin pour Android.

Diffusion : un lien ou les stores ?

Une application web se diffuse par un lien et un identifiant : rien à installer, rien à faire valider. Une application mobile passe par un store ; chez Apple, la documentation d'App Store Connect distingue trois modes de diffusion :

• Publique : l'application est visible dans l'App Store des pays choisis.
• Non répertoriée : accessible uniquement par un lien direct, absente des catégories, des classements et des résultats de recherche de l'App Store.
• Privée : réservée aux entreprises et organisations désignées, qui la reçoivent via Apple Business ou Apple School Manager, puis la déploient par leur outil de gestion de flotte ou par des codes.

Ce choix se fait au départ. Apple indique qu'une fois l'application approuvée, son mode de diffusion ne peut plus changer, à une exception près : une application publique peut devenir non répertoriée. Passer du privé au public impose de créer une nouvelle fiche et de soumettre à nouveau l'application. C'est par ce canal privé, via Apple Business Manager, que l'application iOS de Cap Vert a été publiée, puis déployée sur la flotte d'appareils du client.

Mises à jour et maintenance : quel suivi prévoir ?

Une application web se met à jour une fois, sur le serveur, et chacun reçoit la nouvelle version au prochain chargement. Une application mobile suit un cycle plus long, en quatre temps :

1. La revue : Apple indique examiner en général au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures, avec une revue accélérée possible pour un correctif critique ou un événement daté.
2. L'installation : chaque téléphone doit récupérer la nouvelle version ; une flotte gérée par l'entreprise simplifie ce point.
3. Les exigences d'Apple : depuis le 28 avril 2026, les applications envoyées sur App Store Connect doivent être compilées avec Xcode 26 ou plus récent et le SDK d'iOS 26. Une application restée longtemps sans évolution devra donc être recompilée avec ces outils avant sa prochaine mise à jour.
4. Les versions de système : il faut fixer les versions minimales prises en charge. La version actuelle de Flutter, par exemple, prend en charge iOS à partir de la version 15 et Android à partir du niveau d'API 24.

Ce suivi a un coût récurrent à prévoir dès le départ, comme l'hébergement : c'est l'objet de l'accompagnement après la mise en service.

Combiner les deux : un back-office web et une application terrain

Dans un projet métier, la vraie question est souvent « qui utilise quoi », pas « web ou mobile ». Le schéma qui revient : un back-office web pour le bureau (planning, clients, facturation, statistiques) et une application mobile pour le terrain, branchés sur la même base de données et la même API.

• Cap Vert : un tableau de bord web regroupe clients, chantiers, planning, rapports et exports ; l'application iOS et Android sert aux équipes sur site.
• Tapas Tour 2026 : l'application publique de vote par QR code s'appuie sur un back-office qui gère l'édition, les restaurants, les tapas multilingues, les QR codes et les résultats, et sur une API dédiée.
• Cospo Line : l'application mobile et le site web offrent les mêmes fonctions sur une base commune.

Cette architecture évite de choisir un camp : chaque profil reçoit l'outil adapté, et la donnée n'est saisie qu'une fois.

Notre verdict selon votre situation

• Tous les utilisateurs sont au bureau : application web. Le téléphone servira à consulter, pas à produire.
• Les utilisateurs sont des clients qui passent rarement : application web, éventuellement installable. Demander d'installer une application pour une commande par trimestre crée une friction inutile.
• Une partie des utilisateurs travaille sur le terrain : back-office web et application mobile, sur la même base.
• Le terrain est souvent sans réseau, ou l'outil pilote du matériel : application mobile conçue pour le hors ligne, sans compromis.
• Le service vise le grand public et se découvre dans les stores : application mobile, avec un site web qui la présente et la fait trouver.

Quand aucune des deux options ne convient

Parfois, aucun développement n'est la bonne réponse. Si un logiciel du marché couvre l'essentiel du besoin avec sa propre application mobile, mieux vaut l'adopter, quitte à le connecter à vos outils. Si le besoin se limite à un formulaire et un tableau partagé pour cinq personnes, un outil no-code ou un tableur bien structuré suffit le temps de valider l'usage. Et si le processus change encore chaque mois, le figer dans une application revient à coder une organisation provisoire. YMHB Web le dit dès le cadrage : on décrit d'abord le travail réel, puis on choisit le support.