Chantiers qualité dans Calames : contexte et objectifs

Dans la seconde moitié des années 2010, plusieurs chantiers qualité ont été menés en concertation avec le groupe de travail Calames. Ces opérations reposaient principalement sur des modifications de masse réalisées par l’Abes, avec une simple information communiquée au réseau.

En 2020, dans le contexte particulier du confinement, un chantier qualité ciblant les autorités et leurs liens avec les notices IdRef s’est déroulé sur plusieurs mois. Pour la première fois, les établissements du réseau ont été sollicités pour améliorer ces liens, grâce à l’envoi par l’Abes d’un tableau de diagnostic détaillé.

En 2023, lors de la journée réseau Calames intitulée « Le Voyage des données », ces chantiers qualité ont été évoqués à nouveau. Il a été annoncé qu’ils seraient relancés afin de préparer la migration des données Calames vers un nouvel outil destiné à remplacer l’actuel.

Cette attention à la qualité des données est également essentielle pour anticiper d’éventuelles conversions vers de nouveaux modèles, comme EAD 4 (dont la publication est prévue en 2026) ou RiC (publié fin 2023).

Identifier les chantiers pertinents 

En 2024, l’équipe Calames a identifié les chantiers qualité pertinents en procédant au requêtage de la base de production. Deux types de cas ont été privilégiés : 

• Des cas repérés dans la base avec une certaine régularité lors d’interventions sur les données ou de traitements de tickets d’assistance
  

• Des éléments EAD estimés « stratégiques » du fait qu’ils alimentent des index de recherche dans l’interface publique de Calames : ID de composant, cotes, dates, indexation de personne physique, collectivité, famille, lieu géographique, sujet ou langue. 

Une trentaine de chantiers qualité potentiels ont ainsi été identifiés et classés en ordre de priorité selon le degré d’importance de l’élément ou de l’attribut EAD concerné dans les index de recherche Calames et du nombre de formes erronées à corriger sur l’ensemble des données publiées dans Calames, les données présentes en base de production, mais non publiées, ayant été systématiquement écartées de l’analyse. 

S’aider de l’intelligence artificielle pour modifier les données en masse 

Pour réaliser des modifications de masse  sur les données, l’Abes utilise deux outils internes : l’un dédié au Sudoc et à IdRef, l’autre à Calames.

Ces outils reposent sur des scripts développés en langage Java, s’appuyant sur l’API standard du DOM W3C. Cette bibliothèque permet de créer, manipuler et analyser des documents XML, en offrant une navigation fine au sein de la structure arborescente des nœuds XML. Grâce à cette technologie, il est possible, en théorie, d’accéder à tout élément ou attribut EAD contenu dans les composants d’un fichier, afin de les modifier de manière ciblée.

L’IA à la rescousse de la qualité des données Calames

La production de ces scripts peut toutefois s’avérer fastidieuse pour des non-informaticiens, notamment selon la complexité des éléments ou attributs EAD à modifier. Afin d’accélérer ce processus et de limiter la sollicitation récurrente des informaticiens, il a été décidé de recourir à un modèle d’intelligence artificielle.

A cette fin, un agent LLM (Large Language Model) a été entraîné pour permettre aux utilisateurs de générer des scripts Java adaptés aux données Calames, sans avoir besoin de connaissances en développement ou en langage de programmation. L’objectif : traduire automatiquement une demande formulée en langage naturel — par exemple, une requête manuscrite décrivant le type de modification souhaitée — en instructions compréhensibles par la machine, tout en respectant la DTD EAD.

Concrètement, un agent LLM est un programme informatique avancé, fondé sur un grand modèle de langage. Il est capable de comprendre et de produire du texte grâce à l’intelligence artificielle. Basé sur un modèle préalablement entraîné, il est ensuite configuré de manière spécifique pour répondre à un usage ciblé — ici, la génération de scripts Java pour le traitement de données XML dans Calames.

Entraînement et configuration des agents LLM

Dans notre cas, les tests ont été menés avec deux agents LLM : l’un basé sur GPT-4-turbo via ChatGPT, l’autre sur Codestral 25.01, accessible via La Plateforme de Mistral AI.

Pour que les agents puissent produire des scripts pertinents, un contexte précis leur a été fourni : normes à respecter (notamment la DTD EAD), bibliothèques Java utilisées, et un échantillon représentatif des données Calames.
La configuration intègre également les spécificités du langage XML, les pièges classiques identifiés lors de l’écriture de scripts, ainsi que des consignes permettant de limiter les erreurs récurrentes.

Construction d’un jeu d’entraînement

En amont, une liste de requêtes de modification courantes a été constituée. Pour chaque demande, un développeur a rédigé le script Java correspondant, servant de référence.
Cette base a ensuite permis d’entraîner l’agent LLM, afin qu’il puisse adapter ses réponses à des formulations en langage naturel, tout en produisant du code exploitable.

Des instructions précises ont également été données sur le format de sortie attendu, la syntaxe à respecter, ainsi que le style de commentaire dans les scripts.

Un nombre conséquent de tests et d’itérations a été nécessaire pour affiner les réponses de l’agent, et le rapprocher au maximum du cahier des charges défini initialement.

Utilisation concrète via Mistral AI

Les tests ont été réalisés avec des agents basés sur GPT-4-turbo via chatGPT et Codestral 25.01 via La Plateforme de Mistral AI. 

Pour la configuration, le contexte, les normes et les librairies utilisées ont été fournies aux agents LLM. Un échantillon du type de données à partir duquel il doit travailler a également été fourni. La configuration a dû faire état des particularités du langage et des écueils connus lors de l’écriture de scripts afin de circonscrire les erreurs connues.

Dans le cas de Mistral, l’utilisateur accède à l’agent conversationnel via la page dédiée de “Mistral AI : Le Chat”, où il peut appeler l’agent LLM entraîné par l’Abes. Il lui suffit alors de formuler sa demande comme il le ferait auprès d’un développeur, en langage courant.

Dans l’exemple ci-dessous, l’agent produit un script Java destiné à être utilisé dans l’outil de modification de masse de Calames. Le fichier texte d’entrée n’a pas besoin d’être détaillé dans son contenu ; seule l’indication de la colonne à cibler dans ce fichier est nécessaire pour générer le script adéquat.

En quelques secondes l’agent LLM génère un nouveau script Java en suivant les instructions. Si l’utilisateur n’est pas satisfait, il peut modifier sa demande plusieurs fois. 

Des scripts en Java étant également utilisés pour les modifications de masse côté Sudoc, un agent LLM a été adapté pour produire de la même manière des scripts adaptés à Unimarc. 

Le résultat généré par l’agent LLM est un script adaptable qui vise à modifier en masse, de manière très précise  les données ciblées. Lors de la génération d’un script, l’agent LLM peut énumérer les détails du script qu’il a généré et permettre à un interlocuteur profane de comprendre ce qu’il fait. 

Mais l’IA peut se tromper et des itérations sont parfois nécessaires si le script produit  provoque des messages d’erreur : dans ce cas, une fois qu’on lui a indiqué l’erreur, l’IA est capable de corriger elle-même son propre script. 

Par sécurité, avant toute exécution en base de production, les scripts sont testés sur des cas types en base de formation Calames et le fichier EAD modifié est alors vérifié par un humain dans un comparateur de fichiers XML. La comparaison avec la version avant modification permet de visualiser ce qui a été modifié ou non et si des modifications non voulues ne se sont pas produites.  

Comment fonctionnent les scripts en Java ?

La structure de tous les scripts produits par l’IA est la même : ils débutent par l’identification du composant où se trouve(nt) la ou les données à modifier ; chaque composant EAD ayant un identifiant unique dans Calames, les identifiants des composants concernés sont listés dans la colonne d’un fichier txt appelé par le script :  

Puis les scripts procèdent à des boucles pour isoler le ou les éléments EAD concerné(s) au sein de chaque composant, comme ci-dessous pour un élément <extref> : 

Les scripts procèdent, si nécessaire, à la suppression des valeurs à corriger dans un ou plusieurs éléments ciblés. Le cas échéant, de nouvelles valeurs sont générées automatiquement pour les remplacer. Une fois les modifications appliquées à un composant, le script passe au suivant, en bouclant à nouveau sur les éléments à traiter dans ce nouveau composant. Ce processus se répète jusqu’à ce que tous les composants concernés aient été parcourus.

Grâce à ce fonctionnement, des milliers de composants répartis dans des dizaines de fichiers EAD issus d’une même base de données peuvent être traités en quelques minutes par un seul et même script.

Pour sécuriser l’opération, l’outil utilisé par l’Abes pour la modification de masse permet de cibler précisément les fichiers EAD concernés : il suffit d’indiquer leurs clés (identifiants de fichiers). Cela garantit que seuls les fichiers explicitement sélectionnés seront modifiés, évitant ainsi toute intervention involontaire sur des données non concernées.

Identifier précisément la donnée à modifier

Aussi rapide soit-elle, la génération d’un script ne dispense pas de vigilance : le script doit cibler avec précision la donnée à corriger ou à mettre à jour, sans risquer d’altérer d’autres données similaires mais correctes.

Lorsqu’un élément EAD est non répétable, sa présence unique dans un composant garantit que le script agira sur la bonne cible. En revanche, dans la majorité des cas, les éléments concernés sont répétables — autrement dit, plusieurs occurrences du même type d’élément peuvent coexister dans un composant. Il devient alors indispensable de mettre en place des critères de sélection fiables pour que le script n’intervienne que sur l’occurrence à modifier, sans toucher aux autres qui sont déjà conformes ou à jour.

Exemple de ciblage précis : le cas des éléments <unitid>

Prenons un cas concret : un composant contient cinq éléments <unitid>, dont un seul doit être modifié. Il est essentiel que le script identifie précisément celui-ci, sans toucher aux autres.

Si le <unitid> à modifier est le seul à porter l’attribut @type="cote" tandis que les quatre autres ont @type="ancienne_cote", alors l’attribut type suffit à le cibler de manière fiable.

En revanche, si l’élément à modifier est lui aussi un <unitid> de type="ancienne_cote", l’attribut seul ne suffit plus : il faudra alors croiser ce critère avec le contenu textuel de l’élément (ayant une valeur spécifique) pour s’assurer qu’il s’agit bien du bon <unitid>.

Ce genre de vérification conditionne la qualité du script : un ciblage trop large peut entraîner des modifications non souhaitées, tandis qu’un ciblage trop restrictif peut empêcher la modification attendue. D’où l’importance de bien analyser les cas de figure avant d’automatiser.

Plutôt pas assez que trop : les limites du ciblage par valeur

La vérification des valeurs d’attributs et du contenu textuel d’un élément est ce qui garantit la fiabilité du ciblage. Mais cette méthode a aussi ses limites.
En effet, si le contenu textuel contient des caractères parasites — espaces superflus, tabulations, retours à la ligne —, le script peut ne pas reconnaître l’élément comme correspondant à la valeur attendue. Ce problème se pose plus rarement sur les attributs, généralement mieux structurés.

Dans ce cas, l’élément ciblé n’est pas trouvé, et le script passe à l’occurrence suivante, que ce soit dans le même composant ou dans un composant différent, sans effectuer la modification attendue.

Ce type d’imprécision explique pourquoi, à l’issue d’une opération de modification de masse, le nombre de modifications effectivement réalisées peut être légèrement inférieur à celui initialement prévu ou identifié.

Limites des scripts et enjeux de qualité des données

Entre deux risques — corriger trop largement au point d’introduire de nouvelles erreurs, ou corriger trop peu et laisser passer certaines anomalies — l’Abes choisit résolument la prudence. Mieux vaut que quelques erreurs subsistent plutôt que de risquer d’en créer de nouvelles.

Un fichier EAD est structuré en trois grandes parties :

• <eadheader>, qui contient des métadonnées sur le fichier lui-même,
  le haut niveau de description,
• <archdesc>, qui regroupe les informations communes à l’ensemble du contenu,
• et enfin le <dsc>, enfant de <archdesc>, qui contient les composants (unités documentaires décrites).

Les scripts Java évoqués plus haut sont conçus pour intervenir uniquement au niveau des composants, ce qui couvre l’essentiel des données publiées dans Calames. Toutefois, certaines mises à jour peuvent également concerner des données situées en <eadheader> ou en <archdesc>.

Dans ces cas-là, il est nécessaire d’effectuer des requêtes SQL UPDATE directement dans la base. Bien que plus sensibles, ces interventions restent maîtrisées : en cas d’erreur, il est possible de restaurer les fichiers à partir des versions de sauvegarde. Les établissements sont d’ailleurs invités à ne pas intervenir simultanément dans la base lorsque l’Abes procède à des modifications de masse, pour garantir la cohérence des données.

Lorsque des corrections doivent être apportées à la fois dans <archdesc> et dans les composants, il est possible de les regrouper dans un même chantier, mené sur une journée.

Conclusion : une amélioration continue de la qualité

La qualité des données n’est jamais totalement acquise — ni à leur production par les collègues des établissements du réseau Calames, ni après correction par l’Abes. Mais ce sont bien ces efforts progressifs, concertés et itératifs qui permettent de tendre vers un niveau de qualité toujours plus élevé, au service des usagers et des outils de signalement.

D’autres billets sont à suivre sur les chantiers qualité menés entre mars et juillet 2025 dans Calames afin de donner plus de détails pour chaque chantier. 

La cybersécurité est devenue un enjeu central pour les établissements publics, notamment depuis la parution de l’Instruction générale interministérielle n°1337 du 26 octobre 2022, qui impose une obligation d’homologation des systèmes d’information (SI) pour toutes les structures concourant aux missions de l’État ou placées sous sa tutelle.

Consulter : Texte officiel sur Légifrance

Une obligation réglementaire à l’horizon 2025

Depuis avril 2023, les établissements disposent d’un délai de deux ans pour se mettre en conformité. Passé ce délai, les pénalités seront encadrées par l’ANSSI, comme précisé dans la section 6.3 de l’Instruction.

Consulter : Section 6.3 sur Légifrance

Qu’est-ce que l’homologation de sécurité ?

L’homologation est un acte formel par lequel une autorité qualifiée (l’AQSSI ou son délégataire) atteste que :

• les risques de sécurité ont été identifiés

• les mesures de maîtrise des risques ont été mises en œuvre

• les risques résiduels sont acceptés en pleine connaissance de cause.

Ce processus doit précéder toute mise en production d’un nouveau service numérique. Il s’applique à tous les SI relevant du périmètre de l’État ou de réglementations spécifiques, et est adapté en fonction de la sensibilité des systèmes concernés.

Une gouvernance assumée

L’autorité d’homologation doit occuper une position hiérarchique suffisamment élevée pour porter la responsabilité de la mise en ligne des services.

Dans le cas de l’Abes, c’est le directeur qui fixe la durée de validité de l’homologation selon une échelle d’évaluation (ex. : note de 4,5 ➝ 3 ans d’homologation).

L’Abes engagée avec MonServiceSécurisé

En tant que DPO et RSSI de l’Abes, nous avons engagé début 2024 une démarche ambitieuse d’homologation, en nous appuyant sur MonServiceSécurisé, la plateforme développée par l’ANSSI pour faciliter cette mise en conformité.

Ce chantier a mobilisé plusieurs parties prenantes en interne : les responsables applicatifs, un expert sécurité. l’AQSSI (rôle assumé par le directeur de l’Abes), la Déléguée à la Protection des données (DPO), le Responsables de la Sécurité des Systèmes d’Information (RSSI).

Au total, plus de 50 applications ont été intégrées à la plateforme. Cette dynamique illustre une volonté forte de structurer la sécurité numérique à l’échelle de l’établissement.

Retour d’expérience dans la communauté ESR

Le 26 juin 2024, nous avons eu le plaisir de partager notre retour d’expérience lors d’un webinaire consacré aux synergies entre urbanistes SI, RSSI et DPO. Organisée par la communauté urbaESR, coanimée par l’Amue et le Csiesr, cette rencontre a rassemblé plus de 50 participants issus de ces trois domaines d’expertise. À cette occasion, Maria Castillo (DPO, Abes), Frédéric Pouilloux (RSSI, Abes)  et Catherine Balleydier (Grenoble INP) ont présenté des exemples concrets de collaboration au sein de leurs établissements. 

Nous avons notamment présenté :

• les apports concrets de MonServiceSécurisé

• la méthodologie d’évaluation des applications

• l’intérêt d’une collaboration étroite entre urbanistes SI, DPO et RSSI

Consulter : Les liens entre urbanistes SI, DPO et RSSI : retour sur un webinaire urbaESR

Une reconnaissance inspirante

Notre engagement a été salué en avril 2025 par l’équipe de MonServiceSécurisé, qui nous a adressé un message de remerciement chaleureux, soulignant notre rôle d’ambassadrice et d’ambassadeur des innovations de l’ANSSI.

Cette reconnaissance renforce notre détermination à poursuivre cette dynamique, et à contribuer à la diffusion des bonnes pratiques en matière de sécurité numérique dans le secteur public.

Et demain ?

La cybersécurité est l’affaire de tous. Nous sommes convaincus que les outils et initiatives comme MonServiceSécurisé jouent un rôle essentiel dans l’évolution des pratiques du secteur public. À l’Abes, cette dynamique va se poursuivre en élargissant l’homologation à de nouveaux services et en partageant nos retours d’expérience avec la communauté ESR.

Maria Castillo, DPO et Frédéric Pouilloux, RSSI

Incident survenu du 19 au 28 mai 2025

Quand on ne trouve pas, c’est qu’en général on ne cherche pas au bon endroit

Tout a commencé vers la mi-avril, avec quelques signaux faibles : des retours isolés, des lenteurs sporadiques, parfois impossibles à reproduire, des utilisateurs gênés… mais rien de franchement alarmant. Puis, le 19 mai, la situation s’accélère : les alertes se multiplient. Calames devient poussif, le moissonnage des entrepôts de données rame, l’autocomplétion des auteurs sur idref.fr prend une pause-café, et même le Sudoc public (sudoc.abes.fr) débouche parfois sur un message « délai dépassé ».

Pour ne rien arranger, certaines de nos sondes de surveillance se sont mises à faire le yoyo (en ligne, hors ligne, de nouveau en ligne, puis encore hors ligne), accentuant la confusion et renforçant le sentiment d’instabilité générale.

Le plus déconcertant ? À l’Abes, ou via notre VPN, tout fonctionne parfaitement. Aucune lenteur, rien à signaler. Impossible de reproduire le problème. En revanche, à distance, les soucis sont présents mais pas de façon constante. D’où cette impression étrange : ce n’est pas l’application qui flanche, mais l’accès. Et pourtant, côté réseau, tout semble en ordre. Aucun indicateur suspect, aucune alerte. Rien.

Alors, on creuse. On mène des tests en direct avec un établissement impacté (la bibliothèque de l’Académie Nationale de Médecine). On inspecte les trames avec les outils de développement du navigateur, puis avec Wireshark. Les lenteurs sont tangibles. Et pourtant, dans les logs, aucune anomalie liée aux IP publiques des utilisateurs concernés. Le vide.

Alors, on continue à chercher. On redémarre des services, on inspecte le DNS, les interfaces réseau, les journaux système, les pares-feux, le débit, la mémoire, la CPU, la couche de virtualisation, les bloqueurs de pub (oui, vraiment), et même Matomo, notre outil de statistiques web.

Mais rien. Les lenteurs persistent, réelles, mesurables… et insaisissables. Comme si le problème s’amusait à jouer à cache-cache avec nous.

Alors, où chercher maintenant ?

Quand on finit (enfin) par chercher au bon endroit

C’est en basculant notre application exemple « hello.abes.fr » sur un autre reverse proxy que l’on a le déclic. Lente et poussive derrière le reverse proxy central, elle devient fluide et réactive lorsqu’on la place derrière un autre proxy. Ce contraste nous met sur la piste. On met donc en place un nouveau reverse proxy central, puis on y migre l’application Calames. Résultat sans appel : sans VPN, tout fonctionne parfaitement. La source du problème se précise nettement.

En creusant la piste du reverse proxy, on s’intéresse de plus près au pare-feu présent sur la machine, on analyse les différentes règles iptables présentes, dont certaines n’ont pas été modifiées depuis des années, sans jamais avoir été réellement réévaluées. En particulier, une règle limitait le nombre de connexions entrantes pour contrer les attaques DoS. Sauf qu’en 2025, avec plus d’applications, plus d’usagers, plus de moissonnages… ces seuils ont fini par faire du zèle. Trop de trafic ? Hop, on bloque. Résultat : un effet de seuil inattendu, où le trafic légitime se retrouve victime d’une politique de sécurité un peu trop stricte.

Les petits réglages qui font toute la différence

Une fois la cause identifiée, les ajustements s’enchaînent avec méthode.

Les règles iptables de protection contre les attaques DoS sont repensées : les seuils sont relevés et les limitations appliquées par adresse IP source. Une approche à la fois plus juste et moins restrictive.

Du côté du serveur web Apache (HTTPd), plusieurs optimisations sont opérées : augmentation des caches pour les sessions HTTPS (de 2 Mo à 5 Mo puis à 10 Mo), ajout de threads sur les serveurs, ajustement du nombre de connexions simultanées… chaque paramètre est affiné pour garantir un fonctionnement fluide et stable.

Enfin, une des règles iptables, oubliée lors des dernières modifications, a provoqué, par effet de bord, le blocage involontaire des accès HTTP. Sa correction a rétabli le fonctionnement normal.

Et le plus réjouissant dans tout ça ? C’est que ça marche. Les lenteurs disparaissent. Les applications redeviennent fluides. Les sondes se stabilisent. Et l’équipe respire enfin.

Ce qu’on en retient

Derrière cet incident se cache une belle leçon de mécanique logicielle et d’archéologie système : des règles oubliées, des seuils devenus obsolètes, un reverse proxy vieillissant, et une croissance d’activité sous-estimée. Cet effet de seuil est, par ailleurs, inhérent à tout système. Un système en fonctionnement repose sur un équilibre défini par de multiples paramètres techniques, fixés à un moment de sa conception ou de son déploiement, qu’il est essentiel de réévaluer dès lors que les usages évoluent.

Mais surtout, c’est l’occasion de rappeler que, quand on ne trouve pas, ce n’est pas toujours parce qu’il n’y a rien. C’est peut-être simplement qu’on ne cherche pas au bon endroit.

Remerciements au SIAT (Service Infrastructure et architecture technique de l’Abes) pour son intervention réactive, aux collègues de l’Abes pour leurs précieuses remontées, ainsi qu’à la Bibliothèque de l’Académie Nationale de Médecine pour sa collaboration lors des tests.

À l’issue d’une expérimentation conduite entre octobre 2024 et janvier 2025, l’Abes a publié le rapport « Indexation  RAMEAU assistée par IA ». Retour en détail sur la façon dont fonctionne cette IA prometteuse.

Lire aussi le Billet Fil’Abes : L’indexation RAMEAU assistée par IA : retour sur une expérimentation prometteuse

Contexte : du projet Labo à l’expérimentation in vivo

En 2023, le Labo de l’Abes a mené un projet dont l’objectif était d’évaluer la faisabilité d’une indexation RAMEAU de qualité satisfaisante au moyen d’une intelligence artificielle (IA), à partir du titre et du résumé d’une monographie en français. Encore fallait-il définir ce qu’est une indexation « satisfaisante », question délicate….

Les particularités de cette tâche nous ont tout d’abord conduits à adopter plusieurs stratégies d’évaluation complémentaires :

1. Évaluation des indexations machines avec les métriques classiques adaptées à la classification multilabel (= Sudoc comme la vérité).
2. Évaluation des indexations machines en les comparant à plusieurs indexations humaines, et pas seulement à l’indexation humaine du Sudoc (= pluralité des vérités). Pour ce faire, nous avons demandé à 6 collègues de l’Abes (nommés les “réindexeurs”) d’indexer une centaine de documents déjà indexés dans le Sudoc, sélectionnés de manière aléatoire.
3. Évaluation qualitative de toutes les indexations, humaines et machines, au moyen d’une grille de notation (= notation comme la vérité). Selon cette grille, noter une indexation, c’était, d’une part, noter chaque sujet retenu pour une notice donnée (on notait l’exactitude et la spécificité de chaque sujet) et, d’autre part, noter le bloc des sujets retenus pour une notice donnée (on notait la complétude et la redondance de chaque bloc).

Les évaluations menées nous ont permis de conclure que l’indexation RAMEAU par une IA est aujourd’hui réalisable en garantissant un niveau de qualité suffisant et un temps de traitement satisfaisant. Cependant, du fait de la grande difficulté à évaluer la qualité d’une indexation et de la nouveauté que présente l’assistance d’une IA, l’Abes a souhaité prolonger ce travail de recherche & développement interne sous la forme d’une expérimentation in vivo, en situation réelle, c’est-à-dire dans WinIBW, l’environnement de catalogage dans le Sudoc.

Dans le cadre de cette expérimentation, il s’agissait d’évaluer à la fois la qualité ressentie du service de suggestion d’indexations et la qualité ressentie de l’intégration de ce service dans l’outil de travail quotidien. L’évaluation de ces deux dimensions a permis de mesurer la satisfaction globale des collègues ayant participé aux tests et d’envisager les améliorations pertinentes. Le rapport final publié récemment décrit les modalités et les conclusions de cette expérimentation.

Dans ce billet, nous nous concentrerons sur la solution technique mise au point et retenue par le Labo de l’Abes pour rendre possible ce nouveau service d’indexation RAMEAU assisté par l’IA. De fait, celui-ci prend la forme d’un web service classique : la requête est une URL qui prend en paramètre le titre+résumé d’un document (outre d’autres paramètres) et renvoie des suggestions sous une forme structurée en JSON. Les détails de ce web service seront présentés plus loin, mais nous souhaitons avant tout présenter de manière simple la solution utilisée pour calculer les concepts RAMEAU à renvoyer, solution basée sur l’état de l’art récent en IA. Cette solution est implémentée dans ce notebook de démonstration.

L’indexation comme recherche des bons concepts

La tâche consiste à trouver dans le vocabulaire RAMEAU les concepts qui représentent le mieux ce dont parle un document. Pour ce faire, il faut trouver une manière de comparer le contenu du document et l’ensemble des concepts RAMEAU.

Mais comment représenter le contenu de ce document ? Et comment représenter un concept RAMEAU ? Et comment les comparer ?

Soit un document à indexer. Supposons que le contenu de ce document est correctement représenté par son titre et son résumé, quand ce dernier existe (pour faire court, on parlera ici de « titre+résumé ».). On peut imaginer d’autres manières de faire, plus ou moins pratiques, plus ou moins efficaces : exploiter tout le texte du document ; exploiter seulement son introduction et sa conclusion ; exploiter sa table des matières ; exploiter un résumé automatique. Dans l’approche retenue, c’est le “titre+résumé” qui est considéré comme le reflet du contenu du document, ce dont il parle.

Côté RAMEAU, il faut également trouver une manière de représenter le « sens » de chaque concept. Il pourrait s’agir de son libellé principal (ex : Élite (sciences sociales)), ou de la liste de tous ses libellés : « Élite (sciences sociales) », « Élites (sciences sociales) », « Establishment », « Haute société », « Notables », « Société, Haute »… Dans l’approche retenue, chaque concept RAMEAU est représenté par l’ensemble des notices bibliographiques Sudoc qui lui sont liées. Plus précisément, dans chaque notice bibliographique liée, on s’intéresse à son titre, et à son résumé s’il existe.

L’indexation sujet revient désormais à comparer deux choses qui semblent comparables :

• D’un côté, le “titre+résumé” d’une notice bibliographique à indexer
• De l’autre, l’ensemble des “titres+résumés” des notices bibliographiques liées à un concept RAMEAU

On comprend aisément que cette comparaison doit être faite autant de fois qu’il y a de concepts RAMEAU : ainsi, pour chaque document à indexer, il y a donc des dizaines de milliers de comparaison à effectuer, pour trouver les concepts les plus « ressemblants » au “titre+résumé” de la notice à indexer, ce qui peut prendre un certain temps…

On sait désormais ce qu’on veut comparer, mais comment les comparer ? Que signifie « ressemblant » ici ? On pourrait par exemple comparer les mots présents de chaque côté, si possible en prenant en compte la fréquence des mots dans toute la base et dans les “titres+résumés” de chaque notice bibliographique (avec TF-IDF). Mais bien souvent, le libellé d’un concept RAMEAU pertinent n’est pas explicitement présent dans le “titre+résumé” du document à indexer. Par exemple, le concept « Classes dirigeantes » semble bien convenir pour un document dont le titre (Les sommets de l’État : essai sur l’élite du pouvoir en France) ne contient pas ce terme.

L’indexation comme recherche sémantique des bons concepts

Or, dans le domaine de l’intelligence artificielle, la notion d’embedding permet justement de représenter un mot, une phrase ou un texte en prenant en compte  son « sens », et pas seulement   sa forme linguistique. Ainsi, le terme « allocution » sera calculé comme plus proche de « discours » que d' »allocation ».

Dans notre cas, il s’agit de calculer des embeddings de phrases (sentence embedding). Il existe différents modèles pour le faire, plus ou moins lourds et adaptés à tel ou tel contexte. Nous avons choisi d’en retenir plusieurs, ce qui permet de croiser ensuite les résultats, qui s’avèrent souvent complémentaires.

C’est ainsi que nous pouvons calculer l’embedding de n’importe quelle notice bibliographique (ou plutôt son “titre+résumé”). Précisons qu’en indexant, nous ne cherchons pas à comparer deux notices bibliographiques via leurs embeddings) mais à comparer un embedding de notice bibliographique à l’ensemble des embeddings des notices bibliographiques liées à un concept RAMEAU donné. Comment représenter cet ensemble d’embeddings sous la forme d’un seul ? Autrement dit, comment agréger les embeddings de plusieurs notices ?

Nous avons retenu la solution la plus simple : la moyenne. L’embedding d’un concept RAMEAU est donc la moyenne des embeddings des “titres+résumés” des notices bibliographiques qui lui sont liées. Nous aurions pu retenir d’autres méthodes d’agrégation, plus complexes, et possiblement plus pertinentes (ex : moyenne pondérée en fonction de la fréquence des mots ou d’un autre facteur).

L’indexation sujet donc revient désormais à comparer deux embeddings, exprimés sous forme numérique (des vecteurs) :

• D’un côté, l’embedding du “titre+résumé” d’une notice bibliographique à indexer

• De l’autre, l’embedding d’un concept RAMEAU (calculé comme nous venons de l’indiquer)

Voici un exemple (issu du notebook de démonstration)  :

text = "Les sommets de l'État : essai sur l'élite du pouvoir en France"
predict(text, 10)
⇒
027322610#Hauts_fonctionnaires
027229629#Bureaucratie
027223345#Classes_dirigeantes
027994775#Institutions_politiques
027792102#Aspect_politique
027225224#Élite_(sciences_sociales)
027365581#Pouvoir_(sciences_sociales)
02726470X#Histoire
027728110#Politique_et_gouvernement
027311163#Caractère_national_français

Ces suggestions de concepts RAMEAU ont été générées par une petite base de vecteurs RAMEAU calculée à partir de 10 000 notices Sudoc (livres), grâce au modèle d’embeddings intfloat/multilingual-e5-large.

Sur cet exemple, malgré la taille du corpus bibliographique et l’absence de résumé, on peut constater que les suggestions sont de très bonne qualité. On observe également des concepts moins pertinents, trop généraux (Histoire) ou « à côté de la plaque » (Caractère national français). Quoique…

En l’état, cette liste de concepts s’avère donc être une très bonne aide à la décision pour l’indexeur, mais encore insuffisante pour une indexation automatique, sans contrôle humain.

Dans cette base de démonstration, on ne trouve que 8 804 concepts RAMEAU, présents dans les 10 000 notices bibliographiques. Les autres concepts RAMEAU ne pouvaient donc pas être suggérés par ce modèle. Il a donc fallu élargir le corpus de notices bibliographiques à exploiter, pour espérer prendre en compte le maximum de concepts RAMEAU.

Dans notre expérimentation (fin 2025), le corpus contenait 400 000 notices de livres. On pourrait inclure des centaines de milliers de thèses pour augmenter encore la couverture de RAMEAU (et inclure des concepts pointus et peu utilisés). On entrevoit la limite de notre approche : même si on peut imaginer des artifices pour dépasser cette limite, un tout nouveau concept RAMEAU, pas encore utilisé dans une notice bibliographique, ne sera jamais proposé.

Plusieurs modèles d’embeddings, jugés par un grand modèle de langage (LLM)

Nous aurions pu décider de ne conserver que le meilleur modèle. Nos évaluations nous ont permis d’observer que les résultats des différents modèles sont souvent complémentaires : les oublis des uns peuvent être compensés par les suggestions des autres. Il est donc intéressant de conserver plusieurs modèles et d’agréger leurs suggestions.

Ainsi, outre les résultats bruts générés par les différents modèles retenus, le web service d’indexation renvoie plusieurs modes d’agrégation de ces résultats :

• « union » : on cumule toutes les suggestions
• « intersection » : on ne garde que les suggestions communes à tous les modèles
• « intersection2best » : on ne garde que les suggestions communes à au moins deux modèles parmi les meilleurs modèles
• « llm » (ou « llm_bad ») : on demande à un LLM d’identifier les suggestions qui lui semblent erronées et on les exclut de la liste renvoyée par ce mode d’agrégation
• « llm_good » :  on demande à un LLM d’identifier les suggestions qui lui semblent adéquates
• « llm_scores » : on demande à un LLM de donner un indice de fiabilité pour chacune des suggestions

Emballer l’IA dans un web service

L’agent (humain ou machine) qui reçoit les résultats du web service possède une grande marge de liberté. Il peut choisir de ne conserver que les résultats du meilleur modèle, ou bien de ceux de l’intersection, ou encore ceux de « llm_good », ou encore les résultats de « llm_score » qui dépassent un certain seuil de confiance (s’il a confiance en eux…). Il peut enfin inventer sa propre méthode de sélection, à partir de la réponse du web service.

Cependant, un grand choix suscite parfois de l’embarras. Le service propose des sorties prémâchées, plus simples à exploiter que la sortie brute (en JSON) :

• Une sortie UNIMARC classique (en texte ou en HTML)
• Une sortie UNIMARC affichant les relations hiérarchiques entre les concepts suggérés
• Une page HTML interactive pour affiner et construire une indexation riche, par drag and drop (expérimental)

Le web service prévoit d’autres paramètres :

• Nombre de suggestions par modèle
• Nom du vocabulaire (aujourd’hui RAMEAU, mais demain…)
• Identifiant du document

Terminons cette démonstration par un exemple complet :

Notice Sudoc : https://www.sudoc.fr/000308838

Titre :  Les sommets de l’État : essai sur l’élite du pouvoir en France

Résumé : Du XIXe siècle à nos jours, l’Etat « fort » à la française a connu bien des vicissitudes que l’on se propose de retracer ici. Institution prestigieuse attirant vers elle les élites de la nation issues des Grandes Ecoles, l’Etat organise les activités les plus diverses grâce à son armée de fonctionnaires fidèles à la logique de leur rôle et aux valeurs du service public. Les élites politiques et celles de l’Etat en viennent alors souvent à se confondre, d’autant que l’état demeure fermé aux intrus du monde des affaires, des professions libérales ou des milieux syndicaux. La République des fonctionnaires étend son contrôle loin dans la société à travers les entreprises publiques, ou encore par le biais du pantouflage. Cet Etat « fort » n’en rencontre pas moins la vive hostilité des élites issues des partis de masse ou des notables de province solidement attachés à leurs fiefs ; le mouvement ouvrier et, davantage encore, les milieux économiques dominants récusent aussi sa légitimité au nom de leurs valeurs propres. En dépit de ces refus, en France, l’Etat est demeuré le lieu de régulation de la vie sociale ou culturelle. De nos jours pourtant, après les diverses alternances, de nouveaux processus de circulation des élites se profilent, estompant peu à peu les frontières autrefois si nettement défendues de l’Etat.

Modèles appelés : victor3_chain, victor1_concept, victor2

Agrégations : toutes

Nombre de résultats par modèle : 6

{
  "DocumentID": "https://www.sudoc.fr/000308838",
  "PredictionByModel": {
    "victor3_chain": {
      "Result": [
        {
          "label": "Élite (sciences sociales)",
          "id": "027225224",
          "score": 0.9189762967389044
        },
        {
          "label": "Classes dirigeantes",
          "id": "027223345",
          "score": 0.9186880052734565
        },
        {
          "label": "Monarchie",
          "id": "050124277",
          "score": 0.9074089154291344
        },
        {
          "label": "Pouvoir (sciences sociales)",
          "id": "027365581",
          "score": 0.9068471643349856
        },
        {
          "label": "Hauts fonctionnaires",
          "id": "027322610",
          "score": 0.906553947770748
        },
        {
          "label": "Élite (sciences sociales)--Histoire",
          "id": "027225224--02726470X",
          "score": 0.9064290266314496
        }
      ],
      "ResponseTime": "0.41 secondes"
    },
    "victor1_concept": {
      "Result": [
        {
          "label": "Hauts fonctionnaires",
          "id": "027322610",
          "score": 0.7638581153626636
        },
        {
          "label": "État",
          "id": "027297942",
          "score": 0.7440623350425135
        },
        {
          "label": "Fédéralisme",
          "id": "027826538",
          "score": 0.737714937615626
        },
        {
          "label": "Centralisation administrative",
          "id": "027465853",
          "score": 0.7310664369558111
        },
        {
          "label": "Armée de métier",
          "id": "030768268",
          "score": 0.7291465091067392
        },
        {
          "label": "Service militaire obligatoire",
          "id": "050549928",
          "score": 0.7253427565342923
        }
      ],
      "ResponseTime": "0.09 secondes"
    },
    "victor2": {
      "Result": [
        {
          "label": "Classes dirigeantes",
          "id": "027223345",
          "score": 0.6716704033357916
        },
        {
          "label": "Hauts fonctionnaires",
          "id": "027322610",
          "score": 0.6692576043596348
        },
        {
          "label": "Élite (sciences sociales)",
          "id": "027225224",
          "score": 0.6563994626198374
        },
        {
          "label": "Pouvoir (sciences sociales)",
          "id": "027365581",
          "score": 0.6537038100972423
        },
        {
          "label": "Pouvoir exécutif",
          "id": "027836622",
          "score": 0.6521094623337023
        },
        {
          "label": "Forces armées françaises",
          "id": "028235460",
          "score": 0.6428029516927859
        }
      ],
      "ResponseTime": "0.14 secondes"
    }
  },
  "PredictionByAggregation": {
    "union": [
      {
        "label": "Centralisation administrative",
        "id": "027465853"
      },
      {
        "label": "État",
        "id": "027297942"
      },
      {
        "label": "Forces armées françaises",
        "id": "028235460"
      },
      {
        "label": "Fédéralisme",
        "id": "027826538"
      },
      {
        "label": "Service militaire obligatoire",
        "id": "050549928"
      },
      {
        "label": "Pouvoir exécutif",
        "id": "027836622"
      },
      {
        "label": "Classes dirigeantes",
        "id": "027223345"
      },
      {
        "label": "Armée de métier",
        "id": "030768268"
      },
      {
        "label": "Monarchie",
        "id": "050124277"
      },
      {
        "label": "Hauts fonctionnaires",
        "id": "027322610"
      },
      {
        "label": "Élite (sciences sociales)",
        "id": "027225224"
      },
      {
        "label": "Élite (sciences sociales)--Histoire",
        "id": "027225224--02726470X"
      },
      {
        "label": "Pouvoir (sciences sociales)",
        "id": "027365581"
      }
    ],
    "intersection": [
      {
        "label": "Hauts fonctionnaires",
        "id": "027322610"
      }
    ],
    "intersection2models": [
      {
        "label": "Hauts fonctionnaires",
        "id": "027322610"
      },
      {
        "label": "Élite (sciences sociales)",
        "id": "027225224"
      },
      {
        "label": "Pouvoir (sciences sociales)",
        "id": "027365581"
      },
      {
        "label": "Classes dirigeantes",
        "id": "027223345"
      }
    ],
    "intersection2Models1Best": [
      {
        "label": "Hauts fonctionnaires",
        "id": "027322610"
      },
      {
        "label": "Élite (sciences sociales)",
        "id": "027225224"
      },
      {
        "label": "Pouvoir (sciences sociales)",
        "id": "027365581"
      },
      {
        "label": "Classes dirigeantes",
        "id": "027223345"
      }
    ],
    "llm": [
      {
        "label": "Centralisation administrative",
        "id": "027465853"
      },
      {
        "label": "État",
        "id": "027297942"
      },
      {
        "label": "Classes dirigeantes",
        "id": "027223345"
      },
      {
        "label": "Hauts fonctionnaires",
        "id": "027322610"
      },
      {
        "label": "Élite (sciences sociales)",
        "id": "027225224"
      },
      {
        "label": "Élite (sciences sociales)--Histoire",
        "id": "027225224--02726470X"
      },
      {
        "label": "Pouvoir (sciences sociales)",
        "id": "027365581"
      }
    ],
    "llm_good": [
      {
        "label": "État",
        "id": "027297942"
      },
      {
        "label": "Classes dirigeantes",
        "id": "027223345"
      },
      {
        "label": "Hauts fonctionnaires",
        "id": "027322610"
      },
      {
        "label": "Élite (sciences sociales)",
        "id": "027225224"
      },
      {
        "label": "Pouvoir (sciences sociales)",
        "id": "027365581"
      }
    ],
    "llm_scores": [
      {
        "label": "État",
        "score": 1,
        "id": "027297942"
      },
      {
        "label": "Hauts fonctionnaires",
        "score": 0.95,
        "id": "027322610"
      },
      {
        "label": "Classes dirigeantes",
        "score": 0.9,
        "id": "027223345"
      },
      {
        "label": "Élite (sciences sociales)",
        "score": 0.9,
        "id": "027225224"
      },
      {
        "label": "Centralisation administrative",
        "score": 0.8,
        "id": "027465853"
      },
      {
        "label": "Pouvoir (sciences sociales)",
        "score": 0.8,
        "id": "027365581"
      },
      {
        "label": "Élite (sciences sociales)--Histoire",
        "score": 0.7,
        "id": "027225224--02726470X"
      },
      {
        "label": "Fédéralisme",
        "score": 0.1,
        "id": "027826538"
      },
      {
        "label": "Service militaire obligatoire",
        "score": 0.1,
        "id": "050549928"
      },
      {
        "label": "Armée de métier",
        "score": 0.1,
        "id": "030768268"
      },
      {
        "label": "Monarchie",
        "score": 0.05,
        "id": "050124277"
      }
    ]
  }
}

En 2024, le service des bibliothèques de l’université de Strasbourg s’est lancé dans un chantier autour des identifiants des structures de recherche dans le référentiel ROR et par extension dans IdRef et AuréHAL.

Pourquoi ce chantier ?

Depuis plusieurs années, particulièrement dans le cadre de sa politique de science ouverte,  l’université de Strasbourg porte une attention spécifique aux identifiants de la recherche : l’archive ouverte institutionnelle univOAK s’appuie notamment sur les identifiants IdRef pour ses chercheurs et ses structures. De même, l’équipe en charge des thèses travaille régulièrement à la mise à jour, toujours dans IdRef, des Ecoles doctorales de l’université.

A l’été 2023, le service des bibliothèques commence à s’intéresser aux identifiants ROR pour ses unités de recherche. Un premier inventaire réalisé à cette époque montre une couverture très parcellaire des unités de recherche strasbourgeoises dans ROR. Nous saisissons donc cette occasion pour proposer à notre direction de la recherche de mettre à jour le référentiel ROR pour les unités de recherche de l’université.

Après échanges avec la direction de la recherche, il est décidé d’attendre 2024 pour commencer les mises à jour dans ROR. En effet, le nouveau contrat quinquennal de l’université, qui a débuté en 2024,  ayant fait évoluer le paysage des unités de recherche de l’université (fusions, éclatements, changement de noms, de tutelles, etc.), il a donc semblé plus pertinent d’attendre les changements de 2024 avant de se lancer dans cet important chantier.

Et tant qu’à plonger tête la première dans nos structures de recherche, l’occasion était parfaite pour faire également un état des lieux dans IdRef et AuréHAL, référentiels sur lesquels nous gardons un œil depuis plusieurs années mais dans lesquels nous n’avions jusqu’à présent pas fait d’opération de vérification systématique.

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.

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.

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.

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.