À la différence de ceux d’André Gide, et même ceux d’un célèbre Palmipède, les interviews de Noria n’ont rien d’imaginaire. Cette semaine, c’est un des chefs projet SGB, chargé en particulier du volet Alma, Régis Griesser, qui se met à table.
L’interview a été réalisée par Thierry Guslevic le 17 janvier dernier.
Hormis toi, Régis, qui d’autre à la BIU travaille sur la migration des données?
Voyons…Surtout, n’oublier personne ! Sonia Dumortier… Nathalie Font-Gravier…Anne-Laure Mennessier…Isabelle Oms…Céline Paillaret… Florence Chaudoreille… Virginie Le Garff et Laure Franceschi.
En ce début d’année 2018, où en est le programme de migration des données dans le calendrier du projet ?
Il est parfaitement dans les clous. Le seul souci, c’est que la migration se déroule en 2 temps : d’abord, une migration de test, et une seule, pour laquelle on a indiqué et validé un certain nombre de choses dans un formulaire (codes de bibliothèques, localisations, statuts de traitements, de prêts, de lecteurs, etc.), qui a eu lieu le 26 octobre, et qu’on peut qualifier de globalement réussie, même si certains points peuvent laisser à désirer. ![]()
Quant à la migration définitive, qui inclut les corrections qu’on aura pu apporter depuis la phase de migration de test, elle interviendra en avril prochain.
Doit-on comprendre qu’entre octobre et avril, l’équipe se reposera sur ses lauriers ?
Pas vraiment… Il nous faut dans cet intervalle procéder à une vérification minutieuse de toutes les données de la migration, et préparer les spécifications pour rectifier ce qui a, ou aura, échoué.
Pour un profane, cela s’apparente à un vrai travail de bénédictin !
En effet, c’est un travail qui exige rigueur, méthode et précision. On compare des ensembles de données, en termes de quantités, entre Aleph et Alma : nombre de lecteurs, ![]()
de notices biblio, de localisations, etc. Cette vérification quantitative doit nous faire retomber sur nos pieds, sans marge d’erreur. En fait, la méthode est simple : on aspire les données dans Aleph, et on réinjecte le tout dans Alma. Avoir affaire au même fournisseur – ExLibris – pour Aleph et Alma est a priori une garantie de savoir-faire. Après quoi, on met en œuvre un autre processus de vérification, cette fois au niveau qualitatif : si l’on constate des écarts quantitatifs sur un bloc de données migrées, on va aller dans l’échantillonnage pour identifier la raison de cette non-concordance. Au bout du compte, on finit par retrouver tout ce qui devait l’être, exception faite des notices de ressources électroniques.
Pourquoi cette singularité ?
Parce que, pour les ressources électroniques, un traitement particulier a été opéré avec le fichier P2E (« physical to electronic »), avant traitement spécifique dans Alma, consistant à générer des inventaires électroniques pour ces ressources. Il nous a été demandé de compléter un fichier d’activation des ressources, en cochant le nombre de bouquets présents dans la « base communautaire », sorte de gros réservoir Alma. Résultat : des doublons, ou bien des notices rejetées au profit des notices de la zone communautaire. Pour les revues électroniques, on n’a pu reprendre que 102 notices : plus de 100 000 notices Aleph ont ainsi été rejetées lors de la migration vers Alma. La faute probablement au fichier d’activation, qui fait référence à des notices bibliographiques issues de la base communautaire, au format MARC 21, et pas en UNIMARC, comme les nôtres. C’est en tout cas notre analyse. De son coté, Ex Libris continue la sienne, sans que les deux soient d’ailleurs forcément divergentes. L’information est toute fraîche, elle date de ce jeudi 17 janvier [date de l’interview].
Comment la migration s’articule-t-elle avec les autres phases du projet ?
Tout se fait en même temps. Pendant qu’on vérifie la migration, les autres missions font leurs propres tests. Les équipes doivent être au diapason : si l’on rencontre un problème dans un des processus, les incidences sur le travail des autres groupes sont inévitables, et l’ensemble du projet peut s’en trouver ralenti. Prenons un exemple, celui des cotes. Dans l’OPAC d’Aleph les champs cote 1 (cote magasin) et cote 2 (cote libre-accès) sont alternativement affichés en fonction de la localisation. Dans Alma, il n’y a qu’une cote principale, utilisée dans Primo pour l’affichage bref de l’exemplaire (bibliothèque –> localisation –> cote). Le processus de migration imposé par Ex Libris est relativement rudimentaire : il a fallu choisir un seul des deux champs pour tous les exemplaires, indépendamment de la localisation. C’est la cote 1 qui a été choisie au détriment de la cote de libre-accès, ce qui engendre des problèmes d’affichage, notamment pour le choix des exemplaires dans le cadre du prêt indifférencié et des réservations. À partir de là, la Mission services aux publics a objecté, avec raison, que ses tests ne pouvaient pas continuer à se faire correctement. Il en va de même pour la Mission collections qui doit vérifier que les ressources électroniques ont été correctement migrées, or ce type de problème les impacte directement. Voilà un exemple de l’interdépendance des processus de travail, et de l’effet domino en cas d’anomalies dans la migration des données.
Y a-t-il eu une difficulté, plus importante que les autres, qui pourrait mettre en péril le projet, ou du moins le retarder significativement ?
Un problème a été pointé par la direction, et transmis à Ex Libris dans une lettre de saisine : la configuration initiale, telle qu’elle a été consignée dans les différents formulaires et les work books Primo – il va falloir se mettre au franglais ! – n’a pas été implémentée de la façon dont elle aurait dû l’être, c’est-à-dire de A à Z, à la livraison des environnements de production.
Un « simple oubli » de la part du fournisseur ?
Réponse d’Ex Libris : ils ont livré les environnements, mais il s’agit d’un processus de configuration itératif, qui s’opère par échanges et allers-retours réguliers entre Ex Libris et l’établissement. De leur point de vue, il n’y a là rien de plus qu’une légère incompréhension, mais qui aura au final généré pas mal de tickets pour corriger les défauts !
On peut être raisonnablement optimiste, et se dire que les choses vont finir par rentrer dans l’ordre ?
C’est-à-dire qu’à la fin, il y aura une VA (vérification d’aptitude) et une VSR (vérification de service régulier) qui seront prononcées : si le service ne peut être lancé en l’état, alors l’établissement pourra remettre en cause le contrat. C’est une possibilité…
N’existe-t-il pas des moyens, en amont, pour corriger ces biais, avant d’en arriver à de telles extrémités ?
Si, justement, les experts qui travaillent sur Alma et Primo ne manquent pas de nous signaler tous les bugs et les problèmes qu’ils peuvent rencontrer. Ensuite, il appartient au fournisseur d’être réactif et de proposer des solutions.![]()
Est-ce à dire que les experts BIU – membres des GT et missions – sont, en quelque sorte, des lanceurs d’alertes ?
D’une certaine façon, oui…On en est aujourd’hui à quelque 90 tickets sur Alma et surtout Primo, d’importance inégale : ça va de la simple coquille ou faute d’orthographe dans un libellé, jusqu’à un problème de migration sur cent milliers de notices !
Y avait-il un risque, ou une crainte forte, avant la mise en œuvre du projet ?
Peut-être une crainte, à titre personnel… Lors des auditions, il n’avait échappé à personne qu’on allait se retrouver avec des systèmes relativement rigides, en termes de personnalisation et de paramétrages, avec certaines choses qui ne seraient absolument pas modifiables. Ensuite, entrent en considération des questions complexes d’arbitrage dans la structure des offres, entre la partie technique et la partie tarifaire.
Mais, si certains points ne sont pas paramétrables, cela n’équivaut-il pas à baisser le niveau de nos exigences propres ?
Voyons plutôt les choses, non pas comme une régression, mais plutôt comme un changement de pratiques. Par exemple, on ne pourra pas exporter dans les notices de commandes les noms ou initiales des acquéreurs, comme dans Aleph. Impossible de rectifier via un ticket : il faudra s’adapter. De façon générale, ce n’est pas parce qu’on va passer à Alma qu’on va « débrancher » les serveurs Aleph et BO. On pourra toujours les interroger, en cas de besoin. Il existe des solutions techniques proposées par Exlibris, tel un export sous forme de fichier CSV (un format tabulé lisible par Excel) à partir d’Aleph pour récupérer des données non migrées, comme l’historique de prêts, pour prendre un exemple concret, utilisé à des fins statistiques. Il existe aussi des solutions de contournement : faire des exports dans Analytics et traiter ces exports dans BO, où l’on peut bâtir des requêtes à partir de deux univers différents.
S’il fallait retenir une ambition du volet « migration », quelle serait-elle ?
Faire en sorte que tout le monde soit satisfait au final, et puisse travailler avec sérénité, et une efficacité augmentée. Ce n’est pas seulement de la langue de bois ! La problématique de la migration est au cœur du projet, c’est même l’une des conditions-clés de sa réussite.
Existe-t-il une recette pour une migration idéale ?
![]()
(Rires.) Non, on n’a pas trouvé de cahier de recettes* tout fait ! Il faut juste faire confiance à l’expérience et au bon goût du cuisinier et de son équipe, faire en sorte que ça n’attache pas…
Pour paraphraser un autre hebdomadaire bien connu de nos lecteurs, y a-t-il des questions auxquelles tu aurais échappé ?
(Un silence.) Non…Mais si tu veux parler d’une question que j’aurais aimé que tu me poses…
Euh…Laquelle ? (Ma parole, c’est l’arroseur arrosé !)
Tous les personnels de la BIU sont-ils bien conscients de l’importance du projet, et de l’investissement des équipes qui en sont partie prenante ?
Communiquer sur le projet SGBM tout au long de son déroulement, tel est précisément l’objet de Noria. Quant à savoir si nos collègues dévorent nos articles à belles dents …
À suivre, donc.
Un grand merci à Régis pour s’être soumis au feu roulant de nos questions.
*En informatique, le terme « recette » désigne l’ensemble des pratiques de test d’un produit pour en vérifier la conformité, en particulier une implémentation correcte des fonctionnalités validées en amont dans le cahier des charges, afin d’assurer la qualité des données de façon pérenne, éviter les problèmes de montée en charge, etc.
![]()
