Ce rapport présente le projet de fin d'études de Khalfaoui Ichraf, réalisé pour l'obtention d'un diplôme de licence en science informatique à l'Institut supérieur d'informatique et de gestion de Kairouan. Le projet porte sur la conception et la réalisation d'un site web dynamique au sein de l'entreprise Optans, avec un encadrement académique et professionnel. Le document comprend une analyse détaillée des besoins, des cas d'utilisation et des méthodes de conception adoptées.

1. A.U. : 2019-2020
Université de Kairouan
Institut Supérieur d’Informatique et de Gestion de Kairouan
Département Informatique
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du diplôme
de licence fondamental
Option : Science Informatique
Conception et réalisation d’un site web dynamique
Préparé au sein de l’entreprise : Optans
Réalisé par :Khalfaoui Ichraf
Encadrant académique :Mr.Ourimi Ali
Encadrant professionnel : Ben Fradj Safwen

2. Dédicace
A mes très chers parents
Source de vie, d’amour et d’affection
A ma belle sœur
Source d’amour et d’encouragement
A mes chers frères
Source de joie et de bonheur
A toute ma famille
Source d’espoir et de motivation
A tous mes amis
A vous cher lecteur
1

3. Remerciement
Avant tout, nous tenons à remercier mon dieu. De nous avoir donné la santé, la volonté et
la patience pour mener à terme notre formation de licence et pouvoir réalise ce travail.
Nous tenons à exprimer nos profonds remerciements à notre encadreur pédagogique Mr
Ourimi Ali qui nous a fourni le sujet de ce rapport et nous a guidés de ses précieux
conseils et suggestions, et la confiance qu’il nous a témoignés tout ou long de ce travail.
Je tiens également à adresser mes remerciements et ma gratitude à mon encadreur
professionnelle Ben Fraj Safwen pour sa disponibilité, son soutien et son aide précieuse
tout au long de ce projet.
Nous tenons a gratifier aussi les membres de jury pour l’intérêt qu’ils ont porté a notre
projet en acceptant d’examiner notre travail.
J’adresse aussi nos remerciements à Mr kalboussi Anis chef de département de
l’Informatique et a tous les enseignants de la filière de science Informatique.
Enfin, on adresse nos sincères sentiment de gratitudes et de reconnaissances atout les
personnes qui ont participe de près ou de loin a réalisation de ce travail.
2

4. Table des matières
1 Cadre générale du projet 16
1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . . . 17
1.2.2 les activités principales de l’entreprise . . . . . . . . . . . . . . . . . 17
1.2.3 Fiche de renseignements de l’organisme d’accueil . . . . . . . . . . . 17
1.2.4 Emplacement de l’entreprise . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Présentation du sujet Proposé . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 Les Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Méthodologie de Travail adoptée . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Méthode de Modélisation (Modèle de cycle de vie) . . . . . . . . . . 19
1.4.1.1 Modèle de cycle de vie en CASCADE . . . . . . . . . . . 19
1.4.1.2 Modèle de cycle de vie en V . . . . . . . . . . . . . . . . . 21
1.4.1.3 Modèle de cycle de vie en SPIRALE . . . . . . . . . . . . 21
1.4.2 Langages De Modélisation . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.3 Langages de modélisation textuels . . . . . . . . . . . . . . . . . . . 22
3

5. Table des matières
1.4.3.1 La vue statique est caractérisée par : . . . . . . . . . . . . 22
1.4.3.2 La vue dynamique est caractérisée par : . . . . . . . . . . 22
1.4.3.3 Les Avantages de langage de modélisation UML : . . . . . 23
1.4.4 Méthode et Langage De Modélisation choisis . . . . . . . . . . . . . 23
1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) . . . . . . . . . 24
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Spécifications des besoins 25
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . . 27
2.3.2 Liste Des Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . 27
2.3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . . 28
2.3.4 Description Des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 28
2.3.4.1 Les cas d’utilisation de l’acteur visiteur . . . . . . . . . . . 29
2.3.4.2 Raffinement du cas d’utilisation consulter membre d’équipe 29
2.3.4.3 Raffinement du cas d’utilisation consulter article . . . . . 30
2.3.4.4 Raffinement du cas d’utilisation consulter client . . . . . 31
2.3.4.5 Raffinement du cas d’utilisation consulter service . . . . . 31
2.3.4.6 Raffinement du cas d’utilisation consulter offre . . . . . . 32
2.3.4.7 Raffinement du cas d’utilisation contacter . . . . . . . . . 33
2.3.4.8 Les cas d’utilisation de l’acteur Membre . . . . . . . . . . 33
2.3.4.9 Raffinement du cas d’utilisation authentification membre . 34
4

6. Table des matières
2.3.4.10 Raffinement du cas d’utilisation gérer client . . . . . . . . 34
2.3.4.11 Raffinement du cas d’utilisation gérer service . . . . . . . 35
2.3.4.12 Raffinement du cas d’utilisation gérer article . . . . . . . . 36
2.3.4.13 Raffinement du cas d’utilisation consulter liste message . . 36
2.3.4.14 Les cas d’utilisation de l’acteur Administrateur . . . . . . 37
2.3.4.15 Raffinement du cas d’utilisation authentification adminis-
trateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.4.16 Raffinement du cas d’utilisation gérer membre . . . . . . . 38
2.3.4.17 Raffinement du cas d’utilisation gérer offre . . . . . . . . . 39
2.3.4.18 Raffinement du cas d’utilisation consulter demande . . . . 39
2.3.5 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . . 41
2.3.6 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 Analyse 45
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Présentation de la démarche du modèle d’analyse . . . . . . . . . . . . . . 46
3.3 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Analyse du cas d’utilisation S’authentification . . . . . . . . . . . . 47
3.3.1.1 Analyse du cas d’utilisation ”s’authentifier” de l’acteur ’ad-
ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1.2 Digramme de collaboration du cas ”s’authentifier” . . . . 47
3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visiteur’ 48
3.3.2.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Consulter article” et le modèle analyse . . . . . . . . 48
3.3.2.2 Digramme de collaboration du cas ”consulter article” . . . 48
5

7. Table des matières
3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visiteur’ 49
3.3.3.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Demander offre” et le modèle analyse . . . . . . . . 49
3.3.3.2 Digramme de collaboration du cas ”Demander Offre” . . . 49
3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Visiteur’ 50
3.3.4.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Envoyer Message” et le modèle analyse . . . . . . . 50
3.3.4.2 Digramme de collaboration du cas ”Demander Offre” . . . 50
3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Membre’ 51
3.3.5.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Ajouter Client” et le modèle analyse . . . . . . . . . 51
3.3.5.2 Digramme de collaboration du cas ”Ajouter Client” . . . . 51
3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Membre’ 52
3.3.6.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Modifier Service” et le modèle analyse . . . . . . . . 52
3.3.6.2 Digramme de collaboration du cas ”Modifier Service” . . . 52
3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’acteur ’Ad-
ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.7.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Supprimer Membre” et le modèle analyse . . . . . . 53
3.3.7.2 Digramme de collaboration du cas ”Supprimer Membre” . 53
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 Conception 55
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Présentation de la démarche du modèle de conception . . . . . . . . . . . . 56
4.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 57
6

8. Table des matières
4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’acteur ’Admi-
nistrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.1.1 Diagramme de traçabilité du cas d’utilisation ”s’authenti-
fier” de l’acteur ’Administrateur’ entre le modèle d’analyse
et le modèle de conception . . . . . . . . . . . . . . . . . . 57
4.3.1.2 Diagramme de séquence relative au cas d’utilisation ”s’au-
thentifier” de l’acteur ’Administrateur’ . . . . . . . . . . . 58
4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur ’Vi-
siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.2.1 Diagramme de traçabilité du cas d’utilisation ”consulter
article” de l’acteur ’visiteur’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 58
4.3.2.2 Diagramme de séquence relative au cas d’utilisation ”Consul-
ter article” de l’acteur ’visiteur’ . . . . . . . . . . . . . . . 59
4.3.3 Conception du cas d’utilisation ” envoyer message” de l’acteur ’Vi-
siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3.1 Diagramme de traçabilité du cas d’utilisation ”envoyer mes-
sage” de l’acteur ’Visiteur’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 59
4.3.3.2 Diagramme de séquence relative au cas d’utilisation ”en-
voyer message” de l’acteur ’visiteur’ . . . . . . . . . . . . 60
4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4.1 Diagramme de traçabilité du cas d’utilisation ”ajouter client”
de l’acteur ’Membre’ entre le modèle d’analyse et le modèle
de conception . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4.2 Diagramme de séquence relative au cas d’utilisation ”ajou-
ter client” de l’acteur ’Membre’ . . . . . . . . . . . . . . . 62
4.3.5 Conception du cas d’utilisation ” modifier service” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7

9. Table des matières
4.3.5.1 Diagramme de traçabilité du cas d’utilisation ”modifier ser-
vice” de l’acteur ’Membre’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 63
4.3.5.2 Diagramme de séquence relative au cas d’utilisation ”mo-
difier service” de l’acteur ’Membre’ . . . . . . . . . . . . . 64
4.3.5.3 Diagramme de traçabilité du cas d’utilisation ”supprimer
membre” de l’acteur ’Administrateur’ entre le modèle d’ana-
lyse et le modèle de conception . . . . . . . . . . . . . . . 65
4.3.5.4 Diagramme de séquence relative au cas d’utilisation ”sup-
primer membre” de l’acteur ’Administrateur’ . . . . . . . 65
4.3.5.5 Diagramme de traçabilité du cas d’utilisation ”demander
offre” de l’acteur ’Visiteur’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 66
4.3.5.6 Diagramme de séquence relative au cas d’utilisation ”de-
mander offre” de l’acteur ’Visiteur’ . . . . . . . . . . . . . 67
4.4 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.1 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Modèles de paquetages et de déploiement . . . . . . . . . . . . . . . . . . . 68
4.5.1 Modèles de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Implémentation 70
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1 Environnement de développement . . . . . . . . . . . . . . . . . . . 71
5.2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Description de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . . 72
8

10. Table des matières
5.3.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . . . 72
5.3.3 Présentation de l’interface ’contacter’ : . . . . . . . . . . . . . . . . 73
5.3.4 Présentation de l’interface ’liste membre’ : . . . . . . . . . . . . . . 73
5.3.5 Présentation de l’interface ’ajouter client’ : . . . . . . . . . . . . . . 74
5.3.6 Présentation de l’interface ’gérer client’ : . . . . . . . . . . . . . . . 74
5.3.7 Présentation de l’interface ’liste des messages’ : . . . . . . . . . . . 75
9

11. Table des figures
1.1 logo de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Emplacment de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Modèle de cycle de vie en CASCADE . . . . . . . . . . . . . . . . . . . . . 20
1.4 Modèle de cycle de vie en V . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 Modèle de cycle de vie en SPIRALE . . . . . . . . . . . . . . . . . . . . . 22
1.6 logo de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Diagramme de contexte Dynamique . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Cas d’utilisateur de l’acteur visiteur . . . . . . . . . . . . . . . . . . . . . . 29
2.4 cas d’utilisation consulter membre d’équipe . . . . . . . . . . . . . . . . . . 29
2.5 cas d’utilisation consulter article . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 cas d’utilisation consulter client . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 cas d’utilisation consulter service . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 cas d’utilisation consulter offre . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9 cas d’utilisation contacter . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10 cas d’utilisation acteur membre . . . . . . . . . . . . . . . . . . . . . . . . 33
2.11 cas d’utilisation authentification membre . . . . . . . . . . . . . . . . . . . 34
10

12. Table des figures
2.12 cas d’utilisation consulter article . . . . . . . . . . . . . . . . . . . . . . . . 34
2.13 cas d’utilisation gérer service . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.14 cas d’utilisation gérer article . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.15 cas d’utilisation consulter liste message . . . . . . . . . . . . . . . . . . . . 36
2.16 cas d’utilisation acteur administrateur . . . . . . . . . . . . . . . . . . . . 37
2.17 cas d’utilisation authentification administrateur . . . . . . . . . . . . . . . 37
2.18 cas d’utilisation gérer membre . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.19 cas d’utilisation gérer offre . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.20 cas d’utilisation consulter demande . . . . . . . . . . . . . . . . . . . . . . 39
2.21 cas d’utilisation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1 diagramme de traçabilité entre le modèle de cas d’utilisation ”s’authentifier”
et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 digramme de collaboration du cas ”s’authentifier” . . . . . . . . . . . . . . 47
3.3 diagramme de traçabilité entre le modèle de cas d’utilisation ”Consulter
article” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 digramme de collaboration du cas ”consulter article” . . . . . . . . . . . . 48
3.5 diagramme de traçabilité entre le modèle de cas d’utilisation ”Demander
offre” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6 digramme de collaboration du cas ”Demander Offre” . . . . . . . . . . . . 49
3.7 diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Mes-
sage” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8 digramme de collaboration du cas ”Envoyer Message” . . . . . . . . . . . . 50
3.9 diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client”
et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.10 digramme de collaboration du cas ”Ajouter Client” . . . . . . . . . . . . . 51
3.11 diagramme de traçabilité entre le modèle de cas d’utilisation ”Modifier Ser-
vice” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11

13. Table des figures
3.12 digramme de collaboration du cas ”Modifier Service” . . . . . . . . . . . . 52
3.13 diagramme de traçabilité entre le modèle de cas d’utilisation ”Supprimer
Membre” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.14 digramme de collaboration du cas ”Supprimer Membre” . . . . . . . . . . 53
4.1 Diagramme de traçabilité du cas d’utilisation ”s’authentifier” . . . . . . . 57
4.2 Diagramme de séquence relative au cas d’utilisation ”s’authentifier” . . . . 58
4.3 Diagramme de traçabilité du cas d’utilisation ”consulter article” . . . . . . 58
4.4 Diagramme de séquence relative au cas d’utilisation ”consulter article” . . 59
4.5 Diagramme de traçabilité du cas d’utilisation ”envoyer message” . . . . . 59
4.6 Diagramme de séquence relative au cas d’utilisation ”envoyer message” . . 60
4.7 Diagramme de traçabilité du cas d’utilisation ”ajouter client” . . . . . . . 61
4.8 Diagramme de séquence relative au cas d’utilisation ”ajouter client” . . . 62
4.9 Diagramme de traçabilité du cas d’utilisation ”modifier service” . . . . . . 63
4.10 Diagramme de séquence relative au cas d’utilisation ”modifier service” . . 64
4.11 Diagramme de traçabilité du cas d’utilisation ”supprimer membre” . . . . 65
4.12 Diagramme de séquence relative au cas d’utilisation ”supprimer membre” 65
4.13 Diagramme de traçabilité du cas d’utilisation ”demander offre” . . . . . . 66
4.14 Diagramme de séquence relative au cas d’utilisation ”demander offre” . . 67
4.15 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . . . . . . 72
5.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . . . . . . . 72
5.3 Présentation de l’interface ’contacter’ . . . . . . . . . . . . . . . . . . . . . 73
5.4 Présentation de l’interface ’liste membre’ . . . . . . . . . . . . . . . . . . . 73
5.5 Présentation de l’interface ’ajouter client’ . . . . . . . . . . . . . . . . . . . 74
5.6 Présentation de l’interface ’gérer client’ . . . . . . . . . . . . . . . . . . . . 74
12

14. Table des figures
5.7 Présentation de l’interface ’liste des messages’ . . . . . . . . . . . . . . . . 75
13

15. Liste des tableaux
2.1 Description textuelle du cas d’utilisation consulter membre . . . . . . . . 30
2.2 Description textuelle du cas d’utilisation consulter article . . . . . . . . . 30
2.3 Description textuelle du cas d’utilisation consulter client . . . . . . . . . . 31
2.4 Description textuelle du cas d’utilisation consulter service . . . . . . . . . . 32
2.5 Description textuelle du cas d’utilisation consulter offre . . . . . . . . . . . 32
2.6 Description textuelle du cas d’utilisation contacter . . . . . . . . . . . . . . 33
2.7 Description textuelle du cas d’utilisation authfication membre . . . . . . . 34
2.8 Description textuelle du cas d’utilisation gérer client . . . . . . . . . . . . . 35
2.9 Description textuelle du cas d’utilisation gérer service . . . . . . . . . . . . 35
2.10 Description textuelle du cas d’utilisation gérer article . . . . . . . . . . . . 36
2.11 Description textuelle du cas d’utilisation consulter liste message . . . . . . 37
2.12 Description textuelle du cas d’utilisation authentification administrateur . 38
2.13 Description textuelle du cas d’utilisation gérer membre . . . . . . . . . . . 38
2.14 Description textuelle du cas d’utilisation gérer offre . . . . . . . . . . . . . 39
2.15 Description textuelle du cas d’utilisation consulter demande . . . . . . . . 40
2.16 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
14

16. Liste des tableaux
Introduction générale
Tout le monde prétend aujourd’hui que l’informatique est une révolution fondamentale et
innovante qui a touché considérablement la vie humaine durant le dernier siècle. En réalité,
loin d’être un phénomène pétillant, ou une tendance passagère, l’informatique vient d’être
exploitée dans tous les aspects de la vie. Aucun domaine ne reste à l’abri de cette politique,
ce qui facilite les tâches de l’entreprise ainsi que celle des personnels.
Grâce a la généralisation et de la globalisation, les domaines de l’information et de la
communication ont évolué très rapidement avec l’amélioration des moyens de développement
et de programmation. Cela a conduit à une révolution dans la représentation, l’organisation
et le traitement des données. De nos jours, les sites Web sont devenus des moyens indispen-
sables pour tout type de service couvrant ainsi tous types de besoins. Une société de service
informatique est une entreprise qui énonce et vend des services informatiques. Elle joue le
rôle d’un médiateur entre les clients et les différents bénéficiaires de services présents sur
le marché de l’informatique. Elles sont considérées parmi les entreprises les plus fréquentes
sur le territoire tunisien. Dans ce cadre, se déroule notre projet de fin d’étude qui consiste
à développer un site web d’une société de service informatique. Notre solution vise à infor-
matiser la procédure traditionnelle et exhaustive de traitement des services, l’objectif est
d’organiser le secteur de travail en mettant à sa disposition un outil performant et fiable
permettant aux sociétés de mieux administrer les services et de faciliter l’accès pour leurs
clients. Le pressent rapport décrit notre projet. Il est structuré en cinq chapitres répartis
comme suit :
• Le premier chapitre présente le cadre général du projet dans lequel on va présenter
une description de l’organisme d’accueil en citant les différents problèmes et les
défauts que l’on remarque avec les solutions proposées. Il fournit aussi une étude
comparative entre quelques solutions existantes et quelques méthodologies de concep-
tion.
• Le deuxième chapitre sera consacré pour la spécification des besoins dans lequel on
va citer une étude de l’existant, ensuite on va présenter les besoins fonctionnels et
non fonctionnels.
• Dans le troisième chapitre, nous présentons la démarche du modèle analyse dont le
but d’examiner les différents cas d’utilisation.
• La démarche du modèle de conception ainsi que les différentes conceptions des cas
d’utilisations seront présentés dans le quatrième chapitre.
• Le dernier chapitre sera consacré pour l’implémentation. Tout d’abord on va présenter
l’environnement de développement matériel et logiciel utilisé pour l’application. En-
fin, nous présentons la description de cette dernière via quelques interfaces.
15

17. Chapitre 1
Cadre générale du projet
Sommaire
1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 17
1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . 17
1.2.2 les activités principales de l’entreprise . . . . . . . . . . . . . . . 17
1.2.3 Fiche de renseignements de l’organisme d’accueil . . . . . . . . . 17
1.2.4 Emplacement de l’entreprise . . . . . . . . . . . . . . . . . . . . . 18
1.3 Présentation du sujet Proposé . . . . . . . . . . . . . . . . . . . 18
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 Les Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Méthodologie de Travail adoptée . . . . . . . . . . . . . . . . . 19
1.4.1 Méthode de Modélisation (Modèle de cycle de vie) . . . . . . . . 19
1.4.2 Langages De Modélisation . . . . . . . . . . . . . . . . . . . . . . 22
1.4.3 Langages de modélisation textuels . . . . . . . . . . . . . . . . . 22
1.4.4 Méthode et Langage De Modélisation choisis . . . . . . . . . . . 23
1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) 24
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.1 introduction
Dans ce premier chapitre, nous présentons l’organisme d’accueil , nous décrivons brièvement
l’entreprise dans laquelle nous avons réalisé notre stage tout en citant l’ensemble de ses
16

18. Chapiter 1 : Cadre générale du projet
activités, par la suite nous avons dégagé les problèmes du système‘ actuel et les solutions
proposées..
1.2 Présentation de l’organisme d’accueil
1.2.1 Présentation générale de l’entreprise
Optans est une société du Technologies et services de l’information basée à Monastir,
elle possède des travailleurs spécialisés dans le développement des applications web et
des applications mobiles. avec un actionnariat et une direction de majorité belges, elle
combine l’exactitude européenne avec la qualité des ressources informatiques tunisiennes
pour donner la solution la plus performante à un coût extrêmement concurrentiel. Elle
applique évidemment les standards de qualité internationaux les plus élevés.
Figure 1.1: logo de l’entreprise
1.2.2 les activités principales de l’entreprise
• l’intégration des solutions open source.
• Développement des application mobiles.
• Des services de marketing internet.
• Développement web.
1.2.3 Fiche de renseignements de l’organisme d’accueil
• Nom de l’entreprise : Optans
• Secteur : Technologie et services de l’information
17

19. Chapiter 1 : Cadre générale du projet
• Taille de l’entreprise : 2-10 employés 4 sur LinkedIn
• Type :Société de personnes (associés)
• Spécialisations : intégration des solutions open source, Développement web, ap-
plication mobile et Marketing internet
• Date de fondation :2012
• Adresse :Immeuble jaafoura 5000, Monastir
• numéro de Téléphone :(+216) 73 46 32 87
1.2.4 Emplacement de l’entreprise
Figure 1.2: Emplacment de l’entreprise
1.3 Présentation du sujet Proposé
Pendant la période de notre stage de fin d’études dans cette entreprise, Nous avons
suggéré de développer une application web comme un projet dans le but de faciliter et
d’informatiser les tâches manuelles.
1.3.1 Problématique
Pendant la période de stage, nous avons découvert plusieurs problèmes :
• Absence d’accès direct à l’information.
• La présence physique des clients à l’entreprise était obligatoire pour toute consul-
tation ou contact.
• Risque de pertes des informations importantes et confidentielles.
18

20. Chapiter 1 : Cadre générale du projet
En outre, plusieurs taches sont réalisées manuellement, par exemple :
• Gestion des produits.
• Gestion des clients.
• Gestion des services.
• Gestion des articles .
• Gestion des membres.
• Gestion des offres.
1.3.2 Les Solutions proposées
Pour remédier à ces problèmes, nous avons proposé de développer un site web dyna-
mique qui représente plusieurs fonctionnalités :
• Résoudre le problème du temps perdu dans la gestion (rapidité).
• Les activités de notre entreprise seront bien présentées et organisés dans un site
web.
• Les clients seront capables de contacter et consulter l’entreprise en ligne.
• Éliminer les risques de chevauchement des informations importantes.
• Stocker les informations avec toute sécurité fiabilité.
• Faciliter la gestion.
Grâce à ces solutions le système de notre entreprise sera plus simple et facile.
1.4 Méthodologie de Travail adoptée
Le développement de tout projet informatique nécessite une démarche (méthodologie)
de travail que l’on choisit avant de commencer le projet. Ceci est assurée grâce à un modèle
de conception et des formalismes de notations.
1.4.1 Méthode de Modélisation (Modèle de cycle de vie)
1.4.1.1 Modèle de cycle de vie en CASCADE
Le modèle de cycle de vie en CASCADE a été élaboré en 1970. Le principe du modèle
CASCADE est de diviser le projet en sept phases distinctes sur le principe du non-retour.
Ce modèle est basé sur l’hypothèse : dès le début, nous pouvons définir ce que nous pouvons
réaliser pleinement (expressions des besoins). Dans ce modèle le principe est très simple :
19

21. Chapiter 1 : Cadre générale du projet
• L’étape peut commencer si son étape précédente est complètement terminée.
• Chaque étape se termine à une date précise avec la production de documents ou
programmes spécifiques.
• Les résultats sont déterminés sur la base des interactions entre les étapes, ils font
l’objet d’un examen approfondi et l’étape suivante n’est franchie que s’ils sont sa-
tisfaisants.
Figure 1.3: Modèle de cycle de vie en CASCADE
Avantages du modèle en cascade :
• C’est un modèle linéaire. Bien sûr, les modèles linéaires sont la méthode de mise en
œuvre la plus simple.
• L’un des grands avantages du modèle CASCADE est la production de documents
à chaque étape du développement du modèle, ce qui facilite la compréhension de la
conception du produit dans chaque procédure.
• Après chaque étape majeure de codage du programme, des tests sont effectués pour
vérifier que le code fonctionne correctement.
• Contrôle facile.
• Faciliter la planification des barrières et des routes.
• Accent sur la documentation et la structure.
• Idéal pour des projets logiciels stables.
Inconvénients du modèle en cascade :
• Mal adapté aux systèmes complexes (processus de développement rarement séquentiel).
• Les tests s’appliquent à l’application globale (pas de validation des besoins).
20

22. Chapiter 1 : Cadre générale du projet
• Difficile de définir toutes les exigences depuis le début du projet.
• Assez longtemps pour voir quelque chose.
1.4.1.2 Modèle de cycle de vie en V
Le modèle du cycle en V (par comparaison avec les méthodes dites agiles) est un modèle
conceptuel de gestion de projet imaginé à la suite du problème de réactivité du modèle
en cascade. Il permet en cas d’anomalie, de limiter un retour aux étapes précédentes. Les
phases de la partie montante doivent renvoyer de l’information sur les phases en vis-à-vis
lorsque des défauts sont détectes, afin d’améliorer le logiciel.[1]
Figure 1.4: Modèle de cycle de vie en V
1.4.1.3 Modèle de cycle de vie en SPIRALE
Le modèle en spirale a été défini par Barry Boehm en 1988 dans son article ”A Spiral
Model of Software Developpement and Enharnachement”. Le modèle en spirale est un
modèle pour le cours de développement logiciel qui prend les différentes étapes du cycle
V. En mettant en œuvre des versions successives, le cycle recommence en proposant un
produit complet et de plus en plus difficile. Le cycle en spirale met cependant plus l’accent
sur la gestion des risques que le cycle en V.
21

23. Chapiter 1 : Cadre générale du projet
Figure 1.5: Modèle de cycle de vie en SPIRALE
1.4.2 Langages De Modélisation
1.4.3 Langages de modélisation textuels
UML(Unified Modeling Langage) ou (langage de modélisation unifié) est le langage de
modélisation graphique permettant de réaliser un modèle d’une manière simple avec des
diagrammes. Ce langage définit par des vues et des diagrammes.
1.4.3.1 La vue statique est caractérisée par :
• le cas d’utilisation.
• Diagramme d’objet.
• Diagramme de classes.
• Diagramme de composants.
• Diagramme de déploiement.
1.4.3.2 La vue dynamique est caractérisée par :
• Diagramme de collaboration.
• Diagramme de séquence.
• Diagramme d’activités.
22

24. Chapiter 1 : Cadre générale du projet
• Diagramme d’état-transition.
1.4.3.3 Les Avantages de langage de modélisation UML :
• facilite les présentations exemplaire et complexes.
• Ce langage est un langage formel :
— Accepte l’utilisation d’outils.
— Assure la précision.
— Assure la stabilité.
• Ce langage peut servir de support pour tout langage de programmation orientée
objet.
Figure 1.6: logo de UML
1.4.4 Méthode et Langage De Modélisation choisis
Pour développer les étapes d’analyse, de conception et de mise en œuvre, nous avons
choisi une méthodologie qui comprend :
— La modèle de vie en CASCADE comme méthode de modélisation pour les raisons
suivantes :
— Les besoins fonctionnels et non fonctionnels de notre projet sont déterminés dès
le départ ...
— la démarche linéaire du modèle en CASCADE est simple à adopter et appliquer
dans les projets.
• Le langage de modélisation sélectionné est UML pour les raisons suivantes :
— UML permet de couvrir le cycle de vie dans CASCADE pour déterminer les
besoins.
— Activer l’encapsulation et le traitement des données.
23

25. Chapiter 1 : Cadre générale du projet
1.5 Planning Prévisionnels (Calendrier prévisionnel
De Travail)
La clé principale de la réussite d’un projet est un bon planning. En fait, la planification
permet de bien répartir le travail et sépare les tâches à effectuer, elle fournit la meilleure
estimation et la gestion du temps nécessaires pour chaque tâche. En outre, il donne un
aperçu de l’arrondi de la date d’achèvement de chaque tâche. L’élaboration du cahier
des charges, la conception et le développement d’un projet informatique nécessite une
organisation et un bon découpage des différentes étapes du projet.
1.6 Conclusion
Dans ce premier chapitre nous avons présenté le cadre général de notre projet avec
une description générale de l’entreprise ensuite nous avons proposé des solutions afin de
résoudre les différents problèmes.
24

26. Chapitre 2
Spécifications des besoins
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . 27
2.3.2 Liste Des Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . 27
2.3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . 28
2.3.4 Description Des cas d’utilisation . . . . . . . . . . . . . . . . . . 28
2.3.5 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . 41
2.3.6 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.1 Introduction
Après avoir défini l’objectif dans le chapitre précédent, nous consacrons ce chapitre à
l’identification des besoins fonctionnels et non fonctionnels d’écriture d’acteurs sur notre
site. Nous fournirons une description détaillée des principaux cas d’utilisation sur la base
des résultats de l’analyse des besoins.
25

27. Chapiter 2 : Spécifications des besoins
2.2 Etude de l’existant
Avant d’identifier les besoins, il est important de mener une étude de l’existant, ce qui
est une étape majeure pour réaliser notre site web. Pour notre étude, deux tâches doivent
être abordées :
2.2.1 Présentation de l’existant
Le système d’information doit actuellement être automatisé pour poursuivre le développ-
ement technologique et améliorer la production de services. Dans notre cas, la communi-
cation entre les différents acteurs est un problème très important. Plusieurs problèmes
caractérisent la gestion actuelle de l’information et de la communication entre les acteurs.
Parmi ces problèmes, nous pouvons citer : L’absence d’une plate-forme numérique et in-
formatique qui s’adapte aux nouvelles technologies. De plus, les informations des clients
sont traitées manuellement, ce qui entraı̂ne une perte d’informations. En fait, cette société
est connue comme une entreprise avec de nombreuses ressources. Le stockage des données
devient chaque jour plus fragile et plus important.
2.2.2 Critiques de l’existant
La critique de l’existant fournit une étape nécessaire importante. Son objectif est d’ex-
primer une opinion pour développer tout défaut existant dans le système actuel afin de
proposer un système plus fiable que l’ancien. A partir des observations que nous avons vues
dans notre entreprise, nous avons distingué des problèmes suivants :
• Problème de réalisation des informations sur les services disponibles.
• L’utilisation de documents dans l’entreprise peut ralentir le travail et cela nous
donne un faible rendement.
• L’absence d’une application web ne peut pas mettre en valeur l’entreprise sur le
marché.
• Problème de connaı̂tre l’emplacement de l’agence.
• Perte de temps dans l’administration due à l’utilisation de documents.
26

28. Chapiter 2 : Spécifications des besoins
2.3 Besoins Fonctionnels
Dans cette partie, nous définissons les spécifications des exigences qui sont le point de
départ de notre projet, l’application fournit des services en fonction des profils d’utilisateurs
et des différents traitements nécessaires pour effectuer les tâches qui assureront les objectifs
de l’application.
2.3.1 Diagramme De contexte Statique
Figure 2.1: Diagramme De contexte Statique
2.3.2 Liste Des Besoins Fonctionnels
Visiteur :
• Consulter membre.
• Consulter .
• Consulter service.
• Consulter client.
• Consulter .
• Contacter.
Membre :
• S’authentifier.
27

29. Chapiter 2 : Spécifications des besoins
• Gérer client.
• Gérer service.
• Gérer article.
• Consulter liste des messages.
Administrateur :
• S’authentifier.
• Gérer les membres .
• Gérer offre.
• Consulter liste des demandes.
2.3.3 Diagramme de contexte dynamique
Figure 2.2: Diagramme de contexte Dynamique
2.3.4 Description Des cas d’utilisation
Les diagrammes de cas d’utilisation sont des diagrammes UML qui sont utilisés pour
donner un aperçu global des fonctionnalités du système logiciel. Le cas d’utilisation représente
une unité d’interaction distincte entre l’utilisateur (humain ou machine) et le système. Il
s’agit d’une unité de travail importante. Dans un diagramme de cas d’utilisation, les utili-
28

30. Chapiter 2 : Spécifications des besoins
sateurs sont appelés acteurs (en anglais actors )et interagissent avec les cas d’utilisation
(use cases).
2.3.4.1 Les cas d’utilisation de l’acteur visiteur
Figure 2.3: Cas d’utilisateur de l’acteur visiteur
2.3.4.2 Raffinement du cas d’utilisation consulter membre d’équipe
Figure 2.4: cas d’utilisation consulter membre d’équipe
29

31. Chapiter 2 : Spécifications des besoins
Cas d’utilisation
Consulter membre
Acteur Visiteur
Pré condition Connexion établie avec succés
Post condition — liste des membres est affiché
Description du
Scénario principal
— le visiteur clique sur le menu de la consultation des
membre
— Le système affiche l’interface des membres
— le visiteur consulte la liste des membre affichés
Exception Erreur d’affichage
Table 2.1: Description textuelle du cas d’utilisation consulter membre
2.3.4.3 Raffinement du cas d’utilisation consulter article
Figure 2.5: cas d’utilisation consulter article
Cas d’utilisation Consulter article
Acteur Visiteur
Pré condition Connexion établie avec succès
Post condition — liste des articles est affiché
Description du Scénario principal
— le visiteur clique sur le menu de la consultation des
articles
— Le système affiche l’interface des articles
— le visiteur consulte la liste des articles affichés
Exception Erreur d’affichage
Table 2.2: Description textuelle du cas d’utilisation consulter article
30

32. Chapiter 2 : Spécifications des besoins
2.3.4.4 Raffinement du cas d’utilisation consulter client
Figure 2.6: cas d’utilisation consulter client
Cas d’utilisation Consulter client
Acteur Visiteur
Pré condition Connexion établie avec succès
Post condition — liste des clients est affiché
Description du Scénario principal
— le visiteur clique sur le menu de la consultation des
Clients
— Le système affiche l’interface des Clients
— le visiteur consulte la liste des Clients affichés
Exception Erreur d’affichage
Table 2.3: Description textuelle du cas d’utilisation consulter client
2.3.4.5 Raffinement du cas d’utilisation consulter service
Figure 2.7: cas d’utilisation consulter service
31

33. Chapiter 2 : Spécifications des besoins
Cas d’utilisation Consulter service
Acteur Visiteur
Pré condition Connexion établie avec succès
Post condition — liste des services est affiché
Description du Scénario principal
— le visiteur clique sur le menu de la consultation des
services
— Le système affiche l’interface des services
— le visiteur consulte la liste des services affichés
Exception Erreur d’affichage
Table 2.4: Description textuelle du cas d’utilisation consulter service
2.3.4.6 Raffinement du cas d’utilisation consulter offre
Figure 2.8: cas d’utilisation consulter offre
Cas d’utilisation Consulter offre
Acteur Visiteur
Pré condition connexion établie avec succès
Post condition — l’opération demander et effectuée avec succès
Description du
Scénario principal
— le visiteur ouvre l’interface de l’offre
— Le système affiche l’interface des offres
— visiteur saisie les données
Exception Erreur de consulter l’offre
Table 2.5: Description textuelle du cas d’utilisation consulter offre
32

34. Chapiter 2 : Spécifications des besoins
2.3.4.7 Raffinement du cas d’utilisation contacter
Figure 2.9: cas d’utilisation contacter
Cas d’utilisation Contacter
Acteur Visiteur
Pré condition connexion établie avec succès
Post condition — l’opération demander et effectuée avec succès
Description du
Scénario principal
— le visiteur ouvre l’interface contacter
— Le système affiche l’interface
— visiteur saisie les données
Exception Erreur de contacter
Table 2.6: Description textuelle du cas d’utilisation contacter
2.3.4.8 Les cas d’utilisation de l’acteur Membre
Figure 2.10: cas d’utilisation acteur membre
33

35. Chapiter 2 : Spécifications des besoins
2.3.4.9 Raffinement du cas d’utilisation authentification membre
Figure 2.11: cas d’utilisation authentification membre
Cas d’utilisation S’authentifier
Acteur Membre
Pré condition
Login et mot de passe enregistre dans la base de Donné,
l’interface membre est affichée
Post condition authentification avec succès
Description du
Scénario principal
- membre doit saisir son login et son mot de passe
pour accéder autres Tâche
Exception Login ou mot de passe non trouvé
Table 2.7: Description textuelle du cas d’utilisation authfication membre
2.3.4.10 Raffinement du cas d’utilisation gérer client
Figure 2.12: cas d’utilisation consulter article
34

36. Chapiter 2 : Spécifications des besoins
Cas d’utilisation Gérer client
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de suppression
est effectuée avec succès
Description du
Scénario principal
— membre ouvre l’interface de gestion des clients
— membre choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des clients
Exception
— membre saisit des données erronées.
— membre ne valide pas la modification.
Table 2.8: Description textuelle du cas d’utilisation gérer client
2.3.4.11 Raffinement du cas d’utilisation gérer service
Figure 2.13: cas d’utilisation gérer service
Cas d’utilisation Gérer service
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de suppression
est effectuée avec succès
Description du
Scénario principal
— membre ouvre l’interface de gestion des services
— membre choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des services
Exception
— membre saisit des données erronées.
— membre ne valide pas la modification.
Table 2.9: Description textuelle du cas d’utilisation gérer service
35

37. Chapiter 2 : Spécifications des besoins
2.3.4.12 Raffinement du cas d’utilisation gérer article
Figure 2.14: cas d’utilisation gérer article
Cas d’utilisation Gérer article
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de suppression
est effectée avec succès
Description du
Scénario principal
— membre ouvre l’interface de gestion des articles
— membre choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des articles
Exception
— membre saisit des données erronées.
— membre ne valide pas la modification.
Table 2.10: Description textuelle du cas d’utilisation gérer article
2.3.4.13 Raffinement du cas d’utilisation consulter liste message
Figure 2.15: cas d’utilisation consulter liste message
36

38. Chapiter 2 : Spécifications des besoins
Cas d’utilisation Consulter liste message
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition — liste des messages est affiché
Description du
Scénario principal
— le membre clique sur le menu de la consultation des
Message
— Le système affiche l’interface des messages
— membre consulte la liste des messages affichés
Exception Erreur d’affichage
Table 2.11: Description textuelle du cas d’utilisation consulter liste message
2.3.4.14 Les cas d’utilisation de l’acteur Administrateur
Figure 2.16: cas d’utilisation acteur administrateur
2.3.4.15 Raffinement du cas d’utilisation authentification administrateur
Figure 2.17: cas d’utilisation authentification administrateur
37

39. Chapiter 2 : Spécifications des besoins
Cas d’utilisation S’authentifier
Acteur Administrateur
Pré condition
Login et mot de passe enregistre dans la base de
Donné, l’interface administrateur est affichée
Post condition authentification avec succès
Description du
Scénario principal
- l’administrateur doit saisir son login et son mot de
passe pour accéder autres taches
Exception Login ou mot de passe non trouvés
Table 2.12: Description textuelle du cas d’utilisation authentification administrateur
2.3.4.16 Raffinement du cas d’utilisation gérer membre
Figure 2.18: cas d’utilisation gérer membre
Cas d’utilisation Gérer membre
Acteur Administrateur
Pré condition L’administrateur doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de
suppression est effectuée avec succès
Description du
Scénario principal
— L’administrateur ouvre l’interface de gestion des clients
— L’administrateur choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des membre
Exception
— L’administrateur saisit des données erronées.
— L’administrateur ne valide pas la modification.
Table 2.13: Description textuelle du cas d’utilisation gérer membre
38

40. Chapiter 2 : Spécifications des besoins
2.3.4.17 Raffinement du cas d’utilisation gérer offre
Figure 2.19: cas d’utilisation gérer offre
Cas d’utilisation Gérer offre
Acteur Administrateur
Pré condition L’administrateur doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de
suppression est effectuer avec succès
Description du
Scénario principal
— L’administrateur ouvre l’interface de gestion des offres
— L’administrateur choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des offres
Exception
— L’administrateur saisit des données erronées.
— L’administrateur ne valide pas la modification.
Table 2.14: Description textuelle du cas d’utilisation gérer offre
2.3.4.18 Raffinement du cas d’utilisation consulter demande
Figure 2.20: cas d’utilisation consulter demande
39

41. Chapiter 2 : Spécifications des besoins
Cas d’utilisation Consulter liste demande
Acteur Administrateur
Pré condition L’administrateur doit être authentifié
Post condition — liste des demandes est affiché
Description du
Scénario principal
— l’administrateur clique sur le menu de la
consultation des Demandes
— Le système affiche l’interface des demandes
— l’administrateur consulte la liste des demandes affichés
Exception Erreur d’affichage
Table 2.15: Description textuelle du cas d’utilisation consulter demande
40

42. Chapiter 2 : Spécifications des besoins
2.3.5 Diagramme de cas d’utilisation générale
Figure 2.21: cas d’utilisation générale
41

43. Chapiter 2 : Spécifications des besoins
2.3.6 tableau récapitulatif
Acteur Intitulé cas utilisation Description
Consulter membre
Le visiteur consulte la liste des membres pour qu’il
explore les informations concernant le membre
Consulter article
Le visiteur consulte la liste des articles pour qu’il
explore les informations concernant les articles
Visiteur Consulter client
Le visiteur consulte la liste des clients pour qu’il
explore les informations concernant les clients
Consulter service
Le visiteur consulte la liste des services pour qu’il
explore les informations concernant les services
Consulter offre
Le visiteur consulte la liste des offres pour qu’il
explore les informations concernant les offres et
envoyer une demande
Contacter
Le visiteur peut contacter l’entreprise en
remplissant un formulaire contenant son nom,
e-mail et un message ou consulter
les coordonnés.
Gérer Client
Le membre a le droit de gérer plusieurs clients en
effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs
clients.
Il est capable de modifier un ou plusieurs clients
de la liste.
-Il est capable de supprimer un ou
plusieurs clients de la liste.
Membre Gérer Service
Le membre a le droit de gérer plusieurs clients en
effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs clients.
Il est capable de modifier un ou plusieurs clients
de la liste.
-Il est capable de supprimer un ou plusieurs
clients de la liste.
42

44. Chapiter 2 : Spécifications des besoins
Gérer Article
Le membre a le droit de gérer plusieurs clients en
effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs clients.
Il est capable de modifier un ou plusieurs clients
de la liste.
-Il est capable de supprimer un ou plusieurs
clients de la liste.
Consulter liste mes-
sage
Le membre consulte les messages envoyés par
le visiteur et peut répondre par mail.
Gérer membre
L’administrateur a le droit de gérer
plusieurs membres en effectuant des différentes
opérations :
-Il est capable d’ajouter un ou plusieurs membres.
Il est capable de modifier un ou plusieurs
membres de la liste.
-Il est capable de supprimer un ou
plusieurs membres de la liste.
Administrateur Gérer offre
L’administrateur a le droit de gérer plusieurs
offres en effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs offres.
-Il est capable de modifier un ou plusieurs offres
de la liste.
-Il est capable de supprimer un ou plusieurs offres
de la liste.
Consulter demande
Il consulte la liste des demandes par le visiteur,
dans ce cas l’administrateur peut accepter ou
refuser une demande selon des conditions.
Table 2.16: tableau récapitulatif
2.4 Besoins non fonctionnels
Ces besoins ne sont pas spécifiquement liés au comportement du système mais définissent
plutôt les contraintes internes et externes du système. Les principaux besoins non fonc-
tionnels de l’application peuvent être résumés dans les points suivants :
• La rapidité de traitements :En effet, il est impératif que la durée des traitements
soit effectuée au plus près du temps réel. . .
43

45. Chapiter 2 : Spécifications des besoins
• La performance : L’application doit être performance, c’est-à-dire elle doit répondre
aux besoins de tous les utilisateurs de manière optimale grâce à ses fonctionnalités.
• La disponibilité : L’application doit être disponible à tout moment pour tout uti-
lisateur et doit être facilement accessible depuis n’importe quel ordinateur connecté
à Internet.
• La convivialité : L’application doit être facile à utiliser. Les interfaces utilisateur
doivent être conviviale, pratiques et s’adaptent aux attentes de l’utilisateur.
• La sécurité : Il est difficile de prétendre avoir une sécurité des logiciels informa-
tiques à 100
2.5 Conclusion
À partir de ce chapitre, nous avons présenté une étude de l’existant, puis nous avons
des descriptions détaillées des différents cas d’utilisation en fournissant des scénarios pour
les cas des différents acteurs. Le chapitre suivant traite de l’analyse de différents cas d’uti-
lisation.
44

46. Chapitre 3
Analyse
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Présentation de la démarche du modèle d’analyse . . . . . . . 46
3.3 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Analyse du cas d’utilisation S’authentification . . . . . . . . . . 47
3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visi-
teur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visi-
teur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Vi-
siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’acteur
’Administrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1 Introduction
Dans ce chapitre, nous présenterons une analyse à travers le diagramme de collabo-
ration, qui nous permet de décrire les interactions entre les objets impliqués dans la
45

47. Chapiter 3 : Analyse
réalisation du scénario d’un cas d’utilisation, et de représenter les interactions entre les
classes. Nous avons tenté d’analyser certains cas d’utilisation en déterminant la traçabilité
entre les différents cas d’utilisation et le modèle d’analyse. Nous avons également essayé
de déterminer les différents diagrammes de collaboration afin de mieux comprendre le flux
de chaque cas d’utilisation.
3.2 Présentation de la démarche du modèle d’analyse
Il existe trois classes d’analyse :
• Interface : La classe d’interface est les classes qui permettent à l’acteur d’interagir
avec le système.Ce sont les écrans proposés à l’utilisateur.
• Entité : La classe d’entité représente les informations et le comportement du champ
d’application.
• Contrôle : La classe de contrôle agit comme un connecteur entre les classes d’in-
terface et les classes d’entité.
Diagramme de traçabilité : Ce modèle représente les différentes interfaces,commandes
et entités impliques dans l’exécution d’un cas d’utilisation, il permet la transition du modèle
du cas d’utilisation au modèle d’analyse.
Diagramme de collaboration : c’est un diagramme d’interaction organisé entre les
rôles qui interagissent et les liens qui les assemblent. Il expose les relations entre les objets
jouant les différents rôles. Cependant, le diagramme de collaboration ne doit contenir aucun
concept du temps.
46

48. Chapiter 3 : Analyse
3.3 Analyse des cas d’utilisation
3.3.1 Analyse du cas d’utilisation S’authentification
3.3.1.1 Analyse du cas d’utilisation ”s’authentifier” de l’acteur ’administra-
teur’
Figure 3.1: diagramme de traçabilité entre le modèle de cas d’utilisation ”s’authentifier”
et le modèle analyse
3.3.1.2 Digramme de collaboration du cas ”s’authentifier”
Figure 3.2: digramme de collaboration du cas ”s’authentifier”
47

49. Chapiter 3 : Analyse
3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur
’Visiteur’
3.3.2.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Consul-
ter article” et le modèle analyse
Figure 3.3: diagramme de traçabilité entre le modèle de cas d’utilisation ”Consulter ar-
ticle” et le modèle analyse
3.3.2.2 Digramme de collaboration du cas ”consulter article”
Figure 3.4: digramme de collaboration du cas ”consulter article”
48

50. Chapiter 3 : Analyse
3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur
’Visiteur’
3.3.3.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”De-
mander offre” et le modèle analyse
Figure 3.5: diagramme de traçabilité entre le modèle de cas d’utilisation ”Demander offre”
et le modèle analyse
3.3.3.2 Digramme de collaboration du cas ”Demander Offre”
Figure 3.6: digramme de collaboration du cas ”Demander Offre”
49

51. Chapiter 3 : Analyse
3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur
’Visiteur’
3.3.4.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer
Message” et le modèle analyse
Figure 3.7: diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Mes-
sage” et le modèle analyse
3.3.4.2 Digramme de collaboration du cas ”Demander Offre”
Figure 3.8: digramme de collaboration du cas ”Envoyer Message”
50

52. Chapiter 3 : Analyse
3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur
’Membre’
3.3.5.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter
Client” et le modèle analyse
Figure 3.9: diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client”
et le modèle analyse
3.3.5.2 Digramme de collaboration du cas ”Ajouter Client”
Figure 3.10: digramme de collaboration du cas ”Ajouter Client”
51

53. Chapiter 3 : Analyse
3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur
’Membre’
3.3.6.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Modi-
fier Service” et le modèle analyse
Figure 3.11: diagramme de traçabilité entre le modèle de cas d’utilisation ”Modifier Ser-
vice” et le modèle analyse
3.3.6.2 Digramme de collaboration du cas ”Modifier Service”
Figure 3.12: digramme de collaboration du cas ”Modifier Service”
52

54. Chapiter 3 : Analyse
3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’ac-
teur ’Administrateur’
3.3.7.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Sup-
primer Membre” et le modèle analyse
Figure 3.13: diagramme de traçabilité entre le modèle de cas d’utilisation ”Supprimer
Membre” et le modèle analyse
3.3.7.2 Digramme de collaboration du cas ”Supprimer Membre”
Figure 3.14: digramme de collaboration du cas ”Supprimer Membre”
53

55. Chapiter 3 : Analyse
3.4 Conclusion
Au cours de ce chapitre, Nous avons essayé d’analyser les Cas d’utilisation pour Déterminer
la traçabilité entre les cas d’utilisation et le modèle d’analyse. Nous avons aussi essayé de
définir des diagrammes de collaboration pour mieux comprendre le flux de chaque cas
d’utilisation. Nous pouvons maintenant passer au chapitre 4 pour fournir une conception
détaillée de ce projet.
54

56. Chapitre 4
Conception
Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Présentation de la démarche du modèle de conception . . . . 56
4.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . 57
4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’acteur ’Ad-
ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur
’Visiteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.3 Conception du cas d’utilisation ” envoyer message” de l’acteur
’Visiteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.5 Conception du cas d’utilisation ” modifier service” de l’acteur
’Membre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Diagramme de classe général . . . . . . . . . . . . . . . . . . . 68
4.4.1 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . 68
4.5 Modèles de paquetages et de déploiement . . . . . . . . . . . . 68
4.5.1 Modèles de paquetages . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
55

57. Chapiter 4 : Conception
4.1 Introduction
La conception est un élément important de la préparation de notre application. Nous
devons élaborer un plan qui examine diverses options de conception et de réalisation.
Dans ce chapitre, Nous fournissons une conception détaillée en utilisant le diagramme de
séquence et le diagramme de classe de conception.
4.2 Présentation de la démarche du modèle de concep-
tion
L’étude conceptuelle a besoin des moyens de déplacer le modèle sur lequel nous allons
travailler,
Les diagrammes de séquence : Les diagrammes de séquence sont utilisés pour
illustrer les cas d’utilisation.Ils laissent de montrer la séquence verticale des messages passés
entre objets au sein d’une interaction.
Diagramme de classe :Le diagramme de classes montrer la structure statique du
système en termes de classes et de relations entre ces classes. L’intérêt du diagramme de
classes est la modélisation des entités du système d’information. Le diagramme de classes
est utilisé pour représenter toutes les informations finales gérées par le domaine.
56

58. Chapiter 4 : Conception
4.3 Conception des cas d’utilisation
4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’ac-
teur ’Administrateur’
4.3.1.1 Diagramme de traçabilité du cas d’utilisation ”s’authentifier” de l’ac-
teur ’Administrateur’ entre le modèle d’analyse et le modèle de concep-
tion
Figure 4.1: Diagramme de traçabilité du cas d’utilisation ”s’authentifier”
57

59. Chapiter 4 : Conception
4.3.1.2 Diagramme de séquence relative au cas d’utilisation ”s’authentifier”
de l’acteur ’Administrateur’
Figure 4.2: Diagramme de séquence relative au cas d’utilisation ”s’authentifier”
4.3.2 Conception du cas d’utilisation ” Consulter article ” de
l’acteur ’Visiteur’
4.3.2.1 Diagramme de traçabilité du cas d’utilisation ”consulter article” de
l’acteur ’visiteur’ entre le modèle d’analyse et le modèle de conception
Figure 4.3: Diagramme de traçabilité du cas d’utilisation ”consulter article”
58

60. Chapiter 4 : Conception
4.3.2.2 Diagramme de séquence relative au cas d’utilisation ”Consulter ar-
ticle” de l’acteur ’visiteur’
Figure 4.4: Diagramme de séquence relative au cas d’utilisation ”consulter article”
4.3.3 Conception du cas d’utilisation ” envoyer message” de l’ac-
teur ’Visiteur’
4.3.3.1 Diagramme de traçabilité du cas d’utilisation ”envoyer message” de
l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception
Figure 4.5: Diagramme de traçabilité du cas d’utilisation ”envoyer message”
59

61. Chapiter 4 : Conception
4.3.3.2 Diagramme de séquence relative au cas d’utilisation ”envoyer mes-
sage” de l’acteur ’visiteur’
Figure 4.6: Diagramme de séquence relative au cas d’utilisation ”envoyer message”
60

62. Chapiter 4 : Conception
4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’ac-
teur ’Membre’
4.3.4.1 Diagramme de traçabilité du cas d’utilisation ”ajouter client” de l’ac-
teur ’Membre’ entre le modèle d’analyse et le modèle de conception
Figure 4.7: Diagramme de traçabilité du cas d’utilisation ”ajouter client”
61

63. Chapiter 4 : Conception
4.3.4.2 Diagramme de séquence relative au cas d’utilisation ”ajouter client”
de l’acteur ’Membre’
Figure 4.8: Diagramme de séquence relative au cas d’utilisation ”ajouter client”
62

64. Chapiter 4 : Conception
4.3.5 Conception du cas d’utilisation ” modifier service” de l’ac-
teur ’Membre’
4.3.5.1 Diagramme de traçabilité du cas d’utilisation ”modifier service” de
l’acteur ’Membre’ entre le modèle d’analyse et le modèle de conception
Figure 4.9: Diagramme de traçabilité du cas d’utilisation ”modifier service”
63

65. Chapiter 4 : Conception
4.3.5.2 Diagramme de séquence relative au cas d’utilisation ”modifier service”
de l’acteur ’Membre’
Figure 4.10: Diagramme de séquence relative au cas d’utilisation ”modifier service”
]Conception du cas d’utilisation ” supprimer membre” de l’acteur ’Administrateur’
64

66. Chapiter 4 : Conception
4.3.5.3 Diagramme de traçabilité du cas d’utilisation ”supprimer membre”
de l’acteur ’Administrateur’ entre le modèle d’analyse et le modèle de
conception
Figure 4.11: Diagramme de traçabilité du cas d’utilisation ”supprimer membre”
4.3.5.4 Diagramme de séquence relative au cas d’utilisation ”supprimer membre”
de l’acteur ’Administrateur’
Figure 4.12: Diagramme de séquence relative au cas d’utilisation ”supprimer membre”
65

67. Chapiter 4 : Conception
]Conception du cas d’utilisation ”demander offre” de l’acteur ’Visiteur’
4.3.5.5 Diagramme de traçabilité du cas d’utilisation ”demander offre” de
l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception
Figure 4.13: Diagramme de traçabilité du cas d’utilisation ”demander offre”
66

68. Chapiter 4 : Conception
4.3.5.6 Diagramme de séquence relative au cas d’utilisation ”demander offre”
de l’acteur ’Visiteur’
Figure 4.14: Diagramme de séquence relative au cas d’utilisation ”demander offre”
67

69. Chapiter 4 : Conception
4.4 Diagramme de classe général
4.4.1 Diagramme de classe général
Figure 4.15: Diagramme de classe général
4.5 Modèles de paquetages et de déploiement
4.5.1 Modèles de paquetages
Un paquetage est un regroupement de classes dont il règle les visibilités. Le contexte
d’un paquetage permet de définir des notions et des propriétés spécifiques du domaine
(noms, types, constantes, etc.). Les paquetages permettent de présenter une vue synthétique
68

70. Chapiter 4 : Conception
du modèle. De même qu’une classe est la représentation d’un concept, un paquetage est
la représentation d’un domaine. Un paquetage peut être considère comme la spécification
d’un domaine Particulier
4.5.2 Modèles de déploiement
Un diagramme de déploiement est un diagramme de classe ou un diagramme d’ob-
jet représentant les nœud ou les instances de nœud sur lequel le système s’exécute. Il
propose une vision statique de la topologie du matériel s’exécute le système. Diagramme
de déploiement montre les associations(connexion) existant ente nœud du système.Il ne
montre pas les interactions entre le nœud
4.6 Conclusion
Dons ce chapitre, Représente le processus de conception de notre application . D’abord
en commençant par une architecture globale pour atteindre une conception détaille, en
définir plusieurs diagrammes de conception. Le derniér chapitre sera concerné pour l’implémentation
du projet ou la réalisation
69

71. Chapitre 5
Implémentation
Sommaire
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Environnement de développement . . . . . . . . . . . . . . . . 71
5.2.1 Environnement de développement . . . . . . . . . . . . . . . . . 71
5.2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Description de l’application . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . 72
5.3.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . 72
5.3.3 Présentation de l’interface ’contacter’ : . . . . . . . . . . . . . . . 73
5.3.4 Présentation de l’interface ’liste membre’ : . . . . . . . . . . . . . 73
5.3.5 Présentation de l’interface ’ajouter client’ : . . . . . . . . . . . . 74
5.3.6 Présentation de l’interface ’gérer client’ : . . . . . . . . . . . . . . 74
5.3.7 Présentation de l’interface ’liste des messages’ : . . . . . . . . . . 75
5.1 Introduction
Dans ce derniér chapitre nous présentons la phase de réalisation qui a pour objectif d’ex-
poser le travail achevé. Nous présentons tout d’abord l’environnement de développement on
va voir l’environnement logiciel et matière utilisée pour développer l’application demandée.
par la suite , Nous présentons des interfaces de l’application et scenario de réalisation.
70

72. Chapiter 5 : Implémentation
5.2 Environnement de développement
Pendant la phase de développement de notre application, nous avons utilisé un ensemble
d’outils et moyens techniques qui constituent l’environnement général de travail. Il peut
être diviser en deux types : un environnement matériel et un environnement logiciel. Ci-
dessous, nous allons écrire et séparer chacun d’eux.
5.2.1 Environnement de développement
5.2.2 Environnement matériel
L’application est développée sur un ordinateur portable avec les caractéristiques sui-
vantes :
Marque Asus
Processeur Intel(R) Core(TM)i3
RAM 8,00 Go
Carte Graphique Intel(R) HD Graphics 520
Disque Dur 1 TB
Système D’exploitation Windows 10 professionnelle64 bits
5.3 Description de l’application
Dans cette partie, nous allons présenter les interfaces les plus importantes de notre
application tout en en expliquant leurs utilités et leurs fonctionnements.
71

73. Chapiter 5 : Implémentation
5.3.1 Présentation de l’interface ’s’authentifier’ :
Figure 5.1: Présentation de l’interface ’s’authentifier’ :
5.3.2 Présentation de l’interface ’page d’accueil’
Figure 5.2: Présentation de l’interface ’page d’accueil’
72

74. Chapiter 5 : Implémentation
5.3.3 Présentation de l’interface ’contacter’ :
Figure 5.3: Présentation de l’interface ’contacter’
5.3.4 Présentation de l’interface ’liste membre’ :
Figure 5.4: Présentation de l’interface ’liste membre’
73

75. Chapiter 5 : Implémentation
5.3.5 Présentation de l’interface ’ajouter client’ :
Figure 5.5: Présentation de l’interface ’ajouter client’
5.3.6 Présentation de l’interface ’gérer client’ :
Figure 5.6: Présentation de l’interface ’gérer client’
74

76. Chapiter 5 : Implémentation
5.3.7 Présentation de l’interface ’liste des messages’ :
Figure 5.7: Présentation de l’interface ’liste des messages’
75

77. Conclusion générale et perspectives
A la fin de notre formation licence informatique, nous avons été capable de réaliser un
Projet de fin d’année. Notre travail est basé sur le développement d’une application web.
Cela nous a conduit à découvrir une nouvelle plateforme de développement. J’ai passé deux
mois dans les locaux du Optans ou j’ai participé aux différentes phases du projet, de la
détermination des exigences aux tests d’admission en utilisant la méthodologie Cascade.
Pendant la période du stage, Je me suis familiarisé avec la conception de systèmes d’in-
formation et le développement en utilisant les nouvelles technologies web. Finalement, Ce
travail peut être améliorér en effectuant certaines tâches supplémentaires que nous n’avons
pas pu terminer faute de temps.
76

78. Annexe 1
NodeJs :
NodeJS est une plateforme construite sur le moteur JavaScript V8 de Chrome qui permet
de développer des applications en utilisant du JavaScript. Il se distingue des autres
plateformes grâce à une approche non bloquante permettant d’effectuer des
entrées/sorties (I/O) de manière asynchrone. [2]
ExpressJs
ExpressJS est une librairie qui vous permettra de créer une application Web plus
simplement qu’avec l’objet http directement. Elle fournit un ensemble de méthode
permettant de traiter les requêtes HTTP et fournit un système de middleware pour
étendre ses fonctionnalités. [3]
MongoDB
MongoDB est base de données de documents, ce qui signifie qu’elle stocke les données au
format de documents JSON. Nous estimons qu’il s’agit de la façon la plus naturelle
d’envisager les données, bien plus efficace et expressive que le modèle traditionnel basé
sur des rangées et des colonnes. [4]

79. Handlebars.Js
Handlebars.js est un langage de Template populaire et très puissant, simple à utiliser et
dispose d’une grande communauté. Il est basé sur le langage de Template Moustache,
tout en ajoutant plusieurs améliorations importantes. Avec Handlebars, vous pouvez
séparer la génération de votre HTML du reste de votre code JavaScript ce qui permet
d’avoir un code plus propre. [5]
HTML5
Le HTML5 est un langage de base pour la création de site internet, il sert à structurer
vote document. D’autre langage peuvent s’ajouter lors de la conception, mais tous les
sites web contiennent du HTML. HTML5 désignant la version du langage HTML.[6]
CSS3
Le terme CSS est l’acronyme anglais de Cascading Style Sheets qui peut se traduire par
”feuilles de style en cascade”. Le CSS est un langage informatique utilisé sur l’internet
pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appelé
les fichiers CSS, comprennent du code qui permet de gérer le design d’une page en
HTML. [7]

80. Bootstrap
Bootstrap est un framework développé par l’équipe du réseau social Twitter. Proposé en
open source (sous licence MIT), ce framework utilisant les langages HTML, CSS et
JavaScript fournit aux développeurs des outils pour créer un site facilement. Ce
framework est pensé pour développer des sites avec un design responsive, qui s’adapte à
tout type d’écran, et en priorité pour les smartphones. Il fournit des outils avec des styles
déjà en place pour des typographies, des boutons, des interfaces de navigation et bien
d’autres encore. On appelle ce type de framework un ”Front-End Framework”. [8]

81. Références
[1] https ://fr.wikipedia.org/wiki/CycleenV
[2] https ://www.grafikart.fr/tutoriels/nodejs-intro-792
[3] https ://www.grafikart.fr/tutoriels/express-798
[4] https ://www.mongodb.com/fr
[5] https ://www.supinfo.com/articles/single/2831-handlebars
[6] http ://41mag.fr/
[7] http ://glossaire.infowebmaster.fr/css/
[8] https ://www.journaldunet.com/web-tech/developpeur/1159810-bootstrap-definition-
tutoriels-astuces-pratiques

82. Résumé
Ce projet a été élaboré dans le cadre du projet de fin d’études en vue
de l’obtention du diplôme de la licence fondamentale en Sciences de
l’informatique. Il a été destiné à l’étude, la conception et la réalisation
d’une application Web au profit du Optans une société du Technolo-
gies et services de l’information . Ä Pour accomplir ce travail, nous
avons choisi comme langage de modélisation le formalisme UML. En
fait, notre choix est prouvé par rapport à sa clarté et sa perfor-
mance en matière de conception. Ä la réalisation de notre applica-
tion nécessite l’utilisation de ” MongoDb ” comme serveur de base de
données. De plus pour la conception des interfaces, nous avons choisi
les langages de programmation Html, Css, javascript