De Maarch MoReq2.
Complet
Liste
É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.
Convivialité
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence
| Test : N (non testable)/P (partiellement testable) / O (testable)
| Observations : Observations éventuelles
|
11.1.4
| L’aide en ligne du SAE devrait être contextuelle.
| O
|
Voir également le commentaire de la 11.2.3.
|
↑
11.1.5
| Le SAE devrait inclure une aide en ligne pour l’utilisation du plan de classement avec au moins un accès à la description des métadonnées des séries, dossiers, sous-dossiers et volumes.
| P
|
|
↑
11.1.6
| Le SAE devrait inclure un thésaurus pour aider les utilisateurs à choisir les mots clés, les descripteurs, etc.
| O
| Voir 11.4.1, 11.4.2 et 11.8.11.
|
↑
11.1.8
| L’interface utilisateurs du SAE devrait être adaptée aux besoins et aux compétences d’utilisateurs très différents ; c’est-à-dire conçue selon les critères d’accessibilité des normes et guides disponibles, et compatible avec les logiciels courants.
| O
| Pour les normes et guides, voir l’annexe 7.
L'interface devrait être « compatible avec les logiciels courants » : soit le SAE utilise sa propre bibliothèque graphique, soit il utilise un logiciel tiers pour fonctionner. Ce dernier cas est principalement implémenté dans les architectures web pour lesquelles un navigateur est nécessaire.
|
↑
11.1.16
| Le SAE devrait permettre aux utilisateurs de choisir des alertes sonores (son et volume), et de sauvegarder ces choix dans leur profil utilisateur.
| O
|
Dans beaucoup de cas, ces paramétrages ne sont pas liés aux applications elles-mêmes mais à l'interface graphique utilisée.
|
↑
11.1.20
| Le SAE devrait être étroitement intégré au système de messagerie de l’entreprise/organisation afin qu’un utilisateur puisse envoyer électroniquement des documents ou des groupes de documents sans quitter le SAE.
Par exemple, un utilisateur doit pouvoir envoyer un courrier client à partir du SAE. L’objectif est que l’utilisateur n’ait pas à se déconnecter pour transmettre un document archivé.
| N
|
Cette exigence semble tout à fait testable.
Voir également la 11.1.21.
|
↑
11.1.21
| Si le point 11.1.20 est acquis, le SAE devrait envoyer des pointeurs ou des liens vers les groupes de documents ou les documents plutôt que des copies, si toutefois l’envoi est destiné à un autre utilisateur du SAE.
| N
| Il peut y avoir des exceptions, par exemple pour un utilisateur éloigné qui n’a pas accès à la base centrale.
|
↑
11.1.22
| Le SAE devrait indiquer si le message électronique a une pièce jointe.
| O
| Par exemple au moyen d’une icône.
L'utilisation de l'article défini « le » suggère qu'il s'agit d'un type de message électronique particulier. Comme cela n'est pas précisé, voici les hypothèses envisagées :
- un message électronique capturé dans le SAE ;
- un message envoyé depuis le SAE par l'utilisateur (voir exigences 11.1.20 et 11.1.21) ;
- un message envoyé depuis le SAE et reçu par un autre utilisateur.
|
↑
11.1.23
| Le SAE devrait autoriser des fonctions programmables par l’utilisateur.
| O
| Par exemple des macros créées par les utilisateurs.
Semble contraire aux règles SSI standard[1]. Si elle existe, cette fonctionnalité doit pouvoir être activée/désactivée par l'administrateur.
|
↑
11.1.24
| Lorsque les utilisateurs doivent saisir des métadonnées pour des documents numérisés (images de documents papier), le SAE devrait permettre le recours à la reconnaissance optique de caractères pour capturer les métadonnées à partir de l’image (OCR sur zone).
| O
| L’utilisateur doit pouvoir par exemple sélectionner la zone de l’image qui contient les métadonnées de date ou de titre, puis océriser cette image et déclarer le résultat comme métadonnées, tout cela en une seule opération.
|
↑
11.1.25
| Le SAE devrait permettre aux utilisateurs de définir des références croisées entre les documents, au sein du même groupe ou à travers différents groupes, pour faciliter la navigation entre les documents.
| O
|
La métadonnées la plus indiquée serait la M023 Relation.renvoie_à, bien que la formulation soit très généraliste.
|
↑
11.1.26
| Quand il consulte ou travaille sur un document ou un groupe de documents (série, dossier, sous-dossier ou volume), qu’il s’agisse ou non d’un résultat de recherche, l’utilisateur devrait pouvoir utiliser les fonctions du SAE pour trouver facilement une information dans le groupe immédiatement supérieur sans quitter ou fermer le document.
| O
| L’utilisateur doit pouvoir par exemple repérer dans quelle série, dans quel dossier, sous-dossier ou volume se situe le document consulté ; s’il voit les métadonnées du dossier, il doit voir la série de rattachement.
Il y aurait donc un « espace » navigation, relativement avancé puisque cet espace doit permettre la consultation des métadonnées des entités, et un « espace » travail, où le dernier document ouvert reste disponible en permanence (mais peut être fermé par l'utilisateur).
|
↑
11.1.27
| Le SAE devrait permettre à l’utilisateur qui accède à un dossier ou à un document de vérifier si un autre utilisateur, groupe ou profil y a accès.
| O
| Ceci doit permettre de signaler explicitement un utilisateur, un groupe ou un profil. Ainsi, un utilisateur peut s’enquérir des droits d’un autre sur tel ou tel document ou dossier, sans connaître forcément les membres du groupe ou du profil.
|
↑
11.1.28
| Le SAE devrait permettre à un utilisateur de réduire le risque d’erreur de classement par un verrou temporaire posé en un clic sur un dossier ou un document. Ce verrou devrait interdire l’accès du document ou du dossier aux autres utilisateurs (excepté l’administrateur) ; le SAE devrait informer systématiquement l’administrateur qu’un verrou temporaire a été posé, lui seul et nul ayant la faculté de le retirer.
| O
| Ceci doit permettre aux utilisateurs de corriger une erreur – document confidentiel classé par inadvertance (par glisser/lâcher) dans un dossier non sécurisé par exemple. Les utilisateurs n’ayant pas le droit de supprimer, retirer ou modifier les documents archivés, il faut l’intervention d’un administrateur.
Pour éviter l’abus de cette facilité, il est important que les utilisateurs soient formés à l’utilisation du verrou temporaire et que les administrateurs vérifient qu’ils n’en abusent pas.
|
↑
11.1.29
| Les utilisateurs devraient pouvoir faire des copies des documents du SAE sur leur poste de travail, dans d’autres environnements, par un simple glisser/lâcher sans que le document ou ses métadonnées en soient affectés.
| P
| Quand la copie d’un document est transposée dans un autre environnement, on peut accepter de perdre ses métadonnées (du fait même que la plupart des applications ne reconnaissent pas le modèle de métadonnées de MoReq2).
N'est-ce pas une forme de restitution ? Cela aurait donc une incidence sur les métadonnées.
|
↑
11.1.30
| Le SAE devrait fournir une aide en ligne qui soit visuelle.
| P
| Par exemple, avec des copies d’écran et/ou des animations montrant aux utilisateurs comment procéder.
En tête de liste de la catégorie « truismes ». Il faudra mettre de côté les expérimentation tactiles et gustatives... À noter la relative ambiguïté de la phrase de la version originale : « ... should provide help which provides visual guidance. » Noter également la testabilité « partielle ».
|
↑
11.1.31
| Le SAE devrait permettre aux utilisateurs de marquer certaines fonctions d’aide comme « favoris » ou équivalent afin de les retrouver plus facilement une autre fois.
| O
|
La fonctionnalité est rarement disponible dans les logiciels actuels, et peut être plus aisément implémentée via la gestion des favoris des navigateurs web.
|
↑
11.1.33
| Le SAE devrait permettre aux utilisateurs de marquer comme favoris des séries, des dossiers ou des documents, afin de les retrouver plus facilement une autre fois.
| O
|
|
↑
11.1.34
| Le SAE devrait permettre aux utilisateurs de transmettre leurs favoris à d’autres utilisateurs.
| O
| Les favoris peuvent être envoyés par messagerie ou par une autre voie.
|
↑
Normes techniques
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence
| Test : N (non testable)/P (partiellement testable) / O (testable)
| Observations : Observations éventuelles
|
↑
11.4.1
↑
11.4.2
↑
11.4.4
↑
11.4.5
↑
Externalisation des données et recours à des tiers
Complet
Remarque préalable : En dépit de l'aspect obligatoire de ce chapitre, aspect lié au fait qu'il ne soit pas dans le chapitre « modules optionnels », ainsi qu'à l'absence de toute mention spécifique dans l'introduction, il est évident que ces exigences ne s'appliquent que si le service d'archivage est fourni par un prestataire externe. Pour toute gestion in situ, il faut donc considérer l'ensemble de ce chapitre comme optionnel.
Dans les tableaux, lire :
| Exigence : Texte de l'exigence
| Test : N (non testable)/P (partiellement testable) / O (testable)
| Observations : Observations éventuelles
|
11.6.7
| Le prestataire devrait pouvoir permettre au client d’effectuer des requêtes, de visualiser et d’imprimer les documents et/ou dossiers depuis ses bureaux.
Ceci peut se faire, par exemple, via une connexion réseau.
| N
|
Voir également la 11.6.10.
Quel serait l'intérêt si ce n'était pas le cas ?
|
↑
11.6.8
| Le prestataire devrait pouvoir permettre au client de demander en ligne le téléchargement ou la transmission de documents et/ou de dossiers entre le SAE du client et les solutions de stockage du prestataire.
| N
|
Voir également la 11.6.10.
|
↑
11.6.9
| Le client devrait pouvoir demander des statistiques sur les documents hébergés, sur les échéances de durées de conservation, etc. Ceci devrait pouvoir se faire en ligne, depuis les bureaux du client.
| N
|
Voir également la 11.6.10.
|
↑
11.6.10
Les prestations énoncées en 11.6.7, 11.6.8 et 11.6.9 devraient :
- avoir des délais de réponse et de livraison contractualisés ;
- être effectuées dans un environnement sécurisé.
| N
|
|
↑
11.6.11
| Le client devrait vérifier que les locaux du prestataire sont corrects et obéissent aux critères de sécurité correspondant à ses besoins.
| N
|
|
↑
11.6.12
| Le client devrait vérifier que les procédures proposées et la gestion du stockage ne présentent pas plus de risques pour les documents que ses propres procédures.
| N
| Le prestataire devra prouver que tous les documents du client sont sauvegardés et que, en cas de panne du système, ils peuvent être récupérés dans les délais contractualisés.
|
↑
11.6.13
| Le client devrait vérifier que le prestataire emploie un personnel fiable lorsque les documents sont particulièrement sensibles.
| N
| La signature d’un engagement de confidentialité par tous les employés du prestataire au moment de leur recrutement est un plus.
Est-ce réellement du domaine du MoReq ? Auquel cas la remarque vaut également lorsque l'application n'est pas externalisée, c'est-à-dire qu'il devrait y avoir une exigence : « L'organisme doit s'assurer que le personnel manipulant les documents sensibles est fiable. »
|
↑
11.6.14
| Tout envoi de documents entre le client et le prestataire devrait être accompagné d’un bordereau comportant l’identification et le nombre des documents et dossiers transmis.
| N
|
Est-ce réellement du domaine du MoReq ?
|
↑
11.6.15
| Les tiers prestataires de transport devraient répondre aux exigences de qualité et de fiabilité du client.
| N
|
Est-ce réellement du domaine du MoReq ?
|
↑
Conservation à long terme et obsolescence technologique
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence
| Test : N (non testable)/P (partiellement testable) / O (testable)
| Observations : Observations éventuelles
|
11.7.3
| Le SAE devrait inclure des fonctionnalités de comparaison automatique et périodique des copies réalisées et le remplacement de toute copie fautive, afin de prévenir la dégradation des supports.
| P
|
La plupart des bons systèmes d'exploitation mettent en œuvre des routines de vérification des disques et des données, avec correction d'erreur. Imposer un tel service au SAE est susceptible de dégrader la performance pour une tâche déjà prise en compte.
|
↑
11.7.7
| Le SAE devrait pouvoir fournir des statistiques sur les formats de fichiers, les versions et les composants.
| O
| Par exemple, le SAE devrait pouvoir produire des listes de composants de formats prédéfinis. Cette fonction serait couplée à un logiciel intelligent ou une fonction de pilotage de la conservation visant à identifier les formats de fichiers susceptibles d’obsolescence.
|
↑
11.7.8
| Le SAE devrait pouvoir restituer (voir le glossaire) les documents archivés à partir de leur format d’origine dans un format de conservation à long terme prédéfini, lors de la capture, plus tard, ou lors d’un export.
| P
| On peut admettre que le processus de restitution soit initié par un programme extérieur au SAE dès lors que le contexte et les liens sont préservés durablement.
|
↑
11.7.9
| Quand cela est possible sans porter atteinte à l’intégrité des documents, le SAE devrait pouvoir convertir les composants à partir de leur format d’origine dans un format de conservation à long terme prédéfini, au moment de la capture, plus tard, ou lors d’un export.
| P
| On peut admettre que le processus de restitution soit exécuté par un programme extérieur au SAE dès lors que le contexte et les liens sont préservés durablement.
Il est essentiel que l’intégrité des documents constitués de composants restitués soit maintenue. La faisabilité de cette approche dépend en général à la fois de la qualité du processus de conversion et du logiciel ou du visualiseur utilisé. Par exemple, s’il s’agit de pages web comportant des images GIF, on peut admettre la conversion des seules images GIF si les conditions suivantes sont toutes remplies :
- les composants GIF sont convertis dans un format exécutable par l’application utilisée pour accéder aux pages web ; dans cet exemple, ce pourrait être JPEG ;
- les références aux images GIF des pages web sont modifiées au cours du processus de migration afin de renvoyer aux nouvelles images JPEG ;
- les composants originaux (les pages web initiales et les composants GIF initiaux) sont conservés à côté des nouveaux composants.
Le SAE doit au minimum permettre ces opérations et devrait au mieux les effectuer automatiquement.
Cet exemple est donné à titre d’illustration ; il ne sous-entend à ce jour aucune recommandation de migrer les images GIF.
|
↑
11.7.12
| Le SAE devrait pouvoir exporter des documents et leurs métadonnées sous la forme d’un Paquet d’information diffusé (DIP) tel que le définit le modèle OAIS, ISO 14721, annexe 7.
| O
|
Les définitions des formats données par l'OAIS sont extrêmement succintes ; il n'y a par exemple pas d'indication sur les informations a minima à inclure dans un tel paquet DIP, seules les catégories d'information sont indiquées : pérénisation, identification, provenance, contexte, intégrité[2]. Bref, rien d'exploitable en l'état.
|
↑
11.7.13
Le SAE devrait conserver au minimum les métadonnées suivantes dans la conversion d’un composant :
- le format original et sa version ;
- la date de conversion.
| O
|
Semble fortement lié au format cible, la testabilité serait donc moins complète.
|
↑
11.7.14
| Le SAE devrait pouvoir extraire les métadonnées techniques incluses dans un composant et les stocker comme métadonnées.
| P
| Ces métadonnées s’ajouteront aux métadonnées indiquées dans le modèle de métadonnées de MoReq2. Ce peut être par exemple les détails techniques d’une image tels que les métadonnées du format TIFF v6, ou l’ordre des octets (petit ou grand indien), la longueur ou la largeur de l’image.
|
↑
11.7.16
| Le SAE devrait pouvoir gérer une série de métadonnées de conservation pour les documents et leurs composants.
| P
| Voir annexe 9.
|
↑
11.7.17
| Le code source du SAE devrait soit être ouvert soit faire l’objet d’un contrat de dépôt chez un tiers de confiance.
| N
|
Cela semble totalement testable. MS© Sharepoint© n'est pas prêt d'être certifié intégralement...
|
↑
Processus métier
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence
| Test : N (non testable)/P (partiellement testable) / O (testable)
| Observations : Observations éventuelles
|
11.8.1
| Le SAE devrait permettre à un utilisateur qui est autorisé à modifier le niveau de sécurité d’un document, d’un dossier ou d’une série, de vérifier le niveau existant et les autorisations dans le déroulement normal du processus de modification.
| O
|
Cette exigence est liée aux exigences du chapitre 10.13 - Niveaux de sécurité, qui est un module optionnel.
|
↑
11.8.2
| Quand un administrateur est avisé que le niveau de sécurité d’un document a été dégradé (voir 10.13.28), il devrait pouvoir examiner le document et/ou ses métadonnées dans le déroulement normal du processus.
| O
|
Voir remarque de l'exigence précédente.
|
↑
11.8.3
| En cas de création d’un nouveau dossier, sous-dossier ou volume destiné à un contenant physique, le SAE devrait permettre à l’utilisateur d’imprimer une étiquette pour ce contenant physique dans le déroulement normal du processus.
| O
| Ceci suppose la production d’une étiquette comportant les métadonnées essentielles pour la gestion de l’entité physique, c’est-à-dire (liste non exhaustive) :
- l’intitulé ;
- l’identifiant système ;
- le code de classement ;
- la date d’ouverture ;
- le niveau de sécurité (le cas échéant) ;
- la localisation (l’adresse).
|
↑
11.8.4
| Lorsqu’un utilisateur qui supprime une information est averti de l’existence de liens (voir section 9.3), il devrait pouvoir voir ces liens et l’information liée et/ou les métadonnées dans le déroulement normal du processus.
| O
|
|
↑
11.8.5
Le SAE devrait permettre à un utilisateur qui masque un document d’effectuer les gestes suivants dans le déroulement normal du processus :
- masquer le document ;
- choisir à quel niveau du plan de classement l’extrait sera classé et l’archiver ;
- lier l’extrait à l’original ;
- lier l’original à l’extrait.
| O
|
La 7.1.1 suggère qu'un extrait n'a pas de code de classement propre, auquel cas il serait impossible de répondre au deuxième point. Voir également la 9.3.14.
|
↑
11.8.6
| Quand un utilisateur déclare un document, le SAE devrait lui permettre de vérifier si le document n’a pas déjà été archivé, dans le déroulement normal du processus.
| O
| Ceci devrait être valable pour tout type de document.
|
↑
11.8.7
| Le SAE devrait avertir un utilisateur qui archive un document si celui-ci a déjà été archivé, en lui indiquant son niveau de classement (série, dossier, etc.) et offrir la possibilité à l’utilisateur de poursuivre ou d’annuler la capture.
| O
|
L'un des grands rêves de l'utilisateur de GED (d'une manière générale). La technique la plus classique consiste à vérifier un condensat[3] du fichier. Cela garantit que le même fichier n'est capturé qu'une fois, mais n'empêche pas un même document, sous plusieurs formats différents. L'un des moyens est de comparer la référence externe du document, mais cela reste soumis à la qualité de la saisie - automatisée ou non.
|
↑
11.8.8
Quand un utilisateur capture un document, le SAE devrait lui permettre de :
- naviguer dans le plan de classement (pour trouver la série et le dossier pertinent) ;
- regarder les métadonnées (autorisations, mots-clés, descripteurs, etc.) de toute série ou dossier ;
avant la fin de la capture dans le déroulement normal du processus.
| O
|
Cela serait presque à considérer comme obligatoire : puisque l'utilisateur n'a par défaut pas la possibilité de modifier le document après sa capture (que ce soit son emplacement ou ses métadonnées), il faut lui donner les moyens d'effectuer une capture correcte.
|
↑
11.8.9
Quand un utilisateur a à l’écran une série, un dossier, un document, etc., dans le cadre d’une requête, en navigant dans le plan de classement ou dans un autre contexte, il devrait pouvoir effectuer directement toute opération autorisée sur cette entité, sans avoir besoin de se déplacer ailleurs dans le SAE, à savoir :
- l’ouvrir ;
- repérer les entités « mères » dans le plan de classement ;
- voir ses métadonnées ou l’historique des événements ;
- voir et consulter ses liens ;
- l’envoyer par messagerie ;
- changer son niveau de sécurité ;
- voir les utilisateurs et les profils qui y ont accès ;
- l’imprimer ou le restituer ;
- le masquer ;
- changer sa localisation ou le supprimer.
| O
|
Cette exigence résume la liste des actions possibles qu'un utilisateur doit pouvoir faire lorsqu'il navigue dans le plan de classement.
|
↑
11.8.10
| Le SAE devrait permettre à un utilisateur de modifier le niveau de sécurité d’un document, d’un dossier ou d’une série, y compris la mise à jour de toutes les métadonnées, en une seule opération.
| O
|
Exigence liée au module optionnel 10.13 - Niveaux de sécurité.
|
↑
11.8.11
| Si un thésaurus conforme à ISO 2788 ou ISO 5964 est intégré au SAE, le SAE devrait permettre à un utilisateur qui saisit ou met à jour un mot-clé (ou une autre métadonnée relevant du thésaurus) d’utiliser toutes les fonctions du thésaurus (termes plus larges, restreints, liés et synonymes) dans le déroulement normal du processus.
| O
| À noter que 8.1.18 comporte une exigence connexe pour la recherche.
Voir commentaire de la 11.1.6.
|
↑
Notes
- ↑ Rappel sur les virus et chevaux de Troie du CERTA.
- ↑ Voir OAIS chap. 4.2.2.3, notamment les schémas 4-15, 4-16, 4-17 et 4-18.
- ↑ Page d'homonymie de Wikipédia, voir la référence du domaine cryptographique.
↑
