Créer l’app Transporter : des opérations de terrain hors ligne pour le transport

Lorsque TST Terschelling nous a abordés pour remplacer leur flux de travail de pilote sur papier, le résumé était simple: le rendre plus rapide, le rendre numérique, le rendre fiable. Ce qui a suivi a été l'un des projets les plus exigeants techniquement que nous ayons expédiés.

La contrainte qui a façonné tout

Les îles Wadden ont une couverture mobile par défaut. Les ferries traversent deux fois par jour. Un conducteur chargant des marchandises au quai à 6 heures du matin n'a pas le luxe d'attendre un serveur aller-retour à chaque fois qu'il scanne un code à barres. L'application devait fonctionner entièrement hors ligne pas comme une rétroaction, mais comme le mode d'exploitation principal.

Cette seule contrainte a changé chaque décision architecturale que nous avons prise.

Ce que Transporter fait

Transporter est la colonne vertébrale opérationnelle de la journée du conducteur.

• L'accès au conducteur et l'affectation du parcours
• Chargement du camion avec numérisation des codes à barres et validation de la quantité
• Flux de travail de livraison stop-by-stop avec traitement des exceptions
• La preuve numérique de livraison, y compris la capture de la signature
• Fermeture de la route à la fin de la journée et synchronisation à l'arrière-plan

Chaque action est locale-première. L'appareil stocke l'état, files d'attente des événements, et synchronise opportuniste lorsque la connectivité est disponible. Rien ne bloque un appel réseau dans le chemin critique.

La pile technique

Nous avons construit Transporter comme une application native C# ciblant Zebra Android appareils. Zebra les poignées sont la norme de l'industrie pour le dépistage des entrepôts et de la logistique ils survivent aux chutes, à la poussière, aux fluctuations de température et au changement après le changement d'utilisation continue. Leurs scanners à codes à barres intégrés sont un ordre de magnitude plus rapides que le dépistage par caméra sur les téléphones de consommation.

Le backend est un PHP REST API soutenu par MySQL. La réconciliation d'état se fait par un modèle de synchronisation basé sur des événements: l'appareil accumule un journal des opérations, le serveur les applique dans l'ordre, et les conflits sont résolus de manière déterministe. Le conducteur ne voit jamais un rotateur de chargement au moment critique.

Ce que nous avons appris

La connexion hors ligne semble simple jusqu'à ce que vous ayez à la gérer correctement. Chaque cas de bord qui est trivial dans une application toujours connectée devient un problème de conception: que se passe-t-il si un pilote scanne le même élément deux fois sur différents appareils? Que se passe-t-il si les données de route ont changé sur le serveur depuis la dernière synchronisation de l'application? Que se passe-t-il si l'horloge de l'appareil est incorrecte?

Nous avons passé beaucoup de temps sur le protocole de synchronisation et sur le modèle de rétroaction de l'interface utilisateur pour nous assurer que le conducteur connaisse toujours l'état d'autorité de son itinéraire, même lorsque cet état a été mis à jour pour la dernière fois il y a trois heures lors d'un trajet de ferry.

Le résultat est une application qui fonctionne quotidiennement depuis son lancement sans aucun problème d'intégrité des données.

Le résultat

TST Terschelling a remplacé un processus de presse-papiers qui était en place depuis des années. Le temps de chargement par camion a considérablement diminué. Les litiges sur la preuve de livraison ont disparu car chaque livraison a maintenant un enregistrement numérique signé.

C'est le genre de projet qui nous rappelle pourquoi le logiciel existe: éliminer les frictions du travail qui comptent vraiment.