Summary in English at bottom of post
Long long billet, allez vous chercher un café d’abord…
Suite de la série commencée en juin 2011 et octobre 2011 sur les systèmes de gestion de bibliothèque dits de “nouvelle génération”.
Le premier billet (SGB XXL #1) évoquait les questions qui se posaient aux BU face à l’arrivée anticipée sur le marché d’une offre renouvellée de systèmes de gestion ayant 2 caractéristiques nouvelles : ils utilisent le cloud; ils sont assis non plus sur un catalogue, au sens traditionnel, mais sur une base de connaissance (KB) qui inclue tous types de documents, ainsi que des données de gestion.
J’ai participé avec quelques collègues d’autres universités à un groupe de travail ad hoc sur le sujet : le second billet (SGB XXL #2) pointait les questions que ce groupe souhaitait discuter avec les prestataires qui avancent sur ces dossiers.
La question, dans ce contexte, de la KB devient cruciale, et j’ai donc continué à réfléchir sur le sujet, cf mon intervention de janvier à l’AURA.
Le projet passe maintenant à une autre phase (cf un peu plus loin) et je veux donc ici juste faire un petit bilan d’étape qui met en avant quelques éléments qu’on a pu apprendre dans cette première période.
On a rencontré plus particulièrement deux prestataires qui annoncent l’arrivée de produits de cette nature : Ex Libris avec Alma, et OCLC avec Worldshare.
Un troisième prestataire, SerialsSolutions, a annoncé au printemps 2011 s’engager dans le développement d’un produit de cette nature, Intota, mais pour une date ultérieure. J’ai discuté de façon beaucoup plus informelle et superficielle avec eux.
Description des systèmes
Architecture des données
Au niveau le plus général, une base de données globale existe qui regroupe les données partagées par toutes les bibliothèques utilisant le système : c’est le niveau appelé, par l’un de ces prestataires, « communautaire ».
Un niveau inférieur existe, qui est de nature consortiale : les données présentent à ce niveau peuvent être privées, réservées au consortium, ou publiques, auquel cas elles « remontent » au niveau communautaire.
Un niveau encore inférieur existe, correspondant à la bibliothèque au sens institutionnel. A nouveau les données peuvent être privées ou partagées avec les niveaux supérieurs, consortial ou communautaire.
Pour finir les documents, numériques ou physiques, sont attachés à un « inventaire » correspondant à une bibliothèque physique.
Globalement, il semble que la gestion des droits, tant au niveau des interventions que des données elles-mêmes entre ces 3 niveaux soit assez souple : une bibliothèque donnée peut a priori partager ce qu’elle veut avec qui elle veut. Par contre, cette structure de base à 3 niveaux (communautaire, consortial, institutionnel local) est fixe.
Architecture du système
Techniquement, l’architecture est aussi assez similaire dans ses grands principes. Ce qui est proposé c’est un outil qui soit aussi une plateforme de développement répondant aux principes de l’Architecture Orientée Service.
On a donc une série de services définis qui permettent d’interagir avec la plateforme de différentes façons :
- workflow engine. Si le prestataire a défini un circuit de travail type pour les bibliothécaires, par exemple commander un livre, il a néanmoins défini des « points d’étape » sur lesquels la bibliothèque peut intervenir. Par exemple la bibliothèque peut définir qu’elle n’a pas besoin de l’étape de validation de la commande définie en standard par le prestataire. On est ici dans des interventions qui sont de l’ordre du paramétrage, classique dans un SIGB dans son principe. A ceci prêt que ces produits étant définis aujourd’hui, avec les méthodes de conception/développement disponibles aujourd’hui, le découpage du workflow est plus fin et les possibilités d’interventions en théorie plus importantes.
- APIs. C’est un des changements d’architecture technique qui a le plus de potentiel pour les bibliothèques. Le prestataire donne en effet accès, de façon documentée et stable, aux APIs de son système : non pas directement aux API internes, qui nécessiteraient d’utiliser les mêmes méthodes et langages de programmation que le prestataire, mais des API externes destinées aux clients. Les prestataires assurent avoir conçu des API les plus détaillées possibles, et ce sera certainement un élément important de discrimination entre eux. A charge pour les bibliothèques, ensuite, d’être capable d’exploiter les API. Ce sera certainement un élément important de discrimination entre elles.
Prenons l’exemple d’un prêt : la fiche de l’étudiant est appelée, un contrôle sur ses droits effectué, par exemple sur d’éventuels blocages, un autre contrôle est effectué pour savoir s’il a des réservations en cours, etc. Si chacune de ces opérations est, au niveau de l’API, séparée, la bibliothèque peut faire un programme qui « intercepte » la réponse et la réutilise dans un autre contexte. On peut imaginer, par exemple, un programme qui vérifie la présence dans le SGB d’une réservation quand l’usager s’authentifie dans l’ENT de l’université, et l’en alerte directement dans l’ENT. Ce type d’intégration, sur le compte lecteur, pourrait être réalisé avec d’autres API pour des données traditionnellement considérées comme internes : les données financières en connectant le SGB et SIFAC, par exemple.
Les prestataires concernés proposent une architecture de ce type en principe. Mais le diable est dans les détails : il faudra voir ce qu’il est possible de faire concrètement avec l’une ou l’autre plateforme. En théorie en tout cas, cette architecture permettrait d’avoir un système standard, et des adaptations locales/nationales propres, à la fois dans le sens de “propres à nous” et de “proprement réalisées”.
Impact potentiel sur les établissements
Fonctionnellement, quelques points sont saillants et ont un fort impact potentiel sur la vie des établissements.
- Périmètre fonctionnel. Les SGB entrevus vont dans la même direction : réunifier la gestion de la bibliothèque dans un outil unique. En particulier en regroupant gestion de la documentation papier et de la documentation électronique. Potentiellement, un établissement qui utiliserait la totalité des fonctionnalités du SGB pourrait le considérer comme son unique logiciel : pour la documentation papier, pour l’électronique, en gestion interne (ERMS) ou en accès public (résolveur de liens), pour les archives ouvertes, pour les thèses, etc. Il faudra donc considérer ces projets, et juger des budgets, non pas à l’aulne du remplacement du seul SIGB, mais par rapport à l’ensemble des logiciels présents dans notre périmètre, voir en informatisant des fonctions qui ne bénéficient pas jusqu’ici d’un outil de gestion propre (ERMS par exemple).
- Organisation interne. Ensuite le regroupement des fonctions dans un seul logiciel peut avoir un impact important sur l’organisation interne des services. A titre d’exemple, si les acquisitions forment un module unique, tous supports confondus, la rupture désormais classique entre service de la doc. électronique d’un côté et services de « politique documentaire » centré sur la documentation papier de l’autre n’a plus beaucoup de sens.
- Productivité. L’objectif affirmé de ces systèmes est de limiter drastiquement le temps de saisie des données, quelles qu’elles soient. C’est en particulier le cas du catalogage : les prestataires envisagent des accords avec les fournisseurs de documentation et/ou de notices, à commencer par les bibliothèques nationales ; par ailleurs ils incitent les bibliothèques utilisatrices du système à autoriser leurs notices à apparaître dans la base de données « communautaire ». L’objectif est clairement de proposer aux bibliothèques une solution où, quand on souhaite acquérir un document, sa notice existe déjà dans le système. On pourrait évoquer une évolution similaire pour la partie administrative des acquisitions : si une connexion est établie entre le SGB et SIFAC, par exemple, le temps de gestion budgétaire gagné par les établissements pourrait ne pas être négligeable.
- Nouveaux services. Un certain nombre de fonctionnalités nouvelles sont directement induites par la taille du système et par le partage de données au niveau international. Par exemple en terme de politique documentaire et de statistiques en général, pour comparer son établissement aux autres. Mais aussi en termes de services au public : la possibilité d’offrir des services du type « recommandation » (ceux qui ont vu ceci, s’intéressent aussi à cela) est directement liée à la taille de la base : plus elle est importante, plus les services sont pertinents.
L’ABES
Comme je le disais plus haut, ce groupe de travail, purement ad hoc, arrive au terme de sa mission (auto-définie) : recueillir de l’information sur ces systèmes. Désormais on passe à une autre phase : l’ABES qui était représentée dans le groupe ad hoc, au même titre que d’autres établissements de l’enseignement supérieur Français, prend désormais en charge ce dossier, qui recoupe très largement son propre projet d’établissement.
La conclusion du groupe ad hoc est assez simple, finalement : ces systèmes arrivent; ils sont “pour du vrai”. On ne doit pas les aborder en ordre dispersé, et les compétences et les moyens requis pour les exploiter ne seront vraisemblablement pas accessibles à un établissement isolé ou même à un PRES. Il faut se regrouper, à une échelle nationale, et l’ABES est le partenaire naturel des BU pour ça.
Et sans vouloir parler bien entendu au nom de l’ABES ou de ses personnels, il semble assez évident que ces outils, quand ils arriveront, auront un impact majeur sur le SUDOC lui même. L’abes, en un mot, ne peut pas les ignorer. Elle peut même, peut-être, en tirer parti pour ses propres besoins, confrontée qu’elle est aux mêmes problèmes que les établissements : des outils vieillissants et qui manquent de souplesse.
Je suis très content d’avoir contribué à la création de ce groupe de travail, et très content de voir que l’ABES prend le relais. C’est certainement le projet qui, dans tout ce qui se fait dans les BU en ce moment dans le domaine de l’informatique documentaire, a l’impact potentiel le plus important.
On a désormais un vrai projet, un groupe de travail estampillé “Comité Technique ABES” est en cours de constitution, avec appel à intérêt imminent.
==========================================
English summary
I initiated the creation of an ad hoc working group of university libraries in France, back in March 2011, with a simple enough goal: let’s gather 6 or 7 systems librarians from different universities and let’s talk to OCLC, Ex Libris and SerialsSolutions about their NextGen library systems. We just need to learn a bit more about those. We spent some time among ourselves and then with OCLC and Ex Libris, interacting from a distance with SerialsSolutions. Pretty quickly we added ABES to our meetings : they manage the Union Catalog SUDOC, used by almost every HigherEd Library in the country.
We’ve had demos and exchanged documents about Alma and Worldshare, and about how French HE libraries, as a group, could approach these new systems.
This first phase is over and I want to share a bit of what we’ve learned, and where we’re headed next.
These systems share a set of basic building principles, which raise a fair number of questions:
- it’s not a catalog, it’s a Knowledge Base: the way the KB’s going to work is going to be crucial. What’s in it? What’s shared? What’s “private”? What’s the license on records, all types of records? How is it managed? What’s the workflow of records, updates, and information within the KB? Getting data in and out?
- it’s a platform. The granularity of the APIs? The stability of the core? The documentation? How are vendors going to interact with libraries or third-parties who want to use the APIs and the underlying data? How open is it? How clean is it?
- it’s a (re-)Unified system. This potentially has a major impact on HR and workflows within the library. It’s going to be a huge change, in some libraries, to re-unify the workflows of, say, print acquisitions and electronic acquisitions which, at least in France, tend to be separate.
We’ve gathered enough information to understand that these systems are for real, are certainly not vaporware, and that we can’t ignore them: they have the potential to have a major impact on the library landscape.
So what now? The ad hoc group hands over it’s duties to ABES, which is emerging, beyond their initial mission of managing a Union catalog, as a general purpose agency for Higher Education libraries in France. They’ll form an official Working Group in the coming weeks and investigate the possibility of ABES setting up a consortium of French libraries that would be interested in selecting one of those systems.
I’ll be a member of that Working Group until August, when I’ll be taking a 3 years “unpaid leave of absence” from the French public sector (I spare you the gory details of the red tape implied in that seemingly simple sentence).












