Applications métier
Application mobile de terrain : concevoir pour le hors-ligne
Livreurs, magasiniers, techniciens : comment concevoir une application qui reste utilisable quand le réseau disparaît, et comment gérer la synchronisation et les conflits.
Une application de terrain doit permettre tout le travail courant sans réseau. L'application enregistre l'action sur l'appareil, la montre tout de suite à l'utilisateur et l'envoie plus tard par une file visible. Il faut aussi définir à l'avance qui gagne quand deux versions d'une même donnée se rencontrent.
En bref
- Concevez d'abord le mode hors ligne. Le mode connecté n'en est qu'un cas particulier.
- L'écran montre à tout moment les saisies envoyées, celles en attente et celles en échec.
- Écrivez une règle métier pour chaque type de conflit. Sans elle, le dernier enregistrement gagne par hasard.
- Testez avec les appareils et les réseaux de vos équipes, loin du wifi du bureau.
Ce qui doit marcher sans réseau
Dans un dépôt en sous-sol, une zone industrielle, sur une route entre deux villes, dans un ascenseur ou un bâtiment aux murs épais, le réseau disparaît régulièrement et revient sans prévenir. Si l'application affiche un message d'erreur dans ces moments-là, les équipes l'abandonnent en quelques jours pour une feuille de papier, et l'information n'arrive jamais dans le système.
La question à poser est donc « quel travail doit rester possible sans aucune connexion ? ». Pour un livreur, la liste ressemble à ceci.
- Consulter la tournée du jour, la fiche client et l'historique récent.
- Enregistrer une livraison, un retour, un relevé ou une photo.
- Scanner un code et retrouver l'article correspondant.
- Signer une réception et générer le document de preuve.
- Voir clairement ce qui n'est pas encore parti vers le serveur.
Écrire d'abord en local, envoyer ensuite
L'application écrit chaque action de l'utilisateur dans une base locale sur l'appareil et la considère comme acquise. Une file d'envoi tente ensuite de la transmettre au serveur, avec des reprises automatiques. L'interface ne bloque jamais en attendant le réseau.
Chaque action porte un identifiant créé sur l'appareil. Grâce à cet identifiant, l'application peut renvoyer la même action plusieurs fois sans créer de doublon. Elle en a besoin quand la confirmation se perd en chemin, le cas le plus fréquent en mobilité et le plus difficile à repérer.
| Situation | Comportement attendu |
|---|---|
| Réseau absent au moment de la saisie | Action enregistrée localement et visible immédiatement |
| Réseau revenu | Envoi automatique de la file, dans l'ordre, sans action de l'utilisateur |
| Envoi interrompu à mi-chemin | Nouvel essai sans créer de doublon grâce à l'identifiant d'origine |
| Le serveur refuse une action | Message qui donne le motif du refus, action conservée, possibilité de corriger |
| Téléphone éteint ou application fermée | File conservée et reprise au démarrage suivant |
| Deux appareils modifient la même donnée | Règle de résolution définie à l'avance, trace des deux versions |
Un conflit de données est une décision métier
Deux magasiniers comptent le même emplacement hors ligne et renvoient des quantités différentes. Un livreur marque une commande livrée pendant qu'un commercial l'annule au bureau. Ce sont des questions métier, et il faut y répondre avant d'écrire le code.
Pour chaque type de donnée, décidez : le dernier arrivé l'emporte, le serveur l'emporte, l'appareil du terrain l'emporte, ou un humain tranche. Dans tous les cas, conservez les deux versions et le motif de la décision. Si le système écrase une quantité sans garder de trace, plus personne ne peut dire lequel des deux magasiniers avait compté juste.
Une interface qui dit la vérité sur l'état des données
L'utilisateur de terrain n'a pas besoin de comprendre la synchronisation. Il doit pourtant voir d'un coup d'œil si l'appareil a gardé sa saisie, si le serveur l'a reçue et si un envoi a échoué. Un compteur d'éléments en attente et un état par ligne suffisent en général.
Concevez le reste de l'interface pour des conditions difficiles : gros boutons utilisables avec des gants, contraste lisible en plein soleil, saisie minimale, scan plutôt que frappe, et une action principale évidente par écran.
Tester dans les vraies conditions
Pour une application de terrain, valider au bureau ne suffit pas. Les tests doivent inclure la coupure en pleine saisie, le passage prolongé hors réseau, la batterie faible, le redémarrage forcé, le changement d'utilisateur sur un appareil partagé et le retour massif de données après plusieurs heures déconnectées.
Emmenez aussi l'équipe technique sur le terrain pendant une journée complète. Ce qui paraît anodin sur une maquette, trois taps pour valider une ligne, devient insupportable quand il faut le répéter deux cents fois sous la pluie.
Questions fréquentes
Les réponses courtes
Faut-il une application native ou une application web pour le terrain ?
Les deux peuvent fonctionner hors ligne. Le natif reste avantageux pour le scan intensif, l'accès matériel et l'autonomie ; le web installable simplifie le déploiement et les mises à jour. Tranchez d'après les usages et le parc d'appareils de vos équipes.
Combien de temps une application peut-elle rester hors ligne ?
Le volume produit et la place disponible sur l'appareil fixent la limite. Une journée complète est un objectif courant. Au-delà, il faut prévoir la purge des données anciennes et prévenir l'utilisateur avant saturation.
Comment éviter les doublons de saisie après une coupure ?
Chaque action reçoit un identifiant généré sur l'appareil, et le serveur ignore un envoi qu'il a déjà traité. Le même envoi rejoué deux fois produit alors un seul enregistrement, ce qui rend les reprises automatiques sûres.