Trois utilisateurs, trois applications, un seul système

Le réflexe, quand on dit « application de livraison », c'est d'imaginer l'app du client : on choisit un restaurant, on paie, on suit le livreur sur une carte. Mais cette app ne sert à rien seule. Pour qu'une commande existe, il faut aussi que le restaurant la reçoive, l'accepte et signale qu'elle est prête ; et que le livreur la voie apparaître, aille la chercher et confirme qu'il l'a remise. Trois besoins, trois interfaces qui n'ont presque rien en commun.

D'où le premier arbitrage : nous avons conçu une application dédiée à chaque métier plutôt qu'une seule app qui changerait de visage selon l'utilisateur. Le client choisit vite et suit sa commande ; le restaurant reçoit et prépare depuis une app tablette qui imprime le ticket en cuisine, et gère son menu et ses statistiques depuis un panel web ; le livreur voit une adresse, un itinéraire et un bouton. Au-dessus, un back-office d'administration pilote l'ensemble. Mélanger tout cela dans une seule interface aurait produit un outil médiocre pour chacun — nous avons développé ces surfaces en Flutter, une base de code partagée pour tenir plusieurs applications sans les réécrire chacune de zéro.

Mais plusieurs applications ne font pas plusieurs produits. Elles regardent toutes le même système — un backend Firebase qui reste la seule source de vérité. Une commande n'existe pas « dans l'app du client » : elle existe dans le système, et chaque application n'en est qu'une fenêtre, avec les droits qui correspondent à son rôle. C'est ce choix — un centre, plusieurs fenêtres — qui évite qu'un jour l'app du restaurant affiche une commande que celle du client croit annulée.

Le vrai sujet n'est pas l'app, c'est la coordination

Une commande de livraison n'est pas une donnée figée : c'est un parcours qui passe de main en main. Passée, payée, acceptée par le restaurant, en préparation, prête, récupérée par le livreur, en route, livrée. À chaque étape, l'information doit remonter au système et redescendre instantanément vers les deux autres acteurs — sinon le client s'inquiète, le restaurant prépare dans le vide, ou le livreur se déplace pour rien.

Nous avons donc traité l'état de la commande comme le cœur du produit, pas comme un détail d'affichage. Chaque transition est une règle claire — qui a le droit de faire passer la commande à l'étape suivante, et à quelles conditions — et chaque changement se propage en temps réel aux applications concernées. Le client voit « votre commande est prête » à la seconde où le cuisinier appuie sur le bouton, pas à la prochaine ouverture de l'app.

L'affectation du livreur relève de la même mécanique. Quand une commande est prête à partir, le système ne l'affiche pas à tous les livreurs en même temps : il propose la course au plus proche, lui laisse un délai court pour l'accepter, puis passe au suivant s'il ne répond pas. Ce petit automatisme décide, sans intervention humaine, qui roule — et c'est lui qui tient la promesse d'un repas encore chaud.

C'est la partie invisible et la plus exigeante : la démonstration se fait sur l'écran du client, mais la fiabilité se joue dans cette mécanique d'états qu'aucun des trois utilisateurs ne voit jamais.

Faire circuler de l'argent entre des inconnus

Une plateforme de livraison ne déplace pas que des plats : elle déplace de l'argent. Le client paie, le restaurant doit être reversé de sa part, la plateforme prélève sa commission. Trois flux financiers pour une seule commande, entre des acteurs qui n'ont aucune relation contractuelle directe entre eux.

Sur ce point, la meilleure décision d'ingénierie est souvent celle qu'on ne prend pas soi-même. Nous n'avons pas voulu que la plateforme détienne l'argent des utilisateurs : encaisser puis reverser des fonds tiers, c'est un métier réglementé, avec des obligations qu'un service de livraison local n'a pas à porter. Nous nous sommes appuyés sur Stripe Connect, conçu exactement pour ça : chaque restaurant dispose de son propre compte de paiement créé via la plateforme, Stripe encaisse le client, répartit les fonds et gère la conformité. La carte bancaire du client n'est jamais stockée par la plateforme — elle transite directement chez Stripe.

Un réflexe complète ce choix, invisible mais essentiel : le prix d'une commande est toujours calculé côté serveur, jamais accepté tel que l'app le présente. Une application est un environnement qu'on ne contrôle pas ; laisser le téléphone annoncer le montant à payer, c'est ouvrir la porte à qui saura le modifier. Ce choix résume notre façon de travailler : sur ce qui touche à l'argent et aux données sensibles, s'adosser à un acteur spécialisé plutôt que réinventer une brique risquée, et ne jamais faire confiance à ce qui vient du client. Le code qu'on n'écrit pas est aussi celui qu'on n'aura pas à sécuriser.

La géolocalisation : utile, mais jamais gratuite

Le suivi du livreur sur une carte fait partie de ce que le client attend. Mais la position géographique est la donnée la plus intrusive qu'une app puisse demander, et la plus coûteuse en batterie. La traiter à la légère, c'est vider le téléphone du livreur en une matinée et collecter bien plus que nécessaire.

Le principe retenu est celui de la sobriété : on géolocalise quand ça sert — proposer les restaurants à proximité du client, suivre une course en cours — et pas en permanence. La position n'est ni un mouchard ni un historique de déplacements : c'est une information de service, active le temps d'une commande. Ce même principe de minimisation gouverne le reste des données personnelles de la plateforme, décrit sans détour dans ses politiques de confidentialité (client, restaurants et livreurs).

Commencer local, sans coder pour une échelle qu'on n'a pas

Une plateforme de livraison, dans l'imaginaire, c'est Uber Eats : des millions de commandes, des centaines de villes. La tentation est de bâtir tout de suite l'architecture de ce géant. C'est une erreur classique et coûteuse : on passe des mois à préparer une charge qui n'arrivera peut-être jamais, au lieu de sortir un service qui fonctionne sur son territoire.

Nous avons construit pour l'usage réel : un service local, lancé à Limoges en octobre 2025, avec ses restaurants et ses livreurs, sur une zone maîtrisée. Les choix techniques restent sobres et éprouvés, l'infrastructure dimensionnée pour ce qui tourne aujourd'hui — et pensée pour grandir le jour où la demande le justifie, pas avant. C'est aussi ce qui permet à un service porté par une petite structure d'exister face aux plateformes nationales : le modèle repose sur des commissions volontairement basses côté restaurants, là où les géants prélèvent lourdement — un positionnement qui n'a de sens que si l'outil coûte peu à faire tourner.

La même base sert déjà de socle à une extension préparée vers Conakry, en Guinée, aujourd'hui au stade de la pré-inscription. C'est le bénéfice concret d'un système bien posé : rouvrir le même produit sur un nouveau territoire ne demande pas de tout reconstruire.

Ce que nous en retenons

Un projet à plusieurs faces comme celui-ci ramène toujours aux mêmes principes :

C'est précisément le type de projet qui a nourri notre offre applications mobiles : des apps iOS et Android connectées à un back-office métier, avec paiement, temps réel et publication sur les stores. La technique détaillée — machine à états, paiements marketplace, temps réel — fera l'objet d'un article dédié ; ici, c'est la démarche qui compte.