Laceramic Virtual University

Dédicace
Je dédie ce travail
A
Mes chers parents
Pour tout le bonheur qu’ils m’apportent, pour leur soutien moral, matériel et affectif.
Pour leur encouragement durant mes études et tout au long de la réalisation de ce
travail. Qu’ils trouvent dans ce travail le fruit de leurs sacrifices consentis pour mon
éducation et l’expression de mon amour et ma gratitude pour tout leur encouragement
qui m’a toujours poussé vers l’avant. Que Dieu le tout puissant leur protège et leur
procure santé et longue vie.
A
Mes sœurs
Je leur souhaite tout le succès et le bonheur du monde.
A
Tous les membres de ma famille, pour les encouragements et les conseils qu’ils n’ont
cessé de me prodiguer, plus spécialement mes chères Ines Maalej, Mouna Mallouli et son
mari Sabeur, Pour leur patience, leur confiance et leur affection.
Qu’ils trouvent avec ce travail l’expression de ma sincère gratitude et de mon affection.
A
Tous mes ami(e)s, notemment Zyed Triki, Ayoub Zayeti et Aladdin El Gharbi.
A
Ma chère amie Chikhrouhou Monia.
Rim
Dédicace
Je me permet d’exprimer ma plus profonde reconnaissance à :
Mon père Ahmed : Qui n’a jamais cessé de me soutenir, m’assister et m’encourager
depuis mes premiers jours du primaire jusqu’aujourd’hui. A celui qui a sacrifié ses
belles années pour embellir les miennes.
Ma mère Majda : Qu’aucune expression de gratitude ne suffisait pour témoigner de

l’étendue des sentiments que j’éprouve à son égard, pour sa bienveillance même
avant que je vit la lumière et pour son affection et son amour avec lesquels elle m’a
comblé. A celle que je sacrifierai mon âme pour regarder son sourire celeste.
Mes sœurs Sara et Maroua : Que personne ne peut égaler leurs places dans mon
cœur, pour les magnifiques moments passés ensemble. Je leur souhaite une belle vie
et qu’Allah les protège.
Ma fiancée Yosr : Pour ses encouragements et son support durant la période du

stage. Je lui souhaite la réussite dans ses études et dans sa vie entière.
Lina : La perle qui ne cesse pas de sèmer la joie et la gaı̈té dans la maison. Qu’Allah la
garde pour ses parents.
A toute la famille et tous mes amis, qui m’ont toujours poussé vers la réussite, qu’Allah
leur offre le bonheur et nous rassemble dans ses paradis.
Akram
Remerciements
Qu’il nous soit permis de remercier les membres du jury, pour l’honneur qu’ils me font
de juger ce modeste travail.
Nos vifs remerciements s’adressent à Monsieur Walid Sadfi pour l’honneur qu’il nous
fait en acceptant d’encadrer notre projet de fin d’études. Votre haute compétence, votre
dynamisme, votre amour de métier et de vos étudiants, et votre sens de l’humain qu’on a
tant admiré, sont pour vous le meilleur guide. Vous êtes pour nous le maı̂tre dont je suis
fier d’être l’élève.
Nous présentons nos remerciements les plus sincères à tout le corps enseignant de
l’Ecole Nationale des Sciences de l’Informatique auxquels nous devons nos instructions.
Au terme de ce travail, nous présentons notamment notre profonde gratitude à Mon-

sieur Hakim Harzallah, Directeur de développement du Groupe Laceramic SA, pour sa
bienveillance de nous avoir accueilli au sein de la société, pour la confiance qu’il nous a
accordé, pour son assistance et son suivi.
Nous citons en particulier nos encadreurs professionnels Messieurs Sofiène Bchir et Bilel
El Ghali dont l’aide et l’encouragement continu nous ont permis de défier les entraves et
de travailler avec acharnement. Nous espérons être à la hauteur de leur confiance. Qu’ils
trouvent dans ce travail l’expression de notre profonde gratitude.
Nous remercions spécialement tous ceux qui ont croisé pour quelques temps notre
route au sein de LACERAMIC, nous pensons notamment à l’équipe des stagiaires qui ont
animé ces quatre mois de travail, notamment notre collègue Hsis Mos’ab.
Enfin, nous exprimons notre sympathie à toutes les personnes qui ont contribuées de
près ou de loin au bon déroulement de ce travail.
Table des matières
Introduction 1
1 Présentation générale 3
1.1 Présentation de Laceramic S.A . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Activités principales de Laceramic . . . . . . . . . . . . . . . . . . 3
1.1.2 Dispersion géographique du groupe LACERAMIC . . . . . . . . . . 4
1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Etat de l’art 9
2.1 Le E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Généralités sur le E-Learning . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Processus du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Situation du E-Learning en Tunisie . . . . . . . . . . . . . . . . . . 12
2.2 Les outils du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Les outils de gestion des formations (LMS) . . . . . . . . . . . . . . 14
2.2.2 Les outils de gestion des contenus de formation (LCMS) . . . . . . 18
3 Analyse et spécification des besoins 23
3.1 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Quelques méthodes agiles de développement . . . . . . . . . . . . . 24
3.1.2 Méthodologie retenue . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Standard UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

viii TABLE DES MATIÈRES
3.3 Définition des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Analyse des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 27
3.6 Les diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 28
3.6.1 Cas d’utilisation de l’apprenant . . . . . . . . . . . . . . . . . . . . 28
3.6.2 Cas d’utilisation de l’adminstrateur . . . . . . . . . . . . . . . . . . 30
3.7 Plan de navigation de la plateforme . . . . . . . . . . . . . . . . . . . . . . 30
3.8 Les diagrammes d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1 Espace de collaboration . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.2 Gestion des supports de formation . . . . . . . . . . . . . . . . . . 33
4 Conception 35
4.1 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Architecture multi-tiers . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.3 Conception de la base de données . . . . . . . . . . . . . . . . . . . 45
5 Réalisation 49
5.1 Environnement logiciel du travail . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.1 Côté apprenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.2 Côté administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Conclusion et perspectives 60
TABLE DES MATIÈRES ix
Netographie 65
Glossaire 66
A Le standard J2EE 66
B Le framework JSF 71
C DAO et Hibernate 73
Table des figures
1.1 Dispersion géographique du groupe LACERAMIC . . . . . . . . . . . . . . 4
2.1 Processus du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Comparaison des LMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Comparaison des fonctionnalités des CMS . . . . . . . . . . . . . . . . . . 21
3.1 Le processus XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Cas d’utilisation d’un apprenant . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Plan de navigation de la plateforme . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Espace de collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Gestion des supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Diagramme de paquetages de l’application . . . . . . . . . . . . . . . . . . 37
4.3 Evaluation des acquis des apprenants . . . . . . . . . . . . . . . . . . . . . 39
4.4 Suppresion de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Suivi des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Diagramme de classes du paquetage Utilisateurs . . . . . . . . . . . . . . . 43
4.7 Diagramme de classes du paquetage Formations . . . . . . . . . . . . . . . 43
4.8 Diagramme de classes du paquetage Evaluation . . . . . . . . . . . . . . . 44
4.9 Diagramme de classes du paquetage Collaboration . . . . . . . . . . . . . . 45

xii TABLE DES FIGURES
4.10 Schéma conceptuel de la base de données . . . . . . . . . . . . . . . . . . . 46
4.11 Conception de la base de données du forum . . . . . . . . . . . . . . . . . 47
5.1 Architecture du framework JSF . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Position d’Hibernate dans une application web . . . . . . . . . . . . . . . . 51
5.3 Les modules réalisés de la plateforme . . . . . . . . . . . . . . . . . . . . . 52
5.4 Authentification des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Accueil d’un apprenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6 Livre interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.7 Evaluation par QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.8 Participation au forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.9 Accueil de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.10 Gestion des modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.11 Ajout d’un support de formation . . . . . . . . . . . . . . . . . . . . . . . 60
5.12 Ajouter un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.13 Chronogramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1 Architecture N-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Introduction
D e nos jours, le monde vit une situation économique de criticité indéniable. En effet les
mutations inéluctables de l’industrie mondiale mettent les entreprises devant le problème
de l’inadéquation de ses employés avec leur environnement économique, chose qui les
empêche d’évoluer dans le rythme international.
Maı̂triser et non subir ces changements est alors un enjeu qui est hors question de le
perdre. Pour cela la majorité des établissements dans le monde a concentré plein d’effort
autour de son maı̂tre d’œuvre qui n’est personne autre que l’employé puisque développer
son sens créatif, sa capacité à apprendre et à évoluer et maintenir ses compétences sont
devenus vitaux pour accroı̂tre l’agilité et la flexibilité de l’entreprise.
En Tunisie, la formation professionnelle continue est organisée par le code de travail

(article 339) et qui la considère comme service comprenant l’acquisition d’éléments essen-
tiels de culture générale et celle d’une technique professionnelle, théorique et pratique, le
perfectionnement professionnel, le reclassement professionnel et la formation profession-
nelle accélérée.
La compétitivité est encore plus d’actualité et le temps de travail reste fixe alors que
le besoin en formation augmente ce qui ne favorise pas la productivité recherchée. En
effet partir en formation nécessite le regroupement d’un nombre maximal d’apprenants
avec le formateur dans une période convenable à tout le monde, d’où la difficulté de la
planification. Comme le temps, c’est l’argent , les sociétés se trouvent dans une course
contre la montre et avec des budgets sans cesse optimisés.
Avec leur apparition, les technologies de l’information et de la communication

représentaient l’arche de Noé pour les entreprises. En effet, que ce soit via Internet ou
l’intranet, les moyens de formation, d’apprentissage, d’accompagnement et d’informations
2 INTRODUCTION
se développent ; faits principalement liés au gain de temps et à l’augmentation du public

touché.
C’est ainsi que le concept de la formation à distance a vu le jour. Néanmoins, la e-

formation n’est pas un luxe qui peut attendre l’arrivée des jours meilleurs de l’économie,
bien au contraire, elle fait partie intégrante du processus susceptible de conduire à ces
jours.
C’est dans ce contexte que s’intègre notre travail et qui consistait à la conception et la
réalisation d’une plateforme de formation à distance au sein de LACERAMIC S.A qui a
inclus l’E-Learning dans sa stratégie pour faire face aux défis du marché et aux nouvelles
circonstances qui viennent de s’imposer.
Le présent document est un rapport descriptif synthétisant tout le travail que nous
avons effectué dans cette perspective. Il est organisé en chapitres comme suit :
– Le premier donne une présentation générale du projet : l’organisme d’accueil ainsi
que les objectifs à atteindre.
– Dans le second, nous exposons l’état de l’art du domaine du E-Learning afin de bien
se mettre dans le contexte.
– Le troisième chapitre intitulé ” Analyse et spécification des besoins ” présente les
différents besoins fonctionnels et non fonctionnels que doit satisfaire l’application à
réaliser.
– La conception générale et la conception détaillée font ensuite l’objet du quatrième
chapitre.
– Le dernier chapitre décrit les tâches accomplies durant le stage en titre de réalisation.
Enfin nous donnons une conclusion récapitulant le travail réalisé ainsi que des pers-
pectives futures.
Le rapport est muni aussi de quelques annexes représentant les détails techniques de
la conception et de la réalisation ainsi que quelques concepts théoriques indispensables
pour la bonne compréhension du rapport.
CHAPITRE
1 Présentation générale
Ce chapitre a pour objectif de situer notre projet dans son contexte général à savoir
l’organisme d’accueil et le sujet à traiter. Dans la première section nous donnons une brève
présentation de l’organisme d’accueil ’LACERAMIC S.A’. Dans la deuxième section, nous
décrivons le sujet à traiter et les objectifs à atteindre.
1.1 Présentation de Laceramic S.A
Pour bien se mettre dans le contexte du stage, nous avons jugé nécessaire de présenter
l’organisme qui nous a accueilli en mettant en relief ses activités diverses et l’étendu
géographique de ses sites en Tunisie.
1.1.1 Activités principales de Laceramic
Fondée en 1931, ”La Céramique Tunisienne”, c’est ainsi que la société s’appelait ini-
tialement, a été rebaptisée LACERAMIC après son rachat par le groupe éponyme.
LACERAMIC, signifiant un groupe et un label, a profité de sa privatisation pour re-

vendiquer le titre d’entreprises pionnières et innovatrices dans leurs domaines : les produits
rouges, réfractaires et les carreaux de faı̈ence. LACERAMIC vient, ces dernières années,
de diversifier ses activités pour toucher d’autres secteurs afin de continuer et accentuer sa
participation dans la construction de la Tunisie en prenant en charge les secteurs dont le
pays a le plus besoin. C’est ainsi que le groupe LACERAMIC a créé MAS, (Mediterranean
Air Service) l’opérateur aérien spécialisé en matière de frêt aérien. C’est dans ce contexte
qu’il a également mis sur pied MEDSOFT, une société de service et d’ingénierie informa-
tique dont le champ de compétences est l’étude technique et le conseil en informatique.
4 CHAPITRE 1. PRÉSENTATION GÉNÉRALE
LACERAMIC s’est aussi intéressée à la finance avec la création de MEDINVEST, une

société à capital risque.
1.1.2 Dispersion géographique du groupe LACERAMIC
Le groupe touche un effectif d’un millier de personnes entre cadres, ingénieurs, tech-
niciens, agents techniques, agents de maı̂trise et ouvriers, travaillant dans les divers sites
de produits rouges et de carreaux de faı̈ences situés à Fouchana, Jendouba, El Hamma,
Kasserine, Bizerte et à Tajerouine comme le montre la figure 1.1.
Figure 1.1 — Dispersion géographique du groupe LACERAMIC

1.2. PRÉSENTATION DU SUJET 5
1.2 Présentation du sujet
Une étude de cas a révélé l’obligation de certaines formations pour les différents agents
de LACERAMIC. D’où le besoin à un parcours professionnel avec des formations obliga-
toires dans le cadre d’une Validation des Acquis Professionnels (VAP) afin de permettre
aux agents de partir en formation malgré un manque de personnel, d’où la favorisation
du remplacement de la stratégie de formation.
Vu la richesse de son système d’information et sa volonté d’amélioration, LACERAMIC

a opté pour la réalisation de sa propre plate-forme de formation à distance. C’est ainsi
qu’elle pourra dépasser les obstacles posés par la formation professionnel classique dont
les principaux sont :
– Le manque de disponibilité du personnel.

– La dispersion géographique des différents sites du groupe.
– Le coût important de la planification et d’exécution.
La solution est donc de diversifier le système d’apprentissage en développant l’utili-

sation des nouvelles technologies. Il s’agit surtout de mettre en place une solution qui
accompagnera les apprenants dans le nouveau dispositif de formation et qui vise à at-
teindre les objectifs suivants :
– Libérer les professionnels intervenant dans la formation.
– Toucher une tranche de population plus large.
– Evaluer les connaissances et les aptitudes de chacun dans la maı̂trise des différents
applicatifs de l’entreprise.
– Mettre à jour les contenus et méthodes afin d’optimiser l’impact de la formation sur
les apprenants.
– Permettre une individualisation de la formation.
– Développer l’autonomie des apprenants, tout en offrant une grande souplesse : le
E-Learning laisse le choix aux apprenants quant au moment et au lieux auxquels ils
désirent se former.
– Permettre la formation juste à temps : les employés changent fréquemment d’em-
plois, de postes, de projets et les informations deviennent obsolètes de plus en plus
rapidement. Avec le E-Learning, l’employé peut consulter le cours(ou la partie du
cours) juste avant d’accomplir la tâche voulue ou avant de résoudre un problème.
6 CHAPITRE 1. PRÉSENTATION GÉNÉRALE
– Assurer un suivi et un contrôle de la formation plus efficacement.

– Accélérer l’apprentissage : permettre de former rapidement une multitude de per-
sonnes (employés, clients, partenaires) réparties dans des lieux différents.
– Créer des espaces de communication et de collaboration ( forums et mails).
1.2. PRÉSENTATION DU SUJET 7
Pour chacune des formations, les niveaux de compétence visent à attribuer aux appre-
nants une des qualifications suivantes :
– sensibilisation : avoir des notions sur des concepts choisis.

– familiarisation : appliquer les bases des concepts choisis dans des situations
connues.
– maı̂trise : avoir des connaissances approfondies et les appliquer dans des situations
connues mais complexes.
– expertise : appliquer l’ensemble des connaissances dans des situations nouvelles et
être capable d’analyser et d’évaluer ces situations
Conclusion
Dans ce premier chapitre nous avons pu situer le projet dans son cadre général en
présentant l’organisme d’accueil et les buts de l’application. Dans le chapitre suivant,
nous allons procéder à une étude détaillée des principaux concepts en relation avec notre
sujet.
CHAPITRE
2 Etat de l’art
Avant d’entamer l’élaboration de notre projet, nous avons jugé primordial de présenter
les objectifs généraux d’une telle application à partir de ses éléments moteurs, à savoir le
concept et les les outils communément utilisés dans l’E-Learning .
2.1 Le E-Learning
Le but de cette section est de s’initier à la notion du E-Learning. Pour cela, nous
commençons par définir ce concept et présenter ses principes. Ensuite, nous définissons le
processus de développement d’un système de formation à distance. Enfin, nous exposons
l’expérience tunisienne dans l’apprentissage à distance.
2.1.1 Généralités sur le E-Learning
Définition
La définition du E-Learning varie selon le plan de vision de ce concept. en effet deux

plans principaux ont contribuer à une définition.
Pédagogiquement, le E-Learning peut se définir comme un ensemble de méthodes de

formation permettant de suivre un programme de formation à distance en ayant recours
à Internet ou Intranet.
l’E-Learning, du point de vue informatique, est la mise en œuvre des outils multimédia
(son, image, vidéo) au sein d’un système réparti grâce aux supports de distribution de l’in-
10 CHAPITRE 2. ETAT DE L’ART
formation (PC, Internet, Intranet, Extranet . . .) pour permettre à l’apprenant d’accomplir

un ensemble de formation et aux responsables de gérer le contenu de la formation.
Les formes du E-Learning
L’E-Learning peut se présenter de trois façons :

– La formation asynchrone : méthode de formation s’appuyant sur la guise de
l’apprenant. Elle ne l’oblige pas à être connecté à une heure précise mais plutôt le
laisse le choix.
– La formation synchrone : permet plus d’interactivité entre les apprenants et les
responsables des formations grâce à la communication en temps réel entre eux.
– L’apprentissage mixte : c’est la combinaison entre les deux façons déjà évoquées.
Elle donne à l’apprenant une période limitée pour acquérir une formation tout en
offrant les outils nécessaires de collaboration en temps réel.
Principes du E-Learning
Le concept du E-Learning se base essentiellement sur trois principes :

– Utilisation des nouvelles technologies : le premier principe porte sur l’utilisation des
TIC 1 interactives et accessibles à un très large public.
– Organisation du contenu : le second principe concerne l’organisation du contenu
pédagogique. Ce contenu est découpé en modules de telle sorte que l’on puisse
construire des parcours d’apprentissage adaptés aux apprenants en fonction de leurs
connaissances de base, de leurs expériences, de leurs objectifs . . .Il s’agit de définir
des sous ensembles ou modules cohérents et de définir une progression logique (un
chemin d’apprentissage) d’un module à l’autre de telle sorte que les conditions sui-
vantes soient satisfaites :
[-] Chaque module apporte à l’apprenant un ensemble de connaissances qui
viennent s’ajouter, de manière cohérente, aux connaissances acquises dans les mo-
dules précédents.
[-] L’assimilation du contenu de chaque module doit être évaluée par des tests
en fin de module. Ces tests seront proposés à l’apprenant sous forme de ques-
1. Technologies de l’Information et de la Communication

2.1. LE E-LEARNING 11
tions/réponses, de questionnaires à choix multiples, de problèmes à résoudre, de

simulation, d’études . . .
[-] Les pré-requis d’un module doivent être contenus dans le(s) module(s)
précédent(s) (sauf, bien entendu, pour le premier module du cours).
[-] La redondance de certains modules, dans leur contenu, permet à l’apprenant
de se rafraichir la mémoire et de revoir sous une autre forme ce qui n’a pas été bien
assimilé.
– La collaboration entre apprenants : par rapport à une formation classique, les ap-
prenants d’un cours dispensé par E-Learning ne sont plus physiquement rassemblés
dans un même local. Comme il est important de ne pas perdre la valeur ajouté
que représente la communication formelle et informelle entre les apprenants, les pla-
teformes de E-Learning fournissent des outils qui permettent de créer des classes
virtuelles ou des groupes d’apprenants vont pouvoir ” se rencontrer ”, échanger des
idées, confronter leurs expériences.
2.1.2 Processus du E-Learning
Le processus de développement des plateformes de formation à distance est

généralement décomposé en cinq phases principales qui sont organisées en boucles afin
de garantir une démarche itérative. En effet les différentes phases sont :
– L’analyse : elle constitue la base sur laquelle les objectifs et les fonctionnalités de
la plateforme seront éclaircis.
– La modélisation (Design) : c’est la phase dans laquelle les développeurs mettent
en place les spécifications des modules de formation, des dépendences entre eux ainsi
que des formats et des contenus des supports de formation.
– L’implémentation : c’est là où l’équipe de développement travaille sur la trans-
formation du modèle en un système fonctionnel. Cette phase doit alors produire des
métadonnées sur les formations, les supports et sur l’évaluation des connaissances.
– Le test et l’intégration : c’est la mise en œuvre de la totalité ou d’une partie du
système afin de le tester et de recueillir les remarques et les votes de ses utilisateurs
directs.
– L’évaluation et la maintenance : après avoir identifié les défauts du système
et ses sources de plantages éventuelles il est nécessaire de passer par une phase de
maintenance permettant de réparer et le rendre opérationnel.

Les différentes phases de ce processus sont décrites par la figure 2.1.
Figure 2.1 — Processus du E-Learning
2.1.3 Situation du E-Learning en Tunisie
Les principaux pays actuellement exportateurs de services de formation par Inter-

net sont les Etats-Unis, les pays européens, l’Australie et le Canada. Les réalisateurs au
Etats-Unis et au Canada sont énormes et diversifiés. En effet c’est vu l’importance qu’ils
l’accordent à ce nouveau mode d’éducation que nous assistons ces jours là à une croissance
vertigineuse du E-Learning . L’Australie et les pays européens investissent moins dans ce
secteur que les pays de l’Amérique de Nord, mais ils réagissent rapidement à l’évolution
de la formation ouverte et à distance. Ils y affectent des crédits importants et se dotent
des structures nécessaires pour le développement de ce secteur. Dans le cadre de la mo-
dernisation et de la mondialisation, les pays en cours de développement commencent bien
2.1. LE E-LEARNING 13
à s’incliner devant cette nouvelle méthode d’apprentissage virtuel. Seulement, certains

sont encore en phase d’hésitation car la transaction vers ce nouveau mode d’éducation est
délicate. En Tunisie, les initiatives dans le secteur professionnel et éducatif du E-Learning
ont débuté avec la création de ces trois principaux sites : l’école virtuelle Tunisienne,
l’école virtuelle de la poste tunisienne et l’université virtuelle de Tunis.
L’école virtuelle Tunisienne
Depuis le 28 janvier 2002, la phase expérimentale de l’école virtuelle tunisienne a

débuté. Cette école s’organise autour de trois axes : accompagnement et encadrement,
apprentissage de la langue arabe et formation aux TIC. L’école virtuelle constitue un
espace d’échange de ressources éducatives, d’expériences et d’idées et veut offrir l’oppor-
tunité de débattre dans le cadre de forums de discussion à propos de sujets divers.
L’école virtuelle de la poste tunisienne
L’école virtuelle de la poste tunisienne ouvre dans une première étape un ensemble de
cycle de formation à distance à l’intention des apprenants qui remplissent les conditions
de participation. Le déroulement de la formation effectue conformément aux étapes es-
sentielles suivantes (apprentissage, auto-évaluation, examen d’évaluation à distance, exa-
men final présentiel). Les cours de l’école virtuelle portent sur des thèmes à caractère
académique tel que la comptabilité, les finances, la gestion, l’économie, le droit, l’informa-
tique, les langues et les thèmes à caractère professionnel postal comme l’épargne postale
des chèques postaux, les nouveaux services.
L’université virtuelle de Tunis.
L’université virtuelle de Tunis(UVT) a démarré ses activités le 28 janvier 2002 en par-

tenariat avec les Instituts Supérieurs des Etudes Technologiques (ISET). L’enseignement
au sein de l’UVT est modulaire, il se fait, essentiellement, avec une dose en présentiel
de 20%. L’UVT se propose d’offrir différents types de formation ouverte et à distance
(FOAD)en utilisant les nouvelles technologies de l’information et de la communication :
– Formations initiales
– Formations spécialisés post-maı̂trise
– Formations courtes à vocation professionnelle

Cette expérience a débuté avec la plate-forme ACOLAD 2 , par la suite, à partir de
février 2004, elle a migré vers la plateforme INES 3 .
2.2 Les outils du E-Learning
Dans une plateforme typique d’apprentissage à distance, nous trouvons des outils de
gestion des formations (LMS=Learning Management System), des outils de création des
modules de cours (LCMS=Learning Content Management System) et des outils destinés
aux différentes formes de communication.
2.2.1 Les outils de gestion des formations (LMS)
L’appellation Learning Management System(LMS), en français ”plate-forme de

gestion de la formation” , désigne une solution logicielle axée sur l’intégration, la diffusion
et la gestion de contenu pour la formation à distance.
Les principales fonctionnalités d’un LMS sont :

– La gestion des apprenants : il s’agit de la principale fonctionnalité d’un LMS. Elle
permet aux responsables de la formation de définir, avec l’aide de l’administrateur,
les différents types de profils avec leurs droits associés. Elle administre l’inscription
et l’identification des apprenants aux formations, de façon individuelle ou groupée :
respect d’un circuit d’approbation prédéfini, prise en compte éventuelle des pré-
requis nécessaires pour suivre une formation. Certains LMS gèrent également la
notion de domaine , segmentant l’accès aux formations selon les profils des
apprenants et/ou les entités concernées.
– La conception des cours : les LMS intègrent le plus souvent des outils simples de
création de contenu, permettant la création de cours, d’exercices et d’évaluations, en
assemblant les différents supports pédagogiques créés par le concepteur (documents,
animations, multimédia). Il est possible de définir un scénario et une arborescence
2. Apprentissage COLLaboratif A Distance
3. Interactive E-Learning System
2.2. LES OUTILS DU E-LEARNING 15
de cours.
– le suivi des cursus de formation : les LMS permettent de suivre les temps consacrés à
la formation et aux exercices, ainsi que d’affecter des rôles aux différents apprenants.
Il est possible d’évaluer les performances des apprenants et de leur délivrer des
certifications si certaines conditions d’obtention sont remplies.
– le suivi et le bilan de la formation : les LMS intègrent des outils de reporting et
de statistiques permettant de suivre de façon synthétique, par apprenant ou groupe
d’apprenants, le temps passé en formation, les résultats obtenus, etc. Cela autorise
notamment le suivi et la gestion des coûts de formation.
Etude de quelques LMS
Il existe deux choix pour mettre en place une plateforme de E-Learning :

– soit choisir parmi les géants des LMS car ils sont riches et proposent des fonction-
nalités standards.
– soit déployer son propre LMS qui répond exactement aux besoins du client.
La solution LMS retenue doit pouvoir permettre le développement d’un contenu E-
Learning facile à utiliser et adaptable. Une personne sans connaissance technique parti-
culière doit être en mesure de développer du contenu E-Learning et de le mettre en ligne
sur la plate-forme pédagogique. Les critères fonctionnels à prendre en compte dans le
choix d’une plateforme LMS sont :
– Simplicité de l’installation et de l’utilisation : un LMS doit avoir une grande simpli-
cité pour qu’il soit jugé convenable à la mise en place d’une plate-forme d’appren-
tissage à distance.
– Adaptabilité : c’est la capacité d’un LMS de s’intégrer avec les éléments du système
d’information de l’entreprise.
– Modularité : un gestionnaire de formation modulaire est un système dont l’architec-
ture est développée en module, ce critère favorise alors l’extension de la plate-forme
en lui ajoutant d’autres modules.
– Scalabilité : c’est la caractéristique d’un système à évoluer en cas d’augmentation
du nombre d’utilisateurs et/ou de la taille son contenu.
– Respect des normes et des standards du E-Learning : pour faciliter les échanges
entre les différents systèmes d’apprentissage à distance, des normes sont mis en
place. Mais le problème réside au fait que les travaux de normalisation sont en cours
et donc les spécifications changent fréquemment.
– Ergonomie des vues : afin d’intensifier la motivation des apprenants ainsi que celle
des tuteurs, les LMS doivent avoir des interfaces interactives et ergonomiques.
Notre stratégie d’évaluation consistait à consulter la documentation de référence en
ligne ainsi que les comparatifs, les analyses et les retours d’expériences des experts. Nous
effectuerons une étude comparative de quatre LMS (Claroline, Dokeos, Ganesha, Moodle)
et qui vise l’identification des caractéristiques ergonomiques, techniques, pédagogiques qui
répondent au mieux à nos contraintes.
Claroline : est une plate-forme Open Source de formation à distance et de travail col-
laboratif. Elle permet aux formateurs de créer des espaces de cours en ligne et de
gérer des activités de formation sur Internet. Elle est simple à installer et à utiliser
grâce à la documentation riche et claire contenue dans le site officiel. Cependant,
elle a quelques points faibles comme l’espace très limité pour les documents et les
liens d’un groupe et l’ergonomie modeste de la messagerie instantannée. De plus, la
possibilité de créer plusieurs comptes avec le même e-mail et de créer des comptes
avec des adresses fausses existent. Ceci pose un problème de statistique quant au
nombre exacte d’utilisateurs. La création de parcours pédagogique est aussi un peu
rigide (difficultés de revenir en arrière suite à une erreur de création).
Dokeos : Dokeos est une plate-forme d’apprentissage à distance. D’une grande simpli-
cité de mise en oeuvre et très intuitive pour ses utilisateurs (professeurs, formateurs,
élèves, auditeurs de la formation continue, etc. . .). Dokeos propose de nombreux ou-
tils destinés à organiser les apprentissages et laisse toute latitude à la créativité du
développeur pour élaborer des cours réellement attractifs, interactifs et multimédias.
Ganesha : est un LMS présentant un ensemble d’outils à des fins pédagogiques. Cette
plateforme est développée à sources ouvertes en 2001 par la société Anema. Ganesha a
été la première plateforme de téléformation gratuite sous licence GNU GPL. Plusieurs
autres plateformes telle que AnaXagora ont été conçues en se basant sur Ganesha. Elle
intègre les standards d’E-Learning SCORM 1.2 4 , SCORM 2004, AICC 5 et LOM 6 .
Ces standards sont à la base de la construction des contenus, de l’insertion de ces
4. Sharable Content Object Reference Model
5. Aviation Industry CBT Committee
6. Learning Object Metadata
contenus dans un LMS et de la communication entre ces contenus et le LMS.
Moodle : Moodle est un LMS à code ouvert sous licence GNU GPL et développé par
Martin Dougiamas en 2003 permettant de créer des communautés d’apprenants au-
tour de contenus et d’activités pédagogiques. La modularité de Moodle lui permet
de s’adapter à toutes les structures. Un des points forts de Moodle c’est qu’il est
centré sur la classe devenue communauté d’apprenants qui doivent partager leurs
connaissances pour apprendre. Avec Moodle il est possible de créer et rassembler les
apprenants dans des groupes simulant ainsi des classes classiques.
Tableau comparatif
Le tableau 2.2 récapitule notre évaluation de ces différents LMS.
Figure 2.2 — Comparaison des LMS
Cette comparaison favorise l’adoption de l’un de Dokeos et Moodle. Or chacune de

ces solutions présente des points faibles qui nous ont mené à les écarter. En premier lieu,
Moodle présente les défauts suivants :
– Pas de création des chemins d’apprentissage.
– Pas d’outil de feedback pour la génération des rapports, fonctionnalité réquise pour
l’évaluation des apprenants.
– Incapacité de créer des contenus hiérarchiques.

En second lieu, Dokeos est éliminé pour les raisons suivantes :
– Orienté entreprise ne prenant pas suffisamment en compte les besoins spécifiques de
l’apprenant.
– N’offre pas de latitude dans le paramétrage de l’interface.
– Système lent ce qui pose des problèmes lors de la mise en ligne des cours.
– Sa prise en main n’est pas facile.
– La création des parcours pédagogiques est assez rigide.
– Sa prochaine orientation vers l’aspect commercial.
A la fin de cette étude nous avons choisi d’opter à développer notre propre gestionnaire
de formation qui s’adapte bien aux besoins de l’Université Virtuelle de LACERAMIC
(UVL).
2.2.2 Les outils de gestion des contenus de formation (LCMS)
Nous pouvons définir les outils de création de cours comme ceux qui offrent les fonc-
tionnalités nécessaires à l’assemblage en modules des pages de contenu et à la création du
cours à partir de ces modules. Nous y trouvons donc :
– Des facilités d’assemblage des pages en modules avec construction automatique de
la navigation à l’intérieur du module.
– Des aides à la création des différents types de tests (questionnaires à choix multiples,
tests, navigation à l’intérieur du module).
– Des outils permettant de construire plus ou moins facilement la logique de navigation
d’un module à l’autre en fonction de la filière de cours et des résultats aux tests de
fin de module.
Les LCMS sont principalement basés sur les systèmes de gestion de contenu (CMS)
qui ont pour but de simplifier la création et la gestion du contenu en ligne. Ils permettent
une meilleure fréquence des mises à jour des ressources déjà publiées et à moindre coût.
Cela repose sur le principe de séparation de la forme et du fond ainsi les auteurs doivent
pouvoir se concentrer uniquement sur leur contenu. Ils disposent pour ce faire de modèles
de présentation prédéfinis spécifiques à chaque élément qui compose le document (en-tête,
format du titre, emplacement d’une image, intégration d’un fichier multimédia etc.)[N1]
Etude de quelques CMS
Il y a énormément de choses à vérifier avant de choisir un CMS, mais en voici les plus
décisives :
Personnalisation du front office : elle consiste à créer la structure éditoriale et à

ajouter des modules fonctionnels spécifiques (sondages, annuaires, . . .).
Personnalisation graphique du front office : si ce critère est prépondérant, il est

strictement conseillé de choisir un CMS se basant sur l’architecture des templates
graphiques car elle détermine une part importante des coûts de maintenance et
d’évolution.
Multilinguisme : c’est la capacité du CMS à gérer plusieurs langues. Ce critère est le

premier à prendre en compte dans les projets internationaux.
Personnalisation du back office : c’est la finesse qu’offre le CMS au niveau de ges-

tion des droits utilisateurs et de personnalisation des workflows offerts par la solu-
tion. Certaines solutions obligent l’entreprise à s’adapter à leur logique et d’autres
lui laissent le choix et ce dans le cas des projets où le but n’est pas de publier les
informations seulement mais de les bien partager.
Flxibilité : c’est la capacité des gestionnaires de contenu à s’intégrer au système d’in-

formation déjà existant. Plus le projet est autonome des autres projets de l’entreprise
plus il sera facile de trouver des solutions répondant précisément aux besoins, notam-
ment parmi les CMS open source.
Capacité à monter en charge : la plupart des CMS proposent un système de cache

qui répond au problème en précalculant les pages et les stockant au format HTML.
Dans ce cas, les éléments à analyser sont l’architecture du cache et ses performances
réelles, via des tests de montée en charge par exemple. Dans le cas contraire, il faut
s’assurer qu’un système externe peut être ajouté sans difficultés.
Appropriation : en pratique, il s’agit de mesurer l’écart entre les habitudes des futurs
utilisateurs et les nouveaux processus. En fonction des cultures d’entreprise, ce critère
peut être le facteur clef de succès, la bonne ou la mauvaise volonté des utilisateurs
pouvant à elle seule faire avorter ou non le projet.
La pondération de ces critères dépend essentiellement de la nature du projet à réaliser.

Une expression du besoin très précise et une grande objectivité sont donc incontournables
à ce stade. Une étude de certaines solutions de gestion de contenu est alors nécessaire.
Pour cela nous avons choisi d’étudier de près trois CMS open source vu le coût de création
et le coût de possession qu’obligent des solutions payantes.
Corinis CCM : Corinis CCM est un système de gestion de contenu open-source basé
sur le langage Java. Il combine à la fois la puissance d’une solution professionnelle de
gestion de contenu (éditeur WYSIWIG, gestion de version, assurance de qualité basée
sur le rôle, . . .) avec facilité d’utilisation d’un framework communautaire. La concep-
tion modulaire du système encourage le développement d’extensions réutilisables
(comme le forum, le vote ou les modules d’album photo). Par ailleurs, le code Java et
l’utilisation de XML comme format de données garantissent l’interopérabilité. L’uti-
lisation de Corinis CCM dans un environnement Internet ou Intranet permettra de
réduire les coûts, les niveaux de compétence exigés et le temps requis pour sa mise
en place tout en s’assurant d’avoir un outil fiable et un développement ouvert de
plate-forme.
Alfresco CMS : Alfresco (Originellement Fresco - FRont-End for Sequence COmpari-

son mais ce nom a déjà été pris) est une référentielle open source pour la gestion de
contenu d’entreprise et des portlets (CMS). C’est un projet multiplateformes, utili-
sant des standards ouverts, et massivement basé sur la technologie J2EE. Alfresco a
développé une architecture moderne qui utilise les derniers outils open-source pour
optimiser les performances, et la Programmation Orienté Aspect (AOP) 7 facilitant
ainsi la modularité et l’adaptabilité de l’application. Il comprend la gestion de do-
cuments, la gestion de contenu Web, la collaboration, la gestion des enregistrement
ainsi que des images. Son architecture modulaire utilise les dernières technologies
Java open source : Spring, Hibernate, Lucene et JSF. Cet outil favorise de sa sim-
plicité pour atteindre sa mission : ”ouvrir le monde de la gestion de contenu afin
d’augmenter les innovations grâce à la participation de la communauté et au libre
accès au code source, et viser à fournir une application complète à moindre coût ”
dotCMS : dotCMS est un système open-source de gestion de contenu dédié aux entre-
prises qui intègre les meilleures fonctionnalités de gestion de contenu. Il permet de
créer des structures de données pour diverses entités et ainsi que des liens entre eux
pour faciliter la création de bases de données générées dynamiquement sous forme
7. Aspect-Oriented Programming
de données en cours de validation à l’aide de l’outil perl facile à modifier. En outre,

il permet de créer des conteneurs inclus dans des templates qui génèrent des pages.
On peut utiliser les macros rapides inclus dans les templates qui supportent Ajax à
travers XML-RPC, la pagination, la recherche, le diaporama et les fonctions gale-
rie. Entre autres macros disponibles dotCMS présente les galeries de photos, le MP3
Player Streaming, le dépôt de fichiers, l’exécution des requêtes SQL et beaucoup
d’autres macros.
Tableau comparatif Une étude comparative a été alors élaborée dans le but de faire le
bon choix. la figure 2.3 récapitule la comparaison effectuée. En premier lieu les choix
Figure 2.3 — Comparaison des fonctionnalités des CMS
de Corinis CCM et d’Alfresco CMS se sont écartés vu que le premier ne peut pas
intégrer la connexion au serveurs d’annuaire LDAP (qui est une fonctionnalité sur
laquelle l’authentification à la plateforme doit se baser) et que la richesse technolo-
gique et fonctionnelle de la deuxième induisent une légère compléxité d’utilisattion
pour les développeurs ainsi que pour les utilisateurs finaux. Enfin nous nous sommes
concentré sur l’étude de dotCMS qui consistituait une solution parfaite de gestion
de contenu. Cependant, le problème de dotCMS c’est qu’il requiert un accès com-
plet au serveur, car il nécessite l’installation personnalisée d’Apache Tomcat comme
serveur d’application , alors que la majorité des possesseurs de domaines internet
n’ont pas cet accès à leur serveur, ils ne possèdent que le domaine dans le nuage In-
ternet. D’autre part, tellement dotCMS est puissant dans sa manière d’architecturer
ses données et dans sa manière de considérer le contenu qu’il nécessite un serveur
de dernière génération au niveau des ressources matérielles, ce qui n’est encore pas
du ressort du grand public. Par ailleurs, le grand défaut de dotCMS reste sa do-
cumentation. En effet, la politique de dotMarketing (l’entreprise qui gère dotCMS)
est d’ailleurs très explicite sur ce point, en libérant le code source, mais en faisant
payer toute aide et support. Enfin comme tout autre CMS, dotCMS présente certains
inconvénients parmi lesquels nous citons :
– La structure en 3 colonnes immuables.
– La rigidité des thèmes (ou templates) téléchargeables gratuitement et qui
nécessitent de conserver un lien visible sur le site développeé vers le site de leur
concepteur, et la création de nouveaux thèmes même si elle est possible parfois elle
sera coûteuse.
– L’uniformité de la diffusion de l’information donne des sites semblables.
– Les CMS sont un peu des usines à gaz puisqu’ils cachent les détails concrêts de
réalisation.
– La scalabilité n’est pas toujours assurée.
– Les risques de sécurité venant du fait que tout le monde connaı̂t le code source du
site et peut engendrer d’éventuels risques de sécurité et des vulnérabilités.
– Les modules complémentaires, souvent développés par des tiers et mis à la disposi-
tion de la communauté des utilisateurs du CMS, peuvent être source d’instabilité
du site.
Conclusion
Dans ce chapitre nous avons pu dégager et étudier les différents concepts surlesquels se
base la FOAD. Le chapitre suivant aura pour but de décortiquer les besoins fonctionnels
et non fonctionnels que notre application doit satisfaire.
CHAPITRE
3 Analyse et spécification
des besoins
La réussite de tout projet dépend de la qualité de son départ. De ce fait, l’étape de

spécification constitue la base de départ de notre travail. En outre, l’adéquation de toute
l’application à réaliser, aux besoins des utilisateurs et aux traitements envisagés au niveau
de ses opérations assurera la réussite de l’application et son utilité future. Pour assurer
ces objectifs, il est essentiel que nous parvenions à une vue claire des différents besoins
escomptés de notre projet.
Dans ce chapitre, nous commençons par définir notre processus de développement ainsi
que standard de modélisation adopté. Nous détaillons ensuite les besoins fonctionnels et
non fonctionnels du système. Enfin, nous proposons quelque diagrammes expliquant les
aspects statiques et dynamiques de l’application.
3.1 Méthodologie de développement
Vu la diversité des méthodologies de conception et de développement, il était indis-

pensable de faire un choix judicieux afin d’assurer la bonne conduite du projet.
C’est dans ce contexte que s’inscrivent les méthodes agiles de développement visant à
réduire le cycle de vie en adoptant une approche itérative basé sur l’écoute continue du
client. Les méthodes agiles sont conçues pour s’adapter au changement, en assurant un
plan macroscopique précis et adaptatif.
24 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS
3.1.1 Quelques méthodes agiles de développement
Les méthodes agiles les plus connues sont :
RAD 1 : développement rapides d’applications.
DSDM 2 : développement des systèmes dynamiques.
RUP 3 : méthode de développement de processus unifié de Rational Software.
XP 4 : eXtreme Programming.
2TUP 5 : propose un cycle de développement en Y, qui dissocie les aspects techniques

des aspects fonctionnels.
3.1.2 Méthodologie retenue
Après une étude des différents processus de développement et de gestion de projets il

nous est apparu favorable d’adopter le modèle XP, et ce vu ses points forts suivants :
– Communication : la communication dans XP est un point central à tous les niveaux
(client-équipe, intra-équipe).
– Intégration continue : l’intégration continue permet de connaı̂tre l’état du logiciel
à tout moment, en compilant, lançant les tests unitaires et fonctionnels à chaque
commit de développeurs.
– Refactoring : le code doit être remanié de façon continue afin de le rendre plus
maintenable et d’améliorer sa qualité.
– Le travail en binôme : dans XP, le travail en binôme est la règle.
La figure 3.1 montre l’aspect itératif du modèle XP et la fréquence de chaque itération.

3.2. STANDARD UML 25
Figure 3.1 — Le processus XP
3.2 Standard UML
UML est un langage de modélisation unifié standardisé par l’OMG. C’est un langage
d’analyse et de conception orientée objet. Il couvre l’aspect statique et dynamique d’un
système selon ses différents diagrammes. Son but est de spécifier, visualiser, construire,
et documenter les systèmes informatiques. Pour cela, il définit des diagrammes qui sont
subdivisés en des vues statiques (qui représentent ”physiquement” le système à modéliser
au moyen de diagrammes d’objets, de classes, de cas d’utilisation, etc.) et des vues dyna-
miques (qui montrent le fonctionnement du système au moyen de diagrammes de séquence,

de communication, d’états transitions et d’activités). UML est purement un langage, Il
n’induit aucune méthodologie. Basé sur une démarche guidée par les besoins des utilisa-
teurs et centrée sur l’architecture logicielle, UML offre un environnement de conception
solide et efficace ainsi que des méthodes de représentation claires et concises. UML a
été réalisé pour matérialiser des stratégies et des heuristiques, bien comprendre et bien
répondre aux spécifications, analyser le risque, organiser le travail et concevoir des ar-
chitectures réutilisables extensibles efficaces. L’approche de la modélisation des besoins
par cas d’utilisation se prête très bien à un processus itératif de développement. Pour ces
avantages de UML, nous l’avons adopté comme langage de modélisation tout au long du
processus de développement.
3.3 Définition des acteurs du système
Cette application vise tous les employés de la société Laceramic, du simple ouvrier
jusqu’au cadre, dirigeant et directeur. Après avoir identifié les objectifs généraux de UVL
, nous avons pu dégager les acteurs qui vont interagir avec l’application. En effet ils sont
en nombre de deux à savoir : l’administrateur et les apprenants.
– L’administrateur : c’est le gérant du système qui a tous les privilèges et qui a la
responsabilité de la gestion des formations et de la mise en ligne des différents sup-
ports. Ce super utilisateur contribue en outre à l’enrichissement de la bibliothèque
virtuelle en déposant différents types de supports utiles pour les formations à court
et à long terme (articles, images, vidéos . . .) Par ailleurs, il est chargé de diriger les
utilisateurs à savoir la définition du cursus approprié à chaque membre.
– L’apprenant : c’est l’acteur principal sur lequel est basé tout le processus de for-
mation à distance. Il possède un espace privé depuis lequel il a accès aux diverses
activités d’apprentissage et aux ressources nécessaires qui lui permettent de mener
à bien sa formation.
3.4. ANALYSE DES BESOINS FONCTIONNELS 27
3.4 Analyse des besoins fonctionnels
L’analyse des besoins fonctionnels consiste à définir d’une manière complète les diverses
fonctions de l’application à réaliser, ainsi que les informations manipulées. Il s’agit de
traduire les besoins du client en fonctionnalités du système à concevoir.
Nous proposons dans ce travail de réaliser une plateforme E-Learning se reposant sur
trois axes complémentaires à savoir :
– La formation professionnelle continue des employés indépendamment de leur locali-

sation géographique.
– L’évaluation et le suivi du personnel de la société dans le but d’assurer une évolution
légale sur l’échelle fonctionnelle et donc une réponse à des besoins individuels
(carrière, employabilité, rémunération . . .). Pour ce faire un générateur de ques-
tions à choix multiples aléatoires doit être mis en place assurant une équitabilité
entre les différents candidats.
– La collaboration entre les différentes catégories d’utilisateurs par l’échange d’idées
et le partage du savoir faire afin de réduire l’isolement professionnel, encourager une
participation plus active entre eux et de développer un esprit critique et synthétique
stimulé par le dialogue entre agents venant d’horizons différents.
Les solutions du E-Learning doivent miser, en outre, sur l’interaction pour susciter
l’attention des participants tout en assurant leur fiabilité, leur pertinence, leur portabilité
ainsi que leur maintenabilité.
3.5 Analyse des besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les contraintes aux quelles est soumis le
système pour son bon fonctionnement.
Besoin de fiabilité et de performance : le système devra être opérationnel d’une

façon continue. En outre, il doit garantir un temps de réponse minimal : le site
devra se charger rapidement et chargement d’une page Web dans le navigateur ne
devrait pas dépasser 6 secondes en condition normale.
Besoin d’ergonomie des interfaces : l’interface de l’application doit être simple et

pratique afin que l’utilisateur puisse l’exploiter sans se référer à des connaissances
particulières. En d’autres termes, les informations doivent être lisibles et faciles à
accéder par n’importe quel utilisateur.
Besoin de sécurité : différents niveaux d’accès possibles au système pour les diverses
catégories d’utilisateurs du système. Ce besoin est assuré via une authentification.
Par ailleurs, le système doit garantir l’intégrité des données de la plateforme quels
que soientt leurs types.
Besoin de flexibilité et de l’évolutivité : le système doit s’adapter aux divers chan-

gements exigés par la société. Il doit être modulaire garantissant ainsi une évolutivité
de la future solution.
Besoin de portabilité : le système doit être multiplateforme, c’est à dire capable à

fonctionner facilement dans les différents environnements matériels et logiciels dans
le but de couvrir tous les ordinateurs des employés tenant compte de leurs diversités.
3.6 Les diagrammes des cas d’utilisation
Un cas d’utilisation permet de mettre en évidence les relations fonctionnelles entre

les acteurs et le système étudié. Il centre l’expression des exigences du système sur ses
utilisateurs. La détermination et la compréhension des besoins sont souvent difficiles car
les intervenants sont noyés sous de trop grandes quantités d’informations. Il faut clarifier
et organiser les besoins des clients (les modéliser). Pour cela, les cas d’utilisation identifient
les utilisateurs (acteurs) et leurs interactions avec le système.
3.6.1 Cas d’utilisation de l’apprenant
Au sein de la plateforme à réaliser, le cas d’utilisation attribué à l’apprenant est la

formation sur les différents composants du système d’information de LACERAMIC. Ce
cas d’utilisation représente l’ensemble des services mis à la disposition des utilisateurs à
savoir le recours aux différents supports de cours, des livres de la bibliothèque, l’évaluation
des acquis et encore la communication avec d’autres utilisateurs. Ce cas d’utilisation est
donné par la figure 3.2.
3.6. LES DIAGRAMMES DES CAS D’UTILISATION 29
Figure 3.2 — Cas d’utilisation d’un apprenant
L’apprenant peut à partir de la plateforme s’inscrire à des modules de formation, se

former en consultant les supports de formations recommandés et doit ensuite passer une
évaluation à travers un QCM de durée de réponse limitée. Ce QCM doit être générer
aléatoirement et sans reprise pour chaque utilisateur. Pour enrichir leurs connaissances,
le système offre à ses utilisateurs la possibilité de consulter une bibliothèque riche en
documents de tous les formats et de participer aux discussions du forum. Tous ces services
ne sont accessibles qu’après l’authentification de l’utilisateur.
3.6.2 Cas d’utilisation de l’adminstrateur
Afin de bien veiller sur le bon fonctionnement de la plateforme et son intégrité, celle-ci
nécessite un utilisateur ayant plus de privilèges pour la gérer correctement. Cet utilisateur
est nomé ”‘administrateur”’. La figure 3.3 montre les tâches dont l’administrateur en est
responsable.
Figure 3.3 — Cas d’utilisation de l’administrateur
3.7 Plan de navigation de la plateforme
La navigation dans la plateforme se fait comme l’indique la figure 3.4 :
3.8 Les diagrammes d’activité
Les diagrammes d’activité décrivent le comportement d’un système, tout en mettant

l’accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du
3.8. LES DIAGRAMMES D’ACTIVITÉ 31
Figure 3.4 — Plan de navigation de la plateforme
cheminement de flots de contrôle et de flots de données (les workflows). Ils permettent ainsi
de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas
d’utilisation. Par ailleurs, ils peuvent comporter des synchronisations pour représenter
les déroulements parallèles. La notion de couloir d’activité décrit les responsabilités en
répartissant les activités entre les différents acteurs opérationnels.
3.8.1 Espace de collaboration
La figure 3.5 représente le diagramme d’activité relatif à l’intégration de l’utilisateur

dans l’espace collaboratif offert par la plateforme. A travers cet espace l’apprenant a la
possiblité de consulter les différentes catégories du forum afin de poser des questions en
relation avec son cursus, s’informer auprès des responsables de quelques détails concernant
le déroulement des formations ou afin de répondre à des problèmatiques postées par
d’autres utilisateurs. La communication via le mail est aussi offerte par l’UVL. C’est ainsi
que les apprenants peuvent contacter l’administrateur du site pour des demandes privées
ou concernant leurs informations personnelles. Dans cet espace l’administrateur agit en
contrôllant les messages du forum, répondant à ceux qui le concernent et supprimant ceux
qui portent du vandalisme dans leurs contenus.
Figure 3.5 — Espace de collaboration

3.8. LES DIAGRAMMES D’ACTIVITÉ 33
3.8.2 Gestion des supports de formation
La figure 3.6 présente le diagramme d’activité relatif à la gestion des supports de

formations de la plate-forme. L’administrateur choisit l’opération, qui soit une suppression
soit un ajout, à effectuer sur un support en précisant la formation concernée et en insérant
les informations nécessaires.
Figure 3.6 — Gestion des supports

Conclusion
Dans cette partie, nous avons cerné les objectifs du système cible. Ces objectifs doivent
tenir comptes des exigences citées. Cette phase va nous permettre de bien élaborer le
modèle de conception de l’application qui sera le sujet du chapitre suivant.
CHAPITRE
4 Conception
Dans ce présent chapitre nous entamerons une partie cruciale du développement logiciel
et qui constitue un pont entre la spécification et la réalisation. Elle comporte la conception
de l’application ainsi que la conception de la base de données.
4.1 Conception générale
Dans cette section, nous donnerons un aperçu sur l’architecture globale de l’ap-
plication, ensuite nous allons explorer l’ensemble de composants de l’application à
réaliser. En fait, l’UVL est une plateforme qui se base essentiellement sur trois modules
complémentaires, à savoir, le module d’apprentissage, le module d’évaluation ainsi que le
module de collaboration.
4.1.1 Architecture multi-tiers
L’architecture multi-tier est mise en œuvre dans notre application afin de bien séparer
tous ses niveaux et nous offrir la possibilité d’utilisation des composants graphiques riches
pour le niveau présentation. Cette approche ne divise pas l’application en un nombre
indéterminé de niveaux de service comme le fait penser son appellation, mais plutôt elle
la décompose en trois couches de services subdivisées elles-même en multiple services.
36 CHAPITRE 4. CONCEPTION
L’architecture de notre application intégrant les framework JSF et Hibernate est

schématisée par la figure 4.1.
Figure 4.1 — Architecture de l’application
4.1.2 Diagramme de paquetages
La notion de paquetages (ou de packages) permet de séparer le modèle en conteneurs

logiques, et décrire leurs interactions à un haut niveau. Le diagramme de paquetages est
donc utilisé pour refléter l’organisation des paquetages et leurs éléments. La figure 4.2
montre cette organisation au sein de notre application.
4.1. CONCEPTION GÉNÉRALE 37
Figure 4.2 — Diagramme de paquetages de l’application
Le paquetage ”Utilisateurs” : les utilisateurs de la plate-forme sont, comme déjà

cité, l’administrateur et les apprenants. Ces derniers commencent le cycle de forma-
tion avec un nombre de points ” jetons ” initial et qu’ils les perdent en fonction de la
formation et le résultat de l’évaluation.Le but est donc de consommer tous les jetons.
Le paquetage”Formations” : les formations proposées sont en relation avec les di-

verses activités de la société comme le système d’information, l’administration, la
gestion. . .Ces formations sont organisées sous forme de cursus personnalisés. En effet,
cette personnalisation est basée sur plusieurs paramètres comme les postes remplis
par l’utilisateur, son poste actuel, son niveau éducatif, son expérience, son âge. . .
A chaque formation est attribué un nombre de jetons qui sera retiré de l’apprenant
lorsqu’il la passe avec succès. En plus, le temps alloué à une formation est prédéfini
afin d’encourager les apprenant à la prendre au sérieux. En cas de dépassement du
délai sans réussir la formation l’administrateur sera notifié et il peut intervenir soit
pour donner une autre chance à l’apprenant soit pour lui proposer un autre cursus
plus adapté à son profile.
Une formation est généralement décomposée en des sous formations afin de définir
des différents niveaux de compétences et pour rendre plus performant le suivi de
l’évolution de la formation.
Les apprenants ont besoin, sans doute, de supports de formation dans lesquels ils
trouvent toutes les informations nécessaires pour acquérir des compétences en premier
lieu, et pour réussir l’évaluation en second lieu. Dans l’UVL les utilisateurs peuvent
trouver l’information dans deux emplacements différents : au sein du module de
formation et dans la bibliothèque virtuelle mise pour la raison.
Le paquetage ”Evaluation” : ce module est basé sur les questionnaires à choix mul-
tiples (QCM) générés aléatoirement et sans reprise avec un temps de réponse bien
déterminé et à ne pas dépasser. La plateforme offre trois chances à l’apprenant de
passer un QCM pour la même formation.
Le paquetage ”Collaboration” : comme partager les connaissances ne fait que les

accroı̂tre, le module de collaboration de l’UVL offre un forum de discussion dans lequel
les utilisateurs peuvent faire des suggestions, demander de l’aide ou bien résoudre
des problèmes pour les autres formés. Ils peuvent aussi utiliser la plateforme pour la
communication par mails.
4.2 Conception détaillée
La conception détaillée vise à transformer le modèle d’analyse (spécification : haut

niveau d’abstraction) en un modèle concrêt, de bas niveau d’abstraction et à partir duquel
le programmeur peut directement implémenter le système.
4.2.1 Diagrammes de séquences
Un diagramme de séquence est une structure de représentation des interactions entre

objets comme une série d’étapes séquentielles dans le temps. Il est utilisé pour décrire
le flux de travail, le passage du message, et de quelle manière les éléments en général
coopèrent avec le temps pour obtenir un résultat. Dans ce qui suit nous allons détailler
les cas d’utilisation présenté dans le chapitre précédent.
4.2. CONCEPTION DÉTAILLÉE 39
Evaluation des acquis des apprenants
La figure 4.3 met en relief le déroulement de l’évaluation des apprenants. Le scénario

d’évaluation peut se déclencher du moment où l’utilisateur commence sa formation. Cette
dernière est caractérisée par une durée que l’utilisateur n’est pas obligé de tout consommer
et une fois épuisée, un échec lui sera accordé avec une notification à l’administrateur. Si
Figure 4.3 — Evaluation des acquis des apprenants
les délais sont bien respectés, un nouveau test se crée déclenchant un générateur de QCM
qui provoque la sélection de questions aléatoires et l’internaute est chargé d’y répondre
pendant une durée qui lui est permise. Le système vérifie alors la validité des réponses
et lui affiche le résultat et la correction. Deux cas de figures peuvent avoir lieu : soit un
échec causant la perte de jetons de l’utilisateur, soit un succès et le système met à jour le
score de l’apprenant et lui propose la formation suivante dans son cursus.
Suppresion de formation
Le diagramme de séquence présenté par la figure 4.4 explique comment doit procéder
un administrateur afin de supprimer une formation. Cette dernière peut être un module
ou un sous module. Notre acteur, ayant les permissions nécessaires pour accéder à l’admi-
nistration des modules doit sélectionner la formation à supprimer, le système lui demande
alors de confirmer sa demande.
Figure 4.4 — Suppresion de formation
Une fois effectuée, le système met à jour un par un les cursus des apprenants dont la
formation choisie en fait partie (et ceci en réglant les ordres respectifs des autres formations
avant de supprimer le module sélectionné du cursus). Les apprenants concernés seront alors
notifiés par ces changements. Par la suite le système se charge de supprimer la formation
sélectionnée tout en l’indiquant à l’administrateur.
Suivi des utilisateurs
Le diagramme de séquence illustré par la figure 4.5 résume le scénario de consulta-

tion des informations et le suivi des utilisateurs par l’administrateur qui commence par
rechercher les utilisateurs.
Figure 4.5 — Suivi des utilisateurs

L’espace d’administration sera sollicité par cette demande et l’action correspondante

sera invoquée. Cette action sera par la suite transmise à la couche Contrôle qui exige
l’entité Apprenant de retrouver les postes ainsi que les diverses directions présentes dans
la base. Le système affiche alors les critères de choix par lesquels notre internaute peut
filtrer la liste demandée, tout en énumérant l’ensemble de tous les utilisateurs. Du moment
où l’administrateur introduit ses critères, le système se charge de recenser la nouvelle liste,
afin que cet acteur fasse de nouveau son choix. Une fois l’utilisateur sélectionné, tous ses
détails seront chargés, le cursus obligatoire qui lui est affecté ainsi que les formations qu’il
a déjà élaboré permettant ainsi d’assurer le suivi de l’apprenant.
4.2.2 Diagrammes de classes
Un diagramme de classes montre la structure interne du système en fournissant une

représentation abstraite des objets du système qui vont interagir ensemble pour réaliser
les cas d’utilisation.
Il s’agit d’une vue statique car il ne tient pas compte du facteur temporel dans le
comportement du système. Le diagramme de classes modélise les concepts du domaine
d’application ainsi que les concepts internes créés de toutes pièces dans le cadre de
l’implémentation d’une application.
Diagramme de classes du paquetage Utilisateurs
La figure 4.6 illustre les différentes classes conçues pour la réalisation du paquetage
Utilisateurs. La classe Apprenant représente un apprenant de la plateforme. Elle contient
toutes les informations de ce dernier ainsi que les méthodes permettant sa bonne gestion.
De cette classe hérite la classe Administrateur qui représente un utilisateur ayant les
privilèges de gestion de la plateforme.
Figure 4.6 — Diagramme de classes du paquetage Utilisateurs
Diagramme de classes du paquetage Formations
Les formations dans l’UVL sont organisées en modules se composant eux même d’un
nombre de sous modules. Chaque utilisateur a son propre cursus, représenté par la classe
Cursus, qui est l’agrégation ordonnée d’un ensemble de formations obligatoires, classe
SousModule du diagramme.
Figure 4.7 — Diagramme de classes du paquetage Formations

Les formations sont enrichies par des différents supports permettant aux appre-
nants d’acquérir certaines connaissances. Cette richesse vient du fait que la plate-forme
propose plusieurs types de supports (PDF, présentation PPT, Flash, livres interactifs,
vidéos)représentés par la classe Support élément du paquetage Bibliothèque et utlisée
par le paquetage Formation. Ces différentes classes et relations sont illustrées dans la
figure 4.7.
Diagramme de classes du paquetage Evaluation
Dans les délais de chaque formation, les apprenants doivent s’évaluer, et ce, à travers
un QCM (classe QCM dans le diagramme) comportant un ensemble de questions générées
automatiquement à partir de la classe CatalogQCM qui contient toutes les questions
en relation avec la formation en cours. Afin d’éviter les répétitions des questions pour un
même apprenant nous avons eu recours à la classe QCMPassé pour sauvegarder toutes
les évaluations des utilisateurs. La figure 4.8 montre comment ces classes sont organisées
au sein du paquetage Evaluation.
Figure 4.8 — Diagramme de classes du paquetage Evaluation
Diagramme de classes du paquetage Collaboration
Le partage de connaisances entre les apprenants se fait essentiellement à travers le

Forum mis à leur disposition. La plate-forme offre aussi la possiblité de contacter l’ad-
ministrateur par mail. Les différentes formes de collaboration sont données par la figure
4.9.
Figure 4.9 — Diagramme de classes du paquetage Collaboration
4.2.3 Conception de la base de données
Le modèle relationnel de données est un modèle de données comme d’autres existants

ayant pour but la description e monde réel à partir des informations et des données qu’on
peut en extraire et se différencient par la nature des associations qu’ils permettent de
modéliser. L’objectif essentiel du modèle relationnel était d’accroı̂tre l’indépendance vis-
à-vis du niveau de représentation des données. Du point de vue utilisateur, une base de
données peut être considérée comme un ensemble de tables manipulables par des langages
de haut niveau dont la caractéristique principale est d’être des langages non procédéraux.
A ce niveau de l’application et tout en tenant compte des besoins déjà spécifiés, nous
avons envisagé un certain nombre de tables pour le stockage des données nécessaires pour
la bonne gestion de la plateforme.
Les tables conçues et les relations qui les inter-relient sont données par les figures 4.10
et 4.11.
Figure 4.10 — Schéma conceptuel de la base de données

Figure 4.11 — Conception de la base de données du forum

Conclusion
Dans ce chapitre nous avons déterminé les différents objets de l’application contri-
buants à assurer les fonctionnalités souhaitées par ses utilisateurs.
Cette phase était alors une préparation à la phase de codage qui constituera l’objet
du chapitre suivant.
CHAPITRE
5 Réalisation
Après avoir achevé l’étape de conception de l’application, nous entamons dans ce

chapitre la phase de réalisation. Nous commençons par présenter les outils, les technologies
et les frameworks utilisés lors de la réalisation de la plate-forme. Ensuite, nous donnerons
un aperçu sur le travail accompli à travers des captures d’écran de l’application. Enfin,
nous illustrons, via un chronogramme, la répartition temporelle des tâches tout au long
du stage.
5.1 Environnement logiciel du travail
Dans cette section nous donnons les caractéristiques logicielles de l’environnement de

réalisation de la plate-forme d’apprentissage en ligne.
Entreprise Architect
Enterprise Architect (EA) est un Atelier de Génie Logiciel (AGL) s’appuyant sur le
langage de modélisation unifié UML 2.1, langage qui constitue un moyen efficace pour
recenser, structurer et formaliser les besoins recueillis par l’Analyste.
Netbeans
Netbeans est un environnement de développement intégré (IDE 1 ) pour le

développement des application java/j2ee, C++, python, Ruby. . .Il rassemble toutes les
caractéristiques d’un IDE moderne (éditeur de code en couleur et permettant l’auto-
compélation, projets multilangages, refactoring, édition graphique d’interfaces . . .).
1. Integrated Development Environment
50 CHAPITRE 5. RÉALISATION
Microsoft SQL Server 2005
SQL Server 2005 est le premier produit Microsoft pour la gestion des bases de données
relationnelles. Il est considéré comme le ”Big brother” de Microsoft Access, mais il vise
des bases de données d’entreprises plus sérieuses. SQL Server 2005 se base sur le langage
Transact-SQL pour la manipulation des données.
Le framework JSF
JSF ou Java Server Faces est un framework java pour le développement de clients
riches pour les applications web. JSF est basé sur la notion de composants, il reprend le
modèle d’autres frameworks pour l’IHM tel que Swing ou SWT où l’état d’un composant
est enregistré lors du rendu de la page pour être ensuite restauré au retour de la requête.
JSF met en œuvre le modèle MVC basé sur une seule servlet nommée Faces Servlet faisant
office de contrôleur et des pages JSF pour l’IHM. L’application de ce modèle permet la
séparation du mode web en trois parties distinctes : le modèle, la vue et le contrôleur.
L’architecture de JSF est donnée par la figure 5.1.
Figure 5.1 — Architecture du framework JSF
Le framework Hibernate
C’est un framework qui donne une solution pour le mapping objet/relationnel et la

gestion de la couche de persistence. Hibernate permet la gestion automatique de la struc-
ture de la base de données : création et mise à jour. Il utilise un langage simple pour
5.2. TRAVAIL RÉALISÉ 51
l’interrogation de la base de données appelé HQL 2 et qui fournit une couche d’abstrac-
tion SQL. Hibernate vient se positionner entre la couche métier de l’application et les
données auxquelles elle a besoin comme représenté dans la figure 5.2.
Figure 5.2 — Position d’Hibernate dans une application web
5.2 Travail réalisé
A cette étape, nous rappellons, à travers la figure 5.3, la structuration fonctionnelle

de la plate-forme. Nous exposerons ensuite le travail réalisé à travers des captures d’écran
relatives aux principaux modules implémentés.
5.2.1 Côté apprenant
Authentification des utilisateurs
La page d’authentification des utilisateurs, représentée par la figure 5.4, est le point
d’entrée à la plate-forme. A travers son login et son mot de passe, l’utilisateur est identifié
par le système. En fait, il peut être soit un apprenant qui veut accéder pour se former
et s’évaluer, soit un administrateur voulant exécuter des tâches de gestion dans la plate-
forme.
2. Hibernate Query Language

Figure 5.3 — Les modules réalisés de la plateforme
Figure 5.4 — Authentification des utilisateurs

Accueil d’un apprenant
Après avoir été reconnu par le système, l’apprenant se trouve dans la page d’accueil
qui lui propose de continuer la formation en cours s’il y en a une ou de s’inscrire dans la
formation suivante de son cursus sinon. La figure 5.5 illustre cette page.
Choix et consultation des supports de formation
L’apprenant est amené ensuite à consulter les différents supports de formation de

différents formats relatives à la sous formation en cours. A travers la page de formation,
l’utilisateur choisit le support à consulter. Un des supports disponibles au sein de l’UVL
est le livre interactif à feuilleter représenté dans la figure 5.6. En effet c’est dans le but
d’attirer les apprenants que ce type de support est mis en place.
L’évaluation par QCM
Les utilisateurs sont invités à un QCM pour valider leurs connaissances acquises durant
la formation. L’interface de cette évaluation est donnée par la figure 5.7. Le test contient
cinq questions à deux, trois ou qutre propositions et l’apprennant doit l’y répondre et
valider sa réponse avant l’écoulement des dix secondes allouées.
Figure 5.5 — Accueil d’un apprenant

Figure 5.6 — Livre interactif
Figure 5.7 — Evaluation par QCM

Participation au forum
A l’aide d’un forum, l’apprenant peut communiquer avec d’autres utilisateurs afin de
poser des questions ou de répondre à d’autres posées par d’autres apprenants.
Figure 5.8 — Participation au forum
5.2.2 Côté administrateur
Un administrateur doit s’authentifier pour pouvoir accéder au site. Ce super utili-

sateur jouit de plusieurs fonctionnalités. Il a la possibilité de gérer toutes les bases de
données de la plate-forme. Cette figure montre l’administration des apprenants, des mo-
dules, des QCMs, des divers supports de cours. Par ailleurs l’administrateur peut accéder
aux différents rubriques du site tel que le forum et la bibliothèque.
Accueil de l’administrateur
La figure 5.9 donne un aperçu sur la première page de l’administration de la plate-

forme à partir de laquelle l’administrateur effectue
Figure 5.9 — Accueil de l’administrateur

Gestion des modules
La figure 5.10 montre l’interface de modification des modules. Cette interface inclue
la modification des divers champs relatifs à ce module. Par ailleurs, un administrateur a
la possibilité d’ajouter un sous module, changer les données concernant ce dernier tel que
la durée de formation . . .Il peut éventuellement supprimer un sous module.
Figure 5.10 — Gestion des modules
Ajout d’un support de cours
L’ajout d’un document électronique est une tâche aussi simple. Tout d’abord, l’admi-
nistrateur doit choisir le module et le sous module auxquels est lié le support de formation.
Une fois choisi, le système se charge automatiquement d’extraire le nom, le type du fichier
et sa taille afin de les insérer dans la base de données. La figure 5.11 montre l’interface
à partir laquelle l’administrateur peut ajouter un document à une formation.
Figure 5.11 — Ajout d’un support de formation
Ajout d’un utilisateur
La figure 5.12 illustre l’interface d’ajout d’un utilisateur. Cette dernière demande le
remplissage ses coordonnées relatives. L’administrateur est alors sollicité de recenser les
formations qui lui sont obligatoires. Dès qu’il commence le système met à jour le cursus
de formation et l’affiche au fur et à mesure que l’administrateur le définit.
5.3. CHRONOGRAMME 61
Figure 5.12 — Ajouter un utilisateur
5.3 Chronogramme
Il est nécessaire de tracer un diagramme qui décrit la répartition temporelle des tâches
du travail durant deux mois afin de montrer les différentes phases par lesquelles notre
projet a passé.
– Documentation et études théorique : elle consiste à rechercher une documentation

sur le sujet et à étudier les objectifs généraux du stage.
– Spécification et analyse de besoins : elle consiste à étudier l’état actuel du processus
de travail de l’entreprise ainsi que ses besoins réels.

– Conception : elle vise à modéliser le système selon une vue bien claire.
– Implémentation : elle s’occupe du développement du codes des différentes fonctio-
nalités du système comme modélisé dans la conception.
– Rédaction du rapport : elle collecte toutes les informations nécessaires et autorisées
à être publiées.
Le chronogramme suivant donne la répartition de ces différentes phases :
Figure 5.13 — Chronogramme des tâches
Conclusion
Dans cet ultime chapitre nous avons présenté l’environnement de la mise en œuvre de
notre application. Nous avons présenté aussi le travail réalisé à l’aide de quelques captures
d’écran.
CHAPITRE
6 Conclusion et
perspectives
Au terme de ce rapport nous rappelons les objectifs du stage et les différentes étapes
par lesquelles l’application a passé pour aboutir à son état actuel.
Ce présent document est le rapport de la mémoire de fin d’études effectué au sein

de Laceramic SA et qui avait pour objectif de développer une plateforme de formation à
distance baptisée ”Laceramic Virtual University” permettant aux différents employés de
laCeramic de suivre à distance des formations concernant le système d’information de la
société afin de gagner en terme de temps et d’argents.
Nous avons commencé par une mise en contexte à travers une introduction et une
présentation générales. Ensuite une étude théorique a été effectuée afin de nous permettre
de bien définir les concepts théoriques en relation avec le domaine de l’apprentissage à
distance. La partie suivante a mis en relief les besoins spécifiques de LACERAMIC qui
l’ont fait penser à une solution de formation à distance. La conception est venu ensuite
pour traduire les spécifications recensées en un modèle logique présentant l’architecture
générale de l’application. La réalisation, où nous avons transformé le modèle théorique en
un système fonctionnel, a constitué la clôture du rapport.
En guise de conclusion, ce projet nous a permis de travailler sur un produit d’avenir

au moins en Tunisie(les plate-formes du E-Learning). Il a été bénifique aussi bien sur le
plan théorique que sur le plan pratique. En effet le développement de cette application
nous a donné l’occasion de se familiariser avec les notions et les outils de la mise en œuvre
des architectures web, notamment l’architecture J2EE.
En outre le travail accompli durant le stage contribuera dans l’amélioration du ren-

61
dement des employés de Laceramic SA travaillant sur son système d’information. C’est
alors que dans cet esprit qu’en perspective notre application peut être perfectionner en
la migrant vers un portail d’apprentissage à distance sans oublier bien évidemment de lui
ajouter d’autres formes de collaboration comme un tableau blanc ou un wiki.
Bibliographie
[1] Olivier Debas, Christine Deffaix Rémy Applications Web Java Servlets et JSP,2004
[2] David GearyCore, Cay Horstmann JavaServer Faces, Second Edition,2007
[3] Giulio zambon Begining JSP, JSF and Tomcat web devloppement.Apress 2007
[4] Eric Sarrion. UML 2 pour la pratique .4ème édition, Septembre 2005
[5] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide
.WESLEY, 1999
[6] Som Naidu. E-Learning – A Guidebook of Principles, Procedures and Practices .se-
cond Revised Edition, CEMCA, 2006
[7] Terry Anderson. Theory and Practice of Online Learning .AU Press, 2008
Netographie
[N1] http://www.elearning-developer.com/2008/ consulté le 02 fevrier 2009

[N2] http://www.leprojetweb.com consulté le 27 février 2009
[N3] http://www.institut.minefi.gouv.fr/e-formation/ consulté le 25 février 2009
[N4] http://cmsreport.com/category/dotcms consulté le 27 février 2009
[N5] http://cms.epfl.ch/ consulté le 28 février 2009
[N6] http://claroline.up.univ-mrs.fr consulté le 01 mars 2009
[N7] http://fr.wikipedia.org/wiki/Alfresco consulté le 02 mars 2009
[N8] http://dev.corinis.org/corinis consulté le 02 mars 2009
[N9] http://www.jsftoolbox.com/documentation/ consulté le 10 mars 2009
[N10] https://javaserverfaces.dev.java.net/ consulté le 20 mars 2009
[N11] http://www.jsfcentral.com/ consulté le 7 avril 2009
[N12] http://www.netbeans.org/ consulté le 10 avril 2009
Glossaire
2TUP : 2 Track Unified Process
ACCOLAD : Apprntissage COLLaboratif A Distance
AJAX :
AOP : Aspect-oriented programming
API : Application Programming Interface
ASP : Active Server Page
CMS : Content Management System
CORBA : Common Object Request Broker Architecture
CGI : Common Gateway Interface
DNS : Domain Name Service
DSDM : Dynamic System Development Method
EJB : Enterprise Java Beans
EVT : Ecole Virtuelle Tunisienne
FOAD : Formation Ouverte A Distance
GNU :
GPL :
HQL : Hibernate Query Language
HTML : HyperText Markup Language
IDE : Integrated Development Environment
IHM : Interface Homme Machine
INES : INteractive E-Learning System

GLOSSAIRE 65
ISET : Institut Supérieur des Etudes Technologiques
J2EE : Java 2 Entreprise Edition
J2SE : Java 2 Standard Edition
JDBC : Java DataBase Connectivity
JMS : Java Messaging Service
JNDI : Java Naming and Directory Interface
JSF : Java Server Face
JSP : JavaServer Pages
JTA : Java Transaction API
LCMS : Learning Content Management System
LDAP : Lightweight Directory Access Protocol
LMS : Learning Management System
MAS : Mediterranean Air Service
MP3 : Mpeg Audio Layer-3
MVC : Model-View-Controller
NIS : Network Information Services
OMG : Object Management Group
PDF : Portable Document Format
PPT : PowerPoinT
QCM : Questionnaire à Choix Mutiples
RAD : Rapid Application Development
RPC : Remote Procedure Call
RUP : Rational Unified Process
SA : Société Anonyme
SQL : Structured Query Language
SWT :
TIC : Technologies de l’information et de la communication

66 GLOSSAIRE
UML : Unified Modeling Language
UVL : Université Virtuelle de LACERAMIC
UVT : Université Virtuelle Tunisienne
VAP : Validation des Acquis Professionnels
WYSIWYG : What You See Is What You Get
XML : eXtensible Markup Language
XP : Extreme Programming
ANNEXE
A Le standard J2EE
J2EE signifie signifie Java 2 Entreprise Edition et repose donc sur Java, le fameux
langage objet conçu pour être ”portable” (”Write Once, Run Anywhere”).
J2EE a pour but de crédibiliser le statut de Java en tant que plateforme pour la
programmation en entreprise.
Architecture système
Il existe de nombreuses architectures possibles pour les applications d’entreprise, nous

allons passer en revue les plus connues et nous verrons à quelle problématique J2EE tente
de répondre.
Architecture à deux niveaux
Pour simplifier, on peut dire que, dans ce type d’architecture, les traitements sont sur
le client et la base de données est sur le serveur. Le plus gros problème est celui de la
maintenance : La moindre modification oblige à mettre à niveau chaque poste client. De
plus les performances de l’application sont pour beaucoup en fonction des ressources des
clients.
Architecture à trois niveaux
A cause des problèmes de l’architecture à deux niveaux, on a rajouté un autre niveau.

Ainsi une application est divisée en trois niveaux logiques :
1. Niveau présentation : l’interface graphique pour l’utilisateur.

67
2. Niveau métier : Recouvre la logique métier ( aussi appelée logique applicative).
3. Niveau données : Les données de l’application ( serveur de base de données, docu-

ments XML, serveur LDAP . . .).
Le niveau métier contient le code appelé (via le niveau présentation) par l’utilisateur
pour extraire et traiter les données de la troisième couche. Cette séparation en couches
améliore la souplesse de l’application. Il devient facile de déployer de nombreuses interfaces
utilisateur sans devoir modifier la logique applicative.
Architecture à n niveaux
Ce genre d’architecture se compose de différents niveaux que l’on peut subdiviser

comme le montre la figure suivante :
Figure A.1 — Architecture N-tiers
– Interface utilisateur ou vue : Couche chargée de gérer les interactions entre l’utilisa-
teur et l’application (Application de bureau, navigateur WAP, Browser Internet. . .)
– Logique de présentation ou contrôleur : Elle permet de définir ce que doit afficher
l’interface utilisateur et la manière dont les requêtes doivent être traitées.
– Logique métier : Modélise les règles métiers de l’entreprise.
– Service d’infrastructure ou classes d’accès aux données : Fonctionnalités fournies
aux composants (connexions, transactions. . .).
68 ANNEXE A. LE STANDARD J2EE
– Données : Données de l’entreprise.

Ce genre d’architecture suit le modèle Modèle Vue Contrôleur (Voir les explications
du pattern MVC sur le site de sun ), c’est ce modèle que J2EE suit.
La plateforme J2EE
En fait, J2EE est une norme qui va spécifier à la fois l’infrastructure de gestion de vos
applications et les API des services utilisées pour concevoir ces applications. La plateforme
J2EE est essentiellement un environnement fournissant :
– Une infrastructure d’exécution pour faire tourner les applications.
– Un ensemble de services accessibles via l’API J2EE pour vous aider à concevoir les
applications.
Les API J2EE
La spécification de la plateforme J2EE prévoit un ensemble d’extensions Java standard

que chaque plate-forme J2EE doit prendre en charge :
– JNDI : JNDI est une extension JAVA standard qui fournit une API uniforme per-
mettant d’accéder à divers services de noms et de répertoires. Derrière un nom JNDI,
il peut y avoir un appel à des services CORBA, DNS, NIS, LDAP . . .En fait, JNDI
permet de localiser et d’utiliser des ressources.
– JDBC : Java Database Connectivity est une API qui permet aux programmes Java
d’interagir avec les bases de données SQL.
– Servlet : Un servlet est un composant coté serveur, écrit en Java, dont le rôle
est de fournir une trame générale pour l’implémentation de paradigmes ” requête-
réponse ”. Ils remplacent les scripts CGI tout en apportant des performances bien
supérieures.
– JSP : La technologie JSP (JavaServer Pages) est une extension de la notion de
servlet permettant de simplifier la génération de pages web dynamiques. Elle se
sert de balises semblables au XML ainsi que de scriplets Java afin d’incorporer la
logique de fabrication directement dans le code HTML. JSP est un concurent direct
de l’ASP et du PHP.
69
– JMS : Java Messaging Service est à la fois une ossature et une API permettant
aux développeurs de construire des applications professionnelles qui se servent de
messages pour transmettre des données.
– JTA : La spécification JTA (Java Transaction API) définit des interfaces standards
entre un gestionnaire de transactions et les éléments impliqués dans celles-ci : L’ap-
plication, le gestionnaire de ressources et le serveur.
– EJB : Chaque instance d’un EJB se construit dans conteneur EJB, un environnement
d’exécution fournissant des services (Sécurité, Communications, Cycle de vie...). Un
client n’accède JAMAIS directement à un composant. Il doit pour cela passer par une
interface locale et une interface distance. L’interface locale décrit le cycle d’existence
du composant en définissant des méthodes permettant de le trouver, de le créer, de
le détruire. Et L’interface distante spécifie les méthodes que ce composant présente
au monde extérieur.
Les conteneurs J2EE
Un conteneur J2EE est un environnement d’exécution chargé de gérer des composants

applicatifs et leur donner accès aux API J2EE.
L’architecture des conteneurs J2EE doit comporter :

– Les composants applicatifs : Les servlets, les JSP, les EJB. . .. En somme les compo-
sants de votre application.
– Descripteur de déploiement : C’est un fichier XML décrivant vos composants appli-
catifs et qui fournit des informations au conteneur sur vos composants applicatifs
(droit d’accès, transaction . . .).
L’architecture d’un conteneur, quand à elle, se divise en quatre parties :
– Les interfaces des composants : Ensembles d’interfaces spécifiées par le conteneur et
que vos composants applicatifs doivent implémenter.
– API des services du conteneur : Services supplémentaires fournies par le conteneur
– Services déclaratifs : Services introduits par le conteneur sur vos applications.
– ” Autres services du conteneur : Il s’agit des services tels que le garbage collector,
le pooling des connexions base de données . . .
70 ANNEXE A. LE STANDARD J2EE
Processus de développement d’application J2EE
Une application J2EE commence par la création de composants J2EE. Ces composants
sont ensuite regroupés en modules auquel on associe des descripteurs de déploiement. Ces
modules J2EE peuvent ensuite être déployés comme application à part entière ou être as-
semblés avec un descripteur de déploiements J2EE et être déployés en tant qu’application
J2EE. ( voir la spécification de sun au format PDF )
Création de composants applicatifs
Durant cette phase, nous modélisons les règles métiers sous la forme de composants
applicatifs. Ces composants applicatifs seront groupés selon leur type ( Web, EJB.. )
avec un descripteur de déploiement pour donner un module J2EE. Ces modules J2EE
composeront l’application J2EE.
Assemblage de l’application
Une application J2EE peut être constituée d’un ou plusieurs module J2EE et un
descripteur d’application J2EE. L’application J2EE est packagée dans un fichier ayant
l’extension .ear ( Entrerpise Archive ).
Déploiement
Le déploiement d’applications consiste à installer et à personnaliser des modules empa-

quetés sur une plateforme J2EE. Ce processus se compose de deux étapes :l’installation(On
installe l’application sur le serveur J2EE) et la configuration (On paramètre l’application
pour qu’elle s’intègre à l’infrastructure sur laquelle elle vient d’être installée : mot de passe
base de données, factory de connexions, utilisateurs, droits . . .).
ANNEXE
B Le framework JSF
JSF - ou JavaServer Faces - est une spécification Sun pour le développement d’inter-
faces utilisateur enrichies pour les applications Web.
Un des principaux avantages de JSF, c’est qu’il est à la fois un standard de Java Web
user-interface et un framework qui suit fermement le Modèle-Vue-Contrôleur (MVC) de-
sign pattern. Cela fait que les applications JSF sont beaucoup plus gérables car le code
d’interface utilisateur (Vue) est nettement séparé des données et de la logique métier
(modèle). Afin de préparer le contexte JSF, qui fournit l’accès des données aux pages,
et pour protéger contre les accès non autorisés ou impropres des pages, toutes les inter-
actions de l’utilisateur avec l’application sont traitées par un front-end ”Faces” Servlet
(Contrôleur).
FacesServlet est l’élément contrôleur dans le framework JSF à travers lequel toutes les
demandes des utilisateurs vont passer. FacesServlet examine les demandes et les appels
des différentes actions sur le modèle utilisant les managed beans. Les Managed beans sont
un exemple du modèle. Les composants de JSF User Interface (UI) représentent la couche
vue.
Le cycle de vie de JSF
Le contrôleur Faces servlet sert comme un lien entre l’utilisateur et l’application JSF.
Il fonctionne dans le cadre d’un du cycle de vie de JSF bien défini qui décrit l’ensemble du
flux d’événements entre les requêtes des utilisateurs. Par exemple, lors d’une initialisation
d’une application JSF, le contrôleur Faces Servlet gère la requête par préparation du
contexte JSF, qui présente un objet Java détenant toutes les données d’application. Le
72 ANNEXE B. LE FRAMEWORK JSF
contrôleur redirige ensuite l’utilisateur à la page demandée. La page rend habituellement

les données à partir du contexte de JSF utilisant un langage simple d’Expression (Ce
langage permet de lier les composants aux managed-beans). Le contrôleur effectue alors
des mises à jour de tout type de données, tout en fournissant les nouvelles données. Ceci
permet aux développeurs de JSF d’avoir accès à l’ensemble du cycle de vie JSF, tout au
long de son exécution, offrant ainsi un degré élevé de contrôle sur le comportement de
l’application.
Les composants User-Interface de JSF
Le point fort de JavaServer Faces réside dans son modèle de composants User-
Interface(UI), où les applications sont simplement construites à partir de collections de
composants qui peuvent se présenter de diverses manières pour plusieurs types de clients.
Vaguement semblable à d’autres technologies propriétaires tels ASP.Net, la technologie
de composants UI propose une productivité illimitée permettant aux développeurs de
construire des interfaces Web utilisant des composants pré-construit plutôt que d’avoir
à construire l’interface utilisateur entièrement à partir de zéro. Les composants JSF UI
prennet de nombreuses formes et peuvent être aussi simple qu’un outputLabel (compsant
qui affiche du simple texte) ou aussi complexe qu’un DataTable (composant qui peut
représenter un tableau de données à partir de collections de données telles que la table
d’une base de données.
La spécification de JavaServer Faces fournit un ensemble de composants de base de

l’interface utilisateur qui sont très utiles. Il s’agit notamment de deux bibliothèques de
composants tels que la bibliothèque ”HTML” de composants, qui s’inspire largement de
la contribution des éléments HTML standard, avec une bibliothèque ”Core” qui aide les
tâches communes de développement d’application telles que l’internationalisation, la va-
lidation / conversion des données d’entrée... En plus de la bibliothèque de base ” User
Interface Components ”, l’API de JSF offre la possibilité d’étendre et de créer des com-
posants UI offrant des fonctions supplémentaires qui dépassent les composants de base.
ANNEXE
C DAO et Hibernate
Quelque soit le choix du programmeur de la plateforme et du serveur de base de

données, la tendance actuelle veut que le développement soit fait dans un langage objet
et utilise une base de données relationnelle.
Les difficultés de cohabitation entre les mondes objets et relationnels sont résolues
grâce au concept de Mapping objet-relationnel (O/R Mapping), qui est le nom donné aux
techniques de transformation des modèles objets en modèles relationnels.
Séparation des couches
Le choix d’une architecture multi-tiers pour les diverses applications, où la séparation
entre couches est mise en relief, est en train de plus en plus s’accentuer. Ces couches
devant être indépendantes. Dès que les spécifications fonctionnelles de chacune d’entre
elles soient établies, leur développement pourra se faire en parallèle, et la maintenance de
l’application n’en sera que plus aisée.
La couche d’accès aux données (Data Access Layer ou DAL), prend en charge toutes
les interactions entre l’application et la base de données. Si une telle couche n’existait
pas, il sera inévitable de réécrire les mêmes lignes de code à différents endroits de l’appli-
cation. En effet, cette couche prend en compte l’ensemble des interactions possibles avec
la base de données, c’est-à-dire la création, la lecture, la modification ou la suppression
des enregistrements dans chacune des tables de la base de données. Il est commun de
créer une classe pour chaque table existante, et de créer des méthodes possédant autant
de paramètres que la table possède de champs.
74 ANNEXE C. DAO ET HIBERNATE
Objectifs d’une couche d’accès aux données
Quel que soit le système de développement, il est toujours possible d’accéder aux
données relationnelles. L’utilisation des API telles que JDBC, ADO, ADO.Net put servir
à exécuter des requêtes SQL, ou à obtenir des objets représentant des tables et leurs
champs,. . .
Ces outils sont suffisants mais ne permettent jamais à eux seuls une vraie abstraction
de la base de données sous-jacente. Par exemple l’obtention de toutes les commandes
d’un client donné avec une seule ligne de code est impossible. De plus, la suppression
d’un client exige sa suppression manuelle par l’intermédiaire de son adresse, alors qu’elle
pourrait être faite automatiquement.
Tous ces problèmes doivent être gérés par une couche d’accès aux données chargée de
communiquer avec le serveur de bases de données, et de renvoyer des objets métiers au
programmeur ; Ce denier n’aurait alors plus besoin de taper des requêtes SQL, comprendre
les relations entre les tables, ou connaı̂tre tous les paramètres des procédures stockées, ou
encore d’autres éléments.
C’est le but des DAO. Ils sont créés pour simplifier au maximum le travail du program-
meur avec le système de données en encapsulant les accès à la base via les frameworks tels
qu’ADO.Net. De plus, les DAO permettent d’accéder à des entités qui sont en relation,
effectuant les jointures en base de données automatiquement.
Limitations
Fonctionnalités : Les DAO n’ont pas pour objectif de gérer des concepts plus com-
plexes tels que les transactions ou la concurrence. De ce fait, la réalisation de la
couche métier restera quand même plus ou moins complexe à réaliser suivant le
modèle de base de données.
Couplage : Vis-à-vis du programmeur des classes métiers, le découplage avec la base de

données est réalisé. Cependant, d’autres programmeurs devront se charger du codage
de l’ensemble de ces classes, et la moindre modification de la base de données obligera
à revoir l’implémentation des DAO correspondants.
Taille des projets : Même s’il existe aujourd’hui de nombreux générateurs de classes
75
DAO qui utilisent des bases de données existantes, leur utilisation pour des projets
volumineux s’avère limitée, car nécessitant des fonctionnalités plus avancées.
Frameworks de persistance
Les frameworks de persistance sont plus que de simples wrappers de tables proposant
l’accès aux champs de celles-ci. Il s’agit en général d’outils permettant de modéliser un
système de données, en UML ou en XML par exemple, et de générer tous les DAO ainsi
que les objets métiers permettant d’exploiter au maximum un système de données.
De plus, ils prennent en charge des concepts avancés comme le cache des objets, la
concurrence, les transactions distribuées, le chargement des données via des requêtes ob-
jets, et peuvent également offrir une totale indépendance vis-à-vis du serveur de bases de
données.
Ils créent des systèmes complètement autonomes de gestion du système d’information,

autorisent un fort découplage avec la base de données, améliorent les performances et
apportent une grande simplicité d’utilisation. Le seul inconvénient est qu’il s’agit sou-
vent de solutions commerciales plus ou moins coûteuses suivant les fonctionnalités ou la
plateforme d’utilisation.
Avantages des Framework de persistance
Indépendance : On n’a plus à se soucier des problèmes liés aux bases de données telles
que le mapping, ou les méthodologies d’accès aux différents serveurs de bases de
données.
Performances : L’utilisation d’un cache objet performant permet d’améliorer sensible-

ment les caractéristiques de montée en charge des applications.
Modélisation objet : Elle est d’autant plus facile qu’elle est objet, permettant une
meilleure compréhension du système de données grâce à l’UML, et une réutilisation
d’autant plus facile de modèles préexistants.
Savoir-faire : En informatique, personne n’est spécialiste dans tous les domaines, et

l’exploitation des bases de données est un domaine vaste. Les frameworks de per-
sistance permettent à n’importe qui d’exploiter des méthodologies d’accès avancées,
76 ANNEXE C. DAO ET HIBERNATE
avec une simplicité d’utilisation déconcertante.
Temps de développement : Les temps de développement sont énormément réduits,

encore plus si il y a peu de logique métier à votre application. Par exemple, un outil
de persistance a permis de réduction du nombre de lignes de codes de 850 000 lignes
de codes à 300 000.
Exemple de framework de persistance : Hibernate
Hibernate permet d’alléger de façon importante le développement de la persistance

de données. Cette librairie a été développée à la base par une équipe de développeurs
Java mené par Gavin King et ensuite fournie par JBoss. Elle permet de faire du mapping
relationnel/objet. C’est un outil de persistence puissant et performant permettant le lien
entre les objets d’une application et les tables d’une base de données tout en éxécutant
des requêtes.
Concrêtement, Hibernate permet de lier/mapper un objet défini en Java avec une table
dans une base de données, via un fichier déclaratif de mapping. Le système peut s’occuper
de la création des tables en fonction des fichiers de configuration et mettre aussi à jour
les tables si nécessaire lors d’un changement dans l’un des fichiers de configuration.
Hibernate posséde plusieurs moyens pour effectuer des requêtes. Il est possible d’expri-
mer des requêtes en SQL, ou en HQL (language propre à Hibernate) ou encore en critéres
orienté objet.
La nouvelle version d’Hibernate (version 3) a apporté de nouvelles fonctions. Une de

ces nouvelles fonctions est la gestion temporelle des données en sous-ensembles. Dans
les versions antérieures, le développeur devait écrire lui-même les requêtes lui permettant
d’accéder à des données d’une certaine période. Le classement en sous-ensembles se fait via
des filtres définis déclarativement. Cela permet de définir quels sont les droits d’accès d’un
utilisateur donné. La dernière version d’Hibernate est liée étroitement avec la spécification
des EJB 3 permettant ainsi une meilleure implémentation des EJB dans JBoss.

Laceramic Virtual University

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Laceramic Virtual University

Transféré par

Droits d'auteur :

Formats disponibles

Dédicace

Je me permet d’exprimer ma plus profonde reconnaissance à :

Ma mère Majda : Qu’aucune expression de gratitude ne suffisait pour témoigner de

Ma fiancée Yosr : Pour ses encouragements et son support durant la période du

Au terme de ce travail, nous présentons notamment notre profonde gratitude à Mon-

1.1 Présentation de Laceramic S.A . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Activités principales de Laceramic . . . . . . . . . . . . . . . . . . 3

1.1.2 Dispersion géographique du groupe LACERAMIC . . . . . . . . . . 4

1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Généralités sur le E-Learning . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Processus du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.3 Situation du E-Learning en Tunisie . . . . . . . . . . . . . . . . . . 12

2.2 Les outils du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Les outils de gestion des formations (LMS) . . . . . . . . . . . . . . 14

2.2.2 Les outils de gestion des contenus de formation (LCMS) . . . . . . 18

3 Analyse et spécification des besoins 23

3.1 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Quelques méthodes agiles de développement . . . . . . . . . . . . . 24

3.1.2 Méthodologie retenue . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Standard UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Définition des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5 Analyse des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 27

3.6 Les diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 28

3.6.1 Cas d’utilisation de l’apprenant . . . . . . . . . . . . . . . . . . . . 28

3.6.2 Cas d’utilisation de l’adminstrateur . . . . . . . . . . . . . . . . . . 30

3.7 Plan de navigation de la plateforme . . . . . . . . . . . . . . . . . . . . . . 30

3.8 Les diagrammes d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.8.1 Espace de collaboration . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8.2 Gestion des supports de formation . . . . . . . . . . . . . . . . . . 33

4.1 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Architecture multi-tiers . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.2 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.3 Conception de la base de données . . . . . . . . . . . . . . . . . . . 45

5.1 Environnement logiciel du travail . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.1 Côté apprenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.2 Côté administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . 57

1.1 Dispersion géographique du groupe LACERAMIC . . . . . . . . . . . . . . 4

2.1 Processus du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Comparaison des LMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Comparaison des fonctionnalités des CMS . . . . . . . . . . . . . . . . . . 21

3.2 Cas d’utilisation d’un apprenant . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Plan de navigation de la plateforme . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Espace de collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6 Gestion des supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Diagramme de paquetages de l’application . . . . . . . . . . . . . . . . . . 37

4.3 Evaluation des acquis des apprenants . . . . . . . . . . . . . . . . . . . . . 39

4.4 Suppresion de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 Suivi des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 Diagramme de classes du paquetage Utilisateurs . . . . . . . . . . . . . . . 43

4.7 Diagramme de classes du paquetage Formations . . . . . . . . . . . . . . . 43

4.8 Diagramme de classes du paquetage Evaluation . . . . . . . . . . . . . . . 44

4.9 Diagramme de classes du paquetage Collaboration . . . . . . . . . . . . . . 45

4.10 Schéma conceptuel de la base de données . . . . . . . . . . . . . . . . . . . 46

4.11 Conception de la base de données du forum . . . . . . . . . . . . . . . . . 47

5.1 Architecture du framework JSF . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Position d’Hibernate dans une application web . . . . . . . . . . . . . . . . 51

5.3 Les modules réalisés de la plateforme . . . . . . . . . . . . . . . . . . . . . 52