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 considérer l’absence de réseau comme l’état normal, pas comme une panne. Cela signifie enregistrer l’action localement, la montrer immédiatement à l’utilisateur, l’envoyer plus tard dans une file visible, et 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’utilisateur doit toujours voir ce qui est envoyé, ce qui attend et ce qui a échoué.
- Les conflits se règlent par des règles métier écrites, pas par le hasard du dernier enregistrement.
- Testez sur les appareils et les réseaux réellement utilisés, pas au bureau en wifi.
Le terrain n’est pas le bureau
Un dépôt en sous-sol, une zone industrielle, une route entre deux villes, un ascenseur, un bâtiment aux murs épais : le réseau y disparaît régulièrement et revient sans prévenir. Une application qui affiche un message d’erreur dans ces moments-là est abandonnée en quelques jours, remplacée par une feuille de papier — et l’information n’arrive jamais dans le système.
La bonne question n’est donc pas « que faire quand la connexion tombe » mais « quel travail doit rester possible sans aucune connexion ». La réponse définit le périmètre technique de l’application bien plus sûrement qu’une liste de fonctions.
- 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
Le principe est simple : toute action de l’utilisateur est écrite dans une base locale sur l’appareil et considérée 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. Cet identifiant permet de renvoyer la même action plusieurs fois sans créer de doublon si la confirmation s’est perdue en chemin — la situation la plus fréquente et la plus insidieuse en mobilité.
| 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 clair, 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 |
Les conflits se décident avec le métier, pas avec la technique
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. Ces situations ne sont pas des bugs : ce sont des questions métier auxquelles il faut répondre avant d’écrire le code.
Pour chaque type de donnée, décidez explicitement : 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. Une donnée écrasée silencieusement détruit la confiance dans le système entier.
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, mais il doit pouvoir répondre à trois questions d’un coup d’œil : est-ce que mon travail est enregistré, est-ce qu’il est parti, est-ce que quelque chose a échoué. Un simple compteur d’éléments en attente et un état par ligne suffisent généralement.
Le reste de l’interface doit être conçu 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
Une application de terrain validée au bureau n’est pas validée. 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. Le choix se fait sur les usages réels et sur le parc d’appareils, pas par principe.
Combien de temps une application peut-elle rester hors ligne ?
Cela dépend du volume produit et de la place disponible sur l’appareil. Une journée complète est un objectif courant et raisonnable. Au-delà, il faut prévoir explicitement la purge des données anciennes et prévenir l’utilisateur avant saturation.
Comment éviter les doublons de saisie après une coupure ?
En attribuant à chaque action un identifiant généré sur l’appareil et en rendant le traitement serveur insensible aux répétitions. Le même envoi rejoué deux fois produit alors un seul enregistrement, ce qui rend les reprises automatiques sûres.