Émission Libre à vous ! du 29 novembre 2022

Titre : Émission Libre à vous ! du 29 novembre 2022

Intervenant·e·s : Vincent Calame - à la régie

Lieu : Radio Cause Commune

Date : 29 novembre 2022

Durée : 1 h 30 min

Podcast PROVISOIRE

Page des références de l'émission

Licence de la transcription : Verbatim

Illustration : Déjà prévue

NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.

Transcription = Eve OK

Voix off : Libre à vous !, l’émission pour comprendre et agir avec l’April, l’association de promotion et de défense du logiciel libre.

Frédéric Couchet : Bonjour à tous, bonjour à toutes.

Les logiciels de gestion de versions décentralisée, les forges logicielles : on évoque souvent ces termes dans les émissions Libre à vous. Et bien, ce mardi, ce sera le sujet principal de l'émission. Avec également au programme la chronique de Vincent Calame sur « Sobriété énergétique et sobriété numérique » et aussi, en fin d'émission, la chronique de Luk : « Où sont nos génies du business ? ».

Soyez les bienvenus pour cette nouvelle édition de Libre à vous, l'émission qui vous raconte les libertés informatiques, proposée par l'April, l'association de promotion et de défense du logiciel libre.

Je suis Frédéric Couchet, le délégué général de l'April.

Le site web de l’émission est libreavous.org. Vous pouvez y trouver une page consacrée à l’émission du jour, avec tous les liens et références utiles, et également les moyens de nous contacter. N’hésitez pas à nous faire des retours ou à nous poser toutes questions.

Nous sommes mardi 29 novembre 2022. Nous diffusons en direct. Vous écoutez peut-être une rediffusion, un podcast. À la rédaction de l'émission, c'est sa première régie en solo, sans filet de sécurité, il va assurer comme un pro : c'est Thierry Holleville, bénévole à l'April. Bonjour, Thierry.

Thierry Holleville : Bonjour à tous.

Frédéric Couchet : Nous vous souhaitons une excellente écoute.

[Jingle]

Chronique « Le libre et la sobriété énergétique » de Vincent Calame, bénévole à l’April, « Sobriété énergétique et sobriété numérique » = Eve

Frédéric Couchet : Nous allons commencer par la chronique de Vincent Calame, informaticien libriste et bénévole à l’April. Cette saison, Vincent propose des chroniques sur le thème du Libre et la sobriété énergétique. Le chapitre aujourd'hui est intitulé « Sobriété énergétique et sobriété numérique ». Bonjour Vincent.

Vincent Calame : Bonjour Fred. Pour explorer le lien entre logiciel libre et sobriété énergétique, j’ai fait appel à une source précieuse, « Libre à lire », le site des transcriptions réalisées par le groupe Transcription de l’April. Le site propose plus de mille transcriptions de multiples origines : les émissions de Libre à vous! bien sûr, des conférences, des tables rondes, d’autres émissions de radio, etc., avec une grande variété dans les personnes intervenantes et les propos retranscrits. Bref, c’est un bon aperçu des débats qui traversent la sphère du libre francophone.

L’autre intérêt, c’est qu’il s’agit, dans la grande majorité des cas, de la retranscription d’une parole spontanée (pas comme ma chronique qui est écrite à l’avance…). Autrement dit, le vocabulaire utilisé est bien représentatif des préoccupations des personnes et de leur appropriation de tel ou tel thème. Je veux dire par là que dans un texte écrit, je peux placer facilement des concepts ronflants, cela ne veut pas dire pour autant que je les maitrise et que je les utilise réellement pour structurer ma pensée et mes actions. Une transcription orale est beaucoup plus révélatrice de ce point de vue.

Frédéric Couchet : Rappelons que l’adresse exacte est www.librealire.org. Et qu’a donné ta recherche sur le terme « sobriété énergétique » ?

Vincent Calame : Pour tout dire, la moisson a été maigre : huit articles à ce jour et, en enlevant mes propres chroniques, cela fait quatre transcriptions. En soi, ce n’est pas surprenant. Si le concept « sobriété énergétique » peut prétendre au titre d’expression de l’année, à cause, malheureusement, de la guerre en Ukraine, il n’était jusqu’à présent utilisé que dans certains cercles.

Sur ces quatre transcriptions, il y a deux émissions de Libre à vous! (un peu d’auto-congratulation...), une émission de France Inter sur la 5G et une conférence sur une monnaie libre. À chaque fois, le terme « sobriété énergétique » n’est utilisé qu’une seule fois dans la discussion, ce qui ne rend pas ces transcriptions moins pertinentes.

Je vais particulièrement m’attarder sur la première mention de « sobriété énergétique » qui date de 2019 : il s’agit de l’émission n° 36 de Libre à vous! sur l’obsolescence programmée que j’avais déjà évoqué dans ma chronique précédente intitulée « Longue vie aux objets ». Les invités de cette émission étaient Adèle Chasson, de l’association HOP (Halte à l’Obsolescence Programmée), et Frédéric Bordage, du collectif GreenIt.fr. Le sujet était porté par l’actualité du projet de loi pour une économie circulaire.

J’en ai retenu deux points éclairants :

Premier point, Adèle Chasson a rappelé qu’il y avait trois types d’obsolescence : l’ obsolescence technique, l’ obsolescence esthétique et l’obsolescence logicielle. L’obsolescence logicielle est la plus sournoise, c’est par exemple une mise à jour qui surcharge le téléphone de fonctions superflues qui le ralentisse jusqu’à le rendre inutilisable. C’est aussi la plus compliquée à expliquer et c’est celle qui rentre en résonance directe avec les combats du logiciel libre pour la maitrise de nos ordinateurs.

Deuxième point, les objets connectés vont poser encore plus le problème d’obsolescence logicielle. Or ceux-ci sont un des arguments du passage à la 5G comme le rappelle une des autres transcriptions, celle d’un débat sur France Inter. Je cite Frédéric Bordage dans l’émission de Libre à vous! : « On s’attend à un tsunami d’objets connectés, jusqu’à plus de 65 milliards d’objets connectés d’ici quelques années ». Pas besoin de faire un dessin pour comprendre le défi que cela va poser en termes de sobriété énergétique.

Je ne sais pas ce qu’a donné la suite des débats sur le projet de loi mais en tout cas, ce concept « d’ obsolescence logicielle » est à retenir dans le lexique du libre et de la sobriété énergétique.

Frédéric Couchet : si possible, à placer ici, quelques infos sur la suite du projet de loi…)

> Et tu as fait d’autres recherche ?

Vincent Calame : Oui, j’ai également fait « transition énergétique » qui donne 9 articles dont le plus ancien date de 2017. Mais la recherche la plus fructueuse a été celle sur le simple mot de « sobriété » avec plus de trente références. Pour l’anecdote, la mention la plus ancienne de « sobriété » date de 2015 et l’intervenant qui l’utilise a encore une vision négative de la sobriété puisqu’il dit en parlant de la déconnexion, je cite : « je ne suis pas en train de prôner l’abstinence et la sobriété ». Cette connotation négative disparaît par la suite et le plus intéressant, c’est l’utilisation de sobriété pour forger un autre concept : celui de « sobriété numérique ».

« sobriété numérique » et « sobriété énergétique », cela sonne proche, n’est-ce pas ? Je vous proposer de nous retrouver la semaine prochaine dans la deuxième partie de cette chronique pour approfondir la question.

Les logiciels de gestion de versions décentralisés et les forges logicielles, avec Cécilia Bossard développeuse à Code Lutin et Nicolas Chauvat fondateur et dirigeant de Logilab = MO

Frédéric Couchet : Nous allons poursuivre par le sujet principal qui va être consacré aujourd’hui aux logiciels de gestion de versions décentralisés et aux forges logicielles. On évoque souvent ces termes dans les émissions Libre à vous !, eh bien aujourd’hui on va en parler un petit en détail. Je précise que ce n’est qu’une première émission, nous n’allons pas forcément rentrer dans les détails techniques, je préviens les personnes les plus expertes, on va surtout s’adresser aux personnes qui n’ont jamais entendu parler de ces outils.

N’hésitez pas à participer à notre conversation. Pour cela vous pouvez venir sur le salon web dédié à l’émission, sur le site causecommune.fm, bouton « chat », salon #libreavous. Vous pouvez même appeler au téléphone au 09 72 51 55 46.

Nos deux invités. Au téléphone nous avons de la société Code Lutin et j’ai en face de moi Nicolas de la société Logilab. On va commencer tout simplement par une petite question de présentation personnelle pour savoir qui vous êtes. On va commencer par Cécilia Bossard. Cécilia à toi.

Cécilia Bossard : Bonjour à tous. Je m’appelle Cécilia Bossard. Je suis développeuse chez Code Lutin. Je fais aussi partie de l’association Duchess France, une association de promotion des femmes dans les métiers techniques du développement et, quand j’ai un pu le temps, j’aime bien aussi apprendre aux enfants à programmer, tout bonnement. Voilà à peu près pour mes activités.

Frédéric Couchet : D’accord. Je suppose que ces ateliers c’est dans le cadre de Coding Goûters.

Cécilia Bossard : C’est ça. Coding Goûters et Devoxx4Kids, deux petits ateliers différents d’ailleurs.

Frédéric Couchet : Nous mettrons les références sur le site de l’émission du jour et on a déjà parlé des Coding Goûters, je ne sais plus dans quelle émission vous chercherez sur Libreavous.org, il y a quelques années, il y a trois ou quatre ans. Je précise que Duchess c’est duchess-france.org. On a eu l’occasion de recevoir déjà plusieurs Duchess dans l’émission.
En face de moi Nicolas Chauvat. Nicolas qui es-tu ?

Nicolas Chauvat : Bonjour à tous. Je m’appelle Nicolas Chauvat. Je suis ici aujourd’hui parce que je suis tombé dans l’informatique quand j’étais petit et ensuite dans Internet, le Web et les logiciels libres pendant mes études, ce qui fait déjà un certain temps, puisque j’ai vu, en écoutant l’émission de la semaine dernière, que je suis né pas longtemps après Cécile Duflot.
Je suis fondateur et dirigeant de Logilab, que je définirais comme une entreprise libérée, âgée d’un peu plus de 20 ans. Nous faisons de l’informatique, du logiciel libre et du Web. La raison qui fait que je suis invité aujourd’hui est que nous avons, entre autres, contribué au développement de Mercurial qui est un outil de gestion de version. Nous avons développé notre propre forge à une époque et aujourd’hui nous soutenons le développement de Heptapod qui est un fork amical de GitHub..

Frédéric Couchet : Merci Nicolas pour cette présentation. En plus, tu commences fort parce que tu places plusieurs mots-clés qu’il faudra expliquer dans le cours de l’émission. On ne va pas les expliquer tout de suite, mais rassurez-vous, on va vous les expliquer évidemment parce que l’objectif de l’émission du jour, de présenter un peu ce principe de logiciels de versions décentralisé et puis les forges logicielles dont on parle assez régulièrement dans l’émission mais sans jamais être rentrés dans les détails.
On va commencer par une première question parce que ces outils sont principalement utilisés pour le code source de logiciels. Comme première question j’ai envie de demander à Cécilia, par exemple, de nous dire ce qu’est un code source et pourquoi on a besoin, finalement, de logiciels de version de codes sources ?

Cécilia Bossard : Il faut voir le code source un peu comme une recette de cuisine. En tant que développeur on va écrire une recette que l’ordinateur va exécuter. Mais l’ordinateur est un cuisinier un peu bête, il va appliquer les instructions à la lettre, donc on va lui donner une recette très détaillée, c’est ce qu’on va appeler le code source, toutes les lignes de code qu’on peut taper pour que l’ordinateur exécute ce qu’on veut qu’il fasse.
Cette recette peut être vraiment très complexe et nécessite que plusieurs personnes interviennent pour la rédiger. C’est là où on va avoir besoin, justement, de ces logiciels de gestion des versions pour qu’on puisse agréger tous les petits ajustements que les uns et les autres vont pouvoir faire sur le code. Puis parfois on fait des bêtises, donc on a besoin de revenir en arrière. Ce logiciel va nous aider à pouvoir avoir un truc propre et savoir où on en est exactement, ce qui fonctionne et ce qui ne fonctionne pas.

Frédéric Couchet : Avant de poser une question à Nicolas, tu as dit « on peut faire des bêtises ». Souvent, le terme de « bêtises » est connoté négativement, pas forcément tout le temps. Que signifie « on peut faire des bêtises » quand on développe un logiciel ?

Cécilia Bossard : On peut faire beaucoup de bêtises différentes. Déjà il y a les bugs, on fait des erreurs, on a mal compris ce qu’il fallait faire et ça ne fonctionne pas comme ça devrait ou il y a des petits problèmes techniques qui font que ça fonctionne pas comme on voudrait. On peut faire des erreurs de compréhension sur ce qu’on voulait que le logiciel fasse, il faut revenir en arrière et échanger parce que ça ne fait pas ce que c’est censé faire. On peut écraser des ??? [ 19 min 07]

Frédéric Couchet : D’accord. Les bugs font partie des bêtises des informaticiens et des informaticiennes.
Si je comprends bien la comparaison, finalement un code source c’est un texte qui va avoir des évolutions.

Nicolas a dit tout à l’heure qu’il avait à peu près le même âge que Cécile Duflot, donc il est un peu plus jeune que moi, il a quand même quelques années de développement derrière lui, Cécilia a aussi, je crois, quelques années de développement derrière elle. Nicolas, si tu veux compléter l’introduction de Cécilia sur le code source et peut-être aussi un petit historique sur les outils, avant qu’on parle des outils d’aujourd’hui qui sont des logiciels de version décentralisés. Nicolas Chauvat.

Nicolas Chauvat : Tu nous as demandé d’essayer de faire des descriptions les moins techniques possible pour que la majorité des auditeurs puisse découvrir ce sujet-là.
Je continue à développer, en effet, même si je suis le dirigeant de l’entreprise. Je dis souvent aux gens qui ne connaissent pas du tout mais qui veulent s’intéresser que mon métier c’est d’écrire. Ça peut leur paraître un peu bizarre, mais quand on fait des propositions commerciales, quand on discute avec les gens, quand on parle de ce qu’on fait ou quand on écrit des articles pour parler de ce qu’on fait, on se retrouve à écrire du français ou de l’anglais. Quand on écrit des programmes, on écrit à destination des ordinateurs et, comme l’expliquait Cécilia, il faut être extrêmement précis parce que les ordinateurs sont complètement bêtes, donc ils vont faire exactement ce qu’on leur dit, ce qui veut dire que, parfois, il faut s’y prendre à plusieurs pour être suffisamment précis et qu’on arrive à leur dire exactement ce qu’on veut.

Je considère que mon métier c’est d’écrire et ça veut dire que pour le faire efficacement il faut se doter d’outils qui fonctionnent bien pour ça et pour gérer le fait que, comme le disait Boileau, « il faut toujours remettre l’ouvrage sur le métier », donc écrire un logiciel c’est écrire de nombreuses versions du logiciel, d’autant que parfois ça prend du temps de savoir exactement ce qu’on veut que le logiciel fasse, donc à chaque fois on écrit une nouvelle version au fur et à mesure que le besoin se précuise.

Je pense que la plupart des auditeurs ont déjà utilisé un traitement de texte, on va parler de LibreOffice parce qu’on va parler de logiciel libre. Dans LibreOffice il y a une fonctionnalité qui s’appelle « Suivi des modifications » ; peut-être que bon nombre d’auditeurs ont déjà utilisé le suivi des modifications dans LibreOffice, l’ont activé, ont fait des modifications, ont transmis le document à quelqu’un d’autre et ont dit à cette personne « regarde les modifications que j’ai apportées au document ». Il faut imaginer que les systèmes de gestion de version dont on va parler c’est cette fonctionnalité-là sous stéroïdes très puissants.

Frédéric Couchet : Sous stéroïdes quasiment, mais stéroïdes autorisés.

Nicolas Chauvat : Autorisés !

Frédéric Couchet : D’accord !
On va parler un petit peu d’historique, on est d’une génération assez proche. Avant de parler des outils décentralisés, au tout départ on a bien compris l’importance de travailler en équipe sur laquelle on reviendra un petit peu après, mais il y a peut-être aussi, au départ, des gens qui développaient tout seuls dans leur coin. Au départ est-ce que les outils étaient déjà décentralisés, ou est-ce que c’étaient des outils beaucoup plus « simplifiés », entre guillemets. Qui veut répondre sur cette partie-là ? Cécilia ou Nicolas ?

Cécilia Bossard : À l’origine les outils ne géraient pas énormément de fichiers. L’historique était sur un seul gros fichier, on ne pouvait pas trop collaborer, c’était assez compliqué, c’était un peu comme si on mettait un verrou sur un fichier : une personne modifiait le fichier et les autres ne pouvaient pas trop le modifier pendant ce moment-là, en même temps.

Il faut savoir que ces logiciels de versions de code source datent quand même des années 70, ce n’est pas quelque chose d’hyper-récent. C’est quelque chose qui est arrivé quand même assez rapidement avec l’avènement de la programmation logicielle. On bloquait un fichier, puis on a réussi à faire plusieurs évolutions, on changeait plusieurs fichiers en même temps avec différents utilisateurs. Je ne sais pas si Nicolas veut rajouter autre chose.

Frédéric Couchet : Il va rajouter. Je vais juste préciser que volontairement on ne va pas citer trop de noms de logiciels aujourd’hui. Les personnes les plus expertes savent sans doute à quels logiciels on fait référence. C’est volontaire, on va mettre les références sur la page de l’émission, si vous voulez vous renseigner sur l’historique, on ne va pas vous noyer avec plein de noms de logiciels.

Si je comprends bien et je vais demander à Nicolas de préciser ou de compléter, au tout départ on pouvait, avec ces outils, travailler avec un seul fichier et, quelque part, tout seul, parce qu’on mettait, comme le dit Cécilia, un verrou empêchant toute autre personne de le modifier. Ensuite on a pu modifier plusieurs groupes de fichiers et ensuite plusieurs groupes de fichiers en parallèle. C’est ça l’évolution de ces systèmes de logiciels de gestion de version ? Nicolas Chauvat.

Nicolas Chauvat : Oui. Je suis d’accord avec ce que vient de décrire Cécilia. Au début, les outils ont permis de gérer l’historique. Si on veut donner une définition rapide, ça veut dire qu’on ouvre le fichier, on le modifie, on le sauve, quand on appuie sur le bouton « sauver » ; on va dire que ça c’est une version. Après on le modifie à nouveau, on fait d’autres changements, on le sauve, on dit que c’est une autre version. L’historique c’est la succession de toutes ces versions du fichier, donc d’une version à l’autre, le texte change un petit peu ou beaucoup.

Au début les outils permettaient de gérer l’historique d’un seul fichier. Après, les outils ont permis de gérer l’historique de plusieurs fichiers. Le besoin suivant c’était de gérer l’historique de changements concomitants dans plusieurs fichiers, c’est-à-dire qu’on a un groupe de fichiers, mais le changement dans le premier fichier n’a de sens que s’il est associé au changement dans le deuxième fichier, donc il fallait que le changement enregistré, la version, concerne les modifications des deux fichiers. Ensuite, comme l’écriture d’un logiciel est un processus de collaboration, il y a des modalités d’échange de ces modifications. Je disais tout à l’heure qu’on veut le suivi des modifications sous LibreOffice, mais sous stéroïdes, ça veut dire qu’on ne passe par le courrier électronique pour se les échanger, ce n’est pas ce qui marche le mieux, on peut faire plus efficace que ça, donc des outils qui ont permis l’échange des modifications. Et puis aujourd’hui, toujours pour faciliter la collaboration parce qu’il y a une phase de mise au point qui est à distinguer d’une phase où le texte est plus figé parce qu’on est content de ce qu’on a écrit, les outils plus avancés permettent de gérer l’historique de l’historique. On peut avoir plusieurs personnes qui travaillent en même temps sur des changements en cours qui ne sont pas finalisés et qui s’échangent les changements sur les changements en gros. Ça demande un petit peu d’habitude pour le maîtriser correctement, mais quand on a cet outil-là à disposition, qu’on fait ça toute la journée et qu’on veut avancer vite à plusieurs, c’est très avantageux de pouvoir travailler comme ça.

Frédéric Couchet : Waouh !
Peut-être deux remarques ou questions par rapport à l’exemple des suivis de modifications dans LibreOffice. L’un des risques potentiels, au-delà du fait que ce ne soit pas concomitant, qu’il faut attendre que quelqu’un modifie, une personne peut écraser des modifications d’une autre et, finalement, on se retrouve avec une perte d’informations. Alors que par rapport à ce que disait tout à l’heure Cécilia en introduction sur le fait qu’on peut faire des bêtises, il y a la possibilité, avec cette notion de version qui est une notion importante, de se dire « si j’ai fait une bêtise sur la version actuelle de mon document, je peux très facilement revenir à la version précédente en une seule commande », c’est ça Cécilia ?

Cécilia Bossard : Tout à fait, oui. À tout moment on peut revenir sur des versions précédentes et intégrer, ou pas, les modifications des autres personnes aussi.

Frédéric Couchet : D’accord. J’espère que les gens ont bien compris l’importance de ces outils de gestion de version. Encore une fois, si vous avez des questions, n’hésitez pas à venir sur le salon web, sur le site causecommune,.fm, bouton « chat », salon #libreavous ou carrément appeler au téléphone au 09 72 51 55 46.

Tout à l’heure Cécilia a rappelé que ça date des années 70. Beaucoup de logiciels qui effectivement ont évolué au cours du temps et on mettra sur la page web une page Wikipédia qui liste ces logiciels avec une seule modification, avec des verrous, comme on le disait, jusqu’à aujourd’hui. Ces outils qui sont très connus, en tout cas un est très connu, je pense qu’il est cité à peu près 99 fois sur 100 dans l’émission Libre à vous  quand on parle de ce genre d’outil, dont on va parler tout à l’heure, c’est Git, mais on va parler également de Mercurial.

On a bien compris que le développement logiciel, notamment le développement logiciel libre encore plus, est globalement une affaire d’équipe avec des outils qui doivent être, quelque part, au service des équipes. Comme la plupart de ces logiciels sont des logiciels libres, je suppute qu’ils ont été adaptés pour correspondre aux besoins des équipes de développement dans leur création. Ceux qu’on va citer, comme Git ou Mercurial, on va en citer deux principaux, sont vraiment des outils qui ont été adaptés aux besoins des équipes de développement. C’est ça ?

Nicolas Chauvat : Oui. Je pense qu’une des caractéristiques qui montre ça, c’est justement le caractère décentralisé des outils dont on parle dans l’émission d’aujourd’hui, sachant que ça n’a pas toujours été comme ça. Les outils de gestion de version décentralisés sont apparus au début des années 2000, tu étais là Fred, moi aussi, tu te souviens, Cécilia aussi : Internet années 80, le Web années 90, il y avait déjà des logiciels libres, mais explosion du nombre de connexions internet et du nombre d’utilisateurs du Web dans les années 90, explosion du logiciel libre dans les années 90 et ça a atteint une espèce de limite au début des années 2000, c’est-à-dire les outils qui étaient utilisés pour faire du logiciel libre jusque-là ne passaient pas complètement à l’échelle. À l’époque, l’outil qui était la référence, CVS, je parle juste de celui-là, présentait un certain nombre désavantages pour travailler nombreux tous en même temps, et c’est là que quantité de nouveaux outils sont apparus, qui ont tous essayé de régler le problème d’une manière ou d’une autre. C’est à ce moment-là que sont apparus les outils de gestion de version décentralisés. Il y en avait un certain nombre à l’époque, dont les deux survivants principaux sont ceux que tu as cités tout à l’heure Git et Mercurial. Ce caractère décentralisé est très lié, je trouve, à la manière de développer quand on fait du logiciel libre, c’est-à-dire qu’il y a quand même beaucoup de communautés avec des gens qui sont répartis dans de nombreux endroits différents, pas forcément sur les mêmes fuseaux horaires, etc., ce n’est pas obligatoire pour faire du logiciel libre, mais on trouve souvent dans les logiciels libres. Donc il faut que chacun puisse travailler en local, enregistrer les modifications en local, faire des allers-retours sur les différentes versions comme le disait Cécilia pour pourvoir comprendre si ce sont des changements qui ont introduit des erreurs ou non, et ensuite échanger ces différentes versions avec les autres participants.
En reprenant cet historique, on retrouve une espèce de définition de ce que sont les outils de gestion de version décentralisés.

Frédéric Couchet : On parle du code source, mais, finalement, tout ce qui peut être texte peut être géré par ces outils-là. Tout à l’heure Nicolas, tu parlais même, je crois, des réponses à des appels d’offre, je ne sais plus quel exemple tu citais.

Nicolas Chauvat : Nous faisions du logiciel libre avant de créer Logilab. Quand on a créé Logilab on a appliqué les méthodes qu’on connaissait du logiciel libre. Les statuts de la société sont toujours dans un entrepôt avec les versions. J’ai une pensée pour mon commissaire aux comptes qui vient de prendre sa retraite cette année et qui, depuis 20 ans, a parfois des petits moments d’hésitation quand on lui explique que notre comptabilité est gérée dans Mercurial, qu’on peut retrouver les versions ; que tous nos appels d’offre sont là-dedans, que nos factures sont là-dedans et nos réponses aux appels d’offre. On rédige une réponse à un appel d’offre de 150 pages de la même façon qu’on rédige du code source de plusieurs milliers de lignes, à cinq ou à dix s’il faut, avec un processus de construction qui construit, dans un cas, un PDF plutôt que, dans le cas d’à côté, un binaire ou un déploiement sur un serveur.

Frédéric Couchet : D’accord. Pour rassurer les gens on ne va aller jusqu’à la compta, mais simplement à de la documentation. Si on veut travailler sur un document quel qu’il soit, une prise de position ou une tribune, en fait on peut utiliser ces systèmes, on expliquera après comment on peut les utiliser assez simple.

J’ai une question pour Cécilia. Tout à l’heure, en introduction, tu as dit que tu fais des ateliers notamment pour les enfants. Je n’avais prévu cette question : est-ce que tu as déjà eu l’occasion de montrer à des enfants ce genre d’outil ou sont-ils encore trop jeunes et ce n’est pas pour tout de suite ?

Cécilia Bossard : Je n’ai jamais eu l’occasion de le faire, du coup, ça me donne des idées ! Je le ferai peut-être à l’avenir.

Frédéric Couchet : Ayant déjà assisté à des Coding Goûters je ne l’ai jamais vu, mais je pensais à ça.

Tout à l’heure Nicolas a cité CVS, je vais préciser. Quand on cite un acronyme on explique ce que ça veut dire, donc Concurrent Versions System, c’est un des rares qu’on va citer, mais c’est vrai que c’est un outil qu’on a utilisé, pour beaucoup, avant ces outils de version décentralisés. D’ailleurs je crois que toi Cécilia, si je me souviens bien, une partie de tes expériences c’est de la migration de systèmes on va dire plus ou moins centralisés, ce n’était pas CVS, c’était un autre, vers des outils décentralisés. Je crois que tu as fait une conférence l’an dernier, une conférence technique où tu expliquais justement comment un changement d’outil pouvait se faire, notamment l’accompagnement pas du commissaire aux comptes mais des équipes de développement. C’est bien ça ?

Cécilia Bossard : C’est ça. Ce n’était pas l’année dernière, c’était il y a un petit peu plus longtemps que ça. Oui, comment passer d’un outil à l’autre. Ça change quand même beaucoup la façon de travailler des équipes, même si on dit que normalement les outils sont au service des équipes. Pour ce genre d’outil il y a parfois des habitudes qu’il faut changer dans nos façons de travailler. Il y a toute la migration du code d’un outil à l’autre, comme si on bougeait, on prenait tous nos fichiers, tous nos papiers dans un dossier et qu’on déplaçait dans l’autre, ça c’est assez facile à faire, mais après il y a toutes les habitudes qu’il faut changer et accompagner tous les développeurs sur cette nouvelle façon de faire pour que ce soit le plus simple possible.

Frédéric Couchet : Justement une question : mon image extérieure, ma vision extérieure de ces outils-là c’est qu’ils sont un poil plus compliqués à comprendre que les anciens systèmes de gestion de version. Est-ce que c’est le cas en fait ? On va d’ailleurs détailler un peu les concepts, j’ai l’impression qu’il y a plus de concepts à comprendre pour les utiliser que les anciens systèmes où on modifiait son fichier, etc. ? Ou est-ce que c’est une image totalement fausse Cécilia ?

Cécilia Bossard : Le fait que ce soit décentralisé rajoute effectivement un peu de complexité. Avant on avait le serveur central, on envoyait ses modifications sur ce serveur, on récupérait les modifications des autres et ça n’allait que dans un seul sens. Là, avec ce système décentralisé, on a tout sur son ordinateur, on a tout le projet, toutes les versions, on a tout en local sur sa machine et on peut interroger le PC d’à côté si on veut se mettre à jour. On a aussi un serveur central, mais on peut tout à fait se mettre à jour sur le poste d’un collègue ou une version d’il y a beaucoup plus longtemps. Cette notion de décentralisation est un peu perturbante au début, quand on n’est pas trop habitué à travailler : quand on a, à la base, un mode de fonctionnement pyramidal – c’est le serveur qui donne toutes les infos et qui redescend tout – ça peut être un peu perturbant. Quand on passe de l’un à l’autre, on essaye de reprendre ce système, on aura quand même un serveur central qui va tout guider pour apporter de la décentralisation au fur et à mesure, doucement.

Frédéric Couchet : D’accord. Si je comprends bien ce n’est pas aussi simple, même pour des équipes de développeurs. Nicolas tu voulais compléter.

Nicolas Chauvat : Juste après sur ce point-là. Je veux revenir sur un autre exemple. Tu disais que les concepts des systèmes de gestion de version décentralisés sont peut-être plus compliqués, je n’ai pas le sentiment que ce soit le cas. Certains outils facilitent plus ou moins les choses. On peut représenter la succession des versions comme un arbre et c’est déjà une première différence importante par rapport au suivi des modifications dans un outil comme LibreOffice. C’est-à-dire que l’outil de gestion de versions va enregistrer l’état des fichiers dans le répertoire de travail. C’est comme si on avait des fichiers dans un répertoire de travail, on les modifie et à un instant on peut faire une photo, un instantané et on dit que c’est une version, on lui donne un nom, un identifiant, etc., on peut mettre un commentaire pour donner détails. Après on refait des modifications et on peut à nouveau enregistrer l’état du répertoire de travail. On dit que la nouvelle version qu’on vient d’enregistrer découle de la précédente. Si on fait cette opération plusieurs fois, on se retrouve avec un enchaînement de versions, chacune découlant de la précédente, et l’outil permet de ramener le répertoire de travail dans l’état où on se trouvait quand on a enregistré n’importe laquelle de ces versions. Donc ça fait une espèce de retour de voyage dans le temps : on peut revenir en arrière et, une fois qu’on est revenu en arrière, on peut revenir en avant. À ce stade on a une ligne. Mais ces outils permettent aussi de revenir à une version antérieure, d’avoir le répertoire de travail tel qu’il était au moment où on a enregistré, de faire des modifications et d’enregistrer à nouveau. Et là on a une séparation dans la ligne du temps. On a depuis l’état où on a fait des modifications, enregistré une première version, et puis on est revenu au point de départ, on a fait d’autres modifications et là on a une fourche.

Frédéric Couchet : Un fork.

Nicolas Chauvat : Absolument. On a option A et option B. On peut poursuivre l’option A avec un enchaînement de modifications, on peut poursuivre l’option B et, à n’importe quel endroit, si on veut on peut à nouveau faire des fourches. C’est intéressant pour un certain nombre de raisons, mais, à la fin, on ne livre qu’une seule version du logiciel. En tout cas, à la base, ça permet de faire ça. Et après on peut déplacer à nouveau les branches pour les intégrer.

C’est ça la fonctionnalité en local. Le fait que ce soit distribué fait qu’on peut échanger ces différentes modifications avec les autres utilisateurs, les autres entrepôts qui sont des copies, des clones de cet entrepôt de base.

Les deux fonctionnalités c’est enregistrer de nouvelles versions et échanger les versions.

Frédéric Couchet : Ça suppose que deux personnes qui travaillent chacune de son côté peuvent faire deux fourches différentes et finalement l’outil va permettre de réintégrer ces fourches. ?

Nicolas Chauvat : C’est exactement ça. Si toi et moi nous partons d’une version A toi, tu vas faire des modifications que tu vas enregistrer, tu vas obtenir une version B. À partir de la version A qu’on a en commun je vais faire des modifications, je vais enregistrer, je vais avoir une version C. Après on va pouvoir échanger ces versions, c’est-à-dire que chez toi tu vas pouvoir avoir A, B et C et chez moi je vais avoir A, B et C. On saura tous les deux que B et C sont issues de A et après l’outil va permettre soit de déplacer les changements C sur B, soit de fusionner les deux, pour essayer d’expliquer ça très simplement.

Il y a des cas simples, il y a des cas plus compliqués, ça revient à ce que tu disais avant.
Admettons qu’on partage un fichier, si tu modifies le haut du fichier, moi je modifie le bas et qu’on veuille fusionner, c’est simple, on n’a pas touché aux mêmes endroits. Quand on n’a pas touché exactement aux même endroits même si c’est le même fichier l’outil sait gérer.
C’est un petit plus compliqué quand on a modifié les mêmes lignes, mais ce n’est peut-être pas aujourd’hui qu’on va rentrer dans ces détails-là. En gros, ces outils-là sont faits pour faciliter la vie alors qu’on va toucher aux mêmes parties du fichier.

Frédéric Couchet : D’accord. Cécilia, c’est cette partie-là qui est compliquée à expliquer lorsqu’on passe d’un système ancien à un système décentralisé ? C’est cette partie-là qui est un peu dure à comprendre quand tu fais de l’accompagnement de migration de devs ou ce sont d’autres choses ?

Cécilia Bossard : Cette notion de branche existait déjà avec les anciens systèmes, mais était peut-être un peu moins souple et un peu moins facile à utiliser en fait. Par exemple, avec l’outil Git, du coup je vais nommer, la base de l’outil c’est un peu de faciliter la création de branches et qu’on en fasse autant qu’on puisse et qu’on puisse les fusionner à nouveau. Ça fait toujours un peu peur au début. Dans les anciens outils, faire des branches c’était quand même assez impactant et là, avec ces outils, on considère qu’on peut faire 30 branches dans la journée, ce n’est pas grave, c’est normal, c’est comme ça qu’on travaille. Ce changement de paradigme, tout est une branche et on ne travaille que sur le tronc de l’arbre, sur les anciens systèmes, ce n’est pas toujours évident. Il faut changer de fonctionnement.

Frédéric Couchet : C’est donc un changement de mentalité, de compréhension. On va renter un peu plus dans les détails après une pause musicale. Pour la pause musicale je remercie le site Ziklibrenbib, la musique libre dans les médiathèques, qui nous fait découvrir le titre qui va suivre. « L’artiste australien, Tom Woodward, laisse parler son jeu de guitare et son sens des mélodies et confère à l'ensemble un esprit quasi-blues ». Nous allons écouter Booth Street Psychosis par Tom Woodward. On se retrouve deux minutes dix. Belle journée à l’écoute de Cause Commune, la voix des possibles.

Pause musicale : Booth Street Psychosis par Tom Woodward.

Voix off : Cause Commune, 93.1.

Frédéric Couchet : Nous venons d’écouter Booth Street Psychosis par Tom Woodward, disponible sous licence libre Creative Commons CC BY.

[Jingle]

Deuxième partie MO

Frédéric Couchet : Nous allons poursuivre notre

Chronique « La pituite de Luk » : « Où sont nos génies du business ? »

Frédéric Couchet :