PalletFlow

La même mission signifie trois choses différentes selon qui la regarde. Pour l'exploitant, c'est une ligne dans une file avec un coût et un affecté. Pour le chauffeur, c'est une tâche à la fois, à bout de bras, peut-être sans réseau. Pour le partenaire, c'est un statut et une date.

Une interface unique pour les trois aurait échoué pour les trois. Trois applications déconnectées auraient signifié trois sources de vérité.

Un backend NestJS, un modèle de domaine, trois clients sur une bibliothèque de composants partagée. La couche partagée est volontairement petite — tokens, primitives, client API, flux d'authentification. Tout ce qui est au-dessus est écrit par public.

L'application chauffeur a hérité des contraintes les plus strictes : grandes cibles tactiles, scanner QR comme interaction principale, et une interface qui part du principe que la connexion va tomber. Les scans sont mis en file localement puis réconciliés au retour du réseau : un chauffeur dans un entrepôt ne doit pas être bloqué par une barre de signal.

• Tableau de bord admin — stock, affectation des missions, suivi des incidents, gestion des partenaires
• Application transporteur — liste des missions, parcours tâche par tâche, scan QR, preuve de livraison
• Application partenaire — visibilité en lecture seule, limitée aux marchandises du partenaire
• Primitives Radix UI partout : comportement clavier et lecteur d'écran corrects par défaut

Des modules NestJS découpés par domaine derrière une couche de garde basée sur les rôles : un jeton partenaire ne peut résoudre que ses propres missions — appliqué au niveau de la requête, pas par filtrage de la réponse.

L'état d'une mission suit une machine à états explicite, et chaque transition est enregistrée avec son acteur et son horodatage. C'est ce qui a transformé le suivi des incidents en simple lecture sur des données existantes plutôt qu'en fonctionnalité séparée.