Première journée Icono-réseau: compte-rendu

Ce billet a été initialement publié le 7 juin 2013 sur le ‘carnet de recherches’ Mame&fils.

Le 5 juin 2013 s’est tenue à la MSH Val de Loire (Tours) la première journée du programme Icono-réseau. Nous avions choisi de la consacrer à Omeka, en commençant par permettre à ses usagers de s’exprimer. La matinée a donc été consacrée à un ample tour d’horizon des utilisations actuelles, par des équipes et projets de recherches, de l’application Omeka, tandis que l’après-midi, plus technique, invitait à entrer dans les fonctionnalités de l’application.

Mame et fils

Déjà longuement évoquée sur ce carnet de recherche, l’aventure de l’ANR Mame avec ses données bibliographiques a fait l’objet de la première intervention. Omeka, dans ce cas, a été la solution proposée comme alternative à une base de données propriétaire (Filemaker Pro), dans le but initial de permettre la collecte, l’archivage et surtout le tri qualitatif des données bibliographiques, puisque le projet de recherches portait surtout sur des livres.

Pourtant, c’est peu dans sa fonction base de données qu’Omeka a servi l’équipe: en effet, il est arrivé trop tard dans le projet; la saisie des données est plus fastidieuse et contraignante que sur Filemaker; et les fonctionnalités de requête et de tri moins satisfaisantes. En revanche, il a permis la mise en valeur des résultats de la recherche, par la possibilité qu’il offre de publier les données “enrichies” (non pas de simples notices de bibliothèques, mais davantage des notices de bibliophile, comportant des informations peu normées mais intéressantes pour le chercheur, comme les ex-præmio permettant de suivre la vie du livre après sa production). Il a surtout séduit l’équipe par la possibilité ultérieure d’éditorialiser les données, c’est-à-dire d’en proposer au public une version moins linéaire, scénarisée et pensée comme une exposition, accompagnée d’un texte qui leur donne sens, à travers la fonction d’exposition virtuelle.

Mutual Heritage

Le projet Mutual Heritage, financé par l’UE, s’intéressait à l’architecture des XIX^e-XX^e siècles dans le bassin méditerranéen, surtout le petit Maghreb. Le premier “livrable” choisi par les équipes a été la composition de cartes (papier), assez hétérogènes selon les équipes locales. L’objet de l’étude suggérait en effet une très simple entrée spatialisée, pour laquelle la carte s’imposait comme naturelle. Pourtant les équipes ont eu le sentiment que le projet aurait dû permettre de croiser davantage les données, d’un pays à l’autre, pour la bonne raison que les acteurs de ces créations architecturales avaient eux-mêmes beaucoup circulé au sein des territoires considérés: il y aurait donc intérêt à réunir un savoir morcelé. D’où l’idée d’utiliser Omeka, dont on attendait qu’il présente, sous un même portail, l’accès à trois bases autonomes. Par rapport au projet précédent, ici le réseau pré-existait au choix d’Omeka, qui devait remplir cette fonction de mise en commun de la connaissance.

Si l’équipe s’est formée de manière rapide et efficace, car le maniement du logiciel est simple, en revanche il a fallu constater une certaine démotivation: la saisie des données iconographiques (nombreuses pour chaque bâtiment étudié) est certes simple, mais fastidieuse… D’où quelques questions, qui reviennent tout au long de la journée: quelle plus-value apporte Omeka au chercheur individuel, qui va lui donner le sentiment que ses efforts seront payés de retour, et à court terme? Une autre question est soulevée ici: Omeka peut-il être utilisé pour générer des contenus facilement exportables sous d’autres format: des notices “type inventaire”, par exemple, dans le cas de l’architecture; ou des diaporamas immédiatement projetables sous Powerpoint, par exemple? Voire des articles en PDF… Romeo Carabelli rappelle ici que nous sommes en face de projets de recherche: les chercheurs qui y sont engagés ne sont pas en train d’élaborer des infrastructures, ce qui est le rôle des institutions; ils produisent du savoir et des informations, mais ils en sont les premiers utilisateurs…

Benoist Lawniczak, présentation des bases du programme Rihvage

Le projet Rihvage réunit des chercheurs de toutes disciplines autour des châteaux de la Loire. Si l’équipe a choisi Omeka, c’est à cause de son usage des normes standards (ici, le Dublin Core), mais aussi sa compatibilité avec Zotero, produit par la même équipe, le Roy Rosenzweig Center for History and New Media. La base, en cours, recense tous les guides qui évoquent les châteaux de la Loire, et renvoie vers des versions numérisées quand elles existent; à terme des numérisation seront entreprises localement. Le projet démarre: les questions se posent donc à mesure de l’usage. À terme, les fiches seront couplées avec une vaste collection iconographique, correspondant partiellement à des fonds existants, rattachés au CESR.

La discussion s’engage déjà: les projets sont différents, dans leur temporalité, dans leurs objets, dans les demandes des chercheurs. Un participant remarque que ce qui vient de nous être présenté est un projet de documentation, pas de recherche: où sont les chercheurs, dans cette configuration? BL explique qu’aucun d’entre eux n’est en effet venu à la journée, et qu’il ne peut pas évoquer à leur place leurs usages des données collectées — mais cette remarque en recoupe d’autres, que nous ferons au cours de la matinée: si Omeka semble efficace pour mettre en valeur des données, iconographiques ou non, il rend des services moins évidents pour la recherche. Ce serait donc plus un outil de valorisation et de documentation, que d’appui à la recherche?…

Sabrina Bresson, présentation de Alter-Prop et Eclips

Le projet Alter Prop réunit des chercheurs en sociologie et en droit autour des alternatives de propriété pour l’habitat (coopératif, “participatif”, etc). L’intérêt pour Omeka est né de la nécessité de travailler en commun malgré la dispersion géographique: on attendait du logiciel la possibilité d’archiver et de mettre en commun la documentation utile. En parallèle, l’équipe avait commencé un recensement des projets d’habitat participatif, et cette base de données devait aussi être accessible à tous les membres du projet. Cette double logique (recensement + documentation) a abouti à deux Omeka. La grande difficulté a tenu au fait que le corpus n’était pas défini à l’avance, c’était un perpétuel work in progress. Par ailleurs, l’accroissement considérable de la littérature critique sur ces sujets a rendu le travail de veille et surtout de saisie des publications très fastidieux… d’autant que personne n’avait été missionné pour le faire: les chercheurs le faisaient “en plus” de leur recherche. On voit apparaître ici un autre des leit-motiv de cette matinée: Omeka est un bon logiciel, mais il n’est pas aussi souple d’usage, pour le chercheur, que ses petits “bricolages” personnels; par ailleurs, mettre en commun une documentation, dès qu’elle devient abondante, demande de la rigueur et du professionnalisme, ainsi que du temps de veille documentaire et de saisie: c’est le travail… d’un documentaliste.

L’équipe attendait aussi d’Omeka qu’il soit un outil de valorisation.  Des “collections” ont été crées, pour rendre disponibles les documents issus des séminaires (PDF, diaporamas, enregistrements audio) ainsi que les publications de l’équipe. Ici s’ébauche une discussion sur un autre des points forts de cette journée: la pérennisation des données mises en valeur par Omeka. Attend-on de l’outil un simple support à la recherche, ponctuel, sur la durée d’un programme financé? Ou est-on en mesure (financièrement, techniquement, institutionnellement) de le faire exister durablement, à la manière dont l’institution veille à ce que les publications (livres, thèses) soient durablement à la disposition de la communauté des savants, via les bibliothèques universitaires? Il y a une réflexion à mener, qui engage aussi la politique d’archivage de l’institution dans son ensemble.

Sophie Caratini, Francesco Correale, Biblimos

“Biblimos” est un projet de bibliothèque virtuelle des sources inédites de l’Ouest saharien, réunissant des archives des pays européens traitant de cette région et des archives et manuscrits africains de cette région. L’équipe est internationale et pluridisciplinaire. Les chercheurs ont souhaité participer à la journée Omeka dans le but de faire ultérieurement leur choix de manière éclairée; Farouk Mohamedade, informaticien à l’université de Nouakchott et récemment arrivé à Tours, participe aussi aux débats. L’objet de la recherche inclut une essentielle réflexion sur le multilinguisme; confronter les témoignages archivistiques différents d’un même événement invite à s’interroger sur les termes dans lesquels ces événements sont évoqués, dans chaque langue, et sur les recouvrements ou les éventuels conflits qui naîtraient des diversités de conception et de formulation. Il faut concevoir en amont la manière dont les sources recueillies vont être traitées en termes documentaires; Omeka serait-il à même de gérer la complexité du multilinguisme?

Une discussion s’engage, au-delà de l’intérêt notable de Biblimos, sur la relation du chercheur à l’outil. Nadine Michau  suggère que si beaucoup de chercheurs rechignent à investir ces outils, c’est peut-être parce qu’ils ne sont pas très bien pensés. Un chercheur peut s’investir sur un portail s’il s’y retrouve en tant que chercheur. On parle de l’intérêt “égoïste” du chercheur: son temps étant compté, il ne va l’accorder qu’à des efforts qui porteront leurs fruits pour lui aussi et  à court terme, c’est-à-dire dans le temps de sa propre recherche. Ce n’est pas du tout la logique d’une institution.

Julien Sicot, SCD Université Rennes 2

La liaison se fait par skype; Julien Sicot a pris soin de déposer son diaporama sur un serveur à notre disposition.

La bibliothèque numérique de Rennes 2  utilise Omeka pour mettre en ligne une collection de livres liés à la Bretagne (quelques manuscrits, quelques unica); la numérisation a été faite sur place, grâce à un financement ad hoc, mais la valorisation qui suit la numérisation est toujours le maillon faible, dans les bibliothèques. Omeka permettait un résultat très satisfaisant sans grosse équipe ni moyens gigantesques. Néanmoins, les fonctionnalités qui nous sont présentées par Julien Sicot sont assez impressionnantes… et demandent à son équipe beaucoup de bricolage avec le code, pour créer les plug-in adaptés aux souhaits de mise en valeur.

Julien Sicot présente tous les atouts qui ont conduit le SCD de Rennes 2 à élire Omeka: la possibilité de structurer les métadonnées en Dublin Core, garante de standardisation et d’interopérabilité, était évidemment le premier avantage; la possibilité de commencer “petit”, avec peu de données, permettait de développer le projet à son rythme; la capacité d’Omeka à gérer tout type de données (texte, image vidéo), sa simplicité de maintenance et de développement (il est open source) ont aussi guidé le choix.

Omeka a pourtant les défauts de ses qualités: quand on l’installe, il est assez pauvre. Julien Sicot énumère alors les plug-in choisis par son projet, pour passer au Dublin Core enrichi, générer des flux RSS, activer la compatibilité avec Zotero, importer des fichiers CSV (issus par exemple d’excel), la dropbox qui permet d’importer des données en masse et non une par une, le module de géolocalisation, celui qui autorise à faire une recherche texte au sein d’un PDF (extrêmement utile pour une bibliothèque numérique), le plug-in permettant de créer des listes de valeurs rattachées à un champ, ce qui facilite la saisie, l’auto-complétion à partir des autorités du SUDOC (via IdRef). La question de la visionneuse a été résolue en adaptant celle qui était présente sur Internet Archive (elle est en HTML5), et qui était open source; elle a été transformée en plug-in Omeka; on peut “embarquer” de la sorte les livres numériques, pour les disséminer via d’autres sites ou blogs. Enfin des plug-in développés par Sylvain Mâchefert (présent à notre journée) pour le SCD de Bordeaux 3 ont été installés à Rennes 2: PDF TOC permet d’extraire des signets qui ont été ajoutés à un PDF; Extract OCR permet d’extraire une OCR en XML. Grâce à ces deux ajouts, il a été possible de générer des tables des matières cliquables. Rennes 2 travaille par ailleurs à un nouveau schéma de visualisation, adaptable à tous supports (tablettes, smartphones…).

Julien Sicot évoque ensuite le workflow mis en place pour cette bibliothèque numérique, assez classique (je ne développe pas, il est détaillé sur ses diapos). Puis il passe à l’énumération des défauts et faiblesses d’Omeka: ce n’est pas un logiciel dédié à l’archivage, de ce fait l’organisation des dépôts est un peu chaotique. La gestion des collaborations multiples manque de souplesse. Par ailleurs, un item ne peut pas appartenir à plusieurs collections, ce qui gêne parfois la fluidité du traitement des données. On évoque aussi la difficulté relative du passage (tout récent) à la version 2.0 d’Omeka, pour laquelle tous les plug-in ne sont pas encore opérationnels. Julien Sicot souligne, et cela fait réagir des chercheurs dans la salle, la relative faiblesse d’Omeka en termes de requêtes (“recherche avancée”), or beaucoup d’équipes de recherches attendent d’Omeka une fonction “base de données” substitutives à des formats propriétaires… Stéphane Loret précise qu’avec Apache Solr, hélas difficile à maintenir, ou peut développer les potentialités de requêtes d’Omeka.

Emilie Trébuchet, INRAP-LAT

Archéologue à l’INRAP, documentaliste, chercheur au LAT, Emilie Trébuchet a suivi à Toulouse une formation qui a donné lieu à la création d’une iconothèque de documents liés à l’archéologie toulousaine. De retour à Tours, elle souhaite mettre en place une iconothèque similaire consacrée à l’archéologie sur le site de Tours (photos, cartes postales, gravures, estampes), pour remédier à la totale dispersion des documents. Ses questions concernent les capacités d’Omeka à gérer autant d’informations, à ses yeux capitales, qu’elle pouvait en manipuler à Toulouse sur la base access qu’elle utilisait.

Sylvain Machefert, SCD Bordeaux 3, projet 1886

Le projet 1886 présenté par Sylvain Mâchefer pour la BU de Bordeaux 3 est assez similaire à celui de Rennes 2. Des éléments ont été numérisés (300 ouvrages, 1500 photos). L’objectif était de proposer des services aux chercheurs, en appui à des ANR (par exemple autour du fonds Paris, lié à l’histoire de l’université et de ses bâtiments). Il s’agit donc ici d’un Omeka « central », à vocation de diffusion. Les chercheurs ont travaillé dans leur base Filemaker ; les données ont ensuite été exportées en CSV (Excel). De même, le catalogage a été fait au sein du SCD à partir des protocoles habituels, familiers aux opérateurs (en l’occurrence, le SUDOC). Dans les deux cas, il s’agissait de respecter les manières de travailler familières à tous les utilisateurs, afin de ne pas ajouter une couche de formation au travail de saisie ou de recherche. Par ailleurs, on a pris soin de multiplier les liens avec des bases de données institutionnelles existantes (comme Mérimée). [voir une autre présentation du même projet ici]

Une discussion s’engage alors sur la connectivité, essentielle à ces différents projets – c’est le sens du terme “réseau” dans l’intitulé “icono-réseau”. Plus largement, le débat se déploie autour de l’engagement des institutions dans ces iconothèques montées par ou pour la recherche. En effet, les divers projets présentés au long de cette matinée émanent soit d’équipes de recherches, soit de groupes constitués ad-hoc pour un projet, et menacés par la disparition des subsides à la fin du financement, soit d’institutions stables et pérennes (SCD par exemple, ou bibliothèques). Il semble clair que ces dernières sont plus en mesure de donner à Omeka tout son rayonnement, de développer toutes ses potentialités, parce que des informaticiens peuvent installer et développer l’application tandis que des documentalistes et bibliothécaires sont chargées d’une partie des tâches de saisie. Les chercheurs, au contraire, sont à la fois bridés par les temporalités réduites, et frustrantes, des programmes courts, et parfois découragés par les efforts chronophages que nécessite l’utilisation d’Omeka. Il semble donc, au terme de la matinée, que si les services que rend Omeka au chercheur en tant qu’outil de la recherche sont parfois considérés comme discutables (du fait du mauvais rapport entre investissement dans la saisie des données, et possibilité d’usage de ces données, notamment quantitatives, pour produire les résultats de la recherche), en revanche il semble très opérationnel pour la mise en valeur des résultats de la recherche – et pour cette raison, plébiscité par les instances de mise en valeur que sont les bibliothèques, ce qui explique peut-être pourquoi les plug-in les plus développés par la communauté des utilisateurs sont orientés livre et bibliothéconomie. Plus qu’une iconothèque, Omeka serait-il une “bibliothèque numérique” clés-en-main?

Les discussions très riches et ouvertes de la matinée font apparaître par ailleurs, du côté des chercheurs, deux problématiques récurrentes: celle des métiers, et celle des institutions. Côté métiers, tous les projets ou presque ont  montré que, de manière plus ou moins consciente, les équipes ont besoin de s’adjoindre les compétences professionnelles d’un(e) documentaliste, aussi bien pour aider les équipes à structurer leurs données selon les normes standards que pour effectuer des tâches indispensables de veille sur la documentation spécialisée, puis de mise en valeur des résultats de la recherche. De manière évidente, elles ont besoin aussi de pouvoir s’appuyer sur des informaticiens, puisque Omeka, tout “élémentaire” qu’il soit, doit être installé, maintenu, développé par des professionnels, qui auront aussi pour charge de former les utilisateurs, mais aussi d’être à l’écoute de leurs besoins, pour les traduire dans la logique de l’application (quand créer une “collection”? à quel moment un champ de métadonnées “libres” s’impose-t-il?). Enfin, et c’est sans doute un peu nouveau pour nous, il est apparu que le développement des “humanités numériques” et le recours de plus en plus spontané des chercheurs à des sources numériques incite les chercheurs  à souhaiter “publier” (au sens étymologique: rendre publiques) les produits de leur recherche… mais que ces souhaits se traduisent parfois par des démarches maladroites, voire contre-productives. Quelle est la résonance d’un simple diaporama déposé en ligne, d’un compte-rendu de workshop, d’un article encore “inédit” mais mis en ligne sous forme de PDF? Quelles données rendre publiques, lesquelles doivent rester confidentielles, autant pour protéger les ressources des chercheurs que pour des raisons juridiques et déontologiques? Toutes ces questions, on le voit, engagent la réflexion du côté du métier de l’éditeur. C’est lui en effet qui réunit les compétences nécessaire en termes juridiques (que peut-on rendre public et sous quelle forme?), en termes de mise en forme (quelle forme, notamment typographique, doit prendre un texte pour devenir “lisible”?), en termes de communication (un éditeur sait qu’un livre qui n’est pas “diffusé” est un livre perdu, son travail consiste donc autant à produire un livre qu’à le faire connaître à ceux qui ont un intérêt à le lire). Je crois qu’on dépasse ici les seules compétences d’un chargé de communication, et que nos réflexions de ce jour engagent une redéfinition des métiers, notamment celui du bibliothécaire-documentaliste et de l’éditeur à l’ère numérique.

Côté institutions, tous les chercheurs sont revenus, à un moment ou à un autre, sur la question de la temporalité: les projets financés ont une temporalité courte, limitée dans le temps; par ailleurs, le chercheur à titre individuel se situe lui-même dans une linéarité centrée sur lui-même (les divers programmes auxquels il participe, sa “carrière” avec ses différentes étapes obligées, l’échelonnement de ses publications…); il est donc indispensable que les institutions, le plus souvent les universités, apportent ici une couche de “temps long”, garantissant le suivi des plateformes (les mises à jour, la sécurité des données), le développement des bases Omeka au-delà du temps nécessairement limité des projets financé, la valorisation des résultats de la recherche sous forme d’expositions virtuelles – en somme, la “vie” des sites Omeka, perçus comme produits d’une université et de ses laboratoires.

Aussi bien en termes de métiers que de temporalité, il n’est pas impossible que les besoins que cette matinée ont permis de faire émerger soient justement les attributions d’un “atelier numérique” comme celui dont dispose la MSH Val de Loire, qui finance Icono Réseau.

L’après-midi, beaucoup plus technique, s’est tenue en comité réduit, beaucoup de chercheurs n’ayant pas de besoin spécifique en la matière. Il a été question des différents modules offerts par les versions récentes d’Omeka; les questions, plus pointues, engageaient des équipes déjà bien investies dans l’utilisation de l’application.

Nous retirons de cette journée le sentiment de n’avoir sans doute pas assez exploré la dimension “iconothèque” du logiciel – il faudra donc organiser une autre rencontre pour avancer sur cette thématique. Mais le nombre inattendu de participants, la diversité des projets présentés, et la richesse des échanges laissent à penser qu’une telle étape de mise au point était vraiment utile. Nous espérons que les commentaires à ce compte-rendu nous permettront d’avancer, et que ce travail aboutira à l’élaboration de conseils pratiques offerts à tous les chercheurs qui se lancent dans un projet nécessitant gestion de données iconographiques et mise en valeur web…

Montée originellement à Tours, puis en collaboration avec Orléans, cette journée s’est faite avec l’aide de la MSH de Nantes, à laquelle est maintenant rattaché Stéphane Loret; peut-être est-il temps d’officialiser ce partenariat: inutile en effet que les chercheurs, région par région, se heurtent partout aux mêmes problèmes; un bon usage de l’argent public consisterait à mettre en commun le fruit de ses réflexions et de ses expériences.

Cécile Boulaire, Romeo Carabelli, Stéphane Loret, Projet Icono Réseau

---

---