Archive for the 'SIGBs generally suck' Category

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]

Publicités

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]

Chef de projet, retour d’expérience

J’ai été chef de projet pour la ré-informatisation de mon SCD pendant 2 ans, et vu que j’ai un peu galéré pour trouver des infos sur ce type de mission, je me dis que mon expérience pourra être utile à d’autres (je ne dis pas que j’ai tout fait correctement, hein, j’en suis souvent bien loin, même).

Se renseigner
Autant le dire tout net : les livres sur « le rôle du chef de projet dans la cadre d’une réinformatisation », ça n’existe pas 🙂 – il n’existe pas non plus grand chose sur l’administration des SIGB en général, entre parenthèses (juste ça et ça). Côté articles ou blogs, la pêche n’est pas terrible non plus, même à l’étranger – il y a une niche à prendre, là, c’est sûr 😉
Finalement, les avis les plus judicieux m’ont été prodigués par des chefs de projet dans d’autres domaines que le mien.

Bien s’entourer

Il faut le savoir : dans la fonction publique, vraiment n’importe qui peut être nommé chef de projet, pas forcément quelqu’un qui connaît à fond techniquement tous les aspects du projet. Pas de panique : ce que l’on attend de vous, c’est que vous coordonniez les différentes actions et étapes du projet. Personne ne vous demande de tout savoir, mais à vous de constituer votre équipe avec des gens qui, eux, sont hyper-compétents techniquement et/ou ont une bonne connaissance des pratiques professionnelles locales. Et une fois qu’ils font partie de l’équipe, leur faire confiance, et ne pas hésiter à déléguer.

Organiser le bal

Pas question de se laisser porter par le mouvement : en réunion, le chef de projet est là pour mener la danse ; il arrive avec un ordre du jour, prend note des demandes et suggestions, et se charge généralement de la rédaction des compte-rendus. Pour les tests, il explique aux testeurs ce qui est attendu d’eux, dans quel délai, sous quelle forme. Il prend également en charge la logistique des formations.

Elle fait rien qu’à rapporter
A toutes les étapes du projet, il faut prévoir un récapitulatif régulier pour sa hiérarchie bien sûr, mais aussi pour les collègues : le projet existe, il y a des agents qui travaillent dessus, il faut que ça se sache, que ça fasse partie du paysage commun, du contexte global du service. Ca permet aussi de rassurer à propos des éventuels retards, et de motiver les équipes, de les impliquer dans la mise en place de ce nouveau système qui, après tout est quand même leur futur outil de travail…
Autre tâche du chef de projet : recueillir les retours des testeurs, et rapporter les bugs au prestataire… Nous utilisons un outil libre pour le suivi des problèmes rencontrés lors de l’utilisation du système (les bugs, quoi) :  on ouvre un ticket à chaque fois que l’on veut signaler un bug, un manque ou suggérer une nouvelle fonctionnalité.

Documentez, documentez, il en restera toujours quelque chose

Parce que chef de projet, c’est une mission temporaire, il faut documenter le plus possible les choix qui sont faits, en terme de paramétrages particulièrement, mais pas seulement : avoir un historique du projet, avec les compte-rendus des réunions, mais aussi les notes et autres synthèses intermédiaires qui auront été produites, sera précieux à la personne qui prendra en charge l’administration quotidienne une fois le système passé en production – qui peut être une personne différente du chef de projet.

Facile à dire, mais pas à faire

Je vois plusieurs écueils pouvant guetter le chef de projet en herbe – à ce que j’ai entendu dire, hein 😉 :

– trop s’investir dans le projet : on en rêve la nuit, quand on arrive à dormir ; on prend les remarques des collègues pour des critiques personnelles – et on finit déprimé et fatigué

– travailler en solo : on ne délègue rien, on communique au minimum – et tout le monde vous tombe dessus lors du passage en production.

– être chef de projet sur le papier, mais chef de rien en réalité : les décisions sont prises ailleurs, la communication vous échappe, vous passez pour un(e) imbécile.

Du suivi

Une ré-informatisation c’est un peu comme la construction d’une maison : il faut suivre tout les corps de métier sous peine d’accumuler erreurs et retards. Et comme en général « votre » projet n’est qu’un projet parmi d’autres pour vos « partenaires » (DSI, scolarités, prestataires), il vous faut relancer les uns et les autres pour que le chantier avance correctement.

Des outils qui aident

  • Freemind (ou tout autre outil pour faire des cartes heuristiques) pour y voir clair dans ce qui est fait / ce qu’il reste à faire.
  • Un outil de reporting comme Mantis, pour alimenter le workflow de tous les bugs et autre problèmes techniques.
  • Des wikis pour mettre en ligne toute la documentation, les tables de correspondance, les supports de formation etc – pour être sûr d’avoir toujours la version la plus à jour (je suis toujours contente de PBworks, mais on travaille aussi avec Dokuwiki).

Est-ce que ces remarques s’appliquent aussi au rôle d’administrateur du SIGB ? Est-ce que c’est plus simple, ou plus compliqué ? Il est trop tôt pour vous le dire, on verra à la fin de l’année universitaire…

[photo : fotemas]

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]

Appel à témoignage

Vous qui avez déjà vécu une réinformatisation (comme chef de projet ou comme simple participant), ça vous dirait de partager vos suggestions, vos astuces, vos erreurs sur la gestion du projet (je pense particulièrement à tout ce qui a trait à la formation des personnels et à la communication vers le public) ?

Si oui, envoyez-moi à l’adresse habituelle (@gmail) les « plus » et les « moins » de vos expériences passées ou en cours, je ferai une synthèse sur la liste ici même, promis !

OPAC is (really) dead

« Jane Burke, VP de Serials Solutions, a décrit comment les ressources électroniques éloignaient de plus en plus les bibliothèques de leurs usagers dans le processus de recherche. Et sa conclusion fut, sans équivoque, que « le modèle traditionnel d’utilisation de la bibliothèque est fini », et que « l’OPAC est vraiment mort ».

Des études de ProQuest, d’Ithaka, d’OCLC et d’autres montrent que l’OPAC n’est plus le premier outil de découverte ou le point de départ des recherches. Les dépenses des bibliothèques portent désormais en priorité sur les ressources électroniques, mais les OPAC couvrent moins de la moitié de ces ressources – ils excluent les articles de revues et les projets de numérisation des collections spécialisées.

La perception des usagers de la valeur et de la qualité de la bibliothèque reste très forte, remarque Burke. Cependant, les étudiants ont des difficultés à naviguer entre des douzaines d’interfaces et de stocks de contenus. Le point d’entrée le plus simple pour une recherche, c’est Google, qui, selon de nombreux enseignants, est la source du déclin de la qualité du travail de recherche fait par les étudiants. La solution ? « Accepter le nouveau modèle de recherche, » suggère J. Burke. « Accepter un risque à court terme pour éviter une désintermédiation à long terme, laisser tomber nos règlements, et simplifier les choses. »

Extrait de E-access changes everything, compte-rendu dans Library Journal de la Charleston Conference de novembre dernier, par Carol Tenopir.

[photo : Brave Heart]


juin 2019
L M M J V S D
« Avr    
 12
3456789
10111213141516
17181920212223
24252627282930

Archives

Licence

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