Vous êtes sur la page 1sur 111

Rpublique de Cte dIvoire

Ministre de LEnseignement Suprieur


et de la Recherche Scientifique

Union Discipline - Travail

ESI
Ecole Suprieure dIndustrie
N dordre : 05/10/ESI/ING TLC/2011

E
Direction de lOrientation et des Bourses

MEMOIRE DE FIN DE CYCLE


Pour lobtention du diplme dingnieur de conception
Option Tlcommunications
THEME :

RENOVATION DU SYSTEME INFORMATIQUE DE


GESTION DES TRAVAUX DE LA COMMISSION
NATIONALE DORIENTATION (CNO) ET DE LA
COMMISSION NATIONALE DES BOURSES (CNB)
Priode du stage : du 27 Juin 2011 au 27 Septembre 2011
Prsent par : KOUAKOU Kouam Valentin,
lve ingnieur en Tlcommunications

ENCADREUR PEDAGOGIQUE
M. TETY Pierre
Enseignant-chercheur lINP-HB

MAITRE DE STAGE
M. AYEKOE Kobon Jrme
Directeur de lOrientation et des Bourses

Anne acadmique 2010 - 2011

Rpublique de Cte dIvoire

Ministre de LEnseignement Suprieur


et de la Recherche Scientifique

Union Discipline - Travail

ESI
Ecole Suprieure dIndustrie
N dordre : 05/10/ESI/ING TLC/2011

E
Direction de lOrientation et des Bourses

MEMOIRE DE FIN DE CYCLE


Pour lobtention du diplme dingnieur de conception
Option Tlcommunications
THEME :

RENOVATION DU SYSTEME INFORMATIQUE DE


GESTION DES TRAVAUX DE LA COMMISSION
NATIONALE DORIENTATION (CNO) ET DE LA
COMMISSION NATIONALE DES BOURSES (CNB)
Priode du stage : du 27 Juin 2011 au 27 Septembre 2011
Prsent par : KOUAKOU Kouam Valentin,
lve ingnieur en Tlcommunications

JURY

MEMBRES

N 3

M. Bla Kouam,
M. Adama Kon,
M. Edi Mousso,
Mme Siaka,

Anne acadmique 2010 - 2011

DEDICACES

A
Dieu Tout-Puissant qui ma accord la sant le long de mon cursus,
LEtat de Cte dIvoire qui a financ ma formation,
Mes parents qui ont su me soutenir dans les moments difficiles de la vie,
Merci !

REMERCIEMENTS

Nous tenons manifester notre gratitude des personnes particulires qui ont permis la
ralisation de ce travail et grce qui nous sommes parvenus la fin de notre formation. Sans tre
exhaustifs, nous aimerions citer :
M. AYEKOE Kobon Jrme, directeur de lorientation et des bourses, notre matre de stage,
pour lintrt quil a su nous accorder et quil a accord notre travail.
Mme EHILE, sous-directrice de lorientation et du suivi des lves, pour sa disponibilit et
tous les efforts consentis la fourniture des lments ncessaires la ralisation du projet.

Mme SEGUI, sous-directrice des bourses, pour nous avoir fourni les informations relatives
aux bourses de lenseignement secondaire gnral.
M. TIECOURA Kouam, directeur de Centre dInformation et dOrientation (CIO), dont la
connaissance du systme oprant nous a t dune utilit indniable.
M. KOUAKOU Marcelin, notre encadreur technique, dont lexpertise dans lenvironnement
WINDEV et la collaboration nous ont t dun apport considrable.
Tout le personnel de la Direction de lOrientation et des Bourses, principalement messieurs
KONAN et YAPO du Service Suivi des programmes, Communication et Archives, et le
Service Informatique et Statistiques de la DOB pour leur entire collaboration et leur grande
sociabilit.
M. TETY Pierre, enseignant-chercheur au DFR-GEE de lINP-HB, notre encadreur
pdagogique, coordinateur de la filire Ingnieur Tlcoms, pour sa disponibilit et tous les
efforts consentis la mise en forme du prsent mmoire.
Tout le corps professoral et administratif de lINP-HB,

Ceux qui nous ont soutenus et continuent de nous soutenir par leurs prires et leurs penses.

III

SOMMAIRE
INTRODUCTION .......................................................................................................................................... 13
PREMIERE PARTIE : CONTEXTE DU STAGE ET ETUDE DE LEXISTANT ................................ 14
CHAPITRE 1 : CADRE DE REFERENCE ................................................................................................. 15
1.1

Prsentation de la structure daccueil ........................................................................................ 15

1.2

Prsentation du thme de stage .................................................................................................. 17

CHAPITRE 2 : ETUDE DE LEXISTANT ................................................................................................. 20


2.1

Description des processus daffectation en sixime, dorientation en seconde, dattribution et

de renouvellement de bourses .................................................................................................................. 20


2.2

Description du systme informatique de la DOB ....................................................................... 26

2.3

Ncessit damlioration ............................................................................................................ 27

DEUXIEME PARTIE : ETUDE TECHNIQUE ......................................................................................... 30


CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION ......................................................... 31
3.1

Approche de la conception de systme dinformation ................................................................ 31

3.2

Proposition de solutions ............................................................................................................. 34

3.3

Choix dune solution ................................................................................................................... 37

CHAPITRE 4 : MODELISATION DU SYSTEME DINFORMATION .................................................... 40


4.1

Concepts gnraux ..................................................................................................................... 40

4.2

Modlisation de lapplication ..................................................................................................... 54

4.3

Modlisation de la base de donnes ........................................................................................... 61

TROISIEME PARTIE : DEPLOIEMENT DE LA SOLUTION .............................................................. 63


CHAPITRE 5 : DEPLOIEMENT MATERIEL............................................................................................ 64
5.1

Pour le service informatique de la DOB .................................................................................... 64

5.2

Pour les services informatiques des structures loignes .......................................................... 65

5.3

Scurit matrielle ...................................................................................................................... 66

CHAPITRE 6 : DEPLOIEMENT LOGICIEL ............................................................................................. 68


6.1

Pour le service informatique de la DOB .................................................................................... 68

6.2

Pour les services informatiques des structures loignes .......................................................... 68

6.3

Scurit logicielle ....................................................................................................................... 68

CONCLUSION ............................................................................................................................................... 70
REFERENCES WEBOGRAPHIQUES ....................................................................................................... 71
REFERENCES BIBLIOGRAPHIQUES ..................................................................................................... 71
ANNEXES ............................................................................................................................................... LXXII
GLOSSAIRE............................................................................................................................................ CVIII

IV

LISTE DES FIGURES

LISTE DES FIGURES


Figure 1.1 : Localisation de la DOB ..................................................................................................15
Figure 1.2 : Organigramme de la DOB .............................................................................................. 17
Figure 2.1 : Processus daffectation en sixime .................................................................................21
Figure 2.2 : Processus dorientation en seconde ................................................................................23
Figure 2.3 : Processus global de gestion des bourses .........................................................................25
Figure 3.1 : Systme dInformation (SI) ............................................................................................ 31
Figure 3.2 : Schma gnrale dune architecture centralise ............................................................. 32
Figure 3.3 : Schma gnrale dune architecture dcentralise .........................................................33
Figure 3.4 : Schma dchange dans une architecture monoposte .....................................................34
Figure 3.5 : Architecture distribue via internet ................................................................................36
Figure 3.6 : Architecture distribue via un rseau tendu national ....................................................37
Figure 3.7 : Architecture distribue dans un rseau local ..................................................................39
Figure 4.1 : Structure hirarchique dune base de donnes hirarchique ...........................................41
Figure 4.2 : Maillage dans une base de donnes rseau .....................................................................41
Figure 4.3 : Cycle d'abstraction pour la conception des systmes d'information............................... 45
Figure 4.4.a : Exemple de certificat numrique sous Mozilla Firefox ...............................................52
Figure 4.4.b : Contenu dun certificat numrique ..............................................................................53
Figure 4.4.c : Exemple de cl publique dans un certificat numrique ...............................................53
Figure 4.5 : Diagramme UML des cas dutilisation dAPPLIDOB ...................................................55
Figure 4.6 : Procdure de communication avec une base de donnes dans une architecture distribue
de type client/serveur .........................................................................................................................56
Figure 4.7 : Diagramme UML de squence relatif la connexion au systme ..................................57
Figure 4.8 : Diagramme UML de squence relatif la mise jour de la BD ....................................58
Figure 4.9 : Diagramme UML de squence relatif la consultation dinformation .......................... 58
Figure 4.10 : Diagramme UML dactivit relatif laffectation automatique en sixime et
lorientation automatique en seconde .................................................................................................60
Figure 5.1 : Serveur de base de donnes ............................................................................................ 64
Figure 5.2 : Ordinateur personnel ......................................................................................................64
Figure 5.3 : Cble paires torsades blind .......................................................................................65
Figure 5.4 : Switch Dlink 24 Ports .....................................................................................................65
Figure 5.5 : Carte rseau Ethernet - RJ45 .......................................................................................... 65
Figure A.1 : MCD du sous-systme Indentification ..................................................................... lxxix

LISTE DES FIGURES

Figure A.2 : MCD du sous-systme Evaluation Cadre ..................................................................lxxx


Figure A.3 : MCD du sous-systme Evaluation Notes ................................................................. lxxxi
Figure A.4 : MCD du sous-systme Vux ................................................................................... lxxxii
Figure A.5 : MCD du sous-systme Authentification ................................................................. lxxxiii
Figure A.6 : MCD du sous-systme Bourses .............................................................................. lxxxiv
Figure A.7 : MCD du sous-systme Cartographie .......................................................................lxxxv
Figure A.8 : MCD du sous-systme Collaboration .................................................................... lxxxvi
Figure A.17 : Arborescence des structures dans APPLIDOB ................................................... lxxxviii
Figure A.18 : Table de dtail dans APPLIDOB ........................................................................ lxxxviii
Figure A.19 : Formulaire denregistrement dlve de troisime Onglet Identification .......... lxxxix
Figure A.20 : Formulaire denregistrement dlve de troisime Onglet Evaluation .............. lxxxix
Figure A.21 : Formulaire denregistrement dlve de troisime Onglet Orientation.................... xc
Figure A.22 : Formulaire denregistrement dlve de CM2 Onglet Identification ....................... xc
Figure A.23 : Formulaire denregistrement dlve de CM2 Onglet Evaluation .......................... xci
Figure A.24 : Formulaire denregistrement dlve de CM2 Onglet Affectation .......................... xci
Figure A.25 : Vue gnrale de MD5 ................................................................................................ xcii
Figure A.26 : Une opration de MD5 .............................................................................................xciii
Figure A.27 : Une itration de SHA-1 ............................................................................................. xcv
Figure A.28 : Centre de contrle HyperFileSQL ...........................................................................xcvii
Figure A.29 : Les ports ncessaires l'utilisation de HyperFileSQL Cluster ................................. xcix
Figure A.30 : HyperFileSQL Client/Serveur via Internet ..................................................................cii
Figure A.31 : Protocoles de communication en HyperFileSQL Client/Serveur ............................... civ
Figure A.32 : Principe de fonctionnement de HyperFileSQL Client/Serveur ................................... cv
Figure A.33 : Principe de fonctionnement de HyperFileSQL classic rseau .................................... cvi

VI

LISTE DES TABLEAUX

Tableau 2.1 : Nombre denfants dune mme famille pouvant prtendre une bourse
dEnseignement gnral secondaire en fonction des ressources ........................................................24
Tableau 2.2 : Tableau rcapitulatif dattribution de bourses en 6me..................................................25
Tableau 2.3 : Tableau rcapitulatif dattribution de bourses en 2nde ..................................................25
Tableau A.1 : Tableau rcapitulatif du choix de base de donnes effectuer en fonction de la
situation .............................................................................................................................................ciii

TABLE DES ABREVIATIONS

TABLE DES ABREVIATIONS

AGL

Atelier de Gnie Logiciel

AOO

Analyse Oriente Objet

BEPC

Brevet d'Etude du Premier Cycle

CA

Certification Authority

CD

Compact Disc

CEPE

Certificat d'Etude Primaire et Elmentaire

CIO

Centre dInformation et dOrientation

CNB

Commission Nationale des Bourses

CNO

Commission Nationale de lOrientation

COO

Conception Oriente Objet

CRCMO

Commission Rgionale de Calcul de Moyenne dOrientation

DDEN

Direction Dpartementale de lEducation Nationale

DECO

Direction des Examens et Concours

DOB

Direction de lOrientation et des Bourses

DREN

Direction Rgionale de lEducation Nationale

HTTP

HyperText Transfer Protocol

IEP

Inspection de lEnseignement Primaire

LDD

Langage de Dfinition de Donnes

LMD

Langage de Manipulation de Donnes

MCD

Modle Conceptuel de Donnes

MCT

Modle Conceptuel des Traitements

MD5

Message Digest 5

MEN

Ministre de lEducation Nationale

VIII

TABLE DES ABREVIATIONS

MGA

Moyenne Gnrale Annelle

MLD - R

Modle Logique de Donnes Relationnel

MO

Moyenne dOrientation

MOT

Modle Organisationnel des Traitements

MPD

Modle Physique de Donnes

POO

Programmation Oriente Objet

RAD

Rapid Application Development

SHA

Secure Harsh Algorithm

SIS

Service Informatique et Statistiques (de la DOB)

SQL

Structured Query Language

TGP

Total Gnral Pondr

TIC

Technologies de lInformation et de la Communication

UML

Unified Modeling Language

IX

AVANT-PROPOS

AVANT-PROPOS

Actes de cration de lINP-HB

L'Institut National Polytechnique Flix HOUPHOUT-BOIGNY, en abrg INPHB, est


n, par Dcret 96678 du 04/09/96, de la fusion de l'cole Nationale Suprieure d'Agronomie
(ENSA), l'cole Nationale Suprieure des Travaux Publics (ENSTP), l'Institut Agricole de Bouak
(IAB) et de l'Institut National Suprieur de l'Enseignement Technique (INSET), quatre
tablissements que l'on dsignait communment sous le vocable Grandes coles de Yamoussoukro.

Missions de lINP-HB

Dfinies par le dcret 96-678 du 04/09/96, les missions de lINP-HB sont :


>

La formation initiale et la formation continue : formations diplmantes et qualifiantes de


techniciens suprieurs, dingnieurs (des techniques ou de conception) dans les domaines de
lindustrie, du commerce, de ladministration, du gnie civil, des mines et de l'agronomie;

>

La recherche applique dans les domaines prcdemment cits ;

>

Lassistance et la production au profit des entreprises et administrations.

Ambitions de lINP-HB

Ses ambitions sont la mesure des espoirs que la nation ivoirienne place en lui pour la
formation des lites qui lui assureront une prsence digne dans le concert des nations du troisime
millnaire. Il ambitionne aussi de dvelopper son leadership tant au plan national qu lchelle
sous-rgionale dans le domaine de la formation et de la recherche technique et technologique.

LEcole Suprieure d'Industrie

LINP-HB est constitu ce jour de sept (07) Ecoles dont une cole prparatoire. Celle
laquelle nous appartenons est lEcole Suprieure dIndustrie (ESI), charge de former des cadres de
haut niveau capables de promouvoir et d'accompagner les volutions techniques et technologiques
au sein des entreprises industrielles et d'accrotre leur comptitivit. Elle est organise aujourdhui
en plusieurs filires dont le Cycle Ingnieur de Conception en Tlcommunications.

Le Cycle Ingnieur de Conception en Tlcommunications

Conscient des besoins du march et constatant la volont du gouvernement de faire de la


Cte dIvoire un point de rfrence en matire de tlcoms, l'INP-HB, a eu la lourde mission
douvrir depuis 2002 au sein de lESI la filire Ingnieur Tlcoms en partenariat avec les
X

AVANT-PROPOS

oprateurs du monde des nouvelles technologies, de lindustrie et de la recherche Lingnieur


Tlcoms et Rseaux INP-HB est appel rpondre aux besoins du march des tlcoms en pleine
croissance. Son intgration sera donc possible chez un constructeur, un oprateur du secteur des Tlcoms
ou dans une socit qui offre des services de tlcoms.

[1]

La formation intgre le dveloppement d'un esprit d'initiative et s'appuie sur un partenariat


trs actif avec les milieux socioprofessionnels. Cette troite collaboration avec les entreprises se
matrialise au niveau des tudiants par des stages quils doivent effectuer durant le cycle. De plus,
la validation de cette formation ncessite deffectuer un stage qui revt un caractre assez
particulier. En effet, au cours de ce stage (qui est le dernier du cycle), ltudiant aura mener des
tudes dans le cadre de son mmoire de fin de cycle.
Cest dans ce cadre que nous avons intgr le Service Informatique et Statistiques de la
Direction de lOrientation et des Bourses (DOB) o nous avons uvr la rnovation du systme
informatique de gestion des travaux de la Commission Nationale dOrientation (CNO) et de la
Commission Nationale des Bourses (CNB).

XI

RESUME

Ce mmoire de fin de cycle dtaille la mise en place dun systme de gestion automatise
des affectations en sixime (6ime) et des orientations en seconde (2nde) en Cte dIvoire. Lobjectif
du projet est la rduction au strict minimum des oprations, jusquici presque manuelles, effectues
par la Commission Nationale dOrientation (CNO) et la Commission Nationale des Bourses (CNB)
en concevant une application oprationnelle et fiable mme dautomatiser celles-ci. Ltude
globale du processus daffectation en sixime (6ime) et dorientation en seconde (2nde) nous a
permis de faire des propositions visant, en partie, des changements notables au sein du systme
ducatif ivoirien. Ces changements devront permettre un fonctionnement optimal de lapplication
que nous avons mise au point par une meilleure rationalisation des oprations qui influencent la
CNO et la CNB. En outre, les diverses solutions proposes sont toutes bases sur larchitecture du
systme informatique de la Direction de lOrientation et des Bourses (DOB) et sur le processus
didentification des lves. Cest dailleurs ce qui nous a amens une analyse technique de
lexistant pour proposer des solutions viables centres sur diffrentes architectures matrielles. La
solution retenue pour le trs court terme exige une architecture distribue de type Client/Serveur.

Mots-cls :
Base

de

donnes,

modlisation,

rseau,

scurit,

systme

dinformation

XII

INTRODUCTION
Aprs lindpendance, la Cte dIvoire a connu prs de deux dcennies de croissance
conomique soutenue. Cas singulier, ce miracle ivoirien s'explique par la volont des
dirigeants

d'asseoir,

ds

1960,

le

dveloppement sur l'agriculture,

principalement

les

plantations de cafiers et de cacaoyers. Si l'agriculture occupe une place de choix dans le


dveloppement conomique, les secteurs secondaire et tertiaire ne sont pas ngligs pour
autant. Avec l'industrie naissante et l'administration qui rclament des cadres comptents, se
pose rapidement la question des ressources humaines. La ncessit de former des cadres
nationaux, trop peu nombreux l'indpendance, dtermine la politique du gouvernement en
matire

d'ducation

et de formation. Ainsi, linstauration dun mcanisme dorientation et

dattribution de bourses, gr par une structure sous tutelle du Ministre de lEducation Nationale
(MEN), simpose, afin de permettre une insertion socioprofessionnelle adquate pour chaque futur
cadre. Cest dans cette vision quest ne la Direction de lOrientation et des Bourses (DOB).
Anime du dsir de suivre le dveloppement prodigieux des Technologies de lInformation
et de la Communication (TIC) et de profiter des avantages indniables quelles offrent
lautomatisation des systmes oprants, la DOB a opt pour la mise en place dun systme de
gestion automatise des affectations en sixime (6ime) et des orientations en seconde (2nde). Mais,
conue au mpris des rgles de la modlisation, lapplication prsente des anomalies qui, au regard
des nombreuses rclamations formules par les parents dlves, affectent la qualit des rsultats
issus de la Commission Nationale dOrientation (CNO) et de la Commission Nationale des Bourses
(CNB). Cest pour pallier ces problmes, par la rnovation de son systme informatique, que nous
avons t accueillis au sein du Service Informatique et Statistiques (SIS) de la DOB.
Le prsent mmoire, dont lobjectif est dexpliquer le travail effectu, est structur en trois
(03) parties. La premire partie prsente ltude de lexistant, en exposant ses diffrents points
faibles qui nourrissent la ncessit de concevoir un nouveau systme plus stable. Dans la deuxime
partie, nous procdons ltude technique des solutions viables par lexplication de leurs avantages
et inconvnients en vue daider la DOB au choix dune solution adquate. Enfin, le dploiement du
systme dinformation conu est lobjet de la troisime partie, en dtaillant la rpartition
gographique, matrielle, logicielle et humaine des diffrentes entits composantes.

13

PREMIERE PARTIE : CONTEXTE DU STAGE ET ETUDE DE LEXISTANT

Nous dcrivons, dans cette partie, lenvironnement de travail dans lequel nous avons volu
et lensemble des mthodes et matriels de travail utiliss par la DOB avant, pendant et aprs les
travaux de la CNO et de la CNB. Nous expliquons aussi lintrt du thme tudi.

14

CHAPITRE 1 : CADRE DE REFERENCE

CHAPITRE 1 : CADRE DE REFERENCE


1.1 Prsentation de la structure daccueil
1.1.1 Gnralits
En 1972, l'office du Baccalaurat est dtach de l'Universit, compte tenu de l'ampleur de
l'organisation de cet examen. Les choses voluant, il devient une direction centrale de l'ducation
nationale. En 1978, on lui adjoint les examens pdagogiques (CAPES, CAPCEG). La fusion des
deux services (le service des examens et concours (qui s'occupait de l'organisation du BEPC et de
l'entre en sixime) et l'office du baccalaurat) donne la Direction des Examens et Concours
(D.EX.C). En 1994, le service de l'orientation est fusionn la D.EX.C pour donner la Direction
des Examens, des Concours et de l'Orientation (D.E.CO). En 1996, le service de l'orientation est
dtach de la DECO, qui devient la Direction des Examens et Concours (DEC) pour tre rattach
la Direction de l'Enseignement Secondaire (DES). En avril 2000, le service de l'orientation et des
bourses revient la DEC qui devient ainsi la Direction des Examens, des Concours, de l'Orientation
et des Bourses (DECOB).
Depuis l'anne 2005, la Sous Direction de l'Orientation et des Bourses (DOB) est devenue
une direction

[2]

situe Abidjan (Plateau), prcisment au quatrime (04me) tage de limmeuble

alpha 2000. Elle compte dix-neuf (19) bureaux et une (01) salle de confrence.

Figure 1.1 : Localisation de la DOB

15

CHAPITRE 1 : CADRE DE REFERENCE

1.1.2 Mission de la DOB


Conformment aux dispositions du dcret n 2010-32/1391 du 18 mars 2010 modifiant et
compltant le dcret n 2004-564 du 07 Octobre 2004 portant organisation du Ministre de
lEducation Nationale, la DOB est charge :
1. de Llaboration dune politique nationale dorientation et de suivi des lves partir du
prscolaire et primaire ;
2. de la prparation et de lorganisation de la commission nationale dorientation en seconde et
daffectation en sixime en liaison avec les structures concernes ;
3. de llaboration, en liaison avec les tablissements concerns des tats nominatifs des lves
boursiers et de leur transmission la Direction des affaires Financires ;
4. de llaboration et du suivi de lapplication des textes rglementaires relatifs linformation,
lorientation et lattribution des bourses du secondaire ;
5. de loctroi, du renouvellement et du transfert des bourses aux lves de lenseignement
secondaire ;
6. du suivi du cursus et de lencadrement psychologique rapproch de llve.
1.1.3 Organisation de la DOB
Pour mener ses missions, la DOB dispose de :
A. deux sous-directions :
1. La sous-direction de lOrientation et du Suivi des Elves avec quatre (04) services ;
2. La sous-direction des Bourses avec trois (03) services
B. trente-trois (33) structures dconcentres : les Centres dInformation et dOrientation
(CIO).
C. six (06) services rattachs:
1. Le Service Comptabilit et Logistique
2. Le Service Gestion Administrative
3. Le Service Courier
4. Le Service Etudes et Projets
5. Le Service Suivi des Programmes, Communication et Archives
6. Le Service Informatique et Statistiques (portes 13 et 14), au sein duquel nous avons
travaill. Ce service a pour missions :
>

La mise en place dun programme dquipement en matriel informatique de la


DOB et de tous les services dorientations et des bourses ;

>

La gestion du parc informatique de la DOB;


16

CHAPITRE 1 : CADRE DE REFERENCE

>

La conception et le suivi des programmes informatiques de la DOB ;

>

La saisie et le traitement des donnes statistiques relatives lorientation en


2nde, laffectation en 6ime et aux bourses ;

>

Larchivage lectronique au sein de la DOB ;

>

Lidentification des besoins de la DOB en matriel informatique ;

>

La maintenance du matriel informatique de la DOB ;

>

La cration dun site internet ;

>

La gestion de la salle informatique de la DOB.

Figure 1.2 : Organigramme de la DOB


1.2 Prsentation du thme de stage

1.2.1 Positionnement du sujet


Lopration daffectation en sixime et dorientation en seconde est une activit sensible et
trs pnible lorsquelle est faite de faon manuelle. Elle ncessite, dans cette configuration, une
importante ressource humaine et donc une plus grande ressource financire. En plus, lide de tenir
les dlais imposs en minimisant les erreurs et les dpenses financires lies au surcrot de
17

CHAPITRE 1 : CADRE DE REFERENCE

personnel, justifie le choix pour la DOB de nous soumettre le thme ainsi libell rnovation du
systme informatique des travaux de la Commission Nationale dOrientation (CNO) et de la
Commission Nationale des Bourses (CNB) . Mais, fort des problmes que pourrait engendrer un
systme informatique de qualit mdiocre, la DOB se donne les moyens de mettre en place un
systme fiable, stable et viable en exigeant une modlisation conforme aux rgles de lart.
1.2.2 Cahier des charges
1.2.2.1 Centre dintrt
Optimiser les travaux de la CNO et ceux de la CNB.
1.2.2.2 Contraintes gnrales
La rnovation du systme informatique de gestion des travaux de la CNO et de la CNB se
droulera sur trois (03) mois et se fera avec lAtelier de Gnie Logiciel (AGL) WINDEV.
1.2.2.3 Objectifs
1. Concevoir un nouveau systme informatique de gestion des travaux de la CNO et de la
CNB ;
2. Matriser lenvironnement WINDEV;
3. Former les gestionnaires lutilisation de lapplication.
1.2.2.4 Mthodologie
La rnovation du systme informatique de gestion des travaux de la CNO et de la CNB sera
consacre aux oprations suivantes :
1.

Analyse et conception de lapplication ;

2.

Exprimentation de lapplication ;

3.

Atelier de validation

Composante 1 : Analyse et conception de lapplication


Cette composante sarticulera autour de 4 phases essentielles.
Phase 1 : Etude fonctionnelle
Il sagit de faire ltat des fonctionnalits existantes et proposition de nouvelles
fonctions :
1. Etude technique (dfinition de larchitecture cible),
2. Etude conceptuelle (la modlisation de la solution envisage).
18

CHAPITRE 1 : CADRE DE REFERENCE

Phase 2 : Ralisation
Conception dune application de gestion des travaux de la CNO et de la
CNB.
Phase 3 : Dploiement
1. Dploiement sur le site de la DOB et sur des sites pilotes en rgion,
2. Dploiement sur les autres sites (33 CIO)
Phase 4 : Renforcement des capacits des utilisateurs
Formation des gestionnaires de la DOB et des sites pilotes en rgion,
Composante 2 : Exprimentation de lapplication.
Cette composante consiste lutilisation de lapplication dans des CIO et tablissements
pilotes pour une priode dessai aux fins de dtecter ses imperfections.
Composante 3 : Validation de lapplication.
La validation de lapplication va runir un ensemble dexperts et de cabinets en WINDEV.
Le cabinet LA FAYETTE reprsentation nationale des produits PC SOFT fournisseur du produit
WINDEV, les experts en environnement WINDEV du MEN et de lInstitut National Polytechnique
Flix Houphout Boigny

donneront leur avis pour la validation de lapplication.

19

CHAPITRE 2 : ETUDE DE LEXISTANT

CHAPITRE 2 : ETUDE DE LEXISTANT


Lexistant est lensemble des moyens matriels, humains et des mthodes utiliss au sein du
systme modliser. Cette tude se ramne, en loccurrence, lensemble des mthodes et
matriels dploys par la DOB pour laffectation en sixime et lorientation en seconde des lves
dans le cadre de la CNO, puis pour lattribution et le renouvellement des bourses dans le cadre de la
CNB, en Cte dIvoire. Une description dtaille de ces diffrents processus savre, par
consquent, indispensable.
2.1 Description des processus daffectation en sixime, dorientation en seconde,
dattribution et de renouvellement de bourses
Le processus qui conduit lorganisation de la CNO et de la CNB dbute ds la rentre
scolaire. Il faut signaler quau niveau de cette activit, la DOB est fortement tributaire de la
Direction de l'Informatique, de la Planification, de lEvaluation et des Statistiques (DIPES) et
surtout de la Direction des Examens et Concours (DECO). En effet, la DECO est la structure de
lEducation Nationale qui organise les examens de fin danne et qui, par consquent, fournit les
notes des candidats la DOB pour les affectations-orientations et attributions de bourses. Quant la
DIPES, elle se charge dimmatriculer les candidats admis lentre en sixime.
2.1.1 Description du processus daffectation en sixime
Le processus daffectation en sixime se droule en trois (03) grandes tapes : avant les
assises de la CNO (pr CNO), pendant les assises de la CNO (assises CNO) et aprs les assises de la
CNO (Post CNO).
2.1.1.1 Pr CNO
Cette tape concerne essentiellement lenregistrement des candidats au CEPE et lentre en
sixime et la rcupration des notes obtenues par ces candidats lexamen. Il y a huit (08) niveaux
doprations quon peut ranger en deux (02) grandes tapes : avant et aprs les examens du CEPE.

Avant les examens du CEPE

1. Installation de lapplication de saisie des candidats dans les IEP.


2. Saisie de lidentit des candidats et de leurs vux dtablissements.
3. Correction des anomalies et fusion des fichiers provenant des IEP par DREN.

Aprs les rsultats des examens du CEPE

4. Installation de lapplication de saisie des TGP dans les IEP.

20

CHAPITRE 2 : ETUDE DE LEXISTANT

5. Enregistrement des TGP dans les IEP en fonction de la barre fixe par le Directeur de la
DOB.
6. Correction et fusion nationale des donnes provenant des IEP la DOB.
7. Transmission dun tat cumulatif par tranches de TGP au MEN pour aider fixer la barre
dadmission en sixime
8. Arrt du MEN fixant la barre dadmission en sixime.
2.1.1.2 Assises de la CNO
Cest le lieu deffectuer les affectations proprement dites. Nous avons trois (03) niveaux
daction. Cette tape se droule aprs les examens du CEPE.
1. Vrifications de la conformit des informations relatives aux lves de la base de donnes
(notes dexamens, identit) avec ceux des PV (procs-verbaux) des rsultats dexamen
rcuprs auprs de la DECO.
2. Affectation automatique : les candidats sont affects par ordre de mrite en fonction des
capacits daccueil des tablissements par lapplication Epervier.
3. Affectation manuelle : les lves battus durant laffectation automatique

sont affects

manuellement dans les tablissements non saturs proches (gographiquement)

des

tablissements viss par leurs vux dtablissements.


2.1.1.3 Post CNO
Il sagit de recueillir et de traiter les dossiers de rclamations introduits par les candidats non
satisfaits des rsultats daffectation publis aprs les assises la CNO.
IEP

DOB

MEN

In iti al

Sa is ir c a nd id ats e t vo eu x

Fou rn ir l og ic ie l p ou r I nfo _ ca n d_

Co ns ol id er fic hi er na ti on al

Fou rn ir l og ic ie l p ou r T GP

Sa is ir T GP

Faire co nt rl es e t fu s ion n er do nn es

Fixer ba rre 6 i m e

T e ni r a ss is es CN O

T e ni r p os t C NO

Fina l
Ac tivi t_ 1

Ac tivi t_ 2

Ava nt exa m en d u CEPE

Ac tivi t_ 3

Ac tivi t_ 4

Ap r s e xa me n du CE PE

Figure 2.1 : Processus daffectation en sixime


21

CHAPITRE 2 : ETUDE DE LEXISTANT

2.1.2 Description du processus dorientation en seconde (2nde)


Le processus dorientation en seconde se droule, linstar du processus daffectation en
sixime, en trois (03) grandes tapes : avant les assises de la CNO (pr CNO), pendant les assises de
la CNO (assises CNO) et aprs les assises de la CNO (Post CNO).
2.1.2.1 Pr CNO

Avant les examens du BEPC

1. Saisie des candidats dans les DREN


2. Consolidation du fichier national des candidats officiels au BEPC
3. Installation de lapplication de saisie des moyennes trimestrielles dans les
tablissements.
4. Saisie des moyennes trimestrielles dans les tablissements (la saisie se fait trimestre
aprs trimestre)
5. Transmission du fichier des moyennes trimestrielles aux CIO qui les envoient la DOB.
(Cette opration se fait trimestre aprs trimestre)
6. Correction des erreurs provenant des fichiers rceptionns.
7. Renvoie dans les CIO la fin du dernier trimestre du fichier des moyennes trimestrielles.

Aprs les rsultats du BEPC

1. Constitution dans les DREN des Commissions Rgionales de Calcul de la Moyenne


dOrientation (CRCMO), installation du logiciel de saisie des notes du BEPC.
2. Enregistrement des notes (notes sur 20) du BEPC dans les matires dorientation (notes
sur 20 en composition franaise, mathmatiques, anglais et en sciences physiques) dans
le logiciel pour lobtention des moyennes dorientation.
3. Constitution de ltat cumulatif des lves par tranches de MO pour aider la fixation de
la barre dorientation en seconde (MO limite).
4. Fixation de la barre dorientation par le MEN
2.1.2.2 Assises CNO
1. Correction des fichiers provenant des CRCMO, fusion et constitution du fichier national.
2. Vrifications de la conformit des informations relatives aux lves de la base de
donnes avec ceux des PV de la DECO.
3. Orientation automatique et manuelle.

22

CHAPITRE 2 : ETUDE DE LEXISTANT

2.1.2.3 Post CNO


Gestion des dossiers de rclamations mis par les lves et parents dlves non satisfaits
des rsultats publis aprs les assises.
DREN

DOB

MEN

ETABLISSEMENT

I nitial

Saisir candidat s et voeux

Fournir Masque de saisie

Consolider f ichier nat ional

I nitial_1
Fournir logiciel de saisie de moyennes

Saisir moyennes t rimest rielles

Par TRI MESTRE


Faire cont rles et calculer MO (CRCMO)

Dt erminer MO limite

Tenir assises CNO

Tenir post CNO

Final
Act ivit_1

Act ivit_2

Avant examen du BEPC

Act ivit_3

Act ivit_4

Aprs examen du BEPC

Figure 2.2 : Processus dorientation en seconde


2.1.3 Description du processus dattribution et de renouvellement de bourses
La sous-direction des bourses est lune des deux sous-directions qui composent la DOB.
Elle a pour missions essentielles :
1. lattribution de bourses aux lves de 6me et de 2nde ;
2. le renouvellement des bourses ;
3. la gestion et le suivi des tats servant au paiement des bourses.
LEtat ivoirien, soucieux de lavenir de sa jeunesse, a institu la bourse scolaire dans son
systme ducatif ds son accession lindpendance. Ainsi, dans les annes soixante (1960), il
suffisait de russir lexamen dentre en 6me pour bnficier dune bourse. On disait lpoque non
pas je suis admis lexamen dentre en 6me mais plutt jai eu ma bourse . A cette poque,
Les seules conditions doctroi de bourse taient celles dtre lve et de nationalit ivoirienne selon
larticle 2 du dcret n 60-310 du 21 Septembre 1960. Plus tard, en 1984, le dcret n84-1024 du 22
Aot ajoutera aux critres mentionns plus haut ceux des rsultats scolaires, du niveau de revenu
des parents et de lge (tre g de 15 ans au plus pour la 6me et de 18 ans au plus pour la 2nde).

23

CHAPITRE 2 : ETUDE DE LEXISTANT

Tableau 2.1 : Nombre denfants dune mme famille pouvant prtendre une bourse
dEnseignement gnral secondaire en fonction des ressources
Nombre denfants

Groupe I

Groupe II

Groupe III

Groupe IV

charge

100.000 F CFA

de 100.000 F

de 200.000 F

300.000 F CFA et

200.000 F CFA

300.000 F CFA

plus

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

10

20

20

10

Ce tableau sexplique simplement : un parent qui a un revenu mensuel de cent mille francs
CFA (100.000 F CFA) voit tous ses enfants obtenir la bourse ( condition bien sr davoir les
moyennes, lge et la nationalit requis). Par contre, un parent de revenu mensuel suprieur cent
mille francs CFA (100.000 F CFA) a droit un nombre limit de boursiers parmi ses enfants,
jusqu ne plus bnficier de la bourse quand il dpasse trois cent mille francs CFA (300.000 F
CFA) de revenu mensuel.
Aujourdhui, les seuls critres retenus sont la nationalit ivoirienne et les rsultats scolaires.
Dans les deux cas (attribution et renouvellement de bourse), le processus global se prsente
comme suit :
1.

La DOB met, en cours danne scolaire, la liste des lves boursiers et demi-boursiers
(pour le renouvellement seulement ; il ny a pas de demi-boursiers en attribution) la
24

CHAPITRE 2 : ETUDE DE LEXISTANT

disposition des tablissements (les conomes sont les acteurs cls de la sous-direction
des bourses dans les tablissements) ;
Lconome imprime les tats de bourse et fait marger les lves concerns pour

2.

signaler leur prsence au sein de ltablissement ;


3.

Les fiches signes sont transfres la DOB ;

4.

Ces fiches sont transfres la Direction des Affaires Financires (DAF) aprs contrle
et gestion des omis et retardataires ;

5.

La DAF met, aprs approbation, la liste des lves mandats la disposition du Trsor
public pour le paiement effectif des bourses.

ETABLISSEMENT

DOB

DAF

TRESOR PUBLIC

Initial

F aire signer tats de bourse

F ournir liste boursiers et demi-boursiers

F aire contrles et grer les omis

F aire contrles et dfinir lves mandats

Payer lves mandats

F inal

Figure 2.3 : Processus global de gestion des bourses


2.1.3.1

Description du processus dattribution de bourses

Chaque anne scolaire, des barres dattribution de bourses pour la sixime et la seconde sont
fixes par rapport au budget restant aprs le renouvellement de bourses. Ainsi, la bourse est
accorde aux lves ivoiriens remplissant les conditions de rsultats scolaires dfinies par la CNB.
Pour exemple, voici les tableaux rcapitulatifs dattribution de bourses des classes de 6me et de 2nde
des trois dernires annes.
Tableau 2.2 : Tableau rcapitulatif dattribution de bourses en 6me
Pourcentage des

Anne scolaire

TGP exig pour

Equivalent du TGP en

Total des lves

Nombre

boursiers par

tre boursier

termes de moyenne

affects

daffects

rapport aux

Boursiers

affects

(TGP/8,5)

2007-2008

147,32

17,33

142 450

1901

01,33

2008-2009

143,30

16,85

165 198

6456

03,90

2009-2010

142,30

16,74

162 272

6225

03,83

Tableau 2.3 : Tableau rcapitulatif dattribution de bourses en 2nde


25

CHAPITRE 2 : ETUDE DE LEXISTANT

2.1.3.2

Description du processus de renouvellement de bourses


Pourcentage des

Anne scolaire

Moyenne dorientation exige

Total des lves

Nombre

boursiers par

orients

dorients

rapport aux

Boursiers

orients

2007-2008

14,30

50 000

1732

03,46

2008-2009

13,20

50 194

2922

05,82

2009-2010

12,72

46 615

3212

06,67

Les textes qui rgissent les bourses sont ceux de 1984. Ils dterminent les critres suivants
pour le renouvellement de la bourse :
Pour le premier cycle
>

tre de nationalit ivoirienne ;

>

avoir une moyenne gnrale annuelle suprieure ou gale douze (12) sur vingt (20) pour la
bourse entire ;

>

une moyenne gnrale annuelle comprise entre onze (11) sur vingt (20) et onze virgule
quatre-vingt-dix-neuf (11,99) sur vingt (20) donne droit une demi bourse.

Pour le second cycle


>

tre de nationalit ivoirienne ;

>

avoir une moyenne gnrale annuelle suprieure ou gale onze (11) sur vingt (20) pour la
bourse entire ;

>

une moyenne gnrale annuelle comprise entre dix (10) sur vingt (20) et dix virgule quatrevingt-dix-neuf (10,99) sur vingt (20) donne droit une demi bourse.

Mais dans la pratique, les critres de moyennes du premier cycle sont appliqus aux deux
cycles vu la rduction de lenveloppe budgtaire due aux difficults conomiques (deux milliard
(2.000.000.000) de F CFA en 1994, puis huit cent million (800.000.000) de F CFA depuis 2007).
Une fiche de demande de renouvellement de bourse pour lanne acadmique prochaine est
remplie par lconome de ltablissement pour chaque lve boursier ou demi-boursier et transfre
la DOB pour analyse. Elle contient principalement les performances scolaire du concern et est
dment signe par ce dernier.
2.2 Description du systme informatique de la DOB
Un systme informatique est un ensemble dentits matrielles et logicielles qui
interagissent selon des algorithmes. Pour optimiser le rendement dun tel systme, une architecture
soigneusement pense doit tre dfinie aux niveaux matriel et logiciel.
26

CHAPITRE 2 : ETUDE DE LEXISTANT

2.2.1

Architecture matrielle

La DOB dispose dun rseau local connect internet. Ce rseau local, est un lment cl
dans les changes de donnes numriques au sein de la direction et de ses services. Il pourra, en
outre tre exploit pour le dploiement du nouveau systme dinformation. Elle possde aussi des
ordinateurs au sein de chaque service, trs utiles pour le dploiement dj voqu.
2.2.2

Architecture logicielle

La DOB dispose de la licence dutilisation de lAGL WINDEV. WINDEV est un produit de


PC SOFT, et est sa version 16 lheure o ces lignes sont crites.
La socit PC SOFT est une socit franaise, spcialise dans la conception de logiciels de
haute technologie comme les environnements de dveloppement professionnels pour Internet,
Intranet, Windows, Linux, Unix, les mobiles,
A laide de cet AGL, une application dnomme Epervier a t conue pour automatiser
les travaux de la CNO ; une autre application GESTBOURSE a t crite pour ceux de la CNB.
Ces applications utilisent des bases de donnes HyperFileSQL classic rseau. Elles sont dployes
au sein des diffrentes structures de la DOB pour les prparatifs de la CNO et de la CNB.
2.3 Ncessit damlioration
La procdure de gestion des orientations et des affectations, dans sa configuration actuelle,
est trop lourde et porte fortement atteinte la qualit des rsultats (au regard des nombreuses
rclamations formules par les parents dlves). Les mthodes de collectes des donnes sont peu
fiables (des va-et-vient des CD). En outre, une trop grande intervention de lhomme sur la chane de
production des rsultats est signaler. Lapplication de gestion informatise des orientations et
affectations connat quelques limites qui obrent la qualit du travail de la CNO et occasionne
dnormes pertes de temps. Cela nous amne cibler les diffrentes failles aux niveaux matriel,
logiciel et de la main duvre en vue de proposer des solutions fiables et viables.
2.3.1

Les failles matrielles

Le systme actuel de gestion automatise des actes de la CNO et de la CNB ne fonctionne


pas en mode rseau. Il ny a pas de serveur ddi pour la base de donnes, toutes les oprations
tant effectues sur des ordinateurs personnels. Cela constitue un problme essentiel dans la mesure
o la synchronisation des donnes est pnible. En outre, les ordinateurs personnels, servant aux
activits de tierces personnes en dehors des actes de la CNO et de la CNB, peuvent subir des dgts
pouvant entraner une perte compromettante de donnes essentielles. Le piratage des donnes
27

CHAPITRE 2 : ETUDE DE LEXISTANT

sensibles en est aussi facilit. Lutilisation de CD pour le transfert de linformation entre les
diffrentes structures est revoir. En effet, le temps daccs mmoire sur les CD est trs lev et
les CD se dtriorent trs facilement (il suffit dune gratignure sur la surface rflchissante),
entrainant des vas-et-viens rpts entre la DOB et des structures loignes, sinon des temps de
ressaisie supplmentaires. On assiste alors au ralentissement du processus de fusion des donnes.
2.3.2

Les failles logicielles

Le dveloppement de lapplication existante, essentiellement bas sur le RAD (Rapid


Application Development), pourrait occasionner la non maitrise du code source, ce qui pourrait
exacerber les difficults de dtection et de correction des erreurs de fonctionnement du logiciel. En
effet, le RAD est une technique de gnration automatique dinterfaces graphiques et de codes
ncessaires lexcution de tches plus ou moins complexes partir dun schma de donnes
appel analyse dans lenvironnent WINDEV. Ainsi, le dveloppeur se contente de crer
lanalyse et par clic sur une suite de boutons, tout le code quil est sens crire est automatiquement
gnr. Bien que cette technique prsente des avantages en terme de rapidit de dveloppement, elle
peut complexifier les diagnostiques derreurs, puisque le dveloppeur ne dispose pas
ncessairement des comptences requises pour comprendre le code gnr. En outre cette technique
est difficile implmenter lorsque lanalyse a une structure relationnelle, raison pour laquelle les
diffrents fichiers (appels tables dans les autres SGBD comme Oracle, MySQL, Access)
nont pas t lis, occasionnant des redondances dinformation, voire de srieuses anomalies de
mise jour de la base de donnes. Aussi, HyperFileSQL est un SGBD relationnel (Voir Annexe
A.6). Par consquent, la gestion dune base de donnes non relationnelle laide de ce SGBD
constitue une erreur dexploitation assez importante qui alourdit les interactions avec la base de
donnes.
En outre, nayant pas t dveloppe selon un modle soigneusement conu ,
lapplication existante exige des modifications frquentes bases sur des dductions empiriques ;
cela prsente linconvnient majeur de crer des redondances de donnes au sein de la base de
donnes pouvant alourdir, pour sr, les changes avec celle-ci. Le dploiement du logiciel est trs
difficile dans la mesure o une copie des composants installer doit tre envoye par CD aux
diffrentes structures loignes autorises lutiliser. Cela rend pnible les mises jour de
lapplication lorsquil y a ncessit de modifier certaines de ses fonctionnalits. Enfin, aprs la
saisie de donnes, lapplication offre la possibilit loprateur de saisie dexporter les donnes
dans un fichier au format xsl non chiffr (fichier ditable par le logiciel Microsoft Excel) quil grave

28

CHAPITRE 2 : ETUDE DE LEXISTANT

sur un CD et le transfre la DOB. Ce moyen est trs fragile puisque le fichier peut tre modifi
sans lapplication fournie par la DOB.
Il faut aussi prciser que malgr la puissance suppose du moteur dHyperFileSQL, ce
SGBD, peu connu dans le monde des experts , mrite une tude approfondie pour dcider de sa
validit pour le projet denvergure qui nous est soumis.
2.3.3

Les failles de main duvre

Conue et administre au mpris des rgles de gestion de systme dinformation,


lapplication ne respecte pas la grande majorit des techniques de modlisation de systme
dinformation. Cela fragilise normment la scurit dont doit jouir une application traitant des
donnes aussi sensibles que lorientation et lattribution de bourses aux lves. Un autre problme
se situe au niveau des collaborateurs informaticiens des structures loignes qui ne matrisent pas
toujours les connaissances ncessaires la bonne marche de lapplication ; ce qui donne leu des
programmes de formation coteux en temps et en moyen financier. Nous notons aussi les
rcurrentes erreurs de saisie faites par les oprateurs de saisie qui imposent un surplus de travail au
SIS.
Enfin, le transport des CD vers la DOB ncessite de solliciter des personnes fiables, choix
plus ou moins difficile faire, pouvant compromettre lauthenticit des informations transmises.
Tous ces problmes ont donn leu des situations plus ou moins regrettables :
>

Double orientation dlves ;

>

Elves affects dans la base de donnes mais absents sur les listings ;

>

Elves affects sans tablissement daccueil ;

29

DEUXIEME PARTIE : ETUDE TECHNIQUE

Nous allons dans cette partie expliquer les diffrents choix effectus pour la ralisation du
projet qui nous a t soumis. Il sagira en effet dexposer de faon explicite les lments techniques
utiliss, allant de la gnralit sur la conception de systme dinformation la ralisation pratique
du projet.

30

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION


3.1 Approche de la conception de systme dinformation
Un Systme dInformation (SI) est un systme
constitu des ressources humaines, des ressources
informatiques (quipement, logiciel, donnes) et des
procdures permettant dacqurir, de stocker, de traiter et
de diffuser les lments dinformation pertinents au
fonctionnement dune entreprise ou dune organisation
(Management Information System, en Anglais)

[3]

En ce qui nous concerne, la partie grer est


lensemble des ressources informatiques que la DOB
utilise lors des diffrentes commissions nationales
dorientation et des bourses. En effet, les autres parties
ont fait lobjet de propositions visant une reforme du
systme ducatif et donc ncessitant lintervention
pralable des dcideurs.
Le dveloppement des TIC tant essentiellement
ax sur la rduction au strict minimum de leffort
humain, diffrentes organisations dquipements ont t

Figure 3.1 : Systme dInformation (SI)

mises au point au cours des dcennies en vue de fdrer


les oprations des divers acteurs et permettre laccs
partag des ressources. Deux architectures de base
nous intressent ici :

larchitecture centralise et

larchitecture dcentralise.
3.1.1 Architecture centralise
Une architecture est dite centralise si toutes les ressources se trouvent au mme endroit ou
sur la mme machine. Toutes les machines de larchitecture qui dsirent accder des donnes
interrogent les ressources distantes.

31

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

Figure 3.2 : Schma gnrale dune architecture centralise


3.1.1.1 Avantages de larchitecture centralise
Une architecture centralise permet de concentrer toute l'intelligence au sein d'un mme
matriel, et de n'avoir qu'un seul point administrer, configurer, et surveiller, car c'est le seul
point expos au piratage. Cela simplifie les contrles de scurit et la mise jour des donnes et des
logiciels. Toute la complexit et la puissance peut tre dporte sur le ou les serveur(s), les
utilisateurs utilisant simplement un client lger sur un ordinateur terminal qui peut tre simplifi au
maximum. Les serveurs tant centraliss, cette architecture est particulirement adapte et vloce
pour retrouver et comparer de vaste quantit d'information
3.1.1.2 Inconvnients de larchitecture centralise
Lorsque plusieurs demandes de communication simultane parviennent au serveur, ce
dernier risque de ne pas supporter la charge. Il doit donc tre trs performant, trs rsistant et
surveill de trs prs, ce qui contribue en hausser le prix. En plus, toute indisponibilit du serveur
occasionne le disfonctionnement systmatique de ses clients. Aussi, les clients ne peuvent, en aucun
cas, communiquer entre eux, entrainant une asymtrie de l'information au profit des serveurs.
3.1.2 Architecture dcentralise
Une architecture est dite dcentralise si les ressources se trouvent diffrents endroits, sur
des machines parses. Toutes les machines de larchitecture qui dsirent accder des donnes
interrogent les ressources distantes. Plusieurs serveurs peuvent aussi bien hberger les mmes
donnes que des donnes diffrentes et complmentaires.

32

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

Figure 3.3 : Schma gnrale dune architecture dcentralise


3.1.2.1 Avantages de larchitecture dcentralise
Ce type d'architecture est facilement extensible pour faire face de nouveaux besoins
fonctionnels. Les architectures distribues offrent une grande souplesse pour faire face aux
problmes de monte en charge (rplication, rpartition de charges...) car le seul fait de distribuer
les traitements sur les ordinateurs d'un rseau augmente les ressources disponibles. En outre, elles
sont trs modulaires et offrent de nombreuses possibilits de dploiement. Elles permettent en plus
de mettre en place une trs forte tolrance aux pannes, des nuds complets pouvant tre
indisponibles sans que le service soit interrompu.
Une architecture distribue courante est l'architecture trois tiers la base de la plupart des
applications distribues de commerce lectronique. Cette architecture permet d'interroger et de
mettre jour des sources de donnes rparties, des services web (programmes hbergs sur des
serveurs spcifiques dinternet) permettant de faire appel diffrents serveurs pour enrichir une
prestation. En effet, l'achat d'un sjour touristique peut comprendre l'achat d'un billet d'avion, d'un
sjour htelier et d'une assurance dannulation auprs de diffrents vendeurs par l'intermdiaire de
services web, donc d'objets distribus sur le rseau et dialoguant par des messages.
3.1.2.2 Inconvnients de larchitecture dcentralise
La rpartition des ressources sur plusieurs serveurs est une source de complexit des
applications dployes qui doivent exploiter ces donnes. En plus, elle ncessite un dploiement de
moyen financier plus lev du fait de la multiplicit des nuds actifs. Enfin, Il y a ici plusieurs
nuds susceptibles de subir des attaques de la part dentits malveillantes, ce qui complexifie les
techniques de scurisation du systme.

33

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

3.2 Proposition de solutions


Dans les paragraphes prcdents, nous avons expos les avantages et inconvnients de deux
types darchitectures de systmes dinformation : les architectures distribue et centralise.
Larchitecture matrielle dun systme dinformation tant indispensable une productivit
optimale, nous proposons dans ce qui suit deux architectures inspires des deux familles
darchitectures dj expliques. Ces architectures sont bien sr adaptes au niveau technologique du
pays (Cte dIvoire) et aux contraintes scuritaires lies aux donnes sensibles que lapplication
doit grer. Nous verrons en premier lieu une architecture monoposte qui ne ncessite pas de rseau
informatique pour fonctionner, et en second lieu une architecture distribue de type client/serveur
qui exige linterconnexion des machines de production et qui donc procure une rentabilit optimale
par la synchronisation automatique des donnes.
3.2.1 Larchitecture monoposte
Nous dsignons par architecture monoposte, une architecture dans laquelle aucun rseau
informatique nest ncessaire. Ici les ordinateurs sont isols les uns des autres et communiquent par
des oprations manuelles. En effet, dans cette architecture, les
diffrents ordinateurs reoivent une copie de
lapplication et traite les donnes de manire
autonome, sous la conduite dun oprateur
humain. Une fois le travail ralis sur lun des
ordinateurs, les donnes sont copies sur une
mmoire de masse (CD, DVD, Cl USB, Disque
dur externe) pour les passer un autre

Figure 3.4 : Schma dchange dans une

ordinateur. Ainsi, nous voyons bien les problmes

architecture monoposte

que peut gnrer une telle architecture. La


synchronisation savre pnible (cest dailleurs
un des problmes qui tourmentent lapplication
existante) dans la mesure o larrive des supports amovibles, depuis plusieurs ordinateurs, est trs
souvent difficile synchroniser. Dans larchitecture monoposte (cest dailleurs larchitecture
utilise actuellement par le SIS pour la gestion de la CNO et de la CNB), seule lapplication sera
notre centre dattention. Il faudra concevoir une application plus stable et la dployer sur les
diffrents sites loigns de la DOB en y implmentant le maximum dlments de scurit.
Contrairement ce qui existe dj, la nouvelle application devra exiger un mot de passe avant toute
utilisation. Un super utilisateur (utilisateur qui a tous les droits sur lapplication) sera
34

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

automatiquement cr linstallation de lapplication. Ce dernier, et lui seul, pourra crer dautres


utilisateurs pour la ralisation de tches donnes en limitant leurs droits sur lapplication. Toute
opration effectue par chaque utilisateur sera automatiquement enregistre pour la gnration des
statistiques dutilisation de lapplication et pour la gestion dventuels contentieux. Une fois les
saisies et les contrles faites au niveau de chaque structure loigne (IEP, Etablissement, CIO),
les donnes seront transfres au SIS par les moyens habituels (CD, Message lectronique,) pour
fusion et prparation de la CNO et de la CNB. Un mcanisme dauthentification par cls
asymtrique sera mis en uvre pour fiabiliser le transfert des donnes. Cest une architecture qui
ncessite des moyens financiers relativement faibles. En effet, seule la fourniture des structures
loignes en matriels informatiques (ordinateur, CD) est exige.
3.2.2 Larchitecture distribue de type client/serveur
Dans une architecture distribue, les ressources sont dployes sur diffrents sites. Les
utilisateurs y accdent pour rcuprer ce qui leur est ncessaire. Cela ncessite par consquent la
prsence dun rseau informatique pour lchange des donnes, faisant croitre les dpenses
financires , tandis que la scurit du systme dinformation globale diminue. Notre proposition,
au vue du niveau technologique du pays, se prsente sous deux formes : linterconnexion des
diffrents sites via internet ou via un rseau tendu national laide du rseau des oprateurs de
tlcommunications.
3.2.2.1 Interconnexion via internet
Internet est un vaste rseau lchelle mondiale. Il fdre une multitude de rseaux travers
le monde et constitue un outil dchange trs pris des ivoiriens par la pluralit et la quasi gratuit
des services offerts (messagerie lectronique, change sur des rseaux sociaux comme facebook,
netlog, twitter). Il constitue ainsi un rseau largement accessible toutes les structures
dcentralises de la DOB et peut tre utilis pour centraliser les ressources utiles la CNO et la
CNB sur de puissants serveurs entirement contrls par la DOB. La centralisation des donnes sur
des serveurs contrls par la DOB lavantage de renforcer la scurit des ressources et aussi
dliminer la dispendieuse (en terme de temps et de ressource humaine) opration de fusion
jusquici effectue par le SIS. En effet, cette architecture sous-tend la cration dun site web
dynamique constituant un masque de saisie distance pour chaque structure dcentralise. Les
donnes saisies sont automatiquement enregistres sur les serveurs de la DOB continuellement
connects au serveur web (le serveur web peut aussi bien tre la proprit de la DOB que celle dun
hbergeur de sites web). Les structures dcentralises nont pas besoin dinstaller une quelconque
35

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

application ( condition de disposer dj dun navigateur web); il leur suffit de se connecter au site
web par les moyens habituels (cybercaf, accs ADSL domicile ou au bureau, cl internet des
oprateurs de tlcommunication) pour profiter pleinement des fonctionnalits offertes. Des
techniques de redondance et rplication seront appliques au niveau des serveurs de la DOB de
sorte rediriger automatiquement et de faon transparente lapplication vers le serveur le plus
disponible un instant donn et pallier dventuels problmes de perte de donnes suite
lendommagement dun serveur. Mais un problme majeur pourrait survenir du fait de linscurit
sur internet. En effet, une personne avertie pourrait injecter des donnes dans la base de donnes et
corrompre la sauvegarde. Ces problmes ont tellement inquit les informaticiens que divers
protocoles de scurit rseau ont t conus. Leur utilisation est une assurance en termes de
scurisation de nos ressources. Nous pouvons entre autres citer les tunnels chiffrs de niveau 2 et 3,
aussi appels Rseaux Privs Virtuels ou Virtual Private Networks (VPN en Anglais), IPsec, SSL,
les techniques de chiffrement comme le RSA qui assure une confidentialit indniable des donnes.
Cette architecture pourrait ncessiter assez de moyens financiers du fait de lachat des serveurs.

Figure 3.5 : Architecture distribue via internet


3.2.2.2 Interconnexion via un rseau tendu national
Les rseaux tendus, ou WAN (Wide Area Network), sont destins transporter des
donnes numriques sur des distances lchelle dun pays, voire dun continent ou de plusieurs
continents. Le rseau est soit terrestre, et il utilise dans ce cas des infrastructures au niveau du sol,
essentiellement de grands rseaux de fibre optique, soit hertzien, comme les rseaux de satellites [4].

36

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

Cette solution est envisageable si nous voulons viter les problmes de scurit et de
disponibilit lis internet. En effet, ici, un accord est pris avec un oprateur de tlcommunication
national qui fournit des services supports. Loprateur donne la garantit de la disponibilit du rseau
sur la quasi-totalit du temps ngoci. La scurisation des donnes circulant sur son rseau peuvent
bien tre de son ressort si laccord sign en tient compte. Ce qui change dans cette architecture par
rapport la prcdente, cest le fait que le systme dinformation soit isol du rseau public et que
le rseau de transport soit sous le contrle dune structure connue et reprable en cas
dinsatisfaction dans la transmission des donnes. Cela confre une scurit accrue au systme
informatique en le rendant plus stable. Cependant, le forfait vers au fournisseur du service support
pourrait rendre cette solution plus coteuse que la prcdente. Dans les deux cas, le fait que toute
lintelligence du systme dinformation soit concentre sur le site web qui est unique et sous le
contrle de la DOB rendrait lvolutivit des services offerts plus souple.

Figure 3.6 : Architecture distribue via un rseau tendu national


3.3 Choix dune solution
Les diffrentes architectures ci-dessus exposes nous incitent choisir une architecture
distribue de type client/serveur. En effet, lobservation du processus de gestion des orientations en
seconde et des affectations en sixime, rvle que la plupart des oprations donnant lieu des
doublons dans la base de donnes provient de la pluralit des sources de donnes non synchronises
(un CD par IEP, voire par tablissement). En plus, le transport manuel de linformation est trs
coteux en temps et en ressource humaine ; un ensemble de problmes aisment surmontables par
lutilisation dune architecture distribue de type client/serveur lchelle nationale. Nanmoins, un
37

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

certain nombre de considrations doit tre pris en compte pour rendre le projet viable au regard des
contraintes exprimes.
3.3.1 Les contraintes
Une contrainte est une entrave la libert daction, une rgle obligatoire appliquer

[5]

Les contraintes constituent donc une part importante dans la ralisation de notre projet. Cest
dailleurs llment essentiel qui nous permettra de percevoir les vritables besoins de lutilisateur
et de fournir en consquence une solution adapte. Elles se situent diffrents niveaux, allant du
temps de ralisation la flexibilit de la solution. En effet :
1. Le temps de ralisation est fix trois (03) mois et prend en compte la formation des
utilisateurs et latelier de validation,
2. Le budget allou au projet est relativement rduit (deux millions (2.000.000) FCFA) et la
solution doit imprativement en tenir compte. Cela impose dailleurs lAGL utiliser pour
dvelopper lapplication. Il sagit de WINDEV, la DOB disposant dj dune licence
dutilisation,
3. La solution doit tre facile dutilisation afin de permettre tous les acteurs autoriss de
lutiliser de faon conviviale,
4. Ladministration de la solution doit tre aisment accessible toute personne autorise pour
faciliter dventuelles maintenances et volutions de lapplication,
5. Les problmes de scurit, dintgrit des donnes et de lourdeur lis lapplication
existante doivent tre rsolus.
Le respect de ces contraintes nous permettra de choisir une solution base ventuellement
sur une des architectures prsentes plus haut.
3.3.2 La solution retenue
Le choix dune solution parmi plusieurs est le rsultat dun exercice intellectuel qui obit
certains critres. En effet, la solution retenue doit obligatoirement rpondre aux besoins de
lutilisateur en tenant compte des contraintes auxquelles ce dernier pourrait tre soumis. Ainsi, les
contraintes exposes dans les paragraphes prcdents nous ont permis de faire un choix optimal
pour la DOB. Alors larchitecture distribue de type client/serveur lchelle nationale savre trs
peu viable pour son cot relativement lev. Elle est donc inadapte, bien quelle aurait procur une
solution indniable aux problmes de scurit et dintgrit des donnes de la CNO et de la CNB.
Elle cde par consquent la place une architecture monoposte qui est bien celle jusquici utilise
par la CNO et la CNB. Nanmoins, fort des inconvnients que prsente une telle architecture et qui
38

CHAPITRE 3 : CONCEPTION DE SYSTEME DINFORMATION

dailleurs justifie notre prsence au sein du SIS, nous avons mis en place une variante de
larchitecture distribue de type client/serveur une chelle rduite. Ainsi, larchitecture ncessite
moins de moyen financier tout en fournissant une grande partie des avantages dune architecture
distribue de type client/serveur lchelle nationale. Il sagit ici de dployer les quipements sur
un rseau local au sein de chaque structure de la DOB intervenant dans le processus menant la
CNO et la CNB. Ds lors, le travail en rseau facilitera les oprations de contrle et de correction
qui pourront tre effectues en mme temps que les oprations de saisie. En outre, plusieurs
oprateurs de saisie pourraient travailler simultanment sur la mme base de donnes en liminant
les fastidieuses oprations de fusion de donnes dues une architecture monoposte, ce qui aboutira
une rduction considrable du temps de saisie de donnes. Le rseau peut bien tre limit un
seul ordinateur, donnant ainsi lieu une architecture monoposte. Cette variante incorpore, par
consquent, les deux architectures dj proposes et bnficie donc des avantages de chacune
dentre elles, en prsentant moins dinconvnients que chacune dentre elles. Un avantage non
ngligeable pour cette architecture est la facilit de la migration vers une architecture distribue de
type client/serveur lchelle nationale que nous avons fortement conseille la DOB pour le
moyen terme.

Figure 3.7 : Architecture distribue dans un rseau local


Pour ce qui est du SGBD, nous utiliserons HyperFileSQL, les moyens notre disposition ne
nous permettant pas de nous procurer la licence dutilisation dun autre SGBD. En effet, la DOB
dispose dj de la licence dutilisation de WINDEV et donc de HyperFileSQL (qui vient en
complment WINDEV). Nanmoins, nous recommandons vivement la DOB deffectuer une
tude approfondie de ce SGBD pour juger sa validit, sinon de se procurer la licence dexploitation
dun SGBD connu, qui a dj fait ses preuves dans diverses entreprises. Nous pouvons, entre autres,
citer Oracle et SQL Serveur (utilis, par exemple, par lINP-HB pour la gestion de ses concours).
Mais le cot relativement lev dOracle pourrait le disqualifier et faire de SQL Serveur, dont le
cot est relativement accessible, un SGBD viable et adapt au projet ; l encore, une tude pralable
doit tre faite pour un choix objectif tenant surtout compte des fonctionnalits offertes.
39

CHAPITRE 4 : MODELISATION DU SYSTEME DINFORMATION


4.1 Concepts gnraux
Une gestion efficiente des donnes ncessite la mise en place dune base de donnes
dploye sur un ou plusieurs serveurs de base de donnes. Cette base de donnes devra tre
interroge par des applications soigneusement conues pour viter au mieux les anomalies de mise
jour observes dans certains systmes de conception mdiocre. Dans ce qui suit, nous prsentons les
concepts gnraux utiles, voire indispensables la conception dun systme dinformation fiable et
viable, dans le but de permettre au lecteur de comprendre les diffrents choix effectus pendant la
ralisation du projet.
4.1.1

Bases de donnes et SGBD

Les bases de donnes sont partout dans la vie quotidienne et se prsentent sous diverses
formes. En effet une base de donnes nest rien dautre quun ensemble de donnes structures et
sauvegardes qui qualifie le fonctionnement dune entit organise. Cela peut aller dune pile
dassiettes soigneusement range dans une tagre un ensemble de donnes numriques
sauvegardes sur un ordinateur de capacit relativement grande appel serveur de base de donnes.
Dans notre cas, le traitement doit tre fait sur des donnes numriques, do la ncessit de
concevoir une base de donnes numrique au moyen dun SGBD puissant et fiable.
Un Systme de Gestion de Base de Donnes (SGBD ou Data Base Management System
(DBMS), en Anglais) est un ensemble de logiciels informatiques qui sert la manipulation des bases
de donnes. Il sert effectuer des oprations ordinaires telles que consulter, modifier, construire,
organiser, transformer, copier, sauvegarder ou restaurer des bases de donnes. Il est souvent utilis
par d'autres logiciels ainsi que les administrateurs ou les dveloppeurs. L'ensemble, dont le
composant central est le moteur de base de donnes, peut tre sous forme de composant logiciel, de
serveur, de logiciel applicatif ou d'environnement de programmation. Il permet gnralement
plusieurs utilisateurs et plusieurs logiciels de manipuler plusieurs bases de donnes en mme temps
et ceci quel que soit le contenu et l'organisation des bases de donnes. La majorit des SGBD du
march manipulent des bases de donnes relationnelles. Il est nanmoins important de prciser quil
existe des bases de donnes hirarchiques, rseaux et orientes objets.

40

4.1.1.1

Les bases de donnes hirarchiques

Une premire gnration de SGBD est ne de travaux de recherche mens dans les annes
1960 pour le compte de la NASA (National Aeronautics and Space Administration, agence
aronautique et spatiale des USA) dans le cadre du projet Apollo et commercialiss dans les annes
1970 par la socit IBM sous le nom IMS (Information Management System)

[6]

. Le SGBD tait

bas sur le principe que les enregistrements conservs dans divers fichiers pouvaient tre lis selon
une certaine hirarchie et constituer un assemblage arborescent. On a appel structure hirarchique
cette forme de liaison entre des enregistrements de fichiers distincts. En vertu de ce modle
dorganisation des donnes, un enregistrement peut tre le pre de plusieurs enregistrements qui
leur tour peuvent avoir des fils. Par exemple un
fichier appel tudiants contenant des donnes sur
les tudiants peut tre li un autre fichier Cours
contenant des donnes sur les cours suivis par les
tudiants. A laide dun langage dit de navigation
entre les fichiers, le programmeur accdant un
enregistrement du fichier tudiants peut reprer
automatiquement les enregistrements fils du fichier
Cours. Un SGBD hirarchique possde un avantage
indniable sur les systmes bass sur des fichiers. Il
permet en effet dtablir des liens un plusieurs

Figure 4.1 : Structure hirarchique dune

entre les fichiers dune base de donnes ; un

base de donnes hirarchique

enregistrement pre peut tre li plusieurs


enregistrements fils.
4.1.1.2

Les bases de donnes rseaux

Suite aux nombreux problmes suscits par


les SGBD hirarchiques, des chercheurs de la
socit amricaine General Electric eurent lide
de gnraliser lapproche de ces SGBD en
proposant un modle dorganisation des donnes
permettant des liens plusieurs plusieurs entre les
fichiers. La hirarchie pre-fils nexiste pas dans ce
modle car un enregistrement peut avoir plusieurs

Figure 4.2 : Maillage dans une base de


donnes rseau
41

successeurs de mme que plusieurs prdcesseurs. Les fichiers sont lis en rseau maill la
manire des rseaux dgout o un point du rseau convergent des connecteurs effluents et des
connecteurs affluents.
Ces SGBD sont dits de type rseau (ou simplement SGBD rseau) et permettent de
reprsenter des associations complexes entre les fichiers. Cette catgorie de SGBD a suscit
beaucoup dintrt dans la communaut des chercheurs et des utilisateurs intresss par les bases de
donnes. Cela a donn lieu, la fin des annes 1960, la cration dun groupe de travail visant
dfinir des normes pour le SGBD de type rseau portant sur les caractristiques requises pour
assurer la cration des bases de donnes ainsi que la manipulation de donnes. Ces normes, connues
sous le vocable CODASYL, dcrivent en quelque sorte lenvironnement requis pour la conception
et lexploitation des bases de donnes rseaux. Elles reconnaissaient pour la premire fois de
manire formelle limportance du schma physique de la base de donnes, le rle cl de la personne
responsable de sa construction et de son entretien, cest--dire ladministrateur de base de donnes
(ABD). La norme met en vidence la ncessit de mettre la disposition de lABD un langage pour
la construction de schma physique appel le Langage de Dfinition de Donnes (LDD, ou Data
Definition Language (DDL) en Anglais) ainsi que doffrir au programmeur un langage pour
exploiter les donnes, le Langage de Manipulation de Donnes (LMD, ou Data Manipulation
Language (DML) en Anglais).
4.1.1.3

Les bases de donnes relationnelles

Les SGBD hirarchiques et rseaux constituent la premire gnration de SGBD.


Malheureusement ils comportaient certaines lacunes notamment au plan des fondements thoriques.
De plus ils ne permettaient pas en pratique dassurer lindpendance tant souhaite entre les
applications et les donnes. En effet, comme le lien entre deux enregistrements tait implant
laide dun pointeur, soit une sorte dadresse permettant de reprer un enregistrement associ, cela
donnait lieu des programmes complexes mme pour des requtes simples. Le dbut des annes
1970 a t marqu par une avance importante dans le domaine des SGBD. Edgar Frank Codd,
chercheur au laboratoire de recherche dIBM (International Business Machines) de San Jose en
Californie, sinspirant de lalgbre relationnelle, proposa un mode dorganisation des donnes ne
ncessitant pas de pointeurs pour lier les enregistrements. Non seulement ce modle avait ses
fondements thoriques solidement tablis dans lalgbre relationnelle, mais il tait aussi dune
grande simplicit. La structure dun fichier est dfinie comme une relation entre des donnes
provenant dun nombre fini de domaines. Les enregistrement sont des tuples, et constituent des
occurrences de la relation. Les liens sont assurs entre deux enregistrements sur la base dun champ
42

de mme type, commun aux deux enregistrements. Si les champs communs possdent la mme
valeur, les enregistrements sont logiquement lis. Il nest ds lors plus ncessaire de grer des
pointeurs physiques pour assurer ces liens. De physiques qutaient les liens dans les SGBD
hirarchiques ou rseaux, les liens sont dornavant logiques, bass sur les valeurs des champs, ce
qui rend la navigation entre les enregistrements beaucoup plus souple. Ce mode dorganisation des
donnes a donn naissance une plthore de SGBD relationnels commerciaux et non commerciaux
dont DB2, Oracle, Microsoft Access, MySQL, pour ne nommer que les mieux connus. Les SGBD
relationnels sont de deuxime gnration et ils ont tous en commun intrinsquement un langage
appel SQL (Structured Query Language) agissant la fois comme langage de dfinition et langage
de manipulation de donnes. Malgr leurs nombreuses qualits, les SGBD relationnels ont un
certain nombre de lacunes pour lexpression de modles de donnes un haut niveau dabstraction,
ce que nous dfinirons la partie 4.3, comme le Modle Conceptuel de Donnes.
4.1.1.4

Les bases de donnes orientes objets et autres

Le dveloppement de langages orients objets tels que Java et Smalltalk a conduit la mise
au point de SGBD devant assurer la persistance des objets, soit le stockage permanent sur un
support de mmoire auxiliaire des objets crs laide de tels langages. Ce SGBD dit orient objet
ou simplement SGBD objet appartient la troisime gnration. Le SGBD Gemstone par exemple
est une extension du langage Smalltalk. Le dveloppement des SGBD objet a t frein par des
SGBD hybrides incorporant le modle relationnel et le stockage dobjets. Les objets peuvent tre
soit de type structur comme ceux crs par un langage orient objet ou de type non structur telles
que des images, de la vido, des trames sonores. Le type non structur est aussi appel BLOB
(Binary Large Object). On donne le nom SGBD relationnel-objet cette forme hybride car il
combine les proprits du SGBD relationnel et du SGBD objet. Lditeur amricain Informix a t
un prcurseur en matire de SGBD relationnel-objet pour tre suivi et vite dpass par Oracle et
IBM avec leur produit Oracle8 et DB2 Universal Database System respectivement. A laube du
XXIe sicle on parle dune quatrime gnration de SGBD. Il sagit dune catgorie htrogne de
SGBD conus avant tout pour des applications spcialises, comme par exemple et non
exclusivement, les SGBD OLAP (On Line Analytical Processing) largement utiliss pour
lentreposage des donnes et lexploration des donnes, les SGBD XML pour les applications Web,
ou enfin les SGBD de contraintes pour les applications doptimisation.

43

4.1.2 Merise, POO et UML


La conception d'un systme d'information n'est pas toujours vidente dans la mesure o il
faut rflchir l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception
ncessite par consquent des mthodes permettant de mettre en place un modle sur lequel lon va
s'appuyer. Il existe plusieurs mthodes d'analyse dont Merise et UML qui utilise principalement
lapproche objet.
4.1.2.1 Merise
Issue de l'analyse systmique, la mthode Merise est le rsultat des travaux mens par
Hubert Tardieu, un ingnieur franais diplm de lEcole Suprieure dElectricit (Suplec) en
France, dans les annes 1970 et qui s'insraient dans le cadre d'une rflexion internationale, autour
notamment du modle relationnel d'Edgar Frank Codd. Elle est devenue un projet oprationnel au
dbut des annes 1980 la demande du ministre de l'industrie, et a surtout t utilise en France,
pour les projets d'envergure, notamment des grandes administrations publiques ou prives.

De

l'aveu mme d'un de ses fondateurs, le nom Merise vient de l'analogie faite avec le merisier "qui ne
peut porter de beaux fruits que si on lui greffe une branche de cerisier : ainsi en va-t-il des
mthodes informatiques bien conues, qui ne produisent de bons rsultats que si la greffe sur
l'organisation russit", mme si beaucoup de gens ont voulu y voir un acronyme comme par
exemple Mthode d'tude et de Ralisation Informatique par les Sous-Ensembles ou pour les
Systmes d'Entreprises.

La

mthode Merise d'analyse et de conception propose une dmarche articule simultanment selon
trois (03) axes pour hirarchiser les proccupations et les questions auxquelles rpondre lors de la
conduite d'un projet:
1.

Cycle de vie : phases de conception, de ralisation, de maintenance puis nouveau cycle de


projet.

2.

Cycle de dcision : des grands choix (GO - NO GO : tude pralable), la dfinition du projet
(tude dtaille) jusqu'aux petites dcisions des dtails de la ralisation et de la mise en
uvre du systme d'information. Chaque tape est documente et marque par une prise de
dcision.

3.

Cycle d'abstraction : niveaux conceptuels, logique/organisationnel et physique/oprationnel


(du plus abstrait au plus concret). Lobjectif est de prendre d'abord les grandes dcisions
mtier, pour les principales activits (Conceptuel) sans rentrer dans le dtail de questions
d'ordre organisationnel ou technique.
44

La mthode Merise distingue nettement les donnes et les traitements, mme si les
interactions entre les deux sont profondes et s'enrichissent mutuellement, la validation des donnes
tant effectue par les traitements et rciproquement. Aujourd'hui, avec les SGBD Relationnel,
l'objet, les notions de donnes et de traitements sont de plus en plus imbriques. La conception du
systme d'information se fait par tapes, afin d'aboutir un systme d'information fonctionnel
refltant une ralit physique. Il s'agit donc de valider une une chacune des tapes en prenant en
compte les rsultats de la phase prcdente. D'autre part, les donnes tant spares des traitements,
il faut vrifier la concordance entre donnes et traitement afin de vrifier que toutes les donnes
ncessaires aux traitements sont prsentes et qu'il n'y a pas de donnes superflues. Cette succession
d'tapes est appele cycle d'abstraction pour la conception des systmes d'information:
L'expression

des

besoins

est

une

tape

consistant dfinir ce que l'on attend du


systme d'information automatis, il faut pour
cela faire l'inventaire des lments ncessaires
et dlimiter le systme en s'informant auprs des
futurs utilisateurs. Cela va permettre de crer le
MCC

(Modle

Communication)

Conceptuel
qui

de

dfinit

les

la
flux

d'informations prendre en compte. L'tape


suivante consiste mettre au point le MCD
(Modle Conceptuel des Donnes) et le MCT
(Modle Conceptuel des Traitements) dcrivant
les rgles et les contraintes prendre en compte.
Le modle organisationnel consiste quant lui
dfinir le MOT (Modle Organisationnel des
Traitements)

dcrivant

les

contraintes

Figure 4.3 : Cycle d'abstraction pour la


conception des systmes d'information

organisationnelles, spatiales et temporelles dues

l'environnement.

Le

modle

logique

reprsente un choix logiciel pour le systme


d'information tandis que le modle physique
reflte un choix matriel pour le systme
d'information.

45

4.1.2.2 Programmation Oriente Objet (POO)


La Programmation Oriente Objet (POO), ou programmation par objet, est un paradigme de
programmation informatique labor par un informaticien amricain nomm Alan Kay dans les
annes 1970. Il consiste en la dfinition et l'interaction de briques logicielles appeles objets ; un
objet reprsente un concept, une ide ou toute entit du monde physique, comme une voiture, une
personne ou encore une page d'un livre. Il possde une structure interne et un comportement, et il
sait communiquer avec ses pairs. Il s'agit donc de reprsenter ces objets et leurs relations ; la
communication entre les objets via leurs relations permet de raliser les fonctionnalits attendues,
de rsoudre le ou les problmes.
partir des annes 1980, commence l'effervescence des langages objets : Objective C
(dbut des annes 1980), C++ (C avec classes) en 1983, Eiffel en 1984, Common Lisp Object
System dans les annes 1980, etc. Les annes 1990 voient l'ge d'or de l'extension de la
programmation par objet dans les diffrents secteurs du dveloppement logiciel.
Depuis, la programmation par objet n'a cess d'voluer aussi bien dans son aspect thorique
que pratique et diffrents mtiers et discours mercatiques son sujet ont vu le jour :
1. lanalyse objet (AOO pour Analyse Oriente Objet ou OOA en Anglais pour Object
Oriented Analysis),
2. la conception objet (COO pour Conception Oriente Objet ou OOD en Anglais (Object
Oriented Design)),
3. les bases de donnes objet (SGBDOO),
4. les langages objet avec les langages prototypes,
5. ou encore la mthodologie avec MDA (Model Driven Architecture).
Aujourdhui, la programmation par objet est vue davantage comme un paradigme, le
paradigme objet, que comme une simple technique de programmation. C'est pourquoi, lorsque l'on
parle de nos jours de programmation par objets, on dsigne avant tout la partie codage dun modle
objets obtenu par AOO et COO. Elle ne renie pas la programmation structure ; elle se fonde sur
elle. Elle contribue la fiabilit des logiciels et facilite la rutilisation de code existant. Elle
introduit de nouveaux concepts, en particulier ceux dobjets, dencapsulation, de classe et
dhritage.

46

4.1.2.2.1 Les concepts dobjet et dencapsulation


En programmation structure, un programme est form de la runion de diffrentes
procdures et de diffrentes structures de donnes gnralement indpendantes de ces procdures.
En POO, un programme met en uvre diffrents objets. Chaque objet associe des donnes et des
mthodes agissant exclusivement sur les donnes de lobjet. Mais cette association est plus quune
simple juxtaposition. En effet, dans ce que lon pourrait qualifier de POO pure , on ralise ce que
lon nomme une encapsulation des donnes. Cela signifie quil nest pas possible dagir directement
sur les donnes dun objet; il est ncessaire de passer par ses mthodes, qui jouent ainsi le rle
dinterface obligatoire. On traduit parfois cela en disant que lappel dune mthode est en fait
lenvoi dun message lobjet.
Le grand mrite de lencapsulation est que, vu de lextrieur, un objet se caractrise
uniquement par les spcifications de ses mthodes, la manire dont sont rellement implantes les
donnes tant sans importance. On dcrit souvent une telle situation en disant quelle ralise une
abstraction des donnes, ce qui exprime bien que les dtails concrets dimplmentation sont cachs.
A ce propos, on peut remarquer quen programmation structure, une procdure pouvait galement
tre caractrise, de lextrieur, par ses spcifications, mais que, faute dencapsulation, labstraction
des donnes ntait pas ralise.
Lencapsulation des donnes prsente un intrt manifeste en matire de qualit de logiciel.
Elle facilite considrablement la maintenance : une modification ventuelle de la structure des
donnes dun objet na dincidence que sur lobjet lui-mme ; les utilisateurs de lobjet ne seront
pas concerns par la teneur de cette modification, ce qui ntait bien sr pas le cas avec la
programmation structure. De la mme manire, lencapsulation des donnes facilite grandement la
rutilisation dun objet.
4.1.2.2.2 Le concept de classe
Le concept de classe correspond simplement la gnralisation de la notion de type que lon
rencontre dans les langages classiques. En effet, une classe nest rien dautre que la description dun
ensemble dobjets ayant une structure de donnes commune et disposant des mmes mthodes. Les
objets apparaissent alors comme des variables dun tel type classe, on dit aussi quun objet est une
instance de sa classe. Bien entendu, seule la structure est commune, les valeurs des champs tant
propres chaque objet. En revanche, les mthodes sont effectivement communes lensemble des
objets dune mme classe. Lorsque, comme cela arrive parfois dans lcriture dinterfaces
graphiques, on est amen ne crer quun seul objet dune classe donne, la distinction entre les
notions dobjet et de classe nest pas toujours trs vidente. En revanche, lorsque lon dispose de
47

plusieurs objets dune mme classe, le principe dencapsulation sappliquera la classe et non
chacune de ses instances.
4.1.2.2.3 Lhritage
Un autre concept important en POO est celui dhritage. Il permet de dfinir une nouvelle
classe partir dune classe existante (quon rutilise en bloc), laquelle on ajoute de nouvelles
donnes et de nouvelles mthodes. La conception de la nouvelle classe, qui hrite des proprits et
des aptitudes de lancienne, peut ainsi sappuyer sur des ralisations antrieures parfaitement au
point et les spcialiser volont. Comme on peut sen douter, lhritage facilite largement la
rutilisation de produits existants, dautant plus quil peut tre ritr autant de fois que ncessaire
(la classe C peut hriter de B, qui elle-mme hrite de A).
4.1.2.2.4 Le polymorphisme
En POO, une classe peut "redfinir", cest--dire modifier, certaines des mthodes hrites
de sa classe de base. Cette possibilit est la cl de ce que lon nomme le "polymorphisme", cest-dire la possibilit de traiter de la mme manire des objets de types diffrents, pour peu quils soient
issus de classes drives dune mme classe de base. Plus prcisment, on utilise chaque objet
comme sil tait de cette classe de base, mais son comportement effectif dpend de sa classe
effective qui est drive de la classe de base, en particulier de la manire dont ses propres mthodes
ont t redfinies. Le polymorphisme permet dajouter de nouveaux objets dans un scnario
prtabli et, ventuellement, crit avant davoir connaissance du type exact de ces objets

[7]

4.1.2.3 Unified Modeling Language (UML)


La premire moiti des annes quatre-vingt-dix (1990) a vu fleurir une cinquantaine de
mthodes objet utilises dans la conception des programmes informatiques orients objet. Un tri
effectu sur les diffrents concepts proposs par les mthodes existantes a donn lieu lunification
des mthodes de modlisations objet. Partant de la constatation que les diffrences entres les
mthodes samenuisent et que la guerre des mthodes ne fait plus progresser la technologie objet,
Jim Rumbaugh et Grady Booch dcident fin quatre-vingt-quatorze (1994) dunifier leurs travaux au
sein dune mthode unique : la mthode unifie (The Unified Method, en Anglais). Une anne plus
tard, ils sont rejoints par Ivar Jacobson, le crateur des cas dutilisation (use cases, en Anglais), une
technique trs efficace pour la dtermination des besoins. Ils se fixent quatre objectifs :
1. Reprsenter des systmes entiers (au-del du seul logiciel) par des concepts objets,
2. Etablir un couplage explicite entre les concepts et les artefacts excutables,
48

3. Prendre en compte les facteurs dchelle inhrents aux systmes complexes et critiques,
4. Crer un langage de modlisation utilisable la fois par les humains et les machines.
Les auteurs de la mthode unifie atteignent trs rapidement un consensus sur les concepts
fondamentaux de lobjet. En revanche, la convergence sur les lments de notation est plus difficile
obtenir et la reprsentation graphique retenue pour les diffrents lments de modlisation
connatra plusieurs modifications. UML est sa version 2.4 beta en Mars 2011 et comprend treize
(13) diagrammes dont les diagrammes de cas dutilisation, de squence, dactivit et de dploiement
que nous verrons de faon dtaille dans les sections qui suivent. UML nest pas une notation
propritaire : elle est accessible tous les fabricants doutils ainsi que les entreprises de formation.
La volont douverture, la richesse de la modlisation font dUML une notation gnrale et simple,
sans tre simpliste.
En franais, UML pourrait se traduire par langage unifi pour la modlisation objet, mais il
est plus que probable quUML se traduise plutt par notation unifie, voire notation UML, sur le
mme schma que mthode OMT.
4.1.3 La scurit informatique
En cryptographie numrique, chiffrer une information consiste modifier la suite
d'octets qui constituent cette information au moyen d'un algorithme mathmatique. L'algorithme
tant normalis, il peut tre connu de tout le monde. Ainsi, pour que le secret soit assur, il
faudra

que

cet

algorithme

utilise

un

paramtre

supplmentaire

appel

cl . Une

information chiffre avec un algorithme connu restera dchiffrable par les seuls possesseurs de la
cl approprie, mme si l'algorithme est connu de tous. Les cls de chiffrement sont donc les
lments essentiels dans la garantie du secret souhait. Une fois le procd mis en place, quelques
services peuvent tre fournis.
4.1.3.1

Confidentialit

L'usage auquel on pense en premier est naturellement la confidentialit des donnes. Le


premier dsir est bien que les messages ne soient lisibles que par les seules personnes autorises,
mais c'est loin de suffire, pour assurer une totale relation de confiance. Il faut un contrle dintgrit
et une authentification pralables des interlocuteurs.

49

4.1.3.2

Contrle d'intgrit et authentification


4.1.3.2.1

Intgrit

Dans certains cas, il peut tre ncessaire d'assurer simplement que les donnes sont intgres,
c'est dire qu'elles n'ont pas t au passage falsifies par un intrus. Ces donnes restent claires ,
au sens o elles ne sont pas secrtes.
Un exemple simple serait le cas du partage en tlchargement dun fichier contenant
une

application informatique. Lauteur voulant viter la dnaturation de son application par

injection post-conception de code nuisible, tout en rendant le code source de lapplication, sous
licences GPL, accessible au grand public , ralise un rsum concis du fichier, typiquement une
somme MD5 ou SHA suffisamment prcise pour mettre en vidence toute modification ultrieure
du fichier (ces deux techniques de hachage sont expliques dans lannexe A.4). Mais sans
prcautions supplmentaires, cela ne sera pas une protection infaillible, dans la mesure o celui qui
corrompt le fichier en tlchargement, peut sans doute modifier aussi l'empreinte, pour qu'elle soit
celle du fichier corrompu. Il faudra donc trouver en plus, un moyen pour certifier l'authenticit de
cette empreinte.
4.1.3.2.2

Authentification

Il s'agit d'apporter par la cryptographie la preuve que le message est bien authentique.
Compte tenu de ce que nous venons de voir, il suffira dans la plupart des cas de pouvoir assurer que
l'auteur de l'empreinte du message est bien celui qu'il prtend tre. Il s'agit en quelque sorte
d'une lettre manuscrite, non rature et signe. Cela permet aussi dassurer la non-rpudiation. En
effet, celui qui a rdig une lettre manuscrite, non rature et signe de sa main, ne pourra en
aucun cas prtendre par la suite qu'il n'en est pas l'auteur ; il en va de mme pour l'authentification
numrique faite au moyen de cls numriques et dalgorithmes soigneusement conus.
4.1.3.2.2.1 Les cls, leurs types et leurs utilits
Il y a deux types de cls :
1. les cls dites symtriques, on chiffre et dchiffre avec la mme cl.
2. les cls dites asymtriques, avec une cl publique et une cl prive, ce qui est chiffr avec
l'une ne peut tre dchiffr qu'avec l'autre. Les deux cls sont uniques et sont lies
l'une l'autre ; mais si la cl prive est confidentielle, la cl publique peut, quant
elle, tre copie volont.

50

Il s'agit en fait d'un abus de langage. Les cls ne sont pas symtriques ni asymtriques, ce
sont les procds de chiffrement qui le sont.
4.1.3.2.2.2 Chiffrement symtrique
C'est le plus facile comprendre , c'est aussi la mthode de chiffrement la plus facile
raliser et qui consomme le moins de ressources de calcul et de bande passante.
Les deux htes qui doivent changer des donnes confidentielles disposent tous les deux
d'une cl identique. L'metteur chiffre les donnes avec cette cl, puis les envoie au rcepteur. Ce
dernier dchiffre avec la mme cl pour rcuprer des donnes lisibles.
Cette mthode assure la confidentialit des donnes car quiconque intercepterait la
communication ne pourrait pas lire les donnes changes tant qu'il ne se serrait pas procurer la
cl. Il n'y a aucune authentification de faite sur l'metteur comme sur le rcepteur, sauf si deux
personnes seulement disposent de la cl. Le principal souci avec cette mthode, c'est qu'il faut
s'changer la cl et lors de cet change, sans prcautions particulires, n'importe quoi peut se
produire. Un exemple de cette technique cryptographique est le chiffrement WEP (Wired
Equivalent Privacy) utilis dans les rseaux WI-FI o seuls les terminaux disposant de la cl WEP
peuvent avoir accs au rseau sans fil.
4.1.3.2.2.3 Chiffrement asymtrique
Cette mthode permet de faire aussi bien l'authentification que la confidentialit des
donnes. Il est videmment possible de combiner les deux. Chaque personne dispose d'un jeu de
cls comportant :
1. une cl prive : elle est unique et confidentielle, elle appartient exclusivement l'hte
concern, aucun double de cette cl ne doit tre cr,
2. une cl publique : elle est unique galement, mais tout le monde peut s'en procurer une
copie, il suffit d'aller la chercher chez un dpositaire, dit tiers de confiance . Il s'agit en
quelque sorte d'un concierge qui garde ces cls publiques et certifie qu'elles appartiennent
bien la personne indique,
Ce qui est chiffr avec une cl publique ne peut tre dchiffr qu'avec la cl
prive correspondante et rciproquement. Cette technique permet deffectuer une authentification
efficace entre un nombre lev dinterlocuteurs lorsque le chiffrement se fait avec la cl prive et
non le contraire. En effet, lorsquun message chiffr est dchiffr avec une cl publique, il ne peut
avoir t chiffr quavec la cl prive de celui qui appartient cette cl publique ; et comme
lunicit des cls est assure dans le systme, le tour est bien jou.
51

Il existe dans le monde plusieurs organismes but lucratif qui fournissent les services
dautorit de certification (Certification Authority (CA), en Anglais). Lorsque lon s'adresse un tel
organisme pour rcuprer une cl publique, il l'envoi avec un certificat. Il s'agit, pour ledit
organisme, de chiffrer la cl publique demande, ainsi que quelques informations supplmentaires
sur le propritaire de cette cl, avec sa propre cl prive, pour authentifier son envoi. Il ne reste
plus qu disposer de la cl publique de cet organisme dit tiers de confiance, par un moyen sr pour
dchiffrer le message et rcuprer la cl envoye. Les certificats sont la norme X.509. Par
exemple, les navigateurs installent, gnralement linsu de linternaute,

des

certificats

de

divers organismes de certification, sur son ordinateur. Voyons le cas de Mozilla Firefox :
Outils Options Avanc Chiffrement Afficher les certificats

Figure 4.4.a : Exemple de certificat numrique sous Mozilla Firefox


Voici un rsum du contenu d'un certificat (remarquons la prsence dune cl publique sur la
figure Figure 4.4.c) :

52

Figure 4.4.b : Contenu dun certificat numrique

Figure 4.4.c : Exemple de cl publique dans un certificat numrique

53

Le volume de donnes chiffres laide dune cl prive devenant trop important avec le
temps, les chances de dcouverte de cette cl par un intrus augmente significativement, do la
ncessit de prvoir une dure de vie cette cl et donc au certificat. Comme une cl peut se perdre
ou tre vole, il faudra aussi prvoir un systme d'opposition , une liste de rvocation, qui permet
de signaler les certificats non encore expirs, mais qui ne sont plus dignes de confiance pour une
raison quelconque. Le CA se doit donc de tenir jour une liste de rvocation, et, lorsqu'un
utilisateur doit user d'un certificat qui est dj en sa possession, il devrait commencer par vrifier si
celui-ci n'a pas t rvoqu entre temps.
4.2

Modlisation de lapplication
La modlisation consiste crer une reprsentation virtuelle d'une ralit de faon faire

ressortir les points auxquels on s'intresse. Elle a lavantage indubitable de simplifier la conception
de logiciel en la rendant assez rationnelle. Il existe plusieurs mthodes de modlisation dont UML
que nous utilisons pour modliser lapplication au moyen de diagrammes de cas dutilisation, de
squence, dactivit et de dploiement.
4.2.1 Expression des besoins
Lobservation du systme oprant (le processus daffectation en sixime et dorientation en
seconde et le processus dattribution et de renouvellement de bourses en Cte dIvoire) et lchange
avec des personnes ressources, nous ont permis de dfinir les besoins ventuels que pourrait
manifester un utilisateur de la plateforme et de procder leur modlisation pour la conception dun
systme informatique convenable et fiable.
Lexpression des besoins sest faite laide de loutil danalyse et de modlisation UML
comme lillustre la figure 4.5. Ce diagramme de cas dutilisation nous permet de prsenter les
besoins de manire graphique pour faciliter leur tude. Nous en dduisons quatre (04) acteurs
principaux sur notre systme ; savoir IEP, ETABLISSEMENT, DOB et ADMINISTRATEUR.
Ces diffrents acteurs utilisent le systme pour effectuer des actions qui influencent la CNO
et la CNB :
1. IEP et ETABLISSEMENT ont la charge de remplir la fiche informatique des candidats aux
diffrents examens. Il sagit de renseigner la base de donnes laide du masque de saisie
offert par le logiciel.
2. DOB se charge de fusionner les donnes transmises par les structures loignes et gre
toutes les oprations utiles la tnue de la CNO et de la CNB. Il peut aussi excuter les
actions de tous les autres acteurs.
54

3. ADMINISTRATEUR

quant

lui

effectue

les

configurations

ncessaires

au

fonctionnement du systme informatique. Il peut exister un ou plusieurs administrateurs


dans chaque structure concerne par le dploiement de lapplication.
Tous les acteurs ont la possibilit dimprimer des tats relatifs leurs activits sur le systme.
Toutefois, laccs au systme nest possible quaprs identification et authentification de lacteur.
APPLIDOB est le nom de lapplication conue.

Appl icati on de gestion automati se des trav aux de la CNO et CN B

IEP

Enregis trer lves et notes

Conf igurer s yst me


Admini st rat eur
<< i nc lude >>
<< i nc lude >>

Etablis sement

S'identif ier et s 'aut hent ifier

<< i nc lude >>

Attribuer et renouveler bours es


<< i nc lude >>

Faire affec tations -orient ati ons


DOB

Figure 4.5 : Diagramme UML des cas dutilisation dAPPLIDOB


4.2.2 Algorithmes de rsolution des besoins
Le paragraphe prcdent nous montre les diffrents besoins combler. Ainsi, nous
constatons bien quune base de donnes savre indispensable dans la conception de la plateforme
demande.
Le concepteur de base de donnes a la possibilit dinterroger cette dernire en ligne de
commande. Nanmoins, la plupart des SGBD modernes offre une interface graphique pour
ladministration de ces bases de donnes. Mais, lutilisation de ces interfaces ncessite une
connaissance informatique plus ou moins pousse. Il savre alors ncessaire de crer une interface
adapte au systme que lon cherche modliser. Cette interface doit tre la plus simple possible
pour permettre lutilisateur moyen dutiliser la base de donnes sans grands efforts. Certains

55

SGBDR modernes tels que Microsoft Access, HyperFileSQL de PC SOFT, offrent la possibilit
de crer des formulaires personnaliss.
En outre, la base de donnes, ayant la vocation de desservir toutes sortes dapplications dans
des domaines varis, les concepteurs de SGBD mettent la disposition des dveloppeurs de
logiciels des interfaces appropries pour faire communiquer leurs applications et la base de
donnes, gnralement dans une architecture distribue de type client/serveur.

Figure 4.6 : Procdure de communication avec une base de donnes dans une architecture distribue
de type client/serveur
4.2.2.1 Connexion au systme
La scurit et la confidentialit des donnes, indispensables au systme qui nous est soumis,
nous amnent dfinir une mthode particulire de connexion lapplication. Le droulement des
oprations est prsent sur le diagramme de squence de la figure 4.7.
Lutilisateur demande la connexion au systme en soumettant au serveur un formulaire
contenant son identifiant et son mot de passe. Le serveur interroge la base de donnes pour
identifier et authentifier cet utilisateur. Il est important de prciser que les mots de passe sont
crypts au sein de la base de donnes, ce qui renforce la scurit du systme. Si lauthentification
est positive, une connexion la base de donnes est ouverte pendant la dure de la session, sinon le

56

formulaire dauthentification est raffich. Lutilisateur correctement identifi et authentifi a accs


aux interfaces associes son profile. En effet le serveur de base de donnes transmet les donnes
du profil de lutilisateur lapplication en vue de lui adapter linterface affiche.

Appl icati on (AP PLIDOB)

Serveur de bas e de donnes

Base de donnes

Uti lis ateur

FormaterRequte (Identifiant, Pass word)


Exci terRequte (Identifi ant, Pas sword)
DonnerInfo (Identifiant, Pass word)

Recevoi rInfo ()

Recevoi rInfoIntgre ()
Choi sirOpration ()

Figure 4.7 : Diagramme UML de squence relatif la connexion au systme


4.2.2.2 Ajout dinformation
Le systme oprant est dynamique. Cela est pleinement visible travers les diverses
oprations comme lenregistrement des candidats dans la base de donnes, lenregistrement des
diffrentes notes, la prcision des barres dadmission ; il en dcoule un dynamisme inluctable de
notre systme informatique afin de traduire textuellement le systme oprant. Ces oprations de
mise jour de la base de donnes se font selon une logique unique : Aprs lindentification et
lauthentification de lutilisateur, les informations fournies par ce dernier sont testes pour voir si
toutes les informations obligatoires ont t fournies. Le SGBD HyperFileSQL se charge de vrifier
automatiquement les rgles dintgrits exiges par la structure de la base de donnes. Si toutes les
rgles sont respectes, la base de donnes est mise jour, sinon un message derreur adquat est
affich pour aider la correction des erreurs.

57

Appl icati on (AP PLIDOB)

Serveur de bas e de donnes

Base de donnes

Uti lis ateur

FormaterRequteMA J (paramtres )
ExcuterRequteMA J (paramtres )

SauvegarderInfo (paramtres )

Recevoi rEtatMA J ()
Recevoi rEtatMA JIntgre ()
Recevoi rEtatMA JFormater ()

Figure 4.8 : Diagramme UML de squence relatif la mise jour de la BD


4.2.2.3 Consultation
La consultation du systme est ralisable par tout utilisateur authentifi. Il sagit de la
recherche dinformation de divers ordres (affichage dtats en gnral). Tout cela se fait sous lil
vigilant du serveur qui ne peut permettre lutilisateur de visualiser des donnes non associes
son profile.

Appl icati on (A PPLIDOB)

Serveur de bas e de donnes

Base de donnes

Uti lis ateur

FormaterRequte (paramtres )
ExcuterRequte (paramtres )

DonnerInfo (paramtres)

Recevoi rInfo ()
Recevoi rInfoIntgre ()
Recevoi rInfoFormater ()

Figure 4.9 : Diagramme UML de squence relatif la consultation dinformation

58

4.2.2.4 Algorithme daffectation et dorientation automatiques


4.2.2.4.1 Algorithme daffectation automatique en sixime
Lalgorithme implment pour effectuer laffectation automatique en sixime se prsente
comme suit : premirement, on dtermine tous les lves affectables, cest--dire tous les candidats
dont le TGP et lAGE sont respectivement suprieur ou gal au TGP minimum et infrieur ou gal
lAGE maximum fixs par le MEN (Dautres critres peuvent tre spcifis par le MEN). Ensuite,
ce rsultat subit un classement par ordre dcroissant des TGP. Les candidats, sont successivement
affects selon leurs vux dtablissements. Si un candidat na pas pu tre affect dans son vu de
prdilection pour cause de saturation des effectifs, le processus est rpt pour son vu de niveau
immdiatement infrieur, jusqu puisement ventuel des trois (03) vux (Le nouveau systme
prvoit dix (10) vux maximum). Dans ce dernier cas, lon considre un tablissement proche de la
localit du candidat qui nest pas encore satur et ly affecte. Une liste des candidats affects hors
de leurs vux est dlivre par le programme pour les oprations post affectation automatique.
4.2.2.4.2 Algorithme dorientation automatique en seconde
Pour lorientation en seconde, plusieurs algorithmes ont t proposs. Nanmoins, la base de
tous ces algorithmes est pratiquement identique celle de laffection en sixime, la seule grande
diffrence quen plus des tablissements, les candidats formulent des vux de sries. Par
consquent, la vrification de la disponibilit de places se fait sur le quota des sries : Si la srie
demande par le candidat dans son tablissement de prdilection est dj sature, on ritre le mme
processus pour le vu dtablissement suivant. A lpuisement infructueux de tous les vux
dtablissements du candidat, on considre un tablissement proche de sa localit qui nest pas
encore satur et on ly oriente. La barre pour lorientation en seconde est fixe par rapport la
Moyenne dOrientation (MO) par le MEN. Il est aussi important de prciser que laccs une srie
obit des critres de profil. En effet, lorsque le candidat affectable a une MO infrieure douze
(12) (une autre moyenne pourra tre utilise) sur vingt (20) (sinon, il est absolument affect dans sa
srie de prdilection), un calcul de moyenne de profil est fait. Il sagit du profil Littraire avec les
moyennes en Anglais et Franais (dautres matires pourront tre prises en compte), et du profil
Scientifique comprenant les moyennes de Mathmatiques et Sciences Physiques (dautres matires
pourront tre prises en compte). La moyenne de profil la plus leve dfinit la srie attribuer au
candidat. Toutefois, la liste des candidats orients de cette manire est fournie pour facilit
dventuelles prises de dcision. Le diagramme ci-dessous prsente les grandes lignes de
lalgorithme de base dans les deux cas (affectation et orientation).
59

Figure 4.10 : Diagramme UML dactivit relatif laffectation automatique en sixime et


lorientation automatique en seconde
60

4.3

Modlisation de la base de donnes

Une base de donnes est une collection dinformations ou de donnes structures qui
qualifient les activits dune organisation appele systme oprant. Ces donnes doivent pouvoir
tre utilises par des programmes et par des utilisateurs diffrents

[8]

. Un serveur est un quipement

ou une application disposant de services quil met la disposition dautres systmes appels clients.
Dans cette section, nous allons nous pencher essentiellement sur la modlisation de la base de
donnes, lment cl du projet. La modlisation est faite selon le formalisme entit-association avec
les notations de Merise. Un modle est une reprsentation simplifie de la ralit. Un modle de
donnes est une reprsentation abstraite des donnes dun systme dinformation. Une entit est un
objet concret ou abstrait du monde rel au sujet duquel une organisation est susceptible de
conserver des donnes (Entity en Anglais). Une association est un lien smantique qui existe entre
deux entits ou plus. Elle reprsente souvent la mmoire dun vnement qui a permis dtablir un
lien logique entre ces entits (Relationship en Anglais)

[9]

4.3.1 Le Modle Conceptuel de Donnes (MCD)


Un MCD (Conceptual Data Model en Anglais) est une reprsentation des besoins en matire
de donnes pour un systme dinformation. Il met en vidence les entits, leurs attributs, les
associations et contraintes entre ces entits pour un domaine donn. Cette reprsentation, de nature
smantique, ne comporte aucune indication concernant la structure de mmorisation des donnes
associes aux entits

[10]

Pour effectuer une modlisation efficiente, nous avons subdivis notre systme en huit (08)
sous-systmes relativement indpendants. Il sagit des sous-systmes :
1. Identification qui concerne les informations qui permettent didentifier et de localiser un
candidat,
2. Evaluation notes qui prend en compte les diffrentes notes des candidats,
3. Evaluation cadres qui dfinit les cadres dvaluation des candidats,
4. Vux qui contient les vux dtablissements et de sries des candidats
5. Authentification pour lauthentification des donnes transmises par CD,
6. Bourses pour les donnes relatives la bourse.
7. Cartographie pour linterconnexion des diffrentes structures,
8. Collaboration pour les informations relatives aux diffrents collaborateurs.
Les diffrents MCD sont prsents dans lannexe A.1.

61

4.3.2 Le Modle Logique de Donnes Relationnel (MLDR)


Maintenant que le MCD est tabli (voir lannexe A.1 pour les rgles de normalisation), on
peut le traduire en diffrents systmes logiques et notamment les bases de donnes relationnelles
qui proposent une vision plus concrte pour modliser la situation. Cela se fait par passage au
MLDR. Un MLD (Logical Data Model en Anglais) est un modle de donnes dcoulant dun
modle conceptuel mais qui le raffine pour tenir compte des caractristiques du type de SGBD
utilis pour la ralisation de la base de donnes

[11]

. Toutefois cette mutation se fait selon des

rgles qui sont spcifies dans lannexe A.3.


4.3.3 Le Modle Physique de Donnes (MPD)
Un MPD (Physical Data Model en Anglais) est un modle de donnes dcoulant dun
modle logique qui spcifie les dtails dimplantation du modle logique dans un SGBD,
habituellement formuls grce un script de dfinition de donnes

[12]

. Pour la ralisation de la

plateforme, nous avons trouv avantageux dutiliser une base de donnes HyperFileSQL tant
donn que la DOB dispose dj de la licence dutilisation de WINDEV. Le mode client/serveur est
utilis, contrairement ce qui se faisait dj, pour suivre larchitecture dj expose dans les parties
prcdentes ; savoir larchitecture distribue de type client/serveur chelle rduite. Quelques
informations sur les performances dHyperFileSQL sont donnes dans lannexe A.6.

62

TROISIEME PARTIE : DEPLOIEMENT DE LA SOLUTION

Cette dernire partie du mmoire expose les diffrentes techniques mettre en uvre pour
dployer le nouveau systme informatique et profiter pleinement de ses fonctionnalits.

63

CHAPITRE 5 : DEPLOIEMENT MATERIEL

CHAPITRE 5 : DEPLOIEMENT MATERIEL


Le matriel, cest lensemble des quipements physiques utiliss dans un systme
informatique. Ltude technique nous a permis, dans le chapitre 3, de dfinir une architecture
optimale pour le projet qui nous a t soumis : larchitecture distribue de type client/serveur
chelle rduite. Mais, pour atteindre lobjectif fix, les quipements doivent tre de bonne qualit
tend bien au niveau de la robustesse physique, de la puissance daction, quau niveau de leur
aptitude tre interconnects.
5.1 Pour le service informatique de la DOB
Le SIS est le nud central du processus automatis menant aux diffrentes commissions
nationales. Il a la charge de fdrer toutes les donnes issues des autres sites dans une base de
donnes commune, en vue deffectuer un traitement global. Il est par consquent vident que les
caractristiques du matriel utilis ce niveau doivent obir aux normes internationales de
systme dinformation de la taille du systme trait.
Les capacits sont spcifies au prorata de leffectif annuel moyen de candidats (environ
trois cent mille (300.000)).
5.1.1 Nuds de larchitecture
Les nuds, ce sont le ou les serveurs de base de
donnes et les ordinateurs clients qui interagissent avec la base
de donnes via le rseau local.
Pour ce qui est du serveur, il faudrait pour une
rentabilit optimale, utiliser un serveur de grande capacit
mmoire (au moins cinq cents Giga-octets (500 Go)). Laccs

Figure 5.1 : Serveur de base de

disque doit tre trs rapide. Il doit surtout avoir une trs grande

donnes

mmoire vive (RAM, Random Access Memory) (huit Gigaoctets (08 Go) pourrait suffire), et un ou plusieurs processeurs
rapides (plus de quatre Gigahertz (04 GHz)), pour lexcution
simultane de requtes et procdures stockes.
Nanmoins, des ordinateurs personnels entirement
ddis, pourront jouer ( lextrme), en partie, le rle de
serveur, pour minimiser le cot de ralisation. Les ordinateurs
serveurs devraient avoir les caractristiques minimales Figure 5.2 : Ordinateur personnel

64

CHAPITRE 5 : DEPLOIEMENT MATERIEL

suivantes :
>

Deux Giga-octets (02 Go) de RAM

>

Deux Gigahertz (02 GHz) de vitesse de processeur

>

Un disque dur de plus de cent Giga-octets (100 Go)


pour stocker les donnes au cours des annes.
5.1.2 Equipements dinterconnexion
Les quipements dinterconnexion sont

lensemble des lments matriels utiliss pour


interconnecter les diffrents nuds ; ce sont les
lments de base dun rseau informatique. Il y
a ncessit davoir au moins :
>

Du cble paire torsade de catgorie


cinq (05) (non) blind (UTP/STP 5,
Unshielded

Twisted

Twisted

Pair),

comme

lien

Pair/Shielded

correctement
dinterconnexion

Figure 5.3 : Cble paires torsades


blind

serti,
des

nuds,
>

Un switch (avec dix (10) ports Ethernet)


comme concentrateur,

>

Figure 5.4 : Switch Dlink 24 Ports

Une carte rseau Ethernet fonctionnelle


par nud.

Figure 5.5 : Carte rseau Ethernet - RJ45

5.2 Pour les services informatiques des structures loignes


Les structures loignes (IEP, ETABLISSSEMENTS) qui ont droit au logiciel, pourront,
dans la mesure du possible, implmenter la mme architecture que celle qui a t dfinie pour le
SIS. Nanmoins, pour minimiser les cots de ralisation, il est possible, comme nous lavons
spcifi dans le paragraphe 3.3.2, de ramener le rseau entier un seul ordinateur. En effet tout
65

CHAPITRE 5 : DEPLOIEMENT MATERIEL

ordinateur sur lequel est install un systme dexploitation valide et fonctionnel, est en rseau avec
lui-mme : ce rseau sappelle boucle locale (local loop, en Anglais). Dans ce rseau, lordinateur
est identifi par ladresse universelle 127.0.0.1 ou le nom localhost. Cette solution monoposte
prsentera bien sr linconvnient majeur de ne permettre que des oprations squentielles. On ne
pourra, en effet, pas faire de vritable contrle pendant la saisie de donnes. En plus, et pire,
plusieurs oprateurs de saisies ne pourront pas travailler simultanment sur la mme base de
donnes ; ce qui augmentera surement le temps de saisie de donnes.
Si ces structures veulent garder larchitecture rseau, elles pourront utiliser, comme serveur,
un ordinateur personnel de plus de deux (02) Giga-octets de RAM et de plus de deux (02)
Gigahertz de vitesse de processeur. Un disque dur de plus de cent (100) Giga-octets sera parfait
pour stocker les donnes au cours des annes. Les ordinateurs clients nont pas ncessairement
besoin davoir des caractristiques impressionnantes : cinq-cent-douze (512) Kilo-octets de RAM et
un (01) Gigahertz de vitesse de processeur. La taille du disque dur est sans importance. Nanmoins,
il faudra un minimum de dix (10) Mga-octets libre sur le disque pour stocker les informations
temporaires gnres par le logiciel.
5.3 Scurit matrielle
La scurit matrielle concerne essentiellement tout ce qui contribue, dune part, garder les
quipements hors de la porte de personnes malveillantes, et dautre part la protection contre les
variations de niveaux dalimentation en lectricit.
5.3.1 Protection contre les vols
Dans une socit, o la criminalit est sans cesse galopante, des personnes mal intentionnes
ne se gneraient pas dpouiller une structures publique de son patrimoine informatique ; raison
pour laquelle, diffrentes mesures de scurits doivent tre mise en uvre en guise de prvention
contre les vols. Les quipements devront tre installs dans des salles closes. En outre, laccs ces
salles devra tre interdit aux personnes trangres au service en charge du systme. Enfin, les portes
et les fentres devront tre recouvertes de grilles mtalliques protectrices.
5.3.2 Protection contre les pannes lectriques
La Cte dIvoire a connu environ cinq (05) mois de crise dlectricit en 2011 donnant lieu
des temps de dlestage, plus ou moins nuisibles aux systmes de production base dlectricit. De
cette exprience nous gardons la leon de la ncessit de se procurer des onduleurs capables
dallonger la fourniture dlectricit pendant un temps suffisant pour teindre convenablement tous

66

CHAPITRE 5 : DEPLOIEMENT MATERIEL

les quipements du systme matriel, voire pour continuer le travail entam. En effet, les
ordinateurs, ntant, en gnral, pas quips de batterie, ils nont aucune autonomie propre en
lectricit et toute rupture de la fourniture en lectricit de loprateur national dlectricit entrane
automatiquement larrt des quipements. Cela peut sans doute occasionner des pertes
dinformation, voire des pannes au niveau du matriel. Par ailleurs, les diffrentes structures
pourront mme se procurer des groupes lectrognes pour ne pas entirement dpendre de
loprateur national dlectricit.
Les salles serveur devront tre dotes dquipements de conditionnement dair
fonctionnels, pour rguler la temprature un maximum de vingt-cinq degr Celsius (25C), en vue
protger les composants lectroniques contre la surchauffe.

67

CHAPITRE 6 : DEPLOIEMENT LOGICIEL

CHAPITRE 6 : DEPLOIEMENT LOGICIEL


Dans le chapitre prcdent, nous avons dfini les diffrents lments matriels fournir pour
rentabiliser le systme de production. Cependant, nous sommes sans ignorer quen informatique, le
matriel sans le logiciel est dune vile utilit. Cest pourquoi nous dtaillons dans ce chapitre, la
rpartition des diffrents composants logiciels conus sur larchitecture matrielle prcdemment
prsente.
6.1 Pour le service informatique de la DOB
Nous avons dvelopp une application de base de donnes, cest--dire une application qui
exige lexistence dune base de donnes pour fonctionner. La base de donnes devra tre dploye
sur les diffrents serveurs matriels (ou ordinateurs jouant le rle de serveur). Il faudra au pralable
installer sur ces serveurs physiques le logiciel serveur HyperFileSQL Client/Serveur de PC SOFT,
compatible avec la plus rcente version de WINDEV (Version 16).
Une fois la base de donnes correctement dploye, il faudra installer lapplication cliente
sur les ordinateurs clients. Aucun pr requis logiciel nest exig sauf quil faudra disposer dun
systme dexploitation issu du monde Microsoft (Microsoft XP, VISTA ou SEVEN). En effet, tous
les lments logiciels ncessaires la bonne marche de lapplication seront incorpors aux
composants dinstallation et seront automatiquement installs linsertion du CD-ROM
dinstallation.
6.2 Pour les services informatiques des structures loignes
Les structures loignes suivront les mmes procdures de dploiement logiciel que ce qui a
t dfini pour le SIS. Toutefois, dans le cas o le rseau est ramen un seul ordinateur, le logiciel
serveur pourra tre dploy sur le mme ordinateur que lapplication cliente.
6.3 Scurit logicielle
Parler de scurit dans un systme dinformation numrique, revient sans doute parler de
la ncessit dempcher laccs frauduleux des donnes sensibles par des programmes
malveillants. En effet, de la mme manire quune personne mal intentionne peut dpouiller une
structure de son patrimoine informatique, un programme habilement conu peut effectuer des
oprations nuisibles au systme dinformation. Un des problmes de scurit gnralement
rencontr dans les systmes dinformation est linjection de code SQL dans la base de donnes des
fins despionnage ou de sabotage. Mais, daprs PC SOFT (Concepteur de HyperFileSQL),
linjection de code SQL est impossible avec les bases de donnes HyperFileSQL (Voir Annexe
68

CHAPITRE 6 : DEPLOIEMENT LOGICIEL

A.6). Loin de nous fixer dfinitivement sur cette assertion, nous avons implment des mcanismes
de scurit qui exigent lidentification et lauthentification de toute personne qui accde la base de
donnes. Tout utilisateur devra fournir un identifiant et un mot de passe avant de pouvoir accder
la base de donnes, voire avant dutiliser lapplication. Les utilisateurs ne sont crs que par le
super-utilisateur qui est lutilisateur par dfaut linstallation du logiciel. Ce dernier pourra
accorder des droits ou en rvoquer tout utilisateur. La journalisation dans HyperFileSQL pourra
nous aider dterminer automatiquement toute action non autorise et prendre les dcisions
idoines pour ne pas saper la CNO et la CNB. Enfin, le hachage et un mcanisme dauthentification
cls asymtrique nous permettront dassurer lintgrit et lauthenticit des donnes transportes
par CD.

69

CONCLUSION
La quasi-totalit des organismes de ce 21ime sicle fonctionne avec un systme
dinformation informatis. La Direction de lOrientation et des Bourses (DOB), ne voulant pas
rester en marge de cette avance technologique, a mis en place un systme dinformation
automatis pour grer ses activits depuis 2005. Mais les applications conues prsentent certaines
faiblesses qui obrent la qualit des rsultats issus des diffrentes commissions nationales. Cest ce
qui a justifi notre prsence au sein du Service Informatique et Statistiques (SIS) de la DOB, o
nous avons travaill la mise en place dun nouveau systme dinformation pour la gestion des
travaux de la Commission Nationale dOrientation (CNO) et de la Commission Nationale des
Bourses (CNB). Il sagissait pour nous de concevoir, laide de lAGL WINDEV, un systme qui
rsout les problmes rencontrs par les applications existantes.
Pour nous convaincre de la ncessit de rnover ce systme informatique, nous en avons
effectu une tude dtaille. Cette tude nous a permis de dceler une gamme de failles au niveau
matriel, logiciel et de la main duvre qui ont rsolu nos doutes. En outre, anims du souci
permanent de concevoir un systme qui obit aux normes internationales de conception de
systme dinformation, nous avons procd la modlisation du systme global au moyen de
concepts divers comme UML, Merise et lOrient Objet. Bien que le dveloppement du logiciel
nait pas atteint sa phase finale, du fait du retard dacquisition de la licence dutilisation de lAGL
WINDEV et de collaboration du SIS, nous avons expliqu le dploiement matriel et logiciel du
systme global, tout en spcifiant les techniques scuritaires implmenter.
Ce stage nous a permis, en plus de la matrise de lAGL WINDEV, de mettre en application
nos connaissances en matire de conception de systme dinformation. Encore mieux, nous en
avons tir lavantage de tisser des relations durables avec certains acteurs du systme ducatif
ivoirien.
Nanmoins, nous ne pouvons pas nous arrter en si bon chemin, car larchitecture distribue
de type client/serveur chelle rduite adopte prsente des inconvnients hrits de larchitecture
monoposte, quil faudra rsoudre dans un futur proche, en ltendant lchelle nationale. Encore,
faudrait-il que toutes les structures (SIS, IEP, CIO, ETABLISSEMENTS) aient des quipements
informatiques de bonne qualit et une bonne formation pour exploiter pleinement ce nouveau
systme dinformation.

70

REFERENCES WEBOGRAPHIQUES
[1]

TETY Pierre, Ingnieur Tlcoms & Rseaux de l'INP-HB | Prsentation de la Filire,

<http://membres.multimania.fr/lenetwork/Pages/presentation.php>, consulte le 13 Juillet 2011


09h40
[2]

DECO, Historique, < http://deco.ci/historique.php>, consulte le 17 Aout 2011 09h26

[15]

Wikipedia, MD5, <http://fr.wikipedia.org/wiki/MD5>, consulte le 16 Aot 2011 10h43

[16]

Wikipedia, SHA-1, <http://fr.wikipedia.org/wiki/SHA-1>, consulte le 16 Aot 2011 10h50

[17]

PC SOFT, HyperFileSQL, <http://blogs.pcsoft.fr/rss.awp?blog=hyperfilesql_performances>,

consulte le 19 Juillet 2011 11h37

REFERENCES BIBLIOGRAPHIQUES
[3] [6] [9] [10]

et [11] Gilles ROY, 2009. Conception de bases de donnes avec UML, Presses de

LUniversit du Qubec, P 8, P14, PP33, 32, 144.


[4]

Guy Pujolle, 2008, Les Rseaux, EYROLLES, P 15

[5]

Le Grand Robert de la langue franaise, 2005, version 2.0, mot-cl : contrainte

[6]

Gilles ROY, 2009. Conception de bases de donnes avec UML, Presses de LUniversit du

Qubec, P 14
[7]
[8]

Claude Delannoy, 5ime dition, Programmer en Java, EYROLLES, P 6


Cours de M. KOFFI Luc, Enseignant lINP-HB

[12] [13]

et [14] Cyril GRUAU, 2006. Conception dune base de donnes, PP 10-14, 15, 24-26

71

ANNEXES

A.1 Les rgles de normalisation dun MCD ................................................................................. lxxiii


A.2 Rsultats de latelier danalyse diagnostique et de validation des applications de gestion des
actes de la CNO et de la CNB ....................................................................................................... lxxiii
A.3 Les rgles de traduction dun MCD en MLDR ................................................................... lxxxvii
A.4 Linterface Homme-Machine (IHM) dAPPLIDOB .......................................................... lxxxviii
A.5 Techniques de Hachage .............................................................................................................xcii
A.6 HyperFileSQL .......................................................................................................................... xcvi

ANNEXES

A.1 Les rgles de normalisation dun MCD

[12]

1. Normalisation des entits : toutes les entits qui sont remplaables par une association
doivent tre remplaces.
2. Normalisation des noms : le nom dune entit, dune association ou dun attribut doit tre
unique.
3. Normalisation des identifiants : chaque entit doit possder un identifiant.
4. Normalisation des attributs : remplacer les attributs en plusieurs exemplaires en une
association supplmentaire de cardinalit maximales n et ne pas ajouter dattribut calculable
partir dautres attributs.
5. Normalisation des attributs des associations : les attributs dune association doivent
dpendre directement des identifiants de toutes les entits en association.
6. Normalisation des associations : il faut liminer les associations fantmes (associations
ayant des cardinalits de type 1-1), redondantes ou en plusieurs exemplaires.
7. Normalisation des cardinalits : une cardinalit minimale est toujours 0 ou 1 (et pas 2, 3, ou
n) et une cardinalit maximale est toujours 1 ou n (pas 2, 3).
A.1.1 Les formes normales

[13]

1. Premire forme normale : un instant donn dans une entit, pour un individu, un attribut ne
peut prendre quune valeur et non pas un ensemble ou liste de valeurs.
NB : Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire lobjet dune
entit supplmentaire, en association avec la premire.
2. Deuxime forme normale : lidentifiant peut tre compos de plusieurs attributs mais les
autres attributs de lentit doivent dpendre de lidentifiant en entier (et non pas une partie
de cet identifiant).
3. Troisime forme normale de Boyce-Codd : tous les attributs dune entit doivent dpendre
directement de son identifiant et daucun autre attribut.
A.2 Rsultats de latelier danalyse diagnostique et de validation des applications de gestion
des actes de la CNO et de la CNB
Dans le souci de rduire au strict minimum le travail manuel, de fiabiliser les rsultats de la
CNO et rduire le temps de travail, un logiciel de slection et daffectation automatique, a t conu
et mis en application depuis lanne 2005. Aprs six ans de mise en uvre du logiciel, un atelier
regroupant les experts de lINP-HB, les responsables et les informaticiens de la DOB a t organis

lxxiii

ANNEXES

du 27 juin au 1er juillet 2011 en vue dexaminer et proposer

les amliorations idoines

de

lapplication existante.
Pour mener bien ces travaux latelier sest dabord attel cerner toute la procdure de la
CNO depuis les travaux prparatoires jusquaux travaux post CNO afin de comprendre et de
matriser toutes les phases et les mcanismes de fonctionnement. Ensuite, latelier sest vertu
modliser tous les actes de la CNO pour sassurer de la prise en compte de tous les lments
indispensables par lapplication existante. Enfin, des recommandations ont t faites tant au niveau
informatique, des quipements ncessaires quau plan administratif en vue dapporter des
amliorations. Cette section des annexes rend compte des rsultats obtenus et des recommandations
faites.
A.2.1 Pour la sixime
Oprateur

1000 Centre d'examen (Dlibration)

Oprateur

1000 Centre d'examen (Dlibration)

Collecter les notes (Notes classe + notes examen)

IEP

Collecter les notes (Notes classe + notes examen)

IEP

Remplir la fiche informatique (PV)

IEP

IEP
Remplir le PV manuellement (Relev de notes)
calculer les TGP (manuel)

IEP

Saisir les notes

IEP

reporter les TGP sur les fiches d'affectation (manuel)

IEP

Contrler les donnes saisies

IEP

Classer les fiches par ordre de mrite (manuel)

IEP

Traiter les donnes

IEP

Etablir les tats cumulatifs (manuel)

IEP

Editions

Etablir la liste des admis

IEP

IEP
des TGP

IEP

des Etats
Remplir les relevs de notes individuels

IEP

statistiques (A dfinir)

IEP
des Etats

cumulatifs

IEP
de la Liste

des admis
Production de CD

2000 IEP D'ORIGINE


Rceptionner les fiches d'affectation

2000 IEP D'ORIGINE


IEP

Rceptionner les listes des admis

IEP

Rceptionner la fiche
Rceptionner les PV d'examen

IEP

Rceptionner les tats cumulatifs


vrifier les documents ci-dessus

informatique (PV)

IEP

IEP

Rceptionner les ditions :

IEP

des TGP

IEP
IEP

des Etats
Proclamer les rsultats

IEP

statistiques (A dfinir)

IEP
des Etats

enregistrer les demandes de rclamation

IEP

cumulatifs

IEP
de la Liste

jury spcial

IEP

Etablir l'tat cumulatif de l'inspection

IEP

des admis

IEP
Rceptionner le CD

contrle des CD
correction des

vrifier les documents ci-dessus

donnes

lxxiv

ANNEXES

Proclamer les rsultats

fusion

enregistrer les demandes de


rclamation
jury spcial

3000 Direction rgionale (DREN)

3000 Direction rgionale (DREN)


Rceptionner la fiche informatique

Rceptionner les fiches d'affectation

DREN

(PV)

DREN
Rceptionner les tats cumulatifs des

Rceptionner les PV

DREN

IEP

DREN
vrifier les documents ci-dessus

Rceptionner les tats cumulatifs des IEP

DREN

vrifier les documents ci-dessus rceptionns

DREN

rceptionns
Etablir l'tat cumulatif rgional

DREN
DREN

Etablir l'tat cumulatif rgional

DREN

Transmettre au CIO

DREN

Transmettre au CIO

DREN

un exemplaire de chaque PV
un exemplaire de l'tat

les fiches d'affectation

cumulatif de chaque IEP

un exemplaire de chaque PV d'examen

cumulatif de la DREN

un exemplaire de l'tat

un exemplaire de l'tat cumulatif de chaque IEP


un exemplaire de l'tat cumulatif de la DREN

Directeur CIO

Directeur CIO
rceptionner les documents

rceptionner les documents transmis

CIO

vrifier les documents transmis

CIO

transmettre la DOB les documents vrifis

CIO

transmis

CIO
vrifier les documents transmis

CIO

transmettre la DOB les

4000 DOB

documents ci-dessus vrifis

CIO

4000 DOB

Rceptionner

DOB

Rceptionner
les PV

les fiches d'affectation

d'admission

les PV d'examen

cumulatifs des IEP

les tats

les tats
les tats cumulatifs des IEP

cumulatifs des DREN

l es tats cumulatifs des DREN

Vrifier
les PV

Vrifier

DOB

d'admission
les tats

les fiches d'affectation

cumulatifs des IEP

les PV d'examen

cumulatifs des DREN

les tats

les tats cumulatifs des IEP

Editer les tats

lxxv

ANNEXES

l'tat cumulatif
les tats cumulatifs des DREN

national
les statistiques des

Saisir des TGP

DOB

admis

Contrler

DOB

DREN /DDEN d'origine

corriger

DOB

IEP d'origine

Traiter

DOB

ordre de mrite

DOB

DREN /DDEN d'origine par IEP d'origine

par

par

les listes des admis par

par
Editer les tats
l'tat cumulatif national
les statistiques des admis
par DREN /DDEN d'origine
par IEP d'origine
les listes des admis par ordre de mrite
par DREN /DDEN d'origine par IEP
d'origine

A.2.2 Pour la seconde


1000 Collecte des donnes (Etablissement)

Oprateur

Etablissement fournisseur
Recueillir

Oprateur

1000 Collecte des donnes (Etablissement)


Etablissement fournisseur

Chef d'etab

Recueillir

1 les notes de classe spcifiques

Chef d'etab
1 les notes de classe

l'orientation

spcifiques l'orientation

2 les effectifs des candidats

2 les effectifs des

l'orientation

candidats l'orientation

3 les vux

3 les vux
4 la langue Vivante 2

4 la langue Vivante 2 (LV2)

(LV2)

Saisir des notes par trimestre

Chef d'etab

Saisir des notes par trimestre

Chef d'etab

Saisir des vux

Chef d'etab

Saisir des vux

Chef d'etab

Produire un CD

Chef d'etab

Produire un CD

Chef d'etab

Etablissement d'accueil
Recueillir

Etablissement d'accueil
Chef d'etab

Recueillir

Chef d'etab
1 les capacits d'accueil

1 les capacits d'accueil (tenir compte des sries A et C)

(tenir compte des sries A et C)


du

du Priv

SAPEP

Priv

SAPEP
du

du Public

Chef d'etab

Public

2 les pyramides

Chef d'etab
2 les pyramides
3 la Langue

3 la Langue Vivante 2 (LV2)

Vivante 2 (LV2)

lxxvi

ANNEXES

A.2.3 Recommandations
Au terme des changes, les recommandations suivantes ont t arrtes :

Au plan administratif
Que la DOB et les directions partenaires (DIPES, DECO, DRH, SAPEP)

saccordent sur les points suivants:


1. avoir une base de donnes commune ;
2. tous les candidats lentre en sixime soient saisis et suivis ;
3. tous les lves de CM2 soient immatriculs ;
4. les IEP soient sensibilises pour que les TGP soient saisis dans tous les centres de
corrections.

Au plan matriel, logiciel et humain

Que la DOB soit dote :


1. dun rseau local performant et scuris quip dun serveur de grande capacit
2. dun rseau tendu performant et scuris reliant les autres localits (CIO, IEP,
DREN)
3. Un systme dexploitation robuste et un gestionnaire de base de donnes adquat,
4. dune quipe pour la mise en uvre et le suivi.

Au plan des critres de slection et daffectation


Pour les affectations :
1. Augmenter le nombre de vux dtablissements distincts (de 3 10)
2. Prendre en compte le lieu de rsidence de llve et faire le rapprochement avec
les structures daccueil de la zone qui nont pas encore fait le plein de leur
capacit
3. Pour chaque IEP, rpertorier les tablissements secondaires daccueil
Pour les critres de slections en seconde A et C :
Calculer la moyenne de profil en appliquant les coefficients suivants :
Profil scientifique

Profil littraire

Matire

Coefficient

Matire

Coefficient

Composition Franaise

Composition Franaise

Anglais

Anglais

Mathmatiques

Mathmatiques

Sciences Physiques

Sciences Physiques

lxxvii

ANNEXES

1. Privilgier le vu de filire exprim par le candidat lorsque les deux (2) moyennes de profil
sont suprieures ou gales 12 sur 20
2. Choisir automatiquement la srie correspondant au profil lorsque les deux (2) moyennes de
profil sont infrieures 12 (moyenne la plus leve du profil)
3. Choisir automatiquement la srie correspondant au profil lorsque lune des moyennes est
suprieure ou gale 12

code

Au plan des documents de travail

appelation
Fiche d'affectation (Fiche
informatique)

niveau

6me

Listing d'margement

6me

Liste gnrale

6me

Liste gnrale des admis

6me

Tableau statistique

6me

Liste des admis affects

6me

Tableau statistique des


affects

6me

description
...sert collecter les informations
produites par la DECO
utilis pour le contrle de prsence des
candidats

utilisateur
ELEVE
IEP

remplir
collecter pour la saisie
valider les rsultats

ELEVE

emmarger

DOB

traiter

par ordre de mrite, sert dterminer la


barre d'admission

comment a s'utilise

dterminer la barre
DOB

d'admission

par DREN/DDEN et IEP d'origine et par


ordre de mrite
par DREN/DDEN et IEP d'origine et par
sexe, sert de statistiques de dpart
par tablissement d'accueil et par ordre
de mrite
par tablissement d'accueil

DOB
DOB

DOB

DOB

dcider des capacits


d'accueil au priv
contrler le respect des
quotas
vrifier les taux d'occupation
des quotas

A.2.4 Le MCD dAPPLIDOB


Le nom APPLIDOB est celui donn lapplication que nous avons dveloppe pour
lautomatisation des travaux de la CNO et de la CNB. Dans ce qui suit, nous exposons les diffrents
MCD conus, lments de base de la base de donnes, et donc de lapplication. Comme dit dans le
paragraphe 4.3.1, nous avons huit (08) sous systmes dont lobjectif majeur est de permettre une
meilleure analyse par zoom sur les diffrents points focaux du systme oprant. Il sagit des soussystmes Indentification, Evaluation Cadre, Evaluation Notes, Vux, Authentification, Bourses,
Cartographie et Collaboration.
Le logiciel qui a t utilis pour llaboration du MCD est WINDESIGN (Version 7).

lxxviii

ANNEXES

Le sous-systme Identification prsente principalement les informations relatives


lidentification de llve, matire premire du systme dinformation concevoir. Il sagit des
informations lies dun ct son identit propre : nom, prnoms, genre ; et dautre part sa
filiation et sa localisation gographique : parents, quartier

Figure A.1 : MCD du sous-systme Indentification

lxxix

ANNEXES

Quant au sous-systme Evaluation Cadre, il dcrit clairement lenvironnement de formation


et dvaluation de llve, ainsi que les diffrentes barres dadmission utiles lautomatisation des
oprations daffectation, dorientation, de redoublement, dattribution et renouvellement de
bourse

Figure A.2 : MCD du sous-systme Evaluation Cadre

lxxx

ANNEXES

Comme son nom lvoque, le sous-systme Evaluation Notes a pour objectif de modliser les
diffrentes notes obtenues par llve aux valuations subies. Il y a aussi des informations ncessaires
ldition des donnes daide la dtermination des diffrentes barres dadmission, ainsi que les
coefficients des diffrentes moyennes. Certaines moyennes, trop utilises dans les algorithmes, sont
mmorises, bien quelles soient des valeurs calcules. Toutefois, des procdures stockes
dclenchement automatique sont actionnes pour recalculer les moyennes qui utilisent une note
donne, aprs toute modification de cette dernire.

Figure A.3 : MCD du sous-systme Evaluation Notes


lxxxi

ANNEXES

Le sous-systme Vux prsente les vux dtablissements et de sries effectus par les
candidats lentre en sixime et en seconde. Il permet aussi de sauvegarder les affectationsorientations ralises pour optimiser les ventuelles consultations.

Figure A.4 : MCD du sous-systme Vux

lxxxii

ANNEXES

Ici, au niveau du sous-systme Authentification, les diffrentes cls (mots de passe) utilises
par les diffrentes structures intervenant sur le systme oprant sont mmorises (de manire
crypte bien sr). En effet, comme expliqu dans le paragraphe 4.1.3, un mcanisme de chiffrement
cls asymtrique a t choisi pour chiffrer les donnes transmises par CD et par la mme occasion
authentifier la source des donnes inscrites sur le CD.

Figure A.5 : MCD du sous-systme Authentification

lxxxiii

ANNEXES

Le sous-systme Bourse sauvegarde les donnes relatives lattribution et au


renouvellement de bourse.

Figure A.6 : MCD du sous-systme Bourses

lxxxiv

ANNEXES

Le sous-systme Cartographie prsente linterconnexion gographique des infrastructures


influenant lautomatisation des affectations-orientations. Lexistence de ce sous-systme se justifie
par le fait quun des algorithmes daffection-orientation automatique demande que le candidat
affectable/orientable qui na t retenu dans aucun de ses vux, soit automatiquement
affect/orient dans un tablissement proche de son lieu dhabitation.

Figure A.7 : MCD du sous-systme Cartographie

lxxxv

ANNEXES

Un point trs important pour le systme dinformation conu est la scurit des donnes.
Cela implique que les diffrents utilisateurs de lapplication soient correctement identifis et
authentifis chaque connexion au systme. Ce sous-systme Collaboration permet de mmoriser
les donnes utiles ce principe scuritaire.

Figure A.8 : MCD du sous-systme Collaboration

lxxxvi

ANNEXES

A.3 Les rgles de traduction dun MCD en MLDR

[14]

Pour traduire un MCD en MLDR, il suffit dappliquer cinq rgles.


Notations : on dit quune association binaire (entre deux entits ou rflexive) est de type :
>

1 : 1 (un un) si aucune des deux cardinalits maximales nest n ;

>

1 : n (un plusieurs) si une des deux cardinalits maximales est n ;

>

n : m (plusieurs plusieurs) si les deux cardinalits maximales sont n.

1. Toute entit devient une table dans laquelle les attributs deviennent les colonnes.
Lidentifiant de lentit constitue alors la cl primaire de la table.
2. Une association binaire de type 1 : n disparait, au profit dune cl trangre dans la
table ct 0-1 ou ct 1-1 qui rfrence la cl primaire de lautre table. Cette cl
trangre ne peut pas recevoir la valeur vide si la cardinalit est 1-1.
3. Une association binaire de type n : m devient une table supplmentaire (parfois
appele table de jonction, table de jointure ou table dassociation) dont la cl
primaire est compose de deux cls trangres (qui rfrencent les deux cls
primaires des deux tables en association). Les attributs de lassociation deviennent
des colonnes de cette nouvelle table.
4. Une association binaire de type 1 : 1 est traduite comme une association binaire de
type 1 : n sauf que la cl trangre se voit imposer une contrainte dunicit en plus
dune ventuelle contrainte de non vacuit (cette contrainte dunicit impose la
colonne de ne prendre que des valeurs distinctes).
5. Une association non binaire est traduite par une table supplmentaire dont la cl
primaire est compose dautant de cls trangres que dentits en association. Les
attributs de lassociation deviennent des colonnes de cette nouvelle table.

lxxxvii

ANNEXES

A.4 Linterface Homme-Machine (IHM) dAPPLIDOB

Figure A.17 : Arborescence des structures dans APPLIDOB

Figure A.18 : Table de dtail dans APPLIDOB


lxxxviii

ANNEXES

Figure A.19 : Formulaire denregistrement dlve de troisime Onglet Identification

Figure A.20 : Formulaire denregistrement dlve de troisime Onglet Evaluation

lxxxix

ANNEXES

Figure A.21 : Formulaire denregistrement dlve de troisime Onglet Orientation

Figure A.22 : Formulaire denregistrement dlve de CM2 Onglet Identification

xc

ANNEXES

Figure A.23 : Formulaire denregistrement dlve de CM2 Onglet Evaluation

Figure A.24 : Formulaire denregistrement dlve de CM2 Onglet Affectation


xci

ANNEXES

A.5 Techniques de Hachage


A.5.1 Message Digest 5 (MD5)

[15]

MD5 (Message Digest 5) est


une

fonction

de

hachage

cryptographique qui calcule, partir


d'un fichier numrique, son empreinte
numrique

(en

l'occurrence

une

squence de 128 bits ou 32 caractres


en notation hexadcimale) avec une
probabilit trs forte que deux fichiers
diffrents donnent deux empreintes
diffrentes.

En 1991, Ronald Rivest,

cryptographe

amricain,

amliore

l'architecture de MD4 pour contrer des


attaques

potentielles

qui

seront

confirmes plus tard par les travaux de


Hans Dobbertin.
Figure A.25 : Vue gnrale de MD5
Cinq ans plus tard, en 1996, une faille qualifie de grave (possibilit de crer des collisions
(situation dans laquelle deux donnes ont un rsultat identique avec la mme fonction de hachage)
la demande) est dcouverte et indique que MD5 devrait tre mis de ct au profit de fonctions plus
robustes comme SHA-1.
En 2004, une quipe chinoise dcouvre des collisions compltes. MD5

n'est

donc

plus

considr comme sr au sens cryptographique. On suggre maintenant d'utiliser plutt des


algorithmes tels que SHA-256, RIPEMD-160 ou Whirlpool. Cependant, la fonction MD5 reste
encore largement utilise comme outil de vrification lors des tlchargements et l'utilisateur peut
valider l'intgrit de la version tlcharge grce l'empreinte. Ceci peut se faire avec un
programme comme md5sum. MD5 peut aussi tre utilis pour calculer l'empreinte d'un mot de
passe ; c'est le systme employ dans GNU/Linux avec la prsence d'un sel (donne particulire
inject dans une fonction de hachage, dans le but de compliquer la dtermination de la donne
hache) compliquant le dcryptage. Ainsi, plutt que de stocker les mots de passe dans un fichier,
xcii

ANNEXES

ce sont leurs empreintes MD5 qui sont enregistres, de sorte que quelqu'un qui lirait ce fichier ne
puisse pas dcouvrir les mots de passe. La commande enable secret des commutateurs et routeurs
Cisco, utilise le hachage MD5 pour stocker le mot de passe du mode privilgi dans le fichier de
configuration de lquipement.
A.5.1.1 Algorithme
MD5 comprend 64 blocs de ce type
(voir figure ci-contre), groups en quatre
tours de 16 oprations. F est une fonction
non-linaire, qui varie selon le tour. Mi
symbolise un bloc de 32 bits provenant du
message hacher et Ki est une constante de
32 bits, diffrentes pour chaque opration.
Notation
>

<<<s est une rotation de s bits vers la


gauche,

varie

pour

chaque

opration.
>

+ symbolise l'addition modulo 232.

>

symbolisent
respectivement

les

oprations

boolennes XOR, AND, OR et NOT.

Figure A.26 : Une opration de MD5

A.5.1.2 Prparation du message


MD5 travaille avec un message de taille variable et produit une empreinte de 128 bits. Le
message est divis en blocs de 512 bits, on applique un remplissage de manire avoir un message
dont la longueur est un multiple de 512. Le remplissage se prsente comme suit :
1.

on ajoute un '1' la fin du message

2.

on ajoute une squence de '0' (le nombre de zros dpend de la longueur du remplissage
ncessaire)

3.

on crit la taille du message, un entier cod sur 64 bits


Ce remplissage est toujours appliqu, mme si la longueur du message peut tre divise par

512. Cette mthode de padding est semblable celle utilise dans la plupart des algorithmes de
xciii

ANNEXES

Message Digest des familles MD (comme MD5 ou RIPEMD) ou SHA (SHA-1 ou SHA-512) mais
diffrente de celle de l'algorithme Tiger qui utilise une convention dite Little endian
d'ordonnancement des bits dans chaque octet. La taille du message est code en Little endian. Le
message a maintenant une taille en bits multiple de 512, c'est--dire qu'il contient un multiple de 16
mots de 32 bits.
A.5.1.3 Boucle principale
L'algorithme principal travaille avec un tat sur 128 bits. Il est lui-mme divis en 4 mots de
32 bits : A, B, C et D. Ils sont initialiss au dbut avec des constantes. L'algorithme utilise ensuite
les blocs provenant du message hacher, ces blocs vont modifier l'tat interne. Les oprations sur
un bloc se dcomposent en quatre rondes (tapes), elles-mmes subdivises en 16 oprations
similaires bases sur une fonction non-linaire F qui varie selon la ronde, une addition et une
rotation vers la gauche. Les quatre fonctions non-linaires disponibles sont :

A.5.2 Secure Hash Algorithm (SHA)

[16]

SHA-1 (Secure Hash Algorithm) est une fonction de hachage cryptographique conue par la
National Security Agency des tats-Unis (NSA), et publie par le gouvernement des tats-Unis
comme un standard fdral de traitement de l'information (Federal Information Processing Standard
du National Institute of Standards and Technology (NIST)). Elle produit un rsultat (appel hash
ou condensat) de 160 bits.
A.5.2.1 Fonctionnement du SHA-1
Le SHA-1 prend un message d'un maximum de 264 bits en entre. Son fonctionnement est
similaire celui du MD4 ou MD5 de Ronald Rivest. Quatre fonctions boolennes sont dfinies,
elles prennent 3 mots de 32 bits en entre et calculent un mot de 32 bits. Une fonction spcifique de
rotation est galement disponible, elle permet de dplacer les bits vers la gauche (le mouvement est
circulaire et les bits reviennent droite).

xciv

ANNEXES

Une de ces rotations n'tait pas


prsente dans le SHA-0, elle permet de
casser certaines caractristiques linaires
dans la structure. Cela permet d'viter une
attaque sur les bits neutres dcrite par Eli
Biham, technique reprise pour calculer la
collision complte sur SHA-0.

Deux rotations vers la gauche et une fonction


non-linaire qui dpend du numro d'itration,
deux autres variables interviennent chaque
tour.
Figure A.27 : Une itration de SHA-1

Le SHA-1 commence par ajouter la fin du message un bit 1 suivi d'une srie de bits 0,
puis la longueur du message initial (en bits) code sur 64 bits. La srie de 0 a une longueur telle que
la squence ainsi prolonge a une longueur multiple de 512 bits. L'algorithme travaille ensuite
successivement sur des blocs de 512 bits. Pour chaque bloc, l'algorithme calcule 80 tours (ou
rondes, rounds en anglais) successifs et applique une srie de transformations sur l'entre. La
premire tape consiste calculer 80 valeurs sur 32 bits. Les 16 premires valeurs sont obtenues
directement partir du bloc message en entre. Les 64 autres sont calcules successivement. Le
SHA-1 les obtient grce une rotation (absente dans SHA-0) qui est applique sur le rsultat d'un
XOR, il utilise pour cela 4 mots obtenus dans les itrations prcdentes. On dfinit ensuite 5
variables qui sont initialises avec des constantes (spcifies par le standard), le SHA-1 utilise
encore 4 autres constantes dans ses calculs. Si un bloc de 512 bits a dj t calcul auparavant, les
variables sont initialises avec les valeurs obtenues la fin du calcul sur le bloc prcdent. Il
s'ensuit 80 tours qui alternent des rotations, des additions entre les variables et les constantes. Selon
le numro du tour, le SHA-1 utilise une des quatre fonctions boolennes. L'une de ces fonctions est
applique sur 3 des 5 variables disponibles. Les variables sont mises jour pour le tour suivant
grce des permutations et une rotation. En rsum, le SHA-1 change sa mthode de calcul tous les
20 tours et utilise les sorties des tours prcdents. A la fin des 80 tours, on additionne le rsultat
avec le vecteur initial. Lorsque tous les blocs ont t traits, les cinq variables concatnes (5 32 =
160 bits) reprsentent la signature.

xcv

ANNEXES

A.6 HyperFileSQL

[17]

HyperFileSQL est un SGBD relationnel cr par PC SOFT. Il est principalement utilis dans
lenvironnement WINDEV ; mais il peut tre interrog avec des langages comme PHP, Java, C#...,
des interfaces logicielles ayant t conues cet effet par ses auteurs. Les lignes qui suivent
prsentent certaines de ses fonctionnalits. Nanmoins, une connaissance pralable de la
terminologie de base est indispensable pour la comprhension des ides dispenses (Voir le
glossaire pour Analyse, Fichier, WLangage ) .
A.6.1 Optimiser le temps de lancement des applications, en vitant une ouverture
systmatique de tous les fichiers de la base.
L'ouverture d'un fichier de donnes au niveau du systme d'exploitation est coteuse en
temps. En effet, le systme doit mettre en place bon nombre de mcanismes pour assurer par la suite
les entres/sorties (allocation, partage rseau, cache ...).
Pour optimiser le lancement des applications, il est donc dconseill d'effectuer une ouverture
systmatique de tous les fichiers en appelant l'une des fonctions suivantes :
HOuvre("*") ou HCrationSiInexistant("*"). Pour cela le moteur HyperFileSQL est dot d'un
mcanisme d'ouverture automatique des fichiers. Il permet ds le premier accs un fichier,
d'effectuer son ouverture si elle n'a pas dj t faite. Le temps ncessaire aux ouvertures des
fichiers est ainsi rparti tout au long de l'application, plutt qu'en une seule fois au lancement. La
fonction HPasse permet si besoin de spcifier le mot de passe des fichiers pour le mcanisme
d'ouverture automatique. Le gain peut tre de plusieurs secondes dans une application ayant des
centaines de fichier.
Autre avantage de ce mcanisme, seuls les fichiers effectivement utiliss sont ouverts,
limitant ainsi les ressources ncessaires sur le serveur de donnes.
Ce mcanisme d'ouverture automatique est disponible pour HyperFileSQL Client/Serveur
mais galement pour HyperFileSQL Classic.
Astuce :
Il est recommand de cocher l'option suivante dans le projet, afin de s'assurer d'avoir en plus
de l'ouverture automatique des fichiers, leur cration automatique :
1. menu "Projet ... Description du projet",
2. volet "Fichiers",
3. cocher "Crer automatiquement les fichiers de donnes".

xcvi

ANNEXES

Cette solution vite de conserver dans le programme l'appel suivant, pour les prochains
ajouts de fichiers de donnes dans la base : HCrationSiInexistant("*", hOuvertureDiffre)
A.6.2 Suivi des requtes et traitements du moteur HyperFileSQL Client/Serveur
Le moteur HyperFileSQL Client/Serveur dispose de mcanismes de "log" et de suivi
d'activit. Ils permettent d'avoir trs prcisment sur une priode donne, toutes les actions
commandes par les diffrents utilisateurs connects aux bases de donnes.
Il est donc vivement recommand
d'activer ces mcanismes sur le serveur :
1. ils n'ont pas d'incidence notable sur
les performances,
2. il suffit pour les activer de se
connecter au serveur via le centre de
contrle HyperFileSQL (Voir figure
ci-contre)
Une fois l'activation faite, il suffit
toujours

dans

le

centre

de

contrle

HyperFileSQL d'utiliser le volet "Logs et


Statistiques" pour accder de nombreuses
informations primordiales notamment en
phase de mise au point, et d'optimisation :
1. les requtes les plus longues,
2. les appels les plus longs,
3. les requtes les plus utilises (pour
optimiser en priorit les traitements
les plus courants),
4. la liste des commandes appeles (par
exemple

vrifier

les

Figure A.28 : Centre de contrle HyperFileSQL

paramtres

reus par une requte d'un utilisateur


qui n'a pas le rsultat attendu),

L'ensemble de ces possibilits permet de rpondre toutes les interrogations pouvant


survenir en exploitation :
1. le dimensionnement du rseau est-il suffisant ?
xcvii

ANNEXES

>

Les statistiques d'activits montrent le volume des demandes.

2. le dimensionnement du serveur est-il suffisant ?


>

Les statistiques d'activits montrent l'utilisation de la RAM et du CPU sur le serveur.

3. un rsultat ne semble pas conforme ?


>

Les logs permettent de vrifier les demandes reues.

4. un arrt inattendu du moteur survient, ou une erreur du journal des vnements de Windows
remonte ?
>

Les logs permettent de voir la demande, ou l'enchainement de traitements l'origine.

Ces possibilits de suivi s'appliquent pour toutes les connexions gres par le moteur
HyperFileSQL Client/Serveur, qu'elles proviennent des stations du rseau local, ou de postes
connects par Internet.
A.6.3 Les ports ncessaires l'utilisation de HyperFileSQL Cluster
L'accs aux donnes d'un Cluster (groupe de serveurs ayant les mmes ressources afin de
partager la charge du serveur au client : le client est redirig vers le serveur le plus disponible) se
fait en donnant un nom DNS de Cluster, un utilisateur et un port de communication. Par exemple
dans la connexion :

[Code WLangage]

Cluster_Support est une Connexion


Cluster_Support..Provider = hAccsHFClientServeur
Cluster_Support..Utilisateur = "admin"
Cluster_Support..MotDePasse = ""
Cluster_Support..Serveur = "Cluster_Support:49015"
Cluster_Support..BaseDeDonnes = "CRM"
HOuvreConnexion(Cluster_Support)
HChangeConnexion("*",Cluster_Support)
HCrationSiInexistant("*")

"Cluster_Support" correspond au nom DNS du Cluster, et 49015 correspond au port de


communication utiliser. Ce port est paramtrable lors de l'installation du Cluster (4900 par
dfaut). Il est donc ncessaire que le rseau autorise les communications sur ce port, en faisant si

xcviii

ANNEXES

besoin le ncessaire au niveau du Firewall. Ce principe est strictement identique celui en place
pour HyperFileSQL Client/Serveur.
Pour permettre toutes les communications
requises par le Cluster, il est galement
ncessaire d'ouvrir les ports :
> TCP/UDP

4997

pour

la

communication avec le coordinateur


(ClusterManager),
> TCP 4998 pour la communication
entre les noeuds du Cluster,
> TCP/UDP 4999 traditionnel pour la
gestion

des

(MantaManager),

serveurs
Figure A.29 : Les ports ncessaires l'utilisation de
HyperFileSQL Cluster

A.6.4 Synchronisation automatique de plusieurs serveurs de donnes HyperFileSQL


Client/Serveur
La version Cluster de HyperFileSQL est disponible, permettant d'obtenir une
synchronisation en temps rel d'une "ferme de serveurs". L'utilisation d'un Cluster offre de
nombreux intrts :
1. Haute disponibilit,
2. Rpartition de charge,
3. Resynchronisation automatique des nuds dfaillants,
4. Modification dynamique de la structure du cluster ...
Une prsentation complte de HyperFileSQL Cluster est disponible sur le site d'aide en
ligne.
Il faut souligner que l'exploitation des donnes en Cluster ne ncessite aucune
transformation des donnes existantes (pas de modification automatique). Les applications doivent
simplement modifier leur paramtre de connexion, afin de spcifier non plus l'adresse d'un serveur
hbergeant le moteur HyperFileSQL Client/Serveur, mais le nom du Cluster.
Le pack d'installation spcifique de HyperFileSQL Cluster est disponible gratuitement pour
tout dtenteur de licence commerciale en version 15. Il suffit d'en effectuer la demande au Support

xcix

ANNEXES

Technique Gratuit par le menu "? ... Requte au Support Technique" de WINDEV, WEBDEV et
WINDEV Mobile.

A.6.5 Placer le moteur HyperFileSQL Client/Serveur sur une machine virtualise


La virtualisation est de plus en plus frquemment retenue pour le dploiement d'applications.
Il n'y a aucune contre-indication l'utilisation d'un systme virtualis pour installer le moteur
HyperFileSQL Client/Serveur utilis par vos applications WINDEV, WINDEV Mobile, ou vos
sites WEBDEV. D'autre part, vous n'avez aucune programmation particulire faire. En effet pour
vos applications, et pour le moteur HyperFileSQL Client/Serveur, le fait que le systme
d'exploitation soit sur une machine virtuelle n'a aucune incidence : votre programmation ou votre
mthode d'installation reste la mme. Il faut en revanche bien vrifier le dimensionnement et la
configuration utilise pour la virtualisation. Voici les points principaux vrifier, tout manquement
de l'un d'entre eux peut provoquer une chute de performances importante.
1. Mmoire vive :
Il est important de supprimer tout risque de "swap" disque, prjudiciable aux performances.
Il est donc capital d'avoir pour la machine virtuelle suffisamment de mmoire. Il faut donc bien
compter la mmoire ncessaire :
>

au systme d'exploitation hte,

>

au systme d'exploitation de la machine virtuelle ou des machines virtuelles,

>

celle utilise par le moteur HyperFileSQL Client/Serveur,

>

celle utilise par d'autres applications...

Pour dmarrer, il faut compter 1,5 Go de plus que pour la mme installation sur un serveur
non virtualis. Par exemple si habituellement le dploiement se fait sur un serveur non virtualis
dot de 4 Go (1 pour le systme, 1,5 pour le moteur HyperFileSQL Client/Serveur, le reste pour
d'autres applications), il faut prvoir au minimum 5,5 Go.
2. Accs disque :
C'est le point le plus important, un moteur de base de donnes devant par dfinition faire de
trs nombreux entres/sorties disques. Il faut imprativement choisir une configuration dans
laquelle le systme invit de la machine virtuelle dispose d'un disque physique entier qui lui est
ddi. Il ne faut pas que la machine virtuelle travaille sur un espace disque rserv de systme hte.
3. Carte rseau :
La bande passante de la carte rseau est partage entre les machines virtuelles. Il faut donc
vrifier avec les logs du moteur HyperFileSQL Client/Serveur, que le dbit sera suffisant pour les
besoins des applications hberges. Sur ce point, il est le plus souvent recommand d'avoir
c

ANNEXES

plusieurs cartes rseaux, afin que la machine virtuelle qui hberge le serveur dispose de sa propre
carte et donc de toute la bande passante disponible.
4. Processeur :
Les processeurs privilgier sont ceux disposant de fonctionnalits matrielles ddies la
virtualisation : Intel-VT (Virtual Technology) ou AMD-V.
A.6.6 Protger vos bases de donnes du piratage par injection de code SQL
L'injection de code SQL est une technique de piratage de base de donnes consistant
injecter du code SQL dans les paramtres de requtes, forant ainsi l'excution de code SQL non
dsir. Lorsque vous utilisez WINDEV, WEBDEV ou WINDEV Mobile, utilisez toujours des
objets requtes. L'objet requte de WINDEV, WEBDEV ou WINDEV Mobile traite les paramtres
de requtes comme des valeurs de recherche et jamais comme du code SQL. L'excution vrifie par
ailleurs le type et la taille des valeurs saisies. Ce qui rend impossible l'injection de code SQL et
limine de nombreux risques de piratage.
A.6.7 Accder une base HyperFileSQL Client/Serveur par Internet
Selon votre configuration par rapport un accs local la base de donnes vous allez avoir
principalement trois (03) " portes " vrifier pour pouvoir accder votre base travers Internet :
Rappel : le choix du type de base HyperFileSQL Client/Serveur s'impose pour les raisons suivantes:
> le rseau est lent (infrieur 100 Mbits)
> le rseau peut avoir des coupures intempestives
> il n'y a pas de partages rseau sur le rpertoire des donnes

ci

ANNEXES

Figure A.30 : HyperFileSQL Client/Serveur via Internet

1. Configuration de vos accs sortant du site sur lequel l'application va fonctionner


Cette tape est

inutile dans les rseaux qui n'ont pas une scurit avance. En effet

beaucoup de stratgies rseaux consistent limiter les entres tout en laissant un libre accs aux
sorties. Toutefois si vos accs sortant sont limits et/ou contrls, il s'agit gnralement de
paramtrer le pare-feu du rseau (aussi appel firewall) et ventuellement le pare-feu local du poste
si vous avez un pare-feu local actif.
2. Vrification des restrictions de votre fournisseur d'accs Internet
Il arrive parfois que les fournisseurs d'accs Internet n'autorisent l'accs qu' certains
protocoles ou certains ports. C'est gnralement le cas pour les accs Internet depuis une carte
SIM (Smartphone...). Dans ce cas contactez votre fournisseur d'accs il faut gnralement souscrire
des forfaits spcifiques du type Data ou Professionnel .

cii

ANNEXES

Parfois galement les accs sont autoriss mais dgrads, subissent des coupures afin
d'assurer une meilleur Qualit de Service (QoS) pour certains ports et protocoles. Les cas les plus
frquents sont :
>

Accs Gprs/Edge/3G/3G+

>

Accs avec une connexion non dgroupe

3. Configuration des accs entrants du site sur lequel se trouve la base HyperFileSQL
Client/Serveur
1. Configuration des pare-feu (rseau et local)
Il faut paramtrer les pare-feu pour HyperFileSQL Client/Serveur.
2. Rediriger les accs entrants vers le serveur HyperFileSQL Client/Serveur
Pour que les connexions des postes clients soient bien rediriges vers le poste sur lequel est
install HyperFileSQL Client/Serveur, il faut :
>

soit que le serveur soit directement sur Internet : modem ou box branch sur le
port USB

>

soit l'accs Internet du serveur se fait par le rseau (le plus frquent), dans ce cas
il faut configurer le " NAT " du routeur du box.

A.6.8 HyperFileSQL Client/Serveur ou Classic rseau ?


HyperFileSQL propose deux modes : classic rseau et Client/Serveur. Ces deux modes ont
des architectures de fonctionnement diffrentes adaptes des situations diffrentes. Dans tous les
cas, 95% du code est identique en mode rseau et en mode Client/Serveur, seule la localisation des
fichiers changent, leur format reste le mme. Il est donc possible de faire une application qui peut
basculer d'un mode l'autre.
Tableau A.1 : Tableau rcapitulatif du choix de base de donnes effectuer en fonction de la
situation
Base de donnes

HyperFileSQL Classic rseau

HyperFileSQL Client/Serveur

OK (conseill)

NON

Rseau local rapide

OK

OK

Intranet lent ou Internet

OK

OK

Rseau peu fiable

NON

OK

Pas de partage rseau

NON

OK

1 50 utilisateurs

NON

OK

OK si rseau trs rapide(Gbps)

OK

NON

OK

Situation

Mono-utilisateur

Plus de 50 utilisateurs
Poste poste sans serveur

ciii

ANNEXES

Base de donnes

HyperFileSQL Classic rseau

HyperFileSQL Client/Serveur

Donnes sur un NAS

OK

NON

Serveur Windows

OK

OK

Serveur Linux

OK

OK

Situation

~ (ncessite une installation, mais facile


OK

mettre en uvre)

OK en local (embarqu) uniquement

OK

Installation simplifie/minimum
Accs depuis un Mobile (Smartphone,
PocketPC...)

A.6.9 HyperFileSQL Client/Serveur communique par sockets TCP et UDP.


Les sockets sont des "tubes" de
communication entre applications (entre
processus pour tre plus prcis). Cela
permet

plusieurs

applications

(processus) de communiquer travers


un rseau TCP/IP ou sur une mme
machine.
Note : TCP/IP est le protocole d'Internet
Figure A.31 : Protocoles de communication en

et de la plus part des rseaux locaux).


Il

deux

modes

de

HyperFileSQL Client/Serveur

communication :
1. le protocole TCP qui est un mode connect, comparable une communication tlphonique.
Une connexion stable et bidirectionnelle est tablie entre les deux parties. Une fois la
connexion tablie plusieurs changes pourront tre effectus sans avoir reprciser l'adresse
avec laquelle on communique (lorsque l'on tlphone on ne fait pas le numro chaque fois
que l'on parle mais uniquement au dbut). C'est par ce moyen que les applications
WINDEV, WINDEV Mobile et les sites WEBDEV se connectent et excutent leurs
requtes.
2. le protocole UDP qui est un mode non connect, comparable une communication par
courrier. Un envoi ponctuel est fait l'adresse du destinataire , il faut donc prciser
l'adresse chaque envoi, et rien ne garantit que le destinataire reoit les donnes (comme un
courrier sans accuss de rception). C'est par ce moyen qu'il est possible de rechercher les
serveurs installs, de les arrter, les redmarrer en communiquant avec MantaManager .

civ

ANNEXES

A.6.10 Principe de fonctionnement de HyperFileSQL Client/Serveur


Lors de l'utilisation de HyperFileSQL Client/Serveur tous les accs aux donnes sont
effectus par le serveur sur lequel le moteur HyperFileSQL Client/Serveur est install. Les postes
clients envoient les ordres au serveur, le serveur les traite localement et renvoie le rsultat. Les
changes entre les clients et le serveur sont minimiss, mais la mmoire et les performances du
serveur sont fortement sollicites.

Figure A.32 : Principe de fonctionnement de HyperFileSQL Client/Serveur


En mode HyperFileSQL Client/Serveur la configuration du serveur est primordiale. La
configuration du rseau et des postes clients est moins importante, mais il ne faut toutefois pas
totalement les ngliger, car mme si elles ne peuvent pas provoquer de corruption de donnes, elles
conservent une influence sur les performances globales de l'application.
Exemple 1 : Recherche d'un enregistrement (HLitRecherche) :
a. Un ordre est envoy au serveur soit 1 aller sur le rseau
b. Le serveur traite localement les accs au fichier
c. Le serveur envoie le rsultat au poste client, soit un (01) retour sur le rseau
>

Total : un (01) aller/retour sur le rseau (il s'agit d'une explication schmatique pour
comprendre le principe, la ralit est un peu plus complexe)

Exemple 2 : Requte ou vue (HExcuteRequete) qui retourne une centaine d'enregistrements :


a. Un ordre est envoy au serveur soit un (01) aller sur le rseau
cv

ANNEXES

b. Le serveur traite localement les accs au(x) fichier(s)


c. Le serveur envoie le rsultat au poste client, soit un (01) retour sur le rseau
>

Total : un (01) aller/retour sur le rseau (il s'agit d'une explication schmatique pour
comprendre le principe, la ralit est un peu plus complexe)
A.6.11 Principe de fonctionnement de HyperFileSQL Classic rseau
Lors de l'utilisation de HyperFileSQL classic rseau, c'est la machine de l'utilisateur qui fait

tout le travail. Au niveau du serveur seuls le disque et systme d'exploitation sont sollicits. Les
changes entre les clients et le serveur sont trs nombreux, le rseau est donc fortement mis
contribution. Lors de l'utilisation de HyperFileSQL classic rseau il est donc important de s'assurer
sur le rseau est rapide.

Figure A.33 : Principe de fonctionnement de HyperFileSQL classic rseau


Les oprations de lectures et d'critures sont directement effectues par chaque poste
utilisateur, il faut donc galement s'assurer que les postes utilisateurs ont leurs systmes
d'exploitation et leurs pilotes (drivers) rseau jour. Un dysfonctionnement de l'un d'entre eux
pourrait provoquer une corruption de donnes.
Exemple 1 : Recherche d'un enregistrement (HLitRecherche):
a. Une plusieurs lectures dans l'index pour rechercher l'index spcifi, approximativement
deux (02) ou trois (03) aller/retour sur le rseau
b. Lecture de l'enregistrement correspondant dans le fichier de donnes, soit 1 aller/retour sur
le rseau
c. Lecture du mmo s'il y en a un dans le fichier mmo, soit un (01) aller/retour sur le rseau
>

Total : quatre (04) ou cinq (05) aller/retour sur le rseau (il s'agit d'une explication
schmatique pour comprendre le principe, la ralit est un peu plus complexe)

Exemple 2 : Requte ou vue (HExcuteRequete) qui retourne une centaine d'enregistrements :

cvi

ANNEXES

a. Une centaine de lectures dans l'index pour rechercher les valeurs spcifies,
approximativement cent (100) aller/retour sur le rseau
b. Lecture des enregistrements correspondants dans le fichier de donnes, soit 100 aller/retour
sur le rseau
c. Lecture du mmo s'il y en a un dans le fichier mmo, soit cent (100) aller/retour sur le rseau
>

Total : deux cents (200) ou trois cents (300) aller/retour sur le rseau (il s'agit d'une
explication schmatique pour comprendre le principe, la ralit est un peu plus complexe).

cvii

GLOSSAIRE

GLOSSAIRE

Affectation

Attribution dtablissement un candidat admis (en loccurrence lentre en


sixime).

Affectation

Affectation prioritaire dun candidat admis dans un tablissement (et/ou une

prcise

srie) lapprciation de la CNO.

Analyse

Schma de la base de donnes (Mtadonnes dfinissant la structure de la BD


et les contraintes sur celle-ci), dans le SGBDR HyperFileSQL.

Application

(Voir Logiciel)

Base de donnes

Collection de donnes structures qui qualifient les activits dune


organisation.

Cluster

Technique de redondance utilise dans HyperFileSQL Client/Serveur.


Plusieurs serveurs de BD, contenant les mmes informations, sont fdrs sous
un seul nom DNS. Ainsi, la requte du client est automatiquement et de faon
transparente, redirige vers le serveur le plus disponible lorsquil interroge ce
nom DNS.

CNB

Commission nationale tnue annuellement, au cours de laquelle sont dfinis les


bnficiaires de la bourse de lenseignement secondaire gnral.

CNO

Commission nationale tnue annuellement, au cours de laquelle sont ralises


les affectations en sixime et les orientations en seconde dans lenseignement
secondaire gnral. Les redoublants de la classe de troisime sont aussi dfinis
au cours de cette commission.

Fichier

Appellation donne une table dans le SGBDR HyperFileSQL.

Hbergeur web

Entreprise qui se charge de mettre des serveurs web la disposition des


personnes ou des entreprises pour leur permettre de dployer leur site web sur
Internet.

HTML

Format de document du web (Internet), dfini par la RFC 1866. Langage


permettant de crer ce type de document.

HTTP

Protocole de transmission ddi aux applications du web.

HyperFileSQL

SGBD relationnel conu par PC SOFT.

Internet

Interconnexion mondiale de rseaux informatiques. Internet est souvent


cviii

GLOSSAIRE

dsign par Web ou World Wide Web (www).


Logiciel

Suites dinstructions rflchies, comprhensibles par un systme informatique


et offrant des moyens de rsolution de problmes plus ou moins complexes. Un
logiciel est gnralement fourni sous forme dentit excutable.

MO

Moyenne calcule laide des moyennes annuelles et notes obtenues


lexamen du BEPC en Anglais, Composition Franaise, Mathmatiques et
Sciences Physiques dun candidat. Elle est utilise pour effectuer les
orientations et les attributions de bourses en seconde.

Modlisation

Reprsentation virtuelle et simplifie d'une ralit de faon en faire ressortir


les points auxquels on s'intresse.

Orientation

Attribution dtablissement et de srie un candidat admis (en loccurrence


lentre en seconde) conformment son profile intellectuel.

Protocole

Ensemble de rgles de communication entre entits fonctionnellement


quivalentes.

Rseau

Ensemble dordinateurs (y compris les priphriques qui y sont connects)


interconnects pour lchange de donnes.

Script

Suite dinstructions simples, peu structures, permettant dautomatiser


certaines tches.

Secteur

Activits industrielles

secondaire
Secteur tertiaire

Secteur de lconomie comprenant le commerce, les assurances, les banques,


lenseignement, etc.

Serveur

Ordinateur dtenant des ressources particulires quil met la disposition


dautres ordinateurs via un rseau. Il peut sagir dune entit fonction comme
une application.

Session

Anne acadmique.

Systme

Systme constitu des ressources humaines, des ressources informatiques

dInformation

(quipement, logiciel, donnes) et des procdures permettant dacqurir, de

(SI)

stocker, de traiter et de diffuser les lments dinformation pertinents au


fonctionnement dune entreprise ou dune organisation.

Systme de

Ensemble des acteurs dun systme oprant et des processus de gestion de ce

pilotage (SP)

systme.
cix

GLOSSAIRE

Systme oprant

Systme physique de production, qui fait lobjet dune tude informatique en

(SO)

vue dinformatiser son fonctionnement.

TGP

Total de points pondrs obtenus par un candidat lexamen du CEPE et en


classes. Le TGP est utilis pour dterminer les admis lentre en sixime et
les lves aptes pour lattribution de bourses.

UML

Langage de modlisation de troisime (03ime) gnration, normalis par


lOMG dbut 1997, permettant de dcrire une application en fonction des
mthodes objet ncessaire sa conception.

WINDEV

Atelier de Gnie Logiciel conu par PC SOFT. Il sagit dun logiciel qui
permet de crer dautres logiciels.

WLangage

Langage de cinquime gnration (L5G) utilis par WINDEV.

cx

Vous aimerez peut-être aussi