Les modélisations mettent en jeux différents types d’informations. Les outils informatiques en revanche manipulent souvent l’information de façon spécialisée. La quantité de logiciels utilisés dans la modélisa-tion de biens patrimoniaux ne se retrouve pas pleinement dans la figure 4.5, qui en présente une sélection, répartie selon leur rapport aux pra-tiques de modélisation. Je m’inspire pour la création de ce graphique des travaux de Chris Alen Sula [Sul13]. Il propose pour sa part un mo-dèle conceptuel de compréhension des activités d’étude du patrimoine et répartit les activités selon deux axes, un premier axe porté par la question « Qui réalise l’activité, l’humain ou la machine? » et un second axe qui s’intéresse au contenu de la modélisation, à savoir si l’on modé-lise du contenu de premier ordre (les données) ou de second-ordre (des méta-données).
Pour comprendre les spécificités des outils, j’ai choisi de répartir les outils sur les deux axes suivants :
— Modélisationlibre (méta-modèle « maison », propre à la modé-lisation) $ Modélisation standard (méta-modèle « normalisé », construit à plusieurs),
— Modélisationlégère (régie par des relations strictement lexicales) $ Modélisation lourde (structurée par une sémantique explicite et des règles logiques).
Les outils représentés par la figure 4.5 sont les suivants :
Magrit : logiciel de cartographie thématique [VGL18] (http://magrit.cnrs.fr/ Gephi : logiciel de visualisation et d’analyse de données orientées graphe
[BHJ09] (https://gephi.org/)
Cytoscape : logiciel de visualisation adjoint de modules permettant l’ana-lyse de données orientées graphes [SOR+10] (https://cytoscape.org/) Recogito : plateforme en ligne de création d’index cartographique
(ga-zeeter en anglais) [SBIdSC15] (https://recogito.pelagios.org/)
Arches : plateforme de gestion de données pilotée par le Getty Institute [MDA16] (https://www.archesproject.org)
Revit : logiciel édité par Autodesk pour la conception et la reconception 3D [Win11] (https://www.autodesk.fr/products/revit/overview)
Recap : logiciel édité par Autodesk pour le traitement de numérisation d’objets 3D [Cox15] (https://www.autodesk.fr/products/revit/overview) Omeka : SGC (Système de Gestion de Contenu),2 édité par le Roy
Ro-senzweig Center for History and New Media décliné en une ver-sion classique et une verver-sion "S" se rapprochant des technolo-gies du web sémantique [KRS10], [MSB19] (https://omeka.org/classic/, https://omeka.org/s/)
3DExperience : plateforme en ligne regroupant plusieurs outils (de mo-délisation, simulation, gestion de données) développés par Das-sault Systèmes, très orienté développement (conception et gestion de la vie) de produits manufacturés [Sys19] (https://www.3ds.com/fr/ a-propos-de-3ds/la-plate-forme-3dexperience/)
Siemens NX et sa suite logicielle PLM : une série de logiciels aux fonc-tionnalités très proche de la précédente [Sie17] https://www.plm.automation. siemens.com/global/fr/
Zooniverse : portail en ligne permettant de réaliser des classifications collaboratives[SPDR14] (https://www.zooniverse.org/)
Oxygen XML-TEI Editor : éditeur de texte à l’interface adaptée pour l’édi-tion TEI [Wie] (https://www.oxygenxml.com/)
ArkeoGIS : application de cartographie pluridisciplinaire développée par Loup Bernard à l’Université de Strasbourg [Ber16], (http://arkeogis. org/)
Haruspex : application de modélisation thématique de corpus, dévelop-pée par Matthieu Quantin à l’Université de Nantes [QHLK17]
IRaMuTeQ : application de textométrie développé par Pierre Ratinaud [LR14] (http://www.iramuteq.org/)
TXM : application de textométrie développée à l’Université de Lyon [HMP10] (http://textometrie.ens-lyon.fr/)
TAPAS : application d’archivage et facilitant l’accès aux textes encodés d’après le formalisme TEI [FH13] (http://tapasproject.org/)
Protégé : éditeur d’ontologies et outil-support pour créer des « systèmes intelligents » [TNTM08] (https://protege.stanford.edu/)
2. Autrement dit un CMS (Content Management System, l’acronyme français nous semblant rarement utilisé dans la pratique
4.4 « La moitié du travail scientifique »
Enfin, avant de me pencher en détail sur la documentation, base du travail et résultat produit, je voudrais encore relayer le billet de Bernard Hours, directeur du Laboratoire de recherche historique Rhône-Alpes (LARHRA UMR 5190) à l’époque où il écrivait ce billet, en 2019. Intitulé « La méthodologie relève-t-elle de la recherche disciplinaire? », il me semble mériter une place sans coupe.
À l’heure où tend à se généraliser, dans les appels à projet, l’exigence d’un plan de gestion de données et du respect des principes FAIR (Findable, Accessible, Interoperable, Reusable), il semble que la communauté historienne soit encore assez loin d’en avoir mesuré tous les enjeux. Le sujet est vaste, tant il relève à la fois de la réflexion disciplinaire et de choix po-litiques, donc d’une vraie vision du développement de la re-cherche en histoire sur les moyen et long termes. A partir de l’expérience développée depuis une dizaine d’années au sein du Pôle Histoire Numérique du Larhra, je me limiterai ici, avec un peu d’humeur, à une réflexion sur un point : quelle est la place de l’historien dans la mise en place des outils et des méthodologies numériques de la recherche en histoire? Quels que soient les débats qu’ils ont pu susciter, nul n’a es-timé que, vénérables professeurs de l’université républicaine, Langlois et Seignobos s’écartaient de leur champ de com-pétence lorsque, dans ”Introduction aux études historiques (1898), ils expliquaient les avantages et les limites du dépouille-ment des sources à l’aide de fiches. Ils citaient d’ailleurs Re-nan : « ces arrangements personnels de bibliothèque qui sont la moitié du travail scientifique », pour renchérir : « Tel éru-dit doit une bonne part de sa légitime réputation à l’art qu’il a de colliger; tel autre est, pour ainsi dire, paralysé par sa maladresse à cet égard » . Il leur paraissait donc naturel que l’historien réfléchisse à « sa manière de colliger » .
Ces remarques ne sont pas frappées d’obsolescence à l’âge du numérique. Qu’il s’agisse de fichiers papier ou de caractères numériques, la question pour l’historien est la même, et là réside la vraie question méthodologique : selon quelle archi-tecture organiser la masse des données que l’on stocke? Ce n’est pas sur la pertinence de cette question que l’on constate des divergences, mais sur la réponse, ou plutôt sur le rôle
de l’historien dans sa formulation. Il est assez commun d’en-tendre affirmer de façon péremptoire, y compris au plus haut niveau des instances qui « encadrent » la recherche histo-rique, que l’historien n’a pas à se préoccuper de cette archi-tecture mais qu’il s’agit d’informatique, que ce n’est pas une question de recherche mais de technique. L’affirmation est d’ailleurs d’autant plus péremptoire que l’on déclare – ou que l’on tente de masquer – en même temps son incompétence technique. Construire l’architecture des données et de l’infor-mation, c’est-à-dire les structurer, cela suppose de modéliser, et pour que cette modélisation soit robuste, de se référer à une ontologie adaptée. Ce travail qui doit être documenté, peut seul garantir l’adéquation aux principes FAIR. Or qui d’autre que l’historien peut définir un modèle de données pour l’his-toire? Qui d’autre que l’historien, une fois déterminés le mo-dèle et l’ontologie de référence, peut concevoir l’architecture de la base données, avec l’ingénieur qui la réalisera?
Soyons sérieux, affirmer que l’élaboration des outils adéquats pour la recherche historique est une pure affaire d’ingénieur et qu’elle ne relève pas de la recherche, c’est refuser de faire, selon les termes de Renan, « la moitié du travail scientifique » . On peut s’aveugler, on sait ce qui arrive à l’autruche... Bernard Hours, Lettre du LAHRA n 15, 2019 (accessible au 15sept 2019 à l’adresse https://lpm.hypotheses.org/1160
Je ne peux que me rallier à l’exhortation de Bernard Hours. L’inter-disciplinarité annoncée de mes travaux me semble pouvoir tenir dans le développement de compétences partagées, mais surtout de la com-préhension fine des enjeux des différents métiers rapprochés. Heureuse-ment, il me semble que seule une pratique collective et partagée, non pas déléguée et segmentée, engendre ce développement de la compré-hension et de compétences mutuelles. Ce billet adressé aux historiens me semble tout autant un appel à ce que les techniciens deviennent historiens.