Hébergement DSpace : cloud géré ou serveur de l'établissement ?

Ce dont DSpace a besoin pour fonctionner

Depuis DSpace 7, la plateforme se compose de deux applications distinctes, qui peuvent vivre sur la même machine ou sur des machines séparées. Il faut le comprendre, car cela change la façon de dimensionner le serveur.

• Le backend : une application Java qui expose l'API REST. Elle se déploie traditionnellement dans un serveur d'applications comme Tomcat ; depuis DSpace 8, elle existe aussi sous forme de JAR exécutable qui embarque Tomcat, ce qui simplifie nettement l'exploitation. DSpace 10 exige Java 21 (le JDK complet), alors que les branches 8.x et 9.x tournent sur Java 17. Attention : depuis DSpace 8, le backend ne fonctionne plus avec Tomcat 9.
• Le frontend : une application Angular avec rendu côté serveur, exécutée sous Node.js (version 20.19 ou ultérieure, 22 ou 24 pour DSpace 10), qui consomme l'API. C'est elle que voit l'usager. Avec DSpace 10, son URL de base doit correspondre exactement à celle du backend, faute de quoi le rendu côté serveur et les redirections échouent.
• PostgreSQL : la base qui contient les métadonnées, les utilisateurs, les droits et les références aux fichiers (versions 14 à 17 pour DSpace 10). Jusqu'à la branche 9.x, l'extension pgcrypto devait être activée ; DSpace 10 n'exige plus de l'installer séparément, PostgreSQL 13 et suivants fournissant nativement ce dont il a besoin. PostgreSQL est le seul moteur de base de données pris en charge par les versions actuelles.
• Solr : le moteur d'indexation (Solr 9 pour les versions récentes), organisé en plusieurs cœurs dont quatre essentiels. search alimente la recherche et les facettes, oai l'exposition OAI-PMH, statistics les statistiques d'usage et authority le contrôle d'autorités. Les deux premiers se reconstruisent par réindexation ; les deux derniers non, car ce sont des données qui n'existent que là. La documentation officielle de DSpace 10 recommande de ne jamais exposer Solr sur Internet et de le placer derrière un pare-feu, DSpace ne gérant pas encore d'authentification vers Solr.
• L'assetstore : le répertoire où vivent les fichiers déposés. Il n'est pas dans la base de données et c'est presque toujours la partition qui grossit le plus.

C'est une pile plus lourde que celle d'un catalogue de bibliothèque. Aussi, quand BiblioLabTech met en œuvre DSpace pour une université, la question de l'infrastructure arrive dès la première réunion et non en fin de projet : elle conditionne les délais, le coût récurrent et la personne qu'on appelle quand quelque chose tombe en panne.

Le stockage : la différence qui surprend

La base de données d'un dépôt universitaire typique occupe quelques gigaoctets : ce ne sont que des métadonnées. Ce qui grossit, c'est l'assetstore, et il grossit vite, car chaque item apporte de vrais fichiers. Quelques ordres de grandeur pour budgéter : une thèse en PDF illustrée pèse entre 2 et 20 Mo, un article numérisé quelques Mo, un jeu de données ou une vidéo plusieurs centaines de Mo.

Conséquence pratique : le disque se dimensionne sur la croissance annuelle attendue des dépôts, et non sur le fonds actuel, en ajoutant l'espace des sauvegardes et des index. Pour un nouveau dépôt, la règle que nous appliquons est simple : estimer les gigaoctets de la première année, multiplier par trois pour couvrir la croissance et les sauvegardes, et exiger un stockage extensible sans migrer l'instance. Un dépôt qui manque de disque ne cesse pas seulement d'accepter des dépôts : il peut aussi arrêter l'indexation et laisser le moteur de recherche dépassé sans que personne ne s'en aperçoive.

Ne sauvegarder que la base de données : l'erreur la plus coûteuse

C'est le point le plus souvent mal résolu, y compris dans des établissements dotés d'une solide direction informatique. Avec DSpace, une sauvegarde complète, ce sont deux sauvegardes : l'export de PostgreSQL et une copie de l'assetstore. Ne sauvegarder que la base donne un dépôt qui démarre, affiche toutes les notices et ne peut livrer aucun fichier. Ne sauvegarder que les fichiers donne un dossier de PDF sans description, sans structure et sans droits.

Il existe en outre un ordre correct : d'abord la base, ensuite les fichiers. DSpace considère la base de données comme le registre de référence ; mieux vaut donc se retrouver avec un fichier sur le disque que la base ne connaît pas, invisible et inoffensif, qu'avec une notice dont le fichier n'existe pas, que l'usager trouve sans pouvoir la télécharger. En complément, DSpace sait exporter toute l'arborescence en paquets AIP fondés sur METS, qui réunissent métadonnées et fichiers. C'est plus cohérent mais plus lent et plus lourd : le plus raisonnable est de combiner les deux méthodes à des fréquences différentes.

Hébergement DSpace : cloud géré ou serveur interne, le tableau de décision

Aucun des deux modèles n'est meilleur dans l'absolu. Tout dépend de la capacité réelle de votre équipe informatique à prendre en charge un service de plus et de la rigueur de vos politiques de données.

Il existe un modèle intermédiaire qui fonctionne très bien dans les universités aux politiques de données strictes : le serveur appartient à l'établissement, physique ou dans son propre cloud, et le prestataire administre DSpace à distance. Les données ne quittent jamais le campus et l'exploitation est confiée à ceux qui connaissent la plateforme. C'est le modèle que BiblioLabTech applique quand le service informatique exige que la machine reste sous son contrôle. C'est aussi la réponse naturelle lorsque vos règles internes ou vos obligations de protection des données imposent que les données restent chez vous ; en Europe, par exemple, le RGPD encadre les transferts de données personnelles hors de l'Union européenne.

À l'autre bout se trouve le cas de l'Universidad Americana au Paraguay, dont le dépôt DSpace est hébergé et exploité par BiblioLabTech, avec HTTPS, sauvegardes automatiques et supervision. Pour une bibliothèque sans équipe d'infrastructure dédiée, ce modèle règle d'un coup la question de savoir qui applique le correctif du vendredi soir.

Nom de domaine, HTTPS et visibilité

Le dépôt doit vivre sur un sous-domaine de l'université, du type depot.votre-universite.fr, et jamais sur un domaine du prestataire. Ce n'est pas une question d'image : chaque item du dépôt sera cité, et si le domaine change avec le prestataire, toutes les URL publiées changent aussi. Techniquement, il suffit de faire pointer un enregistrement DNS.

Le certificat TLS doit se renouveler automatiquement, et DSpace 10 présente une particularité à vérifier avec le prestataire : le proxy, Apache ou Nginx, doit transmettre correctement l'en-tête Host, dont dépend le rendu côté serveur du frontend. Mal réglé, ce détail produit un dépôt qui fonctionne pour les humains mais reste invisible pour les moteurs de recherche.

Le même raisonnement vaut pour l'interopérabilité. Pour que le dépôt soit moissonné par les agrégateurs, comme OpenAIRE en Europe ou les réseaux régionaux ailleurs, le serveur OAI-PMH doit être publié, accessible de l'extérieur et conforme aux lignes directrices de métadonnées correspondantes. Pour Google Scholar, il faut en plus les balises de métadonnées que son robot sait lire. Un dépôt sans OAI exposé n'existe que pour ceux qui connaissent déjà son adresse.

Sauvegardes, disponibilité et SLA : ce qu'il faut écrire noir sur blanc

Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde. Voici les paramètres à faire figurer au contrat.

• Périmètre : base de données et assetstore. Si la proposition indique seulement « sauvegarde quotidienne », demandez explicitement si elle inclut les fichiers.
• Fréquence : une copie quotidienne de la base ; l'assetstore se prête à une sauvegarde incrémentale, puisque les fichiers déjà déposés ne changent pas.
• Rétention : 15 à 30 jours pour la base, et une copie mensuelle conservée plus longtemps pour les fichiers.
• Emplacement : hors du serveur de production. Une sauvegarde sur le même disque ne protège de rien.
• Test de restauration : au moins une fois par an, documenté, en restaurant les deux couches ensemble.
• RTO et RPO : combien de temps le service peut rester indisponible, et combien d'heures de dépôts on accepte de perdre dans le pire des cas.
• Disponibilité garantie : 99,5 % par mois représentent environ 3,6 heures d'indisponibilité mensuelle ; 99,9 %, environ 43 minutes.

Pour un dépôt, le RPO compte souvent plus que le RTO. Que le site soit indisponible deux heures est gênant ; perdre les dépôts d'une semaine de fin de semestre est un problème d'une autre nature.

Les questions à poser à un prestataire d'hébergement DSpace

• Quelle version de DSpace installez-vous, et à quel rythme appliquez-vous les versions de maintenance ? Depuis DSpace 10.0, les branches maintenues sont 8.x, 9.x et 10.x ; en octobre 2026, leurs dernières versions de maintenance étaient 8.5, 9.4 et 10.1, qui corrigent notamment des failles de sécurité.
• La sauvegarde inclut-elle l'assetstore en plus de la base, et dans quel ordre sont-elles prises ?
• Quel stockage comprend le forfait, combien coûte son extension et dans quel délai ?
• Le serveur est-il dédié à mon dépôt ou partagé avec d'autres établissements ?
• Quelle disponibilité mensuelle garantissez-vous, et que se passe-t-il si elle n'est pas tenue ?
• Si je pars, me remettez-vous l'export PostgreSQL et l'assetstore complet, dans quel délai et à quel coût ?
• Le nom de domaine, le certificat et, s'il existe, le préfixe Handle sont-ils au nom de l'établissement ?
• Le support couvre-t-il les questions d'usage du dépôt ou seulement les incidents d'infrastructure ?

La sixième question est la plus importante et la moins posée. DSpace est un logiciel libre et les données appartiennent à l'université : tout prestataire sérieux doit pouvoir remettre une copie intégrale des deux couches sans discussion. La septième a une conséquence moins visible : si le préfixe Handle est au nom du prestataire, en changer revient à casser toutes les citations publiées, un problème que nous détaillons dans notre guide de migration et mise à niveau de DSpace.

Quel modèle choisir

Choisissez le cloud géré si votre équipe informatique n'a pas la disponibilité nécessaire pour un service de plus, si personne dans l'établissement n'administre Java et PostgreSQL, si vous voulez un coût prévisible qui inclut la croissance du stockage, ou si le dépôt doit rester disponible en continu pour le moissonnage. À titre indicatif, dans les projets de BiblioLabTech, l'hébergement géré d'un dépôt DSpace se situe entre 600 et 2 000 USD pour douze mois, selon le stockage, la disponibilité garantie et la politique de sauvegarde.

Choisissez le serveur de l'établissement si votre politique exige que les fichiers restent sur le campus, si vous disposez déjà d'une infrastructure virtualisée avec des sauvegardes formalisées et du personnel formé, ou si le dépôt doit s'intégrer à des systèmes internes qui ne sont pas exposés à l'extérieur. Et envisagez le modèle mixte, serveur de l'établissement et administration externe, quand les deux conditions se croisent.

Dans les trois cas, le logiciel est le même et passer d'un modèle à l'autre reste possible : il s'agit de déplacer une base de données, un assetstore et quelques fichiers de configuration. Si vous envisagez d'ajouter la couche de gestion de la recherche, le dimensionnement change ; lisez notre article sur DSpace-CRIS. Pour le budget global, consultez le coût d'un dépôt DSpace, et si vous découvrez le logiciel, commencez par qu'est-ce que DSpace. Notre service DSpace chiffre toujours le projet avec et sans hébergement, précisément parce que la bonne réponse dépend de chaque établissement.