Migration vers un nouveau logiciel

[Luciole56]

Bonjour,

 

La bibliothèque où je travaille est informatisée depuis 2008. Lors de la commande du logiciel, la mairie a opté pour un hébergement des données chez le fournisseur. Prochainement la bibliothèque va intégrer le réseau des bibliothèques de la Communauté de Communes à laquelle est rattachée la commune. Les bibliothèques de cette CC fonctionnent avec un logiciel concurrent et la CC prend à sa charge l'installation du logiciel dans les bibliothèques intégrant le réseau.

 

J'ai donc fait une demande auprès de notre fournisseur actuel afin de récupérer une copie de sauvegarde des données pour les communiquer au futur fournisseur en vue de la migration des données. Cette dernière est retardée car le founrisseur actuel m'a informée qu'il s'agit d'une exportation des données (ce qui n'est pas ma demande) et que cette prestation  a un coût (élevé et pas budgétisé). Je leur ai réexpliqué que j'avais uniquement besoin d'une copie de la sauvegarde mais rien à faire...

 

Ce fournisseur est-il dans son bon droit ? et si non quels sont les recours possibles ?

 

Je remercie d'avance les personnes qui pourront m'apporter leur aide et conseil.

 

Luciole56

 

 

[symac]

Il est très important lors de la rédaction d'un cahier des charges, a fortiori lors de l'acquisition d'un outil dans les nuages, de prévoir les modalités de récupération de la base. Sans cela, on reste tributaire du bon vouloir du prestataire, qui dans le cas d'un marché perdu aura bien évidemment tendance à laisser traîner les choses ou à proposer un tarif exhorbitant (vu parfois des devis de plusieurs milliers d'euros pour un simple export).

 

Si votre fournisseur actuelle est signataire de la charte FULBI vous pouvez éventuellement le lui rappeler : http://www3.fulbi.fr

 

Je ne suis pas juriste et ne sais pas quel recours vous avez si le prestataire se refuse à vous fournir les données, à part lui faire une bonne pub dans le milieu bibliothécaire (pas forcément publiquement sur le forum mais via le bouche à oreilles évidemment).

 

Désolé pour cette non réponse, en espérant que ces quelques pistes puissent vous aider.

[Isalabib]

le founrisseur actuel m'a informée qu'il s'agit d'une exportation des données (ce qui n'est pas ma demande) et que cette prestation  a un coût (élevé et pas budgétisé). Je leur ai réexpliqué que j'avais uniquement besoin d'une copie de la sauvegarde mais rien à faire...

 

On ne fait pas à ma connaissance une migration de données en donnant juste une copie de sauvegarde au nouveau prestataire...

Votre demande correspond en fait à un export de données, et vous devriez vérifier dans le cahier des charges de 2008 ce qui était dit à ce sujet.

 

Si les conditions de récupération de vos données n'y sont pas précisées, le prestataire peut effectivement faire traîner et/ou vous facturer à sa guise.

 

La CC a-t-elle pris en compte cette question ? le coût des imports dans le nouveau logiciel est peut-être prévu ? d'autres bibliothèques sont-elles dans votre cas ?...

 

Avant de revenir vers votre fournisseur, vérifiez ces différents points.

La lecture de la charte FULBI devrait vous être d'une aide préciseuse.

[cromagnon]

Situation délicate si rien n'est prévu. Vous avez votre réponse dans l'article 1 :

 

 

Le fournisseur courant s’engage :

 à mettre à la disposition de l’établissement documentaire client, sur simple demande, et à titre gratuit ou selon un tarif fourni, l’ensemble des données demandées par lui dans un format documenté non crypté,

[Thierry Clavel]

voici la liste des 20 fournisseurs qui ont signé la charte des bonnes pratiques http://www3.fulbi.fr/?q=node/8

[Ferris]

J'ai vécu la migration à deux reprises. Les fournisseurs se tirent dans les pattes un maximum à ce niveau et nous sommes perdants à chaque fois. Pas de copie de sauvegarde qui tienne. Le nouveau prestataire doit aller chercher, extraire, des données dans les champs de l'ancien, lequel rechigne à laisser voir ses secrets de fabrication si l'on peu dire. Or il y a toujours des champs qui restent inaccessibles parce que non codifiés de la bonne façon, du point de vue du nouveau prestataire.

 

En plus tu es dans la mème situation que nous à l'époque : une bibliothèque doit migrer pour intégrer le systeme dominant du réseau de la CC; Autrement dit, tu es minoritaire et ne comptes pas trop sur le soutien des collègues trop heureux de s'en tirer à bon compte.

 

Nous, on a perdu dans la zone exemplaire les noms des fournisseurs et les prix par exemple, "parce que ces champs n'étaient pas récupérables" par le nouveau prestataire, soi-disant.

 

Un truc qui n'a l'air de rien mais qui pèse lourd ensuite quand tu veux te lancer dans un désherbage normalisé, c'est que tu perds systématiquement l'historique des prêts. Et quand tu vis 2 fois la migration sur un mème fonds, il devient impossible d'avoir une vision suffisante des taux de sortie de tel ou tel segment du fonds. Impossible par exemple dès la première année de calculer ton taux de rotation. Si tu peux conserver ces données sur ton vieux logiciel non hébergé, ça peut améliorer les choses mais il faudra que tu joues sur les deux tableaux pour additionner les prêts par exemple. Nous, on l'a fait une fois, la migration ayant eu lieu au mois de mai. Et çà nous a permis d'avoir des stats à peu près correctes en fin d'année. Mais je ne te dis pas le boulot !

 

Par contre on a eu d'autres pertes non récupérables au niveau des actifs, et on n'a pas pu donner notre nombre d'actifs à la DLL cette année là. (Impossible en effet d'additionner les actifs arrêtés en mai sur l'ancien avec les actifs répertoriés sur le nouveau à partir de juin, puisque par définition un actif n'est compté qu'une fois dans l'année quel que soit le nombre de passages et d'emprunts qu'il a effectués). La-dessus tu peux faire une croix.

 

Essaies aussi de négocier la date de migration, de préférence en début d'année, après tes stats de janvier. Ca limitera la casse. Fais attention aussi à tout ce que tu as pu mettre dans les champs 900 de tes notices : si tu peux avoir la garantie qu'ils seront conservés au mème endroit c'est OK, sinon il n'est pas trop tard, avant la migration, pour demander à ton fournisseurs actuel de les faire migrer sur un autre champ avant la migration. Il faut absolument faire et exiger des réunions préparatoires pour se faire préciser les choses et ne pas hésiter, champ par champ , à avoir des garanties. Ne pas laisser les deux prestataires s'arranger entre eux en étant exclus du débat.

 

Ah, tant que j'y penses, encore un truc à vérifier : Certaines zones qui étaient interrogeables sur ton ancien SIGB ne le seront pas forcément dans le nouveau, ne pourront pas servir de filtres ou de critères de classement pour tes editions ou tes stats. Et je ne parle pas de l'opac, c'est un autre sujet. Nous, par exemple, on nous a dit de placer nos genres locaux en champ 902; On a fait faire le transfert avant la migration. Résultat, depuis on les a mais on ne peut plus les utiliser dans une edition comme critère, tout juste les faire apparaître à l'affichage.

 

Bon, j'arrête la liste, parce que je sens que tu as le moral dans les chaussettes...

 

Tant qu'on restera esclaves de ces systèmes propriétaires, ce sera pareil. (Vive le logiciel libre). Et bon courage, c'est une sacrée épreuve !

[Moody]

Edite tes stats avant la date fatidique si tu ne peux pas la caler quand tu veux.

Si tu as du désherbage à faire c'est le moment, idem pour le ménage dans la base abonnés si ça n'a pas été fait régulièrement.

Ainsi si tu dois retravailler sur tes données après la migration, la quantité sera moindre.

Est-ce que quelqu'un à la CC est référent sur ce dossier ? Il / Elle peut probablement t'aider. Voir avec cette personne les particularités de tes notices et exemplaires.

Après tu es informatisée depuis 2008, peut être que vous avez eu la bonne idée de faire de la récupération BNF toute simple et de ne pas "personnaliser" les notices, auquel cas ça va simplifier les choses !

Si par contre tu as des spécificités, tu as peut être aussi moyen d'exporter ton fonds dans un tableur pour garder une trace d'éléments qui pourraient disparaître.

[Ferris]

supprimé

 

Modifié le 3 août 2019 par Ferris

[Invité DamienR]

Je viens de relire la charte de la Fulbi : elle ne couvre pas que les notices bibliographiques du Sigb. Par exemple elle prend en compte les autorités, la base emprunteurs, les prêts en cours, les rappels... Je ne vois pas de mention des statistiques.

 

Et pour compléter le message ci-dessus :

Situation délicate si rien n'est prévu. Vous avez votre réponse dans l'article 1 :

 

 

Le fournisseur courant s’engage :

 à mettre à la disposition de l’établissement documentaire client, sur simple demande, et à titre gratuit ou selon un tarif fourni, l’ensemble des données demandées par lui dans un format documenté non crypté,

 

"ou à lui fournir les outils et la documentation lui permettant d’extraire lui-même l’ensemble de ces données."

[Ferris]

supprimé

 

Modifié le 3 août 2019 par Ferris

[lucas]

J'ai vécu la migration à deux reprises. Les fournisseurs se tirent dans les pattes un maximum à ce niveau et nous sommes perdants à chaque fois. Pas de copie de sauvegarde qui tienne. Le nouveau prestataire doit aller chercher, extraire, des données dans les champs de l'ancien, lequel rechigne à laisser voir ses secrets de fabrication si l'on peu dire. Or il y a toujours des champs qui restent inaccessibles parce que non codifiés de la bonne façon, du point de vue du nouveau prestataire.

 

En plus tu es dans la mème situation que nous à l'époque : une bibliothèque doit migrer pour intégrer le systeme dominant du réseau de la CC; Autrement dit, tu es minoritaire et ne comptes pas trop sur le soutien des collègues trop heureux de s'en tirer à bon compte.

 

Nous, on a perdu dans la zone exemplaire les noms des fournisseurs et les prix par exemple, "parce que ces champs n'étaient pas récupérables" par le nouveau prestataire, soi-disant.

 

Un truc qui n'a l'air de rien mais qui pèse lourd ensuite quand tu veux te lancer dans un désherbage normalisé, c'est que tu perds systématiquement l'historique des prêts. Et quand tu vis 2 fois la migration sur un mème fonds, il devient impossible d'avoir une vision suffisante des taux de sortie de tel ou tel segment du fonds. Impossible par exemple dès la première année de calculer ton taux de rotation. Si tu peux conserver ces données sur ton vieux logiciel non hébergé, ça peut améliorer les choses mais il faudra que tu joues sur les deux tableaux pour additionner les prêts par exemple. Nous, on l'a fait une fois, la migration ayant eu lieu au mois de mai. Et çà nous a permis d'avoir des stats à peu près correctes en fin d'année. Mais je ne te dis pas le boulot !

 

Par contre on a eu d'autres pertes non récupérables au niveau des actifs, et on n'a pas pu donner notre nombre d'actifs à la DLL cette année là. (Impossible en effet d'additionner les actifs arrêtés en mai sur l'ancien avec les actifs répertoriés sur le nouveau à partir de juin, puisque par définition un actif n'est compté qu'une fois dans l'année quel que soit le nombre de passages et d'emprunts qu'il a effectués). La-dessus tu peux faire une croix.

 

Essaies aussi de négocier la date de migration, de préférence en début d'année, après tes stats de janvier. Ca limitera la casse. Fais attention aussi à tout ce que tu as pu mettre dans les champs 900 de tes notices : si tu peux avoir la garantie qu'ils seront conservés au mème endroit c'est OK, sinon il n'est pas trop tard, avant la migration, pour demander à ton fournisseurs actuel de les faire migrer sur un autre champ avant la migration. Il faut absolument faire et exiger des réunions préparatoires pour se faire préciser les choses et ne pas hésiter, champ par champ , à avoir des garanties. Ne pas laisser les deux prestataires s'arranger entre eux en étant exclus du débat.

 

Ah, tant que j'y penses, encore un truc à vérifier : Certaines zones qui étaient interrogeables sur ton ancien SIGB ne le seront pas forcément dans le nouveau, ne pourront pas servir de filtres ou de critères de classement pour tes editions ou tes stats. Et je ne parle pas de l'opac, c'est un autre sujet. Nous, par exemple, on nous a dit de placer nos genres locaux en champ 902; On a fait faire le transfert avant la migration. Résultat, depuis on les a mais on ne peut plus les utiliser dans une edition comme critère, tout juste les faire apparaître à l'affichage.

 

Bon, j'arrête la liste, parce que je sens que tu as le moral dans les chaussettes...

 

Tant qu'on restera esclaves de ces systèmes propriétaires, ce sera pareil. (Vive le logiciel libre). Et bon courage, c'est une sacrée épreuve !

Bonjour, je ne suis pas tout à fait d'accord avec ton analyse, la plupart des prestataires ont une certaine expérience dans la migration de données. Tu dois bien savoir que le monde des bibliothèques surtout chez les éditeurs est tout petit, tu prends Opsys : ils ont plus de 800 références, AFI : 400; Decalog : 2200, PMB doit en avoir plusieurs centaines...

Tu crois que ces prestataires n'ont pas capitalisé quoi que ce soit ? C'est impensable.

J'ai entendu dernièrement un collègue me dire : "bah tu vois pour l'extraction des données il suffit de cliquer là et hop on récupère les notices et les exemplaires au format iso !"

Mais en creusant un peu tu constates que ce n'est pas si simple. Je prends un exemple : quand sur un SIGB on va te parler de "situation", sur le nouveau système tu n'as pas cette fonctionnalité ou plutôt tu sais qu'elle sera prise en charge par un autre paramètre comme les "abonnés fonctionnels", et bien cette fameuse prestation d'extraction de données va permettre de récupérer les documents avec leurs "situations", les emprunteurs, les abonnements voire les statistiques de l'année en cours.

Le problème avec les prestataires n'est plus dans la récupération de données car ce type de prestation ne dépasse guère les 2 000 € HT (au-delà vous vous faites avoir, car la prestation d'extraction ne dépend pas de la taille de la base).

Le problème va se poser quand vous allez choisir un portail et un OpacWeb d'une société X avec un SIGB d'une société Y, ce sont des prestations totalement injustifiées pour récupérer API et autres Web Service qui peuvent aller jusqu'à 5 000 € HT pour une base. C’est bien sur ce point que les prestataires ne jouent pas le jeu et non sur la migration ou l’extraction des données.

Quant au libre, je ne vois pas en quoi une solution dite « libre » va régler ces problèmes d’extractions de données, des solutions comme Aloès, Carthame ou VSmart sont très paramétrables et « ouvertes » et comme dit Jacques Kergomard : une solution ouverte n’est pas forcément une solution Open Source.

Modifié le 21 mai 2013 par lucas

[DigéRidou]

Jolie analyse Lucas, tout à fait d'accord. Je pense que la Fulbi n'a pas pu aller assez loin malgré toute sa bonne volonté pour moraliser ces questions de données. En fait il faut tout d'abord bien accepter l'idée que chaque structure est propriétaire de son catalogue. De manière objective chaque structure devrait pouvoir obtenir de son fournisseur SIGB qu'il réalise un dump de la base (si celle-ci est hébergée par l'éditeur) sans aucun coût associé. Le nouvel éditeur retenu, s'il est sérieux, est capable (et préfère!) partir de données brutes et des tables de l'éditeur précédent que de s'appuyer sur des exports de fait toujours médiocre. Lucas donne des exemples parfaitement judicieux sur des points qui qualifient de manière utile le fonds et ne sont pas prévus en Unimarc.

 

Dans cette hypothèse le fait de facturer quelquechose devrait être perçu comme une "taxe au départ", on peut estimer que poser une base sur un serveur FTP ne coute pas très cher. 

 

J'ai vu fleurir nombre de réponses de fournisseurs précisant en petit "sous réserve de founiture des fichiers en Unimarc" et vu des bibliothèques étranglées par un export Unimarc facturé 10 KE. Et un export Ascii des lecteurs avec abandon des prêts en cours, on rêve.

 

Ce que je suggèrerais bien à la fulbi c'est de qualifier 2 prestations génériques, objectives et parfaitement cadrées correspondant à des éléments vérifiables car valorisés explicitement.

 

Prestation 1 - Copie physique de la base de production et mise à disposition sur site FTP - 2 itérations (phase de test / grandeur réelle) Donc sans aucun traitement.

 

Prestation 2 - Exportation de toutes les tables en ASCII / format XLS / XML et export en Unimarc du catalogue avec là encore 2 itérations (phase de test / grandeur réelle)

 

La prestation 2 n'est pas scandaleuse, même si l'essentiel des porduits récents exporte nativement en Unimarc il faut réaliser les opérations d'export des tables, prendre contact au téléphone, transmettre sur FTP. Ce n'est pas monstrueux mais il n'est pas illégitime de facture 0.5 à 1 journée pour chaque itération.

 

Mais attention ! Dites vous bien aussi que l'éditeur qui vous a proposé une nouvelle solution connait parfaitement les pratiques commerciales de celui qu'il remplace ! Il a donc un devoir d'information et mettre "sous réserve..." est un peu court avec une ch'tite logique du monde des contrats d'assurance ou licences utilisateurs Windows...

 

En final on voit bien là que l'on est sur des valeurs relativement modestes en équivalent nombre de jours. Après si certains éditeurs préfèrent une politique de terre brulée libre à eux, mais il vaut mieux laisser partir un site utilisateur avec élégance car il reviendra peut être, ou son personnel ira dans une autre médiathèque. On est un tout petit monde...

 

Et pour ceux qui disent que c'est simple, un seul clic etc. qu'ils se fassent connaître...

Modifié le 15 mai 2013 par DigéRidou

[Ferris]

@ Lucas. Je ne suis pas un spécialiste de tous ces aspects, comme beaucoup d'entre nous. Je donnais simplement un retour d'expérience sur des trucs vécus, et non une "analyse", et sur les problèmes de pertes que j'ai pu connaître personnellement, et qui sont des aspects sur lesquels je serais plutôt méfiant la prochaine fois, c'est tout. Et tu en ajoutes d'ailleurs à ma liste avec les exports de  réservations, données lecteurs, localisation  etc..

 

 

 

 

 

 

Modifié le 3 août 2019 par Ferris

[zibook]

Nous sommes actuellement en phase de choix du nouveau SIGB avec un calendrier trop court à mon avis mais c'est ma première réinformatisation .

Les fournisseurs proposent à peu près tous la même chose pour les fonctions de base mais ce qui m'inquiète c'est la migration des données: un des fournisseurs est très précis sur la méthodologie avec un calendrier qui dépasse nos prévisions.et les autres plus succincts mais dans les cordes.

Nous avons prévu 1 mois pour la migration des données et  la formation au nouveau logiciel et mise en place de l'opac-portail.

(20000 documents-1800 inscrits)

 

Ce délai est-t-il raisonnable ?

 

P.S ça me rappelle Biblio.fr ce genre de question

 

.

 

[B. Majour]

Bonjour 

 

Tout dépend.

 

Si le fournisseur est capable de transférer sans problème les données ou pas. (= le logiciel est-il classique ou pas sur le marché ?)

Donc, s'il a déjà réalisé cette migration du logiciel actuel vers le sien.

Si oui, avec quelle bibliothèque. Un petit coup de fil permet de s'en assurer et de leur demander le temps mis.

 

 

Pour la formation, ça ne doit pas prendre plus d'une semaine pour les fonctions de base.

Le reste, ce sera en cours de route.   Comme d'habitude.

 

Et la mise en place de l'Opac, une fois les données transférées et disponibles, ça ne devrait pas prendre plus de temps qu'une mise en place standard. Si le réseau est bien configuré à la base, que les postes sont compatibles avec le logiciel Opac, c'est l'affaire d'un à deux jours maximum.

 

Si tout se passe bien, avec une équipe rôdée, un mois, c'est raisonnable.

 

Après, bien sûr, ce sera à l'équipe bibliothécaire de se mettre en phase et d'assurer la bonne marche du logiciel.

Et surtout les différents petits problèmes classiques : Opac qui ne démarre pas, fonction que l'on ne retrouve pas, etc.

 

Là, un mois, c'est court. Puisque, en réalité, ce sera plutôt dans les quinze jours, le temps de se former et de pouvoir travailler sur le nouveau logiciel, sans public si possible.

 

La bonne idée, ici, c'est de faire une liste de toutes les tâches réalisées avec le logiciel actuel, afin de les "valider" en formation.

 

Attention aussi au type de machine requis par le nouveau logiciel. S'il faut passer à Windows 7 ou 8, voire à Linux, ce n'est pas juste le logiciel pour lequel il faut se former, mais aussi tout l'environnement. Des fois on l'oublie un peu vite.

 

Bien cordialement

  B. Majour

[Ferris]

Déja pas mal de réponses (et de questions) la-dessus en premières pages de cette rubrique, delais, pertes de données, cahiers des charges etc... (http://www.agorabib.fr/index.php/topic/199-migration-vers-un-nouveau-logiciel/?hl=migration

[zibook]

merci d'éclairer ma lanterne car certains fournisseurs sont très clairs dans leur procédure (sur le papier mais y a pas de raison de ne pas y croire)

alors que d'autres sont plus flous.

[Ferris]

Si c'est ta première, n'hésite pas à pomper.

 

 

Pour la partie Opac et interface, à partir de la page 11, celui-ci est très bien http://www.bds.cg72.fr/iso_upload/cahier_des_charges_isgb.pdf

 

 

 

Pour la reprise de données, de la page 11 à 13, celui-ci n'est pas mal non plus :http://www.cc-nozay.fr/IMG/pdf_Cahier_des_charges_logiciel_bibliotheques.pdf

 

 

 

 

 

 

 

Modifié le 3 août 2019 par Ferris