samedi 27 juillet 2013

SAE, OAIS, les 3 âges : vus par un informaticien

Suites aux remarques de Janus et Anouk, je dois essayer de préciser le fond de ma pensée sur la notion des 3 âges pour une archive, mais du coup aussi ce qu'est pour moi un SAE dans la lignée de l'OAIS. Je précise tout de suite (au cas où ce ne serait pas clair) : 
  1. Je ne suis pas archiviste mais informaticien.
  2. Mais je pense pouvoir comprendre ces notions selon une approche pragmatique (d'usages et non de théorie), mais du coup, peut-être biaisée.
  3. Je n'ai pas tout lu, loin s'en faut (et notamment, honte à moi, M Perotin) : je peux donc évidemment être dans l'erreur.
  4. C'est tout l'intérêt des échanges : affiner sa connaissance pour être de moins en moins dans l'erreur, et de moins en moins seul.
Je vous invite à lire les commentaires de l'article précédent et les pointeurs associés :
Je comprends que ma présentation des 3 âges (selon un informaticien, pas un archiviste) est quelque peu déroutante pour vous (archivistes). Je ne pense pas que nous disions quelque chose de fondamentalement différent, modulo quelques éléments de langage.



"Mes" définitions



Tout d'abord je redéfinirais quelques termes, car je m’aperçois que j'ai une définition qui ne colle pas avec tout le monde...
  • archive : document, train de bits, données issues de base de données, ..., bref ce que l'on peut aussi nommé "l'archive"
  • métadonnées : pour moi de trois types
    • Archivistique : les métadonnées décrivant les aspects "métiers" des archivistes comme la durée d'utilité administrative (et légale), sort final, propriétaire, ...
    • Descriptif : toutes métadonnées décrivant l'archive (dont l'instrument de recherche, des mots clefs, un plan de classement (ou plusieurs), un contexte, ...)
    • Technique : les métadonnées décrivant techniquement l'archive (son format, sa taille, son empreinte, son lieu de stockage, ...)
    • Ceci simplifie le schéma standard OAIS :

OAIS - 2009
  • coffre-fort électronique : (hérité du concept de la Z42-020) un espace de stockage sécurisé permettant de tracer, de garantir, de conserver en l'état un objet numérique (archive et métadonnées) et de restituer ces objets numériques ; cette brique n'est pas un SAE ni un PAE, ce n'est qu'une brique sous-jacente indispensable
  • PAE : plateforme d'archivage électronique, une plateforme "physique" hébergeant les fonctions d'un SAE
  • SAE : système ou mieux service (au sens service du "As A Service" des IaaS, PaaS, DaaS, SaaS, ...) d'archivage électronique (hérité de l'OAIS et de la Z42-013), solution s'appuyant sur une plateforme (PAE) dont un Coffres fort électronique (mais pas que), gérant les archives au sens conservation et pérennisation, mais aussi les métadonnées qui vont avec (que l'on ne peut disjoindre des archives, sinon il y a un risque de perte d'informations).
  • SIA : système d'information archivistique, solution frontale à un SAE pour gérer les aspects métiers de l'archivage (contrats, élimination, versements, ...) mais aussi le cas échéant les utilisateurs et les droits d'accès (authentification, habilitation).
  • Application métier : une application pouvant produire des données (producteur de la donnée, au sens informatique, pas métier), pouvant verser des données (pour elle-même ou pour le compte d'autrui), pouvant accéder à des données (consultation des archives ET des métadonnées). D'une certaine façon, le SIA est une application métier particulière pour un SAE (elle a plus de droits et de fonctionnalités ouvertes).
  • GEIDE (ou équivalent) : une application métier particulière qui gère un workflow de validation et qui est un service versant très pertinent pour un SAE et également un excellent candidat comme client en accès d’un SAE (pour ce qu’il a versé, voire plus selon les droits). Une GEIDE ne gère pas l'obsolescence des formats, même si parfois elle gère un coffre-fort électronique. Si les fonctionnalités de pérennisation sont intégrées, il s'agit alors d'un SAE étendu et non plus d'une GEIDE. Mais il est probable que la conception modulaire de l'application conduira à considérer un module pur GEIDE et un autre pur SAE. C'est justement sur cette interconnexion que je place le SAE auquel je pense (et donc pas en lieu et place d'une GEIDE).
  • Entrepôt de données : (ou data warehouse) est une base de données regroupant une partie ou l'ensemble des données fonctionnelles d'une entreprise ; à ce titre, elle permet l'aide à la décision sur la base de données à l'unité (référentiel global) ou sur la base d'agrégats (Datamart) ; puisque son objet est l'accès unitaire à des données (une ligne d'une table) et non à une table dans son ensemble, ou encore de réaliser un calcul (un agrégat), cet entrepôt ne peut pas constituer en soit de l'archivage. Au mieux, il pourrait être un excellent client pour verser vers un SAE, grâce à sa connaissance des référentiels de l'entreprise et de la signification des données ainsi stockées. A noter qu'il n'y a pas de garantie particulière sur les données ainsi stockées puisque ce n'est pas l'objet d'un entrepôt de données de garantir l'inviolabilité de ses données. Ce n'est pas un "coffre-fort électronique de bases de données". Ceci dit, c'est une piste intéressante si on pouvait s'en inspirer...

Qu’est-ce qu’un SAE ?             

Sur la base de ces définitions, un SAE est un service qui est à la confluence des intérêts des métiers, des besoins historiques et légaux, tant sur le versement, la conservation, la pérennisation, la gestion de la donnée et les accès (bon vieux modèle OAIS, toujours d’actualité même si il est un peu incomplet ou imprécis selon moi).
Pour moi, faire une distinction entre un SAE intermédiaire (que souvent on appelle à tort un coffre-fort électronique) et un SAE définitif, sur un plan technique, n’a pas de sens. Techniquement, ils font la même chose. Par contre, je suis d’accord que sur le plan des responsabilités, il peut être nécessaire d’avoir deux instances différentes, mais pas toujours (il existe des entités qui ont la responsabilité mixte).

La vraie différence, autre que celle liée aux responsabilités, est qui et comment accède-t-on aux archives ?
L’intermédiaire est par définition encore fortement lié au métier (puisque la durée d’utilité administrative (DUA) court toujours), contrairement au définitif. Mais alors, quel est l’impact ?
Aucun, si ce n’est donner la capacité à une application métier frontale d’accéder nativement aux archives et aux métadonnées associées (en lecture) depuis un SAE. Ensuite, lorsque la DUA est dépassée, soit le sort final la destine à être détruite, soit celui-ci demande sa conservation : pourquoi la déplacer ? Il suffit alors de couper les liens (si nécessaire) depuis les applications métiers pour ces données à dates dépassées… Dit autrement, le référentiel des accès bouge, pas les données.

En très résumé, pour illustrer ces distinctions entre SAE, Coffre-fort et les applications métiers, voici un extrait de la documentation du projet français VITAM :

Modèle général du SAE VITAM (c) Projet VITAM 2012 MCC/MAE/MINDEF France
Il est fortement inspiré du modèle OAIS :
OAIS - 2009
Ce schéma illustre la position en mode « service » du SAE vis-à-vis des applications métiers frontales, de l’application de gestion des archives (SIA), tant pour le versement que pour les accès, ainsi que la position du coffre-fort numérique, brique inclue dans le SAE (mais potentiellement elle-aussi en mode service et possiblement externe).

Mon approche du SAE est celle d'un service rendu, pas d'une fin en soi, tourné résolument vers les clients et non sur lui-même. Je vois le SAE au sein de la société qui vit et évolue autour de lui. Mais il a quelques particularités qui lui impose de se "préserver" :
  • Les données conservées ont une forte valeur et doivent être garantie (conformité, traçabilité, ...), ce qui impose des contraintes de sécurité très élevées.
  • Les accès sont réglementés, contrôlés, mais ils doivent être facilités pour être utiles.
Du coup, le module "Accès" doit être à la fois "ouvert" et "sécurisé, ce qui peut paraître contradictoire. Pour y arriver, le mode "service" (inspiré des "XaaS", quelque chose As A Service) permet de découpler les aspects présentations, contextes, modalités de transport vers le client final, puisque cet aspect sera pris en charge par l'application métier frontale.
En effet, les clients finaux peuvent évoluer très (trop) vite, bien plus vite que ne peut le faire une seule application (le SAE). Du coup, ce sont les applications frontales qui évolueront vis-à-vis des clients finaux, soit par elles-même, soit par remplacement ou ajout d'applications frontales. 
Seul le format de fichier peut du coup avoir une obligation d'adaptation pour être compatible avec le client final. Pour cela, 2 options sont possibles :
  1. Le format est admis par le SAE comme un format de "visualisation" (potentiellement différent du format de pérennisation). Le SAE peut donc proposer ce format (sur la base d'un contrat de service entre l'application frontale et le SAE et de paramètres lors de l'appel de service).
  2. Le format n'est pas admis par le SAE (pas encore, ou ne le sera jamais), la transformation de format sera alors à la charge de l'application frontale avant transmission au client final. Néanmoins, ce cas de figure est peu probable puisque au même titre que le SAE doit gérer les formats pérennes, il doit aussi gérer les formats "visualisables" (potentiellement dégradés en qualité) par ses partenaires (applications frontales).
Les fonctions à couvrir par un SAE sont complexes (maintient de la lisibilité d'un document dans le temps, métadonnées associées et requêtables, les droits d'accès, conservation sécurisée et garantie, ...), et il est déraisonnable de demander à toutes les applications métiers de devoir gérer cela elle-même, alors qu'un SAE peut le faire pour elle...

Et l'intermédiaire n'échappe pas à cette règle.

L'intermédiaire a aussi besoin d'un SAE

  • la lisibilité (pérennisation) : si les durées sont très courtes (moins de 3 ans par exemple), le sujet du format des fichiers n'est pas un problème ; mais si cette durée excède cette période (ou un peu plus, selon les cas), alors la pérennisation est un sujet car :
    • Au delà de 10 ans, un format devient illisible en raison de l'obsolescence des logiciels associés
    • Une application créée, après un certain temps de développement, s'appuie sur un format de fichier d'année daté d'avant le début de sa conception. Si on additionne le temps de vie de l'application avec la DUAL associée aux documents produits dans ce format, on peut aboutir à une obligation de gérer l'obsolescence d'un format.
Obsolescence d'un format même en archivage intermédiaire (c) Projet VITAM 2012 MCC/MAE/MINDEF France
    • L'obsolescence peut être soit prise en compte au niveau de l'application (elle change de format), soit au niveau d'un SAE qui stockerait ses archives.
  • les droits d'accès : si les données sont mutualisables (plusieurs applications pourraient nécessiter l'accès à ces archives), une application seule ne peut pas le gérer, sauf à intégrer à son tour une offre de service d'accès, alors que le SAE peut lui offrir nativement. En effet, le SAE peut gérer de multiples attributaires (un attributaire est différent de la notion de "propriétaire").
Exemple de gestion des droits d'accès mutualisés pour une même archive (c) Projet VITAM 2012 MCC/MAE/MINDEF France
  • les métadonnées conservées et requêtables : pour permettre la mutualisation des accès (plusieurs attributaires), il est indispensable que les métadonnées (descriptives essentiellement) soient partageables et requêtables. Si plusieurs applications conservent les métadonnées, il est à craindre que celles-ci seront mises à jour par les applications en leur sein, mais jamais dans le SAE, ce qui constituera une perte d'information (ceci est aussi valable avec une seule application). De plus, le service de requête de métadonnées n'est pas un service simple à implémenter : demander à toutes les applications de le gérer est dispendieux. La mutualisation répond donc à la fois à la cohérence des métadonnées (et leur qualité) et à la réduction des coûts.
  • la conservation sécurisée : verser dans un coffre-fort électronique ne suffit pas puisqu'un coffre-fort ne gère pas l'obsolescence, il ne gère pas les métadonnées, ni en général les droits multiples d'accès à une archive. Demander à une application métier de verser dans un coffre-fort électronique déporte toute la complexité de la gestion de l'obsolescence, du partage de l'information et des métadonnées dans celle-ci. A nouveau, l'offre d'un SAE vient faciliter la mise en oeuvre pour une application, tout en réduisant les coûts.
Cette facilité donner aux applications métiers  ne peut qu'encourager les responsables d'application à mieux considérer l'intérêt des archives pour eux-mêmes et leurs partenaires (pendant la DUAL).

Et cette approche service vient expliquer les nuances d'interprétation des 3 âges d'une donnée.

Les 3 âges et le SAE


Si je reprends quelques éléments de Lourdes, ultra résumé :
"Il propose alors qu’il y ait une véritable gestion à chaque âge, il expose ainsi une théorie sur le cycle de vie des archives. Il identifie à chaque étape, de façon très méthodique, un certain nombre de critères à prendre en compte:
- une durée d’utilité
- un emplacement (où se trouvent les archives physiquement)
- un utilisateur
- un responsable (de la gestion et de la conservation)
"
Je reformulerais légèrement les critères :
  • une utilité (qui implique une durée et pour qui) : potentiellement multiple
  • un emplacement : potentiellement multiple
  • un utilisateur : potentiellement multiple
  • un responsable (de la gestion et de la conservation) : potentiellement unique, y compris entre intermédiaire et définitif
Tout au long de ce qui va suivre, j'espère détailler un peu plus cette reformulation. Quelques rappels (ou précisions) :
  1. Pour moi, un SAE n'est ni définitif, ni intermédiaire. Son rôle est de conserver, de manière garantie et légale des données avec un (ou plusieurs) plan de classement ET de permettre l'accès à ces archives ET métadonnées. En clair, j'étends le périmètre du SAE tel que peut-être il est par trop souvent limité.
  2. Le rôle d'un SAE est de servir, d'être utile... On ne conserve pas pour la beauté du geste, mais bien parce que cela a une utilité (immédiate, intermédiaire ou long terme). Il faut donc prendre en compte ce besoin de rendre "utile" des métiers et les outils associés. Par trop souvent, les archives sont considérées comme "poussière" et je ne suis pas d'accord. En mettant le doigt sur l'intermédiaire, on se rend compte de l'intérêt de celles-ci (pour le commun des mortels), et ensuite on peut étendre l'intérêt au long terme (mais ensuite seulement, l'esprit humain se concentrant hélas sur l'immédiateté).
Du coup, dans mes trois âges :
  1. la production initiale : elle correspond à l'étape de création dans le schéma d'Anouk. Elle est inévitablement intimement liée au contexte de sa production (le pc, l'application métier, ...). Elle prend une valeur lorsqu'elle est validée. Cette validation peut intervenir lorsque celle-ci est versée dans un autre contexte (par exemple dans une GEIDE ou un data warehouse), ou lorsque celle-ci fait l'objet d'un gel lié au métier (clôture comptable par exemple). La validation au sein de la même application est elle-aussi possible mais le "versement" à un système d'archive n'interviendra probablement qu'après une des deux étapes ci-avant citées.
  2. une fois validée : elle est pour moi déjà une archive (au sens strict puisqu'elle ne bouge plus sur son fond). Qu'elle passe par une application intermédiaire (par exemple une GEIDE) ou qu'elle aille directement dans un SAE, ne change rien. Sur le fond, une GEIDE est un SAE mais avec des fonctions en moins (conservation, pérennisation), et d'autres en plus (workflow de validation, gestion des authentifications et habilitations). Du coup une coopération intense peut être menée entre un SAE et une GEIDE : la GEIDE gère l'amont (l'utilisateur, les habilitations, les workflows de validation, les plans de classement, la génération des requêtes, ...), le SAE gère l'aval (la conservation, la pérennisation, le classement stocké et le requêtage réel des métadonnées pour ce qui est conservé). Par contre, placer un coffre-fort électronique pour conserver le document pendant la DUAL me semble incorrect (sur la base de ma définition de ce qu'est un coffre-fort électronique). Il faut d'autres fonctionnalités (notamment de requêtage des métadonnées et de pérennisation).
  3. sa conservation : qu'elle soit de courte durée ou de longue durée (voire de très longue durée), le SAE peut répondre à l'évidence à une grande partie du besoin. Il ne peut par contre pas gérer l'intégration dans le métier (sous peine d'être non extensible, et donc inexploitable). Il faut donc qu'il accepte d'être au service d'autres applications (frontales) qui, elles, géreront les aspects métiers associés (création de nouvelles données ou actions associées).
 Voici en quelque sorte comment je vois les 3 âges :
Cycle de vie, Containers et mode d'accès aux données numériques (c) Projet VITAM 2012 MCC/MAE/MINDEF France
Du coup, si je remets en cause les 3 âges classiques, c'est parce que j'identifie trois cas d'accès différents :
  1. La création, intimement liée au contexte de la production des données : seul l'utilisateur (ou l'application autonome le cas échéant en cas d'auto-génération de données) accède à ses données
  2. La validation et le démarrage de la DUAL : toujours en lien avec le métier, cette fois l'accès peut être plus large que le seul utilisateur créateur. Cet accès se fait exclusivement au travers d'un contexte métier (applicatif). Pour autant, dès que la donnée est figée (validée), si son accès est toujours et impérativement réalisée au travers d'une application métier, cette donnée peut être stockée (si son usage le permet - pas des données unitaires d'une base de données par exemple -) dans un SAE, dit intermédiaire. Bien sûr, l'application peut elle-même conserver ses données pendant la DUAL sans l'obligation d'un SAE.
  3. Une vois la DUAL terminée, et si le sort final est la conservation : a priori le lien depuis le métier est coupé puisqu'il s'agit d'une conservation dite "historique", et donc d'un SAE dit définitif.
Ainsi, si l'application est capable de gérer elle-même la conservation et la qualité des données (pérennisation), l'usager accédera aux données directement stockées par l'application. Mais ce cas de figure sera selon moi de moins en moins fréquent compte-tenu de la spécificité des fonctionnalités nécessaires et du savoir faire (archiviste) associés. Les applications métiers (et les informaticiens associés) ont bien d'autres chats à fouetter (et pourtant j'aime les chats) que de s'ajouter une complexité aussi élevée que celle d'un SAE interne à l'application.
En conséquence je crois plus à une délégation de ce service à un SAE, accédé depuis l'application, tant que la DUAL court.

Une fois la DUAL terminée, et si le document a pour sort final la conservation, le document peut être alors toujours conservé dans un SAE et accédé depuis un SIA (ou toute autre application jouant ce rôle - comme Gal@tae ? -).

Quelques avantages à cette approche SAE comme un Service

Une fois placée ce décor, nous arrivons alors à plusieurs constatations :
  • Gestion des formats obsolètes : Si des applications métiers conservent en leur sein des archives sans les transmettre à un SAE, il y a un fort risque que lorsqu'elles devront être transmise, ces archives auront un format obsolète ingérable par le SAE (délai de 10 ans depuis la création du format en moyenne).
  • Qualités des Métadonnées : Si des applications métiers conservent les métadonnées des archives en plus des mêmes métadonnées transmises au SAE, il y a un fort risque que celles-ci finissent par diverger, car il est à prévoir que l'application métier autorisera leurs mises à jour en interne, sans en informer le SAE. Ceci conduira à une perte de qualité des métadonnées. C'est pourquoi il faut que les applications accèdent aux métadonnées directement depuis le SAE (pour ce qui relève de l'archive bien sûr) et propose via les interfaces de connexions les mises à jour que ses utilisateurs auront saisies directement dans le SAE (en fonction des droits associés bien sûr).
  • Mutualisation des données : Cette possibilité de stocker ET de requêter les métadonnées depuis une application frontale (en fonction de ses droits à en connaître) permet également de mutualiser l'information au sein du SI de l'entreprise. Elle est un facteur de mémoire (immédiate) de l'entreprise. Cette possibilité doit donc être vue comme un facilitateur important pour les applications métiers et répond aux besoins de multiples utilités d'une donnée pour plusieurs utilisateurs (applications métiers). 
  • Modèle OAIS : Le stockage et le requêtage des métadonnées peut sembler en contradiction avec le modèle OAIS, mais je ne le pense pas. La notion de query request et de DIP est suffisamment souple pour autoriser que ceux-ci puissent ne contenir que des métadonnées en résultats (et toutes formes de métadonnées). Ainsi la notion d'Information Object autorise un contenu nommé Representation Information s'assimilant aux 3 catégories de métadonnées (je cite : "The Information Object is composed of a Data Object that is either physical or digital, and the Representation Information that allows for the full interpretation of the data into meaningful information." OAIS-2009 chapitre 4.2.1.1 puis le chapitre 4.2.1.3.1 précisant les Structure Information et Semantic Information, mais également le chapitre 4.2.1.4.2 sur les Preservation Description Information). Et l'ensemble de ces données sont requêtables dans le modèle OAIS. De même, l'OAIS autorise plusieurs SAE à collaborer ensemble ou à avoir des utilisateurs fédérés, ce qui selon moi était une préfiguration de la mutualisation des SAE et de leur fonctionnement en mode "service" (chapitre 6.1).
  • Garantie de la mémoire immédiate de l'entreprise : Le fait de stocker et de pouvoir requêter les métadonnées offre également une autre garantie dans le temps : une application métier peut devenir elle-aussi obsolète (retrait de service, sinistre complet, ...). Plutôt que de demander de gérer l'historique depuis la nouvelle (si elle existe déjà), il est possible d'utiliser le SAE pour faciliter le passage de l'ancienne à la nouvelle pour l'historique pendant la DUAL. Si une nouvelle application n'existe pas, le SIA pourra le cas échéant remplacer ponctuellement l'application métier, mais avec de fait bien moins de connaissances métiers associées. Le SAE peut donc être vue comme une roue de secours en cas de défaillance d'une application métier.
  • Mutualisation des SAE : Si l'organisation le permet (que ce soit d'un point de vue légal, organisationnel ou autre), pourquoi avoir deux SAE, un intermédiaire et un définitif, quand un seul pourrait répondre aux deux besoins simultanément.
    • Le passage de l'intermédiaire au définitif (fin de la DUAL) se traduira alors simplement par exemple par une diminution des accès natifs depuis les applications métiers pour les archives concernées. Tout le reste, métadonnées et données archivées n'ont pas besoin d'être modifiées. 
    • J'inscris un bémol : les métadonnées ne sont pas sensées changer modulo le cas échéant la destruction de métadonnées purement utiles à l'intermédiaire et qui n'auraient donc aucune valeur à être conservées au-delà. Ceci dit, ce cas sera relativement rare, notamment car il peut être difficile de déterminer si une métadonnée n'a pas de valeur pour l'histoire.
    • Si l'organisation ne le permet pas, il y aura donc plusieurs emplacements pour une archive donnée selon son sort final. Je conseillerais dans ce cas que le versement se fasse dans le même pas de temps (soit en Y depuis l'application versante vers les 2 SAE, soit en série depuis l'application vers le SAE intermédiaire qui immédiatement enverrait une copie au SAE définitif).
    • Sur l'aspect organisationnel, le frein principal peut être la responsabilité associée à une archive (quant à sa gestion et sa conservation). En effet, si j'ai bien compris, la responsabilité qui est transférée lors d'un versement aux archives est la responsabilité liée à la conservation et à la gestion de ces archives, pas la responsabilité sur le fond de celles-ci. Il est clair que changer les rôles (service d'archives intermédiaires versus service d'archives définitives) peut poser de lourds problèmes (juridiques, étiques, ...).
  • Continuité de la mémoire de l'entreprise : Toujours si l'organisation le permet, une application métier pourrait continuer d'accéder aux archives et métadonnées bien au-delà de la DUAL. Il arrive fréquemment que des services d'archives définitifs restituent (original ou copie) des archives en leur possession au service producteur car un sujet d'actualité rend à nouveau utile cette donnée. Bien sûr, il y a plusieurs façons de gérer cela. Qu'un seul SAE soit utilisé (intermédiaire et définitif) ou que plusieurs SAE le soient, l'application métier pourrait toujours accédées aux données concernées. La question des droits d'accès pourrait être traitée de multiples façons : autoriser le producteur ad-vitam-aeternam à accéder à ses données, autoriser ponctuellement sur requête l'accès à ses données (modifications de métadonnées gérant les accès), ou comme aujourd'hui réaliser une demande via le SIA (application métier des archivistes) pour demander une restitution ou une copie de ses données.
Ainsi, je pense que si un SAE respecte son contrat de service (modularité, tout doit être interchangeable) et possède suffisamment d'ouverture vis-à-vis des applications métiers frontales et versantes, notamment via la mise en œuvre de services aisément implémentables dans d'autres applications (respectant des standards et normes en la matière), il peut représenter une énorme plus-value et en même temps une source de gains financiers et métiers pour les besoins d'une entité (publique ou privée), puisqu'il permettra ainsi d'assurer l'accès à la mémoire tant immédiate que de long terme, dans de bonnes conditions, depuis un grand nombre d'applications et avec une grande capacité d'adaptation aux évolutions organisationnelles, fonctionnelles et technologiques.

7 commentaires:

  1. Bonsoir,

    j'ai bien apprécié votre approche des 3 âges et l'opportunité de repenser ces étapes du cycle de vie des documents électroniques héritées des pratiques papier ou tout devait être sérialisé et planifié pour des contraintes d'espace dans les locaux.
    En tant qu'ingénieur informatique de formation et à l'origine orienté sur les projets de GED et de dématérialisation je me passionne maintenant dans les projets où je peux prendre en compte les enjeux d'une conservation dans le temps que ce soit pour des raisons de préservation de "preuves" ou simplement pour préserver une mémoire.

    Roger GIMENEZ (XDEMAT)

    RépondreSupprimer
  2. Avant de commencer, les définitions que tu avances me semblent acceptables pour un archiviste, ou pour le moins un cyber-archiviste, aux nuances près suivantes :

    Métadonnées, tes trois types sont grossièrement acceptables en première approche, mais pour le détail il me semble que définir de manière standardisée des jeux de métadonnées un peu plus fines (pas trop car alors les usagers deviennent fous) est nécessaire (voir nos échanges antérieurs à propos des « couches »).

    SAE as a service : Une idée à creuser, voir l’article
    Jan Askhoj, Shigeo Sugimoto, Mitsuharu Nagamori, (2011) "Preserving records in the cloud", Records Management Journal, vol. 21 Iss: 3, pp. 175 – 187
    que je commente ici : http://regarddejanus.wordpress.com/2013/03/01/conservation-des-documents-dans-le-nuage-cloud-et-oais/)

    Commentaire global : Je pense que nous nous entendrions mieux, pas seulement les archivistes et les informaticiens, mais aussi tous les utilisateurs potentiels, si nous tombions d’accord sur un réseau de fonctionnalités emboitées et/ou hiérarchiques, qui nous permettrait de placer les types d’applications et de bases de données aux bons endroits. Je n’en ai pour l’instant qu’une ébauche dans mes projets de « papiers ».

    Qu’est-ce qu’un SAE ?

    La seule différence que je fais entre un SAE intermédiaire et un SAE définitif est que ce dernier intègre des fonctionnalités de pérennisation que n’a pas le premier. Et, je me répète, cela a pour incidence des temps d’accès plus longs (cela dit le SAE as a service est une réponse possible). Pour le reste, ils sont bien techniquement équivalents.

    Quant à la responsabilité, elle renvoie aussi à un concept cher à l’archiviste qui est celui de l’évaluation. Je renvoie à ce propos au billet d’Anouck à propos du 5% archivable définitivement (http://present-hieretdemain.tumblr.com/post/48924358386/considerations-sur-les-fameux-5-de-documents-a). L’erreur est de le voir de manière statistique, alors qu’il est qualitatif. Ce qui, dans le monde du numérique, pourrait se traduire par : nous conserverons définitivement TOUTE CETTE base de données (pour d’évidentes raisons de simplicité techniques), mais nous ne conserverons PAS TOUTES LES bases de données (c’est simplificateur, mais cela donne une idée).

    Intellectuellement je te suis quand tu dis « couper les liens mais garder les données à la même place ». C’est un débat qui a déjà eu lieu chez nos collègues anglo-saxons entre le « custodial » (= j’ai la garde physique des données) et le « non-custodial » (= j’ai la responsabilité des données mais pas la garde physique). Jusqu’à présent l’expérience des archivistes a plutôt été décevante avec le non-custodial à cause des incompréhension avec les informaticiens, ce qui leur a fait préférer le custodial avec un transfert effectif des données (et là encore le souci de pérennisation à long terme qui dépasse l’horizon de l’informaticien lambda). Je rencontre cependant de plus en plus d’informaticien à la recherche de « data owners », ce qui ressemble bien à une forme de responsabilité métier.

    RépondreSupprimer
  3. SAE as a service

    Je crois que la principale nouveauté que tu introduis ici (et la cause de certaines de nos incompréhensions) est la notion qu’un système métier peut être un client d’un SAE de manière automatique aussi bien en mode ingest (ce qui est largement admis par les archivistes concernés, qui visent à une automatisation aussi poussée que possible de ce processus) mais également (et c’est la nouveauté) en mode « accès », et là les archivistes ont une réflexion de retard, due à notre manque d’expérience.
    Format de conservation versus de visualisation

    Je ne veux pas entrer dans le détail car c’est un monde ne soi. Cette question des formats selon les usages doit être développée. Par exemple, alors même que nous ne sommes pas dans une logique SAE, mon institution conserve les documents numérisés en 3 formats :
    - Tiff de numérisation initiale (= format d’archivage car pixelisation initiale)
    - Pdf (= format de visualisation car tous PC possèdent un reader ad-hoc)
    - Xml (= format de traitement pas des applications actuelle ou à venir)

    Intermédiaire et SAE

    Le tableau présenté est plus qu’intéressant. Il montre une nouvelle vision du cycle de vie du document et surtout de ses « sous-bassements ». L’organisation que tu propose est pertinente mais devrait être affinée, tu esquisse d’ailleurs le multiples problèmes que cela pose.

    Les 3 âges et le SAE

    J’agrée complètement à ta reformulation qui met l’accent sur la multiplicité sauf en ce qui concerne la responsabilité (quoique que l’on puisse en discuter).

    Sur la suite de ta formulation, d’accord sur « l’extension du domaine de la lutte » (pardon : du SAE) et d’insister sur le « rendre utile ».

    A propos des conséquences que tu en tir sur les trois âges :

    1. « Elle prend une conséquence quand elle est validée », malheureusement cette conséquence de la validation est loin d’être consciente dans beaucoup de processus administratifs actuels.
    2. Validation = archives, OK pour moi. Le reste de tes commentaires également.
    3. Conservation. La problématique que tu pose est vraie aussi en mode analogique. Certains processus sont éphémères (facture) et certains s’inscrivent dans le temps long (état-civil). La difficulté est d’identifier le moment où l’on bascule dans l’historique et surtout de documenter cette échéance de manière pertinente.

    Le tableau qui suit est super mais difficile à commenter de manière purement discursive, je retiens la suite qui est de lier les trois âges à la modalité d’accès.

    « seul l’utilisateur accède à ses données » est en contradictions avec les multiples utilisateurs que tu cites plus haut. De fait il y a dès cette étape des accès différenciés par des utilisateurs multiples selon leur droit d’accès.

    Sur les avantages du SAE as a service

    Qualité des métadonnées : je persiste et signe, cette qualité peut être garantie par les datawarehouses, qui sont directement utiles/utilisables par les utilisateurs opérationnels. Ce « monitoring » peut bien entendu être exploité par les SAE en « back.office ». C’est vari aussi pour la mutualisation des données.

    OAIS et requêtage : D’accord sur le principe, mais les outils restent à construire.

    Métadonnées et destruction
    Oui il est utile de conserver les métadonnées des objets numériques détruits. Pour justifier leur disparition au même titre que nous conservons les bordereaux de destructions des documents papiers (pour prouver qu’ils sont effectivement détruits et non pas que nous les cachons.

    Sur ta conclusion je suis convaincu que le SAE en tant que service n’est viable que si la contractualisation entre producteur(s) et archives est effectuée de la manière la plus précise possible. Ces contrats-types existent déjà à titre d’ébauches, ils doivent être de mieux élaborés et si possible normalisés.

    RépondreSupprimer
  4. Bonsoir Janus,

    Merci pour ces commentaires plus que complets !

    Je ferais juste deux remarques :
    1) Le SAE intermédiaire selon toi n'incorpore pas de fonctions de pérennisation ? Mais alors, comment peut-il gérer des documents qu'il doit conserver 20 ans, 30 ans, si ce n'est en appliquant, tout comme le définitif, les mêmes procédures de pérennisation.

    D'où que selon moi, la plupart des SAE intermédiaires (cf le schéma sur l'obsolescence des formats) devrait être en fait des SAE qui techniquement n'ont aucune différence avec un SAE définitif.

    2) OAIS et requêtage : comme je l'ai écrit, l'OAIS le prévoit (même si ce n'est pas assez explicite), et quant aux outils, nous avons réalisé des tests qui nous laissent penser que les solutions existent... Restent à les valider et les "renforcer"...

    Merci !

    RépondreSupprimer
    Réponses
    1. Bonjour
      la gouvernance de l'information n'apparait pas dans votre schéma ?
      est ce remis a plus tard faute de budget ou il y a t-il d'autres raisons ?
      SYLVAIN LAFFAY RSD

      Supprimer
    2. Bonjour,

      La gouvernance de l'information, si j'en crois sa définition, réside en différents items (je ne prétendrais pas être complet dans ma réponse) :
      a) les aspects organisationnels et politiques : ils sont indépendants de VITAM par essence
      b) une traduction de ces aspects en termes de classement, de plan de classement, de thesaurus, ... : la liberté sera totale auprès de l'entité versant (ou gérant) ses archives. Ce n'est pas le SAE qui fait cette partie, il doit par contre la stocker.
      c) stocker ces éléments pour pouvoir les utiliser après coup : le SAE y répond (requêtage notamment)

      Donc à moins que je n'ai pas compris votre question, je ne pense pas que nous ayons "oublié" ce point, il ne semble simplement ne pas faire partie du périmètre du SAE.

      Cependant, nous pourrions nous en approcher et traitant de ce que l'on appelle le "pré-versement", puisque cette partie doit mettre en oeuvre les plans de classement et les thesaurus associés. Néanmoins, si nous y participerons, ce sera certainement dans une mesure limitée car nous ne pouvons nous substituer au métier dont la connaissance de l'information est antérieure à celle du SAE, et donc sa gouvernance.

      J'espère avoir répondu à votre question...

      Supprimer
  5. D'accord avec toi, si l'on définit qu'un SAE intermédiaire gère au-delà de 10 ans de conservation, il y a de bonnes raisons qu'il ait les mêmes fonctionnalités qu'un SAE définitif. Mais cela me semble une bonne raison de définir des consensus sur les périodes que nous entendons gérer.

    Pour le développement de la réflexion de l'aspect accès d'OAIS via un requêtage le plus automatisé possible, je suis pour (et intrinséquement les archiviste devraient l'être aussi, car le but de la conservation reste la communication). Reste que le paramétrage ne semble pas des plus évident à ce jour. Mais si nous (tous) voulons chercher des solutions nous les trouverons,

    Bon été.

    RépondreSupprimer