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 markdown, the production of statistics on the whole project and its documentation through functionalities such as issues, milestones and branches. 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. <h3>1-Introduction</h3> Cet article esquisse une analyse d’un projet ouvert de traduction collaborative mobilisant le “geste simondonien” (Dodier, 1995 p. 9). Ce projet (Doc fr CIDOC CRM · GitLab, 2023) utilise le logiciel de gestion de version distribuée Git et l’environnement associé GitLab. Depuis 2019, un groupe de chercheuses et chercheurs francophones a entrepris le projet de traduire collectivement en français l’ontologie formelle du Modèle Conceptuel de Référence du Comité International de DOCumentation de l’ICOM (<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. Au sein de la communauté scientifique française, le champ des humanités numériques émerge avec le manifeste de 2010 (Dacos, 2010). Avant cela, des précurseurs interrogent la place de l’ordinateur dans divers champs disciplinaires, par exemple les médiévistes (Bourlet & al, 1979) ou au sein de la sociologie de l’innovation (Gavillet, 2010) ou encore les médiologues au début des années 1990 (Debray Régis, 2001). En 2017, les sciences de l’information et de la communication dépassent le champ des humanités numériques (digital humanities) et se positionnent vis-à-vis des études numériques (digital studies) (Paquienséguy, 2017). Ce n’est pas un hasard si les termes sont désormais en anglais, en effet, la discipline des humanités numériques connaît une nette prédominance anglophone. Par conséquent, les institutions et les chercheurs et chercheuses travaillant dans cette langue sont surreprésentées par rapport aux autres communautés. L’enjeu de la traduction du CIDOC CRM est de 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. 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 (Guillem, Bruseker, 2017) et des méthodes d’alignement sont utilisées avec les outils 3M (Marketakis et al. 2017) et Ontop (Calvanese et al. 2015), suite à quoi des participant⋅es ont souhaité approfondir ces questions. Le groupe de traduction se crée alors de manière informelle dans le but de traduire en français le CIDOC CRM. L’objectif 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 &oelig;uvre de l’ontologie formelle CIDOC CRM, tant par la modélisation formelle de problématiques données que dans son implémentation technique en lien avec des travaux de recherche de diverses disciplines. Cette appropriation multilingue d’un standard international va dans le sens de l’évolution de la norme IFLA LRM/FRBR (Riva, 2017) adoptée par la Bibliothèque nationale de France (BnF). Cet effort de traduction vers le français n’est pas le premier : en effet, deux démarches similaires ont été entreprises en 2006 et 2014 (Croft, 2007 et Szabados et al. 2012). Ces initiatives internationales étaient, comme celle qui nous occupe aujourd’hui, corrélées dans le temps avec un processus de certification ISO, ou sa révision. La traduction de 2006 concernait la version 4.0 du CIDOC CRM associée à la norme ISO 21127:2006 tandis que la traduction de 2014 concernait la version 5.0.4 associée à la norme ISO 21127:2014. Ces traductions ne sont pas librement accessibles. Comme tout document ISO, leur accès est payant. Le projet dans lequel nous nous sommes lancés en 2019 comptait initialement des membres canadiens qui, pour des raisons institutionnelles, développent dorénavant leur propre traduction. Le CIDOC CRM est continuellement mis à jour par un Special Interest Group (CIDOC CRM SIG) dont les procédures se font en anglais. Celui-ci se réunit plusieurs fois par an et contribue à faire évoluer l’ontologie formelle en fonction des usages et la résolution, par consensus, de questions épistémologiques. À ce jour, l’usage du CIDOC CRM nécessite donc de naviguer entre une documentation obsolète en français et une version en anglais régulièrement mise à jour, ce qui est source d’erreurs et/ou de mésusages. Le choix de traduire à nouveau la documentation CIDOC CRM est aussi lié au nouveau processus réglementaire de certification ISO de la version anglaise - qui fera autorité. Ce souhait de stabilisation du modèle conceptuel de base motive l'investissement en temps et en travail du collectif d’individus impliqués et de leurs institutions. La complexité du texte à traduire (Ladjadj & Chiflet, 2015), les différentes cultures professionnelles et scientifiques des membres du collectif et la diversité de pratiques du CIDOC CRM augmentent a priori la difficulté d’obtenir un consensus autour d’une traduction proposée. C’est pourquoi la concomitance entre l’invention de méthodes d’organisation, de processus de décision et la mise en place de l’environnement GitLab permet de co-construire la plateforme et de la faire évoluer de manière continue. La diversité des langues francophones (de France, de Belgique, du Luxembourg ou du Canada) et leurs pratiques actuelles (par exemple, la neutralisation du genre) peuvent également accroître la complexité des choix pour la validation par consensus de la traduction collective en français. Expliciter les données 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é (Simondon, 2012, p.310) 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 (Guarino 1998) qui définit ce type d’ontologie comme, d’une part, une spécification d'un ensemble de concepts nommés utilisés pour décrire et approcher un fragment du réel, ainsi que, d’autre part, une théorie logique du premier ordre qui restreint la signification 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. La relation entre les membres du collectif de traduction et l’environnement GitLab d’Huma-Num est envisagée comme une expérimentation en humanités numériques. Celle-ci conduit à considérer a priori le terme de dispositif numérique comme une plateforme, au sens de l’approche critique de la métaphore de la plateforme (Gillespie, 2017) : lieu d’un travail habituellement caché, la plateforme peut se voir assigner la tâche d’héberger le travail réel qui ne peut pas être effacé, voire de le protéger. Dans ce contexte, la dynamique collaborative du processus de traduction contribue à construire une culture et des techniques communes qui dépassent le cadre socio-technique de production de la traduction. Cette réflexion est nourrie par le contenu textuel à traduire, puisqu’il s’agit de la documentation d’une ontologie formelle servant à décrire le monde. L’analyse fine des relations productives (partie 2) à et par la plateforme de travail tient compte d’une forme de solidarité technique entre l’humain et la machine, de la formation d’un ensemble technique (Dodier, 1995, p.13) ou informationnel (Barthélémy, 2015, p.4), susceptible de réaliser la traduction. Ce cadre d’échanges au sein du groupe génère une auto-analyse théorique continue (partie 3). Le projet donne l’opportunité d’une acculturation avec 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. <h3 class="western">2-GitLab comme plateforme de travail du projet de traduction collaborative : méthodes, outils et processus</h3> <h4 class="western">2.1 La plateforme GitLab comme dispositif technique et informationnel pour le projet collaboratif de traduction</h4> Le projet de traduction collective se développe comme une expérimentation (Gavillet, 2010) 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) (Wilkinson et al., 2016). 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. 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 (issues) permet de documenter le processus de traduction mobilisant le langage markdown (2.2). La définition du tableau de bord (boards) permet de suivre l'avancée du travail de traduction et de validation (2.3). Des branches scindent les alternatives de versions de documents (2.4) et des jalons (milestones) organisent les sessions de traduction/validation autour de groupes cohérents d'entités et de propriétés de l’ontologie du CIDOC CRM (2.5). <h4 class="western">2.2 Fichiers, dépôt et tickets (issues) dans la plateforme GitLab et projet de traduction</h4> 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 (GitLab runner). Le workflow typique de Git implique des actions pour : (a) dupliquer localement les fichiers du serveur distant (git clone, git pull), avant de (b) réaliser des modifications de manière asynchrone, puis de mettre à jour l’historique des changements (c) git commit, et permettre le versement des modifications (d) git push, à la prochaine connexion avec le serveur. 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 workflow 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 merge requests, 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. 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 (<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) présente le projet de traduction. Un Wiki (<a href="https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm/-/wikis/home">Home · Wiki</a><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. Dans le cas usuel d’un projet de développement informatique, le dépôt (repository) 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 (regex) (Préparation Des Fichiers à Traduire (#8), 2020; David-Jacquot, 2021). 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 markdown (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. 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 (issue). 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. <h4 class="western">2.3 Tickets et tableau de bord : workflows de traduction et de validation</h4> L’utilisation de la fonctionnalité du ticket (issue) est proche de celle d’un guichet pour mettre à l’ordre du jour un problème ou une question afin de la résoudre, le cas échéant, collectivement. Traditionnellement, les tickets (issues) sont utilisés en développement de projet informatique pour une remontée de bug ou une demande de nouvelle fonctionnalité, d’évolution, d’extension ou d’adaptation. La page d’un ticket contient les échanges entre 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. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205224-2.png" style="width: 600px; height: 267px;" /> Figure 1 : Avancée des tickets (Issues) dans les workflows de traduction et de validation des traductions utilisant les tableaux de bord (Boards) et les labels dans la plateforme GitLab pour le suivi du projet. Après l’entrée de l’élément à traduire dans le flux de travail, le suivi de la traduction et de la validation par le groupe est assuré grâce aux fonctionnalités du tableau de bord (boards). Il permet l’organisation des tickets et leur manipulation (Development · Boards, 2023) pour la gestion d'un double workflow (figure 1). La définition des étapes des workflows de traduction et de validation sont discutées puis choisies par le groupe collectivement. Les étapes de traduction sont : <ol> <li align="justify">À traduire : l'élément à traduire entre dans le flux de travail selon les priorités définies par le groupe.</li> <li align="justify">En cours de traduction : 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.</li> <li align="justify">Traduit en attente de révision : 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.</li> </ol> Les étapes de validation commencent à partir de l'étape 3 du workflow de traduction : <ol start="3"> <li align="justify">Traduit en attente de révision : il s’agit de l'étape charnière, le passage entre le flux individuel de traduction et celui, collectif, de validation.</li> <li align="justify">En cours de révision : 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.</li> <li align="justify">Validé : la validation de la traduction est terminée. Le ticket est alors marqué validé par ce label puis clos (closed), ce qui intervient sur l’avancement des jalons (milestones) (2.5).</li> </ol> Les workflows de traduction et de révision sont matérialisés par le tableau de bord (boards). Les tickets associés à un élément à traduire sont déplacés par un glisser-déposer d’une colonne à l'autre (figure 2b) au fur et à mesure de son avancée dans le workflow. 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 &oelig;uvre de la traduction individuelle asynchrone avec la révision/validation qui est synchrone et collective. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205258-3.png" style="width: 600px; height: 48px;" /> Figure 2a : exemple de changement d'étiquette (label) pour le ticket (issue) #87 pour l’entité E10 Transfer of custody (E10 Transfer of Custody (#87)). <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205309-4.png" style="width: 600px; height: 287px;" /> Figure 2b : exemple de changement dans le tableau de bord (board) du ticket (issue) #82 pour l'entité E30 Rights (E30 Rights (#82)). Rappelons ici que pour matérialiser le passage d’une étape du workflow à une autre (par exemple de “à traduire” à “en cours de traduction”), le ticket (issue) est déplacé d’un tableau de bord (boards) à l'autre. Cela a pour conséquence, à l’échelle du ticket, d’assigner une étiquette (label) jusqu' à l’attribution d’une étiquette ultérieure. Cela modifie le statut du ticket en y attachant le libellé des étapes de traduction et de validation. Un historique des processus de traduction et de validation est ainsi créé (figure 2a). Les étiquettes (labels) permettent ainsi une double relation à la plateforme. Les tickets tracent l’état d’avancement de traduction d’un élément spécifique à l’échelle du ticket (issue) (figure 2a), tandis que le tableau de bord (boards) présente l’avancée globale du projet de traduction (figure 2b) à l’échelle du workflow. À 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 (boards), l’itération est possible puisque la validation de la traduction d’un élément se poursuit par la fermeture du ticket associé, qui pourra être ré-ouvert pour initier la mise à jour de la traduction lors du passage à une version ultérieure de la documentation de l’ontologie. Si la plateforme GitLab permet de visualiser la trace des actions réalisées à l’échelle du ticket ou d’un ensemble structuré de tickets (boards), elle permet aussi de rendre visible la genèse des transformations successives d’un élément (fichier markdown) au cours du temps et au moyen des enregistrements successifs (commit) qui sont rattachés à la branche (branch) active. <h4 class="western">2.4 Les branches dans GitLab et l’intégration continue vers une page web</h4> Une grande partie du succès de Git vient de sa gestion efficace et rapide des branches. Une branche (branch) est une succession d’états donnés (commits) de l’ensemble des éléments du dépôt (fichiers versionnés). Plusieurs branches peuvent coexister au sein d’un seul dépôt. 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 translate, (figure 3) 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 (framework) (Symfony n.d.), dans le domaine du développement informatique. <img height="643" src="https://www.numerev.com/img/ck_2783_17_image-20230301211426-1.png" width="589" /> Figure 3 : évolution du modèle du CIDOC CRM, évolution du projet de traduction, implémentation par les branches (branch translate). Ainsi, la publication de la traduction des différentes versions du CIDOC-CRM est accessible à des adresses (URL) différentes (<a href="https://cidoc-crm-fr.mom.fr/">https://cidoc-crm-fr.mom.fr/</a>). Grâce à l'intégration continue (continuous integration) de GitLab, chaque enregistrement (commit) des modifications d'un fichier entraîne l'exécution de transformations des fichiers (David-Jacquot, 2023). Ce processus itératif automatisé synchronise le contenu des documents de travail markdown, 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 pandoc dans un environnement de style (framework) standard et léger, et (b) l’accès simple et rapide à l’entité ou la propriété recherchée dans une page web statique. Les commandes permettant l’intégration continue sont rassemblées dans un fichier d’instructions (gitlal-ci.yml) versionné au sein de chaque branche. À chaque enregistrement (commit), la plateforme exécute automatiquement les commandes (scripts) réalisant les deux étapes (stages) suivantes : (a) la préparation (build) de l’ensemble des fichiers à publier, dont notamment (i) le sommaire dynamique (ancres HTML) des entités et des propriétés à partir des noms des fichiers du dépôt, (ii) la transcription en code HTML des textes codés en markdown et (iii) la création des pages statiques HTML. La seconde étape consiste en (b) la publication (deploy) de la traduction par le déplacement des fichiers transformés, agrégés et construits en code HTML vers le serveur (WEB) de consultation pour les usagers. La page web statique (figure 4) ainsi déployée 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 workflow 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. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205341-6.png" style="width: 600px; height: 277px;" /> Figure 4 : page web qui publie le résultat de la traduction depuis les fichiers en markdown grâce à l'intégration continue La page web de publication du work in progress est produite par la relation à la plateforme GitLab, mais elle est extérieure à celle-ci : les fichiers constitutifs de la version HTML de la traduction en cours sont présents sur le serveur de la Maison de l’Orient et de la Méditerranée (MOM). Il n’est pas possible de modifier directement le code HTML issu du processus d’intégration continue. Cela n’est pas non plus souhaitable, car ce travail ne serait pas pris en compte par la plateforme. La participation au processus de traduction/validation nécessite donc le retour à la plateforme GitLab. Les contributeur⋅trices y mesurent l’avancée du projet et y définissent les priorités de traduction, grâce à la fonctionnalité des jalons (milestones) de GitLab. <h4 class="western">2.5 Jalons (milestones) dans GitLab et organisation des sessions de validation</h4> En programmation informatique, les jalons (milestones) sont utilisés pour définir des séquences (sprints) agiles, auxquelles sont associés des tickets (issues). La culture agile est liée à l’expression de valeurs, notamment : “des individus et de leurs interactions plutôt que des processus et outils” et “des logiciels opérationnels plutôt qu’une documentation exhaustive” (Manifeste Pour Le Développement Agile de Logiciels, n.d.). Pour la plateforme de traduction, l’utilisation des jalons permet de reprendre notamment le principe agile de simplicité, c’est-à-dire “l’art de maximiser la quantité de travail qu’on ne fait pas”. De même, la compréhension au fil de l’eau du projet permet de développer des fonctions au gré des besoins (YAGNI, 2022). En conséquence, le processus permet des livraisons régulières de fragments traduits et de techniques associées, sur de courts délais et évalués collectivement. Adoptant une pratique agile dans le projet de traduction, le groupe tire parti de la structure non linéaire du texte à traduire. L’ontologie est organisée par des relations hiérarchiques (classes et sous-classes) et des relations entre entités et propriétés. Or l’utilisation des tickets au sein de tableaux de bord (boards) ne permet pas de transcrire ces relations sémantiques et syntaxiques de l’ontologie. La fonctionnalité des jalons (milestones) permet de tenir compte de cette organisation intrinsèque au texte à traduire. Chaque jalon est construit à partir des regroupements d’entités et de propriétés fondés sur deux concepts propres au CIDOC CRM (figures 5 et 6) : le domaine d’une propriété et la relation de spécialisation d’une entité. (i) Le domaine (domain) est l’entité dont la propriété part pour la relier à une autre entité (son co-domaine, range en anglais), (ii) la relation de spécialisation “Est Un·e” (notée IsA) traduit une relation hiérarchique entre entités. Par exemple : (i) l’entité E99 est dans le même groupe logique que les propriétés P187 et P188 dont elle est le domaine : E99 Product Type : <ul> <li> P187 has production plan (is production plan for): E29 Design or Procedure </li> <li> P188 requires production tool (is production tool for): E19 Physical Object. </li> </ul> E29 et E19 sont les entités co-domaine respectivement de P187 et P188. (ii) E55 est dans le groupe logique de l’entité E28 dont elle est une sous-classe : <ul> <li> E55 Type IsA E28 Conceptual Object, </li> </ul> et le groupe E55 contient les sous-classes E56, et E57, E58 et E99 : <ul> <li> E56 Language IsA E55 Type, </li> <li> E57 Material IsA E55 Type, </li> <li> E58 Measurement Unit IsA E55 Type, </li> <li> E99 Product Type IsA E55 Type. </li> </ul> Les entités et propriétés à traduire sont ainsi regroupées par proximité sémantique au sein de groupes logiques (voir figures 5 et 6) au moyen d’un script. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205359-7.png" style="width: 600px; height: 218px;" /> Figure 5 : représentation schématique d’un groupe logique à un moment donné du flux de travail, reprenant : (i) la hiérarchie des entités (IsA), (ii) les relations (has domain) avec les propriétés associées à l’entité considérée, (iii) le nombre calculé de mots de la note d’application et (iv) l’état au regard des étapes du workflow. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205408-8.png" style="width: 600px; height: 424px;" /> Figure 6 : Hiérarchie des groupes sémantiques support de la construction des milestones (entités et propriétés avoisinantes). Les jalons (milestones) de GitLab ainsi construits permettent simultanément le suivi de la création des tickets, mais aussi une planification possible du déroulé de la validation des traductions. Ils répondent au besoin de définir une cohérence dans les priorités de traduction et de validation au sein du collectif. La production 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. <h3 class="western" style="margin-bottom: 11px;">3-Dépasser la fonction technique et productive de la plateforme : analyse simondonienne de l’objet technique numérique</h3> La traduction elle-même est un moyen et non une fin per se : il s’agit de faciliter l'accès et l’usage du CIDOC CRM par la communauté francophone de chercheur⋅ses en patrimoine culturel. La description de l’expérimentation (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. La complexité de l’expérimentation et des processus de transformation en relation à la plateforme nécessite d’introduire des concepts articulant ontologie et technologie. La démarche d’auto-analyse de la relation du groupe à et par la plateforme au fil de l’eau fait appel à l’usage d’une “boîte à outils” conceptuels (Gavillet, 2010, p.34) qui aide à expliciter à la fois la relation à la plateforme et la posture d’expérimentation. La philosophie de la technique de Simondon se prête bien à une analyse incarnée dans une pratique (Barthélémy, 2014). L’ontogenèse proposée s'appuie simultanément sur la lecture de textes de Simondon (Simondon, 2005 & 2012) et ceux en prolongement de la philosophie simondonienne. Centrée sur la technicité (Duhem, 2013, Feenberg, 2014) 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 markdown 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 (3.2), 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 (3.3) un ensemble d’individus techniques qui contribuent à une amplification (3.4) de ce qui est produit dans la relation entre l’humain et la machine. <h4 align="justify" class="western">3.1 Théorie de l’objet technique numérique (et son heuristique), les apports théoriques de Simondon</h4> 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 (Simondon 2005, p.41-45), une première chaîne opératoire de la matière transforme l’argile avec l’eau. Une seconde chaîne opératoire correspond à la prise de forme par le moulage, le façonnage et le séchage ou la cuisson de la brique. Ces deux demi-chaînes opératoires sont nouées par un geste technique réalisé par l’humain. Ensuite l’individuation met en relation des structures d’échelles différentes au sein du milieu, relation qui sous-détermine le processus de prise de forme. La genèse de l’objet technique concerne sa “concrétude” (Grosman, 2016, p.253), c’est-à-dire à la fois la réalisation d’une synergie fonctionnelle dans la relation de l’objet technique à son milieu et la dynamique de ce processus. En termes simondoniens, il s’agit au cours du processus d’individuation de réduire les incompatibilités dans la relation entre le moule et l’argile dans le milieu associé pour faire advenir la brique (concrétisation). Toutefois, cette définition des objets techniques physiques peut-elle être étendue au monde du numérique ? L’utilisation de la définition simondonienne pour l'objet technique numérique a deux conséquences. La première est sociale et culturelle, elle induit un changement de paradigme dans la relation au document. 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 (Hui 2015). Dans ce contexte, Hui (Hui, 2015) définit l’objet numérique (digital object) comme un nouveau type d’objet technique industriel, constitué de données et de métadonnées, appréhendables à la fois par des humains et des ordinateurs, au moyen d’un code commun. La définition de l’objet numérique comme objet technique fonctionne bien dans le cadre du projet de traduction. La plateforme GitLab donne à voir les mécanismes de transformation des objets techniques numériques (fichiers markdown) du dépôt, à savoir leur édition, les choix de traduction, l’inscription du texte traduit, les corrections de syntaxe, leur homogénéité et cohérence interne. Ces mécanismes se propagent de proche en proche, en résonance à 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. Pour (Azema, 2022), 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 Simondon d’une part, et de transaction pour Dewey d’autre part, décrit mutatis mutandis le même processus d’individuation de Simondon (Barthelemy et al., 2015). 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. <h4 align="justify" class="western">3.2 La plateforme comme individu technique simondonien</h4> 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 markdown sont des objets techniques numériques qui constituent des éléments unitaires irréductibles, contenant le texte en anglais des entités et propriétés du CIDOC CRM à traduire, soit 241 fichiers représentant environ 70% du texte total. Le devenir de ces fragments est ouvert : les opérations de transformation en markdown sont une étape préparatoire à 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 markdown résulte d’une chaîne opératoire complexe conduisant à la rencontre d’une forme - la syntaxe markdown, et d’une matière, le texte. 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 (Grosman, 2016, p. 250) 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. 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 (2.4 ou Fig.4) 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 (repository) GitLab. Par exemple, le dossier intitulé entities comprend tous les fichiers markdown 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 (2.5). 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. La plateforme ressemble à une machine ouverte au sens de Simondon. 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). Tout en faisant partie de l’être machine, l’interpréteur est un acteur mixte qui va traduire un code informatique en actions. Il est un médiateur entre l’instruction et le milieu qui reçoit l’action. Cette plateforme est ouverte, tout du moins en partie, au sens où elle est sensible à l’information. Elle existe par les relations des éléments qui la composent et peut se transformer par sa marge d’indétermination (Simondon, 2012, pp.188-189). 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. 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 (Combes, 1999). Elle implique des transformations des différentes parties de la relation : du côté de la plateforme, de la traduction et de celui du groupe. <h4 class="western" style="margin-bottom: 11px;">3.3 La traduction comme concrétisation</h4> 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” (Ladjadj & Chiflet, 2015) suppose non seulement d’en connaître la genèse, les éléments de sa structure interne (2.5) 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. 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) (Simondon, 2012, pp.21-23). En reprenant l’illustration de l’argile, les gestes, les formes et matières utilisées dans leur contexte sont modifié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 &oelig;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 (2.5). Cette synergie fonctionnelle de la page contribue à concrétiser l’individu work in progress 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. 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 (Zacklad, 2012), les objets techniques numériques se co-construisent en même temps que la mise en &oelig;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 (“Etherpad” n.d.) ou encore les éditeurs de texte vim ou emacs. Ces ramifications de la plateforme concrétisent un ensemble informationnel. À la différence du domaine du développement informatique, le champ dans lequel la relation à la plateforme s’inscrit est pluridisciplinaire et non marchand (Alcaras, 2023). Il suppose un triple engagement (Bachimont, 2007) : engagement sémantique (discuter du sens dans 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 (Treleani, 2016). 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 (Duhem, 2013). L’ouverture de la plateforme et des modalités de la relation productive permet en retour une désaliénation à la technique elle-même. La bienveillance collective envers la plateforme et au sein du groupe permet d’éviter deux écueils : la méfiance (dans le sens d’un contrôle de la traçabilité) et le sentiment d’incompétence (l’étrangeté de la technique ou syndrome de l’imposteur imposter syndrom) vis-à-vis de la plateforme et de la technique. <h4 align="justify" class="western">3.4 Relation humain-machine</h4> 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 (3.2) : ce sont les transducteurs (Grosman, 2016, p. 250) numériques ou computationnels. Ils sont la relation opératoire entre l’humain et la machine numérique. Dans le cas de la traduction, la demi-chaîne opératoire de la “matière” (le texte anglais structuré) produit un ensemble de fichiers markdown. Organisé au sein de la structure du dépôt du GitLab, il est issu de transformations successives du document de référence (Figure 7a). À leur échelle, les fichiers markdown sont des objets techniques numériques (3.1) puisqu’ils résultent de la rencontre d’un texte brut et d’une forme syntaxique particulière traduisant la sémantique de l’ontologie. Cette matière va ensuite être manipulée et transformée de manière empirique (éditée, discutée, complétée, documentée, étiquetée, validée etc.) et computationnelle (corrigée, transcrite, agrégée puis mise en forme par intégration continue). Comme le montre la figure 7b, ce geste technique noue la première demi-chaîne opératoire à la seconde. Au fur et à mesure de la traduction, un code commun émerge du processus de mise en relation à la plateforme. Cette invention (Simondon toujours) rend concrète la traduction et incarne simultanément le double processus d'individuation de la traduction et de la plateforme. Ce code commun est l’un des creusets où est déposée l’information produite par la relation opératoire de traduction. Un autre fichier opère un processus de transformation sur le texte : c'est un fichier (David-Jacquot et al., 2022) composé d’un dictionnaire syntaxique des occurrences de formes d’intitulés du texte qui permet d’homogénéiser les intitulés dans l’ensemble des fichiers markdown. 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. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205435-9.png" style="width: 600px; height: 250px;" /> Figure 7a : demi chaîne opératoire de transformation du document initial (au format .docx) en code commun. <img src="https://www.numerev.com/img/ck_2783_17_image-20230301205618-10.png" style="width: 600px; height: 250px;" /> Figure 7b : demi-chaîne opératoire de rencontre entre la matière et la forme : la traduction. Les informations sont transcrites dans le code commun de la traduction de plusieurs façons : par la relation à la plateforme GitLab (boutons éditer, valider), puis par les instructions de transformations réalisées par les transducteurs (la commande git et son interprétation, les étapes du .gitlab-ci.yml et le job de l’intégration continue). La traduction du CIDOC CRM n’exclut pas d’autres méthodologies et types d’organisations. 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 (Grosman, 2016, p. 253), qui continue à grandir. Le nombre de commits en 2022 a triplé par rapport à 2021 (489 en 2022, 153 en 2021) avec 16 contributeur⋅trices actifs (ayant effectué au moins un commit). Le nombre d’issues ouvertes en 2023 est 202, 70 ont été fermées (traduction validée). Autrement dit, elle devient une machine ouverte à traduire le CIDOC CRM. Cerise sur le gâteau, il est en plus possible de partager librement la méthodologie et le flux de travail pour d’autres initiatives de traduction. Ces gains inattendus 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. 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. 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” (Dodier & Barbot, 2016). <h3 class="western" style="margin-bottom: 11px;">4-Conclusion</h3> Pour conclure, nous avons montré que le projet de traduction collaborative du CIDOC CRM en français (<a href="https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm">https://gitlab.huma-num.fr/bdavid/doc-fr-cidoc-crm</a>) 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é (Feenberg, 2016, p.323) 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. 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. La visibilité du projet sur GitLab dès le départ a permis aux individus l'accès à la documentation et assure pérennité et résilience à l’initiative. L’expérience en relation à la plateforme est source d’autres relations à la culture et à la technique comme ensemble indissociable. Cela illustre un champ des possibles en termes de dispositif académique non marchand et non institutionnalisé d’une plateforme numérique, ici, pour traduire la documentation d’une méthode de représentation formelle du monde, le CIDOC CRM.