Par Antony Belin, archiviste expert chez API
La transformation numérique de la société à marche forcée, pourquoi pas, mais à quel prix ? Que devient l’archivistique dans le contexte de dématique ? De ce que je constate, via ma propre expérience d’Autorité de tiers-archivage (ATA), m’amenant à voir bien des pratiques par nos clients allant du simple village à l’établissement national, sans compter nos clients du secteur privé, la démarche semble présentement de déstocker les données sur un système d’archivage électronique (SAE), certes avec un souci de conservation à valeur probatoire, afin de désengorger les autres systèmes d’information (SI) en amont (outils de production donc), sans se soucier un seul instant de la qualité des données déposées au sens archivistique, soit leur caractère pérenne et intelligible à plus ou moins long terme. Le présent constat n’est de toute évidence pas spécifique au tiers-archivage et devrait alarmer au plus haut…
1.1. Structuration des données à vocation archivable
Combien de données redondantes (doublonnage, versions multiples sans pouvoir définir la version finale sur laquelle repose néanmoins la valeur probatoire…) se retrouvent désormais en archivage ? Dans des dossiers d’audits qu’on nous demande de verser manuellement (et il est déjà heureux qu’il en soit ainsi justement), ils sont légions, suite aux multiples envois de l’audité durant la période de contrôle, sans qu’un tri préalable soit opéré par les producteurs à réception. En outre, des données de commande publique notamment, se trouvent versées par bien des outils, nécessitant de définir quoi arrive par où et donc quoi ne pas verser si issu d’une autre source. De plus, un mauvais plan de classement se trouvera figé à jamais une fois archivé, notamment dans le contexte de modèles de données tels que le Standard d’échange de données pour archivage (SEDA). A contrario d’archives physiques, il n’est plus question une fois déposées de modifier l’ordre des unités d’archive.
Il apparaît donc impératif de structurer les données le plus en amont possible, soit dès leur production. Cela s’avère d’autant plus crucial dans le cas de dossiers (la commande publique en étant un parfait exemple) où les données présentes dans les sous-dossiers soient soumises à des règles de gestion (durées de conservation légale, sorts finaux ou durées de rétention de communicabilité) hétérogènes, impliquant dès lors de systématiquement isoler toute donnée à règle de gestion différente dans un sous-dossier spécifique, quel que soit le niveau de positionnement dans le plan de classement. Les plans de classement de dossiers (commande publique, ressources humaines, dossiers patients…) devraient donc être gravés dans le marbre par les pouvoirs publics au niveau national, provincial ou fédéral, dès lors que les pratiques soient communes, et s’imposer aux éditeurs sous forme de clauses rédhibitoires lors d’appels d’offres. Dès lors, tout serait ainsi déjà en place pour faciliter un archivage à l’état de l’art. De mon « jeune » temps à l’Établissement public d’aménagement universitaire de la région Île-de-France (ÉPAURÎF), je mis en place une arborescence type de sous-dossiers reproduisant de façon exhaustive un dossier de commande publique, suffisant alors au service juridique de copier cette arborescence sous un dossier portant le numéro de nouveau marché, l’archivage au moment de la notification s’en trouvant aisé. Il n’est rien à faire de différent présentement.
Il faut aussi faire en sorte que le déclenchement de passage au statut « archive » sur les outils de production soient intelligemment contrôlé. Créer des « archives » à chaque phase de la passation d’un marché, engendrant donc autant de doublons de données et le caractère ubuesque de trouver ces documents placés en des endroits différents du plan de classement selon la phase « archivée », est une fort mauvaise pratique. Dans ce cadre, la logique est de verser l’archive au moment de la notification du marché ou de sa déclaration sans suite ou infructueuse, le reste du marché étant par la suite versé en divers moments de sa vie (avenants au moment de leur contractualisation par le service juridique, décompte général définitif [DGD] à clôture du marché par le service financier, suivi technique à réalisation de chaque ordre de service [OS] par le service technique…). Il faut donc définir, là aussi par les pouvoirs publics, les phases où l’archivage soit pertinent, sans attendre néanmoins que l’ensemble d’une affaire soit clôturée, surtout dans le temps long (marchés de travaux, dossiers de personnel, dossiers de locataires, dossiers patients…), l’éclatement de ces versements n’étant nullement un problème en dématique dès lors qu’un dénominateur commun (cette bonne vieille clé primaire des systèmes de gestion de bases-de-données [SGBD] type Access) soit clairement défini par son unicité (numéro de marché, matricule d’agent, numéro unique de patient…).
Il faut néanmoins adapter ce découpage de versements au contexte dans certains métiers. Ainsi en aille-t-il dans le cadre des dossiers médicaux : un dossier concernant une simple opération de l’appendicite, en raison de son caractère désormais bénin, le patient entrant et sortant dans la même journée bien souvent, peut être intégralement archivé à sortie du patient, tandis que chaque prescription soit systématiquement archivée dans un contexte comme la triste affaire (29 septembre 2008-11 juillet 2019) Vincent Lambert (1976-2019), compte-tenu des déchirements judiciaires de la famille et de l’impérieux besoin du personnel médical de s’en préserver. Lors des consultations, il suffit simplement de faire une recherche sur l’ensemble des données déposées via le mot-clé reprenant cette fameuse clé primaire afin de reconstituer virtuellement l’intégralité de l’affaire.
1.2. Reprise de métadonnées
La reprise de métadonnées descriptives est elle aussi à prendre sérieusement en compte, puisque c’est par leur biais que les données déposées seront retrouvées. Ces points affectent l’amont comme l’aval du système d’archivage électronique (SAE) (versements entrants ou sortants), à divers moments du contrat. Il est affligeant de recevoir des codes systèmes en guise d’intitulés d’archives en lieu et place de leur signification réelle, de même que de réceptionner des valeurs systèmes « (non-disponible) » (authentique), au lieu de valeurs nulles (et non pas « NULL »), la pire situation qui soit dans le cadre de métadonnées absentes en amont et induisant inévitablement en erreur le lecteur, alors que les données soient pourtant bel et bien disponibles.
Pour la reprise de données, il est néanmoins des facteurs à prendre impérativement en compte, et ce très en amont du projet, par l’Autorité juridique utilisatrice du système d’archivage électronique (SAE), qu’il soit internalisé, tiers-hébergé ou tiers-archivé, l’Autorité d’archivage ou de tiers-archivage (ATA) ne faisant pas autrement que de reprendre globalement l’existant en l’état, avec quelques étapes d’ajustements mais avec bien des limites :
- harmonisation des processus par l’ensemble des entités de l’Autorité juridique
- homogénéisation des terminologies
- unicité des référentiels d’autorités fonctionnelles (autorités versantes, autorités productrices, Archives et autorités de contrôle) avec harmonisation de leurs notices
- unicité des référentiels d’autorités requérantes (lecteurs et services administratifs ou judiciaires), avec harmonisation de leurs notices
- unicité des référentiels de gestion des données (cadres et plans de classement, tableaux de gestion de données [TGD], règles de communicabilité, durées de conservation légale, règles de conservation finale, règles de réutilisation, règles de classifications…)
- thésauri de mots matières, métiers, géographiques, topographiques, typologiques… multiples, mais pour chaque type de thésauri convenant là aussi d’harmoniser les différents thésauri se constituant au sein des entités
- traduction des codes de gestion utilisés
Un tel travail de redressement de données se base sur un audit exhaustif de l’existant, afin de définir l’ensemble des écarts avec les attendus du nouveau système d’archivage électronique (SAE), paramétré de façon à accueillir les données ou les métadonnées reprises tel que désiré suite aux travaux d’harmonisation, indépendamment des possibilités de l’existant. Ainsi, des éléments ne sont pas repris quand d’autres sont potentiellement ajoutés, même si, de facto, ces champs soient vides au moment de la reprise, et pour cause compte tenu qu’ils n’existent pas dans l’environnement sortant. L’intégration de nouvelles données par la suite est soumise aux nouveaux processus et le renseignement exhaustif des champs devient la norme. Néanmoins, tout système d’archivage électronique (SAE) permet de renseigner ou de modifier a posteriori toute métadonnée, tant qu’elle n’affecte pas le cycle de vie de la donnée s’y référant et si cette modification soit dûment tracée dans le journal de cycle de vie de la donnée.
Dans l’exemple infra, le champ de métadonnées A de l’application sortante correspondant au champ de métadonnées D dans le système d’archivage électronique (SAE) entrant, en allant de même entre le champ de métadonnées B sortant et le champ de métadonnées A entrant. En revanche, les champs de métadonnées C et D sortants correspondent à un seul champ de métadonnées dans le système d’archivage électronique (SAE) entrant, ils sont alors concaténés au moment de la reprise afin de correspondre aux attendus sémantiques du champ de métadonnées B entrant. Enfin, le champ de métadonnées E sortant n’ayant pas de correspondance dans le système d’archivage électronique (SAE) entrant et n’étant pas considéré d’intérêt majeur, il se trouve alors rejeté lors de la reprise, alors que le champ de métadonnées C n’ayant aucune correspondance en l’état avec l’application sortante, il reste non-renseigné dans l’immédiat.
Les extractions de métadonnées issues des systèmes de gestion électronique de documents (GED), des systèmes d’archivage physique, des systèmes d’archivage électronique (SAE) ou de toute autre application à reprendre, pour décommissionnement, se font dans des formats ouverts (type <CSV>…), exploitables et interopérables, nécessitant pour autant un travail préparatoire de la part de l’Autorité juridique commanditaire :
- documentation exhaustive impérative de la part de l’éditeur ou du prestataire responsable de l’application sortante, imposant dès lors une contractualisation de ce volet dès la mise-en-œuvre de l’application, au risque de se voir refuser une fin de non-recevoir ou des complications juridico-psychologiques freinant considérablement la reprise (le facteur prestataire non reconduit jouant sérieusement)
- explicitation de l’ensemble des champs à reprendre, les intitulés n’étant souvent pas intelligibles, même pour un expert métier
- nettoyage de l’ensemble des colonnes ou des lignes inutiles à la reprise, car issue du fonctionnement de l’application sortante, mais aucunement pertinentes pour le système d’archivage électronique (SAE) entrant ou pour le contexte métier
- nettoyage de certaines cellules dont le contenu serait faussé lors de la reprise : ainsi en va-t-il des champs dates indiquant certes un évènement 14 juillet (« 14-juil»), mais qui dans un contexte en Excel seront finalement repris comme « 14 juillet 2018 » et non comme « 14 juillet 1789 » ou « 14 juillet 1790 », eh oui duquel s’agit-il du reste, Bastille ou Fédération ?), mais aussi de tout champ disparate, car libres de contenu à une époque…
- harmonisation du contenu des champs, des applications s’accommodant en leur temps de toute dérive, mais ceci n’étant non seulement plus possible, mais n’étant plus admissible de nos jours, tels que des champs <Noms> et <Prénoms> où se retrouvent un nom de régiment dans le premier et un code d’opération extérieur (« Serval») ou intérieur (« Vigipirate ») dans le second
- indiquer tout champ à ajouter présent dans un tableau de suivi interne, mais n’étant pas implémenté dans l’application originelle (un nombre limité de profondeur de séries, alors que le tableau descend à un niveau de sous-série plus exhaustif…)
- pointer la reprise de cellules soit sur l’extraction de l’applicatif soit sur un tableau interne dans le cas où les contenus soient plus exhaustifs (ainsi « 8S Parchemins» dans une application métier s’avère en réalité « 8S Chambre des comptes de Bretagne (Parchemins) » dans le tableau tenu par l’Autorité productrice ou par l’Autorité d’archivage, orientant radicalement les recherches par la suite)
Les modalités techniques et surtout organisationnelles et financières sont clairement contractualisées, afin de ne pas générer de surcoûts et de contentieux dommageables lorsque le besoin se fasse jour. En tout état de cause, si le travail préalable exposé supra ne soit pas réalisé, l’Autorité d’archivage ou de tiers-archivage (AA/ATA) responsable de la reprise de données est légitimement en droit de facturer en conséquence le surplus de tâches, s’apparentant à de l’assistance à maîtrise d’ouvrage (AMO).
Dans le cas de projets très importants affectant plusieurs sites (multinationale avec ses filiales, Autorité juridique publique avec ses services déconcentrés…), il faut, en lien avec le plan de conduite du changement, se poser la question de savoir s’il soit réellement plus judicieux de déployer une reprise de données par sites ou plutôt par applications, tout dépendant du degré d’harmonisation possible et une reprise globale d’une application s’avérant plus pertinente au final, plutôt que de la saucissonner par site.
Les métadonnées descriptives attendues devraient donc être imposées conjointement par les autorités métiers et par les autorités d’archivage (AA) des pouvoirs publics au niveau national, provincial ou fédéral, dès lors que les pratiques soient communes, et s’imposer là encore aux éditeurs sous forme de clauses rédhibitoires lors d’appels d’offres, facilitant de facto un archivage à l’état de l’art.
1.3. Piégeuses conversions de formats de fichiers
La conversion de formats et, in extenso, la qualité des fichiers à archiver est un point particulièrement délicat et pour autant totalement négligé, les conversions automatiques laissant franchement songeur au regard des innombrables pièges que seul un esprit humain soit à même de déceler, refusant dès lors certaines conversions. Sans prétendre à l’exhaustivité, voici un certain nombre de ces obstacles rencontrés par typologie de fichiers bureautiques.
Concernant les formats de type « texte » (Word…), à convertir dans la mesure du possible en Portable Document Files / Archive (<PDF/A>), mieux vaut s’assurer en premier lieu que le fichier soit en version récente du logiciel, quitte à le convertir en montée de version (<Fichier> à <Informations> à <Convertir> si bouton actif). La vigilance est cependant de mise concernant les dates incrémentées, à repérer au préalable, celles-ci affichant en effet automatiquement la date du jour de lecture du fichier (tout le contraire de ce qui convienne pour conférer une valeur probatoire), le risque étant donc de figer un fichier en Portable Document Files / Archive (<PDF/A>) avec une date falsifiée : il est en ce cas préférable de conserver le fichier en format éditable. Ce dernier point montre bien la nécessité de figer les données dès leur état final (signées ou pas) pour que leur caractère probatoire demeure valide dans le temps. Il est à noter que de rares fichiers Word ont un étrange comportement lors de la conversion, la fenêtre de visualisation du fichier se réduisant à la portion congrue (un tout petit bout du bandeau d’en-tête), laissant à penser un dysfonctionnement voire une corruption de ce fichier, à écarter donc de l’archivage, si qualité informationnelle négligeable.
Concernant les formats de type « tableur » (Excel…), à convertir dans la mesure du possible en Portable Document Files / Archive (<PDF/A>), mieux vaut s’assurer en premier lieu que le fichier soit en version récente du logiciel, quitte à le convertir en montée de version (<Fichier> à <Informations> à <Convertir> si bouton actif). S’il s’agit de conserver les possibilités de calcul, on convertira les fichiers en Comma-Separated Values (<CSV>). Toutefois, pour des fichiers comportant plusieurs onglets, on aura intérêt à les conserver en version la plus récente du logiciel, car en ce cas la conversion en Comma-Separated Values (<CSV>) implique de créer un fichier par onglets, multipliant donc les fichiers d’une part et annihilant toute corrélation entre onglets d’autre part. Lors de la conversion en Portable Document Files / Archive (<PDF/A>), dès lors que les données puissent se trouver figées, il faut porter une attention soutenue à l’orientation de la mise-en-page (mode portrait ou mode paysage) pour une meilleure lisibilité ainsi que, selon le nombre de lignes ou selon le nombre de colonnes impliquées (soit selon la largeur ou selon la longueur applicables), au choix de convertir tel quel ou d’ajuster à la largeur de la feuille, voire de faire en sorte que l’ensemble d’un onglet tienne sur une seule page. Ce dernier aspect est essentiel afin d’éviter ces fichiers où il faille naviguer entre les pages pour visualiser l’ensemble des colonnes liées à une ligne et vice-versa, ainsi que pour limiter le nombre de pages du fichier (soit son poids). Rappelons que la visualisation d’une page d’un fichier soit toute relative selon qu’on la consulte en version physique ou en version dématérialisée, la résolution d’écran permettant d’agrandir de façon parfaitement intelligible les caractères sur un Portable Document Files / Archive (<PDF/A>) qui paraîtraient pourtant illisibles en support physique. Si les données au sein des cases éditables du tableur ne reprennent de façon explicite l’intitulé des onglets, il est en ce cas préférable de conserver le fichier en format éditable.
Concernant les formats de type « présentation » (PowerPoint…), à convertir dans la mesure du possible en Portable Document Files / Archive (<PDF/A>), mieux vaut s’assurer en premier lieu que le fichier soit en version récente du logiciel, quitte à le convertir en montée de version (<Fichier> à <Informations> à <Convertir> si bouton actif). Il est possible de conserver l’ensemble des animations en encapsulant le fichier en Portable Document Files / X (<PDF/X>), ce procédé étant rigoureusement réversible de par l’encapsulage du fichier d’origine et non sa conversion, s’agissant alors juste de l’extraire du Portable Document Files / X (<PDF/X>) pour le récupérer dans son état d’origine, ce principe s’appliquant par ailleurs à tout type de fichier pris en charge par Adobe (audio, vidéo, AutoCAD…).
Concernant les formats de type « logigramme » (Visio…), à convertir dans la mesure du possible en Portable Document Files / Archive (<PDF/A>), mieux vaut s’assurer en premier lieu que le fichier soit en version récente du logiciel, quitte à le convertir en montée de version (<Fichier> à <Informations> à <Convertir> si bouton actif). Il faut être vigilant concernant l’ajustement de la fenêtre ou de la page, afin que l’ensemble du logigramme soit pris en compte dans le fichier converti, sans rognure.
Pas de difficulté particulière concernant les fichiers images (<JPG>, <BMP>, <PNG>, <TIFF>…), bien qu’il faille rester vigilant sur leur orientation, notamment dans le cadre de plans numérisés, ayant même été confronté à des plans carrément inversés en effet miroir.
Concernant les Portable Document Files / Archive (<PDF/A> natifs ou issus des conversions supra), il reste souvent plusieurs tâches à effectuer afin d’assurer leur qualité, l’acquisition de la suite Adobe Acrobat DC paraissant indispensable (en plus de ses nombreuses autres possibilités), les outils gratuits n’ayant pas la même efficacité. Sur la conversion stricto sensu d’un Portable Document File (<PDF>) en Portable Document Files / Archive (<PDF/A>), il arrive régulièrement qu’un certain nombre de caractères se retrouvent convertis en petits rectangles, rendant alors inintelligible le document. Il faut être extrêmement vigilant, ce phénomène apparaissant parfois au bout de plusieurs pages. La raison en est le plus fréquemment un Portable Document File (<PDF>) issu d’un logiciel gratuit autre qu’Adobe ou un Portable Document File (<PDF>) issu d’une conversion d’un fichier bureautique en version trop ancienne (d’où l’insistance supra sur le fait de convertir ces fichiers au préalable en montée de version logicielle). En pareil cas, on sera contraint de se contenter de la version originelle du Portable Document File (<PDF>), sauf à disposer miraculeusement du fichier bureautique initial et à lui appliquer les recommandations supra. Il reste aussi à supprimer les innombrables pages blanches (parfois une page sur deux !), pesant le plus lourd dans un fichier, de même qu’il faille redresser dans le bon sens les pages, étant logique d’avoir des alternances de pages en mode portrait ou en mode paysage. Il est anormal de se retrouver encore avec tant de fichiers où il faille soit montrer bien de la souplesse en faisant le poirier pour les lire, soit retourner l’ordinateur… Enfin, alors qu’en support physique on faisait en sorte d’agrafer le document maître et ses annexes, de façon parfois hasardeuse, que ne fusionnons-nous en Portable Document Files / Archive (<PDF/A>) les fichiers maîtres et leurs annexes, limitant ainsi le nombre de fichiers ? Plus les systèmes supportent de fichiers, plus cela implique de contrôles viraux et de contrôles d’intégrité, jusqu’à leur saturation.
Concernant les fichiers <ZIP>, mieux vaut les décompresser avant versement en archivage. Les fichiers dont l’extension de noms soit inconnue peuvent révéler avec un peu d’expérience cette extension en les ouvrant avec un éditeur <XML> (NotePad++…), la conversion de format n’étant envisageable qu’avec la connaissance de l’extension. Pour finir, mais il est toujours bon de le rappeler, il est inutile de verser des fichiers de raccourcis, caduques une fois dans le système d’archivage électronique (SAE), de même que les fichiers systèmes de type « Thumbs » ou commençant pas « ~ », « . », générant logiquement des erreurs au moment du versement…
Autant de constats affligeants me faisant de plus en plus songer à changer de voie, ayant le sentiment de ne réaliser plus qu’un semblant de métier d’archiviste, dans un monde de… faux-semblants… en définitive cela s’accorde bien. Je reste perplexe du moins devant le fait que des archivistes soient prêts à dépenser tant d’énergie à supprimer agrafes, trombones et autres ornements ferreux ou plastiques, mais renoncent à une tâche équivalente en dématique…
***
Pour découvrir ou revisiter la série complète qui précède ce texte, CLIQUER ICI
Convergence AAQ 