Après 2 années de préparations intensives et le lancement de la réalisation début 2016, je reviens dans mon blog avec quelques précisions sur le modèle de données Vitam, mais cette fois sur une orientation très "stockage" et "calcul" au service de l'archivage électronique.
Dans le cadre du projet Vitam, des réflexions ont été menées pour gérer et proposer de nouveaux services au mieux dans le cadre des archives numériques publiques. Vitam est un projet français interministériel dont l'objectif est de développer un logiciel libre pour gérer des archives et leurs métadonnées dans un back-office pour les administrations publics en général, que ce soit pour les archivistes et les gestionnaires de données ou que ce soit pour les informaticiens.
Dans le cadre du projet Vitam, des réflexions ont été menées pour gérer et proposer de nouveaux services au mieux dans le cadre des archives numériques publiques. Vitam est un projet français interministériel dont l'objectif est de développer un logiciel libre pour gérer des archives et leurs métadonnées dans un back-office pour les administrations publics en général, que ce soit pour les archivistes et les gestionnaires de données ou que ce soit pour les informaticiens.
L'objectif est de réaliser un logiciel fiable d'archivage, autorisant le stockage et la préservation de plusieurs milliards d'éléments numériques. Chaque élément est un objet numérique (un document, une image, une vidéo, ...) qui possède ses métadonnées elles-aussi numériques (métadonnées techniques, descriptives et de gestion, dont les droits d'accès et les durées de conservation ainsi que le sort final). Ce logiciel devra présenter des garanties de sécurité et maintenir et conserver les valeurs légales de ces éléments (intégrité, valeur probante et confidentialité).
Cet article se concentre sur deux aspects : le stockage des AIP (paquets d'archives définis dans le modèle OAIS [1])
- en respectant les usages et les nécessaires calculs pour chaque élément numérique, tous les deux dans un contexte de plusieurs milliards d'éléments et d'actions,
- en assurant une compatibilité d'usage depuis la création et jusqu'aux archives historiques.
Ces deux aspects conduisent à une implémentation suivant l'esprit du stockage en nuage (Cloud storage) et du calcul en nuage (Cloud computing), en fonction des normes et standards qui s'appliquent. Il n'est pas question de stockage auprès d'hébergeur du "Cloud" pour des raisons légales et de sécurités mais bien d'un hébergement réalisé par l'Etat sur ses propres infrastructures. Le modèle fonctionnel de Vitam est basé sur l'OAIS [1] et intègre également les standards de la gestion des enregistrements (records management) comme ICA-Req [2] et MoReq [3] afin d'adapter le système aux besoins des agences publics françaises.
Certains aspects liés à la valeur probante seront abordés, mais ils ne font pas partis du coeur de cet article.
Cet article décrit les motivations et les propositions d'implémentations qui ont à ce jour émergées. Il ne constitue pas une documentation à proprement parlé de Vitam mais une réflexion ouverte au plus grand nombre dans un objectif de partager et d'améliorer ma vision.
Comme toujours, ce blog est réalisé à titre privé et personnel.
Certains aspects liés à la valeur probante seront abordés, mais ils ne font pas partis du coeur de cet article.
Cet article décrit les motivations et les propositions d'implémentations qui ont à ce jour émergées. Il ne constitue pas une documentation à proprement parlé de Vitam mais une réflexion ouverte au plus grand nombre dans un objectif de partager et d'améliorer ma vision.
Comme toujours, ce blog est réalisé à titre privé et personnel.
NB : Une version en anglais était prévue pour être publiée dans une revue mais à ce jour elle n'a pas été acceptée. Les schémas sont ainsi en anglais car directement issus du travail de préparation de l'article en question.
De plus, comme un élément peut avoir plusieurs vues selon son usage immédiat, comme par exemple en photographie le master (format RAW), la version de diffusion (JPG sans perte) ou sa vignette (petit JPG de quelques kilooctets) sont plusieurs vues de la même image, chaque vue doit pouvoir être considérée et accédée séparément. En effet, le format et son obsolescence doivent être considéré en fonction de son usage (le master pour le très long termes, la diffusion et la vignette pour les courts à moyens termes). Comme décrit également dans le modèle SEDA, il a été introduit la notion d'ObjectGroup (que l'on retrouve aussi dans l'EAD sous le termes de DAO set ou group) qui recouvre toutes les versions des objets binaires pour tous les usages pour un élément particulier.
Par exemple, un élément constituant un objet d'archives cohérent pourrait être constitué d'une version papier native, d'une version native originale (format LibreOffice ODT), d'une version de diffusion (PDF) et d'une version vignette (JPG de la première page).
Les accès aux AIP doivent aussi permettre de modifier les métadonnées (descriptives et/ou de gestion) à n'importe quel moment. Ainsi, il faut considérer que si l'objet binaire n'est pas modifiable, les métadonnées elles peuvent l'être. Par exemple, un dossier d'affaires avec ses sous-dossiers et ces éléments constitutifs pourraient être créés dans un système d'archivage avec un statut "ouvert", signifiant que ce dossier d'affaire n'est pas "clos" (ais le sera plus tard) et pourra ainsi être mis à jour jusqu'à ce moment. Il peut même être considéré des cas où les modifications interviennent après la clôture, par exemple pour un reclassement ou l'ajout de précisions ou de nouvelles règles de gestion.
Cette contrainte tend à nouveau à ne pas créer une collection d'archives (AIC de type TAR ou ZIP) mais à créer un AIP unitaire par élément (AIU).
Si cette façon de faire est tout à fait valable dans les conditions évoquées, dans la perspective qui nous occupe, ceci n'est plus acceptable car la démultiplication des objets et des opérations associées (tant en lecture unitaire qu'en traitement de masse) tend à découper au maximum pour favoriser la performance, tout en limitant ce découpage à un niveau acceptable pour des raisons de sécurité et d'homogénéité.
Je crois de plus que, même pour la gestion des archives "inactives" (sans modification), qu'il sera nécessaire de pouvoir accéder séparément aux métadonnées ou à la partie binaire, et ceci de manière unitaire et rapide, faisant suite aux nouvelles habitudes et outils liés à Internet et aux politiques liées à l' "Open Data" et à l' "Open Gouv".
Il faut noter que même les auteurs de l'OAIS dans [5] indiquent qu'un AIP totalement intégré n'est pas la seule option :
La Figure 3 présente une comparaison graphique de la représentation selon l'OAIS d'un AIP et celle qui est proposé ici. L'AIP conceptuel de l'OAIS se retrouve éclaté en différents sous-AIPs, un pour les métadonnées de description et de gestion, un pour les métadonnées techniques, un pour le journal du cycle de vie du Unit et un pour le journal du cycle de vie de l'ObjectGroup, et enfin plusieurs Binary Objects, un pour chaque version/usage de l'ObjectGroup.
Processus d'élimination
Le processus d'élimination est piloté par les métadonnées de gestion (fonction des lois et règles de protection des données, notamment la durée de rétention et le sort final à la fin de cette durée) positionnées sur les Units.
Une fois qu'une unité d'archives a sa date de validité dépassée, Vitam vérifiera alors récursivement sur ses enfants (dans l'arborescence du plan de classement) pour vérifier s'ils ont des exceptions. Une fois ces exceptions appliquées, seules les branches valides pour l'élimination sont proposées à l'archiviste en charge de la gestion.
Une fois la validation opérée par l'archiviste, la destruction est alors récursivement réalisée uniquement sur ces unités d'archives valides et validées.
Un ObjectGroup est détruit uniquement si tous les unités d'archives (Units) parentes sont elles-mêmes détruites.
Par exemple, dans la Figure 4 représentant une hiérarchie d'unités d'archives et les ObjectGroups associés :
Par exemple, il est possible de demander : "Je cherche une unité d'archive qui contienne cette information (la partie where de la requête), mais dont au moins un objet binaire existe avec un format vignette". Ou encore, "mais retourne moi les objets binaires correspondants au format vignette.
Bien sûr, en cas de réversibilité, le DIP produit devra être "complet", c'est-à-dire contenant l'ensemble des informations disponibles pour les unités d'archives concernées et dans un format SEDA.
Dans toutes les situations, les droits d'accès sont calculés en utilisant les métadonnées de gestion, sur la base d'un calcul en modèle hiérarchique (les arbres de Units), afin de vérifier la validité de la requête vis à vis du demandeur.
Contexte de l'administration française
En France, le processus d'archivage démarre à la date de création du document, ce qui conduit à considérer 3 âges : la création, la validation et l'usage (archivage courant), suivi de son usage à des fins légales ou institutionnelles (archives intermédiaires) et enfin son usage historique (archivage définitif). (NB: je ne prétends pas ici redéfinir ou mieux définir les termes archivistiques alors que je ne suis qu'un informaticien, mais juste poser un cadre à cet article pour mes propres besoins)
L'objectif poursuivi est de fournir une réponse aux 3 âges, avec un cas d'usage dont les deux limites basses seraient :
L'objectif poursuivi est de fournir une réponse aux 3 âges, avec un cas d'usage dont les deux limites basses seraient :
- le nombre d'éléments numériques stockés, probablement au moins 1 million,
- la durée de rétention, probablement au moins 10 ans.
En effet, que l'une ou l'autre de ces limites soient dépassées semble une condition suffisante pour considérer des solutions capables de gérer des milliards d'éléments tout en conservant leur lisibilité dans le temps (en transformant les formats globalement tous les 10 ans au moins). Si ces deux limites ne sont pas atteintes, alors il existe probablement d'autres solutions plus "simples" pour répondre à ces besoins. Il faut entendre "plus simple" au regard des efforts d'installation et d'exploitation des outils informatiques nécessaires pour gérer cette multitude et cette durée. Dans des cas très limités, par exemple, un tableur peut suffire à gérer ses archives.
La solution envisagée doit servir, pour tout élément nativement numérique fraîchement créé, les fonctions de recherche dans un système d'archivage (la partie "requête" de l'OAIS) et d'accès à un élément unique (pouvant être tant sa partie métadonnées, sa partie objet binaire ou les deux), et ce dans un délai "court", compatible avec les besoins métiers concernés.
Nos hypothèses de "délai court" sont les suivantes :
La solution envisagée doit servir, pour tout élément nativement numérique fraîchement créé, les fonctions de recherche dans un système d'archivage (la partie "requête" de l'OAIS) et d'accès à un élément unique (pouvant être tant sa partie métadonnées, sa partie objet binaire ou les deux), et ce dans un délai "court", compatible avec les besoins métiers concernés.
Nos hypothèses de "délai court" sont les suivantes :
- moins de 1 seconde pour une requête "simple", jusqu'à une minute pour des requêtes complexes,
- moins de 10 secondes pour un accès à un élément de 100 Ko.
Si ces chiffres font références bien sûr au cas de l'archivage courant pour les usages métiers réguliers (consultation des dossiers actifs), ils peuvent être étendus aussi jusqu'aux archives définitives qui pourraient ainsi bénéficier de ces temps de réponses, si ce n'est maintenant, probablement dans le futur. Notre monde évolue vers une possibilité d'accès aux données de manière facilitée et rapide, selon le principe de l'Open Data, et en particulier de l'Open Gouv. Cela devrait conduire à vouloir améliorer les temps de réponses aux documents "publics" (accès non restreint) y compris pour les archives historiques.
Je ne reviendrais pas sur le modèle de données que nous avions présentés dans le cadre de Vitam en 2013 au sein de iPRES [4], mais je vais donc me focaliser sur le modèle de stockage ainsi que les impacts sur le modèle de calcul associé.
Je ne reviendrais pas sur le modèle de données que nous avions présentés dans le cadre de Vitam en 2013 au sein de iPRES [4], mais je vais donc me focaliser sur le modèle de stockage ainsi que les impacts sur le modèle de calcul associé.
Pour le modèle de données, je vous invite à consulter l'article de iPRES ([4] ou Article iPRES 2013) ou les quelques éléments présentés dans ce blog : "Présentation préliminaire du schéma VITAM conçu pour le versement d’archives"Pour l'AIP, comme dans "OAIS Reference Model" [5] et dans e-Ark [6], il est distingué :
De la même manière, le langage de requête proposé est décrit :
- Billet de 2014 sur le modèle de requête proposé : "Un langage de requêtes pour rechercher et consulter des archives depuis un front-office vers un SAE back-office"
- Et très récemment, Vitam a publié ses API Alpha qui reprennent et améliorent le modèle de requête : Site de publication des API Vitam - http://api.programmevitam.fr/
- la partie binaire de l'archive (data object),
- la description technique de l'objet numérique (métadonnées techniques),
- la description informative (métadonnées de description),
- les métadonnées de gestion archivistiques (métadonnées de gestion) comme les droits d'accès, la durée de rétention, l'historique de préservation (journal du cycle de vie)
- et finalement le plan de classement (représentation hiérarchique, voir l'article [4] de iPRES 2013).
A part le journal du cycle de vie, les métadonnées sont standardisées en France avec le SEDA [7] (Standard d'Echange de Données pour l'Archivage) qui fait partie de notre référentiel général d'interopérabilité national (RGI [8]).
Définition de l'AIP dans le contexte Vitam
AIP orienté ACCES
La plupart des usages envisagés conduit à favoriser l'accès à un élément unique et non seulement à un ensemble d'éléments (un lot d'archives), et ce dans un temps raisonnable. Les archives papiers, de par leur conditionnement et les précautions de manipulation, sont stockées par lot (des cartons) et accédées selon un processus parfois dépassant la journée. Dans le cas des archives numériques, et en particulier pour les archives courantes et les archives intermédiaires, l'accès aux archives doit pouvoir être unitaire (grain fin) et donc utiliser le modèle Archive Information Unit (AIU) et non Archive Information Collection (AIC) (cf [5]). Il s'avère que ce besoin est de plus en plus visible au niveau des archives définitives également. Cet accès unitaire impose que le stockage de ces éléments soit compatible avec ce besoin.
De plus, comme un élément peut avoir plusieurs vues selon son usage immédiat, comme par exemple en photographie le master (format RAW), la version de diffusion (JPG sans perte) ou sa vignette (petit JPG de quelques kilooctets) sont plusieurs vues de la même image, chaque vue doit pouvoir être considérée et accédée séparément. En effet, le format et son obsolescence doivent être considéré en fonction de son usage (le master pour le très long termes, la diffusion et la vignette pour les courts à moyens termes). Comme décrit également dans le modèle SEDA, il a été introduit la notion d'ObjectGroup (que l'on retrouve aussi dans l'EAD sous le termes de DAO set ou group) qui recouvre toutes les versions des objets binaires pour tous les usages pour un élément particulier.
Par exemple, un élément constituant un objet d'archives cohérent pourrait être constitué d'une version papier native, d'une version native originale (format LibreOffice ODT), d'une version de diffusion (PDF) et d'une version vignette (JPG de la première page).
Les accès aux AIP doivent aussi permettre de modifier les métadonnées (descriptives et/ou de gestion) à n'importe quel moment. Ainsi, il faut considérer que si l'objet binaire n'est pas modifiable, les métadonnées elles peuvent l'être. Par exemple, un dossier d'affaires avec ses sous-dossiers et ces éléments constitutifs pourraient être créés dans un système d'archivage avec un statut "ouvert", signifiant que ce dossier d'affaire n'est pas "clos" (ais le sera plus tard) et pourra ainsi être mis à jour jusqu'à ce moment. Il peut même être considéré des cas où les modifications interviennent après la clôture, par exemple pour un reclassement ou l'ajout de précisions ou de nouvelles règles de gestion.
Cette contrainte tend à nouveau à ne pas créer une collection d'archives (AIC de type TAR ou ZIP) mais à créer un AIP unitaire par élément (AIU).
AIP orienté sécurité à l'ECRITURE
Afin de limiter l'impact des écriture sur un élément, considérant qu'une opération d'écriture est l'événement le plus insécurisé, et ce quelque soit la solution de stockage mise en oeuvre, il a été décidé de limiter les risques en considérant 4 blocs composant un AIU en répartissant ainsi les événements d'écritures en fonction des blocs :
- l'objet binaire en tant que contenu numérique (Objet Binaire, Binary Object aussi nommé Binary Object AIP),
- les métadonnées techniques de cet objet, regroupées pour toutes les versions et usages dans un seul groupe d'objets (Groupe d'Objets, ObjectGroup nommé aussi Technical Metadata AIP),
- L'ensemble des Binary Object AIPs et du Technical Metadata AIP forme ainsi le Binary AIP.
- l'unité d'archives contenant à la fois les métadonnées de gestion et de description (Unit aussi nommé Metadata AIP),
- le journal du cycle de vie de l'unité d'archives et le journal du cycle de vie du groupe d'objets (respectivement Metadata AIP logbook et (Binary) AIP logbook).
Chaque opération survenant durant la vie de l'unité d'archives ne devra impacter que la surface la plus minimale possible, par exemple :
- Modifier les métadonnées (de gestion ou de description) ne doit impacter que le Metadata AIP ;
- Mettre à jour le groupe d'objets (en ajoutant ou en supprimant une version) ne doit impacter que le Technical Metadata AIP et bien sûr le Binary Object AIP concerné ;
- Une opération d'élimination impactera les nécessaires Métadata AIP, les Technical Metadata AIP et les Binary Object AIP ;
- Chaque action impactera les journaux du cycle de vie correspondant (Metadata AIP logbook, (Binary) AIP logbook) ; en effet, ces journaux participent pleinement au maintient de la valeur probante systémique comme défini dans la NF Z42-013 [9] (aussi disponible en ISO 14641-1).
Comparaisons avec d'autres implémentations
Des différences existent entre cette proposition et d'autres modèles d'implémentations comme celui de e-Ark [6] ou celle utilisée par SPAR à la BNF [19]. Selon nous, les raisons principales de ces différences sont :- ces implémentations ciblent essentiellement la gestion d'archives où aucune modification ne peut intervenir, exceptée pour des raisons de préservation de la lisibilité ;
- les accès ne sont pas fréquents et ne nécessitent pas des temps d'accès contraints et faibles.
Si cette façon de faire est tout à fait valable dans les conditions évoquées, dans la perspective qui nous occupe, ceci n'est plus acceptable car la démultiplication des objets et des opérations associées (tant en lecture unitaire qu'en traitement de masse) tend à découper au maximum pour favoriser la performance, tout en limitant ce découpage à un niveau acceptable pour des raisons de sécurité et d'homogénéité.
Je crois de plus que, même pour la gestion des archives "inactives" (sans modification), qu'il sera nécessaire de pouvoir accéder séparément aux métadonnées ou à la partie binaire, et ceci de manière unitaire et rapide, faisant suite aux nouvelles habitudes et outils liés à Internet et aux politiques liées à l' "Open Data" et à l' "Open Gouv".
Il faut noter que même les auteurs de l'OAIS dans [5] indiquent qu'un AIP totalement intégré n'est pas la seule option :
“Arrangements for storing archived information and its metadata are left to the OAIS’s implementers; possible solutions might range from complete physical integration, to storage in separate yet logically related databases.”
Bien sûr l'implémentation proposée maintient les liens nécessaires entre les différentes parties avec la prise en compte du risque de perte (fault tolerance). Ainsi, si un événement conduit à détruire définitivement une partie, sans qu'il ne reste aucune copie, il sera toujours possible de reconstruire les liens entre les parties restantes, sans pour autant pouvoir récupérer l'information ainsi perdue. Par exemple, perdre les métadonnées techniques ne conduira pas à perdre le lient entre les objets binaires et l'unité d'archives, permettant ainsi de conserver leur description. Un travail d'analyse permettra de reconstituer une partie des informations manquantes. Il en est de même pour les autres parties.
Exemple de l'entrée, du stockage, du cycle de vie et de l'accès
Je vais décrire rapidement le processus d'entrée en me focalisant sur la partie stockage, en partant du SIP de départ pour arriver jusqu'au découpage en AIPs, puis en indiquant la logique d'usage pour l'accès et les diverses opérations durant la vie des archives.SIP ou le début du processus d'entrée
Le SIP est celui défini dans le modèle SEDA, c'est à dire un ensemble (ZIP ou TAR) contenant tous les objets binaires et un fichier SEDA (au format XML) qui contient toutes les métadonnées (techniques, de gestion et de description, ainsi que la représentation hiérarchique).
Prenons par exemple comme source un répertoire contenant les métadonnées, l'organisation sous forme de sous-dossiers et les fichiers associés. La première étape est de produire le manifeste SEDA puis l'ensemble (ZIP ou TAR) qui contient alors tous les éléments (voir la Figure 1).
Prenons par exemple comme source un répertoire contenant les métadonnées, l'organisation sous forme de sous-dossiers et les fichiers associés. La première étape est de produire le manifeste SEDA puis l'ensemble (ZIP ou TAR) qui contient alors tous les éléments (voir la Figure 1).
 |
| Figure 1. Depuis un dossier source jusqu'à sa représentation SEDA équivalente. |
Le SEDA suit la logique de Isad(G) et de l'EAD :
- l'ArchiveUnit (Unit) représente soit un simple "dossier" (folder) ou un "fichier" (file), avec les métadonnées de description et de gestion ainsi que la structure hiérarchique ;
- le DataObject (Object) représente un objet binaire ou un objet physique (document papier par exemple),avec ses métadonnées techniques ;
- le DataObjectGroup (ObjectGroup), qui n'est pas représenté sur l'image pour des raisons de simplification, représente un ensemble d'objets (binaires ou physiques), chacun étant une version du même objet d'archives mais dans différents formats et cas d'usages (original papier, original numérique au format LibreOffice, version de diffusion en PDF, …).
Cette représentation en groupe d'objets par opposition aux objets unitaires est là aussi compatible avec les auteurs de l'OAIS [5] :
“Note that the unitary or atomistic nature of the object associated with an AIU is conceptual: in practice, the object could exist as multiple physical or digital parts.”
AIP ou la finalisation du processus d'entrée côté stockage
Une fois que le SIP est validé lors de l'opération d'entrée, il est alors décomposé et stocké sous la forme de simples AIU comme présenté dans la Figure 2. Toutes les parties sont stockées sur les supports de stockage, tandis que certaines sont également stockées en base de données afin d'être requêtables (les métadonnées et les journaux).
 |
| Figure 2. Représentation interne du stockage d'un AIP. |
Chaque Unit, ObjectGroup, Binary Object et Logbook (journaux) est stocké indépendamment, avec un identifiant unique. Ces identifiants servent à relier toutes les parties entre elles (de manière redondante pour être "fault tolerant"), ceci afin de préserver la vision globale d'un AIP selon la conception de l'OAIS.
Il est proposé d'étendre la conception d'un AIP selon l'OAIS au cas d'un Unit ne disposant d'aucun Object (binaire ou physique) : il contient les liens (identifiants uniques) vers les Units parents, et permet ainsi de conserver la représentation hiérarchique (arborescente) du plan de classement de manière indépendante. Cette extension permet notamment de faciliter les multiples plans de classement pour un Unit donné et ainsi de favoriser le partage d'une même information entre différents contextes (cf article iPRES 2013).
Il est proposé d'étendre la conception d'un AIP selon l'OAIS au cas d'un Unit ne disposant d'aucun Object (binaire ou physique) : il contient les liens (identifiants uniques) vers les Units parents, et permet ainsi de conserver la représentation hiérarchique (arborescente) du plan de classement de manière indépendante. Cette extension permet notamment de faciliter les multiples plans de classement pour un Unit donné et ainsi de favoriser le partage d'une même information entre différents contextes (cf article iPRES 2013).
La Figure 3 présente une comparaison graphique de la représentation selon l'OAIS d'un AIP et celle qui est proposé ici. L'AIP conceptuel de l'OAIS se retrouve éclaté en différents sous-AIPs, un pour les métadonnées de description et de gestion, un pour les métadonnées techniques, un pour le journal du cycle de vie du Unit et un pour le journal du cycle de vie de l'ObjectGroup, et enfin plusieurs Binary Objects, un pour chaque version/usage de l'ObjectGroup.
 |
| Figure 3. Comparaison entre un AIP OAIS et l'implémentation de l'AIP dans Vitam. |
En même temps que l'écriture sécurisée sur le stockage, une représentation en base de données est également créée afin de permettre les requêtes sur n'importe quelles parties (voir [4]), comme illustrée dans la Figure 4. Cette représentation est celle visible par les utilisateurs finaux (archivistes ou agents administratifs). Elle permet d'avoir plusieurs plans de classement simultanément, par exemple un pour la vision métier, très proche du modèle de gestion de la donnée (records management) utilisé par le métier, et un pour la vision archivistique qui doit survivre à la vision strictement utilitaire du métier jusqu'à l'archivage définitif.
Nous ne montrons pas avec détail les multiples plans de classement dans cette figure pour des raisons de simplification, mais celle-ci a déjà été présentée dans l'article iPRES 2013.
Nous ne montrons pas avec détail les multiples plans de classement dans cette figure pour des raisons de simplification, mais celle-ci a déjà été présentée dans l'article iPRES 2013.
 |
| Figure 4. Représentation d'un AIP dans Vitam en base indexée. |
Bien sûr, afin d'assurer la sécurité du stockage, de multiples copies sont réalisées sur des "offres de stockages" différentes. Vitam, en fonction de la configuration lors de son installation, peut ainsi gérer des écritures simultanées sur 3 offres de stockages :
- 2 offres de stockage dites "chaudes" (basées sur des disques) pour assurer la rapidité des accès et des contrôles,
- 1 offre de stockage dite "froide" (basée sur des bandes) pour assurer la disponibilité et la sécurité contre les sinistres et les cyber-attaques.
Ces offres de stockages sont à considérer comme des offres "WORM" logiques (sans réécriture).
Pour le support sur bandes, la logique objet est globalement la même, exceptée qu'il y aura une unité de stockage intermédiaire (une enveloppe au format TAR) pour stocker les éléments sur une bande, selon le même algorithme que les logiciels de sauvegarde, tout en choisissant le mode de "Tape as a service" (similaire au "storage as a service") en utilisant le support LTFS [11] qui est la cible actuelle du support objet sur les plateformes Cloud.
Bien sûr, je le rappelle, lorsque je parle de "Cloud storage" (stockage sur le nuage), je ne parle pas de placer les archives dans le "Cloud" standard (Google, Amazon ou autres), mais bien dans un "Cloud privé", détenu, hébergé et géré par des agences de l'Etat Français pour des raisons de la protection du secret et de la sécurité nationale.
Finalement, ces offres de stockage seront réalisées dans le respect de la norme NF Z42-020 [12] qui définie les fonctionnalités attendues d'un tel composant, comme la disponibilité, la traçabilité et l'intégrité.
Stockage en nuage / Cloud Storage
Comme l'objectif est de stocker des milliards d'éléments (Units, ObjectGroups, Binary Objects, Logbooks) et de pouvoir y accéder de manière unitaire, tandis que la hiérarchie est portée par les Units et non par le stockage, il s'agit donc d'avoir un "stockage orienté objet", nommé "Content Addressable Storage" (CAS) aujourd'hui largement connu. Ce modèle de stockage est notamment très utilisé dans le domaine de l'hébergement Cloud pour son approche "storage as a service". Par exemple, il est envisagé d'utiliser le stockage objet natif de OpenStack (SWIFT [10]) ou une implémentation équivalente (par exemple avec CEPH [18]) pour le stockage "chaud".Pour le support sur bandes, la logique objet est globalement la même, exceptée qu'il y aura une unité de stockage intermédiaire (une enveloppe au format TAR) pour stocker les éléments sur une bande, selon le même algorithme que les logiciels de sauvegarde, tout en choisissant le mode de "Tape as a service" (similaire au "storage as a service") en utilisant le support LTFS [11] qui est la cible actuelle du support objet sur les plateformes Cloud.
Bien sûr, je le rappelle, lorsque je parle de "Cloud storage" (stockage sur le nuage), je ne parle pas de placer les archives dans le "Cloud" standard (Google, Amazon ou autres), mais bien dans un "Cloud privé", détenu, hébergé et géré par des agences de l'Etat Français pour des raisons de la protection du secret et de la sécurité nationale.
Finalement, ces offres de stockage seront réalisées dans le respect de la norme NF Z42-020 [12] qui définie les fonctionnalités attendues d'un tel composant, comme la disponibilité, la traçabilité et l'intégrité.
Les opérations du cycle de vie des AIP et valeur probante
Préservation de la lisibilité
Une fois les Binary AIP stockés (Binary Objects et Technical Metadata AIP), Vitam prend à sa charge les nécessaires transformations de formats tout au long de la vie des archives pour maintenir leurs lisibilités. Comme ces conditions de lisibilité sont des événements qui peuvent être différents considérant les usages différents, cette opération ne se concentre que le format fautif.
Ainsi par exemple, si on considère que nous avons un groupe d'objets où un de ses usages est le PDF/A-2 toujours valide, tandis qu'un autre de ses usages est un format Word 98 où son obsolescence a été décidée, seul le dernier format fera l'objet d'une transformation (par exemple en ODT 1.2). Ainsi, seul le Technical Metadata AIP (l'ObjectGroup) et le Binary Object concerné (Word 98) seront téléchargés et modifiés (le second pour son nouveau format ODT, le premier pour intégrer la nouvelle version ainsi produite).
Dans le cas où nous utiliserions un format de type AIC ou équivalent, il aurait fallu télécharger l'intégralité des versions (y compris le PDF/A-2) et réécrire l'intégralité de l'AIC. Comme l'objectif est de pouvoir gérer des milliards d'unités d'archives, ceci engendrerait un surcoût très important et potentiellement insupportable par une architecture avec un coût raisonnable du fait de la bande passante en lecture et en écriture bien plus importante qu'avec notre proposition. De plus, le risque lié à l'écriture serait propagé sur l'ensemble des versions de l'AIC, alors que dans notre version seuls les éléments impactés sont lus et/ou écrits.
Calculs en nuage / Cloud computing
Du fait des milliards d'unités d'archives, ces processus ne peuvent pas être manuels mais doivent être pilotés par des décisions humaines (décision d'obsolescence, tests des procédures de transformations de formats ainsi que la validation de la stratégie de préservation).
Vitam devra gérer plusieurs millions de processus de transformations d'unités d'archives. Comme ceci ne pourra pas être instantané ni parallèle du fait de la limitation de puissance disponible (dans un contexte raisonnable d'infrastructure mise en place), Vitam utilisera les technologies inspirées du "Cloud computing" (calcul en nuage), toujours en mode "cloud privé" bien sûr, pour gérer la distribution du travail sur les ressources disponibles, tout en assurant un statut complet et fiable durant toute l'exécution du processus, alors que celui-ci pourrait durer des semaines voire des mois (le temps nécessaire pour transformes des millions d'archives peut dépasser 6 mois selon la nature de celles-ci).
Une fois les Binary AIP stockés (Binary Objects et Technical Metadata AIP), Vitam prend à sa charge les nécessaires transformations de formats tout au long de la vie des archives pour maintenir leurs lisibilités. Comme ces conditions de lisibilité sont des événements qui peuvent être différents considérant les usages différents, cette opération ne se concentre que le format fautif.
Ainsi par exemple, si on considère que nous avons un groupe d'objets où un de ses usages est le PDF/A-2 toujours valide, tandis qu'un autre de ses usages est un format Word 98 où son obsolescence a été décidée, seul le dernier format fera l'objet d'une transformation (par exemple en ODT 1.2). Ainsi, seul le Technical Metadata AIP (l'ObjectGroup) et le Binary Object concerné (Word 98) seront téléchargés et modifiés (le second pour son nouveau format ODT, le premier pour intégrer la nouvelle version ainsi produite).
Dans le cas où nous utiliserions un format de type AIC ou équivalent, il aurait fallu télécharger l'intégralité des versions (y compris le PDF/A-2) et réécrire l'intégralité de l'AIC. Comme l'objectif est de pouvoir gérer des milliards d'unités d'archives, ceci engendrerait un surcoût très important et potentiellement insupportable par une architecture avec un coût raisonnable du fait de la bande passante en lecture et en écriture bien plus importante qu'avec notre proposition. De plus, le risque lié à l'écriture serait propagé sur l'ensemble des versions de l'AIC, alors que dans notre version seuls les éléments impactés sont lus et/ou écrits.
Calculs en nuage / Cloud computing
Du fait des milliards d'unités d'archives, ces processus ne peuvent pas être manuels mais doivent être pilotés par des décisions humaines (décision d'obsolescence, tests des procédures de transformations de formats ainsi que la validation de la stratégie de préservation).
Vitam devra gérer plusieurs millions de processus de transformations d'unités d'archives. Comme ceci ne pourra pas être instantané ni parallèle du fait de la limitation de puissance disponible (dans un contexte raisonnable d'infrastructure mise en place), Vitam utilisera les technologies inspirées du "Cloud computing" (calcul en nuage), toujours en mode "cloud privé" bien sûr, pour gérer la distribution du travail sur les ressources disponibles, tout en assurant un statut complet et fiable durant toute l'exécution du processus, alors que celui-ci pourrait durer des semaines voire des mois (le temps nécessaire pour transformes des millions d'archives peut dépasser 6 mois selon la nature de celles-ci).
Processus d'élimination
Le processus d'élimination est piloté par les métadonnées de gestion (fonction des lois et règles de protection des données, notamment la durée de rétention et le sort final à la fin de cette durée) positionnées sur les Units.
Une fois qu'une unité d'archives a sa date de validité dépassée, Vitam vérifiera alors récursivement sur ses enfants (dans l'arborescence du plan de classement) pour vérifier s'ils ont des exceptions. Une fois ces exceptions appliquées, seules les branches valides pour l'élimination sont proposées à l'archiviste en charge de la gestion.
Une fois la validation opérée par l'archiviste, la destruction est alors récursivement réalisée uniquement sur ces unités d'archives valides et validées.
Un ObjectGroup est détruit uniquement si tous les unités d'archives (Units) parentes sont elles-mêmes détruites.
Par exemple, dans la Figure 4 représentant une hiérarchie d'unités d'archives et les ObjectGroups associés :
- Si le Unit 5 est éliminable, et qu'aucuns des Units 6, 7 et 8 ne sont à conserver, alors tous les Units cités ainsi que les ObjectGroups associés 2, 3 et 4 seront détruits.
- Si le Unit 9 est éliminable comme le Unit 10 mais pas les Unit 2, 3 ou 4, alors seuls les Units 9 et 10 sont éliminés, et l'ObjectGroup 1 perd son lien avec le Unit 10 mais n'est pas détruit car le Unit 4 est conservé. Lorsque le Unit 4 sera éliminé à son tour, alors seulement l'ObjectGroup 1 pourra être éliminé lui-aussi.
La gestion de processus complexes sur des millions d'éléments est un schéma récurrent dans Vitam :
- l'audit d'archives peut prendre beaucoup de temps et doit être évalué à l'aune des milliards d'éléments à contrôler,
- la destruction d'archives peut prendre beaucoup de temps, en fonction du nombre d'archives à détruire (et en particulier si l'on prend en compte la destruction sur le support froid qui est par nature beaucoup plus lent que sur disques),
- la migration d'une offre de stockage obsolète vers une autre offre (il faut aussi prendre en compte l'obsolescence des supports),
- et bien d'autres opérations de longs termes.
Principes de distribution des calculs
Une des difficultés principales est la gestion de calculs potentiellement massivement parallèles mais avec un modèle de faible bande passante d'accès à la mémoire.
En effet, les calculs que nous avons à réaliser concernent possiblement des millions d'éléments (l'entrée d'objets binaires depuis un SIP) vus comme une seule opération (le SIP est globalement accepté ou rejeté). Mais comme ces calculs ne peuvent pas être strictement parallèles, notamment en raison des limites raisonnables liées à l'infrastructure qui pourrait être déployée, nous devons distribuer les nécessaires calculs sur un ensemble de serveurs de travail disponibles (il s'agit de la partie distribution, noté en anglais par le terme "map").
Cette distribution, contrairement à l'approche Hadoop [13], n'est pas que la distribution d'un calcul mais aussi celle des données (l'objet binaire sur lequel le calcul opère, comme par exemple le contrôle de l'empreinte ou du format). En effet, dans le modèle Hadoop, la donnée est déjà distribuée sur les serveurs, supposant que ceux-ci aient bien la capacité tous réunis de stocker l'ensemble de l'information. Hélas, si l'on considère un versement de 1 millions de fichiers chacun de 100 Ko en moyenne, avec 10 serveurs de travail, cela signifierait que chacun devrait pouvoir héberger simultanément 100 000 x 100 Ko = 10 To. Et si cela ne semble pas être impossible, alors si simultanément 100 transferts similaires opèrent, cela fait 1 Po sur chaque serveur, ce qui à ce jour reste peu réaliste. Il apparaît donc qu'il n'est pas raisonnable d'opter pour cette approche de distribution à l'avance de tous les fichiers, mais plutôt d'opter pour une distribution au fur et à mesure des fichiers, limitant ainsi la capacité à la taille d'un fichier ou de quelques un.
Comme le transfert de chaque fichier depuis l'espace de stockage central et global (un NAS ou assimilé) vers le serveur de travail a un coût important en raison de la latence et de la bande passante du réseau, ce modèle se rapproche donc de la théorie des calculs sur des architectures aux accès non uniformes à la mémoire (Non Uniform Memory Access, NUMA) où la mémoire locale d'un processeur est remplacée par le disque local d'un serveur de travail et la mémoire centrale du serveur (dont l'accès est plus coûteux que l'accès à la mémoire locale) par l'espace de stockage central et global de la plateforme. De nombreuses recherches ont opéré sur ce thème [14, 15, 16] où le modèle de calcul doit prendre en compte cette contrainte. Il s'agit donc d'adopter une distribution des calculs et des données en optimisant le déplacement de la donnée (le fichier) au mieux par rapport aux calculs à effectués.
Une fois la distribution de l'ensemble des calculs effectuée et terminée, tous les résultats sont alors assemblés afin de produire le résultat final (l'acceptation ou le rejet), ce que l'on nomme en anglais par le terme "reduce".
Les deux étapes reproduisent donc le modèle classique de "map/reduce" utilisé dans les calculs distribués en nuage. A chaque étape, plusieurs calculs peuvent être exécutées consécutivement pour un même fichier, limitant ainsi le nombre de transferts depuis la mémoire centrale. Chacun de ces calculs sont aussi bien des opérations quasi élémentaires (calcul d'empreinte, test d'existence sur le stockage ou en base) que des opérations plus complexes (analyse et transformation de formats). Leur organisation en un processus (workflow) permet de définir différents types d'opérations utiles pour l'archivage (l'entrée, l'audit, l'élimination, ...).
Ainsi l'approche est un mixte des "micro-services" comme dans Archivematica [17] mais suivant un modèle massivement parallèle puisant dans les principes de distribution des architectures NUMA.
La valeur probante d'un élément dans un SAE dépend de plusieurs critères :
Chaque fichier journalier est ainsi stocké à son tour sur les offres de stockage, tout comme les archives.
Une des difficultés principales est la gestion de calculs potentiellement massivement parallèles mais avec un modèle de faible bande passante d'accès à la mémoire.
En effet, les calculs que nous avons à réaliser concernent possiblement des millions d'éléments (l'entrée d'objets binaires depuis un SIP) vus comme une seule opération (le SIP est globalement accepté ou rejeté). Mais comme ces calculs ne peuvent pas être strictement parallèles, notamment en raison des limites raisonnables liées à l'infrastructure qui pourrait être déployée, nous devons distribuer les nécessaires calculs sur un ensemble de serveurs de travail disponibles (il s'agit de la partie distribution, noté en anglais par le terme "map").
Cette distribution, contrairement à l'approche Hadoop [13], n'est pas que la distribution d'un calcul mais aussi celle des données (l'objet binaire sur lequel le calcul opère, comme par exemple le contrôle de l'empreinte ou du format). En effet, dans le modèle Hadoop, la donnée est déjà distribuée sur les serveurs, supposant que ceux-ci aient bien la capacité tous réunis de stocker l'ensemble de l'information. Hélas, si l'on considère un versement de 1 millions de fichiers chacun de 100 Ko en moyenne, avec 10 serveurs de travail, cela signifierait que chacun devrait pouvoir héberger simultanément 100 000 x 100 Ko = 10 To. Et si cela ne semble pas être impossible, alors si simultanément 100 transferts similaires opèrent, cela fait 1 Po sur chaque serveur, ce qui à ce jour reste peu réaliste. Il apparaît donc qu'il n'est pas raisonnable d'opter pour cette approche de distribution à l'avance de tous les fichiers, mais plutôt d'opter pour une distribution au fur et à mesure des fichiers, limitant ainsi la capacité à la taille d'un fichier ou de quelques un.
Comme le transfert de chaque fichier depuis l'espace de stockage central et global (un NAS ou assimilé) vers le serveur de travail a un coût important en raison de la latence et de la bande passante du réseau, ce modèle se rapproche donc de la théorie des calculs sur des architectures aux accès non uniformes à la mémoire (Non Uniform Memory Access, NUMA) où la mémoire locale d'un processeur est remplacée par le disque local d'un serveur de travail et la mémoire centrale du serveur (dont l'accès est plus coûteux que l'accès à la mémoire locale) par l'espace de stockage central et global de la plateforme. De nombreuses recherches ont opéré sur ce thème [14, 15, 16] où le modèle de calcul doit prendre en compte cette contrainte. Il s'agit donc d'adopter une distribution des calculs et des données en optimisant le déplacement de la donnée (le fichier) au mieux par rapport aux calculs à effectués.
Une fois la distribution de l'ensemble des calculs effectuée et terminée, tous les résultats sont alors assemblés afin de produire le résultat final (l'acceptation ou le rejet), ce que l'on nomme en anglais par le terme "reduce".
Les deux étapes reproduisent donc le modèle classique de "map/reduce" utilisé dans les calculs distribués en nuage. A chaque étape, plusieurs calculs peuvent être exécutées consécutivement pour un même fichier, limitant ainsi le nombre de transferts depuis la mémoire centrale. Chacun de ces calculs sont aussi bien des opérations quasi élémentaires (calcul d'empreinte, test d'existence sur le stockage ou en base) que des opérations plus complexes (analyse et transformation de formats). Leur organisation en un processus (workflow) permet de définir différents types d'opérations utiles pour l'archivage (l'entrée, l'audit, l'élimination, ...).
Ainsi l'approche est un mixte des "micro-services" comme dans Archivematica [17] mais suivant un modèle massivement parallèle puisant dans les principes de distribution des architectures NUMA.
Journaux et valeur probante
L'objet n'est pas ici de présenter complètement le processus de maintient de la valeur probante au sein d'un SAE, mais de l'éclairer dans le cadre décrit ci-avant jusqu'ici.La valeur probante d'un élément dans un SAE dépend de plusieurs critères :
- La valeur d'origine des éléments transmis au SAE : sur ce point, le SAE ne peut pas fournir une valeur probante à un élément qui n'en possédait pas déjà une ;
- Chaque opération du SAE doit être tracée pour permettre un contrôle a posteriori du respect des obligations du SAE en termes de preuve. C'est le rôle des journaux du SAE (journaux du cycle de vie pour les Units et pour les ObjectGroups, mais aussi journal des opérations du SAE qui retrace toutes les opérations au niveau macroscopique qui se sont produites).
- Ainsi, lors d'une entrée, les journaux de cycle de vie des Unités d'archives et des objets numériques vont tracer toutes les opérations relatives à leur entrée et les contrôles associés. Ils vont aussi contenir les empreintes des éléments ainsi stockés.
- Le journal du SAE, quant à lui, va stocker les informations par grandes étapes du processus d'entrée (transfert du fichier, contrôle des empreintes, contrôles des formats, ... jusqu'à l'écriture sur les offres de stockage et en bases de données).
- Nous y ajoutons un journal des écritures :
- En plus que chaque offre de stockage est sensée conserver un journal des opérations pour elle-même, Vitam qui gère les accès en écritures vers ses offres conserve lui aussi un journal des écritures. Pour chaque écriture d'un élément, la liste des offres de stockage et les informations identifiant l'opération (identifiant, taille, empreinte) sont ainsi consignées dans ce journal.
- Chaque journal fait lui même usage d'un chaînage pour en assurer sa fiabilité et sa conformité. Plusieurs techniques existent pour mener à bien cette opération :
- Un chaînage fichier à fichier, chaque jour donnant lieu à un nouveau fichier : le fichier suivant contient l'empreinte du fichier précédent, produisant ainsi un chaînage un par un. L'inconvénient majeur de cette approche est son caractère difficile à contrôler car pour valider le 1000ème fichier (environ 3 ans), il faut relire les 1000 fichiers un par un, et les contrôler tous un par un.
- L'utilisation du principe du "blockchain" et en particulier de l'arbre de Merkle [20] qui permet de calculer sous une forme arborescente et itérative les empreintes des fichiers ainsi produit chaque jour (cf Figure 5) : les avantages sont multiples puisque l'on peut vérifier rapidement si un fichier est correct en validant a minima 3 empreintes (les deux fils dont celle du fichier concerné, puis le parent commun), mais aussi car on peut publier auprès de tiers ces arbres de Merkle, sans rendre public le contenu des fichiers et donc sans rompre la confidentialité nécessaire, mais tout en permettant à tout un chacun de vérifier itérativement que ces arbres sont cohérents.
 |
| Figure 5. Représentation simplifiée d'un arbre de Merkle |
- Le cas particulier des journaux de cycle de vie impose un chaînage événement par événement (ligne à ligne) ou par groupe d'événements (réalisés lors d'une étape sur un serveur de travail pour un élément), c'est à dire à l'intérieur du fichier lui-même (l'empreinte de la ligne ou du bloc précédent étant dans la ligne ou le bloc suivant). La validité de ces fichiers est assurée par le journal des écritures qui trace toutes les opérations d'écritures et donc celles des journaux de cycle de vie également.
Chaque fichier journalier est ainsi stocké à son tour sur les offres de stockage, tout comme les archives.
DIP ou le processus d'accès
Comme je l'ai écrit auparavant, l'accès peut être sur n'importe quelle partie d'une unité d'archives : une requête sur les métadonnées descriptives ou de gestion, sur les métadonnées techniques ou un accès à un objet binaire pour une version donnée ou au journal du cycle de vie de l'unité ou du groupe d'objets. En conséquence nos DIP peuvent avoir n'importe quelles parties (toutes ou une), en fonction de la requête exprimée.
Comme dans l'OAIS, le DIP ne contient pas nécessairement exactement les mêmes informations que celles de l'AIP, ni n'est obligé d'être de la même finesse : le DIP peur être une collection ou un seul élément, tandis que l'AIP peut être lui-même un AIU ou un AIC.
Comme dans l'OAIS, le DIP ne contient pas nécessairement exactement les mêmes informations que celles de l'AIP, ni n'est obligé d'être de la même finesse : le DIP peur être une collection ou un seul élément, tandis que l'AIP peut être lui-même un AIU ou un AIC.
Par exemple, il est possible de demander : "Je cherche une unité d'archive qui contienne cette information (la partie where de la requête), mais dont au moins un objet binaire existe avec un format vignette". Ou encore, "mais retourne moi les objets binaires correspondants au format vignette.
Bien sûr, en cas de réversibilité, le DIP produit devra être "complet", c'est-à-dire contenant l'ensemble des informations disponibles pour les unités d'archives concernées et dans un format SEDA.
Dans toutes les situations, les droits d'accès sont calculés en utilisant les métadonnées de gestion, sur la base d'un calcul en modèle hiérarchique (les arbres de Units), afin de vérifier la validité de la requête vis à vis du demandeur.
Perspectives
Si les solutions techniques de Cloud computing et Cloud storage offrent des possibilités intéressantes pour l'archivage électronique, en tant que telles, elles ne constituent certainement pas à elles toutes seules la solution. Elles n'offrent que des services, pour permettre la gestion de milliards d'éléments dans la durée, en prenant en compte les durées longues de traitement et la gestion de ceux-ci.
D'autres technologies peuvent devenir un point d'appui à ce travail titanesque qui s'ouvre devant nous, du fait de l'accroissement exponentiel des données numériques et de leur archivage :
D'autres technologies peuvent devenir un point d'appui à ce travail titanesque qui s'ouvre devant nous, du fait de l'accroissement exponentiel des données numériques et de leur archivage :
- les outils d'analyses des images, des vidéo et des sons pour en extraire les informations sémantiques de premier niveau (texte brut notamment) de manière automatisée,
- les outils sémantiques, quand ceux-ci sauront travailler sur des milliards de documents et dans des contextes très variées et surtout évolutifs, que ce soit pour permettre un meilleur classement ou pour faciliter la recherche de documents,
- les outils d'analyses statistiques appliquées à la masse de document pour permettre de nouvelles approches de l'étude des archives (où l'échantillonnage ne serait plus la règle car cela priverait de sources d'informations riches pour de futurs usages inconnus à ce jour),
- les outils d'analyses et de transformations de formats, ce qui est une vraie gageure tant le nombre de formats et leur obsolescence rapide ne fait que croître,
- les outils d'abstraction des données, notamment dans le cadre de l'archivage d'applications ou plus exactement de leurs bases de données (archiver un code source peut être utile, mais l'archivage d'une application n'est pas réaliste tant la technologie sous-jacente nécessaire devient trop vite obsolète).
Il es peu probable que nous ayons le temps d'ici la fin du projet (2019) pour couvrir tous ces besoins, mais sans doute pourront nous au moins faire quelques expérimentations sur ces sujets.
REMERCIEMENTS
Je remercie tout particulièrement toute l'équipe Vitam ainsi que les équipes des administrations associées qui m'ont aidé à préparer cet article présentant les concepts et les modèles de données de Vitam pour les paquets d'archives.
Cet article n'est pas une fin, mais une pierre dans l'édifice, en espérant qu'il soit utile à beaucoup.
Cet article n'est pas une fin, mais une pierre dans l'édifice, en espérant qu'il soit utile à beaucoup.
REFERENCES
- ISO 14-721:2003, OAIS, Reference model for an Open Archival Information System.
- ISO 16 175 (ICA-Req), CONSEIL INTERNATIONAL DES ARCHIVES, Principes et exigences fonctionnelles pour l'archivage dans un environnement électronique, Paris, 2008.
- DLM Forum foundation, European standard MoReq, Model Requirements for the Management of Electronic Records, 2011, available online : http://moreq2010.eu/pdf/moreq2010_vol1_v1_1_en.pdf
- Frédéric Brégier, Thomas Van de Walle, Marie Laperdrix, Frédéric Deguilhen, Lourdes Fuentes-Hashimoto, Nathalie Morin and Edouard Vasseur. 2013. A new data model for digital preservation and digital archiving for the French Administration: VITAM model on NoSQL technologies. In IPRES 2013 : proceedings of the 10th International Conference on Preservation of Digital Objects ; ed. José Borbinha, Michael Nelson, Steve Knight. - Recurso em linha. - Lisboa : Biblioteca Nacional de Portugal, 2013, ISBN 978-972-565-493-4
- Brian Lavoie. The Open Archival Information System (OAIS), Reference Model: Introductory Guide (2nd Edition), OCLC Research, DPC Technology Watch Report 14-02 October 2014, ISSN: 2048-7916, DOI: http://dx.doi.org/10.7207/twr14-02
- D4.3 E-ARK AIP pilot specification, February 2016, E-ARK Project, available online: http://www.eark-project.com/resources/project-deliverables/53-d43earkaipspec-1
- Standard d’Echange de Données pour l’Archivage : SEDA, V2.0, décembre 2015, Service Interministériel des Archives de France, available online: http://www.archivesdefrance.culture.gouv.fr/seda/ and its related AFNOR NF Z44-022 MEDONA - Modélisation des échanges de données pour l'archivage, Janvier 2014
- Référentiel Général d’Interopérabilité, V1.0, Mai 2009, DGME, available online: http://references.modernisation.gouv.fr/interoperabilite
- AFNOR NF Z42-013, Archivage électronique - Spécifications relatives à la conception et à l'exploitation de systèmes informatiques en vue d'assurer la conservation et l'intégrité des documents stockés dans ces systèmes, March 2009 (also in English as ISO 14641-1)
- SWIFT, OpenStack Object Storage, available online: http://swift.openstack.org/
- Linear Tape File System (LTFS), V2.2, December 2013, SNIA, available online: http://www.snia.org/ltfs
- AFNOR NF Z42-020, Spécifications fonctionnelles d'un composant Coffre-Fort Numérique destiné à la conservation d'informations numériques dans des conditions de nature à en garantir leur intégrité dans le temps -. July 2012
- Apache project, Hadoop, available online: http://hadoop.apache.org/
- Nakul Manchanda; Karan Anand (2010-05-04). Non-Uniform Memory Access (NUMA) (PDF). New York University. Available online: http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf
- Laercio L. Pilla, Christiane Pousa Ribeiro, Daniel Cordeiro, Abhinav Bhatele, Philippe O. A. Navaux, Jean-François Mehaut, Laxmikant V. Kale. Improving Parallel System Performance with a NUMA-aware Load Balancer. [Research Report] 2011.(Institute of Informatics – Federal University of Rio Grande do Sul – Porto Alegre, Brazil), (LIG Laboratory – INRIA – Grenoble University – Grenoble, France), (Department of Computer Science – University of Illinois at Urbana-Champaign – Urbana, IL, USA). HAL Id : hal-00788813, version 1, available online: http://charm.cs.illinois.edu/newPapers/11-28/paper.pdf
- B. Chapman, F. Bregier, A. Patil and A. Prabhakar. Achieving performance under OpenMP on ccNUMA and software distributed shared memory systems. June 2002 in Volume 14 Concurrency and Computation: Practice and Experience (pages 713–739). DOI: 10.1002/cpe.646
- Archivematica Micro-services, available online: https://wiki.archivematica.org/Micro-services
- SWIFT implementation using CEPH: http://docs.ceph.com/docs/master/radosgw/swift/
- SPAR implementation at BNF: http://www.bnf.fr/fr/professionnels/spar_systeme_preservation_numerique/a.spar_presentation.html
- Arbre de Merkle, définition dans Wikipedia : https://fr.wikipedia.org/wiki/Arbre_de_Merkle
Aucun commentaire:
Enregistrer un commentaire