‫ﺍ ــ ـــ ـــ ـــ ﺭ ــ ﺍ ــ ــ ﺍ ــ ــ ﺍ ــ ــ ــ ــ ﺍ ــ ــ ﺍ ــ ــ ــ ــ ــــ‬

People’s Democratic Republic of Algeria

‫ﻭﺯﺍﺭﺓ ﺍ ــ ــ ــ ــ ــ ﺍ ــ ــ ــ ﻭﺍ ــ ــ ــ ﺍ ــ ــ ــ ــــ‬
Ministry of Higher Education and Scientific

Research

‫ــ ــ ــ ــ ــ ــ ــ ﺕ ﺍ ــ ــ ــ ــ‬ ‫ﺍ ـــــ ﺭ ـــــ ﺍ ــ ــ ــ ــ ﺍ‬

National Higher School of Advanced
Technologies

Département de Génie Logistique et Transport

Mémoire de fin d’étude en vue de l’obtention du diplôme

D’INGÉNIEUR d’État
Filière : Ingénierie des transports
Spécialité : Ingénierie des transports

Thème :

Amélioration de la réactivité et de
l’efficacité des tournées de livraison et
approvisionnement des chantiers
Cas d’ENAGEO

Réalisé par :
AMEUR Thilleli

Les membres de Jury :

Tabti Amina Présidente MCA ENSTA
AGGUINI Chafik Encadrant MAA ENSTA
REZKI Nafissa Co-encadrante MCB ENSTA
Moulai Ratiba Examinatrice MAA ENSTA

Année universitaire : 2024 - 2025

Dédicaces

À la mémoire de ma chère mère…

À celle qui a semé en moi les graines du bien,
qui m’a bercée d’un amour inégalé,
à celle dont l’absence physique n’a jamais effacé la présence dans mon cœur.
Je te dédie le fruit de mes efforts et de mes années d’étude.
Tes prières continuent de me guider à chaque pas.
Que Dieu t’accorde Sa miséricorde et fasse du paradis ta demeure.

...‫ﺓ‬ ‫ﺍ‬ ‫ﺭﻭﺡ ﺃ‬ ‫ﺇ‬

، ُ ‫ﻥ‬
ٍ ‫ﻭ‬، ‫ﻭﺭ ﺍ‬ ‫ﺇ‬

، ‫ﺃ ًﺍ‬ ‫ًﺍ ﻭ‬ ‫ﺭ‬ ‫ﺇ‬

، ‫ﺍ‬ ‫ﻱﻭ‬ ‫ﺓ‬ ِ ‫ﺃ‬

.‫ﺓ‬ ِ ‫ﺩ ﺍ‬ ‫ﺯﺍ‬ ،ِ‫ﻙ‬ ‫ﻭﻥ‬

.ِ‫ﻭﺍﻙ‬ ‫ﺍ‬ ‫ ﻭ‬،ِ ‫ﺃ‬ ‫ﺭ‬ ‫ِ ﺍ‬ ‫ﺭ‬

i
Remerciements
Je tiens à exprimer ma profonde gratitude à toutes les personnes qui ont contribué à
la réalisation de ce travail et qui m’ont accompagnée tout au long de ce parcours.
Mes premiers remerciements s’adressent à mes encadrants, Monsieur Aguini Chafik
et Madame Rezki Nafissa, pour leur encadrement rigoureux, leurs conseils précieux et
leur suivi constant. Leur expertise, leur disponibilité et leurs orientations judicieuses ont
été déterminantes pour mener à bien ce projet de fin d’études. Je les remercie également
pour la confiance qu’ils m’ont témoignée et pour leur soutien dans les moments de doute.
Je souhaite également exprimer ma reconnaissance à l’entreprise d’accueil ENAGEO,
qui m’a offert l’opportunité de réaliser ce stage dans d’excellentes conditions. Mes remer-
ciements vont particulièrement à Monsieur Derdiche Karim pour son accueil chaleureux
et pour avoir facilité mon intégration au sein de l’équipe, ainsi qu’à Monsieur Cheriaf
Samir pour l’intérêt qu’il a porté à mon travail durant ce stage.
J’adresse mes sincères remerciements à Messieurs Isolah Samir et Amoura Mohand
pour leur collaboration précieuse, leurs explications techniques et le partage de leur ex-
périence professionnelle. Leur soutien et leurs conseils pratiques ont grandement enrichi
mon apprentissage et ma compréhension du domaine.
Mes remerciements s’étendent aux membres du jury qui ont accepté d’évaluer ce travail
et de partager leur expertise lors de la soutenance.
Enfin, je tiens à remercier ma famille et mes proches pour leur soutien indéfectible, leur
patience et leurs encouragements constants tout au long de cette période. Leur présence
et leur confiance ont été une source de motivation essentielle.
À toutes et à tous, j’exprime ma sincère gratitude.

ii
 ‫ﺍ‬ ‫ﻭ ﺍ‬ ‫ﻭﺭﺵ ﺍ‬ ‫ﻭ‬ ‫ﺕﺍ‬ ‫ﺩﺍﺭﺓ ﺍ‬ ‫ﺇ‬ ‫ﻭﻉ ﺍ‬ ‫ﺍﺍ‬ ‫ﻑ‬
‫ﺍ‬ ّ ،( ‫ﺍ‬ ‫ﺏ ﻭﺍ‬ ) ‫ﻭ‬ ‫ﺍ‬ ‫ﺩﺍ ً ﺇ ﺍ‬ ‫ ﺍ‬ENAGEO.
. ‫ﺍ‬ ‫ﻥ‬ ‫ﺀﺓ ﻭﺍ‬ ‫ﻭﺍ ـ‬ ‫ﺍ‬ ‫ﺍ‬

، ‫ﺭ‬ ‫ﺍ‬ ‫ﺩ ﺍ‬ ‫ ﺍ‬،‫ﺍ ﺩﺩﻱ‬ ‫ﺕ ﺍ‬ ،‫ﺕ‬ ‫ﺭ ﺍ‬ ، ‫ ﺍ‬، ‫ ﺍ‬: ‫ﺕ ﺍ‬ ‫ﺍ‬

. ‫ﺩ‬ ‫ﺍ‬ ، ّ ‫ﺍ ﺍﺭﺯ ﺕ ﺍ‬

Résumé
Ce projet de fin d’études vise la conception d’une solution intégrée de gestion des
transports pour les opérations de démantèlement, de relocalisation des chantiers et des
bases de vie chez ENAGEO. Basée sur une modélisation mathématique du problème et le
développement d’une application (desktop et mobile) bien dédiée, cette solution a permis
une amélioration significative de la réactivité, l’efficacité et la sécurité des activités logis-
tiques de l’entreprise.

Mots-clés : Optimisation , Transport, Problèmes de tournées de véhicules, Services

en navettes, contraintes temporelles strictes, heuristiques , Problème d’empaquetage .

Abstract
This final year project aims to design an integrated transport management solution for
dismantling operations, worksite relocation, and accommodation facilities at ENAGEO.
Based on mathematical modeling of the problem and the development of a dedicated
application (desktop and mobile), this solution has enabled significant improvement in
responsiveness, efficiency, and safety of the company’s logistics activities.

Keywords : Optimization, Transport, Vehicle Routing Problems,Bin Backing , Shuttle

Services, Strict Time Constraints, Heuristics.

iii
Table des matières

���� iii

Résumé iii

Abstract iii

Introduction Générale 1

1 Étude de l’existant 3
1.1 Présentation d’ENAGEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Activités de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Expertise technologique et innovation . . . . . . . . . . . . . . . . . . . . . 4
1.5 Certifications et avantages concurrentiels . . . . . . . . . . . . . . . . . . . 5
1.5.1 Système de management intégré QHSE . . . . . . . . . . . . . . . . 5
1.5.2 Positionnement concurrentiel . . . . . . . . . . . . . . . . . . . . . 5
1.6 Structure organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 La logistique au sein d’ENAGEO . . . . . . . . . . . . . . . . . . . . . . . 6
1.7.1 Organisation logistique . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7.2 Missions principales . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.3 Enjeux et spécificités . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.8 Défis environnementaux et contraintes opérationnelles . . . . . . . . . . . . 7
1.8.1 Infrastructures temporaires et opérations DTM . . . . . . . . . . . 8
1.9 Parc de véhicules et moyens logistiques . . . . . . . . . . . . . . . . . . . . 10
1.10 Processus de gestion actuel et ses limites . . . . . . . . . . . . . . . . . . . 10
1.10.1 Organisation de la gestion du transport . . . . . . . . . . . . . . . 10
1.11 État des lieux technologique . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.12 Analyse du secteur géophysique . . . . . . . . . . . . . . . . . . . . . . . . 11
1.13 Analyse des dysfonctionnements actuels . . . . . . . . . . . . . . . . . . . 12
1.13.1 Dysfonctionnements techniques et organisationnels . . . . . . . . . 12
1.13.2 Conséquences sur les opérations DTM . . . . . . . . . . . . . . . . 12
1.14 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 État de l’art 14
2.0.1 Théorie de la complexité (P, NP, NP-complet) . . . . . . . . . . . . 14
2.0.2 Le problème du bin-packing : formalisation et complexité . . . . . . 15
2.0.3 Le bin packing multidimensionnel . . . . . . . . . . . . . . . . . . . 17
2.0.4 Le Problème de Tournées de Véhicules (VRP) . . . . . . . . . . . . 17
2.0.5 Complexité Computationnelle . . . . . . . . . . . . . . . . . . . . . 20

iv
 2.1 Les Méthodes de Résolution du Problème VRP . . . . . . . . . . . . . . . 21
2.1.1 Les Méthodes Exactes . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Les Heuristiques Classiques . . . . . . . . . . . . . . . . . . . . . . 21
2.1.3 Les Métaheuristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Technologies de Déploiement des Systèmes VRP . . . . . . . . . . . . . . . 24
2.3 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Modélisation du problème 25
3.1 Classification du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Description générale du problème . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Le défi à résoudre : . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 L’objectif : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Les caractéristiques spécifiques : . . . . . . . . . . . . . . . . . . . . 27
3.3 Modélisation mathématique . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Hypothèses du modèle . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Données d’Entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.1 Indices et ensembles . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.2 Paramètres temporels et réglementaires . . . . . . . . . . . . . . . . 28
3.4.3 Paramètres géographiques . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.4 Paramètres des produits . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.5 Paramètres de voyages . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.6 Paramètres des véhicules . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.7 Paramètres de compatibilité terrain-véhicule . . . . . . . . . . . . . 29
3.5 Variables de Décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.1 Variables de sélection multi-semaines . . . . . . . . . . . . . . . . . 29
3.5.2 Variables d’état temporel continu . . . . . . . . . . . . . . . . . . . 29
3.5.3 Variables temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.4 Variables d’anticipation inter-semaines . . . . . . . . . . . . . . . . 30
3.5.5 Fonction indicatrice . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Variables et Paramètres Calculés . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.1 Calculs de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.2 Filtrage et Disponibilité des Véhicules . . . . . . . . . . . . . . . . 30
3.6.3 Calculs temporels et opérationnels . . . . . . . . . . . . . . . . . . 31
3.6.4 Règles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Fonction Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7.1 Fonction objectif principale . . . . . . . . . . . . . . . . . . . . . . 32
3.8 Contraintes du Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8.1 Contraintes de capacité par voyage . . . . . . . . . . . . . . . . . . 32
3.8.2 Contrainte de satisfaction de demande : . . . . . . . . . . . . . . . 32
3.8.3 Contraintes temporelles strictes (règle 18h) . . . . . . . . . . . . . 32
3.9 Contraintes de Cohérence Temporelle . . . . . . . . . . . . . . . . . . . . . 33
3.9.1 Contraintes de durée hebdomadaire effective . . . . . . . . . . . . . 33
3.9.2 Contraintes de continuité inter-semaines . . . . . . . . . . . . . . . 33
3.9.3 Contraintes d’optimisation de chargement . . . . . . . . . . . . . . 34
3.9.4 Contraintes d’anticipation inter-semaines . . . . . . . . . . . . . . . 34
3.10 Contraintes d’Intégrité et de Domaine . . . . . . . . . . . . . . . . . . . . 35
3.11 Algorithme de Résolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.11.1 Critère de sélection glouton . . . . . . . . . . . . . . . . . . . . . . 36

v
 3.12 Algorithme principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.13 Propriétés du Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.13.1 Complexité algorithmique . . . . . . . . . . . . . . . . . . . . . . . 36
3.13.2 Garanties de qualité . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Résultats obtenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.15 Justificatifs des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.15.1 Analyse des contraintes spécifiques au transport d’équipements géo-
physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.15.2 Nature des équipements transportés . . . . . . . . . . . . . . . . . 38
3.15.3 Contraintes techniques justifiant l’utilisation volumétrique prioritaire 38
3.15.4 Justification économique de l’approche volumétrique . . . . . . . . 39
3.15.5 Implications pour l’optimisation logistique . . . . . . . . . . . . . . 39
3.16 Modélisation UML de la solution . . . . . . . . . . . . . . . . . . . . . . . 40
3.16.1 Diagramme de Cas d’Utilisation . . . . . . . . . . . . . . . . . . . . 40
3.16.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.16.3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . 44
3.17 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Implémentation et expérimentation 48
4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1 python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.2 ttkboostrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.3 SQLAlchemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.4 les autres bibliothéques . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.5 Architecture de l’environnement . . . . . . . . . . . . . . . . . . . . 50
4.1.6 Technologies et outils utilisés . . . . . . . . . . . . . . . . . . . . . 50
4.2 présentation de l’application Desktop . . . . . . . . . . . . . . . . . . . . . 51
4.2.1 La page d’authentification . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2 la page accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.3 la page équipements . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.4 la page chantiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.5 la page commandes . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.6 la page conducteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.7 la page transférer équipements . . . . . . . . . . . . . . . . . . . . 55
4.2.8 la page tournées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.9 La page cartographie . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.10 Fenêtre de commande clients . . . . . . . . . . . . . . . . . . . . . 59
4.2.11 application mobile pour les conducteurs . . . . . . . . . . . . . . . 60
4.2.12 Jeu de Données de Test . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.13 Fonctionnement en terrain désertique . . . . . . . . . . . . . . . . . 61
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Conclusion générale 63

Bibliographie 65

Webographie 66

vi
Annexes 67
Annexe A : Pseudo-code de la Simulation Temporelle . . . . . . . . . . . . . . . 67
Annexe B : Log détaillé de la validation temporelle . . . . . . . . . . . . . . . . 70
Annexe C : Exemple numérique détaillé des formules . . . . . . . . . . . . . . . 71
Annexe D : Canevas utilisé pour tester l’algorithme d’optimisation . . . . . . . . 76
Annexe E : Formulaire de création des tournées . . . . . . . . . . . . . . . . . . 77
Annexe F : Vue de la base de données implémentée dans Railway . . . . . . . . 77
Annexe J : Plan de trajet spécifique . . . . . . . . . . . . . . . . . . . . . . . . . 78

vii
Table des figures

1.1 Répartition géographique des activités internationales d’ENAGEO . . . . . 5

1.2 Organigramme de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Vue d’un camion ENAGEO naviguant sur un terrain difficile . . . . . . . . 8
1.4 Vue du camp sismique ENAGEO(enageo-doc-2025) . . . . . . . . . . . . 9
1.5 Vue du parc automobile ENAGEO . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Diagramme d’Euler des classes de complexité (P, NP, NP‑Complete, NP‑Hard) 15
2.2 Méthodes de resolution VRP . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Comparaison entre les différentes méthodes de résolution . . . . . . . . . . 23

3.1 Schéma descriptif des contraintes temporelles . . . . . . . . . . . . . . . . 26

3.2 Taux d’utilisation poids et volume moyens par semaine des véhicules gé-
nérés par la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Fichier Excel des voyages générés . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Diagramme de cas d’utilisation – Application Mobile . . . . . . . . . . . . 40
3.5 Diagramme de sequence ConducteurDiagramme de cas d’utilisation – Ap-
plication Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Diagramme de cas d’utilisation – Application Mobile . . . . . . . . . . . . 41
3.7 Diagramme de cas d’utilisation – Application Mobile . . . . . . . . . . . . 41
3.8 Diagramme de cas d’utilisation – Application Mobile . . . . . . . . . . . . 41
3.9 Diagramme de classe du système de gestion de transport . . . . . . . . . . 43
3.10 Diagramme de sequence Conducteur – Application Mobile . . . . . . . . . 45
3.11 Diagramme de sequence Client – Web Service . . . . . . . . . . . . . . . . 46
3.12 Diagramme de sequence Gestionnaire – Interface ttkbootstrap (Desktop) . 47

4.1 La page d’authentification principale . . . . . . . . . . . . . . . . . . . . . 51

4.2 Page d’accueil desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 fenêtre du gestion des conducteurs . . . . . . . . . . . . . . . . . . . . . . 52
4.4 fenêtre 2 du statistiques des tournées . . . . . . . . . . . . . . . . . . . . . 52
4.5 fenêtre du gestion des équipements . . . . . . . . . . . . . . . . . . . . . . 53
4.6 gestion des chantiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7 fenêtre du gestion des commande . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Fenêtre statistiques des commandes – Partie 1 . . . . . . . . . . . . . . . . 54
4.9 Fenêtre statistiques des commandes – Partie 2 . . . . . . . . . . . . . . . . 54
4.10 fenêtre vue globale conducteurs . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11 Fenêtre du transfert d’équipements . . . . . . . . . . . . . . . . . . . . . . 55
4.12 Fenêtre du formulaire de transfert . . . . . . . . . . . . . . . . . . . . . . . 55
4.13 fenêtre d’exécution de l’heuristique . . . . . . . . . . . . . . . . . . . . . . 56
4.14 fenêtre du gestion des tournées . . . . . . . . . . . . . . . . . . . . . . . . 56
4.15 fenêtre statistiques des tournée 1 . . . . . . . . . . . . . . . . . . . . . . . 57

viii
4.16 fenêtre statistiques des tournée 1 . . . . . . . . . . . . . . . . . . . . . . . 57
4.17 fenêtre 2 du statistiques des tournées . . . . . . . . . . . . . . . . . . . . . 57
4.18 Page cartographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.19 Formulaire de commande web . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.20 Authentification du chauffeur . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.21 Interface principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.22 Affichage de la mission du conducteur . . . . . . . . . . . . . . . . . . . . 60
4.23 Étapes de la mission en cours . . . . . . . . . . . . . . . . . . . . . . . . . 60
24 Log détaillé de la validation temporelle . . . . . . . . . . . . . . . . . . . 70
25 Formulaire de création des tournées . . . . . . . . . . . . . . . . . . . . . . 77
26 Vue de la base de données implémentés dans Railway . . . . . . . . . . . . 77
27 Plan de trajet spécifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

ix
Liste des tableaux

1.1 Cartographie des applications existantes . . . . . . . . . . . . . . . . . . . 11

2.1 Caractéristiques des extensions du problème de tournées de véhicules . . . 18

3.1 Résultats de l’optimisation sur 12 semaines . . . . . . . . . . . . . . . . . . 37

4.1 Outils et plateformes de développement . . . . . . . . . . . . . . . . . . . . 50

2 Caractéristiques des produits à transporter . . . . . . . . . . . . . . . . . . 71
3 Résultats de l’exemple numérique . . . . . . . . . . . . . . . . . . . . . . . 75
4 Instance des équipements à transporter par semaine . . . . . . . . . . . . . 76

x
Liste des abréviations

DTM Démontage Transport et Montage

ENAGEO Entreprise nationale géophysique

MCS-TC-MP-HFVRP Multi-Commodity Shuttle with Time Constraints, Multi-Period

Heterogeneous Fleet Vehicle Routing Problem
VRP Vehicle routing problem

xi
Introduction Générale

Dans un environnement caractérisé par des coûts élevés, une instabilité accrue des
marchés et des contraintes environnementales croissantes, l’efficacité opérationnelle est
devenue un levier essentiel de compétitivité pour les entreprises du secteur pétrolier et
gazier. En Algérie, les campagnes d’exploration sismique, réalisées principalement par
Entreprise nationale géophysique (ENAGEO) pour le compte de SONATRACH, jouent
un rôle stratégique dans la chaîne de valeur des hydrocarbures.
Ces campagnes s’appuient sur des chantiers mobiles déployés dans des zones déser-
tiques difficiles d’accès. Elles nécessitent des transferts fréquents de matériel lourd, d’ins-
tallations techniques et de personnel. Ces opérations de transfert impliquent le démontage,
le transport et le remontage d’équipements complexes (unités géophysiques, quartiers de
vie, structures logistiques), dans des conditions climatiques extrêmes et selon des délais
stricts.
Loin de se limiter à une simple opération logistique, ces transferts représentent un enjeu
technique, humain et organisationnel majeur. Une mauvaise planification peut entraîner
des retards importants, des surcoûts, des incidents de sécurité et une baisse significative
de la performance opérationnelle. ENAGEO doit ainsi relever un double défi : assurer la
continuité des opérations dans des délais réduits (souvent trois mois) tout en garantissant
la sécurité et l’intégrité des équipements transportés.

Problématique
La problématique à laquelle répond ce mémoire peut être formulée comme suit :

« Comment optimiser les opérations logistiques liées au transport et au char-

gement des camps sismiques dans le Sahara algérien, tout en respectant les
délais impartis, en garantissant la sécurité des équipements et en améliorant
l’efficacité opérationnelle ? »

Objectifs du mémoire
Ce travail de fin d’études vise à proposer une solution d’optimisation logistique adap-
tée au contexte spécifique des transferts sismiques dans le désert algérien. Les objectifs
poursuivis sont les suivants :

• Modéliser le processus logistique de transfert des équipements sismiques.

• Améliorer la planification et la coordination des flux logistiques.

1
 • Optimiser les opérations de chargement et les tournées durant les phases de Démon-
tage Transport et Montage (DTM).

• Automatiser certaines étapes du processus logistique, notamment les commandes.

• Réduire les coûts de transport et améliorer la réactivité opérationnelle.

Démarche méthodologique
Pour atteindre ces objectifs, une démarche structurée a été mise en œuvre, reposant
sur les étapes suivantes :

• L’analyse des pratiques logistiques actuelles d’ENAGEO.

• Une revue de littérature ciblée sur les méthodes d’optimisation combinatoire (pro-
blème de tournées de véhicules, sac à dos, heuristiques).

• La modélisation mathématique du problème en intégrant les contraintes du terrain

désertique.

• Le développement et l’implémentation d’un outil logiciel basé sur des techniques

modernes d’optimisation et de gestion de flotte.

Organisation du mémoire
Ce mémoire est structuré en quatre chapitres principaux, précédés de la présente
introduction et suivis d’une conclusion générale :

Chapitre 1 : Étude de l’existant Présentation de l’entreprise ENAGEO, de son or-

ganisation logistique et des contraintes spécifiques liées aux transferts de camps
sismiques dans le Sahara.

Chapitre 2 : État de l’art Revue des travaux de recherche sur les méthodes d’optimi-
sation logistique, en particulier les variantes du Vehicle routing problem (VRP) et
les approches de résolution associées.

Chapitre 3 : Modélisation du problème Élaboration d’un modèle mathématique dé-

crivant le processus de transfert, avec définition des variables, contraintes et objec-
tifs.

Chapitre 4 : Implémentation et expérimentation Développement de l’application

logicielle intégrant la solution proposée, présentation des fonctionnalités, des résul-
tats obtenus et de leur analyse.

Enfin, une conclusion générale viendra résumer les principaux résultats obtenus et
proposera des perspectives d’amélioration pour des travaux futurs

2
Chapitre 1

Étude de l’existant

Introduction
L’analyse stratégique d’une organisation industrielle requiert une appréhension systé-
mique de son identité institutionnelle, de son architecture opérationnelle et de son écosys-
tème d’activité. Ce chapitre a pour objet la présentation institutionnelle de l’Entreprise
Nationale de Géophysique (ENAGEO), acteur pivot du secteur parapétrolier Algérien.

1.1 Présentation d’ENAGEO

Créée en août 1981, l’Entreprise Nationale de Géophysique (ENAGEO) est une so-
ciété par actions située à Hassi Messaoud, dans la wilaya de Ouargla. Filiale à 100 % de
Sonatrach, elle dispose d’un capital social de 7 milliards de dinars algériens et emploie
plus de 5 000 personnes, s’affirmant comme l’acteur de référence du secteur géophysique
en Algérie.

1.2 Historique
L’origine d’ENAGEO remonte au décret no 81-172 du 1er août 1981, qui officialise la
fusion de plusieurs entités de Sonatrach, dont ALGEO (une société mixte entre Sona-
trach et l’américain Teledyne, active depuis 1967), le département géophysique, le service
topographie de la Direction des Travaux Pétroliers, ainsi que le service de traitement sis-
mique de Sonatrach. Initialement sous la tutelle du Ministère de l’Énergie et des Mines,
l’entreprise a connu plusieurs évolutions de son actionnariat avant de devenir, en 2005,
une filiale à 100 % de Sonatrach. ENAGEO a également participé à des partenariats in-
ternationaux, notamment avec la société libyo-algérienne ALAGCO, et mené des projets
avec des groupes étrangers tels que SINOPEC, CGG et GDC pour renforcer ses capacités
technologiques et opérationnelles. (Pimido, 2024)

1.3 Activités de l’entreprise

ENAGEO exerce principalement dans les domaines suivants :
Prospection géophysique : Première étape du processus industriel pétrolier, elle
consiste à localiser et évaluer les gisements d’hydrocarbures à l’aide de méthodes

3
 sismiques (réflexion sismique 2D et 3D), de gravimétrie, de magnétométrie et de
prospection électrique.

Études géotechniques : Analyse de la mécanique des roches et des caractéristiques

pétrochimiques, incluant divers tests de laboratoire (dureté, porosité, perméabilité,
etc.).

Topographie : Réalisation d’études topographiques pour l’implantation de forages pé-

troliers et hydrauliques, l’étude de pipelines, de routes et autres infrastructures.

Forages hydrauliques : Réalisation de puits d’eau et de puits d’anodes, avec une ca-
pacité de forage jusqu’à 800 mètres de profondeur.

Traitement et interprétation des données géophysiques : Grâce à deux centres

de calcul (Ouled Fayet et Boumerdès), ENAGEO assure le traitement informatique
avancé des données sismiques.

1.4 Expertise technologique et innovation

ENAGEO s’est positionnée comme un acteur innovant en développant ses propres
technologies. L’entreprise détient actuellement six (6) brevets internationaux en géos-
ciences, dont plusieurs ont été récompensés par des prix d’innovation en Algérie :

• ENAGEO ADVANCE (2010) : Atténuation du bruit harmonique pour améliorer

la productivité sismique

• TortuoSolution : Évaluation quantitative de la tortuosité des fluides dans les ré-

servoirs hétérogènes

• PoroSolution (2013) : Estimation de la porosité à partir d’impédances acoustiques

- 3ème prix de l’innovation en Algérie

• LithoSolution : Estimation du volume d’argile (Vclay) dans les réservoirs gréseux-

argileux

• CarboSolution (2017) : Estimation du carbone organique total (TOC) - 1er prix

de l’innovation en Algérie

• A-LFSweep : Optimisation du contenu basse fréquence des données sismiques

ENAGEO a également développé des solutions logicielles propriétaires (ScincusLog

et ScincusGeologia) pour l’analyse pétrophysique et l’illustration des opérations de
forage.
Cette expertise en développement de solutions brevetées démontre la capacité d’EN-
AGEO à transformer les défis opérationnels en innovations technologiques, approche qui
sera appliquée à l’optimisation logistique dans ce mémoire.

4
1.5 Certifications et avantages concurrentiels
1.5.1 Système de management intégré QHSE
ENAGEO a développé un système de management robuste démontrant son engage-
ment envers l’excellence opérationnelle. Depuis 1997, l’entreprise applique un système de
gestion de la sécurité conforme aux directives de l’OGP (International Association of Oil
& Gas Producers) et de l’IAGC (International Association of Geophysical Contractors).
L’évolution des certifications d’ENAGEO témoigne de sa démarche d’amélioration
continue :
• 2004 : Développement du système intégré QHSE selon les normes ISO 9001-2000,
ISO 14001-2004 et OHSAS 18001-1999
• 2009 : Mise à jour vers ISO 9001-2008, ISO 14001-2004 et OHSAS 18001-2007
• 2018 : Actualisation selon les standards ISO 9001-2015 et ISO 14001-2015
Cette certification QHSE constitue un atout majeur pour la gestion des opérations
logistiques complexes, garantissant des processus standardisés et une approche préventive
des risques.

1.5.2 Positionnement concurrentiel

Fort de plus de 50 années d’expérience en Algérie, ENAGEO bénéficie d’avantages
concurrentiels distinctifs qui renforcent sa position sur le marché géophysique :
Expertise des conditions extrêmes : Maîtrise opérationnelle unique des défis saha-
riens acquise depuis 1981, permettant une adaptation optimale des processus logis-
tiques aux contraintes environnementales.
Expérience internationale diversifiée : Opérations réussies au Mali, Niger, Libye,
Tunisie et Oman, développant une capacité d’adaptation aux contextes géopolitiques
et réglementaires variés.

Fig. 1.1 : Répartition géographique des activités internationales d’ENAGEO

Source : (enageo-doc-2025)

5
1.6 Structure organisationnelle
Ces avantages concurrentiels positionnent ENAGEO comme un partenaire privilégié pour les opérations
géophysiques complexes, justifiant l’investissement dans des solutions d’optimisation logistique avancées pour
maintenir cette position de leadership .

Fig. 1.2 : Organigramme de l’entreprise

Source : (enageo-doc-2025)

1.7 La logistique au sein d’ENAGEO

1.7.1 Organisation logistique
ENAGEO dispose d’une division logistique structurée, comprenant notamment une Direction transport.
Cette organisation est essentielle pour soutenir les opérations géophysiques, qui nécessitent la mobilisation
rapide de ressources, d’équipements et de personnel sur des chantiers souvent situés dans des zones éloignées
et difficiles d’accès.

6
1.7.2 Missions principales
• Approvisionnement : La logistique assure l’achat, la réception et la distribution des
matériaux, pièces de rechange et équipements nécessaires à la conduite des missions
de prospection et d’exploration.

• Gestion des stocks : Elle gère les entrepôts et veille à la disponibilité permanente
des consommables et matériels stratégiques, afin d’éviter toute rupture susceptible
de retarder les opérations sur le terrain.

• Sécurité des sites : ENAGEO fait appel à des prestataires pour la surveillance et la
protection des personnes et des biens sur ses bases et chantiers sismiques, ce qui re-
lève également de la coordination logistique. Par exemple, des marchés sont attribués
pour la sécurité de plusieurs bases et chantiers, notamment à Hassi Messaoud.Cette
mission critique est confiée a la division logistique .

• Soutien aux chantiers sismiques : La logistique assure le transport des équipements

lourds, l’installation des bases-vie, la gestion des flux de personnel et la fourniture
des services nécessaires au bon déroulement des opérations sur le terrain.

1.7.3 Enjeux et spécificités

La logistique chez ENAGEO est confrontée à des défis particuliers liés à la nature des
activités géophysiques : éloignement des sites, nécessité d’une grande réactivité, gestion de
volumes importants de matériel, et respect strict des délais pour garantir la continuité des
opérations. Elle joue donc un rôle stratégique dans la performance globale de l’entreprise
et la réussite des projets géophysiques.

1.8 Défis environnementaux et contraintes opération-

nelles
L’exploitation géophysique dans le Sahara algérien impose à ENAGEO des contraintes
opérationnelles majeures qui impactent directement l’efficacité logistique et les coûts de
transport, notamment les terrains difficiles, les pistes non revêtues, les températures ex-
trêmes...
Contraintes liées aux distances importantes : Dans les zones urbaines, les
centres de distribution sont souvent situés à proximité des clients, permettant des
livraisons rapides et économiques. En revanche, dans le cas du désert algérien où se
situent les chantiers d’ENAGEO, les marchandises doivent parcourir des distances
beaucoup plus longues pour atteindre leur destination, ce qui impose des contraintes
supplémentaires à l’entreprise.

Ces contraintes génèrent des coûts élevés, incluant :

• Les frais liés au carburant qui augmentent avec la distance parcourue ;

• Les coûts d’entretien des véhicules plus élevés en raison de l’usure accrue sur des
trajets longs ;

7
Fig. 1.3 : Vue d’un camion ENAGEO naviguant sur un terrain difficile

Source : (enageo-doc-2025)

• Les frais supplémentaires liés à la gestion des risques (sécurité contre le vol et assu-
rance).

Ces contraintes imposent à ENAGEO d’adapter ses stratégies à ces contraintes, par
exemple l’utilisation de véhicules 4×4 ou 6×6 , pour les terrains difficiles les bulldozers .

1.8.1 Infrastructures temporaires et opérations DTM

Caractéristiques des camps sismiques
Les camps sismiques d’ENAGEO sont de véritables villages temporaires installés au
cœur du désert pour accueillir jusqu’à 600 personnes pendant plusieurs mois. Ils sont com-
posés de roulottes, de tentes, d’espaces de travail, de repos, de restauration et de loisirs,
avec toutes les commodités nécessaires (accès à internet via satellite, services médicaux,
sécurité, etc.). L’installation d’un camp peut prendre un à trois mois et mobilise une lo-
gistique importante, avec des dizaines de véhicules, bulldozers, camions vibreurs, et tout
le matériel nécessaire à la prospection sismique.
Ces camps sont conçus pour permettre aux équipes (informaticiens, topographes,
chauffeurs, techniciens, équipes de restauration, sécurité, etc.) de travailler dans des condi-
tions extrêmes, souvent au cœur du Sahara, tout en assurant leur sécurité et leur confort.
Les camps sismiques ENAGEO ressemblent à des villages autonomes en plein désert,
équipés pour supporter de longues missions et un grand nombre de travailleurs.

Définition des opérations DTM

Le DTM désigne l’ensemble des opérations nécessaires au transfert d’un appareil de
forage ou d’un camp sismique d’un site A vers un site B dans une période déterminée.
Cette opération se déroule en trois étapes principales :

8
Fig. 1.4 : Vue du camp sismique ENAGEO(enageo-doc-2025)

Source : (enageo-doc-2025 )

• Démontage (Pre-move) : Démontage de l’appareil de forage et du camp de base

sur le site de départ, en veillant à la sécurité des équipements et du personnel .

• Transport (Move) : Acheminement de tous les équipements, matériels et infra-

structures du site d’origine vers le nouveau site, en utilisant des moyens logistiques
adaptés (camions, grues, véhicules spécialisés) .

• Montage (Rig-up) : Remontage de l’appareil de forage et du camp de base sur le

nouveau site, afin de permettre la reprise rapide des activités.

Le Démontage, Transport et Montage (DTM) constitue une phase critique qui exige
une planification rigoureuse, la mobilisation de moyens humains et matériels importants,
ainsi qu’une gestion stricte des risques liés à la sécurité, à l’environnement et à la continuité
des opérations.

Risques et défis des opérations DTM

Les opérations DTM présentent des défis logistiques majeurs qui impactent directe-
ment la performance opérationnelle d’ENAGEO :

• Complexité logistique : Le déplacement fréquent des équipements, matériaux

et cabines mobiles nécessite une coordination logistique complexe. Les routes non
préparées ou les terrains difficiles augmentent les risques de retards et d’accidents,
tandis que le transport de charges lourdes ou volumineuses exige des véhicules spé-
cialisés (exemple : porte-engins) et des itinéraires soigneusement planifiés.

• Impact financier : Les déménagements fréquents augmentent considérablement

les dépenses opérationnelles. Chaque relocalisation implique des frais supplémen-
taires pour le transport, l’installation et parfois la réparation des infrastructures
endommagées. De plus, les interruptions temporaires du travail pendant ces dépla-
cements peuvent réduire la productivité globale et entraîner des pertes financières
indirectes.

9
 • Effets sur le personnel : Ces relocalisations répétées génèrent un stress important
chez les employés. Le déracinement constant peut provoquer une fatigue physique
et mentale, affectant leur engagement et leur performance. Les conditions de vie
temporaires dans des environnements souvent isolés ou hostiles exacerbent ces effets,
entraînant une baisse de motivation et une augmentation du taux de rotation du
personnel. En outre, le manque de stabilité sociale et professionnelle peut créer un
sentiment d’incertitude chez les travailleurs.

1.9 Parc de véhicules et moyens logistiques

Le parc automobile d’ENAGEO dispose d’une flotte hétérogène et variée pour répondre
à l’ensemble de ses activités où on distingue ces principaux types :
• Véhicules lourds : tracteurs routiers, camions plateaux, camions frigorifiques,
camions citernes carburant et autres véhicules spécialisés
• Véhicules légers : véhicules de transport personnel, véhicules légers DTM et tout-
terrain spécialisés
Ces véhicules disposent de différents types de configuration : ils peuvent être en 4x4 ou
6x6 ou 4x6, ce qui leur permet de répondre aux contraintes spécifiques désertiques.

Fig. 1.5 : Vue du parc automobile ENAGEO

Source : (enageo-doc-2025)

1.10 Processus de gestion actuel et ses limites

1.10.1 Organisation de la gestion du transport
Structure organisationnelle
La gestion du transport au sein d’ENAGEO s’articule autour de plusieurs entités :
• Division Logistique : Planification stratégique et coordination générale .
• Direction Transport : Gestion opérationnelle des véhicules et des tournées .
• Direction Maintenance : Gestion intégrée de la maintenance : entretien systé-
matique et interventions spécialisées .

10
Processus de demande de transport
Le processus actuel suit les étapes suivantes :

1. Demande formulée par les chefs de chantier (formulaire papier)

2. Validation hiérarchique par le responsable de base

3. Transmission à la Direction Logistique (fax/téléphone)

4. Planification manuelle des tournées

5. Attribution des véhicules et conducteurs

6. Exécution de la mission

7. Rapport de mission.

1.11 État des lieux technologique

Infrastructure actuelle
L’analyse de l’infrastructure informatique d’ENAGEO révèle :

Tab. 1.1 : Cartographie des applications existantes

Application Fonction État

ERP Gestion financière , Ressources humaines Opérationnel
GMAO Maintenance véhicules Opérationnel
Excel Logistique Planification transport Manuel
Messagerie Outlook Communication Opérationnel
Source : (enageo-doc-2025)

1.12 Analyse du secteur géophysique

Nature des équipements transportés
Le secteur géophysique nécessite le transport d’équipements hautement spécialisés et
d’infrastructures complètes pour l’installation des camps sismiques temporaires. L’ana-
lyse du parc d’équipements d’ENAGEO révèle une grande diversité de matériels aux
contraintes de transport variées, répartis en quatre catégories principales.
Les équipements géophysiques spécialisés représentent la catégorie la plus cri-
tique, avec des poids variant de 500 kg (géophones) à 30 tonnes (vibrateurs sismiques) et
nécessitant des protections extrêmes contre les chocs, vibrations et variations thermiques.
Les infrastructures de camp incluent l’ensemble des installations temporaires (ba-
raques modulaires, conteneurs techniques, groupes électrogènes) pesant de 2,5 à 8 tonnes.
Ces équipements présentent souvent des densités relativement faibles (80-200 kg/m³) du
fait de leur conception modulaire et de leurs contraintes d’assemblage.

11
 Les équipements auxiliaires regroupent les matériels de soutien (grillages, extinc-
teurs, batteries, équipements de communication) dont le transport, bien que moins com-
plexe, doit respecter diverses réglementations de sécurité. Ces équipements contribuent
également à la contrainte volumétrique globale. Enfin, les matériels en panne néces-
sitent des solutions de dépannage et de remorquage spécialisées. Cette hétérogénéité ex-
trême (de 10 kg à 30 tonnes) impose des algorithmes d’optimisation sophistiqués capables
de gérer simultanément les contraintes de poids, volume, sensibilité et réglementations
pour les opérations DTM d’ENAGEO.

1.13 Analyse des dysfonctionnements actuels

1.13.1 Dysfonctionnements techniques et organisationnels
• Planification manuelle des DTM : Les opérations de démontage-transport-
montage, d’une durée de trois mois, sont planifiées manuellement sans outils d’op-
timisation algorithmique. Cette approche artisanale ne permet pas de gérer effica-
cement la complexité logistique impliquant des centaines de véhicules, équipements
et contraintes temporelles.

• Absence de prévision et d’anticipation : L’entreprise fonctionne en mode réactif

sans système de prévision des besoins en transport, des pannes potentielles ou des
contraintes météorologiques.

• Coordination difficile des ressources multiples : La gestion simultanée des vé-

hicules lourds, légers, des conducteurs, des équipements spécialisés et des contraintes
géographiques s’effectue sans synchronisation générant des inefficacités.

• Gestion des stocks réactive : L’absence de système de prévision des besoins

entraîne des ruptures récurrentes de pièces de rechange, particulièrement pour les
modèles anciens, immobilisant inutilement des véhicules.

• Suivi en temps réel partiel : Plus de 50% des véhicules lourds ne disposent pas
de système de géolocalisation GPS satellitaire, limitant le suivi des missions en cours
et les ajustements en temps réel. Les véhicules légers, exposés aux risques de vol,
sont équipés de géolocalisation satellitaire pour leur sécurisation.

1.13.2 Conséquences sur les opérations DTM

Ces dysfonctionnements génèrent des impacts particulièrement critiques lors des opé-
rations de transfert de camps sismiques :

• Planification DTM sous-optimale : Les trois mois alloués aux opérations de

démontage-transport-montage sont mal exploités en raison de l’absence d’algorithmes
d’optimisation. Les séquences de démontage, les tournées de transport et les phases
de remontage ne sont pas coordonnées de manière optimale.

• Adaptabilité limitée aux imprévus : Face aux aléas climatiques (tempêtes de

sable), pannes ou modifications de dernière minute, l’absence d’outils de replanifi-
cation dynamique empêche une adaptation rapide et optimale.

12
 • Gestion des contraintes multiples non maîtrisée : Les DTM impliquent la ges-
tion simultanée de contraintes temporelles, géographiques, techniques et humaines
que la planification manuelle ne peut traiter de manière optimale.

• Traçabilité et reporting inefficaces : L’absence de système digitalisé rend diffi-

cile le suivi précis de l’avancement des DTM et l’établissement de bilans permettant
d’améliorer les opérations futures.

Cette analyse révèle l’urgente nécessité de développer un système algorithmique spé-

cialement conçu pour les opérations DTM d’ENAGEO .

1.14 Conclusion
Dans ce chapitre, nous avons procédé à la présentation de l’établissement d’accueil.
L’analyse institutionnelle révèle qu’ENAGEO, réunissant plus de 40 années d’expertise
et six brevets internationaux, occupe une position stratégique dans le secteur parapétrolier
algérien.
Cette analyse révèle les défis logistiques majeurs d’ENAGEO : gestion manuelle des
opérations DTM et absence d’outils d’optimisation pour coordonner les ressources. Ces
dysfonctionnements nous ont orientés vers le développement d’une solution algorithmique
adaptée aux contraintes spécifiques de l’entreprise.

13
Chapitre 2

État de l’art

introduction
L’optimisation combinatoire est un domaine fondamental à l’intersection de la re-
cherche opérationnelle, des mathématiques discrètes et de l’informatique. Elle est essen-
tielle tant par la complexité intrinsèque des problèmes qu’elle aborde que par la diversité
de ses applications pratiques, qui peuvent être modélisées sous forme de problèmes d’op-
timisation combinatoire(Hao et al., 1999).
Ce chapitre introduit les principaux concepts théoriques liés à la thématique de ce
mémoire. Ces notions serviront de base pour la modélisation du problème étudié et pour
le développement de la solution proposée.

2.0.1 Théorie de la complexité (P, NP, NP-complet)

La théorie de la complexité computationnelle constitue une branche fondamentale
des sciences informatiques qui fournit un cadre théorique pour comprendre la difficulté
intrinsèque des problèmes algorithmiques et guide le choix des méthodes de résolution
appropriées (neukart2024thermodynamic).

Classes de complexité fondamentales

La classe P (Polynomial time) regroupe les problèmes de décision qui peuvent être
résolus efficacement par un algorithme déterministe en temps polynomial. Un problème
appartient à P si son temps d’exécution peut être borné par un polynôme O(nk ) de la
taille de l’entrée n. Ces problèmes sont considérés comme ”faciles” à résoudre en pratique
. La classe NP (Nondeterministic Polynomial time) comprend les problèmes de décision
dont une solution candidate peut être vérifiée en temps polynomial, même si on ne sait
pas forcément comment la trouver rapidement. Si un problème est dans NP, il n’est pas
forcément ”facile” à résoudre, mais il est ”facile” à vérifier .
Cette distinction capture l’essence de nombreux problèmes d’optimisation combina-
toire : vérifier une solution proposée est souvent beaucoup plus simple que de la découvrir
initialement.(Korte et al., 2009)

Problèmes NP-complets et leur importance

Un problème NP-complet est un problème de décision qui satisfait deux conditions
cruciales :

14
 1. Il appartient à NP (vérification rapide possible)
2. Il est NP-difficile (tous les problèmes de NP peuvent se réduire à lui)
L’importance fondamentale des problèmes NP-complets réside dans le fait que ré-
soudre un seul problème NP-complet en temps polynomial permettrait de
résoudre tous les problèmes NP en temps polynomial. Cette propriété fait de ces
problèmes les ”plus durs” de la classe NP.(Korte et al., 2009)

Fig. 2.1 : Diagramme d’Euler des classes de complexité (P, NP, NP‑Complete, NP‑Hard)

Source : Behnam Esfahbod – Wikimedia Commons, licence CC BY‑SA 3.0

La Figure 2.1 illustre les relations entre ces classes fondamentales de complexité. Dans
le cas général (gauche), P forme un sous-ensemble de NP, les problèmes NP-Complets
étant les plus difficiles de NP. Si P = NP était démontré (droite), toutes ces classes
coïncideraient, révolutionnant l’informatique.
Le problème du sac à dos (version décisionnelle) illustre parfaitement cette com-
plexité : étant donné un ensemble d’objets avec leurs poids et valeurs, et une capacité
limitée, déterminer s’il existe une sélection atteignant une valeur cible tout en respectant
la contrainte de poids peut être vérifié rapidement, mais trouver cette sélection optimale
parmi 2n combinaisons possibles demeure exponentiellement difficile.(Korte et al., 2009)

2.0.2 Le problème du bin-packing : formalisation et complexité

Le problème du bin-packing constitue l’un des problèmes d’optimisation combinatoire
les plus fondamentaux avec un intérêt pratique évident .
Supposons que nous ayons n objets, chacun d’une taille donnée, et des boîtes de
même capacité. On veut ranger les objets dans les boîtes, en utilisant le moins de boîtes
possible. Bien entendu, la taille totale des objets affectés à une boîte ne doit pas dépasser
sa capacité. Sans perte de généralité, on suppose que la capacité des boîtes est égale à 1.
Alors le problème peut être formulé de la manière suivante :(Korte et al., 2009)
Instance : Une liste de nombres non négatifs a1 , . . . , an ≤ 1.
Tâche : Trouver un k ∈ N et une affectation f : {1, . . . , n} → {1, . . . , k} telle que :
∑
ai ≤ 1 pour tout j ∈ {1, . . . , k} (2.1)
i:f (i)=j

k soit minimum (2.2)

15
 Supposons que la capacité des boîtes est égale à 1. Cette normalisation simplifie l’ana-
lyse sans réduire la généralité du problème.
Notation : Pour une instance I, nous utilisons les notations suivantes :

• |I| : le nombre d’éléments de la liste I

∑|I|
• SUM(I) := i=1 ai : la somme totale des tailles

• OPT(I) : le nombre minimum de boîtes nécessaires

La borne inférieure évidente est : SUM(I) ≤ OPT(I) pour toute instance I.

Complexité computationnelle
Le problème du bin-packing présente une complexité remarquable qui illustre parfai-
tement les concepts de NP-complétude développés précédemment (Korte et al., 2009).
Résultats de complexité principaux :

• Le problème de décision ”peut-on emballer tous les objets dans k boîtes ?” est NP-
complet

• Le problème d’optimisation est NP-difficile

• Il existe une NP-complétude forte, ce qui signifie qu’aucun algorithme pseudo-

polynomial n’existe (sauf si P = NP)

• Borne d’inapproximabilité : À moins que P = NP, aucun algorithme d’approxi-

mation de facteur strictement inférieur à 23 n’existe

(Korte et al., 2009)

Ces propriétés théoriques justifient le recours aux méthodes heuristiques pour résoudre
efficacement des instances de taille réelle.

Algorithme First-Fit (FF) L’algorithme First-Fit place chaque objet dans la première
boîte disposant d’un espace suffisant :

Algorithme 1 ALGORITHME FIRST-FIT (FF)

Une instance a1 , . . . , an du problème du bin-packing Une solution (k, f ) i := 1
to n Trouver la première boîte j telle que l’objet ai peut y être placé aucune boîte
trouvée Ouvrir une nouvelle boîte Placer ai dans la boîte j

⌈ ⌉
Performance : FF(I) ≤ 17
10
OPT(I) (Korte et al., 2009)

Applications aux problèmes de transport

Le bin-packing trouve des applications directes dans les problèmes de gestion de flotte
et de transport :
Chargement de véhicules : L’affectation d’objets (colis, palettes) à des véhicules
de capacité limitée constitue un problème de bin-packing. Les heuristiques FFD sont
largement utilisées dans les systèmes de gestion d’entrepôt.

16
 Optimisation multi-contraintes : Dans le transport, le bin-packing se généralise au
cas multidimensionnel (poids et volume simultanément), problème également NP-difficile
nécessitant des adaptations des heuristiques classiques.
Lien avec le VRP : Le bin-packing apparaît comme sous-problème dans certaines va-
riantes du VRP, notamment lorsque les contraintes de capacité sont complexes ou lorsque
plusieurs types de marchandises doivent être transportés. Nous allons voir ceci dans le
chapitre modélisation mathématique.
Cette analyse du bin-packing illustre parfaitement comment la théorie de la complexi-
té guide le développement d’algorithmes pratiques et oriente les choix de méthodes de
résolution pour les problèmes d’optimisation combinatoire rencontrés en logistique.

2.0.3 Le bin packing multidimensionnel

Le bin packing multidimensionnel, également appelé problème de vector packing à
deux contraintes, consiste à affecter des objets à des conteneurs (ou « bins ») tout en
respectant simultanément plusieurs contraintes de capacité, typiquement le poids et le
volume. L’étude de Heßler et al. (2021) propose une modélisation fine de ce problème
dans l’industrie agroalimentaire, en intégrant des objectifs lexicographiques (minimisation
séquentielle du nombre total de camions, du nombre de camions réfrigérés, etc.) ainsi
que des contraintes pratiques telles que l’interdiction ou la limitation du fractionnement
des commandes. Les auteurs développent à la fois des méthodes exactes, basées sur la
génération de colonnes et la résolution de sous-problèmes de sac à dos multidimensionnel,
et des heuristiques exploitant la densité (rapport poids/volume) des objets pour
équilibrer au mieux les chargements. (Heßler et al., 2022)
Après avoir établi les fondements théoriques de l’optimisation combinatoire et illustré
la complexité computationnelle à travers le problème du bin-packing, nous nous intéres-
sons maintenant au problème de tournées de véhicules et ses multiples variantes.

2.0.4 Le Problème de Tournées de Véhicules (VRP)

Définition Générale
Le Problème de Tournées de Véhicules constitue l’un des problèmes d’optimisation
les plus étudiés en recherche opérationnelle, trouvant des applications cruciales dans les
domaines de la logistique, du transport et de la gestion des chaînes d’approvisionnement.
L’objectif consiste à établir des itinéraires optimaux pour une flotte de véhicules desservant
un ensemble de clients, en minimisant les coûts tout en maximisant la satisfaction clientèle.
(Samuel Sowole, 2024).

17
Tab. 2.1 : Caractéristiques des extensions du problème de tournées de véhicules

Caractéristiques Options possibles

• Un véhicule
Nombre de véhicules disponibles
• Plusieurs véhicules
• Homogène (véhicules identiques)
Type de véhicule
• Hétérogène (véhicules différents)
• Finie (contrainte de capacité)
Capacité de véhicule
• Infinie (pas de contrainte)
• Un seul dépôt
Dépôts
• Plusieurs dépôts
• Statiques (connues à l’avance)
• Dynamiques (apparaissent au cours du
Demandes des clients
temps)
• Stochastiques (suivent des lois aléatoires)
• Avec fenêtres de temps
• Ramassage ou livraison
Service proposé • Ramassage et livraison
• Ramassage avant livraison
• Journalière
Période considérée • Hebdomadaire
• Périodique (multi-périodes)
Source : Zhao, 2008

Le tableau 2.1 présente une synthèse des principales caractéristiques permettant de

classifier les extensions du problème de tournées de véhicules (Zhao, 2008). Cette taxo-
nomie illustre la richesse et la diversité des variantes développées pour modéliser les si-
tuations logistiques réelles.

Variantes du Problème VRP

Problème de Tournées avec Flotte Hétérogène (VRPHF) Cette variante étend
le problème classique en utilisant une flotte composée de véhicules aux caractéristiques
distinctes. La différenciation entre véhicules s’effectue principalement selon leurs capacités
de transport ou leurs coûts de déplacement respectifs (Xu, 2007).

Problème de Tournées avec Livraison Fractionnée (VRPSD) Dans cette confi-

guration, la contrainte d’unicité de visite par client est levée, permettant à un même client
d’être desservi par plusieurs véhicules si nécessaire. Cette flexibilité permet de traiter des
demandes clientèle supérieures à la capacité individuelle des véhicules, contrairement aux
hypothèses du VRP classique Xu, 2007.

Problème de Tournées avec Nombre Limité de Véhicules (m-VRP) Cette va-

riante impose une contrainte supplémentaire en limitant explicitement le nombre de vé-
hicules disponibles pour la résolution du problème de tournées (Xu, 2007).

Problème de Tournées avec Contrainte de Capacité (CVRP) Considéré comme

la version standard du VRP depuis les travaux de Dantzig et al. (1959), le CVRP utilise

18
une flotte homogène de véhicules à capacité limitée, opérant depuis un dépôt unique.
Chaque véhicule dessert un ensemble de clients ayant des demandes connues (soit de
ramassage, soit de livraison, mais pas simultanément) avant de retourner au dépôt. La
contrainte fondamentale stipule que la demande totale assignée à chaque véhicule ne peut
excéder sa capacité. L’objectif vise la minimisation de la distance totale parcourue. Le
CVRP constitue le problème de référence dans la littérature et sert de base à la définition
des extensions du VRP (Xu, 2007).

Problème de Tournées avec Fenêtres Temporelles (VRPTW) Cette variante

enrichit le VRP classique en introduisant des contraintes temporelles : chaque client spé-
cifie un intervalle de temps durant lequel le service doit débuter, défini par une borne
inférieure et une borne supérieure (Xu, 2007).

Problème de Tournées Multi-Dépôts (MDVRP) Cette configuration implique

l’utilisation de plusieurs dépôts distribués géographiquement. Chaque véhicule effectue sa
tournée en partant de son dépôt d’origine et y retournant à l’issue de sa mission (Xu,
2007).

Problème du Voyageur de Commerce (TSP) Le TSP représente un cas particulier

du VRP sans contrainte de capacité, impliquant un véhicule unique (le représentant de
commerce) qui doit déterminer l’itinéraire de coût minimal pour visiter toutes les localités
une seule fois avant de revenir à son point de départ Xu, 2007.

Problème de Tournées avec Ramassage et Livraison (VRPPD) Dans cette va-

riante, les clients requièrent simultanément deux types de services : le ramassage et la
livraison de produits. Chaque client fournit deux localisations géographiques distinctes
correspondant respectivement au lieu de ramassage et au lieu de livraison. Cette confi-
guration introduit naturellement une contrainte de précédence : l’opération de ramassage
doit impérativement précéder l’opération de livraison dans chaque tournée (Xu, 2007).

Problème de Tournées Ouvertes (OVRP) La caractéristique distinctive de cette

variante réside dans l’absence d’obligation pour les véhicules de retourner au dépôt, ou
lorsque ce retour est requis, ils revisitent les clients dans l’ordre inverse. Par conséquent,
les itinéraires ne forment pas des cycles fermés mais peuvent demeurer ouverts (Xu, 2007).

Problème de Tournées de Véhicules Dynamique (DVRP) Contrairement au

VRP classique où toutes les demandes clients sont connues a priori, cette variante intègre
des éléments dynamiques tels que l’apparition de nouveaux clients en cours de journée.
Le décideur doit alors adapter la planification des tournées en temps réel pour répondre
aux nouvelles demandes qui émergent au cours de l’exécution (Xu, 2007).

Problème de Tournées de Véhicules Multi-Périodes Ces problèmes sont définis

sur un horizon temporel s’étendant sur plusieurs périodes et visent généralement à minimi-
ser le coût total des tournées sur l’ensemble de ces périodes Xu, 2007. Dans le problème
périodique de tournées de véhicules (PVRP), chaque client est caractérisé par une fré-
quence de visite indiquant le nombre de visites requises sur l’horizon de planification,
ainsi qu’une liste de schémas de visite représentant les combinaisons de jours acceptables.

19
La résolution implique de sélectionner un schéma de visite pour chaque client et de générer
les tournées correspondantes pour chaque période, rendant les décisions interdépendantes
entre les différentes périodes (Liapis & Nenes, 2023).

Problème de Tournées de Véhicules Longue Distance (Long-Haul VRP) Cette

variante complexe se caractérise par la nécessité d’optimiser les itinéraires sur de longues
distances, souvent étalées sur plusieurs jours. Particulièrement pertinente en logistique et
en gestion de la chaîne d’approvisionnement, elle vise à minimiser les coûts tout en res-
pectant diverses contraintes incluant la capacité des véhicules, les fenêtres temporelles et
les demandes clients. Sa complexité est amplifiée par des facteurs tels que les flottes hété-
rogènes, les livraisons fractionnées et la demande dynamique, nécessitant des méthodes de
résolution avancées. Les applications réelles concernent notamment l’industrie pétrolière,
où des véhicules à compartiments multiples transportent différents types de carburants,
illustrant l’importance de respecter des réglementations spécifiques tout en optimisant les
coûts (Liapis & Nenes, 2023).

Problème de Tournées de Véhicules basé sur des Navettes (Shuttle-based

VRP) Cette forme spécialisée du VRP se concentre sur l’optimisation des itinéraires
pour les services de navette, utilisés dans des contextes variés tels que le transport de
conteneurs, les navettes de personnel ou les systèmes de stockage automatisés. L’objectif
consiste à déterminer les itinéraires les plus efficaces pour minimiser les coûts et améliorer
l’efficacité du service. Sa complexité découle de contraintes spécifiques aux opérations de
navette, notamment le type de marchandise ou de passagers, la nature de la zone desservie
et les objectifs opérationnels.

1.Service de Navette pour Conteneurs Le VRP pour les services de navette

de conteneurs concerne le transport de conteneurs entre des paires origine-destination
fixes, utilisant des véhicules équipés de châssis de types différents. Ce problème se formule
comme un VRP avec enlèvements et livraisons, permettant plusieurs visites par nœud. La
solution repose sur l’utilisation de remorques à châssis combiné, capables de transporter
deux conteneurs de 20 pieds ou un seul de 40 pieds, optimisant ainsi la planification du
transport (Shin, 2009).

2.Tournées de Navettes pour le Personnel Le problème de tournées de navettes

pour le personnel (PSRP) constitue une variante spécifique axée sur l’optimisation des
trajets des navettes assurant le transport de groupes d’employés, par exemple sur des sites
industriels ou des campus universitaires. L’objectif principal vise à minimiser le temps ou
la distance totale de trajet tout en assurant une couverture efficace et équitable du service
pour l’ensemble des employés concernés (Tütüncü et al., 2023).

2.0.5 Complexité Computationnelle

Il a été démontré que le problème VRP classique appartient à la classe NP-difficile, ce
qui signifie qu’aucun algorithme déterministe capable de résoudre ce problème en temps
polynomial n’est connu à ce jour. Cette propriété s’étend également au CVRP, au VRPTW
et aux autres extensions du VRP (Xu, 2007).
Si les méthodes exactes permettent effectivement de déterminer une solution optimale
pour des instances de petite taille, elles deviennent rapidement inefficaces pour résoudre

20
des instances de moyenne ou grande taille. Or, la majorité des problèmes réels se situent
précisément dans cette seconde catégorie. Face à des cas plus complexes impliquant des
contraintes multiples ou des problèmes de plus grande envergure, le recours aux méthodes
approchées devient nécessaire pour fournir des solutions de qualité acceptable (Xu, 2007).
La diversité et la complexité des variantes VRP présentées nécessitent le développement
d’approches de résolution adaptées. Cette section présente les principales familles de mé-
thodes développées dans la littérature, des approches exactes garantissant l’optimalité
aux métaheuristiques privilégiant l’efficacité computationnelle.

2.1 Les Méthodes de Résolution du Problème VRP

Les méthodes de résolution des problèmes d’optimisation combinatoire, et par exten-
sion du VRP, se répartissent en deux grandes catégories : les méthodes exactes et les
méthodes approchées. Les méthodes exactes fournissent une solution optimale au prix
d’un effort de calcul souvent considérable, tandis que les méthodes approchées cherchent
à approximer une solution optimale en se contentant d’obtenir des solutions de qualité
dans un délai raisonnable, sans garantir leur optimalité. Les méthodes approchées ba-
sées sur les heuristiques se divisent en deux branches : les heuristiques classiques et les
métaheuristiques.
Ces propriétés illustrent l’un des problèmes fondamentaux en optimisation combina-
toire : la nécessité d’établir un compromis entre la qualité de solution désirée et le temps
de calcul requis pour l’obtenir (Xu, 2007).

2.1.1 Les Méthodes Exactes

Le caractère NP-difficile du problème VRP rend difficile le développement de mé-
thodes exactes capables de résoudre des instances de taille moyenne dans un temps de
calcul raisonnable. Néanmoins, plusieurs méthodes ont été développées pour résoudre ef-
ficacement des problèmes comportant 50 clients, et même des problèmes avec 100 clients.
Les méthodes exactes pour le VRP se classifient en trois catégories principales : la pro-
grammation dynamique, la programmation linéaire en nombres entiers, et les méthodes
de recherche arborescente (Branch & Bound) (Xu, 2007).

2.1.2 Les Heuristiques Classiques

Le terme « heuristique » trouve son origine dans le grec « heuriskein » qui signifie
« trouver ». Il qualifie tout ce qui sert à la découverte, à l’invention et à la recherche.
Depuis les années soixante, de nombreuses heuristiques classiques ont été proposées par
les chercheurs. Les récents développements de la théorie de l’optimisation combinatoire
ont considérablement enrichi les heuristiques, se traduisant concrètement par un grand
nombre d’applications réussies.
Généralement, les heuristiques développées pour le VRP s’inspirent d’heuristiques
initialement conçues pour le TSP. Les heuristiques classiques se répartissent en trois classes
principales : les méthodes constructives, les méthodes à deux phases, et les méthodes
d’amélioration (Xu, 2007).

21
Fig. 2.2 : Méthodes de resolution VRP

Source : (Xu, 2007)

Les Méthodes Constructives

Parmi les méthodes constructives figurent les algorithmes gloutons, qui jouent un rôle
central dans la conception des heuristiques pour les problèmes d’optimisation combina-
toire. Un algorithme glouton (ou « greedy algorithm ») construit une solution complète
en effectuant, à chaque étape, le meilleur choix possible selon un critère local, sans jamais
revenir sur ses décisions précédentes. Cette approche consiste à résoudre progressivement
le problème en se focalisant sur le sous-problème restant, chaque choix étant définitif et

22
motivé par l’optimisation immédiate d’une fonction d’évaluation locale.
L’avantage principal des algorithmes gloutons réside dans leur simplicité de mise
en œuvre et leur rapidité d’exécution, ce qui les rend particulièrement attractifs pour des
problèmes de grande taille où les méthodes exactes sont impraticables.

2.1.3 Les Métaheuristiques

Le terme « métaheuristique », introduit pour la première fois par Glover en 1986, dérive
de la composition de deux mots grecs : « Heuristique », dérivé du verbe « heuriskein »
qui signifie « trouver », et le suffixe « méta » qui signifie « au-delà » ou « dans un niveau
supérieur ». Avant l’adoption de ce terme, les métaheuristiques étaient souvent appelées
heuristiques modernes. Plusieurs définitions ont été proposées pour expliquer clairement
ce qu’est une métaheuristique, bien qu’aucune ne soit universellement reconnue.

Fig. 2.3 : Comparaison entre les différentes méthodes de résolution

Source : (Xu, 2007)

Caractéristiques des Métaheuristiques

Les métaheuristiques sacrifient la garantie d’optimalité ou d’approximation avec en
contrepartie l’espoir de trouver très rapidement de bonnes solutions dans S.
Les métaheuristiques se classifient en deux groupes selon le nombre de solutions ma-
nipulées :

Métaheuristiques à Solution Unique Ces méthodes sont basées sur une recherche
de voisinage qui commence avec une solution initiale puis l’améliore pas à pas en choi-
sissant une nouvelle solution dans le voisinage de la solution courante. Les méthodes
de descente, le recuit simulé et la recherche tabou constituent des exemples typiques de
métaheuristiques à solution unique.

Métaheuristiques à Population de Solutions Ces métaheuristiques améliorent une

population de solutions au fur et à mesure des itérations. L’intérêt de ces méthodes réside
dans l’utilisation de la population comme facteur de diversité. Les métaheuristiques à
population de solutions les plus connues sont l’algorithme génétique et l’algorithme des
colonies de fourmis.

23
2.2 Technologies de Déploiement des Systèmes VRP
Les technologies de déploiement des systèmes VRP varient considérablement selon le
contexte d’utilisation et les contraintes opérationnelles spécifiques. Les applications desk-
top offrent des avantages significatifs en termes de performance et de temps de calcul pour
les problèmes d’optimisation complexes, exploitant pleinement les ressources matérielles
locales sans latence réseau . Cette approche s’avère particulièrement adaptée aux variantes
NP-difficiles du VRP nécessitant des calculs intensifs, comme le MCS-TC-MP-HFVRP
étudié dans ce cas .
Les solutions web privilégient la centralisation et la collaboration multi-utilisateurs,
permettant la coordination de flottes distribuées géographiquement , tandis que les appli-
cations mobiles excellent dans le suivi temps réel des tournées et la capture de données
terrain grâce à l’accès aux capteurs GPS et aux notifications push.
Le choix de l’architecture technologique doit donc s’aligner sur les exigences com-
putationnelles du problème VRP considéré : optimisation centralisée pour les systèmes
desktop, coordination distribuée pour les plateformes web, et exécution terrain pour les
solutions mobiles.

2.3 conclusion
Dans ce chapitre nous avons présentés les fondements théoriques et méthodologiques
nécessaires à la compréhension et à la résolution des problèmes de tournées de véhicules.
L’analyse de la complexité computationnelle, illustrée par le problème du bin-packing, a
démontré pourquoi la majorité des problèmes VRP appartiennent à la classe NP-difficile,
justifiant ainsi le recours aux méthodes heuristiques et métaheuristiques pour traiter des
instances de taille réelle.
La taxonomie exhaustive des variantes VRP présentée révèle la richesse et la diversité
de ces problèmes, depuis le TSP classique jusqu’aux extensions multi-contraintes comme
le VRPTW, le MDVRP ou les problèmes multi-périodes. Cette classification permet de
positionner précisément le problème étudié dans ce projet .

24
Chapitre 3

Modélisation du problème

Introduction
La modélisation mathématique constitue l’étape fondamentale dans la résolution de
tout problème d’optimisation complexe. Elle permet de traduire une situation réelle, avec
ses contraintes et objectifs multiples, en un langage mathématique rigoureux susceptible
d’être analysé et résolu par des méthodes algorithmiques appropriées.
Dans le domaine de l’optimisation logistique, cette démarche de modélisation devient
cruciale lorsqu’il s’agit de gérer simultanément plusieurs dimensions interdépendantes :
allocation de ressources, contraintes temporelles, minimisation des coûts et respect des
exigences opérationnelles. La formalisation mathématique offre alors un cadre structuré
pour explorer l’espace des solutions possibles et identifier les configurations optimales.
Au-delà de la dimension purement algorithmique, la résolution complète de la problé-
matique étudiée nécessite également une approche de modélisation orientée objet pour
concevoir un système informatique capable de gérer efficacement l’ensemble du processus
logistique. La modélisationUML (Unified Modeling Language) s’impose alors comme
un complément indispensable à la modélisation mathématique, permettant de structurer
l’architecture du système de gestion de transport et de définir les interactions entre les
différents acteurs .

3.1 Classification du problème

Le modèle développé s’inscrit dans la famille des problèmes de tournées de véhicules
(Vehicle Routing Problem - VRP) avec les spécificités suivantes :

• Multi-Commodity Shuttle VRP (MC-SVRP) : transport de produits hétéro-

gènes en navette

• Time-Constrained VRP (TC-VRP) : contraintes temporelles strictes de projet

• Multi-Period VRP (MP-VRP) : extension sur plusieurs semaines

• Heterogeneous Fleet VRP (HFVRP) : flotte de véhicules différents en capaci-

tés, coûts, et caractéristiques. Etant donnee

25
Originalité de l’étude
Le problème étudié est une extension complexe du Vehicle Routing Problem, in-
tégrant plusieurs dimensions rarement combinées qui, selon Braekers et al. (2016), sont
”principalement considérées individuellement ou avec un nombre limité d’autres caracté-
ristiques”.. Il s’agit d’un transport en navettes (Shuttle VRP) où des véhicules effec-
tuent des allers-retours répétés entre des sites fixes, sur de longues distances et sur
plusieurs jours. Les marchandises transportées sont hétérogènes, avec des contraintes
de compatibilité véhicule-produit. La flotte est également hétérogène en termes de
capacités et de coûts d’exploitation, rendant l’affectation optimale des véhicules parti-
culièrement délicate. La planification multi-périodes impose une coordination inter-
journalière, avec une disponibilité variable des ressources. Enfin, des contraintes
temporelles strictes, liées à l’avancement des projets, limitent fortement l’espace des
solutions réalisables. L’interaction de ces facteurs crée une structure combinatoire com-
plexe, nécessitant des approches d’optimisation avancées pour obtenir des solutions
de qualité dans des temps de calcul raisonnables.

3.2 Description générale du problème

3.2.1 Le défi à résoudre :
L’entreprise doit transporter différents types de marchandises entre deux sites (A et B)
en navettes sur plusieurs semaines. Elle dispose d’une flotte de véhicules variés (capacités
différentes, terrains compatibles différents) et doit respecter des règles strictes :

• Règle des 18h : Aucun conducteur ne peut conduire après 18h (sécurité)ou avant
7h00.

• Pauses obligatoires : Pause toutes les 2h de conduite

• Produits critiques : Certains produits ne peuvent pas être mélangés et doivent être
transportés seules.

Fig. 3.1 : Schéma descriptif des contraintes temporelles

Source : Élaboration personnelle

26
3.2.2 L’objectif :
Minimiser les coûts totaux en optimisant :

• Le choix des véhicules à utiliser chaque semaine .

• La planification des voyages .

• Le chargement des produits .

• Les repositionnements de véhicules .

3.2.3 Les caractéristiques spécifiques :

• Les décisions d’une semaine impactent les suivantes .

• Véhicules différents, produits différents .

• Contraintes temporelles strictes non négociables .

• Les repositionnements de véhicules .

• Anticipation, chargement mixte .

3.3 Modélisation mathématique

3.3.1 Hypothèses du modèle
• Temps de chargement et déchargement constants (1.5h chacun) .

• Produits normaux peuvent être mélangés si capacités le permettent .

• Vitesse moyenne réglementée : 75 km/h .

• Repos conducteurs pris en considération, congés non considérés (remplacement im-

médiat d’un conducteur) .

3.4 Données d’Entrée

3.4.1 Indices et ensembles

S : ensemble des semaines {1, 2, . . . , Ns }

L : ensemble des types de véhicules disponibles
Kℓ = {1, 2, . . . , mℓ } : ensemble des véhicules individuels de type ℓ
∪
K= Kℓ : ensemble de tous les véhicules individuels
ℓ∈L
Ps : ensemble des produits à transporter en semaine s
Ω = {A, B} : ensemble des sites (A = origine, B = destination)

27
3.4.2 Paramètres temporels et réglementaires

s
Hmax : durée maximale autorisée par semaine (7 jours)
Hwork : temps de travail effectif par jour (11 heures)
max
Hdrive : temps de conduite continue maximum (2 heures)
Tbreak : durée d’une pause obligatoire (0.25 heure)
Tnight : durée d’un arrêt nocturne (13 heures)
Hstop : heure limite de conduite quotidienne (18h00)
Tload : temps de chargement par voyage (1.5 heures)
Tunload : temps de déchargement par voyage (1.5 heures)
Vm : vitesse moyenne réglementaire (75 km/h)
D : distance entre A et B (km)

3.4.3 Paramètres géographiques

Ddepot : distance entre le dépôt et le site A (km)

s−1
πℓ,k ∈ Ω : position du véhicule k de type ℓ à la fin de la semaine s − 1
s−1
τℓ,k : instant de disponibilité du véhicule k à la fin de la semaine s − 1

3.4.4 Paramètres des produits

qps : quantité du produit p à transporter en semaine s (unités)

wp : poids unitaire du produit p (tonnes/unité)
vp : volume unitaire du produit p (m³/unité)
κp ∈ {0, 1} : 1 si produit p est critique (homogène obligatoire)

3.4.5 Paramètres de voyages

ℓ,k
Tmax : nombre maximum de voyages possibles par véhicule k de type ℓ par semaine
Ts,ℓ,k = {1, 2, . . . , Tmax
ℓ,k
} : ensemble des voyages possibles du véhicule k en semaine s

3.4.6 Paramètres des véhicules

w
Cℓ,k : capacité en poids du véhicule k de type ℓ (tonnes)
v
Cℓ,k : capacité en volume du véhicule k de type ℓ (m³)
Fℓ : coût fixe par jour pour le type ℓ (DA/jour)
Gℓ : coût variable par kilomètre pour le type ℓ (DA/km)

28
3.4.7 Paramètres de compatibilité terrain-véhicule

Θterrain ∈ {Normal, Accès_difficile}

Tℓ : ensemble des types de terrain compatibles avec véhicule type ℓ
ξℓterrain ∈ {0, 1} : 1 si véhicule type ℓ compatible avec Θterrain

Règles de compatibilité terrain :


 si Θterrain = Normal
1

ξℓterrain = 1 si Θterrain = Accès_difficile et type ℓ ∈ {4 × 4, 6 × 6}



0 sinon

3.5 Variables de Décision

3.5.1 Variables de sélection multi-semaines

xsℓ,k ∈ {0, 1} : 1 si le véhicule k de type ℓ est utilisé en semaine s

s
yp,t,ℓ,k ∈ N : quantité du produit p transportée au voyage t par véhicule k en semaine s
nsℓ,k ∈ N : nombre de voyages assignés au véhicule k de type ℓ en semaine s

3.5.2 Variables d’état temporel continu

Θsℓ,k : instant exact de disponibilité du véhicule k en fin de semaine s (heures)

Σsℓ,k ∈ {A, B} : position exacte du véhicule k en fin de semaine s
Ψs→s+1
ℓ,k : temps de transition inter-semaines pour véhicule k (heures)
Ωdate
ℓ,k (s) : date calendaire de fin d’activité véhicule k en semaine s

3.5.3 Variables temporelles

s
τℓ,k,t : instant de début du voyage t du véhicule k en semaine s
s
δℓ,k,t : instant de fin du voyage t du véhicule k en semaine s
pauses
Nℓ,k,t ∈ N : nombre de pauses repos pour le voyage t
nuits
Nℓ,k,t ∈ {0, 1} : 1 si arrêt nocturne nécessaire pour le voyage t

29
3.5.4 Variables d’anticipation inter-semaines

s,s+1
αp,ℓ,k ∈ N : quantité du produit p de semaine s + 1 anticipée par véhicule k en semaine s
ρsℓ,k ∈ [0, 1] : taux d’utilisation du véhicule k au dernier voyage de semaine s
ϵmin = 0.7 : seuil d’utilisation minimum pour déclenchement d’anticipation

3.5.5 Fonction indicatrice

I(condition) ∈ {0, 1} : fonction indicatrice définie par :


1 si la condition est vraie
I(condition) =
0 si la condition est fausse

3.6 Variables et Paramètres Calculés

3.6.1 Calculs de base

Wprestant : quantité restante du produit p à transporter

s,ℓ,k,last
Wutilis : poids utilisé au dernier voyage du véhicule k
s,ℓ,k,last
Vutilis : volume utilisé au dernier voyage du véhicule k
rℓ,k ∈ {0, 1} : 1 si le véhicule k nécessite un repositionnement en semaine s
s

s,ℓ,k w
Wtransportable = Cℓ,k
σps ∈ N : rang de priorité du produit p selon la densité décroissante en semaine s

3.6.2 Filtrage et Disponibilité des Véhicules

Filtrage de véhicules disponibles par compatibilité terrain :

xsℓ,k = 0 ∀ℓ, k : ξℓterrain = 0

Ensemble de véhicules disponibles filtré :

K compatible = {(ℓ, k) ∈ L × Kℓ : ξℓterrain = 1}

Le processus commence par un filtrage des véhicules selon leur compatibilité avec la nature
du terrain. Cependant, dans le reste du document, on continue avec la notation k pour
les véhicules individuels au lieu de K compatible , afin de faciliter la lecture.
Calcul de la demande totale par semaine en poids et volume :

Wps = qps × wp : poids total du produit p en semaine s

Vps = qps × vp : volume total du produit p en semaine s

30
3.6.3 Calculs temporels et opérationnels
1. Temps de conduite : Temps de conduite pure :
s,t,ℓ,k
pure Def f ectif
Tℓ,k,t =
Vm
Calcul du nombre de pauses :
⌊
pure ⌋
pauses Tℓ,k,t
Nℓ,k,t = max
Hdrive
Temps de conduite total avec pauses :
conduite pure pauses
Tℓ,k,t = Tℓ,k,t + Nℓ,k,t × Tbreak
2. Nombre de voyages estimé :
(⌈ ⌉ ⌈ ⌉)
demande_poids demande_volume
nbVoys,ℓ,k = max w
, v
Cℓ,k Cℓ,k
3. Temps par voyage :
2D
tempsVoys,ℓ,k = + 3.0
Vm
4. Durée d’utilisation :
⌈ ⌉
nbVoys,ℓ,k × tempsVoys,ℓ,k
dureeUtils,ℓ,k =
11
5. Distance totale :
distTots,ℓ,k = nbVoys,ℓ,k × 2D
6. Poids transportable estimé :
( )
poidsTransps,ℓ,k = min nbVoys,ℓ,k × Cℓ,k
w
, demande_poids_restante
Un exemple détaillé d’application de ces formules est présenté dans l’annexe C

3.6.4 Règles de calcul

Le repositionnement consiste à faire en sorte que les véhicules, pour la semaine S+1,
soient présents soit au dépôt, soit sur le site B. Cela implique, le cas échéant, un déplace-
ment à vide depuis leur position actuelle vers le site de chargement, qui est le site A. 1.
Détermination du besoin de repositionnement :


1 si xsℓ,k = 1 et xs−1
ℓ,k = 0 (nouveau véhicule)

s s−1
rℓ,k = 0 si xsℓ,k = 1 et xℓ,k = 1 (véhicule réutilisé)

 s
0 si xℓ,k = 0 (véhicule non utilisé)
2. Calcul de distance de repositionnement :


0
s
si rℓ,k =0

dist_repositionnementsℓ,k = D si rℓ,k = 1 et xs−1
s
ℓ,k = 1



Ddepot s
si rℓ,k = 1 et xs−1
ℓ,k = 0

3. Distance effective par voyage :


2D si voyage intermédiaire avec retour (A→B→A)
s,t,ℓ,k
Def f ectif = D si dernier voyage (A→B, véhicule reste en B)

31
3.7 Fonction Objectif
3.7.1 Fonction objectif principale
∑
min Z = Zs
s∈S
s
où Z est le coût réel de la semaine s :

 
∑ ∑ ∑
xs × Fℓ × nb_jourssℓ,k + Gℓ × Def s 
f ectif + rℓ,k × Gℓ × dist_repositionnementℓ,k
s,t,ℓ,k
Zs = ℓ,k
s

ℓ∈L k∈Kℓ t∈Ts,ℓ,k

Cette section formalise l’ensemble des contraintes prises en compte dans le modèle d’optimisation,
couvrant les aspects de capacité, de durée, de réglementation horaire, de continuité inter-semaines
et de stratégie de chargement .

3.8 Contraintes du Modèle

Les contraintes de capacité assurent que chaque véhicule respecte ses limites maximales de
charge pondérale et volumique à chaque voyage.

3.8.1 Contraintes de capacité par voyage

∑
s
yp,t,ℓ,k × wp ≤ Cℓ,k
w
× xsℓ,k ∀s ∈ S, ∀t ∈ Ts,ℓ,k (1)
p∈Ps
∑
s
yp,t,ℓ,k · vp ≤ Cℓ,k
v
· xsℓ,k ∀s ∈ S, ∀t ∈ Ts,ℓ,k (2)
p∈Ps
 
∑
 s
yp,t,ℓ,k > 0 ⇒ t ≤ nsℓ,k ∀s ∈ S, ∀ℓ ∈ L, ∀k ∈ Kℓ , ∀t ∈ Ts,ℓ,k (3)
p∈Ps

3.8.2 Contrainte de satisfaction de demande :

∑ ∑ ∑
s
yp,t,ℓ,k ≤ qps ∀s ∈ S, ∀p ∈ Ps (4)
ℓ∈L k∈Kℓ t∈Ts,ℓ,k

3.8.3 Contraintes temporelles strictes (règle 18h)

conduite nuits
s
τℓ,k,t + Tℓ,k,t + Tload + Tunload + Nℓ,k,t × Tnight ≤ τℓ,k,t+1
s
(5)

32
Implémentation des contraintes temporelles strictes
Le respect strict des contraintes temporelles réglementaires, notamment l’interdiction
de conduite après 18h00 et avant 7h00, ainsi que les pauses obligatoires toutes les 2 heures,
est assuré par une simulation temporelle complexe intégrée à l’algorithme d’optimisation
. Cette simulation pas-à-pas reproduit fidèlement les conditions opérationnelles réelles en
tenant compte des interruptions nocturnes, des pauses repos et des reports d’activité.
L’implémentation algorithmique de cette simulation, dont le pseudo-code détaillé est
présenté en annexe A et le log détaillé lors de l’implémentation est présen-
té dans l’annexe B , garantit la faisabilité pratique de chaque solution générée par le
modèle d’optimisation. Cette simulation garantit que chaque solution générée par l’algo-
rithme d’optimisation respecte intégralement les contraintes temporelles réglementaires,
assurant ainsi sa faisabilité opérationnelle dans les conditions réelles d’exploitation.
Si l’heure d’arrivée prévue (début + temps de conduite) dépasse 18h00, alors un arrêt
nocturne obligatoire est déclenché.
Hstop = 18h00 : heure limite absolue de conduite quotidienne
N (ℓ, k, t)nuits = 1 : force un arrêt nocturne de 13 heures

3.9 Contraintes de Cohérence Temporelle

Variables d’heure normalisée pour application règle 18h :
conduite
hsℓ,k,t = heure(τℓ,k,t
s
+ Tℓ,k,t ) mod 24
Contrainte de cohérence jour calendaire :
⌊ s ⌋ ⌊ s conduite
⌋
τ ℓ,k,t+1 τℓ,k,t + Tℓ,k,t
≥ ∀t < nsℓ,k (6)
24 24

3.9.1 Contraintes de durée hebdomadaire effective

nsℓ,k
∑( )
conduite nuits
∆sℓ,k = Tℓ,k,t + Tload + Tunload + Nℓ,k,t × Tnight ≤ Hmax
s
× Hwork (7)
t=1

3.9.2 Contraintes de continuité inter-semaines


B si dernier voyage de k en semaine s
s
πℓ,k = (8)
A si retour effectué
Contrainte de continuité temporelle :
s+1
τℓ,k,1 ≥ Θsℓ,k + Ψs→s+1
ℓ,k ∀s < Ns , ∀ℓ, k (9)
Cette équation garantit que le temps nécessaire pour un voyage de repositionnement soit
respecté est inférieur au temps disponible entre deux départs successifs.
Temps de transition selon position :

 si Σsℓ,k = A
0

s→s+1
Ψℓ,k =  VDm si Σsℓ,k = B (10)
D  depot
Vm
si xsℓ,k = 0 et xs+1
ℓ,k = 1

33
3.9.3 Contraintes d’optimisation de chargement
Nous introduisons ici des variables logiques pour gérer les stratégies de chargement
homogène et hétérogène, en priorisant les produits selon leur densité massique :
Variables de stratégie de chargement :

µsℓ,k,t ∈ {0, 1} : 1 si chargement homogène possible pour voyage t

s
νℓ,k,t ∈ {0, 1} : 1 si chargement mixte nécessaire pour voyage t
ηps ∈ R+ : efficacité du produit p pour l’optimisation
ϕsp,ℓ,k,t ∈ {0, 1} : 1 si produit p sélectionné pour voyage t

Chargement mixte par défaut :

s
νℓ,k,t = 1 − µsℓ,k,t (11)

Calcul de la densité pour chargement hétérogène :

wp
ηps = ∀p ∈ Ps
max(vp , 0.001)

Contrainte de rang par densité décroissante :

σps = rang(ηps , ordre décroissant) ∀p ∈ Ps , ∀s ∈ S (12)

Contrainte de sélection séquentielle par densité :

ϕsp,ℓ,k,t = 1 ⇒ νℓ,k,t
s
=1 ∀p ∈ Ps : σps ≤ capacité_limite (13)

3.9.4 Contraintes d’anticipation inter-semaines

Modèle d’anticipation
Quand ρsℓ,k < ϵmin pour le dernier voyage, le modèle résout :
∑
max s,s+1
αp,ℓ,k × wp
p∈Ps+1

Sujet aux contraintes de capacité résiduelle :

Contrainte de capacité résiduelle en poids :
∑ s,s+1
αp,ℓ,k × wp ≤ (Cℓ,k
w
− Wutilis
s,ℓ,k,last
) × I(ρsℓ,k < ϵmin ) (14)
p∈Ps+1

Contrainte de capacité résiduelle en volume :

∑ s,s+1
αp,ℓ,k × vp ≤ (Cℓ,k
v
− Vutilis
s,ℓ,k,last
) × I(ρsℓ,k < ϵmin ) (15)
p∈Ps+1

Contrainte de mise à jour des demandes :

∑ ∑
qps+1 ← qps+1 − s,s+1
αp,ℓ,k ∀p ∈ Ps+1 (16)
ℓ∈L k∈Kℓ

34
 Conditions de déclenchement de l’anticipation :


ρsℓ,k < ϵmin = 0.7




|Ps+1 | > 0


s,s+1
αp,ℓ,k > 0 ⇐⇒ (C w − W s,ℓ,k,last ) > 0 (17)


ℓ,k utilis



(C v
− V s,ℓ,k,last
)>0


ℓ,k utilis
 terrain
ξℓ =1

Ce mécanisme d’anticipation est spécifiquement appliqué aux derniers voyages de chaque

semaine, car ce sont eux qui présentent le plus souvent une utilisation partielle des capaci-
tés logistiques. L’objectif est d’optimiser ces trajets en y intégrant, de manière anticipée,
une partie de la demande de la semaine suivante. Les contraintes (14) et (15) garantissent
que le poids total et le volume total du produit p de semaine s + 1 anticipé par véhicule
k en semaine s ne dépassent pas la capacité de ce véhicule. La contrainte (16) garantit la
mise à jour des demandes de la semaine prochaine après leurs anticipations.La contrainte
(17) garantit le respect strict de toutes les conditions avant de lancer une anticipation.
Calcul de l’instant de disponibilité finale :
conduite
Θsℓ,k = τℓ,k,n
s
s
ℓ,k
+ Tℓ,k,n s
ℓ,k
+ Tunload (18)

Position finale selon type de voyage :


B si dfℓ,k,n
inal
s = 1 (dernier voyage sans retour)
Σsℓ,k = ℓ,k
(19)
A si retour effectué ou repos au dépôt

3.10 Contraintes d’Intégrité et de Domaine

Domaines des variables :

xsℓ,k ∈ {0, 1}, nsℓ,k ∈ N, s

yp,t,ℓ,k ∈ N, s,s+1
αp,ℓ,k ∈N (20)
nuits pauses
Nℓ,k,t ∈ {0, 1}, Nℓ,k,t ∈ N, s
τℓ,k,t s
, δℓ,k,t , Θsℓ,k ≥0 (21)

Bornes et cohérence :

0 ≤ nsℓ,k ≤ Tmax
ℓ,k
× xsℓ,k (22)
s
yp,t,ℓ,k ≤ qps , s,s+1
αp,ℓ,k ≤ qps+1 (23)
s
δℓ,k,t ≥ s
τℓ,k,t , xsℓ,k ≤ ξℓterrain (24)

Activation des voyages :

∑
s
yp,t,ℓ,k ≤ M × I(t ≤ nsℓ,k ) ∀s, t, ℓ, k (25)
p∈Ps

Produits critiques (chargement homogène) :

∑
s
I(yp,t,ℓ,k > 0) ≤ 1 ∀p ∈ Ps : κp = 1 (26)
t∈Ts,ℓ,k

Plage horaire légale :

7 ≤ heure(τℓ,k,t
s
) ≤ 18, 7 ≤ heure(δℓ,k,t
s
) ≤ 18 (27)

35
3.11 Algorithme de Résolution
3.11.1 Critère de sélection glouton
Pour chaque semaine s et à chaque itération, sélectionner le véhicule minimisant :
duree_utilisations,ℓ,k × Fℓ + distance_totale_estimees,ℓ,k × Gℓ + dist_repositionnementsℓ,k × Gℓ
ϕsℓ,k =
poids_transportable_estimes,ℓ,k

3.12 Algorithme principal

Algorithme 2 Heuristique Gloutonne Multi-Semaines

Entrées : Demandes {Ps }s∈S , Flotte {Kℓ }ℓ∈L
Sorties : Planning {xsℓ,k , yp,t,ℓ,k
s
}
1: INITIALISATION :
2: pour ℓ ∈ L, k ∈ Kℓ faire
3: 0
πℓ,k ← A, τℓ,k 0
← instant_début
4: end pour
5: pour s = 1 à Ns faire
6: Demandes_restantes ← Ps
7: Flotte_disponible ← K
8: ÉTAPE 1 - TRAITEMENT ÉQUIPEMENTS CRITIQUES :
9: P critique ← {p ∈ Demandes_restantes : κp = 1}
10: pour p ∈ P critique faire
p,ℓ,k
11: Calculer qmax pour tous véhicules disponibles
∗ ∗ Coûts
12: (ℓ , k ) ← arg minℓ,k qp,ℓ,kℓ,k
max
13: Charger p dans véhicule (ℓ∗ , k ∗ ) (chargement homogène)
14: Retirer (ℓ∗ , k ∗ ) de Flotte_disponible
15: Retirer p de Demandes_restantes
16: end pour
17: ÉTAPE 2 - HEURISTIQUE GLOUTONNE STANDARD :
18: tant que Demandes_restantes ̸= ∅ et Flotte_disponible ̸= ∅ faire
19: (ℓ∗ , k ∗ ) ← arg minℓ,k ϕsℓ,k (critère standard)
20: Planifier voyages avec chargement mixte optimal
21: Mettre à jour listes
22: end tant que
23: end pour

3.13 Propriétés du Modèle

3.13.1 Complexité algorithmique
• Complexité temporelle : O(|S| × |K| × |P |)
• Complexité spatiale : O(|S| × |K| × |T |)
• Scalabilité : Linéaire par rapport au nombre de semaines

36
3.13.2 Garanties de qualité
• Faisabilité : Respect garanti de toutes les contraintes

• Optimalité locale : Choix glouton optimal à chaque étape

3.14 Résultats obtenue

Tab. 3.1 : Résultats de l’optimisation sur 12 semaines

Métrique Valeur Unité Détail

Nombre de semaines 12 semaines Du 2025-06-09 au 2025-08-25
Statut optimisation RÉUSSIE Taux de réussite : 100.0%
Coût total 88 830 719,2 DA
Coût moyen par semaine 7 402 559,933 DA
Véhicules utilisés total 24 véhicules Toutes semaines confondues
Poids total transporté 1 315,5 tonnes 12 types de produits
Volume total transporté 11 167 m³
Coût par tonne 67 526,20236 DA/tonne
Coût par volume 7 957,32 DA/m³

Fig. 3.2 : Taux d’utilisation poids et volume moyens par semaine des véhicules générés par la
solution

Source : Exportée depuis le solveur d’optimisation, réalisée par l’étudiante.

37
Fig. 3.3 : Fichier Excel des voyages générés

Source : Exportée depuis le solveur d’optimisation, réalisée par l’étudiante.

3.15 Justificatifs des résultats

3.15.1 Analyse des contraintes spécifiques au transport d’équi-
pements géophysiques
Les résultats obtenus révèlent une utilisation volumétrique de 100 %, contrastant avec
une utilisation pondérale relativement faible. Cette apparente sous-optimisation appelle
une analyse approfondie, notamment en lien avec les caractéristiques spécifiques du trans-
port d’équipements géophysiques pour ENAGEO.

3.15.2 Nature des équipements transportés

Les matériels acheminés vers les chantiers géophysiques du Sahara algérien présentent
des caractéristiques particulières, expliquant les résultats observés :
Équipements modulaires et préfabriqués :

• Baraques de chantier démontables (densité moyenne : 80–150 kg/m³)

• Conteneurs techniques et de stockage (60–120 kg/m³ à vide)

• Équipements électroniques de traitement de données

• Générateurs et équipements électriques (densité variable : 100–300 kg/m³)

• Citernes d’eau et de carburant (transportées à vide vers les sites)

La liste d’équipements détaillée utilisée dans le test est présentée dans l’annexe D.

3.15.3 Contraintes techniques justifiant l’utilisation volumétrique

prioritaire
Indivisibilité des charges
Contrairement aux marchandises traditionnelles, les équipements géophysiques pré-
sentent une contrainte d’indivisibilité fondamentale :

38
 • Une baraque de chantier constitue une unité fonctionnelle complète

• Les conteneurs techniques ne peuvent être fractionnés

• Les équipements spécialisés forment des ensembles cohérents

Cette indivisibilité impose une optimisation basée sur le volume plutôt que sur le poids,
créant une priorité d’optimisation volumétrique sur l’optimisation pondérale. Pour illus-
tration, le transport de baraques avec une densité de 118 kg/m³ entraîne une saturation en
volume avant poids, imposant une approche logistique spécifique et expliquant l’utilisation
volumétrique maximale observée.

3.15.4 Justification économique de l’approche volumétrique

Valeur ajoutée des équipements
La nature haute valeur ajoutée des équipements géophysiques justifie une approche
de transport privilégiant la sécurité et l’intégrité (avec le mécanisme de chargement ho-
mogène pour ces produits critiques) plutôt que l’optimisation pondérale :

• Équipements scientifiques de précision (coût unitaire élevé)

• Matériel spécialisé à forte valeur technologique

• Impossibilité de remplacement rapide en cas de dommage

Cette composition explique directement la densité moyenne observée de 118 kg/m³,

parfaitement cohérente avec les caractéristiques physiques des équipements identifiés.

3.15.5 Implications pour l’optimisation logistique

L’optimisation logistique pour ENAGEO doit privilégier :

• La planification volumétrique plutôt que pondérale

• La protection des équipements comme critère prioritaire

• La flexibilité opérationnelle face aux contraintes terrain

Indicateurs de performance adaptés

Les indicateurs de performance traditionnels (taux de charge pondérale) ne sont
pas pertinents pour évaluer l’efficacité du transport géophysique. Il convient de privilégier :

• Taux d’utilisation volumétrique proche de l’objectif optimal (100%) grâce à notre

solution.

• Respect des délais de livraison sur site( La solution garantit le respect stricte des
contraintes temporelles)

• Coût par m³ transporté (7 957,32 DA/m³)

39
3.16 Modélisation UML de la solution
Le Unified Modeling Language (UML) constitue un langage de modélisation graphique
standardisé permettant de visualiser, spécifier, construire et documenter les artefacts des
systèmes logiciels. Développé et maintenu par l’Object Management Group (OMG), UML
offre une notation standardisée pour représenter les systèmes orientés object ((OMG),
2017).

3.16.1 Diagramme de Cas d’Utilisation

Le diagramme de cas d’utilisation représente les fonctions attendues du système et son
interaction avec l’environnement. Il constitue une base de communication entre le client
et les développeurs (OMG), 2017.
Composants principaux :

• Acteurs : entités externes (gestionnaire de flotte, chauffeurs, clients)

• Cas d’utilisation : fonctionnalités du système (planifier les tournées, optimiser les

itinéraires)

• Relations : associations entre acteurs et fonctionnalités

• Frontière système : délimitation du périmètre de l’application

Diagrammes de cas d’utilisation

application mobile pour les conducteurs

Fig. 3.4 : Diagramme de cas d’utilisation – Application Mobile

Source : Élaboration personnelle

Fig. 3.5 : Diagramme de sequence ConducteurDiagramme de cas d’utilisation – Application

Mobile

Source : Élaboration personnelle

40
Fig. 3.6 : Diagramme de cas d’utilisation – Application Mobile

Source : Élaboration personnelle

Fig. 3.7 : Diagramme de cas d’utilisation – Application Mobile

Source : Élaboration personnelle

Fig. 3.8 : Diagramme de cas d’utilisation – Application Mobile

Source : Élaboration personnelle

41
3.16.2 Diagramme de classe
Ce diagramme décrit la structure statique du système en représentant les classes, leurs
attributs, méthodes et relations ((OMG), 2017).
Éléments structurels :

• Classes : entités (Véhicule, Tournée, Client, Commande)

• Attributs : capacité, position, horaires

• Opérations : calculerDistance(), optimiserTournée()

• Relations : associations, agrégations, compositions, héritage

Le diagramme suivant présente une architecture logistique organisée en quatre modules :

Gestion : Les classes Chantier, Commande et Affectation gèrent les sites de livraison,
affichage des commande, et assurent la traçabilité des assignations conducteur-vehicule-
mission.
Ressources : Conducteur et Véhicule modélisent les ressources opérationnelles avec
gestion de disponibilité.
Équipement : Trois classes (Équipement, CommandeEquipement, TransfererEqui-
pement) gèrent les équipements, CommandeEquipement est une classe de relation entre
commande et équipements et Transferer-Equipement est une classe incluant une planifi-
cation sur 13 semaines.
Transport : Tournée et EtapeRotation centralisent les déplacements avec suivi dé-
taillé par étapes.
Cette architecture modulaire facilite la maintenance et l’évolutivité du système.

42
Fig. 3.9 : Diagramme de classe du système de gestion de transport

Source : Élaboration personnelle

43
3.16.3 Diagrammes de séquence
Le diagramme de séquence illustre les échanges temporels entre objets pour exécuter
un scénario spécifique d’un cas d’utilisation ((OMG), 2017).
Éléments temporels :

• Objets participants : instances des classes

• Lignes de vie : durée d’existence des objets

• Messages : appels synchrones ou asynchrones

• Fragments combinés : boucles, alternatives conditionnelles

1. Conducteur – Application Mobile

Acteur : Conducteur
Objectif : Consulter les missions de livraison et enregistrer l’état d’avancement.
Scénario d’utilisation :

1. Lancer l’application mobile.

2. S’authentifier avec ses identifiants.

3. Visualiser la liste des missions planifiées (par jour/semaine).

4. Démarrer une mission.

5. Valider manuellement les étapes (chargement, livraison…)

6. Clôturer la mission.

7. Synchroniser les données avec le serveur .

44
Fig. 3.10 : Diagramme de sequence Conducteur – Application Mobile

Source : Élaboration personnelle

2. Client – Web Service

Acteur : Client (externe)
Objectif : Faire une demande.
Scénario d’utilisation :

1. Accéder à l’interface web .

2. S’authentifier .

3. Déposer une commande.

4. confirmer.

45
Fig. 3.11 : Diagramme de sequence Client – Web Service

Source : Élaboration personnelle

3. Gestionnaire – Interface ttkbootstrap (Desktop)

Acteur : planificateur
Objectif : Gérer les tournées, assigner les véhicules, suivre les indicateurs.
Scénario d’utilisation :

1. Lancer l’application desktop.

2. S’authentifier.

3. Visualiser et modifier le planning des tournées.

4. Affecter les véhicules et les chauffeurs.

5. Exporter des rapports (Excel, PDF).

6. Visualiser les KPI : taux de remplissage, retards, distances…

46
Fig. 3.12 : Diagramme de sequence Gestionnaire – Interface ttkbootstrap (Desktop)

Source : Élaboration personnelle

3.17 Conclusion
La modélisation mathématique développée dans ce chapitre optimise le transport des
équipements durant les DTM en minimisant les coûts opérationnels. La classification du
problème comme un MC-SVRP-TC intègre les contraintes spécifiques ENAGEO : flotte
hétérogène, horaires 7h-18h et continuité inter-semaines. L’heuristique gloutonne propo-
sée, avec son critère de sélection ϕsℓ,k et l’algorithme d’anticipation, garantit une allocation
optimale des ressources tout en respectant les contraintes réglementaires.

La modélisation UML complète cette approche en structurant les exigences fonction-

nelles et l’architecture logicielle adaptée . Les diagrammes développés facilitent la re-
présentation des interactions entre les composants et assurent la cohérence du système
multi-plateforme développé.

47
Chapitre 4

Implémentation et expérimentation

introduction
Après avoir défini les exigences fonctionnelles et conçu l’architecture de notre sys-
tème à l’aide d’outils de modélisation adaptés, cette partie du travail est consacrée à
la phase d’implémentation concrète de notre solution. Il s’agit ici de passer de la théo-
rie à la pratique en détaillant les choix technologiques adoptés, les outils utilisés et les
expérimentations menées.
Dans ce chapitres , nous présentrons d’abord les raisons ayant guidé notre choix vers
une architecture hybride multi-plateforme, combinant une interface desktop performante
avec une infrastructure cloud distribuée, particulièrement adaptée aux problèmes d’opti-
misations complexes et les calcules intensifs. Ensuite, nous détaillerons les technologies
mobilisées pour le développement de la plateforme. Enfin, nous présenterons l’environne-
ment de développement moderne adopté . L’objectif de cette phase est de démontrer la
faisabilité technique de la plateforme hybride, de valider l’intégration des différents com-
posants (desktop, mobile, web) et de présenter les fonctionnalités implémentées prêtes
pour l’évaluation opérationnelle.

4.1 Environnement de développement

4.1.1 python
Python est un langage de programmation interprété, orienté objet et de haut niveau,
reconnu pour sa syntaxe simple et lisible. Il facilite le développement rapide d’applica-
tions, l’analyse de données, l’automatisation, le développement web, et bien plus encore.
(Python Software Foundation, 2025)

4.1.2 ttkboostrap
TtkBootstrap est une bibliothèque Python qui améliore l’apparence et la convivialité
des applications graphiques créées avec Tkinter. Elle propose des thèmes modernes inspirés
de Bootstrap . TtkBootstrap étend les widgets standards de Tkinter pour offrir plus de
flexibilité et d’options de personnalisation. Ce choix garantit une expérience utilisateur
agréable, tout en conservant la simplicité d’intégration de Tkinter. Developer Service,
2024

48
4.1.3 SQLAlchemy
SQLAlchemy est une bibliothèque open source pour Python qui fournit un ensemble
d’outils SQL et un ORM (Object Relational Mapper) pour interagir avec des bases de
données relationnelles. Elle permet aux développeurs de manipuler des bases de données
via des objets Python, facilitant la création, la requête et la gestion des schémas de bases
de données tout en restant compatible avec de nombreux systèmes de gestion de bases de
données, facilitant ainsi les opérations CRUD (Create, Read, Update, Delete) sans écrire
directement du SQL.

4.1.4 les autres bibliothéques

Folium : Folium est une bibliothèque Python qui permet de créer des cartes interac-
tives et des visualisations géospatiales en s’appuyant sur la bibliothèque JavaScript
Leaflet.js. Elle est idéale pour afficher et analyser des données géographiques, l’af-
fichage des trajets, des points de passage et des résultats d’optimisation de tour-
nées.(Folium Contributors, 2025)

Pandas : Pandas est une bibliothèque Python dédiée à la manipulation et à l’analyse

de données. Elle propose des structures de données puissantes comme les Data-
Frames, ainsi que des fonctions pour nettoyer, explorer, transformer et analyser des
ensembles de données volumineux ou complexes. Pandas est un outil incontournable
en science des données et en analyse statistique.

OSRM : OSRM est un moteur de routage open source qui fournit des fonctionnalités
de planification d’itinéraires, de navigation et d’analyse de réseaux de transport.
Basé sur les données d’OpenStreetMap, il permet de calculer rapidement les itiné-
raires optimaux entre plusieurs points, ce qui le rend particulièrement utile pour les
applications de logistique, de mobilité et de planification de trajets.

Flask : Flask est un micro-framework web développé en Python, reconnu pour sa simpli-
cité et sa flexibilité. Il permet de créer rapidement des applications web ou des API
grâce à une structure légère, tout en offrant la possibilité d’ajouter des fonctionnali-
tés selon les besoins du projet via des extensions. Ce choix technologique s’explique
par sa facilité de prise en main, sa rapidité de développement et son adaptabilité à
différents types de projets.

HTML/CSS Le formulaire de commande est conçu en HTML pour la structure et en

CSS pour le style. L’interface utilisateur est moderne et responsive, avec une at-
tention particulière portée à l’ergonomie et à l’accessibilité. L’utilisation de styles
personnalisés et de composants comme les barres de progression ou les alertes contri-
bue à une expérience utilisateur fluide et professionnelle .

API REST L’architecture REST est adoptée pour structurer les échanges entre le fron-
tend et le backend. Les routes /api/commandes et /api/equipements permettent
de créer, consulter et manipuler les données au format JSON, ce qui favorise la
modularité, la réutilisabilité et l’intégration avec d’autres systèmes ou applications.

49
4.1.5 Architecture de l’environnement
Notre environnement de développement s’articule autour d’une architecture moderne
combinant développement local, versionnage distribué, et déploiement cloud distribué.
L’application suit une approche client-serveur avec une API REST déployée sur Render,
une base de données MySQL hébergée sur Railway, et une interface utilisateur desktop
locale.

4.1.6 Technologies et outils utilisés

Le tableau 4.1 présente de manière exhaustive l’ensemble des technologies employées
dans ce projet, accompagnées de leur utilisation spécifique et de leur justification.

Tab. 4.1 : Outils et plateformes de développement

Outil/PlateformeUtilisation spécifique Justification du choix

Python 3.x Langage principal de déve- Écosystème riche, syntaxe claire, nom-
loppement breuses bibliothèques pour le dévelop-
pement web et GUI
GitHub Versionnage et collabora- Plateforme de référence pour le version-
tion nage Git, fonctionnalités avancées de
suivi des modifications
Railway Hébergement de la base de Déploiement automatisé de la BD,
données MySQL configuration simplifiée, intégration na-
tive avec les services web
Render Déploiement de l’API Flask Déploiement automatisé des services
web, intégration Git native, scaling au-
tomatique
MySQL Base de données relation- Base de données robuste hébergée sur
nelle Railway, support excellent pour les ap-
plications web
Flask Framework web pour l’API Framework léger et flexible, documen-
REST tation complète, écosystème mature
SQLAlchemy ORM (Object-Relational Abstraction de la base de données, re-
Mapping) quêtes Python intuitives, gestion avan-
cée des relations
Alembic Gestion des migrations de Migrations versionnées, intégration na-
BD tive avec SQLAlchemy, suivi de l’évo-
lution du schéma
ttkbootstrap Interface utilisateur desktop Thèmes modernes pour Tkinter, com-
posants stylisés, développement rapide
d’interfaces
VS Code Environnement de dévelop- Éditeur polyvalent, extensions Python
pement riches, débogage intégré
Git Contrôle de version local Système de versionnage distribué,
branching efficace, historique complet
des modifications
Source : Élaboration personnelle

50
4.2 présentation de l’application Desktop
L’application est structurée en 9 pages :

4.2.1 La page d’authentification

Fig. 4.1 : La page d’authentification principale

Source : élaborée par l’étudiante

4.2.2 la page accueil

Une interface avec boutons hyperliés permettant d’accéder aux différentes sections de
l’application .

Fig. 4.2 : Page d’accueil desktop

Source : élaborée par l’étudiante

51
La vue RH

Fig. 4.3 : fenêtre du gestion des conducteurs

Source : élaborée par l’étudiante

La vue Assistant bien d’équipements

Fig. 4.4 : fenêtre 2 du statistiques des tournées

Source : élaborée par l’étudiante

Cette interface de gestion de flotte centralise les informations essentielles des véhicules
d’ENAGEO : immatriculation, caractéristiques techniques, capacités et état de disponi-
bilité. Elle intègre des fonctionnalités de recherche, filtrage par statut, et des actions
CRUD complètes (ajout, modification, suppression), ainsi qu’une fonction d’export pour
le reporting administratif.

52
4.2.3 la page équipements

Fig. 4.5 : fenêtre du gestion des équipements

Source : élaborée par l’étudiante

4.2.4 la page chantiers

Fig. 4.6 : gestion des chantiers

Source : élaborée par l’étudiante

On peut voir l’historique des commandes associées à chaque chantier, voir annexe .

53
4.2.5 la page commandes

Fig. 4.7 : fenêtre du gestion des commande

Source : élaborée par l’étudiante

Fig. 4.8 : Fenêtre statistiques des commandes – Partie 1

Source : élaborée par l’étudiante

Fig. 4.9 : Fenêtre statistiques des commandes – Partie 2

Source : élaborée par l’étudiante

54
4.2.6 la page conducteurs

Fig. 4.10 : fenêtre vue globale conducteurs

Source : élaborée par l’étudiante

4.2.7 la page transférer équipements

Cette feuille calcule automatiquement le nombre de vehicules minimale qu il faut
utiliser pour deplacerer tous les équipements efficacaemnt Lors de la periode des DTM

Fig. 4.11 : Fenêtre du transfert d’équipements

Source : élaborée par l’étudiante

Fig. 4.12 : Fenêtre du formulaire de transfert

Source : élaborée par l’étudiante

55
Fig. 4.13 : fenêtre d’exécution de l’heuristique

Source : élaborée par l’étudiante

4.2.8 la page tournées

Fig. 4.14 : fenêtre du gestion des tournées

Source : élaborée par l’étudiante

Cette interface de gestion des tournées présente les missions avec filtrage avancé par conducteur, véh

Note : Le formulaire de création des tournées est présenté dans l’annexe E .

56
Fig. 4.15 : fenêtre statistiques des tournée 1

Source : élaborée par l’étudiante

Fig. 4.16 : fenêtre statistiques des tournée 1

Source : élaborée par l’étudiante

Fig. 4.17 : fenêtre 2 du statistiques des tournées

Source : élaborée par l’étudiante

Cette interface présente la vue planificateur du module véhicules, offrant une consul-
tation en lecture seule de la flotte disponible. Contrairement à l’interface assistant, le

57
planificateur dispose uniquement des fonctions de consultation et de filtrage, sans accès
aux opérations CRUD (création, modification, suppression). L’interface affiche les infor-
mations essentielles pour la planification des tournées : état de disponibilité, capacités
de charge, types de véhicules et caractéristiques techniques, permettant une sélection
optimale des ressources selon les besoins des missions. Le même principe s’applique aux
équipements, permettant au planificateur de consulter les équipements disponibles et leurs
informations relatives pour optimiser l’affectation des ressources.

4.2.9 La page cartographie

Fig. 4.18 : Page cartographie

Source : élaborée par l’étudiante

En effet, dans les zones désertiques algériennes, les chantiers d’ENAGEO sont souvent
reliés par des pistes ou des voies sablées qui n’apparaissent pas sur les cartes standard
comme OpenStreetMap. Par conséquent, le service OSRM ne peut pas calculer les itiné-
raires réels pour ces zones non cartographiées. Pour pallier cette limitation, nous avons
développé une fonctionnalité d’intégration de tracés personnalisés, exploitant les plans
d’itinéraires spécifiques fournis par l’équipe topographique d’ENAGEO (voir Annexe J
pour un exemple de trajet spécifique). Cette carte interactive distingue visuellement les
routes existantes (tracés en vert) des connexions non disponibles (lignes droites en bleu).
La solution implémentée offre deux méthodes d’ajout de tracés personnalisés : l’import
de fichiers GPX fournis par les topographes, et la saisie manuelle de points géographiques
pour construire les arcs routiers manquants. Cette approche permet d’obtenir une carto-
graphie précise et opérationnelle des zones d’intervention, essentielle pour la planification
optimale des tournées en terrain difficile.

les indicateurs de performance KPI

Les graphiques intégrés offrent une visualisation claire des données opérationnelles :
kilométrages par conducteur et véhicule, nombre de tournées mensuelles, durées moyennes
des missions, et disponibilité de la flotte par période. Ces outils d’aide à la décision per-
mettent aux gestionnaire d’identifier rapidement les goulots d’étranglement, d’optimiser

58
l’utilisation des ressources et d’améliorer l’efficacité opérationnelle globale du système de
transport.

4.2.10 Fenêtre de commande clients

Fig. 4.19 : Formulaire de commande web

Source : élaborée par l’étudiante

Cette interface représente un formulaire de commande web développé en HTML, CSS

et JavaScript, permettant aux clients d’ENAGEO de soumettre leurs demandes de trans-
port de manière autonome .

59
4.2.11 application mobile pour les conducteurs

Fig. 4.20 : Authentification du chauf-

Fig. 4.21 : Interface principale
feur
Source : élaborée par l’étudiante
Source : élaborée par l’étudiante

Fig. 4.22 : Affichage de la mission du

conducteur Fig. 4.23 : Étapes de la mission en
cours
Source : élaborée par l’étudiante
Source : élaborée par l’étudiante
60
4.2.12 Jeu de Données de Test
Dans le cadre du développement de l’application desktop de gestion des tournées ,
un jeu de données fictif a été conçu afin de simuler des scénarios réalistes de livraison et
d’approvisionnement. L’objectif est de valider l’ensemble des fonctionnalités du système,
notamment les opérations CRUD, les tableaux de bord, les calculs liés aux tournées, ainsi
que les différentes contraintes logistiques.
Les types de véhicules utilisés dans les tests sont identiques à ceux réellement dispo-
nibles au sein de l’entreprise, à l’exception des immatriculations, volontairement rempla-
cées par des valeurs fictives pour des raisons de confidentialité. Le même principe a été
appliqué aux conducteurs : cinq profils fictifs ont été créés pour simuler diverses situations
opérationnelles.
Concernant les équipements, les poids et volumes utilisés dans les données de test cor-
respondent à ceux réellement manipulés par l’entreprise. De plus, l’ensemble des contraintes
du système (capacités, disponibilités, règles métier, etc.) a été reproduit fidèlement, confor-
mément aux spécificités réelles de l’environnement de travail. Cette approche permet d’as-
surer la pertinence des tests tout en respectant les exigences de confidentialité des données
sensibles.

4.2.13 Fonctionnement en terrain désertique

Défis techniques spécifiques
L’utilisation d’applications mobiles en zones désertiques présente des contraintes par-
ticulières que notre solution doit adresser :
Connectivité intermittente : Les zones d’intervention d’ENAGEO sont souvent
caractérisées par une couverture réseau cellulaire faible ou inexistante, nécessitant une
approche adaptée pour maintenir la fonctionnalité de l’application.
Conditions environnementales extrêmes : Les températures élevées, la poussière
et les vibrations des véhicules tout-terrain imposent des contraintes supplémentaires sur
les équipements mobiles.
Précision géographique critique : La localisation précise des équipements et vé-
hicules est essentielle pour la sécurité et l’efficacité opérationnelle dans des espaces vastes
et peu différenciés.

Solutions implémentées
Architecture de communication adaptée : L’application mobile tire parti de
l’infrastructure existante d’ENAGEO, qui dispose de connexions Thuraya satellitaires
dans les bases de départ et d’arrivée. Cette configuration permet une communication
fiable aux points critiques du processus.
Processus optimisé pour les contraintes terrain : Le processus de suivi se limite
aux événements essentiels : confirmation de début de mission au point A (base de départ)
et confirmation de fin de mission au point B (base d’arrivée). Cette approche minimise
les besoins de connectivité tout en assurant la traçabilité nécessaire.

61
4.3 Conclusion
Ce chapitre a démontré la faisabilité technique de notre solution de gestion des tournées
pour ENAGEO, traduisant les modélisations théoriques en système opérationnel. L’implé-
mentation d’une architecture hybride multi-plateforme répond aux besoins diversifiés des
acteurs du processus logistique, offrant une interface desktop pour la gestion intensive,
une API pour l’interopérabilité, et une application mobile adaptée aux contexte d’opti-
misation. Les solutions développées pour pallier les défis de l’environnement désertique -
connectivité intermittente, zones non cartographiées, conditions extrêmes - valident l’ap-
proche adoptée et assurent la continuité opérationnelle dans le contexte spécifique d’EN-
AGEO.

62
Conclusion générale

Ce projet de fin d’études a permis de développer un système complet de gestion et

d’optimisation logistique spécialement conçu pour répondre aux défis complexes de l’en-
vironnement désertique. Les principales réalisations de ce travail se traduisent par :

• Gestion complète des entités métier : Interfaces CRUD dédiées pour la gestion
des conducteurs, véhicules, équipements, chantiers et commandes, offrant une vision
globale et centralisée des ressources disponibles.

• Optimisation algorithmique : Module de calcul automatique du nombre minimal

de véhicules pour les transferts d’équipements (DTM) et un ordonnancement détaillé
de ces opérations sur un échelon de trois mois, permettant une allocation optimale
des ressources selon les contraintes opérationnelles.

• Synchronisation des données en temps réel : Application mobile permettant

aux conducteurs de valider les étapes critiques et synchroniser leur progression avec
le système central.

Malgré ces avancées significatives, l’analyse critique du système développé révèle cer-
taines limitations qu’il convient de reconnaître. Ces contraintes constituent autant d’axes
d’amélioration pour les développements futurs :

• Traitement séquentiel : L’algorithme d’optimisation traite les semaines de ma-

nière séquentielle, sans exploiter les possibilités de parallélisation qui pourraient
considérablement réduire les temps de calcul.

• Courbe d’apprentissage : L’adoption de nouveaux processus digitalisés nécessite

une période d’adaptation pour les utilisateurs habitués aux méthodes tradition-
nelles surtout pour les conducteurs, ça nécessite une formation et une adaption au
processus de confirmation de débuts de mission et clôture des missions.

• Validation quantitative insuffisante : L’absence de mesures comparatives avec

l’ancien système constitue une limitation dans l’évaluation précise des gains de per-
formance. Une étude comparative approfondie permettrait de quantifier objective-
ment les améliorations apportées.

L’expérience acquise au cours de ce développement ouvre plusieurs perspectives d’amé-

lioration prometteuses qui méritent d’être explorées dans le cadre d’évolutions futures du
système :

• Parallélisation des calculs : La perspective la plus prometteuse consiste à paral-

léliser l’algorithme sur plusieurs niveaux : parallélisation par semaine pour traiter

63
 plusieurs semaines simultanément sur différents cœurs processeurs, ce qui réduirait
considérablement le temps de calcul total ; VNS parallèle pour explorer simulta-
nément différents voisinages (k = 1, 2, 3, 4) sur plusieurs threads, permettant une
convergence plus rapide ; et évaluation parallèle des véhicules pour analyser simul-
tanément plusieurs candidats véhicules lors de la phase de sélection gloutonne.
Exploration de métaheuristiques spécialisées : Étant donné la rareté des travaux
sur cette combinaison complexe de variantes VRP (Shuttle + Multi-Commodity + Open
+ Periodic + Time Windows + Heterogeneous Fleet), l’exploration de nouvelles méta-
heuristiques pourrait générer des résultats significativement meilleurs.
Mode hors ligne : Développement de capacités de fonctionnement dégradé pour l’ap-
plication mobile en cas de connectivité intermittente.
Interfaces utilisateur avancées : Amélioration de l’ergonomie des interfaces existantes
basée sur les retours d’utilisation terrain.
Intégration de données météorologiques : Prise en compte des conditions climatiques
dans la planification des tournées.
Intégration ERP : Développement d’interfaces avec les systèmes de gestion existants
de l’entreprise.
Basées sur les observations de terrain et l’analyse des besoins opérationnels d’EN-
AGEO, les recommandations pour l’amélioration continue s’articulent autour d’une ap-
proche progressive et réaliste. À court terme, il est essentiel de mettre l’accent sur la
formation continue du personnel, car l’observation de terrain révèle une courbe d’appren-
tissage nécessaire à l’adoption des nouveaux processus digitalisés.
L’amélioration des processus de chargement représente un autre axe prioritaire. Il
est nécessaire d’optimiser ces processus en renforçant les équipes dédiées et spécialisées
dans la préparation et la gestion des cargaisons avant leur départ, ce qui permettra de
minimiser le temps post-conduite et d’augmenter l’efficacité globale des opérations. Par
ailleurs, l’automatisation complète des processus administratifs contribuera à réduire le
temps perdu par les chauffeurs dans des tâches non prioritaires, augmentant ainsi leur
productivité et réduisant les délais au sein de la chaîne logistique.
À moyen terme, la mise en place d’un système de maintenance prédictive devient un
élément clé de la stratégie opérationnelle. Dans un contexte de flotte hétérogène, marqué
par une disponibilité réduite des pièces de rechange et la présence d’équipements coûteux
comme les grues et les porte-chars, l’intégration d’un tel système permettrait de prévoir les
défaillances avant qu’elles ne surviennent. Cette approche permettrait de réduire les coûts
de réparation, d’anticiper les besoins en pièces détachées, et d’assurer une disponibilité
optimale de la flotte en évitant les pannes imprévues.
À long terme, la centralisation d’un dépôt au centre du désert constitue un défi lo-
gistique majeur ainsi qu’un projet d’envergure, mais offre une perspective stratégique
intéressante. Étant donné l’emplacement actuel du dépôt à Hassi Messaoud, éloigné de la
majorité des chantiers, la création d’un dépôt secondaire au centre du désert permettrait
de réduire les coûts de transport, de diminuer les distances parcourues, et d’améliorer
la réactivité en cas d’urgence. Une étude approfondie sur les apports opérationnels et
les économies potentielles générées par ce projet serait particulièrement pertinente pour
évaluer sa faisabilité et son retour sur investissement. Ce projet de fin d’études démontre
concrètement comment les défis logistiques des environnements désertiques peuvent être
relevés par l’application judicieuse de technologies modernes et d’approches d’optimisation
adaptées.

64
Bibliographie

Braekers, K., Ramaekers, K., & Van Nieuwenhuyse, I. (2016). The vehicle rou-
ting problem : State of the art classification and review. Computers & Industrial
Engineering, 99, 300-313. https://doi.org/10.1016/j.cie.2015.12.007
Hao, J.-K., Galinier, P., & Habib, M. (1999). Méthaheuristiques pour l’optimisation
combinatoire et l’affectation sous contraintes. (1999).
Heßler, K., Irnich, S., Kreiter, T., & Pferschy, U. (2022). Bin packing with lexi-
cographic objectives for loading weight- and volume-constrained trucks in a direct-
shipping system. OR Spectrum, 44(2), 375-417. https://doi.org/10.1007/s00291-
021-00628-x
Korte, B., Vygen, J., Fonlupt, J., & Skoda, A. (2009). Optimisation combinatoire :
théories et algorithmes. Springer.
Liapis, I., & Nenes, G. (2023). Vehicle routing problem applications in the oil indus-
try : A literature review and research agenda. Journal of Cleaner Production, 410,
137322. https://doi.org/10.1016/j.jclepro.2023.137322
(OMG), O. M. G. (2017). OMG Unified Modeling Language (OMG UML), Version 2.5.1
(rapp. tech. No formal/2017-12-05) (Specification document, December 2017). Ob-
ject Management Group. https://www.omg.org/spec/UML/2.5.1/PDF
Samuel Sowole, O. (2024, juillet). A Comparative Analysis of Search Algorithms for
Solving the Vehicle Routing Problem. In M. Andriychuk & A. Sadollah (Éd.),
Optimization Algorithms - Classics and Recent Advances. IntechOpen. https://doi.
org/10.5772/intechopen.112067
Shin, J.-Y. (2009). An Efficient Heuristic to Solve Vehicle Routing Problem for Container
Shuttle Service [Vérifier les informations exactes selon la source officielle]. Inter-
national Journal of Industrial Engineering, 16(3), 207-214.
Tütüncü, K. A., Gül, N. N., Bölükbaş, U., & Güneri, A. F. (2023). Integer Linear
Programming Approach for the Personnel Shuttles Routing Problem in Yıldız Cam-
pus in Istanbul [Open Access]. Journal of Soft Computing and Decision Analytics,
1(1), 303-316. https://doi.org/10.31181/jscda11202326
Xu, J. (2007, décembre). Modèles stochastiques évolutionnaires pour la gestion de tournées
de véhicules avec fenêtres de temps souples et demandes floues [Thèse de doctorat].
Laboratoire de Génie Informatique et d’Automatique [Soutenue publiquement en
vue de l’obtention du Doctorat en Génie Informatique].
Zhao, X. (2008). Thèse de doctorat en Génie Informatique : Présentée et soutenue pu-
bliquement le 12 décembre 2008 en vue de l’obtention du Doctorat de l’Université
d’Artois [Doctorat]. Université d’Artois [Président du jury : Daniel Jolly. Rappor-
teurs : Tahar Kechardi, Dominique Breuil. Examinateurs : Gilles Goncalves, Rémy
Dupas, Daniel Jolly, Tienté Hsu].

65
Webographie

Developer Service. (2024, février 21). Creating a GUI in Python With TtkBootstrap
[Consulté le 9 juin 2025]. https://developer-service.blog/creating-a-gui-in-python-
with-ttkbootstrap/
Folium Contributors. (2025). Folium Documentation (latest) [Consulté le 9 juin 2025].
https://folium.readthedocs.io/en/latest/
Pimido. (2024, octobre 18). Présentation de l’entreprise ENAGEO [Consulté le 8 juin
2025]. Pimido. Récupérée juin 8, 2025, à partir de https://www.pimido.com/blog/
nos-astuces/presentation-entreprise-enageo-18-10-2024.html
Python Software Foundation. (2025). What is Python ? Executive Summary [Consul-
té le 9 juin 2025]. https://www.python.org/doc/essays/blurb/

66
 Annexes
Annexe A : Pseudo-code de la Simulation Temporelle
Le pseudo-code suivant décrit les étapes de la simulation temporelle.

Algorithme 3 Simulation Contraintes Temporelles avec Règle 18h Stricte

Entrées : Tconduite_aller , Tconduite_retour , Tchargement , Tdechargement
Sorties : ∆total
voyage , Npauses , Nnuits
1: INITIALISATION
2: hcurrent ← 8.3 ▷ Heure de début : 8h18
3: ∆total ← 0 ▷ Durée totale accumulée
4: Npauses ← 0, Nnuits ← 0 ▷ Compteurs
5: PHASE 1 : CHARGEMENT
6: hcurrent ← hcurrent + Tchargement
7: ∆total ← ∆total + Tchargement
8: PHASE 2 : CONDUITE ALLER
9: Trestant ← Tconduite_aller
10: tant que Trestant > 0 faire
11: Tdisponible ← max(0, 18.0 − hcurrent ) ▷ Temps jusqu’à 18h
12: si Tdisponible ≤ 0 alors ▷ Arrêt nocturne obligatoire
13: Tarret ← (24 − hcurrent ) + 7.0 ▷ Arrêt jusqu’à 7h
14: ∆total ← ∆total + Tarret
15: hcurrent ← 7.0
16: Nnuits ← Nnuits + 1
17: continue
18: end si
19: Tconduite ← min(Trestant , 2.0, Tdisponible ) ▷ Max 2h d’affilée
20: hcurrent ← hcurrent + Tconduite
21: ∆total ← ∆total + Tconduite
22: Trestant ← Trestant − Tconduite
23: si Tconduite ≥ 2.0 and Trestant > 0 and hcurrent + 0.25 ≤ 18.0 alors
24: hcurrent ← hcurrent + 0.25 ▷ Pause 15 minutes
25: ∆total ← ∆total + 0.25
26: Npauses ← Npauses + 1
27: end si
28: end tant que

67
PHASE 3 : DÉCHARGEMENT
si hcurrent + Tdechargement > 18.0 alors ▷ Report déchargement
Tarret ← (24 − hcurrent ) + 7.0 + Tdechargement
∆total ← ∆total + Tarret
hcurrent ← 7.0 + Tdechargement
Nnuits ← Nnuits + 1
sinon
hcurrent ← hcurrent + Tdechargement
∆total ← ∆total + Tdechargement
end si
PHASE 4 : CONDUITE RETOUR ▷ Répéter logique Phase 2
Trestant ← Tconduite_retour
tant que Trestant > 0 faire
Tdisponible ← max(0, 18.0 − hcurrent )
si Tdisponible ≤ 0 alors
Tarret ← (24 − hcurrent ) + 7.0
∆total ← ∆total + Tarret
hcurrent ← 7.0
Nnuits ← Nnuits + 1
continue
end si
Tconduite ← min(Trestant , 2.0, Tdisponible )
hcurrent ← hcurrent + Tconduite
∆total ← ∆total + Tconduite
Trestant ← Trestant − Tconduite
si Tconduite ≥ 2.0 and Trestant > 0 and hcurrent + 0.25 ≤ 18.0 alors
hcurrent ← hcurrent + 0.25
∆total ← ∆total + 0.25
Npauses ← Npauses + 1
end si
end tant que
return ∆total , Npauses , Nnuits

68
Algorithme 4 Validation Contraintes Temporelles pour une Solution
Entrées : Solution S = {xsℓ,k , yp,t,ℓ,k
s
}, Hmax
weekly

Sorties : Faisable ∈ {T rue, F alse}

1: pour s ∈ S faire ▷ Pour chaque semaine
2: pour ℓ ∈ L, k ∈ Kℓ faire ▷ Pour chaque véhicule
3: si xsℓ,k = 1 alors ▷ Si véhicule utilisé
4: ∆hebdomadaire ← 0
5: Htravail_ef f ectif ← 0
6: pour t = 1 à nsℓ,k faire ▷ Pour chaque voyage
t Ds,t,ℓ,k
7: Calculer Tconduite_aller = efVfmectif
t Ds,t,ℓ,k
8: Calculer Tconduite_retour = efVfmectif
9: [∆tvoyage , Npauses
t t
, Nnuits ]←
t t
SimulerContraintes(Tconduite_aller , Tconduite_retour , Tload , Tunload )
10: ∆hebdomadaire ← ∆hebdomadaire + ∆voyage t

11: Htravail_ef f ectif ← Htravail_ef f ectif + (Tconduite_aller

t t
+ Tconduite_retour +
Npauses × Tbreak + Tload + Tunload )
t

12: end pour

weekly
13: si ∆hebdomadaire > Hmax alors ▷ 168 heures
14: return F alse
15: end si
16: si Htravail_ef f ectif > 77 alors ▷ 77 heures de travail effectif
17: return F alse
18: end si
19: end si
20: end pour
21: end pour
22: return T rue

69
Annexe B : Log détaillé de la validation temporelle

Fig. 24 : Log détaillé de la validation temporelle

Source : élaborée par l’étudiante

70
Annexe C : Exemple numérique détaillé des formules
mathématiques d’optimisation
Données d’Entrée
Paramètres de Base

D = 450 km (distance A-B)

Ddepot = 80 km (distance dépôt-A)
Vm = 75 km/h (vitesse réglementaire)
Tload = 1.5 h (temps de chargement)
Tunload = 1.5 h (temps de déchargement)
max
Hdrive = 2 h (temps de conduite maximum continu)
Tbreak = 0.25 h (durée pause obligatoire)
Tnight = 13 h (durée arrêt nocturne)
Hstop = 18h00 (heure limite conduite)

Caractéristiques du Véhicule Étudié

Soit le véhicule k = 3 de type ℓ = 1 (camion standard) avec :
w
C1,3 = 25 tonnes (capacité poids)
v
C1,3 = 80 m³ (capacité volume)
F1 = 15000 DA/jour (coût fixe)
G1 = 120 DA/km (coût variable)

Produits à Transporter (Semaine s = 1)

Produit qp1 wp vp Wp1 Vp1

(unités) (t/unité) (m³/unité) (tonnes) (m³)
P1 100 0.15 0.8 15 80
P2 80 0.2 0.5 16 40
P3 50 0.3 1.2 15 60
Total - - - 46 180

Tab. 2 : Caractéristiques des produits à transporter

Étape 1 : Calcul du Nombre de Voyages Nécessaires

Application des Formules du Modèle
Contrainte par poids :
⌈∑ 1
⌉ ⌈ ⌉
p∈P1 Wp 46
nbVoypoids = w
= = ⌈1.84⌉ = 2 voyages
C1,3 25

71
 Contrainte par volume :
⌈∑ 1
⌉ ⌈ ⌉
p∈P1 Vp 180
nbVoyvolume = v
= = ⌈2.25⌉ = 3 voyages
C1,3 80

Nombre de voyages final (selon le modèle) :

(⌈ ⌉ ⌈ ⌉)
demande_poids demande_volume
nbVoy1,1,3 = max w
, v
= max(2, 3) = 3
C1,3 C1,3

Étape 2 : Calculs Temporels par Voyage

Voyage 1 : Trajet A→B→A (voyage intermédiaire)
Distance effective (selon le modèle) :

f ectif = 2D = 2 × 450 = 900 km

1,1,1,3
Def

Temps de conduite pure :

1,1,1,3
pure Def f ectif 900
T1,3,1 = = = 12 heures
Vm 75
Calcul du nombre de pauses obligatoires :
⌊
pure ⌋ ⌊ ⌋
pauses T1,3,1 12
N1,3,1 = max
= = 6 pauses
Hdrive 2

Temps de conduite total avec pauses :

conduite
T1,3,1 pure
= T1,3,1 pauses
+ N1,3,1 × Tbreak = 12 + 6 × 0.25 = 13.5 heures

Temps total du voyage 1 :

conduite
Tempsvoyage 1 = T1,3,1 + Tload + Tunload = 13.5 + 1.5 + 1.5 = 16.5 heures

Voyage 2 : Trajet A→B→A (voyage intermédiaire)

Les calculs sont identiques au voyage 1 :

Tempsvoyage 2 = 16.5 heures

Voyage 3 : Trajet A→B (dernier voyage, pas de retour)

Distance effective :
1,3,1,3
Def f ectif = D = 450 km

Temps de conduite pure :

pure 450
T1,3,3 = = 6 heures
75

72
 Nombre de pauses : ⌊ ⌋
pauses 6
N1,3,3 = = 3 pauses
2
Temps de conduite avec pauses :
conduite
T1,3,3 = 6 + 3 × 0.25 = 6.75 heures
Temps total du voyage 3 :
Tempsvoyage 3 = 6.75 + 1.5 + 1.5 = 9.75 heures

Étape 3 : Simulation Temporelle avec Contrainte 18h

Planning Initial
Début des opérations : lundi 7h00
1
τ1,3,1 = 7.0 heures

Voyage 1 (Lundi avec arrêt nocturne)

Instant de début :
1
τ1,3,1 = 7.0 h (lundi 7h00)
Instant de fin prévu sans contrainte 18h :
1
τ1,3,1 + Tempsvoyage 1 = 7.0 + 16.5 = 23.5 h (lundi 23h30)
Application de la contrainte temporelle : Comme 23.5 > 18.0, un arrêt nocturne
est obligatoire.
nuits
N1,3,1 =1
Calcul de l’instant de fin réel :
Temps travaillé lundi = 18.0 − 7.0 = 11.0 heures (1)
Temps restant = 16.5 − 11.0 = 5.5 heures (2)
Fin réelle = mardi 7.0 + 5.5 = 12.5 h (mardi 12h30) (3)

1
δ1,3,1 = 31.5 heures (mardi 12h30 en temps cumulé)

Voyage 2 (Mardi-Mercredi)
Instant de début :
1
τ1,3,2 = 31.5 heures (mardi 12h30)
Instant de fin :
1
δ1,3,2 = 31.5 + 16.5 = 48.0 heures (mercredi 5h00)
Vérification contrainte 18h : Le voyage se termine mercredi à 5h00, donc aucun
dépassement de 18h.

73
Voyage 3 (Mercredi)
Instant de début :
1
τ1,3,3 = 48.0 heures (mercredi 5h00)
Instant de fin :
1
δ1,3,3 = 48.0 + 9.75 = 57.75 heures (mercredi 14h45)
Position finale du véhicule :
Σ11,3 = B (site B, pas de retour)

Étape 4 : Calculs de Coûts

Distance Totale

∑
3
1,t,1,3
distTot1,1,3 = Def f ectif = 900 + 900 + 450 = 2250 km
t=1

Durée d’Utilisation
Durée totale effective :
3 (
∑ )
∆11,3 = conduite
T1,3,t nuits
+ Tload + Tunload + N1,3,1 × Tnight
t=1

∆11,3 = (13.5 + 3.0) + (13.5 + 3.0) + (6.75 + 3.0) + 1 × 13 = 55.75 heures

Nombre de jours d’utilisation :
⌈ ⌉
55.75
dureeUtil1,1,3 = = ⌈5.07⌉ = 6 jours
11

Coût Total du Véhicule

1
Z1,3 = u11,3 × F1 × nb_jours11,3 + G1 × distTot1,1,3

1
Z1,3 = 1 × 15000 × 6 + 120 × 2250 = 90000 + 270000 = 360000 DA

Étape 5 : Optimisation du Chargement

Calcul des Densités
Application de la formule du modèle :
wP 1 0.15 0.15
ηP1 1 = = = = 0.1875
max(vP 1 , 0.001) max(0.8, 0.001) 0.8
wP 2 0.2 0.2
ηP1 2 = = = = 0.4
max(vP 2 , 0.001) max(0.5, 0.001) 0.5
wP 3 0.3 0.3
ηP1 3 = = = = 0.25
max(vP 3 , 0.001) max(1.2, 0.001) 1.2

74
Ordre de Priorité (densité décroissante)

σP1 2 = 1 (densité la plus élevée : 0.4)

σP1 3 = 2 (densité intermédiaire : 0.25)
σP1 1 = 3 (densité la plus faible : 0.1875)

Plan de Chargement Optimal

Voyage 1 :

P2 (complet) : 16 t, 40 m³
P3 (partiel) : 9 t (30 unités), 36 m³
Total voyage 1 : 25 t, 76 m³ ✓

Voyage 2 :

P3 (restant) : 6 t (20 unités), 24 m³

P1 (partiel) : 19 t, 56 m³
Total voyage 2 : 25 t, 80 m³ ✓

Voyage 3 :

P1 (restant) : Calcul selon capacité résiduelle

Résumé des Résultats

Métrique Valeur
Nombre de voyages 3
Distance totale 2250 km
Durée d’utilisation 6 jours
Coût total 360000 DA
Efficacité transport 46 tonnes
Taux utilisation volume 88.9% (moyenne)
Taux utilisation poids 100%

Tab. 3 : Résultats de l’exemple numérique

75
Annexe D : Instance utilisé pour tester l’algorithme
d’optimisation

Tab. 4 : Instance des équipements à transporter par semaine

Équipements à transporter

Volet Désignation de l’équipement à transférer Modalité de transport Total 12 sem. 11 sem. 10 sem. 09 sem. 08 sem. 07 sem. 06 sem. 05 sem. 04 sem. 03 sem. 02 sem. 01 sem.

(Tractable/Chargeable) des équipements Quantité Quantité Quantité Quantité Quantité Quantité Quantité Quantité Quantité Quantité Quantité Quantité Quantité

1 Baraque (Unité) Chargeable 5 8 11 11 11 11 11 11 11 11 11 11 11

2 Baraque (Unité) Tractable 4 6 4 4 4 4 4 4 4 4 4 4 4

3 Conteneur Chargeable 2 4 2 2 2 2 2 2 2 2 2 2 2

4 Magasin (Unité) Chargeable 6 3 6 6 6 6 6 6 6 6 6 6 6

5 Ravitaillement (Unité) Chargeable 8 4 8 8 8 8 8 8 8 8 8 8 8

6 Tente (Unité) Chargeable 50 100 50 50 50 50 50 50 50 50 50 50 50

7 Clim-Modificateur (Unité) Chargeable 60 80 60 60 60 60 60 60 60 60 60 60 60

8 Levage (Grue) (Unité) Chargeable 2 6 2 2 2 2 2 2 2 2 2 2 2

9 Levage (Clark) (Unité) Chargeable 2 4 2 2 2 2 2 2 2 2 2 2 2

10 Réservoir d’eau (Unité) Tractage 4 2 4 4 4 4 4 4 4 4 4 4 4

11 Groupe électrogène (Unité) Tractage 1 2 1 1 1 1 1 1 1 1 1 1 1

12 Sondeuse (Unité) Chargeable 2 4 2 2 2 2 2 2 2 2 2 2 2

76
Annexe E : Formulaire de création des tournées

Fig. 25 : Formulaire de création des tournées

Source : élaborée par l’étudiante

Annexe F : Vue de la base de données implémentée

dans Railway

Fig. 26 : Vue de la base de données implémentés dans Railway

Source : élaborée par l’étudiante

77
Annexe J : Plan de trajet spécifique

Fig. 27 : Plan de trajet spécifique

Source : ENAGEO-Doc

78