2. Mutualiser le SIGB : l'expérience Koha

Soumis par cvigneault le jeu 05/01/2017 - 11:27

 

 

La convergence des pratiques de coopération à l'œuvre dans les bibliothèques et des valeurs de partage du monde du logiciel libre peut être vue comme une évidence, et cette évidence s’applique à des réalités dont la mise en œuvre peut prendre des aspects variés. Cette contribution en décrira un certain nombre.

Les logiciels libres et les bibliothèques : des valeurs communes


Pour reprendre la définition de la Free Software Foundation, « logiciel libre » désigne les logiciels qui respectent la liberté des utilisateurs. « En gros, cela veut dire que les utilisateurs ont la liberté d'exécuter, copier, distribuer, étudier, modifier et améliorer ces logiciels »11., ce qui encourage les pratiques de coopération et d'échange au sein de « communautés » de développeurs et d'utilisateurs.

Dans le monde des bibliothèques, S. R. Ranganathan22., bibliothécaire indien, est célèbre pour avoir énoncé, en 1931, cinq lois aujourd'hui rattachées à son nom, et que Mentor Cana a transposées au monde du logiciel libre.

 

Tableau 1. De la bibliothéconomie aux logiciels libres : les 5 lois
S. R. Ranganathan (1931) Mentor Cana (2003)
Les livres sont faits pour être lus. Les logiciels sont faits pour être utilisés.
À chaque lecteur son livre. À chaque utilisateur, son logiciel.
À chaque livre son lecteur. À chaque logiciel, son utilisateur.
Épargnons le temps du lecteur. Épargnons le temps de l’utilisateur.
Une bibliothèque est un organisme en constante évolution. Une bibliothèque de logiciels est un organisme en développement.

Les bibliothèques vont, à partir de 1999, mettre en pratique ces principes en participant à la création puis au développement du premier SIGB libre, Koha.

 

Koha, émergence d'une communauté


Koha est un SIGB développé fin 1999, par la société néo-zélandaise Katipo, à l'initiative d'un réseau de bibliothèques rurales, dont le système propriétaire risquait de ne pas passer l'an 2000.

Émergence d'une communauté

Le code fut déposé en open source sur le site de gestion de développement < https://sourceforge.net/> le 21 décembre 2000, 16 jours plus tard le premier commit33. extérieur est fait : c'est le point de départ de la communauté Koha.

Dans cette communauté44., le travail de développement, de signalement des bugs, de correction, de traduction et de documentation, mais aussi d'installation et de formation se partage entre contributeurs bénévoles ou participant dans un cadre professionnel (par exemple un bibliothécaire) et contributeurs tiers rétribués par les établissements demandeurs, appartenant à une entreprise de type société de services en logiciel libre (SSLL)55..

Prééminence des outils communautaires en ligne

Les premiers outils de partage sont mis en place dès le départ : site web, liste de discussion, gestionnaire de code, ils ne feront que se multiplier et s'affiner.

Parallèlement, une structure informelle émerge, basée sur la cooptation, répartissant les rôles de responsabilité, afin d'optimiser le travail des contributeurs répartis dès le départ dans le monde entier.

En 2015, la communauté se dote d'un International Koha Fund Committee destiné à récolter des fonds pour le financement de projets trop coûteux pour être pris en charge à une échelle locale ou concernant autre chose que de simples fonctionnalités.

Un outil international et mature

Koha, au départ assez basique et orienté vers la lecture publique, répond aujourd'hui aux standards internationaux de la profession grâce au travail partagé de nombreux développeurs, testeurs, traducteurs ou simples utilisateurs rapportant des bugs ou proposant et finançant des améliorations.

Avec plus de 30 traductions complètes pour l'OPAC et 70 moins abouties, Koha a été adopté par au moins 3 500 bibliothèques66.dans le monde entier et la France est assez bien représentée.

La situation française

En France, les premières installations ont lieu en 2003. Aujourd'hui, plus d'une centaine d'établissements l'utilisent et trois SSLL proposent leurs services et leur offre de prestations, tout en participant activement à la communauté.

La communauté française est structurée au sein de l'association KohaLa, depuis 2007, et a su développer ses propres outils et pratiques de coopération.

Tableau 2. Koha : les outils de la coopération communautaire
Type d'outils International / francophone
Dépôt du code et gestion des versions  < http://git.koha-community.org/gitweb/ >
Signalement des bugs < https://bugs.koha-community.org/bugzilla3/ >
Plate-forme de traduction < http://translate.koha-community.org/ >
Site web < https://koha-community.org/ >
Wiki < https://wiki.koha-community.org/wiki/Main_Page >
Documentation < https://koha-community.org/documentation/ >
Listes de discussion < https://koha-community.org/support/koha-mailing-lists/infos-subscribe[@]koha-fr.org >
Rencontre annuelle < https://koha-community.org/kohacon/ > `
< http://koha-fr.org/content/symposium >f
Messagerie instantanée (chat) < http://irc.koha-community.org/koha/ >
< http://webchat.freenode.net/ >
Réunion de développement Hackfest : 1 fois par an, en France

La mutualisation au sein de la communauté nationale ou internationale n'est pas la seule possibilité de travail coopératif autour de Koha, celui-ci peut se faire à d'autres échelles et avec des objectifs plus resserrés.

Mutualisation ponctuelle autour d'un développement

Deux établissements souhaitent faire réaliser un même développement : ils peuvent en mutualiser les différentes étapes, de la conception au déploiement.

Nous prendrons les exemples des bibliothèques de Nîmes et de la Médiathèque intercommunale Istres Ouest Provence (MIOP) d'une part et du SCD de Limoges et la Bibliothèque francophone multimédia (Bfm) d'autre part.

Toutes ont fait indépendamment le choix de Koha et se sont engagées dans la contribution au développement de Koha.

L'implémentation du Webservice Babelthèque

Pour le projet MIOP/Carré d'Art, concernant l'intégration du Webservice Babelthèque77.dans l'interface Koha, la mise au point du projet est faite entre mai et octobre 2011 pour une ouverture effective du service à mi-janvier 2012.

La conduite de projet collaborative est partagée entre deux maîtres d'ouvrage : Ouest Provence/Nîmes et la réalisation commune à deux maîtres d'œuvre : Babelio/Biblibre.

Après deux réunions entre les chefs de projet, ayant permis une expression fine des besoins et une réunion avec les acteurs sur la faisabilité du projet, le cahier des charges est rédigé collaborativement, puis un devis demandé.

Une prestation de développement est commandée, sous forme d'un bordereau des prix unitaires (BPU), par chacun des partenaires, pour moitié du montant total. Après implémentation locale, en janvier 2012, le Webservice est rendu disponible dans la version communautaire 3.8, en avril 2012.

Coopération croisée à Limoges

Pour les bibliothèques de Limoges, les conditions de départ ont été la simultanéité du déploiement de Koha, les mêmes choix techniques (SolR)88.et une même version. Un accord s'est fait sur deux développements portant sur la structuration des rapports et l'amélioration de la gestion des périodiques. Les spécifications d'un développement sont écrites par l'un et revues par l'autre, avec une clause sur le déploiement des développements dans les deux établissements et leur intégration dans une version communautaire. Après une première évaluation, un devis est demandé pour chacun des développements et un bon de commande émis par chacun des établissements.

Le reversement ne se fera pas, la branche SolR n'ayant pas été intégrée dans la version communautaire.

La collaboration ne s'est pas poursuivie par la suite, de nombreux changements de personnel ayant affecté les responsables du SIGB dans les deux établissements.

Les conditions du partage

Dans ces deux exemples, on peut noter l'importance d'avoir une version identique et un prestataire commun, le même intérêt pour les développements envisagés. L'entente et une relation horizontale entre les partenaires sont également des éléments favorables.

Il faut aussi souligner la nécessité de la clause sur le reversement dans une version communautaire, seule garantie que le travail financé bénéficiera au plus grand nombre d'utilisateurs.

Afin de favoriser ces coopérations inter-établissement, l'association KohaLa a mis en place depuis 2016 une plate-forme de partage de développement : < http://koha-fr.org/content/que-voudriez-vous-en-plus-pour-koha>.

Ce travail collaboratif peut toutefois débuter bien en amont et se mettre en place dès la phase de réflexion sur une réinformatisation.

Se regrouper pour préparer une réinformatisation


C'est ce qu'a fait un groupe rhône-alpin de bibliothèques de l'enseignement supérieur.

Un groupe informel

Fin 2005, ce groupe se réunit afin d'étudier l'évolution des SIGB libres, d'observer leur utilisation dans un contexte universitaire et de mener des tests techniques et comparatifs ; à moyen terme le but était d'écrire des spécifications en vue d'une réinformatisation avec un SIGB libre.

Des outils sont mis en place pour mutualiser les ressources techniques et humaines et faciliter la coordination du groupe : une liste de discussion privée, un site web public enrichi par l'ensemble du groupe.

Après une étude comparative des SIGB libres disponibles, Koha fut identifié comme le plus à même de répondre aux besoins de ces établissements, après quelques développements.

Un groupe resserré et plus impliqué

Pour l'étape suivante, une charte d'adhésion fut mise en place, ce qui renforçait la cohésion et l'homogénéité en insistant sur la nécessité de partager l'expertise acquise dans la connaissance de Koha avec des objectifs concrets et un investissement effectif.

Les résultats les plus significatifs furent rendus publics sur le site web et en 2008, un atelier de 2 jours fut organisé dans le cadre du symposium accueilli par Lyon 2, afin d'échanger avec d'autres acteurs.

La phase de réinformatisation

Fin 2008, trois universités (Lyon 2, Lyon 3 et Jean Monet de Saint-Étienne) se trouvaient confrontées à une échéance concernant leur ré-informatisation et prenaient la décision de déployer Koha : chaque établissement mena alors séparément son propre projet.

Parallèlement, chacun des trois établissements, sur la base des spécifications définies collectivement, fut chargé de rédiger le cahier des charges d'un des développements identifiés comme nécessaires à la mise en production et de le financer.

Les développements réalisés, chacun mena les tests sur une version identique, les valida, les mettant à disposition du groupe, puis chacun bénéficia des développements des autres.

La version choisie de Koha ne permit pas le reversement rapide de ces développements dans la version communautaire et par la suite, la gestion de Koha fut propre à chaque établissement, en raison de choix techniques différents, mais une bonne connaissance mutuelle des acteurs locaux autour de Koha demeure, pouvant être une ressource pour une aide éventuelle ou d'autres projets en commun.

À travers les exemples précédents, nous avons pu voir que si dans la communauté, les outils de communication et de partage en ligne sont essentiels à la dynamique du projet Koha, dans les coopérations entre établissements il s'agit plus de trouver des intérêts communs, d'établir un fonctionnement horizontal et de travailler sur les mêmes bases.

Mutualiser le SIGB au sein d'un réseau


Dans le cadre d'un réseau de bibliothèque, la mutualisation du SIGB coule de source, on peut toutefois souligner que pour un fonctionnement optimal, certaines conditions doivent être réunies.

Archirès, un réseau informel

L'exemple du réseau informel ArchiRès, comprenant aujourd'hui 20 écoles nationales supérieures d’architecture et de paysage (ENSA) françaises et francophones et quelques écoles étrangères, nous montre toute l'importance de la structuration.

Ce réseau a mis en place plusieurs pratiques coopératives, y compris la mise en ligne des mémoires d'étudiants.

Une réinformatisation partagée

En 2010, alors que les bibliothèques du réseau s'inquiètent de l'avenir de leurs catalogues respectifs et de la base de données partagée, elles obtiennent un audit, qui propose la mise en place mutualisée de trois outils : un catalogue, un système de gestion électronique des documents (GED) et un portail unique.

Le choix de Koha et d'une architecture basée sur des logiciels libres est fait, un marché est lancé, remporté en 2012 par la société BibLibre, aboutissant à la mise en ligne du catalogue commun de 390 000 notices en septembre 2014.

Le comité de pilotage mis en place au début du projet est pérennisé afin de dégager des orientations et valider les évolutions, qui seront mises en œuvre par un coordinateur encore à nommer par le ministère.

L'étape suivante, par la reconnaissance d'une entité encore à définir, permettra de stabiliser l'architecture technique, financière et humaine du réseau.

Les inconvénients d'un réseau informel

L'absence de structure fédératrice rend les choses un peu plus difficiles, car le cadre mutualisé n'est pas assez visible par tous, et la perte de reconnaissance des engagements ou des décisions est notable ; l'administrateur n'est pas toujours bien identifié comme référent rendant la mise sur pied d'un groupe moteur pour la formation complexe et engendrant parfois des difficultés d'utilisation au quotidien.

Cela n'empêche toutefois pas la mise sur pied de chantiers collaboratifs autour des données ou des pratiques de catalogage et les remontées du terrain vont permettre une amélioration du service rendu aux utilisateurs.

Pour le fonctionnement en réseau, on soulignera l'importance de la structuration qui favorisera la pérennité, la stabilité, la fluidité et la communication interne facilitant la participation et l'implication des utilisateurs professionnels.

Le réseau du syndicat d’agglomération nouvelle (SAN) Ouest Provence (MIOP)

On peut citer l'exemple de la MIOP, qui s'appuyant sur un réseau bien structuré, a mis en place un système de référent SIGB dans chacun des établissements du réseau.

Ce référent capable de tester Koha et d'assister ses collègues dans leur utilisation du SIGB, a été formé à l'utilisation de l'outil de signalement « Mantis »99.et participe donc activement à l'évolution de son outil de travail, fait le lien entre l'utilisateur professionnel et le chef de projet.

Pour conclure et élargir notre propos, nous attirerons l'attention sur le fait que la logique qui conduit au choix d'un SIGB libre établissant un rapport différent entre le client-utilisateur et son prestataire de maintenance, relève plus de la co-construction et que ce positionnement nouveau participe de l'évolution du métier.

En effet, la culture informatique est assez peu développée chez les bibliothécaires, bien que l'informatique soit au cœur de la fonction documentaire depuis longtemps. Sans faire nécessairement des bibliothécaires des spécialistes, il est aujourd'hui indispensable de s'ouvrir à cette connaissance, non seulement pour acquérir une expertise mais aussi pour pouvoir participer activement aux choix stratégiques de l'établissement.

Le choix d'une solution libre et évolutive comme Koha, inscrit le projet informatique dans la durée. Il nécessite une communication active, donnant la possibilité aux utilisateurs de participer aux évolutions du logiciel et d'en comprendre les enjeux.

Surtout, le projet s'inscrit dans une démarche d'échange et de mutualisation : la bibliothèque ne peut plus vivre seule, elle doit collaborer, partager ses ressources, mutualiser ses moyens, se constituer en réseau et de ce point de vue, le choix de Koha se fond dans ce mouvement plus général.

En résumé, plus qu'une option technologique ou financière pour l'établissement, le logiciel libre et collaboratif est porteur d’une culture qui peut faire bouger les schémas organisationnels en renforçant le capital humain de la bibliothèque, en élevant le niveau de qualification de son personnel, et sa capacité d'adaptation aux évolutions du métier.

 

 
1.

Système d’exploitation GNU : < https://www.gnu.org/philosophy/free-sw.fr.html >.

2.

Marie-France Blanquet, « Un visionnaire venu des Indes », Bulletin des bibliothèques de France, 2012, n° 1. [En ligne] : < http://bbf.enssib.fr/consulter/bbf-2012-01-0012-002 >.

3.

Fait d'enregistrer dans un outil de gestion de versions une nouvelle version d'un ensemble de fichiers. Cet ensemble peut ne receler qu'un seul fichier. Dans la plupart des cas, il s'agit de modules de code source ou de documentation, au sein desquels un participant au projet (dit committer) enregistre ses modifications au moyen d'un commit. Par extension, cela désigne également le résultat de cette action.

4.

Nombre de commits dans le dépôt Koha, par mois depuis 2000 : < http://git.koha-community.org/stats/koha-master/activity.html >.

5.

Une société de services en logiciels libres est une société de services en ingénierie informatique (SSII) spécialisée dans la réalisation de projets informatiques basés sur des logiciels libres ou logiciels Open Source. À la différence des SSII classiques, ces entreprises proposent des prestations (conseil, assistance, formation, intégration, développement) développées exclusivement avec des composants logiciels libres.

7.

Outil d'enrichissement des OPAC commercialisé par la société Babelio : < http://www.babeltheque.com/ >.