La dématérialisation au Conseil départemental de la Seine-Maritime : de la mise en place d’une chaîne de numérisation à l’archivage des données

Retour d’expérience proposé par Matthieu Angebault et Thomas Bernard, Archives départementales de la Seine-Maritime

Stratégie de dématérialisation et de numérisation

En 2015, le Conseil départemental de la Seine-Maritime a opté pour une stratégie de dématérialisation processus métier par processus métier (pas de numérisation de l’intégralité des flux entrants par exemple).

Pour un processus métier donné, la dématérialisation est cependant complète ou dite « de bout en bout » (full demat) : l’instruction des affaires est réalisée à l’écran et la collectivité ne gère pas de dossiers mixtes. Cela sous-entend la numérisation du flux entrant mais également la numérisation des dossiers de stock pour que l’instruction des nouvelles demandes puisse être réalisée avec l’ensemble des éléments à l’écran.

La numérisation est répartie entre deux acteurs. Un Centre de dématérialisation interne (CDD) a été créé. Sa vocation première est la numérisation du flux. Il est cependant capable de traiter ponctuellement des dossiers de stock. Ces derniers sont pour l’essentiel confiés à un prestataire externe de numérisation.

L’objectif de conférer aux dossiers numériques le statut de dossiers de référence a rapidement été validé avec, pour corollaire, la destruction anticipée des documents papier. Les jalons posés par le vade-mecum « Autoriser la destruction de documents sur support papier après leur numérisation »[1] ont alors pu être utilisés comme fil conducteur dans les groupes de travail.

Accompagnement des métiers

La Direction de l’autonomie du conseil départemental (DA) et la Maison départementale des personnes handicapées (MDPH) ont été retenues comme pilotes des projets de dématérialisation.

Le passage à une gestion dématérialisée a été l’occasion de réviser les plans de classement internes des dossiers et leur cycle de vie. Cela a particulièrement été le cas pour la DA où l’on est passé d’un dossier d’aide familial dont la DUA courrait à compter de la clôture de la dernière mesure à un dossier d’aide individuel géré, en matière de cycle de vie, mesure par mesure. Ce travail amont des AD avec les métiers a permis de présenter à la Direction des systèmes d’information (DSI) un cahier des charges négocié et partagé, coordonnant les besoins métiers et les besoins d’archivage.

La révision des plans de classement métiers et du cycle de vie des dossiers a également permis de préparer les dossiers de stock en vue de leur numérisation. Des opérations dites de « toilettage » ont été conduites par les agents de la MDPH et de la DA. Ces opérations consistaient tout d’abord à identifier les dossiers clos exclus du périmètre de la numérisation. Les dossiers vivants (55.000 pour la DA et 100.000 pour la MDPH) ont été épurées en application des nouvelles DUA et réorganisés afin de faire correspondre leur structure à la structure attendue pour le dossier numérique dans la GED.

Cadrage des prestations de numérisation des dossiers

Les AD ont été associés au cadrage des prestations de numérisation dès la rédaction du CCTP du marché de numérisation de masse. À ce stade l’objectif était de s’assurer de la présence de clauses faisant référence au vade-mecum : sécurisation des documents de la prise en charge jusqu’à la restitution, résolution et format des fichiers livrés, traitements autorisés sur les images, structure des livrables, métadonnées associées et contrôle qualité des prestations notamment. L’ensemble des exigences spécifiées dans le CCTP ont été affinées après notification du marché lors de points techniques préalables au lancement des prestations.

Dans la perspective de l’audit de la chaîne de numérisation, les AD ont également été fortement impliquées dans la mise en place des procédures de numérisation du CDD. La principale problématique rencontrée a été celle du contrôle qualité des prestations. Ce point a suscité de nombreuses inquiétudes tant sur le plan de l’intégration des tâches de contrôles au sein de la chaîne de numérisation que de la charge de travail représentée.

Les modalités de contrôle n’ont été arrêtées qu’après stabilisation des processus du CDD pour associer à chaque étape de la numérisation des contrôles adaptés. Pour assurer la fluidité des activités, les points de contrôles les plus fins et les plus chronophages sont positionnés en bout de chaîne, lorsque les lots numérisés répondent déjà à certains prérequis. Ainsi, on contrôlera, dans l’ordre, la cohérence entre le nombre de dossiers scannés et le nombre de dossiers à l’écran, la bonne indexation du dossier à l’usager et, enfin, la lisibilité des images et leur rattachement aux bonnes typologies documentaires.

Une fois les points de contrôles fixés, il convient de définir leur modalité précise de mise en œuvre et leur ampleur. Le premier contrôle est directement réalisé par l’opérateur de numérisation et porte donc sur l’ensemble des plis numérisés. Pour les autres contrôles, réalisés par des agents dédiés, les AD et le CDD ont opté, en complément des préconisations de la NF Z42-026[2], pour une méthodologie de contrôle par échantillon en s’inspirant de la norme NF ISO 2859-1[3]. La taille de l’échantillon contrôlé est déterminée en fonction de la taille du lot numérisé (nombre de dossiers ou nombre de page numérisés en une journée) et du niveau – plus ou moins fin – du contrôle. La norme permet également de s’engager sur un taux de qualité en faisant varier le nombre maximum d’erreurs acceptables pour un échantillon contrôlé. Cette possibilité a été retenue pour les derniers points de contrôle réalisés sur les images.

Lorsque le nombre maximum d’erreur est atteint, les contrôles s’arrêtent et le lot est rejeté. La numérisation ou l’indexation sont reprises et les contrôles relancés jusqu’à validation du lot. Un niveau de contrôle renforcé est appliqué à l’initialisation des prestations et jusqu’à leur stabilisation sur le plan qualitatif. Ce niveau de contrôle plus strict est réactivé dès que le contrôles mettent en évidence une dégradation de la qualité des livrables.

Audit de la chaîne de numérisation des dossiers de stock de la MDPH

Cet audit a été réalisé en trois phases : audit des méthodes de travail du prestataire de numérisation en juin 2017, audit des infrastructures informatiques de stockage du Conseil départemental, la même année, et audit du CDD en 2019, en clôture de la phase d’élaboration des procédures internes de numérisation.

Les audits ont été conduits sur pièce puis sur site en suivant la grille proposée par le vade-mecum. Ils n’ont laissé apparaître aucun point bloquant dans la démarche de dématérialisation. Une autorisation d’élimination anticipée 6 mois après numérisation a donc pu être délivrée. Cette autorisation est assortie de remarques portant principalement sur la sécurité des espaces dédiés à la conservation des dossiers papier, la répartition des tâches au sein du CDD pour assurer une continuité de service et la coordination des acteurs. Un bilan des actions correctives mises en place sera effectué en mai 2020 dans le cadre de l’instruction du renouvellement de l’autorisation d’élimination.

Les destructions de dossiers numérisés n’ont cependant été autorisées par les AD qu’après signature par la MDPH, le CDD, la DSI et les AD d’une Charte qualité pour la numérisation fidèle de documents[4]. Cette charte, basée sur le modèle proposé par le SIAF[5], définit les principes et les règles à mettre en œuvre afin de garantir la création de copies numériques fidèles et fixe les responsabilités de chacun. Cette charte sera déclinée pour chacune des chaînes qui seront auditées et, en premier lieu, le flux MDPH en 2020.

L’archivage des dossiers numériques n’a pas été exigé pour la délivrance de l’autorisation initiale. Un délai d’un an a été convenu entre la DSI et les AD. C’est donc le renouvellement de l’autorisation d’élimination qui est conditionné à la mise en production d’un outil d’export de données de la GED.

Gestion du cycle de vie et archivage des dossiers MDPH numériques

Le socle technico-fonctionnel sur lequel s’appuie la dématérialisation a fortement évolué en 2015. Les différents systèmes de GED nativement connectés aux applications métier ont été remplacés par un système de GED unique (Alfresco). Dans ce contexte d’urbanisation, les métadonnées présentes en GED ne permettent en aucun cas de gérer le cycle de vie des dossiers numériques. L’export des données repose donc sur la mise en relation et la combinaison de données de gestion issues de l’application métier et de la GED.

Le point de départ du processus d’archivage est une requête dans l’application métier permettant d’identifier les usagers de la MDPH disposant d’un dossier dont la DUA est échue. Un rapport de requête est livré sous la forme d’un tableur Excel contenant les métadonnées attendues pour la description de haut niveau des dossiers : nom de l’usager, sexe, date de naissance, dates extrêmes, etc. Le rapport contient également une métadonnée « clé GED » permettant d’associer un usager dans Génésis à son dossier en GED.

Un générateur XML SEDA, issu de développements internes au format JSON et connecté à la GED, est ensuite utilisé. Après avoir été éventuellement épuré pour sélection d’un échantillon, le rapport de requête est chargé dans cet outil et associé à un modèle de bordereau de transfert. Un bordereau de transfert SEDA 1.0 peut alors être produit : le générateur encode les données du rapport de requête et, lorsqu’il rencontre une métadonnée « clé GED », appelle Alfresco via un web service. Il récupère alors et encode dans le bordereau les métadonnées issues de la GED : intitulé des répertoires, sous-répertoires et documents. Dans un second temps, le générateur exploite le bordereau pour extraire les documents de la GED et générer un paquet SEDA (bordereau de transfert et pièces jointes sous la forme d’un fichier compressé).

Générateur interne XML SEDA. Colonne à gauche : liste des métadonnées disponibles, en haut de l’écran, les premières valeurs du tableur Excel chargé et sur la partie basse, le modèle de bordereau de transfert SEDA (partie dossier de l’usager).

Le paquet SEDA est versé dans le SAE As@lae (version 1.6.7) via la fonction « Transfert pré-formaté ». Les tests de performance réalisés fin 2019 ont permis l’export de 40 Go de données de la GED (2000 dossiers) et le versement d’un paquet de 13 Go de données (7000 fichiers / 600 dossiers) dans le SAE.

Fichier XML SEDA, balises correspondant à un dossier usager.

Le générateur dispose également d’une fonction de suppression de données qui permet, toujours sur la base d’un bordereau XML SEDA, de procéder aux éliminations réglementaires dans la GED.

Le choix de ne connecter le générateur qu’à la GED et non à l’application métier permettra de le mettre en œuvre facilement et sans développement complémentaire pour l’ensemble des flux documentaires pris en charge par Alfresco. La connexion au SAE sera examinée dans un second temps, lorsque le volume et la fréquence des flux le justifieront.

______________________

[1] Dénommé « vade-mecum » dans la suite de l’article.

[2] Définition et spécifications des prestations de numérisation fidèle de documents sur support papier et contrôle de ces prestations

[3] Règles d’échantillonnage pour les contrôles par attributs – Partie 1 : procédures d’échantillonnage pour les contrôles lot par lot, indexés d’après le niveau de qualité acceptable

[4] Le prestataire n’a pas été inclus car ses modes opératoires sont fixés par le CCTP et les documents de cadrage établis après notification du marché.

[5] https://francearchives.fr/file/ff3319f66e51aa8c35970bfde2f7bc12bbe68361/BDR_06_Charte_qualite.pdf

Dématérialisation et archivage des dossiers d’étrangers à la préfecture de Seine-Maritime

Ce retour d’expérience est proposé par Matthieu Angebault et Thomas Bernard, Archives départementales de la Seine-Maritime

Le cas des dossiers d’étrangers en préfecture

Contexte

 L’archivage des dossiers numériques d’étrangers, et plus particulièrement des demandes de titres de séjour, est un sujet déjà largement analysé au sein de la profession. Tandis que la préfecture des Ardennes avait développé un module d’export des dossiers au format SEDA[1] fonctionnant avec le logiciel de GED[2] Gargantua, le groupe de travail constitué sous l’égide du Service interministériel des Archives de France a produit la circulaire DGP/SIAF/2011/021 du 15 novembre 2011, qui donnait des règles quant à la gestion du cycle de vie des dossiers d’étrangers et proposait un profil d’archivage. Cependant, force est de constater que les modalités d’application de ces dispositions dans les préfectures ont été variables, et le plus souvent presque inexistantes.

 En Seine-Maritime, la dématérialisation des dossiers d’étrangers a démarré en 2005. Elle porte en priorité sur le flux des demandes de titres de séjour, mais s’est également étendue au stock et à d’autres typologies comme les dossiers d’éloignement. La chaîne de numérisation repose sur une application nationale AGDREF, qui contient les données dont la conservation est à la charge des Archives nationales, et une GED locale, Gargantua[3], qui contient les documents dont la conservation est à la charge des Archives départementales. La préfecture est concernée depuis l’origine, tandis que la sous-préfecture du Havre vient de se lancer dans la dématérialisation. Le sujet n’est pas anodin dans la mesure où plus de 10 000 dossiers sont instruits chaque année en matière de séjour par la préfecture de Seine-Maritime.

 L’intervention des Archives départementales

 La numérisation des dossiers d’étrangers et la gestion des originaux papiers sont des questions qui sont suivies depuis le début par les Archives départementales de Seine-Maritime. Les échanges entre le service et la préfecture avaient fait apparaître un besoin de définition d’un périmètre précis pour la numérisation et de révision des procédures internes pour une meilleure efficacité. Par ailleurs, le classement et le nommage des dossiers et documents en GED n’étaient pas formalisés, et les mécanismes de gestion du cycle de vie et d’archivage déjà présents dans Gargantua (distinction entre base active et base archives) n’étaient pas maîtrisés.

 En 2017, le contexte est devenu favorable. Côté préfecture, la présence d’un référent Archives bien identifié, le recrutement d’un développeur au SIDSIC[4] et l’installation de la GED en sous-préfecture du Havre ont été des leviers. Aux Archives départementales, la mise en production d’un SAE en 2017, reposant sur le logiciel As@lae édité par Libriciel SCOP, a doté le service des outils nécessaires à l’archivage pérenne des dossiers numériques.

 Les contours d’un projet ont ainsi pu être délimités autour de trois axes principaux : l’organisation de l’arborescence des dossiers en GED par un plan de classement, l’export des dossiers qui se trouvent dans Gargantua pour archivage définitif dans le SAE[5] des Archives départementales et l’audit de la chaîne de numérisation en vue d’une autorisation de destruction anticipée des originaux papiers après numérisation. Seuls les deux premiers points ont été instruits à ce stade.

Organiser les dossiers en GED

 La première étape a consisté à travailler sur un plan de classement des dossiers d’étrangers en GED, en repartant d’un travail mené par les Archives départementales et la préfecture du Calvados. Cette organisation, voulue simple afin de ne pas transformer radicalement les habitudes de travail des opérateurs de numérisation, reflète les différentes procédures relatives aux événements qui peuvent survenir dans le parcours d’un étranger (asile, séjour, regroupement familial, éloignement, naturalisation, etc.). Des consignes de nommage ont également été diffusées afin de standardiser la structure des dossiers et sous-dossiers. Enfin, le traitement des dossiers en doublon sur la base d’un premier repérage demeure à mener.

Exporter les dossiers d’étrangers numériques

 L’export des dossiers numériques qui se trouvent dans Gargantua constitue la principale difficulté à laquelle les archivistes et la préfecture ont été confrontés. Vraisemblablement issu des expérimentations menées dans les Ardennes, un module d’export SEDA existe nativement dans Gargantua. Les tests menés à partir de ce module n’ont toutefois pas permis d’aboutir à un paquet conforme au standard d’échange, si bien qu’il a fallu repartir de zéro.

 En partant d’un bordereau modèle spécifié par les Archives départementales, le SIDSIC a pu développer un fichier de configuration au format JSON permettant de faire la correspondance entre les données et documents présents dans Gargantua et la structure du SEDA telle qu’elle est préconisée par la circulaire de 2011. Cet outil a permis de produire, pour chaque année, un paquet contenant un fichier XML au format SEDA 1.0 et un fichier ZIP contenant les objets-données. Le fichier XML est construit selon trois niveaux d’objets d’archives : le dossier, au nom de l’étranger, qui porte les métadonnées issues d’AGDREF (identifiants, dates, informations d’état civil, nationalité, etc.), le sous-dossier, pour chaque événement (première demande, renouvellement de titre, etc.) et le document.

 Les Archives départementales ont fait le choix d’opérer un versement intégral et non un échantillonnage, en raison de la valeur administrative de ces dossiers. Les dossiers papiers plus anciens déjà versé aux Archives départementales font en effet l’objet de nombreuses demandes de recherche de la part du public, surtout à des fins de preuve, mais aussi pour la recherche historique.

 

Structure XML-SEDA pour un dossier d’usager

Cycle de vie et métadonnées

 Il existe en théorie au sein de Gargantua une métadonnée au niveau de chaque dossier intitulée « date de fin de validité du dernier titre délivré », qui devrait permettre d’opérer un export des dossiers clos depuis plus de cinq ans en application de la circulaire susdite.

 Or, les premiers exports réalisés par le SIDSIC ont rapidement mis en évidence le fait que cette information n’est pas systématiquement mise à jour lorsqu’un nouveau titre est délivré à la personne, si bien que la date indiquée est régulièrement obsolète, le dossier pouvant même contenir des documents postérieurs à cette date. Le problème tient du mode d’alimentation des métadonnées dans Gargantua : les informations tirées d’AGDREF sont importées lorsqu’un dossier est ouvert par l’édition d’une « feuille patch » qui est lue par le scanner, mais elles ne sont pas écrasées lorsque de nouveaux événements surviennent dans la vie du dossier.

 Il a donc fallu adopter une approche « pragmatique » consistant à combiner la date de fin de validité du dernier titre délivré avec la date du document le plus récent. En appliquant un délai de sécurité de dix ans, soit la durée maximale d’un titre de séjour, cette méthode a permis de s’assurer que seuls des dossiers véritablement clos seraient exportés.

État de la volumétrie des versements de dossiers d’étrangers par année. Note : les premières années sont essentiellement constituées de dossiers vides constitués à partir de la reprise des données d’AGDREF.

Conclusion

 Bien que majoritairement composés de pièces justificatives, les dossiers d’étrangers sont un exemple de données issues d’un système d’information déconcentré de l’État pour lequel la continuité est très forte avec les dossiers papiers conservés aux Archives départementales dans les séries modernes et en série W. Permettant de retracer l’histoire de l’immigration au sein du département, ils ont une dimension locale et une valeur ajoutée manifestes.

 Le projet d’archivage numérique des dossiers d’étrangers a amené les Archives départementales de la Seine-Maritime à changer d’échelle en matière d’utilisation de leur SAE, dans la mesure où les exports annuels font état de volumétries importantes, non en taille brute des objets-données (il s’agit d’une numérisation de faible qualité), mais en nombre d’objets d’archives dans les bordereaux SEDA. De telles quantités posent la question de la capacité des outils actuels à traiter, à la fois lors de l’import puis au moment de la recherche, des cas réels de versements annuels concernant des procédures dématérialisées touchant un grand nombre d’usagers. Cette question est sans doute destinée à devenir cruciale dans un contexte où, en dehors des flux « traditionnels » liés aux finances, au contrôle de légalité ou aux marchés publics, il sera difficile de mettre en place des procédures d’exports fréquents et automatisés depuis les applications. Les Archives départementales sont en effet dans la plupart des cas confrontées à des systèmes vieillissants dans lesquels les mécanismes d’archivage sont embryonnaires, et où il importe en premier lieu d’obtenir une extraction exploitable. 

 À ce titre, le travail mené sur les dossiers d’usagers de la MDPH est un contre-exemple qui illustre une fois de plus l’intérêt du positionnement en amont de l’archiviste dans le déroulement d’un projet de dématérialisation.

__________

[1]     Standard d’Échange de Données pour l’Archivage.

[2]     Gestion Électronique de Documents.

[3]     À ce jour, le logiciel Gargantua édité par SIATEL équipe environ 55 préfectures.

[4]     Service Interministériel Départemental des Systèmes d’Information et de Communication.

[5]     Système d’Archivage Electronique

Construire des points d’accès unifiés vers les archives : l’expérience FranceArchives

Le portail FranceArchives, agrégateur national des archives, a vocation à proposer un accès fédéré aux métadonnées archivistiques à destination de tous types de publics. Ouvert en mars 2017, il est le fruit d’un développement en méthode agile, piloté par le Service interministériel des archives de France et réalisé par la société Logilab. Le lancement des développements d’une deuxième version – qui doit porter un certain nombre d’évolutions et approfondissements de la première version – est l’occasion de faire un premier bilan et de revenir ici sur les traitements spécifiques réalisés sur les données d’indexation des instruments de recherche.

Les possibilités offertes par la recherche plein texte n’ont pas fait disparaitre la nécessité de produire et de diffuser des métadonnées structurées et indexées. Dans la lutte contre le « bruit » les entités normalisées, non ambiguës et compréhensibles par les humains comme par les machines apparaissent aujourd’hui comme d’incontournables alliés. Le traitement des entités lieux, agents, sujets liés aux unités de description permet de construire des points d’accès cohérents vers les archives, à l’échelle d’une diffusion nationale, et plus largement à l’échelle du web. Les résultats de ces traitements mutualisés sur le portail FranceArchives ont été publiés sur le portail data.culture, ils sont ouverts à la réutilisation notamment celle des services producteurs qui souhaiteraient les exploiter dans leurs propres systèmes.

Point de départ : des inventaires et des entrées d’index

FranceArchives agrège des données de nombreux services, données qui témoignent de pratiques d’indexation hétérogènes : du point de vue de la granularité, de la normalisation du libellé, des référentiels utilisés. Par ailleurs, on constate que la part des instruments de recherche possédant des entrées d’index explicitement liées à un référentiel est faible. L’objectif des traitements décrits ici était de lier ces entités à des référentiels, et de grouper les entrées d’index faisant référence à la même entité afin de constituer un corpus d’autorités homogène, pérenne et normalisé pour mieux les valoriser.

Au départ, il y a l’indexation réalisée par les services d’archives : l’action d’associer une personne, un lieu, une collectivité, un thème à un fonds ou à un document d’archives. Le format de description le plus représenté sur FranceArchives est l’XML-EAD qui formalise le principe de description arborescent de la norme ISAD(G). Ce format permet une indexation spécifique à tous les niveaux de la description. Sur le portail, on applique aux entrées d’index le principe d’héritage des informations de niveau haut aux niveaux subordonnés : toutes les unités de description subordonnées héritent des entrées d’index liées aux unités de description parent. Le schéma ci-dessous explicite le modèle de données opérant sur le portail. Le niveau haut d’un instrument de recherche (findingaid) peut être lié à un ou plusieurs niveaux de description enfant (facomponent). On attribue automatiquement aux entrées d’index lieux, agents, sujets (geogname, persname, famname, corpname, function, occupation, subject) contenus dans un élément <controlaccess> d’une unité de description, une autorité miroir de l’entrée d’index. L’autorité devient en quelque sorte un double de l’entrée d’index qui va pouvoir être manipulé : aligné, regroupé, renommé, restitué. On ne manipule pas directement les entrées d’index afin de pouvoir conserver la trace de l’information initiale, telle qu’elle a été transmise par le service d’archive producteur de la donnée. Les autorités sont accessibles sur le portail et valorisées notamment à travers l’auto-complétion, voici par exemple l’autorité désignant la ville de Mâcon en Saône-et-Loire et les descriptions d’archives qui lui sont associées.

Modélisation partielle des instruments de recherche XML-EAD et des entités lieux, agents, sujets sur FranceArchives

Vers des autorités normalisées et unifiées

Plusieurs traitements automatisés ou manuels peuvent s’appliquer aux autorités une fois créées : l’alignement vers un référentiel externe, le groupement d’autorités désignant la même entité, la modification du libellé de l’autorité. Ces traitements peuvent s’appliquer à l’import de données sur le portail ou bien a posteriori, une validation humaine est systématiquement requise. Chaque manipulation est sauvegardée et rejouée lors des mises à jour de données. Les URI des autorités sont pérennes.

L’interface du back office permet d’exporter les autorités de chaque service partenaire au format CSV, de les traiter dans un logiciel tierce et de les réimporter. Elle permet également l’administration unitaire de l’autorité. L’alignement permet de lier explicitement une entité déjà référencée, identifiée sur le web et une autorité FranceArchives. C’est également l’opportunité d’enrichir l’autorité à partir d’informations existantes. Par exemple, lorsqu’on lie une autorité FranceArchives à une entité personne sur data.bnf.fr ou wikidata, une requête est envoyée à l’entrepôt SPARQL d’une de ces bases de connaissances. Une description ainsi que les dates d’existence sont récupérées et affichées sur le portail, exemple avec Robert Debré. Les alignements des noms de lieux ont permis la récupération des coordonnées géographiques disponibles dans les bases GeoNames et la base adresse nationale, voir la carte des lieux des archives. Enfin, les référentiels spécifiques archives sont également utilisés et valorisés. Les sujets sont alignés automatiquement vers le thésaurus-matières pour la description des archives locales (ex-thesaurus W), la prise en compte des termes rejetés dans la recherche est en projet. Le portail intègre des notices EAC permettant la description des personnes et collectivités liées aux instruments de recherche par l’intermédiaire des entrées d’index, exemple avec Alain Juppé décrit par les Archives nationales. Outre l’alignement, l’action de regroupement d’autorités vers une seule permet de rationaliser les entités produites par les différents services d’archives. En effet, on recense sur le portail de nombreuses entrées d’index qui désignent une même entité dans le monde réel. Par exemple les entrées « Nîmes (Gard, France) » et « Nîmes (Gard) » désignent la même ville, tout comme « Charles de Gaulle, général » et « De Gaulle, Charles (1890-1970 ; général) » désignent la même personne. Il s’agit alors de fusionner deux entités sans en supprimer : une redirection http est appliquée lorsqu’on groupe A vers B, on choisit comme cible l’autorité la plus normalisée.

Focus sur l’alignement des autorités lieux sur le portail

Le succès de ces différentes opérations de traitement est largement corrélé à la précision et au degré de normalisation des entrées d’index traités en entrée. En effet, les scripts d’alignements sont construits de manière à interpréter les informations telles qu’on s’attend à les trouver organisées dans les entrées d’index, c’est-à-dire en fonction des normes d’indexation actuellement en vigueur. La pratique d’indexation des lieux, à la différence de celle des personnes, nous est apparue relativement suivie et normalisée. Il s’est de ce fait avéré pertinent d’automatiser largement les opérations d’alignement et de groupement pour les lieux.

Le script d’alignement des lieux vers GeoNames et la Base adresse nationale a été réalisé en fonction de la norme NF Z44-081 Documentation – Catalogage des documents cartographiques – Forme et structure des vedettes noms géographiques. La norme prescrit une organisation spécifique des différents niveaux d’information au sein de chaque vedette géographique. La ponctuation offre un cadre, l’alignement s’appuie donc nécessairement sur ce cadre : avant la parenthèse ouvrante on s’attend à trouver un point d’accès, entre parenthèse : des descripteurs, après deux tirets une subdivision, exemple : Bagnères-de-Bigorre (Hautes-Pyrénées, France) — Tour des Jacobins. Les entités distribuées sur GeoNames sont quant à elles organisées dans une ontologie. Chaque entité appartient à une classe qui la définit en partie : par exemple l’entité du département du Doubs appartient à la classe administrative, la rivière du Doubs appartient à la classe cours d’eau, ces deux entités portent pourtant le même nom. L’enjeu de la construction du script d’alignement était de faire converger ces deux organisations : celle portée par le norme NF Z44-081 et celle portée par l’ontologie GeoNames. À titre d’exemple, la liste des principaux termes génériques recommandés en désignation (château, chaine de montagne, estuaire, forêt, etc.) a été rapprochée des différentes classes de GeoNames afin d’aiguiller l’alignement vers les entités appropriées : en fonction du terme identifié en désignation dans la vedette géographique, l’alignement est tenté vers une classe d’entité spécifique. On a pu constater que la formation de la vedette géographique, lorsqu’elle n’est pas complètement normalisée répond souvent à un besoin local de description : certains descripteurs sont simplement sous-entendus. Par exemple, un service d’archives municipal indexe uniquement les rues, puisqu’à son échelle la ville est sous-entendue, un service d’archives départemental inscrit le département en descripteur uniquement lorsqu’il se situe hors de son département. Dans un contexte de diffusion nationale, voire internationale, ces logiques sont inopérantes. Afin de contourner ce phénomène, on ajoute un paramètre supplémentaire : celui du département ou de la ville du service producteur de la donnée dans les cas d’absence de descripteurs.

Conclusion

L’objectif de ces traitements est de clarifier, d’enrichir et d’inscrire les métadonnées archivistiques dans le web de données. Ces travaux ne sont actuellement permis que par la présence d’entrées d’index au sein des instruments de recherche réalisés par les archivistes et le succès des opérations de traitement est largement corrélé au degré de structuration de ces dernières. L’équipe FranceArchives ne peut qu’encourager le renforcement d’une pratique d’indexation normalisée au sein des services d’archives, en lien avec les perspectives offertes par le modèle de données Record in Context (RiC-CM), modèle qui affirme la pertinence de construire des entités lieux, agents, sujets, gravitant autour des archives et contribuant indirectement à leur description et enrichissement. Enfin les projets de reconnaissance d’entités nommés au sein de textes bruts offrent des perspectives d’enrichissement automatisés considérables, notamment pour le traitement des masses d’instruments de recherche pas ou peu indexés. Ils convergent ainsi avec les intérêts et les besoins des historiens et autres utilisateurs du portail.

La boîte à outils numériques de l’archiviste

Le 24 octobre dernier s’est tenu au SIAF un lab “Prospective numérique” dédié aux outils utilisés quotidiennement par les archivistes (hors SAE et SIA). Les participants ont cité près d’une centaine d’applications, de plateformes ou de logiciels qui leur servent régulièrement pour des tâches aussi variées que la bureautique (au-delà des suite office classiques), l’animation de réunions, de communication, de gestion de projet, de traitement des fichiers, de production et analyse de données, de sécurité et partage etc.

Sur le modèle de la Cartographie des outils et pratiques de la vie privée de la CNIL, l’ensemble des logiciels cités vous est proposé sous forme de carte mentale., pour vous aider à construire la stratégie numérique correspondant à vos besoins.Carte mentale boîte à outils numériques archiviste

N’hésitez pas à signaler d’autres outils que vous trouvez pratiques au quotidien, ou à commenter la cartographie.

Note : vous pouvez télécharger la carte XMIND et les fichiers images ici.

Contact : merci d’avance de vos propositions pour compléter la carte et la tenir à jour. Envoyez-les à archivage.numerique.siaf@culture.gouv.fr  !

 

Trois outils contribuant à l’archivage numérique

Voici une présentation rapide d’Archifiltre, Octave et ReSip pour vous permettre de construire votre stratégie de traitement des documents numériques.

Evaluation, tri, traitements, descriptions, envoi vers un système d’archivage électronique, chaque outil a sa personnalité et ses ensembles de fonctionnalités cohérentes.

Après quelques éléments de présentation, un tableau des principales fonctionnalités couvertes par les versions de septembre 2019 vous permettra un premier aperçu. N’hésitez pas à essayer, et à suivre l’évolution de ces logiciels !

  • Son manifeste : L’objectif d’ArchiFiltre est de proposer à tout utilisateur de fichiers bureautiques un outil de visualisation d’arborescences complètes afin de pouvoir les appréhender rapidement en vue de les décrire, les organiser, les trier et aussi les enrichir en apportant de la contextualisation et de la qualification aux documents.
  • Son histoire : l’outil est né en 2018 dans le cadre du programme « entrepreneurs d’intérêt général » (porté par la DINSIC). Depuis avril 2019, il a rejoint l’Incubateur des ministères sous forme de startup d’Etat et les développements se poursuivent (corrections d’anomalies, nouvelles fonctionnalités). Le chef de produit (responsable du pilotage de l’équipe projet) est le bureau des archives (également mission des archives de France auprès des ministères sociaux). L’outil est libre et gratuit et se construit en fonction des besoins exprimés par les utilisateurs.
  • L’équipe du produit peut être contactée à l’adresse archifiltre@sg.social.gouv.fr.
  • Où le trouver : https://archifiltre.github.io/ (application en téléchargement)
  • Un peu de technique : V12 Lucky Llama est une application locale, exécutable à la fois sur des postes en 32 bits et en 64 bits sans installation, la version 64 bits est disponible également sous Linux ; la V8, dernière version utilisable par navigateur web (Chrome ou Firefox) est toujours accessible sur le site.
  • Le code est entièrement accessible sur github (https://github.com/SocialGouv/archifiltre) et ouvert aux contributions.

 

  • Son manifeste : Outil de Constitution et de Traitement Automatisé des Versements Électroniques (OCTAVE) permet à l’archiviste de traiter après import des arborescences bureautiques (dédoublonnage, tri, fusion, classement, renommage), d’enrichir les métadonnées et de constituer des SIP aux formats SEDA 1 et SEDA 2.1 accompagné d’un manifeste xml, tout en pouvant produire bordereau de récolement et d’élimination
  • Son histoire : il est le fruit d’un certain nombre d’actions menées par le SIAF pour répondre à la problématique du vrac bureautique et notamment l’animation en 2015 d’un groupe de travail transverse et d’un recueil de cas d’usage, un benchmark international des outils de préparation des versements déjà existants, pour prendre une tournure concrète avec le démarrage de développements en novembre 2017. Tests, échanges avec les utilisateurs, séances de sensibilisation ont permis de faire des ajustements et d’aboutir à la présente version qui a été l’objet d’un audit de sécurité informatique commandé par le RSSI du Ministère de la Culture à Ernst & Young.
  • Contact : le SIAF rassemble les retours d’expérience sur OCTAVE à l’adresse archivage.numerique.siaf@culture.gouv.fr
  • Où le trouver : https://francearchives.fr/fr/article/88482499 (Téléchargeable  accompagné d’un manuel d’utilisation)
  • Un peu de technique : Version de septembre 2019 basée sur la version 5.3 de Docuteam Packer, logiciel libre, développé en Java par la société Docuteam https://www.docuteam.ch/fr/.

 

RESIP
  • Son manifeste : L’application ReSIP, construite au-dessus de la bibliothèque sedalib, permet de construire et manipuler des structures arborescentes d’archives, d’en éditer les métadonnées, de les importer et exporter sous la forme de SIP, sous la forme de hiérarchie disque ou encore sous forme csv pour les plans de classement. Elle peut prendre en compte des fichiers bureautiques ou des conteneurs de messagerie.
  • Son histoire : L’objectif était initialement de créer un outil pour faciliter le travail de recette des archivistes de l’équipe Vitam. En effet, dans le cadre des développements Agile, ils sont amenés à tester les développements réalisés à l’issue de chaque itération et donc à effectuer de multiples tests d’entrées de paquets d’archives (SIP) dans Vitam. Au commencement des développements en 2016, ces jeux de tests étaient réalisés manuellement rendant très long et fastidieux le travail de recette. Un outil, le « générateur Seda » a donc été créé pour industrialiser la réalisation des jeux de tests. Cette moulinette, rapidement adoptée par les archivistes de l’équipe projets Vitam et des projets utilisateurs, a été plébiscitée et priorisée pour en faire un réel outil de production pour la préparation des entrées d’archives. Les fonctionnalités en ont été améliorées et complétée au fil des itérations, aboutissant à l’actuel RESIP.
  • Contact : contact@programmevitam.fr
  • Où le trouver: http://www.programmevitam.fr/pages/ressources/resip/
  • Un peu de technique : version courante 1.10.0-SNAPSHOT compilée le 01/09/2019, fichier exécutable portable nécessitant la présence de Java 8, une version Linux est disponible également.
Tableau des fonctionnalités d’Archifiltre, Octave et Resip, septembre 2019
Tableau des fonctionnalités d’Archifiltre, Octave et Resip, septembre 2019