03 — Applications mobiles
Un parcours pensé pour le moment où il sert.
Sur le terrain ou entre deux rendez-vous, une application doit rendre la prochaine action compréhensible. La conception part du contexte réel : une main disponible, une connexion incertaine ou une saisie interrompue.
Rendre chaque état compréhensible
Un exemple de transmission lorsqu’une connexion peut être interrompue.
Saisie en cours
La personne complète l’information et peut vérifier ce qu’elle s’apprête à transmettre.
En attente de connexion
L’interface indique que la transmission reste à effectuer et propose une reprise.
Réception confirmée
La confirmation apparaît lorsque le système a établi la réception.
Si la transmission échoue, le parcours doit permettre de comprendre l’erreur et de reprendre sans confondre attente et réception.
Définir le parcours prioritaire
Consulter un dossier, compléter une information ou transmettre un élément sont des usages différents. Le prototype doit rendre visibles le début de la tâche, son état d’avancement, les erreurs possibles et la confirmation de son résultat.
L’accès à la caméra, les notifications et le fonctionnement hors connexion se prévoient lorsqu’ils répondent à un besoin identifié. Les permissions demandées doivent être compréhensibles pour la personne qui utilise l’application.
Prévoir les interruptions et la continuité
Un écran « envoyé » doit correspondre à un résultat établi. Si une opération attend une connexion ou doit être reprise, cet état doit rester distinct et offrir une action utile. Les conflits de synchronisation doivent avoir un traitement défini.
Le choix entre une application native et une base multiplateforme dépend des appareils, des interactions et des intégrations nécessaires. La publication et les évolutions doivent aussi tenir compte des comptes, des droits et des procédures des plateformes concernées.
Un périmètre à définir ensemble
- Parcours prioritaires et prototype à examiner sur appareil
- Application pour les plateformes convenues
- Intégrations, permissions et états de reprise définis au périmètre
- Essais sur les appareils et situations retenus
- Préparation de la remise et des étapes de publication
Les usages concernés
- Services qui accompagnent un travail sur le terrain
- Organisations qui proposent un accès mobile à leurs clients
- Équipes qui veulent prolonger un parcours web par un usage mobile précis
Choix techniques possibles
- SwiftUI
- React Native
- TypeScript
- API du système concerné
Questions fréquentes
- Faut-il une application distincte pour iOS et Android ?
- La décision dépend des appareils visés, des interactions et des fonctions nécessaires. Le cadrage permet de comparer une réalisation native et une base multiplateforme, avec leurs contraintes de maintenance et de publication.
- L’application peut-elle fonctionner sans connexion ?
- Certains parcours peuvent être conçus pour cela. Il faut préciser les informations accessibles, leur protection sur l’appareil, les actions mises en attente et la manière de traiter une synchronisation ou un conflit.
- Comment se prépare la publication ?
- Le projet doit identifier les comptes éditeurs, les droits nécessaires, les contenus à fournir et les étapes de soumission. L’acceptation par une plateforme ne peut pas être garantie par la seule réalisation de l’application.
Qu’aimeriez-vous rendre plus simple ?
Un parcours client, un outil interne, une tâche documentaire : décrivez le contexte et le changement recherché. Ce premier échange permet de préciser le travail à engager.
Parler d’un projet