Lorsque TST Terschelling nous a demandé de remplacer les procédures papier de ses chauffeurs, le cahier des charges était simple : gagner en rapidité, passer au numérique et assurer la fiabilité. Le projet qui a suivi est l’un des plus exigeants sur le plan technique que nous ayons livrés.
La contrainte qui a déterminé tous nos choix
La couverture mobile des îles de la mer des Wadden est irrégulière. Les ferries effectuent deux traversées par jour. Un chauffeur qui charge des marchandises sur le quai à 6 heures du matin ne peut pas attendre un aller-retour avec le serveur à chaque lecture de code-barres. L’application devait fonctionner entièrement hors ligne, comme mode de fonctionnement principal et pas uniquement comme solution de secours.
Cette seule contrainte a influencé toutes nos décisions d’architecture.
Ce que fait Transporter
Transporter accompagne le chauffeur tout au long de sa journée. L’application prend en charge :
- La connexion du chauffeur et l’affectation de sa tournée
- Le chargement du camion avec lecture de codes-barres et validation des quantités
- Les livraisons étape par étape, avec gestion des cas particuliers
- La preuve de livraison numérique, y compris la capture de signature
- La clôture de la tournée en fin de journée et la synchronisation avec le backend
Chaque action est d’abord traitée localement. L’appareil conserve l’état des opérations, met les événements en file d’attente et les synchronise dès qu’une connexion est disponible. Aucune opération essentielle n’est bloquée par un appel réseau.
Les technologies utilisées
Nous avons développé Transporter sous la forme d’une application native en C# pour les terminaux Android Zebra. Ces terminaux portables sont une référence pour la lecture de codes-barres en entrepôt et en logistique : ils résistent aux chutes, à la poussière, aux variations de température et à une utilisation continue, équipe après équipe. Leurs lecteurs de codes-barres intégrés sont environ dix fois plus rapides que la lecture par caméra sur les téléphones grand public.
Le backend repose sur une API REST en PHP et une base de données MySQL. La mise en cohérence des états s’effectue grâce à un modèle de synchronisation fondé sur un journal d’événements : l’appareil enregistre les opérations, le serveur les applique dans l’ordre et les conflits sont résolus selon des règles déterministes. Le chauffeur ne voit jamais d’indicateur de chargement au moment où il doit agir.
Ce que nous avons appris
Concevoir d’abord pour le mode hors ligne paraît simple, jusqu’à ce qu’il faille le faire correctement. Chaque cas particulier facile à gérer dans une application toujours connectée devient un problème de conception : que se passe-t-il si un chauffeur scanne deux fois le même article sur des appareils différents ? Si les données de la tournée ont changé sur le serveur depuis la dernière synchronisation ? Si l’horloge de l’appareil est incorrecte ?
Nous avons consacré beaucoup de temps au protocole de synchronisation et aux informations affichées dans l’interface, pour que le chauffeur sache toujours quel état de sa tournée fait référence, même si sa dernière mise à jour remonte à trois heures, pendant une traversée en ferry.
Depuis son lancement, l’application accompagne les tournées quotidiennes sans le moindre problème d’intégrité des données.
Le résultat
TST Terschelling a remplacé une procédure fondée depuis des années sur le papier et les porte-documents. Le temps de chargement par camion a nettement diminué. Les litiges relatifs à la preuve de livraison ont disparu, car chaque livraison dispose désormais d’un enregistrement numérique horodaté et signé. L’équipe d’exploitation suit aussi l’avancement des tournées en direct depuis le bureau, sans attendre les appels des chauffeurs.
Ce type de projet nous rappelle la raison d’être du logiciel : simplifier les tâches qui comptent réellement.
