Moderniser une plateforme de livraison et de logistique multi-restaurants
Une architecture coordonnée pour les applications clients, livreurs et restaurants, l’affectation des courses, le temps réel, les paiements et les déploiements multi-marques.
Classification
Projet client anonymisé
Secteur
Food delivery, logistique et commerce multi-marque
Capacités mobilisées
Ingénierie de plateforme · Applications mobiles · Workflows logistiques · Paiements et portefeuille · Architecture cloud
Synthèse exécutive
Ce que ce cas démontre
Le projet a remplacé une collection de parcours isolés par une plateforme opérationnelle où l’état de commande, l’affectation du livreur, les événements temps réel et les règles financières sont gouvernés de manière cohérente.
01 · Contexte
Le système métier dans lequel la solution s’inscrit
- 01Une commande traverse l’application client, le restaurant, le moteur d’affectation, l’application livreur et les mécanismes de paiement.
- 02Les restaurants et livreurs n’ont pas les mêmes besoins de temps réel, de notification et de tolérance aux interruptions.
- 03Le modèle doit gérer des livreurs affiliés ou indépendants, des zones, des rayons, des disponibilités et des règles de rémunération.
- 04Plusieurs marques doivent être déployées sans maintenir un code source distinct pour chacune.
02 · Défi
Le problème opérationnel à résoudre
La complexité ne résidait pas dans un seul écran de commande, mais dans la synchronisation de plusieurs applications, acteurs et états sous charge réelle.
- Une affectation concurrente pouvait proposer la même course à plusieurs livreurs sans verrouillage adapté.
- Les restaurants avaient besoin d’événements continus, tandis que les livreurs dépendaient davantage des notifications mobiles.
- Les zones, frais, délais et modes de livraison devaient produire une décision financière cohérente.
- Chaque nouvelle marque risquait de dupliquer la configuration, les builds et les procédures de publication.
- Les environnements de développement, staging et production devaient rester séparés et reproductibles.
Pourquoi les outils existants ne suffisaient pas
Traiter chaque application comme un produit indépendant créait des divergences d’état et une dette de coordination. Une source centrale de vérité et des protocoles adaptés à chaque canal étaient nécessaires.
03 · Solution
L’approche construite par Atlas
Atlas est intervenu sur l’architecture et l’implémentation d’un écosystème multi-app, avec un modèle d’état partagé et des mécanismes spécialisés pour les interactions temps réel.
- 01Applications clients pour le catalogue, la commande, le paiement, le suivi et la fidélité.
- 02Applications livreurs pour la disponibilité, les propositions de course, la navigation opérationnelle et les changements de statut.
- 03Back-office restaurant pour la réception, la préparation et le traitement des exceptions.
- 04Administration centrale pour les zones, restaurants, livreurs, marques, paiements et paramètres métier.
- 05Moteur d’affectation tenant compte du type de livreur, du rayon, de la charge, des timeouts et de la distance.
- 06Événements temps réel, notifications push et distribution Redis autour d’un état de commande centralisé.
- 07Configurations white-label pour les actifs, identifiants, environnements et pipelines de publication mobiles.
- 08Règles de portefeuille, paiement, frais et rémunération intégrées au cycle opérationnel.
04 · Architecture et produit
Les décisions qui structurent la solution
Orchestrer l’affectation par étapes
Le moteur filtre l’éligibilité, classe les candidats, propose la course et gère l’expiration avant d’élargir la recherche. Les files et verrous de données protègent les décisions concurrentes.
Adapter le temps réel au contexte utilisateur
Le back-office restaurant utilise des flux SSE pour maintenir une file active. Les livreurs reçoivent des notifications push adaptées au fonctionnement en arrière-plan. Redis distribue les événements entre instances.
Industrialiser le white-label
Les différences de marque sont isolées dans la configuration, les actifs et les pipelines. Le socle fonctionnel reste commun afin d’éviter des branches qui divergent à chaque publication.
Modéliser l’économie de livraison comme une règle métier
Les zones, distances, frais, commissions et rémunérations sont évalués dans un modèle versionné et auditable, plutôt que dispersés dans les interfaces.
05 · Impact métier
Ce que la solution doit changer
Le projet client est réel et les informations sensibles sont anonymisées. Les effets ci-dessous décrivent les capacités livrées. Les chiffres de production restent soumis à validation du client avant publication.
- Coordination plus directe entre la commande client, la préparation restaurant et la prise en charge logistique.
- Réduction du recours à l’affectation manuelle dans les scénarios couverts par le moteur.
- Meilleure visibilité sur les commandes bloquées, refusées ou en attente d’un événement.
- Prise en charge de livreurs affiliés et indépendants dans un même modèle opérationnel.
- Déploiement de plusieurs marques sur une base commune, avec moins de duplication technique.
- Application cohérente des zones, frais et règles de livraison.
06 · Preuves
Comment la solution est validée
La validation associe scénarios E2E, charge ciblée et observation des interactions entre les applications et les services.
- Tests du cycle complet depuis la création de commande jusqu’à la livraison et au paiement.
- Tests de réception et de changement de statut côté restaurant.
- Tests de concurrence et d’expiration sur l’affectation des livreurs.
- Tests de reconnexion, de diffusion temps réel et de distribution des événements.
- Tests de notification push et de fonctionnement lorsque l’application livreur est en arrière-plan.
- Tests des règles de zone, frais, paiement et portefeuille.
- Tests d’isolation de configuration et de build entre les différentes marques.
07 · Pilotage
Les métriques à suivre
Ces indicateurs définissent le protocole de mesure. Ils ne constituent pas des résultats publiés tant qu’un pilote ou le client n’a pas validé les données.
| Indicateur | Ce qu’il vérifie | Mode de mesure |
|---|---|---|
| Temps d’affectation | Mesurer la réactivité logistique | De la disponibilité de la course à son acceptation par un livreur |
| Taux d’affectation automatique | Évaluer la couverture du moteur | Courses affectées sans intervention manuelle sur courses éligibles |
| Interventions manuelles | Identifier les exceptions coûteuses | Actions opérateur nécessaires pour 100 commandes |
| Erreurs de zone ou de frais | Contrôler les règles commerciales | Incidents confirmés par volume de commandes |
| Délai de déploiement d’une marque | Mesurer l’efficacité white-label | Du gel de configuration à la disponibilité en environnement cible |
| Incidents de synchronisation | Surveiller la cohérence multi-app | Divergences d’état confirmées par période et par parcours |
08 · Retour d’expérience
Les enseignements à retenir
- 01Une plateforme de livraison est d’abord un système de coordination distribué.
- 02Un seul mécanisme temps réel ne convient pas à toutes les applications du terrain.
- 03L’affectation automatique doit rendre ses décisions et ses expirations observables.
- 04Le white-label devient rentable lorsque la variabilité est traitée comme de la configuration testée.
Pour aller plus loin
Capacités et services liés
Votre contexte mérite une solution mesurable.
Nous cadrons le problème, les contraintes, les décisions et les preuves attendues avant de proposer une trajectoire de livraison.