Premières qualités attendues de tout système informatique du point de vue utilisateur : performance et simplicité. Est-ce possible pour nos systèmes de bibliothèques, connus pour leur complexité – qu’ils soient intégrés ou mutualisés ? Celle-ci n’est-elle que le reflet de besoins eux-mêmes complexes dans des organisations de taille importante1 ? Après une expérience de responsable d’une équipe informatique documentaire importante, me voici dans une bibliothèque d’école dont la totalité de l’effectif est de… trois personnes ! Certes, les publics comme les collections sont en proportion, mais comment faire si on ne veut pas consacrer, disons, plus de 0,1 à 0,2 ETP à l’informatique ? Peut-on sérieusement envisager d’user des mêmes outils qu’une BU ? Pour ce qui concerne le SIGB, c’est le défi que nous avons relevé à l’ENTPE lors de notre réinformatisation en 2017.

L’ENTPE est une école d’ingénieurs de l’aménagement durable des territoires, établissement public sous tutelle du ministère de Transition écologique et solidaire, membre de l’Université de Lyon. État des lieux en 2016 : une base documentaire « maison » en mauvais état et coupée du monde, non visible en dehors du campus (environ 25 000 documents). Première décision : passer à Unimarc et rentrer dans le Sudoc ! Deuxième décision : passer à Koha ! Troisième décision : faire les deux en même temps ! Durée du projet (après le choix d’un prestataire) : sept mois (d’octobre 2016 à avril 2017), avec ½ ETP en interne. Budget : inférieur à 25 K€.

Exemplariser dans le Sudoc

La stratégie est celle d’une externalisation maitrisée, à commencer par le catalogage. En tant que petite bibliothèque, nous voulons exemplariser dans le Sudoc pour bénéficier de sa qualité bibliographique à moindre coût, sans la mauvaise conscience de ne pas vraiment contribuer à créer cette richesse. Première difficulté : quel Unimarc parles-tu ? En bon professionnel, notre prestataire parle l’Unimarc standard. Nous, les yeux rivés sur le Sudoc et sans passé Unimarc en interne (notre base étant migrée depuis un format maison), n’avons que le Guide méthodologique comme référence. Malentendu que le format d’échange du Sudoc ne contribue paradoxalement pas à résoudre. Chacun son histoire… mais pourquoi passer du temps à établir un format de catalogue local, mix d’Unimarc standard, de règles Sudoc et de spécificités locales ? Pourquoi ne pas dire : nous voulons en 2018 démarrer un catalogue local produit à 100 % selon les règles du Sudoc, par défaut, et suivant a priori ses évolutions, quitte à assumer des dérives locales ultérieures ? Pourquoi passer par un Unimarc standard qui ne fait qu’alourdir les choses, avec des chargeurs qu’il faut faire évoluer à part du logiciel (dans tous les SIGB, cette passerelle n’est jamais qu’un outil externe au SIGB lui-même), puisque in fine la règle, pour de vrai, est que chacun fait sa sauce Unimarc localement ? Un tel SIGB n’existe pas, pas plus Koha qu’un autre, malheureusement. Et s’il existait, on le critiquerait sûrement en disant : pourquoi installer chacun son catalogue local si on adopte vraiment tous le même format de catalogage, pourquoi ne pas utiliser directement le même catalogue centralisé ? Ah oui au fait, pourquoi ?

« Comme l’outil le propose »

La deuxième « externalisation » est celle des procédures et modèles de travail : chaque fois que Koha (ou notre prestataire) a adopté un paramétrage par défaut, nous ne le changeons que si c’est indispensable ; sinon, nous changeons notre façon de faire pour adopter celle proposée par le logiciel. C’est vrai en particulier pour tout ce qui est gestion des lecteurs et des règles de circulation, mais aussi pour la gestion des exemplaires, ou le bulletinage. Ou, mieux, nous nous posons la question : avons-nous vraiment besoin d’intégrer cette fonctionnalité ? Ne peut-on s’en passer (par exemple et d’évidence, dans notre petite bibliothèque, pour la gestion budgétaire des acquisitions) ? C’est fou ce que l’on gagne comme temps de cette façon.

La dernière externalisation, moins surprenante, est celle de l’hébergement et de la maintenance évolutive. Le SIGB est un service comme un autre. Up-to-date, c’est encore mieux.

Sous-traitants et logiciel libre

On pourrait nous demander : si vous sous-traitez tout, alors, à quoi ça sert d’avoir choisi un logiciel libre ? Première raison : dans notre contexte, Koha, c’est le meilleur au moindre coût. « Le meilleur » veut dire qu’il fait déjà plutôt bien tout ce que nous voulons d’indispensable et qu’il a la communauté d’utilisateurs la plus large en France. « Le moindre coût » (projet et maintenance), c’est un constat – sans que nous puissions dire si cela vient du modèle libre et de la concurrence entre prestataires sur un même logiciel (prestations même imparfaites), ou de la maturité atteinte par ce logiciel né dans le Web au début des années 2000 (à la différence de ses prédécesseurs, qui n’ont jamais quitté leur interface pro client-serveur ni des OPAC discutables). Dit autrement : sur le segment de marché de l’ESR français (délimité en première approximation par le réseau Sudoc), Koha est probablement le plus moderne des SIGB classiques, et même le seul qui ait continué à se développer malgré le ralentissement du marché de ces dernières années et la perspective d’une nouvelle ère, celle des plateformes de services pour les bibliothèques.

Deuxième raison : rationaliser notre investissement sur le SIGB au quotidien permet de se concentrer sur la valeur ajoutée que l’on décide d’y apporter. Et pour des développements spécifiques, le libre, c’est mieux. Nous avons ainsi choisi d’enrichir les notices de périodiques par les données de la base Mir@bel, dans laquelle nous gérons nos accès en ligne aux revues, grâce à un connecteur mirabel_to_koha. Impossible en effet pour une bibliothèque de notre taille d’ambitionner la mise en place d’un outil de découverte2. Difficile par contre et a minima de se passer d’une liste de revues avec les accès en ligne. Mais, nouveau constat étonnant : il n’existe toujours pas, en 2018, de solution libre et mutualisée satisfaisante pour gérer une fonction aussi ancienne et basique qu’une liste de périodiques, alphabétique ou thématique, mêlant au choix supports imprimés et électroniques. Alors, on s’y emploie… là encore avec le réseau Mir@bel, qui a développé un début de solution en 2017.

A l’avenir, répondre au besoin des petites et moyennes bibliothèques supposera davantage de solutions standardisées (vraiment) et centralisées (autant que de besoin). Qui sera en mesure de proposer pour ces bibliothèques des plateformes de services à moindre coût ? Ou faut-il les imaginer comme des solutions davantage bricolées (« low tech »), mais peut-être, au fond, plus adaptées au service rendu que celles des entreprises décidées à dominer le marché à l’échelle mondiale ?

Faut-il imaginer des solutions bricolées pour répondre aux besoins des petites et moyennes bibliothèques ?

La communaute Koha en France

La communauté Koha française comporte des bibliothèques de taille importante (Aix-Marseille Université, nombreuses bibliothèques d’écoles relevant ou non de l’enseignement supérieur, comme, par exemple, le réseau Archirès des écoles d’architecture…) mais aussi des structures plus petites (bibliothèques de laboratoires), sans oublier une large part de bibliothèques de lecture publique et de centre de documentation spécialisés. L’association Kohala fédère cette communauté. Son rôle est semblable à celui d’un club utilisateurs d’un logiciel propriétaire, la différence étant qu’elle fait collaborer les bibliothèques utilisatrices avec les différents prestataires qui développent et supportent le logiciel, même si la société Biblibre joue un rôle prépondérant parmi celles-ci depuis l’origine. Chacun peut ainsi suivre des formations ou participer aux améliorations du logiciel ou à la traduction française des nouvelles versions, notamment à l’occasion d’un hackfest annuel.
Kohala organise chaque année un symposium en juin et une journée d’étude en janvier, et participe aux différents événements organisés par la communauté Koha à l’international.