Rapport GesFormJ2ee

Projet de Fin d’Etudes
Pour l’Obtention du Titre
d’Ingénieur d’Etat en Informatique
Option : Génie logiciel
Sujet
Etude et mise en œuvre d’une solution pour la gestion de la

formation en intranet à base des frameworks J2EE
Réalisé par : Sous la direction de :

M. Abdellah SKAL Mme. Bouchra BERRADA
M. Omar BEL LAKHDAR M. Youssef EL MAZOURI
M. Mourad ZEKRAOUI
Année Universitaire 2003/2004

Dédicace
A mes très chers parents,

Aucun terme et aucune langue ne pourra exprimer mon amour et mes
sentiments envers vous.
A mes chères sœurs et frères,

Je ne sais comment vous remercier pour tout ce que vous faites pour moi.
A toute ma famille.
A tous mes chers amis du Maroc et de la France,

A mes chers sœurs, frères et amis de l’ENSIAS et de la cité Souissi II,
Pour tout le soutien que vous m’avez offert, je vous dis MERCI.
A tous ceux qui m’aiment.

A tous les martyrs, je dédie ce travail…
Abdellah
Dédicace
A mes très chers parents,

Aucun mot ne pourra exprimer mes sentiments envers vous.
A mes chères sœurs,

A mon cher frère,
Je ne sais comment vous remercier pour tout ce que vous avez fait pour moi.
A toute ma famille.
A tous mes chers amis de Kelaa,

A mes chers amis de l’école,
A mes très chers frères et amis de la cité universitaire Souissi II,
Pour tout le soutien que vous m’avez offert, je vous dis MERCI.
A tous ceux qui m’aiment.

A tous les musulmans à travers le monde, je dédie ce travail…
Omar
Remerciements
Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès

de toutes les personnes, dont l’intervention au cours de ce projet, a
favorisé son aboutissement.
Ainsi, nous exprimons notre profonde gratitude et tenons à remercier tout

le personnel de l’Administration des Douanes et Impôts Indirectes et plus
précisément l’équipe RIAD, pour leur soutien et pour leur générosité
considérable quant à l’offre de l’information.
Nous tenons à exprimer nos gratitudes à M. Youssef EL MAZOURI, notre

encadrant à l’Administration, qui nous a proposé un sujet très intéressant.
Nos remerciements les plus sincères vont à Mme. Bouchra BERRADA,

notre encadrant à l’ENSIAS, pour les conseils qu’elle nous a prodigué, son
judicieux encadrement ainsi que son assistance pour la rédaction du
rapport.
Nos remerciements s’adressent également à M. Abdelhamid EL

MAAZOUZI, M. Mourad ZEKRAOUI, M. Ali BEZGOURI, M.
Mohamed DADSI, Mounir SEFIANI, Hicham ELIMAM, Chakir
ETTAYEBI, Mlle Fatiha ID MHAMED et Mme Asmaa RETBI, pour
avoir été toujours à l’écoute, et pour leurs conseils et éclaircissements.
Que messieurs les membres de jury trouvent ici l’expression de nos

reconnaissances pour avoir accepté de juger notre travail.
Que tous ceux et celles qui ont contribué de près ou de loin à
l’accomplissement de ce travail trouvent l’expression de nos
remerciements les plus chaleureux.
Résumé
Le présent document constitue le fruit de notre travail accompli dans le
cadre du Projet de Fin d’Etudes au sein de l’Administration des Douanes
et Impôts Indirects (ADII). L’objectif de ce projet est la mise en place
d’une solution pour la gestion de la formation continue en intranet sur la
plate forme Java2 Entreprise Edition (J2EE). Cette solution sera intégrée
dans le projet stratégique de l’ADII, RIAD (Ressources Intégrées de
l’Administration des Douanes)
Notre mission a consisté en l’étude du processus de gestion de la

formation au sein de l’ADII, ainsi que la réalisation de l’ensemble des
phases du développement de ce projet, depuis l’établissement des cahiers
des charges jusqu’à l’intégration dans RIAD.
Quant à l’aspect technique, l’utilisation du framework Struts a facilité la

gestion des Interactions Homme Machines (IHM), et permis la migration
du Design Pattern MVC vers MVC2. L’adoption de ce dernier apporte un
remède aux faiblesses de sécurité dans les applications basées sur MVC.
Le mapping ainsi que la gestion de la persistence ont été réalisés en
utilisant le framework TopLink 9i d’Oracle.
Ce rapport comporte trois parties. La première partie définit le contexte

général du projet. Elle est composée de deux chapitres : la présentation de
l’organisme d’accueil et les objectifs de notre projet. La deuxième partie,
présente l’analyse des besoins et la conception des différentes
composantes du système à développer. La troisième partie décrit les
différentes étapes de la mise en œuvre du projet selon l’approche en « Y ».
A la fin du rapport, nous présentons en complément les différentes
annexes ayant trait du Plan d’Assurance Qualité (PAQ), de la grille des
compétences, du processus Y, des types des Design Patterns et du
frameworks TopLink.
Tables des matières
Liste des abréviations ---------------------------------------------------------------- ii
Liste des figures ----------------------------------------------------------------------- ii
Listes des tableaux ------------------------------------------------------------------- iii
Introduction---------------------------------------------------------------------------- 4
PARTIE I : CONTEXTE GENERAL DU PROJET

Chapitre1 : Présentation de l’organisme d’accueil ---------------------------- 7
Introduction ------------------------------------------------------------------------------------ 7
1. Activités principlaes de l’ADII ----------------------------------------------------------- 7
2. Organisation de l’ADII -------------------------------------------------------------------- 8
2.1. Organigrame de l’ADII -------------------------------------------------------------------- 8
2.2. Service de la Programmation et de l’Evaluation ------------------------------------- 8
2.3. Infrastructure technique du projet RIAD ---------------------------------------------- 9
Conclusion -------------------------------------------------------------------------------------- 9
Chapitre2 : Présentation du projet ---------------------------------------------- 10

Introduction ----------------------------------------------------------------------------------- 10
1. Politique de la formation continue ------------------------------------------------------ 10
2.1. La régionalisation de la formation continue ----------------------------------------- 11
2.2. Processus de gestion de la formation -------------------------------------------------- 11
2.2.1. Identification des besoins de formation ---------------------------------------------- 11
2.2.2. Elaboration des plans ------------------------------------------------------------------- 12
2.2.3. Mise en œuvre des actions de formation --------------------------------------------- 12
2.2.4. Evaluation des actions de formation-------------------------------------------------- 13
3. Contexte et but du projet ----------------------------------------------------------------- 13
4. Conduite du projet------------------------------------------------------------------------- 14
4.1. Processus de développement ------------------------------------------------------------ 14
4.2. Planification du projet -------------------------------------------------------------------- 14
Conclusion ------------------------------------------------------------------------------------- 15
PARTIE II : ANALYSE ET CONCEPTION DU PROJET

Chapitre3 : Analyse et spécification -------------------------------------------- 17
Introduction ----------------------------------------------------------------------------------- 17
1. Fonctionnalités principales -------------------------------------------------------------- 17
2. Analyse du contexte ----------------------------------------------------------------------- 19
2.1. Les rôles ------------------------------------------------------------------------------------- 19
2.2. Identification des acteurs ----------------------------------------------------------------- 19
2.3. Hiérarchisation des rôles ----------------------------------------------------------------- 20
2.4. Interactions acteurs - système et les messages échangés -------------------------- 21
2.5. Diagrammes de contexte ----------------------------------------------------------------- 22
Conclusion ------------------------------------------------------------------------------------- 24
Chapitre4 : Conception de la solution ------------------------------------------ 25
Introduction ----------------------------------------------------------------------------------- 25
1. Décomposition du système --------------------------------------------------------------- 25
2. Choix du formalisme UML --------------------------------------------------------------- 26
3. Packages du système ---------------------------------------------------------------------- 27
3.1. Package grille ------------------------------------------------------------------------------- 27
3.2. Package plan -------------------------------------------------------------------------------- 31
3.3. Package action ------------------------------------------------------------------------------ 35
3.4. Package évaluation ------------------------------------------------------------------------ 40
4. Architecture technique du système ------------------------------------------------------ 44
Conclusion ------------------------------------------------------------------------------------- 45
PARTIE III : MISE EN ŒUVRE DU PROJET

Chapitre5 : Technologies et outils utilisés ------------------------------------ 47
Introduction ----------------------------------------------------------------------------------- 47
1. L’architecture J2EE ----------------------------------------------------------------------- 47
2. Les technologies J2EE -------------------------------------------------------------------- 48
3. Design Patterns MVC et MVC2 --------------------------------------------------------- 49
4. Framework « Struts » --------------------------------------------------------------------- 50
4.1. Choix du framework Struts -------------------------------------------------------------- 50
4.2. Architecture et fonctionnement du Framework Struts ----------------------------- 51
5. Framework « TopLink » ------------------------------------------------------------------ 52
5.1. La problématique de la persistance objet --------------------------------------------- 52
5.2. La solution « Oracle9iAS TopLink »-------------------------------------------------- 53
6. Oracle 9i Application Server ------------------------------------------------------------ 54
7. Environnement de développement JDeveloper 10g ----------------------------------- 55
Conclusion ------------------------------------------------------------------------------------- 55
Chapitre6 : Mise en œuvre de la solution et intégration dans RIAD ----- 56

Introduction ----------------------------------------------------------------------------------- 56
1. Architecture Applicative ------------------------------------------------------------------ 56
2. Réalisation des couches applicatives --------------------------------------------------- 57
2.1. La couche Données ------------------------------------------------------------------------ 57
2.2. La couche Métier -------------------------------------------------------------------------- 57
2.3. La couche Mapping et persistance ----------------------------------------------------- 58
2.4. La couche Présentation ------------------------------------------------------------------- 59
2.5. La couche Services ------------------------------------------------------------------------ 60
3. Intégration avec le projet RIAD --------------------------------------------------------- 60
Conclusion ------------------------------------------------------------------------------------- 61
Conclusion et Perspectives -------------------------------------------------------- 62
Bibliographie ------------------------------------------------------------------------ 63
ANNEXES---------------------------------------------------------------------------- 65
Annexe 1 : Plan d’Assurance Qualité ------------------------------------------- 66
Annexe 2 : Grille de Compétences----------------------------------------------- 70
Annexe 3 : Processus Y ------------------------------------------------------------ 71
Annexe 4 : Types de Design Patterns ------------------------------------------- 72
Annexe 5 : TopLink ---------------------------------------------------------------- 74
Listes des abréviations
Liste des abréviations

Abréviation Désignation
ADII Administration des Douanes et Impôts Indirects
EJB Entreprise JavaBean
GIPE Gestion Intégrée du Personnel de l’Etat
IDE Integrated Development Environment
J2EE Java 2 Enterprise Edition
JDBC Java Data Base Connectivity
JDO Java Data Object
JNDI Java Naming and Directory Interface
JSP Java Server Pages
JTS Java Transaction Service
MVC Model View Controller
ODMG Object Data Management Standards
OJB Object Java Bridge
PAQ Plan d’Assurance Qualité
RMI Remote Method Invocation
RO Relational Object
SGBD Systèmes de Gestion de Bases de Données
UML Unified Modelling Language
XML eXtensible Markup Language
Projet de Fin d’Etudes / ENSIAS 2004 i

Listes des figures
Liste des figures

Figure 1 : Organigramme de l’ADII------------------------------------------------------------------- 8
Figure 2 : Processus « 2TUP »------------------------------------------------------------------------ 14
Figure 3 : Hiérarchisation des acteurs humains ---------------------------------------------------- 20
Figure 4 : Hiérarchisation du rôle du responsable immédiat ------------------------------------- 20
Figure 5 : Hiérarchisation des systèmes ------------------------------------------------------------- 21
Figure 6 : Digramme de contexte : Vue Humaine -------------------------------------------------- 23
Figure 7 : Digramme de contexte : Vue Système---------------------------------------------------- 23
Figure 8 : Décomposition du système en sous modules -------------------------------------------- 26
Figure 9 : Diagramme de cas d’utilisation du package « Grille » ------------------------------- 28
Figure 10 : Diagramme d’objets du cas d’utilisation «Gestion des grilles » ------------------- 29
Figure 11 : Diagramme de classes du package « Grille » ----------------------------------------- 30
Figure 12 : Diagramme de séquences du scénario « Création d’une grille »------------------- 31
Figure 13 : Diagramme de cas d’utilisation du package « Plan » ------------------------------- 32
Figure 14 : Diagramme d’objets du cas d’utilisation « Gestion des plans régionaux » ------- 33
Figure 15 : Diagramme de classes candidates du package « Plan »----------------------------- 34
Figure 16 : Diagramme de séquences de « création de plan régional » ------------------------- 35
Figure 17 : Diagramme de cas d’utilisation du package Action ---------------------------------- 36
Figure 18 : Diagramme d’objets de « Planification d’une action de formation» -------------- 38
Figure 19 : Diagramme de classes candidates du package « action » --------------------------- 39
Figure 20 : Diagramme de séquences de planification d’une session de formation ----------- 40
Figure 21 : Diagramme de cas d’utilisation du package Evaluation ---------------------------- 41
Figure 22 : Diagramme d’objets de « Elaboration du rapport d’évaluation» ------------------ 42
Figure 23 : Diagramme de classes candidates du package «Evaluation»----------------------- 43
Figure 24 : Diagramme de séquences de l’élaboration du rapport d’évaluation -------------- 44
Figure 25 : Architecture technique du système de gestion de la formation --------------------- 44
Figure 26 : Technologies J2EE ----------------------------------------------------------------------- 48
Figure 27 : Modèle MVC2 ----------------------------------------------------------------------------- 49
Figure 28 : Modèle MVC2 ----------------------------------------------------------------------------- 50
Figure 29 : Principe de fonctionnement du framework Struts ------------------------------------ 52
Figure 30 : Composantes principales du framework ----------------------------------------------- 54
Figure 31 : Architecture applicative du système de gestion de formation ----------------------- 57
Figure 32 : Arborescence des packages métier ----------------------------------------------------- 58
Figure 33 : Outil de mapping des classes vers les tables de la BD ------------------------------- 59
Figure 34 : Page d’accueil du système de gestion de formation ---------------------------------- 60
Figure 35 : Planning détaillé du déroulement du projet ------------------------------------------- 68
Figure 36 : Evaluation du modèle de persistance EJB --------------------------------------------- 78
Figure 37 : Evaluation du modèle de persistance JDO -------------------------------------------- 79
Figure 38 : Evaluation du modèle de persistance Oracle9iAS TopLink ------------------------- 80
Projet de Fin d’Etudes / ENSIAS 2004 ii

Listes des tableaux
Listes des tableaux

Tableau 1 : Planning global de réalisation du projet ---------------------------------------------- 15
Tableau 2 : Liste des messages échangés entre le système et les acteurs ------------------------ 22
Tableau 3 : Comparaison de quelques frameworks en terme de puissance et de complexité - 51
Tableau 4 : Les participants au projet côté ADII --------------------------------------------------- 66
Tableau 5 : Les participants au projet côté ENSIAS ----------------------------------------------- 66
Tableau 6 : Membres du comité de pilotage --------------------------------------------------------- 67
Tableau 7 : Membres du comité de projet ----------------------------------------------------------- 67
Tableau 8 : Les livrables par phase ------------------------------------------------------------------ 69
Projet de Fin d’Etudes / ENSIAS 2004 iii

Introduction
Introduction
Après quelques décennies, la formation continue, plutôt sporadique et inégalement répartie,
est reconnue comme un prolongement naturel et indispensable de l'école. Les mutations et les
évolutions récentes de l’économie mondiale accentuent cette tendance et rendent nécessaire
une réflexion profonde et renouvelée sur la formation continue.
Les organismes conscients de l’importance de la formation continue comme étant un pilier de

toute stratégie de gestion des ressources humaines d’une part, et un enjeu clé pour
accompagner les changements émanant des évolutions d’autre part, ont développés leurs
politiques de formations qui leurs permettent de diagnostiquer et par conséquent enrichir leurs
référentiels de compétences. Cet enrichissement permet d’avoir un rendement important et de
palier aux dysfonctionnements à court, moyen et long terme.
Dans ce sens et conformément à sa stratégie de veille technologique et économique, l’ADII a

jugé nécessaire l’élaboration de sa politique lui permettant de diagnostiquer les compétences
disponibles afin de les faire évoluer.
Ainsi, notre projet a pour but de doter les responsables de la formation continue au sein de
l’administration d’un système transactionnel (Web) leurs permettant la gestion des différentes
composantes de la formation à savoir :
• Grille de compétences,
• Plans de formations,
• Rapports d’évaluation.
Le présent rapport comporte trois parties. La première partie, composée de deux chapitres,
définit le contexte général du projet. Elle débute par la présentation de l’organisme d’accueil.
La présentation de notre projet et la démarche suivie feront l’objet du deuxième chapitre de
cette partie.
Dans la deuxième partie, nous exposons les concepts de modélisation de notre projet. Ainsi, le
premier chapitre est consacré à l’analyse et la spécification des besoins afin d’énumérer les
fonctionnalités principales du système à développer et de délimiter le périmètre fonctionnel de
ce futur système. Le deuxième chapitre fera l’objet de la phase de conception du projet en
utilisant le standard UML.
Quant à la troisième partie, elle présente les aspects techniques du projet. Elle décrit les
différentes technologies et outils utilisés ainsi que les étapes de la mise en œuvre de ce projet
selon la démarche choisie. Dans le premier chapitre, nous allons décrire l’architecture et les
technologies J2EE, les outils ainsi que les frameworks utilisés pour la concrétisation de notre
projet : Struts, TopLink, JDevelopper 10g et le serveur d’applications Oracle 9i AS. Le
Projet de Fin d’Etudes / ENSIAS 2004 4

Introduction
deuxième chapitre abordera l’étape de la mise en œuvre du projet tout en présentant la mise
en place de chaque couche de l’architecture technique du système.
A la fin du rapport, nous présentons un complément dans les différents annexes traitant le
plan d’assurance qualité, la grille de compétences, le processus de développement, les types
des Design Patterns et le framework TopLink.

Partie 1 : Contexte général du projet
PARTIE 1 : CONTEXTE GENERAL DU PROJET
Cette partie comprend deux chapitres :
Le premier chapitre introduit l’organisme d’accueil, ses

activités et son organigramme.
Le deuxième chapitre présente le sujet du projet et traite les

différents aspects de la politique de gestion de la formation
dans l’ADII. Il précise également l’objectif et la conduite du
projet ainsi que le planning général de la réalisation.

Chapitre 1 : Présentation de l’organisme d’accueil
Chapitre1 : Présentation de l’organisme d’accueil
Dans ce chapitre nous présentons l’organisme

d’accueil : Administration des Douanes et Impôts
indirects. Nous exposons d’abord, les activités de
l’ADII puis son organisation ainsi que son
infrastructure technique.
Introduction
Comme nous l’avons indiqué auparavant, notre projet s’est déroulé au sein de l’ADII, dont le
fonctionnement est axé autour de plusieurs activités, et se base sur un système d’information
mature.
1. Activités principales de l’ADII

L’Administration des Douanes et Impôts Indirects (ADII), est un organe du ministère de
l’économie, des finances et de la privatisation. Elle participe à la définition de la politique
douanière nationale et en assume la mise en oeuvre à travers les missions suivantes :
La promotion de l’investissement
L’ADII contribue au développement économique du Maroc. Son intervention dans la
promotion de l’investissement revêt plusieurs aspects, en particulier :
• L’application des dispositions relatives aux avantages fiscaux accordés aux matériels,
outillages et autres équipements importés ;
• La promotion des régimes économiques en douanes, notamment l’admission
temporaire et l’entrepôt industriel franc ;
• La simplification des procédures de dédouanement ;
• La mise en place d’une organisation efficiente des services douaniers basés sur un
recours de plus en plus accru au traitement automatique rendu possible grâce à la
généralisation de l’outil informatique.
La protection du consommateur
Dans le cadre de la mise en application de certaines législations particulières, l’ADII veille,
aussi bien à l’importation qu’à l’exportation, au respect d’un certain nombre de règlements en
matière de contrôle de la qualité, des normes techniques, des mesures sanitaires, vétérinaires
et photo sanitaires, de la protection de la propriété intellectuelle et de contrôle de la répression
des fraudes. Cette protection s’exerce également à travers le contrôle des ouvrages en métaux
précieux.
La protection de l’économie nationale

Avec le démantèlement tarifaire, la protection de l’économie nationale intervient davantage à
travers la maîtrise des règles d’origine et la lutte contre le dumping. Le développement des
accords tarifaires bilatéraux et multilatéraux fait de l’origine de la marchandise une des

conditions essentielles pour l’octroi des avantages prévus par lesdits accords. De même une
attention particulière est accordée à la valeur des marchandises importées pour prévenir toute
action de dumping pouvant porter préjudice à la production nationale.
L’équité fiscale
L’ADII veille à ce que les importations d’une même marchandise (même origine, même
valeur, etc..) acquittent les mêmes droits et taxes quelque soit l’importateur ou le bureau
d’importation. L’équité fiscale implique également une lutte contre la contrebande et la fraude
sous toutes ses formes.
2. Organisation de l’ADII
L’ADII est organisée en services centraux et services extérieurs. Le nombre du personnel au
sein des services Centraux et Extérieurs s’élève à 4795 répartis sur des échelles et des
catégories diverses.
2.1. Organigramme de l’ADII
ADII
Directions Division de Directions

centrales l’audit régionales
Divisions Circonscriptions
centrales
Services Brigade Recette Ordonnancements

centraux
Figure 1 : Organigramme de l’ADII
Les services centraux sont placés sous l'autorité du directeur général de l'administration,
assisté des directeurs centraux et des chefs de division. L'organisation des services centraux
repose sur quatre directions, groupant dix divisions, et une division de l’audit rattachée
directement au directeur général.
2.2 Service de la Programmation et de l’Evaluation
Notre projet s’est déroulé dans le service de la programmation et de l’évaluation. Ce service
appartient à la division de la programmation et de la communication composée de trois
services :
• Service de la Programmation et de l'Evaluation ;
• Service de la Gestion de l'Information ;
• Service de la Communication.

La division de la programmation et de la communication est sous l’autorité de la direction des

ressources et de la programmation.
Le service de la programmation et de l’évaluation est chargé de la réalisation du projet
stratégique RIAD.
2.3. Infrastructure technique du projet RIAD

Vu l’importance accordée par l’ADII au projet RIAD, une infrastructure technique très riche a
été mise à disposition de l’équipe RIAD composée des membres du service de la
programmation et de l’évaluation. Cette infrastructure s’articule autour des technologies J2EE
et se base sur un spectre d’outils très puissant.
Les principales composantes de l’infrastructure de RIAD sont :
• Serveur de bases de données Oracle
• Serveur d’applications 9i Application Server (9iAS)
• Moteur Workflow
• Serveurs Web
• Progiciel GIPE
Conclusion
Dans le présent chapitre, nous avons présenté l’organisme d’accueil en terme d’activités et
d’organisation. Le Service de la Programmation et de l’Evaluation, dans lequel s’est déroulé
notre projet, a été situé dans l’organigramme de l’ADII avant de présenter le projet RIAD.
Le chapitre suivant présente le sujet du projet, son but et la démarche adoptée pour sa
réalisation.

Chapitre 2 : Présentation du projet
Chapitre2 : Présentation du projet
Dans ce chapitre, nous décrivons la politique de

l’ADII en matière de gestion de la formation continue
ainsi que l’objectif de notre projet. Nous terminons
par présenter la démarche adoptée et le planning
général suivi pour la réalisation de notre projet.
Introduction
La politique de formation adoptée par l'ADII entre dans le cadre du plan d’action stratégique
du ministère de l’économie et des finances, qui a inscrit la formation parmi ses priorités. Dans
cette même optique, l'administration a entrepris un programme de réformes et de
modernisation, où la formation professionnelle servirait cette même mission.
1. Politique de la formation continue

Cette politique vise à définir :
• d'une part les objectifs opérationnels généraux que les actions de formation doivent
permettre de réaliser, et la démarche permettant d'assurer une meilleure adéquation
formation – emploi ;
• et d'autre part, le cadre général de la régionalisation de la formation, ainsi qu'une
démarche d'identification des besoins et d'élaboration des plans de formation internes,
régionaux et nationaux.
La transmission ainsi que l’amélioration des savoir-faire sont réalisées au moyen de deux
types de formation : la formation de base et la formation continue.
La formation de base vise à doter le stagiaire de connaissances générales, théoriques et

pratiques sur toutes les composantes de l’environnement douanier, lui permettant ainsi,
d’intégrer facilement le milieu professionnel avec un minimum d’opérationnalité, au terme de
sa formation.
Quant à la formation continue, elle permet de faire évoluer d’une part, les compétences des
agents pour la bonne maîtrise des opérations, qui contribuent à la production d’une plus-value
au sein de l’ADII, et d’autre part leurs savoir-faire.
La politique de formation continue de l’ADII vise à atteindre les objectifs suivants :

• développer la polyvalence des agents ;
• atténuer la vulnérabilité des services et accompagner la politique de redéploiement du
personnel poursuivie par l’administration d’une part ;
• et d’assurer l'unification du langage avec les partenaires de l'administration.

Afin d’atteindre ces objectifs, l’ADII a engagé une politique de déconcentration et de

régionalisation de la formation continue.
2.1. La régionalisation de la formation continue

La régionalisation de la formation continue est dictée par le souci de généraliser le bénéfice de
la formation à l'ensemble des douaniers à moindre coût et d’assurer une meilleure adéquation
entre les emplois qu’ils occupent et les formations qu’ils possèdent.
Une telle politique ne peut être efficace que si elle permet une bonne identification des
besoins. Celle-ci doit se baser sur une analyse fine des écarts entre les compétences
disponibles et les compétences exigées, aussi bien à court terme, pour corriger les
dysfonctionnements actuels, qu'à long terme, pour accompagner les évolutions futures.
Cette démarche permet l’élaboration et la mise en œuvre d’actions de formation répondant
aux besoins stratégiques de l'administration, de ses agents et de ses partenaires.
Ainsi, l’ADII a adopté une approche scientifique qui consiste à approfondir la connaissance
de l'existant, écouter les intéressés, et les associer étroitement à la préparation des plans de
formation les concernant, et enfin, à mettre en adéquation les orientations générales de
l'administration.
L’approche adoptée par l’ADII en matière de formation continue est inspirée de la méthode
de formation intégrée mise au point par l’Institut de Socio économie des Entreprises et des
Organisations (ISEOR) en France.
2.2. Processus de gestion de la formation

L’approche précitée se décompose en quatre phases principales :
2.2.1. Identification des besoins de formation

Cette phase repose sur deux étapes essentielles :
• Diagnostic des compétences
Le diagnostic des compétences vise le repérage des "points de fragilité" tant au niveau de la
polyvalence du personnel qui compose l'entité qu’au niveau de la vulnérabilité des postes de
l'entité elle même. Les dysfonctionnements sont localisés au moyen de trois sources
d’information : entretiens qualitatifs, analyse de quelque documents (notes d’orientations
générales, compte rendus de réunions, rapports d’audit et d’inspection…) et Observation
directe.
• Etablissement des grilles de compétences

Une grille de compétences se présente sous forme d’un tableau synoptique à double entrée
(Annexe 2) constituant un véritable tableau de bord de pilotage des compétences, fortement
visualisé permettant, grâce au degré de noircissement des symboles utilisés pour la cotation,
d’apprécier le niveau des compétences disponibles au sein de l’unité.
Elle est établie par le supérieur hiérarchique qui recense les compétences existantes, aussi
bien sur les opérations liées aux activités de l’unité ou de l’équipe, que sur les savoir-faire
particuliers des personnes qui y constituent.
Cette phase d’identification des besoins se termine par la cotation des agents qui se fait sur la
base de la qualité de la réalisation effective d’une opération par un individu et non sur la base
du jugement de ses capacités potentielles à son éventuelle exécution.

Sur la base de cette cotation, les deux indicateurs : Indicateur de Polyvalence, qui mesure la
polyvalence des agents, et Indicateur de Vulnérabilité, qui mesure le niveau de vulnérabilité
d’un service, sont calculés pour pouvoir identifier les besoins en formation (Annexe 2).
2.2.2. Elaboration des plans

Les besoins de formation identifiés au moyen du diagnostic sont comblés par le biais de trois
types de plans de formation :
• Plan interne de formation

Le plan interne de formation, élaboré par le responsable immédiat qui est le chef de l’unité,
est destiné à combler les besoins individuels spécifiques des agents. Il est mis en œuvre sur le
lieu de travail, au niveau des services locaux et centraux, sous la responsabilité de la
hiérarchie directe. Ce plan est intégré dans la même grille de compétences ayant servi à
identifier les besoins individuels en formation.
• Plan régional de formation

Chaque Direction Régionale a un plan de formation qui vise à satisfaire les besoins collectifs
en formation, décelés dans différents services locaux relevant de la même Direction
Régionale. Les plans régionaux sont élaborés par les structures régionales chargées de la
gestion de la formation.
Le responsable immédiat, après avoir réalisé le diagnostic des compétences, au niveau de sa

structure, doit distinguer les besoins individuels de ceux collectifs. Ces derniers doivent faire
l’objet d’une remontée aux cellules régionales chargées de la gestion de la formation, aux fins
de leur intégration dans les plans régionaux.
• Plan national de formation

Le plan national de formation est élaboré par le service de la formation. Il intègre les besoins
en formation :
collectifs des agents de l’Administration Centrale;
des formateurs régionaux chargés d’animer les formations inscrites dans les plans
régionaux;
concernant les thèmes jugés stratégiques par l’Administration.
Une note d’orientations générales doit permettre au Service de dégager des axes stratégiques
de formation qui seront également intégrés dans le plan national de formation.
2.2.3. Mise en œuvre des actions de formation

Les actions de formation retenues dans les différents plans sont mises en oeuvre selon le type
du plan.
La mise en œuvre des formations internes suppose l’implication active de la hiérarchie directe
tout en donnant la possibilité à l’agent concerné de pratiquer réellement l’opération sur
laquelle il a besoin d’être formé et désigner le formateur adéquat, celui-ci doit être choisi
parmi l’encadrement le plus proche de l’agent à former.
Les actions de formation retenues dans les plans régionaux sont animées par les formateurs
régionaux et sont mises en œuvre dans les espaces pédagogiques relevant des différentes
directions régionales sous la responsabilité directe du directeur régional.
Enfin, les actions de formation retenues dans le plan national en faveur des formateurs
régionaux qui vont assurer les mêmes formations à leurs collègues dans le cadre des plans

régionaux, sont mises en œuvre ou bien par des formateurs internes à l’administration, ou bien
par des formateurs externes provenant des organismes de formations spécialisés.
2.2.4. Evaluation des actions de formation

Trois évaluations, quantitative, qualitative et financière sont nécessaires pour apprécier
l’efficacité et l’efficience des actions de formation engagées par l’administration.
• Evaluation quantitative
Elle a pour objectif de mettre en évidence l’effort quantifié de formation. Elle porte sur :
Le nombre d’agents formés (par catégorie, sexe, structure, etc.) ;
Le nombre de jours de formation par agent et par an ;
Le nombre d’actions de formation réalisées au niveau central, régional, et local.
• Evaluation qualitative
L’évaluation qualitative a pour objectif de vérifier, d’une part, le degré de mise en œuvre
effective des connaissances acquises dans les situations réelles de travail et, d’autre part, le
degré de satisfaction des agents formés, aussi bien par rapport à la qualité de la formation, que
par rapport aux conditions de son déroulement.
• Evaluation financière
Si l’évaluation qualitative permet de s’assurer de l’efficacité de la formation, l’évaluation
financière permet de rendre compte de son efficience. Ainsi, au moyen de cette évaluation,
doivent être appréciés les coûts financiers générés par la formation, tout en les rapportant à sa
qualité.
3. Contexte et but du projet

Consciente de l’importance de l’informatique, l’ADII accorde aujourd’hui une attention
particulière à son système d’information et adopte une démarche de « gestion par projet »
émanant d’un schéma directeur. Le dernier projet soumis est celui des Ressources Intégrées
de l’Administration des Douanes, baptisé RIAD.
Pour ce projet initié en l’an 2000, il avait été envisagé plusieurs scénarii : l’achat d’un
progiciel de gestion, le recours à un prestataire et le développement spécifique ou en interne.
En raison des difficultés d’ordre technique et financier que présentent les deux premiers
scénarii, l’administration a retenu le développement spécifique comme choix stratégique.
Le projet RIAD couvre quatre domaines :
• Ressources humaines ;
• Ressources matérielles ;
• Ressources financières ;
• Le self-service.
Relevant du domaine des RH, le projet qui nous a été assigné comprend trois phases :
• Etude et modélisation du processus de gestion de la formation, qui est l’un des piliers
de la stratégie de la gestion des ressources humaines dans l’administration ;
• La mise en œuvre d’une solution répondant aux différentes exigences fonctionnelles et
techniques ;
• L’intégration de la solution dans le projet RIAD.
Ainsi, notre travail consiste à gérer les composantes des quatre phases du processus de la
formation précitées : l’élaboration des grilles de compétences, l’élaboration des plans de

formation, la planification et la mise en œuvre des actions de formation, et enfin l’élaboration

des fiches et des rapports d’évaluation.
4. Conduite du projet
4.1. Processus de développement
Traditionnellement, la modélisation des systèmes se base sur les trois hypothèses suivantes :
• Les fonctionnalités d'un système sont stables, elles n'évoluent pas avec les temps;
• Les besoins relatifs à un système sont donnés au départ;
• La validation des besoins peut se faire en référence aux fonctionnalités du système
[CORCA01].
Aujourd'hui, il est clair que ces hypothèses ne sont plus valides. Ainsi, une séparation entre le
fonctionnel et le technique, lors du développement, est dictée par le besoin d'un produit
extensible.
Pour livrer un produit qui respecte les besoins des utilisateurs tout en s'adaptant aux futurs
changements, nous avons optés pour le processus 2TUP (Two «2» Tracks Unified Process).
C'est un processus unifié qui apporte une réponse aux contraintes de changement continuel
imposées aux systèmes d'information de l'entreprise. "2 Tracks" signifie littéralement que le
processus suit deux chemins. Il s'agit des chemins "fonctionnel" et "d'architecture technique",
qui correspondent aux deux axes de changement [ROVA00]:
Figure 2 : Processus « 2TUP »
2TUP est un processus qui répond également aux caractéristiques ci-après:

• Un processus incrémental piloté par les risques
• Un processus pilotés par les exigences des utilisateurs
• Un processus de modélisation avec UML (Annexe 3)
4.2. Planification du projet

La planification du projet est parmi les phases d'avant projet. Elle consiste à prévoir le
déroulement du projet tout au long des phases constituant le cycle de développement. Grâce
aux réunions tenues avec nos encadrants au sein de l’administration, nous avons été éclairés

sur les différentes étapes du projet ainsi que leur séquencement. Cela consistait en trois
grandes étapes: la première est une phase d'analyse et de spécification dont les objectifs est de
bien cerner le sujet d'une part et de délimiter le périmètre du projet d'autre part. La seconde est
consacrée à la conception de la solution et quant à la troisième étape, elle traite la mise en
oeuvre de la solution.
Le tableau suivant présente sommairement le planning des étapes du déroulent de notre projet,
le planning détaillé figure dans le Plan d'Assurance Qualité (Annexe 1)
Phase Estimation Début Fin Livrable

(%)
Lancement du Projet 09/02/04 12/02/04 PAQ
- Cahier des charges
Analyse et spécification 20% 13/02/04 04/03/04 utilisateur (CDCU)
- Cahier des charges
fonctionnel (CDCF)
- Dossier de conception
Conception de la solution 40% 05/03/04 14/04/04 générale
- Dossier de conception
détaillée
Mise en œuvre de la solution 35% 15/04/04 20/05/04 - Système développé et
testé.
Validation fonctionnelle 5% 21/05/04 25/04/04 - Dossier de validation
fonctionnelle
Tableau 1 : Planning global de réalisation du projet
Ce planning était un fil conducteur tout au long du projet. Il nous a permis d’ajuster les
dérives et de maîtriser la gestion du temps alloué pour la réalisation du projet. Les livrables
des différentes phases de ce planning servent de documentation pour le projet et nous ont
servis à la rédaction de ce rapport.
Conclusion
Dans ce chapitre, nous avons présenté la politique de formation adoptée par l’ADII. Cette
politique n’est autre que le processus de gestion de la formation au sein de l’administration.
La présentation du but du projet est la seconde partie de ce chapitre suivie de la description du
processus de développement 2TUP que nous avons adopté pour le développement du système
de gestion de la formation. A base de ce processus que nous avons établi un planning de
travail afin de bien maîtriser les ressources allouées au projet.
Le chapitre suivant est consacré à l’analyse et la spécification du sujet.

Partie 2 : Analyse et conception du projet
PARTIE 2 : ANALYSE ET CONCEPTION DU

PROJET
Cette partie traite les deux phases les plus importantes et les
plus critiques de tout cycle de développement. Ce sont l’analyse
et la conception.
Un premier chapitre présente la phase d’analyse dont le but est

de délimiter le périmètre du projet en identifiant les
fonctionnalités auxquelles le système doit répondre, ainsi que
les entités externes (acteurs humains et systèmes) qui
réagissent avec le système.
Les résultats de la phase d’analyse sont la base de la phase de

conception traitée par un deuxième chapitre. Ce dernier
commence par une décomposition du système en packages
fonctionnels ce qui permet de maîtriser sa conception avec le
formalisme UML.

Chapitre 3 : Analyse et spécification
Chapitre3 : Analyse et spécification
Ce chapitre décrit la phase d’analyse et de

spécification du projet. Dans un premier temps, nous
identifions les fonctionnalités auxquelles le système de
gestion de la formation doit répondre. La seconde
partie traite de l’analyse du contexte du projet
permettant d’identifier les interactions entre le
système et le monde extérieur afin de délimiter le
périmètre fonctionnel.
Introduction
Lors de cette phase nous avons effectué une étude des besoins des utilisateurs du système à
développer. Ces besoins ont été identifiés lors des réunions tenues avec ces utilisateurs. Cette
première phase du cycle de développement avait comme livrables, le cahier des charges
utilisateur et le cahier des charges fonctionnel.
Dans le présent chapitre nous présentons la synthèse de ces deux livrables.
1. Fonctionnalités principales
Cette partie est réservée à l’énumération ainsi qu’à la description des différentes
fonctionnalités que le système de gestion de la formation doit assurer. Une analyse profonde
du cahier des charges utilisateur établie suite aux réunions avec nos encadrants, nous a mené à
dégager les sept fonctionnalités suivantes :
1. Sécurisation des accès au système

Lors de sa connexion, chaque utilisateur du système doit être reconnu par un login et un mot
de passe et la fonction qu’il occupe.
La gestion des mots de passe et des profils des utilisateurs est assurée par le système de
gestion des habilitations.
2. Gestion des opérations et des savoir-faire

L’activité principale d’une unité organisationnelle (UO) s’articule autour d’un certain nombre
d’opérations qui représentent le cœur de son métier. En outre, les agents d’une unité peuvent
avoir des compétences supplémentaires qualifiées de savoir-faire. Le système doit fournir au
responsable de l’unité la possibilité de gérer les opérations et les savoir-faire relatifs à sa
structure et de les classer selon leurs natures.
3. Gestion des grilles de compétences

En vu d’identifier les besoins en formation dans une unité organisationnelle, le responsable de
l’unité organisationnelle procède à un diagnostic des compétences disponibles dans son unité
en remplissant la grille des compétences.

Ainsi, le système doit permettre le remplissage da la grille et calculer automatiquement les

indicateurs de polyvalence pour chaque agent et de vulnérabilité du service par rapport à
chaque opération.
Le responsable de l’unité peut également créer, modifier et supprimer une grille. La validation
d’une grille la rend visible par le formateur régional concerné.
4. Elaboration des plans de formation

Plan interne
Une fois les besoins sont identifiés et hiérarchisés, le responsable d’une UO entame la phase
de l’élaboration du plan interne contenant les formations visant à satisfaire les besoins
individuels au niveau de sa structure et qui seront dispensées en interne.
Le système permettra au responsable de gérer ses plans internes tout en saisissant les
formations ainsi que les dates prévues pour la réalisation de chacune de ces formations. La
validation d’un plan interne le rend accessible par le formateur régional.
Plan régional
Chaque formateur régional consulte les plans internes des UO relevant de son autorité afin de
dégager les besoins en formation à caractère régional. Le système lui permet d’élaborer un
plan régional de formation contenant les formations répondant aux besoins dégagés des plans
internes.
Dans le cas où une circonscription est directement attachée à la direction centrale, le chef de
circonscription joue le même rôle que celui du formateur régional : il établit le plan régional
des UO qui sont sous son autorité.
Plan national
Quant au plan national, le service central de la formation procède à un regroupement des
besoins exprimés dans les plans régionaux en vue de tirer ceux à caractère national, ensuite il
recense les besoins des services de l’administration centrale. Enfin, tenant compte des
orientations générales du comité directeur, le service élabore le plan national en précisant les
formations répondant aux besoins ainsi identifiés.
Ce plan doit être remis au comité pédagogique pour la planification et une éventuelle
modification. Tous ces aspects doivent être gérés par notre système à développer.
5. Programmation des sessions de formation

Une session de formation est mise en place pour satisfaire un besoin mentionné dans un plan
interne, régional ou national. Cette réalisation nécessite la mise en place d’un planning de
réalisation de la session, la détermination du lieu, des participants, des dates et des animateurs
ou formateurs. Notre système doit pouvoir offrir un outil pour programmer les sessions de
formations.
6. Traitement et synthèses des résultats de formations

Le système doit gérer les résultats issus des différentes fiches d’évaluation :
Fiches d’évaluation remplies par un jury, elles permettent d’évaluer les acquis des
participants à la formation,
Fiches d’appréciation remplies par les participants pour apprécier la formation.
L’évaluation est aussi effectuée au niveau financier. En effet, cet axe financier permet
d’optimiser les ressources lors des prochaines réalisations.

L’opération d’évaluation a pour résultat l’élaboration d’un rapport d’évaluation qui permet de
donner une vision synthétique sur les formations réalisées au profit des agents de
l’administration.
7. Intégration au Système d’Information de l’ADII :

Vu l’importance étroite de l’interopérabilité entre les applications du SI d’un même
organisme, le système de gestion de la formation doit être bien conçu pour être intégré
facilement au SI de l’ADII en s’interfaçant avec les applications qui le constituent.
Le système de gestion de la formation est un module du projet RIAD ce qui nécessite son
intégration dans le projet via des interfaces avec les autres modules.
Les systèmes avec lesquels nous devons assurer un interfaçage sont :

Le système de gestion du personnel de l’ADII (GIPE)
Le système de gestion des profils et des compétences de l’ADII
Le système de gestion des habilitations
Le système de gestion organisationnelle de l’administration
Le système de gestion budgétaire.
L’identification de ces fonctionnalités, nous permet maintenant de procéder à une analyse du

contexte du système à développer.
2. Analyse du contexte
L’analyse du contexte a pour objectif l’identification des différentes entités qui interagiront
avec le système. Ces entités seront regroupées par la suite sous forme de rôles dont chacun
englobe un ensemble d’entités. Le regroupement sera effectué en se basant sur les
interactions.
2.1. Les rôles

Un rôle réfère à une mission et à des responsabilités assumées par des entités externes au
système étudié. Ces entités ou acteurs (utilisateur, dispositif matériel ou autre système)
interagissent (communiquent) directement avec le système étudié.
Un acteur peut consulter et/ou modifier directement l’état du système, par émission et/ou
réception de messages éventuellement porteurs de données.
L’étude de la typologie des rôles a conduit à la classification suivante :
Rôles joués par des acteurs humains :

• Agents de l’ADII.
Rôles joués par des systèmes (acteurs non humains)
• Systèmes internes à l’ADII
2.2. Identification des acteurs

Un acteur peut consulter et/ou modifier directement l’état du système, par émission et/ou
réception de messages éventuellement porteurs de données.
Les acteurs que nous avons identifiés à partir de la description des fonctionnalités ci-dessus
sont les suivants :

• Responsable immédiat
• Formateur régional
• Chef de circonscription
• Cadre du service de formation central
• Fonctionnel de formation
• Comité directeur
• Comité pédagogique
• Système de gestion du budget
• Système de gestion des profils et compétences
• Système d’Habilitation
• Système de gestion organisationnel
• Système de gestion du personnel GIPE
2.3. Hiérarchisation des rôles

L’identification de la majorité des rôles pertinents à retenir a permis de concevoir
l’arborescence des rôles, en utilisant la représentation graphique fondée sur le formalisme
UML.
Figure 3 : Hiérarchisation des acteurs humains

Afin de préciser les acteurs qui pourront jouer le rôle du responsable immédiat nous avons
procédé à l’hiérarchisation de ce rôle :
Figure 4 : Hiérarchisation du rôle du responsable immédiat

Les systèmes sont aussi hiérarchisés de la manière suivante :

Figure 5 : Hiérarchisation des systèmes

Ces acteurs systèmes sont tous des modules du projet RIAD auquel doit être intégré le
système à développer et ce à travers les interfaces de communication avec ces systèmes.
2.4. Interactions acteurs - système et les messages échangés

Un message représente ici la spécification de haut niveau d’une interaction (communication)
entre acteurs et système, avec l’intention (métier) de déclencher une activité chez le récepteur.
La réception d’un message est normalement considérée comme un événement. Il faut se
demander :
• Pour chaque acteur, quels sont les messages qui déclenchent un comportement attendu
par l’acteur du système, dans le cadre de son activité;
• Pour le système, quels sont les messages émis à l’attention d’un acteur particulier et
qui portent une information utilisée par ce destinataire;
L’identification des interactions des acteurs avec le système consiste à l’identification des
différents messages échangés par ces acteurs avec le système à développer.
Les messages que nous avons identifiés après l’analyse des rôles des acteurs listés ci-dessus
sont résumés dans le tableau de la page suivante :

Acteurs Message(s) émis par les Message(s) reçus par les

acteurs acteurs
La grille de compétences à La création, la modification
Le responsable immédiat remplir, la liste des opérations et la suppression de grille et
et des savoir-faire et la liste de plan interne
des agents d’une UO
Les grilles de compétences et La création, la modification
Formateur régional les plans internes de formation et la suppression du plan
régional de formation
Chef de circonscription Les grilles de compétences et
les plans internes de formation
Cadre du service de Le plan régional de formation La création, la modification
formation et la suppression du plan
national de formation
Les plans régionaux de Les données de suivi et
Fonctionnel de formation formation validés par les d’évaluation de la session
formateurs régionaux de formation
Système de gestion du Les estimations des coûts des La validation des
budgétaire formations estimations des coûts de
formation
Système de gestion des Résultats de l’évaluation des
profils et compétences formations
Système de gestion des Les login et les mots de passe
Habilitations
Système de gestion La position de chaque UO
organisationnel dans l’organigramme de
l’ADII
Système de gestion du Les données administratives
personnel GIPE des participants
Comité directeur Orientations générales Plan National validé
Comité pédagogique Validations des programmes Programmes et plannings
Tableau 2 : Liste des messages échangés entre le système et les acteurs
2.5. Diagrammes de contexte

Au cours de ce paragraphe nous procédons à une modélisation du contexte général du système
sous formes de deux diagrammes de contexte selon deux vues différentes : « Vue Humaine »
et « Vue Système », et ce afin de ne pas surcharger cette modélisation.

• Vue Humaine
Figure 6 : Digramme de contexte : Vue Humaine
Sur ce diagramme nous avons regroupé les différents acteurs humains et leurs interactions
avec le système. Les acteurs potentiels sont le cadre de formation, le responsable immédiat et
le formateur régional.
• Vue Système
Figure 7 : Digramme de contexte : Vue Système

Ce deuxième diagramme de contexte, montre les interactions du système avec les autres
modules du projet RIAD. Ces interactions permettent de concevoir les interfaces nécessaires à
l’intégration du système au projet RIAD.
Parmi les système qui figurent sur le diagramme ceux qui sont déjà mis en place à savoir :
GIPE, Système des habilitations et le système de gestion des organisations. Les deux autres
sont en cours de développement.
Conclusion
Au cours de ce chapitre, nous avons présenté les différentes fonctionnalités auxquelles doit
répondre le système de gestion de la formation. Cela nous a permis par la suite d’identifier les
différentes entités composant l’environnement d’interactions du système, à savoir : les acteurs
humains, les acteurs systèmes et les messages échangés avec ces acteurs.
Le chapitre suivant est consacré à la présentation de la phase de conception du système de
gestion de la formation, et donc nous allons passer de l’étude de l’environnement externe du
système à l’étude de sa structure interne.

Chapitre 4 : Conception de la solution
Chapitre4 : Conception de la solution
Ce chapitre traite de la conception de la solution.

Nous présentons la décomposition du système en sous
modules. Ensuite, nous présentons le formalisme UML
(Unified Modeling Language) adopté pour
l’élaboration des diagrammes des différents packages
issus de la décomposition suivi de l’architecture
technique du système.
Introduction
« Diviser pour régner », c’est un principe appliqué presque partout. Cette fois, on le trouve
très pratique lors de la conception du système de gestion de la formation.
Vu la taille du système à développer, nous avons jugé très utile sa décomposition en sous
modules à faible couplage afin de bien maîtriser les aspects de modélisation.
1. Décomposition du système
Après avoir élaborer les diagrammes de contexte (Vue humaine et système), le regroupement
des messages et des interactions par catégories permet la décomposition du système selon les
différentes phases du processus de gestion de la formation dans l’ADII à savoir :
• Identification des besoins
• Elaboration des plans de formation
• Réalisation des actions de formation
• Evaluation des formations
Lors de cette décomposition en sous modules, nous nous sommes fixés l’objectif suivant : le
flux d’échange entre les sous modules doit être minimale tout en répondant à la totalité des
besoins identifié lors de la phase d’analyse des besoins.
Ainsi, cet aspect de modularité n’était en aucun cas au détriment des fonctionnalités
auxquelles le système doit répondre.
Le schéma ci-après, présente la décomposition du système (les acteurs ne sont pas tous
représentés pour ne pas surcharger le diagramme) :

Figure 8 : Décomposition du système en sous modules

Le Référentiel a pour but la mise en place des fonctionnalités d’archivage et de stockage de
données importantes pour la gestion des formations à l’administration telles que les
formateurs disponible sur le marché, les pôles de formation.
Le sous-module Services Communs est conçu pour assurer les différentes fonctionnalités
communes à tous les acteurs telles que les éditions et les consultations ainsi que l’accès aux
données.
Le sous module Interface permet à notre système de s’interfacer correctement avec les autres
système des projet RIAD.
Dans l’optique de concevoir un système extensible, évolutif, modulaire et orienté objet, le

formalisme UML s’est imposé comme l’outil le plus approprié pour ce projet. En effet, UML
permet de mener la phase d’analyse et de conception tout en bénéficiant de la puissance et de
la simplicité de ses diagrammes.
2. Choix du formalisme UML

Rappelons-nous que la plate forme technique du projet RIAD se base sur l’architecture J2EE.
C’est pourquoi nous avons opté pour UML comme langage de modélisation car la notation

UML est la plus appropriée pour des projets orientés objet. Ce choix peut être justifié
également par plusieurs raisons :
• Le processus de développement adopté se base sur les diagrammes UML
• La notation UML facilite la compréhension et la communication d’une modélisation
objet ;
• UML est aujourd’hui un standard, adopté par les grands constructeurs de logiciel du
marché.
Pour organiser le modèle de spécification fonctionnel d’une part et respecter la décomposition

précédente d’autre part, nous avons opté pour l’utilisation des packages, qui représentent les
besoins d’une entreprise vis-à-vis d’un système informatique.
3. Packages du système
Dans l’optique de s’aligner avec le choix du formalisme UML, les sous modules de la
décomposition sont traduit en cinq packages essentiels à savoir :
• Package grille
• Package plan
• Package action
• Package évaluation
• Package interface permettant de communiquer avec les autres systèmes.
Dans la suite de ce chapitre, nous allons nous focaliser sur les quatre packages métier et
essentiellement sur les composantes principales de chacun de ces packages. Pour mieux
expliciter ces composantes, nous nous sommes appuyés sur la méthodologie suivante :
1. Elaboration du diagramme de cas d’utilisation (use cases)

2. Description textuelle de chaque cas d’utilisation : la fiche de description textuelle d’un
cas d’utilisation n’est pas normalisée par UML. Nous préconisons pour notre part la
structuration suivante :
a. Sommaire d’identification (obligatoire) : inclut titre, but, résumé, dates,
acteurs, responsables, version…
b. Description des scénarios (obligatoire) : décrit les scénarios principaux et ceux
secondaires, mais aussi les pré conditions et les post-conditions.
c. Besoins d’IHM : ajoute éventuellement les contraintes d’interfaces homme-
machine.
3. Identification des objets pour aboutir à un diagramme d’objets.
4. Etablissement des diagrammes des classes candidates à partir des diagrammes
d’objets.
5. Elaboration des diagrammes de séquences des scénarios principaux.
3.1. Package grille

Ce package répond aux différentes fonctionnalités relatives à l’élaboration des grilles de
compétences permettant l’identification des besoins en formation de l’administration.
Après avoir analyser les fonctionnalités à ce package, nous constatons l’existence de trois cas
d’utilisations à savoir :
1- Gestion des opérations ;
2- Gestion des savoir faire ;
3- Gestion des grilles.

Le diagramme suivant montre les interactions entre les cas d’utilisation de ce package et les
utilisateurs du système :
Figure 9 : Diagramme de cas d’utilisation du package « Grille »
Les acteurs interagissant avec le système dans le cadre de ce package sont le responsable
immédiat qui établit les grilles de compétences et le cadre de formation qui valide l’ajout de
nouveaux savoir-faire et des opérations.
Description du cas d’utilisation « Gestion des grilles de compétences »
Sommaire d’identification
Titre : Gestion des grilles de compétences

But : Ce cas d’utilisation permet au responsable immédiat d’élaborer la grille de
compétences de sa structure.
Résumé : Création d’une nouvelle grille de compétence ainsi que la mise à jour de
cette dernière.
Acteurs : Responsable immédiat.
Date de création : 19/02/2004 Date de mise à jour : 22/02/2004
Version : 1.0 Responsable : Omar BEL LAKHDAR
Description des scénarios
Pré condition :
1. Le responsable immédiat est authentifié.
Enchaînement : Ce cas d’utilisation commence lorsque le responsable immédiat
demande au système de créer, modifier ou supprimer une grille.
Scénario principal :
1. Création d’une nouvelle grille
Après diagnostic des compétences disponibles au sein de sa structure, le
responsable immédiat fournit les informations du diagnostic à savoir:

• Pour chaque agent, son degré de maîtrise d’une opération

• Son savoir-faire : maîtrise de certaines langues.
Une fois validée, le système calcule les deux indicateurs qui servent à
l’élaboration des plans internes.
Scénarios secondaires :
2. Mise à jour d’une grille
Le responsable immédiat peut mettre à jour une grille sélectionnée tout en :
enlevant une opération, un agent et/ou modifiant les compétences mentionnées
dans la grille.
3. Suppression d’une grille
Le responsable immédiat peut également supprimer une grille existante.
Post condition
La grille ne contient que les opérations effectuées au sein de la structure ainsi
que les agents de cette dernière.
Besoins d’IHM
Le responsable immédiat doit pouvoir :

a. Lister les opérations qui s’effectuent au sein de sa structure.
b. Lister les agents de sa structure par ordre alphabétique ou autre.
c. Lister les savoir-faire existants dans sa structure.
Diagramme d’objets
Figure 10 : Diagramme d’objets du cas d’utilisation «Gestion des grilles »
Ce diagramme montre qu’une fois une instance de grille est créée, il y a automatiquement
création de plusieurs instances de « Savoir-faire », « Opération » et « Agent ».

Diagramme de classes
Pour ne pas surcharger le diagramme, nous avons opté à présenter les classes sans méthodes.
Figure 11 : Diagramme de classes du package « Grille »

Sur ce diagramme figurent les classes candidates du package grille. La classe grille est une
classe d’association entre les opérations et les agents car elle permet d’évaluer le degré de
maîtrise effective des opérations par l’agent.
Diagramme de séquence
Nous allons présenter celui de la création d’une grille parce qu’il constitue le noyau de tout le
package :

Figure 12 : Diagramme de séquences du scénario « Création d’une grille »
Sur ce diagramme, nous illustrons les différentes interactions entre les objets participant à la
création d’une grille de compétences.
La création des grilles de compétences déclenche la deuxième phase du processus de gestion
de la formation qui est l’élaboration des plans. La partie suivante, montre la conception du
package « Plan ».
3.2. Package plan

Ce package regroupe toutes les fonctionnalités visant à satisfaire le besoin de définir les
actions de formation à entreprendre et à l’établissement des plans internes, régionaux et
nationaux.
Pour pouvoir gérer les différentes sortes de plans, nous identifions les trois cas d’utilisation
suivants :
1. Gestion des plans internes ;
2. Gestion des plans régionaux ;
3. Gestion des plans nationaux.
Le diagramme suivant montre les interactions entre les utilisateurs responsables de

l’établissement des plans de formations et les cas d’utilisation de ce package :

Figure 13 : Diagramme de cas d’utilisation du package « Plan »
Les acteurs cette fois-ci sont : le responsable immédiat, le cadre de formation, le chef de
circonscription et le formateur régional. Ces deux derniers jouent le même rôle et ce dans le
cas où la circonscription est attachée directement à la direction centrale.
Description de la «Gestion des plans régionaux»

Titre : Gestion des plans régionaux.

But : Ce cas d’utilisation permet au responsable de formation (*) d’élaborer
le plan régional de formation de la direction ou de la circonscription.
Résumé : Création, mise à jour et suppression d’un plan régional.
Acteurs : Responsable de formation (*)
Directeur régional.
Version : 1.0 Responsable : Omar BEL LAKHDAR
(*) : Responsable régional est soit un formateur régional ou un chef de circonscription
dans le cas où la circonscription est attachée directement à la direction centrale.

Pré condition :
1. Le responsable de formation est authentifié.
2. Les plans internes sont validés.
Enchaînement : Ce cas d’utilisation commence lorsque le responsable de formation
demande au système de créer, modifier ou supprimer un plan régional.
1. Création d’un nouveau plan régional
Le responsable de formation sélectionne les plans internes et élabore son plan
régional en se basant sur le plan provisoire offert par le système.
Il est appelé à fournir les informations nécessaires à la finalisation du plan
régional. Une fois le plan est validé par le Directeur régional, une notification
est envoyée au cadre de formation.
2. Mise à jour d’un plan
Le responsable de formation peut mettre à jour un plan tout en le sélectionnant
de la liste.
3. Suppression d’un plan
Le responsable de formation peut également supprimer un plan existant.
Post condition :
Les formations qui figurent dans le plan régional peuvent être parmi celles des
plans internes.
Besoins d’IHM
Le responsable de formation doit pouvoir :

a. Lister les plans internes par structure.
b. Lister tous les plans internes.
c. Lister les plans régionaux pour la modification et la suppression.
Nous prenons comme exemple, celui du cas d’utilisation « gestion des plans régionaux » :
Figure 14 : Diagramme d’objets du cas d’utilisation « Gestion des plans régionaux »

Ce diagramme sert de base pour l’implémentation du diagramme de classes suivant :

Diagramme de classes
Figure 15 : Diagramme de classes candidates du package « Plan »

Le diagramme de classe ci-dessus, illustre la structure du package « Plan ». Un plan de
formation est composé d’une ou plusieurs formations dont chacune peut prendre en charge
des axes de notes d’orientations générales.

Diagramme de séquences
Figure 16 : Diagramme de séquences de « création de plan régional »

Sur ce diagramme, s’illustre la séquence d’actions à entreprendre pour la création d’un plan
régional de formation.
Une fois les plans de formation sont élaborés, la programmation et la planification des actions
de formation commencent. L’étude du package « Action » est l’objet de la partie suivante.
3.3. Package action

Ce package, comme l’indique son nom, vise à répondre au besoin de la programmation des
actions ou sessions de formation.
Les cas d’utilisation de ce package sont les suivants :
1. Gestion des formateurs ;
2. Gestion des formations ;
3. Gestion des participants ;
4. Gestion des organismes de formation ;
5. Planification des actions de formation ;
utilisateurs du système :

Figure 17 : Diagramme de cas d’utilisation du package Action
Les interactions entre les entités composant ce diagramme, permettent de mettre en place les
programmes de mise en place des formations retenues dans les plans régionaux et national.
Description de la « Planification d’une action de formation »
Titre : Planification d’une action de formation

But : Mise en place d’un planning de réalisation d’une action de formation et
affectation des ressources nécessaires à l’action de formation
Résumé : Détermination du lieu et des dates de réalisation d’une action de formation
ainsi que les formateurs qui vont assurer l’animation de cette action.
Les moyens matériels nécessaires à la mise en place de l’action de
formation doivent être réservés
Acteurs : Responsable de formation
Version : 1.0 Responsable : Abdellah Skal

Pré condition :
1. Le responsable de formation est authentifié
2. L’action de formation doit être prévue dans un plan de formation
Enchaînement : Ce cas d’utilisation commence lorsque le responsable de formation
demande la création, la modification ou la suppression d’un planning de réalisation
d’une action de formation.
1. Création d’un planning
Le responsable de formation sélectionne une action de formation prévue dans un
plan de formation puis crée un planning de réalisation de l’action.
Dans le planning, il précise :
a. le lieu de déroulement
b. les dates de début et de fin
c. l’heure de début et de fin de chaque séance et sa durée
d. l’animateur de l’action…
2. Modification d’un planning
Le responsable de formation sélectionne une action de formation et modifie les
éléments figurant dans le planning de l’action de formation en modifiant un ou
plusieurs des éléments cités dans la description du scénario précédent.
3. Suppression d’un planning
Le responsable de formation sélectionne une action de formation et supprime son
planning créé auparavant.
Post condition ;
Besoins d’IHM
Afin de pouvoir créer, modifier ou supprimer un planning d’une action de formation,

le responsable doit pouvoir sélectionner l’action dans une liste d’actions de formation.
Il peut ordonner cette liste selon :
a. Les plans de formation
b. l’ordre alphabétique
c. Autres critères à déterminer.
Le responsable de formation doit pouvoir imprimer le planning de l’action de
formation.

Figure 18 : Diagramme d’objets de « Planification d’une action de formation»
Les objets figurant sur ce diagramme sont des instances des classes constituant le diagramme
de classes suivant :

Diagrammes de classes
Figure 19 : Diagramme de classes candidates du package « action »

Figure 20 : Diagramme de séquences de planification d’une session de formation

Sur ce digramme nous trouvons la logistique nécessaire pour la mise en place d’une session
de formation.
Une fois les formations sont réalisées, alors la phase importante de l’évaluation commence.
Lors de cette phase, les fiches résultantes des différentes sessions de formations sont
synthétisées pour évaluer ces formations.
La partie suivante montre la conception du package « Evaluation » qui prend en charge les
fonctionnalités de cette phase.
3.4. Package évaluation

Le package « évaluation » se charge des différentes fonctionnalités permettant l’analyse des
résultats de la phase de mise en place des actions de formation.
Les cas d’utilisation de ce package sont les suivants :
1. Gestion des fiches d’évaluation ;
2. Gestion des fiches d’absences ;
3. Gestion des fiches d’appréciation ;
4. Elaboration du rapport d’évaluation.
utilisateurs participants à la réalisation de la phase d’évaluation des résultats :

Figure 21 : Diagramme de cas d’utilisation du package Evaluation
D’après ce diagramme, il est clair que l’évaluation s’effectue essentiellement à base des fiches
d’appréciation remplies par les participants aux formations, des fiches d’évaluation
permettant le contrôle du niveau d’apprentissage des participants et des fiches de présences.
La synthèse de ces fiches constitue le noyau du rapport d’évaluation qui est le fruit final de
cette phase.
Description du cas d’utilisation « Elaboration du rapport d’évaluation »
Titre : Elaboration du rapport d’évaluation

But : Elaboration de la synthèse d’une formation ce qui permet l’évaluation de
ses résultats.
Résumé : Le rapport d’évaluation d’une formation est destiné à l’analyse des résultats
d’une formation, en synthétisant les données des fiches d’évaluation et des
fiches d’appréciation ainsi que les fiches d’absences.
Acteurs : Cadre de formation
Version : 1.0 Responsable : Abdellah Skal

Pré condition :
1. Le cadre de formation est authentifié
Enchaînement : Ce cas d’utilisation commence lorsque le cadre de formation
demande la création, la modification ou la suppression d’un rapport d’évaluation
d’une formation.
1. Création d’un rapport d’évaluation
Le cadre de formation sélectionne un plan de formation et choisit une formation,
puis crée un rapport d’évaluation de la formation.
2. Modification d’un rapport d’évaluation
Le cadre de formation sélectionne un rapport d’évaluation et modifie son contenu.
3. Suppression d’un rapport d’évaluation
Le cadre de formation sélectionne une formation et supprime son rapport
d’évaluation.
Post condition :
1. Le rapport à créer doit concerner une formation déjà réalisée
Besoins d’IHM
Le plan de formation est choisi à partir d’une liste de plans qui peut être ordonnée
selon l’année pour laquelle le plan est élaboré. Lors de la création du rapport
d’évaluation d’une formation, le cadre de formation doit pouvoir accéder directement
aux fiches d’évaluation et d’appréciation.
Figure 22 : Diagramme d’objets de « Elaboration du rapport d’évaluation»

Ce diagramme et ceux concernant les autres cas d’utilisation de ce package, constituent la

base du digramme de classes suivant :
Diagramme de classes candidates
Figure 23 : Diagramme de classes candidates du package «Evaluation»

Ce diagramme traduit les relations entre les classes constituant le package « Evaluation ».

Figure 24 : Diagramme de séquences de l’élaboration du rapport d’évaluation

Ce dernier diagramme montre l’aspect dynamique des composants de ce package. En effet, il
décrit les interactions entre les objets participant à l’élaboration du rapport d’évaluation d’une
formation.
4. Architecture technique du système

Après avoir achevé la conception du système, nous avons mis en place l’architecture
technique du système qui permet de le décomposer en plusieurs couches. Cette décomposition
permet de maîtriser le développement du système.
L’architecture technique du système que nous avons mis en place est schématisée comme
suit :
Système de gestion de la formation
Client
Figure 25 : Architecture technique du système de gestion de la formation

Cette architecture comporte cinq couches dont chacune a un rôle bien déterminé :
• Couche Présentation : Elle regroupe les interfaces de l’application du système qui
reçoivent les actions des utilisateurs ;
• Couche Services : Cette couche traduit les scénarios identifiés lors de la phase de
conception sous forme de services mis à disposition des utilisateurs ;
• Couche Métier : Cette couche est constituée des objets métier identifiés lors de la
phase de conception après l’élaboration des diagrammes de classes des différents
packages ;
• Couche Mapping et Persistance : Cette couche se charge de la persistance des objets
et du mapping (association des objets avec les éléments de la BD relationnelle) ;
• Couche Données : Cette dernière couche assure le stockage des données manipulées
par les utilisateurs.
Conclusion
Dans ce chapitre, nous avons exploré les différents packages métiers qui ont été identifiés lors
de la décomposition du système étudié et nous avons mis en place l’architecture technique du
système de gestion de la formation.
La conception présentée dans ce chapitre est la base de la phase de réalisation du système qui
fera l’objet de la partie suivante.

Partie 3 : Mise en œuvre du projet et intégration dans RIAD
PARTIE 3 : MISE EN ŒUVRE DU PROJET ET

INTEGRATION DANS RIAD
La dernière phase de du cycle de développement adopté est la

réalisation du système et son intégration avec l’existant.
Ainsi, cette partie est composée de deux chapitre : le premier

passe en revue les différentes technologies et outils utilisés
pour la réalisation, et établit des comparaisons entre ces
technologies et outils et d’autres choix disponibles et
concurrents.
Le deuxième chapitre présente l’architecture applicative du

système suivie par l’explication du déroulement des différentes
étapes de la phase de réalisation. La dernière partie de ce
chapitre est consacrée à la présentation des différentes
interfaces permettant l’intégration du système dans le projet
RIAD, et par la suite son déploiement.

Chapitre 5 : Technologies et outils utilisés
Chapitre5 : Technologies et outils

utilisés
Compte tenu de la richesse de l’infrastructure support

du projet RIAD, nous avons réservé le présent
chapitre pour la présentation de cette infrastructure
selon les axes suivants : l’architecture, les
technologies, les modèles et les outils.
Introduction
L’infrastructure informatique mise à disposition par l’ADII pour la réalisation du projet
RIAD, est basée sur l’architecture et les technologies J2EE. Ainsi, les frameworks et les
Design Patterns open source en plus du pack Oracle9i AS sont les piliers de cette
infrastructure.
1. L’architecture J2EE
Les entreprises recherchent, de plus en plus, des solutions qui permettent la diminution des
coûts des applications et la réduction du temps de développement tout en respectant les
standards de qualité logicielle.
Typiquement, les applications qui répondent à ces besoins doivent combiner entre les
systèmes d’information existants et les nouvelles fonctions métiers qui apportent des services
à un large intervalle des utilisateurs. Ces services doivent assurer :
• Une haute disponibilité, pour répondre aux besoins actuels de l’environnement
métier ;
• La sécurisation des applications et des données.
• Une meilleure fiabilité, pour s’assurer que les transactions sont exécutées d’une
manière exacte et prompte.
Pour répondre à ces critères, ces services sont conçus à base d’applications multicouches
reposant sur plusieurs niveaux à savoir la couche client, la couche donnée et plusieurs
couches intermédiaires [wwwSUNJ2EE].
L’architecture J2EE (Java 2 Entreprise Edition) promue par SUN® MICROSYSTEMS définit
et fournit un modèle de programmation multi tiers basé sur des composants. Avec ce modèle,
des applications légères peuvent interagir facilement avec le système d'information et les
composants implantant la logique d'entreprise sur des serveurs d'applications.
L’architecture J2EE consiste en trois parties :
• Components : les composants qui prennent en charge la présentation et la logique
métier ;
• Containers : fournit un contexte aux composants ;
• Connectors : fournit l’accès aux sources de données de l’entreprise.

2. Les technologies J2EE

Les technologies J2EE définissent la norme de développement des applications d’entreprise
distribuées et multi tiers. Elles permettent de simplifier les applications d'entreprise en les
basant sur des composants modulaires normalisés tout en fournissant un ensemble complet de
services et en gérant automatiquement un grand nombre de détails sur le comportement des
applications.
Ces technologies qui sont regroupées en trois catégories : composant, service et
communication [wwwSUNJ2EE].
Technologies de type composant

Les technologies de type composant sont utilisées par les développeurs afin de créer des
composants logiciels d’une application d’entreprise notamment l’interface utilisateur et la
logique métier. Elles permettent de développer des modules réutilisables qui peuvent être
intégrés dans d’autres applications. De plus, elles sont supportées par les services
d’infrastructures de la plate-forme J2EE qui simplifient le développement des applications et
permettent d’adapter les composants aux besoins des ressources de l’environnement de
déploiement.
Technologies de type service

Etant donné que la plupart des applications d’entreprise ont besoin d’accéder aux systèmes
d’information d’entreprise, la plate-forme J2EE offre un ensemble de services tels que l’accès
aux bases de données (JDBC), nommage (JNDI), transaction et services de Messagerie.
Technologies de type communication

La plate-forme J2EE fournit un ensemble de technologies permettant la communication entre
clients et serveurs, et entre les objets qui collaborent dans les différents serveurs, telles que les
connecteurs aux systèmes d’information existants et l’invocation des méthodes distantes à
travers RMI.
Les technologies présentées ci-dessus peuvent être positionnées comme suit :
Tools Application Programming Model
Transactions
Connectors
JavaBeans
Container
Messaging Mail
Applets
Java 2 SDK, Standard Edition

CORBA RMI Database Naming/Directory
Figure 26 : Technologies J2EE

3. Design Patterns MVC et MVC2

Comme nous l’avons signalé, l’infrastructure de RIAD intègre le Design Pattern MVC pour la
conception des applications développées dans le cadre du projet RIAD.
Dans cette partie, nous allons définir le terme Design Pattern avant de procéder à une
comparaison entre les deux Design Patterns : MVC et MVC2 suivant lequel nous avons conçu
le système de gestion de la formation.
Un Design Pattern donne un nom, isole et identifie les principes fondamentaux d'une structure
générale, pour en faire un moyen utile à l'élaboration d'une conception orientée objet
réutilisable [GAMMA95]. Ce type de Patterns, également appelés Patterns de conception
orientés objet, sont les Patterns les plus utilisés.
Trois catégories des Design Patterns sont définies [wwwECKEL]: les patterns de création, les
patterns structuraux et les patterns de comportement (Annexe 4).
Le modèle MVC est un type de Design Patterns de la catégorie « Patterns structuraux ». Il est
simple mais en même temps très utile, il permet essentiellement de concevoir une application
en utilisant les trois niveaux suivants :
• MODEL : c’est le noyau de l’application. Il maintient l’état et les données que
l’application représente. Quand des changements significatifs apparaîtront dans le
modèle, les vues aussi seront changées ;
• CONTROLLER : il définit le comportement de l’application et gère l’interaction avec
l’utilisateur. Il fait appel au modèle des composants pour répondre aux requêtes de
l’utilisateur
• VIEW : l’interface utilisateur qui est la représentation visuelle du « modèle ».
Application Web
Servlet Modèle
Contrôleur
JSPs
Servlet Classes
NAVIGATEUR BD,
Métiers
fichiers
JSPs
Servlet
Vue
JSPs
Figure 27 : Modèle MVC

Cette architecture qui sépare le contrôle des actions utilisateurs, la couche métier et la couche
de présentation favorise le développement et la maintenance d'une application. Malgré cet
apport, il présente un inconvénient majeur : la multiplication des points d'entrée (pages JSP et
servlet) dans l'application. La mise en place de services comme la sécurité,
l'internationalisation, ou la personnalisation devient alors complexe avec cette architecture.
Le modèle MVC 2 propose de palier à cet inconvénient en utilisant un seul point d’entrée
pour chaque application. Ainsi, une application contient un seul contrôleur frontal sous la
forme d'un servlet d'entrée unique.

Le modèle ci dessus devient ainsi comme suit :
Application Web
Servlet Modèle
Contrôleur Frontal
niq e
Classes
NAVIGATEUR BD,
Métiers
JSPs fichiers
JSPs
Vue
JSPs
Figure 28 : Modèle MVC2
C'est sur ce modèle que plusieurs frameworks sont conçus afin d'aider les développeurs à
construire la couche de présentation de leur applications web. Dans la communauté java, c'est
le projet Jakarta Struts qui fait référence
4. Framework « Struts »
Un framework est un ensemble d'outils et de composants qui aident au développement
d'application, pour un contexte donné. Cela inclut :
• Un ensemble de Design Patterns ;
• Un ensemble d’interfaces et d’implémentations ;
• Des outils associés.
4.1. Choix du framework Struts
Pour remédier aux inconvénients du modèle MVC, nous avons proposé au comité de pilotage
du projet RIAD de concevoir le système de gestion de la formation selon le modèle MVC2.
La proposition a été retenue et nous avons choisi de bénéficier des atouts du framework Struts
qui seront listés dans cette partie.
Le projet Struts est géré au sein de la communauté « Apache Software Foundation » dans le
cadre des projets « Jakarta ». La motivation de ce projet est de fournir à la communauté Java
un framework basé sur le design pattern MVC2 tout en utilisant les technologies J2EE
standards : JSP/Servlet, JavaBean, XML.
Cependant, Struts n‘est pas le seul framework permettant la gestion de la couche présentation.
En effet, d’autres frameworks ont été conçus pour le même objectif, tels que Barracuda,
Hammock, Tapestry et Webwork.
L'apport le plus significatif de Struts est la structuration de la couche de présentation des

applications Internet/Intranet suivant le pattern MVC2. Le développeur est bien mieux guidé
dans sa tâche. En général, il lui suffit de personnaliser les actions pour les traitements
adéquats des requêtes. Il en découle un développement plus efficace mais également une
meilleure homogénéisation du code des applications.

Le tableau suivant résume une comparaison entre plusieurs frameworks MVC2 [wwwAS] :
Framwork Version URL Puissance Complexité

Barracuda PR2 http://barracuda.enhydra.org/ +++ +++
Hammock 1.0 http://www.oop.com/TechnologiesHammock.jsp +++ +++
Tapestry 0.2.9 http://sourceforge.net/projects/tapestry ++ +++
Webwork 0.95 http://sourceforge.net/projects/webwork/ + +
Struts 1.1 http://jakarta.apache.org/struts +++ ++
Tableau 3 : Comparaison de quelques frameworks en terme de puissance et de complexité
Ainsi, l’atout principal qui fait la force de Struts est la complexité réduite par rapport aux
autres Frmework de même degré de puissance.
Le manque d'expertise technique sur les technologies web de Java n'est plus un frein pour
aboutir à une application robuste, évolutive et maintenable : on peut utiliser Struts pour la
couche de présentation avec un niveau d'expertise minime.
4.2. Architecture et fonctionnement du framework Struts

La structure du framework Struts découle du modèle MVC2 (cf. la figure 28). Selon ce
modèle, on retrouve dans Struts un contrôleur, des vues et l'accès au modèle.
Contrôleur
Le contrôleur du framework Struts est chargé de faire le lien entre la vue et le modèle. Il
réceptionne toutes les requêtes clientes et les redirige vers des actions spécifiques. Ces
correspondances (mapping) sont décrites dans un fichier de configuration « struts-
config.xml ».
Le contrôleur principal est matérialisé par un unique servlet offert par le framework :
« ActionServlet ». Les autres actions sont des modules actions construits à partir de classes
Struts « Action ». Chaque action accède au modèle pour récupérer les données nécessaires au
traitement de la requête cliente.
La centralisation des accès à l’application permet un contrôle fin et personnalisé des
traitements des requêtes. La gestion de la navigation est déclarative et n’est pas figée dans le
code java. Cette solution est très flexible.
Vue
La vue est un ensemble de pages JSP. Afin de faciliter leur construction, le framework struts
propose plusieurs librairies de "tag" (ou balise).
Un tag permet de séparer le code java du rendu de la page. L'écriture du tag repose sur deux
composants : les classes de gestion de tag et le fichier de description des tags. Les tags
peuvent ensuite être utilisés dans les JSPs. On évite ainsi la présence de code java au sein
même de la page JSP.
Aujourd'hui, Struts 1.1 intègre quatre bibliothèques de tags :

• La librairie de tag « Bean » pour la manipulation des beans ;
• La librairie de tag « Html »pour la création et la manipulation des formulaires html ;
• La librairie de tag « logic » pour mettre en œuvre des traitements conditionnels et
itératifs ;
• La librairie de tag « Template » pour la création et la gestion de modèles.

Modèle
Suivant le pattern MVC2, le modèle est indépendant du contrôleur. Le framework Struts n'en
impose aucun. Le choix technologique incombe au développeur (JDBC, EJB, JDO, XML,
Composant métier maison ...) suivant ses besoins.
Serveur d’application
Framework Struts
Contrôleur 2 Modèle
3
Action
Action Action
1 servlet
1 Action
5 EJB, CORBA,
6
JDO, JDBC,
4
7 XML,…
Vue
Navigateur JSP
JSP
JSP
Struts-config.xml
Figure 29 : Principe de fonctionnement du framework Struts

L'interaction entre les trois composants est orchestrée par le contrôleur principal. Afin de
mieux comprendre le fonctionnement du framework, on détaille le cycle de vie d'une requête
HTTP, schématisé dans la figure 29 :
1. Le client envoie sa requête HTTP à l'application. Cette requête est prise en charge par
le contrôleur principal, en l'occurrence ActionServlet;
2. La requête est redirigée vers le contrôleur adéquat;
3. Le contrôleur choisi prend en charge le traitement de la requête. Un dialogue avec les
services métiers est entamé si nécessaire;
4. Le modèle fournit les données demandées;
5. Le contrôleur principal est notifié du résultat du traitement. En cas de succès, les
données sont encapsulées dans des JavaBean (ActionForm) et transmis à la JSP
sélectionnée par le contrôleur;
6. La JSP construit la réponse suivant les données transmises;
7. La réponse est envoyée au navigateur.
5. Framework « TopLink »
5.1. La problématique de la persistance objet
Si le modèle objet offre des capacités de modélisation et d’abstraction avancées, il est en
revanche handicapé par une grave limitation : il se focalise exclusivement sur les aspects
dynamiques de l’exécution des programmes, sans couvrir réellement la problématique de la
persistance des objets.

Par contraste, dans le modèle relationnel, les données sont persistantes : une fois que la
structure du schéma relationnel a été définie, les données qui y sont ajoutées restent
accessibles durablement, tant qu’elles ne sont pas explicitement supprimées. La durée de vie
des données est donc totalement indépendante du cycle de vie des sessions applicatives qui les
manipulent.
Pour apporter ce caractère de durabilité des données au modèle objet, il convient donc de
trouver un moyen de prolonger l’existence des objets au-delà de l’existence d’une session
applicative. Pour désigner cette capacité des objets à survivre en dehors du contexte
d’exécution applicatif, on parle de persistance objet. La problématique de la persistance objet
consiste donc à élaborer et à mettre en œuvre les mécanismes permettant de sauvegarder de
façon fiable et durable l’état des objets manipulés par une application.
Techniquement, il existe plusieurs approches pour implémenter la persistance objet [SQLI03]:

• sérialisation : La sérialisation consiste à sauvegarder l’état (les valeurs d’attributs)
d’un objet comme un flux d’information unidimensionnel (sériel) dans un fichier texte
(fichiers XML par exemple) ou binaires (fichiers binaires).
• mapping objet/relationnel : cette technique vise à définir et utiliser un schéma en
base de données relationnelle pour assurer la persistance de l’état des objets. Elle
consiste à définir précisément la structure d’une ou plusieurs tables qui seront utilisées
pour sauvegarder les différents attributs d’un objet.
• persistance en base de données objet : le problème de la persistance objet a donné
lieu au développement d’un nouveau type de bases de données : les bases de données
orientées objet. Contrairement aux bases de données relationnelles qui emploient des
structures bidimensionnelles (les tables), les bases de données objet utilisent les
mêmes représentations que les objets : des structures hiérarchiques (graphes).
Il est également nécessaire d’implémenter la logique de persistance qui va permettre aux

applications d’effectuer la sauvegarde et la restauration de l’état des objets manipulés. C’est le
rôle de la couche de persistance (ou moteur de persistance). Le moteur de persistance expose
une API aux applications pour la création, la mise à jour, et la recherche d’objets sur le
support de persistance. A ce moteur de persistance, il est également nécessaire d’associer un
outil de projection des objets sur le support de persistance : le rôle de cet outil est de fournir le
moyen de définir les règles de transformation entre la représentation des objets en mémoire et
la représentation de ces objets sur le support de persistance, avec la création des structures de
données nécessaires.
La persistance objet est donc une problématique très complexe, qui nécessite la mise en
œuvre d’outils spécifiques et sophistiqués.
Parmi ces outils, on trouve Oracle9iAS TopLink qui représente la solution la plus mature sur
le marché (Annexe 5).
5.2. La solution « Oracle9iAS TopLink »

Oracle9iAS TopLink est un produit dont le noyau est le framework TopLink éprouvé en
matière de persistance de modèles objets complexes en base relationnelle, et adoptant
l’approche de persistance : mapping objet/relationnel.
Oracle9iAS TopLink relève la problématique de persistance en établissant un lien entre les

technologies orientées objet et relationnelles, ce qui permet aux applications de stocker et

d’extraire des objets Java de manière transparente à l’aide d’une base de données relationnelle
ou d’autres systèmes de stockage.
Oracle9iAS TopLink permet aux applications Java d’accéder aux données stockées dans des
bases de données relationnelles en tant qu’objets. Les développeurs d’applications peuvent
travailler avec des bases de données relationnelles comme ils le feraient avec n’importe quelle
application Java, indépendamment de la persistance.
Oracle9iAS TopLink permet aux développeurs de se concentrer sur l’application et le modèle

d’objet, plutôt que sur l’infrastructure de la base de données. Oracle9iAS TopLink peut lier
des objets Java à une base de données existante (héritée) ou suggérer un nouveau schéma de
base de données à partir d’un modèle d’objet (ou vice versa).Cette solution fournit un jeu de
fonctionnalités étendu pour lire, écrire, supprimer et gérer efficacement les objets.
Oracle9iAS TopLink ne remplace pas JDBC, mais l’utilise efficacement et isole les
développeurs de ses détails. Les développeurs d’applications travaillent uniquement en
langage Java avec des objets via Oracle9iAS TopLink, et non avec des lignes relationnelles et
le langage SQL via des appels JDBC.
Figure 30 : Composantes principales du framework TopLink
Oracle9i AS TopLink crée un ensemble de «descripteurs de mapping » (Annexe 5), ou méta

données, qui définissent le mode de stockage des objets dans un schéma de base de données
particulier. Oracle9iAS TopLink utilise ces descripteurs lors de l’exécution pour générer de
façon dynamique les déclarations SQL requises. Les descripteurs peuvent être modifiés sans
qu’il soit nécessaire de recompiler les classes qu’ils représentent. Aucune programmation
SQL n’est requise. Les descripteurs de méta donnés sont indépendants du langage et de la
base de données.
6. Oracle 9i Application Server

Un serveur d’applications reprend la même logique du serveur de fichiers, et applique cette
logique aux applications qu’il héberge. Ainsi, les applications déployées dans un serveur

d’applications deviennent disponibles pour les utilisateurs demandant l’exécution de ces

applications.
D’autres fonctionnalités sont offertes par les serveurs d’applications telles que la sécurité et la
tolérance aux pannes.
Dans l’ADII, le serveur d’applications utilisé pour le déploiement des applications du projet
RIAD, est le serveur d’application d’Oracle : Oracle 9i Application Server.
Oracle9iAS est une plate-forme très fiable dédiée au déploiement d’applications
Internet/Intranet. Ce serveur d’applications comprend des environnements J2EE et Web
Services très bien optimisés; une excellente évolutivité sur un ou plusieurs processeurs;
plusieurs fonctions de haute disponibilité telles que la tolérance aux pannes, le clustering, les
mises à jour et la maintenance en ligne; l’administration centralisée des systèmes et de la
sécurité pour les applications Internet et les utilisateurs.
Il est conçu pour réduire le coût total d’exploitation associé au développement, au
déploiement et à l’utilisation des applications.
Oracle9iAS, permet de :
• développer et déployer des sites Web Internet/Intranet dynamiques, des applications
J2EE et des Web Services ;
• créer des portails personnalisés ;
• rendre les sites et les applications accessibles depuis les navigateurs traditionnels et les
terminaux mobiles ;
• émettre des recommandations personnalisées en temps réel, analyser les journaux de
flux de clics et extraire des informations de type Business Intelligence du trafic sur le
Web ;
• intégrer les applications, sources de données et partenaires commerciaux existants au
sein d’une infrastructure e-business commune ;
• redimensionner les sites Web et applications à mesure que l’entreprise se développe ;
• administrer et sécuriser l’ensemble de l’infrastructure Web.
7. Environnement de développement JDeveloper 10g

JDeveloper 10g est un environnement de développement gratuit d’Oracle, adoptant les
technologies J2EE. Il permet le développement de plusieurs types d’applications, et intègre
plusieurs frameworks, en particulier, les deux que nous avons utilisé : Struts et TopLink.
Conclusion
Au cours de ce chapitre, nous avons présenté les différentes technologies et outils que nous
avons mis en œuvre pour la réalisation du système de gestion de la formation de l’ADII.
Dans le chapitre suivant, nous présentons l’architecture applicative du système, ainsi que
l’implémentation de chacune des couches de cette architecture tout en utilisant les différents
outils présentés ci-dessus.

Chapitre 6 : Mise en oeuvre
Chapitre6 : Mise en œuvre de la solution

et intégration dans RIAD
Ce chapitre a pour but la description de la phase de

mise en œuvre de la solution. Nous présentons d’abord
l’architecture applicative du système et détaillons
ensuite les deux dernières phases du cycle de
développement suivi : la réalisation et l’ intégration.
Introduction
La mise en place l’architecture technique et le choix des outils de travail présentés dans le
chapitre précédant, nous ont permis de mettre en place l’architecture applicative du système
de gestion de la formation. L’implémentation de cette architecture est le fruit de la phase de
réalisation.
La phase des tests permet de vérifier la validité du système, avant d’entamer la phase
d’intégration avec les autres modules du projet RIAD.
1. Architecture Applicative
L’architecture applicative comporte les différentes couches applicatives du système, et associe
à chaque couche l’outil de réalisation adéquat.
Afin de bien maîtriser le développement du système, l’architecture applicative du système de
gestion de la formation a été décomposée en cinq couches :
• couche Présentation ;
• couche Services ;
• couche Métier ;
• couche Mapping et persistance ;
• couche Données ;
Le schéma suivant montre l’architecture applicative finale du système :

Struts sous Jdeveloper10g PowerAMC 9
Couche Couche Couche Métier

Présentation Services (Packages
(JSP) (Actions) & Beans)
Oracle9iAS TopLink
Couche Mapping et persistance

(Chaine de connexion et Descripteurs de tables)
SGBD Oracle9i
Couche Données
(Base de données relationnelle)
Figure 31 : Architecture applicative du système de gestion de formation
Ce schéma, associe à chaque couche l’outil utilisé pour son implémentation. Ces couches ont
été développées dans l’ordre donné au début de ce paragraphe.
2. Réalisation des couches applicatives

2.1. La couche Données
Cette couche comporte le schéma de la base de données du système de gestion de la
formation. Le script de ce schéma a été généré automatiquement par PowerAMC9, que nous
avons utilisé pour élaborer le diagramme de classe pendant la phase de développement.
Ce script a été exécuté sur le serveur de base de données RIADDB, en utilisant SQL
Navigator4 qui sert à l’administration des bases de données.
2.2. La couche Métier

Cette deuxième couche comporte les beans des différents packages métier du système. Ces
beans sont les implémentations des classes métier du système. Ils ont été générés
automatiquement aussi par Power AMC9 à partir du digramme de classe élaboré
précédemment.
L’arborescence des packages métiers est la suivante :

Figure 32 : Arborescence des packages métier
Chaque package de l’arborescence comporte les beans correspondant aux classes lui
appartenant.
Ces beans sont appelés par les composants de la couche Services pour répondre aux requêtes
des utilisateurs.
2.3. La couche Mapping et persistance

Cette couche se charge de la persistance des objets métier manipulés par les services. En effet,
dans cette couche se compose des descripteurs (fichiers XML) des classes métier et des tables
associées à ces classes dans la base de données.
Le mapping des classes vers les tables de la base de données se fait à travers l’interface
graphique WorkBench de Oracle9iAS TopLink représentée par la figure suivante :

Figure 33 : Outil de mapping des classes vers les tables de la BD
A travers cette interface graphique, on associe à chaque classe sa table correspondante, ainsi
que les différentes relations entre les classes.
Une fois le maping est terminé, alors on génère le code XML ou JAVA correspondant au
projet de mapping achevé afin d’exécuter les fonctions de persistance. Dans notre cas, nous
avons choisi de générer le code JAVA pour optimiser le temps d’exécution de l’application.
En effet, le code XML que génère WorkBench est transformé en code JAVA avant d’être
utilisé dans un environnement JDevelopper.
2.4. La couche Présentation

Cette couche concerne les interfaces Homme-Machine que nous avons développé en utilisant
JSP et les Taglibs du framework Struts. A chacune de ces interfaces est associée une classe
ActionForm permettant de passer les paramètres de l’interface à l’Action (Service).Cette
opération se fait par le contrôleur « ActionServlet ».
Un exemple d’interface est représenté par la figure suivante :

Figure 34 : Page d’accueil du système de gestion de formation

Cette page contient le menu principal du système permettant d’accéder aux différents services
disponibles. Une présentation de la politique de formation de l’ADII figure aussi sur la même
page. Ainsi, la dernière couche à implémenter est la couche Services.
2.5. La couche Services

Comme l’indique son nom, cette couche comporte les services offerts par le système à
l’utilisateur. Ces services ne sont autres que l’implémentation des scénarios identifiés lors de
la phase de conception. Leur rôle consiste à répondre aux requêtes des utilisateurs qui sont
transmises par l’ActionServlet qui est le contrôleur frontal du système.
Lors de l’appel d’un service, ce dernier fait appel aux objets métier nécessaire pour répondre à
la requête de l’utilisateur.
3. Intégration dans le projet RIAD

Comme nous l’avons annoncé, et pour achever la mise en place du système de gestion de la
formation, il nous reste encore deux étapes : l’interfaçage avec les autres module de RIAD et
le déploiement.

3.1 Interfaçage avec les autres applications de RIAD

Les systèmes avec lesquels notre système doit s’interfacer sont ceux qui figurent sur le
diagramme de contexte (Vue système) élaboré lors de la phase de l’analyse. Ces interfaces
sont les suivantes :
• Interface avec le système des habilitations : cette interface a été mise en place du
coté du système de gestion des habilitations. Elle s’appuie sur une matrice de
privilèges constituée des différents rôles que nous avons identifiés lors de l’analyse, et
des différents services offerts par le système des gestion des de la formation. Cette
matrice associe chaque rôle aux services accessibles pour lui ;
• Interface avec le progiciel GIPE : Cette interface est implémentée par la classe
« Agent » du package « Grille ». En effet, cette classe a été mappée vers la table Agent
du progiciel GIPE. Ce mapping rend les données administratives du personnel de
l’ADII, gérées par le GIPE, accessible en lecture pour le système de gestion de la
formation.
L’option « lecture seule » a été choisie pour interdire aux utilisateurs de notre système
d’agir en écriture sur ces données ;
• Interface avec le système des organisations : l’interfaçage avec le système de
gestion des organisations a été réalisé de la même façon qu’avec GIPE. Cette fois, la
classe « Organisation » du package « Grille » a été mappée vers la table
« Organisation » du système de gestion des organisations. Ce mapping a été fait
toujours avec l’option « lecture seule » ;
• Interface avec le système de gestion budgétaire : Cette interface doit être mise en
place du côté du système de gestion budgétaire qui est en cours de réalisation. Cette
interface doit permettre au système de gestion budgétaire l’accès aux coûts des
formations réalisées par l’ADII. Ces coûts sont gérés par le système de gestion des
formations ;
• Interface avec le système de gestion des profils et compétences : Cette dernière
interface doit être aussi mise en place par le système de gestion des profils et des
compétences qui n’est pas encore réalisé. Le rôle de cette interface consiste en
l’alimentation du référentiel des compétences par les nouvelles compétences acquises
par les participants aux formations réalisées par l’ADII.
Conclusion
Dans ce chapitre nous avons présenté la dernière phase du cycle de développement du
système de gestion de la formation. Cette phase a été décomposée en deux sous phases
principales : la réalisation et l’intégration du système dans le système d’information de
l’ADII.

Conclusion et Perspectives
Conclusion et Perspectives
Nous avons pu découvrir, à travers ce projet, une nouvelle approche qui facilite grandement le
développement d’applications web. En effet, l’intégration des frameworks dans le
développement d’applications réduit considérablement le coût de développement, grâce
notamment à leur qualité d’être paramétrable.
Notre travail a consisté, dans un premier temps, en l’étude et l’analyse de la politique de

formation continue dans l’ADII. Dans un second temps, nous avons modélisé le processus de
gestion de la formation qui est l’axe principal de cette politique de formation.
L’analyse des besoins des utilisateurs, la conception, la réalisation et l’intégration du système
de gestion de la formation dans le projet RIAD, ont été les phases du cycle de développement
de notre projet.
Au cours de la période de notre projet de fin d’études, nous avons eu l’opportunité de mettre
en application les différentes connaissances acquises durant notre formation à l’ENSIAS. De
plus, nous avons eu l’occasion d’acquérir de nouveaux concepts, à savoir : la technologie
J2EE, les Design Patterns ainsi que l’utilisation des frameworks Struts et TopLink.
Ce stage a été également l’occasion de découvrir le dynamisme et l’enthousiasme qui

caractérisent l’équipe RIAD. Les réunions régulières effectuées avec les encadrants à l’ADII
nous ont permis de mettre en œuvre les concepts de gestion de projets acquis à l’ENSIAS.
Les difficultés majeures que nous avons rencontrées durant ce projet résident essentiellement
dans la nouveauté du framework Open Source Struts, qui manque énormément de
documentation.
Enfin, nous précisons que la conception effectuée garantira l’extensibilité du système

développé et permettra à l’ADII d’ajouter d’autres services pour réponde aux futurs besoins.
Par exemple, le système peut être doté d’un outil aidant les décideurs de l’administration à
mieux appréhender et répondre aux besoins en formation.

Bibliographie
Bibliographie
Ouvrages
[CORCA01] Corine Cauvert et al. : Ingénierie des Systèmes d’Information. 2001
[BORUJA98] Grady Booch, James Rumbaugh, Ivar Jacobson : Le Guide de l’Utilisateur

UML. 1998.
[ROVA00] Pascal Roques, Frank Vallée : UML en Action. 2000
[LAI97] Michel LAI, UML la notation unifiée de modélisation objet, Édition InterEdition,
1997
[GAMMA95] E. Gamma et al., Design Patterns: Elements of Reusable Object Oriented
Software,Addison-Wesley Professional Computing Series. 1995.
[HUSTED03] Ted Husted et al. : Struts in Action. 2003
[SQLI03] Groupe SQLI : Maîtriser la persistance objet métier au sein d’une architecture
J2EE. 2003.
Adresses Internet
[wwwAPACHE] http://www.apache.org
Site de la fondation Apache pour le développement des logiciels Open Source
[wwwAS] http://www.application-servers.com
[wwwONJAVA] http://www.onjava.com
(Introduction to Jakarta Struts framework)
[wwwECKEL] http://www.mindview.net/Books/TIPatterns/; Bruce ECKEL (Thinking in
Patterns with Java)
[wwwLEA] http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html
D. Lea, Patterns Discussion FAQ.
[wwwTHOMAS] http://www.psgroup.com
A. THOMAS, Java 2 Platforme Entreprise Edition
[wwwIBM] http://www-106.ibm.com/developerworks/java/
(Manage complexity in large Web sites with this servlets and JSP framework)
[wwwMyCGI] http://www.mycgiserver.com

Bibliographie
(Développement Web Java avec Struts 1.0)
[wwwSTRUTS] http://jakarta.apache.org/struts/
Site du projet Open Source Struts
[wwwSUNJ2EE] http://Java.sun.com/J2EE
Simplified Guide to the J2EE, Sun Microsystems

Annexes
ANNEXES

Annexe1 : Plan Assurance Qualité
Annexe 1 : Plan d’Assurance Qualité

1. Objectifs du plan
Le présent Plan d’Assurance Qualité précise les éléments permettant de s'assurer de la mise en
œuvre et de l'efficacité des activités prévues dans le cadre du projet. Il expose notamment :
La description du projet ;
L’organisation du projet ;
Le planning détaillé du déroulement du projet ;
La liste des livrables ;
Les critères d’acceptation et contrôles qualité.
2. Description du projet
Afin d’assurer la polyvalence des agents et d’atténuer la vulnérabilité des structures
composants l’administration des douanes d’une part, et d’accompagner la politique de
redéploiement du personnel d’autre part, l’administration opte pour une politique de
régionalisation de la formation en se basant sur un méthode scientifique permettant d’extraire
les besoins en formation. Ces besoins sont répertories dans trois types de plans : plans
internes, plans régionaux et plan nationaux de formation.
Ainsi notre projet consiste à l’automatisation de ce processus tout en gérant les différentes
composantes de ce processus, à savoir :
La gestion des grilles de compétences qui nécessite à son tour la gestion
des opérations des structures.
La gestion ainsi que l’élaboration de tous les types de plan de formation.
La programmation des actions de formations retenues dans les plans de
formation
Elaboration du rapport d’évaluation
3. Rôles et responsabilités
L’organisation du projet est la suivante :
• Côté Administration du Douanes et Impôts Indirects :
Personne Rôle
Youssef EL MAZOURI
Mourad ZEKRAOUI
Mohamed LAHLOU Chef du service de la formation
Zouhair FADIL
Tableau 4 : Les participants au projet côté ADII
• Côté ENSIAS :
Personne Rôle
Bouchra BERRADA Professeur Encadrant
Abdellah SKAL Stagiaire élève ingénieur
Omar BEL LAKHDAR Stagiaire élève ingénieur
Tableau 5 : Les participants au projet côté ENSIAS

D’autre part, les comités qui seront constitués sont :
Le comité de pilotage : a pour mission de suivre la progression du projet

par rapport au planning déjà établi, de modifier le PAQ, de prendre,
proposer des décisions correctives ou mettre en place des ajustements. Ce
comité sera composé des personnes suivantes :
Personne
ENSIAS
Mme Bouchra BERRADA
ADII
Mr. Youssef EL MAZOURI
Mr. Mourad ZEKRAOUI
Mr. Mohamed LAHLOU
Mr. Zouhair FADIL
Tableau 6 : Membres du comité de pilotage
Le comité de projet : a pour mission de suivre de près l’avancement du

projet et de concevoir, développer et de déployer le projet. Ce comité aura
également pour rôle de préparer les réunions de pilotage et sera composé de
personnes suivantes :
Personne
ENSIAS
Abdellah SKAL
Omar BEL LAKHDAR
Tableau 7 : Membres du comité de projet
4. Organisation des Réunions

Chaque réunion sera verbalisée par un compte rendu synthétisant l’état d’avancement du
projet et tous les points et décisions prises. Ce compte rendu sera envoyé aux encadrants et
stagiaires concernés par le projet.
Périodicité : les réunions seront effectuées vers la fin de chaque phase du développement.
Objectifs :
• Définir les objectifs à réaliser pour prochaine phase ;
• Procéder à l’évaluation de l’état d’avancement pour chacune des ressources
ainsi que le niveau de réalisation des objectifs prédéfinis ;
• Identifier les problèmes rencontrés et apporter les solutions qui s’imposent ;
• Assurer la coordination des différentes structures et le suivi opérationnel du
projet ;
• Réajuster la planification en cas de nécessité.
5. Planning du projet
Dans ce qui suit, le planning détaillé du déroulement du projet.

Annexe 1 : Plan Assurance Qualité
Figure 35 : Planning détaillé du déroulement du projet

6. Plan de livrable
Afin d’assurer une bonne qualité du produit qui va être réalisé par ce projet, chaque phase du
projet va être jalonnée par un livrable comme il est indiqué ci-dessous :
Nom de la phase Livrable

Lancement Plan Assurance Qualité
Analyse des besoins Cahier des charges utilisateur
Cahier des charges fonctionnel
Conception Dossier de conception générale
Dossier de conception détaillée
Elaboration de la solution Implémentation et tests
Application de validation de Présentation + Rapport
l’approche.
Tableau 8 : Les livrables par phase

Annexe2 : Grille de compétences
Annexe 2 : Grille de Compétences
DANS L’ORGANISATION, EN DEBUT DE PERIODE OPERATIONS

Activités ET SAVOIRS-
OPERATIONS EXISTANTES FAIRE
SAVOIR-FAIRE EXISTANTS
NOUVEAUX
POLYVALENCE
DE GESTION A CREER
DE GESTION -SECURITE
DEVELOPPEMENT DANS LA FORMATIONS PERIODES
PERIODE INTERNES
ordonnancement
acquits a caution
Établissement et
gestion des actes
droits et taxes et
des mains levées
des déclarations
informatique de
PREVUES
Liquidation des
Prise en charge
reconnaissance
administrative
administrative
documentaire
Informatique
Décharge des
(évolution de
Bureautique
contentieux
Statistiques
en français
Validation
Rédaction
Rédaction
l'étude et l’organisation)
Partielles
en arabe
Étude
Acteurs
Forte
P1
■ ■ ■ ■ ■ ◪ ◪ ◪ ◪ ◪
Moyenne
P2
■ ◪ ◪ ◪ ■ ■ ◪ □ ■ ◪ O
Faible ♦ - Du
◪ ◪ ◪ □ ■ ◪ ◪ ◪ □ □
Liquidation des
Anglais 28/02/2000
droits et taxes et
P3 O ordonnancement au 03/03/2000
Faible ♦ - Du
□ ■ ■ □ ■ □ ◪ ◪ □ □
Etablissement et
Allemand 28/02/2000
gestion des actes
P4 contentieux
au 03/03/2000
O ♦ Liquidation des
- Du
06/03/2000
droits et taxes et au 10/03/2000
ordonnancements
Très ♦ - Du
■ ■ ◪
Etablissement et
___ ___ ___ ___ ___ ___ ___ faible 06/03/2000
gestion des actes
P5 contentieux au 10/03/2000
O ♦ Liquidation des
- Du
20/03/2000
droits et taxes et au 24/03/2000
ordonnancements
Forte Moyen Faible Très Nulle Forte Forte Forte Forte Très forte
ne forte
Vulnérabilité
■ Bonne connaissance théorique et pratique courante ou occasionnelle. □Connaissance des principes sans pratique.
◪ Connaissance des principes avec pratique occasionnelle ou bonne connaissance mais sans pratique. ━ Ni connaissance théorique ni pratique
Annexe3 : Processus « Y »
Annexe 3 : Processus Y
Le processus en « Y » est un processus de développement logiciel qui se caractérise par :
1- processus incrémental piloté par les risques

Définition d’incrément
Un incrément constitue un ensemble d’étapes de développement qui aboutit à la construction
de tout ou partie du système. Le contenu d’un incrément est porteur d’améliorations ou
d’évolutions du système et il peut être évalué par les utilisateurs.
Le processus de développement en « Y » se reproduit à différents niveaux d’avancement en se

terminant sur la livraison d’un nouvel incrément.
Il a été conçu pour gérer en priorité et en parallèle les risques de nature fonctionnelle et
technique :
- d’une part, les risques d’imprécision fonctionnelle, et d’inadéquation aux besoins
sur la branche gauche.
- d’autre part les risques d’incapacité d’intégrer les technologies, et d’inadéquation
technique sur la branche droite.
2- processus piloté par les exigences des utilisateurs

La majorité des risques proviennent de la non adéquation technique et fonctionnelle du
système aux besoins des utilisateurs. Les exigences des utilisateurs sont donc prioritairement
traitées dans les deux branche du processus en Y.
L’enjeu du processus en Y est donc de développer le point de vue utilisateur et de construire
la spécification puis la conception objet à partir des concepts maniés par les acteurs du
système.
3- Processus de modélisation avec UML

Il apparaît difficile d’envisager le processus 2TUP sans recourir à UML comme support. Le
processus en Y utilise UML dans toutes les phases par exemple : les cas d’utilisation et les
diagrammes de séquences dans la phase de spécification fonctionnelle, diagramme de classes
dans la phase de structuration…

Annexe 4 : Types de Design Patterns
1. Les modèles de création
On se trouve en programmation objet souvent confronté au problème d'évolution des classes.

Une classe hérite d'une autre classe pour en spécialiser certains éléments. On aimerait donc
qu'un objet puisse appartenir à telle ou telle classe (dans une même famille par héritage) sans
avoir à chercher la classe de gestion de ces objets et la ligne de code qui effectue
l'instanciation.
Fabrique de création
Une fabrique de création (ou factory) est une classe qui n'a pour rôle que de construire des
objets. Cette classe utilise des interfaces ou des classes abstraites pour masquer l'origine des
objets.
Singleton
Un singleton sert à contrôler le nombre d'instances d'une classe présent à un moment donné.
C'est souvent très pratique pour les classes sans état et effectuant toujours les mêmes
traitements.
Builder
Le Builder ou Monteur est une classe offrant des moyens de construction d'un objet. Il ne doit
pas être confondu avec la Fabrique. Le problème d'une Fabrique de création, c'est qu'elle ne
permet de définir comment un objet va être construit, certes, il est toujours possible de passer
plusieurs paramètres dans la méthode de création d'une fabrique mais cela s'avère souvent très
réducteurs voire délicat pour la maintenance.
2. Les modèles de structure
Ces modèles de conception tentent de composer des classes pour bâtir de nouvelles structures.
Ces structures servent avant tout à ne pas gérer différemment des groupes d'objets et des
objets uniques.
Adapter
L'Adapter ou Adapter est un moyen commode de faire fonctionner un objet avec une interface
qu'il ne possède pas. L'idée est de concevoir une classe supplémentaire qui se charge
d'implémenter la bonne interface (L'Adapter) et d'appeler les méthodes correspondantes dans
l'objet à utiliser (L'adapté).
Proxy

Assez proche de l'Adapter, le Proxy cherche à ajouter un niveau de redirection entre l'appel
d'une méthode d'un objet et l'action associée. A cet effet, on construit une nouvelle classe
implémentant l'interface de l'objet à manipuler et déportant toutes les actions sur un autre
objet implémentant la même interface. Ce type de structure vise à pouvoir changer l'objet
cible sans changer l'objet source (manipulé).
Les Proxy sont très utilisés pour la gestion d'objets distribués (protocole RMI en Java par
exemple). L'idée étant de construire des Proxy capable de communiquer avec des objets
distants (usage de la sérialisation en Java) sans que l'exploitant fasse de différences entre un
accès locale ou un accès distant.
Composite
Le modèle Composite cherche à éliminer toute différence entre un groupe d'objets et un objet.
Il s'agit d'une démarche récurrente valable pour tous les problèmes qui font émerger de
nouvelles structures par association.
3. Les modèles de comportement
Le modèle de comportement simplifie l'organisation d'exécution des objets. Typiquement, une

fonction est composée d'un ensemble d'actions qui parfois appartiennent à des domaines
différents de la classe d'implémentation. On aimerait donc pouvoir "déléguer" certains
traitements à d'autres classes. D'une manière générale, un modèle de comportement permet de
réduire la complexité de gestion d'un objet ou d'un ensemble d'objet.
Iterator
L'Itérateur ou Iterator est le plus connu des modèles de comportement. L'idée étant de limiter
la vision d'une collection par un utilisateur. Typiquement une collection contient un ensemble
d'objets stockés par différentes méthodes (un tableau, un vecteur...), l'exploitant qui accède au
contenu de la collection ne souhaite pas être concerné par cette manière de gérer les objets. La
collection offre donc un point d'accès unique sous la forme d'une interface Iterator.
Template
Un Template ou Patron de méthode est très utilisé dans la conception objet. Ce modèle utilise
simplement les mécanismes de surcharge pour déléguer à d'autres classes certaines parties
d'un algorithme. L'idée ressemble un peu au modèle Builder sauf qu'ici, il sert à construire un
traitement et non un objet.

Annexe 5 : TopLink
Annexe 5 : TopLink
1. Descripteur TopLink
Oracle 9iAS Toplink se base essentiellement sur les descripteurs qui lui permettent de stocker
les informations décrivant comment une instance d’objet peut être représenté dans la base de
données relationnelle
Parmi les informations nécessaires que contient un descripteur, on trouve :

1- La description des classes Java persistantes et les tables correspondantes
2- Une collection de mapping permettant la description de la façon avec laquelle les
attributs et les relations vont être stocker dans la base de données
3- Les informations sur la clé primaire des tables.
2. Quelques exemples de mapping

Exemple1 :
Soit l’exemple suivant :
Chaque « ClasseOperation » contient une ou plusieurs « Operation ». Au niveau

implémentation, dans la classe « ClasseOperation », il va y avoir une collection d’objet
« Operation ».
Le modèle relationnelle correspondant est comme suit :
Supposons qu’on veut récupérer les opérations d’une classe :

Annexe 5 : TopLink
Avec JDBC Avec framework TopLink

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); (*)ProjetToplink prjTop=new
String url = "jdbc:odbc:sourceDonnee"; ProjetToplink ();
Connection maconnection = DatabaseSession sessionTop =
DriverManager.getConnection(url); prjTop.createDatabaseSession();
Statement ps =maconnection.createStatement(); UnitOfWork unit =
sessionTop.acquireUnitOfWork();
sessionTop.login();
String query = ‘Select * from Operation, ExpressionBuilder builder = new

ClasseOperation where ExpressionBuilder();
Operation.idClasseOperation= Expression exp=
ClasseOperation.idClasseOperation And builder.get("idClasseOperation").equal(valeur);
Operation.idClasseOperation=valeur’
ClasseOperation classe =
ResultSet rs = null;
sessionTop.readObject(SavoirFaireExistant.class,
rs=stat.executeQuery(query);
exp);
Collection operations=classe.getOperations() ;
(*) ProjetToplink c’est la classe java générer une fois le mapping est terminé
Exemple 2 :
Soit le modèle objet suivant :
Une opération peut être dans plusieurs organisations et l’activité de chaque organisation se
base sur un ensemble d’opérations.
Lors de l’implémentation de cette relation, on doit trouver une collection des opérations dans
la classe organisation et une autre collection d’organisation dans la classe opération.
Le modèle relationnel correspondant est :

Annexe 5 : TopLink
Supposons qu’on veut chercher les opérations d’une organisation donnée :
Avec JDBC Avec framework TopLink

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); (*)ProjetToplink prjTop=new
String url = "jdbc:odbc:sourceDonnee"; ProjetToplink ();
Connection maconnection = DatabaseSession sessionTop =
DriverManager.getConnection(url); prjTop.createDatabaseSession();
Statement ps =maconnection.createStatement(); UnitOfWork unit =
sessionTop.acquireUnitOfWork();
sessionTop.login();
String query = ‘Select * from Operation, ExpressionBuilder builder = new

Organisation, OperationOrganisation ExpressionBuilder();
where Expression exp=
Operation.idOperation= builder.get("idOrganisation").equal(valeur);
OperationOrganisation.idOperation And
OperationOrganisation.idOragnisation=
ClasseOperation classe =
Organisation. idOragnisation and sessionTop.readObject(SavoirFaireExistant.class,
Organisation.idOrganisation=valeur’ exp);
Collection operations=classe.getOperations() ;
ResultSet rs = null;
rs=stat.executeQuery(query);
3. Alternatives de persistance d’objets métier dans une architecture J2EE

Au sein de l’architecture J2EE, on retrouve la norme EJB, qui fait figure de standard
incontournable et exclusif pour la modélisation d’objets métier persistants, tel est bien le
discours tenu par Sun Microsystems.
Avec le recul et l’expérience accumulés depuis quelques années, d’autres normes co-existent
avec J2EE, et certaines se posent même comme potentiellement concurrentes à certaines de
ses fonctionnalités. C’est le cas notamment de JDO qui se pose comme une alternative
sérieuse au modèle EJB pour la persistance.
Dans le domaine de la persistance objet, des produits comme Oracle9iAS TopLink, Hybernate
et OJB ont été conçus de sorte qu’ils soient neutres par rapport au modèle d’architecture
applicative. De plus, ces alternatives se posent non pas uniquement comme approches
concurrentes à J2EE et au modèle EJB, mais également en tant que briques complémentaires
dans une architecture multi-tiers J2EE pouvant mettre en œuvre le modèle d’application EJB.
Dans ce qui suit, une étude comparative et objective est menée entre les trois alternatives
pour la persistance d’objets métier en architecture multi-tiers J2EE :
• la persistance de composants métier à travers le modèle EJB de J2EE ;
• la persistance d’objets métier à travers le modèle JDO ;
• la persistance d’objets métier à travers Oracle9iAS TopLink, l’un des outils
de mapping objet/relationnel les plus évolués disponibles sur le marché.

Annexe 5 : TopLink
Cette étude procède d’une évaluation méthodique, et s’appuie sur une grille de critères
détaillée qui regroupe en huit domaines les différents aspects de la problématique de
persistance objet:
1. Transparence de modélisation : La Flexibilité dans la modélisation permet de
modéliser le domaine métier le plus fidèlement possible ;
2. Support des sources de données pour la persistance : La capacité de prise en charge

des principaux SGBD du marché maximise le potentiel de l’outil ;
3. Capacités de modélisation et de projection : La richesse de modélisation apporte

souplesse de conception et simplicité de développement ;
4. Langage de requêtage objet : La puissance et la richesse du langage de requêtage

objet ;
5. Potentiel transactionnel : La prise en charge de fonctionnalités transactionnelles

sophistiquées ;
6. Cache objet et optimisations : La présence d’un cache objet distribué, favorise une
meilleure montée en charge des applications ;
7. Environnement de développement (IDE) : La simplicité de développement permet

des gains de productivité ;
8. Déploiement et intégration : La facilité de déploiement et d’intégration avec les

serveurs d’application J2EE, détermine le potentiel du modèle pour l’entreprise.
4. Etude comparative entre les mécanismes de persistance

4.1. Evaluation du modèle EJB
La norme EJB définit une architecture de composants transactionnels qui couvre largement le
spectre de la modélisation métier :
• les EJB session permettent de modéliser des processus métier ;
• les EJB orienté message (message-driven beans) permettent de modéliser
des processus asynchrones ;
• enfin, les EJB entité permettent de modéliser des entités métier persistantes.
La grille d’évaluation détaillée de la couverture fonctionnelle du modèle EJB en matière de

persistance est présentée le schéma ci-dessous :

Annexe 5 : TopLink
Modélisation 42%
Support des sources de données 75%
Mapping 55%
Langage de requêtage 25%
Potentiel transactionnel 80%
Cache objet & optimisations 60%
IDE 63%
Déploiement & intégration 88%
Figure 36 : Evaluation du modèle de persistance EJB
Ces résultats illustrent clairement les limitations du modèle EJB en termes de respect du
paradigme objet, avec des capacités de modélisation et de requêtage réduites. On note
également des capacités de projection (mapping) limitées, ainsi que des faiblesses au niveau
du cache objet et des optimisations proposées. Enfin, ce modèle est limité en termes de
déploiement à une architecture J2EE 4 tiers. En revanche, il bénéficie intrinsèquement d’un
haut niveau d’intégration dans l’architecture J2EE, de la disponibilité d’outils de
développement adaptés, et d’un potentiel transactionnel satisfaisant.
4.2. Evaluation de JDO

JDO est une spécification qui vise à définir un standard universel pour la persistance
transparente d’objets Java simples. Cette spécification constitue l’adaptation au langage Java
du standard de persistance transparente défini par l’ODMG (Object Database Management
Group), un consortium de fournisseurs de bases de données objet formé avant l’avènement de
Java, à l’époque où SmallTalk et C++ étaient les deux principaux langages orientés objet du
marché.
Le développement du standard JDO s’est produit parallèlement à l’élaboration des normes

EJB et J2C, et le groupe de travail JDO a toujours estimé qu’il était important de garder JDO
en ligne avec ces standards. Cependant, l’implémentation d’un modèle de persistance non-
intrusif, flexible et sophistiqué mais qui reste simple d’utilisation au sein des applications, a
été la considération primordiale qui a guidé l’élaboration de cette norme.
La grille d’évaluation détaillée de la couverture fonctionnelle du modèle JDO en matière de

persistance est présentée par le schéma ci-dessous :

Annexe 5 : TopLink
Modélisation 100%
Mapping 60%
IDE 50%
Figure 37 : Evaluation du modèle de persistance JDO
Les notes obtenues par le modèle JDO sur les capacités de modélisation et de requêtage
démontrent sa prise en charge complète du paradigme objet. On note également sa versatilité
en termes de support de sources de données et de déploiement, ainsi que sa facilité
d’intégration au sein d’une architecture J2EE. En revanche, les capacités de projection
(mapping) de ce modèle restent moyennes : l’explication vient d’une part du support limité
pour les relations d’association (pas de support de relations bi-directionnelles et de gestion de
l’intégrité référentielle avec la prise en charge des suppressions en cascade), et d’autre part du
faible niveau de compatibilité entre implémentations (mapping non-standardisé). Enfin, les
implémentations JDO sont des produits encore jeunes. Bien que les produits disponibles
intègrent un cache objet transactionnel sophistiqué, les possibilités de paramétrage et
d’optimisation restent limitées.
4.3. Evaluation de La solution « Oracle9iAS TopLink »

Oracle9iAS TopLink est un produit éprouvé en matière de persistance de modèles objets
complexes en base relationnelle. Très complète, la solution Oracle9iAS TopLink est
constituée de plusieurs briques.
Oracle9iAS TopLink adopte une approche non-intrusive pour l’implémentation de la

persistance objet, et permet une approche de modélisation à granularité fine utilisant les
paradigmes de la conception objet : héritage, composition, et polymorphisme.
La logique de persistance est entièrement découplée de la logique métier et de la logique

applicative. Aucun ajout de code spécifique à la persistance n’est requis, et contrairement à
JDO, Oracle9iAS TopLink n’a pas recours à un mécanisme de post-traitement du code des
objets métier pour l’implémentation des mécanismes de persistance. Les seules informations
nécessaires à Oracle9iAS TopLink pour l’implémentation de la logique de persistance sont
les mappings des attributs objet sur le support de persistance (Dans la pratique très
majoritairement des bases de données relationnelles), qui sont stockés dans des descripteurs
XML.
La grille d’évaluation détaillée de la couverture fonctionnelle du modèle Oracle9iAS TopLink

en matière de persistance est présentée par le schéma ci-dessous :

Annexe 5 : TopLink
Modélisation 100%
Mapping 90%
IDE 88%
Figure 38 : Evaluation du modèle de persistance Oracle9iAS TopLink
Le modèle Oracle9iAS TopLink excelle dans la plupart des domaines. On notera tout
particulièrement ses possibilités étendues en matière de requêtage objet, ses capacités de
mapping exhaustives, et un potentiel transactionnel remarquable. D’autre part, Oracle9iAS
TopLink inclut un cache objet transactionnel de haut niveau, qui offre des possibilités de
paramétrage étendues et intègre de nombreuses optimisations pour l’amélioration des
performances (optimisations au niveau de l’exécution des requêtes notamment). Enfin, ce
modèle, facilement intégrable au sein d’une architecture J2EE, offre une grande versatilité
pour le déploiement. Seuls points perfectibles, la richesse de l’IDE et le support des sources
de données. Durant les phases de développement, un environnement de test pour les objets
persistants serait un plus. D’autre part, la prise en charge des bases de données objet et des
sources de données J2C serait également appréciable.

Rapport GesFormJ2ee

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport GesFormJ2ee

Uploaded by

Copyright:

Available Formats

Projet de Fin d’Etudes

Pour l’Obtention du Titre

d’Ingénieur d’Etat en Informatique

Option : Génie logiciel

Etude et mise en œuvre d’une solution pour la gestion de la

Réalisé par : Sous la direction de :

Année Universitaire 2003/2004

A mes très chers parents,

A mes chères sœurs et frères,

A tous mes chers amis du Maroc et de la France,

A tous ceux qui m’aiment.

A mes très chers parents,

A mes chères sœurs,

A tous mes chers amis de Kelaa,

A tous ceux qui m’aiment.

Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès

Ainsi, nous exprimons notre profonde gratitude et tenons à remercier tout

Nous tenons à exprimer nos gratitudes à M. Youssef EL MAZOURI, notre

Nos remerciements les plus sincères vont à Mme. Bouchra BERRADA,

Nos remerciements s’adressent également à M. Abdelhamid EL

Que messieurs les membres de jury trouvent ici l’expression de nos

Notre mission a consisté en l’étude du processus de gestion de la

Quant à l’aspect technique, l’utilisation du framework Struts a facilité la

Ce rapport comporte trois parties. La première partie définit le contexte

PARTIE I : CONTEXTE GENERAL DU PROJET

Chapitre2 : Présentation du projet ---------------------------------------------- 10

PARTIE II : ANALYSE ET CONCEPTION DU PROJET

PARTIE III : MISE EN ŒUVRE DU PROJET

Chapitre6 : Mise en œuvre de la solution et intégration dans RIAD ----- 56

Conclusion et Perspectives -------------------------------------------------------- 62

Liste des abréviations

Projet de Fin d’Etudes / ENSIAS 2004 i

Liste des figures

Projet de Fin d’Etudes / ENSIAS 2004 ii

Listes des tableaux

Projet de Fin d’Etudes / ENSIAS 2004 iii

Les organismes conscients de l’importance de la formation continue comme étant un pilier de

Dans ce sens et conformément à sa stratégie de veille technologique et économique, l’ADII a

Projet de Fin d’Etudes / ENSIAS 2004 4

Projet de Fin d’Etudes / ENSIAS 2004 5

PARTIE 1 : CONTEXTE GENERAL DU PROJET

Cette partie comprend deux chapitres :

Le premier chapitre introduit l’organisme d’accueil, ses

Le deuxième chapitre présente le sujet du projet et traite les

Projet de Fin d’Etudes / ENSIAS 2004 6

Chapitre1 : Présentation de l’organisme d’accueil

Dans ce chapitre nous présentons l’organisme

1. Activités principales de l’ADII

 La protection de l’économie nationale

Projet de Fin d’Etudes / ENSIAS 2004 7

Directions Division de Directions

Services Brigade Recette Ordonnancements

Figure 1 : Organigramme de l’ADII

Projet de Fin d’Etudes / ENSIAS 2004 8

La division de la programmation et de la communication est sous l’autorité de la direction des

2.3. Infrastructure technique du projet RIAD

Projet de Fin d’Etudes / ENSIAS 2004 9

Chapitre2 : Présentation du projet

Dans ce chapitre, nous décrivons la politique de

1. Politique de la formation continue

La formation de base vise à doter le stagiaire de connaissances générales, théoriques et

La politique de formation continue de l’ADII vise à atteindre les objectifs suivants :

Projet de Fin d’Etudes / ENSIAS 2004 10

Afin d’atteindre ces objectifs, l’ADII a engagé une politique de déconcentration et de

La protection de l’économie nationale