mardi 9 juillet 2013

Complément sur les 4 notions de l'archivage : pré-versement et quelques précisions


Je me devais de compléter mon billet, notamment sur ce que nous nommons entre nous le pré-versement.
Je me suis en effet focalisé sur le SAE (Système d'Archivage Électronique) dans le billet précédent (puisque c'était l'objet), mais il est clair qu'avant le versement, un grand nombre d'actions sont à mener, et si possible même très en amont, de façon à ne pas recommencer à chaque versement des opérations fastidieuses, mais au contraire à laisser faire l'informatique là où elle peut être utile (quand c'est possible, bien sûr).
Cependant, l'informatique ne fera pas tout, je dirais même plus, l'informatique ne fera rien pour les archives si les archivistes ne s'en mêlent pas. Appelez ça si vous voulez la paresse des informaticiens...

Le rôle des archivistes

Selon moi, les archivistes doivent intégrer le SI et le métier en son cœur, notamment pour discuter, conseiller et suivre les chefs de projets (métiers et informaticiens) en charge des applications. Ainsi, les extractions ou sorties de ces applications seront alors correctement documentées (plan de classement), au bon format, et avec un mode opératoire pour les versements correct et maîtrisé.

Le rôle de l'archiviste selon moi est de sortir de son bureau et d'aller à la rencontre des métiers et des informaticiens, non pas en tant qu'expert en tout, mais expert en archivage, en gestion de la donnée, bref je sors le mot à la mode : des experts en gouvernance de l'information dans un objectif de pérennisation de celle-ci (ce qui est un peu plus que la simple gouvernance des données). 

Je sais que ce point est partagé par un grand nombre d'archivistes, et je ne peux que les soutenir en cette période où l'Open Data oublie un peu (beaucoup ?) leur profession, alors qu'ils ont des compétences que peu de gens ont (je suis le premier à dire que je ne les ai pas et que j'ai besoin de vous, archivistes), compétences qui seraient pour le moins utile. Maintenant, un effort de publicité, de communication, et ce n'est pas votre fort de faire votre propre publicité, est bien nécessaire. J'espère humblement, avec mes limites, y contribuer un peu...
Alors oui, je suis d'accord avec toi, Janus, la phase préalable est sensible, très sensible même.

Le pré-versement

Nous comptons aussi œuvrer pour cette partie, par la proposition d'outils pour aider. Mais avant d'aller plus loin, il faut aussi préciser qu'il y a deux types de candidats aux versements aux archives (que ce soit pour l'intermédiaire ou pour le définitif) :
  • les versements automatisables : ceux-la sont à prendre en charge par la MOA et la MOE après les conseils et le suivi de l'archiviste en amont (confer ci-avant), puis des contrôles ponctuels réalisés par ce dernier. Le métier (MOA) est nécessaire pour identifier ce qui est "utile", la législation associée. L'informatique (MOE) est nécessaire pour savoir comment et d'où extraire les informations ainsi déterminées. A partir de là, les métadonnées sont elles-aussi extraites directement, et les formats des données d'archives (format PDF/A par exemple) sont pris en compte bien en amont. Pour ce cas, il n'y a pas de "pré-versement" puisque tout est défini (sauf bien sûr la première fois, où il faut s'assurer de la qualité des opérations réalisées).
  • les versements manuels : ceux-ci sont à réaliser humainement (en général, pour le vrac, comme on dit). C'est pour ceux-ci que nous proposerons des outils (extraction de métadonnées, techniques et descriptives, transformation de format, ...). Là, il n'y a plus de MOE, voire plus de MOA (le ministre est parti par exemple en laissant un disque avec ses données). Les traitements sont par nature plus compliqués, mais certains peuvent néanmoins être automatisés (en amont donc, en "pré-versement").
 Les diverses étapes, proches de celles de versement, peuvent êtres les suivantes (l'ordre n'est pas forcément correct) : 
  • Sécurité des objets numériques fournis : antivirus, macro, ... 
  • Vérification des formats unitaires : identification du format, puis identification si ils doivent faire l'objet d'une transformation (par exemple Word vers PDF/A)
  • Extraction de métadonnées techniques (format, taille, empreinte et horodatage, ...)
  • Extraction de métadonnées descriptives (auteur, mots clefs, voire extraction du texte pour des besoins de recherches plein-texte, ...)
  • Création d'un (ou plusieurs) plan(s) de classement
  • Préparation des formats finaux de versement (SIP en OAIS), comprenant :
    • Document numérique original
    • Document numérique adapté au contrat de conservation
    • Document numérique original anonymisé et ses versions de conservation
    • Métadonnées descriptives, incluant le ou les plans de classement
    • Métadonnées archivistiques
    • Métadonnées techniques
Comme vous pouvez le constater, certaines opérations sont très similaires à celles illustrées dans le versement dans le SAE. C'est ainsi que nous comptons proposer des outils pour le pré-versement, en dupliquant nos outils pour des postes de taille plus réduite (les "PC" des archivistes).
Tout ne pourra pas être automatisé pour le vrac, mais plus les outils en feront, plus les archivistes pourront passer plus de temps sur la qualité puisque l'informatique fera la quantité.

La granularité des métadonnées

Pour les métadonnées, s'il est vrai que des métadonnées globales sont possibles, et même plus, souhaitables, liées au versement dans son ensemble, la grande différence avec le papier est que chaque document devra être documenté et donc posséder ses propres métadonnées. En effet, il n'est pas (selon moi) acceptable qu'un fichier soit simplement référencé comme faisant parti d'un ensemble sans que l'on sache en rien ce qu'il est, sur quoi il porte...
  • Dans le cas sériel, ces métadonnées seront sans doutes limitées unitairement (encore que, cela dépend grandement de ce qui est concerné, voire plus loin), mais elles viendront principalement des applications métiers d'origines.
  • Dans le cas du vrac, ces métadonnées seront indispensables et avec un niveau de détail très fin, car ce sera alors la seule façon de donner de la valeur à ces archives.
Un cas particulier, à mi-chemin du sériel et du vrac, est le cas des courriels ou messageries d'autorité. Les métadonnées sont à la fois globales (quelle autorité est concernée par exemple), mais aussi et surtout unitaire (chaque message est unique et doit pouvoir être retrouvé le plus facilement possible, ce qui impose de nombreuses métadonnées comme autant de critères de recherche). Une étude viendra prochainement sur ce sujet (mais sans doute pas publiée par moi ;-)

Quelques exemples de métadonnées que l'on peut extraire "facilement", si on a les outils pour :
  • l'auteur
  • la date de création
  • le format du fichier et les métadonnées techniques associées (nombre de pages, dimension d'une image, "significant properties" pour les courriels, ...)
  • dans le cas de documents, les mots clefs (voire le texte au format brut pour des recherches plein-texte)
Je ne dis pas que cela suffit bien sûr, mais c'est un début, et ceci peut être automatisé. Et plus tard, avec les outils de sémantisation, et avec l'aide d'une ontologie adaptée, il serait même possible de proposer un premier plan de classement automatiquement, une approximation de premier niveau, que l'archiviste pourra corriger à loisir (s'il en a le temps).

Comment gérer ces métadonnées ? Ce que nous proposons, qui n'est pas neuf, mais que nous avons prouvé comme faisable sur un plan informatique et surtout pratique et utile pour les métiers (y compris les archivistes), c'est une représentation des métadonnées sous la forme d'arbres. Chaque arbre est un plan de classement (confer MOREQ2010). La petite nouveauté est qu'une archive peut appartenir à plusieurs arbres, ce que l'on appelle alors un graphe dirigé sans cycle (DAG en anglais). Cette structure de données n'est pas neuve, mais elle correspond parfaitement au besoin. Et là encore, cela fera l'objet d'une publication prochaine.

Autres interrogations ou remarques

Je détaillerais une autre fois la partie qu'attend Janus sur la sécurité en trois couches : l'authentification/archivage/stockage. Mais ce que je peux ajouter, c'est une distinction pratique (pragmatique serait plus juste) : il s'agit d'un découpage des rôles et responsabilités par couche (utilisateurs, applications, SAE, stockage des archives).

J'aurais dû relire l'article (je corrige ce passage) pour ses acronymes : PRA = Plan de Reprise d'Activité effectivement. Il était indiqué avant, mais sans l'acronyme...

Durabilité des médias

C'est un point qui est à la fois simple et complexe, mais je vais essayer de préciser ce que j'entends par là.

Un média (support physique) peut être obsolète de deux façons :
  • Le support en tant que tel a une fin de vie physique (5 à 10 ans en moyenne au maximum, parfois moins).
    • La solution est alors simplement de recopier les données numériques sur un autre support de technologie identique.
    •  Dans ce cas, il est souhaitable que la solution de "stockage" soit rendu responsable de cette migration de support dans le temps. Par exemple, si l'offre de stockage est une bandothèque (gestionnaire de bandes magnétiques), alors c'est de sa responsabilité que d'effectuer des relectures et recopies environ tous les 5 ans sur de nouveaux supports pour éviter l'effacement dû à la démagnétisation dans le temps. On peut voir la même chose avec les disques et le RAID5 qui permet de changer un disque en panne par un autre identique.
  • Le support est obsolète non en tant que support physique mais en tant que technologie (là aussi, possiblement entre 10 et 20 ans au maximum, souvent moins).
    • La solution peut être effectuée à deux niveaux, selon le cas de figure :
    1. L'offre de stockage est capable de "s'upgrader" toute seule, et peut donc gérer cette migration de technologie toute seule. Par exemple, dans le cas de notre bandothèque, celle-ci peut être compatible avec des LTO3, puis LTO4, puis LTO5... De même pour des baies de disques qui accepteraient des disques de technologies différentes.
    2. L'offre de stockage est elle-même obsolète (l'obsolescence de l'une provoquant l'obsolescence de l'autre), alors le SAE doit piloter cette migration. En clair, c'est la procédure de réversibilité réalisée au niveau du stockage uniquement. 
      • Le principe, pour faire court, est : le SAE lit depuis l'offre de stockage obsolète une archive, puis l'écrit dans la nouvelle, vérifie puis enfin efface l'archive dans l'offre de stockage obsolète. 
      • On peut aussi le faire plus efficacement en faisant discuter les deux offres de stockage entre elles : procédure de réversibilité avec versement direct vers une autre offre, puis contrôle par le SAE que tout est ok avant de donner l'autorisation de destruction auprès de l'offre de stockage obsolète.
Dans le cas du "Cloud" (privé, interne, et non pas externalisé, considéré pour l'aspect technologique et non comme hébergeur), c'est un peu pareil. 
Si l'offre de stockage devient obsolète :
  • soit le Cloud est "bien fait", c'est à dire que les services informatiques assurent son évolution de manière transparente pour le SAE, nous sommes alors dans le premier cas où l'offre de stockage assure sa propre migration technologique ;
  • soit il est "mal construit" ou "est vraiment obsolète", et alors il faut migrer les données d'un container (Cloud d'origine) vers un autre (Cloud ou pas), via le SAE qui contrôle et pilote ces opérations. A nouveau c'est le second cas, c'est à dire la réversibilité appliquée à l'offre de stockage uniquement.
La réversibilité doit être partout, à chaque étape, mais je ne vous apprend rien.

Distinction entre archivage et offre de stockage

Ensuite la distinction entre archivage et offre de stockage, c'est la même différence pour le papier entre le référentiel des archives, le plan de classement, le référentiel de localisation des archives d'une part (le SAE) et le bâtiment qui contient les cartons d'archives (l'offre de stockage) d'autre part. On ne demande pas au bâtiment de gérer les archives comme peuvent le faire les archivistes, mais de les conserver en bon état. 
On demande la même chose à l'offre de stockage. Elle n'a pas à avoir l'intelligence, c'est le SAE qui l'a. Le SAE vient aider l'archiviste sur les travaux de masse, ceux qui peuvent être automatisés.

La distinction est donc pragmatique : à chacun son rôle et ses compétences. L'architecte en bâtiment sait construire un bâtiment qui résiste au feu, aux inondations, ..., tout comme un concepteur d'offres de stockage devrait être capable d'offrir les fonctionnalités de bases attendues (conservation au sens physique et non logique, traçabilité, ...). La plupart des offres dites "d'archivage", y compris sur le Cloud (Janus pourrait même dire "surtout sur le Cloud"), sont en fait des offres de stockage sécurisé, mais pas des SAE. Ils répondent en général aux spécifications correspondant à la norme française AFNOR Z42-020 dite "coffre-fort électronique". Dans ces offres, aucune fonctionnalité de transformation de format dans le temps, aucune fonctionnalité concernant les métadonnées, aucune gestion en fait tout court des archives, mais juste un stockage garanti dans le temps... En clair, dans 50 ans (si le média existe toujours), vous retrouverez toujours vos données numériques, si vous avez toujours leur référence, mais vous ne pourrez plus les consulter (le format sera obsolète).

Là encore, nous publierons quelque chose. Mais rien de très nouveau sous le soleil. En France, c'est la distinction entre la Z42-013 (le SAE complet) et la Z42-020 (uniquement l'offre de stockage, nommée ici "coffre-fort électronique", mais sans intelligence, hormis les aspects conservations techniques et traçabilités).

Formats de communication

Comme le souligne Janus, le format de communication est loin d'être une chose simple, surtout pour les formats "très professionnels" comme ceux liés à la CAO et autres. 
Il s'agit là selon moi de spécifications d'experts, hors du périmètre de compétences des archivistes pour le coup. En effet, il faut sur ce sujet des experts dans les formats de fichiers correspondants pour aider les archivistes à déterminer d'une part le bon format de conservation (si le PDF/A répondait à tout, ça se saurait), ainsi que le bon format de communication (là encore, si le PDF/A était partout, nous ne nous poserions même pas la question).

De plus, ces questions doivent être reposées (par les archivistes) régulièrement, car la technologie évoluant, même le PDF/A dans 20 ans sera totalement obsolète... Et les navigateurs web d'aujourd'hui ne seront sans doute pas nos outils dans 20 ans pour atteindre l'information, donc les formats de communication évolueront avec les technologies d'accès. 
Il faudra donc régulièrement se reposer la question du format de conservation et du format de communication.  
Je n'ai malheureusement pas de solution toute faite, hormis être pro-actif sur les formats les plus courants, et réactifs sur les plus rares, quand ils sont détectées en entrée du SAE (versement). 

Mais pour que cela soit efficace, encore faut-il que le versement ne tarde pas par rapport à la date de création de la donnée numérique. Si 20 ans s'écoulent entre les deux, autant dire que les solutions risquent fort d'avoir disparues dans les soubresauts des révolutions technologiques.

Je me rends compte que j'ai souvent dit : nous publierons prochainement... Bon, espérons que nous aurons le temps de le faire, ce serait dommage de ne pas partager le fruit de nos études...

2 commentaires:

  1. D’accord sur tout… ou presque.
    Juste quelques nuances.

    A propos des versements automatisables
    C’est bien entendu ce type de mise en place auquel il faut viser le plus possible. C’est plus laborieux à la conception, il faut penser à tout et le diable est dans le détail (un exemple récent : Quand une base de données génère des pdf à la volée pour la visualisation mais que ceux-ci ne sont pas sauvegardés en tant que pdf en mode opérationnel courant, comment générer des pdf pour l’archivage alors qu’il existe plusieurs formats de visualisation).

    Dans ce processus, l’archiviste se sent comme le jambon entre deux tranches de pain (l’informaticien de l’application métier qui exporte et l’informaticien du SAE qui importe). Cela n’est pas forcément inconfortable car les informaticiens peuvent être rassurés par la présence d’un confrère et que l’archiviste n’a plus qu’à se préoccuper d’archivistique (en fait, il faut quand même qu’il puisse suivre le langage des informaticiens sinon il est disqualifié).

    La granularité dans le cas du vrac.
    Dans ce cas, je ne suis pas d’accord que la messagerie soit une sorte de vrac. C’est vrai si l’on considère la messagerie comme une forme générique mais faux dans la mesure ou chaque messagerie peut être configurée selon des besoins métier fort différents, qui nécessitent des méthodes d’archivage numérique propre. Pour s’en convaincre, voir les liens ci-dessous :
    http://regarddejanus.wordpress.com/2011/11/28/gestion-du-courriel-les-bonnes-pratiques-de-la-bodleian-library/
    http://regarddejanus.wordpress.com/2011/10/01/pourquoi-conserver-les-courriels-est-plus-difficile-quil-ne-semble/
    http://regarddejanus.wordpress.com/2011/09/28/conserver-les-courriels-la-nature-du-probleme/

    Je suis persuadé que les outils sémantiques pourront à l’avenir (mais dans quel délai ?) nous aider dans l’indexation. Mais à voir par exemple comme la Bibliothèque du Congrès tarde à publier des instruments de recherche de nouvelle génération pour les archives de Twitter j’ai des doutes. (http://regarddejanus.wordpress.com/2011/06/13/archivage-de-twitter-nouvelles-du-front/)

    Archives appartenant à plusieurs arborescences (de classement)
    Ici aussi, je suis convaincu mais une référence plus précises sur les expérimentations en cours dans ce sens serait appréciable (et appréciée).

    Durabilité des medias
    Les distinctions entre les différents types d’obsolescences sont un vrai délice de clarté.
    Il va sans dire, mais encore mieux en le disant, que LA REVERSIBILITE DOIT ETRE PARTOUT (on ne le dira jamais assez).


    Voila. Il ne reste plus…
    Qu’à publier prochainement !

    RépondreSupprimer
    Réponses
    1. Merci pour tes compléments !

      Effectivement, la position d'un archiviste au milieu de 2 informaticiens (amont, aval) est certainement inconfortable, mais elle rassure les informaticiens, je peux te l'assurer.

      Je comprends ta remarque sur la messagerie n'est pas un vrac. Dans un cas idéal, où l'utilisateur et les usages sont respectueux de son usage, d'un classement dès le départ (ou l'arrivée), alors ce n'est pas du vrac.

      Malheureusement, comme tu le notais dans ton blog de 2011, c'est loin d'être le cas. On peut pester, gronder, il n'empêche que les messageries sont un ensemble de courriels disparates, de valeurs variables, sur des sujets souvent très divers, voire même désordonnés (en apparence). Et c'est cet apparent "vrac" dont je parlais. Je parle donc bien d'un vrac "métier" et non "technique".

      Mettons de côté pour le moment les aspects techniques (EML non Microsoft, MSG Microsoft, NSF Lotus, ... et autres éléments comme le format de consultation, de conservation, le traitement des pièces jointes, ...). C'est encore un autre problème, et l'archéologie des courriels est un problème pour le moins ardu.

      Sur un plan "métier", il n'est pas question ici de demander à un être humain de classer à la main les 100.000 courriels d'une messagerie, mais qu'un programme le fasse à sa place.

      L'humain ne pourra pas se charger de gérer un par un les documents variables (que ce soient des courriels ou de la bureautique). Il n'en aura pas le temps. On n'embauchera pas des milliers d'agents pour faire ces traitements de qualité (hélas).
      Partant de ce constat, il faut donc que l'informatique vienne à l'aide en effectuant des travaux de masse, pour soulager les archivistes du fastidieux. Puis les archivistes, par un jeu de sémantisation (on s'en approche, lentement, mais surement) ou d'autres techniques, pourront alors affiner et apporter de la qualité là où c'est nécessaire.

      Ce ne sera jamais aussi bien que l'humain, mais entre ne rien faire, et faire un peu, il vaut mieux faire un peu, n'est-ce pas ?

      Pour les multiples arborescences, le premier élément que je peux dire, c'est que nous sommes partis de MOREQ 2010, et notamment de sa capacité à proposer qu'un objet numérique puisse être multi-référencé. Nous avons simplement généralisé ce point à l'ensemble de l'arbre, et non seulement les feuilles.

      Un peu de patience... les publications arrivent...

      Supprimer