Introduction

Cet article esquisse une analyse d’un projet ouvert de traduction collaborative mobilisant le « geste simondonien » (Dodier, 1995 p. 9). Ce projet (Doc fr CIDOC CRM · GitLab, 2023) utilise le logiciel de gestion de version distribuée Git et l’environnement associé GitLab. Depuis 2019, un groupe de chercheuses et chercheurs francophones a entrepris le projet de traduire collectivement en français l’ontologie formelle du Modèle Conceptuel de Référence du Comité International de DOCumentation de l’ICOM (CIDOC CRM) version 7.1.2 (Bekiari, 2022), version choisie pour le renouvellement de la certification ISO 21127 (Croft et al., 2011). Le standard de documentation du CIDOC CRM permet l’intégration et l'interopérabilité des données dans les champs du patrimoine culturel et des sciences humaines et sociales (LeBoeuf, 2013). Les données produites dans ces domaines sont hétérogènes et dispersées au sein de bases de données ou de plateformes de musées, bibliothèques, archives ou laboratoires de recherche. Les définitions et la structure du modèle ontologique permettent de décrire les concepts et les relations implicites pour l'exploration de ces ensembles de données au sein du web sémantique.

Ce projet de traduction collective numérique se construit comme une expérimentation dans le champ des humanités numériques ou digital humanities (University of California, 2009). Celui-ci émerge au sein de la communauté scientifique française avec le manifeste de 2010 (Dacos, 2010). Avant cela, des précurseur⋅es interrogent la place de l’ordinateur dans plusieurs disciplines, par exemple chez les médiévistes (Bourlet & al, 1979) ou au sein de la sociologie de l’innovation (Gavillet, 2010) ou encore chez les médiologues au début des années 1990 (Debray, 2001). En 2017, les sciences de l’information et de la communication en France vont au-delà du champ des humanités numériques (digital humanities) et se positionnent par rapport au projet épistémologique des Digital Studies dans la lignée anglophone (Paquienséguy, 2017). Ce n’est pas un hasard si les termes sont désormais en anglais, en effet, le champ des humanités numériques connaît une nette prédominance anglophone. Par conséquent, les institutions et les chercheurs et chercheuses travaillant dans cette langue sont surreprésentées par rapport aux autres communautés. L’enjeu de la traduction du CIDOC CRM est de permettre à ces dernières de travailler dans leur langue maternelle. Les abstractions conceptuelles devenant plus accessibles, l’appropriation de la méthode de modélisation est facilitée pour la communauté francophone.

Le groupe de traduction se constitue à la suite de DONIPAT, DONnées Interopérables pour le PATrimoine, une école thématique du CNRS organisée en 2019 par le consortium Huma-Num Mémoires des Archéologues et des Sites Archéologiques (MASA). Dans ce cadre, le CIDOC CRM est abordé par le biais de questions de transformation et de diffusion des données. Le jeu CIDOC CRM (Guillem, Bruseker, 2017) et des méthodes d’alignement sont utilisées avec les outils 3M (Marketakis et al., 2017) et Ontop (Calvanese et al., 2015), suite à quoi des participant⋅es ont souhaité approfondir ces questions. Le groupe de traduction se crée alors de manière informelle dans le but de traduire en français le CIDOC CRM. L’objectif principal est de favoriser la coopération autour des technologies du web sémantique et de l’ontologie formelle du CIDOC CRM. Un enjeu sous-jacent commun se dessine : il s’agit de faciliter l’appropriation du CIDOC CRM dans la communauté scientifique en sciences humaines et sociales (SHS). Dès le début, le rôle du projet de traduction collaborative s’avère central dans les processus d'apprentissage et de diffusion de la pratique du CIDOC CRM. Au sein du collectif de traduction, on trouve des chercheur⋅ses individuel⋅les qui collaborent à des mises en œuvre de l’ontologie formelle CIDOC CRM, tant par la modélisation formelle de problématiques données que dans son implémentation technique en lien avec des travaux de recherche de diverses disciplines. Cette appropriation multilingue d’un standard international va dans le sens de l’évolution de la norme IFLA LRM/FRBR (Riva, 2017) adoptée par la Bibliothèque nationale de France (BnF).

Cet effort de traduction vers le français n’est pas le premier : en effet, deux démarches similaires ont été entreprises en 2006 et 2014 (Croft, 2007; Szabados et al., 2012). Ces initiatives internationales étaient, comme celle qui nous occupe aujourd’hui, corrélées dans le temps avec un processus de certification ISO, ou sa révision. La traduction de 2006 concernait la version 4.0 du CIDOC CRM associée à la norme ISO 21127:2006 tandis que la traduction de 2014 concernait la version 5.0.4 associée à la norme ISO 21127:2014. Ces traductions ne sont pas librement accessibles. Comme tout document ISO, leur accès est payant. Le projet dans lequel nous nous sommes lancé⋅es en 2019 a pour objet de produire une traduction ouverte, gratuite et totalement accessible.

Le CIDOC CRM est continuellement mis à jour par un Special Interest Group (CIDOC CRM SIG) dont les procédures se font en anglais. Celui-ci se réunit plusieurs fois par an et contribue à faire évoluer l’ontologie formelle en fonction des usages et la résolution par consensus de questions épistémologiques. À ce jour, l’usage du CIDOC CRM nécessite donc de naviguer entre une documentation obsolète en français et une version en anglais régulièrement mise à jour, ce qui est source d’erreurs et/ou de mésusages. Le choix de traduire à nouveau la documentation CIDOC CRM est aussi lié au nouveau processus réglementaire de certification ISO de la version anglaise - qui fera autorité. Ce souhait de stabilisation du modèle conceptuel de base motive l'investissement en temps et en travail du collectif d’individus impliqués et de leurs institutions respectives. Les concepteur·ices du CIDOC l’ont qualifié d’ontologie « formelle » en adoptant la position de (Guarino, 1998) qui définit ce type d’ontologie comme, d’une part, une spécification d'un ensemble de concepts nommés utilisés pour décrire et approcher un fragment du réel, ainsi que, d’autre part, une théorie logique du premier ordre qui restreint la signification des concepts nommés. Les questions éthiques et pratiques entraînent des ajustements du modèle de base du CIDOC CRM, c’est pourquoi le modèle se déploie avec des extensions thématiques qui couvrent des champs spécifiques de la recherche en SHS, comme CIDOC CRMarchaeo pour les fouilles archéologiques, CRMsci pour l’observation scientifique ou CRMdig pour la provenance des métadonnées. Le modèle et ses extensions évoluent donc en fonction des communautés de recherche qui se l'approprient.

La complexité du texte à traduire (Ladjadj & Chiflet, 2015), les différentes cultures professionnelles et scientifiques des membres du collectif et la diversité de pratiques du CIDOC CRM augmentent a priori la difficulté d’obtenir un consensus autour d’une traduction proposée. C’est pourquoi la concomitance entre l’invention de méthodes d’organisation, de processus de décision et la mise en place de l’environnement GitLab permet de co-construire la plateforme et de la faire évoluer de manière continue. La diversité des langues francophones (de France, de Belgique, du Luxembourg ou du Canada) et leurs pratiques actuelles (par exemple, la pratique de l’écriture inclusive) peuvent également accroître la complexité des choix pour la validation par consensus de la traduction collective en français. Traduire l'ontologie formelle du CIDOC CRM permet aussi de remettre dans l’espace critique des choses qui semblent acquises. Expliciter des données lors d’un appariement avec le CIDOC CRM a un effet performatif : il s’agit de décrire dans ce cadre ontologique des objets, concepts ou assertions sans en réduire le sens. A l’épreuve de la traduction, il peut survenir que des triplets signifiants en anglais ne le soient pas en français. De même, l’implicite n’est pas identique d’une langue à l’autre.

La relation entre les membres du collectif de traduction et l’environnement GitLab d’Huma-Num est envisagée comme une expérimentation en humanités numériques. Celle-ci conduit à considérer a priori le terme de dispositif numérique comme une plateforme, au sens de l’approche critique de la métaphore de la plateforme (Gillespie, 2017). Lieu d’un travail habituellement caché, la plateforme peut se voir assigner la tâche d’héberger le travail réel qui ne peut pas être effacé, voire de le protéger. Pour assumer cette responsabilité, le dispositif numérique initial est peu à peu modifié jusqu’à devenir la plateforme souhaitée par les membres du collectif. Dans ce contexte, la dynamique collaborative du processus de traduction contribue à construire une culture et des techniques communes qui dépassent le cadre socio-technique de production de la traduction. Cette réflexion est nourrie par le contenu textuel à traduire, puisqu’il s’agit de la documentation d’une ontologie formelle servant à décrire le monde. L’analyse fine des relations productives (partie 2) à et par la plateforme de travail tient compte d’une forme de solidarité technique entre l’humain et la machine, de la formation d’un ensemble technique (Dodier, 1995, p.13) ou informationnel (Barthélémy, 2015, p.4), susceptible de réaliser la traduction. Ce cadre d’échanges au sein du groupe génère une auto-analyse théorique continue (partie 3). Le projet donne l’opportunité d’une acculturation avec certains thèmes présents dans l'œuvre de Simondon en lien avec une pratique du numérique. Il crée un espace de dialogue sur l’évolution et la formalisation de nouvelles pratiques professionnelles associées à une numérisation du monde de la recherche. Ces outils conceptuels, dans la continuité du geste simondonien, articulent la réalité de cette production avec d’autres dispositifs.

GitLab comme plateforme de travail du projet de traduction collaborative du CIDOC CRM : méthodes, outils et processus

Le(s) document(s) du CIDOC CRM, ses concepts, ses supports (et leur grammaire), ses enjeux d’usage et les intérêts d’une traduction française

L’acronyme CIDOC CRM désigne le modèle conceptuel de référence (CRM) établi par le Comité International pour la DOCumentation (CIDOC) de l’International Council Of Museum (ICOM). Le CIDOC se compose de professionnel·les issu·es du monde des GLAM (Galeries, Bibliothèques, Archives et Musées). Les membres du CIDOC sont invité·es à participer à divers groupes de travail. Le CIDOC CRM est l’un d’entre eux. Il cible la question des normes documentaires.  Initialement, ce modèle devait avant tout soutenir les pratiques de catalogage des objets de musées, de la même manière que la définition de l’ISBD (International Standardized Bibliographical Description) avait standardisé le catalogage bibliographique au début des années 1970 en soutenant la création des formats d’échange de données bibliographiques tels que le MARC ou le MARC 21 par exemple (Anderson, 1978; Gorman, 1978, 2014). L’émergence du web sémantique a considérablement élargi les perspectives originelles du projet.

Aujourd’hui, le CIDOC CRM est une ontologie, reconnue depuis 2006 comme un standard descriptif (Organisation internationale de normalisation, 2014)  pour la modélisation des informations relatives aux objets patrimoniaux.  La page d’accueil du site Web du CIDOC CRM (Home | CIDOC CRM, s. d.) présente le modèle comme une ontologie formelle, mais peut être considéré également comme une ontologie de domaine. Concrètement, le modèle propose un ensemble de classes (appelées entités) et de relations (appelées propriétés) assemblées en une structure hiérarchisant les entités entre elles selon un principe de spécialisation (de la super-classe à la sous-classe), qui s’applique aussi aux propriétés mettant en relation deux entités, d’un domaine (domain) vers un co-domaine (range). Ce schéma permet d’implémenter l’information sous la forme de triplets RDF (Resource Description Framework) du consortium mondial du web (W3C) (RDF - semantic web standards, s. d.). En sus, le CRM édicte une définition pour chacun de ses concepts afin d’en asseoir le socle sémantique. Celle-ci est elle-même structurée, à la fois au moyen des champs issus de la logique de premier ordre des relations de spécialisation entre classes (extrinsèques à la classe elle-même), mais aussi par une structure propre constituée par une note d’application (scope note) et des exemples, ainsi qu’une cardinalité définie par les relations.

Le CIDOC CRM initial porte désormais le nom de CRMbase. C’est lui qui bénéficie du statut standardisé. Cet ensemble central est ourlé de plusieurs extensions élaborées au fil du temps par divers groupes disciplinaires ou de secteurs d’activités différenciés. Ces extensions permettent de cibler soit des domaines spécifiques au monde culturel (par exemple les opérations de fouilles archéologiques), soit des domaines liés (par exemple le domaine de la bibliographie), ou encore des méthodologies d’acquisition des connaissances (telles que l’observation scientifique).  Le vocable CIDOC CRM désigne le CRMbase ainsi que l’ensemble de ses extensions. Les mises à jour du CIDOC CRM se pratiquent grâce à des réunions du Special Interest Group (SIG) qui se réunit deux fois par an. Chaque version du CIDOC CRM est publiée sous forme d’un texte accessible dans un document numérique au format word ou pdf le plus souvent. Des sériations dans des formats standards interopérables RDF et OWL (OWL - semantic web standards, s. d.) ont également été proposées.  Le travail du collectif de traduction se concentre sur le texte semi-structuré extrait du document numérique au format word (.docx) de la version 7.1.2 du CRMbase.

La plateforme GitLab comme dispositif technique et informationnel pour le projet collaboratif de traduction

Nous l’avons dit plus haut, le projet de traduction collective se développe comme une expérimentation (Gavillet, 2010) en humanités numériques. L’approche pluridisciplinaire du projet (traduction, édition numérique, sciences de l’information, standard de documentation…) « implique des changements dans les langages, les pratiques, les méthodes, et les résultats » (traduction des auteur⋅rices, University of California, 2008, #4). Le choix d’utiliser l’environnement GitLab d’Huma-Num répond à un besoin technique pour produire la traduction collective et permet également d’affirmer les valeurs du groupe de partage des connaissances, d’appropriation libre, d’accès ouvert aux contributeur⋅rices, des principes FAIR (Findable, Accessible, Interoperable, Reusable) (Wilkinson et al., 2016). L’environnement GitLab est le plus souvent utilisé pour le contrôle de versions de travaux, documentations, éditions et le développement de programmes informatiques, mais le groupe s’est approprié cet objet numérique dans un « besoin de travail d’équipe comme nouveau modèle de production et reproduction de savoir des humanités » (traduction des auteur⋅rices, University of California, 2008, #9). Pour reprendre les termes du Digital Manifesto, ce qui fait le « coeur des humanités numériques, [c’est la] prise de risque, collaboration et expérimentation » (traduction des auteur⋅rices, University of California, 2008, #9). Cette partie montre comment le projet détourne la plateforme et les fonctionnalités de Gitlab pour mettre en œuvre l’expérimentation d’une traduction et d’édition collective et numérique du CIDOC CRM en français.

Les caractéristiques de la fonction productive de la plateforme numérique en relation avec les valeurs de la communauté et les objectifs du projet de traduction collective semblent une polyphonie éditoriale qui se déploie tel un architexte (Bazet et al., 2017) co-constitué par les relations transformatrices du texte à traduire, transformant le texte lui-même, la plateforme et le groupe d’individus. Comment créer un flux de travail numérique qui permette l’initiation, le suivi et la gestion des versions (versionnement) des éléments de traduction de manière simple pour les contributeur·ices ? GitLab rend possible le versionnement par le dépôt-archivage public des fichiers de travail et du projet. Les jeux de données et la documentation produite par le projet de traduction sont ouverts et accessibles pour la réutilisation et la reproductibilité de l'expérience. Le collectif s'appuie sur des fonctionnalités de la plateforme GitLab pour versionner la traduction et la documentation associée. La création de tickets (issues) permet de documenter le processus de traduction mobilisant le langage markdown. La définition du tableau de bord (boards) permet de suivre l'avancée du travail de traduction et de validation. Des branches scindent les alternatives de versions de textes et des jalons (milestones) organisent les sessions de traduction/validation autour de groupes cohérents d'entités et de propriétés de l’ontologie du CIDOC CRM.

Fichiers, dépôt et tickets (issues) dans la plateforme GitLab et projet de traduction

Pour les lecteurs et lectrices habituées à Git et Gitlab, il est possible de sauter les paragraphes suivants pour aller directement à l’utilisation de GitLab dans le processus de traduction.

Git permet de gérer le versionnement en ligne de commande. GitLab est une interface graphique qui est construite sur Git pour ajouter des fonctionnalités complémentaires de gestion de projet (tickets, jalons, tableau de bord), de gestion des droits d’accès des contributeur⋅rices (rôles) et d'intégration continue (GitLab runner). Le workflow typique de Git implique des actions pour : (a) dupliquer localement les fichiers du serveur distant (git clone, git pull), avant de (b) réaliser des modifications de manière asynchrone, puis de mettre à jour l’historique des changements (c) git commit, et permettre le versement des modifications (d) git push, à la prochaine connexion avec le serveur. Ainsi, GitLab est une application serveur qui centralise les fichiers et sert d’interface web pour accéder au projet. La plupart des contributeur⋅ices peut ainsi modifier les fichiers via la plateforme GitLab sans en connaître les mécanismes sous-jacents. Avec GitLab, le processus de travail est simplifié, les étapes de synchronisation avec le serveur (a) et (d) sont supprimées.

L’usage veut que chaque modification d’un dépôt Git, par exemple une proposition d’ajout d’une traduction de texte, fasse l’objet d’une demande de fusion (merge request). Outre la difficulté technique pour le ou la contributrice, cette modalité d’organisation du travail  implique généralement la validation par un⋅e chef⋅fe de projet, Or la volonté du groupe est d’avoir un processus de validation collégiale. La traduction, telle que proposée, est intégrée immédiatement à la plateforme sous un certain statut (traduit en attente de révision). Elle devient l’ébauche support de la discussion lors de la séance de validation et change alors de statut (en cours de révision).

Il n’est pas nécessaire d’être un expert de Git pour utiliser les services de la plateforme GitLab. Le fichier README (README.md · translate · Doc fr CIDOC CRM · GitLab, s. d.) présente le projet de traduction. Le Wiki (Home · Wiki · Doc Fr CIDOC CRM · GitLab, s. d.) intégré à GitLab donne accès à un tutoriel pas-à-pas, expliquant comment participer aux traductions, et aux comptes rendus des principales réunions. Les relations à la plateforme du groupe de projet et ses individus sont hétérogènes. Toutefois, cette hétérogénéité n’apparaît pas comme un obstacle, mais plutôt comme une richesse dans la mesure où la relation à la plateforme fonctionne également comme un système de documentation, d’information et de transfert de connaissances et compétences.

Le plus souvent, un dépôt (repository) permet d’entreposer et de partager du code de logiciels exprimé dans un ou plusieurs langages informatiques (php, java, C etc). Pour le projet de traduction collaborative, le dépôt permet de donner accès non pas à du code informatique, mais aux textes, tables et figures du CIDOC CRM à traduire. Le texte issu du document numérique au format MS-Word (extension .docx) est fragmenté de manière logique et partiellement automatisée avec l’application d’expressions rationnelles ou régulières (regex) (Préparation des fichiers à traduire (#8) · Issues · Doc fr CIDOC CRM · GitLab, s. d.; David-Jacquot, 2021). Les fichiers sont alors organisés par grands types  : (a) les textes introductifs, le texte structuré définissant chacune (b) des entités et (c) des propriétés, puis (d) les figures et (e) les tables. L’environnement GitLab permet au groupe de traducteur⋅rices un accès libre et ouvert au texte à traduire, mais aussi à la documentation, au suivi et aux choix des traductions réalisées ou à entreprendre.

L’utilisation est un détournement de la plateforme numérique Gitlab qui rend possible un processus itératif et collaboratif de traduction et de validation. Chaque élément à traduire entre dans le flux de traduction à la création d’un ticket (issue). Celui-ci contient la mémoire des opérations réalisées sur cet élément. Il peut être assigné à un⋅e ou plusieurs contributeur⋅rices au cours du projet.

Tickets et tableau de bord : workflows de traduction et de validation

Rappelons tout d’abord que l’utilisation de la fonctionnalité du ticket (issue) est proche de celle d’un guichet pour mettre à l’ordre du jour un problème ou une question afin de la résoudre souvent collectivement. Traditionnellement, les tickets (issues) sont utilisés en développement de projet informatique pour une remontée de bug ou une demande de nouvelle fonctionnalité, d’évolution, d’extension ou d’adaptation. La page d’un ticket contient les échanges entre la personne à l’origine de la demande et celles qui prennent en charge la résolution de ce ticket. Dans le cadre de la traduction, le groupe a fait le choix de créer un ticket pour chaque élément à traduire. Cela permet, d’une part, le suivi du travail et des questions posées et garde trace des choix réalisés en temps réel. D’autre part, l’association d’un ticket à chaque élément permet de dissocier la traduction elle-même (dans chaque fichier du dépôt) de sa documentation, produite lors de la traduction. Ce ticket constitue la note de traduction avec les remarques sur le texte en anglais (erreurs typographiques, exemples, bibliographie), la restitution des discussions etc.

Figure 1 : Avancée des tickets (issues) dans les workflows de traduction et de validation des traductions utilisant les tableaux de bord (boards) et les étiquettes (labels) dans la plateforme GitLab pour le suivi du projet.

Après l’entrée de l’élément à traduire dans le flux de travail, le suivi de la traduction et de la validation par le groupe est assuré grâce aux fonctionnalités du tableau de bord (boards). Il permet l’organisation des tickets et leur manipulation (Development · Boards · Doc fr CIDOC CRM · GitLab, s. d.) pour la gestion d'un double workflow (figure 1). La définition des étapes des workflows de traduction et de validation sont discutées puis choisies par le groupe collectivement.

La première partie du workflow comprend quatre étapes de traduction. Dans la première d'entre elles, l'élément à traduire entre dans le flux de travail selon les priorités définies par le groupe. Ensuite, un·e ou plusieurs contributeur·rices (s’)assignent la traduction de l’élément à traduire selon les intérêts scientifiques de chacun·e. Le travail de traduction se fait de manière asynchrone. Lorsque l'élément a été traduit, il est prêt à être discuté au sein du groupe en vue de la validation de sa traduction.
La seconde partie du workflow est dédié aux étapes de validation. L'étape n°3 est un moment charnière dans lequel on passe d'un flux individuel de traduction à un flux collectif de validation. À ce stade, la proposition de traduction de l’élément est discutée collectivement. Sa cohérence sémantique et syntaxique est vérifiée. Après l'étape de révision, la traduction finale est donc une production consensuelle et collective. Finalement, lorsque la traduction est terminée, le ticket est labellisé "validé" puis il est clos. Cette dernière opération permet de mesurer l’avancement dans les jalons (milestones).

La vision d’ensemble du projet au moyen du tableau de bord permet une cohérence dans la mise en œuvre de la traduction individuelle asynchrone avec la validation qui est synchrone et collective. La complexité combinée du CIDOC CRM avec celle de la plateforme génère un besoin de discussion continuelle mobilisant les participant·e·s ayant une connaissance approfondie du CIDOC CRM et/ou de GitLab. Ces débats aboutissent non seulement à des ajustements de la plateforme numérique mais également à un affinage cognitif collégial.

Figure 2a : exemple de changement d'étiquette (label) pour le ticket (issue) #87 pour l’entité E10 Transfer of custody (E10 Transfer of Custody (#87) · Issues · Doc fr CIDOC CRM · GitLab, s. d.).

Figure 2b : exemple de changement dans le tableau de bord (board) du ticket (issue) #82 pour l'entité E30 Rights (Development · Boards · Doc fr CIDOC CRM · GitLab, s. d.).

Pour matérialiser le passage d’une étape du workflow à une autre (figure 2b), le ticket (issue) est déplacé d’un tableau de bord (boards) à l'autre. Cela a pour conséquence, à l’échelle du ticket, d’assigner une étiquette (label) jusqu’à l’attribution d’une étiquette ultérieure. Cela modifie le statut du ticket en y attachant le libellé des étapes de traduction et de validation. Un historique des processus de traduction et de validation est ainsi créé (figure 2a). Les étiquettes (labels) permettent ainsi une double relation à la plateforme. Chaque ticket trace l’état d’avancement de traduction à l’échelle de chaque élément, tandis que le tableau de bord (boards) présente une vue de l’avancée globale du projet de traduction (figure 2b). À ces deux échelles, la relation à la plateforme diffère par la nature du processus de production en jeu. À l’échelle du ticket, les étiquettes permettent de fournir l’information relative aux processus de traduction et de validation, mais aussi celles correspondant à la définition de labels d’état (entité, propriété) et de version de travail etc. À l’échelle du tableau de bord (boards), l’itération est possible puisque la validation de la traduction d’un élément se poursuit par la fermeture du ticket associé, qui pourra être ré-ouvert pour initier la mise à jour de la traduction lors du passage à une version ultérieure de la documentation de l’ontologie.

Si la plateforme GitLab permet de visualiser la trace des actions réalisées à l’échelle du ticket ou d’un ensemble structuré de tickets (boards), elle permet aussi de rendre visible la genèse des transformations successives du texte (fichier markdown) au cours du temps et au moyen des enregistrements successifs (commit) qui sont rattachés à une branche de traduction (branch) active. Le rapport entre le groupe de traduction et la plateforme GitLab permet de gérer le processus de traduction de manière collective et transparente, tout en la rendant actionnable, c’est ce que la partie suivante montre avec le processus d’intégration continue et d'éditorialisation numériques (Bachimont, 2007, Vitali-Rosati, 2016 & 2020).

Les branches dans GitLab et l’intégration continue et publication vers une page web

Une grande partie du succès de Git vient de sa gestion efficace et rapide des branches. Une branche (branch) est une succession d’états donnés (commits) de l’ensemble des éléments du dépôt (fichiers versionnés). Plusieurs branches peuvent coexister au sein d’un seul dépôt, ce qui nous permet dans le projet de traduction de diverger d’une branche parente pour traduire une ou des versions différentes du document. Si l’intention initiale du projet conduit à créer une première branche translate (figure 3), son évolution est de ne pas se limiter à la traduction de la version ISO actuelle 7.1.2, mais de continuer à traduire les différentes versions de l’ontologie et de ses extensions. Ainsi, quand la traduction de cette version ISO 7.1 sera réalisée, une nouvelle branche sera créée pour prendre en compte les modifications de la prochaine version du modèle (actuellement la version 7.2). Outre le fait de permettre le travail sur des versions différentes du document, l’usage de différentes branches permet de publier en même temps différentes versions, comme c’est le cas pour la plupart des projets de documentation des bibliothèques logicielles (framework) (Symfony n.d.), dans le domaine du développement informatique.

Figure 3 : évolution du modèle du CIDOC CRM, évolution du projet de traduction, implémentation par les branches (branch translate).

La publication de la traduction des différentes versions du CIDOC CRM est immédiatement accessible à l’URL suivante : https://cidoc-crm-fr.mom.fr/ grâce à l'intégration continue. Ce processus itératif automatisé synchronise le contenu des documents de travail markdown avec une mise en forme HTML de la publication. Les choix techniques tiennent à deux arguments : (a) la simplicité et le coût réduit de la transformation éditoriale : la transcription est exécutée par le logiciel pandoc dans un environnement de style (framework) standard et léger, et (b) l’accès simple et rapide à l’entité ou la propriété recherchée dans une page web statique. Les commandes permettant l’intégration continue (Doc fr CIDOC CRM  ·  translate  · GitLab  ·  .gitlab-ci.yml, s. d.) sont rassemblées dans un fichier d’instructions (gitlal-ci.yml) versionné au sein de chaque branche. À chaque enregistrement (commit), la plateforme exécute automatiquement les commandes (scripts) réalisant les deux étapes (stages) suivantes : (a) la préparation (build) de l’ensemble des fichiers à publier, dont notamment (i) le sommaire dynamique (ancres HTML) des entités et des propriétés à partir des noms des fichiers du dépôt, (ii) la transcription en code HTML des textes codés en markdown et (iii) la création des pages statiques HTML. La seconde étape consiste en (b) la publication (deploy) de la traduction par le déplacement des fichiers transformés, agrégés et construits en code HTML vers le serveur (WEB) de consultation pour les usagers.

La page web statique (figure 4) ainsi déployée fournit l’état d’avancement du travail de traduction le plus à jour. Elle permet la navigation au moyen de la fonctionnalité des ancres HTML référencées dans le sommaire. Ce dernier fournit une vue d’ensemble qui rend compte des éléments de texte entrés dans le processus de traduction ; en effet, ceux qui ne sont pas encore traduits ont un intitulé vide. Le groupe fait ainsi le choix de rendre visible le travail qui reste à faire. De fait, tous les éléments publiés ne sont pas au même stade dans le processus de traduction/validation : par exemple, certains d’entre eux sont traduits en attente de validation, tandis que d’autres sont validés. La publication par intégration continue présente donc un instantané de la traduction. Elle gomme la complexité du processus de traduction collective. Elle n’en présente que le résultat.

Figure 4 : page web qui publie le résultat de la traduction depuis les fichiers en markdown grâce à l'intégration continue.

La page web de publication du work in progress est produite par la relation à la plateforme GitLab, mais elle est extérieure à celle-ci : les fichiers constitutifs de la version HTML de la traduction en cours sont présents sur le serveur de la Maison de l’Orient et de la Méditerranée (MOM). Il n’est pas possible de modifier directement le code HTML issu du processus d’intégration continue. Cela n’est pas non plus souhaitable, car ce travail ne serait pas pris en compte par la plateforme. La participation au processus de traduction/validation nécessite donc le retour à la plateforme GitLab. Les contributeur⋅rices y mesurent l’avancée du projet et y définissent les priorités de traduction, grâce à la fonctionnalité des jalons (milestones) de GitLab.

Jalons (milestones) dans GitLab et organisation des sessions de validation

En programmation informatique, les jalons (milestones) sont utilisés pour définir des séquences (sprints) agiles, auxquelles sont associés des tickets (issues). La culture agile est liée à l’expression de valeurs, notamment : « des individus et de leurs interactions plutôt que des processus et outils » et « des logiciels opérationnels plutôt qu’une documentation exhaustive » (Manifeste Pour Le Développement Agile de Logiciels, n.d.). Pour la plateforme de traduction, l’utilisation des jalons permet de reprendre notamment le principe agile de simplicité, c’est-à-dire « l’art de maximiser la quantité de travail qu’on ne fait pas ». De même, la compréhension au fil de l’eau du projet permet de développer des fonctions au gré des besoins (YAGNI, 2022). En conséquence, le processus permet des livraisons régulières de fragments traduits et de techniques associées, sur de courts délais et évalués collectivement.

Adoptant une pratique agile dans le projet de traduction, le groupe tire parti de la structure non linéaire du texte à traduire. En effet, l’ontologie est organisée par des relations hiérarchiques (classes et sous-classes) et des relations entre entités et propriétés. Or l’utilisation des tickets au sein de tableaux de bord (boards) ne permet pas de transcrire ces relations sémantiques et syntaxiques de l’ontologie. La fonctionnalité des jalons (milestones) permet de tenir compte de cette organisation intrinsèque au texte à traduire par des regroupements d’entités et de propriétés fondés sur deux concepts propres au CIDOC CRM (figures 5 et 6) : le domaine d’une propriété et la relation de spécialisation d’une entité. (i) Le domaine (domain) est l’entité dont la propriété part pour la relier à une autre entité (son co-domaine, range en anglais), (ii) la relation de spécialisation IsA traduit une relation hiérarchique entre entités.

Par exemple :

(i) l’entité E99 est dans le même groupe logique que les propriétés P187 et P188 dont elle est le domaine :

E99 Product Type :
- P187 has production plan (is production plan for): E29 Design or Procedure
- P188 requires production tool (is production tool for): E19 Physical Object.
E29 et E19 sont les entités co-domaine respectivement de P187 et P188.

(ii) E55 est dans le groupe logique de l’entité E28 dont elle est une sous-classe :

E55 Type IsA E28 Conceptual Object,

et le groupe E55 contient les sous-classes E56, et E57, E58 et E99 :
- E56 Language IsA E55 Type,
- E57 Material IsA E55 Type,
- E58 Measurement Unit IsA E55 Type,
- E99 Product Type IsA E55 Type.

Les entités et propriétés à traduire sont ainsi regroupées par proximité sémantique au sein de groupes logiques (voir figures 5 et 6) au moyen d’un script.

Figure 5 : représentation schématique d’un groupe logique à un moment donné du flux de travail, reprenant : (i) la hiérarchie des entités (IsA), (ii) les relations (has domain) avec les propriétés associées à l’entité considérée, (iii) le nombre calculé de mots de la note d’application et (iv) l’état au regard des étapes du workflow.

Figure 6 : Hiérarchie des groupes sémantiques support de la construction des jalons (entités et propriétés avoisinantes).

Les jalons (milestones) de GitLab ainsi construits permettent simultanément le suivi de la création des tickets, mais aussi une planification possible du déroulé de la validation des traductions. Ils répondent au besoin de définir une cohérence dans les priorités de traduction et de validation au sein du collectif. La production de ces jalons résulte de la rencontre entre une relation experte à la plateforme (technicité), une prise en compte de la structure interne du texte et la nécessité d’assurer la qualité de la traduction. En ce sens, l’activité technique associée à la traduction suit les besoins et les priorités du groupe de traduction. La relation du groupe de traduction à la plateforme GitLab est une relation productive et inventive qui laisse la possibilité à d'autres relations d'émerger et, outre la traduction du CIDOC CRM, de transformer tant les individus que la plateforme elle-même.

Dépasser la fonction technique et productive de la plateforme : analyse simondonienne de l’objet technique numérique

La traduction elle-même est un moyen et non une fin per se : il s’agit de faciliter l'accès et l’usage du CIDOC CRM par la communauté francophone de chercheur⋅ses en patrimoine culturel. La description de l’expérimentation (cf. seconde partie) montre qu’envisager la plateforme comme agrégat d’éléments socio-techniques productifs est réducteur. En effet, la relation à la plateforme relève d’une triple logique de transformation : (a) celle du travail de traduction d’un document en contexte numérique, mais aussi (b) l’évolution de la plateforme elle-même au gré de la mise en oeuvre du projet et (c) celle des relations au sein du collectif, dans leur appropriation du CIDOC CRM et leurs rapports au numérique.

La complexité de l’expérimentation et des processus de transformation en relation à la plateforme nécessite d’introduire des concepts articulant ontologie et technologie. La démarche d’auto-analyse de la relation du groupe à et par la plateforme au fil de l’eau fait appel à l’usage d’une « boîte à outils » conceptuels (Gavillet, 2010, p.34) qui aide à expliciter à la fois la relation à la plateforme et la posture d’expérimentation. La philosophie de la technique de Simondon se prête bien à une analyse incarnée dans une pratique (Barthélémy, 2014). L’ontogenèse proposée s'appuie simultanément sur la lecture de textes de Simondon (Simondon, 2005 & 2012) et ceux en prolongement de la philosophie simondonienne.

Ancrée à la technicité (Duhem, 2013, Feenberg, 2016) et non à l’usage de la plateforme numérique, l’expérimentation élabore une construction collective de sens. Cette expérimentation peut être appréhendée à l’aide de concepts simondoniens dans une perspective épistémologique vis-à-vis de notre pratique en humanités numériques. La définition de l’objet technique numérique (3.1), le fichier markdown d’une entité ou d’une propriété, permet d’éprouver les notions de préindividuel, d’individuation et de milieu associé. Ajoutons à cela que les mécanismes transductifs, empiriques ou computationnels, transforment le document initial et la plateforme elle-même (3.2). La traduction en français du document, intention initiale à la constitution du groupe, concrétise (3.3) un ensemble d’individus techniques qui contribuent à une amplification (3.4) de ce qui est produit dans la relation entre l’humain et la machine.

Les apports de Simondon dans la théorie de l’objet technique numérique

Selon Simondon, la définition de l’objet technique a deux volets : il est défini par sa genèse (Simondon 2012, p.15) et il s’individue au sein de son milieu (Simondon 2005, p.63). Il est d’abord défini par sa genèse, ou comment l’objet s’est individué au cours du temps. L’objet technique résulte de la rencontre de deux demi-chaînes techniques ou opérations incomplètes. Dans l’exemple de la fabrication de la brique (Simondon 2005, p.41-45), une première chaîne opératoire de la matière transforme l’argile avec l’eau. Une seconde chaîne opératoire correspond à la prise de forme par le moulage, le façonnage et le séchage ou la cuisson de la brique. Ces deux demi-chaînes opératoires sont nouées par un geste technique réalisé par l’humain. Ensuite l’individuation met en relation des structures d’échelles différentes au sein du milieu, relation qui sous-détermine le processus de prise de forme. La genèse de l’objet technique concerne sa « concrétude » (Grosman, 2016, p.253), c’est-à-dire à la fois la réalisation d’une synergie fonctionnelle dans la relation de l’objet technique à son milieu et la dynamique de ce processus. En termes simondoniens, il s’agit au cours du processus d’individuation de réduire les incompatibilités dans la relation entre le moule et l’argile dans le milieu associé pour faire advenir la brique (concrétisation).

Toutefois, cette définition des objets techniques physiques peut-elle être étendue au monde du numérique ? L’utilisation de la définition simondonienne pour l'objet technique numérique a deux conséquences. La première est sociale et culturelle, elle induit un changement de paradigme dans la relation au document ou à la plateforme. Les deux ont un mode d’existence indissociablement culturel et technique. La seconde conséquence est technique : il s’agit de prendre le document ou la plateforme numérique non comme un objet fini et utilitaire, mais comme résultant de transformations successives et susceptible de se transformer de nouveau. Sur ce dernier volet, le terme numérique est ici utilisé pour désigner la technique permettant de réaliser des opérations sur des données en relation ou non avec des réseaux de données ou des bases de données, au sein de réseaux d’ordinateurs (Hui 2015). Dans ce contexte, Hui (2015) définit l’objet numérique (digital object) comme un nouveau type d’objet technique industriel, constitué de données et de métadonnées, appréhendables à la fois par des humains et des ordinateurs, au moyen d’un code commun.

La définition de l’objet numérique comme objet technique fonctionne bien dans le cadre du projet de traduction. En effet, la plateforme GitLab donne à voir les mécanismes ou opérations de transformation des objets techniques numériques (fichiers markdown) du dépôt, à savoir leur édition, les choix de traduction, l’inscription du texte traduit, les corrections de syntaxe, leur homogénéité et cohérence interne. Ces mécanismes se propagent de proche en proche, en résonance interne à la traduction elle-même. La découverte progressive d’un sens partagé du texte anglais s’inscrit dans une continuité entre connaissance empirique du modèle et attribution théorique de sens. Par exemple, il est fréquent qu’un terme anglais soit mieux traduit par un terme français de sens commun que par le terme technique peut-être plus juste en théorie, mais peu compréhensible en pratique. Cette approche n’est ni inductive, ni déductive, elle est transductive.

Azema, (2022) investit le concept simondonien de transducteur à la lumière de la pratique du design, comme traduction de la matière. Elle souligne le triptyque outil, fabricant et matière comme un système où la traduction désigne la concrétisation d’un objet abstrait. Selon son expérience, la morphogenèse de la traduction est un processus créatif formulé dans le langage des choses, c’est-à-dire une traduction première permettant de nommer les choses, un langage du domaine du sensible. Chaque choix, dans notre traduction, résulte de la tension créée par la multiplicité des sens possibles : le sens publié dans les dictionnaires, le vocabulaire disciplinaire ou enfin la signification empirique. Ce processus détermine l’individuation du texte traduit. Il y a un ancrage de la traduction dans le milieu et son actualité. Le groupe de contributeur·rices est lui-même situé au sens où une même intention de traduction n’aboutit pas à une même concrétisation de la traduction. C’est le cas de la traduction en français du CIDOC CRM par deux groupes, l’un dit « français continental » et l’autre « français canadien». Chaque projet conduit à des processus d’individuation différents.

On peut aller encore plus loin et envisager la relation à la plateforme de traduction comme le lieu des échanges possibles au moyen de transducteurs entre des vases communicants que sont le groupe de traduction, le texte-code et la plateforme. Par analogie, les opérations qui ont lieu au sein de la plateforme sont transductives, à la fois empiriques et computationnelles, contribuant à faire passer la plateforme d’un état à un autre. Elles produisent un individu constitué par la mise en relation de cet ensemble, mais un individu susceptible d’évoluer continûment encore car en relation avec son milieu associé. C’est pour cela qu’il reste, selon les cas, inachevé ou métastable. La plateforme elle-même devient un objet technique numérique, un être-relation, qui permet la transformation des individus par la circulation de l’information. On peut même considérer la plateforme comme une « matière inorganique organisée par son fonctionnement », elle-même procédant d’une individuation par sa logique propre de détermination et de transduction (Azéma, 2022, #24), et que « l’opérateur humain doit apprendre à "écouter" dans le fonctionnement matériel » (Stiegler, 1993 cité par Azéma, 2022).

Le texte et la plateforme comme individus techniques simondoniens

Simondon définit le préindividuel comme ce qui deviendra l’individu technique dans son milieu associé avant son individuation. Il est caractérisé par son potentiel de transformation plutôt que par son état existant. Les fichiers markdown sont des objets techniques numériques qui constituent des éléments unitaires irréductibles, contenant le texte en anglais des entités et propriétés du CIDOC CRM à traduire, soit 241 fichiers représentant environ 70% du texte total. Le devenir de ces fragments est ouvert : les opérations de transformation en markdown sont une étape préparatoire, préalable à la traduction, agnostique au document numérique considéré. De même que le mélange eau-argile ne détermine pas la fabrication d’une brique ou d’une céramique, l’ensemble de ces fichiers textuels ne présuppose pas le terme de la relation à la plateforme : ces fragments peuvent être transformés par d’autres expérimentations numériques que la traduction. Le fichier markdown résulte d’une chaîne opératoire complexe conduisant à la rencontre d’une forme (la syntaxe markdown) et d’une matière (le texte). En termes simondoniens, l’ensemble documentaire fragmenté et ainsi formaté au sein du dépôt GitLab est constitutif d’un être préindividuel à la traduction. La relation à cet être préindividuel est réalisée par la création d’un code commun (Grosman, 2016, p. 250) généré entre la plateforme GitLab et les contributeur⋅rices. Ainsi, avant même la création d’un ticket ouvrant le flux du travail de traduction, le fragment de texte brut en anglais est individué grâce au geste technique et intellectuel du collectif.

Cet ensemble fragmenté du texte est classé en différents répertoires qui correspondent à des éléments de la structure du dépôt (repository) GitLab. Par exemple, le dossier intitulé entities comprend tous les fichiers markdown contenant chacun le texte des entités du CIDOC CRM. Celles-ci sont elles-mêmes structurées par le formalisme de leur description et la logique de leurs relations (cf. 2.5). En traduisant des fragments de la documentation, le collectif met à l’épreuve la cohérence interne du texte initial : dans quel ordre et selon quelles priorités les choix de traduction doivent-ils être discutés ?

À ce stade, la matière du texte à traduire et les choix du collectif transforment la manière d'interagir avec la plateforme, ce qui a pour conséquence de modifier la plateforme elle-même. L’accès via les jalons a fini par détrôner l’accès initial par le tableau de bord. Peu à peu, les modulations de la plateforme visent à refléter la cohérence interne du texte. En outre, la plateforme prise comme architexte (Bazet et al., 2017) du texte traduit s'individue au sens d’un objet technique proto-industriel. Elle accommode la plasticité du texte en cours de traduction en résolvant les tensions associées à une double finalité. La première est de conserver la mémoire des processus et de rendre visible une ontogenèse de la traduction elle-même. Cette dernière articule l’individualisation du texte traduit (page web HTML) et la concrétisation de l’architexte constitué par la relation du groupe de traduction à la plateforme (par exemple les notes de traduction dans les tickets, ou les scripts associés à la syntaxe). La seconde finalité est celle de la reproductibilité de ces mécanismes d'adaptation et de plasticité du texte pour la traduction d’une autre version ou celle d'un autre groupe dans une autre langue, en conférant à l’architexte des caractéristiques structurelles (sémiotiques) et opératoires (computationnelles) communes (Bazet et al., 2017).

La plateforme ressemble ainsi à une machine ouverte au sens de Simondon (Barthélémy, 2015). Il s’agit d’une machine parce qu’elle est composée de 3 types d’éléments organisés :

• des instruments : le langage informatique utilisé ou le protocole URL,
• d'éléments informationnels : le fichier d’instructions, l’interpréteur, la mémoire vive ou le processeur,
• d'outils : un clavier, une souris ou un écran.

Tout en faisant partie de l’être machine, l’interpréteur est un acteur mixte qui va traduire un code informatique en actions. Il est un médiateur entre l’instruction et le milieu qui reçoit l’action. Cette plateforme est ouverte, tout du moins en partie, au sens où elle est sensible à l’information. Elle existe par les relations des éléments qui la composent et peut se transformer par sa marge d’indétermination (Simondon, 2012, pp.188-189).

La machine ouverte est à opposer à une machine fermée qui est un automate. Celui-ci ne dispose pas de récepteur ou de capteur d’information extérieure à son fonctionnement et ne peut donc pas se transformer : il ne peut que dysfonctionner, s’abîmer et donc s’arrêter de fonctionner. La plateforme GitLab et l’ensemble du projet de traduction constitue donc une machine ouverte dans la mesure où elle évolue avec de nouvelles informations et données en développant de nouvelles fonctionnalités et processus. L’information numérique à laquelle la machine est sensible diffère de l’information analogique considérée par Simondon à la naissance de l’informatique et de l’ordinateur. L’information numérique qui transforme la machine est intensive, concrète et complexe :

« L’information est alors ce qui permet au sujet de se situer dans le monde, dans la mesure où le monde n’est strictement ni un ensemble de signaux discrets ni un ensemble de structures données, mais ce qui a un sens pour un sujet. Et c’est en fonction de ce sens recherché que le sujet, dans le devenir de sa relation au monde, affectera un coefficient d’intensité à l’information reçue » (Duhem, 2013).

Pour paraphraser (Duhem, 2008, p.128, qui cite Simondon), le rapport entre le groupe de traduction et la plateforme Gitlab est « une invention perpétuée ». Ce qui réside dans la plateforme, c'est de la réalité humaine, le geste humain est fixé et cristallisé en structures qui fonctionnent. Ainsi, la plateforme GitLab reflète les valeurs du groupe : le partage des connaissances, la solidarité et la collaboration, la copie libre du contenu, l’accès facilité, l’association progressive et continue de contributeur⋅rices, le choix d’une version inclusive de la langue française. De plus, parce qu’elle permet des mises en relations productives, la plateforme devient le siège de processus d’individuation collective (Combes, 1999). Elle implique des transformations des différentes parties de la relation : du côté de la plateforme, de la traduction et de celui du groupe.

La traduction comme concrétisations

Traduire la documentation du CIDOC CRM semble une gageure. La complexité du texte dans son contexte de production, celle de la langue, ses idiomes ou références culturelles et philosophiques et celle de l’ontologie événementielle se conjuguent. Traduire un texte « intraduisible » (Ladjadj & Chiflet, 2015) suppose non seulement d’en connaître la genèse, les éléments de sa structure interne (cf. supra), mais également les usages. En revanche, cela nécessite aussi de disposer d’une capacité inventive pour faire converger les points de vue et obtenir un consensus au sein du collectif.

C’est l’acquisition d’une synergie fonctionnelle (c’est-à-dire la réalisation d’autres fonctions utiles à celles visées) et la dynamique du processus d’individuation associé qui conduisent à sa concrétisation dans son contexte de production (Simondon, 2012, pp.21-23). En reprenant l’illustration de l’argile, les gestes, les formes et matières utilisées dans leur contexte sont modifiées selon les modes d’utilisation de la brique, c’est-à-dire que la dynamique de sa fabrication évolue. Ce faisant, l’invention de nouvelles méthodes ou l’usage d’autres matières font émerger de nouvelles fonctionnalités pour la brique (isolation thermique ou sonore par exemple), ou de nouveaux objets sont inventés à partir du même matériau initial de mise en œuvre (céramique). En ce sens, la finalité de la page statique HTML est de publier la traduction finale sur le web. Toutefois, du fait de l’intégration continue de la plateforme, cette page web prend une autre fonction que la finalité initiale et devient une photographie instantanée de la traduction en cours (cf. 2.5). Cette synergie fonctionnelle contribue à concrétiser l’individu work in progress de la traduction du CIDOC CRM dans son contexte : le texte traduit s’individualise comme un objet technique numérique artisanal, il est une concrétisation interprétative de la version de la documentation CIDOC CRM traduite, il est unique. La plateforme numérique du projet devient une preuve de concept d’une machine numérique à traduire le CIDOC CRM, peu importe la langue choisie : elle se concrétise comme objet technique proto-industriel. Ces concrétisations sont autant de conséquences de l’adoption de la posture d’expérimentation.

La finalité de la traduction en français du CIDOC CRM suppose donc une autre vision que celle de la relation utilitaire à un environnement GitLab. Au-delà de leur « adaptation » ou « extension » au sens de Jenkins (Zacklad, 2012), les objets techniques numériques se co-construisent en même temps que la mise en œuvre du projet de traduction. La plateforme numérique comme machine est ouverte selon deux voies (Simondon, 2012, p.146). La première est celle de la relation de la machine aux éléments qui la compose. La seconde est celle des relations interindividuelles dans un ensemble technique plus vaste comprenant des appareils de visioconférence Rendez-Vous de Renater ou l’outil d’édition collaborative et simultanée, Etherpad de l’IN2P3 (Etherpad, s. d.) ou encore les éditeurs de texte vim ou emacs etc. Ces ramifications de la plateforme concrétisent un ensemble technique informationnel complexe.

À la différence du domaine du développement informatique, notre relation à la plateforme est pluridisciplinaire et non marchande (Alcaras, 2023). Il suppose un triple engagement (Bachimont, 2000):

• engagement sémantique (discuter du sens dans la traduction),
• engagement ontologique (partageant la logique formelle du projet et des outils),
• et engagement computationnel (adoptant une démarche d’expérimentation dans la relation aux outils numériques).

La contrainte technique de la relation à la plateforme est contrebalancée par la complémentarité des individus et le partage des connaissances, ce qui transforme les membres du groupe eux-mêmes. Le rapport à la technique fait partie intégrante du fonctionnement du groupe. La relation est collective et plurielle. Elle s’actualise dans la pratique où les membres changent de rôle dans la relation d’apprentissage. La technique n’est donc pas vecteur d’un rapport de pouvoir (Treleani, 2016). Le concept d’individuation ne concerne pas seulement l’objet technique numérique, mais comme dans le cas de la relation à la plateforme, il est aussi psycho-cognitif. Le collectif se co-constitue alors comme transindividualité par sa propre genèse et la dynamique des flux sémiotiques échangés ou générés (Duhem, 2013).

L’ouverture de la plateforme et des modalités de la relation productive permet en retour une désaliénation à la technique elle-même. La bienveillance collective envers la plateforme et au sein du groupe permet d’éviter deux écueils : la méfiance (dans le sens d’un contrôle de la traçabilité) et le sentiment d’incompétence (l’étrangeté de la technique ou syndrome de l’imposteur imposter syndrom) vis-à-vis de la plateforme et de la technique.

Relation humain-machine

Selon Simondon, de la même manière que l’argile est façonnée avant son individuation physique, les objets techniques numériques sont créés par opérations successives au moyen de commandes. La commande consiste à exécuter une ou plusieurs lignes de code, ce que réalise l’interpréteur (cf. supra) : ce sont les transducteurs (Grosman, 2016, p. 250) numériques ou computationnels. Ils sont la relation opératoire entre l’humain et la machine numérique. Dans le cas de la traduction, la demi-chaîne opératoire de la « matière » (le texte anglais structuré) produit un ensemble de fichiers markdown. Organisé au sein de la structure du dépôt du GitLab, il est issu de transformations successives du document de référence (Figure 7a). À leur échelle, les fichiers markdown sont des objets techniques numériques (cf. supra) puisqu’ils résultent de la rencontre d’un texte brut et d’une forme syntaxique particulière traduisant la sémantique de l’ontologie. Cette matière va ensuite être manipulée et transformée de manière empirique (éditée, discutée, complétée, documentée, étiquetée, validée etc.) et computationnelle (corrigée, transcrite, agrégée puis mise en forme par intégration continue). Comme le montre la figure 7b, ce geste technique noue la première demi-chaîne opératoire à la seconde.

Au fur et à mesure de la traduction, un code commun émerge du processus de mise en relation à la plateforme. Cette invention (Simondon toujours) rend concrète la traduction et incarne simultanément le double processus d'individuation de la traduction et de la plateforme. Ce code commun est l’un des creusets où est déposée l’information produite par la relation opératoire de traduction. Un autre fichier opère un processus de transformation sur le texte : c'est un fichier composé d’un dictionnaire syntaxique des occurrences de formes d’intitulés du texte qui permet d’homogénéiser les intitulés dans l’ensemble des fichiers markdown (Doc fr CIDOC CRM  ·  translate  · GitLab  ·  Dictionnaire syntaxique des occurrences de formes d’intitulés du texte, 2023). Un troisième exemple de concrétisation s’effectue au moment de la fabrication des hyperliens (ancres de la transcription en HTML). La synergie fonctionnelle du texte-code est enrichie par ce mécanisme : il est possible de naviguer au sein de la page en cliquant sur les entités ou propriétés.

Figure 7a : demi chaîne opératoire de transformation du document initial (au format .docx) en code commun.

Figure 7b : demi-chaîne opératoire de rencontre entre la matière et la forme : la traduction. Les informations sont transcrites dans le code commun de la traduction de plusieurs façons : par la relation à la plateforme GitLab (boutons éditer, valider), puis par les instructions de transformations réalisées par les transducteurs (la commande Git et son interprétation, les étapes du .gitlab-ci.yml et le job de l’intégration continue).

La traduction du CIDOC CRM n’exclut pas d’autres méthodologies et types d’organisations (cf. supra). Par exemple, le projet en cours de traduction en français canadien du CIDOC CRM utilise la plateforme Github, à ce stade non pour le flux de traduction, mais pour déployer un site internet statique à partir de Github Pages. À la différence de cette initiative, la posture d’expérimentation que notre groupe a adoptée dans ce projet est techniciste (au sens de Simondon) et pas purement utilitaire. Elle a un double effet de sérendipité : d’une part, elle permet l’émergence d’un code commun via celle du processus inventif. D’autre part, la relation à la plateforme produit une preuve du concept de la plateforme concrète (Grosman, 2016, p. 253), qui continue à grandir. Le nombre de commits en 2022 a triplé par rapport à 2021 (489 en 2022, 153 en 2021) avec 16 contributeur⋅rices actif⋅ves (ayant effectué au moins un commit). Le nombre d’issues ouvertes en 2023 est 202, 70 ont été fermées (traduction validée). Autrement dit, elle devient une machine ouverte à traduire le CIDOC CRM. Cerise sur le gâteau, il est en plus possible de partager librement la méthodologie et le flux de travail pour d’autres initiatives de traduction. Ces gains inattendus, qui s’expliquent par les mécanismes d’amplification associés aux processus transductifs tels que décrits dans la philosophie de la technique de Simondon, comblent les exigences du collectif de traduction en termes de valeurs et de sens conférés à leur travail. Ils et elles ne sont plus de simples opérateur⋅rices, mais bien des partenaires à part entière d’un processus enrichissant où la technique elle-même participe de la valeur d’être de la relation. Cette logique de transformation appelle à la participation d’une diversité et pluralité de la francophonie dans le collectif.

Bien plus encore, le choix du HTML statique, qui pourrait sembler désuet, répond en réalité à une triple exigence : la performance technique, la sobriété énergétique et le respect de la richesse culturelle de la francophonie. Elle est la conséquence de notre choix de « solidarité technique » qui conduit à une désaliénation mutuelle. En effet, notre posture d’expérimentation semble une volonté de répondre à (Simondon, 2012, p. 138) quand il écrit : « L’homme comprend les machines; il a une fonction à jouer entre les machines plutôt qu’au-dessus des machines, pour qu’il puisse y avoir un véritable ensemble technique. C’est l’homme qui découvre les significations : la signification est le sens que prend un événement par rapport à des formes qui existent déjà; la signification est ce qui fait qu’un événement a valeur d’information. »

Il faut donc considérer que notre projet comporte trois dimensions transformantes. La première remet en cause les dépendances hiérarchiques traditionnelles entre humains et entre humains et machines. La deuxième exploite les qualités d’incompétence des partenaires (dont les machines et le CIDOC CRM) en les poussant au dialogue mutuel. Enfin, le troisième changement renouvelle et assouplit l’agencement des rapports entre usagers, prescripteur⋅rices, producteur⋅rices et production. En cela, nous pouvons affirmer que nous avons bâti une « organisation distribuée » au sens de (Dodier & Barbot, 2016).

Conclusion

Pour conclure, nous pensons avoir montré que le projet de traduction collaborative du CIDOC CRM en français (Doc Fr CIDOC CRM · GitLab, s. d.) est une expérimentation avec la plateforme de versionnement GitLab. Le rapport à la plateforme numérique nous a amené⋅es à repenser ce qu’est une traduction et comment être auteurs et autrices collectivement. Les termes d’auteur⋅rices et de contributeur⋅rices deviennent interchangeables puisqu’il s’agit à la fois de la traduction en tant que texte et code. Ce processus est donc créatif, collectif et ancré dans les humanités et la technique numériques. Le projet est parti d’un moment d’apprentissage et de partage de connaissances. Il continue à s’amplifier et se ramifier comme pratique professionnelle dans le contexte de la révolution numérique. L’écriture collective de cet article est une résolution de la tension entre la technicité et la finalité (Feenberg, 2016, p.323) de l’ensemble technique informationnel que l’on constitue avec la plateforme numérique. Elle répond également à des attentes plus traditionnelles du monde académique.

La plateforme GitLab et les projets qu’elle héberge sont des individus techniques numériques complexes pensés dans la continuité théorique de Gilbert Simondon. La relation à la plateforme dépasse son aspect productif. Par le processus de transindividuation et les mécanismes de transduction, la communauté s’agrège autour de la plateforme. Elle s’actualise dans le performatif du travail scientifique collaboratif au sein d’espaces académiques ouverts et protégés. La visibilité du projet sur GitLab dès le départ a permis aux individus l'accès à la documentation et assure pérennité et résilience à l’initiative. L’expérience en relation à la plateforme est source d’autres relations à la culture et à la technique comme ensemble indissociable. Cela illustre un champ des possibles en termes de dispositif académique non marchand et non institutionnalisé d’une plateforme numérique, ici, pour traduire la documentation d’une méthode de représentation formelle du monde, le CIDOC CRM.

Bibliographie

Alcaras, G. (2023). L’informatique sous contrôle : Enjeux marchands et professionnels de l’écriture collective des codes. Séminaire du CIS #30, Centre Internet et Société. https://cis.cnrs.fr/sem-cis-30-gabriel-alcaras/

Anderson, D. (1978). IFLA’s Programme of ISBDs : (International Standard Bibliographic Descriptions). IFLA Journal, 4(1), 26‑33. https://doi.org/10.1177/034003527800400106

Azéma, C. (2022). Les outils-transducteurs dans les traductions du designer. Appareil, 24, Art. 24. https://doi.org/10.4000/appareil.4399

Bachimont, B. (2000). Engagement sémantique et engagement ontologique : Conception et réalisation d’ontologies en Ingénierie des connaissances. In Ingénierie des connaissances : Évolutions récentes et nouveaux défis. Eyrolles.

Bachimont, B. (2007). Ingénierie des connaissances et des contenus : Le numérique entre ontologies et documents. Hermès Science : Lavoisier.

Barthélémy, J.-H. (2014). Simondon, ou le symptôme d’une époque. Chronique d’une redécouverte. Hermes, La Revue, n° 70(3), 191-196.

Barthélémy, J.-H. (2015). Glossaire Simondon : Les 50 grandes entrées dans l’œuvre. Appareil, 16, Art. 16. https://doi.org/10.4000/appareil.2253

Bazet, I., Hémont, F., & Mayère, A. (2017). Entretien avec Yves Jeanneret. Communication. Information médias théories pratiques, vol. 34/2, Article 34/2. https://doi.org/10.4000/communication.7287

Bekiari, C., Bruseker, G., Canning, E., Doerr, M., Michon, P., Ore, C.-E., Stead, S., & Velios, A. (2022). Volume A : Definition of the CIDOC Conceptual Reference Model. CIDOC CRM Special Interest Group. https://www.cidoc-crm.org/sites/default/files/cidoc_crm_version_7.1.2.pdf

Binda, E. (2015). Techno-esthétiques ou philosophies de l’interaction : Les réflexions de Gilbert Simondon et John Dewey. Appareil, 16, Art. 16. https://doi.org/10.4000/appareil.2217

Bontems, V. (Éd.). (2016). Gilbert Simondon, ou, L’invention du futur : Actes de la décade des 5-15 août 2013 du Centre culturel international de Cerisy-la-Salle. Klincksieck.

Bourlet, C., Fossier, L., Genet, J.-P., Klapisch-Zuber, C., Lefort, J., Metman, J., & Zarri, G. P. (1979). Editorial. Le médiéviste et l’ordinateur, 1(1), 1-2.

Calvanese, D., Cogrel, B., Komla-Ebri, S., Lanti, D., Rezk, M., & Xiao, G. (2015). How to Stay Ontop of Your Data : Databases, Ontologies and More. In F. Gandon, C. Guéret, S. Villata, J. Breslin, C. Faron-Zucker, & A. Zimmermann (Éds.), The Semantic Web : ESWC 2015 Satellite Events (Vol. 9341, p. 20-25). Springer International Publishing. https://doi.org/10.1007/978-3-319-25639-9_4

Combes, M. (1999). Simondon individu et collectivité : Pour une philosophie du transindividuel. Presses universitaires de France.

Crofts, N. (2007). La norme récente ISO 21127 : Une ontologie de référence pour l’échange d’infomations de patrimoine culturel. Systèmes d’informations et synergies entre musées, archives, bibliothèques universités, radios et télévisions. Les bases de données et les médias numériques au service des patrimoines historique, culturel, naturel et scientifique, 17-22. https://www.museums.ch/fr/assets/files/dossiers_f/Publikationen/Documentation%20informatique%202007%20web.pdf

Croft, N., Doerr, M., Gill, T., Stead, S., & Stiff, M. (2011). Definition of the CIDOC Conceptual Reference Model. Produced by the ICOM/CIDOC Documentation Standards Group, Continued by the CIDOC CRM Special Interest Group. Version 5.0.4. November 2011. http://old.cidoc-crm.org/docs/cidoc_crm_version_3.3.2.pdf

Dacos, M. (2010). Manifeste des Digital humanities [Hypothese.org]. THATCamp Paris. https://tcp.hypotheses.org/318

David-Jacquot, B. (2021). Manipulation de chaîne de caractères avec les REGEX (expressions rationnelles). https://touticphoto.fr/developpement/12-manipulation-de-chaine-de-carateres-avec-les-regex-expressions-rationnelles

Doc fr CIDOC CRM  ·  translate  · GitLab  ·  Dictionnaire syntaxique des occurrences de formes d’intitulés du texte. (s. d.). Consulté 1 mars 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/blob/translate/utils/toc-title-with-underscore-and-grave.sed

Doc fr CIDOC CRM  ·  translate  · GitLab  ·  .gitlab-ci.yml. (s. d.). Consulté 28 février 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/blob/translate/.gitlab-ci.yml

Debray, R. (2001). Cours de médiologie générale / Régis Debray (Réédition, avec une nouvelle postface). Gallimard.

Development · Boards · Doc fr CIDOC CRM · GitLab. (s. d.). GitLab. Consulté 4 janvier 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/boards

Doc fr CIDOC CRM · GitLab. (s. d.). Consulté 26 février 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm

Dodier, N. (1995). Les Hommes et les Machines. Editions Métailié. https://doi.org/10.3917/meta.dodie.1995.01

Dodier, N., & Barbot, J. (2016). La force des dispositifs. Annales. Histoire, Sciences Sociales, 71e année(2), 421-450.

Duhem, L. (2008) L'être préindividuel de l'œuvre d'art : Simondon et le problème de l'esthétique, thèse, université de Lille 3

Duhem, L. (2013). Penser le numérique avec Simondon (Thinking the digital with Simondon). https://www.ludovicduhem.com/. https://www.ludovicduhem.com/_files/ugd/8bc434_276e3c0ec30d41849d8a96203a3df747.pdf

E10 Transfer of Custody (#87) · Issues · Doc fr CIDOC CRM · GitLab. (s. d.). GitLab. Consulté 4 janvier 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/issues/87

Etherpad. (s. d.). Consulté 4 janvier 2023, à l’adresse https://etherpad.in2p3.fr/

Feenberg, A. (2016). Concrétiser Simondon et le constructivisme. Une contribution récursive à la théorie de la concrétisation. In V. Bontems (Éd.), Actes de la décade des 5-15 août 2013 du Centre culturel international de Cerisy-la-Salle (p. 317-329). Klincksieck. https://www.academia.edu/34457056/Simondon_et_linformatique

Gavillet, I. (2010). Chapitre 2. Michel Foucault et le dispositif : Questions sur l’usage galvaudé d’un concept. In Les dispositifs d’information et de communication (p. 17-38). De Boeck Supérieur. https://doi.org/10.3917/dbu.masso.2010.01.0017

Gillespie, T. (2017, août 24). The Platform Metaphor, Revisited – Digital Society Blog. HIIG. https://www.hiig.de/en/the-platform-metaphor-revisited/

Gorman, M. (1978). International Standard Bibliographical Description and the new ISBDs. Journal of Librarianship, 10(2), 131‑137. https://doi.org/10.1177/096100067801000205

Gorman, M. (2014). The Origins and Making of the ISBD : A Personal History, 1966–1978. Cataloging & Classification Quarterly, 52(8), 821‑834. https://doi.org/10.1080/01639374.2014.929604

Grosman, J. (2016). Simondon et l’informatique II. In V. Bontems (Éd.), Actes de la décade des 5-15 août 2013 du Centre culturel international de Cerisy-la-Salle (p. 247-254). Klincksieck. https://www.academia.edu/34457056/Simondon_et_linformatique

Guarino, N. (1998). Formal ontology in information systems : Proceedings of the First International Conference (FOIS’98), June 6-8, Trento, Italy. IOS Press. http://digitale-objekte.hbz-nrw.de/storage/2007/05/31/file_14/1916697.pdf

Guillem, A., & Bruseker, G. (2017). THE CIDOC CRM GAME : A Serious Game Approach to Ontology Learning. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, XLII-2/W5, 317-323. https://doi.org/10.5194/isprs-archives-XLII-2-W5-317-2017

Home | CIDOC CRM. (s. d.). Home | CIDOC CRM. http://www.cidoc-crm.org/

Home · Wiki · Doc fr CIDOC CRM · GitLab. (s. d.). GitLab. Consulté 2 janvier 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/wikis/home

Hui, Y. (2015). Induction, Deduction and Transduction : On the Aesthetics and Logic of Digital Objects. Networking Knowledge: Journal of the MeCCSA Postgraduate Network, 8(3). https://www.academia.edu/12788303/Induction_Deduction_and_Transduction_On_the_Aesthetics_and_Logic_of_Digital_Objects

Ladjadj, H., & Chiflet, J.-L. (2015). Vous voulez rire ? C’est intraduisible…: Propos recueillis par Hélène Ladjadj. Traduire, 232, 22-26. https://doi.org/10.4000/traduire.690

Le Boeuf, P. (2013). Le modèle conceptuel de référence du CIDOC : De la sémantique des inventaires aux musées en dialogue. Culture & musées, 22(1), 89-111.

Manifeste pour le développement Agile de logiciels. (s. d.). Consulté 16 janvier 2023, à l’adresse https://agilemanifesto.org/iso/fr/manifesto.html

Marketakis, Y., Minadakis, N., Kondylakis, H., Konsolaki, K., Samaritakis, G., Theodoridou, M., Flouris, G., & Doerr, M. (2017). X3ML mapping framework for information integration in cultural heritage and beyond. International Journal on Digital Libraries, 18(4), 301-319. https://doi.org/10.1007/s00799-016-0179-1

Organisation internationale de normalisation (Éd.). (2014). ISO 21127:2014. https://www.iso.org/fr/standard/57832.html

OWL - semantic web standards. (s. d.). W3C. https://www.w3.org/OWL/

Paquienséguy, F. (2017). Manifeste pour un positionnement des Sciences de l’Information Communication (SIC) vis-à-vis des Digital Studies (DS) et autres mutations du Numérique. Revue française des sciences de l’information et de la communication, 10, Art. 10. https://journals.openedition.org/rfsic/2630

Préparation des fichiers à traduire (#8) · Issues · Doc fr CIDOC CRM · GitLab. (s. d.). GitLab. Consulté 2 janvier 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/issues/8

RDF - semantic web standards. (s. d.). W3C. https://www.w3.org/RDF/

README.md · translate · Doc fr CIDOC CRM · GitLab. (s. d.). GitLab. Consulté 2 janvier 2023, à l’adresse https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/blob/translate/README.md

Riva, P., Le Bœuf, P., & Žumer, M. (2017). IFLA Library Reference Model : A conceptual model for bibliographic information. IFLA. https://www.ifla.org/publications/node/11412

Simondon, G. (2005). L’individuation à la lumière des notions de forme et d’information. Millon. http://catalogue.bnf.fr/ark:/12148/cb400814710

Simondon, G. (2012). Du mode d’existence des objets techniques (Nouv. éd. rev. et corr). Aubier.

Symfony. (s. d.). Contributing to the Documentation (Symfony Docs). Consulté 2 janvier 2023, à l’adresse https://symfony.com/doc/current/contributing/documentation/overview.html

Szabados, A.-V., Briatte, K., & Letricot, R. (2012). Utiliser l’ontologie CIDOC CRM pour l’information relative au patrimoine culturel. THATCamp Paris 2012 Non-actes de la non-conférence des humanités numériques, 1-13. https://doi.org/10.4000/books.editionsmsh.319

Treleani, M. (2016). Yves Jeanneret, Critique de la trivialité.Les médiations de la communication, enjeu de pouvoir,Paris, Editions Non Standard, 2014, 784 pages. Actes Sémiotiques, 119, 1-4.

University of California. (2008, 15 décembre). A Digital Humanities Manifesto. [Collaborative Document produced by the Mellon Seminar on the Digital Humanities]. https://web.archive.org/web/20090118054545/http://dev.cdh.ucla.edu/digitalhumanities/2008/12/15/digital-humanities-manifesto/

University of California. (2009, 29 mai). The Digital Humanities Manifesto 2.0. [Collaborative Document produced by the Mellon Seminar on the Digital Humanities]. https://web.archive.org/web/20090614071215/http://dev.cdh.ucla.edu/digitalhumanities/2009/05/29/the-digital-humanities-manifesto-20

Vitali-Rosati, M. (2020). Pour une théorie de l’éditorialisation. Humanités numériques, 1. https://doi.org/10.4000/revuehn.371

Vitali-Rosati, Marcello. (2016). Qu’est-ce que l’éditorialisation? Sens Public. http://sens-public.org/articles/1184/

Wilkinson, M. D., Dumontier, M., Aalbersberg, Ij. J., Appleton, G., Axton, M., Baak, A., Blomberg, N., Boiten, J.-W., da Silva Santos, L. B., Bourne, P. E., Bouwman, J., Brookes, A. J., Clark, T., Crosas, M., Dillo, I., Dumon, O., Edmunds, S., Evelo, C. T., Finkers, R., … Mons, B. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3(1), Art. 1. https://doi.org/10.1038/sdata.2016.18

YAGNI. (2022). In Wikipédia. https://fr.wikipedia.org/w/index.php?title=YAGNI&oldid=193388758

Zacklad, M. (2012). Organisation et architecture des connaissances dans un contexte de transmédia documentaire : Les enjeux de la pervasivité. Études de communication. langages, information, médiations, 39, Art. 39. https://doi.org/10.4000/edc.4017