Intégrer les nouvelles consignes FRBR du Sudoc dans le quotidien du catalogage

Contexte

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

Croiser des statistiques : l’enjeu des URI

Voilà un cas pratique qui vient de tomber pour illustrer une utilisation "simple" (oserai-je "intuitive" ?) des URI.

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>

Support + Projet (= Su-jet ?)

(le titre ne veut rien dire, je sollicite votre indulgence)

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 ?

Retour d’expérience sur la mise en place du nouveau site web du SCD de Nice (2/2)

Cf. billet précédent d’abord.

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 :

Dans les rayons	Collections remarquables
Ressources en ligne	Utiliser les ressources en ligne

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.

Retour d’expérience sur la mise en place du nouveau site web du SCD de Nice (1/2)

Comme c’est un billet de blog, et pas un article du BBF, je ne vais pas rentrer dans l’intégralité des détails. Si vous avez des questions précises, des curiosités mal placées, etc., les commentaires sont là pour ça.

L’idée de ce billet est de rendre compte globalement de la méthodologie suivie pour la mise en place du site web, de septembre 2011 à janvier 2013 (oui, on a laissé mûrir).

Il ne vise pas à donner d’exemple de ce qu’il faut faire : je vous laisse trouver par vous-même ce qu’il ne faut éventuellement pas faire

Situation de départ

Le site précédent correspondait à l’ancien site de l’Université : même CMS (Jahia), même charte graphique.

Il était aussi l’héritier d’une situation antérieure ou, au début des années 2000, chaque section avait commencé à élaborer ses propres pages web dans son coin. Le site sous Jahia était déjà une première étape d’homogénéisation, avec :

• une charte graphique identique
• une navigation identique

Ce dernier point signifie que, une fois qu’on avait cliqué dans le menu sur le nom d’une des BU, on retrouvait les mêmes rubriques, sous-rubriques, sous-sous-rubriques et sous-sous-sous-rubriques (la profondeur pouvait aller jusqu’à 8 niveaux, dans un ou deux cas extrêmes).

Mais le fait est que sous le site Jahia, il y avait en réalité un site par BU + un site SCD (présentant les ressources dans leur ensemble, l’organigramme, etc.). Les infos pratiques, les services, les ressources thématiques, étaient déclinés dans les pages rangées sous chaque BU.

Enjeux (multiples)

• Adopter la nouvelle charte graphique de l’Université

• Supprimer toute la redondance des pages et avoir "un site des BU" plutôt que 8 sites de BU
• le reste des objectifs s’est dégagé après la phase de benchmarking (cf. plus bas)

Moyens engagés

En septembre 2010 : on a repris les "correspondants opac" en section pour réfléchir à la mise en place du futur nouveau site web. Ils ont souhaité s’adjoindre des collègues (donc 2 "correspondants Portail" par section), ce qui a représenté un groupe de travail d’une vingtaine de personnes environ, bibliothèques de composantes incluses).

Un groupe de travail de 20 personnes pourra être jugé assez lourd par certains — ce qu’il est. Mais l’idée était vraiment d’inclure dans cette démarche une conduite au changement assez forte, dût-elle coûter en temps et en énergie.

Groupe de travail = se mettre autour d’une table, et tirer la nappe à soi ? [Photo Flickr par Scott Maxwell - CC-BY-SA-2.0]

Calendrier global

En octobre 2011, mise en place d’un groupe projet porté par le Sidoc, avec un ou 2 représentants de chaque BU, ainsi que des bibliothèques de composantes (Bib du Labo de Math J.A. Dieudonné, Centres de ressources de l’Institut des Langues, Bib IUT Fabron).

Octobre-décembre 2011 : analyses de différents sites de SCD-BU pour identifier les bonnes idées, les choses à ne pas faire – et ce que pouvait ou devait être un portail de bibliothèque universitaire. Utilisation d’une grille d’analyse commune qui invite à interroger quelques axes :

• Ergonomie
• Navigation
• Exhaustivité des contenus
• Accès aux contenus
• Accès au texte intégral
• Actualités
• Informations pratiques
• Aide
• Contacts

L’objectif était de se contraindre à aller voir d’autres sites web pour en retirer les bonnes et les mauvaises idées, avec un minimum de méthode.

Suite à ces analyses, on a pu synthétiser des objectifs (ce qu’on voulait ou non), notamment :

• adoption du CMS de l’Université pour rester dans la logique institutionnelle et ne pas assumer l’administration d’un nouvel outil
• structuration transversale du nouveau site web, et non accès par BU -> pas de migration à l’identique des pages Jahia du SCD
• Le site sera relativement statique et transversal. Mais à la suite de sa mise en place, démarche d’investissement des réseaux sociaux ou mise en place de petits sites thématiques type blog comme moyens de toucher des communautés d’intérêts ou de pratiques
• identification de besoins techniques spécifiques au regard de ce que ne fait pas le site de l’UNS
• navigation unifiée entre le site et le catalogue (cf. billet précédent sur cette question)
• le catalogue devient une base de signalement de l’ensembles des ressources. Il n’existe plus en tant que tel et est (ou semble être) complètement intégré au site

Janvier-mars 2012 : groupes de travail thématiques sur les différents aspects à creuser pour le portail :

• Formation des étudiants
• Documentation électronique
• informations pratiques & aide
• etc.

avril 2012 : élaboration d’une première maquette

Cette maquette résultait des préconisations du groupe de travail : transversalité, accès direct à certains services ou certaines ressources, etc. Je vous laisse l’évaluer, en précisant d’emblée qu’elle ne fut pas retenue.

Nous avons ensuite sollicité la société d’ergonomie LudoTIC, pour un double travail

• Analyse ergonomique de la maquette par évaluation heuristique
• Enquête auprès des usagers pour définir l’utilisation actuelle des outils du SCD (site web, catalogue), les frustrations, les besoins, etc.

Et c’est là que tout a basculé…

Suite au prochain épisode

Du catalogue à l’outil de recherche

Jusqu’au 15 janvier, le SCD de Nice avait un site web d’un côté, un catalogue en ligne de l’autre.

Le site web était géré avec le CMS Jahia, le catalogue en ligne avec Primo. Depuis le site web, il fallait bien désigner le catalogue, donc on l’appelait "catalogue" [sic].

Depuis, avec une migration du site web, on a toujours 2 outils logiciels distincts (le site web sous CMS Plone et l’opac sous Primo), mais pour l’utilisateur, c’est (censé être) transparent : il y a un seul site web, celui des bibliothèques.

(Source d’inspiration : nous avons voulu reproduire le résultat de "transparence de navigation" observé à l’UVSQ, qui possède le même opac)

Amélioration immédiate : plus besoin de dire au lecteur ou à l’internaute "d’aller sur le catalogue", etc. Il n’y a plus pour lui de "catalogue", il y a un site web qui propose un moteur de recherche, exactement comme le font Amazon ou la Fnac (et les sites d’Amazon et la Fnac ne suggèrent pas à leurs clients d’interroger leur catalogue).

La mise à jour de janvier permet donc un progrès purement ergonomique. C’était notre objectif : éviter à l’usager de voir passer le mot "catalogue".

Mais il y a finalement un deuxième intérêt, en interne : une distanciation par rapport au catalogue.

Désormais, on dispose de 2 termes qui ne désignent pas les mêmes choses

1. l’outil de recherche (public), accessible sur le site web du SCD
2. le catalogue, qui désigne la masse des notices décrivant l’ensemble de nos collections, présentes dans le SIGB.

Qu’est-ce que ça peut changer ? La perception que le bibliothécaire a de l’outil de recherche.

Les catalogues dits "de nouvelle génération" et autres "discovery tools" sont théoriquement autre chose que le simple signalement des ressources. Outre des fonctionnalités supplémentaires de recherche (typiquement : les facettes, le moissonnage de sources hétérogènes), ils permettent de construire un continuum entre les différents services proposés par la bibliothèque.

Ainsi quand on parlait du "catalogue" (pour désigner Primo), les fonctions du compte lecteur étaient signalées dans un second temps : primauté à la recherche. Désormais, l’outil de recherche est un service qui s’articule autour des collections, de même que la plupart des services proposés par la bibliothèque.

Désormais, la transition est plus fluide entre :

• la recherche dans les collections
   (qui n’est pas une recherche bibliographique)
• Dans le bandeau supérieur une recherche plus scientifique, dans Google Scholar (plus scientifique, indépendamment des contenus de Google Scholar, du fait que les résultats ne dépendent pas du fait de savoir si la bibliothèque propose la ressource trouvée ou non)
• le service du PEB (en bas des résultats)
• les suggestions d’achats
• le service "Interroger un bibliothécaire" (ouvert à l’occasion du nouveau site web)
• les prolongations
  les réservations
  les prêts en cours (tout ça sous l’onglet "Mon compte")
• et certainement plein d’autres choses, dont certaines à construire encore
  (par exemple la page la plus lue du site — 10% des consultations — qui liste les principales ressources en ligne, reprend l’affichage en facettes de l’opac)

Certains services étaient déjà présents avant (par exemple les rebonds vers le PEB, le formulaire de suggestion d’achat dans les listes de résultats).

J’ai l’impression qu’avec l’intégration de l’outil de recherche dans le site, on peut plus facilement considérer que la BU est dans une démarche de service vis-à-vis d’une demande documentaire : l’outil de recherche est un des services, le PEB en est un autre, Interroger un Bibliothécaire un troisième. Tous s’appuient sur les ressources locales et les ressources distantes (accessibles ou non).

Du coup, chaque service doit se positionner par rapport aux autres et penser les transitions de l’un à l’autre.

Et non seulement l’outil de recherche est ergonomiquement plus adapté aux internautes, mais on le fait évoluer dans le sens d’un service, et non d’une simple base de données pour accéder aux ressources.

Tant que l’outil de recherche restait visuellement distinct du site web, on était obligé de le penser à part. On change désormais de logique, et c’est une bonne nouvelle.

PS : au sein même du SIGB, on a toujours disposé parallèlement d’une "recherche professionnelle" permettant d’interroger les notices. Dans ce contexte pro, le "catalogue" a toujours désigné la base des notices, et "la recherche professionnelle" une certaine manière d’y accéder (pas la seule). Je n’avais jamais envisagé que l’appellation "catalogue" pour l’interface publique avait un caractère entravant.

Mouvement des conservateurs de bibliothèques février 2013 : géolocalisation

J’ai repris les outils de l’an dernier (Google Docs exporté en CSV, importé dans Yahoo Pipes pour géolocalisation automatique puis réinjecté dans Google Maps pour un meilleur affichage)

Vous pouvez donc visualiser les postes proposés au mouvement sous forme de carte.

Pour accéder au profil du poste, c’est aussi laborieux que l’an dernier :

• copier le code établissement indiqué
• aller sur la page d’accueil de Poppée > Postes vacants ouverts au mouvement > Conservateurs > Consulter les profils
• coller le code établissement

Les liens profonds sont toujours impossibles sur Poppee…

<mise à jour 16h>J’ai refait une seconde carte, qu intègre les intitulés des profils (mais pas le détail. Du coup il y a une info-bulle par profil, et non par établissement : donc quand plusieurs postes dans le même établissement, il faut utiliser le menu latéral gauche. En outre, je découvre que certains postes ont "disparu" (en tout cas, au moins Les Antilles — les autres, je ne sais pas)

En tout cas si ça vous intéresse, voici la carte</mise à jour>