renovation du systeme informatique de gestion des travaux de la

Transcription

République de Côte d’Ivoire
Ministère de L’Enseignement Supérieur
et de la Recherche Scientifique
Union – Discipline - Travail
ESI
Ecole Supérieure d’Industrie
N° d’ordre : 05/10/ESI/ING TLC/2011
G
2
E
Direction de l’Orientation et des Bourses
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du diplôme d’ingénieur de conception
Option Télécommunications
THEME :
RENOVATION DU SYSTEME INFORMATIQUE DE
GESTION DES TRAVAUX DE LA COMMISSION
NATIONALE D’ORIENTATION (CNO) ET DE LA
COMMISSION NATIONALE DES BOURSES (CNB)
Période du stage : du 27 Juin 2011 au 27 Septembre 2011
Présenté par : KOUAKOU Kouamé Valentin,
élève ingénieur en Télécommunications
ENCADREUR PEDAGOGIQUE
M. TETY Pierre
Enseignant-chercheur à l’INP-HB
MAITRE DE STAGE
M. AYEKOE Kobon Jérôme
Directeur de l’Orientation et des Bourses
Année académique 2010 - 2011
République de Côte d’Ivoire
Ministère de L’Enseignement Supérieur
et de la Recherche Scientifique
Union – Discipline - Travail
ESI
Ecole Supérieure d’Industrie
N° d’ordre : 05/10/ESI/ING TLC/2011
G
2
E
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du diplôme d’ingénieur de conception
Option Télécommunications
THEME :
RENOVATION DU SYSTEME INFORMATIQUE DE
GESTION DES TRAVAUX DE LA COMMISSION
NATIONALE D’ORIENTATION (CNO) ET DE LA
COMMISSION NATIONALE DES BOURSES (CNB)
Période du stage : du 27 Juin 2011 au 27 Septembre 2011
Présenté par : KOUAKOU Kouamé Valentin,
élève ingénieur en Télécommunications
JURY
MEMBRES
N° 3
M. Bla Kouamé,
M. Adama Koné,
M. Edi Mousso,
Mme Siaka,
Année académique 2010 - 2011
DEDICACES
A
Dieu Tout-Puissant qui m’a accordé la santé le long de mon cursus,
L’Etat de Côte d’Ivoire 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 particulières qui ont permis la
réalisation de ce travail et grâce à qui nous sommes parvenus à la fin de notre formation. Sans être
exhaustifs, nous aimerions citer :
M. AYEKOE Kobon Jérôme, directeur de l’orientation et des bourses, notre maître de stage,
pour l’intérêt qu’il a su nous accorder et qu’il a accordé à notre travail.
Mme EHILE, sous-directrice de l’orientation et du suivi des élèves, pour sa disponibilité et
tous les efforts consentis à la fourniture des éléments nécessaires à la réalisation du projet.
Mme SEGUI, sous-directrice des bourses, pour nous avoir fourni les informations relatives
aux bourses de l’enseignement secondaire général.
M. TIECOURA Kouamé, directeur de Centre d’Information et d’Orientation (CIO), dont la
connaissance du système opérant nous a été d’une utilité indéniable.
M. KOUAKOU Marcelin, notre encadreur technique, dont l’expertise dans l’environnement
WINDEV et la collaboration nous ont été d’un apport considérable.
Tout le personnel de la Direction de l’Orientation 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 entière collaboration et leur grande
sociabilité.
M. TETY Pierre, enseignant-chercheur au DFR-GEE de l’INP-HB, notre encadreur
pédagogique, coordinateur de la filière Ingénieur Télécoms, pour sa disponibilité et tous les
efforts consentis à la mise en forme du présent mémoire.
Tout le corps professoral et administratif de l’INP-HB,
Ceux qui nous ont soutenus et continuent de nous soutenir par leurs prières et leurs pensées.
III
SOMMAIRE
INTRODUCTION .......................................................................................................................................... 13
PREMIERE PARTIE : CONTEXTE DU STAGE ET ETUDE DE L’EXISTANT ................................ 14
CHAPITRE 1 : CADRE DE REFERENCE ................................................................................................. 15
1.1
Présentation de la structure d’accueil ........................................................................................ 15
1.2
Présentation du thème de stage .................................................................................................. 17
CHAPITRE 2 : ETUDE DE L’EXISTANT ................................................................................................. 20
2.1
Description des processus d’affectation en sixième, d’orientation en seconde, d’attribution et
de renouvellement de bourses .................................................................................................................. 20
2.2
Description du système informatique de la DOB ....................................................................... 26
2.3
Nécessité d’amélioration ............................................................................................................ 27
DEUXIEME PARTIE : ETUDE TECHNIQUE ......................................................................................... 30
CHAPITRE 3 : CONCEPTION DE SYSTEME D’INFORMATION ......................................................... 31
3.1
Approche de la conception de système d’information ................................................................ 31
3.2
Proposition de solutions ............................................................................................................. 34
3.3
Choix d’une solution ................................................................................................................... 37
CHAPITRE 4 : MODELISATION DU SYSTEME D’INFORMATION .................................................... 40
4.1
Concepts généraux ..................................................................................................................... 40
4.2
Modélisation de l’application ..................................................................................................... 54
4.3
Modélisation de la base de données ........................................................................................... 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 éloignées .......................................................... 65
5.3
Sécurité matérielle ...................................................................................................................... 66
CHAPITRE 6 : DEPLOIEMENT LOGICIEL ............................................................................................. 68
6.1
Pour le service informatique de la DOB .................................................................................... 68
6.2
Pour les services informatiques des structures éloignées .......................................................... 68
6.3
Sécurité 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 d’affectation en sixième .................................................................................21
Figure 2.2 : Processus d’orientation en seconde ................................................................................23
Figure 2.3 : Processus global de gestion des bourses .........................................................................25
Figure 3.1 : Système d’Information (SI) ............................................................................................ 31
Figure 3.2 : Schéma générale d’une architecture centralisée ............................................................. 32
Figure 3.3 : Schéma générale d’une architecture décentralisée .........................................................33
Figure 3.4 : Schéma d’échange dans une architecture monoposte .....................................................34
Figure 3.5 : Architecture distribuée via internet ................................................................................36
Figure 3.6 : Architecture distribuée via un réseau étendu national ....................................................37
Figure 3.7 : Architecture distribuée dans un réseau local ..................................................................39
Figure 4.1 : Structure hiérarchique d’une base de données hiérarchique ...........................................41
Figure 4.2 : Maillage dans une base de données réseau .....................................................................41
Figure 4.3 : Cycle d'abstraction pour la conception des systèmes d'information............................... 45
Figure 4.4.a : Exemple de certificat numérique sous Mozilla Firefox ...............................................52
Figure 4.4.b : Contenu d’un certificat numérique ..............................................................................53
Figure 4.4.c : Exemple de clé publique dans un certificat numérique ...............................................53
Figure 4.5 : Diagramme UML des cas d’utilisation d’APPLIDOB ...................................................55
Figure 4.6 : Procédure de communication avec une base de données dans une architecture distribuée
de type client/serveur .........................................................................................................................56
Figure 4.7 : Diagramme UML de séquence relatif à la connexion au système ..................................57
Figure 4.8 : Diagramme UML de séquence relatif à la mise à jour de la BD ....................................58
Figure 4.9 : Diagramme UML de séquence relatif à la consultation d’information .......................... 58
Figure 4.10 : Diagramme UML d’activité relatif à l’affectation automatique en sixième et à
l’orientation automatique en seconde .................................................................................................60
Figure 5.1 : Serveur de base de données ............................................................................................ 64
Figure 5.2 : Ordinateur personnel ......................................................................................................64
Figure 5.3 : Câble à paires torsadées blindé .......................................................................................65
Figure 5.4 : Switch Dlink 24 Ports .....................................................................................................65
Figure 5.5 : Carte réseau Ethernet - RJ45 .......................................................................................... 65
Figure A.1 : MCD du sous-système Indentification ..................................................................... lxxix
LISTE DES FIGURES
Figure A.2 : MCD du sous-système Evaluation Cadre ..................................................................lxxx
Figure A.3 : MCD du sous-système Evaluation Notes ................................................................. lxxxi
Figure A.4 : MCD du sous-système Vœux ................................................................................... lxxxii
Figure A.5 : MCD du sous-système Authentification ................................................................. lxxxiii
Figure A.6 : MCD du sous-système Bourses .............................................................................. lxxxiv
Figure A.7 : MCD du sous-système Cartographie .......................................................................lxxxv
Figure A.8 : MCD du sous-système Collaboration .................................................................... lxxxvi
Figure A.17 : Arborescence des structures dans APPLIDOB ................................................... lxxxviii
Figure A.18 : Table de détail dans APPLIDOB ........................................................................ lxxxviii
Figure A.19 : Formulaire d’enregistrement d’élève de troisième – Onglet Identification .......... lxxxix
Figure A.20 : Formulaire d’enregistrement d’élève de troisième – Onglet Evaluation .............. lxxxix
Figure A.21 : Formulaire d’enregistrement d’élève de troisième – Onglet Orientation.................... xc
Figure A.22 : Formulaire d’enregistrement d’élève de CM2 – Onglet Identification ....................... xc
Figure A.23 : Formulaire d’enregistrement d’élève de CM2 – Onglet Evaluation .......................... xci
Figure A.24 : Formulaire d’enregistrement d’élève de CM2 – Onglet Affectation .......................... xci
Figure A.25 : Vue générale de MD5 ................................................................................................ xcii
Figure A.26 : Une opération de MD5 .............................................................................................xciii
Figure A.27 : Une itération de SHA-1 ............................................................................................. xcv
Figure A.28 : Centre de contrôle HyperFileSQL ...........................................................................xcvii
Figure A.29 : Les ports nécessaires à 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 réseau .................................... cvi
VI
LISTE DES TABLEAUX
Tableau 2.1 : Nombre d’enfants d’une même famille pouvant prétendre à une bourse
d’Enseignement général secondaire en fonction des ressources ........................................................24
Tableau 2.2 : Tableau récapitulatif d’attribution de bourses en 6ème..................................................25
Tableau 2.3 : Tableau récapitulatif d’attribution de bourses en 2nde ..................................................25
Tableau A.1 : Tableau récapitulatif du choix de base de données à effectuer en fonction de la
situation .............................................................................................................................................ciii
TABLE DES ABREVIATIONS
AGL
Atelier de Génie Logiciel
AOO
Analyse Orientée Objet
BEPC
Brevet d'Etude du Premier Cycle
CA
Certification Authority
CD
Compact Disc
CEPE
Certificat d'Etude Primaire et Elémentaire
CIO
Centre d’Information et d’Orientation
CNB
Commission Nationale des Bourses
CNO
Commission Nationale de l’Orientation
COO
Conception Orientée Objet
CRCMO
Commission Régionale de Calcul de Moyenne d’Orientation
DDEN
Direction Départementale de l’Education Nationale
DECO
Direction des Examens et Concours
DOB
DREN
Direction Régionale de l’Education Nationale
HTTP
HyperText Transfer Protocol
IEP
Inspection de l’Enseignement Primaire
LDD
Langage de Définition de Données
LMD
Langage de Manipulation de Données
MCD
Modèle Conceptuel de Données
MCT
Modèle Conceptuel des Traitements
MD5
Message Digest 5
MEN
Ministère de l’Education Nationale
VIII
MGA
Moyenne Générale Annelle
MLD - R
Modèle Logique de Données – Relationnel
MO
Moyenne d’Orientation
MOT
Modèle Organisationnel des Traitements
MPD
Modèle Physique de Données
POO
Programmation Orientée Objet
RAD
Rapid Application Development
SHA
Secure Harsh Algorithm
SIS
Service Informatique et Statistiques (de la DOB)
SQL
Structured Query Language
TGP
Total Général Pondéré
TIC
Technologies de l’Information et de la Communication
UML
Unified Modeling Language
IX
AVANT-PROPOS
AVANT-PROPOS

Actes de création de l’INP-HB
L'Institut National Polytechnique Félix HOUPHOUËT-BOIGNY, en abrégé INP–HB, est
né, par Décret 96–678 du 04/09/96, de la fusion de l'École Nationale Supérieure d'Agronomie
(ENSA), l'École Nationale Supérieure des Travaux Publics (ENSTP), l'Institut Agricole de Bouaké
(IAB) et de l'Institut National Supérieur de l'Enseignement Technique (INSET), quatre
établissements que l'on désignait communément sous le vocable Grandes Écoles de Yamoussoukro.

Missions de l’INP-HB
Définies par le décret 96-678 du 04/09/96, les missions de l’INP-HB sont :
>
La formation initiale et la formation continue : formations diplômantes et qualifiantes de
techniciens supérieurs, d’ingénieurs (des techniques ou de conception) dans les domaines de
l’industrie, du commerce, de l’administration, du génie civil, des mines et de l'agronomie;
>
La recherche appliquée dans les domaines précédemment cités ;
>
L’assistance et la production au profit des entreprises et administrations.

Ambitions de l’INP-HB
Ses ambitions sont à la mesure des espoirs que la nation ivoirienne place en lui pour la
formation des élites qui lui assureront une présence digne dans le concert des nations du troisième
millénaire. Il ambitionne aussi de développer son leadership tant au plan national qu’à l’échelle
sous-régionale dans le domaine de la formation et de la recherche technique et technologique.

L’Ecole Supérieure d'Industrie
L’INP-HB est constitué à ce jour de sept (07) Ecoles dont une école préparatoire. Celle à
laquelle nous appartenons est l’Ecole Supérieure d’Industrie (ESI), chargée 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'accroître leur compétitivité. Elle est organisée aujourd’hui
en plusieurs filières dont le Cycle Ingénieur de Conception en Télécommunications.

Le Cycle Ingénieur de Conception en Télécommunications
Conscient des besoins du marché et constatant la volonté du gouvernement de faire de la
Côte d’Ivoire un point de référence en matière de télécoms, l'INP-HB, a eu la lourde mission
d’ouvrir depuis 2002 au sein de l’ESI la filière Ingénieur Télécoms en partenariat avec les
X
AVANT-PROPOS
opérateurs du monde des nouvelles technologies, de l’industrie et de la recherche « … L’ingénieur
Télécoms et Réseaux INP-HB est appelé à répondre aux besoins du marché des télécoms en pleine
croissance. Son intégration sera donc possible chez un constructeur, un opérateur du secteur des Télécoms
ou dans une société qui offre des services de télécoms. »
[1]
La formation intègre le développement d'un esprit d'initiative et s'appuie sur un partenariat
très actif avec les milieux socioprofessionnels. Cette étroite collaboration avec les entreprises se
matérialise au niveau des étudiants par des stages qu’ils doivent effectuer durant le cycle. De plus,
la validation de cette formation nécessite d’effectuer un stage qui revêt un caractère assez
particulier. En effet, au cours de ce stage (qui est le dernier du cycle), l’étudiant aura à mener des
études dans le cadre de son mémoire de fin de cycle.
C’est dans ce cadre que nous avons intégré le Service Informatique et Statistiques de la
Direction de l’Orientation et des Bourses (DOB) où nous avons œuvré à la « rénovation du système
informatique de gestion des travaux de la Commission Nationale d’Orientation (CNO) et de la
Commission Nationale des Bourses (CNB)».
XI
RESUME
Ce mémoire de fin de cycle détaille la mise en place d’un système de gestion automatisée
des affectations en sixième (6ième) et des orientations en seconde (2nde) en Côte d’Ivoire. L’objectif
du projet est la réduction au strict minimum des opérations, jusqu’ici presque manuelles, effectuées
par la Commission Nationale d’Orientation (CNO) et la Commission Nationale des Bourses (CNB)
en concevant une application opérationnelle et fiable à même d’automatiser celles-ci. L’étude
globale du processus d’affectation en sixième (6ième) et d’orientation en seconde (2nde) nous a
permis de faire des propositions visant, en partie, des changements notables au sein du système
éducatif ivoirien. Ces changements devront permettre un fonctionnement optimal de l’application
que nous avons mise au point par une meilleure rationalisation des opérations qui influencent la
CNO et la CNB. En outre, les diverses solutions proposées sont toutes basées sur l’architecture du
système informatique de la Direction de l’Orientation et des Bourses (DOB) et sur le processus
d’identification des élèves. C’est d’ailleurs ce qui nous a amenés à une analyse technique de
l’existant pour proposer des solutions viables centrées sur différentes architectures matérielles. La
solution retenue pour le très court terme exige une architecture distribuée de type Client/Serveur.
Mots-clés :
Base
de
données,
modélisation,
réseau,
sécurité,
système
d’information…
XII
INTRODUCTION
Après l’indépendance, la Côte d’Ivoire a connu près de deux décennies de croissance
économique soutenue. Cas singulier, ce « miracle ivoirien » s'explique par la volonté des
dirigeants
d'asseoir,
dès
1960,
le
développement sur l'agriculture,
principalement
les
plantations de caféiers et de cacaoyers. Si l'agriculture occupe une place de choix dans le
développement économique, les secteurs secondaire et tertiaire ne sont pas négligés pour
autant. Avec l'industrie naissante et l'administration qui réclament des cadres compétents, se
pose rapidement la question des ressources humaines. La nécessité de former des cadres
nationaux, trop peu nombreux à l'indépendance, détermine la politique du gouvernement en
matière
d'éducation
et de formation. Ainsi, l’instauration d’un mécanisme d’orientation et
d’attribution de bourses, géré par une structure sous tutelle du Ministère de l’Education Nationale
(MEN), s’impose, afin de permettre une insertion socioprofessionnelle adéquate pour chaque futur
cadre. C’est dans cette vision qu’est née la Direction de l’Orientation et des Bourses (DOB).
Animée du désir de suivre le développement prodigieux des Technologies de l’Information
et de la Communication (TIC) et de profiter des avantages indéniables qu’elles offrent à
l’automatisation des systèmes opérants, la DOB a opté pour la mise en place d’un système de
gestion automatisée des affectations en sixième (6ième) et des orientations en seconde (2nde). Mais,
conçue au mépris des règles de la modélisation, l’application présente des anomalies qui, au regard
des nombreuses réclamations formulées par les parents d’élèves, affectent la qualité des résultats
issus de la Commission Nationale d’Orientation (CNO) et de la Commission Nationale des Bourses
(CNB). C’est pour pallier à ces problèmes, par la rénovation de son système informatique, que nous
avons été accueillis au sein du Service Informatique et Statistiques (SIS) de la DOB.
Le présent mémoire, dont l’objectif est d’expliquer le travail effectué, est structuré en trois
(03) parties. La première partie présente l’étude de l’existant, en exposant ses différents points
faibles qui nourrissent la nécessité de concevoir un nouveau système plus stable. Dans la deuxième
partie, nous procédons à l’étude technique des solutions viables par l’explication de leurs avantages
et inconvénients en vue d’aider la DOB au choix d’une solution adéquate. Enfin, le déploiement du
système d’information conçu est l’objet de la troisième partie, en détaillant la répartition
géographique, matérielle, logicielle et humaine des différentes entités composantes.
13
PREMIERE PARTIE : CONTEXTE DU STAGE ET ETUDE DE L’EXISTANT
Nous décrivons, dans cette partie, l’environnement de travail dans lequel nous avons évolué
et l’ensemble des méthodes et matériels de travail utilisés par la DOB avant, pendant et après les
travaux de la CNO et de la CNB. Nous expliquons aussi l’intérêt du thème étudié.
14
CHAPITRE 1 : CADRE DE REFERENCE
1.1 Présentation de la structure d’accueil
1.1.1 Généralités
En 1972, l'office du Baccalauréat est détaché 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 pédagogiques (CAPES, CAPCEG). La fusion des
deux services (le service des examens et concours (qui s'occupait de l'organisation du BEPC et de
l'entrée en sixième) et l'office du baccalauréat) 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
détaché 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'année 2005, la Sous Direction de l'Orientation et des Bourses (DOB) est devenue
une direction
[2]
située à Abidjan (Plateau), précisément au quatrième (04ème) étage de l’immeuble
alpha 2000. Elle compte dix-neuf (19) bureaux et une (01) salle de conférence.
Figure 1.1 : Localisation de la DOB
15
1.1.2 Mission de la DOB
Conformément aux dispositions du décret n° 2010-32/1391 du 18 mars 2010 modifiant et
complétant le décret n° 2004-564 du 07 Octobre 2004 portant organisation du Ministère de
l’Education Nationale, la DOB est chargée :
1. de L’élaboration d’une politique nationale d’orientation et de suivi des élèves à partir du
préscolaire et primaire ;
2. de la préparation et de l’organisation de la commission nationale d’orientation en seconde et
d’affectation en sixième en liaison avec les structures concernées ;
3. de l’élaboration, en liaison avec les établissements concernés des états nominatifs des élèves
boursiers et de leur transmission à la Direction des affaires Financières ;
4. de l’élaboration et du suivi de l’application des textes réglementaires relatifs à l’information,
à l’orientation et à l’attribution des bourses du secondaire ;
5. de l’octroi, du renouvellement et du transfert des bourses aux élèves de l’enseignement
secondaire ;
6. du suivi du cursus et de l’encadrement psychologique rapproché de l’élève.
1.1.3 Organisation de la DOB
Pour mener ses missions, la DOB dispose de :
A. deux sous-directions :
1. La sous-direction de l’Orientation et du Suivi des Elèves avec quatre (04) services ;
2. La sous-direction des Bourses avec trois (03) services
B. trente-trois (33) structures déconcentrées : les Centres d’Information et d’Orientation
(CIO).
C. six (06) services rattachés:
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 d’un programme d’équipement en matériel informatique de la
DOB et de tous les services d’orientations et des bourses ;
>
La gestion du parc informatique de la DOB;
16
>
La conception et le suivi des programmes informatiques de la DOB ;
>
La saisie et le traitement des données statistiques relatives à l’orientation en
2nde, à l’affectation en 6ième et aux bourses ;
>
L’archivage électronique au sein de la DOB ;
>
L’identification des besoins de la DOB en matériel informatique ;
>
La maintenance du matériel informatique de la DOB ;
>
La création d’un site internet ;
>
La gestion de la salle informatique de la DOB.
Figure 1.2 : Organigramme de la DOB
1.2 Présentation du thème de stage
1.2.1 Positionnement du sujet
L’opération d’affectation en sixième et d’orientation en seconde est une activité sensible et
très pénible lorsqu’elle est faite de façon manuelle. Elle nécessite, dans cette configuration, une
importante ressource humaine et donc une plus grande ressource financière. En plus, l’idée de tenir
les délais imposés en minimisant les erreurs et les dépenses financières liées au surcroît de
17
personnel, justifie le choix pour la DOB de nous soumettre le thème ainsi libellé « rénovation du
système informatique des travaux de la Commission Nationale d’Orientation (CNO) et de la
Commission Nationale des Bourses (CNB) ». Mais, fort des problèmes que pourrait engendrer un
système informatique de qualité médiocre, la DOB se donne les moyens de mettre en place un
système fiable, stable et viable en exigeant une modélisation conforme aux règles de l’art.
1.2.2 Cahier des charges
1.2.2.1 Centre d’intérêt
Optimiser les travaux de la CNO et ceux de la CNB.
1.2.2.2 Contraintes générales
La rénovation du système informatique de gestion des travaux de la CNO et de la CNB se
déroulera sur trois (03) mois et se fera avec l’Atelier de Génie Logiciel (AGL) WINDEV.
1.2.2.3 Objectifs
1. Concevoir un nouveau système informatique de gestion des travaux de la CNO et de la
CNB ;
2. Maîtriser l’environnement WINDEV;
3. Former les gestionnaires à l’utilisation de l’application.
1.2.2.4 Méthodologie
La rénovation du système informatique de gestion des travaux de la CNO et de la CNB sera
consacrée aux opérations suivantes :
1.
Analyse et conception de l’application ;
2.
Expérimentation de l’application ;
3.
Atelier de validation
Composante 1 : Analyse et conception de l’application
Cette composante s’articulera autour de 4 phases essentielles.
Phase 1 : Etude fonctionnelle
Il s’agit de faire l’état des fonctionnalités existantes et proposition de nouvelles
fonctions :
1. Etude technique (définition de l’architecture cible),
2. Etude conceptuelle (la modélisation de la solution envisagée).
18
Phase 2 : Réalisation
Conception d’une application de gestion des travaux de la CNO et de la
CNB.
Phase 3 : Déploiement
1. Déploiement sur le site de la DOB et sur des sites pilotes en région,
2. Déploiement sur les autres sites (33 CIO)
Phase 4 : Renforcement des capacités des utilisateurs
Formation des gestionnaires de la DOB et des sites pilotes en région,
Composante 2 : Expérimentation de l’application.
Cette composante consiste à l’utilisation de l’application dans des CIO et établissements
pilotes pour une période d’essai aux fins de détecter ses imperfections.
Composante 3 : Validation de l’application.
La validation de l’application va réunir un ensemble d’experts et de cabinets en WINDEV.
Le cabinet LA FAYETTE représentation nationale des produits PC SOFT fournisseur du produit
WINDEV, les experts en environnement WINDEV du MEN et de l’Institut National Polytechnique
Félix Houphouët Boigny
donneront leur avis pour la validation de l’application.
19
CHAPITRE 2 : ETUDE DE L’EXISTANT
L’existant est l’ensemble des moyens matériels, humains et des méthodes utilisés au sein du
système à modéliser. Cette étude se ramène, en l’occurrence, à l’ensemble des méthodes et
matériels déployés par la DOB pour l’affectation en sixième et l’orientation en seconde des élèves
dans le cadre de la CNO, puis pour l’attribution et le renouvellement des bourses dans le cadre de la
CNB, en Côte d’Ivoire. Une description détaillée de ces différents processus s’avère, par
conséquent, indispensable.
2.1 Description des processus d’affectation en sixième, d’orientation en seconde,
d’attribution et de renouvellement de bourses
Le processus qui conduit à l’organisation de la CNO et de la CNB débute dès la rentrée
scolaire. Il faut signaler qu’au niveau de cette activité, la DOB est fortement tributaire de la
Direction de l'Informatique, de la Planification, de l’Evaluation et des Statistiques (DIPES) et
surtout de la Direction des Examens et Concours (DECO). En effet, la DECO est la structure de
l’Education Nationale qui organise les examens de fin d’année et qui, par conséquent, fournit les
notes des candidats à la DOB pour les affectations-orientations et attributions de bourses. Quant à la
DIPES, elle se charge d’immatriculer les candidats admis à l’entrée en sixième.
2.1.1 Description du processus d’affectation en sixième
Le processus d’affectation en sixième se déroule en trois (03) grandes étapes : avant les
assises de la CNO (pré CNO), pendant les assises de la CNO (assises CNO) et après les assises de la
CNO (Post CNO).
2.1.1.1 Pré CNO
Cette étape concerne essentiellement l’enregistrement des candidats au CEPE et à l’entrée en
sixième et la récupération des notes obtenues par ces candidats à l’examen. Il y a huit (08) niveaux
d’opérations qu’on peut ranger en deux (02) grandes étapes : avant et après les examens du CEPE.

Avant les examens du CEPE
1. Installation de l’application de saisie des candidats dans les IEP.
2. Saisie de l’identité des candidats et de leurs vœux d’établissements.
3. Correction des anomalies et fusion des fichiers provenant des IEP par DREN.

Après les résultats des examens du CEPE
4. Installation de l’application de saisie des TGP dans les IEP.
20
5. Enregistrement des TGP dans les IEP en fonction de la barre fixée par le Directeur de la
DOB.
6. Correction et fusion nationale des données provenant des IEP à la DOB.
7. Transmission d’un état cumulatif par tranches de TGP au MEN pour aider à fixer la barre
d’admission en sixième
8. Arrêté du MEN fixant la barre d’admission en sixième.
2.1.1.2 Assises de la CNO
C’est le lieu d’effectuer les affectations proprement dites. Nous avons trois (03) niveaux
d’action. Cette étape se déroule après les examens du CEPE.
1. Vérifications de la conformité des informations relatives aux élèves de la base de données
(notes d’examens, identité…) avec ceux des PV (procès-verbaux) des résultats d’examen
récupérés auprès de la DECO.
2. Affectation automatique : les candidats sont affectés par ordre de mérite en fonction des
capacités d’accueil des établissements par l’application Epervier.
3. Affectation manuelle : les élèves battus durant l’affectation automatique
sont affectés
manuellement dans les établissements non saturés proches (géographiquement)
des
établissements visés par leurs vœux d’établissements.
2.1.1.3 Post CNO
Il s’agit de recueillir et de traiter les dossiers de réclamations introduits par les candidats non
satisfaits des résultats d’affectation publiés après 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 rôl 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 d’affectation en sixième
21
2.1.2 Description du processus d’orientation en seconde (2nde)
Le processus d’orientation en seconde se déroule, à l’instar du processus d’affectation en
sixième, en trois (03) grandes étapes : avant les assises de la CNO (pré CNO), pendant les assises de
la CNO (assises CNO) et après 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 l’application de saisie des moyennes trimestrielles dans les
établissements.
4. Saisie des moyennes trimestrielles dans les établissements (la saisie se fait trimestre
après trimestre)
5. Transmission du fichier des moyennes trimestrielles aux CIO qui les envoient à la DOB.
(Cette opération se fait trimestre après trimestre)
6. Correction des erreurs provenant des fichiers réceptionnés.
7. Renvoie dans les CIO à la fin du dernier trimestre du fichier des moyennes trimestrielles.

Après les résultats du BEPC
1. Constitution dans les DREN des Commissions Régionales de Calcul de la Moyenne
d’Orientation (CRCMO), installation du logiciel de saisie des notes du BEPC.
2. Enregistrement des notes (notes sur 20) du BEPC dans les matières d’orientation (notes
sur 20 en composition française, mathématiques, anglais et en sciences physiques) dans
le logiciel pour l’obtention des moyennes d’orientation.
3. Constitution de l’état cumulatif des élèves par tranches de MO pour aider à la fixation de
la barre d’orientation en seconde (MO limite).
4. Fixation de la barre d’orientation par le MEN
2.1.2.2 Assises CNO
1. Correction des fichiers provenant des CRCMO, fusion et constitution du fichier national.
2. Vérifications de la conformité des informations relatives aux élèves de la base de
données avec ceux des PV de la DECO.
3. Orientation automatique et manuelle.
22
2.1.2.3 Post CNO
Gestion des dossiers de réclamations émis par les élèves et parents d’élèves non satisfaits
des résultats publiés après 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 rôles et calculer MO (CRCMO)
Dét 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
Après examen du BEPC
Figure 2.2 : Processus d’orientation en seconde
2.1.3 Description du processus d’attribution et de renouvellement de bourses
La sous-direction des bourses est l’une des deux sous-directions qui composent la DOB.
Elle a pour missions essentielles :
1. l’attribution de bourses aux élèves de 6ème et de 2nde ;
2. le renouvellement des bourses ;
3. la gestion et le suivi des états servant au paiement des bourses.
L’Etat ivoirien, soucieux de l’avenir de sa jeunesse, a institué la bourse scolaire dans son
système éducatif dès son accession à l’indépendance. Ainsi, dans les années soixante (1960), il
suffisait de réussir l’examen d’entrée en 6ème pour bénéficier d’une bourse. On disait à l’époque non
pas « je suis admis à l’examen d’entrée en 6ème» mais plutôt « j’ai eu ma bourse ». A cette époque,
Les seules conditions d’octroi de bourse étaient celles d’être élève et de nationalité ivoirienne selon
l’article 2 du décret n° 60-310 du 21 Septembre 1960. Plus tard, en 1984, le décret n°84-1024 du 22
Août ajoutera aux critères mentionnés plus haut ceux des résultats scolaires, du niveau de revenu
des parents et de l’âge (être âgé de 15 ans au plus pour la 6ème et de 18 ans au plus pour la 2nde).
23
Tableau 2.1 : Nombre d’enfants d’une même famille pouvant prétendre à une bourse
d’Enseignement général secondaire en fonction des ressources
Nombre d’enfants à
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
1
1
1
0
0
2
2
1
1
0
3
3
2
1
0
4
4
2
1
0
5
5
3
2
0
6
6
3
2
0
7
7
4
2
0
8
8
4
3
0
9
9
5
3
0
10
10
5
3
0
11
11
6
4
0
12
12
6
4
0
13
13
7
4
0
14
14
7
5
0
15
15
8
5
0
16
16
8
5
0
17
17
9
6
0
18
18
9
6
0
19
19
10
6
0
20
20
10
7
0
Ce tableau s’explique 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 sûr d’avoir les
moyennes, l’âge et la nationalité requis). Par contre, un parent de revenu mensuel supérieur à cent
mille francs CFA (100.000 F CFA) a droit à un nombre limité de boursiers parmi ses enfants,
jusqu’à ne plus bénéficier de la bourse quand il dépasse trois cent mille francs CFA (300.000 F
CFA) de revenu mensuel.
Aujourd’hui, les seuls critères retenus sont la nationalité ivoirienne et les résultats scolaires.
Dans les deux cas (attribution et renouvellement de bourse), le processus global se présente
comme suit :
1.
La DOB met, en cours d’année scolaire, la liste des élèves boursiers et demi-boursiers
(pour le renouvellement seulement ; il n’y a pas de demi-boursiers en attribution) à la
24
disposition des établissements (les économes sont les acteurs clés de la sous-direction
des bourses dans les établissements) ;
L’économe imprime les états de bourse et fait émarger les élèves concernés pour
2.
signaler leur présence au sein de l’établissement ;
3.
Les fiches signées sont transférées à la DOB ;
4.
Ces fiches sont transférées à la Direction des Affaires Financières (DAF) après contrôle
et gestion des omis et retardataires ;
5.
La DAF met, après approbation, la liste des élèves mandatés à la disposition du Trésor
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 contrôles et gérer les omis
F aire contrôles et définir élèves mandatés
Payer élèves mandatés
F inal
Figure 2.3 : Processus global de gestion des bourses
2.1.3.1
Description du processus d’attribution de bourses
Chaque année scolaire, des barres d’attribution de bourses pour la sixième et la seconde sont
fixées par rapport au budget restant après le renouvellement de bourses. Ainsi, la bourse est
accordée aux élèves ivoiriens remplissant les conditions de résultats scolaires définies par la CNB.
Pour exemple, voici les tableaux récapitulatifs d’attribution de bourses des classes de 6ème et de 2nde
des trois dernières années.
Tableau 2.2 : Tableau récapitulatif d’attribution de bourses en 6ème
Pourcentage des
Année scolaire
TGP exigé pour
Equivalent du TGP en
Total des élèves
Nombre
boursiers par
être boursier
termes de moyenne
affectés
d’affectés
rapport aux
Boursiers
affectés
(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 récapitulatif d’attribution de bourses en 2nde
25
2.1.3.2
Description du processus de renouvellement de bourses
Pourcentage des
Année scolaire
Moyenne d’orientation exigée
Total des élèves
Nombre
boursiers par
orientés
d’orientés
rapport aux
Boursiers
orientés
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 régissent les bourses sont ceux de 1984. Ils déterminent les critères suivants
pour le renouvellement de la bourse :
Pour le premier cycle
>
être de nationalité ivoirienne ;
>
avoir une moyenne générale annuelle supérieure ou égale à douze (12) sur vingt (20) pour la
bourse entière ;
>
une moyenne générale 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 générale annuelle supérieure ou égale à onze (11) sur vingt (20) pour la
bourse entière ;
>
une moyenne générale 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 critères de moyennes du premier cycle sont appliqués aux deux
cycles vu la réduction de l’enveloppe budgétaire due aux difficultés é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 l’année académique prochaine est
remplie par l’économe de l’établissement pour chaque élève boursier ou demi-boursier et transférée
à la DOB pour analyse. Elle contient principalement les performances scolaire du concerné et est
dûment signée par ce dernier.
2.2 Description du système informatique de la DOB
Un système informatique est un ensemble d’entités matérielles et logicielles qui
interagissent selon des algorithmes. Pour optimiser le rendement d’un tel système, une architecture
soigneusement pensée doit être définie aux niveaux matériel et logiciel.
26
2.2.1
Architecture matérielle
La DOB dispose d’un réseau local connecté à internet. Ce réseau local, est un élément clé
dans les échanges de données numériques au sein de la direction et de ses services. Il pourra, en
outre être exploité pour le déploiement du nouveau système d’information. Elle possède aussi des
ordinateurs au sein de chaque service, très utiles pour le déploiement déjà évoqué.
2.2.2
Architecture logicielle
La DOB dispose de la licence d’utilisation de l’AGL WINDEV. WINDEV est un produit de
PC SOFT, et est à sa version 16 à l’heure où ces lignes sont écrites.
La société PC SOFT est une société française, spécialisée dans la conception de logiciels de
haute technologie comme les environnements de développement professionnels pour Internet,
Intranet, Windows, Linux, Unix, les mobiles,…
A l’aide de cet AGL, une application dénommée « Epervier » a été conçue 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 données HyperFileSQL classic réseau. Elles sont déployées
au sein des différentes structures de la DOB pour les préparatifs de la CNO et de la CNB.
2.3 Nécessité d’amélioration
La procédure de gestion des orientations et des affectations, dans sa configuration actuelle,
est trop lourde et porte fortement atteinte à la qualité des résultats (au regard des nombreuses
réclamations formulées par les parents d’élèves). Les méthodes de collectes des données sont peu
fiables (des va-et-vient des CD). En outre, une trop grande intervention de l’homme sur la chaîne de
production des résultats est à signaler. L’application de gestion informatisée des orientations et
affectations connaît quelques limites qui obèrent la qualité du travail de la CNO et occasionne
d’énormes pertes de temps. Cela nous amène à cibler les différentes failles aux niveaux matériel,
logiciel et de la main d’œuvre en vue de proposer des solutions fiables et viables.
2.3.1
Les failles matérielles
Le système actuel de gestion automatisée des actes de la CNO et de la CNB ne fonctionne
pas en mode réseau. Il n’y a pas de serveur dédié pour la base de données, toutes les opérations
étant effectuées sur des ordinateurs personnels. Cela constitue un problème essentiel dans la mesure
où la synchronisation des données est pénible. En outre, les ordinateurs personnels, servant aux
activités de tierces personnes en dehors des actes de la CNO et de la CNB, peuvent subir des dégâts
pouvant entraîner une perte compromettante de données essentielles. Le piratage des données
27
sensibles en est aussi facilité. L’utilisation de CD pour le transfert de l’information entre les
différentes structures est à revoir. En effet, le temps d’accès mémoire sur les CD est très élevé et
les CD se détériorent très facilement (il suffit d’une égratignure sur la surface réfléchissante),
entrainant des vas-et-viens répétés entre la DOB et des structures éloignées, sinon des temps de
ressaisie supplémentaires. On assiste alors au ralentissement du processus de fusion des données.
2.3.2
Les failles logicielles
Le développement de l’application existante, essentiellement basé sur le RAD (Rapid
Application Development), pourrait occasionner la non maitrise du code source, ce qui pourrait
exacerber les difficultés de détection et de correction des erreurs de fonctionnement du logiciel. En
effet, le RAD est une technique de génération automatique d’interfaces graphiques et de codes
nécessaires à l’exécution de tâches plus ou moins complexes à partir d’un schéma de données
appelé « analyse » dans l’environnent WINDEV. Ainsi, le développeur se contente de créer
l’analyse et par clic sur une suite de boutons, tout le code qu’il est sensé écrire est automatiquement
généré. Bien que cette technique présente des avantages en terme de rapidité de développement, elle
peut complexifier les diagnostiques d’erreurs, puisque le développeur ne dispose pas
nécessairement des compétences requises pour comprendre le code généré. En outre cette technique
est difficile à implémenter lorsque l’analyse a une structure relationnelle, raison pour laquelle les
différents « fichiers » (appelés tables dans les autres SGBD comme Oracle, MySQL, Access…)
n’ont pas été liés, occasionnant des redondances d’information, voire de sérieuses anomalies de
mise à jour de la base de données. Aussi, HyperFileSQL est un SGBD relationnel (Voir Annexe
A.6). Par conséquent, la gestion d’une base de données non relationnelle à l’aide de ce SGBD
constitue une erreur d’exploitation assez importante qui alourdit les interactions avec la base de
données.
En outre, n’ayant pas été développée selon un « modèle soigneusement conçu »,
l’application existante exige des modifications fréquentes basées sur des déductions empiriques ;
cela présente l’inconvénient majeur de créer des redondances de données au sein de la base de
données pouvant alourdir, pour sûr, les échanges avec celle-ci. Le déploiement du logiciel est très
difficile dans la mesure où une copie des composants à installer doit être envoyée par CD aux
différentes structures éloignées autorisées à l’utiliser. Cela rend pénible les mises à jour de
l’application lorsqu’il y a nécessité de modifier certaines de ses fonctionnalités. Enfin, après la
saisie de données, l’application offre la possibilité à l’opérateur de saisie d’exporter les données
dans un fichier au format xsl non chiffré (fichier éditable par le logiciel Microsoft Excel) qu’il grave
28
sur un CD et le transfère à la DOB. Ce moyen est très fragile puisque le fichier peut être modifié
sans l’application fournie par la DOB.
Il faut aussi préciser que malgré la puissance supposée du moteur d’HyperFileSQL, ce
SGBD, peu connu dans le monde des « experts », mérite une étude approfondie pour décider de sa
validité pour le projet d’envergure qui nous est soumis.
2.3.3
Les failles de main d’œuvre
Conçue et administrée au mépris des règles de gestion de système d’information,
l’application ne respecte pas la grande majorité des techniques de modélisation de système
d’information. Cela fragilise énormément la sécurité dont doit jouir une application traitant des
données aussi sensibles que l’orientation et l’attribution de bourses aux élèves. Un autre problème
se situe au niveau des collaborateurs informaticiens des structures éloignées qui ne maîtrisent pas
toujours les connaissances nécessaires à la bonne marche de l’application ; ce qui donne leu à des
programmes de formation coûteux en temps et en moyen financier. Nous notons aussi les
récurrentes erreurs de saisie faites par les opérateurs de saisie qui imposent un surplus de travail au
SIS.
Enfin, le transport des CD vers la DOB nécessite de solliciter des personnes fiables, choix
plus ou moins difficile à faire, pouvant compromettre l’authenticité des informations transmises.
Tous ces problèmes ont donné leu à des situations plus ou moins regrettables :
>
Double orientation d’élèves ;
>
Elèves affectés dans la base de données mais absents sur les listings ;
>
Elèves affectés sans établissement d’accueil ;
29
DEUXIEME PARTIE : ETUDE TECHNIQUE
Nous allons dans cette partie expliquer les différents choix effectués pour la réalisation du
projet qui nous a été soumis. Il s’agira en effet d’exposer de façon explicite les éléments techniques
utilisés, allant de la généralité sur la conception de système d’information à la réalisation pratique
du projet.
30
CHAPITRE 3 : CONCEPTION DE SYSTEME D’INFORMATION
3.1 Approche de la conception de système d’information
Un Système d’Information (SI) est un système
constitué des ressources humaines, des ressources
informatiques (équipement, logiciel, données) et des
procédures permettant d’acquérir, de stocker, de traiter et
de diffuser les éléments d’information pertinents au
fonctionnement d’une entreprise ou d’une organisation
(Management Information System, en Anglais)
[3]
.
En ce qui nous concerne, la partie à gérer est
l’ensemble des ressources informatiques que la DOB
utilise lors des différentes commissions nationales
d’orientation et des bourses. En effet, les autres parties
ont fait l’objet de propositions visant une reforme du
système éducatif et donc nécessitant l’intervention
préalable des décideurs.
Le développement des TIC étant essentiellement
axé sur la réduction au strict minimum de l’effort
humain, différentes organisations d’équipements ont été
Figure 3.1 : Système d’Information (SI)
mises au point au cours des décennies en vue de fédérer
les opérations des divers acteurs et permettre l’accès
partagé à des ressources. Deux architectures de base
nous intéressent ici :
l’architecture centralisée et
l’architecture décentralisée.
3.1.1 Architecture centralisée
Une architecture est dite centralisée si toutes les ressources se trouvent au même endroit ou
sur la même machine. Toutes les machines de l’architecture qui désirent accéder à des données
interrogent les ressources distantes.
31
Figure 3.2 : Schéma générale d’une architecture centralisée
3.1.1.1 Avantages de l’architecture centralisée
Une architecture centralisée permet de concentrer toute l'intelligence au sein d'un même
matériel, et de n'avoir qu'un seul point à administrer, à configurer, et à surveiller, car c'est le seul
point exposé au piratage. Cela simplifie les contrôles de sécurité et la mise à jour des données et des
logiciels. Toute la complexité et la puissance peut être déportée sur le ou les serveur(s), les
utilisateurs utilisant simplement un client léger sur un ordinateur terminal qui peut être simplifié au
maximum. Les serveurs étant centralisés, cette architecture est particulièrement adaptée et véloce
pour retrouver et comparer de vaste quantité d'information
3.1.1.2 Inconvénients de l’architecture centralisée
Lorsque plusieurs demandes de communication simultanée parviennent au serveur, ce
dernier risque de ne pas supporter la charge. Il doit donc être très performant, très résistant et
surveillé de très près, ce qui contribue à en hausser le prix. En plus, toute indisponibilité du serveur
occasionne le disfonctionnement systématique de ses clients. Aussi, les clients ne peuvent, en aucun
cas, communiquer entre eux, entrainant une asymétrie de l'information au profit des serveurs.
3.1.2 Architecture décentralisée
Une architecture est dite décentralisée si les ressources se trouvent à différents endroits, sur
des machines éparses. Toutes les machines de l’architecture qui désirent accéder à des données
interrogent les ressources distantes. Plusieurs serveurs peuvent aussi bien héberger les mêmes
données que des données différentes et complémentaires.
32
Figure 3.3 : Schéma générale d’une architecture décentralisée
3.1.2.1 Avantages de l’architecture décentralisée
Ce type d'architecture est facilement extensible pour faire face à de nouveaux besoins
fonctionnels. Les architectures distribuées offrent une grande souplesse pour faire face aux
problèmes de montée en charge (réplication, répartition de charges...) car le seul fait de distribuer
les traitements sur les ordinateurs d'un réseau augmente les ressources disponibles. En outre, elles
sont très modulaires et offrent de nombreuses possibilités de déploiement. Elles permettent en plus
de mettre en place une très forte tolérance aux pannes, des nœuds complets pouvant être
indisponibles sans que le service soit interrompu.
Une architecture distribuée courante est l'architecture trois tiers à la base de la plupart des
applications distribuées de commerce électronique. Cette architecture permet d'interroger et de
mettre à jour des sources de données réparties, des services web (programmes hébergés sur des
serveurs spécifiques d’internet) permettant de faire appel à différents serveurs pour enrichir une
prestation. En effet, l'achat d'un séjour touristique peut comprendre l'achat d'un billet d'avion, d'un
séjour hôtelier et d'une assurance d’annulation auprès de différents vendeurs par l'intermédiaire de
services web, donc d'objets distribués sur le réseau et dialoguant par des messages.
3.1.2.2 Inconvénients de l’architecture décentralisée
La répartition des ressources sur plusieurs serveurs est une source de complexité des
applications déployées qui doivent exploiter ces données. En plus, elle nécessite un déploiement de
moyen financier plus élevé du fait de la multiplicité des nœuds actifs. Enfin, Il y a ici plusieurs
nœuds susceptibles de subir des attaques de la part d’entités malveillantes, ce qui complexifie les
techniques de sécurisation du système.
33
3.2 Proposition de solutions
Dans les paragraphes précédents, nous avons exposé les avantages et inconvénients de deux
types d’architectures de systèmes d’information : les architectures distribuée et centralisée.
L’architecture matérielle d’un système d’information étant indispensable à une productivité
optimale, nous proposons dans ce qui suit deux architectures inspirées des deux familles
d’architectures déjà expliquées. Ces architectures sont bien sûr adaptées au niveau technologique du
pays (Côte d’Ivoire) et aux contraintes sécuritaires liées aux données sensibles que l’application
doit gérer. Nous verrons en premier lieu une architecture monoposte qui ne nécessite pas de réseau
informatique pour fonctionner, et en second lieu une architecture distribuée de type client/serveur
qui exige l’interconnexion des machines de production et qui donc procure une rentabilité optimale
par la synchronisation automatique des données.
3.2.1 L’architecture monoposte
Nous désignons par architecture monoposte, une architecture dans laquelle aucun réseau
informatique n’est nécessaire. Ici les ordinateurs sont isolés les uns des autres et communiquent par
des opérations manuelles. En effet, dans cette architecture, les
différents ordinateurs reçoivent une copie de
l’application et traite les données de manière
autonome, sous la conduite d’un opérateur
humain. Une fois le travail réalisé sur l’un des
ordinateurs, les données sont copiées sur une
mémoire de masse (CD, DVD, Clé USB, Disque
dur externe…) pour les passer à un autre
Figure 3.4 : Schéma d’échange dans une
ordinateur. Ainsi, nous voyons bien les problèmes
architecture monoposte
que peut générer une telle architecture. La
synchronisation s’avère pénible (c’est d’ailleurs
un des problèmes qui tourmentent l’application
existante) dans la mesure où l’arrivée des supports amovibles, depuis plusieurs ordinateurs, est très
souvent difficile à synchroniser. Dans l’architecture monoposte (c’est d’ailleurs l’architecture
utilisée actuellement par le SIS pour la gestion de la CNO et de la CNB), seule l’application sera
notre centre d’attention. Il faudra concevoir une application plus stable et la déployer sur les
différents sites éloignés de la DOB en y implémentant le maximum d’éléments de sécurité.
Contrairement à ce qui existe déjà, la nouvelle application devra exiger un mot de passe avant toute
utilisation. Un super utilisateur (utilisateur qui a tous les droits sur l’application) sera
34
automatiquement créé à l’installation de l’application. Ce dernier, et lui seul, pourra créer d’autres
utilisateurs pour la réalisation de tâches données en limitant leurs droits sur l’application. Toute
opération effectuée par chaque utilisateur sera automatiquement enregistrée pour la génération des
statistiques d’utilisation de l’application et pour la gestion d’éventuels contentieux. Une fois les
saisies et les contrôles faites au niveau de chaque structure éloignée (IEP, Etablissement, CIO…),
les données seront transférées au SIS par les moyens habituels (CD, Message électronique,…) pour
fusion et préparation de la CNO et de la CNB. Un mécanisme d’authentification par clés
asymétrique sera mis en œuvre pour fiabiliser le transfert des données. C’est une architecture qui
nécessite des moyens financiers relativement faibles. En effet, seule la fourniture des structures
éloignées en matériels informatiques (ordinateur, CD…) est exigée.
3.2.2 L’architecture distribuée de type client/serveur
Dans une architecture distribuée, les ressources sont déployées sur différents sites. Les
utilisateurs y accèdent pour récupérer ce qui leur est nécessaire. Cela nécessite par conséquent la
présence d’un réseau informatique pour l’échange des données, « faisant croitre les dépenses
financières », tandis que la sécurité du système d’information globale diminue. Notre proposition,
au vue du niveau technologique du pays, se présente sous deux formes : l’interconnexion des
différents sites via internet ou via un réseau étendu national à l’aide du réseau des opérateurs de
télécommunications.
3.2.2.1 Interconnexion via internet
Internet est un vaste réseau à l’échelle mondiale. Il fédère une multitude de réseaux à travers
le monde et constitue un outil d’échange très prisé des ivoiriens par la pluralité et la quasi gratuité
des services offerts (messagerie électronique, échange sur des réseaux sociaux comme facebook,
netlog, twitter…). Il constitue ainsi un réseau largement accessible à toutes les structures
décentralisées de la DOB et peut être utilisé pour centraliser les ressources utiles à la CNO et à la
CNB sur de puissants serveurs entièrement contrôlés par la DOB. La centralisation des données sur
des serveurs contrôlés par la DOB à l’avantage de renforcer la sécurité des ressources et aussi
d’éliminer la dispendieuse (en terme de temps et de ressource humaine) opération de fusion
jusqu’ici effectuée par le SIS. En effet, cette architecture sous-tend la création d’un site web
dynamique constituant un masque de saisie à distance pour chaque structure décentralisée. Les
données saisies sont automatiquement enregistrées sur les serveurs de la DOB continuellement
connectés au serveur web (le serveur web peut aussi bien être la propriété de la DOB que celle d’un
hébergeur de sites web). Les structures décentralisées n’ont pas besoin d’installer une quelconque
35
application (à condition de disposer déjà d’un navigateur web); il leur suffit de se connecter au site
web par les moyens habituels (cybercafé, accès ADSL à domicile ou au bureau, clé internet des
opérateurs de télécommunication…) pour profiter pleinement des fonctionnalités offertes. Des
techniques de redondance et réplication seront appliquées au niveau des serveurs de la DOB de
sorte à rediriger automatiquement et de façon transparente l’application vers le serveur le plus
disponible à un instant donné et à pallier à d’éventuels problèmes de perte de données suite à
l’endommagement d’un serveur. Mais un problème majeur pourrait survenir du fait de l’insécurité
sur internet. En effet, une personne avertie pourrait injecter des données dans la base de données et
corrompre la sauvegarde. Ces problèmes ont tellement inquiété les informaticiens que divers
protocoles de sécurité réseau ont été conçus. Leur utilisation est une assurance en termes de
sécurisation de nos ressources. Nous pouvons entre autres citer les tunnels chiffrés de niveau 2 et 3,
aussi appelés Réseaux Privés Virtuels ou Virtual Private Networks (VPN en Anglais), IPsec, SSL…,
les techniques de chiffrement comme le RSA qui assure une confidentialité indéniable des données.
Cette architecture pourrait nécessiter assez de moyens financiers du fait de l’achat des serveurs.
Figure 3.5 : Architecture distribuée via internet
3.2.2.2 Interconnexion via un réseau étendu national
Les réseaux étendus, ou WAN (Wide Area Network), sont destinés à transporter des
données numériques sur des distances à l’échelle d’un pays, voire d’un continent ou de plusieurs
continents. Le réseau est soit terrestre, et il utilise dans ce cas des infrastructures au niveau du sol,
essentiellement de grands réseaux de fibre optique, soit hertzien, comme les réseaux de satellites [4].
36
Cette solution est envisageable si nous voulons éviter les problèmes de sécurité et de
disponibilité liés à internet. En effet, ici, un accord est pris avec un opérateur de télécommunication
national qui fournit des services supports. L’opérateur donne la garantit de la disponibilité du réseau
sur la quasi-totalité du temps négocié. La sécurisation des données circulant sur son réseau peuvent
bien être de son ressort si l’accord signé en tient compte. Ce qui change dans cette architecture par
rapport à la précédente, c’est le fait que le système d’information soit isolé du réseau public et que
le réseau de transport soit sous le contrôle d’une structure connue et repérable en cas
d’insatisfaction dans la transmission des données. Cela confère une sécurité accrue au système
informatique en le rendant plus stable. Cependant, le forfait versé au fournisseur du service support
pourrait rendre cette solution plus coûteuse que la précédente. Dans les deux cas, le fait que toute
l’intelligence du système d’information soit concentrée sur le site web qui est « unique » et sous le
contrôle de la DOB rendrait l’évolutivité des services offerts plus souple.
Figure 3.6 : Architecture distribuée via un réseau étendu national
3.3 Choix d’une solution
Les différentes architectures ci-dessus exposées nous incitent à choisir une architecture
distribuée de type client/serveur. En effet, l’observation du processus de gestion des orientations en
seconde et des affectations en sixième, révèle que la plupart des opérations donnant lieu à des
doublons dans la base de données provient de la pluralité des sources de données non synchronisées
(un CD par IEP, voire par établissement). En plus, le transport manuel de l’information est très
coûteux en temps et en ressource humaine ; un ensemble de problèmes aisément surmontables par
l’utilisation d’une architecture distribuée de type client/serveur à l’échelle nationale. Néanmoins, un
37
certain nombre de considérations doit être pris en compte pour rendre le projet viable au regard des
contraintes exprimées.
3.3.1 Les contraintes
Une contrainte est une entrave à la liberté d’action, une règle obligatoire à appliquer
[5]
.
Les contraintes constituent donc une part importante dans la réalisation de notre projet. C’est
d’ailleurs l’élément essentiel qui nous permettra de percevoir les véritables besoins de l’utilisateur
et de fournir en conséquence une solution adaptée. Elles se situent à différents niveaux, allant du
temps de réalisation à la flexibilité de la solution. En effet :
1. Le temps de réalisation est fixé à trois (03) mois et prend en compte la formation des
utilisateurs et l’atelier de validation,
2. Le budget alloué au projet est relativement réduit (deux millions (2.000.000) FCFA) et la
solution doit impérativement en tenir compte. Cela impose d’ailleurs l’AGL à utiliser pour
développer l’application. Il s’agit de WINDEV, la DOB disposant déjà d’une licence
d’utilisation,
3. La solution doit être facile d’utilisation afin de permettre à tous les acteurs autorisés de
l’utiliser de façon conviviale,
4. L’administration de la solution doit être aisément accessible à toute personne autorisée pour
faciliter d’éventuelles maintenances et évolutions de l’application,
5. Les problèmes de sécurité, d’intégrité des données et de lourdeur liés à l’application
existante doivent être résolus.
Le respect de ces contraintes nous permettra de choisir une solution basée éventuellement
sur une des architectures présentées plus haut.
3.3.2 La solution retenue
Le choix d’une solution parmi plusieurs est le résultat d’un exercice intellectuel qui obéit à
certains critères. En effet, la solution retenue doit obligatoirement répondre aux besoins de
l’utilisateur en tenant compte des contraintes auxquelles ce dernier pourrait être soumis. Ainsi, les
contraintes exposées dans les paragraphes précédents nous ont permis de faire un choix optimal
pour la DOB. Alors l’architecture distribuée de type client/serveur à l’échelle nationale s’avère très
peu viable pour son coût relativement élevé. Elle est donc inadaptée, bien qu’elle aurait procuré une
solution indéniable aux problèmes de sécurité et d’intégrité des données de la CNO et de la CNB.
Elle cède par conséquent la place à une architecture monoposte qui est bien celle jusqu’ici utilisée
par la CNO et la CNB. Néanmoins, fort des inconvénients que présente une telle architecture et qui
38
d’ailleurs justifie notre présence au sein du SIS, nous avons mis en place une variante de
l’architecture distribuée de type client/serveur à une échelle réduite. Ainsi, l’architecture nécessite
moins de moyen financier tout en fournissant une grande partie des avantages d’une architecture
distribuée de type client/serveur à l’échelle nationale. Il s’agit ici de déployer les équipements sur
un réseau local au sein de chaque structure de la DOB intervenant dans le processus menant à la
CNO et à la CNB. Dès lors, le travail en réseau facilitera les opérations de contrôle et de correction
qui pourront être effectuées en même temps que les opérations de saisie. En outre, plusieurs
opérateurs de saisie pourraient travailler simultanément sur la même base de données en éliminant
les fastidieuses opérations de fusion de données dues à une architecture monoposte, ce qui aboutira
à une réduction considérable du temps de saisie de données. Le réseau peut bien être limité à un
seul ordinateur, donnant ainsi lieu à une architecture monoposte. Cette variante incorpore, par
conséquent, les deux architectures déjà proposées et bénéficie donc des avantages de chacune
d’entre elles, en présentant moins d’inconvénients que chacune d’entre elles. Un avantage non
négligeable pour cette architecture est la facilité de la migration vers une architecture distribuée de
type client/serveur à l’échelle nationale que nous avons fortement conseillée à la DOB pour le
moyen terme.
Figure 3.7 : Architecture distribuée dans un réseau local
Pour ce qui est du SGBD, nous utiliserons HyperFileSQL, les moyens à notre disposition ne
nous permettant pas de nous procurer la licence d’utilisation d’un autre SGBD. En effet, la DOB
dispose déjà de la licence d’utilisation de WINDEV et donc de HyperFileSQL (qui vient en
complément à WINDEV). Néanmoins, nous recommandons vivement à la DOB d’effectuer une
étude approfondie de ce SGBD pour juger sa validité, sinon de se procurer la licence d’exploitation
d’un SGBD connu, qui a déjà fait ses preuves dans diverses entreprises. Nous pouvons, entre autres,
citer Oracle et SQL Serveur (utilisé, par exemple, par l’INP-HB pour la gestion de ses concours).
Mais le coût relativement élevé d’Oracle pourrait le disqualifier et faire de SQL Serveur, dont le
coût est relativement accessible, un SGBD viable et adapté au projet ; là encore, une étude préalable
doit être faite pour un choix objectif tenant surtout compte des fonctionnalités offertes.
39
CHAPITRE 4 : MODELISATION DU SYSTEME D’INFORMATION
4.1 Concepts généraux
Une gestion efficiente des données nécessite la mise en place d’une base de données
déployée sur un ou plusieurs serveurs de base de données. Cette base de données devra être
interrogée par des applications soigneusement conçues pour éviter au mieux les anomalies de mise à
jour observées dans certains systèmes de conception médiocre. Dans ce qui suit, nous présentons les
concepts généraux utiles, voire indispensables à la conception d’un système d’information fiable et
viable, dans le but de permettre au lecteur de comprendre les différents choix effectués pendant la
réalisation du projet.
4.1.1
Bases de données et SGBD
Les bases de données sont partout dans la vie quotidienne et se présentent sous diverses
formes. En effet une base de données n’est rien d’autre qu’un ensemble de données structurées et
sauvegardées qui qualifie le fonctionnement d’une entité organisée. Cela peut aller d’une pile
d’assiettes soigneusement rangée dans une étagère à un ensemble de données numériques
sauvegardées sur un ordinateur de capacité relativement grande appelé serveur de base de données.
Dans notre cas, le traitement doit être fait sur des données numériques, d’où la nécessité de
concevoir une base de données numérique au moyen d’un SGBD puissant et fiable.
Un Système de Gestion de Base de Données (SGBD ou Data Base Management System
(DBMS), en Anglais) est un ensemble de logiciels informatiques qui sert à la manipulation des bases
de données. Il sert à effectuer des opérations ordinaires telles que consulter, modifier, construire,
organiser, transformer, copier, sauvegarder ou restaurer des bases de données. Il est souvent utilisé
par d'autres logiciels ainsi que les administrateurs ou les développeurs. L'ensemble, dont le
composant central est le moteur de base de données, peut être sous forme de composant logiciel, de
serveur, de logiciel applicatif ou d'environnement de programmation. Il permet généralement à
plusieurs utilisateurs et plusieurs logiciels de manipuler plusieurs bases de données en même temps
et ceci quel que soit le contenu et l'organisation des bases de données. La majorité des SGBD du
marché manipulent des bases de données relationnelles. Il est néanmoins important de préciser qu’il
existe des bases de données hiérarchiques, réseaux et orientées objets.
40
4.1.1.1
Les bases de données hiérarchiques
Une première génération de SGBD est née de travaux de recherche menés dans les années
1960 pour le compte de la NASA (National Aeronautics and Space Administration, agence
aéronautique et spatiale des USA) dans le cadre du projet Apollo et commercialisés dans les années
1970 par la société IBM sous le nom IMS (Information Management System)
[6]
. Le SGBD était
basé sur le principe que les enregistrements conservés dans divers fichiers pouvaient être liés selon
une certaine hiérarchie et constituer un assemblage arborescent. On a appelé structure hiérarchique
cette forme de liaison entre des enregistrements de fichiers distincts. En vertu de ce modèle
d’organisation des données, un enregistrement peut être le père de plusieurs enregistrements qui à
leur tour peuvent avoir des fils. Par exemple un
fichier appelé Étudiants contenant des données sur
les étudiants peut être lié à un autre fichier Cours
contenant des données sur les cours suivis par les
étudiants. A l’aide d’un langage dit de navigation
entre les fichiers, le programmeur accédant à un
enregistrement du fichier Étudiants peut repérer
automatiquement les enregistrements fils du fichier
Cours. Un SGBD hiérarchique possède un avantage
indéniable sur les systèmes basés sur des fichiers. Il
permet en effet d’établir des liens un à plusieurs
Figure 4.1 : Structure hiérarchique d’une
entre les fichiers d’une base de données ; un
base de données hiérarchique
enregistrement père peut être lié à plusieurs
enregistrements fils.
4.1.1.2
Les bases de données réseaux
Suite aux nombreux problèmes suscités par
les SGBD hiérarchiques, des chercheurs de la
société américaine General Electric eurent l’idée
de généraliser l’approche de ces SGBD en
proposant un modèle d’organisation des données
permettant des liens plusieurs à plusieurs entre les
fichiers. La hiérarchie père-fils n’existe pas dans ce
modèle car un enregistrement peut avoir plusieurs
Figure 4.2 : Maillage dans une base de
données réseau
41
successeurs de même que plusieurs prédécesseurs. Les fichiers sont liés en réseau maillé à la
manière des réseaux d’égout où à un point du réseau convergent des connecteurs effluents et des
connecteurs affluents.
Ces SGBD sont dits de type réseau (ou simplement SGBD réseau) et permettent de
représenter des associations complexes entre les fichiers. Cette catégorie de SGBD a suscité
beaucoup d’intérêt dans la communauté des chercheurs et des utilisateurs intéressés par les bases de
données. Cela a donné lieu, à la fin des années 1960, à la création d’un groupe de travail visant à
définir des normes pour le SGBD de type réseau portant sur les caractéristiques requises pour
assurer la création des bases de données ainsi que la manipulation de données. Ces normes, connues
sous le vocable CODASYL, décrivent en quelque sorte l’environnement requis pour la conception
et l’exploitation des bases de données réseaux. Elles reconnaissaient pour la première fois de
manière formelle l’importance du schéma physique de la base de données, le rôle clé de la personne
responsable de sa construction et de son entretien, c’est-à-dire l’administrateur de base de données
(ABD). La norme met en évidence la nécessité de mettre à la disposition de l’ABD un langage pour
la construction de schéma physique appelé le Langage de Définition de Données (LDD, ou Data
Definition Language (DDL) en Anglais) ainsi que d’offrir au programmeur un langage pour
exploiter les données, le Langage de Manipulation de Données (LMD, ou Data Manipulation
Language (DML) en Anglais).
4.1.1.3
Les bases de données relationnelles
Les SGBD hiérarchiques et réseaux constituent la première génération de SGBD.
Malheureusement ils comportaient certaines lacunes notamment au plan des fondements théoriques.
De plus ils ne permettaient pas en pratique d’assurer l’indépendance tant souhaitée entre les
applications et les données. En effet, comme le lien entre deux enregistrements était implanté à
l’aide d’un pointeur, soit une sorte d’adresse permettant de repérer un enregistrement associé, cela
donnait lieu à des programmes complexes même pour des requêtes simples. Le début des années
1970 a été marqué par une avancée importante dans le domaine des SGBD. Edgar Frank Codd,
chercheur au laboratoire de recherche d’IBM (International Business Machines) de San Jose en
Californie, s’inspirant de l’algèbre relationnelle, proposa un mode d’organisation des données ne
nécessitant pas de pointeurs pour lier les enregistrements. Non seulement ce modèle avait ses
fondements théoriques solidement établis dans l’algèbre relationnelle, mais il était aussi d’une
grande simplicité. La structure d’un fichier est définie comme une relation entre des données
provenant d’un nombre fini de domaines. Les enregistrement sont des tuples, et constituent des
occurrences de la relation. Les liens sont assurés entre deux enregistrements sur la base d’un champ
42
de même type, commun aux deux enregistrements. Si les champs communs possèdent la même
valeur, les enregistrements sont logiquement liés. Il n’est dès lors plus nécessaire de gérer des
pointeurs physiques pour assurer ces liens. De physiques qu’étaient les liens dans les SGBD
hiérarchiques ou réseaux, les liens sont dorénavant logiques, basés sur les valeurs des champs, ce
qui rend la navigation entre les enregistrements beaucoup plus souple. Ce mode d’organisation des
données a donné naissance à une pléthore 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 deuxième génération et ils ont tous en commun intrinsèquement un langage
appelé SQL (Structured Query Language) agissant à la fois comme langage de définition et langage
de manipulation de données. Malgré leurs nombreuses qualités, les SGBD relationnels ont un
certain nombre de lacunes pour l’expression de modèles de données à un haut niveau d’abstraction,
ce que nous définirons à la partie 4.3, comme le Modèle Conceptuel de Données.
4.1.1.4
Les bases de données orientées objets et autres
Le développement de langages orientés 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 mémoire auxiliaire des objets créés à l’aide de tels langages. Ce SGBD dit orienté objet
ou simplement SGBD objet appartient à la troisième génération. Le SGBD Gemstone par exemple
est une extension du langage Smalltalk. Le développement des SGBD objet a été freiné par des
SGBD hybrides incorporant le modèle relationnel et le stockage d’objets. Les objets peuvent être
soit de type structuré comme ceux créés par un langage orienté objet ou de type non structuré telles
que des images, de la vidéo, 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 propriétés du SGBD relationnel et du SGBD objet. L’éditeur américain Informix a été
un précurseur en matière de SGBD relationnel-objet pour être suivi et vite dépassé par Oracle et
IBM avec leur produit Oracle8 et DB2 Universal Database System respectivement. A l’aube du
XXIe siècle on parle d’une quatrième génération de SGBD. Il s’agit d’une catégorie hétérogène de
SGBD conçus avant tout pour des applications spécialisées, comme par exemple et non
exclusivement, les SGBD OLAP (On Line Analytical Processing) largement utilisés pour
l’entreposage des données et l’exploration des données, les SGBD XML pour les applications Web,
ou enfin les SGBD de contraintes pour les applications d’optimisation.
43
4.1.2 Merise, POO et UML
La conception d'un système d'information n'est pas toujours évidente dans la mesure où il
faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception
nécessite par conséquent des méthodes permettant de mettre en place un modèle sur lequel l’on va
s'appuyer. Il existe plusieurs méthodes d'analyse dont Merise et UML qui utilise principalement
l’approche objet.
4.1.2.1 Merise
Issue de l'analyse systémique, la méthode Merise est le résultat des travaux menés par
Hubert Tardieu, un ingénieur français diplômé de l’Ecole Supérieure d’Electricité (Supélec) en
France, dans les années 1970 et qui s'inséraient dans le cadre d'une réflexion internationale, autour
notamment du modèle relationnel d'Edgar Frank Codd. Elle est devenue un projet opérationnel au
début des années 1980 à la demande du ministère de l'industrie, et a surtout été utilisée en France,
pour les projets d'envergure, notamment des grandes administrations publiques ou privées.
De
l'aveu même 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
méthodes informatiques bien conçues, qui ne produisent de bons résultats que si la greffe sur
l'organisation réussit", même si beaucoup de gens ont voulu y voir un acronyme comme par
exemple Méthode d'Étude et de Réalisation Informatique par les Sous-Ensembles ou pour les
Systèmes d'Entreprises.
La
méthode Merise d'analyse et de conception propose une démarche articulée simultanément selon
trois (03) axes pour hiérarchiser les préoccupations et les questions auxquelles répondre lors de la
conduite d'un projet:
1.
Cycle de vie : phases de conception, de réalisation, de maintenance puis nouveau cycle de
projet.
2.
Cycle de décision : des grands choix (GO - NO GO : Étude préalable), la définition du projet
(étude détaillée) jusqu'aux petites décisions des détails de la réalisation et de la mise en
œuvre du système d'information. Chaque étape est documentée et marquée par une prise de
décision.
3.
Cycle d'abstraction : niveaux conceptuels, logique/organisationnel et physique/opérationnel
(du plus abstrait au plus concret). L’objectif est de prendre d'abord les grandes décisions
métier, pour les principales activités (Conceptuel) sans rentrer dans le détail de questions
d'ordre organisationnel ou technique.
44
La méthode Merise distingue nettement les données et les traitements, même si les
interactions entre les deux sont profondes et s'enrichissent mutuellement, la validation des données
étant effectuée par les traitements et réciproquement. Aujourd'hui, avec les SGBD Relationnel,
l'objet, les notions de données et de traitements sont de plus en plus imbriquées. La conception du
système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel
reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en
compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements,
il faut vérifier la concordance entre données et traitement afin de vérifier que toutes les données
nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues. Cette succession
d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information:
L'expression
des
besoins
est
une
étape
consistant à définir ce que l'on attend du
système d'information automatisé, il faut pour
cela faire l'inventaire des éléments nécessaires
et délimiter le système en s'informant auprès des
futurs utilisateurs. Cela va permettre de créer le
MCC
(Modèle
Communication)
Conceptuel
qui
de
définit
les
la
flux
d'informations à prendre en compte. L'étape
suivante consiste à mettre au point le MCD
(Modèle Conceptuel des Données) et le MCT
(Modèle Conceptuel des Traitements) décrivant
les règles et les contraintes à prendre en compte.
Le modèle organisationnel consiste quant à lui à
définir le MOT (Modèle Organisationnel des
Traitements)
décrivant
les
contraintes
Figure 4.3 : Cycle d'abstraction pour la
conception des systèmes d'information
organisationnelles, spatiales et temporelles dues
à
l'environnement.
Le
modèle
logique
représente un choix logiciel pour le système
d'information tandis que le modèle physique
reflète un choix matériel pour le système
d'information.
45
4.1.2.2 Programmation Orientée Objet (POO)
La Programmation Orientée Objet (POO), ou programmation par objet, est un paradigme de
programmation informatique élaboré par un informaticien américain nommé Alan Kay dans les
années 1970. Il consiste en la définition et l'interaction de briques logicielles appelées objets ; un
objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une
personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il
sait communiquer avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ; la
communication entre les objets via leurs relations permet de réaliser les fonctionnalités attendues,
de résoudre le ou les problèmes.
À partir des années 1980, commence l'effervescence des langages à objets : Objective C
(début des années 1980), C++ (C avec classes) en 1983, Eiffel en 1984, Common Lisp Object
System dans les années 1980, etc. Les années 1990 voient l'âge d'or de l'extension de la
programmation par objet dans les différents secteurs du développement logiciel.
Depuis, la programmation par objet n'a cessé d'évoluer aussi bien dans son aspect théorique
que pratique et différents métiers et discours mercatiques à son sujet ont vu le jour :
1. l’analyse objet (AOO pour Analyse Orientée Objet ou OOA en Anglais pour Object
Oriented Analysis),
2. la conception objet (COO pour Conception Orientée Objet ou OOD en Anglais (Object
Oriented Design)),
3. les bases de données objet (SGBDOO),
4. les langages objet avec les langages à prototypes,
5. ou encore la méthodologie avec MDA (Model Driven Architecture).
Aujourd’hui, 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 désigne avant tout la partie codage d’un modèle
à objets obtenu par AOO et COO. Elle ne renie pas la programmation structurée ; elle se fonde sur
elle. Elle contribue à la fiabilité des logiciels et facilite la réutilisation de code existant. Elle
introduit de nouveaux concepts, en particulier ceux d’objets, d’encapsulation, de classe et
d’héritage.
46
4.1.2.2.1 Les concepts d’objet et d’encapsulation
En programmation structurée, un programme est formé de la réunion de différentes
procédures et de différentes structures de données généralement indépendantes de ces procédures.
En POO, un programme met en œuvre différents objets. Chaque objet associe des données et des
méthodes agissant exclusivement sur les données de l’objet. Mais cette association est plus qu’une
simple juxtaposition. En effet, dans ce que l’on pourrait qualifier de POO « pure », on réalise ce que
l’on nomme une encapsulation des données. Cela signifie qu’il n’est pas possible d’agir directement
sur les données d’un objet; il est nécessaire de passer par ses méthodes, qui jouent ainsi le rôle
d’interface obligatoire. On traduit parfois cela en disant que l’appel d’une méthode est en fait
l’envoi d’un message à l’objet.
Le grand mérite de l’encapsulation est que, vu de l’extérieur, un objet se caractérise
uniquement par les spécifications de ses méthodes, la manière dont sont réellement implantées les
données étant sans importance. On décrit souvent une telle situation en disant qu’elle réalise une
abstraction des données, ce qui exprime bien que les détails concrets d’implémentation sont cachés.
A ce propos, on peut remarquer qu’en programmation structurée, une procédure pouvait également
être caractérisée, de l’extérieur, par ses spécifications, mais que, faute d’encapsulation, l’abstraction
des données n’était pas réalisée.
L’encapsulation des données présente un intérêt manifeste en matière de qualité de logiciel.
Elle facilite considérablement la maintenance : une modification éventuelle de la structure des
données d’un objet n’a d’incidence que sur l’objet lui-même ; les utilisateurs de l’objet ne seront
pas concernés par la teneur de cette modification, ce qui n’était bien sûr pas le cas avec la
programmation structurée. De la même manière, l’encapsulation des données facilite grandement la
réutilisation d’un objet.
4.1.2.2.2 Le concept de classe
Le concept de classe correspond simplement à la généralisation de la notion de type que l’on
rencontre dans les langages classiques. En effet, une classe n’est rien d’autre que la description d’un
ensemble d’objets ayant une structure de données commune et disposant des mêmes méthodes. Les
objets apparaissent alors comme des variables d’un tel type classe, on dit aussi qu’un 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 méthodes sont effectivement communes à l’ensemble des
objets d’une même classe. Lorsque, comme cela arrive parfois dans l’écriture d’interfaces
graphiques, on est amené à ne créer qu’un seul objet d’une classe donnée, la distinction entre les
notions d’objet et de classe n’est pas toujours très évidente. En revanche, lorsque l’on dispose de
47
plusieurs objets d’une même classe, le principe d’encapsulation s’appliquera à la classe et non à
chacune de ses instances.
4.1.2.2.3 L’héritage
Un autre concept important en POO est celui d’héritage. Il permet de définir une nouvelle
classe à partir d’une classe existante (qu’on réutilise en bloc), à laquelle on ajoute de nouvelles
données et de nouvelles méthodes. La conception de la nouvelle classe, qui hérite des propriétés et
des aptitudes de l’ancienne, peut ainsi s’appuyer sur des réalisations antérieures parfaitement au
point et les spécialiser à volonté. Comme on peut s’en douter, l’héritage facilite largement la
réutilisation de produits existants, d’autant plus qu’il peut être réitéré autant de fois que nécessaire
(la classe C peut hériter de B, qui elle-même hérite de A).
4.1.2.2.4 Le polymorphisme
En POO, une classe peut "redéfinir", c’est-à-dire modifier, certaines des méthodes héritées
de sa classe de base. Cette possibilité est la clé de ce que l’on nomme le "polymorphisme", c’est-àdire la possibilité de traiter de la même manière des objets de types différents, pour peu qu’ils soient
issus de classes dérivées d’une même classe de base. Plus précisément, on utilise chaque objet
comme s’il était de cette classe de base, mais son comportement effectif dépend de sa classe
effective qui est dérivée de la classe de base, en particulier de la manière dont ses propres méthodes
ont été redéfinies. Le polymorphisme permet d’ajouter de nouveaux objets dans un scénario
préétabli et, éventuellement, écrit avant d’avoir connaissance du type exact de ces objets
[7]
.
4.1.2.3 Unified Modeling Language (UML)
La première moitié des années quatre-vingt-dix (1990) a vu fleurir une cinquantaine de
méthodes objet utilisées dans la conception des programmes informatiques orientés objet. Un tri
effectué sur les différents concepts proposés par les méthodes existantes a donné lieu à l’unification
des méthodes de modélisations objet. Partant de la constatation que les différences entres les
méthodes s’amenuisent et que la guerre des méthodes ne fait plus progresser la technologie objet,
Jim Rumbaugh et Grady Booch décident fin quatre-vingt-quatorze (1994) d’unifier leurs travaux au
sein d’une méthode unique : la méthode unifiée (The Unified Method, en Anglais). Une année plus
tard, ils sont rejoints par Ivar Jacobson, le créateur des cas d’utilisation (use cases, en Anglais), une
technique très efficace pour la détermination des besoins. Ils se fixent quatre objectifs :
1. Représenter des systèmes entiers (au-delà du seul logiciel) par des concepts objets,
2. Etablir un couplage explicite entre les concepts et les artefacts exécutables,
48
3. Prendre en compte les facteurs d’échelle inhérents aux systèmes complexes et critiques,
4. Créer un langage de modélisation utilisable à la fois par les humains et les machines.
Les auteurs de la méthode unifiée atteignent très rapidement un consensus sur les concepts
fondamentaux de l’objet. En revanche, la convergence sur les éléments de notation est plus difficile
à obtenir et la représentation graphique retenue pour les différents éléments de modélisation
connaîtra plusieurs modifications. UML est à sa version 2.4 beta en Mars 2011 et comprend treize
(13) diagrammes dont les diagrammes de cas d’utilisation, de séquence, d’activité et de déploiement
que nous verrons de façon détaillée dans les sections qui suivent. UML n’est pas une notation
propriétaire : elle est accessible à tous les fabricants d’outils ainsi que les entreprises de formation.
La volonté d’ouverture, la richesse de la modélisation font d’UML une notation générale et simple,
sans être simpliste.
En français, UML pourrait se traduire par langage unifié pour la modélisation objet, mais il
est plus que probable qu’UML se traduise plutôt par notation unifiée, voire notation UML, sur le
même schéma que méthode OMT.
4.1.3 La sécurité informatique
En cryptographie numérique, chiffrer une information consiste à modifier la suite
d'octets qui constituent cette information au moyen d'un algorithme mathématique. 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
paramètre
supplémentaire
appelé
« clé ». Une
information chiffrée avec un algorithme connu restera déchiffrable par les seuls possesseurs de la
clé appropriée, même si l'algorithme est connu de tous. Les clés de chiffrement sont donc les
éléments essentiels dans la garantie du secret souhaité. Une fois le procédé 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 données. Le
premier désir est bien que les messages ne soient lisibles que par les seules personnes autorisées,
mais c'est loin de suffire, pour assurer une totale relation de confiance. Il faut un contrôle d’intégrité
et une authentification préalables des interlocuteurs.
49
4.1.3.2
Contrôle d'intégrité et authentification
4.1.3.2.1
Intégrité
Dans certains cas, il peut être nécessaire d'assurer simplement que les données sont intègres,
c'est à dire qu'elles n'ont pas été au passage falsifiées par un intrus. Ces données restent « claires »,
au sens où elles ne sont pas secrètes.
Un exemple simple serait le cas du partage en téléchargement d’un fichier contenant
une
application informatique. L’auteur voulant éviter la dénaturation de son application par
injection post-conception de code nuisible, tout en rendant le code source de l’application, sous
licences GPL, accessible au grand public , réalise un « résumé concis » du fichier, typiquement une
somme MD5 ou SHA suffisamment précise pour mettre en évidence toute modification ultérieure
du fichier (ces deux techniques de hachage sont expliquées dans l’annexe A.4). Mais sans
précautions supplémentaires, cela ne sera pas une protection infaillible, dans la mesure où celui qui
corrompt le fichier en téléchargement, 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 prétend être. Il s'agit en quelque sorte
d'une lettre manuscrite, non raturée et signée. Cela permet aussi d’assurer la non-répudiation. En
effet, celui qui a rédigé une lettre manuscrite, non raturée et signée de sa main, ne pourra en
aucun cas prétendre par la suite qu'il n'en est pas l'auteur ; il en va de même pour l'authentification
numérique faite au moyen de clés numériques et d’algorithmes soigneusement conçus.
4.1.3.2.2.1 Les clés, leurs types et leurs utilités
Il y a deux types de clés :
1. les clés dites symétriques, on chiffre et déchiffre avec la même clé.
2. les clés dites asymétriques, avec une clé publique et une clé privée, ce qui est chiffré avec
l'une ne peut être déchiffré qu'avec l'autre. Les deux clés sont uniques et sont liées
l'une à l'autre ; mais si la clé privée est confidentielle, la clé publique peut, quant à
elle, être copiée à volonté.
50
Il s'agit en fait d'un abus de langage. Les clés ne sont pas symétriques ni asymétriques, ce
sont les procédés de chiffrement qui le sont.
4.1.3.2.2.2 Chiffrement symétrique
C'est le plus « facile à comprendre », c'est aussi la méthode de chiffrement la plus facile à
réaliser et qui consomme le moins de ressources de calcul et de bande passante.
Les deux hôtes qui doivent échanger des données confidentielles disposent tous les deux
d'une clé identique. L'émetteur chiffre les données avec cette clé, puis les envoie au récepteur. Ce
dernier déchiffre avec la même clé pour récupérer des données lisibles.
Cette méthode assure la confidentialité des données car quiconque intercepterait la
communication ne pourrait pas lire les données échangées tant qu'il ne se serrait pas procurer la
clé. Il n'y a aucune authentification de faite sur l'émetteur comme sur le récepteur, sauf si deux
personnes seulement disposent de la clé. Le principal souci avec cette méthode, c'est qu'il faut
s'échanger la clé et lors de cet échange, sans précautions particulières, n'importe quoi peut se
produire. Un exemple de cette technique cryptographique est le chiffrement WEP (Wired
Equivalent Privacy) utilisé dans les réseaux WI-FI où seuls les terminaux disposant de la clé WEP
peuvent avoir accès au réseau sans fil.
4.1.3.2.2.3 Chiffrement asymétrique
Cette méthode permet de faire aussi bien l'authentification que la confidentialité des
données. Il est évidemment possible de combiner les deux. Chaque personne dispose d'un jeu de
clés comportant :
1. une clé privée : elle est unique et confidentielle, elle appartient exclusivement à l'hôte
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 dépositaire, dit « tiers de confiance ». Il s'agit en
quelque sorte d'un concierge qui garde ces clés publiques et certifie qu'elles appartiennent
bien à la personne indiquée,
Ce qui est chiffré avec une clé publique ne peut être déchiffré qu'avec la clé
privée correspondante et réciproquement. Cette technique permet d’effectuer une authentification
efficace entre un nombre élevé d’interlocuteurs lorsque le chiffrement se fait avec la clé privée et
non le contraire. En effet, lorsqu’un message chiffré est déchiffré avec une clé publique, il ne peut
avoir été chiffré qu’avec la clé privée de celui à qui appartient cette clé publique ; et comme
l’unicité des clés est assurée dans le système, le tour est bien joué.
51
Il existe dans le monde plusieurs organismes à but lucratif qui fournissent les services
d’autorité de certification (Certification Authority (CA), en Anglais). Lorsque l’on s'adresse à un tel
organisme pour récupérer une clé publique, il l'envoi avec un certificat. Il s'agit, pour ledit
organisme, de chiffrer la clé publique demandée, ainsi que quelques informations supplémentaires
sur le propriétaire de cette clé, avec sa propre clé privée, pour authentifier son envoi. Il ne reste
plus qu’à disposer de la clé publique de cet organisme dit tiers de confiance, par un moyen sûr pour
déchiffrer le message et récupérer la clé envoyée. Les certificats sont à la norme X.509. Par
exemple, les navigateurs installent, généralement à l’insu de l’internaute,
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 numérique sous Mozilla Firefox
Voici un résumé du contenu d'un certificat (remarquons la présence d’une clé publique sur la
figure Figure 4.4.c) :
52
Figure 4.4.b : Contenu d’un certificat numérique
Figure 4.4.c : Exemple de clé publique dans un certificat numérique
53
Le volume de données chiffrées à l’aide d’une clé privée devenant trop important avec le
temps, les chances de découverte de cette clé par un intrus augmente significativement, d’où la
nécessité de prévoir une durée de vie à cette clé et donc au certificat. Comme une clé peut se perdre
ou être volée, il faudra aussi prévoir un système « d'opposition », une liste de révocation, qui permet
de signaler les certificats non encore expirés, mais qui ne sont plus dignes de confiance pour une
raison quelconque. Le CA se doit donc de tenir à jour une liste de révocation, et, lorsqu'un
utilisateur doit user d'un certificat qui est déjà en sa possession, il devrait commencer par vérifier si
celui-ci n'a pas été révoqué entre temps.
4.2
Modélisation de l’application
La modélisation consiste à créer une représentation virtuelle d'une réalité de façon à faire
ressortir les points auxquels on s'intéresse. Elle a l’avantage indubitable de simplifier la conception
de logiciel en la rendant assez rationnelle. Il existe plusieurs méthodes de modélisation dont UML
que nous utilisons pour modéliser l’application au moyen de diagrammes de cas d’utilisation, de
séquence, d’activité et de déploiement.
4.2.1 Expression des besoins
L’observation du système opérant (le processus d’affectation en sixième et d’orientation en
seconde et le processus d’attribution et de renouvellement de bourses en Côte d’Ivoire) et l’échange
avec des personnes ressources, nous ont permis de définir les besoins éventuels que pourrait
manifester un utilisateur de la plateforme et de procéder à leur modélisation pour la conception d’un
système informatique convenable et fiable.
L’expression des besoins s’est faite à l’aide de l’outil d’analyse et de modélisation UML
comme l’illustre la figure 4.5. Ce diagramme de cas d’utilisation nous permet de présenter les
besoins de manière graphique pour faciliter leur étude. Nous en déduisons quatre (04) acteurs
principaux sur notre système ; à savoir IEP, ETABLISSEMENT, DOB et ADMINISTRATEUR.
Ces différents acteurs utilisent le système 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
différents examens. Il s’agit de renseigner la base de données à l’aide du masque de saisie
offert par le logiciel.
2. DOB se charge de fusionner les données transmises par les structures éloignées et gère
toutes les opérations utiles à la ténue de la CNO et de la CNB. Il peut aussi exécuter les
actions de tous les autres acteurs.
54
3. ADMINISTRATEUR
quant
à
lui
effectue
les
configurations
nécessaires
au
fonctionnement du système informatique. Il peut exister un ou plusieurs administrateurs
dans chaque structure concernée par le déploiement de l’application.
Tous les acteurs ont la possibilité d’imprimer des états relatifs à leurs activités sur le système.
Toutefois, l’accès au système n’est possible qu’après identification et authentification de l’acteur.
APPLIDOB est le nom de l’application conçue.
Appl icati on de gestion automati sée des trav aux de la CNO et CN B
IEP
Enregis trer élèves 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 d’utilisation d’APPLIDOB
4.2.2 Algorithmes de résolution des besoins
Le paragraphe précédent nous montre les différents besoins à combler. Ainsi, nous
constatons bien qu’une base de données s’avère indispensable dans la conception de la plateforme
demandée.
Le concepteur de base de données a la possibilité d’interroger cette dernière en ligne de
commande. Néanmoins, la plupart des SGBD modernes offre une interface graphique pour
l’administration de ces bases de données. Mais, l’utilisation de ces interfaces nécessite une
connaissance informatique plus ou moins poussée. Il s’avère alors nécessaire de créer une interface
adaptée au système que l’on cherche à modéliser. Cette interface doit être la plus simple possible
pour permettre à l’utilisateur moyen d’utiliser la base de données sans grands efforts. Certains
55
SGBDR modernes tels que Microsoft Access, HyperFileSQL de PC SOFT…, offrent la possibilité
de créer des formulaires personnalisés.
En outre, la base de données, ayant la vocation de desservir toutes sortes d’applications dans
des domaines variés, les concepteurs de SGBD mettent à la disposition des développeurs de
logiciels des interfaces appropriées pour faire communiquer leurs applications et la base de
données, généralement dans une architecture distribuée de type client/serveur.
Figure 4.6 : Procédure de communication avec une base de données dans une architecture distribuée
de type client/serveur
4.2.2.1 Connexion au système
La sécurité et la confidentialité des données, indispensables au système qui nous est soumis,
nous amènent à définir une méthode particulière de connexion à l’application. Le déroulement des
opérations est présenté sur le diagramme de séquence de la figure 4.7.
L’utilisateur demande la connexion au système en soumettant au serveur un formulaire
contenant son identifiant et son mot de passe. Le serveur interroge la base de données pour
identifier et authentifier cet utilisateur. Il est important de préciser que les mots de passe sont
cryptés au sein de la base de données, ce qui renforce la sécurité du système. Si l’authentification
est positive, une connexion à la base de données est ouverte pendant la durée de la session, sinon le
56
formulaire d’authentification est réaffiché. L’utilisateur correctement identifié et authentifié a accès
aux interfaces associées à son profile. En effet le serveur de base de données transmet les données
du profil de l’utilisateur à l’application en vue de lui adapter l’interface affichée.
Appl icati on (AP PLIDOB)
Serveur de bas e de données
Base de données
Uti lis ateur
FormaterRequête (Identifiant, Pass word)
Exéci terRequête (Identifi ant, Pas sword)
DonnerInfo (Identifiant, Pass word)
Recevoi rInfo ()
Recevoi rInfoIntègre ()
Choi sirOpération ()
Figure 4.7 : Diagramme UML de séquence relatif à la connexion au système
4.2.2.2 Ajout d’information
Le système opérant est dynamique. Cela est pleinement visible à travers les diverses
opérations comme l’enregistrement des candidats dans la base de données, l’enregistrement des
différentes notes, la précision des barres d’admission… ; il en découle un dynamisme inéluctable de
notre système informatique afin de traduire textuellement le système opérant. Ces opérations de
mise à jour de la base de données se font selon une logique unique : Après l’indentification et
l’authentification de l’utilisateur, les informations fournies par ce dernier sont testées pour voir si
toutes les informations obligatoires ont été fournies. Le SGBD HyperFileSQL se charge de vérifier
automatiquement les règles d’intégrités exigées par la structure de la base de données. Si toutes les
règles sont respectées, la base de données est mise à jour, sinon un message d’erreur adéquat est
affiché pour aider à la correction des erreurs.
57
Appl icati on (AP PLIDOB)
Base de données
Uti lis ateur
FormaterRequêteMA J (paramètres )
ExécuterRequêteMA J (paramètres )
SauvegarderInfo (paramètres )
Recevoi rEtatMA J ()
Recevoi rEtatMA JIntègre ()
Recevoi rEtatMA JFormater ()
Figure 4.8 : Diagramme UML de séquence relatif à la mise à jour de la BD
4.2.2.3 Consultation
La consultation du système est réalisable par tout utilisateur authentifié. Il s’agit de la
recherche d’information de divers ordres (affichage d’états en général). Tout cela se fait sous l’œil
vigilant du serveur qui ne peut permettre à l’utilisateur de visualiser des données non associées à
son profile.
Appl icati on (A PPLIDOB)
Base de données
Uti lis ateur
FormaterRequête (paramètres )
ExécuterRequête (paramètres )
DonnerInfo (paramètres)
Recevoi rInfo ()
Recevoi rInfoIntègre ()
Recevoi rInfoFormater ()
Figure 4.9 : Diagramme UML de séquence relatif à la consultation d’information
58
4.2.2.4 Algorithme d’affectation et d’orientation automatiques
4.2.2.4.1 Algorithme d’affectation automatique en sixième
L’algorithme implémenté pour effectuer l’affectation automatique en sixième se présente
comme suit : premièrement, on détermine tous les élèves affectables, c’est-à-dire tous les candidats
dont le TGP et l’AGE sont respectivement supérieur ou égal au TGP minimum et inférieur ou égal à
l’AGE maximum fixés par le MEN (D’autres critères peuvent être spécifiés par le MEN). Ensuite,
ce résultat subit un classement par ordre décroissant des TGP. Les candidats, sont successivement
affectés selon leurs vœux d’établissements. Si un candidat n’a pas pu être affecté dans son vœu de
prédilection pour cause de saturation des effectifs, le processus est répété pour son vœu de niveau
immédiatement inférieur, jusqu’à épuisement éventuel des trois (03) vœux (Le nouveau système
prévoit dix (10) vœux maximum). Dans ce dernier cas, l’on considère un établissement proche de la
localité du candidat qui n’est pas encore saturé et l’y affecte. Une liste des candidats affectés hors
de leurs vœux est délivrée par le programme pour les opérations post affectation automatique.
4.2.2.4.2 Algorithme d’orientation automatique en seconde
Pour l’orientation en seconde, plusieurs algorithmes ont été proposés. Néanmoins, la base de
tous ces algorithmes est pratiquement identique à celle de l’affection en sixième, à la seule grande
différence qu’en plus des établissements, les candidats formulent des vœux de séries. Par
conséquent, la vérification de la disponibilité de places se fait sur le quota des séries : Si la série
demandée par le candidat dans son établissement de prédilection est déjà saturée, on réitère le même
processus pour le vœu d’établissement suivant. A l’épuisement infructueux de tous les vœux
d’établissements du candidat, on considère un établissement proche de sa localité qui n’est pas
encore saturé et on l’y oriente. La barre pour l’orientation en seconde est fixée par rapport à la
Moyenne d’Orientation (MO) par le MEN. Il est aussi important de préciser que l’accès à une série
obéit à des critères de profil. En effet, lorsque le candidat affectable a une MO inférieure à douze
(12) (une autre moyenne pourra être utilisée) sur vingt (20) (sinon, il est absolument affecté dans sa
série de prédilection), un calcul de moyenne de profil est fait. Il s’agit du profil Littéraire avec les
moyennes en Anglais et Français (d’autres matières pourront être prises en compte), et du profil
Scientifique comprenant les moyennes de Mathématiques et Sciences Physiques (d’autres matières
pourront être prises en compte). La moyenne de profil la plus élevée définit la série à attribuer au
candidat. Toutefois, la liste des candidats orientés de cette manière est fournie pour facilité
d’éventuelles prises de décision. Le diagramme ci-dessous présente les grandes lignes de
l’algorithme de base dans les deux cas (affectation et orientation).
59
Figure 4.10 : Diagramme UML d’activité relatif à l’affectation automatique en sixième et à
l’orientation automatique en seconde
60
4.3
Modélisation de la base de données
Une base de données est une collection d’informations ou de données structurées qui
qualifient les activités d’une organisation appelée système opérant. Ces données doivent pouvoir
être utilisées par des programmes et par des utilisateurs différents
[8]
. Un serveur est un équipement
ou une application disposant de services qu’il met à la disposition d’autres systèmes appelés clients.
Dans cette section, nous allons nous pencher essentiellement sur la modélisation de la base de
données, élément clé du projet. La modélisation est faite selon le formalisme entité-association avec
les notations de Merise. Un modèle est une représentation simplifiée de la réalité. Un modèle de
données est une représentation abstraite des données d’un système d’information. Une entité est un
objet concret ou abstrait du monde réel au sujet duquel une organisation est susceptible de
conserver des données (Entity en Anglais). Une association est un lien sémantique qui existe entre
deux entités ou plus. Elle représente souvent la mémoire d’un événement qui a permis d’établir un
lien logique entre ces entités (Relationship en Anglais)
[9]
.
4.3.1 Le Modèle Conceptuel de Données (MCD)
Un MCD (Conceptual Data Model en Anglais) est une représentation des besoins en matière
de données pour un système d’information. Il met en évidence les entités, leurs attributs, les
associations et contraintes entre ces entités pour un domaine donné. Cette représentation, de nature
sémantique, ne comporte aucune indication concernant la structure de mémorisation des données
associées aux entités
[10]
.
Pour effectuer une modélisation efficiente, nous avons subdivisé notre système en huit (08)
sous-systèmes relativement indépendants. Il s’agit des sous-systèmes :
1. Identification qui concerne les informations qui permettent d’identifier et de localiser un
candidat,
2. Evaluation notes qui prend en compte les différentes notes des candidats,
3. Evaluation cadres qui définit les cadres d’évaluation des candidats,
4. Vœux qui contient les vœux d’établissements et de séries des candidats
5. Authentification pour l’authentification des données transmises par CD,
6. Bourses pour les données relatives à la bourse.
7. Cartographie pour l’interconnexion des différentes structures,
8. Collaboration pour les informations relatives aux différents collaborateurs.
Les différents MCD sont présentés dans l’annexe A.1.
61
4.3.2 Le Modèle Logique de Données Relationnel (MLDR)
Maintenant que le MCD est établi (voir l’annexe A.1 pour les règles de normalisation), on
peut le traduire en différents systèmes logiques et notamment les bases de données relationnelles
qui proposent une vision plus concrète pour modéliser la situation. Cela se fait par passage au
MLDR. Un MLD (Logical Data Model en Anglais) est un modèle de données découlant d’un
modèle conceptuel mais qui le raffine pour tenir compte des caractéristiques du type de SGBD
utilisé pour la réalisation de la base de données
[11]
. Toutefois cette « mutation » se fait selon des
règles qui sont spécifiées dans l’annexe A.3.
4.3.3 Le Modèle Physique de Données (MPD)
Un MPD (Physical Data Model en Anglais) est un modèle de données découlant d’un
modèle logique qui spécifie les détails d’implantation du modèle logique dans un SGBD,
habituellement formulés grâce à un script de définition de données
[12]
. Pour la réalisation de la
plateforme, nous avons trouvé avantageux d’utiliser une base de données HyperFileSQL étant
donné que la DOB dispose déjà de la licence d’utilisation de WINDEV. Le mode client/serveur est
utilisé, contrairement à ce qui se faisait déjà, pour suivre l’architecture déjà exposée dans les parties
précédentes ; à savoir l’architecture distribuée de type client/serveur à échelle réduite. Quelques
informations sur les performances d’HyperFileSQL sont données dans l’annexe A.6.
62
TROISIEME PARTIE : DEPLOIEMENT DE LA SOLUTION
Cette dernière partie du mémoire expose les différentes techniques à mettre en œuvre pour
déployer le nouveau système informatique et profiter pleinement de ses fonctionnalités.
63
CHAPITRE 5 : DEPLOIEMENT MATERIEL
Le matériel, c’est l’ensemble des équipements physiques utilisés dans un système
informatique. L’étude technique nous a permis, dans le chapitre 3, de définir une architecture
optimale pour le projet qui nous a été soumis : l’architecture distribuée de type client/serveur à
échelle réduite. Mais, pour atteindre l’objectif fixé, les équipements doivent être de bonne qualité
tend bien au niveau de la robustesse physique, de la puissance d’action, qu’au niveau de leur
aptitude à être interconnectés.
5.1 Pour le service informatique de la DOB
Le SIS est le nœud central du processus automatisé menant aux différentes commissions
nationales. Il a la charge de fédérer toutes les données issues des autres sites dans une base de
données commune, en vue d’effectuer un traitement global. Il est par conséquent évident que les
caractéristiques du matériel utilisé à ce niveau doivent obéir aux « normes internationales » de
système d’information de la taille du système traité.
Les capacités sont spécifiées au prorata de l’effectif annuel moyen de candidats (environ
trois cent mille (300.000)).
5.1.1 Nœuds de l’architecture
Les nœuds, ce sont le ou les serveurs de base de
données et les ordinateurs clients qui interagissent avec la base
de données via le réseau local.
Pour ce qui est du serveur, il faudrait pour une
rentabilité optimale, utiliser un serveur de grande capacité
mémoire (au moins cinq cents Giga-octets (500 Go)). L’accès
Figure 5.1 : Serveur de base de
disque doit être très rapide. Il doit surtout avoir une très grande
données
mémoire vive (RAM, Random Access Memory) (huit Gigaoctets (08 Go) pourrait suffire), et un ou plusieurs processeurs
rapides (plus de quatre Gigahertz (04 GHz)), pour l’exécution
simultanée de requêtes et procédures stockées.
Néanmoins, des ordinateurs personnels entièrement
dédiés, pourront jouer (à l’extrême), en partie, le rôle de
serveur, pour minimiser le coût de réalisation. Les ordinateurs
serveurs devraient avoir les caractéristiques minimales Figure 5.2 : Ordinateur personnel
64
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 données au cours des années.
5.1.2 Equipements d’interconnexion
Les équipements d’interconnexion sont
l’ensemble des éléments matériels utilisés pour
interconnecter les différents nœuds ; ce sont les
éléments de base d’un réseau informatique. Il y
a nécessité d’avoir au moins :
>
Du câble à paire torsadée de catégorie
cinq (05) (non) blindé (UTP/STP 5,
Unshielded
Twisted
Twisted
Pair),
comme
lien
Pair/Shielded
correctement
d’interconnexion
Figure 5.3 : Câble à paires torsadées
blindé
serti,
des
nœuds,
>
Un switch (avec dix (10) ports Ethernet)
comme concentrateur,
>
Figure 5.4 : Switch Dlink 24 Ports
Une carte réseau Ethernet fonctionnelle
par nœud.
Figure 5.5 : Carte réseau Ethernet - RJ45
5.2 Pour les services informatiques des structures éloignées
Les structures éloignées (IEP, ETABLISSSEMENTS…) qui ont droit au logiciel, pourront,
dans la mesure du possible, implémenter la même architecture que celle qui a été définie pour le
SIS. Néanmoins, pour minimiser les coûts de réalisation, il est possible, comme nous l’avons
spécifié dans le paragraphe 3.3.2, de ramener le réseau entier à un seul ordinateur. En effet tout
65
ordinateur sur lequel est installé un système d’exploitation valide et fonctionnel, est en réseau avec
lui-même : ce réseau s’appelle boucle locale (local loop, en Anglais). Dans ce réseau, l’ordinateur
est identifié par l’adresse universelle 127.0.0.1 ou le nom localhost. Cette solution monoposte
présentera bien sûr l’inconvénient majeur de ne permettre que des opérations séquentielles. On ne
pourra, en effet, pas faire de véritable contrôle pendant la saisie de données. En plus, et pire,
plusieurs opérateurs de saisies ne pourront pas travailler simultanément sur la même base de
données ; ce qui augmentera surement le temps de saisie de données.
Si ces structures veulent garder l’architecture réseau, 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 données au cours des années. Les ordinateurs clients n’ont pas nécessairement
besoin d’avoir des caractéristiques 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. Néanmoins,
il faudra un minimum de dix (10) Méga-octets libre sur le disque pour stocker les informations
temporaires générées par le logiciel.
5.3 Sécurité matérielle
La sécurité matérielle concerne essentiellement tout ce qui contribue, d’une part, à garder les
équipements hors de la portée de personnes malveillantes, et d’autre part à la protection contre les
variations de niveaux d’alimentation en électricité.
5.3.1 Protection contre les vols
Dans une société, où la criminalité est sans cesse galopante, des personnes mal intentionnées
ne se gêneraient pas à dépouiller une structures publique de son patrimoine informatique ; raison
pour laquelle, différentes mesures de sécurités doivent être mise en œuvre en guise de prévention
contre les vols. Les équipements devront être installés dans des salles closes. En outre, l’accès à ces
salles devra être interdit aux personnes étrangères au service en charge du système. Enfin, les portes
et les fenêtres devront être recouvertes de grilles métalliques protectrices.
5.3.2 Protection contre les pannes électriques
La Côte d’Ivoire a connu environ cinq (05) mois de crise d’électricité en 2011 donnant lieu à
des temps de délestage, plus ou moins nuisibles aux systèmes de production à base d’électricité. De
cette expérience nous gardons la leçon de la nécessité de se procurer des onduleurs capables
d’allonger la fourniture d’électricité pendant un temps suffisant pour éteindre convenablement tous
66
les équipements du système matériel, voire pour continuer le travail entamé. En effet, les
ordinateurs, n’étant, en général, pas équipés de batterie, ils n’ont aucune autonomie propre en
électricité et toute rupture de la fourniture en électricité de l’opérateur national d’électricité entraîne
automatiquement l’arrêt des équipements. Cela peut sans doute occasionner des pertes
d’information, voire des pannes au niveau du matériel. Par ailleurs, les différentes structures
pourront même se procurer des groupes électrogènes pour ne pas entièrement dépendre de
l’opérateur national d’électricité.
Les salles « serveur » devront être dotées d’équipements de conditionnement d’air
fonctionnels, pour réguler la température à un maximum de vingt-cinq degré Celsius (25°C), en vue
protéger les composants électroniques contre la surchauffe.
67
CHAPITRE 6 : DEPLOIEMENT LOGICIEL
Dans le chapitre précédent, nous avons défini les différents éléments matériels à fournir pour
rentabiliser le système de production. Cependant, nous sommes sans ignorer qu’en informatique, le
matériel sans le logiciel est d’une vile utilité. C’est pourquoi nous détaillons dans ce chapitre, la
répartition des différents composants logiciels conçus sur l’architecture matérielle précédemment
présentée.
6.1 Pour le service informatique de la DOB
Nous avons développé une application de base de données, c’est-à-dire une application qui
exige l’existence d’une base de données pour fonctionner. La base de données devra être déployée
sur les différents serveurs matériels (ou ordinateurs jouant le rôle de serveur). Il faudra au préalable
installer sur ces serveurs physiques le logiciel serveur HyperFileSQL Client/Serveur de PC SOFT,
compatible avec la plus récente version de WINDEV (Version 16).
Une fois la base de données correctement déployée, il faudra installer l’application cliente
sur les ordinateurs clients. Aucun pré requis logiciel n’est exigé sauf qu’il faudra disposer d’un
système d’exploitation issu du monde Microsoft (Microsoft XP, VISTA ou SEVEN). En effet, tous
les éléments logiciels nécessaires à la bonne marche de l’application seront incorporés aux
composants d’installation et seront automatiquement installés à l’insertion du CD-ROM
d’installation.
6.2 Pour les services informatiques des structures éloignées
Les structures éloignées suivront les mêmes procédures de déploiement logiciel que ce qui a
été défini pour le SIS. Toutefois, dans le cas où le réseau est ramené à un seul ordinateur, le logiciel
serveur pourra être déployé sur le même ordinateur que l’application cliente.
6.3 Sécurité logicielle
Parler de sécurité dans un système d’information numérique, revient sans doute à parler de
la nécessité d’empêcher l’accès frauduleux à des données sensibles par des programmes
malveillants. En effet, de la même manière qu’une personne mal intentionnée peut dépouiller une
structure de son patrimoine informatique, un programme habilement conçu peut effectuer des
opérations nuisibles au système d’information. Un des problèmes de sécurité généralement
rencontré dans les systèmes d’information est l’injection de code SQL dans la base de données à des
fins d’espionnage ou de sabotage. Mais, d’après PC SOFT (Concepteur de HyperFileSQL),
l’injection de code SQL est impossible avec les bases de données HyperFileSQL (Voir Annexe
68
A.6). Loin de nous fixer définitivement sur cette assertion, nous avons implémenté des mécanismes
de sécurité qui exigent l’identification et l’authentification de toute personne qui accède à la base de
données. Tout utilisateur devra fournir un identifiant et un mot de passe avant de pouvoir accéder à
la base de données, voire avant d’utiliser l’application. Les utilisateurs ne sont créés que par le
super-utilisateur qui est l’utilisateur par défaut à l’installation du logiciel. Ce dernier pourra
accorder des droits ou en révoquer à tout utilisateur. La journalisation dans HyperFileSQL pourra
nous aider à déterminer automatiquement toute action non autorisée et à prendre les décisions
idoines pour ne pas saper la CNO et la CNB. Enfin, le hachage et un mécanisme d’authentification
à clés asymétrique nous permettront d’assurer l’intégrité et l’authenticité des données transportées
par CD.
69
CONCLUSION
La quasi-totalité des organismes de ce 21ième siècle fonctionne avec un système
d’information informatisé. La Direction de l’Orientation et des Bourses (DOB), ne voulant pas
rester en marge de cette avancée technologique, a mis en place un système d’information
automatisé pour gérer ses activités depuis 2005. Mais les applications conçues présentent certaines
faiblesses qui obèrent la qualité des résultats issus des différentes commissions nationales. C’est ce
qui a justifié notre présence au sein du Service Informatique et Statistiques (SIS) de la DOB, où
nous avons travaillé à la mise en place d’un nouveau système d’information pour la gestion des
travaux de la Commission Nationale d’Orientation (CNO) et de la Commission Nationale des
Bourses (CNB). Il s’agissait pour nous de concevoir, à l’aide de l’AGL WINDEV, un système qui
résout les problèmes rencontrés par les applications existantes.
Pour nous convaincre de la nécessité de rénover ce système informatique, nous en avons
effectué une étude détaillée. Cette étude nous a permis de déceler une gamme de failles au niveau
matériel, logiciel et de la main d’œuvre qui ont résolu nos doutes. En outre, animés du souci
permanent de concevoir un système qui obéit aux « normes internationales » de conception de
système d’information, nous avons procédé à la modélisation du système global au moyen de
concepts divers comme UML, Merise et l’Orienté Objet. Bien que le développement du logiciel
n’ait pas atteint sa phase finale, du fait du retard d’acquisition de la licence d’utilisation de l’AGL
WINDEV et de collaboration du SIS, nous avons expliqué le déploiement matériel et logiciel du
système global, tout en spécifiant les techniques sécuritaires à implémenter.
Ce stage nous a permis, en plus de la maîtrise de l’AGL WINDEV, de mettre en application
nos connaissances en matière de conception de système d’information. Encore mieux, nous en
avons tiré l’avantage de tisser des relations durables avec certains acteurs du système éducatif
ivoirien.
Néanmoins, nous ne pouvons pas nous arrêter en si bon chemin, car l’architecture distribuée
de type client/serveur à échelle réduite adoptée présente des inconvénients hérités de l’architecture
monoposte, qu’il faudra résoudre dans un futur proche, en l’étendant à l’échelle 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
système d’information.
70
REFERENCES WEBOGRAPHIQUES
[1]
TETY Pierre, Ingénieur Télécoms & Réseaux de l'INP-HB | Présentation de la Filière,
<http://membres.multimania.fr/lenetwork/Pages/presentation.php>, consultée le 13 Juillet 2011 à
09h40
[2]
DECO, Historique, < http://deco.ci/historique.php>, consultée le 17 Aout 2011 à 09h26
[15]
Wikipedia, MD5, <http://fr.wikipedia.org/wiki/MD5>, consultée le 16 Août 2011 à 10h43
[16]
Wikipedia, SHA-1, <http://fr.wikipedia.org/wiki/SHA-1>, consultée le 16 Août 2011 à 10h50
[17]
PC SOFT, HyperFileSQL, <http://blogs.pcsoft.fr/rss.awp?blog=hyperfilesql_performances>,
consultée le 19 Juillet 2011 à 11h37
REFERENCES BIBLIOGRAPHIQUES
[3] [6] [9] [10]
,
,
,
et [11] Gilles ROY, 2009. Conception de bases de données avec UML, Presses de
L’Université du Québec, P 8, P14, PP33, 32, 144.
[4]
Guy Pujolle, 2008, Les Réseaux, EYROLLES, P 15
[5]
Le Grand Robert de la langue française, 2005, version 2.0, mot-clé : contrainte
[6]
Gilles ROY, 2009. Conception de bases de données avec UML, Presses de L’Université du
Québec, P 14
[7]
[8]
Claude Delannoy, 5ième édition, Programmer en Java, EYROLLES, P 6
Cours de M. KOFFI Luc, Enseignant à l’INP-HB
[12] [13]
,
et [14] Cyril GRUAU, 2006. Conception d’une base de données, PP 10-14, 15, 24-26
71
ANNEXES
A.1 Les règles de normalisation d’un MCD ................................................................................. lxxiii
A.2 Résultats de l’atelier d’analyse diagnostique et de validation des applications de gestion des
actes de la CNO et de la CNB ....................................................................................................... lxxiii
A.3 Les règles de traduction d’un MCD en MLDR ................................................................... lxxxvii
A.4 L’interface Homme-Machine (IHM) d’APPLIDOB .......................................................... lxxxviii
A.5 Techniques de Hachage .............................................................................................................xcii
A.6 HyperFileSQL .......................................................................................................................... xcvi
ANNEXES
A.1 Les règles de normalisation d’un MCD
[12]
1. Normalisation des entités : toutes les entités qui sont remplaçables par une association
doivent être remplacées.
2. Normalisation des noms : le nom d’une entité, d’une association ou d’un attribut doit être
unique.
3. Normalisation des identifiants : chaque entité doit posséder un identifiant.
4. Normalisation des attributs : remplacer les attributs en plusieurs exemplaires en une
association supplémentaire de cardinalité maximales n et ne pas ajouter d’attribut calculable
à partir d’autres attributs.
5. Normalisation des attributs des associations : les attributs d’une association doivent
dépendre directement des identifiants de toutes les entités en association.
6. Normalisation des associations : il faut éliminer les associations fantômes (associations
ayant des cardinalités de type 1-1), redondantes ou en plusieurs exemplaires.
7. Normalisation des cardinalités : 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. Première forme normale : à un instant donné dans une entité, pour un individu, un attribut ne
peut prendre qu’une valeur et non pas un ensemble ou liste de valeurs.
NB : Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l’objet d’une
entité supplémentaire, en association avec la première.
2. Deuxième forme normale : l’identifiant peut être composé de plusieurs attributs mais les
autres attributs de l’entité doivent dépendre de l’identifiant en entier (et non pas une partie
de cet identifiant).
3. Troisième forme normale de Boyce-Codd : tous les attributs d’une entité doivent dépendre
directement de son identifiant et d’aucun autre attribut.
A.2 Résultats de l’atelier d’analyse diagnostique et de validation des applications de gestion
des actes de la CNO et de la CNB
Dans le souci de réduire au strict minimum le travail manuel, de fiabiliser les résultats de la
CNO et réduire le temps de travail, un logiciel de sélection et d’affectation automatique, a été conçu
et mis en application depuis l’année 2005. Après six ans de mise en œuvre du logiciel, un atelier
regroupant les experts de l’INP-HB, les responsables et les informaticiens de la DOB a été organisé
lxxiii
ANNEXES
du 27 juin au 1er juillet 2011 en vue d’examiner et proposer
les améliorations idoines
de
l’application existante.
Pour mener à bien ces travaux l’atelier s’est d’abord attelé à cerner toute la procédure de la
CNO depuis les travaux préparatoires jusqu’aux travaux post CNO afin de comprendre et de
maîtriser toutes les phases et les mécanismes de fonctionnement. Ensuite, l’atelier s’est évertué à
modéliser tous les actes de la CNO pour s’assurer de la prise en compte de tous les éléments
indispensables par l’application existante. Enfin, des recommandations ont été faites tant au niveau
informatique, des équipements nécessaires qu’au plan administratif en vue d’apporter des
améliorations. Cette section des annexes rend compte des résultats obtenus et des recommandations
faites.
A.2.1 Pour la sixième
Opérateur
1000 Centre d'examen (Délibération)
Opérateur
1000 Centre d'examen (Délibération)
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
Contrôler les données saisies
IEP
Classer les fiches par ordre de mérite (manuel)
IEP
Traiter les données
IEP
Etablir les états cumulatifs (manuel)
IEP
Editions
Etablir la liste des admis
IEP
IEP
des TGP
IEP
des Etats
Remplir les relevés de notes individuels
IEP
statistiques (A définir)
IEP
des Etats
cumulatifs
IEP
de la Liste
des admis
Production de CD
2000 IEP D'ORIGINE
Réceptionner les fiches d'affectation
2000 IEP D'ORIGINE
IEP
Réceptionner les listes des admis
IEP
Réceptionner la fiche
Réceptionner les PV d'examen
IEP
Réceptionner les états cumulatifs
vérifier les documents ci-dessus
informatique (PV)
IEP
IEP
Réceptionner les éditions :
IEP
des TGP
IEP
IEP
des Etats
Proclamer les résultats
IEP
statistiques (A définir)
IEP
des Etats
enregistrer les demandes de réclamation
IEP
cumulatifs
IEP
de la Liste
jury spécial
IEP
Etablir l'état cumulatif de l'inspection
IEP
des admis
IEP
Réceptionner le CD
contrôle des CD
correction des
données
lxxiv
ANNEXES
Proclamer les résultats
fusion
enregistrer les demandes de
réclamation
jury spécial
3000 Direction régionale (DREN)
3000 Direction régionale (DREN)
Réceptionner la fiche informatique
Réceptionner les fiches d'affectation
DREN
(PV)
DREN
Réceptionner les états cumulatifs des
Réceptionner les PV
DREN
IEP
DREN
Réceptionner les états cumulatifs des IEP
DREN
vérifier les documents ci-dessus réceptionnés
DREN
réceptionnés
Etablir l'état cumulatif régional
DREN
DREN
Etablir l'état cumulatif régional
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
réceptionner les documents
réceptionner les documents transmis
CIO
vérifier les documents transmis
CIO
transmettre à la DOB les documents vérifiés
CIO
transmis
CIO
vérifier les documents transmis
CIO
transmettre à la DOB les
4000 DOB
documents ci-dessus vérifiés
CIO
4000 DOB
Réceptionner
DOB
Réceptionner
les PV
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
Vérifier
les PV
Vérifier
DOB
d'admission
les états
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
Contrôler
DOB
DREN /DDEN d'origine
corriger
DOB
IEP d'origine
Traiter
DOB
ordre de mérite
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 mérite
par DREN /DDEN d'origine par IEP
d'origine
A.2.2 Pour la seconde
1000 Collecte des données (Etablissement)
Opérateur
Etablissement fournisseur
Recueillir
Opérateur
1000 Collecte des données (Etablissement)
Etablissement fournisseur
Chef d'etab
Recueillir
1 les notes de classe spécifiques à
Chef d'etab
1 les notes de classe
l'orientation
spécifiques à l'orientation
2 les effectifs des candidats à
2 les effectifs des
l'orientation
candidats à l'orientation
3 les vœux
3 les vœux
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 vœux
Chef d'etab
Saisir des vœux
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 capacités d'accueil
1 les capacités d'accueil (tenir compte des séries A et C)
(tenir compte des séries 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é arrêtées :

Au plan administratif
Que la DOB et les directions partenaires (DIPES, DECO, DRH, SAPEP…)
s’accordent sur les points suivants:
1. avoir une base de données commune ;
2. tous les candidats à l’entrée en sixième soient saisis et suivis ;
3. tous les élèves de CM2 soient immatriculés ;
4. les IEP soient sensibilisées pour que les TGP soient saisis dans tous les centres de
corrections.

Au plan matériel, logiciel et humain
Que la DOB soit dotée :
1. d’un réseau local performant et sécurisé équipé d’un serveur de grande capacité
2. d’un réseau étendu performant et sécurisé reliant les autres localités (CIO, IEP,
DREN…)
3. Un système d’exploitation robuste et un gestionnaire de base de données adéquat,
4. d’une équipe pour la mise en œuvre et le suivi.

Au plan des critères de sélection et d’affectation
Pour les affectations :
1. Augmenter le nombre de vœux d’établissements distincts (de 3 à 10)
2. Prendre en compte le lieu de résidence de l’élève et faire le rapprochement avec
les structures d’accueil de la zone qui n’ont pas encore fait le plein de leur
capacité
3. Pour chaque IEP, répertorier les établissements secondaires d’accueil
Pour les critères de sélections en seconde A et C :
 Calculer la moyenne de profil en appliquant les coefficients suivants :
Profil scientifique
Profil littéraire
Matière
Coefficient
Matière
Coefficient
Composition Française
1
Composition Française
2
Anglais
1
Anglais
2
Mathématiques
2
Mathématiques
1
Sciences Physiques
2
Sciences Physiques
1
lxxvii
ANNEXES
1. Privilégier le vœu de filière exprimé par le candidat lorsque les deux (2) moyennes de profil
sont supérieures ou égales à 12 sur 20
2. Choisir automatiquement la série correspondant au profil lorsque les deux (2) moyennes de
profil sont inférieures à 12 (moyenne la plus élevée du profil)
3. Choisir automatiquement la série correspondant au profil lorsque l’une des moyennes est
supérieure ou égale à 12

code
Au plan des documents de travail
appelation
Fiche d'affectation (Fiche
informatique)
niveau
6ème
Listing d'émargement
6ème
Liste générale
6ème
Liste générale des admis
6ème
Tableau statistique
6ème
Liste des admis affectés
6ème
Tableau statistique des
affectés
6ème
description
...sert à collecter les informations
produites par la DECO
… utilisé pour le contrôle de présence des
candidats
utilisateur
ELEVE
IEP
remplir
collecter pour la saisie
valider les résultats
ELEVE
emmarger
DOB
traiter
par ordre de mérite, sert à déterminer la
barre d'admission
comment ça s'utilise
déterminer la barre
DOB
d'admission
par DREN/DDEN et IEP d'origine et par
ordre de mérite
par DREN/DDEN et IEP d'origine et par
sexe, sert de statistiques de départ
par établissement d'accueil et par ordre
de mérite
par établissement d'accueil
DOB
DOB
DOB
DOB
décider des capacités
d'accueil au privé
contrôler le respect des
quotas
vérifier les taux d'occupation
des quotas
A.2.4 Le MCD d’APPLIDOB
Le nom APPLIDOB est celui donné à l’application que nous avons développée pour
l’automatisation des travaux de la CNO et de la CNB. Dans ce qui suit, nous exposons les différents
MCD conçus, éléments de base de la base de données, et donc de l’application. Comme dit dans le
paragraphe 4.3.1, nous avons huit (08) sous systèmes dont l’objectif majeur est de permettre une
meilleure analyse par zoom sur les différents points focaux du système opérant. Il s’agit des soussystèmes Indentification, Evaluation Cadre, Evaluation Notes, Vœux, Authentification, Bourses,
Cartographie et Collaboration.
Le logiciel qui a été utilisé pour l’élaboration du MCD est WINDESIGN (Version 7).
lxxviii
ANNEXES
Le sous-système Identification présente principalement les informations relatives à
l’identification de l’élève, « matière première » du système d’information à concevoir. Il s’agit des
informations liées d’un côté à son identité propre : nom, prénoms, genre… ; et d’autre part à sa
filiation et sa localisation géographique : parents, quartier…
Figure A.1 : MCD du sous-système Indentification
lxxix
ANNEXES
Quant au sous-système Evaluation Cadre, il décrit clairement l’environnement de formation
et d’évaluation de l’élève, ainsi que les différentes barres d’admission utiles à l’automatisation des
opérations d’affectation, d’orientation, de redoublement, d’attribution et renouvellement de
bourse…
Figure A.2 : MCD du sous-système Evaluation Cadre
lxxx
ANNEXES
Comme son nom l’évoque, le sous-système Evaluation Notes a pour objectif de modéliser les
différentes notes obtenues par l’élève aux évaluations subies. Il y a aussi des informations nécessaires
à l’édition des données d’aide à la détermination des différentes barres d’admission, ainsi que les
coefficients des différentes moyennes. Certaines moyennes, trop utilisées dans les algorithmes, sont
mémorisées, bien qu’elles soient des valeurs calculées. Toutefois, des procédures stockées à
déclenchement automatique sont actionnées pour recalculer les moyennes qui utilisent une note
donnée, après toute modification de cette dernière.
Figure A.3 : MCD du sous-système Evaluation Notes
lxxxi
ANNEXES
Le sous-système Vœux présente les vœux d’établissements et de séries effectués par les
candidats à l’entrée en sixième et en seconde. Il permet aussi de sauvegarder les affectationsorientations réalisées pour optimiser les éventuelles consultations.
Figure A.4 : MCD du sous-système Vœux
lxxxii
ANNEXES
Ici, au niveau du sous-système Authentification, les différentes clés (mots de passe) utilisées
par les différentes structures intervenant sur le système opérant sont mémorisées (de manière
cryptée bien sûr). En effet, comme expliqué dans le paragraphe 4.1.3, un mécanisme de chiffrement
à clés asymétrique a été choisi pour chiffrer les données transmises par CD et par la même occasion
authentifier la source des données inscrites sur le CD.
Figure A.5 : MCD du sous-système Authentification
lxxxiii
ANNEXES
Le sous-système Bourse sauvegarde les données relatives à l’attribution et au
renouvellement de bourse.
Figure A.6 : MCD du sous-système Bourses
lxxxiv
ANNEXES
Le sous-système Cartographie présente l’interconnexion géographique des infrastructures
influençant l’automatisation des affectations-orientations. L’existence de ce sous-système se justifie
par le fait qu’un des algorithmes d’affection-orientation automatique demande que le candidat
affectable/orientable qui n’a été retenu dans aucun de ses vœux, soit automatiquement
affecté/orienté dans un établissement proche de son lieu d’habitation.
Figure A.7 : MCD du sous-système Cartographie
lxxxv
ANNEXES
Un point très important pour le système d’information conçu est la sécurité des données.
Cela implique que les différents utilisateurs de l’application soient correctement identifiés et
authentifiés à chaque connexion au système. Ce sous-système Collaboration permet de mémoriser
les données utiles à ce principe sécuritaire.
Figure A.8 : MCD du sous-système Collaboration
lxxxvi
ANNEXES
A.3 Les règles de traduction d’un MCD en MLDR
[14]
Pour traduire un MCD en MLDR, il suffit d’appliquer cinq règles.
Notations : on dit qu’une association binaire (entre deux entités ou réflexive) est de type :
>
1 : 1 (un à un) si aucune des deux cardinalités maximales n’est n ;
>
1 : n (un à plusieurs) si une des deux cardinalités maximales est n ;
>
n : m (plusieurs à plusieurs) si les deux cardinalités maximales sont n.
1. Toute entité devient une table dans laquelle les attributs deviennent les colonnes.
L’identifiant de l’entité constitue alors la clé primaire de la table.
2. Une association binaire de type 1 : n disparait, au profit d’une clé étrangère dans la
table côté 0-1 ou côté 1-1 qui référence la clé primaire de l’autre table. Cette clé
étrangère ne peut pas recevoir la valeur vide si la cardinalité est 1-1.
3. Une association binaire de type n : m devient une table supplémentaire (parfois
appelée table de jonction, table de jointure ou table d’association) dont la clé
primaire est composée de deux clés étrangères (qui référencent les deux clés
primaires des deux tables en association). Les attributs de l’association 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é étrangère se voit imposer une contrainte d’unicité en plus
d’une éventuelle contrainte de non vacuité (cette contrainte d’unicité impose à la
colonne de ne prendre que des valeurs distinctes).
5. Une association non binaire est traduite par une table supplémentaire dont la clé
primaire est composée d’autant de clés étrangères que d’entités en association. Les
attributs de l’association deviennent des colonnes de cette nouvelle table.
lxxxvii
ANNEXES
A.4 L’interface Homme-Machine (IHM) d’APPLIDOB
Figure A.17 : Arborescence des structures dans APPLIDOB
Figure A.18 : Table de détail dans APPLIDOB
lxxxviii
ANNEXES
Figure A.19 : Formulaire d’enregistrement d’élève de troisième – Onglet Identification
Figure A.20 : Formulaire d’enregistrement d’élève de troisième – Onglet Evaluation
lxxxix
ANNEXES
Figure A.21 : Formulaire d’enregistrement d’élève de troisième – Onglet Orientation
Figure A.22 : Formulaire d’enregistrement d’élève de CM2 – Onglet Identification
xc
ANNEXES
Figure A.23 : Formulaire d’enregistrement d’élève de CM2 – Onglet Evaluation
Figure A.24 : Formulaire d’enregistrement d’élève 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 numérique, son empreinte
numérique
(en
l'occurrence
une
séquence de 128 bits ou 32 caractères
en notation hexadécimale) avec une
probabilité très forte que deux fichiers
différents donnent deux empreintes
différentes.
En 1991, Ronald Rivest,
cryptographe
américain,
améliore
l'architecture de MD4 pour contrer des
attaques
potentielles
qui
seront
confirmées plus tard par les travaux de
Hans Dobbertin.
Figure A.25 : Vue générale de MD5
Cinq ans plus tard, en 1996, une faille qualifiée de grave (possibilité de créer des collisions
(situation dans laquelle deux données ont un résultat identique avec la même fonction de hachage) à
la demande) est découverte et indique que MD5 devrait être mis de côté au profit de fonctions plus
robustes comme SHA-1.
En 2004, une équipe chinoise découvre des collisions complètes. MD5
n'est
donc
plus
considéré comme sûr au sens cryptographique. On suggère maintenant d'utiliser plutôt des
algorithmes tels que SHA-256, RIPEMD-160 ou Whirlpool. Cependant, la fonction MD5 reste
encore largement utilisée comme outil de vérification lors des téléchargements et l'utilisateur peut
valider l'intégrité de la version téléchargée grâce à 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 système employé dans GNU/Linux avec la présence d'un sel (donnée particulière
injecté dans une fonction de hachage, dans le but de compliquer la détermination de la donnée
hachée) compliquant le décryptage. Ainsi, plutôt que de stocker les mots de passe dans un fichier,
xcii
ANNEXES
ce sont leurs empreintes MD5 qui sont enregistrées, de sorte que quelqu'un qui lirait ce fichier ne
puisse pas découvrir 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 privilégié dans le fichier de
configuration de l’équipement.
A.5.1.1 Algorithme
MD5 comprend 64 blocs de ce type
(voir figure ci-contre), groupés en quatre
tours de 16 opérations. F est une fonction
non-linéaire, qui varie selon le tour. Mi
symbolise un bloc de 32 bits provenant du
message à hacher et Ki est une constante de
32 bits, différentes pour chaque opération.
Notation
>
<<<s est une rotation de s bits vers la
gauche,
s
varie
pour
chaque
opération.
>
+ symbolise l'addition modulo 232.
>
symbolisent
respectivement
les
opérations
booléennes XOR, AND, OR et NOT.
Figure A.26 : Une opération de MD5
A.5.1.2 Préparation 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 manière à avoir un message
dont la longueur est un multiple de 512. Le remplissage se présente comme suit :
1.
on ajoute un '1' à la fin du message
2.
on ajoute une séquence de '0' (le nombre de zéros dépend de la longueur du remplissage
nécessaire)
3.
on écrit la taille du message, un entier codé sur 64 bits
Ce remplissage est toujours appliqué, même si la longueur du message peut être divisée par
512. Cette méthode de padding est semblable à celle utilisée 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
différente 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 codée 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-même divisé en 4 mots de
32 bits : A, B, C et D. Ils sont initialisés au début avec des constantes. L'algorithme utilise ensuite
les blocs provenant du message à hacher, ces blocs vont modifier l'état interne. Les opérations sur
un bloc se décomposent en quatre rondes (étapes), elles-mêmes subdivisées en 16 opérations
similaires basées sur une fonction non-linéaire F qui varie selon la ronde, une addition et une
rotation vers la gauche. Les quatre fonctions non-linéaires disponibles sont :
A.5.2 Secure Hash Algorithm (SHA)
[16]
SHA-1 (Secure Hash Algorithm) est une fonction de hachage cryptographique conçue par la
National Security Agency des États-Unis (NSA), et publiée par le gouvernement des États-Unis
comme un standard fédéral de traitement de l'information (Federal Information Processing Standard
du National Institute of Standards and Technology (NIST)). Elle produit un résultat (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 entrée. Son fonctionnement est
similaire à celui du MD4 ou MD5 de Ronald Rivest. Quatre fonctions booléennes sont définies,
elles prennent 3 mots de 32 bits en entrée et calculent un mot de 32 bits. Une fonction spécifique de
rotation est également disponible, elle permet de déplacer les bits vers la gauche (le mouvement est
circulaire et les bits reviennent à droite).
xciv
ANNEXES
Une de ces rotations n'était pas
présente dans le SHA-0, elle permet de
casser certaines caractéristiques linéaires
dans la structure. Cela permet d'éviter une
attaque sur les bits neutres décrite par Eli
Biham, technique reprise pour calculer la
collision complète sur SHA-0.
Deux rotations vers la gauche et une fonction
non-linéaire qui dépend du numéro d'itération,
deux autres variables interviennent à chaque
tour.
Figure A.27 : Une itération de SHA-1
Le SHA-1 commence par ajouter à la fin du message un bit à 1 suivi d'une série de bits à 0,
puis la longueur du message initial (en bits) codée sur 64 bits. La série de 0 a une longueur telle que
la séquence ainsi prolongée 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 série de transformations sur l'entrée. La
première étape consiste à calculer 80 valeurs sur 32 bits. Les 16 premières valeurs sont obtenues
directement à partir du bloc « message » en entrée. Les 64 autres sont calculées successivement. Le
SHA-1 les obtient grâce à une rotation (absente dans SHA-0) qui est appliquée sur le résultat d'un
XOR, il utilise pour cela 4 mots obtenus dans les itérations précédentes. On définit ensuite 5
variables qui sont initialisées avec des constantes (spécifiées par le standard), le SHA-1 utilise
encore 4 autres constantes dans ses calculs. Si un bloc de 512 bits a déjà été calculé auparavant, les
variables sont initialisées avec les valeurs obtenues à la fin du calcul sur le bloc précédent. Il
s'ensuit 80 tours qui alternent des rotations, des additions entre les variables et les constantes. Selon
le numéro du tour, le SHA-1 utilise une des quatre fonctions booléennes. L'une de ces fonctions est
appliquée sur 3 des 5 variables disponibles. Les variables sont mises à jour pour le tour suivant
grâce à des permutations et une rotation. En résumé, le SHA-1 change sa méthode de calcul tous les
20 tours et utilise les sorties des tours précédents. A la fin des 80 tours, on additionne le résultat
avec le vecteur initial. Lorsque tous les blocs ont été traités, les cinq variables concaténées (5 × 32 =
160 bits) représentent la signature.
xcv
ANNEXES
A.6 HyperFileSQL
[17]
HyperFileSQL est un SGBD relationnel créé par PC SOFT. Il est principalement utilisé dans
l’environnement WINDEV ; mais il peut être interrogé avec des langages comme PHP, Java, C#...,
des interfaces logicielles ayant été conçues à cet effet par ses auteurs. Les lignes qui suivent
présentent certaines de ses fonctionnalités. Néanmoins, une connaissance préalable de la
terminologie de base est indispensable pour la compréhension des idées dispensées (Voir le
glossaire pour « Analyse, Fichier, WLangage… ») .
A.6.1 Optimiser le temps de lancement des applications, en évitant une ouverture
systématique de tous les fichiers de la base.
L'ouverture d'un fichier de données au niveau du système d'exploitation est coûteuse en
temps. En effet, le système doit mettre en place bon nombre de mécanismes pour assurer par la suite
les entrées/sorties (allocation, partage réseau, cache ...).
Pour optimiser le lancement des applications, il est donc déconseillé d'effectuer une ouverture
systématique de tous les fichiers en appelant l'une des fonctions suivantes :
HOuvre("*") ou HCréationSiInexistant("*"). Pour cela le moteur HyperFileSQL est doté d'un
mécanisme d'ouverture automatique des fichiers. Il permet dès le premier accès à un fichier,
d'effectuer son ouverture si elle n'a pas déjà été faite. Le temps nécessaire aux ouvertures des
fichiers est ainsi réparti tout au long de l'application, plutôt qu'en une seule fois au lancement. La
fonction HPasse permet si besoin de spécifier le mot de passe des fichiers pour le mécanisme
d'ouverture automatique. Le gain peut être de plusieurs secondes dans une application ayant des
centaines de fichier.
Autre avantage de ce mécanisme, seuls les fichiers effectivement utilisés sont ouverts,
limitant ainsi les ressources nécessaires sur le serveur de données.
Ce mécanisme 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 création automatique :
1. menu "Projet ... Description du projet",
2. volet "Fichiers",
3. cocher "Créer automatiquement les fichiers de données".
xcvi
ANNEXES
Cette solution évite de conserver dans le programme l'appel suivant, pour les prochains
ajouts de fichiers de données dans la base : HCréationSiInexistant("*", hOuvertureDifférée)
A.6.2 Suivi des requêtes et traitements du moteur HyperFileSQL Client/Serveur
Le moteur HyperFileSQL Client/Serveur dispose de mécanismes de "log" et de suivi
d'activité. Ils permettent d'avoir très précisément sur une période donnée, toutes les actions
commandées par les différents utilisateurs connectés aux bases de données.
Il est donc vivement recommandé
d'activer ces mécanismes 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
contrôle HyperFileSQL (Voir figure
ci-contre)
Une fois l'activation faite, il suffit
toujours
dans
le
centre
de
contrôle
HyperFileSQL d'utiliser le volet "Logs et
Statistiques" pour accéder à de nombreuses
informations primordiales notamment en
phase de mise au point, et d'optimisation :
1. les requêtes les plus longues,
2. les appels les plus longs,
3. les requêtes les plus utilisées (pour
optimiser en priorité les traitements
les plus courants),
4. la liste des commandes appelées (par
exemple
vérifier
les
Figure A.28 : Centre de contrôle HyperFileSQL
paramètres
reçus par une requête d'un utilisateur
qui n'a pas le résultat attendu),
L'ensemble de ces possibilités permet de répondre à toutes les interrogations pouvant
survenir en exploitation :
1. le dimensionnement du réseau est-il suffisant ?
xcvii
ANNEXES
>
Les statistiques d'activités montrent le volume des demandes.
2. le dimensionnement du serveur est-il suffisant ?
>
Les statistiques d'activités montrent l'utilisation de la RAM et du CPU sur le serveur.
3. un résultat ne semble pas conforme ?
>
Les logs permettent de vérifier les demandes reçues.
4. un arrêt inattendu du moteur survient, ou une erreur du journal des événements de Windows
remonte ?
>
Les logs permettent de voir la demande, ou l'enchainement de traitements à l'origine.
Ces possibilités de suivi s'appliquent pour toutes les connexions gérées par le moteur
HyperFileSQL Client/Serveur, qu'elles proviennent des stations du réseau local, ou de postes
connectés par Internet.
A.6.3 Les ports nécessaires à l'utilisation de HyperFileSQL Cluster
L'accès aux données d'un Cluster (groupe de serveurs ayant les mêmes 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 = hAccèsHFClientServeur
Cluster_Support..Utilisateur = "admin"
Cluster_Support..MotDePasse = ""
Cluster_Support..Serveur = "Cluster_Support:49015"
Cluster_Support..BaseDeDonnées = "CRM"
HOuvreConnexion(Cluster_Support)
HChangeConnexion("*",Cluster_Support)
HCréationSiInexistant("*")
"Cluster_Support" correspond au nom DNS du Cluster, et 49015 correspond au port de
communication à utiliser. Ce port est paramétrable lors de l'installation du Cluster (4900 par
défaut). Il est donc nécessaire que le réseau autorise les communications sur ce port, en faisant si
xcviii
ANNEXES
besoin le nécessaire 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
nécessaire 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 nécessaires à l'utilisation de
HyperFileSQL Cluster
A.6.4 Synchronisation automatique de plusieurs serveurs de données HyperFileSQL
Client/Serveur
La version Cluster de HyperFileSQL est disponible, permettant d'obtenir une
synchronisation en temps réel d'une "ferme de serveurs". L'utilisation d'un Cluster offre de
nombreux intérêts :
1. Haute disponibilité,
2. Répartition de charge,
3. Resynchronisation automatique des nœuds défaillants,
4. Modification dynamique de la structure du cluster ...
Une présentation complète de HyperFileSQL Cluster est disponible sur le site d'aide en
ligne.
Il faut souligner que l'exploitation des données en Cluster ne nécessite aucune
transformation des données existantes (pas de modification automatique). Les applications doivent
simplement modifier leur paramètre de connexion, afin de spécifier non plus l'adresse d'un serveur
hébergeant le moteur HyperFileSQL Client/Serveur, mais le nom du Cluster.
Le pack d'installation spécifique de HyperFileSQL Cluster est disponible gratuitement pour
tout détenteur de licence commerciale en version 15. Il suffit d'en effectuer la demande au Support
xcix
ANNEXES
Technique Gratuit par le menu "? ... Requête au Support Technique" de WINDEV, WEBDEV et
WINDEV Mobile.
A.6.5 Placer le moteur HyperFileSQL Client/Serveur sur une machine virtualisée
La virtualisation est de plus en plus fréquemment retenue pour le déploiement d'applications.
Il n'y a aucune contre-indication à l'utilisation d'un système 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 particulière à faire. En effet pour
vos applications, et pour le moteur HyperFileSQL Client/Serveur, le fait que le système
d'exploitation soit sur une machine virtuelle n'a aucune incidence : votre programmation ou votre
méthode d'installation reste la même. Il faut en revanche bien vérifier le dimensionnement et la
configuration utilisée pour la virtualisation. Voici les points principaux à vérifier, tout manquement
de l'un d'entre eux peut provoquer une chute de performances importante.
1. Mémoire vive :
Il est important de supprimer tout risque de "swap" disque, préjudiciable aux performances.
Il est donc capital d'avoir pour la machine virtuelle suffisamment de mémoire. Il faut donc bien
compter la mémoire nécessaire :
>
au système d'exploitation hôte,
>
au système d'exploitation de la machine virtuelle ou des machines virtuelles,
>
celle utilisée par le moteur HyperFileSQL Client/Serveur,
>
celle utilisée par d'autres applications...
Pour démarrer, il faut compter 1,5 Go de plus que pour la même installation sur un serveur
non virtualisé. Par exemple si habituellement le déploiement se fait sur un serveur non virtualisé
doté de 4 Go (1 pour le système, 1,5 pour le moteur HyperFileSQL Client/Serveur, le reste pour
d'autres applications), il faut prévoir au minimum 5,5 Go.
2. Accès disque :
C'est le point le plus important, un moteur de base de données devant par définition faire de
très nombreux entrées/sorties disques. Il faut impérativement choisir une configuration dans
laquelle le système invité de la machine virtuelle dispose d'un disque physique entier qui lui est
dédié. Il ne faut pas que la machine virtuelle travaille sur un espace disque réservé de système hôte.
3. Carte réseau :
La bande passante de la carte réseau est partagée entre les machines virtuelles. Il faut donc
vérifier avec les logs du moteur HyperFileSQL Client/Serveur, que le débit sera suffisant pour les
besoins des applications hébergées. Sur ce point, il est le plus souvent recommandé d'avoir
c
ANNEXES
plusieurs cartes réseaux, afin que la machine virtuelle qui héberge le serveur dispose de sa propre
carte et donc de toute la bande passante disponible.
4. Processeur :
Les processeurs à privilégier sont ceux disposant de fonctionnalités matérielles dédiées à la
virtualisation : Intel-VT (Virtual Technology) ou AMD-V.
A.6.6 Protéger vos bases de données du piratage par injection de code SQL
L'injection de code SQL est une technique de piratage de base de données consistant à
injecter du code SQL dans les paramètres de requêtes, forçant ainsi l'exécution de code SQL non
désiré. Lorsque vous utilisez WINDEV, WEBDEV ou WINDEV Mobile, utilisez toujours des
objets requêtes. L'objet requête de WINDEV, WEBDEV ou WINDEV Mobile traite les paramètres
de requêtes comme des valeurs de recherche et jamais comme du code SQL. L'exécution vérifie 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 Accéder à une base HyperFileSQL Client/Serveur par Internet
Selon votre configuration par rapport à un accès local à la base de données vous allez avoir
principalement trois (03) " portes " à vérifier pour pouvoir accéder à votre base à travers Internet :
Rappel : le choix du type de base HyperFileSQL Client/Serveur s'impose pour les raisons suivantes:
> le réseau est lent (inférieur à 100 Mbits)
> le réseau peut avoir des coupures intempestives
> il n'y a pas de partages réseau sur le répertoire des données
ci
ANNEXES
Figure A.30 : HyperFileSQL Client/Serveur via Internet
1. Configuration de vos accès sortant du site sur lequel l'application va fonctionner
Cette étape est
inutile dans les réseaux qui n'ont pas une sécurité avancée. En effet
beaucoup de stratégies réseaux consistent à limiter les entrées tout en laissant un libre accès aux
sorties. Toutefois si vos accès sortant sont limités et/ou contrôlés, il s'agit généralement de
paramétrer le pare-feu du réseau (aussi appelé firewall) et éventuellement le pare-feu local du poste
si vous avez un pare-feu local actif.
2. Vérification des restrictions de votre fournisseur d'accès à Internet
Il arrive parfois que les fournisseurs d'accès à Internet n'autorisent l'accès qu'à certains
protocoles ou à certains ports. C'est généralement le cas pour les accès Internet depuis une carte
SIM (Smartphone...). Dans ce cas contactez votre fournisseur d'accès il faut généralement souscrire
à des forfaits spécifiques du type « Data » ou « Professionnel ».
cii
ANNEXES
Parfois également les accès sont autorisés mais dégradés, subissent des coupures afin
d'assurer une meilleur Qualité de Service (QoS) pour certains ports et protocoles. Les cas les plus
fréquents sont :
>
Accès Gprs/Edge/3G/3G+
>
Accès avec une connexion non dégroupée
3. Configuration des accès entrants du site sur lequel se trouve la base HyperFileSQL
Client/Serveur
1. Configuration des pare-feu (réseau et local)
Il faut paramétrer les pare-feu pour HyperFileSQL Client/Serveur.
2. Rediriger les accès entrants vers le serveur HyperFileSQL Client/Serveur
Pour que les connexions des postes clients soient bien redirigées 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'accès à Internet du serveur se fait par le réseau (le plus fréquent), dans ce cas
il faut configurer le " NAT " du routeur du box.
A.6.8 HyperFileSQL Client/Serveur ou Classic réseau ?
HyperFileSQL propose deux modes : classic réseau et Client/Serveur. Ces deux modes ont
des architectures de fonctionnement différentes adaptées à des situations différentes. Dans tous les
cas, 95% du code est identique en mode réseau et en mode Client/Serveur, seule la localisation des
fichiers changent, leur format reste le même. Il est donc possible de faire une application qui peut
basculer d'un mode à l'autre.
Tableau A.1 : Tableau récapitulatif du choix de base de données à effectuer en fonction de la
situation
Base de données
HyperFileSQL Classic réseau
HyperFileSQL Client/Serveur
OK (conseillé)
NON
Réseau local rapide
OK
OK
Intranet lent ou Internet
OK
OK
Réseau peu fiable
NON
OK
Pas de partage réseau
NON
OK
1 à 50 utilisateurs
NON
OK
OK si réseau très rapide(Gbps)
OK
NON
OK
Situation
Mono-utilisateur
Plus de 50 utilisateurs
Poste à poste sans serveur
ciii
ANNEXES
Base de données
HyperFileSQL Classic réseau
Données sur un NAS
OK
NON
Serveur Windows
OK
OK
Serveur Linux
OK
OK
Situation
~ (nécessite une installation, mais facile à
OK
mettre en œuvre)
OK en local (embarqué) uniquement
OK
Installation simplifiée/minimum
Accès 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 précis). Cela
permet
à
plusieurs
applications
(processus) de communiquer à travers
un réseau TCP/IP ou sur une même
machine.
Note : TCP/IP est le protocole d'Internet
Figure A.31 : Protocoles de communication en
et de la plus part des réseaux locaux).
Il
y
a
deux
modes
de
communication :
1. le protocole TCP qui est un mode connecté, comparable à une communication téléphonique.
Une connexion stable et bidirectionnelle est établie entre les deux parties. Une fois la
connexion établie plusieurs échanges pourront être effectués sans avoir à repréciser l'adresse
avec laquelle on communique (lorsque l'on téléphone on ne fait pas le numéro à chaque fois
que l'on parle mais uniquement au début). C'est par ce moyen que les applications
WINDEV, WINDEV Mobile et les sites WEBDEV se connectent et exécutent leurs
requêtes.
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 préciser
l'adresse à chaque envoi, et rien ne garantit que le destinataire reçoit les données (comme un
courrier sans accusés de réception). C'est par ce moyen qu'il est possible de rechercher les
serveurs installés, de les arrêter, les redémarrer 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 accès aux données sont
effectués 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 résultat. Les
échanges entre les clients et le serveur sont minimisés, mais la mémoire et les performances du
serveur sont fortement sollicitées.
Figure A.32 : Principe de fonctionnement de HyperFileSQL Client/Serveur
En mode HyperFileSQL Client/Serveur la configuration du serveur est primordiale. La
configuration du réseau et des postes clients est moins importante, mais il ne faut toutefois pas
totalement les négliger, car même si elles ne peuvent pas provoquer de corruption de données, 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 réseau
b. Le serveur traite localement les accès au fichier
c. Le serveur envoie le résultat au poste client, soit un (01) retour sur le réseau
>
Total : un (01) aller/retour sur le réseau (il s'agit d'une explication schématique pour
comprendre le principe, la réalité est un peu plus complexe)
Exemple 2 : Requête ou vue (HExécuteRequete) qui retourne une centaine d'enregistrements :
a. Un ordre est envoyé au serveur soit un (01) aller sur le réseau
cv
ANNEXES
b. Le serveur traite localement les accès au(x) fichier(s)
c. Le serveur envoie le résultat au poste client, soit un (01) retour sur le réseau
>
Total : un (01) aller/retour sur le réseau (il s'agit d'une explication schématique pour
comprendre le principe, la réalité est un peu plus complexe)
A.6.11 Principe de fonctionnement de HyperFileSQL Classic réseau
Lors de l'utilisation de HyperFileSQL classic réseau, c'est la machine de l'utilisateur qui fait
tout le travail. Au niveau du serveur seuls le disque et système d'exploitation sont sollicités. Les
échanges entre les clients et le serveur sont très nombreux, le réseau est donc fortement mis à
contribution. Lors de l'utilisation de HyperFileSQL classic réseau il est donc important de s'assurer
sur le réseau est rapide.
Figure A.33 : Principe de fonctionnement de HyperFileSQL classic réseau
Les opérations de lectures et d'écritures sont directement effectuées par chaque poste
utilisateur, il faut donc également s'assurer que les postes utilisateurs ont leurs systèmes
d'exploitation et leurs pilotes (drivers) réseau à jour. Un dysfonctionnement de l'un d'entre eux
pourrait provoquer une corruption de données.
Exemple 1 : Recherche d'un enregistrement (HLitRecherche):
a. Une à plusieurs lectures dans l'index pour rechercher l'index spécifié, approximativement
deux (02) ou trois (03) aller/retour sur le réseau
b. Lecture de l'enregistrement correspondant dans le fichier de données, soit 1 aller/retour sur
le réseau
c. Lecture du mémo s'il y en a un dans le fichier mémo, soit un (01) aller/retour sur le réseau
>
Total : quatre (04) ou cinq (05) aller/retour sur le réseau (il s'agit d'une explication
schématique pour comprendre le principe, la réalité est un peu plus complexe)
Exemple 2 : Requête ou vue (HExécuteRequete) qui retourne une centaine d'enregistrements :
cvi
ANNEXES
a. Une centaine de lectures dans l'index pour rechercher les valeurs spécifiées,
approximativement cent (100) aller/retour sur le réseau
b. Lecture des enregistrements correspondants dans le fichier de données, soit 100 aller/retour
sur le réseau
c. Lecture du mémo s'il y en a un dans le fichier mémo, soit cent (100) aller/retour sur le réseau
>
Total : deux cents (200) ou trois cents (300) aller/retour sur le réseau (il s'agit d'une
explication schématique pour comprendre le principe, la réalité est un peu plus complexe).
cvii
GLOSSAIRE
GLOSSAIRE
Affectation
Attribution d’établissement à un candidat admis (en l’occurrence à l’entrée en
sixième).
Affectation
Affectation prioritaire d’un candidat admis dans un établissement (et/ou une
précise
série) à l’appréciation de la CNO.
Analyse
Schéma de la base de données (Métadonnées définissant la structure de la BD
et les contraintes sur celle-ci), dans le SGBDR HyperFileSQL.
Application
(Voir Logiciel)
Base de données
Collection de données structurées qui qualifient les activités d’une
organisation.
Cluster
Technique de redondance utilisée dans HyperFileSQL Client/Serveur.
Plusieurs serveurs de BD, contenant les mêmes informations, sont fédérés sous
un seul nom DNS. Ainsi, la requête du client est automatiquement et de façon
transparente, redirigée vers le serveur le plus disponible lorsqu’il interroge ce
nom DNS.
CNB
Commission nationale ténue annuellement, au cours de laquelle sont définis les
bénéficiaires de la bourse de l’enseignement secondaire général.
CNO
Commission nationale ténue annuellement, au cours de laquelle sont réalisées
les affectations en sixième et les orientations en seconde dans l’enseignement
secondaire général. Les redoublants de la classe de troisième sont aussi définis
au cours de cette commission.
Fichier
Appellation donnée à une « table » dans le SGBDR HyperFileSQL.
Hébergeur web
Entreprise qui se charge de mettre des serveurs web à la disposition des
personnes ou des entreprises pour leur permettre de déployer leur site web sur
Internet.
HTML
Format de document du web (Internet), défini par la RFC 1866. Langage
permettant de créer ce type de document.
HTTP
Protocole de transmission dédié aux applications du web.
HyperFileSQL
SGBD relationnel conçu par PC SOFT.
Internet
Interconnexion mondiale de réseaux informatiques. Internet est souvent
cviii
GLOSSAIRE
désigné par Web ou World Wide Web (www).
Logiciel
Suites d’instructions réfléchies, compréhensibles par un système informatique
et offrant des moyens de résolution de problèmes plus ou moins complexes. Un
logiciel est généralement fourni sous forme d’entité exécutable.
MO
Moyenne calculée à l’aide des moyennes annuelles et notes obtenues à
l’examen du BEPC en Anglais, Composition Française, Mathématiques et
Sciences Physiques d’un candidat. Elle est utilisée pour effectuer les
orientations et les attributions de bourses en seconde.
Modélisation
Représentation virtuelle et simplifiée d'une réalité de façon à en faire ressortir
les points auxquels on s'intéresse.
Orientation
Attribution d’établissement et de série à un candidat admis (en l’occurrence à
l’entrée en seconde) conformément à son profile intellectuel.
Protocole
Ensemble de règles de communication entre entités fonctionnellement
équivalentes.
Réseau
Ensemble d’ordinateurs (y compris les périphériques qui y sont connectés)
interconnectés pour l’échange de données.
Script
Suite d’instructions simples, peu structurées, permettant d’automatiser
certaines tâches.
Secteur
Activités industrielles
secondaire
Secteur tertiaire
Secteur de l’économie comprenant le commerce, les assurances, les banques,
l’enseignement, etc.
Serveur
Ordinateur détenant des ressources particulières qu’il met à la disposition
d’autres ordinateurs via un réseau. Il peut s’agir d’une entité fonction comme
une application.
Session
Année académique.
Système
Système constitué des ressources humaines, des ressources informatiques
d’Information
(équipement, logiciel, données) et des procédures permettant d’acquérir, de
(SI)
stocker, de traiter et de diffuser les éléments d’information pertinents au
fonctionnement d’une entreprise ou d’une organisation.
Système de
Ensemble des acteurs d’un système opérant et des processus de gestion de ce
pilotage (SP)
système.
cix
GLOSSAIRE
Système opérant
Système physique de production, qui fait l’objet d’une étude informatique en
(SO)
vue d’informatiser son fonctionnement.
TGP
Total de points pondérés obtenus par un candidat à l’examen du CEPE et en
classes. Le TGP est utilisé pour déterminer les admis à l’entrée en sixième et
les élèves aptes pour l’attribution de bourses.
UML
Langage de modélisation de troisième (03ième) génération, normalisé par
l’OMG début 1997, permettant de décrire une application en fonction des
méthodes objet nécessaire à sa conception.
WINDEV
Atelier de Génie Logiciel conçu par PC SOFT. Il s’agit d’un logiciel qui
permet de créer d’autres logiciels.
WLangage
Langage de cinquième génération (L5G) utilisé par WINDEV.
cx

renovation du systeme informatique de gestion des travaux de la

Transcription

Documents pareils

OFFRE D`EMPLOI – ANALYSTE / PROGRAMMEUR - G-SYS

paiement_ bourse 2016

Guide Aide à la saisie d`un DSE (bourses MESR

Fiche tarifs lycée 2012-2013 - Lycée Saint Jacques de Compostelle

frais de scolarisation au lycee saint jacques de compostelle a

Communiqué de presse

Programme Erasmus Mundus Green IT

Formulaire de renonciation au droit à l`image

23 novembre 2015 Séance plénière DOB

Programme Canadien de Bourses de la Francophonie -2015