Projet module référentiel

Postulats

La première phase du projet SAEM s'est attachée à expérimenter l'utilisation du libriciel as@lae. A cette occasion les partenaires du projet ont défini certains principes de fonctionnement qui guident la stratégie de développement du futur service d'archivage électronique mutualisé. Le premier concerne le cloisonnement des accès aux applications.

Malgré la présence de fonctionnalités offertes par le libriciel pour le dépôt et la recherche d'archives par les services producteurs, nous avons déporté ces fonctions dans un outil de gestion distinct afin de réserver l'accès au module de gestion des archives électroniques aux seuls archivistes. En découle le besoin d'un sas de gestion dans lequel se déroule les différents processus d'archivage : versement, élimination, restitution ou communication. Ce sas, appelé «GED SAS», est outillé par une instance d'Alfreso community dans laquelle sont implémentés les processus cités.

A ce stade, ce module de pré-versement permet d'envisager l'agrégation d'unités documentaires provenant de systèmes de gestion différents, comme c'est le cas par exemple pour les délibérations, les marchés publics ou les flux financiers issus du passage au PES V2. En effet, ces différents flux font intervenir plusieurs applications tels que des parapheurs électroniques, des tiers de télé-transmission et des logiciels de gestion. La GED SAS peut ainsi être utilisée pour du depôt de fichiers par des connecteurs applicatifs ou pour le dépôt de paquets d'informations dans le cas de l'utilisation d'un connecteur transverse plus intelligent. Elle peut également être utilisée pour des dépôts manuels de fichiers.

processus de versement

Illustration des cas de figure et schéma du processus de versement. 

En amont de la phase de pré-versement, mais également pour les phases de conservation et de communication, le système d'archivage électronique doit être alimenté en données de référence, telles que des vocabulaires contrôlés ou des notices acteurs. En effet, les processus d'archivage sont caractérisés par des échanges entre les acteurs comportant des transfert de responsabilité portant notamment sur la conservation ou l'autorisation d'élimination des archives.

Le module référentiel

Après plusieurs mois d'expérimentation des outils assemblés lors de la phase de prototypage, nous sommes arrivés au constat que le temps passé à paramétrer les données concernant les acteurs, les flux et les vocabulaires d'indexation hypothéquait la perspective d'archiver les nombreux flux disparates d'archives contemporaines produits par les acteurs publics.

Pour tenter d'y remédier, nous avons décidé de réunir au sein d'une application orientée données un ensemble d'entités liées provenant des métiers. Cette application appelée « référentiel » est développées par la société Logilab, suivant la méthode Agile et sur Cubicweb, une plate-forme de développement oriéntée WEB sémantique.

Les vocabulaires contrôlés

Pour débuter, nous nous sommes appuyés sur le modèle de données SKOS adapté à la description des vocabulaires contrôlés.

Le module référentiel permet d'importer des vocabulaires d'indexation au format SKOS ou d'en générer des nouveaux, soit en créant une liste de descripteurs soit en les important depuis un tableur numérique (y compris en utilisant la syntaxe lcsv).

Nous importons donc, les vocabulaires mis à disposition par le Service interministériel des Archives de France comme le thésaurus-matières pour l'indexation des archives locales ou la liste d'autorité typologie documentaire. Nous avons aussi importé les listes de données intégrées dans le schéma SEDA que nous avons transformées en vocabulaires de concepts SKOS telles que les règles de sort final, les règles de restriction d'accès (délais de communicabilité) ou la liste des niveaux de description.

Les notices d'autorité des acteurs

Parallèlement, nous avons développé un modèle de données "Acteurs" en suivant la norme ISAAR (CPF) et le schéma XML-EAC.

Nous pouvons donc aujourd'hui :

  • créer des notices d'autorité des producteurs et plus largement, de tous les acteurs intervenant dans le système d'archivage électronique. 
  • importer des notices d'autorité au format XML-EAC
  • exporter et synchroniser les éléments de ces notices utiles au paramétage de l'instance d'archivage as@lae
  • enrichir ces notices acteurs avec les vocabulaires contrôlés disponibles dans le référentiel, en utilisant par exemple des descripteurs matière, géographiques ou de fonction.

A partir de la disponibilité de ces modèles d'objets, nous poursuivons nos itérations avec la spécification des données d'archivage en vue de générer des profils spécifiant les besoins de documentation sur un ensemble de données ou de documents à archiver.

Spécification de l'objet archives

Le but de ces spécifications est de définir un modèle de données permettant ensuite de remplacer l'outil de production des profils SEDA AGAPE pour générer des profils SEDA au format XML qui permettront par la suite d'alimenter la GED SAS et as@lae
Un profil SEDA définit un ensemble de caractéristiques pour un flux documentaire en vue d'en systématiser la constitution et d'en contrôler le versement. Conceptuellement, c'est le pendant numérique du bordereau de versement (exemple). On y décrit notamment le contenu des boîtes de documents, leur organisation, les éléments liés à leur cycle de vie ainsi que les liens avec le producteur en relation avec ses activités.
 
Si l'on se place du point de vue ontologique, un flux documentaire représente un paquet d'information. La structuration de ces paquets est définie dans le modèle conceptuel OAIS qui en distingue au moins 3 : 
  •  paquet d'information à verser (SIP) : constitué par les services producteurs ou versants à partir de leurs archives courantes
  •  paquet d'information à archiver (AIP) : constitué par le service archives suite à la signature d'un bordereau de versement et maintenu à jour pour garantir l'intégrité mais également l'intelligibilité des données prises en charge
  •  paquet d'information à communiquer (DIP) : constitué par le service archives suite à une demande de communication d'un tiers.

Ce schéma représente le paquet d'information à archiver (AIP). Le contenu d'information constitué d'un objet données et d'informations de représentation est lui-même documenté par des informations descriptives de pérennisation permettant de le maintenir intelligible dans le temps.

modèle de données OAIS

Dans un premier temps nous nous sommes posés la question de savoir comment peut être géré ce meta-modèle de représentation des objets d'archives.
On peut, en effet, imaginer un vocabulaire contrôlé pour les types d'objets (SIP, AIP, DIP) qui fait référence à un vocabulaire de typologie d'information (Content Information, Preservation Description Information, Representation Information, Provenance Information, etc...). Ce niveau d'abstraction est nécessaire pour gérer les différents types de paquets d'information et associer des métadonnées provenant du cycle de vie des objets versés, conservés et communiqués tout au long de leur existence.
A ce stade du projet, nous nous concentrons sur la définition des paquets d'information à verser (SIP).
 
Pour créer un profil SEDA on choisit donc de modéliser des objets de type SIP qui auraient auparavant été définis à partir des différents types d'informations disponibles. Cette structuration de l'information est importante car elle permet de gérer des niveaux de confidentialité différents suivant les typologies et de réutiliser des entités définies. On peut par exemple imaginer de définir une entité d'information de représentation (RI) qui serait utilisée pour caractériser la structuration d'un fichier XML en mentionnant le schéma qui caractérise ce format de données et d'y faire référence pour chaque contenu de données qui utilise ce format sans avoir à le redéfinir ni même éventuellement à l'attacher pour chaque objet versé.
 
La "rédaction" d'une instance d'objet de type SIP consisterait ensuite à rattacher des entités à l'objet (de type agent, document, attachement et vocabulaire principalement) et à préciser la cardinalité attendue pour chacun.
Cette modélisation répond à la feuille de route définie par les Archives de France sur leur site : http://www.archivesdefrance.culture.gouv.fr/seda/evolutions.html pour constituer un schéma SEDA qui définit l'ensemble des référentiels à utiliser pour les échanges d'archives dans le secteur public afin de : 
  • repenser les choix de référentiels en fonction de l'état du marché des normes, des standards et des outils disponibles.
  • définir les principes et mécanismes du SEDA qui permettront d'assurer une compatibilité ascendante.
  • s'assurer de l'exploitabilité de la solution proposée afin que l'automatisation des traitements puisse se faire sans part interprétative.

Modèle de données objet d'archives

L'ensemble des descripteurs actuellement disponible dans la version 1.0 du SEDA est accessible ici ttp://www.archivesdefrance.culture.gouv.fr/seda/api/index.html
 
On peut constater dans cette documentation que ce schéma fait référence à de nombreux vocabulaires contrôlés. Il définit également dans un schéma dédié (seda_v1-0_organization.xsd) les éléments permettant de décrire les acteurs au sens SEDA qui interviendront ensuite dans les processus d'archivage.
 
Si on étudie le schéma SEDA on constate qu'il est constitué de la manière suivante :
- une partie d'en-tête qui décrit le contenu du bordereau
- une description des acteurs impliqués dans le processus
- différentes entités qui correspondent aux éléments de description de la norme ISAD-G, à savoir, une archive constituée de une ou plusieurs unités documentaires, elle(s)-même(s) composée(s) de un à plusieurs objet(s) document(s), alimenté(s) par un ou plusieurs fichier(s) de données.
Un objet SEDA est ainsi  constitué par différentes entités embriquées dont les caractéristiques sont décrites ci-dessous. 

Archive

Cette entité est définie comme un objet correspondant à  un ensemble constitué d'objets-données, de leurs informations de représentation, de leurs informations de pérennisation et de leurs informations de gestion. Il s'agit du plus haut niveau de description de ce qui est échangé. La caractérisation de la composition de cette archive est définie dans le profil d'archivage associé et la définition du contrat de conservation est stipulée dans la convention d'archivage. La langue principale de l'archive, son nom, la description de son contenu, les règles d'accès et le niveau de service attendu peuvent être précisés à ce stade ainsi que des identifiants permettant de faire des liens avec les acteurs impliqués dans le versement ou la prise en charge.
Le schéma SEDA le caractérise avec les éléments ci-dessous.
 
modèle seda archives
 
Dans le premier jalon du projet, cette entité est composée des éléments prioritaires de description
 
 

Archive Object  

Cette entité est définie comme un objet réunissant plusieurs éléments et correspondant à  une subdivision de l'Archive. Pour se rapprocher d'un vocabulaire plus compréhensible on utilise le terme d'unité documentaire, matérialisée dans la vie de nombreuses archives par une boîte de conservation. A l'intérieur de cette boîte on peut trouverplusieurs liasses et chacune de ces liasses peut contenir une unité documentaire ou un document,. Cette unité intellectuelle de base, correspond à un fichier dans le cas de l'archivage électronique. Toutefois ce fichier peut lui-même être caractérisé par un objet binaire composé de bits d'information.

A ce niveau de description du flux on décrit généralement le contenu de la boîte dans une entité particulière, la description du contenu.

 

Dans ce premier jalon du projet, cette entité est composée des éléments principaux de description.

Description du contenu

Cette entité est définie comme un objet permettant la description du contenu de l'unité documentaire. On y retouve notamment la description littérale, les date extrêmes, le plan de classement, le niveau de description et les liens avec d'autres versements d'objets liés.

Document 

Cette entité est définie comme un objet correspondant à  une subdivision de l'unité documentaire ne pouvant pas lui-même être subdivisé et comportant obligatoirement un objet-données (fichier), accompagné de ses informations de représentation et de ses informations de pérennisation. C'est à ce stade que la particularité de l'archivage électronique se précise dans le sens où il est essentiel de conserver un certain nombre de métadonnées techniques sur les fichiers qui sont rattachés à cet objet. On retrouve donc ici des éléments comme la somme de contrôle, la taille, le type ou le statut qui permettent de caractériser techniquement les documents et d'y associer le cas échéant des visionneuses appropriées ou des modalités de conservation préventives spécifiques.
 
 
 

Attachment

Cette entité est définie comme l'objet-données (contenu binaire ou fichier joint) à archiver. On décrit ici l'objet donnée du point de vue de la sémantique de l'information encapsulée dans le fichier binaire versé dans l'archive comme par exemple l'encodage des caractères, le format de fichier, le type MIME, le nom du fichier ou le jeu de caractères utilisé. Cela, permet de garantir que l'on sera capable d'associer la bonne application pour accéder aux données contenues dans le fichier de façon intelligible et sans risquer dans corrompre le contenu.

Cycle de vie

Ces éléments définis, le profil SEDA est enregistré comme un modèle de SIP et synchronisé avec le dictionnaire de données dans la GED SAS pour permettre la génération du formulaire de versement.
Enrichi d'autres éléments de structuration et de description, il peut être utilisé pour générer un AIP qui servira de station d'accueil dans l'entrepôt de métadonnées et, dans as@lae, pour servir au contrôle de conformité du versement par rapport aux éléments définis dans le profil.
Le travail de modélisation effectué à cette ocassion est indépendant de la version du SEDA puisqu'il est basé sur le besoin du métier des archivistes. Il peut, donc, être exporté conformément à une version du standard donné en fonction du besoin par le biais d'une simple règle de transformation. Il est ré-utilisable pour les 3 types d'objets couramment gérés dans le cycle de vie des archives à savoir le paquet d'information à verser, celui à conserver et celui à communiquer. On peut également se servir de ces entités pour définir au sein d'un système de gestion des contenus actifs (par exemple une GED) un référentiel documentaire. A tritre d'exemple : un document de type acte d'engagement d'un marché public peut être défini comme une entité disposant d'un type, d'un nom, d'un format de fichier, d'une ou plusieurs règles de sort final et de liens avec d'autres documents. Lors de la création d'une instance de cette entité dans le système de gestion courant, un ensemble de métadonnées peut accompagner sa création et être acheminé lors de son pré-versement dans un sas facilitant ainsi le travail de description lors du processus d'archivage.
 
Après 5 itérations de 15 jours de développement, nous avons donc à disposition les modèles de données schématisés ci-dessous. 
 
 
 
Dans les prochaines semaines nous allons ajouter des éléments de description et des types d'entités pour permettre d'enrichir les futurs bordereaux de versement qui alimenteront le système d'archivage électronique.
 
Nous mettrons prochainement à disposition de tous une application de démonstration. En fin de projet les sources de l'application sous licence de libre, seront disponibles. N'hésitez pas à nous contacter si vous êtes intéressés par l'utilisation de ce module.