Marlène's corner

J’ai assisté les 26 et 27 mai au 2ème symposium Koha organisé par l’association KohaLa à Lyon. Organisation remarquable, à mettre au crédit des collègues du SCD de Lyon 2 (à part la wifi qui n’a guère fonctionné, mais les collègues n’y sont pour rien). Contre toute attente*, 2 journées très riches d’interventions variées, laissant la part belle aux retours d’expériences et abordant des thématiques cruciales comme le rapport avec les fournisseurs dans le contexte du logiciel libre ou les changements organisationnels induits par le passage à Koha. Et des ateliers plus techniques (sur XSLT et SQL, et même une install party !) qui ont eu paraît-il un franc succès auprès des participants. Les diaporamas et les podcasts des journées seront bientôt mis à disposition sur le futur site du symposium, où l’on trouvera également celles de l’année passée. Juste quelques notes sur les conférences auxquelles j’ai assisté :
Travailler avec les professionnels du libre
Bon casting pour cette table ronde qui rassemblait P. Poulain pour BibLibre, R. Ganier pour Progilone et F. Aubriot pour PLOSS Rhône Alpes, animée avec pertinence par F. Elie, président de l’ADULLACT. Les points saillants que j’ai relevés :
– Le manque d’info sur les développements est un handicap pour les sociétés de services comme pour les bibliothécaires. L’exemple de mutualisation Lyon 2 / Lyon 3 / St Etienne fait figure d’exception, la plupart des bibliothèques déployées ou en cours de déploiement ne partage pas ses développements. Pour atténuer cette opacité, le mot d’ordre c’est la mutualisation : KohaLa pourrait être, sinon le lieu, du moins la caisse de résonance pour ce type d’information. L’AG de l’association qui a eu lieu en fin de journée a, du reste, validé la mise en ligne d’un annuaire des établissements déployés, enrichi de la liste des développements en cours ou prévus.
– Le manque de structuration de la communauté française : la communauté des utilisateurs est assez réduite et peine à collaborer, et l’investissement des bibliothécaires dans la communauté internationale est quasi-nul (c’est un prestataire, en l’occurrence Paul Poulain, qui fait le lien) ; on évoque la barrière de la langue, of course… mais il faudra bien définir, à un moment ou un autre, le rôle de chacun (bibliothécaires et prestataires)
– Le temps des marchés publics n’est pas adapté à l’évolution rapide des logiciels libres ; le passage du modèle de feature-based releases (on sort une nouvelle version une fois que toutes les fonctionnalités prévues sont prêtes) à une logique de time-based releases (on sort une nouvelle version selon une fréquence définie à l’avance, si les fonctionnalités ne sont pas prêtes cette fois, elles seront dans la version suivante), décidé par la communauté Koha (une nouvelle version tous les 6 mois), devrait être un atout pour les établissements. C’est toute l’économie de la maintenance des systèmes qui est en jeu derrière.
Les changements dans l’organisation du travail : Retours d’expérience du SAN Ouest Provence, des SCD de Lyon 2 et de Lyon 3
– La mise en place de Koha a induit une dynamique de « work in progress » au SAN Ouest Provence : démarche permanente d’apprentissage, d’évolution. Volonté d’être contributeurs du logiciel, et mise à disposition des ressources humaines nécessaires en informatique
– Accélération de la dématérialisation des procédures pour les acquisitions à Lyon 2, au prix d’une augmentation certaine du temps de traitement des commandes – les développements en cours pour St Etienne devraient améliorer les choses.
– Repérage de besoins en formation des personnels aux bases de l’informatique à Lyon 3 ; certaines fonctionnalités (relances, réservations, outils d’interactivité avec l’usager) soulèvent des questionnements chez les personnels et incitent à une réflexion sur une nouvelle organisation de certains services.
Des outils pour extraire des statistiques dans Koha : Birt (F. Barré, Lyon 2) et JasperReports (L. Prête, Progilone)
Birt et JasperReports sont 2 outils open source de création de rapports. Leur intérêt principal est qu’ils permettent d’agréger des données provenant de sources différentes (par exemple les prêts et les entrées) : on peut ainsi réaliser de véritables tableaux de bord pour suivre l’activité de tel ou tel secteur de sa bibliothèque. Les 2 ont une communauté d’utilisateurs assez active, Lyon 2 s’investit et proposera bientôt un mode d’emploi en français pour Birt. JasperReports peut être installé sur un serveur pour une utilisation mutualisée, Progilone développe l’intégration d’une connexion à JasperServer pour la BULAC.
Koha, d’un petit centre de doc à un grand SCD : Retours d’expérience à l’école d’architecture de Nantes (CERMA), au SCD de Lyon 2 et à la BM de Nîmes
3 établissements assez différents, qui reflètent bien la diversité des possibilités de Koha.
– Du travail mais pas de regret pour le laboratoire CERMA : malgré de nombreux problèmes de reprise de données (export manuel, pertes de liens entre les notices), le gain en ergonomie et en fonctionnalités est appréciable. Un investissement humain important est nécessaire, et beaucoup d’espoirs sont placés dans la communauté.
– Expérience positive de la coopération avec Lyon 3 et St Etienne pour Lyon 2 : les coûts ont vraiment été partagés, les compétences mutualisées, et l’organisation de formations ouvertes à tous les partenaires a permis de constituer un socle de connaissances commun. L’articulation avec des prestataires différents et des versions différentes de Koha, la difficulté de récupérer les développements des partenaires et de les intégrer dans la version de Lyon 2 constituent les principaux désagréments rencontrés ; au final le SCD a un outil qu’il maîtrise et qui représente une économie sur le long terme.
– Inscription du choix de Koha dans la stratégie informatique globale de la ville à Nîmes, avec un engagement de la DSI pour mobiliser les moyens nécessaires pour mener le projet à bien. Implication moindre de la DSI depuis le déploiement (changement de priorités), forte attente de la mutualisation avec les autres établissements pour les développements futurs.

Quelques réflexions plus globales pour terminer ce trop long billet :
– La nécessité de disposer d’un informaticien a été relevée par tous les intervenants (ce qui ne fait que renforcer une impression déjà évoquée sur ce blog) ; plus largement, la question des ressources humaines à mettre a disposition pour ce type de projet est cruciale (autour de 3-4 ETP pour les projets présentés, et cela ne semble pas suffisant)
– La mutualisation des développements est capitale : KohaLa va relancer une enquête pour constituer l’annuaire des établissements et de leurs développements évoqué plus haut.
– La synchronisation des calendriers de la communauté / des prestataires / des établissements reste une difficulté, que la publication des développements et/ou des cahiers des charges des uns et des autres permettra peut-être de contourner, au moins partiellement.

* J’avais je l’avoue quelques appréhensions : allais-je tomber en pleine convention de barbus mangeurs de pizza ou me retrouver dans une réunion Tupperware de Bisounours idéalistes ?
[photos : National Media Museum, satane]

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]

Une fois n’est pas coutume, 2 mots sur ce qui se passe en ce moment dans mon SCD : au bout de 2 ans de préparation, la migration est terminée, nous avons quitté Loris et nous sommes en production sur le logiciel de gestion de bibliothèque open source Koha. Nous ne sommes pas seuls dans cette galère aventure : il s’agit d’un projet inter-universitaire, qui aboutit à un catalogue commun aux 3 universités d’Aix-Marseille. En chiffres, cela représente 705 000+ notices bibliographiques, 1 200 000+ exemplaires, 78 000+ lecteurs potentiels, dans un réseau de 53 bibliothèques (BU et bibliothèques associées).
Notre installation fonctionne avec le système de carte à puce des étudiants et personnels déjà à l’oeuvre dans les universités, nous interrogeons les bases de gestion des scolarités et des personnels (Apogée / Harpège) au moyen de webservices, ce qui nous permettra, à terme, d’avoir une information à jour en quasi-temps réel.
Qu’en dire de plus ? Tout n’est pas encore complètement calé, mais on peut déjà faire l’essentiel : faire des prêts/retours, récupérer les données qui redescendent du Sudoc, cataloguer… Bref rien que de très normal pour un SIGB. Quelques « innovations » intéressantes cependant – pour ce que je peux en juger, n’étant pas utilisatrice du système – du côté de l’OPAC : on peut récupérer des fils RSS sur ses requêtes, les notices ont des URLs pérennes et tout ça est compatible avec Zotero.
Pour ceux que ça intéresse (?), nous sommes sur une version quelque part entre la 3.2 et la 3.4, les décors sont de Roger Harth et les costumes de Donald Cardwell notre prestataire technique est BibLibre et l’assistance à maîtrise d’ouvrage est assurée par Doxulting.
[photo : Violaine Bavent]