Memoire de Fin de Cycle Ingenieur - Ano Steve - 2008

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD
Ddicace
DEDICACE
A la mmoire de mon oncle Thomas Kouam ANO, qui je nai pas pu dire Merci. Que son me repose en paix. Steve Koffi Ano
Ddicace

1
Remerciements
Remerciements
Le prsent mmoire mane de plusieurs journes et nuits de dur labeur qui ont ncessit limplication de plusieurs personnes. Cest pourquoi nous voulons dune manire distincte leur exprimer toute notre reconnaissance. Ainsi, nous adressons nos sincres remerciements au Dr Ibrahim LOKPO, Directeur de la Direction Suivi-Evaluation (DSE), pour nous avoir permis deffectuer notre stage au sein de sa direction. Nous remercions M. Marcelin Konan BROU notre encadreur pdagogique pour la justesse de ses critiques et lexpertise dont il nous a fait bnficier lors de certaines difficults rencontres. Aussi, exprimons-nous notre reconnaissance lensemble du personnel de la DSE pour leur accueil, singulirement M. Oumar TATO, responsable informatique, qui a accept dtre notre tuteur de stage et dont les conseils nous ont orients 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 rcents) dont nous ne citerions pas les noms de peur den oublier, qui ont su nous apporter leur soutien durant ces 23 premires annes de notre vie. Nous esprons bnficier de leur prsence encore de longues annes.
Sincrement Steve Koffi Ano
Remerciements

1
Table des matires
Table des matires

Ddicace ..................................................................................................................................... 2 Remerciements ........................................................................................................................... 3 Table des matires ...................................................................................................................... 4 Avant-propos .............................................................................................................................. 8 Introduction ................................................................................................................................ 9 I PRSENTATION DE LA STRUCTURE DACCUEIL ................................................... 11 I.1 Prsentation du Ministre dtat, Ministre du Plan et Dveloppement .............. 11 I.1.1 Le cabinet .............................................................................................................. 11 I.1.2 Les services rattachs ............................................................................................ 11 I.1.3 Les directions ........................................................................................................ 12 I.2 Prsentation de la Direction Gnrale de la Population et du Renforcement de Capacits (DGPRC) ........................................................... 13 I.2.1 Les Missions ......................................................................................................... 13 I.2.2 La composition...................................................................................................... 13 I.3 Prsentation de la Direction du Suivi-Evaluation (DSE) ..................................... 14 I.3.1 Les Missions ......................................................................................................... 14 I.3.2 La composition...................................................................................................... 14 I.4 Prsentation du Service Informatique .................................................................... 15 I.4.1 Les Missions ......................................................................................................... 15 I.4.2 Linventaire des ressources informatiques ............................................................ 15 I.4.3 Le rseau informatique ......................................................................................... 16 II ETUDE PREALABE ........................................................................................................ 19 II.1 Prsentation du projet ................................................................................................. 19 II.1.1 Contexte et justification ...................................................................................... 19 II.1.2 Objectifs ............................................................................................................... 19 II.1.3 Rsultats attendus ................................................................................................ 19 II.2 Mthodes danalyse et de conception ......................................................................... 20 II.2.1 La Mthode dtude et de Ralisation Informatique par Sous-ensemble (MERISE) ............................................................ 21 II.2.1.2 Les concepts ................................................................................................. 21 II.2.1.2 Les niveaux ................................................................................................... 21
Sommaire

1
II.2.1.3 La dmarche ................................................................................................. 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 dmarche ................................................................................................. 27 II.2.3 Choix dune mthode........................................................................................... 31 II.3 Etude de lexistant ...................................................................................................... 33 II.3.1 Description de lexistant ...................................................................................... 33 II.3.1.1 Description du processus de gestion des projets........................................... 34 II.3.1.2 Le diagramme de cas dutilisation ................................................................ 34 II.3.1.2.1 les concepts ............................................................................................ 34 II.3.1.2.2 la reprsentation du diagramme de cas dutilisation.............................. 36 II.3.1.3 Les descriptions textuelles ............................................................................ 37 II.3.1.4 Les diagrammes dactivits .......................................................................... 38 II.3.1.4.1 Les concepts .......................................................................................... 38 II.3.1.4.2 Les reprsentations des diagrammes dactivits ................................... 40 II.3.1.5 Les diagrammes de classes ........................................................................... 42 II.3.1.5.1 Les concepts .......................................................................................... 42 II.3.1.5.2 Les reprsentations des diagrammes de classes ................................... 43 II.3.2 Critiques de lexistant .......................................................................................... 46 II.4 Proposition de solution ............................................................................................... 47 III CONCEPTION DU CADRE ........................................................................................... 49 III.1 Modlisation mtier ................................................................................................... 49 III.1.1 Prsentation du projet raliser ......................................................................... 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 Modlisation du contexte ................................................................................... 50 III.2 Recueil et expression des besoins ............................................................................. 52 III.2.1 Identification des cas dutilisation ...................................................................... 52 III.2.2 Diagramme de cas dutilisation .......................................................................... 52 III.2.3 Descriptions textuelles ....................................................................................... 54 III.3 Analyse ...................................................................................................................... 57 III.3.1 Dveloppement du modle statique ................................................................... 57 III.3.2 Dveloppement du modle dynamique .............................................................. 60 II.3.2.1 Diagramme dactivits .................................................................................. 60 Sommaire

1
II.3.2.2 Diagramme dtats-transition ....................................................................... 65 IV SECURISATION DU CADRE ....................................................................................... 67 IV.1 Ncessit dune scurisation du systme dinformation ........................................... 67 IV.2 Prsentation 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 mthodes danalyses de risques .......................................................................... 74 IV.3.1 EBIOS (Expression des Besoins et Identification des Objectifs de Scurit) . 74
IV.3.2 OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) ....................
76
IV.3.3 MEHARI (Mthode harmonise dAnalyse des Risques) ............................... 77 IV.3.3 Choix dune mthode danalyse de risques........................................................ 79 IV.4 Mesures de scurit ................................................................................................... 81 IV.4.1 Scurisation du rseau ........................................................................................ 82 IV.4.1.1 Prsentation ................................................................................................. 82 IV.4.1.2 Menaces et contre-mesures ......................................................................... 82 IV.4.2 Scurisation du serveur web .............................................................................. 86 IV.4.2.1 Prsentation ................................................................................................. 86 IV.4.2.2 Menaces et contre-mesures ......................................................................... 86 IV.4.3 Scurisation du serveur dapplications .............................................................. 89 IV.4.3.1 Prsentation ................................................................................................. 89 IV.4.3.2 Menaces et contre-mesures ......................................................................... 89 IV.4.4 Scurisation du serveur de base de donnes ...................................................... 92 IV.4.4.1 Prsentation ................................................................................................. 92 IV.4.4.2 Mesures et contre-mesures .......................................................................... 92 IV.4.5 Scurisation de lapplication web ...................................................................... 95 IV.4.5.1 Prsentation ................................................................................................. 95 IV.4.5.1 Conseils de conception................................................................................ 95 V REALISATION DU CADRE ............................................................................................ 99 V.1 Choix techniques ........................................................................................................ 99 V.1.1 Architectures dapplication ................................................................................. 99 V.1.1.1 larchitecture un tiers .................................................................................. 100 V.1.1.2 larchitecture deux tiers .............................................................................. 101 V.1.1.3 larchitecture trois tiers ............................................................................... 103 V.1.1.4 choix dune architecture ............................................................................. 103 V.1.2 Serveurs physiques ............................................................................................ 105 V.1.3 Systmes dexploitation .................................................................................... 106 Sommaire

1
V.1.3.1 Windows ..................................................................................................... 107 V.1.3.2 GNU/Linux ................................................................................................. 108 V.1.3.3 Choix dun systme dexploitation............................................................. 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 dun serveur web ............................................................................. 115 V.1.5 Systme de gestion de bases de donnes (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 dun 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 dun langage de script cot serveur ................................................. 127 V.2 Interfaces .................................................................................................................. 127 V.2.1 Interface classique dadministration .................................................................. 128 V.2.2 Assistant ............................................................................................................ 131 Conclusion .............................................................................................................................. 134 Liste des figures et des tableaux ............................................................................................. 135 Rfrences bibliographiques .................................................................................................. 138 Annexes .................................................................................................................................. 140
Sommaire

1
Avant-propos
Avant-propos
N le quatre (04) septembre 1996 par le dcret 96 678, de la fusion et de la restructuration de quatre (04) grandes coles dont : lInstitut National Suprieur de lEnseignement Technique (INSET), lcole Nationale Suprieure de Travaux Publics (ENSTP), lcole Nationale Suprieure dAgronomie (ENSA), lInstitut Agricole de Bouak (IAB), LInstitut National Polytechnique Houphout-Boigny (INP-HB) se prsente comme un tablissement de rfrence en matire de formation des cadres et techniciens suprieurs en Cte dIvoire et en Afrique subsaharienne. Il a en son sein six (06) grandes coles qui sont : lcole de Formation Continue et de Perfectionnement des Cadres (EFCPC), lcole Suprieure dAgronomie (ESA), lcole Suprieure des Mines et Gologie (ESMG), lcole Suprieure de Travaux Publics (ESTP), lcole Suprieure dIndustrie (ESI) lcole Suprieure de Commerce et dadministration dEntreprise (ESCAE). Lcole Suprieure dIndustrie (ESI), notre cole a pour objectif la formation dingnieurs de conception et de techniciens suprieurs oprationnels pour le march professionnel. Pour y parvenir, lcole initie un stage de fin de cycle permettant ltudiant de se familiariser aux ralits de lentreprise et de mettre au profit de celle -ci les connaissances acquises tout au long de sa formation. Cest ainsi que nous avons t accueillis la Direction de Suivi-Evaluation (DSE) pour une priode de trois (03) mois.
Avant - Propos

1
Introduction
Introduction
Depuis son accession lindpendance, le 07 aot 1960, la Cte dIvoire a opt pour un rgime conomique libral qui lui a permis de connatre une croissance conomique sans prcdent. Ce choix a conduit des progrs dans de nombreux domaines sociaux notamment la sant, lducation, lemploi et le logement pour le bien-tre des populations. partir de lanne 1980, avec la dtrioration des termes de lchange, le pays a t confront une crise conomique aigu qui a favoris la mise en uvre des programmes dajustement structurels (PAS). Lexcution de ces programmes a eu pour consquences la rduction des dpenses dans la plupart des secteurs sociaux. Ce qui amena le gouvernement a accord une attention particulire lutilisation rationnelle et efficiente des dpenses publiques et de laide extrieure. Cette proccupation partage galement par les partenaires au dveloppement sest traduite par un grand intrt accord au suivi et lvaluation. Cette convergence de visions sest matrialise au niveau international par plusieurs engagements internationaux. Au niveau national, lengagement sest concrtis par la cration dans les ministres techniques, de structures charges du suivi et de lvaluation des actions de dveloppement. Toutefois, malgr limportance accorde au suivi et lvaluation, force est de constater que, la mise en uvre efficace de systmes de suivi et valuation est confronte la faiblesse des capacits nationales en matire de suivi et valuation et en labsence de donnes de base fiables pour llaboration des indicateurs de conception et de suivi et valuation des programmes. Cest ainsi que la Direction Suivi-Evaluation au vu de lacuit du problme de reconnaissance et de la gestion transparente des ressources nous a accueillis en son sein et nous a confis le thme suivant : RALISATION ET SCURISATION DUN CADRE DE GESTION DE PROJETS : CAS DU SIGPOD Pour mener bien ce travail, objet de ce prsent mmoire, notre approche sarticulera autour de 5 phases principales : une premire phase de prsentation de la structure daccueil qui consistera dcrire lenvironnement dans lequel nous avons travaill, une deuxime phase dtude pralable qui nous amnera analyser lexistant et proposer une solution aux problmes rencontrs, une troisime phase de conception qui permettra de mettre en place la solution choisie, une quatrime phase de scurisation qui indiquera les moyens utiliser pour la scurit des informations, et enfin la dernire phase qui est la ralisation de la solution.
Introduction

1
PRESENTATION DE LA STRUCTURE DACCUEIL
Dans le souci dune meilleure prsentation de notre travail, il convient de dcrire la structure dans laquelle nous avons effectu notre stage. Ainsi, dans cette partie nous vous prsenterons le Ministre dtat, Ministre du plan et du dveloppement et aussi sa composition. Cette dernire nous amnera la description de la Direction Gnrale de la Population et du Renforcement des Capacits (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 quelle comporte.
10
Prsentation de la structure daccueil
il

1
I PRSENTATION DE LA STRUCTURE DACCUEIL

I.1 Prsentation du Ministre dtat, Ministre du Plan et Dveloppement
Le Ministre dtat, Ministre du Plan et du Dveloppement est le ministre charg de la gestion de tous les projets de dveloppement du pays. Occupant les dixime (10e), onzime (11e), sixime (6e) paliers de limmeuble alpha 2000 sis dans la commune du Plateau Abidjan, ce ministre qui stend aussi sur les immeubles prs de limmeuble alpha 2000, est lun des plus grands ministres compte tenu du nombre de fonctionnaires quil regorge et surtout pour le rle transversal quil assure. Depuis sa constitution du 23 janvier 2003, le Ministre dtat, Ministre du Plan et du Dveloppement se compose dun cabinet, de plusieurs directions gnrales, de services rattachs, de directions centrales et aussi de plusieurs services extrieurs (annexe 1).
I.1.1 Le cabinet
Dfini comme le personnel dun ministre, celui du Ministre dtat, Ministre du Plan et du Dveloppement 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 chargs dtudes un chef de secrtariat particulier
I.1.2 Les services rattachs

En plus de ses composantes, le cabinet du ministre est rattach plusieurs services qui sont : linspection gnrale (IG) dont les missions sont : le contrle du bon fonctionnement des structures du Ministre d tat, Ministre du Plan et du Dveloppement, le contrle et lvaluation des ralisations physiques et financires, lapplication des procdures admises dans le cadre de lexcution des actions relevant des attributions du ministre,
11

1
la ralisation des rapports daudits et lamlioration des capacits et des systmes de gestion. Le Bureau National de la Prospection (BNP), structure autonome qui a en charge la conduite de rflexions prospectives et stratgiques, ncessaires la dtermination de la vision stratgique du pays et lclairage de laction publique dans le temps et dans lespace. Le Service de la Communication, de la Documentation et des Archives (SCDA), qui est charg dassurer la conception, lorganisation et la mise en uvre de la politique de communication et de la documentation du Ministre dtat, Ministre du Plan et du Dveloppement. La Direction des Affaires Administratives et Financires (DAAF) qui est charge de : la gestion du personnel, la gestion des crdits, la gestion du matriel et des locaux.
I.1.3 Les directions

Parmi les directions composant ce ministre, nous pouvons citer : La Direction Gnrale du Plan (DGP) dont les rles sont : la conception et la mise en uvre de la politique, des stratgies et des objectifs en matire de planification ; llaboration des politiques sectorielles contribuant au soutien des secteurs crateurs de richesses et demplois ; llaboration des documents de synthse des actions de ltat en matire de planification, sur la base des options retenues en relation troite avec les services des ministres concerns ; llaboration du programme triennal dinvestissements publics et la participation la recherche, en liaison avec les services du ministre charg de lconomie et des finances, des ressources et des moyens de son financement ; le suivi et lanalyse de lexcution des investissements publics au re gard de la programmation triennale dinvestissements publics ; Les coordinations des projets et programmes de dveloppement dans lesquelles le Ministre dtat, Ministre du Plan et du Dveloppement intervient titre exclusif ou avec dautres ministres. Cette direction a en son sein 4 directions qui sont : la direction de la planification la direction du dveloppement la direction de la programmation des investissements publics la direction de la coordination, du contrle et de lvaluation
12

1
La Direction Gnrale du Dveloppement de lconomie Rgionale (DGDER) qui a les finalits suivantes : la structuration et la rgulation de lespace conomique national et rgional ; lappui la mise en valeur des potentialits conomiques, sociales, culturelles et institutionnelles pour un dveloppement rgional quilibr ; la conception, la prparation des orientations nationales ; la coordination des actions en matire de dveloppement et damnagement du territoire ; llaboration de la politique damnagement du territoire, en relation avec les services des ministres techniques et des collectivits territoriales, dans le respect de leur libre administration et des principes de la dcentralisation, ainsi que dautres acteurs, notamment le secteur priv, les organisations non gouvernementales et les partenaires au dveloppement. La Direction Gnrale du Dveloppement de lconomie Rgionale est compose de deux directions qui sont : la Direction du Dveloppement de lEconomie Rgionale ; la Direction de lAnalyse et de lAmnagement du Territoire. La Direction Gnrale de la Population et du Renforcement des Capacits (DGPRC).
I.2 Prsentation de la Direction Gnrale de la Population et du Renforcement de Capacits (DGPRC)

I.2.1 Les Missions
Les nombreuses missions de la Direction Gnrale de la Population et du Renforcement des Capacits (DGPRC) se prsentent comme suit : la formulation et la mise en uvre des politiques des populations ; le suivi et lvaluation de limpact des politiques sur la dynamique de la population ; la gestion de la base de donnes sur la population ; la formulation des politiques et stratgies de renforcement des capacits nationales particulirement en ce qui concerne la qualit des ressources humaines ; la coordination et le suivi des programmes et projets en matire de population.
I.2.2 La composition
Cette direction gnrale qui est plus que dynamique, comprend trois (03) directions qui se nomment : la Direction des Politiques de Population (DPP) ; la Direction du Renforcement des Capacits Nationales (DRCN) ; Prsentation de la structure daccueil
13

1
la Direction du Suivi-Evaluation (DSE).
I.3 Prsentation de la Direction du Suivi-Evaluation (DSE)

I.3.1 Les Missions
Cre par le dcret n 2006-03 du 23 janvier 2006, la Direction du Suivi-Evaluation, qui a t notre direction daccueil, a pour prrogatives de : coordonner et suivre les programmes et projets en matire de population ; suivre et valuer limpact des politiques sur la dynamique de la population ; laborer le rapport annuel sur ltat de la population ivoirienne.
I.3.2 La composition
Cette direction, garante du bon suivi des projets est constitu de deux (02) sousdirections, savoir : la Sous-direction du Suivi et de lvaluation des Politiques de Population (SDSEPP) la Sous-direction des Programmes et Projets de Population (SDPPP) qui pour mener bien ses missions est subdivise 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 passs, en cours ou prvus court, moyen et long terme concernant les populations en vue de recueillir des informations sur ces projets ; dfinir et/ou recueillir les indicateurs de suivi, de lvaluation des projets/programmes de concert avec la sous-direction du suivi, de lvaluation et de la politique de la population, avec les structures externes responsables des programmes et projets de population ; produire la documentation sur lensemble des applications informatiques pour la maintenance ou dautres 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 dvaluation sur la population ; coordonner les activits des projets ; superviser les activits ; suivre llaboration des rapports annuels des activits des projets. le Service Informatique.
14

1
I.4 Prsentation du Service Informatique

I.4.1 Les Missions
Ce service qui nous a prcisment reus se rsume en une quipe ayant un champ daction transversal et dont le travail sarticule autour des lments suivants : la rsolution des problmes relatifs au rseau ; la maintenance des applications internet ; la mise en place du site web ; la maintenance du matriel informatique ; le dveloppement dapplication de dveloppement ; la maintenance des applications de dveloppement. 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 dinformation, dducation et de conseil.
I.4.2 Linventaire des ressources informatiques

notre arrive dans la Direction du Suivi-Evaluation (DSE), nous avons remarqu que des investissements avaient t raliss pour acqurir des ressources informatiques qui sont :
les ressources matrielles

Type de matriel Ordinateurs de bureau Caractristiques Un processeur Intel Pentium 4 de frquence 3 GHz, un disque dur de 80 Go, une mmoire vive de 512 Mo, graveur DVD-CD, des outils multimdias Un processeur Intel Pentium M Centrino de frquence 1,8 GHz, un disque dur de 60 Go, une mmoire vive 512 Mo, graveur DVD-CD, outils multimdias et technologie Wifi Marque HP dc5100 MT Nombre 9
Ordinateur portable
TOSHIBA M70
Imprimante Imprimante Onduleur-stabilisateur 550 VA / 300 W, Input : 220-240 V ~50-60 HZ, 5A
HP Laserjet 1020 HP Office jet 6615(tout en un) LEADER 550
3 1 9
Tableau 1. Liste du matriel informatique Prsentation de la structure daccueil
15

1
les ressources logicielles : Les ordinateurs du parc informatique sont dots des logiciels suivants : le systme dexploitation Microsoft Windows Xp la suite bureautique Office 2003 Professionnel lantivirus Norton Antivirus 2005
I.4.3 Le rseau informatique

Dabord, il convient de mentionner que le rseau informatique (figure 1) du Ministre dEtat, Ministre du Plan et du Dveloppement a t mis en place par la Socit Nationale de Dveloppement Informatique (SNDI), qui en assure ladministration et la maintenance. Les directions situes dans limmeuble Alpha 2000, fonctionnent dans un intranet gr par un routeur. Et cest ce dernier qui sert de passerelle, entre le rseau informatique des directions de limmeuble Alpha 2000, et le rseau de la SNDI, ouvert sur Internet. Une description synthtise du rseau peut se prsenter 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 ladresse 10.6.8.190 un serveur DNS, avec la mme adresse ; un pare-feu. La communication entre le routeur (qui est le nud central des machines des directions de limmeuble) et le rseau de la SNDI est rgie par des antennes radio. Les signaux parviennent au routeur via le modem, et vice versa. Mais, il est souligner que lintranet des directions de limmeuble Alpha 2000, nest pas directement en liaison avec le rseau de la SNDI. Sa liaison est avec lintranet de limmeuble CIAM, o se situe le cabinet ministriel, puis partir de limmeuble CIAM, la connexion est tablie avec la SNDI.
16

1
Figure 1 : rseau informatique du ministre
17

1
ETUDE PREALABLE
Point de dpart de toute analyse, ltude pralable savre trs importante puisquelle permet avant dentreprendre un projet, dlaborer globalement diffrentes solutions et den valuer les consquences. Par ailleurs, elle envoie cerner le processus de fonctionnement du domaine, dcrire lexistant et faire ressortir les points forts et points faibles du systme. Une fois ces avantages et inconvnients connus, ltude pralable nous envoie proposer des solutions palliant les diffrents problmes rencontrs et en choisir la plus adapte la structure daccueil.
18
Etude pralable

1
II ETUDE PREALABE
II.1 Prsentation du projet
Avant toute proposition ou tude, il serait opportun de prsenter la situation ayant motiv notre thme. De ce fait, nous allons dcrire son contexte, exposer ses objectifs et avancer les rsultats attendus lissu de ce projet.
II.1.1 Contexte et justification

Avec lavnement des programmes dajustements structurels (PAS), un ensemble de nouvelles priorits se sont dfinies auprs de notre gouvernement. Parmi elles, nous pouvons citer une relance conomique rapide, une rduction des dpenses du gouvernement et surtout un suivi et une valuation des projets afin de rationaliser ses dpenses et laide extrieure. Et cest dans cet lan que fut cr le 23 janvier 2006, la Direction du Suivi-Evaluation (DSE). Afin de mieux rpondre ses objectifs, cette direction en collaboration avec ses partenaires a convenu de disposer dun ensemble doutils intgrs et efficients pour le suivi et lvaluation des projets de la population ivoirienne. Cest ainsi quil a t soumis notre rflexion le thme suivant : ralisation et scurisation dun cadre de gestion de projets .
II.1.2 Objectifs
Ce thme a pour principaux buts : la conception et la ralisation dune base de donnes relative aux projets et programmes dj raliss et en-cours de ralisation ; la ralisation doutils permettant de prendre en compte des projets et/ou des programmes court, moyen et long terme raliser
II.1.3 Rsultats attendus

Les diffrents rsultats attendus sont repartis travers les objectifs prcdemment dfinis. Dans cet ordre ide : La base de donnes doit : contenir toutes les donnes relatives aux projets et programmes raliss et en-cours de ralisation ; classifier les projets et programmes selon notamment les secteurs, les facteurs, les indicateurs ;
19
Etude pralable

1
permettre de dcrire les projets et programmes en prcisant notamment les bnficiaires, les objectifs, le mode de financement, les partenaires, et autres lments utiles ;
Les outils doivent permettre : dextraire des donnes de la base de connaissances ; denrichir la base de connaissances de faon rgulire par toutes les parties prenantes des projets et programmes afin de garantir une cohrence et une adquation avec la ralit du terrain ; aux oprateurs conomiques et aux partenaires de consulter la base de connaissances.
II.2 Mthodes danalyse et de conception

La conception dun systme dinformation nest pas vidente, car il faut rflchir lensemble de lorganisation que lon doit mettre en place. Do la ncessit dune mthode danalyse et de conception permettant de mettre en place un modle sur lequel lon va sappuyer. Il est noter quune mthode danalyse et de conception est la runion dune dmarche et dun formalisme. Son objectif est de permettre de formaliser les tapes prliminaires du dveloppement dun systme afin de rendre ce dveloppement plus fidle aux besoins du client. Pour ce faire, lon part dun nonc informel (le besoin tel quil est exprim par le client, complt par des recherches dinformations auprs des experts du domaine fonctionnel, par exemple les futurs utilisateurs dun logiciel), ainsi que de lanalyse de lexistant ventuel (cest--dire la manire dont les processus traiter par le systme se droulent actuellement chez le client). La phase danalyse permet de lister les rsultats attendus, en termes de fonctionnalits, de performance, de robustesse, de maintenance, de scurit, dextensibilit. Tandis que, la phase de conception permet de dcrire de manire non ambigu, le plus souvent en utilisant un langage de modlisation, le fonctionnement futur du systme, afin den faciliter la ralisation. Nous distinguons, de nos jours, une multitude de mthodes danalyse et de conception telles que : Object Modeling Technique (OMT) Booch Object Oriented Software Engineering (OOSE) Structured Analysis and Design Technique (SADT) la Mthode dtude et de Ralisation Informatique par Sous-ensemble (MERISE) le couple Unified Processus (UP) et Unified Modeling Language (UML)
Toutefois, ce ne sont que les deux dernires mthodes qui seront tudies puisquelles sont les plus utilises et les plus abouties.
20
Etude pralable

1
II.2.1 La Mthode dtude et de Ralisation Informatique par Sous-ensemble (MERISE)

MERISE est une mthode de conception, de dveloppement et de ralisation de projets informatiques. Le but de cette mthode est d'arriver concevoir un systme d'information. La mthode MERISE est base sur la sparation des donnes et des traitements effectuer en plusieurs modles conceptuels et physiques. Cette sparation des donnes et des traitements assure une longvit au modle. En effet, l'agencement des donnes n'a pas tre souvent remani, tandis que les traitements le sont plus frquemment. La mthode MERISE date de 1978-1979, et fait suite une consultation nationale lance en 1977 par le ministre de l'Industrie dans le but de choisir des socits de conseil en informatique afin de dfinir une mthode de conception de systmes d'information. Les deux principales socits ayant mis au point cette mthode sont le CTI (Centre Technique d'Informatique) charg de grer le projet, et le CETE (Centre d'tudes Techniques de l'quipement) implant Aix-en-Provence. Par ailleurs, cette mthode spcifiquement franaise, a demble connu la concurrence internationale de mthodes anglo-saxonnes telles que SDM/S ou Axial. Elle a ensuite cherch sadapter aux volutions rapides des technologies de linformatique avec MER ISE/objet, puis MERISE/2 destine sadapter au client-serveur et la vision objet. En outre, la mthode MERISE reprsente le systme dinformation suivant 3 approches et 4 niveaux. II.2.1.2 Les concepts Pour tudier et dvelopper linformatique dune entreprise ou de tout type dorganisme, il est ncessaire de connatre ses changes internes et avec lextrieur, comment ragit-elle une sollicitation externe et quelle est la structure des informations quelle utilise. Partant de ce constat, la mthode MERISE dcrit cette connaissance sous forme de trois approches : Communication Les changes ou la communication sont les flux entre systmes, notamment des flux dinformations ou messages. Traitement Les traitements des messages, flux dinformations, dcrivent les tches effectuer la rception ou pour lmission dun flux dinformations. Donnes La structure de mmorisation des informations est reprsente sous une forme qui permet un passage ais vers les enregistrements informatiques. II.2.1.2 Les niveaux Linformatique consiste mettre disposition de lutilisateur des moyens ou des outils de gestion informatique. Avant de spcifier les moyens informatiques, il est ncessaire de
21
Etude pralable

1
dfinir le travail de ce ou de ces utilisateurs finals, de dfinir lorganisation, lanalyse des objectifs et des fonctions majeures de lentreprise doit tre mene. Ainsi, linformatisation est conue en fonction de lorganisation et lorganisation en fonction des objectifs atteindre. Or lenchainement de linformatique, de lorganisation et de la fonction ncessite un dcoupage en niveaux de la dmarche dinformatisation. Ces niveaux sont : Le niveau conceptuel Cest le niveau le plus invariant, il correspond aux finalits de lentreprise. Il sagit de dcrire le Quoi en faisant abstraction des contraintes dorganisation et techniques. Les modles utiliss pour la description conceptuelle du systme dinformation sont : le Modle Conceptuel de Communication (MCC) qui reprsente les changes de flux de produits, dnergie, de personne, de valeur ou dinformation entre systme. le Modle Conceptuel de Donnes (MCD) qui est une description des donnes et des relations et est ralis laide des trois concepts du formalisme entitassociation : entit (ou objet) relation proprits. le Modle Conceptuel des Traitements (MCT) qui est la description de la partie dynamique du systme dinformation et est ralis laide des concepts suivants : vnements/rsultat synchronisation opration - processus. Le niveau organisationnel Les choix dorganisation sont pris en compte ce niveau comme la rpartition des traitements entre lhomme et la machine, le mode de fonctionnement (temps rel ou diffr) et laffectation des donnes et des traitements. Ce niveau rpond aux questions Qui fait Quoi et O Trois modles sont associs ce niveau : le Modle Organisationnel de Communication (MOC) qui reprsente les changes qui ont lieu entre les sites de traitements et de donnes. Il ne concerne que les communications entre sites. Il nexiste pas sil nexiste quun site ; le Modle Organisationnel de Donnes (MOD) qui reprend le formalisme utilis dans le MCD et qui reprsente aussi lensemble des donnes par type de site organisationnel ; le Modle Organisationnel des Traitements (MOT) qui reprsente par procdures les phases et les tches excutes par chaque poste de travail. Le niveau logique Ce niveau dcrit le systme dinformation au plan informatique sans choix de matriel ou de logiciel prcis. Nous avons trois modles relis ce niveau : le Modle Logique de Communication (MLC) qui est une reprsentation des messages changs entre site et base de donnes. Il provient du MLD et de lutilisation des outils en temps diffr. le Modle Logique des Donnes (MLD) qui est une reprsentation des donnes dcrit dans le MCD en tenant compte du type de base de donnes.
22
Etude pralable

1
le Modle Logique des Traitements (MLT) qui permet de dcrire la conception technique qui traite principalement de la structuration en units de traitement de type temps rel ou de type temps diffr.
Le niveau physique Ce niveau dcrit le rsultat de la mthode ou linformatisation finale. Il dpend des logiciels de dveloppement ncessaires la programmation et la manipulation des donnes. La mthode laisse place aux normes du rel. Nous avons encore trois modles lis : le Modle Physique des Communication (MPC) qui comprend la tlmatique entre sites informatiques. le Modle Physique des Donnes (MPD) qui nest quun modle de la base de donnes. le Modle Physique des Traitements (MPT) qui comprend les programmes techniques et leur environnement dexploitation, moniteur temps rel, traitement par lot, temps partag. II.2.1.3 La dmarche
La mthode MERISE propose une dmarche de construction de systme dinformation en 6 tapes (figure 2) : le schma directeur : dfinition de la politique de lentreprise ltude pralable : analyse de lexistant qui conduit des variantes ltude dtaille : tude approfondie de la solution choisie par la direction ltude technique : tude purement informatique, seuls les informaticiens interviennent la ralisation : programmation proprement dite la maintenance : suivi et volution.
Cette dmarche (figure 2) sappuie sur un cycle de vie en cascade qui date de 1970 et est luvre de Royce. Il sagit dun mode linaire o toute tape est cense navoir de rtroaction que sur ltape qui la prcde. Lactivit dune tape se ralise avec les rsultats fournis par ltape prcdente ; ainsi, chaque tape sert de contrle du travail effectu lors de ltape prcdente. Lutilisateur attend le droulement complet du cycle de vie du logiciel pour vrifier, lors de la dernire tape, ladquation entre ses exigences et le produit livr.
23
Etude pralable

1
Figure 2 : la dmarche MERISE En 1978, MERISE introduisit les prmices de diffrenciation entre dcoupage temporel du cycle de vie et activits menes chaque tape; cette diffrenciation a t illustre par la courbe du soleil (figure 3). Sur laxe horizontal se trouve le cycle de vie sous forme dtat du systme dinformation et sur laxe vertical, le cycle dabstraction, se trouve la reprsentation du systme. Dans cet espace 2 dimensions sont reprsentes les diffrentes activits.
Figure 3 : la courbe du soleil
24
Etude pralable

1
II.2.2 Le processus unifi

Le processus unifi (en anglais Unified Process) est une mthode gnrique de dveloppement de logiciel. Il est gnrique puisquil est ncessaire de ladapter au contexte du projet, de lquipe, du domaine et/ou de lorganisation (exemple R.UP ou X.UP ou 2T.UP). Cette mthode regroupe les activits mener pour transformer les besoins dun utilisateur en systme logiciel. De plus, le processus unifi : est base de composants, utilise le langage UML, est pilot par les cas dutilisation, est centr sur larchitecture, est itratif et incrmental.
En outre, le langage de modlisation UML quil utilise nest quun langage graphique de modlisation des donnes et des traitements. Cest une formalisation trs aboutie et nonpropritaire de la modlisation objet. Depuis novembre 2007, sa version 2.1.2 est diffuse par lObject Management Group (OMG). Ce langage de modlisation est laccomplissement de la fusion des prcdents langages de modlisation objet Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML qui est prsent un standard dfini par lOMG, nest pas une mthode, mais seulement un langage graphique qui permet de reprsenter, de communiquer les divers aspects dun systme dinformation. Compte tenu du fait, quil soit impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre systme complexe, UML propose des vues partielles dont la juxtaposition donnera une ide utilisable en pratique sans risque derreur grave. Ainsi UML 2.0 comporte treize diagrammes reprsentant autant de vues distinctes pour reprsenter les concepts particuliers du systme dexploitation. II.2.2.1 Les diagrammes Nous dnotons depuis sa version 2.0, treize diagrammes qui sont dpendants hirarchiquement et complmentaires : Les diagrammes structurels ou diagrammes statiques le diagramme de classes : il reprsente les classes intervenant dans le systme ; le diagramme dobjets : il sert reprsenter les instances de classes (objets) utilises dans le systme ; le diagramme de composants : il permet de montrer les composants du systme dun point de vue physique, tel quils sont mis en uvre ; le diagramme de dploiement : il sert reprsenter les lments matriels (ordinateurs, priphriques, rseaux, systme de stockage..) et la manire dont les
25
Etude pralable

1
composants du systme sont rpartis sur ces lments matriels et interagissent avec eux ; le diagramme de paquetages : un paquetage tant un conteneur logique permettant de regrouper et dorganiser les lments dans le modle UML, le diagramme de paquetages sert reprsenter les dpendances entre paquetages, c'est--dire les dpendances entre ensembles de dfinitions ; le diagramme de structure composite : il permet de dcrire sous forme de boite blanche les relations entre les composants dune classe.
Les diagrammes comportementaux le diagramme des cas dutilisation : il permet didentifier les possibilits dinteraction entre le systme et les acteurs (intervenants extrieurs au systme), c'est--dire toutes les fonctionnalits que doit fournir le systme; le diagramme dtats transition : il permet de dcrire sous forme de machine tats finis le comportement du systme ou de ses composants ; le diagramme dactivit : il permet de dcrire sous forme de flux ou denchanement dactivits le comportement du systme ou de ses composants ; les diagrammes dinteractions ou diagrammes dynamiques le diagramme de squence : il est la reprsentation squentielle du droulement des traitements et des interactions entre les lments du systme et/ou de ses acteurs ; le diagramme de communication : il est la reprsentation simplifie dun diagramme de squence se concentrant sur les changes de messages entre les objets ; le diagramme global dinteraction : il permet de dcrire les enchanements possibles entre les scnarios pralablement identifis sous forme de diagrammes de squences (variante du diagramme dactivit) ; le diagramme de temps : il permet de dcrire les variations dune donne au cours du temps II.2.2.2 Les vues Pour mettre en uvre UML, lon peut considrer diffrentes vues (figure 4) qui peuvent se superposer pour collaborer la dfinition du systme. Nous pouvons citer : la vue des cas dutilisation : cest la description du modle vue par les acteurs du systme. Elle correspond aux besoins attendus par chaque acteur (cest le QUOI et le QUI) ; la vue logique : cest la dfinition du systme vu de lintrieur. Elle explique comment peuvent tre satisfaits les besoins des acteurs (cest le COMMENT) ; la vue dimplmentation : cette vue dfinit les dpendances entre les modules ;
26
Etude pralable

1
la vue des processus : cest la vue temporelle et technique qui met en uvre les notions de tches concurrentes, stimuli, contrle, synchronisation ; la vue de dploiement : cette vue dcrit la position gographique et larchitecture physique de chaque lment du systme (cest le OU).
Vue dimplmentation Vues des cas dutilisation Vue du dploiement
Vue Logique
Vue des processus
Figure 4 : les vues dUML
II.2.2.3 La dmarche Le processus unifi est organis autour de quatre phases (figure 5) dont : linception : elle permet de dterminer les limites du projet, ce qui doit tre ralis et ce qui ne doit pas tre ralis. Pour cela, les besoins des utilisateurs sont recueillis et exprims dans les cas dutilisation du systme. Lensemble des cas dutilisation constitue les spcifications du systme. partir des cas dutilisation, une architecture candidate est propose. En se basant sur de ce plan darchitecture, les cots sont valus, un plan de travail est ralis, et les principaux risques rpertoris. Enfin, lenvironnement est mis en place. llaboration : elle permet de stabiliser et de raffiner larchitecture. Le plan de travail de la phase de construction est prcis par un plan ditrations. En raffinant larchitecture, les principaux composants sont identifis. la construction : elle applique le plan ditration dfini dans la phase prcdente, et consiste surtout optimiser la gestion des ressources. Afin de rduire les cots de dveloppement et amliorer la qualit, le processus est optimis. la transition : elle consiste dployer, tester et valider. Une grosse partie de la dernire phase consiste accompagner lutilisateur final par la rdaction de documentation et la mise en place de sessions de formation.
27
Etude pralable

1
Figure 5 : les diffrentes phases
Le processus unifi propose aussi des activits (figure 6) qui se repartissent dans les diffrentes phases prcdemment cites. Nous avons : la modlisation mtier Lactivit de modlisation mtier permet de mieux comprendre la structure et la dynamique de lorganisation. Il est alors plus ais de comprendre un problme pos et de proposer la meilleure solution dans le contexte de lorganisation cliente. En outre, cette activit peut donner lieu la ralisation dun glossaire des termes mtiers. Un livrable important de cette activit est la cartographie des processus mtier de lorganisation cliente. Coteuse raliser, car elle tient compte de lensemble du systme dinformation du client, elle permet dacclrer la comprhension dun problme pos en extrayant les besoins utilisateurs et en exprimant toutes les dpendances fonctionnelles. le recueil de besoins Grce lanalyse mtier, on comprend les rouages du systme complet dune organisation. Lorsquil sagit de dvelopper une application sur une partie du systme dinformation, il convient de cibler les besoins des utilisateurs et des clients au moyen dune srie dinterviews. Lensemble des parties prenantes du projet , matrise duvre et matrise douvrage, est acteur de cette activit. Lactivit de recueil et dexpression des besoins dfinit ce que doit faire le systme. Lanalyste utilise les cas dutilisation pour schmatiser les besoins, et structurer les documents de spcifications fonctionnelles. Les cas dutilisation sont en effet dcomposs en
28
Etude pralable

1
scnarios dusage du systme, dans lesquels lutilisateur explique ce quil fait laide du systme et ses interactions avec le systme. Un maquettage est ralisable pour mieux immerger lutilisateur dans le futur systme. Une fois les limites fonctionnelles poses, le projet est planifi et une prvision des cots est ralise. lanalyse et conception Cette activit consiste transformer les besoins utilisateurs en modles UML, donc faire une analyse objet. Les principaux livrables de cette activit sont les modles danalyse et de conception. Lanalyse objet est neutre vis--vis dune technologie. La conception tient compte des exigences non fonctionnelles et des choix technologiques. Le systme est analys et rsulte en une proposition darchitecture. Cette architecture est dcoupe en composants. Implmentation Cette activit consiste concevoir le systme par composants. Cest--dire que le systme est dvelopp par morceaux dpendant les uns des autres. Ainsi, il est possible doptimiser lutilisation des ressources selon leurs expertises. Les dcoupages fonctionnels et en couches sont indispensables pour cette activit. Il est tout fait envisageable de retoucher les modles danalyse et de conception ce stade. De cette faon, les futurs dveloppements bnficieront de lexprience des travaux prcdents sur le mme type darchitecture. Test toutes les tapes, diffrents types de test sont raliss. Dans le cycle de dveloppement itratif, chaque activit doit tre rgulirement valide, chaque point de contrle dfini au pralable et nomm : jalon. Dploiement Lactivit de dploiement consiste dployer les dveloppements une fois raliss. Elle peut tre ralise trs tt dans le processus dans une sous-activit de prototypage dont lobjectif est de valider larchitecture physique, et les choix technologiques. Configuration/gestion du changement, gestion de projet et gestion de lenvironnement Ces activits sont indispensables au droulement dun cycle de dveloppement dun systme 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 lutilisateur lui-mme. La gestion de projet consiste grer les ressources et ordonnancer lensemble du processus. Enfin, la gestion de lenvironnement consiste mettre en place tout ce qui permet aux diffrents rles de raliser au mieux leurs activits.
29
Etude pralable

1
Figure 6 : les activits
Comme prcdemment signal, le processus unifi sappuie sur un cycle de vie itratif et incrmental (figure 7). Ce qui signifie que le dveloppement sorganise en une srie de mini projets courts, de dure fixe, nomms itrations. Le rsultat de chacune des itrations est un systme test, intgr et excutable. Chacune de ces itrations comprend ses propres activits : analyse des besoins, conception, implmentation, tests et dploiement.
Figure 7 : le dveloppement itratif et incrmental
30
Etude pralable

1
II.2.3 Choix dune mthode

Aprs avoir pass en revue, les diffrentes prsentations des mthodes tudies et en tenant compte des spcifications de notre projet, nous avons orient notre choix sur le processus unifi pour les raisons suivantes : Une meilleure gestion des changements Grce aux diffrents livrables produits la fin des itrations, le processus unifi nous permet dajuster les choix en termes darchitecture ou de conception graphique par exemple trs tt dans le processus et non aprs que ces derniers aient t compltement raliss comme en MERISE. Une rduction des risques En nous basant sur les propos de Peter F. Drucker qui stipule que le risque est inhrent lengagement de ressources actuelles vers des attentes futures (figure 8), nous pouvons dire que le processus unifi rduit considrablement les risques. En effet, le systme se construisant par tapes travers des livrables, elle nous permet de dtecter les risques plus tt et aussi les ressources mobilises sont minimes par rapport ceux occasionns par MERISE. Cette dernire qui prsente le produit au client quune fois termine, entraine une grande utilisation de ressources qui peut savrer dangereuse si le produit livr ne correspond pas aux exigences du client.
Figure 8 : les risques Un contrle perptuel de la qualit Contrairement MERISE qui ne juge de la qualit quune fois le produit fini, le processus unifi vrifie chaque itration la qualit du livrable travers des tests de fonctionnement.
31
Etude pralable

1
Une mise en confiance du client Le processus unifi permet de rassurer le client, car celui-ci peut voir concrtement la progression du projet travers la manipulation ou lexcution de cas dutilisation rels de son produit. Alors quavec MERISE, il pourra tester son produit quune fois termine et aprs avoir attendu un long moment. Une participation active du client Le processus unifi donne loccasion au client de visualiser le rsultat des itrations et donc dexprimer les ajustements dsirs au fur et mesure que le projet avance, et non pas uniquement la fin du projet comme en MERISE. Un meilleur dveloppement Le processus unifi permet aux dveloppeurs de demeurer concentrs sur les fonctionnalits qui font partie de litration courante au lieu de rflchir sur lensemble des fonctionnalits du systme. Ainsi, tout changement, ou correction qui sajoute la liste des tches est planifi dans les itrations subsquentes. Comme la dure dune itration est relativement courte, les clients et chefs de projets acceptent gnralement ce dlai.
Toutefois, le processus unifi tant une mthode gnrique puisquelle ne dfinit quun certain nombre de critres de dveloppement, plusieurs dclinaisons personnalises selon les besoins ont t labores. Ainsi, nous notons parmi les plus connus : le Rational Unified Process (RUP), lExtrem Unified Process (XUP) et enfin le Two Tracks Unified Process (2TUP). Cette dernire dclinaison qui est luvre de la socit Valtech a t celle q ui a t adopte tout au long du projet puisque non seulement elle prend en compte les alas et contraintes lies aux changements perptuels et rapides des systmes dinformations des entreprises. Mais aussi parce que laxiome fondateur du 2TUP a t le constat que toute volution impose au systme dinformation peut se dcomposer et se traiter paralllement, suivant un axe fonctionnel et un axe technique. lissue des volutions du modle fonctionnel et de larchitecture technique, la ralisation du systme consiste fusionner les rsultats de ces deux branches du processus.
Description Instanciation dUP par Rational Software (IBM). Le RUP est la fois une mthodologie et un outil prt l'emploi (documents types partags dans un rfrentiel Web) Cible des projets de plus de 10 personnes Avantages Itratif Spcifie le dialogue entre les diffrents intervenants du projet : les livrables, les plans de travail, les prototypes Propose des modles de documents, et des canevas pour des projets types Inconvnients Coteux personnaliser Trs ax processus, au dtriment du dveloppement : peu de place pour le code et la technologie
RUP Rational Unified Process
32
Etude pralable

1
XUP eXtrem Programming Unified Process
Instanciation hybride intgrant UP avec lExtrem Programming Ensemble des meilleures pratiques de dveloppement (travail en quipes, transfert de comptences) Cible des projets de moins de 10 personnes
Itratif Simple mettre en uvre Fait une large place aux aspects techniques : prototypes, rgles de dveloppement, tests Innovant: programmation en duo, kick-off matinal debout
Ne couvre pas les phases en amont et en aval au dveloppement : capture des besoins, support, maintenance, tests d'intgration Elude la phase d'analyse, si bien qu'on puisse dpenser son nergie faire et dfaire Assez, confus dans sa mise en uvre: quels intervenants, quels livrables ? Plutt superficiel sur les phases situes en amont et en aval du dveloppement : capture des besoins, support, maintenance, gestion du changement Ne propose pas de documents types
2TUP Two Tracks Unified Process
Instanciation dUP propos par Valtech prenant en compte les alas et contraintes lies aux changements perptuels et rapides des SI des entreprises. S'articule autour de l'architecture Propose un cycle de dveloppement en Y Cible des projets de toutes tailles
Itratif Fait une large place la technologie et la gestion du risque Dfinit les profils des intervenants, les livrables, les plans de travail, les prototypes
Tableau 2 : les diffrentes dclinaisons du processus unifi
II.3 Etude de lexistant

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 dtudier les lments existants dans le systme actuel de gestion de projets et de faire par la suite quelques critiques.
II.3.1 Description de lexistant

Tout au long de cette partie, nous avons utilis les modles dUML pour mieux reprsenter les donnes et les traitements que nous avons trouvs en place. Mais avant de commencer modliser, une description du processus de gestion des projets obtenue travers des interviews et de lexamen des documents utiliss se rvle indispensable.
33
Etude pralable

1
II.3.1.1 Description du processus de gestion des projets Ds quun organisme dcide de travailler avec un gouvernement, il tudie avec celui ci les diffrentes priorits nationales. la sortie de cette tude, les deux parties saccordent sur un programme stendant sur une priode donne, et visant pallier les problmes que rencontre le pays. Le programme adopt se divise en un ou plusieurs sous-programmes pour mieux rpondre ses objectifs. Chaque sous-programme se voit attribuer un point focal li un organisme. Non seulement, ces sous-programmes dfinissent chacun des produits qui ne sont que les diffrents buts, mais se dcomposent encore en plusieurs projets qui tendent raliser ces produits. Pour chaque projet, des stratgies sont dtermines et elles fixent des rsultats que devront atteindre les diffrentes activits du projet. Les activits en question sont caractrises par des indicateurs, se ralisent dans des localits et sont budgtises. Dans leurs excutions, elles entrainent des dcaissements proportionnels aux diffrentes contributions apportes par les organismes et les ministres. Dans un souci de bonne organisation, une direction dpendant dun ministre 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 nomms slectionnent les parties responsables de lexcution des activits de leurs projets. chaque fin de trimestre, lavance de chaque projet est relate dans un rapport qui signale aussi les diffrents problmes rencontrs dans le droulement des activits. Les problmes mentionns suscitent des recommandations qui conduisent lexcution d'autres activits. De plus, la fin de lanne, des rapports dcrivant le droulement des projets son t prsents. Pour les besoins de lvaluation et du suivi, un contrleur vrifie les diffrents indicateurs dune activit pour la valider ou non. II.3.1.2 Le diagramme de cas dutilisation Ce diagramme dont la principale utilit est de reprsenter la structure des grandes fonctionnalits ncessaires aux utilisateurs du systme nous a permis ici de modliser les diffrents besoins des utilisateurs par rapport au systme actuel (figure 9). II.3.1.2.1 les concepts Compte tenu du fait que nous avons eu recours au formalisme dUML pour mieux dcrire notre existant, il nous est apparu judicieux de prsenter les diffrents concepts qui rentrent en ligne de compte : Un acteur est lidalisation dun rle jou par une personne externe, un processus ou une chose qui interagit avec un systme. Il se reprsente par un petit bonhomme (figure 9) avec son nom (son rle) inscrit en dessous.
34
Etude pralable

1
Un cas dutilisation est une unit cohrente dune fonctionnalit visible de lextrieur. Il ralise un service de bout en bout, avec un dclenchement, un droulement et une fin, pour lacteur qui linitie. Un cas dutilisation modlise donc un service rendu par le problme, sans imposer le mode de ralisation de ce service. Il est reprsent par une ellipse (figure 9) contenant le nom du cas et optionnellement, audessus du nom un strotype. Une Relation dassociation est chemin de communication entre un acteur et un cas dutilisation. Elle est reprsente par un trait continu (figure 9). Un cas dutilisation interne est un cas dutilisation (figure 9) qui nest pas directement reli un acteur. Une relation dinclusion dun cas dutilisation A par un cas dutilisation B signifie quune instance de A contient le comportement dcrit dans B (figure 9). Une telle relation est symbolise par une flche avec un trait pointill (figure 9). Une relation de gnralisation : un acteur A est une gnralisation dun acteur C si lacteur A peut tre substitu par lacteur C. Dans ce cas, tous les cas dutilisation accessibles A le sont aussi C, mais linverse nest pas vrai. Le symbole utilis pour la gnralisation est une flche avec un trait plein dont la pointe est un triangle ferm dsignant le cas le plus gnral (figure 9).
Figure 9 : concepts du diagramme de cas dutilisation
35
Etude pralable

1
II.3.1.2.2 la reprsentation du diagramme de cas dutilisation
Figure 10 : systme actuel - diagramme de cas dutilisation
36
Etude pralable

1
II.3.1.3 Les descriptions textuelles Ces descriptions nous ont permis dexpliciter les cas dutilisations du systme actuel. Cas dutilisation : mettre jour une activit
Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Mettre jour une activit Responsable dactivit charg dtude, SIGPOD Des activits ont t enregistres Scnario nominal 1 Le responsable dactivit saisit les informations sur lactivit quil veut renseigner 2 Le responsable dactivit prsente le document 3 Le charg dtude vrifie le document 4 Le SIGPOD sauvegarde le document Scnario alternatif Point 3 : le document nest 1 Le charg dtude prsente le document pas conforme en mettant en surbrillance les erreurs 2 Reprise au point 1 Des activits ont t mises jour
Post conditions
Tableau 3 : systme actuel - mettre jour une activit Cas dutilisation : valider un indicateur
Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Valider un indicateur Contrleur charg dtude, SIGPOD Des activits et des indicateurs ont t sauvegards Scnario nominal 1 Le contrleur saisit les informations concernant lindicateur quil veut valider 2 Le contrle prsente le document 3 Le charg dtude vrifie le document 4 Le SIGPOD sauvegarde le document Scnario alternatif Point 3: le document nest 1 Le charg dtude prsente le document pas conforme en mettant en surbrillance les erreurs 2 Reprise au point 1 Des indicateurs ont t mis jour
Post conditions
Tableau 4 : systme actuel valider un indicateur
37
Etude pralable

1
Cas dutilisation : mettre jour des informations

Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Mettre jour des informations Charg dtude SIGPOD Le systme est disponible Scnario nominal 1 Le charg dtude saisit les informations quil veut renseigner 2 Le charg dtude vrifie le document 3 Le SIGPOD sauvegarde le document Scnario alternatif Point 3: le document nest 1 Le charg dtude prsente le document pas conforme en mettant en surbrillance les erreurs 2 Reprise au point 1 Des informations ont t mises jour
Post conditions
Tableau 5 : systme actuel - mettre jour des informations Cas dutilisation : consulter des informations
Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Consulter les informations Tierce personne Charg dtude Des informations sont disponibles Scnario nominal 1 La personne demande les informations quil souhaite 2 Le charg dtude recherche les informations 3 Le charg dtude ralise une copie des informations 4 Le charg dtude prsente les informations 5 La personne prend connaissance des informations Des informations sont disponibles
Post conditions
Tableau 6 : systme actuel - consulter des informations
II.3.1.4 Les diagrammes dactivits Ces diagrammes qui permettent de mettre laccent sur les traitements nous ont servi reprsenter les diffrentes procdures existantes dans le systme actuel.
II.3.1.4.1 Les concepts En vue dune meilleure comprhension des diagrammes dactivits, nous allons procder une dfinition des principaux lments qui concernent le diagramme dactivit.
38
Etude pralable

1
Une partition souvent appele couloir ou ligne deau (swimlane) du fait de leur notation, permet dorganiser les nuds dactivits dans un diagramme dactivits en oprant des regroupements. Graphiquement, les partitions sont dlimites par des lignes continues. Il sagit gnralement de lignes verticales, comme sur la figure 1 1, mais elles peuvent tre horizontales ou mme courbes. Un nud initial est un nud de contrle partir duquel le flot dbute lorsque lactivit enveloppante est invoque. Une activit peut avoir plusieurs nuds initiaux. Un nud initial possde un arc sortant et pas darc entrant. Graphiquement, un nud initial est reprsent par un petit cercle plein (figure 11). Un nud final est un nud de contrle ne possdant quun ou plusieurs arcs entrants et aucun sortant. Il est reprsent par un petit cercle qui contient une croix (figure 11). Un nud de dcision est un nud de contrle qui permet de faire un choix entre plusieurs flots sortants. Il possde un arc entrant et plusieurs arcs sortants. Ces derniers sont gnralement accompagns de conditions de garde pour conditionner le choix. Graphiquement, on reprsente un nud de dcision par un losange (figure 11) ; Un nud daction est un nud dactivit excutable qui constitue lunit fondamentale de fonctionnement excutable dans une activit. Un nud daction doit avoir au moins un arc entrant. Graphiquement, un nud daction est reprsent par un rectangle aux coins arrondis (figure 11). Une transition marque le passage dun nud vers un autre. Graphiquement, une transition est reprsente par une flche en trait plein et connecte les nuds entre eux (figure 11).
39
Etude pralable

1
Figure 11 : concepts du diagramme dactivits II.3.1.4.2 Les reprsentations des diagrammes dactivits Cas dutilisation : mettre jour une activit
Figure 12 : systme actuel mise jour dune activit
40
Etude pralable

1
Cas dutilisation : valider un indicateur
Figure 13 : systme actuel validation dun indicateur
Cas dutilisation : mettre jour les informations
Figure 14 : systme actuel mise jour dinformations
41
Etude pralable

1
Cas dutilisation : consulter des informations
Figure 15 : systme actuel consultation dinformations II.3.1.5 Les diagrammes de classes Principalement utiliss pour reprsenter la structure interne dun systme dinformation, nous les avons utiliss pour modliser larchitecture conceptuelle du systme actuel. Cependant compte tenu du grand nombre de classes du systme nous avons dcoup notre diagramme de classes en deux diagrammes axs lun sur les projets et lautre sur les activits. II.3.1.5.1 Les concepts Les concepts propres aux diagrammes de classes doivent tre dfinis pour permettre une bonne lecture des diagrammes de classes qui seront reprsentes. Une classe est la description abstraite dun ensemble dobjets de mme structure et de mme comportement extrait du monde modliser. Elle est reprsente par un rectangle divis en un ou cinq compartiments (figure 16). Une proprit est une donne lmentaire qui sert caractriser les classes et les relations. Une mthode est une opration autorise sur les objets dune classe. Une association est une relation entre deux classes ou plus qui dcrit les connexions structurelles entre leurs instances. Graphiquement, elle est reprsente par un trait continu reliant les classes participantes (figure 16).
42
Etude pralable

1
Une multiplicit exprime le nombre minimum et maximum dobjets dune classe qui peuvent tre relis des objets dune autre classe. la gnralisation dcrit une relation entre une classe gnrale et une classe spcialise. La classe spcialise est intgralement cohrente avec la classe de base, mais comporte des informations supplmentaires. Un objet de la classe spcialise peut tre utilis partout o un objet de la classe de base est autoris. Graphiquement, elle est matrialise par un trait plein dont la pointe est un triangle ferm dsignant la classe de base (figure 16). Le rle dfinit comment une classe voit une autre classe au travers dune association. La visibilit dfinit les niveaux daccs dune proprit ou dune mthode.
Figure 16 : concepts du diagramme de classes II.3.1.5.2 Les reprsentations des diagrammes de classes
43
Etude pralable

1
Figure 17 : systme actuel diagramme de classes ax sur les activits
44
Etude pralable

1
Figure 18 : systme actuel Diagramme de classes ax sur les projets
45
Etude pralable

1
II.3.2 Critiques de lexistant

Notons que la DSE dispose doutils et de personnes comptentes et de trs grande volont, car elles ont permis jusqu' aujourdhui la gestion, le suivi et lvaluation de plusieurs projets. Mais, il nous incombe de faire ressortir les trivialits de cette gestion afin de proposer des solutions idoines. Dans ce qui suit, nous nous vertuerons exposer au mieux les points que nous avons jugs insuffisants, et qui requirent une attention particulire. Une redondance des informations Aucun contrle nest effectu pour vrifier lexistence de certaines informations dans le systme. Ce qui induit des redondances puisquun fichier concernant un sujet peut se retrouver plusieurs fois dans le systme. une lourdeur daccs aux donnes Il est souvent ncessaire dditer plusieurs fichiers et les lire afin den tirer les informations ncessaires. Un manque de scurit Les fichiers tant sur des ordinateurs, la seule protection dont ils jouissent nest que le mot de passe de lutilisateur de la machine. Ce qui parfois savre insuffisant. De plus , aucune traabilit des modifications sur un fichier nest gre. Un manque de contrle de concurrence Dans un environnement comme celui de la DSE, o plusieurs personnes accdent au mme fichier, des problmes de concurrence daccs se posent trs rapidement. Une maintenance difficile Afin dapporter des complments dinformations concernant un projets, les diffrents intervenants sont obligs de rencontrer les chargs dtude en vue de pouvoir leur soumettre leurs modification. Ce qui ralentit souvent le processus de suivi puisquil dpend principalement de la disponibilit des chargs dtude. Une consultation dinformations difficile Les oprateurs conomiques et les partenaires voulant consulter des informations sont obligs de prendre contact avec un charg dtude. Dans un tel contexte, il revient assez pnible aux intervenants de recueillir des informations au moment dont ils ont le plus besoin.
46
Etude pralable

1
II.4 Proposition de solution

Dans le souci de rsoudre les problmes cits plus haut et de respecter le cahier de charge dfini au dbut du projet, nous proposons une solution organise autour de plusieurs axes. Premirement, vu la ncessit de prsenter les informations en rapport des projets tous les intervenants, nous avons opt pour la cration dun site web dynamique qui est de nos jours le meilleur moyen de communication et de propagation dinformations. Deuximement, en vue de conserver toutes les informations concernant les projets et de permettre un accs ais, une base de donnes de ces projets sera construite et optimise pour de meilleures performances. Troisimement, afin de permettre tous les intervenants dun projet de mettre jour les informations dudit projet, un ensemble de formulaires assez intuitifs et faciles dutilisation seront labors et se grefferont au site web dynamique. Et finalement, pour les besoins de scurit, des mesures de scurit seront mises en place afin de permettre lauthentification et la gestion des utilisateurs, en plus de la traabilit des oprations sur les informations.
47
Etude pralable

1
CONCEPTION DU CADRE
Aprs les tapes de ltude pralable qui nous ont permis de : comprendre lexistant montrer ses limites proposer une solution idoine. Cette partie va nous permettre dlaborer les diffrents modles ncessaires la ralisation de la solution propose. Ainsi, cette conception qui se fera selon la mthode du processus unifi sorganisera autour des diffrentes activits qui se sont rpts au cours des diffrentes itrations.
48
Conception du cadre

1
III CONCEPTION DU CADRE

III.1 Modlisation mtier
III.1.1 Prsentation du projet raliser
En nous basant sur notre proposition de solution, nous pouvons dire que le projet raliser est un site web dynamique et scuris. En rsum, Il doit permettre dans un environnement scuris de grer, suivre et valuer les diffrents projets dont soccupe la Direction du Suivi-Evaluation.
III.1.2 Recueil des besoins fonctionnels

Afin de rpondre aux attentes des utilisateurs, nous avons procd plusieurs recherches pour identifier au mieux les besoins de lapplication. Nous sommes non seulement alls chercher les informations auprs des chargs dtudes de la DSE. Mais, nous nous sommes procur quelques documents qui expliquent le mode de fonctionnement de la gestion, du suivi et de lvaluation des projets. Ce qui nous a permis dtablir la description des processus de gestion, suivi et valuation des projets qui figure dans ltude pralable plus haut.
III.1.3 Identification des acteurs

Pour trouver les acteurs dun systme, il faut au pralable identifier quels sont les diffrents rles que vont devoir jouer ses utilisateurs. Il faut galement sintresser aux autres systmes aux autres systmes avec lesquels le systme va devoir communiquer. Une fois ces tches effectues, nous avons pu identifier les acteurs susceptibles dinteragir avec le systme : Linternaute qui est considr comme toute personne se connectant au site web. Il peut consulter toutes les informations mises sa disposition Le responsable dactivit qui est un intervenant dun projet charg dapporter des informations sur les diffrentes activits dont il a la charge. Ainsi, il introduit des informations sur des activits
le contrleur qui est la personne dont la fonction est de contrler les indicateurs. De ce fait, il valide les diffrents indicateurs caractrisant les activits le charg dtude 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. Conception du cadre
49

1
ladministrateur qui est la personne charge de crer les profils utilisateurs et dattribuer les droits daccs.
III.1.4 Identification des messages

Dans cette partie, nous allons citer les diffrents messages changs entre le systme et lextrieur mais dabord il serait profitable de dfinir un message. En effet, un message reprsente la spcification dune communication unidirectionnelle entre les objets qui transporte de linformation avec lintention de dclencher une activit chez le rcepteur. Comme messages mis par le systme, nous avons : Les informations dtailles sur les projets. La liste des programmes. La liste des sous-programmes par programme. La liste des projets par sous-programme. La liste des activits par projets. Les tats des indicateurs des activits. La liste des profils utilisateurs. Concernant les messages que reoit le systme, nous pouvons citer : Les crations, modifications, suppressions de profils utilisateurs. Les ajouts, modification, suppression dinformations concernant des projets. Les ajouts, modification, suppression dinformations concernant des activits. Les validations dindicateurs. Les demandes dinformations concernant les projets.
III.1.5 Modlisation du contexte

partir des informations obtenues lors des deux prcdentes tapes, nous avons pu modliser le contexte de notre application. Ceci va nous permettre de dfinir le rle de chaque acteur dans le systme.
50
Conception du cadre

1
Utilisateurs finaux Linternaute
Description des besoins fonctionnels Lapplication doit permettre linternaute de Consulter toutes les informations disponibles. Demander des informations prcises en rapport avec des projets. Lapplication doit permettre au responsable dactivit de Sauthentifier. Enregistrer/modifier/supprimer les dates de ralisation effective des activits signaler/modifier/supprimer les problmes rencontrs lors de lexcution dune activit Enregistrer/modifier/supprimer les preuves de la ralisation dune activit Lapplication doit permettre au contrleur de Sauthentifier. valider ou non un indicateur donner/modifier/supprimer ses observations concernant un indicateur consulter les tats des indicateurs Lapplication doit permettre au charg dtude de Sauthentifier. enregistrer/modifier/supprimer les informations en rapport avec des projets Lapplication doit permettre ladministrateur de Sauthentifier. Crer/modifier/supprimer des profils utilisateurs Donner/retirer/modifier des droits daccs
Le responsable dactivit
Le contrleur
Le charg dtude
Ladministrateur
Tableau 7 : les besoins fonctionnels
51
Conception du cadre

1
III.2 Recueil et expression des besoins

III.2.1 Identification des cas dutilisation
Pour constituer les cas dutilisation, il faut considrer lintention fonctionnelle de lacteur par rapport au systme dans le cadre de lmission ou de la rception de chaque message. En regroupant les intentions fonctionnelles en units cohrentes, nous obtenons les cas dutilisation.
Cas dutilisation Consulter des informations
Acteur principal internaute
Messages mis / reus par les acteurs mission : demande dinformation Rception : informations dtailles sur un projet, liste des programmes, liste des sous-programmes, liste des activits, liste des projets mission : ajouts, modification, suppression dinformations concernant des activits Rception : liste des activits mission : ajouts, modification, suppression dinformations concernant des projets Rception : liste des projets mission : validation dindicateur Rception : tats des indicateurs mission : cration, modification, suppression de profils et dutilisateur Rception : liste des profils utilisateurs.
Mettre jour une activit
Responsable dactivit
Mettre jour des informations
Charg dtude
Valider un indicateur Grer les profils
contrleur administrateur
Tableau 8 : les cas dutilisation
III.2.2 Diagramme de cas dutilisation
52
Conception du cadre

1
Figure 19 : systme futur - diagramme de cas dutilisation
53
Conception du cadre

1
III.2.3 Descriptions textuelles

Cas dutilisation : Mettre jour une activit
Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Mettre jour une activit Responsable dactivit Des activits ont t enregistres Scnario nominal Le responsable dactivit ouvre une session en entrant son login et son mot de passe 2 Le systme vrifie lauthenticit du couple fourni 3 Le systme recherche les activits auxquelles le responsable dactivit droit 4 Le systme prsente les activits 5 Le responsable dactivit choisit lactivit quil veut renseigner 6 Le systme prsente le formulaire de lactivit choisie 7 Le responsable dactivit renseigne le formulaire 8 Le systme vrifie la conformit du formulaire 9 Le systme enregistre les donnes fournies par le formulaire 10 Le responsable dactivits ferme sa session Scnario alternatif Point 2 : le couple fourni est Le systme redemande le login et le mot de passe erron Point 2 : le nombre de 1 Le systme empche la connexion pendant une tentatives > 3 heure 2 Fin 1 Point 8 : le formulaire nest 1 pas conforme Des activits ont t mises jour Le systme prsente le formulaire rempli en mettant en surbrillance les champs corriger
Post conditions
Tableau 9 : systme futur - mettre jour une activit Cas dutilisation : Consulter des informations
Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Consulter les informations Internaute Des informations sont disponibles Scnario nominal 1 Linternaute clique sur un lien 2 Le systme recherche les informations demandes 3 Le systme prsente les informations 4 Linternaute consulte les informations Des informations sont disponibles
Post conditions
Tableau 10 : systme futur - consulter des informations
54
Conception du cadre

1

Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Valider un indicateur Contrleur Des activits et des indicateurs ont t enregistrs Scnario nominal 1 Le contrleur ouvre une session en entrant son login et son mot de passe 2 Le systme vrifie lauthenticit du couple fourni 3 Le systme recherche les indicateurs 4 Le systme recherche les activits lies 5 Le systme prsente les couples indicateurs/activits 6 Le contrleur choisit le couple indicateur/activit quil veut renseigner 7 Le systme prsente le formulaire du couple choisi 8 Le contrleur renseigne le formulaire 9 Le systme vrifie la conformit du formulaire 10 Le systme enregistre les donnes fournies par le formulaire 11 Le contrleur dactivits ferme sa session Scnario alternatif Point 2 : le couple fourni Le systme redemande le login et le mot de est erron passe Point 2 : le nombre de 1 Le systme empche la connexion tentatives > 3 pendant une heure 2 Fin Point 9: le formulaire nest pas conforme Post conditions 1 Le systme prsente le formulaire rempli en mettant en surbrillance les champs corriger
Des indicateurs ont t mis jour
Tableau 11 : systme futur - valider un indicateur
55
Conception du cadre

1
Cas dutilisation : mettre jour des informations

Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Mettre jour des informations Charg dtude Le systme est disponible Scnario nominal Ladministrateur ouvre une session en entrant son login et son mot de passe 2 Le systme vrifie lauthenticit du couple fourni 3 Le systme recherche les informations auxquelles ladministrateur a droit 4 Le systme prsente les informations 5 Ladministrateur choisit les informations quil veut renseigner 6 Le systme prsente le formulaire des informations 7 Ladministrateur renseigne le formulaire 8 Le systme vrifie la conformit du formulaire 9 Le systme enregistre les donnes fournies par le formulaire 10 Ladministrateur ferme sa session Scnario alternatif Point 2 : le couple fourni Le systme redemande le login et le mot de est erron passe Point 2 : le nombre de 1 Le systme empche la connexion tentatives > 3 pendant une heure 2 Fin 1 Point 8: le formulaire nest pas conforme Post conditions 1 Le systme prsente le formulaire rempli en mettant en surbrillance les champs corriger
Des informations ont t mises jour
Tableau 12 : systme futur - mettre jour des informations
56
Conception du cadre

1
Cas dutilisation : grer les profils

Nom Acteurs principaux Acteurs secondaires Pr conditions Scnarii Grer les profils administrateur Des utilisateurs ont t dfinis Scnario nominal Ladministrateur ouvre une session en entrant son login et son mot de passe Le systme vrifie lauthenticit du couple fourni Le systme recherche les utilisateurs du systme Le systme prsente la liste des utilisateurs Ladministrateur choisit lutilisateur qui il veut attribuer ou retirer un profil Le systme prsente le formulaire des profils Ladministrateur renseigne le formulaire Le systme vrifie la conformit du formulaire Le systme enregistre les donnes fournies par le formulaire Ladministrateur ferme sa session Scnario alternatif Point 2 : le couple fourni Le systme redemande le login et le mot de passe est erron Point 2 : le nombre de 1 Le systme empche la connexion pendant une tentatives > 3 heure 2 Fin 1 2 3 4 5 6 7 8 9 10 Point 8: le formulaire 1 Le systme prsente le formulaire rempli en nest pas conforme mettant en surbrillance les champs corriger Des utilisateurs ont reu ou perdu des droits daccs
Post conditions
Tableau 13 : systme futur - grer les profils
III.3 Analyse
III.3.1 Dveloppement du modle statique
Suite aux diffrentes interviews ralises au sein de la direction, et en nous basant sur les cas dutilisations dfinis plus haut, nous avons pu dvelopper le modle statique de lapplication. C'est--dire le diagramme de classe. Ce diagramme permet de dcrire la structure des entits manipules par les utilisateurs. En conception, le diagramme de classe reprsente la structure dun code orient objet ou un niveau de dtail plus important, les modules du langage de dveloppement. Cependant, en raison du grand nombre dentits dans notre diagramme de classes, nous lavons divis en deux selon deux axes. Ainsi, nous avons un diagramme de classe ax sur les projets un diagramme de classes ax sur les activits
57
Conception du cadre

1
Figure 20 : systme futur diagramme de classes ax sur les activits
58
Conception du cadre

1
Figure 21 : systme futur diagramme de classes ax sur les projets
59
Conception du cadre

1
III.3.2 Dveloppement du modle dynamique

Le dveloppement du modle dynamique constitue la deuxime activit de ltape danalyse. Il sagit dune activit o sont labors les diffrents diagrammes dynamiques proposs par le langage UML. Parmi ces diagrammes, nous avons choisi den prsenter deux : les diagrammes dactivit qui permettront d'expliciter les traitements des diffrentes fonctionnalits du cadre raliser (cas dutilisation) le diagramme dtat transition qui reprend le concept bien connu de machines tats fini, et qui consiste sintresser au cycle de vie dune instance gnrique dune classe particulire au fil de ses interactions avec les autres classes. II.3.2.1 Diagramme dactivits Les diffrents diagrammes dactivits sont fonctions des diffrents cas dutilisation puisquils viennent expliciter ce qui a t crit dans les descriptions textuelles. Cas dutilisation : consulter des informations
Figure 22 : systme futur - consulter des informations
60
Conception du cadre

1
Cas dutilisation : mettre jour une activit
Figure 23: systme futur - mettre jour une activit
61
Conception du cadre

1
Figure 24: systme futur - valider un indicateur
62
Conception du cadre

1
Cas dutilisation : mettre jour les informations
Figure 25: systme futur - mettre jour des informations
63
Conception du cadre

1
Cas dutilisation : grer les profils
Figure 26: systme futur - grer les profils
64
Conception du cadre

1
II.3.2.2 Diagramme dtats-transition Toutes les classes du modle classique ne requirent pas ncessairement une machine tats, reprsente par un diagramme dtats. Il sagit donc de trouver celles qui ont un comportement dynamique complexe et ncessitant une description avance. Dans cet ordre dide, nous avons opt pour la prsentation du diagramme dtats transition de la classe activit (figure 27) puisquelle est la plus intressante du point de vue du comportement dynamique.
Figure 27: systme futur - activit
65
Conception du cadre

1
SECURISATION DU CADRE
A la suite de la conception du cadre, nous allons maintenant tablir sa scurit. Cette scurit qui ncessite une mthode particulire nous a amen tudier la gestion des risques et plus spcifiquement les diffrentes mthodes danalyse de risques en vue den choisir une. Une fois le choix effectu nous avons procd son application proprement dite.
66
Scurisation du cadre

1
IV SECURISATION DU CADRE
IV.1 Ncessit dune scurisation du systme dinformation
Si nous devons lire linventeur de ces 20 dernires annes, nous choisirons sans aucun doute Tim-Berners LEE, ce physicien du Centre Europen de Recherche Nuclaire (CERN) qui est aujourdhui prsident du World Wide Web Consortium (W3C) puisquil est considr comme le pre fondateur dInternet. Le fruit de ses labeurs a connu de nos jours une volution majeure allant mme simmiscer dans tous les secteurs dactivits. Les facilits quil offre pour les transferts de fichiers, le courrier lectronique, les listes de diffusion, les forums entre autres ont permis un dveloppement spectaculaire et fructueux des communications, des changes et du travail. Mais, paralllement la mutation extraordinaire de nos mthodes de travail qua induit cette volution, nous assistons dautres phnomnes parasitaires inquitants, notamment depuis louverture dInternet des activits prives ou commerciales, ce qui confirme la ncessit, pour les organismes qui veulent pouvoir communiquer librement, stocker et traiter des donnes, de protger leurs systmes dinformation. Effectivement, de nouvelles formes de malveillance ont rcemment fait leur apparition. Certaines de ces malveillances constituent des crimes ou des dlits et peuvent entraner des poursuites judiciaires ; dautres provoquent une entrave la communication. Plus inquitante encore est lapparition dune dlinquance organise qui cherche pntrer les systmes pour sapproprier de linformation et la monnayer aux plus offrants. Linformation, mme dapparence anodine, constitue aprs compilation, recoupements et traitements, une valeur marchande pour des groupes de mieux en mieux structurs. De ce point de vue, nous avons dpass lpoque du vulgaire bricoleur solitaire qui par jeu ou par dfi, cherche pntrer les systmes les mieux protgs. Les pirates daujourdhui oprent en bande; ils utilisent des procds quils rcuprent sur des sites spcialiss et ne sont guids par aucune thique. Pour ces prdateurs dun nouveau type, les laboratoires universitaires, les diffrentes institutions tatiques constituent des cibles privilgies. De ce fait, la scurit de notre cadre de gestion de projet savre assez cruciale puisquelle doit prserver les ressources matrielles, logicielles et aussi les informations de lorganisation de toutes utilisations illicites. Toutefois, la scurit des systmes dinformation est de plus en plus aborde, dans les entreprises, laide dapproches bases sur les risques, car lexprience montre que de telles tudes prospectives rduisent de manire considrable les pertes lies aux faiblesses de scurit des systmes dinformation. Partant de ce constat, une tude de la gestion des risques nous semble utile.
67

1
IV.2 Prsentation de la gestion des risques

Le concept de gestion des risques (ou risk management) a fait son apparition la fin des annes 50 aux tats-Unis dans le domaine financier, en relation avec des questions dassurance. Par la suite, la notion de gestion des risques a t tendue dautres domaines, notamment lenvironnement, la gestion de projet, le marketing, ainsi que la scurit informatique. Elle est dfinie par lInternational Organization for Standardization (ISO), comme lensemble des activits coordonnes visant diriger et piloter un organisme vis--vis du risque. Ainsi, trois finalits la gestion des risques sont dgages pour les systmes dinformation : amliorer la scurisation des systmes dinformation ; justifier le budget allou la scurisation du systme dinformation ; prouver la crdibilit du systme dinformation laide des analyses effectues. Bien quun grand nombre ne soit plus utilis ou confidentiel, les mthodes de gestion des risques existantes sont dans lordre de 200 mthodes. Cette multiplicit entrane une trs grande diversit dans les approches des risques de scurit do 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 interdpendants. Nous distinguons lorganisation cible de ltude, dfinie par ses assets et ses besoins de scurit, puis les risques pesant sur ces assets et enfin les mesures prises ayant pour but de traiter les risques et donc dassurer un certain niveau de scurit.
Figure 28 : concepts de la gestion des risques
68

1
Nous pouvons dfinir les assets comme tant lensemble des biens, actifs, ressources ayant de la valeur pour lorganisme et ncessaire son bon fonctionnement. Nous distinguons les assets du niveau business des assets lis au systme dinformation. Du ct des assets business, nous retrouvons principalement des informations (par exemple des numros de carte bancaire) et des processus (comme la gestion des transactions ou ladministration des comptes). De plus, les assets business de lorganisme sont bien souvent entirement (ou presque) grs au travers du systme dinformation, ce qui entrane une dpendance de ces assets vis--vis de ce dernier. Ce sont les assets systme. Nous retrouvons dans les assets systme les lments techniques, tels les matriels, les logiciels et les rseaux, mais aussi lenvironnement du systme informatique, comme les utilisateurs ou les btiments. Se basant sur ces dfinitions, le but de la gestion des risques est donc dassurer la scurit des assets, scurit exprime la plupart du temps en termes de: confidentialit des donnes qui consiste rendre linformation inintelligible aux personnes autres que les seuls acteurs de la transaction ; intgrit des donnes qui consiste dterminer si les donnes nont pas t altres durant la communication (de manire fortuite ou intentionnelle) ; disponibilit du systme qui garantit laccs un service ou des ressources ;
Ces assets protger sont soumis des risques de scurit. Le guide 73 de lInternational Organization for Standardization (ISO) dfinit un risque par la combinaison de la probabilit dun vnement et de ses consquences. Cette dfinition est gnralement tendue et un risque est couramment dfini comme la combinaison dune vulnrabilit, dune menace et dun impact. Il est aussi illustr laide de ce que lon nomme lquation du risque RISQUE = MENACE * VULNRABILIT * IMPACT Cette quation est celle qui est la plus frquemment utilise et la plus reconnue dans le domaine de la gestion des risques. Elle joue un rle fondamental dans lidentification et lvaluation du risque. Cependant, pour bien comprendre la notion de risque, il est important dexaminer chacune de ses composantes : La menace qui est la cause potentielle dun incident mettant en danger les assets. Elle est souvent assimile lagresseur. La vulnrabilit qui est la caractristique dun asset constituant une faiblesse ou une faille au regard de la scurit. Limpact reprsente la consquence du risque sur lorganisme et ses objectifs.
69

1
Figure 29 : exemple dun risque Afin de mitiger ces risques et de protger les assets, une politique de traitement des risques est mise en place. Elle sera constitue dexigences de scurit permettant de rpondre aux risques. Ces exigences de scurit vont ensuite entraner la mise en place de contrles (ou contre-mesures) de scurit implmenter, afin de satisfaire aux exigences. Les contrles sont de deux types : sur la menace ou la vulnrabilit, afin de limiter la cause du risque ; sur limpact, afin de limiter la consquence du risque.
IV.2.2 Le processus de gestion des risques

Aprs 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 mthodes pratiques de gestion des risques.
70

1
Identification du contexte et des assets Dtermination des objectifs de scurit Dfinition des exigences de scurit Analyse des risques
Slection des contrles
Implmentation des contrles
Figure 30 : le processus de gestion de risques Au vu de la figure ci-dessus reprsentant la dmarche de gestion des risques, nous notons les tapes suivantes : lidentification du domaine et des assets qui est ltape o il est question de prendre connaissance de lorganisation, son environnement, son systme dinformation et de dterminer prcisment les limites du systme sur lequel va porter ltude de gestion des risques. Une fois notre systme born, nous procdons en premier lieu lidentification des assets business constituant la valeur de lorganisation. Ensuite, le
71

1
lien sera fait entre ces assets business et les assets systmes, sur lesquels nous identifierons et corrigerons les risques dun point de vue technique et organisationnel. La dtermination des objectifs de scurit vise spcifier les besoins en termes de confidentialit, intgrit, disponibilit, non-rpudiation et authentification des assets, en particulier au niveau business. Le lien entre les assets business et les assets systme tant en amont, nous retrouvons donc les besoins en scurit au niveau du systme Lanalyse des risques constitue le cur de la dmarche de gestion des risques. Elle a pour finalit lidentification et lestimation de chaque composant du risque (menace/vulnrabilit/impact), afin dvaluer le risque et dapprcier son niveau, dans le but de prendre des mesures adquates (parfois cette tape est appele apprciation du risque). Nous notons deux grandes coles pour lidentification des risques : soit en ralisant un audit du systme et de ses diffrents acteurs, soit partir de bases de connaissances prdfinies. Pour lestimation des risques, il est possible en thorie de les quantifier laide de distributions de probabilits sur les menaces et les vulnrabilits, ainsi quen estimant les cots occasionns par les impacts. En pratique il se rvle difficile de donner des valeurs absolues et lon se contente bien souvent dune chelle de valeurs relatives. Cette estimation permet de faire un choix, reprsent sur la figure 31, dans le traitement du risque.
Figure 31: les diffrentes zones de risques
72

1
Dune manire gnrale, lon considre que : Les risques ayant une occurrence et un impact faible sont ngligeables. Les risques ayant une forte occurrence et un impact important ne doivent pas exister, autrement une remise en cause des activits de lentreprise est ncessaire (on vite le risque, avoidance en anglais). Les risques ayant une occurrence forte et un impact faible sont accepts, leur cot est gnralement inclus dans les cots oprationnels de lorganisation (acceptation du risque). Les risques ayant une occurrence faible et un impact lourd sont transfrer. Ils peuvent tre couverts par une assurance ou un tiers (transfert du risque). Enfin, les autres risques, en gnral majoritaires, sont traits au cas par cas et sont au centre du processus de gestion des risques ; lobjectif tant de diminuer les risques en les rapprochant au maximum de lorigine de laxe (mitigation du risque laide de contrles).
La dfinition des exigences de scurit permet de rduire les risques identifis. En fonction des mthodes, cette tape pourra tre effectue avec lassistance de rfrentiels, ou aiguille par la connaissance dexperts systme/scurit. La dfinition des exigences de scurit, au vu de son importance et sa complexit, est souvent effectue de manire incrmentale et par raffinements successifs. En effet, il est conseill bien souvent de dbuter par des exigences gnrales, qui dfiniront lintention de contrer les risques identifis (de niveau stratgique), pour les raffiner ensuite en des exigences plus prcises (vers le niveau oprationnel). Toutefois, les exigences sont censes tre gnriques et applicables tout systme dinformation. Il faut galement rappeler que ces exigences de mitigation des risques porteront la fois sur le systme informatique (comme le besoin de chiffrement des mots de passe), mais aussi sur son environnement (par exemple, lutilisateur du systme ne doit pas dvoiler son mot de passe un tiers ). La slection des contrles est le dernier niveau de raffinement. Les contrles sont linstanciation des exigences de bas niveau pour le systme cible tudi. Dans cette tape, nous dfinissons les choix techniques des solutions de scurit influencs par le systme dj en place, les comptences disponibles, les cots de mise en uvre. Limplmentation des contrles qui permet dimplmenter les contrles dans le systme dinformation et ventuellement de les tester et les valuer.
73

1
Bien que les concepts et le processus de gestion des risques soient dfinis, la notion de risque reste un concept difficile apprhender do lexistence de plusieurs mthodes danalyse des risques pour faciliter la mise en pratique dune gestion de risque. En outre, relativement la complexit des organisations actuelles associes aux enjeux conomiques, il est judicieux de ne pas sen remettre exclusivement des subjectivits, mais plutt utiliser des mthodes danalyse des risques qui sont formelles et ont t prouves.
IV.3 Les mthodes danalyses de risques

Prsentement, nous pouvons dnombrer plus de 200 mthodes danalyses des risques qui sont dclines travers le monde. Ces dernires sont plus ou moins finalises, plus ou moins faciles daccs ou tout simplement inconnues. Nonobstant lexistence de toutes ces mthodes, 3 dentre elles sont trs utilises et prises des entreprises. Nous pouvons citer : lExpression des Besoins et Identification des Objectifs de Scurit (EBIOS), Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), la Mthode Harmonise dAnalyse de Risques (MEHARI).
IV.3.1 EBIOS (Expression des Besoins et Identification des Objectifs de Scurit)

Il sagit dune mthode dveloppe et maintenue par la Direction Centrale de la Scurit des Systmes dInformation (DCSSI). Cette mthode, cre en 1995, se compose de cinq guides (Introduction, Dmarche, Techniques, Outillages pour lapprciation des risques et Outillages pour le traitement des risques) et dun logiciel support dont la diffusion est gratuite. La mthode a pour objectif la formalisation dobjectifs de scurit adapts aux besoins du systme audit (et de son contexte).
74

1
tude du contexte
Expression des besoins de scurit
tude des menaces
Identification des objectifs de scurit
Dtermination des exigences de scurit
Figure 32: dmarche globale dEBIOS Par ailleurs, cette mthode avant tout destine ladministration franaise et aux entreprises est dcoupe en 5 tapes comme le montre la figure 32. Nous avons : Ltude du contexte qui permet d'identifier quel systme d'information est la cible de l'tude. Cette tape dlimite le primtre de l'tude : prsentation de l'entreprise, architecture du systme d'information, contraintes techniques et rglementaires, enjeux commerciaux. Mais est aussi tudi le dtail des quipements, des logiciels et de l'organisation humaine de l'entreprise. Lexpression des besoins de scurit qui permet d'estimer les risques et de dfinir les critres de risque. Les utilisateurs du systme dinformation expriment durant cette tape leurs besoins de scurit 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 systme d'information. Ainsi, la liste des vulnrabilits et des types d'attaques est dresse en fonction des matriels, de l'architecture rseau et des logiciels employs. Et ce, quelles que soient leur origine (humaine, matrielle, environnementale) et leur cause (accidentelle, dlibre).
75

1
L'identification des objectifs de scurit qui permet de confronter les besoins de scurit exprims et les menaces identifies afin de mettre en vidence les risques contre lesquels le SI doit tre protg. Ces objectifs vont former un cahier des charges de scurit qui traduira le choix fait sur le niveau de rsistance aux menaces en fonction des exigences de scurit. La dtermination des exigences de scurit qui permet de dterminer jusqu'o on devra aller dans les exigences de scurit. Il est vident qu'une entreprise ne peut faire face tout type de risques, certains doivent tre accepts afin que le cot de la protection ne soit pas exorbitant. C'est notamment la stratgie de gestion du risque tel que cela est dfini dans un plan de risque qui sera dtermin ici : accepter, rduire ou refuser un risque. Cette stratgie est dcide en fonction du cot des consquences du risque et de sa probabilit de survenue. La justification argumente de ces exigences donne l'assurance d'une juste valuation.
IV.3.2 OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

Cette mthode dvaluation du risque cre en 1999 a t publie par le Software Engineering Institute (SEI) de la Carnegie Mellon University, reconnue dans le domaine de la scurit des systmes dinformation (fdration des Computer Emergency & Reponse Team CERTS). Les fondements mmes de cette mthode reposent sur la possibilit de raliser une analyse des risques de lintrieur de lorganisation, exclusivement avec des ressources internes en se basant sur un catalogue de bonne pratique de scurit fourni avec la mthode. Pleinement oriente vers les grandes entreprises, une version OCTAVE-S (Small) peut, cependant, facilement se dcliner au sein dune petite structure conomique. OCTAVE est une mthode dvaluation des vulnrabilits et des menaces sur les actifs oprationnels. Une fois ces derniers identifis, la mthode permet de mesurer les menaces et les vulnrabilits pesant sur eux. Les trois phases suivantes dclines au cur dOCTAVE, respectent lanalyse progressive des trois blocs des concepts de gestion des risques prsents en amont : La phase 1 (vue organisationnelle) permet d'identifier les actifs de l'entreprise, les menaces qui psent sur son fonctionnement, les vulnrabilits de son organisation, les objectifs de scurit imposs par la direction et les mesures actuelles de scurit. Ce sont trois processus de collecte de l'information qui sont raliss durant cette phase, chacun par une population particulire : les cadres suprieurs, les cadres oprationnels et les quipes de production. La consolidation des informations nes de ces processus amne crer des profils de menaces. La phase 2 (vue technique) permet didentifier les lments essentiels des actifs et les audite afin den connaitre les vulnrabilits.
76

1
La phase 3 de la mthode dcline le dveloppement de la stratgie de scurit qui consiste valuer les risques identifis (impact, probabilit) plus haut et proposer les mesures permettant de les rduire. Un plan de rduction des risques est alors planifi.
Actifs Menaces Vulnrabilits Objectifs de scurit
Phase 1 Vue Organisationnelle
Phase 3 Dveloppement de la stratgie de scurit
Prparation
Risques Stratgie de protection Plan de rduction
Vulnrabilits
Phase 2 Vue Technique
Figure 33: les principales phases dOCTAVE
IV.3.3 MEHARI (Mthode harmonise dAnalyse des Risques)

MEHARI (Mthode Harmonise d'Analyse de Risques) est dveloppe par le CLUSIF depuis 1995, elle est drive des mthodes Melissa et Marion. Existant en langue franaise et en anglais, elle est utilise par de nombreuses entreprises publiques ainsi que par le secteur priv. Elle possde aussi un outil de gestion des risques dvelopp par la socit BUC SA nomme RISICARE. La dmarche gnrale de MEHARI consiste en l'analyse des enjeux de scurit : quels sont les scnarios redouts ?, et en la classification pralable des entits du systme dinformation en fonction de trois critres de scurit de base (confidentialit, intgrit, disponibilit). Ces enjeux expriment les dysfonctionnements ayant un impact direct sur l'activit de l'entreprise. Puis, des audits identifient les vulnrabilits du SI. Et enfin, l'analyse des risques proprement dite est ralise.
77

1
Figure 34 : la dmarche globale de MEHARI Par ailleurs, la dmarche MEHARI s'articule autour de 3 types de livrables dnomms plans. Nous avons : Le Plan Stratgique de Scurit (PSS) fixe les objectifs de scurit ainsi que les mtriques permettant de les mesurer. C'est ce stade que le niveau de gravit des risques encourus par l'entreprise est valu. Il dfinit la politique de scurit ainsi que la charte d'utilisation du systme dinformation pour ses utilisateurs. Les Plans Oprationnels de Scurit (POS) dfinissent pour chaque site les mesures de scurit qui doivent tre mises en uvre. Pour cela, ils laborent des scnarios de compromission et audite les services du SI. Sur la base de cet audit, une valuation de chaque risque (probabilit, impact) est ralise permettant par la suite d'exprimer les besoins de scurit, et par la mme les mesures de protection ncessaires. Enfin, une planification de la mise niveau de la scurit du SI est faite. Le Plan Oprationnel d'Entreprise (POE) assure le suivi de la scurit par l'laboration d'indicateurs sur les risques identifis et le choix des scnarios de catastrophe contre lesquels il faut se prmunir.
78

1
IV.3.3 Choix dune mthode danalyse de risques

lissue de la prsentation des prdominantes mthodes danalyse, nous remarquons que ces diffrentes mthodes ne sont pas opposes, mais plutt complmentaires (annexe 2). Cependant dans le cadre de notre projet nous ferons un choix afin de pouvoir faire ressortir les besoins de scurit de notre application, quitte nous damliorer continuellement cette scurit en appliquant les autres rfrentiels de scurit. Toutefois, ce choix ne peut se faire quen se basant sur une tude compare rsume dans le tableau cidessous.
79

1
Mthodes
Origine
Outils logiciels
Existence dun club
Qualit de la documentation
Facilit dutilisation et le pragmatisme de la mthode
Comptabilit avec une norme nationale ou international e
Taille de lentreprise
Support de la mthode par son auteur
popularit
Quantit de moyens humains
EBIOS
France (DCSSI gouvernem ent)
Logiciel gratuit
communaut dexperts cre en 2003
5 guides sont fournis et existence dun centre de formation
MEHARI
France (CLUSIF association )
Logiciel RISICA RE payant
CLUSIF (Club de la Scurit des Systmes dInformatio n Franais)
3 guides dutilisation, des manuels de rfrence sont disponibles
OCTAVE
Etats-Unis (Universit de Carnegie Melon)
Logiciel payant
non
Un catalogue de bonnes pratiques est fourni et lensemble des activits mener est trs dtaille
Facile dutilisation et trs adaptable selon les besoins, utilisation amliore par loutil logiciel Cadre mthodologique assez facile dutilisation, et amliore par des bases de connaissances et des outils En considrant sa dclinaison pour les petites entreprises, OCTAVE est trs accessible
Compatible avec les normes l'ISO/IEC 15408, l'ISO/IEC 17799 Compatibles avec les normes ISO 13335 et ISO 27001
Toutes les entreprises et originellement conue pour les organismes dtats Grandes entreprises et organismes
Soutenue par le gouverneme nt
***
La mthode a t conue pour tre utilise par un analyste ou une quipe. Ncessite la mise en place dun management de risques
Dveloppe et maintenue par le CLUSIF
***
aucune
Premirement oriente vers les grandes entreprises mais une dclinaison OCTAVE-S a t labore pour les petites entreprises.
Maintenue par le SEI de luniversit
**
Une petite quipe compose de membres de lquipe oprationnell e et du dpartement informatique
Tableau 14 : comparaison des mthodes danalyses de risques
80

1
Forts de cette comparaison, nous avons jet notre dvolu sur la mthode EBIOS puisquelle offre dune part un logiciel dassistance facile dutilisation et gratuit. Dautre part, elle est la production dun organisme gouvernemental o la scurit est une affaire de tous les instants et qui sied donc ce type dentit par corollaire. En plus, cette mthode a pour vocation la protection de lorganisation en entier et non des actifs de lorganisation.
IV.4 Mesures de scurit

la suite dune tude base sur la mthode EBIOS et ralise laide de leur outil dassistance, nous sommes arrivs dterminer les actions de scurit quil convient dentreprendre. Ainsi, les rsultats de cette tude recommandent pour la scurisation dune application web dadopter une approche globale (figure 35) et dappliquer la scurit au niveau : du rseau, de lhte (serveur web, serveur de base de donnes, serveur dapplications), de lapplication.
Figure 35 : approche globale de la scurit
81

1
IV.4.1 Scurisation du rseau

IV.4.1.1 Prsentation Le rseau est le point d'entre de notre application. C'est ce niveau que se situent les premiers gardes-barrires qui contrlent l'accs aux diffrents serveurs dans notre environnement. Les serveurs sont protgs par les gardes-barrires de leur propre systme d'exploitation, mais il est important de les prserver d'attaques provenant de la couche rseau. Il est tout aussi important de nous assurer que les gardes-barrires du rseau ne peuvent pas tre remplacs ou reconfigurs par des imposteurs. En un mot, la scurit du rseau consiste protger les priphriques du rseau et les donnes qu'ils transmettent (annexe 3). Les principaux composants d'un rseau qui font office de gardes-barrires de premier niveau sont le routeur, le pare-feu et le commutateur.
Figure 36 : Composants rseau : routeur pare-feu - commutateur
IV.4.1.2 Menaces et contre-mesures Ce sont les priphriques de rseau mal configurs qui sont les cibles privilgies des attaques. Les problmes de vulnrabilit sont gnralement dus au manque de scurit des paramtres d'installation par dfaut, aux ngligences dans les contrles d'accs et la nonapplication de correctifs sur les services. Le tableau ci-dessous rcapitule les menaces majeures dun rseau et les contre mesures adquates.
82

1
Menaces Collecte dinformations
Dfinitions La collecte dinformations peut rvler des informations dtailles sur la topologie du rseau, la configuration systme et les priphriques du rseau. Un agresseur utilise ces informations pour lancer des attaques cibles sur les zones de vulnrabilit ainsi mises en vidence
Vulnrabilits caractre peu scuris de la suite de protocoles TCP/IP informations de configuration fournies par les bannires services accessibles qui devraient tre appliques
Espionnage
Lespionnage galement appel coute clandestine consiste surveiller le trafic du rseau afin dobtenir des donnes telles que des mots de passe non scuriss ou des informations de configuration. Il suffit dun intercepteur de paquets pour lire aisment le trafic en clair. Ce dispositif permet galement de pirater des algorithmes de hachage simples et de dchiffrer une charge utile considre comme scurise.
scurit physique insuffisante absence de cryptage lors de lenvoi des donnes sensibles communication entre services effectue en clair, en recourant un dispositif de cryptage insuffisant ou au hachage
Attaques utilisation de Tracert pour dtecter la topologie du rseau utilisation de Telnet afin douvrir des ports pour laccrochage des bannires analyse des ports pour la dtection de ports ouverts utilisation de demandes de diffusion pour numrer les htes dun sous-rseau mise en place doutils despionnage de paquets sur le rseau afin denregistrer lensemble du trafic
Contre-mesures utilisation de bannres de services gnriques qui ne fournissent pas dinformations 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 renforcement de la scurit physique pour viter lintrusion de priphriques malveillants sur le rseau. cryptage des informations dauthentification et du trafic applicatif circulant sur le rseau.
83

1
Usurpation
Dtournement de session
L'usurpation d'identit, galement appele dissimulation d'identit, offre un moyen de masquer son identit relle sur le rseau. Elle consiste utiliser une fausse adresse source qui ne correspond pas l'adresse relle de l'metteur du paquet. L'usurpation peut servir masquer la source d'une attaque ou contourner les listes de contrle d'accs (ACL) mises en place pour limiter les accs htes en fonction des rgles dfinies sur les adresses sources. Avec le dtournement de session, galement dsign 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 considrer tort l'hte situ en amont comme l'hte lgitime. En ralit, l'hte situ en amont est l'hte d'un pirate qui manipule le rseau afin d'en faire la destination souhaite. Le dtournement de session peut tre utilis pour obtenir des informations de connexion exploitables pour accder une application ou des donnes confidentielles.
caractre peu scuris de la suite de protocoles TCP/IP absence de filtrage entrant et sortant. Le filtrage entrant consiste dtecter les paquets IP dots d'adresses source non approuves avant qu'ils ne puissent s'introduire dans notre systme ou dans notre rseau et les endommager. Le filtrage sortant porte sur le trafic issu du rseau. scurit physique insuffisante caractre peu scuris de la suite de protocoles TCP/IP communication non crypte
utilisation de plusieurs outils pour modifier les paquets sortants afin quils semblent issus dun autre rseau ou dun autre hte
utilisation du filtrage entrant et sortant sur les routeurs de primtre.
utilisation de plusieurs outils associant des fonctions despionnage, de modification, de routage et de manipulation de paquets
cryptage de session inspection dynamique pare-feu
du
84

1
Refus de service
Une attaque de refus de service consiste empcher les utilisateurs lgitimes d'accder un serveur ou des services. Les attaques de refus de service sur la couche rseau procdent gnralement par saturation du rseau, ce qui consomme la bande passante et les ressources disponibles.
caractre peu scuris de la suite de protocoles TCP/IP configuration de routeurs et de commutateurs peu scurise communication non crypte bogues des logiciels de services
attaque en force brute par lenvoi de flux de paquets tel que du trafic diffusion gnrale en cascade saturation SYN attaque de services, telles que les dpassements de capacits de la mmoire tampon
filtrage des demandes de diffusion gnrale filtrage des requtes ICMP (Internet Control Message Protocol) application de correctifs et de mises jour sur les logiciels de service
Tableau 15 : menaces et contre-mesures dun rseau
85

1
IV.4.2 Scurisation du serveur web

IV.4.2.1 Prsentation 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 appropries 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 Accs non autoris Excution arbitraire du code lvation des privilges Virus, vers et chevaux de Troie
La figure 37 rsume les attaques les plus communes ainsi que les vulnrabilits courantes.
Figure 37 : Menaces du serveur web prdominantes et vulnrabilits courantes IV.4.2.2 Menaces et contre-mesures
86

1
Menaces Profilage
Refus de service
Description Le profilage, ou numration de sessions est un processus dexploration utilis pour collecter des informations sur un site web. Lattaquant utilise ces informations pour attaquer les points faibles connus. Les attaques par refus de service surviennent lorsque notre serveur est satur par les requtes de service. La menace rside dans le fait que notre serveur peut tre trop submerg pour rpondre aux requtes de clients lgitimes. On parle d'accs non autoris lorsqu'un utilisateur sans autorisation parvient accder aux informations protges ou effectue une opration restreinte. Les attaques par excution de code se produisent lorsqu'un attaquant excute un code nuisible sur notre serveur pour en compromettre les ressources ou pour lancer d'autres attaques contre les systmes en aval.
Vulnrabilits protocoles inutiles ports ouverts serveur web fournissant des informations de configuration dans les bannires configuration faible des la pile TCP/IP serveurs non mis jour
Attaques lanalyse des ports les balayages de Ping lnumration NetBIOS et bloc de message serveur (SMB) saturations SYN au niveau du rseau dpassement de capacit de la mmoire tampon saturation du serveur web avec des requtes issues demplacements distribus
Contre-mesures bloquer tous les ports inutiles, arrter le trafic ICMP dsactiver les protocoles inutiles tels que NetBIOS et SMB renforcement de la pile TCP/IP application cohrentes des derniers correctifs logiciels et mises jour sur le logiciel systme
Accs non autoris
Excution arbitraire du code
faibles contrles daccs au serveur web, autorisations web comprises autorisations faibles faible configuration du serveur web serveurs non mis jour
pntration des rpertoires dpassements de capacits de la mmoire tampon menant linjection de code
utilisation des autorisations web scurises utilisation des mcanismes de contrles daccs utilisation configuration du serveur web pour rejeter les URL contenant ../ afin dviter la pntration des rpertoires verrouillages des commandes systmes et des utilitaires avec des listes de contrles daccs restrictifs (ACL) installation des nouveaux correctifs et mises jour
87

1
lvation privilges
des
On parle d'attaque par lvation des privilges lorsqu'un attaquant excute le code en utilisant un compte de processus privilgi
comptes de processus surprivilgis compte de services surprivilgis
Virus, vers chevaux de Troie
et
Le code nuisible peut revtir diverses formes, parmi lesquelles : Les virus. Il s'agit des programmes conus pour excuter des actions nuisibles et provoquer l'interruption du systme d'exploitation ou des applications. Les vers. Ce sont des programmes qui s'auto-rpliquent et s'autoentretiennent. 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 inaperu jusqu' ce qu'il consomme les ressources du systme et ralentisse ou interrompe l'excution des autres programmes.
serveur non mis jour excution de services inutiles filtres ISAPI et extensions inutiles
excuter les processus au moyen du compte le moins privilgi utiliser des comptes utilisateurs et des services les moins privilgis possible application des derniers correctifs logiciels dsactivation des fonctionnalits non utilises telles que les filtres ISAPI et extensions inutiles excution des processus laide de compte peu privilgi pour rduire ltendue des dommages en cas dinfection
Tableau 16 : menaces et contre-mesures dun serveur web
88

1
IV.4.3 Scurisation du serveur dapplications

IV.4.3.1 Prsentation Du fait que les serveurs d'applications sont censs tre isols de tout accs via Internet, nombre des dangers qui les menacent proviennent de l'intrieur de l'entreprise. Les principales menaces pour le serveur d'applications sont les suivantes :

coute clandestine du rseau Accs 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 vulnrabilits dun serveur dapplications IV.4.3.2 Menaces et contre-mesures
89

1
Menaces Ecoute clandestine du rseau
Accs non autoris
Descriptions Les personnes malveillantes quipes de logiciels de surveillance du rseau peuvent intercepter les donnes circulant entre le serveur Web et le serveur d'applications, ainsi que celles qui transitent entre le serveur d'applications et les systmes en aval ou les serveurs de base de donnes. la personne malveillante peut visualiser ces donnes et tre en mesure de les modifier. Si nous ne parvenons pas bloquer les ports utiliss par les applications qui s'excutent sur le serveur d'applications au niveau du pare-feu du primtre, 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.
Vulnrabilits donnes sensibles transmises sous forme de texte clair par lapplication absence de cryptage sur la couche transport ou application interface dadministration du matriel rseau non scurise faiblesse dans la configuration du rseau de primtre et du pare-feu ports superflus ouverts sur le pare-feu interne absence de stratgie IPSec pour limiter la connectivit aux htes services actifs inutiles protocoles inutiles faiblesse des stratgies de comptes et de mots de passe
Attaques mise en place doutils dinterception de paquets sur le rseau afin de capturer le trafic
lanalyse de ports pour dtecter les services lcoute laccrochage de bannires, qui diffuse les services disponibles et ventuellement les versions de logiciels lintroduction dapplications malveillantes les attaques par mots de passe contre les comptes par dfaut dots de mots de passe trop simples
Contre-mesures utiliser une authentification scurise crypter les informations dauthentification du serveur web scuriser les canaux de communications (SSL ou IPSec) utiliser un rseau segment, qui permet d'isoler les segments susceptibles de subir des coutes. application sur les pare-feu de stratgies visant bloquer tout le trafic, sauf sur les ports de communications attendus stratgie de filtrage TCP/IP ou IPSec pour empcher les htes non autoriss dtablir des connexions Dsactivation des services inutiles
90

1
Virus, vers chevaux de Troie
et
Ces attaques sont gnralement remarques que lorsquelles commencent consommer les ressources systmes, ce qui ralentit ou arrte lexcution dautres applications.
serveurs sans correctifs excutions de services inutiles filtres et extensions ISAPI inutiles
application rapide des derniers correctifs dsactivation des fonctionnalits inutilises, telles que les filtres et extensions ISAPI inemploys excution des processus avec les comptes moins privilgies pour limiter lampleur des dommages si le systme est compromis
Tableau 17 : menaces et contre-mesures dun serveur dapplications
91

1
IV.4.4 Scurisation du serveur de base de donnes

IV.4.4.1 Prsentation Un attaquant dispose de diffrents moyens pour cibler et compromettre un serveur de base de donnes en exploitant les diverses vulnrabilits au niveau des applications et de la configuration. Les principales menaces du serveur de base de donnes sont les suivantes :

Injection SQL coute clandestine du rseau Accs non autoris au serveur Piratage de mot de passe
La figure 39 illustre les principales menaces et vulnrabilits pouvant conduire l'infection d'un serveur de base de donnes et la possibilit de dtruire ou de drober les donnes sensibles.
Figure 39 : Principales menaces et vulnrabilits dun serveur de base de donnes IV.4.4.2 Mesures et contre-mesures
92

1
Menaces Injection SQL
Description Dans le cas d'une attaque par injection SQL, l'attaquant exploite les vulnrabilits de validation des entres dans notre application et du code d'accs aux donnes. Il peut ainsi excuter arbitrairement des commandes dans la base de donnes dans le contexte de scurit de l'application Web.
Vulnrabilits la faiblesse de la validation des entres dans nos applications web des commandes SQL non scurises, construites de manire dynamique lutilisation de connexions surprivilgies la base de donnes des autorisations faibles qui ne parviennent pas limiter la connexion de lapplication la base de donnes des canaux de communication non scuriss des transmissions dautorisations en texte clair la base de donnes.
Attaques
coute clandestine rseau
du
L'architecture de dploiement de la plupart des applications comprend une sparation physique entre le code d'accs aux donnes et le serveur de base de donnes. Les donnes sensibles, telles que les donnes spcifiques d'une application ou les autorisations de connexion la base de donnes, doivent par consquent tre protges contre les coutes clandestines de rseau.
Contre-mesure lapplication doit limiter et assainir les donnes saisies avant des les utiliser dans des requtes SQL utilisation de paramtres scuriss SQL pour accder aux donnes. Ces paramtres peuvent tre utiliss dans des procdures stockes ou dans des chaines de commandes SQL construites de manire dynamique. utilisation dun nom de connexion au serveur de base de donnes qui restreint les autorisations dans la base de donnes. Idalement, nous ne devons accorder dautorisations dexcution qu certaines procdures stockes slectionnes dans la base de donnes et ne pas fournir daccs direct la table utilisation de lauthentification du systme pour se connecter au serveur de base de donnes et viter denvoyer des informations didentification sur le rseau installation dun certificat de serveur sur le serveur de base de donnes. Ce certificat permet dobtenir un cryptage automatique des informations didentification SQL sur le rseau utilisation dune connexion SSL entra le
93

1
Accs autoris serveur
non au
L'accs direct notre serveur de base de donnes doit tre limit certains ordinateurs clients spcifiques pour empcher les accs non autoriss au serveur.
impossibilit de bloquer le port du serveur de base de donnes au niveau du pare-feu de primtre absence de stratgie de filtrage TCP/IP ou IPSec
Piratage de mot de passe
L'une des attaques type consiste essayer de dcouvrir les mots de passe des noms de compte bien connus.
mots de passe vierge ou faibles mots de passe contenant des mots usuels
il existe des outils tels que lanalyseur de requtes qui permettent dtablir une connexion directe avec le serveur de base de donnes et denvoyer des commandes les informations du serveur telles que la version des logiciels sont rvles lattaquant qui envoie des paquets construits avec soin pour couter les ports les attaques par dictionnaire la recherche manuelle de mot de passe
serveur web et le serveur de base de donnes pour protger les donnes sensibles des applications. Ce type de connexion ncessite un certificat de serveur de base de donnes utilisation dun canal crypt IPSec entre le serveur web et le serveur de bases de donnes veiller ce que les ports du serveur de base de donnes ne soient visibles en dehors du primtre du rseau au sein de ce primtre, limiter laccs direct des htes non autoriss en utilisant par exemples des filtres IPSec ou TCP/IP
pour les comptes de connexion au serveur de base de donnes, crer des mots de passe rpondant des critres de complexits viter les mots de passe contenant des mots courants, figurant dans le dictionnaire
Tableau 18 : menaces et contre-mesures dun serveur de base de donnes
94

1
IV.4.5 Scurisation de lapplication web

IV.4.5.1 Prsentation Les concepteurs et dveloppeurs des applications web doivent faire face un grand nombre de difficults. La nature sans tat de HTTP signifie que le suivi de session par utilisateur relve dsormais de la responsabilit de l'application. Au pralable, l'application doit tre capable d'identifier l'utilisateur en faisant appel une forme ou une autre d'authentification. Sachant que toutes les dcisions d'autorisation ultrieures sont bases sur l'identit de l'utilisateur, il est essentiel que le processus d'authentification soit scuris et que le mcanisme de gestion de session utilis pour suivre les utilisateurs authentifis bnficie du mme niveau de protection. La conception de mcanismes d'authentification et de gestion de session ne constitue qu'une partie des difficults auxquelles les concepteurs et dveloppeurs des applications web sont confronts. D'autres difficults apparaissent du fait que les donnes d'entre et de sortie sont transmises sur des rseaux publics. La prvention de la manipulation des paramtres et la divulgation des donnes sensibles constituent d'autres problmes majeurs. Certains des principaux problmes devant tre rsolus en ayant recours des pratiques de conception scurise sont illustrs sur la figure 40.
Figure 40 : Problmes de conception des applications web IV.4.5.1 Conseils de conception
95

1
Catgories de vulnrabilit
Problmes dus une conception mdiocre Attaques ralises en insrant des chanes malveillantes dans des chanes de requte, des champs de formulaires, des cookies et des enttes HTTP. Il peut s'agir d'attaques d'excution de commande, de script inter-site (XSS), d'injection SQL et de dpassement de la capacit de la mmoire tampon.
Validation des entres
Authentification
Usurpation d'identit, dcodage de mot de passe, lvation des privilges et accs non autoris.
Autorisation
Accs des donnes confidentielles ou restreintes, falsification et excution d'oprations non autorises.
Gestion de la configuration
Accs non autoris aux interfaces d'administration, capacit mettre jour les donnes de configuration et accs non autoris aux comptes utilisateurs et aux profils de compte.
Instructions pour une conception scurise Ne vous fions pas la saisie ; envisageons la validation centralise des entres. Ne vous fions pas la validation ct client. Soyons prudent vis-vis des problmes de canonisation. Contraignons, rejetons et assainissons la saisie. Validons le type, la longueur, le format et la plage des donnes. Partitionnonsle site en zones anonymes, identifies et authentifies. Utilisons des mots de passe srs. Prenons en charge les priodes d'expiration des mots de passe et la dsactivation des comptes. Ne stockons pas d'informations d'identification (utilisons des hachages unidirectionnels). Cryptons les canaux de communication pour protger les jetons d'authentification. Ne transmettons les cookies d'authentification que sur des connexions HTTPS. Utilisons les comptes les moins privilgis. Envisageons la granularit de l'autorisation. Imposeons la sparation des privilges. Restreignons l'accs de l'utilisateur aux ressources de niveau systme. Utilisons des comptes de processus et de service les moins privilgis. Ne stockons pas d'informations d'identification en texte brut. Utilisons l'authentification et l'autorisation renforces sur les interfaces d'administration. Scurisons le canal de communication pour l'administration distance. vitons de stocker des donnes sensibles dans l'espace Web. vitons de stocker des secrets. Cryptons les donnes sensibles sur le rseau. Scurisons le canal de communication. Fournissons des contrles d'accs renforcs sur les magasins de donnes sensibles. Ne stockons pas de donnes sensibles dans des cookies persistants. Ne transmettons pas de donnes sensibles avec le protocole HTTP-GET.
Donnes sensibles
Divulgation d'informations confidentielles et falsification des donnes.
96

1
Gestion des sessions
Capture des identificateurs de session se traduisant par le piratage de session et l'usurpation d'identit.
Cryptographie
Accs des donnes confidentielles ou des informations d'identification de compte, ou les deux.
Manipulation des paramtres
Attaques de pntration de rpertoire, excution de commande et contournement des mcanismes de contrle d'accs (entre autres), se traduisant par la divulgation d'informations, l'lvation des privilges et le refus de service. Refus de service et divulgation d'informations sensibles de niveau systme.
Gestion des exceptions
Audit et journalisation
Absence de dtection des signes d'intrusion, incapacit authentifier les actions d'un utilisateur et difficults diagnostiquer les problmes.
Limitons la dure de vie d'une session. Scurisons le canal. Cryptons le contenu des cookies d'authentification. Protgeons l'tat d'une session des accs non autoriss. Ne dveloppons pas notre propre cryptographie. Utilisons les fonctions testes et prouves de la plate-forme. Conservons les donnes non cryptes proximit de l'algorithme. Utilisons l'algorithme et la taille de cl corrects. vitons la gestion des cls. Recyclons priodiquement nos cls. Stockons les cls dans un emplacement accs restreint. Cryptons l'tat des cookies sensibles. Ne vous fions pas aux champs que le client peut manipuler (chanes de requte, champs de formulaires, cookies, ou en-ttes HTTP). Validons toutes les valeurs envoyes par le client. Utilisons une gestion structure des exceptions. Ne rvlons pas les informations sensibles d'implmentation de l'application. N'enregistrons pas les donnes prives telles que les mots de passe. Envisageons une infrastructure de gestion centralise des exceptions. Identifions les comportements malveillants. Analysons et consignons l'activit travers toutes les couches de notre application. Scurisons l'accs aux fichiers journaux. Sauvegardons et analyons rgulirement les fichiers journaux.
Tableau 19 : instructions de conceptions dune application web
97

1
REALISATION DU CADRE
Postrieure aux diffrentes phases de conception, cette partie intitule ralisation du cadre va nous permettre de mettre en application les diffrents choix organisationnels et conceptuels effectues dans les phases prcdentes. De ce fait, elle regroupe les diffrents choix techniques (environnement, serveurs, langages, architecture) ncessaires une meilleure ralisation. Cette partie, en plus de rpertorier les outils utiles au dveloppement du cadre nous permettra aussi de prsenter certaines interfaces du cadre.
98
Ralisation du cadre

1
V REALISATION DU CADRE
V.1 Choix techniques
V.1.1 Architectures dapplication
En rgle gnrale, une application informatique peut tre dcoupe en trois niveaux d'abstraction distincts (figure 41) : La couche de prsentation, encore appele interface homme-machine (IHM), permet linteraction de lapplication avec lutilisateur. Cette couche gre les saisies au clavier, la souris, et la prsentation des informations lcran. Dans la mesure du possible, elle doit tre conviviale et ergonomique ; La logique applicative, les traitements, dcrivant les travaux raliser par lapplication. Ils peuvent tre dcoups en deux familles : les traitements locaux, regroupant les contrles effectus au niveau du dialogue avec l'IHM, visant essentiellement le contrle et l'aide la saisie, les traitements globaux, constituant lapplication elle-mme. Cette couche appele Business Logic ou couche mtier, contient les rgles internes qui rgissent une entreprise donne. Les donnes, encore plus exactement l'accs aux donnes, regroupant l'ensemble des mcanismes permettant la gestion des informations stockes par l'application.
Figure 41 : les trois niveaux dabstraction dune application informatique Ces trois niveaux pouvant tre imbriqus ou repartis de diffrentes manires entre plusieurs machines, leur dcoupage et leur rpartition permettent de distinguer les architectures applicatives suivantes : Ralisation du cadre
99

1
larchitecture un tiers larchitecture deux tiers larchitecture trois tiers larchitecture n-tiers V.1.1.1 larchitecture un tiers
Dans une application un tiers, les trois couches applicatives sont intimement lies et sexcutent sur le mme ordinateur. Nous ne parlons pas ici darchitecture client-serveur, mais dinformatique centralise. Dans un contexte multiutilisateur, on peut rencontrer deux types darchitecture mettant en uvre des applications un tiers : des applications sur site central (mainframe) des applications rparties sur des machines indpendantes communiquant par partage de fichiers
Historiquement, les applications sur site central furent les premires proposer un accs multi utilisateurs. Les utilisateurs se connectent aux applications excutes par le serveur central (le mainframe) laide de terminaux passifs se comportant en esclaves. Cest le serveur central qui prend en charge lintgralit de traitements, y compris laffichage qui est simplement dport sur des terminaux passifs.
Figure 42: Architecture dune application sur site central Ralisation du cadre
100

1
Cependant, avec larrive dans lentreprise des premiers ordinateurs personnels en rseau, il est devenu possible de dployer une application sur plusieurs ordinateurs indpendants (application un tiers dploy). Dans ce cadre, plusieurs utilisateurs se partagent des fichiers de donnes stocks sur un serveur commun. Le moteur de base de donnes est excut indpendamment sur chaque poste client. La gestion des conflits daccs aux donnes doit tre prise en charge par chaque programme de faon indpendante. V.1.1.2 larchitecture deux tiers Dans une architecture deux tiers, encore appele client-serveur de premire gnration ou client-serveur de donnes, le poste client se contente de dlguer la gestion des donnes un service spcialis. Ce type d'application permet de tirer partie de la puissance des ordinateurs dploys en rseau pour fournir l'utilisateur une interface riche, tout en garantissant la cohrence des donnes, qui restent gres de faon centralise. Le modle client-serveur met en uvre une conversation entre deux programmes que l'on peut opposer l'change fig matre-esclave qu'entretiennent les applications sur site central avec leurs terminaux passifs. Lors dune 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 rpondre au client.
Figure 43 : dialogue client-serveur
Le client provoque l'tablissement d'une conversation afin d'obtenir des donnes ou un rsultat de la part du serveur. :
101
Ralisation du cadre

1
Figure 44 : accs aux donnes en mode client serveur Cet change de messages transite travers le rseau reliant les deux machines. Il met en uvre des mcanismes relativement complexes qui sont, en gnral, pris en charge par un middleware. Ce dernier cit, dnomm littralement lment du milieu , est lensemble des couches rseau et services logiciel qui permettent le dialogue entre les diffrents composants dune application rpartie. Ce dialogue se base sur un protocole applicatif commun. Par ailleurs, lobjectif principal du middleware est dunifier, pour les applications, laccs et la manipulation de lensemble des services disponibles sur le rseau, afin de rendre lutilisation de ces derniers presque transparente.
Figure 45 : Positionnement du middleware entre client et serveur
102
Ralisation du cadre

1
V.1.1.3 larchitecture trois tiers Larchitecture trois tiers applique les principes suivants : les donnes sont toujours gres de faon centralise la prsentation est toujours prise en charge par le poste client la logique applicative est prise en charge par un serveur intermdiaire Par consquent, cette architecture appele encore client-serveur de deuxime gnration ou client-serveur distribu spare lapplication en trois niveaux de service distincts : premier niveau : laffichage et les traitements locaux (contrles de saisie, mise en forme de donnes) sont pris en charge par le poste client, deuxime niveau : les traitements applicatifs globaux sont pris en charge par le service applicatif, troisime niveau : les services de base de donnes sont pris en charge par un systme de gestion de base de donnes (SGBD).
Dans le cadre dune application web, le poste client prend la forme dun navigateur, le service applicatif est assur par un serveur HTTP et la communication avec le SGBD met en uvre des mcanismes bien connus des applications client-serveur de la premire gnration. Nous avons aussi, une nette distinction entre deux tronons de communication indpendants et dlimits par le serveur HTTP. le premier tronon relie le poste client au serveur Web pour permettre l'interaction avec l'utilisateur et la visualisation des rsultats. On l'appelle circuit froid et n'est compos que de standards (principalement HTML et HTTP). Le serveur web tient le rle de faade HTTP , le deuxime tronon permet la collecte des donnes, il est aussi appel circuit chaud. Les mcanismes utiliss sont comparables ceux mis en uvre pour une application deux tiers. Ils ne franchissent jamais la faade http, et de ce fait, peuvent voluer sans impacter la configuration des postes clients. V.1.1.4 choix dune architecture Afin de choisir une architecture pour lapplication, nous avons procd une tude compare des diffrentes architectures prcdemment prsentes. Partant de cette tude, nous avons obtenu le tableau suivant :
103
Ralisation du cadre

1
Architectures
Architecture un tiers (mainframe)
Avantages
grande facilit dadministration et haute disponibilit large palette doutils de conception, de programmation et dadministration utilisation optimale des ressources grce la centralisation et la puissance sur une seule et mme machine possibilits de traitements par lots (en batch) conception et mise en uvre simple existence de nombreux environnement de dveloppement richesse ergonomiques des applications rponse aux besoins dun utilisateur isol dploiement dans un environnement multiutilisateur envisageable
Inconvnients
interface utilisateur obsolte car il est en mode caractres lourdeur des interfaces graphiques
Architecture un tiers (application un tiers dploye)
saturation assez rapide du rseau lors de lexcution dune requte cohabitation instable de plusieurs moteurs de bases de donnes indpendants manipulant les mmes donnes conflits frquents lors des consultations, ou modifications simultanes dun mme enregistrement par plusieurs utilisateurs mise en pril de lintgrit des donnes difficult assurer la confidentialit des donnes. rserv des applications non critiques exploites par de petits groupes de travail (une dizaine de personnes au maximum) totale dpendance des modules dapplications vis--vis de la base de donnes (il nexiste pas de solution vritablement fiable et ouverte dans linterconnexion des SGBD) le manque de modularit lorsque toute la logique dapplication se trouve sur le poste client ne facilite pas la maintenance et la rutilisation (une modification de lapplication ou de la structure de la base de donnes ncessite un redploiement sur les postes clients) la rsolution des problmes de monte en charge dpend
Architecture deux tiers
utilisation dune interface utilisateur riche appropriation des applications par lutilisateur introduction de la notion dinteroprabilit simplification des contrles de scurit facilit des mises jour des donnes et des logiciels maturit des technologies supportant larchitecture client/serveur cohrence globale, simplicit de dveloppement, dexploitation et de
104
Ralisation du cadre

1
maintenance, meilleure ergonomie du poste de travail
Architecture trois tiers
une plus grande flexibilit et souplesse une scurit accrue, car la scurit peur tre dfinie indpendamment pour chaque service et chaque niveau de meilleures performances, tant donn le partage des tches entre les diffrents serveurs bonne fiabilit, disponibilit et une excellente volutivit centralisation dune grande partie de la logique applicative sur un serveur HTTP soulagement du poste client, car il ne prend en charge que la prsentation et les contrles de saisie reprise des avantages de larchitecture deux tiers
essentiellement des capacits du SGBD grande sollicitation du poste client ce qui le rend de plus en plus complexe et doit tre mis jour rgulirement (client lourd) la conversation entre le client et le serveur est assez bruyante et sadapte mal des bandes passantes troites ce type darchitecture est grandement rigidifi par les cots et la complexit de sa maintenance les solutions mises en uvre sont relativement complexes maintenir et la gestion des sessions est complique forte sollicitation du serveur HTTP la rduction de la charge du serveur passe par la mise en uvre de plusieurs serveurs dapplications
Tableau 20: comparaison des architectures dapplications Au vu de ce tableau, et compte tenu du cadre professionnel et institutionnel du projet, notre choix sest port sur une architecture trois tiers puisquelle offre une grande marge dvolution et est assez flexible. Nous pouvons compter aussi au nombre des motivations de ce choix, la possibilit dappliquer une scurit tous les niveaux de manire indpendantes, la rduction des charges du poste client ce qui le rend plus simple manipuler pour les noninformaticiens, et en outre la grande fiabilit et disponibilit du systme.
V.1.2 Serveurs physiques

Suite au choix dune architecture trois tiers, il nous est ncessaire de faire le choix des diffrents serveurs physiques. Ainsi, nous avons opt pour deux serveurs HP Proliant ML 150 Gnration 5 avec les caractristiques suivantes :
105
Ralisation du cadre

1
Mmoire Vive : 4GB PC2-5300 DDR2 ; Disque dur : 160GB 3G SATA 7 ; Processeur : Quad-Core Intel Xeon processor E5410 ; Prix. unitaire 113 152,00 186 784,00 120 224,00 28 704,00 41 600,00 49 504,00 24 544,00 Total
Description HP ML150G5 HP CTO Chassis HP ML150G5 E5410 FIO Kit HP 4GB REG PC2-5300 2x2GB LP Kit HP HH SATA DVD ROM Kit ML150G5 650W Power Supply FIO Kit HP 160GB 7.2k HP SATA ETY 1y Wty HDD HP SAS/SATA 4 in 1 to 4 in 1 Cable
Quantit 1 1 1 1 1 1 1
Remise 1,00% 1,00% 1,00% 1,00% 1,00% 1,00% 1,00%
Total 112 020,48 184 916,16 119 021,76 28 416,96 41 184,00 49 008,96 24 298,56 558 866,88
Tableau 21: devis dun serveur HP Proliant ML 150 Ces serveurs ont t choisis parce quils ont de hautes performances, peu onreux et avec des opportunits dextension importantes pour une entreprise.
V.1.3 Systmes dexploitation

Dfini comme le programme de base de tout ordinateur, le systme dexploitation est un ensemble de programmes responsables de la liaison entre les ressources matrielles dun ordinateur et les applications informatiques de lutilisateur. Il permet de dissocier les programmes et le matriel, afin notamment de simplifier la gestion des ressources et offrir lutilisateur une interface homme-machine simplifie pour lui permettre de saffranchir de la complexit de la machine physique. Outre ces fonctions gnriques, le systme dexploitation accomplit plusieurs tches telles que : la gestion du processeur la gestion de la mmoire vive la gestion des entres et sorties la gestion de lexcution des applications
106
Ralisation du cadre

1
la gestion des droits la gestion des fichiers De nos jours, nous recensons une multitude de systmes dexploitation dont : OS/2 de IBM, Mac OS, Windows, GNU/Linux, etc. Dans le cadre de notre projet, le choix dun systme dexploitation savre ncessaire puisque cest ce systme qui fournira aux applications informatiques des points dentres gnriques, fiables et stables pour les priphriques. Ainsi, le choix dun mauvais systme dexploitation peut avoir un impact sur lefficacit, la disponibilit et le fonctionnement de notre application. Pour ce faire, nous avons tudi les deux systmes les plus connus, qui sont : Windows (dans sa version Server) et Linux. V.1.3.1 Windows Windows est une gamme de systmes dexploitation produite par Microsoft, principalement destins aux machines compatibles lIBM Personal Computer (IBM PC ou PC). Cest le remplaant de Microsoft Disk Operating System (MS-DOS). Depuis les annes 1990, avec la sortie de Windows 95, son succs commercial pour quiper les ordinateurs personnels est tel quil possde lheure actuelle un statut de quasi-monopole. Par ailleurs, la gamme de Windows est compose de plusieurs branches, dont la branche NT (News Technologies) apparue en 1993, et qui a t lobjet dune rcriture complte du systme, afin de convenir aux ordinateurs personnels comme au serveur. Cette branche sest principalement dveloppe dans le milieu professionnel, et est n du divorce de Microsoft et dIBM sur le dveloppement du systme dexploitation OS/2. Sinspirant de VAX VMS et dUnix, cette famille a apport des concepts nouveaux, comme la notion dobjet permettant une utilisation uniforme. Actuellement, Microsoft a prsent lors des TechDays 2008 qui se sont drouls du 11 au 13 fvrier 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 mme base de code que Windows Vista ; par consquent, ils partagent tous deux la mme architecture et les mmes fonctionnalits. Puisque la base de code est commune, Windows Server 2008 contient par dfaut la plupart des fonctionnalits techniques, de scurit, de gestion et d'administration nouvelles Windows Vista et aussi des innovations telles que : la rcriture de la couche rseau (IPv6 native, connectivit sans-fil native, amlioration de la scurit et de la vitesse); lamlioration du dploiement, de la rcupration et de l'installation base sur une image source; lamlioration des outils de diagnostics, de supervision, de traabilit des vnements et de rapports; lapport de nouvelles fonctionnalits de scurit telles que Bitlocker et ASLR; lamlioration du pare-feu Windows avec la configuration scurise par dfaut; une administration optimise de linfrastructure avec un modle du rseau fond sur des stratgies Ralisation du cadre
107

1
de nouvelles technologies de script et de contrles pour une gestion centralise des serveurs et lautomatisation des tches une scurit renforce et une meilleure gestion des serveurs situs lextrieur de lorganisation
Les processeurs et composants mmoire sont dfinis comme des priphriques Plug and Play, afin de permettre le "branchement chaud" (hot-plug) de ceux-ci. Cela permet aux ressources systme d'tre partitionnes de faon dynamique l'aide du module Dynamic Hardware Partitioning (littralement: "Gestion Dynamique du Partitionnement"); chacune disposant de sa propre partition de mmoire, processeur et pont d'hte E/S indpendante les unes des autres. V.1.3.2 GNU/Linux Linux, ou GNU/linux est un systme dexploitation compatible POSIX. Linux est bas sur le noyau Linux, un logiciel libre cr en 1991 sur un ordinateur compatible lIBM PC (PC) par Linus Torvalds. Ce dernier, qui au dbut des annes 1990 voulait mettre au point son propre systme dexploitation pour son projet de fin dtudes, dcida de dvelopper une version UNIX pouvant tre utilise sur une architecture de type 80386. Pour y parvenir, il conclut dtendre les possibilits de Minix (premier clone dUNIX fonctionnant sur PC et crit par Andrew Tanenbaum), en crant ce qui allait devenir Linux. Attires par cette initiative, de nombreuses personnes ont contribu aider Linus Torvalds raliser ce systme, si bien quen 1991 une premire version du systme a vu le jour. Cest en mars 1992 qua t diffuse la premire version ne comportant quasiment aucun bogue. Dvelopp sur Internet par des milliers dinformaticiens souvent bnvoles, Linux fonctionne maintenant sur du matriel allant du modem au superordinateur. GNU/Linux tant gratuit, diffrentes socits lon reprit et complt afin de distribuer un systme dexploitation visant des publics (figure 46) et caractris par sa portabilit, sa stabilit, sa robustesse et sa conformit aux standards.
Figure 46: les distributions de Linux
108
Ralisation du cadre

1
Parmi les plus connus, nous pouvons citer : Debian qui est une distribution non commerciale rgie par le contrat social Debian. Elle se distingue par le trs grand nombre darchitectures supportes, son importante logithque et par son cycle de dveloppement relativement long, gage dune certaine stabilit. Fedora qui est une distribution communautaire supervise par RedHat. Mandriva Linux qui est une distribution internationale dite par la socit Mandriva en France et dans le monde. Trs oriente grand public, elle est conue pour tre facile dinstallation et dusage pour les dbutants et les professionnels. Gentoo est une distribution caractrise par sa gestion des paquetages la manire des ports BSD, effectuant gnralement la compilation des logiciels sur lappareil de lutilisateur. Elle est ddie aux utilisateurs avancs, aux dveloppeurs et aux passionns. RedHat (officiellement RedHat Enterprise Linux ou RHEL) est une distribution commerciale largement rpandue dans les entreprises (surtout aux tats-Unis). Slackware est lune des plus anciennes distributions existantes. Slackware a t historiquement une des premires permettant de faire tourner GNU/Linux in situ depuis un CD-ROM ds 1995. Slackware est toujours maintenue par son crateur Patrick Volkerding et est particulirement adapte aux utilisations serveur. Cest la version la plus pure de GNU/Linux. Suse Linux a t la premire distribution europenne. Cre en 1993 Nuremberg, elle a t rachete par la socit Novell la fin de lanne 2003. Elle propose deux distributions principales : SUSE Linux Enterprise oriente vers les entreprises (certifications matrielles et logicielles nombreuses) et openSUSE oriente vers le grand public Ubuntu, base sur Debian. Plus oriente vers le grand public, dite des versions stables plus frquemment. Elle est maintenant disponible en live CD. Cette distribution dispose dune solide base dutilisateurs en France, et partout ailleurs.
109
Ralisation du cadre

1
V.1.3.3 Choix dun systme dexploitation Dans loptique dune meilleure prise de dcision au niveau des systmes dexploitation, une tude comparative des deux systmes prsents prcdemment a t ralise. Cest ainsi que nous avons eu comme rsultat le tableau suivant :
110
Ralisation du cadre

1
Systmes dexploitation Windows
Prise en main Prise en main assez aise grce une interface pure et intuitive, prsence de nombreux assistant pour guider lutilisateur dans ses taches
GNU Linux
Linux exige plus de temps pour le maitriser. La courbe dapprentissage est plus raide, mais plus avance. Cependant avec des distributions rcentes comme Ubuntu, Mandriva ou Xandros, la simplicit dutilisation a augment
Cot dexploitation Windows est assez onreux, de plus quil faut dbourser de largent pour acqurir dautres logiciels indispensables. Par ailleurs, Windows au fil du temps devient gourmand en ressources. Beaucoup de distributions de Linux sont gratuites et assez bien abouties. Elles viennent aussi avec bon nombre de logiciels quil suffit dinstaller sur des postes qui ne sont pas ncessairement puissants.
volution Au fil des annes, Windows abandonne le suivi de ses anciennes versions. Ce qui envoie les utilisateurs suivre de manire force lvolution en achetant les versions les plus rcentes. Avec Linux les mises jour sont continuelles et incrmentales afin de permettre une volution volontaire.
Scurit Windows est configur par dfaut de faon moins stricte afin de faciliter la vie de lutilisateur, mais aussi celle des personnes et logiciels malveillants. Il faut attendre des mois pour avoir le correctif dune faille dcouverte. Or les failles dcouvertes sont dune grande ampleur (faille RPC : virus blaster). La gestion interne de la scurit dans Linux lui confre un statut dun systme sr, car elle le rend moins sensible aux virus et vers. Les failles de scurit sont assez rapidement corriges (gnralement dans les 24 heures). Son code ouvert contribue aussi sa scurit puisque quiconque peut vrifier sil y a des logiciels espions lintrieur.
Ouverture et respect des standards Sous Windows il est souvent ncessaire dacheter ou installer des logiciels supplmentaires pour raliser des actions. Les standards sont souvent mal respects ce qui rend linterconnexion des systmes complique.
Dcouplage de systme et des logiciels La base de registre contient la configuration du systme dexploitation et de tous les logiciels. Si elle est endommage, cest tout le systme qui devient instable. Ainsi, le mauvais fonctionnement dune application ou son installation peut ncessiter un redmarrage pour que Windows se stabilise. Sous Linux, le systme et les programmes sont dans des environnements bien spars, puisque la configuration de chaque logiciel est enregistre dans des fichiers spars ce qui est un gage de stabilit puisque la dsinstallation, linstallation ou une erreur dune application ne peut pas agir gnralement sur le systme entier.
Linux est trs ouvert aux standards. Cela fait que Linux est facile interconnecter aux autres systmes. Grce a sa conformit aux standards, Linux est un systme de choix pour tout ce qui concerner le rseau et les communications
Tableau 22 : Comparaison des systmes dexploitation
111
Ralisation du cadre

1
En nous basant sur cette comparaison, nous avons opt pour le systme dexploitation GNU\Linux puisquil 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 daccs, mais encore cause de son volutivit et de la forte communaut de dveloppeurs qui sattlent corriger au plus vite les failles rencontres dans le systme. Il est noter que nous avons opt plus particulirement pour la distribution Debian car elle entirement gratuite, sa qualit et son srieux sont unanimement reconnus, et enfin parce quelle est trs utilise par les serveurs.
V.1.4 Serveurs web

N en 1990 au CERN des travaux de Tim Berners Lee, le premier serveur HTTP Nexus dlivrait des pages HTML statiques au navigateur web www. Aujourd'hui, la principale mission des serveurs web dynamiques porte sur l'accs aux applications et aux donnes de l'entreprise, qui permet, par exemple, d'exploiter un progiciel en ligne. Et ce, au moyen de transactions effectues par des interprteurs de scripts ou des classes techniques (Perl, VB, JS, ADO.NET , JDBC...), qui traduisent des requtes HTTP en commandes adresses au systme d'exploitation. L'autre type de transaction repose sur l'accs un site scuris. Les requtes HTTP sont alors chiffres sur une couche SSL (HTTPS) afin d'accder un serveur HTTP qu'authentifie un certificat. Plusieurs annes dexistence ont consolid le march des serveurs, au point quil ne regroupe aujourdhui quune poigne 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 dbut, 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 rpandu. 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 compltement rcrit, de sorte que, dans la version 2, il ne reste pas de trace de NCSA HTTPd. De plus, cette dernire version possde plusieurs avances majeures par rapport la version 1, entre autres : le support de plusieurs plateformes, le support de processus lgers UNIX, une nouvelle API et le support IPv6.
112
Ralisation du cadre

1
Il est noter que le serveur Apache fonctionne principalement sur les systmes d'exploitation Unix (GNU/Linux, BSD et UNIX) et Windows. La version Windows n'est considre comme stable que depuis la version 2 d'Apache. Et quil est utilis par de nombreux produits, dont Websphere d'IBM, ainsi que par Oracle Corporation. Il est galement support d'une faon ou d'une autre par les outils de dveloppement Borland Delphi et Kylix, ainsi que par des CMS comme Drupal. Cot conception, Apache est conu pour supporter de nombreux modules lui donnant des fonctionnalits supplmentaires : interprtation du langage Perl, PHP et Python, serveur proxy, Common Gateway Interface, Server Side Includes, rcriture d'URL, ngociation 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 dbut de l'histoire de ce produit, il y a eu de nombreux problmes de scurit. La mise en place de site tait trs abordable mais il n'y avait aucune scurit. Microsoft est donc repartie de zro pour la sixime version de leur serveur. Au volet fonctionnalits, Microsoft IIS : supporte de nombreuses technologies telles que ASP, .NET, le PHP ou encore le CGI. utilise une mtabase texte qui permet de faire des sauvegardes et des restaurations en cas de problmes critiques sur le serveur. possde des fonctionnalits de rsolutions de problmes et la possibilit de rcupration de mtabase endommage. dtecte galement les problmes de pertes de mmoire, les violations d'accs et autres erreurs. permet la tolrance des pannes et le redmarrage des processus si ncessaire.
113
Ralisation du cadre

1
Au niveau des parts de march, IIS possde environ 30% de celles-ci mais la commercialisation de la version 6.0, a redonn un nouveau souffle ce produit. En effet actuellement, il possde une croissance de 4.25%. V.1.4.3 Sun Java System Web Server Sun One Web Server est une solution prouve par plus de 50% des sites des entreprises classes au Fortune 100, particulirement sensibles aux notions de haute disponibilit et de continuit de service. Il rsiste aux fortes montes 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 paramtres de configuration et dot de gnrateurs de statistiques et de rapports, la dclaration de sites web par le biais d'instances se rvle peu conviviale.
Pour revenir sur laspect technique de ce serveur, il possde la version 1.1 du protocole HTTP fond sur lexploitation des servlets (applications Java fonctionnant du ct serveur). Il intgre la technologie de pages JSP, la possibilit de dclaration de sites virtuels scuriss (SSL 3.0, TLS 1.0) et non scuriss, au sein d'une mme instance de serveur web. Le serveur Sun est prt pour IPv6 et intgre 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 dun filtrage d'en-ttes HTTP et de contrle des ressources par serveur virtuel (bande passante, connexion) La solution de Sun, disponible pour de nombreux systmes dexploitation est destine 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. dveloppe 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'lment fondamental d'Internet, Zeus a cr une gamme de produits logiciels puissants et trs 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 possde une impressionnante clientle et des partenaires stratgiques, incluant des entreprises de classe mondiale, comme eBay, Hewlett- Packard, SGI, Sprint, Telefonica et UUNET, qui lui ont permis de connatre une croissance constante depuis sa cration ne 1995. Destin aux environnements Linux, Unix et Mac OS X, Zeus Web confirme sa rputation de serveur multi plate-forme scurise. Il assure par exemple le rglage des ressources systme (temps processeur, bande passante) alloues une session scurise de type SSL. Il intgre aussi une base de droits qui vite la mise en place d'un plan de nommage
114
Ralisation du cadre

1
au moyen d'un annuaire LDAP externe. Enfin, il assure la dtection d'une signature d'attaque par dni de service (scriptSnort) et le filtrage des en-ttes HTTP. Muni d'un rpartiteur de charge, il prsente par ailleurs une interface d'exploitation trs ergonomique. Simple et complte, Web Controller permet de procder des rplications ou des modifications par lot de sites au moyen dune slection manuelle. Grce un partenariat avec Zend, spcialiste de l'optimisation du code PHP, Zeus Web Server assure de bonnes performances pour la gnration dynamique des sites crits l'aide de ce langage. En outre, il propose un interfaage natif avec le serveur d'application libre Tomcat. Un autre atout est le support de Webdav, un standard de l'IETF, pour grer la codition de documents sur le Web. Autres fonctions qui mritent l'attention: un traitement la vole des redirections d'URL ou encore un moteur optimis pour des flux bidirectionnels gnrs par exemple par l'exploitation de "Web Services". V.1.4.5 Choix dun serveur web Afin de porter un choix judicieux et adapt nos besoins, nous avons tabli un tableau comparatif des diffrents serveurs web dominant le march.
115
Ralisation du cadre

1
Critres Apache
Prise en main et installation Complexit de paramtrage, car seffectue en ligne de commande ou avec une interface web peu conviviale et ergonomique
tendue des fonctions de scurit Exploitation de diffrents processus au sein de plusieurs flots dexcution, base de droit intgre pour la gestion des utilisateurs
Performances Peu gourmand en ressources matrielles, excellente stabilit
Environnements Linux, Windows, de nombreux UNIX, MacOs X
Cot gratuit
volutivit Sa modularit et sa gratuit font que ses failles de scurits sont assez rapidement rsolues et permettent aussi le dveloppement de plusieurs extensions
Microsoft IIS
Existence de plusieurs assistants qui guide tout au long de lutilisation
Sun Java System Web Server
Installation en ligne de commande moins conviviale quoiquefficace avec lapparition de menus adapts Linterface HTML Web Controller centralise lensemble des oprations dinstallation, de configuration et dexploitation
Zeus Web Server
Adoption de rgles de cloisonnement pour offrir une certaine stabilit, mcanisme de sauvegarde des donnes de configuration Adoption de rgles de cloisonnement pour offrir une certaine stabilit, mcanisme de sauvegarde des donnes de configuration Adoption de rgles de cloisonnement pour offrir une certaine stabilit, base de droit intgre pour la gestion des utilisateurs,
Trs gourmand en ressources matrielles,
Windows Server 2000, Windows Server 2003, Windows Server 2008 Linux, Windows, de nombreux UNIX, MacOs X
Inclus dans la branche des serveurs de Windows Logiciels propritaires, il faut souvent attend un certain temps avant dobtenir de nouvelles versions
Dot de gnrateurs de statistiques et de rapports qui le rendent assez pratique, destin aux entreprises exploitant des serveurs dapplication Java Peu gourmande en ressources matrielles, capacit tenir de trs gros pics de frquentation, interface native avec certaines bases de donnes
100$ par utilisateur et par an.
Linux, de nombreux UNIX, MaxOs X
1900 euros
Tableau 23: Comparaison des serveurs web
116
Ralisation du cadre

1
Face aux diffrents rsultats de la comparaison, nous avons choisi comme serveur web, Apache car il est entirement gratuit, il possde une panoplie dextensions utiles, il est bas sur prcdent dveloppement de qualit (notorit), il est le fruit de ladoption de plusieurs choix techniques populaires, il est un produit qui a une image de marque prserve et renforce par la qualit du produit (performance et scurit) il est modulaire ce qui encourage linnovation et la personnalisation il possde une forte communaut dutilisateurs et de dveloppeurs 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 Systme de gestion de bases de donnes (SGBD)

La fonction premire d'un Systme de Gestion de Base de Donnes (SGBD) est d'tre un outil de stockage d'informations offrant des fonctions simples de manipulation de grands volumes de donnes. Lun des avantages de ces SGBD est que l'interrogation de ces informations seffectue dune manire indpendante de l'architecture physique de stockage. Les SGBD garantissent la cohrence de ces donnes en cas de mise jour simultane par plusieurs utilisateurs. Les transactions assurent l'intgrit des donnes en cas d'oprations incorrectes ralises par un programme ou un utilisateur. Les donnes stockes dans un SGBD sont dites persistantes, leur fiabilit et leur rcupration en cas de panne matrielle ou logicielle doivent tre toujours possibles. De plus, le SGBD doit assurer la confidentialit des donnes en cas d'accs malveillant ou accidentel. Les fonctionnalits essentielles d'un SGBD sont donc les suivantes : Le systme doit assurer la persistance des donnes : lorsquune transaction (ensemble de requtes) est valide, les donnes doivent tre persistantes, c'est--dire quelles doivent tre enregistres de manire permanente. Le systme doit assurer la fiabilit des donnes : une transaction doit tre atomique, autrement dit, soit excute compltement, soit pas du tout. Des mcanismes de reprise sur panne doivent tre prsents. La panne dune mmoire doit assurer la fiabilit des donnes. Le systme doit offrir la possibilit plusieurs utilisateurs de manipuler les donnes concurremment. Il doit au minimum assurer la srialisation des transactions.
117
Ralisation du cadre

1
La srialisation des transactions est l'excution en parallle dun ensemble de transactions, produisant le mme rsultat que si elles taient excutes en srie. Le systme doit offrir la possibilit l'utilisateur d'interroger la base de faon simple. Le langage de requte SQL a t cr dans le but d'interroger, de manire relativement simple, les bases de donnes. Il peut tout de mme tre remplac, pour le nophyte par une interface graphique. Le systme doit assurer la confidentialit des donnes. La notion d'utilisateur et de droits associs (droits de lecture, d'criture et d'excution sur les objets de la base) est indispensable afin dassurer cette confidentialit. Le systme doit galement prvoir des mcanismes de cession et de retrait de droits. Le systme doit pouvoir efficacement grer les demandes : les performances doivent tre suffisamment bonnes. Pour cela, le SGBD doit utiliser des techniques d'indexation, d'optimisation de requtes et de gestion de caches. De plus, il est essentiel que le SGBD puisse facilement voluer et sadapter laugmentation du nombre de requtes et celle de lespace de stockage, cette augmentation se produisant immanquablement au fil des ans.
Aprs avoir recens les principes gnraux des bases de donnes, nous allons procder maintenant la prsentation des diffrents SGBG sur le march. V.1.5.1 MySQL MySQL est un systme de gestion de base de donnes (SGDB) qui selon le type dapplication, est libre ou propritaire. Il fait partie des logiciels de gestion de base de donnes les plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels. Dvelopp par MySQL AB, qui a t achet le 16 janvier 2008 par Sun Microsystems pour un milliard de dollars amricains, MySQL est un serveur de base de donnes relationnelle SQL dvelopp dans un souci de performances leves en lecture, ce quil signifie qu il est davantage orient vers le service de donnes dj en place que vers celui de mises jour frquentes et fortement scurises. Il est multithread et multiutilisateur. Il fonctionne sur de nombreux systmes dexploitation diffrents incluant : AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, Windows, OpenBSD, OS/2 Warp, et bien dautres. MySQL possde plusieurs systmes de fichiers notamment MyIsam, InnoDB, BDB, etc. les fonctionnalits supportes, comme les cls trangres ou les transactions sont diffrentes en fonction du systme de fichier choisi.
118
Ralisation du cadre

1
V.1.5.2 PostgreSQL PostgreSQL est un systme de gestion de base de donnes relationnelle et objet (SGBDRO). Cest un outil libre disponible selon les termes dune licence de type BSD. Ce systme est fond sur une communaut mondiale de dveloppeurs et dentreprises. Il est capable de stocker plus de types de donnes que les types traditionnels entiers, caractres, etc. Lutilisateur peut crer des types, des fonctions, utiliser lhritage de type. Au nombre des environnements supports, 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 laide dun mulateur de type cygwin. Par ailleurs, PostgreSQL est sans aucun doute, le systme de gestion de base de donnes code ouvert le plus avance au monde. Il possde les caractristiques des systmes commerciaux les plus puissants dont : le support complet pour transactions le support complet ACID (Atomicity Consitency Isolation Durability) lorientation objet avec hritages des tables. V.1.5.3 Microsoft SQL-Server SQL Server est un SGBDR dvelopp et commercialis par Microsoft. Initialement co-dvelopp par Sybase et Microsoft, Ashton-Tate ayant aussi t associ la premire version qui est sortie en 1989. Cette version est sortie sur les plateformes Unix et OS/2. Depuis Microsoft a port ce systme de base de donnes sous Windows et il est maintenant uniquement support sur ce systme. En 1994 le partenariat entre les 2 socits 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 donnes 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 dsormais partie de la stratgie technique de Microsoft en matire de base de donnes. Le moteur MSDE qui est la base de SQL Server doit terme remplacer le moteur Jet (celui qui gre les bases Access) dans les applications telles qu Exchange et Active Directory. Il est idal pour les dveloppements spcialiss dans les produits Microsoft : ASP, Visual Basic, modles dobjet composants. En outre, cest un systme de base de donnes parfaitement adapt pour des applications critiques, et avec nimporte quel niveau de
119
Ralisation du cadre

1
complexit. De plus, il utilise une partie de lespace de la base de donnes pour sauvegarder le log des transactions avec les commandes restantes, ce qui assure quen aucun cas, indpendamment si le programmeur utilise des transactions sur son code, la base de donnes de donnes reste dans un tat inconsistant d une excution partielle des commandes. Il est remarquer que ce systme offre beaucoup dautres caractristiques avances, orientes maintenir lintgrit de la base de donnes, 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 dvelopp par Lawrence Ellison, accompagn dautres 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 fonctionnalits telles que : le support de SQL, PL/SQL et de Java la possibilit de monter la base de donnes sur plusieurs serveurs (grid en 10g, rac en 9i) la possibilit de gestion de donnes gographiques, le partitionnement physique des donnes en sous-ensemble pour optimiser les temps daccs lintgration du moteur OLAP qui permet de stocker les cubes sous forme de BLOB (Binary Large Object) la gestion de trs grands volumes de donnes, la rplication des donnes selon diffrents mode synchrone ou asynchrone de tout ou une partie dune base de donnes. Ce systme est disponible sous les environnements suivants : Linux, Windows, Unix, Mac OS X. V.1.5.5 Choix dun SGBD Compte tenu des fonctionnalits plus ou moins avances de chaque SGBD, une tude comparative nous a sembl ncessaire afin de choisir le SGBD le plus adapt notre projet.
120
Ralisation du cadre

1
MySQL
Points forts solution trs courante en hbergement public trs bonne intgration dans lenvironnement Apache/PHP OpenSource, bien sue les critres de licences soient de plus en plus difficiles supporter version cluster depuis la version 4 facilit de dploiement plusieurs moteurs de stockage adapts aux diffrentes problmatiques gratuit rapidit dexcution des requtes
Points faibles ne supporte quune faible partie des standards SQL-92 supports incomplets des triggers et procdures stockes gestion des transactions que depuis la version 4 avec InnoDB assez peu de richesse fonctionnelle manque de robustesse avec de fortes volumtries pas dhritage de table pas de vue matrialise pas dordonnanceur intgr pas de partitionnement cluster par clonage de base / impact sur la volumtrie
PostgreSQL
opensource et gratuit fiable et relativement performant, tout en restant simple dutilisation supporte la majorit du standard SQL-92 et possde en plus un certain nombre dextensions (Java, Ruby, PL-SQL) trs riche fonctionnellement, multitude de modules simple dutilisation et dadministration hritage de tables solution en cluster possible
SQL Server
Administration aise Indpendance entre les diverses bases, facilitant l'intgration de plusieurs applicatifs dans une mme instance Une des bases les plus performantes sous Windows en configuration par dfaut Optimiseur statistique enrichi flux tendu Rplication intgre (sauf pour MSDE) Frontaux et assistants trs pousss (sauf pour MSDE) Langage T-SQL trs convivial, intgration de CLR Sous-SELECT possible dans clause FROM
sauvegardes peu volues supporte les bases de donnes de moyenne importance pas de service web pas de support XML pas dordonnanceur intgr pas de vue matrialise permissions seulement au niveau de la table, pas au niveau de la colonne solutions de rplications pas encore totalement russis cluster par clonage de base : impact sur la volumtrie lenteur dans les excutions des requtes lourdeur Distributions fortement lies au systme d'exploitation Mono-plateforme (MS Windows) Depuis la version 2005, plus de prise directe sur les tables systme (remplaces par de vues systme) Pas possibilit de donner des priorits 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'intgration Java,
121
Ralisation du cadre

1
Gestion de l'indexation textuelle Services Web Support XML Ordonnanceur intgr
orientation C# Pas d'hritage de table Fonctionnalits s'loignant des normes en vigueur (CLR remplaant Java, fonctions dans clauses FROM, ...)
Oracle
Richesse fonctionnelle Row level storage security (RLSS) : permet de ne faire apparatre que certaines lignes des tables pour un utilisateur/une application donne. Intgration LDAP, SSL, Unicode; rplication intgre; capable de mapper un fichier plat en table Paralllisme, caches nomms; haute disponibilit; grande possibilit de tuning Compression des backups Procdures stockes en PL-SQL (langage propritaire Oracle, orient ADA) ou ... en JAVA (depuis la 8.1.7) ce qui peut s'avrer utile pour les quipes de dveloppement. Assistants performants via Oracle Manager Server, possibilit de grer en interne des tches et des alarmes Gestion centralise de plusieurs instances Concept unique de retour arrire (Flashback) Prennit de l'diteur : avec plus de 40% de part de march, ce n'est pas demain qu'Oracle disparatra Rglages fins : dans la mesure o l'on connait suffisamment le moteur, presque TOUT est paramtrable. Accs aux donnes systme via des vues, bien plus aisment manipulables que des procdures stockes. Interface utilisateur remanie et extrmement riche, permettant - enfin ! - le tuning fin de requtes par modification des plans d'excution. Architecture Multi-Gnrationnelle (MGA) Services Web, support XML Ordonnanceur intgr
Prix exorbitant, tant au point de vue des licences que des composants matriels (RAM, CPU) fournir pour de bonnes performances Administration complexe... lie la richesse fonctionnelle Fort demandeur de ressources, ce qui n'arrange rien au point prcit, Oracle est bien plus gourmand en ressource mmoire que ses concurrents, ce qui implique un investissement matriel non ngligeable. Porosit entre les schmas = difficile de faire cohabiter de nombreuses applications sans devoir crer plusieurs instances. Il manque rellement la couche "base de donnes" au sens Db2/Microsoft/Sybase du terme. Mta modle propritaire, loin de la norme. Tables partitionnes, RAC... uniquement possible l'aide de modules payants complmentaires sur la version Enterprise. Gestion des verrous mortels mal conue (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 gnraux, statistiques rgnrs par saccade...) Tables systme peu documentes Une quantit de bogues proportionnelle la richesse fonctionnelle, surtout sur les dernires versions Gestion erratique des rles et privilges (pas possible de donner des droits sur des schmas particuliers sans passer par leurs objets, dsactivation des rles lors d'excution de packages...) Nombreuses failles de scurits lies l'architecture elle-mme
Tableau 24 : Comparaison des SGBD
122
Ralisation du cadre

1
Aprs la ralisation de cette comparaison, nous avons arrt notre choix sur MySQL qui malgr les inconvnients savre tre le SGBD ayant la plus grande vitesse dexcution des requtes. Or nous savons que la rapidit dexcution est un facteur important dans la conception dune application web. De plus, ce SGBD est gratuit et possde une grande famille dutilisateurs 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 annes 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 automatises. C'est l'une des fonctions d'un langage de script ct serveur, parmi d'autres, comme la connexion une base de donnes, la gnration 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 sexcutent sur les serveurs sont une multitude de nos jours. Nous avons comme exemple : Java Server Pages (JSP), Active Server pages (ASP), HyperText Prprocesseur (PHP), Perl. V.1.6.1 PHP Le langage PHP (acronyme rcursif pour PHP: Hypertext Prprocesseur), est cr en 1994 par Rasmus Lerdorf pour son site Web. C'tait l'origine une bibliothque 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 fonctionnalits, Rasmus a transform la bibliothque en une implmentation en langage C, capable de communiquer avec des bases de donnes et de crer des applications dynamiques et simples pour le Web. Rasmus dcida 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, redvelopprent le cur de PHP/FI. Ce travail aboutit un an plus tard avec Zend Engine, le nouveau cur de PHP/FI, devenu alors PHP: Hypertext Preprocessor en version 3. Le langage PHP est utilis principalement en tant que langage de script ct serveur, ce qui veut dire que c'est le serveur (la machine qui hberge la page web en question) qui va interprter le code PHP et gnrer du code (constitu gnralement d'XHTML ou d'HTML, de CSS, et parfois de JavaScript) qui pourra tre interprt par un navigateur. Il peut galement
123
Ralisation du cadre

1
fonctionner comme n'importe quel langage interprt de faon locale, en excutant les programmes en ligne de commande. PHP peut de plus gnrer 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 conu pour permettre la cration d'applications dynamiques, le plus souvent ddies au Web. PHP est trs 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 rcuprer des informations issues d'une base de donnes, d'un systme de fichiers (contenu de fichiers et de l'arborescence) ou plus simplement des donnes envoyes par le navigateur afin d'tre interprtes ou stockes pour une utilisation ultrieure. C'est un langage peu typ et souple et donc facile apprendre par un dbutant mais, de ce fait, des failles de scurit peuvent rapidement apparatre dans les applications. Pragmatique, PHP ne s'encombre pas de thorie et a tendance choisir le chemin le plus direct. Nanmoins, le nom des fonctions (ainsi que le passage des arguments) ne respecte pas toujours une logique uniforme, ce qui peut tre prjudiciable l'apprentissage. Son utilisation commence avec le traitement des formulaires puis par l'accs aux bases de donnes. L'accs aux bases de donnes est ais une fois l'installation des modules correspondant effectue 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'hbergement. Libre, gratuit, simple d'utilisation et d'installation, ce langage ncessite comme tout langage de rseau une bonne comprhension des mcanismes sous-jacents ainsi qu'une connaissance des problmes de scurit. V.1.6.2 ASP Active Server Pages (ASP) est une technologie dveloppe par Microsoft utilise dans la programmation Web. C'est une technologie web dynamique, quivalente et concurrente de PHP. Elle ncessite pour fonctionner une plate-forme Windows avec IIS (Internet Information Services) install, ou encore une plate-forme Linux ou Unix avec une version modifie d'Apache. ASP n'est en ralit qu'une structure compose 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'interprtation du langage adquat IIS. l'inverse de certains langages de programmation pour ordinateur (C, C++), cette technologie n'utilise pas de langages compils, mais des langages interprts. Elle est capable
124
Ralisation du cadre

1
de se connecter des bases de donnes, de lire des fichiers XML et possde 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 mme technologie COM, condition de tourner galement sur un serveur Windows o les produits Office sont installs. Nomm COM (Component Object Model, aussi appel ActiveX), ce systme est linterface utilis par lASP 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 base sur Java qui permet aux dveloppeurs de gnrer dynamiquement du code HTML, XML ou tout autre type de page web. La technologie permet au code Java et certaines actions prdfinies d'tre ajouts dans un contenu statique. Depuis la version 2.0 des spcifications, la syntaxe JSP est compltement XML. Cette dernire ajoute des balises XML, appeles actions JSP, qui peuvent tre utilises pour appeler des fonctions. De plus, la technologie permet la cration de bibliothques de balises JSP (taglib) qui agissent comme des extensions au HTML ou au XML. Les bibliothques de balises offrent une mthode indpendante de la plate-forme pour tendre les fonctionnalits d'un serveur HTTP. Les JSP sont compiles par un compilateur JSP pour devenir des servlets Java. Un compilateur JSP peut gnrer un servlet Java en code source Java qui peut son tour tre compil par le compilateur Java, ou peut gnrer le pseudo-code Java interprtable directement. En plus des actions JSP prdfinies, les dveloppeurs peuvent ajouter leurs propres actions personnalises en utilisant l'API d'extension de balises JSP (JSP Tag Extension API). Pour ce faire, il faut crire une classe Java qui implmente une des interfaces de balises et crire le fichier XML de description de balise qui donne les caractristiques du marqueur et les classes qui l'implmentent. Par dfaut, le langage de script utilis est le Java ; cependant, les spcifications permettent d'employer d'autres langages, tout comme ASP autorisent le JScript et le VBScript. En dpit du fait que les pages JSP crites en Java restent plus flexibles et robustes que les scripts cods 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.
125
Ralisation du cadre

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 ct serveur qui permettent aux dveloppeurs de produire la plupart des oprations de gnration de contenus dynamiques sans la moindre ligne de code en Java. Ces balises sont plus particulirement destines aux dveloppeurs familiers aux scripts, voire aux graphistes n'utilisant que le HTML mais mme les dveloppeurs Java peuvent les utiliser pour obtenir des oprations avances dans les pages JSP. V.1.6.4 Perl Perl est un langage de programmation cr par Larry Wall en 1987 et reprenant des fonctionnalits du langage C et des langages de scripts sed, awk et shell (sh). Larry Wall donne deux interprtations de l'acronyme "PERL":

Practical Extraction and Report Language ou langage pratique d'extraction et de gnration de rapports Pathetically Eclectic Rubbish Lister ou collectionneur de dchets pathtiquement clectiques
Perl est un langage optimis pour extraire des informations de fichiers textes et imprimer des rapports bass sur ces informations. C'est aussi un bon langage pour de nombreuses tches d'administration systme. Il est crit dans le but d'tre pratique (simple utiliser, efficace, complet) plutt que beau (petit, lgant, minimaliste). Contrairement TCL/TK qui interprte ligne aprs ligne, l'interprteur Perl compile les scripts Perl pour ensuite les excuter, ce qui permet deux choses: des vrifications de syntaxe, et une trs grande vitesse d'excution. Perl est squentiel 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 systme d'exploitation un autre est extrme ! On peut mme 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 intgr Apache, le transformant en langage compil et cach en mmoire, le rendant aussi performant que du C. Le Perl combine les meilleures fonctionnalits de C, sed, awk et sh, de telle manire que les personnes familiarises ces langages ne devraient avoir aucune difficult avec celuici. La syntaxe se rapproche presque totalement de celle du C. Contrairement la plupart des utilitaires Unix, Perl ne limite pas arbitrairement la taille des donnes, si vous avez assez de mmoire, Perl peut remplir une chane de caractres avec le contenu total d'un fichier. Il n'y a pas de niveau maximum la rcursivit. Et les tables utilises par les tableaux de hachage (anciennement appel "tableaux associatifs") croissent ds que ncessaire afin de garantir un bon niveau de performance.
126
Ralisation du cadre

1
Perl utilise des techniques sophistiques de recherche de motif pour pouvoir traiter trs rapidement de trs grandes quantits de donnes. Bien qu'optimis pour le traitement des fichiers textes, Perl peut aussi traiter des donnes binaires, et faire que des fichiers dbm soit vus comme des tableaux de hachage. Les scripts Perl ayant leurs setuid bits positionns sont plus srs que des programmes C grce des mcanismes de suivi de flot de donnes qui permettent d'viter de nombreux trous de scurits particulirement stupides. V.1.6.6 Choix dun langage de script cot serveur Comme nous avons pu le voir dans les diffrentes sections consacres chacune un langage de script, les offres semblent au premier abord trs proches en valeur. Pour effectuer le choix du langage utiliser, un examen comparatif a t ralis.
Complexit dapprentissage Puissance Complexit/ Puissance Portabilit AGL Ressources
ASP Moyen Moyen Bon Faible MS visual InterDev Peu
JSP lev lev bon lev IBM VisualAge for Java Peu
PERL lev lev Bon lev Perl Builder Peu
PHP Faible Moyen lev Bonne
normment
Tableau 25: Comparaison des langages de scripts Suite cette comparaison, nous avons dcid dutiliser PHP pour sa faible complexit dapprentissage, sa puissance et sa portabilit. Il est de surcroit gratuit et bnficie du soutien de plusieurs personnes qui dveloppent des extensions plus utiles les unes par rapport aux autres. De plus, ce langage sinscrit dans le cadre dun environnement qui a fait ses preuves dans le domaine du web : lenvironnement LAMP (Linux Apache MySQL PHP). Au nombre des motivations de ce choix, vient sajouter le fait quil est t conu ds le dpart pour le dveloppement web et a repris les syntaxes de plusieurs langages prouvs tels que le C et de Perl. Il ne faudrait surtout pas oublier, la forte communaut qui corrige rapidement les failles de scurit dcouvertes.
V.2 Interfaces
Par considration pour les utilisateurs finaux du cadre qui ne sont pas des spcialistes de linformatique, nous avons dvelopp deux parties distinctes mais menant au mme objectif : renseigner la base de donnes. Il est signaler que ces parties font partie intgrante de linterface dadministration qui nest quune composante du cadre.
127
Ralisation du cadre

1
V.2.1 Interface classique dadministration

Liste des projets
Figure 47: Classique liste des projets Cette page permet de consulter tous les projets contenus dans la base de donnes. A partir des liens gauche, nous pouvons modifier ou supprimer un projet.
128
Ralisation du cadre

1
Ajouter un projet
Figure 48: Classique ajouter un projet Cette page permet dajouter un projet en definissant le sous-programme auquel il appartient et en renseignant aussi les champs obligatoires.
129
Ralisation du cadre

1
Modifier un projet
Figure 49: Classique modifier un projet Cette page permet de modifier les informations dun projet en modifiant les champs necssaires.
130
Ralisation du cadre

1
V.2.2 Assistant
Liste des programmes
Figure 50: Assistant liste des programmes Cette page permet de consulter tous les programmes contenus dans la base de donnes. 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.
131
Ralisation du cadre

1
Ajouter un programme
Figure 51: Assistant ajouter un programme Cette page permet dajouter un programme. Dans cette partie, lajout dun programme implique lajout de toutes ces composantes travers dautres formulaires. Lajout dun lement est automatiquement materialis par lapparition dune icne dans lexplorateur qui est droite de la page.
132
Ralisation du cadre

1
Modifier un projet
Figure 52: Assistant modifier un projet Cette page permet de modifier un projet, en parcourant les diffrentes composantes du programme laide de lexplorateur situe droite de la page.
133
Ralisation du cadre

1
Conclusion
Conclusion
Durant le stage effectu la Direction du Suivi-Evaluation pendant la priode davril mai 2008, il nous a t demand de raliser et de scuriser un cadre de gestion de projet. Plus prcisment, le cas du SIGPOD. Ce cadre a pour finalit une meilleure gestion et un meilleur suivi des projets travers la cration dune base de donnes et dune application web dinterfaage. Au cours de cette priode de dur labeur, nous avons travaill de concert avec le personnel de la DSE qui a t rellement formidable tant du point de vue des informations fournies, mais aussi de lassistance pour la ralisation de ce projet. ce jour, le bilan est tel que ; nous avons pu concevoir la base de donnes de la gestion des projets et aussi linterface dadministration qui servira la renseigner. Le dveloppement des autres interfaces est en cours de ralisation. De ce fait, nous avons mis la disposition du personnel de la DSE, linterface dadministration afin quil puisse la tester et apporter les suggestions ncessaires pour sa correction, mais aussi pour les autres interfaces raliser trs prochainement. Visiblement, ce stage nous a t dun apport bnfique en ce sens quil nous a permis : de travailler sur un projet de grande envergure et trs volutif, ce qui nous a permis dlargir nos domaines de connaissance dapprendre le dveloppement collectif dapplicatif de taille importante et de nous frotter aux mthodes danalyse et de conception dans un environnement rel
Au demeurant, nous esprons que le dveloppement intgral de cette application permettra la DSE de pouvoir amliorer son rendement de travail qui est dj excellent et aussi de disposer dun outil technique quelle pourra mettre en exergue dans les mois venir.
134
Conclusion

1
Liste des figures Liste des figures et des tableaux

Les figures 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.
et tableaux
rseau informatique du ministre la dmarche merise la courbe du soleil les vues dUML les diffrentes phases les activits le dveloppement itratif et incrmental les risques concepts de diagramme de cas dutilisation systme actuel diagramme de cas dutilisation concepts du diagramme dactivits systme actuel mise jour dune activit systme actuel validation dun indicateur systme actuel mise jour dinformations systme actuel consultation dinformations concepts du diagramme de classes systme actuel diagramme de classes ax sur les activits systme actuel diagramme de classes ax sur les projets systme futur diagramme de cas dutilisation systme futur diagramme de classes ax sur les activits systme futur diagramme de classes ax sur les projets systme futur consulter des informations systme futur mettre jour une activit systme futur valider un indicateur systme futur mettre jour des informations systme futur grer des profils systme futur activit concepts de la gestion des risques exemple dun risque le processus de gestion de risques les diffrentes zones de risques dmarche globale dEBIOS les principales phases dOCTAVE la dmarche globale de MEHARI approche globale de la scurit Liste des figures et des tableaux
135

1
36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52.
composants rseau : routeur pare-feu commutateur menaces du serveur web prdominantes et vulnrabilits courantes principales menaces et vulnrabilits dun serveur dapplications principales menaces et vulnrabilits dun serveur de base de donnes problmes de conception des applications web les trois niveaux dabstraction dune application informatique architecture dune application sur site central dialogue client-serveur accs aux donnes en mode client-serveur positionnement du middleware en mode client-serveur les distributions de Linux classique liste des projets classique ajouter un projet classique modifier un projet assistant liste des programmes assistant - ajouter un programme assistant modifier un projet
Les tableaux 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. rseau informatique du ministre liste du matriel informatique les diffrentes dclinaisons du processus unifi systme actuel mettre jour une activit systme actuel valider un indicateur systme actuel mettre jour des informations systme actuel consulter des informations les besoins fonctionnels les cas dutilisation systme futur mettre jour une activit systme futur consulter des informations systme futur valider un indicateur systme futur mettre jour des informations systme futur grer des profils comparaison des mthodes danalyses de risques menaces et contre-mesures dun rseau menaces et contre-mesures dun serveur web menaces et contre-mesures dun serveur dapplications menaces et contre-mesures dun serveur de base de donnes instructions de conception dune application web
136
Liste des figures et des tableaux

1
21. 22. 23. 24. 25. 26.
comparaisons des architectures dapplications devis dun serveur HP Proliant ML 150 comparaison des systmes dexploitation comparaison des serveurs web comparaison des SGBD comparaison des langages de script
137
Liste des figures et des tableaux

1
Rfrences bibliographiques Rfrences
bibliographiques
Buyens, fevrier 2001, Le guide du webmaster : trucs et astuces, France, Microsoft Press, 381p. Damien Seguy et Phillipe Gamache, fevrier 2006, Scurit 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 systme 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 scurit des systmes dinformations : lusage des directeurs, France, CNRS, 100p. Adou Aboua, 2007, Conception et mise en place dune solution de tlphonie IP : cas du Ministre dEtat Ministre du plan et du dveloppement : mmoire de fin dtude , INP-HB-EFCPC-CFCIP, Abidjan, 109p. Deli Zran, 2007, Mise en place dune plate-forme de surveillance dquipements et dapplications : alerte dexploitation (ALEX) : mmoire de fin dtude , INP-HB, Yamoussoukro, 109p. Steve Koffi Ano, 2005, Cration du site web dynamique de la marine nationale : mmoire de fin dtude , INP-HB, Yamoussoukro, 61p. Nicolas Mayer et JeanPhillipe Humbert, avril-mai 2006, la gestion des risques pour les systmes dinformation , MISC n 24, 60p, p10-22. Cases, 2005, Rfrentiel de scurit des applications web, consult le 12 mai 2008, http://www.case.lu. Sbastien Poggi, mais 2005, Rapport de veille sur les standards et mthodes en matire de scurit informatique, consult le 12 Mai 2008, http://www.case.lu. Sbastien Poggi, mais 2005, Etude compare de rfrentiels et mthodes utilises en scurit informatique, consult le 12 Mai 2008, http://www.case.lu. Ysosecure, 2008, Evolution des mthodes de gestion des risques informatiques, consult le 13 mai 2008, http://www.ysosecure.com Ysosecure, 2008, Les mthodes de gestion de risques, consult le 13 mai 2008, http://www.ysosecure.com
138
Rfrence bibliographiques

1
DCSSI, juillet 2004, Expression des Besoins et Identification des Objectifs de Scurit : 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 Scurit : Referentiel de comptences, consult le 14 mai 2008, http.//www.ssi.gouv.fr DCSSI, fvrier 2004, Expression des Besoins et Identification des Objectifs de Scurit : Section 1 Introduction, consult le 14 mai 2008, http.//www.ssi.gouv.fr DCSSI, fvrier 2004, Expression des Besoins et Identification des Objectifs de Scurit : Section 2 dmarche, consult le 14 mai 2008, http.//www.ssi.gouv.fr DCSSI, fvrier 2004, Expression des Besoins et Identification des Objectifs de Scurit : Section 3 Techniques, consult le 14 mai 2008, http.//www.ssi.gouv.fr DCSSI, fvrier 2004, Expression des Besoins et Identification des Objectifs de Scurit : Section 4 Outillage pour lappreciation des risques SSI, consult le 14 mai 2008, http.//www.ssi.gouv.fr CLUSIF, fvrier 2007, Mehari 2007 manuel de rfrences des services de scurit, consult le 14 mai 2008, http.//www.clusif.asso.fr CLUSIF, fvrier 2007, Mehari 2007 Enjeux, consult le 14 mai 2008, http.//www.clusif.asso.fr CLUSIF, fvrier 2007, Mehari 2007 Introduction, consult le 14 mai 2008, http.//www.clusif.asso.fr CLUSIF, fvrier 2007, Mehari 2007 analyse des risques, consult le 14 mai 2008, http.//www.clusif.asso.fr CLUSIF, fvrier 2007, prsentation Mehari, consult le 14 mai 2008, http.//www.clusif.asso.fr Hugo Etivant, aot 2006, Normes de scurit : les mthodes danalyse des risques, consult le 15 mai 2008, http://www.developpez.com. C.Alberts, A. Dorofee, J.Stevens, C.Woody, aot 2003, Introduction to the OCTAVE Approach, consult le 15 mai 2008, http://www.cert.org/octave. Microsoft, aot 2004, Scurisation des applications web, consult le 17 mai 2008, http:// msdn2.microsoft.com Rmi Leblond, dcembre 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, http://fr.wikipedia.org Communaut wikipedia, juin 2008, les sgbd, consult le 20 juin 2008, http://fr.wikipedia.org
139
Rfrence bibliographiques

1
Annexes
Annexes
Annexe 1 Organigramme du Ministre du Plan et du Dveloppement Annexe 2 Rpartition des normes et rfrentiels SSIC dans une perspective d'amlioration continue Annexe 3 Caractristiques dun rseau scuris Annexe 4 Pourcentage dutilisation des serveurs web
140
Annexes

1
Annexe 1
Organigramme du Ministre du Plan et du dveloppement
141
Annexes

1
Annexe 2
Rpartition des normes et rfrentiels SSIC dans une perspective damlioration continue
142
Annexes

1
Annexe 3
Caractristiques dun rseau scuris
Composant Routeur Correctifs et mises jour Protocoles Caractristique Le systme d'exploitation du routeur est corrig avec un logiciel mis jour. Les protocoles et les ports inutiliss sont bloqus. Le filtrage entrant et sortant est activ. Le trafic ICMP est analys depuis le rseau interne. Les messages concernant l'expiration de la dure de vie de valeur 1 ou 0 sont bloqus (la dtermination d'itinraires est dsactive). Le trafic de diffusion dirig n'est pas transfr. Les paquets ping volumineux sont analyss. Les paquets du protocole RIP (Routing Information Protocol), si celui-ci est utilis, sont bloqus au niveau du routeur le plus extrieur. Les interfaces de gestion inutilises sur le routeur sont dsactives. Une stratgie trs stricte est applique en matire de mot de passe d'administration. Le routage statique est utilis. L'administration Web est dsactive. Les services inutiliss sont dsactivs (par exemple bootps et Finger). La journalisation de tout le trafic refus est active. Les journaux sont stocks de manire centralise et scurise. L'audit des journaux est mis en place pour les situations inhabituelles. Des systmes IDS sont mis en place pour identifier et informer d'une attaque active. Le logiciel de pare-feu et le systme d'exploitation sont corrigs avec les dernires mises jour de scurit. La politique de filtrage de paquets bloque tout le trafic dans les deux directions, l'exception des donnes requises. Les filtres d'application spcifiques sont mis en place pour limiter le trafic inutile. Tout le trafic autoris est enregistr. Le trafic refus est enregistr. Les journaux changent selon une frquence permettant d'effectuer une analyse rapide des donnes. Tous les priphriques du rseau sont synchroniss par rapport une mme source horaire.
Accs administratif
Services Audit et journalisation
Dtection d'intrusion Pare-feu Correctifs et mises jour Filtres
Journalisation et audit
Rseaux de primtre Commutateur Correctifs et mises jour VLAN Valeurs par dfaut non scurises Services
Les tous derniers correctifs de scurit sont tests et installs, ou la menace de vulnrabilits connues est attnue. Assurez-vous que les VLAN ne font pas l'objet d'une utilisation ou d'une confiance excessives. Les services inutiliss sont dsactivs. Les services inutiliss sont dsactivs.
143
Annexes

1
Cryptage
Le trafic commut est crypt.
Autres Synchronisation des journaux Accs administratif au rseau Listes de contrle d'accs (ACL) au rseau
Toutes les horloges de priphriques ayant des capacits de journalisation sont synchronises. Les protocoles TACACS ou RADIUS sont utiliss pour authentifier les utilisateurs administratifs. Le rseau est structur de manire ce que les ACL puissent tre places sur les htes et sur les rseaux.
144
Annexes

1
Annexe 4
Pourcentage dutilisation des serveurs web
145
Annexes

Memoire de Fin de Cycle Ingenieur - Ano Steve - 2008

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Memoire de Fin de Cycle Ingenieur - Ano Steve - 2008

Hochgeladen von

Copyright:

Verfügbare Formate

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Sincrement Steve Koffi Ano

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Table des matires

Table des matires

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

PRESENTATION DE LA STRUCTURE DACCUEIL

Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

I PRSENTATION DE LA STRUCTURE DACCUEIL

I.1.2 Les services rattachs

Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

I.1.3 Les directions

Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

I.2 Prsentation de la Direction Gnrale de la Population et du Renforcement de Capacits (DGPRC)

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

la Direction du Suivi-Evaluation (DSE).

I.3 Prsentation de la Direction du Suivi-Evaluation (DSE)

Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

I.4 Prsentation du Service Informatique

I.4.2 Linventaire des ressources informatiques

les ressources matrielles

Imprimante Imprimante Onduleur-stabilisateur 550 VA / 300 W, Input : 220-240 V ~50-60 HZ, 5A

HP Laserjet 1020 HP Office jet 6615(tout en un) LEADER 550

Tableau 1. Liste du matriel informatique Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

I.4.3 Le rseau informatique

Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Figure 1 : rseau informatique du ministre

Prsentation de la structure daccueil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

II.1.1 Contexte et justification

II.1.3 Rsultats attendus

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

II.2 Mthodes danalyse et de conception

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

II.2.1 La Mthode dtude et de Ralisation Informatique par Sous-ensemble (MERISE)

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Figure 3 : la courbe du soleil

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

II.2.2 Le processus unifi

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Vue dimplmentation Vues des cas dutilisation Vue du dploiement

Vue des processus

Figure 4 : les vues dUML

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Figure 5 : les diffrentes phases

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Ralisation et scurisation dun cadre de gestion des projets : cas du SIGPOD

Figure 6 : les activits