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

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 « Le Libre et la sobriété énergétique ». Le chapitre d’aujourd’hui est intitulé « Sobriété énergétique et sobriété numérique ».
Bonjour Vincent.

Vincent Calame : Bonjour Fred.
Pour continuer à 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 1000 transcriptions de multiples origines : les émissions 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, par exemple, 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 maîtrise 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 du site est librealire.org.
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 la 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ée 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 portait sur 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 ralentissent 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 maîtrise 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 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, 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 : Comme tu l’as dit, la chronique étant écrite, tu me l’as envoyée à l’avance et tu m’as chargé de me renseigner un petit peu. La loi relative à la lutte contre le gaspillage et l’économie circulaire instaurait, en fait, un indice de réparabilité qui vise à une meilleure information du consommateur et de la consommatrice sur le caractère plus ou moins réparable des achats. Mais pour aller plus loin, une mesure phare réclamée par HOP – Halte à l’obsolescence programmée – est un indice de durabilité et non pas de réparabilité. L’objectif d’un indice de durabilité est de garantir un indice donnant des informations sur la fiabilité, la réparabilité et l’évolutivité, afin de pouvoir comparer les produits en magasin ou en ligne et répondre à la question : lequel est conçu pour durer ?
Cet indice de durabilité, qui devrait remplacer l’indice de réparabilité, entrera en vigueur en 2024. Actuellement, il y a un groupe de travail créé par le gouvernement pour travailler sur le contenu de cet indice, travail qui nous intéresse, évidemment, car un tel indice doit inclure la question du logiciel. Le logiciel ce n’est pas seulement de la réparabilité, c’est aussi de la durabilité, de savoir qu’on va pouvoir installer des logiciels libres, revenir à une version précédente, etc. Ça peut être considéré plutôt comme de la durabilité que de la réparabilité.
As-tu fait d’autres recherches ?

Vincent Calame : Oui, j’ai également fait « transition énergétique » qui donne neuf 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 30 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, mais, 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 propose de nous retrouver la semaine prochaine pour la deuxième partie de cette chronique pour approfondir la question.

Frédéric Couchet : Tu fais vraiment durer le suspense ! On va donc te retrouver dès le mardi 6 décembre pour la seconde partie de cette chronique sur la sobriété énergétique et le Libre. C’est bien ça ?

Vincent Calame : C’est bien ça.

Frédéric Couchet : D’accord. Au sujet de l’émission dont tu parlais, l’émission numéro 36, je vais préciser que vous pouvez écouter le podcast ou lire la transcription directement à l’adresse libreavous.org/36. En fait, pour toutes les émissions vous faites libreavous.org/le numéro de l’émission, vous retrouvez directement l’émission. C’était l’émission qui était consacrée à l’obsolescence programmée et au projet de loi sur l’économie circulaire.
Je te remercie, Vincent, je te souhaite une belle fin de journée. À la semaine prochaine.

Vincent Calame : À la semaine prochaine.

Frédéric Couchet : On va faire une pause musicale.

[Virgule musicale]

Frédéric Couchet : Après la pause musicale, nous parlerons de logiciels de gestion de versions décentralisés et de forges logicielles.
Je remercie Alice, du site auboutdufil.com, qui nous fait découvrir l’artiste Zoo Shapes et le titre Burn, « une musique triste qui explore les thèmes de l’amour à sens unique, la rupture amoureuse, la difficulté d’oublier et d’aller mieux, la douloureuse prise de conscience lorsque l’on comprend que c’est terminé, la mélancolie, la nostalgie. » Nous allons écouter Burn par Zoo Shapes. On se retrouve dans trois minutes cinquante. Belle journée à l’écoute de Cause commune, la voix des possibles.

Pause musicale : Burn par Zoo Shapes.

Voix off : Cause Commune, 93.1.

Frédéric Couchet : Nous venons d’écouter Burn par Zoo Shapes, disponible sous licence libre Creative Commons Attribution, CC BY.

[Jingle]

Frédéric Couchet : Nous allons poursuivre par notre sujet principal.

[Virgule musicale]

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

Frédéric Couchet : Nous allons poursuivre par le sujet principal 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 peu 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 essayer de s’adresser surtout 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 Cécilia Bossard de la société Code Lutin et j’ai, en face de moi, Nicolas Chauvat 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 peu le temps, j’aime bien aussi apprendre aux enfants à programmer. Voilà à peu près pour mes activités.

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

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

Frédéric Couchet : Nous mettrons les références sur le site de l’émission du jour. On a déjà parlé des Coding Goûters, je ne sais plus dans quelle émission, il y a trois ou quatre ans, vous chercherez sur libreavous.org. 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, qui est â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 c’est parce que nous avons, entre autres, contribué au développement de Mercurial qui est un outil de gestion de versions. 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 GitLab.

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. L’objectif de l’émission du jour c’est de présenter un peu ce principe de logiciels de versions décentralisés 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 versions 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, donc 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 vraiment nous aider à 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 cette expression, « on peut faire des bêtises » est connotée 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.
Il y a déjà 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 ne fonctionne pas comme on voudrait.
On peut faire des erreurs de compréhension sur ce qu’on voulait que le logiciel fasse, eh bien il faut revenir en arrière et changer parce que ça ne fait pas ce que c’est censé faire.
On peut aussi écraser des modifications.

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 a à peu près le même âge que Cécile Duflot, il est donc un peu plus jeune que moi, mais 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 des logiciels et peut-être aussi un petit historique sur les outils, avant qu’on parle des outils d’aujourd’hui qui sont des logiciels de gestion de versions 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 des 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 arriver à leur dire exactement ce qu’on veut.

Donc je considère que mon métier c’est d’écrire. Ça veut dire que pour le faire efficacement il faut se doter d’outils qui fonctionnent bien pour ça et gérer le fait que, comme disait Boileau, il faut toujours remettre son 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écise.

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 versions 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 !

Nicolas Chauvat : Carrément !

Frédéric Couchet : 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, 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 tout départ, des gens qui développaient tout seuls dans leur coin. Au départ, est-ce que ces 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 ? Vas-y Cécilia, si tu veux introduire.

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 pouvait changer plusieurs fichiers, après 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 c’est volontairement qu’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, finalement, 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 versions ? 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 » et 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 fonctionnalité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 pas 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 de gérer l’échange des modifications.
Et puis aujourd’hui, toujours pour faciliter la collaboration parce que la phase de mise au point doit être distinguée 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. C’est-à-dire qu’on peut avoir plusieurs personnes qui travaillent en même temps sur des changements en cours qui ne sont pas finalisés et qui, en gros, s’échangent les changements sur les changements. Ç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. À tout moment on peut revenir sur des versions précédentes et intégrer aussi, ou pas, les modifications des autres personnes.

Frédéric Couchet : D’accord. J’espère que les gens ont bien compris l’importance de ces outils de gestion de versions. 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 ont effectivement évolué au cours du temps : une seule modification, d’un seul fichier, avec, comme on le disait des verrous. On mettra sur la page web de l’émission une page Wikipédia qui liste ces logiciels jusqu’à aujourd’hui. Ces outils 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 il y a aussi, évidemment, Mercurial.

On a bien compris que le développement logiciel, et 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 versions 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, puis 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 que les outils qui étaient utilisés pour faire du logiciel libre jusque-là ne passaient pas complètement à l’échelle.

L’outil qui était à l’époque la référence, CVS, je parle juste de celui-là, présentait un certain nombre de désavantages pour travailler nombreux tous en même temps. C’est là que quantité de nouveaux outils sont apparus, tous ont essayé de régler le problème d’une manière ou d’une autre, et c’est à ce moment-là que sont apparus les outils de gestion de versions décentralisés. Il y en avait un certain nombre à l’époque, dont les deux principaux survivants 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 dont on a l’habitude 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 ça 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 pouvoir 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 versions 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, nos réponses à nos appels d’offre, etc. 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’à de la compta, mais simplement à de la documentation. Si on veut travailler à plusieurs 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 de façon 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-là : 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 gestion de versions 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 sa façon de travailler. Il y a toute la migration du code d’un outil à l’autre, comme si on bougeait, on prenait tous ses fichiers, tous ses papiers dans un dossier et qu’on les 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 versions. Est-ce que c’est le cas en fait ? D’ailleurs on va 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, tout est 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, qu’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 si simple que ça même pour des équipes de développeurs. Nicolas, tu voulais compléter ?

Nicolas Chauvat : Sur ce point-là après.
Je veux juste revenir sur un autre exemple. Tu disais que les concepts des systèmes de gestion de versions 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 des 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ù il 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.
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. 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, enregistré, donc 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é de base, 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 sont 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, 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, que 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 même si on touche 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 le nomme - la base de l’outil c’est un peu de faciliter la création de branches, qu’on en fasse autant qu’on peut et qu’on puisse les fusionner à nouveau. Ça fait toujours un petit 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. Avec 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 rentrer 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 dans 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]

Frédéric Couchet : Nous allons poursuivre notre sujet principal, toujours avec nos deux invités : au téléphone Cécilia Bossard de la société Code Lutin, basée du côté de Nantes et, en face de moi, Nicolas Chauvat de la société Logilab. J’en profite d’ailleurs pour remercier vos deux sociétés de leur soutien aux actions de l’April, elles sont toutes les deux membres de l’April. On ne remercie jamais assez les personnes qui nous soutiennent.

On parlait et on va continuer de parler de logiciels de gestion de version décentralisés et ensuite on abordera la question des forges logicielles que souvent les gens peuvent confondre.

N’hésitez pas à participer à notre conversation sur le salon web dédié à l’émission sur le site causecommune.fm, bouton « chat », salon #libreavous ou vous pouvez passer un petit coup de fil pour poser une question ou réagir au 09 72 51 55 46.

Juste avant la pause musicale Nicolas et Cécilia nous expliquaient un point peut-être un peu complexe à comprendre, avec des notions d’arbre, de tronc, de branches. Nicolas souhaitait faire une comparaison qui permettrait de mieux comprendre cette notion-là, c’est La fabrique de la loi, les amendements. Nicolas Chauvat.

Nicolas Chauvat : Une association, qui s’appelle Regards Citoyens, met en ligne plusieurs sites dont l’un est nosdeputes.fr, d’ailleurs ils cherchent de l’aide pour la prochaine mandature, si ça peut intéresser les auditeurs, allez voir nosdeputes.fr. Et, avec le médialab de Sciences Po – d’ailleurs je crois que Regards Citoyens a déjà fait l’objet d’une émission Libre à vous !, le médialab de Sciences Po aussi, donc on reste dans le thème – ils ont mené un projet commun, qui s’appelait La Fabrique de la Loi, au cours duquel ils ont essayé, dans un site web, de représenter justement comment la loi est produite : la proposition initiale du gouvernement qui vient au Parlement, le mécanisme d’amendements, le mécanisme de navette parlementaire entre l’Assemblée et le Sénat. Je pense que ce processus est connu, pas forcément dans les détails, mais du moins d’une manière générale, on en parle dans tous les médias, et je trouve qu’on peut le rapprocher du processus de rédaction d’un logiciel. Les amendements au texte initial sont autant de branches, comme le disait Cécilia, par rapport à la version qui est enregistrée. Ces amendements peuvent être discutés et modifiés, c’est comme s’il y avait des versions successives de ces amendements, et après ces amendements sont ou non, suivant le résultat du vote, intégrés au texte initial, donc fusionnés avec le texte initial et, à la fin, on produit une loi. Si on va voir sur Légifrance, on voit qu’on sait dire, à un instant donné, que tel paragraphe de la loi, qui est entré en vigueur à telle date et qui a cessé de prendre effet à telle autre date, a été introduit dans la loi par le texte qui a été voté à telle date au Parlement.

Ce sont les mêmes outils de gestion de version dont on a besoin pour faire efficacement et précisément du logiciel que ceux dont on a besoin pour suivre la loi, la législation dans un pays. « Est-ce qu’il faut mettre le texte de loi sous Git ou Mercurial ? », c’est une présentation que j’avais faite à une conférence de La Fabrique de la Loi il y a quelques années.

Frédéric Couchet : Le site dont parle Nicolas c’est lafabriquedelaloi.fr, on mettra les références. Là-dessus il y a sans doute l’outil qui agit, il y a aussi une question d’intervention humaine, que ce soit des parlementaires ou des équipes de l’administration du Sénat et de l’Assemblée nationale. Par rapport à la question qu’il y avait tout à l’heure, il y a aussi un travail humain qui est fait quand, justement, les modifications portent au même endroit : laquelle on va garder, laquelle va tomber parce qu’elle est satisfaite ou parce que tel amendement qui a été voté fait tomber cette proposition-là ? Je pense que l’outil ne fait pas tout. Cécilia, sur cette partie-là, est-ce que tu veux compléter par rapport à ce que vient de présenter Nicolas ?

Cécilia Bossard : Je pense qu’il a été assez clair.

Frédéric Couchet : Comme tu es au téléphone, je ne te vois pas réagir, c’est pour ça.
On a cité Git et Mercurial. Encore une fois, ne vous préoccupez pas trop des noms des logiciels, on reviendra dans le fonctionnement de ces logiciels un peu plus dans le détail technique, sans doute en 2023 ; là on va essayer de rester à un niveau qui nous permet de comprendre les enjeux, etc.
J’ai quand même envie de poser une question : pourquoi le choix de ces logiciels ? On va commencer par Cécilia de Code Lutin. Tout à l’heure, j’expliquais que tu avais notamment travaillé sur des migrations d’anciens systèmes de gestion sur des systèmes d’aujourd’hui, décentralisés, et le choix a été Git. Pourquoi avez-vous choisi Git ? Est-ce que ce sont des raisons techniques ? Des raisons d’historique ? Pourquoi le choix de Git a-t-il été fait par Code Lutin ?

Cécilia Bossard : Quand je suis arrivée à Code Lutin, le choix était déjà fait, je suis désolée, je ne vais pas pouvoir donner la raison. Je n’ai pas pensé à demander à mes collègues pourquoi.

Frédéric Couchet : Pourquoi toi, par exemple, choisirais-tu plutôt Git qu’autre chose ?

Cécilia Bossard : Pour une équipe qui migrerait d’un ancien système vers ces systèmes décentralisés, j’aurais tendance à aller effectivement vers Git – désolée Nicolas –, parce que c’est l’outil qui est peut-être le plus utilisé et pour lequel on trouve énormément de documentation sur Internet. C’est assez facile de trouver des guides, des tutoriels, de savoir quoi faire, des petites fiches mémo pour savoir quelles commandes il faut taper et tout ça.

Frédéric Couchet : Il y a aussi une raison de connaissance par les personnes qui vont potentiellement l’utiliser. Le fait que tu dises Git ça va tout de suite parler aux gens alors que, et je laisserai Nicolas défendre son outil, si on dit Mercurial, les gens vont dire « c’est quoi ce truc-là ? », les gens ne connaissent même pas.

Cécilia Bossard : J’ai peur qu’il y ait un peu de ça. Oui.

Frédéric Couchet : Je connais évidemment Mercurial pour l’utiliser aussi, mais il est clair qu’aujourd’hui - on fera des statistiques sur les transcriptions des émissions -, je pense que c’est peut-être la première fois qu’on cite le nom de Mercurial, alors que le nom de Git, on va notamment parler tout à l’heure d’un des sites les plus connus, GitHub, qui est problématique, dans les forges logicielles. Git parle quasiment à tout le monde. C’est une des raisons du choix, ce n’est pas que technique, ce qui peut très bien s’entendre, c’est aussi le fait que les gens connaissent, l’ont peut-être déjà utilisé, ce sera plus facile, finalement, pour les gens de se mettre sur ce projet-là.

Cécilia Bossard : Tout à fait.

Frédéric Couchet : Nicolas, parole à la défense ! Je blague ! Ma fille fait des études de droit, c’est pour ça que je me permets ! Quand on a préparé l’émission, quand j’ai monté le sujet, il était important de ne pas parler que de Git. Initialement d’ailleurs, la première personne que j’ai invitée c’est Nicolas parce que j’ai vu qu’il y avait une Mercurial Conférence à Paris, en septembre dernier, qui a dû être annulée, qui est, je crois, décalée en 2023. On va dire que Git et Mercurial ce sont finalement un peu les mêmes périodes de création. Même question qu’à Cécilia : pourquoi le choix de Mercurial ?

Nicolas Chauvat : On a commencé Logilab en 2000. On utilisait CVS. Je crois que c’est aux alentours de 2005 qu’a eu lieu l’explosion de solutions alternatives dont on a parlé plus tôt. Ce qui a bien marché, dans un premier temps, s’appelait Subversion. Ensuite il y a eu les systèmes de gestion distribués, nous en avons essayé plusieurs dont Git. Mercurial était écrit en Python, on a toujours fait du Python à Logilab, on s’est dit « si on a besoin de modifier des choses et de contribuer, avec Mercurial on pourra ». Avec Mercurial, les commandes nous paraissaient plus claires qu’avec Git. S’il y a moins de documentation avec Mercurial, c’est parce qu’il y a moins besoin de documentation ! Donc nous sommes partis sur Mercurial. Il n’y avait pas autant de forges qu’aujourd’hui, je suis en train d’essayer de te faciliter la transition ! On a même développé une forge à l’époque, à laquelle on a intégré Mercurial. On a un peu contribué à Mercurial avec un petit peu de code, en hébergeant des sprints, en allant à des conférences.

Frédéric Couchet : Les sprints sont des sessions de travail à plusieurs.

Nicolas Chauvat : Le terme hackathon est peut-être plus diffusé, je ne sais pas.
Au début, pour gérer cette différence entre le travail brouillon et le travail validé, on utilisait deux entrepôts Mercurial, un avec le code validé et un avec une pile de patchs avec un outil qui s’appelait Quilt. Au bout d’un moment, gérer les piles de patchs de Quilt et se relire mutuellement les patchs Quilt avec Mercurial devenait pénible. On a cherché comment faire mieux et on s’est mis à contribuer à Mercurial. Une personne de chez nous a été ensuite embauchée chez Facebook, a travaillé justement sur cette fonctionnalité-là et, maintenant, a fait une entreprise qui a fait ce fork amical de GitLab, je peux te la recommander pour une future émission sur les systèmes de gestion de versions distribués, si tu veux rentrer dans les détails. Nous, nous sommes toujours restés avec Mercurial.

Frédéric Couchet : D’accord. En tout cas c’est intéressant et ça montre aussi la dynamique logiciel libre sur le choix. Le fait que vous pouviez plus facilement contribuer à ce projet a beaucoup joué sur le choix parce que c’est en Python, parce que vous êtes des spécialistes reconnus de Python, donc potentiellement si, à un moment, quelque chose vous bloquait ou que vous aviez besoin de quelque chose, vous pouviez plus simplement contribuer « qu’en demandant », entre guillemets, mais plutôt en proposant justement une nouvelle branche qui pourrait être intégrée ensuite dans le tronc commun, etc., si j’ai bien compris ce que vous faites. C’est vraiment très intéressant.

Tu as employé le terme forge. Je regarde le temps qui avance. Juste avant de parler des forges, on va faire la transition : est-ce qu’il faut être geek pour utiliser ces outils de gestion de versions décentralisés, que ce soit Git ou Mercurial ? Pour l’instant on n’a pas dit comment réellement on les utilise. Est-ce qu’il faut être geek ? Est-ce qu’il faut vraiment être à l’aise avec l’informatique pour utiliser ces outils ? Peut-être Cécilia sur cette question.

Cécilia Bossard : Je ne pense pas qu’il faille absolument être à l’aise avec l’informatique. Pas mal d’outils graphiques permettent de gérer, d’utiliser ces outils de manière assez simple. Il y en a même qui sont intégrés à l’explorateur de fichiers, que ce soit sous Windows ou sous GNU/Linux. Avec un simple clic droit on peut sauver la version de son fichier.
On peut les utiliser pas que pour du code. Nicolas parlait de son comptable qui récupérait pas mal de documents. J’ai vu des gens qui l’utilisent - c’est Git dans ce cas-là - un peu comme une base de données pour rédiger leur blog, pour rédiger leur site web, où chaque unité de code est un nouvel article ; ils utilisent Git pour ajouter de nouvelles infos.
On peut inventer plein d’utilisations. Pour la rédaction des blogs je crois qu’il faut quand même être un peu geek pour faire ça, il y a des outils plus simples, mais c’est vraiment ouvert à tout.

Frédéric Couchet : D’accord. Je viens de penser que mes trois collègues utilisent effectivement un outil intégré dans le gestionnaire de fichiers pour valider des modifications, par exemple de la documentation, ce n’est pas du code source. Notre système de fichiers de compta est mis lui aussi dans un système de gestion de versions qui exporte, etc. Ils utilisent effectivement un gestionnaire de version de fichiers.

Là on a parlé des logiciels de gestion de versions décentralisés avec notamment deux exemples, Git et Mercurial. On invite les personnes qui veulent se renseigner à aller sur le site libreavous.org, dans la page des références vous aurez des liens. Mais il y a un terme qui revient souvent, qui est souvent confondu, qui est celui de « forge logicielle » ou « forge informatique ». Qu’est-ce qu’une forge logicielle et quel est le lien avec le sujet dont on vient de parler jusqu’à présent ? Nicolas.

Nicolas Chauvat : Un petit mot sur le point juste avant. Il y a beaucoup de gens qui sont habitués à utiliser par exemple LibreOffice et ils vont penser en termes de documents, de tableaux, de présentations. Ce qu’on n’a pas dit mais qu’on aurait dû préciser plus tôt, c’est que tous ces outils de gestion de version sont faits pour manipuler du texte et ils gèrent les différences entre fichiers texte. Un fichier de traitement texte n’est pas un fichier texte : il y a quantités de choses dedans, la mise en forme, les titres, etc., c’est différent. Moi je fais tout avec des fichiers texte, beaucoup de gens ne font pas tout avec des fichiers texte, donc, moi je peux tout faire avec un outil de gestion de versions parce que je fais tout avec du texte, pour d’autres gens qui ne font pas tout avec du texte, ce n’est pas exactement la même situation. C’est un premier point.

Pour les forges. C’est clair que Git va être connu par 99,9 % des gens qui vont avoir entendu parler de gestion de versions alors que ce n’est pas le cas pour d’autres outils, comme Mercurial, et c’est encore moins le cas pour d’autres outils qui ont existé il y a 15 ans et qui sont tombés plus ou moins dans l’oubli aujourd’hui.
Le processus de collaboration a besoin de plusieurs outils : on peut écrire de la documentation ; on a besoin de partager le code source et les différentes versions, on en a parlé ; on a besoin de savoir ce qu’on veut faire, souvent ça s’appelle gestion de tickets ou, au moins, gestion de demandes ou gestion des bugs ; on veut enregistrer les anomalies qu’on doit corriger ; on veut planifier ce qu’on va faire maintenant, ce qu’on va faire plus tard ; au fur et à mesure que le temps avance, il y a d’autres choses, il y a les tests automatiques des logiciels, il y a le déploiement.

GitHub est une forge qui date déjà d’une bonne dizaine d’années, voire plus, peut-être, je ne sais pas, je n’ai pas pensé à vérifier, probablement plus d’une dizaine d’années.

Frédéric Couchet : GitHub c’est depuis 2008, donc 14 ans.

Nicolas Chauvat : Je me souviens qu’au début je demandais aux gens pourquoi ils utilisaient GitHub, ils disaient « parce que c’est un super réseau social. »

Frédéric Couchet : D’ailleurs, une des traductions du mot hub c’est « réseau », « un centre de concentration ».

Nicolas Chauvat : Concentration, le point où se concentrent, ça a vraiment été pensé comme ça. GitHub qui, au passage, était indépendant, est aujourd’hui dans les mains de Microsoft.

Je dirais qu’une forge est aujourd’hui un logiciel de gestion de projet. Par exemple à Logilab, quand on a besoin de gérer un projet, même s’il n’y a pas de code dedans, même s’il n’y a rien à déployer sur un cluster, juste quand on veut faire des tickets pour savoir ce qui avance, ce qui n’avance pas, le processus d’intégration d’un nouvel employé, on a un certain nombre de tâches à exécuter, eh bien c’est un projet dans notre Heptapod, c’est-à-dire dans notre GitLab.

Frédéric Couchet : Juste préciser pour qu’on ne soit pas perdu, qu’est-ce qu’Heptapod ?

Nicolas Chauvat : GitLab est un logiciel libre, c’est une forge qui est faite pour Git, comme son nom l’indique. Heptapod c’est GitLab modifié de manière à ce qu’on puisse avoir à la fois du Git et du Mercurial. On choisit pour chaque projet.

Frédéric Couchet : C’est une forge qui permet d’avoir en-dessous l’outil que l’on veut en gestion de version, soit Git soit Mercurial. OK.

Nicolas Chauvat : GitLab est un logiciel qui est développé très rapidement, il y a vraiment beaucoup de gens et une version tous les mois, qui est développé par une société commerciale, etc., qui vend de l’hébergement de GitLab et aujourd’hui ils essayent de tout intégrer là-dedans.
Il y a plein d’autres forges, tu as fait une liste sur le site de l’émission des forges les plus actives ou dont le développement est le plus actif. GitHub est un exemple et c’est le plus connu, quantité d’entreprises achètent GitHub à Microsoft pour l’utiliser en interne et ainsi de suite.
GitHub et GitLab, pour prendre les plus connues, intègrent de plus en plus de fonctionnalités pour en faire vraiment le concentrateur de tout ce dont on peut avoir besoin pour faire du logiciel. Ça veut dire la documentation, ça veut le suivi des demandes de fonctionnalités, ça veut dire le code source, ça veut dire les tests automatiques, ça veut dire le déploiement des logiciels, ça veut dire la récupération des erreurs pendant l’exécution des logiciels, ça veut dire le stockage et la diffusion des binaires, pour le dire vite, qui sont produits suite à la construction du logiciel pour les diffuser. Dans GitLab on stocke des paquets Python, on stocke des images Docker. On peut automatiser le déploiement sur un cluster Kubernetes. Ça va assez loin.

Frédéric Couchet : Tout et n’importe qui ! On ne va pas rentrer plus dans les détails, on reparlera de Kubernetes. C’est donc un outil de développement de projet avec plein de choses.
Cécilia, une chose qui est assez connue dans le monde de Git, plutôt GitHub vu que ça a été popularisé par GitHub, je vais le dire en anglais, on va essayer de le traduire en français, c’est la notion de pull request, demande d’intégration en français. J’ai l’impression que c’est un truc qui a été vraiment démocratisé, qui a eu beaucoup de succès, est-ce que tu peux expliquer ce qu’est cette notion de pull request ou demande d’intégration ?

Cécilia Bossard : Ça a été démocratisé par GitHub, dans GitLab ça s’appelle des merge requests, en plus les mots ne sont pas pareils, c’est pratique !, donc des demandes de fusion. Quand un développeur ou plusieurs développeurs ont développé une nouvelle fonctionnalité, une nouvelle portion de code, et souhaitent l’intégrer à la version finale de la future application ; ils veulent vraiment intégrer cette portion de code dans le gros paquet qui sera livré, donc ils font ce qu’on appelle une merge request, une pull request, une demande de fusion. C’est comme un patch, des lignes de code modifiées qu’on va envoyer. Après, en fonction de la façon dont fonctionnent les équipes, cette portion de code peut être relue par d’autres personnes pour s’assurer que tout va bien, que ça fonctionne bien et, une fois que c’est relu et validé, c’est intégré dans la version finale de l’application.

Frédéric Couchet : D’accord. C’est GitHub qui a effectivement initié et popularisé ça. Aujourd’hui la plupart des forges intègrent ce genre d’outil. Comme tu le dis, ils ont peut-être des noms différents, demande d’intégration ou de fusion, merge request ou pull request.

On va rappeler, ceci dit peut-être qu’on ne l’a pas précisé, comme on est une émission sur le logiciel libre, Git et Mercurial sont deux logiciels libres, mais est-ce que ça veut dire pour autant que les forges sont des outils en logiciel libre ? Nicolas fait non de la tête. On va peut-être laisser Nicolas commencer. Finalement, quand on utilise une forge, est-ce qu’on ne doit pas regarder aussi si la forge elle-même, les outils qu’elle propose, sont des outils en logiciel libre ou des outils privateurs qui pourraient nous rendre, quelque part, prisonniers et prisonnières d’une forge, notamment dans le cas GitHub ?

Nicolas Chauvat : C’est une très bonne question, je vous remercie de me l’avoir posée. Il me parait utile de distinguer les outils de gestion de versions, donc Git, Mercurial et tous les autres, qui sont des outils relativement bas niveau puisque, comme on le disait, ça permet de gérer des modifications qui sont faites sur un ensemble de fichiers texte, essentiellement dans un répertoire de travail, et les forges ; même s’il y a Git partout, dans tous les noms, il faut distinguer les deux, donc les outils de gestion de versions d’un côté, les forges de l’autre ; les forges sont plus des outils de gestion de projet qui peuvent aller assez loin. Si ce mécanisme de pull request, par exemple, a eu du succès c’est parce qu’il plaquait - de mon point de vue en tout cas, c’est l’explication que je donnerais - une interface utilisateur dans un navigateur et un processus de collaboration qui permettait à beaucoup de gens d’utiliser Git, alors qu’ils auraient trouvé compliqué de l’utiliser en ligne de commande. Beaucoup de gens n’utilisent pas Git, utilisent GitHub, et ils seraient bien embêtés s’ils devaient utiliser Git directement parce que ce n’est pas comme ça qu’ils réfléchissent.

Frédéric Couchet : Je te laisse poursuivre, mais, quelque part, ça a été un peu « vendu », entre guillemets, comme une simple interface web, qui s’est révélée plus problématique derrière. C’est ça ?

Nicolas Chauvat : Ça a commencé comme une simple interface web qui a rendu accessible un outil qui n’est pas complètement simple – de ce point de vue-là Mercurial n’est pas complètement simple non plus, pour des gens qui sont habitués à LibreOffice, il y a une différence – et, au final, les gens n’utilisent que l’interface, que GitHub. Les concepts de base qui sont nécessaires pour faire fonctionner Git n’apparaissent pas nécessairement dans l’interface qui vient par-dessus. Ce n’est parce que tu es habitué à utiliser l’interface que tu sauras retrouver l’équivalent dans l’outil qui est en dessous.

Frédéric Couchet : De ce point de vue-là, si des gens veulent utiliser des forges, que leur conseille-t-on ? Est-ce qu’il y a des forges qui sont 100 % en logiciel libre ? Cécilia, de ton point de vue, tu utilises plus Git que Mercurial, est-ce qu’il y a des forges que tu conseillerais plus ? Quel est ton point de vue là-dessus ?

Cécilia Bossard : Pas GitHub, c’est clair. Nous, nous utilisons GitLab. Le fonctionnement est quand même très similaire entre GitLab et GitHub. Comme disait Nicolas tout à l’heure, GitLab n’est pas non plus totalement libre sur toutes les fonctionnalités, derrière c’est une entreprise qui vend des fonctionnalités supplémentaires.

Frédéric Couchet : En gros il y a deux versions, c’est ça ?

Cécilia Bossard : C’est ça. Il y a une version communautaire et une version, je ne sais pas comment ils l’appellent, une version payante.

Frédéric Couchet : Une version entreprise.Je ne sais pas comment elle s’appelle, GitLab for Enterprise.

Cécilia Bossard : Voilà, c’est ça !

Frédéric Couchet : En tout cas on a le choix, c’est-à-dire qu’on n’est pas obligé d’aller sur GitHub.

Une question. De nos jours les entreprises recrutent. Quand vous faites des offres d’emploi ou des candidatures spontanées je suppose qu’aujourd’hui les gens mettent le lien vers le compte de leur forge. Comment ça se passe ? Vous voyez ce genre de chose ? Nicolas.

Nicolas Chauvat : Nous avons très rarement des CV avec Mercurial, mais on dit que ce n’est pas grave, on leur expliquera. Les concepts sont les mêmes en fait. C’est-à-dire que quelqu’un qui sait utiliser Git en ligne de commande va appendre à utiliser Mercurial en ligne de commande et quelqu’un qui sait utiliser GitHub saura utiliser Gitlab, il n’y a aucun problème là-dessus.

Dans notre processus de recrutement, on demande aux gens d’écrire du code et ils nous répondent souvent en nous envoyant l’adresse d’un projet GitHub.

Frédéric Couchet : C’est bien l’impression que j’ai en fait. Du côté de Code Lutin, est-ce que vous avez la même chose ?

Cécilia Bossard : Globalement. Ce sont souvent des profils GitHub qui sont envoyés.

Frédéric Couchet : D’accord. Quelque part ces forges ont permis de mettre des outils accessibles au plus grand nombre. Se pose après la question d’orienter ces personnes-là vers les bons outils, notamment d’un point de vue des libertés informatiques.

Nicolas Chauvat : L’utilité de ces forges est clé. J’insistais juste sur la distinction qui me paraît nécessaire entre les deux. Il y a l’outil sous-jacent et puis il y a une interface utilisateur par-dessus qui est orientée vers beaucoup de fonctionnalités qui n’ont rien à voir avec la gestion de versions. C’est le premier point.
À Logilab, par exemple, on n’a pas que des gens qui travaillent avec la ligne de commande. On utilise l’interface, on commence à utiliser l’interface de GitLab qui permet de modifier certains fichiers et, quand on appuie sur le bouton « sauvegarder », ça sauvegarde mais ça fait aussi un commit, c’est-à-dire que ça enregistre une version, ça enregistre des changements. On utilise l’interface web pour permettre à des gens de participer au processus de collaboration avec cet outil qui est central, sans les obliger à apprendre la ligne de commande.

Frédéric Couchet : On arrive à la fin de l’échange. Je vous laisse quelques instants pour réfléchir à la dernière question, que vous connaissez.
Je vais juste préciser que sur le site de l’émission, libreavous.org, on a mis plein de références sur un certain nombre de sujets qu’on a évoqués. On a dû mettre, je pense, un lien vers la forge proposée par le Chapril, notre site qui propose des services libres et loyaux. Sur chapril.org, il y a une forge que vous pouvez tester, qui, par contre, est vraiment orientée contenus libres, que ce soit du code source, de la documentation ou autre chose, vous pouvez tester et il y a d’autres liens. On a sans doute cité beaucoup de noms, mais n’hésitez pas à aller sur la page libreavous.org, il y a les références.

On arrive vraiment à la fin de l’émission. Je répète que c’était une première émission d’introduction sur ces concepts-là, on rentrera plus dans les détails en 2023, on parlera aussi parce qu’on nous a posé la question sur linuxfr.org, de l’initiative de fédération de forges. Il faut déjà comprendre ce que c’est qu’une forge avant de parler de fédération de forges, on en parlera en 2023.

Juste pour conclure, en deux minutes chacun et chacune, quels sont, selon vous, les éléments clés que vous souhaiteriez que les gens retiennent ou à faire passer ? On va commencer par Nicolas Chauvat.

Nicolas Chauvat : Je voudrais dire que j’encourage la fédération des forges, le fédivers et tout ça.

Je voulais donner un autre exemple de tendance dans les forges. Ça existe, par exemple dans GitHub, avec un petit programme qui s’appelle Dependabot.
On a parlé, en tout cas on a cité l’automatisation des tests dans les forges ; à une époque c’était des logiciels distincts, peut-être que des gens connaissent Jenkins qui servait à automatiser des choses. Dans GitLab il y a aujourd’hui l’équivalent de Jenkins, donc on utilise ça dans GitLab.
On peut même faire des choses du genre « je pousse des changements dans la forge et je dis si que les tests passent, tu intègres automatiquement ».
On peut avoir un accès programmatique à ces forges avec une API, pour reprendre un terme à la mode, ça veut dire qu’on peut écrire des programmes qui vont regarder ce qui se passe dans la forge et qui vont rajouter des tickets, des objets, des changements, etc.
Donc sur GitHub il y a quelque chose qui s’appelle Dependabot, qui peut proposer automatiquement des demandes d’intégration, de mise à jour des dépendances de votre logiciel.

À Logilab on a un petit logiciel libre qu’on appelle Code Doctor. Code Doctor court dans les entrepôts de notre forge, il propose des mises à jour des dépendances ou parfois, quand les API de nos logiciels changent, on écrit des petits programmes de mise à jour des API ; Code Doctor court dans les entrepôts et propose des modifications, donc des merge requests, il génère des demandes de fusion pour mettre à jour le code en fonction des modifications d’API des dépendances, chose que permettent de faire les forges, par exemple.

Frédéric Couchet : Sur le salon web, Booky demande ce qu’est une forge et ce que ça permet. Je crois que tout à l’heure tu as précisé qu’une forge. En quelques mots, c’est un système qui permet d’offrir plusieurs outils, permettant le travail en collaboration, basé sur un système de gestion de versions, offrant aussi un système de support, d’échanges, éventuellement de listes de travail, etc.

Nicolas Chauvat : Je dirais que c’est une boîte à outils pour faire de la gestion de projet et du logiciel.

Frédéric Couchet : Tu résumes mieux que moi mais c’est normal, tu es l’invité, moi je ne suis qu’un humble animateur.
Cécilia Bossard, en conclusion ?

Cécilia Bossard : Pour conclure, j’aurais tendance à vouloir inciter tout le monde à tester ce genre d’outil, même si les gens ne font pas de code, même pour des fichiers importants sur leur ordinateur, voir ce que ça peut donner de gérer des versions et d’avoir une sauvegarde quelque part, c’est très important. Il ne faut pas hésiter à tester, à jouer avec, et je pense que je vais inciter mes enfants à mettre leurs travaux personnels du collège sur Git pour qu’ils puissent avoir les versions et arrêter de les perdre. Ce ne serait pas mal !

Frédéric Couchet : C’est une belle conclusion. Comme tu l’as dit tout à l’heure en introduction, on peut faire des bêtises et ce n’est pas grave parce qu’on peut rattraper les bêtises avec Git ou Mercurial, évidemment, avec ces outils de gestion de versions décentralisés.

En tout cas cet échange a été un grand plaisir. Premier échange, première émission sur ce sujet-là avec nos invités, Cécilia Bossard de la société Code Lutin et Nicolas Chauvat de la société Logilab. Je vous souhaite une belle fin de journée et à bientôt.

Nicolas Chauvat : Merci beaucoup.

Cécilia Bossard : Au revoir.

Frédéric Couchet : Nous allons faire une pause musicale.

[Virgule musicale]

Frédéric Couchet : Après la pause musicale nous entendrons la chronique de Luk intitulée « Où sont nos génies du business ? » En attendant nous allons écouter Peau Rouge par Les Gueules Noires. On se retrouve dans trois minutes. Belle journée à l’écoute de Cause Commune, la voix des possibles.

Pause musicale : Peau Rouge par Les Gueules Noires.

Voix off : Cause Commune, 93.1.

Frédéric Couchet : Nous venons d’écouter Peau Rouge par Les Gueules Noires, disponible sous licence libre Creative Commons CC BY. J’espère que vous avez eu envie de sauter sur place en entendant ces trompettes, de balancer vos cheveux dans tous les sens avec les guitares et de danser.

[Jingle]

Frédéric Couchet : Nous allons passer au sujet suivant.

[Virgule musicale]

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

Frédéric Couchet : Nous allons poursuivre avec « La pituite de Luk ».
« La pituite de Luk » est une chronique rafraîchissante, au bon goût exemplaire, qui éveille l’esprit et développe la libido. Il a été prouvé scientifiquement qu’écouter la pituite augmente le pouvoir de séduction, augmente le succès dans les affaires, aux examens et décuple le sex-appeal, le retour de l’être aimé, il ou elle reviendra manger dans votre main comme un petit chien. Je précise que c’est évidemment une description signée Luk. Le thème du jour de la chronique « Où sont nos génies du business ? ».

[Virgule sonore]

Luk : Je sais que ce n’est pas de saison, mais moi j’admire quand même un peu Elon Musk. Et pourtant, j’ai usé ma voix un bon paquet de dizaines de fois derrière des stands au contact du public et j’avais été un peu vexé de découvrir comment il avait fait abandonner WhatsApp à des millions de personnes en twittant simplement use Signal. Il faut bien admettre que cette simple injonction avait fait faire un pas dans la bonne direction à pas mal de monde.

Il récidive aujourd’hui en rachetant Twitter. Grâce à lui ce sont encore des millions de personnes qui migrent vers Mastodon. Encore mieux que la dernière fois, car ce coup-ci c’est vraiment libre et décentralisé. J’aimerais pouvoir croire que c’était son plan depuis le début. Je trouve séduisante l’hypothèse qu’il soit un stratège hors-pair qui joue des parties de billard à quatre bandes. En dépit de ces impressionnants résultats, j’ai quand même du mal à m’en convaincre tant cette affaire est chaotique.

Pour résumer les faits de façon tout à fait subjective et imprécise, Musk a déclaré sa flamme à Twitter, mais Twitter ne le calculait pas. De toute façon, comme le petit oiseau bleu tapine pour ses actionnaires, il n’a pas vraiment eu la liberté de choisir son nouveau patron. Alors que l’affaire était déjà bien engagée, Musk s’est soudain indigné que le ramage du piaf ne se rapportait pas du tout à son plumage et a tenté un coïtus interruptus. Mais sous le regard austère de la justice qui l’a rappelé à son devoir, il a dû se résoudre à inonder les poches des actionnaires de ses précieux milliards. Comme Twitter le craignait, Musk lui a fait directement subir les pires outrages et a abîmé son nouveau jouet dès la première semaine.

La procédure judiciaire a rendu publics les échanges privés de Musk et a révélé qu’il n’avait aucun maître-plan. On a découvert ses conversations de type cours de récré avec ses copains milliardaires dont la moitié s’appliquaient à lui lécher les bottes. C’est vraiment ça nos grands génies du business ?

J’apprends dans le même temps qu’Alexa, le bébé de Bezos, est en réalité une très mauvaise gagneuse qui a perdu dix milliards en 2022. Ce génie du business, dont la richesse est inversement proportionnelle au nombre de ses cheveux, s’est planté et a persisté dans l’erreur. Le pire est que ses géniaux concurrents vendent le même genre d’équipement et probablement pour le même genre de résultat.

Coïncidence heureuse, dix milliards c’était la cotation boursière de Theranos, une fabuleuse escroquerie menée par Elizabeth Holmes il y a 20 ans. Elle vient tout juste d’être condamnée à 11 ans de prison pour avoir berné tout l’aréopage du business de l’époque alors qu’elle avait tout juste 18 ans et un aplomb sans faille.

Et où est le génie dans la faillite de FTX ? FTX ? C’est la société de SBF. SBF c’est un mec qui aime les sigles en trois lettres et les cryptomonnaies. Sa tignasse frisée et sa bouille de sympathique adolescent faisaient vibrer ces mêmes cadors des affaires qui avaient signé avec Holmes 20 ans plus tôt. Son nom complet est Sam Bankman Fried soit Samuel Banquier Grillé en bon français. Ce n’est pas un patronyme, c’est de la prédestination, car ce prétendu génie des cryptos, qui militait pour une « régulation de l’industrie », s’est révélé avoir fait tous les trucs tordus qui peuplent les rêves mouillés des banksters conventionnels. Il a même bouché les trous de sa caisse avec les sous de ses clients.

J’ai dit « industrie » en parlant des cryptomonnaies parce que c’est le terme que toute la presse utilise, mais soyons bien clairs, l’industrie crame des mégawatts pour produire des marchandises. Cramer des mégawatts pour calculer des jetons spéculatifs ce n’est pas une industrie, c’est, à minima, un crime contre l’environnement.

Il m’est venu une hypothèse. Le monde est rempli de gens monomaniaques et mégalomanes, de narcissiques qui sont convaincus d’avoir un destin, de brutes qui marcheront sur la tête de n’importe qui pour réussir. Oui, certains sont intelligents, talentueux et travailleurs mais là encore, le monde est rempli d’anonymes qui le sont tout autant. Beaucoup se planteront bien vite, quelques-uns parviendront à monter un truc avant de faire un faux pas fatal. Mon hypothèse est que parmi les centaines de millions de tarés qui ne doutent de rien, il y en a bien une poignée qui évitera les chausse-trappes par pure chance et on ne les considérera à la fin comme des génies que par l’entremise du biais du survivant.

C’est peut-être pour ça que les gens finissent par migrer vers le Libre, parce qu’une fois passées les spectaculaires gesticulations de ces héros autoproclamés, une fois que leur révolution aura démontré son caractère circulaire, le Libre est le seul truc qui reste et qui ait réellement du sens.

[Virgule sonore]

Frédéric Couchet : Nous venons d’écouter la chronique de Luk « Où sont nos génies du business ? » Dans sa chronique, Luk parle du réseau social libre et décentralisé Mastodon. Si vous voulez en savoir plus, je vous invite à écouter le podcast de l’émission de la semaine dernière, l’émission 159, donc sur libreavous.org/159.

Nous approchons de la fin de l’émission. Nous allons terminer par quelques annonces.

[Virgule musicale]

Quoi de Libre ? Actualités et annonces concernant l’April et le monde du Libre

Frédéric Couchet : Mercredi 30 novembre 2022, à Paris, à 20 heures 15, il y aura la projection du film documentaire LoL, logiciel libre, une affaire sérieuse, suivie d’un débat avec Thierry Bayoud, l’un des auteurs de ce film documentaire qui date de 2019, qui dure une petite heure et dans lequel plusieurs personnes libristes sont interviewées.

La radio Cause Commune vous ouvre ses portes vendredi 2 décembre 2022, à partir de 19 heures, pour une réunion d’équipe ouverte au public. Venez nous voir, à Paris dans le 18e.

Du côté de Marseille, AïoLibre, un collectif de structures libristes, organise son apéro mensuel le même soir, le vendredi 2 décembre, à 19 heures.

Ce samedi ont lieu les rencontres mensuelles autour du logiciel libre au Carrefour numérique² de la Cité des sciences et de l’industrie, à Paris, à partir de 14 heures. Venez découvrir des conférences ; il y a aussi une fête d’installation pour découvrir le logiciel libre.

À l’April, nous organisons un apéro vendredi 16 décembre 2022 dans nos locaux à Paris 14e, à partir de 19 heures.

Je précise également que toutes les références utiles, adresses, etc., sont disponibles sur le site de l’émission, libreavous.org. Vous pouvez trouver toutes ces informations sur le site de l’Agenda du Libre, agendadulibre.org, pour trouver aussi d’autres événements en lien avec les logiciels libres et la culture libre près de chez vous.

Notre émission se termine.
Je remercie les personnes qui ont participé à l’émission du jour : Vincent Calame, Nicolas Chauvat, Cécilia Bossard, Luk.
Aux manettes de la régie aujourd’hui, et il a assuré comme un pro pour sa première en solo, on l’applaudit, bravo [applaudissements], Thierry Holleville, bénévole à l’April.
Merci également aux personnes qui s’occupent de la post-production des podcasts : Samuel Aubert, Élodie Déniel-Girodon, Lang1, Julien Osman, bénévoles à l’April.
Également à Olivier Grieco, le directeur d’antenne de la radio.
Merci également à Quentin Gibeaux, bénévole à l’April, qui découpera le podcast complet en podcasts individuels par sujet.

Vous trouverez sur notre site web, libreavous.org, toutes les références utiles, ainsi que sur le site de la radio causecommune.fm.

N’hésitez pas à nous faire des retours. On en discutait avec l’un de nos invités à l’instant, c’est important d’avoir des retours pour indiquer ce qui vous a plu, si ça vous a plu, mais aussi des points d’amélioration, évidemment.
Vous pouvez également nous poser toute question et nous vous y répondrons directement ou lors d’une prochaine émission.
Toutes vos remarques et questions sont les bienvenues à l’adresse contact chez libreavous.org. Si vous préférez nous parler, vous pouvez aussi nous laisser un message sur le répondeur de la radio pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur est 09 72 51 55 46.

Nous vous remercions d’avoir écouté l’émission.

Si vous avez aimé cette émission, n’hésitez pas à en parler le plus possible autour de vous. Faites connaître également la radio Cause Commune, la voix des possibles. Et pour rappel, si vous êtes sur Paris vendredi 2 décembre à partir de 19 heures, vous pouvez venir au 18 rue Bernard Dimey nous rencontrer, pour l’apéro mensuel Cause Commune, chaque premier vendredi du mois.

La prochaine émission aura lieu en direct mardi 6 décembre à 15 heures 30. Notre sujet principal portera sur Le Guide du connard professionnel, c’est le titre d’une BD satirique sur le capitalisme de surveillance, avec ses deux auteurs, Gee et Pouhiou.

Nous vous souhaitons de passer une belle fin de journée. On se retrouve en direct mardi 6 décembre et d’ici là, portez-vous bien.

Générique de fin d’émission : Wesh Tone par Realaze.