Application web ou mobile : que choisir pour une équipe de terrain ?
Une équipe qui travaille en déplacement peut avoir besoin d’un outil simple sur téléphone, sans avoir besoin d’une application native. Le bon choix se fait sur le lieu d’usage : réseau disponible, gestes à accomplir, matériel et reprise des données.
06 chapitres
Observer une intervention avant de choisir la plateforme
Observer une tâche de bout en bout
Suivez une tâche entière : trouver le dossier, lire les consignes, prendre une photo, relever une information et terminer le compte rendu. Notez où la personne se trouve, ce qu’elle tient dans les mains et ce qui l’interrompt. Une maquette sur grand écran ne révèle pas ces contraintes.
Exemple : une intervention avec peu de réseau
Dans un exemple fictif, un technicien consulte la fiche avant de partir, saisit des relevés dans un bâtiment peu couvert, puis transmet son rapport à son retour. Le besoin central est la continuité de cette saisie. Le choix ne peut pas être tranché uniquement par la présence d’un téléphone.
Inventorier les appareils utilisés
Relevez les appareils et versions réellement utilisés. Téléphones personnels ou fournis, tablettes, scanners et ordinateurs de bureau ne se gèrent pas de la même manière. Demandez aussi qui installe, met à jour et remplace les appareils.
- Lieu d’usage et qualité du réseau.
- Tâche complète, avec interruptions possibles.
- Appareils, systèmes et versions utilisés.
- Personne responsable du parc et de l’assistance.
Comparer application web, PWA et application mobile
Application web
Une application web se consulte dans un navigateur. Elle peut être conçue pour le téléphone et l’ordinateur avec des interfaces adaptées. Elle convient notamment lorsque les fonctions nécessaires sont disponibles dans les navigateurs ciblés et que la distribution par un lien facilite l’accès.
PWA
Une PWA est une application web qui utilise des possibilités supplémentaires de la plateforme, par exemple l’installation ou certains usages hors connexion. Ces capacités se conçoivent et se testent ; elles ne viennent pas automatiquement avec le nom. Le navigateur et le système restent des contraintes à vérifier.
Application mobile installée
Une application mobile installée peut être pertinente pour une intégration poussée au matériel ou au système. Elle ajoute son mode de distribution, ses versions et son cycle de maintenance. Le choix natif ou multiplateforme vient ensuite, selon les fonctions et les appareils à couvrir.
Choisir selon l’accès et l’intégration attendus
MDN distingue les applications web, les applications propres à une plateforme et les capacités ajoutées par une PWA.
- Web
Un accès par le navigateur
Partager une adresse et adapter l’interface aux écrans visés.
- PWA
Des capacités web supplémentaires
Concevoir les fonctions disponibles sur les systèmes ciblés.
- Mobile
Une application installée
Évaluer la distribution et l’intégration au système.
Décrire ce qui doit fonctionner sans réseau
Préciser les actions hors connexion
« Fonctionne hors connexion » est trop large pour cadrer un projet. Distinguez consulter un dossier déjà chargé, enregistrer un relevé et valider une opération qui dépend d’un serveur. Une application installée peut elle aussi dépendre du réseau pour une partie de son travail.
Distinguer saisie locale et transmission
Choisissez les données disponibles avant le départ et les actions autorisées pendant la coupure. L’interface doit distinguer enregistré sur l’appareil, en attente d’envoi et accepté par le serveur. La personne ne doit pas confondre une saisie locale avec un dossier partagé à jour.
Tester le retour du réseau
Prévoyez le retour du réseau, les changements concurrents et la fermeture de l’application. La documentation MDN détaille les mécanismes hors ligne des PWA ; la règle métier de reprise reste à définir. Le guide des connexions entre outils traite aussi ces échanges incomplets ou répétés.
La reprise fait partie de la fonction
MDN explique comment une PWA peut conserver des ressources et gérer certaines opérations différées. Leur disponibilité dépend de la plateforme.
- Avant
Préparer les ressources
Identifier ce qui doit rester disponible sans connexion.
- Pendant
Conserver le travail
Distinguer les données locales des données déjà partagées.
- Après
Reprendre les échanges
Vérifier les opérations différées sur les appareils visés.
Tester les fonctions matérielles décisives
Essayer les fonctions sur les appareils cibles
- Prenez la photo, le scan ou la localisation réellement nécessaires au travail.
- Testez-les sur les appareils cibles, avec les permissions refusées puis accordées.
- La disponibilité d’une fonction dans une documentation ne suffit pas à garantir son comportement dans votre contexte.
Valider les contraintes matérielles
Un lecteur spécialisé, une communication avec un appareil ou une exigence de traitement en arrière-plan peut orienter le choix. Demandez un essai court de cette fonction avant de construire tous les écrans. Le test doit reproduire le matériel, les interruptions et la fréquence d’usage.
Préciser la fréquence et la précision
Séparez la précision requise et le confort souhaité. Prendre une photo ponctuelle et effectuer des scans en série n’imposent pas la même ergonomie. Le développement d’applications mobiles se justifie par ces contraintes observées, pas par l’idée qu’une icône serait plus professionnelle.
Rendre les actions courtes et la progression visible
Conserver les saisies interrompues
Sur le terrain, un long formulaire peut être interrompu par un appel ou un déplacement. Regroupez la saisie par tâche, conservez le travail et montrez clairement ce qui manque. Les champs indispensables doivent être distingués de ce qui peut être complété plus tard.
Nommer clairement les états
Un statut doit porter des mots : à envoyer, envoyé, erreur à reprendre. La couleur seule ne suffit pas dans un environnement lumineux ni pour tous les lecteurs. Vérifiez aussi le clavier, les zones tactiles et la lecture avec un grossissement du texte.
Inclure la reprise au bureau
Le retour au bureau fait partie du parcours. La personne qui reprend les relevés doit retrouver les bonnes pièces, voir les éventuelles incertitudes et corriger avec une trace. Une application web métier peut partager ces règles avec une interface dédiée au terrain.
Comparer les coûts sur la durée et essayer en situation
Comparer le même périmètre
Comparez les options sur le même usage : droits, données, hors connexion, matériel et interface de bureau. Ajoutez la distribution, les mises à jour, l’assistance et les tests sur les appareils. Une base de code commune ne supprime pas ces vérifications.
Tester une intervention réelle
- Un pilote doit accompagner une intervention réelle avec un réseau dégradé, une interruption et un retour au bureau.
- Vérifiez les saisies conservées et leur reprise dans le dossier partagé.
- Un parcours réussi sur un réseau parfait ne tranche pas une décision de terrain.
Décider sur des critères écrits
Décidez après cet essai et gardez les critères écrits. Les repères de prix servent à préparer l’enveloppe ; le calcul de rentabilité aide à examiner ce que l’équipe récupère réellement.
Les points qui restent à trancher
Une application web peut-elle être utilisée sur téléphone ?
Oui si l’interface est conçue et testée pour cet écran. Le besoin d’une application installée dépend ensuite du réseau, du matériel et de l’intégration au système.
Une PWA fonctionne-t-elle toujours hors connexion ?
Non. Le contenu disponible et les actions autorisées sans réseau doivent être développés. Les mécanismes utilisés doivent être vérifiés dans les navigateurs et systèmes ciblés.
Une application native résout-elle les conflits de synchronisation ?
Non. Les règles de reprise et de modifications concurrentes sont des décisions de données et de métier, quel que soit le format de l’application.
Quel est le meilleur test avant de choisir ?
Faire accomplir une tâche complète sur les appareils cibles, avec une coupure réseau et une interruption, puis contrôler les données reprises au bureau.
Confronter le guide à un projet réel.
Quelques lignes suffisent : contexte, contrainte principale et résultat attendu.