mémoiredpgr 14.07.2010
TRANSCRIPT
Ministère de l’enseignement supérieur et de la recherche scientifique
Ecole nationale Supérieure d’Informatique (ESI) ex. (INI)
Oued-Smar Alger
Mémoire de fin d’études
Pour l’obtention du diplôme d’ingénieur
d’état en informatique
Option : Systèmes d’information
Thème
Conception et réalisation d’un site web dynamique pour le suivi
des activités pédagogiques et scientifiques de la DPGR de
l’ESI
Promotion : 2009/2010
Réalisé par :
FELLAH Abdeldjalil
HEBBACHE Khaled
Proposé par :
M. MEDJAOUI Nadji
M. BALLA Amar
Remerciements
C’est avec l’aide de Dieu qu’a vu le jour ce présent travail.
Ensuite, il n’aurait pas pu être achevé sans le soutien, les conseils et les encouragements de
certaines personnes auxquelles nous tenons ici à exprimer nos sincères remerciements.
En premier lieu, nous exprimons toute notre gratitude pour Nos Promoteurs, Monsieur N.
MEDJAOUI et Monsieur A. BALLA pour leurs précieux conseils, leurs disponibilité, la
confiance qu’ils nous ont toujours témoigné et la sollicitude dont ils nous ont entouré, et ce
tout au long de l’élaboration du présent travail.
Nous n’oublions pas non plus Nos Enseignants, qui tout au long du cycle d’études à l’Ecole
nationale Supérieure d’Informatique, nous ont transmis leur savoir.
Nous adressons une pensée particulièrement affective à Nos Amis de l’ESI qui ont rendu
agréables nos longues années d’études.
Nous remercions tout particulièrement Les Membres du Jury, pour avoir accepté de participer
en tant qu'Examinateurs à notre soutenance.
Nous tenons enfin à remercier tous ceux qui ont collaborés de près ou de loin à l’élaboration
de ce travail. Qu’ils acceptent nos humbles remerciements.
Abdeldjalil & Khaled
Dédicaces
À mes très chers parents à qui j`ai transmis mon stress et anxiété, pour leur affection, leur
patience, leur soutien et leurs encouragements qui m` ont permis d’arriver au bout de ce
travail.
À mes frères que je les aime énormément.
À mon binôme Abdeljalil que j`estime beaucoup.
À toute ma famille, à tous mes amis.
Khaled
A Ma Mère.
A Mon Père.
A mes chers frères Abdelhamid et Abderrahmane.
A Tous les Membres de Ma Famille.
A tous mes Amis et à Tous les Collègues de Promotion.
Je dédie ce modeste travail.
Abdeldjalil
Résumé:
Ce projet entre dans le cadre du projet de la mise-en-place d’un système d’informations au
niveau de la Direction de la Post Graduation et de la Recherche (DPGR) de l’Ecole nationale
Supérieur de l’Informatique (ESI, ex-INI),afin d’augmenter la productivité de la
direction par l’automatisation (au maximum) des procédures de travail actuelles telle
que les inscriptions des candidats au concours, les inscriptions des étudiants en début de
l`année, la saisie et la consultation des notes, la gestion des absences des étudiants, les
soutenances, les activités scientifiques ainsi que les projets de recherche.
Les services du système sont destinés au personnel de la direction, les étudiants et les
enseignants.
La réalisation d’un tel système nécessite une étude approfondie de tous ces aspects ainsi que
les perspectives des solutions possibles. Ce travail fait l'objet de notre projet de fin d'étude
intitulé « Conception et réalisation d’un site web dynamique pour le suivi des activités
pédagogiques et scientifiques de la DPGR de l’ESI ».
Mots clés :
Site web dynamique, concours, scolarité, activité pédagogique, post graduation, école
doctorale, activité scientifique et projet de recherche.
SOMMAIRE
I. INTRODUCTION GENERALE : .................................................................................................... 2
II. ETUDE DE L’EXISTANT : ............................................................................................................ 5
II.1. Introduction : ______________________________________________________________ 5
II.2. Présentation de l’organisme d’accueil : _________________________________________ 6
II.2.1. Présentation de l’ESI : ______________________________________________________________ 6
II.2.2. Présentation de la DPGR de l’ESI : ____________________________________________________ 7
II.3. Présentation du sujet : ______________________________________________________ 8
II.3.1. Système actuel : ____________________________________________________________________ 8
II.3.2. Problématique : ____________________________________________________________________ 8
II.3.3. Objectifs de l’étude : ________________________________________________________________ 8
II.4. Etude des acteurs de système : ________________________________________________ 9
II.4.1. Liste des acteurs : ___________________________________________________________________ 9
II.4.2. Les tâches des acteurs : _____________________________________________________________ 10
II.5. Etude des procédures de travail : ____________________________________________ 11
II.5.1. Liste des procédures de travail : _____________________________________________________ 11
II.5.2. Etude détaillée des procédures : ______________________________________________________ 11
II.6. Etude de quelques documents : ______________________________________________ 28
II.7. Etude quantitative : ________________________________________________________ 30
II.8. Diagnostics de la situation existante : _________________________________________ 30
II.8.1. Recensement des anomalies : ________________________________________________________ 30
II.8.2. Diagnostic du système : ____________________________________________________________ 32
II.8.3. Suggestions : ______________________________________________________________________ 32
II.9. Conclusion : ______________________________________________________________ 33
III. ANALYSE : ................................................................................................................................... 35
III.1. Introduction : ____________________________________________________________ 35
III.2. Analyse fonctionnelle : ____________________________________________________ 36
III.2.1. Identification des acteurs : _________________________________________________________ 36
III.2.2. Le diagramme de contexte du système : ______________________________________________ 38
III.2.3. Identification des cas d’utilisation : __________________________________________________ 38
III.2.4. Description détaillée des cas d’utilisations du système : _________________________________ 41
III.2.5. Regroupement des cas d’utilisation en package : _______________________________________ 62
III.3. Analyse statique : _________________________________________________________ 66
III.3.1. Identification des classes candidates : ________________________________________________ 66
III.3.2. Description détaillée des classes d’objet : _____________________________________________ 72
III.3.3. Description détaillée des classes d’association : ________________________________________ 77
III.4. Analyse dynamique : ______________________________________________________ 78
III.4.1. Les Diagrammes de séquences : _____________________________________________________ 78
III.4.2. Les Diagrammes des états / transitions : ______________________________________________ 84
III.5. Conclusion : _____________________________________________________________ 88
IV. CONCEPTION : ........................................................................................................................... 90
IV.1. Introduction : ____________________________________________________________ 90
IV.2. Conception du système (conception générale) :_________________________________ 91
IV.2.1. Schéma de l’architecture du nouveau système : ________________________________________ 91
IV.2.2. Les avantages de l’architecture multi tiers: ___________________________________________ 92
IV.2.3. Les inconvénients de l’architecture multi tiers: ________________________________________ 92
IV.2.4. Description des serveurs : __________________________________________________________ 92
IV.2.5. Principe de fonctionnement : _______________________________________________________ 94
IV.2.6. Découpage du système en sous-systèmes : _____________________________________________ 95
IV.2.7. Présentation des sous-systèmes : _____________________________________________________ 95
IV.2.8. Gestion de la persistance de données : ________________________________________________ 98
IV.3. Conception des objets (conception détaillée) : __________________________________ 99
IV.3.1. Schéma général de l’implémentation : _______________________________________________ 100
IV.3.2. Implémentation des classes d’objet : ________________________________________________ 100
IV.3.3. Implémentation des classes d’association : ___________________________________________ 105
IV.3.4. Passage du modèle objet au modèle relationnel : ______________________________________ 106
IV.3.5. Implémentation des classes de contrôle : _____________________________________________ 107
IV.3.6. Implémentation des classes de dialogue (IHM) : ______________________________________ 108
IV.3.7. Codification : ____________________________________________________________________ 111
IV.4. Conclusion : ____________________________________________________________ 112
V. IMPLEMENTATION : ................................................................................................................ 114
V.1. Introduction : ____________________________________________________________ 114
V.2. Le diagramme de déploiement : _____________________________________________ 115
V.3. Outils de développement : __________________________________________________ 116
V.4. Présentation du prototype réalisé (Imp. écr.) : _________________________________ 118
V.5. Sécurité du système : ______________________________________________________ 125
V.5.1. Vue générale sur le système à sécuriser : _____________________________________________ 125
V.5.2. Facteurs de risque et mesures de sécurité : ____________________________________________ 126
V.5.3. Qualités sécuritaires du nouveau système : ___________________________________________ 129
V.6. Conclusion : _____________________________________________________________ 132
VI. CONCLUSION GÉNÉRALE : .................................................................................................. 134
VI.1. Conclusion : ____________________________________________________________ 134
VI.2. Perspectives : ___________________________________________________________ 134
VII. REFERENCES : ........................................................................................................................ 135
VII.1. Bibliographie : _________________________________________________________ 135
VII.2. Webographie : __________________________________________________________ 135
VIII. ANNEXE : ................................................................................................................................ 137
VIII.1. Comment calculer les frais de séjours (montant d’allocation) : _________________ 137
VIII.2. Captcha: ______________________________________________________________ 138
VIII.3. Ajax : ________________________________________________________________ 142
Liste des figures
Figure 1.Démarche de développement .................................................................................................... 3
Figure 2. Organigramme de la DPGR ..................................................................................................... 7
Figure 3 : Diagramme de contexte du système ..................................................................................... 38
Figure 4 : Cas d’utilisation N°1 « Authentification » ............................................................................ 41
Figure 5 : Cas d’utilisation N°2 « Gestion des utilisateurs » ................................................................ 42
Figure 6 : Cas d’utilisation N°3 «Publication des messages d’accueil » ............................................... 43
Figure 7 : Cas d’utilisation N°4 «Initialisation de l’année scolaire » .................................................... 44
Figure 8 : Cas d’utilisation N°5 « Détermination des options et des modules » ................................... 45
Figure 9 : Cas d’utilisation N°6 «Inscription des candidats au concours » ........................................... 46
Figure 10 : Cas d’utilisation N°7 «Gestion des convocations » ............................................................ 47
Figure 11 : Cas d’utilisation N°8 «Affectation des candidats aux salles» ............................................. 48
Figure 12 : Cas d’utilisation N°9 «Détermination de résultat de concours » ........................................ 49
Figure 13 : Cas d’utilisation N°10 «Inscription scolaire » .................................................................... 50
Figure 14 : Cas d’utilisation N°11 «Elaboration des plannings » ......................................................... 51
Figure 15 : Cas d’utilisation N°12 «Gestion d’assiduité des 1ère années magistère ».......................... 52
Figure 16 : Cas d’utilisation N°13 « Introduction du résultat des examens » ....................................... 53
Figure 17 : Cas d’utilisation N°14 « Gestion des projets » ................................................................... 54
Figure 18 : Cas d’utilisation N°15 «Modification du tableau de montant d’allocation ventilé » .......... 56
Figure 19 : Cas d’utilisation N°16 «Gestion des stages et communications » ...................................... 57
Figure 20 : Cas d’utilisation N°17 «Gestion de projets de recherche » ................................................ 59
Figure 21 : Cas d’utilisation N°18 « Consultation des statistiques » .................................................... 61
Figure 22. Organisation du concours d’accès à l’école doctorale ......................................................... 63
Figure 23. Gestion de la scolarité de l’école doctorale.......................................................................... 63
Figure 24. Suivi des projets des étudiants ............................................................................................. 64
Figure 25. Gestion des soutenances....................................................................................................... 64
Figure 26. Suivi des projets de recherche .............................................................................................. 65
Figure 27. Gestion des activités scientifiques et pédagogiques ............................................................. 65
Figure 28 : Diagramme de classe associé à la gestion de concours ...................................................... 67
Figure 29 : Diagramme de classe associé à la gestion de la scolarité.................................................... 68
Figure 30 : Diagramme de classe associé à la gestion de soutenance ................................................... 69
Figure 31 : Diagramme de classe associé à la gestion de projet de recherche ...................................... 70
Figure 32 : Diagramme de classe associé à la gestion des activités scientifiques ................................. 71
Figure 33. Diagramme de séquence N°1 : Affection des candidats aux salles ..................................... 78
Figure 34. Diagramme de séquence N°2 : Gestion de connexion des utilisateurs ................................ 79
Figure 35 : Diagramme de séquence N°3 : Initialisation de l’année scolaire ........................................ 79
Figure 36. Diagramme de séquence N°4 : Gestion des messages d'accueil ......................................... 80
Figure 37. Diagramme de séquence N°5 : Proposition de projets ......................................................... 80
Figure 38. Diagramme de séquence N°6 : Gestion des utilisateurs ...................................................... 81
Figure 39. Diagramme de séquence N°7 : Inscription en ligne ............................................................ 81
Figure 40. Diagramme de séquence N°8 : Gestion des convocations .................................................. 82
Figure 41. Diagramme de séquence N°9 : Gestion des options et des modules ................................... 82
Figure 42. Diagramme de séquence N°10: Gestion des options et des modules ................................... 83
Figure 43. Diagramme de séquence N°11 : Gestion de résultat de soutenance ................................... 83
Figure 44. Diagramme de séquence N°12 : Création d'une nouvelle communication (stage) .............. 84
Figure 45. Diagramme de transition d'un projet ................................................................................... 84
Figure 46. Diagramme de transition d'un candidat ................................................................................ 85
Figure 47. Diagramme de transition d'un étudiant ............................................................................... 86
Figure 48: Diagramme de transition d'un profil utilisateur ................................................................... 87
Figure 49: Diagramme de transition d'une année universitaire ............................................................. 87
Figure 50 : Architecture du nouveau système ....................................................................................... 91
Figure 51 : Principe de fonctionnement ................................................................................................ 94
Figure 52 : Hiérarchie de développement. ............................................................................................ 95
Figure 53 : Le diagramme de déploiement. ......................................................................................... 115
Figure 54 : Page d'accueil .................................................................................................................... 118
Figure 55 : Page d'autentification ....................................................................................................... 118
Figure 56 : Formulaire des options ...................................................................................................... 119
Figure 57 : Formulaire de modules de concours par option ............................................................... 119
Figure 58 : Formulaire d’inscription en ligne des candidats au concours ........................................... 120
Figure 59 : Formulaire d’inscription et validation d’inscription des candidats ................................... 121
Figure 60 : Formulaire de saisie des notes pour le concours .............................................................. 121
Figure 61 : Formulaire de délibération de concours ........................................................................... 122
Figure 62 : Formulaire d’intégration des nouveaux étudiants ............................................................ 122
Figure 63 : Modification des informations d'un étudiant ................................................................... 123
Figure 64 : Formulaire des projets de recherche ................................................................................ 123
Figure 65 : Formulaire de suivi des projets de recherche ................................................................... 124
Liste des tableaux
Tableau 1 : Liste de procédure de travail .............................................................................................. 11
Tableau 2 : Symboles utilisés dans le DCI ............................................................................................ 12
Tableau 3 : Procédure du suivi de concours .......................................................................................... 14
Tableau 4 : Procédure du suivi des inscriptions de 1ère année magistère ............................................. 16
Tableau 5 : Procédure du suivi de mini-projets ..................................................................................... 17
Tableau 6 : Procédure de délibération de la 1ère année ........................................................................ 18
Tableau 7 : Procédure d’inscription 2ème année magistère et doctorant .............................................. 20
Tableau 8 : Procédure du suivi de soutenances magistère et doctorant ................................................. 22
Tableau 9 : Procédure du suivi de communications .............................................................................. 24
Tableau 10 : Procédure du suivi de stages ............................................................................................. 25
Tableau 11 : Procédure du suivi de projets de recherche ...................................................................... 27
Tableau 12 : Etude quantitative ............................................................................................................. 30
Tableau 13 : Liste des acteurs du système ............................................................................................. 36
Tableau 14: Liste des cas d'utilisation du système ................................................................................ 40
Tableau 15 : Découpage du système en sous-systèmes ......................................................................... 97
Tableau 16 : Schéma général de l’implémentation ............................................................................. 100
Tableau 17 : Les classes d'objet .......................................................................................................... 104
Tableau 18 : Les classes d'association ................................................................................................. 105
Tableau 19 : Equivalences entre les concepts objets et relationnels ................................................... 106
Tableau 20 : Implémentation des contrôles ......................................................................................... 107
Tableau 21 : Liste des classes de contrôle ........................................................................................... 108
Tableau 22 : Conception des interfaces utilisateur .............................................................................. 110
Tableau 23 : Liste des modules autorisés avec type d’accès par profil ............................................... 130
INTRODUCTION
GENERALE
ESI 2009/2010 INTRODUCTION GENERALE
2
I. INTRODUCTION GENERALE :
L’Ecole nationale Supérieure d’Informatique (ESI) est une école de l’enseignement
supérieur qui a pour vocation, d'une part, la formation d’ingénieurs d’état en informatique
aptes à mener des projets dans divers domaines, et d'autre part, la formation de formateurs
pour le secteur de l’enseignement supérieur et de la promotion de la recherche scientifique
dans le domaine informatique.
Afin de bien suivre le parcours de ses étudiants et chercheurs, l’ESI a décidé de mettre
en place un nouveau système d’information pour sa Direction de la Post Graduation et de la
Recherche (DPGR).
Pour mener notre étude, nous avons adopté le formalisme UML et nous avons suivi la
méthode de développement Object Modeling Technique (OMT), cela en employant les
différents diagrammes du langage UML 2.0.
Chapitre I : « Etude de l’existant »
Dans ce chapitre, après avoir présenté l’école et défini une problématique qui résume le
besoin enregistré, on effectue une étude des différentes structures et postes de travail au
sein de la DPGR :
Concours d’entrée à l’école doctorale
Scolarité (suivi des cours magistère, soutenances, mini projets)
Activités scientifiques (stage de courte durée, formation à l’étranger, séjour
scientifique)
Projets de recherches.
Chapitre II : « Analyse du nouveau système »
On présente, dans ce chapitre, le nouveau système à réaliser sur trois axes : fonctionnel
(identification des besoins et interactions avec les acteurs), statique (détermination des
objets manipulés et les relations entre eux) et dynamique (indication des interactions
entre les objets déjà déterminés, et de même pour l’évolution interne de ces derniers).
Chapitre III : « Conception du nouveau système »
Ce chapitre a pour objectif de donner plus de détail et moins d’abstraction par rapport ce
qu'a été traité lors de l’analyse. On présente la conception du système (architecture
physique et logique et découpage en sous-systèmes) et la conception des objets (classes
de contrôle, transaction et dialogue et conception des IHM).
ESI 2009/2010 INTRODUCTION GENERALE
3
Chapitre IV : « Réalisation et sécurité du nouveau système »
La présentation du prototype réalisé (par des prises d’écran) et l’établissement de ses
aspects sécuritaires (après avoir recensé les risques et menaces le guettant et les
précautions et mesures à prendre) ont été faites dans ce dernier chapitre.
Le schéma suivant démontre les étapes de cette méthode :
Figure 1.Démarche de développement
ETUDE DE
L’EXISTANT
ESI 2009/2010 ETUDE DE L’EXISTANT
5
II. ETUDE DE L’EXISTANT :
II.1. Introduction :
Dans le cadre du développement d’un nouveau système d’information pour la DPGR
de l’ESI, on présente dans cette partie l’étude de l’existant concernant la DPGR.
Après une brève présentation de l’école et de la DPGR, les problèmes ayant initié ce
projet seront rappelés et les objectifs attendus du développement de ce nouveau système
seront présentés.
Pour représenter les différentes besoins, on a adopté le DCI (Diagramme de
Circulation de l’Information).
ESI 2009/2010 ETUDE DE L’EXISTANT
6
II.2. Présentation de l’organisme d’accueil :
II.2.1. Présentation de l’ESI :
L’école nationale supérieure d’informatique (ESI ex. INI) est un établissement de
l’enseignement supérieur crée par le décret n° 82-434 du 04.01.1982 -sous la tutelle du
Ministère de la Planification et de l’Aménagement Territoire. Il est ensuite placé, sous la
tutelle du Ministère de l’Enseignement Supérieur et de la Recherche Scientifique par le décret
du 02-01-1984. Jusqu'à cette date, l’ESI existait sous l’appellation de Centre d’Etudes et de
Recherche en Informatique (C.E.R.I.)- issu de la restructuration du Commissariat National à
l’Informatique au sein duquel il a été créé par ordonnance n° 69-104 du 26.12.1969 et placé
sous la tutelle du Ministère de la Planification et de l’Aménagement du Territoire. Puis sous
l’appellation de l’Institut National de Formation en Informatique (INI) jusqu’à la fin de 2008.
Le CERI fut le premier centre de formation spécialisé en informatique en Afrique. Il
forma les premiers ingénieurs d’état, ingénieurs d’application (analystes) et programmeurs
d’Algérie et d’autres pays d’Afrique.
Depuis dix-sept ans l’ESI est érigé en centre national d’orientation des nouveaux
bacheliers et il traite des millions de fiches de vœux des nouveaux bacheliers provenant de
toutes les régions du pays et il les oriente selon les critères définis par le ministère de
l’enseignement supérieur et de la recherche scientifique.
Après quarante ans d’existence, l’école nationale supérieure d’informatique reste
toujours fidèle à sa mission de produire des ingénieurs en informatique capable de concevoir,
de développer et de maintenir des systèmes d’informations et des systèmes d’informatiques.
Ses principales missions se résument comme suit:
La formation en graduation d’ingénieur d’état en informatique.
La formation en première post-graduation durant deux années ouverte aux titulaires
d’ingéniorat d’état en informatique pour l’obtention d’un magister en informatique.
La formation en deuxième post graduation durant trois années ouverte aux titulaires
d’un magister en informatique pour l’obtention d’un doctorat en informatique.
Assister le secteur industriel et socio professionnel en matière d’informatisation.
Effectuer et promouvoir la recherche scientifique dans les domaines de technologie de
pointe notamment les technologies de l’information et de la communication, en
coopérant avec des centres de recherches et universités nationaux et internationaux.
La formation continue pour le perfectionnement de cadres d’entreprises.
L’orientation des nouveaux bacheliers vers les établissements universitaires, qui est
une opération d’envergure nationale.
ESI 2009/2010 ETUDE DE L’EXISTANT
7
II.2.2. Présentation de la DPGR de l’ESI :
Présentation :
La post-graduation constitue la pierre angulaire de développement de l’enseignement
supérieur. Elle permet de former des enseignants chercheurs pour les établissements
universitaires et les chercheurs pour les secteurs industriels et socio-économiques et les
centres de recherche. L’ESI a l’habilitation pour assurer la formation en post-graduation.
En 2005, l'ESI a intégré l'Ecole Doctorale en se mettant d'accord avec les autres
universités à travers le territoire national pour présenter le même concours d'accès à la post-
graduation et à suivre la même formation. Ce pas a permis d'obtenir une formation homogène
et a donné la possibilité d'accès à l'école doctorale même pour les universités qui ne disposent
pas d'un service de post-graduation et dont les étudiants admis après le concours peuvent
rejoindre l'université la plus proche qui dispose d'un service de post-graduation.
Cette direction a pour mission :
La gestion, l'organisation et le suivi des études en première et deuxième post
graduation (école doctorale).
L'organisation du concours d'accès à l’école doctorale.
La promotion de la recherche scientifique (Gestion des projets de recherches en
veillant à fournir les moyens appropriés).
La promotion des échanges scientifiques dans le cadre de la coopération nationale et
international.
Organigramme de la DPGR :
Figure 2. Organigramme de la DPGR
DPGR
Service de la post-
graduation
Labo post-graduation
Ecole doctorale
Service de la recherche
Labo de recherche
LMCS
Labo de recherche LCSI
ESI 2009/2010 ETUDE DE L’EXISTANT
8
II.3. Présentation du sujet :
II.3.1. Système actuel :
Il n’existait pas une gestion automatisée au sens propre du terme pour la DPGR, mais
seulement des opérations qui étaient gérées de façon manuelle et un site web statique, ce qui
rendait impossible toute synthèse ou de disposer d’un quelconque indicateur de gestion ou de
statistiques.
II.3.2. Problématique :
A l’issue d’une brève étude d’opportunité, il s’est avéré que les déficits sont dus à un
ensemble de problèmes dont nous citons:
La difficulté dans l’élaboration des documents administratifs vu la gestion actuelle des
archives.
L’incapacité d’avoir une trace de l’état d’avancement des thèses de doctorat et de
magistère.
Difficulté de retracer les activités scientifiques et pédagogique menées par les
enseignants et les chercheures au sein de la direction.
La difficulté dans l’élaboration des statistiques.
Le système actuel n’est pas à la hauteur de l’image de l’ESI.
Difficulté d’avoir l’historique des cursus des étudiants depuis l’inscription en première
année jusqu'à la fin de cursus.
Pertes des informations concernent des étudiants et leurs dossiers.
Difficulté d’établir tous les taches manuellement (surtout établissement des documents
administratifs).
Pour cela, la direction de l’ESI, consciente de l’enjeu et soucieuse de mettre en place
et de moderniser son ensemble du système d’information, a décidé dans ce cadre de mettre
en place un système de gestion pour la DPGR, pour disposer d’un outil qui lui permettra de
prendre des décisions de gestion à partir des éléments scientifiques et réels.
II.3.3. Objectifs de l’étude :
Afin d’améliorer les fonctions et les processus de travail au niveau de la DPGR, nous
allons concevoir et réaliser un système d’information pour la gérer, permettant de répondre
aux besoins perçus par la DPGR.
Le système à réaliser apportera des solutions pour les problèmes cités ci-dessus et à
toutes les raisons des dysfonctionnements existants.
Les objectifs du système à réaliser sont:
Faciliter la couverture de l'ensemble du cycle d’étude d'un post-graduant.
Effectuer le suivi pédagogique de l’école doctorale.
Avoir à tout moment l’état d’avancement des thèses de magister et doctorat.
ESI 2009/2010 ETUDE DE L’EXISTANT
9
Disposer à tout moment d’une trace de toutes les activités scientifique et pédagogique
organisées (formations, stages et congés scientifique) et des projets de recherche
mènes au sein de la direction.
Prendre en charge les différentes post graduation existantes depuis la création d’école
doctorale, en récupérant toutes les données et les injecter dans le nouveau système.
Mettre à la disposition du conseil scientifique toutes les informations nécessaires pour
prendre des décisions concernant la DPGR.
Assurer la disponibilité et la sécurité des informations.
Exploiter les documents archivés pour délivrer des documents administratifs.
Avoir un site évolutif pour la prise en charge des besoins futurs.
Avoir un tableau de bord pédagogique (statistique et historique).
Avoir un outil d’aide pour l’élaboration des emplois du temps et des plannings
(examens, soutenances,…)
Faciliter d’obtenir tous les statistiques de façon automatique et fiable.
Faciliter la récupération de n’importe quelle information concernant n’importe quel
objet.
Minimiser le temps de traitement des différentes procédures en éliminant les
opérations qui se répètent et les redondances des documents.
Sécuriser les informations internes contre les pertes et les modifications erronées.
Garder toutes les traces des opérations qui se déroulent à l’intérieur.
Pour atteindre ces objectifs, nous allons mettre en place un système automatisé, sécurisé et
fiable en vue de bien gérer les différentes procédures internes de la DPGR.
II.4. Etude des acteurs de système :
II.4.1. Liste des acteurs :
Le directeur de la DPGR.
Le responsable de l’école doctorale.
Agent administratif.
Président du conseil scientifique.
Enseignant chercheur.
Etudiant en école doctorale.
Candidat au concours de l’école doctorale
Promoteur.
Membre de Jury.
ESI 2009/2010 ETUDE DE L’EXISTANT
10
II.4.2. Les tâches des acteurs :
Les tâches du directeur de la DPGR :
Il a pour mission de gérer la direction de la post graduation et de la recherche : il valide les
différents documents, provenant des étudiants ou des enseignants, contrôle le suivi des cours,
gère les soutenances et délivre les diplômes, déterminer le jury des mini-projets.
Les tâches du responsable de l’école doctorale :
Suivre les notes des concours et la scolarité de l’école doctorale.
Délibération finale de 1ière année magistère.
Suivi des projets de recherche (suivi de contrat de recherche et les rapports
individuels).
Les tâches d’agent administratif :
Gérer les inscriptions des étudiants.
Préparer les relevés de notes et les certificats scolarité.
Edition des différents documents (Attestations, Tableaux,…).
Suivi des communications des enseignants.
Suivi des soutenances, mini-projets et stages des étudiants.
S’occupe des différentes tâches administratives.
Les tâches du président du conseil scientifique :
Valider les mini-projets, les sujets de mémoire de Magister et Doctorat, les projets de
recherche et les activités de recherche.
Les tâches de l’enseignant chercheur :
Assurer les cours de Magister et évaluer les étudiants, participer dans les projets de recherche
et suivre les activités de scientifiques.
Les tâches d’étudiant :
Il peut être :
Un magistère : il s’inscrit pour suivre des cours, mène des travaux pratiques et des
projets de mémoire et consulte ses notes, il reçoit des documents administratifs.
Un doctorant : il s’inscrit pour l’obtention du diplôme de doctorat, publie ses travaux
et suit des stages de courte durée, il reçoit des documents administratifs.
ESI 2009/2010 ETUDE DE L’EXISTANT
11
Les tâches du candidat au concours de l’école doctorale :
Il s’inscrit pour participer au concours d’accès à l’école doctorale.
Les tâches du promoteur :
Encadrer les étudiants dans leurs mini-projets et mémoires.
Les tâches du membre du Jury :
Participer au jury qui évalue les projets de mémoire réalisés par les étudiants.
II.5. Etude des procédures de travail :
II.5.1. Liste des procédures de travail :
Procédure Fréquence
Procédure du suivi des concours. Chaque début d’année.
Procédure des inscriptions. Chaque début d’année.
Procédure du suivi des mini-projets et des
soutenances. Chaque fin d’année.
Procédure de préparation des plannings
(examens, emplois du temps,…).
Procédure des activités scientifiques (stages,
formations, communications).
Procédure du suivi des projets de recherche
Procédure d’élaboration des statistiques Chaque fin d’année.
Tableau 1 : Liste de procédure de travail
II.5.2. Etude détaillée des procédures :
Diagramme et symboles utilisés :
On va utiliser le diagramme de circulation de l’information (DCI) pour modéliser les
procédures du travail, le tableau suivant présente les différents symboles utilisés dans ce
diagramme :
Symbole Désignation
Opération / Processus
Décision
Document / Dossier
ESI 2009/2010 ETUDE DE L’EXISTANT
12
Données
Archivage
Validation
Sens de circulation de l’information.
Séparateur entre deux étapes de la même
procédure.
Tableau 2 : Symboles utilisés dans le DCI
Procédure du suivi de concours d’entrée de l’école doctorale:
Cas l : Définition du concours
Définir le concours de Magister : chaque début d'année, une demande d'habilitation
pour l'organisation du concours est adressée à la Conférence Régionale des Universités du
Centre-Algérie dans laquelle sont précisés les spécialités à ouvrir et le nombre de places
souhaitées.
Afficher la date du concours, la nature des épreuves avec les durées respectives,
Préciser les conditions à remplir et du dossier à fournir pour l'inscription,
Effectuer l'affichage se fait au niveau de l'ESI, au niveau des universités concernées,
par voie de presse et via le site Internet de l'ESI.
Cas 2 : Inscription au concours
Les intéresses au concours peuvent envoyer leurs dossiers par voie postale ou bien le
déposer directement au niveau de l'ESI. Les candidats ayant rempli les conditions
d'inscription au concours seront enregistrées.
Cas 3 : Organisation des épreuves
Elaboration des listes des candidats par filière,
Impression des sujets des examens proposés par les enseignants,
Demande de mise à disposition de la DPGR de salles, et de surveillants auprès de la
D.E.
Affectation des candidats et surveillants par salles.
ESI 2009/2010 ETUDE DE L’EXISTANT
13
Cas 4 : Saisie des notes
Codification des copies d'examen pour garantir l'anonymat,
Double correction des copies (éventuellement une troisième si l'écart entre les deux
corrections est supérieur à quatre points)
Inversion de la codification, saisie des notes, et calcul des moyennes.
Cas 5 : Affichage des résultats
Edition de la liste des admis et d'une liste d'attente après classement des candidats.
Validation des résultats par le C.S.
Affichage des résultats du concours et contact des admis par email ou courrier.
ESI 2009/2010 ETUDE DE L’EXISTANT
14
Diagramme de circulation d’information :
Procédure du suivi de concoursP
rép
ara
tio
nC
on
vo
ca
tio
ns
Ré
su
lta
ts
DPGRAgent DPGR CSResponsable de
l’école doctoraleEtudiant
Dossier
Traitement de dossier
Liste des
candidats
+
Etablissement
des
convocations
Convocation
Validation
Proposer les
spécialités et les
modules
Fixer la période de
dépôt des dossiers et
la date de concours
Ramène les sujets
de concours
préparés par les
enseignants
Concours
Résultat de
concours
(notes)
Liste des admis et
attentes
Validation
Archivage
Tableau 3 : Procédure du suivi de concours
ESI 2009/2010 ETUDE DE L’EXISTANT
15
Procédure de suivi des inscriptions 1ère année magistère:
Cas 1 : Inscription des étudiants
Les candidats figurant sur la liste des admis se présentent pour s'inscrire à la 1ière
année de Magister et ceux qui ne se manifestent pas avant une date limite seront remplacés
par leurs successeurs dans la liste d'attente.
Cas 2 : Elaboration des emplois du temps
Affectation des étudiants et des enseignants.
Elaboration des emplois du temps.
Cas3 : Gestion de l'assiduité des étudiants
Les absents sont signalés à la direction.
Sanction ou avertissement des étudiants en fonction de leurs absences.
ESI 2009/2010 ETUDE DE L’EXISTANT
16
Diagramme de circulation d’information :
Procédure d’inscription 1ère année magistèreL
iste
de
s a
dm
isL
iste
fin
ale
Enseignant Agent DPGR CS DPGREtudiant
Formulaire de
confirmation de
l’inscription
(Admis)
Liste initiale
Validation
Formulaire de
confirmation de
l’inscription
(Attentes)
Liste finale
des 1ière
années
Validation
Archivage
Certificat scolaritéEtablir
certificat
de
scolarité
Etablir
certificat
de
scolarité
Certificat scolarité
Tableau 4 : Procédure du suivi des inscriptions de 1ère année magistère
Procédure du suivi de mini-projets :
Cas 1 : Constituer les jurys
Les jurys proposes par les enseignants ou encadreurs sont constitues. Un jury est compose
d'un président et de deux assesseurs ou plus.
ESI 2009/2010 ETUDE DE L’EXISTANT
17
Cas2 : Elaborer un planning des soutenances des mini-projets
Selon les disponibilités des membres du jury, le directeur de la DPGR programme le planning
et l’affiche.
Cas3 : Enregistrer les résultats des mini-projets
Après la tenue de chaque soutenance, le jury remplit un procès verbal de délibération
indiquant le résultat de la soutenance qui sera enregistré et affiché.
Après chaque soutenance, on délivre les notes de succès et les remarques.
Diagramme de circulation d’information :
Procédure du suivi de mini-projets
Enseignant CS Agent DPGR DPGREtudiant
Mémoire
Autorisation de
soutenance
(promoteur) Déterminer le jury
Validation
Avis favorable
Fixer la date
de soutenance
Soutenance
Procès verbal de
soutenance
(La note du mini-
projet)
Archivage
Validation
Tableau 5 : Procédure du suivi de mini-projets
ESI 2009/2010 ETUDE DE L’EXISTANT
18
Procédure de délibération de la 1ière année :
A partir des notes d'examens et des notes des mini projets, on calcule les moyennes des
étudiants.
Délibérations, validation des résultats par le C.S. et édition des bulletins de notes.
Diagramme de circulation d’information :
Procédure de délibération de la 1ère année
DPGREnseignant CSResponsable de
l’école doctorale
Traitement (calculer les
moyennes)
Ramener les
notes des
étudiants
Délibération
Listes finale des
admis, redoubles
et des exclus.
Tableau 6 : Procédure de délibération de la 1ère année
ESI 2009/2010 ETUDE DE L’EXISTANT
19
Procédure d’inscription 2ème année magistère et doctorat :
Cas l : Enregistrer les sujets de mémoire affectés aux étudiants :
Les sujets de mémoire, proposes par les enseignants et valides par le Cs, sont
enregistres.
Cas 2 : Inscrire les doctorants
Après validation des sujets par le Conseil Scientifique, on enregistre les doctorants
inscrits.
Cas3 : Suivre l'avancement des thèses de Doctorat
Dépôt des rapports a des dates d'échéance
Le candidat doit publier des travaux dans au moins une revue scientifique de
renomme
ESI 2009/2010 ETUDE DE L’EXISTANT
20
Diagramme de circulation d’information :
Procédure d’inscription 2ème année magistère et doctorantN
ou
ve
lle in
scrip
tio
nP
rolo
ng
atio
n 3
èm
e a
nn
ée
Enseignant Agent DPGR CS DPGREtudiant
Déterminer le
sujet et le
promoteur
Formulaire
d’autorisation
d’inscription
Archivage
Certificat scolarité
Validation
Etablir
certificat
scolarité
Archivage
Validation
Certificat scolaritéEtablir
certificat
scolarité
Formulaire
d’autorisation de
prolongation
Demande de
prolongation
Tableau 7 : Procédure d’inscription 2ème année magistère et doctorant
ESI 2009/2010 ETUDE DE L’EXISTANT
21
Procédure du suivi de soutenances magistère et doctorant :
Cas 1 : Constituer les jurys
Les jurys proposes par les enseignants ou encadreurs sont constitues. Un jury est compose
d'un président et de deux assesseurs ou plus.
Cas2 : Elaborer un planning des soutenances
Selon les disponibilités des membres du jury, la directrice programme les soutenances et
affiche les plannings.
Cas3 : Enregistrer les résultats des soutenances
Apres la tenue de chaque soutenance, le jury remplit un procès verbal de délibération
indiquant le résultat de la soutenance qui sera enregistre et affiche.
Après chaque soutenance, on délivre les attestations de succès et les diplômes. [06 34]
ESI 2009/2010 ETUDE DE L’EXISTANT
22
Diagramme de circulation d’information :
Procédure du suivi de soutenances magistère et doctorant
Enseignant CS Agent DPGR DPGREtudiant
Mémoire
+
5 résumés
Autorisation de
soutenance
(promoteur)
Proposer le jury
(promoteur)Traitement
Validation
Avis favorable
Avis favorable
(président jury)
Fixer la date
de soutenance
Soutenance
Procès verbal de
soutenance
Archivage
Validation
Les rapports de
lecture (jury)
Lecture du
mémoire (jury)
Tableau 8 : Procédure du suivi de soutenances magistère et doctorant
ESI 2009/2010 ETUDE DE L’EXISTANT
23
Procédure du suivi du séjour scientifique (communication) :
Cas 1 : Suivre les activités scientifiques
Enregistrement des informations concernant les formations programmées à l'étranger,
les séjours, les stages de courte durée.
Garder une trace de tous les chercheurs ayant bénéficies de ces activités.
Cas2 : Elaborer des statistiques
Edition des états statistiques, destines aux responsables de l'établissement et a ceux du
ministère de la tutelle, nécessaires pour la gestion future du département.
ESI 2009/2010 ETUDE DE L’EXISTANT
24
Diagramme de circulation d’information :
Procédure du suivi de communicationsN
ou
ve
lle c
om
mu
nic
atio
nR
eto
ur
de
la
co
mm
un
ica
tio
n
DPGR DG CSEnseignant,
Doctorant
Article
+
Acceptation
(Invitation) de la
communication
+
Demande manuscrite
Tableau de frais
d’allocation
+
Tableau de frais
d’inscription
Archivage
Validation
1 copie de
l’attestation
+
1 copie de
tableaux des frais
Traitement
Validation du dossier
et détermination du
séjour de la
communication
Attestation de
communication
1 copie de
passeport (date
sortie + date
d’entrée)
+
Attestation de
participation dans
la communication
Validation
Archivage
Tableau 9 : Procédure du suivi de communications
ESI 2009/2010 ETUDE DE L’EXISTANT
25
Procédure du suivi de stages à l’étranger (courte durée ou formation) :
Procédure du suivi de stages
No
uve
au
sta
ge
Re
tou
r d
u s
atg
e
DPGR DG CSEnseignant,
Doctorant
Demande de stage
+
Acceptation de stage
Tableau de frais
d’allocation
Archivage
Validation
1 copie de
l’attestation et de
tableau de frais
Traitement
Validation du dossier
et détermination du
séjour du stage
Attestation de
stage
1 copie de
passeport (date
sortie + date
d’entrée)
+
Attestation de
participation dans
le stage
Validation
Archivage
Tableau 10 : Procédure du suivi de stages
ESI 2009/2010 ETUDE DE L’EXISTANT
26
Procédure du suivi de projets de recherche :
Cas l : enregistrer les projets de recherche
L'enseignant-chercheur souhaitant proposer un nouveau projet de recherche doit soumettre le
dossier à la D.P.G.R.
Le directeur de la DPGR vérifie si les recommandations sont respectées dans le dossier.
Exemple : le chef du projet doit être de rang magistral, le nombre de chercheurs dans l’équipe
doit être compris entre 3 et 6, le CV de chaque membre de l'équipe est joint au dossier.
Si le dossier est complet et que les recommandations ont été respectées, Le directeur de la
DPGR enregistre le nouveau projet propos » et transmet le dossier au Comite National
d'Evaluation et de Programmation de la Recherche Universitaire (C.N.E.P.R.U.) pour la
validation.
Note: lorsqu'un projet est soumis en l'an X, il sera agrée par C.N.E.P.R.U. en l'an X+1 et son
démarrage sera effectif en l'an X+2. (Réglementation actuelle).
Cas2: gérer les nouvelles intégrations
L'enseignant-chercheur désireux de s'intégrer dans un projet de recherche doit adresser une
demande d'intégration au directeur de la D.P.G.R.
Le directeur vérifie si le nombre de chercheurs impliqués dans le projet ne dépasse pas les six
(06), Si c'est le cas, la demande est ensuite envoie au conseil scientifique pour décider.
Si la réponse est favorable, le nouvel enseignant-chercheur est intégré et la date d'intégration
est enregistrée.
Cas3 : suivre l'avancement des projets
Après chaque semestre, chaque membre de l'équipe de recherche (y compris le chef du projet)
doit rédiger un rapport individuel d'activité de recherche dûment signé par le chef du projet,
en un seul exemplaire, sur une seule page, selon un canevas bien précis. Le chef du projet doit
rédiger aussi en un seul exemplaire un rapport de synthèse d'activité de recherche (3 pages
maximum) sur la base des rapports individuels.
Le directeur de la DPGR transmet ensuite les rapports individuels et le rapport de synthèse de
chaque équipe au C.S pour évaluation.
Un rapport de recherche annuel de chaque projet doit être transmis au C.N.E.P.R.U. pour
évaluation. Pour cela, tous les chefs de projet doivent transmettre au directeur de la D.P.G.R.
leurs rapports annuels (en 3 exemplaires) selon un canevas bien précis. [06 34]
ESI 2009/2010 ETUDE DE L’EXISTANT
27
Diagramme de circulation d’information :
Procédure du suivi de projets de recherche:
No
uve
au
pro
jet d
e r
ech
erc
he
Su
ivi c
ha
qu
e s
em
est
re c
ha
qu
e a
nn
ée
P
rolo
ng
atio
n F
initi
on
pro
jet
MESRSEnseignantDG CS DPGR
Détail du projet
(l’équipe, le chef
et la description
du projet)Validation
Contrôle
et
Validation
Accord de la
commission de
ministère (tableau
d’agreement)
Archiver
l’accord
Contrat de
recherche
Validation
Rapport individuel
d’activité de
recherche
Validation
Validation
Archiver
Archiver
Validation Validation
Bilan (Etat
d’avancement)
Archiver
Demande de
prolongation
validation
Acceptation
Validation
Tableau 11 : Procédure du suivi de projets de recherche
Enregistre le
résultat
Valider
ESI 2009/2010 ETUDE DE L’EXISTANT
28
Procédure d’élaboration des statistiques :
Edition des états statistiques, destinés aux responsables de l’établissement et à ceux du
ministère de la tutelle, nécessaires pour la gestion future de la direction.
II.6. Etude de quelques documents :
Le certificat de scolarité :
Champs Type de valeur
Date du certificat Date
Nom et prénom Chaîne de caractères.
Date de naissance Date
Adresse et lieu de naissance Chaîne de caractères.
Option Chaîne de caractères.
La carte d’étudiant :
Champs Type de valeur
Code étudiant Chaîne de caractères.
Date de la carte Date
Nom et prénom Chaîne de caractères.
Date de naissance Date
Adresse et lieu de naissance Chaîne de caractères.
Option Chaîne de caractères.
Le relevé de notes :
Champs Type de valeur
Date du relevé Date
Nom et prénom et option Chaîne de caractères.
Modules Module
Note de chaque module Réel
Moyen général Réel
Rang Entier
Décision du conseil de délibération Admis, Redouble, Exclu
ESI 2009/2010 ETUDE DE L’EXISTANT
29
Tableau de frais d’allocation pour les activités scientifiques:
Champs Type de valeur
L’année de l’activité scientifique Année
Période de
l’activité
date début Date
date fin Date
Type de perfectionnement
Séjour scientifique (SS)
Stage de courte durée (SCD)
Expérience au laboratoire et acquisition
de nouvelles techniques (ELAT)
Nom et prénom du concerné Chaîne de caractères.
Grade MCA, MCB,MAA…
Pays d’accueil Pays
Durée de stage Nombre de jours
Objectif du stage Type de perfectionnement
Frais d’allocation Monnaie (DA)
Tableau de frais d’inscription pour les séjours scientifiques:
Champs Type de valeur
L’année du congé scientifique Année
Période du congé date début Date
date fin Date
Nom et prénom du concerné Chaîne de caractères.
Grade Chaîne de caractères.
Pays d’accueil Pays
Durée de stage Nombre de jours
Frais d’inscription Monnaie (DA)
ESI 2009/2010 ETUDE DE L’EXISTANT
30
II.7. Etude quantitative :
Elément Valeur
Nombre moyen
des étudiants
1ère
année magistère 36
2ème
année magistère 30
Doctorant 8
Nombre moyen des candidats
(concours) 100..200
Nombre de documents 5
Taux d’erreur (Copier-coller) 5%
Temps moyen pour saisir les
informations d’un candidat / étudiants 5 minutes
Temps moyen pour préparer un
certificat de scolarité 7 minutes
Temps moyen pour préparer un relevé
de notes 5 minutes
Temps moyen pour préparer les
tableaux des frais (stage et
communication)
30 minutes
Temps moyen pour élaborer les
statistiques 4 jours
Tableau 12 : Etude quantitative
II.8. Diagnostics de la situation existante :
II.8.1. Recensement des anomalies :
Anomalie N°1 : Lourdeur des traitements :
Causes Perte du temps.
Tâches manuelles ou semi manuelles.
Conséquences Retard dans l’établissement des
documents.
ESI 2009/2010 ETUDE DE L’EXISTANT
31
Anomalie N°2 : Manque ou non disponibilité de l’information utile :
Anomalie N°3 : Retard dans l’établissement des documents :
Anomalie N°4 : Erreur lors de l’établissement des documents :
Causes
Lourdeur de la circulation de
l’information
Lourdeur des traitements
Des documents non mis à jour en temps
voulu
Mauvais e connaissance de la situation
réelle des étudiant, des enseignant et leurs
projets
Conséquences
Retard dans l’établissement des
documents
Retard dans la prise de décision ou des
décisions mal prises
Causes
Lourdeur de la circulation de
l’information
Lourdeur des traitements
Surcharge de certains postes de travail
Existence de tâches manuelles
Conséquences
Non disponibilité de l’information voulue
et fiable en temps voulu
Retard et non respect des délais
Retard dans la prise de décision
Causes
Tâches manuelles
Présence de document non mis â jour
Existence de documents mal conçus
Conséquences
Non disponibilité de l’information voulue
et fiable en temps voulu
Gestion et suivi de scolarité mal assuré
ESI 2009/2010 ETUDE DE L’EXISTANT
32
Anomalie N°5 : Un manque en états statistiques :
II.8.2. Diagnostic du système :
Le diagnostic nous a permis de recenser un certain nombre de causes de dysfonctionnement,
et cela en distinguant les différentes catégories de problèmes.
Nous pouvant dire que les principaux problèmes soulevés dans l’étude du domaine sont
essentiellement d’ordre informationnel. Nous citerons :
Gestion manuelle :
Retard.
Erreurs sur les documents.
Surcharge de certaines tâches.
Difficultés d’estimation des besoins :
Manque d’application de méthodes scientifiques.
Non uniformité des procédures de travail et des documents.
II.8.3. Suggestions :
L’étude de l’existant nous a permis de nous rendre compte que la plupart des causes de
dysfonctionnement du système en question sont d’ordre informationnel et organisationnel.
Pour y remédier, nous proposons les quelques suggestions suivantes :
Organisationnel :
Uniformiser les procédures de travail (travailler de la même manière).
Uniformiser les documents.
Causes
Absence d’un outil pour éditer les états
statistiques
Historique manuel
Conséquences
Mauvais suivi de scolarité et de stage
Mauvaise prise de décision
Mauvaise prévision
ESI 2009/2010 ETUDE DE L’EXISTANT
33
Redéfinir les tâches et responsabilités des différents poste de travail afin d’alléger et
d’équilibrer la charge des postes.
Informationnel :
Automatiser les tâches manuelles.
Mise à jour automatique des documents.
Suppression des éléments inutiles (registre, etc.)
Uniformisation des documents.
Utilisation de méthodes scientifiques.
Technique :
Une meilleure codification.
Exploiter au mieux les moyens informatiques pour relier les différentes postes de
travail entres elles.
Diminuer au mieux les recours aux archives (utilisation d’une base de données).
Automatiser toutes les procédures du travail.
II.9. Conclusion :
Cette étude du système actuel nous permet de déterminer les différents acteurs et leurs tâches
même les anomalies figurants dans le système, donc maintenant on peut procéder à la
conception du nouveau système en commençant par l’étape d’analyse.
ANALYSE
ESI 2009/2010 ANALYSE
35
III. ANALYSE :
III.1. Introduction :
L’analyse, met en place les fondements du système à réaliser en donnant une idée
précise et claire sur ce dernier qui délimite son étendue et son fonctionnement. Cela se fait en
présentant les différents diagrammes (cas d’utilisation, classes, séquences,..), suivant la
méthode de modélisation OMT dont chacun résume et explique un aspect du nouveau système
et son fonctionnement. L’analyse présente une abstraction totale étant indépendante de toute
technologie ou implémentation.
Cette analyse se base sur les résultats de l’étude de l’existant qui nous a permis d'une
part d’évaluer le système actuel en percevant ses besoins, et d'autre part, décrire le bon
comportement que doit avoir le nouveau système.
ESI 2009/2010 ANALYSE
36
III.2. Analyse fonctionnelle :
Les besoins sont le point de départ pour le développement du nouveau système, ils
doivent traduire ce qu’il va apporter aux utilisateurs, en montrant les différentes
fonctionnalités.
Pour cette phase on a utilisé le diagramme de cas d’utilisation pour bien collecter les
besoins des utilisateurs du nouveau système, et pour cela nous avons procédé comme suit :
L’identification de tous les acteurs du nouveau système.
L’identification des cas d’utilisation.
La description de chaque cas d’utilisation.
Le regroupement des cas d’utilisation en package.
Cette phase nous permet de bien connaitre les utilisateurs du nouveau système, chacun
avec son rôle, ainsi que ce que le nouveau système pourra leur apporter.
III.2.1. Identification des acteurs :
Définition : Un acteur représente l'abstraction d'un rôle joué par des entités externes
(utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système
étudié. [ROQ, VAL, 2002].
Remarque : Nous avons utilisé une codification pour les acteurs pour ne pas alourdir les
différents diagrammes qu’on va illustrés ; les acteurs de notre système sont décrits comme
suit :
N° Acteur Code
1 Administrateur du système Administrateur
2 Directeur Général de l’ESI DirecteurESI
3 Le Directeur de la DPGR DirecteurPGR
4 Le Directeur des Etudes DirecteurE
5 Président du Conseil Scientifique PrésidentCS
6 Responsable de l’Ecole Doctorale ResponsableED
7 Agent Administratif AgentAd
8 Ministère de l’enseignement supérieur et de la
recherche scientifique MESRS
9 Enseignant Enseignant
10 Promoteur Promoteur
11 Membre de jury Membre de jury
12 Etudiant Etudiant
13 Visiteur du site web Visiteur
Tableau 13 : Liste des acteurs du système
ESI 2009/2010 ANALYSE
37
ESI 2009/2010 ANALYSE
38
III.2.2. Le diagramme de contexte du système :
La description des différents acteurs permet de dégager ce qu’on appelle le diagramme
de contexte pour le système [ROQ, VAL, 2002], il permet de présenter l’utilisation du
système par les différents acteurs au vu de la solution adoptée.
Dans la figure ci-dessous, nous avons illustré les différents acteurs qui interagissent
dans notre système, et ceci a travers un diagramme de contexte.
Figure 3 : Diagramme de contexte du système
III.2.3. Identification des cas d’utilisation :
Définition :
Un cas d’utilisation (Use Case) représente un ensemble de séquences d’action réalisées
par le système et produisant un résultat observable intéressant pour un acteur particulier. Un
cas d’utilisation modélise un service rendu par le système, il permet de décrire ce que le futur
système devra faire, sans spécifier comment il le fera. L’ensemble des cas d’utilisation doit
décrire exhaustivement les exigences fonctionnelles du système [ROQ, VAL, 2002].
ESI 2009/2010 ANALYSE
39
Le tableau suivant résume les cas d’utilisations de notre système :
N° Cas d’utilisation Acteur
1 Authentification
Connexion Tous les acteurs du
système sauf le visiteur
bien sûr. Déconnexion
2 Gestion des utilisateurs Ajout, Modification,
Suppression, Consultation Administrateur
3 Publication des messages. Administrateur,
DirecteurPGR
4 Initialisation de l’année scolaire DirecteurPGR
5 Détermination des options et des modules (concours
et scolaire)
PrésidentCS,
DirecteurPGR
6 Saisie des informations de candidat Visiteur, AgentAd
7 Inscription des candidats au concours AgentAd, DirecteurPGR
8 Préparation des convocations (Impression, envoi) AgentAd, DirecteurPGR
9 Affectation des candidats aux salles AgentAd, DirecteurPGR
10 Introduction des résultats de concours (notes et liste
des admis et des attentes)
ResponsableED,
PrésidentCS
11 Inscription des 1
ères, 2
èmes années magistère et
doctorant DirecteurPGR
12 Elaboration des plannings (concours, emploi du
temps, examens, mini-projets, projets)
DirecteurPGR, AgentAd,
ResponsableED
13 Gestion d’assiduité des 1ère
s années (Pocket PC) AgentAd
14 Introduction des résultats des examens (notes) ResponsableED
15 Gestion des mini-projets
(1ère
année magistère)
Proposition Enseignant
Affectation des mini-
projets aux étudiants Etudiant, AgentAd
Constitution des jurys DirecteurPGR
Soutenance (note,
mention) ResponsableED
16
Gestion des projets (2ème
année magistère et
doctorant)
Proposition Enseignant
Affectation des projets
aux étudiants Etudiant, AgentAd
Suivi de l’avancement
des thèmes DirecteurPGR
Constitution des jurys DirecteurPGR
ESI 2009/2010 ANALYSE
40
Soutenance (note,
mention) ResponsableED
17 Modification du tableau de montant d’allocation
ventilé (journal officiel)
DirecteurESI,
PrésidentCS
18 Gestion des promotions dans la recherche DirecteurPGR
19
Suivi des activités
scientifiques (formations
à l’étranger, stages de
courtes durées, séjours
scientifiques)
Création
AgentAd, PrésidentCS,
DirecteurESI,
DirecteurPGR
Résultat PrésidentCS
20 Gestion de projets de
recherche
Création AgentAd, PrésidentCS,
DirecteurESI,
DirecteurPGR
Suivi de l’avancement
Résultat
21 Gestion des nouvelles intégrations DirecteurPGR
22 Consultation des statistiques
MESRS, DirecteurESI,
DirecteurPGR,
PrésidentCS,
ResponsableED
Tableau 14: Liste des cas d'utilisation du système
Pour documenter les cas d’utilisation, la description textuelle est indispensable, car
elle seule permet de communiquer facilement et précisément avec les utilisateurs. La
description textuelle est également l’occasion de s’entendre sur la terminologie employée,
ainsi que d’identifier le contexte d’exécution de l’un ou de l’autre des enchainements, en
revanche, le texte présente des désavantages puisqu’il est difficile de montrer comment les
enchainements se succèdent; en outre la maintenance des évolutions s’avère souvent
périlleuse.
Il est donc recommandé de compléter la description textuelle par un ou plusieurs
diagrammes dynamiques, qui apporteront un niveau supérieur de formalisation [ROQ, VAL,
2002].
ESI 2009/2010 ANALYSE
41
III.2.4. Description détaillée des cas d’utilisations du système :
Cas d’utilisation N°1 « Authentification » :
Diagramme :
Figure 4 : Cas d’utilisation N°1 « Authentification »
Description sommaire
Titre Gestion des utilisateurs
But Permettre à un utilisateur de se connecter au système.
Acteurs Tous les acteurs de système sauf le visiteur
Description des enchainements
Pré-conditions L’utilisateur saisit ses droits d’accès (nom d’utilisateur et mot
de passe).
Enchainements
1. L’utilisateur demande une connexion au système.
2. le système demande le login et le mot de passe
3. L’utilisateur entre le login et le mot de passe puis il valide.
4. Le système vérifie l`existence de l`utilisateur.
5. Le système ouvre une session et affiche l’espace personnel
Post-conditions L’utilisateur se connecte au système et peut ainsi accéder aux
rubriques correspondantes à son profil.
Exceptions Néant.
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
42
Cas d’utilisation N°2 « Gestion des utilisateurs » :
Diagramme :
Figure 5 : Cas d’utilisation N°2 « Gestion des utilisateurs »
Description sommaire
Titre Gestion des utilisateurs
But Ce cas d’utilisation permet à l’administrateur de gérer les
utilisateurs et leurs privilèges.
Acteurs administrateur
Description des enchainements
Pré-conditions L’administrateur est authentifié.
Enchainements
1. L’administrateur s’authentifie.
2. L’administrateur accède à l’espace des utilisateurs
3. L’administrateur peut modifier, ajouter, consulter les
utilisateurs, même peut modifier les privilèges.
4. Le système demande une confirmation de modification.
5. L’administrateur confirme la modification puis il peut se
déconnecter.
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
43
Cas d’utilisation N°3 « Publication des messages d’accueil » :
Diagramme :
Figure 6 : Cas d’utilisation N°3 «Publication des messages d’accueil »
Description sommaire
Titre Publication des messages d’accueil
But Permettre de gérer les messages d’actualités
Acteurs Administrateur, DirecteurPGR, PrésidentCS, ResponsableED
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’utilisateur s’authentifie.
2. L’utilisateur accède à l’espace des messages
3. L’utilisateur peut modifier(le message ce qu’il ajoute sauf
l’administrateur peut modifier n’importe quel message),
ajouter, consulter les messages.
4. Le système demande une confirmation de modification.
5. L’utilisateur confirme la modification puis il peut se
déconnecter.
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
44
Cas d’utilisation N°4 « Initialisation de l’année scolaire » :
Diagramme :
Figure 7 : Cas d’utilisation N°4 «Initialisation de l’année scolaire »
Description sommaire
Titre Initialisation de l’année scolaire
But Permettre d’initialiser une année scolaire
Acteurs DirecteurPGR
Description des enchainements
Pré-conditions Néant
Enchainements
1. Le directeur s’authentifie.
2. Le directeur accède à l’espace des années scolaires
3. Le directeur peut modifier, ajouter, consulter les années
scolaires.
4. Le système demande une confirmation de modification.
5. Le directeur confirme la modification puis il peut se
déconnecter.
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
45
Cas d’utilisation N°5 « Détermination des options et des modules » :
Diagramme :
Figure 8 : Cas d’utilisation N°5 « Détermination des options et des modules »
Description sommaire
Titre Détermination des options et des modules
But Permettre de déterminer les options et les modules de concours
et scolaire
Acteurs DirecteurPGR, PrésidentCS
Description des enchainements
Pré-conditions L’année scolaire est initialisée.
Enchainements
1. L’utilisateur s’authentifie.
2. L’utilisateur accède à l’espace des options et modules
3. L’utilisateur peut modifier, ajouter, consulter les options et
les modules.
4. Le système demande une confirmation de modification.
5. l’utilisateur confirme la modification puis il peut se
déconnecter.
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
46
Cas d’utilisation N°6 « Inscription des candidats au concours » :
Diagramme :
Figure 9 : Cas d’utilisation N°6 «Inscription des candidats au concours »
Description sommaire
Titre Inscription des candidats en ligne
But Permettre d’inscrire les candidats à distance
Acteurs DirecteurPGR
Description des enchainements
Pré-conditions La date d’inscription est arrivée
Enchainements
1. Le candidat accède à l’espace d’inscription des candidats de
concours.
2. Le système affiche un formulaire d’inscription
3. Le candidat remplit ses informations sur le formulaire de
l’inscription
4. Le système demande la confirmation de l’inscription.
5. Le candidat confirme l’inscription.
6. L’agent confirme d’après le dossier envoyé par le candidat
Post-conditions Néant
Exceptions Dans le cas ou les informations qui sont introduit par le
candidat sont fausses, l’AgentAd peut les corriger
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
47
Cas d’utilisation N°7 « Gestion des convocations » :
Diagramme :
Figure 10 : Cas d’utilisation N°7 «Gestion des convocations »
Description sommaire
Titre Gestion des convocations
But Permettre de créer, imprimer et envoyer les convocations aux
candidats
Acteurs DirecteurPGR, AgentAd
Description des enchainements
Pré-conditions Le délai de l’inscription est dépassé
Enchainements
1. L’utilisateur s’authentifie
2. L’utilisateur accède à l’espace des convocations
3. Le système affiche le détail de convocation
4. L’utilisateur choisit le (les) candidats(s) concerné(s)
5. Le système demande la confirmation.
6. L’utilisateur confirme la convocation.
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
48
Cas d’utilisation N°8 « Affectation des candidats aux salles » :
Diagramme :
Figure 11 : Cas d’utilisation N°8 «Affectation des candidats aux salles»
Description sommaire
Titre Affectation des candidats aux salles
But Permettre d’affecter les candidats aux selles
Acteurs DirecteurPGR, AgentAd
Description des enchainements
Pré-conditions La gestion d’inscription des candidats est terminée
Enchainements
1. L’utilisateur s’authentifie
2. L’utilisateur accède à l’espace d’affectation
3. L’utilisateur affecte les candidats aux salles (amphis)
disponible.
4. Le système demande la confirmation.
5. L’utilisateur confirme l’affectation.
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
49
Cas d’utilisation N°9 « Détermination de résultat de concours » :
Diagramme :
Figure 12 : Cas d’utilisation N°9 «Détermination de résultat de concours »
Description sommaire
Titre Détermination de résultat de concours
But Ce cas nous permet de saisir les notes et les moyennes
obtenus, et la liste des admis et des attentes
Acteurs DirecteurPGR, ResponsableED, PrésidentCS
Description des enchainements
Pré-conditions Néant
Enchainements
1. Le ResponsableED s’authentifie
2. Le ResponsableED accède à l’espace des notes de concours
3. Le système affiche la liste des candidats
4. Le ResponsableED remplit les notes
5. Le système demande la confirmation.
6. Le système affiche la liste des admis et des attentes
automatiquement.
7. Le PrésidentCS accède au résultat de concours et le valide
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
50
Cas d’utilisation N°10 « Inscription scolaire » :
Diagramme :
Figure 13 : Cas d’utilisation N°10 «Inscription scolaire »
Description sommaire
Titre Inscription scolaire
But
Ce cas nous permet d’inscrire les 1ère
s années, 2ème
s années
magistère et les doctorants (même la prolongation pour les
2ème
années et les doctorants)
Acteurs DirecteurPGR, ResponsableED, PrésidentCS
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’utilisateur s’authentifie
2. Le ResponsableED accède à l’espace inscriptions
3. Le système affiche la liste des étudiants qualifiés à
l’inscription.
4. L’utilisateur confirme l’inscription des étudiants ayant
toutes les conditions pour l’inscription
5. Le système propose à l’utilisateur d’imprimer le certificat de
la scolarité
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
51
Cas d’utilisation N°11 « Gestion des plannings» :
Diagramme :
Figure 14 : Cas d’utilisation N°11 «Elaboration des plannings »
Description sommaire
Titre Elaboration des plannings
But
Ce cas nous permet de préparer les différents plannings
(concours, emploi du temps, examens, mini-projets,
soutenances)
Acteurs DirecteurPGR, ResponsableED, AgentAd
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’utilisateur s’authentifie
2. L’utilisateur accède à l’espace des plannings
3. Le système affiche la liste des plannings (concours, emploi
du temps, examens, mini-projets, soutenances)
4. L’utilisateur sélectionne un type de planning
5. Le système affiche l’éditeur approprie à la sélection
6. L’utilisateur crée le planning et l’enregistre
7. Le système propose à l’utilisateur d’imprimer le planning
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
52
Cas d’utilisation N°12 « Gestion d’assiduité des 1ères années» :
Diagramme :
Figure 15 : Cas d’utilisation N°12 «Gestion d’assiduité des 1ère années magistère »
Description sommaire
Titre Gestion d’assiduité des 1ères
années magistère
But Ce cas nous permet de suivre l’assiduité des 1
ères années
magistère
Acteurs AgentAd
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’AgentAd s’authentifie
2. L’AgentAd accède à l’espace des assiduités
3. Le système affiche la liste des étudiants
4. L’AgentAd sélectionne les étudiants absents et enregistre la
liste
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
53
Cas d’utilisation N°13 « Introduction du résultat des examens » :
Diagramme :
Figure 16 : Cas d’utilisation N°13 « Introduction du résultat des examens »
Description sommaire
Titre Introduction du résultat des examens
But Ce cas nous permet d’introduire le résultat des examens au
système
Acteurs ResponsableED
Description des enchainements
Pré-conditions Néant
Enchainements
1. Le ResponsableED s’authentifie
2. Le ResponsableED accède à l’espace des examens
3. Le système affiche la liste des étudiants
4. Le ResponsableED introduis les notes des étudiants
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
54
Cas d’utilisation N°14 « Gestion des projets » :
Diagramme :
Figure 17 : Cas d’utilisation N°14 « Gestion des projets »
Souscas d’utilisation « Proposition des projets » :
Description sommaire
Titre Proposition des projets
But Ce cas permet à l’enseignant de proposer un nouveau projet
(pour les 1ère
s années on a le mini-projet)
Acteurs Enseignant
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’Enseignant s’authentifie
2. L’enseignant accède à l’espace des projets et propose un
nouveau projet (il introduit le titre et le résumé de ce sujet)
3. Le système affiche une fenêtre de confirmation
4. l’enseignant confirme l’opération
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
55
Souscas d’utilisation « Affectation des projets aux étudiants» :
Description sommaire
Titre Affectation des projets aux étudiants
But Ce cas permet à l’AgentAd d’affecter les projets aux étudiants
d’après leurs choix
Acteurs AgentAd, Enseignant (promoteur)
Description des enchainements
Pré-conditions
L’étudiant doit avoir les conditions d’accès (admit en 2ième
magistère pour le projet de magistère, ou il est un magistère
soutenu pour le projet de doctorat)
Enchainements
1. L’AgentAd s’authentifie
2. L’AgentAd accède à l’espace d’affectation des projets aux
étudiants
3. Le système affiche la liste des étudiants et la liste des
projets
4. L’AgentAd affecte un projet par étudiant
Post-conditions Néant
Exceptions Si l’étudiant est déjà affecté, le système lui demande de
contacter le directeur de la DPGR pour changer son sujet
Besoins d’IHM Utilisation d`un formulaire web
Souscas d’utilisation « Gestion du résultat de soutenance » :
Description sommaire
Titre Gestion du résultat de soutenance
But Ce cas nous permet d’introduire le résultat de soutenance (note
et mention)
Acteurs ResponsableED
Description des enchainements
Pré-conditions Le cas de suivi de soutenance est terminé
Enchainements
1. Le ResponsableED s’authentifie
2. Le ResponsableED accède à l’espace des soutenances
3. Le système affiche la liste des soutenances programmées
4. Le ResponsableED sélectionne la soutenance et introduit
son résultat
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
56
Cas d’utilisation N°15 « Modification du tableau de montant d’allocation ventilé» :
Diagramme :
Figure 18 : Cas d’utilisation N°15 «Modification du tableau de montant d’allocation ventilé »
Description sommaire
Titre Modification du tableau de montant d’allocation ventilé
But Ce cas nous permet de modifier du tableau de montant
d’allocation ventilé
Acteurs DirecteurESI, PrésidentCS
Description des enchainements
Pré-conditions L’activité est déjà crée
Enchainements
1. L’utilisateur s’authentifie
2. L’utilisateur accède à l’espace de tableau de montant
d’allocation ventilé
3. Le système affiche le tableau et donne la possibilité de le
modifier
4. L’utilisateur fait la modification et enregistre sa
modification
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
57
Cas d’utilisation N°16 « Gestion des stages et communications » :
Diagramme :
Figure 19 : Cas d’utilisation N°16 «Gestion des stages et communications »
Souscas d’utilisation « Création d’un nouveau stage ou une nouvelle communication» :
Description sommaire
Titre Création d’un nouveau stage ou une nouvelle communication
But Ce cas nous permet de créer un nouveau stage ou une nouvelle
communication
Acteurs DirecteurESI, PrésidentCS
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’utilisateur s’authentifie
2. L’utilisateur accède à l’espace de stage/communication
3. L’utilisateur demande une création de nouveau stage
4. Le système affiche un formulaire de stage
5. l’utilisateur remplit les informations du stage
5. le système demande une confirmation
6. l’utilisateur enregistre le nouveau stage
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
58
Souscas d’utilisation « Détermination du résultat de stage ou de communication » :
Description sommaire
Titre Détermination du résultat de stage ou de communication
But Ce cas nous permet de déterminer le résultat de stage ou de
communication
Acteurs DirecteurESI, PrésidentCS
Description des enchainements
Pré-conditions Néant
Enchainements
1. Le PrésidentCS s’authentifie
2. Le PrésidentCS accède à l’espace de stage/communication
3. Le système affiche la liste des stages en cours
4. Le PrésidentCS sélectionne le stage/communication et
introduit son résultat
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
59
Cas d’utilisation N°17 « Gestion de projets de recherche» :
Diagramme :
Figure 20 : Cas d’utilisation N°17 «Gestion de projets de recherche »
Souscas d’utilisation « Création d’un projet de recherche » :
Description sommaire
Titre Création d’un nouveau projet de recherche
But Ce cas permet de crée un nouveau projet de recherche
Acteurs Enseignant
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’Enseignant s’authentifie
2. L’enseignant accède à l’espace des projets et propose un
nouveau projet (il introduit le titre et le résumé de ce sujet)
3. Le système affiche une fenêtre de confirmation
4. l’enseignant confirme l’opération
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
60
Souscas d’utilisation « Suivi des projets de recherche» :
Description sommaire
Titre Suivi des projets de recherche
But Ce cas permet de suivre un projet de recherche chaque
semestre
Acteurs PrésidentCS
Description des enchainements
Pré-conditions Néant
Enchainements
1. Le PrésidentCS s’authentifie
2. Le PrésidentCS accède à l’espace de projets de recherche
3. Le PrésidentCS choisit le projet concerné
4. Le PrésidentCS mis à jour les informations du projet
5. Le PrésidentCS enregistre les informations
6. Le système affiche une fenêtre confirmant l’enregistrement
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
Souscas d’utilisation « Détermination du résultat de projet de recherche» :
Description sommaire
Titre Détermination du résultat de projet de recherche
But Ce cas nous permet de déterminer le résultat d’un projet de
recherche
Acteurs PrésidentCS
Description des enchainements
Pré-conditions Néant
Enchainements
1. Le PrésidentCS s’authentifie
2. Le PrésidentCS accède à l’espace de projets de recherche
3. Le système affiche la liste des projets
4. Le PrésidentCS sélectionne le projet et introduit son résultat
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
61
Cas d’utilisation N°18 « Consultation des statistiques » :
Diagramme :
Figure 21 : Cas d’utilisation N°18 « Consultation des statistiques »
Description sommaire
Titre Consultation des statistiques
But Ce cas nous permet de consulter les statistiques
Acteurs DirecteurESI, Président CS, DirecteurPGR, MESRS, AgentAd
Description des enchainements
Pré-conditions Néant
Enchainements
1. L’utilisateur s’authentifie
2. L’utilisateur accède à l’espace de statistiques
3. Le système affiche la fenêtre contenant le détail de
statistiques
4. L’utilisateur peut consulte ou télécharger les statistiques
Post-conditions Néant
Exceptions Néant
Besoins d’IHM Utilisation d`un formulaire web
ESI 2009/2010 ANALYSE
62
III.2.5. Regroupement des cas d’utilisation en package :
Nous allons découper les cas d’utilisation en 6 packages, à savoir :
Package Cas d’utilisation Acteurs
Organisation du concours
d’accès à l’école doctorale
Détermination des options et
des modules
Candidat, AgentAd,
PrésidentCS, DirecteurPGR,
DirecteurE, ResponsableED
Création du concours
Inscription des candidats au
concours
Affectation des candidats et
des surveillants aux salles
Préparation des convocations
Saisie de notes
Délibération et résultat du
concours
Gestion de la scolarité de
l’école doctorale
Inscription des étudiants
Etudiant, AgentAd,
DirecteurPGR, Enseignant,
ResponsableED
Elaboration des emplois du
temps
Suivi de l’assiduité des
étudiants
Gestion des examens et
délibération
Suivi des projets des
étudiants
Enregistrement des projets
affectés aux étudiants Etudiant, PrésidentCS,
DirecteurPGR, AgentAd,
promoteur Suivi de l’avancement des
projets
Gestion des soutenances
Constitution des jurys
DirecteurPGR, Enseignant,
PrésidentCS, Etudiant,
Promoteur, Jury
Elaboration des plannings
des soutenances
Enregistrement des résultats
des soutenances
Suivi des projets de
recherche
Enregistrement des projets de
recherche
DirecteurPGR, Enseignant,
PrésidentCS
Suivi de l’avancement des
projets
Gestion des promotions dans
la recherche
Gestion des nouvelles
intégrations
Gestion des activités
scientifiques et pédagogiques
Création d’une nouvelle
activité scientifique
DirecteurPGR, DirecteurESI,
Enseignant, PrésidentCS
Suivi des activités
scientifiques
Elaboration des statistiques
(activité pédagogique)
ESI 2009/2010 ANALYSE
63
Organisation du concours d’accès à l’école doctorale :
Figure 22. Organisation du concours d’accès à l’école doctorale
Gestion de la scolarité de l’école doctorale :
Figure 23. Gestion de la scolarité de l’école doctorale
ESI 2009/2010 ANALYSE
64
Suivi des projets des étudiants :
Figure 24. Suivi des projets des étudiants
Gestion des soutenances :
Figure 25. Gestion des soutenances
ESI 2009/2010 ANALYSE
65
Suivi des projets de recherche :
Figure 26. Suivi des projets de recherche
Gestion des activités scientifiques et pédagogiques :
Figure 27. Gestion des activités scientifiques et pédagogiques
ESI 2009/2010 ANALYSE
66
III.3. Analyse statique :
Cette phase doit déterminer le modèle statique du système qui consiste à déterminer
les objets, leurs attributs et leurs méthodes ainsi que les relations qui relient ces objets.
Pour bien présenter les objets du nouveau système, on a fait une description des objets
de leurs caractéristiques ainsi que les relations qui existent entre eux représentés par cas
d’utilisation, et pour cela nous avons procédé comme suit :
Identification des classes candidates
Les diagrammes des classes par cas d’utilisation
III.3.1. Identification des classes candidates :
Candidats
Options
Concours
Etablissement
Universitaires
Modules
Etudiants
Salles
Enseignants
Délibérations
Séances
Sanctions
Absences
Niveaux
Années
Universitaires
Wilayas
Personnes
Pays
Projets
Mémoire
Type Projet
Recherche
Promoteur
Laboratoire
Rapport
Avancement
Etablissement
Surveillant
Soutenances
Date
Activité
Scientifique
Type Activité
Catégorie
Pays
Compte Utilisateur
Grade
Privilège
Région
Message
Etat
Module Concours
Etat Etudiant
Montant
Allocation
ESI 2009/2010 ANALYSE
67
Diagramme de classes par packages :
Diagramme de classe associé à la gestion de concours:
Figure 28 : Diagramme de classe associé à la gestion de concours
ESI 2009/2010 ANALYSE
68
Diagramme de classe associé à la gestion de la scolarité :
Figure 29 : Diagramme de classe associé à la gestion de la scolarité
ESI 2009/2010 ANALYSE
69
Diagramme de classe associé à la gestion de soutenance :
Figure 30 : Diagramme de classe associé à la gestion de soutenance
ESI 2009/2010 ANALYSE
70
Diagramme de classe associé à la gestion de projet de recherche :
Figure 31 : Diagramme de classe associé à la gestion de projet de recherche
ESI 2009/2010 ANALYSE
71
Diagramme de classe associé à la gestion des activités scientifiques :
Figure 32 : Diagramme de classe associé à la gestion des activités scientifiques
ESI 2009/2010 ANALYSE
72
III.3.2. Description détaillée des classes d’objet :
Classe Attributs Description
Année
universitaire
idAun Ex. : 2009/2010
etatAun nouvelle, en cours, clôturée
dateInit Date d’initialisation
dateCloture Date de clôture
Candidat
idCnd Numéro séquentiel
prefixeCnd M., Mlle, Mme
nomCnd Le nom
prenomCnd Le prénom
dateNaissCnd La date de naissance
wilayaNaiss La wilaya de naissance
adrCnd L’adresse
communeNaiss La commune de la naissance
paysCnd Pays de la nationalité
telCnd Numéro de téléphone
emailCnd L’adresse Email
etbCnd L’établissement mère
loginCnd Le login pour passer les épreuves (ex. :
a_laribi)
pwCnd Le mot de passe pour passer les épreuves (ex. :
ade0872bou)
idCcr Le concours dont le candidat participe dans.
isInscrit Etat de l’inscription du candidat (validée, non
validée)
Catégorie
Pays
idCat Séquentiel
descCat
Les catégorie des pays selon le journal officiel
de la république algérienne N°68
(actuellement : Catégorie I et Catégorie II)
Commune
idCmn Séquentiel
nomCmn Nom de la commune
wilayaCmn Wilaya de la commune
codePostal Le code postal
Activité
scientifique
idAct Séquentiel
typeAct Séjour scientifique, stage de courte durée,
formation à l’étranger
ESI 2009/2010 ANALYSE
73
descAct Description de l’activité scientifique
dateDebutAct Date début
dureeAct Nombre de jours
montantInscr Le montant de l’inscription pour les séjours
scientifiques
montantAlloc Le montant d’allocation (de séjour)
montantTrans Le montant de transport
etatAct En cours, finie
Concours
idCcr Séquentiel
titreCcr Titre du concours
etatCcr En cours, terminé
Enseignant
idEns Séquentiel
prefixeEns M., Mme, Mlle
nomEns Le nom
prenomEns Le prénom
gradeEns VAC, MAB, MAA, MCB, MCA, PR
Établissement
Universitaire
(candidat)
idEun Séquentiel
nomEun Le nom
regionEun Centre, Est, Ouest
adrEun L’adresse
telEun Le n° de téléphone
faxEun Le n° de fax
Etablissement
(activité
scientifique)
idEtb Séquentiel
nomEtb Le nom
paysEtb Pays de l’établissement
adrEtb L’adresse de l’établissement
telEtb Le n° de téléphone
faxEtb Le n° de fax
Etudiant
idEtd Ex. : 09IRM07
prefixeEtd M., Mlle, Mme
nomEtd Le nom
prenomEtd Le prénom
dateNaissEtd La date de naissance
wilayaNaiss La wilaya de naissance
ESI 2009/2010 ANALYSE
74
adrEtd L’adresse
communeNaiss La commune de la naissance
paysEtd Pays de la nationalité
telEtd Numéro de téléphone
emailEtd L’adresse Email
etbEtd L’établissement mère
etatEtd Nouveau, scolarisé, exclu, soutenu magister,
soutenu doctorat
photoEtd La photo d’identité
Module
idMod Séquentiel
abrvMod L’abréviation
nomMod Nom du module
typeMod De concours, scolaire
Niveau
idNiv Séquentiel
descNiv Actuellement : 1
e et 2
e magister et 1
e, 2
e et 3
e
doctorat
Option
idOpt Séquentiel
abrvOpt L’abréviation
nomOpt Le nom
aunOpt L’année d’intégration
Pays
idPays Séquentiel
nomPays Le nom
catPays
Privilège idPriv Séquentiel
descPriv Description du privilège
Salle
idSalle Séquentiel
nomSalle Le nom
capaciteSalle La capacité
Utilisateur
idUser Séquentiel
loginUser Le Login
pwUser Le mot de passe
nomUser Le nom
prénomUser Le prénom
isBloque L’état de compte (actif, bloqué)
ESI 2009/2010 ANALYSE
75
typeUser Administrateur
Wilaya idWil Le code de la wilaya
nomWil Le nom
Surveillant
idSurv Séquentiel
nomSurv Le nom
prenomSurv Le prénom
Promoteur
idProm Séquentiel
gradeProm VAC, MAB, MAA, MCB, MCA, PR
isExterne Si le promoteur est externe.
nomProm Le nom
prénomProm Le prénom
Séance
idSnc Code de la séance ex. : SA1, SA2, DI1,…
typeSnc De concours, scolaire, examen
heureDebutSnc L’heure début
Durée La durée de la séance
Absence
idAbs Séquentiel
dateAbs La date
etatAbs Justifié, non justifié
Sanction idSanc Séquentiel
descSanc La description
Projet
idPrj Séquentiel
intituléPrj L’intitulé du projet
résumePrj Le résumé
probPrj Les problématiques
objPrj Les objectifs
etatPrj Nouveau, En cours, fini
typePrj Mémoire magister, thèse doctorat, mini projet,
projet de recherche
Soutenance
idSout Séquentiel
datePrévueSout La date prévue
dateEffectSout La date effective
noteSout La note de soutenance
décisionSout Passable, assez-bien, bien,…
Laboratoire idLab Séquentiel
ESI 2009/2010 ANALYSE
76
nomLab Le nom
abrvLab L’abréviation du laboratoire
Rapport
avancement
idRpt Séquentiel
dateDepot Date dépôt
descRpt Description d’état d’avancement
ESI 2009/2010 ANALYSE
77
III.3.3. Description détaillée des classes d’association :
Classe Attributs Description
Affectation
Candidat
(idCnd, idOpt,
idSalle)
Affecter ce candidat pour cette option dans cette
salle
Avoir Privilège (idTypeUser,
idPriv) Attribuer ce privilège à ce type d’utilisateur
Concours
contient option
(idCcr, idOpt) Cette option est incluse dans ce concours
dateEpreuves La date des épreuves
placeDispo Le nombre de place disponibles
placeEnAttente Le nombre de place dans la liste d’attente
Candidat état
option
(idCnd, idOpt) Ce candidat participe dans cette option
isExclu L’état du candidat
décisionDélib Admis, en attente, non admis
Note candidat
(idOpt, idMod,
idCnd) Ce candidat à l’état pour ce module de cette option
isExaminé Est-ce que le candidat passer cette épreuve
noteMod La note
Option contient
module
(idCcr, idOpt,
idMod)
Ce module est inclus dans cette option pour ce
concours
coefMod Le coefficient
dateMod La date
heureDebutMod L’heure début
dureeMod Nombre de minute
Ouvrir option (idAun, idOpt) Cette année universitaire, on ouvre cette option
Passer épreuve
(IdCnd, idEpr,
idSal) Un candidat passer une épreuve à une salle
noteEpr La note obtenue dans l’épreuve
Etat Avancement
(idMem,
etatMem) L’état d’un mémoire
etatAvanc Etat avancement
Promouvoir
Grade
(idEns,
codeGra, date) L’enseignant obtient un grade
decPromoGra La décision
etatPromoGra L’état de la promotion
ESI 2009/2010 ANALYSE
78
III.4. Analyse dynamique :
Cette phase a pour but de préciser la modélisation dynamique du nouveau système en
sebasant sur divers modèles, nous y utiliserons deux diagrammes, à savoir :
Diagramme de séquence : quipermet de représenter des collaborations entre objets
impliqués dans les scénarios (présentés dans les cas d’utilisation) selon un point de
vue temporel, on y met l'accent sur la chronologie des envois de messages.
Diagramme d’états / transitions : qui sert à représenter des automates d'états finis, sous
forme de graphes d'états, reliés par des arcs orientés qui décrivent les transitions. Il
permet de décrire les changements d'états d'un objet, en réponse aux interactions avec
d'autres objets/composants ou avec des acteurs.
III.4.1. Les Diagrammes de séquences :
Diagramme de séquence N°1 : Affection des candidats aux salles
Figure 33. Diagramme de séquence N°1 : Affection des candidats aux salles
ESI 2009/2010 ANALYSE
79
Diagramme de séquence N°2 : Gestion de connexion des utilisateurs :
Figure 34. Diagramme de séquence N°2 : Gestion de connexion des utilisateurs
Diagramme de séquence N°3 : Initialisation de l’année scolaire (universitaire) :
Figure 35 : Diagramme de séquence N°3 : Initialisation de l’année scolaire
ESI 2009/2010 ANALYSE
80
Diagramme de séquence N°4 : Gestion des messages d'accueil :
Figure 36. Diagramme de séquence N°4 : Gestion des messages d'accueil
Diagramme de séquence N°5 : Proposition de projets :
Figure 37. Diagramme de séquence N°5 : Proposition de projets
ESI 2009/2010 ANALYSE
81
Diagramme de séquence N°6 : Gestion des utilisateurs :
Figure 38. Diagramme de séquence N°6 : Gestion des utilisateurs
Diagramme de séquence N°7 : Inscription en ligne :
Figure 39. Diagramme de séquence N°7 : Inscription en ligne
ESI 2009/2010 ANALYSE
82
Diagramme de séquence N°8 : Gestion des convocations :
Figure 40. Diagramme de séquence N°8 : Gestion des convocations
Diagramme de séquence N°9 : Gestion des options et des modules :
Figure 41. Diagramme de séquence N°9 : Gestion des options et des modules
ESI 2009/2010 ANALYSE
83
Diagramme de séquence N°10 : Gestion des options et des modules :
Figure 42. Diagramme de séquence N°10: Gestion des options et des modules
Diagramme de séquence N°11 : Gestion de résultat de soutenance :
Figure 43. Diagramme de séquence N°11 : Gestion de résultat de soutenance
ESI 2009/2010 ANALYSE
84
Diagramme de séquence N°12 : Création d'une nouvelle communication (stage) :
Figure 44. Diagramme de séquence N°12 : Création d'une nouvelle communication (stage)
III.4.2. Les Diagrammes des états / transitions :
Les états d’un projet :
Figure 45. Diagramme de transition d'un projet
ESI 2009/2010 ANALYSE
85
Les états du candidat :
Figure 46. Diagramme de transition d'un candidat
ESI 2009/2010 ANALYSE
86
Les états d’un étudiant :
Figure 47. Diagramme de transition d'un étudiant
ESI 2009/2010 ANALYSE
87
Les états d’un profil utilisateur :
Figure 48: Diagramme de transition d'un profil utilisateur
Les états d’une année universitaire :
Figure 49: Diagramme de transition d'une année universitaire
ESI 2009/2010 ANALYSE
88
III.5. Conclusion :
Au cours de l’étape de l’analyse nous avons donné une synthèse sur l’axe fonctionnel
par la détermination des acteurs, une brève description des cas utilisation, le regroupement des
cas et la définition de quelques relations d’extension et d’inclusions entre cas d’utilisation.
Nous avons élaboré le modèle statique globale et le modèle dynamique global. Donc nous
avons préparé le projet pour l’étape suivante qui est la conception pour proposer des solutions
concrètes pour le problème posé.
Au cours de la phase d’analyse, nous nous sommes concentrés sur ce qui devait être
fait, le quoi, indépendamment de la manière de le faire, le comment. Au cours de la
conception, des décisions doivent être prises concernant la façon de résoudre le problème,
d’abord à un niveau général, puis à des niveaux de détail de plus en plus fins [ROQ, VAL,
2002].
CONCEPTION
ESI 2009/2010 CONCEPTION
90
IV. CONCEPTION :
IV.1. Introduction :
La conception du nouveau système vient donner suite à l’analyse qui l’a préparé en
présentant les deux modèles statique et dynamique. Cela en enlevant cette abstraction qui a
caractérisé l’analyse pour présenter clairement la conception du système et aussi de même
pour la conception des objets.
Ainsi, après avoir expliqué les différentes fonctionnalités que comporte le
nouveau système et ses interactions avec les divers acteurs, vient cette phase pour en
donner une vision de son implémentation.
ESI 2009/2010 CONCEPTION
91
IV.2. Conception du système (conception générale) :
La conception du système est la première étape de conception, au cours de laquelle
doit être choisie une approche de base pour la résolution du problème. Pendant la conception
du système, on décide de la structure générale et du style à adopter. L’architecture du système
désigne l’organisation du système en composants appelés sous-systèmes.
L’architecture fournit le contexte dans lequel seront prises des décisions plus
détaillées, au cours des phases ultérieures de conception. En prenant des décisions de haut
niveau s’appliquant au système entier, le concepteur effectue une partition du problème en
sous-systèmes, afin que les travaux suivants puissent être assurés par plusieurs concepteurs
travaillant indépendamment sur des sous-systèmes différents [ROQ, VAL, 2002].
IV.2.1. Schéma de l’architecture du nouveau système :
Comme le système est une solution web, les différents utilisateurs devront se
connecter par internet pour pouvoir accéder à leurs comptes respectifs.
On a décidé d’adopter un schéma de déploiement multi tiers (plusieurs serveurs).
Voici le schéma de la solution :
Figure 50 : Architecture du nouveau système
ESI 2009/2010 CONCEPTION
92
IV.2.2. Les avantages de l’architecture multi tiers:
Tendance au couplage faible : possibilité de remplacer un composant par un autre.
Système ajusté : Le système n’impose aucune restructuration ni nouvelle fonction plutôt
il est ajusté pour coller à la structuration en vigueur et garde (pour faciliter le processus
d’adaptation aux utilisateurs) la majorité des termes et processus utilisés actuellement ;
Facilité d’utilisation : Utiliser le système se résume à cliquer sur les liens, suivre les
instructions et consulter les résultats et les rapports sur des pages WEB.
Sécurité des données : Les données sont stockées au niveau de serveur protégé et tout accès
est tracé et sécurisé. Ces données se voient traitées localement sans être transférées par
internet qu’en cas de besoin (des cas particuliers avec un nombre réduit) pour diminuer
le risque qu’elles soient interceptées ;
Intégrité des données : Le système gère la consultation, l’ajout et la suppression des données
au niveau des différents serveurs de données, de façon à éviter les contradictions et les
redondances (qui peuvent être permises suivant le besoin) ;
IV.2.3. Les inconvénients de l’architecture multi tiers:
Problème de sécurité : Comme l’accès au système s’accomplit via internet, le risque
d’attaques est permanent (aucun firewall n’est impénétrable à 100%);
Problème de coût : La nature du système et encore plus la sensibilité et l’importance des
informations gérées exigent l’acquisition de firewall et antivirus professionnels et de marque
(frais d’acquisition et d’utilisation élevés) ;
IV.2.4. Description des serveurs :
Serveur de base de données : SQL Server
SQL Server est un SGBD de Microsoft (Système de Gestion de
Base de Données). Il est particulièrement adapté aux systèmes d’E-
Business et de DataWare Housing (on parle aussi de Workflow). Il inclut un support XML et
HTTP, permettant d’accéder aux données depuis un navigateur, ou d’une application pouvant
créer des requêtes HTTP.
Ses avantages sont multiples :
Performant : SQL Server se classe parmi les SGBDR les plus rapides
Evolutif et fiable : vous pouvez répartir la charge sur plusieurs serveurs, bénéficier des
avantages des systèmes multi-processeurs (SMP – Sysmetric Multi Processing) et profiter des
performances de Windows DataCenter Server qui supporte 32 processeurs et 64 GO de ram).
ESI 2009/2010 CONCEPTION
93
Rapidité de mise en œuvre : avec SQL Server, le développement, le déploiement et
l’administration d’applications destinées au Web sont accélérés grâce aux nombreuses
fonctionnalités dédiées, ainsi qu’au support du Web.
Serveur Web : IIS
Internet Information Services, communément appelé IIS, est le logiciel de
serveur Web (ou HTTP) de la plateforme Windows NT.
ASP et plus récemment ASP.NET sont les deux technologies de développement Web de
Microsoft. Toutes deux sont nativement supportées par le serveur IIS (versions récentes d'IIS
seulement pour l’ASP.NET). La consultation des articles éponymes offre plus de détails quant
à la construction, au fonctionnement et au développement de ces langages.
Serveur de messagerie : Gmail
Gmail est un service de messagerie gratuit proposé par Google. Les
messages reçus sur un compte Gmail peuvent aussi bien être lus via un
client de messagerie (grâce à sa compatibilité avec les protocoles POP3 et IMAP) qu'avec un
navigateur web. De nombreuses fonctionnalités du service ne sont cependant accessibles qu'à
travers le navigateur web. En février 2010, 176 millions d'internautes utilisent ce service de
messagerie électronique.
À son lancement le 1er avril 2004, l'inscription nécessitait une invitation. Deux ans plus tard,
la version bêta fut ouverte au public. À l'époque, avec une capacité initiale de 1 GO (Environ
7 456 Mo maintenant). La capacité de stockage a augmenté de 6 GO en 5 ans. Depuis le 7
juillet 2009, le service n'a plus le statut de bêta.
Antivirus et pare-feu : Kaspersky Internet Security
Kaspersky Internet Security offre un nombre d’options et de caractéristiques résolument
nouvelles associées à des technologies de protection uniques pour répondre aux cyber-
menaces en ligne les plus récentes. Les technologies primées de Kaspersky Internet Security
protègent le système contre un large éventail de cyber-menaces :
Virus, chevaux de Troie, vers informatiques et autres malware, spyware et adware
Rootkits, bootkits et autres cyber-menaces complexes
Usurpation d’identité par les keyloggers (enregistreurs de frappe, captures d’écran
malicieuses) ou par phishing
Botnets et autres méthodes illégales de prise de contrôle du PC
Attaques zero-day, cyber-menaces inconnues et se propageant rapidement
Infections par téléchargement à la dérobée, attaques de réseaux et intrusions
Contenu web indésirable et spam [KIS 2010]
ESI 2009/2010 CONCEPTION
94
IV.2.5. Principe de fonctionnement :
Le principe de fonctionnement de notre système est présenté dans le diagramme d’activité
suivant :
Figure 51 : Principe de fonctionnement
Si un utilisateur désire de se connecter au système en introduisant le login et le mot
de passe, la première étape consiste à vérifier la disponibilité de celui-ci, s’il existe et est ce
que son profil est activé ou bien sa durée limité n’est pas expirée.
Dans le cas du succès, le système génère un accès pour cet utilisateur et enregistrant les
informations nécessaire suivantes : le login, le date de l’accès et les informations
concernant le poste de connexion telle que l’adresse IP et l’adresse MAC.
La dernière étape consiste à charger l’application à base du profil de l’utilisateur, donc une
classe .NET va charger les données qui composent l’arborescence des objets, les
composants du menu général les menus secondaires, les pages et les panneaux
d’affichage. Mais aussi les droits pour les opérations du MAJ sous forme du bottons
de validation est ce qu’ils apparaissent dans les pages appropriées ou pas.
ESI 2009/2010 CONCEPTION
95
IV.2.6. Découpage du système en sous-systèmes :
Les fonctionnalités du système sont basées sur les cas d’utilisation de l’étape de l’analyse et
sont regroupées en modules qui forment les sous-systèmes.
Donc dans la conception : les package seront transformés en sous système et les cas
d’utilisation en module et les modules englobent un certain nombre de fonctionnalités. La
figure suivante décrit la hiérarchie :
Figure 52 : Hiérarchie de développement.
IV.2.7. Présentation des sous-systèmes :
Sous système Module Fonctionnalité
Gestion des
ressources
Gestion de l'année
universitaire
Mise à jour de l'année universitaire
(Création, initialisation, clôture)
Gestion des
moyens.
Gestion des salles.
Gestion des laboratoires.
Gestion des établissements.
…
Suivi des options et
modules (concours
et examens).
Mise à jour des niveaux, options et des
module.
ESI 2009/2010 CONCEPTION
96
Gestion des
enseignants. Mise à jour des enseignants (chercheurs).
Sécurité
Gestion de la
base de
données
Connexion à la base de données.
Exécution des requêtes.
Chargement des images.
Importation de la base de données.
Exportation de la base de données.
Administration
du système
Gestion des utilisateurs.
Gestion des profils.
Gestion des
traces.
Gestion des accès.
Elaboration de rapport de traces.
Activités
pédagogiques
Gestion de
l'assiduité.
Saisie d'absence des étudiants aux
séances, examens.
Saisie d'absence des enseignants
aux séances.
Saisie des sanctions et des justifications
(élèves, enseignants).
Inscription et
réinscription des
étudiants et candidat.
Inscription des nouveaux candidats,
étudiants.
Réinscription des anciens étudiants.
Gestion des notes
Paramétrage des notes.
Saisie des notes des étudiants.
Saisie des notes des candidats de concours.
Calcul des moyennes et affectation des
mentions aux étudiants.
Elaborations des bulletins de notes.
ESI 2009/2010 CONCEPTION
97
Tableau 15 : Découpage du système en sous-systèmes
Gestion des
délibérations
(passage)
Génération automatique des décisions de
délibérations à bases des paramètres
prédéfinis.
Saisie des décisions de délibérations des
étudiants et candidats.
Plannings
Gestion emploi du
temps.
Saisie et consultation des emplois de temps
par option.
Gestion des
plannings de
concours et des
examens
Saisie et consultation des plannings de
concours et des examens.
Gestion des
plannings de
soutenances
Saisie et consultation des plannings de
soutenances.
Statistiques et
rapports
Elaboration des
statistiques et des
rapports
Elaborer et consulter les statistiques et les
rapports.
Activités
scientifiques
Gérer les séjours
scientifiques
Suivi les séjours scientifiques
Ajouter nouveau séjour scientifique
Change l’état d’un séjour scientifique
Gérer les stages de
courte durée
Suivi les stages de courte durée
Ajouter nouveau stage
Change l’état d’un stage
Projets de
recherche
Gérer les projets de
recherche
Créer un projet de recherche
Intégrer un nouveau membre
Ajouter un rapport d’avancement
ESI 2009/2010 CONCEPTION
98
Remarque :
Le sous-système « Administration » :
Il prend en charge principalement les activités de l’administrateur qui se résument à toutes les
opérations qui paramètrent et préparent le système dans son fonctionnement ainsi que sa
supervision.
Le module « Gestion des utilisateurs » : Il permet de gérer les profils des utilisateurs(gestion
des privilèges et informations pour chaque profil) et leurs comptes (création, modification et
mise à jour, suppression, suspension, …etc.), et d’avoir accès aux historiques et traces
des opérations effectuées par les utilisateurs.
Le module « Authentification » : Il concerne essentiellement la gestion des accès
utilisateurs (vérification des noms d’utilisateur et les mots de passe pour assurer les identités
des entrants) et par la suite garder une trace de chaque accès.
Le sous-système « Statistiques et rapports » :
Il comporte intégralement un seul module.
Le module « Génération des statistiques et des rapports ». Il prend en charge la
génération des statistiques et l’établissement des rapports pour le suivie générale des
opérations et processus (se basant sur divers indicateurs) pour avoir une idée sur la marche du
système dans son intégralité, afin d’aider dans la prise de décision.
IV.2.8. Gestion de la persistance de données :
Ça correspond à la conception et l’implémentation d’une base de données en se basant
sur le diagramme de classe élaboré lors de l’analyse du nouveau système, et sous cet angle,
il faut noter que bien gérer les données et les interactions est un sujet délicat est important
pour la bonne marche du système, pour notre part, on a choisi d’utiliser le SGBD SQL Server
pour tout ce qui concerne la persistance de données qui, avec plus de détail, sera traitée dans
la partie Conception des objets.
ESI 2009/2010 CONCEPTION
99
IV.3. Conception des objets (conception détaillée) :
La conception détaillée est la phase ultime de la modélisation qui consiste à construire
et à documenter précisément les classes, les tables et les méthodes qui constituent le codage
de la solution, le noyau central de cette étape est le diagramme des classes, donc dans tout le
reste de travail on concentre sur l'enrichissement de ce dernier en déterminant la liste
d'attributs par classe et en précisant toutes les méthodes qui assurent les fonctionnalités du
système. Nous allons décrire les types de classes qui forment le diagramme de classes de
conception :
Les classes entités (classes d’objet et classes d’association) :
Les classes métier, qui proviennent directement du modèle du domaine, sont qualifiées
d’entités. Ces classes sont généralement persistantes, c’est-à-dire qu’elles survivent à
l’exécution d’un cas d’utilisation particulier et qu’elles permettent à des données et des
relations d’être stockées dans des fichiers ou des bases de données. Lors de l’implémentation,
ces classes peuvent ne pas se concrétiser par des classes mais par des relations, au sens des
bases de données relationnelles [ROQ, 2002].
Les classes de dialogues (frontières ou IHM) :
Les classes qui permettent les interactions entre l’IHM et les utilisateurs sont qualifiées de
dialogues. Ces classes sont directement issues de l’analyse. Il y a au moins un dialogue pour
chaque association entre un acteur et un cas d’utilisation du diagramme de cas d’utilisation.
En général, les dialogues vivent seulement le temps du déroulement du cas d’utilisation
concerné [ROQ, 2002].
Les classes de contrôles :
Les classes qui modélisent la cinématique de l’application sont appelées contrôles. Elles font
la jonction entre les dialogues et les classes métier en permettant aux différentes vues de
l’application de manipuler des informations détenues par un ou plusieurs objets métier. Elles
contiennent les règles applicatives et les isolent à la fois des dialogues et des entités [ROQ,
2002].
On ajoutera aussi des associations entre les classes d'analyse, mais avec des règles strictes :
Les dialogues ne peuvent être reliés qu’à des contrôles ou d’autres dialogues. En
général, les associations sont unidirectionnelles, de dialogue vers contrôle.
Les entités ne peuvent être reliées qu’aux contrôles ou à d’autres entités. Toujours
unidirectionnelles et dans le sens de contrôle vers entité.
Les contrôles ont accès à tout type de classe, y compris d’autres contrôles.
Les acteurs peuvent aussi être rajoutés à ces diagrammes, un acteur ne pouvant être
relié qu’à un dialogue.
ESI 2009/2010 CONCEPTION
100
IV.3.1. Schéma général de l’implémentation :
Concernant l’implémentation, on tient compte de l’architecture physique déjà présentée, ce
qui nous amène à avoir le schéma général suivant :
Tableau 16 : Schéma général de l’implémentation
Après avoir éliminé l’abstraction qui caractérisait l’analyse et pris conscience des
spécifications de l’implémentation et ce qui en résulte, on peut finaliser les classes d’objet et
les classes d’association en apportant des modifications et quelques ajouts.
IV.3.2. Implémentation des classes d’objet :
Classe Attributs Type (taille) Description
Année
universitaire
idAun Char(9) Ex. : 2009/2010
etatAun Enum nouvelle, en cours, clôturée
dateInit Date Date d’initialisation
dateCloture Date Date de clôture
Candidat
idCnd Int Numéro séquentiel
prefixeCnd Enum M., Mlle, Mme
nomCnd Varchar(50) Le nom
prenomCnd Varchar(50) Le prénom
dateNaissCnd Date La date de naissance
wilayaNaiss Wilaya La wilaya de naissance
ESI 2009/2010 CONCEPTION
101
adrCnd Varchar(100) L’adresse
communeNaiss Commune La commune de la naissance
paysCnd Pays Pays de la nationalité
telCnd Varchar(20) Numéro de téléphone
emailCnd Varchar(80) L’adresse Email
etbCnd EtablissementUniv L’établissement mère
loginCnd Varchar(50) Le login pour passer les
épreuves (ex. : a_laribi)
pwCnd Varchar(50)
Le mot de passe pour passer
les épreuves (ex. :
ade0872bou)
idCcr Concours Le concours dont le candidat
participe dans.
isInscrit Booléen
Etat de l’inscription du
candidat (validée, non
validée)
Catégorie
Pays
idCat Int Séquentiel
descCat Varchar(50)
Les catégorie des pays selon
le journal officiel de la
république algérienne N°68
(actuellement : Catégorie I et
Catégorie II)
Commune
idCmn Int Séquentiel
nomCmn Varchar(60) Nom de la commune
wilayaCmn Wilaya Wilaya de la commune
codePostal Int Le code postal
Activité
scientifique
idAct Int Séquentiel
typeAct Enum
Séjour scientifique, stage de
courte durée, formation à
l’étranger
descAct Text Description de l’activité
scientifique
dateDebutAct Date Date début
dureeAct Int Nombre de jours
montantInscr Float Le montant de l’inscription
pour les séjours scientifiques
montantAlloc Float Le montant d’allocation (de
séjour)
montantTrans Float Le montant de transport
etatAct Enum En cours, finie
Concours idCcr Int Séquentiel
ESI 2009/2010 CONCEPTION
102
titreCcr Varchar(200) Titre du concours
etatCcr Enum En cours, terminé
Enseignant
idEns Int Séquentiel
prefixeEns Enum M., Mme, Mlle
nomEns Varchar(50) Le nom
prenomEns Varchar(50) Le prénom
gradeEns Enum VAC, MAB, MAA, MCB,
MCA, PR
Établissement
Universitaire
(candidat)
idEun Int Séquentiel
nomEun Varchar(200) Le nom
regionEun Enum Centre, Est, Ouest
adrEun Varchar(200) L’adresse
telEun Varchar(20) Le n° de téléphone
faxEun Varchar(20) Le n° de fax
Etablissement
(activité
scientifique)
idEtb Int Séquentiel
nomEtb Varchar(100) Le nom
paysEtb Pays Pays de l’établissement
adrEtb Varchar(200) L’adresse de l’établissement
telEtb Varchar(20) Le n° de téléphone
faxEtb Varchar(20) Le n° de fax
Etudiant
idEtd Char(7) Ex. : 09IRM07
prefixeEtd Enum M., Mlle, Mme
nomEtd Varchar(50) Le nom
prenomEtd Varchar(50) Le prénom
dateNaissEtd Date La date de naissance
wilayaNaiss Wilaya La wilaya de naissance
adrEtd Varchar(100) L’adresse
communeNaiss Commune La commune de la naissance
paysEtd Pays Pays de la nationalité
telEtd Varchar(20) Numéro de téléphone
emailEtd Varchar(80) L’adresse Email
etbEtd EtablissementUniv L’établissement mère
etatEtd Enum
Nouveau, scolarisé, exclu,
soutenu magister, soutenu
doctorat
ESI 2009/2010 CONCEPTION
103
photoEtd Byte[] La photo d’identité
Module
idMod Int Séquentiel
abrvMod Varchar(7) L’abréviation
nomMod Varchar(50) Nom du module
typeMod Enum De concours, scolaire
Niveau
idNiv idNiv Séquentiel
descNiv Varchar(50)
Actuellement : 1e et 2
e
magister et 1e, 2
e et 3
e
doctorat
Option
idOpt Int Séquentiel
abrvOpt Varchar(7) L’abréviation
nomOpt Varchar(100) Le nom
aunOpt Année
universitaire L’année d’intégration
Pays
idPays Int Séquentiel
nomPays Varchar(100) Le nom
catPays Catégorie pays
Privilège idPriv Int Séquentiel
descPriv Varchar(200) Description du privilège
Salle
idSalle Int Séquentiel
nomSalle Varchar(20) Le nom
capaciteSalle Int La capacité
Utilisateur
idUser Int Séquentiel
loginUser Varchar(50) Le Login
pwUser Varchar(50) Le mot de passe
nomUser Varchar(50) Le nom
prénomUser Varchar(50) Le prénom
typeUser Enum Administrateur
Wilaya idWil Int Le code de la wilaya
nomWil Varchar(100) Le nom
Surveillant
idSurv Int Séquentiel
nomSurv Varchar(50) Le nom
prenomSurv Varchar(50) Le prénom
Promoteur idProm Int Séquentiel
gradeProm Enum VAC, MAB, MAA, MCB,
ESI 2009/2010 CONCEPTION
104
MCA, PR
isExterne Booléen Si le promoteur est externe.
nomProm Varchar(50) Le nom
prénomProm Varchar(50) Le prénom
Séance
idSnc Char(3) Code de la séance ex. : SA1,
SA2, DI1,…
heureDebutSnc Heure L’heure début
Durée Int La durée de la séance
Absence
idAbs Int Séquentiel
dateAbs Date La date
etatAbs Enum Justifié, non justifié
Sanction idSanc Int Séquentiel
descSanc Text La description
Projet
idPrj Int Séquentiel
intituléPrj Varchar(100) L’intitulé du projet
résumePrj Text Le résumé
probPrj Text Les problématiques
objPrj Text Les objectifs
etatPrj Enum Nouveau, En cours, fini
typePrj Enum
Mémoire magister, thèse
doctorat, mini projet, projet
de recherche
Soutenance
idSout Int Séquentiel
datePrévueSout Date La date prévue
dateEffectSout Date La date effective
noteSout Float La note de soutenance
décisionSout Enum Passable, assez-bien, bien,…
Laboratoire
idLab Int Séquentiel
nomLab Varchar(200) Le nom
abrvLab Varchar(7) L’abréviation du laboratoire
Rapport
avancement
idRpt Int Séquentiel
dateDepot Date Date dépôt
descRpt Text Description d’état
d’avancement
Tableau 17 : Les classes d'objet
ESI 2009/2010 CONCEPTION
105
IV.3.3. Implémentation des classes d’association :
Classe Attributs Type (taille) Description
Affectation
Candidat (idCnd, idOpt,
idSalle) (int, int, int)
Affecter ce candidat pour cette
option dans cette salle
Avoir Privilège (idTypeUser,
idPriv) (int, int)
Attribuer ce privilège à ce type
d’utilisateur
Concours
contient option
(idCcr, idOpt) (int, int) Cette option est incluse dans ce
concours
dateEpreuves Date La date des épreuves
placeDispo Int Le nombre de place disponibles
placeEnAttente Int Le nombre de place dans la liste
d’attente
Candidat état
option
(idCnd, idOpt) (int, int) Ce candidat participe dans cette
option
isExclu Booléen L’état du candidat
décisionDélib Enum Admis, en attente, non admis
Note candidat
(idOpt, idMod,
idCnd) (int, int, int)
Ce candidat à l’état pour ce
module de cette option
isExaminé Booléen Est-ce que le candidat passer
cette épreuve
noteMod Float La note
Option contient
module
(idCcr, idOpt,
idMod) (int, int, int)
Ce module est inclus dans cette
option pour ce concours
coefMod Float Le coefficient
dateMod Date La date
heureDebutMod Heure L’heure début
dureeMod Int Nombre de minute
Ouvrir option (idAun, idOpt) (int, int) Cette année universitaire, on
ouvre cette option
Passer épreuve
(IdCnd, idEpr,
idSal) (int, int, int)
Un candidat passer une épreuve
à une salle
noteEpr Float La note obtenue dans l’épreuve
Etat Avancement
(idMem,
etatMem) (int, int) L’état d’un mémoire
etatAvanc Text Etat avancement
Promouvoir
Grade
(idEns,
codeGra, date)
(int, Varchar,
date) L’enseignant obtient un grade
decPromoGra Text La décision
etatPromoGra Varchar L’état de la promotion
Tableau 18 : Les classes d'association
ESI 2009/2010 CONCEPTION
106
IV.3.4. Passage du modèle objet au modèle relationnel :
L’utilisation d’un SGPDR impose un changement de représentation entre la structure des
classes et la structure des données relationnelles. Les deux structures ayant des analogies, les
équivalences exprimées au tableau suivant sont utilisés pour en réaliser le rapprochement.
Une classe défini une structure de données à laquelle souscrivent les instances ; elle
correspond donc à une table du modèle relationnel : chaque attribut donne lieu à une colonne,
chaque instance stocke ses données dans une ligne (T-uplet) et son OID sert de clé primaire.
Certains attributs de type complexe ne correspondent a aucun des type de SQL, on rencontre
fréquemment ce cas pour les attributs représentant une structure de données. Un type
complexe peut être conçu :
Soit avec plusieurs colonnes, chacune correspondant à un champ de la structure
Soit avec une table spécifique dotée d’une clé étrangère pour relier les insistances aux valeurs
de leur attribut complexe.
Modèle objet Modèle relationnel
Classe Table
Attribut de type simple Colonne
Attribut de type complexe Colonne ou clé étrangère
Instance T-uplet
OID Clé primaire
Association Clé étrangère ou table de lien
Héritage Clé identique sur plusieurs tables
Tableau 19 : Equivalences entre les concepts objets et relationnels
ESI 2009/2010 CONCEPTION
107
IV.3.5. Implémentation des classes de contrôle :
Tableau 20 : Implémentation des contrôles
On peut décrire les classes FieldControlClass et ProfileControlClass de la façon suivante :
FieldControlClass : Elle assure le contrôle des champs de tous les formats
alphabétiqueset/ou numériques, les dates, …etc. ; assurant par l’occasion la validité des
informations (sur le plan type de données) et permet d’éviter les erreurs commises lors de la
saisie (par inadvertance par exemple).
ProfileControlClass : Elle permet de suivre et de contrôler les opérations et tâches
accomplies par les utilisateurs, leur limitant l’accès à ce qui leur est permit selon leurs profils.
Sous système Module Classe de contrôle
Ressources
du système Gestion des ressources ResCC
Sécurité
Gestion de la
base de
données
DbMCC
Administration
du système
UserMCC, ProfileCC
Gestion des TraceCC
ESI 2009/2010 CONCEPTION
108
Tableau 21 : Liste des classes de contrôle
IV.3.6. Implémentation des classes de dialogue (IHM) :
Pour compléter la définition du système, nous allons énumérer les interfaces des composants
en vue de donner une description sommaire de ce que réalise le composant dans le système.
Le tableau suivant illustre une première définition des interfaces des composants recenses (par
convention, tour les noms des interfaces sont précèdes d'un I, comme suggère dans [UML en
action, page 239]):
Application Interface (formulaire
web) Description des responsabilités
Concours
Définition du concours
Permet de créer un nouveau concours,
les épreuves à passer, les spécialités et
les modules à ouvrir et en spécifiant les
places disponibles dans chaque
spécialité.
Editeur des épreuves
Gérer les épreuves : créer, modifier,
rechercher...
Inscription en ligne
Permet au candidat d’inscrire en ligne
en saisissant un formulaire de
renseignement.
Gestion des candidats
Permet de rechercher, ajouter, modifier,
supprimer des candidats au concours,
valider l’inscription en ligne.
Listes des admis et listes
d'attente par spécialité
Visualiser, imprimer les listes des admis
et les listes d'attente par spécialité.
traces.
Activités
pédagogique
s
Gestion de l'assiduité. AssSncCC
Inscription et réinscription des
étudiants et candidat. InscrCC
Gestion des notes NoteCC
Gestion des délibérations (passage) DelibCC
Plannings
Gestion emploi du temps. ETempsCC
Gestion des plannings de concours et
des examens PlanningCC
Gestion des plannings de soutenances PlanningCC
Statistiques
et rapports
Elaboration des statistiques et des
rapports StatRptCC
Activités
scientifiques
Gérer les séjours scientifiques SejourScCC
Gérer les stages de courte durée ScdCC
Projets de
recherche Gérer les projets de recherche PRechCC
ESI 2009/2010 CONCEPTION
109
Inscription
Inscription des étudiants Inscrire, rechercher, saisir, modifier,
annuler, valider.
Editer les documents
Permet d'imprimer des documents
(certificat de scolarité, carte d'étudiant,
bulletin de notes,…)
Assiduité
Gestion des absences Enregistrer les absences, les
justifications.
Gestion des sanctions Enregistrer les sanctions, les motifs,
modifier, supprimer, valider.
Planification
Emplois du temps Créer, modifier un emploi du temps.
Planning des examens Créer, modifier les plannings des
examens.
Organisation des
épreuves
Créer, modifier le planning des
épreuves du concours.
Planning des soutenances Créer, modifier le planning des
soutenances.
Mise en ligne des
plannings
Interface dédiée à la consultation
distante des utilisateurs.
Enseignement
Gestion des années post
graduation
Ajouter, modifier, supprimer.
Gestion des années
magisters
Gestion des modules
Gestion des
établissements
Gestion des enseignants
chercheurs
Gestion des salles
Gestion des
notes
Saisie des notes Saisie, calcul des moyennes, annulation,
validation.
Mise en ligne des notes Interface qui permet aux étudiants de
consulter leurs notes en ligne.
Mémoires
Enregistrer les sujets de
mémoire
Créer un nouveau, modifier, supprimer,
valider.
Gestion de l'état
d'avancement des
mémoires
Créer, modifier, supprimer, valider.
Constituer les jurys Création, modification et affectation des
jurys.
Enregistrer les résultats
des soutenances Saisie des résultats des soutenances.
Projet de
recherche
Gérer les projets de
recherche
Créer un nouveau, modifier, supprimer,
valider.
Gérer les équipes des
projets Rechercher, créer, modifier, supprimer.
Gérer les laboratoires de
recherche Rechercher, créer, modifier, supprimer.
Suivi de l'avancement Saisie des états d'avancement,
ESI 2009/2010 CONCEPTION
110
des projets impression...
Gestion des
activités
scientifiques
Définition d’une activité
Permet de créer une nouvelle activité
scientifique, en fournissant le type, la
durée, le concerné, les frais,…
Suivi d’activité
Permet de changer l’état de l’activité
(en cas d’annulation ou retour du
concerné).
Impression du tableau
des frais
Permet d’imprimer le tableau des frais
pour être validé par le CS, DG, DPGR
Les
documents
administratifs
Edition des documents
administratifs
Edition des certificats de scolarité,
cartes des étudiants, les procès
verbaux...
Statistiques Elaboration des
statistiques
Edition et impression des statistiques
selon plusieurs critères.
Tableau 22 : Conception des interfaces utilisateur
ESI 2009/2010 CONCEPTION
111
IV.3.7. Codification :
Code de l’année universitaire :
A : Année
B : Année
Ex. : 2009/2010
Code de l’étudiant :
A : Année d’entrée
B : Code de l’option
C : Numéro séquentiel
Ex. : 09IRM06
Code de séance :
A : Le jour (SA : Samedi, DI : Dimanche, ...etc.)
B : Numéro séquentiel
Ex. : SA1, SA2, DI6
Remarque : Pour le reste des objets de la base de données le code proposé est un code
séquentiel.
ESI 2009/2010 CONCEPTION
112
IV.4. Conclusion :
Dans cette partie on a pu avoir une idée globale sur l’implémentation du
système (Architecture physique et logique), avec une vision un peu plus détaillée de la
solution dans son côté application (différentes classes de dialogue, de contrôle et de
persistance et aussi IHM) et de son côté base de données (modèle relationnel, architecture
logique, …etc.).
Cela permet de cerner la solution proposée et mieux comprendre le fonctionnement
du système et ses différentes fonctionnalités, mais surtout permet de préparer la phase de
réalisation qui concrétisera tout ce qui a été présenté jusque là.
IMPLEMENTATION
ESI 2009/2010 IMPLEMENTATION
114
V. IMPLEMENTATION :
V.1. Introduction :
La réalisation vient couronner les phases précédentes, donnant un aspect tangible aux
suggestions présentées lors de l’étude de l’existant et une forme concrète à la conception.
Afin de présenter le prototype réalisé, on utilise des prises d’écrans (Imp. Ecr.)
pour figurer le travail fait et d’illustrer les grandes et principales fonctionnalités du système.
Cela est fait suivant l’architecture logique du système (répartition en sous-systèmes et
modules).
La sécurité elle, aborde la finalisation de l’étude qui est la sécurisation du système et le
recensement des différents risques potentiels et les précautions à suivre.
ESI 2009/2010 IMPLEMENTATION
115
V.2. Le diagramme de déploiement :
Les modèles de déploiement et de configuration matérielle s’expriment tous deux à l’aide
d’un diagramme de déploiement.
Le modèle de configuration matérielle a pour but d’exprimer les contraintes de mise en
œuvre au niveau physique. On y trouve les nœuds et les connexions physiques du système,
qui sont les différents types de machine connectés par des moyens divers. Le modèle de
configuration matérielle permet de spécifier, de documenter et de justifier tous les choix
d’organisation physique en fonction des machines dédies aux diverses fonctions techniques du
système.
Le modèle de déploiement considère plutôt chaque nœud comme une poste de travail. Il
exprime la répartition physique des fonctions métier du système et permet de justifier la
localisation de la base de données et des environnements du travail. Le modèle de
déploiement aide à préciser la qualification des postes client, des réseaux et de leur sécurité
physique, par rapport à des critères fonctionnels [ROQ, VAL, 2002].
Figure 53 : Le diagramme de déploiement.
ESI 2009/2010 IMPLEMENTATION
116
V.3. Outils de développement :
Présentation de la plateforme.Net :
.Net est la plateforme XML qui facilite le développement, l’utilisation, le déploiement, la
sécurisation et la gestion des services web XML. Il intègre nativement les standards des
services web (XML, SOAP, WSDL, UDDI) La plateforme .Net a pour but de proposer un
environnement d’exécution sécurisé et une plateforme de développement simplifiée,
cohérente et unifiée. Cette plate-forme est spécialement conçue dans l’objectif du
développement de produits et services web. Elle s’adresse aux systèmes distribués utilisant
XML et d’autres standards (XSD, SOAP, WSDL, HTTP …) en tant que plate forme
d’intégration, de développement et de déploiement. Un des aspects les plus intéressants de
.NET se situe au niveau de la plateforme de développement, des langages et des protocoles
qu’elle met en avant, permettant de développer simplement des applications Web
interopérables, reposant sur une architecture totalement nouvelle. Plusieurs raisons pour
lesquels nous avons choisi la plateforme .Net pour le développement de notre application :
Microsoft propose une vision très simplifiée des services Web pour le développeur. En .Net, il n’existe
qu’un seul environnement d’exécution à savoir le couple IIS / ASP.Net.
Microsoft une solution complète pour le développement de web services (tous les standards sont
intégrés dans la plateforme)
Présentation de Visual Studio :
Visual Studio .NET ne fait pas partie du Framework .NET. Il
s'agit tout simplement d'un environnement de développement
intégré proposé par Microsoft pour développer des applications
conformes aux spécifications de .NET (Web et Windows).
Langage de programmation : ASP .NET, C#:
ASP.NET est un ensemble de technologies de programmation web créé par
Microsoft. Les programmeurs peuvent utiliser ASP.NET pour créer des
sites web dynamiques, des applications web ou des web services XML. La technologie est
accessible grâce à l'installation d'un serveur web compatible ASP (IIS) ou à l'intérieur de
Visual Web Developer Express Edition.
ASP.NET fait partie de la plateforme Microsoft .NET et est le successeur de la technologie
Active Server Pages (ASP).
ASP.NET permet aux développeurs de passer plus facilement du développement classique
d'applications Windows au développement d'applications Web en offrant la possibilité de
créer des pages web composées de Widget (ou zone de contrôle) similaires à celles des
interfaces d'applications Windows habituelles.
ESI 2009/2010 IMPLEMENTATION
117
Le C# est un langage de programmation orienté objet à typage fort, créé par la
société Microsoft, et notamment un de ses employés, Anders Hejlsberg, le
créateur du langage Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage
permettant d'utiliser toutes ses capacités. Il est très proche du Java dont il reprend la syntaxe
générale ainsi que les concepts (la syntaxe reste cependant relativement semblable à celles de
langages tels que le C++ et le C). Un ajout notable à Java est la possibilité de surcharge des
opérateurs, inspirée du C++. Toutefois, l'implémentation de la redéfinition est plus proche de
celle du Pascal Objet.
Générateur des rapports (Crystal Reports):
Crystal Reports est un progiciel d'informatique décisionnelle qui permet de générer
une grande variété de rapports à partir de données informatiques.
Il permet de créer les connexions aux données sources et la génération de présentations
graphiques à des fins de reporting.
Table de donnés (GridView) :
On a utilisé des tables qui fonctionnent avec la méthode AJAX, l'avantage de cette méthode
est essentiellement la vitesse à laquelle une application AJAX répond aux actions de
l'utilisateur, qui sont traitées (en partie au moins) localement par le navigateur. [OBOUT
2010]
ESI 2009/2010 IMPLEMENTATION
118
V.4. Présentation du prototype réalisé (Imp. écr.) :
Page d’accueil :
Figure 54 : Page d'accueil
Page d’authentification :
Figure 55 : Page d'authentification
ESI 2009/2010 IMPLEMENTATION
119
Formulaire des options :
Figure 56 : Formulaire des options
Formulaire de modules de concours par option :
Figure 57 : Formulaire de modules de concours par option
ESI 2009/2010 IMPLEMENTATION
120
Formulaire d’inscription en ligne des candidats au concours:
Figure 58 : Formulaire d’inscription en ligne des candidats au concours
ESI 2009/2010 IMPLEMENTATION
121
Formulaire d’inscription et validation d’inscription des candidats :
Figure 59 : Formulaire d’inscription et validation d’inscription des candidats
Formulaire de saisie des notes pour le concours:
Figure 60 : Formulaire de saisie des notes pour le concours
ESI 2009/2010 IMPLEMENTATION
122
Formulaire de délibération de concours :
Figure 61 : Formulaire de délibération de concours
Formulaire d’intégration des nouveaux étudiants :
Figure 62 : Formulaire d’intégration des nouveaux étudiants
ESI 2009/2010 IMPLEMENTATION
123
Pour modifier les informations d’un étudiant, il suffit de cliquer sur le bouton
« modifier », le système affiche le formulaire suivant :
Figure 63 : Modification des informations d'un étudiant
Formulaire des projets de recherche :
Figure 64 : Formulaire des projets de recherche
ESI 2009/2010 IMPLEMENTATION
124
Formulaire de suivi des projets de recherche :
Figure 65 : Formulaire de suivi des projets de recherche
ESI 2009/2010 IMPLEMENTATION
125
V.5. Sécurité du système :
La télécommunication est un domaine qui utilise des moyens technologiques avancés assurant
une disponibilité quasi-permanente, ce qui intensifie la vulnérabilité de n’importe quel
système d’information en relation avec, et là, ce dernier se voie face à différents risques qui
peuvent lui porter atteintes et diverses menaces qui peuvent nuire à son bon
fonctionnement et aux intérêts de ses utilisateurs, surtout dans le cas où ce système traite des
informations de la plus grande importance et la plus majeure sensibilité.
A l’instar de tout système baignant dans ces conditions, notre système est dans l’obligation
de prendre des précautions et des mesures qui le permettront de faire face à toutes ses
menaces et surtout de protéger les informations qu’il traite et la confidentialité qui découle de
leurs natures sensible, étant des informations portant sur la vie privée des enseignants et
étudiants de l’ESI (DPGR).
Notamment ses mesures seront prises selon le besoin qui se présente que ce soit au sein du
système lui-même, concernant le matériel utilisé pour son implémentation, avec ceux qui
auront accès à ses fonctionnalités et de même pour l’environnement qui en sera le
réceptacle.
Pour assurer ces tâches indispensables en matière de sécurité, on a besoin de dénombrer ces
risques et de les classifier pour tracer un plan pour les changements à faire, les solutions à
préconiser et les dispositifs à mettre en œuvre.
V.5.1. Vue générale sur le système à sécuriser :
Pour bien cerner la situation et bien comprendre ce qu’impose la nature du système et
qu’exigent les données traitées par ce dernier, en terme de protection et sécurité, donner un
aperçu de lui est de la plus grande utilité. Cet aperçu est simplement un résumé
récapitulant les aspects essentiels du système et qui, spécialement, doivent être pris en
considération dans cette partie.
Un système disponible par internet, installées sur un serveur d’application et utilisées par
des utilisateurs de l’ESI et de la DPGR après authentification et par des internautes
(inscription au concours en ligne) sans authentification.
Des informations (sensibles) concernant les étudiant, les enseignants, leurs cursus, leurs
projets, ainsi que concernant les utilisateurs en relation avec le système et leurs comptes,
hébergées dans une bases de données implémentées sur un serveur de base de données au
niveau de la DPGR et disponibles aux interrogations faites à la demande des utilisateurs
connectés par internet (par le biais de l’application).
ESI 2009/2010 IMPLEMENTATION
126
V.5.2. Facteurs de risque et mesures de sécurité :
On peut classer les différents facteurs de risque qui représente un danger pour notre
système en trois principales catégories.
Les accidents :
Ce sont les risques qui ne peuvent être totalement prédis et qui résultent des facteurs
d’environnement du système au sein de la direction et se présentant hors son
utilisation causant des dommages physiques et/ou logiques :
Les catastrophes naturelles (séisme, incendies, inondations, …etc.)susceptibles de
toucher les lieux d’installation des serveurs (d’application et de données).
Défaillance des installations (câblage, matériel, … etc.) pouvant être causée par les
facteurs naturels tels la pluie ou le soleil (oxydation, brûlure, radiations, …etc.)
ou humains (arrachage, endommagement non intentionnel, …etc.).
Pannes d’électricité (pendant un long moment), surtout dans le cas de défaillance ou
même arrêt complet des générateurs et groupes électrogènes.
Problème de disponibilité d’internet, surtout quand il s’agit de panne qui dépasse les
limites d’interventions et d’actions de la DPGR (au niveau des câbles
internationaux par exemple).
Les mesures à prendre se résument à quelques dispositifs de prévision pour protéger le
système de ces accidents et de réduire, le plus possible, leurs dommages potentiels :
Installer les serveurs d’application et de données dans des bâtisses construites selon les
normes mondiales anti-séisme.
Des bâtisses dotées de systèmes anti-incendie (alarmes, détecteurs de flammes
et dispositifs d’extinction automatiques et manuels à la fois).
Dotées de systèmes d’évacuation de l’eau et étanchéité (surtout pour les salles des
serveurs) contre les inondations.
Définir une politique de sauvegarde d’urgence (environnement logiciel et interne du
système et des bases de données) se déclenchant automatiquement en cas de
catastrophe.
Définir une conduite à tenir pour le personnel pour éviter les accidents, et en ce qui
concerne les étapes d’intervention pour la protection des installations en cas de
catastrophe pour assurer rapidité, calme et efficacité.
Louer les services de spécialistes en la sécurité des installations (entreprises
spécialisées, experts, conseillers, …etc.)qui peuvent préconiser et/ou effectuer la
mise en place de ses dispositifs.
ESI 2009/2010 IMPLEMENTATION
127
Les erreurs :
Ce sont des risques qui peuvent survenir lors de l’utilisation du système. Généralement
émanant des utilisateurs mêmes, elles causent essentiellement des dommages touchant
l’intégrité des données et leur exactitude. Mais notamment, elles peuvent résulter des
opérations faites pendant les interactions entre les différents sous-systèmes :
Erreurs de saisie commises par les utilisateurs (lors de la création d’un compte
utilisateur, inscription des candidats, …etc.) et faites par manque d’attention ou
causées par des problèmes d’ergonomie, de fatigue des agents, d’incommodité des
conditions de travail, …etc.
Erreurs de manipulation et d’exploitation par les utilisateurs comme dans
l’accomplissement de tâches inappropriées (suivi d’un projet de recherche,
élaboration des statistique, …etc.) celles là pouvant être causées par
l‘incompréhension des notions et règles en vigueur ou manque de maîtrise du système.
Erreurs se produisant en dehors de l’utilisation du système par les utilisateurs mais
plutôt engendrer par l’interaction des sous-systèmes (gestion des concours, gestion
de la scolarité, …etc.).
Afin d’éviter ce genre d’erreurs et fautes, et après prise en compte de leurs causes, on peut
adopter les recommandations suivantes :
Entamer une période d’essai ou une sorte de mise à l’épreuve avant la mise en
service qui permettra d’évaluer le système et sa stabilité et aussi de voir et détecter
d’éventuelles défaillances ou anomalies.
Améliorer l’ergonomie et assurer la continuité de son évolution pour toujours fournir
aux utilisateurs un système qui peut être considérer comme facile à exploiter.
Suivie permanent des connexions et de la bonne marche des transmissions
nécessaires pour le fonctionnement du système.
Pourvoir les utilisateurs de manuels d’aide et de support disponibles constamment
pour les accompagner durant leur exploitation du système (des explications
d’opérations transcrites, des pages interactives ou même des vidéos et tutoriaux).
Suivie des opérations exécutées (par les utilisateurs) par des superviseurs (en
l’occurrence les chefs et les administrateurs) pour diminuer le nombre d’erreurs
commises par inadvertance ou même par manque de maîtrise.
Politique de sauvegarde quotidienne.
ESI 2009/2010 IMPLEMENTATION
128
Les malveillances :
Ce sont les menaces les plus dangereuses et les plus destructrices (relativement), parce
qu’elles émanent des intentions hostiles de malveillants qui veulent volontairement nuire à la
bonne marche du système, voler ou détruire des informations confidentielles ou même
porter préjudice à la DPGR, on cite les malveillances suivantes :
Fautes dolosives lors de l’utilisation du système afin de compromettre l’intégrité et
l’exactitude des informations traitées (changer le niveau d’un étudiant, créer des
activités scientifiques pour des fins personnelles, …etc.).
Sabotage du matériel et des installations utilisés hébergeant l’application et labase
de données.
Attaques de piraterie et hacking, dirigées vers le système pour introduire des
programmes malicieux et malveillants (Ver, cheval de Troie, virus, …etc.), voler
des données confidentielles ou prendre contrôle du système. Ces attaques sont
beaucoup probables à cause de l’utilisation d’internet principalement et aussi en
raison de l’importance des informations gérées au cours des inscriptions au
concours, des délibérations, …etc. Leurs motifs peuvent être des profits à réaliser ou
même à la recherche de la gloire.
Et pour prévenir de tels actes, les stopper et diminuer les dégâts qu’ils peuvent causer, il faut
s’orienter vers une politique de protection efficace pour le système entier :
Restreindre l’accès aux lieux d’installation des serveurs et celles du matériel
indispensable pour le déroulement des opérations quotidiennes et périodiques et
les doter de protections contre la destruction (des codes d’accès, portes blindées,
vitres armées (Shatterproof), Vidéosurveillance, …etc.).
Restreindre l’accès aux différentes fonctionnalités du système et tracer toutes les
opérations accomplies lors de son utilisation (profils d’accès et système de privilèges,
système de traçabilité, historiques, …etc.).
Munir les serveurs de Firewall et Antivirus professionnels performants.
Suivre l’évolution en termes de sécurité et menaces (études, veille
technologique, …etc.)
ESI 2009/2010 IMPLEMENTATION
129
V.5.3. Qualités sécuritaires du nouveau système :
Le système comprend, pour assurer confidentialité, intégrité et disponibilité, les aspects
suivants pour faire face aux différentes menaces :
Confidentialité :
Etant un aspect capital du système, la confidentialité rassemble toutes les procédures qui
limitent le nombre des personnes pouvant accéder au système :
Sécurité Physique :La DPGR dispose pour sa part d’une panoplie de moyens qui l’aide
à protéger ses installations (salles de serveurs, matériel de connexion, …etc.)et cesmoyens
font la majorité des éléments cités ci-dessus en terme de sécurité physique contre les risque
d’accidents, d’erreur ou même de malveillance.
Sécurité logique : Comme les données traitées lors des inscriptions et délibérations sont de
la plus grande importance (portant principalement sur la vie privée des personnes), elles
exigent un degré élevé de discrétion et de confidentialité.
Restriction des accès : Les accès au système et ses différentes parties sont limités
selon la fonction de l’utilisateur, ce qui est réalisé au moyen d’un système de
gestion de profils. Ces derniers sont assignés à chaque compte utilisateur pour en
déterminer les opérations lui étant permises et les sections lui étant accessibles dans
les applications. Seul un administrateur peut créer, modifier, suspendre un
compte utilisateur et lui affecter le profil approprié. Ainsi, quand l’utilisateur se
connecte au système, il a affaire à un nombre réduit de liens et de pages
correspondant à son profil d’accès.
Profils Modules autorisés Types d’accès
Administrateur
Gestion des utilisateurs Mise à jour
Authentification Consultation
Gestion des traces Mise à jour
Sauvegarde/Restauration de la base de
données Consultation
Enseignant
Saisir les note des épreuves et examens Mise à jour
Consulter ses projets de recherche et activités
scientifiques Consultation
Etudiant Consulter ses notes, mémoire et thèse Consultation
Président du
conseil
scientifique
Délibération 1e année magister Mise à jour
Validation des résultats de concours Mise à jour
Validation des projets de recherche et des
activités scientifiques Mise à jour
Directeur de la
PGR
Gestion de l’année universitaire (création,
initialisation, clôture) Mise à jour
Gestion des concours (création, Mise à jour
ESI 2009/2010 IMPLEMENTATION
130
déclaration,…)
Validation des activités scientifiques Mise à jour
Elaboration des statistiques Consultation
Elaboration des déférents plannings Mise à jour
Responsable de
l’école doctorale
Validation des notes de concours et examen Mise à jour
Suivi des soutenances Mise à jour
Agent
administratif
Impression des déférents documents
administratifs Consultation
Inscription des candidats au concours et des
étudiants Mise à jour
Gestion des assiduités et sanctions Mise à jour
Candidat
Consultation de l’actualité (les derniers
messages publiés par la DPGR) Consultation
Inscription en ligne au concours Mise à jour
Tableau 23 : Liste des modules autorisés avec type d’accès par profil
Sécurité des données : En combinant les dispositifs pour la protection des données
déjà en vigueur au sein de la DPGR et ceux proposés avec notre système on a la
liste suivante :
Politique de sauvegarde assurant la sûreté des données en effectuant une copie des
bases de données sur des cartouches (sorte de disque de sauvegarde) avec une
capacité qui dépasse les cinq cents Giga-octets (500 GO) par équipement de
gravure (appelé en l’occurrence le robot qui est une sorte de station de gravure)
cela de façon quotidienne.
Cryptage des données transmises sur internet entre l’application et la base de
données.
Utiliser la forme Captcha pour protéger le système contre
l’inscription en ligne des candidats au concours par des
programmes malicieux (Un captcha est une forme de test de Turing permettant de
différencier de manière automatisée un utilisateur humain d'un ordinateur).
Munir les serveurs de Firewall professionnel tel celui proposé (Microsoft Internet
Security & Acceleration Server 2004).
Sécurité de l’application : Afin de protéger le système on se tient aux indications
suivantes :
Gestion des rôles sur le site WEB (pour accompagner le système de gestion des
profils d’accès) effectuée au niveau de l’ASP.Net ainsi que la fermeture de session
en dépassement de durée de non activité permise.
Contrôle des données et informations introduites au système lors de son
exploitation pour contrer toute tentative de sabotage ou faute dolosive ou non
intensionnelle (formes régulières, injections SQL, …etc.), cela grâce aux
différentes classes de contrôle déjà présentées.
ESI 2009/2010 IMPLEMENTATION
131
Munir les serveurs d’Antivirus professionnel (mis à jour automatiquement
via internet) tel celui proposé (Kaspersky Internet Security).
Intégrité :
Un aspect qui ne manque pas d’importance de la confidentialité, assurant l’exactitude des
informations et donc par la suite des résultats justes, optimaux et lucratifs.
Gestion de la concurrence : Garantie par les différentes classes de persistance et transaction
réalisées et déjà présentées, par l’ASP.Net et C# et SQL Server au niveau de la base de
données.
Redondance justifiée et réfléchie : Les redondances et les répétitions des données ont été
faites en se basant sur les besoins qui se sont présentés afin d’optimiser l’exploitation de ces
données et du système entier à la fois.
Contrôles de champs : Les champs sont contrôlés pour diminuer les fautes commises lors de
la saisie par les utilisateurs.
Disponibilité :
Grâce aux recommandations pour la protection des serveurs et installations en cas
d’incidents de tout genre, données auparavant, en plus des précautions prises pour assurer la
connexion à internet (seul moyen d’exploitation du système) et des autres connexions
nécessaires (entre le serveur d’application et de données par exemple), on peut maintenir une
disponibilité continue et sans interruption du système.
ESI 2009/2010 IMPLEMENTATION
132
V.6. Conclusion :
Penser que la réalisation met fin à l’élaboration d’un bon système d’information, tel le
sujet de cette étude, est une idée complètement fausse. Parce qu’il faut préciser que la
réalisation vient couronner les phases précédentes mais n’est en aucun cas la dernière,
plutôt c’est la transition entre la partie préparation et étude du système, et son exploitation et
utilisation, et comme constaté au cours de l’étude des risques et mesures à prendre et ce qui en
suit du côté du système, c’est confirmé qu’il faut continuer à le suivre et le superviser, en sus
de se tenir aux recommandations et indications qui le protégeront des dangers le
guettant.
Il faut aviser le personnel des politiques suivies, les former et en créer des
sanctions pour punir tout dépassement pour garantir l’efficience de ces mesures prises.
CONCLUSION
GENERALE
ESI 2009/2010 CONCLUSION GENERALE
134
VI. CONCLUSION GÉNÉRALE :
VI.1. Conclusion :
Le travail que nous avons effectué consiste à concevoir et réaliser un site web
dynamique pour la gestion de la DPGR de notre école (ESI).
Nous avons réussi à développer un site web qui couvre pratiquement toute les activités
pédagogiques pertinentes de la DPGR tout en profitant les avantages des TIC. Et pour sa
réalisation nous avons suivi une méthode itérative composée de trois étapes : analyse,
conception et réalisation.
Dans l’analyse nous avons spécifié plusieurs cas d’utilisations, nous avons organisé
ces cas en 4 paquets : Suivi de cours, concours d’entrée à l’école doctorale, suivi des activités
scientifique et projet de recherche, et la gestion électroniques des documents.
Pour la conception nous avons présenté l’étude conceptuelle du futur système en
respectant la modélisation qui a été élaborée dans la partie précédente et ce, pour répondre, au
mieux, aux objectifs qui ont été fixés.
Et en fin dans la réalisation nous avons développé notre système en utilisant :
ASP.NET (pour la construction du site), et SQLSERVER (pour la gestion de la base de
données).
Comme notre système doit fonctionner en réseau local, nous avons choisi une
architecture web pour le développement (architecture trois tiers) qui est la plus appropriée,
cela offre plusieurs avantages : la sécurité des données, la facilité de déploiement, …
Nous avons appris à maitriser le langage de modélisation UML et une méthode de
conception du système d’information très efficace OMT, avec une expérience pratique par la
maitrise de langage ASP.NET, le système de gestion de base de données SQLSERVER et
l’environnement de web (Java Script, html,…).
VI.2. Perspectives :
Il serait intéressant d’enrichir ce travail par :
Intégrer au site un forum pour la communication et le partage de connaissances entre
les post-graduants.
Intégration d’un outil pour que les post-graduants puissent passer les examens en
ligne.
VII. REFERENCES :
VII.1. Bibliographie :
[DEBRAUWER 06] DEBRAUWER L., KARAM N.; UML 2: Entraînez-vous à la
modélisation ; France 2006.
[ROQ, 2002] Pascal Roques, Les cahiers du programmeur UML, modéliser un site e-
Commerce, 2002.
[ROQ, VAL, 2002]Pascal Roques et Franck Vallée, UML en action de l’analyse des besoins
à la conception en Java, 2002.
[RUM, 1997] James RUMBAUGH et al, OMT 1.Modélisation et conception orientées objet,
1997.
[06 34] AMRANI B., ARAOUR M. : Conception et réalisation d’un SI pour le suivi du
système pédagogique de l’INI (Mémoire de fin d’études)
VII.2. Webographie :
[PG 2010] pg.esi.dz (vu en 2010)
[KIS 2010] www.kaspersky.com/fr (vu en mai 2010)
[WIKI 2010] fr.wikipedia.org (vu en mai 2010)
[OBOUT 2010] www.obout.com (vu en juin 2010)
ANNEXE
ESI 2009/2010 ANNEXE
137
VIII. ANNEXE :
VIII.1. Comment calculer les frais de séjours (montant d’allocation) :
A partir du tableau ci-dessous on peut calculer le montant d’allocation pour les activités
scientifiques comme suit :
1. On récupère le montant selon la durée de l’activité et le pays d’accueil.
2. Si l’activité est un stage à l’étranger : une majoration de 20% du montant est effectuée.
3. Si l’activité est une communication : une majoration de 40% du montant est effectuée.
ESI 2009/2010 ANNEXE
138
VIII.2. Captcha:
Un captcha est une forme de test de Turing
permettant de différencier de manière automatisée un
utilisateur humain d'un ordinateur.
Parce que le test est réalisé par un ordinateur, en
opposition avec les tests de Turing standard réalisés par
des humains, un captcha est souvent décrit comme un test
de Turing inversé. Ce terme est néanmoins ambigu parce
qu’il pourrait aussi signifier que les participants essaient de prouver qu'ils sont des
ordinateurs.
Applications :
Ce test est utilisé sur Internet dans les formulaires pour se prémunir contre les soumissions
automatisées et intensives réalisées par des robotsmalveillants.
La vérification utilise la capacité d'analyse d'image ou de son de l'être humain. Un captcha
usuel requiert ainsi que l'utilisateur tape les lettres et les chiffres visibles sur une image
distordue qui apparait à l'écran. Certains sites Web préfèrent afficher une image qui contient
une question mathématique.
Ils sont utilisés :
Contre le spam :
Lors de l'inscription à des webmails gratuits (dont les comptes pourraient être utilisés
par la suite pour l'envoi de courriers non sollicités),
Lors de la soumission de messages dans des forums de discussion et des blogs (qui
pourraient permettre de faire du spamdexing), etc. ;
Contre l'extraction automatisée de bases de données ;
Contre les tentatives d'attaque par force brute ;
Pour la participation à des sondages (dont les résultats pourraient être faussés par des
votes automatisés).
À propos du nom :
« Captcha » est un rétro-acronyme : le mot se prononce comme capture en anglais américain
et est censé être composé des initiales de Completely Automated Public Turing test to Tell
Computers and Humans Apart, soit en français, « test public de Turing complètement
automatique ayant pour but de différencier les humains des ordinateurs ». Ce terme, qui est
une marque déposée par l'université Carnegie Mellon, a été inventé en 2000 par Luis von
Ahn, Manuel Blum et Nicholas J. Hopper de cette université, et par John Langford d'IBM. Le
Ce captcha de « smwm » rend
difficile son interprétation par
un ordinateur en modifiant la
forme des lettres et en ajoutant
un dégradé de couleur en fond.
ESI 2009/2010 ANNEXE
139
nom "captcha" peut également être interprété comme "capture character" (capture de
caractères).
Histoire :
Dès le début d'Internet, les utilisateurs ont toujours voulu rendre le texte illisible par les
ordinateurs. Les premiers furent les hackers, postant sur des sujets sensibles dans des forums
en ligne, qui étaient automatiquement surveillés avec des mots-clefs. Pour contourner ces
filtres, ces hackers ont commencé à remplacer les mots par des caractères visuellement
ressemblants. Par exemple, HELLO pouvait être remplacé par |-|3|_|_() ou )-(3££0, ainsi
qu'une multitude d'autres variantes numériques. Ainsi les filtres à mots-clefs ne pouvaient pas
tous les détecter. Ce procédé fut plus tard connu sous le nom de « 13375p34k » (leetspeak).
La première réflexion sur la création de tests automatiques qui pourraient distinguer les
humains des ordinateurs dans le but de contrôler l'accès aux services web est apparue dans un
manuscrit de Moni Naor de l'institut de science de Weizmann, daté de 1996, et intitulé
Verification of a human in the loop, or Identification via the Turing Test. Des captcha
primitifs semblent avoir été développés plus tard, en 1997 chez AltaVista par Andrei Broder
et ses collègues dans le but d'empêcher des robots d'ajouter des sites à leur moteur de
recherche.
En recherchant un moyen de rendre leurs images résistantes à des attaques de logiciels de
reconnaissance de caractères, l'équipe a cherché dans le manuel de leur numériseur de marque
Brother, qui donnait des recommandations pour améliorer les performances de la
reconnaissance de caractères (types d'écritures similaires, fond homogène…). L'équipe conçut
des puzzles en essayant de simuler ce qui pourrait causer une mauvaise reconnaissance
automatique de caractères. En 2000, von Ahn et Blum développèrent et publièrent la notion
de captcha, qui comprenait tout programme qui pouvait différencier un humain d'un
ordinateur. Ils inventèrent de multiples exemples de captcha, dont les premiers qui furent
largement utilisés (par Yahoo! notamment).
Caractéristiques :
Les captcha sont, par définition, entièrement automatisés, ne nécessitant qu'une petite
intervention humaine lors de l'utilisation du test. Ceci présente donc des bénéfices au niveau
des coûts et des performances.
L'algorithme utilisé pour créer un captcha est souvent public, bien qu'il puisse être breveté.
Ceci est fait dans le but de démontrer que casser ce type de test nécessite la résolution d'un
problème difficile en faisant appel à des notions de l'intelligence artificielle, plutôt que la
découverte des secrets de l'algorithme, qui pourraient être obtenus par décompilation ou un
autre moyen.
ESI 2009/2010 ANNEXE
140
Complexité :
La complexité de certains types de ce système contribue à pénaliser l'expérience des
internautes contraints d'essayer plusieurs fois des combinaisons possibles. En effet, certains
captcha sont tellement déformés pour éviter une reconnaissance automatique que même les
internautes ne peuvent les reconnaître. Pire, certain captchas sont plus facilement reconnus
par les ordinateurs.
De plus, leur efficacité est contestée, et des captchas peuvent être reconnus en quelques
secondes.
Accessibilité :
Les tests de captcha basés sur une lecture de texte - ou toute autre tâche de perception visuelle
- rendent impossible l'accès aux ressources protégées pour des personnes déficientes visuelles.
Néanmoins, le captcha n'a pas forcément besoin d'être visuel. N'importe quel problème
d'intelligence artificielle, comme la reconnaissance vocale, peut être utilisé comme base pour
un test de captcha. Certaines implémentations de captcha permettent aux utilisateurs d'opter
pour un captcha audio.
Le développement des captcha audio semble être en retard par rapport aux tests visuels.
D'autres types de tests, comme ceux qui nécessitent une compréhension de texte (par
exemple, un puzzle logique, des questions ou des instructions pour créer un mot de passe)
peuvent aussi constituer des méthodes utilisables dans le cadre d'un captcha. Encore une fois,
il n'y a que peu d'études concernant leur résistance face aux contre-mesures.
Quelques tests intéressants apparurent avec l'idée de la reconnaissance d'images. KittenAuth
est un test de ce type, qui demande à l'utilisateur de reconnaître un animal (des chatons) dans
une série de photographies de différentes espèces (dauphins, chiots, renards, etc.)
Pour les personnes déficientes visuelles (comme les utilisateurs aveugles ou ayant des
difficultés à la perception des couleurs), les captcha visuels présentent de sérieuses difficultés.
Du fait que les captcha sont conçus pour ne pas être lus par les machines, les outils courants
d'aide comme les lecteurs d'écran ne peuvent pas les interpréter. Du fait que certains sites
peuvent utiliser les tests de captcha dès le processus d'inscription initial, ou même à chaque
connexion, ces derniers peuvent complètement bloquer l'accès. Dans certaines juridictions, les
propriétaires de sites peuvent devenir la cible de litiges s'ils utilisent des captcha qui
discriminent les gens ayant certains handicaps. Dans d'autres cas, ceux qui ont des difficultés
visuelles peuvent choisir d'identifier un mot qui leur est lu.
Bien que fournir un captcha audio permette aux utilisateurs aveugles de lire le texte, ce
procédé exclut toujours les personnes souffrant à la fois d’un déficit visuel et auditif.
ESI 2009/2010 ANNEXE
141
L'utilisation d'un captcha empêche ainsi un grand nombre d'individus d'utiliser tous les
services basés sur Internet comme PayPal, Gmail, Orkut, Yahoo!, ainsi que de nombreux
forums et blogs.
Même pour des personnes parfaitement voyantes, les nouvelles générations de captcha,
conçues pour résister aux logiciels sophistiqués de reconnaissance, peuvent devenir
pratiquement impossibles à lire.
Un rapport du W3C a souligné l'inaccessibilité de certains tests visuels anti-robots.
Contournement :
Il y a plusieurs approches pour mettre en échec un captcha :
Utiliser une main-d’œuvre humaine pour les reconnaître ;
Exploiter les bogues dans les implémentations qui permettent à l'attaquant de passer
complètement outre le captcha ;
Améliorer les logiciels de reconnaissance de caractères.
Main-d’œuvre humaine :
Il est possible de passer au travers du test de captcha en utilisant des opérateurs humains
employés à décoder les captcha. Une publication du W3C indique qu'un tel opérateur
« pourrait aisément vérifier des centaines de captcha par heure ». Des entreprises de services
indiennes sont spécialisées dans ce négoce. Des spammeurs ont réussi à contourner la
difficulté en créant des sites internet qui demandent à ce que l'utilisateur passe un test de
captcha pour y accéder, ce test étant en fait celui requis par un autre site, tel celui de Yahoo
pour valider la création d'une nouvelle adresse électronique. L'utilisateur du premier site
contribue ainsi, à son insu, aux actes malveillants de ces derniers. Une contre-mesure existe :
ajouter, dans le captcha, une expression identifiant clairement son émetteur (telle que
« yahoo.fr »).
Bogues de conception :
Certains systèmes de protection par captcha mal conçus peuvent parfois être forcés sans
utiliser de logiciels de reconnaissance de caractères, mais simplement en réutilisant l'ID d'une
session d'une image connue de captcha. Parfois, si une partie du logiciel qui génère le captcha
est située côté client (la validation est faite sur un serveur, mais le texte que l'utilisateur doit
saisir pour s'identifier est généré côté client), alors les utilisateurs peuvent modifier le logiciel
client pour afficher le texte de captcha non déformé par exemple.
ESI 2009/2010 ANNEXE
142
Reconnaissance automatique de caractères :
Bien que les captcha fussent initialement conçus pour contrer les logiciels de reconnaissance
de caractères standards utilisés pour la numérisation par balayage de documents, plusieurs
projets de recherche ont prouvé qu'il est possible de décrypter un grand nombre de captcha
avec des programmes spécifiquement adaptés à un type de captcha. Pour des captcha avec des
lettres déformées, l'approche adaptée est constituée d'une manière générale par les étapes
suivantes :
Suppression du fond de l'image, par exemple avec des filtres de couleurs et la
détection de lignes fines ;
Segmentation, c'est-à-dire découpe de l'image en plusieurs segments contenant une
seule lettre ;
Identification de la lettre contenue dans chaque segment.
Le reCAPTCHA propose une approche semblable. [WIKI 2010]
VIII.3. Ajax :
Ajax est un acronyme pour Asynchronous JavaScript and XML (« XML et Javascript
asynchrones ») et désignant une solution informatique libre pour le développement de pages
dynamiques et d'applications Web.
À l'image de DHTML ou de LAMP, AJAX n'est pas une technologie en elle-même, mais un
terme qui évoque l'utilisation conjointe d'un ensemble de technologies libres couramment
utilisées sur le Web :
HTML (ou XHTML) pour la structure sémantique des informations ;
CSS pour la présentation des informations ;
DOM et JavaScript pour afficher et interagir dynamiquement avec l'information
présentée ;
L'objet XMLHttpRequest pour échanger et manipuler les données de manière
asynchrone avec le serveur Web.
XML pour remplacer le format des données informatives (JSON) et visuelles
(HTML).
En alternative au format XML, les applications Ajax peuvent utiliser les fichiers texte ou
JSON.
Les applications Ajax peuvent être utilisées au sein des navigateurs Web qui supportent les
technologies décrites précédemment. Parmi eux, on trouve Mozilla Firefox, Internet Explorer,
Konqueror, Google Chrome, Safari et Opera.
ESI 2009/2010 ANNEXE
143
Histoire :
Le terme Ajax a été introduit par Jesse James Garrett (informaticien étasunien), le 18 février
2005, dans un article sur le site Web Adaptive Path. Depuis, il a rapidement gagné en
popularité.
Les éléments qui composent Ajax (Javascript, DOM, XML…) et leur utilisation pour générer
des interactions asynchrones sont de loin antérieurs à l'apparition du terme.
En 2001, l'objet XMLHttp, apparu avec la bibliothèque MSXML, point de départ de cette
technique, fut développé à l'origine par Microsoft pour Internet Explorer 5 en tant qu'objet
ActiveX, puis intégré en tant qu'objet navigateur natif nommé XMLHttpRequest par Mozilla,
ce qui permit aux autres navigateurs de l'intégrer car ActiveX n'est utilisé que par Internet
Explorer.
Comparaison avec les applications Web traditionnelles :
Les applications Web traditionnelles permettent aux utilisateurs d'effectuer des choix (suivre
un lien, remplir et valider un formulaire). Une requête est alors envoyée au serveur HTTP, qui
agit en fonction de l'action et des données reçues, et renvoie une nouvelle page (dans le jargon
du Web, ces requêtes sont dites « synchrones »). Ce fonctionnement consomme inutilement
une partie de la bande passante, une grande partie du code (X)HTML étant commune aux
différentes pages de l'application. Et parce qu'une requête au serveur HTTP doit être réalisée à
chaque interaction avec l'application, le temps de réponse de l'application dépend fortement
du temps de réponse du serveur HTTP. Cela conduit à des interfaces utilisateur plus lentes
que leurs équivalentes natives. Les navigateurs actuels mettent les éléments communs en
cache, donc le chargement de pages nouvelles n'oblige pas le serveur à redonner les mêmes
éléments à chaque fois.
Les applications utilisant les techniques Ajax, quant à elles, peuvent envoyer des requêtes au
serveur HTTP pour récupérer uniquement les données nécessaires en utilisant la requête
HTTP XMLHttpRequest ; ces requêtes sont dites « asynchrones ». Les feuilles de style (CSS)
sont utilisées pour la présentation des informations au sein des pages Web. Le langage
JavaScript côté client est utilisé pour interpréter la réponse du serveur HTTP et pour effectuer
des traitements (affichages de menus déroulants, saisies…). Les applications sont alors plus
réactives, la quantité de données échangées entre le navigateur et le serveur HTTP étant
fortement réduite. Le temps de traitement de la requête côté serveur est également réduit, une
partie du traitement étant réalisée sur l'ordinateur d'où provient la requête.
En contrepartie, le chargement de la première page peut être pénalisant si l'application utilise
une bibliothèque Ajax volumineuse (certaines bibliothèques pèsent plus de 500 ko, mais cela
reste rare).
ESI 2009/2010 ANNEXE
144
Approches côté serveur :
Un des points critiques dans la programmation avec Ajax est la nécessité d'une architecture
client/serveur, mais des solutions en mode déconnecté (offline en anglais) commencent à voir
le jour (fonctionnement du poste client sans nécessité d'être relié au réseau Internet ou à
l'Intranet d'une entreprise). AJAX n'a pas besoin de code actif sur le serveur (seul le code
JavaScript est actif sur le poste client), ce dernier étant un serveur Web se contentant
d'envoyer les pages Web vers le poste client. Car les langages employés sont de type
interprété et sont exécutés directement au sein du navigateur du poste client. Il n'est donc pas
nécessaire de déployer ou de mettre à jour une machine virtuelle (comme pour Java par
exemple) sur le poste client. Ainsi AJAX est une solution portable, ses différents composants
suivant les standards du W3C. Malgré tout, des technologies supplémentaires peuvent être
employées côté serveur, notamment pour la gestion des données au format XML, ou comme
par exemple des langages de script et des bases de données (PHP et MySQL par exemple).
Ces choix sortent du périmètre d'Ajax, mais peuvent apporter de nombreux services
supplémentaires ou complémentaires :
Java fournit une technologie à maturité avec un support des processus légers (threads)
et un important soutien de la communauté Open Source.
PHP possède aussi un fort soutien de la communauté Open Source, notamment la
version 5 plus performante sur la gestion du XML en natif.
Perl propose notamment Catalyst.
Python est un langage de script complet et largement utilisé mais moins que Java ou
PHP sur les serveurs (Google l'utilise largement).
ColdFusion avec les librairies CFjavax, Neuromancer, Sarissa, etc.
Uniface 9.3 implémente Ajax avec ses Pages dynamiques
La concurrence :
La concurrence pour l'affichage de contenus dynamiques au sein d'une page Web est la
suivante :
Flash et Flex (Adobe Systems);
JavaFX (Sun Microsystems);
Silverlight (Microsoft) ;
XForms, un standard de formulaire proposé par le W3C (non implémenté).
Avantages et inconvénients :
L'avantage de cette méthode est d'abord la vitesse à laquelle une application AJAX répond
aux actions de l'utilisateur, qui sont traitées (en partie au moins) localement par le navigateur.
Respectant en grande partie les standards Web (W3C et IETF), AJAX possède également des
ESI 2009/2010 ANNEXE
145
qualités de portabilité. Très vite déployé, Ajax permet d'abaisser les coûts de développement
de petites applications, ainsi que les coûts de renouvellement de parc informatique ; car AJAX
fonctionne avec des ressources matérielles relativement faibles : simples postes clients ne
nécessitant pas beaucoup de mémoire (contrairement aux technologies JAVA), simple
navigateur, simple serveur Web. Seule condition : choisir un navigateur respectant les
standards et acceptant en outre l'emploi du langage JavaScript (et en particulier l'objet
XMLHttpRequest), ou bien adapter le code de façon à ce que les pages Web soient lues par
tout type de navigateur (ces navigateurs étant de plus en plus rares) ainsi que par les
utilisateurs ne souhaitant pas activer les fonctionnalités JavaScript de leur navigateur
compatible.
L'utilisateur d'applications Ajax doit en effet autoriser l'exécution de code Javascript par son
navigateur, ce qui peut laisser craindre des problèmes de sécurité (cependant, il existe des
antivirus bloqueurs de scripts efficaces). N'utilisant pas le composant JavaScript standard
XMLHTTP, les versions d'Internet Explorer 5 ou 6 pour Windows doivent autoriser les
ActiveX, contrairement aux autres navigateurs (Firefox, Safari, Opera, etc.), cependant la
version 7 d'IE est compatible. Il est donc conseillé de tester les applications Ajax sur chaque
type de navigateur, en raison du non respect des normes Web par certains éditeurs de
navigateurs.
Un autre inconvénient est la question du référencement puisque les robots d'indexation ne
sont pas en mesure d'indexer les contenus engendrés dynamiquement.
Enfin, différents cas de failles de sécurité de type « injection de code » ont été signalés en
2005 et 2006 avec des solutions AJAX déployées de façon standard. À cet égard, il faut
rappeler que dans leur majorité les applications informatiques déployées de façon standard
sont vulnérables. Cette recommandation n'est pas propre à AJAX, elle est valable pour toute
technologie et tout développement. Comme pour presque toute application informatique, une
sécurisation du code, du serveur et des postes clients est donc nécessaire avec AJAX. Ceci se
traduira d'abord par une sécurisation du serveur Web et des bibliothèques de code JavaScript,
ainsi que, côté poste client par la mise à jour du navigateur et l'installation d'un antivirus
bloqueur de scripts malveillants.
Comme pour tout développement Web, établir une connexion par le protocole sécurisé https
est également une solution pour sécuriser les échanges entre les postes clients et le serveur
distribuant les pages Web.
Environnements de développement Ajax :
Pour faciliter l’utilisation de ces technologies, de nombreux frameworks ont été mis en place.
Il s’agit en général d’un ensemble de bibliothèques javascriptpermettant de réaliser les
traitements asynchrones et d’offrir une ergonomie avancée grâce à une palette d’objets
graphiques aboutis.
ESI 2009/2010 ANNEXE
146
Dans un souci d’industrialisation, nombre de ces frameworks ont été couplés à des
frameworks de conception web.
On estime à plus de 500 le nombre de frameworks Javascript actuels. Les principaux sont
dans l'article Frameworks Ajax.
Côté serveur, le principe même d'Ajax implique que nous avons le choix de la technologie.
Cependant, certaines technologies orientées événementiel ont un fort potentiel de
productivité.
Ruby, et spécialement Ruby on Rails
.NET 2.0 de Microsoft développe un framework pour ASP.Net (Microsoft ASP.Net Ajax).
Morfik WebOS AppsBuilder de MORFIK est un EDI complet pour des applications AJAX
avec un 'designer' visuel et le choix du langage de programmation (Pascal, Basic, Java, C#).
Une nouvelle approche permet de se défaire du développement Javascript, souvent jugé
coûteux et complexe. Cette approche vise à industrialiser le développement et est symbolisée
par des frameworks tels que GWT ou Echo2.
En parallèle est développée une ASP.NET Ajax Control Toolkit, qui offre de nombreux
contrôles « prêts à l’emploi » pour les développeurs utilisant Visual Studio 2005. On y trouve
actuellement une trentaine de contrôles mais Microsoft en prévoit 50 à 100, tous fournis avec
leur source. Il existe aussi un tutoriel sur le site pour créer ses propres contrôles Toolkit qui
utilisent la technologie Ajax .NET.
De plus, on a vu récemment arriver le design pattern « Comet », qui propose des solutions
pour effectuer du push de données grâce à Ajax.
Open AJAX :
IBM a créé Open AJAX Initiative, un groupe de promotion de cette technologie avec des
partenaires tels que 24SevenOffice, Adobe Systems, BEA Systems, Borland, the Dojo
Foundation, Eclipse Foundation, Google, Ilog, Yahoo!, Laszlo Systems, Mozilla Corporation,
Novell, Openwave Systems, SAP, Oracle, Red Hat, Tibco, Zend et Zimbra.
Le premier résultat de cette initiative est l'AJAX Toolkit Framework (ATF), un projet qui vise
à proposer des outils pour le développement d'applications AJAX dans l'outil de
développement Eclipse. Ce projet s'appuie entre autres sur la contribution initiale d'IBM et
divers frameworks AJAX open source (tels que Dojo ou Rico) [WIKI 2010].