Exigences optionnelles du MoReq2/Chapitre 3 : Plan de classement et organisation des dossiers
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
COMPLET
Liste
| Configurer le plan de classement | Séries et dossiers | Volumes et sous-dossiers | Maintenance du plan de classement | ||
|---|---|---|---|---|---|
É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.
Configurer le plan de classement
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
3.1.6
| Le SAE devrait permettre la gestion de séries spécifiques par des profils utilisateurs et/ou un groupe particulier d’utilisateurs. | O | Dans l’exigence ci-dessus, « gestion » a le même sens que dans l’exigence précédente. Deux cas de figure sont prévus :
|
3.1.7
| Le SAE ne devrait pas limiter le nombre de niveaux de la hiérarchie du plan de classement. | P | Dans la plupart des cas, le nombre des niveaux nécessaires ne devrait pas excéder dix.
Voir la 3.1.4 dans les exigences obligatoires. |
3.1.10
| Le SAE devrait permettre l’insertion de notices (appelées descriptions) pour toutes les séries, dossiers, sous-dossiers et volumes. | O | Ces libellés descriptifs ont pour but de préciser ce que doivent contenir ou ne pas contenir les séries et les dossiers, dans l’intérêt des utilisateurs.
S'agit-il de métadonnées ? DC ? La métadonnée la plus proche et commune à toutes les agrégations est la M047 - Description.résumé.description. |
3.1.12
| Le SAE devrait permettre l’import de tout ou partie du plan de classement, au moment de la configuration ou à un autre moment. | O | Cette exigence vise à permettre la création d’un plan de classement pendant que la configuration du SAE est, et avant sa mise en service pour l’archivage. L’import d’une partie de plan correspond à l’ajout à un plan existant ou à la création d’un nouveau plan de classement qui n’existe pas. |
3.1.13
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE importe tout ou partie d’un plan de classement, il doit permettre l’import des métadonnées associées, des règles de conservation/destruction et des historiques des événements, s’ils existent. | O | Idéalement, le plan de classement importé aura ses métadonnées de séries et ses règles de conservation/destruction. Il peut arriver qu’ils manquent ou soient incomplets. |
3.1.14
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE importe les métadonnées d’un plan de classement, il doit rejeter toute série dépourvue de libellé et produire un rapport d’anomalie pour l’administrateur énumérant les séries ainsi rejetées. | O | Dans un SAE non conforme à MoReq2, on peut avoir une série sans libellé (valeur nulle) ; mais une telle série ne saurait être utilisée dans un SAE conforme à MoReq2. |
3.1.15
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
Quand le SAE importe les métadonnées d’un plan de classement, il doit attribuer à chaque série importée un code hiérarchique selon le choix opéré par l’administrateur parmi les possibilités suivantes :
| P | Lorsqu’une hiérarchie importée comporte déjà des codes de séries hiérarchiques (ex : 4/6/4) il se peut que ces codes ne puissent pas être utilisés dans le SAE si la cohérence et l’unicité ne sont pas garanties.
Il existe de nombreux scénarios d’import, avec divers niveaux d’incompatibilité entre les plans hiérarchiques numériques. MoReq2 ne préjuge pas des résultats du choix d’une option logiquement impossible à cause d’une incompatibilité des plans. Si les codes existants sont inexploitables, ils peuvent être néanmoins conservés comme métadonnée dénommée « ancien code de classement ». Voir également la 3.2.3. |
3.1.16
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE importe les métadonnées et les règles de conservation/destruction d’un plan de classement, il est impératif de les valider avec les mêmes règles que pour un plan de classement créé manuellement (voir chapitre 12). Si ce processus de validation détecte des erreurs (par exemple l’absence de métadonnées obligatoires, ou des erreurs de format), il doit le signaler à l’administrateur qui supervise l’import, en indiquant les métadonnées en cause.
Le rapport à l’administrateur n’exige pas que le processus d’import se fasse en direct ou en temps réel ; on peut admettre une opération décalée (batch). | O | Dans l’idéal, le plan de classement importé aura des métadonnées (les métadonnées de séries) parfaitement conformes au modèle de métadonnées de MoReq2. D’autres fois, les métadonnées ne seront pas conformes. Dès lors, plusieurs cas de figure sont possibles (MoReq2 n’en préconise aucun) :
|
3.1.17
| Le SAE devrait pouvoir effectuer l’export de tout ou partie du plan de classement. | O |
Voir la 5.1.9. |
3.1.18
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE permet l’export de tout ou partie du plan de classement, les métadonnées associées, sélectionnées par un administrateur habilité, doivent être incluses. | O |
3.1.19
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE permet l’export de tout ou partie du plan de classement, les règles de conservation/destruction associées, sélectionnées par un administrateur, doivent être incluses. | O |
3.1.20
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE permet l’export de tout ou partie du plan de classement, l’export doit inclure tout ou partie de l’historique des événements, au choix de l’administrateur. | O |
En somme, un export doit comprendre :
|
3.1.21
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE permet un export (pour une des raisons ci-dessus), il doit utiliser un procédé proprement documenté pour relier les entités entre elles. | O | La documentation du procédé doit dire comment les documents, dossiers, séries, etc. se présentent ainsi que leurs interrelations. Voir aussi 3.1.22. |
3.1.22
| Quand le SAE permet un export (pour une des raisons ci-dessus), il devrait exporter l’information en XML ou dans un format ouvert normalisé équivalent. | O |
Voir également la 3.2.16. |
3.1.23
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE permet la copie de tout ou partie du plan de classement, les métadonnées associées doivent être incluses. | O |
Voir l'exigence 3.4.4. La formulation est ambiguë : cela veut-il dire qu'au final ce sont les métadonnées sources qui persistent, ou bien celles de la nouvelle agrégation mère ? |
3.1.24
Exigence obligatoire liée à la mise en œuvre d'une exigence optionnelle.
| Quand le SAE permet la copie de tout ou partie du plan de classement, les règles de conservation/destruction associées doivent être incluses. | O |
Voir observations de la 3.1.23. |
3.1.26
| Le SAE devrait permettre l’élaboration et l’utilisation simultanée de plusieurs plans de classement. | O | Dans la plupart des cas, un seul plan de classement pour le classement initial de tous les dossiers dans le SAE suffira. Cette exigence vise à permettre le rattachement de certains dossiers à des plans de classement différents au sein du SAE. Ceci peut être nécessaire à la suite d’une fusion entre deux entreprises ou organisations, ou lorsque les différents fonds d’une même structure requièrent des systèmes de gestion différents.
Correspond pour l'instant aux collections de Maarch Core. Voir également la 3.1.3. |
Séries et dossiers
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
3.2.7
Le SAE devrait permettre de configurer le code de classement à partir :
| O |
Voir également la 3.2.6. |
3.2.12
| Tout ajout aux métadonnées héritées d’une série devrait être hérité par défaut par toutes les séries et dossiers « filles/fils ». | O |
Catégorie « Lapalissade » : N'est-ce pas le propre d'une métadonnée « héritée » d'être... « héritée » ? |
3.2.13
| Le SAE devrait supporter l’introduction d’un vocabulaire contrôlé conforme à ISO 2788[1] pour les métadonnées de séries et de dossiers, en plus des autres exigences de cette section. | O | Les exigences 3.2.13 et 3.2.14 sont identiques à ceci près que la première vise les thésaurus monolingues et la seconde les thésaurus multilingues. |
3.2.14
| Le SAE devrait supporter l’introduction d’un vocabulaire contrôlé conforme à ISO 5964[2] pour les métadonnées de séries et de dossiers, en plus des autres exigences de cette section. | O | Les exigences 3.2.13 et 3.2.14 sont identiques à ceci près que la première vise les thésaurus monolingues et la seconde les thésaurus multilingues. |
3.2.16
| Le SAE devrait pouvoir exporter une liste, ou un répertoire, de tous les dossiers ou des dossiers relevant d’une série donnée (avec ses séries filles) au format XML et/ou dans un format lisible par l’homme. | P | Stricto sensu, il faut donc comprendre "une exportation sans les documents portés par la série exportée".
Apparemment redondant avec la 3.1.22. |
Volumes et sous-dossiers
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
3.3.17
| Le SAE devrait permettre à l’administrateur de créer un modèle de sous-dossier pour une série donnée, qui indiquerait les sous-dossiers à créer automatiquement pour chaque nouveau dossier créé dans cette série. | O | Ceci vaut principalement pour les dossiers sériels. Par exemple, dans une compagnie d’assurance, le modèle pourrait indiquer, pour la série des polices d’assurance client, les sous-dossiers suivants : police et avenants, correspondance interne, correspondance avec le corps médical, facturation, autre correspondance client. Dès lors, tout nouveau dossier créé dans cette série comporterait automatiquement ces sous-dossiers.
N.B. : Il est plus que probable que le premier mot « sous-dossier » a été mal accordé, car la version anglaise écrit « sub-files ». Il faudrait donc comprendre : « créer un modèle de sous-dossiers pour une série donnée », ce qui prend tout son sens dans la suite de l'exigence et du commentaire. Quel besoin y a-t-il de distinguer cette exigence de celles du chapitre 10.5 ? Déjà intégré dans Maarch Core via les FolderTypes. À adapter. |
Maintenance du plan de classement
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
3.4.4
| Le SAE devrait permettre à un administrateur de dupliquer une série du plan de classement en une seule opération. | O | « Dupliquer » signifie ici créer une copie de la série avec tout son contenu à un autre point du plan de classement tout en laissant la série dupliquée à sa place. La copie peut se trouver au même niveau du plan de classement ou à un autre niveau. La duplication impose plusieurs exigences complémentaires décrites plus loin.
Cette option est prévue pour la duplication de branches d’un plan de classement, opération requise par exemple lors de la conception d’un plan de classement dont la structure n’est pas fonctionnelle. Le recours à un export suivi d’un import ne sera pas considéré suffisamment simple pour répondre à cette exigence. Noter que cette dernière remarque est redondante avec l'exigence 3.4.6. |
3.4.17
| Le SAE devrait permettre à un administrateur de déclarer « inactif » une série ou un dossier pour éviter que de nouveaux dossiers soient ajoutés à cette série ou de nouveaux documents à ce dossier. | O |
Cette exigence laisse l'auteur de ces lignes perplexe (après vérification, le terme vient bien de la version anglo-saxonne originelle) : en plus de l'ouverture et de la clôture d'une division, il serait donc possible de la "désactiver" ? L'auteur a beau chercher dans toute la documentation, il n'y a aucune trace d'une définition de "désactivation" (sauf pour un utilisateur dans la liste des métadonnées[3]). Les tests donnent plus d'indications sur l'objectif d'un tel marquage. Le double-emploi avec la clôture est on ne peut plus ambigu. |
3.4.18
| Le SAE devrait permettre à un administrateur de supprimer une série vide. | O |
L'emploi de vide est ambigu :
Les tests suggèrent qu'il s'agit de la première hypothèse. Mériterait d'être dans le chapitre sur les séries et dossiers, à l'instar des exigences de suppression de volume (qui sont dans le chapitre sur les sous-dossiers et les volumes). |
3.4.21
Le SAE devrait être capable de clore un volume électronique automatiquement sur la base de critères spécifiques définis lors de la configuration ; ce sera au minimum :
| O | D’autres critères peuvent être souhaitables dans certains cas, par exemple quand la taille du volume atteint la capacité de stockage d’un disque amovible... |
3.4.23
| Le SAE devrait permettre aux utilisateurs de créer des références croisées (liens de type « voir aussi ») entre les dossiers. | O |
Mériterait d'être dans le chapitre sur les séries et dossiers. |
3.4.24
| Le SAE devrait permettre de créer des entrées multiples pour un document électronique archivé dans plusieurs séries, dossiers, sous-dossiers ou volumes, sans dupliquer le document ou la pièce qui le constitue. | O | MoReq2 ne précise pas la manière de procéder. Une des façons de répondre à cette exigence peut être l’utilisation de pointeurs lors de la capture de plusieurs documents comportant la même pièce.
Attention : Cela irait à l'encontre de ce qui est suggéré par la 3.4.9. La duplicité d'un document pourrait donc être remise en question ? Point à débattre car conséquences techniques très importantes. Il est également suggéré qu'une même pièce (=composant) pourrait être référencée dans plusieurs documents différents, ce qui ne semble pas correspondre à la pratique puisque 2 documents électroniques différents, capturés dans le SAE, auront vraisemblablement 2 contenus électroniques ne référençant pas les mêmes fichiers. Cette exigence apporte donc matière à débats. |
3.4.26
| Le SAE devrait fournir des fonctionnalités de reporting adaptées à la vie du plan de classement. | P |
Presque dans la catégorie des truismes... Disons pour mettre tout le monde d'accord qu'elle figure dans la catégorie : « Cela va sans dire mais cela va mieux en le disant. » |
3.4.27
| Tout utilisateur travaillant sur une série, un dossier ou un document devrait pouvoir accéder à son contexte, c’est-à-dire aux métadonnées et au dossier ou à la série mère ; cet accès aux entités mères doit se faire à partir de la série, du dossier ou du document. | O |
Domaine ergonomique. |
