« Il nous faut une appli » peut vouloir dire plusieurs choses : un logiciel qu’on ouvre depuis un lien, quelque chose qu’on installe sur son téléphone, ou les deux. Avant de décider, je veux comprendre la tâche et l’endroit où les gens l’effectuent. C’est une meilleure base pour choisir comment livrer le produit.
Une cliente qui réserve de temps en temps depuis un résultat de recherche n’a pas les mêmes besoins qu’un technicien de terrain qui saisit des informations toute la journée. Partez de ces situations pour décider ce qui compte, puis testez les capacités dont le produit dépend.
Partez de la tâche et du chemin pour y arriver
Décrivez comment quelqu’un découvre le produit, à quelle fréquence il revient et quel appareil il utilise. Un chargé de clientèle qui parcourt un long rapport préférera peut-être un ordinateur portable. Un technicien qui prend des photos sur un chantier a besoin d’un parcours pensé pour le téléphone. Une même entreprise peut avoir les deux publics.
Comment les gens trouveront-ils et ouvriront-ils le produit : un résultat de recherche, une invitation, un QR code ou une boutique d’applications ?
La tâche est-elle occasionnelle, quotidienne ou intégrée à une longue session de travail ?
Qu’est-ce qui doit fonctionner quand la connexion est faible ou absente ?
Quelles fonctions de l’appareil sont indispensables pour accomplir la tâche ?
Quand une application web est un bon point de départ
Une application web tourne dans le navigateur et se partage avec un lien. Elle convient aux espaces clients, aux systèmes de réservation, aux tableaux de bord et à bien d’autres usages. Le responsive design adapte l’interface aux différentes tailles d’écran, mais il faut quand même tester les vraies tâches sur ces écrans.
Par exemple, un portail fournisseurs pourrait permettre aux clients de commander depuis leur téléphone pendant que l’équipe traite les commandes sur ordinateur. Une même application web pourrait servir les deux groupes, avec des vues et des droits différents. Une fiche dans une boutique d’applications devrait apporter un bénéfice précis pour justifier sa place dans la première version.
Ce qu’une application web installable peut offrir
Une progressive web app, ou PWA, utilise les technologies du web et peut offrir une expérience d’application installée sur les appareils compatibles. Le fonctionnement hors ligne, les notifications et les autres capacités demandent une mise en œuvre réfléchie et des tests de compatibilité. Une icône sur l’écran d’accueil ne fait rien fonctionner hors ligne.
Pour en savoir plus sur cette approche, consultez l’introduction de MDN aux progressive web apps. Pour votre projet, je testerais les capacités nécessaires sur les appareils et navigateurs de vos clients, puis je définirais une solution de repli pour tout ce qui n’est pas disponible.
Quand une application mobile mérite son propre périmètre
Une application mobile peut se justifier quand le parcours dépend d’une intégration plus poussée avec l’appareil, d’une expérience installée ou d’un canal de distribution particulier. Notez ces besoins précisément. « Utilise l’appareil photo » est trop vague ; ce qu’il faut évaluer, c’est le processus de capture, les autorisations et les appareils pris en charge.
Un outil d’inspection pourrait devoir garder un brouillon de rapport sur l’appareil pendant une visite de site et envoyer les photos plus tard. La décision doit couvrir la façon dont les brouillons survivent aux interruptions, le fonctionnement de la synchronisation et ce qui se passe quand deux personnes modifient le même enregistrement. Ce sont des décisions produit, et une application installée a elle aussi besoin qu’on les prenne.
La publication sur les stores demande aussi de la préparation : comptes, fiches, exigences de validation et un processus pour maintenir les versions publiées. Nous devrions en tenir compte en comparant les options. La validation et les délais restent soumis à l’examen de chaque store.
Un code partagé doit quand même être testé sur chaque plateforme
Certaines approches partagent du code entre plateformes ou prolongent un produit web existant. Cela peut permettre de réutiliser du travail, mais dans une mesure qui dépend de l’application et de ses exigences. J’examinerais le code existant avant de promettre qu’une application web peut simplement devenir une application mobile.
Le serveur et la base de données peuvent servir à la fois l’interface web et l’interface mobile. Chaque interface a quand même besoin d’une navigation, d’une gestion des saisies, de droits et de tests adaptés. L’objectif est un produit cohérent sur les appareils que les gens utilisent vraiment.
Choisissez la prochaine version sur des éléments concrets
Vous pouvez commencer par un canal et en ajouter un autre quand il y a une raison claire. Si l’incertitude porte sur une capacité de l’appareil, testez-la tôt. Si elle porte sur le besoin même des clients, testez le parcours avec des utilisateurs représentatifs avant d’élargir sa diffusion.
Nos principaux utilisateurs et leurs appareils sont : …
Leur tâche la plus importante est : …
Ils arrivent sur le produit par : …
Les capacités que nous devons vérifier sont : …
Nous ajouterions une autre plateforme quand : …
Envoyez ce contexte avec votrebrief de projet. Je peux vous aider à comparer les options au regard du travail à accomplir et à planifier une première version utile.