Aperçu
Send est une startup de livraison du dernier kilomètre qui met en relation des commerces locaux et des livreurs. J’étais le seul développeur backend : j’ai construit une API REST Laravel pour une application mobile Flutter (livreurs et vendeurs) et un tableau de bord d’administration Vue.js, que j’ai également réalisé de bout en bout.
La plateforme gère trois rôles utilisateur (administrateurs, vendeurs et livreurs), chacun authentifié par un guard Laravel Sanctum dédié. Les vendeurs soumettent des demandes de livraison pour un ou plusieurs points de dépose ; le backend planifie un itinéraire, calcule le prix, attribue un livreur et suit la livraison jusqu’à son terme.
C’était mon premier projet professionnel, construit de la conception de la base de données jusqu’à un backend et un tableau de bord complets, avec environ 85 points d’accès d’API et 15 modèles principaux. Send n’a pas encore été lancé publiquement ; le fondateur vise un lancement prochain.
Optimisation d’itinéraire à arrêts multiples
Un vendeur peut regrouper plusieurs points de dépose dans une même demande de livraison. Trouver le chemin prouvablement le plus court passant par tous est le problème du voyageur de commerce, NP-difficile et démesuré pour le nombre d’arrêts qu’un seul livreur assure réellement. Le backend utilise à la place une heuristique du plus proche voisin :
À partir de la position du vendeur, elle saute à chaque étape vers l’arrêt restant le plus proche en additionnant la distance orthodromique. Cette distance totale est rapprochée d’une tranche tarifaire par zone de distance (chaque zone ayant son propre tarif de base, son tarif au km et ses frais par arrêt) pour produire le prix.
C’est une approximation gloutonne qui utilise la distance en ligne droite plutôt que la distance routière réelle, un compromis de coût délibéré : à l’échelle où la startup opérait, l’intégration d’un service d’itinéraires payant ne se justifiait pas.
Principales contributions techniques
- Architecture d’API multi-rôles : conception et construction de trois surfaces d’API protégées indépendamment (admin, vendeur, livreur) sur Laravel Sanctum, avec des points d’accès partagés pour les ressources communes comme les commandes et les demandes de livraison.
- Planification d’itinéraire et tarification : implémentation de l’optimisation d’itinéraire par plus proche voisin décrite ci-dessus, couplée au moteur de tarification par zones de distance.
- Attribution des livreurs : mise en place de l’attribution au livreur disponible le plus proche à partir des positions en direct, en tenant compte du type de véhicule et de la disponibilité.
- Tableau de bord d’administration : construction du tableau de bord opérationnel complet en Vue 3 / Vuetify (files d’intégration et d’approbation des livreurs et vendeurs, configuration des tarifs et du parrainage, suivi des paiements et règlements, vues KPI et analytiques), qui consomme l’API que j’ai conçue.
- Notifications : intégration de Firebase Cloud Messaging pour les notifications push aux livreurs et vendeurs, et de l’API WhatsApp Cloud pour les messages de confirmation de commande, de fin de livraison et de demande d’évaluation envoyés aux vendeurs.
- Système de parrainage : création d’un programme de parrainage des vendeurs avec des bonus en pourcentage suivis par livraison.
- Authentification et onboarding : implémentation de la connexion Google OAuth pour les trois types d’utilisateurs, en plus de l’authentification classique par identifiants.
Stack technique
| Composant | Technologies |
|---|---|
| Backend | PHP, Laravel |
| Base de données | MySQL |
| Authentification | Laravel Sanctum (multi-guard), Google OAuth |
| Architecture d’API | API REST |
| Tableau de bord admin | Vue 3, Vuetify |
| Notifications push | Firebase Cloud Messaging |
| Messagerie | WhatsApp Cloud API |
Avec le recul
Send est l’endroit où j’ai appris à prendre en charge un backend de bout en bout (schéma, API, intégrations et le tableau de bord qui consomme le tout), sans développeur senior sur qui m’appuyer.
Ce que je changerais avec le recul
- Validation dans des classes
FormRequestplutôt qu’en ligne dans le contrôleur - Logique métier dans des classes de service plutôt que dans des contrôleurs surchargés
- Réponses via des API Resources
- Attribution des livreurs sous forme de job en file d’attente avec un verrouillage approprié autour de l’attribution, plutôt que de l’exécuter en ligne sans protection
C’est la leçon qui façonne aujourd’hui la façon dont je structure chaque base de code Laravel que je touche.