Une application de terrain qui exige du réseau est une application qui ne sera pas utilisée là où elle sert. Cave, chantier, montagne, atelier, sous sol, aérodrome : le réseau y est absent ou intermittent, et c'est précisément là que la saisie a de la valeur.
Le hors connexion n'est pas une option qu'on ajoute
C'est une décision d'architecture qui se prend au début. Ajouter le hors connexion à une application qui n'a pas été conçue pour revient à la reconstruire.
La raison est simple : une application connectée demande au serveur ce qu'elle doit afficher. Une application hors connexion doit savoir répondre elle même, donc posséder les données, donc gérer leur fraîcheur, leurs conflits et leur taille.
Le surcoût à la conception est réel, de l'ordre de 20 à 40 % selon la complexité. Nous l'annonçons, parce que la découverte en cours de route de cette exigence est l'une des causes les plus fréquentes de dépassement de budget.
Les trois conflits à trancher avant de coder
Ils n'ont pas de bonne réponse universelle : la réponse dépend du métier, et elle doit être décidée par le client, pas par nous.
Deux personnes modifient la même fiche hors connexion
Qui gagne ? Le plus récent, le premier revenu sur le réseau, ou personne, avec une alerte ? Pour un relevé de terrain, garder les deux est souvent le bon choix, parce que deux observations ne sont pas une contradiction.
La donnée locale a vieilli
L'appareil affiche un tarif ou une consigne datant de trois semaines. La règle que nous appliquons : afficher la donnée avec sa date, toujours, plutôt que de la masquer ou de bloquer l'application.
La synchronisation échoue en partie
Douze fiches partent, trois échouent. Il faut que l'utilisateur le sache, sache lesquelles, et puisse réessayer. Une synchronisation silencieusement partielle est le pire des cas.
Ce qu'il faut embarquer, et ce qu'il ne faut pas
Tout embarquer est impossible et inutile. La règle : embarquer ce dont on a besoin pour la journée de travail prévue, et rien de plus.
Concrètement, cela veut dire connaître à l'avance le périmètre de la sortie : quelles parcelles, quels appareils, quels clients. Une application de terrain bien conçue prépare sa journée quand elle a du réseau, le matin, et fonctionne seule ensuite.
Ce qui ne s'embarque pas : les référentiels volumineux, les historiques complets, les images en pleine résolution. Ils restent au serveur et l'application le dit clairement plutôt que d'afficher une page vide.
L'erreur classique consiste à tester le hors connexion en coupant le réseau. Le vrai cas, plus dur, est le réseau très mauvais : une barre qui apparaît et disparaît. C'est celui qui casse les synchronisations, et c'est celui qu'il faut simuler.
Ce que cela permet, au delà de la saisie
Une application qui possède ses données peut faire des choses qu'une application connectée ne fait pas : afficher instantanément, fonctionner dans l'ascenseur, survivre à une panne du serveur.
Et elle change la relation à la donnée sur le terrain. Quand la consultation est immédiate, elle est faite. Quand elle demande d'attendre huit secondes, elle est remplacée par une supposition, et c'est ainsi qu'on prend une décision fausse avec un outil qui contenait la bonne information.
Coût et délai
Le hors connexion sur une application métier de terrain, avec préparation de journée, synchronisation et gestion des conflits : de 4 000 à 14 000 francs supplémentaires selon la complexité des données.
Décidé au départ, c'est un surcoût maîtrisé. Ajouté après coup, c'est souvent une reconstruction. C'est la raison pour laquelle nous posons la question dès le premier entretien, même quand personne ne l'a évoquée.
Du travail sans réseau ?
Audit gratuit sous 48 heures, et la question posée dès le premier entretien
Demander un audit gratuit