Aller à : navigation, rechercher

Maarch RM/Étapes de la mise en œuvre

Ce document détaille les étapes de la mise en œuvre de votre système d'archivage électronique avec le logiciel Maarch RM. Il décrit les éléments d'architecture, de configuration, de paramétrage et d'intégration à prendre en compte pour déployer un système d'archivage électronique qui répond aux besoins de conservation et de respect des exigences normatives et réglementaires.


Définir les besoins fonctionnels

Cette étape est cruciale car elle permet d'exprimer les besoins en termes d'organisation des données et des processus liés à la conservation. Il s'agit d'identifier les différentes typologies de documents du point de vue du domaine d'activité de l'organisation, pour définir leur origine, leur mode de versement, leur description spécifique et leur cycle de vie dans l'archive.


Qualifier le niveau d'exigence

Il s'agit ici de définir le périmètre règlementaire et normatif dans lequel doit s'inscrire le système d'archivage. De cette expression des besoin découlera un ensemble d'exigences à respecter pour l'architecture matérielle, les procédures d'exploitation, la configuration et le paramétrage de la solution, etc. Cette liste est non exhaustive car elle ne tient pas compte des aspects administratifs et organisationnels des exigences, qui sont en-dehors du périmètre logiciel.

Archives publiques ou privées ?

La première question est : est-ce que mes documents entrent dans le domaine de l'archivage de données publiques ?

Si oui, il en découle un ensemble de règles très spécifiques. Le SAE doit respecter les exigences du SIAF (Service Interministériel des Archives de France) en termes de conservation des données publiques, et celles de la CNIL (Commission Nationale Informatique et Liberté) pour la conservation des données à caractère personnel.

Dans ce cadre, Maarch RM doit être configuré pour assurer un fonctionnement dans le respect de ces exigences, à savoir:

  • utiliser le SEDA (Standard d'Echange des Données pour l'Archivage) pour les échanges entre les acteurs
  • identifier les acteurs du système d'archivage et leur rôle, et permettre le contrôle scientifique et technique de l'état sur les archives
  • prendre en charge les métadonnées descriptives associées aux archives publiques pour leur indexation et leur recherche
  • respecter la norme ISO 14721 - OAIS
  • respecter la norme AFNOR NF Z42-013

Certification selon la NF461 ?

Les règles de la NF 461 décrivent les conditions d'application de la marque NF sur le système d’archivage électronique et les activités d’archivage électronique correspondantes, indiquant ainsi qu'elles garantissent aux documents archivés leur fidélité, intégrité, pérennité et traçabilité pour que ceux-ci puissent conserver leur valeur d’origine.

Si vous souhaitez obtenir la marque NF pour votre système d'archivage électronique, il vous faudra suivre les prescription du guide d'application AFNOR GA Z42-019 et valider les règles de certification de la norme AFNOR NF 461.

Maarch RM doit être déployé afin de respecter notamment les exigences suivantes:

  • production d'attestations de l'activité du prestataire d'archivage
  • sécurisation des journaux de l'application et du cycle de vie
  • stockage des données et métadonnées sur au moins 2 sites distants, dans un système de fichiers réinscriptible
  • utilisation d'une empreinte numérique sur les documents


La plupart de ces exigences sont adressées par défaut par Maarch RM et n'ont pas besoin d'être activées ou configurées. Il n'en reste pas moins qu'elle doivent mener à des décisions essentielles sur l'infrastructure à mettre en oeuvre et la configuration technique.

Analyse des flux

Classement

Chaque flux est associé à une activité et à un service producteur, selon une vue fonctionnelle – par opposition à une vue strictement hiérarchique de l'organisation. On obtient ainsi une classification des documents sur plusieurs niveaux qui définit en grande partie la politique de droits d'accès des différentes catégories de personnes et services aux documents archivés.

Par exemple, pour les factures de vente émises au sein d'un groupe de sociétés (ou holding), on définira le classement suivant :

Groupe
 |_ Société du groupe 
     |_ Direction Administrative et Financière
        |_ Comptabilité
           |_ Comptabilité clients
              |_ Facturation
                 |_ Factures de vente

Le dernier niveau de classement est notre typologie documentaire, les niveaux précédents décrivent l'organisation fonctionnelle de l'entreprise et/ou le plan de classement des documents.

Indexation

A chaque typologie documentaire correspond un jeu de données descriptives qui permettent de les rechercher et de les indetifier dans les listes. On reste ici à un niveau conceptuel, sans présumer de la manière dont sera structurée l'information.

Par exemple, les factures de ventes seront indexées à miniam selon

  • la société qui les a émises,
  • le tiers facturé,
  • le numéro de facture,
  • la date

Il n'est pas strictement nécessaire d'indexer selon le montant, car il ne représente pas une donnée d'identification du document mais correspond plus à un besoin de gestion (GED) et d'exploitation.

Une fois les typologies documentaires listées et l'ensemble des données d'indexation identifiées, il est possible d'établir le plan de classement avec, pour chaque domaine d'activité, un jeu de données utilisables pour décrire les documents archivés. Après analyse, cela permet d'établir le schéma de métadonnées qu'il faut implémenter dans Maarch RM pour la description des archives.

Règle de conservation

Chaque document doit indiquer, directement dans ses métadonnées ou par renvoi à un référentiel de gestion, sa durée de conservation par le SAE. Il faut donc préciser la DUA (Durée d'Utilisation Administrative) du document, son sort final pour les archives publiques ou présentant un intérêt historique ou patrimonial et le texte règlementaire permettant de définir cette règle.

Pour les factures de vente, la durée légale de conservation est de 10 ans à compter de la datée d'émission, au terme des quelles le document peut être détruit, selon le Code du commerce, art L. 123-22 - archivage électronique depuis 2006.

Origine et opérations au versement

Il faut préciser comment les documents vont être versés dans le système d'archivage et quelles sont les opérations nécessaires pour ce faire. Par exemple, certains documents sont produits sous la forme d'originaux papier et devront être numérisés, d'autres seront directement produits en tant qu'originaux nativement numériques. Pour les documents numériques, il peuvent être produits sur un poste d'utilisateur et ainsi nécessiter des opérations de versement intéractif, ou au contraire être issu d'une chaîne éditique qui déverse directement dans le SAE. Pour chaque flux on aura donc une procédure de veserment spécifique qui doit faire l'objet d'une documentation.

Cette analyse permet notamment de définir quelles sont les opérations optionnelles à réaliser dès le versement ou à postériori par le système d'archivage:

  • identification et validation du format lorsque le document numéique est reçu d'un tier et transmis au système
  • extraction des métadonnées intégrées au contenu (PDF, bureautique)
  • indexation manuelle ou vidéo-codage
  • extraction du texte pour indexation plein-texte
  • conversion de format non pérenne vers un format pérenne
  • validation par le service d'archives ou non avant dépôt

Volumétrie

Pour chaque typologie documentaire on évaluera le volume de données produites à conserver, notamment afin de définir l'espace de stockage nécessaire et les quotas éventuels à fixer dans les échanges pour sécuriser le système.

On peut noter

  • le volume de documents générés par période (jour, mois, année)
  • la taille globale des données générées
  • la taille maximale d'un document versé

Déployer un environnement

La première phase vous a permis de définir le périmètre documentaire et les exigences à respecter, cette étape sera le moyen d'implémenter une plateforme initiale pour intégrer votre éventuel modèle de données métier spécifique et valider les choix de configuration.

Architecture technique

L'infrastructure matérielle nécessaire et les pré-requis système doivent être étudiés pour permettre le déploiement du SAE et la réalisation des cas d'usage conformément aux exigences.

Serveur(s) applicatif(s)

L'instance du SAE Maarch RM peut être publiée sur un serveur applicatif unique, ou plusieurs serveurs accessibles au travers d'un frontal qui assure une bonne répartition des charges (load balancing).

Sur ces systèmes, un serveur HTTP Apache en version 2.4 ou supérieure va permettre de publier l'interface homme-machine et d'exposer les services internet. Il embarque le module PHP en version 5.4 ou supérieure (PHP5 Module), Maarch RM étant validé en environnement PHP 7, ainqi que les modules de définition des variables d'environnement (ENV Module) et de réécriture des routes http (REWRITE Module).

Le système dispose du l'espace disque suffisant pour l'installation de l'application (quelques Mo) et la production de fichiers temporaires. Lorsque l'application procède à des échanges de données d'archives, notamment pour le versement et la communication, elle utilise un sas d'échange qui est un répertoire qui doit être accessible à toutes les instances du SAE ainsi qu'aux éventuels logiciels tiers de transmission. Dans ce cas, il est recommandé d'allouer un espace disque suffisant pour conserver les paquets échangés sur une durée de quelques jours, dont la taille dépend de la quantité de données échangées.

Un fonctionnement local peut nécessiter 2Go de mémoire vive, à adapter selon le nombre d'utilisateurs et de requêtes simultanées attendues.

Le fonctionnement de Maarch RM peut nécessiter l'installation de logiciels compagnons listés dans la procédure d'installation. Il s'agit globalement d'utilitaires libres et open-source qui seront nécessaires pour la mise en oeuvre de fonctions répondant aux exigences spécifiques.

Serveur(s) de stockage

Ces systèmes seront utilisés pour le stockage des contenus numériques des archives. Il s'agit d'un ou plusieurs systèmes qui peuvent être adressés par une technologie de stockage implémentée par Maarch RM.

De base, et pour répondre aux exigences normatives, Maarch RM permet d'adresser des systèmes de fichiers reinscriptibles, des disques partagés, serveurs NAS ou SAN par exemple. Il est tout à fait possible d'implémenter d'autres connecteurs pour stocker les documents sur des supports WORM, des espaces en ligne dans le nuage, ou des technologies de stockage propriétaires spécifiques. Il faut cependant être attentif à ce que ce stockage soit sécurisé et permette de respecter les exigences identifiées pour votre système d'archivage.

L'espace de stockage nécessaire est à définir selon la volumétrie des archives versées pour la période de conservation associée.

Il faut aussi prévoir que chaque document pourra être accompagné de descriptions complémentaires qui constituent le paquet d'information archivé (AIP), c'est-à-dire l'information de représentation et l'information de préservation tels que définis dans la norme ISO 14721 – OAIS. De même, il est possible que le document original numérique fasse l'objet de conversions vers d'autres formats au cours de son cycle de vie, la probabilité augmentant avec la durée de conservation, la conversion étant presque obligée si les formats versés ne sont pas pérennes.

Serveur(s) de base de données

Maarch RM est validé pour les bases de données PostgreSQL 9.3 et supérieures, car il s'agit du SGBDR libre et open-source le plus robuste et performant du marché. Il est tout à fait envisageable d'adapter la couche d'accès aux données afin d'utiliser une base de données Oracle, MySql, Microsoft SQLServer ou autre, moyennant une courte phase de développement mais qui nécessiterait surtout un test complet de la solution.

Pour respecter certaines exigences normatives, il est à la charge de l'exploitant de réaliser une réplication de la base de données en utilisant les moyens matériels et logiciels de son choix, en mode maître-esclave ou maître-maître, pour sécurité, dans la cadre d'un plan de reprise d'activité ou de continuité d'activité.

Installation

Une fois l'environnement système préparé, il est temps de déployer une première instance de l'application Maarch RM.

Pour ceci, il suffit de suivre la procédure d'installation standard et d'adapter les valeurs de configuration et de paramétrage à votre environnement.

Configuration des instances

L'application est publiée par un ou plusieurs serveurs Http pour trois modes d'utilisation:

  • une utilisation interactive via l'interface homme-machine
  • l'appel aux services internet par des application tierces
  • l'appel aux services par des scripts du systèmes

Pour chacun de ces modes de publication, il faut établir une configuration de fonctionnement de l'application.

Les instances en mode client-serveur http (IHM ou web-services) sont publiées dans des hôtes virtuels par le serveur http. Pour chacun on précise le nom de l'hôte, le répertoire public de l'installation, seul à contenir des ressources exposées, les règles de réécriture (normalement fixées tel que dans l'exemple fourni dans la procédure d'installation), et les directives de configuration de l'application sous la forme de variables d'environnement définies par la commande Apache "SetEnv".

Les appels à l'application par des scripts système établissent la configuration adaptée lors de l'exécution sous la forme de variables d'environnement, soit les commandes "export" sur les systèmes Linux et "set" en environnement Microsoft Windows.

Certaines directives doivent être définies avec des valeurs identiques pour tous les modes d'accès car elles constituent la définition même de l'application, alors que d'autres valeurs sont adaptées à l'utilisation en mode interactif ou service et au périmètre métier exposé.

Parmi les valeurs constitutives de l'application instanciée et donc à reporter à l'identique dans toutes les configuration d'hôte et scripts, on notera :

  • le nom de l'instance (domaine) qui sert à identifier l'application publiée, notamment dans les architectures distribuées et entre les hôtes http et les scripts
  • la clé secrète de chiffrement des jetons de sécurité, qui doit permettre d'utiliser un jeton généré en interactif dans les appels en mode ligne de commande
  • la liste des paquets (bundles service/métier et dépendances techniques) qui devraient être constants quel que soit le mode d'accès.
  • Le chemin du fichier de paramétrage. Bien qu'il ne soit pas nécessaire d'avoir un fichier unique pour toutes les instances publiées, il est fortement conseillé de ne pas multiplier les fichiers de paramétrage qui risquent de provoquer des dysfonctionnements en cas de valeurs contradictoires.

Les autres valeurs permettent d'adapter le fonctionnement en précisant par exemple une couche de présentation pour l'IHM (absente pour le mode service web), la gestion du cache Http et mémoire, le mode de production des traces système, le mode de gestion des erreurs, etc.

La liste complète des directives de configuration de l'instance est fournie dans une autre documentation.

Paramétrage technique et métier

La configuration des instance publiées précise donc un fichier de paramétrage qui définit le comportement des paquets logiciels, fonctionnels métier ou techniques, livrés avec l'application. Il s'agit de fichiers d'initialisation utilisant la même syntaxe et structure que ceux du moteur PHP, avec en plus la possibilité de définir des valeurs complexes à la manière de la notions json.

Dans le paramétrage des paquets, il est nécessaire d'adapter les directives suivantes, une barre oblique indiquant que la première valeur représente une section:

  • @var.Dsn, @var.username et @var.password : chaîne et informations de connexion à la base de données.
  • medona/messageDirectory : chemin du répertoire d'échange de données d'archives.
  • recordsManagement/profilesDirectory : chemin du répertoire des profils de validation des échanges.
  • recordsManagement/archivalProfileType : type de profil pour la validation des échanges seulement, pour la description seulement, pour les deux.
  • les configurations spécifiques des logiciels compagnons, notamment dans les dépendances fileSystem et xml

Le détail de ces configuration est fourni dans une autre documentation.

Personnalisation

Lorsque l'expression des besoins a montré la nécessité d'implémenter un modèle de données spécifique pour la description des archives, il est nécessaire de se reporter à la procédure spéifique associée, dont les principales étapes sont les suivantes:

  • définition du modèle de données
  • ajout de la logique du métier pour l'enregistrement la recherche, la lecture et la suppression des métadonnées descriptives
  • création des écrans de recherche et listes de résultat

La plus grande partie des fonctions archivistiques sont rendues disponibles à l'utilisateur en branchant des appels aux services de gestion livrés en standard: affichage des données, affichage des métadonnées, modification, gel/dégel, demande de communication, demande d'élimination, etc.

Administrer

Avant de commencer à utiliser le système d'archivage et de réaliser les premiers versements, il est nécessaire de configurer l'application selon 3 axes:

  • l'administration fonctionnelle pour assurer la sécurité et définir les rôles et autorisations
  • l'administration technique pour adapter les processus aux exigences
  • l'administration archivistique pour alimenter les référentiels nécessaires à la gestion des archives

Administration fonctionnelle

Utilisateurs

Les données de base livrées avec l'application déclarent un super utilisateur nommé superadmin, dont le mot de passe est superadmin. Il est fortement conseillé de modifier ce mot de passe par défaut avant toute autre opération.

Le panneau de gestion des utilisateurs permet ensuite de déclarer les utilisateurs de l'application, avec pour chacun le moyen de l'identifier par un nom unique et un mot de passe. Chaque utilisateur pourra ultérieurement être rattaché à un ou plusieurs rôles fonctionnel et positionné dans un ou plusieurs services de l'organisation.

Comptes de service

Pour que les logiciels tiers puissent accéder aux services exposés par l'application en mode web-service, il est nécessaire de déclarer un ou plusieurs comptes de service, avec pour chacun le moyen de l'identifier par un nom unique et de générer un jeton d'authentification sécurisée. Chaque service pourra ultérieurement être rattaché à un service de l'organisation.

Rôles

Cette partie permet de définir des rôles fonctionnels dans l'application pour les utilisateurs. L'application est livrée de base avec des rôles adaptés à l'archivage:

  • Le rôle administrateur permet d'accéder à l'administration fonctionnelle et technique
  • Le rôle archiviste permet d'accéder aux fonctions de gestion archivistique
  • Le rôle utilisateur permet d'accéder aux fonctions d'échange de données d'archives, notamment le dépôt, la recherche et la consultation

Ces rôles attribuent des droits d'accès aux fonctionnalités (aussi appelés privilèges) mais ne définissent en aucun cas les droits d'accès aux données d'archives ou aux bordereaux d'échange. Cette mécanique est portée par la définition de l'organisation fonctionnelle et le positionnement des utilisateurs et comptes de service au sein de l'organisation.

Contacts

Le respect de certaines exigences normatives ou règlementaire implique de définir un moyen de contacter les acteurs des échanges de données d'archives. Concrètement, il s'agit de déclarer un ou plusieurs contacts, avec des adresses et moyens de communication, qui seront rattachés aux services afin d'apparaître dans les échanges.

Chaque contact est déclaré comme une personne physique ou morale, avec un nom complet, un identifiant unique, ainsi qu'une ou plusieurs adresses et un ou plusieurs moyens de communication: e-mail, téléphone, fax, etc.

Organisation

Cette partie permet de déclarer l'organisation fonctionnelle et de positionner des utilisateurs et comptes de service au sein de l'organisation afin de définir les droits d'accès aux données d'archives.

Deux entités principales sont gérées:

  • les organisation représentent les collectivités, les entreprises ou organismes. Elles peuvent contenir d'autres organisation et des unités organisationnelles.
  • les unités organisationnelles représentent les services des organisations du point de vue fonctionnel, c'est-à-dire selon leur activité. Chacune possède un ou plusieurs rôles d'acteur archivistique (voir liste ci-dessous). Elles peuvent contenir d'autres UO.
groupe
 |_ société A
 |  |_ service A1
 |  |_ service A2
 |     |_ service A2.1
 |_ société B
    |_ service B1

Les rôles des services archivistiques prévus par l'application sont les suivants:

  • Service d'Archives : il est responsable de la conservation des données pour une ou plusieurs organisations
  • Service Versant : il est responsable du transfert des données d'archives des producteurs à un service d'archives
  • Service Producteur : il est à l'origine des documents archivés
  • Service de Contrôle : dans le cadre d'un archivage sphère publique, il est responsable du contrôle scientifique et technique de l'état sur les archives
  • Service Demandeur : lorsque les archives ne sont pas librement communicables, il est en mesure d'effectuer des demandes de communication d'archives avec dérogation
  • Opérateur d'Archivage : unique sur le système, il est responsable du fonctionnement du système d'archivage

L'administration de l'organisation permet de positionner d'autres entités définies au travers de panneaux d'administration différents:

  • les utilisateurs des services (possible aussi à partir du panneau d'administration des utilisateurs)
  • les comptes de service (possible aussi à partir du panneau d'administration des comptes de service)
  • les contacts d'un service ou d'une organisation
  • les adresses et moyens de communication d'un service ou d'une organisation

Pour ces deux derniers points, il existe deux manières de rattacher un contact à un service ou une organisation:

  • ajouter une personne (morale ou physique) de contact, dont les informations apparaîtront en plus des adresses et communication
  • lier le contact comme représentant l'entité, dont seuls les adresses et moyen de communication seront accolés au service
Pour un contact ajouté :
  service
    |_ contact
         |_ adresses
         |_ communications

Pour un contact lié :
  service
    |_ adresses
    |_ communications

Administration technique

Stockage

Cette partie permet de déclarer les sites de stockage des documents d'archives. Elle est composée de deux panneaux:

  • la déclaration des supports de stockage
  • la déclaration des grappes de stockage

Chaque support possède un nom unique, un type de stockage et des paramètres pour accéder au service de stockage. Les technologies de stockage peuvent être multiples:

  • système de fichiers réinscriptible
  • système WORM (Write Once Read Many) logique ou physique
  • serveur FTP
  • service du nuage (Google Drive, Microsoft Azure, DropBox...)

Selon le niveau d'exigence, seuls certains systèmes seront utilisables. Maarch RM est livré en standard avec un connecteur pour système de fichiers réinscriptibles.

Une fois les supports déclarés, il sont organisés au sein de grappes, chaque grappe possédant un nom unique et regroupant un ou plusieurs supports de stockage avec des priorités en écriture, lecture et suppression pour définir les modalités d'accès aux données stockées.

Niveau de service

A mi-chemin entre la technique et l'archivistique, le niveau de service représente la manière dont les données d'archive seront gérées par le système. On peut déclarer plusieurs niveaux de service pour répondre à plusieurs niveau d'exigence normatives ou contractuelles, chaque archive déposée pouvant en effet être rattachée à un niveau de service particulier.

Le niveau de service définit notamment:

  • les opérations réalisées lors du dépôt : détection de format, validation de format, conversion de format, extraction plein-texte, contrôle antivirus
  • les opérations à réaliser ultérieurement (à venir)
  • la grappe de stockage utilisée

Formats et outils

La maîtrise des formats de contenus archivés est une facette essentielle du système d'archivage. Cette partie permet de déclarer le référentiel de formats et les outils utilisés pour les opérations de migration.

Le référentiel de format est livré avec la dépendance fileSystem, sous la forme d'un fichier XML. La version utilisé par l'application est affichée dans l'écran de gestion des formats. Une version plus récente peut être téléchargée sur le site des Archives Nationale du Royaume-Uni et déployée dans Maarch RM.

La configuration technique déclare les outils de conversion de format disponibles, avec pour chacun les formats acceptés en entrée et ceux produits en sortie. Un panneau d'administration vous permet d'activer la conversion pour des formats d'entrée vers les formats cibles souhaités. La conversion sera effectuée au versement (si activée dans le niveau de service) ou planifiée.

Administration archivistique

Un archiviste doit gérer les référentiels éventuellement nécessaires à l'utilisation du système d'archivage par les différents acteurs. Ceci inclut:

  • le tableau de gestion
  • les règles d'accès
  • les profils d'archives (ou typologies documentaires)
  • les accords de versement
  • les plans de classement des producteur (à venir)

Tableau de gestion

Ce référentiel, facultatif pour les application de la sphère publique, permet de déclarer des règles de conservation des documents par :

  • un code
  • un nom et une description
  • une durée d'utilisation administrative (délai de conservation)
  • un sort final (détruire ou conserver donc transférer à un archivage définitif)
  • la référence à la règlementation

Règles d'accès

Ce référentiel permet de déclarer les codes d'accès portés par les archives pour identifier leur accessibilité aux différents acteurs.

  • un code
  • une description
  • un délai de communicabilité

Profils d'archives

Le profil permet de déclarer les typologies documentaires selon deux visions complémentaires :

  • Dans la vision SEDA et NF Z44-022 MEDONA, le profil est un moyen de contrôler que les informations versées comportent bien les données de gestion et de description attendues
  • Dans la vision NF Z42-013, le profil est un moyen de factoriser les informations relatives aux archives gérées, afin de limiter l'information échangée et/ou conservée. Chaque document d'archive peut déclarer un profil, qui permet de retrouver les règles de gestion et de constitution des métadonnées associées

Maarch RM permet d'utiliser indifféremment l'une ou les deux visions:

  • télécharger un fichier de profil SEDA/MEDONA au format RelaxNG pour valider les flux XML des bordereaux de dépôt
  • définir le format des métadonnées descriptives, rattacher à une règle du tableau de gestion et une règle d'accès
Profil d'archive
 |_ contenu en métadonnées descriptives
 |_ règle de conservation (tableau de gestion)
 |_ règle d'accès

Accords de versement

L'accord de versement permet de déclarer les termes d'un accord liant les trois acteurs principaux du système que sont le service d'archives, le service versant et le service producteur. Il définit

  • la fréquence et la volumétrie des versements
  • le profil des archives versées
  • le niveau de service applicable
  • les formats acceptés
  • les règles de gestion des dépôt (workflow)

Plans de classement

A venir

Le plan de classement des producteur permet de positionner les documents archivés dans un plan hiérarchique virtuel (qui n'a aucune conséquence sur le stockage).

Pour chaque service producteur, il définit une arborescence de classement qui reflète l'organisation de l'activité qui mène à la production des documents, chacun pouvant être classé à un ou plusieurs endroits.

Exploiter

Tous les éléments sont réunis pour permettre d'exploiter le système d'archivage et assurer la conservation des documents dans le respect des exigences définies.

  • le logiciel est déployé et mis en ligne
  • les ressources techniques et logicielles tierces sont accessibles
  • les données de référence sont alimentées pour la sécurité et les règles métier

Cas d'usage

Il est désormais possible pour les utilisateurs membres des services versants de procéder à des versements dans le cadre éventuel d'un accord avec le service d'archives, aux producteurs d'archives d'accéder à leurs documents, au services d'archives de prendre la responsabilité de la conservation et d'assurer une gestion efficace et cohérente des archives.

  • versement interactif ou par lot
  • recherche et consultation
  • communication au producteur ou demandeur avec dérogation
  • modification des règles de conservation, des règles d'accès, des métadonnées, gel et dégel de l'application du cycle de vie
  • contrôle de conformité à la demande ou planifié
  • conversion de format planifiée
  • élimination des archives à terme de leur DUA pour destruction ou transfert en archives définitives
  • restitution des archives au producteur

Les cas d'usage sont détaillés dans une documentation dédiée.

Production de journaux

L'exploitation du système va produire un certain nombre de traces de l'activité dans deux journaux distincts:

  • le journal du cycle de vie de l'archive, accompagné des messages échangés entre les acteurs, permet de retracer tous les événements ayant trait à la vie de l'archive
  • le journal de l'application conserve une trace de tous les événements applicatifs tels que les connexions et les appels aux fonctions

Exploitation système

Des procédures complémentaires peuvent être mises en place via des scripts système qui appellent en ligne de commande des services réalisant les opérations planifiées:

  • prise en charge des bordereaux de versement pour la validation et le dépôt final
  • ressortie des données et métadonnées pour la communication, la restitution et le transfert vers un archivage définitif (ou autre tiers)
  • opérations de conversion de formats
  • archivage sécurisé des journaux du cycle de vie et de l'application
  • sauvegardes