L’infrastructure numérique & documentaire BVH, qui supporte l’ensemble des productions du programme de recherche, poursuit sa refonte, tant du point de vue du déploiement des nouvelles bases et fonctionnalités de production, d’indexation et de visualisation, que de la migration et de l’enrichissement de ses données.

Sommaire
— Modèle de données BVH pour la description de livres anciens & la base de données CataFonds
Rappels & définitions des niveaux structurels du Catalogue (ou base de données CataFonds)
Remodelage et découpage des données
Développements
Gestion de la bibliographie scientifique
— Le référentiel de données d’autorités commun BVH : data.bvh
Préparation des données & alignement
Déploiement, réconciliation & insertion des données sous Wikibase
— La plateforme de traitement & de reconnaissance d’image Arkindex
— La plateforme de gestion de numérisation : Numahop.bvh

Voir aussi les supports de présentation des interventions lors de l’assemblée générale BVH 2025 :
— Supports de présentations | Assemblée générale 2025 du programme « Bibliothèques Virtuelles Humanistes » & Atelier Bibliotheques françoises. 21 novembre 2025, CESR, Tours. Bibliothèques Humanistes. https://doi.org/10.58079/15a2u

Rappel : les collections BVH aujourd’hui

– 1 331 numérisations intégrales de manuscrits et imprimés en ligne (BVH Fac-similés)
En 2025, si le volume du corpus n’a pas augmenté, il a néanmoins fait l’objet de nombreux compléments, corrections et normalisation des notices, des sommaires, etc. au travers du travail en cours sur le « remodelage » des données en vue des imports dans le référentiel d’autorité data.bvh et dans la nouvelle base Catafonds – le catalogue général de description des sources BVH.
– 172 éditions numériques en XML-TEI (BVH Epistemon), et environs 50 textes transcrits en production
– des bases de données et sites-projets de recherche « satellites » : BaTyR, MONLOE, Scritpa Manent, Bibliotheques françoises, TypoReF, EDITEF, etc.

Au vu de l’ampleur du chantier, des avancées notables et importantes – bien qu’invisible de l’extérieur (ou presque, pour l’instant) – peuvent être présentées.

Les efforts se sont donc poursuivis en 2025 avec l’appui du pôle numérique du CESR (Sarra Ferjani) et du CETU ILIAD3 (Barthélémy Serres, Olivier Roussey – prestation interne). Les tests des solutions requises à la production et au traitement des données sont concluants. Leurs (re)déploiements sont opérationnels pour ce qui est des services/briques logicielles pivot de la nouvelle architecture, en vue de l’import des données qui nécessiteront des traitements préliminaires (engagé pour la partie métadonnées, cf. infra). Cela concerne la mise en œuvre en 2025 : du référentiel de données data.bvh (Wikibase), de la base de donnée Catafonds (PostGrSQL/Django), de la plateforme de suivi de numérisation (NumaHOP), des services IIIF (migration en cours pour intégration de nouvelles collections supplémentaires) et d’un stockage S3 (en test avant migration des données images/textes), et enfin de la plateforme de reconnaissance et d’indexation automatique (Arkindex / Deep learning ; AgoraWeb). La réflexion sur la refondation de la chaîne éditoriale texte (BVH-Epistemon) pour l’adosser à cette nouvelle infrastructure est prévue à compter de 2026 avec l’appui du PDN (Caen) et de la plateforme Estrade (Strasbourg). Le développement de la nouvelle bibliothèque virtuelle et des IHM de saisie autant que celles de consultation publique, interviendra à compter de 2026.

— Modèle de données BVH pour la description de livres anciens & la base de données CataFonds

Les BVH ont vocation à numériser et présenter des objets dans leur globalité et leur complexité. Un travail de fond est en cours aux BVH pour passer de données « à plat » qui mélangent actuellement des informations sur les éditions et les exemplaires à un découpage cohérent avec différents niveaux structurels (Œuvre, Expression, Manifestation, Unité éditoriale, Objet physique et Objet numérique).

Rappels & définitions des niveaux structurels du Catalogue (ou base de données CataFonds)

Le modèle de données visé inclura six niveaux de description :

• 3 abstraits
  • Œuvre : un concept abstrait et opératoire – qui à la manière d’une autorité – sert de point d’accès pour celui qui cherche.
  • Expression : la réalisation intellectuelle ou artistique d’une œuvre. Soit, selon la documentation IFLA-LRM, « une combinaison particulière de signes qui véhicule un contenu intellectuel ou artistique ». Dans note cas, ce niveau devra rester le plus transparent possible pour nos usagers. Il servira surtout à mieux organiser les niveaux inférieurs, et en premier lieu les Manifestations.
  • Manifestation : ici, comme il s’agira majoritairement d’imprimés, nous nous appuierons sur la définition de J.-F. Gilmont, à savoir l’ « ensemble des exemplaires d’un même ouvrage caractérisé par l’identité du texte, de la composition typographique, de la mise en page, des illustrations et de la pagination ».
• 1 intermédiaire, un concept charnière
  • Unité éditoriale : soit la plus petite composante de l’édition, elle se caractérise par la présence d’une page de titre, d’une pagination/foliotation continue et d’un relevé de signatures cohérent. C’est un découpage effectué par le catalogueur pour rassembler des unités issues d’un même geste éditorial (par exemple, une édition en plusieurs tomes).
• 2 concrets
  • Objet physique (ou exemplaire ou item) : une entité concrète qui permet la description de toutes les particularités de la ressource cataloguée. C’est le point de départ de la description. Il rassemble les aspects physiques, donc palpables, de l’objet qui est numérisé et/ou transcrit : reliure, annotations, incomplétudes, provenances, mentions manuscrites, localisation, cote…
  • Objet numérique : l’ensemble des contenus produits aux Bibliothèques Virtuelles Humanistes : 
    • collections d’images en différents formats (jpeg, jpeg2, pdf)
    • des transcriptions, ou éditions numériques
    • des métadonnées techniques et administratives (date de numérisation ou encore mention des droits applicables aux documents)

Remodelage et découpage des données

En novembre 2025, le chantier de reprise des données (étape 1/6 de la complexification du modèle) est avancé au ¾ pour le corpus BVH Fac-similés (soit 1 331 unités numérisées et actuellement en ligne) : 904 Manifestations ont été traitées. Il en restera 323 à faire. Pour ces futures notices de Manifestation, 6% se sont avérées problématiques ou compliquées à traiter.

Sur le plan méthodologique, ce travail de longue haleine a nécessité plusieurs étapes :

1. l’éclatement des données préexistantes dans un tableur de 11 feuilles
2. l’ajout des données à la création quasi ex nihilo des niveaux Œuvre et Expression
3. la prise en compte des travaux menés sur les autorités Personnes, Lieux, Collectivités et Familles, afin d’anticiper le raccordement de ces données au référentiel data.bvh (alors en cours de déploiement)
4. un renforcement des alignements de ces niveaux descriptifs avec le référentiel data.biblissima.

En terme de volumétrie, cela représente pour la seule base Fac-similés :

• 1 391 Œuvres
• 1 462 Expressions
• 904 Manifestations (ou édition)
• 1 063 Unités éditoriales
• 642 Objets physiques (ou exemplaire ou item) décrits
• 3 621 Objets numériques produits par les BVH (JPG, PDF, manifestes IIIF)

Le terme du chantier est prévu pour la fin février 2026 et permettra l’import dans la nouvelle base de données Catafonds.

Développements

Lors de l’assemblée générale de 2022, Marlène Arruga (IGE CDD en développement web, Biblissima) avait présenté un premier jet d’interfaces pour la future bibliothèque numérique. Cette étape a permis de confirmer la plupart des choix faits pour notre modèle relationnel et d’y ajouter un niveau important : celui des Expressions. Plus largement, cette étape a permis d’avoir un support visuel sur lequel accrocher nos réflexions et travailler en équipe. Mais ce travail a aussi mis en lumière certaines limites, liées surtout à la complexité de notre modèle de données.

En premier lieu, un risque sur les données : le temps et les moyens humain requis pour rendre toutes ces données compatibles avec le modèle complet, en intégrant toutes les informations encore manquantes ou à l’état embryonnaire comme les provenances, description des reliures, vie de l’objet, etc. Un traitement et découpage itératif et progressif des données est donc requis pour éviter un maximum d’accentuer l’hétérogénéité des données au sein de la base, ainsi qu’éviter tout blocage de la migration même des données. En second lieu, s’ajoute un risque sur les usages : la multiplication des points d’accès par niveau Œuvre, Objet, Manifestation, Objet numérique que nous avions envisagée rend la navigation difficile, peu fluide et peu intuitive. À terme, le risque serait d’invisibiliser les données devenues difficiles à comprendre et à exploiter. Elles ne seraient ainsi accessibles qu’aux seuls experts, alors que nos publics sont beaucoup plus larges et ont des besoins ou des façons de consulter très variés.

À partir de ces constats, nous avons choisi d’adopter une stratégie de migration itérative, par étapes : commencer par un modèle de données simplifié pour la première phase, puis réintroduire les éléments avancés au fil des phases suivantes.

Les choix techniques réalisés en 2022 sont maintenus : une base de données PostgreSQL et un développement des interfaces avec le framework Django (Python). La première étape étape est entièrement menée en interne (S. Ferjani, pôle numérique du CESR) afin de mieux comprendre nos propres données et permettre l’ajustement du schéma si nécessaire. Fin 2025, le développement du back-office – la partie « administration » de la base – est finalisé. Un jeu de données test nous a permis de vérifier l’affichage correct dans les interfaces de saisies. Le front-office – les interfaces destinées au public seront quant à elles développées ensuite, toujours en interne, au premier semestre 2026. À ce stade, les interfaces et l’organisation resteront proche de l’actuelle bibliothèque virtuelle : un seul point d’entrée, une organisation linéaire des données, ce qui facilitera la lecture et la navigation. La structure avec une navigation plus complexe telle qu’elle a été imaginée en 2022, sera réintroduite progressivement dans les prochaines versions. Il s’ait pour nous au préalable d’identifier et définir les différents modes de navigation et points d’entrée que nous souhaitons mettre à disposition de nos publics. Le recours aux compétences d’un prestataire spécialisé en UI/UX design sera nécessaire. Enfin, pour plus de clarté et lisibilité, le site actuel sera scindé en deux espaces distincts : l’entrée dans la bibliothèque virtuelle via le catalogue, l’entrée dans la partie éditoriale de présentation du programme de recherche et de ses activités, déployée sous WordPress.

Gestion de la bibliographie scientifique

Parallèlement, au remodelage des données issues des Fac-similés, le stage de 4 mois de Mathis Quais (M2 HN, CESR ; Biblissima+) s’est consacré à la mise en place d’un workflow de gestion de la bibliographie scientifique dans les différentes bases de données du programme BVH, ainsi qu’au traitement rétroactif des références existantes associées aux Fac-similés¹. Un état de l’art initial des outils disponibles a permis de confirmer le choix de Zotero, retenu pour différents atouts évidents : sa simplicité d’usage et son adoption large dans la communauté scientifique, sa compatibilité avec des formats standards d’échange (BibTeX, JSON), sa gestion collaborative (groupes partagés, synchronisation) et son API, et enfin son statut de logiciel libre autant que sa gratuité. Ont ensuite été définis grâce à un état des lieux des bibliographies dans les multiples bases : des normes de saisie internes et un style pour l’affichage des références proche des pratiques BVH actuelles. L’étape majeure visait au traitement et à la normalisation des données vers un format importable dans l’outil Zotero en utilisant le modèle de langage Mistral. Le script Python établit sur 4 028 références, envoyant chacune à l’API avec à la fois le texte brut et une version pré-traitée par expressions régulières pour améliorer les résultats. Un dédoublonnage avec OpenRefine a ensuite permis d’obtenir une bibliothèque Zotero partagée relativement propre mais nécessitant une dernière étape de vérification et particulièrement de complétion des références. La bibliographie a ainsi été réduite de 4 000 occurrences à 1 100 références qui devront donc être retravaillées individuellement et manuellement. Leworkflow validé et testé permet désormais la synchronisation entre les références de la bibliothèque Zotero (détection des modifications récentes via l’API Zotero) et la base de données CataFonds (Django/PosGrSQL).

— Le référentiel de données d’autorités commun BVH : data.bvh

Le but de ce référentiel data.bvh est d’établir un jeu de données normalisées pour indexer et organiser efficacement les ressources au sein de notre bibliothèque numérique dans un  premier temps, et d’optimiser le partage  et la réutilisation de ces métadonnées pour nos partenaires dans un second.

Préparation des données & alignement

En 2025, un noyau de descripteurs a été retenu avec la définition des règles de saisie (dates, formes retenues, estimation du niveau de certitude de l’information) et l’alignement avec les référentiels externes réalisés (BnF, IdRef, data.biblissima…). Le modèle retenu s’adosse aux modèles ontologiques existants – tels que CidocCRM (puissant mais complexe) ou RDA-FR (un modèle encore récent appliqué aux pratiques du livre dont il faudra suivre les évolutions) – sans pour autant prétendre à un alignement à 100%, afin de garder une certaine souplesse.

Concrètement, le travail sur les données du référentiel BVH a consisté en :

1. un tri entre les personnes, les collectivités, les familles et les titres uniformes qui étaient mélangés afin obtenir un fichier cohérent pour chaque groupe
2. puis une répartition logique des informations préexistantes et un contrôle des URIs déjà renseignées.
3. puis un rapprochement entre des noms d’agents similaires avec les fonctions de clusterisation d’OpenRefine afin d’effectuer une première vague de dédoublonnage.
4. enfin, la réconciliation en elle-même, à savoir le rapprochement de chaque valeur présente dans notre jeu de données avec un autre référentiel. Notre jeu de données a été enrichi avec l’importation de nouvelles informations depuis data.biblissima (puis Wikidata, par rebond), telles que des identifiants ou tout autre élément jugé utile.

Ainsi, le jeu de données issu de BVH-Fac-similés a été traité (Anne-Laure Allain) et est en cours d’importation dans la toute nouvelle instance wikibase data.bvh, déployée par ILIAD3 et paramétrée par le pôle numérique du CESR (Sarra Ferjani). Les référentiels comptent actuellement : 99 Propriétés, 2 805 Personnes, 650 Lieux, 64 Collectivités, 38 Pays, 3 Familles. Lors de cette phase, quelques rectifications ont été apportées au schéma (reprise des incohérences, des propriétés floues, etc.).

Déploiement, réconciliation & insertion des données sous Wikibase

Notre instance de Wikibase, hébergée sur une VM de l’Université de tours (Data-Centre, BRGM Orléans) et documentée (GitLab Huma-Num), est désormais opérationnelle : la phase de configuration et de prise en main est engagée. Cette version de Wikibase (Wikibase suite Deploy 4, stack docker) comprend un système d’interrogation SPARQL avec son EndPoint, un système d’insertion de données avec Quickstatements ainsi qu’une API de réconciliation avec OpenRefine. Ces deux derniers permettent l’intégration des données par lot. 

Le travail d’insertion est rendu complexe du fait des fichiers contenant des dizaines de colonnes. Il impose de recourir en amont à OpenRefine pour procéder à la réconciliation des données. Le fait qu’il soit dorénavant directement connecté au Wikibase permettra lorsque la réconciliation est faite, de faciliter l’insertion et inversement si nécessaire, d’enrichir les données du référentiel. L’insertion des données nécessite de recourir à des schémas. Il s’agit de créer les déclarations à intégrer dans le Wikibase. L’avantage de ces schémas réside dans le fait qu’ils peuvent être sauvegardés et réutilisés pour d’autres jeux de données similaires, et ainsi refaire rapidement la procédure. Ils permettent également de créer des déclarations complexes. Pour les dates par exemple, on ne souhaite pas seulement les déclarer mais également les qualifier avec des éléments pré-déterminés tels que post, ante, circa ou encore indiquer une mention de fiabilité de l’information. Un export avec Quickstatement permettra d’insérer de la même façon. Il permet toutefois une validation visuelle préalable, c’est-à-dire de voir en clair les données qui vont être insérées.

Malgré son efficacité, cette chaîne de traitement comporte quelques contraintes. Une fois les entités créées dans Wikibase, il est possible d’ajouter de nouvelles déclarations (par exemple un nouvel identifiant externe), mais pas de modifier la valeur d’une déclaration existante. On doit donc intervenir manuellement, entité par entité ou passer par l’API à l’aide de scripts. Autre point non négligeable, la manipulation de tableaux de données comportant parfois un grand nombre de colonnes peut devenir complexe et peu intuitive pour une partie de l’équipe. Enfin, contrairement à un processus développé sur mesure où les étapes sont déjà cadrées, la réutilisation des schémas impose des fichiers strictement identiques et un ordre d’insertion rigoureux, rendant le workflow peu intuitif. Un formulaire type base de données classique, où le process d’insertion dans les tablées dédiées à déjà été pensé et intégré, est donc requis pour les insertions ou interventions ponctuelles des membres de l’équipe scientifique afin d’assurer leur autonomie lors de la saisie.

Plusieurs points restent à résoudre pour que le référentiel devienne un outil pleinement opérationnel au sein de l’écosystème BVH. Les insertions doivent encore être finalisées : alias, sources, bibliographies, relations entre les personnes, professions, etc. Pour certaines données complexes, la réflexion n’est pas encore aboutie, plus particulièrement sur nos champs de notes. Souvent très riches, longues et détaillées, elles sont pourtant indispensables pour identifier ou distinguer certains individus. Or ce type d’information s’intègre difficilement dans le cadre natif de Wikibase puisque les champs textes sont limités à 400 caractères.

Les outils (scripts, API, IHM) du workflow entre Catafonds et les référentiels data.bvh constituent la prochaine étape du travail à mettre en œuvre. Outre le choix des outils pour créer des interfaces de saisie et de modification plus intuitives, il s’agira aussi d’évaluer la capacité de Wikibase à répondre de manière performante lors de multiples accès API ou de requêtes complexes. Cette évaluation est cruciale pour déterminer quelles informations devront rester stockées (voire dupliquées) en base de données, et celles qui pourront être entièrement externalisées dans le Wikibase. Cet enjeu devient d’autant plus important que nous envisageons de faire du Wikibase un référentiel commun et partagé. Data.bvh sera progressivement enrichie dans les années à venir avec les données issues des multiples bases BVH qui nécessiteront des traitements et développements spécifiques (BibFr, BaTyR, Editef, ORB, Scripta manent, Epistemon…).

Aux problématiques précédents s’ajoutent celles de la gestion des droits et des différents niveaux d’administration (qui peut créer, modifier, dédoublonner, valider), de la synchronisation des données et d’autant plus pour certaines bases qui stockent en interne des informations également dans le wikibase, et enfin de la gestion des divergences ou autrement dit, comment gérer les cas où deux sources ne concordent pas ? Comment traiter les désaccords sur une donnée ?

— La plateforme de traitement & de reconnaissance d’image Arkindex

Basée sur la solution Arkindex de la société TEKLIA (partenariat innovant, Biblissima+), le déploiement de la plateforme de traitement et de reconnaissance d’image en co-portage LIFAT-CESR, est effectif depuis janvier 2025. Un modèle d’apprentissage centré sur le matériel d’imprimerie (Y. Hbada, T. Brouard – LIFAT) a été établi et est en cours de test sur cette plateforme, déployée et maintenue par le CETU ILIAD3 (prestation interne sur ressources propres). De la force de calcul supplémentaire sera nécessaire rapidement pour accélérer les traitements sur un volume de données conséquent à traiter (cf. projet régional GPU4all déposé, et investissement matériel sur Biblissima+). Les premiers tests d’extraction avec AgoraWEB (version web d’AGORA redéveloppé par JY Ramel – LISTIC) sont en cours. Le worker WAGORA – en cours de développement par Teklia – permettra l’échange et la réutilisation/mise à jour des données entre Arkindex et AgoraWeb (cf. bilan scientifique 2025, dédié à la base BaTyR / ANR TypoReF). 

— La plateforme de gestion de numérisation : Numahop.bvh

Une instance locale de NumaHOP est désormais fonctionnelle, déployée par ILIAD3. La plateforme doit permettre de rationaliser et fluidifier autant le traitement rétroactif des numérisations BVH (images, métadonnées, sommaires et générations des formats d’exports pour la diffusion et l’archivage), que celles issues des futures campagnes de numérisation dans les établissements de conservation partenaires. Les paramétrages et tests fonctionnels sont encore à mener au premier trimestre 2026 dans la perspective d’établir des spécifications pour développer des connecteurs et modules spécifiques (échanges des métadonnées avec Catafonds, établissement des sommaires, services IIIF…), et mettre en place une prestation de maintenance (Biblissima+).

Le 19 juin 2025 s’est tenue à la BULAC (Paris), la première journée du groupe de travail sur la Feuille de route pour le développement du logiciel NumaHOP. L’ensemble des conclusions, ainsi que les premières restitutions de cette journée de travail, dont le schéma des entrées et sorties NumaHOP, ont été communiqués aux membres de la communauté. Il a été acté aussi la création d’un dépôt Github unique pour NumaHOP. Ce dépôt communautaire a été créé au nom de l’association NumaHOP par la société Biblibre à l’adresse suivante : https://github.com/NumaHOP/NumaHOP ; il donne accès également à la documentation technique et au guide d’installation.

La participation du CESR comme équipe de recherche est très bien accueillie par l’Association NumaHOP, en raison de la complémentarité des expériences et besoins déjà émis par la communauté essentiellement jusque là issue des bibliothèques. La plateforme NumaHOP fait partie des outils soutenus et intégrés à la feuille de route CollEx-Persée et bénéficiera à ce titre, et au travers de l’association NumaHOP,  d’une communauté active et en devenir, dans laquelle s’insère le CESR-BVH.

Extrait du bilan 2025 présenté lors de l’assemblée générale du programme BVH,
par Anne-Laure Allain, Sandrine Breuil & Sarra Ferjani (le 21 nov. 2025)

Biblissima+ bénéficie d’une aide de l’État gérée par l’ANR au titre du Programme d’investissements d’avenir intégré à France 2030, portant la référence ANR-21-ESRE-0005

1. Voir profil et missions détaillées : Offre de stage | Spécifications et traitement de la bibliographie dans le portail BVH (4 mois, CESR, Tours), https://bvh.hypotheses.org/12273 [↩]

---

Le texte seul est utilisable sous licence Creative Commons Attribution 4.0 International. Les autres éléments (illustrations, fichiers annexes importés) sont “Tous droits réservés”, sauf mention contraire.

---

---