---

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 à toutes, bonjour à tous. C’est le moment que vous avez choisi pour vous offrir 1 heure 30 d’informations et d’échanges sur les libertés informatiques et également de la musique libre.

Abolir les barrières entre les équipes de développement et les équipes d’administration système, c’est l’approche DevOps, en tout cas c’est ce que j’en ai compris. Ce sera le sujet principal de l’émission du jour. Avec également au programme la chronique de Vincent Calame sur le Libre et la sobriété énergétique et aussi, en fin d’émission, la chronique de Véronique Bonnet sur le monde du Libre.

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 4 octobre septembre 2022. Nous diffusons en direct, mais vous écoutez peut-être une rediffusion ou un podcast.

À la réalisation de l’émission, il est plein d’énergie, sait rester sobre, a minima digne en toute circonstance, c’est mon collègue Étienne Gonnu. Bonjour Étienne.

Étienne Gonnu : Salut Fred. Bonne émission à vous !

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, intitulée « Sobriété énergétique, longue vie aux objets »

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 une chronique sur le thème du Libre et de la sobriété énergétique, chapitre par chapitre. Le deuxième chapitre, aujourd’hui, est intitulé « Sobriété énergétique, longue vie aux objets ».
Bonjour Vincent.

Vincent Calame : Bonjour Frédéric.
Lorsqu’on parle de sobriété énergétique on pense spontanément à la réduction de notre consommation d’électricité ou de carburant au quotidien. De fait, aucun d’entre nous n’échappera à la question du chauffage cet hiver. Les outils numériques sont aussi concernés par cette question de la diminution de leurs usages puisque la consommation liée au numérique est estimée à 10 % de la consommation électrique en France.

Cependant, quand on fait le bilan énergétique d’un objet, on ne peut pas se contenter de regarder sa consommation quotidienne, il faut aussi regarder l’énergie consommée pour sa construction, qu’on appelle l’énergie grise. Celle-ci est très importante, souvent supérieure à la consommation de l’objet même pendant sa durée de vie. Et je ne parle ici que de l’impact énergétique, il ne faut pas oublier les dégâts environnementaux et sociaux pour l’extraction des métaux nécessaires.

Bref ! Une réflexion sur nos objets électroniques, qui ont envahi notre quotidien, est nécessaire. C’est le sens d’une campagne lancée par l’ADEME, l’Agence gouvernementale pour la transition écologique dont vous avez peut-être vu, comme moi, une publicité dans les journaux. Cette campagne, joliment appelée « Longue vie aux objets », est consultable à l’adresse suivante longuevieauxobjets.gouv.fr.

Frédéric Couchet : Est-ce que ce site parle du Libre ?

Vincent Calame : C’est bien sûr ce que je suis allé regarder en premier. Le site est bien fait, il y a des références intéressantes, par exemple l’estimation de 10% de la consommation électrique citée en début de chronique vient de là, mais, dans les pages que j’ai consultées, je n’ai malheureusement pas trouvé de référence au logiciel libre. Dans le doute, je suis même allé jusqu’à faire une recherche « logiciel libre » via Google, c’est dire !, sur les pages du site, et rien de pertinent ne m’a été retourné.

Frédéric Couchet : Et pourtant, le logiciel libre est un bon moyen de prolonger la vie d’un ordinateur !

Vincent Calame : Tout à fait. Je pense que nous n’apprenons rien aux auditrices et auditeurs fidèles de cette antenne, car ce sujet a souvent été traité, que ce soit dans les chroniques d’Antanak, dans certains sujets longs, par exemple dans l’émission n°70 sur le réemploi informatique, la n°36 sur l’obsolescence programmée, la n°118 sur la téléphonie mobile libre. Je m’arrête là dans l’énumération, ça pourrait faire l’objet d’un futur chapitre de ma chronique.

Frédéric Couchet : J’en profite pour signaler aux personnes qui souhaitent retrouver une émission par son numéro sur le site web que c’est simple, c’est libreavous.org/le numéro de l’émission. Si vous voulez réécouter l’émission 70 sur le réemploi informatique vous allez sur libreavous.org/70.

Vincent Calame : Tout à fait.
Je prendrai, pour illustrer propos, deux exemples récents.
Le premier est un article du site ZDNet, recensé par la revue presse de l’April de début septembre, article intitulé « Vous voulez donner une seconde vie à votre vieil ordinateur, essayez ces distributions Linux ». Tout est dans le titre, seconde ou longue vie, l’idée est la même. À côté des distributions GNU/Linux les plus connues qui sont à la pointe pour fonctionner sur les appareils les plus récents, il existe, en effet, des distributions qui se concentrent sur l’installation sur du matériel ancien en proposant notamment des environnements de bureau plus légers, c’est-à-dire qui ne conservent que les fonctions essentielles pour un usage bureautique de base. On ne fera évidemment pas tourner dix logiciels en même temps sur ces machines, mais elles pourront bien nous dépanner en cas de besoin ou servir au petit dernier de la famille.

Mon deuxième exemple, plus vécu personnel. On m’a signalé récemment qu’un site sur lequel je travaille n’est visible, sur un vieux Mac, que sur Firefox, mais, par exemple sous Safari, le navigateur par défaut, il n’est pas visible. Après investigation, j’ai découvert que cela venait du durcissement des normes de sécurité du protocole HTTPS, le protocole qui permet d’afficher les pages de manière sécurisée. Pour gérer ce protocole, le navigateur Safari se reposait sur le système d’exploitation alors que le logiciel Firefox le gérait de manière indépendante. Comme c’était un vieux Mac et qu’il n’était plus maintenu, Safari n’était plus utilisable, CQFD.

On voit ici l’importance stratégique des grands logiciels libres multi-plateformes comme Firefox et LibreOffice pour maintenir en vie des systèmes anciens.

Je pense qu’on pourrait multiplier les exemples à l’infini. Malheureusement ils vont surtout concerner les ordinateurs où, heureusement, nous pouvons encore installer ce que nous voulons. Le problème est beaucoup plus ardu pour les téléphones et les tablettes ; il n’est pas simple, sans accompagnement, d’installer ce qu’on veut. Or, les téléphones sont aussi les objets numériques qui sont renouvelés le plus souvent. Est-ce une simple coïncidence ? Je vous laisse juges.

Sur le site Longue vie aux objets, un onglet est destiné aux entreprises. Dans celui-ci, une entrée est destinée spécifiquement aux producteurs d’objets numériques intitulée, attention, je cite « Alertez vos clients sur les mises à jour qui peuvent ralentir ou rendre prématurément obsolètes des appareils. » Dans cet article il y a une phrase presque cocasse, je trouve : les fabricants vont avoir, entre guillemets, « une obligation d’information sur la durée pendant laquelle les mises à jour logicielles permettent un usage restant normal des appareils ». Soyons sérieux, au vu des enjeux ce n’est pas une obligation d’information qu’il faut mais bien une interdiction de ces pratiques, tout simplement.

On voit ici que si le logiciel libre est utile pour atteindre la sobriété énergétique, celle-ci, en retour, peut aussi être un levier efficace dans la lutte pour la libération de nos téléphones en une sorte de donnant-donnant dans ces deux combats.

Frédéric Couchet : Merci Vincent. J’en profite pour rappeler que toutes les références citées seront sur le site de l’émission, libreavous.org, et sur le site de la radio, causecommune.fm.

Vincent Calame : J’ai également mis dans les références un article du journal en ligne Basta !, qui était aussi recensé par la revue presse de l’April récemment, qui développe bien les questions abordées ici. Un journal de ce type-là, plutôt à destination de militants, est aussi une bonne source de nouvelles références.

Frédéric Couchet : Basta ! publie régulièrement des articles sur le logiciel libre. Je renvoie aussi à un article récent, très fouillé, qui concerne le logiciel libre, notamment dans le monde de l’éducation. C’est effectivement une belle référence. Merci Vincent.
On se retrouve le mois prochain pour le chapitre 3 de ta chronique sur la sobriété énergétique,

Vincent Calame : Tout à fait.

Frédéric Couchet : Belle journée Vincent. Nous allons faire une pause musicale.

[Virgule musicale]

Frédéric Couchet : Après la pause musicale, nous parlerons de DevOps. On va essayer de vous faire comprendre ce que signifie ce terme.

J’ai choisi la pause musicale quelque part en hommage à la chronique de Vincent, car ça va parler de 4x4 qui pue. Nous allons en effet écouter 4x4 par JeanBleu. On se retrouve dans moins de deux minutes. Belle journée à l’écoute de Cause Commune, la voix des possibles.

Pause musicale : 4x4 par JeanBleu.

Voix off : Cause Commune, 93.1.

Frédéric Couchet : Nous venons d’écouter 4x4 par JeanBleu, disponible sous licence libre Creative Commons Partage dans les mêmes conditions, CC By SA.

[Jingle]

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

[Virgule musicale]

DevOps - Abolir les barrières entre les équipes de développement et les équipes d’administration système - avec Xavier Talon et Romain Soufflet

Frédéric Couchet : Nous allons poursuivre par notre sujet principal qui va porter sur l’approche DevOps, c’est-à-dire, en tout cas c’est ma compréhension, abolir les barrières entre les équipes de développement et les équipes d’administration système. Nos invités du jour sont Xavier Talon, cofondateur et directeur technique de la société Orness, président de DitRit, association loi 1901 d’intérêt général qui traite de la transformation numérique et Romain Soufflet, SRE indépendant, SRE voulant dire Site Reliability Engineering, mais comme mon anglais est pourri, je vais vous le faire en français aussi : ingénieur de fiabilité de site. Il nous expliquera évidemment tout à l’heure ce que signifie SRE.
Bonjour Xavier.

Xavier Talon : Bonjour.

Frédéric Couchet : Bonjour Romain.

Romain Soufflet : Bonjour.

Frédéric Couchet : N’hésitez pas à participer à notre conversation au 09 72 51 55 46 ou sur le salon web dédié à l’émission, sur le site causecommune.fm, bouton « chat », salon #libreavous.
On va commencer par une petite question classique que vous allez maîtriser, une présentation personnelle rapide. On va commencer par Romain Soufflet.

Romain Soufflet : Je suis ingénieur développeur à la base, sur du Python. Je suis progressivement passé sur les questions plutôt DevOps et opérationnelles, c’est là que je suis arrivé à être indépendant SRE. Le SRE va traiter de la stabilité des sites en production et de l’aide aux développeurs dans ce cadre-là, et on va en parler pendant pas mal de temps.

Frédéric Couchet : Tout à fait. Xavier Talon ?

Xavier Talon : J’ai participé à la création de la société Orness, ça fait déjà 22 ans. Au départ on était effectivement sur des problématiques toujours très techniques, on travaillait pour des grands comptes où on avait des problématiques d’ingénierie assez classiques. On a fait pas mal de choses et, dès le départ, on était assez motivés. On a été des gros défenseurs, on a essayé de poser des aspects du logiciel libre chez nos clients.

Et puis on a assisté à pas mal de révolutions, petit à petit, avec l’arrivée de nouvelles technologies, notamment le cloud, toutes sortes de choses, et puis le DevOps. Avec ça, on a rencontré de nouvelles problématiques et un nouveau champ d’action qui nous a permis de voir qu’il y avait vraiment de grosses améliorations à faire et de grosses difficultés à abolir, pour lesquels on pouvait avancer et créer beaucoup de valeur, d’où un gros tournant dans la société, c’est devenu un de nos axes principaux. Je pense qu’on va en reparler, ça a été aussi l’occasion de créer l’association DitRit qui travaille sur ces problématiques-là. C’est une association loi 1901 qui essaye de traiter ces problématiques, notamment par l’incubation de logiciels libres.

Frédéric Couchet : On reviendra bien évidemment tout à l’heure, notamment en fin d’émission, sur la partie DitRit. On va commencer par une question un peu simple. D’ailleurs je précise que c’est Xavier Talon ou plutôt Carole Amado, l’une des cofondatrices d’Orness, qui m’a proposé, il y a quelque temps, de traiter ce sujet de DevOps. Ma première réaction a été de me dire « DevOps sur une émission grand public ! C’est un défi ». En même temps, à l’April, on aime bien les défis et on s’est dit qu’on allait inviter les gens qui savent en parler.

Évidemment, si je parle de DevOps aux gens, les deux termes qu’ils entendent, c’est « Dev » et « Ops ». On voit bien que « Dev » fait référence au développement, « Ops » operations, « opérationnels ». Peut-être qu’on va commencer par préciser ces deux termes. Le premier est peut-être mieux connu, en tout cas le rappeler, et le deuxième terme, avant d’entrer dans les détails. Qui veut commencer ? Romain Soufflet.

Romain Soufflet : Très bien, on va commencer par là.
Effectivement, développeur, on arrive très bien à comprendre ce que c’est, c’est devenu plus facile à comprendre pour un peu tout le monde maintenant. On a des développeurs qui sont plus nombreux qu’il y a 30 ans et encore plus nombreux qu’il y a 50 ans, donc maintenant on a une assez bonne compréhension, globalement, de ce que sont par nature les développeurs. Ils se concentrent à changer les applications. Leur métier c’est vraiment d’ajouter des fonctionnalités, d’ajouter des corrections de bugs, de faire en sorte que les applications évoluent pour que les utilisateurs puissent avoir de nouvelles fonctionnalités.

Les opérationnels sont ceux qui vont s’occuper des serveurs physiques pour que l’application soit disponible pour leurs utilisateurs. L’objectif des opérationnels, par définition, c’est que ce soit stable et que l’utilisateur qui a besoin de l’application à deux heures du matin puisse s’en servir.

Le développeur est axé sur le changement, l’opérationnel sur « une fois que ça marche, on ne veut plus trop à y toucher », donc ils sont amenés, par nature, à être en conflit, et c’est là que la culture DevOps est née. On est une même entreprise, on a un même objectif : servir nos utilisateurs, il faut qu’on travaille ensemble.

C’est comme ça que je définirais ce terme, avec ces deux métiers principaux : développeur et opérationnel.

Frédéric Couchet : Xavier, est-ce que tu veux compléter cette partie de définition ?

Xavier Talon : Oui. Ce n’est pas si facile que ça. Il faut savoir une chose, c’est qu’il n’y a pas réellement de définition figée, normative, de ce qu’est DevOps, de même qu’il n’y a pas non plus de manifeste, comme il y a un manifeste Agile. Le mieux, pour définir, c’est de considérer que c’est une approche qui vise à améliorer la performance, qui vise effectivement à abolir un petit peu les silos, toutes les difficultés, toutes les frictions qui peuvent se passer, notamment entre les Devs, on l’a vu, et les Ops, mais pas que ! Pour faire tourner un logiciel on a besoin de développeurs, on a besoin de gens qui vont faire les opérations, on a besoin de gens qui vont faire la sécurité, aussi de gens qui vont gérer les budgets. On a fait l’acronyme DevOps, mais en fait, on a aussi le DevStackUp, le DevFinOps, etc. C’est finalement vraiment ce principe d’essayer de mettre de l’agilité, de fluidifier un petit peu les principes, de faire qu’on va être beaucoup plus efficients dans la construction des logiciels et surtout, d’arriver beaucoup plus vite à un résultat donné. Beaucoup plus vite !, on va essayer de donner beaucoup plus de capacités à voir l’évolution et à aller dans le bon sens, de corriger les évolutions au fur et à mesure qu’elles vont venir. Ce sont tous ces objectifs qui visent vraiment à l’efficience, qui sont traités par le DevOps, par cette approche. Après, on a différents moyens d’y accéder.

Frédéric Couchet : On va y revenir. J’ai deux questions. On va commencer par la première. Tu as a parlé de l’agilité. Peut-être que les gens qui font du sport ont une vision de l’agilité, mais qu’est-ce que l’agilité dans le domaine de l’ingénierie informatique ? Est-ce que tu peux présenter ça rapidement ?

Xavier Talon : L’agilité va consister à essayer de mieux exploiter les ressources, les capacités de l’ensemble des personnes, de mieux lisser les communications entre les personnes et, surtout, à essayer de faire une amélioration continue, beaucoup plus visible, qui permettra d’être beaucoup plus en accord avec le besoin. Entre le moment où on écrit le code et le moment où il va être en production, il y a beaucoup d’activités différentes à réaliser : la mise en place des serveurs, leur installation, la sécurité, etc., qui sont nécessaires pour que le logiciel puisse tourner. Quand on faisait un logiciel on va dire à l’ancienne, il y a quelques années, typiquement il pouvait se passer facilement six mois, un an, parfois plus, entre le moment où on voulait concevoir un logiciel et le moment où le logiciel allait tourner. Pendant ce temps-là, on a un tunnel ; que va t-il se passer ? Il faut attendre tout ce temps pour pouvoir avoir un résultat et, sans doute, s’apercevoir que ce n’était pas tout à fait ce qu’on visait.

Quand on va arriver sur des approches d’agilité, on va essayer de faire plus petit, plus vite et de manière cyclique. On va essayer de se dire « fixons-nous non pas directement la cible qu’on peut atteindre, mais une première étape où on va pouvoir aller rapidement et voir un premier résultat qui va permettre de corriger le tir puis faire une deuxième petite étape qui sera améliorée par rapport à cette première itération ». Et on va aller comme ça, petit à petit, jusqu’au bout. On ne va pas forcément plus vite sur le tout, par contre, très rapidement, on voit les déviances et on peut corriger, on peut améliorer et ça apporte énormément de qualité, énormément de stabilité.

Frédéric Couchet : Et aussi une adéquation entre les besoins réels de l’équipe cliente et ce que développe l’équipe de développement, plutôt que de livrer au bout de x mois quelque chose qui ne correspond pas aux besoins ; ces itérations continues permettent de correspondre aux besoins.
J’aimerais juste préciser qu’on a consacré une émission sur l’agilité, c’est l’émission n°59. Si vous avez écouté le début de l’émission, c’est libreavous.org/59.

Merci pour la précision sur l’agilité.
Ma deuxième question, pour tous les deux : tu as parlé d’approche DevOps, c’est d’ailleurs ce que j’ai utilisé dans le titre de l’émission. On voit « DevOps » sur des CV, aujourd’hui c’est très à la mode. Est-ce que DevOps est un métier en tant que tel, est-ce un nouveau métier en tant que tel ? Ou est-ce, finalement, une approche qui est mise en œuvre par des gens dont le métier existe déjà, qui sont soit développeur ou développeuse soit dans l’administration système. Est-ce que c’est un métier ou une approche ? Romain.

Romain Soufflet : C’est un sujet qui me tient à cœur. En tant qu’indépendant, quand je mets « DevOps »sur mon CV – c’est d’ailleurs ce que j’ai fait, je ne m’en cache pas – c’est que j’ai besoin d’éclaircir avec le client ce qu’il entend par DevOps. Le souci de cette approche DevOps, de cette culture DevOps, c’est que c’est tellement large, ça regroupe tellement de métiers différents, que c’est à peu près impossible de dire « je suis DevOps » et de maîtriser l’ensemble des sujets.
Comme le disait Xavier, ça prend parfois de la finance – le coût des serveurs, le coût des applications qu’on utilise ; parfois ça peut être de la sécurité informatique ; parfois on va parler donc des backups, donc des sauvegardes, des solutions de stockage, qui sont plus de la base de données. C’est impossible, pour une seule personne, de maîtriser tous ces aspects-là. Donc, au final, dire « Je suis DevOps », c’est quand même assez difficile, parce que ça regroupe vraiment beaucoup trop de choses.

C’est pour ça que moi, dans ma présentation, je me revendique comme SRE, un terme un peu à la mode dans le milieu dans lequel nous évoluons, donc ingénieur de fiabilité de site en français, mais, au final, c’est une implémentation de cette culture DevOps. C’est un poste qui va consister à s’occuper de la stabilité de la production afin de s’assurer qu’elle est toujours en place, qu’on a de bonnes informations sur comment elle tourne, est-ce qu’elle tourne bien, est-ce qu’elle tourne de manière optimale ou de manière un petit peu dégradée ? Voilà ! Mon métier va être vraiment sur cet aspect « maintien en conditions opérationnelles ».

Mais dire que DevOps est un métier, c’est beaucoup trop difficile. C’est trop large pour qu’une seule personne puisse le maintenir.

Frédéric Couchet : Juste avant que Xavier complète sur SRE, donc « ingénierie de la fiabilité des sites », je suis quand même allé me renseigner un petit peu avant et je vois que sur la page Wikipédia il y a une citation de Ben Treynor, fondateur de la team, l’équipe SRE de Google, qui dit : « SRE est ce qui se passe quand un ingénieur ou une ingénieure logiciel est chargée de ce qu’on appelle des opérations ». C’est ça, en fait ?

Romain Soufflet : Oui, c’est ça, c’est-à-dire que tout ce qui va être automatisable va être automatisé. On va voir le déploiement non pas comme une tâche d’administrateur système qui va devoir le faire à la main, mais comme un projet informatique à part entière. Les développeurs écrivent les applications et, de mon point de vue, les développeurs sont mes clients, c’est-à-dire que je dois leur fournir des outils et une infrastructure pour que leurs applications viennent s’interfacer avec la mienne et se mettre en production, je vais dire un peu toutes seules, de manière un peu magique, qui va faire que tout fonctionne, sera monitoré correctement, avec de bonnes métriques, avec de quoi donner au management, on va dire, les informations sur ce qui est en ligne, ce qui tourne bien, de quelle manière. C’est vraiment un projet de développement, le développement de l’infrastructure.

Frédéric Couchet : On parlera des outils tout à l’heure, dans une deuxième partie.
On va poursuivre là-dessus, toujours sur ma question. Ce coup-ci Xavier Talon.
Donc, c’est un métier, c’est une approche. Tu disais, en introduction, que Orness s’est maintenant positionnée sur cette pratique du DevOps. Par rapport à ça, c’est un métier, c’est une approche, comment cela se passe-t-il en fait ?

Xavier Talon : L’objectif de DevOps, c’est, comme on le disait, de réussir à aller vite sur des fonctionnalités bien définies, délimitées, pour faire des cycles courts. Pour le coup, c’est là où le DevOps est un peu une extension de l’agilité que nous sommes habitués à voir plutôt au niveau des développeurs, le DevOps c’est l’idée de le faire sur l’ensemble des métiers qui sont nécessaires pour supporter l’application. Ça veut dire qu’il va falloir faire des petites équipes où on va avoir toutes les compétences : développement, opérations, sécurité ; toutes les technologies qui vont être derrière : la qualité, le testing, etc. On voit tout de suite la complexité qui se pose : il faut que l’équipe maîtrise tous ces aspects. Par l’automatisation, les outils, on facilite les choses, mais comment va-t-on le réaliser ?

On a besoin et on voit apparaître des nouveaux métiers, on voit aussi apparaître des projets où on s’imagine qu’on va avoir le profil DevOps qui est capable de gérer tous ces aspects. C’est un peu une utopie, ça n’est pas réalisable, il y a assez peu de moutons à cinq pattes ! Par contre, on voit qu’on va, d’une manière ou d’une autre, devoir, dans les équipes, introduire toutes ces compétences. Du coup, il va aussi falloir lisser un petit peu le processus, voir globalement comment on met en place de la qualité et on a de nouveaux métiers, comme le SRE, dont le rôle est d’assurer la qualité un petit peu transversale de tout ça.

Donc, il y a pas de métier DevOps. Il y a un ensemble de métiers, il y a aussi un ensemble de nouveaux métiers et on a besoin de réussir à mettre en musique toutes ces compétences au sein de petites cellules qui vont être capables d’aller très vite pour pouvoir fournir, au rythme de deux semaines à deux mois, des petites release, des nouvelles versions d’une solution, d’une application, qui vont permettre de granter systématiquement de plus en plus de qualité et de stabilité dans les produits.

Frédéric Couchet : J’ai une question par rapport à ce que tu décris. Historiquement il y a plutôt souvent un antagonisme entre les équipes de développement et les équipes de maintenance ou d’administration système, parce qu’en fait les objectifs ne sont pas les mêmes. L’équipe d’administration système veut que ça fonctionne, qu’il n’y ait pas de bugs, là où les équipes de devs, souvent, veulent livrer le plus vite possible, etc. Est-ce que l’un des enjeux ou l’un des défis de DevOps c’est de réunir ces personnes qui ont, à priori, des antagonismes historiques de fonctionnement dans une même équipe, pour que les deux travaillent en cohérence avec, au final, rendre un système opérationnel pour la partie cliente, qui est le plus important ? Xavier.

Xavier Talon : C’est bien sûr tout l’objectif. L’idée c’est effectivement d’enlever les barrières qu’on va avoir. On a deux populations qui ont effectivement des objectifs contraires : les gens qui vont développer veulent introduire de nouvelles fonctionnalités. Toute nouvelle fonctionnalité implique des changements, donc un risque sur la stabilité du système. Pour les Ops, l’objectif primaire, s’ils ne prennent que celui-là, c’est d’assurer la stabilité du système, d’empêcher qu’il y ait quoi que ce soit qui vienne l’impacter, du coup on voit tout de suite cette friction. Maintenant, une des idées principales du DevOps c’est tout simple, c’est de remettre l’humain au centre, de prendre les différentes populations et qu’elles discutent directement autour d’une table.

Frédéric Couchet : Donc l’humain et la communication ?

Xavier Talon : Exactement, et c’est le point principal. Quand on met des personnes ensemble, avec une qui va dire « moi, j’ai besoin de faire telle fonctionnalité. Comment va-t-on mettre ça au niveau technique ? » et que l’autre, en face, voit l’objectif, on va pouvoir immédiatement interagir, on va résoudre les problèmes en quelques minutes, là où, de manière classique, dans un mode d’organisation comme on pouvait l’avoir il y a quelques années, eh bien ça serait passé par des équipes qui communiquent via des mails, qui vont faire des réunions, qui vont avoir des comptes-rendus, des niveaux de décisions à prendre, etc., et la même problématique pouvait prendre des mois !

Frédéric Couchet : Romain, tu veux compléter ?

Romain Soufflet : C’est tout à fait ça. En pratique on a effectivement cette difficulté. Dans certaines grosses entreprises, par exemple, le pôle sécurité n’est pas du tout convié dans les processus de développement et se retrouve, à la fin du développement, à dire « pourquoi ne nous a-t-on pas appelés ? »
Il y a effectivement cette culture DevOps qui a du mal à s’implanter dans des structures qui ont été organisées il y a pas mal de temps. C’est pour ça qu’on parle plus de culture et de philosophie DevOps. Dans beaucoup d’entreprises qui ont des modèles où l’humain n’est pas réellement au centre, où l’application non plus n’est pas réellement au centre, il y a une vraie transition à effectuer. Typiquement, cette équipe sécurité est souvent vue comme un ennemi du développement, c’est malheureux, mais on les prend un peu pour des empêcheurs de tourner en rond. Leur travail c’est la sécurité, c’est de s’assurer que ça fonctionne bien à la fin, mais, comme on leur en parle beaucoup trop tard, ça ne fonctionne pas bien et ça crée vraiment des divergences énormes dans les entreprises.

C’est aussi pour ça qu’on parle de transition DevOps, c’est vraiment une question organisationnelle. Je sais que pour moi, personnellement, c’est très difficile d’agir là-dessus, parce que, comme je suis indépendant, je suis tout seul par nature, arriver tout seul dans une grosse structure et dire « vous vous organisez mal en termes de structure, on a besoin de se parler tous ensemble », c’est parfois un discours qui a du mal à passer et c’est ce qui fait que notre métier est quand même assez difficile.
Il y a une grosse composante organisationnelle, restructuration des équipes et communication inter-équipes à faire entrer en jeu.

Frédéric Couchet : D’où ma question. Tu viens de parler de grosses structures. Tout à l’heure Xavier Talon, dans son introduction, a parlé de petites équipes. Est-ce que cette approche culture, philosophie DevOps s’applique à tout type de projet ? Quelle est la différence entre appliquer DevOps dans une équipe de développement et d’opérationnels qui est toute petite, donc une petite structure, et quel est le défi de le faire dans une grosse structure, comme vient de le citer Romain, une grande banque ou une grande collectivité, que sais-je ? Je suppose que les défis ne sont pas les mêmes et que la mise en œuvre n’est pas la même. Xavier Talon.

Xavier Talon : Oui. Ce sont des problématiques qui sont de niveaux différents et c’est ce qu’on va appeler la mise à l’échelle. Vous avez des méthodologies qui commencent à expliquer comment on peut faire de l’agilité, Scrum par exemple. Scrum est une des méthodes qui permet de faire de l’agilité.

On s’aperçoit déjà que la problématique de faire des petites équipes avec toutes les compétences, pour un petit projet, n’est pas simple. Quand il s’agit de traiter un parc global ou des applications qui sont ce qu’on appelle des monolithes, des grosses applications, énormes, avec énormément de fonctionnalités, etc., ça devient beaucoup plus compliqué. Du coup, si on veut l’agilité, DevOps lui-même ne va pas marcher, en termes d’équipes, si on a des centaines de personnes. Or on a forcément des niveaux, des parcs applicatifs et des applications-mêmes, uniques, qui demandent d’organiser un très grand nombre de personnes. Comment va-t-on faire ? Il faut réussir à décomposer les problématiques pour que différentes petites équipes puissent traiter chacune un bout. Sauf que, du coup, il faut assurer la cohérence. Donc il va falloir trouver un cadre méthodologique pour réaliser ça et ça devient assez compliqué.

On a des méthodologies qui arrivent, qui sont mises en place, qui sont vraiment des méthodologies pour le coup assez complexes. Safe, typiquement, est une méthodologie de montée à l’échelle qui a justement pour objectif de monter ou d’organiser un système d’information pour qu’on puisse traiter à l’échelle, selon la méthodologie Agile DevOps, des parcs beaucoup plus importants. Là aussi c’est assez compliqué, ce n’est pas la seule méthodologie. Ce sont des méthodologies qui devraient se prêter un petit peu à toutes les caractéristiques or chaque système d’information est spécifique, on a un ensemble de technologies qui peuvent être extrêmement différentes, des organisations de comptes qui peuvent être complexes à gérer. Ce sont des vrais chantiers de transformation qui sont vraiment importants et qui sont difficiles à mettre en œuvre. Typiquement, il faut considérer qu’il faut une bonne dizaine d’années pour transformer l’organisation d’un grand compte, pour aller d’une organisation classique, type ITIL [Information Technology Infrastructure Library ] qu’on pouvait avoir avant, et ça. Pourquoi ? Parce que toutes ces nouvelles méthodologies et ces approches agiles sont très différentes, très clivantes par rapport aux organisations qu’on avait avant. On avait tendance, effectivement, à structurer, à siloter, on a une culture d’entreprise qui est construite et qui s’est consolidée pendant 30 ans, 40 ans, sur ces modèles, qui visaient justement à découper, à siloter, à stratifier et à organiser par des outils de communication le passage entre les équipes. En fait, il s’agit de déstructurer tout ça et de remettre une organisation qui est, effectivement, complètement à l’opposé et c’est d’une complexité énorme.

Le problème n’est pas technique. On sait comment faire la mise en place du DevOps, on sait trouver les cibles, mais il n’y a rien de plus difficile que de modifier les usages, la manière dont les gens travaillent, l’organisation. Faire du DevOps, c’est aussi un nouveau type de métier, de nouvelles manières de gérer du personnel, donc, c’est aussi une remise en cause des RH, des budgets. C’est une transformation très globale du système d’information.

Frédéric Couchet : Plutôt une problématique de grands comptes, on a bien compris. Je suppose qu’il faut un engagement très fort de la direction générale. Quelle est votre première approche pour les convaincre, leur dire qu’on va se lancer dans un chantier de dix ans pour refondre toute l’organisation. C’est quoi ? C’est le fait de produire des logiciels de meilleure qualité ? Le plaisir des équipes qui vont travailler, parce que, justement, elles vont travailler différemment, donc avec plus de plaisir ? Quelle est votre première approche pour essayer de convaincre de se lancer dans cette étude d’une migration vers une approche DevOps. Romain puis Xavier.

Romain Soufflet : De mon expérience, les entreprises m’appellent parce qu’elles ont déjà mis en place ou elles ont la volonté de mettre en place cette transition DevOps. De mon point de vue, la transition est surtout basée sur la technique. Techniquement, les applications ont énormément évolué ces dix dernières années, avec surtout l’arrivée des clouds publics, l’informatique en nuage en français. C’est donc une nouvelle manière, on va dire, de gérer sa production. Ce sont des produits qui coûtent cher, qui ont besoin de nouvelles compétences pour être utilisés, donc, à partir de là, la mise en production est plus simple. Mais ce sont surtout des problématiques de marché, en fait, qui incitent les entreprises à vouloir déployer plus vite, plus rapidement et plus souvent de nouvelles fonctionnalités ; d’être plus agiles comme l’agilité d’un sportif, de pouvoir bouger plus facilement et plus rapidement pour réagir aux utilisateurs, aux usages. C’est cet usage d’utilisateur final qui pousse les entreprises à se remettre en question et à faire cette transition DevOps.

De mon expérience, ce ne sont pas des prestataires comme moi qui viennent pour pousser cette transition. Le client demande, il veut transitionner vers un modèle DevOps, vers un modèle plus agile, plus rapide et c’est à partir de là que les problèmes commencent parce que la plupart des grosses entreprises ne sont clairement pas structurées de cette manière-là. C’est effectivement beaucoup plus facile d’être agiles et d’être DevOps pour des petites équipes, en étant une petite équipe on se parle beaucoup plus facilement. Les problèmes viennent justement avec cette mise à l’échelle des grosses entreprises où on est 5 000, où c’est quand même difficile de connaître tout le monde, de partager et de communiquer.

Frédéric Couchet : Je suppose que la problématique est la même pour Orness et je suppose – mais tu vas confirmer ou infirmer, Xavier – que vous avez peut-être une démarche un peu plus proactive vers vos clients actuels ou vers de nouveaux clients pour, entre guillemets, « leur vendre l’intérêt d’une démarche DevOps ».

Xavier Talon : Comme le disait Romain, on n’a pas vraiment besoin de le défendre. Aujourd’hui c’est une évidence c’est-à-dire que les clients, depuis un certain nombre d’années, se retrouvent effectivement avec, quelque part, une organisation, un existant qui est lourd, qui est difficile. Ils vont souvent se retrouver en concurrence avec des sociétés qui se mettent immédiatement, en partant de rien, dans un mode d’organisation beaucoup plus facilement agile, puisqu’elles partent de rien, elles n’ont pas tout cela à adapter. En fait, ils n’ont pas le choix, ils se retrouvent, de facto, face à des concurrents. Quand à eux il faudra six mois, un an, sinon plus pour sortir un nouveau produit, le même produit, avec le même niveau de conception, va arriver immédiatement sur le marché. Par exemple la Fintech, une entreprise de la finance, va peut-être pouvoir le sortir en trois semaines par rapport à une banque. Elle est sur un mode, un petit peu société nouvelle génération et va pouvoir s’organiser sans avoir l’historique, sans avoir à gérer tout un existant.
À partir de ce moment-là, pour eux, c’est vital. De toute façon la plupart de nos clients, ces grands comptes, n’ont pas vraiment le choix. Il faut pouvoir adapter les mêmes outils, les mêmes démarches, les mêmes capacités, qu’a la concurrence.

Je disais tout à l’heure qu’il faut une dizaine d’années pour se transformer, pour arriver à maturité. Bien évidemment, on peut commencer à faire des choses, à transformer le système d’information, étape par étape, en mettant les choses. Les évolutions technologiques et tous les nouveaux outils dont on dispose permettent de faire beaucoup de choses. Après, pour réussir à transformer une organisation à tous ces niveaux dont on parlait, aussi bien la finance, la gestion, l’organisation, la gouvernance, ça prend évidemment beaucoup plus de temps. La plupart des grands comptes français ont commencé leur transformation vers ces objectifs-là depuis plusieurs années, il y a déjà cinq, sinon plus, souvent déjà depuis sept/huit ans.

Frédéric Couchet : D’accord. On va faire une pause musicale. Après la pause musicale, on va voir un peu plus en pratique comment ça se met en place dans des organisations. En attendant, nous allons écouter Un instant par Tchip et Odysseus. On se retrouve dans environ deux minutes. Belle journée à l’écoute de Cause Commune, la voix des possibles.

Pause musicale : Un instant par Tchip et Odysseus.

Voix off : Cause Commune, 93.1.

Frédéric Couchet : Nous venons d’écouter Un instant par Tchip et Odysseus, disponible sous licence libre Art Libre.

[Jingle]

Frédéric Couchet : Nous allons poursuivre notre sujet principal qui porte sur l’approche DevOps, avec nos invités Xavier Talon et Romain Soufflet.
Je vous rappelle que vous pouvez participer à notre conversation au 09 72 51 55 46. Si vous avez des questions, ou des réponses, n’hésitez pas à nous appeler.

On a un petit peu dégrossi, à gros traits, avant la pause musicale ce qu’est DevOps. J’annonçais, avant la pause, qu’on allait peut-être un peu rentrer dans la mise en œuvre ou les conseils pour commencer la mise en oeuvre. Pendant qu’on écoutait cette belle musique, Romain Soufflet me disait que son premier conseil c’était de boire des bières avec les équipes. Donc, ma question, plus généralement, c’est comment commencer à mettre en œuvre cette philosophie, cette approche DevOps dans une équipe ? Toi, ta réponse, c’est la bière ou toute autre boisson non alcoolisée ou alcoolisée.

Romain Soufflet : Étant indépendant, encore une fois, j’arrive dans une entreprise, je suis tout seul et c’est vrai que les apéros entre collègues ou la machine à café ce sont vraiment les points privilégiés pour moi pour entrer dans l’entreprise, rencontrer un maximum de personnes. Comme ça, quand j’ai besoin de parler à la sécurité, je sais à qui il faut que je parle ; si j’ai besoin du soutien utilisateur, les services qui répondent aux demandes clientes, au moins je sais à qui en parler, et ainsi de suite.

Dans les entreprises où il y a des apéros ou des bières, j’y invite le maximum de personnes parce que c’est là où on fait des ponts entre les silos organisationnels, les différentes structures de l’entreprise et les personnes qui, au final, travaillent ensemble depuis 15 ans sans jamais s’être parlé ou sans jamais se voir. Le fait de se voir à la machine à café ou devant une bière permet vraiment de casser les barrières et de faire en sorte que les différentes personnes de l’entreprise se parlent.

En général, c’est vrai que le premier conseil que je donne c’est « faites des apéros » et ça a tendance à bien marcher dans les différentes expériences que j’ai eues jusqu’à maintenant. C’est quelque chose qui anime une communauté, ça fait vraiment faire communauté dans l’entreprise, ça permet d’abolir les barrières, d’augmenter la communication et, en plus, ça ne coûte pas cher.

Frédéric Couchet : Et de remettre de l’humain donc la communication au centre. J’aurais tendance à dire qu’une entreprise qui, au bout de 15 ans, n’a toujours pas organisé d’apéro ou de rencontre conviviale, peut-être qu’il faut en changer aussi, mais c’est un autre sujet !

Romain Soufflet : C’est un autre sujet.

Frédéric Couchet : Même question pour Xavier. Là, on a parlé plutôt d’une petite structure. Les grands comptes organisent aussi des événements. Comment cela se passe-t-il dans un grand compte ? Quelle est la première approche, comment cela se passe-t-il quand vous arrivez ?

Xavier Talon : Quand on arrive, c’est exactement le même problème qui reste à résoudre : comment faire que les gens communiquent effectivement directement. Ce n’est pas seulement vrai mais ça a toujours été un peu vrai, de fait beaucoup de choses se font à la machine à café. Quand on est là pour chercher à aplanir des complexités, des difficultés qui sont posées entre des équipes qui ne sont pas forcément alignées, des gens qui ne maîtrisent pas forcément les besoins d’une autre équipe, etc., la seule manière et la manière la plus évidente de les résoudre, la plus efficace, c’est que les gens parlent. Donc réussir à introduire des moments, dans la journée, où les gens vont pouvoir directement discuter autour d’un café, autour d’un repas, ça fait énormément avancer un projet. C’est la réalité.
Après, dans des grands comptes, on peut avoir effectivement des organisations très différentes, parfois les gens qui vont écrire le code sont encore outsourcés, pourquoi pas dans un autre pays.

Frédéric Couchet : Outsourcé, c’est quelqu’un qui travaille à l’étranger, en dehors de l’entreprise.

Xavier Talon : Voilà, et qui répondent à des commandes. Là, évidemment, on a des contextes, comme ça, qui sont plus difficiles à traiter, ça prend du temps pour réussir à réintroduire de la communication, mais, souvent, on va juste avoir des gens qui sont sur des sites différents, parce qu’on a aussi séparé les différents métiers dans des localisations différentes, dans des équipes différentes, parfois dans des entités différentes de la même entreprise. Et là, toutes les questions qu’on se pose c’est comment faire pour que les gens puissent interagir beaucoup mieux, donc on va déléguer, déplacer des personnes, ça fait partie des recettes qui vont permettre de mieux fonctionner. On a aussi tous les outils collaboratifs, les salles virtuelles, qui vont permettre de rapprocher les gens.

Frédéric Couchet : Justement, une de mes questions. Je vois bien comment ça peut être mis en œuvre dans une équipe où les gens sont physiquement sur le même lieu, mais quels sont les outils nécessaires pour des gens qui sont à distance, c’est-à-dire sur différents sites, voire dans différents pays ? Et quels sont les types d’outils absolument nécessaires pour mettre en place cette approche DevOps, outils informatiques ou autres d’ailleurs ?

Xavier Talon : On va avoir les outils qui sont nécessaires à leur travail, donc tout ce qui va permettre de supporter ou d’automatiser tout un ensemble de tâches ; après il y a aussi des outils de communication. Les recettes qu’on voit dans le monde du Libre avec les outils qui vont permettent à des équipes de collaborer, même en ayant des gens très éparpillés dans des endroits différents, sont applicables, peuvent être utilisées pour ça, bien évidemment. D’ailleurs il y a une vraie inspiration qui peut venir des communautés du Libre.

Ensuite, il y a juste des évidences : rapprocher les gens aussi à travers la structure, déplacer des équipes de façon à ce que les gens soient plus proches, ça en fait aussi partie et c’est encore, bien évidemment, plus efficace pour le fonctionnement, c’est ce qu’on disait tout à l’heure. Mais la maturité, au niveau de la mise en œuvre de ces approches, prend du temps puisque ça peut passer par une réorganisation nécessaire, même dans la manière dont est structurée une organisation.

Frédéric Couchet : Des qualités ou des compétences sont-elles nécessaires dans les équipes qui existent, qui vont se mettre à cette approche DevOps ? Ou des choses qui, par exemple, pourraient remettre en question cette approche DevOps, des blocages, qu’ils soient organisés ou humains ? Là, je pense plutôt aux équipes actuelles, donc humaines.

Xavier Talon : Dans mon expérience récente, dans mes dernières missions, j’ai eu ce cas. On initie cette transition, on va déplacer des personnes, sauf que, dans les personnes que l’on déplace, il y a des profils plus jeunes, qui sont très contents de bouger, et des profils plus âgés, qui ne sont vraiment pas contents du tout de bouger. C’est une grande difficulté de la transition DevOps : dans le nom, c’est une transition et la transition ne fait pas plaisir à tout le monde.<br/
Parfois dans certains groupes où on a trop insisté dessus, il y a même une sorte de dégoût du mot DevOps, un rejet même, oui, c’est déjà arrivé qu’on nous rejette. Et là il faut quasiment inventer une nouvelle façon d’en discuter, une nouvelle façon d’en parler pour ne pas brusquer des personnes. Le côté humain est extrêmement important. Il faut savoir que quand on parle d’équipe, on parle des humains qui composent les équipes. C’est vraiment quelque chose de primordial, je pense, quand on fait un peu de l’évangélisme, on va dire, sur le DevOps, vraiment cette qualité humaine de comment parler aux gens, comment s’adapter à eux, parce que tout le monde n’est pas ouvert au changement de la même manière. Si vous êtes à deux ans de votre retraite vous n’avez pas envie de changer de métier, ça peut se comprendre. C’est, je pense, une qualité primordiale avant de s’attaquer au sujet.

Frédéric Couchet : En fait DevOps, c’est de la conduite du changement.

Xavier Talon : Complètement ! La mise en œuvre de DevOps c’est de la conduite du changement et c’est l’une des plus complexes qu’on ait eues à mettre en œuvre depuis, on va dire, les 40 dernières années. Par rapport aux révolutions technologiques qu’on a pu avoir avant, c’est sans doute la transformation la plus complexe à opérer.

Frédéric Couchet : Si je comprends bien ce que dit Romain, ça marche mieux, même si l’entreprise est importante ou la structure est importante, si elle est composée plutôt d’équipes de jeunes qui sont en début de carrière ou mi-carrière et qui sont dans le plaisir d’évoluer, parce qu’un des grands plaisirs, dans l’informatique, c’est aussi de faire des choses nouvelles régulièrement, donc ça marche bien dans ce contexte-là. Peut-être que le contexte où ça va être plus compliqué, ce sont les fameux grands comptes, voire les grands comptes administrations où vous avez encore des vieux systèmes. Ce matin nous écoutions une conférence sur les algorithmes, quelqu’un parlait des logiciels utilisés par la CNAM dans des langages comme Cobol et autres, là le vrai défi, dans ce genre de structure, va être d’arriver à convaincre ces équipes-là de faire effectivement une conduite du changement qui va remettre en cause leurs pratiques actuelles, à un moment où, peut-être, ces gens-là n’ont pas envie de bouger, tout simplement. Je ne parle même pas physiquement, mais bouger dans leur fonctionnement.

Xavier Talon : Je ne dirais pas forcément tout à fait ça. Pour l’anecdote, j’ai travaillé pour un de nos clients, un grand compte où 97 % de son cœur d’information est en Cobol sur du mainframe. Les équipes du mainframe sont venues nous trouver en disant « nous avons envie de conduire notre transformation et d’essayer de voir comment on peut faire de l’agilité avec notre mainframe.
Mainframe ce sont de gros ordinateurs centralisés qui étaient aussi des systèmes extrêmement robustes. Le code de votre banque, pour la plupart des banques françaises, est un code qui a été écrit il y a peut-être 40 ans et qui va encore continuer parce qu’on est bien incapable de refaire rapidement, en tout cas de sortir ces éléments justement de ces systèmes centraux. En fait on a des équipes comme ça. On a fait un programme très intéressant, « DevOps pour le mainframe », où on a réussi à faire des choses très intéressantes, à virtualiser des machines de type mainframe, de façon à pouvoir accélérer les développements et ça a très bien fonctionné.

Le problème qu’il y a c’est plus une culture d’entreprise et aussi une culture personnelle. Il faut voir qu’on va demander aux gens plutôt de transformer leur manière de travailler, même de transformer leur métier, d’intégrer d’autres activités, d’autres choses, mais aussi d’avoir une autre vue. Typiquement, par exemple quand nous avons mis en place notre société, quand on avait un ingénieur système qui allait travailler chez un client, il n’avait pas forcément une vision de pourquoi il opérait ; il travaillait sur des systèmes techniques, après, ce qui tournait sur ces systèmes ce n’était pas son rôle. Il était, lui, sur la couche infrastructure, il travaillait pour optimiser les systèmes ; quel que soit, finalement, ce qui allait tourner dessus, c’était quelque chose qui lui échappait totalement.

Aujourd’hui on va redonner de la visibilité, on va remettre un petit peu l’humain au centre et les gens vont plus travailler sur une fonctionnalité globale. Même s’ils ont un travail plus Ops que développeurs, en fait ils vont vraiment communiquer avec les clients, avec les développeurs, avec les gens de la sécurité. Ils vont avoir un petit peu une vision complète, fonctionnelle : je fais quoi ? Pourquoi ? Qu’est-ce que je dois réussir à mener ? Quel est finalement l’objectif qu’on va viser sur le produit dans sa globalité ?

Quand on fait ça, c’est aussi une responsabilité. C’est-à-dire que ces équipes dont on a parlé, les équipes DevOps qui vont créer un service, une fonctionnalité, une application, vont en être responsables et en être responsables non pas juste sur la partie technique qu’elles réalisent, mais elles vont avoir une responsabilité globale de tout ce qui va se passer, même dans le run, dans le fonctionnement de l’application quand elle va être mise à disposition des utilisateurs.
Et là, ça pose un petit souci. D’abord, tout le monde n’a pas forcément cette appétence de vouloir bien comprendre les choses et les objectifs et puis, en plus, il y a une responsabilité : si quelque chose se passe mal, j’en suis responsable pour ma partie et je dois l’assumer avec les autres. Par rapport à un modèle où les gens travaillaient dans leur cadre et s’il y avait quelque chose, hop !, ce n’est pas chez moi, ça vient pour toi, c’est une mise en responsabilité des équipes qui n’est pas forcément facile à accepter et c’est vraiment un changement culturel. C’est ce changement culturel – les équipes ont plus d’autonomie, le travail peut devenir beaucoup plus intéressant – qu’il faut réussir à accepter, avec la responsabilité que cela implique.
Une des difficultés qu’on voit souvent c’est qu’on a des équipes pour qui cette prise de responsabilité, ce changement d’orientation peut être difficile à accepter. Et ce ne sont pas seulement les personnes, c’est aussi l’organisation qui est derrière, en termes d’objectifs, en termes d’organisation, etc.

Frédéric Couchet : D’accord. On voit bien que les thèmes qui reviennent souvent c’est approche, philosophie, culture DevOps. Ça n’est pas forcément un métier, mais je me pose une question : est-ce qu’il existe une fiche métier DevOps ? Et, corollaire, est-ce qu’il existe des formations DevOps ? En fait, j’ai trouvé des fiches métier sur des sites, mais est-ce ces fiches métiers correspondent à une réelle réalité ? Est-ce qu’il y a des formations ? Quelqu’un qui se dit « l’approche DevOps m’intéresse, est-ce qu’il existe des formations ? » Ou est-ce que, finalement, la formation c’est un peu sur le tas, quand on travaille sur des projets ? Romain.

Romain Soufflet : Quand on parle DevOps chez les clients, on a vraiment besoin de communiquer un peu plus loin pour savoir ce qu’ils entendent par ce terme-là. Ce sont souvent des postes techniques qui sont décrits avec le mot DevOps. Donc oui, on peut imaginer faire des formations par exemple pour les fameux pipelines d’intégration continue qui sont, on va dire, comme des usines logicielles.

Frédéric Couchet : Explique ce qu’est un pipeline d’intégration continue ou explique ce qu’est l’intégration continue, s’il te plaît.

Romain Soufflet : Quand les développeurs vont travailler ils vont envoyer leurs changements et on va faire passer à ces changements toute une batterie de tests, on va leur faire passer différents scripts pour les construire, pour vérifier qu’ils fonctionnent bien, pour les intégrer avec le reste du travail de l’équipe. Tout ça c’est comme une usine d’assemblage, un petit tapis roulant de plein de mécanismes qui vont se mettre les uns derrière les autres pour, au final, arriver à une application packagée, finie. Quand elles parlent de DevOps, pas mal d’entreprises veulent un ingénieur capable d’écrire ce pipeline. Certaines entreprises demandent un DevOps, mais au final, derrière, c’est plutôt de l’administration système, donc du maintien en conditions opérationnelles, s’occuper des serveurs. C’est quand même très diverse.
Si je disais, aujourd’hui, que je veux faire une formation DevOps, j’ai besoin d’écrire un paragraphe, derrière, pour expliquer ce dont je parle. La grande difficulté qu’on a quand on parle de transition DevOps, de culture DevOps, c’est que le terme est tellement flou qu’on a vraiment besoin de faire un paragraphe derrière et de bien expliquer ce qu’on entend par ce mot et ce qu’il y a dans notre formation.

C’est aussi pour ça que, quand je me présente, je parle d’ingénieur de fiabilité de site, parce que là, du coup, la fiche de poste est plus précise, il y a moins d’ambiguïté, c’est-à-dire que d’autres personnes qui connaissent l’ingénieur de fiabilité de site savent ce dont je parle et savent quel est, on va dire, le périmètre de mon travail. C’est plus facile de parler sur ce poste-là plutôt que de faire toute une présentation DevOps à chaque client, parce que je passe beaucoup de temps à en parler et ça devient vite long.

Frédéric Couchet : D’accord. Sur cette question, Xavier, tu voulais rajouter quelque chose ?

Xavier Talon : Oui. Si vous voyez une fiche de poste DevOps, méfiance ! C’est ce qu’on disait tout à l’heure, il y a beaucoup trop de choses derrière ce concept pour que ce soit un métier, ça n’existe pas. On peut avoir des gens qui vont être un peu des tech leads, qui vont avoir une vision assez globale de l’ensemble des outils, des processus, qui vont pouvoir former les autres, mais ce ne sont pas des gens qui vont pouvoir assumer toutes les tâches qu’il y a à faire.

Par contre, c’est un domaine et, comme pour toute nouveauté, il faut quelques années pour que tout ça se formalise, que ça se stabilise, qu’on voit émerger les différentes définitions et métiers qui vont avec et on commence à le voir. Il y a quelques années on ne parlait pas des SRE, c’est un métier qui est apparu par nécessité. On s’est rendu compte qu’il fallait des gens pour assurer cet aspect fiabilité, donc le poste s’est créé et lui, pour le coup, est très clair. Donc on commence à voir des aspects comme les product owners il y a quelques années, comme les SRE aujourd’hui, etc. On commence à voir les choses se stabiliser, ces définitions qui commencent à se poser, ces fiches métiers qui deviennent de plus en plus claires. Avec le temps, on va arriver à ce que ça devienne une normalité et où on aura commencé à poser les choses.

Frédéric Couchet : D’accord. Question rapide puisque vous l’avez abordée indirectement dans vos réponses sur les outils et la partie de logiciel libre.
Pour mettre en œuvre cette approche, en fait cette partie technologique, il y a plein d’outils en logiciel libre qui existent, que ce soit l’outil pour la gestion des codes sources, pour ce que tu décrivais à l’instant sur l’intégration continue, pour les tests, pour le monitoring c’est-à-dire le suivi de l’application en conditions opérationnelles, tout ça est faisable, d’un point de vue technique, avec des logiciels libres.

Romain Soufflet : D’un point de vue technique, oui. C’est le poste où on est le plus amené à utiliser des logiciels libres. J’ai tendance à penser qu’on n’utilise que ça, en fait. Le métier est assez nouveau, ça fait moins de dix ans qu’on parle de ces cultures DevOps et de ces problématiques-là. Au final tous les outils qui ont été développés, qui sont utilisés aujourd’hui, sont quasiment tous open source. Avec certains copains on va même parfois plus loin et on se dit que si notre problème n’est pas résolu par un logiciel déjà existant, open source, disponible sur Internet, c’est qu’on s’est trompé de problème !

C’est vrai que c’est un gros avantage. On n’écrit pas énormément de code lorsque l’on fait du SRE avec cette culture DevOps. On va souvent réutiliser des choses que d’autres ont faites, les adapter, contribuer aussi. C’est assez rare qu’on déploie un projet de A à Z dans son quotidien. En fait, on va souvent réutiliser ce que d’autres ont fait, des choses qui sont mises à disposition par d’autres SRE à travers le monde. C’est une communauté, au final, qui collabore énormément, même inter-entreprises, et c’est quelque chose qui fait très plaisir à voir. C’est un nouveau métier qui s’est quand même construit beaucoup autour de cette culture du logiciel libre.

Frédéric Couchet : D’accord, super, en plus tu me fais la transition avec le dernier sujet. Le temps passe super vite, je vous avais prévenus. Tu viens d’employer le terme « communauté ». Xavier, tu voulais aborder un sujet justement sur cette construction de communauté à travers, notamment, l’association DitRit.

Xavier Talon : Tout à fait. Je pense que DitRit est une aventure qui a commencé justement par la manière dont on a abordé avec nos clients, au niveau d’Orness, la problématique DevOps et l’agilité en général. On s’est rendu compte, de client en client, qu’on rencontrait finalement tout le temps un peu les mêmes problématiques. On a vu que la mise en œuvre de DevOps c’est compliqué, surtout quand il y a un gros existant, etc. Finalement, on se retrouvait toujours un petit peu avec la même manière de travailler, où les gens qui veulent mettre en place l’approche se disent « aujourd’hui, on a des outils ». Il y a beaucoup d’outils ; les outils open source sont effectivement un peu la base aujourd’hui. Ce serait difficile d’avoir les reins assez solides pour une société qui voudrait faire du code propriétaire pour traiter ce type de problématique et ce serait difficile d’apporter, justement, l’agilité nécessaire, la capacité d’adapter.
Et puis on est sur des outils techniques pour des gens techniques qui vont forcément avoir besoin de les adapter ; l’outil qui fera tout, c’est difficile. La communauté open source est, aujourd’hui, un peu la seule qui sera capable d’apporter ces évolutions, de créer une communauté suffisamment importante pour que tout le monde puisse s’en emparer, adapter et, finalement exploiter un outil qui aura vraiment une valeur sur la longueur.

Quand on a fait ça, on s’est rendu compte qu’à l’opposé on a beaucoup de gens qui voient le DevOps comme la mise en œuvre de certains types d’outils et qui partent uniquement sur une démarche de mise en œuvre technique, en oubliant un petit peu d’autres aspects et toutes ces problématiques, notamment de monter à l’échelle.

Ce qu’on observait souvent, c’est « on va traiter une application », on prend une application-type, le cas d’école. Tout ce qui gêne, tout ce qui est un petit peu compliqué, la sécurité, la résilience, tous ces aspects-là on les traitera dans un second temps. Et puis on fait une preuve de concept et on s’aperçoit que, avec une petite équipe resserrée, on arrive à traiter de manière très parfaite et on arrive à mettre en place ce démonstrateur de l’intérêt de l’approche, etc.

Après on veut généraliser, donc on commence à regarder, à faire ça sur une vraie application-pilote, en vraie réalité. Là, c’est un petit peu plus douloureux et on commence à voir vraiment toute la complexité, tout ce que ça veut dire parce que, bêtement, il faut par exemple s’intégrer avec tout le reste du système d’information, il faut traiter de la sécurité. On s’éponge bien, on remet encore un petit peu d’huile dans les rouages, on met les moyens, on remet des personnes et on s’en tire.

Après on va vraiment généraliser et là, généralement, ça s’écroule et ça devient vraiment très difficile. Il faut des années pour passer ce mur qui a été rencontré.

On retrouve ce type de problématique un peu partout, à peu près systématiquement chez tous nos clients qui se sont lancés dans des démarches. Ce qu’on a pu voir aussi avec eux, c’est qu’on arrivait à identifier des manières de traiter ça, en se disant « finalement, avec des approches comme celle qui consiste à essayer non pas directement d’implémenter des configurations techniques, mais à essayer de modéliser, d’avoir des outils qui vont nous permettre d’identifier les architectures qu’on va avoir, on va pouvoir aller beaucoup plus loin dans le niveau d’automatisation et on va surtout pouvoir beaucoup mieux réutiliser du code technique qui a été réalisé par des experts ». C’est l’une des choses qui sont très complexes. Typiquement c’est assez difficile de réutiliser d’une application sur une autre un code d’infrastructure tel que peuvent le concevoir des gens comme Romain ou les gens avec lesquels il travaille. Donc on a trouvé des moyens de commencer à identifier des choses, on a commencé à avoir, à différents endroits, des idées qui semblaient intéressantes.

Après on s’est dit que finalement, en clientèle, on ne peut pas toujours aller jusqu’au bout du geste et on s’est dit « on va faire un laboratoire interne Orness pour essayer de continuer à développer ces choses »

Là, on s’est retrouvés à faire de la R&D, comme le font toutes les sociétés en interne, et on s’est retrouvés à faire de l’entre-soi. Et finalement, nous, avec notre petite taille – nous ne sommes pas gros pour une société de services – nous n’avions pas les reins assez solides pour pouvoir créer du logiciel et, typiquement, mettre en œuvre les applications et les concepts que nous étions en train de développer. Et là on s’est dit « finalement on y perd », même par rapport à des chantiers, avant, où on était chez nos clients avec des gens qui venaient d’autres sociétés qui apportaient aussi leur savoir-faire. D’où l’idée, à un moment, de se dire « et si on externalisait notre recherche et développement, si on jouait l’intelligence collective ? ».
Et là, toute l’idée a été ce constat : on est beaucoup plus fort à plusieurs. Si on veut le faire nous-mêmes, si on veut créer ce type de solutions nous-mêmes, on n’aura, de toute façon, pas les moyens de le faire ou, en tout cas, on n’a pas la taille pour pouvoir faire ça, finalement, si on créait une communauté basée sur les idées libristes ? On a donc créé une association loi 1901 qui s’appelle DitRit, qui a pour vocation de travailler sur tout ce qui est transformation numérique, que ce soit pour les grands comptes, mais aussi les petites sociétés, pour n’importe quelle organisation, avec l’idée de se dire qu’il y a sûrement moyen de rendre disponible pour tout un chacun ce qu’on arrive à faire avec d’autres, pour ces grands comptes. Si on est vraiment sur une organisation transverse qui n’a strictement aucun intérêt pécuniaire, on va dire, qu’on arrive à attirer et à créer une vraie communauté d’entreprises, d’étudiants, d’universités, de personnes qui ont simplement envie de donner leur temps et qui veulent faire avancer des causes comme ça, eh bien on pourra faire quelque chose d’intéressant.

C’est ce qu’on a fait, donc DitRit s’est construite. Dans DitRit on va avoir un étage réflexion, un think tank, tools tank. On a donc un étage réflexion, des groupes de travail : on en a, par exemple, un sur la souveraineté numérique, on a un groupe de travail sur l’éthique et les communs. On est vraiment dans l’esprit et rentre évidemment, là-dedans, tout ce qu’on peut identifier sur le Libre. Et puis on a une incubation de projets open source. C’est dans les statuts de la société que ces projets open source ne pourront jamais donner lieu à des fonctionnalités ou à quelque utilisation commerciale que ce soit. Cet incubateur a pour vocation de mettre en pratique des idées, des principes, et de créer des solutions auxquelles on croit, avec lesquelles on a vu, par expérience, qu’on pouvait faire des choses intéressantes, et rassembler une communauté autour de ça pour avancer.

On a donc des collaborations, au sein de DitRit, avec des sociétés. On a des écoles qui viennent, des universitaires qui participent aux travaux, des contributeurs qui viennent de tout horizon. C’est intéressant puisqu’on a tout à y gagner. C’est la seule manière d’illustrer un peu nos idées, de mettre en œuvre notre recherche et développement et on la met à disposition de la communauté au sens large. On n’est pas les seuls. On commence à être rejoints par différentes sociétés qui jouent le jeu, qui viennent, et c’est extrêmement enrichissant. Pour nous c’est une vraie aventure, passionnante, et on a de plus en plus de choses qui se mettent dedans.

La bonne nouvelle, c’est qu’on a été reconnus d’intérêt général l’année dernière et c’est un vrai coup d’accélérateur. Bercy nous a reconnus ce statut et ça va nous permettre d’accélérer encore. On commence à avoir des vraies contributions avec différentes sociétés. On voit là toute la puissance que peut avoir cet aspect communautaire et libre. Ça nous fait un levier qui nous permet vraiment d’accélérer ces développements-là et c’est extrêmement intéressant.

Frédéric Couchet : Excusez-moi pour la sonnerie. On arrive à la fin du sujet.
C’est très intéressant. Je renvoie sur le site web de DitRit, ditrit.io, on mettra les références sur le site web. Ça me fait penser qu’on va parler de ce sujet de collaboration entre entreprises du Libre, industriels, grands comptes, sur des problématiques communes, bientôt dans des émissions, notamment peut-être autour de PostgreSQL.
On arrive en fin de sujet, parce qu’on a un sujet court juste après.
Je vais poser la dernière question, traditionnelle, de Libre à vous !, celle du sujet principal. On va commencer par Romain Soufflet : en moins de deux minutes, quels seraient les points essentiels que tu souhaiterais rappeler ou que tu souhaiterais que les gens qui nous écoutent aient en tête ?

Romain Soufflet : En deux minutes, c’est un peu compliqué !

Frédéric Couchet : J’avais envoyé la question avant !

Romain Soufflet : Si déjà, à la fin de l’émission, on arrive à faire passer l’idée de la culture DevOps, de ce que ça veut dire, de cet antagonisme entre les développeurs et les personnes qui font l’opérationnel, donc le maintien en conditions optimales pour l’utilisateur ; le fait de pouvoir les faire travailler ensemble sur les problématiques des utilisateurs, de faire communauté au sens de tous les différents métiers des systèmes d’information aujourd’hui, de travailler ensemble, de mieux communiquer et de partager un but commun, qui est donc les utilisateurs, leur bien-être, les fonctionnalités qu’on va leur offrir, ça serait déjà beau qu’on arrive à faire passer tous ces messages et que nos auditeurs puissent comprendre cette notion et que ça serve déjà à un peu démystifier ce mot très obscur qu’est DevOps.

Frédéric Couchet : Très bien ! Xavier Talon, même question.

Xavier Talon : Ce qu’il faut retenir. Je dirais que DevOps est une approche qui permet vraiment d’apporter beaucoup de valeur et qui, surtout aussi, permet de recentrer l’humain dans le tableau. C’est une vraie transformation importante qui touche vraiment tous les aspects.

Par contre, je pense qu’il faut aussi retenir que DevOps n’est pas juste un outil ou l’utilisation d’outils. Il n’y a pas de magie, on est sur des problématiques complexes. Il y a des outils, effectivement, qui apportent énormément de choses, mais il faut prendre un petit peu de recul par rapport à ça. Et surtout, ce n’est pas parce qu’on fait du DevOps qu’il ne faut pas avoir une vision globale et bien étudier les choses. Comme le disait Romain, il faut, dès le départ, intégrer la sécurité, avoir une vraie démarche d’architecture, etc. Le vrai risque – et je pense que c’est quelque chose à retenir pour les gens qui veulent se lancer là-dessus – c’est de se lancer à corps perdu sans savoir exactement où on va. Quand on fait des petits pas sans savoir vers où on va, c’est le meilleur moyen de se prendre le mur !

Un des enseignements du DevOps c’est aussi que ça peut apporter énormément de qualité, par contre, ça peut aussi devenir extrêmement coûteux et, finalement, presque contre-productif si on n’est pas bien préparé. Ce qu’on a aussi essayé de vous montrer ce sont toutes les réalités, toutes les facettes de ce monde DevOps. Je pense que c’est important de bien comprendre et de bien étudier les choses avant de se lancer pour éviter les problèmes et vraiment en tirer la valeur.

Frédéric Couchet : Merci à tous les deux. Je crois que vous avez vraiment répondu au défi de faire comprendre ce qu’est DevOps au public de Libre à vous !.
Nos invités : Xavier Talon, cofondateur et directeur technique de la société Orness et président de DitRit, association loi 1901 d’intérêt général qui traite de la transformation numérique, et Romain Soufflet, SRE indépendant, SRE c’est ingénieur de fiabilité de site.
Je vous remercie. Belle journée à vous. On va faire une pause musicale.

[Virgule musicale]

Frédéric Couchet : Après la pause musicale, nous entendrons la chronique de Véronique Bonnet sur le monde du Libre. En attendant, nous allons écouter Dag-ztepFroggy par Dag-z. Je vous préviens, ça va bouger. On se retrouve dans moins de quatre minutes. Belle journée à l’écoute de Cause Commune, la voix des possibles.

Pause musicale : Dag-ztepFroggy par Dag-z.

Voix off : Cause Commune, 93.1.

Isabella Vanni : Nous venons d’écouter Dag-ztepFroggy par Dag-z – j’adore ce morceau, j’adore globalement ce que fait par Dag-z – disponible sous licence Art Libre.

[Jingle]

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

[Virgule musicale]

Chronique « Partager est bon » de Véronique Bonnet, professeur de philosophie et présidente de l’April sur le thème « Le monde du Libre »

Frédéric Couchet : Une lecture philosophique du logiciel libre, c’est la chronique « Partager est bon » de Véronique Bonnet, professeur de philosophie et présidente de l’April. Le thème du jour : « Le monde du Libre ». La chronique a été enregistrée il y a quelques semaines. On se retrouve juste après.

[Virgule sonore]

Véronique Bonnet : J’ai intitulé le podcast d’aujourd’hui « Le monde du logiciel libre ». La notion de monde me semble effectivement une entrée philosophique intéressante pour aborder les enjeux du logiciel libre.

« Monde » peut avoir plusieurs sens. Je commence par le sens le plus restreint. On dit parfois de quelqu’un qu’il est dans son monde, il est dans sa bulle, c’est-à-dire dans une sphère qui lui est propre. Si on élargit encore, on peut parler par exemple du monde des libristes, c’est-à-dire ceux qui partagent entre eux un idéal commun. Il se trouve que cet idéal commun concerne le monde au sens le plus large, le monde, ce qui englobe toutes les expériences possibles, non pas une somme, mais une totalité. Le monde c’est l’ensemble qui synthétise et fait le lien de tout ce que les humains peuvent connaître, expérimenter, ressentir.

Bien sûr, notre rapport au monde est subjectif. Bien sûr, nous nous construisons comme des individus singuliers. Mais la promotion du logiciel libre favorise une sortie de nos aspirations auto-centrées.

Je vais me référer à un philosophe du 20e siècle, Maurice Merleau-Ponty. C’est un phénoménologue. Ce terme veut dire tout simplement qu’il se penche sur les phénomènes, c’est-à-dire ce qui apparaît, il s’est notamment beaucoup penché sur le monde.
Merleau-Ponty refuse deux extrêmes. Il refuse de dire du monde qu’il est simple. Ça reviendrait à poser que le monde a une seule entrée et ça serait une vision monolithique. Il refuse aussi de dire que chacun est seulement dans son monde. Il refuse de parler d’une infinité de mondes qui seraient étanches. Je cite Maurice Merleau-Ponty : « Nous nous plaçons en nous et dans les choses, en nous et en autrui, au point que nous devenons les autres et nous devenons le monde. La philosophie se refuse les facilités d’un monde à une seule entrée aussi bien que les facilités d’un monde à multiples entrées. Elle se tient au point où se fait le passage du soi dans le monde et dans l’autre, à la croisée des avenues. »

Je trouve qu’on pourrait tout à fait dire que le logiciel libre, lui aussi, se tient à l’écart de ces deux illusions : l’illusion qu’il y aurait un seul monde monolithique, homogène, ce qui serait un monde tyrannique ; deuxième illusion : qu’il y aurait simplement une pluralité de mondes étanches.

Je commence par la première, donc l’illusion qui voudrait qu’il y ait un seul monde qui ne tiendrait aucun compte des contextes particuliers de chacun.
Il se trouve que la philosophie GNU, qui est la philosophie du logiciel libre, insiste beaucoup sur l’importance de pouvoir adapter les logiciels, adapter les logiciels à la singularité, aux besoins spécifiques, aux aspirations de la diversité des êtres. Une analogie revient souvent entre un code source et une recette de cuisine : si la recette de cuisine était sous copyright, comme certains programmes sont sous brevet logiciel, alors on ne pourrait pas enlever en elles le sel, le sucre ou tel ingrédient auquel nous serions allergiques. On serait contraint d’exécuter les recettes de cuisine à l’identique, sans jamais pouvoir les modifier.

Il se trouve que dans les idéaux du logiciel libre se trouvent les libertés d’exécuter, étudier, améliorer, distribuer des copies modifiées ou non d’un programme. Ceci respecte la diversité des personnes, ne leur impose pas un rapport au monde impératif.

Il me semble que le logiciel libre se tient aussi à l’écart de cette seconde illusion qui parlerait simplement de mondes singuliers et étanches. En effet, cette collaboration des libristes entre eux, qu’on appelle non seulement le pot commun du code mais le pot commun des bonnes pratiques, le pot commun de nos initiatives éthiques, fait qu’en cela le logiciel libre évite que chacun reste dans son monde ou encore affronte seul les dangers des pratiques informatiques. Il faut absolument qu’il y ait de l’aide, qu’il y ait une communauté pour veiller sur le code source. En ce sens, chacun où il est est en lien avec l’autre, dans notre communauté et, à ceux qui sont en dehors de cette communauté, nous nous devons de parler de la différence entre logiciel libre et logiciel propriétaire, irrespectueux.

Il y a une image très belle chez le philosophe dont j’ai parlé au début, Maurice Merleau-Ponty. Il invente une expression, il parle de la chair du monde, la chair du monde qu’il est important d’expérimenter, de goûter.
C’est vrai que l’informatique propriétaire n’en a rien à faire de ce sens de l’autre, du partage délectable de ce qui fait que nous relevons d’une humanité jamais contre les autres, malgré les autres, mais avec les autres. Je dirais que l’informatique propriétaire propose une prétendue convivialité, affiche un monde lisse qui cache un monde souterrain fait de portes dérobées, d’opérations que l’utilisateur ne maîtrise pas. Le logiciel libre, lui, est de plain-pied avec le monde.
Étienne, ce monde te va-t-il ?

Étienne Gonnu : Je pense qu’il y a une grande marge de progression pour le monde tel qu’il est actuellement. Ce que tu viens de dire résonne beaucoup en moi et j’aime beaucoup. Je pense qu’on existe particulièrement à travers les liens qui nous unissent, qu’on explore, et ce monde qu’on partage, comme tu le dis très justement

Véronique Bonnet : Je pense aussi à l’image de cette sensibilité. Il me semble qu’on dit souvent des libristes que ce sont des êtres qui ont simplement pour intérêt des démarches techniques, des démarches techniques pratiques. Or, je pense que le partage du sensible tout autant que de l’intelligible est ce qui nous donne envie, à l’April, de continuer.

Étienne Gonnu : C’est sûr. Je pense que le nombre de personnes qui se considèrent libristes, sans pour autant être des techniciens ou des techniciennes, témoigne aussi qu’il ne s’agit pas que d’une question technique, mais est plus une question politique et aussi une question sociale de ce qui nous unis. Comme tu le dis très justement, je pense qu’on défend avant tout la libre diffusion des connaissances et également leur partage.

Un grand merci, Véronique, pour cette nouvelle chronique toujours aussi intéressante. Je te dis au mois prochain pour une nouvelle chronique elle aussi enregistrée. Bonne journée Véronique.

Véronique Bonnet : Très bonne journée à toi Étienne.

[Virgule sonore]

Frédéric Couchet : Nous venons d’écouter la chronique de Véronique Bonnet, professeur de philosophie et présidente de l’April. Le thème de sa chronique était « Le monde du Libre ». Prochaine chronique sans doute le mois prochain.

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 : Notre émission Libre à vous ! est diffusée sur la radio associative Cause Commune, la voix des possibles. La radio propose un nouveau rendez-vous convivial chaque premier vendredi du mois, à partir de 19 heures, dans ses locaux à Paris : une réunion d’équipe ouverte au public avec apéro participatif à la clef. Occasion de découvrir le studio, de rencontrer les personnes qui animent des émissions, voire de proposer votre propre projet. La première soirée-rencontre aura lieu vendredi 7 octobre 2022 à partir de 19 heures. J’y serai. Adresse du studio : 22, rue Bernard Dimey, 75018 Paris et ensuite ça sera un rendez-vous chaque premier vendredi du mois à partir de 19 heures.

Comment échapper à la surveillance des GAFAM, ces géants du Net qui se goinfrent de nos données personnelles ? L’association École du Logiciel Libre organise un évènement mercredi 5 octobre 2022 à partir de 19 heures à Ivry-sur-Seine.

La même École du Logiciel Libre organise ce samedi 8 octobre 2022, à partir de 14 heures 30, un cours. C’est un cours de l’École du Logiciel Libre pour découvrir le logiciel libre.

Du côté de Lyon, jeudi 6 octobre 2022, il y a un jeudi Vie privée de 19 heures à 21 heures 30.

Vous retrouverez évidemment les informations précises sur ces évènements sur le site de l’Agenda du Libre que je vous invite à consulter, agendadulibre.org, pour trouver des évènements en lien avec le logiciel libre ou la culture libre près de chez vous. Vous pouvez aussi trouver des organisations libristes près de chez vous.

Notre émission se termine.

Je remercie les personnes qui ont participé à l’émission du jour : Vincent Calame, Xavier Talon, Romain Soufflet, Véronique Bonnet.
L’émission a été mise en ondes par le toujours sobre Étienne Gonnu.
Merci également aux personnes qui s’occupent de la post-production des podcasts : Samuel Aubert, Élodie Déniel-Girodon, Lang1, Quentin Gibeaux, bénévoles à l’April, et Olivier Grieco, le directeur d’antenne de la radio.

Vous retrouverez 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 pour indiquer ce qui vous a plu, mais aussi des points d’amélioration. Vous pouvez également nous poser toute question et nous 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 nous laisser un message sur le répondeur de la radio soit pour réagir à l’un des sujets de l’émission, soit pour partager un témoignage, des idées, des suggestions, des encouragements ou tout simplement 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 et à faire connaître également la radio Cause Commune, la voix des possibles.

La prochaine émission aura lieu en direct mardi 11 octobre 2022 à 15 heures 30. Notre sujet principal portera sur les jeux vidéo libres.

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

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