Créer un planificateur de tournées de livraison avec React et unmap

Le Planificateur de tournées de livraison est un outil de répartition léger pour une petite entreprise de livraison : un fourgon quitte un entrepôt, visite jusqu'à huit clients et revient. Planifiez la tournée sur une carte en direct, ajoutez des arrêts en les cherchant, réordonnez-les, laissez unmap optimiser l'ordre et comparez-le au vôtre, consultez un horaire d'arrivée estimé et faites rouler un livreur simulé tout au long de la journée. L'application est en ligne à apps.unmap.dev/route-planner, et son code source est un projet Next.js autonome que vous pouvez cloner et exécuter avec votre propre clé.

La tournée appartient à Chinook Parcel Co., un service de messagerie fictif de Calgary. L'entreprise, les clients, leurs adresses, les notes de livraison, les temps de service et le départ de 8 h 30 sont des données d'exemple, et le livreur est une simulation, ni GPS ni suivi en direct. L'application le signale partout où ils apparaissent. La carte, les itinéraires, les temps de route, l'ordre optimisé, le tableau des temps de route et la recherche proviennent d'unmap en direct.

Ce qu'elle fait

• La tournée sur la carte : l'entrepôt, des arrêts numérotés colorés selon leur état, et l'itinéraire. Chaque tronçon est sa propre requête d'itinéraire, demandée une seule fois et conservée. Un tronçon sans réponse est dessiné comme un vide, jamais comme une ligne droite.
• Modifier les arrêts : ajoutez-en un en le cherchant (les résultats favorisent Calgary, et tout lieu au Canada est accepté), retirez-le, ou avancez-le et reculez-le avec des boutons. Jusqu'à huit arrêts.
• Optimiser : une seule requête, seulement quand vous appuyez sur le bouton. L'entrepôt reste fixe comme premier et dernier arrêt, et seuls les arrêts entre les deux sont réordonnés.
• Comparer votre ordre à celui d'unmap : les deux totaux côte à côte et la séquence optimisée avec vos numéros d'arrêts. Une différence n'est présentée comme une économie que si elle dépasse l'écart possible entre les deux calculs, et « Optimisé par Unmap » n'apparaît que si l'ordre à l'écran est celui que l'API a renvoyé.
• Horaire d'arrivée : l'heure de départ, le temps de route de chaque tronçon et le temps de service de chaque arrêt. Après un tronçon sans réponse, l'estimation s'arrête au lieu de deviner.
• Temps de route entre les arrêts : un tableau tiré d'une seule requête de matrice sur l'entrepôt et tous les arrêts, chargé seulement quand vous l'ouvrez. Une case vide signifie que le moteur n'a pas eu de réponse pour cette paire, pas qu'aucune route n'existe.
• Itinéraires : des indications virage par virage pour chaque tronçon, en français ou en anglais, sur demande.
• Livreur simulé : lecture, pause, arrêt suivant ou réinitialisation, à 60, 120 ou 300 fois la vitesse réelle. Il suit l'itinéraire propre à chaque tronçon selon son temps de route et attend le temps de service de chaque arrêt. Avec les animations réduites, il avance d'une minute simulée à la fois et la caméra ne s'anime jamais.

Ce qu'elle coûte en appels d'API

Charger la tournée d'exemple fait un appel /route par tronçon, huit en tout. Réordonner ne demande que les tronçons que l'application n'a pas encore vus, et changer de langue ne demande rien de nouveau. Optimiser coûte un appel /optimized-route, le tableau des temps de route un appel /matrix, et les itinéraires un appel /route par tronçon et par langue, chacun seulement quand vous le demandez. La recherche attend une pause dans la saisie et annule les requêtes périmées. La simulation n'appelle rien.

Une tournée compte au plus huit arrêts parce que /optimized-route accepte dix points et que l'entrepôt est envoyé deux fois, au début et à la fin.

Construite à partir du registre, sans modification

La carte, les repères, le tracé d'itinéraire, les indications et la recherche sont des éléments du registre copiés sans modification, et le code propre à l'application n'appelle l'API que par @unmap/sdk. Installer les mêmes pièces dans votre projet tient en une commande :

npx @unmap/cli add map marker-popup map-controls route-line route-steps geocoder

Ce qu'elle n'affiche pas

Ce sont des limites de l'API ou de la portée de l'application, et elle le dit au lieu de les cacher :

• La circulation. Les temps de route sont des estimations en circulation fluide, sans circulation en direct ni prévue : ni l'horaire ni la simulation ne promettent une heure d'arrivée.
• De vrais véhicules. Le livreur est une lecture le long de l'itinéraire, sans GPS et sans transmission de données.
• Plusieurs véhicules, fenêtres horaires ou capacité. Un fourgon, une tournée, sans plans enregistrés ni preuve de livraison.
• Des lieux hors du Canada. Les itinéraires et la recherche couvrent le Canada. Un arrêt à l'extérieur est refusé, et un arrêt sans lien routier est signalé sur l'arrêt comme n'ayant aucun itinéraire routier.
• Les fermetures partout. Les avertissements de fermeture couvrent l'Ontario, l'Alberta et la Colombie-Britannique, où des sources officielles existent.

Là où l'optimisation est désactivée sur un déploiement, l'API répond 404; l'application garde votre ordre, indique que l'optimisation n'est pas offerte et cesse de la demander.

L'exécuter vous-même

Il vous faut Git, Node.js 24, pnpm et une clé de navigateur du tableau de bord qui autorise http://localhost:3202.

git clone --depth 1 https://github.com/unmap-dev/route-planner.git
cd route-planner
pnpm install --frozen-lockfile
cp .env.example .env.local

Définissez NEXT_PUBLIC_UNMAP_KEY dans .env.local avec votre clé, lancez pnpm dev et ouvrez localhost:3202. Commencez par remplacer data/route.sample.json par votre propre plan : parsePlan() dans lib/plan.ts le vérifie et liste chaque problème trouvé. Pour suivre de vrais véhicules, remplacez l'horloge simulée de hooks/use-simulation.ts par les positions de votre flotte. La référence de l'API d'itinéraires décrit l'optimisation et la matrice derrière le tableau.