Etude d’un système pour l’organisation d’une conférence  sur la base du modèle de participation et son implémentation dans le cartable électronique


1. Introduction

L’objectif est de pouvoir créer un système qui permet d’organiser une conférence mais ce n’est pas à partir de Zéro ! C’est à la base du modèle de participation et sur la plate forme du cartable électronique®.

2. Analyse détaillé du système

La conférence par définition est l’union d’un certain nombre de personnes qui vont discuter sur un sujet commun. On peut voir ici presque tous les éléments distinctifs d’un travail en groupe, donc le système s’agit bien d’un Collecticiel.

Je vais commencer par identifier l’enceinte pour cette activité, ensuite identifier les acteurs ou bien les profils des participants, puis identifier les message émis et reçus par chaque acteur, juste après je vais essayer d’énumérer les outils déjà existant dans le cartable électronique® et les possibilités de l’utiliser pour implémenter ce système.

2.1. Identification de l’enceinte

Notre enceinte ici est un groupe parmi tout les groupes de l’université qu’on peut facilement le rejoindre. La modélisation des groupes dans le cartable[1] est sous la forme d’un dossier : Un conteneur d’un certain nombre d’objets.

2.2. Identification des acteurs
Les acteurs de ce système sont :

Anonymes : C’est l’internaute ou le visiteur de l’espace web de la conférence, dans le but d’avoir des informations utiles sur cette conférence (date, lieu, comment s’inscrire, sujet…). Aussi ce profil est celui de tout Rédacteur ou bien Relecteur avant l’inscription. On peut prévoir la désactivation du lien vers l’inscription pour pouvoir fermer les inscriptions. Aussi je pense qu’au moins une page d’accueil est nécessaire pour le groupe.

Super User : Comme d’habitude et pour chaque système, ou moins informatique, il existe un Super User. Mais dans ce contexte, cet acteur aura les privilèges nécessaires pour administrer le système.De préférence le Super User n’aura pas le droit d’intervenir dans le processus après le lancement du système d’inscription : il va juste préparer l’enceinte (le groupe). On peut tester la performance du système par le nombre d’intervention de l’administrateur. Pour ce cas bien précis, l’administrateur doit malheureusement, intervenir pour créer le répertoire personnel de chaque participant.

Rédacteur : Les Rédacteurs ce sont les personnes anonymes qui vont s’inscrire comme « Rédacteur ». Après validation de leurs inscriptions ils vont rédiger et proposer un ou plusieurs article. Le dossier rédacteurs contient tout les dossiers personnels de chaque Rédacteur. A chaque connexion le Rédacteur peut visualiser ces articles : il n’a le droit que de créer ou bien d’importer des fichiers.

La séparation entre l’entête et le corps de l’article permet de garantir la confidentialité des articles mais on voit bien le manque dans le cartable de la relation entre l’utilisateur et son espace de travail. Lorsqu’une personne se connecte à la conférence on va lui affecter un répertoire et comme il ne peut pas créer d’autre répertoire et parcourir les autres et donc il va avoir un seul espace de travail.

L’ajout des articles, je pense bien, qu’il faut être contrôlé par une date ou bien par une validation : Un Rédacteur ne peut pas ajouter des articles ou bien les modifier jusqu’au jour J de la conférence !

Relecteur : Ce sont ceux responsable de la relecture des articles. A chacun un répertoire personnel que le président de la conférence va lui déposer les articles qui va les relire (sans entête) Un ajout de commentaire est possible pour chaque article.

Le même problème pour la gestion de l’espace de travail.

Président de la conférence : En terme de nombre c’est une seule personne dont son rôle est de gérer la distribution des articles aux Relecteurs et gérer la publication. Comme il ne s’agit pas du Super User même que son rôle est bien évidemment un rôle d’administration donc il lui faut une bonne console d’administration pour pouvoir gérer tous les flux (des documents) selon des contraintes bien précises comme le temps(date de dernière relecture, date de publication ).


3. Conclusion
Le cartable électronique® peut servir à une plate forme de création (dans le sens de réalisation) de collecticiels. Mais ça sera mieux si on construit un modèle générique du système sur le quel on peut savoir s’il peut servir à un support pour construire un autre système ou non. Comme ça on peut savoir dès le début si c’est possible ou non de construire notre système sur le cartable. Dans le cas où c’est difficile ou bien impossible, la cause c’est qu’il existe des règles non compatibles entre les deux systèmes. Donc on peut penser à un petit Analyseur de règles qui vérifie que les règles du système à implémenter ne s’oppose pas à celles déjà implémentés dans le cartable. Si il n’y a pas d’opposition (ou bien intersection) on peut dire qu’on peut l’implémenter mais il reste à vérifier les contraintes techniques !
https://www.univ-savoie.fr/Portail/Groupes/conferance/portal_contents


[1] Cartable : Le cartable électronique® de l’université de Savoie.

Répondre