Application terrain hors ligne : comment la concevoir ?

Le vrai coût du hors ligne

Une application qui lit et écrit en direct sur un serveur est simple : une seule source de vérité, aucune ambiguïté. Le hors ligne casse ce modèle. Il faut une base locale, une file d'attente, une stratégie de résolution des conflits et une interface qui dit à l'utilisateur ce qui est parti et ce qui attend. C'est un surcoût réel. Il se justifie quand l'alternative est un technicien qui note sur papier puis ressaisit le soir, ce qui coûte du temps, produit des erreurs et fait perdre les photos. Pour voir à quoi ressemble une application complète pour techniciens, voir notre page application terrain sur mesure.

Décision 1 — que doit-on emporter ?

Tout emporter n'est pas viable : un parc de plusieurs centaines de machines avec son historique complet ne tient pas raisonnablement sur un téléphone, et la synchronisation initiale devient interminable. La bonne granularité est presque toujours la journée du technicien : ses interventions affectées, les fiches des équipements concernés, les checklists applicables, et l'historique récent de ces équipements seulement.

Décision 2 — qui gagne en cas de conflit ?

Deux techniciens modifient la même fiche hors ligne. Au retour du réseau, il faut trancher. Trois stratégies sont possibles : le dernier qui synchronise gagne, le premier gagne, ou les deux versions sont conservées avec arbitrage au bureau. Le choix dépend de la donnée. Pour un compteur d'heures, la valeur la plus élevée est probablement la bonne. Pour un rapport d'intervention, il ne faut jamais écraser silencieusement : on conserve les deux et on demande. La seule réponse inacceptable est de perdre une saisie sans le dire.

Décision 3 — que fait-on des photos ?

Les photos représentent l'essentiel du volume. Une intervention en compte trois à sept, et une photo de téléphone récent pèse plusieurs mégaoctets. Envoyées telles quelles sur un réseau faible, elles bloquent la synchronisation. Il faut donc redimensionner et compresser sur l'appareil avant l'envoi, envoyer les photos séparément des données pour que le rapport arrive même si une photo échoue, et permettre de reprendre un envoi interrompu.

Décision 4 — comment sait-on que c'est parti ?

Un technicien qui ne sait pas si son rapport est envoyé fera une capture d'écran « au cas où ». C'est le signe d'une interface qui n'assume pas son état. L'application doit afficher en permanence combien d'éléments attendent, tenter la synchronisation dès que le réseau revient, et ne jamais supprimer une donnée locale avant confirmation du serveur.

Ce guide décrit une pratique, pas un avis juridique. Les obligations applicables dépendent de votre matériel, de son usage et de votre secteur : vérifiez-les auprès de votre organisme de contrôle ou de votre conseil.