Cet article propose une synthèse du mémoire d’étude Programmation informatique en BU : vers un nouveau profil de bibliothécaire ? réalisé par Élise Leclere dans le cadre du diplôme de conservatrice des bibliothèques[1]. L’autrice a rejoint les bancs de l’Enssib après avoir travaillé pour la plateforme de revues en accès ouvert Prairial et le service de formation des usagers au sein des bibliothèques de l’université Jean Moulin Lyon 3. Elle est désormais responsable du département des formations des usagers de la Bibliothèque Sorbonne nouvelle.
Gérer la compétence en programmation informatique en bibliothèque universitaire : de la recension de l’existant à l’établissement d’une stratégie RH
Questionner la possession d’une compétence en programmation informatique dans les bibliothèques universitaires peut étonner, il s’agit cependant de l’une des compétences informatiques qui font l’objet de réflexions importantes au sein de la profession, comme le montre la réalisation de l’enquête « Applications informatiques métiers en bibliothèques universitaires » par la commission SSI de l’ADBU[2]. La nécessité d’un tel questionnement provient d’un contexte d’évolution plus général à l’œuvre au sein des bibliothèques universitaires. En effet, la technicité des tâches liées à la gestion des collections nécessite depuis longtemps de se familiariser avec des outils informatiques parfois complexes. Cependant, la place grandissante qu’occupent la collecte, le nettoyage, le traitement et l’exploitation des données, notamment dans le cadre de l’ouverture de la science, mais aussi de l’évaluation, implique de monter en compétence sur les outils qui permettent d’accomplir ces tâches et de les automatiser. Deux solutions sont possibles pour faire face à ce besoin : l’acquisition de compétences en interne à la bibliothèque ou le recours à une solution externe (en général fournie par l’université ou par un·e prestataire).
En résumé, la première solution a l’avantage de permettre une indépendance relative de la bibliothèque universitaire tout en permettant de créer ou d’adapter des outils propres à un contexte local sans avoir à en payer le coût de développement et de maintenance (le coût est évidemment alors à calculer en temps de formation et de travail, mais ne relève pas de l’investissement financier direct) ou à s’adapter aux délais de la DSI de l’établissement. Elle exige cependant un investissement important et répété en termes de formation et peut avoir des retombées négatives sur le plan des relations avec les autres services de l’université et de la pérennité des projets. La seconde solution a l’avantage de permettre l’acquisition d’outils normalement clés en main avec, a priori, de meilleures chances de pérennisation. Elle est également moins dispendieuse en temps de formation et de travail sur l’outil en lui-même. Il n’y a pas de solution idéale : les différentes situations rencontrées[3] s’expliquent par la conjonction d’un environnement (politique, stratégique ou financier), d’un besoin (réaliser une tâche ou obtenir des informations) et de la présence ou non dans l’équipe d’une compétence ou au moins d’une appétence, plus ou moins perçue et encadrée par la hiérarchie.