Note de l’éditeur clandestin: ce texte a été reproduit avec la permission de son auteur à partir de son dépôt Git public.

Git comme nouvel ingrédient des chaînes de publication – Antoine Fauchié

Introduction

Depuis l’avènement de l’informatique le processus de gestion éditoriale d’un texte est modifié. Les traitements de texte ont profondément bouleversé notre appréhension de l’écriture (Guichard, 2014), mais aussi l’acte de publication ou plus spécifiquement le métier d’éditeur. Le passage du duo crayon-papier à l’usage de logiciels, en passant par les nombreuses évolutions des machines à écrire mécaniques puis électroniques, a engendré de nouvelles pratiques, facilitant l’accès à l’écriture à des publics divers et faisant gagner un temps précieux aux auteurs et aux éditeurs. Il nous faut toutefois noter qu’un aspect ne semble pas avoir changé lors du passage progressif de l’encodage analogique à l’encodage numérique : la gestion des différentes versions d’un même texte. Les feuilles froissées ou empilées ont été remplacées par la multiplication de fichiers – générant des noms à rallonge comme “mon-texte-relu-par-truc-version-finale-3-date-(copie).doc” – ou par des écrasements successifs. Comment les changements d’un même texte peuvent être gérés dans un environnement désormais entièrement numérique ? Comment l’introduction d’un système élaboré de gestion de versions peut-il nous amener à faire avec le numérique ?

Un décalage éclate entre des applications numériques d’écriture de plus en plus sophistiquées et l’absence de transformation des pratiques de gestion des fichiers qui en résultent. Pourtant d’autres domaines ont dû mettre en place des processus pour contrôler les différentes versions d’un fichier, et donner aux personnes qui travaillent sur un même projet la possibilité de coopérer ensemble, de façon conviviale. Le développement informatique a ainsi mis en place plusieurs systèmes de gestion de versions, dont Git qui peut être utilisé dans d’autres contextes. Git formalise des pratiques encore très peu présentes dans la publication ou l’édition, pourtant essentielles pour travailler dans un environnement numérique.

Nous devons tout d’abord constater les pratiques actuelles de gestion de fichiers issus de traitements de texte : que ce soit les écrasements successifs, les limites de la numérotation ou encore le manque de visibilité sur un projet collectif. Le concept de versionnement constitue le deuxième temps de notre réflexion : comment s’inspirer des pratiques d’autres secteurs qui consistent à gérer également du code – une autre forme de texte ? Enfin la notion de système est une nouvelle dimension introduite par la gestion de versions, il s’agit de modifier notre approche de la chaîne de publication, tout en identifiant des limites liées à l’application d’un modèle issu de l’informatique au champ du livre. Nous nous concentrons sur le document en tant que composé principalement de texte, mais aussi sur des objets plus précis comme le livre.

1. Comment nous opérons sur les fichiers

Nous vivons dans un univers informatisé depuis les années 1980, avec l’arrivée de l’ordinateur personnel et des outils d’édition comme le traitement de texte (Figer, 2009). Le recours à une application comme Microsoft Word, Apple Pages ou plus tard LibreOffice Writer est devenu la norme pour la création de tout document texte. En ce qui concerne la mise en forme, les logiciels de publication assistée par ordinateur ont fait leur apparition dans la même période, facilitant le travail des designers graphiques. Dans le cas de l’écriture, l’utilisation d’une feuille ou d’un crayon est désormais réservée à la prise de note, ou dans une moindre mesure à une mode du renouveau avec la machine à écrire mécanique. Plus question de faire appel à des procédés analogiques lorsque l’informatique offre un confort ou représente une norme pour l’édition de documents – qu’il s’agisse d’un contexte administratif ou de création.

Ce que l’on appelle parfois la “révolution numérique” est liée à l’émergence d’Internet et du Web, qui a suivi de près l’informatisation de nos vies professionnelles puis personnelles. De nouveaux usages sont apparus mais la gestion des fichiers générés par les traitements de texte n’a pas été immédiatement bouleversée. Cette gestion reste singulièrement la même depuis la feuille et le stylo : chaque nouvelle modification vient écraser ou se superposer à la précédente. Pour le papier cela signifie plusieurs échelles : d’une rature dans l’espace d’écriture jusqu’à la suppression du support – nous renvoyons ici à l’image d’Épinal de la corbeille remplie de boulettes de papier. Avec l’informatique le fichier peut garder trace de l’historique des modifications – certains traitements de texte intègrent d’ailleurs des fonctionnalités avancées quoique relativement difficiles à exploiter –, mais nos usages courants se limitent aux mêmes phénomènes que le papier : l’empilement ou l’écrasement. L’empilement consiste à créer une copie du fichier pour conserver les anciennes versions, ce qui est une fausse bonne idée : le nom de fichier devient vite illisible, intégrant des informations trop complexes à résumer en quelques caractères – mon-fichier-de-travail-V4-relu-par-antoine-VERSION-FINALE-ok-2018-11-02.doc est un classique. L’écrasement est dangereux, le risque étant de faire disparaître des morceaux de texte qui auraient été utiles pour la suite du travail.

La gestion des versions d’un document semble se heurter aux difficultés de conserver un historique – qui est intervenu sur le texte et comment –, mais aussi à la complexité d’être en mesure de ne pas perdre des informations – retrouver une formulation dans une ancienne version. Enfin il s’agit de disposer d’une visibilité globale des phases de modification du fichier. Ce dernier point est important. Comment retrouver la trace des différents changements, d’autant plus lorsque l’on opère à plusieurs, et les visualiser facilement ? Le Web a permis le développement de nouveaux outils, dans le champ de l’édition de documents Google Docs est probablement le plus emblématique. Google Docs intègre une fonction de gestion de versions, il est possible d’identifier des étapes, de figer l’état d’un fichier et revenir à cet état si besoin. Même si cette option est aussi simple à utiliser que limitée en fonctionnalités, elle est peu connue des utilisateurs. Gérer les versions d’un texte est inexistant et compliqué. Pour mieux comprendre l’intérêt d’un tel processus – remplacer l’écrasement ou l’empilement par des enregistrements identifiables –, nous devons détailler les différentes étapes d’un projet de publication.

Dans le cas de l’édition d’un texte, les étapes de travail varient énormément en fonction du domaine concerné. Nous proposons ici un modèle qui peut convenir à différents contextes sans pouvoir être exhaustif. La première étape est la création du projet, il faut comprendre par là la mise en place de l’environnement qui va accueillir les textes et matériaux. Pochette de couleur, casier, dossier informatique, répertoire mail, espace de stockage en ligne, les possibilités sont nombreuses mais ont toutes en commun la délimitation d’un espace plus ou moins matérialisé. Que ce soit un élément matériel ou un environnement informatique, cela nous permet de nous projeter facilement et d’identifier où sont réunis les pièces du projet. La seconde étape est la réception du texte – dans le cas où une première version a été produite par une ou plusieurs autres personnes – ou la création du fichier – s’il s’agit d’un projet partant de zéro. L’espace préalablement définit va pouvoir accueillir le ou les fichiers. Ces deux premières étapes sont parfois fusionnées mais nous devons les distinguer pour prendre la mesure de deux actions : délimiter un travail et créer un contenu.

La troisième étape concerne les actions sur le texte, ainsi que leur signification et leur définition. Travailler sur un texte avec des outils informatiques induit de nombreux enregistrements numériques, ces derniers devenant presque invisibles tant les applications masquent cet acte désormais banal. Les traitements de texte classiques affichent cette option d’enregistrement, certaines interfaces en ligne l’intègrent automatiquement de façon récurrente. Il faudrait probablement ajouter une nouvelle dimension, avec une granularité plus haute que l’enregistrement : la définition d’une session de travail, formant un ensemble en fonction des actions effectuées, comportant plusieurs enregistrements, et peut-être sur plusieurs fichiers différents. Cette suggestion prend tout son sens pour des phases de relecture : après plusieurs interventions sur un ou plusieurs fichiers il serait pertinent de signaler cette phase, et autrement qu’avec un nouveau nom de fichier. Indiquer des modifications avec un même marqueur donne une cohérence dans les démarches proprement humaines et souvent très organisées. Il devient possible de comprendre quelles actions ont été effectuées, à quel moment, par qui et pourquoi.

La quatrième étape est la mise en commun d’une série de modifications par plusieurs personnes. C’est un point délicat à gérer avec les traitements de texte comme Microsoft Word ou LibreOffice Writer, puisque le premier réflexe est de renommer le fichier en conséquence, et le second est d’utiliser des fonctions intégrées à ces logiciels. Dans le premier cas le projet se retrouve vite avec une multitude de fichiers dont les noms deviennent incompréhensibles, dans le second la mise en commun dépend des fonctionnalités d’un logiciel et pose la question de la compatibilité. Les outils en ligne comme Google Docs ont permis de substituer à cette friction une édition commune entre plusieurs personnes. Les rédacteurs d’un document l’écrivent en même temps, et plusieurs options permettent éventuellement d’identifier plus précisément les actions et les personnes. Quoi qu’il en soit, dans une situation où le texte demande des interventions nombreuses et diverses, il y a un enjeu majeur à pouvoir valider certains ajouts sans dépendre de fonctions d’un seul traitement de texte ou d’un service en ligne.

Enfin, une étape souvent écartée est celle de la génération des formats nécessaires au projet. Si un format de traitement de texte – .doc ou .odt – peut suffire, il est probable que le texte doive être fourni dans une autre forme ou un autre format en fonction des objectifs. Le fameux “enregistrer sous” ou le moins pratiqué “exporter” des traitements de texte ou des logiciels en ligne sont censés régler cette question. Pourtant, la matérialisation finale du texte mériterait d’être plus précise, et moins dépendante du traitement de texte ou du service en ligne – pour reprendre les exemples de Microsoft Word, LibreOffice Writer ou Google Docs. Envisager la forme finale d’un texte n’est pas un détail, qu’il s’agisse d’un billet de blog, d’un article, d’un document, d’un livre.

Les cinq étapes que nous avons définies précisent les actions liées au texte, que la démarche originelle soit la création d’un document ou l’édition d’un ouvrage. Ces actions sont trop souvent considérées comme évidentes, comme n’exigeant pas d’être énoncées et expliquées. Les outils fréquemment utilisés ont plusieurs lacunes qu’il est possible de résoudre, d’une part à partir de la liste des étapes d’édition ci-dessus, mais aussi en s’inspirant d’autres domaines. Nous nous proposons de chercher des solutions en dehors du domaine de l’écriture et des traitements de texte – qu’il s’agisse de logiciels relativement classiques ou de services en ligne. Le monde du développement logiciel ouvre plusieurs perspectives en ce qui concerne la gestion d’un fichier, il nous faut déterminer si le texte peut se substituer au code, et présenter plusieurs exemples convaincants.

2. Versionner

Lorsque nous évoquons la question de la gestion d’un fichier, un terme revient systématiquement : le versionnement. Inconnu au dictionnaire français, le versionnement – ou gestion de versions – provient du monde du logiciel, et définit le mécanisme de suivi d’un programme informatique. Il s’applique pour identifier quelles versions d’une application existent et sont disponibles. V1, V2, bêta, date de publication, appellation spécifique, etc., autant de façon d’attribuer une temporalité à des objets numériques en mouvement. Particulièrement utile pour savoir, par exemple et dans le cas d’un utilisateur, si le logiciel est à jour, ou compatible avec d’autres composants informatiques – matériels, systèmes d’exploitation, autres logiciels en lien. Cet élément est également indispensable pour les développeurs qui travaillent à l’évolution d’un programme, pour s’assurer de la bonne version et du cadre de leur intervention – il serait en effet dommageable de résoudre un problème qui a déjà été réglé, ou de créer une fonctionnalité sur une mauvaise base. Le versionnement est donc intrinsèquement lié aux modes de fonctionnement du domaine de l’informatique – de la programmation en général, qu’il s’agisse de logiciels ou de développement web ou applicatif –, et nous devons déterminer s’il peut également s’appliquer à celui de l’édition de documents – articles, livres, etc.

Pour gérer les versions, plusieurs systèmes ont été mis en place, et avec eux des logiciels spécifiques. Certains ont en commun plusieurs concepts inhérents à la gestion de versions : les branches, la proposition de révision, les conflits de modification, la centralisation ou la décentralisation, et l’étiquetage (Wang, s. d.). Ces fonctions donnent des réponses aux problèmes évoqués dans la première partie. Commençons avec les branches, qui comme son nom l’indique est la possibilité de créer différentes voies pour un même projet. Créer une branche revient à isoler une version identifiée d’un programme pour développer une fonctionnalité précise, sans mettre en péril le reste du programme, et surtout pour autoriser d’autres personnes à travailler sans que ce nouveau développement vienne perturber d’autres actions parallèles en cours. Une fois la fonctionnalité en question finalisée, il suffit de la proposer à la branche de départ pour effectuer une fusion. La proposition de révision est une façon de recueillir ces nouvelles interventions sur du code, c’est une fonctionnalité qui constitue le cœur de certains systèmes de gestion de versions. C’est ici que nous pouvons rencontrer des conflits : si une autre personne a continué de travailler sur la version de départ du logiciel, alors il risque d’y avoir des différences entre cette version et celle qui contient la nouvelle fonctionnalité. Il s’agit d’arbitrer entre plusieurs modifications qui s’ajoutent, se contredisent ou s’annulent.

Figure 1 : capture d’écran d’une proposition de modifications sur l’interface GitLab.

Cet arbitrage ne sera pas du même ordre si le projet est centralisé ou décentralisé, c’est-à-dire si toutes les modifications sont réunies au même endroit ou si elles proviennent de dépôts délocalisés – le terme dépôt correspond au lieu où sont rassemblés les fichiers et versions d’un projet. La force d’un système de gestion de versions décentralisé est qu’il peut agréger plusieurs développements en cours depuis différentes intervenants différents. Par ailleurs ces derniers conservent tous l’ensemble des fichiers et de l’historique, ce qui constitue une forme de résilience. Enfin l’étiquetage correspond à la partie la plus visible pour les utilisateurs – qu’ils soient simples usagers ou développeurs contributeurs. Chaque version peut faire l’objet d’une attribution particulière, parmi l’ensemble des sessions d’enregistrement, une peut être identifiée comme l’aboutissement de la V1 d’un programme, par exemple.

Nous pouvons déjà reconnaître dans ces actions d’intervention sur du code des processus qui concernent également l’édition de documents. Rédiger, modifier, valider, créer des espaces de travail, mettre en commun des propositions, etc. Avant de découvrir comment un système de gestion de versions peut être sollicité pour une activité centrée sur le texte et non plus le code, il nous faut comprendre son utilisation dans le domaine de la programmation. Tout d’abord leur première apparition est liée à l’essence même du développement logiciel : il s’agit d’un processus itératif, et cela implique de ne pas se limiter à conserver la dernière version d’un travail, mais également les précédentes pour pouvoir revenir en arrière si nécessaire. Pour les personnes qui écrivent du code cela implique que “la gestion de versions est avant tout une pratique” (Demaree & Brown, 2017, p. 13), et qu’un système de nommage successif ne peut suffire, il faut une méthode et un outil qui la matérialise. L’objectif de ce texte n’est pas de présenter une histoire de ces logiciels de contrôle de versions – versionner les systèmes de gestion de versions paraît toutefois une entreprise originale et très utile dans le cas d’une archéologie de l’informatique –, mais nous pouvons citer quelques cas emblématiques. De nombreux logiciels ont cohabité pendant plusieurs années, avec parfois des approches très différentes, jusqu’à l’arrivée de Git (Chacon & Straub, 2014). Conçu par Linus Torvalds – le créateur du noyau Linux – en 2005 et en quelques semaines pour remplacer un autre logiciel sous licence open source et non libre, Git a bénéficié d’une pluralité de solutions et a pu remédier aux différents défauts de ceux-là. Décentralisé, libre, intelligent, complexe, souple, robuste, ce système a pris une place prépondérante dans le numérique en général et le développement en particulier. Détrônant CVS (Concurrent Versions System) ou BitKeeper, son succès est dû autant à ses qualités qu’aux plateformes web qui l’intègrent pour permettre de partager du code et de travailler à plusieurs. GitHub est le premier ambassadeur de Git, il s’agit d’un moyen de partager du code et de le rendre public et visible via un site web, mais aussi de réunir des contributions diverses. Si Git est décentralisé par nature, il faut une solution pour réunir les différents acteurs d’un même projet, et GitHub propose depuis 2008 un peu plus que cela : un espace de partage de code, des outils de travail en ligne, et la possibilité pour les développeurs de se créer une identité autour de ces activités. Git est désormais un standard si ce n’est une norme.

Si l’écosystème de Git est principalement pensé et utilisé pour du code, il est aussi investi pour des projets de texte, de documentation, de livres (Fauchié & Parisot, 2018). D’abord initiés par des développeurs pour des livres techniques, des blogs, des manuels ou de la documentation – sous l’appelation documentation as code (Web en Vert, 2016) –, ce sont aussi des éditeurs qui ont fait le choix d’employer des méthodes et des outils issus du domaine de l’informatique pour mener des projets de livres ou d’articles. Si l’étonnement peut être la première réaction, nous comprenons rapidement les raisons de tels choix, et pour faciliter cette préhension nous nous proposons de plonger dans quelques exemples représentatifs. Le premier est une revue scientifique dans le domaine du machine learning, il s’agit de Distill (https://distill.pub/), lancée officiellement en 2017 (Rosenthal, 2017). La parcours d’édition des articles est basé sur Git : dépôts de papiers, avis du comité éditorial, propositions de modifications, révisions diverses. Chaque commit – dans Git un commit correspond à un enregistrement lié à une tâche spécifique – identifie une action dans l’activité éditoriale de la revue. Distill propose un modèle pour chaque article, et les chercheurs qui souhaitent soumettre un article sont obligés de passer par Git et la plateforme GitHub. Les éditeurs et le comité éditorial pratiquent également ce système de gestion de versions pour suivre le travail, modifier le texte puis le valider. L’intérêt est triple¹ : disposer d’un procédé transparent divulguant les coulisses de la recherche scientifique ; appliquer les méthodes du développement informatique à un domaine proche qu’est le machine learning ; automatiser la mise en ligne des articles via l’utilisation de Git. Cet exemple ouvre de nombreux questionnements que nous n’aborderons pas ici, dont la pérennité, la citabilité ou encore la légitimité.

Le second exemple est la chaîne de publication du département numérique de Getty Publications, la maison d’édition du musée The Getty. Depuis plusieurs années une petite équipe a mis en œuvre une ambitieuse chaîne d’édition (Evan Lan, 2016) basée sur trois grands principes : la pérennité, l’interopérabilité et la multiformité, afin de produire des livres numériques et imprimés à partir d’une même source. La gestion de versions est venue s’insérer naturellement dans l’assemblage des briques techniques issues du développement web. Le point commun de Quire – la chaîne de publication inventée par Getty Publications – avec Distill est cette volonté de transparence : chaque modification est visible en ligne sur la plateforme GitHub, et ouverte à des contributions extérieures. Il est ainsi possible de découvrir que le catalogue Ancient Lamps in the J. Paul Getty Museum a connu plusieurs révisions mineures le 25 octobre 2018. Cette information est publique mais surtout utile aux éditeurs de l’ouvrage, Git implique une discipline – en partie à l’œuvre dans le domaine de l’édition – qui consiste à distinguer différentes phases – la réception d’un texte, sa relecture, ses corrections, etc. Le versionnement offre par ailleurs la possibilité de retracer l’historique des modifications depuis la création.

Figure 2 : capture d’écran de la visualisation de différences pour un catalogue de Getty Publications dans l’interface de GitHub.

La puissance des logiciels de contrôle de versions et de Git en particulier dépend d’une méthodologie précise et complexe que nous ne pouvons pas détailler ici mais qui peut s’apprendre par la pratique. L’écriture d’un mémoire avec Git (Fauchié, 2018) a été une expérience d’apprentissage autant qu’une expérimentation d’écriture dans un environnement programmatique – finalement proche de l’édition en terme de méthodes plus que d’outils. Penser et travailler en versions ne nous aide pas seulement à comprendre comment un projet évolue au fil du temps, mais nous donne aussi notre mot à dire sur ce processus d’évolution.

3. La dimension de système

Un système de gestion de versions est une réponse cohérente pour des projets d’édition, et non plus uniquement pour le suivi du développement de programmes. En plus d’aborder des exemples de mise en pratique dans la seconde partie, nous précisons ici quelques modalités d’emploi dans des cas d’utilisation éditoriale. Il faut toutefois noter quelques limites à cette forme de détournement, car les logiciels de contrôle de versions et Git en particulier ont été pensé pour un usage spécifique, et le texte présente quelques singularités par rapport au code. Enfin, une nouvelle dimension est introduite par le biais de cette nouvelle pratique : le processus d’édition n’est plus une chaîne mais un système.

Que ce soit la revue Distill, le workflow Quire ou l’exemple de la rédaction d’un mémoire, nous détaillons plusieurs points de méthode pour insister sur l’intérêt d’un système de gestion de versions. Nous avons déjà évoqué le commit, cette phase d’enregistrement correspondant à une série de modifications autour d’une même action. Une pratique courante dans le domaine du développement logiciel est de créer des commits atomiques (Jouannic, 2013) : c’est-à-dire, dans le cas d’un travail éditorial, de structurer le plus finement possible chaque intervention sur un texte. Chaque commit est ainsi une unité de travail bien identifiée et surtout bien identifiable une fois qu’elle a été réalisée. Cela facilite la compréhension des tâches réalisées et un éventuel retour en arrière. Ensuite les branches dont nous avons fait une explication très rapide s’avère un formidable outil. Git permet de créer des branches comme des versions de travail parallèles, isolant plusieurs processus en cours et ouvrant des fonctionnalités de synchronisation – une version parallèle peut bénéficier de développements en cours dans une autre branche, sans attendre la fin de ces développements, et cela d’un côté comme de l’autre. En pratique cela signifie que deux relecteurs peuvent intervenir sur un même texte soit en même temps de façon asynchrone – pour ensuite réunir leurs propositions –, soit de façon successive afin de limiter le temps de travail. Autre exemple : pendant qu’un relecteur intervient sur un contenu, un designer peut également modifier la structuration, pour ensuite fusionner leurs activités. C’est ici qu’intervient une autre fonctionnalité tout aussi puissante que complexe, la gestion des conflits via la proposition de révisions. Une branche contient des commits, une fois une phase terminée (réécriture, relecture, traduction), cette branche va être proposée à la version principale du projet – souvent appelé “master”. La personne en charge de la validation de la proposition peut examiner les commits – qui contiennent un court texte descriptif, utile en plus des modifications elles-mêmes –, et valider ou ré-intervenir sur les contenus concernés. La branche sera ensuite fusionnée et donc intégrée. Et ainsi de suite.

Hormis le degré d’abstraction nécessaire et la barrière technique non négligeable pour s’accaparer ce nouvel environnement, ce fonctionnement semble bien s’appliquer au domaine du texte. Pourtant il y a certaines limites que nous devons expliciter. La principale distinction avec le code est la granularité : un programme comporte de nombreuses lignes, il est structuré de façon à être le plus compréhensible par un humain, même s’il est écrit pour une machine. Il y a relativement peu de caractères sur une même ligne, en tout cas beaucoup moins qu’un paragraphe ou même qu’une ligne de texte. Pourquoi évoquer ce point très technique ? Tout simplement parce qu’un système de gestion de versions s’intéresse aux modifications à l’intérieur d’une ligne, ce qui correspond à la rédaction de code, moins à celle de textes. Pour palier à cette limite, une des recommandations de l’usage de Git appliqué au texte est d’effectuer un saut de ligne à la fin de chaque phrase, la figure 3 présente ainsi plusieurs modifications sur le présent article, chaque phrase occupant une ligne distincte.

Figure 3 : capture d’écran d’une visualisation de différences entre deux commits dans l’interface GitLab.

Git s’utilise originellement avec un terminal, il s’agit d’une console virtuelle qui permet d’appeler des commandes comme l’ajout d’un commit et son texte descriptif, ou l’envoi des commits sur un dépôt centralisé. Utiliser un terminal requiert des connaissances spécifiques, une précision importante et beaucoup de pratique. Heureusement des interfaces graphiques simplifient l’usage de Git, soit sous la forme de logiciels sur l’ordinateur de l’utilisateur, soit par le biais de plateformes en ligne.

Git n’est pas simplement un modèle et un outil à appliquer à l’univers des documents et du livre, avec quelques incompatibilités ou des contraintes soulignées ci-dessus. Ce système de gestion de versions apporte une nouvelle dimension à l’activité éditoriale :

Quand nous gérons notre travail à l’échelle du commit, nous sommes encouragés à penser au-delà de l’état actuel de notre travail et à envisager celui dans lequel il était hier, et dans lequel il sera demain. En écrivant des messages de commit, en choisissant ce que nous voulons inclure dans un commit, nous sommes amenés à réfléchir à la description de nos actions au moment même où nous agissons. Et c’est ainsi qu’on adopte une position plus réfléchie et plus pondérée de notre travail.
(Demaree & Brown, 2017, p. 123)

La description des actions, l’anticipation de leur compréhension par d’autres membres d’une équipe, la nécessité de penser en mouvements atomiques dans l’objectif d’une vue d’ensemble des différentes phases, ces éléments convergent pour constituer non plus une chaîne, mais un système. Le simple fait de décrire chaque série d’actions ouvre des perspectives nouvelles, chaque commit peut être isolé et réutilisé à n’importe quel moment, nourrissant le projet non plus dans une linéarité mais dans un ensemble fait d’éléments en interactions entre eux. Entre eux ne consiste pas qu’en un lien entre l’action précédente et l’action suivante, mais une action précédente et une action suivante qui s’inscrivent dans un ensemble.

Là où l’objet a presque toujours une forme et des frontières fixes, la cohérence d’un système peut être altérée dans le temps et dans l’espace, et son comportement déterminé à la fois par des conditions externes et par ses mécanismes de contrôle. (Burnham, Haacke, Quinz, & Jones, 2015, p. 63)

En substituant le concept d’objet par celui de chaîne, nous soulignons combien Git amène une forme de malléabilité dans le processus d’édition. Les phases qui composent ce processus peuvent être réversibles – chaque action étant identifiée et commentée –, en lieu et place d’étapes uniquement liées à la précédente et à la suivante. Les humains qui œuvrent avec les programmes (Fétro, 2017) gagnent en flexibilité, s’appropriant les outils numériques sans en être soumis.

Conclusion

Versionner un texte avec les méthodes et les outils du développement logiciel est donc possible, Git se prête à des pratiques éditoriales, sans pour autant s’abstraire de plusieurs contraintes identifiées ici. Il s’agit même d’une opportunité pour modifier la façon d’écrire, d’éditer et de publier, qu’il s’agisse de documents, d’articles ou de livres. Les non-développeurs peuvent s’emparer de Git (GitHub, 2018).

Git nous engage par ailleurs à redéfinir d’autres pratiques que la seule gestion des fichiers dans un processus éditorial. Se passer de traitement de texte pour faciliter la rédaction et la structuration de contenu est un exemple. Les langages de balisage léger, eux aussi originaires du domaine de l’informatique, ont été créés pour faciliter la rédaction de documents numériques tout en distinguant les contenus – et leur structuration – de leur mise en forme. Un langage de balisage léger comme Markdown est un format texte lisible par des humains et des programmes, et qui s’insère parfaitement dans un workflow utilisant Git. Il devient alors très facile de comprendre les interventions sur un texte, contrairement à un traitement de texte qui crée une confusion entre structuration et mise en forme, ou entre modification et validation.

Le second point qui résulte des trois parties de ce texte est la nécessité d’apprendre à comprendre le fonctionnement de Git. Il s’agit de déplacer certains savoir-faire, par exemple d’un traitement de texte à l’utilisation d’un langage de balisage léger et d’un logiciel de contrôle de versions. Les auteurs, et plus particulièrement dans le domaine académique, doivent maîtriser certains usages dans la rédaction de leurs écrits (Vitali-Rosati, 2018). C’est également le cas, pour des professionnels de l’édition, dans bien d’autres domaines. La manière d’appréhender l’écriture et la publication a des conséquences directes sur la diffusion du savoir (Stern, Guédon, & Jensen, 2015).

Enfin, Git ouvre une perspective que nous n’avons pas encore abordée : le déploiement. Dans le fonctionnement de ce système de gestion de versions, chaque commit est identifiable, paramètre qui peut être cumulé avec la branche à laquelle il est rattaché. Aujourd’hui des applications sont en mesure de déclencher des actions en fonction de ces commits – et donc aussi en fonction de sa branche. Cela signifie qu’à chaque enregistrement d’une série de modifications, il est possible de lancer une opération sur plusieurs fichiers, par exemple en transformant le fichier source en un format d’export. Dans le domaine du développement informatique nous appelons cette pratique développement continu. Un texte peut ainsi être automatiquement transformé en une version web, un PDF ou un format XML à chaque nouveau commit.

Déployer un texte, voilà un horizon stimulant pour le domaine de la publication en général, et celui de l’édition en particulier.

Bibliographie

Beams, C. (2014, août 31). How to Write a Git Commit Message. Consulté le 30 avril 2018, à l’adresse https://chris.beams.io/posts/git-commit/

Burnham, J., Haacke, H., Quinz, E., & Jones, C. A. (2015). Esthétique des systèmes. Dijon, France: les Presses du réel.

Chacon, S., & Straub, B. (2014). Pro Git. Berkeley, Etats-Unis d’Amérique.

Comparison of version control software. (2018). In Wikipedia. Consulté à l’adresse https://en.wikipedia.org/w/index.php?title=Comparison_of_version_control_software&oldid=870920930

Dehut, J. (2018, janvier 23). En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation [Billet]. Consulté le 29 mars 2018, à l’adresse https://eriac.hypotheses.org/80

Demaree, D., & Brown, M. (2017). Git par la pratique. (A.-S. Gagnié Fradier, Trad.). Paris, France: Eyrolles.

Evan Lan, R. (2016, mai 16). An Editor’s View of Digital Publishing. Consulté le 30 avril 2018, à l’adresse http://blogs.getty.edu/iris/an-editors-view-of-digital-publishing/

Fauchié, A. (2017, janvier 23). Publier des livres avec un générateur de site statique. Consulté le 30 avril 2018, à l’adresse https://jamstatic.fr/2017/01/23/produire-des-livres-avec-le-statique/

Fauchié, A. (2018a). Vers un système modulaire de publication. Mémoire sous la direction de Masure, A. & Marcello Vitali-Rosati, M. Consulté le à l’adresse https://memoire.quaternum.net/

Fauchié, A. (2018b, juin 4). Un mémoire en dépôt. Consulté le 15 décembre 2018, à l’adresse https://www.quaternum.net/2018/06/04/un-memoire-en-depot/

Fauchié, A., & Parisot, T. (2018). Repenser les chaînes de publication par l’intégration des pratiques du développement logiciel. Sciences du Design, n° 8(2), 45‑56.

Fétro, S. (2017). Œuvrer avec les machines numériques. Back Office, (1). Consulté le à l’adresse http://www.revue-backoffice.com/numeros/01-faire-avec/sophie-fetro-oeuvrer-machines-numeriques

Figer, J.-P. (2009). L’accumulation du logiciel : de la programmation à « l’informatique dans les nuages » [cloud computing]. Annales des Mines - Réalités industrielles, Mai 2009(2), 36‑41. https://doi.org/10.3917/rindu.092.0036

GitHub. (2018). Empowering non-developers to use Git - Git Merge 2018. Consulté à l’adresse https://www.youtube.com/watch?v=pY5i0Io86UQ&feature=youtu.be

Guichard, É. (2014). L’internet et les épistémologies des sciences humaines et sociales. Revue Sciences/Lettres, (2). https://doi.org/10.4000/rsl.389

Jouannic, T. (2013, juillet 9). Pour arrêter de galérer avec Git. Consulté le 30 avril 2018, à l’adresse http://www.miximum.fr/blog/enfin-comprendre-git/

Les machines (3/5) : Merveilleuses bécanes. (s. d.). France Culture. Consulté à l’adresse https://www.franceculture.fr/emissions/les-nouvelles-vagues/les-machines-35-merveilleuses-becanes

Lodato, M. (s. d.). Une Référence Visuelle de Git. Consulté le 30 avril 2018, à l’adresse https://marklodato.github.io/visual-git-guide/index-fr.html

Mozzadrella, V. (2017, juin 13). How to grade programming assignments on GitHub. Consulté le 30 avril 2018, à l’adresse https://blog.github.com/2017-06-13-how-to-grade-programming-assignments-on-github/

Rosenthal, D. (2017, mai 2). Distill: Is This What Journals Should Look Like? Consulté le 1 juin 2018, à l’adresse https://blog.dshr.org/2017/05/distill-is-this-what-journals-should.html

Simondon, G. (2012). Du mode d’existence des objets techniques. Paris, France: Aubier, impr. 2012.

Stern, N., Guédon, J.-C., & Jensen, T. W. (2015). Crystals of Knowledge Production. An Intercontinental Conversation about Open Science and the Humanities. Nordic Perspectives on Open Science, 1(0), 1‑24. https://doi.org/10.7557/11.3619

Vitali-Rosati, M. (2018, mars 11). Les chercheurs en SHS savent-ils écrire ? Consulté le 20 mars 2018, à l’adresse http://theconversation.com/les-chercheurs-en-shs-savent-ils-ecrire-93024

Wang, W. (s. d.). Explain Git with D3. Consulté le 30 avril 2018, à l’adresse https://onlywei.github.io/explain-git-with-d3/

Web en Vert. (2016). Documentation as code (expliqué à mon père) — Hubert Sablonnière. Consulté le à l’adresse https://www.youtube.com/watch?v=1rKgVF5CEEY