Rapport Final Barry

UNIVERSITE AUBE NOUVELLE
INSTITUT SUPERIEUR D’INFORMATIQUE ET DE GESTION
DEPARTEMENT HIGH-TECH
MEMOIRE DE LICENCE
Option : Technologie du Génie Informatique
T hème :
Mise en place d’une plateforme web pour la gestion de prise de
rendez-vous dans les entreprises.
Présenté par : BARRY Inoussa Sous la direction de :

M. TRAORE Tiémogo
Ingénieur de conception en
système d’information
Maitre de stage :
M. TRAORE Souleymane
Ingénieur Analyste-Programmeur
en informatique
Année académique : 2021-2022

GESTION DE PRISE DE RDV DANS LES ENTREPRISES
SOMMAIRE
RESUME .................................................................................................................................. V
ABSTRACT .............................................................................................................................. VI
INTRODUCTON GENERALE ..................................................................................................... 1
PROBLEMATIQUE.................................................................................................................... 2
CHAPITRE 1 : CONTEXE ET DEMARCHE METHODOLOGIQUE ................................... 3
1.1. INTRODUCTION PARTIELLE .............................................................................................. 3
1.2. PRESENTATION DU CONTEXTE DU STAGE ....................................................................... 3
1.2.1. Présentation de l’université Aube Nouvelle ................................................................. 3
1.2.2. Présentation de la structure de Nos3S ......................................................................... 6
1.2.3. Présentation du thème ................................................................................................. 7
1.3. DEMARCHE ET MOYEN DE RESOLUTION ......................................................................... 9
1.3.1. Les exigences fonctionnelles et techniques ............................................................... 10
1.3.2. Méthodes de résolution du problème ....................................................................... 11
1.4. DOMAINE D’ETUDE........................................................................................................ 16
1.4.1. Etude de l’existant ...................................................................................................... 16
1.4.2. Présentation des ressources disponibles ................................................................... 17
1.5. CONCLUSION PARTIELLE ................................................................................................ 17
CHAPITRE 2 : ANALYSE FONCTIONNELLE ET TECHNIQUE DU FUTUR SYSTEME
.................................................................................................................................................. 18
2.1. INTRODUCTION PARTIELLE ............................................................................................ 18
2.2. SPECIFICATION DU FUTUR SYSTEME ............................................................................. 18
2.2.1. Identification des acteurs et des cas d’utilisation ...................................................... 18
2.2.2. Diagramme de cas de d’utilisation ............................................................................. 24
2.2.3. Diagramme de séquence ............................................................................................ 25
2.3. ARCHITECTURE DU FUTUR SYSTEME ............................................................................. 30
2.3.1. Identification des outils .............................................................................................. 30
2.3.2. Architecture logicielle ................................................................................................. 33
2.3.3. Estimation du coût...................................................................................................... 35
CHAPITRE 3 : CONCEPTION ET REALISATION DE LA SOLUTION ............................ 37
UNIVERSITE AUBE NOUVELLE I

3.2. CONCEPTION DE LA SOLUTION...................................................................................... 37

3.2.1. Délimitation et analyse du domaine .......................................................................... 37
3.3. REALISATION ET BILAN .................................................................................................. 47
3.3.1. Modules développés .................................................................................................. 47
3.3.2. L’enchainement des écrans ........................................................................................ 47
3.3.3. Planning réel ............................................................................................................... 53
3.3.4. Analyse des écarts ...................................................................................................... 54
3.3.5. Politique de sécurité ................................................................................................... 54
CONCLUSION GENERALE ...................................................................................................... 57
UNIVERSITE AUBE NOUVELLE II

DEDICACE
Je dédie ce travail
A ma maman qui m’a soutenu et encouragé durant toutes ces années d’études.
Qu’elle trouve ici le témoignage de ma profonde reconnaissance.
A mes frères, mes sœurs et tous ceux qui ont partagé avec moi tous les moments
d’émotions lors de la réalisation de ce travail. Ils m’ont chaleureusement supporté et
encouragé tout au long de mon parcours.
A ma famille, mes proches et à ceux qui me donnent de l’amour et de la vivacité.
A tous mes amis qui m’ont toujours encouragé, et à qui je souhaite plus de succès.
A tous ceux que j’aime.
UNIVERSITE AUBE NOUVELLE III

REMERCIEMENTS
Comme disait Henry Ward Beecher « La reconnaissance est la plus belle fleur qui jaillit
de l’âme ». Ainsi, je tiens à adresser ma reconnaissance et mes remerciements à toutes les
personnes qui ont contribué de près ou de loin à l’aboutissement de ce travail. Il s’agit notamment
de :
 L’Université Aube Nouvelle de Bobo-Dioulasso et son personnel pour la formation
pédagogique et l’encadrement reçu ;
 L’entreprise Nos3S pour l’accueil, l’accompagnement et les conseils reçus tout au
long du stage ;
 L’entreprise NafaVision pour leur aide et leurs conseils qu’ils nous ont offerts.
Un remerciement particulier et distingué à :
 M.Tiémogo TRAORE, ingénieur de conception en système d’information, mon

superviseur pour sa disponibilité, ses conseils et ses suggestions ;
 M.Souleymane TRAORE, ingénieur analyste-programmeur en informatique, mon
maitre de stage pour son accueil et son accompagnement ;
 M.Drissa BARRO, ingénieur analyste-programmeur en informatique, Directeur
Général de No3S ;
 Nos parents et familles pour le soutien ;
 Nos amis et tous ceux qui ont apporté leur aide d’une manière quelconque.
UNIVERSITE AUBE NOUVELLE IV

RESUME
La prise de rendez-vous est une étape indispensable pour rapprocher les entreprises de
services et leurs clients. Au XXIe siècle, la prise de rendez-vous est devenue une tendance aussi
bien pour de nombreux clients, que pour les entreprises. Cette tendance augmente
considérablement les demandes de rendez-vous dans les entreprises. Face à ce flux massif de
prise de rendez-vous, les entreprises se retrouvent confrontées à d’énormes difficultés et
n’arrivent pas à gérer astucieusement leurs rendez-vous, laissant ainsi échapper beaucoup de
partenaires clés qui pourraient leur permettre de booster leurs business.
L’objectif de notre étude consiste donc à mettre en place un système informatique qui
facilitera la gestion des prises de rendez-vous dans les entreprises.
Pour la réussite de cette étude, nous nous sommes servis de 2TUP (Two Track Unified Process),
une méthode de résolution de problème basée sur le langage de modélisation UML (Unified
Modeling Language). Pour la mise en place de la solution, nous avons fait usage de technologies
web telles que PHP, HTML, CSS, JavaScript, le Framework Bootstrap et le système de gestion
de base de données MySQL.
A l’issue de l’étude du projet, nous avons développé une application web responsive
(adaptable aux ordinateurs, tablettes et smartphones) dénommée RDVonline. Les principales
fonctionnalités de l’application ont été implémentées et des perspectives d’amélioration sont
prévues.
UNIVERSITE AUBE NOUVELLE V

ABSTRACT
Making an appointment is an essential step to bring service companies and their

customers closer together. In the twenty-first century, appointment scheduling has become a
trend for both customers and companies. This trend significantly increases appointment
requests in companies.
Faced with this massive flow of appointments, companies find themselves facing enormous
difficulties and are unable to manage their appointments cleverly, leaving many key partners
who could allow them to boost their business.
The objective of our study is therefore to set up a computer system that will facilitate
the booking and management of online appointments in companies.
For the success of this study, we used 2TUP (Two Track Unified Process), a problem-solving
method based on the Unified Modeling Language (UML). For the implementation of the
solution, we made use of web technologies such as PHP, HTML, CSS, JavaScript, the Bootstrap
Framework and the MySQL database management system.
At the end of the project study, we developed a responsive web application (adaptable
to computers, tablets and smartphones) called RDVonline. The main functionalities of the
application have been implemented and prospects for improvement are planned.
UNIVERSITE AUBE NOUVELLE VI

LISTE DES TABLEAUX
Tableau 1 : Analyse critique de l’existant ................................................................................ 16

Tableau 2 : Les acteurs et leurs rôles ....................................................................................... 18
Tableau 3 : Les acteurs et leurs cas d’utilisation ...................................................................... 19
Tableau 4 : Identification des cas d’utilisation......................................................................... 20
Tableau 5 : Description du cas d'utilisation "créer un compte" ............................................... 20
Tableau 6 : Description du cas d'utilisation "S'authentifier" .................................................... 21
Tableau 7 : Description du cas d'utilisation "Demander rendez-vous" .................................... 22
Tableau 8 : Description du cas d'utilisation "Ajouter une entreprise" ..................................... 22
Tableau 9 : Description du cas d'utilisation "Ajouter un personnel" ....................................... 23
Tableau 10 : Description du cas d'utilisation "Ajouter un emploi de temps"........................... 23
Tableau 11 : Formules de calcul des coûts proposées par COCOMO ..................................... 35
Tableau 12 : Coût du développement ....................................................................................... 36
Tableau 13 : Coût total de mise en œuvre ................................................................................ 36
Tableau 14 : Règles de gestion du domaine d’étude ................................................................ 38
Tableau 15 : Dictionnaire de données de la classe utilisateur .................................................. 39
Tableau 16 : Dictionnaire de données de la classe entreprise .................................................. 39
Tableau 17 : Dictionnaire de données de la classe personnel .................................................. 40
Tableau 18 : Dictionnaire de données de la classe emploi de temps ....................................... 40
Tableau 19 : Dictionnaire de données de la classe Rendez-vous ............................................. 40
UNIVERSITE AUBE NOUVELLE VII

LISTE DES FIGURES
Figure 1 : Organigramme de Nos3S source Nos3S .................................................................... 7

Figure 2 : Planning prévisionnel ................................................................................................ 9
Figure 3 : Présentation 2TUP ................................................................................................... 15
Figure 4 : Diagramme de cas d’utilisation ............................................................................... 25
Figure 5 : Diagramme de séquence de "S’authentifier" ........................................................... 26
Figure 6 : Diagramme de séquence de "Demander RDV" ....................................................... 27
Figure 7 : Diagramme de séquence de " Créer compte" .......................................................... 28
Figure 8 : Diagramme de séquence de "Ajouter entreprise" .................................................... 29
Figure 9 : Diagramme de séquence de "Ajouter personnel" .................................................... 30
Figure 10 : Illustration du modèle MVC .................................................................................. 34
Figure 11 : Diagramme de classe ............................................................................................. 41
Figure 12 : Diagramme d’état transition de la classe rendez-vous........................................... 42
Figure 13 : Diagramme d’état transition de la classe entreprise .............................................. 42
Figure 14 : Diagramme de déploiement ................................................................................... 43
Figure 15 : Modèle logique de données ................................................................................... 45
Figure 16 : Modèle physique de données ................................................................................. 46
Figure 17 : Ecran d’accueil ...................................................................................................... 48
Figure 18 : Ecran d’inscription................................................................................................. 49
Figure 19 : Ecran de connexion................................................................................................ 50
Figure 20 : Ecran d’ajout d’entreprise...................................................................................... 51
Figure 21 : Ecran de présentation d’entreprise......................................................................... 52
Figure 22 : Ecran de présentation des personnels .................................................................... 53
Figure 23 : Ecran des demandes de rendez-vous ..................................................................... 53
Figure 24 : Planning réel .......................................................................................................... 54
UNIVERSITE AUBE NOUVELLE VIII

LISTE DES SIGLES ET ABREVIATION
Sigles Définitions
2TUP 2 Tracks Unified Process
AJAX Asynchronous JavaScript And XML
AP Analyse et Programmation
COCOMO COnstructive COst MOdel
CSS3 Cascading Style Sheets
CU Cas d’Utilisation
U-AUBEN Université Aube Nouvelle
UFR Unité de Formation et de Recherche
HTML HyperText Makup Language
http HyperText Transfert Protocol
ISIG Institut Supérieur d’Informatique et de
Gestion
NAFAVISION NAko et FAbrice VISION
Nos3S Nos Solutions Systèmes et Services
OMT Object Modeling Technique
PHP HyperText Preprocessor
RS Réseaux et Systèmes
SGBD Système de Gestion de Base de Données
SI Système d’Information
SMS Short Message System
SQL Structured Query Language
TCP/IP Transmission Control Protocol /Internet
Protocol
TIC Techniques de l’Information et de la
Communication
UML Unified Modeling Language
XHTML eXtensible HyperText Makup Language
XML eXtensible Makup Language
RDV Rendez-Vous
UNIVERSITE AUBE NOUVELLE IX

INTRODUCTON GENERALE
La gestion de prise de rendez-vous en ligne peut être définie comme étant une solution
digitale qui permet aux professionnels de partager en temps réel leur agenda avec leurs clients
ou leurs partenaires afin d’organiser une potentielle visite.
Après une enquête menée par sondage sur certaines entreprises locales, nous avons
constaté que beaucoup d’entreprises perdaient du temps à enregistrer fréquemment sur papier
des rendez-vous qui n’avaient jamais lieu. Cela est dû soit à un oubli volontaire ou involontaire
des clients ou des partenaires, soit à l’indisponibilité des employés dont les plages horaires déjà
bien définies ne correspondent pas avec celles des clients ou des partenaires. C’est dans cette
optique qu’est née l’idée de mettre en place une plateforme web pour la gestion de prise de
rendez-vous baptisée RDVonline, afin de permettre aux entreprises et à leurs collaborateurs de
gagner en temps et en efficacité, mais aussi de proposer une excellente relation clientèle.
Pour une bonne appréhension de notre présent document, nous allons l’organiser en trois
(03) chapitres. Le premier chapitre présente notre université de formation, la structure d’accueil,
la démarche et les moyens de résolution utilisés, l’étude de l’existant ainsi que l’analyse du
domaine. Le deuxième chapitre traite de la spécification des besoins recueillis et présente
l’architecture de notre système. Et, le troisième chapitre définit la manière dont le système sera
implémenté puis présente l’implémentation de la solution proposée et le bilan du travail
effectué.
UNIVERSITE AUBE NOUVELLE 1

PROBLEMATIQUE
La gestion des rendez-vous est un élément incontournable pour le développement d’une

entreprise. Véritable activité chronophage, la gestion des rendez-vous implique une
disponibilité permanente du personnel pour répondre le plus rapidement possible aux
différentes préoccupations des clients et ou des partenaires. Cependant, même étant
parfaitement organisées, certaines entreprises font face à des difficultés pour gérer leurs rendez-
vous. Lesdites difficultés sont entre autres :
 Des pertes considérables de temps liée aux nombreux appels téléphoniques ;
 Une augmentation de risques des rendez-vous oubliés ou manqués ;
 Un manque de visibilité sur les disponibilités des prestataires causant des pertes de
clients et de partenaires ;
 De longues heures d’attente des clients et ou des partenaires ;
Pour remédier à ces problèmes, nous allons mettre en place une plateforme web pour la
gestion de prise de rendez-vous dans les entreprises.

CHAPITRE 1 : CONTEXE ET DEMARCHE METHODOLOGIQUE

1.1. INTRODUCTION PARTIELLE
Nous présentons premièrement dans ce chapitre notre établissement de formation ainsi

que la structure qui nous a accueillis dans le cadre du stage. Nous présentons également le projet
en faisant ressortir le problème à résoudre, les objectifs à atteindre et les résultats attendus à la fin
du projet, puis le planning prévisionnel pour la gestion de ce projet. Deuxièmement nous
identifions d’une part les exigences fonctionnelles ainsi que les exigences techniques du futur
système, et d’autre part nous présentons la méthode de résolution que nous utilisons dans le
cadre de notre projet en faisant ressortir également le langage de modélisation et les outils
choisis pour l’étude. Nous faisons ressortir troisièmement les ressources (matérielles, logicielles,
humaines) dont dispose l’entreprise Nos3S pour nous accompagner dans le travail.
1.2. PRESENTATION DU CONTEXTE DU STAGE

1.2.1. Présentation de l’université Aube Nouvelle
1.2.1.1. Présentation générale
L’Institut Supérieur d’Informatique et de Gestion (ISIG) est un établissement privé

d’enseignement supérieur. Il a été créé en Octobre 1992, agréé par l’Etat par arrêté N°2005-
244/ MESSRS/CAB du 02 Décembre 2005 ; par arrêté 2010-355/ MESSRS/ETFP/CAP du 11
Octobre 2010 portant modification des statuts de l’ISIG-INTERNATIONAL ; arrêté 2010-
356/MESSRS/ETFP/CAP du 11 Octobre 2010 portant autorisation d’ouverture de cycles de
filières d’études et de délivrance de diplômes à l’ISIG-INTERNATIONAL, devenu Université
Aube Nouvelle, par autorisation N° 2012 000344/MESSRS/SG/DGESR/DIESPR du 17 Février
2012.
L’Université Aube Nouvelle est membre du CAMES (Conseil Africain et Malgache
pour l’Enseignement supérieur). Les diplômes délivrés ont les grades DTS, Licence, Master et
Doctorat. U-AUBEN a deux sites : l’un basé à Ouagadougou et l’autre à Bobo-Dioulasso. Son
siège est à Ouagadougou (Burkina Faso).
U-AUBEN est un centre officiel d’administration du TOEIC depuis 2009, à travers ETS Global
BV qui est une division d’Education Testing Service (ETS) basé à
Princeton aux Etats-Unis d’Amérique. Depuis Juillet 2013, à travers un partenariat entre

l’Ambassade des Etats-Unis d’Amérique au Burkina Faso et l’Université Aube Nouvelle, le

Centre Américain de Langue (ALC en anglais) a été transféré dans les locaux de l’Université
Aube Nouvelle. L’U-AUBEN est organisée en Unités de formations et de recherches (UFR) et
en instituts.
1.2.1.2. Formation et diplôme
La formation à l’Université Aube Nouvelle se fait suivant le système LMD (Licence Master
Doctorat). La licence dure trois (03) ans. Le diplôme s’obtient après validation de six (06)
semestres dont le sixième semestre est constitué d’un stage pratique d’au moins trois (03) mois
en entreprise qui fait l’objet d’une soutenance publique. Le master s’étend sur une durée de
deux (02) ans.
Les offres de formation sont reparties en des Unités de Formation et de Recherche (UFR), des
instituts et d’une école doctorale comme suit :
1.2.1.2.1. Les unités de formation et de recherche
Nous distinguons plusieurs UFR qui sont les suivantes :
 UFR /Sciences Juridiques et Politiques

 Licence en Sciences Juridiques, Politiques et Administratives ;
 Master en Sciences Juridiques, Politiques et Administratives.
 UFR /Sciences Economiques et de Gestion
 Licence en Sciences Economiques et de Gestion ;
 Master en Sciences Economiques et de Gestion.
 UFR /Sciences et Techniques
 Licence en Eau Hygiène et Assainissement ;
 Licence en Géologie Appliquée et Mines ;
 Licence professionnelle en Bio-analyse et contrôle qualité ;
 Licence professionnelle en Industries Agro-alimentaires ;
 Licence en Agronomie.
 UFR / Langue, Lettres, Sciences Humaines et Sociales
 Licence en Langues, Traduction et Interprétariat.

1.2.1.2.2. Les unités
Nous distinguons plusieurs instituts qui sont les suivants :
 Institut des Métiers de la Communication, du Journalisme, de l’Audiovisuel et du

Cinéma (IMCJAC) ;
 Licence en Sciences et Technologies.
 Institut Supérieur d’Informatique et de Gestion
 Business School ;
 High Tech ;
 Des Masters spécialisés
 Management de l’environnement et de développement durable ;
 Micro finance (en collaboration avec l’université Senghor d’Alexandrie) ;
 Management et administration des entreprises ;
 Gestion durable des ressources minérales ;
 Management des reformes, de développement institutionnel et de
renforcement organisationnel.
 Des Masters de recherche
 Domaine en Sciences et Technologies
 Imagerie Numérique pour le Développement Durable (INDD) ;

 Génie Informatique
 Domaine en Sciences de Gestion
 Développement des Projets à l’International ;

 Innovation et Intelligence Economique ;
 Management International ;
 Gestion de la Valeur et Modélisation des coûts ;
 Management de l’Environnement ;
 Management des Ressources Humaines ;
 Marketing ;
 Comptabilité Contrôle Audit.
1.2.1.2.3. L’école doctorale
U-AUBEN à de nos jours une école doctorale deux domaines :

 Sciences de Gestion ;
 Sciences et Technologies.
1.2.2. Présentation de la structure de Nos3S

1.2.2.1. Historique et situation géographique
Nos Solutions, Systèmes et Services (Nos3S) est une entreprise d’ingénierie créée en
décembre 2013. C’est une Société à Responsabilité Limitée (SARL) fondée par un groupe de
techniciens et d’ingénieurs en informatique. C’est une entreprise burkinabè située au secteur 09
de la ville de Bobo-Dioulasso principalement basée dans le même immeuble que la Badf (Banque
Agricole du Faso).
1.2.2.2. Objectifs et missions
Nos3S est une entreprise spécialisée dans plusieurs domaines d’activités informatiques.
Comme l’indique son nom elle apporte des solutions, des systèmes et des services aux problèmes
informatiques. Les principales prestations de Nos3S sont les suivantes :
 Analyse diagnostique et conception de système d’information ;
 Développement de logiciels ;
 Maintenances, réseaux et systèmes informatiques ;
 Assistance technique ;
 Audits, conseils et formations.
Depuis sa création, Nos3S n’a cessé d’affirmer sa présence sur la place nationale et travers
ses produits et ses services et de contribuer ainsi au renforcement de la compétitivité des
entreprises burkinabè.
1.2.2.3. Les différentes réalisations
Nos Solution, Système et Services (Nos3S) a mis en place plusieurs produits et réalisations
qui améliorent le quotidien des différents utilisateurs. Parmi ces différentes réalisations nous
pouvons citer :
 LigdiCash qui est un portefeuille électronique ;
 LafiDoc qui est une plateforme d’assistance en santé humaine ;
 Sysgesco qui est un logiciel de gestion des établissements scolaires ;
 Logoba qui est une plateforme de e-commerce développée avec le concours d’une autre
entreprise qui est NafaVision ;

 SIH LAFIBORD.
1.2.2.4. Organisation de Nos3S
La structure Organisationnelle de Nos3S est hiérarchisée et comprend :
 Un Conseil d’Administration (CA) ;

 Une Direction Générale (DG) ;
 Un Département des Ressources Humaines (DRH) ;
 Un Département de Comptabilité et Budget (DCB) ;
 Un Département de Commercial et Marketing (DCM) ;
 Un Département Projets et Développement (DPD) ;
 Un Département Réseaux et Maintenance (DRM).
CA
DG
DRH DCB DCM DPD DRM

Figure 1 : Organigramme de Nos3S source Nos3S
Source : « Nos3S »
1.2.3. Présentation du thème

1.2.3.1. Objectifs d’études
L’objectif principal de notre étude consiste à mettre en place une plateforme web qui
facilitera la prise et la gestion des rendez-vous en ligne dans les entreprises. Pour atteindre cet
objectif nous avons défini plusieurs objectifs spécifiques que sont :
 Permettre aux clients de prendre rendez-vous par internet 24h/24 et 7 jours sur 7 ;
 Simplifier le travail des agents en leur permettant de passer moins de temps à l’appel
téléphonique ;
 Consulter le calendrier des entreprises en ligne pour connaitre les disponibilités d’un

agent ;
 Répondre aux nouvelles exigences de disponibilités en permettant à nos clients de
demander le créneau horaire en ligne souhaité pour prendre rendez-vous ;
 Permettre à nos clients de gagner en temps et en efficacité ;
 Envoyer des rappels à nos clients par e-mail ou SMS, ceci afin de réduire le taux de
rendez-vous manqués ou annulés.
1.2.3.2. Résultats attendus
Au regard des objectifs définis ci-dessus, il est attendu comme résultat une plateforme
permettant, de créer des espaces virtuels de prise et de gestion de rendez-vous. Pour cela la
plateforme devra disposer des fonctionnalités suivantes :
 La gestion des entreprises ;

 La gestion des comptes ;
 La gestion des emplois du temps ;
 La gestion des rendez-vous ;
 La gestion des abonnements ;
 La gestion du personnel.
1.2.3.4. Gestion du projet

1.2.3.4.1. Délimitation de l’analyse du domaine
La délimitation d’un projet consiste à mettre en évidence les différentes parties

intégrantes du système par l’étude du projet. Elle est très capitale pour le projet dans le sens où
une mauvaise définition peut conduire à un système ne répondant pas aux besoins des utilisateurs
et à des pertes en ressources qui auraient pu être évitées. Pour ce projet, nous allons nous focaliser
sur la gestion de prise de rendez-vous dans les entreprises.
1.2.3.4.2. Acteurs du projet
Un acteur du projet est toute personne qui intervient dans la réalisation du projet. Ces
derniers sont primordiaux pour la mise en place du projet. Nous pouvons les repartir en trois
(03) groupes : le groupe de pilotage, le groupe du projet et le groupe des utilisateurs.
 Le groupe de pilotage : c’est l’ensemble des acteurs chargés d’assurer le bon
déroulement du projet. Ils ont pour rôle d’arbitrer, de contrôler, de valider les choix et

les moyens à mettre en place pour la réalisation du projet. Ce groupe est constitué de :
 M. TRAORE Souleymane, ingénieur analyste-programmeur en

informatique, notre maître de stage ;
 M. TRAORE Tiémogo, Ingénieur de conception en système d’information.
 Le groupe du projet : il est constitué des acteurs chargés d’effectuer l’analyse, la
conception et la réalisation du projet. Le travail du groupe du projet est validé par le
groupe de pilotage et celui des utilisateurs. Il est constitué de :
 M. BARRY Inoussa, étudiant en licence informatique option technologie du

génie informatique à U-AUBEN.
 Le groupe des utilisateurs : le groupe des utilisateurs est l’ensemble des utilisateurs
finaux du futur système à concevoir. Il est chargé de l’utilisation de la solution et de faire
des propositions d’amélioration. Ce groupe concerne les propriétaires d’entreprise et les
clients.
1.2.3.4.3. Planning prévisionnel
L’exécution d’un projet suit un planning bien établi avant son lancement. Ce planning tient
compte des difficultés liées aux problèmes, des contraintes de travail de la structure d’accueil
mais aussi de l’urgence du projet et du délai octroyé au groupe de projet. Il permet également
aux différents acteurs du projet de suivre l’évolution du projet à chaque instant afin de se
conformer au cahier des charges.
Figure 2 : Planning prévisionnel
1.3. DEMARCHE ET MOYEN DE RESOLUTION

Un projet est une étude de conception d’un but que l’on souhaite réaliser dans l’optique
de résoudre un problème. Ainsi, le choix de la démarche et des moyens de résolution est d’une
importance capitale. En effet, l’ampleur d’un projet dépend des contraintes techniques,
fonctionnelles et aussi du problème dont il traite. Dans cette partie, notre travail sera divisé en
deux (02) volets. En premier lieu, nous allons mettre en exergue les exigences techniques et
fonctionnelles. En second lieu, nous allons définir la méthode de résolution pour laquelle nous
avons optée.
1.3.1. Les exigences fonctionnelles et techniques
Les exigences décrivent le comportement et les fonctions du futur système ainsi que les
critères spécifiques qui peuvent être utilisés pour juger son exploitation, par exemple la
performance, la sécurité et la disponibilité.
1.3.1.1. Les exigences fonctionnelles
Les exigences fonctionnelles sont un groupe d’ensemble de possibilités et de fonctions que

renferme un système. Elles doivent pouvoir répondre aux besoins des utilisateurs mais aussi
contribuer à l’amélioration du quotidien des utilisateurs. Comme exigences fonctionnelles, que
nous avons regroupées sous forme de modules, nous pouvons citer :
 Le module de gestion des entreprises ;
 Le module de gestion des comptes ;
 Le module de gestion des emplois du temps ;
 Le module de gestion des rendez-vous ;
 Le module de gestion des abonnements ;
 Le module de gestion du personnel.
1.3.1.2. Les exigences techniques
Les exigences techniques sont des contraintes internes et externes au fonctionnement du

système. Aussi, l’usage de l’application doit être simple et l’interface graphique attractif.
Comme exigences techniques, nous avons :
 La sécurité des données : les données personnelles ne doivent pas être divulguées et
l’accès doit être restreint ;
 L’évolutivité : l’application doit pouvoir évoluer et s’adapter au changement ;
 L’adaptabilité sur tous les types d’écrans : l’affichage de l’application doit être adapté
en fonction des terminaux.

1.3.2. Méthodes de résolution du problème
Un modèle est une représentation partielle de la réalité, abstraction de ce qui est

intéressant pour un contexte donné. La modélisation consiste à concevoir des modèles qui vont
servir de directive dans la résolution d’un problème en passant par un certain nombre d’étapes.
On commence par étudier le projet tout en ayant une vision globale de la situation. Le projet
peut être une mise à jour d’une solution existante ou la mise en place d’un nouveau système.
Ensuite, vient l’étude de la faisabilité et des contraintes (fonctionnelles, techniques et
financières). Dans l’optique de répondre aux besoins des utilisateurs, un choix du langage de
modélisation s’impose.
1.3.2.1. Choix de langage de modélisation
Un langage de modélisation est un langage graphique pour représenter et communiquer

les divers aspects d’un système d’information. Il possède un vocabulaire et des règles qui
permettent de combiner les mots afin de communiquer.
De nos jours, il existe plusieurs langages de modélisation et chacun d’eux a des avantages et
des inconvénients. Comme exemples, il y a :
 SYSML ;
 IDEF ;
 UML.
Face à tous ces langages de modélisation, un choix judicieux s’impose et répondant à nos
attentes. Pour cela, nous avons décidé d’utiliser UML.
1.3.2.1.1. Justification du choix d’UML
UML nous est familier et possède de nombreux atouts. Plusieurs raisons peuvent justifier
notre choix d’utiliser UML comme langage de modélisation. Nous pouvons évoquer par
exemple :
 Son cadre d’analyse objet en offrant différentes vues ou perspectives complémentaires
d’un système ;
 Son contrôle de la complexité dans l’expression des besoins ;
 Son support de communication car il est universel et sa notation graphique exprime
visuellement les solutions objets ;
 Son indépendance face au langage de programmation choisi.

1.3.2.1.2. Présentation d’UML

UML signifie « Unified Modeling Langage » ou Langage de Modélisation unifié en

français. C’est un langage de modélisation qui permet de représenter graphiquement les besoins
des utilisateurs. Il a été conçu en 1994 par la fusion de trois (03) langages de modélisation qui
sont les suivants :
 Le langage OMT de James Rumbaugh qui prône la représentation graphique des aspects
statiques, dynamiques et fonctionnels d’un système ;
 Le langage OOD de Grady Booch pour le concept de package ;
 Le langage OOSE de Ivar Jacobson qui est basé sur la description des besoins de
l’utilisateur.
UML est la référence actuelle fondée sur le modèle orienté objet et il est employé dans
l’ensemble des secteurs du développement informatique. En 1997, il a été défini comme norme
standard de la modélisation des systèmes d’informations objet par l’OMG (Object Management
Group).
1.3.2.1.3. Les diagrammes
Un diagramme est une représentation graphique d’un modèle. Il fournit une perspective du
modèle considéré. UML propose plusieurs diagrammes qui représentent une solution pour un
problème donné selon différents points de vue. Ces diagrammes sont regroupés en trois (03)
groupes appelés modèles. Un modèle est une représentation schématique d’un processus ou
d’une démarche raisonnée. Comme modèles, nous avons :
 Le modèle statique ou structurel
Le modèle statique indique comment le système « EST ». Il est constitué de six (06)
diagrammes que sont :
 Le diagramme de classe : c’est le diagramme pivot de l’ensemble de la
modélisation d’un système. Il représente la description statique du système
en intégrant dans chaque classe la partie dédiée aux données et celle consacrée
au traitement ;
 Le diagramme d’objets : ce diagramme fait état des instances (objets)
identifiés dans le système ;
 Le diagramme de composants : ce diagramme décrit les instances de
composants (les objets) recensés dans le système ;
 Le diagramme de déploiement : ce diagramme décrit l’architecture
technique d’un système avec une vue centrée sur la répartition des composants

dans la configuration d’exploitation ;

 Le diagramme de package : ce diagramme donne une vue d’ensemble du
système structuré en paquetage. Chaque paquetage représente un ensemble
homogène d’éléments du système ;
 Le diagramme de structures composites : ce diagramme décrit les relations
entre les composants d’une classe.
 Le modèle fonctionnel ou comportemental
Le modèle fonctionnel indique ce que le système « FAIT ». Il est constitué de trois (03)
diagrammes que sont :
 Le diagramme de cas d’utilisation : ce diagramme est destiné à représenter
les besoins des utilisateurs par rapport au système. Il constitue un des
diagrammes les plus structurants dans l’analyse d’un système ;
 Le diagramme d’états-transitions : ce diagramme montre les différents états
des objets en réaction aux événements ;
 Le diagramme d’activités : ce diagramme donne une appréciation du
comportement du système sous forme de flux ou d’enchaînement.
 Le modèle dynamique ou d’interaction
Le modèle dynamique indique « COMMENT » le système évolue. Il est constitué de quatre

(04) diagrammes que sont :
 Le diagramme de séquence : ce diagramme permet de décrire les scénarios
de chaque cas d’utilisation en mettant l’accent sur la chronologie des
opérations en interaction avec les objets ;
 Le diagramme de communication : ce diagramme fait une représentation
simplifiée d’un diagramme de séquence en se focalisant sur les échanges de
messages entre les objets ;
 Le diagramme global d’interaction : ce diagramme précise la façon dont
les groupes d’objets collaborent pour réaliser un comportement donné ;
 Le diagramme de temps : ce diagramme décrit les interactions des différents
objets en précisant la chronologie d’exécution des opérations.
Pour l’analyse de notre projet, nous avons utilisé les diagrammes suivants :
 Le diagramme de classe ;
 Le diagramme de déploiement ;
 Le diagramme de cas d’utilisation ;

 Le diagramme d’état transition ;

 Le diagramme de séquence.
1.3.2.1.4. Outils de modélisation
De nos jours, il existe plusieurs outils de modélisation qui semblent tous offrir les mêmes
services, rendant ainsi difficile le choix de l’un d’entre eux. Nous pouvons citer :
 ArgoUML ;
 PowerDesigner ;
 BoUML.
Dans le cadre de notre projet, nous avons utilisé PowerDesigner la version 16.5.0.3982 qui
est une puissante solution de modélisation des systèmes d’informations, proposée par la société
Sybase. Cet ensemble d’outils supporte plusieurs techniques de modélisations standard :
modélisation Merise et modélisation UML. PowerDesigner offre un environnement graphique
très intuitif et très facile à aborder. Il permet aussi la génération de modèles et de codes. Il est
utilisé dans notre projet pour la représentation des diagrammes de cas d’utilisation, de
séquences, d’états transition, de classes, et de déploiement.
1.3.2.2. Processus de développement
UML permet de faire la représentation des modèles mais il ne définit pas de processus
d’élaboration des modèles. Cependant dans l’optique de mettre en place une application qui
répond parfaitement aux besoins des utilisateurs, nous devons suivre une démarche qui est :
 Guidée par les besoins des futurs utilisateurs du système ;
 Centrée sur l’architecture logicielle ;
 Evolutive et facile de maintenance.
Il existe plusieurs processus de développement qui répondent à ces critères. Dans notre cas,
nous allons travailler avec le processus 2TUP.
2TUP (Two Tracks Unified Process) est un processus de développement logiciel et qui
implémente le Processus Unifié (UP) dans le but d’apporter une réponse aux contraintes de
changement fonctionnelles et techniques qui s’imposent aux systèmes d’information. Ce
processus est :
 Interactif et incrémental : le projet est découpé en des itérations de courtes durées. Ces
itérations aident à mieux suivre l’avancement du système global. A chaque itération, il
est produit un exécutable de façon incrémentale ;

 Piloté par les risques : tout risque pouvant conduire à un échec du projet est identifié et
écarté au plus tôt ;
 Centré sur l’architecture : le système est décomposé en modules pour des besoins de
maintenabilité et d’évolutivité ;
 Conduit par les cas d’utilisation : le processus met en avant les besoins et exigences
des futurs utilisateurs du système.
Il propose un cycle de développement en Y dissociant les aspects techniques des aspects
fonctionnels en commençant par une étude préliminaire. Cette étude consiste à identifier les
acteurs qui interagissent avec le système, construire les messages échangés entre les acteurs et
le système, produire le cahier de charges et modéliser le contexte. Le processus s'articule ensuite
autour de trois phases essentielles :
 Une branche technique qui capitalise un savoir-faire technique et/ou des contraintes
techniques. Les techniques développées pour le système sont indépendantes des
fonctions à réaliser ;
 Une branche fonctionnelle qui capitalise la connaissance du métier de l’entreprise. Cette
branche capture des besoins fonctionnels, ce qui produit un modèle focalisé sur le métier
des utilisateurs finaux ;
 Une branche de conception et de réalisation qui consiste à réunir les deux branches,
permettant de mener une conception applicative et enfin la livraison d'une solution
adaptée aux besoins.
Figure 3 : Présentation 2TUP
Source : « Cours d’UML »

1.4. DOMAINE D’ETUDE

1.4.1. Etude de l’existant
La réalisation d’un projet suit une suite logique d’étapes qui doivent être en adéquation.
C’est dans cette optique que nous allons effectuer dans cette partie une étude sur l’existant.
Nous présenterons également les ressources qui sont mises à notre disposition pour la
réalisation du projet.
1.4.1.1. Présentation de l’existant
1.4.1.1.1. Définition
A l’heure du développement de l’économie numérique, le Burkina Faso ne manque pas

au rendez-vous. Certes, ce n’est pas encore le même niveau que dans les pays reconnus comme
référence en matière du numérique, mais les initiatives existent. En ce sens, il existe déjà de
nombreux sites de prise de rendez-vous comme Laafi-Express qui permet d'organiser les prises
de rendez-vous sanitaires et permet aux cliniques et centres de santé du Burkina d’avoir un
cadre plus apte pour la gestion de leur personnel médical et leur planning. Cette plateforme vise
à rendre le système de santé burkinabè plus efficace, accessible et humain. A l’international il
existe aussi des plateformes qui s’engagent dans la prise de rendez-vous en ligne. C’est le cas
de madate qui est une plateforme française et Reservio qui est quant à lui tchèque. Ces
plateformes sont accessibles sur les adresses : https//www.laafi-express.com ;
https//www.madate.fr ; https//www.app.reservio.com.
1.4.1.1.2. Analyse critique de l’existant
Madate et Reservio sont des systèmes de réservation en ligne gratuit mais force est de
constater qu’ils présentent des insuffisances. Après une analyse minutieuse, nous avons
identifié quelques-unes de leurs forces et faiblesses résumées dans le tableau ci-dessous :
Tableau 1 : Analyse critique de l’existant
Critères RDVonline Madate Reservio

Fonctionnalités pour l’ajout d’une OUI OUI OUI
entreprise
La gestion des personnels OUI OUI NON
La gestion des emplois de temps OUI OUI OUI
La gestion des rendez-vous OUI OUI OUI

Fonctionnalité pour le paiement en OUI NON NON

ligne par Orange Money, par Moov
Money et/ou par portefeuilles
électroniques.
Intégration avec d’autres outils OUI OUI OUI
Rendez-vous en visioconférence OUI OUI NON
Disponibilité en temps réel OUI OUI OUI
1.4.2. Présentation des ressources disponibles
Pour la mise en place de notre solution, plusieurs ressources ont été mises à notre
disposition.
Comme ressources, nous pouvons citer :
 Une salle de travail équipée de mobiliers de bureau ;
 Un réseau wifi pour accéder à internet ;
 Une salle de réunion afin de recevoir d’éventuelles remarques et suggestions.
1.5. CONCLUSION PARTIELLE
Dans ce chapitre, nous avons d’abord présenté le contexte du stage en présentant U-

AUBEN, notre établissement de formation et l'entreprise Nos3S qui est la structure qui nous a
accueillis dans le cadre de notre stage. Nous avons également présenté le projet en faisant
ressortir le problème, les objectifs à atteindre, et les résultats attendus à la fin de notre étude.
Ensuite nous avons fait ressortir les exigences fonctionnelles et techniques du futur système
avant de présenter la méthode de résolution des projets informatiques 2TUP que nous utilisons
dans le cadre de notre étude ainsi que le langage de modélisation UML. Enfin nous avons vu les
ressources humaines, matérielles et logicielles dont dispose l'entreprise Nos3S pour la bonne
marche de ses activités. Le prochain chapitre va nous permettre d’effectuer les analyses
fonctionnelles et techniques du futur système.

CHAPITRE 2 : ANALYSE FONCTIONNELLE ET TECHNIQUE DU

FUTUR SYSTEME
Dans ce chapitre, nous abordons d’une part la spécification du futur système qui permet
d’expliciter les besoins recueillis auprès des utilisateurs. Pour ce faire, nous identifions les
différents acteurs du futur système ainsi que leurs cas d’utilisation avant de modéliser les
diagrammes de cas d’utilisation et de séquences systèmes. D’autre part nous effectuons une
analyse architecturale, nous permettant ainsi de traiter les besoins non fonctionnels exprimés
par les utilisateurs en se servant des besoins fonctionnels. L’objectif est d’harmoniser le produit
avec les objectifs métiers en définissant l’architecture que nous suivrons lors de
l’implémentation et la phase de déploiement du futur système. Pour effectuer cette analyse nous
identifions dans un premier lieu les composantes logicielles nécessaires à la réalisation. Nous
présentons ensuite dans une deuxième partie l’architecture logicielle du système.
2.2. SPECIFICATION DU FUTUR SYSTEME

2.2.1. Identification des acteurs et des cas d’utilisation
2.2.1.1. Identification des acteurs
Un acteur définit un ensemble cohérent de rôle qu’un utilisateur ou une entité externe peut
jouer en interagissant avec le système. Un acteur peut consulter et/ou modifier directement l’état
du système en émettant et/ou en recevant des messages susceptibles d’être porteurs de données.
Dans le cas de notre projet, nous avons recensé six (6) acteurs qui vont intervenir sur le système.
Tableau 2 : Les acteurs et leurs rôles
Acteurs Rôles
Visiteur Principal
Client Principal
Propriétaire d’entreprise Principal
Administrateur Secondaire
API paiement (LigdiCash) Système connexe
API SMS (Lesmsbus) Système connexe

2.2.1.2. Identification des acteurs et des cas d’utilisation
Le tableau suivant est une représentation des acteurs associés à leurs cas d’utilisations.
Tableau 3 : Les acteurs et leurs cas d’utilisation
Acteurs Cas d’utilisation

Visiteur  Créer un compte
 Consulter une entreprise
Client  Récupérer son compte
 S’authentifier
 Demander un RDV
 Modifier son RDV
 Annuler son RDV
Propriétaire  S’authentifier
d’entreprise  Demander un RDV
 Modifier un RDV
 Annuler un RDV
 Ajouter une entreprise
 Accepter un RDV
 S’abonner/se réabonner
 Ajouter un personnel
 Modifier un personnel
 Ajouter un emploi de temps
 Modifier un emploi de temps
Administrateur  S’authentifier
 Activer/désactiver une entreprise
API paiement  Participe à un abonnement
ligdicash  Participe à une réservation
API SMS (lesmsbus)  Participe à la récupération d’un compte
 Participe à la prise, à la modification et à
l’annulation d’un RDV
2.2.1.3. Les cas d’utilisation
Un cas d’utilisation est une technique de description du système étudié privilégiant

le point de vue de l’utilisateur. Il permet une meilleure structuration des besoins de
l’utilisateur qui définissent clairement la manière dont ils interagissent avec le
système. Il est composé d’un ensemble d’actions déclenchées par un acteur externe et
qui produit un résultat identifiable. Ces cas d’utilisation ont été identifiés grâce aux
besoins fonctionnels recueillis au niveau des utilisateurs du futur système. Nous avons
réuni les cas d’utilisation dans le tableau suivant :

Tableau 4 : Identification des cas d’utilisation
Numéros Cas d’utilisation

CU01 Consulter une entreprise
CU02 Créer un compte
CU03 Récupérer un compte
CU04 S’authentifier
CU05 Demander un RDV
CU06 Modifier un RDV
CU07 Annuler un RDV
CU08 Ajouter une entreprise
CU09 Accepter un RDV
CU10 Faire un abonnement
CU11 Faire un réabonnement
CU12 Ajouter un personnel
CU13 Modifier un personnel
CU14 Ajouter un emploi de temps
CU15 Modifier un emploi de temps
CU16 Activer/désactiver une entreprise
2.2.1.4. Description textuelle des cas d’utilisations
Un cas d’utilisation peut être décrit graphiquement ou textuellement. Les tableaux

suivants font respectivement la description textuelle des cas d’utilisation.
Tableau 5 : Description du cas d'utilisation "créer un compte"
CU « Créer un compte »
Résumé : Ce cas d’utilisation permet aux Acteur : Client
différents utilisateurs d’ouvrir leur compte Auteur : BARRY Inoussa
sur la plateforme Précondition : Ne pas avoir
de compte
Postcondition : Compte créé
Scénario nominal
1. L’utilisateur demande à s’inscrire ;
2. Le système envoie le formulaire d’inscription ;
3. L’utilisateur renseigne ses informations puis valide ;
4. Le système vérifie les informations saisies ;
5. Le système notifie le succès de l’inscription ;
6. Fin du cas d’utilisation.
Scénario alternatif : La saisie est incomplète ou incorrecte
7. Le système affiche un message d’erreur et renvoie le formulaire à corriger ;
8. L’enchainement reprend à partir de l’étape 3 du scénario nominal.
Scénario erreur : Annulation de la création de compte
9. Le système arrête la création du compte ;

Tableau 6 : Description du cas d'utilisation "S'authentifier"
CU « S’authentifier »
Résumé : Ce cas d’utilisation permet à Acteurs :Client,propriétaire
l’utilisateur de saisir ses paramètres de d’entreprise, administrateur
connexion pour pouvoir se connecter au Auteur : BARRY Inoussa
système Précondition :
 Avoir un compte
 Être non connecté
Postcondition :Utilisateur
connecté
Scénario nominal
1. L’utilisateur demande à se connecter ;
2. Le système envoie le formulaire de connexion ;
5. Le système affiche la page d’accueil de l’utilisateur ;
Scénario alternatif 1 : Mot de passe et/ou téléphone incorrect

Scénario alternatif 2 : Mot de passe oublié

9. Le système demande à l’utilisateur de récupérer ses identifiants ;
10. Inclure le cas d’utilisation « Récupérer un compte »
Scénario erreur : La session est déjà bloquée
11. L’enchainement reprend à partir de l’étape 1 du scénario alternatif 2

Tableau 7 : Description du cas d'utilisation "Demander rendez-vous"
CU « Demander un rendez-vous »
Résumé : Ce cas d’utilisation permet à l’utilisateur de Acteurs : Client, propriétaire

demander un rendez-vous sur la plateforme d’entreprise
Auteur : BARRY Inoussa
Précondition : Être connecté
Postcondition :
• Demande enregistrée
• Le propriétaire reçoit une
notification
Scénario nominal
1. L’utilisateur demande à prendre rendez-vous ;

2. Le système affiche les personnels disponibles ;
3. L’utilisateur choisit le personnel ;
4. Le système affiche la disponibilité du personnel ;
5. Le client choisit la date et le motif du RDV et lance la réservation ;
6. Le système vérifie puis envoie un sms au client et à la personne concernée par le RDV ;
Scénario alternatif : la saisie est incorrecte
8. Le système affiche un message d’erreur et renvoie le formulaire à corriger

9. L’enchainement reprend à partir de 4 du scénario nominal
Scénario d’erreur : Annulation de la demande de RDV
10. Le système arrête le processus de la demande de RDV ;

Tableau 8 : Description du cas d'utilisation "Ajouter une entreprise"
CU « Ajouter une entreprise »

Résumé : Ce cas d’utilisation permet Acteurs :Client,propriétaire
d’ajouter une entreprise sur la plateforme d’entreprise
Auteur : BARRY Inoussa
Précondition :
• Être connecté
• Être abonné
Postcondition : Entreprise ajoutée
Scénario nominal
1. L’utilisateur demande à ajouter une entreprise ;
2. Le système envoie le formulaire d’ajout d’entreprise ;
4. Le système vérifie les informations saisies et affiche le formulaire d’abonnement ;
5. L’utilisateur choisit le forfait d’abonnement puis effectue le paiement ;
6. Le système vérifie puis envoie une notification de succès pour l’ajout de son entreprise ;

Scénario alternatif : la saisie est incomplète ou incorrecte

9. L’enchainement reprend à partir de l’étape 4 du scenario nominal.
Scénario erreur : annulation d’ajout de l’entreprise.
10. Le système arrête le processus de création de l’entreprise ;
Tableau 9 : Description du cas d'utilisation "Ajouter un personnel"
CU « Ajouter un personnel »
Résumé : Ce cas d’utilisation permet d’ajouter Acteurs : Propriétaire d’entreprise
un personnel dans une entreprise Auteur : BARRY Inoussa
Précondition :
• Être connecté
• Avoir une entreprise active
Postcondition : Personnel ajouté
Scénario nominal
1. L’utilisateur demande à ajouter un personnel ;
2. Le système envoie le formulaire de renseignement du personnel à ajouter dans
l’entreprise ;
3. L’utilisateur renseigne les informations puis valide ;
5. Le système notifie le succès d’ajout du personnel dans l’entreprise ;
Scénario alternatif : La saisie est incomplète ou incorrecte.
Scénario erreur : Annulation d’ajout du personnel dans l’entreprise
9. Le système arrête le processus d’ajout du personnel ;
Tableau 10 : Description du cas d'utilisation "Ajouter un emploi de temps"
CU « Ajouter un emploi de temps »

Résumé : Ce cas d’utilisation permet Acteurs : Propriétaire d’entreprise
d’ajouter un emploi de temps dans une Auteur : BARRY Inoussa
entreprise
Précondition :
• Être connecté
• Avoir une entreprise activée
Postcondition :
Emploi de temps ajouté
Scénario nominal
1. L’utilisateur demande à ajouter un emploi de temps
2. Le système envoie le formulaire d’ajout d’emploi de temps ;
3. L’utilisateur remplit puis valide
4. Le système notifie le succès d’ajout de l’emploi de temps

5. Fin du cas d’utilisation

Scénario alternatif : La saisie est incomplète ou incorrecte.
7. L’enchainement reprend à partir de l’étape 3 du scénario nominal ;
Scénario erreur : Annulation d’ajout d’emploi de temps
9. Le système arrête le processus d’ajout d’emploi de temps ;
2.2.2. Diagramme de cas de d’utilisation
Le diagramme des cas d’utilisation montre l’ensemble des processus du domaine d’étude.
Il représente les acteurs en relation avec le système constitué de l’ensemble des cas d’utilisation.
Il relève de l’aspect fonctionnel ou comportemental du système. Son objectif est de permettre la
visualisation des cas d’utilisation et le recensement des besoins des utilisateurs. Ces éléments
de base sont : les acteurs, les cas d’utilisation et les associations. La figure suivante représente
le diagramme des cas d’utilisation de notre projet.

Consulter
une
Visiteur entreprise
Activer ou
Créer un désactiver une
compte entreprise
Administrateur
Récupérer
son compte <<include>>
Modifier
son RDV <<include>>
Demander
<<include>>
un RDV
Annuler
son RDV
Client
<<include>>
Créer une
<<include>>
entreprise
API SMS LESMSBUS
Accepter
un RDV <<include>>
Ajouter un
emploi de
<<include>>
temps
S'authentifier
<<include>>
Propriétaire d'entreprise Modifier un
emploi de <<include>>
temps
API Ligdicash
Ajouter un
personnel
<<include>>
Modifier un
personnel
<<include>>
Faire un
abonnement/ <<include>>
Reabonnement
Figure 4 : Diagramme de cas d’utilisation
2.2.3. Diagramme de séquence
Le diagramme de séquence montre les interactions entre les objets en mettant l’accent sur
l’aspect temporel (la chronologie des envois de messages). Il permet de mieux visualiser la
séquence des messages pour une lecture du haut vers le bas. Ci- dessous se trouve la
représentation de quelques diagrammes de séquences.

S'authentifier
Plateforme Base de données
Utilisateur Demande de connexion
Affichage du formulaire
Remplir et valider
Demande des données du compte
Envoie des données du compte
Vérification des données
alt Connexion refusée
loop [Min=1; Condition=connexion refusée; Max=3]
Erreur, données incorrectes
Renvoie de formulaire
Saisir et valider
Demande des données du compte
Envoie des données du compte
Vérification des données
opt [Echec > 3]

Bloquer compte
Envoie de la reponse
Inforrmation compte bloqué
Connexion acceptée
Demande du profil
Envoie de profil
Affichage de la page d'accueil
Charger paramètres
Figure 5 : Diagramme de séquence de "S’authentifier"

Demander RDV
Système Base de données
Utilisateur
ref S'authentifier()
Demande de RDV
Affichage des personnels
Choix du personnel
Affichage de la disponibilité
ChoixDatePuisLancementReservation Vérification
alt Erreur
opt [Erreur de saisie]
Renvoie du formulaire
ChoixDatePuisLancementReservation Vérification
Enregistrement dans la BD
Envoie du message de succès Succès d'enregistrement
Saisie correcte Enregistrement dans la BD
Succès d'enregistrement
Envoie du message de succès
Figure 6 : Diagramme de séquence de "Demander RDV"

Créer compte
système Base de données
Utilisateur
demande de création de compte
Envoie de formulaire
Remplire et valider Vérification
alt Erreur de saisie

loop [Tous les champs non renseignés]
Renvoie du formulaire à corriger
Remplire et valider
Vérification
Notification de succès
Saisie correcte
Figure 7 : Diagramme de séquence de " Créer compte"

Ajouter Entreprise
Utilisateur
ref
S'authentifier()
Ajouter Entreprise
Remplir et valider Vérification
Renvoie de formulaire à corriger
Affichage du formulaire d'abonnement
Validation et paiement
Enregistrement et appel à l'API paiement
Vérification du paiement
Saisie correcte
Affichage du formulaire d'abonnement
Validation et paiement
Enregistrement et appel à l'API paiement
Vérification du paiement
Figure 8 : Diagramme de séquence de "Ajouter entreprise"

Ajouter Personnel
Utilisateur
ref
S'authentifier()
Demande d'ajout de personnel
Renvoie du formulaire
Vérification
Remplir et valider
Saisie correcte
Figure 9 : Diagramme de séquence de "Ajouter personnel"
2.3. ARCHITECTURE DU FUTUR SYSTEME
Cette partie est consacrée à la définition des objectifs à atteindre en termes de

performance, de robustesse, de maintenance. Il y sera défini l’architecture de l’application telle
quelle sera implémentée et déployée. Pour cela, nous identifierons les différents outils dans un
premier temps. Et dans un second temps, nous présenterons l’architecture logicielle du système
et ainsi que le cout de réalisation du projet.
2.3.1. Identification des outils
Bootstrap est un Framework ou une infrastructure qui permet de styliser les pages web et

de les rendre responsives. Il est constitué de HTML5, CSS3 et javascript afin d’apporter du style
aux boutons, aux formulaires, à la navigation. Bootstrap utilise un concept basé sur un système
de grille qui consiste à diviser l’écran en douze colonnes (12) distincts pour mettre en ordre
l’aspect visuel d’une page web. Il a pour devise de développer rapidement un site web en
écrivant moins de code.
 HTML 5 (HyperText Markup Langage)
HTML est un langage de balisage qui a vu le jour avec le lancement du web dans les
années 1990. Son rôle est de générer et organiser du contenu des pages web. Il nous permet
d’écrire le rendu visuel sur les pages à savoir : du texte, des liens (hyperliens), des images. Ce
langage a connu plusieurs améliorations depuis sa première version. Les différentes versions
sont les suivantes :
 HTML 1 : la première version créée par Tim Berners-Lee en 1991 ;

 HTML 2 : la deuxième version apparue en 1994 et prend fin en 1996 ;
 HTML 3 : la troisième version apparue en 1996 avec de nouvelles possibilités
à savoir les tableaux, les applets, les scripts ;
 HTML 4 : il est apparu pour la première fois en 1998 et apporte de nouvelles
fonctionnalités comme les frames, les tableaux complexes ;
 HTML 5 : c’est la dernière version actuelle et assez peu rependue. Elle
apporte de nouvelles fonctionnalités comme l’ajout des vidéos, des audio.
 CSS 3 (Cascading Style Sheet)
CSS est un langage stylisation utilisé pour rendre attirant la présentation des contenus des
pages HTML. C’est un concept présent depuis l’origine du web et nous aide à décrire
l’apparence de la plateforme à travers : la couleur et la taille des polices du texte, la taille des
titres, les positions, etc... Ce langage a connu des améliorations depuis sa création et comme
version, nous avons :

 CSS 1 qui est la première version apparue en 1996 et pose les bases de ce langage ;
 CSS 2 apparue en 1996 puis complété par CSS 2.1 avec de nouvelles possibilités
notamment dans le positionnement avec précision ;
 CSS 3 qui est la dernière version actuelle. Elle apporte de nombreuses options comme
les bordures arrondies, les dégradés, les ombres.
 PHP 7.3.1 (HyperText Preprocessor)
PHP est un langage de programmation web côté serveur c’est-à-dire que c’est le serveur qui
va interpréter le code PHP et générer du code qui pourra être interprété par un logiciel client (le
navigateur). Il a été créé par Rasmus Lerdorf en 1994. Son but est de permettre la création
d’applications dynamiques le plus souvent dédiées au web. Il peut s’installer sur les principaux
serveurs web du marché dont les plus répandus étant IIS et Apache. Ce couplage permet de
récupérer des informations issues d’une base de données, d’un système de fichiers (contenu de
fichiers et d’arborescence) ou des données envoyées par le navigateur afin d’être interprétées
ou stockées pour une utilisation ultérieure. Il est utilisé dans le traitement des données envoyées
par les formulaires et l’accès devient facile une fois les modules installés.
 JAVASCRIPT
JavaScript est un langage de script côté client (navigateur) développé par Brendan Eich de
la société Netscape Communication Corporation en 1995 avec pour nom LiveScript. Associé à
d’autres langages de programmation, il permet de développer des pages web dynamiques et
interactives. Il est à noter qu’il y a une différence entre JavaScript et Java qui est un langage de
programmation orienté objet développé par la société Sun Microsystems. Les deux (02)
langages n’ont pas le même principe de fonctionnement et le JavaScript est au cœur de la
technologie AJAX prôné par le web 2.0.
 JQUERY
JQuery, très peu connu par les utilisateurs du web, est l’une des bibliothèques du
JavaScript. Son objectif est de rendre les pages web interactives tout en réduisant le travail des
programmeurs.
 SQL
SQL, acronyme de Structured Query Langage (Langage de Requête Structure), est un

langage standard de création et d’exploitation de base de données. Il est utilisé dans presque
tous les SGBD connus dont Oracle, Microsoft SQL, MySQL.

 Apache 2.4.37
Apache http server est un serveur HTTP créé et maintenu par la fondation Apache. C’est
un logiciel open source et fonctionne aussi bien sur Linux que sur Windows.
 MySQL 5.7.24
MySQL, le plus populaire des serveurs de bases de données SQL Open Source, est
développé, distribué et supporté par MySQL AB. MySQL AB a été racheté par Microsystems
en 2008 et ce dernier sera racheté à son tour en 2009 par Oracle Corporation. Faisant partie des
SGBD les plus populaires au monde, ce serveur de bases de données relationnelles fonctionne
sur de nombreux systèmes d’exploitation (dont Linux, Mac OS X, Windows, Solaris, FreeBSD,
…) et permet de répartir la charge sur plusieurs machines, d’optimiser les performances ou
d’effectuer facilement des sauvegardes des données.
2.3.2. Architecture logicielle
L’architecture logicielle décrit d’une manière symbolique et schématique, les différents

éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions.
Cependant pour notre projet, nous avons adopté l’architecture MVC (Modèle, Vue et
Traitement) qui est une manière d’architecturer le code en la décomposant en trois (03) parties :
 Le Modèle : Il définit les données utilisées par l’application en faisant le lien entre
l’application et la base de données. Le modèle est chargé de récupérer les informations
dans la base de données, de les organiser afin qu’elles puissent être traitées par le
contrôleur.
 La Vue : Il s’agit de l’interface utilisateur, définit la manière dont les données
récupérées du modèle sont présentées à l’utilisateur. Il reçoit également les actions de
l’utilisateur permettant ainsi son interaction avec le système.
 Le Contrôleur : Cette partie gère la logique du code qui prend des décisions. C’est la
couche intermédiaire, qui met en relation le modèle et la vue. En effet, le contrôleur est
chargé de récupérer les informations au niveau du modèle, de les traiter en fonction des
paramètres demandés par la vue, puis de renvoyer à la vue.

Figure 10 : Illustration du modèle MVC
Source : « webcky.fr »

2.3.3. Estimation du coût
L’estimation du coût est une étude sur le coût de réalisation d’une application. Elle est
très importante car elle permet d’avoir le budget total de réalisation d’un projet afin d’éviter les
retards de livraison des livrables et les dérives budgétaires. Elle prend en compte le coût de
développement, de formation des utilisateurs, d’achat de matériel et des logiciels. Dans notre
cas, nous avons choisi de travailler avec la méthode COCOMO (COnstructive COst MOdel).
Cette méthode permet d’estimer le coût de développement d’un logiciel à partir du type de
projet, la taille de l’application (nombre de lignes de code à écrire) et du salaire moyen d’un
informaticien. Selon cette méthode, il existe trois (03) types de projet :
 Les projets organiques : leurs réalisations sont assurées par une équipe de petite
taille ;
 Les projets médians : ce sont des projets dont la complexité est moindre et qui
sont pilotés par une équipe dont les membres se connaissent. Les technologies
utilisées peuvent être nouvelles mais pas difficiles à appréhender ;
 Les projets imbriqués : le niveau d’innovation est important, l’organisation est
complexe, couplage fort avec beaucoup d’interactions. Le tableau suivant donne
les formules de calcul des coûts avec COCOMO.
Tableau 11 : Formules de calcul des coûts proposées par COCOMO
Type de projet Effort (Homme en mois) Temps de développement

(TDev en mois)
Organique MM= 2,4*(KLOC)*1,05 TDev = 2,5*(MM)0,38
Médian MM=3*(KLOC)* 1,12 TDev = 2,5*(MM)0,35
Imbriqué MM=3,6*(KLOC)*1,20 TDev = 2.5*(MM)0,32
 MM signifie Man-Month pour désigner la quantité homme-mois ;

 KLOC signifie Kilo Line Of Code pour désigner le nombre de millier de ligne de code
source de l’application ;
 TDev signifie Temps de Développement.
L’analyse du présent projet le place dans la catégorie Organique de COCOMO. Le nombre
de ligne de code est estimé à 3000 et le coût de développement est résumé dans le tableau
suivant :

Tableau 12 : Coût du développement
Intitulé Formule Valeur

HM 2,4*(3) 1,05 7,6 Homme-mois
TDev 2,5∗ (7.6)0,38 5.40~6 mois
Nombre de personnes Effort/TDev : 7,6/5,40 1,40~1 personne
nécessaires
Coût du financement Effort*Salaire moyen : 2.280.000 FCFA
7,6*300 000
Tableau 13 : Coût total de mise en œuvre
Désignation Détail Prix Total (en FCFA)
Serveur GoGeek Cout du serveur pour 77000/an

l’hébergement de notre plateforme
Coût de Cout total de développement de 2.280.000 FCFA

développement l’application
Coût de réalisation du Cout total de réalisation du projet 2 357 000 FCFA

projet
Ce chapitre nous a permis dans un premier temps de mieux spécifier les besoins recueillis
auprès du groupe utilisateur. Cette spécification s’est faite en identifiant dans un premier lieu
les acteurs et les cas d’utilisations du système RDVonline. Ensuite, nous avons effectué une
description textuelle de quelques cas d’utilisation avant de dresser le diagramme de cas
d’utilisation ainsi que les diagrammes de séquence système. Nous avons dans un deuxième
temps effectué l’analyse architecturale de notre système. Nous avons d’abord déterminé les
composantes logicielles qui vont intervenir dans la phase d’implémentation, ce sont entre autres
les librairies, les langages de programmation etc. Nous avons par la suite présenté l’architecture
MVC que nous utilisons comme architecture de base de notre système. Dans le prochain
chapitre, nous allons indiquer comment le système sera implémenté et réalisé.

CHAPITRE 3 : CONCEPTION ET REALISATION DE LA

SOLUTION
La conception de la solution permet de définir comment le système sera implémenté. Elle

permet d’identifier tous les éléments de conception nécessaire à la réalisation de la solution. Il
s’agit dans un premier lieu de délimiter et analyser notre domaine d’étude afin d’en avoir une
meilleure compréhension. Cette analyse passe par l’identification des concepts, la construction
des dictionnaires de données de certains de ces concepts. Par la suite nous allons dresser le
diagramme de classes d’application du système. Pour finir, nous allons dresser le schéma
logique et physique des données. Nous présentons dans un deuxième lieu l’implémentation de
la solution et le bilan du projet. Il s’agit de présenter les modules de la solution qui ont été
développés et présenter l’enchainement de quelques écrans de la solution. Nous faisons ensuite
une analyse des écarts pour en connaître les causes avant de présenter la politique de sécurité de
la solution proposée.
3.2. CONCEPTION DE LA SOLUTION

3.2.1. Délimitation et analyse du domaine
La délimitation et l’analyse du domaine consiste à bien définir les périmètres du projet.

Pour effectuer cette délimitation nous identifions d’abord les concepts clés de notre domaine
d’étude avant d’établir le dictionnaire de données de certains concepts. Nous dressons
également le diagramme de classe de domaine et le diagramme d’états transition des classes les
plus représentatives du diagramme de classe.
3.2.1.1. Identification des règles de gestion
Les règles de gestion sont les règles qui permettent d’exprimer la manière dont les classes
seront associées mais aussi ce qui est interdit dans le fonctionnement du système. Elles sont
traduites par les associations et les cardinalités et sont représentées dans le tableau suivant :

Tableau 14 : Règles de gestion du domaine d’étude
N° Règles de Gestion
1. Un utilisateur a un profil (Client, propriétaire d’entreprise, administrateur)
2. Un pays contient des villes
3. Dans une ville on a plusieurs entreprises
4. Un rendez-vous concerne un seul personnel
5. Un utilisateur peut ajouter au plus une entreprise
6. Une entreprise contient plusieurs personnels
7. Un utilisateur peut prendre plusieurs RDV
8. Un propriétaire d’entreprise peut accepter plusieurs RDV
9. Un personnel a au plus un emploi de temps
10. Un abonnement concerne une seule entreprise
11. Un propriétaire d’entreprise peut ajouter un personnel
3.2.1.2. Identification des concepts clés du domaine
Les concepts clés désignent les classes pertinentes pour les objets du domaine de notre
application. Comme classes pertinentes nous avons identifié :
 Utilisateur
 Entreprise
 Rendez-vous
 Emploi de temps
 Personnel
3.2.1.3. Dictionnaire de données
Un dictionnaire des données est une collection de données de référence nécessaire à la

conception d'une base de données relationnelle. Il revêt une importance stratégique particulière,
car il est le vocabulaire commun de notre domaine d’étude. Nous avons identifié le dictionnaire
de données de chacun de nos concepts et les avons réunis dans les tableaux respectifs suivants :

Tableau 15 : Dictionnaire de données de la classe utilisateur
Utilisateur
Attribut Description Type Taille
IdUtilisateur Code attribué à chaque Int 11
utilisateur de façon à
identifier chaque utilisateur
de manière unique.
idtypeUtilisateur Code attribué à chaque Int 11
utilisateur afin de connaitre
leurs rôles (Client,
Propriétaire d’entreprise ou
secrétaire).
NomUtilisateur Désigne le nom String 70
d’utilisateur.
PrenomUtilisateur Désigne le prénom de String 70
l’utilisateur
Téléphone Désigne le numéro de Int 20
téléphone de l’utilisateur
Email Désigne l’adresse mail de String 70
l’utilisateur.
Mot de passe Désigne le mot de passe de String 20
l’utilisateur.
Tableau 16 : Dictionnaire de données de la classe entreprise
Entreprise
idEntreprise Identifiant de l’entreprise Int 11
Nom Désigne le nom de l’entreprise String 70
Contact Désigne le contact de l’entreprise Int 20
Email Désigne le mail de l’entreprise String 70
Logo Désigne le logo de l’entreprise String 20
Etat Désigne l’état de l’entreprise Boolean 20

Tableau 17 : Dictionnaire de données de la classe personnel
Personnel
idPersonnel Code attribué à chaque personnel de façon Int 11
à l’identifier de manière unique
Poste Désigne le poste du personnel String 70
Etat Désigne l’état du personnel dans Boolean
l’entreprise
Nom Désigne le nom du personnel String 70
Prénom Désigne le prénom du personnel String 70
Tableau 18 : Dictionnaire de données de la classe emploi de temps
Emploi de temps
IdEmploitemps Identifiant de l’emploi de temps Int 70
Libelle Désigne le libellé de l’emploi de temps String 70
Horaire Désigne l’horaire de l’emploi de temps Date 20
Tableau 19 : Dictionnaire de données de la classe Rendez-vous
Rendez-vous
idRdv Désigne l’identifiant du rendez-vous Int 11
Objet Désigne l’objet du Rendez-vous String 20
Date Désigne la date du rendez-vous Date 20
Etat Désigne l’état du rendez-vous Boolean 20
3.2.1.4. Diagramme de classe du domaine
Le diagramme de classe permet de faire une représentation visuelle des classes

conceptuelles de notre domaine d’étude. Il permet aussi de faire une représentation des
différentes relations entre elles. Il est présenté dans la figure ci-dessous :

Pays
- idPays : int
- nomPays : String
- codePays : int
1..1
1..*
utilisateur
Ville - idUtilisateur : int typeUtilisateur
- nom : String
- idVille : int - idTypeUtilisateur : int
- prenom : String 0..*
- nomVille : String - tel : int 1..1 - libelle : String
- email : String
- password : String
+ Créer_compte () : void
1..1
0..* + Modifier () : void 0..1
+ Bloquer () : void
entreprise
- idEntreprise : int 1..1
- nom : String
- contact : int
- email : String 0..1
- logo : String
- etat : Boolean
+ Ajouter () : void 0..*
+ Modifier () : void
+ Désactiver () : void rendezVous
Personnel - idRdv : int
- objet : String
1..1 1..1 - idPersonnel : int - date : Date
0..* - poste : String - etat : Boolean
- etat : boolean
1..1 + Demander () : void
- nom : String
0..* + Accepter () : void
- prenom : String
+ Refuser () : void
+ Ajouter () : void
0..* + Modifier () : void
+ Desactiver () : void
Abonnement
1..1
- id_abonnement : int
- libelle : String
- duree : int
0..1
emploiTemps
- idEmploiTemps : int
- libelle : String
- horaire : Date
+ Ajouter () : void
+ Modifier () : void
+ Supprimer () : void
Figure 11 : Diagramme de classe

3.2.1.5. Diagramme d’états-transitions
Le diagramme d’états-transition est la représentation du cycle de vie des instances d’une

classe. Il permet de décrire leur réaction aux évènements reçus des autres objets. Dans notre
cas, on a identifié les classes agence, réservation et la classe commande respectivement
représentées dans les figures suivantes :
[Enregistrement de la demande]
Rendez-vous en cours Rendez-vous enregistré
[Rendez-vous en attente de validation]
Rendez-vous annulé
Rendez-vous validé
Rendez-vous terminé
[Durée] Rendez-vous en traitement
Figure 12 : Diagramme d’état transition de la classe rendez-vous
Entreprise créée [En attente d'abonnement] Entreprise abonnée
[En attente d'activation]

[En attente d'abonnement]
Entreprise activée
Entreprise désactivée
[Validation du formulaire de création]
[Fin d'abonnement]
Entreprise visible
Figure 13 : Diagramme d’état transition de la classe entreprise

3.2.1.6. Diagramme de déploiement
Le diagramme de déploiement UML montre l'architecture d'exécution des systèmes qui

représentent l'affectation (déploiement) des artefacts logiciels à des cibles de déploiement. Il est
utilisé pour visualiser la topologie des composants physiques d'un système dans lequel les
composants logiciels sont déployés. Ainsi, pour le déploiement de notre système, nous avons
identifié les composants suivants : un réseau (réseau local ou réseau Internet), un serveur de base
de données (MySQL), un serveur de fichiers (SFTP), un serveur d’application (WampServer) et
un dispositif de sécurité (Firewall). La figure suivante fait une représentation graphique du
déploiement :
Figure 14 : Diagramme de déploiement
Source : « lucidchart.com »

3.2.2. Schéma logique et physique des données

3.2.2.1. Schéma logique des données
Le schéma logique de données est l’intermédiaire entre le modèle entité-association et

le modèle physique de données. Il est constitué essentiellement des tables relationnelles,
constituées d’attributs, parmi lesquels :
 Une clé primaire (identifie de manière unique chaque occurrence de la table) ;

 Eventuellement une ou plusieurs clés étrangères (clés primaires
dans une autre table).
Il est représenté dans la figure suivante :

utilisateur
Pays
idUtilisateur Integer
idPays Integer idEntreprise Integer
nomPays Variable characters (254) idTypeUtilisateur Integer
codePays Integer nom Variable characters (254)
Identifier_1 <pi> prenom Variable characters (254)
tel Integer
email Variable characters (254)
password Variable characters (254)
Identifier_1 <pi>
Ville
idPays Integer
idVille Integer
nomVille Variable characters (254)
Identifier_1 <pi>
typeUtilisateur
idTypeUtilisateur Integer
libelle Variable characters (254)
Identifier_1 <pi>
entreprise
idEntreprise Integer
idPays Integer
idVille Integer
nom Variable characters (254) (D)
contact Integer
email Variable characters (254)
logo Variable characters (254)
etat Short integer
rendezVous
Identifier_1 <pi>
idRdv Integer
idUtilisateur Integer
idPersonnel Integer
objet Variable characters (254)
date Timestamp
etat Short integer
Personnel Identifier_1 <pi>
idPersonnel Integer
idEmploiTemps Integer
idEntreprise Integer
poste Variable characters (254)
etat Short integer
nom Variable characters (254)
prenom Variable characters (254)
Identifier_1 <pi>
Abonnement (D)
id_abonnement Integer
idEntreprise Integer emploiTemps
libelle Variable characters (254) idEmploiTemps Integer
duree Integer libelle Variable characters (254)
Identifier_1 <pi> horaire Timestamp
Identifier_1 <pi>
Figure 15 : Modèle logique de données

3.2.2.2. Schéma physique des données
Le schéma physique est la représentation graphique de la structure de la base de données.

Il est a été obtenu grâce à la conversion du schéma logique et est présenté dans la figure
suivante :
Pays
utilisateur
idPays integer <pk>
idUtilisateur integer <pk>
nomPays varchar(254)
idEntreprise integer <fk2>
codePays integer
idTypeUtilisateur integer <fk1>
nom varchar(254)
prenom varchar(254)
tel integer
email varchar(254)
password varchar(254)
Ville
idPays integer <pk,fk>
idVille integer <pk>
nomVille varchar(254)
typeUtilisateur
idTypeUtilisateur integer <pk>
libelle varchar(254)
entreprise
idEntreprise integer <pk>
idPays integer <fk>
idVille integer <fk>
nom varchar(254) rendezVous
contact integer idRdv integer <pk>
email varchar(254) idUtilisateur integer <fk1>
logo varchar(254) idPersonnel integer <fk2>
etat smallint objet varchar(254)
date timestamp
etat smallint
emploiTemps
idEmploiTemps integer <pk>
libelle varchar(254)
horaire timestamp
Abonnement Personnel
id_abonnement integer <pk> idPersonnel integer <pk>

idEntreprise integer <fk> idEmploiTemps integer <fk2>
libelle varchar(254) idEntreprise integer <fk1>
duree integer poste varchar(254)
etat smallint
nom varchar(254)
prenom varchar(254)
Figure 16 : Modèle physique de données

3.3. REALISATION ET BILAN

3.3.1. Modules développés
Pour s’assurer du bon fonctionnement de notre système, nous avons développé quelques
modules qui sont récapitulés dans la liste suivante :
 La gestion de compte : ce module permet la création et la modification des comptes
sur la plateforme. Le compte comprend les identifiants de l’utilisateur (son nom, prénom,
adresse, etc.) ;
 La gestion des entreprises : ce module permet de créer une entreprise et d’avoir un
aperçu sur les différents personnels, les rendez-vous et sur l’état de son abonnement ;
 La gestion des emplois de temps : ce module permet l’ajout d’un emploi un temps dans
la plateforme, la modification et la suppression d’un emploi de temps ;
 La gestion des rendez-vous : ce module permet aux secrétaires de gérer les différents
rendez-vous sur la plateforme ;
 La gestion des personnels : ce module permet d’ajouter, de modifier et supprimer des
personnels dans la plateforme.
3.3.2. L’enchainement des écrans
Ecran d’accueil
La page d’accueil est le tout premier écran qui apparait lorsqu’une personne se rend sur la
plateforme. Il permet un premier contact avec un utilisateur ou un visiteur.

Figure 17 : Ecran d’accueil

Ecran d’inscription
La page d’inscription permet à tous les utilisateurs de s’inscrire sur la plateforme en
renseignant ses différentes informations.
Figure 18 : Ecran d’inscription

Ecran de connexion
Chaque utilisateur souhaitant prendre rendez-vous, ajouter une entreprise, ajouter un

personnel dans son entreprise etc… doit s’authentifier en fournissant son email et son numéro
de téléphone. Les administrateurs devront également s’authentifier.
Figure 19 : Ecran de connexion

Ecran d’ajout d’entreprise
Cette image présente le formulaire d’ajout d’entreprise sur la plateforme.
Figure 20 : Ecran d’ajout d’entreprise
Ecran de présentation d’entreprises
Sur cet écran l’utilisateur pourra voir des différentes entreprises disponibles sur la
plateforme.

Figure 21 : Ecran de présentation d’entreprise
Ecran de présentation des personnels

Sur cet écran, l’utilisateur pourra voir les différents personnels de l’entreprise choisi.
Figure 22 : Ecran de présentation des personnels
Ecran des demandes de rendez-vous
Sur cette page, les administrateurs d’entreprises pourront voir les différents rendez-vous qu’ils
ont reçus.
Figure 23 : Ecran des demandes de rendez-vous
3.3.3. Planning réel

Figure 24 : Planning réel
3.3.4. Analyse des écarts
Nous constatons que le planning prévisionnel défini plus haut n’a pas été respecté et tous
les modules n’ont pas étés implémentés. Ces différences sont dues à plusieurs facteurs. Parmi
ces facteurs nous pouvons citer :
 L’étude et la compréhension du domaine a pris plus de temps que

prévu, car le thème est assez large et renferme beaucoup
d’éléments ;
 La validation des différentes étapes de la conception a suscité aussi
plus de temps par rapport à nos premières estimations ;
 Il y a aussi la prise en main du Framework Bootstrap. 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.
3.3.5. Politique de sécurité
La politique de sécurité d’un système d’information est un plan d’actions définies pour
maintenir un certain niveau de sécurité. Ce plan d’action consiste par exemple à :
 Minimiser les accès non autorisés ;

 Prévenir la présence des programmes malveillants ;
 Eviter les incohérences de données.
Ainsi, il faut prendre les dispositions nécessaires afin d’assurer la disponibilité et le bon

fonctionnement du système.
3.3.5.1. Protection contre les instructions
Dans l’optique de la sécurisation du système, les utilisateurs doivent s’authentifier avant

d’avoir accès aux fonctionnalités de l’application. La politique de protection contre l’intrusion
est à la fois technique et organisationnelle. Elle vise à réduire les risques d’accès interdits au
système d’information à travers l’usage du mécanisme d’authentification par le couple
identifiants et mots de passe. Dans la réalisation du présent projet, nous avons pris les
dispositions suivantes :
 Les identifiants de connexion sont uniques et propre à un utilisateur donné ;

 Les mots de passe sont cryptés par un algorithme de Hachage ;
 L’accès à la base de données est protégé par un mot de passe.
3.3.5.2. Mise en place de la sauvegarde et de la restauration
En informatique, une sauvegarde ou backup en anglais, est une opération qui consiste à
dupliquer et à mettre en sécurité les données contenues dans un système d’information. Comme
méthode de sauvegarde, nous avons les techniques suivantes :
 La première technique est la sauvegarde complète qui consiste à

sauvegarder l’intégralité des données ;
 La deuxième technique est la sauvegarde incrémentale ou

incrémentielle. Elle consiste à ne sauver que les données modifiées
ou nouvelles depuis la dernière version. La restauration passe
obligatoirement par une restauration de la sauvegarde complète, puis
de toutes les sauvegardes incrémentales ;
 Et enfin la technique de sauvegarde différentielle. Elle sauve toutes

les données nouvelles ou modifiées depuis la dernière sauvegarde
complète. La restauration passe par une restauration de la sauvegarde
complète puis de la dernière sauvegarde différentielle.
Dans notre cas nous avons opté pour la technique de sauvegarde différentielle car sa
restauration passe par une restauration de la sauvegarde complète puis de la dernière sauvegarde
différentielle.

Nous avons d’une part, identifiés dans ce chapitre les éléments de conception
nécessaires à la réalisation du système RDVonline. Nous avons procédé à la délimitation du
domaine d’étude, puis établi les diagrammes de classes. Nous avons également présenté le
schéma logique et le schéma physique des données. Nous avons d’autre part, présenté
l’implémentation de la solution et le bilan. Nous avons d’abord présenté les modules qui ont
été développés. Nous avons par suite présenté l’enchainement de quelques écrans de la solution
proposée. Une analyse des écarts a été faite avant de présenter la politique de sécurité du
système.

CONCLUSION GENERALE
Nous avons effectué notre stage de fin de cycle de licence informatique option analyse
et programmation au sein de l’entreprise Nos3S. Après notre intégration à l’équipe, chose qui
fut rapide, nous avons eu à effectuer plusieurs tâches qui ont constituées notre mission globale
de stage. Le présent rapport fait le bilan de notre stage. Il est composé de trois (03) chapitres
qui détaillent respectivement le contexte de stage, les démarches et les moyens de résolution, le
domaine d’étude, la spécification du système, l’architecture du système, la conception de la
solution ainsi que la réalisation et le bilan du système. Nous tenons à exprimer notre satisfaction
d’avoir travaillé dans de bonnes conditions matérielles et un environnement agréable.
Au terme de ce stage, les bénéfices qui s’en dégagent sont manifestes. D’abord sur le plan
professionnel, nous avons engrangé des acquis considérables. Ensuite nos connaissances ont
été approfondi en conduite de projet, en programmation notamment la programmation web, en
base de données ainsi qu’en conception et modélisation. Enfin nous avons été initiés à l’art d’un
savoir-faire professionnel inégalable.

LISTE DES REFERENCES BIBLIOGRAPHIQUE.
BIBLIOGRAPHIE
 Pascal Roques, « les Cahiers du Programmeur UML2 » 6e édition, 2008.

 Mathieu NEBRA, « Apprenez à créer votre site web avec
HTML5 et CSS3 », OpenClassrooms, Avril 2013.
 Mathieu NEBRA, « concevez votre site web avec PHP et
MySQL », site du zéro.
 Nesquik69 et Thunderseb, « Dynamisez vos sites web avec
JavaScript ! », site du zéro Décembre 2011.
 MichelMartin, « Simplifiez vos développements JavaScript avec
jQuery », site du zéro.
 Bestmomo, « Prenez en main Bootstrap », OpenClassrooms, Mars 2014.
 MichelMartin, « Simplifiez vos développement JavaScript avec
jQuery », OpenClassrooms, Janvier 2013.
WEBOGRAPHIE
 Période : Du 05/02/2022 au 21/02/2022
https//www.laafi-express.com
https//www.madate.fr
https//www.app.reservio.com.
 Période : Du 01/03/2022 au 21/03/2022
https//www.openclassrooms.com/fr/courses
https/www.getbootstrap.com
https/www.bootstrapmade.com
 Période : Du 03/06/2022 au 26/06/2022
https/www.jquery.net
https/www.jqueryscript.net
https/www.3schools.com
https/www.phpgang.com
UNIVERSITE AUBE NOUVELLE i

ANNEXE
Annexe 1 : mysql
Date de première version 23 mai 1995

Développeur MySQL AB / Oracle
Dernière version 8.0.23 du 18 Janvier 2021
Système d’exploitation Windows, Linux, Mac OS X et d'autres
Licence GPL ou propriétaire
Site web http://www.mysql.com/
MySQL est un Système de Gestion de Bases de Données Relationnelles (SGBDR). Il

est distribué sous une double licence GPL 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, en concurrence avec Oracle, Informix et Microsoft
SQL Server. Son nom vient du prénom de la fille du Co-créateur, Michael Widenius. MySQL
fait référence au Structured Query Language, le langage de requête utilisé.
UNIVERSITE AUBE NOUVELLE ii

Annexe 2 : Bootstrap
Bootstrap est une collection d’outils utile à la création du design (graphisme, animation
et interactions avec la page dans le navigateur, etc ...) de sites et d'applications web. C'est un
ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation
et autres éléments interactifs, ainsi que des extensions JavaScript en option.
UNIVERSITE AUBE NOUVELLE iii

TABLES DES MATIERES

DEDICACE ............................................................................................................................... III
REMERCIEMENTS ................................................................................................................... IV
RESUME .................................................................................................................................. V
ABSTRACT .............................................................................................................................. VI
LISTE DES TABLEAUX ............................................................................................................. VII
LISTE DES FIGURES ............................................................................................................... VIII
LISTE DES SIGLES ET ABREVIATION ........................................................................................ IX
INTRODUCTON GENERALE ..................................................................................................... 1
PROBLEMATIQUE.................................................................................................................... 2
CHAPITRE 1 : CONTEXE ET DEMARCHE METHODOLOGIQUE ................................... 3
1.1. INTRODUCTION PARTIELLE .............................................................................................. 3
1.2. PRESENTATION DU CONTEXTE DU STAGE ....................................................................... 3
1.2.1. Présentation de l’université Aube Nouvelle ................................................................. 3
1.2.1.1. Présentation générale ............................................................................................... 3
1.2.1.2. Formation et diplôme ................................................................................................ 4
1.2.1.2.1. Les unités de formation et de recherche ............................................................... 4
1.2.1.2.2. Les unités ................................................................................................................ 5
1.2.1.2.3. L’école doctorale .................................................................................................... 5
1.2.2. Présentation de la structure de Nos3S ......................................................................... 6
1.2.2.1. Historique et situation géographique ....................................................................... 6
1.2.2.2. Objectifs et missions.................................................................................................. 6
1.2.2.3. Les différentes réalisations ........................................................................................ 6
1.2.2.4. Organisation de Nos3S .............................................................................................. 7
1.2.3. Présentation du thème ................................................................................................. 7
1.2.3.1. Objectifs d’études ...................................................................................................... 7
1.2.3.2. Résultats attendus ..................................................................................................... 8
1.2.3.4. Gestion du projet ....................................................................................................... 8
1.2.3.4.1. Délimitation de l’analyse du domaine.................................................................... 8
1.2.3.4.2. Acteurs du projet .................................................................................................... 8
1.2.3.4.3. Planning prévisionnel ............................................................................................. 9
1.3. DEMARCHE ET MOYEN DE RESOLUTION ......................................................................... 9
1.3.1. Les exigences fonctionnelles et techniques ............................................................... 10
1.3.1.1. Les exigences fonctionnelles ................................................................................... 10
UNIVERSITE AUBE NOUVELLE iv

1.3.1.2. Les exigences techniques ........................................................................................ 10

1.3.2. Méthodes de résolution du problème ....................................................................... 11
1.3.2.1. Choix de langage de modélisation........................................................................... 11
1.3.2.1.1. Justification du choix d’UML................................................................................. 11
1.3.2.1.2. Présentation d’UML .............................................................................................. 11
1.3.2.1.3. Les diagrammes .................................................................................................... 12
1.3.2.1.4. Outils de modélisation.......................................................................................... 14
1.3.2.2. Processus de développement ................................................................................. 14
1.4. DOMAINE D’ETUDE........................................................................................................ 16
1.4.1. Etude de l’existant ...................................................................................................... 16
1.4.1.1. Présentation de l’existant........................................................................................ 16
1.4.1.1.1. Définition .............................................................................................................. 16
1.4.1.1.2. Analyse critique de l’existant ............................................................................... 16
1.4.2. Présentation des ressources disponibles ................................................................... 17
CHAPITRE 2 : ANALYSE FONCTIONNELLE ET TECHNIQUE DU FUTUR SYSTEME
.................................................................................................................................................. 18
2.2. SPECIFICATION DU FUTUR SYSTEME ............................................................................. 18
2.2.1. Identification des acteurs et des cas d’utilisation ...................................................... 18
2.2.1.1. Identification des acteurs ........................................................................................ 18
2.2.1.2. Identification des acteurs et des cas d’utilisation ................................................... 19
2.2.1.3. Les cas d’utilisation .................................................................................................. 19
2.2.1.4. Description textuelle des cas d’utilisations ............................................................. 20
2.2.2. Diagramme de cas de d’utilisation ............................................................................. 24
2.2.3. Diagramme de séquence ............................................................................................ 25
2.3. ARCHITECTURE DU FUTUR SYSTEME ............................................................................. 30
2.3.1. Identification des outils .............................................................................................. 30
2.3.2. Architecture logicielle ................................................................................................. 33
2.3.3. Estimation du coût...................................................................................................... 35
CHAPITRE 3 : CONCEPTION ET REALISATION DE LA SOLUTION ............................ 37
3.2. CONCEPTION DE LA SOLUTION...................................................................................... 37
UNIVERSITE AUBE NOUVELLE v

3.2.1. Délimitation et analyse du domaine .......................................................................... 37

3.2.1.1. Identification des règles de gestion......................................................................... 37
3.2.1.2. Identification des concepts clés du domaine .......................................................... 38
3.2.1.3. Dictionnaire de données ......................................................................................... 38
3.2.1.4. Diagramme de classe du domaine .......................................................................... 40
3.2.1.5. Diagramme d’états-transitions ................................................................................ 42
3.2.1.6. Diagramme de déploiement .................................................................................... 43
3.2.2. Schéma logique et physique des données ................................................................. 44
3.2.2.1. Schéma logique des données .................................................................................. 44
3.2.2.2. Schéma physique des données ............................................................................... 46
3.3. REALISATION ET BILAN .................................................................................................. 47
3.3.1. Modules développés .................................................................................................. 47
3.3.2. L’enchainement des écrans ........................................................................................ 47
3.3.3. Planning réel ............................................................................................................... 53
3.3.4. Analyse des écarts ...................................................................................................... 54
3.3.5. Politique de sécurité ................................................................................................... 54
3.3.5.1. Protection contre les instructions ........................................................................... 55
3.3.5.2. Mise en place de la sauvegarde et de la restauration............................................. 55
CONCLUSION GENERALE ...................................................................................................... 57
LISTE DES REFERENCES BIBLIOGRAPHIQUE. ................................................................. i
BIBLIOGRAPHIE ........................................................................................................................ i
WEBOGRAPHIE ........................................................................................................................ i
ANNEXE ................................................................................................................................... ii
UNIVERSITE AUBE NOUVELLE vi

Rapport Final Barry

Transféré par

Informations du document

Titre original

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 Final Barry

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE AUBE NOUVELLE

INSTITUT SUPERIEUR D’INFORMATIQUE ET DE GESTION

Présenté par : BARRY Inoussa Sous la direction de :

Année académique : 2021-2022

UNIVERSITE AUBE NOUVELLE I

3.2. CONCEPTION DE LA SOLUTION...................................................................................... 37

UNIVERSITE AUBE NOUVELLE II

Qu’elle trouve ici le témoignage de ma profonde reconnaissance.

d’émotions lors de la réalisation de ce travail. Ils m’ont chaleureusement supporté et

encouragé tout au long de mon parcours.

A ma famille, mes proches et à ceux qui me donnent de l’amour et de la vivacité.

A tous ceux que j’aime.

UNIVERSITE AUBE NOUVELLE III

 M.Tiémogo TRAORE, ingénieur de conception en système d’information, mon

UNIVERSITE AUBE NOUVELLE IV

UNIVERSITE AUBE NOUVELLE V

Making an appointment is an essential step to bring service companies and their

UNIVERSITE AUBE NOUVELLE VI

LISTE DES TABLEAUX

Tableau 1 : Analyse critique de l’existant ................................................................................ 16

UNIVERSITE AUBE NOUVELLE VII

LISTE DES FIGURES

Figure 1 : Organigramme de Nos3S source Nos3S .................................................................... 7

UNIVERSITE AUBE NOUVELLE VIII

LISTE DES SIGLES ET ABREVIATION

UNIVERSITE AUBE NOUVELLE IX

UNIVERSITE AUBE NOUVELLE 1

La gestion des rendez-vous est un élément incontournable pour le développement d’une

UNIVERSITE AUBE NOUVELLE 2

CHAPITRE 1 : CONTEXE ET DEMARCHE METHODOLOGIQUE

Nous présentons premièrement dans ce chapitre notre établissement de formation ainsi

1.2. PRESENTATION DU CONTEXTE DU STAGE

L’Institut Supérieur d’Informatique et de Gestion (ISIG) est un établissement privé

UNIVERSITE AUBE NOUVELLE 3

l’Ambassade des Etats-Unis d’Amérique au Burkina Faso et l’Université Aube Nouvelle, le

1.2.1.2. Formation et diplôme

1.2.1.2.1. Les unités de formation et de recherche

Nous distinguons plusieurs UFR qui sont les suivantes :

 UFR /Sciences Juridiques et Politiques

UNIVERSITE AUBE NOUVELLE 4

1.2.1.2.2. Les unités

Nous distinguons plusieurs instituts qui sont les suivants :

 Institut des Métiers de la Communication, du Journalisme, de l’Audiovisuel et du

 Des Masters de recherche

 Domaine en Sciences et Technologies

 Imagerie Numérique pour le Développement Durable (INDD) ;

 Développement des Projets à l’International ;

1.2.1.2.3. L’école doctorale

U-AUBEN à de nos jours une école doctorale deux domaines :

UNIVERSITE AUBE NOUVELLE 5

1.2.2. Présentation de la structure de Nos3S

1.2.2.3. Les différentes réalisations

UNIVERSITE AUBE NOUVELLE 6

1.2.2.4. Organisation de Nos3S

La structure Organisationnelle de Nos3S est hiérarchisée et comprend :

 Un Conseil d’Administration (CA) ;

DRH DCB DCM DPD DRM

1.2.3. Présentation du thème

UNIVERSITE AUBE NOUVELLE 7

1.2.3.2. Résultats attendus

 La gestion des entreprises ;

1.2.3.4. Gestion du projet

La délimitation d’un projet consiste à mettre en évidence les différentes parties