mémoireDPGR 14.07.2010

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ài 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èstime 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ànné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).


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.


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


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.


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.


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.


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


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.


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.


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


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.


16


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.


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.


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


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.


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


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


20


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


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]


22


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


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.


24


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


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


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]


27


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


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 :


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 :


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


29

Tableau de frais d’allocation pour les activités scientifiques:


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:


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)


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.


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é


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


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.


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


37


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


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


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


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èxistence de lùtilisateur.

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ùn formulaire web


42

Cas d’utilisation N°2 « Gestion des utilisateurs » :

Diagramme :

Figure 5 : Cas d’utilisation N°2 « Gestion des utilisateurs »


Titre Gestion des utilisateurs

But Ce cas d’utilisation permet à l’administrateur de gérer les

utilisateurs et leurs privilèges.

Acteurs administrateur


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



43

Cas d’utilisation N°3 « Publication des messages d’accueil » :

Diagramme :

Figure 6 : Cas d’utilisation N°3 «Publication des messages d’accueil »


Titre Publication des messages d’accueil

But Permettre de gérer les messages d’actualités

Acteurs Administrateur, DirecteurPGR, PrésidentCS, ResponsableED


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.


5. L’utilisateur confirme la modification puis il peut se

déconnecter.


Exceptions Néant



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 »


Titre Initialisation de l’année scolaire

But Permettre d’initialiser une année scolaire

Acteurs DirecteurPGR



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.


5. Le directeur confirme la modification puis il peut se

déconnecter.


Exceptions Néant



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 »


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


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.


5. l’utilisateur confirme la modification puis il peut se

déconnecter.


Exceptions Néant



46

Cas d’utilisation N°6 « Inscription des candidats au concours » :

Diagramme :

Figure 9 : Cas d’utilisation N°6 «Inscription des candidats au concours »


Titre Inscription des candidats en ligne

But Permettre d’inscrire les candidats à distance

Acteurs DirecteurPGR


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


Exceptions Dans le cas ou les informations qui sont introduit par le

candidat sont fausses, l’AgentAd peut les corriger



47

Cas d’utilisation N°7 « Gestion des convocations » :

Diagramme :

Figure 10 : Cas d’utilisation N°7 «Gestion des convocations »


Titre Gestion des convocations

But Permettre de créer, imprimer et envoyer les convocations aux

candidats

Acteurs DirecteurPGR, AgentAd


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.


Exceptions Néant



48

Cas d’utilisation N°8 « Affectation des candidats aux salles » :

Diagramme :

Figure 11 : Cas d’utilisation N°8 «Affectation des candidats aux salles»


Titre Affectation des candidats aux salles

But Permettre d’affecter les candidats aux selles

Acteurs DirecteurPGR, AgentAd


Pré-conditions La gestion d’inscription des candidats est terminée

Enchainements


2. L’utilisateur accède à l’espace d’affectation

3. L’utilisateur affecte les candidats aux salles (amphis)

disponible.


5. L’utilisateur confirme l’affectation.


Exceptions Néant



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 »


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



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


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


Exceptions Néant



50

Cas d’utilisation N°10 « Inscription scolaire » :

Diagramme :

Figure 13 : Cas d’utilisation N°10 «Inscription scolaire »


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



Enchainements


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é


Exceptions Néant



51

Cas d’utilisation N°11 « Gestion des plannings» :

Diagramme :

Figure 14 : Cas d’utilisation N°11 «Elaboration des plannings »


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



Enchainements


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


Exceptions Néant



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 »


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



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


Exceptions Néant



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 »


Titre Introduction du résultat des examens

But Ce cas nous permet d’introduire le résultat des examens au

système

Acteurs ResponsableED



Enchainements


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


Exceptions Néant



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 » :


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



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


Exceptions Néant



55

Souscas d’utilisation « Affectation des projets aux étudiants» :


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)


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


Exceptions Si l’étudiant est déjà affecté, le système lui demande de

contacter le directeur de la DPGR pour changer son sujet


Souscas d’utilisation « Gestion du résultat de soutenance » :


Titre Gestion du résultat de soutenance

But Ce cas nous permet d’introduire le résultat de soutenance (note

et mention)

Acteurs ResponsableED


Pré-conditions Le cas de suivi de soutenance est terminé

Enchainements


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


Exceptions Néant



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é »


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


Pré-conditions L’activité est déjà crée

Enchainements


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


Exceptions Néant



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» :


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




Enchainements


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


Exceptions Néant



58

Souscas d’utilisation « Détermination du résultat de stage ou de communication » :


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




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


Exceptions Néant



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 » :


Titre Création d’un nouveau projet de recherche

But Ce cas permet de crée un nouveau projet de recherche

Acteurs Enseignant



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


Exceptions Néant



60

Souscas d’utilisation « Suivi des projets de recherche» :


Titre Suivi des projets de recherche

But Ce cas permet de suivre un projet de recherche chaque

semestre

Acteurs PrésidentCS



Enchainements


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


Exceptions Néant


Souscas d’utilisation « Détermination du résultat de projet de recherche» :


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



Enchainements


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


Exceptions Néant



61

Cas d’utilisation N°18 « Consultation des statistiques » :

Diagramme :

Figure 21 : Cas d’utilisation N°18 « Consultation des statistiques »


Titre Consultation des statistiques

But Ce cas nous permet de consulter les statistiques

Acteurs DirecteurESI, Président CS, DirecteurPGR, MESRS, AgentAd



Enchainements


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


Exceptions Néant



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


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


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


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)


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


64

Suivi des projets des étudiants :

Figure 24. Suivi des projets des étudiants

Gestion des soutenances :

Figure 25. Gestion des soutenances


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


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


67

Diagramme de classes par packages :

Diagramme de classe associé à la gestion de concours:

Figure 28 : Diagramme de classe associé à la gestion de concours


68

Diagramme de classe associé à la gestion de la scolarité :

Figure 29 : Diagramme de classe associé à la gestion de la scolarité


69

Diagramme de classe associé à la gestion de soutenance :

Figure 30 : Diagramme de classe associé à la gestion de soutenance


70

Diagramme de classe associé à la gestion de projet de recherche :

Figure 31 : Diagramme de classe associé à la gestion de projet de recherche


71

Diagramme de classe associé à la gestion des activités scientifiques :

Figure 32 : Diagramme de classe associé à la gestion des activités scientifiques


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


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


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é)


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


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


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


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


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


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


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


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


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


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


85

Les états du candidat :

Figure 46. Diagramme de transition d'un candidat


86

Les états d’un étudiant :

Figure 47. Diagramme de transition d'un étudiant


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


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.


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


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).


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]


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.


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.


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.


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


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.


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.


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


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


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


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,


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


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


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


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


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


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,


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


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.


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.


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.


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.


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]

http://fr.wikipedia.org/wiki/Progiciel

http://fr.wikipedia.org/wiki/Informatique_d%C3%A9cisionnelle


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


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


120

Formulaire d’inscription en ligne des candidats au concours:

Figure 58 : Formulaire d’inscription en ligne des candidats au concours


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


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


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


124

Formulaire de suivi des projets de recherche :

Figure 65 : Formulaire de suivi des projets de recherche


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).


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.


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.


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.)


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


130

déclaration,…)

Validation des activités scientifiques Mise à jour

Elaboration des statistiques Consultation

Elaboration des déférents plannings Mise à jour

Responsable de


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.


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.


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)

pg.esi.dz

http://www.kaspersky.com/

http://www.obout.com/

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.


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.

http://fr.wikipedia.org/wiki/Test_de_Turing

http://fr.wikipedia.org/wiki/Utilisateur_%28informatique%29

http://fr.wikipedia.org/wiki/Ordinateur

http://fr.wikipedia.org/wiki/Test_de_Turing

http://fr.wikipedia.org/wiki/Internet

http://fr.wikipedia.org/wiki/Bot_informatique

http://fr.wikipedia.org/wiki/Bot_informatique

http://fr.wikipedia.org/wiki/Image

http://fr.wikipedia.org/wiki/Son_%28physique%29

http://fr.wikipedia.org/wiki/Lettre_%28typographie%29

http://fr.wikipedia.org/wiki/Chiffre

http://fr.wikipedia.org/wiki/Image

http://fr.wikipedia.org/wiki/Moniteur_d%27ordinateur

http://fr.wikipedia.org/wiki/Site_Web

http://fr.wikipedia.org/wiki/Spam

http://fr.wikipedia.org/wiki/Webmail

http://fr.wikipedia.org/wiki/Forum_de_discussion

http://fr.wikipedia.org/wiki/Blog

http://fr.wikipedia.org/wiki/Spamdexing

http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es

http://fr.wikipedia.org/wiki/Attaque_par_force_brute

http://fr.wikipedia.org/wiki/Sondage_d%27opinion

http://fr.wikipedia.org/wiki/R%C3%A9tro-acronymie

http://fr.wikipedia.org/wiki/Anglais_am%C3%A9ricain

http://fr.wikipedia.org/wiki/Marque_commerciale

http://fr.wikipedia.org/wiki/Universit%C3%A9_Carnegie_Mellon

http://fr.wikipedia.org/wiki/2000

http://fr.wikipedia.org/wiki/Luis_von_Ahn

http://fr.wikipedia.org/wiki/Luis_von_Ahn

http://fr.wikipedia.org/wiki/Manuel_Blum

http://fr.wikipedia.org/wiki/International_Business_Machines_Corporation


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.

http://fr.wikipedia.org/wiki/Hacker_%28s%C3%A9curit%C3%A9_informatique%29

http://fr.wikipedia.org/wiki/Mot_clef

http://fr.wikipedia.org/wiki/Leetspeak

http://fr.wikipedia.org/wiki/Institut_de_science_de_Weizmann

http://fr.wikipedia.org/wiki/1996_en_informatique

http://fr.wikipedia.org/wiki/1997

http://fr.wikipedia.org/wiki/AltaVista

http://fr.wikipedia.org/wiki/Moteur_de_recherche

http://fr.wikipedia.org/wiki/Moteur_de_recherche

http://fr.wikipedia.org/wiki/OCR

http://fr.wikipedia.org/wiki/OCR

http://fr.wikipedia.org/wiki/Num%C3%A9riseur_de_document

http://fr.wikipedia.org/wiki/Brother_%28entreprise%29

http://fr.wikipedia.org/wiki/Reconnaissance_de_caract%C3%A8res

http://fr.wikipedia.org/wiki/Puzzle

http://fr.wikipedia.org/wiki/2000_en_informatique

http://fr.wikipedia.org/wiki/Yahoo%21

http://fr.wikipedia.org/wiki/Algorithmique

http://fr.wikipedia.org/wiki/Brevet

http://fr.wikipedia.org/wiki/Intelligence_artificielle

http://fr.wikipedia.org/wiki/D%C3%A9compilation


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.

http://fr.wikipedia.org/wiki/Accessibilit%C3%A9

http://fr.wikipedia.org/wiki/D%C3%A9ficience_visuelle

http://fr.wikipedia.org/wiki/Intelligence_artificielle

http://fr.wikipedia.org/wiki/Reconnaissance_vocale

http://fr.wikipedia.org/wiki/Mot_de_passe

http://fr.wikipedia.org/wiki/C%C3%A9cit%C3%A9

http://fr.wikipedia.org/wiki/Lecteur_d%27%C3%A9cran


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.

http://fr.wikipedia.org/wiki/PayPal

http://fr.wikipedia.org/wiki/Gmail

http://fr.wikipedia.org/wiki/Orkut


http://fr.wikipedia.org/wiki/Forum

http://fr.wikipedia.org/wiki/Blog

http://fr.wikipedia.org/wiki/World_Wide_Web_Consortium


http://fr.wikipedia.org/wiki/Spam

http://fr.wikipedia.org/wiki/Client_%28informatique%29


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.

http://fr.wikipedia.org/wiki/ReCAPTCHA

http://fr.wikipedia.org/wiki/Asynchronisme

http://fr.wikipedia.org/wiki/JavaScript

http://fr.wikipedia.org/wiki/Extensible_Markup_Language

http://fr.wikipedia.org/wiki/Informatique

http://fr.wikipedia.org/wiki/Application_%28informatique%29

http://fr.wikipedia.org/wiki/World_Wide_Web

http://fr.wikipedia.org/wiki/DHTML

http://fr.wikipedia.org/wiki/LAMP

http://fr.wikipedia.org/wiki/Hypertext_Markup_Language

http://fr.wikipedia.org/wiki/XHTML

http://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade

http://fr.wikipedia.org/wiki/Document_Object_Model


http://fr.wikipedia.org/wiki/XMLHttpRequest

http://fr.wikipedia.org/wiki/Extensible_Markup_Language

http://fr.wikipedia.org/wiki/JSON

http://fr.wikipedia.org/wiki/Navigateurs_Web

http://fr.wikipedia.org/wiki/Firefox

http://fr.wikipedia.org/wiki/Internet_Explorer

http://fr.wikipedia.org/wiki/Konqueror

http://fr.wikipedia.org/wiki/Google_Chrome

http://fr.wikipedia.org/wiki/Safari_%28logiciel%29

http://fr.wikipedia.org/wiki/Opera


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).

http://fr.wikipedia.org/w/index.php?title=Jesse_James_Garrett&action=edit&redlink=1

http://fr.wikipedia.org/wiki/XMLHttp

http://fr.wikipedia.org/wiki/Microsoft


http://fr.wikipedia.org/wiki/ActiveX


http://fr.wikipedia.org/wiki/Mozilla

http://fr.wikipedia.org/wiki/Serveur_HTTP


http://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade


http://fr.wikipedia.org/wiki/Biblioth%C3%A8que_logicielle


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

http://fr.wikipedia.org/wiki/Client-serveur


http://fr.wikipedia.org/wiki/PHP

http://fr.wikipedia.org/wiki/MySQL

http://fr.wikipedia.org/wiki/Java_%28langage%29

http://fr.wikipedia.org/wiki/Processus_l%C3%A9ger

http://fr.wikipedia.org/wiki/Open_Source

http://fr.wikipedia.org/wiki/PHP:_Hypertext_Preprocessor

http://fr.wikipedia.org/wiki/Open_Source

http://fr.wikipedia.org/wiki/SimpleXML

http://fr.wikipedia.org/wiki/Perl_%28langage%29

http://fr.wikipedia.org/wiki/Catalyst_%28logiciel%29

http://fr.wikipedia.org/wiki/Python_%28langage%29

http://fr.wikipedia.org/wiki/Google

http://fr.wikipedia.org/wiki/ColdFusion

http://fr.wikipedia.org/wiki/UNIFACE

http://fr.wikipedia.org/wiki/Adobe_Flash

http://fr.wikipedia.org/wiki/Adobe_Flex

http://fr.wikipedia.org/wiki/Adobe_Systems

http://fr.wikipedia.org/wiki/JavaFX

http://fr.wikipedia.org/wiki/Sun_Microsystems

http://fr.wikipedia.org/wiki/Microsoft_Silverlight


http://fr.wikipedia.org/wiki/XForms

http://fr.wikipedia.org/wiki/W3C


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.


http://fr.wikipedia.org/wiki/Microsoft_Windows

http://fr.wikipedia.org/wiki/Firefox

http://fr.wikipedia.org/wiki/Safari_%28logiciel%29

http://fr.wikipedia.org/wiki/Opera

http://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rencement

http://fr.wikipedia.org/wiki/Robot_d%27indexation


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

http://fr.wikipedia.org/wiki/Cadre_d%27Application_AJAX

http://fr.wikipedia.org/wiki/Ruby

http://fr.wikipedia.org/wiki/Ruby_on_Rails

http://fr.wikipedia.org/wiki/Microsoft_.NET


http://fr.wikipedia.org/wiki/MORFIK

http://fr.wikipedia.org/wiki/EDI

http://fr.wikipedia.org/wiki/GWT

http://fr.wikipedia.org/wiki/Echo_%28Framework%29

http://fr.wikipedia.org/wiki/Design_pattern

http://fr.wikipedia.org/wiki/Comet_%28informatique%29

http://fr.wikipedia.org/wiki/Server_push

http://fr.wikipedia.org/wiki/International_Business_Machines_Corporation

http://fr.wikipedia.org/wiki/Asynchronous_JavaScript_and_XML#Open_AJAX

http://fr.wikipedia.org/w/index.php?title=24SevenOffice&action=edit&redlink=1

http://fr.wikipedia.org/wiki/Adobe_Systems

http://fr.wikipedia.org/wiki/BEA_Systems

http://fr.wikipedia.org/wiki/Borland

http://fr.wikipedia.org/wiki/Google

http://fr.wikipedia.org/wiki/Ilog


http://fr.wikipedia.org/wiki/OpenLaszlo

http://fr.wikipedia.org/wiki/Mozilla_Corporation

http://fr.wikipedia.org/wiki/Novell

http://fr.wikipedia.org/wiki/Systems,_applications,_and_products_for_data_processing

http://fr.wikipedia.org/wiki/Oracle_Corporation

http://fr.wikipedia.org/wiki/Red_Hat

http://fr.wikipedia.org/wiki/Zend

http://fr.wikipedia.org/wiki/Zimbra

http://fr.wikipedia.org/wiki/Ajax_Toolkit_Framework

http://fr.wikipedia.org/wiki/Eclipse_%28logiciel%29

http://fr.wikipedia.org/wiki/Framework

http://fr.wikipedia.org/wiki/Open_source

http://fr.wikipedia.org/wiki/Dojo_Toolkit

http://fr.wikipedia.org/wiki/Rico

Documents

mémoireDPGR 14.07.2010