Les réalisations numériques du projet FFL: présentation et bilan

Le projet ANR Foucault fiches de lecture (FFL) arrivant à son terme fin mars 2021, nous proposons ici un bilan de ses réalisations numériques. Le projet FFL s’inscrivait dans le champ des humanités numériques, puisqu’il s’agissait de rendre possible l’exploration des fiches de lecture pour la communauté scientifique via la numérisation des manuscrits et le développement d’un outil numérique innovant.

L’objectif de cet outil était d’abord de faciliter le travail collaboratif, c’est-à-dire de proposer un système permettant de produire collectivement la description archivistique de ce corpus considérable (ce qui inclut le relevé systématique des références bibliographiques et des mentions de personnes données par Foucault) en mutualisant les informations produites par les chercheurs dans le cadre de leur travail. Notre postulat fondamental consistait à présupposer, derrière la disparité des pratiques de recherche et des problématiques spécifiques à chacun·e, un dénominateur commun, à savoir le besoin de s’orienter dans le corpus, et donc d’en faire l’inventaire. Ce qui nous incitait à parier sur les principes de « l’économie de la contribution » (Stiegler) pour agréger dans un même espace documentaire les éléments de description produits par chaque chercheur·e. Nous expliciterons par la suite les défis techniques et les arbitrages que cela impliquait.

Tout en proposant un espace de travail collaboratif, notre outil se devait également d’offrir les fonctionnalités de consultation attendues d’une exposition virtuelle, et donner la possibilité d’ouvrir progressivement au public l’accès aux manuscrits de fiches. Mettre à disposition l’ensemble des fiches numérisées, de manière ouverte et pérenne, était en effet une finalité intrinsèquement liée à la facilitation du travail de recherche. Le fonds Foucault conservé à la BnF, qui a acquis le statut de trésor national, nous paraissait devoir être autant que possible rendu accessible au public : les fiches de lecture constituent un ensemble documentaire exceptionnel (près de 20 000 fiches) qui présente un intérêt non seulement pour la connaissance du travail de l’auteur, en ce qu’il met en perspective ses œuvres dites et écrites, mais aussi, plus largement, pour l’histoire de la philosophie et des sciences au XXe. Ce n’est pas ici le lieu de développer ces points mais retenons que notre projet d’humanités numériques comportait de manière essentielle un aspect de valorisation du fonds d’archives, ainsi qu’une réflexion sur ce que la mise en archives et le numérique font à l’œuvre.

Il n’existe cependant à l’heure actuelle aucun outil qui satisfasse pleinement chacun de ces critères. Nous avons donc mené nos travaux dans plusieurs directions, à la fois en développant une plate-forme expérimentale et en réutilisant des dispositifs existants. Nous présenterons d’abord (1) la plate-forme expérimentale FFL, ou « prototype FFL », ainsi que les données produites par l’équipe sur cette plate-forme. Cet outil collaboratif s’articule avec deux autres dispositifs, (2) le logiciel Transkribus et (3) la plate-forme d’exposition FFL-Eman.

1. La plate-forme expérimentale FFL

Cet espace de travail collaboratif, développé par Vincent Ventresque pour les besoins du projet, nous a servi de point de départ pour constituer progressivement le corpus, le décrire et l’annoter, en même temps qu’il a permis de tester un certain nombre d’hypothèses dans le champ des humanités numériques. De plus, à partir de cette base de réflexion, nous avons pu proposer quelques développements qui ont été intégrés sous forme de plugins à la plateforme Eman de Richard Walter.

Pour organiser le travail collectif (et itératif) de description du corpus numérisé, notre positionnement méthodologique consistait à proposer un traitement différencié du corpus : 1) faire en sorte que l’ensemble des fiches numérisées soit suffisamment inventorié et indexé pour qu’un plan de classement et un moteur de recherche puissent faciliter la consultation ; 2) pour certaines chemises présentant un intérêt pour les travaux de recherche des membres du projet, proposer une description plus fine, ainsi qu’un système d’annotation. La plate-forme devait ainsi articuler plusieurs dimensions : à la fois une exposition virtuelle et un outil de travail, où les membres du projet pouvaient simultanément mutualiser les données de description et baliser les documents pour les besoins de leur propre analyse, constituant ainsi des sous-corpus spécifiques à une problématique de recherche. Deux grands types d’usage se sont donc rencontrés sur la plate-forme : le premier était celui des éditeurs, comme E. Basso et Ph. Sabot [note 1], qui avaient besoin de connaître les sources de Foucault pour réaliser l’édition critique des ouvrages sur Binswanger et sur la phénoménologie, en précisant l’origine de certains concepts, en clarifiant certains passages où manquait la référence exacte. Cela nécessitait de sonder et décrire plusieurs boîtes (n° 37, 38, 42 B), pour y retrouver les sources implicites et mesurer leur importance relative. Le second usage, plus thématique, impliquait une analyse détaillée de certaines chemises, comme celles de la boîte n° 19 pour mettre en perspective les recherches de Foucault sur le néolibéralisme ; ou encore, exhumer les pistes abandonnées autour du concept de biopolitique [note 2].

Trois hypothèses essentielles concernant le numérique proprement dit ont été testées, que nous allons présenter avant de recenser les données produites sur ce prototype (1.4). La première hypothèse (1.1), déjà évoquée plus haut, concernait l’articulation de deux types d’information et d’usages : les annotations personnelles et les données de description. La seconde (1.2) pariait sur les potentialités des technologies du web de données, en termes de réutilisation (alignements avec les données de data.bnf.fr) mais aussi de structuration et d’évolutivité. Nous avions par ailleurs établi un parallèle entre la conception foucaldienne de l’intertextualité d’une part, et d’autre part le mouvement de décloisonnement qui anime l’histoire récente des systèmes d’information dédiés aux données de bibliothèques et d’archives [note 3]. Enfin, une dernière hypothèse (1.3) concernait l’architecture fonctionnelle et l’ergonomie de l’outil, et plus particulièrement la possibilité d’une hybridation entre le système de l’exposition virtuelle (comme Omeka, Pleade, et autres CMS dédiés à la mise en ligne de collections numériques) et celui du Wiki (dont l’exemple le plus connu est Wikipedia).

1.1) Un modèle de données pour agréger et mutualiser Les contributions

Le principe essentiel de notre modèle de données original, implémenté en RDF (cf. § 1.2) et représenté ci-dessous de manière simplifiée, consistait à remplacer le schéma classique de la notice par un système « d’annotations » indépendantes, chacune ayant un identifiant unique et pouvant être décrite par un ensemble de métadonnées. En effet, les catalogues de bibliothèque et les inventaires d’archives reposent sur l’association entre une grille de description, composée de champs, et une ressource (exemplaire de livre, boîte d’archives). Or ce modèle classique est depuis quelques années remis en question, avec des recommandations comme FRBR par exemple, qui visent à autonomiser les informations contenues dans les champs de la notice pour faciliter leur réutilisation. Nous inspirant de ce mouvement de décloisonnement, nous avons choisi de rendre indépendante chaque information enregistrée par un·e utilisateur·rice.

Soient par exemple deux personnes A et B qui travaillent simultanément sur le corpus. Un système classique à base de notices, comme celui d’Omeka, permet de remplir les champs d’une grille et éventuellement d’éviter que les modifications de A soient écrasées par le travail de B. Toutefois, rien n’est prévu pour distinguer les informations enregistrées par A et B : elles sont par défaut rassemblées, fusionnées dans la notice préexistante, et il est impossible a posteriori de savoir que A a ajouté un titre « a1_tit » et B un commentaire personnel « b1_com », ou une note éditoriale « b2_not ». De même, rien n’est prévu pour que l’on puisse choisir que ce commentaire « b1_com » soit privé et non l’autre commentaire « c1_com » ajouté par C : il est seulement possible de décider que tous les commentaires seront privés et visibles uniquement par les utilisat·eur·rice·s dûment loggés, ou que tous les commentaires seront publics, visibles par tout·e internaute. À l’inverse, le principe de base des wikis consiste à tracer rigoureusement toute modification effectuée par A et B, et permettre de restaurer une version antérieure, etc.

Pour distinguer les contributions de A et B, le modèle du prototype FFL permet d’exprimer les énoncés suivants :

<Boîte_39_fiche_220> <annotée_par> <Annot_1>, <Annot_2>, <Annot_3> . 

<Annot_1> <est_de type> <Titre> . 
<Annot_1> <a_pour_valeur> " F.-V. Raspail, la fécondation chez les plantes " . 
<Annot_1> <a_pour_auteur> <Utilisateur_A> . 
<Annot_1> <créée_le> "12/01/2020 à..." . 
<Annot_1> <visible_par> "TOUT PUBLIC".

<Annot_3> <est_de type> <Commentaire_personnel> . 
<Annot_3> <a_pour_valeur> " Comparer cette fiche sur Raspail avec la fiche sur Geoffroy... " . 
<Annot_3> <a_pour_auteur> <Utilisateur_A> . 
<Annot_3> <créée_le> "12/01/2020 à ..." . 
<Annot_3> <visible_par> <Utilisateur_A>.

<Annot_2> <est_de type> <Mention_de_Personne> . 
<Annot_2> <a_pour_valeur> <François-Vincent_Raspail> . 
<Annot_2> <a_pour_auteur> <Utilisateur_B> . 
<Annot_2> <créée_le> "12/01/2020 à ..." . 
<Annot_2> <visible_par> "TOUT PUBLIC".

Dans cet exemple simplifié, nos trois annotations portent toutes sur la fiche n° 220 de la boîte n°39, et elles ont été créées par deux utilisateurs A et B ; les informations de description (Annot_1, titre ; Annot_2, mention de personne) sont mutualisées et peuvent être affichées pour tout public sur la page du feuillet ; le commentaire personnel (Annot_3) n’est visible que par son auteur (A) mais celui-ci peut décider de le rendre public. De plus, chacune des annotations a une provenance (auteur, date), ce qui permet de restituer aux utilisateurs A et B l’ensemble de leurs interventions sous la forme d’un historique. Ce modèle permet donc de composer autant de vues du corpus que souhaité, et propose par défaut un espace personnel où sont retracées toutes les contributions correspondant à un compte utilisateur.

Il est important de remarquer que ces énoncés ou « triplets » 1) utilisent des identifiants uniques, et que ces identifiants peuvent être formulés sous formes d’URI (par ex. http://ffl.org/Annot_1) ; 2) que ces énoncés sont lisibles indépendamment les uns des autres, et que l’association entre les contenus des énoncés se fait uniquement par le moyen des identifiants ; 3) que les triplets forment un « graphe » comme celui représenté ci-dessus. De ces trois points découlent trois conséquences très intéressantes :

— on peut stocker ces énoncés dans des espaces distincts, qu’il s’agisse d’un stockage physique (réseaux distribués sur différents serveurs ayant chacun un entrepôt spécifique) ou logique. Nous avons fait un usage systématique du partitionnement logique permis par le système des named graphs : les données du projet ont d’abord été réparties dans des graphes public, restreint, et privés (chaque utilisateur·ice ayant un graphe privé), puis de nouveaux graphes ont été ajoutés au fur et à mesure selon les besoins, par exemple pour stocker des données extraites de data.bnf.fr ou des données de visualisation. Ce partitionnement permet de séparer des ensembles d’information qui ne doivent pas être interrogés conjointement, et de gagner en performance (une requête qui cible un named graph donné est beaucoup plus rapide que si toutes les informations sont dans un seul graphe).

— il est possible de modifier très simplement la structure du modèle de données. Le sens des énoncés et la relation entre leurs composantes ne dépendent pas d’un système de coordonnées extérieur, comme c’est le cas d’une base de données tabulaire — où chaque enregistrement se situe dans une table et doit être repéré par un numéro de ligne et un numéro de colonne, et où les tables sont interdépendantes. De ce fait, il est beaucoup plus simple d’ajouter de nouveaux types d’information ou de redéfinir le sens d’un type existant, puisqu’il suffit d’ajouter de nouveaux énoncés, et qu’il n’est pas nécessaire de modifier des tables interdépendantes comme dans une base de données relationnelle. Nous avons pu faire évoluer notre modèle très facilement au fil du projet, en fonction de nouveaux besoins.

— les données sont stockées sous forme de graphe, et de ce fait il est possible d’explorer et visualiser à tout moment l’ensemble des informations enregistrées. De même, il est possible de parcourir le graphe de proche en proche, sans qu’une connaissance a priori de la structure logique soit nécessaire (impossible dans le cas d’une base de données tabulaire). Comme le prototype intégrait un dispositif de cartographies dynamiques et interactives (cf. infra), cela nous a permis de voir évoluer en temps réel l’état de la description du corpus, de repérer des similitudes ou des manques, etc, et donc de pouvoir examiner la qualité des données.

1.2) Les Potentialités du Web de données

Le prototype a été entièrement réalisé grâce à des outils libres et repose en particulier sur le triple store Fuseki de la fondation Apache. Quelques échantillons de code ont été mis à disposition sur SourceForge, sous forme de bac à sable. De plus, pour un développement rapide, le framework PHP Code Igniter a été choisi, parce qu’il est très léger et performant, et propose une architecture MVC.

Outre l’avantage présenté ci-dessus de fournir une structure de données en graphe, les technologies du Web de données promettaient de faciliter la réutilisation des informations biographiques et bibliographiques de la BnF, qui constituent une source indispensable pour reconstituer les parcours de lecture de Foucault (rappelons notamment qu’il passait beaucoup de temps à la BnF).

Un développement expérimental a donc été réalisé pour faciliter deux opérations essentielles du travail sur les fiches : 1) la recherche d’informations sur les documents consultés par Foucault et sur les auteurs qu’il mentionne ; 2) la collecte de ces informations et leur exploitation pour la circulation dans le corpus via les fonctionnalités de recherche et de cartographie.

Le module de recherche permet d’interroger directement les données de la BnF à l’intérieur du formulaire de création d’annotation et d’enregistrer automatiquement les informations pertinentes. Par exemple, supposons qu’une fiche mentionne Wesley et que celui-ci ne figure pas dans l’index nominum qui contient les « entités-personnes ». L’utilisateur·rice peut alors décider de créer une nouvelle entité-personne et lui associer les données de la BnF, i.e. procéder à un « alignement » entre l’entité-personne « Wesley-chez-FFL » et l’entité personne « Wesley-chez-BnF » référencée grâce à l’identifiant pérenne <http://data.bnf.fr/ark:/12148/cb119869651#foaf:Person> .

La vidéo ci-dessous montre comment une entité FFL est créée pour Wesley, comment cette entité FFL est associée à celle de la BnF après une recherche d’informations biographiques, et comment on peut réutiliser cette entité pour d’autres mentions de personnes.

Recherche d’informations sur Wesley, création de l’entité, alignement et réutilisation (vidéo de 2’04)

Sur le même principe, il est possible de créer une entité-document par une recherche sur l’auteur et un mot du titre. Non seulement ce module permet un grain de temps important, puisqu’il n’est pas nécessaire d’aller chercher les informations sur le catalogue de la BnF pour les copier-coller, mais il donne aussi la possibilité de lancer une recherche sur des termes incomplets, comme un mot tronqué ou une expression régulière, ce qui n’est pas faisable dans le moteur de recherche du catalogue de la BnF.

Recherche d’informations sur l’ouvrage d’A. de la Gorce consacré à Wesley, création de l’entité, alignement et réutilisation (vidéo de 2’40)

1.3) Cartographies

Nous avons également produit un module de visualisation interactive, permettant de dessiner des graphes pour représenter les relations implicites entre les fiches de lecture.

Le principe est simple : pour chaque fiche de lecture, représentée par un nœud, associer les auteurs, œuvres, concepts, également sous forme de nœud, et reliés par une arête à la fiche qui les mentionne. L’idée de ces cartographies avait déjà été testée à la suite du projet La Bibliothèque foucaldienne (http://lbf-ehess.ens-lyon.fr/pages/visualiser_les_donnees.html).

Toutefois, le module du prototype FFL permet une véritable navigation dans les contenus produits par l’équipe, puisqu’il est possible de dessiner à volonté le graphe des fiches mentionnant tel élément (auteur, concept ou oeuvre) et de consulter les fiches par un simple clic sur les nœuds qui les représentent. Cela permet de répondre par exemple à la question : quels sont les autres auteurs cités dans les fiches qui mentionnent Nietzsche? Mais également, de faire apparaître des rapprochements inattendus, ou encore, et cela nous a été très utile, d’appréhender de manière synoptique les contenus d’un ensemble documentaire, et de voir en temps réel le travail de description réalisé par l’équipe.

Quelques cartographies ont été exportées à des fins d’illustration (voir la page publique de cartographie : http://ffl-public.huma-num.fr/carto) ; la vidéo ci-dessous présente l’utilisation du module.

1.3 Architecture fonctionnelle et ergonomie

Le principe fondamental de la conception de la plateforme était de réunir sur une même page les fonctionnalités de consultation et les fonctionnalités de production de données.

En effet, la plupart des CMS, dont Omeka, contraignent l’utilisateur·rice à basculer sans cesse de la page de rédaction (interface d’administration) à la page finale, visible par le public. Ce système est chronophage, puisqu’il implique de repositionner le curseur dans des fenêtres ou onglets différents, et rompt la continuité de l’attention. En outre, il est nécessaire de recharger la page finale pour y vérifier la prise en compte des modifications effectuées dans l’interface d’administration. Le problème est d’autant plus gênant que l’écran est petit, et travailler sur un ordinateur portable avec cette contrainte du va et vient entre fenêtres est assez pénible.

Au contraire, comme on peut le voir sur les vidéos ci-dessus, la plateforme FFL réunit sur une même page web plusieurs blocs dont l’affichage peut être modulé, et évite autant que possible de devoir recharger la page.

— le premier bloc occupe la moitié supérieure de la page et contient la visionneuse qui permet d’afficher un feuillet recto-verso. La taille de ce bloc peut être ajustée pour proposer une vue plus complète du feuillet. Ce bloc contient également un bouton qui permet de remplacer la vue du feuillet par une galerie, i.e. d’afficher une vingtaine de vignettes correspondant aux feuillets situés avant et après le feuillet en cours de consultation. Cette fonctionnalité est très pratique pour comparer rapidement la fiche avec son contexte, et notamment trouver une information plus complète ou une graphie plus lisible lorsque le feuillet fait partie d’une série de fiches consacrées au même ouvrage.

— le second bloc, en dessous de la visionneuse, contient les formulaires dédiés à l’ajout d’informations. La colonne de gauche contient un bloc-notes (zone de texte libre avec mise en forme) réservé à l’utilisateur·rice, et son contenu s’affiche à l’identique sur chaque page : cela garantit une continuité lorsque l’on passe d’un feuillet à un autre, et permet d’avoir toujours sous les yeux les dernières notes enregistrées. La colonne de droite contient les informations déjà enregistrées (publiques ou privées) et un formulaire permettant d’ajouter de nouvelles annotations sur le feuillet (qu’il s’agisse d’éléments de description, d’analyse scientifique ou de notes éditoriales). Là encore, il est possible de moduler l’affichage, et de masquer une colonne au profit de l’autre. En outre, les différentes étapes de la création d’une annotation ou d’une entité (saisie d’un texte libre ou sélection d’une entité entité dans une liste déroulante, recherche bio-bibliographique pour créer une nouvelle entité) s’enchaînent dans le même bloc : grâce à la technologie Ajax, qui permet de remplacer une partie de la page par des informations actualisées, les formulaires se succèdent sans affecter le reste de l’affichage, et l’on a toujours le feuillet sous les yeux.

Cette utilisation de l’espace de la page web présente à première vue une certaine complexité, mais l’utilisation est suffisamment intuitive, et le gain de temps est considérable par rapport à un système qui oblige à jongler avec deux fenêtres ou plus. En moyenne, le temps pour saisir des informations sur une série de fiches est réduit environ de moitié, et surtout la continuité de l’attention est préservée, ce qui permet de se concentrer sur le contenu du manuscrit et d’oublier les opérations nécessaires pour comparer les informations ajoutées et le manuscrit.

Malheureusement le temps nous a manqué pour généraliser ce principe à l’ensemble des fonctionnalités, et le prototype comporte encore des pages séparées qu’il est nécessaire d’ouvrir dans d’autres onglets ou fenêtres : une page de recherche, une page personnelle (liste de toutes les contributions du compte utilisateur), une page d’inventaire, une page de galerie permettant d’annoter un lot de fiches sélectionnées.

1.4 Bilan de la production de données : quelques chiffres

2. Transkribus : rendre lisible et indexer le texte des fiches

Développé dans le cadre du projet européen READ (H2020), le système expert Transkribus promettait de révolutionner le travail sur les documents d’archives grâce à l’intelligence artificielle et à ses fonctionnalités de reconnaissance automatique d’écriture manuscrite (Handwritten Text Recognition, HTR).

Une collaboration avec l’équipe du projet READ, entamée en 2017, nous a permis d’expérimenter Transkribus sur les fiches de lecture de Michel Foucault, pour voir dans quelle mesure ce logiciel pouvait nous aider à « lire » et à indexer les manuscrits du philosophe.

Nous étions particulièrement intéressés par la recherche d’occurrences, d’auteurs, de concepts ou bien d’ouvrages, mais aussi par le travail que nous pourrions envisager sur le plein texte : analyses textométriques du lexique, repérage de styles de citations. Ce dispositif promettait donc de faciliter l’exploration de manuscrits encore jamais étudiés pour les sonder automatiquement, mais aussi d’en faciliter la lecture, et d’accélérer considérablement le travail de transcription en fournissant un premier jet qu’il ne reste plus qu’à corriger.

Les résultats des tests sont très encourageants puisque notre équipe a formé un modèle pour reconnaître l’écriture du philosophe avec une précision de 95% (taux d’erreur de 5% sur caractère), après entraînement du modèle HTR sur 600 images.

Malgré l’imperfection des transcriptions, le dispositif s’avère extrêmement utile pour l’exploration d’un corpus. Non seulement la collaboration avec l’équipe READ et le test de l’outil a été une expérience très intéressante, mais elle a totalement modifié notre point de vue sur le corpus et son exploitation.

Vidéo de démonstration de transcription automatique avec Transkribus : http://ffl-public.huma-num.fr/doc/Transkribus_automatique.mov

Article dans une revue :

Marie-Laure Massot, Arianna Sforzini, Vincent Ventresque. Transcribing Foucault’s handwriting with Transkribus. Journal of Data Mining and Digital HumanitiesEpisciences.org, 2019, Atelier Digit_Hum. ⟨hal-01913435v3⟩

Compte-rendu :

Marie-Laure Massot, Jean-Philippe Moreux et Vincent Ventresque. Scénario réalisé dans le cadre du projet ANR Foucault Fiches de lecture (ANR-17-CE38-001) pour tester le logiciel Transkribus sur les fiches de lecture de Michel Foucault. Version du 19/09/2020 : https://f-origin.hypotheses.org/wp-content/blogs.dir/4503/files/2020/09/tester_transkribus-1.pdf

Marie-Laure Massot, Arianna Sforzini, Vincent Ventresque. Transcrire les fiches de lecture de Michel Foucault avec le logiciel Transkribus : compte rendu des tests. 2018. ⟨hal-01794139v2⟩

Vidéos :

Expérimenter Transkribus sur les fiches de lecture de Michel Foucault : Scénario pour tester le logiciel sur un corpus test : tester_transkribus

Vous pouvez consulter les vidéos « Transkribus_automatique.mov » et « Transkribus_KWS.mov » pour vous guider pour transcrire automatiquement une fiche et pour faire une recherche Keyword Spotting.

3. La plateforme publique FFL Eman basée sur Omeka

Une limitation importante de la plate-forme collaborative FFL (prototype) est qu’elle n’a pas été conçue comme un outil pérenne, devant être accessible au grand public, mais comme un espace de travail et d’expérimentation limité aux membres du projet et destiné à l’analyse scientifique. De ce fait, nous avions prévu dès le départ de mettre en ligne le corpus sur deux autres supports plus pérennes et ouverts, la bibliothèque numérique Gallica et le site FFL sur la plate-forme publique EMAN (http://eman-archives.org/Foucault-fiches). Cette dernière contient l’ensemble des données de description qui ont été mutualisées par les membres de l’équipe, et que nous avons isolées des annotations privées, puis exportées vers la base de données gérant le site FFL sur EMAN.

EMAN est une plate-forme permettant la mise en ligne et le travail collaboratif sur des corpus numérisés. Conçue et administrée par Richard Walter, elle compte actuellement plus d’une quarantaine de projets d’humanités numériques, dont le projet FFL. Elle offre une garantie de pérennité des données et de leur accessibilité : hébergée par Huma-Num, elle a été développée sur des bases open source et des formats interopérables (métadonnées Dublin Core et transcriptions XML/TEI ). En outre, son architecture modulaire permet de personnaliser les fonctionnalités de consultation et de travail, ainsi que la navigation dans les corpus, puisqu’elle est basée sur le logiciel Omeka auquel peuvent être ajoutés de nombreux plugins, dont une grande partie spécifiquement conçue pour la communauté EMAN.

Dans le cadre du projet FFL, nous avons choisi d’utiliser EMAN comme le support public final des images et données produites collaborativement dans le prototype. Sans entrer dans le détail technique des opérations, il faut commencer par rappeler ici que l’interopérabilité des outils est un enjeu majeur pour tout projet d’humanités numériques : exporter vers un autre support un corpus numérique aussi volumineux que celui des fiches de lecture serait difficile voire impossible sans la souplesse de systèmes comme Omeka et les technologies RDF.

Comme indiqué plus haut, le modèle de données du prototype permettait d’isoler très facilement certains types d’information et de ne retenir que les contributions qui avaient une visibilité publique. Nous avons donc exporté les données suivantes : classement (chemise ou boîte d’origine du feuillet) ; titre du feuillet ; références bibliographiques et alignements avec data.bnf.fr ; mentions de personnes ; remarques éditoriales. Omeka est construit sur un système arborescent classique de collections contenant des ressources numériques appelées « items » et décrites par des notices – sachant qu’une arborescence de sous-collections est facile à créer. Dans notre cas, un item est un feuillet recto-verso, soit deux images et une notice. Il a donc suffi d’agréger les données RDF de chaque feuillet pour recomposer une notice (abstraction faite des informations de provenance, à savoir la date et l’auteur·e des contributions). L’intégration finale des images et des notices sous formes d’items dans la plateforme publique EMAN a été facilitée par l’utilisation du plugin CSV Import, qui nous a d’ores et déjà permis de mettre en ligne 19 boîtes. Une limite importante de ce plugin est qu’il ne tient pas compte des sous-collections ; cependant la simplicité de la base de données d’Omeka nous a permis, grâce à une seule requête, de reclasser automatiquement les feuillets dans des sous-collections correspondant aux chemises.

La plus grande partie des fiches numérisées sont désormais en ligne et consultables par tout·e internaute. La circulation dans le corpus est possible selon deux modalités, à savoir le plan de classement et les outils de recherche. L’arborescence du corpus est en effet exploitée à deux niveaux : une page qui permet de déplier le plan de classement et donc de développer chaque boîte en chemises, puis chaque chemise en feuillets ; et pour chaque boîte, une page « collection », qui renvoie à la fois à l’ensemble des feuillets et à la liste des chemises (sous-collections). En outre, une présentation a été rédigée pour présenter le contenu et l’intérêt scientifique de chaque boîte, et nous avons y ajouté quelques éléments chiffrés pour rendre compte de la couverture du corpus (nombre d’annotations et références) ainsi que des auteurs et œuvres les plus cités. Cette reconstitution du plan de classement a donc l’avantage d’offrir une vue d’ensemble du corpus et de respecter les chemises constituées par Foucault, et de faire apparaître ainsi les regroupements thématiques effectués par le philosophe. Par opposition aux outils de recherche qui nécessitent de poser une question aux contenus indexés et donc de savoir déjà quoi chercher, cette vue d’ensemble donne la possibilité de découvrir le corpus en le feuilletant.

L’autre accès aux manuscrits des fiches est assuré par les dispositifs d’indexation, avec au premier chef un moteur de recherche SolR intégré au site, à la fois pour permettre d’explorer le plein texte par la recherche simple d’un terme dans tous les champs confondus, et pour l’exploitation des données structurées, en les interrogeant via une fonctionnalité de « facettes ». Ainsi, une recherche simple sur le mot « Freud » renvoie 333 résultats : soit le terme figure dans le titre du feuillet, soit dans celui de la chemise qui le contient, ou encore dans les mentions de personnes et les références bibliographiques. Les résultats peuvent être triés grâce à un système de filtres (facettes) en choisissant un ou plusieurs critères, comme la collection (boîte ou chemise), les références ou les noms de personnes, par exemple pour extraire les sept fiches qui citent également Binswanger.

De plus, tout comme l’arborescence permet de feuilleter le corpus selon son classement, le plugin EMAN Index (page « index des valeurs ») donne à voir l’ensemble des références et personnes citées, en précisant pour chacune le nombre d’occurrences et les titres des fiches, accessibles par un simple clic. Ces informations sont parfois redondantes avec les titres donnés aux feuillets ou aux chemises, mais elles les complètent souvent : d’une part les titres n’indiquent pas toujours la source principale mise en fiche, d’autre part de nombreuses fiches citent plusieurs ouvrages ou auteurs non indiqués dans le titre. Il est à noter que pour des usages plus avancés, les internautes peuvent exporter les données en différents formats tabulaires ou XML, ou demander au comité éditorial l’ouverture d’un accès à l’interface privée d’EMAN, qui propose un moteur de recherche supportant des requêtes plus complexes, et donne la possibilité de participer à la correction ou à l’enrichissement des notices.

En retour, le projet FFL a contribué à faire évoluer la plateforme EMAN (cf. https://ffl.hypotheses.org/activites#eman). En effet, plusieurs plugins et fonctionnalités ont été inspirés par les fonctionnalités du prototype et développés avec les soutiens financier et technique du projet FFL. Ces plugins sont diffusés en open source et réutilisables par chacun des 35 projets de la communauté EMAN, et, plus largement, pour tout·e utilisa·eur·rice du logiciel Omeka (voir le dépôt : https://github.com/EMAN-Omeka).

Ainsi la réflexivité par rapport aux données et à leur production, qui était assurée par le modèle RDF du prototype, s’est traduite en deux plugins apportant une traçabilité des interventions des utilisat·eur·rice·s. Le plugin Historique permet de repérer les dernières modifications et de savoir qui en est l’auteur, ce qui facilite grandement les travaux de correction et d’harmonisation des notices, ainsi que l’organisation du travail en équipe. Le plugin Bookmarks, centré au contraire sur le travail personnel,permet de lister les contenus créés ou modifiés par l’utilisat·eur·rice, d’enregistrer des marque-pages et des notes personnelles, et de comparer des notices. De cette manière, toutes les informations liées au travail sur les collections numériques sont rassemblées au même endroit et accessibles en ligne.

Par ailleurs, la réflexion sur la réutilisation des données nous a inspiré deux autres plugins, le premier concernant les valeurs saisies dans la base de données du site FFL sur EMAN et le second exploitant les données en ligne de data.bnf.fr. EMAN Index, déjà mentionné ci-dessus pour le cas des références et des personnes, permet de générer en temps réel la liste complète des valeurs utilisées pour un champ de notice, et pour chaque valeur de renvoyer vers ses occurrences dans les collections, de les modifier au besoin. En outre, à cet index correspond une fonctionnalité d’auto-complétion pour faciliter la saisie d’informations dans les notices : cela évite l’effort inutile de retaper une information déjà enregistrée, ainsi que les fautes de frappe. Enfin, le plugin BnfMashup permet d’afficher automatiquement des données tirées de data.bnf.fr. Grâce aux alignements bibliographiques évoqués plus haut, qui consistent à associer à un document l’identifiant de sa notice BnF, les technologies du Web de données rendent possible d’incruster à côté de la fiche de lecture la reproduction numérique (stockée dans Gallica) du document lu par Foucault, et les informations bibliographiques (auteur, titre, date, tout ce qui est disponible dans la notice BnF du document, stockées dans l’entrepôt de data.bnf.fr).

NOTES

[note 1] Foucault, M. Binswanger et l’analyse existentielle, 2021, éd. Elisabetta Basso ; Phénoménologie et psychologie, à paraître, éd. Ph. Sabot.

[note 2] Respectivement : C. Verlengia, thèse en cours, chemises de la boîte n° 19 ; L. Paltrinieri, analyse de la lecture de Malthus et chemise « Population » dans les boîtes n° 18 et 19. Signalons également les travaux de G. Dassonneville sur le jeune Foucault (boîte 37) et de J. Guilhamou sur la réception foucaldienne de la philosophie du langage (boîte 43), qui ont donné lieu à des expositions thématiques (cf. http://eman-archives.org/Foucault-fiches/exhibits).

[note 3] « C’est que les marges d’un livre ne sont jamais nettes ni rigoureusement tranchées : par-delà le titre, les premières lignes et le point final, par-delà sa configuration interne et la forme qui l’autonomise, il est pris dans un système de renvois à d’autres livres, d’autres textes, d’autres phrases: nœud dans un réseau ». M. Foucault, L’Archéologie du savoir, 1969. Ce parallèle a été pointé par Martin Rueff, par exemple, dans sa notice à l’édition Pléiade de l’Archéologie : «Car notre époque (nous sommes en 1967 et Foucault se montre très attentif à l’histoire quantitative) est celle du stockage infini des énoncés, de leur transformation en ressource ou en cimetières – en banque de données. Dans un des manuscrits préparatoires à L’archéologie du savoir, Foucault écrit : « Si bien que dans la culture moderne, les énoncés avec lesquels on a rapport, ce ne sont pas ceux qu’on commente, etc., c’est d’abord et avant tout la masse totale de ce qui a été dit et se trouve directement ou indirectement conservé ; à cette masse la culture moderne a rapport dans la mesure où elle fait place à ce fourmillement de choses dites, où elle accueille la rumeur immense et où elle lui prête l’oreille. » À l’heure des ressources les plus puissantes dont l’homme ne se soit jamais doté pour stocker les énoncés et les images dont il double le monde, à l’heure où l’humanité est en passe de devenir digitale, l’archéologue nous ‘nargue’ ici comme nous narguerait un Laocoon vainqueur sous les murs de Troie – ou d’un autre rivage encore. Sa lecture est devant nous.»