Une brève histoire d’Okina

Ouverte à sa communauté en février 2015, Okina, l’archive ouverte institutionnelle de l’Université d’Angers (UA), a été développée au sein d’un projet global autour de l’Open Access. Les lignes qui suivent retracent l’histoire de cette archive et la manière dont Okina est née puis a été portée politiquement. Elles se penchent également sur les choix techniques comme stratégiques ou humains effectués le long du chemin, qui ont permis que de vagues idées se concrétisent dans un objet fonctionnel né de (presque) rien.

L’histoire d’un choix

La genèse

Si plus d’une année de discussions, de réflexions et d’études des possibles a précédé la décision officielle de mettre en place une archive locale, l’histoire d’Okina trouve son déclencheur dans un premier projet qu’il faut évoquer ici, dans lequel il s’agissait de répondre au besoin exprimé par un laboratoire souhaitant disposer d’un outil de gestion de ses références bibliographiques intégré au site web de l’unité, tâche impossible à réaliser avec Amétys, le CMS utilisé par l’Université d’Angers.

En cours d’instruction, cette demande est apparue rapidement comme une opportunité idéale pour proposer des solutions plus ambitieuses (en l’espèce, une archive institutionnelle), mettre en lumière toutes les spécificités bibliographiques de ce type de projet (exposition des données, interopérabilité des formats, etc.) et, bien entendu, poser la question de l’Open Access et des archives ouvertes.

Plutôt que de se contenter de répondre à la commande exprimée, la stratégie a alors été de se positionner à un niveau plus général de la problématique soulevée, et de proposer à l’Université d’Angers de se lancer dans une politique ambitieuse d’Open Access tout en se dotant d’une archive institutionnelle. C’est à ce moment que s’enclenchent les premières pièces du puzzle de ce qui deviendra Okina, et c’est là que les premières discussions politiques commencent.

Le vice-président recherche de l’Université, Christian Pihet, alors contacté, est immédiatement convaincu, et une première intervention est faite en Conseil scientifique au printemps 2012 afin de présenter d’une manière générale l’Open Access et une première esquisse de ce que pourrait être l’archive institutionnelle de l’UA. Des contacts sont également pris dès l’automne 2012 avec le PRES LUNAM, qui se montre intéressé par l’expérience proposée dans le cadre évident d’une éventuelle extension ultérieure à l’échelle de la région.

Un comité de pilotage du projet en émergence est à ce moment monté, qui compte parmi ses membres le vice-président recherche, le vice-président du numérique Stéphane Amiard, la directrice recherche de l’époque, trois directeurs de laboratoire représentant les SHS, les sciences exactes et la santé, une représentante de la Direction du développement du numérique, la directrice par intérim de la bibliothèque universitaire, et la bibliothécaire chef de projet Stéphanie Bouvier. Suite aux premières réunions de ce comité, un cahier des charges des fonctionnalités attendues est validé, qui comprend trois grands volets : modalités de dépôt, valorisation et services, archivage pérenne.

À ce moment de l’histoire d’Okina, les auteurs de cet article sont rattachés au SCD de l’Université d’Angers. Celui-ci connaît alors une période d’incertitudes, la direction étant vacante depuis quelques mois et l’intérim assuré par la directrice adjointe Nadine Kiker. Prenant officiellement la direction du SCD en septembre 2012, Nathalie Clot demande que soit réétudiée la question de l’archive locale versus une utilisation directe de HAL 1

, et conditionne l’utilisation d’une archive institutionnelle au vote d’un mandat officiel valant obligation de dépôt pour les chercheurs.

Des comparatifs fonctionnels sont alors réalisés, des scénarios soulignant les implications RH respectives établis. À la suite de la semaine Erasmus passée par la chef de projet à l’Université de Liège, pionnière en matière d’archive ouverte institutionnelle avec ORBi ouverte dès 2007, une délégation angevine se rend à son tour à Liège : le président de l’UA, Jean-Paul Saint-André, la directrice du SCD, le VP numérique et un directeur de laboratoire y rencontrent Paul Thirion, directeur des bibliothèques universitaires, et Bernard Rentier, alors recteur de l’Université, convaincu de la première heure du bien-fondé de l’Open Access et des archives locales. Celui-ci trouve les mots pour achever de convaincre le président.

En mars 2013, lors du CS qui suit ce voyage liégeois, le principe d’une archive institutionnelle locale et connectée à HAL est officiellement voté, puis c’est au tour du texte d’un mandat de dépôt 2

d’être adopté en CS et CA en avril 2013. Le travail technique commence lors de l’été 2013.

Le local ou le portail ?

S’il semble évident que HAL joue un rôle de plate-forme nationale qui n’est pas à remettre en cause, il paraît tout aussi évident que la priorité du CCSD doit rester la diffusion en Open Access et qu’il faut éviter de « tordre » l’outil pour en faire une base de gestion interne aux institutions, dérive qui présente le risque de multiplier les dépôts de notices seules (ce type de dépôt représente actuellement environ deux tiers du nombre total de dépôts HAL). En ce sens, logiquement, les archives institutionnelles locales paraissent essentielles à développer au sein des institutions souhaitant avoir une vue exhaustive de leurs publications.

Par ailleurs, les archives locales permettent de disposer classiquement de fonctionnalités absentes de HAL. Ainsi, dans le cadre d’un mandat d’obligation de dépôt des fichiers, et en l’absence d’une directive politique claire enjoignant à diffuser systématiquement la version auteur en accès libre, il est nécessaire de permettre la modulation des droits d’accès aux fichiers car tous ne peuvent pas – sauf choix personnel des auteurs – être diffusés en accès libre. En l’occurrence, HAL permet d’entrer une référence avec fichier diffusé en accès libre, le cas échéant après une période d’embargo pouvant aller jusqu’à deux ans, mais HAL ne gère pas l’accès restreint, ce qui oblige à déposer une notice nue lorsque les droits de diffusion en accès libre ne sont pas acquis 3

. HAL, ici, ne répondait clairement pas à l’un des besoins de l’UA puisqu’il était important pour l’Université que tout fichier puisse être déposé et diffusé, de manière directe ou non.

Il paraissait également primordial d’être au plus près des besoins des chercheurs, et de bénéficier du retour des utilisateurs pour procéder à des améliorations immédiates ou à la création de nouveaux services. Cette proximité, permettant une réactivité maximale dans le cas d’une équipe maîtrisant son outil et son planning de développement ou de paramétrages, était évidemment assurée uniquement dans le cas d’une archive institutionnelle locale.

Enfin, le souhait premier était de travailler avec le souci permanent de faciliter autant que possible le travail des chercheurs. Cet objectif, apparemment simple, a de nombreuses implications, allant de l’identification automatique sans nécessité de création de compte sur un site externe, à l’ergonomie du formulaire, qu’il s’agissait de rendre le plus intuitif possible. La plate-forme nationale HAL, que ce soit sous sa forme générique ou ses portails, ne répondant pas à ces critères, il a été finalement fait le choix d’une archive institutionnelle locale.

La gestion du projet

Les ressources humaines

Dans la vie d’Okina, une étape importante s’est produite début mai 2013 lorsqu’une lettre de mission signée du président de l’Université a été adressée à la chef de projet. Ce document précieux rappelait en effet les objectifs poursuivis et la tutelle politique du projet (en l’occurrence, le vice-président délégué au développement du numérique) tout en en fixant les contraintes, en particulier de délai, soit mars 2014 pour la mise en œuvre d’un outil bêta, et mars 2015 pour la généralisation de son utilisation à l’ensemble des unités.

Les moyens humains étaient également précisés dans ledit document.

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 1^er septembre ;
• 1 développeur temps plein 7 mois à partir du 1^er juin.

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 août ;
• 1 développeur temps plein 5 mois jusqu’au 31 mai ;
• finalisation de l’une ou l’autre fonction ci-dessus pour mise en production 1^er septembre 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.

Trello, une aide précieuse

Concernant le quotidien de la gestion de projet, deux tableaux de bord Trello 4

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 dispose en effet de fonctionnalités fort utiles, telles que la possibilité d’assigner des tâches à des individus, de mentionner des échéances pour chaque item, de catégoriser les « cartes », de dresser des listes à cocher, etc. 5

Le tableau de bord technique, utilisé prioritairement par le développeur et la chef de projet, a permis de lister les fonctionnalités souhaitées, de préparer de la documentation en vue des développements, de planifier les réalisations et de les suivre. Concrètement, ce tableau se compose des éléments suivants, de gauche à droite : une wishlist (comprenant encore de nombreux items, peut-être pour une v2 future ?), trois listes priorisant les fonctionnalités à réaliser, « étape 3 », « étape 2 », « étape 1 », une liste « en cours » et une liste « réalisé ».

Le tableau de bord « laboratoires », partagé entre l’assistant-ingénieur et la chef de projet, a été pour sa part utilisé pour dresser les listes de laboratoires par pôles, référencer les correspondants pour chaque laboratoire, et organiser les vagues d’intégration des unités.

Quelques détails de méthodologie

Dans les coulisses

Tout le travail effectué lors du projet Okina s’est fait suivant l’inspiration de la méthode agile : priorisation des attendus, déploiement d’une v1 (en interne dans un premier temps) 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 permet en effet une grande réactivité et des ajustements immédiats en fonction des retours des utilisateurs, et donne des résultats intéressants pour des configurations du type de celle en place sur ce projet.

Après avoir au départ essayé d’adopter et d’appliquer très scrupuleusement la méthode SCRUM, il est vite apparu que la petite taille de l’équipe rendait les choses un peu artificielles. Il a donc été décidé de mettre en place plus simplement des points d’étapes très réguliers avec Daniel Bourrion, supérieur hiérarchique de la chef de projet, dans le rôle du facilitateur, ces points constituant autant de bilans temporaires en plus des échanges permanents permis par la proximité physique 6

et la taille réduite de l’équipe-projet (3 personnes).

Concernant la v1 d’Okina, elle a été ouverte en interne en avril 2014, sans le module de tirés à part, et évidemment sans le module d’envoi dans HAL dont la conception a occupé les trois derniers mois de l’année 2014. Avant sa mise en production, cette v1 a été testée une première fois – et alors même que le travail de mise en page graphique n’avait pas débuté – par un chercheur en ingénierie des systèmes choisi pour sa familiarité avec les questions de développements informatiques : le fait que le site soit peu présentable et en désordre ne constituait pas un obstacle à ces tests et à ces retours. Une fois l’habillage graphique réalisé, de nouveaux tests ont été réalisés avec des chercheurs chimistes.

Dans la même logique, les modules développés ont fait l’objet d’une batterie de tests successifs : d’abord éprouvés dans un premier temps par la chef de projet et l’assistant-ingénieur 7

, ils ont ensuite été pris en main par les utilisateurs eux-mêmes 8 de manière informelle. Les bêta-testeurs n’ont en effet pas été réunis spécifiquement pour réaliser des scénarios prédéfinis, du fait du risque de désamour que représentaient de trop nombreuses sollicitations, mais il leur a été demandé de décortiquer l’outil et de faire tout retour qu’ils pouvaient juger utile, ce qu’ils ont fait très volontiers.

Enfin la version 2 d’Okina a été mise en production en février 2015, et ouverte dès lors au grand public, des ajustements continuant depuis cette date à être effectués sur l’outil, en fonction des demandes et des ressources humaines disponibles pour y répondre.

Des utilisateurs et des contenus

Afin d’assurer l’intégration des laboratoires, une première vague de test a été constituée avec huit laboratoires volontaires, de discipline, taille et rythme de publications variés. Après cette première expérience destinée à rôder la procédure envisagée, les autres laboratoires ont été ventilés en cinq vagues prises en charge successivement d’octobre 2013 à juin 2015 par l’assistant-ingénieur et la chef de projet, qui en assuraient conjointement l’encadrement et l’accompagnement.

Pour ce qui concerne le processus d’intégration, il comprenait plusieurs phases, de la vérification de la liste du personnel aux formations desdits personnels en passant par la reprise du rétrospectif des chercheurs. Par ailleurs, il a été demandé à chaque laboratoire de désigner en son sein un correspondant – IGE ou chercheur selon les unités, parfois même directeur du laboratoire – avec qui l’équipe-projet pouvait échanger et travailler directement.

Le mandat imposant le référencement des publications depuis 2008, et pour ne pas décourager les chercheurs, il avait été par ailleurs décidé que l’équipe-projet Okina se chargerait directement du rétrospectif 9

des laboratoires correspondant à la période 2008-2012. Ceci a constitué l’une des deux principales missions de l’assistant-ingénieur, l’autre versant de ses tâches consistant en la formation des utilisateurs 10. À lui seul, l’assistant-ingénieur a ainsi créé au final dans Okina, en lieu et place des chercheurs, plus de 7 000 notices bibliographiques.

Pour que cette tâche conséquente puisse être réalisée, il a été demandé à chaque laboratoire de fournir ses données bibliographiques sous la forme de son choix. Dans de rares cas, des bases bibliographiques existaient déjà en interne, permettant de disposer d’exports dans des formats standards connus d’Okina. Plus souvent, il a fallu travailler à partir de listes au format doc ou pdf.

Le travail consistait alors à créer des enregistrements Zotero pour chaque publication, en recherchant préalablement chaque élément en ligne, afin de récupérer des notices plus complètes que les seules informations fournies dans des citations parfois bien lacunaires. Une fois que la collection du laboratoire était complète dans Zotero, un import dans Okina était effectué. Enfin, et c’était là la partie de loin la plus rébarbative, il « restait » à repasser sur chaque notice pour mentionner les affiliations UA du ou des auteurs 11

des publications. Cela terminé, il était temps de passer à la phase suivante, celle des formations.

Pour ces formations, le schéma a été d’organiser d’abord une présentation générale d’Okina et du projet à destination de l’ensemble des membres du laboratoire, présentation assurée par la chef de projet et l’assistant-ingénieur 12

. Ensuite, des formations composées de petits groupes d’une douzaine de personnes maximum et prises en charge par l’assistant-ingénieur, aidé de la chef de projet, étaient proposées aux laboratoires, sur plusieurs créneaux horaires, à plusieurs dates. Enfin, en dehors de ces formations de groupes, des formations individuelles étaient et sont toujours dispensées à la demande.

On notera qu’il est apparu très nettement que le facteur décisif d’une mobilisation maximale des chercheurs, doctorants et autres personnels d’un laboratoire était l’investissement de son directeur dans le projet : si celui-ci était absent des échanges préalables, peu motivé ou inintéressé, les interventions sur un projet tel que celui décrit ici ne parvenaient à toucher que des chercheurs motivés par ces problématiques à titre individuel. Au contraire, dans les cas où le directeur adoptait et présentait Okina comme l’outil du laboratoire, les interventions faisaient pour ainsi dire salle comble.

Lors des formations, il était demandé aux publiants de se munir des fichiers de leurs articles depuis 2012. Un premier temps permettait de leur apprendre à ajouter leurs documents sur les notices 2012 pré-saisies par Emmanuel Lemoine. Les participants étaient ensuite formés à déposer les références complètes de leurs parutions postérieures à 2012. Évidemment, les chercheurs ont apprécié de trouver dès leur première connexion des listes de publications déjà associées à leur nom, et ils étaient naturellement enclins à compléter ces listes avec les publications n’y figurant pas encore.

Concernant la création des comptes 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 à tel ou tel laboratoire à partir d’Harpège et d’Apogée, envoyée pour vérification au correspondant de chaque laboratoire pour correction, signalement des départs en retraite ou ajout des nouveaux arrivants. Au retour de la liste corrigée vers l’équipe-projet, une copie en était envoyée pour information aux services RH de l’Université pour d’éventuelles mises à jour, puis la liste finale était finalement importée dans Okina, avec attribution automatique du rôle « déposant » aux comptes ainsi créés.

Cette manière de procéder a émergé du fait qu’aucun référentiel « personnes » n’était suffisamment à jour pour travailler sur une récupération automatique des données dans Okina via des connexions LDAP 13

 : ces données n’auraient pas été fiables. Toujours est-il que lors des séances de formation, les utilisateurs n’avaient qu’à se connecter : sans création de compte ou opération préalable à exécuter, ils avaient directement accès au dépôt.

Zoom technique

Drupal et ses modules

Après le choix de construire une archive institutionnelle locale, et considérant qu’aucun des outils spécialisés présents sur le marché en 2012-2013 ne disposait de l’ensemble des fonctionnalités souhaitées, décision avait été prise de partir d’une base applicative existante et de réaliser les développements nécessaires.

Du fait des compétences locales construites autour de Drupal et de ses multiples possibilités, déjà mises en œuvre avec le site web de la BU d’Angers 14

et surtout DUNE 15, l’archive des travaux étudiants de l’UA, le choix s’est rapidement porté sur ce CMS, dont le principal avantage est sans conteste que nombre de fonctionnalités peuvent être imaginées et créées grâce à de simples paramétrages de vues et de règles automatisant le déclenchement d’actions 16.

Un certain nombre de modules déjà existants et bien maintenus rendaient de plus immédiatement disponibles des fonctionnalités attendues. Citons en particulier :

• CAS 17
  X
  

  https://www.drupal.org/project/cas

  , pour l’identification des usagers de l’Université ;
• Bibliography 18
  X
  

  https://www.drupal.org/project/biblio

  , pour la gestion des références bibliographiques ;
• Search API 19
  X
  

  https://www.drupal.org/project/search_api

  , son extension Biblio Search API, et Facet API pour la recherche parmi les références ;
• Views OAI-PMH 20
  X
  

  https://www.drupal.org/project/views_oai_pmh

  pour l’implantation du protocole éponyme ;
• Download Count 21
  X
  

  https://www.drupal.org/project/download_count

  pour les statistiques de téléchargements.

Certaines fonctionnalités offrant des éléments plus spécifiques ont en revanche nécessité un développement intégral, toujours en respectant la logique de 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.

Si certains de ces modules sont très simples (Biblio Sherpa Romeo par exemple), d’autres sont clairement plus complexes (l’envoi dans HAL en particulier). Quoi qu’il en soit, l’ensemble de ces développements, plus le montage intégral du site, la sélection des modules à déployer, leur configuration, la réalisation de l’habillage graphique du site, et tous les paramétrages, ont été effectués sur une période courant de l’été 2013 à décembre 2014.

Métadonnées et fonctions bibliographiques

On l’a vu précédemment, la gestion des références bibliographiques dans Okina repose sur un module dédié préexistant au projet, nommé Bibliography. Ce module, riche et intéressant, dispose de fonctionnalités dont certaines méritent qu’on s’y arrête quelques lignes.

Dans le cahier des charges initial, les références bibliographiques devaient pouvoir être entrées de différentes manières, d’une part, à l’unité ou en lots, d’autre part, en étant entièrement créées ex nihilo ou précomplétées automatiquement à partir d’un DOI par exemple. C’est justement l’une des fonctionnalités natives du module Bibliography qui est ici utilisée et qui permet au déposant d’opter pour la complétion manuelle du formulaire, un copier-coller Bibtex ou RIS, ou encore un import à partir d’un DOI ou d’un PubMedID. Ce module permet également l’import d’un lot de notices 22

sous forme de fichiers BibTex, Endnote, RIS, MARC, etc. En outre, Bibliography propose un dédoublonnage a priori lors des imports sur DOI, PubMedID ou copier-coller BibTex/RIS : ce qui a déjà été importé, un DOI par exemple, ne peut l’être une seconde fois, et Okina redirige en ce cas automatiquement l’utilisateur vers la notice préexistante 23.

Toujours dans l’écosystème Drupal, signalons au passage Bibliography Advanced Import 24

, un module très intéressant offrant nombre de possibilités puisqu’il permet de définir les règles de repérage des doublons et l’action à mener (ne rien faire, mettre à jour, remplacer). Ce module n’a toutefois pas été utilisé sur Okina, en particulier parce qu’il ne prend en compte que les métadonnées et qu’il n’est pas possible de définir une règle qui favoriserait la conservation d’une notice avec fichier par rapport à une notice seule.

Bien entendu, une fonction d’export des références dans divers formats standards était prévue et est également assurée par le module Bibliography, qui fournit les formats BibTex, RTF, EndNote, MARC, RIS, selon des règles de mapping de champs paramétrables via l’administration du module (dans les sens import comme export).

Enfin, pour ce qui concerne les métadonnées d’Okina, elles sont exposées en OAI-PMH grâce au module Views OAI-PMH 25

. Notons ici que l’exposition par sets n’est en revanche pas implantée de manière native dans le module et qu’elle nécessiterait un développement qui n’a pas été jugé prioritaire et n’a finalement pas été réalisé à cette date.

Fichiers, tirés à part

L’un des choix initiaux du projet a été de permettre aux utilisateurs de déposer les versions auteur ou éditeur de leurs articles, et de choisir pour chaque fichier ses modalités de diffusion selon trois possibilités : accès libre, accès restreint (accès à la seule communauté de l’UA, après identification), ou confidentialité. De cette manière, tous les fichiers, sans exception, peuvent être déposés dans Okina.

Précisons par ailleurs que, contrairement à ORBi par exemple, le dépôt du fichier n’est pas requis sur Okina, quel que soit le type de publication : même si le mandat requiert qu’un fichier soit joint aux notices d’articles publiés depuis 2012, il est techniquement possible d’enregistrer une référence bibliographique seule. Ce choix a ses avantages et ses inconvénients. La présidence ayant souhaité utiliser Okina pour les extractions HCÉRES, en fixant comme priorité les références bibliographiques jusqu’à l’automne 2015, une autre option n’aurait de toute façon pas pu convenir jusqu’ici. On peut espérer toutefois que la pédagogie, l’émulation entre pairs et une politique forte en faveur de l’accès ouvert favoriseront le dépôt systématique des fichiers dans un avenir très proche.

L’objectif premier d’une archive ouverte restant la diffusion la plus large possible des travaux de la recherche, il fallait également disposer d’une fonctionnalité permettant aux auteurs de distribuer des tirés à part de leurs articles aux utilisateurs qui leur en feraient la demande, que les fichiers soient en accès restreint ou confidentiels. Le fameux bouton, « request copy », parfois sujet de polémiques, a donc fait l’objet du développement d’un module spécifique.

Une logique permanente de facilitation

Okina dispose évidemment de fonctionnalités, plus ou moins classiques des archives ouvertes ou même de sites web, telles que la recherche à facettes. Les lignes qui suivent ne se penchent cependant que sur certaines de ces fonctionnalités plus « particulières ».

Toutes les raisons susceptibles de créer un rejet d’Okina par les chercheurs ont été, d’une manière générale et dans la mesure du possible, écartées. En l’occurrence, les arguments classiques en défaveur des archives ouvertes sont bien connus : « on nous demande toujours du travail administratif supplémentaire », ou « mes papiers sont déjà dans ResearchGate ». Citons aussi, mais assez rarement à l’UA où, curieusement, le dépôt dans HAL était peu fréquent et la plateforme nationale peu connue de la majorité des chercheurs jusqu’à l’émergence du projet Okina, le fameux « je dépose déjà dans HAL », ou enfin le tout aussi classique « le formulaire est incompréhensible ».

L’interface

Pour répondre à ce dernier argument, un soin particulier a été apporté à l’ergonomie du formulaire de dépôt 26

, qui comporte un minimum de champs obligatoires (ils sont au nombre de trois : le titre, l’année, le type de document), choix radical fait en comptant sur le bon sens des déposants pour qu’ils en complètent davantage, et sur une modération a posteriori par des bibliothécaires pour enrichir les notices si besoin.

Le lien avec HAL

Il s’agissait également d’éviter que le dépôt dans Okina soit vécu comme « encore un dépôt de plus », le challenge étant au contraire de faire de l’archive institutionnelle le lieu de dépôt unique pour l’UA avec dissémination automatique ou facilitée vers d’autres archives ou sites. En particulier, compte tenu du contexte national, il était indispensable de développer un connecteur Okina-HAL, l’archive centrale ne moissonnant pas les dépôts institutionnels, au contraire de ce qui se fait en Belgique. Pour cela, un travail a été mené à partir de la documentation technique du CCSD, et en collaboration avec Laurent Capelli via échanges de mails, dès le passage en production de la v3 de HAL à l’automne 2014 27

.

Notons que, côté utilisateur, l’envoi dans HAL n’est pas systématique puisque c’est 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. Plusieurs raisons motivent ce choix.

D’abord, il a semblé essentiel que l’utilisateur accepte lui-même les conditions de HAL, considérant qu’il n’était pas de la mission des gestionnaires de l’archive, simples intermédiaires, d’endosser cette responsabilité. En particulier, il n’était pas question que des envois systématiques de fichiers fassent postérieurement au dépôt l’objet de demandes de retrait par les utilisateurs, demandes que les gestionnaires locaux auraient eues à traiter avec le CCSD, et qui iraient de plus à l’encontre de la politique de HAL 28

. En outre, un dépôt HAL systématique aurait participé à la création de doublons dans le cas d’auteurs hors UA déposant déjà dans HAL, en raison de l’absence de contrôle sur les notices sans texte intégral côté plateforme nationale.

En tout cas, lors d’un envoi vers HAL, et HAL étant plus exigeant que Okina pour ce qui concerne les métadonnées, le déposant se voit demander de procéder à la complétion des champs obligatoires dans HAL éventuellement laissés vides jusque-là côté Okina. Pour cette raison, il est d’ailleurs apparu à l’usage que certains déposants renoncent à l’envoi dans HAL, mais la simplicité de dépôt dans l’archive de l’établissement étant la priorité, le choix du nombre minimal de champs obligatoires a été maintenu pour ne pas ralentir l’adoption de l’outil.

L’import-export

Toujours dans cette 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 (par exemple par type de documents, panier de sélections). Des flux XML permettent également une récupération automatique des références dans des sites tiers. Enfin, parmi les fonctionnalités souhaitées au départ du projet mais malheureusement non réalisées faute de temps de développement disponible figure l’envoi dans d’autres archives, en particulier arXiv 29

.

Un bilan

Côté utilisateurs

Sur environ 900 utilisateurs potentiels 30

à l’Université, 257 ont été formés par l’équipe-projet et 389 ont créé au moins une notice dans Okina. La mobilisation par laboratoire s’est révélée par ailleurs fluctuante, jusqu’à l’exemple enthousiasmant de quelques laboratoires au sein desquels les correspondants sont apparus très actifs, suivant les dépôts « locaux » et formant eux-mêmes leurs collègues. Quoi qu’il en soit, 604 personnes parmi les utilisateurs potentiels se sont connectées au moins une fois à la plate-forme.

Malgré ces bons chiffres, une part importante de la communauté reste toutefois encore à sensibiliser, notamment dans le domaine de la santé où plusieurs laboratoires n’ont manifesté aucun intérêt pour l’outil en ne semblant pas voir l’intérêt des archives ouvertes du fait de l’existence de PubMed.

Du point de vue qualitatif, pour ce qui concerne les utilisateurs, ils expriment sans ambiguïté lors des formations leur satisfaction 31

, en particulier en ce qui concerne la simplicité de l’outil, la facilité de prise en main d’Okina étant à peu près systématiquement soulignée comme une bonne surprise. Les services 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.

Coté contenus

12 987 références bibliographiques sont signalées dans Okina à ce jour. Parmi elles, 5 690 ont été créées par les chercheurs eux-mêmes, ce qui représente une moyenne de plus de 14 références par utilisateur déposant, le reste des dépôts étant le fruit du travail de reprise du rétrospectif évoqué plus haut, et d’une aide ponctuelle apportée aux laboratoires pour leur permettre d’extraire leur liste de publications en temps et en heure pour l’HCÉRES. Si le mandat de dépôt requiert le signalement des productions depuis 2008, on notera que certains chercheurs ont rapidement compris l’intérêt de l’outil et signalé l’ensemble de leurs publications, y compris certaines remontant aux années 1980.

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

Par ailleurs, 3 160 notices correspondent aux critères du mandat voté par l’Université 32

, mais seules 715 comportent un fichier, soit 23 % des notices concernées. Ce pourcentage constituerait un score plutôt bon pour une archive ouverte non régie par un mandat de dépôt. Dans le cas d’Okina, on voit bien que la politique officielle de l’Université en la matière n’a pour le moment pas de répercussion concrète sur l’utilisation de l’archive ouverte institutionnelle.

Plusieurs explications peuvent être apportées. La première est sans doute que, fin 2015, du fait de l’échéance HCÉRES 33

, la priorité de la gouvernance a clairement porté sur l’obligation de signalement des références et non sur l’obligation de dépôt de fichiers.

Ensuite, il n’existe actuellement aucun contrôle du respect du mandat, et aucune conséquence, positive ou négative, n’est définie pour qui se plie (ou ne se plie pas) à ce mandat, demeurant de fait pour l’instant une invitation plus qu’une réelle obligation.

Une fois l’évaluation HCÉRES terminée, l’accent devrait cependant à nouveau être mis sur la dimension Open Access du projet, et il est à espérer que se mette en place une réelle politique en la matière avec l’appui des élus et de la direction recherche de l’Université.

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.

Coté coulisses

Côté coulisses, la difficulté majeure se situe actuellement dans la sortie du mode projet d’un programme lancé voilà plusieurs années, et l’attribution de ressources humaines pour le suivi courant d’Okina, qu’elles relèvent du service commun de la documentation, de la Direction recherche ou de postes en dehors de ces deux services. En l’espèce, plusieurs scénarios ont été construits pour accompagner cette nécessaire sortie de mode projet, qui attendent encore une prise de décision.

L’assistant-ingénieur n’est en tout cas plus en poste à l’Université depuis septembre 2015 du fait de la fin de son CDD. Les auteurs de cet article ont pour leur part été mis à disposition par le SCD sur un nouveau service de la Direction du développement du numérique, le Lab’UA 34

, et le projet Okina a suivi ces personnes puisqu’il n’était évidemment pas question de l’abandonner en l’absence de réorganisation de sa gestion humaine.

Actuellement, deux personnes assurent le suivi quotidien d’Okina, soit sa chef de projet et un personnel magasinier du SCD, à temps partiel et en télétravail, depuis septembre 2015. Pour cette dernière personne, le travail consiste au contrôle qualité des métadonnées au fur et à mesure des dépôts puisqu’il n’y a pas de validation a priori des enregistrements faits par les utilisateurs mais, en revanche, un contrôle a posteriori des notices, corrigées ou complétées le cas échéant, avec rappel au déposant, si besoin, des mentions essentielles qu’il aurait omis (son laboratoire par exemple).

Ce suivi quotidien est primordial et les éventuels échanges avec le chercheur doivent être faits le plus rapidement possible après le dépôt. Cette réactivité a en effet des conséquences très positives : les déposants répondent, des échanges s’ensuivent, des formations se mettent également en place, parfois le jour même. Partant, ce suivi est apprécié, les utilisateurs constatant qu’ils sont réellement accompagnés dans leur démarche de dépôt, ce qui ne peut que les satisfaire, voire les rassurer.

De nombreuses tâches ne sont cependant pas encore passées dans les missions courantes d’autres ressources humaines qui seraient dévolues à Okina. À terme, il faut espérer que d’autres personnels s’occuperont côté SCD des métadonnées, mais aussi des fichiers. De plus, il serait grandement souhaitable qu’un personnel prenne en charge le suivi des référentiels laboratoires et auteurs, ainsi que celui des mouvements de personnel au sein des unités.

Côté outil

Du strict point de vue technique, le développeur qui est intervenu dans ce projet a veillé à appliquer les bonnes pratiques de développement pour Drupal. Il respectait par là l’objectif premier de réaliser des modules utilisables par tous, et disposant donc d’interfaces de configuration pour tous les éléments variant d’une instance à l’autre, le but avoué étant de mettre ces modules à disposition de la communauté Drupal.

L’une des ambitions de ce projet était aussi de réaliser une distribution Okina prête à l’emploi incluant tous les modules indispensables à une archive ouverte institutionnelle, et qui pourrait être diffusée, déployée et réutilisée facilement par d’autres établissements ou institutions. Ici, le temps a malheureusement manqué au développeur pour parfaire ce packaging si bien que les modules créés ne sont pour la plupart pas partagés en ligne à cette date. Ce point est d’autant plus frustrant qu’il ne reste que peu de travail à effectuer pour que ces modules soient parfaitement réutilisables, mais à l’heure actuelle, d’autres priorités ont éclipsé cette question. Le souhait demeure toutefois d’aller au bout de ces développements pour finaliser dès que possible une distribution Okina, aboutissement logique de la démarche ici retracée.

Si Okina est plutôt une réussite du point de vue de l’expérience utilisateur, des points noirs subsistent pour les professionnels amenés à suivre les dépôts, comme pour toute application similaire.

En particulier, aucune solution miracle n’a été trouvée à la question des multiples formes auteurs, ce qui suppose encore d’effectuer une vérification systématique des noms d’auteur sur chaque nouveau dépôt afin de fusionner si nécessaire les formes dans le référentiel auteurs, pour ce qui concerne les chercheurs de l’Université.

Du fait de l’import des nouveaux laboratoires depuis HAL, le problème des nombreux doublons existant dans la base HAL d’origine se reporte également sur Okina. Une alerte a donc été mise en place, qui signale chaque nouveau laboratoire importé : il arrive encore que des chercheurs importent une occurrence nouvelle d’un laboratoire de l’Université, et créent ainsi un doublon, et ce, malgré les efforts de pédagogie et de mise en valeur graphique de la ligne à choisir, déjà présente dans le référentiel Okina. Ce suivi qualité, effectué quotidiennement par la chef de projet, n’est pas délégué pour le moment : aucune ressource humaine n’est présente pour le prendre en charge, et cette prise en charge suppose en outre comme prérequis d’être très familier des sigles, codes, labels des unités de l’Université.

En guise de conclusion

Au final, 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 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. Ici, ce n’est plus tant d’un sprint dont il s’agit, que qu’une course de fond – une tout autre discipline.