Logistique urbaine

Plateforme de livraison en temps réel

Trois populations aux besoins opposés, un seul jeu de données, et l'obligation que tout le monde voie la même chose au même moment.

Console de dispatch : carte avec trajet en direct, étapes de la livraison et fiche du livreur.
Illustration d'interface, reconstituée pour la présentation. Ce n'est pas une capture du livrable final.

Contexte

Une activité de livraison à la demande fait intervenir trois populations dont les besoins n'ont presque rien en commun. Le coursier travaille en mouvement, souvent d'une seule main, sur un réseau mobile instable. Le client veut savoir où en est sa commande sans avoir à téléphoner. Le restaurateur doit accepter, préparer et suivre ses commandes sans quitter son poste de travail. Faire cohabiter ces trois usages sur un même jeu de données est le cœur du sujet, bien avant les questions d'interface.

Le problème

Sans plateforme unifiée, la coordination repose sur des appels et des messages. Chacun se construit sa propre version de l'état d'une commande, et ces versions divergent.

  • Le client rappelle parce qu'il n'a aucune visibilité sur l'avancement
  • Le restaurateur relance le coursier, qui est en train de conduire
  • Une commande annulée continue d'être préparée
  • Aucune trace exploitable une fois la journée terminée

La solution

Un socle applicatif unique, et trois interfaces taillées chacune pour son usage. Un seul modèle de commande fait autorité, et chaque changement d'état est diffusé aux clients connectés.

  • Application coursier : liste des missions, itinéraire, changement de statut en un geste, preuve de livraison
  • Application client : commande, paiement, suivi de la position et heure d'arrivée estimée
  • Back-office restaurateur : catalogue, stocks, acceptation et suivi des commandes
  • Diffusion des changements d'état par WebSocket, plutôt qu'un rafraîchissement périodique
  • Un modèle de commande unique, avec des transitions d'état explicites

Mon rôle

J'ai porté l'ensemble de la chaîne : le modèle de données et les transitions d'état, l'API, les trois interfaces, la base et le déploiement. Le point le plus structurant a été de définir les états d'une commande et les transitions autorisées entre eux, car c'est de là que découlent les trois interfaces.

Contraintes

  • Réseau mobile instable : l'application coursier doit tolérer les coupures et reprendre sans perdre d'action
  • Suivi de position suffisamment fréquent pour être utile, sans vider la batterie du téléphone
  • Cohérence des statuts entre trois clients connectés simultanément
  • Paiement en ligne, avec les exigences de sécurité correspondantes
  • Montées de charge concentrées sur les créneaux de repas

Résultat

La plateforme remplace la coordination téléphonique par un état partagé. Les trois acteurs lisent la même information au même moment, et l'historique des commandes devient exploitable.

  • Le suivi côté client supprime le motif principal d'appel entrant
  • Le restaurateur gère seul son catalogue et ses stocks, sans intervention technique
  • Chaque commande laisse une trace complète, du panier à la preuve de livraison

Les résultats sont décrits par la capacité livrée. Aucune mesure de performance commerciale n'est avancée ici : les chiffres d'usage appartiennent au client, et je ne publie pas de métriques que je ne peux pas justifier.

Un projet de cette nature ?

Décrivez votre besoin en quelques lignes. Je vous réponds sur ce qui est faisable, ce qui ne l'est pas, et par où commencer.

Me contacter