Rapport - MoncarFinal

Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de
l’Innovation
(M.E.S.R.S.I.)
------------------
Secrétariat Général
------------------
Université Nazi BONI (U.N.B.)
------------------
Ecole Supérieure d’Informatique (E.S.I.)
Licence
Cycle des Ingénieurs deen Informatique
Travaux Informatiques (C.I.T.I.)
Option : Ingénierie des Systèmes d’Information (ISI)
Option : Système d’Information (S.I.)
RAPPORT DE FIN DE CYCLE
Thème : « Mise en place d’une plateforme de gestion et de réservation des

tickets de bus »
Période du 16 aout 2017 au 15 décembre 2017

Auteurs : José Arthur OUEDRAOGO & Josué OUEDRAOGO
Maître de stage Superviseur

M. Alban W OUEDRAOGO Dr Borlli Michel Jonas SOME
Ingénieur informaticien à Enseignant chercheur à l’Ecole
AvePLUS Supérieure d’Informatique
Année Académique 2016-2017

DEDICACE
A nos familles.
II
REMERCIEMENTS
A travers ces lignes, nous exprimons nos sincères remerciements d’abord à l’équipe pédagogique
de l’ESI pour la formation qu’elle nous a donnée, et à AvePLUS pour l’opportunité de stage qu’elle
nous a offerte.
Nous adressons tout particulièrement nos sincères remerciements à l’endroit des personnes
suivantes :
- M. Lassane OUEDRAOGO, le Directeur Général de AvePLUS ;
- M. Alban W OUEDRAOGO, Ingénieur informaticien à AvePLUS, notre maître de stage ;
- Dr Borlli Michel Jonas SOME, Enseignant-chercheur à l’ESI, le superviseur de ce travail ;
- M. Armand S YAO directeur exécutif de AvePLUS et M. Victorien Zidabou BAMBARA
développeur web et d’API à AvePLUS, nos personnes ressources ;
- Toute l’équipe de AvePLUS/KeoLID pour sa brillante collaboration ;
- Nos amis pour leurs soutiens ;
- Nos familles pour tout ce qu’elles sont pour nous.
Pour finir, nous témoignons de notre gratitude à tous ceux qui, d’une manière ou d’une autre, ont
contribué à notre formation ou à la réussite de ce travail.
III
LISTE DES SIGLES ET ACRONYMES
AJAX Asynchronous Javascript And XML
API Application Programming Interface
BD Base de données
CICI Cycle des Ingénieurs de Conception Informatique
CITI Cycle des Ingénieurs de Travaux Informatiques
CU Cas d’Utilisation
DOM Document Object Model
ESI Ecole Supérieure d’Informatique

IDE Integrated Development Environment
JSON JavaScript Object Notation
GPL General Public Licence
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secured
MVC Model View Controller
PHP HyperText PreProcessor
SGBD Système de Gestion des Bases de Données

SHA1 Secure Hash Algorithm
SSL Secure Socket Layer
SQL Structured Query Language
UML Unified Modeling Language
UNB Université Nazi BONI

URL Uniform Resource Locator
XML eXtensible Markup Language
IV
RESUME
La question de « la gestion et de la réservation des tickets de bus » demeure un défi à relever dans
nos différentes sociétés de transport. Cette gestion implique une bonne organisation du temps et
une meilleure stratégie concernant les réservations de trajets.
Cependant, l’organisation actuelle de la gestion et de la réservation de tickets de bus rencontre des
contraintes en termes de savoir-faire, de matériel et de temps. Dans le contexte local, la quasi-
absence de logiciel métier, la redondance des réservations, l’absence de base de données constituent
les principaux points de dysfonctionnement de cette organisation.
Dans le but de pallier à ces difficultés précédemment énoncées afin de gagner en temps, faciliter le
travail des sociétés de transport et parvenir à de meilleurs résultats, il s’avère nécessaire de mettre
en place une plateforme de gestion et de réservation des tickets de bus dont nous avons baptisé
« MonCar ».
Pour la mise en place de cette plateforme, le processus de développement scrum et le langage de
modélisation UML ont été retenu pour la conception tandis que la réalisation de l’application a été
possible grâce au Framework CodeIgniter et MySQL comme système de gestion de base de
données.
V
ABSTRACT
The question of “Management and reservation of bus ticket” is a challenge to increase in our
transport companies. This Management carry away of good organization of time and the best
solution concerning the routes reservations.
However, the actual organization of the management and the reservation of bus ticket meet many
constraints of knows-how, materials and time. Actually, in our local context, the lack of software
in this domain, the redundancy of reservation, the lack of database can a set of main malfunctions
of this organization.
To avoid these difficulties, in the aims to win time, facilitate the work of transport companies and
achieve better results, it is necessary to set up a platform for managing and booking bus tickets
which we named “MonCar”.
For the implementation of this platform, the scrum development process and the UML modeling
language were retained for the design while the realization of the application was made possible
thanks to CodeIgniter framework and MySQL as a basic management system of data.
VI
AVANT-PROPOS
L’Université Nazi BONI (UNB) a été créée le 19 septembre 1995 sous le nom de Centre
Universitaire Polytechnique de Bobo-Dioulasso (CUPB). En mai 1997 elle changea de nom et
devint Université Polytechnique de Bobo-Dioulasso (UPB) et le 8 mai 2017, l’UPB devient
l’Université Nazi BONI (UNB). L’Université Nazi BONI comprend, d’une part, quatre instituts :
- l’Institut du Développement Rural (IDR) ;
- l’Institut Supérieur des Sciences de la Santé (INSSA) ;
- l’Institut Universitaire de Technologie (IUT) ;
- l’Institut des Médias (IM).
D’autre part, une école et trois unités de formation et de recherche (UFR) :
- l’Ecole Supérieure d’Informatique (ESI) ;
- l’Unité de Formation et de Recherche en Sciences Juridiques, Politiques, Économique et
de Gestion (UFR/SJPEG) ;
- l’Unité de Formation et de Recherche en Sciences et Techniques (UFR/ST) ;
- l’Unité de Formation et de Recherche en Lettre et Sciences Humaines (UFR/LSH).
Outre ses établissements, l’UNB compte un centre universitaire, le Centre Universitaire
Polytechnique de Gaoua (CUPG).
Toutes ces structures œuvrent à donner aux étudiants des compétences dans des domaines de
formation pointus. Pour ce qui est de l’Ecole Supérieure d’Informatique, elle forme des diplômés
de niveau bac+3 et bac+5 qui répondent aux besoins du milieu professionnel. Au niveau bac+3
elle prépare de nos jours d’une part à la licence en Ingénierie des Réseaux et Systèmes (IRS), et
d’autre part en Ingénierie des Systèmes d’Information (ISI), des filières qui dans le temps
s’appelaient respectivement Réseaux et Maintenance Informatiques (REMI) et Analyse-
programmation (AP). Au niveau bac+5 elle propose également deux formations : un master en
Réseaux et Systèmes (RS) et un master en Systèmes d’Information (SI).
Pour l’obtention du diplôme de licence d'informatique, l’étudiant doit valider d’abord ses cinq
premiers semestres, puis effectuer dans le cadre du sixième semestre un stage d’au moins trois mois.
Durant ce stage en entreprise, l’occasion est donnée à l’étudiant de découvrir un nouveau monde
et de confronter ses connaissances théoriques à la pratique. A la suite de ce séjour en entreprise, il
rédige un rapport de fin de stage faisant l’objet d’une soutenance et dans lequel ses réalisations sont
présentées. C’est ce qui justifie que nous ayons été reçues à l’entreprise AvePLUS pour la période
du 16 août 2017 au 15 décembre 2017, plus précisément au centre d’incubation KeoLID.
VII
LISTE DES FIGURES
Figure 1 : Organigramme de la structure d’accueil ............................................................................................. 3

Figure 2 : Planning prévisionnel .................................................................................................................... 5
Figure 3 : Processus scrum ........................................................................................................................... 8
Figure 4 : Diagramme d'état transition de la classe « user ».............................................................................. 15
Figure 5 : Diagramme d'état transition de la classe « booking_details » .............................................................. 15
Figure 6 : Diagramme de classe du domaine .................................................................................................. 17
Figure 7 : Diagramme de cas d'utilisation global du système ............................................................................. 22
Figure 8 : Schéma de l'architecture MVC..................................................................................................... 25
Figure 9 : Diagramme de CU global du sprint Gestion des utilisateurs .............................................................. 27
Figure 10 : Diagramme de classe des CU: « S'authentifier » et « Créer un compte client » ...................................... 30
Figure 11 : Diagramme de séquence du CU: « S'authentifier » ......................................................................... 31
Figure 12 : Diagramme de séquence du CU: « Créer un compte client » .............................................................. 32
Figure 13 : Interface d'inscription ................................................................................................................ 33
Figure 14 : Interface de vérification d'identité ................................................................................................. 33
Figure 15 : Interface de connexion ............................................................................................................... 33
Figure 16 : Interface de la page d'accueil ....................................................................................................... 33
Figure 17 : Diagramme de CU global du sprint Administration ...................................................................... 35
Figure 18 : Diagramme de classe des CU: « Enregistrer une compagnie » et « Enregistrer un bus » ......................... 37
Figure 19 : Diagramme de séquence du CU: « Enregistrer une compagnie » ........................................................ 38
Figure 20 : Diagramme de séquence du CU: « Enregistrer un bus » .................................................................. 38
Figure 21 : Interface du menu principal ........................................................................................................ 39
Figure 22 : Interface d'ajout d'un bus .......................................................................................................... 39
Figure 23 : Interface de la liste des bus ......................................................................................................... 40
Figure 24 : Diagramme du CU global du sprint gestion des réservations ............................................................. 41
Figure 25 : Diagramme de classe des CU: « Faire une réservation » et « Annuler une réservation ».......................... 43
Figure 26 : Diagramme de séquence du CU: « Faire une réservation » .............................................................. 44
Figure 27 : Diagramme de séquence du CU: « Annuler une réservation » ........................................................... 45
Figure 28 : Interface de consultation de trajets ................................................................................................ 46
Figure 29 : Interface de choix de place .......................................................................................................... 46
Figure 30 : Interface de confirmation de réservation ......................................................................................... 46
Figure 31 : Interface d'annulation ............................................................................................................... 47
Figure 32 : Diagramme de package ............................................................................................................. 48
Figure 33 : Diagramme de séquence d'application du CU: « S'authentifier » ....................................................... 50
Figure 34 : Diagramme de séquence d'application du CU: « Enregistrer un trajet » .............................................. 51
Figure 35 : Diagramme de séquence d'application du CU: « Faire une réservation ».............................................. 52
Figure 36 : Diagramme de classe d'application global du système ....................................................................... 53
Figure 37 : Diagramme de déploiement ........................................................................................................ 54
Figure 38 : Modèle physique de donnée......................................................................................................... 56
Figure 39 : Ecran d'accueil ........................................................................................................................ 58
Figure 40 : Ecran de consultation de trajet.................................................................................................... 58
Figure 41 : Ecran de Choix de la place ........................................................................................................ 59
Figure 42 : Ecran de paiement ................................................................................................................... 59
Figure 43 : Ecran de réservation réussie ....................................................................................................... 60
Figure 44 : Tableau de bord du back office ................................................................................................... 60
Figure 45 : Interface d'ajout d'un trajet ........................................................................................................ 61
Figure 46 : Planning réel........................................................................................................................... 61
VIII
LISTE DES TABLEAUX
Tableau 1 : Description des concepts du domaine ............................................................................................ 12

Tableau 2 : Dictionnaire de donnée de la classe user........................................................................................ 13
Tableau 3 : Dictionnaire de donnée de classe bus ............................................................................................ 13
Tableau 4 : Dictionnaire de donnée de la classe booking_details ........................................................................ 14
Tableau 5 : Product Backlog ..................................................................................................................... 18
Tableau 6 : Coût de développement ............................................................................................................. 20
Tableau 7 : Coût de formation des formateurs ............................................................................................... 20
Tableau 8 : Coût total de réalisation ........................................................................................................... 21
Tableau 9 : Planning des releases ................................................................................................................ 21
Tableau 10 : Identification de l'équipe scrum ................................................................................................. 21
Tableau 11 : Backlog du sprint «Gestion des utilisateurs » ............................................................................... 26
Tableau 12 : Description textuelle du CU : « S'authentifier » .......................................................................... 28
Tableau 13 : Description textuelle du CU: « Créer un compte client » ................................................................ 28
Tableau 14 : Backlog du sprint « Administration » ....................................................................................... 34
Tableau 15 : Description textuelle du CU : « Enregistrer une compagnie » ......................................................... 36
Tableau 16 : Description textuelle du CU: « Enregistrer un bus » .................................................................... 36
Tableau 17 : Backlog du sprint « Gestion des réservations » ............................................................................. 40
Tableau 18 : Description textuelle du CU: « Faire une réservation » ................................................................ 42
Tableau 19 : Description textuelle du CU : « Annuler une réservation » ............................................................ 42
IX
Table des matières
DEDICACE ............................................................................................................................................... II
REMERCIEMENTS ............................................................................................................................ III
LISTE DES SIGLES ET ACRONYMES ....................................................................................... IV
RESUME .................................................................................................................................................... V
ABSTRACT .............................................................................................................................................. VI
AVANT-PROPOS ................................................................................................................................. VII
LISTE DES TABLEAUX .................................................................................................................... IX
INTRODUCTION GENERALE ........................................................................................................ 1
CHAPITRE I : PRÉSENTATION DU CONTEXTE DE STAGE.......................................... 2
1.1 Introduction ...................................................................................................................................... 2
1.2 Structure de formation ................................................................................................................... 2
1.3 Structure d’accueil .......................................................................................................................... 2
1.4 Présentation du projet.................................................................................................................... 3
1.4.1 Problématique ........................................................................................................................... 3
1.4.2 Objectifs du projet ................................................................................................................... 4
1.4.3 Résultats attendus ................................................................................................................... 4
1.4.4 Gestion du projet ..................................................................................................................... 4
1.5 Conclusion ........................................................................................................................................ 5
CHAPITRE II : DEMARCHE ET MOYENS DE REALISATION........................................ 6
2.1 Introduction ...................................................................................................................................... 6
2.2 Exigences fonctionnelles et techniques ................................................................................... 6
2.3 Méthode de résolution du problème ......................................................................................... 6
2.3.1 Langage de modélisation UML .......................................................................................... 6
2.3.2 Méthode de résolution ........................................................................................................... 7
2.4 Méthode d’estimation des coûts .............................................................................................. 10
2.5 Conclusion ...................................................................................................................................... 10
CHAPITRE III : DOMAINE D'ETUDE ....................................................................................... 11
3.1 Introduction .................................................................................................................................... 11
3.2 Etude de l’existant ........................................................................................................................ 11
3.2.1 Ressources et organisation du travail .............................................................................. 11
3.2.2 Analyse critique de l'existant ............................................................................................. 11
3.3 Délimitation et analyse du domaine ....................................................................................... 12
3.3.1 Identification des concepts clés ........................................................................................ 12
3.3.2 Dictionnaire de données ..................................................................................................... 13
3.3.3 Diagramme de classe de domaine ................................................................................... 14
X
3.3.4 Diagramme d’états transition ............................................................................................ 15
3.4 Conclusion ...................................................................................................................................... 16
CHAPITRE IV : PHASE INITIAL DE SPRINT OU ITERATION 0 ................................. 18
4 .1 Introduction ................................................................................................................................... 18
4.2 Backlog du produit ....................................................................................................................... 18
4.3 Évaluation des coûts du projet ................................................................................................. 20
4.4 Planification des releases............................................................................................................ 21
4.5 Identification de l’équipe scrum .............................................................................................. 21
4.6 Diagramme de cas d’utilisation initial ................................................................................... 22
4.7 Technologies et outils de développement ............................................................................. 22
4.7.1 Outils technologiques prérequis ....................................................................................... 22
4.7.2 Architecture de l’application .............................................................................................. 24
4.8 Conclusion ...................................................................................................................................... 25
CHAPITRE V : DEVELOPPEMENT DE L’APPLICATION................................................ 26
5.1 Introduction .................................................................................................................................... 26
5.2 Sprint 1 : Gestions des utilisateurs ........................................................................................... 26
5.2.1 Sprint planning ou planification du sprint ..................................................................... 26
5.2.2 Spécification fonctionnelle ................................................................................................. 27
5.2.3 Conception .............................................................................................................................. 29
5.2.4 Test ............................................................................................................................................ 32
5.3 Sprint 2 : Administration............................................................................................................. 34
5.3.3 Conception .............................................................................................................................. 37
5.3.4 Test ............................................................................................................................................ 39
5.4 Sprint 3 : Gestions des réservations ......................................................................................... 40
5.4.3 Conception .............................................................................................................................. 43
5.4.4 Test ............................................................................................................................................ 45
5.5 Conclusion ...................................................................................................................................... 47
CHAPITRE VI : CODAGE ET DEPLOIEMENT ..................................................................... 48
6.1 Introduction .................................................................................................................................... 48
6.2 Codage ............................................................................................................................................. 48
6.2.1 Diagramme de package ....................................................................................................... 48
6.2.2 Diagramme de classe global de l’application ............................................................... 49
XI
6.2.3 Diagramme de séquence d’application .......................................................................... 49
6.2.4 Schéma physique des données .......................................................................................... 54
6.3 Déploiement ................................................................................................................................... 54
6.4 Conclusion ...................................................................................................................................... 55
CHAPITRE VII : REALISATION ET BILAN ............................................................................ 57
7.1 Introduction .................................................................................................................................... 57
7.2 Modules développés..................................................................................................................... 57
7.3 Enchainements des écrans ........................................................................................................ 57
7.4 Analyses des écarts ....................................................................................................................... 61
7.5 Procédures transitoires ................................................................................................................ 62
7.6 Politique de sécurité .................................................................................................................... 62
7.6.1 Politique de gestion des connexions distantes aux serveurs .................................... 63
7.6.2 Gestion des mots de passe et connexion à l’application............................................ 63
7.6.3 Protection contre les virus .................................................................................................. 63
7.7 Conclusion ...................................................................................................................................... 64
CONCLUSION GENERALE ............................................................................................................ 65
LISTE DES REFERENCES BIBLIOGRAPHIQUES ............................................................... 66
ANNEXE I : CODEIGNITER .......................................................................................................... 67
ANNEXE II : COMPARAISON ENTRE L’APPROCHE CLASSIQUE ET
L’APPROCHE AGILE .......................................................................................................................... 68
ANNEXE III : CONTEXTE D’UTILISATION DE QUELQUES METHODES
AGILES ...................................................................................................................................................... 69
XII
INTRODUCTION GENERALE
De nos jours l’automatisation des traitements de données constitue un enjeu stratégique pour les
entreprises. Elle se présente parfois comme une nécessité car la gestion au sein de l’entreprise est
de plus en plus économique, facilitée, fiable et maîtrisée. L’informatique est devenue ainsi un outil
incontournable à toute entreprise qui se veut compétitive sur le marché.
Consciente de cette réalité, AvePLUS, un centre d’entrepreneuriat numérique, a décidé de mettre
en place un système de gestion informatisée des sociétés de transport routière. KeoLID, un
incubateur de projet informatique de AvePLUS est la structure en charge de ce projet, au sein
duquel nous avons effectué notre stage. Il a opté ainsi de nous mettre sur le projet dont le thème
s’intitule : « La Mise en place d’une plateforme de gestion et de réservation des tickets de
bus ».
La numérisation de ce secteur permet une meilleure connaissance et une bonne gestion des
réservations de tickets de bus, grâce à cette innovation, il est possible de mieux optimiser le temps
lors des réservations des tickets de bus et de mieux fidéliser la clientèle. Ce projet vise à mettre en
place une solution de réservation des trajets de voyage en ligne prenant en comptes différentes
compagnies de transport afin de réduire les contraintes liées aux réservations physiques que
rencontrent les clients dans ces services de transport. Ainsi pour atteindre cet objectif, la solution
qui sera issue de ce projet devra être une plateforme web de réservation. La plateforme sera
déployée dans un domaine en environnement Linux afin de permettre à tous les utilisateurs de
pouvoir y accéder via une URL.
Le présent rapport est constitué de sept (07) chapitres. Le premier chapitre présente les structures
de formation et d’accueil en stage. Le deuxième chapitre expose la démarche et les moyens de
résolution retenus. Le troisième chapitre correspond à l’analyse et à la délimitation du domaine. Le
quatrième chapitre correspond au sprint 0 de la méthode scrum ou encore la phase de préparation
où nous détaillerons les technologies que nous allons manipuler tout au long de notre projet. Le
cinquième chapitre abordera les étapes de développement de l’application (la conception). Pour ce
qui est du sixième chapitre, il sera dédié à la partie déploiement et codage de notre application. Le
septième et dernier chapitre présente nos réalisations avec un bilan à l’appui.
1
CHAPITRE I : PRÉSENTATION DU CONTEXTE DE STAGE
1.1 Introduction
La conduite d’un projet dans une structure sur un thème donné requière une très bonne
connaissance de la structure ainsi qu’une excellente maitrise du thème d’étude. Pour ce faire, nous
présentons d’abord l'organisation administrative de notre école et son dispositif pédagogique.
Ensuite il sera question pour nous de présenter notre structure d’accueil AvePLUS, son historique
et ses domaines d’intervention. Enfin, nous évoquerons la problématique et les résultats attendus
de notre étude pour finir par une proposition de solution aux problèmes posés.
1.2 Structure de formation
L’ESI a été créée en 1990 à Ouagadougou, il a été déplacée à Bobo-Dioulasso en 1995 à la faveur
de la création du Centre Universitaire Polytechnique de Bobo-Dioulasso (CUPB) qui est devenu
en 1997 Université Polytechnique de Bobo-Dioulasso (UPB) rebaptisée Université Nazi BONI
(UNB) le 8 mai 2017. L’ESI est sur le campus de Nasso et suit partiellement le système Licence
Master Doctorat (LMD). En effet, l’ancien Cycle des Ingénieurs de Travaux Informatiques (CITI),
d’une durée de trois ans, est devenu une licence d’informatique. La licence offre deux spécialités :
Ingénierie des réseaux et systèmes (anciennement « Réseaux et maintenance informatiques, REMI
») et Ingénierie des systèmes d’information (anciennement « Analyse et programmation, AP »). A
la tête de l’ESI il y a un directeur assisté d'un directeur adjoint. Le corps professoral de
l’établissement est constitué d’enseignants qualifiés nationaux et internationaux.
1.3 Structure d’accueil
Initiative du Groupe AvePLUS, KeoLID est un projet innovant et ambitieux qui a été lancé
officiellement le 09 Février 2017. Ce centre qui bénéficie du soutien de plusieurs institutions
publiques dans le domaine du numérique entend contribuer activement à l’émergence d’une réelle
économie numérique au Burkina Faso par la formation, la créativité et l’innovation. Pour ce faire,
il s’articule autour de trois axes que sont :
- Le centre de Formation KeoLID (Training Center) pour créer une expertise locale dans
le domaine du numérique afin de répondre à l’épineux problème de déficit en compétences
spécialisées dans les nouveaux métiers du numérique ;
2
- Le centre d’Incubation (Incubator) pour accompagner les porteurs de projets novateurs
et les aider à transformer leurs idées en startup viables, performantes, créatrices d’emplois
et de richesses ;
- Le laboratoire KeoLID qui est un centre d’expertise et de solutions technologiques dédié à
la réalisation de projets innovants en collaboration avec des partenaires publics et privés.
Dans le souci de bâtir un écosystème d’innovation pour transformer notre pays. KeoLID s’est fixé
les missions suivantes :
- Réduire la disparité entre les compétences offertes par le système éducatif et ceux exigés
par le marché du travail ;
- Répondre aux exigences du marché de l’emploi dont le niveau est de plus en plus élevé ;
- Contribuer à faciliter l’intégration du Burkina Faso et les pays ouest Africain dans le
processus de globalisation à travers la création et le transfert de compétences ;
- Créer de la richesse et une compétitivité globale à travers l’utilisation de l’outil informatique
pour un développement durable ;
- Réussir à mieux combiner enseignement supérieur et expérience professionnelle.
L’organigramme de KeoLID est celui de la figure ci-après.
Directeur
Général
Responsable
Responsable Responsable
Administratif
Commercial Technique
et Financier
Dévéloppeurs
Sécrétaire
Informatiques
Figure 1 : Organigramme de la structure d’accueil
1.4 Présentation du projet
1.4.1 Problématique
Les sociétés de transports, routières en particulier, rencontrent des difficultés dans la gestion et la
réservation des tickets de bus. Ces difficultés sont particulièrement dues au mode de gestion
actuelle de ces sociétés, essentiellement basé sur la gestion manuelle et l'utilisation d’outils
classiques et non adaptés à une gestion efficace. Nos sociétés de transports jusqu’à présent non pas
3
de système de réservations et de paiements en ligne. Afin de pallier à toutes ces insuffisances,
KeoLID dans son ambition de bâtir un écosystème d’innovation pour transformer notre pays, a
initié le présent projet dont le thème est intitulé « La Mise en place d’une plateforme de gestion
et de réservation des tickets de bus ». C’est la réalisation d’une plateforme web permettant aux
sociétés de transports d’avoir une gestion efficace et rapide des réservations de tickets de bus qui
est attendue.
1.4.2 Objectifs du projet
L’objectif général du projet est de réaliser une solution logicielle capable de faciliter la gestion et la
réservation des tickets de bus dans toute structure de transport routière. Les objectifs spécifiques
du projet sont :
- La pérennisation de l’information ;
- La facilitation des réservations des tickets de bus ;
- La digitalisation de la gestion et la réservation des tickets de bus ;
- La facilitation du suivi des réservations ;
- La réduction du temps des réservations.
1.4.3 Résultats attendus
L’application que nous allons mettre en place doit permettre :

- La consultation des différents trajets proposés par différentes compagnies de transports
par les utilisateurs ;
- La gestion des utilisateurs ;
- La gestion des réservations de tickets de bus par compagnie de transport ;
- La gestion des compagnies de transports ;
- La gestion des trajets ;
- La gestion des paiements de tickets réservés en ligne par mobile money.
1.4.4 Gestion du projet
Pour mener à bien ce projet, un planning prévisionnel de réalisation a été élaboré. Le planning
prévisionnel donne les tâches à effectuer assorties de leurs durées de réalisation. Il a été établi dès
le lancement du projet.
4
Figure 2 : Planning prévisionnel
1.5 Conclusion
Ce chapitre nous a permis en premier de présenté l’organisation administrative de l’école, le

dispositif pédagogique ainsi que la structure d’accueil. Il a également permis de définir quelques
grandes lignes du projet telles que la présentation du projet en elle-même, de faire ressortir les
résultats attendus et de proposer un planning prévisionnel d’exécution. Ainsi après avoir eu
connaissance du projet, une approche de résolution est alors envisageable dans la suite de notre
étude.
5
CHAPITRE II : DEMARCHE ET MOYENS DE REALISATION
2.1 Introduction
La phase de la démarche et des moyens de résolution permet d’identifier exactement ce que le futur
système devra réaliser en termes de métier. Ainsi pour réduire le risque d’échec du projet, il est
important de bien choisir la démarche à suivre et la méthode à appliquer. Dans cette partie nous
mettrons en évidences les exigences fonctionnelles et techniques puis annoncerons la méthode
retenue pour la résolution du problème.
2.2 Exigences fonctionnelles et techniques
Compte tenu des besoins exprimés par les utilisateurs du système c’est-à-dire les compagnies de
transport et les passagers, les opérations que le système proposé devra permettre d’effectuer sont :
- La possibilité de consulter les différents trajets ;
- La possibilité de créer un compte utilisateur ;
- La possibilité de gérer les trajets ;
- La possibilité de gérer des réservations dans un trajet ;
- La possibilité de gérer des compagnies de transport ;
- La possibilité d’effectuer un paiement d’une réservation par mobile money ;
- La possibilité de générer un ticket de réservation.
Le système mise en place pour la gestion et la réservation des tickets de bus, est destiné à être
utilisés par toute société de transport routière. C’est une application web ayant une structure 3-tiers
implémentant le modèle MVC (Model View Controller).
2.3 Méthode de résolution du problème
2.3.1 Langage de modélisation UML
La réalisation de tout système informatique nécessite une modélisation préalable. Un langage de

modélisation est un langage artificiel qui peut être utilisé pour exprimer de l'information dans un
formalisme qui est définie par un ensemble cohérent de règles. Dans la conduite de ce projet, nous
avons choisi Unified Modeling Language (UML) comme langage de modélisation. UML est un
langage de modélisation graphique à base de pictogrammes conçu pour fournir une méthode
normalisée pour visualiser la conception d'un système. Il est couramment utilisé en développement
logiciel et en conception orientée objet.
6
2.3.2 Méthode de résolution
2.3.2.1 La Méthode Scrum
Pour mener à bien la tâche qui nous a été confiée, nous avons opté pour une méthode
d'organisation efficace, permettant la satisfaction du client et son implication tout au long du
processus de réalisation du projet : il s'agit de Scrum.
Scrum est défini par ses créateurs comme, un « Framework », un cadre de travail permettant de
livrer un maximum de valeur métier en un temps minimal, de livrer rapidement un logiciel de qualité
dans lequel le client définit les priorités, dans lequel l’équipe s’auto organise pour livrer à chaque
itération un produit fonctionnel. Notre choix de la méthode scrum est motivé par les raisons
suivantes :
- Elle permet de gérer les quatre paramètres nécessaires à l’analyse d’un plan de livraison : le
coût, le délai, les fonctionnalités livrés et la qualité ;
- Les données pour une éventuelle validation sont disponibles.
Les trois piliers de la méthode Scrum sont les suivants :
- La transparence : les aspects importants du processus doivent être visibles à tous. C’est
pour cela que Scrum insiste sur le fait de créer un langage commun entre les membres de
l’équipe et le management, ce qui permettra une compréhension commune du projet.
- L’inspection : un bilan régulier sur les résultats produits est réalisé afin de détecter les
écarts indésirables. Il est important que ces inspections soient faites par un inspecteur bien
formé et cela de manière adaptée car cela pourrait nuire à l’avancement du projet.
- L’adaptation : lorsqu’un écart est constaté pendant l’inspection, le processus devra être
adapté grâce à des actions visant à améliorer la situation.
La méthodologie scrum propose les intervenants suivants :
- Le Product Owner (le client ou son représentant) ;
- La Team (les développeurs) ;
- Le Scrum Master (facilitateur ou animateur) ;
- Des intervenants extérieurs (Stakeholders).
La méthodologie scrum propose les activités suivantes :
- Planification d’itération « Sprint Planning » : une réunion de pré-sprint organisée par le
scrum master en 2-temps :
o 1ère Phase : Clients, utilisateurs, management, « Product Owner » et « Scrum Team
» établissent le « Sprint Backlog » (liste priorisée des « stories ») ;
7
o 2ième Phase : Le « scrum master » et la « Scrum Team » organise le déroulement
du Sprint avec un « TimeBox » égale à deux (2) heures par semaine de Sprint.
- Revue d’itération « Sprint Review » : réunion informelle, l'équipe présente au client ce qui
a été développé pendant les 30 jours précédents via une démonstration puis une décision
de « release » ou non avec un « TimeBox » de 1 heure par semaine de Sprint ;
- Mêlée quotidienne : c’est une réunion de partage des connaissances, un temps pour faire
un point sur l'avancement dont le « TimeBox » est de 15 à 20 minutes et donne au
management une certaine visibilité sur la progression du projet, le contrôle continu et
empirique via trois questions quotidiennes : qu'est ce qui a été fait pendant la journée ? Que
reste-il à faire ? Quels sont les obstacles qui gênent l'avancement du projet ?
- Sprint rétrospective : réunion ayant lieu après le « Sprint Review » et avant le « Sprint
planning meeting », le but est d’inspecter la manière dont s'est déroulée le Sprint précédent
quant aux personnes, relations, processus et outils utilisés, identifier et ordonner les
éléments majeurs qui se sont déroulés ainsi que les améliorations potentielles, créer un plan
pour implémenter des améliorations quant à la manière de travailler de l'équipe scrum. Le
« TimeBox » est de trois heures pour quatre semaines de Sprint.
2.3.2.2 Cycle de vie de la méthode Scrum
La figure ci-dessous représente le cycle de vie de la méthode de résolution scrum.
Figure 3 : Processus scrum
Un processus scrum est constitué en trois (03) étapes :

- La phase initiale : elle aboutit à la conceptualisation et l'analyse du système, la mise en
place d'un carnet de produit « Product Backlog », c'est à dire une liste de tâches à effectuer,
8
la définition approximative de la date de livraison, la définition des fonctionnalités à livrer,
la formation de l'équipe de développement et l'analyse du risque et des coûts ;
- La phase de Sprints (itérations +/- 30 jours) : elle aboutit à la phase où le développement
est, à proprement parlé, réalisé (analyse, conception, implémentation de chaque élément),
les Sprints sont guidés par une liste de tâches provenant du Product Backlog formant le «
Sprint Backlog » ;
- La phase de clôture : c’est la phase de préparation du produit pour une livraison
(intégration, tests systèmes, documentation utilisateur, préparation des supports de
formation, préparation des supports marketing, etc.)
2.3.2.3 Acteurs du projet selon la méthode Scrum
D’après le choix de la méthode de résolution de notre projet, les personnes impliquées de façon
directe ou indirecte dans ce projet peuvent être répartis comme suit :
- Le Product Owner : Ce dernier définit les spécifications fonctionnelles et communique la
vision globale du produit à l’équipe. Il établit la priorité des fonctionnalités à développer ou
à corriger et valide les fonctionnalités développées. Il se doit de jouer le rôle client final, se
mettre à sa place et donc de prioriser ses besoins. Celui qui tient ce rôle est celui qui a le
plus de responsabilités et d’autorité. Le responsable (produit) est en effet celui qui est en
première ligne lorsque quelque chose se passe mal ; ce qui nécessite de trouver le juste
équilibre entre autorité – responsabilité et engagement. Dans notre projet ce rôle est destiné
à M. Lassane OUEDRAOGO (Directeur général de AvePLUS).
- Le Scrum Master : Ce dernier agit en tant que facilitateur entre le responsable produit et
l’équipe. Son rôle principal est d’éliminer tous les obstacles qui peuvent empêcher l’équipe
d’atteindre les objectifs fixés pour chaque sprint de travail. Il s’assure que les principes et
les valeurs Scrum sont respectés. Il facilite la communication au sein de l’équipe et cherche
à améliorer la productivité et le savoir-faire de son équipe. Le Scrum Master conseille aussi
le responsable produit sur la façon de maximiser le « Return On Investment » général de
l’équipe. Dans ce projet, ce rôle est réservé à M. Alban W OUEDRAOGO (Ingénieur
informaticien à AvePLUS).
- La Team Member : C’est le groupe qui a pour mission d’exécuter le projet. Cela veut dire
qu’il est chargé d’étudier, de concevoir, de réaliser et de déployer l’application. Dans ce
projet, ce groupe est composé de M. José Arthur OUEDRAOGO et M. Josué
OUEDRAOGO.
9
- Les Stakeholders : Ce sont les intervenants extérieurs « les personnes ressources » ayant
participé à la réalisation du projet. Dans notre contexte, ce rôle est celui de Dr Borlli Michel
Jonas SOME (Enseignant chercheur à l’ESI).
2.4 Méthode d’estimation des coûts
Etant donné que nous sommes dans une méthodologie agile, nous avons opté d’estimer les coûts
de réalisation de notre projet avec un processus adapté : il s’agit du planning poker.
Le processus de planification Poker se déroule comme suit :
- Étape 1 : le modérateur lit la description de la fonctionnalité / User Story que l’équipe doit
estimer. Le « Product Owner » peut fournir des clarifications sur la fonctionnalité. Chaque
expert est doté d’un jeu de cartes ;
- Étape 2 : chaque membre de l’équipe scrum choisit une carte dans son jeu qui correspond
à son estimation initiale de l’effort de développement. Chaque membre pose sa carte à
l’envers sur la table pour ne pas influencer les autres ;
- Étape 3 : quand toutes les évaluations sont sur la table, les cartes sont retournées ;
- Étape 4 : s’il y a une palette très large entre les estimations, les experts qui ont suggéré les
plus fortes et plus basses évaluations fournissent le raisonnement qui les a amenés à ces
valeurs.
Une fois que la discussion sur la palette d’estimations a été menée, les étapes 2 à 4 sont répétées
jusqu’à ce qu’un consensus soit atteint. Dans notre projet, les coûts seront estimés dans la partie
4.3.
2.5 Conclusion
Après avoir abordé le thème d’étude qui nous a été attribué, nous avons adopté le processus de
développement Scrum et le langage de modélisation UML comme outils d’analyse et de conception
pour ce projet. Cependant, comment y arriver si l’on n’a pas une bonne appréhension du domaine
d’étude ? Le chapitre suivant sera consacré au domaine d’étude.
10
CHAPITRE III : DOMAINE D'ETUDE
3.1 Introduction
Ce chapitre a pour objectif de présenter l’existant et d’analyser le domaine pour une meilleure
compréhension. Pour ce faire, nous allons dans un premier temps étudier l’existant et procéder à
la délimitation et à l’analyse du domaine.
3.2 Etude de l’existant
3.2.1 Ressources et organisation du travail
Les ressources matérielles et logicielles disponibles dans une compagnie de transport classique tel
que la compagnie de transport TSR (Transport Sana Rasmané) et la compagnie RAKIETA, d’après
nos investigations peuvent être étayé ainsi :
- Pour ce qui est de l’existant matériel, on y retrouve le plus souvent des postes de travail,
des imprimantes, un téléphone fixe ou mobile, des clés USB, des registres de réservations
et des tickets de réservation.
- Du point de vue de l’existant logiciel, il est essentiellement constitué de la suite bureautique
Microsoft Office. On y rencontre parfois, des systèmes de paiement des tickets de bus par
orange money dans quelques compagnies de transport.
3.2.2 Analyse critique de l'existant
L’analyse critique de l’existant est une appréciation du fonctionnement du système en place. Par
cette analyse, nous faisons ressortir les forces et les faiblesses du système actuel (le système de
départ). Cependant les outils utilisés actuellement sont les logiciels Word et Excel de Microsoft
Corporation et les documents papier, ce qui n’est pas adapté. L’analyse a permis de révéler les
limites de ces outils utilisés qui sont entre autres :
- La redondance des réservations ;
- L’absence d’automatisation dans la gestion des réservations ;
- Le mauvais suivi des réservations ;
- Le traitement très fastidieux pour uniquement une ou deux passagers ;
Toutes ses limites entrainent des conséquences sur l’activité des sociétés de transport telles que : la
lenteur et la non précision dans l’exécution des tâches, la difficulté dans la gestion et la réservation
des tickets de bus et l’impossibilité d’user des informations sauvegardées à des fins évolutives.
11
3.3 Délimitation et analyse du domaine
Dans cette partie, nous repérons les concepts clés du système qui serviront d’une part à élaborer le
dictionnaire de données et d’autre part à représenter le diagramme des classes puis les diagrammes
d’états-transitions.
3.3.1 Identification des concepts clés
Elle va consister à débuter la modélisation orientée objet en répertoriant les classes principales du
futur modèle statique d’analyse. Les concepts clés du domaine d’étude sont présentés dans le
tableau ci-dessous :
Tableau 1 : Description des concepts du domaine

Concepts Descriptions
Admin Il s’agit de l’administrateur principal du site.
Agent Il s’agit d’un administrateur du site en fonction d’une compagnie de
transport.
Amenities Ce sont les équipements dont dispose le bus.
Board_points Ce sont les villes de départ des bus.
Booking_details Il s’agit des réservations de trajets effectuées par les clients.
Bus Il s’agit des bus de transport présent dans le système.
Bus_gallery Ce sont les images des bus.
Bus_type Ce sont les types de bus dont dispose notre système.
Cancellation Il s’agit des frais d’annulation des réservations d’un trajet.
Compagny Ce sont les compagnies de transport.
Customer_details Ce sont les passagers.
Drop_point Ce sont les villes d’arrivés des bus.
Promo_details Ce sont les promotions offertes par compagnie de transport.
Rating Ce sont les notes et commentaires faites par les utilisateurs sur les
compagnies de transport.
Route Ce sont les trajets proposés par les compagnies de transport.
Seat_layout C’est la disposition des places en fonction des bus.
Settings Ce sont les paramètres de configuration de la plateforme.
User Ce sont les utilisateurs de la plateforme.
12
3.3.2 Dictionnaire de données
Le dictionnaire de données permet d’avoir une meilleure compréhension des concepts à travers la
description de leurs attributs. Pour un souci d’avoir un document succinct nous avons choisi de
présenter le dictionnaire de données de quelques concepts jugés les plus pertinents du domaine.
Tableau 2 : Dictionnaire de donnée de la classe user

Classe : user
Attribut Type Description
User_id Entier La clé primaire qui permet d’identifié de façon
unique un utilisateur.
Username Alphanumérique Représente l’adresse-mail de l’utilisateur.
Password Alphanumérique Représente le mot de passe d’un utilisateur.
Name chaine de caractère Représente le nom d’un utilisateur.
Dob Date Représente la date de naissance de l’utilisateur.
Gender chaine de caractère Représente le genre (sexe) de l’utilisateur.
Mob Entier Représente le numéro de téléphone d’un utilisateur.
Status Entier Représente le statut d’un utilisateur du système.
Tableau 3 : Dictionnaire de donnée de classe bus

Classe : bus
Bus_id Entier Représente la clé primaire permettant d’identifier
de façon unique un bus.
Bus_name chaine de caractère Représente le nom du bus.
Bus_reg_no Alphanumérique Représente le numéro immatriculation du bus.
Max_seats Entier Représente le nombre maximal de place d’un bus.
Board_point chaine de caractère Représente les villes de départ des bus.
Board_time Date Représente le l’heure de départ d’un bus.
Drop_point chaine de caractère Représente les villes d’arrivée des bus.
Drop_time Date Représente le l’heure d’arrivée d’un bus
Bus_status Entier Représente le statut d’un bus. (actif ou désactive)
13
Create_by chaine de caractère Représente l’agent / l’administrateur qui a créé le
bus.
Tableau 4 : Dictionnaire de donnée de la classe booking_details

Classe : booking_details
Booking_id Entier Représente la clé primaire permettant
d’identifier de façon unique une réservation.
Amount Entier Représente le prix d’un ticket de bus par
réservation.
Payment_status chaine de caractère Représente le statut de paiement d’une
réservation.
Payment_option chaine de caractère Représente les options de paiement d’une
réservation.
Promo_code Entier Représente le code promotionnel d’une
réservation.
Booking_date Date Représente la date d’une réservation.
Status chaine de caractère Représente le statut d’une réservation.
3.3.3 Diagramme de classe de domaine
Le diagramme de classe exprime de manière générale la structure statique d’un système en termes
de classes et en termes de relations entre ces classes.
Ce diagramme est considéré comme le plus important de la modélisation orientée objet. Il

représente la structure statique du système, c'est à dire la partie du système qui sera toujours
présente lors des interactions définies par les cas d'utilisation. Le diagramme de classes permet ainsi
de représenter les structures des classes composant le système en même temps que les relations
entre ces classes. Une classe représente la description abstraite d'un ensemble d'objets possédant
les mêmes caractéristiques, tandis qu’une association ou relation représente un lien sémantique
durable entre deux classes. La Figure 6 représente le diagramme de classe de notre application.
14
3.3.4 Diagramme d’états transition
Le diagramme d'états-transitions est une représentation graphique du comportement d'une classe.

Il décrit les différents changements d’état d’une classe suite à la survenue d’un évènement. Dans
cette section nous allons représenter les diagrammes d’état transition des classes suivantes « user »
et « booking_details » respectivement par les figures 4 et 5.
Figure 4 : Diagramme d'état transition de la classe « user »
Figure 5 : Diagramme d'état transition de la classe « booking_details »
15
3.4 Conclusion
L’étude du domaine a mis en emphase les différentes ressources et organisation du travail du

système existant. Cela a consisté concrètement à la présentation des forces et des faiblesses de
l’existant. En plus, ce chapitre a permis de faire ressortir les différents concepts, le diagramme
d’états transition ainsi que le diagramme de classe du domaine.
16
Agent
Inscri t 0..*
- agent_i d
- usernam e
- fi rst_nam e
- l ast_nam e
- com pagny_nam e
- addresse
- em ai l
1..1 - phone_num ber
- ci ty
Enregi stre - country
Com pagny 0..* 1..1 Adm i n
- profi l e_pi cture
- com pagny_i d 1..1 - adm i n_i d - status
0..* Cree
- com pagny_nam e - usernam e - create_by
- com pagny_num ber - password
Cancel l ati on - profi l e_pi cture
- com pagny_m ai l 1..1 1..1 Adm i ni stre
- status - cancel l ati on_i d - status
... - adverti sem ent_status - user_type
...
- cancel _ti m e 1..1
- percentage 1..1
- fl at Cree
Di spose - type
0..*
... Enregi stre
1..1
1..1 Prom o_detai l s
Bus_type - prom o_i d
1..1 Correspond 1..*
- code
- bustype_i d
1..* - type
- bus_type
- am ount Setti ng
- status Correspond
... Bus Affecte - expi re_date
1..* - setti ng_i d
1..* - status
- bus_i d 1..* - ti tl e
- create_by
- bus_nam e ... - l ogo
1..* Affecte
Am eni ti es 1..1 - bus_reg_no - fl avi con
Route - sm tp_usernam e
- am eni ti es_i d - m ax_seats 1..1
Se retrouve
- am eni ti es - board_poi nt 1..* 1..* - route_i d - sm tp_host
1..*
- status - board_ti m e Donne l i eu - board_poi nt - sm tp_password
... - drop_poi nt 0..* - board_ti m e - sender_i d
1..1 Booki ng_detai l s
- drop_ti m e - drop_poi nt - sm s_usernam e
Bus_gal l ery 1..* - booki ng_i d
- status - drop_ti m e - sm s_password
- busgal l ery_i d Possede - am ount
- bus_status 1..1 - fare - paym ent_opti on
- i m age - paym ent_status 1..1
... - status - paypal
- create_by 1..* 1..1 - paym ent_opti on
Conti ent - create_by - paypal i d
... - prom o_code ... - app_key
Donne l i eu - booki ng_date 1..*
Seat_l ayout 1..1
est affecte - status Conti ent
1..1
- seatl ayout_i d 0..* Board_poi nts 1..*
- totel _seat 0..*
- boardpoi nt_i d
- l ayout Rati ng Drop_poi nts
- l ayout_type Concerne - pi ckup_poi nt
- rati ng_i d - pi ckup_ti m e - droppoi nt_i d
- l ast_seat - bus_qual i ty Effectue
- l andm ark - stoppi ng_poi nt
- no_sl eeper - punctual i ty - addresse - drop_ti m e
...
- staff_behavi our - status - l andm ark
1..1 1..* ...
- average - addresse
- com m ents User - status
Custom er_detai l s
0..* ...
- user_i d - custom er_i d
Effectue - usernam e - custom er_nam e
1..1 - password - age
- nam e - m obi l e
- dob - em ai l
- i m age - gender
- gender - order_i d
- m ob - seat_no
- reset_key
...
Figure 6 : Diagramme de classe du domaine
17
CHAPITRE IV : PHASE INITIAL DE SPRINT OU ITERATION 0
4 .1 Introduction
Le sprint 0, l’itération 0 ou l’exploration est un élément important pour mettre les bonnes bases
d’un nouveau projet et pour permettre à une nouvelle équipe de se former et d’apprendre à travailler
ensemble.
4.2 Backlog du produit
Le Backlog produit est utilisé pour planifier la release et aussi à chaque sprint, lors de la réunion de
planification du sprint pour décider du sous-ensemble qui sera réalisé. Ses éléments sont classés
par ordre de priorité ce qui permet de définir l’ordre de réalisation.
Tableau 5 : Product Backlog

Nom (user story) Rang Estimation(jours) Priorité Descriptions
S’authentifier en tant 1 2 1 En tant que client, je veux
que client pouvoir me connecter sur la
plateforme afin de bénéficier
des fonctionnalités de
l'application
Chercher un trajet 2 2 1 En tant que client, je veux
pouvoir faire une recherche sur
un trajet donné
Choisir une place 3 2 1 En tant que client, je veux
pouvoir choisir une ou des
chaise(s) précise(s) dans le bus
Faire une 2 2 En tant que client, je veux
réservation pouvoir effectuer une
réservation d’un trajet.
Recevoir une 4 1 2 En tant que client, je veux
notification par sms pouvoir recevoir des alertes par
sms après une réservation
Noter les services 5 2 2 En tant que client, je veux
pouvoir noter la qualité, la
ponctualité du bus et la
courtoisie des agents
Consulter l’histoire 6 2 2 En tant que client, je veux
de mes réservations pouvoir Consulter l’histoire de
mes réservations
Imprimer un ticket 7 3 2 En tant que client, je veux
pouvoir Imprimer mes tickets
18
Annuler une 8 2 2 En tant que client, je veux
réservation pouvoir Annuler une
réservation
Changer de mot de 9 1 3 En tant que client, je veux
passe pouvoir changer mon mot de
passe
Editer un compte 10 2 3 En tant que client, je veux
pouvoir éditer mon compte
afin de le mettre à jours
S’authentifier en tant 11 1 4 En tant qu’administrateur ou
qu’administrateur ou agent d’une compagnie, je veux
agent pouvoir me connecter sur la
plateforme afin de faire des
mises à jour
Enregistrer un bus 12 1 4 En tant qu’administrateur ou
agent d’une compagnie, je veux
pouvoir enregistrer un bus afin
de faire des mises à jour
Supprimer un bus 13 1 4 En tant qu’administrateur ou
pouvoir supprimer un bus afin
de faire des mises à jour
Ajouter un trajet 14 1 4 En tant qu’administrateur ou
pouvoir ajouter un trajet afin de
faire des mises à jour
Consulter les 15 2 5 En tant qu’administrateur ou
réservations agent d’une compagnie, je veux
pouvoir consulter les
réservations afin de vérifier une
réservation donnée.
annulations de agent d’une compagnie, je veux
réservations pouvoir consulter les
annulations de réservations afin
de vérifier une annulation
donnée.
Générer la 17 2 5 En tant qu’administrateur ou
disposition des agent d’une compagnie, je veux
chaises d’un bus pouvoir générer la disposition
des chaises d’un bus.
commentaires des agent d’une compagnie, je veux
clients pouvoir Consulter les notes et
les commentaires effectués par
un client.
Configurer le 19 2 5 En tant qu’administrateur, je
paramètre initial du veux pouvoir Configurer les
site paramètres du site.
19
Pour chaque user story on identifie le rang, l’estimation, l'importance et la description.
- Rang : Pour les user stories ayant la même priorité, un rang est assigné pour indiquer l'ordre
dans lequel l'équipe doit les implémenter.
- Estimation : Elle sert à estimer l’effort nécessaire à une équipe pour implémenter une
fonctionnalité. Elle prend en compte l’effort pour le développement.
- Priorité : Le Product Owner classe les user story par ordre de priorité dans le Backlog
product en travaillant avec le client pour savoir ce qui est important pour lui.
- Description : Elle permet de décrire les user stories. Généralement, pour rendre ce nom
explicite, une bonne façon de procéder est d'utiliser le Template suivant : « En tant que X,
je veux Y, afin de... ».
4.3 Évaluation des coûts du projet
Dans cette partie, nous allons estimer les différents coûts liés à la réaliser de ce projet à travers le
planning poker précédemment énoncé dans la partie 2.4. Nous avons travaillé à temps plein 280
heures soit 8 heures par jour. De plus, la rémunération d’un développeur junior maitrisant le
Framework CodeIgniter est de 32 €/heure, environ 20800 FCFA/heure selon les salaires des
développeurs web en 2017. Les tableaux 6, 7 et 8 donnent une estimation des coûts du
développement, de formation et enfin de réalisation du projet.
Tableau 6 : Coût de développement

Charge du projet Heures de travail Coût horaire d’un Montant
développeur junior
280 H 20 800 FCFA 5 824 000 FCFA
AvePLUS dispose d’agents technico-commerciaux qui doivent être formés au préalable afin de
commercialiser le futur système.
Tableau 7 : Coût de formation des formateurs

Nombre d’heure Coût horaire Nombre Montant
d’utilisateur
10 H 5 000 FCFA 4 200 000 FCFA
20
Tableau 8 : Coût total de réalisation
Désignation Prix
Coût de développement 5 824 000 FCFA
Coût de formation des formateurs 200 000 FCFA
Coût total 6 024 000 FCFA
4.4 Planification des releases
La planification des sprints est une étape importante dans Scrum. Le planning du travail et
l'identification du Backlog des sprints sont les buts de cette réunion. Durant ce meeting, la durée
de chaque sprint est décidée selon la complexité du contexte et la taille de l'équipe. La planification
de Sprint répond aux questions suivantes :
- Qu’est-ce qui peut être terminé au cours de ce sprint ?
- Comment sera effectué le travail choisi ?
Et donc, une succession de Releases est le produit de cette réunion pour organiser le travail de
l'équipe. Un Release est une série de sprints qui se termine quand les incréments successifs
constituent un produit présentant suffisamment de valeurs à ses utilisateurs. Dans notre cas, nous
avons décidé de découper notre projet en trois Releases.
Tableau 9 : Planning des releases

Releases Sprint Priorités
Release 1 Gestion des utilisateurs 1
Release 2 Administration 2
Release 3 Gestion des réservations 3
4.5 Identification de l’équipe scrum
Le tableau ci-dessous, donne un aperçu de notre équipe de travail ainsi que le rôle de chaque
équipier selon les rôles définis par scrum
Tableau 10 : Identification de l'équipe scrum

Rôles Scrum Intervenants
Product Owner M. Lassane OUEDRAOGO
Scrum Master M. Alban W OUEDRAOGO
Stakeholder Dr Borlli Michel Jonas SOME
Team OUEDRAOGO José Arthur
OUEDRAOGO Josué
21
4.6 Diagramme de cas d’utilisation initial
Il est question ici de présenter les différents besoins fonctionnels de notre application en utilisant
le digramme de cas d'utilisation d'UML.
Modifier son compte
Consulter les offres de voyages
<<include>> Enregistrer un bus

Agent
Visiteur
Creer un compte
<<include>>
Enregistrer un trajet
<<include>>
Consuter ses reservations
Creer une promotion
<<include>> <<include>>
<<include>>
Faire une reservation S'authentifier
<<include>> <<include>>
Enregistrer un agent
Client
Administrateur
Annuler une reservation
<<include>>
Enregistrer une compagnie

<<include>>
Generer un ticket <<include>>
Modifier son profile
Figure 7 : Diagramme de cas d'utilisation global du système
4.7 Technologies et outils de développement
4.7.1 Outils technologiques prérequis
Dans cette partie nous allons présenter les outils à utiliser pour la réalisation du système.
22
4.7.1.1 Langage de programmation et Framework applicatif
Dans le cadre de notre projet, plusieurs langages ont été envisagés pour sa mise en œuvre. Parmi
eux, PHP, JAVA EE et ASP.net. Grâce à une étude comparative, notre choix s’est porté sur PHP
dans sa version 7 parue le 12 Novembre 2015. En effet, PHP est un langage qui s'adapte très
rapidement aux technologies émergentes. Il est de plus en plus utilisé dans des développements
web dynamiques professionnels et open source. Aussi, ce langage dispose d’une documentation
détaillée et d’une grande communauté de développeurs actifs qui rendent disponibles de milliers
de librairies. De par sa facilité, PHP accélère le temps de développement tout en optimisant le code
en permettant sa réutilisation, en toute sécurité à travers ses Framework comme CodeIgniter que
nous utiliserons d’ailleurs dans ce projet.
CodeIgniter est Framework PHP open source, robuste et particulièrement très léger. Il dispose
d’une large communauté de développeurs et il très apprécier par les professionnels. Les principales
caractéristiques de CodeIgniter :
- Une compatibilité totale avec PHP 7 ;
- Simplicité de prise en main ;
- Une intégration de l’architecture MVC qui est une bonne pratique de programmation
recommandant le découpage du code en au moins trois parties que sont le Modèle, la Vue
et le Contrôleur ;
- Une disponibilité de nombreuses librairies ;
- Une souplesse et une évolution constante ;
- Une compatibilité avec la quasi-totalité des systèmes de gestion de base de données.
4.7.1.2 Serveur de gestion de base de données
Le système de gestion de base de données (SGBD) est un logiciel qui permet le stockage, la
consultation, la mise à jour, la structuration ou encore le partage d'informations dans une base de
données. Nous utilisons comme système de gestion de base de données, MySQL Server version
5.7. Ce SGBD est distribué sous double licence GPL (pour la licence que nous avons choisie) et
propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde,
autant par le grand public (applications web principalement) que par des professionnels. Toutes
ces raisons ont motivé notre choix.
4.7.1.3 Outils de modélisation et de développement
23
- PowerAMC
C’est un outil de modélisation permettant de représenter les concepts et les différents diagrammes
de notre système. Avec ces diagrammes, on a une compréhension claire du futur système à mettre
en place.
- Sublime Text
Pour le développement de l’application, nous avons utilisé Sublime Text qui est l’un des meilleurs
éditeurs de texte du moment. Sublime Text est léger, rapide, fluide, facile à personnaliser et offre
une possibilité d’automatiser les tâches répétitives à travers des snippets.
4.7.1.4 Librairies et technologie de développement
Pour la mise en place de notre application, nous avons utilisé entre-autres les librairies suivantes :
- JQuery : C’est une bibliothèque (Framework) JavaScript libre qui porte sur l'interaction
entre JavaScript et HTML, et qui a pour but de simplifier des commandes communes de
JavaScript.
- Angular js : C’est un Framework JavaScript. La principale caractéristique de ce Framework
est qu'un grand nombre d’actions sont effectuées sur le serveur tel que le rendu du moteur
de template, la récupération des données, leur (pré) validation et la navigation dans une
application, sont désormais déportés côté client. Le serveur se limite à traiter, vérifier,
valider et envoyer les données aux clients dans un format générique (JSON, XML, etc.)
Cela permet d’avoir une charge sur les serveurs nettement moins importants et une fluidité
de navigation chez le client.
- AJAX : Ajax (acronyme de Asynchronous Javascript and XML) est une manière de
construire des applications web et des sites web dynamiques basés sur diverses technologies
web ajoutées aux navigateurs dans les années 1990. JavaScript et DOM (Document Object
Model) sont utilisés pour modifier l'information présentée dans le navigateur par
programmation.
4.7.2 Architecture de l’application
24
Le système peut se subdiviser en trois parties à savoir les données, la présentation et le traitement.
Suivant cette logique, notre système obéit aux principes d’une architecture implémentant le modèle
MVC (Modèle – Vue – Contrôleur). Son principal intérêt réside dans la séparation des données
(modèle), de l’affichage (vue) et des actions (contrôleur). La vue correspond à ce qui va être affiché
à l’écran de l’utilisateur. C’est à partir d’elle que l’utilisateur va interagir avec le système. Le modèle
correspond aux données stockées la plupart du temps dans une base de données. Le contrôleur
utilise les données pour les envoyer à la vue. Son rôle est de récupérer les informations, de les traiter
en fonction des paramètres demandés par la vue (par l’utilisateur, exemple : lister les trajets), puis
de renvoyer à la vue les données afin qu’elles soient affichées.
Figure 8 : Schéma de l'architecture MVC
4.8 Conclusion
Tout au long de ce chapitre, nous avons présenté le Sprint 0 qui, est en fait une phase de préparation
pendant laquelle nous avons construit notre backlog du produit en se basant sur les besoins
fonctionnels et non fonctionnels. En plus, nous avons découpé notre projet en des releases qui
formeront le chapitre suivant. Finalement, nous avons défini les technologies et les environnements
de développement ainsi que l’architecture globale de l’application.
25
CHAPITRE V : DEVELOPPEMENT DE L’APPLICATION
5.1 Introduction
Dans ce chapitre, nous allons traiter les histoires utilisateurs (c’est-à-dire les cas d’utilisation) de nos
sprints considérés en même temps comme des releases pour produire un ensemble d'incréments
potentiellement livrable. Avant de se lancer dans le premier sprint, l'équipe doit définir le but de ce
dernier qui doit être défini en terme métier et non pas terme technique pour qu'il soit
compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question
fondamentale « Pourquoi faisons-nous ce sprint ?».
5.2 Sprint 1 : Gestions des utilisateurs
Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le Backlog de ce sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe
ne peuvent être modifiés. Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
- Objectif : Un visiteur du site peut créer un compte client. L’administrateur est capable de
créer un compte agent. L’administrateur, les agents et les clients peuvent modifier leurs
comptes ou leurs profiles.
- Développeurs : Team.
5.2.1 Sprint planning ou planification du sprint
Une fois que nous avons défini le but de notre sprint, il est temps de décider quelles histoires de
notre Backlog du produit inclure dans le Backlog du sprint. Le tableau suivant résume donc le
Backlog du premier sprint.
Tableau 11 : Backlog du sprint «Gestion des utilisateurs »

Nom Description Priorité
S’authentifier En tant qu’administrateur, agent ou client, je veux 1
m'authentifier afin de bénéficier des
fonctionnalités non public de l'application.
Modifier le mot de passe En tant qu’administrateur, agent ou client, je veux 1
changer mon mot de passe afin de mieux
personnaliser mes paramètres de connexion.
26
Modifier un profile En tant qu’agent ou client, je veux modifier mon 1
profile afin de faire des mises à jours.
Créer un compte client En tant visiteur, je peux créer un compte client 1
afin d’accéder aux services de réservation.
Créer un compte agent En tant qu’administrateur, je peux créer un 1
compte agent pour chaque compagnie.
5.2.2 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une
description textuelle de ses histoires utilisateurs.
5.2.2.1 Diagramme de Cas d'utilisation
La politique mise en place pour la gestion des utilisateurs de l’application répertorie quatre (04)
types d’utilisateur à savoir L’administrateur, les agents, les clients et les visiteurs. La figure ci-
dessous illustre le diagramme des cas d’utilisation global de ce sprint.
Creer un compte cl i ent
<>
Vi si teur Agent
Modi fi er son profi l e
S'authenti fi er
<>
<>
Creer un compte agent
Admi ni strateur
Modi fi er son compte

Cl i ent
Figure 9 : Diagramme de CU global du sprint Gestion des utilisateurs
A titre d'exemple, nous détaillons les cas d'utilisation « S’authentifier » et « Créer un compte client
», les autres cas d'utilisation généralisés suivent le même principe. Après avoir chargé la page
d’accueil, le visiteur de l'application MonCar pourra créer un compte client.
27
5.2.2.2 Description textuelle
Ci-dessous la description textuelle des différents cas d'utilisation généralisés du cas d’utilisation «
Créer un compte client ».
Tableau 12 : Description textuelle du CU : « S'authentifier »

Cas d’utilisation (CU) : S’authentifier
Objectif : permettre la connexion a un compte Acteurs : Administrateur, Agents et Clients
Version : 1.0
Pré condition : Charger la page de connexion de l’application Back Office ou la page d’accueil
de l’application Front Office
Scénario nominal :
1- L’acteur demande à se connecter
2- Le système envoie le formulaire de connexion
3- L’acteur renseigne les champs obligatoires puis les envoie
4- Le système vérifie (SA1)
5- Le système envoie l’acteur sur sa vue en fonction de son profil
Scenario alternatif :
SA1 : L’acteur saisit des données incorrectes : l’enchaînement commence au point 5 du scénario
nominal
6- Le système notifie à l’acteur l’invalidité des données saisies
7- L’enchaînement continue au point 3 du scénario nominal
Post condition : L’acteur est maintenant connecté et dispose des fonctionnalités du système
selon son profil.
Ci-dessous la description textuelle du cas d'utilisation généralisés « Créer un compte client ».
Tableau 13 : Description textuelle du CU: « Créer un compte client »

Cas d’utilisation (CU) : Créer un compte client
Objectif : permettre au visiteur de devenir un Acteur : Visiteur
client (Avoir un compte)
Version : 1.0
Pré condition : Charger la page d’accueil de l’application
Scénario nominal :
1- L’acteur demande à créer un compte
2- Le système envoie le formulaire d’inscription
5- Le système enregistre le compte
6- Le système envoie le formulaire de vérification d’identité
28
7- Le système envoie un code d’identification sur le numéro de l’acteur
8- L’acteur renseigne le code reçu puis envoie
10- Le système connecte l’acteur
nominal
SA2 : L’acteur saisit un code incorrect : l’enchaînement commence au point 10 du scénario
nominal
13- Le système notifie à l’acteur l’invalidité du code saisie
Post condition : L’acteur est maintenant connecté et dispose des fonctionnalités du système
5.2.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
- Le diagramme de classes permet de représenter une vue statique du système d’information. Il

identifie la structure des classes du système, y compris les propriétés et les méthodes de
chaque classe, et les diverses relations qui peuvent exister entre les classes y sont également
représentées.
- Le diagramme de séquence permet de représenter une vue dynamique du système
d’information. Il permet de décrire les scénarii de chaque cas d'utilisation en mettant l'accent
sur la chronologie des opérations en interaction avec les objets. Pour les cas d’utilisation de
ce Sprint, nous allons présenter ces deux diagrammes.
- Cas d’utilisation « S’authentifier » et « Créer un compte client »
o Diagramme de classes
Le diagramme de classes des cas d’utilisation « S’authentifier » et « Créer un compte client » se

résume par les différentes classes participantes à la réalisation de ces derniers. La figure suivante
illustre le diagramme de classes de ces cas d’utilisations.
29
Ag e n t
0 ..*
In scri t - a g e n t_ i d
Ad m i n - u se rn a m e
1 ..1
- adm i n_i d - fi rst_ n a m e
- u se rn a m e - l a st_ n a m e
- p a sswo rd - co m p a g n y_ n a m e
- p ro fi l e _ p i ctu re - a d d re sse
- em ai l
+ ch a n g e _ p a ss ()
- co u n try
+ p ro fi l e _ vi e w ()
... - p ro fi l e _ p i ctu re
+ vi e w_ a g e n t ()
+ a d d _ a g e n t ()
Use r
+ e d i t_ a g e n t ()
- u se r_ i d + d e l e te _ a g e n t ()
- u se rn a m e
- p a sswo rd
- nam e
- re se t_ ke y
+ si g n u p ()
+ l o g i n ()
+ re se t_ p a ss ()
+ fo rg o t_ p a ss ()
Figure 10 : Diagramme de classe des CU : « S'authentifier » et « Créer un compte client »
o Diagramme de séquences
Ce diagramme décrit le scénario du cas d’utilisation « S’authentifier ». Dans un premier lieu,
l’utilisateur MonCar remplit le formulaire d’authentification. Ensuite le système vérifie s’il s’agit
bien d’un abonné ou non à travers le web service « Login ».
30
S'authentifier
MonCar
Administrateur/Agent/Client
Demande a se connecter
Affichage du formulaire de connexion
Renseigne le formulaire de connexion
Verification des informations saisies
loop [Donnees saisies incorrectes]

Notifie l'invalidité des identifiants
Renvoie du formulaire de connexion
Renseigne du formulaire de connexion
Verification des informations saisies
Connexion ()
Affichage de la page d'accueil
Figure 11 : Diagramme de séquence du CU : « S'authentifier »
Ce diagramme décrit le scénario du cas d’utilisation « Créer un compte client ». Dans un premier
temps, le visiteur de la plateforme MonCar remplit le formulaire d’inscription. Ensuite le système
vérifie les données saisies et enregistre un nouveau client.
31
Créer un com pte cl i ent
M onCar
Vi si teur
Dem ander a créer un com pte cl i ent
Affi chage du form ul ai re d'i nscri pti on
Rem pl i ssage des cham ps obl i gatoi res
Véri fi cati on des i denti fi ants
l oop [Données i ncorrectes]

Noti fi e l 'i nval i di té des i nform ati ons
Rem pl i ssage des cham ps obl i gatoi res
Veri fi cati on des i denti fi ants
Affi chage du form ul ai re de veri fi cati on d'i denti té
envoi e du code de veri fi cati on
sai si e du code véri fi cati on
l oop [Code i ncorrect] Noti fi e l 'i nval i di té du code
sai si e du code véri fi cati on
Veri fi cati on du code
Creati on d'un com pte ()
Affi chage de l a page d'accuei l connectée
Figure 12 : Diagramme de séquence du CU : « Créer un compte client »
5.2.4 Test
L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin du développement. Au contraire, le test est une phase intégrée dès le
début du premier sprint jusqu'à la livraison du produit final. Nous illustrons à ce niveau par des
captures d’écran la réalisation de ce sprint.
- La figure 13 illustre l’interface d’inscription en tant que client sur la plateforme

- La figure 14 illustre l’interface de saisie du code de vérification d’identité.
- La figure 15 illustre l’interface de la page de connexion.
- La figure 16 illustre l’interface de la page d’accueil inscription ou connexion.
32
Figure 13 : Interface d'inscription
Figure 14 : Interface de vérification d'identité
Figure 15 : Interface de connexion
Figure 16 : Interface de la page d'accueil
33
5.3 Sprint 2 : Administration
constitueront le Backlog du sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés. Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
- Objectif : L’administrateur ou les agents sont capables de s’authentifier, des mettre à jours les
données de la plateforme à savoir les compagnies, les bus, les trajets et les paramètres par
défaut.
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
Backlog du produit inclure dans le Backlog du sprint. Le tableau 5 résume donc le Backlog de ce
sprint.
Tableau 14 : Backlog du sprint « Administration »

S’authentifier En tant qu’administrateur ou agent d’une 1
compagnie, je veux me connecter sur la
plateforme administration afin de faire des
mises à jour
Enregistrer une compagnie En tant qu’administrateur, je veux enregistrer 2
une compagnie afin de faire des mises à jour
Enregistrer un bus En tant qu’administrateur ou agent d’une 2

compagnie, je veux enregistrer un bus afin de
Enregistrer un trajet En tant qu’administrateur ou agent d’une 2
compagnie, je veux ajouter un trajet afin de
Enregistrer un agent En tant qu’administrateur, je veux enregistrer 2
un agent pour le compte d’une compagnie.
Enregistrer une promotion En tant qu’administrateur ou agent d’une 2
compagnie, je veux enregistrer une
promotion.
34
Afin d'accéder aux différentes fonctionnalités offertes par l'application MonCar, l’administrateur
ou l’agent doit s'authentifier en saisissant son login et son mot de passe. Il a également la possibilité
de modifier son mot de passe afin de personnaliser ses paramètres d'authentification.
<>

Enregi strer une com pagni e
Agent
<>

Enregi strer un bus
Enregi strer un traj et
S'authenti fi er <>
Creer une prom oti on

<>
<> Enregi strer un agent
Adm i ni strateur
Figure 17 : Diagramme de CU global du sprint Administration
A titre d'exemple, nous détaillons le cas d'utilisation « Enregistrer un agent » et les autres cas
d'utilisation généralisés suivent le même principe. Une fois authentifié, l'administrateur de
l'application MonCar pourra gérer les agents. La gestion inclut l'opération d'ajout, de modification
des données de son profil et de suppression.
35
Ci-dessous la description textuelle des différents cas d'utilisation généralisés « Enregistrer une
compagnie » et « Enregistrer un bus ».
Tableau 15 : Description textuelle du CU : « Enregistrer une compagnie »

Cas d’utilisation (CU) : Enregistrer une compagnie
Objectif : permettre à l’administrateur Acteur : Administrateur
d’enregistrer une compagnie.
Version : 1.0
Pré condition : Se connecter
Scénario nominal :
1- L’acteur demande à enregistrer une compagnie
2- Le système envoie le formulaire
5- Le système enregistre la compagnie
6- Le système notifie l’enregistrement et renvoie le formulaire
nominal
Post condition : La compagnie est maintenant enregistrer dans le système
Tableau 16 : Description textuelle du CU: « Enregistrer un bus »

Cas d’utilisation (CU) : Enregistrer un bus
Objectif : permettre à l’administrateur ou Acteur : Administrateur ou agent
l’agent d’enregistrer un bus.
Version : 1.0
Scénario nominal :
1- L’acteur demande à enregistrer un bus
2- Le système envoie le formulaire
5- Le système enregistre le bus
6- Le système notifie l’enregistrement et renvoie le formulaire
36
nominal
Post condition : Le bus est maintenant enregistrer dans le système
5.3.3 Conception
Elle se traduit par un diagramme de classes et un diagramme de séquences.
- Pour ce sprint, le diagramme de classes des cas d’utilisation « Enregistrer une compagnie »
et « Enregistrer un bus » peuvent se traduire par les différentes classes participantes à la
réalisation de ce dernier.
Agent
0..*
Inscri t - agent_i d
- usernam e
- fi rst_nam e
- l ast_nam e
- com pagny_nam e
- addresse
- em ai l
1..1 - country
Enregi stre Adm i n + vi ew_agent ()
Com pagny 0..* 1..1
+ add_agent ()
- com pagny_i d - adm i n_i d
0..* Cree + edi t_agent ()
- com pagny_nam e 1..1 - usernam e
1..1 + del ete_agent ()
- com pagny_num ber - password
- com pagny_m ai l Cancel l ati on - profi l e_pi cture Adm i ni stre
- status - cancel l ati on_i d : i nt + change_pass () 1..1
+ vi ew_com pagny () - adverti sem ent_status : i nt + profi l e_vi ew ()
+ vi ew_cancel l ati on () ...
+ add_com pagny () Di spose
+ edi t_com pagny () + add_cancel l ati on () 1..1 1..1
+ del ete_com pagny () + edi t_cancel l ati on ()
+ del ete_cancel l ati on () 0..*
... Enregi stre
Prom o_detai l s
1..1 - code 1..*
- bustype_i d
1..* - expi re_date___
- bus_type
- status Correspond + vi ew_prom o () Setti ng
... Bus + add_prom o () - setti ng_i d
1..*
- bus_i d + edi t_prom o () - ti tl e
1..*
+ del ete_prom o () - l ogo
- bus_nam e
Am eni ti es - board_poi nt - fl avi con
1..1 Route
- am eni ti es_i d - board_ti m e - sm tp_usernam e
Se retrouve
1..*
- am eni ti es - drop_ti m e - route_i d - sm tp_host
- status - bus_status - board_poi nt - sm tp_password
... + vi ew_bus () - board_ti m e - sender_i d
- fare - sm s_usernam e
Bus_gal l ery + add_bus ()
Possede - sm s_password
+ bus_acti ve () + vi ew_route ()
- busgal l ery_i d : i nt 1..* - paym ent_opti on
1..1 + edi t_bus () 1..1 + add_route () 1..1
- i m age : i nt - paypal
- create_by : i nt + del ete_bus () + edi t_route ()
Conti ent + del ete_route () - paypal i d
...
... - app_key
1..* 1..*
Seat_l ayout Conti ent
1..1 est affecte
- seatl ayout_i d Board_poi nts 1..*
- totel _seat - boardpoi nt_i d
- l ayout - pi ckup_poi nt Drop_poi nts
- l ayout_type
- pi ckup_ti m e - droppoi nt_i d
- l ast_seat - l andm ark - stoppi ng_poi nt
- no_sl eeper - addresse
... - drop_ti m e
- status - l andm ark
...
- addresse
- status
...
Figure 18 : Diagramme de classe des CU : « Enregistrer une compagnie » et « Enregistrer un bus »
- Pour ce Sprint, nous allons présenter le diagramme de séquence pour les cas d’utilisation
« Enregistrer une compagnie » et « Enregistrer un bus ».
37
Enregi strer une compagni e
MonCar
Admi n / Agent
Demander à enregi strer une compagni e
Affi chage du formul ai re d'enregi strement de compagni e
Rempl i ssage des champs obl i gatoi res
Véri fi cati on des i nformati ons sai si es

Noti fi e l 'i nval i di té des i nformati ons
Renvoi e du formul ai re d'enregi strement de compagni e
Enregi strer compagni e ()
Affi chage du formul ai re d'enregi strement et noti fi cati on du reussi te de l 'operati on
Figure 19 : Diagramme de séquence du CU: « Enregistrer une compagnie »

Enregi strer un bus
MonCar
Admi n / Agent
Demander à enregi strer un bus
Affi chage du formul ai re d'enregi strement de bus

Noti fi e l 'i nval i di té des i nformati ons
Renvoi e du formul ai re d'enregi strement de bus
Enregi strer bus ()
Affi chage du formul ai re d'enregi strement et noti fi cati on du reussi te de l 'operati on
Figure 20 : Diagramme de séquence du CU : « Enregistrer un bus »
38
5.3.4 Test
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Après
l’authentification, le client se trouve capable de bénéficier des différents services offerts.
- La figure 22 illustre l’interface du menu principal (qui inclut uniquement les services dédiés
aux administrateurs).
- La figure 23 illustre l’interface d’ajout d’un bus.
- La figure 24 illustre l’interface de la liste des bus.
Figure 21 : Interface du menu principal
Figure 22 : Interface d'ajout d'un bus
39
Figure 23 : Interface de la liste des bus
5.4 Sprint 3 : Gestions des réservations
constitueront le Backlog du sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés. Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
- Objectif : Le visiteur peut consulter les offres de voyages. Le client peut de s’authentifier, faire
une réservation, consulter ses réservations et annuler une réservation.
Le planning de ce sprint est représenté ici par le Backlog du sprint qui est issue du Backlog global.
Tableau 17 : Backlog du sprint « Gestion des réservations »

Consulter les offres de voyages En tant que visiteur ou client, je veux consulter les 1
offres de voyages
Faire une réservation En tant que client, je veux faire une réservation 2
Consulter ses réservations En tant que client, je veux consulter mes réservations 3
Générer un billet En tant que client, je veux générer un billet 3
Annuler une réservation En tant que client, je veux annuler une réservation 3
40
Afin d'accéder aux différentes fonctionnalités offertes par l'application MonCar, le client doit
s'authentifier en saisissant un numéro de téléphone ou un email et un mot de passe qu’il a eu à
saisir lors de son inscription. Il a également la possibilité de modifier son mot de passe afin de
personnaliser ses paramètres d'authentification.
Consul ter l es offres de voyages
Vi si teur
<>
Consuter ses reservati ons
<>
Fai re une reservati on
S'authenti fi er
<>

Annul er une reservati on
Generer un bi l l et <>
Cl i ent
Figure 24 : Diagramme du CU global du sprint gestion des réservations
A titre d'exemple, nous détaillons le cas d'utilisation « Faire une réservation », « Annuler une
réservation » et les autres cas d'utilisation généralisés suivent le même principe.
Ci-dessous la description textuelle du cas d’utilisation « Faire une réservation »
41
Tableau 18 : Description textuelle du CU: « Faire une réservation »
Cas d’utilisation (CU) : Faire une réservation
Objectif : permettre au client de faire une Acteur : Client
réservation.
Version : 1.0
Pré condition : Se connecter et consulter les offres de voyages
Scénario nominal :
1- L’acteur choisie une offre de voyages et sélectionne une chaise disponible
2- Le système envoie le formulaire de réservation
5- Le système charge le site de payement
6- L’acteur effectue le payement
7- Le système vérifie le payement(SA2)
8- Le système envoie la page de payement réussie
nominal
SA2 : Le payement n’a pas abouti : l’enchaînement commence au point 8 du scénario nominal
11- Le système envoie la page d’échec payement
Post condition : La réservation est enregistrée dans le système
Ci-dessous la description textuelle du CU : « Annuler une réservation »
Tableau 19 : Description textuelle du CU : « Annuler une réservation »

Cas d’utilisation (CU) : Annuler une réservation
Objectif : permettre au client d’annuler une Acteur : Client
réservation
Version : 1.0
Scénario nominal :
1- L’acteur demande à annuler une réservation
2- Le système envoie le formulaire d’annulation de réservation
5- Le système effectue l’opération
6- Le système notifie la réussite de l’opération
42
nominal
Post condition : L’annulation de la réservation est enregistrée dans le système
5.4.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
- La figure ci-dessous illustre le diagramme de classes des cas d’utilisation « Faire une
réservation » et « Annuler une réservation ».

- prom o_i d
Cancel l ati on - code
1..1 - expi re_date___
- cancel l ati on_i d
- adverti sem ent_status + vi ew_prom o ()
+ add_prom o ()
+ vi ew_cancel l ati on ()
+ edi t_prom o ()
+ add_cancel l ati on () Affecte + del ete_prom o ()
+ edi t_cancel l ati on ()
+ del ete_cancel l ati on () Correspond
...
1..* 1..* Route

1..1
- route_i d
Booki ng_detai l s 0..* Donne l i eu - board_poi nt
- board_ti m e
- booki ngdetai l s_i d
- fare
- paym ent_status
- paym ent_opti on + vi ew_route ()
1..1 + add_route () 1..1
- prom o_code
+ edi t_route ()
- booki ng_date Conti ent
Conti ent + del ete_route ()
+ vi ew_booki ng () ...
1..* 1..*
+ vi ew_bookpopup () 1..1
0..* Board_poi nts Drop_poi nts

- boardpoi nt_i d - droppoi nt_i d
Concerne - pi ckup_poi nt - stoppi ng_poi nt
- pi ckup_ti m e - drop_ti m e
Effectue
- l andm ark - l andm ark
- addresse - addresse
1..1 - status
1..* - status
User ... ...
- user_i d Custom er_detai l s
- usernam e - custom er_i d
- password - custom er_nam e
- nam e - age
- reset_key - m obi l e
+ si gnup () - em ai l
+ l ogi n () - gender
+ reset_pass () + vi ew_custom er ()
+ forgot_pass ()
Figure 25 : Diagramme de classe des CU : « Faire une réservation » et « Annuler une réservation »
- Pour ce Sprint, nous allons présenter le diagramme de séquence pour les cas d’utilisation
« Faire une réservation » et « Annuler une réservation ».
43
Figure 26 : Diagramme de séquence du CU : « Faire une réservation »
44
Figure 27 : Diagramme de séquence du CU : « Annuler une réservation »
5.4.4 Test
Nous illustrons à ce niveau les captures d’écran réalisés dans ce sprint. Après s’être authentifié, le
client MonCar se trouve capable de bénéficier des différents services offerts par la plateforme.
- La figure 28 illustre l’interface de consultation des trajets.

- La figure 29 illustre l’interface de choix de place(s).
- La figure 30 illustre l’interface de réservation.
- La figure 31 illustre l’interface d’annulation de réservation d’un trajet.
45
Figure 28 : Interface de consultation de trajets
Figure 29 : Interface de choix de place
Figure 30 : Interface de confirmation de réservation
46
Figure 31 : Interface d'annulation
5.5 Conclusion
Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui est
un produit potentiellement livrable. Dans ce chapitre, nous avons réussi à produire des incréments
ayant suffisamment de valeur pour notre client. Dans le chapitre qui suit, notre effort sera consacré
au déploiement de notre application finale.
47
CHAPITRE VI : CODAGE ET DEPLOIEMENT
6.1 Introduction
Dans ce chapitre, nous donnerons un aperçu sur le travail accompli au niveau de l’implémentation
des modules définis dans les chapitres précédents. Plus précisément, nous allons présenter les
diagrammes de package, de déploiement et de séquence d’application, ainsi qu’un diagramme de
classes global de toute l’application suivi du schéma de la base de données.
6.2 Codage
Les travaux menés dans cette étape se résument tout simplement dans l’implémentation et la
réalisation des cas d’utilisations analysés lors des étapes précédentes. Pour notre cas, le codage se
traduit par un diagramme de package, un diagramme de classes global de toute l’application, un
diagramme de séquence d’application et un schéma de la base de données.
6.2.1 Diagramme de package
Le diagramme de package est un regroupement d’éléments de modélisation. Les packages

constituent des regroupements fonctionnels de classes et d’associations dans le but de mettre en
évidence une fonctionnalité particulière. Dans le cadre de la réalisation de notre logiciel nous avons
distingués trois (03) packages principaux : le package de gestion des utilisateurs, le package
administration, et le package de gestion des réservations.
Gestion des utilisateurs Administration
Gestion des reservations
Figure 32 : Diagramme de package
48
6.2.2 Diagramme de classe global de l’application
Le diagramme de classes d’application constitue le diagramme de classe raffiné. En effet, il

complète celui-ci par des interfaces où figurent les différentes méthodes qui pourront être appelées.
La Figure 6 ci-dessous illustre le digramme de classe d’application de notre système.
6.2.3 Diagramme de séquence d’application
Le diagramme de séquences d’application est un diagramme de séquence système amélioré avec

plus de précision. Son objectif est de faire ressortir les interactions des acteurs avec les composants
logiciels que présente le système.
49
S'authentifier
MonCar BD
Utilisateur
Demande à acceder au système
Envoie du formulaire de connexion
Remplir le formulaire de connexion

Demande donnees du compte
Envoie des donnees du compte
Verification
alt Connexion echouée
loop [Donnees saisies incorrectes]
Notifie données saisies incorrectes
Renvoie du formulaire
Saisir et valider
Demande des donnees du compte
Envoie des donnees

Verification
opt [Connexion reussie]
Demande des privileges utilisateur
Envoie des privileges
Charge les parametres
Connexion reussie
Demande des privileges utilisateur
Envoie des privileges
Charge les privileges
Figure 33 : Diagramme de séquence d'application du CU : « S'authentifier »
50
Figure 34 : Diagramme de séquence d'application du CU : « Enregistrer un trajet »
51
Figure 35 : Diagramme de séquence d'application du CU : « Faire une réservation »
52
Agent
Inscri t 0..*
- agent_i d
- usernam e
- fi rst_nam e
- l ast_nam e
- com pagny_nam e
- addresse
- em ai l
1..1 - country
Enregi stre Adm i n + vi ew_agent ()
Com pagny 0..* 1..1
+ add_agent ()
- com pagny_i d - adm i n_i d
0..* Cree + edi t_agent ()
1..1 - usernam e
- com pagny_nam e + del ete_agent ()
1..1 - password
- com pagny_num ber
Cancel l ati on - profi l e_pi cture
- com pagny_m ai l Adm i ni stre
1..1
- status - cancel l ati on_i d : i nt + change_pass ()
- adverti sem ent_status : i nt + profi l e_vi ew ()
+ vi ew_com pagny ()
...
+ add_com pagny () Di spose + vi ew_cancel l ati on () 1..1
+ edi t_com pagny () + add_cancel l ati on () 1..1
Cree
+ del ete_com pagny () + edi t_cancel l ati on ()
+ del ete_cancel l ati on () 0..*
... Enregi stre
1..1
1..1 Correspond - code 1..*
- bustype_i d
1..* - expi re_date___
- bus_type
- status Correspond + vi ew_prom o () Setti ng
... Bus Affecte + add_prom o ()
1..* - setti ng_i d
1..* + edi t_prom o () - ti tl e
- bus_i d 1..*
+ del ete_prom o () - l ogo
- bus_nam e Affecte
Am eni ti es 1..* - board_poi nt - fl avi con
1..1
1..* 1..* Route - sm tp_usernam e
- am eni ti es_i d - board_ti m e 1..* 1..1
Se retrouve
- am eni ti es - drop_ti m e - route_i d - sm tp_host
- status - bus_status Booki ng_detai l s 0..* Donne l i eu - board_poi nt - sm tp_password
... - board_ti m e - sender_i d
+ vi ew_bus () - booki ngdetai l s_i d
- fare - sm s_usernam e
Bus_gal l ery + add_bus () - paym ent_status
Possede - sm s_password
1..* + bus_acti ve () - paym ent_opti on + vi ew_route ()
- busgal l ery_i d : i nt - paym ent_opti on
1..1 + edi t_bus () 1..1 + add_route () 1..1
- i m age : i nt - prom o_code
+ edi t_route () - paypal
- create_by : i nt + del ete_bus () - booki ng_date
Conti ent + del ete_route () - paypal i d
...
1..1 + vi ew_booki ng () ... - app_key
1..* Donne l i eu 1..1 1..*
Seat_l ayout + vi ew_bookpopup ()
est affecte Conti ent
1..1
- seatl ayout_i d 0..* 0..* Board_poi nts 1..*
- totel _seat
- boardpoi nt_i d
- l ayout Rati ng Drop_poi nts
- l ayout_type Concerne - pi ckup_poi nt
- rati ng_i d - pi ckup_ti m e - droppoi nt_i d
- l ast_seat - bus_qual i ty Effectue
- l andm ark - stoppi ng_poi nt
- no_sl eeper - punctual i ty - addresse
... - drop_ti m e
- staff_behavi our - status - l andm ark
1..1 1..* ...
- average - addresse
- com m ents User - status
Custom er_detai l s
0..* ...
- user_i d - custom er_i d
Effectue - usernam e - custom er_nam e
1..1 - password - age
- nam e - m obi l e
- reset_key - em ai l
+ si gnup () - gender
+ l ogi n () + vi ew_custom er ()
+ reset_pass ()
+ forgot_pass ()
Figure 36 : Diagramme de classe d'application global du système
53
6.2.4 Schéma physique des données
Le schéma physique des données est une représentation graphique des relations des différents
concepts du système. Le modèle physique de données est le résultat de la transformation du
diagramme des classes UML. Le modèle physique de données est directement exploitable par le
SGBD. La Figure 8 ci-dessous illustre le modèle physique de donnée de notre application.
6.3 Déploiement
Dans notre projet, le déploiement se traduit par un diagramme de déploiement qui permet de
représenter la répartition géographique des composants matériels de notre système sous forme de
nœuds.
Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont répartis
ainsi que leurs relations entre eux. Il est couramment utilisé pour décrire l’architecture technique
générale d’un système. La figure suivante représente le diagramme de déploiement de notre
solution.
Figure 37 : Diagramme de déploiement
54
6.4 Conclusion
Dans ce chapitre, nous avons essayé de donner une meilleure visibilité du projet sur le plan
technique, à travers la mise en place d’un schéma de la base de données et de présenter le
diagramme de déploiement de l’application globale. Le prochain chapitre évoquera la politique de
sécurité et présentera quelques écrans de l’application ainsi réalisée.
55
board_poi nts drop_poi nts
board_poi nt_i d i nt(11) fk_dropi d_route drop_poi nt_i d i nt(11)

pi ckup_poi nt varchar(20) stopi ng_poi nt varchar(250)
pi ckup_ti me varchar(20) drop_ti me varchar(250)
l andmark varchar(250) route l andmark varchar(250)
address varchar(250) address varchar(250)
route_i d i nt(11)
status i nt(11) status i nt(11)
bus_i d i nt(11)
... ...
board_poi nt_i d i nt(11)
fk_boardi d_route board_ti me varchar(20)
bus_type drop_poi nt_i d i nt(11)
bus_type_i d i nt(11) drop_ti me varchar(20)
bus_type varchar(20) fare i nt(11)
status varchar(250) fare_ar varchar(250)
cal endar varchar(250)
status i nt(11)
bus_gal l ery
created_by varchar(250)
customer_detai l s
busgal l ery_i d i nt(11) ...
i mage varchar(250) ameni ti es customer_i d i nt(11)
user_i d i nt(11) fk_routei d_booki ng_detai l s customer_name varchar(250)
fk_busi d_bus_gal l ery ameni ti es_i d i nt(11)
bus_i d i nt(11) age varchar(250)
ameni ti es varchar(250)
booki ng_detai l s mobi l e varchar(250)
created_by i nt(250) status i nt(11)
fk_bustypei d_bus
... booki ng_i d i nt(11) emai l varchar(250)
cancel l ati on_i d i nt(11) gender varchar(250)
fk_booki ng_customer_detai l s
promo_i d i nt(11) booki ngdet_i d i nt(11)
fk_ameni ti esi d_bus
seat_l ayout bus amount varchar(250) order_i d varchar(250)
bus_i d i nt(11) seat_no varchar(250)
seat_i d i nt(11) bus_i d i nt(11)
route_i d i nt(11) ...
bus_i d i nt(11) bus_name varchar(20)
bus_type_i d i nt(11) user_i d i nt(11)
bus_type varchar(250)
fk_busi d_route payment_status varchar(250)
totel _seat varchar(250) compagny_i d i nt(11)
payment_opti on varchar(250) fk_promoi d_booki ng_detai l s
l ayout l ongtext fk_busi d_seat_l ayout ameni ti es_i d varchar(250) fk_busi d_booki ng_detai l s
admi n_i d i nt(11) promo_code varchar(255)
l ayout_type varchar(250)
bus_reg_no varchar(20) fk_booki ngi d_user booki ng_date varchar(250)
l ast_seat varchar(250)
max_seats i nt(11) status varchar(250)
no_sl eeper varchar(20)
... board_poi nt varchar(250)
board_ti me varchar(20)
drop_poi nt varchar(20) promo_detai l s
drop_ti me varchar(20) user promo_i d i nt(11)
status i nt(11) fk_admi ni d_bus
user_i d i nt(11) admi n_i d i nt(11)
bus_status i nt(200) booki ng_i d i nt(11) code varchar(100)
created_by varchar(250) type varchar(100)
username varchar(30)
...
password varchar(250) amount i nt(11)
name varchar(20) expi re_date date
fk_useri d_bus_gal l ery
dob varchar(20) status i nt(11)
fk_compagnyi d_bus i mage varchar(80) created_by i nt(11)
gender varchar(16) ...
fk_cancel l ati oni d_booki ng_detai l s
mob i nt(11)
rati ng reset_key varchar(250)
fk_busi d_rati ng ...
rati ng_i d i nt(11)
user_i d i nt(11) fk_useri d_rati ng
bus_i d i nt(11)
bus_qual i ty varchar(250) admi n
punctual i ty varchar(250) fk_admi ni d_promo_detai l s
compagny admi n_i d i nt(11)
Staff_behavi our varchar(250)
username varchar(250) cancel l ati on
average varchar(250) compagny_i d i nt(11)
password varchar(250)
comments varchar(250) admi n_i d i nt(11) fk_admi ni d_compagny cancel l ati on_i d i nt(11)
profi l e_pi cture varchar(250)
... compagny_name varchar(250) admi n_i d i nt(11)
status varchar(250) fk_admi ni d_cancel l ati on
compagny_number varchar(250) adverti sement_status i nt(11)
fk_admi ni d_agent user_type i nt(11)
compagny_mai l varchar(250) cancel _ti me varchar(250)
...
compagny_status varchar(250) percentage varchar(11)
fk_admi ni d_setti ng
... fl at varchar(250)
type varchar(250)
...
setti ng
agent
setti ng_i d i nt(11)
agent_i d i nt(11)
admi n_i d i nt(11)
admi n_i d i nt(11)
ti tl e varchar(250)
compagny_i d i nt(11)
l ogo varchar(250)
username varchar(250)
favi con varchar(250)
fi rst_name varchar(250)
smtp_username varchar(250)
l ast_name varchar(250)
smtp_host varchar(250)
password varchar(250)
smtp_password varchar(250)
company_name varchar(250)
sender_i d varchar(250)
address varchar(250)
sms_username varchar(250)
emai l varchar(250)
sms_password varchar(250)
phone_number varchar(250)
payment_opti on varchar(255)
ci ty varchar(250)
paypal varchar(250)
country varchar(250)
paypal i d varchar(251)
profi l e_pi cture varchar(250)
app_key varchar(100)
status varchar(250) ...
created_by varchar(250)
...
Figure 38 : Modèle physique de donnée
56
CHAPITRE VII : REALISATION ET BILAN
7.1 Introduction
Dans ce chapitre, nous présenterons les modules développés, de l’enchainement des écrans de
notre système et nous justifierons les écarts constatés après une comparaison du planning réel et
prévisionnel. Au terme de ce chapitre, les politiques et moyens de sécurité liées à l’application et
d’ordre général seront présentés.
7.2 Modules développés
Pour la mise en place de notre solution, nous avons pu réaliser en grande partie les modules
englobant les fonctionnalités qui nous ont été demandés. Les modules développés sont entre autre :
- Gestion des réservations : ce module rassemble toute les fonctionnalités liées à une
réservation (la création d’une nouvelle réservation, la suppression d’une réservation, la
modification d’une réservation, lister ses réservations) ;
- Gestion des utilisateurs : ce module regroupe toutes les fonctionnalités permettant l’ajout,
la modification, la suppression d’un utilisateur ;
- Gestion des trajets : ce module permet l’enregistrement d’un nouveau trajet ainsi que sa
gestion ;
- Gestion des bus : ce module permet l’enregistrement d’un nouveau bus ainsi que sa gestion;
- Paramétrage des comptes : ce module permet aux utilisateurs de la plateforme de
personnaliser leurs comptes.
7.3 Enchainements des écrans
Ici seront présentées quelques interfaces de notre système développé pendant le stage.
Pour accéder à la plateforme MonCar, le visiteur entre l’URL dans le navigateur web, il devra
obtenir la page d’accueil qui lui offrira la possibilité de se connecter ou de s’inscrire en tant que
client sur ladite plateforme. Une fois l’authentification ou l’inscription réussie, l’utilisateur accède
à son environnement de travail.
57
Figure 39 : Ecran d'accueil
Cet écran permet à l’utilisateur connecté de consulter les différents trajets de voyages sur la
plateforme.
Figure 40 : Ecran de consultation de trajet
L’écran suivant permet à l’utilisateur connecté de choisir le nombre place pour une réservation de
trajet.
58
Figure 41 : Ecran de Choix de la place
L’écran ci-dessous permet de remplir le formulaire de réservation et de choisir le mode de paiement.
Figure 42 : Ecran de paiement
L’écran ci-dessous illustre celui d’une réservation réussie.
59
Figure 43 : Ecran de réservation réussie
La figure 45 ci-dessous illustre l’écran du tableau de bord d’un administrateur.
Figure 44 : Tableau de bord du back office
La dernière figure illustre l’écran d’ajout d’un nouveau trajet.
60
Figure 45 : Interface d'ajout d'un trajet
7.4 Analyses des écarts
Figure 1 : Planning réel
Nous constatons que le planning prévisionnel n’a pas été suivi. Nous donnons les raisons qui ont
prévalues :
- L’étude et la compréhension du domaine a pris plus de temps que prévu, l’équipe de
développement n’étant pas en contact direct avec les principaux acteurs, nous avons dû
nous inspirer des analyses menées par nos agents technico-commerciaux.
- Il y a aussi la prise en main du Framework CodeIgniter. En effet, même si cette plateforme
est construite sur le langage PHP, elle y ajoute un grand nombre d’outils remplissant tout
un tas de fonctionnalités que nous avons pris le temps de comprendre.
- Le temps prévu pour la modélisation a connu un grand dépassement du fait des
modifications opérées tout au long du processus.
61
7.5 Procédures transitoires
Les procédures transitoires constituent un ensemble de tâches à exécuter pour passer du système
d'information actuel au système futur. Ces tâches correspondent à la mise en place du nouveau
système et son fonctionnement pendant une période donnée. Le futur système devra alors être
soumis à une série de tests afin de s'assurer de son adéquation avec les besoins exprimés par les
utilisateurs. Les éventuelles défaillances décelées au cours de ces tests seront progressivement
corrigées jusqu'à l'obtention d'une application relativement stable.
Par ailleurs, une formation des utilisateurs est prévue afin que ceux-ci puissent prendre pleinement
possession des différentes fonctionnalités du futur système. La formation va donc permettre non
seulement à ces utilisateurs de se familiariser avec le logiciel mais aussi de constater les éventuelles
erreurs et insuffisances de ce dernier. Cela permettra la révision et la correction des imperfections
par l'équipe des développeurs. L'application sera mise en service pour une période transitoire de
trois (03) mois au cours de laquelle elle fonctionnera en parallèle avec le système actuel pour
s'assurer qu'il répond entièrement aux besoins spécifiés. Au cas où les essais sont concluants le
basculement définitif vers le futur système pourra se faire aisément en concertation avec les
compagnies de transport.
7.6 Politique de sécurité
La sécurité est une stratégie préventive qui s'inscrit dans une approche d'intelligence économique.
Elle ne permet pas de gagner de l'argent, mais évite d'en perdre. L'objectif de la sécurité des
systèmes d'information est de garantir, qu'aucun préjudice ne puisse mettre en péril la pérennité de
l'entreprise. La politique de sécurité a pour but de minimiser les risques de panne, d'éviter que la
base de données soit dans un état d'incohérence, d'éviter les accès non autorisés à la base et d'éviter
la présence de programmes indésirables dans le réseau. Il s'agit donc de prendre toutes les
dispositions utiles afin de réduire au minimum les effets néfastes des pannes matérielles ou
logicielles.
62
7.6.1 Politique de gestion des connexions distantes aux serveurs
Le scenario choisit pour accéder à l’application MonCar impose une connexion internet. Ce qui
pose un problème de sécurité sur les données échangées entre les machines clientes et le nouveau
système hébergé sur le serveur distant.
Pour cela, nous proposons lors de la configuration du serveur, d’intégrer le serveur web Apache-
HTTP afin de protéger les transferts de données par une connexion sécurisée : HTTPS (avec S
pour secured, soit « sécurisé ») est la variante de HTTP basée sur les protocoles SSL. Il permet au
visiteur de vérifier l'identité du site auquel il accède grâce à un certificat d'authentification. Il permet
également de chiffrer la communication. Il est utilisé pour les transactions sécurisées sur Internet.
Ce protocole est inclus dans pratiquement tous les navigateurs.
Cela assurera trois choses :
- Confidentialité des données : Il est ardu d'espionner les informations échangées ;
- Intégrité des données ;
- Authentification : Il permet de s'assurer de l'identité du programme, de la personne avec

laquelle le système communique.
7.6.2 Gestion des mots de passe et connexion à l’application
La politique de gestion de mots de passe est à la fois technique et organisationnelle. Elle vise à
réduire les risques pour le système d'information liés à l'emploi du mécanisme d’authentification
par le couple nom d’utilisateur/mot de passe.
Dans ce projet, des dispositions sont prises :
- Les mots de passe utilisés pour se connecter au système seront chiffrés par l’algorithme SHA1;
- La longueur minimum pour les mots de passe est de 6 caractères.
7.6.3 Protection contre les virus
Un virus informatique est un logiciel malveillant conçu pour se propager à d'autres ordinateurs en
s'insérant dans des programmes légitimes appelés « hôtes ». Il a pour but de perturber l'ordinateur
infecté. Il peut se répandre à travers tout moyen d'échange de données numériques comme les
réseaux informatiques et de périphériques (USB, CD etc…). Pour assurer la protection contre les
virus, des antivirus efficaces sont installés sur les postes des différents administrateurs et agents.
63
7.7 Conclusion
Dans ce chapitre nous avons exposé les différents éléments concernant la réalisation de la
plateforme. Ensuite, nous avons expliqués les écarts constatés au niveau du planning prévisionnel.
Enfin des politiques et moyens de sécurité dans le but de rendre l’application plus pérenne et fiable
ont été présentées.
64
CONCLUSION GENERALE
Dans le cadre de notre stage de fin du cycle en licence d’Ingénierie des Systèmes d’Information
(ISI), nous avons été accueillis à KeoLID d’où nous avons effectué un stage d’une durée de quatre
(04) mois. Il nous a été soumis comme thème d’étude : « La Mise en place d’une plateforme de
gestion et de réservation des tickets de bus ». Il était question pour nous de digitaliser la gestion et
la réservation des tickets de bus tout en résolvant les contraintes de temps rencontrées lors des
réservations, de suivi, de stockage et les problèmes de paiements des réservations.
Afin de mener à bien ce projet, nous avons utilisé plusieurs technologies et outils. En ce qui
concerne la méthode de résolution, elle est basée essentiellement sur le processus de
développement Scrum et le langage de modélisation UML pour l’analyse du domaine, la
spécification du système et la conception de la solution. Pour ce qui est du développement, nous
avons utilisé entre autres la plateforme PHP 7, le Framework CodeIgniter en sa version 3.0.3, Ajax,
Angular js et JQuery. Le système de gestion de base de données est MySQL 5.7.
En rappel, les résultats attendus étaient :
- La consultation des différents trajets proposés par différentes compagnies de transports ;
- La gestion des utilisateurs ;
- La gestion des réservations de tickets de bus par compagnie de transport ;
- La gestion des compagnies de transports ;
- La gestion des trajets ;
- La gestion des paiements de tickets réservés en ligne par mobile money.
A l’issue de ce stage nous avons pu produire un cahier de charges fonctionnelles et techniques du
projet, modéliser puis réaliser une plateforme web pour la gestion et la réservation des tickets de
bus.
Ce projet a été pour nous une opportunité de mise en pratique de l’ensemble des connaissances
apprises tout au long du cycle. Nous nous sommes initiés à un nouvel environnement de
développement qui est le Framework CodeIgniter. A travers les formations, nos connaissances sur
le fonctionnement des compagnies de transport et de la gestion d’entreprise ont été enrichie.
En perspective, nous pensons que la conception d’une plateforme mobile permettra aux potentiels
clients d’en bénéficier d’avantage des services offerts par MonCar. Aussi il sera intéressant de
réaliser un système qui interagira entre les systèmes de gestion des compagnies de transport et notre
application.
65
LISTE DES REFERENCES BIBLIOGRAPHIQUES
[1] Jean Engels, « PHP5 cours et exercices », 2ème édition, Eyrolles, 2005,623 pages.
[2] PASCAL ROQUES, « UML2 par la pratique : Étude de cas et exercices corrigés » 6ème édition,
Eyrolles, 2008,380 pages.
[3] M. BAMBARA Victorien Zidabou, « Mise en place d’un portail web intégré institutionnel pour
l’Association pour le Renforcement des Capacités des Diplômés de l’École Supérieure
d’Informatique (ARCDESI) », Mémoire de fin de cycle CICI, ESI 2016-2017.
[4] M. CABORE Kévin Aziz& M. ZIDA Moussa, « Mise en place d’une bibliothèque numérique à
l’ESI », Rapport de fin d’année CICI, ESI 2015-2016.
[5] M. ILLY Poulmanogo, « Réalisation d’un logiciel de Comptabilité générale avec suivi analytique
et budgétaire selon le SYSCOHADA », Rapport de fin de cycle CITI, ESI 2013-2014.
[6] M. LANKOUANDE Laurent, « Système de gestion informatisée d’un tiers lieu dédié à
l’entrepreneuriat numérique : cas de BeoogoLab », Rapport de fin de cycle CITI, ESI 2015-2016.
[7] « Documentation officielle de CodeIgniter »
http://www.codeigniter.com/, consulté régulièrement depuis le 11 septembre 2017.
[8] « Documentation officielle de PHP »
http://www.php.net/, consulté régulièrement depuis le 11 septembre 2017.
[9] « Méthodes classiques VS méthodes agiles »
http://www.access-dev.com/access-dev/la-gestion-de-projet-methodes-classiques-vs-methodes-
agiles/ , consulté le 20 octobre 2017.
[10] « La méthode agile scrum »
http://www.supinfo.com/articles/single/3633-gestion-projet-agile-avec-scrum/, consulté le 24
octobre 2017.
http://www.supinfo.com/articles/single/6107-presentation-methode-agile-scrum/, consulté le
24 octobre 2017.
[11] « La méthode d’estimation des coûts : Le planning poker »
https://www.unow.fr/blog/le-coin-des-experts/estimations-planning-poker/, consulté le 7
novembre 2017.
[12] « La rémunération salariale des développeurs web en 2016-2017 »
https://www.journaldunet.com/web-tech/developpeur/1186121-les-salaires-des-developpeurs-
digitaux-par-profils-en-2016/, consulté le 22 novembre 2017.
66
ANNEXE I : CODEIGNITER
CodeIgniter est un Framework d'EllisLab conçu par Ric k Ellis.

CodeIgniter est très largement inspiré de leur projet
ExpressionEngine3. CodeIgniter a connu sa première version le 28
février 2006. CodeIgniter est un environnement cadre de
développement d'application, un ensemble d'outils permettant de
structurer et de construire des sites Web en utilisant PHP. Les
principales caractéristiques de CodeIgniter :
- Une compatibilité totale avec PHP 7 ;
- Simplicité de prise en main ;
- Une intégration de l’architecture MVC qui est une bonne pratique de programmation
recommandant le découpage du code en au moins trois parties que sont le Modèle, la Vue
et le Contrôleur ;
- Une disponibilité de nombreuses librairies ;
- Une souplesse et une évolution constante ;
- Une compatibilité avec la quasi-totalité des systèmes de gestion de base de données.
Son objectif est de vous permettre de développer des projets beaucoup plus rapidement
que si vous partiez de zéro, en fournissant un ensemble fourni de bibliothèques pour les
tâches habituellement nécessaires, ainsi que d'une interface simple et une structuration
logique d'accès à ces bibliothèques. CodeIgniter vous permet de vous concentrer sur votre
créativité en minimisant la quantité de code nécessaire pour réaliser une tâche donnée.
67
ANNEXE II : COMPARAISON ENTRE L’APPROCHE CLASSIQUE ET
L’APPROCHE AGILE
Thème Approche classique Approche agile

(traditionnelle)
Cycle de vie En cascade ou en V, sans rétroaction Itératif et incrémental
possible, phase séquentielles.
Planification Prédictive, caractérisée par des plans Adaptative avec plusieurs niveaux de
plus ou moins détaillés sur la base d’un planification (macro- et micro-
périmètre et d’exigences définies et planification) avec ajustements si
stables au début du projet. nécessaires au fil de l’eau en fonction
des changements survenus.
Documentation Produite en quantité importante Réduire au strict nécessaire au profit
comme support de communication, d’incréments fonctionnels
de validation et de contractualisation. opérationnels pour obtenir le
feedback du client.
Equipe Une équipe avec des ressources Une équipe responsabilisée ou
spécialisée, dirigées par un chef de l’initiative et la communication sont
projet. privilégiées, soutenue par le chef de
projet.
Qualité Contrôle qualité à la fin du cycle Un contrôle qualité précoce et
développement. Le client découvre le permanent, au niveau du produit et
produit fini. du processus. Le client visualise les
résultats tôt et fréquemment.
Changement Résistance voire opposition au Accueil favorable au changement
changement. Processus lourds de inéluctable, intégré dans le
gestion des changements acceptés. processus.
Suivi de Mesure de la conformité aux plans Un seul indicateur d’avancement : le
l’avancement initiaux. Analyse des écarts. nombre de fonctionnalités
implémentées et le travail restant à
faire.
Gestion des Processus distinct, rigoureux, de Gestion des risques intégrée dans le
risques gestion des risques. processus global, avec
responsabilisation de chacun dans
l’identification et la résolution des
risques. Pilotage par les risques.
Mesure du Respect des engagements initiaux en Satisfaction client par la livraison de
succès termes de couts, de budget et de valeur ajoutée.
niveau de qualité.
68
ANNEXE III : CONTEXTE D’UTILISATION DE QUELQUES METHODES
AGILES
METHODE CONTEXTE D’UTILISATION
Scrum Développement orienté valeur d’affaires, environnement avec

des changements, les projets sont gérés selon les quatre
variables : coût, délai, fonctionnalités et qualité. Remplace les
méthodes en cascade.
Extreme Programming Petits projets, le client est disponible tout au long du projet, les
(XP) participants acceptent les pratiques imposées par la méthode
(travail en binôme).
Lean Kanban Le retour sur investissement n’est pas satisfaisant.
L’optimisation du flux de travail, la limite du travail en cours
et la visualisation du travail.
Agile UP Les grandes organisations. Les processus sont bien définis.
Projets de grande envergure.
Crystal Projets de petite taille avec des contextes différents : ponctuel
ou pas d’historique.
FDD (Feature Driven Conception et implémentation. La taille de l’équipe peut
Development) atteindre 20 personnes.
69

Rapport - MoncarFinal

Transféré par

Droits d'auteur :

Formats disponibles

Rapport - MoncarFinal

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport - MoncarFinal

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de

Thème : « Mise en place d’une plateforme de gestion et de réservation des

Période du 16 aout 2017 au 15 décembre 2017

Maître de stage Superviseur

Année Académique 2016-2017

AJAX Asynchronous Javascript And XML

API Application Programming Interface

CICI Cycle des Ingénieurs de Conception Informatique

CITI Cycle des Ingénieurs de Travaux Informatiques

DOM Document Object Model

ESI Ecole Supérieure d’Informatique

SGBD Système de Gestion des Bases de Données

UNB Université Nazi BONI

Figure 1 : Organigramme de la structure d’accueil ............................................................................................. 3

Tableau 1 : Description des concepts du domaine ............................................................................................ 12

1.2 Structure de formation

1.3 Structure d’accueil

L’organigramme de KeoLID est celui de la figure ci-après.

Figure 1 : Organigramme de la structure d’accueil

1.4 Présentation du projet

1.4.2 Objectifs du projet

1.4.3 Résultats attendus

L’application que nous allons mettre en place doit permettre :

1.4.4 Gestion du projet

Ce chapitre nous a permis en premier de présenté l’organisation administrative de l’école, le

2.2 Exigences fonctionnelles et techniques

2.3 Méthode de résolution du problème

2.3.1 Langage de modélisation UML

La réalisation de tout système informatique nécessite une modélisation préalable. Un langage de

2.3.2.1 La Méthode Scrum

2.3.2.2 Cycle de vie de la méthode Scrum

La figure ci-dessous représente le cycle de vie de la méthode de résolution scrum.

Figure 3 : Processus scrum

Un processus scrum est constitué en trois (03) étapes :

2.3.2.3 Acteurs du projet selon la méthode Scrum

2.4 Méthode d’estimation des coûts

3.2 Etude de l’existant

3.2.1 Ressources et organisation du travail

3.2.2 Analyse critique de l'existant

3.3.1 Identification des concepts clés

Tableau 1 : Description des concepts du domaine

Tableau 2 : Dictionnaire de donnée de la classe user

Tableau 3 : Dictionnaire de donnée de classe bus

Tableau 4 : Dictionnaire de donnée de la classe booking_details

3.3.3 Diagramme de classe de domaine

Ce diagramme est considéré comme le plus important de la modélisation orientée objet. Il

Le diagramme d'états-transitions est une représentation graphique du comportement d'une classe.

Figure 4 : Diagramme d'état transition de la classe « user »

Figure 5 : Diagramme d'état transition de la classe « booking_details »

L’étude du domaine a mis en emphase les différentes ressources et organisation du travail du

Figure 6 : Diagramme de classe du domaine

4.2 Backlog du produit

Tableau 5 : Product Backlog

4.3 Évaluation des coûts du projet

Tableau 6 : Coût de développement

Tableau 7 : Coût de formation des formateurs

4.4 Planification des releases

Tableau 9 : Planning des releases

4.5 Identification de l’équipe scrum