Dans le secteur culturel et patrimonial, l’interopérabilité des données est un enjeu majeur. Le protocole OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) reste la norme incontournable pour exposer et moissonner des notices d’œuvres à grande échelle. Retour sur le fonctionnement technique sous le capot, son application sur le Portail des collections du musée du Louvre, développé et maintenu par Kernix depuis 2021, et les pièges d’implémentation à éviter pour un développeur.

Le défi de l’interopérabilité culturelle

Quand on gère le portail de collection ou un portail documentaire pour un musée ou une grande institution patrimoniale, la donnée est au cœur de tout. Des centaines de milliers (parfois des millions) de notices d’œuvres, d’archives ou de documents numérisés doivent non seulement être consultables par le grand public, mais aussi être partagées avec d’autres écosystèmes : agrégateurs nationaux (Ministère de la Culture, Gallica), internationaux (Europeana), portails de recherche ou partenaires institutionnels.

La tentation historique du développeur web face à ce besoin ? Créer une API REST ou GraphQL sur-mesure pour chaque partenaire. Le problème ? Multiplier les connecteurs propriétaires devient rapidement un enfer de maintenance, tant pour l’émetteur que pour les récepteurs.

C’est ici qu’intervient l’OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting). Bien qu’il ait fêté ses 20 ans, ce protocole reste la référence absolue de l’interopérabilité culturelle.

Chez Kernix, c’est une brique d’architecture que nous manipulons au quotidien pour garantir un échange de données robuste, standardisé et hautement performant.

Sous le capot de l’OAI-PMH : comment ça marche ?

L’OAI-PMH repose sur une architecture maître-esclave très claire qui permet de bien séparer les rôles :

• Le Data Provider (Entrepôt) : il détient la base de données source (ex: le CMS du musée ou le système de gestion des collections) et expose les métadonnées via le protocole.
• Le Service Provider (Moissonneur) : il envoie des requêtes HTTP au Data Provider pour récupérer (« moissonner ») les métadonnées et les intégrer dans son propre système (moteur de recherche, index global, etc.).

Des requêtes HTTP et des flux XML

Techniquement, pour entrer un peu plus dans le détail, le protocole OAI-PMH fonctionne via HTTP avec des requêtes en méthode GET ou POST. Le serveur répond toujours avec un flux XML structuré.

Le protocole ne comporte que 6 verbes d’action :

• Identify : renvoie les informations générales sur l’entrepôt (nom, version du protocole, adresse email du contact, politique de suppression).
• ListMetadataFormats : indique les formats XML supportés (le format Dublin Core / oai_dc est obligatoire, mais on peut supporter EDM, LIDO, etc.).
• ListSets : retourne la structure des ensembles (arborescence ou catégories d’œuvres) dans lesquels les données sont organisées.
• ListIdentifiers : ne liste que les en-têtes/identifiants des notices (pratique pour vérifier ce qui est à jour rapidement).
• GetRecord : récupère une notice individuelle précise via son identifiant unique.
• ListRecords : la commande reine. Elle permet de moissonner l’ensemble ou une partie des notices complètes de l’entrepôt.

Cas d’usage concret : le portail des Collections du musée du Louvre

Pour bien comprendre l’intérêt et l’exigence de l’OAI-PMH, prenons l’exemple du travail que nous menons actuellement chez Kernix sur l’architecture et les évolutions du portail des Collections du musée du Louvre (https://collections.louvre.fr).

Ici, le défi de l’interopérabilité est total. Le portail ne se contente pas d’une source unique, mais doit consolider des données provenant de deux bases de gestion métiers distinctes :

• Museum Plus, qui documente la grande majorité des départements (Antiquités, Peintures, Sculptures, Objets d’art…).
• Arts graphiques, une base spécifique consacrée aux dessins, gravures et estampes.

Le rôle de Kernix a été de concevoir l’architecture d’import (ETL) capable de moissonner, de transformer et d’harmoniser ces données brutes, fournies dans des formats et des structurations non identiques (JSON, XML). C’est cette base de données consolidée et structurée par nos équipes qui alimente ensuite l’entrepôt OAI-PMH, garantissant une exposition fluide et standardisée des notices d’œuvres vers le monde extérieur.

Sur un projet de cette envergure, le volume de notices à exposer se compte en centaines de milliers d’œuvres. L’enjeu de l’OAI-PMH pour le Louvre est double :

• Permettre aux organismes tiers d’extraire les données de manière automatisée et normalisée sans surcharger la base de données principale du portail.
• Gérer le moissonnage incrémental grâce aux paramètres from et until. Un moissonneur externe n’a pas besoin de re-télécharger toute la collection chaque nuit : il demande simplement « donne-moi uniquement les notices modifiées depuis hier à 00h00 ».

Voici un exemple simplifié d’un extrait de réponse XML en sortie de l’API OAI-PMH que nous générons :

<!-- Exemple de structure XML OAI-PMH (Dublin Core) -->
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/">
  <responseDate>2026-07-21T10:00:00Z</responseDate>
  <request verb="GetRecord" identifier="oai:louvre.fr:ARK-12345" metadataPrefix="oai_dc">https://collections.louvre.fr/oai</request>
  <GetRecord>
    <record>
      <header>
        <identifier>oai:louvre.fr:ARK-12345</identifier>
        <datestamp>2026-07-20T14:30:00Z</datestamp>
      </header>
      <metadata>
        <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/">
          <dc:title>Portrait de Lisa Gherardini, épouse de Francesco del Giocondo, dite La Joconde ou Monna Lisa</dc:title>
          <dc:creator>Léonard de Vinci (Leonardo di ser Piero da Vinci)</dc:creator>
          <dc:type>Peinture</dc:type>
          <dc:date>1503 - 1519</dc:date>
          <dc:identifier>https://collections.louvre.fr/ark:/53355/cl010062370</dc:identifier>
        </oai_dc:dc>
      </metadata>
    </record>
  </GetRecord>
</OAI-PMH>

Mais pour l’exposition des données du musée du Louvre, l’entrepôt OAI-PMH que nous avons implémenté ne se contente pas du standard Dublin Core minimal (oai_dc). Il supporte également le format LIDO MC (Lightweight Information Describing Objects, profil Musées de France).

C’est un point crucial : LIDO est la norme internationale de référence pour l’échange de données de musées. En exposant ce format via l’OAI-PMH, le portail garantit une interopérabilité scientifique de haut niveau, permettant à des agrégateurs comme Europeana ou le Ministère de la Culture de récupérer des notices d’œuvres d’une richesse et d’une précision inégalées.

Les pièges techniques à éviter

Sur le papier, renvoyer du XML en HTTP à partir de 6 verbes semble simpliste. Dans la réalité d’un projet web d’envergure, l’implémentation de l’OAI-PMH comporte de véritables défis d’ingénierie backend.

La gestion fine des resumptionToken (Pagination)

Tenter d’envoyer 500 000 notices XML d’un coup, c’est le crash assuré du serveur. L’OAI-PMH résout ce problème avec un système de relais : le resumptionToken. Le serveur livre un premier paquet (par exemple 100 notices), accompagné d’un jeton unique qui permet au moissonneur de réclamer la suite.

Le piège classique pour un développeur, c’est de vouloir sauvegarder l’historique de ces requêtes en base de données ou en cache serveur. C’est le meilleur moyen de saturer sa mémoire pour rien. L’astuce sur des projets à très fort volume comme pour le portail de Collection du musée du Louvre, c’est de faire porter toute l’information de pagination à l’intérieur du jeton lui-même. Le serveur n’a plus rien à garder en mémoire entre deux requêtes, et le système peut encaisser des moissonnages massifs sans la moindre surchauffe.

Le mapping de données & la validation de schémas

Les bases de données métiers des musées sont souvent complexes, hautement structurées et possèdent parfois des champs personnalisés. Convertir ce modèle métier en un flux XML conforme aux schémas stricts (XSD) sans corruption de caractères UTF-8 ni perte d’informations requiert une rigueur absolue lors de la phase d’ETL (Extract, Transform, Load).

Stratégie de mise en cache & performance

Un moissonneur un peu trop gourmand peut vite alimenter l’API OAI-PMH de requêtes ListRecords. Sans couche de cache efficace (Varnish, Redis ou cache de requêtes HTTP), ces opérations de jointures SQL massives peuvent mettre à genoux la base de données principale. Séparer l’index d’exposition ou mettre en place un cache de rendu XML est indispensable.

La gestion des suppressions (deleted records)

Quand une notice est dépubliée ou supprimée au niveau de la source, comment l’indiquer aux agrégateurs ? L’OAI-PMH prévoit un statut status= »deleted » dans l’en-tête du XML. Cela implique que votre système conserve un historique léger (soft delete) des identifiants supprimés et de leur horodatage, faute de quoi les moissonneurs conserveront indéfiniment des données obsolètes.

Ce qu’il faut retenir !

L’OAI-PMH n’a rien d’un protocole poussiéreux : c’est la véritable colonne vertébrale du Web de données (Linked Open Data) dans l’écosystème patrimonial.

Réussir son implémentation ne se résume pas à installer une bibliothèque tierce. Cela nécessite une vraie réflexion d’architecture sur la modélisation des données, la gestion des volumétries et la résilience du système. C’est précisément cette double compétence, compréhension des enjeux métiers de la culture et maîtrise des contraintes de développement web à forte charge, que nous appliquons chez Kernix pour accompagner les institutions dans la valorisation de leur patrimoine numérique.

Vous avez un projet d’exposition de données, un chantier OAI-PMH à cadrer ou des flux à optimiser ?

Échangeons sur vos enjeux techniques et vos contraintes d’architectures de données, contactez-nous !