La version 3.2 de Koha vient d’être annoncée, Nicole Engard nous en liste les nouveautés. Je travaille pour ma part sur une version sans nom de Koha, quelquepart entre la 3.2 et la 3.4, qui intègre les développement faits pour Aix-Marseille, pour Lyon 3 et pour Nîmes. Ma brève expérience du sujet me laisse à penser que, si on veut vraiment travailler avec un logiciel libre, il faut en connaître les défauts aussi bien que les qualités. Donc j’ai fait une petite liste au père noël, non pas de défauts, mais juste de quelques unes des choses qui me semblent manquer dans le Koha actuel (enfin, uniquement pour les modules qui m’intéressent : OPAC, gestion des lecteurs, stats) et qui sont susceptibles d’intéresser d’autres utilisateurs (on ne sait jamais, si quelqu’un manque d’inspiration pour son cahier des charges) :
– une connexion à Electre : le webservice est développé côté Electre, mais pas côté Koha. Une fois ce développement en place, à nous les couvertures sans lien vers Amazon, les résumés et les tables des matières (moyennant un abonnement annuel, cela va sans dire)
– une fonction d’enrichissement des notices depuis plusieurs sources de données, paramétrable : à l’heure actuelle, si on active Amazon et Google Books en même temps, on voit bien que l’affichage n’est pas prévu pour ça. Et impossible de se connecter à une autre source que celles proposées. Or ce serait pas mal de pouvoir utiliser Electre pour la production française et une autre base pour la production internationale. Ou bien de se brancher sur les sommaires des revues qui disposent d’un fil RSS. Ou encore d’afficher des couvertures ou du contenu depuis une base de documents numérisés, etc.
– un module de gestion des tables de correspondances : si vous souhaitez utiliser les webservices d’Apogee et d’Harpège pour récupérer les données sur les lecteurs, préparez-vous à un gros travail sur les correspondances entre codes-étape, cycle de l’étape et j’en passe. Actuellement les modifications sont faites manuellement via un editeur pour geeks pas très convivial ; sachant qu’il y a pour une université moyenne entre 600 et 800 correspondances à faire, susceptibles de changer tous les ans, c’est un vrai besoin.
– un outil de gestion des listes : la possibilité de créer des dossiers et sous-dossiers, mais aussi un moyen de gérer la durée de vie de la liste. En cas d’utilisation « massive » de cette fonction – et c’est possible, ça fait partie des services « vendeurs », j’ai testé auprès des chargés de TD – il va être vite difficile de s’y retrouver…
– idem pour les statistiques : il faut pouvoir organiser les rapports statistiques SQL dans des dossiers et sous-dossiers, sous peine de perdre en lisibilité. Parce qu’il faut bien le reconnaître, beaucoup de données sur les notices passent par des requêtes SQL.
– une séparation plus claire de ce qui est public et de ce qui ne concerne que les professionnels : actuellement les listes, les formats d’export sont communs – ce qui peut rendre la présentation à l’OPAC quelque peu confuse pour l’utilisateur.
[photo : David Reeves]
Marlène's corner 