Journées Abes : groupe SIGB mutualisé

Présentation générale

La veille des journées Abes, j’ai participé, avec une vingtaine d’autres personnes, à un groupe de travail « SIGB mutualisé ». J’avoue que je pensais à une espèce de brainstorming visant à préparer l’avenir, sur le mode : Internet bouge, offre de nouvelles perspectives. Parmi celles-ci, comme l’architecture du Sudoc peut-elle évoluer pour proposer des services professionnels et publics plus satisfaisants (permettant d’arriver par exemple à ce genre de résultats), à travers une articulation différente entre systèmes locaux et système central.

Très exactement, j’avais en tête ceci : les technologies du web des données, le RDF et SPARQL, permettent de penser différemment un réseau tel que le nôtre. Notamment sur les points suivants (que je n’ai pas exprimé complètement lors échanges de mails visant à préparer la réunion) :

• Si les bibliothèques adoptent le RDA (RDF pour catalogues), les spécificités des formats MARC disparaissent. Ceux-ci sont liés à l’appropriation précoce par les bibliothèques des technologies informatiques dans les années 70, quand n’existait pas de standard « universel ».
  Les bibliothèques ont donc su créer des normes, des outils, propres à répondre à leurs besoins fonctionnels et catalographiques. Ces outils et ces normes sont devenues des spécificités bibliothéconomiques, pendant que se développaient peu à peu d’autres standards, d’autres outils, dans d’autres secteurs d’activités.
  Le RDF permet de décrire un ouvrage très précisément aussi bien qu’un stock de légumes. La notion de grille de catalogage est obsolète, au profit d’autres modes de saisie (et surtout de production et récupération des métadonnées).
  Donc aujourd’hui s’ouvre à nous tout le panel des outils développés de manière beaucoup plus large. La pertinence de continuer à acheter des logiciels pour bibliothèques doit se poser, au moins à long terme (donc dans le cadre d’un réseau aussi vaste que le Sudoc, elle doit se poser).
• Le Sudoc fonctionne sur la base d’échanges de fichiers : vous cataloguez dans le Sudoc (base centrale), et dans la nuit vos notices sont extraites dans un format standard (iso2709), chargées sur un serveur où votre SIGB vient les récupérer, pour les réinjecter dans sa base locale. L’iso2709 sert de format d’échange, compris par les deux systèmes.
  Mais les données que vous retrouvez le lendemain dans votre SIGB sont bien le double de celles du Sudoc : elles sont stockées sur votre serveur, et vont désormais mener une vie distincte de la base catalographique du Sudoc.
  Là encore, le web des données (précédé en cela par les API) permet de reconsidérer complètement le problème, puisque la même donnée (une notice bibliographique) peut désormais être accessible (soit pour consultation, soit pour modification) par deux systèmes différents (ou plus !).
  Donc l’articulation entre base centrale et SIGB local peut être repensée, en essayant de réfléchir à la notion d’accès en temps réel aux données (à leur ouverture, en somme) plutôt qu’à leur circuit actuel d’extraction-export-chargement.

Sur place, j’ai appris qu’en réalité, le conseil scientifique et le conseil d’administration de l’Abes avaient estimé qu’il était économiquement (et logiquement ?) plus intelligent de disposer d’un SIGB unique pour l’ensemble du réseau, plutôt que d’avoir des sysèmes indépendants les uns des autres, s’efforçant péniblement de dialoguer entre eux. Donc commande est faite à l’Abes de proposer des scénarios de « SIGB mutualisés ».
Si j’ai bonne mémoire (mais les autres participants me corrigeront si j’ai mal compris), il faut que d’ici septembre 2011 certaines bibliothèques acceptent le challenge et se proposent comme établissements pilotes pour accompagner le projet en avant-première.

J’ai trouvé que l’enjeu de la réunion était tout différent, entre essayer entre bibliothécaires de construire l’avenir, et s’efforcer de répondre à une commande injonctive. J’aurais sans doute répondu différemment aux échanges par mail préalables à la réunion, et j’y serai vraisemblablement venu avec d’autres idées.

A noter : l’équipe de l’Abes a fait en début de réunion une restitution de ces échanges, les attentes des différents participants du groupe. Y figurait une ligne : « Le web des données : hors sujet ? » (je cite de mémoire).
J’en conclus que j’ai été le seul à attendre quelque chose en lien avec le web des données. Des autres motivations mentionnées, j’ai noté celles-ci :

• Projet de réinformatisation de l’établissement
• SIGB en fin de course
• Changement du contexte institutionnel (fusion d’universités, PRES)
• Qu’est-ce qu’un atelier : échange d’idées, partage d’infos, calendriers prévus
• Objectif d’une mutualisation :
• Économie d’échelle
• Allègement des procédures de gestion
• SIGB : modules classiques, SIGB nouvelle génération, ressources électroniques, « SIGB désintégré ».
• SIGB-Sudoc : alimentation des systèmes locaux, données de circulation dans le sudoc, FRBR/RDA (format de catalogage), Sudoc & web des données.
• Articulation national/local : comment signaler documents uniquement en local dans un SIGB mutualisé ?

Qu’est-ce qu’une mutualisation de SIGB ?

Jean Bernon (directeur du SCD de Lyon 3) a présenté 3 niveaux de mutualisations, chacun avec ses enjeux, ses atouts, ses limites.

Trois modèles de mutualisation :

• Modèle décentralisé acheté par chaque bib auprès d’un prestataire –> mutualisation = club utilisateur
• Modèle centralisé et non commercial = Libra
  A la fin des années 80, tentative de créer un modèle de SIGB centralisé = Libra (autre exemple : Sibil). Un des grands acteurs en est Philippe Lepape.
• Modèle décentralisé avec des produits libres = Koha.

Facebook Social Graph - par Gilad Lotan / CC BY-NC 2.0

Questionnant ensuite les modèles envisagés par l’Abes, il a posé les questions suivantes (je ne détaille pas trop) :

• quelles seront les fonctionnalités attendues ?
• où seront les données ? Toutes seront-elles mutualisables (données bibliographiques ? données d’exemplaires ?) ou seulement une partie, les autres étant conservées en propre (données lecteurs, données de prêt, etc.)
• qu’est-ce que ça signifie dans la gestion des workflows (articulation avec les services de la scolarité, automates de prêt, mutualisation des acquisitions)
• quel scénario de mise en œuvre pour le passage du fonctionnement actuel au fonctionnement futur (quel qu’il soit) ?

Présentation des outils : philosophie

Nicolas Morin (du PRES de Toulouse) a enfin présenté dans leurs grandes lignes les deux SIGB nouvelle génération : Alma d’Ex Libris, et Web-scale Management Services (WMS) d’OCLC.

WMS d'OCLC

Sans présenter beaucoup de copies d’écran, il s’est surtout attardé sur la philosophie de chacun. Voici les points que j’en ai retenu :

• Après l’apparition et la consolidation des SIGB, qui géraient les collections papier (les seules existantes initialement dans les bibliothèques), la gestion des autres types de documents s’est faite en-dehors du SIGB :
• Revues en ligne (ERMS pour la gestion — ou fichiers Excel, outil de type AtoZ pour le signalement, résolveur OpenURL pour l’accès)
• Bibliothèque numérique
• Base de signets
• etc.
  mais aussi : annuaires universitaires, outils de comptabilité, etc.
  Bref, les logiciels se sont multipliés dans l’environnement professionnel d’un bibliothécaire
• Aujourd’hui, une nouvelle génération de SIGB s’efforce de remettre la gestion de ces collections à l’intérieur du logiciel intégré.
  Quelque part, on en revient donc à l’idée de départ d’avoir un seul outil à manipuler, administrer, gérer, mais celui-ci est dans une philosophie différente
• Il est full-web
• Il intègre les technologies « normales » du web d’aujourd’hui (sur la difficulté de nos SIGB à faire comme tout le monde, je vous renvoie par exemple à ce billet)
• Etant capable de gérer une plus grande diversité de collections, il intègre par défaut moins de fonctionnalités métier
• Tout est paramétrable : les types de contenus (ça n’a pas été dit clairement, mais je ne vois pas comment il pourrait en être autrement), les workflows, les fonctionnalités
• Le logiciel est conçu comme un framework de développement, c’est-à-dire qu’il est extensible : on peut y rajouter des plugins, fonctionnalités, etc. comme on rajoute des plugins à Firefox (quoique, je suppose, de manière un peu plus complexe, mais bon…).
  Il peut notamment s’interconnecter beaucoup plus facilement avec les autres sites web proposant API ou données exposées en RDF.
  En gros, ces logiciels new generation sont conçus un peu comme le CMS Drupal (cf. d’ailleurs le dernier billet de Silvère) : à l’installation standard, il est brut et ne fait pas grand chose, mais c’est le nombre de modules qu’on peut y ajouter qui en fait toute la puissance.

Présentation des outils : état d’avancement

Alma et WMS seraient tous deux dans une phase de déploiement de prototypes, avec des bibliothèques partenaires qui assurent un retour sur le produit pour en favoriser le développement en fonction des besoins exprimés et des carences constatées.

Les BU de Norvège, qui avaient mis en place un réseau avec un SIGB unique arrivé en fin de vie, Bibsys, ont signé en 2010 avec OCLC pour remplacer Bibsys par WMS. Celui-ci est également implémenté dans 4 universités américaines.

Alma est également déployé et testé dans quatre bibliothèques universitaires (des early adopters) : Princeton, le Boston College, l’Université catholique de Louvain, et la Purdue University Library.

Deux autres outils ont également été cités, mais sans plus de précision :

• OLE, libre
• Innovative annonce Sierra, qui serait un système de nouvelle génération.

Cela dit, à l’heure actuelle, il semble que ces prestataires ne s’empressent pas de convoiter le marché francophone, et projettent de se rôder sur d’autres territoires — on peut espérer que ceci serait négociable, si un réseau suffisamment important se montrait suffisamment intéressé.

Scénarios envisagés par l’Abes

J’avais retenu que 6 niveaux (cumulatifs) de mutualisation avaient été évoqués — curieusement, je n’ai réussi à n’en noter que 5 (hem !)

1. mutualisation simplement au niveau du groupement d’achat (l’Abes faisant office de négociateur pour un groupement de commande)
2. stockage des données en central
3. logiciel et données en central
4. fusion des bases Sudoc et SIGB local
5. données du SIGB dans une base central à un échelon supérieur au Sudoc
   le Sudoc ne serait qu’un élément d’une base bibliographique beaucoup plus large, l’Abes se présentant comme un client parmi d’autres d’un prestataire

Réactions, débat, réflexions

Les questions ont demandé des précisions sur les fonctionnalités des deux logiciels présentés.
Les inquiétudes exprimées ont plutôt été sur la difficulté à coordonner des calendriers locaux (ceux qui viennent de changer de SIGB n’auront pas forcément envie de repartir dans une mutation aussi profonde) avec un projet national concernant tout le réseau. Il faut donc prévoir une longue période de transition, et une montée en puissance tenant compte de la capacité d’accompagnement de l’Abes.

Pour ma part, j’aurais aimé aller plus loin sur quatre questions (qui se révèleront peut-être foireuses, mais qu’il me semble utile de poser tout de même) :

• On espère de nouveau un outil intégrateur, alors que la philosophie actuelle (notamment avec le web des données) consiste plutôt à travailler en garantissant la circulation, la fluidité, l’accès aux données depuis n’importe où.
  Avec un tel SIGB, j’ai l’impression de retomber dans le fantasme du portail : enfin un seul outil qui fait tout !
  alors qu’il est possible de penser aujourd’hui un système d’information comme une imbrication souple de logiciels qui interagissent entre eux, en utilisant des protocoles standardisés qui ne dupliquent pas les données de l’un à l’autre, mais stockent les données en un seul endroit et les rendent interrogeables de partout.
• Plusieurs échanges ont tourné autour du stockage des données dans un contexte de cloud computing : fait-on remonter les données de circulation ? Que fait-on des données lecteurs ? etc.
  Et les scénarios de l’Abes envisagent de stocker les données en central, ou le logiciel + données en central, mais n’envisagent pas de décentraliser les données, tout en branchant sur ces multiples réservoir un logiciel unique (ou des logiciels multiples), la centralisation consistant essentiellement à décrire de manière normalisée le mode d’accès aux données (ou à certaines données).
  Je ne parle pas de décentraliser les données bibliographiques. Mais si les données de circulation sont stockées en local, cela ne signifie pas qu’elles ne puissent être accessibles par le logiciel central.
• Voilà encore un outil spécifique aux bibliothèques ?
  La question devrait se poser, même si c’est pour conclure qu’à l’heure actuelle c’est encore la meilleure solution.
  Je précise que je n’ai pas creusé plus que ça la possibilité de se passer de SIGB pour avoir une gestion de bibliothèque tout à fait correcte. Je sais que des expériences existent, et que @Got s’en fait régulièrement le chantre sur Twitter
• Enfin, plusieurs personnes se sont inquiétées de ce que ces logiciels, non seulement proposaient moins de fonctionnalités, mais surtout, s’il y avait une installation mutualisée, risquaient de ne pas pouvoir s’adapter à certains besoins locaux
  Il me semble que la réponse à apporter était l’extensibilité des outils présentés : puisqu’ils sont adaptables et extensibles, il « suffit » de s’assurer que l’installation d’un plugin peut se faire au bénéfice obligatoire de l’ensemble d’un réseau, ou de manière optionnelle, chaque membre ou sous-groupe étant libre de l’installer sur sa « vue » du même logiciel.
  Cette réponse n’est pas venue.

Enfin, on est fortement tenté de penser que si un SIGB mutualisé se met en place, ce sera avec un des logiciels new generation du marché (ce pourrait être un truisme de l’énoncer, mais l’Abes a pris la peine de préciser qu’elle ne ferait plus de développements).

Donc on peut faire des scénarios, il vaut mieux partir des outils, se demander comment les optimiser dans le cadre d’un réseau national (en posant la question des besoins locaux en fonctionnalités, des données d’utilisateurs, etc.), plutôt que de laisser aller trop loin son imagination, bien inutilement.
(et je parle de moi, là)