Version classiqueVersion mobile

Réinformatiser une bibliothèque

 | 
Anna Svenbro

Partie 1. Questions de méthode

Accompagner les changements de pratique dans un projet de réinformatisation

Catherine Storne-Sengel

Texte intégral

« On ne peut prévoir les choses qu'après qu'elles sont arrivées. » Eugène Ionesco, Rhinocéros

1Cette contribution met en exergue des points de vigilance pour aider les chefs de projet qui mèneraient des projets de réinformatisation du point de vue de la conduite du changement, en s’appuyant sur la description de l'organisation d'un projet de réinformatisation à Strasbourg. Eu égard à l'obsolescence du parc de SIGB dans les bibliothèques universitaires françaises et à la création des communautés d’universités et établissements (COMUE), la configuration rencontrée à Strasbourg est susceptible de se retrouver ailleurs.

Le contexte de la réinformatisation : tenir compte de l’environnement

  • 1 Les logiciels Sebina OpenLibrary (SIGB) et SebinaYOU (portail documentaire) ont été mis en place p (...)
  • 2 Profil graphique du SCD de l'université : < https//bu.unistra.fr >.

2Le réseau nouvellement informatisé des bibliothèques universitaires de Strasbourg est constitué de deux couches logicielles, l'outil professionnel (SIGB) et le portail documentaire public1. Ce réseau englobe la plupart des bibliothèques de l'université de Strasbourg, dont toutes celles du SCD, des bibliothèques d'écoles nationales (École nationale du génie de l'eau et de l'environnement de Strasbourg [ENGEES], École nationale supérieure d'architecture de Strasbourg [ENSAS], Institut national des sciences appliquées de Strasbourg [INSA]) auxquelles s'ajoute, uniquement pour le portail documentaire, la bibliothèque nationale et universitaire de Strasbourg (BNU). Au final, ce sont cinq SIGB qui ont été fusionnés et plus de 3 millions de notices qui sont désormais signalées sur le portail documentaire2.

Intégrer l’évolutivité du contexte

3Début 2010, l'université de Strasbourg, récemment fusionnée (2009), a inscrit le projet d'un nouveau SIGB dans son schéma directeur du numérique*, manifestant ainsi son soutien aux opérations de fusion des outils informatiques, dont ceux du SCD, et sa volonté d'inscrire l'informatique documentaire dans le SI général de l'université. À cette date, le SIGB était en effet la dernière brique du SID restant à unifier ; les autres l'avaient été depuis 2007, date de la fusion des SCD (anticipant celle des universités) de Strasbourg. Dans les faits, l'absence d'outil commun perpétuait des méthodes de travail différenciées, avec un sentiment d'appartenance au SCD unifié peu développé.

4En raison de ce contexte de fusions successives et d'une transformation organisationnelle décidée par la direction du SCD pour 2011, celle-ci a souhaité que la réinformatisation (ap)porte des changements fonctionnels mais pas structurels. Les changements de pratique devaient être menés sans nouvelle modification de l'organigramme.

5La durée totale du processus de réinformatisation a été très longue. Elle a duré cinq ans, dont une phase d'études et d'analyses préalables, deux ans de phase de marché public (choix du dialogue compétitif, dont un premier déclaré infructueux) et quatorze mois de mise en œuvre des logiciels choisis. Cela a évidemment créé un effet tunnel, période pendant laquelle, il était difficile de donner aux collègues de l'information sur l'avancement du projet, ce qui n'a pas été sans conséquence sur la conduite du changement à mener et la mobilisation des collègues. Quelle que soit l'étape, l'effet tunnel est un risque inhérent à tout projet ; il peut être réduit par la communication, ou l'établissement de jalons plus fréquents.

6Pendant cette période, des acteurs-clés du projet, que ce soit parmi les acteurs politiques ou les collaborateurs informatiques, ont changé d'affectation. Il y a donc eu nécessité constante de s'adapter à un environnement en mouvement. Enfin, en 2013, la partie portail documentaire du projet a été inscrite dans le schéma directeur de la documentation en Alsace, sur un périmètre élargi au SCD de Haute-Alsace.

Focus

Tout projet de réinformatisation doit être capable de s'adapter à un environnement et un contexte en perpétuel changement. L'ingénierie de marché choisie doit permettre de s'adapter à des modifications fonctionnelles ou de périmètre qui surgissent en cours de projet.

Intégrer les objectifs de l’institution aux objectifs du projet

7Les objectifs assignés à la réinformatisation étaient avant tout fonctionnels, pour ne pas dire techniques : remplacer les SIGB, dont certaines versions logicielles n'étaient plus maintenues, par un outil unique, évolutif, respectant les formats informatiques, avec reprise des données.

8Le nouveau système devait s'insérer au moins partiellement dans le SI de l'université, sur des points techniques (serveurs, langages de programmation) mais aussi sur les données des utilisateurs.

9La réinformatisation devait aussi créer un sentiment d'appartenance au SCD unique, en harmonisant les pratiques de travail, car la coexistence de plusieurs SIGB, hérités des anciens SCD, n'avait pas permis de faire converger toutes les pratiques.

10De manière plus générale, la réinformatisation était jugée comme un projet structurant dans un SCD qui lui-même devait être inscrit dans un processus continu d'amélioration des services.

11Enfin, la participation au projet de bibliothèques extérieures à l'université a introduit la création d'un réseau local, avec des règles de fonctionnement et de gouvernance à établir. Dans la conception du fonctionnement et des spécifications, il a fallu élargir le raisonnement à cinq établissements.

Focus

Une réinformatisation impose d'inclure, dans ses jalons de planning, les décisions de projets ou réflexions parallèles qui peuvent avoir une répercussion pour elle. Mais, si ces dernières prennent du retard, le projet doit faire des hypothèses et anticiper les conclusions les plus probables, au vu de l'avancement de ces projets parallèles.

Connaître les attentes des professionnels

12En raison de l'utilisation de quatre SIGBs au sein du SCD, et, parfois, de deux différents dans une même bibliothèque, la réinformatisation était globalement attendue par le personnel.

13En début de projet, une enquête a été lancée afin de photographier à un instant t l'état d'esprit général. Celle-ci consistait en un recueil de données quantitatives par des formulaires anonymes et un recueil de données qualitatives par quelques entretiens menés par des membres des groupes de travail du projet.

14Les questions sur la situation des collègues au sein de l'établissement, sur leurs expériences antérieures de changement, sur leur aisance avec les outils informatiques avaient pour seul but de mieux interpréter le reste de l'enquête. Toutefois, elles ont indisposé certains collègues qui n'ont pas souhaité évoquer leur ressenti des fusions antérieures.

15D'autres questions portaient sur l'accueil du projet SIGB et sur l'inquiétude qu'il pouvait générer.

16110 réponses ont été reçues, ce qui a permis de tirer les enseignements suivants :

  • les collègues étaient attachés d'abord à leur bibliothèque (55 %), ensuite seulement au SCD (40 %) et, pour 20 %, à un des anciens SCD (plusieurs réponses étant possibles, la somme dépasse 100 %) ;
  • trois-quarts d'entre eux se sentaient directement concernés par le projet car il s'agissait de leur outil de travail quotidien. À l'opposé, seuls 5 % s'en désintéressaient, soit en raison d'un départ prochain soit parce qu'ils estimaient que c'était l'affaire des groupes de travail ;
  • s’agissant de l'attitude à l'égard du projet, le projet en lui-même n'était pas source d'inquiétude : 48 % des collègues se déclaraient confiants ; pour les autres, les craintes portaient sur d'éventuelles réorganisations des services, sur la perte de spécificités lors de la mise en commun de procédures (13 %) ; inévitablement, les craintes concernaient aussi la reprise des données. Au final, la fusion des SIGB s'imposait comme nécessaire pour 79 % ; d'autres ne la pensaient pas nécessaire mais personne n'en contestait le bien-fondé ;
  • la portée du changement était jugée importante car 33 % des collègues considéraient que, bien qu'il s'agisse d'un simple changement d'outil, cela nécessitait l'harmonisation des pratiques de travail. 65 % y voyaient un changement organisationnel. Derrière ce terme se cachent deux définitions : changement de procédures, de méthodes chez les uns, changement plus profond avec modification de l'organisation générale du travail chez les autres, suscitant de nombreuses craintes ;
  • du point de vue de la réception par les collègues, la réinformatisation se plaçait donc dans un contexte très favorable, avec un a priori plutôt positif et peu ou pas d'opposition. En outre, les collègues se sentaient plutôt à l'aise avec les outils informatiques (89 %) et l'idée d'un nouveau logiciel n'était pas vue comme un obstacle, s'il était accompagné d'une bonne formation. La crainte que la réinformatisation ne soit un prétexte pour imposer des réorganisations lourdes était néanmoins présente.

Focus

Il est plus facile de gérer un projet qui démarre dans un contexte favorable et un climat où la confiance a été instaurée au préalable.

La conduite du changement : un enjeu d’importance

17Consciente de l'importance à accorder à la conduite du changement, de la nécessité de ne pas faire du changement de SIGB un projet uniquement « technique », le SCD a décidé de se faire accompagner par un cabinet de consultants.

La gestion du projet

Lier la gouvernance de projet aux circuits décisionnels

18Schématiquement, le suivi du projet strasbourgeois était organisé de manière classique avec :

  • un comité de pilotage, pour les orientations stratégiques, composé des responsables du SCD, de la direction du SI de l'université, de la BNU et des chefs de projet (informatique et fonctionnel) ;
  • une équipe projet plus opérationnelle, avec les responsables des bibliothèques partenaires, les coordinateurs des groupes de travail, les administrateurs des SIGB existants, les responsables des départements transversaux (« services aux publics », « collections » incluant les ressources électroniques) ;
  • des groupes de travail, calqués sur les modules traditionnels d'un SIGB.

19Dans le cas d'une volonté politique d'imposer un service ou une technologie entièrement innovante, il faudrait au contraire créer des groupes de travail en rupture avec l’organisation fonctionnelle existante. Dans tous les cas, il faut veiller à inscrire la participation des collègues au projet dans leur fiche de poste et à ne pas les solliciter en vain, dans la mesure où tous assument d'autres tâches.

20Une des difficultés a été le chevauchement entre les attributions des groupes de travail du projet et celles des groupes de travail « pérennes » du SCD ; il a fallu créer des passerelles entre les groupes et veiller à la cohérence des dossiers instruits.

Focus

Si l'organisation de projet est distincte du circuit de décision de l'établissement, il faut veiller à la convergence des décisions et à ne pas créer de hiatus entre les deux circuits. Une fois validées par le comité de pilotage du projet, les décisions doivent être relayées auprès de l'équipe de direction de la bibliothèque ; les points susceptibles de prêter à discussion sont à discuter au niveau de l'équipe de direction avant d'être portés devant le comité de pilotage.

Débrider l’étude des besoins des personnels

21Après l'analyse de l'existant, les groupes de travail ont procédé à l'analyse des besoins.

22La première réunion a été l'occasion d'un brainstorming, parfois par le biais de post-it, pour faire émerger des besoins nouveaux, une sorte de « lettre au père Noël ». À ce stade, aucune idée ne devait être censurée. Chaque groupe a ensuite tenu deux ou trois réunions pour filtrer, trier, ordonner les besoins.

23Une des difficultés de la formalisation des besoins est de suffisamment détailler les points importants pour l'établissement, mais de ne pas exclure d'offres, par un excès de détails. Une fois le logiciel choisi, les besoins sont affinés pour être en phase avec lui. Par exemple, dans le cas de Strasbourg, il était important que le nombre de documents empruntés puisse être limité au niveau de chaque bibliothèque mais aussi du SCD ; cette contrainte n'avait pas été énoncée lors de l'analyse des besoins mais le logiciel a pu être adapté en conséquence.

Focus

Les logiciels formatent les utilisateurs. Après des années d'utilisation, il est difficile de s'extraire de l'existant. Les besoins émis visent surtout à éviter les défauts des logiciels utilisés, sans grande prospective vers les évolutions à venir. Pour y remédier, les membres du projet doivent organiser une activité de veille. Dans ce cadre, des présentations de logiciels, à prévoir avant le lancement de l'appel d'offres, par les éditeurs ou intégrateurs, sont une aide indéniable.

Formaliser les nouveaux processus

  • 3 Un diagramme état-transition est un graphe orienté qui décrit les changements d'état d'un item à l (...)

24À l'issue de l'analyse des besoins, les processus ont été formalisés, sous forme de logigrammes, à mi-chemin entre les diagrammes des cas d'utilisation et les diagrammes états-transitions de la méthode UML3 pour Unified Modeling Language (en français, langage de modélisation unifié).

Focus

L'étape de formalisation, même si elle demande du temps, est essentielle : elle permet de vérifier la cohérence et la bonne compréhension des besoins exprimés et est utile pour la rédaction du cahier des charges.

Prévoir le plan de communication

25La rédaction d'un plan de communication est la première étape visible par tous de l'accompagnement au changement.

26Dans le cas strasbourgeois, outre l'enquête initiale auprès du personnel, ce plan prévoyait un blog de projet, des communications sur les conséquences organisationnelles, les nouveaux processus, le déroulement des tests, sous la forme de réunions décentralisées sur les différents campus.

Confier les formations logicielles aux formateurs-relais

27La formation au nouveau logiciel était prévue en trois temps : formations de l'équipe projet, en début de projet, pour aider à la compréhension des paramétrages ; formation de formateurs-relais du SCD, environ quatre mois avant la mise en production ; formation de l'ensemble des collègues par les formateurs-relais, un à deux mois avant la mise en production.

28L'idée de confier les formations de l'ensemble du personnel à des formateurs-relais (issus soit des groupes de travail du projet soit de l'équipe de formateurs du SCD) était de transmettre non seulement le savoir sur le logiciel mais la manière de l'utiliser au sein du réseau.

Focus

Faire assurer les formations par des formateurs-relais nécessite par conséquent un investissement très important de leur part mais permet de donner une formation adaptée, au plus près de la réalité du terrain. Cela facilite aussi une adoption du logiciel en deux temps : par les formateurs-relais, puis par l'ensemble des collègues. C'est ce qui a permis, malgré l'abandon d'une partie de la conduite du changement, une utilisation opérationnelle du nouvel outil.

Le redéploiement des ressources

29Lors de la mise en production, la signification et les conséquences concrètes de certaines décisions prises se sont imposées à tous. Il a été nécessaire d'expliquer à nouveau ou de rediscuter certains choix.

30Le plan de communication, établi en début de projet, n'a été mis en œuvre que dans sa partie initiale.

31Comme la durée du marché public a été plus longue que prévue, il a été décidé de modifier la répartition des missions de l'AMOA, parmi celles initialement prévues. À cela s'est ajoutée la difficulté de communiquer pendant la période du dialogue compétitif. Bien que considérée comme essentielle, la conduite du changement a été la première sacrifiée. La communication sur les nouvelles procédures, sur le déroulement des tests, du moins telle que conçue dans le plan initial, a été abandonnée. Les points d'informations thématiques n'ont pas eu lieu. Le blog n'a plus été alimenté. La communication s'est faite lors des plénières du SCD, seul moment de rassemblement de l'ensemble du personnel du SCD ou dans le cadre de la communication sur le schéma directeur du numérique. Un bilan des écarts entre le prévu et le réalisé a été établi au bout de 9 mois et doit servir de feuille de route d'amélioration de la formation/information et du logiciel.

La pression du planning

32Les chefs de projet ont été sollicités par tous les aspects du projet : le suivi du budget, de la rédaction des spécifications, de l'organisation des tests, des relations avec les établissements partenaires, des relations avec la maîtrise d'œuvre. Les aspects fonctionnels et techniques ont pris le pas sur l'accompagnement au changement.

33De manière presque intrinsèque, un responsable fonctionnel cherche à adapter les besoins exprimés au logiciel. Il est vite absorbé par les aspects fonctionnels et techniques, aux dépens des actions de conduite de changement ; en cas de retard dans certaines phases du planning, le temps prévu pour que les utilisateurs finaux prennent en main le logiciel et découvrent la version définitive des interfaces est réduit d'autant.

34Pour limiter ce risque, inhérent à tout projet, les actions de conduite du changement peuvent être prises en charge par un responsable différent des chefs de projet, avec une forte synchronisation entre tous.

35Dans le cas de Strasbourg, les processus-cibles avaient été définis mais les ajustements à faire en termes d'organisation n'avaient pas été clairement identifiés ; c'était une des missions de l'AMOA avant la nouvelle répartition de ses attributions ; ce peut aussi être le rôle d'un responsable conduite du changement.

La force de la routine

36Parmi les freins à l'adoption et la mise en œuvre du changement figure le discours négatif, voire l'action négative, de personnes en désaccord. Dans ce cas, il faut discuter, convaincre ou imposer. Mais le phénomène de routine est presque plus insidieux, parce que moins décelable. Malgré l'adoption de nouvelles règles, certains collègues pensent fonctionner comme auparavant et continuer à utiliser des règles non formalisées, propres à leur bibliothèque, parce qu'ils ont toujours procédé ainsi. Il y a de leur part une acceptation de façade des changements mais pas une adoption.

37Il s'avère donc que la validation des besoins et des processus-cibles par les groupes de travail et leur communication ne vaut pas pour autant acceptation. Pour certains collègues, ces processus étaient la description de ce que le logiciel devait pouvoir faire, sans que le processus fonctionnel ne s'impose à eux.

Focus

Il est nécessaire non seulement de faire connaître les nouvelles règles adoptées, de leur caractère contraignant ou non, mais de faire prendre conscience des changements d’habitude qu’elles induisent.

Changement ou changement ? Entre théorie et pratique

38Le changement n'est pas un concept monolithique.

39Il est au contraire parcouru de plusieurs veines qui peuvent interagir :

  • l'état du changement (nouvel état ou transition) ;
  • la mesure du changement (simple ou complexe) ;
  • la nature du changement (rupture ou progressivité) ;
  • la subjectivité du changement.

État du changement

40Le changement peut désigner la transition, période instable, pleine de paramètres inconnus, à califourchon sur l'avant et l'après ; il peut désigner uniquement la nouvelle situation.

41En général, la plus grande attention est portée à la situation nouvelle puisque c'est vers elle que tendent les processus-cibles. Pour autant, l'inquiétude des collègues porte aussi sur la transition. Elle est donc à préparer avec autant d'attention, avec les différents responsables concernés.

Mesure du changement

42Plusieurs niveaux de changement sont à distinguer :

  • le changement mineur, simple techniquement et relationnellement : ce peut être le fait de pouvoir décider, lors du catalogage dans le Sudoc (pour Système universitaire de documentation) si la notice d'exemplaire est importée ou non, mise à jour ou non dans la base locale ; ce peut être la demande et délivrance en ligne du quitus… ;
  • le changement complexe techniquement, peu sujet à des problèmes relationnels : à Strasbourg, c'est le cas de l'import des dossiers lecteurs depuis le système d'information de l'université et l'identification sur le portail avec Shibboleth4. Pour les informaticiens, que ce soit du côté du fournisseur, de l'université ou des établissements partenaires, cela a demandé un travail très important, parmi lequel la mise en œuvre de services web, la configuration d'une relation d'approbation entre annuaires, la mise en place d'un IDP (pour Identity Provider, en français, fournisseur d'identité) par établissement. Pour les bibliothécaires, ce travail est passé quasiment inaperçu. Leur principale inquiétude, à juste titre, concernait la qualité des données envoyées par l'université et les établissements partenaires ;
  • le changement simple techniquement et relationnellement (ou politiquement) complexe : le choix de l'identité graphique d'une application mobile pour l'ensemble des établissements partenaires a retardé la mise en place de ce nouveau service car une telle identité n'existait pas et devait être définie ;
  • le changement complexe techniquement et relationnellement.

Nature du changement

43Le changement peut s'opérer sous forme de rupture ou de progressivité.

44Strasbourg a choisi la méthode d'une amélioration progressive. La réinformatisation a permis d'introduire un certain nombre de changements, qui doivent d'abord être consolidés et pérennisés mais la dynamique doit être poursuivie par l'amélioration progressive et l'introduction de nouveaux services, comme par exemple la mise en place d'un outil de découverte*.

45Or, d'autres projets peuvent se faire dans une perspective de changement-rupture : combinaison sans transitions de changements de procédures, de locaux, d'organigrammes, en plus du logiciel.

Subjectivité du changement

46Il faut tenir compte du fait que la notion de changement est subjective : pour certains une nouvelle interface est un changement plus grand qu'une modification des règles de fonctionnement du prêt de la bibliothèque ; pour d'autres, c'est l'inverse.

47Dans le présent projet, la typologie des changements aurait dû être poussée davantage. Une telle catégorisation permet en effet de définir les actions à mettre en œuvre pour atteindre le changement souhaité et sur quel aspect porter l'effort (action technique, pédagogique, etc.).

48Les questionnements de Strasbourg se retrouvent dans la plupart des projets : malgré la formalisation des différentes étapes et aspects du projet, comment maîtriser les écarts entre ce qui a été formalisé et ce qui est fait ? Comment ne pas sacrifier la conduite du changement ?

49À l'issue de ce parcours, quelques réflexions s'imposent :

  • le projet doit être en mesure d'absorber les modifications organisationnelles de son environnement (changements d'organigrammes, changements de collègues, vacances de postes, changement du périmètre du projet, etc.) ;
  • les plus grandes difficultés ne sont pas forcément celles prévues. Par exemple, dans le cas de Strasbourg, l'harmonisation des règles de prêt a été définie de manière rapide et assez consensuelle alors que cela semblait auparavant être une grande difficulté. À l'inverse, d'autres sujets apparaissent conflictuels, de manière imprévue : par exemple, le niveau de codage de la carte documentaire (au niveau de la notice bibliographique ? De l'exemplaire ?) ;
  • le changement est accepté, si globalement le ratio avantages/contraintes est positif : par exemple, on accepte le catalogage (ou modification) de l'exemplaire dans le Sudoc, si la création ou la mise à jour est répercutée dans le système local ; ou bien l'utilisation du module des acquisitions si les commandes sont importées et gérées automatiquement via Electronic Data Interchange (EDI, en français échange de données informatisées) ;
  • la vision des changements doit être claire et partagée, portée par les dirigeants, assimilée par les utilisateurs : ne sont pérennisés comme changements que ceux qui sont à l’intersection des intérêts du plus grand nombre, les plus largement partagés. Le rôle du directeur du projet, ou du sponsor politique, est primordial car c'est lui qui légitime les grands objectifs ainsi que les conséquences concrètes qui en découlent. C'est lui qui donne sa feuille de route à l'équipe projet et contrôle la coordination entre les chefs de projet.

50La conduite du changement est un aspect à part entière de tout projet. Il faut prévoir que la tentation de l’abandonner puisse surgir à la première difficulté, et trouver les mesures à prendre pour qu'elle ne le soit pas.

Notes

1 Les logiciels Sebina OpenLibrary (SIGB) et SebinaYOU (portail documentaire) ont été mis en place par les sociétés Data Management P. A. Solutions (éditeur) et Decalog en janvier 2015.

2 Profil graphique du SCD de l'université : < https//bu.unistra.fr >.

3 Un diagramme état-transition est un graphe orienté qui décrit les changements d'état d'un item à la suite d'un événement. Exemple : le retour d'un livre réservé génère une modification de l'état de la réservation.

4 Shibboleth est un mécanisme de propagation d'identité : l'identification se fait auprès de l'établissement de rattachement, selon ses règles ; ensuite, Shibboleth transmet soit l'identifiant de la personne soit le seul fait de son appartenance à l'établissement.

Auteur

Responsable du département du système d’information documentaire, SCD, université de Strasbourg jusqu’au 31 août 2016 ; directrice de la bibliothèque municipale classée de Mulhouse depuis le 1er septembre 2016.

© Presses de l’enssib, 2017

Conditions d’utilisation : http://www.openedition.org/6540

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search