Archive for the 'Open source' Category

Le marché du mardi, n°46

Vite fait, parce que c’est la saison des grands ménages mais aussi les vacances :-), un sélection d’outils open :
Annotum est une extension de Worpress qui permet d’en faire un outil de publication scientifique.
Showme : une plateforme ouverte de vidéos pédagogiques, sur toutes sortes de thèmes (art, musique, langues, sciences…)
CASH Music : une plateforme open source de publication en direction des artistes
– Il n’y a pas que Zotero dans la vie : il y a aussi Mendeley, et voici une série de tutoriels vidéo en français.
F1000Research : open peer-review, publication rapide, datasets, révisions, multi-format, le tout sous licence CC ; bref, un nouveau projet éditorial à suivre.

Publicités

Symposium Koha 2011

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]

Il faut des développeurs en bibliothèque

Dans Why Not Grow Coders from the inside of Libraries?, Bohyun Kim (Library Hat) s’interroge sur le manque de compétences techniques en interne dans les bibliothèques :
« Ca ne serait pas génial si chaque petite bibliothèque disposait d’un développeur en interne ? On utiliserait tous des logiciels open source, avec des fonctionnalités sur-mesure, correspondant exactement à nos projets et aux besoins de nos communautés d’utilisateurs. Les bibliothèques deviendraient alors des consommatrices de technologie réellement avisées, et plus de simples clientes à la merci de systèmes bancals. Et même, cela les re-positionnerait en tant que contributrices des technologies permettant au public d’accéder à l’information et aux ressources scientifiques. Je suis sûre qu’aucun bibliothécaire n’aurait d’objection à cette proposition. Mais en ces temps de restrictions budgétaires continues, conserver du personnel de bibliothèque est un défi en soi, alors engager un développeur…
Mais pourquoi devrions nous en passer par là ? Les bibliothécaires sont sans doute les professionnels les plus compétents techniquement après les informaticiens, les scientifiques, les ingénieurs et les personnels du marketing. Alors pourquoi n’y a-t-il pas plus de bibliothécaires qui codent ? Pourquoi n’assistons nous pas à un déferlement de bibliothécaires-développeurs ? Après tout, nous vivons à une période où le web est la plateforme sur laquelle se déroulent pratiquement toutes les activités humaines, et où les bibliothèques changent leurs noms pour des appellations comme « learning centers ». Développer ne me semble pas trop compliqué ni trop difficile à apprendre pour n’importe quel bibliothécaire, quel que soit son parcours. Les bibliothèques proposent aujourd’hui un large éventail de ressources et de services en ligne, et déploient et utilisent de nombreux outils, du SIGB au système de gestion électronique de documents, qu’elles pourraient certainement utiliser avec un grand profit des personnels capables de développer. »
[…]
Pour elle, le problème vient en partie du fait que les compétences informatiques ne sont pas suffisamment valorisées au sein des établissements, qui ont tendance à recruter uniquement en dehors des bibliothèques. Alors que, ce type de compétences s’acquérant souvent en auto-formation, sur le temps personnel des agents, ce sont généralement des personnes motivées, qui pourraient apporter un vrai plus. A cela s’ajoute le fait que, quand elles existent, ces compétences sont utilisées de façon fragmentaire : rares sont les bibliothécaires qui développent à plein temps. En filigrane, il y a aussi la question de la formation : les vagues notions de html survolées dans la plupart des cursus initiaux ne font pas des codeurs aguerris…
Le sujet devient plus brûlant pour les bibliothèques qui utilisent des logiciels libres – il a été abordé lors d’une session la dernière conférence Code4lib consacrée à l’open source en bibliothèque  :
« Les participants [à la conférence] habitués à travailler avec des logiciels libres étaient unanimes sur le fait que l’adoption du libre n’est pas bon marché. On croit souvent à tort qu’en adoptant des logiciels libres, les bibliothèques vont faire des économies. Mais, si c’était le cas, cela ne serait pas à court terme. Le libre nécessite d’avoir en interne du personnel technique formé, capable de bien comprendre le fonctionnement des logiciels pour tirer avantage de leur flexibilité au profit de leur établissement. Ce n’est pas du gratuit prêt à l’emploi qui démarre au quart de tour. Adopter les logiciels en open source donne certes aux bibliothèques une certaine liberté pour expérimenter et améliorer leurs services, et de fait les rend plus autonomes, mais les bénéfices ne viennent pas sans investissement. On peut alors se demander pourquoi les bibliothèques n’utiliseraient-elles pas, simplement, les services de sociétés tierces assurant le support de systèmes ou de logiciels libres. Mais sans la capacité à comprendre le code source, et les méthodes pour le modifier selon ses propres besoins, comment les bibliothèques pourraient-elles exploiter le potentiel du libre ? Et parvenir à des relations plus cordiales entre bibliothécaires et vendeurs ? »
[photos : rezponze]

Ce qu’il manque à (« mon ») Koha

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]

Koha de neuf ?

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]

Gaffe aux données

Dans ce post du koha blog, Owen Leonard donne quelques conseils aux bibliothèques qui se lancent dans les SIGB libres en externalisant leur hébergement (il parle de Koha, mais à mon avis cela vaut pour les autre systèmes aussi) :

Insistez pour avoir accès à votre base de données : vous êtes propriétaires de vos données (des lecteurs aux autorités), vous devez pouvoir y accéder à tout moment (pour faire des sauvegardes complémentaires par exemple, ou les tester sur un autre système).

Ne vous limitez pas aux données : intéressez-vous à toutes les procédures mises en place par votre prestataire autour de la base de données (tout ce qui tourne autour des imports notamment, et des mises à jour : toutes ces opérations que l’on ne voit pas et qui sont pourtant primordiales pour le bon fonctionnement du système) – infos qu’il me semble indispensable d’avoir quelquepart, même quand on héberge son SIGB localement.

Exigez que les développements que vous financez soient reversés à la communauté, histoire de ne pas vous retrouver coincé avec un système que seul votre prestataire maîtrise, ce qui rend les choses beaucoup plus compliquées le jour où vous décidez d’en changer. Si les développements vous sont spécifiques – ça peut arriver – là aussi, avoir une documentation complète à portée de clic sur ce qui a été fait est essentiel.

Travailler autrement

« Nous devons apprendre de nouveaux modes de travail si nous voulons maximiser la valeur de Koha dans nos organisations :

– Réfléchissez en fonction de ce que VOUS voulez, et pas de ce qui existe

– Apprenez les compétences de base de l’administration du système, et prenez la responsabilité du paramétrage de Koha pour qu’il soit conforme à ce que VOUS voulez

– Devenez à l’aise sur un outil de réseautage comme irc

– Apprenez à identifier, à décrire et à signaler les bugs, puis à tester les corrections

– Dites-vous « et si… ? » – et proposez des suggestions d’améliorations

– Puis rejoignez la conversation au sein de la communauté, pour vous assurer que les développeurs aient bien compris ce que vous vouliez, et réfléchissez au moyen de l’inclure dans la branche de développement principale

– Trouvez un développeur pour réaliser ce dont vous avez besoin si vous même n’êtes pas programmeur

– Apprenez à demander de l’aide et à en donner aux autres

– Partagez vos analyses et réflexions, vos trucs et astuces et vos supports internes (comme des tutoriels ou des vidéos)

– Devenez un adepte du travail collaboratif sur les wikis

– Financez des développements pour la communauté, sans les garder égoïstement pour vous-mêmes

– Et co-financez des développement conséquents avec d’autres organismes pour en partager les coûts, et que cela bénéficie à tout le monde ».

Ce sont les suggestions que Joann Ransom propose aux bibliothécaires qui se lancent dans l’aventure du libre avec Koha dans Users vs developpers : not in my universe ! Elle souligne la nécessité de sortir de la relation traditionnelle client-vendeur – pourtant si confortable – pour que les bibliothécaires arrivent à reprendre le contrôle de leur outil de travail. Il me semble qu’en France, on est loin de certains points de cette liste (passer à IRC après des décennies de messagerie, c’est pas gagné…), mais on se rapproche d’autres (le SUDOC a amené une certaine forme de travail collaboratif, au moins parmi les catalogueurs). Ce qui me paraît crucial ici, c’est le fait de savoir ce que nous voulons : finalement, avons-nous jamais réfléchi à ce que devrait être notre SIGB idéal ? Ne nous contentons-nous pas bien souvent de reproduire à l’identique les spécifications du système précédent dans nos cahiers des charges de réinformatisation ?

[photo : LuChOeDu]


novembre 2017
L M M J V S D
« Sep    
 12345
6789101112
13141516171819
20212223242526
27282930  

Archives

Licence

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution 3.0 France.