Outils et applications métier en BU : une enquête, une rencontre

Sur cette base, la commission SSI a proposé un échange avec la communauté, sous la forme d’ateliers en visio-conférence le 24 mars dernier.

Cette réunion a regroupé 25 collègues, issus d’établissements variés, et occupant généralement des fonctions au sein de services d’informatique documentaire. Suite à une présentation rapide des premières conclusions de l’enquête, les participants ont été répartis en 4 ateliers, portant sur les différentes étapes qui guident l’acquisition ou le développement d’un nouvel outil métier au sein des bibliothèques universitaires.

Associer les équipes du SCD dès la phase d’expression des besoins apparaît comme une démarche indispensable, qui se heurte néanmoins à des difficultés variées : se projeter dans un environnement nouveau, imaginer des fonctionnalités et des processus différents.

Cette étape est parfois considérée à tort comme purement technique, alors même qu’elle a pour objectif de permettre aux équipes métiers de transmettre leurs besoins en termes de fonctionnalités et de décrire leur utilisation des outils dans les processus de travail quotidiens. Les services d’informatique documentaire doivent être pleinement impliqués à cette étape pour accompagner et guider les collègues dans cette démarche d’expression des besoins.

Pour faciliter cette étape, plusieurs idées ont été évoquées lors de l’atelier :

• Organiser des réflexions collectives sur les circuits, fonctionnalités, manques des outils actuels, pour mettre à plat le fonctionnement et aider les équipes à verbaliser leurs besoins ;

• Organiser des présentations d’outils par les prestataires, pour montrer ce qui existe dans d’autres établissements et aider les équipes à se projeter dans d’autres fonctionnements ;
• Désigner des responsables de modules ou de fonctionnalités, qui seront ensuite impliqués dans toutes les phases du projet (réflexion sur les fonctionnalités, tests, formation etc.)

Si l’implication des collègues des équipes métier dès cette phase d’expression des besoins est identifiée comme indispensable, le fait d’associer la DSI à la démarche est moins systématique et dépend des contextes locaux qui s’imposent aux SCD.

Lorsqu’elle est très impliquée dans les projets du SCD, la DSI peut participer à la formalisation des processus (rédaction de fiches projet, workflow de validation). Une implication précoce de la DSI et la mise en place d’un dialogue fructueux entre les équipes constituent alors un atout pour les projets du SCD, et permettent d’identifier, dès la phase d’expression des besoins, l’existence de contraintes techniques ou de préférences de la DSI.

Lorsque la DSI n’est pas du tout impliquée, notamment par manque de disponibilité, les projets sont moins accompagnés et soutenus, ce qui peut provoquer pour la suite des problèmes techniques (sauvegardes, d’interfaçage, etc)

Le processus de choix, de sélection d’un outil varie en fonction du besoin et du contexte (notamment de la taille des établissements), mais la relation avec la DSI est identifiée comme centrale pour tous les établissements, que ce soit dans la réflexion ou dans les stratégies mises en œuvre.

De façon générale, l’échelle du projet induit fortement la méthodologie suivie. Lorsque le périmètre du projet dépasse le cadre strict du SCD, au sein de l’université ou de la COMUE par exemple, les procédures de choix et de conduite de projet sont fortement formalisées, et associent plusieurs acteurs, dont les DSI.

Lorsque les projets sont de moindre envergure, le choix de l’outil peut s’opérer de manière moins formelle et interne aux SCD ou services.

Quelle que soit l’étape à laquelle les DSI interviennent, leurs retours peuvent induire des stratégies de contournement variées si les propositions ne sont pas pleinement adoptées : développements internes, hébergements externalisés, recours à des outils externes à l’université et déployés au niveau inter-universitaire (SICD par exemple), recours à des développements réalisés par des prestataires sur des outils déjà déployés (SIGB par exemple).

La question des moyens tant humains (compétences informatiques propres aux services) que financiers est une source de contraintes fortes qui préside aux choix. La perspective d’une éventuelle mutualisation à termes constitue rarement un élément pris en compte en première intention dans le choix de l’outil.

Dans la perspective de simplifier cette étape de choix d’un nouvel outil, quelques idées ont été partagées lors de l’atelier :

• Organisation de rendez-vous réguliers avec les DSI sur les questions documentaires, y compris en dehors du cadre de la gestion de projet
• Favoriser l’information mutualisée sur les outils existants qui donnent satisfaction afin de faire émerger et de formaliser d’éventuels besoins

Au sein de cet atelier encore, la dépendance très importante des SCD vis-à-vis des DSI a été relevée comme une réalité unanimement partagée. En effet, l’intégration des outils des bibliothèques dans l’infrastructure générale de l’université est nécessaire afin de pouvoir utiliser les serveurs et de s’interfacer avec les autres applications de l’écosystème informatique de l’établissement.

Cette interdépendance se révèle parfois bénéfique, car elle pousse les bibliothécaires à s’intégrer dans un environnement plus large, mais constitue également un frein lorsque les relations avec la DSI sont compliquées ou que les ressources humaines dédiées ne sont pas suffisantes. L’activité globale et la marge d’autonomie laissée aux bibliothèques dépend de la culture d’établissement dont la DSI se fait l’écho (outils libres ou propriétaires par exemple).

Lorsque le choix est fait de développer un nouvel outil, les établissements peuvent envisager plusieurs alternatives.

Dans certains cas, le développement repose, au sein de la bibliothèque, sur l’implication d’une personne ressource, c’est-à-dire intéressée et capable techniquement de développer une application destinée à l’usage des services internes du SCD. L’implication d’une telle personne dans ce type de projet permet à la bibliothèque de gagner en autonomie et d’imaginer des projets de plus grande envergure, en adéquation directe avec les besoins des équipes, ce qui représente un atout essentiel. Néanmoins, cela nécessite aussi une adaptation forte de l’organisation en cas de départ ou d’évolution du poste dans l’organigramme, afin d’assurer la soutenabilité des projets à long terme et de ne pas perdre de visibilité sur l’activité de la bibliothèque au niveau de l’université.

L’établissement peut également faire le choix d’un stage consacré au développement, qui représente une solution intermédiaire entre l’externalisation et l’internalisation complète des développements. Cette solution reste néanmoins relativement peu connue et rarement mise en œuvre en bibliothèque universitaire. En effet, les stages de développement demandent un investissement fort en termes de formation et souvent de correction a posteriori.

Enfin, l’établissement peut opter pour l’externalisation de certains développements. Cette solution peut néanmoins rencontrer certaines réticences auprès des DSI, très attentives aux solutions d’hébergement des applications externes (sécurité des données et des accès, questions financières).

La mise en place de nouveaux développements est parfois ralentie par la difficulté à communiquer sur ces derniers et à former même en interne les personnes directement concernées. Les outils de type dossiers partagés, google drive ou wiki posent des problèmes d’actualisation régulière et d’organisation, que les établissements ne parviennent pas à résoudre totalement.

Les possibilités d’ouverture et de mise en commun ultérieures des développements réalisés constituent un point de vigilance récurrent pour les bibliothécaires. Cependant, ces intentions de mutualisation se heurtent souvent à la réalité d’un changement d’échelle et de ce que cela implique en termes de documentation, de sécurité, d’accompagnement, d’infrastructures. De plus, les développements sont souvent liés à des outils locaux spécifiques, ce qui freine considérablement la possibilité de partage en dehors des clubs utilisateurs. Pour toutes ces raisons, la mutualisation s’envisage souvent à l’échelle de la ville ou d’un ensemble restreint d’institutions partenaires, et plus rarement à l’échelle nationale.

Si quelques retours d’expériences de mutualisation de développements locaux ont pu être échangés au sein de cet atelier, cette pratique demeure rare, y compris lorsque les développements sont nombreux. Certains établissements ont pris l’habitude de déposer leurs développements sur GitHub, lorsque les collègues impliqués savent le faire et lorsqu’il existe déjà un espace GitHub pour l’outil sur lequel des développements ont été effectués.

L’absence de partage ne relève jamais d’une culture ou d’une politique d’établissement délibérée, mais plutôt de pratiques individuelles au cas par cas. De façon générale, il existe plutôt un a priori favorable à cette notion de partage.

Ces démarches de mutualisation se heurtent à de nombreux freins, en premier lieu la logique du “sur-mesure” – qui est le propre des établissements pratiquant beaucoup le développement maison. Les développements réalisés ne sont pas toujours facilement transposables, pour plusieurs raisons (spécificités des outils, spécificités des besoins, spécificités des contextes).

Sortir du spécifique pour aller vers le générique, réécrire ou adapter un outil pour le rendre réappropriable par tous demande du temps et les bonnes volontés se heurtent au constat global d’un manque de disponibilité, qui traduit souvent un manque de ressources humaines ou financières.

Plus que le manque de temps, c’est parfois le manque de moments d’échanges et d’espaces de partage qui semble constituer le principal frein à la mutualisation.

Des propositions de leviers d’amélioration ont émergé lors de cet atelier. Si les spécificités d’établissement existent incontestablement, de très nombreux besoins en commun existent, ainsi que des écosystèmes d’outils qui convergent largement. Il y a donc matière à mutualisation et entraide. Pour que cette mutualisation fonctionne et devienne une habitude à plus large échelle, il est indispensable de sortir du particulier, de l’expérience ponctuelle et locale – aussi réussie soit-elle – et de bénéficier d’un portage, d’une reconnaissance et d’une formalisation de ces missions de mutualisation. Il existe plusieurs échelles possibles pour cela.

Au niveau local, ce peut être le rôle d’un réseau d’établissements. Les clubs utilisateurs constituent également d’excellents leviers. Enfin, au niveau national, cette mission de mutualisation figure dans les missions d’un opérateur national comme l’ABES, concernant la gestion et le traitement des métadonnées. D’autres leviers pourraient être à approfondir avec le ministère (appels à projets, reconnaissance et soutien financier…)

L’ensemble des échanges avec les participants ont permis de mettre en valeur les points saillants et communs à tous les établissements dans le processus de développement ou d’adoption de nouveaux outils (implication et accompagnement nécessaire de l’ensemble des acteurs internes au SCD et de la DSI tout au long du processus, interdépendances entre le SCD et la DSI, organisation de la démarche de développement, mise en place de conditions favorables à la mutualisation des développements). Ce temps d’échange entre la commission SSI et des membres du réseau ADBU a permis de compléter les conclusions techniques obtenues grâce à l’enquête en apportant une vision plus détaillée sur l’organisation interne des équipes et des processus de travail tout au long des projets de développement de nouveaux outils.