Émission Libre à vous ! du 4 octobre 2022

Titre : Émission Libre à vous ! du 4 octobre 2022

Intervenants : Vincent Calame - Xavier Talon - Romain Soufflet - Véronique Bonnet - Étienne Gonnu - Frédéric Couchet- Étienne Gonnu à la régie

Lieu : Radio Cause Commune

Date : 4 octobre 2022

Durée : 1 h 30 min

Podcast PROVISOIRE

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

Licence de la transcription : Verbatim

Illustration : Déjà prévue

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

Transcription

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 qui est 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 70 sur le réemploi informatique, la 36 sur l’obsolescence programmée, la 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 ici 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 surtout 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 i ;l n’est pas simple, sans accompagnement, d’installer ce qu’on veut. Or, les téléphones sont aussi des 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 ???, je trouve, « les fabricants vont avoir entre guillemets « une obligation d’information sur la durée pendant laquelle les mises logicielles permettent un usage restant normal des appareils ». Soyons sérieux, au vu les enjeux ce n’est pas une obligation d’information qu’il faut mais bien une interdiction de ces pratiques, tout est 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 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 source de bonnes 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 Jean Bleu. On se retrouve dans moins de deux minutes. Belle journée à l'écoute de Cause Commune, la voix des possibles.

Pause musicale : 4x4 par Jean Bleu.

Voix off : Cause Commune, 93.1

Frédéric Couchet : Nous venons d’écouter 4x4 par Jean Bleu, 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.

DevOps (abolir les barrières entre les équipes de développement et les équipes d’administration système) avec Xavier Talon (co-fondateur 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 = Eve 11:29

Frédéric Couchet : Nous allons passer au sujet suivant. 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 : Xavier Talon, co-fondateur 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, c'est-à-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. Donc, bonjour Xavier, bonjour Romain. N'hésitez pas à participer à notre conversation : 09 72 51 55 46, ou sur le salon dédié à l'émission sur le site causecommune.fm, bouton de chat « salon libre à vous ».

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 : Oui, d'accord. Je suis ingénieur développeur à la base, donc sur du python, puis j'ai progressivement passé sur les questions plutôt DevOps. C'est opérationnel, donc, c'est là que je suis arrivé à être indépendant SRE. Donc, 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 : Évidemment. Xavier Talon ?

Xavier Talon  : J'ai participé à la création de la société ORNESS, ça fait déjà 22 ans et, au départ on était 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évolution, petit à petit, avec l'arrivée de nouvelles technologies, notamment le cloud, toutes sortes de choses. Et puis le DevOps. Et avec ça, on a rencontré des nouvelles problématiques et un nouveau champ d'action qui nous a permis de voir qu'il y avait vraiment des améliorations à faire et des grosses difficultés qui étaient à abolir et avec 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.

Et, on va en reparler, ça a été aussi l'occasion de créer l'association DitRit qui travaille sur ces problématiques. C'est une association loi 1901 qui essaye de traiter ces problématiques, notamment par l'incubation de logiciels libres.

Frédéric Couchet : Alors 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. Je précise que d'ailleurs, c'est Xavier Talon- et 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 a été « DevOps sur une émission grand public ? C'est un défi ». En même temps, on aime bien les défis, à l'April : on s'est dit, on va inviter les gens qui vont savoir en parler. Donc, si je parle aux gens de DevOps, les deux termes qu'ils entendent, c'est Dev et Ops. Dev, on voit bien que ça fait référence au développement ; Ops, opérationnel. Peut-être qu'on va commencer par préciser ces deux termes. Le premier est Peut-être mieux connu, mais en tout cas le rappeler, et le deuxième terme, avant d'entrer dans les détails. Romain Soufflet ?

Romain Soufflet : Très bien, on va commencer par là. Donc, effectivement, développeurs, on arrive très bien à comprendre ce que c'est. C'est devenu plus facile à comprendre pour un peu tout le monde maintenant, puisque on a des développeurs qui sont plus nombreux qu'il y a trente ans et encore plus nombreux qu'il y a cinquante 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 bug, de faire en sorte que les applications évoluent pour que les utilisateurs puissent avoir de nouvelles fonctionnalités.

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

Donc, par nature, le développeur est axé sur le changement, l'opérationnel sur « une fois que ça marche, on joue plus trop y toucher ». Donc, ils sont par nature amenés à ê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. Faut qu'on travaille ensemble, et c'est comme ça que je définirais donc ce terme, avec ces deux métiers principaux : développeurs et opérationnels.

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

Xavier Talon  : Oui, ça n'est pas si facile que ça, puisque il y a une chose qu'il faut savoir, 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, puisque pour faire tourner un logiciel, on a besoin de développeurs, on a besoin des gens qui vont faire les opérations, on a besoin des gens qui vont faire la sécurité, les gens qui vont gérer aussi les budgets. Et donc on a fait l'acronyme DevOps, mais en fait, on a aussi le Dev???, le Dev??? [17:02], etc. Et c'est vraiment ce principe d'essayer finalement de mettre de l'agilité, de fluidifier un petit peu les principes, de faire qu'on va être beaucoup plus efficient dans la construction des logiciels et surtout, de pouvoir aller beaucoup plus vite à un résultat donné. Alors, beaucoup plus vite, on va essayer de donner beaucoup plus de de capacité à voir l'évolution et à aller dans le bon sens, et de corriger les évolutions au fur et à mesure où elles vont venir. Donc, c'est tous ces objectifs qui visent vraiment à l'efficience, qui sont traitées 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, mais 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 c'est quoi l'agilité dans le domaine de l'i ngénierie informatique ? Est-ce que tu peux présenter ça rapidement ?

Xavier Talon  : L'agilité, ça 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 et qui permettra d'être beaucoup plus en accord avec le besoin. Typiquement, quand on faisait un logiciel à l'ancienne, il y a quelques années, on pouvait avoir, entre le moment où on écrit le code et le moment où il va être en production, il y a beaucoup d'activités à réaliser : la mise en place des serveurs, leur installation, toutes les différentes activités, comme la sécurité, etc., qui sont nécessaires pour que le logiciel puisse tourner.

Et 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. Dans ce temps-là, on a un tunnel. Ce qui va se passer, finalement, c'est qu'il va falloir 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. Et donc, on va essayer de se dire : fixons-nous non pas directement la cible qu'on peut atteindre, mais une première étape où on vous voir aller rapidement et voir un premier résultat, qui va permettre de corriger le tir et 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. Alors 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, et 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 leur livrer au bout de x mois quelque chose qui ne correspond pas aux besoins. Là, 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. Donc, si vous écoutez le début de l'émission, c'est libravous.org/59. Merci pour la précision sur l'agilité.

Maintenant, ma deuxième question, mais pour tous les deux : tu as parlé de d'approches DevOps, c'est d'ailleurs ce que j'ai utilisé dans le titre de l'émission. Mais on voit DevOps sur des CV, aujourd'hui, c'est très à la mode. Donc, DevOps, c'est un métier en tant que tel ? C'est un nouveau métier en tant que tel ? Ou est-ce que c'est une approche qui est mise en œuvre par des gens qui ont un métier qui existe déjà, qui sont soit développeurs ou développeuse, soit dans l'administration système. Est-ce que c'est un métier ou une approche ?

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 ce que j'ai fait d'ailleurs, en fait, je ne m'en cache pas - c'est que j'ai besoin de d'éclaircir avec le client ce qu'il entend par DevOps. En fait, le souci de cette approche DevOps, 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 va être de la sécurité informatique. Parfois, on va parler donc des backups (les sauvegardes), des solutions de stockage, qui sont plus donc 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 dis SRE : c'est un terme qui est un peu à la mode dans le milieu dans lequel nous évoluons, qui est donc ingénieur de fiabilité de site en français, mais c'est au final une implémentation de cette culture DevOps. C'est un poste qui va consister en s'occuper de la stabilité de la production afin de s'assurer qu'elle est toujours en place, qu'on a les bonnes informations sur comment elle tourne, qu'elle tourne bien, 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 condition opérationnelle ».

Mais dire 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é ». Je suis 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 l'équipe SRE de Google, qui dit : « SRE est ce qui se passe quand un ingénieur ou une ingénieuse logiciel, est chargé de ce qu'on appelle des opérations ». C'est ça, en fait ?

Romain Soufflet : Oui, c'est ça, c'est-à-dire qu'en fait, tout ce qui va être automatisables va être automatisé. On va voir donc 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. Donc, les applications, ce sont les développeurs qui les écrivent et moi, de mon point de vue, les développeurs, ce 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 mettent en production, je vais dire un peu tout seul, un peu de manière magique, qui va faire que tout fonctionne, sera monitoré correctement, avec des bonnes métriques, avec de quoi donner au management, on va dire, les informations sur qu'est-ce qui est en ligne, qu'est 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 : Les outils, on en parlera tout à l'heure dans une deuxième partie. On poursuivre là-dessus, donc toujours sur ma question. En fait donc, ce coup-ci, Xavier Talon. Donc, c'est un métier ? C'est une approche ? Tu disais en introduction que ORNESS, maintenant s'est positionnée sur cette pratique du DevOps. Donc par rapport à ça, c'est un métier, c'est une approche, comment ça se passe en fait ?

Xavier Talon  : L'objectif de DevOps, c'est, comme on le disait, d'aller vite sur des fonctionnalités bien définies, délimitées, pour faire des cycles courts. Mais pour le coup, c'est là ou le DevOps est un peu une extension de l'agilité qu'on est habitué à 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. Donc, ça veut dire qu'il va falloir faire des petites équipes où on va avoir toutes les compétences : développement, opération, sécurité, toutes les technologies qui vont être derrière, la qualité, le testing, etc.

Et donc, on voit tout de suite la complexité qui se pose : c'est qu'il faut que l'équipe maîtrise tous ces aspects. Donc, par l'automatisation, les outils, on facilite les choses, mais comment est-ce qu'on va le réaliser ? Donc on voit apparaître des nouveaux métiers, on voit apparaître aussi des personnes, enfin 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, le mouton à cinq pattes, il y en a assez peu.

Mais par contre, on voit qu'on va, d'une manière ou d'une autre, devoir dans les équipes introduire toutes ces compétences. Et du coup, il va aussi falloir lisser un petit peu le processus, pouvoir voir globalement comment est-ce qu'on met en place de la qualité. Et on a des 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 et 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, très vite pour pouvoir fournir, au rythme de deux semaines à deux mois, des realise, petites, mais les nouvelles versions du système, d'une solution, d'une application qui va permettre de cranter systématiquement de plus en plus de qualité et de stabilité dans les produits.

Frédéric Couchet : Alors, 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, 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 bug. Là où les équipes de devs veulent livrer le plus vite possible, etc.

Donc est-ce que l'un des enjeux ou l'un des défis de DevOps, c'est de réunir ces personnes qui ont a priori des antagonismes de fonctionnement historiques dans une même équipe, pour que les deux travaillent en cohérence avec, au final, rendre un système opérationnel pour le plus important qu'est la partie cliente ?

Xavier Talon  : Bien sûr, l'idée, effectivement, c'est d'enlever les barrières. Effectivement, on a deux populations qui ont 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. Les Obs, eux, leur objectif primaire, s'ils ne prennent que celui-là, c'est d'assurer la stabilité du système et d'empêcher qu'il y ait quoi que ce soit qui viennent l'impacter. On voit tout de suite cette friction.

Maintenant, l'idée du DevOps, une des idées principales, 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 juste des personnes ensemble, avec une qui va dire « Moi, j'ai besoin de faire telle fonctionnalité. Comment est-ce qu'on va 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 vous pouviez l'avoir il y a quelques années, et bien, ça serait passer par des équipes qui vont communiquer 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 : Oui, c'est tout à fait ça. Maintenant, effectivement, en pratique, on a cette difficulté, dans certaines grosses entreprises, d'un pôle sécurité qui n'est pas du tout convié dans les processus de développement et qui se retrouve à la fin du développement à dire « Pourquoi on ne nous a pas appelés ?».

Donc, effectivement, il y a 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, c'est parce qu'il y a une vraie transition à effectuer, beaucoup d'entreprises qui ont des modèles où l'humain n'est pas réellement au centre. L'application non plus n'est pas réellement au centre. Typiquement, cette équipe sécurité est souvent vu comme un ennemi du développement. C'est malheureux, mais c'est qu'on les prend un peu pour des empêcheurs de tourner en rond. C'est à dire que 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 des divergences énormes dans les entreprises.

C'est pour ça aussi qu'on parle de transition DevOps. C'est vraiment une question organisationnelle. Je sais que moi, personnellement, c'est très difficile d'agir là-dessus, parce que comme je suis indépendant, je suis tout seul par nature. Donc, arriver tout seul dans une grosse restructure et dire : « Vous vous organisez mal en terme de structure, parce qu'on a besoin de se parler tous ensemble », parfois c'est 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 ? Et quelle est la différence entre appliquer DevOps dans une équipe de développement et d'aide opérationnelles qui est toute petite, par nature, donc une petite structure, et quel est le défi de le faire dans une grosse structure, comme vient de le citer Romain, dans 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  : Ce sont des problématiques qui sont de deux niveaux différents et c'est ce qu'on va appeler la mise à l'échelle. Vous avez des méthodologies qui commencent à expliquer comment est-ce qu'on peut faire de l'agilité, Scrum, par exemple. Scrum est une des méthodes qui permet de faire de l'agilité. Et, effectivement, déjà, on s'aperçoit que la problématique de faire des petites équipes avec toutes les compétences pour un petit projet n'est pas simple. Mais alors 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é.

Et là, du coup, si on veut l'agilité, en terme d'équipe, le DevOps ça ne va pas marcher si on a des centaines de personnes. Or on a forcément des niveaux, des parcs applicatifs et des applications même, uniques, qui demandent d'organiser un très grand nombre de personnes. Et donc, du coup, comment est-ce qu'on va 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, faut assurer la cohérence. Donc il va falloir trouver un cadre méthodologique pour réaliser ça. Et c'est compliqué.

On a des méthodologies qui arrivent, qui sont mises en place, qui sont vraiment des méthodologies pour le coup assez complexes, typiquement Safe, qui est une méthodologie de monter à l'échelle et qui a justement pour objectif de démontrer 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.

Mais c'est là aussi assez compliqué. Ce n'est pas la seule méthodologie, et c'est des méthodologies qui, du coup, 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érents. Des organisations de compte qui peuvent être complexes à gérer. C'est 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, comme on pouvait les avoir avant, et ça.

Pourquoi ? Parce que toutes ces nouvelles méthodologies et ces approches agiles sont très différentes, très clivante par rapport aux organisations qu'on avait avant. On avait tendance, effectivement, à structurer, à siloter, on a une culture d'entreprise qui s'est construite et qui s'est consolidée pendant trente ans, quarante ans, sur ces modèles, qui visait justement à découper, à siloter, à stratifier et organiser par communication, par des outils de communication de passage entre les équipes. Et, en fait, il s'agit de déstructurer tout ça et de remettre une organisation, effectivement, qui est complètement à l'opposé, et c'est d'une complexité énorme.

Le problème n'est pas technique, c'est-à-dire que la mise en place du DevOps, on sait comment faire, on sait trouver les cibles, mais il y a rien de plus difficile que modifier les usages, la manière dont les gens travaillent, l'organisation. Faire du DevOps, c'est aussi un nouveau type d e métier, des 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 : Une question : on va adresser plutôt une problématique de grands comptes autres. 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 de se dire : « 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 de une migration vers une approche DevOps. Romain, et puis Xavier.

Romain Soufflet : Dans mon expérience, ce sont les entreprises qui m'appellent parce qu'ils ont déjà mis en place ou ils ont la volonté de mettre en place cette transition DevOps. C'est-à-dire que, de mon point de vue, la transition est surtout basée sur la technique, en fait. Techniquement, les applications ont énormément évolué ces dix dernières années, avec surtout l'arrivée des des clouds et des clouds public, donc 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 et donc, à partir de là, la mise en production est plus simple. Mais c'est surtout des problématiques, je vais dire, de marché, en fait, qui donc incitent les entreprises à vouloir déployer plus vite, plus rapidement et plus souvent des 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. Et c'est cet usage, on va dire, d'utilisateur final, qui pousse les entreprises à se remettre en question et à faire cette transition DevOps.

De mon expérience, ce n'est pas des prestataires comme moi qui viennent pour pousser cette transition. Le client me demande : nous voulons 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 qu'ils sont clairement pas structurés de cette manière-là pour la plupart des grosses entreprises.

Et, effectivement, c'est beaucoup plus facile pour des petites équipes d'être agiles et d'être DevOps, parce qu'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, c'est quand même difficile de connaître tout le monde, et de partager et de communiquer.

Frédéric Couchet : Je suppose la problématique est la même pour ORNESS, et je suppose peut-être - mais tu vas me 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 leur - entre guillemets - « vendre l'intérêt d'une démarche DevOps ».

Xavier Talon  : Alors, 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. Et ils vont se retrouver souvent 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'ils partent de rien, ils n'ont pas tout à adapter. Et, en fait, ils n'ont pas le choix : ils se retrouvent de facto face à des concurrents qui, quand eux il leur faudra six mois, un an, sinon plus, pour sortir un nouveau produit, le même produit, avec le même niveau de conception, et bien la fintech, à côté, par rapport à une banque par exemple...

Frédéric Couchet : Fintech, c'est une entreprise de la finance, c'est ça ?

Xavier Talon  : Oui, voilà, mais qui sont sur un mode un petit peu, société nouvelle génération qui, immédiatement, va arriver sur le marché et pouvoir s'organiser, eux, sans avoir l'historique, sans avoir à gérer leur existence.

Donc, à partir de ce moment-là, pour eux, c'est vital. Donc, 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'ont la concurrence.

Après, quand je disais tout à l'heure 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, par étapes. En mettant les choses simplement, et en plus 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. Évidemment, ça prend beaucoup plus de temps. Mais la plupart des grands comptes français ont commencé leur transformation vers ces objectifs-là 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 et 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 Cheap et Odysseus. ??? On se retrouve dans environ deux minutes. Belle journée à l'écoute de Cause Commune, la voix des possibles.

Nous venons d'écouter Un instant, par Cheap et Odysseus, disponible sous licence libre.

[Virgule musicale]

Deuxième partie

Frédéric Couchet : Nous allons poursuivre notre sujet principal, 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, n'hésitez pas, ou des réponses, n'hésitez pas à nous appeler.

Donc, on a un petit peu dégrossi à gros traits avant la pause musicale ce qu'était 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. Et pendant qu'on écoutait cette belle musique, Romain 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 ? Donc, toi, ta réponse, c'est la bière ou tout autre boisson non alcoolisée ou alcoolisée.

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

Et donc, au final, les entreprises où il y a des apéros ou des bières, j'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 quinze ans sans jamais s'être parlé ou sans jamais se voir. Le fait de se voir à la machine à café ou devant une bière, ça permet vraiment de casser les barrières et de faire en sorte que les différentes personnes de l'entreprise se parlent.

Moi, le premier conseil que je donne en général, 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 vraiment anime une communauté, ça fait vraiment faire communauté dans l'entreprise. Ça permet donc d'abolir ces barrières et d'augmenter la communication, et en plus ça ne coûte pas cher.

Frédéric Couchet : Et de remettre donc l'humain et la communication au centre. J'aurais tendance à dire qu'une entreprise qui, au bout de quinze 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...

Donc, même question pour Xavier. Là, on parle plutôt d'une petite structure, parce que les grands comptes organisent aussi des événements. Mais comment ça se passe dans un grand compte, c'est quoi la première approche, comment ça se passe quand vous arrivez ?

Xavier Talon  : Quand on arrive, c'est exactement le même problème qui reste à résoudre : effectivement, comment faire que les gens communiquent directement. Et, de fait, c'est pas seulement vrai, ça a été toujours un peu vrai, mais beaucoup de choses se font à la machine à café. Quand on a des difficultés et donc 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 le résoudre, la plus efficace, c'est que les gens parlent, et donc de réussir à introduire des moments dans la journée où les gens vont directement pouvoir discuter, autour d'un café, d'un repas. Ça fait énormément avancer un projet. C'est la réalité.

Après, dans des grands comptes effectivement, on peut avoir des organisations très différentes. Parfois les gens qui vont écrire le code sont même 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  : Et ils répondent à des commandes. Alors là, évidemment, on a des contextes comme ça qui sont plus difficiles à traiter. Donc, ç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 justement aussi séparé les différents métiers dans des localisations différents, dans des équipes différentes, parfois dans des entités différentes de la même entreprise. Et là aussi, toutes les questions qu'on se pose, c'est comment faire que les gens puissent interagir beaucoup mieux. Et donc, on va déléguer, déplacer des personnes. Ça fait partie des recettes qui vont permettre de mieux fonctionner.

Et puis 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 outils sont nécessaires pour des gens qui sont effectivement à distance, c'est-à-dire dans différents sites, voire dans différents pays ? Et quels types d'outils sont 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. Et puis, après, il y a aussi des outils de communication. Et finalement, ce 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 : les mêmes recettes sont applicables, bien évidemment. Et d'ailleurs il y a une vraie inspiration qui peut venir des communautés du libre qui peuvent être utilisées pour ça.

Et puis, 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 fait aussi partie et c'est encore bien évidemment plus efficace pour le fonctionnement, mais c'est ce qu'on disait tout à l'heure.

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 de la manière dont est structurée une organisation.

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

Xavier Talon  : Dans mes expériences récentes, dans mes dernières missions, j'ai eu donc ce cas. On initie donc 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 profil 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.

Et même 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, oui, c'est déjà arrivé qu'on nous rejette. Et là, il faut quasiment inventé une nouvelle façon d'en discuter, d'en parler pour ne pas brusquer des personnes. Donc, le côté humain est extrêmement important. [22:01]

Il faut savoir que quand on parle d'équipe, on parle des humains qui composent les équipes, et donc ça, c'est vraiment quelque chose de primordial, je pense, quand on fait un peu de l'évangélisme, on va dire sur le DevOps. C'est 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. Et si vous êtes à deux ans de votre retraite, vous n'avez pas envie de changer de métier, ça peut se comprendre. Donc, ça, c'est une qualité primordiale, je pense, 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 de changement, et c'est l'une des plus complexes qu'on ait eu à mettre en œuvre depuis les - on va dire - quarante 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 mais composée de 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 que un des grands plaisirs dans l'informatique, c'est aussi de faire des choses nouvelles régulièrement. Et donc ça marche bien dans ce contexte-là.

Et 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 on écoutait 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 va être, dans ce genre de structure, arriver à convaincre ces équipes-là, effectivement, de faire 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 parle même pas physiquement, mais de bouger dans leur fonctionnement.

Xavier Talon  : Je ne dirais pas forcément tout à fait ça. Alors 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. Et, en fait, les équipes du mainframe sont venus nous trouver en disant : nous, on a envie de conduire notre transformation et d'essayer de voir comment on peut faire de l'agilité avec notre mainframe.

Frédéric Couchet : Mainframe, c'est les gros ordinateurs...

Xavier Talon  : Des gros ordinateurs centralisés. C'était aussi des systèmes extrêmement robustes. Le code de votre banque, pour la plupart des banques françaises, c'est un code qui a été écrit peut-être il y a quarante 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. Et 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 mainsframe de façon à pouvoir accélérer les développements, et ça a très bien fonctionné.

Non, le problème qu'il y a, c'est plus une culture d'entreprise et une culture personnelle aussi. Ce qu'il faut voir, c'est que on va demander aux gens plutôt de transformer leur manière de travailler, de transformer même leur métier, d'intégrer d'autres activités, d'autres choses. Mais aussi d'avoir une autre vue. C'est à dire que, typiquement, quand on a par exemple mis en place notre société, nous, 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. C'est à dire que lui travaillait sur des systèmes techniques. Après qu'est-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. Et même s'ils ont un travail plus Ops que développeurs, eh bien en fait, ils vont vraiment communiquer, même 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é ?

Et 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'elle réalise, 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 puis s'il y avait quelque chose, hop !, c'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. Et c'est ce changement culturel  : les équipes ont plus d'autonomie, le travail peut devenir beaucoup plus intéressant. Mais qu'il faut réussir à accepter, avec la responsabilité que cela implique. Et ça, c'est 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 n'est 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 la question que je me pose est : 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 ça correspond à une réelle réalité, ces fiches métiers ? Et est-ce qu'il y a des formations ? Quelqu'un qui se dit : tiens, moi l'approche DevOps m'intéresse, mais est-ce qu'il existe des formations, ou est-ce que finalement la formation c' est un peu sur le tas, ou quand on travaille sur des projets. Romain ?

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

Frédéric Couchet : Explique ce que c'est que pipeline d'intégration continue, et 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 dans toute une batterie de tests, on va leur faire passer différents scripts pour les construire, pour vérifier qu'ils fonctionne bien, pour les intégrer avec le reste du travail de l'équipe. Donc, tout ça, c'est comme une usine d'assemblage, en fait, et tout 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.

Et donc dans pas mal d'entreprises, quand ils parlent de DevOps, ils 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 condition opérationnelle, s'occuper des serveurs.

Donc voilà, c'est quand même très diverse. Si je disais : je veux faire une formation DevOps, j'ai besoin de faire un paragraphe derrière pour dire de quoi je parle. Et c'est ça 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 nous par ce mot, et qu'est-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à, la fiche de poste est plus précise. Et il y a moins d'ambiguïté; c'est-à-dire que d'autres personnes qui connaissent l'ingénieur de fiabilité de site savent de quoi je parle et savent qu'elle est, on va dire, le périmètre de de mon travail. C'est plus facile de parler donc 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, en fait, ce qu'on voit, 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. Alors on peut avoir des des gens qui vont être un peu des tech lead, qui vont avoir un peu 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 ont pouvoir assumer toutes les tâches qu'il y a à faire.

Par contre, c'est un domaine comme toute nouveauté, il faut quelques années pour que tout ça se formalise, que ça se stabilise. On voit émerger un peu les différentes définitions et métiers qui vont avec. Et on commence à le voir. Les SRE, il y a quelques années, on n'en parlait pas. 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é, et donc le poste s'est créé. Et lui, pour le coup, il est très clair. Et donc on commence à voir des aspects comme les product owners il y a quelques années. Comme les SRE aujourd'hui, etc. Et on commence à voir les choses se stabiliser. Ces définitions qui commencent à se poser, ces fiches métier qui deviennent de plus en plus claires. Avec le temps, on va arriver à ce que ça devienne une normalité et on aura commencé à poser les choses.

Frédéric Couchet : D'accord. Question rapide, puisque vous l'avez abordé indirectement dans vos réponses sur les outils, en fait, et la partie de logiciel libre. Pour mettre en œuvre cette approche, en fait, cette partie technologique, il y a plein d'outils de logiciels libres 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, sur les tests, sur le monitoring, sur le suivi de l'application en conditions opérationnelles : tout ça, c'est faisable, en fait, avec des logiciels d'un point de vue technique.

Qui parle ?D'un point de vue technique, oui. En fait, moi, 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,

C'est-à-dire qu'au final, le métier est assez nouveau. Ça fait moins de dix ans qu'on parle donc de ces cultures DevOps et ces problématiques-là. Donc, 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 que on s'est trompé de problème.

C'est vrai que ça, c'est un gros avantage. On n'écrit pas énormément de code lorsque l'on fait du SRE, cette culture DevOps. Souvent on va réutiliser des choses que d'autres ont fait, les adapter, contribuer aussi. Mais c'est assez rare que je déploie un projet de a à z dans mon 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 et c'est une communauté, au final, qui collabore énormément, même inter-entreprises, et ça, c'est quelque chose qui fait très plaisir à voir.

Donc, 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, tu me fais en plus la transition avec le dernier sujet. Le temps passe super vite... Tu viens d'employer le terme communauté. Et Xavier, tu voulais aborder un sujet, justement sur cette construction de communauté à travers l'association, notamment, de DitRit.

Xavier Talon  : Tout à fait. En fait, je pense que DitRit c'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 agilité en général. On s'est rendu compte finalement, de client en client, qu'on rencontrait tout le temps un peu les mêmes problématiques. Et on l'a vu, la mise en œuvre de DevOps, c'est compliqué, surtout quand il y a un gros existant, etc. Et finalement, on se retrouvait toujours un petit peu avec la même manière de travailler, où les gens veulent mettre en place l'approche, se disent: aujourd'hui, on a des outils.

Alors, il y a beaucoup d'outils, effectivement, les outils open source, c'est un peu la base aujourd'hui. Une société qui voudrait faire du code propriétaire pour traiter ce type de problématique, ça serait difficile d'avoir les reins assez solides 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 avoir besoin de les adapter, forcément : l'outil qui fera tout, c'est difficile. Et la communauté open source, aujourd'hui, c'est 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.

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

Et donc, ce qu'on observait souvent, c'est tiens, on va traiter une application, on prend une application-type, le cas d'école. Tout ce qui gêne, la sécurité, tout ce qui est un petit peu compliqué, la sécurité, la résilience, tous ces aspects-là, on 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 à avoir vraiment toute la complexité, tout ce que ça veut dire, parce que, bêtement, par exemple, il faut s'intégrer avec tout le reste du système d'information, il faut traiter la sécurité...

Alors on s'éponge bien, on remet encore de l'huile dans les rouages, on met les moyens, on remet des personnes et on s'en tire. Puis 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é. Et on retrouve ce type de problématique un peu partout et à peu près systématiquement chez tous nos clients qui se sont lancés dans des démarches.

Et du coup, ce qu'on a pu voir aussi avec eux, c'est qu'on arrivait à identifier des manières de traiter ça. En se disant tiens. finalement, avec des approches comme, par exemple, celle qui consiste à essayer de non pas directement implémenter des configurations techniques, mais essayer de modéliser, d'avoir des outils qui vont nous permettre d'identifier finalement 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 une des choses qui sont très complexes  : un code typiquement d'infrastructures, tel que peuvent le concevoir des gens comme Romain ou les gens avec lesquels ils travaillent, c'est assez difficile de les réutiliser d'une application sur une autre. Et donc on a trouvé des moyens de commencer à identifier des choses, donc on a commencé à faire à différents endroits des idées qui semblaient intéressantes. Et puis après, on s'est dit: tiens, finalement, on peut pas toujours, en clientèle, 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é à faire de la R&D, comme le font toutes les sociétés en interne, et on s'est retrouvé à faire de l'entre-soi. Et puis, finalement, nous, avec notre petite taille - on est pas gros pour une société de services - et bien, on n'avait pas les reins assez solides pour pouvoir créer du logiciel et typiquement mettre en œuvre des applications et des concepts qu'on était en train de développer.

Et là on s'est dit : mais finalement on y perd. Même avant où on faisait ça par rapport à des chantiers 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 de se dire un moment : et si on externalisait notre recherche et développement, si on jouait l'intelligence collective? Et là, toute l'idée, ça a été ce constat, se dire : on est beaucoup plus fort à plusieurs, c'est nous de toute façon, si on veut le faire nous-mêmes, si on veut aller créer ce type de solutions nous-mêmes, on n'aura pas les moyens de le faire, ou en tout cas, on n'a pas la taille pour pouvoir faire ça.

Et finalement, si on crée une communauté basée sur les idées libristes. Et donc on a créé une association loi 1901, qui s'appelle DitRit et qui a pour vocation de travailler sur tout ce qui est transformation numérique. Et 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 : ce qu'on arrive à faire avec d'autres pour ces grands comptes, il y a surement moyen de le rendre disponible pour tout un chacun. Et si on est vraiment sur une organisation transverse qui n'a strictement aucun intérêt pécuniaire, on va dire, et qu'on arrive à attirer et à créer une vraie communauté d'entreprises, d'étudiants, d'universités, de personnes simplement qui ont envie de donner leur temps et qui veulent faire avancer des causes comme ça, et bien, on pourra faire quelque chose d'intéressant.

Et c'est ce qu'on a fait. Et donc, DitRit s'est construit, et dans DitRit, on va avoir un étage réflexion, un think tank ???. Donc, on a un étage réflexion, des groupes de travail - par exemple on en a un sur la souveraineté numérique, on a un groupe de travail sur l'éthique et les communs. Donc, on est vraiment dans l'esprit, rentre évidemment là-dedans tout ce qu'on peut identifier sur le libre.

Et puis on a une incubation de projets open source. Ces projets open source, c'est dans les statuts de la société que ça ne pourra jamais donner lieu à des fonctionnalités ou à quelque utilisation commerciale que ce soit. Et cet incubateur a pour vocation de mettre en pratique des idées, des principes, et de créer des solutions auxquelles on croit, auxquels on a, par l'expérience, vu qu'on pouvait faire des choses intéressantes, et de rassembler une communauté autour de ça pour avancer.

Et donc on a des collaborations au sein de DitRit avec des sociétés. On a EdF, la Société Générale, par exemple, qui participent à des travaux. On va avoir des écoles qui viennent, des universitaires qui participent aux travaux, et des contributeurs qui viennent de tous horizons.

Et c'est intéressant, puisque, pour nous, 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. Et on n'est pas les seuls. On commence à être rejoint par différentes sociétés qui jouent le jeu, qui viennent, et c'est extrêmement enrichissant. Et 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 que c'est un vrai coup d'accélérateur. Donc, Bercy nous a reconnu ce statut et ça va nous permettre d'accélérer encore. On commence à avoir des vraies contributions avec différentes sociétés. Et là, on voit toute la puissance que peut avoir cet aspect communautaire et libre, qui fait que ça nous fait un levier qui nous permet vraiment d'accélérer ces développements, et c'est extrêmement intéressant.

Frédéric Couchet : Voilà. Excusez-moi pour la sonnerie, c'est marrant parce que j'allais te dire qu'on arrive à la fin du sujet. Donc je m'excuse pour cette sonnerie.

Alors 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. Et ça me fait penser que ce sujet de collaboration entre entreprises du libre, industriels, grands comptes sur des problématiques communes, on va en parler dans les émissions, notamment peut-être autour de PostgreSQL, bientôt.

Mais on arrive en fin de sujet, parce que voilà, on a un sujet court juste après. Je vais vous faire la dernière question traditionnelle de libreavous, du sujet principal. Donc, 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 : Alors 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 qu'est-ce que ça veut dire, donc, 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 de l'un 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 donc tous ces messages et que nos auditeurs puissent comprendre cette notion et déjà un peu démystifier ce mot très obscur qu'est DevOps.

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

Xavier Talon  : Moi, ce que je dirais, c'est que ce qu'il faut retenir, c'est que DevOps, c'est une approche qui permet vraiment d'apporter beaucoup de valeur et qui, surtout, permet de recentrer aussi l'humain dans le tableau et qui, du coup, est une vraie transformation importante et qui touche vraiment tous les aspects.

Et, par contre, ce que je pense qu'il faut retenir aussi, c'est que DevOps n'est pas juste un outil ou l'utilisation d'outils. 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.

Et, comme le disait Romain, il faut dès le départ intégrer la sécurité, avoir vraiment une vraie démarche d'architecture, etc. Puisque le vrai risque - et je pense que ça, 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. Et quand on fait des petits pas sans savoir vers où on va, c'est le meilleur moyen de se prendre le mur.

Et c'est aussi un des enseignements du DevOps, c'est 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 essayé de vous montrer aussi, c'est toutes les réalités, toutes les facettes de ce monde DevOps, et 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, vous avez vraiment répondu au défi de faire comprendre ce qu'est DevOps au public de libreavous. Nos invités : Xavier Talon, co-fondateur 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. Après la pause musicale, nous entendrons la chronique de véronique Bonnet sur le monde du Libre. En attendant, nous allons écouter ???. 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.

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 mode 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 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 Mauricie 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 monde monolithique, homogène, ce qui serait un monde tyrannique ; deuxième illusion, qu’il y aurait 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, 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 dans 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 connaissance 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, 75 018 Paris et ensuite ça sera un rendez-vous chaque premier mardi du mois à partir de 19 heures.

Comment échapper à la surveillance des GAFAM, ces géants du Net qui se goinfrent nos données personnelles. L’association L’é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@libreavous.org.
Si vous préférez nous parler, vous pouvez nous laisser un message sur le répondeur de la radio pour 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éos 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.