Accueil » Dossiers » Créer une archive ouverte institutionnelle
HMS Belfast boiler room gauges - © Rémi Kaupp, CC-BY-SA, Wikimedia Commons
© Rémi Kaupp, CC-BY-SA, Wikimedia Commons

Créer une archive ouverte institutionnelle

Comment créer une archive institutionnelle dans son établissement ? Nous vous proposons de prendre connaissance du témoignage de Stéphanie Bouvier et de Daniel Bourrion qui ont mis en place ce projet à l’université d’Angers en retenant la solution Okina.

Les lignes qui suivent sont la version condensée d’un article paru par ailleurs

 

Une brève histoire d’Okina

———————————

Stéphanie Bouvier est bibliothécaire. Elle est chef du projet Okina depuis 2012. Chargée de la valorisation Recherche, elle est en outre l’adjointe de Daniel Bourrion au sein du Lab’UA, un service de la Direction du Développement Numérique de l’Université d’Angers, dédié à l’innovation.

Daniel Bourrion est conservateur. Responsable de la section Bibliothèque numérique du SCD d’Angers de 2007 à 2014, il est à présent en charge du pôle Données et publications de la Recherche du Lab’UA.

———————————-

1. Local ou portail ?

2. La solution Drupal

3. Zoom RH

4. Quelques éléments de méthodologie

4.1 Développement

4.2 Intégration

4.3 Formation

4. Une logique permanente de facilitation

5. Un bilan

5.1 Coté utilisateurs

4.2 Coté contenus

6. Et maintenant

Ouverte à sa communauté en février 2015, Okina, l’archive ouverte institutionnelle de l’Université d’Angers, a été développée au sein d’un projet global autour de l’Open Access.

Inspirées d’un article plus détaillé retraçant la genèse globale du projet, les lignes qui suivent se focalisent principalement sur les choix méthodologiques et aspects techniques de l’outil.

1. Local ou portail ?

Cette question rituelle a été, dans le cas d’Okina, relativement aisée à trancher, puisqu’une archive institutionnelle locale :

  • permet à l’institution qui la déploie d’avoir une vue exhaustive des publications de ses chercheurs, y compris par le biais des seules notices, sans fichiers (ce qui n’est pas souhaitable évidemment) ;
  • assure une modulation fine (accès libre, sous embargo, restreint) des droits d’accès et diffusion (directe ou indirecte) des fichiers ;
  • est la garantie d’une proximité et d’une réactivité maximales par rapports aux besoins et demandes des utilisateurs ;
  • autorise un travail fin sur l’expérience utilisateur (UX) qui va pouvoir être rendue la plus intuitive possible.

Les quatre items précédents faisant partie du cahier des charges du projet dès son esquisse, le choix s’est naturellement porté vers un outil local, qu’il restait à déterminer.

2. La solution Drupal

Drupal, traité comme une base applicative autour de laquelle les développements nécessaires seraient réalisés, a rapidement émergé parmi les possibles car ce CMS dispose d’une communauté très étendue et active ; est extensible au quasi infini ; et permet de disposer de fonctionnalités réalisables grâce à de simples paramétrages de vues et de règles automatisant le déclenchement d’actions1.

Par ailleurs, un certain nombre de modules déjà existants sur Drupal et bien maintenus permettaient de disposer immédiatement de nombre des possibilités attendues. On citera en particulier :

  • CAS2, pour l’identification des usagers de l’Université ;
  • Bibliography3, pour la gestion des références bibliographiques (ce module très riche proposant entre autres :
    • la création de notives par import via DOI ou PubMEdID ;
    • l’import d’un lot de notices4 sous forme de fichiers BibTex, Endnote, RIS, MARC, etc.
    • un dédoublonnage a priori lors des imports sur DOI, PubMedID ou copier-coller BibTex/RIS avec redirection automatique de l’utilisateur sur la notice existante en cas de doublon5;
    • des fonctions d’export des références vers les formats BibTex, RTF, EndNote, MARC, RIS, selon des règles de mapping de champs paramétrables
  • Search API6, son extension Biblio Search API, et Facet API pour la recherche parmi les références ;
  • Views OAI-PMH7 pour l’implantation du protocole éponyme (exposition par sets non disponible à ce jour, encore à développer) ;
  • Download count8 pour les statistiques de téléchargements.

Certaines fonctionnalités plus spécifiques au projet ont par contre nécessité un développement intégral, qui a été réalisé en l’espèce dans le respect de la logique intrinsèque à Drupal, c’est-à-dire sous la forme de modules activables ou non en fonction des nécessités de chacun :

  • Biblio Contributors Affiliations pour la gestion des affiliations dans les notices ;
  • Biblio Contributors Affiliations HAL, qui permet d’étendre les fonctionnalités du précédent en permettant la récupération de nouveaux laboratoires déjà référencés dans AureHAL ;
  • Biblio Export HAL, pour l’envoi des notices depuis Okina vers HAL ;
  • Biblio Files qui permet une gestion fine des fichiers et de leurs modalités d’accès ;
  • Biblio Files Request pour les tirés à part ;
  • Biblio Sherpa Romeo pour la récupération et l’affichage des informations de Sherpa Romeo directement dans le formulaire de dépôt Okina ;
  • Biblio Files Request qui implante la fonction de demande de tirés à part sur les fichiers à diffusion restreinte.

Bien que n’étant pas lié à Drupal, mais puisqu’il est question d’outils, indiquons, concernant le quotidien de la gestion de projet, que deux tableaux de bord Trello9 ont été utilisés pour gérer le travail technique d’une part, et organiser l’intégration des laboratoires d’autre part. Outre sa facilité de prise en main et la qualité de son interface, Trello, éminemment recommandable, permet de très simplement assigner des tâches à des individus, mentionner des échéances pour chaque item, catégoriser les “tâches”, de dresser des listes à cocher, etc10

3. Zoom RH

Les moyens humains mis à disposition devaient être théoriquement :

sur 2013 :

  • 1 Bibliothécaire titulaire temps plein pendant 8 mois ;
  • 1 ASI recherche 50 % pendant 8 mois ;
  • 1 Contrat Bibliothécaire temps plein 4 mois à partir du 01/09 ;
  • 1 Développeur temps plein 7 mois à partir du 01/06 ;

sur 2014 :

  • 1 Bibliothécaire titulaire temps plein pendant 8 mois ;
  • 1 ASI recherche 50 % pendant 12 mois ;
  • 1 Contrat Bibliothécaire Temps plein 8 mois jusqu’au 31/08 ;
  • 1 Développeur temps plein 5 mois jusqu’au 31/05 ;
  • Finalisation de l’une ou l’autre fonction ci-dessus pour mise en production 01/09/2014 : 3 mois TP ou 6 mois 50% ;

Dans les faits, en mode projet, soit de l’été 2013 à l’été 2015, l’équipe archive ouverte a compté les éléments suivants :

  • une chef de projet, bibliothécaire titulaire, 80% puis 100% ETP à partir de janvier 2015 : Stéphanie Bouvier ;
  • un développeur de la Direction du Développement Numérique, à temps plein, de l’été 2013 à décembre 2014 : Baptiste Judic ;
  • un ASI contractuel à temps plein, de septembre 2013 à août 2015 : Emmanuel Lemoine

4. Quelques éléments de méthodologie

4.1 Développement

Tout le travail effectué lors du projet Okina s’est fait en s’inspirant de la méthode agile, à savoir :

  • priorisation des attendus ;
  • déploiement d’une v1 proposant des fonctionnalités élémentaires ;
  • et implémentation des développements ultérieurs au fur et à mesure de leur réalisation sur un outil déjà en production.

cette manière souple de faire permettant une grande réactivité et des ajustements immédiats en fonction des retours des utilisateurs dont, tout particulièrement et avant même la mise en production publique, certains chercheurs bêta-testeurs qu’un environnement instable ne déstabilisait pas.

Cette approche, par ailleurs, continue à être appliquée au quotidien, la mise en production ne signifiant pas la fin de l’évolution de l’outil, auquel des améliorations continuent à être apportées au fil de l’eau, toujours en interaction étroite avec ses utilisateurs.

4.2 Intégration

L’intégration des laboratoires s’est faite par cinq vagues successives précédées d’une vague de test constituée de huit laboratoires volontaires sur lesquels a été testée la procédure envisagée :

  • désignation au sein du laboratoire d’un correspondant Okina ;
  • vérification de la liste des personnels du laboratoire ;
  • reprise du rétrospectif des chercheurs : le projet Okina est en effet appuyé sur un mandat de l’Université imposant le référencement des publications des chercheurs sur Okina depuis 2008, les articles postérieurs à 2012 devant en outre être signalés et idéalement accompagnés d’un fichier. On précisera qu’il avait été par ailleurs décidé que l’équipe-projet Okina se chargerait directement du rétrospectif des laboratoires correspondant à la période 2008-2012, ce qui a représenté un travail important de l’équipe backoffice.

Concernant la création des comptes utilisateurs et l’attribution des droits nécessaires au dépôt dans Okina, elle a reposé sur une extraction de la liste du personnel et des doctorants affiliés aux laboratoires à partir d’Harpège et d’Apogée, liste qui a fait l’objet d’échanges entre les laboratoires et les services RH de l’Université pour corrections avant d’être utilisée pour pré-créer les comptes utilisateurs, assortis des droits “déposant”. Le but de l’opération était ici clairement de faciliter le premier contact avec l’outil : lors des séances de formation, les utilisateurs n’avaient qu’à se connecter et, sans création de compte ou opération préalable à exécuter, accédaient directement accès au dépôt.

4.3 Formation

La mise en place d’un tel outil s’accompagne évidemment d’un important effort de formation qui a reposé en l’espèce sur le schéma suivant :

  • une présentation générale d’Okina et du projet à destination de l’ensemble des membres de chaque laboratoire réuni pour l’occasion ;
  • des formations composées de petits groupes d’une douzaine de personnes maximum proposées aux laboratoires sur plusieurs créneaux horaires et à plusieurs dates ;
  • en dehors de ces formations de groupes, des formations individuelles dispensées à la demande (elles le sont toujours)

avec ce constat que le facteur décisif d’une mobilisation maximale des membres d’un laboratoire était l’investissement de son directeur dans le projet : le nombre des personnes présentes et impliquées s’est avéré être directement en relation avec la position du directeur du laboratoire par rapport à Okina.

4. Une logique permanente de facilitation

Toutes les raisons susceptibles de créer un rejet d’Okina par les chercheurs ont d’une manière générale été autant que possible écartées.

Un soin tout particulier a donc été apporté à la cruciale ergonomie du formulaire de dépôt qui comporte un minimum de champs obligatoires (trois seulement, le titre, l’année, le type de document).

Un connecteur Okina-HAL a par ailleurs été développé, permettant au déposant de décider s’il souhaite procéder à un dépôt HAL en simultanéité avec son dépôt Okina, l’objectif avoué étant d’éviter un double dépôt ou toute opération chronophage de ce type.

Enfin, toujours dans une logique de point d’entrée unique permettant des exploitations multiples des données, Okina propose des services d’import mais aussi d’export des références bibliographiques. Que ce soit à l’échelle du laboratoire ou du chercheur, des exports aux formats bibliographiques et bureautiques standards (BibTex, RIS, Endnote, doc, pdf, html…) sont disponibles pour tout ou partie des références. Parallèlement des flux XML permettent une récupération automatique des références dans des sites tiers.

5. Un bilan

5.1 Coté utilisateurs

Les bons chiffres d’Okina (sur 900 utilisateurs potentiels, 257 ont été formés, 389 ont créé au moins une notice, 604 se sont connectés au moins une fois) ne doivent pas cacher qu’une part importante de la communauté reste toutefois encore à sensibiliser.

Les retours qualitatifs sont positifs, les utilisateurs exprimant sans ambiguïté leur satisfaction11, en particulier en ce qui concerne la simplicité de l’outil et sa facilité de prise en main. Les services proposés sont également appréciés, ainsi que la réactivité de l’équipe, tant dans le suivi quotidien des dépôts que dans les réponses concrètes apportées aux suggestions d’amélioration.

4.2 Coté contenus

Sur les 5690 références créés par les membres des laboratoires, 1955 sont accompagnées d’au moins un fichier, qui totalisent 14 775 téléchargements (hors robots).

Par ailleurs, 3160 notices correspondent aux critères du mandat voté par l’Université12, mais seules 715 comportent un fichier, soit seulement 23% des notices concernées, preuve que la politique officielle de l’Université en la matière n’a pour le moment, du fait de son seul caractère incitatif, pas de répercussion concrète sur l’utilisation de l’archive ouverte institutionnelle.

En dehors de ces considérations, et pour information, à ce jour, près de 64% des documents déposés dans Okina sont diffusés en accès libre, 26% en accès restreint et à peine moins de 10% sont dits confidentiels : il est manifeste que la proportion des documents librement accessibles pourrait encore progresser.

6. Et maintenant

L’une des ambitions du projet était dès le départ d’aboutir à réaliser une distribution Drupal-Okina prête à l’emploi, et pouvant être déployée facilement par d’autres établissements ou institutions dans l’optique d’une communauté d’utilisateurs.

Cet objectif n’a pour l’heure pas été atteint bien qu’il soit à portée de main, le développeur en charge de l’aspect “code” pour Okina ayant été dès après la mise en production chargé d’autres tâches, bien qu’il reste toujours impliqué dans le projet pour ce qui concerne la maintenance et les ajustements locaux de l’outil. Du point de vue strictement technique, le passage de l’application Okina à une distribution Drupal-Okina est donc clairement toujours l’étape suivante en ligne de mire.

Plus généralement, le projet Okina a été mené à bien dans les délais impartis et fonctionne à présent au quotidien dans un mode de production satisfaisant, même s’il faut encore éclaircir la manière dont il sera pris en charge dorénavant par les différents partenaires présents au sein de l’Université.

Au-delà des enjeux généraux liés à l’Open Access, la mise en place d’Okina a également été l’occasion de prouver qu’un tel projet pouvait être préfiguré, monté, organisé et réalisé dans des délais relativement courts à l’aide d’une équipe légère mais motivée, pour peu qu’un appui politique vienne soutenir les efforts, et que des modes de fonctionnement agiles, peu hiérarchiques, soient privilégiés.

Projet d’établissement, Okina doit à présent s’ancrer définitivement dans les habitudes des chercheurs, et construire une communauté autour de l’outil. Ici, ce n’est plus tant d’un sprint dont il s’agit, que qu’une course de fond – une toute autre discipline.


1 Comprendre, “sans écrire une seule ligne de code”.

4 Dans tous les cas toutefois, pour des raisons de qualité des données, il est apparu nécessaire de repasser sur ces notices présaisies à l’unité ou en lot pour ajouter les affiliations des auteurs et si possible les fichiers. Pour cette raison nous avons réservé l’import par lot aux administrateurs de la plateforme, et décidé d’imposer aux utilisateurs le passage par le formulaire en mode édition.

5 Des vues ont par ailleurs été créées, listant de possibles doublons en repérant les occurrences de titres etc.

10 Dans le cadre du projet Okina, la version gratuite, tout à fait suffisante, a été utilisée. Il est probable qu’aujourd’hui, le choix se porterait plutôt vers Framaboard, un équivalent libre à Trello proposé par Framasoft.

11 Pour l’Open access week 2015, une vidéo intitulée “Okina vue des labos” a été réalisée, offrant à entendre les retours de six utilisateurs (chercheurs, directeurs d’unité, ingénieur) membres de trois laboratoires (domaines de recherche : langues, littérature et linguistique, ingénierie des systèmes, sciences et technologies moléculaires).

12 Rappelons que ce mandat requiert le dépôt du texte intégral pour les seuls articles parus depuis 2012 dans des revues à comité de lecture.