Proxy de bibliothèque : comment fonctionne l'accès distant aux ressources électroniques

Le problème : des ressources qui authentifient par adresse IP

Depuis des décennies, le moyen le plus simple pour les grands fournisseurs de bases de données académiques (des plateformes comme EBSCO, Scopus, JSTOR ou ProQuest) de contrôler l'accès à leur contenu consiste à vérifier l'adresse IP d'où arrive la requête. Si cette adresse appartient à la plage que l'université a déclarée comme « réseau du campus », l'accès est accordé sans autre question. Le mécanisme est commode tant que l'usager se trouve physiquement sur le campus, et totalement inopérant dès qu'il se connecte depuis chez lui, depuis un café ou depuis l'étranger lors d'un échange universitaire : son adresse n'est plus celle du campus, et le fournisseur le traite comme un inconnu.

L'accès distant résout précisément ce décalage, de deux manières techniquement différentes qu'il ne faut pas confondre.

Le modèle classique : le proxy inverse à réécriture d'URL

Le modèle le plus répandu, popularisé par EZproxy, un logiciel distribué par OCLC, fonctionne comme un proxy inverse à réécriture d'URL. La bibliothèque tient à jour une configuration qui liste l'adresse de chaque ressource sous abonnement. Lorsqu'un usager hors campus s'authentifie auprès du proxy, généralement avec ses identifiants institutionnels, le système réécrit chaque lien vers ces ressources pour qu'il passe par le serveur proxy. Du point de vue du fournisseur, la requête provient d'une adresse IP qui figure bien dans sa liste autorisée, celle du proxy et non celle de l'usager : il l'accepte. Le fournisseur ne sait jamais qui est la personne de l'autre côté ; il voit seulement une adresse qu'il reconnaît comme appartenant à l'université.

Avant de laisser passer l'usager, ce mécanisme peut l'authentifier de plusieurs façons : contre un fichier d'utilisateurs propre au proxy, contre un annuaire institutionnel, ou directement contre le système de gestion de la bibliothèque au moyen d'un protocole standard comme SIP2, qui vérifie le numéro de carte et le mot de passe du lecteur dans la même base que celle du prêt. La documentation d'EZproxy décrit d'ailleurs l'authentification par SIP et SIP2. C'est une manière de réutiliser une identité que la bibliothèque gère déjà, sans dupliquer les comptes dans un troisième système.

Le modèle fédéré : SAML, Shibboleth et OpenAthens

L'autre option, retenue notamment par de grandes bibliothèques universitaires, est l'authentification fédérée reposant sur le standard SAML, avec des solutions comme Shibboleth ou OpenAthens. Il n'y a ici aucun masquage d'adresse : l'usager se connecte avec son compte institutionnel, le même que pour sa messagerie ou son espace numérique de travail, et l'université atteste auprès du fournisseur, selon un standard d'identité fédérée, que cette personne est bien membre de l'établissement et a le droit d'accéder à la ressource. Le fournisseur ne voit pas une IP « de confiance » : il reçoit une assertion d'identité signée par l'université.

Ces échanges s'appuient souvent sur des fédérations d'identité nationales de l'enseignement supérieur et de la recherche. En France, la Fédération Éducation-Recherche opérée par RENATER référence ainsi des éditeurs comme ProQuest ou Cambridge University Press parmi ses fournisseurs de services ; au Canada, la Canadian Access Federation (CAF), opérée par CANARIE, permet aux étudiants et aux chercheurs d'accéder avec les identifiants de leur établissement à des bases de données de recherche et à des revues.

La différence n'est pas seulement technique. Le modèle à IP masquée est plus simple à déployer et n'exige pas que chaque fournisseur configure une intégration d'identité, mais il suppose d'entretenir des listes d'adresses et que l'usager pense à passer par la bonne porte. Le modèle fédéré est plus robuste, au prix d'une coordination d'identité plus exigeante entre l'université et chaque fournisseur. C'est la voie qu'a choisie Harvard : la Harvard Library a retiré son ancien service EZproxy le 31 mai 2026 au profit d'OpenAthens, avec une connexion par l'identifiant institutionnel de l'université.

Proxy de bibliothèque ou fédération d'identités : le comparatif

Dans la pratique, beaucoup d'établissements ne choisissent pas un modèle pur et font cohabiter les deux : le proxy sert les ressources qui n'acceptent pas encore SAML, la fédération celles qui l'acceptent déjà. Ce n'est pas un défaut de conception, c'est l'état réel du secteur, puisque tous les fournisseurs de bases de données ne migrent pas au même rythme.

Pourquoi l'accès distant devrait faire partie du métamoteur

C'est l'erreur de budget la plus fréquente que BiblioLabTech observe chez les bibliothèques qui montent leur projet : traiter le proxy comme une licence indépendante à chiffrer, installer et maintenir séparément du métamoteur, alors que l'usager ne veut qu'une chose. Il veut chercher et, si le résultat se trouve dans une base payante, y entrer sans friction, même depuis chez lui. BiblioMeta Académico intègre l'accès distant (proxy) au même service, et non dans un contrat à part : l'usager cherche dans le métamoteur de recherche, trouve le résultat dans une base sous abonnement, et le système règle l'accès distant dans le même parcours, sans réglage à faire ni adresse différente à retenir pour le « mode maison ».

Lorsque BiblioLabTech déploie cette brique pour une université, la première question n'est pas de savoir quel logiciel de proxy utiliser, mais contre quoi authentifier l'usager. Si l'établissement dispose déjà d'un annuaire institutionnel avec SSO, c'est là qu'on se connecte ; s'il dispose du système de gestion de la bibliothèque et de sa base de lecteurs, on passe par ce chemin. L'objectif est d'éviter d'imposer à l'université une nouvelle fédération d'identité uniquement pour obtenir l'accès distant, quand son système actuel règle déjà le problème avec moins de pièces en jeu.

Ce que la bibliothèque doit préparer

Trois éléments méritent d'être clarifiés avant une demande de devis :

1. L'inventaire réel des bases sous abonnement et du mode d'authentification que chaque fournisseur accepte : certains n'acceptent que l'IP, d'autres déjà SAML, beaucoup les deux.
2. La base d'utilisateurs de référence contre laquelle valider l'identité : le SIGB, un annuaire institutionnel, ou les deux.
3. Qui administre cette base, et à quelle fréquence elle est mise à jour. Un proxy qui valide contre un fichier de lecteurs périmé bloque des usagers légitimes, et c'est la cause la plus fréquente de tickets de support dans ce type de projet.

BiblioLabTech établit cet inventaire pendant la phase de diagnostic, avant tout devis, pour ne pas promettre une intégration d'un jour avec un fournisseur qui exige en réalité plusieurs semaines de coordination. L'accès distant fait d'ailleurs partie des facteurs qui font varier le prix d'un métamoteur, avec le nombre de sources à connecter, la complexité de chaque intégration et le niveau de personnalisation visuelle.

Un détail que peu de bibliothèques vérifient : le transit des identifiants

Quand l'authentification se fait contre le système de gestion de la bibliothèque, l'échange entre le proxy et le SIGB, c'est-à-dire le numéro de carte et le mot de passe du lecteur, doit circuler chiffré, et non en clair sur le réseau interne. C'est un détail d'infrastructure qui figure rarement dans une proposition commerciale et qui apparaît, trop tard, dans un rapport d'audit. Dans les projets de BiblioLabTech, ce chiffrement fait partie de la liste de contrôle de mise en service, avec la politique d'expiration des sessions et la vérification des données de l'usager qui parviennent réellement au fournisseur : la confidentialité des lecteurs n'est pas un détail dans une bibliothèque universitaire.

Ce que BiblioMeta Académico est, et ce qu'il n'est pas

Autant le dire avec la précision que l'on attend de tout fournisseur : BiblioMeta Académico n'est pas EZproxy et ne prétend pas l'être, pas plus qu'il n'est un service générique d'identité fédérée comme Shibboleth ou OpenAthens. C'est une couche d'accès distant intégrée au métamoteur, pensée à partir du cas d'usage des bibliothèques universitaires de taille moyenne avec lesquelles BiblioLabTech travaille en Amérique latine : authentifier contre ce que l'établissement possède déjà, sans ajouter un système de plus. Il ne prétend pas non plus remplacer l'architecture d'identité qu'une grande université a déjà déployée. Si votre établissement exploite une fédération SAML bien établie avec des dizaines de fournisseurs, la conversation n'est pas la même que pour une bibliothèque qui commence tout juste à traiter l'accès distant : il s'agit alors de connecter BiblioMeta Académico à cette fédération existante, et chaque projet est abordé en conséquence.

Pour comprendre comment le métamoteur relie ces bases entre elles, lisez notre guide du métamoteur de recherche pour bibliothèque. Pour voir ce que l'on peut construire au-dessus, comme la synthèse de sources avec citations, consultez le guide de l'assistant de recherche IA. Et pour chiffrer votre projet, écrivez-nous : le devis se fait sur votre inventaire réel de ressources et d'utilisateurs.