Application web ou mobile : choisir selon le travail à effectuer

Décrire les situations avant de choisir le support

Listez les actions principales et l'appareil utilisé pour chacune. Un responsable peut préparer un planning sur grand écran tandis qu'un technicien consulte son intervention sur téléphone. Un client qui ouvre un document une fois de temps en temps n'a pas nécessairement intérêt à installer une application. Le même système peut offrir plusieurs interfaces selon les rôles.

Notez les conditions difficiles : interruption pendant la saisie, faible réseau, photo à joindre, notification à ouvrir ou changement de compte. Ces situations déterminent les essais à réaliser. Elles sont plus utiles qu'une préférence générale pour le web ou le mobile, car elles expliquent ce que la solution doit permettre concrètement.

Comprendre ce que recouvrent web, PWA et application installée

Une application web s'utilise dans un navigateur. Une PWA peut ajouter des possibilités d'installation et des fonctions hors connexion lorsqu'elles sont conçues pour cela. Une application distribuée sur téléphone possède son propre parcours d'installation et de mise à jour. Le fait d'avoir une icône sur l'écran d'accueil ne prouve pas que toutes les données sont disponibles sans réseau.

MDN documente des différences d'installation des PWA selon le navigateur et le système. Le support des fonctions doit donc être vérifié sur les appareils cibles. Dans la décision métier, retenez ce que l'utilisateur peut réellement faire et les contraintes qu'il devra accepter, plutôt qu'une étiquette technique présentée comme supérieure dans tous les cas.

Définir précisément le besoin hors connexion

Exemple hypothétique : un technicien doit ouvrir une intervention dans un local sans réseau, saisir un compte rendu et joindre une photo. Précisez ce qui aura été téléchargé avant son arrivée, ce qui peut être modifié sans connexion et comment l'outil confirmera l'envoi au retour du réseau. Si un collègue modifie le même dossier, une règle doit résoudre ce désaccord.

MDN décrit les mécanismes permettant aux applications web de mettre des ressources en cache et de gérer certaines opérations en arrière-plan. Leur existence ne rend pas automatiquement une application utilisable hors connexion. Le comportement doit être conçu, testé et expliqué. La même exigence de preuve s'applique à une application mobile dédiée.

• Ouvrir les informations nécessaires après perte du réseau.
• Distinguer brouillon local, envoi en attente et données confirmées par le serveur.
• Reprendre après fermeture de l'application sans perdre la saisie.
• Éviter un double enregistrement après une tentative d'envoi répétée.

Tester les fonctions du téléphone qui comptent

La caméra, les fichiers, les notifications et la localisation peuvent modifier le choix de support. Demandez une démonstration sur le matériel prévu et avec les autorisations réellement accordées. Il faut aussi vérifier le parcours quand l'utilisateur refuse une permission : peut-il sélectionner un fichier à la place d'une photo ou poursuivre la tâche autrement ?

Pour une notification, testez l'ouverture du bon dossier, puis le cas où l'utilisateur n'est plus connecté. Pour un scan, observez la lisibilité de la capture et la correction possible. Une capture d'écran de la fonction ne démontre ni sa fiabilité dans ces conditions ni sa disponibilité sur tous les appareils.

Comparer la mise en service et le suivi

Le budget doit couvrir les interfaces retenues, les connexions au système commun et les essais nécessaires. Ajoutez l'accompagnement des utilisateurs : accès par lien, installation, récupération du compte et support. Deux interfaces qui partagent les données peuvent éviter la ressaisie, mais exigent de maintenir la cohérence des rôles et des fonctions.

Définissez la politique de versions. Une modification du serveur doit rester compatible avec les interfaces encore utilisées, ou annoncer clairement la mise à jour nécessaire. Vérifiez qui gère les comptes de distribution et les accès techniques. La décision comprend ce suivi après lancement, pas seulement le développement du premier écran.

Choisir à partir d'un parcours démontré

Préparez une comparaison courte : tâches à réaliser, contraintes indispensables, résultat de l'essai et limite acceptée. Une application web peut être retenue pour la consultation et la gestion sur plusieurs appareils. Une interface mobile dédiée peut être justifiée par un usage terrain fréquent ou une fonction qui nécessite une intégration particulière. Une combinaison reste possible.

Commencez par le parcours le plus contraignant et faites-le tester par une personne concernée. Si aucune exigence ne différencie les options, privilégiez le périmètre le plus simple à déployer et à maintenir dans votre contexte. Le choix du framework intervient ensuite ; il ne remplace pas la décision sur les usages et les preuves attendues.