Principe

Vous avez deux tableaux, qui contiennent tous deux une colonne où se retrouvent des identifiants communs (n°, ISBN, code-barres, titre, etc). Le tableau 1 est celui que vous voulez enrichir, avec des infos tirées du tableau 2.

Cela ne permet pas exactement de jointer deux tableaux, mais de reproduire dans le tableau 1 tout ou partie des infos du tableau 2, sur la base d’un identifiant commun (présent n fois dans le tableau 1, mais 1 fois dans le tableau 2)

La fonction RECHERCHEV() contient les paramètres suivants :

• Paramètre 1 : dans le tableau 1, quelle valeur va devoir être retrouvée dans le tableau 2 (l’identifiant commun)
• Paramètre 2 : où est le tableau 2 (dont la 1ère colonne contient l’identifiant qu’on va chercher comme premier paramètre)
• Paramètre 3 : si on trouve dans la colonne 1 du tableau 2 l’identifiant défini comme paramètre 1, quelle valeur récupère-t-on (donc : n° de colonne du tableau 2)
• Paramètre 4 : FAUX
  (FAUX pour dire : la correspondance des deux identifiants doit être exacte)

Ca a l’air un peu abstrait ? C’est pourtant très pratique, donc on va voir ce que ça donne en vrai

Exemple 1 : enrichir une liste d’informations extraites d’une liste plus longue

Imaginons un prof qui vous envoie une bibliographie de 100 ouvrages : Titre, Auteur, ISBN (sympa !). Vous voulez enrichir cette liste de leur cote (quand vous en avez un exemplaire dans votre bibliothèque).

Une solution un peu brutale, mais rapide, consiste à extraire la liste de vos dizaines de milliers d’exemplaires (même si Excel 2007 accepte désormais 1 million de lignes, mieux vaut quand même l’éviter) avec : ISBN, localisation, cote.

• Le tableau 1 sera donc celui de l’enseignant (100 lignes)
• Le tableau 2 sera votre liste d’exemplaires (disons : 7811 lignes – c’est comme ça)

Dans chaque tableau, la première colonne est l’identifiant commun, à savoir l’ISBN (nettoyé, c’est-à-dire sans tiret — c’est mieux pour être sûr de matcher plus aisément les 2 listes).

Dans le tableau 1, je rajoute en dernière colonne à droite la formule qui va

• [Paramètre 1] prendre l’ISBN de la première colonne du tableau 1
• [Paramètre 2] chercher cette valeur dans le tableau 2
• [Paramètre 3] s’il trouve l’ISBN, prendre la 2e colonne (la localisation)
• [Paramètre 4] faire une correspondance exacte sur l’ISN (‘FAUX’)

Ce qui me donne pour la première ligne (cellule D4) la formule : RECHERCHEV(A2;$F$2:$I$7812;2;FAUX)

Exemple 2 : attribuer une typologie plus large sur la base d’une typologie fine

Imaginons que vous ayez 2 listes :

1. La liste des étudiants emprunteurs de votre Université, avec mention du code Diplôme dedans (extraction du SIGB)
2. La liste des codes Diplômes, avec libellé complet et mention du cycle et de l’UFR

Si vous voulez faire des stats sur votre population d’étudiants et leurs pratiques de prêt, il est vraisemblable que les sous-groupes par code diplôme seront trop réduits : il sera donc plus utile d’exploiter l’info Cycle et/ou UFR.

Vous avez donc besoin d’attribuer à chaque étudiant son cycle et son UFR, à partir de la seconde liste.

Puis

Bon, il faut me croire sur parole si je dis que chacune des valeurs présentes (de manière répétée) dans la colonne C [tableau 1] l’est également (mais une seule fois) dans la colonne G [tableau 2].

Je suis convaincu que pour la gestion de la documentation électronique, par exemple, cette fonction peut se révéler très utile (par exemple si on a un tableau avec des ISSN et des stats, et un tableau avec des ISSN et des prix ou des noms de collections Elsevier).

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 :

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

———————–

Synthèse de l’étude d’impact SGBM

L’Abes vient de produire le résultat de 2 études, avec appel à réactions et commentaires de la part du réseau.

Voici une présentation concise de l’un de ces 2 documents : l’étude d’impact de la mise en place d’un SGBM (système de gestion de bibliothèque mutualisé).

Ce document rappelle d’abord l’historique du projet, avant d’en décrire les principaux enjeux.

Le SGBM est défini comme un outil de gestion des collections de tous types (monographies et périodiques, papier et en ligne, acquises ou numérisées), dans toute la chaîne de traitement de ces ressources (acquisitions, signalement, prêt-retour, désherbage).
Cet outil serait mutualisé dans toutes ses fonctionnalités, pour l’ensemble du réseau ou presque.
Le document commence donc par définir les contours de cet outil (en insistant particulièrement sur l’émergence des outils de découverte « de nouvelle génération », et leur caractéristique propre d’être systématiquement dans les nuages).

Avant d’évoquer et décrire les 3 scénarios envisagés, l’étude décline les impacts qu’aura la mise en place d’un SGBM pour les établissements, pour l’Abes et pour le réseau Sudoc, dans ses aspects :

• organisationnels et techniques
• juridiques
• financiers

Puis il donne un calendrier de déploiement envisagé (compter 5 ans au moins pour le gros des migrations).

Les scénarios vont pour l’essentiel décliner plusieurs manières de concevoir cette « mutualisation » :

• Instance unique, centralisée (sur des serveurs) à laquelle se connecteraient les établissements pour travailler
• Instances multiples interconnectées
• Hybride

Pour en donner un des aspects techniques les plus immédiats et significatifs : l’adoption d’un SGB permettrait pour chaque bibliothèque de n’alimenter et gérer qu’une seule base, et de se passer des chargements quotidiens des notices Sudoc à jour. Les collections de la bibliothèque seraient dans une seule base, accessible immédiatement

• à la fois depuis l’outil de gestion utilisée par la bibliothèque
• et par l’interface de recherche nationale des collections des BU (actuellement http://www.sudoc.abes.fr/).

Cf. ci-dessous un schéma qui récapitule les 3 scénarios envisagés

Les 3 scénarios envisagés dans l’étude d’impact SGBM

Pour chaque scénario, l’étude d’impact propose aussi des schémas assez complexes sur les articulations entre les outils, parce que :

• Ils présentent en une image la diversité des situations et la coexistence d’outils multiples
  (or aucun établissement n’a tous ces outils et n’est dans toutes ces situations à la fois)
• La distinction entre les rectangles "données" et les rectangles "interfaces d’accès à ces données" (en lecture/écriture) n’est pas immédiatement visible.
  De même la distinction entre les installations locales et les interfaces "personnalisées" à une base globale n’est pas évidente

 Pour comprendre les problématiques évoquées et les scénarios retenus, il faut revenir sur 2 aspects qui se sont rajoutés en cours du projet à la demande initiale (plusieurs établissements voulant réinformatiser au même moment) :

1. l’apparition des outils de nouvelle génération dans les nuages, comme Alma et WMS (d’OCLC)
   Conséquence : L’Abes a renoncé à faire un simple groupement de commande pour des SIGB classiques, et décidé de passer à une autre dimension du projet.
2. la nécessité du remplacement de CBS (outil de gestion de la base Sudoc derrière WinIBW), qu’OCLC cessera de maintenir bientôt
   Conséquence : L’Abes doit coupler la migration dans un futur SGB à la question du remplacement de CBS, en partant du principe qu’il n’est pas garanti qu’un de ces SGB soit capable d’assurer cette mission de catalogage national.

La présente synthèse ne restitue évidemment de tous les aspects qu’évoque le document. A titre d’exemple, l’étude d’impact prend aussi en compte le cas des établissements qui ne migreraient pas (ou pas avant trèèèès longtemps) et pour lesquels les chargements Sudoc demeureraient une nécessité.

Le 29 mars ont été publiées sur le fil de l’Abes 2 études :

• Etude d’impact de l’implantation d’un SGBM au sein du réseau Sudoc – impact pour les établissements, pour l’Abes et pour le réseau
• Rapport de la société Pléiade sur des scénarios de mise en place d’un discovery tool pour réaliser un signalement national des ressources électroniques

Dans la foulée paraissaient les sites ouverts à commentaires, sur ces mêmes études (étude d’impact SGBM, discovery tool). Et l’Abes lançait un appel à réactions et commentaires de la part du réseau, "de préférence avant le 15 mai".

C’est la deuxième fois (à ma connaissance) que l’Abes s’efforce de solliciter de manière ouverte son réseau, incontestablement solide et actif, sur un projet précis.

Souvenez-vous le projet d’établissement (Arabesques 65, février-mars 2012)  :

Nous avions aussi placé des espoirs dans la mise en commentaire sur le web des idées charpentant notre projet. Force est de reconnaître que nos attentes – sans doute naïves – furent largement déçues à moins que la période – l’été – n’ait été mal choisie : les commentaires se sont comptés sur les doigts des deux mains.

Je ne suis pas community manager, je n’ai pas de trucs, astuces et conseils à donner à l’Abes (ou à qui que ce soit, d’ailleurs), pour expliquer comment il faudrait faire.

Ce que je peux essayer d’expliquer, en revanche, c’est pourquoi dans le cas présent la méthodologie utilisée risque de (me/nous) poser quelques difficultés.

Le principal problème : le comité technique, qui existe depuis déjà pas mal de mois et travaille au projet, engage des établissements. L’étude évalue l’impact d’un SGB sur les établissements. Ce sont donc aux établissements de réagir à cette étude pour voir s’ils s’y retrouvent.

En gros : j’envisage difficilement de lire l’étude SGB puis d’aller la commenter à titre personnel sur le site dédié.

Si je suis intéressé par le projet (ce que je suis !), il faut donc que je puisse parler au nom de mon établissement. Même mieux : que mon établissement se soit engagé dans une lecture, et un retour construit et constructif sur cette étude.

Cela signifie

• soit une délégation forte de la direction, où je partirai en électron libre : j’émettrai des remarques sans aucun doute pertinentes, mais sans avoir consulté mes collègues (donc pour "l’intelligence collective", on repassera)
• soit une lecture et discussion au niveau du conseil de direction
• soit la constitution d’un groupe de travail

Dans tous les cas

• c’est donc à moi de convaincre ma direction
• c’est à moi de dégager du temps pour m’y plonger, et (dans les scénarios 2 et 3) de faire en sorte que les collègues en trouvent
• c’est à moi d’organiser le tout en urgence, pour avoir produit d’ici le 15 mai quelque chose d’intéressant
  (je rappelle que d’ici le 15 mai, il y a les vacances d’avril et déjà quelques ponts)

N’aurait-il pas été plus simple :

1. que ma direction soit informée de cette demande de l’Abes directement par l’agence (soit par un courrier/courriel de M. Bérard aux directeurs, soit par un appel sur le forum de l’ADBU)
   pour éviter que ça ne vienne "d’en bas"
2. de la prévenir 3-4 semaines à l’avance, afin d’anticiper ce chantier et de l’intégrer au mieux dans le calendrier des autres activités (par exemple : les enquêtes Couperin…)

Pour le reste, je vais faire au mieux, en diffusant l’information en interne, en insistant particulièrement sur les pages les plus vibrantes du rapport SGBM : ainsi cette sous-partie intitulée "3.2 Des coûts répercutés aux établissements" (p. 27).

Ca donne envie de se demander ce qu’ils nous réservent, non ?

(précision ultime : quand j’écris "je" ci-dessus, ce n’est pas pour laisser croire que je, Etienne Cavalié, sois le seul de mon établissement à suivre ces questions : c’était un "je philosophique", comme disait ma prof de terminale)

(le titre de mon billet est un mauvais jeu de mot partant de l’expression Meeting in the Middle qui, à ma connaissance, n’a rien à voir avec l’univers de Tolkien. Que les anglicistes chevronnés et les spécialistes d’Heroic Fantasy daignent me pardonner)

Demandez à des bibliothécaires ce qu’ils pensent de Wikipedia, et vous obtiendrez sans doute quelques réponses intéressantes. Certains se lamenteront sur la paresse de cette génération Google et de leur hyper-dépendance à l’égard de Wikipedia.

Certains décriront avec fatalisme l’excellence de leurs collections ignorées au profit des ressources en ligne.
Certains le verront comme une "compétition". Et certains vous diront que c’est la plus grande invention depuis le fil à couper le beurre.

Wikipedia et les bibliothèques travaillent dans le même domaine : les 2 veulent accroître la quantité des connaissances disponibles pour le plus grand nombre possible, gratuitement.

Mais en dépit de ces objectifs communs, les 2 entités sont encore restées très distantes l’une de l’autre.

Certes, il existe des bibliothécaires wikipediens, et il existe des bibliothèques qui travaillent avec les projets GLAM de Wikipedia.

Il y a Wikipedia Loves Libraries.

Les wikipédiens ont développé des outils et des liens pour aider à intégrer les ressources des bibliothèques, mais tout cela reste sous-utilisé.

Les bibliothèques contiennent de vastes réserves de connaissances, et beaucoup veulent venir à la rencontre de Wikipedia, d’une manière ou d’une autre. Comment Wikipedia peut participer à la construction du pont pour accéder à cette connaissance ?

Interfaces actuelles Wikipedia-Bibliothèques

Un des freins à l’intégration est le système de catégorisation de Wikipedia.

Dans ses premiers jours, Wikipedia a évité d’adopter les schéma standard organisationnels utilisés dans les bibliothèques, comme l’indexation matière de la Bibliothèque du Congrès.

Les bibliothèques attribuent plusieurs mots-clés à leurs items : Wikipedia se contente d’un titre unique, et parfois un mode de désambiguïsation entre parenthèses. Les catégories Wikipedia sont venus plus tard, et sont ajoutées (ou pas) au bon vouloir des contributeurs.

Certains efforts ont été faits pour intégrer les pages de Wikipedia dans des contextes plus larges de métadonnées "library-friendly".

Le projet VIAF est une tentative d’unifier les différents systèmes de gestion des autorités utilisés par les bibliothèques nationales. Un modèle fournissant des liens VIAF a été ajouté à de nombreux articles biographiques (cf. les commentaires sur le modèle VIAF pour Wikipedia). Les bibliothèques bénéficient également de la page Special:BookSources, qui exploite le modèle de citation sur la base d’une requête sur ISBN. Cette page permet aux lecteurs d’utiliser des catalogues collectifs comme WorldCat d’OCLC, et de trouver l’item cherché dans une bibliothèque proche de chez lui. OCLC fournit égalemetn un lien vers les livres à travers l’infobox Livre. Quoi qu’il en soit, ces liens et services ne fournissent pas d’état de collection de la bibliothèque "locale" sur un sujet, ils ne font que pointer vers une ressource spécifique si demandée.

Les bibliothécaires ont continué d’explorer différentes manières d’associer leurs collections avec les articles Wikipedia correspondants. Les efforts de l’Université de Washington et de l’Université de Houston ont visé à ajouter des liens externes vers des pages de collections pertinentes. Certains ont esséy d’utiliser les partenariats GLAM avec des wikipediens expérimentés pour améliorer l’intégration de leurs ressources dans WIkipedia.

Un nouvel outil

John Mark Ockerbloom, architecte d’une bibliothèque numérique et planificateur à l’Université de Pennsylvanie, a conçu un outil différent, appelé : "Vers les bibliothèques" (Forward to libraries).

Ce service utilise le titre de l’article Wikipedia comme sujet ou mot clé de recherche dans la bibliothèque choisie par l’utilisateur, en utilisant l’opac de cette bibliothèque. On peut choisir sa bibliothèque dans une "sous-page", ou d’installer un cookie. Ockerblomm a échangé sur ses idées dans un blog la semaine passée.

Cory Doctorow, contributeur de Boing Boing, auteur de fiction et wikipedien a été impressionné et a qualifié le template de "formidable proposition pour créer des synergies de recherche entre les bibliothèques et Wikipedia".

Le nouveau modèle d’Ockerbloom se trouve à l’adresse : http://en.wikipedia.org/wiki/Template:Library_resources_box.

Pour en voir un exemple d’utilisation, voyez dans la section "Further reading" de la page Louisa May Alcott.

[La suite de l'article est une interview de John Mark Ockerbloom]
[Puis reprise de l'article]

Modèles et questions visuelles

Les modèles qui créent des boîtes dans les pages Wikipedia ne sont pas universellement acceptées chez les contributeurs. Beaucoup les trouvent peu esthétiques, et contestent leur utilités. Ces modèles peuvent aussi accroître le temps de chargement des pages, d’une manière disproportionnée pour les connexions à faible débit.

S’il y en a un trop grand nombre dans un article, le lecteur doit supporter un "template ghetto" en bas de page. Et en mode écriture, le modèle de boîte "Library Resources" n’a pas été soumis au vote d’une large communauté, même s’il a déjà attiré l’intérêt sur la page de commentaires. Il reste à voir comment l’idée va évoluer, et s’il gagne en soutien de la part des wikipediens.

Il n’y a pas qu’une seule manière pour une bibliothèque d’interconnecter ses ressources avec Wikipedia. La communauté n’a pas pour l’instant priorisé ce genre de relations. Néanmoins une chose est certaine : les bibliothèques veulent travailler avec Wikipedia. Vont-elles trouver un terrain de rencontre ?

Télécharger le nouveau translator UnimarcXML

(Ouvrir le lien, enregistrer le fichier sur son poste — de préférence en l’appelant "UnimarcXML.js". Pour la suite de la procédure d’installation, celle-ci est toujours valable si vous voulez savoir où déposer ce fichier.)

Il faut aussi que j’apprenne à me professionnaliser, sur tous ces types d’outils, en utilisant les canaux adaptés.

Pour un petit bout de code comme ça, Julien a déposé sa mise à jour sur Github (en fait, là c’est Gist — faut encore que j’apprenne la différence entre les deux). J’en ai fait un fork ("fourche") pour y ajouter un paramètre qui manquait (l’URL en 856).

C’est plus sérieux que mon utilisation initiale de Google Docs pour vous proposer ce fichier.

Il me resterait encore à y ajouter quelques nouveaux paramètres pour prendre en compte les spécificités des thèses. Mais comme ce translator a surtout été conçu à destination de bibliothécaires, pour gérer leurs paniers d’acquisitions dans Zotero et les exporter ensuite vers leur SIGB pour passer des commandes… la "commande" de thèses n’est pas ce qui se fait de plus fréquent.

Donc je préfère indiquer dès à présent le translator mis à jour (d’autant que certains insistent !), et voir plus tard pour les améliorations.

N’hésitez pas à

Le 20 février 2013 est sortie une série de nouvelles consignes de catalogage pour décrire les documents dans le Sudoc, en lien avec la future FRBRisation des données.

Comme mon travail n’est ni de cataloguer, ni même d’animer le réseau des catalogueurs de mon SCD, je ne vous entretiendrai pas directement de ces nouvelles consignes, de leur intérêt, de leur enjeu, de leur complexité ou tous autres aspects de ce genre.

Je vais simplement vous expliquer comment nous essayons de les prendre en compte pour les faire entrer — façon méthode douce — dans les pratiques de catalogage des courageux collègues qui s’y attèlent chaque jour, et doivent ajouter de nouvelles règles aux anciennes déjà existantes.

Dans ce projet de FRBRisation du Sudoc, les consignes de catalogage sont  à deux niveaux :

1. une insistance nouvelle sur des règles déjà existantes — parce qu’elles ont une importance nouvelle
2. de nouvelles règles

Contrôle bibliographique de données FRBR – Photo FlickR de rarewren – CC-BY-NC-SA-2.0

Réponse technique

Dans notre SIGB (Aleph), le chargement quotidien des données du Sudoc (mises à jour "propres", avec redescente uniquement quand nous modifions les notices) donne lieu à un rapport, produit automatiquement, qui liste les n° de notices ajoutées, modifiées et rejetées, par RCR. Ce rapport est produit dans Aleph au format HTML.

Nous avions déjà fait il y a quelques mois un travail de retraitement de ce fichier (en local — sans modifier le programme qui génère ce fichier pour conserver intacte la maintenance associée à l’outil auprès du prestataire) pour en faire du XHTML.

Le XHTML, c’est du XML + HTML :

• on peut l’ouvrir dans un navigateur
• on peut lui appliquer une feuille de style XSL pour retransformer le fichier, notamment
  • modifier le format d’affichage (jouer sur l’ordre de tri, etc.)
  • appeler des API, c’est-à-dire des informations extérieures, sur la base des informations présentes dans le fichier.

Dans ce rapport, il y a donc les n° des notices chargées.

Or il existe une API Aleph qui permet de récupérer la notice en MarcXML en construisant une URL contenant le n° de notice. Donc on récupère cette notice en MarcXML, on l’ouvre et on en contrôle le contenu.

Bien évidemment, le code XSL qui va contrôler ce contenu n’a pas le livre en main ! Il n’est donc pas question de vérifier la qualité du catalogueur ! Simplement, une succession de tests vont vérifier la cohérence interne de la notice.

Voici quelques exemples (nous n’avons pas encore exploré l’ensemble des consignes FRBR pour voir comment les traduire en contrôles automatisés) :

• Tous les 7XX ont-ils un $4 (code de fonction)
• S’il se trouve un traducteur dans les 7XX ($4 = 730), y a-t-il un titre original en 454 ? — et réciproquement
• Si un code 205 existe (ce qui signifie que ce n’est pas la première édition, mais forcément une réédition), vérifier qu’il y a une mention "cop." dans 210 $$d (mention de la date de copyright)

J’insiste : je ne suis pas catalogueur, et dans ma manière de formuler ces exemples je peux me fourvoyer. Cela n’a aucune importance puisque mon seul rôle sera de transformer en XSL les contrôles qu’on me demandera d’appliquer : d’autres se chargent de décortiquer les consignes de l’Abes, donc je m’en décharge allègrement. Merci de votre indulgence sur cet aspect !

Par exemple, dans la feuille XSL se trouve le code suivant qui contrôle le 700$4 :

<!--Vérifs sur le code fonction de l'auteur (zones 7XX)-->
  <xsl:template name="code_fonction_auteur">
    <!--Récup de 2 variables : le n° de notice Aleph et le contenu de la notice Unimarc dans Aleph (API Aleph)-->
    <xsl:param name="no_aleph"/>
    <xsl:variable name="not_url" select="concat($url_opac_aleph, ':8080/X?op=find-doc&amp;doc_num=', $no_aleph, '&amp;base=', $base_bib)"/>
    <!--$not_file : contenu de la notice Aleph en MarcXML (API Aleph)-->
    <xsl:variable name="not_file">
          <xsl:copy-of select="document($not_url)//metadata"/>
    </xsl:variable>

    <p>Vérifs code fonction Auteur (7XX)</p>
    <ul>
      <xsl:for-each select="$not_file//varfield[starts-with(@id, '7')]">
        <li>
            <xsl:value-of select="position()"/><xsl:text> : </xsl:text>
              <xsl:choose>
                <xsl:when test="subfield[@label = '4'] != ''"><xsl:text>OK</xsl:text></xsl:when>
                <xsl:otherwise><xsl:text>Pb</xsl:text></xsl:otherwise></xsl:choose>
        </li>
      </xsl:for-each>
    </ul>
    <xsl:if test="not($not_file//varfield[starts-with(@id, '7')])">Pas de zone 7XX</xsl:if>
  </xsl:template>

Rapport actuel

Rapport avec contrôles sur 7XX$4

La "visualisation" du rapport est centralisée, et le signalement des erreurs envoyé à chaque correspondant Catalogue en section qui redistribuera les corrections à faire.

Entre la chaise et le clavier

Ce n’est pas le tout de mettre en place plein de contrôles, il faut encore ménager les collègues.

Chaque agent recevra par mail ses notices corrigées automatiquement au stylo rouge – Photo FlickR de Wootang01 – CC-BY-ND-2.0

En effet avec ce système, les notices vont être contrôlées au lendemain de leur localisation dans le Sudoc, y compris avec les erreurs faites par d’autres BU. Donc si un catalogueur s’est contenté de créer un exemplaire sous une notice existante, il peut se retrouver avec un ensemble de corrections à faire, alors qu’il n’avait rien demandé !

Donc, bien évidemment, pour que ce soit efficace et afin de ne pas dégoûter les collègues, l’ensemble de ces contrôles va être mis en place progressivement, afin d’évaluer, à chaque nouvel ajout, le nombre de notices concernées et le temps nécessaire pour que ce nombre s’approche de 0 : ce qui signifiera que les notices sont propres quand elles arrivent dans notre SIGB, donc qu’on peut ajouter un contrôle supplémentaire qui fera remonter dans les rapports quotidiens le nombre de notices "sales", jusqu’à l’intégration de ces contrôles dans le regard, le cerveau et les mains de nos estimés catalogueurs.

Pour conclure

Le processus démarre tout juste. Il n’est pas exclu que nous butions sur des difficultés techniques ou humaines — par exemple un si grand nombre de problèmes par notices qu’il deviendrait inenvisageable de déployer in fine l’ensemble des contrôles techniquement possibles.

Bref, je signale là une intention, pas un retour d’expérience

L’enjeu

Il y a quelques jours, Symac a initié sur Bibliopedia une page Services numériques en BU, afin de pouvoir décrire et comparer les "services numériques" (au sens décrit dans un précédent billet, c’est-à-dire avec toute la diversité des tâches qui vont ou non rentrer dans cette appellation) entre eux.
Si ce genre de tableau est intéressant, il est à mon sens forcément insuffisant : savoir qu’il y a 3 ou 10 personnes dans un tel service n’est vraiment utile que si ça peut devenir un outil d’aide à la décision, par exemple dans le cadre d’une réflexion sur une réorganisation interne.
Mais pour comparer 2 SCD comptant, l’un 3 personnes et l’autre 10 dans son "service informatique", il faut par exemple savoir

• combien il y a d’étudiants
• combien il y a de campus
• combien il y a de BU
• quelle est la taille du parc informatique public
• quelles sont les stats de consultations du site web ou de l’opac

Certes, on pourrait reproduire ces informations, tirées de l’ESGBU (ou d’ailleurs), dans le tableau sur Bibliopedia.
Mais il est beaucoup plus évident de les croiser de manière plus dynamique avec les données ESGBU, ERE, PAPESR, Insee ou autre, en matchant ces tableaux épars sur la base d’un identifiant commun.
Il faut donc que dans le tableau Bibliopedia, je dispose d’un identifiant unique à l’établissement (désignant le SCD ou l’Université) que je retrouverai ailleurs.

Mise en application

ILN

On pourrait par exemple ajouter une colonne ILN.
Pour ceux qui l’ignoreraient, l’ILN est l’identifiant unique désignant l’établissement dans le cadre de sa participation au réseau Abes. Un ILN regroupe généralement plusieurs RCR — les RCR étant les centres de catalogage dans le Sudoc.
Donc en pratique, on trouve

• Un ILN par SCD
• Un RCR par BU (+ un RCR pour les collections électroniques)

Si on trouve l’ILN dans les stats ESGBU et PAPESR, par exemple, ce peut être une bonne idée.
A noter que si quelqu’un tombe, dans ce tableau, sur l’ILN, il n’aura aucune définition de ce à quoi ça peut correspondre (sauf évidemment à chercher sur Google).

Identifiant PAPESR

Chaque établissement dont les statistiques sont publiées dans PAPESR a un identifiant interne à la base.  Mais comme cette information n’est visible que dans l’URL, et qu’en plus on ne peut pas faire d’URL profonde à cause de la barrière d’authentification, ça n’a aucun intérêt.

Identifiant Wikipedia

On pourrait aussi rajouter une colonne "Page Wikipedia" de cet établissement — en choisissant l’Université (car beaucoup de SCD n’ont pas de page Wikipedia spécifique) ou la bibliothèque (possible pour la BSG, Cujas, etc.).
Cela permet aussi, si on a décidé dans le tableau Bibliopedia, d’indiquer "Université Jules Verne" (parce que politiquement l’Université veut être appelée ainsi pour sa comm), de lier quand même à Université de Picardie : http://fr.wikipedia.org/wiki/Universit%C3%A9_de_Picardie
L’intérêt, en ajoutant cette URL, c’est qu’en cliquant dessus l’utilisateur sait de quoi il s’agit et a déjà des informations complémentaires sur l’institution.

Identifiant DBpedia

C’est le même que l’identifiant Wikipedia, sauf que l’URL racine n’est pas

http://fr.wikipedia.org/wiki/

mais

http://fr.dbpedia.org/resource/

Cela permet du même coup de se raccrocher au web des données (et d’exploiter automatiquement les diverses infos présentes dans la notice DBpedia), et d’utiliser les technologies afférentes.

En soit, dans le cas présent, l’objectif n’est pas forcément d’exploiter les triplets de la fiche DBpedia présents derrière l’URI, mais plutôt :

1. de se mettre dans la philosophie de DBpedia
2. d’utiliser un URI plus souvent utilisé ailleurs, dans d’autres bases qui ont besoin de tels référentiels (et qui utiliseront plus volontiers l’URI DBpedia que l’URL de la page Wikipedia correspondante)

Pourquoi faire intervenir le web des données dans cette histoire ?

Le langage de requête SPARQL, qui exploite les triplets RDF, est particulièrement bien adapté pour la jointure de 2 (ou plus) jeux de données.
Il permet très facilement de jointer plusieurs tableaux utilisant un référentiel (ILN, Wikipedia, DBpedia, etc.) commun.
Il permet aussi très facilement d’associer plusieurs tableaux n’utilisant pas un référentiel commun, mais utilisant des référentiels distincts pour lesquels les correspondances existent.
Quand j’avais exploré la mise en RDF de données statistiques (le dernier billet de cette série est là), j’avais notamment fait une correspondance PAPESR-Wikipedia (donc DBpedia), dans une version RDF/XML (assez rapide
Pour revenir à la question Bibliopedia : l’ajout de l’ILN pourrait être le plus pertinent dans notre contexte, à condition de disposer ensuite d’une table de correspondance.
On trouve la liste des ILN dans la recherche avancée du Sudoc (index "Etablissements documentaires"), en allant fouiller dans le code des pages. J’imagine cependant qu’il en existe une liste plus "officielle" quelque part.
Si ensuite on fait une table de correspondance ILN – Wikipedia, la correspondance ILN – PAPESR se fait toute seule — et on peut donc croiser facilement les données publiées sur Bibliopedia relativement aux services numériques du SCD, avec les données PAPESR.
Dans l’ESGBU, ce sont encore d’autres codes d’établissements : les mêmes qu’on retrouve sur Poppee. Bref, il faudrait (et il serait pertinent) de faire là encore une table de correspondance vers Wikipedia, DBpedia ou ILN.
Le résultat une fois qu’on a tout ça ?

• identifier l’établissement qui me ressemble le plus en nombre d’ETP du SCD, d’étudiants, de nombre de salles de lecture et de postes informatiques
• et voir si les ressources humaines mises sur les questions informatiques sont les mêmes
• si mon établissement a mis plus de "monde" sur les services numériques :  voir si les stats de consultation de l’opac  et du site web fournissent des résultats en proportion(ce n’est qu’un indicateur parmi d’autres, mais c’est le seul, sur l’ESGBU, qui permette d’évaluer l’efficacité des moyens mis en oeuvre)
  (ce n’est qu’un indicateur parmi d’autres, mais c’est le seul, sur l’ESGBU, qui permette d’évaluer l’efficacité des moyens mis en oeuvre)

C’est d’une utilité évidente, non ?
Pas forcément sur cette question-là des services numériques en BU, mais de manière générale de fournir un URI (pour faire court : identifiant unique qui prend la forme d’une URL) dans la perspective d’une utilisation élargie, ultérieurement.

Question annexe : où mettre ces tables de correspondance ?

Il faudra évidemment disposer d’un tableau d’équivalences ESGBU-PAPESR-ILN-identifiants Ministère-DBpedia-Wikipedia.
Certains bouts existent déjà forcément à droite ou à gauche. Ca peut se faire très simplement dans un tableur Google Docs public (ou un fichier RDF/XML sur la même plate-forme). Mais je ne connais pas de base qui hébergerait spontanément ce genre d’infos produites par des citoyens lambda. Freebase peut-être ? On suggère Open Metadata Registry, dont j’ignore tout (j’ai l’impression qu’il permet surtout d’enregistrer des vocabulaires, des ontologies — là, il s’agit juste de relier les ressources par paires, avec le prédicat “owl:sameAs”).

<Mise à jour du 3 mars>En fait, je me demande si tout simplement la vraie bonne source ne doit pas être VIAF, qui est là pour gérer les autorités à destination des utilisateurs du web des données (homme et machines), avec correspondances entre différents identifiants désignants une même ressource, etc. Sauf que j’ignore tout du mode d’alimentation de cette base. La Bibliothèque Universitaire de Nice (en tant que service commun, pas en tant que salle de lecture, n’y paraît pas).</Mise à jour du 3 mars>

L’équipe technique devant la BU Santé – Photo FlickR de Patrick Briggs – Stormtroopers — CC-BY-2.0

Une discussion début janvier avec Got m’a éclairé sur certaines difficultés que je peux rencontrer régulièrement dans mes activités au SCD de Nice. La société pour laquelle il travaille, Antidot, décompose ses activités auprès des clients en 2 équipes distinctes : Projet et Support — comme toutes les sociétés, je pense.

• L’équipe Projet est là pour amener le client à l’utilisation courante des outils vendus. Une fois le client en fonctionnement normal, elle passe ensuite complètement la main.
• L’équipe Support vient alors prendre le relai pour répondre aux sollicitations du client, en cas de difficultés, d’insatisfactions, de bugs, de plantages, etc.

La logique étant que, si ces deux équipes oeuvrent sur les mêmes outils, et doivent donc les connaître parfaitement, leur travail n’est pas du tout le même. Notamment — et je cite Got, merci à lui pour m’avoir ainsi éclairé sur une chose qui paraîtra évidente à beaucoup — la périodicité et les phases de stress n’ont rien à voir.

Pour l’équipe Projet, l’activité annuelle ressemble à ceci :

Alors que l’équipe Support vivait plutôt sur ce rythme-là :

Tous les SCD que je connais ont un service qui s’apparente à un département informatique, avec des compétences plus ou moins étendues : il intègre généralement la docélec (ou pas), la maintenance matérielle du parc, la gestion des logiciels (à commencer par le SIGB) et des serveurs, etc. Bibnum à Angers et Clermont-Ferrand, Cellule informatique à Paris 6, Système d’information documentaire à Caen, Sidoc (qui veut dire la même chose) à Nice.

Et j’ai tendance à croire que tous ces établissements, à l’image du nôtre, gèrent à la fois les projets (quand il y a une part technique, informatique) et le support (tout problème rencontré en section ou par un lecteur relatif aux outils utilisés).

Les dossiers en mode Projet se gèrent en semaines et en mois, avec une planification anticipée (pléonasme ?) de la charge de travail et des périodes d’intensité.

Les tâches en mode Support se gèrent dans la journée ou dans la semaine, en s’appuyant autant que possible sur des procédures déjà en place (donc, logiquement, sans improvisation sauf en cas de difficulté inédite : heureusement ce sont souvent les mêmes problèmes qui reviennent).

Je constate au moins deux conséquences problématiques à cette double fonction :

• Du côté de l’équipe Support + Projet : une certaine difficulté à gérer les deux casquettes, avec la nécessité de mener des projets sur le long terme et la possibilité statistique d’être interrompu à tout moment pour une urgence (urgence concernant un collègue ou un lecteur, ou tout le réseau)
  Si bien que leur rythme peut ressembler à ça
  
  à quoi s’ajoute le sentiment de ne faire bien ni l’un ni l’autre, puisque ne bénéficiant ni de disponibilité complète nécessaire à l’action support, ni de la concentration utile à la gestion des projets.
• Du côté des collègues en section : la fonction Support les habitue à ce que l’équipe réagisse rapidement avec des solutions immédiates. Donc il peut arriver qu’ils viennent avec un problème qui, pour eux, relève du support — sauf qu’après une analyse plus ou moins longue, l’équipe technique l’identifie comme relevant du projet (nouveau service et/ou nouveau circuit et/ou nouveau problème).
  Donc nécessité de temporisation, de prendre le temps de l’analyse, etc. — ce qui peut ne pas être compris

Par ailleurs, cette organisation où des "techniciens" (quels que soient leurs grades et statuts) traitent l’ensemble de la chaîne, de l’analyse des besoins au fonctionnement courant en passant par la montée en charge, n’est que l’héritage d’une époque pas si lointaine ou les questions informatiques étaient une excroissance des activités de la bibliothèque.

Aujourd’hui, sans être forcément le coeur de ces activités (après tout, on doit rester conscient qu’on ne parle là que d’outils), il y a eu comme la passage à une ère "industrielle" de l’informatique en bibliothèque, avec des cadences et des exigences différentes, qui du coup nécessitent une conception complètement différente de l’organisation — peut-être plus "industrielle" elle aussi.

Avez-vous dans vos établissements la même (con)fusion ? Avez-vous distingué les deux fonctions ? Ou trouvez-vous au contraire que c’est une richesse que d’avoir les deux casquettes (diversité du quotidien) ?

Observez-vous les problèmes que j’évoque (ou d’autres) ? Et coment essayez-vous de les résoudre ?

Donc le rapport de LudoTIC relatif à l’analyse heuristique de la maquette n’était pas vraiment éliminatoire. Mais il accumulait une multitude de petites remarques qui finissaient par mettre à mal ce qui paraissait a priori logique et satisfaisant.

Bref, en juin 2012, on ne sait plus trop comment avancer, comment intégrer toutes les remarques à la fois, par où reprendre.

Là où on en était :

• les ~20 membres du groupe projet avaient bien intégré ce que devait être théoriquement un site web de BU (les choses à éviter et à privilégier)
• une maquette avait été faite, sans qu’on puisse la reprendre telle quelle
• des groupes de travail thématiques mis en place depuis février avaient bien avancé sur la rédaction des contenus initiaux, avec forte délégation à chacun d’entre eux (infos pratiques, pages du PEB, description des ressources, etc.)

D’où une 2e prestation commandée à LudoTIC (septembre 2012), double elle aussi :

1. un tri de cartes
2. un maquettage du site web (page d’accueil est pages des rubriques), sur la base
   • du tri de cartes
   • des objectifs que nous leur avions donnés
   • des critères d’ergonomes qui leur sont propres
   • des résultats de l’enquête sur les usages des internautes vis-à-vis du site actuel, et de l’expression de leurs besoins
     Le maquettage n’intégrait absolument pas la charte graphique : il définissait simplement des zones et un mode de navigation.

Dendogramme des cartes proposées, suite au tri de cartes des lecteurs

Le tri de cartes à consisté en ceci :

• le SCD fournit la liste des contenus qu’il pense mettre sur le site — mais pas les rubriques qu’il pensait utiliser pour les structurer
  Cela a représenté 70 "cartes" environ
• LudoTIC trouve des lecteurs testeurs de tous profils (étudiants, chercheurs, personnels des bibliothèques) — une quinzaine a suffi pour obtenir des résultats satisfaisants et concordants.
• Il leur présente des cartes (sous forme de post-its) sur lesquelles sont inscrits les différents contenus envisagés (ainsi que la possibilité de créer de nouvelles cartes si nécessaires)
• Chaque lecteur regroupe en quelques tas, puis regroupe encore ces tas pour constituer les futures rubriques et sous-rubriques — et il nomme chacun de ces tas et sous-tas

LudoTIC a ensuite entré les différents résultats dans un outil idoine, pour produire une synthèse de l’ensemble (dendrogramme).

Par chance, les différents profils interrogés arrivaient à peu près aux mêmes préconisations (ce qui nous a évité le double portail : étudiants/chercheurs).

Mi-octobre 2012, LudoTIC présentait ses conclusions (arborescence et maquettage). On a passé ensuite deux mois et demi.

Remarques globales

Ressources humaines

Je ne l’ai pas détaillé, mais en gros sur la conduite du projet nous étions 3 au niveau central à coordonner l’ensemble des membres du groupe projet — avec différents niveaux d’intervention, à la fois de nature et d’intensité.

Navigation générale sur le site

En regardant en arrière, j’ai l’impression que l’arborescence finale proposée par LudoTIC n’était pas tellement différente de celle que nous avions envisagée. En revanche le mode de navigation, la page d’accueil, permettent un accès beaucoup plus aisé aux contenus qui nous a d’une certaine manière "sauvés".

Nous n’avions pas de réflexion théorique sur les modes de navigations existants, sur ce qu’il convenait de choisir, etc. Dans son maquettage, LudoTIC nous a indiqué avoir choisi une navigation systématiquement "en entonnoir". Donc on peut être amené à faire un certain nombre de clics (quoique la profondeur finale du site ne soit pas très grande), mais le comportement global de navigation est très cohérent, donc d’une prise en main rapide.

La page d’accueil

Dans l’enquête du printemps 2012 auprès des usagers, il ressortait clairement que (notamment au regard de notre propre maquette) les internautes n’avaient que faire des actualités de la bibliothèque : ce n’est pas ça qu’ils venaient chercher sur le site.

La première conclusion a donc été de les évacuer, de les reléguer dans un endroit plus discret — mais pour y mettre quoi ?

Et finalement la maquette proposée par LudoTIC a laissé toute la place aux actualités sur la page d’accueil, mais sous la forme d’un carrousel. Pourquoi ? Parce que si ce n’est pas ce que les internautes veulent, ils ne rejettent pas pour autant ce type d’information. Donc cette page d’accueil avec très grande image a pour permettre de laisser le lecteur voir la navigation (les onglets) : l’alternative aurait été de lui proposer sur la page d’accueil, soit une redondance de l’arborescence du site, soit un ensemble de "liens rapides" ou "raccourcis". Bref, une page avec beaucoup plus trop de liens.

La description des ressources

Cette rubrique Ressources nous a donné du fil à retordre : plusieurs réunions à avoir le sentiment de tourner en rond, de partir d’une proposition pourrie, d’évacuer tout un tas d’autres options, et de revenir à la proposition du départ — qui nous semblait un tout petit peu moins pourrie.

Je ne prétends pas d’ailleurs que nous aillons trouvé l’ultime solution.

Pour décrire nos ressources, il y a plusieurs paramètres contradictoires à prendre en compte :

• La distinction papier/en ligne est dépassée, elle n’est pas pertinente : pour l’utilisateur, il faut lui proposer des ressources documentaires en lien avec ses besoins.
• La distinction entre ce qui est payé par le SCD et ce qui est disponible en ligne n’est pas plus pertinente : c’est l’adéquation de la ressource au besoin de l’internaute qu’il faut viser. Mais concrètement, ça se traduit comment sur une page "Ressources" ?
• La documentation électronique a besoin d’une "exposition" particulière, vu qu’il n’est pas possible de circuler dans des rayons virtuels rangés par discipline.
• La partie purement descriptive n’a que peu d’intérêt et sera rarement lu, mais il est difficile de ne rien fournir (disciplines couvertes par les acquisitions, mode de rangement, etc.)
• Il y a aussi un paratexte à fournir sur les ressources en ligne : conditions d’accès, mode d’authentification, difficultés techniques possibles, etc.

Nous sommes partis de l’idée qu’il "fallait" produire quelque chose, mais que fondamentalement cette rubrique descriptive ne servirait pas beaucoup : après tout, l’accès aux ressources se fait "naturellement" via l’outil de recherche très visible sur toutes les pages.

Eh bien non : dans les statistiques de consultation des pages du site

• 10% des logs concernent la page "Ressources"
• 10% concernent la page "Ressources en ligne"
  

Les premiers jours, les pavés cliquables étaient dans un autre ordre :

C’était donc une structuration "en ligne" : première ligne pour le papier, seconde ligne pour l’électronique.
Les stats nous ont tout de suite montré que c’était le lien "Ressources en ligne" que venaient chercher les internautes. Il fallait donc le mettre en haut à gauche. Comme le pavé "Collections remarquables" fait aussi fonction de valorisation, il n’était pas possible de le mettre en-dessous. Et c’est ainsi qu’on s’est retrouvé sur une structuration en colonne (première colonne : l’électronique ; seconde colonne : le papier).

Conduite du changement, frustrations diverses et méthodologie

L’investissement a été long, et a sollicité pas mal de monde.

Au final, ceux qui ont concrètement pris part au projet — de près ou de loin — représentent environ un tiers du SCD pendant plus d’un an. Donc la mise en place du nouveau site n’a surpris personne. Pour autant, cela ne signifie pas que ces différents acteurs se sont "reconnus" dans le portail, et c’est un aspect instructif du projet.

En effet nous avions décidé de valider la méthodologie "Tri de cartes" avec externalisation de cette technique, et d’assumer ce qui en sortirait (je n’ose dire : "quoi que ce fût", mais c’était à peu près l’idée). Ce qui signifie que les bibliothécaires (moi y compris) ont forcément eu envie d’avoir de meilleures idées que ce qui découlait de la méthodologie.

Cela nous a tout de même sauvé d’avoir validé celle-ci en amont, et d’avoir externalisé la démarche : il y avait ainsi une forme d’engagement à tenir.

De même, sur l’alimentation de chacune des rubriques, les groupes de travail ont été autonomes, la seule intervention du petit groupe de pilotage ayant consisté, lors de la mise en ligne, à questionner la mise en forme, l’homogénéité de la rédaction, la lisibilité de la page, etc. J’ai ainsi vu passer et mis moi-même en ligne des pages que je n’aurais pas rédigées, que je n’avais pas envie d’approuver. Mais comme j’avais estimé que la méthode (d’autonomie des groupes de travail) était la bonne… Je suis très satisfait que les pages aient pu être mises en ligne telles quelles.

Ce qui n’empêche pas que, par nature, à partir du moment où on implique autant de monde, la frustration de chacun est inévitable, à différents niveaux. L’essentiel est d’arriver à en sortir pour constater le résultat global, et apprécier le contentement de ses utilisateurs.