Chez NOVIPRO, je découvre des appareils Windows durcis et des usages pas mal moins confortables que le poste de bureau. Dehors, un écran pourtant clair devient difficile à lire. Un bouton facile à viser à la souris est minuscule avec des gants. Surtout, le réseau peut disparaître au milieu d’une opération. Ça oblige à concevoir le trajet complet, pas seulement l’écran.

Prenons une inspection. Le technicien ouvre une fiche, saisit cinq mesures, prend une photo et appuie sur Terminer. Sur le bureau, l’application pourrait envoyer chaque champ directement au serveur. Sur le terrain, cette dépendance transforme une coupure radio en perte de travail.

Le téléphone doit posséder un état local

Je donnerais à chaque inspection un identifiant généré sur l’appareil et un état explicite :

brouillon → prête à envoyer → en cours → confirmée

Les champs sont d’abord écrits dans une base locale, par exemple SQL Server Compact sur un terminal Windows. La photo est enregistrée dans un fichier référencé par l’inspection. Une file locale contient les opérations à synchroniser. L’interface peut donc confirmer « enregistré sur l’appareil » même sans connexion, puis afficher séparément « pas encore reçu par le serveur ».

Quand le réseau revient, le client envoie l’identifiant, la version connue et le contenu. Le serveur ouvre une transaction, valide les types et les règles, écrit les données, puis retourne un reçu avec la nouvelle version. Le client ne retire l’élément de sa file qu’après ce reçu. Si la réponse se perd après l’écriture, il renvoie la même opération; le serveur reconnaît l’identifiant et retourne le résultat existant au lieu de créer un doublon.

Le conflit arrive lorsqu’une autre personne modifie la même fiche. Écraser silencieusement est rarement acceptable. La version envoyée permet une comparaison optimiste : si le serveur est rendu à la version 6 et que l’appareil a modifié la version 4, il retourne un conflit. Certains champs peuvent être fusionnés; une décision humaine est nécessaire pour deux valeurs incompatibles.

Radio, batterie et sécurité changent l’architecture

Une connexion intermittente demande des délais courts et des reprises avec attente croissante. Réessayer toutes les secondes vide la batterie et surcharge un service déjà fragile. Les gros fichiers peuvent être découpés en blocs avec somme de contrôle afin de reprendre l’envoi au dernier bloc confirmé. Le protocole doit distinguer une panne temporaire, une authentification expirée et une donnée rejetée définitivement.

Le GPS, la caméra, l’écran lumineux et la radio consomment beaucoup. Je déclencherais la localisation à la demande plutôt que continuellement, compresserais raisonnablement les photos et regrouperais les synchronisations. L’application doit aussi survivre à une batterie arrachée entre deux écritures : une transaction locale évite une fiche à moitié enregistrée.

Comme l’appareil voyage, les données locales doivent être chiffrées, l’accès verrouillé et les secrets évités dans le code. Un certificat ou un jeton court permet d’authentifier l’appareil; une console de gestion peut révoquer celui qui est perdu. L’effacement à distance aide, sans remplacer le chiffrement puisqu’un appareil hors réseau ne reçoitra peut-être jamais la commande.

L’iPad et les téléphones intelligents font parler de stratégie mobile, mais je partirais encore de la tâche : quelles données faut-il vraiment dehors, combien de temps peut-on être déconnecté et quelle preuve confirme la synchronisation? Une bonne application mobile montre honnêtement les trois réalités — local, en attente, serveur — au lieu de faire croire que le réseau est toujours là.