L’objet qui nous a réunis, alors que notre ancrage disciplinaire et nos objets de recherche sont très éloignés les uns des autres, est le logiciel Omeka, développé par le Roy Rosenzweig Center for History and New Media (RRCHNM) qui promeut aussi le logiciel de récupération et de gestion de références bibliographiques ZoteroVoir aussi le chapitre 3 « Zotero : la gestion de références bibliographiques et de corpus documentaires » de Chloée Fabre.↩︎. Omeka est un Content Management System (CMS) dédié à l’organisation, à l’exposition, à la mise en ligne de données iconographiques, avec leurs métadonnées, qui permet d’en faire très facilement une publication sur le Web. Ce chapitre sera pourtant consacré moins à Omeka qu’au rapport que nous entretenons, comme chercheurs, aux logiciels que nous utilisonsÀ cet égard, nous souhaitons manifester notre reconnaissance à l’équipe de ce qui fut Crévilles, et s’intitule désormais Atelier Numérique, au sein de la Maison des Sciences de l’Homme (MSH) Val de Loire, et en particulier à Stéphane Loret, qui a guidé nos réflexions.↩︎. Dans l’exemple d’Omeka, nous essaierons d’analyser l’usage que nous avons fait des diverses applications nécessaires à nos recherches, de comprendre les impasses que nous avons connues, et surtout, d’extraire de cette expérience quelques préceptes de bon sens destinés à la communauté des chercheurs en lettres, sciences humaines et sociales (LSHS).

C’est en effet comme chercheurs en LSHS que nous nous définissons, et c’est à ce titre que nous souhaitons réfléchir à notre posture dans le champ des humanités numériques (HN), en racontant comment nous sommes passés du stade de digital naive à celui, tout aussi modeste, de bricoleur numérique – le bricolage s’entend ici au sens où Claude Lévi-Strauss le défend, dans La Pensée sauvage : « une science que nous préférons appeler “première” plutôt que primitive », une science liée à l’accident, au « mouvement incident : celui de la balle qui rebondit, du chien qui divague, du cheval qui s’écarte de la ligne droite pour éviter un obstacle » (1962). Le bricoleur, selon l’anthropologue, est « celui qui œuvre de ses mains, en utilisant des moyens détournés par comparaison avec ceux de l’homme de l’art ». Nous souhaitons ici présenter les démarches de deux chercheurs en LSHS qui, parce qu’ils sont pris dans les réalités concrètes de la vie universitaire (en matière de moyens, de formation, de personnel d’accompagnement de la recherche), mais aussi parce qu’ils sont absorbés dans ce qui fait l’essence de leur métier, la recherche elle-même, en sont amenés à adapter les outils numériques à un faisceau de contraintes et de besoins qui leur sont propres… et qui changent avec chaque nouveau projet. Nous revendiquons l’appellation « bricoleurs » dans l’univers des HN. Ni développeurs, ni ingénieurs, ni documentalistes de notre propre recherche, ni photographes, ni chargés de communication ou de vulgarisation scientifique, nous avons pourtant besoin d’un petit peu des compétences de chacun de ces professionnels, pour faire avancer nos travaux. C’est donc armés de savoir-faire hétéroclites et animés par des besoins extrêmement précis et définis par notre recherche que nous abordons les outils des HN. Un peu comme nous utilisons notre voiture : nous aimons qu’elle fonctionne, et nous savons où nous voulons aller parce que nous avons quelque chose à y faire ; mais nous ne souhaitons pas apprendre la mécanique.

Nos projets

Pourquoi Omeka ? Au début des années 2010, nous sommes l’un comme l’autre engagés dans des projets de recherche (nationaux, européens) qui nous amènent à brasser des quantités importantes de données iconographiques et textuelles. Nous avons besoin de stocker ces données, de les classer, de les rendre accessibles aux autres chercheurs du projet, dispersés géographiquement. Nous pensons aussi à l’après, et imaginons déjà comment mettre ces données à la disposition d’une communauté plus vaste (autres chercheurs, simples curieux) en les rendant notamment accessibles sur le Web. Idéalement, elles devraient non seulement être accessibles à d’autres utilisateurs, mais mises en valeur, expliquées, éditorialisées, enrichies perpétuellement. L’un des projets concerne l’entreprise Mame, une maison d’édition de livres religieux et de livres pour enfants installée à Tours depuis la fin du XVIII^e siècle. Une équipe financée par l’Agence nationale de la recherche (programme Jeunes chercheurs) se consacre à son histoire, en tentant pour ce faire de reconstituer virtuellement une partie de son catalogue, car toute l’entreprise a brûlé, avec ses archives, en 1940. L’équipe a commencé à recenser les livres, en utilisant une base de données propriétaire, FileMaker, qui donne toute satisfaction… sauf pour la mise en commun des données, extrêmement fastidieuse. De plus, ce logiciel commercial n’est pas du tout pensé pour un débouché sur le Web alors qu’on souhaite pouvoir « montrer » la production Mame, la rendre publique, la partager. L’équipe recherche donc une solution de remplacement, d’autant qu’elle souhaite associer aux fiches bibliographiques rédigées par les chercheurs les photographies des livres, réalisées dans les bibliothèques et les fonds privés qui conservent une partie des publications. Ces photographies encombrent les disques durs des chercheurs, et sont à la fois difficiles à partager et mal répertoriées, car aucune réflexion sur leurs métadonnées n’a été envisagée d’emblée : nous avons pris des photos d’instinct.

L’autre projet, Mutual Heritage, concerne le patrimoine architectural et urbain récent dans le monde méditerranéen ; il a pour cadre plus large le programme européen Euromed Heritage 4. Ce projet vise à inventorier, documenter et promouvoir le patrimoine récent des XIX^e et XX^e siècles, afin d’encourager l’intégration du patrimoine culturel dans la vie économique et sociale actuelle. Les acteurs de ce programme, de provenances multiples, ont donc collecté des images photographiques d’éléments architecturaux patrimoniaux, pour les villes d’Alger, Casablanca et Tunis. Les chercheurs réalisent et documentent ces clichés géolocalisés sur le terrain. Ils sont la matière première de la recherche et de la réflexion ; ils peuvent aussi, à terme, constituer une base d’exemples à la disposition des professionnels concernés par les questions d’urbanisme et de patrimoine ; ils sont enfin destinés à être mis en valeur sous la forme d’expositions virtuelles qui récapituleront les principaux enseignements de cette recherche. Deux des points communs de nos projets résident dans le fait qu’ils sont l’un comme l’autre pris dans une temporalité contrainte (projets financés), et dans le fait qu’ils nous conduisent à brasser des données sérielles (ce qui est loin d’être le cas général en LSHS).

Après quelques errances (pour le projet Mame, elles sont exposées au jour le jour dans le carnet de bord Mame & filsConsulter la catégorie « Base de données » du carnet de recherches de l’ANR « Mame (1796-1975) : deux siècles d’édition pour la jeunesse ».↩︎), chacun de nous trouve au sein de la Maison des Sciences de l’Homme (MSH) de Tours (désormais MSH Val de Loire) une aide technique essentielle. Au sein de l’Atelier Numérique, nous sommes aiguillés vers la solution Omeka ; c’est à cette occasion que nous faisons connaissance, et mettons en commun nos interrogations de chercheurs.

Nos attentes de digital naive

Omeka est un Content Management System (CMS), c’est-à-dire un logiciel permettant de créer un site Web assez complexe avec une assistance technique limitée. En effet, une interface d’administration, avec des champs à remplir en langage naturel, sert d’intermédiaire à l’usager. À cet égard, si l’on est familier d’une interface de blog comme WordPress par exemple, on est en terrain (relativement) connu. La particularité d’Omeka, ce qui fait tout son intérêt pour des projets qui concernent le patrimoine, pour lesquels on cherche souvent à collectionner et mettre en ordre des images, c’est qu’il est précisément dédié à la mise en valeur de collections importantes. C’est d’ailleurs le terme utilisé dans la nomenclature même du logiciel pour organiser les données : celles-ci sont rangées en « collections ». À l’intérieur d’une collection, chaque élément (dans l’un des cas évoqués, c’est un livre des éditions Mame ; dans l’autre, c’est un bâtiment présentant un intérêt patrimonial) fait l’objet d’une description précise et normée. Le schéma de métadonnées choisi pour Omeka est le Dublin Core, qui a l’avantage d’être une norme internationale, permettant éventuellement le moissonnage automatisé des données (récupération de données comparables depuis des entrepôts Open Archives Initiative – Protocol for Metadata Harvesting (OAI-PMH), par exemple la Bibliothèque nationale de France (BNF), mais aussi mise à disposition, dans un entrepôt OAI-PMH, des données constituées par les chercheurs, à l’intention d’une communauté large). C’est par ailleurs un Dublin Core « enrichi » : en plus des 15 champs réglementaires du Dublin Core de baseVoir les 15 éléments de base du Dublin Core.↩︎, Omeka offre la possibilité d’utiliser 15 autres champs (on parle alors de Dublin Core « qualifié ») qui viennent s’ajouter aux premiers, ou plutôt les raffiner (grâce au plugin Dublin Core Extended). Enfin, il ouvre encore la possibilité de définir soi-même certaines entrées (Item Type), selon une nomenclature personnelle, en plus des champs de base.

On peut associer des images à chaque élément de la collection : pour les livres, nous pouvons ainsi inclure une photographie du premier plat de couverture, de la page de titre, des illustrations, voire de toutes les pages qui présentent un intérêt particulier par rapport au projet (préface ou ex præmio par exemple) ; pour les bâtiments, il est possible de proposer plusieurs vues, ainsi que des détails pertinents. Et puisque chacune de ces photographies est en elle-même une source, nous pouvons éditer une notice descriptive pour chaque photo ; elle donne accès, par exemple, aux données EXIFExchangeable Image File Format.↩︎ et XMPExtensible Metadata Platform. En savoir plus sur les données XMP.↩︎ de la photo, mais aussi à tout commentaire singulier que souhaiterait inclure le chercheur. Il est possible aussi d’adjoindre à chaque document un lien hypertexte vers une ressource Web, ou une source extérieure, par exemple un PDF. Omeka remplit ainsi une fonction de base de données. Lors de l’affichage Web, l’internaute a accès à des champs de requête, qui peuvent lui permettre de demander par exemple tous les livres publiés dans la Bibliothèque de la jeunesse chrétienne en 1850, ou tous les bâtiments d’Alger dessinés par l’architecte Gabriel Darbeda.

Mais Omeka peut aussi servir à mettre en forme ces données, de manière plus linéaire et plus construite que sous la forme d’un vaste réservoir de données brutes. Le plugin Exhibit Builder permet en effet de créer des expositions virtuelles. Autant dans la première phase du travail le chercheur se sert d’Omeka comme d’un outil d’appui à sa recherche, lui permettant de rationaliser l’indexation et le partage des données collectées sur le terrain, autant dans cette seconde phase il se retrouve dans sa posture intellectuelle favorite, celle qui consiste à donner sens à un amas de faits, d’images, de phénomènes. Il va sélectionner les images qui lui paraissent les plus à même de faire percevoir les réalités essentielles ; il va mettre en valeur ces images en les commentant ; il va organiser le parcours intellectuel de son lecteur, construire un discours élaboré, scénariser la mise en forme des conclusions de sa recherche, comme on le fait en établissant la table des matières d’un ouvrage de synthèse ou en assurant un commissariat d’exposition. Ici, l’intérêt d’Omeka réside dans la possibilité d’organiser très facilement ces expositions sur le Web. L’interface qui contient de manière préprogrammée quelques types de mise en page facilite la mise en forme ; on puise les images dans les collections, et le chercheur rédige librement les textes explicatifs. Le programme Mutual Heritage a ainsi monté une exposition virtuelle intitulée « Des styles architecturaux variés », qui permet une entrée synthétique dans le corpus et les réflexions de l’équipe de rechercheCette exposition n’est actuellement plus en ligne, car elle n’a pas supporté la montée de version. Voir les pages archivées par Internet Archive.↩︎. Le programme Mame a créé une exposition consacrée aux albums publiés durant l’entre-deux-guerresVisiter l’exposition virtuelle Les albums Mame de l’entre-deux-guerres, commissariat Marie-Pierre Litaudon. Exposition en sursis : elle aussi risque de mal vivre la montée de version.↩︎. Ces expositions sont complémentaires à la mise à disposition des données intégrales.

Nos déceptions

Tout cela semble parfait, et facile. Mais dans la réalité, les choses ne se déroulent pas de manière linéaire, loin de là. Peut-être parce qu’on nous propose la solution Omeka en cours de projets, et non à l’ouverture de ceux-ci – mais à l’ouverture précisément, nous ne savions ni l’un ni l’autre que nous allions avoir besoin de ce type de produit ! C’est bien l’expérience de nos terrains qui fait émerger le besoin d’outils permettant de négocier les données produites par l’enquête. De ce fait, l’un comme l’autre, dans nos équipes, nous avons mis en place (ou laissé s’installer de manière anarchique) des méthodologies et des démarches disparates, qui se révèlent à ce stade peu compatibles avec la rigueur (très souvent perçue comme de la rigidité) d’un CMS comme Omeka.

Un exemple : les chercheurs du projet Mame sont à parts égales des historiens et des littéraires, des usagers de catalogues de bibliothèques, mais n’ont pas reçu de formation au catalogage normé. Lorsqu’ils ont entre les mains un ouvrage de la maison Mame qui leur paraît présenter de l’intérêt pour la recherche collective, ils le décrivent donc en privilégiant des informations pertinentes pour eux, par rapport à leur orientation épistémologique – certes, en respectant quelques fondamentaux concernant les références bibliographiques, mais en ajoutant des champs de description très personnels, et très liés à la nature des informations que l’équipe a besoin de réunir, parce que justement aucun catalogue de bibliothèque existant ne les a fournies jusque-là. Le cas est loin d’être anecdotique. Un débat récent entre Stéphane Vial et Pierre Lévy sur le blog Design & Digital Humanities rappelle que l’une des grandes activités des chercheurs en LSHS consiste justement en ce que Lévy appelle la « curation », c’est-à-dire l’établissement de ces corpus et bases de donnéesVoir Vial (2015). Lire le débat entre l’auteur et Pierre Lévy dans les commentaires visibles sous l’article.↩︎, à partir d’observations de terrain et de dépouillements.

L’équipe de Mame a donc constitué sa propre base de données, aidée en cela par la souplesse de prise en main de FileMaker… or la convertir en Dublin Core pour passer sur Omeka va se révéler très compliqué et fastidieux. Techniquement, ce n’est pas impossible : il est toujours imaginable d’exporter les données de FileMaker vers un tableur ; et le module CSV Import d’Omeka permet de récupérer ces données. Encore faut-il pouvoir « glisser » les informations que l’équipe a considérées comme importantes, et qu’elle a organisées selon sa logique propre, dans le schéma contraignant du Dublin Core ! L’opération est possible, mais elle conduit souvent à fusionner des informations initialement distinctes pour les intégrer à un même champ, ce qui prive de la possibilité de faire des requêtes fines sur ces champs « écrasés ». Or il est hors de question, pour les chercheurs, que l’effort de normalisation technique fasse disparaître des informations scrupuleusement amassées pour leur qualité inédite. L’exercice de bascule représente donc une acrobatie intellectuelle qui freine la recherche plus qu’elle ne l’aide – ce stade, plusieurs chercheurs de l’équipe s’interrogent sur la pertinence d’un outil dont la prise en main demande tant de temps et d’efforts, pour un résultat moins satisfaisant.

Certes, on aurait pu éviter facilement une telle dépense d’énergie par une réflexion anticipée sur la structuration des champs de saisie. Mais nous avons tous fait l’expérience de données non prévues dans un protocole de recherche initial – parce que nous n’avions pas anticipé l’existence de ces informations, ou l’intérêt qu’elles pourraient présenter, une fois réunies – et qui se révèlent pourtant centrales, en cours de route, pour produire un regard entièrement neuf sur nos objets. Un exemple : pour indexer les livres Mame, nous n’avions pas prévu de détailler les informations liées aux ex præmio, les étiquettes collées dans les livres et indiquant à quelle occasion scolaire le livre a été offert et à quel enfant. Or ces ex præmio étaient présents dans la majorité des livres que nous trouvions (alors qu’ils sont évidemment absents des ouvrages de la BNF, qui par définition n’ont jamais connu d’usagers), et ils fournissaient des informations qualitatives d’une importance essentielle : à quel âge étaient destinées telles collections et séries, à quel sexe tel livre était prioritairement offert, combien de temps s’écoulait entre la date d’impression d’un livre (présente sur le colophon) et la date de distribution lors des prix de fin d’année (manuscrite sur l’étiquette d’ex præmio), un indice précieux pour comprendre la circulation concrète du livre sur le marché des ouvrages scolaires. FileMaker permet de créer des champs de saisie de natures diverses, de les nommer librement, de les insérer n’importe où dans un masque de saisie, à n’importe quel stade du travail. Découvrant l’intérêt de ces ex præmio, nous improvisons d’emblée, et pour notre plus grande satisfaction de chercheurs, une manière d’en enregistrer les informations. De même que pour le projet Mutual Heritage, c’est seulement une fois sur le terrain que les chercheurs chargés de la ville de Tunis ont imaginé qu’ils pouvaient analyser les dynamiques de transformation d’un quartier patrimonial en s’appuyant sur une donnée facile à obtenir : le prix du mètre carré locatif moyen du quartier considéré (fourni par les journaux d’annonces immobilières). Mais où ranger cette information, donnée essentielle à la recherche, dans un schéma Dublin Core ? Tout chercheur sait donc bien à quel point c’est le terrain qui construit empiriquement sa réflexion, et combien sa collecte évolue dans ses modalités à mesure qu’il confronte ses hypothèses au réel. Mais lors du passage au rigide Dublin Core, les choses se compliquent.

Une autre difficulté se présente aux deux équipes : le temps nécessaire à l’indexation des données dans Omeka. Le chercheur en effet est toujours pris entre deux exigences, coincé entre deux temps : le temps de la collecte des données, qui est en réalité constitutif de ces données – car, au mépris de l’étymologie, les choses sur lesquelles s’exerce la réflexion ne sont pas « données » mais fabriquées par le regard du scientifique ; et le temps de la réflexion, qui donne un sens à un amas de phénomènes, et engage l’action. La question du temps intervient ici. Le chercheur fait face à la difficulté d’engranger le plus possible d’informations, pendant une campagne à la durée forcément limitée (un séjour dans telle bibliothèque éloignée, une mission à l’étranger contingentée, ou encore un chantier de fouilles à l’existence restreinte par des délais légaux), en satisfaisant à l’exigence de précision, de méthode et d’exhaustivité induite par la perspective, à moyen terme, de l’exploitation puis de la mise en valeur des éléments collectés. Il est conscient que le temps passé à indexer et documenter des clichés photographiques empiète là sur la campagne de photos elle-même, ici sur la rédaction du compte-rendu de terrain, voire sur les nuits de récupération – sans compter que, sans être cynique, on évalue le chercheur sur sa production bibliographique… pas au nombre de données indexées ! La nature fastidieuse d’une indexation normée, indispensable à l’utilisation du corpus a posteriori, doit impérativement être atténuée par l’outil qui accompagne le chercheur dans sa collecte. Or Omeka ralentit le temps de saisie, obligeant à utiliser des nomenclatures peu ergonomiques et à travailler sur des interfaces peu intuitives.

Comme responsables d’équipe, nous savons d’expérience qu’il existe une loi simple régissant la collecte de données dans un cadre de recherche : n’étant pas payé en fonction du nombre de fiches réalisées, le chercheur ne se livre à une constitution fine de corpus que dans la mesure où il est convaincu que cet investissement temporel sera rentable au moment de la phase d’élaboration du savoir. Un exemple très concret : le logiciel FileMaker offre une énorme puissance de calcul et de croisement des champs de requête. Il est donc très facile à un chercheur, travaillant sur une masse de données recueillies collectivement, de décider soudainement, pour les besoins d’une publication, de chercher combien de titres différents Just-Jean-Étienne Roy a publiés aux éditions Mame entre 1855 et 1867 : la requête est simple, la réponse immédiate, l’information utilisable, on peut la croiser avec autant de requêtes similaires qu’en exige la logique de l’article en cours. Les efforts que le chercheur a produits auparavant (et que ses collègues ont produits) en saisissant manuellement toutes sortes de données (notamment des pseudonymes) se voient donc immédiatement récompensés. Omeka offre moins de souplesse dans le croisement des requêtes, il classe moins bien les réponses et produit plus d’erreurs ; le chercheur peut être déçu, au moment où il élabore du savoir, en constatant que le temps qu’il avait consacré à la production des données lui est si mal rendu.

À ce stade de nos deux programmes de recherche, nous constatons donc, l’un comme l’autre, qu’Omeka n’est pas le miracle de fluidité que nous avions (naïvement ?) imaginé. Efficace dans l’idéal, il suppose, pour être vraiment opérationnel, que l’équipe ait préalablement mis sur pied des procédures de travail finement calibrées. Or ces procédures, justement, il n’est pas toujours possible de les anticiper a priori, car le terrain apporte son lot de découvertes, qui orientent de manière rétroactive les démarches du chercheur, se dégageant d’une impasse ou à l’inverse investissant brusquement un territoire qui n’était pas cartographié au démarrage du projet. De digital naive, nous voilà devenus digital disappointed. Comment surmonter ce sentiment de relatif échec ?

Le bricolage comme solution

Avec du recul, la solution qui nous apparaît la plus pertinente à développer devant une communauté de chercheurs est donc celle du bricolage. On ne pense pas le bricolage ici négativement, comme un rejet de la technicité ou du professionnalisme, mais positivement, comme une capacité d’adaptation à un contexte qui n’est, techniquement, humainement et économiquement, jamais idéal, et par définition, jamais prévisible – c’est ce qui distingue la recherche de l’expertiseCes réflexions avaient déjà été évoquées dans un billet du carnet de recherches Mame & fils à l’occasion de l’excellente ANGD (Action Nationale à Gestion Déconcentrée) « Gestion numérique des sources de la recherche en SHS » (Aussois, octobre 2010). Lire le billet.↩︎. Partant du principe que la montre la moins chère, c’est la montre que l’on possède déjà ; que le mieux est l’ennemi du bien ; que les journées ne comptent que vingt-quatre heures même chez les chercheurs publiants, notre réflexion nous a amenés à tempérer notre enthousiasme devant l’objet Omeka, et à revenir à une réflexion épistémologique moins tributaire du mirage techniciste qui semble parfois envahir les discours sur les HN.

Nos équipes ont trouvé Omeka d’un maniement difficile, chronophage, pour un rendu qualitatif inférieur aux outils empiriques que nous étions pourtant tentés de rejeter parce qu’ils n’étaient pas optimaux. Or l’honnêteté nous conduit pourtant à reconnaître les atouts qu’il présente. Comment obtenir d’Omeka (et du Dublin Core qui le structure) qu’il nous offre à la fois la rigueur qui nous permettra d’utiliser et de partager les résultats de la recherche, et à la fois la souplesse dont nos équipes ont impérativement besoin durant le temps de l’enquête, qui est une exploration intellectuelle plus qu’une simple récolte ? Nous avions choisi FileMaker ou Excel dans le tâtonnement préliminaire des deux projets, parce qu’ils sont faciles à comprendre, et très souples. Plutôt que de nous contraindre à rentrer dans la logique un peu raide d’Omeka, une solution d’avenir pourrait-elle être de lui inventer un « assouplisseur » ? C’est là qu’intervient la notion de bricolage.

Imaginons un charpentier de marine qui, pour parfaire la courbure de la coque d’un bateau, se plaint que son herminette ait un fer trop droit. Si on lui répond « Tu dois faire avec cette herminette, car l’outil est ainsi conçu ; pour lui conserver sa rigueur, il doit avoir cet angle de courbure, et pas un autre, adapte-toi », il y a fort à parier qu’il renoncera à terminer sa coque… ou que le bateau prendra l’eau. Mais l’expérience réelle est tout autre : il suffit en fait que le charpentier aille voir le forgeron, explique à quoi doit exactement ressembler l’outil dont il a besoin pour son art, afin que le forgeron produise précisément la forme de tranchant adaptée à l’usage ici et maintenant. Ou, si aucun forgeron ne se trouve à proximité, que le charpentier aménage lui-même son outil, certes sans la rigueur qui serait celle du forgeron, mais dans le but que le produit, et non l’outil, soit conforme à la rigueur la plus absolue : que la courbure soit bonne, et que le bateau flotte. Le charpentier et son forgeron sont-ils plus près du bricolage que de l’informatique ? Sans doute. C’est cet esprit de bricolage adaptatif que nous revendiquons. Que le charpentier ne soit pas un forgeron ; que le forgeron adapte l’outil à l’art du charpentier selon les exigences de ce dernier ; que personne ne vienne dire à l’artisan qu’il doit se plier à la rigidité de son outil, mais qu’au bout du compte le travail soit fait, et bien fait ; et qu’au besoin, le forgeron s’inspire des « aménagements bricolés » qu’en son absence le charpentier aura apportés à son outil, pour améliorer lui-même la forme des prochaines herminettes qui sortiront de sa forge. Pour la plus grande satisfaction des charpentiers de marine, certes, mais surtout des navigateurs, pour qui les bateaux, in fine, sont faits.

Nous ne voulons pas bricoler Omeka – nous le voudrions, que nous ne le pourrions pas, car nous ne sommes pas compétents pour entrer dans le code, de même que le charpentier n’est pas forgeron. Mais nous voulons bricoler quelque chose qui nous offre les avantages d’Omeka sans nous imposer ses inconvénients – pour gagner du temps de recherche, pas pour en gaspiller. Il nous apparaît progressivement que la solution n’est pas technique, mais procédurale. Omeka est un excellent outil de gestion de données et de valorisation des résultats de la recherche. Mais il nécessite l’intervention d’un ingénieur, d’une part pour l’installer et le maintenir – les montées de version peuvent se révéler fastidieuses, comme nous en avons fait l’expérience –, d’autre part pour réfléchir avec l’équipe au meilleur protocole de distribution des tâches, celui qui garantit l’exploitation la plus rationnelle possible des capacités de chacun, sans les alourdir, et si possible en les allégeant. Plusieurs années après la fin de ces deux projets, nous sommes convaincus que la fonction de l’ingénieur, au sein de l’équipe de soutien, n’est pas d’imposer son outil, serait-il excellent (Omeka, d’un certain point de vue, l’est), mais d’aménager, avec les chercheurs, les passerelles qui permettront d’intégrer dans Omeka (qui offrira sa rigueur) les données qui auront été collectées sur le terrain avec les outils les plus souples et les plus élémentaires, ceux que les chercheurs connaissent bien, ont bien en main, ceux qui leur font gagner du temps et ne nécessitent ni connexion à internet ni disque dur surpuissant.

Encore faut-il que les procédures soient élaborées ensemble : pour que l’ingénieur puisse sans difficulté aucune rapatrier les données des chercheurs, ceux-ci doivent accepter de s’imposer un certain nombre de normes, dont le nombre et la précision doivent être négociés ; afin que les chercheurs aient la garantie que la nature et la qualité de leurs données soient reflétées de manière exacte dans l’objet final, l’ingénieur doit s’astreindre à bien comprendre l’intérêt suscité chez le chercheur par chacune d’entre elles ; enfin, ingénieurs et chercheurs doivent se mettre d’accord sur les procédures, non pas accidentelles mais consubstantielles au travail de terrain, de modification et d’amélioration du protocole de saisie, quand soudain apparaît « quelque chose qu’on n’avait pas prévu » mais dont l’analyse est au cœur de la démarche de recherche. Le chercheur doit alors accepter de ne pas modifier anarchiquement et unilatéralement un champ de saisie ou la nature d’une donnée ; l’ingénieur ne doit pas être autorisé à répondre « Ce n’est pas possible ». C’est en cela que réside le bricolage : dans ce mouvement d’allers et retours entre chercheurs pris dans les réalités du terrain, et ingénieurs chargés du soutien technique – mais en gardant à l’esprit que ce qui prime est évidemment la démarche de recherche, et non la logique d’ingénierie. Bricoler une « moulinette » qui permettrait aux chercheurs d’utiliser les outils qu’ils connaissent et apprécient pour automatiser le versement des données vers Omeka, voilà ce qui, à notre sens, constituerait une véritable avancée en matière d’instrumentation numérique.

Pour en revenir à un cas concret : dans le cadre du projet Mame, nous avons basculé de FileMaker à Omeka. Il a fallu extirper les données de FileMaker, en les convertissant sous la forme d’un fichier CSV ; puis concaténer certains champs, pour produire un équivalent Dublin Core ; enfin réintroduire ces données CSV dans Omeka, via un plugin. À partir de cette date, on invitait les chercheurs à saisir directement dans Omeka les nouvelles observations menées sur le terrain. Avec du recul, nous pensons qu’il aurait fallu considérer cette étape intermédiaire (la moulinette FileMaker-CSV-Omeka) non pas comme une procédure ponctuelle, mais comme la procédure ordinaire : que les chercheurs n’aient jamais à saisir sous Omeka, mais que la bascule se fasse à intervalles réguliers via la moulinette ; et en économisant la déperdition liée à la concaténation des données, parce qu’une réflexion collective aurait permis de normer et réadapter en permanence les champs de saisie sous FileMaker pour les rendre d’emblée compatibles avec le Dublin Core.

Si le bricolage nous semble essentiel, c’est aussi, ne l’oublions pas, parce qu’en LSHS, il n’est pas rare qu’une équipe (équipe d’accueil, petit laboratoire sans moyens) ne dispose pas d’un ingénieur à demeure. Il est illusoire de considérer qu’un chercheur répondant à un appel à projets puisse se faire aider d’emblée, au moment de la rédaction de son programme, par un ingénieur maison, puisque la précarisation de l’emploi à l’université a raréfié les postes d’ingénieurs statutaires, en invitant à ne recruter que ponctuellement ces accompagnateurs de la recherche – donc après la réponse à l’appel à projets. Généraliser le bricolage, c’est une manière pragmatique de répondre au besoin d’instrumentation de la recherche, tout en s’adaptant à son contexte concret d’exercice. Toutes les équipes n’ont pas d’ingénieur ; mais tous les chercheurs utilisent un tableur. Aidons les chercheurs à bricoler leurs moulinettes, à mieux utiliser les outils qu’ils connaissent déjà, ceux qu’ils possèdent déjà, mais en formalisant quelques règles simples qui leur éviteront les considérables déperditions d’énergie dont nos projets ont souffert lors des bascules vers des outils à l’ingénierie complexe.

Le bricolage n’est pas l’absence de rigueur

C’est donc en ayant à l’esprit les réalités concrètes de la vie du chercheur que nous avons cherché à aller plus loin dans notre réflexion sur l’instrumentation numérique de la recherche en LSHS. Il nous semblait en effet que, en amont d’Omeka, en amont même des « moulinettes » qui nous avaient sauvé la mise, nous avions la possibilité d’améliorer des démarches mises en place empiriquement par les chercheurs dans leur usage de l’outillage numérique devenu ordinaire. Nous avions en effet le sentiment qu’une partie des difficultés que nous avions rencontrées aurait pu être évitées dès l’étape de la création des images qu’Omeka allait nous aider à mettre en ordre et en valeur. Une enquête que nous avons décidé de mener au sein d’une large communauté de chercheurs a confirmé cette intuition, autour de l’usage de la photo numérique dans les recherches en LSHSEnquête réalisée à l’automne 2013 auprès de 200 chercheurs en lettres et sciences humaines. La synthèse des réponses à cette enquête a été publiée le 13 novembre 2013 sur le carnet de recherches IconoRéseau. En savoir plus.↩︎. Elle a en effet révélé qu’aujourd’hui, très nombreux sont les chercheurs à utiliser la photographie numérique comme un outil de la recherche (comme nous l’avions fait) ; que très peu d’entre eux ont reçu une formation spécifique ; et que fort peu de chercheurs savent réellement optimiser leurs prises de vues, trier et archiver convenablement leurs photos, c’est-à-dire de manière rationnelle et surtout rentable pour l’utilisation future. Notre intention n’était nullement de réfléchir à l’épistémologie de cette pratique photographique – les chercheurs font ça très bien eux-mêmes – mais de penser cette pratique sur le plan de l’outillage, afin d’aider les chercheurs à l’améliorer, ce qui, espérions-nous, simplifierait les utilisations ultérieures de ces données iconographiques, notamment dans des procédures impliquant de l’ingénierie un peu rigide.

Faire de meilleures photos pour en faire moins ; connaître le fonctionnement de son appareil, et l’existence des logiciels de traitement les plus simples ; s’initier à quelques réflexes et bonnes pratiques de nommage, d’indexation et d’archivage ; apprendre à automatiser des tâches qui se feront en quelques secondes sans saisie manuelle, voilà quelques-uns des services que nous avons souhaité rendre à la communauté des chercheurs, en nous appuyant sur notre propre expérience, mais aussi sur les témoignages issus de l’enquête. C’est l’objet d’un petit manuel que nous avons rédigé, et que nous publions par morceaux sur notre blogVoir le carnet de recherche IconoRéseau. Images, bricolage et humanités numériques.↩︎, non pas La photo pour les [chercheurs] nuls, pour paraphraser une collection populaire, mais précisément La photo pour les chercheurs compétents qui ont besoin de faire de bonnes photos, sachant qu’une « bonne » photo est une photo qui est exploitable dans le contexte disciplinaire de la recherche. Nous imaginons que ce partage de pratiques élémentaires aidera les chercheurs dans le quotidien de leurs différents terrains, et favorisera les usages ultérieurs de solutions numériques comme Omeka, parce que nous les aurons aidés à croiser rigueur de la nomenclature et efficacité dans le traitement de l’information, sans jamais les contraindre, mais à l’inverse en les aidant à gagner du temps.

Si la première étape de la rationalisation du travail se situe dans l’acte même de prendre une photo et de la transférer sur son ordinateur, la seconde intervient au moment de documenter cette photo : qu’est-ce qui a été photographié ? Où, quand ? À quel ensemble plus large se rattache cet objet, ce phénomène ? Quelles informations de nature qualitative le chercheur souhaite-t-il ajouter à cette donnée brute qu’est la photographie, et qui ne figurent pas sur l’image (le nom de l’architecte qui a construit le bâtiment, par exemple) ? Et surtout, où et comment stocker ces métadonnées : dans le nom même de chaque photo, dans un fichier de métadonnées (mais lequel ?), dans un tableur, dans une base de données ? Quelle solution fournira le meilleur rapport simplicité/réutilisabilité, pour le chercheur d’abord, pour une éventuelle équipe d’ingénierie ensuite ? Ce que nous souhaitons apporter, c’est notre expérience dans ce domaine, en explicitant les choix que nous avons faits, et mettant en garde contre les erreurs que nous avons commises. Mais nous savons que là s’arrête le bricolage – et donc notre fonction – et qu’au-delà commence la compétence d’un professionnel qui n’appartient que rarement à nos équipes, le documentaliste. Il est sans doute indispensable de l’intégrer à un programme de recherche qui nécessite de traiter des données sérielles ; peut-être même de proposer ses compétences à tout chercheur en LSHS, au sein de son laboratoire ou d’une MSH : mais ces questions relèvent de la politique de la recherche, et non de l’épistémologie.

C’est à cette étape en effet qu’idéalement un chercheur devrait pouvoir s’appuyer sur les compétences de ce professionnel dont le métier est justement le tri et l’archivage rationnel des informations. Spécialiste de la gestion de l’information documentaire, c’est lui qui saura par exemple conseiller le chercheur dans la manière de comprendre le fonctionnement du Dublin Core, et surtout, de traduire en langage ordinaire « l’esprit » des champs. Dans quelle rubrique faut-il entrer le nom de l’illustrateur d’un livre : comme « creator » ou comme « contributor » ? À quelle notion renvoie le champ « is part of » lorsqu’on est en train de réaliser la fiche d’identité d’un bâtiment patrimonial ? Au-delà même de ces opérations simples de répertoire, le documentaliste, familier des démarches de recherche, saura aussi conseiller le chercheur quant à l’organisation même du corpus : faut-il créer une seule collection Omeka pour l’ensemble des données, ou scinder le corpus en plusieurs collections, et dans ce cas, selon quelle logique ? Ces choix auront des répercussions importantes sur l’affichage et la recherche, à moyen terme. C’est encore au documentaliste qu’on devrait pouvoir demander, à terme, d’utiliser les ontologies pour proposer aux chercheurs des démarches d’organisation de l’information qui rendent compte de la richesse des objets étudiés, au lieu de les forcer à se plier à des formats standards qui tendent peu ou prou à en réduire la complexité, parfois jusqu’à la caricature, comme nous l’avons subi avec le Dublin Core. Mais là, encore, ce n’est plus tout à fait la compétence du chercheur…

Les chercheurs en activité aujourd’hui n’ont pour la plupart pas reçu de formation aux HN. Pour eux, les démarches intellectuelles directement liées à l’épistémologie de leurs champs disciplinaires priment sur toute autre considération. Nous appartenons à cette frange des chercheurs en SHS qui considèrent que les naissantes HN ne constituent pas forcément un nouveau paradigme de la recherche, mais pour l’instant surtout un faisceau d’outils – qui, comme tous les outils, notamment technologiques, auront leur temps, mais dont il serait absurde de ne pas se saisir s’ils peuvent aider le chercheur pour sa recherche, et pour la mise en valeur de ses résultats. Omeka aujourd’hui, un autre demain, s’avère être un bon outil. Mais nous sommes convaincus que c’est la main de l’artisan qui doit guider l’outil, et non l’inverse. Nous ne souhaitons ni nous laisser imposer par un outil logiciel un modèle d’organisation de la pensée qui nous détournerait de notre mission, nous empêchant de penser nos objets ; ni nous livrer à de fastidieux apprentissages du maniement d’outils subtils, mais très compliqués. Nous voulons des outils de structuration et de partage des données de nos recherches qui soient aussi faciles à conduire que nos voitures personnelles, qui se plient à notre style de conduite comme aux terrains sur lesquels nous avons décidé de les mener, et qui nécessitent peut-être un permis, mais pas de leçons de mécanique. Que les outils des HN permettent aux chercheurs digital naive de rester des bricoleurs numériques, du moment qu’ils sont d’excellents anthropologues, géographes, historiens. Que les progrès des usages communautaires de ces nouveaux outils mènent à la création de ces « moulinettes » qui rendront les opérations indolores, de sorte que l’outil numérique leur permette de décupler leur force de travail, sans jamais alourdir leur charge.

Il ne s’agit pas d’opposer la rigueur du numérique à l’amateurisme foutraque du terrain, mais bel et bien de faire dialoguer deux rigueurs : celle de l’outillage informatique, qui de fait impose sa structuration, gage d’efficacité mais poids au quotidien ; et celle de l’épistémologie propre à chaque démarche de chercheur, et adaptée à chaque terrain, chaque problème. Ce n’est qu’au prix de cette médiation, de ce dialogue, que pourront naître, aux confins des humanités et de l’outillage numérique, de véritables HN. Il nous semble, quant à nous, que les « bricoleurs » sont l’avant-garde tâtonnante de ces nouvelles conquêtes de la recherche.

Contenus additionnels

Cécile Boulaire

Cécile Boulaire est maître de conférences habilitée à diriger des recherches en littérature française à l’Université François-Rabelais de Tours, et membre du laboratoire INTRU (EA 6301). Ses recherches portent sur la littérature pour la jeunesse, et plus particulièrement sur l’esthétique de l’album, et l’histoire de l’édition ; dans ce dernier cadre, elle a dirigé le projet ANR Mame de 2008 à 2011. Elle a été pendant six ans responsable du master Patrimoine écrit et édition numérique du Centre d’études supérieures de la Renaissance (CESR).

Romeo Carabelli

Romeo Carabelli est ingénieur de recherche et formation habilité à diriger des recherches en géographie à l’Université François-Rabelais de Tours, et membre du laboratoire CITERES (UMR 7324 CNRS et Université François-Rabelais). Il axe son travail sur les processus de (re)territorialisation patrimoniale de l’héritage colonial e et, plus spécifiquement, sur les agencements contemporains des productions dispersées et multinationales. Orienté vers les travaux collectifs, il anime et gère des programmes de recherche s, coopération et expertise sur l’architecture et l’aménagement patrimoniaux dans le bassin méditerranéen et dans les “suds” en général.