Mise en place d'une carte unique avec des SIGB hétérogènes

L'offre en matière de cartes réseau ou cartes uniques s'est généralisée dans les communautés de communes ou d'agglomération : un seul abonnement permet de bénéficier des services de toutes les bibliothèques d'un réseau, quelles que soient leurs tutelles administratives. Quand tous les établissements ne travaillent pas sur un même logiciel de gestion, l'usager doit se réinscrire dans chacune des bases emprunteurs des SIGB utilisés dans le réseau. Pour les médiathèques du réseau du Pays de Romans, j'ai réalisé cet été une étude de faisabilité d'une application permettant de répercuter une inscription unique dans tous les logiciels existants sur le réseau.

Le SIGB unique n'est pas toujours une solution.

Préalablement, le Pays de Romans avait réalisé une étude pour mettre en place un même logiciel sur l'ensemble du réseau. Cette solution n'avait pas été retenue en raison du coût élevé de l'opération, mais surtout par respect de la diversité des fonctionnements des établissements: 9 bibliothèques associatives ou communales, certaines à vocation intercommunales et les deux médiathèques du Pays de Romans, la médiathèque Beauvoir (2000m², 115.000 documents) et la médiathèque Monnaie (500m², 19.000 documents). Les SIGB existants, 6 Microbib et Aloès pour les 2 médiathèques du Pays du Romans, ont été choisis en fonction des pratiques professionnelles supposées correspondre à la politique culturelle de leur autorité de tutelle.

Une plate-forme d'échange de cartes.

L'étude propose la mise en place d'un entrepôt constitué d'une base de données des cartes réseau et de services pour la récupération des cartes créées ou modifiées dans un établissement et la distribution aux autres SIGB. Le Pays de Romans a souhaité que l'application de gestion soit réalisée dans le domaine du libre et diffusée ultérieurement sous cette forme. Chaque fois que cela a été possible, les protocoles et standards existants ont été privilégiés en ne retenant que les services de type web (http).

Format XML d'échange

Le premier travail a été de définir un format d'échange pour les cartes réseaux. Les protocoles existants relatifs aux abonnés (DLF/ILS, ANSI Z39.81 ex SIP ,..) ne prennent en compte les abonnés que dans le contexte de la circulation des documents et ignorent les données qui nous sont indispensable : état-civil, coordonnées, dates d'inscription, etc. Il donc fallu concevoir notre propre schéma XML en ne retenant que les champs présents dans les deux SIGB.

2 modes de travail en fonction de la connexion internet

Sur la communauté d'agglomération, seul le service informatique de l'agglomération qui héberge le serveur Aloès dispose d'une connexion internet permanente avec un nom de domaine. L'application propose pour chaque fonctionnalité deux modes de travail, Le premier laisse l'initiative à l'entrepôt central qui fonctionne en tant que client des services du SIGB. Le second est à l'initiative du SIGB qui utilise les services de l'entrepôt central pour récupérer les cartes des autres établissements et les intégrer à sa base de données.

Récupération des cartes

Un premier service permet à une application cliente de «moissonner» les cartes réseau d'un serveur, entrepôt central ou SIGB, en vue de leur intégration à sa propre base de données. En l'absence de protocole particulier pour la récupération des données d'abonnés, nous avons choisi d'utiliser le protocole OAI/PMH qui correspond exactement à nos besoins. Même s'il a été conçu pour l'échange de données bibliographiques, il permet de définir son propre format de données (metadataprefix) et donc d 'utiliser le nôtre. Pour les puristes, la seule entorse au protocole est que nous ne pouvons pas fournir les données en Dublin Core!

Fourniture des cartes.

Le second service permet d'intégrer ou mettre à jour une base pour une carte ou un lot de cartes. Le seul protocole permettant cette fonctionnalité est le protocole SIP3 (requête 33 -Update Patron) que nous n'avons pas retenu car ce n'est pas un service web. Les données à mettre à jour sont fournies au format XML des cartes d'abonnés et un schéma XML a été défini pour le rapport d'intégration à retourner au client.

Implémentation par les SIGB.

Le cahier des spécifications a été envoyé aux deux SIGB concernés pour qu'ils puissent faire une proposition de mise en place.

Microbib a répondu favorablement. Il propose de développer un client OAI pour récupérer les données de l'entrepôt central et un client web utilisant le service de mise à jour de l'entrepôt central pour la fourniture des cartes.

Opsys (Archimed) ne souhaite pas se lancer dans les développements souhaités en considérant qu'il s'agit d'une demande spécifique qui ne rentre pas dans sa stratégie de développement.

Pour la récupération des données, la solution proposée est l'achat et la mise en place du module d'export de données emprunteurs d'Aloès. Les données fournies seront, en ASCII délimité, selon un format propriétaire,à charge pour l'entrepôt central de les rendre conformes aux spécifications.

Pour la mise à jour des cartes dans la base Aloès, Opsys prépare pour l'été 2013, une version 2.10 d'Aloès intégrant un service web permettant la création et la mise à jour des abonnés. Là aussi, le protocole est propriétaire et il faudra mettre en place une application spécifique au niveau de l'entrepôt central.

La communauté d'agglomération du Pays de Romans a décidé de migrer vers cette version 2.10 dès que possible. Le projet n'est pas abandonné pour autant, car il correspond parfaitement aux besoins, il est simplement mis en veille au moins jusqu'à septembre 2013.

En attendant...

Comme le pays de Romans,je reste attaché à ce projet et compte profiter de ce délai imposé pour le faire avancer.

En voulant essayer d'aller vite, nous avons oublié que l'interopérabilité et la définition de protocoles d'échanges passent par la concertation et le travail collectif, comme cela a été fait pour les recommandations 995 ou Idrabib. La réaction d'Opsys aurait, je l'espère, été différente si la demande avait été faite dans un contexte similaire.

En conséquence, je vais solliciter l'ABF et la Fulbi pour voir ce qui peut être fait corriger le tir, quitte à modifier les spécifications de l'étude.

Télécharger l'étude ou le schéma XML

Ce projet a besoin de vous, n'hésitez pas à réagir et à me contacter s'il vous intéresse.