<p align="justify"><span style="background-color:#ffffff;">This article presents a project of collaborative translation into French of the English documentation of the CIDOC Conceptual Reference Model (CIDOC CRM) version 7.1.2. The project uses the distributed management software Git and the GitLab environment. The translation work is based on the versioning of the text in </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;">, the production of statistics on the whole project and its documentation through functionalities such as </span><i><span style="background-color:#ffffff;">issues, milestones</span></i><span style="background-color:#ffffff;"> and </span><i><span style="background-color:#ffffff;">branches</span></i><span style="background-color:#ffffff;">. The project is designed as an experiment in digital humanities. The practice of the collective translation on the digital platform Gitlab opens a space for a reflection about the digital technical object in the tradition of the French philosopher Gilles Simondon. The genesis of the technical object happens through the individuation process. The relationship to the platform produces reproducible processes and reusable objects. The translation project builds a community of French-speaking researchers around values of open data, FAIR, and cooperation in the semantic web and cultural heritage.</span></p>

<h3><span style="background-color:#ffffff;">1-Introduction</span></h3>

<p align="justify"><span style="background-color:#ffffff;">Cet article esquisse une analyse d’un projet ouvert de traduction collaborative mobilisant le “geste simondonien” (Dodier, 1995 p. 9). Ce projet<i><span style="background-color:#ffffff;"> </span></i>(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 (<a href="https://cidoc-crm.org/Version/version-7.2.2">CIDOC CRM</a>) 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 le domaine du patrimoine culturel 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.</span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Au sein de la communauté scientifique française, le champ des humanités numériques émerge avec le manifeste de 2010 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Dacos, 2010)</span></span><span style="background-color:#ffffff;">. Avant cela, des précurseurs interrogent la place de l’ordinateur dans divers champs disciplinaires, par exemple les médiévistes (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Bourlet & al, 1979</span></span><span style="background-color:#ffffff;">) ou au sein de la sociologie de l’innovation (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Gavillet, 2010)</span></span><span style="background-color:#ffffff;"> ou encore les médiologues au début des années 1990 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Debray Régis, 2001</span></span><span style="background-color:#ffffff;">). En 2017, les sciences de l’information et de la communication dépassent le champ des humanités numériques (</span><i><span style="background-color:#ffffff;">digital humanities</span></i><span style="background-color:#ffffff;">) et se positionnent vis-à-vis des études numériques (</span><i><span style="background-color:#ffffff;">digital studies)</span></i><span style="background-color:#ffffff;"> (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Paquienséguy, 2017</span></span><span style="background-color:#ffffff;">). Ce n’est pas un hasard si les termes sont désormais en anglais, en effet, la discipline des humanités numériques </span><span style="background:#ffffff">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.</span><span style="background-color:#ffffff;"> L’enjeu de la traduction du CIDOC CRM est de leur permettre 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.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">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 le cadre de cette école, le CIDOC CRM est abordé par le biais de questions de transformation et de diffusion des données. Le jeu CIDOC CRM (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Guillem, Bruseker, 2017</span></span><span style="background-color:#ffffff;">) et des méthodes d’alignement sont utilisées avec les outils 3M </span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">(Marketakis et al. 2017) </span></span><span style="background-color:#ffffff;">et Ontop </span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">(Calvanese et al. 2015)</span></span><span style="background-color:#ffffff;">, 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 est de favoriser la coopération autour des technologies du web sémantique et des ontologies formelles. Un enjeu sous-jacent commun à la réalisation de ce double objectif 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 la 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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Riva, 2017</span></span><span style="background-color:#ffffff;">) adoptée par la Bibliothèque nationale de France (BnF).</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">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 (</span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">Croft, 2007 et Szabados et al. 2012)</span></span><span style="background-color:#ffffff;">. 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 </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">ISO 21127:2014</span></span><span style="background-color:#ffffff;">. Ces traductions ne sont pas librement accessibles. Comme tout document ISO, leur accès est payant. Le projet dans lequel nous nous sommes lancés en 2019 comptait initialement des membres canadiens qui, pour des raisons institutionnelles, développent dorénavant leur propre traduction.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Le CIDOC CRM est continuellement mis à jour par un </span><i><span style="background-color:#ffffff;">Special Interest Group</span></i><span style="background-color:#ffffff;"> (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.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">La complexité du texte à traduire </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">(Ladjadj & Chiflet, 2015)</span></span><span style="background-color:#ffffff;">, 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 neutralisation du genre) peuvent également accroître la complexité des choix pour la validation par consensus de la traduction collective en français.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background:#fff2cc"><span style="background-color:#ffffff;">Expliciter les données</span></span><span style="background-color:#ffffff;"> lors d’un appariement avec le CIDOC CRM a un effet performatif. Ce faisant, les chercheur⋅ses sont d’autant plus critiques sur la manière dont les données sont produites. Traduire l'ontologie formelle du CIDOC CRM permet aussi de remettre dans l’espace critique des choses qui semblent acquises. Plus généralement, il s’agit pour la communauté francophone d’appréhender la normativité (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Simondon, 2012, p.310</span></span><span style="background-color:#ffffff;">) de la technique de modélisation portée par la philosophie du CIDOC CRM. Les concepteur·ices du CIDOC l’ont qualifié d’ontologie “formelle” en adoptant la position de </span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">(Guarino 1998) </span></span><span style="background-color:#ffffff;">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 prévue des concepts nommés. Les questions éthiques et pratiques entraînent des ajustements du modèle de base du CIDOC CRM. 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.</span></span></p>

<p align="justify"><span style="background-color:#ffffff;">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 </span><i><span style="background-color:#ffffff;">a priori</span></i><span style="background-color:#ffffff;"> le terme de dispositif numérique<i><span style="background-color:#ffffff;"> </span></i>comme<i><span style="background-color:#ffffff;"> </span></i>une plateforme, au sens de l’approche critique de la métaphore de la plateforme (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Gillespie, 2017</span></span><span style="background-color:#ffffff;">) : 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. 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) </span><i><span style="background-color:#ffffff;">à</span></i><span style="background-color:#ffffff;"> et </span><i><span style="background-color:#ffffff;">par</span></i><span style="background-color:#ffffff;"> 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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Dodier, 1995, p.13</span></span><span style="background-color:#ffffff;">) ou informationnel (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Barthélémy, 2015, p.4</span></span><span style="background-color:#ffffff;">), 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 des concepts philosophiques 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 concepts, dans la continuité du geste simondonien, articulent la réalité de cette production avec d’autres dispositifs.</span></p>

<h3 class="western"><span style="background-color:#ffffff;">2-GitLab comme plateforme de travail du projet de traduction collaborative : méthodes, outils et processus</span></h3>

<h4 class="western"><span style="background-color:#ffffff;">2.1 La plateforme GitLab comme dispositif technique et informationnel pour le projet collaboratif de traduction</span></h4>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><span style="background-color:#ffffff;">Le projet de traduction collective se développe comme une expérimentation (</span><span style="background:#c27ba0"><span style="background-color:#ffffff;">Gavillet, 2010</span></span><span style="background-color:#ffffff;">) en humanités numériques. 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⋅trices, des principes FAIR (Findable, Accessible, Interoperable, Reusable) </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">(Wilkinson et al., 2016)</span></span><span style="background-color:#ffffff;">. Le logiciel Git et l’environnement GitLab sont notamment utilisés pour le contrôle de versions de travaux, documentations, éditions et le développement de programmes informatiques.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Il s’agit dans cette partie de décrire 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. Comment créer un flux de travail numérique qui permette le 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 et sa documentation (comptes-rendus de réunion, choix de traduction, etc.). 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. Dans la suite de l’article, l’usage des termes plateforme, interface, GitLab seront indifféremment utilisés. Le collectif s'appuie sur les fonctionnalités de la plateforme GitLab pour versionner la traduction et la documentation associée. La création de tickets (</span><i><span style="background-color:#ffffff;">issues</span></i><span style="background-color:#ffffff;">) permet de documenter le processus de traduction mobilisant le langage </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> (2.2). La définition du tableau de bord (</span><i><span style="background-color:#ffffff;">boards) </span></i><span style="background-color:#ffffff;">permet de suivre l'avancée du travail de traduction et de validation (2.3). Des </span><i><span style="background-color:#ffffff;">branches</span></i><span style="background-color:#ffffff;"> scindent les alternatives de versions de documents (2.4) et des jalons (</span><i><span style="background-color:#ffffff;">milestones</span></i><span style="background-color:#ffffff;">) 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 (2.5).</span></span></p>

<h4 class="western"><span style="background-color:#ffffff;">2.2 Fichiers, dépôt et tickets (</span><i><span style="background-color:#ffffff;">issues</span></i><span style="background-color:#ffffff;">) dans la plateforme GitLab et projet de traduction</span></h4>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><span style="background-color:#ffffff;">Git et GitLab apportent les mêmes principes de versionnement, mais l’environnement GitLab y ajoute 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 (</span><i><span style="background-color:#ffffff;">GitLab runner</span></i><span style="background-color:#ffffff;">). Le </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;"> typique de Git implique des actions pour : (a) dupliquer localement les fichiers du serveur distant (</span><i><span style="background-color:#ffffff;">git clone, git pull</span></i><span style="background-color:#ffffff;">), avant de (b) réaliser des modifications de manière asynchrone, puis de mettre à jour l’historique des changements (c) </span><i><span style="background-color:#ffffff;">git commit,</span></i><span style="background-color:#ffffff;"> et permettre le versement des modifications (d) </span><i><span style="background-color:#ffffff;">git push,</span></i><span style="background-color:#ffffff;"> à la prochaine connexion avec le serveur.</span></span></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><span style="background-color:#ffffff;">GitLab est une application serveur qui centralise les fichiers et sert d’interface web pour le projet. La plupart des contributeur⋅rices peut ainsi modifier les fichiers via l’interface GitLab sans connaître ses mécanismes sous-jacents. Avec GitLab, le </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;"> est simplifié, les étapes de synchronisation avec le serveur (a) et (d) sont supprimées par l’accès à la plateforme. Il est possible de travailler avec les </span><i><span style="background-color:#ffffff;">merge requests</span></i><span style="background-color:#ffffff;">,<i><span style="background-color:#ffffff;"> </span></i>mais, outre la difficulté technique, ceux-ci impliquent généralement la validation des modifications par un chef de projet, contrairement à la volonté du groupe d’avoir un processus de validation collégiale. La proposition de traduction reste “un brouillon” support du débat lors de la séance de validation.</span></span></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><span style="background-color:#ffffff;">Le groupe de traduction n’est pas homogène dans sa capacité à utiliser toutes les subtilités de la plateforme GitLab. Les utilisateur⋅trices les plus aguerri⋅es ont un rôle de formation et de soutien pour les plus novices. Il n’est pas nécessaire d’être un expert de Git pour utiliser les services de la plateforme GitLab. Un fichier README (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;"><a href="https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/blob/translate/README.md">README.md</a> Doc Fr CIDOC CRM · GitLab, 2023</span></span><span style="background-color:#ffffff;">) présente le projet de traduction. Un Wiki (</span><a href="https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/wikis/home"><span style="background:#ead1dc"><span style="background-color:#ffffff;">Home · Wiki</span></span></a><span style="background-color:#ffffff;"><a href="https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/wikis/home">)</a>, intégré à GitLab, donne accès aux comptes rendus des principales réunions et à un tutoriel pas-à-pas expliquant comment participer aux traductions. 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.</span></span></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><span style="background-color:#ffffff;">Dans le cas usuel d’un projet de développement informatique, le dépôt (</span><i><span style="background-color:#ffffff;">repository</span></i><span style="background-color:#ffffff;">) permet d’entreposer des fichiers de code informatique exprimés dans un langage (php, java, C etc). Pour le projet de traduction collaborative, le dépôt permet d’archiver non pas du code informatique, mais le texte, les tables et les figures du CIDOC CRM à traduire. Le document de référence au format MS-Word (extension .docx) est découpé en fragments de manière partiellement automatisée avec l’application d’expressions rationnelles (</span><i><span style="background-color:#ffffff;">regex</span></i><span style="background-color:#ffffff;">) (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Préparation Des Fichiers à Traduire (#8), 2020; David-Jacquot, 2021</span></span><span style="background-color:#ffffff;">). Les fichiers sont alors organisés par grands types dans le dépôt : (a) les textes introductifs, la définition (b) des entités, (c) des propriétés, (d) les figures et (e) les tables. Ainsi, chaque fichier transformé au format </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> (extension .md) correspond à une portion de texte ou un élément à traduire. Bien que l’environnement GitLab ait été développé pour héberger des projets de développement informatique, celui-ci permet au groupe de traducteur⋅trices un accès ouvert à toute la documentation du projet, un suivi de son avancée et une documentation des choix de traductions.</span></span></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><span style="background-color:#ffffff;">L’utilisation de la plateforme numérique rend possible un processus itératif et collaboratif de traduction et de validation. Pour être le plus ouvert possible aux contributions de la communauté, le groupe de traduction a choisi un système ouvert, documenté et accessible, outillé par les services de versionnement du logiciel GitLab. Chaque élément à traduire entre dans le flux de traduction à la création d’un ticket (</span><i><span style="background-color:#ffffff;">issue</span></i><span style="background-color:#ffffff;">). Celui-ci assure la documentation et le suivi du processus de traduction. Il peut être assigné à un⋅e ou plusieurs contributeur⋅trices au cours du projet.</span></span></p>

<h4 class="western"><span style="background-color:#ffffff;">2.3 Tickets et tableau de bord : </span><i><span style="background-color:#ffffff;">workflows</span></i><span style="background-color:#ffffff;"> de traduction et de validation</span></h4>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">L’utilisation de la fonctionnalité du ticket (</span><i><span style="background-color:#ffffff;">issue</span></i><span style="background-color:#ffffff;">) est proche de celle d’un guichet pour mettre à l’ordre du jour un problème ou une question afin de la résoudre, le cas échéant, collectivement. Traditionnellement, les tickets (</span><i><span style="background-color:#ffffff;">issues</span></i><span style="background-color:#ffffff;">) 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 ses auteur⋅trices et les personnes 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 des tickets pour chaque élément de traduction mis en chantier pour le groupe. Cela permet un suivi en temps réel et documente l'avancée du travail de traduction d’un élément. Le second avantage est de dissocier le travail de traduction lui-même (dans les fichiers du dépôt) avec la documentation qui est produite lors de la traduction, c'est-à-dire les notes de traduction, les remarques sur le texte en anglais (erreurs typographiques, exemples, bibliographie), la restitution des discussions en lien avec la traduction. De cette façon, la documentation (dans les tickets) du projet de traduction est clairement identifiée et séparée de la traduction.</span></span></p>

<p align="justify" style="margin-bottom:16px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205224-2.png" style="width: 600px; height: 267px;" /></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><font style="font-size:9pt"><font size="2"><span style="background:#d9ead3"><span style="background-color:#ffffff;">Figure 1 </span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">: Avancée des tickets (Issues) dans les workflows de traduction et de validation des traductions utilisant les tableaux de bord (Boards) et les labels dans la plateforme GitLab pour le suivi du projet.</span></font></font></span></p>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">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 (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">). Il permet l’organisation des tickets et leur manipulation (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Development · Boards, 2023</span></span><span style="background-color:#ffffff;">) pour la gestion d'un double </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;"> (</span><span style="background:#d9ead3"><span style="background-color:#ffffff;">figure 1</span></span><span style="background-color:#ffffff;">). La définition des étapes des </span><i><span style="background-color:#ffffff;">workflows</span></i><span style="background-color:#ffffff;"> de traduction et de validation sont discutées puis choisies par le groupe collectivement.</span></span></p>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">Les étapes de traduction sont :</span></span></p>

<ol>
	<li align="justify"><span style="line-height:100%"><i><span style="background-color:#ffffff;">À traduire </span></i><span style="background-color:#ffffff;">: l'élément à traduire entre dans le flux de travail selon les priorités définies par le groupe.</span></span></li>
	<li align="justify"><span style="line-height:100%"><i><span style="background-color:#ffffff;">En cours de traduction</span></i><span style="background-color:#ffffff;"> : un 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.</span></span></li>
	<li align="justify"><span style="line-height:100%"><i><span style="background-color:#ffffff;">Traduit en attente de révision </span></i><span style="background-color:#ffffff;">: l'élément a été traduit par un ou plusieurs contributeur·rices, il est prêt à être discuté au sein du groupe en vue de la validation de sa traduction.</span></span></li>
</ol>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">Les étapes de validation commencent à partir de l'étape 3 du </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;"> de traduction :</span></span></p>

<ol start="3">
	<li align="justify"><span style="line-height:100%"><i><span style="background-color:#ffffff;">Traduit en attente de révision</span></i><span style="background-color:#ffffff;"> : il s’agit de l'étape charnière, le passage entre le flux individuel de traduction et celui, collectif, de validation.</span></span></li>
	<li align="justify"><span style="line-height:100%"><i><span style="background-color:#ffffff;">En cours de révision</span></i><span style="background-color:#ffffff;"> : lors des séances de validation, la proposition de traduction de l’élément est discutée collectivement. Sa cohérence sémantique et syntaxique est vérifiée. Le groupe produit ainsi collaborativement une traduction qui fait consensus. Après l'étape de révision, le résultat de la traduction est une production collective et non individuelle.</span></span></li>
	<li align="justify"><span style="line-height:100%"><i><span style="background-color:#ffffff;">Validé</span></i><span style="background-color:#ffffff;"> : la validation de la traduction est terminée. Le ticket est alors marqué validé par ce label puis clos (</span><i><span style="background-color:#ffffff;">closed</span></i><span style="background-color:#ffffff;">), ce qui intervient sur l’avancement des jalons (</span><i><span style="background-color:#ffffff;">milestones</span></i><span style="background-color:#ffffff;">) (2.5).</span></span></li>
</ol>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Les </span><i><span style="background-color:#ffffff;">workflows</span></i><span style="background-color:#ffffff;"> de traduction et de révision sont matérialisés par le tableau de bord (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">). Les tickets associés à un élément à traduire sont déplacés par un glisser-déposer d’une colonne à l'autre (</span><span style="background:#b6d7a8"><span style="background-color:#ffffff;">figure 2b</span></span><span style="background-color:#ffffff;">) au fur et à mesure de son avancée dans le </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;">. Le groupe de projet produit ainsi une visualisation de l'état d'avancement de traduction pour chaque élément. Cette vision d’ensemble et partagée du projet au moyen du tableau de bord permet la cohérence dans la mise en œuvre de la traduction individuelle asynchrone avec la révision/validation qui est synchrone et collective.</span></span></p>

<p align="justify" style="margin-bottom:11px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205258-3.png" style="width: 600px; height: 48px;" /></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><font style="font-size:9pt"><font size="2"><span style="background:#b6d7a8"><span style="background-color:#ffffff;">Figure 2a </span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">: exemple de changement d'étiquette (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">label</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">) pour le ticket (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">issue</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">) #87 pour l’entité E10 Transfer of custody (</span></font></font><font style="font-size:9pt"><font size="2"><span style="background:#ead1dc"><span style="background-color:#ffffff;">E10 Transfer of Custody (#87</span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">)).</span></font></font></span></p>

<p align="justify" style="margin-bottom:11px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205309-4.png" style="width: 600px; height: 287px;" /></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><font style="font-size:9pt"><font size="2"><span style="background:#b6d7a8"><span style="background-color:#ffffff;">Figure 2b </span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">: exemple de changement dans le tableau de bord (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">board</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">) du ticket (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">issue</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">) #82 pour l'entité E30 Rights (</span></font></font><font style="font-size:9pt"><font size="2"><span style="background:#ead1dc"><span style="background-color:#ffffff;">E30 Rights (#82</span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">)).</span></font></font></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Rappelons ici que pour matérialiser le passage d’une étape du </span><i><span style="background-color:#ffffff;">workflow </span></i><span style="background-color:#ffffff;">à une autre (par exemple de “à traduire” à “en cours de traduction”), le ticket (</span><i><span style="background-color:#ffffff;">issue</span></i><span style="background-color:#ffffff;">) est déplacé d’un tableau de bord (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">) à l'autre. Cela a pour conséquence, à l’échelle du ticket, d’assigner une étiquette (</span><i><span style="background-color:#ffffff;">label</span></i><span style="background-color:#ffffff;">) 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éé (</span><span style="background:#d9ead3"><span style="background-color:#ffffff;">figure 2a</span></span><span style="background-color:#ffffff;">). Les étiquettes (</span><i><span style="background-color:#ffffff;">labels</span></i><span style="background-color:#ffffff;">) permettent ainsi une double relation à la plateforme. Les tickets tracent l’état d’avancement de traduction d’un élément spécifique à l’échelle du ticket (</span><i><span style="background-color:#ffffff;">issue</span></i><span style="background-color:#ffffff;">) (figure 2a), tandis que le tableau de bord (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">) présente l’avancée globale du projet de traduction (</span><span style="background:#b6d7a8"><span style="background-color:#ffffff;">figure 2b</span></span><span style="background-color:#ffffff;">) à l’échelle du </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;">. À ces deux échelles, la relation à la plateforme diffère par la nature du processus de production en jeu. À l’échelle fine du ticket, les étiquettes permettent de fournir la documentation des processus de traduction et de validation, mais aussi d’autres informations, notamment par la définition de labels d’état (entité, propriété), ou de version de travail etc. À l’échelle du tableau de bord (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">), 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.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">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 (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">), elle permet aussi de rendre visible la genèse des transformations successives d’un élément (fichier </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;">) au cours du temps et au moyen des enregistrements successifs (</span><i><span style="background-color:#ffffff;">commit</span></i><span style="background-color:#ffffff;">) qui sont rattachés à la branche (</span><i><span style="background-color:#ffffff;">branch</span></i><span style="background-color:#ffffff;">) active.</span></span></p>

<h4 class="western"><span style="background-color:#ffffff;">2.4 Les branches dans GitLab et l’intégration continue vers une page web</span></h4>

<p align="justify"><span style="background-color:#ffffff;">Une grande partie du succès de Git vient de sa gestion efficace et rapide des branches. Une branche (</span><i><span style="background-color:#ffffff;">branch</span></i><span style="background-color:#ffffff;">) est une succession d’états donnés (</span><i><span style="background-color:#ffffff;">commits</span></i><span style="background-color:#ffffff;">) 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. Elles permettent 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 </span><i><span style="background-color:#ffffff;">translate</span></i><span style="background-color:#ffffff;">, (</span><span style="background:#b6d7a8"><span style="background-color:#ffffff;">figure 3</span></span><span style="background-color:#ffffff;">) son évolution est de ne pas se limiter à la traduction de la version ISO, mais de continuer à traduire les différentes versions de l’ontologie. Ainsi, quand la version ISO, 7.1.2 sera réalisée, une nouvelle branche sera créée pour prendre en compte les modifications du modèle, actuellement vers la version 7.2.x. 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 (</span><i><span style="background-color:#ffffff;">framework)</span></i><span style="background-color:#ffffff;"> (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Symfony n.d.</span></span><span style="background-color:#ffffff;">), dans le domaine du développement informatique.</span></p>

<p align="justify"><img height="643" src="https://www.numerev.com/img/ck_2783_17_image-20230301211426-1.png" width="589" /></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><font style="font-size:9pt"><font size="2"><span style="background:#93c47d"><span style="background-color:#ffffff;">Figure 3 </span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">: évolution du modèle du CIDOC CRM, évolution du projet de traduction, implémentation par les branches (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">branch translate</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">).</span></font></font></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Ainsi, la publication de la traduction des différentes versions du CIDOC-CRM est accessible à des adresses (URL) différentes </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">(<a href="https://cidoc-crm-fr.mom.fr/">https://cidoc-crm-fr.mom.fr/</a>)</span></span><span style="background-color:#ffffff;">. Grâce à l'intégration continue</span><i><span style="background-color:#ffffff;"> (continuous integration)</span></i><span style="background-color:#ffffff;"> de GitLab, chaque enregistrement (</span><i><span style="background-color:#ffffff;">commit</span></i><span style="background-color:#ffffff;">) des modifications d'un fichier entraîne l'exécution de transformations des fichiers (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">David-Jacquot, 2023</span></span><span style="background-color:#ffffff;">). Ce processus itératif automatisé synchronise le contenu des documents de travail </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;">, avec la 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 </span><i><span style="background-color:#ffffff;">pandoc</span></i><span style="background-color:#ffffff;"> dans un environnement de style (</span><i><span style="background-color:#ffffff;">framework</span></i><span style="background-color:#ffffff;">) 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 sont rassemblées dans un fichier d’instructions (</span><i><span style="background-color:#ffffff;">gitlal-ci.yml</span></i><span style="background-color:#ffffff;">) versionné au sein de chaque branche. À chaque enregistrement (</span><i><span style="background-color:#ffffff;">commit</span></i><span style="background-color:#ffffff;">), la plateforme exécute automatiquement les commandes (</span><i><span style="background-color:#ffffff;">scripts</span></i><span style="background-color:#ffffff;">) réalisant les deux étapes (</span><i><span style="background-color:#ffffff;">stages</span></i><span style="background-color:#ffffff;">) suivantes : (a) la préparation (</span><i><span style="background-color:#ffffff;">build</span></i><span style="background-color:#ffffff;">) </span><font color="#252525"><span style="background-color:#ffffff;">de l’ensemble des fichiers à publier, dont notamment</span></font><span style="background-color:#ffffff;"> (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 </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> et (iii) la création des pages statiques HTML. La seconde étape consiste en (b) la publication (</span><i><span style="background-color:#ffffff;">deploy</span></i><span style="background-color:#ffffff;">) 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.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">La page web statique (</span><span style="background:#93c47d"><span style="background-color:#ffffff;">figure 4</span></span><span style="background-color:#ffffff;">) ainsi déployée rend immédiatement accessible le résultat du travail de traduction. Elle en fournit l’état d’avancement le plus à jour. Elle permet la navigation dans la documentation traduite, 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 </span><i><span style="background-color:#ffffff;">workflow</span></i><span style="background-color:#ffffff;"> 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.</span></span></p>

<p align="justify" style="margin-bottom:11px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205341-6.png" style="width: 600px; height: 277px;" /></p>

<p><font style="font-size:9pt"><font size="2"><span style="background:#b6d7a8"><span style="background-color:#ffffff;">Figure 4 </span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">: page web qui publie le résultat de la traduction depuis les fichiers en markdown grâce à l'intégration continue</span></font></font></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="page-break-inside:auto"><span style="page-break-after:auto"><span style="background-color:#ffffff;">La page web de publication du </span><i><span style="background-color:#ffffff;">work in progress</span></i><span style="background-color:#ffffff;"> 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⋅trices y mesurent l’avancée du projet et y définissent les priorités de traduction, grâce à la fonctionnalité des jalons (</span><i><span style="background-color:#ffffff;">milestones</span></i><span style="background-color:#ffffff;">) de GitLab.</span></span></span></span></p>

<h4 class="western"><span style="background-color:#ffffff;">2.5 Jalons (</span><i><span style="background-color:#ffffff;">milestones</span></i><span style="background-color:#ffffff;">) dans GitLab et organisation des sessions de validation</span></h4>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">En programmation informatique, les jalons (</span><i><span style="background-color:#ffffff;">milestones)</span></i><span style="background-color:#ffffff;"> sont utilisés pour définir des séquences (</span><i><span style="background-color:#ffffff;">sprints</span></i><span style="background-color:#ffffff;">) agiles, auxquelles sont associés des tickets (</span><i><span style="background-color:#ffffff;">issues</span></i><span style="background-color:#ffffff;">). 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” (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Manifeste Pour Le Développement Agile de Logiciels, n.d.</span></span><span style="background-color:#ffffff;">). 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 </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">(YAGNI, 2022</span></span><span style="background-color:#ffffff;">). 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.</span></span></p>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">Adoptant une pratique agile dans le projet de traduction, le groupe tire parti de la structure non linéaire du texte à traduire. 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 (</span><i><span style="background-color:#ffffff;">boards</span></i><span style="background-color:#ffffff;">) ne permet pas de transcrire ces relations sémantiques et syntaxiques de l’ontologie. La fonctionnalité des jalons (</span><i><span style="background-color:#ffffff;">milestones</span></i><span style="background-color:#ffffff;">) permet de tenir compte de cette organisation intrinsèque au texte à traduire. Chaque jalon est construit à partir des regroupements d’entités et de propriétés fondés sur deux concepts propres au CIDOC CRM (</span><span style="background:#b6d7a8"><span style="background-color:#ffffff;">figures 5 et 6</span></span><span style="background-color:#ffffff;">) : le domaine d’une propriété et la relation de spécialisation d’une entité. (i) Le domaine (</span><i><span style="background-color:#ffffff;">domain</span></i><span style="background-color:#ffffff;">) est l’entité dont la propriété part pour la relier à une autre entité (son co-domaine, </span><i><span style="background-color:#ffffff;">range</span></i><span style="background-color:#ffffff;"> en anglais), (ii) la relation de spécialisation “Est Un·e” (notée </span><i><span style="background-color:#ffffff;">IsA</span></i><span style="background-color:#ffffff;">) traduit une relation hiérarchique entre entités. Par exemple :</span></span></p>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">(i) l’entité E99 est dans le même groupe logique que les propriétés P187 et P188 dont elle est le domaine :</span></span></p>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">E99</span><i><span style="background-color:#ffffff;"> Product Type :</span></i></span></p>

<ul>
	<li>
	<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">P187</span><i><span style="background-color:#ffffff;"> has production plan (is production plan for): </span></i><span style="background-color:#ffffff;">E29</span><i><span style="background-color:#ffffff;"> Design or Procedure </span></i></span></p>
	</li>
	<li>
	<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">P188</span><i><span style="background-color:#ffffff;"> requires production tool (is production tool for): </span></i><span style="background-color:#ffffff;">E19</span><i><span style="background-color:#ffffff;"> Physical Object.</span></i></span></p>
	</li>
</ul>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">E29 et E19 sont les entités co-domaine respectivement de P187 et P188.</span></span></p>

<p align="justify"><span style="line-height:100%"><span style="background-color:#ffffff;">(ii) E55 est dans le groupe logique de l’entité E28 dont elle est une sous-classe :</span></span></p>

<ul>
	<li>
	<p align="justify"><span style="background-color:#ffffff;">E55</span><i><span style="background-color:#ffffff;"> Type IsA </span></i><span style="background-color:#ffffff;">E28</span><i><span style="background-color:#ffffff;"> Conceptual Object, </span></i></p>
	</li>
</ul>

<p align="justify"><span style="background-color:#ffffff;">et le groupe E55 contient les sous-classes E56, et E57, E58 et E99 :</span></p>

<ul>
	<li>
	<p><span style="background-color:#ffffff;">E56 </span><i><span style="background-color:#ffffff;">Language IsA</span></i><span style="background-color:#ffffff;"> E55 </span><i><span style="background-color:#ffffff;">Type</span></i><span style="background-color:#ffffff;">,</span></p>
	</li>
	<li>
	<p><span style="background-color:#ffffff;">E57 </span><i><span style="background-color:#ffffff;">Material IsA</span></i><span style="background-color:#ffffff;"> E55 </span><i><span style="background-color:#ffffff;">Type</span></i><span style="background-color:#ffffff;">,</span></p>
	</li>
	<li>
	<p><span style="background-color:#ffffff;">E58 </span><i><span style="background-color:#ffffff;">Measurement Unit</span></i><span style="background-color:#ffffff;"> IsA E55 </span><i><span style="background-color:#ffffff;">Type</span></i><span style="background-color:#ffffff;">,</span></p>
	</li>
	<li>
	<p><span style="background-color:#ffffff;">E99 </span><i><span style="background-color:#ffffff;">Product Type IsA</span></i><span style="background-color:#ffffff;"> E55 </span><i><span style="background-color:#ffffff;">Type</span></i><span style="background-color:#ffffff;">.</span></p>
	</li>
</ul>

<p><span style="background-color:#ffffff;">Les entités et propriétés à traduire sont ainsi regroupées par proximité sémantique au sein de groupes logiques (</span><span style="background:#6aa84f"><span style="background-color:#ffffff;">voir figures 5 et 6</span></span><span style="background-color:#ffffff;">) au moyen d’un </span><i><span style="background-color:#ffffff;">script</span></i><span style="background-color:#ffffff;">.</span></p>

<p style="margin-bottom:11px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205359-7.png" style="width: 600px; height: 218px;" /></p>

<p style="margin-bottom:11px"><span style="line-height:108%"><font style="font-size:9pt"><font size="2"><span style="background:#b6d7a8"><span style="background-color:#ffffff;">Figure 5</span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;"> : représentation schématique d’un groupe logique à un moment donné du flux de travail, reprenant : (i) la hiérarchie des entités (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">IsA</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">), (ii) les relations (</span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">has domain</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">) 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 </span></font></font><font style="font-size:9pt"><font size="2"><i><span style="background-color:#ffffff;">workflow</span></i></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">.</span></font></font></span></p>

<p align="justify" style="margin-bottom:16px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205408-8.png" style="width: 600px; height: 424px;" /></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">Figure 6 : Hiérarchie des groupes sémantiques support de la construction des milestones (entités et propriétés avoisinantes).</span></font></font></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Les jalons (</span><i><span style="background-color:#ffffff;">milestones</span></i><span style="background-color:#ffffff;">) 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 des ces jalons résulte de la rencontre entre une relation experte à la plateforme (technicité), une prise en compte de la structure interne du document 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 de transformer tant les individus que la plateforme elle-même.</span></span></p>

<h3 class="western" style="margin-bottom: 11px;"><span style="line-height:108%"><span style="background-color:#ffffff;">3-Dépasser la fonction technique et productive de la plateforme : analyse simondonienne de l’objet technique numérique</span></span></h3>

<p align="justify"><span style="background:#ffffff">La traduction elle-même est un moyen et non une fin </span><i><span style="background:#ffffff">per se</span></i><span style="background:#ffffff"> : il s’agit de faciliter l'accès et l’usage du CIDOC CRM par la communauté francophone de chercheur⋅ses en patrimoine culturel</span><span style="background-color:#ffffff;">. La description de l’expérimentation (2.) 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.</span></p>

<p align="justify"><span style="background-color:#ffffff;">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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Gavillet, 2010, p.34</span></span><span style="background-color:#ffffff;">) 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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Barthélémy, 2014</span></span><span style="background-color:#ffffff;">). L’ontogenèse proposée s'appuie simultanément sur la lecture de textes de Simondon (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Simondon, 2005 & 2012</span></span><span style="background-color:#ffffff;">) et ceux en prolongement de la philosophie simondonienne.</span></p>

<p align="justify"><span style="background-color:#ffffff;">Centrée sur la technicité (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Duhem, 2013, Feenberg, 2014</span></span><span style="background-color:#ffffff;">) et non l’utilité de la plateforme numérique, l’expérimentation élabore une construction collective de sens autour de quelques concepts simondoniens. La définition de l’objet technique numérique (3.1), le fichier </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> d’une entité ou d’une propriété, permet d’éprouver les notions de préindividuel, d’individuation et de milieu associé. Des mécanismes transductifs, empiriques ou computationnels, transforment non seulement le document initial en édition numérique instantanée de la traduction en cours, mais aussi la plateforme elle-même (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">3.2</span></span><span style="background-color:#ffffff;">), par sa relation au collectif de traduction du CIDOC CRM. La traduction en français du document, intention initiale à la constitution du groupe, concrétise (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">3.3</span></span><span style="background-color:#ffffff;">) un ensemble d’individus techniques qui contribuent à une amplification (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">3.4</span></span><span style="background-color:#ffffff;">) de ce qui est produit </span><i><span style="background-color:#ffffff;">dans</span></i><span style="background-color:#ffffff;"> la relation entre l’humain et la machine.</span></p>

<h4 align="justify" class="western"><span style="background-color:#ffffff;">3.1 Théorie de l’objet technique numérique (et son heuristique), les apports théoriques de Simondon</span></h4>

<p align="justify"><span style="background-color:#ffffff;">Selon Simondon, la définition de l’objet technique a deux volets : il est défini par sa genèse et il s’individue au sein de son milieu. 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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Simondon 2005, p.41-45</span></span><span style="background-color:#ffffff;">), 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” (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Grosman, 2016, p.253</span></span><span style="background-color:#ffffff;">), c’est-à-dire à la fois la réalisation d’une synergie fonctionnelle </span><i><span style="background-color:#ffffff;">dans</span></i><span style="background-color:#ffffff;"> 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 </span><i><span style="background-color:#ffffff;">dans</span></i><span style="background-color:#ffffff;"> la relation entre le moule et l’argile dans le milieu associé pour faire advenir la brique (concrétisation).</span></p>

<p align="justify"><span style="background-color:#ffffff;">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 </span><i><span style="background-color:#ffffff;">dans</span></i><span style="background-color:#ffffff;"> la relation au document. Le document numérique a un mode d’existence indissociablement culturel et technique. La seconde conséquence est technique : il s’agit de prendre le document 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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Hui 2015</span></span><span style="background-color:#ffffff;">). Dans ce contexte, Hui (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Hui, 2015</span></span><span style="background-color:#ffffff;">) définit l’objet numérique (</span><i><span style="background-color:#ffffff;">digital object</span></i><span style="background-color:#ffffff;">) 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.</span></p>

<p align="justify"><span style="background-color:#ffffff;">La définition de l’objet numérique comme objet technique fonctionne bien dans le cadre du projet de traduction. La plateforme GitLab donne à voir les mécanismes de transformation des objets techniques numériques (fichiers </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;">) 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 à la traduction elle-même. Les opérations qui ont lieu au sein de la plateforme sont donc transductives, à la fois empiriques ou computationnelles. Elles produisent un individu constitué par la mise en relation de cet ensemble, mais un individu susceptible d’évoluer encore car en relation avec son milieu (la plateforme). C’est pour cela qu’il reste inachevé ou métastable</span><i><span style="background-color:#ffffff;">.</span></i></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Pour (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Azema, 2022)</span></span><span style="background-color:#ffffff;">, l’usage de transducteurs dans un processus de traduction nécessite d’articuler le triptyque milieu, individu et matière comme un système. La proximité sémantique des concepts traduction et transduction chez </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Simondon</span></span><span style="background-color:#ffffff;"> d’une part, et de transaction pour </span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Dewey</span></span><span style="background-color:#ffffff;"> d’autre part, décrit </span><i><span style="background-color:#ffffff;">mutatis mutandis</span></i><span style="background-color:#ffffff;"> le même processus d’individuation de Simondon (</span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">Barthelemy et al., 2015)</span></span><span style="background-color:#ffffff;">. La relation à la plateforme est alors vue 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. La plateforme elle-même peut ainsi être analysée comme un objet technique numérique qui permet la transformation des individus par la circulation de l’information.</span></span></p>

<h4 align="justify" class="western"><span style="background-color:#ffffff;">3.2 La plateforme comme individu technique simondonien</span></h4>

<p align="justify"><span style="background-color:#ffffff;">Selon Simondon, le préindividuel (c’est-à-dire l’individu technique avant son individuation) est défini par son potentiel de transformation plutôt que par son état existant. Les fichiers </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> 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 </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> sont une étape préparatoire à la traduction. 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 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. Comme la brique, le fichier </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> résulte d’une chaîne opératoire complexe conduisant à la rencontre d’une forme - la syntaxe </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;">, et d’une matière, le texte. Ainsi 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, dans le cas présent, est réalisée par la création d’un code commun (</span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">Grosman, 2016, p. 250</span></span><span style="background-color:#ffffff;">) généré entre la plateforme GitLab (son milieu) et les contributeur⋅trices. Ainsi, avant même la création d’un ticket ouvrant le flux du travail de traduction, le fragment de texte brut en anglais s’est individué dans un code par la relation au geste technique et culturel du collectif.</span></p>

<p align="justify"><span style="background-color:#ffffff;">La relation à la plateforme opère alors par mécanismes transductifs les transformations et l'agrégation des fragments de texte pour établir la traduction et la publier en l’état (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">2.4 ou</span></span><span style="background:#d9ead3"><span style="background-color:#ffffff;"> Fig.4</span></span><span style="background-color:#ffffff;">) sur la page web. Cet ensemble fragmenté du document en cours de traduction est classé en différents répertoires, correspondant à des éléments de la structure du dépôt (</span><i><span style="background-color:#ffffff;">repository</span></i><span style="background-color:#ffffff;">) GitLab. Par exemple, le dossier intitulé </span><i><span style="background-color:#ffffff;">entities</span></i><span style="background-color:#ffffff;"> comprend tous les fichiers </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> contenant chacun les déclarations relatives aux entités du CIDOC-CRM. Celles-ci sont elles-mêmes structurées par le formalisme de leur description et leurs relations (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">2.5</span></span><span style="background-color:#ffffff;">). En traduisant divers fragments de la documentation, le collectif met à l’épreuve la cohérence interne du document initial : dans quel ordre et selon quelles priorités les choix de traduction doivent-ils être discutés ? Tant les groupes sémantiques que les choix opérés dès le départ par les membres du collectif transforment leur lien à la plateforme et par là même, cette dernière. Par exemple, l’accès via les jalons a détrôné l’accès initial par le tableau de bord. Peu à peu, la modulation de la plateforme en arrive à refléter l’essence processuelle du CIDOC CRM. C’est ce qui caractérise son individuation.</span></p>

<p align="justify"><span style="background:#ffffff">La plateforme ressemble à une machine ouverte au sens de Simondon. </span><span style="background-color:#ffffff;">Il s’agit d’une machine parce qu’elle est composée d'instruments (le langage informatique utilisé et le protocole URL), d'éléments informationnels (le fichier d’instructions, l’interpréteur, la mémoire vive ou le processeur), et enfin d'outils (un clavier, une souris ou un écran par exemple).</span><span style="background:#ffffff"> 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 (</span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">Simondon, 2012, pp.188-189</span></span><span style="background:#ffffff">). A contrario, une machine fermée est un automate : elle ne dispose pas de récepteur ou de capteur d’information extérieure à son fonctionnement et ne peut donc pas se transformer : elle 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. </span></p>

<p align="justify"><span style="background-color:#ffffff;">GitLab permet de travailler dans un environnement technique aligné avec les valeurs d’ouverture du groupe : le partage des connaissances, la copie libre du contenu, l’accès facilité, l’association progressive et continue de contributeur⋅trices, 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 (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Combes, 1999</span></span><span style="background-color:#ffffff;">). 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.</span></p>

<h4 class="western" style="margin-bottom: 11px;"><span style="line-height:108%"><span style="background-color:#ffffff;">3.3 La traduction comme concrétisation</span></span></h4>

<p align="justify" style="margin-bottom:13px"><span style="line-height:100%"><span style="background-color:#ffffff;">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 évenementielle se juxtaposent. Traduire un texte “intraduisible” (</span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">Ladjadj & Chiflet, 2015)</span></span><span style="background-color:#ffffff;"> suppose non seulement d’en connaître la genèse, les éléments de sa structure interne (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">2.5</span></span><span style="background-color:#ffffff;">) ou 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.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">La notion de concrétisation est définie par Simondon comme 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é conduisent à sa concrétisation dans son contexte de production) (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Simondon, 2012, pp.21-23</span></span><span style="background-color:#ffffff;">). En reprenant l’illustration de l’argile, les gestes, les formes et matières utilisées dans leur contexte sont modifiés 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 (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">2.5</span></span><span style="background-color:#ffffff;">). Cette synergie fonctionnelle de la page contribue à concrétiser l’individu </span><i><span style="background-color:#ffffff;">work in progress</span></i><span style="background-color:#ffffff;"> de la traduction du CIDOC-CRM dans son contexte. 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. Cette concrétisation est une des conséquences de la posture adoptée d’expérimentation.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">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 ou GitHub. Au-delà de leur “adaptation” ou “extension” au sens de Jenkins (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Zacklad, 2012</span></span><span style="background-color:#ffffff;">), les objets techniques numériques se co-construisent en même temps que la mise en œuvre du projet de traduction. La machine numérique est composée non seulement du dépôt GitLab, mais aussi des appareils de visioconférence Rendez-Vous de Renater ou l’outil d’édition collaborative et simultanée, Etherpad de l’IN2P3 (“</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Etherpad</span></span><span style="background-color:#ffffff;">” n.d.) ou encore les éditeurs de texte vim ou emacs. Ces ramifications de la plateforme concrétisent un ensemble informationnel.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><font color="#252525"><span style="background-color:#ffffff;">À la différence du domaine du développement informatique, le champ dans lequel la relation à la plateforme s’inscrit est pluridisciplinaire et non marchand (</span></font><font color="#252525"><span style="background:#ead1dc"><span style="background-color:#ffffff;">Alcaras, 2023</span></span></font><font color="#252525"><span style="background-color:#ffffff;">). Il suppose un triple engagement (</span></font><font color="#252525"><span style="background:#ead1dc"><span style="background-color:#ffffff;">Bachimont, 2007</span></span></font><font color="#252525"><span style="background-color:#ffffff;">) : engagement sémantique (discuter du sens </span></font><font color="#252525"><i><span style="background-color:#ffffff;">dans</span></i></font><font color="#252525"><span style="background-color:#ffffff;"> la traduction), ontologique (partageant la logique formelle du projet et des outils) et 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 (</span></font><font color="#252525"><span style="background:#d5a6bd"><span style="background-color:#ffffff;">Treleani, 2016)</span></span></font><font color="#252525"><span style="background-color:#ffffff;">. Le concept d’’individuation ne concerne pas seulement l’objet technique, mais comme dans le cas de la relation à la plateforme, il est aussi psycho-cognitif. Le collectif se constitue alors comme transindividualité par sa propre genèse et la dynamique des flux sémiotiques échangés ou générés</span></font><font color="#252525"><span style="background:#ead1dc"><span style="background-color:#ffffff;"> (Duhem, 2013). </span></span></font></span></p>

<p align="justify" style="margin-bottom:16px"><span style="line-height:100%"><font color="#252525"><span style="background-color:#ffffff;">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 </span></font><font color="#252525"><i><span style="background-color:#ffffff;">imposter syndrom</span></i></font><font color="#252525"><span style="background-color:#ffffff;">) vis-à-vis de la plateforme et de la technique.</span></font></span></p>

<h4 align="justify" class="western"><span style="background-color:#ffffff;">3.4 Relation humain-machine</span></h4>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">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 (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">3.2</span></span><span style="background-color:#ffffff;">) : ce sont les transducteurs (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Grosman, 2016, p. 250</span></span><span style="background-color:#ffffff;">) 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 </span><i><span style="background-color:#ffffff;">markdown.</span></i><span style="background-color:#ffffff;"> Organisé au sein de la structure du dépôt du GitLab, il est issu de transformations successives du document de référence (</span><span style="background:#d9ead3"><span style="background-color:#ffffff;">Figure 7a</span></span><span style="background-color:#ffffff;">). À leur échelle, les fichiers </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;"> sont des objets techniques numériques (</span><span style="background:#cfe2f3"><span style="background-color:#ffffff;">3.1</span></span><span style="background-color:#ffffff;">) 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 </span><span style="background:#d9ead3"><span style="background-color:#ffffff;">figure 7b</span></span><span style="background-color:#ffffff;">, ce geste technique noue la première demi-chaîne opératoire à la seconde.</span></span></p>

<p align="justify"><span style="background-color:#ffffff;">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 (</span><span style="background:#d5a6bd"><span style="background-color:#ffffff;">David-Jacquot et al., 2022</span></span><span style="background-color:#ffffff;">) 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 </span><i><span style="background-color:#ffffff;">markdown</span></i><span style="background-color:#ffffff;">. 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.</span></p>

<p align="center" style="text-indent:-0.25cm; margin-bottom:11px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205435-9.png" style="width: 600px; height: 250px;" /></p>

<p style="margin-bottom:11px"><span style="line-height:108%"><font style="font-size:9pt"><font size="2"><span style="background:#b6d7a8"><span style="background-color:#ffffff;">Figure 7a </span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;">: demi chaîne opératoire de transformation du document initial (au format .docx) en code commun.</span></font></font></span></p>

<p style="margin-bottom:11px"><img src="https://www.numerev.com/img/ck_2783_17_image-20230301205618-10.png" style="width: 600px; height: 250px;" /></p>

<p style="margin-bottom:11px"><span style="line-height:108%"><font style="font-size:9pt"><font size="2"><span style="background:#b6d7a8"><span style="background-color:#ffffff;">Figure 7b</span></span></font></font><font style="font-size:9pt"><font size="2"><span style="background-color:#ffffff;"> : 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). </span></font></font></span></p>

<p align="justify"><span style="background-color:#ffffff;">La traduction du CIDOC CRM n’exclut pas d’autres méthodologies et types d’organisations. 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 (POC) de la plateforme concrète (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Grosman, 2016, p. 253</span></span><span style="background-color:#ffffff;">), qui continue à grandir. Le nombre de </span><i><span style="background-color:#ffffff;">commits</span></i><span style="background-color:#ffffff;"> en 2022 a triplé par rapport à 2021 (489 en 2022, 153 en 2021) avec 16 contributeur⋅trices actifs (ayant effectué au moins un </span><i><span style="background-color:#ffffff;">commit</span></i><span style="background-color:#ffffff;">). Le nombre d’</span><i><span style="background-color:#ffffff;">issues</span></i><span style="background-color:#ffffff;"> 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 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⋅trices, mais bien des partenaires à part entière d’un processus enrichissant. Cette logique de transformation appelle à la participation d’une diversité et pluralité de la francophonie dans le collectif.</span></p>

<p align="justify"><span style="background-color:#ffffff;">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. Notre choix de “solidarité technique” conduit à une désaliénation mutuelle.</span></p>

<p align="justify"><span style="background-color:#ffffff;">Par ailleurs, il faut 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, prescripteurs, producteurs et production. En cela, nous pouvons affirmer que nous avons bâti une “organisation distribuée” (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Dodier & Barbot, 2016</span></span><span style="background-color:#ffffff;">).</span></p>

<h3 class="western" style="margin-bottom: 11px;"><span style="line-height:108%"><span style="background-color:#ffffff;">4-Conclusion</span></span></h3>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">Pour conclure, nous avons montré que le projet de traduction collaborative du CIDOC CRM en français (</span></span><a href="https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm"><span style="background-color:#ffffff;">https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm</span></a><span style="line-height:108%"><span style="background-color:#ffffff;">) 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⋅trices et de contributeur⋅trices 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é (</span><span style="background:#ead1dc"><span style="background-color:#ffffff;">Feenberg, 2016, p.323</span></span><span style="background-color:#ffffff;">) de l’ensemble informationnel que l’on constitue avec la plateforme numérique. Elle répond également à des attentes plus traditionnelles du monde académique.</span></span></p>

<p align="justify" style="margin-bottom:11px"><span style="line-height:108%"><span style="background-color:#ffffff;">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 Gilles 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. </span><font color="#252525"><span style="background-color:#ffffff;">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’</span></font><span style="background-color:#ffffff;">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.</span></span></p>