Aller à : navigation, rechercher

OAIS

Nous présentons ici le logiciel Maarch dans le cadre d'un projet suivant la structuration d'OAIS. Ceci permet d'avoir un vocabulaire et des concepts communs, et facilite ainsi la compréhension du logiciel.

OAIS global.png


OAIS (Open Archival Information System) est un modèle conceptuel destiné à la gestion, à l'archivage et à la préservation à long terme de documents numériques.

Il introduit les notions de producteurs, utilisateurs, et paquets d’archivage intègres.

Il comprend 4 grandes fonctions (versement, stockage, gestion des données, accès), ainsi qu'une fonction d'administration.

Il introduit la notion de Producteur, qui soumet à l'archive des « paquets de soumission d'information » (SIP). Le SAE les conserve sous la forme de « paquets d'information d'archive » (AIP), et les restitue au consommateur-utilisateur sous la forme de « paquets de diffusion d'information » (DIP).

Chaque fonction OAIS est structurée en processus. C'est cette structuration que nous suivons dans ce document pour la description d'un système Maarch.

Sommaire

Fonction 1 - Versement des archives

OAIS F1.png

Le versement des archives est un point clé d'un logiciel d'archivage électronique. Selon la norme OAIS, il consiste à transmettre un paquet SIP (Submission Information Package) au SAE, qui conserve les documents sous forme d'AIP (Archival Information Package), et retourne en échange un Compte-Rendu de Versement (CRV).

F1.P1: Recevoir versement

Ce processus consiste à effectivement réceptionner dans un espace de stockage tampon, les SIP en provenance du Service Versant. La transmission entre les deux services peut être effectuée en ligne ou via un support amovible dans le cas par exemple de fichiers volumineux envoyés à faible fréquence.

La réception du SIP dans un espace tampon peut se faire par différents moyens :

  • par dépôt direct dans un répertoire
  • par dépôt synchrone via l'interface pour enregistrer des données d'activité
  • par télétransmission entre SAE via un bordereau SEDA. La télétransmission peut être simple (SIP de poids faible et moyen) ou assurée par un moniteur de transfert de fichier (SIP de gros volume).

Le dépôt direct dans un répertoire des SIP est une opération simple, à effectuer en sortie d'un logiciel métier par exemple.

Enregistrement unitaire transactionnel

Dans ce cas on ne parle pas de versement mais plutôt d'enregistrement. Ce processus consiste à numériser/enregistrer les documents à la volée en mode transactionnel, ce qui est applicable pour la gestion des documents d'activité (GDA - traduction officielle du Record Management).

L’application Maarch ouvre une page d’indexation. L’écran est séparé en deux parties : à droite le document venant d'être chargé ou numérisé, directement au format PDF, et à gauche un formulaire d'indexation pour caractériser ce dernier.

Les informations à saisir pour l'indexation sont conditionnées par deux mécanismes :

  • les catégories d'indexation, qui sont de grandes familles de masques finement paramétrées. Les masques standards répondant à la plupart de cas sont déjà présents :
    • Documents/courriers entrants, avec circulation (Maarch gère aussi les archives intermédiaires)
    • Documents d'archive
    • etc.
  • les index dynamiques affectés à un type de document. Ces index sont choisis par l'administrateur fonctionnel pour apparaître en fonction du type de document concerné.

L'écran ci-dessous illustre l'aspect que prend le versement interactif :

GDA.png

Écran de versement en mode interactif

Dans le cas d'une archive papier, l'archiviste doit saisir le nombre de mètres linéaires.

Versement par bordereau SEDA

Le bordereau SEDA permet de normaliser la transmission d'archives par le service producteur vers le SAE. L'opération de versement se fait avec un bordereau de versement SEDA, qui peut être soit fourni directement par le service producteur, soit généré à l'aide d'un assistant en ligne. Le bordereau SEDA décrit l'ensemble des métadonnées de l'archive. Il est rattaché (ou pas en cas d'archive papier) à une information de contenu (CI : Content Information), elle-même constituée :

  • d'un manifeste PDF contenant les empreintes de l'ensemble des document constituant l'archive
  • des fichiers à archiver

L'ensemble constitue un SIP (Submission Information Package) au sens de la norme OAIS ISO14721.

Figure 3 - Structure d'un SIP

La procédure de versement par bordereau SEDA s'exécute en trois étapes :

  • Étape 1 : Création du bordereau (le cas échéant)
  • Étape 2 : Rattachement des objets numériques au bordereau pour constitution d'un SIP
  • Étape 3 : Transmission et ingestion du SIP

Cette procédure permet la remontée et le versement de très gros volumes d'objets numériques, sans virtuellement aucune limite de taille, a condition de bien gérer le transport.

Le protocole SEDA ne traitant pas la problématique du transport, il convient de monter une infrastructure adaptée, surtout si les volumes sont importants. On pourra pour cela faire appel à un moniteur de transfert de fichier tel que CFT de la société AXWAY, ou mieux car plus performant et Open Source le produit Waarp.

Étape 1 : Assistant de création du bordereau SEDA

L'utilisateur autorisé dispose d'un assistant de création des bordereaux SEDA. L'objectif est de disposer d'un outil simple où l'utilisateur est guidé pour la création du bordereau. Cette procédure est utilisée de préférence par les services connexes (CCAS, Police municipale) pour les versements formels dans le SAE de la collectivité. Un versement direct en archive peut aussi se faire sans bordereau, tel que montré plus haut. L'assistant de création de bordereau SEDA présente l'aspect suivant :

OAIS br.png

On pourra connecter pour les archives contemporaines un Thésaurus W, outil réglementaire de description et d'indexation des archives administratives contemporaines (circulaire AD 89-3 du 31 août 1989 diffusant le Thésaurus W, à valeur réglementaire à partir du 1er janvier 1990, et mises à jour de 1997 et 2000).

Étape 2 : Empaquetage des archives

Les services versant ont à leur disposition un outil Java pour empaqueter les archives à transférer. L'outil prend en entrée le bordereau SEDA généré, en rappelle son contenu, puis l'utilisateur y rattache les objets numériques. L'outil Java est une applet exécutée à l'intérieur du navigateur : l'utilisateur reste dans son environnement, le déploiement en est facilité. L'applet est appelée directement en sortie de la création du bordereau manuel. Le système est extrêmement souple et permet de verser tout type de document répondant à la Politique d'Archivage. La convention d'archivage est inscrite dans le système par service versant : Voir Conventions d'archivage. Elle est importée dans l'outil afin d'effectuer un pré-contrôle sur les documents électroniques joints.


OAIS java.png

L'outil va chercher les aspects qui le concernent de la convention d'archivage directement dans le référentiel documentaire. La convention, au moins pour ce qui concerne le versement, est donc administrée au niveau central. Cela autorise la constitution de SIP de très grande taille (de l'ordre du Téraoctet), ce qui peut être utile pour archiver les vidéos ou enregistrements sonores.

Étape 3 : Transport des paquets monitoré

La souplesse de constitution des SIP peut générer des paquets d'archivage de grande taille (plusieurs Gigas pour une vidéo par exemple).

Afin de ne pas être confronté à des problèmes de time-out, de monopolisation de la bande passante, ainsi qu'à des risques de perte d'intégrité, le SIP devrait être transmis par un mécanisme asynchrone, entièrement sécurisé et crypté, fonctionnant en mode Boîte à lettre.

Nous conseillons fortement l'utilisation de Waarp, outil de transfert transactionnel s'accompagnant de tâche de pré-transfert et post-transfert. Waarp permet d'assurer l'envoi d'un fichier d'un serveur vers un autre tout en assurant l'intégrité du fichier envoyé. Par ailleurs Waarp s'accompagne d'une reprise sur erreur permettant de relancer un traitement là où il s'est arrêté, ainsi que d'écrans de contrôle de tous les flux entrants et sortants pour les serveurs actifs.

Waarp sera mis en place entre les services producteurs et le sas d'entrée du SAE pour les remontées asynchrones. Waarp prend en charge la couche Transport du protocole SEDA, le vocabulaire(protocole) de communication entre producteur et SAE restant égal par ailleurs.

Waarp prendra aussi en charge le transport des compte-rendus de versement redescendant vers les services versants.

F1.P2: Vérifier transmission

Dans le cas d'un enregistrement synchrone GDA ou par Web Service (WS), ce processus n'a pas lieu d'être : le document apparaît à l'affichage, et ne serait pas affiché en cas d'altération technique.

En revanche, pour le versement SEDA grâce aux SIP constitués en amont, le contrôle d'intégrité est effectué à deux niveaux :

  • unitairement par Waarp qui garantit l'acheminement et l'intégrité des informations transmises
  • par des post-traitement Waarp, intégrés à la transaction de transfert, qui vont vérifier les CRC calculés par le logiciel d'empaquetage.

Dans ce processus de vérification de transmission, on assure aussi l'innocuité de l'archive à l'aide de l'antivirus CLAMAV.

En cas d'échec, c'est toute la transaction Waarp qui est en échec, et la transmission est relancée.

F1.P3: Contrôler conformité

Afin d'avoir un suivi du cycle de versement, les paquets SIP sont injectés par Maarch AutoImport en zone de sas de versement. Il n'est pas autorisé de visualiser le contenu de l'archive tant que les tests de conformité n'ont pas été passés. Le contrôle de conformité fait partie de la convention d'archivage, qui elle-même est une composante de la Politique d'Archivage/Règle de Gestion. La convention d'archivage a pour objet de stipuler les règles de soumission et de contrôle des paquets versés. Les variables d'ajustement de la convention portent sur :

  • l'identité du service versant
  • les formats, au sens PRONOM
  • la taille maximale autorisée
  • le nombre maximal d'articles autorisés
  • La définition du message de versement (SEDA ou autre)

F1.P4: Journaliser

Compte-rendu de versement

Lorsque l'archive est correctement intégrée dans Maarch en zone tampon de versement, puis en zones redondées avec sécurisation de l'archive, Maarch établi un compte-rendu de versement qui est adressé au Producteur via Waarp, ou via SEDA. Ceci est effectif uniquement lors d'un transfert par bordereau.

Mécanismes de la journalisation et traçabilité interne

Waarp dispose d'un système complet de journalisation, comme l'ensemble des outils de l'écosystème Maarch.En dehors du CRV, il existe un système de journalisation et de trace complet dans Maarch. Maarch distingue deux types de journalisation :

  • La journalisation technique : il s'agit de la collecte des journaux ou logs générés par les applications, les équipements réseaux ou systèmes d'exploitation,
  • La journalisation fonctionnelle : ce domaine recense les actions des utilisateurs sur les applications et les archives. Il permet d'assurer une traçabilité des actions sur les SI du SICTIAM afin de mesurer la sécurité de ceux-ci, d'utiliser la gestion des traces comme outil de pilotage de l'exploitation des SI et d'apporter des éléments de preuve en cas de besoin. La journalisation est indépendante de la supervision : la supervision détecte le fonctionnement d’un processus, mais pas les alertes fonctionnelles ou informations enregistrées dans les journaux.
Génération des traces fonctionnelles

Maarch produit deux sortes de traces stockées dans des tables distinctes de la base de données Maarch:

  • Les journaux de production fournis par les batchs (ex: AutoImport et Politique d'Archivage/Règle de Gestion)
  • Les traces d'utilisation de l'interface logicielle

Les traces actuelles apportent les informations suivantes :

  • Nom de l’objet (table)
  • Identifiant de l’objet
  • Type d’événement
  • Id utilisateur
  • Date-heure
  • Info complémentaire événement
  • Module Maarch ayant déclenché l’événement
  • Adresse IP
  • Flag log système/fonctionnel
Génération des traces techniques

Les traces techniques concernent les logs techniques des composants applicatifs de la solution à savoir:

  • Les logs système linux
  • Les logs des serveurs web Apache HTTP (y compris les logs de connexions)
  • Les logs des bases de données (PostgreSQL, Oracle, etc)
  • Les logs d'envoi de messages courriel (Postfix, Exim, ...)
  • Les logs Waarp
  • Les logs d'erreur des modules Maarch
Alertes et notifications

Maarch possède un système d'alerte et de notification par courriel s'appuyant sur n'importe quel événement du système : chaque événement peut être notifié à un ou plusieurs groupes d'individus.

Archivage des journaux

Pour être conforme aux exigences du SIAF, on archivera les journaux avec le même niveau de sécurité et d'intégrité que les archives. Pour ce faire, les journaux doivent être considérés comme une collection d'archivage à part entière. En fin de journée, un batch récupère :

  • les journaux de tous les batchs Maarch passés
  • les journaux des événements Maarch (table HISTORY), dont on aura paramétré une copie texte avec log4php.
  • Les journaux système UNIX fournis par le SICTIAM

On conservera les journaux ad vitam, en ayant soin qu'ils ne comportent pas de données à caractère personnel.

Registre des entrées

Le registre des entrées est un chrono des entrées mentionnant le mode d'entrée (dons, dépôts, achat, legs) et reprenant les informations ci-dessous du bordereau de versement. Il est établi de date à date.

Regent.png

F1.P5: Consulter

La consultation avant archivage définitif est possible dès lors que l'archive se trouve dans le sas d'entrée du SAE, en contrôle de transfert positif. C'est une première zone de stockage définie dans le cycle de vie, qui a pour caractéristique d'être la plus rapide possible afin d'absorber rapidement les versements. La fonction de consultation OAIS sert à valider les versements alors qu'ils sont dans le SAS.

Corbeille de bordereaux

Différentes corbeilles (ou bannettes) affichent les bordereaux selon leur état dans le workflow. Par exemple, la corbeille suivante affiche tous les bordereaux qui n'ont pas passé avec succès le contrôle de conformité.


En cliquant sur l'icône « Information », on peut obtenir le détail du bordereau, et agir sur les articles le composant : Figure 7 - Détail des articles d'un bordereau L'archiviste a la possibilité de rejeter un article, toujours avec mention du motif de rejet : le motif est choisi dans une liste fermée de motifs de refus, et complété par un commentaire libre facultatif. Pour valider définitivement le transfert, l'archiviste doit confirmer la cote, ou bien recoter l'ensemble des articles du bordereau. L'ancienne cote est conservée à des fins de recherche ou d'historique. Elle permet aussi de faire le lien avec le service versant.

Transmission des accusés de réception

Les articles suivent ensuite un processus de sécurisation via le module de cycle de vie, dans lequel ils sont empaquetés dans les AIP, puis écrits en « Y » dans deux zones de stockage distinctes.

Un traitement par lot identifie les bordereaux sécurisés, puis émet un accusé de réception de transfert positif au format SEDA, déposé dans un répertoire pour traitement.

Un second traitement par lot constitue des accusés de réception négatifs en cas de bordereaux rejetés. Ces accusés sont au format SEDA, toutefois enrichis de l'identification des articles posant problème, et mentionnant le motif de refus.

En retour, le SAE Maarch « Émetteur » saura décoder les AR négatifs avec la mention des articles à problème, sans que cela perturbe le message SEDA pour un autre type de SAE.

F1.P6: Convertir

La conversion de format est un aspect théorique d'OAIS difficile à mettre en œuvre sans cas pratique. Elle a pour objectif la pérennisation de l'archive par migration des formats obsolètes ou en passe de le devenir, avant que les outils de lecture ne soient plus disponibles.

La convention d'archivage ne devrait autoriser que des formats normés disposant d'une très longue durée de vie.

Si malgré tout on devait effectuer une conversion à l'entrée du SAE, la conversion automatique devrait être validée par le service versant, car il y a des risques d'infidélité par rapport à l'original.

F1.P7: Générer AIP

Ce processus revient à constituer un Archival Information Package (AIP) conforme aux normes de documentation et de formatage des données de l'OAIS. Dans Maarch, l'AIP est généré a posteriori au travers du cycle de vie car sa constitution exige du temps CPU et quelques pré-requis :

  • le passage d'archives courantes à intermédiaire, et donc la fin de vie « active » du document, ce qui permet de disposer de journaux de production complets (par exemple les étapes et intervenants dans un worflow de validation).
  • la présence de suffisamment de ressources pour générer des paquets AIP incluant de multiples Archival Information Units (AIU), et ainsi optimiser la compression.

Maarch a adopté la norme OAIS pour le stockage des archives sous forme de paquets.

L’« Archiving Information Package » (AIP) est une figure essentielle de la couche stockage OAIS : En contenant la ressource (« Archiving Information Unit »), ses métadonnées, et l’historique de production, il est autoporté, et doit résister à la perte du logiciel d’archivage et de son référentiel en base de données.

Le format d'un paquet AIP est le suivant :

OAIS aip.png

Un AIP est composé d’une information d’empaquetage, de contenu (CI), et de préservation (PDI). Un AIP peut inclure plusieurs Archival Information Units (AIUs), chacune d’elle disposant d’un contenu et d’une PDI :

  • Packaging Information: information de référence pour la lecture et l’interprétation du paquet. C’est ici que se situe la signature électronique serveur d’archivage.
  • Content Information (CI) : conteneur des ressources (fichiers PDF ou autres)
  • Preservation Description Information (PDI) : information nécessaire pour une préservation appropriée, qui est catégorisée en Provenance, Référence, Intégrité, Contexte et droits d’accès.

La communication d’une ressource suit les étapes suivantes :

  • Détermination de la zone de stockage et du chemin vers l’AIP
  • Décompression ciblé de la ressource recherchée en fonction des règles décrites pour le type de zone
  • Recalcul et comparaison des empreintes en fonction des règles décrites pour le type de zone

>> Télécharger un AIP Maarch

F1.P8: Coordonner les mises à jour

Ce processus consiste d’une part à transmettre à la fonction stockage le contenu d’information à conserver et d’autre part à transmettre à la fonction gestion des données descriptives les données correspondantes.

L’ensemble de ces informations se retrouve dans l'AIP. Le processus attend ensuite en retour l’accusé de réception du résultat de l’opération. Dans le cas du stockage, l’accusé de réception doit contenir l’information d’identification de l’espace de stockage. Cette dernière donnée est ensuite envoyée en complément des informations précédentes à la fonction gestion des données descriptives.

La fonction de stockage est une classe PHP faisant partie du cœur du produit Maarch. C'est elle qui gère concrètement les écritures et lectures sur les serveurs de documents. Elle choisit les espaces de stockage à utiliser en fonction de leur priorité et de la collection documentaire (ceci étant administré via l'interface).

Maarch établit un parallèle entre les informations de la règle de gestion/politique d’archivage en matière de sécurité (disponibilité, intégrité, confidentialité, preuve) et les niveaux de services décrits dans la convention d’archivage. Par exemple, en fonction des critères, la machine attribue un niveau de sécurité à la politique d'archivage/règle de gestion, en fonction des critères suivants :

  • présence d'empreinte – niveau de sécurité des empreintes
  • présence de signature / horodatage
  • activation de la réplication
  • activation de l'empaquetage

Le niveau de service résultant est comparé au niveau de service exigé par l'élément du tableau de gestion, avec affichage d'un message d'alerte en cas de non souscription aux exigences.

Fonction 2 - Stockage

OAIS F2.png

Maarch est un système de référencement et d'indexation de ressources/articles électroniques, quelque soit leur format. Ces ressources/articles sont entreposées séparément de la base de référencement, dans des zones de stockage gérées par le logiciel au niveau logique, et par le matériel au niveau physique. N'importe quel système de stockage peut être utilisé, à partir du moment où celui-ci présente un "système de fichier" à accès direct. Ce peut être le cas d'un attachement direct ou indirect de type NFS sur une baie SAN, NAS, ou pour les cas simples un ensemble de disques RAID.

Structurellement, Maarch a aussi été prévu pour supporter les systèmes de stockage à jeton (adressage logique de type CAS). Maarch peut tout à fait utiliser des API natives Centera, ou des API standard XAM/SNIA pour communiquer avec ce type de baie.

Les notions de "Worm logique" ou de paquets d'archivage exigés par les normes sont ici entièrement gérées au niveau logique par le SAE.

F2.P1: Recevoir

L'outil Maarch AutoImport réceptionne les archives à ingérer, effectue des vérifications, copie les archives dans la zone de stockage dédiée au versement (zone tampon) et insère les métadonnées fonctionnelles et techniques en base de données.

La zone tampon de versement se justifie par le besoin d'aller très vite pour la prise en compte de l'intégration dans le SAE. Ensuite, Maarch applique une Politique d'Archivage/Règle de Gestion pour l'écriture en « Y » sur deux zones de stockage conformes OAIS, avec constitution de paquets AIP. Le composant Maarch de stockage est chargée de l'écriture de l'archive sur le support physique. C'est le même composant qui est utilisé partout, que ce soit dans les programmes transactionnels ou batch.

Ce composant est aussi chargé de la lecture des paquets dans les espaces de stockage.

F2.P2: Mode de stockage

Ce processus consiste à conserver effectivement les paquets d’informations archivés et à choisir le support adéquat en fonction d’un certain nombre de critères dont les principaux sont l’accessibilité et la durée.

Les ressources/articles sont placés dans des zones de stockage. Une zone de stockage est un espace physique ou logique contenant les ressources/articles numériques.

Dans Maarch, la zone de stockage effective est choisie selon le fonds d'archive et la politique d'archivage/règle de gestion à appliquer.

Une partie de la définition de la zone de stockage est intégrée dans son type. Ceci permet d'instancier plusieurs zones de stockage de la même famille. Un type de zone de stockage renseigne sur la conformation du stockage dans la zone : empaquetage AIP ou pas, nombre de ressources/articles dans un paquet, méthode de calcul d'empreinte, etc. La zone de stockage quant à elle possède des propriétés telles que l'emplacement précis de stockage, ou l'espace total et disponible.

Maarch gère plusieurs zones de stockage pour la même ressource.

F2.P3: Détruire

Il est possible de « supprimer » à tout moment une archive, à condition d'en avoir les droits, mais il ne s'agit que d'une destruction logique, avec conservation des journaux.

La destruction physique quant à elle est un processus associé à la Politique d'Archivage/Règle de Gestion. Elle consiste à supprimer physiquement toute trace de l'archive, à la fois sur les multiples zones de stockage et dans les journaux.

Sur les baies magnétiques à accès direct, le SIAF recommande le broyage des données (shredding), c'est à dire de l'effacement bit à bit du document. Le shredding prend plus de temps qu'une simple suppression de fichier, aussi c'est une action spécifique dans une étape de cycle.

F2.P4: Garantir l'intégrité

La garantie d'intégrité dans la fonction de stockage d'un SAE est primordiale. Dans Maarch elle se manifeste de la sorte :

  • Calcul systématique par la couche de stockage d'une empreinte numérique unique du document réceptionné. L'algorithme utilisé est sélectionnable parmi une liste (MD5, SHA256, SHA512, SHA1, CRC32, ADLER32). Cette liste est paramétrable et pourra être complétée au fil des évolutions technologiques.
  • Contrôle de l'empreinte systématique à chaque lecture (pour traitement ou affichage).

En cas de différence, indiquant un problème grave de perte d'intégrité, l'erreur est tracée dans le journal des événements Maarch, et le système tente de basculer en cascade sur les espaces de stockage secondaires et de secours, afin de rendre le service utilisateur de façon transparente. L'erreur doit être remontée via de la supervision NAGIOS par exemple.

Le remplacement de l'AIP corrompu est une procédure d'exploitation, qui ne doit être passée qu'après un diagnostic précis de la cause du problème. Dans un archivage sécurisé, la ressource/article est présente sur d'autres zones dans d'autres AIP. La procédure consiste à reconstituer l'archive corrompue à partir des archives saines.

Contrôle périodique d’intégrité

L'écosystème Maarch dispose aussi d'un outil de vérification périodique d'intégrité (record_patrol) , qui effectue des rondes de vérification des archives sur leurs différents espaces de stockage, avec relecture et contrôle de l'empreinte.

Le module record_patrol fournit un historique complet des contrôles effectués et des alertes pour le système de supervision.

Ce système permet de détecter une perte d'archive avant que cette perte soit remontée par un accès utilisateur (si l'utilisateur lui-même s'aperçoit de la perte, il est peut-être déjà trop tard, car cela voudra dire que toutes les occurrences répliquées de l'archive présentent une anomalie). Le mécanisme est suffisamment rapide pour balayer plusieurs fois par mois la totalité de l'archive, en travaillant durant une période de temps donnée.

On ajoute aussi le contrôle de malware, ce qui peut déclencher la détection de virus qui n'étaient pas encore identifiés au moment du versement.

F2.P5: Gérer les migrations

Le processus de migration de support est géré par la Politique d'Archivage/Règle de Gestion. Ce dernier permet d'associer à un cycle plusieurs étapes de traitement exécutant une action.

La migration des archives dans les différentes zones de conservation de longue durée correspond au passage d’une zone à l’autre et est assurée exclusivement par le workflow, soit de manière automatique quand les conditions de transition sont réalisées, soit de manière manuelle par l'intervention d'un administrateur ou d'un gestionnaire d'archives.

La mécanique interne du workflow procède en deux étapes :

  • Remplissage d’une pile de traitement (table SQL Maarch) avec les actions à effectuer sur les documents sélectionnés. La pile ne peut être remplie qu’avec un cycle à la fois, et il y a une limite en nombre de documents sélectionnés pour la passe
  • Traitement de la pile, et vidage par lot en mode transactionnel

En ce sens, la migration est un traitement batch sécurisé, et peut être suivi pour les traitements très longs par consultation de la table de pile.

Il faut noter que ce processus natif Maarch, qui a l'avantage d'être tracé et géré par le système, n'est pas le plus simple : on peut aussi déplacer toutes les archives d'une baie à l'autre, et modifier le basepath des serveurs de documents.

F2.P6: Préparer DIP

Ce processus est intégré à la consultation/communication des archives. Ainsi dans l’ordre :

  • La fonction communication demande à la fonction stockage des articles
  • La fonction stockage s’exécute et renvoie des DIP
  • La fonction communication traite les DIP reçus et les affiches à l’utilisateur ou les met sur un support externe ou les transmet via Waarp.

F2.P7: Fournir les statistiques

Le menu « Etats et Editions » permet de visualiser les différentes statistiques calculées par Maarch. L’accès aux statistiques est un droit particulier ; par défaut, les simples agents n’y ont pas accès, et les droits sont ensuite positionnés par l'administrateur fonctionnel au niveau de chaque édition.

Les statistiques sont produitent directement sur des formats bureautiques comme Excel.

Les statistiques fournies dans le cadre du projet sont :

  • Métrage linéaire (archives physiques) et volume électronique par fonds et par année de versement, avec calcul de l'accroissement relatif et absolu
  • Idem pour les entrées (versements) et les sorties (éliminations)
  • Registre détaillé des entrées sur une période
  • Inventaire détaillé de cote à cote, par fonds

Fonction 3 - Gestion des données

OAIS F3.png

OAIS cite 4 fonctions conceptuelles de gestion des données :

  • Assurer lien

Les métadonnées sont intrinsèquement liées aux documents au sein des AIP

  • Mettre à jour
  • Garantir l'intégrité

L'AIP garantit l'intégrité des métadonnées, via une empreinte calculée sur le PDI.

  • Administrer

Métadonnées primaires

Maarch intègre nativement les 15 index Dublin Core, depuis sa toute première version en 2005. Ces index sont annotés (DC) dans le schéma ci-dessous. Dès la conception, Maarch comportait aussi les index nécessaires à la traçabilité de l'acquisition dans la norme AFNOR NFZ42-013, ici annotés (Z42).

Le référentiel documentaire comprend également des informations de service nécessaires au bon fonctionnement du SAE.

L'ensemble de ces qualificateurs peut être regroupé selon le schéma OAIS en informations de contexte, provenance, identification et intégrité. Ces mêmes index se retrouvent selon ce classement dans le PDI des AIP.

OAIS data.png

Descripteurs fonctionnels

Des jeux de descripteurs fonctionnels complémentaires permettent de construire des fonds d'archives avec un schéma d'indexation spécifique.

Contenu

Maarch dispose de fonctions d'indexation et de recherche en plein texte, basées sur l'implémentation Zend PHP du moteur plein texte Lucène.

La recherche sur le contenu est activée à la demande. On pourra par exemple l'activer pour une collection particulière, dans un cycle donné. Les champs de description de la base de données seront eux indexés en plein texte.

Fonction 4 - Communication/Consultation des archives

OAIS F4.png

F4.P1: Vérifier les accès

Maarch gère trois concepts de sécurité :

  • le périmètre documentaire gère les droits d'accès aux documents
  • le profil d'utilisation gère les droits d’usage des fonctions de Maarch
  • l'organisation gère les héritages des droits selon le positionnement de l'utilisateur

Le périmètre documentaire

Le schéma de sécurité Maarch s'appuie sur les listes de contrôles d'accès au niveau des profils d'utilisation. Il ne l'implémente pas au niveau de chaque document mais au niveau des collections qui regroupent des archives intermédiaires et définitives selon un critère spécifique.

Lorsqu'un utilisateur se connecte, la liste des groupes auxquels il appartient est constituée. Chaque groupe dispose d'accès à une ou plusieurs collections, et se voit filtrer l'accès à la collection par une clause de restriction.

La clause se rapproche du SQL, et autorise des restrictions sur des valeurs fixes de champs d’index (Ex : flag_confidentiel=’N’), ou sur des valeurs instanciées à la connexion (Ex : user_dest = @user_id). En phase d’administration, on peut utiliser ces mots clés pour exploiter l’organisation dans la gestion des autorisations :

  • @user : id de l’utilisateur connecté
  • @my_entities : toutes les entités rattachées à l’utilisateur connecté. N’inclue pas les sous-entités
  • @my_primary_entity : entité primaire de l’utilisateur connecté
  • @subentities[(entity_1,...,entity_n)] : sous-entités de la liste d’argument, qui peut aussi être @my_entities ou @my_primary_entity
  • @parent_entity[entity_id] : entité parente de l’entité en argument
  • @sisters_entities[entity_id] : toutes les entités du même niveau que l’entité en argument
  • @all_entities : toutes les entités (actives)
  • @immediate_children[entity_1,..., entity_id] : sous-entités immédiates (n-1) des entités données en argument

Une politique de sécurité est donc facilement gérable via les écrans d'administration Maarch :

  • Administration/Utilisateurs : ajout/modification d'utilisateurs, affectation à un groupe, et définition du groupe primaire
  • Administration/Groupes : ajout/modification de groupes, accès et filtrage sur les collections disponibles

La date de communicabilité est vérifiée avant toute communication d'archive.

Le profil d'utilisation

Le profil d'utilisation est l'inventaire des capacités de l'utilisateur à manipuler les fonctions proposées par la couche de présentation Maarch.

Comme vu plus haut, Maarch dispose de modules proposant des fonctionnalités exposées en tant que services. Les services de nature "utilisateur" (et non "système") peuvent être affectés à un groupe, afin que les utilisateurs de ce groupe puissent en tirer parti.

Dans Administration/Groupes, partie gauche, un profil administrateur peut affecter les différents services :

Dans Maarch, les fonctionnalités sont regroupées dans des modules indépendants. Chaque module propose une liste de fonctions système et utilisateur. On peut gérer très finement les privilèges pour chacun des groupes, afin de disposer par exemple de plusieurs niveaux d'administration fonctionnelle. Les autorisations sont cumulatives : elles s'ajoutent les unes aux autres en fonction des groupes d'appartenance de l'utilisateur.

Le positionnement dans l'organisation

La position dans l'organisation hiérarchique appliquée dans l'entité (ex: l'appartenance à une direction, un service ou un bureau particulier) va permettre de gérer strictement :

  • les accès au périmètre documentaire, si la sécurité des documents dépend de leur relation à un service rédacteur ou traitant
  • le contenu des corbeilles, si celles-ci constituent un moyen de transférer un document d'un service à l'autre
  • les autorisations de redirection de service à service ou utilisateur

Les entités représentent les composants hiérarchiques de l'organisation auxquelles sont ensuite rattachées les utilisateurs.

Les droits d'accès aux documents et les droits aux services Maarch du profil de l'utilisateur sur une entité sont automatiquement répercutés sur toutes les entités de niveaux inférieurs par un système d'héritage.

Le positionnement dans l'organisation est ensuite mis à profit dans la gestion du périmètre documentaire, et dans la gestion des redirections dans les corbeilles de traitement.

Matrice de gestion des profils et des droits

La gestion de la sécurité et des utilisateurs dans Maarch peut être résumée à un système matriciel affectant à un groupe de profil une série de droits, choisis parmi les services proposés par l'application et ses modules.

La stratégie d'implémentation de la matrice est la suivante :

  • Définition de l’ensemble des fonctions disponibles, que ces fonctions soient natives dans Maarch ou bien des extensions spécifiques au projet.
  • Déclaration de ces fonctions/modules spécifiques au sein du fichier « services.xml » déclarant l’ensemble des services système et utilisateur apportés par le module.
  • Définition dans Maarch des profils utilisateurs. Ces profils utilisateurs doivent être en correspondance avec les profils déclarés dans l'annuaire LDAP. Il est souvent pertinent de compartimenter quelques grands groupes d’utilisateurs, puis d’affecter plusieurs de ces groupes à un utilisateur ayant plusieurs rôles.
  • Saisie des droits par clic dans une case à cocher dans la console d'administration Maarch.

Principe d'intégration des données annuaire dans le SAE

La connexion de l'utilisateur est gérée par un annuaire LDAP, base de données ou autre (nommé ACL). L'authentification des utilisateurs est gérée au travers d'une authentification unique CAS SSO. Ensuite, lorsque l’utilisateur se connecte au SAE, les habilitations sont validées par Maarch. A terme on pourra envisager une connexion à l'aide d'un certificat électronique.

Remarque : le système de sécurité Maarch est très bien adapté aux gros volumes de documents et à l’archivage documentaire. Il évolue aisément au fil des changements d’organisation, ce qui n’est pas le cas des systèmes à base d’ACL positionnées sur chacun des documents. Ce point est crucial dans le montage d’un projet d’archivage.

Voir aussi : http://www.maarch.org/projets/entreprise/gestion-de-la-securite

F4.P2: Gérer les demandes

Gestion de la salle de lecture

Un exemple de gestion des demandes est fourni par la problématique de la salle de lecture. Il s'agit ici d'un cas d'application parmi d'autres. Ce module n'a pas encore été générisé mais est disponible à la demande en mode projet.

Accueil du lecteur
  • Réception du lecteur par l’agent d’accueil
    • Si la personne n’est jamais venue, proposition de saisir sur l’ordinateur de l’accueil les informations de la « Fiche de lecteur »
    • Si la personne est déjà inscrite, il lui est demandé de s’enregistrer simplement. Il s’agit de saisir son identifiant et son mot de passe, qui permettront de retrouver la fiche.
    • Si le logiciel détecte que la fiche n’a pas eu de mise à jour annuelle, une mise à jour est proposée au lecteur.

idem si le logiciel détecte que la fiche est inactive.

  • A l’issue de la saisie, l’agent d’accueil vérifie les informations concernant la pièce d’identité, et valide la fiche et l’enregistrement.
  • Quand la personne est enregistrée dans la liste des personnes présentes ce jour, l’information est visualisable en salle de lecture.
  • Des statistiques sont disponibles :
    • nombre de personnes inscrites par jour
    • nombre de visites pour une personne, pour un thème, …..
OAIS lecteur.png

On peut demander la liste des lecteurs sur une période de date, et exporter le résultat de liste sous Excel.

Prêt en salle de lecture
OAIS salle lecture.png
  • Le lecteur va rechercher sur la (les) bases Archives les documents qui vont lui permettre de travailler. Le fait qu’il se soit enregistré en arrivant lui donne les droits de recherche sur un des PC de la salle de lecture.
  • En sélectionnant dans la liste résultant de la recherche, le lecteur peut constituer un « panier » des documents qu’il a sélectionné à l’issue de ses recherches. Il réalise un document PDF de son panier et l’envoie par courriel.
  • Quand le lecteur a terminé ses recherches, il coche les 3 documents qu’il souhaite obtenir en premier : cela constitue sa « commande ». Deux cas de figure peuvent se présenter :
    • Soit le document est disponible, et la commande arrive chez la personne en charge de la recherche des articles physiques.
    • Soit le document est incommunicable, et le responsable de la salle de lecture décide ou non de débloquer l’article, et en informe le lecteur.
  • Quand la commande est terminée, le lecteur lance l'édition des fantômes (avec les codes barres) sur les imprimantes des magasiniers, qui vont chercher les articles et les remplacent par les fantômes, et ramènent les articles en salle de lecture. Ils peuvent visualiser les demandes.
  • Quand il le donne au lecteur (l'un après l'autre), le responsable de la salle indique que l’article est communiqué.
  • Quand le lecteur a terminé sa consultation, il retourne l’article au responsable de salle. L’article est noté « Rendu » et le lecteur peut en recommander un autre.

Le lecteur a également la possibilité de demander que l’article soit réservé pour une consultation ultérieure, ne dépassant pas une semaine : le responsable de salle note « Réservé », et ne range pas l'ouvrage.

En fin de journée :

  • Le président de salle visualise la liste des prêts. Il peut éditer la liste des documents rendus.
  • Le lendemain, le magasinier remet les articles « rendus » à leur place et scanne le code barre du fantôme pour mettre le panier à jour avec la mention « Rangé ». Dans le cas des articles réservés, ils sont conservés en salle de lecture.
  • A la visite suivante du lecteur, les articles réservés sont automatiquement transférés dans son panier de commande, et notés par le responsable de salle « communiqué ».

Cas particulier du prêt au service producteur :

Ce prêt entraîne la sortie temporaire de l’article hors des archives. Il est géré par le responsable de salle qui remplit le panier commande de l’agent représentant le producteur, à sa place et saisit dans la catégorie de prêt « prêt extérieur ».

Ce statut ne bloque pas la cote : on pourra prêter les autres documents de la boite (de la cote). Dans ce cas, on dispose sur chaque article prêté d'une zone de commentaire pour les mentions particulières qui sont éditées sur la fiche fantôme (exemple : le dossier qui est prêté, et pas la totalité de l’article). Panier de recherche

En fonction du paramétrage de l’état du document ( communicable, dérogation, non communicable), le responsable de la salle de lecture est averti, et peut selon les cas débloquer ou non la cote. Le panier est conservé pour la fois suivante, et supprimé au bout de 100 j après sa dernière utilisation. Le lecteur peut supprimer son panier. Le lecteur peut intégrer 100 articles maximum. Le panier peut être généré en PDF et envoyé par courriel en proposant au lecteur son adresse courriel par défaut.

Pour passer d’un simple panier de recherche à un panier de commande, il suffit de cliquer une case à cocher « commande » sur les articles désirés. Panier de commande

Les règles de communication sont paramétrables par l’administrateur du système, par exemple :

  • 30 documents par jour
  • 3 documents à la fois

Le quota de n documents peut être étendu sur validation du président de salle (notamment pour le prêt au service producteur).

Si, parmi les articles commandés, un des documents n’est pas « disponible », un message avertit le lecteur qu’il doit contacter le responsable de salle, qui pourra le débloquer. Le lecteur peut également saisir une zone de commentaire à destination du responsable de salle.

Le lecteur lance l’impression de la fiche fantôme sur l’imprimante du magasinier, avec un code barre. Dès qu’un document est rendu, le lecteur peut en commander un autre.

F4.P3: Exécuter les requêtes

La recherche peut s'effectuer par plusieurs moyens :

  • par recherche directe sur les critères de qualification (Dublin Core, index Z42, index techniques Maarch, index fonctionnels)
  • par recherche sur le contenu textuel du document (recherche plein texte sur le contenu si activé, vu plus haut)
  • par recherche sur un dossier structuré
  • par exploration XML/EAD

Recherche directe ou sur contenu

La recherche directe est une recherche SQL sur index. Les écrans de recherche sont dynamiques, ou entièrement personnalisables.

La souplesse de Maarch permet de construire des écrans de recherche et des listes de résultat totalement personnalisés.

La recherche plein texte fonctionne grâce au moteur d’indexation libre Lucène, implémenté dans Maarch. Ce moteur supporte la recherche floue, phonétique, et le « stemming » (recherche de la racine du mot, puis déclinaison). L'indexation plein-texte, requise pour la recherche sur le contenu, peut être déconnectée. En effet, sur certaines collections documentaires, la recherche plein texte n'apporte pas une grande valeur ajoutée, et elle est consommatrice de ressources.

Le résultat de la recherche se présente sous la forme d’une liste correspondant aux documents trouvés. Cette liste est paginée, il est ainsi facile de passer d’une page à l’autre. Elle peut être triée par n’importe quelle colonne, et est paramétrable par un fichier de configuration (administrateur technique). Les recherches sont enregistrables par l’utilisateur, qui les retrouve dans son dictionnaire de recherche. Elles sont exécutées à nouveau à chaque appel.

Recherche sur dossier structuré

A la demande, Maarch structure le contenu documentaire par dossier. Chaque dossier dispose d'un plan de classement associé à son type. Par exemple :

  • Plan de classement RH pour un dossier RH
  • Plan de classement Client pour un dossier client

Le dossier dispose de ses propres métadonnées, sur lesquelles on peut lancer des recherches :

Certaines fonctions permettent de manipuler le regroupement plutôt que l'unité documentaire. Par exemple, la recherche de dossier affiche tous les documents du dossier selon le plan de classement, avec un espace pour afficher le contenu du document sélectionné :

Comme expliqué plus loin, il s’agit d’un plan de classement fixe associé à chaque instance de dossier, ce qui est idéal pour gérer des structures de dossier métier, avec comme point d’entrée le n° de dossier ou son intitulé (exemple d’application : dossier RH).

Des aides à la saisie par auto-complétion sont disponibles : la machine propose des valeurs existantes dans le référentiel, à partir des premiers caractères entrés.

Exploration XML/EAD

Maarch s'associe à la société Archimaine pour traiter la partie purement archivistique des projets. Une intégration poussée des produits Maarch et Archinöe ...

F4.P4: Mettre en forme

La mise en forme consiste à préparer les paquets d'informations DIP avant leur communication. Celle-ci va dépendre du mode de communication utilisé :

  • Communication synchrone avec affichage instantané
  • Communication asynchrone par ticket
  • Communication synchrone avec affichage instantané

Dans ce cas la préparation se limite à :

  • écrire un filigrane sur les pages du document (sous condition) – option (fichier de configuration ou interface d'administration – non encore déterminé)
  • préparer une version de consultation du document :

sur PDF, en fonction des droits et règles, empêcher le copier/coller, l'impression, l'enregistrement - option

  • appliquer de la stéganographie (marquage discret) – option non dans le périmètre, et à spécifier
  • appliquer un chiffrement avec transmission du mot de passe par courriel

Le document est présenté sur le poste client pour consultation ou téléchargement.

F4.P5: Communiquer

Ce processus revient à communiquer les paquets d’informations diffusés aux utilisateurs (DIP). En fonction du type de demande, la communication des résultats de la recherche pourra être obtenue :

  • directement en ligne par le navigateur ou téléchargement synchrone
  • par dépôt sur un espace distant chez le demandeur. Dans ce cas l'archive pourra être chiffrée, et le mot de passe de déchiffrement envoyé au demandeur par courriel. (hors périmètre immédiat).
  • Par transfert SEDA vers un autre SAE

Les écritures subséquentes des archives téléchargées sur clé USB, CD, etc ne sont pas du ressort de Maarch, et peuvent dès lors être divulguées sans contrôle, sauf à appliquer les options de marquage.

Communiquer avec SEDA

Ce standard s’inspire de la norme OAIS qui lui fournit d’une part les concepts de base et le vocabulaire de l’archivage numérique, et d’autre part la méthodologie de l'UN/CEFACT pour la forme des messages échangés (flux XML).

L’intégration du SEDA dans les systèmes d’information vise à éviter les ruptures de charge entre les différents partenaires et par exemple à éviter que des données descriptives identifiant des dossiers, qui sont enregistrées dans un système d’information, soient ressaisies manuellement par les services producteurs préalablement au versement des dossiers, sous la forme d’un bordereau de versement, puis ressaisies ensuite par le service d’archives dans son propre système d’information. La dématérialisation croissante des procédures et la masse des fichiers à verser qui en résultera imposent de passer à un processus de transfert automatisé.

Le standard précise le contenu et la structure des messages échangés, suivant que l’on souhaite effectuer un versement, éliminer des archives, communiquer ces archives, ou éventuellement les restituer. En particulier, il précise un ensemble de fichiers XSD qui fixe la forme des fichiers XML contenant les métadonnées dans un document AIP tel que défini dans le chapitre précédent.

Les informations devront être fixées dans les contrats d'échange entre le SAE et chacune des applications qui vont faire appel aux services du SAE.

Notons que le SEDA demande la création d’un profil, en coordination avec le SIAF (voir http://www.references.modernisation.gouv.fr/profils-du-standard-dechange-de-donnees-pour-larchivage-des-donnees-numeriques)

Communiquer aux Archives Départementales

La communication avec SEDA concerne principalement l'envoi par la collectivité vers les Archives Départementales de documents d'archives ayant atteint leur durée limite d'archivage intermédiaire. Le processus de communication avec SEDA est très formel et comprend des actions humaines et informatiques.

L'ensemble des messages échangés se fait par le protocole SEDA, tandis que les opérations de tri sont du ressort de l'archiviste collectivité, assisté par la machine.