# Interopérabilité des bases de données scientifiques : une sobriété de façade

## Interoperability of Scientific Databases: a Facade of Sobriety

Régis Witz et Guillaume Porte

<figure><img src="image_1.png" /></figure>

### Édition électronique

URL : https://journals.openedition.org/revuehn/4575

DOI : 10.4000/1498w

ISSN : 2736-2337

### Éditeur

Humanistica

### Référence électronique

Régis Witz et Guillaume Porte, « Interopérabilité des bases de données scientifiques : une sobriété de façade », *Humanités numériques* [En ligne], 11 | 2025, mis en ligne le 15 juin 2025, consulté le 09 décembre 2025. URL : http://journals.openedition.org/revuehn/4575 ; DOI : https://doi.org/10.4000/1498w

<figure><img src="image_2.png" /></figure>
<figure><img src="image_3.png" /></figure>

# Interopérabilité des bases de données scientifiques : une sobriété de façade

## Interoperability of Scientific Databases: a Facade of Sobriety

Régis Witz et Guillaume Porte

### Résumés

Une tâche est plus sobre si elle consomme moins de ressources, sur l'ensemble de son cycle de vie. Dans le domaine des humanités numériques, certaines des tâches les plus difficiles ont trait à l'interopérabilité des bases de données, telles que la documentation, l'alignement, la migration ou la publication. Nécessitant souvent un savoir spécialisé, ces tâches peuvent vite devenir chronophages. Après avoir rappelé le contexte dans lequel ces tâches sont généralement réalisées, cet article proposera des éléments de solution pour réduire leur consommation en ressources, en particulier en ressources humaines. Enfin, il discutera les bénéfices et les limites de ces solutions.

Any task is more sustainable if it consumes fewer resources, over its entire lifecycle. Some of the challenges of Digital Humanities are tasks related to interoperability between databases, such as documentation, alignment, migration and publication. Often requiring specialised knowledge, these tasks can quickly become time-consuming. After recalling the context in which these tasks are generally undertaken, this article will propose solutions for reducing their consumption of resources, of human resources in particular. Finally, it will discuss the benefits and limitations of these solutions.

### Entrées d'index

MOTS-CLÉS : sobriété numérique, base de données, interopérabilité, données ouvertes, encodage, ontologie

KEYWORDS: digital sufficiency, database, interoperability, open data, encoding, ontology
# Une multitude de formats de bases de données

Le paysage actuel des bases de données est caractérisé par pléthore de formats et de syntaxes, de variantes lexicales au sein d'un même format et de différences sémantiques d'un projet à l'autre. Pour dresser une liste non exhaustive des formats de données, on peut citer les modèles relationnels, majoritairement basés sur SQL¹, ou ceux orientés tableurs, tels que CSV² ou ODS³. De nombreux formats plus génériques, tels que XML⁴, JSON⁵ ou YAML⁶, sont très courants. On peut aussi y ajouter ceux utilisés par les triplestores, basés sur les triplets RDF⁷, ainsi que ceux basés sur des graphes ou même sans schéma⁸ prédéfini, généralement issus de la mouvance NoSQL⁹. Dans le contexte des sciences humaines, le terme « base de données » désignant souvent un corpus de textes ou d'images, on pourrait aussi considérer les langages de balisage comme Markdown¹⁰ ou reStructuredText¹¹ ou encore les différents modèles d'organisation de collections de sons, d'images, de vidéos ou de modèles 3D. De plus, de nombreux projets en humanités numériques partagent leurs données grâce à des CMS¹² tels qu'Omeka ou WordPress, qui ont leur propre organisation des données sous-jacente. La liste est longue et, suivant les points de vue, chacun de ces formats pourrait être considéré comme un standard.

Un format numérique est fondamentalement une spécification de la façon dont l'information est organisée. Plus cette spécification est permissive ou imprécise, plus il peut y avoir de différences entre ses implémentationes. Chaque implémentation peut aussi élargir son périmètre fonctionnel au-delà de la spécification initiale, mais cette extension lexicale sera généralement inexistante ailleurs.

Quelques exemples :

* Le format Comma-Separated Values (CSV) est décrit par la RFC 13 4180 (Shafranovich 2005). Toutefois, le format CSV n'a jamais été formellement spécifié, la RFC 4180 ayant uniquement valeur de recommandation. N'importe quel séparateur de valeurs peut donc être utilisé, avec un niveau de support très variable.

* La plupart des systèmes de bases de données relationnelles peuvent être interrogés avec le langage SQL. La syntaxe des requêtes SQL usuelles est la même partout. Toutefois, chaque système peut offrir des fonctionnalités avancées similaires mais légèrement différentes, et la syntaxe des requêtes correspondantes varie (Kellerer 2023).

* Le Markdown souffre de nombreuses variantes visant à l'étendre, souvent à contrecourant de sa philosophie initiale (Gruber 2004 ; Hyde 2018).

* La TEI¹⁴ est implémentée comme un sous-ensemble de XML, définissant ses propres éléments de schéma, XML étant extensible. Cependant, une conséquence est que travailler en TEI peut nécessiter des logiciels spécialisés, là où un outil XML générique ne suffira généralement pas.

* Chaque API « REST » partage ses ressources à sa manière, avec une logique qui lui est généralement propre. En particulier, chacune de ces API n'a pas le même niveau de maturité (Richardson 2008 ; Fowler 2010). La plupart ne s'autodocumentent pas, ne peuvent donc pas être découvertes automatiquement et nécessitent donc des clients *ad hoc*.
4

Même si on ne considère qu'une seule implémentation d'un unique format, il n'est pas rare que chaque projet développe sa propre sémantique. Par exemple, la quasi-totalité des bases de données relationnelles ont leurs propres tables, avec leurs propres colonnes, qui ont leurs propres noms et types. Autre exemple : certaines spécifications, comme la TEI, offrent tellement de possibilités et couvrent tellement de cas, qu'il est facile d'aboutir à un résultat totalement spécifique à son projet¹⁵.

5

Aussi, le niveau de documentation des décisions prises varie considérablement d'un projet à l'autre. Or, connaître la vision des créateurs d'une base de données est crucial pour interagir avec elle ou assurer sa migration. Si cette vision est incomplète, cela peut conduire à des imprécisions, voire à des erreurs d'interprétation.

6

L'usage croissant des référentiels d'autorité, des ontologies, des identifiants uniques et autres standards scientifiques¹⁶ constitue une bonne pratique (et traduit une prise de conscience ?). Cependant, cette pratique évolue régulièrement, et n'est pas forcément adoptée partout, ne serait-ce qu'en raison du poids des habitudes ou de la dette technique constituée par les projets « historiques » non mis à jour. Les communautés de recherche sont encore souvent clairement distinctes, disciplinaires ou thématiques, et leurs préconisations ne se propagent pas toujours en dehors de leur sphère d'influence.

7

Bien qu'elles aillent dans le bon sens, toutes ces innovations ne réduisent dans le meilleur des cas que l'hétérogénéité des projets (souvent nouveaux) qui font l'effort de les adopter. Au contraire, la découverte progressive des pratiques numériques, les dispositifs de financement de la recherche par projet et autres contraintes systémiques posent toujours de nombreux défis à l'interopérabilité des données de recherche.

8

Cet article fait l'hypothèse que la tendance actuelle ne s'inversera pas et que le nombre de standards n'ira jamais en diminuant. À l'inverse, les nouveaux standards s'ajouteront toujours aux existants, sans les remplacer. Chaque projet ou communauté suivra son propre chemin, accueillant parfois d'autres communautés et leurs standards, essaimant parfois ses propres « standards » et de énièmes silos de données, de moins en moins accessibles au fil du temps. Cette hypothèse est certes défaitiste mais elle est aussi pragmatique. Cet article propose des éléments de solution pour rendre plus résiliente, et donc plus sobre, l'interopérabilité entre des bases de données condamnées à être toujours différentes. Le but est de contribuer à rendre les activités liées à l'interopérabilité moins chronophages et moins demandeuses en ressources humaines et, donc, en financements.

## L'interopérabilité, en pratique

9

Considérons un nouveau projet souhaitant réutiliser, entièrement ou en partie, les données d'un projet existant. Cet article désignera le nouveau projet par le terme de consommateur et le projet existant par celui de producteur. Pour rendre le projet consommateur interopérable avec le projet producteur, l'équipe du projet consommateur devra passer par les étapes suivantes.

1. Maîtriser les technologies utilisées par le projet producteur pour sa base de données.

2. Comprendre le schéma d'organisation de ces données. Dans le meilleur des cas, cela signifie connaître le standard utilisé, si ledit standard ne laisse aucune marge à l'interprétation et si le producteur de
données ne s'en écarte pas du tout. Dans tous les autres cas, cela signifie
comprendre l'organisation particulière des données du projet
producteur.

3. Concevoir l'alignement des schémas des projets producteur et consommateur. Cette étape est celle qui a tendance à poser le plus de défis scientifiques et, parfois, techniques. Elle peut nécessiter un enrichissement des données, ce qui implique potentiellement que le consommateur doive devenir interopérable avec un ou plusieurs autres projets producteurs en plus du premier, auquel cas il lui faudra franchir ces 5 étapes pour chacun d'eux.

4. Implémenter ce qui a été conçu, en général sous la forme d'un composant logiciel, que cet article désignera par le terme de connecteur. Le rôle d'un connecteur est d'adapter les données du projet producteur au projet consommateur.

5. Valider la qualité de l'implémentation, tant sur les aspects scientifiques que techniques.

La complexité des projets impliqués, l'expérience technique et scientifique de leurs membres, et de nombreux autres paramètres influent sur la durée et l'efficience de chaque étape. Ces étapes ne sont pas forcément séquentielles. Le processus complet peut être itératif et complété par d'autres étapes propres à l'organisation et aux particularités des projets concernés.

## Construire un écosystème de bases de données interopérables

Assurer l'interopérabilité entre deux bases nécessite donc le développement d'au moins un connecteur, qui adapte les données du projet producteur au projet consommateur. Chaque base de données étant différente, cela suppose de développer un connecteur adapté aux particularités des deux projets. Par exemple, si le projet consommateur agrège N corpus différents, il peut être nécessaire de développer N connecteurs.

Parfois, une collaboration scientifique permet à un projet producteur de bénéficier en retour des données que le projet consommateur a enrichies ou mises à jour. Dans cette hypothèse, le transfert des données se fait dans les deux sens, les deux projets étant à la fois consommateurs et producteurs. La collaboration est heureuse mais elle peut imposer de doubler le nombre de connecteurs. En effet, convertir les données d'une base vers une autre n'est pas la même chose que de les convertir dans l'autre sens.

Par conséquent, créer un écosystème de bases de données scientifiques interopérables entre elles dans les deux sens avec N bases productrices et M bases consommatrices peut imposer de créer $2 \times N \times M$ connecteurs (figure 1). Cela demande un important travail, aussi bien pour la conception et l'implémentation initiales, que pour la maintenance sur le long terme. Chaque base ayant ses spécificités et son propre cycle de vie, maintenir un tel écosystème sur la durée – et *a fortiori* l'étendre par la suite – représente un réel défi.

10

11

12

13
<figure><img src="image_4.png" /><figcaption>Figure 1. Exemple d'écosystème de bases de données</figcaption></figure>

Dans cet exemple, N (= 4) bases productrices de données (en bas) alimentent M (= 2) bases consommatrices (en haut) à travers N × M (= 8) connecteurs (au milieu).

Image produite par l'auteur

## Des contraintes multiples

Toutes les étapes du développement d'un seul connecteur imposent des temps de réflexion, d'apprentissage et d'échange. Elles nécessitent des profils détenteurs de compétences scientifiques et techniques bien particulières. De tels profils ne sont pas toujours disponibles. Même quand ils le sont, ces étapes impliquent quand même des coûts indirects, humains et financiers, engloutis en réunions, déplacements, recrutements, formations, outillage, et ainsi de suite (ANR 2022).

Le projet producteur peut être encore actif au moment où le projet consommateur se monte. Si le projet consommateur réutilise les données du projet producteur de manière synchrone ou, plus simplement, si les données sont régulièrement mises à jour, il est soumis au cycle de vie du projet producteur. En d'autres termes, les membres du projet consommateur doivent être en capacité de gérer les montées de version et autres ruptures de compatibilité entre les deux projets. Ces événements sont d'autant plus probables lors de travaux de recherche de longue durée.

Les choix techniques, le manque de documentation, de démarche qualité systématique¹⁷, de maintenance, de mutualisation, sont autant de handicaps qui peuvent condamner n'importe quelle base de données scientifique à disparaître en quelques années. Si cela est évidemment tragique du point de vue de l'équipe porteuse du projet, cela peut être autrement problématique si, avec le temps, ce projet était devenu un producteur de données. Dans le pire des cas, cela peut entraîner une réaction en chaîne de projets dégradés.

Le financement de la recherche sur le mode projet accentue ces contraintes, tous les projets ou presque semblant préférer redévelopper et réinventer au lieu de s'appuyer sur l'expérience des projets précédents.

La création d'un écosystème de recherche entre de nombreuses bases de données différentes, dans lequel chaque base conserve ses spécificités organisationnelles et techniques, est une démarche relativement rare. Lorsque la création d'un tel écosystème est entreprise, son périmètre se cantonne à quelques bases aux thématiques proches ou au sein de la même discipline. Parfois, il s'agit de migrer d'anciennes bases vers une nouvelle organisation, puis de les supprimer : ce n'est pas une démarche de création d'un écosystème de bases communicantes, mais la création d'une énième nouvelle base de données, qui ne remplace pas toujours les précédentes.
Réinventer la roue : le patron de conception façade

Il y a au moins une manière de réduire la complexité d'un tel écosystème, et donc les ressources nécessaires à son développement et à sa maintenance. À chaque fois qu'un connecteur entre deux bases semble nécessaire, il est préférable de ne pas en développer un... mais deux. Le premier connecteur adapte la base du projet producteur non pas directement au projet consommateur, mais à une interface unique, commune à tous les projets de l'écosystème. Le second connecteur adapte les données depuis cette interface commune vers le projet consommateur.

Cette technique permet de n'avoir à développer et maintenir que $N + M$ connecteurs ou, dans le pire des cas, $2 \times (N + M)$, si l'interopérabilité doit se faire dans les deux sens. Le travail à fournir pour créer et maintenir l'interopérabilité est donc plus faible, dès lors qu'il y a dans l'écosystème considéré au moins 2 projets producteurs et 2 projets consommateurs.

Cette technique est en fait une déclinaison du patron de conception « façade ».

Initialement décrits formellement par Gamma *et al.* (1994), les patrons de conception, ou *design patterns*, sont des solutions d'architecture logicielle répondant à des problématiques habituelles de développement logiciel. La façade est l'un d'entre eux, qui a pour objectif de simplifier l'accès à une interface ou un ensemble d'interface complexes¹⁸.

Dans le cas qui nous occupe, l'interface commune entre les connecteurs est une façade simplifiant l'accès à l'ensemble des bases de données productrices par les projets consommateurs. Cette façade gomme les spécificités et détails d'implémentation des projets producteurs qui sont inutiles aux projets consommateurs, mais conserve et harmonise ce qui est indispensable. Ainsi, chaque base de données peut garder ses spécificités. Chacune voit la justification de son existence renforcée, car elle prend part à un écosystème plus grand que la somme de ses parties, car il permet de tirer le meilleur de toutes les données qui y transitent.

<figure><img src="image_5.png" /><figcaption>Figure 2. Principe de la façade</figcaption></figure>

En adoptant le principe de la façade, les $N$ (= 4) bases productrices de données (en bas) alimentent $M$ (= 2) bases consommatrices (en haut) à travers seulement $N + M$ (= 6) connecteurs (au milieu). La façade n'est pas elle-même un connecteur à implémenter mais une spécification du format d'interface unique que les autres connecteurs doivent respecter pour leurs entrées et sorties.

Image produite par l'auteur
24

Évidemment, le réel défi est de créer une telle façade, capable de donner accès de manière unifiée à toutes les données transitant dans l'écosystème de recherche. La façade doit supporter toutes les informations indispensables de tous les projets existants ou à venir, quelles que soient leurs spécificités technologiques, syntaxiques, lexicales et sémantiques. Pour rester pertinente, elle doit, entre autres, faire tout cela de manière sobre et pérenne.

25

Chaque écosystème de recherche, ou groupe de projets, pourrait implémenter une telle façade correspondant à ses besoins particuliers et à ses propres habitudes syntaxiques et conceptuelles. Cependant, concevoir et mettre en place une telle interface peut prendre du temps, surtout si le périmètre d'action de cette interface (en particulier le nombre de projets scientifiques qu'elle doit supporter) est important. Outre les contraintes techniques à surmonter, la plus grande difficulté semble plutôt être scien-tifique, car créer un écosystème operable nécessite d'aligner les concepts, les vocabulaires, les ontologies, et ainsi de suite. Mais paradoxalement, si on prend le périmètre le plus large qu'on puisse imaginer, à savoir une interface entre toutes les bases de données existantes et à venir, quelles que soient leur discipline, leur thématique de recherche, la vision de leurs porteurs, la qualité de leur documentation, la quantité de données qu'elles contiennent, les technologies sous-jacentes, leur origine institutionnelle, leur capacité à coopérer, et ainsi de suite..., dans ce cas, le travail n'est peut-être pas si difficile que cela.

26

D'ailleurs, une telle façade existe déjà : Hera.

## Hera : un schéma de schémas

27

Hera (Witz 2024a) s'appuie sur une modélisation minimale et générique des données¹⁹. Son modèle interne, volontairement simple et resserré, ne cherche cependant pas à se substituer aux bases avec lesquels il interagit. L'objectif est de permettre la réutilisation des données à moindre coût. Hera propose donc un modèle permettant de traduire les données de n'importe quelle base de données externe, quels que soient son format ou sa thématique, sans toutefois imposer une conversion complète des schémas. L'utilisateur (qu'il soit humain ou un logiciel tiers) peut configurer ses connecteurs en fonction des besoins afin de produire ses propres solutions de conversion, d'analyse ou de visualisation, ou n'importe quel autre traitement.

28

Pour représenter toute base de données imaginable, le schéma Hera s'appuie sur les 5 concepts principaux suivants.

* Une propriété est une caractéristique réutilisable susceptible d'être déclarée par une ou plusieurs entités d'une base de données.

* Une métadonnée est un élément atomique d'information. Elle n'a de sens que si elle est associée à d'autres métadonnées ; l'agrégat ainsi formé est un élément. Elle est obligatoirement relative à une propriété ou un attribut dont elle représente la valeur pour cet élément (ou une des valeurs, si elle est répétable).

* Un élément est un agrégat ou composite de métadonnées. Il s'agit souvent de la manifestation concrète d'une entité mais ce n'est pas obligatoire.

* Une entité est un type de sujet, un concept en rapport avec la thématique de la base de données à laquelle elle appartient. Une entité est caractérisée par des attributs permettant de définir toutes les informations nécessaires à sa description.
* Un attribut est l'utilisation par une entité d'une propriété particulière.

29

Chaque base de données contient donc des éléments décrits par des métadonnées. Chaque métadonnée référence une propriété, qui explicite sa sémantique et contraint les valeurs qu'elle peut prendre.

30

Dans de nombreux cas, la base de données contient aussi des entités, qui explicitent la sémantique des éléments qu'elle contient et contraint les métadonnées que ces éléments contiennent. Chaque entité est décrite par des attributs ; chaque attribut spécialise une propriété et explicite sa sémantique dans le contexte de son entité.

31

À des fins d'illustration, les trois figures ci-après (figure 3, figure 4 et figure 5) montrent un exemple de modélisation Hera, et les relations unis-sant les concepts précédemment décrits.

<figure><img src="image_6.png" /><figcaption>Figure 3. Exemple de propriété (à gauche)</figcaption></figure>

Image produite par l'auteur

<figure><img src="image_7.png" /><figcaption>Figure 4. Exemple d'entité (à gauche) listant ses attributs (au milieu), dont chacun est l'utilisation concrète, potentiellement plus spécialisée, d'une propriété (à droite)</figcaption></figure>

Image produite par l'auteur

<figure><img src="image_8.png" /><figcaption>Figure 5. Exemple d'élément (à gauche) listant ses métadonnées (au milieu)</figcaption></figure>

Chaque métadonnée est la valeur concrète d'un attribut de l'entité décrivant cet élément ou d'une propriété (à droite)

Image produite par l'auteur
32

En plus de représenter les données elles-mêmes, ce modèle encourage le fait de renseigner la description et une ou plusieurs URI pour chaque propriété et chaque entité. En effet, propriétés et entités devraient être reliées à des ontologies ou standards scientifiques existants, pour documenter le schéma de chaque base de données et ainsi maximiser l'accessibilité et la réutilisabilité des éléments qui la composent.

33

Il peut être intéressant de noter que descriptions et URI peuvent être ajoutées par un connecteur, même si ces informations documentaires sont absentes de la base de données d'origine. Cela permet, par exemple, de compenser le manque d'informations dans la base de données producitrice, de préciser la vision des porteurs originaux ou l'intention du connecteur, de spécialiser un jeu de données restreint à une sous-partie de sa base d'origine, et ainsi de suite.

34

Cependant, toutes les équipes de recherche n'ont pas la motivation, le temps ou la compétence pour développer leurs propres connecteurs. D'autant que le connecteur le plus rapide à développer est... celui qui existe déjà. C'est pour cela qu'a été créé Heimdall.

## Heimdall : une bibliothèque de connecteurs

35

Heimdall est un logiciel mettant à profit la modélisation offerte par Hera pour rendre plus aisée et pérenne l'interopérabilité entre de multiples systèmes. En pratique, il met à disposition trois jeux de fonctionnalités : une liste de connecteurs pré-implémentés pour convertir facilement une ou plusieurs bases de données d'un format à un autre ; un mécanisme d'extension permettant à n'importe quelle équipe ou projet de créer son ou ses connecteurs, qui seront automatiquement fonctionnels sans intervention supplémentaire sur le code d'Heimdall ; et un ensemble d'utilitaires pour réorganiser, documenter et enrichir n'importe quelle base de données, sans nécessairement la modifier.

36

À des fins d'illustration, le tableau 1 présente l'alignement des concepts d'Hera vers des équivalents dans d'autres modèles. Ce ne sont que des exemples : l'alignement est libre et se décide au moment de l'implémentation de chaque connecteur.

<table><caption>Tableau 1. Équivalences entre les concepts d'Hera et ceux d'autres modèles : tableurs (CSV), bases relationnelles (SQL), bases de données orientées documents (NoSQL), programmation orientée objet (POO), services Web RESTful (REST), triplestores (RDF)</caption><thead><tr><th>Hera</th><th>CSV</th><th>SQL</th><th>NoSQL</th><th>POO</th><th>REST</th><th>RDF</th></tr></thead><tbody><tr><td><strong>propriété</strong></td><td>colonne</td><td>champ</td><td>clé</td><td>type</td><td>URI</td><td>prédicat</td></tr><tr><td><strong>métadonnée</strong></td><td>valeur</td><td>cellule</td><td>valeur</td><td>valeur</td><td>ressource</td><td>objet</td></tr><tr><td><strong>élément</strong></td><td>ligne</td><td>record</td><td>document</td><td>objet</td><td>ressource</td><td>sujet</td></tr><tr><td><strong>entité</strong></td><td>fichier</td><td>table</td><td>-</td><td>classe</td><td>entité</td><td>classe</td></tr><tr><td><strong>attribut</strong></td><td>colonne</td><td>champ</td><td>-</td><td>attribut</td><td>URI</td><td>propriété</td></tr></tbody></table>

37

Au moment de l'écriture de cet article, Heimdall était disponible pour les écosystèmes XQuery<sup>20</sup> (Witz, Porte et Van Kote 2024) et Python<sup>21</sup> (Witz 2024b). Les deux cas concrets suivants permettent de mieux envisager les bénéfices du schéma Hera et de sa première manifestation concrète, Heimdall.

38

Estrades<sup>22</sup> est une plateforme de soutien à la recherche autour de l'édition numérique de corpus. Entre autres, Estrades peut tirer le meilleur parti, non seulement de corpus textuels au format TEI, mais aussi de bases de données relationnelles renfermant davantage d'informations sur
les entités nommées auxquelles les fichiers TEI font référence. C'est initialement pour pallier les limitations du logiciel de bases de données dont dépendait à l'époque la chaîne de traitement d'Estrades qu'a été créé Heimdall. Grâce à Heimdall, et donc à la modélisation permise par Hera, le périmètre d'action d'Estrades s'est rapidement élargi, puisque la réutilisation de certaines bases de données, auparavant inenvisageable, était dorénavant aisée.

Chi-Know-Po<sup>23</sup> porte sur l'articulation entre les domaines de la poésie et du savoir dans la Chine médiévale. Une partie de la base de données s'appuie sur Estrades et a donc profité des bénéfices cités ci-dessus. L'autre partie des données de Chi-Know-Po nécessitait une migration vers un serveur mis à disposition par l'infrastructure de recherche Huma-Num<sup>24</sup>. Dans le cadre de cette migration, sont apparues certaines questions de sécurité liées au mode d'accès à ladite base par des *notebooks* Jupyter<sup>25</sup>, développés en Python. Le portage d'Heimdall vers Python a permis à la base Chi-Know-Po de l'utiliser dans ses *notebooks*, afin de continuer à exister conformément aux prérequis de sécurité établis par Huma-Num. En bonus, ce travail a permis à Heimdall d'être directement accessible aux communautés utilisatrices de Python.

39

## Discussion

Cette partie liste les caractéristiques les plus évidentes d'un écosystème de recherche basé sur une façade. Il est précisé lorsque certaines d'entre elles sont propres à Hera ou à Heimdall.

40

Lorsqu'un nouveau connecteur exportant une base de données dans un format compatible avec la façade est développé, toutes les bases de données déjà compatibles peuvent y accéder. Le corollaire est vrai : un nouveau connecteur capable d'importer ses données avec la façade obtient un accès à toutes les bases de données déjà compatibles avec ce format, ainsi qu'à celles qui seront compatibles dans le futur, sans effort de développement ou de maintenance supplémentaire.

41

La modularité intrinsèque de ce type d'écosystème en favorise la pérennité. Premièrement, si le schéma ou la technologie d'un élément de l'écosystème évolue, cela n'a aucun impact sur les autres : de l'extérieur, toutes ces spécificités sont abstraites par la façade. Deuxièmement, au cours du temps, certaines bases de données ou formats de l'écosystème disparaîtront et les connecteurs concernés deviendront alors inutiles. Mais là encore, cela n'hypothèquera théoriquement en rien l'existence des autres éléments de l'écosystème, qui pourrait même continuer à grandir si le rythme de création de nouvelles connexions est supérieur au rythme de mort de certains projets. De plus, un projet producteur de données facilement accessibles à travers une façade a une chance accrue qu'un autre projet reprenne ces données à son compte. Par conséquent, si infrastructurellement parlant, un projet disparaît, cela ne signifie pas forcément la disparition des connaissances scientifiques qu'il renfermait.

42

En tant que spécification d'interface commune, une façade ne souffre d'aucun problème d'échelle. Premièrement, créer davantage d'éléments compatibles n'a aucun impact sur le reste de l'écosystème. Donc, si la spécification d'une façade servant à un petit écosystème local s'avère pertinente pour d'autres projets de recherche extérieurs à son périmètre, elle pourrait être réutilisée en l'état. Deuxièmement, puisqu'une façade est fondamentalement destinée aux données d'un écosystème particulier, elle peut ne pas être appropriée à un autre. Pourtant, si on crée un connecteur

43
entre une première façade « locale » et une seconde à la spécification différente, toutes les bases de données de la première seront théoriquement accessibles à la seconde et ce, sans avoir à respécifier aucune des deux façades.

Il peut être utile de préciser à nouveau que ces deux avantages sont propres à une façade en tant que spécification. Un serveur qui mettrait quantité de données hétérogènes à disposition de nombreux clients à travers la même interface (et qui serait donc, de fait, l'implémentation d'une façade) aurait évidemment à relever les mêmes défis infrastructurels que tout serveur de haute performance ou soumis à une demande forte.

Les cinq concepts présentés plus tôt dans cet article forment la base de la spécification que constitue Hera. Ils constituent une abstraction conceptuelle presque absolue. En effet, comme l'a démontré la partie précédente, grâce à elle, Heimdall est capable d'aligner ces concepts avec ceux de tous les types de bases de données actuels et, théoriquement, futurs. Cela est possible tout simplement car ces concepts sont largement partagés, sous un nom ou un autre, dans le monde des bases de données. Hera ne fait que les nommer de la même manière, en ajoutant une couche de flexibilité et d'identifiants sémantiques indispensables pour rendre la recherche accessible et réutilisable selon les critères actuels.

Lors des activités de structuration d'un corpus en début de projet de recherche, ou durant les formations en humanités numériques portant sur les bases de données, parti est souvent pris d'utiliser assez tôt un logiciel en particulier. Cette attitude a des avantages mais comporte aussi le risque de rendre les utilisateurs dépendants de cet outil et désarmés lorsqu'il leur est nécessaire de transférer leurs connaissances à un autre contexte d'utilisation, par exemple un autre logiciel. À terme, une formation pratique mais insuffisamment théorique peut paradoxalement contribuer à rendre le numérique intimidant et, parfois, épuisant. Qui n'a jamais eu la sensation de devoir constamment s'adapter et réapprendre des notions qu'elle ou il croyait maîtriser ? Et qui n'a jamais regretté un choix technique, parfois choisi par défaut ?

De par la « pureté » de ses concepts, Hera constitue un outil mental utile aux activités de modélisation, notamment exploratoires ou pédagogiques. Concevoir une base de données scientifique peut se faire de manière détachée de toute contrainte technique et de toute (mé)connaissance d'un outil. Cela permet d'avoir davantage conscience de ce qui est conceptuellement nécessaire ou non pour un projet donné et de choisir dans un second temps, de manière éclairée, la technologie satisfaisant le mieux ce besoin. Si, par la suite, ce besoin devait évoluer, Hera et Heimdall permettent l'interopérabilité avec un grand nombre de logiciels de bases de données différents, afin de ne pas enfermer chercheurs et chercheuses dans leurs choix. Cela contribue à atténuer les biais d'utilisation des logiciels et à offrir à la recherche la flexibilité dont elle a besoin.

La modélisation d'Hera permet théoriquement de représenter n'importe quelle donnée et de la convertir dans n'importe quel format pertinent, mais cela ne signifie aucunement que tous les projets devraient utiliser cette modélisation. En effet, certaines bases de données ont besoin de performances élevées, ce qu'Hera ne permet pas forcément. Par exemple, un flux de données constamment actualisé nécessitera probablement une infrastructure technique et une représentation des données, dédiées à ses impératifs de performance, et à eux seuls. Hera pourra par contre offrir une interface générique pour extraire ou analyser une partie de ces données, de manière asynchrone, par exemple.

44

45

46

47

48
Cet article ne prétend aucunement qu’Hera devrait remplacer les standards internationaux, présents ou futurs. Il ne s’agit que d’une alternative pour spécifier une façade, et ce n’est certainement pas la seule ²⁶. Ce n’est qu’une modélisation qui a fait ses preuves à l’échelon local et qui est donc potentiellement utile ailleurs. Les standards souffrent généralement tous du même prérequis : leur hypothèse est que tous les projets devraient dépenser du temps pour les suivre. Or, les projets scientifiques ne disposent généralement pas de ce temps. En effet, implémenter un nouveau standard n’est pas toujours facile, lorsqu’il faut composer avec un existant, un historique. À l’inverse, Hera ne demande rien à personne. Adapter son schéma au standard du jour sera fait tant qu’Hera sera utilisé et tous les projets pourront en bénéficier. Suivant la technologie supportant votre base de données, un connecteur correspondant à votre situation existe peut-être déjà. En faisant le choix de l’ouverture et de la mutualisation, Hera peut contribuer à rendre les standards internationaux utilisables à moindre effort, par des équipes peu dotées.

Le cœur de la modélisation d’Hera est si abstrait qu’il aura probablement peu besoin d’évoluer, tant que les concepts sous-jacents aux bases de données informatiques n’évolueront pas ²⁷. Bien sûr, certaines fonctionnalités pourraient être ajoutées avec le temps mais, si celles-ci sont pensées afin d’être optionnelles, elles seront rétrocompatibles. En cela, Hera pourra rester versionless ²⁸. En conséquence, l’existence prolongée d’un connecteur devrait nécessiter une maintenance très faible, voire nulle, suivant la manière dont il est développé et la base de données qu’il connecte.

Une grande partie des connecteurs proposés par Heimdall est parfaite-ment réutilisable et mutualisable, en partie grâce à leur méthode de dév-lopptom à faible maintenance. Par exemple, le connecteur permettant d’exporter n’importe quelle base en dump SQL peut être réutilisé facile-par tous les projets basés sur une implémentation SQL, sans qu’au-cun développement supplémentaire ne soit nécessaire.

Dans certains cas, cela n’est malheureusement pas vrai : par exemple, un connecteur important les données d’une API REST spécifique est rare-ment réutilisable en l’état pour interroger une autre API, les schémas des différentes API REST étant aujourd’hui encore souvent assez dissem-blables. Par contre, s’inspirer de la manière dont a été implémenté un connecteur basé sur la technologie dont un projet a besoin peut grandement accélérer la phase de compréhension de cette technologie et d’implé-mentation d’un nouveau connecteur par les membres du projet.

Même si elles ne sont que techniques, ces facilités dégagent davantage de temps pour les étapes de réflexion scientifique. Et cela est possible car Hera et Heimdall sont partagés sous licences libres. Ils sont donc aussi transparents, réutilisables et modifiables qu’il est possible.

Il n’y a rien d’obligatoire dans la manière dont ont été pensés Hera et Heimdall. Ils constituent une facilité mais qui reste facultative et qui a une incidence la plus faible possible sur les projets existants. Il peut n’y avoir aucune action nécessaire, ni pour développer un connecteur, ni pour en modifier le schéma. Cette technique architecturale peut être mise en œuvre à n’importe quel stade de maturation d’un écosystème de recherche. Elle est particulièrement adaptée aux écosystèmes protéi-formes, aux besoins potentiellement changeants et parfois inattendus. L’ensemble offre une flexibilité qui favorise sa pertinence sur la durée, une ouverture qui est un gage d’accessibilité et qui facilite l’innovation, et une sobriété qui est un élément de pérennité.
55

# Conclusion

Cet article a proposé une manière éprouvée d'organiser conceptuellement des écosystèmes de bases de données de recherche. Articuler chaque écosystème autour d'une ou plusieurs façades lui permet d'être plus évolué, en cloisonnant les îlots de complexité technique. La modélisation proposée, Hera, ainsi que son implémentation concrète, Heimdall, sont pensées de manière pragmatique.

56

Adopter de telles solutions basées sur l'ouverture, l'accessibilité, la sobriété, la mutualisation et la pérennisation des logiciels et des compétences, permet d'atteindre une forme de résilience pour la recherche.

## CONTRIBUTIONS

* Régis Witz : conceptualisation, recherche, méthodologie, administration du projet, développement informatique, supervision, validation (principal), visualisation, rédaction – version originelle, rédaction – révision et correction (principal)

* Guillaume Porte : validation (en appui), rédaction – révision et correction (en appui)
(Contributor Roles Taxonomy, Credit)

# Bibliographie

ANR (Agence nationale de la recherche). 2022. « Les coûts admissibles (dépenses éligibles) ». Fiche Règlement financier n° 3 – V3. Paris : ANR. https://anr.fr/fileadmin/documents/2023/ANR-RF-Fiche-COUTS-2023.pdf.

DINSIC (Direction interministérielle du numérique et du système d'information et de communication de l'État). 2015. « Référentiel général d'interopérabilité ». Version 2.0. Paris : DINSIC.

Fowler, Martin. 2010. « Richardson Maturity Model. Steps Toward the Glory of Rest ». martinfowler.com (blog). https://martinfowler.com/articles/richardsonMaturityModel.html.

Gamma, Erich, Richard Helm, Ralph Johnson et John Vlissides. 1994. *Design Patterns. Elements of Reusable Object-Oriented Software*. Boston : Addison-Wesley.

Gruber, John. 2004. « Markdown : Syntax ». Daring Fireball (blog). https://daringfireball.net/projects/markdown/syntax.

Hohpe, Gregor et Bobby Woolf. 2003. *Enterprise Integration Patterns. Designing, Building, and Deploying Messaging Solutions*. Boston : Addison-Wesley.

Hyde, Adam. 2018. « What's Wrong With Markdown ? » adamhyde.net (blog). https://www.adamhyde.net/whats-wrong-with-markdown/.

Kellerer, Thomas. 2023. « DBMS Comparison ». SQL Workbench. https://www.sql-workbench.ch.eu/dbms_comparison.html.

Richardson, Leonard. 2008. « Justice Will Take Us Millions of Intricate Moves. Act Three : the Maturity Heuristic. QCon, San Francisco, 19-21 novembre ». Crummy. https://www.crummmy.com/writing/speaking/2008-QCon/act3.html.

Shafranovich, Yakov. 2005. « Common Format and MIME Type for Comma-Separated Values (CSV) Files (RFC 4180) ». Internet Engineering Task Force (IETF). https://www.ietf.org/rfc/rfc4180.txt.

Witz, Régis. 2024a. « Hera ». Zenodo. 7 février. https://doi.org/10.5281/zenodo.12795179.

Witz, Régis. 2024b. « pyHeimdall ». Zenodo. 24 décembre. https://doi.org/10.5281/zenodo.12795207.

Witz, Régis, Guillaume Porte et Elsa Van Kote. 2024. « xHeimdall ». Zenodo. 13 février. http://doi.org/10.5281/zenodo.10665319.
## Notes

1. Le langage SQL permet d'interagir avec de nombreux systèmes de gestion de bases de données relationnelles. Malgré quelques variations locales, la syntaxe SQL est supportée par des systèmes tels que PostgreSQL, MariaDB ou SQLite. https://sql.sh.

2. CSV est un format d'échange de données tabulaires. Il est disponible comme format d'import et d'export dans la plupart des tableurs. Très utilisé empiriquement par de nombreux utilisateurs et logiciels à travers le monde, il n'a cependant jamais été réellement spécifié, peut-être justement car il est si utilisé. C'est un exemple de situation où, même pour les formats de données, l'usage peut l'emporter sur la règle.

3. Spécifications d'OpenDocument : https://docs.oasis-open.org/office/OpenDocument/. OpenDocument est un format de données ouvert pour, notamment, les tableurs, traitements de texte et présentations de la suite LibreOffice (ODT, ODS...). Rappelons qu'en France, OpenDocument est recommandé par le référentiel général d'interopérabilité (RGI) de la fonction publique (DINSIC 2015), contrairement aux formats privateurs com-mis par Microsoft pour sa suite bureautique (DOCX, XLSX...), basés sur OOXML.

4. XML est un format d'échange ancien et des plus utilisés. Il sépare les données des méta-données, qu'il représente par des attributs. Le format XML peut quasiment tout représen-ter, au prix d'un poids syntaxique parfois élevé comparativement à la sémantique associée. La spécification originale de XML (version 1.0) est disponible à cette adresse : https://www.w3.org/TR/xml/.

5. JSON est un format d'échange de données basé sur le langage de programmation Java-Script. Ce format se voulait à l'origine une alternative plus légère au XML, au prix d'un périmètre fonctionnel plus faible. https://www.json.org.

6. YAML est un format d'échange de données dont la syntaxe se veut human-friendly. Sa syntaxe est encore plus légère que celle du format JSON. JSON peut être considéré comme un sous-ensemble du YAML, ce qui rend la syntaxe YAML la plus robuste des deux, fonc-tionnellement parlant. https://yaml.org.

7. RDF est un modèle d'échange de données à la base du Web sémantique. Au cœur de cette spécification, il y a la notion de triplets RDF, de la forme « sujet, prédicat, objet ». https://www.w3.org/RDF/.

8. Dans un contexte de bases de données, le terme « schéma » désigne l'organisation logique des données d'une base. Il s'agit de la manière dont les données qu'elle contient sont modélisées.

9. La mouvance NoSQL désigne plusieurs catégories de bases de données « pas forcé-ment » relationnelles. MongoDB ou CouchDB en sont des exemples, même si la définition de NoSQL reste relativement floue.

10. Markdown est une syntaxe d'écriture de textes simples créée par John Gruber (2004).

11. ReStructuredText (RST) est un langage de balisage pour l'écriture de documentations. Si on le compare, par exemple, au Markdown, ses possibilités sont bien plus vastes et standardisées. Pour un aperçu de sa syntaxe : https://www.sphinx-doc.org/en/master/usa ge/restructuredtext/basics.html. RST est notamment utilisé dans l'écosystème du langage de programmation Python.

12. Un système de gestion de contenu (Content Management System ou CMS en anglais) est un logiciel permettant de créer un site Internet grâce à une interface graphique. Par exemple, Omeka (https://omeka.org) est un CMS spécialisé dans la publication sur le Web de collections scientifiques. WordPress (https://fr.wordpress.org) est, quant à lui, un des CMS les plus utilisés dans le monde. Il a parfois mauvaise presse, en partie à cause de ses limitations intrinsèques, mais aussi car les sites WordPress sont si nombreux que, statis-tiquement, une grande partie « pourrit » pendant des années, faute de maintenance.

13. Les Requests for Comments (RFC) sont des spécifications techniques et des recommandations pratiques. L'Internet Engineering Task Force (IETF), un organisme de normalisation à l'origine notamment de la plupart des standards d'Internet, est une des plus importantes sources de RFC. https://www.ietf.org/process/rfcs/.

14. TEI est en fait un schéma représentable dans plusieurs langages, pour représenter les textes sous forme numérique. Travailler en XML n'est théoriquement qu'une des possibilités. https://tei-c.org.

15. Voir les TEI Guidelines : https://tei-c.org/guidelines/customization/.
16 Voir : https://cidoc-crm.org ; https://www.bnf.fr/fr/modeles-frbr-frad-et-frsad/ ; https://www.w3.org/2004/02/skos/ ; https://opentheso.huma-num.fr ; https://www.dublincor.org ; https://schema.datacite.org.

17 L'article parle ici de qualité dans un contexte d'ingénierie logicielle. Pour des exemples de critères d'appréciation de la qualité logicielle, voir la norme ISO/IEC 25010 et ses dérivées.

18 Pour davantage d'explications sur les patrons de conception, en particulier sur la façade : https://refactoring.guru/fr/design-patterns/facade/.

19 Cette section de l'article reprend une partie de la spécification technique d'Hera, dont l'URL est indiquée dans le dépôt cité en bibliographie (Witz 2024a).

20 Au moment d'écrire cet article, seul l'environnement BaseX (https://basex.org) était explicitement supporté par xHeimdall, la version XQuery d'Heimdall.

21 Python est un langage de programmation très connu et très puissant. https://www.python.org.

22 Estrades (Solutions de transcription, d'analyse et de diffusion pour l'édition structurée) : https://estrades.huma-num.fr.

23 Chi-Know-Po (Chinese Knowledge in Poetry) : https://chiknowpo.hypotheses.org.

24 https://www.huma-num.fr.

25 Un notebook Jupyter est un format pour créer et partager des documents mêlant code et texte : https://jupyter.org.

26 Il est possible de trouver des guides d'implémentation de façades (ainsi que ceux d'autres design patterns servant à l'interopérabilité), par exemple du côté des EIP (Enterprise Integration Patterns, Hohpe et Woolf 2003) ou des ORB (Object Request Broker), avec des degrés variables d'utilisabilité en environnement de recherche. En pratique, la plupart des langages de programmation permettent l'operopérabilité ; tout dépend du besoin fonctionnel et des contraintes du projet.

27 À titre de comparaison, une telle évolution conceptuelle est survenue dans les années 2000 avec l'apparition de la mouvance NoSQL, qui a entraîné la création de nouvelles bases qui rompaient avec le modèle relationnel, dominant à l'époque. Avec Hera, passer du relationnel au non-relationnel a été aussi simple que de rendre optionnelle l'existence des entités et, donc, des attributs. Même dans les situations où le lien conceptuel entre éléments et entités n'existe pas, les éléments restent reliables à des ontologies scientifiques, puisque chaque métadonnée référence une propriété *a priori* standard et correctement documentée. Il est évidemment tout à fait possible d'avoir le raisonnement inverse, par exemple en implémentant un connecteur rendant accessible une base non relationnelle comme si elle était relationnelle dès le départ, potentiellement dans un objectif de performance, ou peut-être pédagogique.

28 Versionless ne signifie pas une absence de mise à jour, mais que les utilisateurs de la solution ne seront jamais affectés par une mise à jour s'ils ne le souhaitent pas. Ce terme de génie logiciel se rencontre surtout dans le cadre du développement d'API.

# Auteurs

## Régis Witz

UAR 3227 MISHA, CNRS, Strasbourg, France
Régis Witz est ingénieur informaticien, spécialiste des données. Sur la période 2023-2025, ses travaux portent sur l'interopérabilité des données de recherche en SHS, ainsi que sur l'empowerment et la résilience des réseaux de recherche.
ORCID 0000-0002-8064-0977
regis.witz@cnrs.fr

## Guillaume Porte

UMR 3400 Arche, université de Strasbourg, Strasbourg, France
Guillaume Porte est ingénieur d'études en analyse de sources et humanités numériques au sein du laboratoire Arche à l'université de Strasbourg. Ses travaux portent sur les bases de données en histoire et littérature, et sur l'édition numérique en XML-TEI. Il est le coordinateur de la plateforme Estrades.
ORCID 0000-0001-8656-8227
gporte@unistra.fr
## Droits d'auteur

<figure><img src="image_9.png" /></figure>

Le texte seul est utilisable sous licence [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.