Le module 2 d’ICA-Req: exigences fonctionnelles pour les SAE

Je viens de lire le module 2 d’ICA-Req qui est très intéressant et qui sera sans doute utile à la communauté de professionnels de l’archivage électronique. Je vais résumer ici les éléments les plus importants et j’ajouterai quelques commentaires tirés de ma compréhension personnelle du texte. Je ne prétends donc pas donner une vision  100% objective. J’ai voulu notamment expliquer certains de mes doutes sur ce module par rapport à ma propre pratique (doutes sur l’application d’ICA-Req et non pas sur sa pertinence).

Structure du module :
Introduction
Lignes directrices (principes généraux)
Exigences fonctionnelles
Annexes

1. Introduction

Le champ d’application de ce module est limité aux produits généralement appelés « SAE ». Le module ne fournit que des exigences spécifiques à ce type de système et il n’y a donc pas d’exigences pour les documents ou données utilisés au sein des applications métier. On ne trouvera pas non plus de recommandations pour la pérennisation de l’information archivée (c’est-à-dire pour la planification de la préservation, telle qu’elle est définie dans le modèle OAIS, il s’agit notamment des migrations qui sont donc exclues de l’étude).
L’objectif est d’établir une liste d’exigences fonctionnelles pour les SAE afin de réviser les fonctionnalités d’archivage et/ou d’évaluer la conformité des SAE existants. Ces exigences peuvent servir comme critère de sélection des SAE disponibles sur le marché. Ica-Req identifie un niveau minimal de fonctionnalités d’archivage pour un SAE. L’ICA souhaite favoriser la standardisation pour les fournisseurs de logiciels dans le monde entier. Les exigences sont basées sur les principes directeurs du records management énoncés dans la première partie de la norme ISO 15489. Il est à mon avis très important d’avoir cette considération à l’esprit lorsque l’on lit ICA-Req.

Publics cibles : personnel responsable de la conception, de la révision et/ou de la mise en œuvre des SAE (cela comprend donc les professionnels des archives et les informaticiens) ; organismes de normalisation, développeurs de logiciels.

Terminologie : dans la mesure où ce document ne s’adresse pas qu’aux archivistes, les auteurs ont souhaité limiter l’utilisation de termes purement archivistiques. Pour les termes spécifiques il faut se reporter au glossaire.  Je note en particulier la définition de « SAE » qui est  restreinte et peut être une source d’ambiguïté dans la pratique archivistique française.  ICA-Req définit les SAE de la façon suivante: « systèmes spécialement conçus pour gérer la conservation et le sort final des documents engageants archivés. Ils conservent le contenu, le contexte, la structure et les liens entre documents pour permettre d’y accéder et renforcer leur valeur de preuve. » (Ica-Req, Module 2, p. 8.) Cette définition donnée présuppose que le SAE est forcément utilisé dès l’âge dit courant (dès la validation des documents). En effet, l’utilisation du terme « documents engageants à archiver » est la traduction du mot anglais « record ». Ce n’est donc pas le terme « archive » qui est utilisé. En plus, la gestion du sort final fait partie de la définition générale ce qui revient à admettre que le SAE gère forcément des archives éliminables. La possibilité qu’un SAE soit destiné exclusivement à un archivage définitif n’est donc pas envisagée par cette définition (cela va dans le sens du records management). Mais, le périmètre documentaire d’un SAE peut varier en fonction des contextes, comme à l’ALPI 40 (Landes) où il y a une plateforme réservée à l’archivage historique. Cependant cela reste un cas marginal, je n’en connais pas d’autres. La définition du SAE donnée par ICA-Req est très précise et on doit bien avoir cette définition à l’esprit pour comprendre le reste du texte.

2. Lignes directrices

Arguments pour développer la gestion et l’archivage des documents engageants.
On trouve d’abord une définition du « document engageant (à archiver)» : il est la conséquence ou le produit d’une action et de ce fait il est lié à une activité. Le contenu du document doit être formellement fixé, c’est-à-dire être une représentation figée d’une action donnée. Il y a ensuite une liste très générale des risques liés à un archivage non maîtrisé puis une liste des bénéfices d’une « bonne » politique d’archivage. Parmi les bénéfices listés je vais citer ceux qui peuvent être repris par les archivistes qui travaillent à la construction d’un projet d’archivage électronique : identification des documents vitaux pour la continuité de l’activité, protection des intérêts de la collectivité, renforcement de la sécurité des documents (en particulier de l’information sensible et des données personnelles), la disponibilité des documents comme aide à la décision, la réduction du risque de perte des données.

Caractéristiques des documents électroniques et fonctions générales attendues d’un SAE

Attention : dans cette partie le terme « production » est utilisé plusieurs fois de façon très ambigüe et ne devrait pas à mon avis être compris comme production d’un document de toutes pièces mais plutôt comme « transfert » d’un document vers le SAE. Mais je me trompe peut-être, je ne sais pas si cela est lié à une mauvaise interprétation du texte anglais ou bien si cela correspond davantage à la pratique archivistique et du records management dans les pays anglophones (l’Australie notamment).

Les documents engageants (à archiver) doivent être gérés dès leur validation afin d’assurer les caractéristiques suivantes : authenticité, fiabilité, intégrité, exploitabilité. Le SAE doit posséder des fonctions pour garantir ces caractéristiques.

Les fonctions attendues sont les suivantes :

-Production (?) et capture des documents engageants dans leur contexte. (Je ne comprends pas l’utilisation du terme « production » ici, a priori on ne produit pas des documents dans un SAE, on y transfère des documents qui ont été produits dans d’autres systèmes).
-Gestion et conservation des documents archivés, c’est-à-dire gestion du cycle de vie : identification des durées de conservation, le sort final doit pouvoir être appliqué de manière ordonnée, systématique et facile à auditer, les systèmes doivent pouvoir supprimer les documents de manière systématique,  responsable et facile à auditer.
-Intégration des métadonnées d’archivage de manière normalisée dans le respect des exigences réglementaires conformément à l’ISO/TS 23081-2 (2007).
-Traçabilité des activités : toute action dont un document engageant ferait l’objet doit être tracée.
-Des rapports peuvent être établis sur les documents archivés et leur gestion.
-Procédures de sécurité, contrôles classiques d’accès et de sécurité des systèmes (Cela veut dire aussi que la sécurité du SAE doit être intégrée au système de sécurité global de l’organisme/entreprise/collectivité, lorsqu’il existe …).

Ica-Req distingue 4 niveaux d’accès (ce sont sans doute les profils de base, il peut y en avoir d’autres)

Niveaux d’accès (Ica-Req, Module 2, page 15):

Utilisateur 

 

Toute personne ayant un droit d’accès au SAE, c’est-à-dire toute personne qui produit (attention à ce mot qui est source d’ambiguïté) et valide, reçoit et/ou utilise les documents conservés dans le système. Cela correspond au niveau d’accès élémentaire attribué à la plupart des employés d’un(e) entreprise/organisme. 

L’utilisation du verbe « produire » pourrait laisser penser que l’on ne parle pas que des SAE. Or, cette partie est présentée comme la description des fonctions attendues pour un SAE.

Utilisateur habilité 

 

Utilisateur ayant des droits d’accès particuliers lui permettant des accès et/ou contrôles supplémentaires sur les documents du SAE. En certaines circonstances, ces utilisateurs peuvent recevoir l’autorisation d’exécuter des tâches identiques à celles de l’administrateur système, telle que la possibilité de clore ou de rouvrir des documents, d’en créer des extraits et d’en modifier les métadonnées. Les droits attribués aux utilisateurs habilités dépendent de leur niveau de responsabilité et des besoins.
Administrateur de l’archivage (archiviste) 

 

Un administrateur système, responsable de l’archivage ou archiviste, chargé de configurer, de contrôler et de gérer le contenu et l’utilisation du SAE.
Administrateur système (informaticien) 

 

Personne chargée d’attribuer et de supprimer les droits des utilisateurs habilités ou non.

– Interopérabilité du SAE avec les autres systèmes informatiques de l’organisme/entreprise
– Export et import des données
–  Le SAE doit permettre de gérer des documents ayant fait l’objet de mesures de protection technologique comme la signature électronique. Les informations concernant la signature électronique et sa validation doivent être enregistrées dans les métadonnées.

Modèle conceptuel des exigences fonctionnelles pour un SAE Attention, le modèle ne décrit pas les étapes des processus gérés par un SAE

Le modèle est présenté sous forme de schéma, celui-ci distingue quatre grandes fonctionnalités qui regroupent d’autres fonctionnalités:

Production (?)/capture: capture, identification, classement
– Maintenance: contrôle et sécurité, dossiers mixtes, conservation, sort final
– Mise à disposition: recherche, repérage, restitution (accès)
– Administration

L’utilisation du mot « production » me semble particulièrement étrange, a priori on ne produit pas de documents dans un SAE ( ?), celui-ci reçoit des documents qui ont été produits dans d’autres systèmes et c’est bien précisé dans le schéma qui évoque les documents « venant de bureautique, workflows, sites web, bases de données, systèmes d’images, applications métier ».  L’utilisation du mot  production me paraît d’autant plus problématique que la définition de cette fonction qui est donnée plus loin est aussi ambigüe:

« En général, les SAE capturent, classent et identifient les documents engageants pour garantir que leur contenu, leur structure et leur contexte de production sont fixes dans le temps et l’espace. Ces processus d’archivage facilitent la constitution d’archives intègres, authentiques et exploitables. Une fonctionnalité permettant de créer un nouveau document en réutilisant contenu, structure et contexte des documents déjà archivés est souhaitable. Le contrôle des versions et des documents dépasse les objectifs de ce module mais est toutefois abordé ». (ICA-Req, Module 2, p. 17).

La phrase qui apparaît en gras me paraît aussi surprenante dans la mesure où l’on ne crée pas de nouveaux documents dans un SAE (je me trompe peut-être ou j’ai mal compris).

Enfin, le module 2 fournit une liste de 275 exigences fonctionnelles qui correspondent à chaque fonction générale du schéma  (pages 24 à 61). Elles sont présentées de façon synthétique et claire. L’ensemble constitue une excellente synthèse des recommandations essentielles pour garantir le bon fonctionnement d’un SAE.

LFH

Étiquettes : , , , , ,

3 commentaires sur “Le module 2 d’ICA-Req: exigences fonctionnelles pour les SAE”

  1. vanessa 14 février 2011 à 18:06 #

    bon, je me suis penchée sur cette histoire de « production » – mieux vaut tard que jamais !

    le texte anglais contient « create », notamment dans la figure 1 (2.3), au 2.3.1 et au début de la partie 3.

    Pour autant, le texte ne parle quasiment pas de la production des documents (forcément hors SAE), sauf au 3.1  » les documents […] sont produits sous différents formats […] Un SAE doit capturer le contenu, la structure et le contexte des documents engageants […]. »
    Il n’y a donc pas ambiguïté, le SAE n’intervient qu’au moment de la capture.

    Pourquoi alors inclure « production » dans le schéma de la figure 1 ? bonne question🙂
    peut-être qu’une piste à explorer se trouve là :
    http://www.naa.gov.au/records-management/create-capture-describe/capture/index.aspx
    « In electronic systems, records might be created and captured at the same time. »
    Si le document devient records au moment où on le valide et on le fige et qu’il est transféré dans le SAE au moment où on le valide et on le fige, alors création du records (qui a été traduit par production) et capture sont simultanés…

    Pour ta remarque sur les utilisateurs, on peut aussi comprendre que toute personne ayant produit des documents peut ensuite, une fois ceux-ci transférés dans le SAE, y accéder. Que cette personne ait produit les documents conservés dans le SAE ne signifie pas qu’elle les a produits dans le SAE lui-même.

    Quant au dernier point (duplication, extraction etc. de contenu venant de documents conservés dans le SAE), il est à relier à la partie 9.3 de Moreq 2 (modification, suppression et masquage des documents archivés), à creuser…

    • archivesonline 15 février 2011 à 10:31 #

      @vanessa

      Comme c’est gentil!😉
      Merci pour ces remarques et compléments d’information qui me sont bien utiles!

Trackbacks/Pingbacks

  1. Cactus Acide » L'observatoire du neuromancien » L’observatoire du neuromancien 12/31/2010 - 1 janvier 2011

    […] Le module 2 d’ICA-Req: exigences fonctionnelles pour les SAE | Archives Online […]

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :