Rappel du contexte

Dans le cadre du projet SGBm, un nouveau mode de coopération entre les établissements pilotes et l’Abes a été initié, basé sur un travail collaboratif dans l’intérêt des établissements, une coopération qui s’est prolongée jusqu’en 2020. Pour accompagner ces opérations, certains services de l’Abes ont évolué ou sont en cours d’évolution :  la  synchronisation des flux entre le Sudoc et les SGB en est un exemple.

Dans un premier temps, un circuit de synchronisation entre le Sudoc et la solution Alma proposé par la société Clarivate (ex ExLibris) a été conçu, testé puis mis en production en relation étroite avec les équipes des SCD des Universités de Bordeaux et de Toulouse, premiers établissements à intégrer ce circuit, en mai 2022 pour Bordeaux, en septembre 2022 pour Toulouse.

En 2022, la société DM Cultura et l’Université Polytechnique Hauts-de-France (UPHF) sollicitaient l’Abes afin d’adapter le circuit de synchronisation à l’environnement SGB Sebina (utilisant le résolveur de liens SFX). Fort de l’expérience de l’Abes en ce domaine et grâce à une collaboration fructueuse entre les trois parties, l’UPHF déployait son circuit de synchronisation fin 2023. 

Dès le début du projet de synchronisation, l’Abes a veillé à utiliser des outils standardisés et réutilisables par les établissements ayant d’autres fournisseurs. Cette solution, basée sur les échanges OAI-PMH et les transferts réguliers, a donc pu être appliquée avec succès au SGB Sebina. Précisons que la particularité du fournisseur Alma, qui utilise le format MARC21, a été traitée comme une spécificité, sans exclure l’usage de l’UNIMARC.

Comment fonctionne le circuit de synchronisation ?

Rappelons au préalable que le signalement optimisé des exemplaires de ressources électroniques ainsi que l’enrichissement et la qualité des données exposées constituent les principaux enjeux de la mise en œuvre d’un circuit de synchronisation.

Enrichir les bases de données des partenaires

Précisons tout d’abord que la présence de PPN (identifiants des notices Sudoc) dans les notices présentes dans les bases de connaissance constitue un préalable, indispensable à la synchronisation des exemplaires de ressources électroniques. Les flux de données, qui permettent d’enrichir respectivement la Zone communautaire Alma et la base de données Sebina, impliquent donc dans les deux cas l’injection des PPN dans les notices d’ebooks pourvues d’un ISBN.  

Pour ce faire, des exports réguliers ont été mis en place par l’Abes, selon un rythme hebdomadaire pour Sebina et mensuel pour Alma. Ces flux concernent plus de 400 000 références ISBN/PPN, soit la totalité des références à chaque extraction. Un fichier ISBN/PPN est utilisé afin d’enrichir les notices d’ebooks pourvues d’un ISBN mais dépourvues d’un PPN. 

Par ailleurs, un second flux de données a été activé afin de faciliter le chargement mensuel des bouquets disponibles dans BACON vers la base de connaissance de la Zone Communautaire Alma. Ce flux inclut les bouquets ajoutés dans BACON pendant le mois précédent, ainsi que les renommages et suppressions effectués.

Schéma de synchronisation pour le SGB Sebina (DM Cultura) 

Le schéma ci-dessus présente les différentes étapes du workflow de synchronisation entre le système Sebina et le catalogue Sudoc : 

1. Activation ou modification du portfolio dans la base de connaissance SFX de l’institution Sebina. Lorsqu’un portfolio est activé/modifié/désactivé/supprimé, il apparaît comme tel dans le rapport MARC-XML de mise à jour généré depuis l’interface d’administration de SFX. Ce rapport est déposé sur les serveurs de DM Cultura et une procédure automatique répercute ces modifications sur la base de Sebina. 
2. L’exemplaire ainsi créé/modifié/supprimé entre dans le circuit de synchronisation. Export des collections de SFX vers l’institution Sebina 
3. Pour les notices pourvues de PPN, les exemplaires sont exposés dans l’entrepôt OAI-PMH Sebina avec leur PPN
4. Le chargeur Sudoc moissonne l’entrepôt OAI-PMH puis convertit les exemplaires moissonnés au format d’exemplaire Sudoc, en respectant le mapping des données pour les fournir à l’API Catcher Sudoc
5. L’API Catcher se charge de la création de l’exemplaire dans le Sudoc. Un rapport de traitement quotidien est envoyé à l’établissement. 
6. Les notices bibliographiques exemplarisées sont renvoyées vers le système local dans le cadre des transferts réguliers. Le chargeur Sebina récupère les notices présentes sur le SFTP de l’Abes.
   

Schéma de synchronisation pour la Zone communautaire Alma

Le schéma ci-dessus présente les différentes étapes du workflow de synchronisation entre le système ALMA et le catalogue Sudoc : 

1- Activation ou modification du portfolio dans l’institution Alma :  l’activation du portfolio permet à l’inventaire de redescendre dans l’institution. Il n’entre dans le circuit de synchronisation que s’il valide trois conditions : 

• le portfolio doit appartenir à une sélection de ressources électroniques prédéfinie par l’établissement
• le portfolio doit être lié à une notice disposant d’un PPN
• le portfolio doit être lié à une notice au format MARC21, une contrainte imposée par la Zone communautaire dont les notices sont en MARC21. 

Ces portfolios sont exposés dans l’entrepôt OAI-PMH d’Alma. 

2- Le chargeur Sudoc moissonne l’entrepôt OAI-PMH puis convertit les portfolios moissonnés au format d’exemplaire Sudoc, en respectant le mapping des données pour les fournir à l’API Catcher Sudoc. 

3- L’API Catcher permet la création de l’exemplaire dans le Sudoc. Un rapport de traitement quotidien est envoyé à l’établissement. 

4- Un transfert régulier spécifique (TRE) en MARC21*  retourne la notice bibliographique de l’exemplaire créé. Le chargeur Alma récupère les notices mises à disposition sur le SFTP de l’Abes. 

*Les notices de documentation électronique de la zone communautaire étant au format MARC21, il est donc nécessaire de fournir en retour du Sudoc les notices au format MARC21 pour permettre la mise à jour des données en local. 

Un environnement technique dédié à la synchronisation

Des RCR dédiés 

Pour  signaler les ressources électroniques via le processus de synchronisation, chaque ILN doit au préalable créer un (ou plusieurs) RCR dédié(s), ce qui facilite le suivi des créations d’exemplaires dans le Sudoc. Il s’agit de RCR de type électronique (99) 

Le moissonnage des entrepôts OAI  

Les données de chaque entrepôt sont moissonnées quotidiennement par un programme JAVA, à une heure fixée en accord avec chaque établissement. Chaque exemplaire doit contenir au minimum :

• le statut de la donnée
• le PPN de la notice
• le RCR de localisation
• l’identifiant de l’exemplaire dans le système local :  Cet identifiant, stocké dans la zone 919 du format Sudoc, est la clé unique pour les mises à jour de l’exemplaire lors de la synchronisation

Les données sont alors transformées en format PICA+ –  format de stockage des données propre au CBS – grâce à un XSLT (mapping) . Elles sont ensuite stockées dans des tables Oracle puis récupérées par le catcher CBS pour permettre la création dans le Sudoc. 

En parallèle, une seconde table Oracle conserve l’historique de chaque donnée :

• identifiant
• PPN
• date de l’action
• date de l’exemplaire
• statut (create, delete, update)
• état (done, error, undo)
• type d’erreur. 

En résumé :

1 – Un job Oracle par ILN

2- Le job s’exécute tous les jours à l’heure précisée dans les paramètres

3- Le job enchaine moissonnage puis insertion CBS

Des données pour faciliter la synchronisation

Mapping des données 

Un premier mapping, élaboré en collaboration avec les universités de Bordeaux et Toulouse pour les données exposées dans les entrepôts des établissements Alma, n’étant pas exploitable pour les données d’un autre système, il a été décidé d’en concevoir un second, plus standard, basé sur les Recommandations de description des données d’exemplaire pour l’échange d’information bibliographique en format UNIMARC (Version 3 – Mai 2022. Éditées par le Comité français UNIMARC).

Ce mapping, utilisé pour la synchronisation avec le SGB Sebina, pourrait l’être également avec tout autre SGB. 

Création/mise à jour/suppression des exemplaires dans le Sudoc 

Statut ‘create’ et ‘update’ 

• L’identifiant local (ID) de l’exemplaire doit être fourni ainsi que son PPN, le RCR et la date de mise à jour. Cette dernière information évite que l’exemplaire ne boucle indéfiniment entre le CBS et le système local.  
• L’interrogation du CBS (comparaison de la date de l’exemplaire dans l’entrepôt OAI et dans le CBS) permet de sélectionner l’action adéquate : création ou mise à jour. 
• Un second test – calcul d’un ‘hash’ CBS comparé au ‘hash’ local – permet de vérifier que l’exemplaire est effectivement modifié et peut donc être rechargé dans le CBS.
• Les données d’exemplaires enregistrées au format ‘PICA+’ dans les tables Oracle sont soumises au programme CBS ‘catcher’, programme qui assure la création des exemplaires dans le CBS conformément aux paramètres enregistrés pour chacun des RCR. 

Précisons que les données sont soumises aux mêmes règles que le catalogage courant : table CBS de catalogage, table CBS de validation. Ainsi, toute erreur est enregistrée dans la table Oracle, récupérée via un webservice puis mise à disposition des établissements, les erreurs pouvant se situer  au niveau de l’exemplaire (absence d’une zone obligatoire) ou au niveau bibliographique (PPN non valide, problème de validation) 

Statut ‘deleted’ 

• L’entrepôt OAI ne fournissant pas les PPN des notices ayant le statut ‘deleted’, le moissonneur recherche dans la table Oracle un PPN pour l’ID et le RCR concernés puis envoie l’information au service CBS qui supprime l’exemplaire. 

En conclusion

Les circuits de synchronisation décrits dans ce billet constituent une proposition efficace et rationnelle à destination des gestionnaires de la documentation électronique. De la création des exemplaires dans le SGB au signalement dans le Sudoc,  la synchronisation automatique des exemplaires contribue à une réelle valorisation des données.

Plus d’informations

• Rendez-vous avec les experts 
• Format d’échange des données d’exemplaires pour la synchronisation Alma/Sudoc 
• Format d’échange des données d’exemplaires pour la synchronisation SGB/Sudoc (hors Alma) 
• Documentation ACEF : Synchronisation avec le Sudoc pour la documentation électronique 
• Documentation Abes : Synchronisation entre le Sudoc et le SGB Alma
• Documentation Abes : Synchronisation entre le Sudoc et le SGB Sebina
  

Ce billet constitue un post-mortem au sujet de l’incident qui a impacté l’application ITEM – pour la création ou la modification en masse d’exemplaires dans le Sudoc –  entre le 14 mars et le 4 avril 2024.

Symptômes et impact de l’incident

Dans un premier temps, l’incident a été signalé via le guichet AbesSTP, plusieurs utilisateurs ayant constaté que leurs demandes déposées via ITEM n’étaient pas traitées intégralement : à partir d’un certain moment dans le traitement du fichier, une erreur était levée, et le reste du fichier n’était pas traité correctement.

Pour contourner ce problème, certains utilisateurs ont tenté de relancer des demandes via ITEM en ne reprenant que les lignes non traitées, mais cette solution, bien que fonctionnelle, n’était pas satisfaisante et demandait, en outre, un certain temps pour reconstituer des fichiers.

Dans la mesure où l’application ITEM « écrit » dans la base Sudoc, afin de limiter les risques de corruption des données d’exemplaires dans le Sudoc, il a donc été décidé  de fermer l’accès à l’application, le temps de diagnostiquer l’origine du problème.

Fonctionnement d’ITEM et interactions avec le Sudoc : rappels

Pour fonctionner, l’application ITEM utilise AccesCBS, une librairie Java développée en 2010 par l’Abes  : simulant le comportement de WinIBW, ce programme gère la majorité des commandes présentes dans WinIBW, de la même façon que si une personne les activait à partir de son propre poste, mais de façon beaucoup plus rapide, tout en offrant la possibilité de lancer des traitements en masse.

Ainsi, lorsqu’une demande est en attente de traitement dans ITEM, AccesCBS est utilisé pour effectuer une série d’actions dans le Sudoc : authentification, recherche de la notice à modifier, passage de la notice en mode édition, validation de la modification, passage à la notice suivante.

Précisons qu’AccesCBS utilise le protocole réseau TCP/IP et le protocole Pica3 pour communiquer avec CBS, base centrale au coeur du Sudoc, exactement de la même manière que l’outil de catalogage WinIBW.

Analyses des causes de l’incident

Une première étape a consisté à tenter de reproduire le problème pour en déterminer la cause. L’équipe en charge de la maintenance d’ITEM a donc lancé différents traitements sur l’environnement de test, mais sans parvenir à reproduire le problème.

Devant cette impasse, un programme spécifique a été développé : il s’agissait de permettre la lecture d’un fichier et le lancement, sur la base de production du Sudoc, des mêmes commandes que celles d’ITEM,  mais sans  validation de ces modifications afin de ne pas modifier les notices utilisées pour ces tests. Lancé à de nombreuses reprises avec des jeux de données différents,  ce programme a été affiné au fur et à mesure afin d’obtenir un diagnostic le plus précis possible.

La série de tests – effectués tout d’abord à partir d’un poste local, puis à partir d’un serveur de l’Abes- a conduit aux constats suivants :

• Le bug ne se produit pas systématiquement et, qui plus est, pas forcément au même endroit dans un fichier (notion d’occurrence aléatoire).
• Selon les lancements, un même lot de notices peut être soit traité intégralement soit rencontrer un problème, ce qui ne permet pas de déterminer quel critère fait « planter » le programme.
• Le bug a tendance à se produire plutôt le matin entre 7h30 et 10h30.

Ce constat fait, des tests plus poussés ont été réalisés. Les éléments suivants ont été particulièrement surveillés :

• Charge des machines
• Activité sur le réseau
• Activité sur le CBS
• Journaux d’évènements du CBS
• Journaux d’évènements du programme développé en interne

Par ailleurs, AccesCBS utilisant le protocole TCP/IP, il a été décidé de surveiller le dialogue réseau entre le programme et le CBS pour déterminer si la communication était normale. C’est ce critère de surveillance qui a permis de comprendre l’origine du problème.

Le protocole TCP/IP, qui consiste en l’envoi et la réception de trames (petits paquets de données) sur le réseau entre un client et un serveur, comporte un système de confirmation de l’envoi et de la réception des informations (nommé ACK). Or, à un moment donné dans le lancement du programme, il a été constaté que celui-ci, au lieu de confirmer la bonne réception d’une trame en provenance du CBS, déclenchait la fermeture de la connexion. Le tunnel entre le programme et le CBS étant fermé, le traitement de la ligne en cours était interrompu, les lignes suivantes n’étant pas traitées.

Solutions mises en place

Au niveau d’AccesCBS

Au sein de son code, AccesCBS fournit une méthode pour l’envoi et la réception des trames sur le réseau. Utilisée pour envoyer les commandes WinIBW depuis l’application ITEM, il s’agit d’une méthode de très bas niveau (couche réseau).  Pour tenter de corriger le problème de réception des trames, le code a été réécrit et optimisé mais, malgré cette réécriture – qui a toutefois permis d’optimiser la communication entre AccesCBS et le CBS, le bug continuait à se produire.

Au niveau d’ITEM

Devant cette impasse, des recherches ont été réalisées pour déterminer s’il était possible, lorsque le bug se produisait, de réinitialiser la connexion entre AccesCBS et le CBS et de relancer le traitement sur la ligne ayant rencontré le problème. Un système a donc été mis en place dans le code d’ITEM afin d’effectuer les opérations suivantes :

• Mise en place d’une remontée d’erreur spécifique lorsque le problème se produit dans AccesCBS pour « informer » ITEM
• Détection de l’erreur dans ITEM
• Déconnexion et reconnexion au CBS lorsque le problème se produit
• Mise en place d’un système permettant de retraiter la ligne en erreur : lorsque le problème est détecté, ITEM tente de traiter la ligne 4 fois. Au-delà de 4 tentatives infructueuses, ITEM renvoie une erreur avec un message explicite dans le fichier résultat de la demande créée par l’utilisateur.

Actions suite à l’incident

Afin d’améliorer le code d’AccesCBS et ainsi se prémunir  contre les potentielles erreurs liées au protocole,  une prestation informatique va être demandée par l’Abes.

En parallèle, il était nécessaire d’isoler les flux des applications communiquant avec le Sudoc des flux des utilisateurs professionnels dans leur usage quotidien du Sudoc.  A cette fin, les applications de l’Abes utiliseront désormais un port spécifique pour se connecter au CBS.

Enfin, ce problème, qui s’est manifesté avec l’application ITEM, pourrait  potentiellement se produire sur d’autres applications utilisant AccesCBS. Pour éviter ce risque, un système de détection de l’erreur « déconnexion / reconnexion au Sudoc » a été mis en place sur les autres applications de l’Abes.

Ce billet constitue un post-mortem d’un incident critique survenu du 4 au 7 mars 2024 . Caractérisé par des ralentissements intermittents et des déconnexions sur l’ensemble des applications de l’Abes, qui ont affecté les établissements du réseau de l’Abes, cet incident a débuté le 4 mars 2024 et a été résolu le 7 mars 2024 à midi.  La cause de l’incident était liée aux scories d’une ancienne configuration de routeur, restées actives sans que l’on en soit conscient. Le redémarrage des machines, notamment des switches, a réactivé ces paramètres, provoquant une redirection alternée de paquets vers un routeur inexistant. Cela a conduit à des « tempêtes réseau » et à des ralentissements importants. 

Symptômes et impacts de l’incident 

Suite à la maintenance effectuée par l’Abes sur son infrastructure les 2 et 3 mars 2024, des ralentissements intermittents ont été observés sur le réseau du SI, provoquant des lenteurs d’accès, voire des déconnexions, sur l’ensemble des applications de l’Abes.

Les utilisateurs ont donc rencontré des difficultés pour accéder aux services en ligne, ce qui a entraîné une perturbation majeure de l’activité. Les tentatives de redémarrage des équipements réseaux n’ayant pas permis de résoudre immédiatement le problème, la période d’indisponibilité des applications a été prolongée.

Causes et solutions 

Après de nombreuses recherches, l’origine de l’incident a été trouvée : elle était liée à une configuration VRRP – Virtual Router Redundancy Protocol (Protocole de Redondance de Routeur Virtuel)  – laissée en place. Le VRRP est un protocole standardisé qui vise à améliorer la haute disponibilité dans un réseau en permettant à plusieurs routeurs de travailler ensemble pour assurer la redondance. Cette double configuration de routeur avait été proposée par Renater en 2020 pour assurer une haute disponibilité à la suite d’une panne. Cependant, après l’installation, cette configuration, qui n’a jamais été testée en conditions réelle, a été jugée trop complexe à maintenir. Elle a donc été supprimée de l’infrastructure de l’Abes l’année suivante. 

Lors du redémarrage du système suite à la maintenance planifiée les 2 et 3 mars, les ports VRRP, normalement désactivés, ont donc renvoyé des paquets sur un routeur qui n’existait plus. C’est cette redirection intermittente qui a entraîné des « tempêtes réseaux » caractérisées par des ralentissements importants.

L’analyse de l’incident s’est basée sur les temps de réponse de la commande « ping ». Les résultats des « ping » en interne étaient excellents, tandis que les « ping » vers le routeur ou l’extérieur étaient par moment fortement dégradés. La résolution de l’incident a finalement été trouvée en identifiant et en éliminant des scories de la configuration VRRP et en redémarrant les interfaces physiques du routeur. Cette action a permis d’instaurer une configuration fonctionnelle, bien que cela ne corresponde pas au comportement attendu des équipements modernes qui devraient normalement prendre en charge les configurations à chaud. 

En résumé, l’incident a mis en évidence l’importance d’une gestion prudente des configurations réseau, en particulier lors de modifications majeures ou après des périodes d’inactivité prolongée. Un contrôle régulier et une maintenance proactive peuvent contribuer à prévenir de tels incidents. Pour limiter les risques, il est également prudent de réduire au maximum les opérations de la maintenance effectuées le jour J. De même, il est important de s’appuyer sur l’assistance externe pour certaines tâches spécifiques. 

La nouvelle version de theses.fr a été mise en ligne jeudi 14 mars 2024. Consulter le billet Fil’Abes

Conduit selon la méthode SCRUM, le projet de refonte de theses.fr illustre parfaitement les concepts de la politique de développement de l’Abes. Il est l’aboutissement de 19 mois de travail pour l’équipe constituée d’une Product Owner, de cinq développeurs – dont un en prestation externe – et d’un devops.

Fidèle à la résolution de l’Abes qui, depuis 2019, publie les codes sources de ses applications sur Github, le projet est entièrement open source. Ses différents modules sont répartis dans plusieurs dépôts, tous hébergés dans l’organisation Github de l’Abes.

L’interface du site

Un premier dépôt contient le code de l’interface de l’application réalisée avec le framework Nuxt, surcouche au framework VueJs. VueJs a été choisi par les développeurs de l’Abes pour sa courbe d’apprentissage jugée plus rapide que pour ses concurrents React ou Angular.

La surcouche Nuxt assure une meilleure indexation du site par les moteurs de recherche du web, notamment grâce au Server Side Rendering, qui permet de préparer, côté serveur, une partie du code client qui sera exécuté dans le navigateur et ainsi le rendre immédiatement lisible par les moteurs d’indexation. De plus, Nuxt propose et préconfigure par défaut un certain nombre de fonctionnalités indispensables, comme le routage qui fournit les URLs de l’application, la gestion des erreurs ou encore la récupération des données depuis les API.

L’accès à l’interface via différents types de terminaux est également facilité par le framework VueJS : une navigation aisée sur mobile est une des nouveautés du site.

Une attention toute particulière a été portée par les développeurs sur l’accessibilité de l’interface, qui respecte les règles édictées dans le Référentiel général d’amélioration de l’accessibilité (RGAA) : polices appropriées, choix des couleurs, contraste, mise en forme de la page et utilisation de balises ARIA pour introduire la sémantique des éléments dans le code HTML.

Une intégration continue

L’intégration continue du projet est assurée par des actions Github, programmes qui se déclenchent à chaque fois qu’un développeur pousse (publie) du code sur une branche (qui propose une fonctionnalité) du projet : le code est alors compilé et, si la compilation et les tests réussissent, la branche en question peut alors être publiée comme image sur la plateforme Dockerhub. Ces images sont alors disponibles pour déploiement sur nos machines de développement, test ou production. A noter que le code de l’intégration continue est versionné sur le même dépôt que le projet, au plus près de ce dernier pour en faciliter la maintenance.

Les API

Côté back-office, theses.fr est composé de trois API, ensemble de services utilisés par l’interface VueJs mais qui peuvent également être appelés depuis des programmes externes.  Ces API, programmées en Java Spring et documentées selon la norme OpenAPI, sont publiées à cette adresse : https://api.gouv.fr/les-api/api-export-donnees-these

Ces services recouvrent trois thématiques :

• La recherche dans les métadonnées : il est possible d’interroger les données en passant directement une chaine de recherche du langage de requête du moteur d’indexation Elastic Search via l’URL. Les réponses sont renvoyées au format JSON.
• La diffusion des documents : cette API fournit à la fois les boutons à afficher dans l’interface pour chacune des thèses et les liens avers les documents eux-mêmes, ou des liens vers des ressources externes décrivant les documents, comme les notices du catalogue Sudoc. Les accès aux documents sont contrôlés : il n’est pas possible de visualiser une thèse confidentielle et la récupération d’une thèse sous embargo est soumis à authentification.
• L’export des métadonnées : les métadonnées des thèses sont fournies dans des formats BIBTEX et RIS qui permettent d’échanger ou d’intégrer facilement la thèse comme référence bibliographique. Elles sont aussi disponibles en RDF, format du web sémantique qui facilite leur intégration dans le Linked Open Data cloud

Le moteur Elastic Search

Les données sont indexées dans le moteur Elastic Search, le choix s’étant porté sur cet outil à la fois pour sa popularité et sa présence dans la pile logicielle Elastic Search – LogStash – Kibana, déjà installée dans  le système d’information de l’Abes.

Elastic Search assure les fonctionnalités essentielles telles que filtres, agrégations, pondération ou encore calcul de pertinence lors de l’exécution des requêtes tout en maintenant un haut niveau de performance en termes de délai de réponse.

Consulter :  https://collection-numerique.amue.fr/numero-27/13.html

Fédération d’identité

Si les thèses en accès restreint ne sont pas disponibles pour le grand public, leur diffusion étant par exemple limitée par un embargo, elles doivent cependant être accessibles aux membres de l’Enseignement Supérieur et de la Recherche. Donner accès à ces thèses constitue donc une des principales nouveautés du nouveau theses.fr.

L’implémentation de cette fonctionnalité a été réalisée grâce à l’inscription de theses.fr en tant que fournisseur de services dans la fédération d’identité RENATER. L’authentification des utilisateurs est ainsi déléguée à cette fédération d’identité qui s’assurera que toute personne disposant d’un compte chez un fournisseur d’identités pourra accéder aux thèses en accès restreint.

Le système, qui repose sur le protocole SAML2, requiert l’installation et la configuration de briques logicielles : à cette fin, nous avons mis en place un proxy Apache chargé de rediriger les URLs des thèses en accès restreint vers une page demandant à l’utilisateur de choisir son fournisseur d’identité afin de s’authentifier pour pouvoir accéder à la ressource.

• Consulter les codes de theses.fr : https://github.com/abes-esr
• Télécharger les API sur api.gouv : https://api.gouv.fr/les-api/api-export-donnees-these