Résorber les sources d’erreur : améliorations de l’export Visio_controle
Dans Calames, comme dans d’autres bases, la méthodologie des Chantiers Qualité menés par l’Abes repose sur plusieurs principes communs. L’un des plus importants consiste à éliminer d’abord les sources d’erreurs afin d’éviter qu’elles ne se reproduisent, avant d’entreprendre le traitement rétrospectif des anomalies déjà présentes dans la base.
Dans Calames, en complément des messages de sensibilisation adressés au réseau, cette démarche repose principalement sur l’amélioration de l’outil “historique” de contrôle qualité : l’export Visio_controle, très fortement recommandé avant toute publication dans Calames – et largement utilisé.
Cet export, qui génère un fichier HTML consultable dans le navigateur de l’utilisateur, est produit par une transformation XSLT (Extensible Stylesheet Language Transformations) détectant les erreurs grâce aux conditions appliquées à chaque élément ou attribut EAD, et/ou faisant l’objet d’une Bonne pratique EAD. En plus de quelques statistiques sur le fichier EAD en en-tête, le fichier récapitule ensuite l’ensemble des erreurs repérées, classées par type, au fil du <archdesc> et des composants.
Cependant, bien que le contrôle de la validité des dates au regard de l’ISO 8601 existait déjà, il laissait passer un certain nombre de cas.
Il n’a pas été possible de contrôler la conformité des dates au moyen de l’expression régulière mise à disposition du réseau. En effet, les fonctions XSL interprétant les expressions régulières ne sont pas disponibles dans la version 1.0 d’XSL utilisée par le processeur XSL de l’outil Calames. Il a donc fallu adopter une autre logique pour le repérage des dates non conformes.
C’est un raisonnement (algorithme) matérialisé par un arbre de décision (cf schéma ci-dessous) qui a permis de lever les cas erronés et de renvoyer un message adapté à l’erreur rencontrée. Cet algorithme fonctionne en “entonnoir”, les erreurs étant hiérarchisées par phases, des plus générales aux plus précises. La validation d’une phase (comprenant un ou plusieurs tests) permet de passer à la suivante. Chacune des 4 phases vise à :
- 1ère phase : écarter les
<unitdate>/@normalqui contiennent un ou des caractères non accepté(s) par l’ISO 8601
- 2ème phase : déterminer si
<unitdate>/@normalcontient un intervalle ou une date
- 3ème phase (uniquement s’il s’agit d’un intervalle) : vérifier sa conformité = slash pour séparer les deux dates ; date de début antérieure à date de fin ; homogénéité de l’utilisation ou non de tirets entre les deux dates
- 4ème phase : valider la forme / syntaxe de la date ou, en cas d’intervalle, de la date de début et de la date de fin (par exemple : année commençant par 0,1 ou 2 ; cohérence entre mois et jour, etc.)
Pour illustrer ce billet, nous avons modélisé l’algorithme de contrôle des dates (<unitdate>/@normal) implémenté dans l’XSL selon la norme BPMN. Ce schéma de processus se lit de la manière suivante :
Chaque losange jaune contenant une croix est une recherche d’erreur sur un critère précis (par exemple, le premier caractère ne peut être que 0, 1 ou 2 car toute date doit commencer par une année).
- Si la date analysée est fausse selon ce critère : affichage du message d’erreur correspondant (les ronds rouges contenant une enveloppe rouge matérialisent les messages affichés contextuellement en fonction de l’erreur rencontrée)
- Si la date analysée est valide selon ce critère : le traitement se poursuit et passe au critère d’erreur suivant (les losanges jaunes contenant une croix sont à lire dans le sens des flèches sur le schéma).
Télécharger l’arbre de décision au format pdf
Du point de vue de l’analyse des caractères présents en NORMAL de <unitdate>, l’XSL procède à des calculs similaires à ceux exprimés dans l’expression régulière. Par exemple, lorsque l’XSL rencontre un premier tiret dans un chaîne de caractères en NORMAL de <unitdate>, elle compte les caractères présents avant et juste après ce premier tiret :
- avant le premier tiret, il ne peut y avoir qu’une année, le nombre de caractères doit donc être de 4
- juste après le tiret, il ne peut y avoir qu’un mois, le nombre de caractères doit donc être de 2
Ainsi, 1950-06 sera considérée comme juste, alors que 1950-1970 sera repérée comme erronée.
Repérage complet par un script Python
La période de trois mois – de mars à fin mai 2025 – prévue pour que les établissements repèrent les dates erronées s’est avérée trop courte pour de nombreux collègues du réseau. Seule une petite dizaine d’établissements ont envoyé des tableaux à l’Abes pour modification de masse, quelques-uns ayant procédé à des corrections manuelles et en ayant informé l’Abes. En outre, les problèmes réseau rencontrés fin avril et en mai qui ont impacté les applications Abes, dont Calames, n’ont pas aidé. Le chantier a donc été prolongé jusqu’à fin juillet 2025.
Face aux difficultés rencontrées par les établissements pour participer au chantier, l’Abes a décidé de procéder elle-même à un repérage exhaustif des <unitdate> erronés.
Une requête SQL a permis d’extraire plus de 1,1 million d’attributs NORMAL et de contenus textuels de <unitdate>publiés dans Calames à la mi-juin 2025. Malheureusement, les fonctions SQL, qui permettent d’embarquer l’expression régulière dans une requête, ne fonctionnent pas dans la base Calames. Ces plus de 1,1 million de NORMALne pouvaient donc pas être triés pour ne conserver que les dates non conformes dès l’extraction de la base SQL Calames. Et au vu de cette volumétrie, un repérage des dates erronées dans NotePad s’avérait inapplicable techniquement.
La solution choisie a donc été d’analyser les plus de 1,1 million de dates dans un fichierCSVextrait de la base Calames à l’aide d’un script Python. La puissance et la capacité de traitement du script permet en effet de balayer dans un temps assez rapide une telle volumétrie.
Ce repérage a permis d’établir qu’au 06/11/2026, 31 259 <unitdate> comprenaient un attribut NORMAL non conforme et 7 078 n’avaient pas d’attribut NORMAL. Le taux d’erreur à l’échelle de la base de production Calames entière est de 3,3% d’attributs NORMAL mal renseignés, dont 2,7% non conformes et 0,6% vides : ces taux d’erreurs très faibles confirment, au fil des années, le bon fonctionnement du contrôle qualité mis en place par l’Abes, ainsi que la grande vigilance des établissements à produire des données de très bonne qualité dans Calames.
Périmètre de repérage et fabrique du script Python
Deux raisonnements complémentaires ont été utilisés pour concevoir le script : la logique de l’expression régulière officielle de l’ISO 8601 combinée à celle conçue par l’Abes. Ces deux expressions régulières repèrent en effet des cas non conformes parfois légèrement différents.
Ces deux logiques ainsi que les expressions régulières correspondantes ont donc été spécifiées à une IA qui a créé le script. Le script embarque également un comparatif de la date de début et de la date de fin au sein d’un intervalle de dates, pour repérer les dates de fin antérieures à la date de début, seul contrôle intellectuel possible à coup sûr sur une large volumétrie de dates.
Le script obtenu, faisant tout de suite preuve d’une grande rapidité de traitement, a cependant fait l’objet de plusieurs itérations sur des échantillons de cas. Certains types d’erreur n’étaient en effet pas détectés par le script.
Parmi ces cas d’erreurs, le script n’identifiait pas les dates commençant ou se terminant par un ou plusieurs espaces parasites. Une requête SQL permettant de les détecter a été générée pour pouvoir intégrer ces cas au repérage.
Le script a été paramétré pour produire un fichier CSV en sortie contenant uniquement les dates à corriger : ce CSV, enrichi de quelques explications rapides, a été mis en ligne comme tableau de repérage à jour dans la documentation Calames.
Dater le passé = produire une donnée pour l’avenir : les enseignements du chantier
Des erreurs récurrentes pleines d’enseignements
Parmi les grands types d’erreurs revenant principalement dans les dates publiées dans Calames, on peut distinguer les erreurs manuelles des erreurs répétées sur de larges volumétries.
Parmi les erreurs manuelles commises très souvent, on retrouve les fautes de frappe, ou parfois la confusion entre NORMALet contenu textuel de <unitdate>.
Une erreur ambiguë quant à la manière dont elle a été produite, mais très répandue, est le tiret pour un intervalle de dates : 1950-1970 au lieu de 1950/1970, seul le slash étant valide pour séparer deux années. Autre exemple, la multiplication des slashs pour une même date : 1990/05/08 au lieu de 1990-05-08. Ces deux erreurs peuvent avoir été produites aussi bien par un catalogueur appliquant la même logique à toutes les dates qu’il saisit que par un outil de conversion en masse de données vers EAD.
D’autres erreurs indiquent davantage une production en-dehors de Calames, soit dans des outils autres, soit des données générées par des macros de tableurs ou moulinettes de conversions depuis d’autres formats informatiques vers EAD. C’est le cas par exemple de valeur comme « none », de NORMAL contenant des zéros multipliés, comme « 00004220 », ou de dates précédées ou suivies d’un slash, comme « 1932/ ».
En nombre à peu près équivalent à celles dont on peut penser qu’elles ont été produites à la main, ces erreurs interrogent quant à la récupération dans Calames de données provenant d’autres bases, pour lesquelles des flux d’import doivent être pensés, autant que pour la production en masse de données EAD.
Dans un moment où l’IA générative permet de produire des données EAD à partir de certaines sources en entrée et constitue une opportunité de massification potentielle de la production autant qu’un risque de diversification (quasi) infinie des sources d’erreurs, cette production en masse plus ou moins automatisée doit être réfléchie collectivement pour que la qualité d’une base nationale comme Calames soit préservée.
Préparer les données Calames pour de nouveaux modèles de données
Au-delà des questions de renouvellement d’outil, occasionnant une migration dans une nouvelle base de données, les modifications de données, risquant de mettre en exergue de manière encore plus marquée une mauvaise qualité de certains attributs ou éléments EAD, seront les conversions d’EAD 2 vers de nouveaux modèles.
Un test de conversion en RiC de fichiers EAD exportés de Calames, effectué par les Archives nationales et la société Sparna avec l’outil RiC-O Converter, en partenariat avec l’équipe Calames de l’Abes, en a donné un premier aperçu.
Plus que jamais, qu’il s’agisse du modèle actuel ou de futurs modèles, les dates constituent une donnée centrale, souvent répétée à différents endroits dans les modèles entités-relations, ce qui a une influence importante sur la découvrabilité d’un document et sa consultation par les chercheurs.
Étienne Naddeo, chargé de normalisation archives, manuscrits et collections patrimoniales
Consulter :
-
- https://punktokomo.abes.fr/2025/11/19/calames-retour-sur-le-chantier-qualite-ameliorer-les-dates-normalisees-dans-calames-2
- https://punktokomo.abes.fr/2025/10/09/les-documents-iconographiques-decrits-dans-calames-1-contours-dune-analyse-globale
- https://punktokomo.abes.fr/2025/07/01/calames-lia-au-service-des-chantiers-qualite-1