Cet article décrit comment nous avons procédé pour obtenir des corps de fichiers XML-EAD à partir de tableaux de données. Nous avons voulu présenter cette technique à nos collègues archivistes, quelle que soit leur structure, en espérant qu’elle leur permette d’obtenir des fichiers complexes à partir d’outils simples. Il s’agit de propositions expérimentales qui pourront certainement être améliorées et gagneront à être partagées.

Seul un tableur ordinaire est nécessaire pour aboutir à ce résultat ; nous avons utilisé LibreOffice Calc, mais des fonctionnalités quasi-identiques se retrouvent par exemple sur MicrosoftOffice Excel.

Les outils du quotidien : les logiciels bureautiques

Dans les faits, les fonds sont couramment gérés, et parfois décrits, au moyen d’outils plus ordinaires que des éditeurs XML, et notamment les suites bureautiques usuelles¹ : instruments de recherche réalisés sous traitement de texte, tableaux de récolement, …

Les tableurs se prêtent à bien des usages ; ils présentent aussi l’avantage de pouvoir segmenter l’information. Le contenu des différentes balises de description XML-EAD² se trouve ainsi déjà isolé. Nous avons donc cherché à récupérer ces chaînes de caractères et à les enchâsser dans la syntaxe XML afin d’obtenir des fichiers le plus facilement possible.

Le « tableau magique »

Une technique assez répandue dans nos services consiste à intercaler dans le tableau d’origine des colonnes contenant les balises manquantes, puis dérouler ces balises jusqu’à la dernière ligne du fichier. Il est ainsi possible de convertir rapidement des fichiers massifs avec jusqu’à plusieurs milliers d’unités de description.

On obtient dès lors le corps d’un fichier XML-EAD qu’il est possible de copier/coller dans un fichier XML, en le débarrassant au besoin des tabulations qui marquent le passage d’une colonne à l’autre, et d’éventuelles balises vides dues à des cellules non renseignées. Il ne reste qu’à composer l’introduction et ajouter les dernières balises de clôture.

C’est ce principe que nous avons essayé de développer pour pouvoir l’appliquer à des données plus hétérogènes. Les formules évoquées sont décrites plus en détail en annexe à ce billet, ci-dessous.

Quelques formules de tableur

Nous avons commencé par dissocier le tableau de données original du code XML que nous en tirions, en travaillant sur une autre feuille de calcul du même tableau.

Il est possible d’y appeler les données contenues dans la première feuille au moyen d’une formule simple : sur LibreOffice Calc, « $data.A1 » appellera le contenu de la cellule A1 de la feuille de calcul « data » du même fichier.

La formule de concaténation (une simple esperluette “&”) permet d’assembler des contenus de cellules et des chaînes de caractères, ces derniers entre guillemets droits³ :

Il est aussi possible de conditionner l’ajout d’une chaîne de caractère à un critère quelconque, comme le fait qu’une cellule soit renseignée, ou qu’elle soit remplie d’une certaine façon. Cette opération utilise la fonction SI, dont la syntaxe est la suivante : SI([test];[résultat si positif];[résultat si négatif]). On peut donc ajouter des membres au code dans la situation où le contenu des balises correspondantes est renseigné ; cela évite d’avoir par la suite à nettoyer les balises vides.

Grâce à ces deux fonctions, il est possible d’obtenir une syntaxe complexe et de générer du code XML-EAD à partir d’un fichier de données hétérogène, sans avoir à le nettoyer comme avec la technique du tableau magique.

Les « formules magiques »

Traiter des données hétérogènes

Nous venons de voir qu’une formule conditionnant l’appel de certaines informations au fait qu’une cellule soit renseignée trouve immédiatement son utilité en limitant la présence de balises vides : le code n’intercalera des balises que si la cellule qu’elles doivent encadrer est renseignée.

L’utilisation de conditions pour ajouter ou non certains membres du code permet surtout de varier la syntaxe selon des critères choisis. Il devient ainsi possible d’envisager des structures plus complexes, comme l’enchâssement de plusieurs niveaux de description au sein d’intitulés de regroupement, dès lors que le tableau de données original aura été rempli de manière à ce que cette hiérarchie puisse correspondre à un test traduisible dans la formule (dans l’exemple qui suit, il s’agit d’une colonne correspondant au niveau du titre dans la hiérarchie retenue).

A priori, chaque nouvelle ligne du tableau correspondra à l’ouverture d’un niveau de description <c/> ; mais la position de la balise fermante « </c> », qui englobera ou non les lignes suivantes, déterminera leurs relations hiérarchiques (descendantes ou collatérales).

Il existe plusieurs possibilités pour obtenir ce résultat. Celle que nous avons adoptée nécessite l’ajout d’une colonne dédiée au « niveau hiérarchique », qui pourra être renseignée par une valeur numérique : « 1 » pour les titres de premier rang, « 2 » pour leurs divisions, « 3 » pour les sous-divisions, …

Le principe est d’introduire dans la “formule magique” un test qui soustraira le niveau de la ligne suivante à celui de la ligne en cours ; si le résultat est inférieur à 0, il s’agit d’un sous-ensemble et il n’est pas nécessaire de fermer l’unité de description ; en revanche, si cette soustraction est égale ou supérieure à 0, la ligne suivante est au moins de rang égal et il faut fermer l’unité de description. En outre, si le résultat est supérieur à 1, la ligne suivante est de rang supérieur et il faut donc au moins une deuxième balise fermante, etc.

Il faut donc procéder à une série de tests en cascade, autant que le plus grand décalage de niveaux hiérarchiques successifs dans la description (3 dans notre exemple). Ces tests successifs peuvent être juxtaposés à la suite l’un de l’autre ou enchâssés l’un dans l’autre (cette dernière possibilité entraîne sans doute moins de calculs).

Prendre en compte la communicabilité des informations

Conditionner la syntaxe à un test quelconque peut également permettre d’automatiser l’occultation de certaines informations en minimisant les interventions manuelles.

Ainsi, l’intégration de certains champs (noms de personnes utilisés comme intitulés, description du contenu, …) peut être subordonnée à des critères variés : date associée à ce niveau de description (valeur inférieure ou supérieure à un seuil défini en composant la formule), ou saisie manuelle dans le tableau d’une colonne « communicable : oui/non ». Toutes les informations sont présentes dans le tableau de données, et le code XML généré ne contiendra que ce qui sera jugé communicable ; dès que le critère de communicabilité aura évolué (passage du temps, changement de la réglementation), il suffira de modifier la formule pour générer par la suite, très rapidement, un nouvel instrument de recherche.

Relier description et images d’un fonds numérisé

Les fonctions des tableurs peuvent aussi faciliter le croisement des références pour rassembler des données issues de plusieurs tableaux.

Une infinité de situation est possible ; nous avons été confronté à cette situation dans le cadre du projet de numérisation des dossiers des dénaturalisés de Vichy. En effet, nous disposions de trois outils distincts : une base de données nominative convertie en fichier XML puis en tableau de données, un tableau de récolement matériel organisé par dossier (chaque dossier correspondant à un ou plusieurs individus), et enfin les tableaux fournis par le prestataire de la numérisation, qui associaient les noms des fichiers produits aux numéros des dossiers (en plusieurs tranches successives).

Dans cette situation, le numéro du dossier, normalisé et unique, nous a servi d’identifiant afin de relier toutes ces informations et de les reprendre dans chacune des fiches individuelles. La difficulté de cette situation était de lier à un fond sériel et numérique un instrument de recherche classé par ordre alphabétique des individus concernés.

Convertir des bases de données

D’autres perspectives se dessinent avec la prise en charge de bases de données. N’ayant pas toujours la possibilité de participer à l’élaboration des exports de données qui nous sont versés, nous avons dû imaginer comment traiter des bases de données parfois redondantes ou partiellement complémentaires afin de produire des instruments de recherches intellectuellement satisfaisants.

L’exemple ci-dessous propose un moyen de hiérarchiser les informations obtenues par un export redondant (en prenant comme critère le changement du contenu d’un champ d’une ligne à l’autre), et de rétablir la hiérarchie entre deux niveaux de description.

Conclusion

Avec un peu de pratique, ces techniques permettent de constituer le corps d’instruments de recherche à la syntaxe complexe et parfois massifs. L’introduction reste à composer à la main, mais le gain de temps reste appréciable ; les tableaux peuvent en outre être complétés par des équipes qui n’auront pas nécessairement à se plonger dans les arcanes du langage XML pour pouvoir commencer à saisir.

Nous espérons que ces astuces expérimentales pourront rendre service et faciliter la production d’instruments de recherche encodés en XML-EAD. Bien d’autres applications pourront être élaborées à partir de ces principes.

---

Annexes

Les techniques présentées ici ont progressivement été développées et mises en œuvre à l’occasion de plusieurs projets : les registres de Londres ; les décrets de naturalisation indexés par le projet participatif Natnum ; le fichier du bureau du Sceau et les dossiers des dénaturalisés de Vichy. Voici quelques remarques sur leur application et un aide-mémoire des formules qui nous ont été les plus utiles.

Considérations pratiques

L’utilisation de ces « formules magiques » est bien commode, mais le temps nécessaire à leur élaboration ne se justifie pas toujours. Elle est particulièrement adaptée lorsque :

● Les données concernées sont relativement sérielles ;

● Les données concernées représentent beaucoup de lignes, et leur arrangement à la main demanderait trop de temps ;

● Les données sont amenées à être mises à jour (tranches ajoutées, ajout d’images après numérisation,…).

Retrouver une coquille ou une erreur quelconque peut s’avérer plus lisible dans un tableau de données que dans le code XML ; en modifiant les cellules sources, le code de la feuille XML se met à jour de lui-même.

En cas de modification à apporter à la structure de l’instrument de recherche (ajout d’avertissement, réorganisation des informations, …), passer par un tableau de données permet d’appliquer la modification systématiquement et éventuellement plus rapidement qu’à la main dans un éditeur XML.

Les tableaux de données peuvent aussi être manipulés plus facilement qu’un fichier XML : il est possible d’en réordonner les lignes selon d’autres critères au moyen d’un tri sur une colonne choisie.

Les données étant déjà proprement délimitées, il est possible de les exporter en totalité sous la forme d’un jeu de données, ou partiellement afin de circonscrire des ensembles thématiques, chronologiques, géographiques ou typologiques, préparer de quoi générer une carte, etc.⁴

Selon la complexité des formules et la taille des données à traiter, le nombre de calculs et de tests à effectuer peut cependant devenir assez lourd. Il peut alors être opportun de désactiver la mise à jour des données ; chaque mise à jour nécessitera ensuite de relancer tous les calculs du fichier par la touche F9.

Il est tout à fait possible, enfin, de n’utiliser que « partiellement » les formules magiques, par exemple avec une syntaxe simple dans une colonne unique, au sein d’un “tableau magique” ordinaire.

Mémento : quelques fonctions utiles

Les fonctions les plus utiles ont été répertoriées ici avec quelques astuces pour en tirer le meilleur parti. Nous avons privilégié la syntaxe LibreOffice, mais l’équivalent se retrouve sur Microsoft Excel.

Concaténer

Afin de juxtaposer des chaînes de caractères saisies directement ou contenues dans des cellules, il suffit d’utiliser l’esperluette « & ». Des guillemets droits permettent d’introduire du texte saisi directement :

=A1&"blabla"

donnera :

[contenu de la cellule A1]blabla

Afin d’intégrer des guillemets droits dans le code lui-même, il faut les doubler :

="""blabla"" "&"blabla"

donnera

"blabla" blabla

Condition

La plupart des fonctionnalités que nous avons explorées ici reposent sur des conditions : cellule renseignée ou non, différence d’une ligne à l’autre, comparaison d’un champ avec une valeur prédéfinie, etc. Ces mécanismes reposent sur la fonction SI, composée de trois éléments : le test logique (p. ex. « A1>A2 » ; « A1=A2 » ; …), le résultat attendu si le test est positif, et le résultat voulu en cas de test négatif. Laisser l’un de ces deux derniers arguments vide ne renverra évidemment rien dans le cas envisagé⁵.

SI([test];[résultat si positif];[résultat si négatif])

Il est possible de discriminer une cellule renseignée ou non au moyen du critère suivant :

[cellule à tester]<>""

Ce test peut s’interpréter comme “la cellule est-elle différente (strictement supérieure ou inférieure) de rien”, c’est-à-dire “contient-elle quelque chose ?”

Paramétrer le format d’affichage des dates

Le format des dates saisies dans un tableur est souvent plus ou moins automatisé, ce qui peut susciter quelques mésaventures lors de la prise en main de l’outil pour un nouveau projet et que chaque date saisie change immédiatement de format.

Bonne nouvelle cependant, à partir du moment où une date a été reconnue comme telle et correctement interprétée par le tableur, quelle que soit sa forme (« 11 février 1821 », « 11/02/1821 », « 11 fév. 1811 », « 1821-02-11 », etc.), il est possible de l’intégrer dans le code XML selon la forme voulue au moyen de la formule TEXTE, en spécifiant le format voulu après la référence de la cellule.

Ce bloc TEXTE([cellule];[format]) peut ensuite être mêlé à la formule magique ; ainsi, pour obtenir une balise <unitdate/> contenant une date en toute lettre et sa correspondance normalisée en attribut, on peut utiliser le code suivant :

=...&"<unitdate normal="""&TEXTE(A2;"aaaa-mm-jj")&""">"&TEXTE(A2;"J MMMM AAAA")&"</unitdate>"&...

constater l’existant : nb si

La fonction NB.SI permet normalement de dénombrer les cellules répondant à un critère donné dans une plage définie : NB.SI([plage];[critère]). Un résultat supérieur à 0 sera interprété comme un résultat (logique) positif : cela signifie que cette fonction peut être utilisée comme test d’une condition.

Ainsi, il est possible de conditionner l’insertion d’une chaîne de code à la présence d’une suite de caractère ou à l’identité de deux cellules, soit que l’on dispose par ailleurs d’une liste d’identifiants pour intégrer ou au contraire masquer une série de références, soit que l’on veuille s’assurer que la référence existe par ailleurs avant d’y faire appel (c’est le cas décrit plus loin).

Accorder deux tableaux : la fonction « recherche »

Autre outil très performant, la fonction RECHERCHE permet de rechercher la correspondance entre deux lignes issues de feuilles de calcul différentes, et de renvoyer un champ déterminé.

Cette formule nous a permis de compléter automatiquement les noms de fichiers issus de la numérisation d’un fonds massif pour les intégrer à leur instrument de recherche ; dans ce cas, nous disposions d’un tableau détaillant les personnes concernées (à partir duquel a été généré l’instrument de recherche), et un tableau de récolement fourni par le prestataire de numérisation, associant au numéro de dossier (également présent dans la première table) les noms des fichiers extrêmes.

La syntaxe de cette formule est un peu plus délicate que les autres :

=RECHERCHE([cellule de la table de base à retrouver];[colonne où chercher];[colonne de la cellule à renvoyer])

Ainsi, si notre identifiant unique se trouve dans la colonne A de la feuille de calcul de base et qu’une autre feuille de calcul “ref” comporte cet identifiant dans sa colonne B et l’information qui nous intéresse dans sa colonne C, la formule à écrire en B2 de la première feuille sera :

=RECHERCHE(A2;$ref.B:B;$ref.C:C)

Une précision cependant, pour que la formule renvoie un résultat pertinent, il faut que la table dans laquelle s’effectue la recherche soit triée en fonction de la colonne de l’identifiant commun.

Des anomalies peuvent aussi survenir s’il n’existe pas de correspondance ; c’est pour cela que notre exemple des dossiers de dénaturalisés⁶ se trouvait enchâssé dans une fonction vérifiant l’existence d’un identifiant commun avant de lancer la recherche :

SI(NB.SI($numerisation.C:C;L2);RECHERCHE(L2;$numerisation.C:C;$numerisation.N:N);"")

1. Voir le rapport récemment diffusé Classement et description archivistiques : pratiques à l’échelle mondiale, Siân Wynn-Jones & Margaret Crocket, Conseil international des archives, 2020. [↩]
2. Voir le Description archivistique encodée. Dictionnaire des balises, Society of American Archivists (trad. par le groupe AFNOR CG46/CN357/GE3), 2004. [↩]
3. Pour insérer des guillemets sans qu’ils soient considérés par le logiciel comme un séparateur, il faut les doubler — sans oublier les guillemets qui entourent les chaînes de caractères ; notre guillemet doublé peut donc se retrouver lui-même suivi, précédé ou entouré de guillemets. [↩]
4. Voir les exploitations du fichier central de la sûreté nationale récemment partagées dans ce carnet par Maïwenn Bourdic : “Visualiser le fichier central de la sûreté nationale” (26 avril 2021) et “Croiser le fichier central de la sûreté nationale avec d’autres ressources” (14 septembre 2021). [↩]
5. Le programme peut, selon les réglages, renvoyer alors un 0 ou un véritable vide ; sur LibreOffice Calc, ce paramètre est réglé par Outils>Options>LibreOffice Calc>Affichage>Valeur zéro. [↩]
6. “Relier description et images d’un fonds numérisé“, plus haut. [↩]

---

---