Skip to content

Mise en place du SGBM : étude d’impact — Extraits

15/04/2013

Voici comme promis quelques extraits complètement arbitraires de l’étude d’impact diffusée par l’Abes concernant le projet de mise en place d’un SGB mutualisé.

Ces extraits ne vous dispensent évidemment pas de la lecture du reste : Le fil conducteur de mes extraits, en gros, c’est que ça concerne tous les établissements du réseau, et tout de suite.

Par exemple la mise en place d’un SGB commun dans les nuages pose la question : que deviennent les ressources humaines actuellement affectées à l’administration et à la gestion courante des serveurs et du SIGB (et tous autres outils gravitant autour : résolveur de liens, AtoZ) ? Quelle est la nature du travail qui leur resterait (s’il leur en reste)

Le scénario 1 évoque en étape 3 :

Remplacer le SIGB installé localement par les services en ligne du SGB : passage d’un investissement + fourniture de logiciel + fourniture de services (de support notamment) à un abonnement annuel + des fournitures de services

Pour vous, ça veut dire quoi ? Et si vous n’êtes pas d’accord, ça veut dire quoi ?

Ainsi sous mon précédent billet, Anne-Sophie a laissé en commentaire : « on ne comprend pas bien d’où sort le scénario 3. » D’une certaine manière, il me semble que c’est aux établissements d’y répondre, soit en l’évacuant d’emblée (parce que aberrant), soit en l’imposant comme évident — par exemple sous la forme : Il est exclu que nous migrions sur une plate-forme dans les nuages sur laquelle nous n’aurions plus la main, alors que nous avons développé en interne des compétences techniques exceptionnelles, et qu’en plus votre solution n’est même pas open source.
Ou tout autre argumentaire (bien construit ou non) qui amène à penser qu’une instance commune pour une quasi-totalité du réseau, même sur le long terme, est purement illusoire.

Donc les autres citations ci-dessous ne reprennent pas du tout la diversité des problématiques évoquées dans le document, et ne vous permettent pas de ne pas lire son introduction, ses enjeux, et les impacts évoqués.

Grille de lecture – Photo Flickr by Brian Metcalfe – CC-BY-NC-SA-2.0

Préambule (par M. Bérard)

(p. 5 du fichier PDF)

Nos destins sont étroitement liés mais là où vous attendez les fonctions d’un système local en mieux, l’ABES attend un système qui remplacerait CBS, le logiciel coeur du Sudoc.

[A propos de la bonne volonté espérée de la part des fournisseurs]

En cas de développement d’un outil de catalogage national extérieur au SGB faute de solution crédible de ce dernier, le fournisseur sera-t-il d’accord pour que son SGB soit interconnecté avec l’outil de catalogage qui serait développé par l’ABES ? Assurera-t-il la synchronisation entre le SGB et la base miroir ? Et entre son SGB et celui d’un concurrent ?

[Et si la mutualisation ne prenait pas ? – p. 6]

Les établissements sont autonomes. L’ABES n’a ni le pouvoir ni la volonté d’imposer un seul système qui s’imposerait à tous, bien que cela semble la solution la plus simple et rationnelle.

[De l’impossibilité de ne rien faire en attendant que l’horizon s’éclaircisse]

Il n’est pas possible de reporter toute décision dans l’attente de dissiper toutes ces incertitudes : ce serait figer toute évolution d’un dispositif qui doit s’adapter à la nouvelle donne du signalement du numérique. L’initiative d’une base de connaissance publique menée en collaboration avec nos partenaires européens pourrait constituer une première étape du dispositif.
Ne rien faire pourrait entraîner le délitement du réseau Sudoc : une bibliothèque du réseau a déjà signé un contrat pour une solution hébergée. Elle prévoit de ne plus produire dans le Sudoc et demande à alimenter le catalogue collectif depuis la base internationale. Ce mouvement peut faire des émules.

Quel l’horizon ? — Photo FlickR by Norma Desmond – CC-BY-NC-SA-2.0

Les enjeux

Petit rappel sur l’évolution interne du projet initial et définition de la notion de SGB (p. 10) :

À l’origine, il s’agissait simplement de faire une économie d’échelle par l’utilisation d’un SIGB commun à plusieurs établissements. Il s’agissait aussi de réduire le nombre de systèmes pour en simplifier l’interopérabilité. L’ABES aurait alors essentiellement joué le rôle de porteur d’une commande groupée.

La réflexion a pris une autre dimension avec l’arrivée des premiers systèmes de gestion de bibliothèque de nouvelle génération caractérisés par :
Le remplacement de l’acquisition d’un système local par un abonnement à un service dans les nuages (« Software as a Service ») ;
L’usage, par toutes les bibliothèques abonnées au service, d’un seul système commun […];
[…] une plate-forme de création et de partage de nouveaux services;
L’intégration et la rationalisation des circuits de traitement des collections physiques et des ressources en ligne […]
L’intégration et la rationalisation des multiples systèmes locaux : SIGB, prêt entre bibliothèques, liste AtoZ, ERMS, [etc]
La fourniture d’un vaste ensemble de métadonnées internationales

Sur les limites du Sudoc actuel concernant les ressources électroniques et quelques échecs antérieurs (p. 10-11) :

Le catalogue SUDOC ne parvient pas à organiser efficacement le signalement des ressources électroniques malgré les demandes de plus en plus pressantes des établissements[…]

Trois projets dans ce sens ont échoué.
En 2004 le projet APE (Accès aux périodiques électroniques) […].
Au même moment le projet de Portail SUDOC visait à donner accès à l’ensemble des ressources documentaires des établissements […].
En 2010-2011 le projet d’ERMS, porté au départ par Couperin […]

Pour résumer (p. 13)

Un SUDOC dans les nuages incluant les fonctions des systèmes locaux apporterait :
– Une solution à la gestion et au signalement des collections électroniques,
– Une amélioration du signalement des collections imprimées (voir 2.1.4)
– Une économie d’échelle.

Like – Photo FlickR by SalFalko — CC-BY-NC-2.0

Impacts pour les établissements > Technique et organisation

Voir d’abord le plan des différents aspects abordés :

impact etablissements

Concernant les besoins en formation et la « répartition des compétences techniques » (partie 2.1.2, p. 12)

Le service d’informatique documentaire devra paramétrer le niveau local du SGB. Il pourra en adapter le fonctionnement local via des API, voire reconfigurer les workflows de certains services ou créer de nouveaux services sur la plate-forme de services partagés. Les établissements souhaiteraient que l’ABES organise des formations nationales à ces outils et prenne en charge des adaptations communes.

Sur les données locales, qui cesseront d’être locales (partie 2.1.4, p. 13)

La distinction actuelle entre catalogage local et catalogage partagé sera profondément remaniée. Le SGB distinguera différents niveaux de données, des données globales partagées librement au niveau international, des données propres à un groupe de bibliothèques, des données propres à une bibliothèque. Mais toutes ces données seront liées entre elles dans un système unique et il n’y aura plus de copies de données entre système local et système central.

Sur le catalogage local, qui lui aussi cessera de l’être (partie 2.1.7) — les établissements seront-ils d’accord (à voir : quelles sont les raisons du maintien d’un catalogage local ?)

Sur l’intégration entre le SGBM et le système d’information de l’établissement (partie 2.1.8, p. 15 du PDF) : j’invite tout particulièrement tous ceux qui ont à gérer ces interconnexions avec Apogée, Sifac, le CAS de leur établissement à évaluer la fluidité et l’optimisme de la description avec les difficultés qu’ils peuvent actuellement rencontrer.

Impact pour les établissements > Questions économiques

Tout simplement,

Le passage d’un SIGB local au SGB sur le Web constitue un changement de modèle économique. L’établissement n’acquiert plus ni logiciel ni matériel mais seulement un service auquel il s’abonne annuellement.

Dans ce contexte nouveau, le modèle économique des fournisseurs est tout à fait différent

Dans ce contexte la notion de support aux établissements, qui représente aujourd’hui le plus gros coût, change de sens. Il n’y a plus à proprement parler que le système commun qui soit susceptible de pannes ou de dysfonctionnements. Un dysfonctionnement spécifique à un établissement ne peut guère être qu’une inadaptation du système commun à un fonctionnement local particulier ou une erreur de paramétrage du niveau local du système commun ou un problème dû au réseau local.

Attention, il y a dans le document une partie « Impacts économiques sur les établissements », et une autre plus loin « Impacts économiques sur l’Abes, répercutés sur les établissements« . Ne la ratez pas !

Cette partie contient notamment en point 3.2.2 (ou dans le PDF : p. 27) une évocation des (sur)coûts durant la phase de test, où il faut maintenir le système actuel, et déployer en même temps un nouveau système : donc ressources humaines et compétences, maintenance, etc.

L’étude d’impact SGBM m’a permis de découvrir la procédure du dialogue compétitif : une vraie mise en production du logiciel sur plusieurs établissements pour tester l’outil et ses limites en grandeur nature. La rédaction du cahier des charges est faite en cours de route.

Si la formule du dialogue compétitif est retenue, qui implique de tester les solutions de plusieurs fournisseurs sur une longue durée (12 à 18 mois), les frais afférents seront partagés entre toutes les bibliothèques SUDOC : il ne serait en effet pas équitable de faire supporter la charge financière de la phase de test aux seuls bibliothèques pilotes dans la mesure où le système retenu le sera à terme pour l’ensemble de la communauté, qui doit ainsi participer à la charge financière des tests.

Donc même si votre établissement n’est pas pilote, vous êtes immédiatement concernés.

Je ne souligne pas ce genre d’extrait pour vous inciter à la révolte, mais pour vous permettre de réaliser que l’impact est immédiat pour l’ensemble du réseau. Le raisonnement tenu ci-dessus me semble par ailleurs tout à fait…. raisonnable.

Et puisqu’on parle de coûts, j’ai trouvé une phrase d’une construction un peu complexe, dont j’irai prochainement m’assurer que je l’ai bien comprise (p. 27)

Comme aujourd’hui avec le catalogue SUDOC, Il ne s’agira pas de faire payer aux établissements l’ensemble des services rendus par l’ABES qui ne leur facture actuellement que les coûts directs du SUDOC hors dépenses de personnels fonctionnaires.

Impact sur les établissements > Questions juridiques

Bien évidemment, est posée la question des données personnelles :

En matière de données personnelles, outre l’application des recommandations générales, il faut attirer l’attention sur deux points, la localisation et le contenu des données. Deux pays, le Canada et l’Australie, ont déjà imposé aux fournisseurs de SGB que les données personnelles soient hébergées par des data centers nationaux. Le comité de pilotage a recommandé que le projet de l’ABES étudie la possibilité d’un hébergement en France (projet de Cloud Ile-de-France) ou du moins en Europe. Il est possible de réduire au minimum le contenu des données personnelles transférées. Un SGB peut a priori fonctionner avec seulement le nom de l’usager et son identifiant numérique, codes-barres ou numéro de puce sans contact. Toutefois les besoins fonctionnels d’une bibliothèque nécessiteront souvent plus d’informations : adresses de mail et de courrier, téléphones pour les rappels de documents en retard et la communication ; niveau et domaine d’étude ou de recherche pour déterminer les droits d’accès et établir des statistiques d’usage.

Impacts pour l’Abes > Impacts techniques

Petit rappel :

Les transferts réguliers ne sont qu’une partie des nombreux traitements d’export régulier (Worldcat,
INIST, VIAF, RNBFD, Google Scholar) et d’import régulier (BnF, ISSN, Fmesh, Springer) ou ponctuel
(licences nationales).

On veut bien le croire :

(je note au passage le projet de Reverse Proxy, dont je suppose qu’il doit aller avec l’outil de signalement national des ressources en ligne ?)

SGB open source ou commercial ?

Le principe d’avoir un logiciel open source, pourquoi pas — mais sans utilité immédiate derrière

Il serait souhaitable que l’appel d’offres de l’ABES suscite une offre basée sur un produit open source susceptible d’être comparée aux offres commerciales. Mais il faut aussi souligner qu’un SGB en open source n’aurait pas exactement les mêmes avantages que les logiciels open source utilisés aujourd’hui en bibliothèque. Un SGB est un système unique pour toutes les bibliothèques. Chacune pourra consulter le code source et peut être mieux comprendre comment adapter tel service, lorsque ce sera prévu et possible, ou comment ajouter un nouveau service, mais elle ne pourra en aucun cas adapter le code commun à ses propres besoins. C’est la raison pour laquelle les fournisseurs commerciaux estiment offrir une solution équivalente avec une bonne documentation sur les fonctions de base du système couplée à une plate-forme de services ouverte.

Je suis certains que de nombreux collègues pro-actifs sur l’open source auraient à commenter cette réflexion — ne vous gênez pas !

SGBM et Discovery Tool national

L’autre étude (menée par le cabinet Pleiade) est évoquée dans son articulation avec le futur SGBM, notamment en 5.1.5 (p. 32) au sein de la partie 5.1 « Eléments de choix pour un scénario ») :

Cette base doit permettre le signalement des périodiques en ligne, mais aussi une recherche au niveau de l’article

Elle sera alimentée parallèlement par les bases de connaissance open source GOKb et Knowledge Base+. L’ensemble des établissements du réseau SUDOC pourra localiser ses ressources électroniques dans la base nationale.
[…]
Seules les données d’articles acquises dans le cadre national (licences nationales, plate-forme ISTEX) seront intégrées au catalogue national.

SGBM et RDA

Dans tous les scénarios évoqués (en particulier en première ligne de la procédure de mise en place du scénario 1) est mentionnée la création d’un profil RDA.

Même si je soupçonne vaguement de quoi il s’agit (déclaration d’un profil de l’institution, pour disposer d’une URI dans un environnement de catalogage RDA où toute autorité, y compris l’autorité catalogueuse, doit disposer d’une notice d’autorité — donc d’une URI), j’avoue ne pas savoir où ce genre de choses se passe, et quelle forme ça peut prendre.

C’était ma parenthèse « technique »…

Conclusion

Ces extraits ne sont donc décidément pas représentatifs de tous les points abordés par le document. Ce n’était pas mon ambition, donc je ne suis pas sûr de devoir m’excuser du résultat.

Comme ce centon a été (re/dé)composé en plusieurs fois, j’espère qu’il reste globalement compréhensible.

Horizons gyroscopiques II – Photo FlickR by Dopamind – CC-BY-NC-SA-2.0

Publicités
4 commentaires
  1. Yannn permalink
    15/04/2013 08:30

    A propos de « profil RDA » :
    ton interprétation est très astucieuse et cohérente, mais c’est pas ça ! 🙂
    Il s’agit, si je ne me trompe, de la notion Dublin Core de « profil d’application » : http://dublincore.org/documents/2001/04/12/usageguide/glossary.shtml#A (mais cette notion est méthodologique, donc générale : elle ne suppose pas l’emploi d’un vocabulaire DC).
    En gros, RDA est davantage un cadre général qu’une guide de catalogage tout cuit. Il contient beaucoup d’indéterminations (voulues ou non), il ménage beaucoup d’options. Au moment de cataloguer, il faut bien lever ces indéterminations, choisir une solution plutôt qu’une autre… C’est à cela que servent les profils RDA.
    Une bibliothèque qui se lancerait dans RDA tout court serait vite perdue, embarrassée par les nombreux choix concrets à effectuer : soit ses catalogueurs devraient effectuer ces choix au moment de cataloguer, à l’improviste, au risque de l’incohérence et de l’inefficacité ; soit elle établirait des règles, ie elle rédigerait son propre profil RDA..
    D’après http://rda.abes.fr/2012/02/28/compte-rendu-de-la-reunion-technique-deurig-paris-27-janvier-2012/ il n’est pas question d’un profil européen. Par contre, il est plus probable qu’il existe un jour un profil RDA Sudoc. Si les petits cochons…
    Enfin, et je continue de répéter ce qu’on m’a dit, la conception et la rédaction d’un tel profil, c’est beaucoup de travail. Sans parler de son implémentation, la formation….
    Ph. Le pape @FinalementNon complétera et corrigera, s’il le faut.

    Merci pour cette série de billets !

  2. 15/04/2013 17:51

    Oui beaucoup de travail. C’est une épine, ce RDA. Ça vient trop tard, d’au moins 10 ans. Il aurait mieux valu mourir avant.

    Ph.

Trackbacks

  1. Mise en place du SGBM : étude d’im...
  2. Plus que 10 jours pour commenter l’étude d’impact ! | Système de gestion de bibliothèque mutualisé

Commentaires fermés

%d blogueurs aiment cette page :