Migration et mise à niveau de DSpace : changer de plateforme ou de version sans casser les liens

Ce qui se migre, ce qui se reconstruit et ce qui se perd

Un dépôt n'est pas une simple base de données : ce sont quatre couches aux formats et aux risques différents. L'erreur de planification la plus courante consiste à chiffrer « la migration du dépôt » en ne pensant qu'aux métadonnées.

• Les métadonnées descriptives : la description de chaque item, généralement en Dublin Core qualifié. C'est ce qui voyage en XML ou en CSV et se met en correspondance champ par champ.
• Les fichiers (bitstreams) : le PDF de la thèse, le jeu de données, l'enregistrement audio. Dans DSpace, ils vivent dans l'assetstore et non dans la base ; ils pèsent lourd et se déplacent à part.
• La structure des communautés et collections : l'arborescence des facultés, des formations et des types de documents. Elle se reconstruit dans la destination avant tout chargement, car chaque item a besoin d'une collection d'arrivée.
• Les identifiants pérennes : les handles ou DOI déjà publiés. C'est la seule couche qui, si elle casse, casse aussi tout ce qui pointe vers le dépôt depuis l'extérieur.

D'autres éléments ne se migrent pas mais se reconstruisent : circuits de validation, groupes et droits, formulaires de dépôt, embargos (qui sont des politiques d'accès) et personnalisation graphique. Quant à l'historique des statistiques d'usage, stocké dans un cœur Solr et non dans la base, il ne se transfère que si l'origine est aussi DSpace ; sinon, on repart de zéro en archivant les anciens rapports.

Les identifiants pérennes : le point qu'on ne peut pas casser

DSpace attribue à chaque item un handle, un identifiant de la forme hdl.handle.net/préfixe/suffixe. Le préfixe est délivré à l'établissement par CNRI contre une redevance annuelle, et la promesse du système est que cette adresse continue de fonctionner même si le domaine, le serveur ou la plateforme changent. Si l'ancien dépôt a publié des identifiants cités dans des thèses, des articles et des CV, il faut les emporter, par l'une des deux voies suivantes, à choisir dès le début du projet.

• Transférer le préfixe : on organise avec CNRI la résolution du préfixe existant vers le nouveau serveur. C'est la solution propre, mais elle fonctionne en tout ou rien : le préfixe entier passe au nouveau dépôt et l'ancienne plateforme cesse de résoudre ses handles.
• Conserver l'ancien identifiant comme métadonnée et publier des redirections depuis les anciennes URL. C'est l'issue lorsque le préfixe appartient à un consortium ou à un prestataire qui ne le cède pas.

Si l'origine utilisait des DOI DataCite, l'opération est équivalente : mettre à jour l'URL cible de chaque DOI, un travail mécanique et massif mais obligatoire. Quand BiblioLabTech migre un dépôt, la vérification des identifiants est une tâche à part entière du calendrier, menée après la bascule sur un échantillon manuel et sur la liste complète ; les URL directes de l'ancien dépôt, elles aussi citées, sont redirigées.

Les formats d'entrée : ce que DSpace accepte

DSpace dispose de plusieurs portes d'entrée, chacune adaptée à un scénario.

Deux mises en garde reviennent dans presque tous les projets. Le ZIP envoyé par l'interface est limité à 2 Go par défaut : un dépôt de plusieurs milliers de PDF se charge par lots ou en ligne de commande. Et un CSV retouché dans Excel a de fortes chances d'arriver avec des accents cassés, car Excel gère mal l'UTF-8 et ajoute souvent une marque invisible en début de fichier. Mieux vaut le savoir avant de charger 12 000 notices qu'après.

Scénarios de migration : difficulté et ce qui se conserve

Toutes les migrations ne se ressemblent pas. Voici les six cas les plus fréquents.

Le dernier scénario paraît le plus simple et se chiffre donc souvent mal : la difficulté passe du code à l'établissement, qui doit décider de ce qui sera publié, obtenir l'autorisation des auteurs, définir les licences et surtout éviter que le dépôt naisse vide. Les dépôts officiellement actifs et presque sans contenu sont nombreux ; c'est précisément le problème réglé à l'Universidad Americana au Paraguay, où BiblioLabTech a intégré MetaExtract API au circuit de dépôt, pour que remplir le dépôt ne dépende plus de la saisie manuelle de chaque page de titre.

La méthode en sept étapes

Voici la séquence que nous suivons, et l'ordre compte. Sauter l'environnement miroir est le raccourci qui coûte le plus cher.

1. Inventaire de l'origine : combien d'items, de fichiers et de gigaoctets ; quel schéma de métadonnées et quelle version exacte du système ; accès à la base ou seulement à un export ; quels identifiants ont été publiés et qui contrôle le préfixe.
2. Mise en correspondance des métadonnées, champ par champ, vers le registre de DSpace. On décide ici ce qui va dans le Dublin Core standard et ce qui va dans le schéma local, où doivent vivre les champs propres pour qu'aucune mise à jour future ne les touche.
3. Conception des communautés et collections dans la destination, avec les types d'items, les formulaires de dépôt et les politiques d'accès déjà définis.
4. Chargement d'essai sur un environnement miroir, identique à la production, avec un lot pilote de 100 à 500 items représentatifs : une thèse sous embargo, un article à plusieurs auteurs, un item à cinq fichiers, un titre plein de caractères spéciaux et un item de chaque collection problématique.
5. Validation par l'équipe de la bibliothèque sur le vrai dépôt, pas sur un tableur : chercher par auteur, filtrer par facettes, ouvrir le PDF, vérifier que l'embargo bloque le téléchargement.
6. Chargement complet et gel : une date et une heure après lesquelles plus rien n'est déposé dans l'ancien système, le chargement intégral, le rapprochement des comptages (items par collection, fichiers par item, volume total) et la migration du différentiel saisi entre l'export et le gel.
7. Bascule et vérification des identifiants : on fait pointer le domaine, on ouvre le dépôt et on vérifie que handles et DOI résolvent, par échantillon manuel et par contrôle automatisé de la liste complète. C'est le dernier livrable, pas une tâche en suspens.

Côté délais, dans nos projets, une migration avec un export standard et une bibliothèque impliquée dans la validation demande quatre à dix semaines de travail effectif pour quelques milliers d'items. La qualité des métadonnées d'origine, le volume des fichiers et les décisions encore en suspens pèsent plus que le nombre d'items.

Mise à niveau de DSpace : passer de la version 6 ou 7 à DSpace 10

Ce n'est pas une migration entre plateformes, mais cela y ressemble, et le calendrier presse. La communauté ne maintient que les trois dernières versions majeures : depuis la sortie de DSpace 10.0, le 28 mai 2026, la branche 7.x n'est plus maintenue (sa dernière version est la 7.6.7) et les branches prises en charge sont 8.x, 9.x et 10.x. La procédure officielle de mise à niveau s'applique depuis n'importe quelle version antérieure, mais trois changements pèsent lourd.

Le saut d'interface

Depuis DSpace 7, les anciennes interfaces XMLUI et JSPUI ont disparu : tout le frontend est une application Angular indépendante du backend. Une personnalisation de thème réalisée sur XMLUI ne se migre pas, elle se refait. Il faut la budgéter comme du développement, pas comme de la configuration.

Le registre de métadonnées et les entités

DSpace 7 a introduit le modèle d'entités et de relations, qui stocke les liens dans une table dédiée. Aucun script ne convertit en bloc les anciens items en entités ; la recommandation, celle de la communauté comme la nôtre, est donc de découpler les deux projets : d'abord la mise à niveau technique avec les entités désactivées, ensuite l'adoption du modèle. Et l'on ne modifie jamais les schémas dc et dcterms. Gardez aussi en tête que DSpace 11, attendu pour mai ou juin 2027, remplacera les deux modèles de relations actuels, celui de DSpace et celui de DSpace-CRIS, par un modèle unifié, avec une procédure de migration prévue.

Les statistiques, les prérequis et la version cible

Les statistiques d'usage et le cœur d'autorités s'exportent et se réimportent explicitement ; les cœurs de recherche et d'OAI se reconstruisent par réindexation. Si les anciennes statistiques étaient fragmentées par année, prévoyez un travail supplémentaire, car les versions modernes ne gèrent plus ce découpage. Côté serveur, DSpace 10 exige Java 21, Maven 3.9 et Node.js 20.19 ou plus : une mise à niveau est souvent aussi un renouvellement de l'infrastructure, que nous détaillons dans notre guide de l'hébergement DSpace. Viser une branche sur le point de perdre son support, c'est payer deux fois le même travail.

Ce qui tourne mal le plus souvent

• Des handles cassés. Le dépôt s'ouvre, tout semble correct, et les citations publiées ne résolvent plus. C'est la seule erreur de cette liste qui pénalise des gens qui ne travaillent pas à la bibliothèque.
• Une sauvegarde incomplète avant la bascule : la base sans l'assetstore, ou l'inverse.
• Des accents cassés par un CSV passé par Excel, et des items sans fichier : la métadonnée est arrivée, le PDF non. Les deux se détectent en rapprochant les comptages, pas en survolant l'écran.
• Des embargos non transférés, qui publient en libre accès une thèse censée rester restreinte : l'erreur aux conséquences juridiques, d'où l'item sous embargo du lot pilote.
• Des collections inventées pendant le chargement au lieu d'être conçues avant : réorganiser l'arborescence avec 10 000 items à l'intérieur coûte bien plus cher qu'une réunion préalable.
• Un ancien système jamais gelé, et deux dépôts qui divergent pendant des semaines.

Après la bascule

Un dépôt migré n'est pas terminé le jour de son ouverture. Restent la visibilité, c'est-à-dire des contextes OAI-PMH conformes aux lignes directrices des agrégateurs (celles d'OpenAIRE en Europe, par exemple) et pas seulement un serveur OAI allumé, et l'infrastructure : où vit l'instance, avec quelle politique de sauvegarde et qui applique les correctifs.

Reste enfin une question stratégique. Si l'université doit répondre à des questions comme « qu'a produit tel chercheur ? » ou « qu'est-il sorti de tel projet financé ? », le dépôt de documents ne suffit plus et la discussion se déplace vers DSpace-CRIS. Mieux vaut poser la question avant de migrer, car la décision change la façon de modéliser les collections et les métadonnées d'auteur.

À l'Escuela Colombiana de Ingeniería Julio Garavito, le dépôt DSpace cohabite avec le catalogue Koha et le reste de la plateforme de la bibliothèque, parce qu'il a été pensé comme un système et non comme un achat isolé (voir l'étude de cas). Si vous devez migrer un dépôt et voulez une proposition qui inclut inventaire, mise en correspondance, environnement de test et vérification des identifiants, BiblioLabTech l'établit à partir des chiffres réels de votre fonds, depuis notre service DSpace. Pour situer le budget, consultez notre article sur le coût d'un dépôt DSpace, et pour les bases du logiciel, qu'est-ce que DSpace.