Migration vers la version V7 d'Arkothèque

Étapes

• Automne 2021 : Commande de migration par la DSI au prestataire 1egal2 sur la base de son devis
• 29 mars 2022 : réunion de lancement DSI/Rize/1egal2
• mai-octobre 2022 : migration
• formation pour permettre la mise en ligne de fond programmée au cours de la migration en juillet.

Réunion de lancement (29 mars 2022)

Rize : points à évoquer lors de la réunion de lancement avec Franck Bernardet, 1egal2

• Problème de FTP pour mise à jour des bases des fonds sériels existants (dépôt des images impossible) > A résoudre impérativement sinon, il est impossible de maintenir les bases existantes.
• VU :
• La DSI va vérifier si elle autorise les dépôts FTP sur serveur de 1egal2. FAIT le 20/07/2022
• La DSI va orienter 1egal2 sur un interlocuteur dédié. FAIT le 20/07/2022
• 1Egal2 doit transmettre ses spécifications à l'interlocuteur DSI. FAIT le 20/07/2022
• Possibilité d'un moteur de recherche transversal en page d'accueil du Rize ?

1. Validation des index > procédure à déterminer

• VU : possible sur les fonds sériels si import correct des instruments de recherche en xml. Suppose :

1. Mise à jour des index dans Avenio. Voir ci-dessous Mise à jour des index dans Avenio.
2. Export des instruments de recherche en XML. Voir page Export avenio pour les manipulations à faire.
3. Intégration de ces XML mis à jour au moment de la migration (date à déterminer). Pourrons-nous créer des tables de relations entre les bases documentaires et les fonds sériels à la fin de la migration ? Par conséquent, sera-t-il possible de rendre les listes existantes communes à l'ensemble des bases et fonds sériels (logique d'indexation archivistique) ?

• Presque vu : Franck Bernardet : "cela dépend de la structure des données"
• Possible sur fonds sériels si correction des index en amont de l'export EAD
• Voir s'il est possible de le faire a posteriori sur les bases documentaires par export et réimport du csv de ces bases (voir avec nouvelle référente 1egal2). Sera-t-il possible de géoréférencer des documents de fonds sériels (exemple : cartes postales) à la fin de la migration ?
• VU : la V7 d'Arkothèque permet d'ajouter des coordonnées GPS dans des colonnes de fonds. Suppose :
• 1. de géoréférencer les fonds en question
• 2. de réimporter les descriptions des fonds avec les colonnes dédiées (comment si XML?)
• 3. de payer 1500€ à 1egal 2 pour la restitution cartographique. Problème important à résoudre concernant les filtres de recherche dans les bases de données et les fonds documentaires : pour l'instant, il est nécessaire d'écrire les mots sans accents pour que cela marche.
• Presque vu : Franck Bernardet indique qu'il faudra régler ce problème au moment de la configuration des moteurs de recherche du site migré
• 1. A voir en formation
• 2. A vérifier suite à la migration 

Demandes Franck Bernardet

• Besoin que le Rize lui envoie ce qu'il appelle des "inventaires" qui sont en fait des inventaires archivistiques et des instruments de recherche en XML (gros travail supplémentaire en amont pour le Rize) > Fourniture le 02/05/2022 des inventaires EAD à jour à 1egal2 (envoi Wetransfer).
• La validation des fonds sériels suppose que les équipes du Rize soient formées :
• 1. aux fonds sériels > avant la fin de la migration de ces fonds > Vincent, Nolwenn, Emanuela archives
• 2 . aux CMS > avant la fin de la migration de ces fonds > Vincent, Nolwenn, Anne-Marie, Lisa
• Contraintes techniques :
• Possibilité de mettre à jour les fonds sériels et bases documentaires suite à leur migration (en fin de processus)
• Indisponibilité du CMS pendant sa phase de migration > A suivre attentivement
• Besoin d'une synthèse sur la pertinence de faire migrer certains fonds précisions (terminés ou alimentés au fil du temps) > Nolwenn
• Vu : conserver tous les fonds.
• Fonds sériels "Archives orales" et "Délibérations (1D) : les champs sont préconfigurés pour les fonds et bases qui seront à remplir après la migration.
  
• Bases documentaires "Atlas du bâti villeurbannais" et "Plans cadastraux de la Ville de Villeurbanne" : les champs sont préconfigurés pour les fonds et bases qui seront à remplir après la migration.
• La base documentaire "Bibliographie" est utilisée par les bases "Inventaire des voies" et "Carnet de mémoires villeurbannaises" (champs en lien vers base doc).

Fonds en attente de mise en ligne

• délibération numérisées
• plans cadastraux numérisés
• inventaire des oeuvres d'art dans l'espace public

Points sur l'habillage à voir avec Gregory,1egal2 à voir par mail

• Comment va être organisé la refonte de l'habillage responsive ?! Rubrique "Encyclopédie" faite avec un modèle de page sur mesure à refondre entièrement problème d'accessibilité sur mobile de l'inventaire EAD accessibilité du modèle des bases de données sur mobile discutable (menus en bas et non en haut de page)
• Combien de modèles de pages seront-ils créés lors de la refonte de l'habillage ?Pour mémoire : nous utilisons actuellement le plus souvent le modèle de page sans titre, celui appelé "modèle type" ne sert que pour l'encyclopédie, nous aimerions utiliser celui de l'exposition "sans visionneuse", mais nous ne le faisons pas car il comporte un filtre de recherche dédié à l'encyclopédie (ce qui crée de la confusion chez l'utilisateur).
• Pourrons-nous créer des modèles de pages ou simplement modifier quelques paramètres de modèles fournis. Si oui, quels sont ces paramètres ?

 Mise à jour des index dans Avenio

(réunion téléphonique avec Bruno Favrit, le 26 avril 2022).

Contexte

Certains index d'Avenio comportent plusieurs milliers de termes, dont les syntaxes sont hétérogènes et qui comportent des doublons. Ce point est rédhibitoire pour les requêtes dans la base. Au vu du nombre de termes concernés, il n'est pas réaliste de les modifier un à un. Le nettoyage de ces index passe nécessairement par un travail comportant des corrections automatiques, et plus globalement un mapping systématique des termes employés.

Étapes de travail 

Un premier travail de nettoyage a été réalisé à partir d'extractions au format .xlsx. Celui-ci a permis de proposer une syntaxe systématique basée sur les recommandations des Archives Nationales (gestion des SIA et web des données).

Ces propositions restent à valider avant leur intégration dans Avenio > processus de validation à préciser.

Au cours de l'entretien téléphonique que nous avons eu avec lui, Bruno Favrit (d'Avenio) nous a confirmé qu'il est nécessaire de suivre une procédure très stricte pour la mise à jour des index, si l'on souhaite passer par un import/export.

1. Supprimer les doublons d'index dans Avenio, selon une méthode qu'il a décrite par téléphone. Cette approche permet de s'assurer qu'il n'y a qu'un numéro de fiche Avenio par entité d'index. Ce point est indispensable pour la suite.
1. Lors du réimport des index modifiés, c'est le numéro de fiche qui sert de clef primaire à la table concernée. Les valeurs des autres champs sont remplacées par celles contenues dans l'index importé.
2. Chaque table d'index est reliée à d'autres tables contenant les cotes et descriptions des documents indexés. Là encore, le numéro de fiche sert de clef primaire afin de conserver ces liens vers les descriptions de fonds, alors que les valeurs des champs de la table d'index sont modifiés.
2. Avant d'exporter, il est préférable de supprimer les retours chariots qui perturbent l'organisation des champs. Utiliser une formule communiquée par Bruno Favrit pour remplacer les retours chariots dans les champs des tables concernées. Voir Supprimer les retours chariots dans Avenio.
3. Exporter les index à mettre à jour. Il est plutôt recommandé de le faire en format txt (après avoir supprimé les retours/chariots) pour un import ultérieur selon le même format. Le problème dans le cas de différents index, c'est que certains champs contiennent du html, ce qui rend cette méthode inopérante. L'export en xml semble donc le plus indiqué. En effet, les balises xml pourraient servir de séparateur de champ adéquat (Note NLG: l'utilisation d'Open Refine, de plus en plus utilisé en archivistique à cet effet, pourrait permettre de manipuler le xml ainsi obtenu : à tester). A défaut, reste la possibilité d'utiliser comme séparateur de champ en .csv un caractère qui n'est jamais utilisé (par exemple µ) : à tester aussi (déjà testé en export : fastidieux, mais ça marche).
4. Modifier les index en batch hors d'Avenio avec Open Refine (méthode Archives nationales) ou R (nettoyage de donnée semi-automatisée tidy).
5. Faire des tests d'imports sur une copie de la base de données Avenio du Rize, à l'aide de la version monoposte gratuite d'Avenio communiquée par Bruno Favrit.
6. Une fois la méthode d'import validée par des tests, réaliser les imports définitifs sur la base Avenio originale.

Par conséquent, la réalisation de tests suppose :

• La copie provisoire (le temps du projet) de la base de données Avenio pour réaliser les tests et l'installation de la version monoposte selon la méthode suivante, communiquée par Bruno Favrit :
• Dézippez le fichier sur le disque (emplacement indifférent). Vous obtenez un répertoire Avenio.
• Raccourci bureau sur AvenioV11. exe
• Copiez votre base de données stockée sur le serveur (fichier Avenio.4DD, stockée par défaut sous Avenio Server\Server Database).
• La coller sous Avenio\Database.
• Au premier lancement de l'application, une question relative au répertoire Documents_Avenio s'affiche.
• Répondez OK à tout.

Une fois la mise à jour des index dans Avenio réalisée, il est possible de les réexporter au format XML et de transmettre leur mise à jour à 1egal2. Ces XML auront alors la même structure que ceux communiqués en début de projet. Il s'agira de simples mises à jour d'index.

La migration en cours a soulevé de nouvelles problématiques : lors de l'export des inventaires en EAD-XML depuis Avenio, il y a plusieurs problèmes de conversion liés :

• à l'encodage des caractères (Avenio réalise des exports soit en Windows 1254, soit en UTF-8, plus vraisemblablement en Windows 1254, à vérifier) ; 
• à la présence de caractères spéciaux éventuellement invisibles et notamment des retours-chariots en html, qui ont ensuite éte convertis dans plusieurs langages. 
• Ils correspondent peut-être à des copier-coller effectués depuis un logiciel de traitement de texte dans Avenio. Il est possible qu'ils aient ensuite été convertis au sein d'Avenio, soit au moment du copier-coller, soit lors de l'export vers l'EAD.
• Voir mail d'un développeur d'1egal2 en base de page pour plus de détails.