É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 développe, 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 développe, c'est-à-dire qu'en fait, il y a une vraie transition à effectuer de beaucoup d'entreprises qui ont des modèles où l'humain est 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 que, bah, 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 parle beaucoup trop tard, ça ne fonctionne pas bien et ça crée des divergences énormes dans les entreprises. Donc, là, c'est pour ça aussi, on parle de transition des veuves. C'est vraiment beaucoup de ses romans. Une question organisationnelle et je sais que moi, pour moi personnellement, c'est très difficile d'agir là-dessus, que comme je suis indépendant, je suis tout seul par nature. Donc, arriver tout seul dans une grosse restructure et dire: vous organisez mal en terme de structure parce que on a besoin de se parler tous ensemble, parfois, c'est quand même un discours qui a du mal à passer et c'est là 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 par douze questions. Je 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 des veuves dans une équipe de développement et d'aide opérationnelles qui toute petite, nette par nature, donc une petite structure, et qu'elle elle dit le défi de le faire dans une grosse structure, comme vient de le citer? Romain, donc une grande banque ou une grande collectivité que c'est? je suppose que les défis ne sont pas les mêmes et il est la mise en œuvre n'est pas la même, xavier talent. C'est, c'est des problématiques qui sont de deux niveaux différents et c'est ce qu'on va appeler la mise à l'échelle. Et donc, vous avez des méthodologies qui permettent, qui commence à expliquer comment est-ce qu'on peut faire de l'agilité scrum, par exemple. Des méthodes qui sont quand même, c'est une des méthodes qui, c'est une méthode qui permet de faire sa formule d'agilité et, effectivement, déjà, on sapé Soit 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 et des crocs aux applications énorme avec énormément de fonctionnalités, etc. Ça devient beaucoup plus compliqué. Et là, du coup, si on veut, L'agilité le développe son lui-même. En termes d'équipe, ça n'a pas marché si on a des centaines de personnes. Or, on a forcément des niveaux, des parcs applicatifs et des applications. Même unique qui demande? Deux, deux, deux, deux, d'organiser un très grand nombre de personnes. Et donc, du coup, comment est-ce qu'on va faire? et donc, 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 ça devrait. 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 self, qui est une une méthodologie de monter à l'échelle pour créer de nouveaux cef, en anglais. Tout à fait. Et qui a justement pour objectif de démontrer ou de d'organiser une 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. 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 de chaque système d'information spécifique. On a un ensemble de technologies qui peuvent être extrêmement différents. Des organisations de de de compte, qui peuvent être complexes à gérer, fait des vrais chantiers de transformation. Ils sont vraiment importants et qui sont difficiles à mettre en oeuvre. Typiquement, il faut considérer qu'il faut une bonne dizaine d'années pour transformer l'organisation. D'un grand compte pour aller de fin de deuil d'une organisation classique. Qui peut y t-il qu'on pourrait les avoir avant? et ça pourquoi? puisque toutes ces nouvelles méthodologies et ses approches agiles sont très différentes, sont très clivante par rapport aux organisations qu'on avait avant. On avait tendance, effectivement à structure. Silo t on a une culture d'entreprise qui est: Construite et qui s'est consolidée pendant trente ans, quarante ans sur ces modèles, qui visait justement à découper, à siffloter, a stratifié et organisé 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 le développe sa mise en place. 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 de métier, des nouvelles manières de gérer du personnel. Donc, c'est aussi une remise en cause des haches des budgets, c'est une transformation très globale du système d'information à leurs questions. On va s'adresser plutôt. Bien compris une problématique de grands comptes autres. Je suppose qu'il faut un engagement très fort de la direction générale. Et c'est quoi la première approche que vous avez pour les convaincre de se dire: on va se lancer dans un chantier de dix ans pour refont toute l'organisation. C'est quoi? c'est le fait de produire des logiciels de meilleure qualité? est-ce que c'est le plaisir des équipes qui vont travailler, parce que, justement, ils vont travailler différemment, donc avec plus de plaisir? c'est quoi? Votre première approche pour, pour essayer de convaincre déjà de se lancer dans cette étude: migration vers une approche DevOps. Romain, et puis xavier. Après, on a l'inverse comme vous voulez. En fait, moi, j'ai, dans mon expérience, Dans mon expérience, c'est que les entreprises m'appellent parce qu'ils ont déjà mis en place ou disaient: ils ont la volonté de se mettre en place. Cette transition développe en fait. C'est-à-dire que, de mon point de vue, la transition et surtout Basé sur la technique. En fait, c'est que, techniquement, les applications ont énormément évolué ces dix dernières années, avec surtout l'arrivée des d'éclats ou de l'éclat de 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à, l'amisom production est plus simple. Mais c'est surtout des problématiques, je vais dire, de marcher, en fait, qui donc incite les Reprise à vouloir déployer plus vite, plus rapidement et plus souvent des nouvelles fonctionnalités, d'être plus agiles d'en bas, 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 de deux. Mon expérience, ce n'est pas des prestataires comme moi qui viennent d'accord pour pousser cette transition, c'est le client me demande: nous voulons transition vers un modèle des vols, vers un modèle plus agile, plus rapide, et c'est à partir de là que les problèmes commencent, parce que 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 agile et d'être développe, parce que en étant une petite équipe, on se parle beaucoup plus facilement. Les problèmes viennent justement avec cette mise à l'échelle des grosses entreprises. On est cinq mille, c'est quand même difficile de connaître tout le monde. Deux, et de partager et de communiquer. Je suppose la problématique est la même pour ernest 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 leurs- entre guillemets- leur vendre l'intérêt d'une démarche DevOps. Alors on a, comme le disait romain, on n'a pas vraiment besoin de le défendre aujourd'hui. C'est une évidence de dire que les clients, depuis un certain nombre d'années. Se retrouve 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 ont Toutes tout, tout ça adapté. Et, en fait, ils ont pas le choix. Ils se retrouvent de facto face à des concurrents qui, quant à 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. La fintech, qui est à côté, par rapport à une banque, par exemple, va peut-être pouvoir, diront que c'est une entreprise doit financer ça. Oui, voilà, mais, garçons, 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 sont ne n'ont pas vraiment le choix. Il faut pouvoir adapter les mêmes. Un outil, les mêmes démarches, les mêmes capacités, qu'on la concurrence. Après. Quand je disais tout à l'heure: il faut une dizaine d'années. Pour, pour se transformer, pour arriver à maturité. Bien évidemment, on peut commencer à faire des choses, à transformer, par étapes. D'information. Voilà, en mettant les choses maintenant. Ce 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. A tous ces niveaux dont on parlait aussi bien à la finance. La gestion, l'organisation, la gouvernance. Évidemment, ça prend beaucoup plus de temps, mais- et la plupart des grands comptes français ont commencé leur transformation vers ces objectifs là il y a déjà cinq, sinon plus il y a quelques années- souvent des chats depuis sept, huit ans. D'accord, on va faire une pause musicale et après la pause musicale, on va avoir un peu plus en pratique, comme on commence. Ça se met en place dans des organisations. En attendant, nous allons écouter un instant par cheap et odyssée us. 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 type et odyssée disponible sous licence libre. Retrouvez toutes les musiques diffusées au cours des émissions sur cause commune. Point f m est sûr, libre à vous. Point org library- libre à vous. Libra l'émission de l'april sur les libertés informatiques, chaque mardi, de quinze h trente à dix sept heures sur radio cause commune, puis en podcast.

Deuxième partie = Eve

Frédéric Couchet :

Nous allons poursuivre notre sujet principal, qui porte sur l'approche DevOps, avec nos invités xavier talon et romain souffler. Je vous rappelle que vous pouvez participer à votre conversation: zéro neuf, soixante douze cinquante et un cinquante cinq quarante six. Je le répète: zéro neuf, soixante douze cinquante et un cinquante cinq, quarante six. Si vous avez des questions, n'hésitez pas, ou des réponses, n'hésitez pas à nous appeler. Alors. Donc, on a, on a un petit peu dégrossi à gros traits avant la pause musicale qui était dévote. J'annonce avant la pause qu'on allait peut-être un peu rentrer dans la mise en œuvre. On lui conseille pour, pour commencer à mettre, et pendant qu'on écoutait cette, 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? donc, toi, ta réponse, c'est la bière du mois. Boissons non alcoolisées ou alcoolisées, pas é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 dans l'entreprise, rencontrer un maximum de personnes, parce que quand j'ai besoin de lui parler, à la sécurité, comme ça, 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 on parler, et ainsi de suite. Et donc, au final, Les entreprises où il y a donc 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 qui sont organisationnels, les, 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 que les différentes personnes à l'entreprise se parlent. Moi, le premier conseil que je donne en général, c'est: fait 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 coûte pas cher- et de remettre donc l'ue. Et la communication au centre. J'aurais tendance à dire que c'est une entreprise. 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. C'est un autre sujet. Donc, même question pour. Pour carla, c'est rond. On parle plutôt d'une petite structure, parce que les grands comptes organise 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. Quand on arrive, c'est exactement le même problème qui arrive, qui reste à résoudre, c'est-à-dire, 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é. C'est clair que. Quand on a des difficultés et donc on est là pour chercher à aplanir des des, des, des des complexités, des difficultés qui sont posées entre des équipes qui sont pas forcément alignés, des gens qu'on peut, qui ne maîtrisent pas forcément les besoins d'une autre équipe, etc. La seule manière est 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. Autour d'un café, autour d'un repas, autour de discuter. Ç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, des fois les gens qui vont écrire le code, ils sont même encore à sourcer. Pourquoi pas dans un autre pays- on va avoir des avis sur ces sujets- qui travaillent en dehors de? Prison va dehors et répondent à des commandes en classe et é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 et qu'on, parce qu'on a justement aussi séparer les différentes des différents métiers dans des localisations différents, Dans des équipes différentes, des fois dans des entités différentes de la même entreprise, et va 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. Tous ça fait partie des recettes qui vont permettre de mieux fonctionner, puis aussi pas tous les outils collaboratifs qui maintient les salles virtuelles de rapprocher les gens. Plutôt, une de mes questions, c'est que dans, je vois bien comment ça, ça peut être. Mise en oeuvre dans une équipe où les gens sont physiquement sur le sur le même lieu. Mais quels outils sont nécessaires pour des gens qui sont effectivement à distance, certes 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 autre d'ailleurs? 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 livre, 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, 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. A travers la structure, de 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. À part. Et ce qui est des qualités ou des compétences qui sont nécessaires dans les équipes. Qui existent, qui vont se mettre à cette approche DevOps, c'est ce qui font des choses qui parlent. On pourrait mettre en question cette approche DevOps, les blocages. Qu'ils soient organisés ou humains. La chance, plutôt nos équipes actuelles, donc humaine, plutôt que moi- dans mon expérience récente, dans mes dernières missions, j'ai eu donc ce cas- c'est que 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 des profil. L'usager, qui sont vraiment pas contents du tout de bouger. C'est une grande difficulté. De la transition développe, c'est que 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- développe un rejet, même un rejet, oui, oui, c'est déjà arrivé qu'on nous rejette, ou là, il faut quasiment inventé une nouvelle. Une nouvelle façon d'en discuter est une nouvelle façon d'en parler pour ne pas brusquer des personnes. Donc, 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, et donc ça, c'est vraiment quelque chose de primordial. Je pense donc, quand on, quand on est, quand on fait un peu du de l'évangélisme, on va dire sur le dévote, 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 masse. Hier. 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 comme une qualité primordiale, je pense, avant de s'attaquer au sujet. En fait, c'est donc, en fait, c'est de la conduite, du changement. Complètement. La mise en œuvre de la conduite de changement, et c'est 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 là la transformation la plus complexe à opérer. Fiche, si je comprends bien ce que dit romain, ça marche mieux. Même si l'entreprise est importante, où la survie est importante, mais composée de plutôt de deux d'équipes de jeunes qui sont en début de carrière ou mi-carrière et qui sont 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 ça va être plus compliqué, c'est les fameux grands comptes. Va voir les grands comptes administrations où vous avez encore des vieux systèmes staff. Ce matin d'écouter, Une conférence sur les algorithmes. Quelqu'un? vous parlez des logiciels utilisés par la cnam dans des langages comme cobol et autres. Donc là, le vrai défi va être: dans ce genre de structure, vous serez va arriver à convaincre ses équipes, l'ad effectivement, de faire une conduite du changement qui va remettre en cause leurs pratiques actuelles. Un mot ou 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. Je ne dirais pas forcément tout à fait ça. Alors voilà pour l'anecdote. Moi, je vais travailler pour un de nos clients grands comptes qui, quatre vingt dix sept pour cent de son cœur d'information, qui 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 manchon est faite pour les gros ordinateurs. Ordinateur centralisé. Ils ont fait: on a, on a. Alors c'était: Aussi des systèmes extrêmement robustes. Le code: 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 pour le mainframe, où on a réussi à faire des choses très intéressantes, à virtualiser des des des des machines de type mainstream, de façon à pouvoir accélérer les développements, et ça a très bien fonctionné. Dans le problème qu'il, qui a fait plus une, une culture d'entreprise et une culture personnelle aussi, ce qu'il faut voir, c'est que John, 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, de 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, Vous n'avez pas forcément une vision de pourquoi il opérait- de dire qu'il avait lu: il travaillait sur des, 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. Quelle 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 up que typiquement développeur, eh bien en fait, ils font 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? quelle 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 ont parlé, les équipes DevOps, qui vont créer un service, une fonctionnalité, une application, vous en êtes responsable. Et vous en êtes responsables non pas juste sur la partie technique qu'elle réalise, mais avant avoir une responsabilité globale de tout ce qui va se passer, même dans le rhône, dans le Fonctionnement de l'application quand elle va être mise à disposition des utilisateurs. Et là. Eh bien, ç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 bastille avait quelque chose. Hein, c'est pas chez moi. Je viens pour toi. C'est une mise en responsabilité des équipes qui 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. D'accord. On voit bien que les thèmes qui reviennent souvent, ces approches, philosophie, culture, DevOps, donc c'est pas forcément un métier, mais la question que je me pose, c'est: est-ce qu'il existe une fiche métier DevOps et, corollaire, la question qui vise des formations. DevOps si je cherche formation des leurs. En fait, j'ai trouvé fiche métier sur des sites. Mais est-ce que c'est, est-ce que ça correspond une vraie, vraie réalité, ces fiches métiers et des formations? quelqu'un qui veut dire: tiens là, mais l'approche DevOps m'intéresse, mais est-ce qu'il existe des formations, ou est-ce que l'information c'est un peu sur le tas, ou quand on travaille sur des projets romains, alors on va être sur. Quand on parle, développe souvent chez les clients, on a vraiment besoin de communiquer un peu plus loin pour savoir. Qu'est ce qu'ils entendent par ce terme là. Et souvent, ce sont des postes techniques qui sont décrits avec le mot développe. Donc, oui, on peut fait, on peut imaginer faire des formations pour les, les, les fameux pipeline d'intégration continue qui sont, on va dire, comme des usines logicielles. Explique, formatrice, pic, ce que c'est qu'une pâte, le pipeline d'intégration vous explique ce que c'est que l'intégration. Ça va être une liaison convenable quand les développeurs vont travailler, vont envoyer leurs changements, et donc, ces changements, on va leur faire passer toute une batterie de tests, on va leur faire passer différents scripts pour les construire, pour les vérifier qui fonctionne bien, pour les intégrer avec le reste du travail de l'équipe. Donc, tout ça, c'est, 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 pour, au final, arriver à une application packagée, fini, et donc pas mal d'entreprises quand il parle de développe. Ils veulent un ingénieur capable d'écrire ce pipeline. Certaines entreprises demandent un dévote, 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 comme très diverses. 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 des veuves de culture développe, c'est que le terme est tellement fou que on a vraiment besoin de faire un paragraphe derrière et de bien expliquer qu'est ce que nous on entend 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, jusque-là, du coup là, la fiche de poste et plus Précise. Et il y a moins d'ambiguïté dire que d'autres personnes qui connaissent le 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 du coup toute une présentation des vox à chaque client, parce que je passe beaucoup de temps à en parler. Et ça devient vite long. D'accord sur cette question, xavier. Tu voulais rajouter quelque chose. Oui, en fait, ce qu'on voit, si vous voyez une fiche de poste, DevOps, méfiance, le fait 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 existe pas. Alors on peut avoir des des gens. Qui iront, qui vont être un peu des tech lead, qui vont pouvoir un peu avoir une vision assez globale de l'ensemble des outils, des processus, qui vont pouvoir former les autres, mais c'est pas des, c'est 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, qu'on veut Voit émerger un peu les différentes Les différents. Nos différentes définitions et métiers qui vont avec. Et on commence à voir les ferreux. Il y a quelques années, on n'en parlait pas. C'est une fée, c'est une nécessité, 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 secret. Et lui, pour le coup, il est très clair. Et donc on commence à voir des aspects comme les producteurs. Il y a quelques Années comme lui, assez heureux aujourd'hui, etc. Et on commence à voir les choses se stabiliser. Ces définitions qui commencent à se poser, c'est fiche métier qui devient de plus en plus claire. Avec le temps, on va arriver à ce que ça devienne une normalité et on aura commencé à poser les choses. D'accord, hum, hum, ah. Question rapide: combien vous voulez? vous l'avez abordé. Indirectement dans de nouveaux réponds sur les outils, en fait la partie de logiciel libre pour mettre en œuvre cette approche. En fait, Cette partie, 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 que tu partes ce que tu décrivais à l'instant sur l'intégration continue, sur les, donc sur les tests, sur le monitoring, sur le suivi de deux, le deux de l'application en conditions opérationnelles, tout ça, c'est faisable, en fait, avec des logiciels d'un point de vue technique. D'un point de vue technique, oui, en fait. Moi, c'est le poste. On est un peu plus amené à utiliser des logiciels libres. Tendance à penser qu'on n'utilise que ça. En fait, C'est-à-dire qu'au final, le le, le métier, il est assez nouveau. Ça fait moins de dix ans qu'on parle donc de ces cultures, développe ces deux 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 a même parfois plus loin et se dire 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, c'est. C'est vrai que ça, c'est un gros avantage. On n'écrit pas énormément de codes lorsque l'on fait du que cette culture développe du essaieront. 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 mis à disposition par d'autres, et c'est re. À travers le monde et c'est une communauté, au final, qui collaborent énormément, même inter-entreprises, et ça, c'est quelque chose qui me fait très plaisir à voir. Donc, c'est un nouveau métier qui s'est comme construit beaucoup autour de cette culture du logiciel libre. Accord, super, tu me fais un plus la transition avec le dernier sujet, quand le temps passe super vite, vous allez, allez, viens d'employer le terme communauté. Et xavier, toi tu voulais aborder un sujet, justement sur cette construction de communauté à travers l'association, notamment, de nitrites. Tout à fait, mais en fait, c'était. Je pense que c'est une aventure qui a commencé justement par la manière dont on a abordé avec nos clients. Au niveau de la nef. La problématique des votes et agilité en général, ou on s'est rendu compte finalement, de client en client, qu'ont rencontré tout le temps un peu les mêmes problématiques et on l'a vu, le la mise en œuvre de DevOps, c'est compliqué, surtout quand il y a un gros existant, etc. Et finalement, on se retrouve toujours un petit peu avec les mêmes. 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 internes pour des gens. 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 ses évolutions, de créer une communauté suffisamment importante pour que tout le monde puisse s'en emparer, adapté et finalement, Exploiter un outil- qui, qui, qui, qui aura vraiment une valeur sur la longueur? Et donc, quand on a fait ça, ce dont on s'est rendu compte, c'est qu'à l'opposé, on a beaucoup de de de gens qui, 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 Traiter une application comprend 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. 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 faire de, on veut généraliser, donc on commence à regarder à faire ça sur une vraie application pilote, en vraie réalité. 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, pour s'intégrer avec tout le reste du système d'information, il faut le traiter de la sécurité. C'est bien. On remet encore un petit peu de 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. On se disant: tiens. Finalement. Avec des approches comme, par exemple, celle qui consiste à essayer de Non pas directement d'implémenter des configurations techniques, mais d'essayer de modéliser, de 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. R. C'est une des choses qui sont très complexes: un code sur des typiquement d'infrastructures telles 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 dont commencer à identifier des choses, donc ont commencé à faire avec différents 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 des laboratoires internet pour essayer de continuer à développer ces choses. Ce jour-là, on s'est retrouvé à faire de la haïr aidés, 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 nos petites taille- on est pas gros pour une société de services- Eh bien, on n'avait pas les reins assez solides pour pouvoir créer. Du logiciel est typiquement mettre en œuvre des applications et des concepts qu'on était en train de développer. J'ai dit: mais finalement on y perd. Même avant 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, leur savoir-faire. D'où l'idée de se dire un moment: et si on externalisé 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 aura. Pas les moyens de le faire ou 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 l'idée, sur les idées libristes. Et donc on a créé Une, une association loi mille neuf cent un, qui s'appelle district 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: bien ce coup. Comment savoir ce qu'on arrive à faire avec d'autres pour ces rencontres? S'il y a surement moyen de le rendre disponible pour tout à chacun. Et si on est vraiment sur une organisation transverse qui n'a strictement aucun intérêt. Pécunier, on va dire, et que on arrive à attirer et à créer une vraie communauté. D'entreprise, de d'étudiants de l'université, de personne 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, dietrich s'est construit, et dandy, très bien, on va avoir un étage réflexion, un film comme tout tank. Donc, on A un étage réflexion des groupes de travail. Donc, auparavant, pour un, 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, dans dans l'aspect, là-dedans rentrer tous les tout ce qu'on peut identifier sur le libre, et puis on a une incubation de projets open source, et donc, ces projets open source, c'est le statut de la société que Ça ne pourra jamais donner lieu à des fonctionnalités ou à quelques. Utilisation commerciale que ce soit. Et sept, cet incubateur a pour vocation de mettre en pratique des des idées et 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 Pour avancer et donc on a des collaborations au sein de nitrites avec des sociétés. Donc on a des fonds, la société générale, par exemple, qui nous, qui participent à des travaux. On va avoir des écoles qui viennent. Des universitaires qui participent aux travaux des et des contributeurs qui viennent de tout horizons. Fait intéressant, puisque, pour nous, on a tout à y gagner. C'est la seule manière de d'illustrer un peu nos 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 est 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. Dans la bonne nouvelle, c'est qu'on a été reconnue 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 donc ça va nous permettre d'accélérer encore et on commence à avoir des vraies contributions avec différentes sociétés. Et là, on voit toute la puissance que peut avoir ce, cet aspect communautaire, et Libre, qui fait que ça nous fait un levier qui nous permet vraiment d'accélérer ses développements, et c'est extrêmement intéressant. Voilà, Les lois pour pouf, pour la sonnerie, ces millions d'images que j'allais te faire. Quand on arrive à la fin du du du sujet. Donc je je m'excuse pour cette, pour cette sonnerie. Alors c'est très intéressant. Je renvoie sur le site web de nitrites. Un des dignité hérité, point i ou non, mettra les références sur le site web. Et ça me fait, et ça me fait penser que ce sujet de collaboration entre entreprises du livre industriel gron en compte sur des problématiques communes. On parle, dans les émissions notamment, peut-être tout autour, de pause graisse, cruel bientôt, mais Iv en fin de sujet, parce que voilà, on a un sujet court juste après. Je vois la dernière question traditionnelle de de, de de libra, vous du sujet principal. Donc, on va commencer par par romain, soufflet en moins de deux minutes. Quels seraient les points essentiels que tu souhaiterais rappeler, ou que les que tu souhaiterais que les gens qui nous écoutent Un en tête. Alors en deux minutes c'est un peu compliqué, mais ça j'ai envoyé la question avant. Si, si déjà fait, à la fin de l'émission, on arrive à faire passer l'idée de la culture DevOps de peu. 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 de 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 que ce serait déjà un peu démystifié, donc ce mot très obscur qui est des votes. Va très bien, xavier talon. Même question. 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 dans le tableau et qui, du coup, est une vraie transformation importante et qui touche vraiment tous les aspects. Et, par contre, ce qui je pense qu'il faut retenir aussi, c'est que des peuples, ce 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 faut prendre un petit peu de recul par rapport à ça. Et surtout, ce n'est pas parce qu'on fait du DevOps que il 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é. Et que je pense que ce qu'on, 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. Ben écoutez. Merci à tous les deux. Vous avez vraiment répondu au défi de faire comprendre ce qu'est des dévots ps au public. Deux de libre à vous, donc. Nos invités, xavier talos, co-fondateur et directeur technique de la société, ornaient ce président de district, association loi mille neuf cent un d'intérêt général qui traite de la transformation numérique, et romain soufflet s indépendant, s. 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 liban. En attendant, nous allons écouter dague, step fro, guy parent daech 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.

Chronique « Le libre et la sobriété énergétique » de Vincent Calame, bénévole à l’April = Marie-Odile

Frédéric Couchet : Nous allons poursuivre

Vincent Calame  :

[Virgule musicale]

Quoi de Libre ? Actualités et annonces concernant l'April et le monde du Libre = Marie-Odile

Frédéric Couchet :