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 1er 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, réclamez !
Des solutions de GED (Gestion Electronique des Documents) seraient probablement plus adaptées que drupal, le CMS (Content Management Sysytem, ou en français système de gestion de contenu) retenu pour cette première version de la forge. 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 vu le temps disponible, il était plus efficace de partir avec un CMS ayant déjà la plupart des briques nécessaires.
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 :
Et le gagnant est...
C'est ce cycle a deux états qui aura été retenu pour la v1 d'edulibre.org, pour privilégier la simplicité d'usage.