Exigences obligatoires 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.1
| Le SAE doit intégrer et être compatible avec le plan de classement métiers. | N | Cette exigence n’est pas testable en général ; elle figure ici comme un rappel aux utilisateurs de MoReq2 du besoin d’aligner le plan de classement géré par le SAE sur les besoins métier. Ces besoins devraient se retrouver dans l’organisation des documents à l’extérieur du SAE.
Toujours vérifié par Maarch en intégration. Les folders permettent tout type d'organisation. |
3.1.2
Le SAE doit maintenir son intégrité (intégrité relationnelle ou autre) en permanence, indépendamment :
| P | Une rupture de continuité du SAE ou de ses bases de données qui résulterait de l'action d'un utilisateur ou d'une panne logicielle doit être impossible.
Toujours vérifié par les logiciels de Maarch jusqu'à présent. |
3.1.3
| Le SAE devrait permettre aux administrateurs de doter chaque plan de classement d’un titre et d’un descriptif, et doit automatiquement attribuer un identifiant à chaque plan de classement.
Ces métadonnées faciliteront les fonctions telles que l’export des plans de classement et des documents archivés. | O |
Bien que commençant par une forme au conditionnel qui aurait pu inciter à classer cette exigence parmi les exigences optionnelles, la présence en seconde partie de phrase d'une forme à l'indicatif conclut à classer cette exigence parmi les exigences obligatoires. Voir également la 3.1.26. |
3.1.4
| Le SAE doit être capable de supporter un plan de classement représentant des dossiers et des documents organisés en séries hiérarchisées. | O | L’utilisation d’un plan de classement hiérarchique est obligatoire pour la conformité à MoReq2, afin de permettre l’héritage des règles de conservation/destruction ou d’autres métadonnées, et faciliter la navigation.
Un plan de classement à trois niveaux est un minimum ; davantage de niveaux seront nécessaires dans de nombreux environnements. De ce dernier commentaire il est possible d'extraire 2 exigences complémentaires :
Cette seconde exigence est couverte par la 3.1.7 dans les exigences optionnelles. Voir également la 3.2.15. |
3.1.5
| Le SAE doit permettre d’attribuer la gestion du plan de classement à un seul administrateur, en liaison avec l’exigence 3.1.6. | O | Dans la phrase ci-dessus, « gestion » renvoie aux opérations décrites aux sections 3.1 et 3.4. |
3.1.8
| Le SAE doit permettre la création du plan de classement au moment de la configuration afin qu’il soit prêt pour la capture et/ou l’importation des documents électroniques. | O | Cette exigence vise à permettre l’élaboration du plan de classement pendant que le SAE est configuré, et avant sa mise en service pour l’archivage des documents.
Natif dans Maarch Core. |
3.1.9
| Le SAE doit offrir un ou des mécanismes de nommage à définir par l’administrateur au moment de la configuration. | O |
On suppose qu'il s'agit du nommage du "plan de classement", donc des séries, dossiers et autres volumes. Cela mérite d'être précisé, et c'est ce qui est testé dans le test correspondant. |
3.1.11
| Le SAE doit être capable d'importer et d'exporter des documents, etc. conformément au schéma XML pour MoReq2. | O |
Cette exigence est réécrite suite à la publication du schéma XML en question. Texte original : Si un schéma XML pour MoReq2 est publié, le SAE devra être capable d’importer et d’exporter des documents, etc. conformément à ce schéma. Cette exigence n'est-elle pas redondante avec la 5.3.1 ? |
3.1.25
| Le SAE doit permettre aux administrateurs d’ajouter de nouvelles séries à n’importe quel point du plan, dès lors qu’il n’y a ni dossiers ni documents à cet endroit. | O | MoReq2 n’autorise pas la coexistence des séries et des dossiers au même niveau au sein d’une série (les dossiers et les séries ne peuvent être mêlés à un même nœud de la hiérarchie du plan de classement), car ce serait contraire aux bonnes pratiques de l’archivage. |
Séries et dossiers
Complet
Voir également la 3.4.20 et la 5.1.13.
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
3.2.1
| Le SAE doit pouvoir effectuer la capture, la maintenance et la restitution des métadonnées pour les dossiers et les séries du plan de classement conformément au modèle de métadonnées de MoReq2. | O | L'exigence exclut les sous-dossiers et les volumes (pas d'équivalent dans le chapitre correspondant).
Il manque la précision de savoir quel profil fait ces actions. Noter que seul un administrateur a l'accès en modification à une série (voir 3.1.25). |
3.2.2
| Le SAE doit restreindre la possibilité d’ajouter des métadonnées aux dossiers et aux séries selon le modèle de métadonnées de MoReq2. | N | Trois compréhensions possibles :
De manière très opportune, ce n'est heureusement pas testable. |
3.2.3
| Le SAE doit proposer un mécanisme d’attribution automatique d’un code de classement hiérarchique (lorsque ce code n’existe pas déjà – voir 3.1.15) à toute série, dossier, sous-dossier et volume au sein du plan de classement. | O | Voir aussi 7.1.1.
Noter qu'il ne s'agit pas uniquement des séries et dossiers. Voir également la 3.3.11. |
3.2.4
| Le SAE doit autoriser les utilisateurs à attribuer un titre à toute série, dossier, sous-dossier ou volume électronique. | O | Cette exigence s’applique aux dossiers non sériels. Dans un environnement de dossiers sériels, un processus de nommage alternatif est nécessaire. Ceci est précisé à la section 10.5.
Il convient également de préciser que pour qu'un utilisateur puisse attribuer un titre à un objet de classement, il faut qu'il en ait les droits. Par ailleurs, un utilisateur n'a pas le droit de créer une série (voir 3.1.25), cela suggèrerait donc qu'il est possible de créer une série sans lui attribuer de titre ? |
3.2.5
| Il doit être possible d’utiliser à la fois le code de classement et le titre du dossier, séparément ou ensemble. | O |
Comprendre : lors d'une recherche (c'est notamment ce qui est suggéré par les tests). |
3.2.6
| Le SAE doit permettre à un administrateur de configurer le code de classement au moment de la configuration ou plus tard. | O |
Voir également la 3.2.7. |
3.2.8
| Le SAE doit enregistrer les dates d’ouverture et de clôture d’une série ou d’un dossier comme métadonnées de la série ou du dossier. | O | Les dates d’ouverture et de clôture d’une série ou d’un dossier fournissent une information contextuelle importante pour les documents qui y sont rattachés.
Tant qu’une série ou un dossier est ouvert, il est possible d’y rattacher des documents. Une fois clos, il n’est plus possible d’y capturer des documents. De cette exigence et de ses commentaires peuvent être déduites les exigences suivantes :
Voir aussi la 3.2.10 ainsi que la 3.3.9, la 3.3.10 et la 3.3.12. |
3.2.9
| Le SAE doit enregistrer la date de création d’une nouvelle série, d’un nouveau dossier, sous-dossier ou volume comme métadonnée de la série ou du dossier.
Dans le cas de dossiers physiques, la date d’ouverture peut être antérieure à la date d’enregistrement dans le SAE. Cela arrive quand un dossier papier est créé et ouvert sous forme physique, avant d’être créé dans le SAE. | O | Dans le cas de dossiers électroniques, la date d’ouverture peut être antérieure à la date d’enregistrement dans le SAE. Cela arrive quand un dossier est importé d’un autre système dans le SAE.
Les termes sont ambigus : s'agit-il de la métadonnée de l'agrégation mère dans laquel serait créée une nouvelle agrégation fille ? dans ce cas il devrait y avoir une métadonnée du type "création fille" multivaluée ? ou bien s'agit-il de la métadonnée de l'agrégation nouvellement créée ? C'est cette seconde solution qui sera retenue. L'exigence et son commentaire appelle les exigences complémentaires suivantes :
Voir également la 3.3.4. |
3.2.10
| À l'ouverture d'une nouvelle série ou d’un nouveau dossier, le SAE doit automatiquement enregistrer comme métadonnées les attributs hérités de sa position dans le plan de classement. | O | Par exemple, si un dossier intitulé « Réunions publiques » se situe dans une série intitulée :
Plan de développement régional : Consultation publique : Réunions publiques et que l’administrateur ajoute un nouveau dossier intitulé « Consultations écrites » au même niveau que « Réunions publiques », le nouveau dossier doit hériter automatiquement du préfixe « « Plan de développement régional : Consultation publique. À noter que les métadonnées héritées ne doivent être saisies explicitement mais récupérées implicitement. Voir le détail en annexe 9.3. Les termes employés sont ambigus, que ce soit dans la version française ou dans la version originale. Cette exigence parle d'une information de position liée à la concaténation des titres (au sens M003 - Description.titre). Les seules métadonnées autres que se référant au code de classement liées à la « position » (« position » en V.O.) d'une entité dans le plan de classement sont les 086 - Description.lieu.localisation_proximité (« Description.place.current_location » en V.O.) et M122 - Description.lieu.localisation_normale (« Description.place.home_location » en V.O.). Malheureusement, ces métadonnées sont liées au lieu de stockage physique de l'entité (cela apparaît très précisément dans la V.O. : « current physical location of a physical entity »), plutôt qu'à une notion de place de l'entité dans la hiérarchie du plan de classement (miroir « humainement lisible » du code de classement). En résumé, il n'existe pas de métadonnée prévue par le MoReq2 où stocker cette information de position liée au titre. La notion de préfixe (« prefix » en V.O.) est pourtant claire, mais ne se retrouve nulle part dans les métadonnées de la version française, ni dans celles de la version originale. Voir au sujet de l'héritage la 3.2.11. Voir également la 3.2.8. |
3.2.11
| Le SAE doit autoriser l’administrateur à modifier les valeurs héritées, dans la mesure où le modèle de métadonnée de MoReq2 le permet. | O | Les valeurs héritées sont souvent des valeurs par défaut ou une valeur initiale. Cela peut être modifié, dès lors que le modèle de métadonnées est respecté.
Le caractère obligatoire de cette exigence doit être examiné, compte tenu des importantes conséquences techniques qu'elle risque d'engendrer, mises en regard du bénéfice fonctionnel perçu. Voir par exemple la 3.3.2. |
3.2.15
| Le SAE ne doit imposer aucune limitation au nombre de séries ou de dossiers à créer. | P |
À mettre en regard des 3.1.4 et consorts, ce qui suggère que nous parlons ici d'une limitation au sein d'un même niveau, donc sur un plan "horizontal". |
3.2.17
| Le SAE doit permettre à l’administrateur de configurer une série de façon à ce qu’elle accepte ou non qu’on y rattache directement des documents. | O | Autrement dit, le système doit pouvoir être configuré pour que les documents ne soient pas rattachés à un dossier, sous-dossier ou volume.
Il est étonnant de trouver cette exigence obligatoire, vu l'aspect exceptionnel donné au rattachement des documents directement à une série[1]. |
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.1
| Il doit être possible pour un administrateur, au moment de la configuration du SAE ou plus tard, de supprimer la possibilité de créer des sous-dossiers et/ou des volumes dans les dossiers du plan de classement. | O |
Cette exigence implique que par défaut il est possible d'ajouter des sous-dossiers et des volumes. Cela est néanmoins relativisé par les deux exigences suivantes. Voir observations de la 3.3.2 et de la 3.3.3, également la 3.4.7. |
3.3.2
| Il doit être possible pour un administrateur au moment de la configuration du SAE ou plus tard de n’autoriser la création de sous-dossiers dans les dossiers que dans une zone donnée du plan de classement. | O |
Cette exigence n'a de sens que combinée avec la précédente, ou plus exactement, la précédente exigence est résumée par « tout autorisé sauf » tandis que celle-ci est résumée par « tout interdit sauf ». Ces deux politiques peuvent difficilement cohabiter, ou en tout cas la réalisation de la seconde après le choix de la première devient rapidement fastidieuse. Cela revient exactement à modifier la valeur d'une métadonnée (l'interdiction de créer des sous-dossiers et/ou des volumes) en un point du plan de classement (voir 3.2.11), si cette métadonnée existait : noter que la métadonnée « peut contenir des sous-dossiers[2] » n'est pas indiquée dans les métadonnées officielles du MoReq2. Voir observations de la 3.3.3, également la 3.4.7. Exigence candidate pour la catégorie « quadricapillosectomie[3] ». |
3.3.3
| Il doit être possible pour un administrateur au moment de la configuration du SAE ou plus tard de n’autoriser la création de volumes dans les dossiers que dans une zone donnée du plan de classement. | O | Le but de ces trois exigences est de permettre aux entreprises/organisations d’autoriser ou d’interdire l’utilisation de sous-dossiers et/ou de volumes dans différentes parties du plan de classement. Cette possibilité procure une grande souplesse mais qui peut aussi engendrer de la complexité et de la confusion pour les utilisateurs.
Quand une partie du plan de classement accepte les sous-dossiers, tous ses dossiers doivent contenir au moins un sous-dossier. Quand une partie du plan de classement accepte les volumes, tous ses dossiers (ou sous-dossiers) doivent contenir au moins un volume. L’essentiel est que le système soit transparent pour les utilisateurs, par exemple :
L’idée est ici de souligner qu’un SAE ne doit pas imposer cette structure de « dossier, sous-dossier, volume ». Il doit permettre l’usage de sous-dossiers et de volumes, tout en permettant aux utilisateurs de se limiter aux dossiers si cela leur convient mieux. Le fondement de tout ceci est que seul l’utilisateur voit ce qui est important du point de vue des processus métier et n’est pas embarrassé par des choix pouvant prêter à confusion.
Ces commentaires impliquent les exigences suivantes :
La somme de tous ces commentaires amène à classer ces 3 exigences, avec leurs commentaires originaux, dans la catégorie « quadricapillosectomie », avec mention spéciale du jury pour avoir séparé en deux les exigences 3.3.2 et 3.3.3 là où l'exigence 3.3.1 réunit sous-dossiers et volumes. Voir également la 3.4.7. |
3.3.4
Le SAE doit prendre en compte le concept de volume électronique ouvert et clos comme suit :
| O |
Il peut y avoir confusion : la formulation peut laisser supposer qu'un volume peut être créé sans être ouvert, et que l'ouverture est postérieure à la création. Hors, ce n'est pas le cas : ouverture=création[4]. Éventuellement, il est possible de rencontrer l'inverse : une date de création postérieure à la date d'ouverture (cas d'importations ou de dossiers physiques, voir 3.2.9). Cela sous-entend donc que la création d'un nouveau volume (donc son ouverture) dans un dossier ou un sous-dossier entraîne de facto la fermeture du précédent volume ouvert. Cette exigence, qui en inclut en fait plusieurs, nécessiterait donc d'être segmentée de la manière suivante :
|
3.3.5
| Le SAE doit empêcher un utilisateur d’ajouter un document électronique à un volume clos. | O |
Il est étonnant que cette exigence ne concerne que les volumes : il serait donc possible d'ajouter un document électronique à une série close ? Bien sûr que non. Cela pourrait être vrai dans un SAE où les volumes ont été imposés (voir 3.3.3), donc où il serait impossible de capturer un document hors d'un volume, mais cette exigence concerne tout type d'agrégation. |
3.3.6
| Le SAE doit permettre à l’administrateur d’ajouter un volume électronique à n’importe quel sous-dossier électronique qui n’est pas clos. | O | Le processus d’ajout d’un nouveau volume consiste à clore le volume courant et à créer un nouveau volume, ouvert.
À rapporter à la 3.3.4. La formulation implique qu'il n'est possible d'ajouter des volumes qu'à des sous-dossiers, hors il est également possible d'en rajouter à des dossiers. Il faut remarquer encore que la formulation sous-entend que seul un administrateur peut ajouter un volume, donc clore le précédent, ce qui ne paraît pas très fonctionnel[5]. Enfin, la formulation sous-entend que l'administrateur « ne peut qu'ajouter des volumes dans des sous-dossiers ouverts » : heureusement pour lui et pour le SAE en général, il peut - doit ! - créer un plan de classement de A à Z (voir 3.1.8, 3.1.25 ainsi que l'ensemble du chapitre 3.4). Tout cela mériterait d'être clarifié :
|
3.3.7
| Le SAE doit permettre à l’administrateur d’ajouter un sous-dossier électronique à n’importe quel dossier électronique qui n’est pas clos. | O |
Mêmes remarques que la 3.3.6. Peut en outre dépendre de la configuration (voir 3.3.1 et 3.3.2). |
3.3.8
| Le SAE doit permettre aux utilisateurs de clore un sous-dossier à tout moment. | O |
3.3.9
| Le SAE doit enregistrer la date d’ouverture du nouveau volume ou du nouveau sous-dossier comme métadonnée. | O |
Voir également la 3.2.8. |
3.3.10
| À l’ouverture d’un nouveau volume ou sous-dossier, le SAE doit lui attribuer automatiquement, par héritage, les métadonnées communes du dossier, comme l’indique le modèle de métadonnées de MoReq2. | O | Les documents archivés dans un volume doivent être accessibles, que le volume soit ouvert ou clos.
Il n'y a nulle part de définition des « métadonnées communes » mais il est possible de déduire qu'il s'agit des métadonnées dont une agrégation fille hérite de son agrégation mère au moment de sa création. Voici le tableau comparatif des métadonnées des 3 types d'agrégation :
L'héritage suit le même principe que pour les divisions de niveau supérieur. Le commentaire appelle l'exigence supplémentaire suivante :
Il faut relever d'une part que cette exigence secondaire n'a que peu à voir avec l'originale, et d'autre part que l'apparition de cette nouvelle exigence est liée essentiellement à un glissement sémantique de l'anglais (emploi de l'auxiliaire "can") au français (emploi du verbe "devoir"). Ceci étant, cette exigence paraît tout à fait justifiée - même mal placée - mais recouvre une réalité qui mérite peut-être d'être mise en opposition avec l'usage des autres divisions : cela veut-il dire que lorsque ces dernières (série, dossier et sous-dossier) sont clôturées les documents qu'elles contiennent ne doivent plus être accessibles ? L'une des exigences secondaires de la 3.2.8 parle de "capture", mais pas de "consultation". En revanche, la 3.4.22 implique clairement que les documents sont accessibles (modulo les règles d'accès, bien sûr) que l'agrégation (même un volume) à laquelle ils appartiennent soit ouverte ou fermée. |
3.3.11
| Quand un nouveau volume est ouvert, le SAE doit automatiquement lui attribuer un identifiant qui est unique au sein de son sous-dossier. | P | L’identifiant pourrait être une simple nombre séquentiel, recommençant à 1 pour chaque sous-dossier.
Il y a ambiguïté par l'emploi du terme « identifiant », qui correspond à la métadonnée M020 - Identification.identifiant_système, alors que le sujet de l'exigence est clairement le « code de classement » relatif (par opposition au « code de classement complet », absolu) correspondant à la métadonnée M011 - Description.classement.code classement. Il reste possible que l'« identifiant » en question soit un « complément » au titre (M003 - Description.titre) du volume, qui reprendrait alors - par exemple - le titre du sous-dossier auquel il appartient en le complétant d'un « numéro d'identification ». S'il s'agit du code de classement, il y a redondance avec les exigences de numérotation automatique et systématique : l'unicité de la numérotation de toute subdivision au sein de l'ensemble du SAE implique de facto l'unicité au sein d'une série (au sens "branche") de ce même SAE. Voir la 3.2.3, ainsi que les 7.1.2 et 7.2.2. En résumé :
|
3.3.12
| Le SAE doit enregistrer la date de clôture des volumes et des dossiers comme métadonnées. | O |
|
3.3.13
| Lorsqu’il classe un document, l’utilisateur doit voir apparaître par défaut le volume le plus récemment créé dans le sous-dossier sélectionné. | O |
Exigence de couche "Vue", totalement inutile au niveau du modèle. En outre, elle doit être complétée par "quand il existe des volumes dans le dossier ou sous-dossier", car ce n'est pas systématiquement le cas. |
3.3.14
| Le SAE doit permettre la création de plusieurs sous-dossiers ouverts concomitamment au sein d’un même dossier. | O |
Comportement identique à une série ou un dossier. Exigence à mutualiser. Ensuite, le lecteur ne doit pas perdre de vue que "création" et "ouverture" recouvrent exactement la même réalité dans un SAE[7]. "Créer" plusieurs sous-dossiers au sein d'un même dossier équivaut donc strictement à "Ouvrir" plusieurs sous-dossiers. La seule différence avec les volumes, mais qui mérite d'être notée et qui est certainement l'objet de cette exigence, est qu'au sein d'un même dossier il peut y avoir plusieurs sous-dossiers ouverts à un moment donné, tandis qu'au sein d'un même dossier ou sous-dossier il ne peut y avoir qu'un seul (ou aucun) volume ouvert à un moment donné. L'exigence mérite donc d'être remplacée par :
|
3.3.15
| Le SAE doit permettre à un administrateur de supprimer un volume vide. | O |
3.3.16
| Le SAE doit permettre à un administrateur de supprimer un volume vide et de ré-ouvrir le précédent volume du sous-dossier en une seule action, avec enregistrement dans l’historique des événements. | O | Ceci doit permettre de corriger une erreur due à la clôture incorrecte d’un volume.
Cette exigence mériterait d'être décomposée de la manière suivante :
Il est important de comprendre que dans tous les cas cela ne peut pas se faire si la gestion de la fermeture des volumes est automatique : au mieux, le dossier sera réouvert et, puisque la condition qui en a déterminé la clôture n'a pas de raison d'avoir changé, il sera immédiatement re-clos par le SAE. Ce qui est historisé est ambigu : s'agit-il de la ré-ouverture du volume ou bien de l'action complète « suppression + ré-ouverture » ? |
3.3.18
| Le SAE doit automatiquement clore tous les sous-dossiers d’un dossier si leur dossier « père » est clos. | O |
Redondant avec la notion d'héritage des métadonnées. Noter que les volumes ne sont pas mentionnés : cela veut-il dire que la clôture d'un dossier ou d'un sous-dossier contenant des volumes n'implique pas la clôture du volume ouvert ? Dans l'exigence 3.3.16, l'absence de précision sur l'état du père tendrait à abonder dans ce sens, mais ce serait alors un contre-sens archivistique. Le bon sens tend à déduire que lorsque n'importe quelle agrégation est close, toutes ses entités filles sont closes. |
3.3.19
| Le SAE doit permettre aux utilisateurs de clore les volumes individuellement. | O |
Exigence : |
Maintenance du plan de classement
Complet
Voir également la 5.1.23.
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
3.4.1
| Le SAE doit permettre à un administrateur de reclasser une série au sein du plan de classement en une seule opération. | O | « Reclasser » signifie ici reclasser une série ou un dossier, c’est-à-dire le déplacer à un autre point du plan de classement. Le reclassement peut se faire au même niveau ou à un autre niveau du plan. Le reclassement impose plusieurs exigences complémentaires décrites plus loin.
Notion ergonomique laissant une marge de manœuvre à l'implémentation relativement importante. Noter que l'exigence ne parle que de reclasser une série, tandis que le commentaire évoque le reclassement d'une série ou d'un dossier (observation également valable pour la version anglo-saxonne), ce qui est entre autre révélateur de la similitude des 2 concepts. L'amalgame n'est plus fait dans les exigences suivantes. Voir également la 4.2.1. |
3.4.2
| Le SAE doit permettre à un administrateur de regrouper deux séries en une seule opération. | O | Le mot « regroupement » doit s’entendre comme suit : si une série est
regroupée avec une autre,
Il y a donc une notion de série « cible ». Noter que cela devrait être valable également pour les dossiers et sous-dossiers. |
3.4.3
| Le SAE doit permettre à un administrateur de diviser une série en deux en une seule opération. | O | Le mot « division » doit s’entendre comme suit : si une série est divisée :
Les contenus de la série divisée peuvent être de tous types : séries, dossiers ou documents. Noter que cela devrait être valable également pour les dossiers et sous-dossiers. |
3.4.5
| Quand une série est reclassée ou copiée, le SAE doit garantir que les dossiers reclassés ou copiés avec leurs contenus sont reclassés avec les codes de classement correspondant à leur nouvel emplacement dans le plan de classement.
Ceci signifie que toute série, dossier, sous-dossier, volume, document ou composant reclassé ou copié reçoit un nouveau code de classement, complet et signifiant. | O | Les règles d’attribution de nouveaux codes sont les mêmes que lors de la création de nouvelles séries, dossiers, documents, etc. |
3.4.6
| Le SAE ne doit pas imposer à l’administrateur qui reclasse, divise, regroupe ou duplique des séries d’effectuer des exports et imports séparés. | O | Cette exigence vise la facilité d’utilisation ; le résultat souhaité doit pouvoir être atteint sans qu’on soit obligé d’exécuter une série d’opérations déconnectées.
Voir également la 3.4.4. |
3.4.7
Le SAE ne doit pas permettre un reclassement ou une duplication qui générerait une structure de données contraire aux règles induites par le modèle des Relations entre Entités de MoReq2 (voir 13.2) ou figurant dans d’autres exigences. Le SAE doit interdire tout reclassement qui conduirait à :
| O |
Cette exigence devrait donc être décomposée de la manière suivante :
|
3.4.8
| Le SAE doit garantir que lors d’un reclassement, tous les documents électroniques restent bien attachés aux séries ou dossiers reclassés ; et que le lien avec les sous-dossiers, volumes et dossiers est maintenu. | P |
3.4.9
| Le SAE doit garantir que lors d’une duplication, toutes les copies des documents électroniques restent bien attachées aux nouvelles séries et/ou dossiers, et que les copies de sous-dossiers, volumes et dossiers sont correctement reliées. | P |
Cette exigence implique qu' il n'y a pas d'unicité des documents au sein du SAE. En fait si, mais il faut faire en sorte qu'un même document puisse être référencé avec plusieurs codes de classement différents. Voir également la 3.4.24. |
3.4.10
| En cas de déplacement ou de reclassement de séries, dossiers, volumes, sous-dossiers ou documents, les dossiers clos doivent rester clos, avec les références (codes de classement) précédant la modification. | O |
En corrélation avec l'exigence 3.4.5, il faut comprendre : « doivent rester clos, avec l'enregistrement des références précédant la modification. » |
3.4.11
En cas de déplacement ou de reclassement de séries, dossiers, volumes, sous-dossiers ou documents, les dossiers ouverts doivent :
à la discrétion de l’administrateur qui effectue le reclassement. | O |
Beaucoup de mots pour peu de chose. En résumé :
Donc il faut comprendre :
|
3.4.12
| En cas de reclassement ou de duplication de séries, le SAE doit permettre que les séries et leurs subdivisions puissent hériter des métadonnées de la nouvelle série mère. | O | Il s’agit notamment des habilitations et des niveaux de sécurité.
Noter l'emploi de « permettre », qui implique que ce n'est pas nécessairement le cas, donc que l'héritage doit être paramétrable. Cela est particulièrement évident dans la version anglo-saxonne (« optional inheritance »). À débattre et trancher. Noter également que le commentaire s'applique à une fonctionnalité d'un module optionnel. Voir encore la 3.4.12. |
3.4.13
| En cas de reclassement ou de duplication de séries, le SAE doit être capable d’appliquer les règles de conservation/destruction héritées de la nouvelle série mère aux séries reclassées ou dupliquées et à leurs subdivisions, en plus des règles de conservation/destruction existantes. | O | Il s’agit là de la fonctionnalité minimale ; le SAE peut proposer d’autres moyens de gérer les règles de conservation/destruction.
Il peut s’ensuivre des contradictions entre les règles ; le cas échéant, on se conformera aux exigences du chapitre 5.1 (voir 5.1.18 et 5.1.33). Même observation que pour la 3.4.12, appliquée au terme "capable". |
3.4.14
| En cas de reclassement ou de duplication de séries, le SAE doit demander à l’administrateur d’en saisir la raison parmi les métadonnées. | O | La saisie d’une raison est obligatoire : reclassement et duplication étant exceptionnels, une erreur pourrait compromettre l’intégrité des documents archivés. |
3.4.15
| En cas de reclassement ou de duplication de séries, dossiers ou documents, le SAE doit enregistrer leur statut précédant (sic) dans l’historique des événements. | O |
En l'occurrence, d'après les métadonnées, il n'existe qu'une seule information sur le statut : « M031 - Gestion.statut.permanent ». |
3.4.16
| En cas de reclassement de séries, le SAE doit enregistrer les valeurs antérieures de leurs métadonnées. | O | Les deux exigences ci-dessus ont pour objectif de permettre d’établir l’historique des documents reclassés.
Attention, implications techniques importantes. |
3.4.19
| Le SAE doit systématiquement empêcher la suppression d’un fichier électronique ou d’une part de son contenu. | O | Il y a deux exceptions à cette exigence :
À comparer avec la version anglo-saxonne originale, ainsi qu'avec les deux versions de la 3.4.20, il faut sérieusement considérer que "fichier" pourrait plutôt être "dossier" (même terme "file" en anglais). Noter que l'emploi du qualificatif "électronique" ("electronic" dans la V.O.) est sans doute à l'origine de la confusion. Inutile d'aller voir au chapitre 9.3 comment est abordée cette notion d'audit : elle n'existe pas dans ce chapitre[9]. En revanche, c'est contradictoire avec la 9.3.5. Les deux exceptions données en commentaires auraient largement mérité d'être transformées en exigences, ce qui aurait conduit à remanier l'exigence présente. |
3.4.20
| Le SAE doit autoriser les utilisateurs à clore un dossier électronique. | O | Ce point diffère de l’exigence correspondante de MoReq qui limitait cette action aux administrateurs.
Voir également la 3.4.19. Aurait mérité d'être dans la partie « Séries et dossiers », à l'instar des exigences sur la clôture des sous-dossiers (3.3.8) et des volumes (3.3.19). |
3.4.22
| Le SAE doit faire en sorte que les contenus des séries, dossiers, sous-dossiers et volumes clos soient aussi aisément accessibles que ceux qui sont ouverts, sans faire de différence entre les uns et les autres. | O | Autrement dit, si des utilisateurs recherchent des informations au sein du SAE, le fait que les dossiers soient clos ou ouverts doit être transparent pour eux ; les mêmes fonctionnalités de recherche et d’accès doivent s’appliquer.
Voir également la 3.3.10. |
3.4.25
| Le SAE doit fournir aux administrateurs des outils de reporting pour produire des statistiques sur la vie du plan de classement, y compris le nombre et la taille des séries, dossiers, volumes, sous-dossiers et documents créés, clos ou détruits au cours d’une période donnée. | O | Le reporting devrait être à la fois global et au niveau d’un utilisateur ou d’une série.
Entraînerait l'intégration d'un outil de type Piwik ? |
3.4.28
| Si un mot-clé d’un dossier est modifié, le SAE doit demander à l’administrateur de saisir la raison de ce changement. | O |
Il serait possible d'ajouter : "de saisir la raison puis de l'enregistrer"... |
3.4.29
| Si un mot-clé d’un dossier est modifié, le SAE doit conserver une trace de son statut antérieur afin que l’historique puisse être facilement établi. | O | Ces contrôles de changement de mots-clés visent à minimiser le risque de dissimulation de documents via des modifications de mots-clés. Dans la mesure où les mots-clés servent à retrouver les documents archivés, il est nécessaire de tracer leurs modifications pour éviter qu’un utilisateur puisse tenter de cacher un document en modifiant ses mots-clés.
Aucune métadonnée ne permet de stocker l'ancienne valeur du mot-clé. Le stockage se fait nécessairement en historique. |
Notes
- ↑ MR2, chap. 2.2, partie "Série", §5, et chap. 3, §7.
- ↑ En V.O. : « can contain subfiles ».
- ↑ Nous laisserons l'Académie débattre du choix entre ce terme et celui de « tetracapillectomie ».
- ↑ MR2, chap. 13.1, définition ouverture.
- ↑ Cf. MR2, chap. 13.1, définitions "administrateur" et "utilisateur", ainsi que chap. 13.4.
- ↑ Possibilité « Non ».
- ↑ Cf. MR2, chap. 13.1, définition "ouverture".
- ↑ Pour rappel, il existe une incohérence forte concernant la métadonnée M091 - précédent_code_classement_complet qui est classée dans la catégorie « Relation », ce qui suggère qu'elle lie l'entité à un autre objet, ce qui est une aberration totale puisque l'objet en question est justement celui qui vient d'être reclassé, dont la référence vient de changer. Les « Maarcheurs » peuvent consulter les spécifications du plan de classement sur le wiki interne pour plus de détails.
- ↑ Voir éventuellement les exigences qui aborde ce point dans les chapitres 4 et 5 : 4.2.7, 4.2.13, 4.2.15, et 5.1.14.
