Étude de cas · FoodTech · Marketplace mobile
Comment nous avons construit un agrégateur de livraison alimentaire multi-vendeur pour une startup FoodTech — applications client natives iOS et Android, un panneau d'administration pour coursiers et managers, et un moteur de routage multimodal qui respecte les délais de livraison pour les coursiers à pied, à vélo, en trottinette et en voiture. Conçu pour les marchés des États-Unis et de l'Union européenne, avec une posture conforme au RGPD et au CCPA, prête pour l'audit dès le premier jour.
Le client FoodTech s'est adressé à YuSMP Group avec un problème opérationnel précis : les coursiers choisissaient des itinéraires sous-optimaux, prenaient des détours inutiles, se perdaient dans les adresses et perdaient du temps — ce qui se traduisait par des livraisons en retard et une érosion de la confiance des clients. La vision produit était un seul agrégateur unifiant restaurants, supermarchés et pharmacies dans une seule marketplace client, tout en offrant aux managers et aux coursiers un back-office opérationnel qui réduisait réellement les délais de livraison plutôt que de se contenter de les enregistrer. L'acheteur à la demande moderne aux États-Unis et dans l'Union européenne attend un catalogue clair, un statut de commande en temps réel et une fenêtre d'arrivée qui tient — et la plateforme devait livrer les trois pour des coursiers à pied, à vélo, en trottinette et en voiture dans des réseaux urbains denses. Nous l'avons conçue de zéro comme une plateforme trilatérale : des applications client iOS et Android natives sur une API Laravel, une surface d'administration et de dispatch basée sur React pour les managers et les coursiers, et un moteur de routage multimodal au cœur qui adapte le chemin optimal au mode de transport de chaque coursier. Le build a atteint la phase finale de tests de pré-lancement sur les stores d'applications américains et européens, avec un support couvrant la publication et les mises à jour futures.
Un aperçu de ce que le build de l'agrégateur de livraison alimentaire a permis de réaliser sur iOS, Android, un plan de contrôle Laravel et un moteur de routage multimodal.
Le choix de routage domine toutes les autres décisions architecturales dans un agrégateur de livraison, car les retards de livraison étaient exactement le problème que le client nous avait engagés pour corriger. Nous avons opté pour une couche de routage multimodal sur mesure plutôt qu'une seule API de directions standard, car la même carte produit des itinéraires optimaux fondamentalement différents pour un coursier à pied, un vélo, un e-scooter et une voiture. Chaque mode obtient son propre profil de vitesse et modèle de coût aux tournants, et le dispatcher évalue les coursiers candidats par temps d'arrivée estimé, charge actuelle et adéquation du mode à la distance de livraison — puis se ré-optimise continuellement à mesure que de nouvelles commandes entrent dans la file. Une API de directions grand public brute, par contraste, suppose un seul mode de déplacement par requête et n'a aucune notion d'équité de dispatch ou de charge de flotte, de sorte que toute promesse honnête de ponctualité doit être raisonnée dans notre propre couche. Nous utilisons des fournisseurs de cartographie pour le graphe routier et piéton sous-jacent et appliquons notre logique de scoring et de dispatch par-dessus, ce qui maintient le moteur de routage portable dans les villes américaines et européennes sans réécrire le dispatcher.
Les SDK de livraison en marque blanche standard ont été éliminés tôt : leurs heuristiques de dispatch sont opaques, leurs modèles de temps de déplacement supposent des flottes uniquement automobiles, et leurs conditions de licence rendaient le modèle de compte trilatéral difficile. Développer le moteur de routage nous-mêmes sur des standards ouverts signifiait que l'ensemble du chemin — catalogue, panier, dispatch, application coursier — est un système cohérent et possédé, livré dans le cadre de notre pratique de développement de logiciels sur mesure.
| Dimension | Custom routing engine | Single-mode directions API | White-label delivery SDK |
|---|---|---|---|
| Transport modes | Walking, bike, scooter, car — separate profiles | One mode per request | Usually car-only fleet model |
| Dispatch fairness & load | Built into the scorer — ETA, load, mode fit | None — directions only | Opaque vendor heuristic |
| Re-optimization on new orders | Continuous via queued jobs | Manual re-query | Vendor-controlled |
| Three-sided account model | Native — customer, manager, courier | Not applicable | Awkward to extend |
| Portability across US & EU cities | High — swap the map graph, keep the dispatcher | High but logic-free | Region-locked licensing |
| Data ownership | Full — order and dispatch data in our plane | Queries leave to vendor | Vendor-held |
| Cost at scale | Predictable — per-graph-query only | Per-request, grows with re-queries | Per-order vendor fee |
Routing references: OpenStreetMap routing concepts, Apple MapKit documentation, Android location and maps reference.
L'application client iOS est développée en Swift, avec une page d'accueil marketplace qui rassemble restaurants, magasins et pharmacies dans une seule surface consultable, des chips de catégorie et un rail promotionnel (la bannière "première livraison gratuite" est un emplacement de merchandising piloté depuis l'admin). Le flux de détail produit et de panier était là où nous avons investi le plus d'effort, car les paniers abandonnés sont là où la plupart des applications de livraison perdent discrètement du chiffre d'affaires : le contrôle d'ajout au panier, le stepper de quantité et le total de commande en direct se mettent à jour instantanément sans aller-retour réseau, et le panier se réconcilie contre les prix du serveur uniquement au paiement. Le catalogue est mis en cache localement afin que la navigation reste fluide sur les réseaux mobiles instables, et l'application se dégrade gracieusement quand un vendeur passe hors ligne en cours de session.
La passation de commande se transmet au moteur de routage dès qu'un client confirme : le backend résout l'adresse de livraison, sélectionne le coursier approprié avec le plus faible temps d'arrivée estimé, et pousse un statut en direct que le client peut suivre depuis "accepté" jusqu'à "en route". Le même client Swift porte les flux de permission de localisation et de notification en contexte — demandés lorsque le client suit une commande pour la première fois, jamais au lancement à froid — pour satisfaire les examinateurs de l'App Store et maintenir une expérience de consentement honnête pour les utilisateurs aux États-Unis et en UE. La surface iOS de bout en bout est livrée dans le cadre de notre pratique de développement d'applications mobiles.
L'application client Android est écrite en Kotlin, partageant la même API Laravel qu'iOS mais ajustée aux réalités de la fragmentation du parc Android. Le catalogue vendeur se rend sous forme d'une grille rapide et riche en images avec des notes, des estimations de temps de préparation et des prix, soutenue par des appels API paginés et une mise en cache agressive des images pour que la liste reste fluide sur les appareils milieu de gamme des familles Samsung, Xiaomi et Pixel. L'état du panier, les favoris et la commande active survivent à la mort de processus et aux changements de configuration — une préoccupation réelle sur Android, où les optimiseurs de batterie agressifs et les suppressions de mémoire faible déchirent régulièrement l'état des applications en arrière-plan.
Le statut de commande en temps réel est le contrat auquel le client s'inscrit implicitement, de sorte que le client Android maintient un canal en direct vers le backend pour les transitions de statut — accepté, en préparation, récupéré, en route, livré — et bascule vers les notifications push lorsque l'application est en arrière-plan. Les permissions de localisation et de notification sont demandées en contexte, et l'écran de suivi de commande lit depuis le même pipeline de statut que l'application coursier écrit, de sorte que le client et le coursier ne voient jamais un état divergent. La même équipe d'ingénierie porte iOS et Android en parallèle dans le cadre de notre pratique d'ingénierie iOS et Android.
Le plan de contrôle est un backend Laravel avec une surface d'administration et de dispatch React pour les managers de restaurants et de magasins ainsi que pour les coursiers. Les managers travaillent sur un tableau de bord de commandes en direct — commandes entrantes, acceptation vendeur, minuteries de préparation — tandis que les coursiers ont une vue de dispatch avec leur itinéraire assigné, le prochain enlèvement et la livraison chez le client. Les événements de commande transitent par un seul pipeline d'état afin que le client, le manager et le coursier lisent toujours le même statut, et le travail de routage et de notification s'exécute comme des jobs en arrière-plan dans une file pour maintenir la réactivité des applications côté client sous charge. La gestion des adresses, la douleur précise soulevée par le client, est normalisée côté serveur et validée contre le graphe de carte avant qu'un coursier ne soit jamais dispatché.
Sur la confidentialité, la plateforme a été architecturée pour s'aligner sur les obligations du RGPD pour les utilisateurs dans l'Union européenne et les obligations CCPA / CPRA pour les utilisateurs en Californie et aux États-Unis. La localisation du client est collectée uniquement pour la durée d'une commande active, l'identité de paiement est gérée par le prestataire de paiement plutôt que stockée dans le plan de commande, et l'accès à la surface d'administration est limité par rôle afin qu'un coursier ne voie jamais les données client d'un autre coursier. La conception fait d'un futur examen indépendant de préparation à la confidentialité un exercice documentaire plutôt qu'une refonte architecturale.
Posture de conformité : Conforme au RGPD · Prêt pour ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA pris en compte.
Un build en cinq phases qui a conduit l'agrégateur de la spécification produit aux tests finaux de pré-lancement sur iOS, Android, un plan de contrôle Laravel et le moteur de routage.
Cartographie du modèle trilatéral (client, manager, coursier), identification des modes de défaillance liés aux retards de livraison et à la confusion des adresses, et définition en amont de la posture RGPD + CCPA et des exigences de revue App Store / Google Play.
Squelette de l'API Laravel, schéma du catalogue multi-vendeur, moteur de routage multimodal avec profils de vitesse par mode, et scorer de dispatch pour le temps d'arrivée estimé, la charge et l'adéquation du mode.
Applications client iOS en Swift et Android en Kotlin sur l'API partagée, plus les surfaces d'administration et de dispatch React pour managers et coursiers, avec panier, paiement et statut en temps réel.
Contrôle d'accès limité par rôle, normalisation des adresses contre le graphe de carte, assurance qualité des flux de permissions, tests de charge de la file de dispatch et vérification de la posture de confidentialité prête pour l'audit.
Tests finaux de pré-lancement en amont de la soumission App Store et Google Play sur les storefronts américains et européens, avec un support couvrant la publication et les mises à jour futures.
L'application côté coursier et la console de dispatch du manager sont là où la plateforme tient réellement sa promesse de ponctualité. Un coursier se connecte, voit un itinéraire assemblé par le moteur de routage pour son mode de transport, et travaille une séquence d'enlèvements et de livraisons avec guidage virage par virage et transitions de statut en un seul tap — arrivé, récupéré, livré — qui écrivent directement dans le pipeline de commandes partagé. Le dispatcher n'assigne pas simplement le coursier le plus proche ; il évalue les candidats sur le temps d'arrivée estimé, la charge actuelle et si un coursier à pied, à vélo, en trottinette ou en voiture est le bon outil pour la distance de livraison, puis se ré-optimise à mesure que de nouvelles commandes arrivent afin qu'une seule nouvelle commande ne perturbe pas un itinéraire déjà efficient. Les managers, quant à eux, gèrent un tableau de commandes React affichant l'acceptation vendeur, les minuteries de préparation et toute livraison en retard sur sa fenêtre, avec la normalisation des adresses qui corrige la confusion d'origine intégrée avant qu'un coursier ne soit dispatché. L'ensemble de la surface opérationnelle a été conçu pour l'extensibilité : l'ajout d'un nouveau type de vendeur, d'un nouveau mode de transport ou d'une nouvelle ville est un exercice de configuration et de données contre les services de catalogue et de routage, pas une livraison de code — la même discipline de mise à l'échelle que nous appliquons à nos feuilles de route cloud & DevOps.
L'agrégateur a été architecturé pour les storefronts App Store et Google Play aux États-Unis et dans l'Union européenne depuis une seule base de code par plateforme. Le build en langue anglaise est positionné pour les utilisateurs en Californie, New York, Texas, Floride et Washington aux États-Unis, et pour les utilisateurs aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans base de code distincte par région. Les flux de consentement sont adaptés à la région au niveau client : les utilisateurs de l'UE et de l'EEE reçoivent un écran de consentement granulaire de style RGPD avec des boutons séparés pour les analyses produit optionnelles, tandis que les utilisateurs en Californie reçoivent une divulgation de style CCPA "Ne pas vendre ni partager mes informations personnelles" dans le même flux. Les pratiques de traitement des données sont alignées avec le RGPD pour les utilisateurs de l'Union européenne et avec le patchwork de confidentialité des États américains — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Comme la localisation du client et les données de commande sont minimisées et éphémères par conception, la conformité régionale se réduit largement à une divulgation honnête plutôt qu'à une ségrégation des données par juridiction.
Le moteur de routage est portable dans les villes américaines et européennes par conception — le dispatcher et les profils de vitesse par mode restent constants tandis que le graphe de carte sous-jacent est échangé par région, en citant les obligations RGPD et les obligations CCPA de Californie directement dans la politique de confidentialité intégrée à l'application. La classification par âge de l'App Store et la classification de contenu de Google Play ont toutes deux été calibrées pour un ensemble de fonctionnalités de livraison alimentaire et de boissons, et les permissions de localisation et de notification sont demandées en contexte pour satisfaire les examinateurs aux États-Unis et en UE. L'équipe d'ingénierie derrière le build est répartie sur CET et travaille selon une journée CET avec un chevauchement avec la côte Est des États-Unis (9 h–13 h ET) pour les stand-ups, la chorégraphie des revues de stores et la gestion des incidents — la fenêtre de fuseau horaire permettant à une équipe produit américaine et à une équipe d'ingénierie européenne de partager quatre heures de chevauchement en direct chaque jour.
La feuille de route active de développement de logiciels sur mesure pour l'agrégateur comprend la commande planifiée et groupée, un moteur de fidélité et de promotions par-dessus les emplacements de merchandising existants, la gestion des gains et des créneaux des coursiers dans la console de dispatch, et le suivi de carte en direct du coursier sur l'écran de commande du client. Les plans d'infrastructure prévoient une automatisation accrue de la file de dispatch, des outils de déploiement multi-villes afin qu'une nouvelle région soit un exercice de données, et une option de résidence des données ancrant les données de commande de l'UE et des États-Unis dans le stockage régional — le tout intégré à la feuille de route cloud & DevOps afin que la plateforme s'étende proprement d'une ville à une empreinte nationale aux États-Unis et en UE.
Si vous planifiez un agrégateur de livraison alimentaire, une application de commerce rapide (q-commerce) ou tout produit logistique à la demande où la promesse de ponctualité doit résister à la réalité de la distribution urbaine pour des audiences en États-Unis et en UE, nous avons livré cette stack de bout en bout et pouvons réduire sensiblement les délais de construction. La plateforme a atteint la phase finale de tests de pré-lancement sur iOS et Android, et l'équipe d'ingénierie qui la pilote se trouve au sein d'YuSMP Group. Vous pouvez consulter l'ensemble du build dans notre étude de cas agrégateur de livraison alimentaire. Nous travaillons à prix fixe pour les MVP bien délimités et sur des équipes de développement dédiées pour la livraison continue, avec une journée de travail CET et une fenêtre de chevauchement garantie avec la côte est des États-Unis (9 h–13 h ET) pour les stand-ups, les démos et la gestion des incidents.
Un MVP d'agrégateur de livraison alimentaire couvrant des applications client iOS et Android, un catalogue multi-vendeur, un panier et un paiement, et un panneau d'administration coursier et manager de base coûte typiquement entre 90 000 et 220 000 €. L'ajout d'un moteur de routage coursier multimodal, du suivi en temps réel, des intégrations de paiement, des promotions et d'une application coursier séparée porte une marketplace complète à 250 000–550 000 €. Les principaux facteurs de coût sont la logique de routage et de dispatch, le modèle de compte trilatéral, et la synchronisation de l'état des commandes en temps réel sur les surfaces client, vendeur et coursier.
Laravel offre à une marketplace de livraison un backend PHP mature et complet — files d'attente pour les jobs de dispatch, un ORM expressif pour le catalogue multi-vendeur, et un grand vivier de recrutement qui maintient une plateforme trilatérale maintenable. React alimente les surfaces d'administration des managers et des coursiers avec un modèle de composants qui se mappe proprement sur les tableaux de commandes en direct et les consoles de dispatch. L'association maintient l'API et les outils web opérationnels dans un écosystème bien compris, ce qui réduit le build et abaisse le coût de possession à long terme pour les équipes américaines et européennes qui gèrent la plateforme.
Un moteur de routage multimodal sépare le modèle de temps de déplacement de la logique de dispatch. Chaque mode de transport — à pied, vélo, trottinette et voiture — obtient son propre profil de vitesse et modèle de coût aux tournants, de sorte que la même carte produit des itinéraires optimaux différents par coursier. Le dispatcher évalue les coursiers candidats par temps d'arrivée estimé, charge actuelle et adéquation du mode à la distance de livraison, puis assigne et se ré-optimise continuellement à mesure que de nouvelles commandes arrivent. Les appels de routage s'exécutent comme des jobs en arrière-plan dans une file afin que l'application côté client reste réactive.
Apple et Google exigent tous deux que les applications de livraison alimentaire divulguent clairement la collecte de données, gèrent la permission de localisation avec une justification d'utilisation au premier plan, et routent les achats numériques intégrés de manière appropriée tout en permettant aux livraisons réelles d'être payées en dehors des achats intégrés. Les deux stores attendent une politique de confidentialité fonctionnelle, des classifications de contenu appropriées à l'âge, et — pour les applications servant des utilisateurs en UE et en Californie — un flux de consentement granulaire satisfaisant le RGPD et le CCPA / CPRA sur le même écran. Les permissions de localisation et de notification doivent être demandées en contexte, pas au premier lancement.
Un MVP ciblé avec des applications client iOS et Android, un catalogue multi-vendeur, un panier et un paiement, et un panneau d'administration de base prend typiquement 16 à 28 semaines. L'ajout d'un moteur de routage coursier multimodal, d'une application coursier dédiée, du suivi en temps réel et des sous-systèmes de paiement et de promotions ajoute 8 à 14 semaines. Cela correspondait au calendrier d'environ neuf mois de ce build, qui a atteint les tests finaux de pré-lancement sur les deux stores avec un support continu couvrant la publication et les mises à jour futures.
Études de cas associées
Marketplace de courses à la demande avec application coursier, console d'opérations et suivi des commandes en temps réel aux États-Unis et en UE.
Voir l'étude →
Plateforme de plans repas et de recommandation diététique associant recettes et livraison pour les utilisateurs soucieux de leur santé aux États-Unis et en UE.
Voir l'étude →
Application grand public native iOS + Android avec un plan de contrôle renforcé et une posture prête pour l'audit aux États-Unis et en UE.
Voir l'étude →
Applications iOS, Android et multiplateformes natives avec pipelines de publication prêts pour les stores.
Découvrir le développement mobile →
Plateformes sur mesure conçues selon votre modèle métier, passant proprement du MVP à des millions d'utilisateurs.
Découvrir le développement sur mesure →
Infrastructure évolutive, pipelines CI/CD et observabilité pour que votre plateforme grandisse d'une ville à une empreinte nationale.
Découvrir Cloud & DevOps →Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvré.