Hébergement Koha : cloud géré ou serveur de votre établissement ?

Ce que couvre réellement l'hébergement Koha

Quand une proposition annonce « hébergement inclus », cela devrait couvrir sept choses. S'il en manque une, son coût est simplement transféré à votre équipe interne.

1. Serveur et système d'exploitation : la machine virtuelle, son dimensionnement et les correctifs de sécurité du système.
2. La pile Koha : Perl et ses dépendances, MariaDB ou MySQL, le serveur web et le moteur d'indexation (Zebra ou Elasticsearch).
3. Domaine et certificat TLS : l'OPAC et l'interface professionnelle servis en HTTPS, avec renouvellement automatique du certificat.
4. Sauvegardes : copie de la base de données et des fichiers de configuration, avec une rétention définie et, surtout, des tests de restauration.
5. Supervision : alertes en cas de panne, de disque plein ou de processus d'indexation arrêté.
6. Mises à jour : application des versions de maintenance et planification des montées de version majeures.
7. Courriel sortant : Koha envoie les avis de retard, les avis de réservation disponible et les liens de récupération de mot de passe ; si l'envoi est mal configuré, ces fonctions n'existent pas en pratique.

Le courriel sortant est le point le plus sous-estimé. Un serveur fraîchement installé finit presque toujours dans les courriers indésirables du domaine institutionnel tant que les enregistrements d'authentification de l'expéditeur (SPF, DKIM) ne sont pas configurés.

Cloud géré ou serveur de l'établissement : 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 d'infrastructure à 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 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 Koha à distance. Les données restent stockées dans le périmètre de l'institution et l'exploitation est confiée à ceux qui connaissent le système. C'est le modèle qu'utilise BiblioLabTech quand la DSI veut garder la machine sous son contrôle. C'est aussi celui de l'Escuela Colombiana de Ingeniería Julio Garavito, dont le catalogue Koha tourne sur un serveur dédié de l'université administré par BiblioLabTech (étude de cas).

Quel serveur pour Koha selon la taille du catalogue

Koha est une application Perl sur MariaDB ou MySQL, avec un moteur d'indexation à part : il faut donc dimensionner deux consommateurs de mémoire, pas un seul. Voici les configurations qui fonctionnent en exploitation réelle, et non les minimums absolus d'installation :

Deux précisions sur le disque. La base de données d'un catalogue universitaire typique occupe quelques gigaoctets ; ce qui consomme de l'espace, ce sont les index, les sauvegardes accumulées et les fichiers joints comme les couvertures ou les PDF. Et le disque doit être un SSD : la réindexation complète d'un grand catalogue sur disque mécanique peut passer de quelques minutes à plusieurs heures.

Zebra ou Elasticsearch

Koha utilise Zebra par défaut, et ce moteur convient parfaitement à l'immense majorité des bibliothèques universitaires. Elasticsearch est l'alternative : il améliore les facettes, la pertinence et la tolérance aux fautes de frappe, mais relève nettement le plancher matériel, car c'est un service Java qu'il vaut mieux doter d'au moins 8 Go de mémoire pour lui seul, en plus de ce que consomment déjà Koha et la base de données.

La recommandation pratique : si votre collection compte moins de 100 000 notices et que personne ne se plaint de la recherche, restez sur Zebra. Elasticsearch se justifie pour un grand catalogue, une forte consultation simultanée ou des besoins de facettes que Zebra ne couvre pas. Le changement de moteur peut se faire à tout moment en modifiant la configuration et en réindexant : la décision n'est pas irréversible, mais elle n'est pas gratuite non plus.

Sauvegardes, disponibilité et SLA

Une sauvegarde jamais restaurée n'est pas une sauvegarde. Voici les paramètres à inscrire noir sur blanc dans le contrat :

• Fréquence : copie quotidienne de la base au minimum ; pour une circulation intense, copie quotidienne plus sauvegarde incrémentale.
• Rétention : entre 15 et 30 jours, ce qui est raisonnable pour une bibliothèque ; au-delà, le stockage coûte plus cher sans apporter grand-chose.
• Emplacement : hors du serveur de production. Une sauvegarde conservée sur le même disque ne protège de rien.
• Test de restauration : au moins une fois par an, documenté.
• RTO et RPO : combien de temps le service peut rester indisponible et combien d'heures de données on peut perdre au pire. Ce sont les deux chiffres qui comptent vraiment.
• Disponibilité garantie : 99,5 % par mois équivaut à environ 3,6 heures d'indisponibilité mensuelle ; 99,9 %, à environ 43 minutes. Choisissez selon le caractère critique de l'OPAC en période d'examens.
• Fenêtres de maintenance : convenues en dehors des heures d'ouverture et annoncées à l'avance.

Domaine, TLS et accès

L'OPAC doit vivre sur un sous-domaine de l'établissement, du type catalogue.universite.fr, et non sur un domaine du prestataire. C'est une question d'image et de continuité : si vous changez un jour de prestataire, le lien imprimé dans les guides et publié sur le site institutionnel continue de fonctionner. Techniquement, il suffit que l'établissement fasse pointer un enregistrement DNS vers le serveur.

Le certificat TLS doit se renouveler automatiquement. L'interface professionnelle gagne à être publiée sur un sous-domaine distinct de l'OPAC et, quand la politique de sécurité le permet, restreinte par réseau ou par VPN. Si l'établissement dispose d'un annuaire, Koha s'intègre à LDAP et Active Directory, ainsi qu'à CAS, SAML et aux fournisseurs OpenID Connect, ce qui évite de gérer un second jeu de mots de passe.

Hébergement Koha et RGPD

Un SIGB traite des données personnelles : identité et coordonnées des lecteurs, historique de prêt. Le choix d'hébergement se valide donc avec votre délégué à la protection des données (DPO). Koha fournit plusieurs outils utiles :

• un formulaire de consentement à la politique de confidentialité lors de la connexion à l'OPAC, obligatoire ou simplement informatif selon le réglage, avec un lien vers votre politique ;
• le verrouillage, l'anonymisation puis la suppression programmés des comptes des lecteurs qui refusent ce consentement, selon des délais configurables ;
• des règles de conservation de l'historique de prêt par catégorie de lecteurs et une anonymisation par lots qui préserve les statistiques ;
• des droits du personnel granulaires et un journal des opérations.

Côté hébergement, si votre politique impose que les données restent sur votre infrastructure, le modèle intermédiaire décrit plus haut, votre serveur administré à distance, répond à cette exigence. Dans tous les cas, l'intervention d'un prestataire se formalise par un contrat de sous-traitance au sens de l'article 28 du RGPD et, lorsque l'accès se fait depuis un pays extérieur à l'Union européenne, par les garanties prévues pour les transferts, comme les clauses contractuelles types de la Commission européenne. C'est le cas avec un prestataire comme BiblioLabTech, dont l'équipe intervient depuis la Colombie. Au Québec, la Loi 25 impose de son côté une évaluation des facteurs relatifs à la vie privée avant de communiquer des renseignements personnels hors de la province.

Les questions à poser à un hébergeur Koha

• Quelle version de Koha installez-vous, et à quel rythme appliquez-vous les versions de maintenance ?
• Le serveur est-il dédié à mon instance ou partagé avec d'autres bibliothèques ?
• Quelles sont la fréquence, la rétention et l'emplacement des sauvegardes, et quand a eu lieu le dernier test de restauration ?
• Quelle disponibilité mensuelle garantissez-vous, et que se passe-t-il si elle n'est pas tenue ?
• Quel est le délai de réponse pour un incident critique, l'OPAC en panne, par rapport à une demande ordinaire ?
• Si je pars, me remettez-vous l'export complet de la base de données et les fichiers de configuration, dans quel délai et à quel coût ?
• Le domaine et le certificat restent-ils au nom de l'établissement ?
• Le support couvre-t-il les questions d'usage du système, ou seulement les incidents d'infrastructure ?

La sixième question est la plus importante et la moins posée. Koha est un logiciel libre et vos données vous appartiennent ; la communauté Koha affirme d'ailleurs que les bibliothèques doivent rester libres de changer de prestataire et d'exporter leurs données à tout moment. Si la réponse est ambiguë, vous retrouvez la dépendance qui vous a peut-être fait quitter un système propriétaire. Ce que doit couvrir le support lui-même est détaillé dans notre article sur le support Koha.

Quel modèle choisir

Choisissez le cloud géré si votre équipe informatique n'a pas la disponibilité pour un service supplémentaire, si l'OPAC doit rester en ligne en continu, si vous voulez un coût prévisible ou si votre instance actuelle n'a jamais été mise à jour faute de personne pour s'en occuper ; ce dernier cas est traité dans notre guide de la mise à jour de Koha.

Choisissez votre propre serveur si votre politique exige que les données restent dans l'établissement, si vous disposez déjà d'une infrastructure virtualisée avec des sauvegardes formalisées et du personnel Linux, ou si Koha doit s'intégrer à des systèmes internes non exposés vers l'extérieur.

Dans les deux cas, le logiciel est exactement le même, et passer d'un modèle à l'autre reste possible : il s'agit de déplacer une base de données et quelques fichiers de configuration. Pour budgéter l'ensemble, consultez le coût de mise en œuvre de Koha. Le service Koha de BiblioLabTech se chiffre avec et sans hébergement, précisément parce que la bonne réponse dépend de chaque établissement ; dans les deux cas, BiblioScan AI, l'outil de catalogage MARC21 assisté par IA, est inclus sans surcoût.