Rapport de Stages Tad

Génie Mathématique et Modélisation 3éme Année
RAPPORT DE STAGE 2012 - 2013
Conception de méthodes pour le transport à la

demande pour les terminaux mobiles de type
smartphones sous Android
Soutenu le 10 septembre 2013
Présenté par
Benjamin Vincent
Responsable du stage Polytech : Gaelle LOOSLI
Responsables du stage au LIMOS : Philippe LACOMME, Nicolay TCHERNEV et Libo REN

Remerciements
Je tiens à remercier dans un premier temps, la direction du LABEX IMOBS3 et plus particulièrement,
Monsieur le Professeur Alain Quilliot responsable du challenge 2 « Services & Systèmes de Mobilité
Intelligente » qui a rendu ce stage possible.
Je tiens également à remercier tous les membres du LIMOS de leur accueil chaleureux.
L’encadrement de mon stage a été réalisé au quotidien par Philippe LACOMME, Nicolay TCHERNEV et Libo
REN. De par leur suivi régulier ils m’ont permis de découvrir le monde de la recherche et ils ont partagé
avec moi leur expérience. Merci aussi à eux pour m'avoir fait découvrir la notion de publication scientifique
et d'avoir écrit avec moi des articles pour des conférences.
Un grand merci pour l’accueil qu’ils m’ont réservé et merci de m’avoir permis de trouver un financement de
thèse, thèse qui débute à la suite de ce stage au sein du LIMOS en collaboration avec Ip Leanware.
Enfin ces remerciements ne seraient pas complets sans y associer les thésards que j’ai eu le plaisir de
fréquenter pendant 6 mois. Sans chercher à les citer tous citons Raksmey PHAN et Diyé DIA.
Résumé
Ce stage a été réalisé au sein du LIMOS, qui est une unité de recherche CNRS et a porté sur l'étude de
différents problèmes de tournées de véhicules dont en particulier le VRP et le HVRP. Dans un premier
temps, mon travail a consisté à implémenter une métaheuristique de résolution approchée du VRP. Dans un
deuxième temps nous nous sommes intéressé au problème de cheminement dans un environnement
urbain afin de pouvoir appliquer le travail sur les tournées de véhicules avec des instances issues d’un
réseau urbain. Nous nous sommes particulièrement intéressé au cas de cheminement de piétons avec
comme objectif de concevoir des algorithmes de cheminement dédiés aux contraintes spécifiques liées au
contexte mobile. Le travail réalisé a donné lieu à la conception d'un web service et d'une application mobile
pour piéton. Enfin le troisième chapitre est dédié à la conception d'une métaheuristique pour HVRP qui est
testée sur des instances de la littérature mais aussi sur des instances générées à partir de réseaux routiers.
Le travail réalisé durant ce stage a donné lieu à trois soumissions dans des conférences.
mots clefs : tournées de véhicules, métaheuristique, cheminement, milieu urbain, mobilité.
Abstract
This internship has been achieved in the LIMOS, a CNRS research unit and has been focused on the
study of different vehicles routing problems especially on the VRP and on the HVRP. At first, my job was to
implement a metaheuristic which is an approximated method of VRP. In a second step we studied the
routing problem in an urban in the case of pedestrian with the objective to design algorithms dedicated to
the specific constraints in mobile context. The work carried out has resulted in the design of a web service
and a route guidance application for pedestrian. Finally, the third chapter of this report is dedicated to
design of metaheuristics for HVRP. The metaheuristic we introduced is benchmarked on instances of the
literature but also on instances generated from real life networks. The work achieved during this internship
resulted in three submissions in conferences.
Keywords : vehicle routing problems, metaheuristic, routing, urban area, mobility.
Table des matières
Table des matières .................................................................................................................................. i
Liste des figures ..................................................................................................................................... v
Liste des tableaux ................................................................................................................................ vii
Liste des algorithmes........................................................................................................................... viii
Introduction........................................................................................................................................... 1
Chapitre 1 : Le problème de base en tournées de véhicules : le VRP......................................................... 3
1. Problème du type VRP .......................................................................................................................... 3
1.1 Présentation du VRP ............................................................................................................................ 3
1.2 Etude sur les méthodes de résolution existantes ............................................................................... 5
2. Conception d’une métaheuristique basée sur un codage indirect ...................................................... 6
2.1 Codage indirect des solutions.............................................................................................................. 6
2.2 Critères d’évaluation d’une métaheuristique ..................................................................................... 8
3. Principe d'un GRASP/ELS basé sur un codage indirect......................................................................... 9
3.1 Définition d’une métaheuristique GRASP ........................................................................................ 9
3.2 Définition d’une métaheuristique ELS ........................................................................................... 11
3.3 La méthode hybride GRASP/ELS .................................................................................................... 11
4. GRASP/ELS proposé ............................................................................................................................ 12
4.1 Schéma général de la méthode implémentée ............................................................................... 13
4.2 Etape d’initialisation : la méthode des plus proches voisins ......................................................... 13
4.3 L’algorithme Split ........................................................................................................................... 14
4.4 La mutation .................................................................................................................................... 18
4.5 La recherche locale ........................................................................................................................ 19
5. Expérimentations numériques ........................................................................................................... 21
5.1 Paramètres ..................................................................................................................................... 21
5.2 Performances des ordinateurs utilisés........................................................................................... 22
5.3 Résultats numériques .................................................................................................................... 22
6. Conclusion .......................................................................................................................................... 23
7. Références .......................................................................................................................................... 23
Chapitre 2 : Le problème de cheminement de piétons en milieu urbain ............................................... 25
8. Introduction ........................................................................................................................................ 25
i
Table des matières
1.1 Le problème du plus court chemin .................................................................................................... 26

1.2 Principaux algorithmes de résolution d’un problème de PCC ........................................................... 27
9. Application du problème de PCC dans un environnement mobile .................................................... 35
2.1 Les contraintes à prendre en compte ............................................................................................ 35
2.2 Etude sur la structure d'un système orienté mobile...................................................................... 36
2.3 Etude sur la limitation de la taille du graphe ................................................................................. 37
2.4 Proposition d’une structure d'un système orienté mobile ............................................................ 39
2.5 Proposition d'un système "dynamique" de calcul du PCC ............................................................. 40
10. Réalisation du système de guidage orienté mobilité ......................................................................... 41
3.1 Etude sur les services de cartographie .............................................................................................. 41
3.2 Analyse des besoins du système liés au service de cartographie ..................................................... 42
3.3 Réalisation du Web service ............................................................................................................... 43
3.4 Réalisation d'un client Android.......................................................................................................... 46
11. Analyse des résultats .......................................................................................................................... 48
4.1 Présentation des données ......................................................................................................... 49
4.2 Analyse des résultats : cas idéal ................................................................................................ 50
4.3 Analyse des résultats : cas avec aléas ........................................................................................ 53
12. Conclusion .......................................................................................................................................... 56
13. Références .......................................................................................................................................... 56
Chapitre 3 : Etude du HVRP dans un contexte mobile ............................................................................ 59
1. Problème du type HVRP ..................................................................................................................... 59
1.1 Présentation du HVRP .................................................................................................................... 59
1.2 Etude sur les méthodes de résolution existantes ............................................................................. 61
2. Métaheuristique proposée basée sur un Path-Relinking ................................................................... 62
2.1 Schéma général de la méthode implémentée .................................................................................. 63
2.2 La méthode Split ............................................................................................................................ 65
2.3 Heuristique de génération de solutions ............................................................................................ 71
2.4 Proposition d'une méthode de type Path-Relinking ......................................................................... 73
2.5 La recherche locale ............................................................................................................................ 76
3. Paramètres et résultats ...................................................................................................................... 79
3.1 Paramètres sur les instances classiques ............................................................................................ 79
3.2 Performances des ordinateurs utilisés .............................................................................................. 80
3.3 Résultats numériques sur les instances classiques........................................................................... 80
ii
Table des matières
3.4 Présentation de l’instance générée sur un réseau routier concret .................................................. 82

3.5 Résultats sur l’instance de Clermont-Ferrand .................................................................................. 83
4. Conclusion .......................................................................................................................................... 86
5. Références .......................................................................................................................................... 86
Conclusion ........................................................................................................................................... 89
Annexes ............................................................................................................................................... 91
iii
Liste des figures
Figure 1 : Solution d’un problème de VRP .......................................................................................... 5
Figure 2 : Classification des fonctions de mapping d'après (Cheng et al., 1996) ................................ 7
Figure 3 : Liste des publications avec un codage indirect selon Duhamel et al., [Duh12] ................. 8
Figure 4 : Schéma d’une heuristique efficace selon (Duhamel et al., 2011 )....................................... 9
Figure 5 : Initialisation de la méthode GRASP.................................................................................. 10
Figure 6 : Recherche locale de la méthode GRASP .......................................................................... 10
Figure 7 : Mutation d’un algorithme ELS .......................................................................................... 11
Figure 8: Recherche locale d’un algorithme ELS .............................................................................. 11
Figure 9 : Schéma d’une métaheuristique de type GRASP/ELS ....................................................... 12
Figure 10 : Mise en correspondance de l’espace des solutions et de celui des tours géants. ............. 12
Figure 11 : Schéma du GRASP/ELS proposé .................................................................................... 13
Figure 12 : Méthode des plus proches voisins ................................................................................... 14
Figure 13 : Exemple d’un problème avec clients déjà ordonnancés .................................................. 15
Figure 14 : Exemple de tournées incluant le premier client .............................................................. 16
Figure 15 : Exemple de tournée n’incluant pas le premier client (A) ................................................ 16
Figure 16 : Schéma de l’ensemble des tournées possibles................................................................. 16
Figure 17 : Calcul du plus court chemin ............................................................................................ 17
Figure 18 : Etape de mutation de l’algorithme GRASP/ELS ............................................................ 18
Figure 19 : Mouvement de type 2-opt intra-tournée .......................................................................... 19
Figure 20 : Mouvement de type 2-opt inter-tournées ........................................................................ 20
Figure 21 : Schéma de la méthode de type GRASP/ELS .................................................................. 22
Figure 22 : Graphe d’un problème de plus court chemin .................................................................. 26
Figure 23 : Initialisation de Dijkstra .................................................................................................. 28
Figure 24 : Première itération de Dijkstra .......................................................................................... 28
Figure 25 : Deuxième itération du Dijkstra ....................................................................................... 29
Figure 26 : Troisième itération du Dijkstra ........................................................................................ 29
Figure 27 : Dernière itération de Dijkstra .......................................................................................... 30
Figure 28 : Initialisation de Bellman.................................................................................................. 31
Figure 29 : Première itération de Bellman ......................................................................................... 31
Figure 30 : Deuxième itération de Bellman ....................................................................................... 32
Figure 31 : Initialisation de Floyd-Warshall ...................................................................................... 32
Figure 32 : Première itération de Floyd-Warshall .............................................................................. 33
Figure 33 : Deuxième itération de Floyd-Warshall ............................................................................ 33
Figure 34 : Troisième itération de Floyd-Warshall ............................................................................ 33
Figure 35 : Fin de Floyd-Warshall ..................................................................................................... 33
Figure 36 : Initialisation de A étoile ................................................................................................... 34
Figure 37 : Liste d’attente de la première itération de A étoile .......................................................... 35
Figure 38 : Liste d’attente de la deuxième itération de A étoile ........................................................ 35
Figure 39 : Liste d’attente de la dernière itération de A étoile ........................................................... 35
Figure 40 : Architecture où l’application client fait office de terminal.............................................. 36
Figure 41 : Limitation du graphe ....................................................................................................... 38
Figure 42 : Contraction du graphe ..................................................................................................... 39
Figure 43 : Architecture permettant de limiter les problèmes de connexion réseau .......................... 40
Figure 44 : Calculs itératifs ................................................................................................................ 41
Figure 45 : Illustration d’une carte constituée de tuiles ..................................................................... 43
v
Liste des figures
Figure 46 : Diagramme de séquence des fonctions du web service................................................... 44

Figure 47 : Environnement de développement du Web service ......................................................... 45
Figure 48 : Utilisation du Web service avec un explorateur internet ................................................. 46
Figure 49 : Environnement de développement de l’application cliente............................................. 47
Figure 50 : Interface de l’application ................................................................................................. 48
Figure 51 : Réseau routier de Clermont-Ferrand et ces banlieues ..................................................... 49
Figure 52 : Graphe représentant le réseau routier de Clermont-Ferrand et ses banlieues ................. 49
Figure 53 : Itinéraire associé à l’instance 2 effectué par un calcul itératif ........................................ 52
Figure 54 : Itinéraire associé à l’instance 10 effectué par un calcul itératif ...................................... 52
Figure 55 : Itinéraire associé à l’instance 20 effectué par un calcul itératif ...................................... 53
Figure 56 : Arbre de probabilité sur trois intersections pour 1% ....................................................... 55
Figure 57 : Arbre de probabilité sur trois intersections pour 10% ..................................................... 55
Figure 58 : Allongement moyen d’un itinéraire par une erreur ......................................................... 56
Figure 59 : Solution d’un problème de HVRP ................................................................................... 60
Figure 60 : Fonction de mapping du HVRP ...................................................................................... 63
Figure 61 : Schéma général de la méthode ........................................................................................ 63
Figure 62 : Ajout de solutions (diversification) ................................................................................. 64
Figure 63 : Etape d’intensification ..................................................................................................... 65
Figure 64 : Première itération du Split pour HVRP ........................................................................... 66
Figure 65 : Deuxième itération du Split pour HVRP ......................................................................... 66
Figure 66 : Troisième itération du Split pour HVRP ......................................................................... 67
Figure 67 : Fin du Split pour HVRP et solution associée .................................................................. 67
Figure 68 : Solution optimale de l’exemple d’HVRP ........................................................................ 68
Figure 69 : Données de l’exemple illustrant l’algorithme de génération de solutions pour HVRP .. 71
Figure 70 : Déroulement de l’algorithme split sur le tour géant initial.............................................. 72
Figure 71 : Première itération de l’algorithme de génération de solution pour HVRP ..................... 72
Figure 72 : Deuxième itération de l’algorithme de génération de solution pour HVRP ................... 72
Figure 73 : Solution de l’heuristique de génération de solutions ....................................................... 72
Figure 74 : Première étape de l’algorithme de Zhang [Zha05] .......................................................... 75
Figure 75 : Deuxième étape de l’algorithme de Zhang [Zha05] ........................................................ 75
Figure 76 : Dernière étape de l’algorithme de Zhang [Zha05] .......................................................... 75
Figure 77 : Principe du Path-Relinking.............................................................................................. 76
Figure 78 : Tours géants générés par l’algorithme du Path-Relinking............................................... 76
Figure 79 : Mouvement d'insertion .................................................................................................... 78
Figure 80 : Mouvement 4_opt intra-tournée ...................................................................................... 78
Figure 81 : Mouvement 4_opt inter-tournée ...................................................................................... 78
Figure 82 : Paramètres de l’algorithme pour le HVRP ...................................................................... 79
Figure 83 : Réseau routier de l’instance de HVRP sur Clermont-Ferrand ........................................ 82
Figure 84 : Répartition des clients de l’instance de HVRP sur Clermont-Ferrand ............................ 83
Figure 85 : Première tournée de la solution associée à l’instance de Clermont-Ferrand ................... 85
Figure 86 : Deuxième tournée de la solution associée à l’instance de Clermont-Ferrand ................. 85
Figure 87 : Cinquième tournée de la solution associée à l’instance de Clermont-Ferrand ................ 86
vi
Liste des tableaux
Tableau 1 : Tableau de comparaison de puissance ............................................................................. 22
Tableau 2 : Résultats du VRP sur les instances de Christofides ........................................................ 23
Tableau 3 : Comparaison des différents systèmes de cartographies .................................................. 42
Tableau 4 : Instances et résultats de référence ................................................................................... 51
Tableau 5 : Bilan des résultats............................................................................................................ 54
Tableau 6: Méthodes publiées utilisant les instances de Golden et al. référencées par [Pri09] ......... 62
Tableau 7 : Demandes des clients du tour géant de l’exemple du Split ............................................. 65
Tableau 8 : Liste des véhicules disponibles de l’exemple du Split .................................................... 65
Tableau 9 : Demandes des clients de l’exemple de génération de solutions ...................................... 71
Tableau 10 : Liste des véhicules disponibles de l’exemple de génération de solutions..................... 71
Tableau 11 : Donnée de l’exemple de calcul de distance de Zhang ................................................... 74
Tableau 12 : Performance des processeurs......................................................................................... 80
Tableau 13 : Résultats du HVRP sur les instances de Golden ........................................................... 81
Tableau 14 : Liste des tournées d’une solution sur l’instance de Clermont-Ferrand ......................... 84
vii
Liste des algorithmes
Algorithme 1 : 4-plus proches voisins .......................................................................................... 14
Algorithme 2 : Séparation d’un tour géant (Prins 2004)1 ............................................................ 18
Algorithme 3 : 2-opt intra tournée (Recherche locale)................................................................. 19
Algorithme 4 : Recherche locale de type 2-opt inter tournées ..................................................... 21
Algorithme 5 : Split pour HVRP .................................................................................................. 70
Algorithme 6 : Distance de Zhang ............................................................................................... 74
Algorithme 7 : Recherche locale pour HVRP .............................................................................. 77
viii
Introduction
La recherche opérationnelle est un domaine mêlant l'informatique et les mathématiques. L'objectif de
ce domaine est de développer des méthodes permettant de choisir parmi un nombre important de
possibilités, la meilleure solution à un problème donné.
Les problèmes de recherche opérationnelle que nous allons traiter tout au long de ce rapport sont des
problèmes de tournées de véhicules. Ils consistent à organiser de façon optimale les tournées d'une flotte
de véhicules afin de livrer une liste de clients. La combinatoire des solutions associées à ces problèmes est
tellement importante qu’il est difficile de déterminer de façon exacte la solution optimale dans des temps
acceptables. De nombreuses méthodes de résolution de ces problèmes sont donc approchées afin d’être
exécutées en un minimum de temps. C’est à ces méthodes que nous nous intéressons dans ce rapport.
D’autre part, les nouvelles technologies mobiles (via la téléphonie mobile par exemple) envahissent
notre quotidien. On peut penser en particulier aux smartphones et à leurs applications dialoguant avec des
services en ligne comme la météo.
L’objectif de ce stage est de réfléchir sur l’adaptation des méthodes du domaine de la recherche
opérationnelle dans un environnement mobile. Dans ce contexte, nous nous sommes plus particulièrement
intéressés aux problèmes de tournées de véhicules en zone urbaine avec pour objectif de développer des
méthodes dynamiques et réactives aux contraintes du développement mobile.
Le rapport de stage est structuré en trois chapitres.

Le premier chapitre concerne la présentation des problèmes de tournées de véhicules et des méthodes
approchées de type métaheuristique. Ce chapitre contient une présentation des différentes méthodes de
résolution du VRP en détaillant plus particulièrement comment concevoir une métaheuristique GRASP/ELS.
Une telle métaheuristique a été implémentée et comparée aux résultats établis en 2004 par C. Prins dont la
méthode proposée est considérée comme une référence dans le domaine.
Le deuxième chapitre porte sur le problème de cheminement en milieu urbain. Ce problème illustre
parfaitement les contraintes liées au développement mobile et sa résolution est de plus nécessaire pour
aborder les problèmes de tournées de véhicules sur des données routières. Nous nous sommes
particulièrement intéressés dans ce chapitre au cas du cheminement de piétons afin d’illustrer nos résultats
sur une architecture constituée d’une application Android et d’un service web. Ce chapitre contient une
présentation du problème de plus court chemin dans des graphes ainsi que de ses différentes méthodes de
résolution. Il contient également la présentation de l’algorithme que l’on a développé afin de pallier aux
contraintes urbaines et mobiles. On présente également les principes de l’application mobile et du service
web développés. On termine ce chapitre par une analyse des résultats de notre algorithme sur des
instances concrètes basées sur le réseau routier de Clermont-Ferrand.
Le troisième chapitre aborde le problème de tournées de véhicules dans le cas d’une flotte hétérogène.
Ce chapitre consiste à élaborer une méthode de résolution de ce problème en appliquant les contraintes
liées à l’environnement mises en évidence au chapitre précédent. Ce chapitre reprend le travail effectué sur
la conception de méthodes approchées du chapitre 1 et les résultats sur le problème de cheminement du
chapitre 2. Il contient la présentation du problème de tournées de véhicules avec une flotte hétérogène
ainsi que de ses différentes méthodes de résolution. Il présente également le principe de la méthode de
résolution développée dont les résultats sont comparés avec les résultats des différents articles référents du
1
Introduction
sujet. Ce chapitre conclut sur l’application de la méthode à un exemple issu du réseau routier de Clermont-
Ferrand.
Ce stage m'a permis de découvrir le monde de la recherche opérationnelle avec une orientation très
appliquée puisque les objectifs ont tous consisté à fournir des méthodes efficaces sur des cas les plus
réalistes possibles. C’est pourquoi, ce rapport met en évidence : d’une part l’aspect ingénierie, à travers le
développement d’une application mobile et d’un service web, et d’autre part l’aspect recherche à travers la
conception de méthodes de résolution pour différents problèmes de recherche opérationnelle.
2
Chapitre 1 : Le problème de base en tournées de véhicules : le VRP
CHAPITRE 1
Le problème de base en tournées de
véhicules : le VRP
L’objectif de ce chapitre est d’appréhender les problèmes de tournées de véhicules et

certaines méthodes de leur résolution. Pour ce faire, on s’appuie sur le VRP (vehicle routing
problem) qui est une extension du problème du voyageur de commerce (travelling salesman
problem) et que l’on résout par une méthode approchée de type métaheuristique.
Ce chapitre est structuré en 5 parties. Dans la première partie, on présente le VRP et les
différentes méthodes existantes dans la littérature pour le résoudre. Dans un deuxième
temps, on s’intéresse à la conception d’une méthode approchée de type métaheuristique.
Pour ensuite, dans la troisième partie, aborder le principe général d’une métaheuristique
GRASP/ELS. On présente par la suite la métaheuristique développée durant la première
partie du stage. Enfin, on présente les résultats obtenus qui sont comparés à ceux de Prins
*Prin04+.
1. Problème du type VRP

1.1 Présentation du VRP
Les problèmes de tournées de véhicules se divisent en deux grandes catégories : les problèmes de
tournées sur arcs et les problèmes de tournées sur nœuds. Traditionnellement, on considère que le
VRP est le problème de base sur les problèmes de tournées sur nœuds. Les problèmes de type VRP
(Vehicle Routing Problem) *Chr79+ font partie des problèmes NP-difficiles, c’est-à-dire qu'a priori (sauf
si P=NP) il est impossible de trouver la solution de coût minimal en temps polynomial *Pap77+. Le VRP
consiste en un certain nombre de clients distants les uns des autres et qui ont chacun une demande
s’exprimant par une quantité entière. On dispose, pour satisfaire les demandes, d’une flotte de
véhicules homogènes qui ont une certaine capacité de chargement limitant le nombre de clients
qu’ils peuvent servir en un seul passage et d’un dépôt. Chaque tournée commence et se termine au
dépôt. L’objectif consiste à déterminer un ensemble de tournées permettant de desservir tous les
clients et minimisant la distance parcourue par les véhicules.
Définition :
Le VRP est définit comme suit : on considère un graphe orienté complet (𝐺 = (𝑉, 𝐸)) où 𝑉 =
*0, . . , 𝑛+ est l’ensemble des sommets et 𝐸 = *(𝑖, 𝑗) | ∀𝑖, 𝑗 𝜖 𝑉, 𝑖 ≠ 𝑗+ est l’ensemble des arcs. Les
sommets regroupent le dépôt (sommet 0) et les clients (sommets 1 à 𝑛). Chaque arc (𝑖, 𝑗) représente
le plus court chemin pour aller de 𝑖 à 𝑗. On lui associe un coût non-négatif qui représente la distance
3
(ou la durée) de parcours pour se rendre de 𝑖 à 𝑗. Un ensemble de K véhicules (numérotés de 1 à 𝐾)

homogènes sont initialement positionnés sur le dépôt. Chaque véhicule k a une capacité 𝑄. Chaque
client i possède une demande de livraison 𝐷𝑖 . On considère que ∑𝑖=𝑉\*0+ 𝐷𝑖 ≤ 𝐾 ∗ 𝑄, pour garantir
que la capacité totale est suffisante. Cette condition n’est cependant pas suffisante pour assurer la
réalisabilité. On cherche au plus 𝐾 tournées de véhicules sur le graphe qui satisfont les propriétés
suivantes :
- (c1) une tournée commence et se termine au dépôt ;
- (c2) un sommet est visité une et une seule fois ;
- (c3) la charge d’un véhicule ne peut pas dépasser sa capacité ;
- (c4) toutes les demandes doivent être satisfaites ;
- (c5) la somme des coûts de transport est minimale.
Modélisation mathématique :
Fisher et Jaikumar *Fis81+ ont formulé le problème sous la forme d’un programme linéaire :
𝐾
𝑘
Min ∶ z = ∑ ∑ 𝐶𝑖𝑗 𝑥𝑖𝑗 (1)
(𝑖,𝑗)∈𝐸 𝑘=1
Sous les contraintes :
∑ di yik ≤ Q ∀ k = 1, … , K (2)
i∈V
K
∑ yik =1 ∀ i ∈ V\*0+ (3)

k=1
N
∑ y0k ≤K (4)
k=1
∑ xijk = yjk ∀ j ∈ (1, . . , n) , k ∈ 1, … , K (5)

i∈V
∑ xijk = yik ∀ i ∈ (1, . . , n) , k ∈ 1, … , K (6)

j∈V
∀ S ⊂ V; 2 ≤ |S| ≤ n − 2,
∑ xijk ≤ |S| − 1 (7)
k = 1, … , K
i,j∈ S
xijk ∈ *0,1+ ∀ i, j ∈ V ; i ≠ j , k = 1, … , K (8)
yik ∈ *0,1+ ∀ i ∈ V , k = 1, … , K (9)
où
𝑉 : l’ensemble des sommets constitué des clients et du dépôt.
𝐸 : l’ensemble des arcs.
𝐶𝑖𝑗 : le coût de l’arc (𝑖, 𝑗).
𝐷𝑖 : la demande du client 𝑖.
𝐾 : le nombre de véhicules.
𝑄 : la capacité des véhicules.
𝑘
𝑥𝑖𝑗 : indique si l’arc (𝑖, 𝑗) fait partie de la tournée 𝑘.
𝑘
𝑦𝑖 : égale à 1 si le véhicule k effectue le service chez le client i. L’indice i=0 correspond au
4
dépôt.
Dans ce modèle, la fonction objectif est de minimiser la somme des coûts de transport. Les
contraintes (2) vérifient que la capacité de chargement de chaque véhicule est bien respectée. Les
contraintes (3) permettent de vérifier que chaque client est desservi. Les contraintes (4) permettent
de vérifier que l’on construit au plus 𝐾 tournées. Les contraintes (5) et (6) assurent la cohérence entre
la visite d’un client par un véhicule 𝑘 et l’appartenance de ce client à la tournée 𝑘. Les contraintes (7)
ont pour but d’éviter la formation de sous-tours au sein des tournées.
Modélisation sous forme de graphe :
On peut modéliser une solution du problème de type VRP par un graphe (voir Figure 1) dans
lequel le dépôt et les clients sont représentés chacun par un nœud. Chaque arc entre deux sommets
symbolise l’ordre de passage du véhicule et la distance qui parcourue.
Figure 1 : Solution d’un problème de VRP
1.2 Etude sur les méthodes de résolution existantes

Les méthodes de résolution des problèmes de VRP peuvent être exactes ou approchées, c’est-à-
dire qu’elles peuvent ou non garantir l’optimalité de la solution obtenue *Tot02, Ren12+.
Méthodes exactes :
Les méthodes de résolution exactes ne sont, en pratique, utilisées que pour les instances de
petite taille (environ 50 clients) *Tot02+ car le temps de calcul pour ce genre de méthode est
exponentiel en fonction du nombre de clients considérés et de ce fait, les instances de taille moyenne
(de 100 à 200 clients) ont des temps de résolution peu raisonnables.
Ces méthodes sont divisées en trois catégories :
- les méthodes de branchement (procédure par évaluation et séparation progressive) qui
ont pour principe de diviser progressivement l’espace des solutions du problème créant
ainsi un arbre de sous problèmes dont les feuilles sont résolubles rapidement par des
méthodes de programmation linéaire. (Ex : branch-and-bound *Lap87+) ;
- les méthodes de programmation dynamique qui sont basés sur une logique de résolution
ascendante et qui ont pour principe d’élaborer une série de sous-problèmes. Ces
méthodes ont été utilisées la première fois pour un problème de type VRP par Eilon et al.
*Eil71+ en 1971 ;
- les méthodes basées sur la programmation linéaire en nombres entiers qui comprend par
5
exemple les méthodes de Génération de colonnes proposées par Dantzig et Wolfe

*Dan60+.Le mécanisme de la génération de colonnes consiste alors à générer, au sein d'un
algorithme à plusieurs étapes, les variables qui sont susceptibles d'améliorer la solution
courante. L'efficacité de la méthode est très dépendante du mécanisme utilisé pour
générer des colonnes.
Méthodes approchées :
Les méthodes de résolution approchées ne garantissent pas d’avoir une solution optimale,
cependant ce sont des outils permettant d’obtenir rapidement une solution de très bonne qualité,
elles sont donc particulièrement biens adaptées pour les instances de grandes tailles (plus de 200
clients). La résolution de ce type d'instance par une méthode exacte est généralement impossible.
On peut distinguer deux catégories de méthodes approchées :
- les heuristiques qui sont des algorithmes dédiés à un unique problème. En particulier,
celles dédiées au VRP sont souvent issues de celles du TSP. Parmi les heuristiques souvent
utilisées pour le VRP, on peut distinguer les heuristiques de construction qui consistent à
élaborer la solution étape par étape sans remettre en question l’étape précédente (ex :
méthode d’insertion *Chr79+) . Les heuristiques d’amélioration consistent à partir d’une
solution existante et à explorer les voisinages pour l’améliorer. Les heuristiques à deux
phases consistent à séparer la recherche de l’ordre dans lequel on dessert les clients et
l’attribution des clients aux différentes tournées (ex : The Fisher and Jaikumar algorithm
*Fis81+) ;
- les métaheuristiques qui sont des méthodes plus générales et qui peuvent s’appliquer à
une grande variété de problèmes. Ce sont des schémas généraux qui peuvent incorporer
une ou plusieurs heuristiques. Les métaheuristiques sont constituées généralement de
deux étapes principales, une étape d’initialisation qui permet d’obtenir une solution
initiale valide et une étape d’amélioration de cette solution.
Les métaheuristiques peuvent se distinguer en trois catégories (Classification par Gendreau et al.
*Gen02+) :
- les méthodes de recherche voisinage qui consistent à améliorer la solution par des
déplacements itératifs en choisissant une nouvelle solution parmi le voisinage considéré.
(ex : Le recuit simulé *Osm93+) ;
- les méthodes de recherche à base de population qui consistent à générer plusieurs
solutions et à les améliorer en parallèle. (ex : l’algorithme génétique (GA) *Prin04+) ;
- les méthodes de mécanisme d’apprentissage qui basent l’évaluation d’une solution sur
les informations recueillies au fur à mesure de l’algorithme. (ex : l’algorithme de colonie
de fourmis *Col91+).
Les métaheuristiques développées sont souvent des hybridations entre ces différentes catégories
comme l’illustre la métaheuristique détaillée dans la section 3 de ce chapitre.
2. Conception d’une métaheuristique basée sur un codage indirect

2.1 Codage indirect des solutions
Lorsqu’on cherche une solution la plus proche à la solution optimale d’un problème
6
d’optimisation, il n’est pas toujours facile de travailler directement dans l’espace des solutions (qui
correspond à l’ensemble des graphes orientés modélisant une solution dans le cas des problèmes de
tournées de véhicules). C’est pourquoi, depuis les années 80, dans un premiers temps pour les
problèmes d’ordonnancement, de nombreux articles ont mis en évidence l’importance d’une
représentation indirecte de la solution. Plus particulièrement, on trouve dans les travaux de Cheng et
al. *Che96+, une définition générale (Figure 2), applicable en particulier à notre problème de tournées
de véhicules. La Figure 2 montre comment doit être mise en place un codage indirect d’une solution
pour être utilisable. Un tel schéma consiste en deux espaces : espace de codage (indirect) et espace
des solutions (i.e. codage direct). Chaque élément de l’espace de codage choisi doit, après avoir été
appliqué par une fonction de « mapping » simple, correspondre à un élément dans celui des
solutions qui respectent les contraintes. D’après *Che96+, il existe trois types de fonctions de
« mapping » :
- Les fonctions de type « 1-to-1 » où un et un seul élément de l’espace de codage est
associé à un et un seul élément de l’espace des solutions
- Les fonctions de type « n-to-1 » où plusieurs éléments de l’espace de codage peuvent
être reliés à un seul élément de l’espace des solutions.
- Les fonctions de type « 1-to-n » où un élément de l’espace de codage peut être relié à
plusieurs éléments de l’espace des solutions.
1-to-n mapping
n-to-1 mapping
1-to-1 mapping
Espace de codage Espace des solutions
Figure 2 : Classification des fonctions de mapping d'après (Cheng et al., 1996)
Il est naturellement plus confortable de trouver une fonction de type « 1-to-1 » pour établir une
correspondance entre l’espace de codage et l’espace des solutions, cependant dans la pratique, il est
très difficile de trouver une fonction de « mapping » du type « 1-to-1 ». Par exemple, la fonction de
« mapping » associée au vecteur de Bierwirth *Bie95+ qui est une représentation indirecte classique
d’une solution d’un problème d’ordonnancement est du type « n-to-1 ».
Dans le cas des problèmes de tournée de véhicule, la première méthode se basant sur un codage
indirect fut une méthode de type « route-first, cluster-second » proposée par Beasley dans un article
de 1983 *Bea83+ dans laquelle apparaît la méthode Split, détaillée dans la section 3.2 de ce chapitre,
qui permet de passer de l’espace de codage à l’espace des solutions.
L'application de codage indirect pour les problèmes de type VRP se base le plus souvent sur la
proposition initiale de Beasley. Depuis les années 2001 ce type de codage a connu un fort
engouement et a été inséré dans des techniques globales d'optimisation *Lac 01+. Duhamel et al.
7
*Duh12+ ont réalisé un état de l'art dans lequel 41 articles ont été référencés (Figure 4).
Figure 3 : Liste des publications avec un codage indirect selon Duhamel et al., *Duh12+
2.2 Critères d’évaluation d’une métaheuristique

En considérant un bon nombre de publications, Duhamel et al. *Duh11+ ont mis en évidence les
points clés pour élaborer une métaheuristique efficace :
- Une représentation indirecte de la solution plus compacte comme une séquence de
nœuds ou de taches à effectuer par exemple ;
- La fonction de « mapping » qui permet d’associer une solution de l’espace de codage
indirecte choisie à l’espace des solutions ;
- Une recherché locale effectuant des améliorations à une solution par exploration de son
voisinage ;
- Un processus de diversification afin d’éviter de rester cloitrer à certains minimums
locaux ;
- Une heuristique de construction d’une bonne solution initiale.
8
Figure 4 : Schéma d’une heuristique efficace selon (Duhamel et al., 2011 )
Comme le montre la Figure 4, le point clef d’une telle métaheuristique est d’alterner entre deux
espaces. L’espace de codage qui est utilisé pour le processus de diversification et l’espace des
solutions qui est utilisé pour améliorer la solution par une recherche locale.
Dans la majorité des méthodes de résolution des problèmes de tournées de véhicules on peut
utiliser comme représentation indirecte un tour géant qui donne un ordre dans lequel doivent être
desservis tous les clients. Un tour géant est une solution du problème de voyageur de commerce
(TSP) sur une instance constituée du même graphe. On peut alors identifier une telle représentation à
une solution de notre problème en découpant ce tour géant de la façon la plus efficace possible en
tenant compte des contraintes telles que la capacité de chargement des véhicules.
3. Principe d'un GRASP/ELS basé sur un codage indirect

La métaheuristique de type GRASP/ELS a été proposée la première fois par Prins en 2009,
*Prin09+. C’est une hybridation entre une heuristique probabiliste de type GRASP (greedy randomized
adaptive search procedure), mise en place par Feo et Resende en 1989, et un algorithme de
recherche locale de type ELS (evolutionary local search), initié par Wolf et Merz en 2007. Le schéma
d’optimisation exposé dans cette partie n’est pas seulement dédié au problème de tournée de
véhicules mais pourra aussi s’appliquer à des problèmes d’ordonnancement par exemple *Cha13+.
3.1 Définition d’une métaheuristique GRASP

La méthode GRASP est une métaheuristique qui permet d’explorer des zones très variées de
9
l’espace des solutions par une gestion correcte de la diversification et de l’intensification durant le
processus d'optimisation. Elle se compose de deux étapes distinctes itérées jusqu’à ce qu’un nombre
d'itérations choisi soit atteint :
- l’initialisation : consiste à générer une solution du problème. La construction de cette
solution se fait généralement par des techniques de construction gloutonne permettant
d'obtenir des solutions de qualité médiocre mais dans des temps raisonnable. Elles sont
basées dans la majorité des cas, sur une technique de plus proche voisin randomisé.
 la première étape consiste à créer une liste ordonnée des sommets à ajouter à la
solution en utilisant par exemple un critère d'éloignement par rapport au dernier
somme inséré. Dans l’exemple ci-dessous l’étape sélectionne les éléments A, B, et
C.
 la deuxième étape consiste à choisir aléatoirement un élément de la liste afin de
le rajouter au vecteur solution illustré dans l’exemple Figure 5. Dans la majorité
des cas, on utilise une probabilité 𝑃 de sélectionner un élément en position 𝑖
dans la liste et on passe à l'élément suivant si la probabilité n'est pas réalisée.
Figure 5 : Initialisation de la méthode GRASP
- La recherche locale consiste, une fois la solution obtenue par l’initialisation, à améliorer
cette solution en recherchant la meilleure des solutions parmi celles de son voisinage.
Figure 6 : Recherche locale de la méthode GRASP
10
3.2 Définition d’une métaheuristique ELS

ELS est un algorithme de recherche locale évolutionnaire qui permet d'explorer les minimums
locaux adjacents à la solution courante (explorer plusieurs bassins d’attraction). Elle consiste en deux
étapes réitérées jusqu’à ce qu’un nombre d’itérations maximal soit atteint :
- Une étape de mutation qui consiste à transformer très légèrement la solution courante
afin de donner plusieurs solutions fils : dans l’exemple ci-dessous la solution de départ
donne trois solutions fils en sélectionnant, à trois reprises, aléatoirement deux éléments
et en les inversant.
Figure 7 : Mutation d’un algorithme ELS
- Une étape de recherche locale qui consiste à améliorer chaque solution fils par un
processus de recherche locale. La meilleure solution obtenue est ensuite retenue pour
être la solution de départ à l’étape suivante.
Figure 8: Recherche locale d’un algorithme ELS
3.3 La méthode hybride GRASP/ELS

Une méthode hybride regroupant des métaheuristiques de types GRASP et ELS profite des points
forts de chacune des d’entre elles ; en effet, une métaheuristique de type GRASP permet de
diversifier l’espace de recherche des solutions en repartant à chaque itération d’une nouvelle solution
générée par l’étape d’initialisation. Quant à ELS, il permet d’intensifier la recherche locale de façon
efficace en explorant un maximum de solutions grâce à sa méthode de mutation. On peut voir sur le
schéma Figure 9 comment s’adjacent les heuristiques pour être efficaces.
11
Figure 9 : Schéma d’une métaheuristique de type GRASP/ELS
4. GRASP/ELS proposé
Dans cette partie est présentée l’application du GRASP/ELS au problème de type VRP. Le
GRASP/ELS proposé dans cette partie se base sur un principe de codage indirect, et suit le schéma
présenté dans la section 3.3.Choix de l’espace de codage
La métaheuristique proposée se base sur une représentation indirecte de la solution. La
représentation indirecte choisie pour notre solution est un vecteur de clients nommé « tour géant » :
le tour géant est en fait une solution du TSP.
La fonction de « mapping » associée est de type « n-to-1» et a été définie en 2001 par *Lac 01+.
Elle est couramment nommée SPLIT dans la littérature, son principe est détaillé dans la section 4.3. La
fonction qui permet de passer de l’espace des solutions à l’espace de codage est une fonction de
concaténation des différentes tournées d’une solution.
Figure 10 : Mise en correspondance de l’espace des solutions et de celui des tours géants.
12
4.1 Schéma général de la méthode implémentée

La Figure 11 présente le principe d’exécution du GRASP/ELS :
Figure 11 : Schéma du GRASP/ELS proposé
Le GRASP/ELS que nous proposons comprend deux étapes, à savoir :

- L’étape d’initialisation se fait par une méthode de génération de solution consistant à
générer un élément (un tour géant) de l’espace de codage indirect par une méthode de
type plus proches voisins puis à lui appliquer un algorithme de Split afin d’obtenir un
élément (une solution de VRP) de l’espace des solutions ;
- La recherche locale est une hybridation de plusieurs opérateurs basés sur des
mouvements de type 2-opt qui s’effectue dans l’espace des solutions. Un mouvement 2-
opt correspond à la suppression de deux arcs et à l’ajout de deux nouveaux dans les
tournées d’une solution ;
- La méthode de mutation s’effectue par interversion entre deux éléments d’un tour géant,
donc s’effectue dans l’espace de codage après la concaténation d’un élément de l’espace
des solutions.
4.2 Etape d’initialisation : la méthode des plus proches voisins

La première étape consiste à générer un tour géant. Pour se faire, on choisit un algorithme de
plus proches voisins (Nearest Neighbors). L’idée de cet algorithme est de remplir le vecteur qui
représente le tour géant élément par élément. Le premier élément du tour géant est un des plus
proches voisins du dépôt, puis chaque nouvel élément est un des plus proches voisins du précédent.
Une version alternative de cette méthode consiste à sélectionner non pas les plus proches voisins en
termes de distance mais les voisins présentant le ratio le plus intéressant entre la charge du véhicule
et la distance.
Cette méthode présentée par la Figure 12 ci-dessous est un algorithme (Algorithme 1) itératif
randomisé dans le sens où il est connu dans le domaine qu’il est possible de randomiser le choix du
voisin dans une liste de sommets voisins qu’on limite à un certain nombre de sommets (souvent 4 ou
13
5).
Figure 12 : Méthode des plus proches voisins
Algorithme 1 : 4-plus proches voisins

Sortie : un tour géant
Début
Etablir la liste des clients ordonnée du plus proche du dépôt au plus
éloigné.
Etablir, pour chaque sommet, la liste ordonnée des clients du plus proche
au plus éloigné du sommet.
Choisir de façon aléatoire comme premier élément du tour géant un des 4

clients les plus proches du dépôt.
Considérer le client choisi comme traité
Tant que tous les clients ne sont pas traités faire
Choisir de façon aléatoire un des 4 clients non-traités les plus

proches du dernier client traité comme élément suivant du tour géant
Considérer le client choisi comme traité
Fin tant que

Fin
4.3 L’algorithme Split

Une fois le tour géant construit, on cherche à identifier les différentes tournées afin d’obtenir un
élément de l’espace des solutions. Pour se faire, on effectue un algorithme de Split, c’est-à-dire un
algorithme de séparation de tour géant qui consiste à trouver la meilleure façon de découper un tour
géant (celle qui donne le coût minimum) tout en respectant la capacité du véhicule.
Le principe de cet algorithme est expliqué à travers un exemple illustré Figure 13 issu de l’article
de Prins *Pri04+ :
14
Figure 13 : Exemple d’un problème avec clients déjà ordonnancés
Voici les données du problème montré sur l’exemple :

- Un dépôt symbolisé par le rectangle bleu ;
- 5 clients à livrer représentés par les nœuds A, B, C, D, E ;
- Chaque client a une demande représentée par l’encadré bleu sous son nœud ;
- Les flèches symbolisent l’ordre dans lequel doit être effectué la livraison (données du
tour géant) ;
- Les distances entres chaque nœud sont écrites sur les arcs les reliant ;
- La capacité de chaque camion est de 10.
L’algorithme du Split est composé de deux étapes:

- une étape de construction du graphe
- une étape du calcul du plus court chemin
L’étape de construction du graphe :
Le graphe à construire est constitué de :
- Un nœud point de départ sous forme rectangulaire ;
- n nœuds alignés horizontalement où n est le nombre total de clients ;
- Un ensemble d’arc où chaque arc représente une tournée avec son coût associé.
L’ensemble des arcs est alors construit de la façon suivante :
Chaque arc du point de départ vers un nœud 𝑖 représente une tournée regroupant les clients du
tour géant du premier au 𝑖 è𝑚𝑒 (les tournées qui ne respectent pas la capacité du camion ne sont pas
prisent en compte) :
15
Figure 14 : Exemple de tournées incluant le premier client
Chaque arc (𝑖, 𝑗) représente une tournée du client 𝑖+1 au client 𝑗 du tour géant.
Figure 15 : Exemple de tournée n’incluant pas le premier client (A)
Cette étape donne le schéma suivant :
Figure 16 : Schéma de l’ensemble des tournées possibles
16
L’étape du calcul du plus court chemin :

Une fois le graphe établie il suffit de calculer le plus court chemin pour aller du dépôt jusqu’au dernier
nœud pour obtenir l’ensemble de tournées de coût optimal. Pour se faire, on traite les sommets dans
l’ordre de leur visite et on obtient ainsi une solution en un seul passage :
Figure 17 : Calcul du plus court chemin
Algorithme de séparation d’un tour géant *Prin04+ :

Données :
- 𝑞 : vecteur de taille n où pour tout i de 1 à n, 𝑞𝑖 est la demande correspondant au client i.
- 𝑑 : vecteur de taille n où pour tout i de 1 à n, 𝑑𝑖 est le coût fixe de livraison du client i.
- 𝑐 : matrice de taille (n+1,n+1) où pour tout i,j de 0 à n, 𝑐𝑖𝑗 correspond au coût de l’arc (i,j)
où l’indice 0 correspond au dépôt et l’indice k de 1 à n correspond au client k.
- 𝑊 : capacité de chargement d’un véhicule
- 𝐿 : coût maximum d’une tournée
Variables :
- n : nombre de clients
- 𝑉 : vecteur de taille n+1 construit durant l’algorithme tel que 𝑉0 = 0 et pour tout i de 1 à
n, 𝑉𝑖 est le coût minimum pour livrer le client en 𝑖 è𝑚𝑒 position du tour géant en finissant
une tournée par lui.
- charge : variable permettant de vérifier qu’une tournée respecte la capacité d’un
véhicule.
- coût : variable permettant d’évaluer le coût de la tournée courante.
- 𝑃 : vecteur de taille n construit durant l’algorithme tel que et pour tout i de 1 à n,
l’élément d’indice 𝑃𝑖 + 1 du tour géant correspond au début de la tournée à laquelle
appartient le client d’indice i du tour géant.
17
Algorithme 2 : séparation d’un tour géant (Prins 2004) :

Sortie : P
Début
𝑉0 = 0
Pour i de 1 à n faire 𝑉𝑖 = +∞ Fin pour
Pour i de 1 à n faire
charge = 0, coût = 0, j = i
Fin pour
Faire
charge = charge + 𝑞𝑇𝑗
Si i = j alors
coût = 𝑐0𝑇𝑗 + 𝑑 𝑇𝑗 + 𝑐𝑇𝑗 0
sinon
coût = coût - 𝑐𝑇𝑗−10 + 𝑐𝑇𝑗−1𝑇𝑗 + 𝑑 𝑇𝑗 + 𝑐𝑇𝑗0
Fin si
si ( charge≤ 𝑊 ) et ( coût ≤ 𝐿 ) alors
si 𝑉𝑖−1 + coût < 𝑉𝑗 alors
𝑉𝑗 =𝑉𝑖−1 + coût
𝑃𝑗 = i-1
Fin si
j = j + 1
Fin si
jusqu’à ( j > n ) ou ( charge > 𝑊 ) ou ( coût > 𝐿 )
Fin pour
Fin
4.4 La mutation
L’originalité de l’approche proposée réside dans la définition d’un opérateur de mutation sur un
tour géant. Cette étape consiste alors à générer plusieurs tours géants par permutation de deux
éléments choisis aléatoirement dans le tour (mouvement swap randomisé).
Figure 18 : Etape de mutation de l’algorithme GRASP/ELS
18
4.5 La recherche locale

Un autre point clé de ce type d’algorithme est la recherche locale qui doit être très efficace et peu
couteuse en temps. Pour le VRP, les mouvements les plus efficaces ont fait l’objet de plusieurs
publications et sont relativement bien connues. Ils comprennent en particulier des échanges d’arcs,
des mouvements 2-opt intra-tournée et 2-opt inter-tournées.
Opérateur 2-opt intra-tournée :
L’opérateur consiste en un mouvement 2-opt intra-tournée et répété jusqu’à ce que la tournée ne
soit plus améliorable par ce mouvement. Le mouvement supprime deux arcs et les remplace par deux
nouveaux comme illustré sur la figure ci-dessous. Il faut noter que le fait de procéder à ce
changement entraine un changement de sens d’une partie de la tournée. L’opérateur est effectué
pour chaque tournée d’une solution.
Figure 19 : Mouvement de type 2-opt intra-tournée
Sur la Figure 19, l’arc de A à B et L’arc de E à F ont été remplacés par un arc de A à E et un de B à F
entrainant l’inversion du sens de 3 arcs de la tournée.
Pour être sûr que la tournée n’est plus améliorable par un tel mouvement, on effectue une
double boucle pour parcourir tous les échanges d’arcs possibles et on réitère l’opération jusqu’à ce
qu’aucune amélioration de la tournée ne soit trouvable (voir Algorithme 3).
Algorithme 3 : 2-opt intra tournée (Recherche locale)

Sortie : solution améliorée
Début
Tant que ( fini = = faux )
fini = vrai
Pour chaque combinaison de deux arcs de la tournée faire
Si le mouvement 2_opt améliore le coût de la tournée alors
fini = faux
effectuer le mouvement 2_opt entre les deux arcs
Fin si
Fin pour
Fin tant que
Fin
19
L’opérateur 2-opt inter-tournées :

L’opérateur consiste en un mouvement 2-opt inter-tournées appliqué à deux tournées et répété
jusqu’à ce que le coût total de ces tournées ne soit plus améliorable par ce mouvement. Le
mouvement supprime un arc de chaque tournée et les remplace par deux nouveaux comme illustré
sur la Figure 20 ci-dessous : ceci revient à échanger la fin des deux tournées. L’opérateur est appliqué
à deux tournées reçues en paramètre de la fonction.
Figure 20 : Mouvement de type 2-opt inter-tournées
Sur la Figure 20, l’arc de A à B et L’arc de E à F ont été remplacés par un arc de A à F et un de E à B.
Pour être sûr que le coût total des deux tournée n’est plus améliorable par un tel mouvement, on
effectue une double boucle pour parcourir tous les échanges d’arcs possibles et on réitère l’opération
jusqu’à qu’aucune amélioration de la tournée ne soit trouvée.
Recherche locale appliquée à chaque couple de tournées du tour géant :
Description des données :

- 𝑛𝑖 : nombre de clients dans la i-ème tournée traitée.
- 𝑑 : vecteur de taille nombre de clients de l’instance tel que pour tout i de 1 à n, 𝑑𝑖 est la
demande du client i
- 𝑑𝑒𝑚𝑎𝑛𝑑𝑒𝑖 : demande totale des clients de la tournée i.
- 𝐿𝑖 : vecteur de la taille de la tournée i tel que pour tout k de 1 à 𝑛𝑖 , 𝐿𝑖𝑘 indique l’indices
du tour géant correspondant au 𝑘 è𝑚𝑒 client de la tournée i.
- 𝑊 : capacité des véhicules
Le déroulement de la recherche locale est donnée par algorithme 4.
20
Algorithme 4 : recherche locale de type 2-opt inter tournées

Sortie : solution améliorée
Début
fini = faux
Tant que fini = = faux
fini = vrai
Pour chaque client i de la tournée 1 faire
trop = faux
Pour chaque client j de la tournée 2 faire
Si fini = = vrai et trop = = faux alors
D = 0
Pour k de i+1 à n1 faire
D = D + d_(L_1k )
Fin pour
Pour k de j+1 à n2 faire
D = D – d_(L_2k )
Fin pour
Si demande_2 + D > W alors
trop = vrai
Sinon Si le coût de la solution est amélioré par le
mouvement 2_opt entre l’arc (i,i+1) de la tournée 1 et
(j,j+1) de la tournée 2 et si demande_1 – D ≤ W alors
fini = faux
Effectuer le mouvement 2-opt entre les deux arcs
Fin des boucles
Fin
5. Expérimentations numériques
Dans cette partie sont exposés les résultats obtenus, en termes de performance, de la
métaheuristique de type GRASP/ELS dont nous venons de faire la description. L’algorithme a été
implémenté c++ sous visual studio 2008 et a été testé sur les instances classiques du VRP puis les
résultats sont comparés à ceux obtenus par C. Prins en 2004 *Prin04+.
5.1 Paramètres
Pour présenter l’algorithme de type GRASP/ELS regroupant les différentes étapes présentées dans
la partie 3 de ce chapitre et établir les paramètres de façon claire on s’appuie sur le schéma Figure 21.
Les différentes étapes :
- L’étape d’initialisation se fait par une méthode de génération de solution de type plus
proches voisins (Nearest Neighbors).
- La recherche locale est constituée d’un opérateur 2-opt inter tournées et d’un opérateur
2-opt intra tournée.
- La méthode de mutation s’effectue par interversion entre deux éléments d’un tour géant.
Les différents paramètres qui ont été choisis, de façon à donner les résultats les plus proches de
la meilleure solution connue en un temps raisonnable, en effectuant des test sur les premières
instances de Christofides et al.:
- Le nombre d’itérations de la boucle GRASP α=30.
- Le nombre d’itérations de la boucle ELS β=30.
- Le nombre d’itérations de la recherche locale après l’initialisation δ1=15.
- Le nombre d’itérations de la recherche locale après la mutation δ2=10.
21
Figure 21 : Schéma de la méthode de type GRASP/ELS
5.2 Performances des ordinateurs utilisés

Pour pouvoir se comparer aux résultats de Prins *Prin04+, on a besoin d’établir la puissance de
calcul relative de l’ordinateur utilisé dans ce stage et de celui utilisé par Prins. Pour se faire, on utilise
le benchmark du site http://www.roylongbottom.org.uk. Les résultats du benchmark sur l’ordinateur
de ce stage et sur un ordinateur équivalent à celui utilisé par Prins sont illustrés dans le Tableau 1 :
Tableau de comparaison de puissance :
Tableau 1 : Tableau de comparaison de puissance
(Prins 2004) Ordinateur personnel

Ordinateur Pentium III de 1 GHz Pentium T4200 de 2 GHz
OS Windows 98 Windows 7
Language Delphi 6.0 C++
Mflops 316.67 1073.36
Facteur vitesse 1 3.4
5.3 Résultats numériques

Les tests ont été effectués sur les instances numéro 1, 2, 3, 4, 5, 11, et 12 des instances de Christofides
et al. *Chr79+, comme indiqué par la première colonne. Ces instances correspondent aux instances traitant
de problème de tournée de véhicules sans contrainte de taille maximum des tournées. La deuxième
colonne indique le nombre de clients par instance. La troisième colonne indique le coût de la meilleure
solution connue sur l’instance. La quatrième colonne donne le coût moyen de la solution obtenu par
l’algorithme génétique avec 30 000 « cross-over » de C. Prins. Le temps d’exécution de cet algorithme
figure colonne 6 et La différence de coût de cette solution par rapport à la meilleure connue est illustrée
colonne 5 par le GAP. A partir de la septième colonne, figurent les résultats de l’algorithme de ce chapitre.
Tout d’abord, en colonne 7, on a le coût moyen (sur 10 exécutions) de la solution obtenue par l’algorithme.
La huitième colonne indique le GAP de la solution obtenue par rapport à la meilleure connue. Le temps
moyen d’exécution de l’algorithme figure colonne 9 et est multiplié par un coefficient de 3.4 colonne 11
22
pour être comparé à celui de C. Prins. La colonne 10 correspond au temps moyen pour atteindre la
meilleure solution connue (0 si la meilleure solution connue n’est pas atteinte) et il est multiplié par un
coefficient de 3.4 colonne 12.
Tableau 2 : Résultats du VRP sur les instances de Christofides
Prins Algorithme proposé

Time
Time
30,000 GAP GAP Time Time Av.
Instance n BKS Time GRASP Av. Av.
crossovers % % Av. Av. St. best
best
St.
1 50 524,61 524,61 0,00 0,5 524,61 0,00 5,75 2,53 19,55 8,60
2 75 835,26 835,26 0,00 46,36 844,26 1,08 15,1 0 51,34 0
3 100 826,14 826,14 0,00 27,63 833,1 0,84 28,86 0 98,12 0
4 150 1028,42 1031,63 0,31 330,11 1050,93 2,19 73,09 0 248,51 0
5 199 1291,45 1300,23 0,68 1146,52 1343,23 4,01 135,15 0 459,51 0
11 120 1042,11 1042,11 0,00 17,85 1048,12 0,58 41,51 0 141.13 0
12 100 819,56 819,56 0,00 2,7 819,56 0,00 30,02 2,88 102,68 9,79
Moyenne 0,23 224,52 1,24 160.12
Sur les instances 1 et 12 l’algorithme proposé parvient à trouver la meilleure solution connue à
chacune de ses 10 exécutions, cependant le temps moyen pour son exécution sur ces 2 instances est
très mauvais par rapport à celui de C. Prins (10 et 20 fois supérieur). Sur les autres instances, en
comparant le GAP des solutions obtenues avec celui de C. Prins, on voit clairement que l’algorithme
proposé donne des solutions qui sont moins bonnes. Au niveau des temps on remarque que
l’algorithme proposé est plus rapide sur les instances où C. Prins ne trouve pas la meilleure solution
connue et qu’il est plus lent dans les autres cas.
6. Conclusion
Dans ce chapitre nous avons pu découvrir les problèmes de tournées de véhicules et nous
sommes monté en compétences sur la conception de méthode de résolution approchée et plus
particulièrement sur les métaheuristiques par le biais de l’élaboration d’une métaheuristique de type
GRASP/ELS pour la résolution du problème de tournée de véhicules. Nous avons par ailleurs pu
comparer les performances de l’algorithme proposé par rapport aux résultats de Prins *Prin04+ qui est
une référence dans le domaine des tournées de véhicules. On obtient des résultats satisfaisants et qui
permettent d’attaquer des problèmes plus complexes de tournées.
7. Références
*Bea83+ J.E. Beasley. Route-first cluster-second methods for vehicle routing. Omega, vol. 11,
pp. 403–408, 1983.
*Bie95+ C., Bierwirth, A generalized permutation approach to job-shop scheduling with genetic
algorithms. OR Spektrum, vol. 17, pp 87-92, 1995.
*Cha13+ M. Chassaing, J. Fontanel, P. Lacomme, L. Ren, N. Tchernev, and P. Villechenon, A GRASP-

ELS approach for the job-shop with a web service paradigm packaging, Expert Systems with
Applications, Available online 19 August 2013.
*Che96+ R. Cheng, M. Gen and Y. Tsujimura. A tutorial survey of job-shop scheduling problems using
genetic algorithms – I representation, Computers and industrial engineering, vol. 30, pp.
983-997. 1996.
23
*Chr79+ N. Christofides, A. Mingozzi, P. Toth. The vehicle routing problem. In Combinatorial

Optimization, John Wiley, vol. 11, pp. 315–338, 1979.
*Col91+ A. Colorni, M. Dorigo, and V. Maniezzo. Distributed optimization by ant colonies. In F. Varela
and P. Bourgine, editors, Proceedings of the European Conference on Artificial Life, Elsevier,
Amsterdam, pp. 134–142, 1991.
*Duh11+ C. Duhamel, P. Lacomme, C. Prodhon. Efficient frameworks for greedy split and new depth
first search split procedures for routing problems. Computers & Operations Research, vol.
38, pp. 723-739, 2011.
*Eil71+ S. Eilon, C.D.T. Watson-Gandy, and N. Christofides. Distribution Management: Mathematical
Modelling and Practical Analysis. Griffin, London, 1971.
*Fis81+ M.L. Fisher, R. Jaikumar. A generalized assignment heuristic for vehicle routing. Networks,
vol. 11, pp. 109–124, 1981.
*Gen02+ M. Gendreau, G. Laporte, J.Y. Potvin. Metaheuristics for the capacitated VRP. In: P. Toth, D.
Vigo, Editors. The Vehicle Routing Problem. SIAM Monographs on Discrete Mathematics and
Applications. SIAM, Philadelphia, pp. 129–154, 2002.
*Lac01+ P. Lacomme, C. Prins and W. Ramdane-Cherif, "Competitive genetic algorithms for the
Capacitated Arc Routing Problem and its extensions". EURO-GP 2001 (4th European
Conference on Genetic Programming), Côme, Italie, 18-20 avril 2001.
*Lap87+ G. Laporte, Y. Nobert. Exact algorithms for the vehicle routing problem. Ann. Discrete Math,
vol. 31, pp. 147–184, 1987.
*Pap77+ C. H. Papadimitriou. The Euclidean travelling salesman problem is NP-complete. Theoretical
Computer Science, vol. 4(3), pp 237–244, 1977.
*Prin04+ C. Prins. A simple and effective evolutionary algorithm for the vehicle routing problem,
Computers & Operations Research, vol. 31, pp. 1985–2002, 2004.
*Prin09+ C. Prins. A GRASP×Evolutionary Local Search Hybrid for the Vehicle Routing Problem, in: F.B.
Pereira and J. Tavares (Ed.), Bio-inspired Algorithms for the Vehicle Routing Problem, Studies
in Computational Intelligence, publisher Springer, Berlin, vol. 161, pp.35–53, 2009.
*Ren12+ L. REN, État de l’art : problèmes et méthodes autour des tournées de véhicules, Conception
et évaluation d’outils décisionnels pour des systèmes réactifs d’aide à la mobilité. PhD
thesis, Université Blaise Pascal, Clermont-Ferrand, 2012.
*Tot02+ P. Toth, D. Vigo. Models, relaxations and exact approaches for the capacitated vehicle
routing problem. Discrete Applied Mathematics, vol. 123 (1-3), pp. 487–512, 2002.
24
Chapitre 2 : Le problème de cheminement de piétons en milieu urbain
CHAPITRE 2
Le problème de cheminement
de piétons en milieu urbain
L’objectif de ce chapitre est d'étudier en quoi un contexte mobile peut amener à redéfinir
certains algorithmes afin de proposer un système orienté mobile qui soit efficace. Pour ce
faire, on se place dans le cas du cheminement de piétons en milieu urbain pour lequel la
conception d'une application mobile basée sur une architecture client-serveur va être
réalisée. La conception de cette application comprend la conception d'un algorithme de plus
court chemin adapté c'est-à-dire permettant d’effectuer des calculs au fur et à mesure du
déplacement du piétons offrant la possibilité de réagir aux aléas du parcours.
Dans un premier temps, on introduit les algorithmes de plus court chemin et plus
généralement les problèmes de cheminement dans les graphes avant de présenter
l’algorithme développé. Dans un deuxième temps, nous montrons comment cet algorithme
s'intègre au sein d'un système complet visant à calculer puis à guider un usager de sa
position actuelle vers une destination. Le chapitre se termine par une étude statistique du
système en évaluant sa performance en fonction des aléas liés aux déplacements.
1. Introduction
Au cours des dernières années il y a eu un regain d'intérêt pour le problème du plus court chemin
pour une utilisation dans diverses applications de l'ingénierie des transports. Ceci peut être attribué
aux récents développements dans les systèmes de transport intelligents (STI), en particulier dans le
domaine du système de guidage (GPS). Dans chacun de ces cas, il est absolument nécessaire de
trouver les chemins les plus courts à partir d'un point d'origine vers une destination d’une manière
rapide et précise.
Un certain nombre de stratégie de recherche ont été développées pour augmenter l'efficacité des
algorithmes de plus court chemin. La plupart de ces stratégies proviennent du domaine de
l'intelligence artificielle (AI). On peut citer entre autres *Nil71+ et *Pea84+ où le problème du plus
court chemin est utilisé comme un mécanisme permettant de valider l'efficacité des heuristiques.
Le domaine actuel du système de guidage en Amérique du Nord et en Europe a généré un regain
d'intérêt en utilisant des algorithmes heuristiques pour trouver les plus courts chemins dans un
réseau routier pour les opérations de routage de véhicules en temps réel. En 1989, *Guz89+ a
examiné comment les méthodes de recherche heuristique pourraient être utilisés dans le système de
navigation de véhicule. Un grand nombre de chercheurs ont alors suivi cette piste et ont essayé
d'introduire une stratégie mondiale visant à améliorer l'efficacité du processus de recherche du plus
court chemin. Ces efforts ont donné lieu à une abondante littérature, y compris un large éventail de
25
stratégies et de mécanismes recherche *Gub10+, *Will05+.
1.1 Le problème du plus court chemin

Le problème de cheminement dans un réseau routier, c’est-à-dire la recherche d’un itinéraire, se
ramène à un problème du plus court chemin (PCC) dans un graphe représentant le réseau routier
(Figure 22). Les sommets du graphe représentent des points précis du réseau (comme un carrefour
ou un bâtiment) et les arcs représentent les routes reliant ces différents points avec pour chacun
d’entre eux un coût symbolisant la longueur de la route (en temps et ou en distance selon les
besoins).
Figure 22 : Graphe d’un problème de plus court chemin
Soit 𝐺 = (𝑉, 𝐸) où 𝑉 est l’ensemble des sommets et 𝐸 est l’ensemble des arcs avec un coût
𝐶𝑖𝑗 ≥ 0 associé à chaque arc (𝑖, 𝑗) ∈ 𝐸, on peut alors formuler le problème de la façon suivante :
𝑘
Min ∶ z = ∑ 𝐶𝑖𝑗 𝑦𝑖𝑗 (1)
(𝑖,𝑗)∈𝐸
1, 𝑠𝑖 𝑗 = 𝑠
∑ yj,i − ∑ y𝑖,𝑗 = {−1, si j = t ∀j ∈ V (2)
(j,i)∈E (i,j)∈E 0, sinon
yi,j ∈ *0,1+ ∀ (i, j) ∈ E (3)
où :
𝑉 : l’ensemble des sommets constitué des clients et du dépôt.

𝐸 : l’ensemble des arcs.
𝑠 : le sommet de départ.
𝑡 : le sommet d’arrivée.
𝑦𝑖,𝑗 : 1 si l’itinéraire passe par l’arc (𝑖, 𝑗) ∈ 𝐸 si non 0
26
Dans ce modèle, les contraintes 2 sont constituées de trois inégalités ; la première vérifie que l’on
part du point de départ, la deuxième vérifie que l’on finit le trajet au point d’arrivée et la dernière
vérifie que chaque sommet du graphe contient autant d’arcs entrants compris dans l’itinéraire que
d’arcs sortants (conservation de flot).
1.2 Principaux algorithmes de résolution d’un problème de PCC

La recherche sur les algorithmes de plus court chemin s’est principalement développée à la fin
des années 50 et durant les années 60 comme le rappelle l’article de Dreyfus en 1969 *Dre69+. De nos
jours, la recherche sur les problèmes de plus court chemin s'est orientée vers les graphes de grandes
tailles et sur la réduction de ces graphes. On peut consulter à ce sujet les travaux de Willhalm en
2005 *Wil05+, ou encore ceux de Gubichev en 2010 *Gub10+. Il est possible de distinguer les
algorithmes de résolution du problème de plus court chemin en deux catégories :
 les méthodes exactes qui garantissent l’optimalité de la solution obtenue ;
 les méthodes approchées qui donnent une solution de bonne qualité mais pas forcément
optimale en un temps généralement plus court.
Méthodes exactes :
Les méthodes exactes pour la résolution de problèmes de PCC sont très utilisées dans le secteur
industriel et cela même pour des graphes de grandes tailles où elles sont généralement associées à
des techniques de réduction et de contraction de graphes. Parmi les algorithmes de résolution exacte
du problème de PCC les plus connus, on retrouve l’algorithme de Dijkstra *Dij59+ qui s’applique aux
graphes à coût positif, l’algorithme de Bellman *Bel58+ qui autorise la présence d'arcs de coût négatif
et l’algorithme de Floyd-Warshall *War62+ qui permet d’obtenir les distances entre chaque pair de
points du graphe en une seule exécution.
- L’algorithme de Dijkstra *Dij59+
Cet algorithme possède une complexité de l’ordre de (m+n)×n où 𝑚 est le nombre d’arcs du
graphe étudié et 𝑛 est son nombre de nœuds. Dans le cas d’un réseau routier 𝑚 et 𝑛 sont du même
ordre de grandeur, l’algorithme a donc une complexité quadratique suivant le nombre de nœuds du
graphe. C’est un algorithme itératif dans lequel l’information sur la distance parcourue depuis le point
de départ est propagée de voisin en voisin jusqu’au point d’arrivée. Pour se faire, cet algorithme
repose sur un principe de propagation de labels. Au fil de l’algorithme, à chaque nœud traité, le label
qui lui est associé est le coût du plus court chemin pour l’atteindre depuis le nœud de départ. A ce
nœud est alors aussi associé un nœud père qui est le précédant dans le plus court chemin jusqu’à lui.
L’exemple de la Figure 23 donne l'initialisation de l'algorithme pour un calcul du plus court
chemin du nœud 𝑠 au nœud 𝑡. Il s'agit d'initialiser le label du nœud 𝑠 à 0 et tous les autres labels à
+∞ puis dans un tableau de mémoriser les sommets du graphe non-traités par l’algorithme.
27
Figure 23 : Initialisation de Dijkstra
Vient ensuite l’étape itérative qui consiste à choisir le sommet du graphe non-traité qui possède
le label le plus petit puis à propager son label vers les nœuds qui lui sont adjacents. Sur l’exemple
on choisit donc le sommet 𝑠 qui a un label de valeur 0. On met ensuite à jour les labels des nœuds
4 et 5 qui sont adjacents au nœud de départ par le label du nœud 𝑠 auquel on ajoute le coût de
l’arc parcouru (notons que l’on ne change un label qu’avec une valeur qui lui est inférieure). Enfin le
sommet 𝑠 est supprimé du tableau des nœuds non-traités.
Figure 24 : Première itération de Dijkstra
On réitère cette étape jusqu’à ce que le nœud d’arrivée t porte le plus petit label parmi les nœuds
non-traités. On choisit donc à l’étape suivante le nœud 4 et on met à jour les labels des nœuds 2,3
28
et 7.
Figure 25 : Deuxième itération du Dijkstra
On tombe sur un cas où on a deux choix pour le sommet à traiter, le 5 et le 7. Il est possible de
choisir arbitrairement l’un des deux sans que cela change la solution finale. Dans ce cas le sommet
5 est choisi en premier. On met donc à jour le label du nœud 2.
Figure 26 : Troisième itération du Dijkstra
A partir du nœud 7, et on met à jour les labels des nœuds 1, 6, 8 et t.
29
Figure 27 : Dernière itération de Dijkstra
Arrivé à cette étape, on peut constater que 𝑡 fait partie des sommets qui ont le plus bas label
parmi ceux non-traités, on peut donc s’arrêter à cette étape. Il nous suffit alors de remonter les
nœuds pères depuis le nœud d’arrivé jusqu’au nœud de départ pour obtenir une solution
optimale ; on trouve alors le chemin (s,4,7,t) de coût 35 comme solution optimale du problème de
plus court chemin.
Une partie très importante du temps de calcul de cet algorithme repose dans la recherche du plus
petit label à chaque itération. Cette étape peut être grandement accélérée par l’utilisation d’un tas
pour stocker les labels des nœuds non-traités au lieu d’un tableau. En effet, lorsque l’on utilise un
tableau, la recherche du plus petit élément se fait en O(n) alors que la recherche dans un tas se
fait en O(1) à partir du moment où le tas est réarrangé en O(ln(n)) à chaque itération. On obtient
alors un algorithme de complexité O((m + n) × ln(n)) au lieu de O((m + n) × n).
- L’algorithme de Bellman *Bel58+
Cet algorithme possède une complexité au pire de l’ordre de 𝑛2 × 𝑚 où 𝑚 est le nombre d’arcs
du graphe et 𝑛 est le nombre de nœuds. Cet algorithme est un algorithme de programmation
dynamique qui se distingue du précédent par le fait que l'ordre de parcours des sommets ne peut
pas être obtenu en sélectionnant le sommet ayant le plus petit label à une itération donné du fait
des arcs à coûts négatifs. Il faut donc déterminer a priori un ordre de parcours des sommets. Cet
ordre a une influence très importante sur le nombre d'itérations de l'algorithme. Un ordre de
parcours des sommets permettant de faire un seul passage sur l'ensemble des sommets du graphe
défini un ordre topologique. Au pire des cas, l'algorithme peut effectuer autant d'itérations qu'il y
a de sommets dans le graphe.
Comme pour l’algorithme de Dijkstra, la première étape est une étape d’initialisation dans
laquelle on met le label du nœud 𝑠 à 0 et tous les autres labels à +∞. A chaque itération de
l’algorithme, tous les arcs du graphe sont parcourus, selon l'ordre initialement choisi. En fonction
de l'ordre choisi, le nombre total d'itérations de la méthode varie. Sur cet exemple, au pire, la
méthode effectuera donc 5 itérations. L'ordre de parcours des sommets du graphe permettant de
trouver le chemin optimal en 1 itération est appelé ordre topologique. Dans la majorité des cas,
sauf à utiliser des graphes ayant une structure particulière, la détermination d'un ordre
topologique n'est pas triviale.
A titre d'exemple, considérons l'ordre O : s 1 2 3 4 t
30
Figure 28 : Initialisation de Bellman
Lors du premier passage :

 On commence par le sommet s qui entraine une mise à jour des nœuds 2 et 3.
 On regarde les arcs issus du nœud 1 qui a toujours pour label +∞ donc rien n’est à mettre
à jour.
 On regarde les arcs issus du nœud 2, on met à jour les labels des nœuds 1 et 4.
 On regarde les arcs issus du nœud 3, on met à jour le label du nœud 4.
 On regarde les arcs issus du nœud 4, on met à jour le label du nœud d’arrivée.
Figure 29 : Première itération de Bellman
Lors du second passage :

 On commence par regarder les arcs issus de s où rien n’est à changer.
 On regarde les arcs issus du nœud 1, on met à jour le label du nœud d’arrivée.
 On regarde les arcs issus du nœud 2, rien n’est à changer.
31
Figure 30 : Deuxième itération de Bellman
L’algorithme effectue un troisième passage durant lequel aucun des labels n’est modifié.
L’algorithme est donc fini et on obtient le chemin (s, 2, 1, t) avec un coût de 40 comme solution
optimale du problème de plus court chemin.
- L’algorithme de Floyd-Warshall :
Cet algorithme possède une complexité de l’ordre de 𝑛3 où 𝑛 est le nombre de nœuds du graphe
étudié. Cet algorithme a un intérêt un peu différent des deux précédents du fait qu’il calcul
l’itinéraire le plus court pour tous les couples de sommets du graphe et pas pour un seul couple. Le
principe de cet algorithme est qu’à chaque itération, on va fixer un point de passage à l’ensemble
des itinéraires et mettre à jour les itinéraires qui sont améliorés en passant par ce point. L’exemple
Figure 31 servira à illustrer son principe. Les figures 31 à 35 présentent le déroulement de
l’algorithme avec les tableaux des coûts associés. Sur l’exemple les arcs ne sont pas orientés afin de
simplifier l’exemple. La première étape est une étape d’initialisation dans laquelle on initialise le
tableau des coûts des différents chemins par le coût des arcs lorsque les nœuds de départ et
d’arrivée sont adjacents et par +∞ sinon.
Figure 31 : Initialisation de Floyd-Warshall
32
La première étape consiste à fixer le nœud 1 et à regarder pour chaque couple de points si le
chemin est amélioré en passant par ce nœud. A cette itération, le chemin 2 à 5 est le seul à être
amélioré.
Figure 32 : Première itération de Floyd-Warshall
A la deuxième itération on s’intéresse au nœud 2, le chemin de 1 à 3 et le chemin de 3 à 5 sont

améliorés.
Figure 33 : Deuxième itération de Floyd-Warshall
On s’intéresse ensuite au nœud 3, les chemins de 1 à 4 et de 2 à 4 sont améliorés.
Figure 34 : Troisième itération de Floyd-Warshall
On s’intéresse ensuite au nœud 4, le chemin de 3 à 5 est amélioré. Enfin en regardant le nœud 5,

le chemin de 1 à 4 est amélioré. On obtient donc, à la fin de ces itérations, un tableau des coûts des
plus courts chemins entre chaque couple de nœuds.
Figure 35 : Fin de Floyd-Warshall
Méthodes approchées :
Les méthodes approchées pour la résolution du problème du PCC sont très utilisées dans le
domaine de l’intelligence artificiel et des jeux vidéo par exemple car elles permettent d’obtenir une
solution de façon très rapide. L’algorithme de résolution approchées du problème du PCC le plus
connu est l’algorithme A* de *Har68+.
33
- L’algorithme de A*:
Si on faisait une recherche en largeur comme le réalise l'algorithme de Dijkstra, on rechercherait
tous les points dans un rayon circulaire fixe, augmentant graduellement ce cercle pour rechercher
des intersections de plus en plus loin de notre point de départ. Ceci pourrait être une stratégie
efficace si on ne savait pas où se trouve notre destination, comme la police recherchant un criminel
en planque.
On peut considérer que l’algorithme de A étoile est basé sur le même principe que celui de
Dijkstra. Il repose en effet sur une propagation de labels et sur une sauvegarde du nœud père à
chaque itération similaire à l’algorithme de Dijkstra. Sa différence réside dans le fait que plutôt que
d’élargir progressivement le rayon de propagation des labels à partir du nœud de départ dans
toutes les directions, on explore en priorité les nœuds en direction du nœud d’arrivé. Cette notion
de direction induit une notion de distance à définir. On choisit pour présenter l’algorithme la
distance euclidienne. L’idée de l’algorithme est alors d’estimer pour chaque nœud le coût qui le
sépare du nœud d’arrivé afin que d’éviter de traiter les nœuds désavantageux ; l’algorithme va à
chaque itération construire un itinéraire en prenant le point de passage suivant, autant que faire se
peut, en direction du point d’arrivée. Son principe est illustré sur l’exemple de la Figure 36, sur
laquelle on s'intéresse au calcul du plus court chemin du nœud s au nœud t. La première étape est
une étape d’initialisation dans laquelle on calcule pour chaque nœud une estimation de sa distance
au point d’arrivée qui est la distance Euclidienne dans le cadre de cet exemple. On finit cette étape
en initialisant la file d’attente avec le point de départ.
Figure 36 : Initialisation de A étoile
A chaque itération de l’algorithme, il faut considérer le premier élément de la file d’attente,

parcourir chacun de ses nœuds adjacents qui n’ont pas encore été traités par l’algorithme. Ils sont
ajoutés à la file d’attente de la façon suivante. On somme le coût de l’arc pour parvenir au nœud et
son estimation pour atteindre le nœud d’arrivée et on ordonne ensuite la liste de la plus petite valeur
à la plus grande. Cette étape est réitérée jusqu’à atteindre le nœud d’arrivée. Lors de la première
itération, on s’intéresse donc aux nœuds 4 et 5 que l’on ajoute à la file d’attente respectivement avec
les valeurs 45 et 65. On considère ensuite s comme traité.
34
Figure 37 : Liste d’attente de la première itération de A étoile
A la deuxième itération, le premier élément de la file est le nœud 4 et ses nœuds adjacents
sont les nœuds 2, 3 et 7 que l’on rajoute donc à la liste.
Figure 38 : Liste d’attente de la deuxième itération de A étoile
A la troisième itération, le premier élément de la file est le nœud 7 et ses nœuds adjacents
sont les nœuds 1, 5, 6, 8 et t. t, le nœud d’arrivée, fait partie de la liste des nœuds adjacents au
nœud en tête de liste donc l’algorithme s’arrête. Suivant le même principe que pour l’algorithme de
Dijkstra, on remonte le chemin depuis le nœud d’arrivée et obtient une solution approchée du plus
court chemin (s,4,7,t) qui est, dans ce cas, une solution optimale.
Figure 39 : Liste d’attente de la dernière itération de A étoile
2. Application du problème de PCC dans un environnement mobile

Cette partie est consacrée à la conception de l’algorithme du plus court chemin pour piétons dans
un environnement urbain modélisé sous la forme d'un graphe orienté. L'objectif est de fournir un
système capable de calculer un plus court chemin mais aussi de guider l'utilisateur dans des
conditions réelles d'utilisation.
2.1 Les contraintes à prendre en compte

La première difficulté à résoudre est la gestion des problèmes de modélisation du réseau routier.
En effet, le graphe modélise un réseau routier "idéal", dans lequel ne sont pas pris en compte les
travaux, les accidents ou les changements "récents" des règles de circulations (nouveau sens interdit,
rue interdite à la circulation…). Ces éléments (aléas) peuvent induire de la part de l'usager du
système, une incapacité à respecter des consignes c'est-à-dire l'incapacité à respecter le plus court
chemin calculé. Ces aléas sont aussi dus à des difficultés à communiquer les consignes (tourner à
droite, puis à gauche) : reflets du soleil sur l'écran du smartphone, bruits ambiant empêchant l'usager
de comprendre l'indication par exemple.
La deuxième difficulté est liée à la taille des graphes modélisant le réseau routier. A titre
d’exemple, une région de la France comme l’Auvergne comporte 95 000 nœuds et 233 000 arcs, on se
situe donc dans des graphes de grandes tailles. Il s'agit donc d'intégrer cela dans la conception des
algorithmes. Cette remarque prend tout son sens dans la mesure où le système est une architecture
client-serveur. Dans ce type de système de nombreux utilisateurs de smartphone partage une même
ressource (le serveur) sur lequel les calculs sont effectués.
35
Compte tenu des deux difficultés qui viennent d'être mise en évidence, nous avons proposé un
algorithme de plus court chemin dynamique travaillant sur un graphe réduit.
2.2 Etude sur la structure d'un système orienté mobile

Il s'agit d'une architecture dans laquelle les clients (leurs mobiles) se connectent via une
application dédiée à un serveur qui va effectuer les calculs. Les rôles respectifs du mobile et du
serveur peuvent varier selon le type d’architecture considérée. On présente ci-dessous deux schémas
d’architecture client-serveur classiques :
Architecture avec un client de type terminal
L’architecture client-serveur dialoguant avec un serveur de cartographie et avec un client de type
terminal se décompose en trois parties (Figure 40) :
 Une partie client qui prend en charge le déclenchement de la demande de calcul du plus court
chemin (1). C’est-à-dire qu’elle est en charge de fournir au serveur les coordonnées de départ et
d’arrivé de l’itinéraire souhaité. Une fois l’itinéraire récupéré (5), elle est chargée également de la
visualisation du chemin, donc de la récupération des tuiles auprès de MapQuest ainsi que de
l’affichage de l’interface.
 Une partie serveur qui, après avoir récupéré les positions de départ et d’arrivée auprès de la
partie cliente, s’occupe de récupérer les données routières auprès d’OSM (2) et (3) afin de
construire le graphe nécessaire au calcul d’itinéraire. Une fois le graphe construit, le serveur
effectue le calcul de plus court chemin (4) afin de renvoyer à l’application cliente l’itinéraire
obtenu (5).
 Le serveur de données routières d’OSM qui permet de fournir les données nécessaires à la
réalisation du graphe (2) et (3).
Figure 40 : Architecture où l’application client fait office de terminal
Une architecture de ce type a pour intérêt, d’une part de limiter au maximum la quantité de
données présentes sur l’application mobile qui ne contient alors que les données strictement
nécessaires à l’interface et à l’affichage du résultat pour l’utilisateur, et d’autre part d’effectuer les
calculs sur le serveur distant afin d’alléger la consommation CPU de l’application.
L’inconvénient de cette architecture est qu’elle nécessite une connexion réseau quasi-
permanente entre l’application cliente et le serveur. En effet, plusieurs appels au serveur sont
36
effectués à chacun des recalculs d’itinéraire, c’est-à-dire à chaque fois que l’utilisateur s’éloigne de
l’itinéraire calculé ou qu’il s’approche de la fin du morceau d’itinéraire calculé. Cette architecture
est donc très sensible aux coupures réseaux qui sont très fréquentes en milieu urbain. C’est
pourquoi la seconde architecture client-serveur qui est présentée limite le nombre d’accès au
serveur.
Architecture avec un client de type semi-autonome

Il s'agit d'une architecture dans laquelle le client est en autonomie partielle vis-à-vis du serveur.
Cette architecture se compose des trois éléments identiques à l’architecture précédente mais qui
voient leur rôle au sein de l’architecture client-serveur modifié :
 La partie client prend en charge le déclenchement du calcul mais aussi le calcul lui-même. Elle
récupère donc du serveur le graphe nécessaire au calcul d’itinéraire (1) et (4) avant d’effectuer, si
l'état du réseau est insuffisant, en local un calcul de plus court chemin (5). Elle reste, bien sûr,
chargée de la récupération des tuiles auprès de MapQuest pour l’étape de visualisation du chemin
ainsi que de l’affichage de l’interface.
 La partie serveur qui récupère les données routières d’OSM (2) et (3) puis qui les transforme en un
graphe qui est ensuite envoyé à la partie client pour le calcul d’itinéraire.
 Le serveur de données routières d’OSM qui continue de jouer le rôle du fournisseur de données
nécessaires à la réalisation du graphe (2) et (3).
Une architecture de ce type a pour intérêt de limiter le nombre de communications avec le serveur
tout en évitant de télécharger des quantités de données routières trop importantes en local.
L’inconvénient de cette architecture est la quantité de données qui doivent être récupérées et
présentes sur le client ainsi que la consommation CPU de l’application client est assez importante dû
au fait que certains calculs se font directement sur le client (en l'occurrence un téléphone portable).
Dans cette configuration, une fois le graphe récupéré du serveur, l’application peut fonctionner en
autonomie jusqu’à ce que le graphe en local devienne obsolète pour le calcul d’itinéraire. En effet, les
cas de demande de recalcul due à l’utilisateur qui s’éloigne de l’itinéraire ne nécessitent
généralement pas le téléchargement d'un nouveau graphe.
Pour résumer, cette architecture comme la précédente permet de ne pas télécharger les données
routières sur le client afin de ne pas saturer la connexion et la mémoire du mobile, elle se différentie
par le calcul effectué éventuellement en local qui permet de réduire le nombre de communications
avec le serveur.
2.3 Etude sur la limitation de la taille du graphe

Depuis plusieurs années les principales publications sur les problèmes de PCC dans les graphes de
grande taille travaillent sur des techniques de limitation de la taille du graphe *Wil05+, *Gub10+. Ces
techniques sont partagées entre les techniques visant à limiter le nombre de nœuds considérés et les
techniques limitant le nombre d’arrêtes empruntables.
37
Techniques limitant l'exploration du graphe

Dans l’optique de parcourir moins de nœuds lors de l’exécution de l’algorithme de Dijkstra, il est
possible de limiter l'exploration du graphe à un sous-graphe situé autour du chemin représentant la
distance euclidienne. On peut alors délimiter une zone ellipsoïdale de taille raisonnable (c’est-à-dire
de façon à garder la connexité entre le point de départ et d’arrivée) autour de cette ligne droite afin
de limité l'exploration du graphe à ce sous-graphe.
Figure 41 : Limitation du graphe
Il faut noter que dans un graphe modélisant une zone urbaine on perd l’optimalité du plus court
chemin mais que probablement dans un grand nombre de cas, le chemin trouvé est probablement
être proche du chemin optimal pour peu que la densité soit suffisante.
Contraction du graphe
Après avoir limité la taille du graphe à explorer, on peut aussi appliquer des principes de
contraction du graphe. Comme de nombreux auteurs l'ont souligné il existe de nombreuses
techniques permettant de contracter plusieurs sommets en un seul sommet et des techniques visant
à limiter le nombre d'arcs. Ces techniques sont présentées par exemple par *Dor03+ et par *Dor05+. A
titre d'exemple, nous soulignons ci-dessous, la possibilité, dans le cas d'un calcul d'itinéraire pour
piétons (graphe non orienté) qu'il est possible d'envisager la suppression des arcs qui ne sont pas
orienté dans la direction (s; t) en considérant que plus on s'éloigne de la ligne droite entre s et t, plus
la probabilité de rester sur le plus court chemin diminue. Toutefois, les nombreux sens interdits en
zone urbaine limite cette remarque aux piétons. Il est alors possible de contracter le graphe de
différentes manières, en supprimant par exemple les arcs qui ont un sens opposé au sens défini par le
point de départ et d’arrivée dans la mesure où l’on garde une connexité entre le point de départ et
d’arrivée. La Figure 42 illustre la contraction possible sur le graphe.
38
Figure 42 : Contraction du graphe
2.4 Proposition d’une structure d'un système orienté mobile

Il s'agit de définir une architecture qui soit compromis des deux architectures présentées afin de
limiter les problèmes liés à la connexion réseau tout en soulageant au minimisant la contribution de
l’application client. Le principe de cette architecture réside sur le fait que lorsque des problèmes de
connexion réseau surviennent dans un milieu urbain, ils ne durent rarement plus de quelques
minutes. Cette architecture va donc tirer profit des créneaux durant lesquels la connexion avec le
serveur est stable pour se préparer aux potentiels problèmes de connexion. L’intérêt est de pouvoir
lancer un recalcul d’itinéraire en local pour pallier aux erreurs d’itinéraires de l’utilisateur lors des
"trous de connexion" mais de continuer à effectuer le calcul sur le serveur lorsque la connexion
réseau le permet. Cette architecture va être présentée en détaillant ses étapes de fonctionnement
illustrées par la Figure 43.
Lors du fonctionnement normal de l’architecture, c’est-à-dire quand la connexion est établie, le
client ne joue le rôle que de terminal à ceci près qu’il récupère, en plus de l’itinéraire, un graphe
autour de la position courante. Il s’occupe donc de la gestion du déclenchement du calcul (1), de la
visualisation du chemin une fois l’itinéraire récupéré auprès du serveur (5) et met à jour si nécessaire
le graphe qu’il a en local avec celui fourni par le serveur (6). Le serveur, quand à lui, récupère les
données routières auprès d’OSM afin de construire le graphe de calcul (2) et (3), effectue le calcul (4),
fourni au client l’itinéraire (5) et fournit si nécessaire un graphe autour de la position courante du
mobile au client (6). (C’est-à-dire dans le cas où le centre du graphe déjà présent du coté client est
trop éloigné de sa position courante.) Lors d’un "trou de connexion", c’est-à-dire quand la connexion
client-serveur n’est plus effective, l’application regarde si le graphe contenu en local contient sa
position courante auquel cas l’application effectue en local un calcul du PCC vers la position du
graphe la plus proche du point de destination (2bis).
39
Figure 43 : Architecture permettant de limiter les problèmes de connexion réseau
2.5 Proposition d'un système "dynamique" de calcul du PCC

Dans le graphe, on ne modélise par les aléas tels que les accidents, les routes momentanément
inaccessibles car fermées pour travaux par exemple. D'autres éléments liés à l'utilisation de
l'algorithme dans un cadre urbain viennent aussi générer d'autres formes d'aléa. En effet,
l'algorithme à concevoir a pour vocation à être intégré dans un système global fonctionnant sur
téléphone portable. Et dans ce cadre, l'usager peut non seulement être amené à ne pas respecter le
trajet calculé car cela est impossible à cause des aléas survenant dans le réseau routier, mais aussi car
le téléphone communiquant par un dessin sur l'écran et oralement ne lui permet pas de comprendre
les instructions données. On peut garder l'esprit les difficultés qu'il y a à lire sur son téléphone un
simple mail alors que l'écran est éclairé par le soleil ou bien la difficulté par tenir une conversation
dans le bruit de la rue.
Compte tenu des aléas liés à une utilisation urbaine, l'aspect dynamique est apparu comme très
important. C'est la raison pour laquelle, le calcul du chemin se fait de manière dynamique afin de
faciliter les recalculs cependant l’optimalité de la solution n’est plus garantit. Le principe réside dans
le fait que l’on n’a pas besoin pour se diriger sur une route de l’ensemble de l’itinéraire mais
seulement des quelques prochaines instructions. L’algorithme consiste donc à ne calculer qu’une
partie de l’itinéraire (un rectangle d'environ 1km et demi est suffisant) afin de rendre le calcul plus
rapide. Le calcul consiste, comme pour la technique de la limitation du graphe, à tracer une droite
entre le point de départ et d’arrivée afin d’obtenir la direction que l’on doit suivre et donc d’établir un
premier point de passage. Le calcul est alors réitéré dans deux cas, le cas où l’utilisateur s’éloigne du
chemin pré-calculé et le cas où l’on est à une distance raisonnable de la fin du premier morceau
d’itinéraire. La Figure 44 ci-dessous illustre deux itérations du calcul itératif pour établir un itinéraire.
On constate sur ce graphe que le chemin initial calcul comprend les nœuds s, a, b, r. Le nouveau
calcul s'effectue à partir du nœud r qui figure en noir sur la figure.
40
Figure 44 : Calculs itératifs
3. Réalisation du système de guidage orienté mobilité

Le système de guidage qui est proposé dans ce chapitre s’applique aux piétons dans un
environnement mobile. Ce système repose sur l’architecture proposée dans la section 2.5. Pour créer
une application basée sur cette architecture, il est nécessaire, dans un premier temps, de générer un
graphe représentant le réseau routier dans lequel l’utilisateur se déplace. Ceci nécessite l’accès à un
service de cartographie le plus récent et le plus complet possible. Après avoir présenté le choix fait
pour ce service de cartographie, on présente la réalisation du web service et l’application mobile qui
sont respectivement le serveur et le client de l’architecture utilisée. L’installation et le détail de
fonctionnement sont donnés en annexe 2.
3.1 Etude sur les services de cartographie

Un service de cartographie est un sous-ensemble de la famille des SIG (Système d'information
géographique) qui sont des systèmes d'information permettant de créer, d'organiser et de présenter
des données géographiques (ex : plans et cartes). Il est constitué principalement de quatre éléments
indispensables au système de guidage :
 Un serveur de données routières qui fournit les données nécessaires pour la modélisation
du réseau routier sous forme de graphe ;
 Un serveur de tuiles permettant d’obtenir la représentation visuelle du réseau sur le
client sous forme de tuiles ;
 Des API de développement qui offrent la possibilité au client d’interagir avec le service de
cartographie afin par exemple d’afficher des repères visuels sur la carte ou la possibilité
d’obtenir une localisation géographique à partir d’une adresse postale.
La plupart des services de cartographie ne proposent l’accès gratuit de façon limitée ou non qu’à
certains de ces éléments. Le Tableau 3 dessous présente les services de cartographie les plus
complets existants ainsi que le degré de disponibilité de leurs ressources :
41
Tableau 3 : Comparaison des différents systèmes de cartographies
Nom Serveur de Serveur de API de

données tuiles développement
Google Maps Non-disponible Accès limité Accès limité
ArcGIS Payant Payant Payant
Bing Maps Non-disponible Accès limité Accès limité
Mapquest Non-disponible disponible disponible
Via Michelin Non-disponible Accès limité Accès limité
OpenStreetMap disponible disponible Non-disponible
3.2 Analyse des besoins du système liés au service de cartographie

Dans cette section, on présente les choix faits sur les différents systèmes de cartographie selon
les besoins :
Constitution du graphe modélisant le réseau routier

Pour récupérer les données routières et ainsi constituer le graphe, il a été choisi OpenStreetMap
(OSM) car c’est un système de cartographie très complet et dont les données routières sont fournies
de façon "open-source". OSM propose une API pour développeur qui permet d’importer des données
du réseau routier au format XML par une simple requête de type GET envoyée au web-service REST
du serveur de données d’OSM afin de définir la zone de la carte demandée. Ceci permet de récupérer
une partie de la carte nécessaire à la constitution du graphe.
Acquisition de la position des points de départ et d’arrivée

La position de départ de l’itinéraire est déterminée directement par l’utilisation des outils de
géolocalisation de l’appareil mobile. Une fois la position GPS de l’utilisateur connue, il suffit de
projeter cette position sur l’arc du graphe le plus proche afin d’obtenir la position de départ. Cette
étape de l’algorithme est détaillée dans section 4.3 de ce chapitre.
Pour déterminer la position d’arrivée, l’utilisateur doit saisir une adresse postale. Une fois cette
adresse récupérée, il faut la géolocaliser. Ceci peut se faire par l’API de géolocalisation proposée par
MapQuest. Une fois la position GPS connue, une projection sur l’arc du graphe le plus proche
s’effectue de la même façon que pour la position de départ.
Visualisation de la carte
Afin que l’utilisateur puisse visualiser l’itinéraire calculé, il est nécessaire une cartographie sous
format image pour pouvoir projeter le chemin obtenu dessus. Une tuile est une portion de la carte
sous format image pour un zoom donné. L’affichage d’une carte sur un mobile est constitué par
exemple d’environ quatre tuiles comme illustré sur la Figure 45. Ces quatre tuiles changent bien sûr
en permanence en fonction du zoom et du défilement effectués sur la carte. De nombreux systèmes
de cartographie laissent un accès libre ou peu restreint à leur serveur de tuiles dont OSM et
MapQuest. Ces deux serveurs sont particulièrement intéressants car ils ont une parfaite
correspondance entre les tuiles de leur serveur et les données routières d’OSM. Le choix d’utiliser
MapQuest a été fait car il fournit de API d’utilisation de tuiles issues de différents services de
cartographie. Ces API facilitent la gestion du zoom et du défilement de la carte par exemple.
42
(a) Carte sans tuile (b) Carte avec tuiles
Figure 45 : Illustration d’une carte constituée de tuiles
3.3 Réalisation du Web service

Le coté serveur du système basé sur l’architecture client-serveur, présentée précédemment par la
Figure 43, est constitué d’un web-service défini par ses différentes fonctions.
Principe du web service
Un service web pourrait être défini comme un logiciel fonctionnant sur un serveur, fournissant un service et
l'exposant sous forme d’un ensemble de fonctions ou de méthodes. Pour chaque appel d’un client à une méthode
exposée, un service web doit accepter la demande, effectuer une exécution d'une ou plusieurs fonctions selon la
demande reçue et retourner un résultat.La description doit être formelle et explicite de manière à ce que le client
puisse facilement interagir avec le système. Le langage XML (eXtensible Mark-up Language), basé sur le
protocole internet, est utilisé pour établir cette description ce qui permet une grande interopérabilité entre
différents web services.
Analyse fonctionnelle
Pour que le système de guidage soit fonctionnel le coté serveur a besoin de communiquer avec le
client et le serveur de données suivant le schéma Figure 46.
43
Utilisateur Web service Serveur de données
demarrer_Guidage
demande de données routières
données routières
Calcul du plus court chemin

testerEtatDemande
état du calcul
recupererResultatGuidage
itinéraire
recupererGraphe
demande de données routières
données routières
données du graphe
Figure 46 : Diagramme de séquence des fonctions du web service
Les méthodes associées au Web service développé ont deux fonctions principales : celle de
fournir un itinéraire entre deux points donnés du réseau routier et celle de fournir les données d’un
graphe autour d’une position donnée. Ces deux fonctions reposent sur le téléchargement de données
routières et leur conversion en graphe. Chacun des appels à une de ces fonctions nécessite donc un
certain temps de traitement et une certaine quantité de mémoire disponible. Ces méthodes sont
implémentées de manière asynchrone ce qui permet le traitement simultané de plusieurs requêtes.
Le Web Service proposé fournit donc cinq méthodes :
 demarrer_Guidage : Méthode qui envoie au serveur une requête de calcul à partir des
coordonnées GPS du point de départ et d’arrivée fournies en argument accompagnées de la clef
d’identification.
 testerEtatDemande : Méthode qui permet de vérifier l’état de la demande de calcul fait au serveur
à partir de la clef qu’on lui fournit en argument.
 recupererResultatGuidage : Méthode qui permet de récupérer, toujours à partir de la clef, la liste
des arcs de l’itinéraire à parcourir sous forme d’une chaîne de caractères une fois qu’il est
disponible.
 lireCodeRetour : Méthode qui prend en argument un nombre et renvoie la signification du code
erreur qui lui est associé sous forme d’une chaîne de caractères.
recupererGraphe : Méthode qui permet de récupérer toutes les informations sur les arcs et les
nœuds d’un graphe dans un rayon donné autour d’une position donnée.
Contrôle d’accès :
Afin de d'identifier les utilisateurs un système de gestion de clefs a été mis en place dans lequel
chaque utilisateur possède une clef qui lui est propre et qui sera communiquée au serveur à chaque
44
fois qu’il fait appel au Web service. L’utilisation de ce système permet de limiter chaque utilisateur à
une connexion au serveur d’une part, et de limiter le nombre de connexion journalière de chaque
utilisateur d’autre part ceci afin de limiter les utilisations abusives.
L’utilisation du Web service est donc restreint par l’utilisation d’une clef qui est fournie de
manière automatique lors de l’utilisation de l’application Android en fonction de l’identifiant unique
du mobile, ou qui peut aussi être fournie par un courrier électronique en remplissant un formulaire
(http://fc.isima.fr/~lacomme/identification/).
Implémentation
Le Web service est développé sous Java dans l’environnement de développement de NetBeans
est hébergé sur un serveur d'applications GlassFish (Figure 47). Ce serveur d’application est hébergé
sur deux serveurs de l’ISIMA afin de palier à l’arrêt d’un des serveurs (http://orws.isima.fr:8080/ et
http://orws2.isima.fr/).
Figure 47 : Environnement de développement du Web service
Utilisation du web service

Il peut être utilisé de trois façons. Soit directement à l’aide d’un explorateur internet, soit par
l’utilisation d’un socket par le biais du langage de programmation choisi, soit en utilisant un
environnement de développement qui gère la communication avec le Web service à partir de
l’adresse du WSDL du web service.
a) Avec un explorateur internet :

Lors du déploiement d’un web service (SOAP) sur un serveur d’application, ce dernier va créer de
façon automatique une page de test permettant d’utiliser les différentes fonctions avec un navigateur
internet. Afin d’accéder à cette page, il suffit de rentrer l’adresse du web service suivi du paramètre
« tester » comme illustrer sur l’exemple ci-dessous :
http://orws2.isima.fr/Recuperation_donnee/Recuperation_donnee?tester
Une page test se présente alors sous la forme illustrée Figure 48 :
45
Figure 48 : Utilisation du Web service avec un explorateur internet
b) Avec un Socket :
Pour accéder au Web service, on peut aussi utiliser un socket afin de faire communiquer
l’application avec le Web service. Il suffit de construire une enveloppe SOAP avec tous les paramètres
nécessaires à la méthode demandée afin d’envoyer au Web service une requête POST constituée de
cette enveloppe. C’est la méthode choisie pour faire communiquer l’application Android avec le Web
service, elle est détaillée et expliquée dans l’annexe.
c) Dans un environnement de développement:

A partir de l’adresse du web service, un environnement de développement, tel que NetBeans par
exemple, est capable de récupérer toutes les informations nécessaires à l’utilisation des méthodes
proposées. C’est-à-dire qu’il génère de façon automatique le code qui s’occupera de toute la partie
communication avec le Web service. Les méthodes du Web service pourront alors être utilisées dans
le code du client comme des fonctions importées à partir d’une librairie.
3.4 Réalisation d'un client Android

L’application mobile est conçue pour fournir un itinéraire depuis la position courante vers une
destination choisie en milieu urbain. Elle est constituée principalement de trois couches illustrée par
la Figure 49 :
 Une couche de communication permettant de dialoguer avec le web service
 Une couche métier traitant les informations issues du web service
 Une couche affichage constituant l’interface avec l’utilisateur
46
Figure 49 : Environnement de développement de l’application cliente
Analyse fonctionnelle
a) Multithread
La principale préoccupation lors de la conception d’une application Android est d'obtenir un
fonctionnement correct mais aussi une fluidité d’utilisation satisfaisante. C’est pourquoi chaque
action coûteuse en temps se fait en tâche de fond de l’application afin que l’utilisateur puisse
continuer de naviguer sur la carte et dans le menu (application multithread).
b) Graphe en local
Comme il l’a été présenté dans la section 2.4, l’application stocke un graphe en local dès qu’elle en
a l’occasion comme sécurité en cas de dégradation du réseau afin de continuer le guidage. Pour éviter
tout conflit dans la constitution de l’itinéraire ou pour l’accès au graphe en local, l’application
n’autorise qu’un seul calcul ou téléchargement de graphe en parallèle. Pour effectuer le calcul, un test
de connexion réseau est effectué. Si le réseau n’est pas disponible, l’application fait le calcul en local
(dans la mesure où le centre du graphe en local est suffisamment proche de la position courante pour
que le calcul ait un sens). Le déclenchement du calcul se fait de deux façons : 1) soit lorsque
l’utilisateur en fait la demande par l’interface; 2) soit de façon automatique lorsque l’application
décide que l’itinéraire nécessite d’être recalculé compte tenu de la position GPS du mobile.
c) Guidage
Dans le cas d’un déclenchement par l’utilisateur, l’application fournit des indications sonores et
visuelles sur l'avancement du calcul. Ensuite, lors du parcours de l’itinéraire, l’application calcule
l’angle entre l’arc sur lequel se trouve l’utilisateur et le prochain arc du chemin ainsi que la distance
restante jusqu’à l’intersection des deux arcs afin d’indiquer à l’utilisateur quelle direction il doit
emprunter (gauche, droite ou tout droit et dans combien de mètres).
d) Géocodage d’une adresse postale

Afin d’obtenir les coordonnées GPS de destination, on récupère l’adresse postale auprès de
l’utilisateur par une interface de saisie. L’adresse postale est ensuite géolocalisée à l’aide d’une API
d’un service de cartographie.
Conception de l’interface :
L’interface de l’application se compose d’une carte sur laquelle l’utilisateur peut se déplacer et
zoomer, d’un bouton permettant de quitter l’application pour éviter qu’elle continue de s’exécuter en
tache de fond et d’un menu déroulant permettant d’accéder aux différentes fonctions de
l’application. L’architecture de l’interface est présentée Figure 50 dans laquelle plutôt que d’utiliser
les composants natifs du langage de développement (java), on choisit, par soucis d’esthétique,
d’incorporer une interface en html. Par conséquent l’interface, vue de l’environnement de
développement, n’est constituée que d’un composant WebView :
47
a) Squelette de l’interface b) Interface en HTML

Figure 50 : Interface de l’application
Détaillons ci-dessous les différentes fonctionnalités de l’application qui sont disponibles à partir du
menu :
 Ma position : Permet de centrer la carte sur la position GPS actuelle.
 Destination : Permet de saisir l’adresse postale de la destination dans une nouvelle fenêtre.
 Guider : Permet de lancer le calcul d’itinéraire une fois que la destination souhaitée a été rentrée
puis d’afficher l’itinéraire obtenu sur la carte.
 La langue : Permet de passer l’application en anglais ou en français. (la langue par défaut
correspond à la langue du téléphone.)
 A propos de : Fournit quelques informations sur la conception de l’application.
Implémentation
L’application cliente a été développée pour Android sous java dans l’environnement Eclipse. Elle
communique avec le serveur de Web services par le protocole SOAP. L’interface de la page principale
de l’application, quant à elle, a été programmée en javascript et html afin, d’une part, d’optimiser sa
compatibilité avec les api de visualisation de carte de MapQuest, et d’autre part, de simplifier
l’agencement et l’élaboration des éléments graphiques qui peuvent être complexe en
programmation Android (Ce n’est pas le cas pour la page de saisie d’adresse et de la page à propos
de).
4. Analyse des résultats

Comme on a pu le voir dans la seconde partie de ce chapitre, l’algorithme développé est destiné à
être utilisé par des utilisateurs en prenant en compte les aléas connus du cheminement de piétons en
milieu urbain, c’est-à-dire que l’itinéraire initial est souvent remis en cause par les déplacements de
l’utilisateur.
Cette partie est donc consacrée à l'analyse du système en modélisant les non-respects des
directives envoyées à l’utilisateur par une certaine probabilité d'erreur au niveau des nœuds du
graphe.
48
4.1 Présentation des données

Pour évaluer le fonctionnement du système dans un cas concret, les données routières d’une zone
géographique d’environ 5 kilomètres de côté ont été récupérées, comprenant la majeure partie de
Clermont-Ferrand et de ses banlieues sud (Chamalières, Beaumont, et Aubière) (Figure 51).
Figure 51 : Réseau routier de Clermont-Ferrand et ces banlieues
On obtient alors un graphe de 1502 sommets et 4400 arcs (Figure 52).
Figure 52 : Graphe représentant le réseau routier de Clermont-Ferrand et ses banlieues
49
A partir de ce graphe, plusieurs couples (points de départ, point d’arrivée) ont été sélectionnés
aléatoirement de telle façon que leur distance, calculée à partir d’une méthode de plus court chemin sur
le graphe, soit supérieure à 800m. Le cas des chemins de longueur trop petite est en effet peu intéressant
car l’algorithme itératif effectue le calcul de PCC jusqu’au point de destination en une seule itération (dans
le cas où l’utilisateur ne se perd pas).
N° instance Point d’origine Point d’arrivée N° instance Point d’origine Point d’arrivée
1 45,7581 3,1101 45,7780 3,0831 15 45,7645 3,1053 45,7812 3,0903
2 45,7792 3,1168 45,7580 3,0784 16 45,7728 3,0727 45,7662 3,0680
3 45,7848 3,1028 45,7746 3,0947 17 45,7805 3,1001 45,7763 3,0770
4 45,7890 3,0951 45,7704 3,1188 18 45,7592 3,0841 45,7777 3,0703
5 45,7780 3,1104 45,7884 3,0983 19 45,7620 3,1248 45,7612 3,0934
6 45,7751 3,0829 45,7710 3,0926 20 45,7691 3,1079 45,7879 3,0997
7 45,7701 3,0808 45,7801 3,1184 21 45,7773 3,0907 45,7877 3,0861
8 45,7821 3,0985 45,7636 3,1078 22 45,7764 3,0713 45,7664 3,0796
9 45,7705 3,0656 45,7651 3,0769 23 45,7725 3,0936 45,7668 3,1143
10 45,7819 3,1027 45,7647 3,0974 24 45,7613 3,0906 45,7867 3,0788
11 45,7590 3,1159 45,7856 3,0735 25 45,7682 3,0893 45,7654 3,0984
12 45,7789 3,0836 45,7823 3,1019 26 45,7654 3,0892 45,7654 3,0882
13 45,7890 3,1001 45,7707 3,0757 27 45,7659 3,1079 45,7804 3,0874
14 45,7683 3,1066 45,7816 3,1239
4.2 Analyse des résultats : cas idéal

Pour chaque instance, on a commencé par établir le plus court chemin par un algorithme de
Dijkstra et puis nous avons calculé l’itinéraire dynamiquement en supposant que l'usager ne se
perdait pas pendant le trajet.
Les résultats obtenus sont présenté sur le Tableau 4. La première colonne représente les numéros
des différentes instances. Les colonnes 2 et 3 représentent les latitudes et longitudes respectivement
du point de départ et d’arrivée du trajet à effectuer. La colonne 4 représente le coût optimal ℎ* du
chemin en mètres obtenu par la résolution d’une méthode exacte (Dijkstra avec tas). La colonne 5
représente le coût en mètre de l’itinéraire obtenu par l’algorithme itératif développé lorsque
l’utilisateur suit parfaitement l’itinéraire indiqué. La colonne 6 représente l’erreur relative en
pourcentage du résultat de la colonne 5 par rapport à celui de la colonne 4. La colonne 7 représente
le nombre d’itérations de l’algorithme nécessaires pour atteindre la destination.
On peut constater qu'en moyenne l’algorithme, de par son caractère dynamique, donne des
chemins qui sont à 5.50% du chemin optimal.
Remarquons dans un premier temps que les itinéraires sélectionnés ont un coût optimal de
l’ordre de 1 à 5 kilomètres et que la moyenne si situe autour de 2 kilomètres 500 soit un trajet
d’environ une heure pour un piéton moyen en milieu urbain. L’algorithme itératif fournit un itinéraire
en moyenne 5,62% plus long que celui obtenu par la méthode exacte ce qui représente sur ce trajet
de 2km500 un allongement d’environ 140 mètre et donc 3min de marche sur un trajet d’une heure. Il
peut donc être estimé, à priori, que dans une situation concrète il sera très peu contraignant pour un
piéton d’effectuer le chemin donné par l’algorithme itératif plutôt que le chemin le plus optimal.
Il est cependant nécessaire de s’intéresser maintenant aux résultats de façon plus individuelle.
On remarque alors que dans près de la moitié des instances (13 sur 27), la différence de longueur de
chemin avec l’optimum est nulle ou inférieur à 1% et dans la moitié des instances restantes (7 sur 27)
elle est supérieure à 10% atteignant jusqu’à 27%. Le pourcentage varie donc grandement selon les
50
positions de départ et d’arrivée.

Pour mieux comprendre pourquoi certaines valeurs sont si élevées, on va examiner le cas des
trois instances dont les résultats possèdent un l’écart à l’optimum important (les instances 2, 10 et
20). Comme le montre la Figure 53, le résultat de l’instance n°2 illustre parfaitement que dans
certains cas particuliers serpenter autour de la ligne en direction de la destination peut avoir un effet
négatif. En effet, le caractère itératif de l’algorithme tente à chaque itération de calculer un itinéraire
le plus proche possible de la droite qui relie le point de départ (position actuelle) et le point final du
trajet. Cela a pour effet d’empêcher l’algorithme d’établir un itinéraire passant par des points
intermédiaires éloignés de cette droite et d’induire un « effet escalier ». Ici sur la Figure 53, vu que le
nombre de liaisons entre la rue de la Pradelle et la rue de l’Oradou est très limité c’est un passage
qu’il vaut mieux contourner comme l’illustre le détour par le nord fait par l’itinéraire optimal.
Tableau 4 : Instances et résultats de référence
N° instance Point d’origine Point d’arrivée ℎ* ℎ(0%) Gap % Itérations

1 45,7581 3,1101 45,7780 3,0831 3629,80 3812,60 5,04 14
2 45,7792 3,1168 45,7580 3,0784 4509,11 5613,92 24,50 22
3 45,7848 3,1028 45,7746 3,0947 1639,40 1639,40 0,00 4
4 45,7890 3,0951 45,7704 3,1188 4047,20 4496,63 11,10 11
5 45,7780 3,1104 45,7884 3,0983 1866,19 1882,40 0,87 6
6 45,7751 3,0829 45,7710 3,0926 1245,82 1289,56 3,51 5
7 45,7701 3,0808 45,7801 3,1184 3278,60 3388,53 3,35 20
8 45,7821 3,0985 45,7636 3,1078 2737,98 2737,98 0,00 7
9 45,7705 3,0656 45,7651 3,0769 1525,79 1699,48 11,38 6
10 45,7819 3,1027 45,7647 3,0974 2417,21 3079,71 27,41 8
11 45,7590 3,1159 45,7856 3,0735 5440,46 5659,44 4,03 20
12 45,7789 3,0836 45,7823 3,1019 1789,43 1943,73 8,62 8
13 45,7890 3,1001 45,7707 3,0757 3383,98 3741,73 10,57 14
14 45,7683 3,1066 45,7816 3,1239 2750,92 2770,76 0,72 8
15 45,7645 3,1053 45,7812 3,0903 2529,81 2529,81 0,00 7
16 45,7728 3,0727 45,7662 3,0680 1260,14 1260,14 0,00 3
17 45,7805 3,1001 45,7763 3,0770 2074,18 2137,08 3,03 12
18 45,7592 3,0841 45,7777 3,0703 2588,66 2588,66 0,00 8
19 45,7620 3,1248 45,7612 3,0934 3033,87 3094,42 2,00 12
20 45,7691 3,1079 45,7879 3,0997 3103,75 3703,95 19,34 7
21 45,7773 3,0907 45,7877 3,0861 1677,82 1682,47 0,28 4
22 45,7764 3,0713 45,7664 3,0796 1454,39 1454,39 0,00 5
23 45,7725 3,0936 45,7668 3,1143 2047,18 2373,95 15,96 9
24 45,7613 3,0906 45,7867 3,0788 3356,14 3356,14 0,00 10
25 45,7682 3,0893 45,7654 3,0984 1127,62 1127,62 0,00 5
26 45,7654 3,0892 45,7654 3,0882 884,33 884,33 0,00 1
27 45,7659 3,1079 45,7804 3,0874 2594,19 2594,19 0,00 13
moyenne 2518,30 2686,78 5,62 9,22
51
Figure 53 : Itinéraire associé à l’instance 2 effectué par un calcul itératif
Les résultats associés aux instances 10 et 20 dont les itinéraires sont illustrés respectivement
Figure 54 et Figure 55, sont aussi assujetties au problème du faible nombre de liaisons entre la rue de
la Pradelle et la rue de l’Oradou représenté par une bulle rouge sur les deux figures.
Ces deux cas se distinguent cependant de la précédente par le fait que le point d’arrivée et de
départ sont de part et d’autres de la voie de chemin de fer. Les passages à niveau au-dessus de la voie
de chemin de fer sont très espacés les uns des autres ; l’algorithme peut donc être amené à faire un
détour important pour traverser la voie afin de rester dans l’axe de direction fixé par la destination
plutôt que de la longer durant un certain temps comme l’optimum.
52
Ces trois cas permettent de montrer que l’algorithme est sensible aux zones de faible densité
routière que cela soit dû à un passage à niveau ou à la faible communication de deux boulevards. Il
faut noter que la traversée d’une ville par un fleuve ou une rivière engendre des situations similaires
à celle d’un chemin de fer et qu’un allongement de 27% sur des trajets de cet ordre, soit le cas le plus
pathologique rencontré, représente plus ou moins 15min de marche.
4.3 Analyse des résultats : cas avec aléas

Dans le but d'évaluer le comportement du système dans des conditions plus réalistes, on a simulé
plusieurs scénarios concernant des utilisateurs ayant une probabilité de se perdre à chaque
intersection de 1, 2, 5, et 10%. A chaque erreur, l’utilisateur parcourt un arc du réseau avant qu’un
calcul soit relancé. On peut supposer raisonnablement que dans la majorité des cas, lorsqu’un
utilisateur se perd à une intersection (donc un nœud), ce n’est pas en repartant par le même arc que
celui qu’il a emprunté pour arriver sur l’intersection. De même, à une intersection de plusieurs voies,
un utilisateur aura plus tendance à se perdre en prenant une voie proche de la direction de la
destination plutôt qu’une voie qui lui est opposée. Ces deux remarques ont donc été prises en
compte dans la simulation.
Lors de la modélisation des erreurs de cheminements dans le réseau routier, il a été considéré
qu'un choix par le piéton d'une rue erronée dépendait de la rue par laquelle il arrivait au carrefour et
que par exemple, la probabilité d'une erreur conduisant le piéton à faire demi-tour pouvait être
considéré comme négligeable.
Les probabilités d'erreur au différents embranchements, ont été calculé en fonction de l’angle
avec le vecteur pointant vers la destination, mesuré de 0 à 180 degrés, et sont affectées d’un poids de
1 à 11 suivant la formule suivante : 1 + ((180 − 𝑎𝑛𝑔𝑙𝑒)/180) ∗ 10) .
Pour chaque paramétrage, c’est-à-dire, pour chaque couple de points sélectionnés et pour chaque
probabilité de se perdre, 100 scénarios ont été effectués. Le Tableau 5 ci-dessous représente la
moyenne sur l’ensemble des couples sélectionnés et sur l’ensemble des scénarios joués des différentes
valeurs auxquelles on va s’intéresser.
53
Tableau 5 : Bilan des résultats
Coût GAP % Distance ajoutée Ecart type Itérations Erreurs

ℎ* 2518,30 - - - 1 -
ℎ(0%) 2686,78 5,62 - - 9,22 -
ℎ̅ (𝑥, 1%) 2704,57 6,32 17,79 58,87 9,39 0,24
ℎ̅ (𝑥, 2%) 2725,76 7,18 38,98 88,18 9,55 0,51
ℎ̅ (𝑥, 5%) 2783,59 9,49 96,81 139,47 10,12 1,26
ℎ̅ (𝑥, 10%) 2896,78 13,96 210,00 206,35 11,20 2,67
Les deux premières lignes sont les moyennes sur les 27 instances des données références relatives à
l’itinéraire optimal ℎ* et à l’itinéraire obtenu de façon itérative sans erreur de l’utilisateur ℎ(0%). Les
quatre lignes suivantes sont des estimateurs ℎ̅ de la moyenne sur les 27 instances des données relatives
aux cas où l’utilisateur s’égare à chaque intersection avec une probabilité de 1, 2, 5 et 10%. Ces
estimateurs sont basés sur la moyenne empirique des données associées aux 100 scénarios effectués sur
chacune instance et représentés par le vecteur d’évènements aléatoires x. La première colonne indique le
coût moyen des itinéraires obtenus en mètres. La deuxième colonne indique le taux moyen d’erreurs en
pourcentage par rapport à l’optimal. La troisième colonne indique la distance moyenne ajoutée en mètres
par rapport au parcourt sans erreurs. La quatrième colonne indique l’écart type moyen en mètres des
coûts d’itinéraires (pour chaque instance un écart type est calculé sur les 100 scénarios joués). La
cinquième colonne indique le nombre moyen d’itérations de l’algorithme pour atteindre la destination. La
sixième colonne indique le nombre moyen d’erreurs que le piéton a commises pour arriver à destination.
Dans un premier temps pour justifier ces choix de probabilité, entre 1 et 10% de chance de se perdre
par intersection, il faut s’attarder sur la dernière colonne. On peut alors remarquer qu’avec la probabilité
d’1%, le piéton fait en moyenne une erreur pour quatre trajets de 2km500 ce qui représente plus ou
moins la probabilité qu’un utilisateur se voit bloquer l’accès à une rue dû à des travaux publics ou un
accident par exemple. D’autre part avec une probabilité de 10%, le piéton fait pratiquement trois erreurs
par trajet d’une heure, ce qui correspond à un piéton plutôt distrait. On a donc un éventail raisonnable de
scénarios en choisissant les probabilités de s’égarer entre 1 et 10%. On rappelle que le but de cette
analyse est d’établir certaines tendances du comportement de l’algorithme et donc cette partie sera
l’objet de plusieurs approximations raisonnables.
Par un rapide calcul, on s’aperçoit que la distance ajoutée par rapport au parcours sans erreur et le
nombre d’itérations nécessaires pour atteindre l’optimum sont proportionnelles au nombre d’erreurs faîte
sur le parcours. Ceci est parfaitement logique étant donné qu’à chaque erreur d’itinéraire un recalcule est
déclenché et le chemin est dans la quasi-totalité des cas allongé. Ce qui par contre plus intéressant est le
coefficient de proportionnalité entre ces différentes grandeurs ; le nombre d’itérations ajoutées est
d’environ trois pour quatre erreurs respectivement pour les quatre probabilités de 70,8%, 64,7%, 71,4%,
74,15%. Ce coefficient est dû à plusieurs causes. Premièrement le piéton a progressé une partie du chemin
avant de se perdre, il est donc logique que le coefficient soit inversement proportionnel à la portion de
l’itinéraire effectué avant de se perdre. En effet si le piéton parcourt à chaque fois une grande partie de
l’itinéraire avant de se perdre et de déclencher un recalcule, le nombre d’itérations nécessaires ne sera
que très peu augmenter alors que si l’utilisateur se perd dès la première intersection à chaque fois le
nombre de recalcule sera approximativement le nombre d’erreurs survenues. Donc pour connaître la
proportion entre le nombre d’itérations supplémentaires nécessaires et le nombre d’erreurs, il suffit de
connaître la proportion moyenne du chemin parcourue avant chaque déclenchement d’erreur tout en
prenant en compte le malus accordé par le parcours de l’arc sur lequel on s’égare ; on sait en effet qu’en
moyenne on allonge le parcours effectué en n’empruntant pas l’arc désigné par l’algorithme du fait que la
distance ajoutée est proportionnelle au nombre d’erreurs.
On peut estimer parcourir environ 27 intersections en moyenne sur des chemins de 2km500 étant
54
donné le taux d’erreurs pour la probabilité d’1% qui est bien inférieur à 1 (0,24) ; en effet la première
intersection a 99% d’être atteinte sans erreur mais la 27ème n’aura que 76% de chance (0,9927), soit 24%
de chance de s’être trompé au moins une fois que l’on approxime au fait qu’il y a 0.24 erreurs en moyenne
par chemin. On précise bien que cette approximation n’est valable uniquement car on suppose la
probabilité d’avoir plus d’une erreur par chemin négligeable. Il faut en moyenne un peu plus de 9
itérations pour parcourir ces 27 intersections, soit une moyenne d’environ trois intersections par
itérations.
Pour une probabilité d’1%, sur trois intersections, on peut considérer les chances qu’une erreur
intervienne est équiprobable à chaque intersection comme le montre Figure 56 où une erreur à la
troisième intersection n’a que 2% de chance de moins de se produire qu’à la première. On peut donc
estimer que l’erreur surviendra en moyenne au milieu du parcours. Et donc le fait que le ratio entre le
nombre d’itérations ajoutées et le nombre d’erreurs survenues soit d’environ trois pour quatre (70,8%) est
en majeur partie dû à l’éloignement causé par les arcs empruntés en cas d’erreurs.
Figure 56 : Arbre de probabilité sur trois intersections pour 1%
Pour une probabilité de 10% par contre, sur trois intersections, la différence entre la troisième et la
première sont non-négligeable comme l’illustre la Figure 57. En effet le piéton a 19% de chance de moins
de se perdre à la troisième intersection plutôt qu’à la première ; si une erreur survient il y a alors 36,9%
que ce soit au niveau de la première intersection, 33,2% que ce soit au niveau de la deuxième 29,9% que
ce soit au niveau de la troisième.
On voit bien cependant que le ratio de 74,15% est là encore en majeur partie dû à l’éloignement causé
par les arcs empruntés en cas d’erreurs cependant il est normal de voir un pourcentage plus élevé dans le
cas de 10% plutôt que dans le cas de 1%. Il faut alors noter que la valeur pour 2% (64,70%) devrait se
trouver légèrement au-dessus de celle de 1% (70,8%) ce qui rend bien compte de l’incertitude des
données malgré le fait que chacun de ces ratios se base sur plus de 2 700 calculs d’itinéraire (27*100).
Figure 57 : Arbre de probabilité sur trois intersections pour 10%
Pour conclure cette analyse, on s’intéresse au rapport de proportionnalité existant entre la distance
moyenne ajoutée par itinéraire et le nombre d’erreurs moyen qui est de 75 mètres par erreur ce qui
correspond à la longueur moyenne d’un arc ; ce qui veut dire qu’en moyenne le chemin issu d’un sommet
sur lequel le piéton se perd est de même longueur que le chemin issu du sommet précédent comme
l’illustre la Figure 58 et donc que l’angle formé par la direction de la destination et l’arc vers le point erroné
est en moyenne inférieur à 90°, vu que le triangle moyen formé par le point destination et les deux
sommets est isocèle. Ceci est surement dû au fait que le piéton favorise la direction de la destination pour
se perdre et a pour effet direct que le piéton n’allonge que très peu l’itinéraire à chaque erreur.
55
Figure 58 : Allongement moyen d’un itinéraire par une erreur
Pour résumer cette analyse aura permis de mettre en évidence : les différents cas pathologiques pour
lesquels l’algorithme itératif fourni un résultat éloigné de l’optimum, et d’autre part, les subtilités des
relations entre les erreurs d’itinéraire et les différentes grandeurs caractéristiques de l’algorithme.
5. Conclusion
Ce chapitre a permis de se familiariser avec les algorithmes de plus court chemin ; une étude des
algorithmes existants les plus utilisés a été faite et a conduit à l’élaboration d’un algorithme de type
Dijkstra avec tas qui a été utilisé dans le dernier chapitre. Dans un second temps cet algorithme a été
modifié afin d’être utilisé dans une architecture client-serveur permettant le guidage d’un piéton en milieu
urbain. Cette architecture a eu deux principaux objectifs : celui de mieux comprendre les enjeux induits
par le fait de travailler dans un milieu urbain et sur des graphes de grande taille, et celui d’élaborer un web
service fonctionnel et une application Android. Le travail sur les tournées de véhicules qui a été effectué
dans le chapitre suivant, utilise comme prétraitement, l’algorithme de plus court chemin qui a été
proposé, afin d’obtenir un tableau des plus courts chemins dans un graphe.
6. Références
*Bel58+ R. E., Bellman, On a Routing Problem, Quart. Appl. Math., Vol. 16(1), pp. 87-90, 1958.
*Chr79+ N. Christofides, A. Mingozzi, P. Toth. The vehicle routing problem. In Combinatorial
Optimization, John Wiley, vol. 11, pp. 315–338, 1979.
*Dij59+ E. W., Dijkstra, Note on Two Problems in Connexion with Graphs, Numerische Mathematik,
vol. 1, pp. 269–271, 1959.
*Dor03+ D. Wagner and T. Willhalm. Geometric Speed-Up Techniques for Finding Shortest Paths in
Large Sparse Graphs. Konstanzer Schriften in Mathematik und Informatik.ISSN 1430–3558.
Nr. 183, Januar 2003.
*Dor05+ D. Wagner, T. Willhalm and C. Zaroliagis. Geometric Containers for Efficient Shortest-Path
Computation. ACM Journal of Experimental Algorithmics, Vol. 10(1.3), pp. 1-30. 2005
*Dre69+ S. Dreyfus. An appraisal of some shortest-path algorithms. Operations Research, vol. 17(3),
pp. 395–412, 1969.
*Gub10+ A. Gubichev, S. Bedathur, S. Seufert and G. Weikum. Fast and Accurate Estimation of
56
Shortest Paths in Large Graphs. CIKM’10, October 26–30, 2010, Toronto, Ontario, Canada.
*Guz89+ J, Guzolek and E. Koch Real-time route planning in road network. Proceedings of VINS,
September 11–13, 1989. Toronto, Ontario, Canada, p. 165–9.
*Har68+ P. E. Hart, A Formal Basis for the Heuristic Determination of Minimum Cost Paths, IEEE
Transactions on Systems Science and Cybernetics SSC4, vol. 4(2), pp. 100–107, 1968.
*Nil71+ J., Nilsson, Problem-solving methods in artificial intelligence. New York: McGraw-Hill; 1971.
*Pea84+ J., Pearl, Heuristics: intelligent search strategies for computer problem solving. Addison-
Wesley Publishing Company; 1984.
*Ren12+ L. REN, Conception et évaluation d’outils décisionnels pour des systèmes réactifs d’aide à la
mobilité, PhD thesis, Université Blaise Pascal, Clermont-Ferrand, 2012.
*War62+ S., Warshall Theorem on Boolean Matrices, J. ACM, vol. 9, pp. 11–12, 1962.
*Wil05+ T. Willhalm. Engineering Shortest Paths and Layout Algorithms for Large Graphs.
Dissertation der Universität Fridericiana zu Karlsruhe (TH). 2005.
57
CHAPITRE 3
Etude du HVRP dans
un contexte mobile
L’objectif de ce chapitre est de proposer une méthode de résolution des problèmes de

tournée de véhicules de type HVRP (Heterogeonous Vehicle Routing Problem) dans un
contexte mobile. Le HVRP est une extension du problème de VRP. La méthode proposée est
originale car elle se base sur une métaheuristique qui exploite une approche de type Path
relinking pour diversifier la recherche. L’originalité de l’approche vient aussi du fait que
l’algorithme de Path Relinking est défini sur l’espace des tours géants et non sur l’espace des
solutions.
La première partie de ce chapitre est consacrée à la présentation du problème et des
différentes méthodes de résolution existantes. Ensuite le schéma général de la
métaheuristique développée ainsi que ces différents éléments sont détaillés. Enfin les
résultats de la métaheuristique sur les instances classiques de la littérature et sur des
réseaux urbains sont exposés dans la dernière partie de ce chapitre.
1. Problème du type HVRP

1.1 Présentation du HVRP
Définition
Le problème de type HVRP, initialement décrit par *Gol84+, est une variante du problème de VRP
et il appartient donc à la famille des problèmes NP-difficiles. Cette variante du problème de tournées
de véhicules a été introduite afin de prendre en compte une flotte de véhicules hétérogènes c’est-à-
dire ayant des coûts d’utilisation différents.
Un problème de HVRP, comme un problème de VRP, se compose d’un ensemble de clients qui ont
chacun une demande. Les véhicules dont on dispose pour effectuer les tournées sont, contrairement
au VRP, en nombre limité d’une part et de capacités de chargement et de coûts différents d’autre
part. Le problème consiste toujours à trouver un ensemble de tournées respectant la capacité du
véhicule qui est attribué à la tournée permettant de desservir tous les clients à coût minimal.
Modélisation sous forme de graphe
On peut modéliser une solution du problème de type HVRP par une liste de tournées présentée
sous la forme d’un graphe comme illustré par la Figure 59 dans lequel le dépôt et les clients sont
représentés chacun par un nœud et où un arc entre deux clients symbolise l’ordre de passage du
véhicule et la distance qui les sépare. A chaque tournée est associé un coût fonction du véhicule
utilisé et de la distance parcourue.
59
Chapitre 3 : Etude du HVRP dans un contexte mobile
Figure 59 : Solution d’un problème de HVRP
Pour établir une formulation du problème de HVRP, on peut reprendre celle de Fisher et Jaikumar
en 1981 *Fis81+ du problème de VRP et adapter certaines contraintes afin de prendre en compte la
flotte hétérogène de véhicules de la façon suivante :
Min ∶ z = ∑M k k n
k=1 C u ∑i=0 ∑nj=0 cijk xijk (1)
∑ni=1 di yik ≤ Qk , ∀ k ∈ (1, . . , M) (2)

∑M k
k=1 yi =1 , ∀ i ∈ (1, . . , n) (3)
k
∑M
k=1 u ≤M (4)
∑ni=1 xijk = yjk , ∀ j ∈ (1, . . , n) , ∀ k ∈ (1, . . , M) (5)
∑nj=1 xijk = yik , ∀ i ∈ (1, . . , n) , ∀ k ∈ (1, . . , M) (6)
∑i,j∈ S xijk ≤ |S| − 1 , ∀ S ⊂ V; 2 ≤ |S| ≤ n − 2 , ∀ k ∈ (1, . . , M) (7)
xijk ≤ uk , ∀ i ∈ (1, . . , n) , ∀ j ∈ (1, . . , n) , ∀ k ∈ (1, . . , M) (8)
xijk ∈ *0,1+ , ∀ i, j ∈ V ; i ≠ j , ∀ k ∈ (1, . . , M) (9)
yik ∈ *0,1+ , ∀ i ∈ V , ∀ k ∈ (1, . . , M) (10)
60
uk ∈ *0,1+ , ∀ k ∈ (1, . . , M) (11)
où 𝑉 est l’ensemble des arcs du graphe complet constitué des clients et du dépôt.
𝑘
𝑥𝑖𝑗 : indique si j est immédiatement visité après i dans la tournée k.
𝑘
𝑦𝑖 : est égale à 1 si le véhicule k effectue le service chez le client i si non 0. L’indice i=0
correspond au dépôt.
𝑢𝑘 : est égale à 1 si le véhicule k est utilisé.
𝑘
𝑐𝑖𝑗 : est le coût de l’arc (i,j) pour le véhicule k.
𝑘
𝐶 : est le coût fixe associé à l’utilisation du véhicule k.
𝑑𝑖 : est la demande du client i.
𝑛 : est le nombre de clients.
𝑀 : est le nombre de véhicules.
𝑄 𝑘 : est la capacité du véhicule k.
Dans ce problème, la contrainte 2 vérifie que la capacité de chargement de chaque véhicule est
bien respectée. La contrainte 3 permet de vérifier que chaque client est desservi. La contrainte 4
permet de vérifier que l’on construit au plus M tournées. Les contraintes 5 et 6 assurent la cohérence
entre la visite d’un client par un véhicule k et l’appartenance de ce client à la tournée k. La
contrainte 7 a pour but d’éviter la formation de sous-tours au sein des tournées. La contrainte 8
assure que chaque véhicule qui assure la livraison auprès d’au moins un client est considéré comme
utilisé.
1.2 Etude sur les méthodes de résolution existantes

Comme le souligne C. Prins dans son article *Pri09+, Les problèmes de tournée de véhicules avec
une flotte hétérogène sont, contrairement aux problèmes de VRP, très peu présents dans la
littérature depuis leur première apparition en 1984 dans un article de Golden et al. *Gol84+. Ces
problèmes sont scindés en quatre catégories :
 Les problèmes de type VFMP-F (Vehicle Feet Mix Problem with Fixed costs) où l’on a à notre
disposition un certain nombre de types de véhicule caractérisés par une capacité et un coût fixe
d’utilisation mais où le coût par unité de distance parcourue est commun. De plus le nombre de
véhicules de chacun des types n’est pas limité.
 Les problèmes de type VFMP-V (Vehicle Feet Mix Problem with Variable costs) où l’on a à notre
disposition un certain nombre de types de véhicule caractérisés par une capacité et un coût par
unité de distance parcourue mais où le coût fixe par camion est identique à tous les camions. De
plus le nombre de véhicules de chacun des types n’est pas limité.
 Les problèmes de type VFMP-FV (Vehicle Feet Mix Problem with Fixed and Variable costs) où l’on a
à notre disposition un certain nombre de types de véhicule caractérisés par une capacité, un coût
fixe d’utilisation et le coût par unité de distance parcourue. De plus le nombre de véhicules de
chacun des types n’est pas limité.
 Les problèmes de type HVRP auxquels on s’intéresse dans ce chapitre. Ce problème se différencie
du VFMP-FV par le fait que le nombre de véhicules de chacun des types est limité.
L’article de Golden et al. *Gol84+ propose 20 instances du problème de VFMP-F : 12 instances de
petites tailles (de moins de 30 clients) et 8 instances de grande taille (plus de 50 clients). Les 8 plus
grandes instances ont ensuite été modifiées par Taillard *Tai99+ afin de fournir des instances de
VFMP-V et de HVRP. Ces instances sont utilisées par la plupart des travaux publiés dans ces domaines
comme instances de références. Parmi les résultats publiés sur ces instances certains articles traitent
61
de plus d’un type de problème avec la même méthode. Les principaux articles sur le sujet et se
basent sur les instances de Golden et sont référencés dans l’article *Pri09+. Le Tableau 6 ci-dessous
précise quels sont les instances utilisées dans chacun des cas.
Tableau 6: Méthodes publiées utilisant les instances de Golden et al. référencées par *Pri09+
Taillard a été le premier à s’intéresser à la résolution du HVRP dans son article de 1999 *Tai99+. Il
utilise pour se faire une heuristique de résolution approchée basée sur le principe de la génération de
colonne qui repose sur l’idée de relaxer le programme linéaire associé au problème en ne prenant en
compte qu’une partie des variables puis en réinjectant progressivement les variables susceptibles de
faire varier la solution obtenue.
Tarantilis a, quant à lui, développé un algorithme TA (Threshold Accepting) *Tar04+ qui autorise
donc la recherche local à détériorer temporairement la solution avec un certain seuil d’acceptation
afin de diversifier la recherche.
Li et al. dans leur article *Li07+ ont utilisé un algorithme de type record-to-record dont la
recherche locale consiste à explorer l’espace(sans rechercher forcément une amélioration), au
voisinage des solutions qui sont raisonnablement peu éloignées (en coût) de la meilleure solution
trouvée.
A ces trois articles référencés dans le Tableau 6, il faut bien sûr ajouter celui de C. Prins *Pri09+ qui
propose deux méthodes de résolutions du HVRP basées sur un algorithme génétique et une
recherche locale intensive. Il faut également citer plusieurs articles qui ont été écrit après celui de C.
Prins en 2009.
Pessoa et al. *Pes09+ en 2009 ont élaboré la première méthode de résolution exacte du HVRP
pour des instances allant jusqu’à 75 clients basée sur un algorithme de BCP (Branch-Cut-and-Price)
qui consiste à diviser le problème principale en sous-problèmes et à résoudre chacun des sous-
problèmes susceptible de contenir la solution optimale par une méthode de génération de colonnes.
Baldacci et Mingozzi *Bal09+ en 2009 ont élaboré une seconde méthode de résolution exacte
permettant de résoudre certaines instances allant jusqu’à 100 clients basée sur un algorithme de SP
(Set Partitioning) utilisant des bornes fixées par une relaxation linéaire et lagrangienne du problème.
Ces deux méthodes de résolution exactes sont cependant extrêmement lentes sur des problèmes de
moyenne taille et ne sont pas adaptées à la résolution d’instances de grande taille.
C. Duhamel et al. *Duh10+ en 2010 ont développé une métaheuristique de type GRASP-ELS basé
sur une procédure de split évoluée.
Enfin A. Subramanian et al. *Sub12+ en 2012 ont formulé le problème sous forme d’un problème
de Set Partitioning qu’ils ont résolu par une méthode de recherche locale itérative (ILS).
2. Métaheuristique proposée basée sur un Path-Relinking

La métaheuristique proposée pour résoudre des problèmes de type HVRP est un algorithme
62
évolutionnaire qui utilise donc un ensemble de solutions afin de donner la meilleure solution
possible. L’algorithme est décrit dans cette partie à travers son schéma général et l’explication
détaillée des principales parties qui le composent.
De même que l’algorithme GRASP/ELS présenté dans le deuxième chapitre, cette méthode se
base sur les tours géants comme représentation indirecte de la solution. Comme pour le VRP, la
construction de la fonction de mapping (le Split) permettant de passer de l’espace de codage à
l’espace des solutions autorise plusieurs tours géants à obtenir la même solution. Cependant,
contrairement au cas du VRP, la fonction de mapping du HVRP peut donner plusieurs solutions. La
fonction de mapping associée au HVRP est alors de type n-to-n illustré Figure 60. L’élaboration de
cette fonction est décrite en détail dans la deuxième section de cette partie.
n-to-n mapping
Figure 60 : Fonction de mapping du HVRP
2.1 Schéma général de la méthode implémentée

La méthode proposée est constituée de deux phases principales illustrée sur la Figure 61
naviguant entre l’espace de codage et l’espace des solutions :
Début de
la méthode
Ajout de nouvelles
solutions Intensification
Diversification Suppression
randomisé d’éléments Fin de la
méthode après
n ittération
Figure 61 : Schéma général de la méthode
 Une partie dite de diversification de la population qui consiste à générer de nouvelles solutions
de façon aléatoire afin d’élargir le champ de recherche au maximum. Elle s’exécute en deux sous-
étapes. D’une part, une partie des solutions de la population est supprimée de façon randomisée
en fonction de leur qualité respective. D’autre part on procède à une injection de solution dans la
population illustrée sur la Figure 62 qui consiste à construire par la méthode des plus proches
63
voisins un tour géant et lui appliquer une heuristique d’obtention de solutions décrite dans la
section 3 de cette partie puis enfin à intégrer les solutions obtenues dans la populations.
Plusieurs
solutions
Méthode des plus

proches voisins
it
Sp l Recherche
locale
Solutions
améliorées
Tour géant
généré 1 5 3 4 2 6
Ajout des
solutions à la
population
Population des
solutions
Figure 62 : Ajout de solutions (diversification)
 Une partie dite d’intensification de la recherche illustrée sur la Figure 63 qui consiste en une
recherche approfondi autour des solutions de la population. Pour se faire plusieurs solutions de
la population sont retranscrites dans l’espace de codage afin de croiser leur tour géant associé
par une méthode de Path-Relinking générant ainsi de nouveaux axes de recherche proches des
solutions croisées et donc couvrant au maximum les solutions proches de très bonnes solutions
déjà mises en évidence lors des précédentes recherches locales. Pour chaque tour géant généré
l’algorithme de Split est appliqué et une recherche locale est alors effectuée sur les solutions
trouvées. La population est ensuite mise-à-jour avec les meilleures solutions parmi celles déjà
contenues dans la population et les nouvelles solutions issues des recherches locales.
64
Plusieurs
solutions
t
Sp l i
Recherche
Ensemble de locale
tours géants Solutions
1 5 2 4 3 6
obtenus améliorées
2 6 3 4 1 5
1 6 3 4 2 5
Ajout des
solutions à la
Path-Relinking population
Tours géants à Population des

croiser solutions
1 5 3 4 2 6
2 6 1 4 3 5 Sélection de
deux
Con Solutions à solutions
cate
nati croiser
on
Figure 63 : Etape d’intensification
2.2 La méthode Split

Le principe du Split est de construire itérativement la façon optimale de découper un tour géant
en tournées réalisées par les différents véhicules à notre disposition. Le principe de base du Split
appliqué au problème de type HVRP reste très similaire à celui détaillé dans le cas du VRP dans le
chapitre deux. On ne s’intéressera donc dans cette partie qu’aux particularités qu’on lui a apportées
afin de rester efficace dans le cadre du HVRP. Afin de clarifier les explications, on va illustrer les
modifications nécessaires au fonctionnement d’un algorithme pour le HVRP par rapport à celui
implémenté pour le VRP à travers un exemple simple.
Présentation de l’exemple et premières modifications de l’algorithme :
L’exemple proposé est composé de 4 clients à desservir dont les demandes sont présentées dans
le Tableau 7, et de 3 véhicules pour effectuer les tournées qui ont chacun une capacité et un coût
différent présentés dans le Tableau 8. On note que choisir seulement un coût variable et non un coût
fixe pour chaque véhicule est suffisant pour rendre l’exemple traité pertinent. On va de plus poser
pour obtenir un exemple la plus clair possible que toutes les distances entre deux clients ou entre un
client et le dépôt sont de 1 unité de distance.
Tableau 7 : Demandes des clients du tour géant de Tableau 8 : Liste des véhicules disponibles de
l’exemple du Split l’exemple du Split
Véhicules 1 2 3
Clients du TG 1 2 3 4
Capacités 9 5 3
Demandes 3 3 4 2
Coût par unité de distance 1 2 3
65
Pour que l’algorithme split soit applicable, il faut bien sûr que chacune des tournées soit
identifiée non seulement par les clients qui la composent mais aussi par le véhicule qui l’effectue ce
qui induit pour chaque tournée un choix de véhicule en fonction de sa capacité, de son coût et de sa
disponibilité. Tous les véhicules disponibles et de capacité suffisante devront donc être testés pour
chaque tournée. On se tiendra, dans un premier temps, à ses simples modifications de l’algorithme
pour résoudre notre exemple afin de mettre en évidence la principale modification qui sera
nécessaire à l’optimalité de la méthode.
Déroulement de l’algorithme :
Afin de présenter cet exemple de manière concise, on ne va détailler que les trois premières
itérations de l’algorithme sous la forme d’un graphe de façon similaire à l’exemple traité pour le VRP.
Chaque arc représente donc une tournée. Sur chaque arc figure un couple de valeur
correspondant respectivement au véhicule de la tournée et au coût de la tournée. A chaque nœud 𝑖
est associé le coût pour desservir les 𝑖 premiers clients du tour géant.
La première étape illustrée par la Figure 64, consiste à desservir le client 1. Les trois véhicules
étant disponibles et de capacité suffisante, on compare donc pour chacun d’entre eux le coût
nécessaire pour faire l’aller-retour entre le premier client et le dépôt. Le coût est minimal (2) en
effectuant la tournée avec le véhicule 1.
Figure 64 : Première itération du Split pour HVRP
La deuxième étape illustrée par la Figure 65 consiste à établir les tournées comprenant le client 1
et 2. Seul le véhicule 1 est assez volumineux pour desservir les deux clients (de capacité 9 > 3 +3). Un
coût de 3 est alors attribué au nœud 2 correspondant aux déplacements effectués : (dépôt;client 1) +
(client 1;client 2) + (client 2;dépôt).
Figure 65 : Deuxième itération du Split pour HVRP
La troisième étape consiste à établir les tournées contenant les clients 1 2 et 3 cependant aucun
des véhicules n’est assez volumineux pour desservir les trois clients. L’algorithme passe donc aux
tournées commençant par le client 2.
On commence donc cette fois par évaluer les tournées comprenant uniquement le client 2
sachant que le véhicule 1 est donc assigné à la tournée constituée uniquement du client 1. Comme
l’illustre la Figure 66 Les véhicules 2 et 3 sont éligibles à effectuer la tournée. Le véhicule 2 est celui
des deux qui possède le coût le plus faible cependant le coût de cette tournée (4) ajouté à celle de la
première tournée constituée du client 1 (2) et supérieure au coût de la tournée qui dessert le client 1
et 2 avec le véhicule 1. Aucune des tournées ne prenant uniquement le client 2 n’est donc prise en
66
compte.
Figure 66 : Troisième itération du Split pour HVRP
On continue de faire fonctionner l’algorithme ; aucun véhicule disponible ne peut contenir le

client 2 et 3, l’algorithme passe donc aux tournées commençant par le client 3. Le véhicule 2 est
choisi pour effectuer la tournée constituée uniquement du client 3. Aucun véhicule disponible ne
peut desservir les clients 3 et 4 dans la même tournée. L’algorithme passe aux tournées commençant
par le client 4 où l’on choisit le seul véhicule disponible, le 3, pour effectuer la tournée constituée du
client 4. A la fin de l’algorithme on obtient donc la solution présentée Figure 67 constituée de trois
tournées et de coût égal à 13.
Figure 67 : Fin du Split pour HVRP et solution associée
Solution optimale et analyse :

En analysant la solution obtenue, on se rend compte qu’en prenant le véhicule 2 pour effectuer
une tournée constituée uniquement du client 1, on peut alors faire rentrer les trois autres clients
dans le véhicule 1 et ainsi trouver une meilleure solution comme l’illustre la Figure 68 n’utilisant que
deux des trois véhicules.
67
Figure 68 : Solution optimale de l’exemple d’HVRP
L’algorithme tel qu’il est n’est donc pas optimal. Il peut même ne trouver aucune solution alors
que plusieurs existent comme on peut le remarquer en ajoutant un cinquième client de demande
égale à 2 à notre exemple. Selon la figure 7, une solution existe du fait que le véhicule 3 n’est pas
occupé et qu’il est de capacité suffisante. Cependant l’algorithme ne trouverait aucune solution. Ce
problème vient du fait que les véhicules sont disponibles en quantité limitée. En effet, l’algorithme
choisi à chaque itération le véhicule le moins couteux. Cependant, il n’est pas trivial qu’il soit plus
judicieux d’utiliser les camions les moins couteux au début de l’algorithme comme l’illustre
parfaitement l’exemple proposé.
La solution est donc, plutôt que de sauvegarder à chaque nœud uniquement la meilleure solution
à priori, de sauvegarder toutes les solutions qui ont une chance de mener à la solution optimale pour
le nœud final. Seules les solutions complètements dominées ne sont alors pas prises en compte ; par
exemple, si deux solutions utilisent la même flotte de véhicules seule la moins coûteuse sera
sauvegardée, de même si la plus coûteuse ne possède aucun véhicule libre non possédé par la moins
coûteuse.
L’algorithme une fois effectué peut alors proposer plusieurs solutions sur le dernier label qui sont
en partie ou toutes intéressantes à conserver pour l’étape de recherche locale étant donné que ces
solutions n’utilisent pas la même composition de véhicules.
Optimisation en temps et en espace de l’algorithme :
Conserver autant de labels sur chaque nœud du graphe de l’algorithme peut rendre le split
extrêmement coûteux en espace et en temps.
En effet, un coût total, un tableau indiquant le nombre de véhicules disponibles pour chacun des
types, l’indice correspondant au premier client de la tournée et l’indice du label père. Cet espace
nécessaire est à multiplier le nombre de labels de chacun des nœuds qui débute sur le premier nœud
par le nombre de types de véhicule à disposition de capacité supérieur à la demande du premier
client du TG puis augmente de façon exponentielle à chaque nœud sur lesquels une nouvelle tournée
est initiée en fonction du nombre de types de véhicule alors disponibles. Un label arrête d’être
propagé au nœud suivant et donc le nombre de labels diminue lorsque plus aucun des véhicules
disponibles ne peut traiter la demande du client suivant.
D’autre part, comparer deux labels revient à comparer le nombre de véhicules disponibles pour
chaque type de véhicule du problème et le coût total. Ce temps nécessaire à une comparaison est à
prendre en compte à chaque fois qu’un nouveau label potentiel doit être comparé aux labels déjà
présents pour un nœud traité.
Afin de réduire le coût en espace et en temps de l’algorithme du split, il est alors judicieux de
réduire le nombre de comparaisons de labels et le nombre de labels par nœud au maximum sans
pour autant perdre les solutions intéressantes. Pour se faire, un pré-calcul est effectué avant de
démarrer le split afin d’associer à chaque nœud un coût minimal pour traiter les clients restants et de
68
ne comparer un label par rapport aux autres, durant l’algorithme, que s’il est suffisamment bon en lui
ajoutant la valeur pré calculée (inférieur au coût de la meilleure solution connue auquel on ajoute un
pourcentage d’incertitude). Cette borne inférieure du coût est calculée en supposant que l’on dispose
en quantité non limité d’un véhicule dont la capacité est le maxima parmi celles présentes dans la
flotte de véhicules et dont le coût fixe et le coût variable sont les minimas parmi ceux présents dans
la flotte de véhicules. De plus la distance entre le dépôt et les clients n’est prise en compte pour ce
coût minimal que lors du retour de la dernière tournée afin de s’assurer de bien être inférieur en tout
cas à la valeur optimale à partir du nœud traité. L’algorithme ainsi optimisé est décrit dans
l’algorithme 5 ci-dessous
Algorithme Split pour HVRP [Duh10] :
Données :
- n : nombre de clients
- t : nombre de types de véhicule
- 𝑞 : vecteur de taille n où pour tout i de 1 à n, 𝑞𝑖 est la demande correspondante
au client i.
- 𝑐 : matrice de taille (n+1,n+1) où pour tout i,j de 0 à n, 𝑐𝑖𝑗 correspond à la
distance de i à j où l’indice 0 correspond au dépôt et l’indice k de 1 à n
correspond au client k.
- 𝑊 : vecteur de taille n où pour tout i de 1 à t, 𝑊𝑖 est la capacité de chargement
d’un véhicule de type i.
- 𝐿 : distance maximum d’une tournée.
- 𝐹 : vecteur de taille t où pour tout i de 1 à t, 𝐹𝑖 est le coût fixe d’un véhicule de
type i.
- 𝑉 : vecteur de taille t où pour tout i de 1 à t, 𝑉𝑖 est le coût variable d’un véhicule
de type i.
- Borne_inf : vecteur de taille n où pour tout i de 1 à n, 𝐵𝑜𝑟𝑛𝑒_ inf𝑖 𝑒𝑠𝑡 la valeur pré-
calculée minimale pour finir de desservir les clients après le client i.
Variables :
- Label : vecteur de taille n où pour tout i de 1 à n, Labeli est la liste des labels
associée au nœud i.
- charge : variable permettant de vérifier qu’une tournée respecte la capacité d’un
véhicule.
- distance : variable permettant d’évaluer la distance de la tournée courante.
- coût : variable permettant d’évaluer le coût de la tournée courante en fonction d’un
type de véhicule choisi.
- coût_variable : variable qui prend la valeur du coût variable minimum parmi ceux des
différents véhicules durant la première étape de l’algorithme
- coût_fixe : variable qui prend la valeur du coût fixe minimum parmi ceux des différents
véhicules durant la première étape de l’algorithme
- capacité : variable qui prend la valeur de la capacité maximum parmi celles des
différents véhicules durant la première étape de l’algorithme
- nb_vehicule : variable temporaire utile dans la première partie de l’algorithme indiquant le
nombre de véhicules nécessaire pour desservir les clients.
- temp, stop, trop, échec : variables temporaires.
- Label_temp : label temporaire.
69
Algorithme 5 : Split pour HVRP

Sortie : Label
Début
coût_variable = Min(𝑉𝑖 ) ; coût_fixe= Min(𝐹𝑖 ) ;capacité = Max(𝑊𝑖 ) ;
Pour i de 1 à n-1 faire
nb_vehicule= 1
Borne_inf[i] = 0
temp = 0
Pour j de i à n-1 faire
Borne_inf[i]= Borne_inf[i]+ 𝑐𝑗,𝑗+1
temp= temp + 𝑞𝑖
Si temp > capacité alors
temp = 𝑞𝑖
nb_vehicule++
Fin si
Fin pour
Borne_inf[i]= Borne_inf[i]+ 𝑐𝑛,0
Borne_inf[i]= Borne_inf[i]* coût_variable + coût_fixe * nb_vehicule
Fin pour
Ajouter un label à 𝐿𝑎𝑏𝑒𝑙0 de coût 0
Pour i de 0 à n-1 faire
j = i + 1
stop=0
Tant que stop == 0 faire
Si i + 1 == j alors
distance = 𝑐0𝑗 + 𝑐𝑗0
charge = 𝑞𝑗
Sinon alors
distance = distance - 𝑐𝑗−1,0 + 𝑐𝑗−1,𝑗 + 𝑐𝑗,0
charge = charge + 𝑞𝑗
Fin si
échec = vrai
Pour chaque élément k de 𝐿𝑎𝑏𝑒𝑙𝑖 faire
trop = faux
Pour l de t à 1 avec un pas de -1 faire
Si trop == vrai faire sortir de la boucle pour Fin si
Si 𝐿𝑎𝑏𝑒𝑙𝑖,𝑘 possède un véhicule l disponible faire
Si 𝑊𝑙 > charge faire
échec = 0
coût = distance ∗ 𝑉𝑙 + 𝐹𝑙
coût total de Label_temp = coût total de 𝐿𝑎𝑏𝑒𝑙𝑖,𝑘 + coût
véhicules disponibles de Label_temp = véhicules
disponibles de 𝐿𝑎𝑏𝑒𝑙𝑖,𝑘
véhicules disponible de type l de Label_temp --
indice du label père de Label_temp = k
indice du nœud père de Label_temp = i
Si (coût total de Label_temp + Borne_inf_j)
< (coût meilleure solution connue du problème * un coefficient
d’incertitude supérieur à 1) faire
insérer Label_temp dans la liste Label_j
Sinon faire trop = vrai Fin si
Fin si
Fin pour
Fin pour
j ++
Si j > n ou échec == 1 faire stop = 1 Fin si
Fin tant que
Fin pour
Fin
70
2.3 Heuristique de génération de solutions

Dans le cas de problèmes, pour lesquels la capacité totale des véhicules de la flotte est proche de
la demande totale des clients, un tour géant obtenu à la suite de l’exécution d’une méthode de plus
proches voisins ne permet pas toujours de trouver une solution en n’utilisant que l’algorithme du
split. Or, contrairement aux instances traitées dans le cadre du VRP, les instances utilisées par les
articles référents sur le HVRP (instances de *Gol84+) possèdent des capacités totales proches des
demandes totales des clients.
L’heuristique proposée pour remédier à ce problème repose sur un principe simple : lorsque
l’algorithme split ne parvient pas à trouver un découpage, cela vient du fait qu’arriver à un certain
nœud l’algorithme ne possède plus de véhicule capable de contenir le client suivant. L’idée est alors
de déplacer ce client à une position plus en amont du tour géant jusqu’à ce que le split aboutisse à
une solution. Il s'agit d'une technique de "réparation" qui va modifier le tour géant.
Pour expliquer le fonctionnement de cette heuristique de façon simple, on a considère l’exemple
de la Figure 69 constitué de 4 clients à desservir et de 2 véhicules de types différents pour effectuer
les tournées. Aucun coût n’est pris en compte dans cet exemple car le but de l’algorithme et de
trouver des solutions et non de chercher les meilleurs possibles.
Tableau 9 : Demandes des clients de l’exemple de Tableau 10 : Liste des véhicules disponibles de
génération de solutions l’exemple de génération de solutions
Véhicules 1 2
Capacités 4 6
Demandes 2 5 1 2
Figure 69 : Données de l’exemple illustrant l’algorithme de génération de solutions pour HVRP
On illustre sur la Figure 70 les deux possibilités de faire évoluer le Split ; c’est-à-dire, en débutant
par le véhicule 1 ou par le véhicule 2. On remarque qu’aucune des deux possibilités ne permet de
desservir la totalité des clients. En effet, on a deux possibilités pour desservir le client 1 en choisissant
(le véhicule 1 ou 2). Ensuite aucun des deux véhicules ne peut prendre en charge la capacité des
clients 1 et 2 dans la même tournée. En partant du label où le client 1 est desservi par le véhicule 1, le
véhicule 2 reste disponible et peut effectuer la livraison du client 2. Le véhicule 2 peut prendre en
charge le client 2 et 3 dans la même tournée ce qui le remplira complètement et donc ce nouveau
label associé au nœud 3 ne se propagera pas. D’autre part, en partant du label où le client 1 est
desservi par le véhicule 2, seul le véhicule 1 est disponible mais il ne dispose pas de la capacité
suffisante pour contenir la demande du client 2 l’algorithme s’arrête donc complètement avec deux
labels sur le nœud 1, un label sur le nœud 2 et un label sur le nœud 3.
71
Client 1 2 3 4
Demande 2 5 1 2
Possibilité 1 Possibilité 2
Véhicule 1 : Véhicule 2 : Véhicule 2 : Véhicule 1 :

1 2 3 1
Volume 2/4 Volume 6/6 Volume 2/6 Volume 4/4
Figure 70 : Déroulement de l’algorithme split sur le tour géant initial
Etant donné qu’aucune solution n’est trouvée, l’heuristique se met en marche afin de modifier le
TG jusqu’à ce qu’une solution soit mise en évidence.
L’indice du client associé au dernier label est donc 3 ; l’algorithme va donc commencer par
essayer de déplacer le client 4 jusqu’à ce l’algorithme du split engendre une solution. La première
itération illustrée par la Figure 71 consiste à échanger la position des clients 3 et 4 et à réitérer
l’algorithme du split sur le TG obtenu.
Demandes 2 5 2 1
Figure 71 : Première itération de l’algorithme de génération de solution pour HVRP

Le split de ce TG donne deux labels sur le nœud 1 et un label sur le nœud 2 mais ne donne
aucune solution c’est-à-dire aucun label sur le dernier nœud. L’algorithme poursuit donc échangeant,
à partir du tour géant de départ, le client 4 avec le client 2 comme l’illustre la Figure 72.
Demandes 2 2 1 5
Figure 72 : Deuxième itération de l’algorithme de génération de solution pour HVRP

Le split de ce tour géant aboutit avec une unique solution qui consiste à effectuer une tournée
avec le véhicule 1 comprenant les deux premiers clients (1 et 4) et une tournée avec le véhicule 2
comprenant les deux derniers clients (3 et 2). L’algorithme s’arrête donc à cette étape avec une seule
solution pour résultante illustrée sur la Figure 73.
Véhicule 1 : Véhicule 2 :
1 4 3 2
Volume 4/4 Volume 6/6
Figure 73 : Solution de l’heuristique de génération de solutions
Le but étant de garder une solution initiale raisonnablement bonne, c’est-à-dire proche de celle
issue par la méthode des plus proches voisins, cet algorithme n’effectue qu’un seul échange de
72
position au maximum dans le tour géant initial. Dans le cas où l’algorithme ne débouche sur aucune
solution un nouveau tour géant est généré par la méthode des plus proches voisins et on réitère
l’algorithme jusqu’à trouver une solution.
2.4 Proposition d'une méthode de type Path-Relinking

L’idée du Path-Relinking est similaire à celui d’un algorithme génétique : elle se base sur le fait
que lorsque deux solutions que l’on sait bonnes sont connues, il est peut être intéressants d’explorer
les solutions qui sont "entre" les deux solutions. Cela signifie qu'il faut disposer d'une notion de
distance afin de définir la notion de "entre" de manière formelle. Avec une notion de distance, on
peut donner un sens à une phrase du type "une solution est à égale distance de la solution S1 et de la
solution S2" ce qui veut aussi dire qu'il faut disposer d'un opérateur permettant de "parcourir" la
distance entre les deux solutions.
Le fonctionnement d'un algorithme de type Path Relinking consiste à évaluer un nombre de
transformations nécessaires pour passer de l’une des deux solutions à l’autre (une distance) et de
générer une nouvelle solution lors de chacune de ces transformations. Chacune de ces
transformations doit être suffisamment significative pour intégrer à la solution générée une nouvelle
propriété issue de la solution cible. Cette idée du Path-Relinking a été pour la première fois proposée
par F. Glover en 1996 *Glo96+ pour améliorer les heuristiques basées sur une recherche taboue. Il
choisit comme transformations pour passer d’une solution à une autre par la méthode de Path-
Relinking des mouvements de type « 1-moves » (mouvements de type 2-opt par exemple). *Li10+ a
proposé en 2010 le premier algorithme basé sur la méthode de Path-Relinking pour résoudre des
problèmes de type HVRP. Son algorithme comme celui de F. Glover effectue chacun des pas pour
transformer une solution en une autre solution cible par des mouvements de type « 1-moves ».
Tel que l’algorithme de ce chapitre est construit, chacune des solutions de la population étudiée
est un minimum local du problème de HVRP. L’idée originale de l’algorithme développé dans ce
chapitre est alors, plutôt que de parcourir le chemin entre deux solutions de la population tel que le
ferrait une méthode de Path-Relinking classique, de parcourir le chemin séparant les deux tours
géants représentant respectivement ces deux solutions dans l’espace de codage indirect. Chaque tour
géant de transition ainsi généré sera soumis à la méthode split pour donner zéro, une ou plusieurs
solutions.
Pour travailler dans l’espace de codage, la première étape est d’établir une notion de distance
entre deux tours géants afin d’évaluer le nombre de tours géants constituant le chemin qui les
sépare.
Elaboration de la distance
Il existe deux principaux types de mesures utilisées pour estimer cette relation: les mesures de
distance et de mesures de similarité. En problème d'ordonnancement de nombreuses mesures de
distances ont été étudiées comme l'a souligné *Sev07+. Dernièrement, en 2005, *Zha05+ propose un
algorithme efficace (Algorithme 6) pour calculer la distance donnant le nombre minimal de
permutations nécessaires pour transformer une séquence B d'éléments dans la séquence B '. Cette
distance suppose que la liste des éléments utilisés dans les deux séquences est identique. C’est cette
distance qui est utilisé pour les tours géants dans le Path-Relinking, elle est notée MPD (Minimal
Permutation Distance).
73
Algorithme de la distance de Zhang [Zha05]

Données :
- 𝐵 : vecteur d’éléments
- 𝐵’ : vecteur d’éléments
Variables :
- 𝑉 : vecteur de booléens
- 𝐿𝑂𝐶 : vecteur tel que 𝐿𝑂𝐶,𝑖- donne la position de 𝑖 dans 𝐵
Algorithme 6 : Distance de Zhang

Sortie : P
Début
V=[Faux, Faux, …, Faux]
m=0
Pour I de 0 à n faire
LOC[B[i]] = i
Fin pour
Pour I de 0 à n faire
Si V[i] == Faux faire
m++
i_tps = i
V[i_tps] = Vrai
First = B[i]
Tant que (B’[i_tps] != First) faire
i_tps = LOC[i_tps]
V[i_tps] = Vrai
Fin tant que
Fin si
Fin pour
Fin
On va illustrer le fonctionnement de cet algorithme à partir de l’exemple donné dans le Tableau

11 :
Tableau 11 : Donnée de l’exemple de calcul de distance de Zhang
B 3 4 1 2 5 6 7
B’ 4 3 5 2 6 1 7
L’algorithme consiste à cherche dans le vecteur B le premier élément non-traité. La Figure 74

illustre la première étape dans laquelle l’élément 3 de B en position 1 est traité. La valeur de B’ en
position est 4 et on a 𝐿𝑂𝐶*4+ qui vaut 2 donc la première permutation enregistrée est l’échange des
positions 1 et 2.
74
V T T F F F F F
B 3 4 1 2 5 6 7 LOC 3 4 1 2 5 6 7
B’ 4 3 5 2 6 1 7
Figure 74 : Première étape de l’algorithme de Zhang *Zha05+
Vu que l’on a échangé les positions 1 et 2 la boucle tant que s’arrête et la boucle pour se déroule.
Comme l’illustre Figure 75, la deuxième itération prend en compte la valeur 1 en position 3 de B. La
valeur 5 associée à la position 3 de B’ est en position 5 de B. La valeur 6 associée à la position 5 de B’
est en position 6 de B. Enfin la position 6 de B’ correspond à la valeur 1 ce qui termine la boucle tant
que.
V T T T F T T F
B 3 4 1 2 5 6 7 LOC 3 4 1 2 5 6 7
B’ 4 3 5 2 6 1 7
Figure 75 : Deuxième étape de l’algorithme de Zhang *Zha05+
Les deux derniers éléments non traités ont des places correspondantes dans le vecteur B et le
vecteur B’ donc l’algorithme se finit donc comme illustré sur la Figure 76 :
V T T T T T T F V T T T T T T T
B 3 4 1 2 5 6 7 B 3 4 1 2 5 6 7
B’ 4 3 5 2 6 1 7 B’ 4 3 5 2 6 1 7
Figure 76 : Dernière étape de l’algorithme de Zhang *Zha05+
Sur cette même Figure 76, à la fin de l’algorithme, on peut apprécier le nombre de permutations
pour passer de B à B’ qui est 3 ; les permutations associées sont (1;2), (3;5), (5;6).
75
Principe général du Path-Relinking proposé

Le Path-Relinking repose alors sur un schéma très simple illustré sur la Figure 77 où ; à chaque
permutation listée par l’algorithme de Zhang on génère un tour géant afin d’intensifier la recherche
en explorant un maximum de solutions dans le voisinage des solutions de la population durant la
suite de l’algorithme général.
Deux tours
géants issus de
solutions de la
population
Calcule de la distance
de Zhang Génération des tours
géants
Algorithme de Zhang Etablissement de la liste

des permutations
Figure 77 : Principe du Path-Relinking
En reprenant, l’exemple du Tableau 11, les tours géants générés par le Path-Relinking à partir de B
et B’ sont donc au nombre de 2 ; il y a 3 permutations et la dernière aboutit sur le vecteur B’
comme le montre la Figure 78 :
B 3 4 1 2 5 6 7
Tour géant 1 4 3 1 2 5 6 7
Tour géant 2 4 3 5 2 1 6 7
B’ 4 3 5 2 6 1 7
Figure 78 : Tours géants générés par l’algorithme du Path-Relinking
2.5 La recherche locale

Une recherche locale intensive est appliquée à chaque nouvelle solution générée par les
différents Split au cours de l’algorithme. Et de ce fait, elle constitue la majeure partie du temps
d’exécution de l’intégralité de l’algorithme. Elle s’organise autour de l’utilisation randomisée de
quatre mouvements différents comme l’illustre l’algorithme 7 ci-dessous.
76
Algorithme 7 : Recherche locale pour HVRP

Entrée : Solution à améliorer
Sortie : Solution améliorée
Début
coût_initial = +∞
coût_trouvé = coût de la solution à amélioré
nb_itération = 1
Tant que (coût_initial - coût_trouvé > amélioration_minimale ou
nb_itération < nb_itération_max) faire
coût_initial = coût_trouvé
Pour chaque tournée de la solution faire
Recherche locale de type 2_opt intra-tournée
Fin pour
Affecter un ordre de façon randomisée aux tournées
Pour i de 1 au nombre de tournées faire
Pour j de 1 au nombre de tournées faire
Si i ≠ j faire
Recherche locale de type insertion entre les tournées i et j
suivant l’ordre randomisé
Fin si
Fin pour
Fin pour
Pour chaque tournée de la solution faire

Recherche locale de type 4_opt intra-tournée
Fin pour
Affecter un ordre de façon randomisée aux tournées
Pour i de 1 au nombre de tournées faire
Pour j de 1 au nombre de tournées faire
Si i ≠ j faire
Recherche locale de type 4_opt inter-tournée entre les
tournées i et j suivant l’ordre randomisé
Fin si
Fin pour
Fin pour
nb_itération++
Fin tant que
Fin
Cette recherche locale repose sur le principe que pour améliorer une tournée, il peut apparaître
logique de se focaliser dans un premier temps sur les clients qui imposent un détour important du
véhicule. Ainsi chacune des deux recherches locales associées à un mouvement intra-tournée (2_opt
intra-tournée et 4_opt intra-tournée) opère avec une certaine probabilité du client le plus
contraignant au client le moins contraignant. Sur ce même raisonnement, pour les mouvements
faisant intervenir deux tournées (insertion et 4_opt inter-tournée), on affecte un ordre de traitement
des tournées afin que les tournées traitées en priorité aient une forte probabilité d’être celles
possédant le client imposant le plus grand détour.
Description des différents mouvements utilisés :
La recherche locale repose donc sur quatre mouvements :

 Le mouvement 2_opt intra-tournée qui est similaire à celui présenté pour le VRP.
 Le mouvement insertion qui consiste prendre un client d’une tournée pour l’insérer dans une
autre comme le montre la Figure 79.
77
Figure 79 : Mouvement d'insertion
 Le mouvement 4_opt intra-tournée qui consiste à changer quatre arcs d’une tournée par quatre
autres. Le nombre de possibilités d’un tel mouvement étant très important, on se restreint dans
cet algorithme au cas où l’on échange les places de deux clients comme le montre la Figure 80.
Figure 80 : Mouvement 4_opt intra-tournée
 Le mouvement 4_opt inter-tournée qui consiste à changer deux arcs d’une tournée et deux arcs
d’une seconde par quatre autres. On se restreint là encore au cas où l’on échange les places de
deux clients illustré sur la Figure 81.
Figure 81 : Mouvement 4_opt inter-tournée
78
3. Paramètres et résultats
3.1 Paramètres sur les instances classiques
Le schéma Figure 82 reprend le schéma général présenté dans la partie précédente afin
d’expliquer plus clairement les différents paramètres qui entre en œuvre dans cet algorithme.
Figure 82 : Paramètres de l’algorithme pour le HVRP
Les principaux paramètres :

 Le nombre maximal de solutions dans la population : 100.
 Le nombre d’itérations de la boucle Principale α=80.
 Le nombre d’itération de la boucle d’injection de nouvelles solutions dans la population β=20
 Le nombre de meilleures solutions prises comme point de départ du Path-Relinking δ1=10.
 Le nombre de solutions cibles associées à chaque point de départ du Path-Relinking δ2=10.
79
 L’amélioration minimale de la boucle principale de la recherche locale : 0.5

 Le nombre d’itérations maximal de la boucle principale de la recherche locale : 10
 Pourcentage de TG pris en compte lors d’un Path-Relinking : 5%
3.2 Performances des ordinateurs utilisés

Pour pouvoir comparer les résultats obtenus à ceux de la littérature, on se base sur le Tableau 12
des puissances relatives des ordinateurs établit par *Duh10+ auquel on rajoute la valeur associée à la
puissance de l’ordinateur utilisé dans le cadre de ce stage et celle de l’ordinateur utilisé par *Sub12+
Tableau 12 : Performance des processeurs
Publications Fréquence Processeurs Mflops Coéfficients

Taillard (1999) 50MHz SunSparc10 27 0.007
Tarantilis et al.(2004) 400Mhz PentiumII 262 0.063
Li et al.(2007) 1GHz Athlon 1168 0.282
Prins (2009a) 1.8GHz Pentium4M 1564 0.378
Duhamel et al.(2010) 2.1GHz Opteron 4140 1.000
Subramaniana et al.(2012) 2.93 GHz IntelCore i7 5839 1.410
Mon ordinateur 2.0 GHz PentiumT4200 1073 0.259
3.3 Résultats numériques sur les instances classiques

Les résultats présentés Tableau 13 (deux parties) pour l’algorithme proposé sont ceux obtenus par la
meilleure parmi 5 exécutions effectuées.
La première colonne indique l’instance traitée. Les instances utilisées sont les instances numéro 13 à
20 des instances de Golden *Gol84+. La colonne 2 indique le nombre de types de véhicules de l’instance. La
colonne 3 indique le nombre de clients de l’instance. La colonne 4 indique le coût de la meilleure solution
connue de l’instance. De la colonne 5 à la colonne 16, figurent les résultats associés aux différentes
publications. A chaque publication est alors associée 3 colonnes respectivement le coût de la solution
obtenue, la différence en pourcentage par rapport à la meilleure solution connue, et le temps d’exécution
standardisé de la méthode utilisée.
80
Tableau 13 : Résultats du HVRP sur les instances de Golden
Taillard Tarantilis Li Prins

Instances types n BKS Cost Gap % scaled time Cost Gap % scaled time Cost Gap% scaled time Cost Gap % scaled time
13 6 50 1517,84 1518,05 0,01 3,311 1519,96 0,14 53,109 1517,84 0,00 100,956 1517,84 0,00 12,5496
14 3 50 607,53 615,64 1,33 4,025 611,39 0,64 24,381 607,53 0,00 39,762 607,53 0,00 14,2128
15 3 50 1015,29 1016,86 0,15 2,345 1015,29 0,00 23,184 1015,29 0,00 46,812 1015,29 0,00 2,4948
16 3 50 1144,94 1154,05 0,80 2,45 1145,52 0,05 21,483 1144,94 0,00 53,016 1144,94 0,00 2,7594
17 4 75 1061,96 1071,79 0,93 15,715 1071,01 0,85 22,869 1061,96 0,00 60,912 1065,85 0,37 30,807
18 6 75 1823,58 1870,16 2,55 20,132 1846,35 1,25 61,173 1823,58 0,00 103,212 1823,58 0,00 72,0468
19 3 100 1117,51 1117,51 0,00 40,831 1123,83 0,57 26,964 1120,34 0,25 113,928 1120,34 0,25 67,2084
20 3 100 1534,17 1559,77 1,67 23,814 1556,35 1,45 72,828 1534,17 0,00 126,054 1534,17 0,00 84,4074
Moyenne 1227,8525 1240,47875 0,93 14,077875 1236,2125 0,62 38,248875 1228,20625 0,03 80,5815 1228,6925 0,08 35,810775
Duhamel (Greedy Split) Duhamel (DFS) Subramaniana Path-Relinking

types Gap Gap
Instances n BKS Cost % scaled time Cost Gap % scaled time Cost Gap % scaled time Cost % scaled time
13 6 50 1517,84 1517,84 0,00 15,36 1517,84 0,00 16,01 1517,84 0,00 1,88 1518,05 0,01 225,68
14 3 50 607,53 609,17 0,27 24,2 607,53 0,00 71,63 608,74 0,20 1,54 609,17 0,27 10,62
15 3 50 1015,29 1015,29 0,00 33,86 1015,29 0,00 9,16 1015,29 0,00 3,00 1015,29 0,00 35,82
16 3 50 1144,94 1144,94 0,00 22,51 1144,94 0,00 28,19 1145,23 0,03 1,99 1148,62 0,32 35,43
17 4 75 1061,96 1065,2 0,31 23,61 1065,2 0,31 43,12 1064,67 0,26 5,95 1067,06 0,48 88,50
18 6 75 1823,58 1823,58 0,00 129,45 1823,58 0,00 7,24 1831,48 0,43 5,72 1838,2 0,80 239,37
19 3 100 1117,51 1120,34 0,25 144,3 1120,34 0,25% 76,44 1121,11 0,32 12,86 1120,34 0,25 145,56
20 3 100 1534,17 1534,17 0,00 60,33 1548,89 0,96% 221,43 1536,89 0,18 12,53 1562,72 1,86 106,82
Moyenne 1227,8525 1228,81625 0,10 56,7025 1230,45125 0,19 59,1525 1230,15625 0,18 5,68 1234,93125 0,50 110,973536
81
De façon générale, on peut voir que l’algorithme de ce stage obtient un coût moyen meilleur que
ceux associés aux publications de Taillard et de Tarantilis. Cependant Les publications les plus
récentes obtiennent globalement de meilleurs coûts. En termes de rapidité l’algorithme développé
est en moyenne plus lent que ceux des articles présentés. En analysant de façon plus détaillée, on
remarque que l’on obtient la meilleure solution connue pour l’instance 15 et que l’on se situe à 0.01%
de la meilleure solution connue de l’instance 13. Pour ce qui est du temps de calcule, on remarque
que l’algorithme est particulièrement lent pour les instances 13 et 18 qui possèdent un nombre de
types de véhicules important, alors qu’il est très correcte sur les autres instances relativement aux
autres publications.
Les résultats sur les instances de Golden sont donc plutôt satisfaisants car proches de ceux
trouvés dans les publications existantes. Le principal point négatif de l’algorithme proposé est son
comportement par rapport à un grand nombre de types de véhicules où son temps d’exécution
devient très élevé comparé aux différentes publications.
3.4 Présentation de l’instance générée sur un réseau routier concret

Apres avoir illustrée l’efficacité de l’algorithme proposé en se comparant aux principaux travaux
du domaine grâce aux instances de Golden *Gol84+, il est intéressant d’étudier un cas se basant sur un
réseau routier concret. Afin de construire une instance de HVRP valide, les données du réseau routier
du centre de Clermont-Ferrand sont récupérées via OSM et sont transformées sous forme de graphe
de façon analogue à ce qui a été fait dans le chapitre 2. Une fois le graphe routier complet établit, on
construit les éléments qui formeront le graphe associé à l’instance que l’on veut générer (Figure 83).
Figure 83 : Réseau routier de l’instance de HVRP sur Clermont-Ferrand
On choisit 51 nœuds du réseau routier de façon randomisée qui représentent les clients à
desservir et on leur associe aléatoirement une demande entre 1 et 100 unités. La répartition des
clients est illustré Figure 24.
82
Figure 84 : Répartition des clients de l’instance de HVRP sur Clermont-Ferrand
On obtient par ce procédé une demande totale à desservir de 1769 unités, on choisit donc en
conséquence une flotte de véhicules de capacité raisonnable. La flotte choisie est composée de
quatre types de véhicules :
 Type 1 : 1 véhicule de capacité 160, de coût fixe 10.0 et de coût par unité de distance 1.0
 Type 2 : 2 véhicules de capacité 260, de coût fixe 25.0 et de coût par unité de distance 2.0
 Type 3 : 2 véhicules de capacité 360, de coût fixe 50.0 et de coût par unité de distance 8.0
 Type 4 : 1 véhicule de capacité 600, de coût fixe 100.0 et de coût par unité de distance 10.0
Pour que les coûts fixes des différents véhicules ainsi choisis aient un impact raisonnable sur la
constitution des tournées par notre algorithme, on choisit d’utiliser comme unité de distance 10
mètres.
Les instances classiques de la littérature, comme les instances de Christofides pour le VRP ou
celles de Golden pour le HVRP, utilisent des coordonnées cartésiennes pour localiser les clients et le
dépôt et utilisent la distance euclidienne pour estimer la distance entre chaque nœud (le coût de
chaque arrête du graphe). Dans cette instance, on utilise les coordonnées GPS du graphe routier pour
localiser les nœuds représentants les clients et le dépôt. Pour établir le coût de chacune des arrêtes
du graphe associé à l’instance on calcule sur le graphe du réseau routier la distance du plus court
chemin entre chacun des 52 nœuds choisis. Ces calculs de plus court chemin sont faits de façon
exacte par un algorithme de Dijkstra. Une fois le graphe construit, l’instance est complète et peut être
utilisée par l’algorithme de résolution de HVRP proposé dans ce chapitre.
3.5 Résultats sur l’instance de Clermont-Ferrand

On va présenter dans cette section la meilleure solution obtenue par l’algorithme de HVRP sur
l’instance du centre de Clermont-Ferrand. Les paramètres utilisés sur cette instance sont les mêmes que
ceux utilisés sur les instances de Golden. La meilleure solution obtenue sur 5 exécutions est constituée de
6 tournées présentées dans le Tableau 14.
83
Tableau 14 : Liste des tournées d’une solution sur l’instance de Clermont-Ferrand
Tournée Type Volume occupé Volume libre Clients Longueur Coût

1 1 160 0 15 985,97 995,97
2 4 580 20 11 387,67 3976,66
3 3 356 4 10 377,71 3071,68
4 2 258 2 4 403,01 871,02
5 3 158 202 3 23,81 240,49
6 2 257 3 8 592,39 1289,79
La première colonne indique l’indice de la tournée. La deuxième colonne indique le type de la

tournée. La troisième colonne indique le volume total de demande traitée par la tournée. La
quatrième colonne indique le pourcentage d’espace restant au véhicule de la tournée. La cinquième
colonne indique le nombre de clients de la tournée. La sixième colonne indique le coût total de la
tournée.
On remarque sur ces résultats que les véhicules les moins coûteux (de type 1 et 2) effectuent des
tournées de longueurs élevées malgré leur faible capacité ; ils s’occupent donc à priori de desservir
les clients les plus éloignés. D’autre part il est logique que les véhicules ayant un gros coût par unité
de distance (de type 3 et 4) ne soient utilisés que partiellement. Cependant il est intéressant de
remarquer que le véhicule qui est très nettement le plus délaissé n’est pas le véhicule de type 4 mais
celui de type 3. Ce phénomène peut s’expliquer par la différence de capacité des véhicules. Il faut en
effet garder en tête que pour les points qui ne sont pas dans le voisinage du dépôt, il est à priori
préférable que les points les plus proches les uns des autres soient traités par la même tournée afin
de limité la distance totale parcourue.
Pour étayer ces remarques, on présente les trois tournées suivantes :
 La tournée 1 qui utilise le véhicule le moins coûteux et qui est de longueur maximale
 La tournée 2 qui utilise le véhicule le plus coûteux et qui est remplie à plus de 98%
 La tournée 5 qui utilise un véhicule de type 3, qui est de longueur minimale est remplie à moins de
la moitié de sa capacité.
La première tournée est constituée de 15 clients qui sont desservis par le véhicule de type 1 dans
l’ordre illustré Figure 85 où le dépôt est représenté par un point vert. Sur la figure, deux clients
successifs sont reliés par une droite afin de ne pas la surcharger avec le chemin complet reliant ces
clients. On peut voir que les clients desservis sont très dispatchés du nord au sud de l’instance et vont
de l’extrême ouest au centre de l’instance. On remarque en particulier que la tournée prend les
points les plus au sud-ouest de la carte.
84
Figure 85 : Première tournée de la solution associée à l’instance de Clermont-Ferrand
La deuxième tournée est constituée de 11 clients qui sont desservis par le véhicule de type 4 dans
l’ordre illustré Figure 86 où le dépôt est représenté par un point vert. On peut voir que les clients
desservis sont scindés en trois groupes :
 Un groupe de trois points proches du dépôt.
 Un groupe très compact de 5 points à une distance modéré du dépôt.
 Un deuxième groupe compact de 3 points à une distance également modéré du dépôt.
Figure 86 : Deuxième tournée de la solution associée à l’instance de Clermont-Ferrand
La cinquième tournée n’est constituée que de 3 clients qui sont desservis par un véhicule de type
3 dans l’ordre illustré Figure 87 où le dépôt est représenté par un point vert. On peut voir que les
85
clients desservis ont de grosses demandes et sont très proches du dépôt.
Figure 87 : Cinquième tournée de la solution associée à l’instance de Clermont-Ferrand
4. Conclusion
Dans ce chapitre nous avons pu, grâce au travail effectué précédemment sur le VRP, résoudre de
façon approchée le problème du HVRP par une métaheuristique. Le point fort de notre méthode fut
d’approcher le problème d’une façon originale par une méthode de Path-Relinking tout en gardant
des résultats satisfaisants comparés aux principales publications sur le sujet.
Nous nous sommes, par ailleurs, servi du travail effectué dans le deuxième chapitre pour
proposer une méthode de construction d’instance basée sur un réseau routier réel afin d’appliquer
notre algorithme à un cas concret.
5. Références
*Bal09+ R., Baldacci and A., Mingozzi, A unified exact method for solving different classes of
vehicle routing problems. Mathematical Programming, vol. 120 , pp. 347-380, 2009.
*Duh10+ C. Duhamel, P. Lacomme and C., Prodhon, Efficient frameworks for greedy split and
new depth first search split procedures for routing problems, Computers &
Operations Research, vol.38, pp. 723–739, 2010.
*Gol84+ B. L., Golden, A. A., Assad, L.,Levy and F., Gheysens, The feet size and mix vehicle
routing problem, Computers & Operations Research, vol. 11, pp. 49-66, 1984.
*Glo96+ F. Glover. Tabu search and adaptive memory programing – Advances, applications and
challenges. In R.S. Barr, R.V. Helgason, and J.L. Kennington, editors, Interfaces in
Computer Science and Operations Research, pp 1–75. Kluwer, 1996.
*Li07+ F., Li, B., Golde and E., Wasil, A record-to-record travel algorithm for solving the
heterogeneous fleet vehicle routing problems. Computers & Operations Research,
vol. 34, pp. 2734–2742, 2007.
86
*Li10+ X. Li, P., Tian and Y., Aneja, An adaptive memory programming metaheuristic for the
heterogeneous fixed fleet vehicle routing problem. Transportation Research Part E:
Logistics and Transportation Review, vol. 46, pp. 1111-1127, 2010.
*Pes09+ A., Pessoa, E., Uchoa and M., Aragao, A robust branch-cut-and-price algorithm for the
heterogeneous fleet vehicle routing problem. Networks, vol. 54 , pp. 167-177, 2009.
*Pri09+ C., Prins. Two memetic algorithms for heterogeneous fleet vehicle routing problems.
Engineering Applications of Artificial Intelligence, vol. 22, pp. 916–928, 2009.
*Sev07+ M., Sevaux, K. Sörensen, J. Springael, and W. Dullaert. Applications of metaheuristics.
European Journal of Operational Research, 179(3):601-604, 2007
*Sub12+ A., Subramaniana, P. Huachi Vaz Penna, E. Uchoa and L. Satoru Ochi. A Hybrid
Algorithm for the Heterogenous Fleet Vehicle Routing Problem. European Journal of
Operational Research January 18, 2012
*Tai99+ E., Taillard, A heuristic column generation method for the heterogeneous fleet VRP.
RAIRO Operations Research, vol. 33 (1), pp. 1–14, 1999.
*Tar04+ C., Tarantilis, C., Kiranoudis and V., Vassiliadis, A threshold accepting metaheuristic for
the heterogeneous fixed fleet vehicle routing problem, European Journal of
Operational Research 152, pp. 148–158, 2004
*Zha05+ L., Wang, Y., Zhang and J. Feng, On the Euclidean Distance of Images, IEEE
Transactions on Pattern Analysis and Machine Intelligence, vol. 27(8), pp. 1334-1339,
Aug. 2005
87
Conclusion
Durant ce stage d'une durée de 6 mois, trois problèmes de recherche opérationnelle ont été
traités sur les problèmes de routing. Le premier problème à résoudre a été le VRP, considéré comme
le problème de base en tournées de véhicules, qui a permis de se familiariser avec les méthodes
approchées. Le deuxième problème abordé a été le problème de cheminement en milieu urbain
intégré dans un environnement mobile. Il a permis d’appréhender les différentes contraintes liées au
milieu urbain et au milieu mobile. Le dernier problème abordé a été le HVRP qui est un problème de
tournées de véhicules sur lequel peu de littérature a été publiée.
Le premier mois du stage a été consacré à la découverte du milieu scientifique, l’étude des
différents problèmes théoriques abordés plus tard durant le stage. Cette première période s'est
terminée par l’élaboration d’une métaheuristique pour résoudre le VRP. Les résultats de cette
méthode ont été comparés aux résultats obtenus par C. Prins.
Une fois ces compétences acquises, une majeure partie du stage fut consacrée au problème de
cheminement pour piéton en milieu urbain dans un environnement mobile. Cette partie consiste,
dans un premier temps, à élaborer une méthode de résolution de plus court chemin dans des
graphes de grandes tailles. Une fois ce travail effectué, un service web dialoguant avec une base de
données routières. Une application GPS sous Android dédiée aux guidages de piétons en milieu
urbain et utilisant ce web service a été élaborée. L’application et le web service sont fonctionnels et
ont été présentés à Paris au siège de Via Michelin qui possèdent des services d’itinérance pour
véhicule très performants.
La dernière partie de mon stage consistait à concevoir une méthode approchée originale pour le
HVRP qui soit applicable aux instances de la littérature mais aussi à des instances construites à partir
de réseaux routiers. Cette méthode de résolution propose des résultats satisfaisants et s’applique
parfaitement aux instances de très grande taille créées à partir de plusieurs milliers de nœuds et
d’arcs issus d’un réseau routier de Clermont-Ferrand.
Ce stage m’a permis de monter en compétences sur de nombreux domaines qui m’étaient peu
familiers mais aussi de m’intégrer au domaine de la recherche opérationnelle me permettant ainsi de
poursuivre mon cursus par une thèse.
A partir du mois de septembre 2013, je débute une thèse avec la société Ip Leanware financée
par une bourse d'innovation de la région Auvergne.
89
ANNEXES
ANNEXE 1 : Installation et détails du fonctionnement de l'application mobile ........................................A1
ANNEXE 2 : Installation et détails du fonctionnement de l'application mobile ...................................... A11
91
Annexes
ANNEXE 1
Installation et détails du fonctionnement de l'application
mobile
A-1
Annexes
Installation de l’application
Pour installer l’application sur un mobile Android, il suffit de suivre les trois étapes suivantes :
 Télécharger l’application sur le mobile à l’adresse suivante :
http//www.isima.fr/~lacomme/ORWebServices/GPS4pedestrian/source/Gps_android.apk
 Configurer le mobile pour accepter les applications non issues du market Android. Pour cela il faut
aller dans les paramètres du téléphone puis dans l'onglet Sécurité et autoriser l’installation
d’application non Market.
 Installer sur le mobile l’application à partir du fichier téléchargé.
Figure A-1 : Installation de l’application Android en trois étapes
Il faut noter que pour utiliser l’application, le GPS et les données mobiles du téléphone doivent être
activés.
Figure A-2 : Exemple d’utilisation de l’application
A-3
Annexes
Détails du fonctionnement de
l'application mobile
Dans cette annexe, nous illustrons à les différents cas d’utilisation de notre application à travers le
parcours d’un itinéraire en allant du parking de l’ISIMA jusqu’au centre d’Aubière (12 rue des ramacles).
Figure A-3 : Vue d’ensemble du trajet à effectuer
Nous commençons donc par vérifier que le mobile dispose d’une connexion réseau et que la
localisation par GPS est activée. Une fois cette vérification effectuée, et l’application lancée, on accède à
l’interface à partir de laquelle on a accès au menu de l’application :
A-5
Annexes
Figure A-4 : Interface de démarrage
A partir de ce menu, on choisit l’onglet "ma position" afin de vérifier que le mobile
localise correctement le téléphone. Cette étape n’est pas nécessaire, elle permet seulement
d’ajuster automatique le zoom de la carte mais il faut noter que le calcul d’itinéraire ne se
déclenchera pas tant que le mobile n’est pas géolocalisé.
A-6
Annexes
Figure A-5 : Lancement du calcul Figure A-6 : Zoom sur la position

sans position GPS courante
On choisit maintenant l’onglet Destination afin de rentrer l’adresse du point d’arrivée

(NB : Les abréviations av. pour avenue sont considérées comme des erreurs de saisie
d’adresse). Une fois l’adresse localisée, la carte est centrée sur la destination mais le zoom est
inchangé. Le calcul de l’itinéraire ne se déclenchera pas tant qu’aucune adresse n’a été saisie.
Figure A : Saisie de l’adresse de destination
Maintenant que l'application à tous les éléments nécessaires, il est possible de lancer la
demande d’itinéraire avec l’onglet guider. Le web service met en moyenne 5 secondes pour
traiter la demande. Une fois que l’itinéraire a été trouvé le chemin s’affiche sur la carte.
Notons qu’après le première itinéraire, l’application récupère auprès du web service un graphe
autour de la position courante afin de pouvoir lancer un recalcule en local en cas de coupure
réseau. Cette opération se fait de façon transparante pour l’utilisateur qui continue d’être
guidé durant le téléchargement.
A-7
Annexes
Figure A-8 : Calcul de l’itinéraire
Les indications à suivre commencent alors dès que la position de l’utilisation a bougé
ou que l’on appuie sur ma position. La position courante du mobile est projetée sur le chemin
et des indications sur la prochaine intersection apparaissent à l’écran au fur et a mesure que
l’on se déplace.
Figure A-9 : Parcours de l’itinéraire
A partir d’une certaine distance à parcourir et ceci même si l’utilisateur suit

parfaitement les consignes fournies par l’application, l’itinéraire se recalcule. Une fois que
l’on s’approche de la fin de la partie de l’itinéraire calculé, un recalcul est alors déclenché
A-8
Annexes
pour compléter l’itinéraire.
Figure A-10 : Calcul itératif
Lors du parcours du chemin, il peut arriver que l’utilisateur s’éloigne de l’itinéraire

précalculé. L’application déclenche alors un recalcul afin de prendre en compte le détour de
l’utilisateur.
Figure A-11 : Recalcule de l’itinéraire
Lors de ces différents recalculs, il peut arriver que la connexion avec le réseau soit
interrompue auquel cas l’application se sert du graphe stocké dans le téléphone (dans la
mesure où il comprend la position actuelle) pour effectuer le calcul d’itinéraire. Cette prise en
charge du calcul par l’application du téléphone est invisible pour l’utilisateur.
Dans l’exemple suivant, une perte de connexion a été simulé par la coupure des
données mobiles puis nous avons relancé le calcul d’itinéraire vers la destination par l’onglet
A-9
Annexes
guider, puis en déclenchant le recalcul de l’itinéraire de façon automatique si l'utilisateur

s’éloigne du chemin précédemment calculé.
Figure A-12 : Gestion de la perte de réseau
A-10
Annexes
ANNEXE 2
Liste de publications
Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path in the context of Route
Guidance Systems. International France-China Workshop. NICST’2013, New and smart
Information Communication Science and Technology to support Sustainable Development,
18-20 September 2013, Clermont Ferrand, France. Accepté pour publication.
Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path for Mobile Devices in Urban
Area., Congrès ROADEF de Société française de Recherche Opérationnelle et d'Aide à la
Décision. 26-28 février 2014. Soumission en cours.
Vincent B., P. Lacomme, R. Libo and N. Techernev. Shortest Path challenging problem in the
context of mobile devices in urban area takling weakened GPS data and wireless network
traffic interruption. ICORES 2014. 3rd International Conferences on Operations Research and
Enterprise Systems. ESEO, Angers, Loire Valley, France, 6-8 march 2014.
A-11
Annexes
Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path in the context of Route
Guidance Systems. International France-China Workshop. NICST’2013, New and smart
Information Communication Science and Technology to support Sustainable Development,
18-20 September 2013, Clermont Ferrand, France. Accepté pour publication.
A-13
Annexes
A-14
Annexes
A-15
Annexes
A-16
Annexes
A-17
Annexes
A-18
Annexes
Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path for Mobile Devices in Urban
Area., Congrès ROADEF de Société française de Recherche Opérationnelle et d'Aide à la
Décision. 26-28 février 2014. Soumission en cours.
A-19
Annexes
A-20
Annexes
Vincent B., P. Lacomme, R. Libo and N. Techernev. Shortest Path challenging problem in the
context of mobile devices in urban area takling weakened GPS data and wireless network
traffic interruption. ICORES 2014. 3rd International Conferences on Operations Research and
Enterprise Systems. ESEO, Angers, Loire Valley, France, 6-8 march 2014.
A-21
Annexes
A-22
Annexes
A-23
Annexes
A-24
Annexes
A-25
Annexes
A-26
Annexes
A-27
Annexes
A-28
Annexes
A-29
Annexes
A-30

Rapport de Stages Tad

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stages Tad

Transféré par

Droits d'auteur :

Formats disponibles

Génie Mathématique et Modélisation 3éme Année

RAPPORT DE STAGE 2012 - 2013

Conception de méthodes pour le transport à la

Soutenu le 10 septembre 2013

Responsable du stage Polytech : Gaelle LOOSLI

Responsables du stage au LIMOS : Philippe LACOMME, Nicolay TCHERNEV et Libo REN

1.1 Le problème du plus court chemin .................................................................................................... 26

3.4 Présentation de l’instance générée sur un réseau routier concret .................................................. 82

Figure 46 : Diagramme de séquence des fonctions du web service................................................... 44

Le rapport de stage est structuré en trois chapitres.

L’objectif de ce chapitre est d’appréhender les problèmes de tournées de véhicules et

1. Problème du type VRP

(ou la durée) de parcours pour se rendre de 𝑖 à 𝑗. Un ensemble de K véhicules (numérotés de 1 à 𝐾)

∑ yik =1 ∀ i ∈ V\*0+ (3)

∑ xijk = yjk ∀ j ∈ (1, . . , n) , k ∈ 1, … , K (5)

∑ xijk = yik ∀ i ∈ (1, . . , n) , k ∈ 1, … , K (6)

Figure 1 : Solution d’un problème de VRP

1.2 Etude sur les méthodes de résolution existantes

exemple les méthodes de Génération de colonnes proposées par Dantzig et Wolfe

2. Conception d’une métaheuristique basée sur un codage indirect

Espace de codage Espace des solutions

Figure 2 : Classification des fonctions de mapping d'après (Cheng et al., 1996)

2.2 Critères d’évaluation d’une métaheuristique

Figure 4 : Schéma d’une heuristique efficace selon (Duhamel et al., 2011 )

3. Principe d'un GRASP/ELS basé sur un codage indirect

3.1 Définition d’une métaheuristique GRASP

Figure 5 : Initialisation de la méthode GRASP

Figure 6 : Recherche locale de la méthode GRASP

3.2 Définition d’une métaheuristique ELS

Figure 7 : Mutation d’un algorithme ELS

Figure 8: Recherche locale d’un algorithme ELS

3.3 La méthode hybride GRASP/ELS

Figure 9 : Schéma d’une métaheuristique de type GRASP/ELS

4.1 Schéma général de la méthode implémentée

Figure 11 : Schéma du GRASP/ELS proposé

Le GRASP/ELS que nous proposons comprend deux étapes, à savoir :

4.2 Etape d’initialisation : la méthode des plus proches voisins

Figure 12 : Méthode des plus proches voisins

Algorithme 1 : 4-plus proches voisins

Choisir de façon aléatoire comme premier élément du tour géant un des 4

Considérer le client choisi comme traité

Tant que tous les clients ne sont pas traités faire

Choisir de façon aléatoire un des 4 clients non-traités les plus

Considérer le client choisi comme traité

Fin tant que

4.3 L’algorithme Split

Figure 13 : Exemple d’un problème avec clients déjà ordonnancés

Voici les données du problème montré sur l’exemple :

L’algorithme du Split est composé de deux étapes:

Figure 14 : Exemple de tournées incluant le premier client

Figure 15 : Exemple de tournée n’incluant pas le premier client (A)

Cette étape donne le schéma suivant :

Figure 16 : Schéma de l’ensemble des tournées possibles

L’étape du calcul du plus court chemin :

Figure 17 : Calcul du plus court chemin

Algorithme de séparation d’un tour géant *Prin04+ :

Algorithme 2 : séparation d’un tour géant (Prins 2004) :

Figure 18 : Etape de mutation de l’algorithme GRASP/ELS

4.5 La recherche locale

Figure 19 : Mouvement de type 2-opt intra-tournée

Algorithme 3 : 2-opt intra tournée (Recherche locale)

L’opérateur 2-opt inter-tournées :

Figure 20 : Mouvement de type 2-opt inter-tournées

Recherche locale appliquée à chaque couple de tournées du tour géant :

stratégies et de mécanismes recherche Gub10+, Will05+.