Elias Bellouti
EN
← Retour aux projets

Projet personnel · Logistique

Livraison : optimisation des tournées de livraison

Un coursier qui manque de chargement doit-il retourner au dépôt, ou peut-il récupérer une partie de la charge d’un collègue en ville ? J’ai développé ce projet personnel pour étudier cette question sur des scénarios de livraison synthétiques. L’outil répartit les clients, calcule les tournées sous contraintes et rend les résultats explorables sur carte. Mon travail associe la modélisation des transferts, un banc de comparaison externe et des expériences sur le compromis entre qualité de solution et temps de calcul.

Comparaisons sur instances Solomon, expériences à budget contrôlé et rejeu interactif des tournées.

Rejeu animé du solveur de livraison : trois coursiers suivent leurs tournées calculées sur une carte de Paris, avec un curseur temporel pour parcourir la journée et un compteur de colis livrés.

Mettre une idée logistique à l’épreuve

J’ai voulu savoir si des échanges entre coursiers pouvaient éviter des retours au dépôt. Pour l’étudier, j’ai construit une chaîne qui génère un scénario, recherche des tournées et restitue les arrêts, horaires et charges. On peut varier les clients, les véhicules, leur capacité et les points de transfert proposés.

Je suis parti de l’exemple OR-Tools de tournées avec rechargement. J’ai ajouté les échanges, une API de scénario et les outils de comparaison. Python organise les expériences ; OR-Tools effectue la recherche sous contraintes. Une matrice cyclable OSRM peut alimenter distances et durées, en option de l’approximation euclidienne.

Modéliser les échanges entre coursiers

Un transfert associe un dépôt et un retrait au même endroit. J’impose leur activation conjointe, deux véhicules distincts et un dépôt antérieur au retrait, suivi d’une livraison. La contrainte reste conditionnelle : le solveur doit pouvoir ignorer un point inutile.

Le modèle échange des quantités de charge, sans suivre chaque colis individuellement jusqu’à son destinataire. Les points sont fixés dans le scénario. Les quelque 700 résolutions documentées n’ont pas montré de gain convaincant dans les configurations à dépôt unique étudiées. Ce résultat a permis de préciser dans quel cadre l’idée méritait d’être poursuivie.

Comparer la qualité et le temps de calcul

Pour calibrer le moteur, je juge d’abord les clients servis, puis la fin de la dernière tournée, puis la distance. Les configurations sont comparées sur les mêmes instances et avec des budgets identiques, puis plus longs.

Un avantage de 3 186 secondes à budget court tombe ainsi à 76 secondes avec trois fois plus de calcul. Le réglage améliorait surtout la vitesse d’obtention d’une bonne solution. Le banc Solomon complète ces expériences : il distingue les objectifs publiés et vérifie les tournées indépendamment du score du moteur.

Explorer une solution sans tout recalculer

J’ai séparé le calcul du composant React et Leaflet par un document JSON de tournée. Le rejeu montre les déplacements, livraisons et variations de charge. Un corpus précalculé permet de comparer quatre budgets, de 5 à 60 secondes, et un solveur interchangeable reçoit les demandes de nouveau calcul.

Cette interface donne un usage concret aux expériences : regarder où une solution change, puis relier ce changement à ses indicateurs.

Protocole expérimental · Banc Solomon · Étude bibliographique

Les compétences mises en pratique

Optimisation combinatoire

À partir d’un exemple OR-Tools, j’ai modélisé des transferts de charge entre coursiers et étudié leur intérêt sur des tournées contraintes.

Développement web et desktop

J’ai développé une carte pour rejouer les tournées et explorer des solutions enregistrées, avec chargement, distances et progression.

Tests, évaluation et fiabilité

J’ai comparé les configurations sur les mêmes instances, à budget contrôlé, puis confronté le moteur à des références externes vérifiées.

← Retour aux projets