Dossier de Conception

Intranet Pédagogique
 Table des matières
I. Introduction .......................................................................................... 2
II. Qu’est ce que « méthode agile ».......................................................... 2
III. Les différentes méthodes agiles ......................................................... 3
1. Méthode agile « XP » ............................................................................ 4
2. Méthode agile «RUP » ........................................................................... 4
3. Méthode agile « Scrum » ....................................................................... 5
4. Méthode agile « FDD ».......................................................................... 5
IV. Comparaison entre les méthodes........................................................ 7
V. Méthode agile adaptée ......................................................................... 8
VI. Implémentation de la méthode ......................................................... 10
Conception ................................................................................................. 13
I. User Cases ........................................................................................ 14
1. User case : Etudiant ...................................................................... 14
2. User case : Professeur ................................................................... 16
3. User case : Personnel pédagogique ............................................. 18
4. User case : Personnel administratif............................................. 21

2
 I. Introduction
Afin de faciliter l’interaction client et maitre d’ouvrage, on procède par
une méthode agile qui permet au client d’être pilote à part entière de son projet
et être à jour de son avancement. Cette méthode vise la satisfaction réelle du
besoin du client et non les termes d’un contrat du développement.

Dans le cas du projet de l’Intranet Pédagogique, on a opté pour la

méthode « Scrum » et « XP » (Extreme programming). La première pour la
gestion de l’équipe et la deuxième pour l’application.

Ce document propose une clarification des différentes méthodes et une

synthèse du fondement du choix proposé.

II. Qu’est ce que «méthode agile » :

Les méthodes agiles permettent de concevoir des logiciels en impliquant
au maximum le demandeur (Client), ce qui permet une grande réactivité à ses
demandes. Les méthodes agiles se veulent plus programmatique. Elles visent la
satisfaction réelle du besoin du client, et non d’un contrat préalablement.

Une telle intégration du client dans l’avancement du projet ne serais que

favorable, Le client sera tous d’abord impliquer, la rectification rapide des
problèmes de compréhension du besoin du client, et aussi la motivation de
l’équipe de travail.

Il y’a quatre fondamentaux processus de méthode agile :

 mettre en œuvre des individualités et des interactions, plutôt que des

procédés et des outils. Cela se manifeste par l'accent mis sur les êtres humains
en tant qu'individus et sur l'expertise des équipes de développement, qui
communiquent entre elles de façon très serrée et dans un esprit de confiance
constant.

Travail en groupe, communication

3
 produire un logiciel entièrement testé et qui fonctionne, plutôt qu'une
documentation claire. On rejoint ici les notions de développement itératif
(notion de phases) et d'intégration continue (notion de builds journaliers), en
insistant sur la simplicité et la robustesse du code produit (tests systématiques).

 Documentations succinctes à jours, documentation permanente du

code

 collaborer avec le client, plutôt que négocier un contrat. Le client devient un

partenaire à part entière, qui participe au développement dans le sens où il
détermine l'objectif à atteindre pour obtenir une réelle plus-value (qui seule
justifie les efforts effectués pendant le développement)

 Feedback régulier du client, solution répondant réellement aux

attentes, relation de confiance

 répondre aux modifications, plutôt que suivre un plan. Il est bien évident que
personne, pas même le client, ne peut appréhender avec précision l'ensemble des
besoins dès le début du projet. Le développement agile vise à atteindre un
compromis entre les spécifications initiales présentées aux développeurs (et sur
lequel se fonde le planning) et le résultat final qui bien souvent s'en éloigne un
peu voire beaucoup, en absorbant les modifications tout au long du cycle de
développement. Cela réclame des outils de suivi et une attitude constante de
coopération avec le client.

 Planning flexible, modification possible après première version du

système

4
III. Les différentes méthodes agiles :
Parmi les différentes méthodes agiles existantes on site :

- XP (Extrem Programming)
- Scrum
- FDD (Feature-Driven Development)
- RUP (Rational Unified Process)

1. La méthode agile « XP »
Il s'agit plus d'un ensemble de pratiques à dimension humaine, plutôt
qu'une véritable méthode. Il faut bien reconnaître qu'elle a de gros côtés positifs
et qu'elle est assez facile à mettre en œuvre, au prix parfois d'un changement de
mentalité et d'une acceptation par l'ensemble des équipes impliquées. Il s'agit ici
d'appliquer "à l'extrême" les principes du développement agile, en se focalisant
sur les besoins du client, les individualités, le développement itératif et
l'intégration continue. Le développeur et ses relations avec le client sont au cœur
de XP. Cette méthode convient à des équipes petites voire moyennes, soit
jusqu'à une vingtaine de personnes environ.

Le plus surprenant dans cette méthode est qu'elle peut sembler naturelle,
mais qu'elle n'est concrètement pas évidente à appliquer et à maîtriser car elle
réclame beaucoup de discipline et de communication (contrairement à la
première impression qui peut faire penser à une ébullition de cerveaux
individuels). Il s'agit d'aller vite, sans perdre de vue la rigueur du codage et les
fonctions finales de l'application. La grande force de XP (et le plus grand risque
de le faire échouer) est précisément sa simplicité et le fait qu'on va droit à
l'essentiel, selon un rythme qui doit rester constant.

2. La méthode agile « RUP »

RUP est une véritable méthode qui couvre l'ensemble du cycle de
développement. Son étendue, son coût et sa lourdeur apparente la réserve pour
les projets de moyenne voire de grande importance. Bien que ses auteurs
affirment qu'il est possible d'adapter RUP pour de petits projets, la tâche semble
ardue, car RUP propose un processus complet dont la rigueur et le formalisme
(documentation exhaustive) peuvent rebuter. Une formation préalable est
indispensable si on ne veut pas se perdre dans les centaines de pages HTML qui
forment le processus et les nombreux "artefacts" (documents et logiciels) que
RUP propose de produire.

5
 RUP a un coût d'investissement très important et, en un sens, il peut être
considéré comme pas tellement "agile" car trop rigide. Il s'agit ici cependant
d'un véritable outil complet de gestion de projets. RUP fournit un cadre
générique qu'il faut adapter à chaque application. Il est centré sur une
architecture incrémentale et itérative, le développement s'articule autour du
modèle objet et des cas d'utilisation, et favorise UML en tant que langage de
modélisation. RUP affecte à chacun un rôle très clair. RUP est formé d'un
découpage en 4 phases : inception (objectifs et cas d'utilisation), élaboration
(architecture logicielle), construction (développement), transition
(déploiement). Chaque phase se découpe en itérations. Chaque itération dure
entre deux semaines et six mois et fournit une version de l'application.

Moins "extrémiste" que XP, RUP donne en même temps une apparence
de plus grande rigueur, ce qui peut rassurer certains clients habitués aux
documentations exhaustives.

3. La méthode agile « Scrum »

Le terme "Scrum" (qui provient d'une stratégie de rugby) se rapproche
plus d'une gestion de ressources humaines plutôt que d'une réelle méthode de
développement. Il s'agit ici de ne pas oublier le côté humain du développement.
Cette approche a été mise au point par Ken Schwaber.
Théoriquement, Scrum peut se marier d'ailleurs très bien avec XP, en
fournissant aux développeurs "agiles" un cadre de prise en compte du facteur
humain. On peut alors envisager des projets plus importants qu'avec le simple
XP. Comme RUP, il s'agit d'un processus incrémental, mais bien moins
formalisé : Scrum ne propose aucune pratique de développement, juste des
pratiques de management. Il s'agit en fait d'un cadre de gestion de projets bien
adapté aux méthodes de développement agile, comme XP.

4. La méthode agile « FDD »

Cette méthode, élaborée par Jeff de Luca et Peter Code, est plus
formalisée que XP. On peut presque considérer que FDD est une application très
"light" de RUP, car sa particularité est de ne se concentrer que sur les phases de
design et de réalisation, ce qui consiste à élaborer le modèle objet du domaine
avec des diagrammes UML, découvrir la liste des fonctions de l'application, puis
implémenter chacune de ces fonctions, l'une après l'autre.

6
IV. Comparaison entre les méthodes
Voici un tableau synthétique de la comparaison entre les méthodes cités
au préalable.

Méthodes Points forts Points faibles

XP - Développement guidé par les besoins - focalisation sur l'aspect individuel du
du client. développement.au détriment d'une vue
- Equipes réduites, centrées sur les globale et des pratiques de management
ou de formalisation.
développeurs.
- Binômes. Builds journaliers. - Risque de manque de contrôle et de
structuration en laissant les
- Amélioration constante.
développeurs
- Adaptabilité aux modifications.
RUP -Processus complet assisté par des outils -Lourd, largement étendu, il peut être
difficile à mettre en œuvre de façon
-Exhaustif spécifique.

-Rôles bien définis, modélisation. - Convient pour les gros projets qui
génèrent beaucoup de documentation.

Scrum -Petites équipes. -La mise en œuvre du développement

n'est pas précisée.

-Itérations de 30 jours.
-Priorité à la gestion des ressources
humaines.
-Réunions journalières.
FDD -Procédé bien défini et simple. -Uniquement centré sur le
développement.
-Orienté objet et basé sur le
développement.
Itérations très courtes.

7
V. Méthode agile adaptée :
D’après le tableau comparatif on remarque que la combinaison entre la
méthode « Scrum » et « XP » est la mieux adaptée à notre projet intranet
pédagogique, pour les raison suivantes

- On forme une petite équipe de 6 personnes.

- Réunions régulières
- Rapport livrable chaque quinzaine.
- Donner confiance au développeur

On a divisé le projet en deux parties coté organisation dans le quel on va

utiliser « Scrum » et coté mise en place dans lequel on va utiliser « XP ».

Quant à la pratique de ces deux méthodes on les résume dans les points
suivants :
- donner toute confiance aux développeurs et les laisser faire leur travail
- faire des réunions tous les jours pour encadrer les équipes et recaler les
objectifs
- Le développement est itératif, le logiciel est livré fréquemment : XP
découpe le projet en phases, comme dans un projet classique (définition
des besoins, construction, déploiement), mais la phase de construction est
découpée en multiples itérations qui sont elles-mêmes découpées en
phases (spécifications courtes, développement, tests, retour du client). Le
fonctionnel de l'application est décrit en brefs scenariis qu'on peut
implémenter tout de suite et que le client peut juger très tôt. Les
mésententes de compréhension sont alors réduites au maximum.
- Les équipes XP mettent en production un système simple très tôt, et
intègrent les modifications très fréquemment, sur un temps de cycle très
court. L'objectif est de disposer d'un pilote opérationnel très rapidement
et de réduire au maximum les risques dès le début du projet, ainsi que de
fournir très régulièrement des versions effectives
- Le système est remanié progressivement, tout au long du
développement, par petits morceaux. Le logiciel est propre : pas de
duplication, une grande communication, simple, mais complet. Le
nettoyage doit se faire régulièrement (prévoir des séances pour toute
l'équipe).
- Les programmeurs XP travaillent en binôme sur la même machine.
Chaque programmeur code à tour de rôle, pendant que l'autre réfléchit à
la prochaine fonctionnalité à implémenter. Cela nécessite tout de même
une bonne entente en tant qu'individualités. Cela est censé produire un
code robuste et de qualité. En pratique ce n'est pas aussi simple ni

8
 répandu, car il ne s'agit pas de perdre de temps en discussions
interminables entre deux façons de coder une fonction. Souvent, les
développeurs ne s'associent donc en binômes que lors des séances de
refactoring, ou quand ils ont à résoudre un problème difficile à plusieurs.
- Tout le code appartient à tous les programmeurs, la responsabilité
est collective. Quand il faut changer quelque chose, on peut le faire tout
de suite, ce qui permet de travailler à plein régime et de bien appréhender
les problèmes de turn-over
- L'intégration du logiciel est continue, avec plusieurs builds par jour.
On n'attaque pas tout en bloc de front, mais on sépare la tâche en petits
modules intégrés et testés progressivement. Le système est donc plus
stable et opérationnel rapidement. Cela impose de disposer d'outils que
chaque développeur maîtrise pleinement.

9
VI. Implémentation de la méthode :
On va définir les spécifications sous forme de Backlogs ces derniers seront
subdivisés en unités fonctionnelles indépendantes appelées épics. Jusqu’à la date
de livraison du produit final le temps sera définit en plusieurs itérations chacune
comportera un certain nombre d’épics. A la fin de chaque itération il sera établi
un bilan de ce qui a été fait.
Chaque épic sera subdivisé en sous unité appelées stories. Une story est
écrite sous la forme suivante :
« En tant que <rôle> je veux <But> pour <Résultat> »
Une story est subdivisée en petit tâches techniques appelés tasks. La fin
d’une story est conditionnée par la réalisation de conditions de test exprimées
dans une phase appelée critère d’acceptation.

Backlog

épic épic

story story

task task

Hiérarchie de l’implémentation Scrum

10
On va distinguer trois rôles :
 Un Scrum Master : animateur d’équipe. Son rôle est de s’occuper de
toutes les choses non liées au développement afin que l’équipe ne soit pas
dérangée.
 Un Product Owner : représentant du (des) client(s) au sein de l’entreprise.
Son rôle est de définir les priorités dans les tâches à réaliser
(fonctionnalités à développer) et de valider / conseiller les choix effectués
(ex: pour une IHM). Cette personne doit bien connaître les besoins du
client.
 L’équipe : elle est auto-gérée et il n’y a aucune notion de hiérarchie. Les
décisions se prennent ensemble et elles peuvent récupérer des
informations auprès du ProductOwner.

Au niveau du planning de livraison du produit (logiciel), on retrouve également

3 niveaux :

 Un point quotidien est fait sur l’état du logiciel (lors du Daily Scrum)
 Le sprint : correspond à une itération du projet livrée en interne, durant
laquelle un lot de fonctionnalités (déterminé au départ) est développé. Les
buts d’une itération sont fixés au début de celle-ci et ne sont pas (ou peu)
changés durant les quelques semaines du sprint.
 La release : constituée de plusieurs sprints, cette étape correspond à un état
d’avancement où le produit doit potentiellement pouvoir être mis en
production.

11
 Ainsi la méthode Scrum s’occupe de tout ce qui est organisation et relation
(Client / équipe). Afin d’optimiser la réalisation de notre intranet on fera appel à
la méthode XP pour tout ce qui est développement.

Les pratiques de base de XP sont les suivantes :

Pratique de base du processus XP

 Programmation en binôme : le principe est de faire travailler deux

développeurs sur une même machine afin de garantir une bonne qualité
du code.
 Règle du codage : tous les développeurs doivent respectés les mêmes
règles du codage.
 Priorité collectif du code : le code n’appartient à personne.
 Métaphore : décrire le système et les fonctionnalités par une métaphore
pour améliorer la communication entre techniciens et fonctionnels.
 Intégration continue : assembler l’intégralité du code et le tester
plusieurs fois par jour sur une machine dédiée à cela.
 Conception simple : adopté une solution simple à implémenter.
 Développement piloté par les tests unitaires : chaque développeur
écrit un scénario de test unitaire pour le code qu’il produit.
 Remaniement continu ou refactorisation de code : consiste à rendre le
code plus « propre » et à améliorer la conception sans en modifier le
comportement.

12
Conception

13
I. Use Cases :
Nous allons passez à la partie conception, en commençant par les user cases
de l’étude de l’intranet.

1. Use case étudiant :

ID Use Case : 1

Titre du cas d’utilisation: Espace Etudiant

Description sommaire: Les principales fonctionnalités données à un étudiant

Référence croisée : Aucune

Acteurs : Etudiant de l’AIAC

Règle d’initiation : - Une connexion à l’intranet doit être établie.

- La personne doit faire partie des élèves inscrits à l’AIAC pour faire
une nouvelle inscription.
- Le nom de l’utilisateur ainsi que le mots de passe doivent être validés.
Description : Un étudiant à l’académie peut se connecter à cet intranet, après avoir créer un
compte propre à lui, pour télécharger des documents postés auparavant ,
participer au forum, passer un test, entrer au wiki ou au FAQ ou tout
simplement pour consulter sa boîte de messagerie et voir les actualités qui
peuvent le concerner. Tout cela vient après une authentification valide de cet
étudiant.

Règle de terminaison:
Exception :
- Pour une nouvelle inscription un nouvel étudiant sera ajouté à la liste.
-
- La personne tentant de se connecter ne fait pas partie des véritables
élèves.(pas de validation de compte)
- Identifiant ou mot de passe erroné.

Cas d’utilisation :

14
 Contacter webmaster

S'inscrire

<<include>>
Regarder l'actualité,publication

<<extend>>
Consulter actualité Consulter publication
<<extend>>

Participer au forum <<include>>

Consulter messagerie <<include>>

S'authentifier
Etudiant

<<include>>
Agir sur cartable électronique
<<extend>>

Ajouter cours,TD,fiche de TP
<<extend>>
<<extend>> Ajouter

Supprimer

<<include>>
Entrer au FAQ <<extend>>
<<extend>>

Consulter questions+réponses Poser de nouvelles questions

Passer test

<<include>>

<<extend>>
Entrer au wiki <<include>>
<<extend>>

<<extend>>

Modifier topic
Ajouter topic Consulter topic

15
 2. Use case professeur:

ID Use Case : 2

Titre du cas d’utilisation: Espace Professeur

Description sommaire: L’utilisateur étant membre des professeurs de l’académie accède à l’espace qui
lui est consacrée et bénéficie de toutes les fonctionnalités qui lui sont destinées.

Référence croisée : Aucune

Acteurs : Professeur

Règle d’initiation :  L’utilisateur doit être un Professeur

 Le login et mot de passé de l’utilisateur doivent etre validés.

Description du processus: Toute personne déjà inscrite et authentifié autant que personnel administratif
peut bénéficier des différentes fonctionnalités offertes dans cet espace.

Parmi ces fonctionnalités y on a celle qui sont commune pour tous les espaces
tel que :

 Forum
 Wiki
 FAQ
 Messagerie
 Contacter le web master. etc.…
Les différentes fonctionnalités qu’offre cet espace sont :

 Gestion des documents : Ce module offre la possibilité au professeur

de gérer ses documents, notamment l’ajout, la modification et la
suppression
 La consultation des de la liste des élèves et le téléchargement des
documents administratifs publiés par le personnel administratif
 La création d’un QCM : Après création du QCM, le professeur a le
choix entre publier ce QCM ou le stocker.
Règle de terminaison:

Cas d’utilisation :

16
 contacter le webmaster

s'inscrire

<<include>>
telecharger les documentation adiministratif

<<include>>

gerer le profil <<include>>

faire une publication <<include>>

<<include>>
consulter actualite publication

<<extends>>
<<extends>>

consulter publication
consulter actualite

lister les eleves <<include>>

s'authentifier

<<include>>
participer au forum

professeur consulter messagerie

<<include>>

gerer les documents

<<include>>
<<extends>> <<extends>>
<<extends>>

ajouter supprimer modifier

creer un QCM

<<extends>> <<extends>> <<include>>

publier un QCM stocker QCM

entrer FAQ
<<include>>
<<extends>> <<extends>>

proposer des reponse consulter

entrer en wiki
<<include>>

<<extends>> <<extends>>

ajouter topic modifier topic

17
3. User cases personnel Pédagogique :

ID Use Case : 3

Titre du cas d’utilisation: Espace pédagogique

Description sommaire: - Le cas d’utilisation comporte l’ensemble des tâches lié à la gestion
pédagogique au sein de l’académie

Référence croisée : Aucune

Acteurs : - Personnel pédagogique.

Règle d’initiation : - Le web browser ouvert.

- Connexion à l’intranet, utilisateur authentifié ainsi qu’une tâche
planifié.

Description : Le personnel pédagogique peut via le système exécuter un ensemble de tâche

qui entre dans le cadre de la gestion pédagogique au sein de l’académie.
L’ensemble de tâche se résume en :

- Gestion des publications et actualité : qui contient la consultation de

l’ensemble des actualités et publication ajouter par d’autre utilisateur
de l’intranet ainsi que la l’ajout des actualités et publication.
- Gestion des emplois du temps : comporte la création des emplois de
temps pour l’ensemble des professeurs et étudiant. L’emploi du temps
sera générer par un outil de reporting.
- Gestion des étudiants : comprend la gestion de la liste des étudiants
(ajout d’un étudiant, liste des étudiants et la modification des
informations relatives à un étudiant) ainsi que la gestion de l’absence
qui comportera l’état global de nombre d’absence par étudiant sur un
intervalle de temps et aussi les alertes d’absence sur des seuils
préalablement fixé
- Gestion professeurs : ce cas d’utilisation contient l’édition de liste de
matière par professeur ainsi d’autres information et l’envoie de ses
listes au professeur concerne par les listes et aussi comportera des cas
d’utilisation propre au professeur vacataire. Par le quelle peuvent
valider le nombre d’heure de vacation écouler ainsi que le nombre
d’heure restant.
- Gestion des documents administratifs : comportera la gestion
électronique des documents administratifs

Le cas d’utilisation « gestion pédagogique » intègre l’ensemble des fonctions

générique propre a l’intranet tel que :

 Messagerie , Wiki , FAQ, Forum etc. …

18
 Cas d’utilisation :

Contacter webmaster

S'inscrire

<<include>>
Créer profil

<<include>>
Participer au
forum

Regarder l'actualités, <<include>>

publications

Consulter Consulter
publication <<extend>> <<extend>> Actualités

<<include>>
Consulter messagerie

<<include>>
Gérer les emplois du temps
personnel pedagogique

Gérer les Gérer les

emplois du emplois du
temps pr temps pr
prof <<extend>> <<extend>> étudiants
S'authentifier

Gérer les étudiants

<<include>>
<<extend>>
Gérer l'
abscence
<<extend>>

Afficher
liste des
Ajouter étudiants
liste des Modifier
étudiants liste des
<<extend>>
<<extend>> étudiants

Gérer les professeurs <<include>>

gestion des gestion des

<<extend>> prof prof
vacataire <<extend>> permanent
<<extend>>

<<extend>> <<extend>>

envoyer la envoyer la ajouter liste

valider le liste de consulter le ajouter liste des matieres
nbre d'heure nbre d'heure liste de
matiere de des matieres par prof
ecouler de vacation matiere de
prof2 par prof2 <<extend>>
<<extend>>
prof

Gérer les documents

administratifs <<include>>

Entrer au FAQ
<<include>>

Répondre à Ajouter
des quéstions question
<<extend>> <<extend>>

Entrer au wiki
<<include>>

Ajouter Modifier
topic topic
<<extend>>
<<extend>>

19
 4. User cases personnel Administratif :
ID Use Case : 4

Titre du cas d’utilisation: Espace Personnel Administratif

Description sommaire: L’utilisateur étant membre du personnel administratif accède à l’espace qui lui
est consacrée et bénéficie de toutes les fonctionnalités qui lui sont destinées.

Référence croisée : Aucune

Acteurs : Personnel Administratif

Règle d’initiation :  L’utilisateur doit être déjà inscrit.

 Une authentification obligatoire de l’usager.
Description : Toute personne déjà inscrite et authentifié autant que personnel administratif
peut bénéficier des différentes fonctionnalités offertes dans cet espace.

Parmi ces fonctionnalités y on a celle qui sont commune pour tous les espaces
tel que :

 Forum
 Wiki
 FAQ
 Messagerie
 Contacter le web master. etc.…
Ce qui caractérise le plus cet espace c’est le fait qu’il donne à ses utilisateurs
l’opportunité de gérer facilement et avec fiabilité les différents modules tout en
utilisant des outils simple à manipuler.

On ce qui concerne les modules qui sont propres a cet espace on cite :

 Gestion des étudiants : ce module inclus la gestion des documents

administratifs propre à l’étudiant tel que les certificats de scolarité, on
y trouve aussi un outil de gestion du transport afin d’identifier les
différents circuits tout en se basant sur les adresses des élèves.
 Gestion des vacations : comme toute école, l’académie fait appel à des
professeurs de l’externe et donc une gestion des vacations est
primordiale. Pour ce faire cet outil donne la possibilité à
l’administration de faire une gestion financière propre à chaque
professeur tout en se basant sur le nombre d’heure travaillé par ce
dernier.
 Gestion des salles : parmi les taches du personnel administratif est la
gestion des classes lors des examens, des TP, des séminaires etc. … ce
qui est le rôle de cet outil.
 Gestion des événements : grâce à ce module l’usager pourra générer un
événement que ca soit une publication ou une publication afin
d’informer les autres utilisateurs des nouveautés.
Règle de terminaison:

Cas d’utilisation :

20
 Contacter le WebMaster

S'inscrire
<<include>>
Gérer le profil

<<include>>
Gerer les évenements
<<extend>>
Supprimer évenement
<<extend>>
<<extend>>
Ajouter évenement

envoyer évenement

<<include>>
Gérer les étudiant

Gérer les documents administratifs

Gérer le transport <<extend>>
<<extend>>

<<include>>
Gérer le personnel

gestion des <<include>>

vacation

Gestion du programme
Gestion financiaire
<<extend>>
<<extend>>

<<include>> S'authentifier
Gestion des salles

Personnel administratif

Consulter messagerie <<include>>

participer au forum
<<include>>

Entrer au FAC
<<include>>

Répondre à des question

<<extend>> Consulter
<<extend>>

Entrer au wiki
<<include>>

Ajouter Topic modifier Topic

<<extend>> <<extend>>

Regarder Actualité et
publication <<include>>

Consulter
Consulter les publication
Actualité <<extend>> <<extend>>

21