Migration vers Koha : méthode, formats d'export et délais selon votre système

Ce que l'on migre exactement

Une migration complète déplace cinq ensembles de données distincts, chacun avec son format et sa difficulté. Les confondre est la première erreur de planification : beaucoup de projets chiffrent « la migration du catalogue » en pensant aux seules notices bibliographiques, puis découvrent qu'il manque les exemplaires.

• Notices bibliographiques : la description de chaque œuvre, qui voyage en MARC (ISO 2709) ou en MARCXML.
• Exemplaires : chaque copie physique, avec son code-barres, sa cote, son site, sa collection et son statut. Dans Koha, ces données vivent dans le champ 952 en MARC21 et dans la zone 995 en UNIMARC.
• Autorités : auteurs, sujets et collectivités normalisés, migrés comme notices d'autorité distinctes.
• Lecteurs : le fichier des usagers, avec catégorie, site, date d'expiration et coordonnées.
• Circulation : prêts en cours, réservations, amendes et historique. C'est l'ensemble qu'on décide le plus souvent de ne pas migrer en entier.

S'y ajoute le paramétrage, qui ne se migre pas mais se reconstruit : types de documents, catégories de lecteurs, règles de prêt, calendriers de fermeture, sites et valeurs autorisées. Dans un réseau de trois sites, cette reconstruction peut durer aussi longtemps que le chargement des données. Elle relève de la mise en œuvre de Koha au sens large.

Étape 1 : l'inventaire du système d'origine

Avant d'exporter quoi que ce soit, il faut documenter le point de départ. Un inventaire utile répond à sept questions et se boucle en une ou deux séances avec l'équipe de la bibliothèque et le service informatique :

1. Le nom et la version exacte du système actuel, et si son éditeur le maintient encore.
2. Le nombre de notices bibliographiques, d'exemplaires et de lecteurs actifs. Ce n'est pas le même chiffre : 16 620 notices peuvent représenter plus de 22 000 exemplaires.
3. Le format de description : MARC21, UNIMARC, un format propriétaire ou des champs épars dans une base de données.
4. L'accès direct à la base de données (MySQL, SQL Server, ISIS) ou seulement à l'interface d'export.
5. Le jeu de caractères : UTF-8, MARC-8, ISO 8859-1. C'est la première cause d'accents cassés après le chargement.
6. Le sort des prêts en cours et des amendes impayées le jour de la bascule.
7. Les fichiers joints : couvertures, PDF en texte intégral, liens vers des ressources électroniques.

Format d'export selon le système d'origine

La difficulté d'une migration se joue dans ce tableau. Les systèmes qui exportent un ISO 2709 propre migrent vite ; ceux dont les données ne sont accessibles que par la base exigent un travail d'extraction préalable qui peut doubler le calendrier.

Les migrations depuis d'autres systèmes commerciaux ou libres, comme Symphony ou ABCD, suivent la même logique : tout dépend de ce que le système sait exporter. Koha accepte deux formats d'entrée pour les notices bibliographiques et d'autorité : le MARC binaire (ISO 2709, fichiers .mrc) et le MARCXML. Tout le reste (CSV, XLSX, JSON, dump SQL) doit être converti avant. Les lecteurs font exception : ils se chargent avec un fichier CSV propre à Koha, par l'outil d'import des lecteurs.

UNIMARC ou MARC21 : la question propre aux catalogues francophones

La plupart des guides de migration raisonnent en MARC21. Pour un catalogue francophone, la première décision est ailleurs : garder l'UNIMARC ou passer au MARC21. Koha gère les deux, mais le format se fixe à l'installation et le manuel de Koha est clair : changer ensuite ce réglage ne convertit pas les notices.

• Garder l'UNIMARC évite toute conversion de format. C'est le choix naturel en France, où le manuel de Koha situe ce format comme standard, et il assure la continuité avec les notices de la BnF, livrées en UNIMARC par son serveur Z39.50 et son API SRU, ouverts à tous sans authentification.
• Passer au MARC21 se justifie pour s'aligner sur un réseau qui travaille dans ce format, comme c'est le cas au Canada. La conversion est une étape bien connue, mais elle exige de revoir avec soin les points d'accès et les notes, qui n'ont pas d'équivalence un pour un.
• Pour un établissement du réseau Sudoc, le paramétrage des transferts réguliers de l'Abes doit figurer dans le plan de bascule : l'Abes demande aux fournisseurs de SGB de respecter ses recommandations pour ces échanges de données.

La correspondance des champs

La table de correspondance relie chaque champ de l'ancien système à sa zone MARC dans Koha. Elle se construit une fois, se documente et s'applique à tout le lot. Quatre décisions doivent toujours être explicites :

• Le type de document au niveau de la notice (942$c en MARC21) : il détermine le comportement de la notice en circulation et dans les facettes de l'OPAC.
• Le champ d'exemplaire (952 en MARC21, 995 en UNIMARC) : au minimum le site de rattachement, le site actuel et le type d'exemplaire ; en pratique, on charge aussi le code-barres, la cote, la collection et la date d'acquisition.
• Les champs de contrôle : 001, 003 et l'identifiant interne. Si l'ancien système avait son propre numéro de contrôle, conservez-le dans un champ local pour pouvoir auditer la migration.
• L'encodage des caractères : décidé au départ et vérifié sur le premier lot test. Corriger les accents de 20 000 notices déjà chargées coûte plus cher que refaire la conversion.

Une erreur fréquente dans les migrations depuis un tableur consiste à charger tout le titre dans un seul sous-champ, sans séparer le complément du titre ni la mention de responsabilité (245$a, $b et $c en MARC21 ; 200$a, $e et $f en UNIMARC). Le catalogue se charge et s'affiche correctement, puis la recherche par auteur et le tri échouent. Mieux vaut le régler à la conversion qu'après.

Dédoublonnage et contrôle des autorités

Presque aucun catalogue hérité n'arrive propre. Dans les projets de nettoyage menés par BiblioLabTech sur des fonds d'environ 9 000 notices, une part qui se situe généralement entre 3 % et 10 % présente un problème : doublons exacts, doublons par variante de titre, auteurs écrits de trois façons différentes, sujets non contrôlés, ISBN mal saisis ou notices sans aucun exemplaire.

Le nettoyage se fait avant le chargement définitif, sur le fichier déjà converti, car c'est là que l'on peut appliquer des règles en masse. Koha propose en outre des règles de concordance à l'import : il peut comparer par ISBN (020$a en MARC21, 010$a en UNIMARC), par ISSN (022$a ou 011$a) ou par l'identifiant interne de Koha, puis ignorer, remplacer ou ajouter la notice entrante. Définir cette règle est indispensable quand on charge en plusieurs lots ou qu'on fusionne des sites qui partagent des titres.

Les autorités méritent une décision explicite : on les migre, on les reconstruit à partir des notices bibliographiques ou on les reporte à une seconde phase. Migrer les notices sans les autorités fonctionne, mais laisse en suspens le contrôle des points d'accès.

Exemplaires, lecteurs et circulation

Les exemplaires se chargent intégrés à leur notice, dans le 952 ou la 995, ce qui évite une deuxième passe. Si le système d'origine livre les exemplaires dans une table à part, il faut les rattacher à la notice pendant la conversion, grâce à l'identifiant commun. C'est la partie qui réserve le plus de surprises en réseau : un même titre présent sur trois campus doit finir en une seule notice bibliographique avec trois champs d'exemplaire ou plus, et non en trois notices en double.

Les lecteurs se chargent par CSV, avec le numéro de carte et le nom comme champs obligatoires, plus ceux que l'établissement a rendus obligatoires dans sa configuration. Deux avertissements pratiques : les colonnes vides écrasent par du vide les données existantes, et les mots de passe sont transmis en clair pour que Koha les convertisse en empreintes (hachage). Ce fichier contient des données personnelles au sens du RGPD : traitez-le comme une donnée sensible et supprimez-le à la fin.

Pour la circulation, la décision raisonnable est souvent la suivante : migrer les prêts en cours et les réservations actives, pas l'historique complet. L'historique justifie rarement son coût de conversion ; s'il sert aux statistiques, on peut le conserver dans un fichier à part ou le charger plus tard, une fois en production.

Chargements tests, validation et bascule

Aucune migration sérieuse ne charge directement en production. La séquence éprouvée est la suivante :

1. Lot pilote de 200 à 1 000 notices représentatives : livres, périodiques, thèses, audiovisuel et au moins un cas difficile par site.
2. Revue du pilote par l'équipe de la bibliothèque dans le vrai catalogue, pas dans un tableur : chercher par auteur, par sujet, afficher la notice complète, prêter un exemplaire.
3. Ajustement de la correspondance selon ce qui apparaît : c'est là qu'on corrige l'encodage, les sous-champs mal affectés et les types d'exemplaire.
4. Chargement complet dans l'environnement de test, avec la totalité des notices, des exemplaires et des lecteurs.
5. Validation par comptages : notices, exemplaires par site, lecteurs par catégorie et codes-barres uniques doivent correspondre à l'origine.
6. Gel de l'ancien système : à partir d'une date et d'une heure fixées, plus aucun catalogage ni prêt n'y est fait.
7. Chargement différentiel et bascule : on migre ce qui a été saisi entre l'extraction et le gel, on pointe le domaine vers Koha et on ouvre l'OPAC.

Gardez l'ancien système accessible en lecture seule au moins un mois après la bascule. Cela coûte peu et règle bien des discussions.

Combien de temps prend une migration vers Koha

Le délai dépend bien plus de la qualité des données que de leur quantité. Ces fourchettes correspondent à des projets disposant d'un export dans un format standard, avec une équipe de bibliothèque qui participe à la validation.

La variable qui pèse le plus sur ces délais est le nombre de sites, pas le nombre de notices : chaque campus ajoute du paramétrage, des règles de prêt, des lecteurs et sa propre validation.

Ce qui tourne mal le plus souvent

• Accents et cédilles cassés par une conversion d'encodage mal déclarée. Cela se détecte au pilote, ou trop tard.
• Exemplaires en double : un champ d'exemplaire répété que la conversion interprète comme plusieurs exemplaires distincts. Neuf notices peuvent ainsi produire des dizaines d'exemplaires fantômes.
• Codes-barres répétés ou absents : Koha exige l'unicité. Si le fonds n'en a jamais eu, il faut les générer, les imprimer et les coller, ce qui constitue un projet à part entière.
• Notices sans exemplaire, visibles dans l'OPAC mais impossibles à prêter.
• Paramétrage incomplet : des catégories de lecteurs ou des règles de prêt oubliées qui se révèlent le jour de la rentrée.
• Ancien système non gelé, avec pour résultat deux catalogues qui divergent pendant des semaines.

Aucun de ces problèmes n'est rare ni grave s'il est détecté en phase de test. Tous coûtent cher s'ils apparaissent en production.

Après la migration

Une fois le catalogue chargé, trois décisions restent ouvertes : où héberger l'instance, avec quelle politique de sauvegarde et qui la met à jour. Nous les traitons dans notre guide de l'hébergement Koha. Pour dimensionner l'investissement, consultez le coût de mise en œuvre de Koha.

Si le fonds arrive avec des notices pauvres ou incomplètes, la migration est le meilleur moment pour l'enrichir. Chaque projet Koha de BiblioLabTech inclut sans surcoût BiblioScan AI, qui propose des notices MARC21 à partir de photos du document, révisées par le catalogueur avant enregistrement. BiblioLabTech migre vers Koha depuis des systèmes commerciaux et libres, y compris à partir de fichiers CSV, XML ou de dumps de base de données quand l'origine n'exporte pas en MARC, et remet un rapport de qualité des données avant le chargement définitif. Pour chiffrer votre projet, passez par notre service Koha.