Skip to content

Calames IT ?

21/07/2014

« IT » pour « Instrument de travail », bien sûr.

logo CalamesPréambule

Ce billet vient à la suite d’une d’une discussion sur Twitter avec le responsable du réseau Calames alimentant le compte Calames de l’Abes.

Manifestement, des choses m’échappent (non, ce n’est pas ironique), et si je mets ici l’état de mes réflexions (qui en fait n’est qu’un avis personnel, mal informé de surcroît), ce n’est pas pour en faire une tribune, mais simplement pour prolonger l’échange : les 140 caractères de Twitter sont rapidement frustrants pour développer des argumentaires sur ce genre de dossier.

Donc j’expose ce que je comprends de la situation, à partir de quoi j’alimente ma réflexion sur ce dossier. L’objectif étant d’être contredit par des personnes mieux informées, venant apporter des infos complémentaires me permettant de comprendre pourquoi je n’avais rien compris.

Court rappel : l’EAD

eadL’EAD est un format XML inspiré de la TEI (autre format XML), développé pour permettre de structurer de l’information textuelle permettant de décrire toutes les informations nécessaires à un inventaire d’archives.

L’EAD est conforme à l’ISAD(G), norme de description des archives : cela signifie que l’ISAD(G) explique le type d’informations que doit contenir un inventaire d’archive. Et l’EAD fournit un ensemble de balises permettant de répondre à ces consignes.

L’EAD est apparu lorsque des services d’archives ont voulu mettre en ligne les inventaires d’archives jusque-là au format papier : cette transposition de la version papier vers une version en ligne ne se satisfaisait pas d’un PDF ou d’un fichier HTML : ces deux formats faisaient perdre toute la sémantisation des informations (si cette notion n’est pas claire, je peux préciser en commentaires).

Les archivistes ont donc récupéré la TEI, qui existait déjà pour baliser du texte en XML, pour l’adapter à leurs besoins spécifiques (concepts particuliers, qui devinrent des balises particulières).

Un éditeur EAD ?

Et donc, il y a ce projet, mentionné aux JABES 2014, évoqué dans l’édito d’Arabesques 73 : le projet de développer un outil national de saisie en EAD, en partenariat avec la BnF, qui est aussi intéressée pour ses propres projets d’archives et manuscrits.

Le constat est (je suppose) le suivant : pour l’instant, quand on veut faire un inventaire en EAD, on a le choix entre saisir du texte XML au kilomètre dans un éditeur XML, ou avoir un espace de masque de saisie très contraignant, où de toute façon les balises sont des balises et les attributs des attributs. Bref, il y a une petite aide sur le temps de saisie, mais ça reste assez pas top. Le projet consisterait donc (je suppose encore) à développer un masque de saisie pour l’EAD, comme peut le faire XMLMind XML Editor adapté à l’EAD (comme quoi Calames n’est pas le seul à écrire en EAD), avec la gestion de listes d’autorités — le tout en mode connecté à une base de données comme c’est le cas pour l’éditeur actuel.

En plus, concernant Calames en tout cas, le logiciel utilisé est propriétaire — et vu que les besoins sont nationaux, pourquoi ne pas envisager de développer une solution plus satisfaisante (et pourquoi pas open source ? j’ignore si c’est dans la feuille de route).

J’avoue que j’ai sursauté en apprenant l’apparition de ce projet. Mais c’est sans doute dû à mon propre parcours et la compréhension que j’ai développée de tout ça. Donc je vais prendre le temps d’expliquer le pourquoi de ma surprise.

Mon EAD à moi

Quand je me suis intéressé à l’EAD, c’était à l’Ecole des chartes. Pour ma thèse, j’avais des centaines de lignes Excel de description de monnaies médiévales dans un tableau interminable, et mon projet était le suivant : trouver la bonne manière de mettre en ligne ce qui était un tableur, mais qui pouvait devenir de la base de données.

Un inventaire de monnaies est toujours organisé en séries, avec une approche arborescente très comparable à ce qu’on trouve dans les fonds d’archives : en ce sens, l’EAD est bien plus adapté pour les décrire sous forme de « collections » que les notices Marc, qui par nature sont isolées les unes des autres.

Et vu ma situation de départ, je n’ai pas envisagé une seule seconde de saisir ces descriptions de monnaies en EAD :  le texte existait déjà, il ne s’agissait que de trouver la bonne manière de le convertir en EAD. Bref, de générer de l’EAD, pas de l’éditer.

D’où par exemple ce billet de 2007, sur la conversion d’Excel vers EAD (avec méthode pour regrouper les séries à partir de descriptions sous forme de notices).

L’EAD, c’est du XML

Mais au-delà de mon cas particulier, j’ai toujours entendu que XML n’était pas fait pour être saisi à la main : le XML est un format de manipulation de données. Il est très pratique, il est lisible en clair quand on l’ouvre dans un simple éditeur de texte, mais il est extrêmement verbeux.

En un sens, JSON serait plus adapté que XML si on a prévu de saisir les données au kilomètre.

Contrairement à ce qu’on pourrait être tenté de croire, l’EAD ne doit pas être mis en parallèle avec les formats MARC. MARC est un format beaucoup plus économe, conçu précisément comme étant un masque de saisie (200$a est plus simple à écrire que « Titre de forme », eh oui !). Ce n’est pas le cas de <unittitle></unittitle>.

Ensuite, je rappelle ce que j’ai écrit au début : l’EAD est venu comme outil à disposition des archivistes comme équivalent des inventaires d’archives publiés.

Dans une chaîne de publication, le XML est un outil extrêmement puissant : outre les capacités d’indexation sémantique grâce au choix de balises signifiantes (une balise de date, de lieu géographique, etc.), le XML permet de produire en sortie toutes sortes de formats : ainsi Revues.org stocke ses articles en TEI, pour les proposer des formats de lecture HTML, ePub et PDF. Et je ne parle pas des tables des matières et autres outils de navigation rendus possibles par le fait qu’un texte soit encodé en XML, et non en HTML par exemple.

Mais dans la chaîne de production de Revues.org, les auteurs de saisissent pas de la TEI. Celle-ci est produite grâce à un module de conversion (OpenText).

Bref, pour moi comme pour d’autres, le XML est un conçu comme un format intermédiaire qui vient s’insérer entre les formats de rédaction (Word, LateX, etc.) et les formats de diffusion (HTML, ePub, PDF, SMS).

D’où notamment mon billet L’EAD, c’est pour l’import-export.

L’EAD chez les archivistes

J’ai eu l’occasion d’utiliser deux outils du monde des archives utilisant l’EAD : Pleade et le portail européen des archives.

Dans ces deux cas, l’EAD est un format d’import. Ces 2 outils sont des plates-formes de diffusion d’inventaires en ligne, et non de saisie de ces inventaires.

Calames peut être mis en parallèle avec le portail européen : comme outil partagé pour le signalement. Mais le portail européen des archives s’adresse à des établissements ayant déjà des outils de production d’EAD (logiquement, même si pas toujours vrai), et n’envisage donc pas de proposer une interface de saisie.

Ils ne prennent pas en charge le mode de production du fichier EAD qui y est injecté. Et je ne connais (mais, je le répète, ma connaissance est très limitée) que Calames pour essayer d’assurer l’ensemble de la chaîne.

Je signale au passage que certains archivistes veulent que leur outil de gestion d’archives soit nativement en EAD (les expressions varient, mais c’est l’idée globale : que les infos sur leurs archives, stockées dans l’outil en question, soient en EAD). Ça n’a pas d’intérêt et ça ne veut rien dire.
L’EAD est un format de production d’inventaire. L’inventaire n’est qu’un objet de publication.  Ce qui est important, c’est que cet outil de gestion soit capable de produire de l’EAD (et éventuellement d’en ingurgiter : mais il faudrait voir d’abord s’il arrive souvent à un service d’archives de recevoir un fonds avec son fichier EAD attaché, en ayant comme mission de gérer ce fonds).

Court rappel : l’origine de Calames

J’ai pris le temps d’expliquer la genèse de mon propre positionnement.

L’honnêteté intellectuelle me contraint de dire que le besoin de manipuler (au sens : traiter à la main) les inventaires de Calames vient de son origine et n’a rien d’absurde : Calames naît de la conversion de Palme et du Catalogue général des manuscrits pour une mise en ligne via le format de  publication EAD. Ces origines sont rappelées dans la version finale du bilan de 6 années d’existence de Calames, mis en ligne le 17 juillet sur le site de l’Abes.

Évidemment, la conversion EAD de ces deux sources n’a pas produit un résultat parfait : il était donc nécessaire de reprendre ces données à la main, pour les corriger et les améliorer. Et pour que ça « prenne » auprès des établissements, il aurait été peu convaincant de leur dire : voici vos fichiers XML, maintenant corrigez-les.

Le besoin d’une interface facilitatrice (c’est la raison d’être d’une interface !), commune, est naturel. Et c’est vrai que les services d’archives qui produisent de l’EAD ne se sont jamais retrouvés dans une telle situation.

L’interface de catalogage : un problème à résoudre

Là où je ne peux qu’être d’accord avec l’Abes et la BnF, c’est que la situation actuelle est insatisfaisante. Les conditions dans lesquelles les collègues en bibliothèque décrivent leurs fonds d’archives sont contraignantes.

Mais pour moi, la solution que le projet prétend apporter (améliorer l’interface de saisie) est pourrie, car elle ne répond pas à un problème plus large.

Le problème plus large, c’est que dans ces établissements qui interviennent dans Calames, il n’y a pas d’outil de gestion des fonds d’archives et de manuscrits.

En disant cela, je fais peut-être une énorme erreur en croyant que ce qui existe dans mon SCD est vrai pour tout le monde. S’il vous plaît, rectifiez-moi et fournissez-moi des données chiffrées sur le nombre de BU qui ont mis en place un outil de gestion de leurs fonds d’archives.

Quoi qu’il en soit, ce que je constate dans mon SCD, c’est que si on veut avoir un outil de suivi des fonds à restaurer, ou des statistiques sur la consultation de ces fonds, ou la date du dernier inventaire (au sens de « récolement ») — 3 exemples de ce que permet généralement un « outil de gestion » — je n’ai rien. Eventuellement, je pourrai grapiller dans quelques tableaux Excel des informations éparses. Ce n’est pas là un « outil de gestion ».

Bref, on ne retrouve pas avec Calames l’articulation qu’on peut avoir pour le Sudoc entre un outil de signalement national, et des outils de gestion locaux.

Calames-et-rien

Prenons le problème par un autre bout : il est essentiel que les SCD se dotent de progiciels pour gérer leurs fonds d’archives et de manuscrits (et j’espère que le réseau Aurore ne me contredira pas !).

Car évidemment, ce n’est pas à l’Abes de fournir aux établissements ces outils de gestions de fonds d’archives et de manuscrits : ce sont des besoins locaux qui doivent relever des objectifs de chaque établissement.

Dans cette perspective, le projet d’améliorer l’interface de saisie en EAD de Calames est contreproductif) :

  1. côté établissements, ça permet aux responsables du signalement de ces fonds de moins souffrir, donc ça donne l’apparence qu’avoir un outil de gestion n’est peut-être pas si nécessaire que ça
  2. côté Abes (et BnF), ça oriente la charge de travail de l’équipe Calames vers l’interface de saisie, au lieu de travailler sur les modalités d’import (automatisés !) de données qui seraient exportées des systèmes locaux.

Ce même bilan de 6 ans de Calames contient son propre schéma, très intéressant, p. 13 (mais c’est moi qui ai entouré en rouge) :

import EAD dans Calames

Ce mode de fonctionnement existe déjà. Mineur, vraisemblablement.

Mais je regrette que les efforts se focalisent sur le catalogage natif, et que rien à ma connaissance (?) ne soit envisagé pour développer, favoriser, encourager les établissements à adopter des outils de gestion d’archives, en leur fournissant par exemple des éléments de cahier des charges concernant l’articulation à prévoir avec Calames.

La piste est évoquée (ce n’est pas rien, ce n’est pas beaucoup), p. 12-13 — et notamment la question du rôle du SGBM dans tout ça :

extrait Calames

Mais si Calames évoque le SGBM, je ne me souviens pas avoir vu le projet SGBM évoqué Calames. Est-ce le cas ?

Autres perspectives

Un risque serait de considérer le fichier EAD comme source d’information de référence, sur laquelle les responsables des fonds viendraient greffer des informations de gestion.

Je ne sais pas trop à quoi ça pourrait ressembler, du reste.

Ce que je veux dire, c’est que si on voulait aller vers une situation où la double saisie serait évitée, il me semblerait risqué de vouloir choisir l’information stockée dans Calames comme l’info de base, avec d’autres infos complémentaires (non redondantes) qui viendraient l’exploiter.

En effet, encore une fois, l’EAD est conçu comme un format visant à la mise en ligne d’inventaires d’archives. Les inventaires d’archives ne sont que des produits du travail courant des archivistes. Ils ne rendent pas compte de ce qu’est une archive.

Il me semble que le point de départ, là où l’information sera vraiment créée, devra s’appuyer (à terme…) sur le modèle conceptuel de description archivistique en cours d’élaboration. Ce modèle permettra de créer des environnements de saisie et de gestion. Et les outils qui mettront à disposition ces environnement seront en mesure d’exporter en EAD les données décrites.

Vous noterez que le sens serait inverse de celui du Sudoc : c’est logique ici puisque le partage des notices bibliographiques n’a pas d’intérêt. En revanche les environnement de saisie (outils de gestion) doivent impérativement être capables de se se connecter aux référentiels comme IdRef pour alimenter les descriptions des fonds.

Si on pousse la logique un peu plus loin, il me semble que Calames n’est pas un outil de mise en ligne d’inventaire (tel que l’EAD était envisagé). On peut certes y naviguer dans les fonds (et c’est important, car la présence d’un document au sein d’un fonds est porteur de sens) — mais à l’usage Calames est avant tout un outil de recherche mutualisé, plus qu’un outil de publication électronique d’un certain type de documents, des inventaires d’archives.

Ce n’est donc pas vraiment parce que l’EAD est parfaitement structuré pour satisfaire aux besoins de navigation et de recherche que ce format a été adopté : l’EAD s’est imposé parce que c’est un format bien répandu, comme un standard.

Et plus exactement, en l’occurence, comme un standard d’échange, en fait.

D’où mon billet sur l’import-export : l’EAD est pertinent pour Calames (comme format en entrée) parce qu’il existe par ailleurs des outils pour produire cet EAD.
Ici, l’EAD est donc un format intermédiaire entre deux applications.

En ce sens, plutôt que de le comparer à MARC, on pourrait le comparer à de l’iso2709.

Conclusion

En prenant le temps d’y réfléchir, je trouve dommage que le SGBm, puisqu’il est censé prendre en considération tous types de ressources que les bibliothèques doivent gérer, n’ait pas — à ma connaissance — été saisi comme une opportunité pour mettre à disposition des établissements un outil de gestion de leurs fonds d’archives et de manuscrits.

Sur Twitter, certains tweets de J.-M. Feurtet m’ont permis de réaliser que certains aspects du problème m’étaient inconnus.

Par exemple, un tel circuit, fonctionnant sur des exports (modèle du portail européen des archives, même si dans ce cas-là il n’y a pas d’automatisation avec logiciels des services qui l’alimentent), ne permettrait plus de continuer à suivre les bonnes pratiques de l’EAD en bibliothèque. Je reconnais ne pas connaître ces bonnes pratiques. Mais je ne vois pas en quoi des spécifications à l’export ne pourraient les mettre en application. D’autant que les archives aussi ont des « bonnes pratiques ».

Bref, j’invite chaleureusement aux explications pédagogiques🙂

Quant à moi, je vais aller lire cette étude sur Calames, qui vient d’être mise en ligne.

https://bibliotheques.wordpress.com/2013/10/07/lead-cest-pour-limport-export/

https://bibliotheques.wordpress.com/2013/10/07/lead-cest-pour-limport-export/

24 commentaires
  1. tahwx permalink
    21/07/2014 07:49

    PDF et html « font perdre » la sémantique.

    Ou : ne réalisent pas la sémantisation.

  2. 21/07/2014 08:16

    @tahwx : Merci, c’est corriger corrigé🙂

  3. Johnlepic permalink
    21/07/2014 08:30

    « ces deux formats faisaient perdre toute la sémantisation des informations (si cette notion n’est pas claire, je peux préciser en commentaires). »

    Ce serait bienvenu pour HTML (sachant que ça englobe aussi xhtml) et pour l’emploi du passé (aujourd’hui, il y a des techniques pour conserver la sémantisation).

  4. 21/07/2014 08:38

    @Johnlepic : c’est pas faux. Mais la TEI et l’EAD sont nées avant cette époque, et ont construit leur « marché » en grande partie sur l’absence (ou quasi-absence) de sémantique dans le HTML.
    Est-ce que le fait que le HTML se soit enrichi dans cette direction va faire diminuer l’utilisation de certaines DTD ? Pas absurde.

  5. Charlotte Maday permalink
    21/07/2014 15:22

    Bonjour,

    Au sujet des progiciels d’archives, le réseau Aurore (qui est en fait une section de l’Association des Archivistes Français) ne contredit absolument pas!

    Effectivement, la prochaine étape de beaucoup de services, apres les reprises d’arriérés d’archives non classées, c’est obtenir un progiciel de gestion des archives.
    Oui, nous en sommes encore pour beaucoup a gérer des kilometres d’archives avec des feuilles excel…
    Certains services ont cependant construit des logiciels « maison », qui permettent de gérer les entrées et sorties et quelques autres fonctionnalités, ceux qui sont dotés d’un progiciel totalement fonctionnel avec des extensions EAD sont une rareté et sont souvent le fait de structures archives dans des établissements de recherche prestigieux.

    Les logiciels pro qui existent sur le marché ont bien entendu des modules de production des IR en EAD avec export prévu, mais ne sont pas vraiment adaptés aux spécificités des services d’archives en EESR (et sont très chers).

    Des solutions open source existent également mais la majorité sont anglo-saxonnes…mais ce sont des pistes a creuser.

  6. 21/07/2014 16:46

    @Charlotte Maday : je me demande pourquoi une fonction d’export est conditionnée au fait d’avoir un logiciel haut de gamme. Techniquement, ça me semble moins exigeant que des fonctions de gestion.
    Mais bon, c’est ainsi…

    Alors il faut travailler sur les formats d’export disponibles, et des outils extérieurs à ces logiciels qui pourraient produire de l’EAD.
    C’est ce qui se passe aux AD06 pour alimenter le portail européen des archives : le logiciel en place ne fournit pas d’EAD. Ca n’a pas empêché d’alimenter le portail européen de plusieurs milliers d’items.

  7. 21/07/2014 18:37

    Désolée, je me suis mal exprimée. La fonction export est en fait une brique supplémentaire par rapport a des briques immédiatement utiles a l’activité de l’archiviste : gestion des espaces, éliminations, versements, communications. L’ajouter est bien sur possible mais comme tout a un cout en ce monde, il faut pouvoir justifier de ce besoin. Et même si c’est a déplorer, souvent ce n’est pas la priorité.

    Peut etre faut il dire ici que ces services d’archives n’ont pas vocation a conserver des documents historiques, ils partent aux Archives départementales ou nationales. Donc le besoin d’échanges d’informations inhérent à l’EAD n’est valable qu’a ce moment précis de la vie du document, a savoir son passage d’inutile a l’activité de l’établissement a utile pour des raisons historiques. Autant dire que le besoin de produire des IR directement en EAD est, comment dire, relativement modeste et ponctuel.

  8. 21/07/2014 19:21

    @lotteauxfraises : on n’est alors pas du tout dans le cas de services alimentant Calames, il me semble.
    C’est cela que je pointais du doigt — et de ce que je comprends de ce dernier commentaire, les archivistes en ESR, le réseau Aurore, ne se préoccupent pas des archives abritées dans les collections des bibliothèques (c’est une question, en fait). Pourtant les bibliothèques n’auraient-ils davantage pas besoin d’outils (conceptuels comme informatiques) pour gérer ces objets ?

  9. 21/07/2014 20:21

    Bon, au vu du tweet, je suis obligé de commenter le billet !😉
    Mais tout comme vous, mes commentaires qui suivront sont à prendre avec précaution d’autant que je risque de partir dans différentes directions et que je me pose des questions similaires:
    Quelques remarques en vrac:
    – Le logiciel que vous évoquez est bien celui en lien avec l’equipex Biblissima qui avait publié une annonce pour recruter un dev à l’université de Caen (http://www.biblissima-condorcet.fr/fr/actualites/offre-emploi-universite-caen-basse-normandie-ingenieur-etude-informatique) ? (je n’ai pas encore lu l’occasion de lire la revue.
    – Pour le projet APEnet, ils utilisent parfois le protocole OAI-PMH mais ne demande pas du DC dans la partie mais directement du XML-EAD (ce qui est « bourrin » car à chaque modifs, on doit relancer tous les fichiers XML). Ce choix est du au fait qu’ils souhaitaient garder le context de la ressources (au tout début, tentative avec OLAC mais sans succès)
    – Au niveau français, pour le système de publication d’IR, il faut aussi recontextualiser le choix de l’EAD avec le futur projet PNIA dont la AMO a été choisie en janvier 2014. La lecture du CTTP pour choisir l’AMO en disait long sur les choix techniques de ce futur portail national des archives.

    Après, je ne sais pas si ce que j’écris est utile donc je m’arrête là (et j’en garde un peu sous le coude pour l’éventuelle réponse ;-))

    Antoine

  10. 21/07/2014 20:24

    Le fait est que dans le réseau Aurore il y a plusieurs types de services : les archivistes en université ou en rectorat effectivement ne s’occupent pas vraiment d’archives historiques, seulement pour les transmettre aux AD/AN (au passage, je signale l’existence de SOSIE pour les Archives nationales : http://www.archivesdefrance.culture.gouv.fr/static/5044) , mais il y a aussi les organismes de recherche, et la il y a des archivistes dans des structures de bibliotheque, des archivistes qui sont responsables de fonds historiques, etc… donc si, le réseau Aurore se préoccupe des archives abritées dans les bibliotheques, et beaucoup de services d’archives d’Aurore alimentent aussi Calames…Par ailleurs, comme je l’avais un peu évoqué a la journée Calames, les services intermédiaires pourraient aussi utiliser Calames comme point d’entrée unique pour le signalement des fonds d’archives de l’ESR. Ca peut eviter des maux de tete aux chercheurs ou lecteurs qui voudraient par exemple des archives sur 1 domaine de recherche ou les archives d’1 chercheur qui a travaillé dans plusieurs établissements par exemple…
    En tous cas c’est possible dans l’EAD, le lieu de conservation est une balise différente du producteur…

    Et nous sommes super-pour travailler avec les bibliotheques! en particulier sur ce type de projet très concret…

  11. Julien Pomart permalink
    22/07/2014 06:58

    Bonjour,

    J’aimerai faire plusieurs remarques.
    J’ai l’impression que l’on parle de l’EAD comme d’un format utilisé partout de la même manière: les services d’archives l’utilisent de manières différentes, et je sais que la pratique de l’EAD par Calames n’est pas adaptée à tous. Calames est avant tout fait pour les petites bibliothèques de l’ESR conservant des archives et devant publier des IR souvent créés par des bibliothécaires, et cela s’en ressent.
    Il s’agit clairement de cataloguer des archives et des manuscrits, comme son nom l’indique.

    De plus c »est un outil de publication et non de gestion, où est l’intérêt d’éditer l’XML?
    Comme je le lis dans cet article (que je trouve vraiment pertinent au passage), il faudrait plutôt s’interroger sur la nécessité d’un SGA pour répondre aux besoins des services au lieu de vouloir bricoler en surface.

    Pour finir, une interrogation: n’est-ce pas un peu tard pour se pencher sur l’évolution de l’EAD, alors que XML/RDF se profile à l’horizon?

  12. 22/07/2014 07:44

    @Julien Pomart : il me semble que je suis d’accord sur toutes les questions soulevées (y compris celles qui sont sous la forme de questions : ce sont aussi les miennes).

    Pour les bibliothécaires : « SGA » = « système de gestion d’archives » (un SIGB, mais sans le B)

    J’en profite pour éclaircir les acronymes utilisés par Antoine Courtin dans son commentaire :
    PNIA = Portail national interministériel des archives
    APEnet : autre nom du projet de Portail européen des archives
    OLAC (je ne connaissais pas) : Open Language Archives Community

  13. 22/07/2014 11:27

    Pardon pour les acronymes et merci Etienne Cavalié de les avoir développés.

    Je rejoins complètement l’avis sur l’EAD et la difficile articulation ou plutôt le paradoxe de position de cet encodage dans la chaine de traitement archivistique dans un SIA (système informatisé archivistique = SGB). A la fois être dans la logique traditionnelle de l’IR (signaler des fonds) mais également, comme c’est informatisé, l’utiliser pour en faire plus…
    Un cas concret de cette difficulté: L’articulation des IR en EAD dans un SAE (système d’archivage électronique) notamment pour respecter le SEDA. Le fait d’utiliser de manière détournée la DTD EAD pour faire entrer des valeurs fermés dans un pour ensuite l’utiliser afin de proposer des règles de gestion de tri et d’élimination montre bien cette ambivalence.

    Concernant l’évolution XML/RDF, une petite remarque:
    – Finalement le plus important est de réfléchir selon moi à une ontologie pour les archives qui pourrait ensuite être exprimée en RDF (et ensuite sérialisé en XML mais aussi en turtle, etc.) Un groupe de l’ICA (conseil international des archives) est actuellement en plein travail sur cette question sachant aussi que la société Anaphore a réalisé une ontologie pour les archives grâce à un travail de Thomas Francart.

    Et il est vrai que le nouveau schéma EAD3 est en plus très loin de faire l’unanimité.

  14. J-M Barbiche permalink
    22/07/2014 11:47

    Cher Etienne,
    il se trouve que j’ai abordé ces dernières années l’EAD côté ABES avec Calames puis côté B-M avec le CGM. Dans les deux cas, il s’agissait de traiter des fonds bien circonscrits. L’arborescence XML s’y prêtait remarquablement. Je n’avais nul besoin de gérer des informations de gestion, simplement de signaler des fonds jusque là invisibles.
    La gestion de fonds d’archives administratives relève d’une toute autre logique : dans les 2 expériences susnommées, je cumulais de façon plus ou moins officielle la responsabilité des archives courantes, il ne m’est jamais venu à l’idée de les traiter en EAD avec le même outil, simplement parce que les besoins, les moyens et la finalité sont différents.
    La facilité de prise en main de l’outil de l’ABES ainsi que la disponibilité et la compétence des collègues formateurs (merci à eux !) permettent à des personnes très éloignées du traitement d’archives de s’y mettre rapidement avec succès, en allant à l’essentiel. En B-M, nous dépendons du bon vouloir des collectivités et ce type de question peut être à mille lieux de leurs priorités, donc on bricole (en l’occurrence avec Notepad++ et pas mal de copier-coller…) et là encore on va à l’essentiel : mettre à la disposition des publics un fonds jusque là inaccessible.
    La principale difficulté, c’est que contrairement aux fonds documentaires traditionnels, ces archives sont très hétérogènes et chaque fonds demande un traitement différent, sans même parler de la gestion. Alors pourquoi pas une réflexion globale dans le cadre du SGBM, mais avec le souci d’un outil souple, facile d’utilisation, malléable pour s’adapter à des réalités documentaires et archivistiques très diverses.

  15. Violaine Challéat-Fonck permalink
    22/07/2014 12:01

    Bonjour,
    A titre d’information, les Archives nationales ont développé il y a quelques années Sosie, pour « Saisie en open office pour la structuration d’instruments de recherche en EAD », qui est un outil dont la prise en main est très aisée : c’est une feuille de style associée à du traitement de texte qui regroupe dans une boîte intitulée « Hiérarchie » l’ensemble des styles nécessaires à la saisie et à la structuration d’un grand nombre d’instruments de recherche produits par les Archives nationales conformément à la norme ISAD(G) et aux règles d’application de la DTD EAD. Ces éléments sont ensuite contrôlés et convertis par des outils bureautiques simples. On peut également utiliser Sosie pour rétroconvertir des instruments de recherche déjà saisis en traitement de texte.
    Depuis la mise en production du système d’information archivistique des Archives nationales (SIA), les instruments de recherche sous Sosie ont été importés dans le progiciel et peuvent être révisés et /ou publiés dans la salle des inventaires virtuelle des AN.

  16. 22/07/2014 18:05

    @Violaine Calléat-Fonck : effectivement, produire de l’EAD à partir d’un éditeur WYSIWYG en s’appuyant sur une feuille de style me semble une piste plus intéressante. J’ai été heureux d’apprendre la sortie de SOSIE, cycle de production OpenOffice->EAD que j’avais essayé de mettre en place en 2006 pour mon propre usage, mais pour lequel il me manquait des compétences techniques.

    Cela dit, dans le cas dans lequel je me trouvais, je n’avais pas à gérer des fonds de monnais : je visais simplement à les décrire.
    Or pour moi la situation est toute différente quand il s’agit de services d’archives et de bibliothèques : ils doivent à la fois décrire leurs ressources (à usage interne et public) et ils doivent aussi les gérer.

    On peut aussi produire des inventaires « thématiques » (j’ai oublié le terme technique — guide des ressources ?) qui ne correspondent pas à l’architecture des fonds : c’est là un cas où il faut effectivement produire un inventaire pour lesquelles il n’y a pas de source initiale d’information à laquelle puiser.

    Mais dans le cas le plus fréquent, on produit des inventaires correspondant à nos fonds. Et dans ce cadre, utiliser un outil pour chaque volet (gestion/publication) me semble au moins dommage.

  17. 22/07/2014 18:10

    @J.-M. Barbiche : Merci beaucoup pour ton retour d’expérience, car c’est précisément ce qui me manque. J’ai conscience que je parle de l’extérieur, n’ayant jamais eu ni à travailler dans Calames, ni à gérer/traiter des fonds d’archives.
    C’est bien pour cela que j’ai tenu à exposer quelles étaient les bases de mon raisonnement, et ce billet est là pour susciter d’autres approches, plus proches du terrain. Donc merci encore.

    Je ne prétends absolument pas qu’il soit impossible d’alimenter directement Calames. L’interface, quoique contrainte par l’architecture peu souple de ce qu’est une DTD (avec des balises et des attributs), reste « alimentable » (et pour ma part je passe une partie de mes journées à écrire des feuilles XSL en code brut).
    Mais je trouve qu’on se satisfait trop facilement des tableaux Excel utilisés pour gérer nos fonds. On est peu exigeants au regard du professionnalisme que ça devrait impliquer.
    Mais je peux aussi comparer cela avec la gestion des congés : on peut tenir des années en gérant les congés (et les plannings) avec des feuilles Excel et des fichiers Word.
    On peut aussi bricoler un rétroplanning Gantt sous Excel.
    On peut même faire des organigrammes sous Word.
    Et puis on peut envisager de reconnaître qu’il y a des progiciels adaptés, bien mieux adaptés, pour chacune de ces tâches, et apprendre à les manipuler.

    En disant cela, je ne te renvoie pas à ton expérience en BM et BU, je renvoie simplement à la mienne : car je parle dans le vide, puisque je ne connais rien au marché (open source ou prioriétaire) des logiciels de gestion d’archives qui pourraient être adaptés pour les besoins d’un SCD.
    C’est précisément que je n’y connaisse rien qui me pose problème.

  18. J-M Barbiche permalink
    23/07/2014 09:57

    @Lully Le nœud du problème, c’est la distorsion entre l’exigence scientifique (ce que je veux faire avec mon fonds : le décrire finement, le mettre en ligne, le gérer, etc.) et la réalité des compétences, des moyens et du temps disponibles. Du coup, on établit des priorités et on renonce à une partie des objectifs.
    L’EAD a l’intérêt d’être utilisable dans plusieurs situations (B-U / B-M /Archives…), l’investissement consenti pour s’y former est largement payé de retour, un peu comme Excel qui s’apparente à un couteau suisse. Dans bien des cas, un autre logiciel ferait mieux l’affaire mais l’investissement pour s’y former efficacement (surtout s’il est riche et complexe) est sans rapport avec le résultat escompté. Sans compter que certaines formations peuvent être difficiles à trouver : combien de fois me suis-je dit que la connaissance de XSL m’aurait bien aidé… je n’ai toujours pas pu m’y mettre.

    Enfin, dans mon cas, ces questions ne représentent qu’une petite partie de mes fonctions, or si on ne « pratique » pas régulièrement tel logiciel ou langage un peu spécialisé, on perd très vite la main.

    Pour toutes ces raisons, je préfère une solution simple, utilisable pour traiter plusieurs problèmes. Tu me diras que ce pourrait être le SGBm… j’avoue que je ne suis plus ce dossier de près depuis 18 mois mais j’ai des doutes sur la faisabilité d’un système auquel on demanderait tant de fonctions aussi variées…

    Mais ce n’est qu’un avis personnel, mon expérience, avec notamment un passage de B-U à B-M, ne peut pas être généralisée.
    En tout cas merci pour ces réflexions, amitiés !

  19. 27/07/2014 14:00

    Bonjour,

    Je précise que je me situe côté archiviste, profession que j’ai exercée pendant 11 ans avant de gérer la société Anaphore.

    Il est intéressant et significatif que ce post de Lully suscite de nombreuses réactions.
    Néanmoins, il me semble que le fait que l’on parle autant du format EAD est en soi un problème. Si nous avions vécu une forme de rejet de l’EAD à son arrivée (nouveauté, de plus importée des USA !), au début des années 2000, on a maintenant au contraire l’impression que l’EAD est presque une fin en soi, en tout cas une évidence. Or, l’EAD n’est qu’un format de restitution – plus exactement un format intermédiaire : un format d’échange –, imparfait (même pas optimal dans son rôle de format d’échange), limité, amené à évoluer (voire à disparaitre).
    J’avais eu l’occasion d’intervenir lors d’un précédent billet ici (https://bibliotheques.wordpress.com/2013/10/07/lead-cest-pour-limport-export/) et de reprendre les très intéressantes réflexions de Bruno Bachimont sur la distinction à faire entre formats de travail et formats d’échange et les nécessaires limites de ces derniers.
    Antoine Courtin a parfaitement raison en soulignant que l’important, aujourd’hui, est de prendre de la hauteur en travaillant sur des modèles conceptuels pour s’inscrire, comme l’évoque Julien Pomart, dans le réseau des données liées Le Service interministériel des Archives de France (SIAF) suit également de près, à notre connaissance, ces questions.
    (Je me permets d’indiquer le lien vers le premier des deux post de Thomas Francart sur le travail que nous avons fait en collaboration avec lui : http://labs.anaphore.eu/penser-modeliser-pour-le-web-de-donnees-part-1/).
    Il est important, également, de prendre conscience que les métadonnées descriptives des ressources archivistiques ne peuvent certainement plus être restituées suivant un seul modèle : je ne parle même pas d’un seul format, mais bien au-delà. Les attentes, les besoins des publics étant distincts. Et, les bilans que l’on peut faire sur la mise en ligne de ces descriptions sont loin d’être positifs, ce que nous avons essayé de consigner sur notre blog (http://labs.anaphore.eu/la-description-archivistique-a-lere-du-numerique-part-1/ et post suivant).
    Par ailleurs, les besoins de convergence entre les métiers patrimoniaux sont une évidence, à laquelle les formats métier ne peuvent répondre.
    Certes, il n’existe pas encore de solution idéale, mais, dans le contexte actuel, stocker et donc enfermer les données descriptives dans une syntaxe particulière revient à hypothéquer dangereusement l’avenir, ceci sans même prendre en compte l’évolution en cours de l’EAD 2002 vers l’EAD 3. C’est pourtant ce que l’on voit assez couramment aujourd’hui ! Là encore, il est indispensable de prendre du recul, de redéfinir des objectifs pour éviter les impasses.

  20. 29/07/2014 14:28

    Tout d’abord, précisons qu’il n’existe pas encore de « projet de développer un outil national de saisie en EAD en partenariat avec la BnF » : nous n’en sommes qu’au stade d’une hypothèse de travail, qui ne peut devenir projet qu’après l’étude de faisabilité qui sera menée d’ici au début de 2015, et qui pourrait s’étendre à d’autres formats XML (TEI notamment).

    Une des racines des problèmes posés, et de l’intérêt soulevé, par EAD, tient aux « succès par défaut » qu’il a connus ces dernières années (possibilité de diffusion rapide, parfois couplée à des numérisations, via des outils comme Pleade ; collections iconographiques et fonds hybrides sortant de l’ombre…). Le choix de décrire des manuscrits en EAD (hors du champ de l’ISAD(G), et en l’absence même de règles de descriptions dans certains cas) pouvait être déjà considéré comme une première récupération ou entorse à l’orthodoxie. L’adoption d’EAD a amené à en faire à la fois un format de production et d’échange, mais je ne crois pas que cela soit spécifique aux bibliothèques françaises, et j’imagine que cela a pu être considéré comme un avantage ou une simplification. Les dangers les plus identifiés tenaient plutôt aux traitements documentaires brûlant trop d’étapes (lorsque l’encodage EAD n’arrive pas en bout de chaîne de traitement, mais dès avant – ou après : je ne connaissais pas l’exemple du SEDA, merci).

    Quand, à l’hypothèse selon laquelle « l’EAD n’est plus saisi (édité) mais produit (exporté) », j’ai twitté en réponse « …il faudrait sortir radicalement de la logique des Bonnes pratiques EAD »

    je voulais plus précisément écrire : sortir radicalement de la logique, non pas de ces recommandations elles-mêmes (on pourrait aussi bien en faire un schéma), mais des principes ayant amené à définir ces bonnes pratiques.
    Si l’EAD n’est plus édité mais exporté, c’est qu’on doit pouvoir composer le même produit échangeable par l’intermédiaire de n’importe quel outil de type formulaire stockant l’information dans une base de données relationnelles. L’adoption d’un tel principe permet de s’affranchir de bien des difficultés techniques (faible maniabilité de gros fichiers XML p.ex.). Or, s’il a été jugé intéressant par les (des) bibliothèques françaises de promouvoir l’EAD comme format de production, et de lui accorder une place au sein de la boîte à outils du catalogueur à l’instar de MARC, c’est que lui seul semblait permettre de décrire à la fois efficacement et fidèlement des « collections de manuscrits » qui se subdivisent bien souvent, partiellement, en fonds d’archives. Le caractère hybride (produire aussi du texte rédigé que des métadonnées qualifiées, non verbeuses – voeu pieux peut-être, mais qui permet de justifier qu’EAD existe indépendamment de la TEI) et souple de la DTD EAD, la structuration d’ensemble, la contextualisation, la modularité dans la profondeur et la précision que son utilisation autorise en permanence, l’existence d’éléments mixtes qui a été très largement exploitée par l’encodage et l’indexation « au fil du texte », sont autant de possibilités qui s’accommodent mal de se voir privé d’édition native XML. (Les partisans d’EAD 3 verront peut-être du maximalisme ou des fioritures dans certains de ces choix, l’encodage au fil du texte étant considérablement amoindri dans le futur schéma.) Et ne pas avoir à choisir entre masques de saisie et édition au plus près du code est une attente de collègues du réseau.
    D’accord avec les commentaires qui mettent l’accent sur la nécessité de définir un ou des modèles conceptuels pour les objets patrimoniaux (avec, un jour, des environnements de saisie à la clé) et sur le fait que l’EAD n’est pas une fin en soi. EAD semble mal prêter le flanc à un passage en RDF et trop de failles dans les possibilités d’interopérer seraient rédhibitoires pour son avenir. Ni l’ABES ni la BnF ne comptent laisser de côté ces problématiques (et qu’il y ait des arbitrages à faire sur les priorités de petites équipes, c’est certain). Si l’idée d’un dispositif de production commun a quelque pertinence, cela est en partie lié à l’existence, depuis un peu moins de deux ans, de bonnes pratiques communes – ainsi qu’au fait que la « fonction catalogage », de production de métadonnées dans les éts. documentaires, se déporte et se cantonne du côté des documents non édités, descriptibles en EAD.

    L’objectif d’une meilleure articulation entre échelles locales et globales tel qu’il est apparaît dans le projet SGBm n’a pendant longtemps jamais été transposé parmi les priorités du réseau Calames ; mais ces demandes (gérer des unités physiques) se sont plus nettement exprimées lors de la journée du réseau le 27 mai. Les cas d’usage du projet SGBm seront bientôt à écrire et certains pourront prendre en compte les données archives et manuscrits. Peu nombreux sont les établissements déployés dans Calames qui jugent nécessaire un SIA (d’où des tentations de bricolages à la marge ou d’une souplesse d’usage encore accrue, avec les attributs @audience= »internal » p.ex.) et peu nombreux ont été les établissements qui ont fait usage des exports Marc prévus dans l’outil de catalogage, à l’origine, pour permettre une ingestion dans des systèmes locaux. (Les demandes en Dublin Core sont cependant devenues plus nombreuses avec les projets de numérisation.) Signaler et rétroconvertir, numériser, valoriser, sont généralement les priorités de la majorité.

    Une incise aussi au sujet de l’origine de Calames (« …pour que ça « prenne » auprès des établissements, il aurait été peu convaincant de leur dire : voici vos fichiers XML, maintenant corrigez-les »). Le projet Calames n’est pas tant né de la volonté de corriger des fichiers EAD issus de conversions massives, que de celle de permettre de signaler des documents hors CGM et hors Palme, souvent pour la première fois. Le modèle d’import de fichiers EAD produits localement, ou ailleurs (qui est celui de l’enrichissement actuel du CGM dans le CCFr Manuscrits) n’existe en effet qu’à la marge dans le réseau Calames puisque le recours à l’outil d’encodage et liage en ligne est un de ses fondements. Et s’il existe, c’est en considérant que le recours aux fonctions de l’outil (au centre desquelles se trouve l’édition en XML) est très souhaitable avant publication (contrôle des identifiants et des bonnes pratiques, liage au référentiel IdRef…).

Trackbacks

  1. Calames IT ? | Numériques | Scoop.it
  2. Calames IT ? | Bibliothèques publiques |...
  3. Calames IT ? | Documentation juridique | Scoop...
  4. Calames IT ? | Bonnes pratiques en documentatio...

Les commentaires sont fermés.

%d blogueurs aiment cette page :