Archivage & Open Source font-ils bon ménage ?

Un mois de mars 2015 riche dans le domaine des archives :

• La publication le 18 mars 2015 par le NARA (The U.S. National Archives and Records Administration) d’une liste d’outils autour du Records Management
• L’annonce faite le 10 mars 2015 par le gouvernement du lancement officiel du programme VITAM (Valeurs Immatérielles Transmises aux Archives pour Mémoire)
• Un nouveau module RM pour Maarch annoncé le 24 mars 2015

Ces 3 événements ont un lien commun car ils parlent tous d’Open Source. Est-ce une tendance de fond ? Est-ce une « bonne » idée d’introduire de l’Open Source dans un système d’archivage ?

Pour moi la question n’est pas là : le système doit répondre aux besoins exprimés et standards du marché avec une gestion de la durée de la conservation, une écriture en Y des contenus, une réversibilité, la gestion des empreintes pour garantir l’intégrité des données et les fonctions habituelles autour du document (accès, métadonnées, recherche…).

Dans le cadre de VITAM,  des briques Open Source seront utilisées  pour fournir un service de dépôt et consultation à base d’API. Pour certains composants, on peut penser qu’ils vont suivre le SILL (Socle Interministériel de Logiciels Libres dont la dernière version est sortie au début du mois de mars)  avec Apache, Tomcat, OpenLDAP, MangoDB (plutôt que PostgreSQL), ElasticSearch…

Mais cela ne concerne que les composants techniques. Il y aura donc des développements autour des spécificités de l’archivage pour implémenter les principes de l’OAIS, de MEDONA, de la 42-013 de MOREQ…

Développements qui seront eux-mêmes proposés en Open Source.

Bref, un beau projet qui n’est pas sans risques notamment au niveau de la capacité à proposer un modèle assez générique pour répondre au versement des différentes applications sources…

PS : Concernant la liste du NARA, j’y reviendrai dans d’autres articles en détaillant certaines solutions intéressantes.

 

Archivage : Exemple d’un ‘bon’ cycle de vie

En publiant mon précédent article sur l’archivage dans le Cloud, je suis tombé sur un graphique présentant le cycle de vie d’un document, toujours extrait du même document de l’Aproged :

Copyright APROGED

Ce graphique  a le mérite d’être simple et d’utiliser des concepts qui me plaisent :

• En effet, on ne parle pas « d’archives courantes » pour désigner des documents en cours d’élaboration.
• Sous l’angle IT, on parle d’un outil de GED pour traiter la gestion du document . En parallèle, et dès le document validé, on parle de SAE. Le document peut donc se trouver dans le deux systèmes à un moment donné. On peut imaginer un système hybride avec une interface GED qui pointe sur les documents stockés en SAE.
• On ne met pas un graphique avec une notion de fréquence d’accès : un SAE n’a pas vocation à récupérer les documents d’une GED qui ne sont pas ‘souvent’ lus.
• On voit bien que la fonction Records Management couvre les fonctions de GED et SAE sur la partie Archives intermédiaire. C’est bien l’ensemble du cycle de vie qu’il est important de gérer comme un tout, seule façon d’assurer une valeur probante au document.

La Théorie des 3 âges, sujet très régulièrement abordé sur la toile, définit sur un vocabulaire qui m’inspire beaucoup moins…

Archivage : quel est LE SAE idéal ?

Le choix d’un progiciel est une phase classique dans un projet du système d’Information.

Ce billet a vocation à mettre en lumière quelques points spécifiques sur le choix d’un progiciel d’archivage (SAE : Système d’Archivage Électronique).

1 – Processus de sélection d’un progiciel

Chaque DSI a sa manière de traiter cette phase de sélection, je resterai donc à un niveau macro. De plus, le processus est à adapter en fonction de l’importance du projet.

Habituellement, dans le choix d’un outil, il y a une phase de prospection visant à définir une liste de produits qui font « référence sur le marché » (au travers de la veille, d’études de marché…). Ensuite, on établit une liste de critères que doit remplir le progiciel (avec pondération éventuelle) répartis sur trois thèmes :

• Partie Fonctionnelle : par rapport à une expression de besoin listant les exigences, notation des différents produits. Il peut être intéressant d’avoir une réponse nuancée : le produit répond au besoin / répond avec un paramétrage / répond avec un développement / ne répond pas au besoin
• Partie Technique : partie essentiellement rédigée par la DSI autour des technologies utilisées, des protocoles supportés, des possibilités d’interface…
• Partie Commune : partie souvent négligée que je trouve importante. Il s’agit de bien mesurer l’importance du produit pour l’éditeur (% du CA du produit / CA total, nombre de clients, nombre de développeurs, fréquence de publication de version, horaires de la hot-line, existence d’un club Utilisateur…). Il y a également les informations classiques sur l’entreprise elle-même, ses références et les prix (licence au volume à l’utilisateur, maintenance). Il est indispensable d’obtenir des noms d’entreprise utilisant le produit pour aller les interroger et avoir un « véritable » retour terrain.

Il est d’usage d’adresser ce questionnaire aux différents éditeurs mais, étrangement, l’outil est parfait selon l’éditeur et répond à tous les besoins. Il est impératif d’avoir un regard critique, d’avoir des soutenances avec les éditeurs pour échanger  autour de leur proposition…

A la fin de cette étape, il ne devrait rester plus que 1 ou 2 candidats. Des maquettes peuvent éventuellement être mises en place pour valider certains points et déterminer l’heureux gagnant.

2 – Spécificités de l’archivage

Lorsque le domaine concerne l’archivage, voici quelques points assez essentiels et déterminants pour le choix :

• Archivage physique, de documents électronique ou mixte
• Gestion de la durée de conservation, Gel
• Sort final – définition d’un workflow (paramétrage, souplesse), alertes sur échéances
• Réversibilité : lorsqu’on parle d’archivage, on peut parler de durées de conservation importantes. Il faut donc envisager la possibilité de changer de système d’archivage. Il doit donc offrir des fonctionnalités pour extraire les données
• Ouverture flux entrants + système d’import : automatiser des versements applicatifs
• Interrogation depuis une autre application
• Connecteurs standards avec d’autres composants du SI (SAP, SharePoint). Bien analyser les possibilités de paramétrage de ces connecteurs
• Mise en place de son propre connecteur pour s’interfacer avec une application « maison » (le développement de ce connecteur pourvant se faire en totale autonomie ou en sous-traitance)
• Gestion de la migration de formats (les formats de fichiers évoluant, il sera peut être nécessaire de transformer les formats des document selon un processus contrôlé)
• Gestion des supports (doit être transparent) : déplacement sur un media plus lent (plus économique)
• Respect normes & standards ? Il n’est jamais facile de s’y retrouver dans la jungle des normes et standards autour de l’archivage. De toute façon, l’éditeur vous dira que son progiciel respecte  l’OAIS, MOREQ, NF Z 42-013…
  Tant qu’il n’y a pas de certification, difficile d’y voir clair. Il est néanmoins intéressant de les utiliser comme check-list afin de poser des questions sur certains thèmes : gestion des logs, horodatage pour la 42-013 ;  gestion des plans de classement, des métadonnées, gestion des rôles pour MOREQ ; gestion des versements et consultation avec l’OAIS…
• Outil séparé ou module de l’ECM ? Les deux approches existent :  soit, j’ai un « pure player » spécialisé dans l’archivage, soit j’utilise un module de mon ECM. Dans ce dernier cas, il faut bien s’assurer que la brique Archivage est autonome, qu’elle est capable de traiter des versements provenant d’autres applications que l’ECM…

Voilà, maintenant vous avez toutes les billes pour trouver l’outil en parfaite adéquation avec vos besoins 🙂

Archinnovez !

Archivage et innovation ?

On a souvent tendance à les exclure…

Or pour moi, il y a de nombreuses opportunités pour remettre l’archivage au goût du jour 🙂

Pour rappel, je vois l’archivage sur deux axes :

• L’archivage à valeur probante, dans le cas d’une réglementation, d’une clause contractuelle…
• L’archivage autour du savoir-faire, lié au patrimoine de l’entreprise (attention, je ne parle pas du patrimoine qui se déversera dans les archives historiques mais plutôt de la gestion des connaissances)

Et c’est sur ce 2ème axe qu’un système d’archivage peut apporter de nombreuses fonctionnalités qui pourraient favoriser des démarches d’innovation.

Je trouve dommage que les éditeurs d’outil n’essaient pas de valoriser ces gisements d’information. On retrouve les mêmes problématiques que pour les ECM : classement, gestion des métadonnées, système de recherche…

Les éditeurs doivent eux-mêmes innover 😉 dans leurs produits afin de faciliter l’accès aux informations au travers de navigations intelligentes, de plans de classement dynamiques, d’aides à la gestion du sort final…

Et voir enfin le SAE comme composant d’une démarche globale d’innovation.