Applications

Application mobile livraison : fonctionnalités indispensables et erreurs à éviter

Une application de livraison démarre à 5 000 € HT pour une version simple, se situe entre 8 000 et 15 000 € HT dès qu'elle gère des livreurs, le paiement en ligne et le suivi des courses, et devient une plateforme à partir de 15 000 € HT quand plusieurs commerces s'y rejoignent. Ce guide détaille les fonctionnalités qui comptent vraiment, celles que vous pouvez repousser, et les erreurs qui font dérailler ce type de projet.

Applications · Lecture : 19 min · Agence DYNSEO

Application de livraison : trois écrans, trois publics, un seul système

Une application de livraison est d'abord un système de commandes qui parle à trois personnes différentes. Le client choisit et suit, le livreur reçoit et exécute, le commerçant prépare et valide. Chacun a besoin d'un écran pensé pour sa situation : le client est souvent installé dans son canapé, le livreur est dans la rue avec un casque ou un gant, le commerçant est derrière son comptoir en plein coup de feu.

C'est ce qui distingue ce projet d'une application vitrine. Un seul écran mal conçu suffit à dégrader l'ensemble : un commerçant qui rate une commande parce que l'alerte n'a pas sonné, c'est un client qui attend, un livreur qui patiente, et un remboursement à gérer.

S'y ajoute un quatrième acteur, invisible du public : l'administrateur. Le back-office (une interface web réservée à vous ou à votre équipe) permet de suivre les courses en cours, de corriger une commande, de rembourser, d'ajouter un livreur ou de modifier une zone. Il arrive qu'un projet le découvre trop tard, alors qu'il conditionne l'exploitation quotidienne.

Notre page sur le développement d'applications mobiles présente la façon dont nous découpons ce type de projet en lots, du plus simple (une application pour vos propres livreurs) au plus large (un service où plusieurs commerces se rejoignent).

Les fonctionnalités indispensables d'une application de livraison, acteur par acteur

La question à se poser pour chaque fonction est la même : que se passe-t-il le jour du lancement si elle manque ? Si la réponse est « une commande ne peut pas aboutir », elle est indispensable. Si c'est « l'expérience est moins agréable », elle peut attendre.

Côté client

• Un catalogue lisible : produits ou plats, photos, prix, options (taille, cuisson, supplément) et indication de disponibilité.
• Un panier qui annonce le prix final : produits, frais de livraison, éventuel pourboire. Un montant qui change à la dernière étape fait abandonner la commande.
• Le choix du créneau : livraison immédiate ou créneau programmé, avec des horaires cohérents avec ceux du commerce.
• L'adresse et la vérification de la zone : l'application doit dire tout de suite si l'adresse est desservie, avant que le client ne remplisse un panier.
• Le paiement en ligne, avec les moyens que vos clients utilisent réellement, et un reçu envoyé automatiquement.
• Le suivi de la commande par étapes (acceptée, en préparation, en route, livrée), avec notification sur le téléphone à chaque changement.
• Un moyen de joindre quelqu'un en cas de problème : un bouton d'appel ou un message, rattaché à la commande.

Côté livreur

• La réception d'une course avec un temps pour répondre : adresse de retrait, adresse de remise, contenu, rémunération si elle est affichée. Sans délai de réponse, une course peut rester en suspens.
• La navigation : soit une carte intégrée, soit l'ouverture de l'application de cartographie que le livreur utilise déjà.
• Les changements d'état en un geste : « arrivé au commerce », « commande récupérée », « livrée ». Chaque état alimente le suivi du client.
• Le signalement d'un incident : client injoignable, adresse introuvable, produit endommagé. Sans ce bouton, le livreur appelle le commerçant, qui est occupé.
• Un historique des courses, utile à la rémunération et aux litiges.

Côté commerçant

• Une alerte de nouvelle commande qui ne peut pas passer inaperçue : son répétitif tant que la commande n'est pas acceptée, plutôt qu'une simple notification silencieuse.
• L'acceptation ou le refus avec un temps de préparation annoncé, repris dans l'estimation donnée au client.
• La gestion du catalogue au quotidien : marquer un produit en rupture en deux touches, sans passer par un administrateur.
• L'ouverture et la fermeture : une pause « coup de feu » qui bloque temporairement les commandes est une fonction utile en restauration.

Côté administration

Le back-office doit au minimum permettre de voir toutes les commandes et leur état, de réaffecter une course, d'annuler et de rembourser, de modifier zones et frais de livraison, et d'exporter les données pour la comptabilité. Un tableau de bord avec les délais moyens et les motifs d'échec vient ensuite : il est précieux, mais il n'est pas nécessaire au premier jour.

Suivi en temps réel et paiement : les deux fonctions de l'application de livraison à soigner en priorité

Ce sont deux fonctions que les clients jugent immédiatement, et que les équipes sous-estiment. Dans les deux cas, le point délicat n'est pas l'écran : c'est ce qui se passe derrière.

Le suivi de la course sur la carte

Afficher un point qui se déplace suppose que le téléphone du livreur envoie sa position régulièrement, y compris lorsque l'application est en arrière-plan. Les systèmes iOS et Android encadrent cet usage : l'utilisateur doit donner une autorisation explicite, et un usage jugé excessif peut être limité par le système ou refusé lors de la publication de l'application. Cela se prépare dès la conception, avec un texte d'explication clair pour le livreur.

Il faut aussi arbitrer entre précision et autonomie de la batterie. Envoyer la position chaque seconde donne une carte fluide mais épuise un téléphone en quelques heures de service ; l'espacer de quelques secondes peut suffire pour rassurer un client. Ce réglage se teste sur le terrain, avec de vrais téléphones et de vraies tournées, pas sur un simulateur.

Les services de cartographie et de calcul d'itinéraire sont des services tiers. Ils peuvent être facturés à l'usage au-delà d'un certain volume : vérifiez les conditions du fournisseur retenu, car la facture évolue avec le nombre de courses. Nous le chiffrons avec vous dès le devis.

Le paiement en ligne

Le paiement passe par un prestataire de paiement spécialisé : l'application ne stocke jamais les numéros de carte. La réglementation bancaire européenne impose, dans de nombreux cas, une authentification forte du payeur (un code reçu ou une validation dans l'application de la banque). Cette étape doit être intégrée au parcours sans que le client se perde, et testée avec de vraies cartes avant la mise en ligne.

Reste la question des flux d'argent. Si vous livrez vos propres produits, le client vous paie : c'est simple. Si plusieurs commerces vendent sur l'application et que vous prélevez une commission, il faut un prestataire capable de répartir les paiements entre vous, le commerçant et parfois le livreur. Ce montage a des conséquences juridiques et comptables : parlez-en à votre expert-comptable avant de figer le modèle.

Application de livraison, site de commande ou solution toute faite : comparer avant de choisir

Une application n'est pas la seule façon de livrer des commandes. Selon votre activité, un site de commande en ligne, ou un outil existant que l'on paramètre, peut suffire pendant un temps. Voici les options, avec leurs limites réelles.

Notre conseil : si vos commandes arrivent déjà par téléphone ou par messagerie, commencez par un site de commande, qui vous apprend ce que vos clients commandent réellement, puis passez à l'application quand le suivi et les notifications deviennent un besoin visible. Nos modèles de boutiques WooCommerce montrent ce que l'on peut obtenir pour une commande en ligne sans application.

À l'inverse, si vous voulez que plusieurs commerçants vendent sur votre service, le projet relève de la création d'une marketplace, avec ses propres sujets : inscription des vendeurs, commissions, litiges entre commerçant et client.

Trois projets d'application de livraison imaginaires, trois périmètres différents

Ces trois situations sont illustratives : ce ne sont pas des clients réels, et aucun montant hors barème n'y figure. Elles montrent comment le périmètre se déplace avec le nombre d'acteurs.

Scénario 1 : une épicerie de quartier qui livre à vélo

Imaginons une épicerie fine qui emploie deux livreurs à vélo et livre dans un rayon de quelques rues. Les clients sont des habitués, le catalogue change selon l'arrivage, et les paniers sont modestes. Le besoin réel : prendre les commandes sans téléphone qui sonne, annoncer une plage horaire, prévenir le client à l'arrivée. Une application simple suffit : un catalogue géré par la gérante, un panier, un paiement, une liste de courses pour les livreurs. Le suivi sur carte apporte peu sur un trajet de dix minutes ; une notification « votre livreur arrive » fait le travail. Le budget se situe dans la zone d'une application simple.

Scénario 2 : un restaurant avec sa propre flotte de livreurs

Imaginons un restaurant qui souhaite cesser de payer une commission aux grandes plateformes et livrer lui-même. Ici, la cuisine, la caisse et la route doivent rester synchronisées : la commande déclenche un bon en cuisine, un temps de préparation, puis l'affectation à un livreur dont la position est suivie. Le suivi en temps réel prend son sens, de même que la gestion des ruptures et des pauses coup de feu. L'application a trois écrans et un back-office : c'est une application métier, avec un budget à la hauteur.

Scénario 3 : des commerçants d'une même ville qui se fédèrent

Imaginons une association de commerçants qui veut proposer un service commun : boucher, fromager, fleuriste, caviste. Un client commande chez plusieurs commerces dans un seul panier, un livreur passe les récupérer. Les difficultés changent de nature : un panier multi-commerces implique des paiements répartis, des délais de préparation différents, une commission, et une règle quand un des produits manque. Techniquement comme juridiquement, c'est une plateforme, et le projet se prépare avec un atelier de cadrage avant tout devis ferme.

Les erreurs qui coûtent cher dans un projet d'application de livraison

Les projets de livraison échouent rarement à cause d'un bogue. Ils échouent parce qu'une situation du quotidien n'avait pas été prévue. Voici celles qui reviennent le plus souvent dans ce type de projet.

1. Concevoir uniquement l'application du client. Sans écran pour le commerçant et le livreur, les commandes arrivent par téléphone et par captures d'écran : l'application ne remplace rien.
2. Oublier les échecs de livraison. Client absent, interphone en panne, produit manquant, commande renversée : chaque cas appelle une décision écrite (reporter, rembourser, facturer le déplacement) et un bouton dans l'application.
3. Lancer partout à la fois. Une zone, un type de commerce et quelques livreurs permettent d'apprendre. Une couverture large dès le premier jour multiplie les cas particuliers avant que les bases ne soient stables.
4. Copier les grandes plateformes de livraison. Elles ont des équipes entières pour l'affectation automatique des courses. Pour un service local, une affectation manuelle depuis le back-office, au départ, est plus sûre qu'un algorithme que personne ne comprend.
5. Tout promettre dans le suivi. Afficher « arrivée dans 6 minutes » sans tenir compte de la circulation et de la préparation crée une attente que vous ne pouvez pas tenir. Mieux vaut une fourchette honnête.
6. Négliger l'outil du commerçant. Une tablette qui ne sonne pas, un menu impossible à mettre à jour : le commerçant reprend le téléphone, et vos clients aussi.
7. Ignorer la publication sur les magasins d'applications. Les règles des magasins (explications des autorisations, politique de confidentialité, modalités de paiement) peuvent entraîner un refus et un délai supplémentaire. Elles se préparent en amont.
8. Ne rien prévoir pour le service client. Un client dont la commande est en retard cherche un interlocuteur. Sans bouton d'aide et sans personne pour répondre, l'avis arrive sur les magasins d'applications.

Ce qu'une application de livraison doit respecter : alcool, allergènes, livreurs, données de position

Nous ne sommes pas juristes, et les règles évoluent : cette section donne des repères généraux, à faire confirmer par un professionnel du droit ou par l'organisation qui représente votre secteur. Elle sert à poser les bonnes questions avant le cahier des charges, pas à les trancher.

Reste la question la plus délicate : le statut des livreurs. Salarié, travailleur indépendant, prestataire d'un service de coursiers : le choix a des conséquences en droit du travail et en protection sociale, et il ne se règle pas par l'application. Elle doit seulement refléter votre choix (par exemple en ne dictant pas d'horaires imposés si le livreur est indépendant). Avant de lancer, faites examiner votre organisation par un avocat ou par un conseiller spécialisé.

Enfin, côté technique, un service qui traite des paiements et des adresses doit être hébergé et sécurisé sérieusement : connexions chiffrées, comptes protégés, droits d'accès distincts pour le client, le livreur, le commerçant et l'administrateur. Cela fait partie du chiffrage, pas d'une option.

Le budget d'une application de livraison : ce qui fait monter ou descendre la facture

Une application simple de livraison commence à 5 000 € HT, une application métier se situe de 8 000 à 15 000 € HT, et une plateforme démarre à 15 000 € HT. Ces paliers dépendent du nombre d'acteurs, des règles de gestion et des services tiers branchés. La facture ne tient pas au nombre d'écrans.

Un point de technique qui joue sur le budget : nous développons avec Flutter, qui permet de livrer une même application sur iPhone et sur Android à partir d'un seul code. Vous évitez de payer deux développements parallèles, même si certains réglages, comme la position en arrière-plan, restent propres à chaque système.

À ces montants s'ajoutent des frais récurrents que le devis détaille : hébergement du serveur, services de cartographie, envoi de notifications et de SMS, commissions du prestataire de paiement, et compte développeur sur les magasins d'applications. Pour une première estimation, le simulateur de coût d'application mobile donne un ordre de grandeur en quelques minutes.

De la maquette au lancement de l'application de livraison, étape par étape

Un projet de livraison se découpe en lots, pour que vous voyiez fonctionner quelque chose tôt et que les erreurs se corrigent quand elles coûtent encore peu. Voici l'enchaînement que nous proposons, avec ce que vous avez à préparer à chaque étape.

1. 1

   Atelier de cadrage

   Nous parlons de votre activité, de vos livreurs, de vos zones et de vos règles. À préparer : vos horaires, vos zones de livraison, la façon dont vous facturez aujourd'hui, et la liste de ce qui se passe quand une livraison échoue.

2. 2

   Scénarios et maquettes

   Nous dessinons les parcours des trois acteurs sous forme de maquettes cliquables, avec des allers-retours illimités jusqu'à votre validation. Montrez-les à un livreur et à un commerçant : leurs remarques valent plus que les nôtres.

3. 3

   Premier lot : commander et livrer

   Catalogue, panier, paiement, réception de la course, changement d'état. L'objectif est de faire passer une vraie commande de bout en bout, même dans une version rudimentaire.

4. 4

   Tests sur le terrain

   Vraies tournées, vrais téléphones, vraies conditions de réseau. Nous testons le paiement, la position, les alertes du commerçant et les cas d'échec. Les tests sont offerts.

5. 5

   Publication sur les magasins

   Préparation des fiches, des textes d'explication des autorisations et de la politique de confidentialité, puis dépôt. Prévoyez un délai pour d'éventuelles demandes de modification des magasins.

6. 6

   Lancement progressif et formation

   Démarrage avec un petit groupe de commerçants et de livreurs, puis élargissement. La formation de vos équipes est offerte et se fait sur le vrai outil.

Le calendrier dépend surtout de la rapidité avec laquelle vous répondez aux questions de cadrage et aux règles à trancher (frais, zones, remboursements). Une application simple se compte en semaines, une plateforme en mois : la durée précise est fixée au devis, après l'atelier.

Après le lancement de l'application de livraison : exploiter, mesurer, faire évoluer

Une application de livraison est un service en fonctionnement permanent. Les systèmes iOS et Android évoluent chaque année, les magasins modifient leurs exigences, un livreur change de téléphone : l'application demande une attention régulière, comme un véhicule demande un entretien.

• La maintenance technique : mises à jour pour rester compatible avec les nouvelles versions des systèmes, correctifs, surveillance du serveur. En cas de panne, nous intervenons dans l'heure ouvrée.
• Les indicateurs à suivre : délai moyen entre commande et remise, nombre de livraisons échouées et leurs motifs, taux de commandes refusées par les commerçants. Trois chiffres simples, relevés chaque semaine, dessinent les évolutions à prioriser.
• Les évolutions : une fonction à la fois, en fonction de ce que vos données montrent. Fidélité, avis, promotions ou affectation automatique viennent à leur tour, quand les bases sont stables.
• Les comptes et les accès : le compte développeur sur les magasins d'applications et l'hébergement doivent être à votre nom, pour que vous gardiez la main sur votre service.

Pour mesurer sérieusement, comparez des périodes de même nature (une semaine de semaine avec une autre) et évitez de conclure sur quelques commandes. Nous ne promettons aucun volume de commandes : il dépend de votre offre, de votre zone et de votre capacité à la faire connaître.

Si votre course ressemble à une course de transport de personnes plutôt que de marchandises, notre page sur les applications de taxi et de VTC présente des mécanismes voisins : mise en relation, suivi de position, paiement.