Remerciements

Après avoir rendu grâce à Dieu le tout puissant et le bienveillant, nous tenons à
remercier vivement tous ceux qui de près ou de loin ont participé à la réalisation
de ce projet.
Nous voudrons citer plus particulièrement :
Docteur Ahmed HADDAD, encadrant académique à l’institut supérieur de
gestion de Sousse pour sa disponibilité, sa rigueur scientifique et son sens de
l’écoute et d’échange.
Tout le corps professionnel du groupe EDUCANET Tunisie qui nous a bénéficié
d’un stage de très haut niveau et très adapté aux réalités de l’informatique de
gestion dans la vie professionnelle.
Nous tenons aussi à les remercier pour leur honnêteté qui nous a permis de
progresser et d’apprendre énormément, et nous voudrons bien citer
particulièrement :
Monsieur Hamda HMISSA ingénieur et encadrant professionnel au sein du
groupe EDUCANET Tunisie.
Docteur Anis BEN ARBIA directeur stratégique du groupe EDUCATET
Tunisie.
Monsieur Achref BEN ARBIA directeur exécutif du groupe EDUCANET
Tunisie.

1
 Dédicaces
À mon exemple éternel, mon soutien moral et source de ma joie et de mon
bien être, celui qui s’est toujours sacrifié pour me voir grandir et
réussir, que Dieu le tout puissant te garde et te donne tout le bonheur
du monde
À toi mon cher père HASSEN.
A la lumière de mes jours, la source de mes efforts qu’aucune dédicace
ne saurait exprimer mon respect, mon amour éternel et ma considération
pour les sacrifices que tu as consenti pour mon bien être
À toi ma chère mère.
À mon cher frère AHMED et mes deux sœurs SAFA et IMEN.
À toutes les personnes qui étaient toujours à mes côtés pour me
conseiller et m’encourager à tous ceux qui m’ont aidé et soutenu de près
ou de loin.

MAROUA LETAIEF

2
Dédicaces

3
 Tale des matières
Introduction générale............................................................................................................................ 16
Chapitre I : Contexte de travaille & étude préalable ....................................................................... 18
Introduction........................................................................................................................................... 18
............................................................................................................................................................... 18
I Contexte de travail ........................................................................................................................ 19
1 Présentation de la société ............................................................................................................. 19
Figure 1 : logo de la société Educanet ................................................................................................... 19
2 Quelque activités d’Educanet........................................................................................................ 19
3 Structure de la société................................................................................................................... 20
Figure 2 : L’organigramme du service technique .................................................................................. 20
4 Technologie utilisée....................................................................................................................... 20
5 Fiche technique ............................................................................................................................. 20
Tableau 1 : fiche technique de la société Educanet............................................................................... 20
II Etude préalable ............................................................................................................................. 21
1 Gestion électronique de document « GED » ................................................................................. 21
1.1 Définition de GED .................................................................................................................. 21
1.2 Cycle de vie d’un document .................................................................................................. 21
Figure 3 : les étapes de cycle de vie d’un document électronique ......................................................... 21
2 Gestion de document électronique « GDE » ................................................................................. 22
2.1 Définition de document ........................................................................................................ 22
3 Présentation de projet .................................................................................................................. 22
Figure 4 : Image descriptive .................................................................................................................. 22
4 Cahier de charge............................................................................................................................ 23
4.1 Etude de l’existant ................................................................................................................. 23
4.1.1 Analyse de l’existant ...................................................................................................... 23
Tableau 2 : Les GED existants ................................................................................................................ 23
4.1.2 Critique de l’existant ..................................................................................................... 24
Tableau 3 : Critique des GED existants .................................................................................................. 25
4.2 Spécification des besoins ...................................................................................................... 25
4.2.1 Les besoins fonctionnels................................................................................................ 25
4.2.2 Les besoins non fonctionnels ........................................................................................ 26
4.3 Architecture envisagée .......................................................................................................... 27
Figure 5 : Architecture 3 tiers ................................................................................................................ 27

4
5 Planning des taches ....................................................................................................................... 28
5.1 Définition de diagramme de GANNT ..................................................................................... 28
5.2 Présentation de diagramme de GANTT ................................................................................. 28
Figure 6 : Diagramme de GANTT ........................................................................................................... 29
Conclusion ............................................................................................................................................. 29
Chapitre II : Elaboration .................................................................................................................... 31
Introduction........................................................................................................................................... 31
I Méthode et outil de modélisation choisis..................................................................................... 32
1 Choix de la méthodologie de conception adopte ......................................................................... 32
1.1 Choix de cycle de vie logiciel ................................................................................................. 32
Figure 7 : ................................................................................................................................................ 32
1.2 Choix de méthode de conception ......................................................................................... 33
Figure 8 : Logo UML.............................................................................................................................. 33
2 Outil de modélisation .................................................................................................................... 34
II Modèle de domaine (diagramme de cas d’utilisation) ................................................................. 34
1 Description .................................................................................................................................... 34
2 Identification des acteurs du système .......................................................................................... 35
Figure 9 : Diagramme de classe des acteurs ......................................................................................... 35
3 Diagramme de processus métier .................................................................................................. 36
Figure 10 : diagramme de processus métier ......................................................................................... 36
4 Identification de cas d’utilisation de système ............................................................................... 36
Tableau 4 : Principales fonctionnalités offertes par le système ............................................................ 37
5 Spécification de cas d’utilisation ................................................................................................... 37
5.1 Cas d’utilisation « Authentification » .................................................................................... 37
Figure 11 : Raffinement de cas d’utilisation « Authentification » ......................................................... 37
Table 1 : Scénario de cas d’utilisation « Authentification » .................................................................. 38
5.2 Cas d’utilisation « Gérer utilisateur » .................................................................................... 38
5.2.1 Raffinement de cas d’utilisation « Gérer utilisateur » .................................................. 38
Figure 12 : Raffinement de cas d’utilisation « Gérer utilisateur » ......................................................... 38
Table 2 : Scénario de cas « Ajouter utilisateur » ................................................................................... 39
Table 3 : Table 3 : Scénario de cas « Modifier utilisateur » ................................................................... 40
Table 4 : Scénario de cas « Consulter utilisateur » ................................................................................ 40
Table 5 : Scénario de cas « Rechercher utilisateur » ............................................................................. 41
Table 6 : Scénario de cas « Supprimer utilisateur »............................................................................... 42
5.2.2 Diagramme de modèle de domaine « Gérer utilisateur » ............................................ 42
Figure13 : Diagramme de modèle de domaine « gérer utilisateur » .................................................... 42

5
 5.3 Cas d’utilisation « Gérer rôle » .............................................................................................. 43
5.3.1 Raffinement de cas d’utilisation « Gérer rôle » ............................................................ 43
Figure 14 : raffinement de cas d’utilisation « gérer rôle » .................................................................... 43
Table 7 : Scénario de cas « Ajouter rôle » ............................................................................................. 44
Table 8 : Scénario de cas « Modifier rôle »............................................................................................ 44
Table 9 : Scénario de cas « Consulter rôle » .......................................................................................... 44
Table 10 : Scénario de cas « Supprimer rôle » ....................................................................................... 45
5.3.2 Diagramme de modèle de cas d’utilisation « Gérer rôle »............................................ 45
Figure 15 : Diagramme de modèle de domaine « gérer Rôle » ............................................................. 45
5.4 Cas d’utilisation « Gérer département » ............................................................................... 46
5.4.1 Raffinement de cas d’utilisation « Gérer département » ............................................. 46
Figure 16 : Raffinement de cas d’utilisation « Gérer département » .................................................... 46
Table 11 : Scénario de cas « Ajouter Département » ............................................................................ 46
Table 12 : Scénario de cas « Modifier département » ........................................................................... 47
Table 13 : Scénario de cas « Consulter département » ......................................................................... 47
Table 14 : Scénario de cas « Supprimer département » ........................................................................ 48
5.4.2 Diagramme de modèle de domaine de cas d’utilisation « Gérer département » ........ 48
Figure17 : Diagramme de modèle de domaine « gérer département »................................................ 48
5.5 Cas d’utilisation « Gérer document » .................................................................................... 50
5.5.1 Raffinement de cas d’utilisation « Gérer document » .................................................. 50
Figure 18 : raffinement de cas d’utilisation « Gérer document » .......................................................... 50
Table 15 : Scénario de cas « Ajouter document » ................................................................................. 51
Table 16 : Scénario de cas « Modifier document »................................................................................ 52
Table 17 : Scénario de cas « Consulter document » .............................................................................. 52
Table 18 : Scénario de cas « Archiver document » ................................................................................ 53
Table 19 : Scénario de cas « Envoyer document » ................................................................................ 53
Table 20 : Scénario de cas « Rechercher document » ........................................................................... 53
Table 21 : Scénario de cas « Télécharger document » .......................................................................... 54
5.5.2 Diagramme de modèle de domaine de cas d’utilisation « Gérer document » ............. 55
Figure 19 : Diagramme de modèle de domaine « gérer document ».................................................... 55
5.6 Diagramme de modèle de domaine générale ....................................................................... 55
Figure 20 : Diagramme de modèle de domaine générale ..................................................................... 55
Conclusion ............................................................................................................................................. 55
Chapitre III : Analyse & conception .................................................................................................... 57
Introduction........................................................................................................................................... 57
I Analyse .......................................................................................................................................... 58

6
1 Modèle d’analyse .......................................................................................................................... 58
1.1 Analyse de cas d’utilisation « Gérer utilisateur » .................................................................. 58
1.1.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « gérer utilisateur » ................................................................................................... 58
Figure 21 : traçabilité de cas d’utilisation « Gérer utilisateur » ............................................................ 58
1.1.2 Diagramme de classe d’analyse de cas d’utilisation « Gérer utilisateur » .................... 59
Figure 22 : Diagramme de cas d’analyse de cas d’utilisation « gérer utilisateur » ............................... 59
1.2 Analyse de cas d’utilisation « Gérer rôle » ............................................................................ 60
1.2.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « Gérer rôle » ............................................................................................................ 60
Figure 23 : traçabilité de cas d’utilisation « gérer rôle » ....................................................................... 60
1.2.2 Diagramme de classe d’analyse de cas d’utilisation « Gérer rôle » .............................. 61
Figure 24 : Diagramme de classe d’analyse de cas d’utilisation « gérer rôle »..................................... 61
1.3 Analyse de cas d’utilisation « Gérer département » ............................................................. 62
1.3.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « Gérer département » ............................................................................................. 62
Figure 25 : traçabilité de cas d’utilisation « gérer département » ........................................................ 62
1.3.2 Diagramme de classe d’analyse du cas d’utilisation « Gérer département » ............... 63
Figure 26 : Diagramme de classe d’analyse de cas d’utilisation « Gérer département » ..................... 63
1.4 Analyse de cas d’utilisation « Gérer document » .................................................................. 64
1.4.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « Gérer document » .................................................................................................. 64
Figure 27 : traçabilité de cas d’utilisation « gérer document » ............................................................. 64
1.4.2 Diagramme de classe d’analyse du cas d’utilisation « Gérer document » .................... 65
Figure 28 : Diagramme de classe d’analyse de cas d’utilisation « Gérer document » .......................... 65
2 Modèle de domaine (diagramme de classe) ................................................................................. 66
2.1 Définition ............................................................................................................................... 66
2.2 Présentation de diagramme de classe .................................................................................. 67
Figure 29 : Diagramme de classe .......................................................................................................... 67
2.3 Identification d’association ................................................................................................... 68
II Conception .................................................................................................................................... 68
1 Diagramme d’activité système ...................................................................................................... 68
1.1 Définition de diagramme d’activité système ........................................................................ 68
1.2 Présentation de diagramme d’activité de système ............................................................... 69
1.2.1 Diagramme d’activité système de cas d’utilisation « Authentification » ...................... 69
Figure 30 : diagramme d’activité système « Authentification » ........................................................... 69
1.2.2 Cas d’utilisation « Gérer utilisateur » ............................................................................ 70

7
 1.2.2.1 Diagramme d’activité système de cas d’utilisation « Ajouter utilisateur »............... 70
Figure 31 : diagramme d’activité système « Ajouter utilisateur » ........................................................ 70
1.2.2.2 Diagramme d’activité système de cas d’utilisation « Modifier utilisateur » ............. 71
Figure 32 : diagramme d’activité système « Modifier utilisateur » ...................................................... 71
1.2.2.3 Diagramme d’activité système de cas d’utilisation « Supprimer/Archiver utilisateur »
72
Figure 33 : diagramme d’activité système « Supprimer / Archiver utilisateur » ................................... 72
1.2.2.4 Diagramme d’activité système de cas d’utilisation « Rechercher utilisateur » ........ 73
Figure 34 : diagramme d’activité système « Rechercher utilisateur » .................................................. 73
1.2.3 Cas d’utilisation « Gérer rôle » ...................................................................................... 74
1.2.3.1 Diagramme d’activité système de cas d’utilisation « Ajouter rôle »......................... 74
Figure 35 : diagramme d’activité système « Ajouter rôle » .................................................................. 74
1.2.3.2 Diagramme d’activité système de cas d’utilisation « Modifier rôle » ....................... 75
Figure 36 : diagramme d’activité système « Modifier rôle »................................................................. 75
1.2.3.3 Diagramme d’activité système « Supprimer rôle » ................................................... 76
Figure 37 : diagramme d’activité système « Supprimer rôle » .............................................................. 76
1.2.4 Cas d’utilisation « Gérer département » ....................................................................... 77
1.2.4.1 Diagramme d’activité système de cas d’utilisation « Ajouter département ».......... 77
Figure 38 : diagramme d’activité système « Ajouter département ».................................................... 77
1.2.4.2 Diagramme d’activité système de cas d’utilisation « Modifier département » ........ 78
Figure 39 : diagramme d’activité système « Modifier département » .................................................. 78
1.2.4.3 Diagramme d’activité système de cas d’utilisation « Supprimer département » ..... 79
Figure 40 : diagramme d’activité système « Supprimer département » ............................................... 79
1.2.5 Cas d’utilisation « Gérer document » ............................................................................ 80
1.2.5.1 Diagramme d’activité système de cas d’utilisation « Ajouter document » .............. 80
Figure 41 : diagramme d’activité système « Ajouter document » ........................................................ 80
1.2.5.2 Diagramme d’activité système de cas d’utilisation « Modifier document »............. 81
Figure 42 : diagramme d’activité système « Modifier propriété d’un document » ............................... 81
1.2.5.3 Diagramme d’activité système de cas d’utilisation « Envoyer document » ............. 82
Figure 43 : diagramme d’activité système « Envoyer un document » .................................................. 82
1.2.5.4 Diagramme d’activité système de cas d’utilisation « Rechercher document » ........ 82
Figure 44 : diagramme d’activité système « Rechercher document » ...................................... 82
1.2.5.5 Diagramme d’activité système de cas d’utilisation « Télécharger document » ....... 83
Figure 45 : diagramme d’activité système « Télécharger document » ................................................. 83
2 Diagramme de séquence............................................................................................................... 83
2.1 Définition de diagramme de séquence ................................................................................. 83

8
 2.2 Le modèle utilisé MVC : Modèle Vue Contrôleur .................................................................. 84
Figure 46 : Principe de modèle MVC...................................................................................................... 84
2.3 Présentation des diagrammes de séquence ......................................................................... 86
2.3.1 Diagramme de séquence de cas d’utilisation « Authentification »............................... 86
Figure 47 : diagramme de séquence « Authentification » .................................................................... 86
2.3.2 Cas d’utilisation « Gérer utilisateur » ............................................................................ 87
2.3.2.1 Diagramme de séquence de cas d’utilisation « Ajouter utilisateur » ....................... 87
Figure 48 : diagramme de séquence « Ajouter utilisateur » ................................................................. 87
2.3.2.2 Diagramme de séquence de cas d’utilisation « Modifier utilisateur »...................... 88
Figure 49 : diagramme de séquence « Modifier utilisateur » ............................................................... 88
2.3.2.3 Diagramme de séquence de cas d’utilisation « Supprimer/Archiver utilisateur » ... 89
Figure 50 : diagramme de séquence « Supprimer / Archiver utilisateur » ............................................ 89
2.3.2.4 Diagramme de séquence de cas d’utilisation « Rechercher utilisateur » ................. 90
Figure 51 : diagramme de séquence « Rechercher utilisateur » ........................................................... 90
2.3.2.5 Diagramme de séquence de cas d’utilisation « Consulter utilisateur » .................... 90
Figure 52 : diagramme de séquence « Consulter utilisateur » .............................................................. 90
2.3.3 Cas d’utilisation « Gérer rôle » ...................................................................................... 91
2.3.3.1 Diagramme de séquence de cas d’utilisation « Ajouter rôle » ................................. 91
Figure 53 : diagramme de séquence « Ajouter rôle » ........................................................................... 91
2.3.3.2 Diagramme de séquence de cas d’utilisation « Modifier rôle »................................ 92
Figure 54 : diagramme de séquence « Modifier rôle ».......................................................................... 92
2.3.3.3 Diagramme de séquence de cas d’utilisation « Supprimer rôle »............................. 93
Figure 55 : diagramme de séquence « Supprimer rôle » ....................................................................... 93
2.3.4 Cas d’utilisation « Gérer département » ....................................................................... 94
2.3.4.1 Diagramme de séquence de cas d’utilisation « Ajouter département » .................. 94
Figure 56 : diagramme de séquence « Ajouter département »............................................................. 94
2.3.4.2 Diagramme de séquence de cas d’utilisation « Modifier département »................. 95
Figure 57 : diagramme de séquence « Modifier département » ........................................................... 95
2.3.4.3 Diagramme de séquence de cas d’utilisation « Supprimer département ».............. 96
Figure 58 : diagramme de séquence « Supprimer département » ........................................................ 96
2.3.5 Cas d’utilisation « Gérer document » ............................................................................ 97
2.3.5.1 Diagramme de séquence de cas d’utilisation « Ajouter document » ....................... 97
Figure 59 : diagramme de séquence « Ajouter document » ................................................................. 97
2.3.5.2 Diagramme de séquence de cas d’utilisation « Modifier propriété de document » 98
Figure 60 : diagramme de séquence « modifier propriété document » ................................................ 98
2.3.5.3 Diagramme de séquence de cas d’utilisation « Envoyer document » ...................... 99

9
Figure 61 : diagramme de séquence « Envoyer document »................................................................. 99
2.3.5.4 Diagramme de séquence de cas d’utilisation « Rechercher document » ................. 99
Figure 62 : diagramme de séquence « Rechercher document » ........................................................... 99
3 Diagramme de déploiement ....................................................................................................... 100
3.1 Définition de diagramme de déploiement .......................................................................... 100
3.2 Présentation de diagramme de déploiement ..................................................................... 101
Figure 63 : diagramme déploiement ................................................................................................... 101
Conclusion ........................................................................................................................................... 101
Chapitre IV : Réalisation & mise en œuvre .................................................................................. 103
Introduction......................................................................................................................................... 103
I Environnement de développement ............................................................................................ 104
1 Environnement matériel ............................................................................................................. 104
2 Environnement Logiciel ............................................................................................................... 104
2.1 Tomcat ................................................................................................................................. 104
Figure 64 : Logo Tomcat ...................................................................................................................... 104
2.2 STS (Spring Tool Suit) ........................................................................................................... 104
Figure 65 : Logo STS............................................................................................................................. 105
2.3 Plateforme de développement JEE ..................................................................................... 105
Figure 66 : Logo java j2ee.................................................................................................................... 106
2.4 Java script ............................................................................................................................ 106
Figure 67 : Logo JavaScript .................................................................................................................. 106
2.5 Spring Security ..................................................................................................................... 106
2.6 Spring ......................................................................................... Error! Bookmark not defined.
2.7 WampServer ........................................................................................................................ 107
Figure 68 : Logo WampServer ............................................................................................................. 107
2.8 MySQL.................................................................................................................................. 107
Figure 69 : Logo MYSQL....................................................................................................................... 107
2.9 Font-Awesome .................................................................................................................... 107
2.10 HTML5 ................................................................................................................................. 108
2.11 CSS3 ..................................................................................................................................... 108
Figure 71 : Logo CSS3 .......................................................................................................................... 108
2.12 JQUERY ................................................................................................................................ 108
Figure 72 : Logo JQUERY...................................................................................................................... 109
2.13 BootStrap............................................................................................................................. 109
Figure 73 : Logo Bootstrap .................................................................................................................. 109
II Création de base de données ...................................................................................................... 109

10
Figure 74 : La base de données de l'application .................................................................................. 109
III Réalisation de l’ensemble de pages ............................................................................................ 109
1 Création de la structure d’une page............................................................................................ 109
Figure 75 : La structure d’une page ..................................................................................................... 110
Conclusion ........................................................................................................................................... 113
Conclusion générale ............................................................................................................................ 128

11
 Liste des figures
Figure 1 : logo de la société Educanet...................................................................................... 19
Figure 2 : L’organigramme du service technique .................................................................... 20
Figure 3 : les étapes de cycle de vie d’un document électronique ........................................... 21
Figure 4 : Image descriptive ..................................................................................................... 22
Figure 5 : Architecture 3 tiers .................................................................................................. 27
Figure 6 : Diagramme de GANTT ........................................................................................... 29
Figure 7 : .................................................................................................................................. 32
Figure 8 : Logo UML .............................................................................................................. 33
Figure 9 : Diagramme de classe des acteurs ............................................................................ 35
Figure 10 : diagramme de processus métier ............................................................................. 36
Figure 11 : Raffinement de cas d’utilisation « Authentification » ........................................... 37
Figure 12 : Raffinement de cas d’utilisation « Gérer utilisateur » ........................................... 38
Figure13 : Diagramme de modèle de domaine « gérer utilisateur » ........................................ 42
Figure 14 : raffinement de cas d’utilisation « gérer rôle » ....................................................... 43
Figure 15 : Diagramme de modèle de domaine « gérer Rôle »................................................ 45
Figure 16 : Raffinement de cas d’utilisation « Gérer département » ...... Error! Bookmark not
defined.
Figure17 : Diagramme de modèle de domaine « gérer département » .................................... 48
Figure 18 : raffinement de cas d’utilisation « Gérer document »............................................. 50
Figure 19 : Diagramme de modèle de domaine « gérer document » ....................................... 55
Figure 20 : Diagramme de modèle de domaine générale ......................................................... 55

12
 Liste des tables
Table 1 : Scénario de cas d’utilisation « Authentification » .................................................... 38
Table 2 : Scénario de cas « Ajouter utilisateur »...................................................................... 39
Table 3 : Table 3 : Scénario de cas « Modifier utilisateur » .................................................... 40
Table 4 : Scénario de cas « Consulter utilisateur » .................................................................. 40
Table 5 : Scénario de cas « Rechercher utilisateur »................................................................ 41
Table 6 : Scénario de cas « Supprimer utilisateur » ................................................................. 42
Table 7 : Scénario de cas « Ajouter rôle » ............................................................................... 44
Table 8 : Scénario de cas « Modifier rôle » ............................................................................. 44
Table 9 : Scénario de cas « Consulter rôle » ............................................................................ 44
Table 10 : Scénario de cas « Supprimer rôle »......................................................................... 45
Table 11 : Scénario de cas « Ajouter Département » ............................................................... 46
Table 12 : Scénario de cas « Modifier département » .............................................................. 47
Table 13 : Scénario de cas « Consulter département » ............................................................ 47
Table 14 : Scénario de cas « Supprimer département » ........................................................... 48
Table 15 : Scénario de cas « Ajouter document » .................................................................... 51
Table 16 : Scénario de cas « Modifier document » .................................................................. 52
Table 17 : Scénario de cas « Consulter document » ................................................................ 52
Table 18 : Scénario de cas « Archiver document » .................................................................. 53
Table 19 : Scénario de cas « Envoyer document » .................................................................. 53
Table 20 : Scénario de cas « Rechercher document » .............................................................. 53
Table 21 : Scénario de cas « Télécharger document » ............................................................. 54

13
 Liste des tableaux
Tableau 1 : fiche technique de la société Educanet .................................................................. 20
Tableau 2 : Les GED existants ................................................................................................. 23
Tableau 3 : Critique des GED existants ................................................................................... 25
Tableau 4 : Principales fonctionnalités offertes par le système ............................................... 37

14
 Avant-propos

Cette étude entre dans le cadre de la préparation d'un mémoire de fin d'études en vue de
l'obtention du diplôme Licence Fondamental en Informatique de gestion au sein de l'institut
supérieur de gestion de Sousse. C'est ainsi que nous avons eu l'occasion de préparer notre
projet de fin d'étude intitulé : « Plateforme de gestion de document électronique ».
Ce projet est un apport très bénéfique quant au perfectionnement des connaissances de
l'étudiant dans le domaine informatique et pour avoir l'opportunité d'appliquer ses
connaissances théoriques acquises tout au long de son cursus universitaire dans le cadre
professionnel.

15
 Introduction générale

Grâce au progrès de la recherche scientifique et technologique, l’informatique n’a pas cessé

d’évoluer et de s’adapter aux besoins de l’homme. Surtout, n’oublions pas de mentionner que
l’homme devient de jour en jour dépendant de son ordinateur puisqu’il lui facilite la tâche et
l’aide avec ses divers outils à réaliser son travail avec perspectivisme et perfectionnement.
Avec l’apparition des outils de développement, de programmation et avec l’évolution des
méthodes de conception et de modélisation des systèmes d’information, l’informatique est
devenue aussi fiable et se voit intégrée dans tous les autres domaines. Les nouvelles
technologies d’information et de télécommunication deviennent indispensables dans notre
quotidien et occupent une place très importante dans notre vie vu qu’elle contribue au
développement économique, social et culturel des pays.
Dans cette perspective, et dans le cadre de notre projet de fin d’études, réalisé au sein de la
compagnie GROUP EDUCANET TUNISIE, nous sommes intéressées au développement
d’une plate-forme de gestion de gestion de document électronique.
Après avoir collecté les informations et avoir fait les études préliminaires, nous avons élaboré
notre vision de l’application, son architecture, ainsi que définir les outils et les technologies
nécessaires. Le présent document est organisé en quatre chapitres : Dans le premier nous
mettons le projet dans son contexte général. Dans le deuxième chapitre a lieu l’étude de
l’existant et la spécification des besoins. Ensuite le troisième chapitre est consacré à l’analyse
et à la conception détaillée de la future application. Dans le dernier chapitre nous présentons
l’environnement de développement utilisé suivi d’une description des interfaces réalisées.
Enfin nous achevons notre travail par une conclusion générale avec une exposition des
apports et des perspectives.

16
17
 Chapitre I : Contexte de
travaille & étude préalable

Introduction

18
 Chapitre I : Contexte & Etude préalable

Contexte de travail
1 Présentation de la société

Figure 1 : logo de la société Educanet

Educanet est une société SARL fondée en 2011 leader tunisien en développement de solusion
informatique dans le domaine de l’éducation nationale. Educanet Tunisie est spécialisée
principalement dans les services de soutien et de gestion des systèmes d'éducation et de suivis
pédagogiques, scientifiques et culturels.

2 Quelque activités d’Educanet

En 2012, les équipes de la société ont pu mettre en place un système d’information pédagogique
100% développé par la société, et respectant les besoins divers des établissements scolaires et
universitaires en Tunisie (nous citons : les écoles privées/publiques, collègues privés/publiques,
universités, écoles d’ingénieurs, centre de formation, …)

Educanet, vu son activité, est l’un des importants partenaires de plusieurs institutions
universitaires tel que : l’Ecole Nationale d’Ingénieurs de Sousse, de l’institut d’informatique et
de mathématique de Monastir, de l’association des parents de Sousse, de la fédération des
associations des parents et des élèves etc.

En 2014, la société a mis en ligne la première bibliothèque numérique gratuite en Tunisie. Cette
bibliothèque représente un référentiel pour les enseignants et les élèves, regroupant plus que
3600 titres en libre téléchargement et lecture. Un grand nombre de visiteurs peuvent accéder à
cette bibliothèque. L’accès en téléchargement à la bibliothèque ne cesse pas d’augmenter
rajouter des contraintes de performance aux solutions informatiques. D’autres, des écoles
peuvent utiliser notre bibliothèque pour l’enseignement interactif via des tableaux interactifs.

En 2015, la société Educanet a signé un partenariat avec un ensemble d’inspecteurs de la

direction régionale de l’éducation de Sousse, afin de mettre en œuvre un magazine
électronique qui regroupe tous les intéressés de l’éducation en Tunisie : inspecteurs, chargés
de l’enfance, maîtres, parents, enfants et cadres administratifs. En 3 mois, le magazine intitulé
‘’‫ ’’مسارات تربوية‬est devenue un référentiel de taille importante accueillant un grand nombre de
visiteurs actif : envoie des documents, demander de l’aide, proposer des formations etc. De
nos jours ‘’‫ ’’مسارات تربوية‬est l’un des sites éducatifs les plus visités en Tunisie.

19
 Chapitre I : Contexte & Etude préalable

3 Structure de la société

Figure 2 : L’organigramme du service technique

4 Technologie utilisée
Educanet utilise des Framework open sources à base du langage de développement java comme
J2EE, Life ray, SPRING. Ce choix, permettra à la société d’être compétitif afin d’offrir à ses
partenaires les meilleures innovations, sans qu’ils soient dans l’obligation de payer des licences
supplémentaires.

5 Fiche technique

Adresse Immeuble Ragaya_6ème Etage

Avenue Yasser Arafat_4054_Sahloul_Sousse

Téléphone +216 73 820 902
E-mail contact@educanet.pro
Web http://www.educanet.tn

Tableau 1 : fiche technique de la société Educanet

20
 Chapitre I : Contexte & Etude préalable

Etude préalable
1 Gestion électronique de document « GED »
1.1 Définition de GED
La gestion électronique de documents permet de remplacer des "documents papier" par leur
représentation sous forme de "documents électroniques", en réponse à la fois aux problèmes
d’archivage et de recherche des documents complets.
La GED ne concerne cependant pas l’élaboration du contenu du document mais seulement le
suivi de celui-ci à partir de sa création. Il s’agit, avant tout, de pouvoir organiser et contrôler
son évolution, son classement, sa transmission ou sa diffusion, son archivage, et à tout
moment, sa recherche pour consultation ou action.
1.2 Cycle de vie d’un document

Figure 3 : les étapes de cycle de vie d’un document électronique

Acquisition des documents

L’acquisition d’un document provient d’un processus automatique ou humain
(numérisation ou création de document) visant à créer, enregistrer, classer et indexer le
document électronique.

Gestion des documents

Les opérations de gestion englobent tout ce qui se passe après la création du document,
c'est-à-dire :
 La sécurité et les droits d’accès : gestion des permissions
 L’administration proprement dite (classement, diffusion, stockage, archivage).
 La variation du document : validité, durée de vie.
 L’évolution du document : version et mise à jour.

21
 Chapitre I : Contexte & Etude préalable

Conservation des Document

Assure la lisibilité et la disponibilité du document numérique et de ses composants à tout
moment.

Diffusion des Documents

Par mise à disposition ou distribution.

2 Gestion de document électronique « GDE »

2.1 Définition de document électronique
Les documents électroniques sont l’ensemble des documents (physiques) numérisés et des
documents créés informatiquement, conservés sur un support numérique, qu’ils ont le format
d’un e-mail fichiers bureautiques, dossiers numérisés, données échangées par télé procédures,
bases de données, etc.

3 Présentation de projet

Figure 4 : Image descriptive

22
 Chapitre I : Contexte & Etude préalable

4 Cahier de charge
4.1 Etude de l’existant
Analyse de l’existant
Dans cette partie nous allons citer quelques solutions de GED connues sur le marché. Cela
permettra de relever les fonctionnalités de base pouvant être intégrées dans le projet, et
proposer d’autres options comme valeur ajoutée.
Le tableau suivant présente ces logiciels :

Solution Développeur Environnement Description

 Alfresco est un système de
gestion de contenu créé par Alfresco
JAVA Software en 2005 et distribué sous
Alfresco Alfresco licence libre. Il permet à l’utilisateur
Software de partager des fichiers simplement
en les déplaçant sur le disque dédie.
 Dernière version : 5.1 en 9
février en 2016.
 SharePoint est une série de
SharePoint Microsoft Windows NT logiciels pour applications
Web et portails développée
par Microsoft. Les fonctionnalités des
produits SharePoint sont la gestion de
contenu, les moteurs de recherche,
la gestion électronique de
documents, les forums, la possibilité
de créer des formulaires .
 Dernière version : En 2016.

 Le logiciel eXo Plateforme

éponyme, est une plateforme de
Exo collaboration sociale destinée aux
plateforme Exo plateforme JAVA, JEE, entreprises. La plateforme fournit un
SAS SAS GROOVY ensemble de fonctionnalités
collaboratives et sociales ainsi que des
fonctionnalités de gestion de contenu
et de documents.

Tableau 2 : Les GED existants

23
 Chapitre I : Contexte & Etude préalable

Critique de l’existant
Solution Avantage Inconvénient
 Possibilité d'essayer la version  Sur le plan de
Community avant d'acheter les l'installation Alfresco est
licences Enterprise livré sous la forme d'un
fichier WAR, qu'il faut
 Modèle de licence simple
installer dans un
 Stockage basé sur un système de serveur tomcat. Il faut en
fichiers plus déplacer ou copier des
 Pas de limite de taille de fichiers fichiers à la main, en
suivant des instructions
souvent incomplètes
Alfresco glanées sur internet.

 Sur le plan de la
configuration initiale rien
n'est prévue pour faciliter
la configuration au moment
du déploiement. Il faut
éditer un fichier de
configuration à la main
dans lequel on indique des
chemins de fichiers, des
informations de connexions
pour le serveur de bases de
données, etc.

 Le manque de glisser-
déposer et glisser-déplacer,
ainsi que le très grand
nombre de clics pour la
moindre action sont de
vrais handicaps dans la
phase de remplissage

 Couverture médiatique importante  SharePoint implique

 Relative facilité d'emploi une politique du tout
 Couverture fonctionnelle suffisante Microsoft, sans
pour beaucoup d'entreprises possibilité d'intégrer des
produits concurrents
SharePoint moins coûteux
 Les besoins matériels
(serveurs) sont
importants, et
augmentent avec la
montée en charge

24
 Chapitre I : Contexte & Etude préalable

 Les données sont

stockées dans des
serveurs SQL, ce qui
implique une forte
dépendance envers
d'autres produits.
 SharePoint a tendance à
se développer de manière
empirique au sein des
entreprises
 Résolu le problème de la 
communication
Exo  Permis une coopération plus
plateforme efficace entre le personnel du
SAS projet.
 Offre une interface pratique pour
promouvoir la collaboration
sociale au sein de l'entreprise

Tableau 3 : Critique des GED existants

4.2 Spécification des besoins
Cette partie va servir à poser les bases du recueil du système à réaliser. Pour pouvoir clarifier
les besoins des utilisateurs de notre application. Nous allons présenter les besoins fonctionnels
et les besoins non fonctionnels.

Les besoins fonctionnels

Il s’agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement
d’entrée/sortie du système.
Le système doit permettre à l’utilisateur d’effectuer les opérations suivantes :

Gestion des utilisateurs :

Il s’agit d’un outil permettant d’effectuer les opérations de gestion telles que l’ajout,
la suppression totale ou l’archivage, la modification, la recherche et la consultation des
informations caractérisant chacun des utilisateurs.
Ce module doit contenir tous les outils suivants :
- Ajouter des rôles spécifiques à la société d’une manière dynamique.
- Changer le rôle d’un utilisateur donné.
- Ajouter les départements spécifiques de la société d’une manière dynamique.

Gestion des documents :

L’application doit assurer une bonne gestion des documents, à savoir, les documents
Word, Excel, PDF, Zip… Elle offrira plusieurs fonctionnalités :
 Importation de documents : les documents peuvent provenir de la machine de
l’utilisateur (document interne) ou bien des autres applications (document
externe).

25
 Chapitre I : Contexte & Etude préalable

 Visualiser les documents dans un navigateur web : les fichiers doivent être
présentés sans déformation ou éléments manquants tout en gardant les
spécifications de chaque type de document.
 Parcourir les différentes versions d’un document donné : l’application doit
gérer les versions (révisions) des documents. Ces versions peuvent être
consultables.
 Indexer les documents pour une recherche rapide : l’application doit disposer
d’un moteur de recherche capable d’enregistrer le contenu des documents et
d’effectuer une recherche rapide sur une grande quantité de documents.
 Exporter et télécharger les documents en plusieurs formats : un utilisateur peut
exporter puis télécharger un document en différents formats selon ses droits
d’accès.
 Classification de document : une classification flexible de documents selon
leurs types.
 Archivage de documents : c’est la fin de cycle de vie d’un document dans une
société.
 Partage de document :

Gestion de langue : Internationalisation de l’application :

Elle peut être utilisée en différentes langues (le Français, Anglais, Arabe). La langue est
choisie automatiquement selon les paramètres du navigateur utilisé.

Gestion de contrôle :
L’administrateur doit effectuer à chaque traitement un ou plusieurs responsables en
précisant les dates de début et fin de chacun entre eux, il peut les modifier au cas où le
traitement aura changé.

Gestion des droits :

Chaque acteur a un compte pour accéder au système, et pour chaque compte, il est attribué
un rôle ou un profil qui définit les fonctionnalités que l’utilisateur ne peut pas dépasser.

Envoyer un E-mail : Tous les utilisateurs de l’application ont la possibilité de rédiger

et envoyer un E-mail d’une interface propre de l’application.

Gestion des évènements : Notre application possède un calendrier propre à lui-même

pour fixer les évènements important pendant toute l’année.

Envoie de notification : Une notification est envoyée lors de l’importation d’un

nouveau document à tous les utilisateurs.

Les besoins non fonctionnels

Un besoin non fonctionnel est un besoin spécifiant des propriétés du système, telles que
les contraintes liées à l’environnement et à l’implémentation, les exigences en matière de
performance, de dépendance, de plates-formes, de facilité, de maintenance, d’extensibilité et
de fiabilité.
Les besoins non fonctionnels sont donc des besoins indépendants des utilisateurs : ce sont
plutôt des contraintes qui sont supposées pour assurer la qualité et le bon fonctionnement du

26
 Chapitre I : Contexte & Etude préalable

système. Ainsi, comme toute application, la nôtre doit présenter une interface ergonomique.
Vu son usage, notre application doit fournir des interfaces simples et bien clair, donc le
système devrait tenir compte des contraintes suivantes :
Besoin de disponibilité et de fiabilité :
Le système devra être opérationnel d’une façon continue, sauf pendant les phases de
maintenances régulières du système par l’administrateur.
Besoins de performance :
Décrivent les performances d’exécution du système, généralement en termes de temps de
réponse. Le système doit garantir un temps de réponse minimal : Le chargement d’une page
Web dans le navigateur ne devrait pas prendre plus de 15 secondes en condition normale.
Les interfaces doivent être ergonomiques :
L’interface de l’application doit être simple et pratique afin que l’utilisateur puisse l’exploiter
sans se référer à des connaissances particulières. En d’autres termes, les informations doivent
être lisibles et faciles d’accès par n’importe quel utilisateur.

4.3 Architecture envisagée

L'architecture trois tiers, également appelée architecture à trois niveaux ou à trois
couches, est une architecture client-serveur dans laquelle coexistent et sont maintenus
des modules indépendants permettant le rendu d'une interface utilisateur, les processus
logiques, fonctionnels et métiers ainsi que l'accès aux données. On parle donc ici d'une
infrastructure physique qui va servir de support à une infrastructure logiciell e. En
effet, n'importe quelle application peut être découpée en trois parties : une partie
interface graphique, une partie fonctionnelle, et une partie de stockage de données. Et
c'est à ces besoins précis que l'architecture trois-tiers s'est dessinée en découpant trois
parties distinctes :

Figure 5 : Architecture 3 tiers

27
 Chapitre I : Contexte & Etude préalable

L'IHM :
Le navigateur installé sur le poste client qui fait un rendu visuel.
Le serveur Applicatif :
Pour la partie traitement et fonctionnelle (de nombreux langages applicatifs tels que Java,
PHP, Ruby peuvent être utilisés).
Le serveur de base de données :
Ce qui va permettre de stocker et de restituer les données (MySQL, PostgreSQL,
Cassandra).
L'architecture trois tiers se veut moderne et son découpage en trois parties fait d'ell e un
essentiel pour le développement d'applications Web, afin d'apporter plus de
performances, de sécurité mais en apportant également une maintenance plus aisée.
Ce type d’architecture présente trois couches principales :
La couche présentation :
C’est la première couche qui compose l'infrastructure trois tiers : il s'agit de la partie
rendu logiciel. Elle est rendue possible grâce aux langages de rendus, en l'occurrence
pour une application Web, au cas de notre application, on a utilisé le HTML, le CSS , le
JavaScript et le JQUERY.
La couche métier ou fonctionnelle :
C'est la seconde couche qui compose l'infrastructure trois tiers : elle correspond à un
ensemble de composants métiers qui permettent de traiter un ensemble d'actions sur un
serveur, et de faire éventuellement appel à des services externes pour envoyer une
réponse au client. Le client communique donc avec le serveur grâce à l'interface
graphique, puis le serveur fait son traitement et renvoie la réponse au client. Les
langages serveurs les plus utilisés sont : le PHP, le JAVA, le JEE, le C/C++/C#.
La couche d’accès aux données :
C'est la troisième couche qui compose l'infrastructure trois-tiers : elle correspond au
serveur de base de données. Sur ce troisième tiers, un SGBD (Système de Gestion de
Base de Données) est installé, comme par exemple MySQL ou Microsoft SQL Server,
et ce serveur est requêté par le serveur applicatif afin d'utiliser un certain nombre de
données. [B1]

5 Planning des taches

5.1 Définition de diagramme de GANNT
Le diagramme de Gantt est un outil utilisé (souvent en complément d'un réseau PERT) en
ordonnancement et gestion de projet et permettant de visualiser dans le temps les diverses
tâches composant un projet. Il permet de représenter graphiquement l'avancement du projet.
Cet outil répond à deux objectifs : planifier de façon optimale et communiquer sur le planning
établi et les choix qu'il impose.

5.2 Présentation de diagramme de GANTT

La colonne gauche du diagramme énumère toutes les tâches à effectuer, tandis que la ligne
d’en-tête représente les unités de temps les plus adaptées au projet (jours, semaines, mois
etc.).

28
 Chapitre I : Contexte & Etude préalable

Chaque tâche est représentée par une barre horizontale, dont la position et la longueur
représentent la date de début, la durée et la date de fin.
Ce diagramme répertoire toutes les tâches à accomplir pour bien mener le projet, et indique la
date à laquelle ces taches doivent être effectuées. En effet, on a commencé le projet par la
recherche, par la suite, on a réalisé l’étude conceptuelle. Finalement, on a développé
l’application et la tester. La rédaction du rapport est établie au cours du projet.

Figure 6 : Diagramme de GANTT

Conclusion
Ce chapitre est le point de départ pour la réalisation du projet, dans la mesure où il décrit
l’organisation d’accueil ainsi que la démarche adoptée pour la mise en œuvre du
projet et le planning que nous allons suivre le long de la période de production. Il décrit aussi
la spécification des besoins des différentes parties du projet. Dans ce chapitre nous avons
décrit d’étude de l’existence et le critiqué pour bien situer le travail qui sera effectué et aussi
pour avoir une idée claire sur le besoin.

29
30
Chapitre II : Elaboration

Introduction

31
 Chapitre II : Elaboration

Méthode et outil de modélisation choisis

1 Choix de la méthodologie de conception adopte
1.1 Choix de cycle de vie logiciel
Le processus unifié se déroule en quatre phases, incubation, élaboration, construction et
transition. Chaque phase répète un nombre de fois une série d'itérations. Et chaque itération
est composée de cinq activités : capture des besoins, analyse, conception, implémentation et
test

Figure 7 :
Incubation
C'est la première phase du processus unifié. Il s'agit de délimiter la portée du système, c'est-à-
dire tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à l'extérieur,
identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires dans
cette phase. Il s'agit aussi d'établir une architecture candidate, c'est à dire que pour une
première phase, on doit essayer de construire une architecture capable de fonctionner. Dans
cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon
déroulement du projet.

Elaboration

C'est la deuxième phase du processus. Après avoir analysé le système et dégagé les
fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant
consiste à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial de cas
d'utilisation, de chercher de nouveaux besoins, analyser et concevoir la majorité des cas
d'utilisation formulés, et si possible implémenter et tester les cas d'utilisation initiaux.

Construction

Dans cette phase, nous allons analyser les besoins restants. Ensuite, nous allons continuer
l'analyse, la conception et surtout l'implémentation de tous les cas d'utilisation. A la fin de
cette phase, nous en tant que développeurs devons fournir une version exécutable du système

32
 Chapitre II : Elaboration

Transition

C'est la phase finale du projet. Il s'agit au cours de cette phase de vérifier si le système offre
véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les
manques dans la documentation du logiciel et adapter le produit à l'environnement (mise en
place et installation).

1.2 Choix de méthode de conception

UML (Unified Modeling Language), se définit comme un langage de modélisation graphique
et textuel destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes,
esquisser des architectures logicielles, concevoir des solutions et communiquer des points de
vue.

Il contient en particulier :
· Les concepts des approches par objets : classe, instance, classification, etc.
· Intégrant d'autres aspects : associations, fonctionnalités, événements, états, séquences, etc.
UML définit neuf types de diagrammes devisés en deux catégories :

Diagramme statistique (structurels) :

Diagramme de classe, d’objet, de composant, de déploiement et de diagramme de cas

d’utilisation.

Diagrammes dynamique (comportementaux) :

Diagramme d’activité, de séquence, d’état-transition et de collaboration.

Pour la modélisation des besoins, nous utilisons les diagrammes UML suivant :

 Diagramme de cas d'utilisation.

 Diagramme d’activité
 Diagramme de séquence
 Diagramme de classe

Figure 8 : Logo UML

33
 Chapitre II : Elaboration

2 Outil de modélisation
IBM Rational Rose est un outil de modélisation d’application
édité par la société IBM. Il permet entre autres la réalisation de
diagrammes UML. Mais il permet également de couvrir toutes les
étapes de la phase descendante du cycle en V de développement
d’un programme jusqu’à l’étape de génération automatique de code
dans le langage souhaité (C/C++, Visual Basic, Java, XML,
Application web etc…). [B2]

Modèle de domaine (diagramme de cas

d’utilisation)
1 Description
Avant de se lancer dans la réalisation d’un logiciel, Il faut comprendre, clarifier et structurer
les attentes et les besoins du client.

Le diagramme des cas d'utilisation (Use Case Diagram) constitue la première étape de
l’analyse UML en :
- Modélisant les besoins des utilisateurs.
- Identifiant les grandes fonctionnalités et les limites du système.
- Représentant les interactions entre le système et ses utilisateurs.
Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument pas une
vision informatique. Il ne nécessite aucune connaissance informatique et l’idéal serait qu’il
soit réalisé par le client. Le diagramme des cas d’utilisations n’est pas un inventaire exhaustif
de toutes les fonctions du système. Il ne liste que des fonctions générales essentielles et
principales sans rentrer dans les détails.
Les éléments de base du diagramme de cas d’utilisation :
Les acteurs :
Avant de rechercher les besoins, la première tâche consiste à définir les limites du système
(c.à.d. ce qui est inclus ou pas dans le système), puis à identifier les différentes entités
intervenantes sur le système. Ces entités sont appelées acteurs.
Les cas d’utilisation :
Elle représente une fonctionnalité du système visible de l’extérieur du système.
Les relations :
Est chemin de communication entre un acteur et un cas d'utilisation et est représenté par un
trait continu entre cas d’utilisations et acteurs. [B3]

34
 Chapitre II : Elaboration

2 Identification des acteurs du système

Dans le cas de notre projet nous présentons les acteurs suivants :
Admin :
Il représente le rôle du premier responsable dans la société (exp : directeur, secrétaire
générale). Le responsable de ce rôle a la possibilité de gérer les utilisateurs, gérer les rôles,
gérer les départements, gérer les documents, de les suivre et de choisir la langue de
l’application (Arabe ou français).
Responsable de bureau d’ordre :
Le responsable de ce rôle a la possibilité d’ajouter tous les documents spécifiques de chaque
société et de les envoyer à l’Admin.
Chef :
Il représente un nombre des responsables qui ont les droits d’envoyer et de recevoir les
documents entre eux, de les suivre, de recevoir les documents de sous-chef et de simple agent,
de contrôler les deux derniers, de renvoyer les documents à l’administrateur et de choisir la
langue de l’application (Arabe ou Français).
Sous-chef :
Il représente un nombre des responsables qui ont les droits d’envoyer et de recevoir les
documents entre eux, de les suivre, de les recevoir de simple agent, de contrôler ceux derniers,
de renvoyer les documents aux leur chef et de choisir la langue de l’application (Arabe ou
Français).
Simple agent :
Il représente un nombre des responsables qui ont les droits justes de faire les traitements de
documents, de les renvoyer aux leur chef et de choisir la langue de l’application (Arabe ou
Français).

Figure 9 : Diagramme de classe des acteurs

35
 Chapitre II : Elaboration

3 Diagramme de processus métier

Le diagramme processus métier est le diagramme général du système qu’on modélise et qui
d´écrit les interactions, les fonctionnalités et les relations globales entre les différents acteurs.

Figure 10 : diagramme de processus métier

4 Identification de cas d’utilisation de système

Dans cette partie, nous recensons les principales fonctionnalités offertes par le système,
tout en les associant aux acteurs qui devront en bénéficier.

Les acteurs
du système
Les cas Admin Responsable Chefs Sous-chefs Simple agent
d’utilisations bureau d’ordre
Authentification     
Ajouter utilisateur 
Modifier utilisateur 
Consulter utilisateur     

36
 Chapitre II : Elaboration

Rechercher utilisateur     
Supprimer utilisateur 
Ajouter rôle 
Modifier rôle 
Consulter rôle 
Supprimer rôle 
Ajouter Département 
Modifier département 
Consulter département 
Supprimer département 
Importer document     
Modifier propriétés de    
document
Consulter document     
Archiver document 
Envoyer document     
Rechercher document     
Télécharger document     
Ouvrir document dans un     
navigateur web
Envoyer E-mail     

Tableau 4 : Principales fonctionnalités offertes par le système

5 Spécification de cas d’utilisation

5.1 Cas d’utilisation « Authentification »

Figure 11 : Raffinement de cas d’utilisation « Authentification »

Description
Nom du cas d’utilisation S’authentifier.
Acteurs Utilisateur

37
 Chapitre II : Elaboration

L’acteur s’authentifie en utilisant son adresse e-mail et son

Description
mot de passe.
Pré Condition - Opération d’authentification demandée par l’acteur.
Post Condition Acteur authentifié.
1. L’acteur saisit son e-mail et son mot de passe.
2. Le système vérifie les données de l’acteur.
Scénario de base
3. Le système affiche un message de succès d’authentification.
4. Le système affiche l’interface d’accueil propre à l’acteur.
2. E-mail ou mot de passe non valide :
Scénario d’exception - Le système affiche un message d’erreur.
- Retour à l’étape 1 du scénario de base.

Table 1 : Scénario de cas d’utilisation « Authentification »

5.2 Cas d’utilisation « Gérer utilisateur »

Raffinement de cas d’utilisation « Gérer
utilisateur »

Figure 12 : Raffinement de cas d’utilisation « Gérer utilisateur »

Description

38
 Chapitre II : Elaboration

Après avoir accéder à son espace de travail, Admin au droit d'ajouter, de modifier, de
consulter, de faire une recherche rapide et de supprimer un utilisateur : soit une suppression
totale ou archivage.
Les cas d'utilisation de ce processus sont détaillés ci-dessous :

 Ajout utilisateur

Nom du cas d’utilisation Ajouter utilisateur

Acteurs Admin
L’administrateur introduit les données concernant l’utilisateur
Description telles que CIN, le Nom, le prénom et d’autres informations.

- Opération d’ajout choisie.

Pré Condition
- Administrateur authentifié.
Post Condition Utilisateur ajoutée.
1. « include » s’authentifier.
2. L’administrateur introduit les données relatives à l’utilisateur
3. L’administrateur valide l’opération.
4. Le système vérifie la saisie.
5. Le système enregistre les données de l’utilisateur.
Scénario de base 6. Le système affiche un message de « Succès d’ajout ».
7. Le système envoie un e-mail à l’utilisateur pour ajouter son
User Name et mot de passe.
8. L’utilisateur introduit l’User Name et le mot de passe.
9. Le système vérifie la saisie.
10. Le système enregistre les nouvelles données.
4.1. Données non valides :
- Le système affiche un message d’erreur : « champ manquant ».
- Retour à l’étape 2 du scénario de base.
4.2. Utilisateur déjà existant :
Scénario d’exception - Le système affiche un message « Utilisateur déjà existant »
- Retour à l’étape 2 du scénario de base.
9.1. Un User Name déjà existant
-Le système affiche un message « il faut changer l’User Name »
-Retour à l’étape 8 du scénario de base

Table 2 : Scénario de cas « Ajouter utilisateur »

 Modifier utilisateur

Nom du cas d’utilisation Modifier utilisateur

Acteur Admin
Description L’acteur a la possibilité de modifier les données de l’utilisateur.

39
 Chapitre II : Elaboration

- le Admin authentifié.
Pré Condition
- Opération de modification choisie.
Post Condition Donnes d’utilisateur modifié.
1. « include » s’authentifier.
2. L’Admin modifie les données d’utilisateur sélectionné.
3. L’Admin valide la modification.
Scénario de base
4. Le système vérifie la modification.
5. Le système enregistre la modification.
6. Le système affiche un message de « succès ».
5.1- Modification non valide
Scénario d’exception 5.1.1 le système affiche un message d’erreur « champs manquants »
5.1.2 Retour à l’étape 2de scenario de base

Table 3 : Table 3 : Scénario de cas « Modifier utilisateur »

 Consulter utilisateur

Nom du cas d’utilisation Consulter Utilisateur

Acteurs Admin
L’acteur sélectionne L’utilisateur parmi ceux affichés dans
Description brève
une liste pour consulter sa fiche technique détaillé.
- Acteur authentifié.
Pré Condition
- Opération de consultation choisie.
Post Condition Profil consultée.
1. « include » s’authentifier.
2. L’acteur demande la consultation de l’utilisateur
Scénario de base 3. Le système affiche une liste d’utilisateur.
4. L’acteur sélectionne un utilisateur à consulter.
5. Le système fournit le profil de l’utilisateur.
3.1. La liste d’utilisateur est vide :
Scénario d’exception
3.1.1 retour à l’étape 2 de scénario de base

Table 4 : Scénario de cas « Consulter utilisateur »

 Rechercher utilisateur

Nom du cas d’utilisation Rechercher utilisateur

Acteurs Admin
Ce cas d’utilisation permet à l’acteur de rechercher un
Description brève
utilisateur existant.
- Acteur authentifié.
Pré Condition
- Opération de recherche choisie.
Post Condition Utilisateur trouvé

40
 Chapitre II : Elaboration

1. « include » s’authentifier.
2. L’acteur saisie le nom de l’utilisateur à rechercher
3. Le système affiche une liste d’utilisateur.
Scénario de base
4. L’acteur sélectionne un utilisateur à rechercher.
5. L’acteur choisie l’opération à saisir (supprimer,
modifier, consulter).
3.1. La liste d’utilisateur est vide
Scénario d’exception
3.1.1 retour à l’étape 2 du scénario de base

Table 5 : Scénario de cas « Rechercher utilisateur »

 Supprimer utilisateur

Nom du cas d’utilisation Supprimer Utilisateur

Acteur Admin
L’acteur a la possibilité de faire une suppression totale ou
Description brève
archiver l’utilisateur.
- l’acteur authentifié.
Pré Condition
- Opération de suppression choisie.
Post Condition Utilisateur supprimé ou archivé.
1. « include » s’authentifier.
2. L’acteur supprime L’utilisateur sélectionné.
3 Le système demande de choisir entre la suppression et
Scénario de base l’archivage de l’utilisateur.
4. L’acteur valide son choix.
5. Le système supprime ou archive l’utilisateur.
6. Le système affiche un message de « succès ».
5. L’utilisateur annule la suppression :
Scénario d’exception
- Retour à l’étape 2 du scénario de base.

41
 Chapitre II : Elaboration

Table 6 : Scénario de cas « Supprimer utilisateur »

Diagramme de modèle de domaine « Gérer
utilisateur »
Le modèle de domaine doit définir les classes qui modélisent les entités ou concepts présents
dans le domaine (on utilise aussi le terme de métier) de l'application. Il s'agit donc de produire
un modèle des objets du monde réel dans un domaine donné.

Figure13 : Diagramme de modèle de domaine « gérer utilisateur »

42
 Chapitre II : Elaboration

5.3 Cas d’utilisation « Gérer rôle »

Raffinement de cas d’utilisation « Gérer rôle »

Figure 14 : raffinement de cas d’utilisation « gérer rôle »

Description
Après avoir accéder à son espace de travail, l’Admin le droit d'ajouter, de modifier, de
supprimer et de consulter les rôles spécifiques de sa société.
Les cas d'utilisation de ce processus sont détaillés ci-dessous :

 Ajouter rôle
Nom du cas
Ajouter Rôle
d’utilisation
Acteurs Admin
Description brève L’administrateur ajouter les rôles spécifiques de sa société.
- Opération d’ajout choisie.
Pré Condition
- Administrateur authentifié.
Post Condition Rôle ajoutée.
1. « include » s’authentifier.
2. L’administrateur ajoute un nouveau rôle.
Scénario de base 3. L’administrateur valide l’opération.
4. Le système vérifie la saisie.
5. Le système enregistre le nouveau rôle.

43
 Chapitre II : Elaboration

4.1. Données non valides :

- Le système affiche un message d’erreur : « champ manquant
Scénario d’exception ».
- Retour à l’étape 2 du scénario de base.

Table 7 : Scénario de cas « Ajouter rôle »

 Modifier rôle

Nom du cas d’utilisation Modifier rôle

Acteurs Admin
Description L’administrateur a la possibilité de modifier le rôle.
- Administrateur authentifié.
Pré Condition
- Opération de modification choisie.
Post Condition Rôle d’utilisateur modifié.
1. « include » s’authentifier.
2. L’acteur modifie le rôle sélectionné.
3. L’administrateur valide la modification.
Scénario de base
4. Le système vérifie la modification.
5. Le système enregistre la modification.

5. Modification non valide

Scénario d’exception - Le système affiche un message d’erreur « champs manquants ».
- Retour à l’étape 2 de scénario de base.

Table 8 : Scénario de cas « Modifier rôle »

 Consulter rôle

Nom du cas d’utilisation Consulter Rôle

Acteurs Admin
Description brève L’acteur consulte la liste des rôles.
- Acteur authentifié.
Pré Condition
- Opération de consultation choisie.
Post Condition Rôle consultée.
1. «include» s’authentifier.
Scénario de base 2. L’acteur demande la consultation de rôle
3. Le système affiche une liste de rôle.
3. La liste de rôle est vide :
Scénario d’exception
- Retour à l’étape 2 du scénario de base.

Table 9 : Scénario de cas « Consulter rôle »

44
 Chapitre II : Elaboration

 Supprimer rôle

Nom du cas d’utilisation Supprimer rôle

Acteur Admin
Description L’administrateur a la possibilité de supprimer le rôle
- Administrateur authentifié.
Pré Condition
- Opération de suppression choisie.
Post Condition Rôle supprimée.

1. « include » s’authentifier.
2. L’administrateur supprime le rôle d’utilisateur sélectionné.
3. Le système demande la confirmation de la suppression.
Scénario de base 4. L’administrateur valide la suppression.
5. Le système supprime le rôle d’utilisateur de la
base de données.
6. Le système affiche un message de « succès de suppression ».

5. L’administrateur annule la suppression :

Scénario d’exception
- Retour à l’étape 2 de scénario de base.

Table 10 : Scénario de cas « Supprimer rôle »

Diagramme de modèle de cas d’utilisation

« Gérer rôle »

Figure 15 : Diagramme de modèle de domaine « gérer Rôle »

45
 Chapitre II : Elaboration

5.4 Cas d’utilisation « Gérer département »

Raffinement de cas d’utilisation « Gérer
département »

Figure 16 : Raffinement de cas d’utilisation « Gérer département »

 Description

Après avoir accéder à son espace de travail, l’Admin a le droit d'ajouter, de modifier, de
supprimer et de consulter les départements spécifiques de sa société.
Les cas d'utilisation de ce processus sont détaillés ci-dessous :

 Ajout département

Nom du cas d’utilisation Ajouter Département

Acteurs Admin
Description brève L’acteur ajouter les départements spécifiques de sa société.
- Opération d’ajout choisie.
Pré Condition
- Administrateur authentifié.
Post Condition Département ajoutée.
1. « include » s’authentifier.
2. L’administrateur ajoute un nouveau département.
3. L’acteur valide l’opération.
Scénario de base
4. Le système vérifie la saisie.
5. Le système enregistre le département.

4.1. Données non valides :

- Le système affiche un message d’erreur : « champ manquant ».
Scénario d’exception
- Retour à l’étape 2 du scénario de base.

Table 11 : Scénario de cas « Ajouter Département »

46
 Chapitre II : Elaboration

 Modifier département

Nom du cas d’utilisation Modifier département

Acteurs Admin
Description L’acteur a la possibilité de modifier le département.
- Administrateur authentifié.
Pré Condition
- Opération de modification choisie.
Post Condition Département modifié.
1. « include » s’authentifier.
2. L’acteur modifie le département sélectionné.
3. L’acteur valide la modification.
Scénario de base
4. Le système vérifie la modification.
5. Le système enregistre la modification.

5. Modification non valide

Scénario d’exception - Le système affiche un message d’erreur « champs manquants ».
- Retour à l’étape 2 de scénario de base.

Table 12 : Scénario de cas « Modifier département »

 Consulter département

Nom du cas d’utilisation Consulter Département

Acteurs Admin
Description brève L’acteur consulte la liste des départements.
- Acteur authentifié.
Pré Condition
- Opération de consultation choisie.
Post Condition Département consultée.
1. « include » s’authentifier.
Scénario de base 2. L’acteur demande la consultation de la liste de départements.
3. Le système affiche la liste de départements.
3. La liste de département est vide :
Scénario d’exception
- Retour à l’étape 2 du scénario de base.

Table 13 : Scénario de cas « Consulter département »

 Supprimer département

Nom du cas d’utilisation Supprimer département

Acteur Admin
Description L’administrateur a la possibilité de supprimer un département.
- l’acteur authentifié.
Pré Condition
- Opération de suppression choisie.

47
 Chapitre II : Elaboration

Post Condition Département supprimée.

1. « include » s’authentifier.
2. L’administrateur supprime le département sélectionné.
3. Le système demande la confirmation de la suppression.
Scénario de base 4. L’acteur valide la suppression.
5. Le système supprime le département de la
base de données.
6. Le système affiche un message de « succès de suppression ».
3. L’administrateur annule la suppression :
Scénario d’exception
- Retour à l’étape 2 de scénario de base.

Table 14 : Scénario de cas « Supprimer département »

Diagramme de modèle de domaine de cas

d’utilisation « Gérer département »

Figure17 : Diagramme de modèle de domaine « gérer département »

48
 Chapitre II : Elaboration

49
 Chapitre II : Elaboration

5.5 Cas d’utilisation « Gérer document »

Raffinement de cas d’utilisation « Gérer
document »

Figure 18 : raffinement de cas d’utilisation « Gérer document »

50
 Chapitre II : Elaboration

 Description

Après avoir accéder chacun à son espace de travail, les acteurs ont le droit d'ajouter, de
modifier, de consulter les documents et leurs informations détaillées, de les archiver et même
de les envoyer.
Les cas d'utilisation de ce processus sont détaillés ci-dessous :

 Ajouter document

Nom du cas d’utilisation Ajouter document

Acteurs Utilisateur
Description brève Les acteurs ajoutent les documents nécessaires.
- Opération d’ajout choisie.
Pré Condition
- acteurs authentifié.
Post Condition Document ajouté.
1. « include » s’authentifier.
2. Les acteurs ajoutent les documents et les informations
nécessaires.
Scénario de base 3. Les acteurs valides l’opération.
4. Le système vérifie la saisie.
5. Le système enregistre les documents ajoutés.

4.1. Données non valides :

- Le système affiche un message d’erreur : « champ manquant ».
Scénario d’exception
- Retour à l’étape 2 du scénario de base.

Table 15 : Scénario de cas « Ajouter document »

 Modifier propriété document

Nom du cas d’utilisation Modifier document

Acteurs Admin, chef, sous-chef
Les acteurs ont la possibilité de modifier les documents ou leurs
Description
informations.
- acteurs authentifiés.
Pré Condition
- Opération de modification choisie.
Post Condition Document ou informations de document modifié.
1. « include » s’authentifier.
2. L’acteur modifie les documents sélectionnés.
Scénario de base
3. L’acteur valide la modification.
4. Le système vérifie la modification.

51
 Chapitre II : Elaboration

5. Le système enregistre la modification.

4. Modification non valide

Scénario d’exception - Le système affiche un message d’erreur « champs manquants ».
- Retour à l’étape 2 de scénario de base.

Table 16 : Scénario de cas « Modifier document »

 Consulter document
Nom du cas d’utilisation Consulter document
Acteurs Utilisateur sauf le responsable de bureau d’ordre
Les acteurs peuvent consulter la liste ou les informations
Description brève
détaillées d’un document sélectionné.
- Acteur authentifié.
Pré Condition
- Opération de consultation choisie.
Post Condition Document consultée.
1. « include » s’authentifier.
2. L’acteur demande la consultation de document.
Scénario de base 3. Le système affiche la liste de document
4. L’acteur sélectionne le document à consulter.
5. Le système fournit la fiche technique détaillée.
3. La liste de document est vide :
Scénario d’exception
- Retour à l’étape 2 du scénario de base.
Table 17 : Scénario de cas « Consulter document »

 Archiver document
Nom du cas d’utilisation Archiver document
Acteur Admin, chef, sous-chef
Description Les acteurs ont la possibilité d’archiver le document
- acteurs authentifié.
Pré Condition
- Opération d’archivage choisie.
Post Condition Document archivé
1. « include » s’authentifier.
2. L’acteur archive le document sélectionné.
3. Le système demande la confirmation d’archivage.
Scénario de base
4. L’acteur valide l’archivage.
5. Le système archive le document dans de données.
6. Le système affiche un message de « succès d’archivage ».
5. L’administrateur annule l’archivage :
Scénario d’exception
- Retour à l’étape 2 de scénario de base.

52
 Chapitre II : Elaboration

Table 18 : Scénario de cas « Archiver document »

 Envoyer document

Nom du cas d’utilisation Envoyer document

Acteurs Utilisateur sauf le responsable de bureau d’ordre
Description brève Les acteurs envoyer les documents nécessaires.
- Opération d’envoie choisie.
Pré Condition
- acteurs authentifié.
Post Condition Document envoyé.
1. « include » s’authentifier.
2. Les acteurs envoyées les documents nécessaires.
Scénario de base 3. Les acteurs valides l’opération.
4. Le système envoyée les documents.

Table 19 : Scénario de cas « Envoyer document »

 Rechercher document
Nom du cas d’utilisation Rechercher document
Acteurs Utilisateur sauf responsable de bureau d’ordre
Ce cas d’utilisation permet à l’acteur de rechercher un
Description brève
document existant.
- Acteur authentifié.
Pré Condition
- Opération de recherche choisie.
Post Condition Document trouvé
1. « include » s’authentifier.
2. L’acteur saisie le nom de document à rechercher
3. Le système affiche une liste de document.
Scénario de base
4. L’acteur sélectionne un document à rechercher.
5. L’acteur choisie l’opération à saisir (archiver, modifier,
consulter).
3.1. La liste de document est vide
Scénario d’exception
3.1.1 retour à l’étape 2 du scénario de base

Table 20 : Scénario de cas « Rechercher document »

 Télécharger document

Nom du cas d’utilisation Télécharger document

Acteur Utilisateur
Description Les acteurs ont la possibilité de télécharger le document

53
 Chapitre II : Elaboration

- Acteurs authentifié.
Pré Condition
- Opération de téléchargement choisie.
Post Condition Document téléchargé
1. « include » s’authentifier.
2. L’acteur télécharge le document sélectionné.
3. Le système demande la confirmation de format de
Scénario de base
téléchargement.
4. L’acteur valide le format.
5. Le système affiche un message de « succès de téléchargement ».
3. L’administrateur annule le téléchargement :
Scénario d’exception
- Retour à l’étape 2 de scénario de base.

Table 21 : Scénario de cas « Télécharger document »

54
 Chapitre II : Elaboration

Diagramme de modèle de domaine de cas

d’utilisation « Gérer document »

Figure 19 : Diagramme de modèle de domaine « gérer document »

5.6 Diagramme de modèle de domaine générale

Figure 20 : Diagramme de modèle de domaine générale

Conclusion
En effet, l'étude de l'existant permet d’aboutir à la représentation des différents besoins de
notre solution moyennant les diagrammes de cas d'utilisation correspondants. Nous nous
focaliserons dans le chapitre suivant à la mise en place du schéma conceptuel de la solution
qui répondra aux besoins précédemment cité

55
56
Chapitre III : Analyse &
conception

Introduction

57
 Chapitre III : Analyse & conception

Analyse
1 Modèle d’analyse
1.1 Analyse de cas d’utilisation « Gérer
utilisateur »
Traçabilité entre le modèle de cas d’utilisation
et le modèle d’analyse du cas d’utilisation
« gérer utilisateur »
Le diagramme ci-dessous permet d’illustrer les classes d’analyses qui participent au cas
d’utilisation « Gérer utilisateur »

Figure 21 : traçabilité de cas d’utilisation « Gérer utilisateur »

58
 Chapitre III : Analyse & conception

Diagramme de classe d’analyse de cas

d’utilisation « Gérer utilisateur »

Figure 22 : Diagramme de cas d’analyse de cas d’utilisation « gérer utilisateur »

Description
Pour gérer les utilisateurs, l’Admin peut interagir avec le système grâce à des interfaces
dédiées à faciliter la communication :
IU_ListUser : Cette interface permet à l’Admin de consulter la liste des utilisateurs et
d’effectuer une recherche rapide. C’est à partir d’elle que l’Admin peut passer à une modal de
création d’un nouvel utilisateur ou d’accédé au profil de ce dernier.
IU_GestionUser : Cette interface permet à l’Admin d’ajouter un nouvel utilisateur.
IU_ProfilUser : Cette interface permet à l’Admin, chefs, sous-chefs ou simples agents de
consulter le profil de n’importe quels utilisateurs.
IU_SuppUser : Cette interface permet à l’Admin d’archiver un ancien utilisateur de
l’application ou de supprimer définitivement.
Pour réaliser toutes ces opérations, le système se dote de deux contrôleurs « control User » et
« control archive » permettant d’exécuter les fonctions. En effet, ces deux contrôleurs
extraites les données nécessaires de la classe Utilisateur contenant les informations de tous les
utilisateurs.

59
 Chapitre III : Analyse & conception

1.2 Analyse de cas d’utilisation « Gérer rôle »

Traçabilité entre le modèle de cas d’utilisation
et le modèle d’analyse du cas d’utilisation
« Gérer rôle »
Le diagramme ci-dessous permet d’illustrer les classes d’analyses qui participent au cas
d’utilisation « Gérer rôle »

Figure 23 : traçabilité de cas d’utilisation « gérer rôle »

60
 Chapitre III : Analyse & conception

Diagramme de classe d’analyse de cas

d’utilisation « Gérer rôle »

Figure 24 : Diagramme de classe d’analyse de cas d’utilisation « gérer rôle »

Description
Pour gérer les rôles,l’Admin peut interagir avec le système grâce à des interfaces dédiées à
faciliter la communication :
IR_ListRôle : cette interface permet à l’Admin de consulter la liste des rôles. C’est à partir
d’elle que l’Admin peut passer à une modal de création d’un nouvel rôle.
IR_GestionRôle ; Cette interface permet à l’Admin d’ajouter les rôles spécifiques à sa
société.
IR_SuppRôle : cette interface permet de vérifier la décision de suppression.
Pour réaliser toutes ces opérations, le système se dote de contrôleur « control rôle »
permettant d’exécuter les fonctions. En effet, ce contrôleur extrait les données nécessaires de
la classe Rôle contenant les informations de tous les rôles.

61
 Chapitre III : Analyse & conception

1.3 Analyse de cas d’utilisation « Gérer

département »
Traçabilité entre le modèle de cas d’utilisation
et le modèle d’analyse du cas d’utilisation
« Gérer département »
Le diagramme ci-dessous permet d’illustrer les classes d’analyses qui participent au cas
d’utilisation « Gérer département »

Figure 25 : traçabilité de cas d’utilisation « gérer département »

62
 Chapitre III : Analyse & conception

Diagramme de classe d’analyse du cas

d’utilisation « Gérer département »

Figure 26 : Diagramme de classe d’analyse de cas d’utilisation « Gérer

département »
Description
Pour gérer les départements, l’Admin peut interagir avec le système grâce à des interfaces
dédiées à faciliter la communication :
IP_ListDepart: cette interface permet à l’Admin de consulter la liste des départements. C’est
à partir d’elle que l’Admin peut passer à une modal de création d’un nouvel
département.
IP_AjoutDepart ; Cette interface permet à l’Admin d’ajouter les départements
spécifiques à sa société.
IP_SuppDpart : cette interface permet de vérifier la décision de suppression.
Pour réaliser toutes ces opérations, le système se dote de contrôleur « control Départ »
permettant d’exécuter les fonctions. En effet, ce contrôleur extrait les données
nécessaires de la classe Département contenant les informations de tous les
départements.

63
 Chapitre III : Analyse & conception

1.4 Analyse de cas d’utilisation « Gérer

document »
Traçabilité entre le modèle de cas d’utilisation
et le modèle d’analyse du cas d’utilisation
« Gérer document »
Le diagramme ci-dessous permet d’illustrer les classes d’analyses qui participent au cas
d’utilisation « Gérer département »

Figure 27 : traçabilité de cas d’utilisation « gérer document »

64
 Chapitre III : Analyse & conception

Diagramme de classe d’analyse du cas

d’utilisation « Gérer document »

Figure 28 : Diagramme de classe d’analyse de cas d’utilisation « Gérer document »

Description
Pour gérer les documents, les utilisateurs peuvent interagir avec le système grâce à des
interfaces dédiées à faciliter la communication :
IDListDocument: cette interface permet aux utilisateurs de consulter la liste des
documents.
IDAjouDocResp : Cette interface permet au responsable de bureau d’ordre d’ajouter
les documents et les informations spécifiques de chacun.

65
 Chapitre III : Analyse & conception

IDajoutDocAdmin: cette interface permet à l’Admin de compléter les informations de

chaque document et de les enregistrer dans la base de données.
IDajoutDocChef : cette interface permet au Chef et les Sous-chef de la durée de
traitement de chaque document.
Pour réaliser toutes ces opérations, le système se dote de deux contrôleurs « control
Document qui permet d’exécuter les fonctions. En effet, ce contrôleur extrait les
données nécessaires de la classe Document contenant les informations de tous les
documents.

2 Modèle de domaine (diagramme de classe)

2.1 Définition
Le diagramme de classe est considéré comme le plus important de la modélisation orientée
objet, il est le seul obligatoire lors d’une telle modélisation.
Alors que le diagramme de cas d’utilisation montre un système du point de vue des acteurs, le
diagramme de classe en montre la structure interne. Il permet de fournir une représentation
abstraite des objets du système qui vont interagir pour réaliser les cas d’utilisation. Il est
important de noter qu’un même objet peut très bien intervenir dans la réalisation de plusieurs
cas d’utilisation
Il s’agit d’une vue statique, car on ne tient pas compte du facteur temporel dans le
comportement du système. Le diagramme de classe modélise les concepts du domaine
d’application ainsi que les concepts internes crées de toutes pièces dans le cadre de
l’implémentation d’une application. [B4]

66
 Chapitre III : Analyse & conception

2.2 Présentation de diagramme de classe

Figure 29 : Diagramme de classe

67
 Chapitre III : Analyse & conception

2.3 Identification d’association

Les associations dégagées sont les suivantes :
L’utilisateur peut être un utilisateur fonctionnel dans la société ou un utilisateur
archivé lorsque sa société nécessite son archivage.
Un utilisateur peut avoir un ou plusieurs rôles.
Un utilisateur peut recevoir ou envoyer un ou plusieurs documents au même temps.
Un utilisateur appartient à un seul département.
Un département peut comprendre plusieurs utilisateurs.
Un département peut recevoir un ou plusieurs documents.
Les utilisateurs selon leurs droits d’accès peuvent archiver un ou plusieurs documents.
 Un document peut être traité d’un ou plusieurs utilisateurs.

Conception
1 Diagramme d’activité système
1.1 Définition de diagramme d’activité système
Un diagramme d’activité permet de modéliser le comportement du système, dont la séquence
des actions et leurs conditions d’exécution. Les actions sont les unités de base du
comportement du système.
Un diagramme d’activités permet de grouper et de dissocier des actions. Si une action pet être
divisée en plusieurs actions en séquence, vous pouvez créer une activité les représentant.

68
 Chapitre III : Analyse & conception

1.2 Présentation de diagramme d’activité de

système
Diagramme d’activité système de cas
d’utilisation « Authentification »

Figure 30 : diagramme d’activité système « Authentification »

69
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer utilisateur »

1.2.2.1 Diagramme d’activité système de cas d’utilisation « Ajouter
utilisateur »

Figure 31 : diagramme d’activité système « Ajouter utilisateur »

70
 Chapitre III : Analyse & conception

1.2.2.2 Diagramme d’activité système de cas d’utilisation « Modifier

utilisateur »

Figure 32 : diagramme d’activité système « Modifier utilisateur »

71
 Chapitre III : Analyse & conception

1.2.2.3 Diagramme d’activité système de cas d’utilisation

« Supprimer/Archiver utilisateur »

Figure 33 : diagramme d’activité système « Supprimer / Archiver utilisateur »

72
 Chapitre III : Analyse & conception

1.2.2.4 Diagramme d’activité système de cas d’utilisation « Rechercher

utilisateur »

Figure 34 : diagramme d’activité système « Rechercher utilisateur »

73
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer rôle »

1.2.3.1 Diagramme d’activité système de cas d’utilisation « Ajouter rôle »

Figure 35 : diagramme d’activité système « Ajouter rôle »

74
 Chapitre III : Analyse & conception

1.2.3.2 Diagramme d’activité système de cas d’utilisation « Modifier rôle »

Figure 36 : diagramme d’activité système « Modifier rôle »

75
 Chapitre III : Analyse & conception

1.2.3.3 Diagramme d’activité système « Supprimer rôle »

Figure 37 : diagramme d’activité système « Supprimer rôle »

76
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer département »

1.2.4.1 Diagramme d’activité système de cas d’utilisation « Ajouter
département »

Figure 38 : diagramme d’activité système « Ajouter département »

77
 Chapitre III : Analyse & conception

1.2.4.2 Diagramme d’activité système de cas d’utilisation « Modifier

département »

Figure 39 : diagramme d’activité système « Modifier département »

78
 Chapitre III : Analyse & conception

1.2.4.3 Diagramme d’activité système de cas d’utilisation « Supprimer

département »

Figure 40 : diagramme d’activité système « Supprimer département »

79
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer document »

1.2.5.1 Diagramme d’activité système de cas d’utilisation « Ajouter
document »

Figure 41 : diagramme d’activité système « Ajouter document »

80
 Chapitre III : Analyse & conception

1.2.5.2 Diagramme d’activité système de cas d’utilisation « Modifier

document »

Figure 42 : diagramme d’activité système « Modifier propriété d’un document »

81
 Chapitre III : Analyse & conception

1.2.5.3 Diagramme d’activité système de cas d’utilisation « Envoyer

document »

Figure 43 : diagramme d’activité système « Envoyer un document »

1.2.5.4 Diagramme d’activité système de cas d’utilisation « Rechercher
document »

Figure 44 : diagramme d’activité système « Rechercher document »

82
 Chapitre III : Analyse & conception

1.2.5.5 Diagramme d’activité système de cas d’utilisation « Télécharger

document »

Figure 45 : diagramme d’activité système « Télécharger document »

2 Diagramme de séquence
2.1 Définition de diagramme de séquence
Le diagramme de séquence 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. Un
diagramme de séquence montre une interaction présentée en séquence dans le temps. En
particulier, il montre aussi les objets qui participent à l'interaction par leur "ligne de vie" et les
messages qu'ils échangent présentés en séquence dans le temps.
Voici quelques notions de base du diagramme :

Scénario :

Une liste d'actions qui décrivent une interaction entre un acteur et le système.

Interaction :

Un comportement qui comprend un ensemble de messages échangés par un ensemble d'objets

dans un certain contexte pour accomplir une certaine tâche.

Message :

Un message représente une communication unidirectionnelle entre objets qui transporte de

l'information avec l'intention de déclencher une réaction chez le récepteur. [B5]

83
 Chapitre III : Analyse & conception

2.2 Le modèle utilisé MVC : Modèle Vue

Contrôleur

Figure 46 : Principe de modèle MVC

Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais (Model-View-Controller) est une

architecture logicielle et une méthode de conception logicielle.
Cette méthode impose la séparation entre les données, les traitements et la présentation. C'est
pour cette raison que l'application est divisée en trois composants fondamentaux : le modèle,
la vue et le contrôleur. Chacun de ces composants tient un rôle bien défini.
La vue :
Correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est de présenter
les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les actions de
l'utilisateur (clic de souris, sélection d'une entrée, boutons…). Ces différents événements sont
envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente d'afficher les
résultats des traitements effectués par le modèle.
Le modèle :
Représente le comportement de l'application : traitements des données, interactions avec la
base de données, etc. Il décrit ou contient les données manipulées par l'application. Il assure la
gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de données,
c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre à jour ces données
(insertion, suppression, changement de valeur). Il offre aussi des méthodes pour récupérer ces
données. Les résultats renvoyés par le modèle sont dénués de toute présentation.
Le contrôleur :
Prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le
modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et déclenche les
actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande
la modification des données au modèle et ensuite avertit la vue que les données ont changé
pour qu'elle se mette à jour. Certains événements de l'utilisateur ne concernent pas les

84
 Chapitre III : Analyse & conception

données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier. Le

contrôleur n'effectue aucun traitement, ne modifie aucune donnée. [B6]

Cette méthode présente des avantages et des inconvénients :

 Ses avantages :
- Séparation des compétences (design, base de données, application) ;
- Simplicité de mise à jour ;
- Vitesse de création de pages.
 Ses inconvénients :
- Pages plus lentes à afficher.
- Plus de ressources consommées.
- Développement initial plus long.

85
 Chapitre III : Analyse & conception

2.3 Présentation des diagrammes de séquence

Diagramme de séquence de cas d’utilisation
« Authentification »

Figure 47 : diagramme de séquence « Authentification »

86
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer utilisateur »

2.3.2.1 Diagramme de séquence de cas d’utilisation « Ajouter utilisateur »

Figure 48 : diagramme de séquence « Ajouter utilisateur »

87
 Chapitre III : Analyse & conception

2.3.2.2 Diagramme de séquence de cas d’utilisation « Modifier utilisateur »

Figure 49 : diagramme de séquence « Modifier utilisateur »

88
 Chapitre III : Analyse & conception

2.3.2.3 Diagramme de séquence de cas d’utilisation « Supprimer/Archiver

utilisateur »

Figure 50 : diagramme de séquence « Supprimer / Archiver utilisateur »

89
 Chapitre III : Analyse & conception

2.3.2.4 Diagramme de séquence de cas d’utilisation « Rechercher

utilisateur »

Figure 51 : diagramme de séquence « Rechercher utilisateur »

2.3.2.5 Diagramme de séquence de cas d’utilisation « Consulter

utilisateur »
Ce diagramme illustre le cas d’utilisation de la consultation les informations par tous les
utilisateurs à partir de la base de données après authentification.
L’utilisateur doit tout d’abord s’authentifier avant de réaliser cette tâche.

Figure 52 : diagramme de séquence « Consulter utilisateur »

90
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer rôle »

2.3.3.1 Diagramme de séquence de cas d’utilisation « Ajouter rôle »

Figure 53 : diagramme de séquence « Ajouter rôle »

91
 Chapitre III : Analyse & conception

2.3.3.2 Diagramme de séquence de cas d’utilisation « Modifier rôle »

Figure 54 : diagramme de séquence « Modifier rôle »

92
 Chapitre III : Analyse & conception

2.3.3.3 Diagramme de séquence de cas d’utilisation « Supprimer rôle »

Figure 55 : diagramme de séquence « Supprimer rôle »

93
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer département »

2.3.4.1 Diagramme de séquence de cas d’utilisation « Ajouter
département »

Figure 56 : diagramme de séquence « Ajouter département »

94
 Chapitre III : Analyse & conception

2.3.4.2 Diagramme de séquence de cas d’utilisation « Modifier

département »

Figure 57 : diagramme de séquence « Modifier département »

95
 Chapitre III : Analyse & conception

2.3.4.3 Diagramme de séquence de cas d’utilisation « Supprimer

département »

Figure 58 : diagramme de séquence « Supprimer département »

96
 Chapitre III : Analyse & conception

Cas d’utilisation « Gérer document »

2.3.5.1 Diagramme de séquence de cas d’utilisation « Ajouter document »

Figure 59 : diagramme de séquence « Ajouter document »

97
 Chapitre III : Analyse & conception

2.3.5.2 Diagramme de séquence de cas d’utilisation « Modifier propriété

de document »

Figure 60 : diagramme de séquence « modifier propriété document »

98
 Chapitre III : Analyse & conception

2.3.5.3 Diagramme de séquence de cas d’utilisation « Envoyer document »

Figure 61 : diagramme de séquence « Envoyer document »

2.3.5.4 Diagramme de séquence de cas d’utilisation « Rechercher

document »

Figure 62 : diagramme de séquence « Rechercher document »

99
 Chapitre III : Analyse & conception

3 Diagramme de déploiement
3.1 Définition de diagramme de déploiement
Un diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de
l’infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que leurs relations entre eux.
Les éléments utilisés par un diagramme déploiement sont principalement les nœuds, les
composants, les associations et les artefacts.
Les caractéristiques des ressources matérielles physiques et des supports de communication
peuvent être précisées par stéréotype. [B7]

100
 Chapitre III : Analyse & conception

3.2 Présentation de diagramme de déploiement

Figure 63 : diagramme déploiement

Conclusion
Dans ce chapitre nous nous somme focalisés sur la partie fonctionnelle du projet, sa
conception ainsi que les différents diagrammes des processus réalisés.
Nous passons à la partie suivante dans laquelle nous présentons l’environnement de travail et
l’implémentation de la base de données et de l’application.

101
Chapitre IV : Réalisation & mise en œuvre

Introduction
I Environnement de développement
1 Environnement matériel
2 Environnement logiciel
II Création de base de données
III Réalisation de l’ensemble de pages
1 Création de la structure d’une page
Conclusion

102
Chapitre IV : Réalisation
& mise en œuvre

Introduction

103
 Chapitre IV : Réalisation & mise en œuvre

Environnement de développement
L’environnement de réalisation englobe le matériel, les logiciels ainsi que les outils de
programmation utilisés pour le développement de l’application.

1 Environnement matériel
L’application est développée sur deux machines :
Machine 1 : ASUS Machine 2 : HP
Modèle : Modèle :
Processeur : Intel Core i7-4750HQ CPU @ Processeur : Intel Pentium CPU B980 @
2.00GHz 2.00GHz 2,40GHz 2,40GHz
Mémoire installée (RAM) : 8,00Go Mémoire installée (RAM) : 6,00Go
Type système : Windows 10 professionnel Type système : Windows 8.1
Système d’exploitation : 64bits Système d’exploitation : 64bits

2 Environnement Logiciel
2.1 Tomcat
Dans ce projet, on s’intéresse à un conteneur de servlet et non pas à un serveur d’application
complet communément connu sous le nom de serveur lourd, d’où l’utilisation d’Apache
Tomcat, qui est un conteneur libre de servlets (conteneur web) et JSP.
Il comporte également un serveur HTTP permettant la gestion des requêtes HTTP entre le
client et le conteneur web. Ce logiciel, dans sa version 7, est intégré à STS durant le
développement de l’application, et utilisé séparément après le déploiement. [B8]

Figure 64 : Logo Tomcat

2.2 STS (Spring Tool Suit)
Logiciel très utilisé par la société Educanet pour le développement des applications.

104
 Chapitre IV : Réalisation & mise en œuvre

Il est un environnement de développement basé sur Eclipse qui est personnalisé pour le
développement d'applications Spring. Il fournit un environnement prêt à l'emploi pour
implémenter, déboguer, exécuter et déployer vos applications Spring et vient s'ajouter aux
dernières versions d’Eclipse. [B9]

Figure 65 : Logo STS

2.3 Plateforme de développement JEE

La plateforme Java Entreprise Edition est une norme qui vise à définir un standard de
développement d’applications d’entreprises, et qui permet de réduire de manière significative
le coût et la complexité du développement, du déploiement et la gestion de ces applications.
Construite à la base du framework JSE, JEE ajoute des bibliothèques additionnelles
dédiées à des applications professionnelles. Ces dernières fonctionnent sur le même JRE
qu’une
application Java SE, mais nécessitent la présence d’un conteneur Java comme Tomcat.
Le choix de cette plateforme n’est pas arbitraire vu que l’ensemble des modules du mini ERP
sont développés sous JEE. [B10]

105
 Chapitre IV : Réalisation & mise en œuvre

Figure 66 : Logo java j2ee

2.4 Java script

JavaScript est un Le Javascript est un langage de script incorporé

dans un document HTML. Historiquement il s'agit même du
premier langage de script pour le Web. Ce langage est un langage
de programmation qui permet d'apporter des améliorations au
langage HTML en permettant d'exécuter des commandes du côté
client, c'est-à-dire au niveau du navigateur et non du serveur web.
[B11]

Figure 67 : Logo JavaScript

2.1 Spring
Spring est considéré comme un conteneur dit « léger ». La raison de ce nommage est très bien
expliquée par Erik Gollot dans l’introduction du document Introduction au framework Spring.
« SPRING est effectivement un conteneur dit “ léger ”, c’est-à-dire une infrastructure
similaire à un serveur d’applicationJ2EE. Il prend donc en charge la création d’objets et la
mise en relation d’objets par l’intermédiaire d’un fichier de configuration qui décrit les objets
à fabriquer et les relations de dépendances entre ces objets. Le gros avantage par rapport aux
serveurs d’application est qu’avec SPRING, vos classes n’ont pas besoin d’implémenter une
quelconque interface pour être prises en charge par le Framework (au contraire des serveur
d’application J2EE et des EJBs). C’est en ce sens que SPRING est qualifié de conteneur “
léger ”. »
Spring s’appuie principalement sur l’intégration de trois concepts clés :

 L’inversion de contrôle est assurée de deux façons différentes : la recherche de

dépendances et l’injection de dépendances
 La programmation orientée aspect
 Une couche d’abstraction.

La couche d’abstraction permet d’intégrer d’autres Framework et bibliothèques avec une plus
grande facilité. Cela se fait par l’apport ou non de couches d’abstraction spécifiques à des
Framework particuliers. Il est ainsi possible d’intégrer un module d’envoi de mails en toute
facilité. [B12]

2.2 Spring Security

Spring Security est un framework utilisé lors de l'implémentation de la fonction de contre-
mesure de sécurité dans l'application. Spring Security peut également être utilisé dans une
application autonome, mais il est généralement utilisé lors de la mise en œuvre des contre-
mesures de sécurité pour l'application Web déployée dans le conteneur de servlet. Ce chapitre

106
 Chapitre IV : Réalisation & mise en œuvre

décrit uniquement les fonctions fournies par Spring Security, considérées comme
fréquemment utilisées dans les applications Web générales. [B13]

2.3 WampServer

Nous allons utiliser WampServer puisque c’est une plate-forme de développement Web sous
Windows pour des applications Web dynamiques. Il nous a permis
donc de pouvoir concevoir le site web transactionnel en local sur mon
ordinateur. WampServer est une plate-forme de développement Web
sous Windows. Il permet de développer des applications web
dynamiques à l'aide du serveur Apache2, du langage de scripts PHP et
d'une base de données MySQL. Il possède également PHPMyAdmin
pour gérer plus facilement nos bases de données. [B14]

Figure 68 : Logo WampServer

2.4 MySQL
MySQL est un serveur de bases des données qui stocke les données dans des tables séparées
plutôt que de tout rassembler dans une seule table. Cela améliore la rapidité et la souplesse de
l'ensemble. Les tables sont reliées par des relations définies,
qui rendent possible la combinaison de données entre
plusieurs tables durant une requête. Le SQL dans "MySQL"
signifie "Structured Query Language" : le langage standard
pour les traitements de bases de données. [B15]

Figure 69 : Logo MYSQL

2.5 Font-Awesome
Font Awesome est une police d'écriture et un outils d'icônes qui se base
sur CSS, LESS et SASS. Elle a été créée par Dave Gandy afin d'être utilisée
avec Bootstrap. [B20]

107
 Chapitre IV : Réalisation & mise en œuvre

2.6 HTML5
C'est un langage de description des documents dont le rôle est de formaliser l'écriture
d'un document avec des balises de formatage.
Il permet notamment la lecture de documents sur internet à
partir de machines différentes, grâce au protocole HTTP,
permettant d'accéder via le réseau à des documents repérés
par une adresse unique, appelée URL.
Cette version apporte de nombreuses améliorations comme
la possibilité d'inclure facilement des vidéos, un meilleur
agencement du contenu, de nouvelles fonctionnalités pour
les formulaires etc.[B16]
Figure 70 : Logo HTML5

2.7 CSS3

CSS est l'acronyme de Cascading Style Sheets, c'est un langage de

feuille de style utilisé pour décrire la mise en forme d'un document écrit
avec un langage de balisage. Il permet aux concepteurs de contrôler
l'apparence et la disposition de leurs pages web. [B17]

Figure 71 : Logo CSS3

2.8 JQUERY
Comme PHP assure la dynamité du site web côté serveur, jQuery l'assure coter client.
JQuery est une bibliothèque JavaScript qui assure la
communication serveur/client (généralement avec un script PHP)
sans avoir à recharger la page, on entend par là AJAX, mais pas
seulement ça, il gère aussi les animations des éléments de la
page, et dispose d'un sélecteur CSS très puissant, et qui fait toute
sa puissance. [B18]

108
 Chapitre IV : Réalisation & mise en œuvre

Figure 72 : Logo JQUERY

2.9 BootStrap

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.[B19]

Figure 73 : Logo Bootstrap

Création de base de données

Tout d’abord il est nécessaire de mettre en place une base de données. En effet, une donnée
saisie par l’utilisateur n’a de l’intérêt que si elle peut être exploitée après son enregistrement
dans une base de données. « PHPMyAdmin » nous a permis de la créer au plus vite. De plus
son utilisation est tellement simple qu’il suffit de quelques clics pour créer une table. Toutes
nos réunions ont permis de dégager les fonctionnalités qu’il y aurait à implémenter. Voici
donc les tables qui leur correspondent et les fonctionnalités.

Figure 74 : La base de données de l'application

Notre base de données est composée des six tables suivantes :
User_information : la table utilisateur de l’application
User_role : gérer tous les rôles de l’application
User_département : gérer tous les départements de l’application
Document : gérer la liste des documents disponibles
Authorities : Table relation entre la table User_information et User_role
Hebernete_sequence :

Réalisation de l’ensemble de pages

1 Création de la structure d’une page
L’application doit être simple d’utilisation et de navigation, que ce soit dans ses
fonctionnalités ou que ce soit dans son contenu.

109
 Chapitre IV : Réalisation & mise en œuvre

Pour faciliter la navigation, il est obligatoire que l’ensemble des pages de l’application web
possèdent la même structure et organisation. Cela permet d’avoir une logique dans la structure
des pages, mais aussi de ne pas gêner la navigation de l’utilisateur, à cause des différentes
structures de page à chaque changement de page.
Cela permet d’avoir une logique dans la structure des pages, mais aussi de ne pas gêner la
navigation de l’utilisateur, à cause des différentes structures de page à chaque changement de
page.
Pour cela, nous allons réaliser un modèle pour la structure des pages que vous pouvez
observer ci-dessous. La totalité des pages visibles par l’utilisateur posséderont cette même
structure :
- Un en-tête de page avec le logo du GROUP EDUCANET TUNISIE et le nom de
l’utilisateur.
- Un menu de navigation complet.
- Le contenu qui se modifiera selon les pages.
- Un pied de page avec l’ensemble des liens et infos pratiques.

Figure 75 : La structure d’une page

L’intérêt de procéder ainsi est que seul le contenu du site varie d’une page à l’autre, c’est
pourquoi de page en page on inclue toujours le même en-tête, le même menu de navigation et
le même pied de page. Cela évite de devoir implémenter à nouveau chaque partie de
l’application, ce qui entraine un gain de temps considérable.

A. L’en-tête :

Figure 76 : L'en-tête de page

La structure de chacune des pages est désormais établie, je vais vous présenter les différents
éléments que comporte chacune des pages à commencer par L’en-tête.

110
 Chapitre IV : Réalisation & mise en œuvre

L’en-tête est présent sur toutes les pages de l’application, elle est composée ; à gauche, de
logo et le nom de l’application, a droit, s’affiche le User Name de la personne qui se connecte,
il peut consulter son profil, modifier ses informations et de se déconnecter de l’application.

Cette figure montre

Cette figure montre

B. Le menu de navigation

111
 Chapitre IV : Réalisation & mise en œuvre

Le menu de navigation est un élément

primordial dans la présentation d’une
application web. En effet, il doit permettre de
rejoindre facilement les autres pages de
l’application web.
Le menu qui a été réalisé pour le site web de la
section locale fut réalisé avec JavaScript. Le
menu dispose de sept onglets pour naviguer,
l’onglet accueil correspond le tableau de bord de
l’application, l’onglet Document correspond à la
page de liste de chaque type de document,
l’onglet Tables contient deux interfaces, la
premier représente un tableau de tous les
document importer dans l’application et la
deuxième interface représente un autre tableau
qui contient tous les utilisateurs de l’application
et leurs informations.
L’onglet Unité administrative, et comme
l’indique son nom, elle représente un ensemble
des interfaces spécifiques à l’administration.
L’onglet Calendrier : une simple interface pour marquer les évènements important avec le
degré d’importance.
L’onglet E-mail : c’est une interface qui permet de rédiger un E-mail et de l’envoyer d’après
d’application.
Le dernier onglet Archive correspond à l’archive de document ou des utilisateurs.

112
 Chapitre IV : Réalisation & mise en œuvre

C. Le contenu

Le contenu de chacune des pages est la partie la plus importante de l’application web. Il
sera entièrement dynamique et modifiable par l’intermédiaire d’un espace spécifiques a
chaque utilisateur. L’ensemble du contenu sera entièrement stocké dans la base de
données relationnelle MySQL et sera modifié par des scripts JEE exécutés lors d’envoi de
formulaires venant de l’espace de l’utilisateur. Ce type de rubrique est extensible en
hauteur à l’infinie ce qui permettra de s’adapter à n’importe quelle taille de contenu saisi
par l’utilisateur.

D. Le pied de page

Le pied de page se trouvera dans la totalité des pages. Cette partie regroupera le copyright et
l’ensemble des liens utiles.

2 Interfaces de l’application
L’une des premières priorités dans la création d’une application est de procurer à
l’utilisateur une interface simple d’utilisation avec une navigation facile et une aide ciblée et
performante. Dans ce qui suit, nous allons présenter les principales interfaces de notre
application pour la mieux comprendre. Notre application met à la disposition des utilisateurs
enregistrés un espace de travail, accessible par un nom utilisateur (User Name) et un mot de
passe qui leur offre par le biais d’une interface simple et pratique des services spécifiques
permettant de gérer automatiquement tous les éléments de la gestion des tâches citées
précédemment et qui peut les consulter n’importe quel navigateur.
2.1 Interface d’authentification
En tant qu’utilisateur enregistré, l’espace de travail lui permet certaines fonctionnalités. Ces
dernières dépendent du rôle de l’utilisateur.
Une fois l’utilisateur lance l’application, l’interface initiale est la suivante :

113
 Chapitre IV : Réalisation & mise en œuvre

Renseignez les deux lignes avec vos coordonnées de connexion ; votre mot de passe
apparaît sous forme d’étoile () pour éviter que quelqu’un ne lise à l’écran le mot de
passe que vous tapez.
Bien entendu, vous validez votre saisie par le bouton « Login ».
Deux cas possibles peuvent se produire :
 UserName et / ou le mot de passe est incorrect donc retour à la même interface.
 L’identification est réussie et vous accédez à l’interface principale.

2.2 Réalisation de l’espace principale

Après la réussite d’authentification, s’affiche l’interface d’accueil présenté ci-dessous.

Page d’accueil

114
 Chapitre IV : Réalisation & mise en œuvre

2.3 Interface côte administrateur

Les pages spécifiques à l’administrateur est trouvé dans l’unité administrative, elles contient
trois sous menu :
 Interface de Rôle
 Interface de département
 Interface d’utilisateur

Interface Rôle

Cette interface donne à L’administrateur l’opportunité de :

 Ajouter un rôle d’une façon dynamique
 Consulter la liste de rôle enregistré dans l’application
 Deux actions peuvent s’exercer sur un rôle sélectionné : la suppression et l’édition

Figure : ajouter nouveau rôle

Cette interface permet à l’administrateur de saisir le nom de rôle et de choisir son type.

Figure : liste de type de rôle

115
 Chapitre IV : Réalisation & mise en œuvre

L’Admin doit choisie un type à chaque rôle pour limite les accès qui son définie
manuellement dans un class intitulé « Security-contexte ».

Figure : liste des rôles

La figure ce dessus présente la liste des rôles enregistré dans l’application et les deux
actions que l’Admin peut l’exercer sur un rôle.

Interface département

Cette interface donne à L’administrateur l’opportunité de :

 Ajouter un département d’une façon dynamique
 Consulter la liste de département enregistré dans l’application
 Deux actions peuvent s’exercer sur un département sélectionné : la suppression et
l’édition

Figure : Ajouter un nouveau département

116
 Chapitre IV : Réalisation & mise en œuvre

Cette interface permet à l’administrateur de saisir le nom de département et de choisir son

type.

Figure : liste de type de département

L’Admin doit choisie un type à chaque département.

Figure : liste des départements

La figure ce dessus présente la liste des départements enregistré dans l’application et
les deux actions que l’Admin peut l’exercer sur un rôle.

117
 Chapitre IV : Réalisation & mise en œuvre

Interface d’utilisateur
Cette interface permet à l’Admin d’ajouter un nouvel utilisateur de l’application par
l’attribution de :

 Informations de base qui sont : le nom, le prénom et l’adresse E-mail pour créer un
compte à chaque utilisateur

 Informations professionnel qui sont : le rôle qui peut être un ou plusieurs et le

département de chaque utilisateur.

 Login : saisir un UserName et un mot de passe à chaque compte qui peut être
modifiable par son propre utilisateur.

Figure : Ajouter les informations de base

118
 Chapitre IV : Réalisation & mise en œuvre

Cette interface est spécifique pour l’ajout de nom, de prénom et de l’adresse mail de
chaque nouvel utilisateur et cela pour la création d’un nouveau compte.

Figure : Ajouter les informations professionnelles

A partir de cette interface l’Admin peut attribuer les rôles et le département à chaque
utilisateur ajouté.

Figure : liste des rôles

Cette figure montre la liste des rôles enregistré dans l’application et qui sont saisis par
l’administrateur comme il montre la figure « ajouter rôle »

119
 Chapitre IV : Réalisation & mise en œuvre

Figure : liste des Départements

Cette figure montre la liste du département enregistré dans l’application et qui sont saisis par
l’administrateur comme il montre la figure : ajouter département

Figure : Login

L’Admin peut saisir un User Name et mot de passe de chaque utilisateur a partir de cette
interface.

120
 Chapitre IV : Réalisation & mise en œuvre

2.4 Interface Coté tous les utilisateurs

Les tables
Notre application possède deux grandes tables :
 Table des utilisateurs qui possède quelques informations sur l’utilisateur
 Table de document qui représente la liste de tous les documents enregistrés dans
l’application.

2.4.1.1 Table utilisateur

Figure : Liste des utilisateurs

Cette interface présente la table de liste des utilisateurs enregistré dans l’application et
représente aussi les actions qui peut être effectué à un utilisateur sélectionné.
Notre application donne la main à ses utilisateurs de faire une recherche facile et rapide soit
par alphabet ou par colonne à partir de l’icône ce dessous

121
 Chapitre IV : Réalisation & mise en œuvre

Figure : icone de recherche

2.4.1.2 Table document

Figure : table de document

Cette table représente la liste de tous les documents enregistrés dans l’application sans
classification.
Notre application donne la main à ses utilisateurs d’affecter un nombre des actions sur le
document sélectionné selon leurs droit d’accès.

Voir les détails de document sélectionne.

Cet butons est visualisé par tous les utilisateurs.

Editer les informations de document sélectionné

Cet butons est visualisé juste par l’Admin

Télécharger le document sélectionné

Cet butons est visualisé par tous les utilisateurs

Ouvrir le document sélectionné dans le navigateur

Cet butons est visualisé par tous les utilisateurs

Envoyer le document sélectionné

Cet butons est visualisé par tous les utilisateurs

122
 Chapitre IV : Réalisation & mise en œuvre

Archiver le document sélectionné

Cet butons est visualisé juste par l’Admin

2.4.1.3 Import document

A travers de l’interface ce dessous, les utilisateurs saisies le titre, le type qui est nécessaire pour la
classification de document, l’expéditeur de document qui apparaisse juste pour ceux qui ont le rôle
responsable de bureau d’ordre et finalement tous les utilisateurs peuvent donner une description
pour chaque document.

Figure : Importer document

2.4.1.4 Calendrier
Cette interface utilisé pour facilite l’enregistrement des évènements marquante au sein de la société,
ces évènements sont classé selon le niveau d’urgence. L’utilisateur peut modifier le titre, la durée et
l’emplacement de chaque évènement.
L’interface calendrier donne à l’utilisateur l’opportunité d’ajouter et de consulter les évènements :

- par jours
- par semaine
- Par mois

123
 Chapitre IV : Réalisation & mise en œuvre

Figure : Calendrier

Pour naviguer entre les mois, les semaines et les jours on va utiliser ces deux buttons qui indiquent
suivant et précédent. Et on ajoute un autre button pour retourner facilement à la date d’aujourd’hui.

124
 Chapitre IV : Réalisation & mise en œuvre

125
 Chapitre IV : Réalisation & mise en œuvre

126
 Chapitre IV : Réalisation & mise en œuvre

La sécurité de l’application :
L’application étant restreinte d’utilisation à un certain nombre de personnes, la sécurité
permet d’interdire l’accès à l’interface ou à des pages spécifiques exécutant des fonctions
d’administration. Ces interdictions sont liées essentiellement à l’accès à une page par son url.
Sans sécurité, une personne peut deviner une url valide et ainsi passer la barrière de la page de
connexion. De la même façon, l’accès aux pages d’administration via des liens apparaissant
que si le rôle de la personne est suffisant peut être possible. Une fois implémentée, la sécurité
est assurée en vérifiant l’url de destination et si la personne est connectée (cela implique aussi
que la session de l’utilisateur n’est pas expirée) et possède des droits suffisants. En cas de
tentative non autorisée, une erreur est créée et transmise à l’utilisateur.

Conclusion
Au cours de ce chapitre, nous avons présenté les différents outils de développement ainsi que
des aperçus d’écran témoignant les différentes facettes de notre projet. Dans la phase de
réalisation, nous avons développé les éléments constituant notre application tout en
respectant aussi bien les besoins que la conception a élaborés. Il nous reste maintenant que de
conclure et de récapituler les apports de ce projet ainsi que les perspectives possibles.

127
 Conclusion générale

L’objectif du présent projet était la réalisation une application web de gestion de

document électronique.
Pour ce faire, nous étions invités dans un premier temps à présenter le cadre général de
notre projet en présentant l’organisme d’accueil et la problématique. Ensuite, nous
avons exposé l’étude de l’existant et la spécification des besoins. L’étape suivante
consiste en l’analyse et la conception. Et enfin, nous avons exposé le travail réalisé à
travers des imprimes écran. La réalisation de mon stage m’a permis d’acquérir trois
principaux apports, ceux-ci sont les plus substantiels, pour moi, puisqu’ils se sont
révélés, lors de la rédaction de mon rapport, immédiatement.
 Le premier apport, sur un plan personnel, de ce stage aura été sans aucun
doute, le devoir d’accomplir des objectifs dans un temps limité. Cet apport est
substantiel pour nous puisqu’il conditionne le fait, dans l’avenir d’être
performant dans notre profession. Savoir gérer notre temps afin de remplir des
objectifs fixés à l’avance, est crucial dans le monde professionnel.
 Le deuxième apport, obtenu par la réalisation de ce stage, est le travail en
équipe : nous nous sentions au fur et à mesure du déroulement du stage,
membre à part entière de l’équipe managé par notre encadreur. Le sentiment
d’appartenance relative à cette équipe fut exacerbé par une relation quotidienne
dans la normalité des choses. Cet apport est important pour nous dans la
mesure où le travail en équipe permet de prendre conscience de
l’interdépendance des acteurs la composant pour la progression plus ou moins
rapide du travail personnel produit.
 Le troisième apport majeur procuré par ce stage, est la découverte du milieu
professionnel. Avec la découverte de professionnels, dans leur milieu, dans
leur travail au quotidien, dans leur manière d’aborder une problématique et de
la résoudre. En observant leurs comportements, cela nous a beaucoup apporté,
d’un point de vue pratique, ce dont l’enseignement universitaire est incapable
de donner.

128
 Bibliographies
[B1] : https://www.supinfo.com/articles/single/6437-fonctionnement-une-architecture-trois-tiers
[B2] : https://www.utc.fr/~wschon/lo19/Tutorial%20Rational%20Rose.pdf

[B3] : http://remy-manu.no-ip.biz/UML/Cours/coursUML2.pdf
[B4] https://laurentaudibert.developpez.com/CoursUML/?page=diagramme-classes

[B5] Sequence

[B6] http://www.labri.fr/perso/johnen/pdf/IUT-Bordeaux/OMGL3/TD7-DesignPattern.pdf
[B7] https://fr.wikipedia.org/wiki/Diagramme_de_d%C3%A9ploiement
[B8] tomcat

[B9] https://spring.io/tools/sts
[B10] jee

[B11] https://www.commentcamarche.com/contents/577-javascript-introduction-au-langage-
javascript

[B12] http://dictionnaire.sensagent.leparisien.fr/Spring%20framework/fr-fr/
[B13] spring security

[B14] http://www.wampserver.com/

[B15] https://wiki.phpnet.org/index.php/Definitions

[B16] https://www.commentcamarche.com/contents/498-html-langage#html-5

[B17] https://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade
[B18] JQUERY

[B19] https://fr.wikipedia.org/wiki/Bootstrap_(framework)
[B20]https://www.google.fr/search?q=fontawesome&source=lnms&tbm=isch&sa=X&ved=0ahUKE
wj5srDR_KvbAhUCjqQKHWAcAVAQ_AUICigB&biw=1366&bih=588

129
130
131
132
133