Des logiciels libres en bibliothèque

NB : Si vous n’êtes pas à l’aise avec les fondamentaux de l’open source, ce serait mieux que vous lisiez d’abord l’article Des petites choses que vous devez savoir sur l’open source.

Ça se répand comme une traînée de poudre ces temps-ci : les systèmes intégrés de gestion de bibliothèques (SIGB) comme Koha, Evergreen ou PMB séduisent de plus en plus de bibliothèques. En 2010, d’après librarytechnology.org, 12% des bibliothèques utilisaient des SIGB open source, et ce pourcentage augmente chaque année. Pourquoi ? Qu’est-ce que cela induit ?

Depuis 2008, les bibliothèques – comme bien d’autres structures – ont souffert de coupes budgétaires à cause de la crise financière. Et les SIGB sont un poste budgétaire important au sein d’une bibliothèque (en moyenne, le 2nd après les salaires). L’adoption de SIGB open source semble une bonne solution pour réduire les coûts : pas besoin de payer une licence d’utilisation chaque année, il est possible de modifier le code si nécessaire, on peut profiter des améliorations que d’autres bibliothèques apportent, et la philosophie de l’open source est assez séduisante quand on est étroitement lié à la circulation du savoir… Au premier regard, tout a l’air parfait et vous vous sentez prêt à sauter le pas.

Je suis désolée de vous dire ça mais s’il vous plaît, réfléchissez à deux fois. Les logiciels libres ont leurs faiblesses, eux aussi, et l’une des plus importantes est que vous aurez besoin de quelqu’un de compétent pour administrer votre SIGB. L’utilisation et l’administration d’un SIGB open source (en fonction de la taille de votre bibliothèque et du type de logiciel que vous choisissez) peut être un travail à plein temps. Vous aurez besoin que quelqu’un le fasse, et vous aurez besoin que cela soit fait sérieusement. Une simple mise à jour pouvant conduire au plantage du système complet, vous aurez besoin de faire des sauvegardes quotidiennes et d’avoir une connaissance basique du langage de programmation dans lequel votre SIGB libre sera codé (par exemple, Koha est en Perl).

Vous devez aussi vous préoccuper de vos usagers : ils se sont probablement habitués à l’interface de recherche de l’ancien SIGB, et ce ne sera pas facile pour eux de s’habituer à une nouvelle interface. Pensez aussi à ceux qui travaillent dans la bibliothèque, et surtout ceux qui utilisent le SIGB intensivement, par exemple les gens qui s’occupent des commandes et du pointage des revues. Peu importe qu’il soit open source ou pas : adopter un nouveau SIGB vous coûtera du temps et de l’argent. C’est une décision difficile à prendre.

Si vous pensez que vous n’avez pas déjà, en interne, quelqu’un de suffisamment compétent ou disponible pour administrer le nouveau SIGB que vous envisagez d’adopter, c’est peut-être le moment d’embaucher quelqu’un (un administrateur de systèmes d’information documentaires !). Si vous pensez que vous aurez besoin d’aide de temps en temps ou juste pour superviser la migration, rappelez-vous que certaines entreprises fournissent ce genre de prestations (vérifiez leurs références et faites jouer votre réseau professionnel pour fixer votre choix). Vous pouvez aussi décider de vous reposer sur la communauté d’utilisateurs, mais cela ne fonctionnera durablement que si vous appartenez à une petite structure et si vous pouvez vous passer de votre SIGB quelques jours (au cas où vous rencontreriez un problème sérieux).

Les projets libres reposent souvent sur l’efficacité de leur communauté – un bon projet a une communauté efficace avec un noyau dur de membres actif. Si vous choisissez une solution open source, pensez-y : vous ferez partie d’une communauté d’usagers, et le futur de votre SIGB reposera aussi (dans une certaine mesure) sur votre implication dans ladite communauté. Ne vous contentez pas d’appeler au secours quand vous rencontrez un problème : une bonne relation est basée sur la réciprocité.

Si vous êtes bibliothécaire-documentaliste ou informaticien, et si votre bibliothèque a effectué une migration d’un SIGB propriétaire vers un SIGB libre (ou si vous y songez sérieusement), merci de réagir à cet article pour nous faire part de votre expérience…

 

[SIBG Libres] Greenstone : du Libre pour les pays émergents

Geenstone est un quatrième « géant » libre, qui complète – et clôt – notre bref panorama. Greenstone, tout comme Koha, est à l’origine un projet néo-zélandais, plus précisément de l’université de Waikato. Son originalité est d’avoir ensuite été développé et distribué en collaboration avec l’UNESCO, dans le cadre de son programme de mise en place de logiciels libres pour combler le « fossé technologique » entre pays développés et pays émergents. Par ailleurs, c’est moins un SIGB qu’un logiciel destiné à faire de la GED.

Greenstone est distribué sous licence GPL, et dans un grand nombre de langues. Un effort tout particulier a été consacré à la traduction, afin de proposer une documentation complète en vietnamien et en kasakh. Le développement du logiciel se fait en collaboration avec des bibliothécaires et informaticiens des pays émergents d’Afrique, d’Asie et d’Amérique Latine, afin de répondre au mieux aux besoins de ceux-ci et de les intégrer au mieux dans la gestion de la feuille de route du projet. L’enjeu principal de Greenstone est d’encourager les pays émergents à mettre en place leurs propres bibliothèques numériques. On peut faire fonctionner en parallèle Greenstone et Koha (qui sont même disponibles ensemble sur un même CD) : Greenstone, qui sert essentiellement à faire de la GED, complète les fonctionnalités de Koha. Les deux logiciels, utilisés conjointement, permettent de créer et de gérer une bibliothèque numérique opérationnelle.

Si Greenstone peut également être utile dans une bibliothèque en Europe, son intérêt – et son originalité – tient aussi à ce qu’il a été développé par et pour les pays émergents, de manière transparente. En effet, la gestion de la connaissance et sa valorisation est un outil de développement considérable, qui peut jouer un rôle important dans la réduction du fossé entre « pays développés » et « pays émergents ».

Conseil de documentaliste :

Je vous conseille de lire l’excellent ouvrage de Ian H. Witten, David Bainbridge et David M. Nichols How to build a digital library, qui fournit non seulement de nombreux exemples de bibliothèques numériques et des études de cas, mais aussi une réflexion poussée sur ce qu’est une bibliothèque numérique et les nombreuses questions à se poser avant de se lancer dans un tel projet.

NB : Cet article appartient à une série d’articles sur les SIGB libres. Je les ai écrits en 2010 dans le cadre d’un travail universitaire, et ils ont fait l’objet de légères modifications avant la présente publication. Ils sont tous sous licence Creative Commons CC-BY-SA.

 

[SIGB Libres] OpenFlora, un logiciel propriétaire “libéré”

NB : Dans cet article, je prends position assez violemment, et risque de passer pour une intégriste du Libre. Je sais que le Libre peut servir de produit d’appel (un éditeur libère le noyau d’un logiciel, et dès que l’usager veut passer aux choses sérieuses, il doit payer pour des modules complémentaires qui sont indispensables). Je ne suis pas d’accord avec cette démarche, en tout cas pratiquée de cette manière. Vous êtes prévenus si vous désirez poursuivre la lecture de cet article.

OpenFlora, à l’instar des deux logiciels dont il a été précédemment question, est un SIGB 100% web. Mais son histoire est quelque peu différente. À l’origine d’OpenFlora, on trouve Ever Team, un éditeur de logiciels lyonnais dont la spécialité est plutôt le logiciel propriétaire, et dont les produits phares étaient depuis une vingtaine d’années les trois Flora : Flora Musée, Flora Archives et Flora Library.

Le 1er février 2010, donc très récemment, Flora Library a été « libéré », c’est à dire que son code a été rendu public et que la licence propriétaire a été troquée contre une licence CeCILL. Les deux autres Flora, moins répandus, restent des applications propriétaires. C’est pour le moins énigmatique, pour un éditeur de logiciels, de « libérer » ainsi son produit phare sans s’inscrire dans une démarche globale de passage au Libre. De plus, Ever Team affiche son intention de rester un éditeur de logiciel et de ne pas se transformer en prestataire de services, comme c’est le cas de PMB Services. Ever Team reste le mainteneur du logiciel, et garde le contrôle de la feuille de route tout en espérant compter sur la formation d’une communauté pour le développer. Mais alors, qui finance ? C’est là que le bât blesse.

OpenFlora, si la solution peut sembler séduisante au premier abord, profite du côté permissif de la licence CeCILL pour proposer, en plus du noyau libre, des modules propriétaires, dont le code reste bien caché. Vous voulez réaliser un import SUDOC sous OpenFlora ? D’accord, mais le module est propriétaire et payant. Vous voulez utiliser utiliser le protocole Z39.50 pour rechercher des informations dans vos bases de données ? Là aussi, il vous faut un module complémentaire payant. Et si vous voulez faire de la GED, gérer une sitothèque ou une photothèque, il vous faut encore des modules complémentaires payants. Pour couronner le tout, Ever Team encourage le plus possible l’usager à utiliser ses solutions hébergées : encore un SIGB par navigateur, paramétrable, personnalisable, mais surtout, dans les nuages… Ever Team s’occupe de vos donnés et de la maintenance, bien sûr. Et c’est payant.

OpenFlora, la fleur ouverte en latin, pouvait sembler s’être épanouie sous l’air du temps avec l’essor des logiciels libres (d’après François Élie, d’ici dix ans, il n’y aura plus de logiciels propriétaires, et c’est fort possible puisque même Microsoft se met à faire du Libre). Mais dès que l’on s’en approche de trop près, la belle fleur libre se referme. Ici, le passage au Libre, en plus de créer un « buzz » intéressant d’abeilles libristes autour de la jolie fleur, permet d’offrir un produit d’appel – qui, ne soyons pas mauvaise langue, conviendra peut-être à quelques bibliothèques – mais qui a pour enjeu principal de faire la promotion de modules complémentaires payants et de solutions d’hébergement, payantes elles aussi. « Le Libre est à la mode, faisons du Libre, mais sans revoir notre modèle économique : après tout, nous sommes un éditeur de logiciels riche de vingt ans d’expérience, pas un prestataire de services. »

Passée la déception de voir un logiciel a priori si prometteur, s’avérer en réalité un produit d’appel destiné à faire la promotion d’un éditeur de logiciel pas si libriste que ça, on peut réfléchir sérieusement à l’avenir d’OpenFlora, libre depuis bientôt un an. Que se passera-t-il probablement ? Un certain nombre de personnes paieront pour les modules complémentaires, certes, mais il y a fort à parier que d’autres préféreront payer pour le développement d’une nouvelle brique logicielle, sous licence libre cette fois, avant de la redistribuer. Et le logiciel finira, s’il est jugé assez intéressant pour être étudié et modifié, par échapper à Ever Team, qui devra soit s’adapter et proposer davantage de services, soit voir la belle fleur s’envoler, libre pour de bon. Car un logiciel, une fois libéré, ne redevient pas propriétaire : il disparaît, ou échappe, en un temps plus ou moins long, à ses concepteurs. Cela fait partie des règles du jeu.

Il est aussi tout à fait possible qu’Ever Team se serve du succès d’OpenFlora pour vendre Flora Musée et Flora Archives… Mais peut-on réellement se réclamer un éditeur de logiciels libres en continuant à se rémunérer grâce à des logiciels propriétaires ? Cela ressemble dangereusement à Microsoft qui, flairant la concurrence du Libre, se met brusquement à faire de l’Open Source, sans changer son intention de continuer à dominer le plus longtemps possible le monde de l’informatique.

Par ailleurs, Ever Team justifie la libération de Flora Library en parlant de l’impact de la crise économique, qui restreint les budgets des bibliothèques. Or, la théorie prouve – et l’expérience le confirme – que le passage au Libre, bien loin d’être gratuit, est coûteux – en temps, en formation, en prestations (il faut assurer la migration), en bugs (les SIGB libres présentent la particularité d’être souvent moins stables), en coûts de développement (il faut parfois financer directement les améliorations à apporter au logiciel et la correction des bugs, quitte à redistribuer par la suite ces modifications au profit de la communauté), etc. Il ne s’agit pas tant de faire des économies sur le coût des licences que d’apprendre à mutualiser, non seulement du côté du l’offre, mais aussi du côté de la demande.

Passer au Libre, c’est certes devenir dans une certaine mesure « propriétaire » de son logiciel, mais aussi assumer les coûts liés à cette propriété – puisqu’il n’est plus aussi facile de se retourner contre l’entreprise éditant le logiciel en cas de dysfonctionnement. Un bug, qui peut sembler très ennuyeux à un usager, peut ne pas l’être du tout pour la communauté – et l’usager mécontent ayant signalé le bug peut avoir la déconvenue d’entendre que la correction dudit bug n’est pas dans la liste des priorités, et que s’il désire que celui-ci soit corrigé, il n’a qu’à financer le débogage.

Évidemment, rien n’est jamais tout noir : OpenFlora est codé en Java.

NB : Cet article appartient à une série d’articles sur les SIGB libres. Je les ai écrits en 2010 dans le cadre d’un travail universitaire, et ils ont fait l’objet de légères modifications avant la présente publication. Ils sont tous sous licence Creative Commons CC-BY-SA.

 

[SIGB libres] PhpMyBibli : le premier SIGB sous licence CeCILL

À l’origine de PhpMyBibli (plus couramment appelé PMB), on trouve un seul passionné : François Lemarchand, qui était à l’époque (en 2002-2003) directeur de la bibliothèque d’Agneaux, une petite commune française d’un peu plus de 4000 habitants.

Dès 2003, le bibliothécaire a été rejoint dans le projet par un ingénieur informaticien, Eric Robert, qui était un libriste convaincu. Le “petit projet” commençait déjà à prendre de l’envergure. En 2003, d’autres développeurs ont rejoint le projet et ajouté un OPAC à PMB (qui était à l’origine plus orienté gestion). La même année, les trois développeurs principaux de PMB ont créé une société, PMB Services, destinée autant à améliorer le logiciel qu’à proposer diverses prestations aux bibliothèques décidées à l’adopter. Parmi les utilisateurs de PMB, on compte aussi bien des centres de documentation de collège que des grosses sociétés comme Orange. PMB est plutôt adapté aux bibliothèques, mais il peut tout aussi bien convenir à des petits centres de documentation. Il est d’ailleurs très utilisé par les professeurs documentalistes de l’enseignement secondaire.

La communauté francophone de PMB est nombreuse et réactive : on trouve de nombreux tutoriels en ligne, en particulier ceux d’Anne-Marie Cubat, qui accompagnent le nouvel utilisateur de PMB depuis la migration jusqu’à l’utilisation avancée du logiciel en situation professionnelle. Il existe aussi des listes de diffusion consacrées à PMB.

PMB a une histoire proche de ce que l’on peut appeler les « success stories du libre » : un passionné, déçu de ne pas trouver de logiciel adapté à ses besoins, développe son propre logiciel et décide d’en partager le code. Il fait des émules, le projet prend de l’ampleur et permet par la suite de voir émerger une structure économique d’un genre nouveau, basée non pas sur la vente du logiciel mais sur l’offre de prestations liées à celui-ci. La structure de PMB, en trois modules (module de gestion, OPAC et modules d’extensions) est certes liée à une volonté de structurer le logiciel, mais permet aussi de retracer son histoire : développement d’un logiciel de gestion de bibliothèque, puis ajout d’un OPAC et enfin effort en faveur de la modularité, grâce à la possibilité d’étendre et d’adapter le SIGB en lui ajoutant des briques logicielles.

Actuellement, on peut reprocher à PMB services de proposer essentiellement des solutions performantes de SAAS, ou Software As A Service (ou Cloud Computing), regroupées sous l’appellation générique « PMB hébergé ». Le développement de ces solutions semblent faire partie des préoccupations majeures de PMB Services, puisque la seule publicité que l’on voit sur leur site (elle se trouve en haut de la page, et reste visible quelle que soit la section visitée) est une petite animation destinée à promouvoir ces solutions « clé en main » de SIGB par navigateur. Or, qu’il s’agisse d’un logiciel libre ou non, le SAAS pose toujours des problèmes épineux… en plus de faire perdre partiellement le contact de l’usager avec son logiciel.

J’ai personnellement testé PMB, puisque lors de mon stage de licence, j’ai effectué une migration complète de Superdoc vers PMB au sein du centre de documentation d’un centre de rééducation. On m’a confié le choix du nouveau logiciel documentaire, et mon choix s’est porté sur PMB en raison de sa simplicité d’utilisation, la facilité de mise en place d’un OPAC sous PMB, l’importante communauté francophone de PMB, mais aussi le fait que PMB est en PHP / MySQL (il est toujours plus facile d’intervenir sur le code quand on connaît déjà les rudiments du langage…). Nous n’avons pas regretté ce choix, même si évidemment PMB n’est pas parfait (en particulier, les formats de sortie des résultats de recherche sont loin d’être visuellement aboutis). Nous avons été agréablement surpris par son interface, qui est vraiment ergonomique et agréable. De plus, j’ai eu l’occasion de faire appel à la communauté, et les “anciens” ont été présents tout au long du projet – une migration de rêve, en somme !

Je trouve PMB parfait pour un petit centre de documentation ou une bibliothèque municipale : il est léger, facile à prendre en main, ergonomique… En revanche, je pense que Koha est plus adapté pour les plus grosses structures.

NB : Cet article appartient à une série d’articles sur les SIGB libres. Je les ai écrits en 2010 dans le cadre d’un travail universitaire, et ils ont fait l’objet de légères modifications avant la présente publication. Ils sont tous sous licence Creative Commons CC-BY-SA.

 

[SIGB libres] Koha, le précurseur

Koha est le premier SIGB Open Source répertorié en tant que tel. Cela n’en fait pas pour autant un dinosaure, puisqu’il est en constante évolution et bénéficie d’une large communauté. Il a été adopté, entre autres, par le Service Commun de la Documentation de Lyon 3, le réseau des bibliothèques universitaires d’Aix-Marseille, l’École des Mines de Paris, l’Université d’Alaska…

À l’origine de Koha, on trouve la Horowhenua Library Trust, une bibliothèque de lecture publique néo-zélandaise qui avait peur de ne pas passer le bug de l’an 2000. Le prestataire retenu par la bibliothèque, Katipo, a su convaincre la HLT de publier le logiciel sous licence GPLv2. Cela explique le nom de Koha, qui signifie « don traditionnel » en Maori.

Par la suite, Koha s’est considérablement développé, en particulier sous l’égide de Paul Poulain, un développeur français qui contribue au développement de Koha depuis 2001 et a fondé en 2007 BibLibre, une société proposant du support aux bibliothèques désirant passer au Libre. Depuis 2000, de nombreuses sociétés supportent Koha, qui peut s’appuyer sur une très large communauté de contributeurs – essentiellement des professionnels, rémunérés par des entreprises ou des organisations. Koha est plutôt adapté aux très grosses bibliothèques, ce qui explique que l’on retrouve ce logiciel essentiellement dans les bibliothèques universitaires. La communauté francophone des utilisateurs de Koha porte le joli nom de KohaLa. La dernière version stable de Koha, Koha 3.6.0, a été publiée en octobre 2011 et comporte de nombreuses améliorations.

L’histoire de Koha montre comment un petit projet libre peut échapper complètement à ses créateurs et aboutir à un très gros logiciel reposant sur une large communauté – en avril 2010, Koha représentait tout de même 558966 lignes de code.

L’un des avantages de Koha repose sur le fait qu’il inclut des possibilités de paramétrage très avancées, qui permettent de l’utiliser aussi bien pour une très grosse bibliothèque universitaire que pour un petit centre de documentation d’entreprise. La dernière version de Koha intègre une partie des fonctionnalités du web 2.0 (possibilités de « tag » des notices par les utilisateurs, texte enrichi, relance des usagers par SMS, flux RSS, personnalisation de l’interface de recherche…). Il peut donc permettre de créer une communauté active autour de la bibliothèque. Par ailleurs, on peut noter le grand nombre de sociétés proposant du support pour Koha – ce qui laisse à une bibliothèque désirant effectuer une migration vers Koha une grande liberté dans le choix d’un prestataire.

Enfin, Koha est écrit en Perl, donc si vous êtes administrateur de SID et envisagez une migration vers Koha, il peut être pertinent de vous lancer (ou vous relancer) dans le Perl – c’est maintenant ou jamais !

NB : Cet article appartient à une série d’articles sur les SIGB libres. Je les ai écrits en 2010 dans le cadre d’un travail universitaire, et ils ont fait l’objet de légères modifications avant la présente publication. Ils sont tous sous licence Creative Commons CC-BY-SA.