Exigences obligatoires du MoReq2/Chapitre 6 : Capture et déclaration des documents
De Maarch MoReq2.
- Ch. 3 : Plan de classement
- Ch. 4 : Sécurité
- Ch. 5 : Conservation et destruction
- Ch. 6 : Capture
- Ch. 7 : Identification
- Ch. 8 : Recherche et restitution
- Ch. 9 : Administration
- Ch. 11 : Non fonctionnel
- Ch. 12 : Métadonnées
Incomplet
Liste
| Capture | Import par lots | Gestion des messages électroniques | Types de documents archivés | Numérisation et traitement de l'image |
|---|---|---|---|---|
Également :
Conventions de lecture
- Les numéros d'exigence en gras dans la liste et en rouge dans le détail indiquent des exigences retenues par M.-A. Chabin.
- Les phrases en italique dans la colonne Observations sont les commentaires extraits directement du MoReq2.
- Les phrases en bleu dans la colonne Observations sont des commentaires, des réflexions ou des questions de l'équipe projet MoReq2.Maarch.
- Les liens sur la qualité des tests (O, N ou P) permettent d'accéder à ceux-ci.
Capture
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
6.1.1
Le processus de capture du SAE doit, par ses contrôles et ses fonctionnalités, permettre aux utilisateurs de :
| P | « Format » est défini dans le glossaire. L’exigence est de pouvoir capturer n’importe quel format de fichier.
Il n’est pas prévu de tester cette exigence de capture et il n’est pas exigé que le SAE fasse des restitutions (voir le glossaire) de tous les formats possibles. MoReq2 du reste ne donne pas de liste de tous les formats à capturer, dans la mesure où ceux-ci varient dans le temps et avec l’évolution des logiciels. Toutefois, il n’y a aucun doute que les types de document à archiver seront variés ; ce sera notamment les documents régulièrement utilisés dans les bureaux :
Dans certains cas, le SAE peut aussi devoir capturer d’autres types de documents tels que :
Ces listes ne sont pas exhaustives. Certains formats peuvent impacter la sécurité de l'application (.exe). Gérer dans Maarch Entreprise par Extensions.xml (apps). |
6.1.2
| Le SAE ne doit imposer aucune limite au nombre de documents à archiver dans une série, un dossier, sous-dossier ou volume, ni au nombre total de documents stockés dans le SAE. | P | De gros volumes de documents archivés tendront à rendre le système difficile à utiliser, et ce n’est en général pas conseillé. Cette exigence vise les situations où les gros volumes sont inévitables comme dans les environnements transactionnels.
|
6.1.3
| En cas de capture d’un document formé de plusieurs composants (voir le glossaire), le SAE devra capturer tous les composants. | P |
|
6.1.4
| En cas de capture d’un document électronique de plus d’un composant, le SAE doit permettre de gérer le document comme une seule entité, en maintenant les liens entre les composants et en maintenant l’intégrité de la structure du document archivé. | P | Exemples de documents composites :
Il peut arriver que les liens entre les composants ne fonctionnent pas s’ils sont simplement copiés dans l’entrepôt du SAE. Ainsi, de nombreuses pages web comportent des liens vers des graphiques ou d’autres objets avec des adresses (URL) extérieures à l’entrepôt ; et les tableaux liés contiennent en général des liens externes à l’entrepôt (noms de fichiers du système d’exploitation). Voir exigence suivante.
|
6.1.5
| En cas de capture d’un document électronique de plus d’un composant, le SAE devrait modifier le document, si nécessaire, afin de préserver la possibilité de restitution. Autrement dit, le SAE pourra changer les références internes (liens) de certains composants. | P | Cette exigence ne s’applique qu’aux seuls formats définis pour le SAE et non aux autres formats. Exemples :
Ceci est contraire au principe général de non modification du contenu des documents archivés, mais c’est inévitable pour des documents composites qui doivent être stockés dans leur format d’origine sans perdre leurs caractéristiques (liens, fidélité). Ces modifications sont acceptables dès lors qu’elles sont tracées dans l’historique de événements du SAE (voir exigence suivante). Une alternative consiste à convertir le document archivé dans un autre format (tel que PDF/A) qui en préserve l’apparence ; voir exigence 11.7.8 ; d’un autre côté, si on évite de modifier les liens, on risque de les perdre. Attention : optionnelle |
6.1.11
| Le SAE doit pouvoir capturer les métadonnées des documents conformément au modèle de métadonnées de MoReq2. | O |
|
6.1.18
Le SAE doit apporter une assistance automatique à la capture des documents entrants et sortants (ex : notes ou courriers avec telle présentation et tel format de fichier) par l’extraction automatique des métadonnées suivantes :
dans la mesure où elles existent. | O | MoReq2 ne précise pas le logiciel ou les formats pour les documents bureautiques ou la messagerie. L’extraction de métadonnées peut s’opérer en les localisant dans le document, à l’aide d’un gabarit qui les identifie et renseigne un formulaire vierge, ou par tout autre moyen.
|
6.1.32
Si un utilisateur capture un document qui possède plusieurs versions, le SAE doit lui permettre de :
| O |
|
Import par lots
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
6.2.1
| Quand un schéma XML pour MoReq2 aura été formellement publié, le SAE devra pouvoir effectuer un import par lots conforme à ce schéma. | O | Voir aussi l’exigence 5.3.1 sur l’export de documents archivés. Prises ensemble, ces deux exigences traitent de l’interopérabilité des systèmes conformes à MoReq2.
|
Gestion des messages électroniques
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
6.3.2
| Le SAE doit favoriser l’intégration de la capture des courriels, de sorte que la capture puisse être effectuée par un utilisateur à partir de l’application de messagerie, sans avoir besoin d’ouvrir le SAE. | O | Cette intégration est essentielle pour l’efficacité d’un SAE. Ainsi, un utilisateur devrait pouvoir faire un « glisser-coller » de l’application cliente vers le SAE ; choisir la fonction « capture » depuis l’application cliente ; ou bien l’application de messagerie devrait signaler les courriels déjà capturés dans le SAE. Le point fort de cette exigence est que l’utilisateur ne doit pas avoir à ouvrir le SAE pour capturer les courriels.
MoReq2 permet en outre (mais n’exige pas) la capture des courriels par d’autres voies, moins intégrées. Il est extrêmement surprenant de trouver une contrainte s'appliquant sur un autre logiciel que le SAE. Cela implique que le respect de la norme MoReq2 est dépendante du bon vouloir des éditeurs de clients de messagerie, donc que la norme n'est pas autonome[1]. |
6.3.3
Il doit être possible de configurer le SAE dès le départ pour déclencher une des opérations suivantes lorsqu’un utilisateur envoie un courriel :
| O | Quelle que soit la formule retenue, on peut accepter que le SAE demande à l’utilisateur de classer les documents manuellement et de saisir quelques métadonnées.
La formulation « lorsqu'un utilisateur envoie un courriel », qui fait référence à une fonctionnalité du client de messagerie (ou éventuellement à son serveur), est de facto incompatible avec l'assertion « être possible de configurer le SAE pour que » la fonctionnalité en question - dans le client de messagerie, donc - ait des conséquence sur le SAE. Cela est faisable techniquement, mais implique a priori[2] une modification du client de messagerie. |
6.3.7
Le SAE doit permettre à un utilisateur de choisir entre plusieurs modes de capture du courriel et de ses pièces jointes :
| O | Ceci s’applique aux courriels envoyés aussi bien que reçus.
La dernière de ces trois options signifie que la ou les pièces jointes sont archivées sans le contexte du message qui les a transmis. |
6.3.11
| Le SAE doit permettre à un utilisateur qui capture et archive un courriel d’en modifier le titre. | O | Ceci a pour but de permettre aux utilisateurs de corriger les titres inappropriés, de les développer ou de les rendre plus explicites.
Le titre du message est distinct de son objet ; ce dernier reste un élément du message, quel que soit le contenu du titre. Il serait certainement intéressant, à toute fin utile, de conserver le titre original dans une métadonnée. |
6.3.16
Le SAE devrait pouvoir identifier automatiquement et capturer tous les messages liés à un message donné indiqué par l’utilisateur, en une seule opération, comme :
ou
au choix de l’utilisateur. | O | La section 3.6.4 du RFC2822 « Champs d’identification » décrit l’utilisation des champs d’en-tête SMTP (« référence » et « répondre à »), en lien avec le champ « identifiant du message », pour identifier les messages liés, ce qu’on appelle parfois « fil de discussion ».
Exigence à reclasser dans les optionnelles. |
Types de documents archivés
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
Numérisation et traitement de l'image
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
