edulibre.org

Ce site utilise Drupal pour l'instant, mais ce n'est pas un choix définitif.

Ce forum est là pour discuter des fonctionnalités utiles ou indispensables au fonctionnement d'un site d'échange de contenus pédagogiques libres.

Cahier des charges

Voici un 1^er cahier des charges « idéal » :

• Deux parties du site, l'une publique avec des ressources validées (par un "comité de validation" ou un "collectif éditorial", l'assentiment du plus grand nombre des utilisateurs...), l'autre privée avec une fonction de "forge" et des ressources en construction ou en attente de validation.
• Gestion de plusieurs espaces (par discipline par exemple) avec des utilisateurs et groupes ayant des droits distincts sur ces espaces (un utilisateur peut avoir les droits pour administrer un espace et n'avoir que des droits de lecture sur un autre espace).
• Possibilité de notification automatique des changements, pour des utilisateurs ou groupes d'utilisateurs (suivant les contenus modifiés).
• Possibilité d'avoir un forum attaché à chaque ressource suivant son stade de validation (un forum entre contributeurs pendant l'élaboration, un forum entre membres pendant la validation, et un forum public pour les ressources publiées, pour les retours des utilisateurs.
• Gestion des différentes versions d'une ressource ET de ses variantes (une même ressource initiale donne souvent lieu à plusieurs variantes suivant les niveaux et les contextes d'utilisation). Gestion des dépendances également (une ressource peut dépendre d'une autre, ou bien d'une ressource extérieure non libre de droits que l'on ne peut incorporer directement).
• Possibilité d'évaluation d'un contenu suivant différents critères (rigueur scientifique, pertinence pédagogique dans un contexte donné, etc.). La liste de ces critères reste à établir par les utilisateurs.
• Gestion des metadatas dublin core, LOM et LOMfr, indispensable pour l'indexation par les moteurs de recherche spécialisés.
• Exposition des metadata via un dépôt AOI-PMH (Open Archives Initiative - Protocol for Metadata Harvesting), pour que d'autres moteurs de recherches spécialisés (comme Correlyce) puissent venir "moissonner" les metadata des contenus d'edulibre et les proposer dans leurs résultats de recherche.
• Export de chaque ressource dans un zip regroupant les fichiers joints, la description et tous les metadatas associés. Si possible, export SCORM également.
• Moteur de recherche étendu (en texte intégral et/ou sur certains metadatas)
• S'il vous semble qu'une fonctionnalité importante manque, décrivez-la dans vos commentaires.

Compte tenu des compétences de l'administrateur actuel du site, une application en php serait plus appropriée.

Drupal (http://www.drupal.org/) n'est peut-être pas le CMS (Content Management System, ou système de gestion de contenu) idéal pour gérer cela, mais il me semble le plus adapté (Joomla est un concurrent mais j'ai du mal à m'y retrouver ; ezPublish concurrence drupal, mais je trouve le code plus long à comprendre, et je n'aime pas trop le "pseudo-langage" de templates ; Moodle gère mieux les métadatas mais est plutôt destiné au e-learning ; plone est aussi très extensible mais c'est du python et je maîtrise nettement moins).

Des solutions de GED (Gestion Electronique des Documents) seraient probablement plus adaptées que les CMS ci-dessus. Parmi elles, deux ECM (Enterprise Content Management, ou gestionnaire de contenus d'entreprise) ont retenu mon attention, Nuxeo et Alfresco. Ces solutions ont l'inconvénient d'être beaucoup plus lourdes (java+openOffice+...), demandent un serveur dédié plus solide (1Go Ram mini), même pour démarrer. Ils ont également l'avantage d'être de "vraies" solutions de gestion de documents (fichiers divers et variés), avec des solutions éprouvées de gestion de repository (JSR-170 et Jackrabbit pour ceux à qui cela parle), des possibilités d'accès hors interface web (avec Webdav par exemple), etc. mais demandent de solides connaissances java, et pas mal de temps d'apprentissage et d'adaptation (alfresco paraît plus simple "out of the box", mais nuxeo semble plus modulaire).

Par ailleurs, scenari (http://scenari-platform.org/) est un outil de gestion de chaînes éditoriales et paraît également intéressant. Il serait adapté à la production des ressources mais moins pour le côté gestion des ressources et de leurs relations.

Sinon, il reste la solution de tout développer, en utilisant un framework adapté pour accélérer les choses, mais je doute de trouver le temps nécessaire (j'ai étudié les ezComponents, mais ça demande quand même un développement conséquent).

Toutes les fonctionnalités listées ci-dessus ne sont pas obligatoires pour une v1, mais il faudrait quand même un minimum de simplicité d'utilisation (gestion des contributions, échanges entre membres, etc.) et la gestion du stade d'élaboration (brouillon, en attente de validation, publié).

Si vous avez d'autres idées... n'hésitez pas à les partager !

Cycle de validation des ressources

Ce schéma retrace le cycle de validation d'une ressource :

(pour le "cycle de vie" des ressources, il y a un schéma simplifié)

il distingue 3 rôles, mais ces rôles peuvent correspondre aux même personnes.
Auteur : la personne qui crée la ressource sur la forge, mais on peut très bien imaginer qu'un membre injecte une nouvelle ressource dans la forge dont il n'est pas l'auteur (si la licence du contenu le permet), ce dernier étant bien sûr crédité.
Contributeur : toute personne qui participe au processus d'élaboration de la ressource, qui complète les métadatas (mot-clés, niveau, disciplines concernées, etc...), qui modifie le contenu, etc.
Membre : toute personne ayant un compte sur edulibre. Vu dans ce schéma comme quelqu'un qui peut accéder à une ressource pour l'évaluer, même s'il n'a pas participé à son élaboration. Concernant les notifications, on peut imaginer que chaque membre choisit d'être prévenu lorsqu'une ressource de tel niveau(x)/discipline(s) est finalisée.
Validateur : personne ayant le droit de publication sur les ressources en attente de validation. À terme, on peut imaginer un processus automatique (plus de x% des membres ayant testé la ressource approuvent la publication et personne ne s'y oppose), mais c'est assez compliqué à mettre en place et pas prioritaire, cela sera donc probablement un "humain" au début (mais même avec un processus automatisé de publication, un "administrateur" pourra toujours modifier le choix automatique).

Cycle de validation à trois états

Mais lors de l'état "En cours de validation", faut-il autoriser les modifications de la ressource ou pas ? La logique voudrait que ce stade soit réservé à la discussion sans modification (pour que tout le monde parle de la même chose), mais en cas de modification demandée "mineure" (correction de coquille ou amélioration de style), ce serait lourd de devoir retourner en "brouillon" pour corriger et revenir "En cours de validation" (avec notification de chaque personne potentiellement concernée, et remise à zéro du flux de commentaires précédents) ensuite. Le problème revient alors à distinguer une modification "mineure", ce qui est forcément très subjectif...

Cycle de validation à deux états

Pour régler ce problème de l'état "En cours de validation", on peut imaginer seulement deux états, "brouillon" et "publié", en ajoutant une notion de "complet" ou pas. Une ressource deviendrait "complète" lorsque tous les champs obligatoires (titre, auteurs, mots-clés, discipline(s), niveau(x)... sont complétés. Lorsque la ressource est complète, et que les différents contributeurs l'estiment prête pour publication, l'un d'entre eux peux activer l'état "finalisé" qui déclenche la notification des personnes potentiellement concernées (qui ont demandé à être prévenu lorsqu'une ressource de même discipline(s)/niveau(x) était finalisée).

Cela correspondrait au schéma suivant :