Créer une application de livraison : commandes, coursiers et répartition

La carte ne raconte pas toute la livraison

Une application de livraison ne se résume pas à la carte affichée au client. Elle doit décider qui accepte la mission, comment elle est attribuée, ce qui se passe sans réseau, comment le prix est calculé et comment l'équipe traite une livraison incomplète.

Ce qu'inclut un MVP

Une première version est utile si elle permet de traiter une vraie commande, de son paiement à sa remise. Prenons un repas : le restaurant confirme, prépare, puis remet le sac au coursier, qui le livre au client. Un trajet en taxi obéit à d'autres règles de prix et de sécurité ; il ne suffit pas d'ajouter une case à ce parcours pour couvrir les deux métiers.

Il faut donc un parcours client, un parcours coursier et une interface pour attribuer les commandes, corriger les statuts, gérer les remboursements et répondre aux réclamations. Les notifications doivent correspondre à ce qui s'est réellement passé, pas à une estimation optimiste.

Pour les contraintes propres aux restaurants, consultez le guide des applications de livraison de repas. Le même parcours général s'applique aux colis et aux commerces de proximité, avec des règles différentes pour la prise en charge et le retour.

Les rôles changent le périmètre

Ce qui complique vraiment l'attribution

Des guides pratiques comme l'article de Leanware sur les applications de livraison et l'analyse d'Appscrip sur le coût des services à la demande montrent que la difficulté ne vient pas seulement de la carte, mais surtout des règles opérationnelles qui l'entourent.

Qui reçoit la demande en premier ? Que faire en cas de refus ? Peut-on grouper deux commandes ? Que se passe-t-il si l'adresse change ou si le chauffeur perd le réseau ? Comment l'assistance corrige-t-elle un statut erroné ? Les outils cartographiques aident, mais ne définissent pas les règles métier. Les cartes, le serveur et l'administration doivent donc être estimés ensemble. Voir le guide sur le serveur d'une application mobile.

Paiements et remboursements

Beaucoup de services de livraison ressemblent à une marketplace : le client paie, la plateforme prend une commission, le livreur ou prestataire reçoit un versement et l'assistance peut effectuer un remboursement. Cela rejoint les sujets des marketplaces et du commerce mobile.

Ce qu'il faut automatiser plus tard

Le coût augmente avec la localisation en temps réel, le calcul d'itinéraires, le prix par distance, l'affectation et la réaffectation, les zones, les créneaux, les prix dynamiques, les paiements aux prestataires, les pourboires, l'assistance, les litiges et les intégrations avec la caisse, le CRM, le stock ou la comptabilité.

La façon la plus simple de réduire le périmètre est de commencer par une attribution manuelle, une petite zone, quelques statuts et un seul modèle de paiement. L'automatisation vient après les premières données d'usage.

Comment Appfyl travaille

Appfyl cartographie la boucle opérationnelle : demande du client, attribution, changements de statut, paiement, intervention d'un membre de l'équipe et cas d'échec. Nous décidons ensuite ce qui doit être automatisé dès le départ et ce qui peut rester manuel. Pour le budget, utilisez le guide du coût de développement ou le calculateur Appfyl.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Limiter la première zone et garder la main

Un premier lancement peut conserver une affectation manuelle, quelques statuts et une zone réduite. Décrivez le refus, la réaffectation, le retard, le changement d'adresse, l'échec du paiement et la preuve de livraison. Testez aussi les codes d'accès, les étages, les consignes et le contact du destinataire. Ces cas indiquent si le suivi continu et l'optimisation des tournées sont indispensables dès le départ ou si de bons outils de coordination suffisent pour apprendre avec moins de risque.

Faire l'essai avec des commandes qui se passent mal

Imaginez que le restaurant annonce dix minutes de retard après que le coursier a accepté la course. Le coursier doit voir le nouvel horaire et le client, un message compréhensible. Une simple icône sur une carte ne suffit pas. Si le coursier refuse, la commande revient à la répartition ou à un opérateur ; elle ne doit pas rester indéfiniment « en cours ».

Testez aussi la perte de réseau. Le coursier peut conserver les informations déjà chargées, mais les changements de statut doivent attendre la reconnexion et être rapprochés des mises à jour plus récentes. L'assistance doit voir qui a déclaré quoi et à quel moment. Si le destinataire est absent, notez la tentative de contact et choisissez explicitement entre nouvelle livraison, retour et remboursement. Un colis non remis n'est pas une livraison terminée.

Dans une première zone, mesurez les réattributions manuelles, le délai entre la préparation et l'enlèvement, ainsi que les remises contestées. Vous saurez alors si l'automatisation répond à un problème réel. Le guide de l'application coursier détaille le travail côté livreur.

Attribuer chaque incident à une personne

Il serait facile de renvoyer tous les problèmes vers « l'assistance ». Pourtant, le commerçant sait si la commande peut être préparée, le coursier sait s'il peut arriver et la personne chargée de la répartition connaît les autres courses disponibles. Définissez qui peut annuler, repousser l'enlèvement ou autoriser une nouvelle tentative. Une annulation avant la prise en charge ne se traite pas comme une annulation après que le coursier a reçu le colis.

Pendant l'essai, choisissez trois vraies commandes et reconstituez ce qui a été promis, ce qui s'est produit et ce que le client a appris. Si personne n'y parvient sans ouvrir plusieurs tableaux, ajoutez d'abord un historique lisible dans l'interface de gestion. Il rendra souvent plus de services qu'une carte animée supplémentaire.

Questions fréquentes