Choisir un parcours réalisable sans connexion
Pour une première version, envisagez l’ouverture d’une mission attribuée, la lecture de sa liste de contrôle et la rédaction d’une note d’intervention. Le guide d’architecture Android recommande des données locales pour les lectures hors ligne essentielles. Traduisez ce principe en critère de validation : le technicien prépare sa mission avant de partir, puis peut rouvrir les consignes sans connexion.
Listez aussi les actions exclues de cette première version. Attribuer une nouvelle mission ou confirmer un changement de rendez-vous peut nécessiter l’accord du bureau. Expliquez cette limite sur l’écran concerné et proposez une prochaine étape utile plutôt qu’un bouton désactivé sans explication.
Donner un sens précis à chaque état de sauvegarde
Rédigez les messages d’état avant de dessiner les écrans. Distinguez enregistré sur cet appareil, en attente d’envoi, reçu par le bureau et intervention nécessaire. Convenez de la preuve requise pour afficher chaque message. Une coche rassurante ne doit pas laisser un salarié se demander si son collègue peut déjà lire la note.
Dans la liste des missions, distinguez un planning vide d’un planning qui n’a jamais été téléchargé. Dans l’éditeur, affichez l’état en attente à côté de la note correspondante. Pour une équipe européenne multilingue, traduisez ces messages opérationnels avec autant de soin que la navigation.
Définir qui peut modifier chaque partie de la mission
Supposons que le responsable du planning déplace un rendez-vous pendant que le technicien documente sa visite. Qui est responsable de chaque information ? Faut-il conserver les deux modifications, et qui examine un désaccord ? Décidez explicitement du traitement de cette situation plutôt que de promettre une fusion automatique de toutes les modifications.
Firestore synchronise les changements locaux à la reconnexion ; pour plusieurs modifications du même document, la dernière écriture l’emporte. Dans cet exemple, demandez à l’équipe de développement de démontrer qu’un changement de rendez-vous ne peut pas effacer discrètement une note d’intervention. La règle métier doit guider le modèle de données.
Prévoir la transmission et le travail inachevé
Définissez ce qui se passe lorsqu’un téléphone contenant une note non envoyée est confié à un autre salarié. Le compte suivant ne doit pas récupérer les coordonnées clients ou les envois en attente de la personne précédente. Convenez d’un moyen pour l’auteur initial de retrouver son travail et expliquez clairement le choix avant la déconnexion du compte.
Présentez les photos et le texte comme des éléments distincts de la transmission. Si la note arrive au bureau mais pas sa photo, l’interface doit montrer ce résultat partiel. Désignez un rôle responsable des éléments qui continuent à demander une intervention.
Répéter la mission avant le lancement
Jouez le même scénario court avec un technicien et un responsable du planning sur des appareils représentatifs. Notez le résultat visible attendu pour chaque étape. Commencez par cette liste de contrôle, puis ajoutez les incidents importants pour votre propre processus de service :
- Ouvrez une mission préparée hors ligne, puis essayez une mission jamais téléchargée.
- Enregistrez une note, fermez l’application et vérifiez que la note peut être récupérée.
- Rétablissez la connexion deux fois et vérifiez que le bureau reçoit une seule note, sans doublon.
- Modifiez le rendez-vous sur un autre appareil et examinez les deux versions de la mission.
- Changez de compte avec du travail inachevé et vérifiez l’appartenance et la visibilité des données.