memoire de fin de cycle ingenieur - ano steve - 2008

Réalisation et sécurisation d’un

cadre de gestion des projets : cas du SIGPOD 1

Dédicace

Dédicace

DEDICACE

A la mémoire de

mon oncle Thomas

Kouamé ANO, à qui

je n’ai pas pu dire

Merci.

Que son âme repose

en paix.

Steve Koffi Ano



Remerciements

Remerciements

Le présent mémoire émane de plusieurs journées et nuits de dur labeur qui ont

nécessité l’implication de plusieurs personnes. C’est pourquoi nous voulons d’une manière

distincte leur exprimer toute notre reconnaissance.

Ainsi, nous adressons nos sincères remerciements au Dr Ibrahim LOKPO, Directeur

de la Direction Suivi-Evaluation (DSE), pour nous avoir permis d’effectuer notre stage au

sein de sa direction.

Nous remercions M. Marcelin Konan BROU notre encadreur pédagogique pour la

justesse de ses critiques et l’expertise dont il nous a fait bénéficier lors de certaines difficultés

rencontrées.

Aussi, exprimons-nous notre reconnaissance à l’ensemble du personnel de la DSE

pour leur accueil, singulièrement M. Oumar TATO, responsable informatique, qui a accepté

d’être notre tuteur de stage et dont les conseils nous ont orientés vers les bons choix

techniques.

Nous tenons à remercier nos partenaires de projet M. Aimé ZACLO et M. Guillaume

SIGUI pour toute la force et la joie qui nous ont apporté tout au long de ce stage.

Enfin, nous remercions notre famille et nos amis (de longues dates comme les plus

récents) dont nous ne citerions pas les noms de peur d’en oublier, qui ont su nous apporter

leur soutien durant ces 23 premières années de notre vie. Nous espérons bénéficier de leur

présence encore de longues années.

Sincèrement

Remerciements

Steve Koffi Ano



Sommaire

Table des matières

Dédicace ..................................................................................................................................... 2

Remerciements ........................................................................................................................... 3

Table des matières ...................................................................................................................... 4

Avant-propos .............................................................................................................................. 8

Introduction ................................................................................................................................ 9

I – PRÉSENTATION DE LA STRUCTURE D’ACCUEIL ................................................... 11

I.1 – Présentation du Ministère d’État, Ministère du Plan et Développement .............. 11

I.1.1 – Le cabinet .............................................................................................................. 11

I.1.2 – Les services rattachés ............................................................................................ 11

I.1.3 – Les directions ........................................................................................................ 12

I.2 – Présentation de la Direction Générale de la Population et du Renforcement de

Capacités (DGPRC) ........................................................... 13

I.2.1 – Les Missions ......................................................................................................... 13

I.2.2 – La composition ...................................................................................................... 13

I.3 – Présentation de la Direction du Suivi-Evaluation (DSE) ..................................... 14

I.3.1 – Les Missions ......................................................................................................... 14

I.3.2 – La composition ...................................................................................................... 14

I.4 – Présentation du Service Informatique .................................................................... 15

I.4.1 – Les Missions ......................................................................................................... 15

I.4.2 – L’inventaire des ressources informatiques ............................................................ 15

I.4.3 – Le réseau informatique ......................................................................................... 16

II – ETUDE PREALABE ........................................................................................................ 19

II.1 – Présentation du projet ................................................................................................. 19

II.1.1 – Contexte et justification ...................................................................................... 19

II.1.2 – Objectifs ............................................................................................................... 19

II.1.3 – Résultats attendus ................................................................................................ 19

II.2 – Méthodes d’analyse et de conception ......................................................................... 20

II.2.1 – La Méthode d’Étude et de Réalisation Informatique par Sous-ensemble

(MERISE) ............................................................ 21

II.2.1.2 – Les concepts ................................................................................................. 21

II.2.1.2 – Les niveaux ................................................................................................... 21

Table des matières



Sommaire

II.2.1.3 – La démarche ................................................................................................. 23

II.2.2 – Le processus unifié .............................................................................................. 25

II.2.2.1 – Les diagrammes ............................................................................................ 25

II.2.2.2 – Les vues ........................................................................................................ 26

II.2.2.3 – La démarche ................................................................................................. 27

II.2.3 – Choix d’une méthode ........................................................................................... 31

II.3 – Etude de l’existant ...................................................................................................... 33

II.3.1 – Description de l’existant ...................................................................................... 33

II.3.1.1 – Description du processus de gestion des projets........................................... 34

II.3.1.2 – Le diagramme de cas d’utilisation ................................................................ 34

II.3.1.2.1 – les concepts ............................................................................................ 34

II.3.1.2.2 – la représentation du diagramme de cas d’utilisation.............................. 36

II.3.1.3 – Les descriptions textuelles ............................................................................ 37

II.3.1.4 – Les diagrammes d’activités .......................................................................... 38

II.3.1.4.1 – Les concepts .......................................................................................... 38

II.3.1.4.2 – Les représentations des diagrammes d’activités ................................... 40

II.3.1.5 – Les diagrammes de classes ........................................................................... 42

II.3.1.5.1 – Les concepts .......................................................................................... 42

II.3.1.5.2 – Les représentations des diagrammes de classes ................................... 43

II.3.2 – Critiques de l’existant .......................................................................................... 46

II.4 – Proposition de solution ............................................................................................... 47

III – CONCEPTION DU CADRE ........................................................................................... 49

III.1 – Modélisation métier ................................................................................................... 49

III.1.1 – Présentation du projet à réaliser ......................................................................... 49

III.1.2 – Recueil des besoins fonctionnels ........................................................................ 49

III.1.3 – Identification des acteurs .................................................................................... 49

III.1.4 – Identification des messages ................................................................................ 50

III.1.5 – Modélisation du contexte ................................................................................... 50

III.2 – Recueil et expression des besoins ............................................................................. 52

III.2.1 – Identification des cas d’utilisation ...................................................................... 52

III.2.2 – Diagramme de cas d’utilisation .......................................................................... 52

III.2.3 – Descriptions textuelles ....................................................................................... 54

III.3 – Analyse ...................................................................................................................... 57

III.3.1 – Développement du modèle statique ................................................................... 57

III.3.2 – Développement du modèle dynamique .............................................................. 60

II.3.2.1 – Diagramme d’activités .................................................................................. 60



Sommaire

II.3.2.2 – Diagramme d’états-transition ....................................................................... 65

IV – SECURISATION DU CADRE ....................................................................................... 67

IV.1 – Nécessité d’une sécurisation du système d’information ........................................... 67

IV.2 – Présentation de la gestion des risques ....................................................................... 68

IV.2.1 – Les concepts de la gestion de risques ................................................................. 68

IV.2.2 – Le processus de gestion des risques ................................................................... 70

IV.3 – Les méthodes d’analyses de risques .......................................................................... 74

IV.3.1 – EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) . 74

IV.3.2 – OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) .................... 76

IV.3.3 – MEHARI (Méthode harmonisée d’Analyse des Risques) ............................... 77

IV.3.3 – Choix d’une méthode d’analyse de risques ........................................................ 79

IV.4 – Mesures de sécurité ................................................................................................... 81

IV.4.1 – Sécurisation du réseau ........................................................................................ 82

IV.4.1.1 – Présentation ................................................................................................. 82

IV.4.1.2 – Menaces et contre-mesures ......................................................................... 82

IV.4.2 – Sécurisation du serveur web .............................................................................. 86

IV.4.2.1 – Présentation ................................................................................................. 86


IV.4.3 – Sécurisation du serveur d’applications .............................................................. 89

IV.4.3.1 – Présentation ................................................................................................. 89


IV.4.4 – Sécurisation du serveur de base de données ...................................................... 92

IV.4.4.1 – Présentation ................................................................................................. 92

IV.4.4.2 – Mesures et contre-mesures .......................................................................... 92

IV.4.5 – Sécurisation de l’application web ...................................................................... 95

IV.4.5.1 – Présentation ................................................................................................. 95

IV.4.5.1 – Conseils de conception ................................................................................ 95

V– REALISATION DU CADRE ............................................................................................ 99

V.1 – Choix techniques ........................................................................................................ 99

V.1.1 – Architectures d’application ................................................................................. 99

V.1.1.1 – l’architecture un tiers .................................................................................. 100

V.1.1.2 – l’architecture deux tiers .............................................................................. 101

V.1.1.3 – l’architecture trois tiers ............................................................................... 103

V.1.1.4 – choix d’une architecture ............................................................................. 103

V.1.2 – Serveurs physiques ............................................................................................ 105

V.1.3 – Systèmes d’exploitation .................................................................................... 106



Sommaire

V.1.3.1 – Windows ..................................................................................................... 107

V.1.3.2 – GNU/Linux ................................................................................................. 108

V.1.3.3 – Choix d’un système d’exploitation ............................................................. 110

V.1.4 – Serveurs web ..................................................................................................... 112

V.1.4.1 – Apache ........................................................................................................ 112

V.1.4.2 – Microsoft IIS .............................................................................................. 113

V.1.4.3 – Sun Java System Web Server ..................................................................... 114

V.1.4.4 – Zeus Web Server ........................................................................................ 114

V.1.4.5 – Choix d’un serveur web ............................................................................. 115

V.1.5 – Système de gestion de bases de données (SGBD)............................................. 117

V.1.5.1 – MySQL ....................................................................................................... 118

V.1.5.2 – PostgreSQL ................................................................................................ 119

V.1.5.3 – Microsoft SQL-Server ................................................................................ 119

V.1.5.4 – Oracle ......................................................................................................... 120

V.1.5.5 – Choix d’un SGBD ...................................................................................... 120

V.1.6 – Langage de scripts coté serveur ......................................................................... 123

V.1.6.1 – PHP ............................................................................................................. 123

V.1.6.2 – ASP ............................................................................................................. 124

V.1.6.3 – JSP .............................................................................................................. 125

V.1.6.4 – Perl .............................................................................................................. 126

V.1.6.6 – Choix d’un langage de script coté serveur ................................................. 127

V.2 – Interfaces .................................................................................................................. 127

V.2.1 – Interface classique d’administration .................................................................. 128

V.2.2 – Assistant ............................................................................................................ 131

Conclusion .............................................................................................................................. 134

Liste des figures et des tableaux ............................................................................................. 135

Références bibliographiques .................................................................................................. 138

Annexes .................................................................................................................................. 140



Avant - Propos

Avant-propos

Né le quatre (04) septembre 1996 par le décret 96 – 678, de la fusion et de la

restructuration de quatre (04) grandes écoles dont :

l’Institut National Supérieur de l’Enseignement Technique (INSET),

l’École Nationale Supérieure de Travaux Publics (ENSTP),

l’École Nationale Supérieure d’Agronomie (ENSA),

l’Institut Agricole de Bouaké (IAB),

L’Institut National Polytechnique Houphouët-Boigny (INP-HB) se présente comme un

établissement de référence en matière de formation des cadres et techniciens supérieurs en

Côte d’Ivoire et en Afrique subsaharienne.

Il a en son sein six (06) grandes écoles qui sont :

l’École de Formation Continue et de Perfectionnement des Cadres (EFCPC),

l’École Supérieure d’Agronomie (ESA),

l’École Supérieure des Mines et Géologie (ESMG),

l’École Supérieure de Travaux Publics (ESTP),

l’École Supérieure d’Industrie (ESI)

l’École Supérieure de Commerce et d’administration d’Entreprise (ESCAE).

L’École Supérieure d’Industrie (ESI), notre école a pour objectif la formation

d’ingénieurs de conception et de techniciens supérieurs opérationnels pour le marché

professionnel. Pour y parvenir, l’école initie un stage de fin de cycle permettant à l’étudiant de

se familiariser aux réalités de l’entreprise et de mettre au profit de celle-ci les connaissances

acquises tout au long de sa formation.

C’est ainsi que nous avons été accueillis à la Direction de Suivi-Evaluation (DSE)

pour une période de trois (03) mois.

Avant-propos



9 Introduction

Introduction

Depuis son accession à l’indépendance, le 07 août 1960, la Côte d’Ivoire a opté pour

un régime économique libéral qui lui a permis de connaître une croissance économique sans

précédent. Ce choix a conduit à des progrès dans de nombreux domaines sociaux notamment

la santé, l’éducation, l’emploi et le logement pour le bien-être des populations.

À partir de l’année 1980, avec la détérioration des termes de l’échange, le pays a été

confronté à une crise économique aiguë qui a favorisé la mise en œuvre des programmes

d’ajustement structurels (PAS). L’exécution de ces programmes a eu pour conséquences la

réduction des dépenses dans la plupart des secteurs sociaux. Ce qui amena le gouvernement a

accordé une attention particulière à l’utilisation rationnelle et efficiente des dépenses

publiques et de l’aide extérieure. Cette préoccupation partagée également par les partenaires

au développement s’est traduite par un grand intérêt accordé au suivi et l’évaluation. Cette

convergence de visions s’est matérialisée au niveau international par plusieurs engagements

internationaux. Au niveau national, l’engagement s’est concrétisé par la création dans les

ministères techniques, de structures chargées du suivi et de l’évaluation des actions de

développement.

Toutefois, malgré l’importance accordée au suivi et à l’évaluation, force est de

constater que, la mise en œuvre efficace de systèmes de suivi et évaluation est confrontée à la

faiblesse des capacités nationales en matière de suivi et évaluation et en l’absence de données

de base fiables pour l’élaboration des indicateurs de conception et de suivi et évaluation des

programmes. C’est ainsi que la Direction Suivi-Evaluation au vu de l’acuité du problème de

reconnaissance et de la gestion transparente des ressources nous a accueillis en son sein et

nous a confiés le thème suivant :

« RÉALISATION ET SÉCURISATION D’UN CADRE DE GESTION DE PROJETS :

CAS DU SIGPOD »

Pour mener à bien ce travail, objet de ce présent mémoire, notre approche s’articulera

autour de 5 phases principales :

une première phase de présentation de la structure d’accueil qui consistera à décrire

l’environnement dans lequel nous avons travaillé,

une deuxième phase d’étude préalable qui nous amènera à analyser l’existant et à

proposer une solution aux problèmes rencontrés,

une troisième phase de conception qui permettra de mettre en place la solution choisie,

une quatrième phase de sécurisation qui indiquera les moyens à utiliser pour la

sécurité des informations,

et enfin la dernière phase qui est la réalisation de la solution.

Introduction

1

10 Présentation de la structure d’accueil il


cadre de gestion des projets : cas du SIGPOD

PRESENTATION

DE LA STRUCTURE D’ACCUEIL

Dans le souci d’une meilleure présentation de notre

travail, il convient de décrire la structure dans laquelle nous

avons effectué notre stage.

Ainsi, dans cette partie nous vous présenterons le

Ministère d’État, Ministère du plan et du développement et

aussi sa composition. Cette dernière nous amènera à la

description de la Direction Générale de la Population et du

Renforcement des Capacités (DGPRC) qui est la direction

ayant en son sein la Direction du Suivi-Evaluation (DSE).

Non seulement, nous ferons une description de cette

direction mais aussi du service informatique qu’elle

comporte.

1

11 Présentation de la structure d’accueil



I – PRÉSENTATION DE LA STRUCTURE D’ACCUEIL

I.1 – Présentation du Ministère d’État, Ministère du Plan

et Développement

Le Ministère d’État, Ministère du Plan et du Développement est le ministère chargé de

la gestion de tous les projets de développement du pays. Occupant les dixième (10e), onzième

(11e), sixième (6e) paliers de l’immeuble alpha 2000 sis dans la commune du Plateau à

Abidjan, ce ministère qui s’étend aussi sur les immeubles près de l’immeuble alpha 2000, est

l’un des plus grands ministères compte tenu du nombre de fonctionnaires qu’il regorge et

surtout pour le rôle transversal qu’il assure.

Depuis sa constitution du 23 janvier 2003, le Ministère d’État, Ministère du Plan et du

Développement se compose d’un cabinet, de plusieurs directions générales, de services

rattachés, de directions centrales et aussi de plusieurs services extérieurs (annexe 1).

I.1.1 – Le cabinet

Défini comme le personnel d’un ministre, celui du Ministère d’État, Ministère du Plan

et du Développement comprend :

un directeur de cabinet

un directeur de cabinet adjoint

un chef de cabinet

six conseillers

un chargé de mission

un attaché de cabinet

5 chargés d’études

un chef de secrétariat particulier

I.1.2 – Les services rattachés

En plus de ses composantes, le cabinet du ministre est rattaché à plusieurs services qui

sont :

l’inspection générale (IG) dont les missions sont :

le contrôle du bon fonctionnement des structures du Ministère d’État,

Ministère du Plan et du Développement,

le contrôle et l’évaluation des réalisations physiques et financières,

l’application des procédures admises dans le cadre de l’exécution des actions

relevant des attributions du ministère,

1




la réalisation des rapports d’audits et l’amélioration des capacités et des

systèmes de gestion.

Le Bureau National de la Prospection (BNP), structure autonome qui a en

charge la conduite de réflexions prospectives et stratégiques, nécessaires à la

détermination de la vision stratégique du pays et à l’éclairage de l’action publique

dans le temps et dans l’espace.

Le Service de la Communication, de la Documentation et des Archives

(SCDA), qui est chargé d’assurer la conception, l’organisation et la mise en œuvre

de la politique de communication et de la documentation du Ministère d’État,

Ministère du Plan et du Développement.

La Direction des Affaires Administratives et Financières (DAAF) qui est

chargée de :

la gestion du personnel,

la gestion des crédits,

la gestion du matériel et des locaux.

I.1.3 – Les directions

Parmi les directions composant ce ministère, nous pouvons citer :

La Direction Générale du Plan (DGP) dont les rôles sont :

la conception et la mise en œuvre de la politique, des stratégies et des objectifs

en matière de planification ;

l’élaboration des politiques sectorielles contribuant au soutien des secteurs

créateurs de richesses et d’emplois ;

l’élaboration des documents de synthèse des actions de l’État en matière de

planification, sur la base des options retenues en relation étroite avec les

services des ministères concernés ;

l’élaboration du programme triennal d’investissements publics et la

participation à la recherche, en liaison avec les services du ministère chargé de

l’économie et des finances, des ressources et des moyens de son financement ;

le suivi et l’analyse de l’exécution des investissements publics au regard de la

programmation triennale d’investissements publics ;

Les coordinations des projets et programmes de développement dans lesquelles

le Ministère d’État, Ministère du Plan et du Développement intervient à titre

exclusif ou avec d’autres ministères.

Cette direction a en son sein 4 directions qui sont :

la direction de la planification

la direction du développement

la direction de la programmation des investissements publics

la direction de la coordination, du contrôle et de l’évaluation

1




La Direction Générale du Développement de l’Économie Régionale (DGDER)

qui a les finalités suivantes :

la structuration et la régulation de l’espace économique national et régional ;

l’appui à la mise en valeur des potentialités économiques, sociales, culturelles

et institutionnelles pour un développement régional équilibré ;

la conception, la préparation des orientations nationales ;

la coordination des actions en matière de développement et d’aménagement du

territoire ;

l’élaboration de la politique d’aménagement du territoire, en relation avec les

services des ministères techniques et des collectivités territoriales, dans le

respect de leur libre administration et des principes de la décentralisation, ainsi

que d’autres acteurs, notamment le secteur privé, les organisations non

gouvernementales et les partenaires au développement.

La Direction Générale du Développement de l’Économie Régionale est composée

de deux directions qui sont :

la Direction du Développement de l’Economie Régionale ;

la Direction de l’Analyse et de l’Aménagement du Territoire.

La Direction Générale de la Population et du Renforcement des Capacités

(DGPRC).

I.2 – Présentation de la Direction Générale de la

Population et du Renforcement de Capacités

(DGPRC)

I.2.1 – Les Missions

Les nombreuses missions de la Direction Générale de la Population et du

Renforcement des Capacités (DGPRC) se présentent comme suit :

la formulation et la mise en œuvre des politiques des populations ;

le suivi et l’évaluation de l’impact des politiques sur la dynamique de la population ;

la gestion de la base de données sur la population ;

la formulation des politiques et stratégies de renforcement des capacités nationales

particulièrement en ce qui concerne la qualité des ressources humaines ;

la coordination et le suivi des programmes et projets en matière de population.

I.2.2 – La composition

Cette direction générale qui est plus que dynamique, comprend trois (03) directions

qui se nomment :

la Direction des Politiques de Population (DPP) ;

la Direction du Renforcement des Capacités Nationales (DRCN) ;

1




la Direction du Suivi-Evaluation (DSE).

I.3 – Présentation de la Direction du Suivi-Evaluation

(DSE)


Créée par le décret nº 2006-03 du 23 janvier 2006, la Direction du Suivi-Evaluation,

qui a été notre direction d’accueil, a pour prérogatives de :

coordonner et suivre les programmes et projets en matière de population ;

suivre et évaluer l’impact des politiques sur la dynamique de la population ;

élaborer le rapport annuel sur l’état de la population ivoirienne.

I.3.2 – La composition

Cette direction, garante du bon suivi des projets est constitué de deux (02) sous-

directions, à savoir :

la Sous-direction du Suivi et de l’Évaluation des Politiques de Population

(SDSEPP)

la Sous-direction des Programmes et Projets de Population (SDPPP) qui pour

mener à bien ses missions est subdivisée en deux (02) services dynamiques :

le Service de Coordination des Projets de Population, dont les objectifs

sont de :

prendre contact avec les structures qui abritent les projets passés, en

cours ou prévus à court, moyen et long terme concernant les

populations en vue de recueillir des informations sur ces projets ;

définir et/ou recueillir les indicateurs de suivi, de l’évaluation des

projets/programmes de concert avec la sous-direction du suivi, de

l’évaluation et de la politique de la population, avec les structures

externes responsables des programmes et projets de population ;

produire la documentation sur l’ensemble des applications

informatiques pour la maintenance ou d’autres fins utiles ;

élaborer les programmes, sous-programmes et projets de population ;

animer le suivi de la coordination des sous-programmes de population ;

coordonner les rapports d’évaluation sur la population ;

coordonner les activités des projets ;

superviser les activités ;

suivre l’élaboration des rapports annuels des activités des projets.

le Service Informatique.

1




I.4 – Présentation du Service Informatique


Ce service qui nous a précisément reçus se résume en une équipe ayant un champ

d’action transversal et dont le travail s’articule autour des éléments suivants :

la résolution des problèmes relatifs au réseau ;

la maintenance des applications internet ;

la mise en place du site web ;

la maintenance du matériel informatique ;

le développement d’application de développement ;

la maintenance des applications de développement.

Cette équipe assure également les services suivants :

le service de recherche et de coordination des projets de population ;

le service du suivi des projets de la population ;

le service d’information, d’éducation et de conseil.

I.4.2 – L’inventaire des ressources informatiques

À notre arrivée dans la Direction du Suivi-Evaluation (DSE), nous avons remarqué

que des investissements avaient été réalisés pour acquérir des ressources informatiques qui

sont :

les ressources matérielles

Type de matériel Caractéristiques Marque Nombre

Ordinateurs de bureau

Un processeur Intel Pentium 4 de

fréquence 3 GHz, un disque dur de 80

Go, une mémoire vive de 512 Mo,

graveur DVD-CD, des outils

multimédias

HP dc5100 MT

9

Ordinateur portable

Un processeur Intel Pentium M Centrino

de fréquence 1,8 GHz, un disque dur de

60 Go, une mémoire vive 512 Mo,

graveur DVD-CD, outils multimédias et

technologie Wifi

TOSHIBA M70

2

Imprimante

HP Laserjet 1020

3

Imprimante

HP Office jet

6615(tout en un)

1

Onduleur-stabilisateur 550 VA / 300 W,

Input : 220-240 V ~50-60 HZ, 5A

LEADER 550 9

Tableau 1. Liste du matériel informatique

1




les ressources logicielles :

Les ordinateurs du parc informatique sont dotés des logiciels suivants :

le système d’exploitation Microsoft Windows Xp

la suite bureautique Office 2003 Professionnel

l’antivirus Norton Antivirus 2005

I.4.3 – Le réseau informatique

D’abord, il convient de mentionner que le réseau informatique (figure 1) du Ministère

d’Etat, Ministère du Plan et du Développement a été mis en place par la Société Nationale de

Développement Informatique (SNDI), qui en assure l’administration et la maintenance. Les

directions situées dans l’immeuble Alpha 2000, fonctionnent dans un intranet géré par un

routeur. Et c’est ce dernier qui sert de passerelle, entre le réseau informatique des directions

de l’immeuble Alpha 2000, et le réseau de la SNDI, ouvert sur Internet.

Une description synthétisée du réseau peut se présenter comme suit :

un serveur DHCP, qui fournit des adresses de classes C (192.168.37.XXX) ;

une passerelle avec comme adresse 192.168.37.200 ;

un serveur Proxy, avec l’adresse 10.6.8.190

un serveur DNS, avec la même adresse ;

un pare-feu.

La communication entre le routeur (qui est le nœud central des machines des

directions de l’immeuble) et le réseau de la SNDI est régie par des antennes radio. Les

signaux parviennent au routeur via le modem, et vice versa. Mais, il est à souligner que

l’intranet des directions de l’immeuble Alpha 2000, n’est pas directement en liaison avec le

réseau de la SNDI. Sa liaison est avec l’intranet de l’immeuble CIAM, où se situe le cabinet

ministériel, puis à partir de l’immeuble CIAM, la connexion est établie avec la SNDI.

1




Figure 1 : réseau informatique du ministère

1

18 Etude préalable



ETUDE PREALABLE

Point de départ de toute analyse, l’étude préalable

s’avère très importante puisqu’elle permet avant

d’entreprendre un projet, d’élaborer globalement différentes

solutions et d’en évaluer les conséquences.

Par ailleurs, elle envoie à cerner le processus de

fonctionnement du domaine, à décrire l’existant et à faire

ressortir les points forts et points faibles du système. Une

fois ces avantages et inconvénients connus, l’étude

préalable nous envoie à proposer des solutions palliant les

différents problèmes rencontrés et à en choisir la plus

adaptée à la structure d’accueil.

1

19 Etude préalable



II – ETUDE PREALABE

II.1 – Présentation du projet

Avant toute proposition ou étude, il serait opportun de présenter la situation ayant

motivé notre thème. De ce fait, nous allons décrire son contexte, exposer ses objectifs et

avancer les résultats attendus à l’issu de ce projet.

II.1.1 – Contexte et justification

Avec l’avènement des programmes d’ajustements structurels (PAS), un ensemble de

nouvelles priorités se sont définies auprès de notre gouvernement. Parmi elles, nous pouvons

citer une relance économique rapide, une réduction des dépenses du gouvernement et surtout

un suivi et une évaluation des projets afin de rationaliser ses dépenses et l’aide extérieure. Et

c’est dans cet élan que fut créé le 23 janvier 2006, la Direction du Suivi-Evaluation (DSE).

Afin de mieux répondre à ses objectifs, cette direction en collaboration avec ses

partenaires a convenu de disposer d’un ensemble d’outils intégrés et efficients pour le suivi et

l’évaluation des projets de la population ivoirienne.

C’est ainsi qu’il a été soumis à notre réflexion le thème suivant : « réalisation et

sécurisation d’un cadre de gestion de projets ».

II.1.2 – Objectifs

Ce thème a pour principaux buts :

la conception et la réalisation d’une base de données relative aux projets et

programmes déjà réalisés et en-cours de réalisation ;

la réalisation d’outils permettant de prendre en compte des projets et/ou des

programmes à court, moyen et long terme à réaliser

II.1.3 – Résultats attendus

Les différents résultats attendus sont repartis à travers les objectifs précédemment

définis. Dans cet ordre idée :

La base de données doit :

contenir toutes les données relatives aux projets et programmes réalisés et en-cours

de réalisation ;

classifier les projets et programmes selon notamment les secteurs, les facteurs, les

indicateurs ;

1

20 Etude préalable



permettre de décrire les projets et programmes en précisant notamment les

bénéficiaires, les objectifs, le mode de financement, les partenaires, et autres

éléments utiles ;

Les outils doivent permettre :

d’extraire des données de la base de connaissances ;

d’enrichir la base de connaissances de façon régulière par toutes les parties

prenantes des projets et programmes afin de garantir une cohérence et une

adéquation avec la réalité du terrain ;

aux opérateurs économiques et aux partenaires de consulter la base de

connaissances.

II.2 – Méthodes d’analyse et de conception

La conception d’un système d’information n’est pas évidente, car il faut réfléchir à

l’ensemble de l’organisation que l’on doit mettre en place. D’où la nécessité d’une méthode

d’analyse et de conception permettant de mettre en place un modèle sur lequel l’on va

s’appuyer. Il est à noter qu’une méthode d’analyse et de conception est la réunion d’une

démarche et d’un formalisme. Son objectif est de permettre de formaliser les étapes

préliminaires du développement d’un système afin de rendre ce développement plus fidèle

aux besoins du client. Pour ce faire, l’on part d’un énoncé informel (le besoin tel qu’il est

exprimé par le client, complété par des recherches d’informations auprès des experts du

domaine fonctionnel, par exemple les futurs utilisateurs d’un logiciel), ainsi que de l’analyse

de l’existant éventuel (c’est-à-dire la manière dont les processus à traiter par le système se

déroulent actuellement chez le client). La phase d’analyse permet de lister les résultats

attendus, en termes de fonctionnalités, de performance, de robustesse, de maintenance, de

sécurité, d’extensibilité. Tandis que, la phase de conception permet de décrire de manière non

ambiguë, le plus souvent en utilisant un langage de modélisation, le fonctionnement futur du

système, afin d’en faciliter la réalisation.

Nous distinguons, de nos jours, une multitude de méthodes d’analyse et de conception

telles que :

Object Modeling Technique (OMT)

Booch

Object Oriented Software Engineering (OOSE)

Structured Analysis and Design Technique (SADT)

la Méthode d’Étude et de Réalisation Informatique par Sous-ensemble (MERISE)

le couple Unified Processus (UP) et Unified Modeling Language (UML)

Toutefois, ce ne sont que les deux dernières méthodes qui seront étudiées puisqu’elles

sont les plus utilisées et les plus abouties.

1

21 Etude préalable



II.2.1 – La Méthode d’Étude et de Réalisation

Informatique par Sous-ensemble (MERISE)

MERISE est une méthode de conception, de développement et de réalisation de projets

informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La

méthode MERISE est basée sur la séparation des données et des traitements à effectuer en

plusieurs modèles conceptuels et physiques. Cette séparation des données et des traitements

assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent

remanié, tandis que les traitements le sont plus fréquemment. La méthode MERISE date de

1978-1979, et fait suite à une consultation nationale lancée en 1977 par le ministère de

l'Industrie dans le but de choisir des sociétés de conseil en informatique afin de définir une

méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au

point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet,

et le CETE (Centre d'Études Techniques de l'Équipement) implanté à Aix-en-Provence.

Par ailleurs, cette méthode spécifiquement française, a d’emblée connu la concurrence

internationale de méthodes anglo-saxonnes telles que SDM/S ou Axial. Elle a ensuite cherché

à s’adapter aux évolutions rapides des technologies de l’informatique avec MERISE/objet,

puis MERISE/2 destinée à s’adapter au client-serveur et à la vision objet.

En outre, la méthode MERISE représente le système d’information suivant 3

approches et 4 niveaux.

II.2.1.2 – Les concepts

Pour étudier et développer l’informatique d’une entreprise ou de tout type

d’organisme, il est nécessaire de connaître ses échanges internes et avec l’extérieur, comment

réagit-elle à une sollicitation externe et quelle est la structure des informations qu’elle utilise.

Partant de ce constat, la méthode MERISE décrit cette connaissance sous forme de

trois approches :

Communication

Les échanges ou la communication sont les flux entre systèmes, notamment des flux

d’informations ou messages.

Traitement

Les traitements des messages, flux d’informations, décrivent les tâches à effectuer à

la réception ou pour l’émission d’un flux d’informations.

Données

La structure de mémorisation des informations est représentée sous une forme qui

permet un passage aisé vers les enregistrements informatiques.

II.2.1.2 – Les niveaux

L’informatique consiste à mettre à disposition de l’utilisateur des moyens ou des outils

de gestion informatique. Avant de spécifier les moyens informatiques, il est nécessaire de

1

22 Etude préalable



définir le travail de ce ou de ces utilisateurs finals, de définir l’organisation, l’analyse des

objectifs et des fonctions majeures de l’entreprise doit être menée. Ainsi, l’informatisation est

conçue en fonction de l’organisation et l’organisation en fonction des objectifs à atteindre.

Or l’enchainement de l’informatique, de l’organisation et de la fonction nécessite un

découpage en niveaux de la démarche d’informatisation. Ces niveaux sont :

Le niveau conceptuel

C’est le niveau le plus invariant, il correspond aux finalités de l’entreprise. Il s’agit de

décrire le « Quoi » en faisant abstraction des contraintes d’organisation et techniques.

Les modèles utilisés pour la description conceptuelle du système d’information sont :

le Modèle Conceptuel de Communication (MCC) qui représente les échanges de

flux de produits, d’énergie, de personne, de valeur ou d’information entre système.

le Modèle Conceptuel de Données (MCD) qui est une description des données et

des relations et est réalisé à l’aide des trois concepts du formalisme entité-

association : entité (ou objet) – relation – propriétés.

le Modèle Conceptuel des Traitements (MCT) qui est la description de la partie

dynamique du système d’information et est réalisé à l’aide des concepts suivants :

événements/résultat – synchronisation – opération - processus.

Le niveau organisationnel

Les choix d’organisation sont pris en compte à ce niveau comme la répartition des

traitements entre l’homme et la machine, le mode de fonctionnement (temps réel ou

différé) et l’affectation des données et des traitements. Ce niveau répond aux questions

« Qui fait Quoi et Où »

Trois modèles sont associés à ce niveau :

le Modèle Organisationnel de Communication (MOC) qui représente les

échanges qui ont lieu entre les sites de traitements et de données. Il ne concerne

que les communications entre sites. Il n’existe pas s’il n’existe qu’un site ;

le Modèle Organisationnel de Données (MOD) qui reprend le formalisme utilisé

dans le MCD et qui représente aussi l’ensemble des données par type de site

organisationnel ;

le Modèle Organisationnel des Traitements (MOT) qui représente par

procédures les phases et les tâches exécutées par chaque poste de travail.

Le niveau logique

Ce niveau décrit le système d’information au plan informatique sans choix de matériel

ou de logiciel précis. Nous avons trois modèles reliés à ce niveau :

le Modèle Logique de Communication (MLC) qui est une représentation des

messages échangés entre site et base de données. Il provient du MLD et de

l’utilisation des outils en temps différé.

le Modèle Logique des Données (MLD) qui est une représentation des données

décrit dans le MCD en tenant compte du type de base de données.

1

23 Etude préalable



le Modèle Logique des Traitements (MLT) qui permet de décrire la conception

technique qui traite principalement de la structuration en unités de traitement de

type temps réel ou de type temps différé.

Le niveau physique

Ce niveau décrit le résultat de la méthode ou l’informatisation finale. Il dépend des

logiciels de développement nécessaires à la programmation et à la manipulation des

données. La méthode laisse place aux normes du réel.

Nous avons encore trois modèles liés :

le Modèle Physique des Communication (MPC) qui comprend la télématique

entre sites informatiques.

le Modèle Physique des Données (MPD) qui n’est qu’un modèle de la base de

données.

le Modèle Physique des Traitements (MPT) qui comprend les programmes

techniques et leur environnement d’exploitation, moniteur temps réel, traitement

par lot, temps partagé.

II.2.1.3 – La démarche

La méthode MERISE propose une démarche de construction de système d’information

en 6 étapes (figure 2) :

le schéma directeur : définition de la politique de l’entreprise

l’étude préalable : analyse de l’existant qui conduit à des variantes

l’étude détaillée : étude approfondie de la solution choisie par la direction

l’étude technique : étude purement informatique, seuls les informaticiens

interviennent

la réalisation : programmation proprement dite

la maintenance : suivi et évolution.

Cette démarche (figure 2) s’appuie sur un cycle de vie en cascade qui date de 1970 et

est l’œuvre de Royce. Il s’agit d’un mode linéaire où toute étape est censée n’avoir de

rétroaction que sur l’étape qui la précède. L’activité d’une étape se réalise avec les résultats

fournis par l’étape précédente ; ainsi, chaque étape sert de contrôle du travail effectué lors de

l’étape précédente. L’utilisateur attend le déroulement complet du cycle de vie du logiciel

pour vérifier, lors de la dernière étape, l’adéquation entre ses exigences et le produit livré.

1

24 Etude préalable



Figure 2 : la démarche MERISE

Figure 3 : la courbe du soleil

En 1978, MERISE introduisit les prémices de différenciation entre découpage

temporel du cycle de vie et activités menées à chaque étape; cette différenciation a été

illustrée par la courbe du soleil (figure 3). Sur l’axe horizontal se trouve le cycle de vie sous

forme d’état du système d’information et sur l’axe vertical, le cycle d’abstraction, se trouve la

représentation du système. Dans cet espace à 2 dimensions sont représentées les différentes

activités.

1

25 Etude préalable



II.2.2 – Le processus unifié

Le processus unifié (en anglais Unified Process) est une méthode générique de

développement de logiciel. Il est générique puisqu’il est nécessaire de l’adapter au contexte

du projet, de l’équipe, du domaine et/ou de l’organisation (exemple R.UP ou X.UP ou

2T.UP). Cette méthode regroupe les activités à mener pour transformer les besoins d’un

utilisateur en système logiciel. De plus, le processus unifié :

est à base de composants,

utilise le langage UML,

est piloté par les cas d’utilisation,

est centré sur l’architecture,

est itératif et incrémental.

En outre, le langage de modélisation UML qu’il utilise n’est qu’un langage graphique

de modélisation des données et des traitements. C’est une formalisation très aboutie et non-

propriétaire de la modélisation objet. Depuis novembre 2007, sa version 2.1.2 est diffusée par

l’Object Management Group (OMG). Ce langage de modélisation est l’accomplissement de la

fusion des précédents langages de modélisation objet Booch, OMT, OOSE. Principalement

issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML qui est à présent

un standard défini par l’OMG, n’est pas une méthode, mais seulement un langage graphique

qui permet de représenter, de communiquer les divers aspects d’un système d’information.

Compte tenu du fait, qu’il soit impossible de donner une représentation graphique

complète d’un logiciel, ou de tout autre système complexe, UML propose des vues partielles

dont la juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave. Ainsi

UML 2.0 comporte treize diagrammes représentant autant de vues distinctes pour représenter

les concepts particuliers du système d’exploitation.

II.2.2.1 – Les diagrammes

Nous dénotons depuis sa version 2.0, treize diagrammes qui sont dépendants

hiérarchiquement et complémentaires :

Les diagrammes structurels ou diagrammes statiques

le diagramme de classes : il représente les classes intervenant dans le système ;

le diagramme d’objets : il sert à représenter les instances de classes (objets)

utilisées dans le système ;

le diagramme de composants : il permet de montrer les composants du système

d’un point de vue physique, tel qu’ils sont mis en œuvre ;

le diagramme de déploiement : il sert à représenter les éléments matériels

(ordinateurs, périphériques, réseaux, système de stockage..) et la manière dont les

1

26 Etude préalable



composants du système sont répartis sur ces éléments matériels et interagissent

avec eux ;

le diagramme de paquetages : un paquetage étant un conteneur logique

permettant de regrouper et d’organiser les éléments dans le modèle UML, le

diagramme de paquetages sert à représenter les dépendances entre paquetages,

c'est-à-dire les dépendances entre ensembles de définitions ;

le diagramme de structure composite : il permet de décrire sous forme de boite

blanche les relations entre les composants d’une classe.

Les diagrammes comportementaux

le diagramme des cas d’utilisation : il permet d’identifier les possibilités

d’interaction entre le système et les acteurs (intervenants extérieurs au système),

c'est-à-dire toutes les fonctionnalités que doit fournir le système;

le diagramme d’états transition : il permet de décrire sous forme de machine à

états finis le comportement du système ou de ses composants ;

le diagramme d’activité : il permet de décrire sous forme de flux ou

d’enchaînement d’activités le comportement du système ou de ses composants ;

les diagrammes d’interactions ou diagrammes dynamiques

le diagramme de séquence : il est la représentation séquentielle du

déroulement des traitements et des interactions entre les éléments du système

et/ou de ses acteurs ;

le diagramme de communication : il est la représentation simplifiée d’un

diagramme de séquence se concentrant sur les échanges de messages entre les

objets ;

le diagramme global d’interaction : il permet de décrire les enchaînements

possibles entre les scénarios préalablement identifiés sous forme de

diagrammes de séquences (variante du diagramme d’activité) ;

le diagramme de temps : il permet de décrire les variations d’une donnée au

cours du temps

II.2.2.2 – Les vues

Pour mettre en œuvre UML, l’on peut considérer différentes vues (figure 4) qui

peuvent se superposer pour collaborer à la définition du système. Nous pouvons citer :

la vue des cas d’utilisation : c’est la description du modèle « vue » par les acteurs du

système. Elle correspond aux besoins attendus par chaque acteur (c’est le QUOI et le

QUI) ;

la vue logique : c’est la définition du système vu de l’intérieur. Elle explique comment

peuvent être satisfaits les besoins des acteurs (c’est le COMMENT) ;

la vue d’implémentation : cette vue définit les dépendances entre les modules ;

1

27 Etude préalable



Figure 4 : les vues d’UML

la vue des processus : c’est la vue temporelle et technique qui met en œuvre les

notions de tâches concurrentes, stimuli, contrôle, synchronisation ;

la vue de déploiement : cette vue décrit la position géographique et l’architecture

physique de chaque élément du système (c’est le OU).

II.2.2.3 – La démarche

Le processus unifié est organisé autour de quatre phases (figure 5) dont :

l’inception : elle permet de déterminer les limites du projet, ce qui doit être réalisé et

ce qui ne doit pas être réalisé. Pour cela, les besoins des utilisateurs sont recueillis et

exprimés dans les cas d’utilisation du système. L’ensemble des cas d’utilisation

constitue les spécifications du système. À partir des cas d’utilisation, une architecture

candidate est proposée. En se basant sur de ce plan d’architecture, les coûts sont

évalués, un plan de travail est réalisé, et les principaux risques répertoriés. Enfin,

l’environnement est mis en place.

l’élaboration : elle permet de stabiliser et de raffiner l’architecture. Le plan de travail

de la phase de construction est précisé par un plan d’itérations. En raffinant

l’architecture, les principaux composants sont identifiés.

la construction : elle applique le plan d’itération défini dans la phase précédente, et

consiste surtout à optimiser la gestion des ressources. Afin de réduire les coûts de

développement et améliorer la qualité, le processus est optimisé.

la transition : elle consiste à déployer, tester et valider. Une grosse partie de la

dernière phase consiste à accompagner l’utilisateur final par la rédaction de

documentation et la mise en place de sessions de formation.

Vue d’implémentation Vue Logique

Vue du déploiement Vue des processus

Vues des cas

d’utilisation

1

28 Etude préalable



Figure 5 : les différentes phases

Le processus unifié propose aussi des activités (figure 6) qui se repartissent dans les

différentes phases précédemment citées. Nous avons :

la modélisation métier

L’activité de modélisation métier permet de mieux comprendre la structure et la

dynamique de l’organisation. Il est alors plus aisé de comprendre un problème posé et

de proposer la meilleure solution dans le contexte de l’organisation cliente. En outre,

cette activité peut donner lieu à la réalisation d’un glossaire des termes métiers. Un

livrable important de cette activité est la cartographie des processus métier de

l’organisation cliente. Coûteuse à réaliser, car elle tient compte de l’ensemble du

système d’information du client, elle permet d’accélérer la compréhension d’un

problème posé en extrayant les besoins utilisateurs et en exprimant toutes les

dépendances fonctionnelles.

le recueil de besoins

Grâce à l’analyse métier, on comprend les rouages du système complet d’une

organisation. Lorsqu’il s’agit de développer une application sur une partie du système

d’information, il convient de cibler les besoins des utilisateurs et des clients au moyen

d’une série d’interviews. L’ensemble des parties prenantes du projet, maîtrise

d’œuvre et maîtrise d’ouvrage, est acteur de cette activité. L’activité de recueil et

d’expression des besoins définit ce que doit faire le système. L’analyste utilise les cas

d’utilisation pour schématiser les besoins, et structurer les documents de

spécifications fonctionnelles. Les cas d’utilisation sont en effet décomposés en

1

29 Etude préalable



scénarios d’usage du système, dans lesquels l’utilisateur explique ce qu’il fait à l’aide

du système et ses interactions avec le système. Un maquettage est réalisable pour

mieux « immerger » l’utilisateur dans le futur système. Une fois les limites

fonctionnelles posées, le projet est planifié et une prévision des coûts est réalisée.

l’analyse et conception

Cette activité consiste à transformer les besoins utilisateurs en modèles UML, donc à

faire une analyse objet. Les principaux livrables de cette activité sont les modèles

d’analyse et de conception. L’analyse objet est neutre vis-à-vis d’une technologie. La

conception tient compte des exigences non fonctionnelles et des choix

technologiques. Le système est analysé et résulte en une proposition d’architecture.

Cette architecture est découpée en composants.

Implémentation

Cette activité consiste à concevoir le système par composants. C’est-à-dire que le

système est développé par morceaux dépendant les uns des autres. Ainsi, il est

possible d’optimiser l’utilisation des ressources selon leurs expertises. Les découpages

fonctionnels et en couches sont indispensables pour cette activité. Il est tout à fait

envisageable de retoucher les modèles d’analyse et de conception à ce stade. De cette

façon, les futurs développements bénéficieront de l’expérience des travaux précédents

sur le même type d’architecture.

Test

À toutes les étapes, différents types de test sont réalisés. Dans le cycle de

développement itératif, chaque activité doit être régulièrement validée, à chaque point

de contrôle défini au préalable et nommé : jalon.

Déploiement

L’activité de déploiement consiste à déployer les développements une fois réalisés.

Elle peut être réalisée très tôt dans le processus dans une sous-activité de prototypage

dont l’objectif est de valider l’architecture physique, et les choix technologiques.

Configuration/gestion du changement, gestion de projet et gestion de

l’environnement

Ces activités sont indispensables au déroulement d’un cycle de développement d’un

système informatique. La gestion du changement consiste à anticiper aussi bien les

évolutions technologiques que les évolutions des besoins. La configuration consiste à

fournir un code ajustable par l’utilisateur lui-même. La gestion de projet consiste à

gérer les ressources et ordonnancer l’ensemble du processus. Enfin, la gestion de

l’environnement consiste à mettre en place tout ce qui permet aux différents rôles de

réaliser au mieux leurs activités.

1

30 Etude préalable



Figure 6 : les activités

Figure 7 : le développement itératif et incrémental

Comme précédemment signalé, le processus unifié s’appuie sur un cycle de vie itératif et

incrémental (figure 7). Ce qui signifie que le développement s’organise en une série de mini

projets courts, de durée fixe, nommés itérations. Le résultat de chacune des itérations est un

système testé, intégré et exécutable. Chacune de ces itérations comprend ses propres

activités : analyse des besoins, conception, implémentation, tests et déploiement.

1

31 Etude préalable



Figure 8 : les risques

II.2.3 – Choix d’une méthode

Après avoir passé en revue, les différentes présentations des méthodes étudiées et en

tenant compte des spécifications de notre projet, nous avons orienté notre choix sur le

processus unifié pour les raisons suivantes :

Une meilleure gestion des changements

Grâce aux différents livrables produits à la fin des itérations, le processus unifié nous

permet d’ajuster les choix en termes d’architecture ou de conception graphique par

exemple très tôt dans le processus et non après que ces derniers aient été

complètement réalisés comme en MERISE.

Une réduction des risques

En nous basant sur les propos de Peter F. Drucker qui stipule que le risque est

inhérent à l’engagement de ressources actuelles vers des attentes futures (figure 8),

nous pouvons dire que le processus unifié réduit considérablement les risques. En

effet, le système se construisant par étapes à travers des livrables, elle nous permet de

détecter les risques plus tôt et aussi les ressources mobilisées sont minimes par rapport

à ceux occasionnés par MERISE. Cette dernière qui présente le produit au client

qu’une fois terminée, entraine une grande utilisation de ressources qui peut s’avérer

dangereuse si le produit livré ne correspond pas aux exigences du client.

Un contrôle perpétuel de la qualité

Contrairement à MERISE qui ne juge de la qualité qu’une fois le produit fini, le

processus unifié vérifie à chaque itération la qualité du livrable à travers des tests de

fonctionnement.

1

32 Etude préalable



Une mise en confiance du client

Le processus unifié permet de rassurer le client, car celui-ci peut voir concrètement la

progression du projet à travers la manipulation ou l’exécution de cas d’utilisation réels

de son produit. Alors qu’avec MERISE, il pourra tester son produit qu’une fois

terminée et après avoir attendu un long moment.

Une participation active du client

Le processus unifié donne l’occasion au client de visualiser le résultat des itérations et

donc d’exprimer les ajustements désirés au fur et à mesure que le projet avance, et non

pas uniquement à la fin du projet comme en MERISE.

Un meilleur développement

Le processus unifié permet aux développeurs de demeurer concentrés sur les

fonctionnalités qui font partie de l’itération courante au lieu de réfléchir sur

l’ensemble des fonctionnalités du système. Ainsi, tout changement, ou correction qui

s’ajoute à la liste des tâches est planifié dans les itérations subséquentes. Comme la

durée d’une itération est relativement courte, les clients et chefs de projets acceptent

généralement ce délai.

Toutefois, le processus unifié étant une méthode générique puisqu’elle ne définit

qu’un certain nombre de critères de développement, plusieurs déclinaisons personnalisées

selon les besoins ont été élaborées. Ainsi, nous notons parmi les plus connus : le Rational

Unified Process (RUP), l’Extrem Unified Process (XUP) et enfin le Two Tracks Unified

Process (2TUP).

Cette dernière déclinaison qui est l’œuvre de la société Valtech a été celle qui a été

adoptée tout au long du projet puisque non seulement elle prend en compte les aléas et

contraintes liées aux changements perpétuels et rapides des systèmes d’informations des

entreprises. Mais aussi parce que l’axiome fondateur du 2TUP a été le constat que toute

évolution imposée au système d’information peut se décomposer et se traiter parallèlement,

suivant un axe fonctionnel et un axe technique. À l’issue des évolutions du modèle

fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner les

résultats de ces deux branches du processus.

Description Avantages Inconvénients

RUP

Rational

Unified Process

Instanciation d’UP par

Rational Software (IBM).

Le RUP est à la fois une

méthodologie et un outil

prêt à l'emploi (documents

types partagés dans un

référentiel Web)

Cible des projets de plus

de 10 personnes

Itératif

Spécifie le dialogue entre

les différents intervenants

du projet : les livrables, les

plans de travail, les

prototypes…

Propose des modèles de

documents, et des canevas

pour des projets types

Coûteux à personnaliser

Très axé processus, au

détriment du développement :

peu de place pour le code et la

technologie

1

33 Etude préalable



Tableau 2 : les différentes déclinaisons du processus unifié

XUP

eXtrem

Programming

Unified Process

Instanciation hybride

intégrant UP avec

l’Extrem Programming

Ensemble des meilleures

pratiques de

développement (travail en

équipes, transfert de

compétences…)

Cible des projets de moins

de 10 personnes

Itératif

Simple à mettre en œuvre

Fait une large place aux

aspects techniques :

prototypes, règles de

développement, tests…

Innovant: programmation

en duo, kick-off matinal

debout …

Ne couvre pas les phases en

amont et en aval au

développement : capture des

besoins, support,

maintenance, tests

d'intégration…

Elude la phase d'analyse, si

bien qu'on puisse dépenser

son énergie à faire et défaire

Assez, confus dans sa mise en

œuvre: quels intervenants,

quels livrables ?

2TUP

Two Tracks

Unified Process

Instanciation d’UP

proposé par Valtech

prenant en compte les

aléas et contraintes liées

aux changements

perpétuels et rapides des

SI des entreprises.

S'articule autour de

l'architecture

Propose un cycle de

développement en Y

Cible des projets de toutes

tailles

Itératif

Fait une large place à la

technologie et à la gestion

du risque

Définit les profils des

intervenants, les livrables,

les plans de travail, les

prototypes

Plutôt superficiel sur les

phases situées en amont et en

aval du développement :

capture des besoins, support,

maintenance, gestion du

changement…

Ne propose pas de documents

types

II.3 – Etude de l’existant

Afin de mener efficacement notre travail et surtout de prendre en compte tous les

aspects techniques, fonctionnels et contextuels qui entourent le projet, il convient d’étudier les

éléments existants dans le système actuel de gestion de projets et de faire par la suite quelques

critiques.

II.3.1 – Description de l’existant

Tout au long de cette partie, nous avons utilisé les modèles d’UML pour mieux

représenter les données et les traitements que nous avons trouvés en place. Mais avant de

commencer à modéliser, une description du processus de gestion des projets obtenue à travers

des interviews et de l’examen des documents utilisés se révèle indispensable.

1

34 Etude préalable



II.3.1.1 – Description du processus de gestion des projets

Dès qu’un organisme décide de travailler avec un gouvernement, il étudie avec celui-

ci les différentes priorités nationales. À la sortie de cette étude, les deux parties s’accordent

sur un programme s’étendant sur une période donnée, et visant à pallier les problèmes que

rencontre le pays.

Le programme adopté se divise en un ou plusieurs sous-programmes pour mieux

répondre à ses objectifs. Chaque sous-programme se voit attribuer à un point focal lié à un

organisme. Non seulement, ces sous-programmes définissent chacun des produits qui ne sont

que les différents buts, mais se décomposent encore en plusieurs projets qui tendent à réaliser

ces produits.

Pour chaque projet, des stratégies sont déterminées et elles fixent des résultats que

devront atteindre les différentes activités du projet. Les activités en question sont caractérisées

par des indicateurs, se réalisent dans des localités et sont budgétisées. Dans leurs exécutions,

elles entrainent des décaissements proportionnels aux différentes contributions apportées par

les organismes et les ministères.

Dans un souci de bonne organisation, une direction dépendant d’un ministère a à sa

charge un ou plusieurs projets. Dans un tel contexte, elle choisit des directeurs de projets qui

doivent administrer les projets qui sont sous sa tutelle. Les directeurs de projets nommés

sélectionnent les parties responsables de l’exécution des activités de leurs projets.

À chaque fin de trimestre, l’avancée de chaque projet est relatée dans un rapport qui

signale aussi les différents problèmes rencontrés dans le déroulement des activités. Les

problèmes mentionnés suscitent des recommandations qui conduisent à l’exécution d'autres

activités. De plus, à la fin de l’année, des rapports décrivant le déroulement des projets sont

présentés.

Pour les besoins de l’évaluation et du suivi, un contrôleur vérifie les différents

indicateurs d’une activité pour la valider ou non.

II.3.1.2 – Le diagramme de cas d’utilisation

Ce diagramme dont la principale utilité est de représenter la structure des grandes

fonctionnalités nécessaires aux utilisateurs du système nous a permis ici de modéliser les

différents besoins des utilisateurs par rapport au système actuel (figure 9).

II.3.1.2.1 – les concepts

Compte tenu du fait que nous avons eu recours au formalisme d’UML pour mieux

décrire notre existant, il nous est apparu judicieux de présenter les différents concepts qui

rentrent en ligne de compte :

Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou

une chose qui interagit avec un système. Il se représente par un petit « bonhomme »

(figure 9) avec son nom (son rôle) inscrit en dessous.

1

35 Etude préalable



Figure 9 : concepts du diagramme de cas d’utilisation

Un cas d’utilisation est une unité cohérente d’une fonctionnalité visible de

l’extérieur. Il réalise un service de bout en bout, avec un déclenchement, un

déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation modélise donc un

service rendu par le problème, sans imposer le mode de réalisation de ce service. Il est

représenté par une ellipse (figure 9) contenant le nom du cas et optionnellement, au-

dessus du nom un stéréotype.

Une Relation d’association est chemin de communication entre un acteur et un cas

d’utilisation. Elle est représentée par un trait continu (figure 9).

Un cas d’utilisation interne est un cas d’utilisation (figure 9) qui n’est pas

directement relié à un acteur.

Une relation d’inclusion d’un cas d’utilisation A par à un cas d’utilisation B signifie

qu’une instance de A contient le comportement décrit dans B (figure 9). Une telle

relation est symbolisée par une flèche avec un trait pointillé (figure 9).

Une relation de généralisation : un acteur A est une généralisation d’un acteur C si

l’acteur A peut être substitué par l’acteur C. Dans ce cas, tous les cas d’utilisation

accessibles à A le sont aussi à C, mais l’inverse n’est pas vrai. Le symbole utilisé pour

la généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé

désignant le cas le plus général (figure 9).

1

36 Etude préalable



Figure 10 : système actuel - diagramme de cas d’utilisation

II.3.1.2.2 – la représentation du diagramme de cas

d’utilisation

1

37 Etude préalable



Tableau 3 : système actuel - mettre à jour une activité

Tableau 4 : système actuel – valider un indicateur

II.3.1.3 – Les descriptions textuelles

Ces descriptions nous ont permis d’expliciter les cas d’utilisations du système actuel.

Cas d’utilisation : mettre à jour une activité

Nom Mettre à jour une activité

Acteurs principaux Responsable d’activité

Acteurs secondaires chargé d’étude, SIGPOD

Pré conditions Des activités ont été enregistrées

Scénarii Scénario nominal

1 Le responsable d’activité saisit les informations sur l’activité qu’il veut

renseigner

2 Le responsable d’activité présente le document

3 Le chargé d’étude vérifie le document

4 Le SIGPOD sauvegarde le document

Scénario alternatif

Point 3 : le document n’est

pas conforme

1 Le chargé d’étude présente le document

en mettant en surbrillance les erreurs

2 Reprise au point 1

Post conditions Des activités ont été mises à jour

Cas d’utilisation : valider un indicateur

Nom Valider un indicateur

Acteurs principaux Contrôleur

Acteurs secondaires chargé d’étude, SIGPOD

Pré conditions Des activités et des indicateurs ont été sauvegardés


1 Le contrôleur saisit les informations concernant l’indicateur qu’il veut

valider

2 Le contrôle présente le document




Point 3: le document n’est

pas conforme




Post conditions Des indicateurs ont été mis à jour

1

38 Etude préalable



Tableau 5 : système actuel - mettre à jour des informations

Tableau 6 : système actuel - consulter des informations

Cas d’utilisation : mettre à jour des informations

Nom Mettre à jour des informations

Acteurs principaux Chargé d’étude

Acteurs secondaires SIGPOD

Pré conditions Le système est disponible


1 Le chargé d’étude saisit les informations qu’il veut renseigner




Point 3: le document n’est

pas conforme




Post conditions Des informations ont été mises à jour

Cas d’utilisation : consulter des informations

Nom Consulter les informations

Acteurs principaux Tierce personne

Acteurs secondaires Chargé d’étude

Pré conditions Des informations sont disponibles


1 La personne demande les informations qu’il souhaite

2 Le chargé d’étude recherche les informations

3 Le chargé d’étude réalise une copie des informations

4 Le chargé d’étude présente les informations

5 La personne prend connaissance des informations

Post conditions Des informations sont disponibles

II.3.1.4 – Les diagrammes d’activités

Ces diagrammes qui permettent de mettre l’accent sur les traitements nous ont servi à

représenter les différentes procédures existantes dans le système actuel.

II.3.1.4.1 – Les concepts

En vue d’une meilleure compréhension des diagrammes d’activités, nous allons

procéder à une définition des principaux éléments qui concernent le diagramme d’activité.

1

39 Etude préalable



Une partition souvent appelée couloir ou ligne d’eau (swimlane) du fait de leur

notation, permet d’organiser les nœuds d’activités dans un diagramme d’activités en

opérant des regroupements. Graphiquement, les partitions sont délimitées par des

lignes continues. Il s’agit généralement de lignes verticales, comme sur la figure 11,

mais elles peuvent être horizontales ou même courbées.

Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque

l’activité enveloppante est invoquée. Une activité peut avoir plusieurs nœuds initiaux.

Un nœud initial possède un arc sortant et pas d’arc entrant. Graphiquement, un nœud

initial est représenté par un petit cercle plein (figure 11).

Un nœud final est un nœud de contrôle ne possédant qu’un ou plusieurs arcs entrants

et aucun sortant. Il est représenté par un petit cercle qui contient une croix (figure 11).

Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre

plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants. Ces derniers

sont généralement accompagnés de conditions de garde pour conditionner le choix.

Graphiquement, on représente un nœud de décision par un losange (figure 11) ;

Un nœud d’action est un nœud d’activité exécutable qui constitue l’unité

fondamentale de fonctionnement exécutable dans une activité. Un nœud d’action doit

avoir au moins un arc entrant. Graphiquement, un nœud d’action est représenté par un

rectangle aux coins arrondis (figure 11).

Une transition marque le passage d’un nœud vers un autre. Graphiquement, une

transition est représentée par une flèche en trait plein et connecte les nœuds entre eux

(figure 11).

1

40 Etude préalable



Figure 12 : système actuel – mise à jour d’une activité

Figure 11 : concepts du diagramme d’activités

II.3.1.4.2 – Les représentations des diagrammes

d’activités


1

41 Etude préalable



Figure 13 : système actuel – validation d’un indicateur

Figure 14 : système actuel – mise à jour d’informations


Cas d’utilisation : mettre à jour les informations

1

42 Etude préalable



Figure 15 : système actuel – consultation d’informations


II.3.1.5 – Les diagrammes de classes

Principalement utilisés pour représenter la structure interne d’un système

d’information, nous les avons utilisés pour modéliser l’architecture conceptuelle du système

actuel. Cependant compte tenu du grand nombre de classes du système nous avons découpé

notre diagramme de classes en deux diagrammes axés l’un sur les projets et l’autre sur les

activités.

II.3.1.5.1 – Les concepts

Les concepts propres aux diagrammes de classes doivent être définis pour permettre

une bonne lecture des diagrammes de classes qui seront représentées.

Une classe est la description abstraite d’un ensemble d’objets de même structure et de

même comportement extrait du monde à modéliser. Elle est représentée par un

rectangle divisé en un ou cinq compartiments (figure 16).

Une propriété est une donnée élémentaire qui sert à caractériser les classes et les

relations.

Une méthode est une opération autorisée sur les objets d’une classe.

Une association est une relation entre deux classes ou plus qui décrit les connexions

structurelles entre leurs instances. Graphiquement, elle est représentée par un trait

continu reliant les classes participantes (figure 16).

1

43 Etude préalable



Figure 16 : concepts du diagramme de classes

Une multiplicité exprime le nombre minimum et maximum d’objets d’une classe qui

peuvent être reliés à des objets d’une autre classe.

la généralisation décrit une relation entre une classe générale et une classe

spécialisée. La classe spécialisée est intégralement cohérente avec la classe de base,

mais comporte des informations supplémentaires. Un objet de la classe spécialisée

peut être utilisé partout où un objet de la classe de base est autorisé. Graphiquement,

elle est matérialisée par un trait plein dont la pointe est un triangle fermé désignant la

classe de base (figure 16).

Le rôle définit comment une classe voit une autre classe au travers d’une association.

La visibilité définit les niveaux d’accès d’une propriété ou d’une méthode.

II.3.1.5.2 – Les représentations des diagrammes de

classes

1

44 Etude préalable



Figure 17 : système actuel -

diagramme de classes axé

sur les activités

1

45 Etude préalable



Figure 18 : système actuel –

Diagramme de classes axé

sur les projets

1

46 Etude préalable



II.3.2 – Critiques de l’existant

Notons que la DSE dispose d’outils et de personnes compétentes et de très grande

volonté, car elles ont permis jusqu'à aujourd’hui la gestion, le suivi et l’évaluation de

plusieurs projets. Mais, il nous incombe de faire ressortir les trivialités de cette gestion afin de

proposer des solutions idoines.

Dans ce qui suit, nous nous évertuerons à exposer au mieux les points que nous avons

jugés insuffisants, et qui requièrent une attention particulière.

Une redondance des informations

Aucun contrôle n’est effectué pour vérifier l’existence de certaines informations dans

le système. Ce qui induit des redondances puisqu’un fichier concernant un sujet peut

se retrouver plusieurs fois dans le système.

une lourdeur d’accès aux données

Il est souvent nécessaire d’éditer plusieurs fichiers et les lire afin d’en tirer les

informations nécessaires.

Un manque de sécurité

Les fichiers étant sur des ordinateurs, la seule protection dont ils jouissent n’est que le

mot de passe de l’utilisateur de la machine. Ce qui parfois s’avère insuffisant. De plus,

aucune traçabilité des modifications sur un fichier n’est gérée.

Un manque de contrôle de concurrence

Dans un environnement comme celui de la DSE, où plusieurs personnes accèdent au

même fichier, des problèmes de concurrence d’accès se posent très rapidement.

Une maintenance difficile

Afin d’apporter des compléments d’informations concernant un projets, les différents

intervenants sont obligés de rencontrer les chargés d’étude en vue de pouvoir leur

soumettre leurs modification. Ce qui ralentit souvent le processus de suivi puisqu’il

dépend principalement de la disponibilité des chargés d’étude.

Une consultation d’informations difficile

Les opérateurs économiques et les partenaires voulant consulter des informations sont

obligés de prendre contact avec un chargé d’étude. Dans un tel contexte, il revient

assez pénible aux intervenants de recueillir des informations au moment dont ils ont le

plus besoin.

1

47 Etude préalable



II.4 – Proposition de solution

Dans le souci de résoudre les problèmes cités plus haut et de respecter le cahier de

charge défini au début du projet, nous proposons une solution organisée autour de plusieurs

axes.

Premièrement, vu la nécessité de présenter les informations en rapport à des projets à

tous les intervenants, nous avons opté pour la création d’un site web dynamique qui

est de nos jours le meilleur moyen de communication et de propagation

d’informations.

Deuxièmement, en vue de conserver toutes les informations concernant les projets et

de permettre un accès aisé, une base de données de ces projets sera construite et

optimisée pour de meilleures performances.

Troisièmement, afin de permettre à tous les intervenants d’un projet de mettre à jour

les informations dudit projet, un ensemble de formulaires assez intuitifs et faciles

d’utilisation seront élaborés et se grefferont au site web dynamique.

Et finalement, pour les besoins de sécurité, des mesures de sécurité seront mises en

place afin de permettre l’authentification et la gestion des utilisateurs, en plus de la

traçabilité des opérations sur les informations.

1

48 Conception du cadre



CONCEPTION DU CADRE

Après les étapes de l’étude préalable qui nous ont

permis de :

comprendre l’existant

montrer ses limites

proposer une solution idoine.

Cette partie va nous permettre d’élaborer les

différents modèles nécessaires à la réalisation de la solution

proposée.

Ainsi, cette conception qui se fera selon la méthode du

processus unifié s’organisera autour des différentes

activités qui se sont répétés au cours des différentes

itérations.

1




III – CONCEPTION DU CADRE

III.1 – Modélisation métier

III.1.1 – Présentation du projet à réaliser

En nous basant sur notre proposition de solution, nous pouvons dire que le projet à

réaliser est un site web dynamique et sécurisé. En résumé, Il doit permettre dans un

environnement sécurisé de gérer, suivre et évaluer les différents projets dont s’occupe la

Direction du Suivi-Evaluation.

III.1.2 – Recueil des besoins fonctionnels

Afin de répondre aux attentes des utilisateurs, nous avons procédé à plusieurs

recherches pour identifier au mieux les besoins de l’application. Nous sommes non seulement

allés chercher les informations auprès des chargés d’études de la DSE. Mais, nous nous

sommes procuré quelques documents qui expliquent le mode de fonctionnement de la gestion,

du suivi et de l’évaluation des projets. Ce qui nous a permis d’établir la description des

processus de gestion, suivi et évaluation des projets qui figure dans l’étude préalable plus

haut.

III.1.3 – Identification des acteurs

Pour trouver les acteurs d’un système, il faut au préalable identifier quels sont les

différents rôles que vont devoir jouer ses utilisateurs. Il faut également s’intéresser aux autres

systèmes aux autres systèmes avec lesquels le système va devoir communiquer.

Une fois ces tâches effectuées, nous avons pu identifier les acteurs susceptibles

d’interagir avec le système :

L’internaute qui est considéré comme toute personne se connectant au site web. Il

peut consulter toutes les informations mises à sa disposition

Le responsable d’activité qui est un intervenant d’un projet chargé d’apporter des

informations sur les différentes activités dont il a la charge. Ainsi, il introduit des

informations sur des activités

le contrôleur qui est la personne dont la fonction est de contrôler les indicateurs. De

ce fait, il valide les différents indicateurs caractérisant les activités

le chargé d’étude qui est celui qui doit enregistrer, modifier et supprimer les

informations concernant les projets. Il peut mettre à jour les informations en rapport

avec les projets.

1




l’administrateur qui est la personne chargée de créer les profils utilisateurs et

d’attribuer les droits d’accès.

III.1.4 – Identification des messages

Dans cette partie, nous allons citer les différents messages échangés entre le système et

l’extérieur mais d’abord il serait profitable de définir un message. En effet, un message

représente la spécification d’une communication unidirectionnelle entre les objets qui

transporte de l’information avec l’intention de déclencher une activité chez le récepteur.

Comme messages émis par le système, nous avons :

Les informations détaillées sur les projets.

La liste des programmes.

La liste des sous-programmes par programme.

La liste des projets par sous-programme.

La liste des activités par projets.

Les états des indicateurs des activités.

La liste des profils utilisateurs.

Concernant les messages que reçoit le système, nous pouvons citer :

Les créations, modifications, suppressions de profils utilisateurs.

Les ajouts, modification, suppression d’informations concernant des projets.

Les ajouts, modification, suppression d’informations concernant des activités.

Les validations d’indicateurs.

Les demandes d’informations concernant les projets.

III.1.5 – Modélisation du contexte

À partir des informations obtenues lors des deux précédentes étapes, nous avons pu

modéliser le contexte de notre application. Ceci va nous permettre de définir le rôle de chaque

acteur dans le système.

1




Tableau 7 : les besoins fonctionnels

Utilisateurs finaux Description des besoins fonctionnels

L’internaute L’application doit permettre à l’internaute de

Consulter toutes les informations disponibles.

Demander des informations précises en rapport avec des

projets.

Le responsable d’activité L’application doit permettre au responsable d’activité de

S’authentifier.

Enregistrer/modifier/supprimer les dates de réalisation

effective des activités

signaler/modifier/supprimer les problèmes rencontrés lors de

l’exécution d’une activité

Enregistrer/modifier/supprimer les preuves de la réalisation

d’une activité

Le contrôleur L’application doit permettre au contrôleur de

S’authentifier.

valider ou non un indicateur

donner/modifier/supprimer ses observations concernant un

indicateur

consulter les états des indicateurs

Le chargé d’étude L’application doit permettre au chargé d’étude de

S’authentifier.

enregistrer/modifier/supprimer les informations en rapport

avec des projets

L’administrateur L’application doit permettre à l’administrateur de

S’authentifier.

Créer/modifier/supprimer des profils utilisateurs

Donner/retirer/modifier des droits d’accès

1




Tableau 8 : les cas d’utilisation

III.2 – Recueil et expression des besoins

III.2.1 – Identification des cas d’utilisation

Pour constituer les cas d’utilisation, il faut considérer l’intention fonctionnelle de

l’acteur par rapport au système dans le cadre de l’émission ou de la réception de chaque

message. En regroupant les intentions fonctionnelles en unités cohérentes, nous obtenons les

cas d’utilisation.

Cas d’utilisation Acteur principal Messages émis / reçus par les acteurs

Consulter des informations internaute Émission : demande d’information

Réception : informations détaillées sur un projet, liste

des programmes, liste des sous-programmes, liste des

activités, liste des projets

Mettre à jour une activité Responsable d’activité Émission : ajouts, modification, suppression

d’informations concernant des activités

Réception : liste des activités

Mettre à jour des informations Chargé d’étude Émission : ajouts, modification, suppression

d’informations concernant des projets

Réception : liste des projets

Valider un indicateur contrôleur Émission : validation d’indicateur

Réception : états des indicateurs

Gérer les profils administrateur Émission : création, modification, suppression de

profils et d’utilisateur

Réception : liste des profils utilisateurs.

III.2.2 – Diagramme de cas d’utilisation

1




Figure 19 : système futur - diagramme de cas

d’utilisation

1




Tableau 9 : système futur - mettre à jour une activité

Tableau 10 : système futur - consulter des informations

III.2.3 – Descriptions textuelles

Cas d’utilisation : Mettre à jour une activité

Nom Mettre à jour une activité

Acteurs principaux Responsable d’activité

Acteurs secondaires

Pré conditions Des activités ont été enregistrées


1 Le responsable d’activité ouvre une session en entrant son login et son mot de

passe

2 Le système vérifie l’authenticité du couple fourni

3 Le système recherche les activités auxquelles le responsable d’activité à droit

4 Le système présente les activités

5 Le responsable d’activité choisit l’activité qu’il veut renseigner

6 Le système présente le formulaire de l’activité choisie

7 Le responsable d’activité renseigne le formulaire

8 Le système vérifie la conformité du formulaire

9 Le système enregistre les données fournies par le formulaire

10 Le responsable d’activités ferme sa session


Point 2 : le couple fourni est

erroné

Le système redemande le login et le mot de passe

Point 2 : le nombre de

tentatives > 3

1 Le système empêche la connexion pendant une

heure

2 Fin

Point 8 : le formulaire n’est

pas conforme

1 Le système présente le formulaire rempli en

mettant en surbrillance les champs à corriger

Post conditions Des activités ont été mises à jour

Cas d’utilisation : Consulter des informations

Nom Consulter les informations

Acteurs principaux Internaute

Acteurs secondaires

Pré conditions Des informations sont disponibles


1 L’internaute clique sur un lien

2 Le système recherche les informations demandées

3 Le système présente les informations

4 L’internaute consulte les informations

Post conditions Des informations sont disponibles

1




Tableau 11 : système futur - valider un indicateur


Nom Valider un indicateur

Acteurs principaux Contrôleur

Acteurs secondaires

Pré conditions Des activités et des indicateurs ont été enregistrés


1 Le contrôleur ouvre une session en entrant son login et son mot de

passe


3 Le système recherche les indicateurs

4 Le système recherche les activités liées

5 Le système présente les couples indicateurs/activités

6 Le contrôleur choisit le couple indicateur/activité qu’il veut renseigner

7 Le système présente le formulaire du couple choisi

8 Le contrôleur renseigne le formulaire



11 Le contrôleur d’activités ferme sa session


Point 2 : le couple fourni

est erroné

Le système redemande le login et le mot de

passe


tentatives > 3

1 Le système empêche la connexion

pendant une heure

2 Fin

Point 9: le formulaire n’est

pas conforme

1 Le système présente le formulaire rempli

en mettant en surbrillance les champs à

corriger

Post conditions Des indicateurs ont été mis à jour

1




Tableau 12 : système futur - mettre à jour des informations

Cas d’utilisation : mettre à jour des informations

Nom Mettre à jour des informations

Acteurs principaux Chargé d’étude

Acteurs secondaires

Pré conditions Le système est disponible


1 L’administrateur ouvre une session en entrant son login et son mot de

passe


3 Le système recherche les informations auxquelles l’administrateur a

droit

4 Le système présente les informations

5 L’administrateur choisit les informations qu’il veut renseigner

6 Le système présente le formulaire des informations

7 L’administrateur renseigne le formulaire



10 L’administrateur ferme sa session



est erroné

Le système redemande le login et le mot de

passe


tentatives > 3

1 Le système empêche la connexion

pendant une heure

2 Fin

Point 8: le formulaire n’est

pas conforme

1 Le système présente le formulaire rempli

en mettant en surbrillance les champs à

corriger

Post conditions Des informations ont été mises à jour

1




Tableau 13 : système futur - gérer les profils

Cas d’utilisation : gérer les profils

Nom Gérer les profils

Acteurs principaux administrateur

Acteurs secondaires

Pré conditions Des utilisateurs ont été définis


1 L’administrateur ouvre une session en entrant son login et son mot de passe


3 Le système recherche les utilisateurs du système

4 Le système présente la liste des utilisateurs

5 L’administrateur choisit l’utilisateur à qui il veut attribuer ou retirer un profil

6 Le système présente le formulaire des profils

7 L’administrateur renseigne le formulaire



10 L’administrateur ferme sa session



est erroné

Le système redemande le login et le mot de passe


tentatives > 3

1 Le système empêche la connexion pendant une

heure

2 Fin

Point 8: le formulaire

n’est pas conforme

1 Le système présente le formulaire rempli en

mettant en surbrillance les champs à corriger

Post conditions Des utilisateurs ont reçu ou perdu des droits d’accès

III.3 – Analyse

III.3.1 – Développement du modèle statique

Suite aux différentes interviews réalisées au sein de la direction, et en nous basant sur

les cas d’utilisations définis plus haut, nous avons pu développer le modèle statique de

l’application. C'est-à-dire le diagramme de classe. Ce diagramme permet de décrire la

structure des entités manipulées par les utilisateurs. En conception, le diagramme de classe

représente la structure d’un code orienté objet ou à un niveau de détail plus important, les

modules du langage de développement.

Cependant, en raison du grand nombre d’entités dans notre diagramme de classes,

nous l’avons divisé en deux selon deux axes. Ainsi, nous avons

un diagramme de classe axé sur les projets

un diagramme de classes axé sur les activités

1




Figure 20 : système futur -


sur les activités

1




Figure 21 : système futur -


sur les projets

1




Figure 22 : système futur - consulter des informations

III.3.2 – Développement du modèle dynamique

Le développement du modèle dynamique constitue la deuxième activité de l’étape

d’analyse. Il s’agit d’une activité où sont élaborés les différents diagrammes dynamiques

proposés par le langage UML.

Parmi ces diagrammes, nous avons choisi d’en présenter deux :

les diagrammes d’activité qui permettront d'expliciter les traitements des différentes

fonctionnalités du cadre à réaliser (cas d’utilisation)

le diagramme d’état transition qui reprend le concept bien connu de machines à états

fini, et qui consiste à s’intéresser au cycle de vie d’une instance générique d’une classe

particulière au fil de ses interactions avec les autres classes.

II.3.2.1 – Diagramme d’activités

Les différents diagrammes d’activités sont fonctions des différents cas d’utilisation

puisqu’ils viennent expliciter ce qui a été écrit dans les descriptions textuelles.


1




Figure 23: système futur - mettre à jour une activité


1




Figure 24: système futur - valider un indicateur


1




Figure 25: système futur - mettre à jour des informations

Cas d’utilisation : mettre à jour les informations

1




Figure 26: système futur - gérer les profils

Cas d’utilisation : gérer les profils

1




Figure 27: système futur - activité

II.3.2.2 – Diagramme d’états-transition

Toutes les classes du modèle classique ne requièrent pas nécessairement une machine

à états, représentée par un diagramme d’états. Il s’agit donc de trouver celles qui ont un

comportement dynamique complexe et nécessitant une description avancée. Dans cet ordre

d’idée, nous avons opté pour la présentation du diagramme d’états transition de la classe «

activité » (figure 27) puisqu’elle est la plus intéressante du point de vue du comportement

dynamique.

1

66 Sécurisation du cadre



SECURISATION DU CADRE

A la suite de la conception du cadre, nous allons

maintenant établir sa sécurité.

Cette sécurité qui nécessite une méthode particulière

nous a amené à étudier la gestion des risques et plus

spécifiquement les différentes méthodes d’analyse de

risques en vue d’en choisir une.

Une fois le choix effectué nous avons procédé à son

application proprement dite.

1




IV – SECURISATION DU CADRE

IV.1 – Nécessité d’une sécurisation du système

d’information

Si nous devons élire l’inventeur de ces 20 dernières années, nous choisirons sans

aucun doute Tim-Berners LEE, ce physicien du Centre Européen de Recherche Nucléaire

(CERN) qui est aujourd’hui président du World Wide Web Consortium (W3C) puisqu’il est

considéré comme le père fondateur d’Internet. Le fruit de ses labeurs a connu de nos jours une

évolution majeure allant même à s’immiscer dans tous les secteurs d’activités. Les facilités

qu’il offre pour les transferts de fichiers, le courrier électronique, les listes de diffusion, les

forums entre autres ont permis un développement spectaculaire et fructueux des

communications, des échanges et du travail. Mais, parallèlement à la mutation extraordinaire

de nos méthodes de travail qu’a induit cette évolution, nous assistons à d’autres phénomènes

parasitaires inquiétants, notamment depuis l’ouverture d’Internet à des activités privées ou

commerciales, ce qui confirme la nécessité, pour les organismes qui veulent pouvoir

communiquer librement, stocker et traiter des données, de protéger leurs systèmes

d’information.

Effectivement, de nouvelles formes de malveillance ont récemment fait leur

apparition. Certaines de ces malveillances constituent des crimes ou des délits et peuvent

entraîner des poursuites judiciaires ; d’autres provoquent une entrave à la communication.

Plus inquiétante encore est l’apparition d’une délinquance organisée qui cherche à pénétrer les

systèmes pour s’approprier de l’information et la monnayer aux plus offrants. L’information,

même d’apparence anodine, constitue après compilation, recoupements et traitements, une

valeur marchande pour des groupes de mieux en mieux structurés. De ce point de vue, nous

avons dépassé l’époque du « vulgaire bricoleur solitaire » qui par jeu ou par défi, cherche à

pénétrer les systèmes les mieux protégés. Les pirates d’aujourd’hui opèrent en bande; ils

utilisent des procédés qu’ils récupèrent sur des sites spécialisés et ne sont guidés par aucune

éthique. Pour ces prédateurs d’un nouveau type, les laboratoires universitaires, les différentes

institutions étatiques constituent des cibles privilégiées.

De ce fait, la sécurité de notre cadre de gestion de projet s’avère assez cruciale

puisqu’elle doit préserver les ressources matérielles, logicielles et aussi les informations de

l’organisation de toutes utilisations illicites. Toutefois, la sécurité des systèmes d’information

est de plus en plus abordée, dans les entreprises, à l’aide d’approches basées sur les risques,

car l’expérience montre que de telles études prospectives réduisent de manière considérable

les pertes liées aux faiblesses de sécurité des systèmes d’information. Partant de ce constat,

une étude de la gestion des risques nous semble utile.

1




IV.2 – Présentation de la gestion des risques

Le concept de gestion des risques (ou risk management) a fait son apparition à la fin

des années 50 aux États-Unis dans le domaine financier, en relation avec des questions

d’assurance. Par la suite, la notion de gestion des risques a été étendue à d’autres domaines,

notamment l’environnement, la gestion de projet, le marketing, ainsi que la sécurité

informatique. Elle est définie par l’International Organization for Standardization (ISO),

comme l’ensemble des activités coordonnées visant à diriger et piloter un organisme vis-à-vis

du risque. Ainsi, trois finalités à la gestion des risques sont dégagées pour les systèmes

d’information :

améliorer la sécurisation des systèmes d’information ;

justifier le budget alloué à la sécurisation du système d’information ;

prouver la crédibilité du système d’information à l’aide des analyses effectuées.

Bien qu’un grand nombre ne soit plus utilisé ou confidentiel, les méthodes de gestion

des risques existantes sont dans l’ordre de 200 méthodes. Cette multiplicité entraîne une très

grande diversité dans les approches des risques de sécurité d’où une analyse de ses

fondements.

IV.2.1 – Les concepts de la gestion de risques

Au sens strict de la notion, la gestion des risques se compose de trois blocs

interdépendants. Nous distinguons l’organisation cible de l’étude, définie par ses assets et ses

besoins de sécurité, puis les risques pesant sur ces assets et enfin les mesures prises ayant pour

but de traiter les risques et donc d’assurer un certain niveau de sécurité.

Figure 28 : concepts de la gestion des risques

1




Nous pouvons définir les assets comme étant l’ensemble des biens, actifs, ressources

ayant de la valeur pour l’organisme et nécessaire à son bon fonctionnement. Nous distinguons

les assets du niveau business des assets liés au système d’information. Du côté des assets

business, nous retrouvons principalement des informations (par exemple des numéros de carte

bancaire) et des processus (comme la gestion des transactions ou l’administration des

comptes). De plus, les assets business de l’organisme sont bien souvent entièrement (ou

presque) gérés au travers du système d’information, ce qui entraîne une dépendance de ces

assets vis-à-vis de ce dernier. Ce sont les assets système. Nous retrouvons dans les assets

système les éléments techniques, tels les matériels, les logiciels et les réseaux, mais aussi

l’environnement du système informatique, comme les utilisateurs ou les bâtiments. Se basant

sur ces définitions, le but de la gestion des risques est donc d’assurer la sécurité des assets,

sécurité exprimée la plupart du temps en termes de:

confidentialité des données qui consiste à rendre l’information inintelligible aux

personnes autres que les seuls acteurs de la transaction ;

intégrité des données qui consiste à déterminer si les données n’ont pas été altérées

durant la communication (de manière fortuite ou intentionnelle) ;

disponibilité du système qui garantit l’accès à un service ou à des ressources ;

Ces assets à protéger sont soumis à des risques de sécurité. Le guide 73 de

l’International Organization for Standardization (ISO) définit un risque par la combinaison de

la probabilité d’un événement et de ses conséquences. Cette définition est généralement

étendue et un risque est couramment défini comme la combinaison d’une vulnérabilité, d’une

menace et d’un impact. Il est aussi illustré à l’aide de ce que l’on nomme «l’équation du

risque»

RISQUE = MENACE * VULNÉRABILITÉ * IMPACT

Cette équation est celle qui est la plus fréquemment utilisée et la plus reconnue dans le

domaine de la gestion des risques. Elle joue un rôle fondamental dans l’identification et

l’évaluation du risque.

Cependant, pour bien comprendre la notion de risque, il est important d’examiner

chacune de ses composantes :

La menace qui est la cause potentielle d’un incident mettant en danger les assets. Elle est

souvent assimilée à l’agresseur.

La vulnérabilité qui est la caractéristique d’un asset constituant une faiblesse ou une faille au

regard de la sécurité.

L’impact représente la conséquence du risque sur l’organisme et ses objectifs.

1




Afin de mitiger ces risques et de protéger les assets, une politique de traitement des

risques est mise en place. Elle sera constituée d’exigences de sécurité permettant de répondre

aux risques. Ces exigences de sécurité vont ensuite entraîner la mise en place de contrôles (ou

contre-mesures) de sécurité à implémenter, afin de satisfaire aux exigences.

Les contrôles sont de deux types :

sur la menace ou la vulnérabilité, afin de limiter la cause du risque ;

sur l’impact, afin de limiter la conséquence du risque.

IV.2.2 – Le processus de gestion des risques

Après avoir mis en évidence les concepts intervenant dans la gestion des risques, nous

pouvons maintenant identifier le processus de gestion des risques. Ce processus est presque

toujours appliqué dans les méthodes pratiques de gestion des risques.

Figure 29 : exemple d’un risque

1




Au vu de la figure ci-dessus représentant la démarche de gestion des risques, nous

notons les étapes suivantes :

l’identification du domaine et des assets qui est l’étape où il est question de prendre

connaissance de l’organisation, son environnement, son système d’information et de

déterminer précisément les limites du système sur lequel va porter l’étude de gestion

des risques. Une fois notre système borné, nous procédons en premier lieu à

l’identification des assets business constituant la valeur de l’organisation. Ensuite, le

Figure 30 : le processus de gestion de risques

Identification

du contexte et

des assets

Implémentation

des contrôles

Sélection des

contrôles

Détermination

des objectifs de

sécurité

Analyse des

risques

Définition des

exigences de

sécurité

1




lien sera fait entre ces assets business et les assets systèmes, sur lesquels nous

identifierons et corrigerons les risques d’un point de vue technique et organisationnel.

La détermination des objectifs de sécurité vise à spécifier les besoins en termes de

confidentialité, intégrité, disponibilité, non-répudiation et authentification des assets,

en particulier au niveau business. Le lien entre les assets business et les assets système

étant en amont, nous retrouvons donc les besoins en sécurité au niveau du système

L’analyse des risques constitue le cœur de la démarche de gestion des risques. Elle a

pour finalité l’identification et l’estimation de chaque composant du risque

(menace/vulnérabilité/impact), afin d’évaluer le risque et d’apprécier son niveau, dans

le but de prendre des mesures adéquates (parfois cette étape est appelée appréciation

du risque). Nous notons deux grandes écoles pour l’identification des risques : soit en

réalisant un audit du système et de ses différents acteurs, soit à partir de bases de

connaissances prédéfinies. Pour l’estimation des risques, il est possible en théorie de

les quantifier à l’aide de distributions de probabilités sur les menaces et les

vulnérabilités, ainsi qu’en estimant les coûts occasionnés par les impacts. En pratique

il se révèle difficile de donner des valeurs absolues et l’on se contente bien souvent

d’une échelle de valeurs relatives. Cette estimation permet de faire un choix,

représenté sur la figure 31, dans le traitement du risque.

Figure 31: les différentes zones de risques

1




D’une manière générale, l’on considère que :

Les risques ayant une occurrence et un impact faible sont négligeables.

Les risques ayant une forte occurrence et un impact important ne doivent pas

exister, autrement une remise en cause des activités de l’entreprise est nécessaire

(on évite le risque, avoidance en anglais).

Les risques ayant une occurrence forte et un impact faible sont acceptés, leur coût

est généralement inclus dans les coûts opérationnels de l’organisation (acceptation

du risque).

Les risques ayant une occurrence faible et un impact lourd sont à transférer. Ils

peuvent être couverts par une assurance ou un tiers (transfert du risque).

Enfin, les autres risques, en général majoritaires, sont traités au cas par cas et sont

au centre du processus de gestion des risques ; l’objectif étant de diminuer les

risques en les rapprochant au maximum de l’origine de l’axe (mitigation du risque

à l’aide de contrôles).

La définition des exigences de sécurité permet de réduire les risques identifiés. En

fonction des méthodes, cette étape pourra être effectuée avec l’assistance de

référentiels, ou aiguillée par la connaissance d’experts système/sécurité. La définition

des exigences de sécurité, au vu de son importance et sa complexité, est souvent

effectuée de manière incrémentale et par raffinements successifs. En effet, il est

conseillé bien souvent de débuter par des exigences générales, qui définiront

l’intention de contrer les risques identifiés (de niveau stratégique), pour les raffiner

ensuite en des exigences plus précises (vers le niveau opérationnel). Toutefois, les

exigences sont censées être génériques et applicables à tout système d’information. Il

faut également rappeler que ces exigences de mitigation des risques porteront à la fois

sur le système informatique (comme le besoin de chiffrement des mots de passe), mais

aussi sur son environnement (par exemple, « l’utilisateur du système ne doit pas

dévoiler son mot de passe à un tiers »).

La sélection des contrôles est le dernier niveau de raffinement. Les contrôles sont

l’instanciation des exigences de bas niveau pour le système cible étudié. Dans cette

étape, nous définissons les choix techniques des solutions de sécurité influencés par le

système déjà en place, les compétences disponibles, les coûts de mise en œuvre.

L’implémentation des contrôles qui permet d’implémenter les contrôles dans le

système d’information et éventuellement de les tester et les évaluer.

1




Bien que les concepts et le processus de gestion des risques soient définis, la notion de

risque reste un concept difficile à appréhender d’où l’existence de plusieurs méthodes

d’analyse des risques pour faciliter la mise en pratique d’une gestion de risque. En outre,

relativement à la complexité des organisations actuelles associées aux enjeux économiques, il

est judicieux de ne pas s’en remettre exclusivement à des subjectivités, mais plutôt à utiliser

des méthodes d’analyse des risques qui sont formelles et ont été éprouvées.

IV.3 – Les méthodes d’analyses de risques

Présentement, nous pouvons dénombrer plus de 200 méthodes d’analyses des risques

qui sont déclinées à travers le monde. Ces dernières sont plus ou moins finalisées, plus ou

moins faciles d’accès ou tout simplement inconnues. Nonobstant l’existence de toutes ces

méthodes, 3 d’entre elles sont très utilisées et prisées des entreprises. Nous pouvons citer :

l’Expression des Besoins et Identification des Objectifs de Sécurité (EBIOS),

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE),

la Méthode Harmonisée d’Analyse de Risques (MEHARI).

IV.3.1 – EBIOS (Expression des Besoins et Identification

des Objectifs de Sécurité)

Il s’agit d’une méthode développée et maintenue par la Direction Centrale de la

Sécurité des Systèmes d’Information (DCSSI). Cette méthode, créée en 1995, se compose de

cinq guides (Introduction, Démarche, Techniques, Outillages pour l’appréciation des risques

et Outillages pour le traitement des risques) et d’un logiciel support dont la diffusion est

gratuite. La méthode a pour objectif la formalisation d’objectifs de sécurité adaptés aux

besoins du système audité (et de son contexte).

1




Par ailleurs, cette méthode avant tout destinée à l’administration française et aux

entreprises est découpée en 5 étapes comme le montre la figure 32. Nous avons :

L’étude du contexte qui permet d'identifier quel système d'information est la cible de

l'étude. Cette étape délimite le périmètre de l'étude : présentation de l'entreprise,

architecture du système d'information, contraintes techniques et réglementaires, enjeux

commerciaux. Mais est aussi étudié le détail des équipements, des logiciels et de

l'organisation humaine de l'entreprise.

L’expression des besoins de sécurité qui permet d'estimer les risques et de définir les

critères de risque. Les utilisateurs du système d’information expriment durant cette

étape leurs besoins de sécurité en fonction des impacts qu'ils jugent inacceptables.

L'étude des menaces qui permet d'identifier les risques en fonction non plus des

besoins des utilisateurs mais en fonction de l'architecture technique du système

d'information. Ainsi, la liste des vulnérabilités et des types d'attaques est dressée en

fonction des matériels, de l'architecture réseau et des logiciels employés. Et ce, quelles

que soient leur origine (humaine, matérielle, environnementale) et leur cause

(accidentelle, délibérée).

Figure 32: démarche globale d’EBIOS

Étude du

contexte

Expression des

besoins de

sécurité

Étude des

menaces

Identification des

objectifs de

sécurité

Détermination

des exigences de

sécurité

1




L'identification des objectifs de sécurité qui permet de confronter les besoins de

sécurité exprimés et les menaces identifiées afin de mettre en évidence les risques

contre lesquels le SI doit être protégé. Ces objectifs vont former un cahier des charges

de sécurité qui traduira le choix fait sur le niveau de résistance aux menaces en

fonction des exigences de sécurité.

La détermination des exigences de sécurité qui permet de déterminer jusqu'où on

devra aller dans les exigences de sécurité. Il est évident qu'une entreprise ne peut faire

face à tout type de risques, certains doivent être acceptés afin que le coût de la

protection ne soit pas exorbitant. C'est notamment la stratégie de gestion du risque tel

que cela est défini dans un plan de risque qui sera déterminé ici : accepter, réduire ou

refuser un risque. Cette stratégie est décidée en fonction du coût des conséquences du

risque et de sa probabilité de survenue. La justification argumentée de ces exigences

donne l'assurance d'une juste évaluation.

IV.3.2 – OCTAVE (Operationally Critical Threat, Asset,

and Vulnerability Evaluation)

Cette méthode d’évaluation du risque créée en 1999 a été publiée par le Software

Engineering Institute (SEI) de la Carnegie Mellon University, reconnue dans le domaine de la

sécurité des systèmes d’information (fédération des Computer Emergency & Reponse Team –

CERTS). Les fondements mêmes de cette méthode reposent sur la possibilité de réaliser une

analyse des risques de l’intérieur de l’organisation, exclusivement avec des ressources

internes en se basant sur un catalogue de bonne pratique de sécurité fourni avec la méthode.

Pleinement orientée vers les grandes entreprises, une version OCTAVE-S (Small) peut,

cependant, facilement se décliner au sein d’une petite structure économique.

OCTAVE est une méthode d’évaluation des vulnérabilités et des menaces sur les actifs

opérationnels. Une fois ces derniers identifiés, la méthode permet de mesurer les menaces et

les vulnérabilités pesant sur eux.

Les trois phases suivantes déclinées au cœur d’OCTAVE, respectent l’analyse progressive des

trois blocs des concepts de gestion des risques présentés en amont :

La phase 1 (vue organisationnelle) permet d'identifier les actifs de l'entreprise, les

menaces qui pèsent sur son fonctionnement, les vulnérabilités de son organisation, les

objectifs de sécurité imposés par la direction et les mesures actuelles de sécurité. Ce

sont trois processus de collecte de l'information qui sont réalisés durant cette phase,

chacun par une population particulière : les cadres supérieurs, les cadres opérationnels

et les équipes de production. La consolidation des informations nées de ces processus

amène à créer des profils de menaces.

La phase 2 (vue technique) permet d’identifier les éléments essentiels des actifs et les

audite afin d’en connaitre les vulnérabilités.

1




Actifs

Menaces

Vulnérabilités

Objectifs de sécurité

Risques

Stratégie de protection

Plan de réduction

Vulnérabilités

Préparation

Phase 1

Vue Organisationnelle

Phase 3

Développement de la

stratégie de sécurité

Phase 2

Vue Technique

La phase 3 de la méthode décline le développement de la stratégie de sécurité qui

consiste à évaluer les risques identifiés (impact, probabilité) plus haut et à proposer les

mesures permettant de les réduire. Un plan de réduction des risques est alors planifié.

IV.3.3 – MEHARI (Méthode harmonisée d’Analyse des

Risques)

MEHARI (Méthode Harmonisée d'Analyse de Risques) est développée par le CLUSIF

depuis 1995, elle est dérivée des méthodes Melissa et Marion. Existant en langue française et

en anglais, elle est utilisée par de nombreuses entreprises publiques ainsi que par le secteur

privé. Elle possède aussi un outil de gestion des risques développé par la société BUC SA

nommée RISICARE.

La démarche générale de MEHARI consiste en l'analyse des enjeux de sécurité : quels

sont les scénarios redoutés ?, et en la classification préalable des entités du système

d’information en fonction de trois critères de sécurité de base (confidentialité, intégrité,

disponibilité). Ces enjeux expriment les dysfonctionnements ayant un impact direct sur

l'activité de l'entreprise. Puis, des audits identifient les vulnérabilités du SI. Et enfin, l'analyse

des risques proprement dite est réalisée.

Figure 33: les principales phases d’OCTAVE

http://www.risicare.fr/

1




Par ailleurs, la démarche MEHARI s'articule autour de 3 types de livrables dénommés

plans. Nous avons :

Le Plan Stratégique de Sécurité (PSS) fixe les objectifs de sécurité ainsi que les

métriques permettant de les mesurer. C'est à ce stade que le niveau de gravité des

risques encourus par l'entreprise est évalué. Il définit la politique de sécurité ainsi que

la charte d'utilisation du système d’information pour ses utilisateurs.

Les Plans Opérationnels de Sécurité (POS) définissent pour chaque site les mesures

de sécurité qui doivent être mises en œuvre. Pour cela, ils élaborent des scénarios de

compromission et audite les services du SI. Sur la base de cet audit, une évaluation de

chaque risque (probabilité, impact) est réalisée permettant par la suite d'exprimer les

besoins de sécurité, et par la même les mesures de protection nécessaires. Enfin, une

planification de la mise à niveau de la sécurité du SI est faite.

Le Plan Opérationnel d'Entreprise (POE) assure le suivi de la sécurité par

l'élaboration d'indicateurs sur les risques identifiés et le choix des scénarios de

catastrophe contre lesquels il faut se prémunir.

Figure 34 : la démarche globale de MEHARI

1




IV.3.3 – Choix d’une méthode d’analyse de risques

À l’issue de la présentation des prédominantes méthodes d’analyse, nous remarquons

que ces différentes méthodes ne sont pas opposées, mais plutôt complémentaires (annexe 2).

Cependant dans le cadre de notre projet nous ferons un choix afin de pouvoir faire

ressortir les besoins de sécurité de notre application, quitte à nous d’améliorer

continuellement cette sécurité en appliquant les autres référentiels de sécurité. Toutefois, ce

choix ne peut se faire qu’en se basant sur une étude comparée résumée dans le tableau ci-

dessous.

1




Tableau 14 : comparaison des méthodes d’analyses de risques

Méthodes Origine Outils

logiciels

Existence

d’un club

Qualité de la

documentation

Facilité

d’utilisation et le

pragmatisme de la

méthode

Comptabilité

avec une

norme

nationale ou

international

e

Taille de

l’entreprise

Support de la

méthode par

son auteur

popularit

é

Quantité de

moyens

humains

EBIOS France

(DCSSI -

gouvernem

ent)

Logiciel

gratuit

communauté

d’experts

crée en 2003

5 guides sont

fournis et

existence d’un

centre de

formation

Facile

d’utilisation et

très adaptable

selon les besoins,

utilisation

améliorée par

l’outil logiciel

Compatible

avec les

normes

l'ISO/IEC

15408,

l'ISO/IEC

17799

Toutes les

entreprises et

originellement

conçue pour les

organismes

d’états

Soutenue par

le

gouverneme

nt

*** La méthode a

été conçue

pour être

utilisée par un

analyste ou

une équipe.

MEHARI France

(CLUSIF –

association

)

Logiciel

RISICA

RE

payant

CLUSIF

(Club de la

Sécurité des

Systèmes

d’Informatio

n Français)

3 guides

d’utilisation,

des manuels

de référence

sont

disponibles

Cadre

méthodologique

assez facile

d’utilisation, et

améliorée par des

bases de

connaissances et

des outils

Compatibles

avec les

normes ISO

13335 et

ISO 27001

Grandes

entreprises et

organismes

Développée

et maintenue

par le

CLUSIF

*** Nécessite la

mise en place

d’un

management

de risques

OCTAVE Etats-Unis

(Université

de

Carnegie

Melon)

Logiciel

payant

non Un catalogue

de bonnes

pratiques est

fourni et

l’ensemble des

activités à

mener est très

détaillée

En considérant sa

déclinaison pour

les petites

entreprises,

OCTAVE est très

accessible

aucune Premièrement

orientée vers les

grandes

entreprises mais

une déclinaison

OCTAVE-S a été

élaborée pour les

petites

entreprises.

Maintenue

par le SEI de

l’université

** Une petite

équipe

composée de

membres de

l’équipe

opérationnell

e et du

département

informatique

1




Forts de cette comparaison, nous avons jeté notre dévolu sur la méthode EBIOS

puisqu’elle offre d’une part un logiciel d’assistance facile d’utilisation et gratuit. D’autre part,

elle est la production d’un organisme gouvernemental où la sécurité est une affaire de tous les

instants et qui sied donc à ce type d’entité par corollaire. En plus, cette méthode a pour

vocation la protection de l’organisation en entier et non des actifs de l’organisation.

IV.4 – Mesures de sécurité

À la suite d’une étude basée sur la méthode EBIOS et réalisée à l’aide de leur outil

d’assistance, nous sommes arrivés à déterminer les actions de sécurité qu’il convient

d’entreprendre. Ainsi, les résultats de cette étude recommandent pour la sécurisation d’une

application web d’adopter une approche globale (figure 35) et d’appliquer la sécurité au

niveau :

du réseau,

de l’hôte (serveur web, serveur de base de données, serveur d’applications),

de l’application.

Figure 35 : approche globale de la sécurité

1




IV.4.1 – Sécurisation du réseau

IV.4.1.1 – Présentation

Le réseau est le point d'entrée de notre application. C'est à ce niveau que se situent les

premiers gardes-barrières qui contrôlent l'accès aux différents serveurs dans notre

environnement. Les serveurs sont protégés par les gardes-barrières de leur propre système

d'exploitation, mais il est important de les préserver d'attaques provenant de la couche réseau.

Il est tout aussi important de nous assurer que les gardes-barrières du réseau ne peuvent pas

être remplacés ou reconfigurés par des imposteurs. En un mot, la sécurité du réseau consiste à

protéger les périphériques du réseau et les données qu'ils transmettent (annexe 3).

Les principaux composants d'un réseau qui font office de gardes-barrières de premier

niveau sont le routeur, le pare-feu et le commutateur.

IV.4.1.2 – Menaces et contre-mesures

Ce sont les périphériques de réseau mal configurés qui sont les cibles privilégiées des

attaques. Les problèmes de vulnérabilité sont généralement dus au manque de sécurité des

paramètres d'installation par défaut, aux négligences dans les contrôles d'accès et à la non-

application de correctifs sur les services. Le tableau ci-dessous récapitule les menaces

majeures d’un réseau et les contre mesures adéquates.

Figure 36 : Composants réseau : routeur – pare-feu - commutateur

1




Menaces Définitions Vulnérabilités Attaques Contre-mesures

Collecte d’informations La collecte d’informations peut révéler

des informations détaillées sur la

topologie du réseau, la configuration

système et les périphériques du réseau.

Un agresseur utilise ces informations

pour lancer des attaques ciblées sur les

zones de vulnérabilité ainsi mises en

évidence

caractère peu sécurisé de la

suite de protocoles TCP/IP

informations de configuration

fournies par les bannières

services accessibles qui

devraient être appliquées

utilisation de Tracert pour

détecter la topologie du

réseau

utilisation de Telnet afin

d’ouvrir des ports pour

l’accrochage des bannières

analyse des ports pour la

détection de ports ouverts

utilisation de demandes de

diffusion pour énumérer

les hôtes d’un sous-réseau

utilisation de bannères de

services génériques qui ne

fournissent pas

d’informations de

configuration telles que les

versions ou les noms de

logiciels

utilisation de pare-feu pour

masquer les services qui ne

doivent pas être

accessibles au public

Espionnage L’espionnage également appelé écoute

clandestine consiste à surveiller le

trafic du réseau afin d’obtenir des

données telles que des mots de passe

non sécurisés ou des informations de

configuration. Il suffit d’un

intercepteur de paquets pour lire

aisément le trafic en clair. Ce dispositif

permet également de pirater des

algorithmes de hachage simples et de

déchiffrer une charge utile considérée

comme sécurisée.

sécurité physique insuffisante

absence de cryptage lors de

l’envoi des données

sensibles

communication entre services

effectuée en clair, en

recourant à un dispositif de

cryptage insuffisant ou au

hachage

mise en place d’outils

d’espionnage de paquets

sur le réseau afin

d’enregistrer l’ensemble

du trafic

renforcement de la sécurité

physique pour éviter

l’intrusion de

périphériques malveillants

sur le réseau.

cryptage des informations

d’authentification et du

trafic applicatif circulant

sur le réseau.

1




Usurpation L'usurpation d'identité, également

appelée dissimulation d'identité, offre

un moyen de masquer son identité

réelle sur le réseau. Elle consiste à

utiliser une fausse adresse source qui

ne correspond pas à l'adresse réelle de

l'émetteur du paquet. L'usurpation peut

servir à masquer la source d'une

attaque ou à contourner les listes de

contrôle d'accès (ACL) mises en place

pour limiter les accès hôtes en fonction

des règles définies sur les adresses

sources.



absence de filtrage entrant et

sortant. Le filtrage entrant

consiste à détecter les

paquets IP dotés d'adresses

source non approuvées

avant qu'ils ne puissent

s'introduire dans notre

système ou dans notre

réseau et les endommager.

Le filtrage sortant porte sur

le trafic issu du réseau.

utilisation de plusieurs outils

pour modifier les paquets

sortants afin qu’ils

semblent issus d’un autre

réseau ou d’un autre hôte

utilisation du filtrage entrant

et sortant sur les routeurs

de périmètre.

Détournement de session Avec le détournement de session,

également désigné sous le terme

d'attaque d'intrus, le pirate utilise une

application qui endosse l'identité du

client ou du serveur. Ceci conduit ce

dernier à considérer à tort l'hôte situé

en amont comme l'hôte légitime. En

réalité, l'hôte situé en amont est l'hôte

d'un pirate qui manipule le réseau afin

d'en faire la destination souhaitée. Le

détournement de session peut être

utilisé pour obtenir des informations de

connexion exploitables pour accéder à

une application ou à des données

confidentielles.

sécurité physique insuffisante



communication non cryptée

utilisation de plusieurs outils

associant des fonctions

d’espionnage, de

modification, de routage et

de manipulation de paquets

cryptage de session

inspection dynamique du

pare-feu

1




Tableau 15 : menaces et contre-mesures d’un réseau

Refus de service Une attaque de refus de service

consiste à empêcher les utilisateurs

légitimes d'accéder à un serveur ou à

des services. Les attaques de refus de

service sur la couche réseau procèdent

généralement par saturation du réseau,

ce qui consomme la bande passante et

les ressources disponibles.



configuration de routeurs et

de commutateurs peu

sécurisée

communication non cryptée

bogues des logiciels de

services

attaque en force brute par

l’envoi de flux de paquets

tel que du trafic à diffusion

générale en cascade

saturation SYN

attaque de services, telles que

les dépassements de

capacités de la mémoire

tampon

filtrage des demandes de

diffusion générale

filtrage des requêtes ICMP

(Internet Control Message

Protocol)

application de correctifs et de

mises à jour sur les

logiciels de service

1




IV.4.2 – Sécurisation du serveur web


La possibilité pour l'attaquant de porter un coup à distance fait du serveur Web une

cible tentante à bien des égards. Comprendre les menaces du serveur web et être capable

d'identifier les contre-mesures appropriées nous permet d'anticiper de nombreuses attaques et

de contrecarrer le nombre sans cesse croissant d'attaquants.

Les principales menaces du serveur Web sont les suivantes :

Profil

Refus de service

Accès non autorisé

Exécution arbitraire du code

Élévation des privilèges

Virus, vers et chevaux de Troie

La figure 37 résume les attaques les plus communes ainsi que les vulnérabilités courantes.


Figure 37 : Menaces du serveur web prédominantes et vulnérabilités

courantes

1




Menaces Description Vulnérabilités Attaques Contre-mesures

Profilage Le profilage, ou énumération de sessions

est un processus d’exploration utilisé

pour collecter des informations sur un

site web. L’attaquant utilise ces

informations pour attaquer les points

faibles connus.

protocoles inutiles

ports ouverts

serveur web fournissant des

informations de

configuration dans les

bannières

l’analyse des ports

les balayages de Ping

l’énumération NetBIOS et

bloc de message serveur

(SMB)

bloquer tous les ports inutiles,

arrêter le trafic ICMP

désactiver les protocoles

inutiles tels que NetBIOS et

SMB

Refus de service Les attaques par refus de service

surviennent lorsque notre serveur est

saturé par les requêtes de service. La

menace réside dans le fait que notre

serveur peut être trop submergé pour

répondre aux requêtes de clients

légitimes.

configuration faible des la pile

TCP/IP

serveurs non mis à jour

saturations SYN au niveau du

réseau

dépassement de capacité de la

mémoire tampon

saturation du serveur web

avec des requêtes issues

d’emplacements distribués

renforcement de la pile

TCP/IP

application cohérentes des

derniers correctifs logiciels

et mises à jour sur le

logiciel système

Accès non autorisé On parle d'accès non autorisé lorsqu'un

utilisateur sans autorisation parvient à

accéder aux informations protégées ou

effectue une opération restreinte.

faibles contrôles d’accès au

serveur web, autorisations

web comprises

autorisations faibles

utilisation des autorisations

web sécurisées

utilisation des mécanismes de

contrôles d’accès

Exécution arbitraire

du code

Les attaques par exécution de code se

produisent lorsqu'un attaquant exécute un

code nuisible sur notre serveur pour en

compromettre les ressources ou pour

lancer d'autres attaques contre les

systèmes en aval.

faible configuration du

serveur web

serveurs non mis à jour

pénétration des répertoires

dépassements de capacités de

la mémoire tampon menant

à l’injection de code

utilisation configuration du

serveur web pour rejeter les

URL contenant «../ » afin

d’éviter la pénétration des

répertoires

verrouillages des commandes

systèmes et des utilitaires

avec des listes de contrôles

d’accès restrictifs (ACL)

installation des nouveaux

correctifs et mises à jour

1




Tableau 16 : menaces et contre-mesures d’un serveur web

Élévation des

privilèges

On parle d'attaque par élévation des

privilèges lorsqu'un attaquant exécute le

code en utilisant un compte de processus

privilégié

comptes de processus sur-

privilégiés

compte de services sur-

privilégiés

exécuter les processus au

moyen du compte le moins

privilégié

utiliser des comptes

utilisateurs et des services

les moins privilégiés

possible

Virus, vers et

chevaux de Troie

Le code nuisible peut revêtir diverses

formes, parmi lesquelles :

Les virus. Il s'agit des programmes

conçus pour exécuter des actions

nuisibles et provoquer l'interruption

du système d'exploitation ou des

applications.

Les vers. Ce sont des programmes qui

s'auto-répliquent et s'auto-

entretiennent.

Les chevaux de Troie. Il s'agit de

programmes qui semblent utiles,

mais qui causent des dommages.

Dans la plupart des cas, le code nuisible

passe inaperçu jusqu'à ce qu'il consomme

les ressources du système et ralentisse ou

interrompe l'exécution des autres

programmes.

serveur non mis à jour

exécution de services inutiles

filtres ISAPI et extensions

inutiles

application des derniers

correctifs logiciels

désactivation des

fonctionnalités non utilisées

telles que les filtres ISAPI

et extensions inutiles

exécution des processus à

l’aide de compte peu

privilégié pour réduire

l’étendue des dommages en

cas d’infection

1




IV.4.3 – Sécurisation du serveur d’applications


Du fait que les serveurs d'applications sont censés être isolés de tout accès via Internet,

nombre des dangers qui les menacent proviennent de l'intérieur de l'entreprise. Les principales

menaces pour le serveur d'applications sont les suivantes :

Écoute clandestine du réseau

Accès non autorisé

Virus, chevaux de Troie et vers

La figure 38 illustre les principaux dangers pour un serveur d'applications.


Figure 38 : Principales menaces et vulnérabilités d’un serveur d’applications

1




Menaces Descriptions Vulnérabilités Attaques Contre-mesures

Ecoute clandestine du

réseau

Les personnes malveillantes équipées de

logiciels de surveillance du réseau

peuvent intercepter les données circulant

entre le serveur Web et le serveur

d'applications, ainsi que celles qui

transitent entre le serveur d'applications

et les systèmes en aval ou les serveurs de

base de données. la personne

malveillante peut visualiser ces données

et être en mesure de les modifier.

données sensibles transmises

sous forme de texte clair

par l’application

absence de cryptage sur la

couche transport ou

application

interface d’administration du

matériel réseau non

sécurisée

mise en place d’outils

d’interception de

paquets sur le réseau

afin de capturer le

trafic

utiliser une authentification

sécurisée

crypter les informations

d’authentification du serveur

web

sécuriser les canaux de

communications (SSL ou IPSec)

utiliser un réseau segmenté, qui

permet d'isoler les segments

susceptibles de subir des écoutes.

Accès non autorisé Si nous ne parvenons pas à bloquer les

ports utilisés par les applications qui

s'exécutent sur le serveur d'applications

au niveau du pare-feu du périmètre, une

personne malveillante externe peut

communiquer directement avec le

serveur d'applications. Si nous autorisons

des ordinateurs autres que les serveurs

Web frontaux à se connecter au serveur

d'applications, le profil d'attaque du

serveur d'applications augmente.

faiblesse dans la configuration

du réseau de périmètre et

du pare-feu

ports superflus ouverts sur le

pare-feu interne

absence de stratégie IPSec

pour limiter la connectivité

aux hôtes

services actifs inutiles

protocoles inutiles

faiblesse des stratégies de

comptes et de mots de

passe

l’analyse de ports pour

détecter les services à

l’écoute

l’accrochage de

bannières, qui diffuse

les services

disponibles et

éventuellement les

versions de logiciels

l’introduction

d’applications

malveillantes

les attaques par mots de

passe contre les

comptes par défaut

dotés de mots de

passe trop simples

application sur les pare-feu de

stratégies visant à bloquer tout le

trafic, sauf sur les ports de

communications attendus

stratégie de filtrage TCP/IP ou

IPSec pour empêcher les hôtes

non autorisés d’établir des

connexions

Désactivation des services inutiles

1




Tableau 17 : menaces et contre-mesures d’un serveur d’applications

Virus, vers et

chevaux de Troie

Ces attaques sont généralement

remarquées que lorsqu’elles commencent

à consommer les ressources systèmes, ce

qui ralentit ou arrête l’exécution d’autres

applications.

serveurs sans correctifs

exécutions de services inutiles

filtres et extensions ISAPI

inutiles

application rapide des derniers

correctifs

désactivation des fonctionnalités

inutilisées, telles que les filtres et

extensions ISAPI inemployés

exécution des processus avec les

comptes moins privilégiées pour

limiter l’ampleur des dommages

si le système est compromis

1




IV.4.4 – Sécurisation du serveur de base de données


Un attaquant dispose de différents moyens pour cibler et compromettre un serveur de

base de données en exploitant les diverses vulnérabilités au niveau des applications et de la

configuration.

Les principales menaces du serveur de base de données sont les suivantes :

Injection SQL

Écoute clandestine du réseau

Accès non autorisé au serveur

Piratage de mot de passe

La figure 39 illustre les principales menaces et vulnérabilités pouvant conduire à l'infection

d'un serveur de base de données et à la possibilité de détruire ou de dérober les données

sensibles.

IV.4.4.2 – Mesures et contre-mesures

Figure 39 : Principales menaces et vulnérabilités d’un serveur de base de

données

1




Menaces Description Vulnérabilités Attaques Contre-mesure

Injection SQL Dans le cas d'une attaque par injection SQL,

l'attaquant exploite les vulnérabilités de

validation des entrées dans notre application

et du code d'accès aux données. Il peut ainsi

exécuter arbitrairement des commandes dans

la base de données dans le contexte de

sécurité de l'application Web.

la faiblesse de la

validation des entrées

dans nos applications

web

des commandes SQL

non sécurisées,

construites de manière

dynamique

l’utilisation de

connexions sur-

privilégiées à la base

de données

des autorisations faibles

qui ne parviennent pas

à limiter la connexion

de l’application à la

base de données

l’application doit limiter et assainir les

données saisies avant des les utiliser

dans des requêtes SQL

utilisation de paramètres sécurisés SQL

pour accéder aux données. Ces

paramètres peuvent être utilisés dans

des procédures stockées ou dans des

chaines de commandes SQL

construites de manière dynamique.

utilisation d’un nom de connexion au

serveur de base de données qui

restreint les autorisations dans la base

de données. Idéalement, nous ne

devons accorder d’autorisations

d’exécution qu’à certaines procédures

stockées sélectionnées dans la base de

données et ne pas fournir d’accès

direct à la table

Écoute

clandestine du

réseau

L'architecture de déploiement de la plupart

des applications comprend une séparation

physique entre le code d'accès aux données

et le serveur de base de données. Les

données sensibles, telles que les données

spécifiques d'une application ou les

autorisations de connexion à la base de

données, doivent par conséquent être

protégées contre les écoutes clandestines de

réseau.

des canaux de

communication non

sécurisés

des transmissions

d’autorisations en

texte clair à la base de

données.

utilisation de l’authentification du

système pour se connecter au serveur

de base de données et éviter d’envoyer

des informations d’identification sur le

réseau

installation d’un certificat de serveur sur

le serveur de base de données. Ce

certificat permet d’obtenir un cryptage

automatique des informations

d’identification SQL sur le réseau

utilisation d’une connexion SSL entra le

1




Tableau 18 : menaces et contre-mesures d’un serveur de base de données

serveur web et le serveur de base de

données pour protéger les données

sensibles des applications. Ce type de

connexion nécessite un certificat de

serveur de base de données

utilisation d’un canal crypté IPSec entre

le serveur web et le serveur de bases

de données

Accès non

autorisé au

serveur

L'accès direct à notre serveur de base de

données doit être limité à certains

ordinateurs clients spécifiques pour

empêcher les accès non autorisés au serveur.

impossibilité de bloquer

le port du serveur de

base de données au

niveau du pare-feu de

périmètre

absence de stratégie de

filtrage TCP/IP ou

IPSec

il existe des outils tels que

l’analyseur de requêtes

qui permettent d’établir

une connexion directe

avec le serveur de base

de données et d’envoyer

des commandes

les informations du serveur

telles que la version des

logiciels sont révélées à

l’attaquant qui envoie

des paquets construits

avec soin pour écouter

les ports

veiller à ce que les ports du serveur de

base de données ne soient visibles en

dehors du périmètre du réseau

au sein de ce périmètre, limiter l’accès

direct des hôtes non autorisés en

utilisant par exemples des filtres IPSec

ou TCP/IP

Piratage de mot

de passe

L'une des attaques type consiste à essayer de

découvrir les mots de passe des noms de

compte bien connus.

mots de passe vierge ou

faibles

mots de passe contenant

des mots usuels

les attaques par

dictionnaire

la recherche manuelle de

mot de passe

pour les comptes de connexion au

serveur de base de données, créer des

mots de passe répondant à des critères

de complexités

éviter les mots de passe contenant des

mots courants, figurant dans le

dictionnaire

1




IV.4.5 – Sécurisation de l’application web


Les concepteurs et développeurs des applications web doivent faire face à un grand

nombre de difficultés. La nature sans état de HTTP signifie que le suivi de session par

utilisateur relève désormais de la responsabilité de l'application. Au préalable, l'application

doit être capable d'identifier l'utilisateur en faisant appel à une forme ou une autre

d'authentification. Sachant que toutes les décisions d'autorisation ultérieures sont basées sur

l'identité de l'utilisateur, il est essentiel que le processus d'authentification soit sécurisé et que

le mécanisme de gestion de session utilisé pour suivre les utilisateurs authentifiés bénéficie du

même niveau de protection. La conception de mécanismes d'authentification et de gestion de

session ne constitue qu'une partie des difficultés auxquelles les concepteurs et développeurs

des applications web sont confrontés. D'autres difficultés apparaissent du fait que les données

d'entrée et de sortie sont transmises sur des réseaux publics. La prévention de la manipulation

des paramètres et la divulgation des données sensibles constituent d'autres problèmes majeurs.

Certains des principaux problèmes devant être résolus en ayant recours à des pratiques de

conception sécurisée sont illustrés sur la figure 40.

IV.4.5.1 – Conseils de conception

Figure 40 : Problèmes de conception des applications web

1




Catégories de vulnérabilité Problèmes dus à une conception médiocre Instructions pour une conception sécurisée

Validation des entrées

Attaques réalisées en insérant des chaînes malveillantes dans des

chaînes de requête, des champs de formulaires, des cookies et des en-

têtes HTTP. Il peut s'agir d'attaques d'exécution de commande, de

script inter-site (XSS), d'injection SQL et de dépassement de la

capacité de la mémoire tampon.

Ne vous fions pas à la saisie ; envisageons la validation

centralisée des entrées.

Ne vous fions pas à la validation côté client. Soyons prudent vis-

à-vis des problèmes de canonisation. Contraignons, rejetons et

assainissons la saisie. Validons le type, la longueur, le format et la

plage des données.

Authentification Usurpation d'identité, décodage de mot de passe, élévation des

privilèges et accès non autorisé.

Partitionnonsle site en zones anonymes, identifiées et

authentifiées. Utilisons des mots de passe sûrs. Prenons en charge

les périodes d'expiration des mots de passe et la désactivation des

comptes. Ne stockons pas d'informations d'identification

(utilisons des hachages unidirectionnels). Cryptons les canaux de

communication pour protéger les jetons d'authentification. Ne

transmettons les cookies d'authentification que sur des connexions

HTTPS.

Autorisation Accès à des données confidentielles ou restreintes, falsification et

exécution d'opérations non autorisées.

Utilisons les comptes les moins privilégiés. Envisageons la

granularité de l'autorisation. Imposeons la séparation des

privilèges. Restreignons l'accès de l'utilisateur aux ressources de

niveau système.

Gestion de la configuration

Accès non autorisé aux interfaces d'administration, capacité à mettre à

jour les données de configuration et accès non autorisé aux comptes

utilisateurs et aux profils de compte.

Utilisons des comptes de processus et de service les moins

privilégiés. Ne stockons pas d'informations d'identification en

texte brut. Utilisons l'authentification et l'autorisation renforcées

sur les interfaces d'administration. Sécurisons le canal de

communication pour l'administration à distance. Évitons de

stocker des données sensibles dans l'espace Web.

Données sensibles Divulgation d'informations confidentielles et falsification des données.

Évitons de stocker des secrets. Cryptons les données sensibles sur

le réseau. Sécurisons le canal de communication. Fournissons des

contrôles d'accès renforcés sur les magasins de données sensibles.

Ne stockons pas de données sensibles dans des cookies

persistants. Ne transmettons pas de données sensibles avec le

protocole HTTP-GET.

1




Tableau 19 : instructions de conceptions d’une application web

Gestion des sessions Capture des identificateurs de session se traduisant par le piratage de

session et l'usurpation d'identité.

Limitons la durée de vie d'une session. Sécurisons le canal.

Cryptons le contenu des cookies d'authentification. Protégeons

l'état d'une session des accès non autorisés.

Cryptographie Accès à des données confidentielles ou à des informations

d'identification de compte, ou les deux.

Ne développons pas notre propre cryptographie. Utilisons les

fonctions testées et éprouvées de la plate-forme. Conservons les

données non cryptées à proximité de l'algorithme. Utilisons

l'algorithme et la taille de clé corrects. Évitons la gestion des clés.

Recyclons périodiquement nos clés. Stockons les clés dans un

emplacement à accès restreint.

Manipulation des

paramètres

Attaques de pénétration de répertoire, exécution de commande et

contournement des mécanismes de contrôle d'accès (entre autres), se

traduisant par la divulgation d'informations, l'élévation des privilèges et

le refus de service.

Cryptons l'état des cookies sensibles. Ne vous fions pas aux

champs que le client peut manipuler (chaînes de requête, champs

de formulaires, cookies, ou en-têtes HTTP). Validons toutes les

valeurs envoyées par le client.

Gestion des exceptions Refus de service et divulgation d'informations sensibles de niveau

système.

Utilisons une gestion structurée des exceptions. Ne révélons pas

les informations sensibles d'implémentation de l'application.

N'enregistrons pas les données privées telles que les mots de

passe. Envisageons une infrastructure de gestion centralisée des

exceptions.

Audit et journalisation Absence de détection des signes d'intrusion, incapacité à authentifier

les actions d'un utilisateur et difficultés à diagnostiquer les problèmes.

Identifions les comportements malveillants. Analysons et

consignons l'activité à travers toutes les couches de notre

application. Sécurisons l'accès aux fichiers journaux.

Sauvegardons et analyons régulièrement les fichiers journaux.

1

98 Réalisation du cadre



REALISATION DU CADRE

Postérieure aux différentes phases de conception,

cette partie intitulée réalisation du cadre va nous permettre

de mettre en application les différents choix

organisationnels et conceptuels effectuées dans les phases

précédentes.

De ce fait, elle regroupe les différents choix

techniques (environnement, serveurs, langages,

architecture) nécessaires à une meilleure réalisation. Cette

partie, en plus de répertorier les outils utiles au

développement du cadre nous permettra aussi de présenter

certaines interfaces du cadre.

1




Figure 41 : les trois niveaux d’abstraction d’une

application informatique

V– REALISATION DU CADRE

V.1 – Choix techniques

V.1.1 – Architectures d’application

En règle générale, une application informatique peut être découpée en trois niveaux

d'abstraction distincts (figure 41) :

La couche de présentation, encore appelée interface homme-machine (IHM), permet

l’interaction de l’application avec l’utilisateur. Cette couche gère les saisies au clavier,

à la souris, et à la présentation des informations à l’écran. Dans la mesure du possible,

elle doit être conviviale et ergonomique ;

La logique applicative, les traitements, décrivant les travaux à réaliser par

l’application. Ils peuvent être découpés en deux familles :

les traitements locaux, regroupant les contrôles effectués au niveau du dialogue

avec l'IHM, visant essentiellement le contrôle et l'aide à la saisie,

les traitements globaux, constituant l’application elle-même. Cette couche appelée

Business Logic ou couche métier, contient les règles internes qui régissent une

entreprise donnée.

Les données, encore plus exactement l'accès aux données, regroupant l'ensemble des

mécanismes permettant la gestion des informations stockées par l'application.

Ces trois niveaux pouvant être imbriqués ou repartis de différentes manières entre

plusieurs machines, leur découpage et leur répartition permettent de distinguer les

architectures applicatives suivantes :

1




Figure 42: Architecture d’une application sur site central

l’architecture un tiers

l’architecture deux tiers

l’architecture trois tiers

l’architecture n-tiers

V.1.1.1 – l’architecture un tiers

Dans une application un tiers, les trois couches applicatives sont intimement liées et

s’exécutent sur le même ordinateur. Nous ne parlons pas ici d’architecture client-serveur,

mais d’informatique centralisée.

Dans un contexte multiutilisateur, on peut rencontrer deux types d’architecture mettant

en œuvre des applications un tiers :

des applications sur site central (mainframe)

des applications réparties sur des machines indépendantes communiquant par partage

de fichiers

Historiquement, les applications sur site central furent les premières à proposer un

accès multi utilisateurs. Les utilisateurs se connectent aux applications exécutées par le

serveur central (le mainframe) à l’aide de terminaux passifs se comportant en esclaves. C’est

le serveur central qui prend en charge l’intégralité de traitements, y compris l’affichage qui est

simplement déporté sur des terminaux passifs.

1




Figure 43 : dialogue client-serveur

Cependant, avec l’arrivée dans l’entreprise des premiers ordinateurs personnels en

réseau, il est devenu possible de déployer une application sur plusieurs ordinateurs

indépendants (application un tiers déployé). Dans ce cadre, plusieurs utilisateurs se partagent

des fichiers de données stockés sur un serveur commun. Le moteur de base de données est

exécuté indépendamment sur chaque poste client. La gestion des conflits d’accès aux données

doit être prise en charge par chaque programme de façon indépendante.

V.1.1.2 – l’architecture deux tiers

Dans une architecture deux tiers, encore appelée client-serveur de première génération

ou client-serveur de données, le poste client se contente de déléguer la gestion des données à

un service spécialisé. Ce type d'application permet de tirer partie de la puissance des

ordinateurs déployés en réseau pour fournir à l'utilisateur une interface riche, tout en

garantissant la cohérence des données, qui restent gérées de façon centralisée.

Le modèle client-serveur met en œuvre une conversation entre deux programmes que

l'on peut opposer à l'échange figé « maître-esclave » qu'entretiennent les applications sur site

central avec leurs terminaux passifs. Lors d’une telle conversation, on distingue les deux

parties suivantes :

Le client, c'est le programme qui provoque le dialogue,

Le serveur, c'est le programme qui se contente de répondre au client.

Le client provoque l'établissement d'une conversation afin d'obtenir des données ou un

résultat de la part du serveur.

:

1




Figure 45 : Positionnement du middleware entre client et serveur

Figure 44 : accès aux données en mode client serveur

Cet échange de messages transite à travers le réseau reliant les deux machines. Il met

en œuvre des mécanismes relativement complexes qui sont, en général, pris en charge par un

middleware. Ce dernier cité, dénommé littéralement « élément du milieu », est l’ensemble

des couches réseau et services logiciel qui permettent le dialogue entre les différents

composants d’une application répartie. Ce dialogue se base sur un protocole applicatif

commun.

Par ailleurs, l’objectif principal du middleware est d’unifier, pour les applications,

l’accès et la manipulation de l’ensemble des services disponibles sur le réseau, afin de rendre

l’utilisation de ces derniers presque transparente.

1




V.1.1.3 – l’architecture trois tiers

L’architecture trois tiers applique les principes suivants :

les données sont toujours gérées de façon centralisée

la présentation est toujours prise en charge par le poste client

la logique applicative est prise en charge par un serveur intermédiaire

Par conséquent, cette architecture appelée encore client-serveur de deuxième génération ou

client-serveur distribué sépare l’application en trois niveaux de service distincts :

premier niveau : l’affichage et les traitements locaux (contrôles de saisie, mise en

forme de données…) sont pris en charge par le poste client,

deuxième niveau : les traitements applicatifs globaux sont pris en charge par le

service applicatif,

troisième niveau : les services de base de données sont pris en charge par un système

de gestion de base de données (SGBD).

Dans le cadre d’une application web, le poste client prend la forme d’un navigateur, le

service applicatif est assuré par un serveur HTTP et la communication avec le SGBD met en

œuvre des mécanismes bien connus des applications client-serveur de la première génération.

Nous avons aussi, une nette distinction entre deux tronçons de communication indépendants

et délimités par le serveur HTTP.

le premier tronçon relie le poste client au serveur Web pour permettre l'interaction avec

l'utilisateur et la visualisation des résultats. On l'appelle circuit froid et n'est composé que

de standards (principalement HTML et HTTP). Le serveur web tient le rôle de « façade

HTTP »,

le deuxième tronçon permet la collecte des données, il est aussi appelé circuit chaud. Les

mécanismes utilisés sont comparables à ceux mis en œuvre pour une application deux

tiers. Ils ne franchissent jamais la façade http, et de ce fait, peuvent évoluer sans impacter

la configuration des postes clients.

V.1.1.4 – choix d’une architecture

Afin de choisir une architecture pour l’application, nous avons procédé à une étude

comparée des différentes architectures précédemment présentées. Partant de cette étude, nous

avons obtenu le tableau suivant :

1




Architectures Avantages Inconvénients

Architecture un tiers

(mainframe)

grande facilité d’administration et

haute disponibilité

large palette d’outils de conception,

de programmation et d’administration

utilisation optimale des ressources

grâce à la centralisation et à la

puissance sur une seule et même

machine

possibilités de traitements par lots

(en batch)

interface utilisateur obsolète car il

est en mode caractères

lourdeur des interfaces graphiques

Architecture un tiers

(application un tiers

déployée)

conception et mise en œuvre simple

existence de nombreux

environnement de développement

richesse ergonomiques des

applications

réponse aux besoins d’un utilisateur

isolé

déploiement dans un environnement

multiutilisateur envisageable

saturation assez rapide du réseau

lors de l’exécution d’une requête

cohabitation instable de plusieurs

moteurs de bases de données

indépendants manipulant les mêmes

données

conflits fréquents lors des

consultations, ou modifications

simultanées d’un même

enregistrement par plusieurs

utilisateurs

mise en péril de l’intégrité des

données

difficulté à assurer la confidentialité

des données.

réservé à des applications non

critiques exploitées par de petits

groupes de travail (une dizaine de

personnes au maximum)

Architecture deux tiers utilisation d’une interface utilisateur

riche

appropriation des applications par

l’utilisateur

introduction de la notion

d’interopérabilité

simplification des contrôles de

sécurité

facilité des mises à jour des données

et des logiciels

maturité des technologies supportant

l’architecture client/serveur

cohérence globale, simplicité de

développement, d’exploitation et de

totale dépendance des modules

d’applications vis-à-vis de la base de

données (il n’existe pas de solution

véritablement fiable et ouverte dans

l’interconnexion des SGBD)

le manque de modularité lorsque

toute la logique d’application se

trouve sur le poste client ne facilite

pas la maintenance et la réutilisation

(une modification de l’application ou

de la structure de la base de données

nécessite un redéploiement sur les

postes clients)

la résolution des problèmes de

montée en charge dépend

1




Tableau 20: comparaison des architectures d’applications

maintenance, meilleure ergonomie du

poste de travail

essentiellement des capacités du

SGBD

grande sollicitation du poste client

ce qui le rend de plus en plus

complexe et doit être mis à jour

régulièrement (client lourd)

la conversation entre le client et le

serveur est assez bruyante et s’adapte

mal à des bandes passantes étroites

ce type d’architecture est

grandement rigidifié par les coûts et

la complexité de sa maintenance

Architecture trois tiers une plus grande flexibilité et

souplesse

une sécurité accrue, car la sécurité

peur être définie indépendamment pour

chaque service et à chaque niveau

de meilleures performances, étant

donné le partage des tâches entre les

différents serveurs

bonne fiabilité, disponibilité et une

excellente évolutivité

centralisation d’une grande partie de

la logique applicative sur un serveur

HTTP

soulagement du poste client, car il

ne prend en charge que la présentation

et les contrôles de saisie

reprise des avantages de

l’architecture deux tiers

les solutions mises en œuvre sont

relativement complexes à maintenir et

la gestion des sessions est compliquée

forte sollicitation du serveur HTTP

la réduction de la charge du

serveur passe par la mise en œuvre de

plusieurs serveurs d’applications

Au vu de ce tableau, et compte tenu du cadre professionnel et institutionnel du projet,

notre choix s’est porté sur une architecture trois tiers puisqu’elle offre une grande marge

d’évolution et est assez flexible. Nous pouvons compter aussi au nombre des motivations de

ce choix, la possibilité d’appliquer une sécurité à tous les niveaux de manière indépendantes,

la réduction des charges du poste client ce qui le rend plus simple à manipuler pour les non-

informaticiens, et en outre la grande fiabilité et disponibilité du système.

V.1.2 – Serveurs physiques

Suite au choix d’une architecture trois tiers, il nous est nécessaire de faire le choix des

différents serveurs physiques. Ainsi, nous avons opté pour deux serveurs HP Proliant ML 150

Génération 5 avec les caractéristiques suivantes :

1




Tableau 21: devis d’un serveur HP Proliant ML 150

Mémoire Vive : 4GB PC2-5300 DDR2 ;

Disque dur : 160GB 3G SATA 7 ;

Processeur : Quad-Core Intel Xeon processor E5410 ;

Description

Prix.

unitaire Quantité Remise Total

HP ML150G5 HP CTO Chassis 113 152,00 1 1,00% 112 020,48

HP ML150G5 E5410 FIO Kit 186 784,00 1 1,00% 184 916,16

HP 4GB REG PC2-5300 2x2GB

LP Kit

120 224,00 1 1,00% 119 021,76

HP HH SATA DVD ROM Kit 28 704,00 1 1,00% 28 416,96

ML150G5 650W Power Supply

FIO Kit

41 600,00 1 1,00% 41 184,00

HP 160GB 7.2k HP SATA ETY

1y Wty HDD

49 504,00 1 1,00% 49 008,96

HP SAS/SATA 4 in 1 to 4 in 1

Cable

24 544,00 1 1,00% 24 298,56

Total 558 866,88

Ces serveurs ont été choisis parce qu’ils ont de hautes performances, peu onéreux et

avec des opportunités d’extension importantes pour une entreprise.

V.1.3 – Systèmes d’exploitation

Défini comme le programme de base de tout ordinateur, le système d’exploitation est

un ensemble de programmes responsables de la liaison entre les ressources matérielles d’un

ordinateur et les applications informatiques de l’utilisateur. Il permet de dissocier les

programmes et le matériel, afin notamment de simplifier la gestion des ressources et offrir à

l’utilisateur une interface homme-machine simplifiée pour lui permettre de s’affranchir de la

complexité de la machine physique.

Outre ces fonctions génériques, le système d’exploitation accomplit plusieurs tâches

telles que :

la gestion du processeur

la gestion de la mémoire vive

la gestion des entrées et sorties

la gestion de l’exécution des applications

1




la gestion des droits

la gestion des fichiers

De nos jours, nous recensons une multitude de systèmes d’exploitation dont : OS/2 de

IBM, Mac OS, Windows, GNU/Linux, etc. Dans le cadre de notre projet, le choix d’un

système d’exploitation s’avère nécessaire puisque c’est ce système qui fournira aux

applications informatiques des points d’entrées génériques, fiables et stables pour les

périphériques. Ainsi, le choix d’un mauvais système d’exploitation peut avoir un impact sur

l’efficacité, la disponibilité et le fonctionnement de notre application. Pour ce faire, nous

avons étudié les deux systèmes les plus connus, qui sont : Windows (dans sa version Server)

et Linux.

V.1.3.1 – Windows

Windows est une gamme de systèmes d’exploitation produite par Microsoft,

principalement destinés aux machines compatibles à l’IBM Personal Computer (IBM PC ou

PC). C’est le remplaçant de Microsoft Disk Operating System (MS-DOS). Depuis les années

1990, avec la sortie de Windows 95, son succès commercial pour équiper les ordinateurs

personnels est tel qu’il possède à l’heure actuelle un statut de quasi-monopole.

Par ailleurs, la gamme de Windows est composée de plusieurs branches, dont la

branche NT (News Technologies) apparue en 1993, et qui a été l’objet d’une réécriture

complète du système, afin de convenir aux ordinateurs personnels comme au serveur. Cette

branche s’est principalement développée dans le milieu professionnel, et est né du divorce de

Microsoft et d’IBM sur le développement du système d’exploitation OS/2. S’inspirant de

VAX VMS et d’Unix, cette famille a apporté des concepts nouveaux, comme la notion

d’objet permettant une utilisation uniforme.

Actuellement, Microsoft a présenté lors des TechDays 2008 qui se sont déroulés du 11

au 13 février 2008 à Paris, Microsoft Windows Server 2008 qui est le successeur de Windows

Server 2003 dont la sortie remonte à 5 ans. Ce nouveau-né est basé sur la même base de code

que Windows Vista ; par conséquent, ils partagent tous deux la même architecture et les

mêmes fonctionnalités. Puisque la base de code est commune, Windows Server 2008 contient

par défaut la plupart des fonctionnalités techniques, de sécurité, de gestion et d'administration

nouvelles à Windows Vista et aussi des innovations telles que :

la réécriture de la couche réseau (IPv6 native, connectivité sans-fil native,

amélioration de la sécurité et de la vitesse);

l’amélioration du déploiement, de la récupération et de l'installation basée sur une

image source;

l’amélioration des outils de diagnostics, de supervision, de traçabilité des évènements

et de rapports;

l’apport de nouvelles fonctionnalités de sécurité telles que Bitlocker et ASLR;

l’amélioration du pare-feu Windows avec la configuration sécurisée par défaut;

une administration optimisée de l’infrastructure avec un modèle du réseau fondé sur

des stratégies

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

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

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

http://fr.wikipedia.org/wiki/Pare-feu

1




Figure 46: les distributions de Linux

de nouvelles technologies de script et de contrôles pour une gestion centralisée des

serveurs et l’automatisation des tâches

une sécurité renforcée et une meilleure gestion des serveurs situés à l’extérieur de

l’organisation

Les processeurs et composants mémoire sont définis comme des périphériques Plug

and Play, afin de permettre le "branchement à chaud" (hot-plug) de ceux-ci. Cela permet aux

ressources système d'être partitionnées de façon dynamique à l'aide du module Dynamic

Hardware Partitioning (littéralement: "Gestion Dynamique du Partitionnement"); chacune

disposant de sa propre partition de mémoire, processeur et pont d'hôte E/S indépendante les

unes des autres.

V.1.3.2 – GNU/Linux

Linux, ou GNU/linux est un système d’exploitation compatible POSIX. Linux est

basé sur le noyau Linux, un logiciel libre créé en 1991 sur un ordinateur compatible à l’IBM

PC (PC) par Linus Torvalds. Ce dernier, qui au début des années 1990 voulait mettre au point

son propre système d’exploitation pour son projet de fin d’études, décida de développer une

version UNIX pouvant être utilisée sur une architecture de type 80386. Pour y parvenir, il

conclut d’étendre les possibilités de Minix (premier clone d’UNIX fonctionnant sur PC et

écrit par Andrew Tanenbaum), en créant ce qui allait devenir Linux. Attirées par cette

initiative, de nombreuses personnes ont contribué à aider Linus Torvalds à réaliser ce

système, si bien qu’en 1991 une première version du système a vu le jour. C’est en mars 1992

qu’a été diffusée la première version ne comportant quasiment aucun bogue.

Développé sur Internet par des milliers d’informaticiens souvent bénévoles, Linux

fonctionne maintenant sur du matériel allant du modem au superordinateur. GNU/Linux étant

gratuit, différentes sociétés l’on reprit et complété afin de distribuer un système d’exploitation

visant des publics (figure 46) et caractérisé par sa portabilité, sa stabilité, sa robustesse et sa

conformité aux standards.

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



1




Parmi les plus connus, nous pouvons citer :

Debian qui est une distribution non commerciale régie par le contrat social Debian.

Elle se distingue par le très grand nombre d’architectures supportées, son importante

logithèque et par son cycle de développement relativement long, gage d’une certaine

stabilité.

Fedora qui est une distribution communautaire supervisée par RedHat.

Mandriva Linux qui est une distribution internationale éditée par la société Mandriva

en France et dans le monde. Très orientée grand public, elle est conçue pour être facile

d’installation et d’usage pour les débutants et les professionnels.

Gentoo est une distribution caractérisée par sa gestion des paquetages à la manière des

ports BSD, effectuant généralement la compilation des logiciels sur l’appareil de

l’utilisateur. Elle est dédiée aux utilisateurs avancés, aux développeurs et aux

passionnés.

RedHat (officiellement RedHat Enterprise Linux ou RHEL) est une distribution

commerciale largement répandue dans les entreprises (surtout aux États-Unis).

Slackware est l’une des plus anciennes distributions existantes. Slackware a été

historiquement une des premières permettant de faire tourner GNU/Linux in situ

depuis un CD-ROM dès 1995. Slackware est toujours maintenue par son créateur

Patrick Volkerding et est particulièrement adaptée aux utilisations serveur. C’est la

version la plus pure de GNU/Linux.

Suse Linux a été la première distribution européenne. Créée en 1993 à Nuremberg,

elle a été rachetée par la société Novell à la fin de l’année 2003. Elle propose deux

distributions principales : SUSE Linux Enterprise orientée vers les entreprises

(certifications matérielles et logicielles nombreuses) et openSUSE orientée vers le

grand public

Ubuntu, basée sur Debian. Plus orientée vers le grand public, édite des versions

stables plus fréquemment. Elle est maintenant disponible en live CD. Cette

distribution dispose d’une solide base d’utilisateurs en France, et partout ailleurs.

1




V.1.3.3 – Choix d’un système d’exploitation

Dans l’optique d’une meilleure prise de décision au niveau des systèmes

d’exploitation, une étude comparative des deux systèmes présentés précédemment a été

réalisée. C’est ainsi que nous avons eu comme résultat le tableau suivant :

1




Tableau 22 : Comparaison des systèmes d’exploitation

Systèmes

d’exploitation

Prise en main Coût

d’exploitation

Évolution Sécurité Ouverture et respect

des standards

Découplage de système et

des logiciels

Windows Prise en main assez

aisée grâce à une

interface épurée et

intuitive, présence de

nombreux assistant

pour guider

l’utilisateur dans ses

taches

Windows est

assez onéreux, de

plus qu’il faut

débourser de

l’argent pour

acquérir d’autres

logiciels

indispensables.

Par ailleurs,

Windows au fil du

temps devient

gourmand en

ressources.

Au fil des années,

Windows

abandonne le

suivi de ses

anciennes

versions. Ce qui

envoie les

utilisateurs à

suivre de manière

forcée l’évolution

en achetant les

versions les plus

récentes.

Windows est configuré par

défaut de façon moins stricte

afin de faciliter la vie de

l’utilisateur, mais aussi celle

des personnes et logiciels

malveillants. Il faut attendre

des mois pour avoir le

correctif d’une faille

découverte. Or les failles

découvertes sont d’une grande

ampleur (faille RPC : virus

blaster).

Sous Windows il est

souvent nécessaire

d’acheter ou installer

des logiciels

supplémentaires pour

réaliser des actions.

Les standards sont

souvent mal respectés

ce qui rend

l’interconnexion des

systèmes compliquée.

La base de registre contient la

configuration du système

d’exploitation et de tous les

logiciels. Si elle est

endommagée, c’est tout le

système qui devient instable.

Ainsi, le mauvais

fonctionnement d’une

application ou son installation

peut nécessiter un

redémarrage pour que

Windows se stabilise.

GNU Linux Linux exige plus de

temps pour le

maitriser. La courbe

d’apprentissage est

plus raide, mais plus

avancée. Cependant

avec des distributions

récentes comme

Ubuntu, Mandriva ou

Xandros, la

simplicité

d’utilisation a

augmenté

Beaucoup de

distributions de

Linux sont

gratuites et assez

bien abouties.

Elles viennent

aussi avec bon

nombre de

logiciels qu’il

suffit d’installer

sur des postes qui

ne sont pas

nécessairement

puissants.

Avec Linux les

mises à jour sont

continuelles et

incrémentales afin

de permettre une

évolution

volontaire.

La gestion interne de la

sécurité dans Linux lui confère

un statut d’un système sûr, car

elle le rend moins sensible aux

virus et vers. Les failles de

sécurité sont assez rapidement

corrigées (généralement dans

les 24 heures). Son code

ouvert contribue aussi à sa

sécurité puisque quiconque

peut vérifier s’il y a des

logiciels espions à l’intérieur.

Linux est très ouvert

aux standards. Cela

fait que Linux est

facile à

interconnecter aux

autres systèmes.

Grâce a sa conformité

aux standards, Linux

est un système de

choix pour tout ce qui

concerner le réseau et

les communications

Sous Linux, le système et les

programmes sont dans des

environnements bien séparés,

puisque la configuration de

chaque logiciel est enregistrée

dans des fichiers séparés ce

qui est un gage de stabilité

puisque la désinstallation,

l’installation ou une erreur

d’une application ne peut pas

agir généralement sur le

système entier.

1




En nous basant sur cette comparaison, nous avons opté pour le système d’exploitation

GNU\Linux puisqu’il est gratuit et vient avec de nombreux logiciels tous gratuits. Il a été

choisi parce que non seulement il nous offre une meilleure stabilité ce qui assez primordiale,

car notre application doit pouvoir être accessible à tout moment et toujours rapide d’accès,

mais encore à cause de son évolutivité et de la forte communauté de développeurs qui

s’attèlent à corriger au plus vite les failles rencontrées dans le système.

Il est à noter que nous avons opté plus particulièrement pour la distribution Debian car

elle entièrement gratuite, sa qualité et son sérieux sont unanimement reconnus, et enfin parce

qu’elle est très utilisée par les serveurs.

V.1.4 – Serveurs web

Né en 1990 au CERN des travaux de Tim Berners Lee, le premier serveur HTTP

Nexus délivrait des pages HTML statiques au navigateur web www.

Aujourd'hui, la principale mission des serveurs web dynamiques porte sur l'accès aux

applications et aux données de l'entreprise, qui permet, par exemple, d'exploiter un progiciel

en ligne. Et ce, au moyen de transactions effectuées par des interpréteurs de scripts ou des

classes techniques (Perl, VB, JS, ADO.NET , JDBC...), qui traduisent des requêtes HTTP en

commandes adressées au système d'exploitation.

L'autre type de transaction repose sur l'accès à un site sécurisé. Les requêtes HTTP

sont alors chiffrées sur une couche SSL (HTTPS) afin d'accéder à un serveur HTTP

qu'authentifie un certificat.

Plusieurs années d’existence ont consolidé le marché des serveurs, au point qu’il ne

regroupe aujourd’hui qu’une poignée de produits. Nous pouvons citer entre autres Apache,

Microsoft IIS, Sun ONE Web Server et Zeus Web Server.

V.1.4.1 – Apache

Apache est apparu en avril 1995. Au début, il s'agissait d'une collection de correctifs

et d'additions au serveur NCSA HTTPd 1.3, qui était dans le domaine public et le serveur

HTTP alors le plus répandu. De cette origine, de nombreuses personnes affirment que le

nom Apache vient de « a patchy server », soit « un serveur rafistolé ». Par la suite, Apache

a été complètement réécrit, de sorte que, dans la version 2, il ne reste pas de trace de

NCSA HTTPd. De plus, cette dernière version possède plusieurs avancées majeures par

rapport à la version 1, entre autres :

le support de plusieurs plateformes,

le support de processus légers UNIX,

une nouvelle API et le support IPv6.

http://www.ado.net/

1




Il est à noter que le serveur Apache fonctionne principalement sur les systèmes

d'exploitation Unix (GNU/Linux, BSD et UNIX) et Windows. La version Windows n'est

considérée comme stable que depuis la version 2 d'Apache. Et qu’il est utilisé par de

nombreux produits, dont Websphere d'IBM, ainsi que par Oracle Corporation. Il est

également supporté d'une façon ou d'une autre par les outils de développement Borland

Delphi et Kylix, ainsi que par des CMS comme Drupal.

Coté conception, Apache est conçu pour supporter de nombreux modules lui

donnant des fonctionnalités supplémentaires :

interprétation du langage Perl, PHP et Python,

serveur proxy,

Common Gateway Interface,

Server Side Includes,

réécriture d'URL, négociation de contenu,

protocoles de communication additionnels,

etc.

V.1.4.2 – Microsoft IIS

Microsoft IIS (Internet Informations Services) est le serveur HTTP créé par

Microsoft. Ce serveur Web n'est utilisable que sur des produits de Microsoft (Windows NT,

Windows 2000, Windows XP et encore Windows Server 2003).

Au début de l'histoire de ce produit, il y a eu de nombreux problèmes de sécurité. La

mise en place de site était très abordable mais il n'y avait aucune sécurité. Microsoft est donc

repartie de zéro pour la sixième version de leur serveur.

Au volet fonctionnalités, Microsoft IIS :

supporte de nombreuses technologies telles que ASP, .NET, le PHP

ou encore le CGI.

utilise une métabase texte qui permet de faire des sauvegardes et des restaurations en

cas de problèmes critiques sur le serveur.

possède des fonctionnalités de résolutions de problèmes et la possibilité de

récupération de métabase endommagée.

détecte également les problèmes de pertes de mémoire, les violations d'accès

et autres erreurs.

permet la tolérance des pannes et le redémarrage des processus si nécessaire.

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



1




Au niveau des parts de marché, IIS possède environ 30% de celles-ci mais la

commercialisation de la version 6.0, a redonné un nouveau souffle à ce produit. En effet

actuellement, il possède une croissance de 4.25%.

V.1.4.3 – Sun Java System Web Server

Sun One Web Server est une solution éprouvée par plus de 50% des sites des

entreprises classées au Fortune 100, particulièrement sensibles aux notions de haute

disponibilité et de continuité de service. Il résiste aux fortes montées en charge et assure ainsi

stabilité et performance. Le serveur web de Sun est disponible sur les plates-formes UNIX,

Linux, et Windows

Capable de restaurer des paramètres de configuration et doté de générateurs de

statistiques et de rapports, la déclaration de sites web par le biais d'instances se révèle peu

conviviale.

Pour revenir sur l’aspect technique de ce serveur, il possède la version 1.1 du

protocole HTTP fondé sur l’exploitation des servlets (applications Java fonctionnant du côté

serveur). Il intègre la technologie de pages JSP, la possibilité de déclaration de sites virtuels

sécurisés (SSL 3.0, TLS 1.0) et non sécurisés, au sein d'une même instance de serveur web.

Le serveur Sun est prêt pour IPv6 et intègre une interface de visualisation des journaux

d'activité, de modules de rapports statistiques et de suivi de l'activité du serveur. Il offre la

possibilité d’un filtrage d'en-têtes HTTP et de contrôle des ressources par serveur virtuel

(bande passante, connexion)

La solution de Sun, disponible pour de nombreux systèmes d’exploitation est destinée

aux entreprises qui exploitent des serveurs d'applications Java. Son meilleur atout demeure sa

portabilité.

V.1.4.4 – Zeus Web Server

Zeus Technology, Ltd. développe une plate-forme de produits et de technologies pour

la mise en service de sites Web critiques à haut rendement. Comme l'optimisation du

rendement du serveur Web constitue l'élément fondamental d'Internet, Zeus a créé une gamme

de produits logiciels puissants et très évolutifs pour atteindre cet objectif. Cette gamme

comprend Zeus Web Server(MC), leur produit phare, ainsi que Zeus Load Balancer, Zeus

Mass Hosting Edition et Zeus Appliance Edition. Zeus possède une impressionnante clientèle

et des partenaires stratégiques, incluant des entreprises de classe mondiale, comme eBay,

Hewlett- Packard, SGI, Sprint, Telefonica et UUNET, qui lui ont permis de connaître une

croissance constante depuis sa création ne 1995.

Destiné aux environnements Linux, Unix et Mac OS X, Zeus Web confirme sa

réputation de serveur multi plate-forme sécurisée. Il assure par exemple le réglage des

ressources système (temps processeur, bande passante) allouées à une session sécurisée de

type SSL. Il intègre aussi une base de droits qui évite la mise en place d'un plan de nommage

1




au moyen d'un annuaire LDAP externe. Enfin, il assure la détection d'une signature d'attaque

par déni de service (scriptSnort) et le filtrage des en-têtes HTTP. Muni d'un répartiteur de

charge, il présente par ailleurs une interface d'exploitation très ergonomique. Simple et

complète, Web Controller permet de procéder à des réplications ou à des modifications par lot

de sites au moyen d’une sélection manuelle.

Grâce à un partenariat avec Zend, spécialiste de l'optimisation du code PHP, Zeus

Web Server assure de bonnes performances pour la génération dynamique des sites écrits à

l'aide de ce langage. En outre, il propose un interfaçage natif avec le serveur d'application

libre Tomcat. Un autre atout est le support de Webdav, un standard de l'IETF, pour gérer la

coédition de documents sur le Web. Autres fonctions qui méritent l'attention: un traitement à

la volée des redirections d'URL ou encore un moteur optimisé pour des flux bidirectionnels -

générés par exemple par l'exploitation de "Web Services".

V.1.4.5 – Choix d’un serveur web

Afin de porter un choix judicieux et adapté à nos besoins, nous avons établi un

tableau comparatif des différents serveurs web dominant le marché.

1




Tableau 23: Comparaison des serveurs web

Critères Prise en main et

installation

Étendue des fonctions de

sécurité

Performances Environnements Coût Évolutivité

Apache Complexité de paramétrage,

car s’effectue en ligne de

commande ou avec une

interface web peu conviviale

et ergonomique

Exploitation de différents

processus au sein de

plusieurs flots d’exécution,

base de droit intégrée pour

la gestion des utilisateurs

Peu gourmand en

ressources matérielles,

excellente stabilité

Linux, Windows,

de nombreux

UNIX, MacOs X

gratuit Sa modularité et sa

gratuité font que ses

failles de sécurités sont

assez rapidement

résolues et permettent

aussi le développement

de plusieurs extensions

Microsoft

IIS

Existence de plusieurs

assistants qui guide tout au

long de l’utilisation

Adoption de règles de

cloisonnement pour offrir

une certaine stabilité,

mécanisme de sauvegarde

des données de

configuration

Très gourmand en


Windows Server

2000, Windows

Server 2003,

Windows Server

2008

Inclus dans la

branche des

serveurs de

Windows

Logiciels propriétaires, il

faut souvent attend un

certain temps avant

d’obtenir de nouvelles

versions

Sun Java

System

Web

Server

Installation en ligne de

commande moins conviviale

quoiqu’efficace avec

l’apparition de menus

adaptés



une certaine stabilité,

mécanisme de sauvegarde

des données de

configuration

Doté de générateurs de

statistiques et de rapports

qui le rendent assez

pratique, destiné aux

entreprises exploitant des

serveurs d’application Java

Linux, Windows,

de nombreux

UNIX, MacOs X

100$ par

utilisateur et par

an.

Zeus Web

Server

L’interface HTML Web

Controller centralise

l’ensemble des opérations

d’installation, de

configuration et

d’exploitation



une certaine stabilité, base

de droit intégrée pour la

gestion des utilisateurs,

Peu gourmande en


capacité à tenir de très gros

pics de fréquentation,

interface native avec

certaines bases de données

Linux, de

nombreux UNIX,

MaxOs X

1900 euros

1




Face aux différents résultats de la comparaison, nous avons choisi comme serveur web,

Apache car

il est entièrement gratuit,

il possède une panoplie d’extensions utiles,

il est basé sur précédent développement de qualité (notoriété),

il est le fruit de l’adoption de plusieurs choix techniques populaires,

il est un produit qui a une image de marque préservée et renforcée par la qualité du

produit (performance et sécurité)

il est modulaire ce qui encourage l’innovation et la personnalisation

il possède une forte communauté d’utilisateurs et de développeurs qui fournit des

supports techniques, et corrigent continuellement le logiciel,

il est le plus utilisé avec un pourcentage de 49.73% en juin 2008 (annexe 4).

V.1.5 – Système de gestion de bases de données (SGBD)

La fonction première d'un Système de Gestion de Base de Données (SGBD) est d'être

un outil de stockage d'informations offrant des fonctions simples de manipulation de grands

volumes de données. L’un des avantages de ces SGBD est que l'interrogation de ces

informations s’effectue d’une manière indépendante de l'architecture physique de stockage.

Les SGBD garantissent la cohérence de ces données en cas de mise à jour simultanée

par plusieurs utilisateurs. Les transactions assurent l'intégrité des données en cas d'opérations

incorrectes réalisées par un programme ou un utilisateur. Les données stockées dans un

SGBD sont dites persistantes, leur fiabilité et leur récupération en cas de panne matérielle ou

logicielle doivent être toujours possibles. De plus, le SGBD doit assurer la confidentialité des

données en cas d'accès malveillant ou accidentel.

Les fonctionnalités essentielles d'un SGBD sont donc les suivantes :

Le système doit assurer la persistance des données : lorsqu’une transaction

(ensemble de requêtes) est validée, les données doivent être persistantes, c'est-à-dire

qu’elles doivent être enregistrées de manière permanente.

Le système doit assurer la fiabilité des données : une transaction doit être atomique,

autrement dit, soit exécutée complètement, soit pas du tout. Des mécanismes de

reprise sur panne doivent être présents. La panne d’une mémoire doit assurer la

fiabilité des données.

Le système doit offrir la possibilité à plusieurs utilisateurs de manipuler les

données concurremment. Il doit au minimum assurer la sérialisation des transactions.

1




La sérialisation des transactions est l'exécution en parallèle d’un ensemble de

transactions, produisant le même résultat que si elles étaient exécutées en série.

Le système doit offrir la possibilité à l'utilisateur d'interroger la base de façon

simple. Le langage de requête SQL a été créé dans le but d'interroger, de manière

relativement simple, les bases de données. Il peut tout de même être remplacé, pour le

néophyte par une interface graphique.

Le système doit assurer la confidentialité des données. La notion d'utilisateur et de

droits associés (droits de lecture, d'écriture et d'exécution sur les objets de la base) est

indispensable afin d’assurer cette confidentialité. Le système doit également prévoir

des mécanismes de cession et de retrait de droits.

Le système doit pouvoir efficacement gérer les demandes : les performances

doivent être suffisamment bonnes. Pour cela, le SGBD doit utiliser des techniques

d'indexation, d'optimisation de requêtes et de gestion de caches. De plus, il est

essentiel que le SGBD puisse facilement évoluer et s’adapter à l’augmentation du

nombre de requêtes et à celle de l’espace de stockage, cette augmentation se

produisant immanquablement au fil des ans.

Après avoir recensé les principes généraux des bases de données, nous allons procéder

maintenant à la présentation des différents SGBG sur le marché.

V.1.5.1 – MySQL

MySQL est un système de gestion de base de données (SGDB) qui selon le type

d’application, est libre ou propriétaire. Il fait partie des logiciels de gestion de base de

données les plus utilisés au monde, autant par le grand public (applications web

principalement) que par des professionnels.

Développé par MySQL AB, qui a été acheté le 16 janvier 2008 par Sun Microsystems

pour un milliard de dollars américains, MySQL est un serveur de base de données

relationnelle SQL développé dans un souci de performances élevées en lecture, ce qu’il

signifie qu’ il est davantage orienté vers le service de données déjà en place que vers

celui de mises à jour fréquentes et fortement sécurisées. Il est multithread et multiutilisateur.

Il fonctionne sur de nombreux systèmes d’exploitation différents incluant :

AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, Windows, OpenBSD, OS/2 Warp, et

bien d’autres.

MySQL possède plusieurs systèmes de fichiers notamment MyIsam, InnoDB, BDB,

etc. les fonctionnalités supportées, comme les clés étrangères ou les transactions sont

différentes en fonction du système de fichier choisi.

1




V.1.5.2 – PostgreSQL

PostgreSQL est un système de gestion de base de données relationnelle et objet

(SGBDRO). C’est un outil libre disponible selon les termes d’une licence de type BSD. Ce

système est fondé sur une communauté mondiale de développeurs et d’entreprises.

Il est capable de stocker plus de types de données que les types traditionnels entiers,

caractères, etc. L’utilisateur peut créer des types, des fonctions, utiliser l’héritage de type. Au

nombre des environnements supportés, nous pouvons citer :

Solaris, SunOS, Mac OS X, HP-UX, AIX, Linux, Digital Unix, BSD, NetBSD, freeBSD,

etc.

Depuis sa version 8.0, PostgreSQL fonctionne également nativement sur Windows.

Avant cette version, PostgreSQL fonctionnait sous Windows à l’aide d’un émulateur de type

cygwin.

Par ailleurs, PostgreSQL est sans aucun doute, le système de gestion de base de

données à code ouvert le plus avancée au monde. Il possède les caractéristiques des systèmes

commerciaux les plus puissants dont :

le support complet pour transactions

le support complet ACID (Atomicity Consitency Isolation Durability)

l’orientation objet avec héritages des tables.

V.1.5.3 – Microsoft SQL-Server

SQL Server est un SGBDR développé et commercialisé par Microsoft. Initialement

co-développé par Sybase et Microsoft, Ashton-Tate ayant aussi été associé à la première

version qui est sortie en 1989. Cette version est sortie sur les plateformes Unix et OS/2.

Depuis Microsoft a porté ce système de base de données sous Windows et il est

maintenant uniquement supporté sur ce système. En 1994 le partenariat entre les 2 sociétés

ayant été rompu Microsoft sortie la version 6.0 puis 6.5 seul, sur la plateforme Windows NT,

et continua à commercialiser le moteur de base de données sous le nom de SQL Server.

Tandis que Sybase, pour éviter toute confusion a renommé Sybase SQL Server en Sybase

Adaptive Server Enterprise.

Microsoft SQL Server fait désormais partie de la stratégie technique de Microsoft en

matière de base de données. Le moteur MSDE qui est la base de SQL Server doit à terme

remplacer le moteur Jet (celui qui gère les bases Access) dans les applications telles qu’

Exchange et Active Directory.

Il est idéal pour les développements spécialisés dans les produits Microsoft : ASP,

Visual Basic, modèles d’objet composants. En outre, c’est un système de base de données

parfaitement adapté pour des applications critiques, et avec n’importe quel niveau de

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

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

http://fr.wikipedia.org/wiki/Ashton-Tate


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


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

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

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

1




complexité. De plus, il utilise une partie de l’espace de la base de données pour sauvegarder le

log des transactions avec les commandes restantes, ce qui assure qu’en aucun cas,

indépendamment si le programmeur utilise des transactions sur son code, la base de données

de données reste dans un état inconsistant dû à une exécution partielle des commandes.

Il est à remarquer que ce système offre beaucoup d’autres caractéristiques avancées,

orientées à maintenir l’intégrité de la base de données, comme les triggers, et il offre un

support complet ACID.

V.1.5.4 – Oracle

Oracle est le SGBDRO fourni par Oracle Corporation. Il a été développé par Lawrence

Ellison, accompagné d’autres personnes telles que Bob Miner et Ed Oates. Reconnu comme le

SGBDRO le plus puissant du point de vu relationnel comme objet, Oracle est un outil doté de

plusieurs fonctionnalités telles que :

le support de SQL, PL/SQL et de Java

la possibilité de monter la base de données sur plusieurs serveurs (grid en 10g, rac en

9i)

la possibilité de gestion de données géographiques,

le partitionnement physique des données en sous-ensemble pour optimiser les temps

d’accès

l’intégration du moteur OLAP qui permet de stocker les cubes sous forme de BLOB

(Binary Large Object)

la gestion de très grands volumes de données,

la réplication des données selon différents mode synchrone ou asynchrone de tout ou

une partie d’une base de données.

Ce système est disponible sous les environnements suivants : Linux, Windows, Unix, Mac OS

X.

V.1.5.5 – Choix d’un SGBD

Compte tenu des fonctionnalités plus ou moins avancées de chaque SGBD, une étude

comparative nous a semblé nécessaire afin de choisir le SGBD le plus adapté à notre projet.

1




Points forts Points faibles

MySQL solution très courante en hébergement public

très bonne intégration dans l’environnement

Apache/PHP

OpenSource, bien sue les critères de licences

soient de plus en plus difficiles à supporter

version cluster depuis la version 4

facilité de déploiement

plusieurs moteurs de stockage adaptés aux

différentes problématiques

gratuit

rapidité d’exécution des requêtes

ne supporte qu’une faible partie des standards

SQL-92

supports incomplets des triggers et procédures

stockées

gestion des transactions que depuis la version

4 avec InnoDB

assez peu de richesse fonctionnelle

manque de robustesse avec de fortes

volumétries

pas d’héritage de table

pas de vue matérialisée

pas d’ordonnanceur intégré

pas de partitionnement

cluster par clonage de base / impact sur la

volumétrie

PostgreSQL opensource et gratuit

fiable et relativement performant, tout en

restant simple d’utilisation

supporte la majorité du standard SQL-92 et

possède en plus un certain nombre

d’extensions (Java, Ruby, PL-SQL)

très riche fonctionnellement, multitude de

modules

simple d’utilisation et d’administration

héritage de tables

solution en cluster possible

sauvegardes peu évoluées

supporte les bases de données de moyenne

importance

pas de service web

pas de support XML

pas d’ordonnanceur intégré

pas de vue matérialisée

permissions seulement au niveau de la table,

pas au niveau de la colonne

solutions de réplications pas encore totalement

réussis

cluster par clonage de base : impact sur la

volumétrie

lenteur dans les exécutions des requêtes

lourdeur

SQL Server Administration aisée

Indépendance entre les diverses bases,

facilitant l'intégration de plusieurs

applicatifs dans une même instance

Une des bases les plus performantes sous

Windows en configuration par défaut

Optimiseur statistique enrichi à flux tendu

Réplication intégrée (sauf pour MSDE)

Frontaux et assistants très poussés (sauf pour

MSDE)

Langage T-SQL très convivial, intégration de

CLR

Sous-SELECT possible dans clause FROM

Distributions fortement liées au système

d'exploitation

Mono-plateforme (MS Windows)

Depuis la version 2005, plus de prise directe

sur les tables système (remplacées par de

vues système)

Pas possibilité de donner des priorités aux

traitements, hormis en passant par le

workflow

Pas de prise en charge du LDAP

Pas de cluster (hormis en actif-passif, en se

basant sur le cluster OS)

Pas certifié SQLJ, pas d'intégration Java,

1




Tableau 24 : Comparaison des SGBD

Gestion de l'indexation textuelle

Services Web

Support XML

Ordonnanceur intégré

orientation C#

Pas d'héritage de table

Fonctionnalités s'éloignant des normes en

vigueur (CLR remplaçant Java, fonctions

dans clauses FROM, ...)

Oracle Richesse fonctionnelle

Row level storage security (RLSS) : permet de

ne faire apparaître que certaines lignes des

tables pour un utilisateur/une application

donnée.

Intégration LDAP, SSL, Unicode; réplication

intégrée; capable de mapper un fichier plat

en table

Parallélisme, caches nommés; haute

disponibilité; grande possibilité de tuning

Compression des backups

Procédures stockées en PL-SQL (langage

propriétaire Oracle, orienté ADA) ou ... en

JAVA (depuis la 8.1.7) ce qui peut s'avérer

utile pour les équipes de développement.

Assistants performants via Oracle Manager

Server, possibilité de gérer en interne des

tâches et des alarmes

Gestion centralisée de plusieurs instances

Concept unique de retour arrière (Flashback)

Pérennité de l'éditeur : avec plus de 40% de

part de marché, ce n'est pas demain

qu'Oracle disparaîtra

Réglages fins : dans la mesure où l'on connait

suffisamment le moteur, presque TOUT est

paramétrable.

Accès aux données système via des vues, bien

plus aisément manipulables que des

procédures stockées.

Interface utilisateur remaniée et extrêmement

riche, permettant - enfin ! - le tuning fin de

requêtes par modification des plans

d'exécution.

Architecture Multi-Générationnelle (MGA)

Services Web, support XML

Ordonnanceur intégré

Prix exorbitant, tant au point de vue des

licences que des composants matériels

(RAM, CPU) à fournir pour de bonnes

performances

Administration complexe... liée à la richesse

fonctionnelle

Fort demandeur de ressources, ce qui

n'arrange rien au point précité, Oracle est

bien plus gourmand en ressource mémoire

que ses concurrents, ce qui implique un

investissement matériel non négligeable.

Porosité entre les schémas = difficile de faire

cohabiter de nombreuses applications sans

devoir créer plusieurs instances. Il manque

réellement la couche "base de données" au

sens Db2/Microsoft/Sybase du terme.

Méta modèle propriétaire, loin de la norme.

Tables partitionnées, RAC... uniquement

possible à l'aide de modules payants

complémentaires sur la version Enterprise.

Gestion des verrous mortels mal conçue

(suppression d'une commande bloquante

sans rollback)

Faiblesses de l'optimiseur (ne distingue pas les

pages en cache ou en disque, n'utilise pas

d'index lors de tris généraux, statistiques

régénérés par saccade...)

Tables système peu documentées

Une quantité de bogues proportionnelle à la

richesse fonctionnelle, surtout sur les

dernières versions

Gestion erratique des rôles et privilèges (pas

possible de donner des droits sur des

schémas particuliers sans passer par leurs

objets, désactivation des rôles lors

d'exécution de packages...)

Nombreuses failles de sécurités liées à

l'architecture elle-même

1




Après la réalisation de cette comparaison, nous avons arrêté notre choix sur MySQL

qui malgré les inconvénients s’avère être le SGBD ayant la plus grande vitesse d’exécution

des requêtes. Or nous savons que la rapidité d’exécution est un facteur important dans la

conception d’une application web. De plus, ce SGBD est gratuit et possède une grande famille

d’utilisateurs qui fournit à la fois un support humain toujours disponible et un gage de fiabilité

et de stabilité.

V.1.6 – Langage de scripts coté serveur

En quelques années seulement, la conception des sites web a radicalement changé. Les

sites doivent être de plus en plus riches en informations ce qui oblige à des mises à jour

automatisées. C'est l'une des fonctions d'un langage de script côté serveur, parmi d'autres,

comme la connexion à une base de données, la génération d'outils de recherche pour les

visiteurs, la personnalisation des pages. En bref, il permet de concevoir un site dynamique

dont la mise en forme des pages reste stable.

Toutefois, ces langages qui s’exécutent sur les serveurs sont une multitude de nos

jours. Nous avons comme exemple :

Java Server Pages (JSP),

Active Server pages (ASP),

HyperText Préprocesseur (PHP),

Perl.

V.1.6.1 – PHP

Le langage PHP (acronyme récursif pour PHP: Hypertext Préprocesseur), est créé en

1994 par Rasmus Lerdorf pour son site Web. C'était à l'origine une bibliothèque logicielle en

Perl dont il se servait pour conserver une trace des visiteurs qui venaient consulter son CV.

Au fur et à mesure qu'il ajoutait de nouvelles fonctionnalités, Rasmus a transformé la

bibliothèque en une implémentation en langage C, capable de communiquer avec des bases de

données et de créer des applications dynamiques et simples pour le Web. Rasmus décida alors

en 1995 de publier son code, pour que tout le monde puisse l'utiliser et en profiter. PHP

s'appelait alors PHP/FI (pour Personal Home Page Tools/Form Interpreter). En 1997, deux

étudiants, Andi Gutmans et Zeev Suraski, redéveloppèrent le cœur de PHP/FI. Ce travail

aboutit un an plus tard avec Zend Engine, le nouveau cœur de PHP/FI, devenu alors PHP:

Hypertext Preprocessor en version 3.

Le langage PHP est utilisé principalement en tant que langage de script côté serveur,

ce qui veut dire que c'est le serveur (la machine qui héberge la page web en question) qui va

interpréter le code PHP et générer du code (constitué généralement d'XHTML ou d'HTML, de

CSS, et parfois de JavaScript) qui pourra être interprété par un navigateur. Il peut également

http://fr.wikipedia.org/wiki/Acronyme_r%C3%A9cursif

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

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

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

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

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

http://fr.wikipedia.org/wiki/Curriculum_vit%C3%A6

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

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



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

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

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

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

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

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

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

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

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

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

1




fonctionner comme n'importe quel langage interprété de façon locale, en exécutant les

programmes en ligne de commande. PHP peut de plus générer d'autres formats en rapport

avec le Web, comme le WML, le SVG, le format PDF, ou encore des images bitmap telles

que JPEG, GIF ou PNG.

Il a été conçu pour permettre la création d'applications dynamiques, le plus souvent

dédiées au Web. PHP est très majoritairement installé sur un serveur Apache, mais peut être

installé sur les autres principaux serveurs HTTP du marché, par exemple IIS. Ce couplage

permet de récupérer des informations issues d'une base de données, d'un système de fichiers

(contenu de fichiers et de l'arborescence) ou plus simplement des données envoyées par le

navigateur afin d'être interprétées ou stockées pour une utilisation ultérieure.

C'est un langage peu typé et souple et donc facile à apprendre par un débutant mais, de

ce fait, des failles de sécurité peuvent rapidement apparaître dans les applications.

Pragmatique, PHP ne s'encombre pas de théorie et a tendance à choisir le chemin le plus

direct. Néanmoins, le nom des fonctions (ainsi que le passage des arguments) ne respecte pas

toujours une logique uniforme, ce qui peut être préjudiciable à l'apprentissage.

Son utilisation commence avec le traitement des formulaires puis par l'accès aux bases

de données. L'accès aux bases de données est aisé une fois l'installation des modules

correspondant effectuée sur le serveur. La force la plus évidente de ce langage est qu'il est

devenu au fil du temps un incontournable des offres d'hébergement.

Libre, gratuit, simple d'utilisation et d'installation, ce langage nécessite comme tout

langage de réseau une bonne compréhension des mécanismes sous-jacents ainsi qu'une

connaissance des problèmes de sécurité.

V.1.6.2 – ASP

Active Server Pages (ASP) est une technologie développée par Microsoft utilisée dans

la programmation Web. C'est une technologie web dynamique, équivalente et concurrente de

PHP. Elle nécessite pour fonctionner une plate-forme Windows avec IIS (Internet Information

Services) installé, ou encore une plate-forme Linux ou Unix avec une version modifiée

d'Apache.

ASP n'est en réalité qu'une structure composée d'objets accessibles par deux langages

principaux : le VBScript et le JScript. Il est possible d'utiliser d'autres langages comme le

PerlScript, le REXX, ou encore le Python en ajoutant le moteur d'interprétation du langage

adéquat à IIS.

À l'inverse de certains langages de programmation pour ordinateur (C, C++), cette

technologie n'utilise pas de langages compilés, mais des langages interprétés. Elle est capable

http://fr.wikipedia.org/wiki/Langage_interpr%C3%A9t%C3%A9_informatique

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

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

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

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

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

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

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

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

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

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_fichiers

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


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

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

http://fr.wikipedia.org/wiki/Plate-forme#Informatique

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

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



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

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

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

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

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

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

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

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

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

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

http://fr.wikipedia.org/wiki/Interpr%C3%A9teur

1




de se connecter à des bases de données, de lire des fichiers XML et possède des composants

pour la gestion de l'upload, du ftp...

En tant que technologie Microsoft, il peut lire et écrire facilement des documents issus

d'Office (Excel, Word...) à condition d'accepter de passer par COM (voir ci-dessous) et

d'avoir Office installé sur le serveur. Du reste, d'autres langages (comme PHP) peuvent tout

aussi bien utiliser la même technologie COM, à condition de tourner également sur un serveur

Windows où les produits Office sont installés.

Nommé COM (Component Object Model, aussi appelé ActiveX), ce système est

l’interface utilisé par l’ASP pour communiquer avec des ressources du poste serveur. Il

renvoie ensuite de l'HTML au client via le protocole HTTP (HyperText Transfert Protocol).

V.1.6.3 – JSP

Le JavaServer Pages ou JSP est une technologie basée sur Java qui permet aux

développeurs de générer dynamiquement du code HTML, XML ou tout autre type de page

web. La technologie permet au code Java et à certaines actions prédéfinies d'être ajoutés dans

un contenu statique. Depuis la version 2.0 des spécifications, la syntaxe JSP est complètement

XML.

Cette dernière ajoute des balises XML, appelées actions JSP, qui peuvent être

utilisées pour appeler des fonctions. De plus, la technologie permet la création de

bibliothèques de balises JSP (taglib) qui agissent comme des extensions au HTML ou au

XML. Les bibliothèques de balises offrent une méthode indépendante de la plate-forme pour

étendre les fonctionnalités d'un serveur HTTP.

Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java. Un

compilateur JSP peut générer un servlet Java en code source Java qui peut à son tour être

compilé par le compilateur Java, ou peut générer le pseudo-code Java interprétable

directement.

En plus des actions JSP prédéfinies, les développeurs peuvent ajouter leurs propres

actions personnalisées en utilisant l'API d'extension de balises JSP (JSP Tag Extension API).

Pour ce faire, il faut écrire une classe Java qui implémente une des interfaces de balises et

écrire le fichier XML de description de balise qui donne les caractéristiques du marqueur et

les classes qui l'implémentent.

Par défaut, le langage de script utilisé est le Java ; cependant, les spécifications

permettent d'employer d'autres langages, tout comme ASP autorisent le JScript et le VBScript.

En dépit du fait que les pages JSP écrites en Java restent plus flexibles et robustes que les

scripts codés dans des langages plus simples tels que le JavaScript et le VBScript, le Java

demande un temps d'apprentissage plus long que les langages de scripts simples.

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

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

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

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

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

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

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

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



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

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

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

http://fr.wikipedia.org/wiki/Plate-forme

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

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

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

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

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

1




Pour jouer sur les deux tableaux à la fois, c'est-à-dire avoir une plate-forme applicative

robuste pour le web et un langage facile à utiliser, JSP est pourvu d'un certain nombre de

balises côté serveur qui permettent aux développeurs de produire la plupart des opérations de

génération de contenus dynamiques sans la moindre ligne de code en Java. Ces balises sont

plus particulièrement destinées aux développeurs familiers aux scripts, voire aux graphistes

n'utilisant que le HTML mais même les développeurs Java peuvent les utiliser pour obtenir

des opérations avancées dans les pages JSP.

V.1.6.4 – Perl

Perl est un langage de programmation créé par Larry Wall en 1987 et reprenant des

fonctionnalités du langage C et des langages de scripts sed, awk et shell (sh).

Larry Wall donne deux interprétations de l'acronyme "PERL":

Practical Extraction and Report Language ou langage pratique d'extraction et de

génération de rapports

Pathetically Eclectic Rubbish Lister ou collectionneur de déchets pathétiquement

éclectiques

Perl est un langage optimisé pour extraire des informations de fichiers textes et

imprimer des rapports basés sur ces informations. C'est aussi un bon langage pour de

nombreuses tâches d'administration système. Il est écrit dans le but d'être pratique (simple à

utiliser, efficace, complet) plutôt que beau (petit, élégant, minimaliste).

Contrairement à TCL/TK qui interprète ligne après ligne, l'interpréteur Perl compile

les scripts Perl pour ensuite les exécuter, ce qui permet deux choses: des vérifications de

syntaxe, et une très grande vitesse d'exécution. Perl est séquentiel et Orienté Objet, donc libre

à son utilisateur de faire son choix. Mais il dispose en standard de nombreuses fonctions qui

font que sa portabilité d'un système d'exploitation à un autre est extrême ! On peut même

exporter du code Perl en C, et compiler des interfaces à des librairies existantes pour les

utiliser en Perl ! Perl est aussi le seul langage de type script qui puisse être intégré à Apache,

le transformant en langage compilé et caché en mémoire, le rendant aussi performant que du

C.

Le Perl combine les meilleures fonctionnalités de C, sed, awk et sh, de telle manière

que les personnes familiarisées à ces langages ne devraient avoir aucune difficulté avec celui-

ci. La syntaxe se rapproche presque totalement de celle du C. Contrairement à la plupart des

utilitaires Unix, Perl ne limite pas arbitrairement la taille des données, si vous avez assez de

mémoire, Perl peut remplir une chaîne de caractères avec le contenu total d'un fichier. Il n'y a

pas de niveau maximum à la récursivité. Et les tables utilisées par les tableaux de hachage

(anciennement appelé "tableaux associatifs") croissent dès que nécessaire afin de garantir un

bon niveau de performance.

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

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


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

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

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

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

1




Tableau 25: Comparaison des langages de scripts

Perl utilise des techniques sophistiquées de recherche de motif pour pouvoir traiter très

rapidement de très grandes quantités de données. Bien qu'optimisé pour le traitement des

fichiers textes, Perl peut aussi traiter des données binaires, et faire que des fichiers dbm soit

vus comme des tableaux de hachage. Les scripts Perl ayant leurs setuid bits positionnés sont

plus sûrs que des programmes C grâce à des mécanismes de suivi de flot de données qui

permettent d'éviter de nombreux trous de sécurités particulièrement stupides.

V.1.6.6 – Choix d’un langage de script coté serveur

Comme nous avons pu le voir dans les différentes sections consacrées chacune à un

langage de script, les offres semblent au premier abord très proches en valeur. Pour effectuer

le choix du langage à utiliser, un examen comparatif a été réalisé.

ASP JSP PERL PHP

Complexité d’apprentissage Moyen Élevé Élevé Faible

Puissance Moyen élevé Élevé Moyen

Complexité/ Puissance Bon bon Bon Élevé

Portabilité Faible Élevé Élevé Bonne

AGL MS visual

InterDev

IBM VisualAge

for Java

Perl Builder

Ressources Peu Peu Peu énormément

Suite à cette comparaison, nous avons décidé d’utiliser PHP pour sa faible complexité

d’apprentissage, sa puissance et sa portabilité. Il est de surcroit gratuit et bénéficie du soutien

de plusieurs personnes qui développent des extensions plus utiles les unes par rapport aux

autres. De plus, ce langage s’inscrit dans le cadre d’un environnement qui a fait ses preuves

dans le domaine du web : l’environnement LAMP (Linux Apache MySQL PHP).

Au nombre des motivations de ce choix, vient s’ajouter le fait qu’il est été conçu dès le

départ pour le développement web et a repris les syntaxes de plusieurs langages éprouvés tels

que le C et de Perl. Il ne faudrait surtout pas oublier, la forte communauté qui corrige

rapidement les failles de sécurité découvertes.

V.2 – Interfaces

Par considération pour les utilisateurs finaux du cadre qui ne sont pas des spécialistes

de l’informatique, nous avons développé deux parties distinctes mais menant au même

objectif : renseigner la base de données.

Il est à signaler que ces parties font partie intégrante de l’interface d’administration qui

n’est qu’une composante du cadre.

1




Figure 47: Classique – liste des projets

V.2.1 – Interface classique d’administration

Liste des projets

Cette page permet de consulter tous les projets contenus dans la base de données. A

partir des liens à gauche, nous pouvons modifier ou supprimer un projet.

1




Figure 48: Classique – ajouter un projet

Ajouter un projet

Cette page permet d’ajouter un projet en definissant le sous-programme auquel il

appartient et en renseignant aussi les champs obligatoires.

1




Figure 49: Classique – modifier un projet

Modifier un projet

Cette page permet de modifier les informations d’un projet en modifiant les champs

necéssaires.

1




Figure 50: Assistant – liste des programmes

V.2.2 – Assistant

Liste des programmes

Cette page permet de consulter tous les programmes contenus dans la base de données.

A partir des liens à gauche, nous pouvons modifier ou supprimer un programme en etant

assité tout au long du processus par des formulaires ergonomiques et intuitifs.

1




Figure 51: Assistant – ajouter un programme

Ajouter un programme

Cette page permet d’ajouter un programme. Dans cette partie, l’ajout d’un programme

implique l’ajout de toutes ces composantes à travers d’autres formulaires. L’ajout d’un

élement est automatiquement materialisé par l’apparition d’une icône dans l’explorateur à qui

est à droite de la page.

1




Figure 52: Assistant – modifier un projet

Modifier un projet

Cette page permet de modifier un projet, en parcourant les différentes composantes du

programme à l’aide de l’explorateur située à droite de la page.

1

134 Conclusion



Conclusion

Durant le stage effectué à la Direction du Suivi-Evaluation pendant la période d’avril à

mai 2008, il nous a été demandé de réaliser et de sécuriser un cadre de gestion de projet. Plus

précisément, le cas du SIGPOD. Ce cadre a pour finalité une meilleure gestion et un meilleur

suivi des projets à travers la création d’une base de données et d’une application web

d’interfaçage. Au cours de cette période de dur labeur, nous avons travaillé de concert avec le

personnel de la DSE qui a été réellement formidable tant du point de vue des informations

fournies, mais aussi de l’assistance pour la réalisation de ce projet.

À ce jour, le bilan est tel que ; nous avons pu concevoir la base de données de la

gestion des projets et aussi l’interface d’administration qui servira à la renseigner. Le

développement des autres interfaces est en cours de réalisation. De ce fait, nous avons mis à la

disposition du personnel de la DSE, l’interface d’administration afin qu’il puisse la tester et

apporter les suggestions nécessaires pour sa correction, mais aussi pour les autres interfaces à

réaliser très prochainement.

Visiblement, ce stage nous a été d’un apport bénéfique en ce sens qu’il nous a permis :

de travailler sur un projet de grande envergure et très évolutif, ce qui nous a permis

d’élargir nos domaines de connaissance

d’apprendre le développement collectif d’applicatif de taille importante

et de nous frotter aux méthodes d’analyse et de conception dans un environnement réel

Au demeurant, nous espérons que le développement intégral de cette application

permettra à la DSE de pouvoir améliorer son rendement de travail qui est déjà excellent et

aussi de disposer d’un outil technique qu’elle pourra mettre en exergue dans les mois à venir.

Conclusion

1

135 Liste des figures et des tableaux



Liste des figures et des tableaux

Les figures

1. réseau informatique du ministère

2. la démarche merise

3. la courbe du soleil

4. les vues d’UML

5. les différentes phases

6. les activités

7. le développement itératif et incrémental

8. les risques

9. concepts de diagramme de cas d’utilisation

10. système actuel – diagramme de cas d’utilisation

11. concepts du diagramme d’activités

12. système actuel – mise à jour d’une activité

13. système actuel – validation d’un indicateur

14. système actuel – mise à jour d’informations

15. système actuel – consultation d’informations

16. concepts du diagramme de classes

17. système actuel – diagramme de classes axé sur les activités

18. système actuel – diagramme de classes axé sur les projets

19. système futur – diagramme de cas d’utilisation

20. système futur –diagramme de classes axé sur les activités

21. système futur – diagramme de classes axé sur les projets

22. système futur – consulter des informations

23. système futur – mettre à jour une activité

24. système futur – valider un indicateur

25. système futur – mettre à jour des informations

26. système futur – gérer des profils

27. système futur – activité

28. concepts de la gestion des risques

29. exemple d’un risque

30. le processus de gestion de risques

31. les différentes zones de risques

32. démarche globale d’EBIOS

33. les principales phases d’OCTAVE

34. la démarche globale de MEHARI

35. approche globale de la sécurité

Liste des figures et tableaux

1




36. composants réseau : routeur – pare-feu – commutateur

37. menaces du serveur web prédominantes et vulnérabilités courantes

38. principales menaces et vulnérabilités d’un serveur d’applications

39. principales menaces et vulnérabilités d’un serveur de base de données

40. problèmes de conception des applications web

41. les trois niveaux d’abstraction d’une application informatique

42. architecture d’une application sur site central

43. dialogue client-serveur

44. accès aux données en mode client-serveur

45. positionnement du middleware en mode client-serveur

46. les distributions de Linux

47. classique – liste des projets

48. classique – ajouter un projet

49. classique – modifier un projet

50. assistant – liste des programmes

51. assistant - ajouter un programme

52. assistant – modifier un projet

Les tableaux

1. réseau informatique du ministère

2. liste du matériel informatique

3. les différentes déclinaisons du processus unifié

4. système actuel – mettre à jour une activité

5. système actuel – valider un indicateur

6. système actuel – mettre à jour des informations

7. système actuel – consulter des informations

8. les besoins fonctionnels

9. les cas d’utilisation

10. système futur – mettre à jour une activité

11. système futur – consulter des informations

12. système futur – valider un indicateur

13. système futur – mettre à jour des informations

14. système futur – gérer des profils

15. comparaison des méthodes d’analyses de risques

16. menaces et contre-mesures d’un réseau

17. menaces et contre-mesures d’un serveur web

18. menaces et contre-mesures d’un serveur d’applications

19. menaces et contre-mesures d’un serveur de base de données

20. instructions de conception d’une application web

1




21. comparaisons des architectures d’applications

22. devis d’un serveur HP Proliant ML 150

23. comparaison des systèmes d’exploitation

24. comparaison des serveurs web

25. comparaison des SGBD

26. comparaison des langages de script

1

138 Référence bibliographiques



Références bibliographiques

Buyens, fevrier 2001, Le guide du webmaster : trucs et astuces, France, Microsoft Press,

381p.

Damien Seguy et Phillipe Gamache, fevrier 2006, Sécurité PHP 5 et Mysql, France,

Eyrolles, 249 p.

DRHC, 2003, Initiation aux principes fondamentaux de la gestion de projet, Canada, 17p.

FIDA, mars 2007, Guide pratique de S&E des projets : concevoir et mettre en place le

système de suivi-évaluation, Rome, 24p.

Pascal Roques, septembre 2006, UML 2 par la pratique, France, Eyrolles, 357p.

Robert Longeon et Jean-Luc Archimbaud, 1999, Guide de la sécurité des systèmes

d’informations : à l’usage des directeurs, France, CNRS, 100p.

Adou Aboua, 2007, Conception et mise en place d’une solution de téléphonie IP : cas du

Ministère d’Etat Ministère du plan et du développement : « mémoire de fin d’étude »,

INP-HB-EFCPC-CFCIP, Abidjan, 109p.

Deli Zran, 2007, Mise en place d’une plate-forme de surveillance d’équipements et

d’applications : alerte d’exploitation (ALEX) : « mémoire de fin d’étude », INP-HB,

Yamoussoukro, 109p.

Steve Koffi Ano, 2005, Création du site web dynamique de la marine nationale :

« mémoire de fin d’étude », INP-HB, Yamoussoukro, 61p.

Nicolas Mayer et JeanPhillipe Humbert, avril-mai 2006, « la gestion des risques pour les

systèmes d’information », MISC n° 24, 60p, p10-22.

Cases, 2005, Référentiel de sécurité des applications web, consulté le 12 mai 2008,

http://www.case.lu.

Sébastien Poggi, mais 2005, Rapport de veille sur les standards et méthodes en matière de

sécurité informatique, consulté le 12 Mai 2008, http://www.case.lu.

Sébastien Poggi, mais 2005, Etude comparée de référentiels et méthodes utilisées en

sécurité informatique, consulté le 12 Mai 2008, http://www.case.lu.

Ysosecure, 2008, Evolution des méthodes de gestion des risques informatiques, consulté

le 13 mai 2008, http://www.ysosecure.com

Ysosecure, 2008, Les méthodes de gestion de risques, consulté le 13 mai 2008,

http://www.ysosecure.com

Références bibliographiques

1

139 Référence bibliographiques



DCSSI, juillet 2004, Expression des Besoins et Identification des Objectifs de Sécurité :

Etude de cas archimed, consulté le 14 mai 2008, http.//www.ssi.gouv.fr

DCSSI, novembre 2004, Expression des Besoins et Identification des Objectifs de

Sécurité : Referentiel de compétences, consulté le 14 mai 2008, http.//www.ssi.gouv.fr

DCSSI, février 2004, Expression des Besoins et Identification des Objectifs de Sécurité :

Section 1 Introduction, consulté le 14 mai 2008, http.//www.ssi.gouv.fr


Section 2 démarche, consulté le 14 mai 2008, http.//www.ssi.gouv.fr


Section 3 Techniques, consulté le 14 mai 2008, http.//www.ssi.gouv.fr


Section 4 Outillage pour l’appreciation des risques SSI, consulté le 14 mai 2008,

http.//www.ssi.gouv.fr

CLUSIF, février 2007, Mehari 2007 manuel de références des services de sécurité,

consulté le 14 mai 2008, http.//www.clusif.asso.fr

CLUSIF, février 2007, Mehari 2007 Enjeux, consulté le 14 mai 2008,

http.//www.clusif.asso.fr

CLUSIF, février 2007, Mehari 2007 Introduction, consulté le 14 mai 2008,


CLUSIF, février 2007, Mehari 2007 analyse des risques, consulté le 14 mai 2008,


CLUSIF, février 2007, présentation Mehari, consulté le 14 mai 2008,


Hugo Etiévant, août 2006, Normes de sécurité : les méthodes d’analyse des risques,

consulté le 15 mai 2008, http://www.developpez.com.

C.Alberts, A. Dorofee, J.Stevens, C.Woody, août 2003, Introduction to the OCTAVE

Approach, consulté le 15 mai 2008, http://www.cert.org/octave.

Microsoft, août 2004, Sécurisation des applications web, consulté le 17 mai 2008, http://

msdn2.microsoft.com

Rémi Leblond, décembre 1999, Vers une architecture n-tiers, consulté le 20 juin 2008,

http://remi.leblond.free.fr

Communauté wikipedia, juin 2008, les architectures logicielles, consulté le 20 juin 2008,

http://fr.wikipedia.org

Communauté wikipedia, juin 2008, les serveurs web, consulté le 20 juin 2008,


Communauté wikipedia, juin 2008, les sgbd, consulté le 20 juin 2008,


1

140 Annexes



Annexes

Annexe 1

Organigramme du Ministère du Plan et du Développement

Annexe 2

Répartition des normes et référentiels SSIC dans une perspective d'amélioration continue

Annexe 3

Caractéristiques d’un réseau sécurisé

Annexe 4

Pourcentage d’utilisation des serveurs web

Annexes

1

141 Annexes



Annexe 1

Organigramme du Ministère du Plan et du développement

1

142 Annexes



Annexe 2

Répartition des normes et référentiels SSIC dans une perspective

d’amélioration continue

1

143 Annexes



Annexe 3

Caractéristiques d’un réseau sécurisé

Composant Caractéristique

Routeur

Correctifs et mises à jour Le système d'exploitation du routeur est corrigé avec un logiciel mis à jour.

Protocoles Les protocoles et les ports inutilisés sont bloqués.

Le filtrage entrant et sortant est activé.

Le trafic ICMP est analysé depuis le réseau interne.

Les messages concernant l'expiration de la durée de vie de valeur 1 ou 0 sont

bloqués (la détermination d'itinéraires est désactivée).

Le trafic de diffusion dirigé n'est pas transféré.

Les paquets ping volumineux sont analysés.

Les paquets du protocole RIP (Routing Information Protocol), si celui-ci est

utilisé, sont bloqués au niveau du routeur le plus extérieur.

Accès administratif Les interfaces de gestion inutilisées sur le routeur sont désactivées.

Une stratégie très stricte est appliquée en matière de mot de passe

d'administration.

Le routage statique est utilisé.

L'administration Web est désactivée.

Services Les services inutilisés sont désactivés (par exemple bootps et Finger).

Audit et journalisation La journalisation de tout le trafic refusé est activée.

Les journaux sont stockés de manière centralisée et sécurisée.

L'audit des journaux est mis en place pour les situations inhabituelles.

Détection d'intrusion Des systèmes IDS sont mis en place pour identifier et informer d'une attaque

active.

Pare-feu

Correctifs et mises à jour Le logiciel de pare-feu et le système d'exploitation sont corrigés avec les

dernières mises à jour de sécurité.

Filtres La politique de filtrage de paquets bloque tout le trafic dans les deux

directions, à l'exception des données requises.

Les filtres d'application spécifiques sont mis en place pour limiter le trafic

inutile.

Journalisation et audit Tout le trafic autorisé est enregistré.

Le trafic refusé est enregistré.

Les journaux changent selon une fréquence permettant d'effectuer une

analyse rapide des données.

Tous les périphériques du réseau sont synchronisés par rapport à une même

source horaire.

Réseaux de périmètre

Commutateur

Correctifs et mises à jour Les tous derniers correctifs de sécurité sont testés et installés, ou la menace

de vulnérabilités connues est atténuée.

VLAN Assurez-vous que les VLAN ne font pas l'objet d'une utilisation ou d'une

confiance excessives.

Valeurs par défaut non sécurisées Les services inutilisés sont désactivés.

Services Les services inutilisés sont désactivés.

1

144 Annexes



Cryptage Le trafic commuté est crypté.

Autres

Synchronisation des journaux Toutes les horloges de périphériques ayant des capacités de journalisation

sont synchronisées.

Accès administratif au réseau Les protocoles TACACS ou RADIUS sont utilisés pour authentifier les

utilisateurs administratifs.

Listes de contrôle d'accès (ACL) au

réseau

Le réseau est structuré de manière à ce que les ACL puissent être placées sur

les hôtes et sur les réseaux.

1

145 Annexes



Annexe 4

Pourcentage d’utilisation des serveurs web

memoire de fin de cycle ingenieur - ano steve - 2008

Documents