26 000 repas livrés par jour ?
La logistique de livraison pour un tel volume est difficile. Nous supposons que nos chauffeurs bénévoles peuvent gérer 15 rations, soit 30 repas par trajet de livraison, et nous leur fournissons chacun un itinéraire de conduite optimisé. Il leur faut tout de même environ 1,5 à 2 heures pour effectuer leur tournée, une durée que nous estimons soutenable 2 à 3 jours par semaine pour nos bénévoles.
Pour nous, 26 000 repas équivalent à 13 000 rations. Nous nous attendons à ce que cela représente environ 7 000 arrêts (environ 2 rations par arrêt). En supposant des chauffeurs bénévoles et des voitures ordinaires pour la livraison, cela signifierait, pour nous, 700 chauffeurs conduisant tous les jours, soit, en réalité, environ 2 000 chauffeurs (car nos bénévoles ne conduiront pas tous les jours).
Si vous contrôlez la source des repas (nous ne produisons pas la nourriture, ce qui nous rend la tâche beaucoup plus difficile), vous n’avez qu’à partitionner la liste des adresses entre les chauffeurs, puis à optimiser chaque itinéraire. Notre volume est beaucoup plus faible que le vôtre (nous envisageons 2 à 3 000 repas par jour, soit 1/10 du vôtre), nous ne partitionnons donc pas automatiquement la liste des adresses. Chaque adresse de livraison est assignée à un quartier, et nos régulateurs partitionnent manuellement la liste des livraisons par quartier (c’est un simple tri sur tableur). Ensuite, nous optimisons l’itinéraire de chaque chauffeur via un serveur web hébergé sur AWS, et nous fournissons à chaque chauffeur un itinéraire de conduite optimisé (algorithme simple du voyageur de commerce).
Nous avons envisagé de partitionner automatiquement la liste complète des adresses. Mais nous n’en avons pas encore besoin, et nous n’avons pas beaucoup d’argent, nous voulons donc maintenir nos coûts pour AWS et l’API Google Maps bas 
Pour le problème généralisé d’acheminement de véhicules multiples, il existe des solutions algorithmiques simples que nous pourrions utiliser, par exemple ici :
Cependant, avec un tel nombre de livraisons, j’imagine que vous devez couvrir une très grande zone géographique, il est donc possible que vous deviez également prendre en compte les adresses de domicile de vos chauffeurs, ce qui vous sort du problème VRP classique. Peut-être que des heuristiques simples peuvent partitionner les groupes de chauffeurs et les adresses de livraison en sous-problèmes où à la fois les livraisons et les chauffeurs se trouvent dans la même zone géographique, auquel cas vous pouvez simplement réutiliser une solution VRP toute faite.
Au fait, nous utilisons la durée de trajet indiquée par GMap comme distance point à point.